Teaching methodology for modeling the activities of company within the discipline “Design of information systems”

Full Text

Постановка проблемы. Дисциплина «Проектирование информационных систем» - одна из фундаментальных на направлениях бакалавриата, связанных с информационными технологиями и программированием. Поэтому качественное усвоение материала этой дисциплины является важнейшим этапом в становлении обучающихся как профессионалов. Одной из тем, которая вызывает существенные затруднения у студентов, выступает моделирование деятельности предприятий с помощью графических нотаций. Для этой цели могут использоваться такие нотации, как IDEF0, IDEF3, BPMN, ARIS и ряд других [1-4]. Многие работы по методике преподавания моделирования делают упор либо на приобретении навыков работы с CASE-средствами [5], либо на проектном подходе с большим количеством практики, что кажется очень естественным при обучении проектированию [6; 7]. При этом запоминание самого графического языка и обучение навыков работе с CASE-средствами почти никогда не вызывает трудностей у студентов. Однако, как только они сталкиваются с конкретной практической задачей, часто бывают не в состоянии применить этот язык правильно. Синтаксически корректные модели, построенные студентами, оказываются бесполезными. Трудности понимания приводят к тому, что модели деятельности предприятий при использовании проектных методик в курсовых и дипломных работах делаются «для галочки» и «задним числом», когда информационная система (ИС) для этого предприятия уже спроектирована и даже разработана. Такие модели не приносят реальной пользы при проектировании ИС, а работа над ними не формирует у студентов понимания реального назначения моделирования. Целью исследования является разработка методики обучения построению моделей деятельности предприятий на примере нотации IDEF0 [1], которая поможет сформировать у студентов более глубокое понимание темы. Методология. В ходе исследования применялись такие общенаучные методы, как анализ, синтез и формализация. В [8; 9] Дж. Свеллером и П.А. Киршнером вводится классификация методик обучения, которая делит их на две основные группы: методики со слабым руководством и методики с сильным руководством. К методикам со слабым руководством относятся такие, которые поощряют обучающегося самостоятельно искать решения поставленных проблем, не давая прямых и однозначных путей решения. Например, проектные методики, проблемное обучение и др. Считается, что обучающиеся приобретают знания и усваивают навыки именно в процессе активного решения проблемы. Преподаватель в таких методиках играет скорее роль фасилитатора [8, c. 75]. Методики с сильным руководством, наоборот, построены на том, чтобы обеспечить обучающегося четкими и однозначными инструкциями. Обучение состоит в запоминании этих инструкций и приобретении навыков их применения на практике [8, c. 80]. П.А. Киршнер и Дж. Свеллер доказывают в [8; 9], что все методики со слабым руководством работают намного хуже, чем методики с сильным руководством. Свое утверждение авторы основывают на особенностях взаимо- действия кратковременной и долговременной памяти человека. Именно из-за особенностей этого взаимодействия, по их мнению, наблюдается парадокс: проектные и проблемные методики приводят к решению проблемы или реализации проекта, но не способствуют приобретению устойчивых навыков и фундаментальных знаний у обучающихся, которые только начинают знакомство с дисциплиной. Эти методики могут быть полезными для людей, которые уже имеют некоторый критический минимум знаний и навыков, так как в этом случае взаимодействие кратковременной и долговременной памяти происходит по иной схеме [8, c. 76, 77]. Студенты, которые сталкиваются с моделированием впервые, не обладают достаточным кругозором, пониманием бизнес-процессов, поэтому им требуются методики с сильным руководством и четкими инструкциями. Трудность обучения состоит в том, что для задач моделирования деятельности предприятий такие инструкции сложно сформулировать. У них нет единственно правильного решения. Если, например, у моделей «сущность - связь», применяемых при проектировании баз данных, есть четкие критерии корректности - соответствие нормальным формам реляционной теории [10; 11], то при моделировании бизнес-процессов такие критерии отсутствуют или выглядят очень размытыми. Экспериментальная работа проводилась на базе Донецкой академии управления и государственной службы. В эксперименте приняли участие 79 студентов второго курса бакалавриата направления подготовки 09.03.03 «Прикладная информатика». Цель исследования - выявление качественных изменений в выполнении индивидуальных проектов студентами при использовании методики обучения, предложенной в данной работе. Эксперимент заключался в анонимном анкетировании после защиты студентами индивидуальных проектов и статистической обработке результатов анкетирования. Результаты и обсуждение. Основной задачей при разработке методики обучения моделированию деятельности предприятий является создание четких инструкций к действиям и критериев проверки правильности модели. В литературе описано два основных метода создания четких инструкций: 1. Готовые работающие примеры, которое позволяют не тратить время на поиск информации, а сразу усваивать верные ходы решения и их взаимосвязи [12]. 2. «Рабочие листы процесса». Такие «рабочие листы» содержат описание этапов, которые необходимо пройти для решения проблемы, а также подсказки и эмпирические правила для успешного завершения каждого этапа [13-15]. Специфика обучения моделированию в нотации IDEF0 состоит в том, что интернет содержит огромное количество готовых примеров для разных задач, но в большей части этих примеров имеются грубые ошибки. Поэтому акцент при обучении должен быть сделан на «рабочих листах» с четкими критериями правильности модели. Изучен ряд типичных ошибок, которые допускают при выполнении заданий по моделированию студенты специальности 09.03.03 «Прикладная информатика», и на основании этих ошибок предложен ряд эмпирических правил, из которых и должен быть сформирован «рабочий лист». Первая ошибка заключается в некорректном использовании знаков нотации IDEF0. Нотация использует всего два графических символа: прямоугольник и стрелка. При этом прямоугольник всегда означает функцию или процесс, а стрелка может означать артефакт, необходимый для выполнения процесса. Стрелки делятся на четыре группы: вход, выход, управление и механизм. В английском языке процесс обозначается герундием, которому в русском языке соответствует отглагольное существительное. Для русскоязычных студентов легко стирается смысловая грань между отглагольным существительным и просто существительным, поэтому нередко в своих работах они вписывают имена существительные в прямоугольники. Чтобы исключить эту ошибку следует ввести следующие два правила. Правило 1. Прямоугольник всегда означает процесс. Процесс - это действие, поэтому он должен быть обозначен глаголом в инфинитиве и существительным. Глагол обозначает действие, существительное обозначает объект, на который направлено действие. Например, не «Прием товара», а «Принимать товар». Правило 2. Стрелка - это артефакт, который нужен для выполнения процесса. Стрелка любой из четырех групп может обозначаться только именем существительным. На рис. 1 представлено корректное использования символов нотации IDEF0. Вторая распространенная ошибка - это возникновение путаницы между входами и механизмами. И входы, и механизмы - это артефакты, без которых процесс не может начаться. Например, прием товара на склад не может произойти без использования весов, поэтому многие обучающиеся изображают на диаграмме и весы, и товар как входы. Для исключения таких ошибок целесообразно использовать правило 3. Изображение выглядит как текст, диаграмма, линия, Параллельный Автоматически созданное описание Рис. 1. Корректное использование символов нотации IDEF0 Изображение выглядит как диаграмма, текст, линия, Параллельный Автоматически созданное описание Figure 1. Correct use of IDEF0 notation symbols Правило 3. Те артефакты, которые преобразуются внутри процесса и в конечном счете оказываются включены в выход, должны рассматриваться как входы. Те артефакты, которые многократно используются как инструменты и не включены в выход из процесса, следует рассматривать как механизмы. Например, товар на рис. 2 в результате процесса принятия на склад появляется на выходе, но с другим статусом. Теперь это уже оприходованный товар. Поэтому товар изображен как вход. Весы же могут многократно использоваться при каждом приеме товара на склад и не являются ни выходом, ни частью выхода. Поэтому весы - это механизм. Следует учитывать, что при изучении дисциплины «Проектирование информационных систем» моделирование деятельности предприятия требуется именно для последующего проектирования ИС. Как правило, курс проектирования студенты изучают уже после завершения курса баз данных. Это означает, что с одной стороны они уже имеют представление о том, что такое диаграмма «сущность - связь» и нотация IDEF1X, а с другой - привыкли проектировать базы данных исключительно на основе словесного описания предметной области. Такая последовательность изучения дисциплин создает у обучающихся непонимание назначения процессного моделирования. Зачем нужна модель в нотации IDEF0, если на основе словесного описания можно выделить сущности предметной области? Необходимо донести до обучающихся, что моделирование деятельности предприятия предшествует проектированию базы данных. Диаграмма «сущность - связь» должна основываться на диаграмме в нотации IDEF0 и находиться в полной согласованности с ней. Поэтому целесообразно оценивать корректность модели в нотации IDEF0, только рассматривая ее вместе с диаграммой в нотации IDEF1X. При этом критерием корректности является правило 4. Правило 4. Стрелки модели в нотации IDEF0, относящиеся к группам «вход» и «выход», должны стать либо сущностями, либо экземплярами сущностей, либо атрибутами сущностей на диаграмме «сущность - связь». Все сущности диаграммы «сущность - связь» должны соответствовать стрелкам на процессной модели. В качестве примера рассмотрим фрагмент диаграммы, приведенный на рис. 2. Для простоты на диаграмме не рассматриваются управляющие воздействия. Изображение выглядит как текст, диаграмма, линия, План Автоматически созданное описание Рис. 2. Фрагмент диаграммы в нотации IDEF0 Изображение выглядит как текст, диаграмма, План, линия Автоматически созданное описание Figure 2. Diagram fragment in IDEF0 notation Диаграмме соответствует следующее словесное описание: На склад товары поступают двумя способами: либо как поставка, либо как возврат. Диспетчер склада проводит процедуру принятия поставки, после чего оприходованные товары поступают в складское помещение на хранение. Также диспетчер принимает возврат и отправляет возвращенные товары в складское помещение на хранение. С точки зрения синтаксиса в этом фрагменте нет ошибок. Но оценить его корректность можно только при одновременном рассмотрении с диаграммой в нотации IDEF1X. Для этого достаточно будет диаграммы уровня «Сущности» (Entities), представленной на рис. 3. Изображение выглядит как текст, диаграмма, снимок экрана, линия Автоматически созданное описание Рис. 3. Фрагмент диаграммы в нотации IDEF1X уровня «Сущность» Изображение выглядит как текст, диаграмма, линия, План Автоматически созданное описание Figure 3. Fragment of a diagram in the IDEF1X notation of the “Entity” level При проектировании связей становится очевидно, что для описания процессов поставки и возврата должны быть выделены соответствующие сущности. Этими сущностями будут документы, описывающие поставку и возврат - приходная накладная и накладная возврата. Далее при правильном проектировании должны возникнуть еще две «слабые» сущности, которые описывают данные оприходованных и возвращенных товаров. На рис.4 они называются «Табличная часть приходной накладной» и «Табличная часть возвратной накладной». Но накладные никак не отражены на фрагменте диаграммы IDEF0, представленном на рис. 2. Поэтому, невзирая на отсутствие синтаксических ошибок, этот фрагмент нельзя назвать корректным. Более корректным будет фрагмент диаграммы, представленный на рис. 4. Он дополнен стрелками «Приходная накладная» и «Накладная возврата». Изображение выглядит как текст, диаграмма, План, линия Автоматически созданное описание Рис. 4. Дополненный фрагмент диаграммы в нотации IDEF0 Изображение выглядит как текст, диаграмма, План, линия Автоматически созданное описание Figure 4. Supplemented diagram fragment in IDEF0 notation В заданиях для обучающихся целесообразно оговаривать отдельное требование изобразить таблицу соответствия стрелок диаграммы IDEF0 и сущностей диаграммы IDEF1X. Это требование будет стимулировать обучающихся к самостоятельному поиску ошибок в диаграммах. Такая таблица соответствия моделей IDEF0 и IDEF1X для рассмотренной выше задачи приведена ниже. Пример таблицы соответствия моделей IDEF0 и IDEF1X Стрелки Сущности Товар, оприходованный товар, возвращенный товар Товар Приходная накладная Приходная накладная, табличная часть приходной накладной Накладная возврата Накладная возврата, табличная часть накладной возврата Диспетчер склада Сотрудники Складское помещение Складские помещения Example of a correspondence table for IDEF0 and IDEF1X models Arrows Entities Goods, credited goods, returned goods Goods Purchase invoice Purchase invoice, table part of purchase invoice Return note Return note, table part of return note Warehouse manager Employees Warehouse spaces Warehouse spaces Следующей задачей исследования стало проведение эксперимента, который покажет качественные изменения в выполнении индивидуальных проектов студентами. В эксперименте приняли участие 79 студентов второго курса бакалавриата направления подготовки 09.03.03 «Прикладная информатика». В процессе изучения дисциплины «Проектирование информационных систем» студенты работали над итоговым проектом информационной системы. Испытуемые были разделены на две группы. Первая состояла из 42 студентов, которые использовали при моделировании в нотации IDEF0 официальную документацию по этой нотации [1]. Вторая - из 37 студентов, которые использовали «рабочие листы», составленные на основе перечисленных выше четырех правил. После завершения работы над проектом студентам предлагался анонимный опрос из следующих вопросов: 1. Использовали ли вы реально модель деятельности предприятия в нотации IDEF0 при проектировании информационной системы? Варианты ответов: - Да, я опирался на модель в процессе проектирования. - Нет, не использовал. Просто требовалось включить модель в пояснительную записку, поэтому я вынужден был ее создать. 2. Сколько раз вам возвращали проект базы данных на доработку по причине упущенных требований заказчика? Варианты ответов: - 1-2 раза. - 3-5 раз. - более 5 раз. Опрос показал, что 85 % студентов первой группы не использовали модель в нотации IDEF0 при проектировании, хотя создавали ее, так как необходимо было включить модель в пояснительную записку к проекту. Более 5 раз переделывали проект базы данных по причине упущенных требований заказчика 73 % студентов этой же группы. Еще 20 % переделывали проект базы данных от 3 до 5 раз. Во второй группе все 100 % студентов сказали, что они опирались на модель в нотации IDEF0 при проектировании информационной системы. В этой группе не было ни одного студента, кто переделывал бы проект базы данных более 5 раз. Почти половине студентов второй группы (44 %) оказалось достаточно двух попыток для создания корректного проекта базы данных, учитывающего все требования заказчика. Остальным студентам (56 %) понадобилось чуть больше попыток - от трех до пяти. Заключение. Основной трудностью обучения моделированию деятельности предприятий на основе нотации IDEF0 является размытость критериев правильности построенной модели и наличие многочисленных альтернатив. Предложенные четыре эмпирических правила составляют «рабочий лист», который обучающийся должен иметь перед началом самостоятельного выполнения заданий по моделированию на основе нотации IDEF0. «Рабочий лист» обеспечивает понятные критерии для проверки и самопроверки результатов задания. Результаты эксперимента показали, что использование предложенного «рабочего листа» обеспечило более осознанный подход обучающихся к моделированию и, как следствие, более корректное выполнение поставленных перед ними задач проектирования.

About the authors

Elena G. Litvak

Donetsk Academy of Management and Public Administration

Author for correspondence.
Email: alttt@yandex.ru
ORCID iD: 0000-0002-9123-5053

Candidate of Economic Sciences, Associate Professor, Assistant Professor of the Department of Information Technologies

163а Cheluskintsev St, Donetsk, 283015, Russian Federation

References

Supplementary files