Разработка информационной модели подсистемы.

С целью соблюдения одного из принципов создания АЭИС [5, 8] (принципа однократного ввода данных) информационная модель подсистемы разрабатывается на основе функциональной модели предлагаемого бизнес-процесса (п. 5.3.2) [6].

Для этого необходимо построить отчет по функциональной модели, используя в BPWin v.4.0-4.1.x. команду Tools/Reports/Arrow Report... или используя в IDEF v.3.1-3.5 команду Data/Report/Arrow Report. Этот отчет предоставляет информацию о совокупности данных, используемых в процессе решения задачи. Следовательно, эти же данные должны присутствовать и в информационной модели.

Для построения информационной модели сначала необходимо провести анализ отчета по следующей схеме:

1) выявление ошибок построения функциональной модели, связанных с нарушением стандарта проектирования SADT:

· неописанные стрелки (Unnamed Arrow) – в функциональной модели присутствуют необозначенные стрелки, как правило, это стрелки, соединяющие два последовательно расположенных функциональных блока;

· несвязанные элементы функциональной модели – некоторые функциональные блоки не имеют входов, выходов или механизмов управления;

· неправильное именование стрелок, например, глаголом или отглагольным существительным, обозначающим действие;

· стрелки, названные по-разному, но обозначающие один и тот же объект, например, «Нач.» и «Начальник», «Док-т» и «Документ»;

2) исправление ошибок проектирования. Эти ошибки исправляются путем возврата на указанные диаграммы функциональной модели, внесения изменений и повторным созданием отчета.

3) выделение и удаление «лишних» данных, служащих только для пояснения функциональной модели и не несущих смысловой нагрузки в информационной модели (к этой группе относятся также стрелки-механизмы, обозначающие ИС);

4) выделение данных, означающих движение информационного элемента по его жизненному циклу, например, «проект приказа», «зарегистрированный приказ», «подписанный приказ» и т.д. В этом случае необходимо оставить только один, исходный, информационный элемент – «приказ»;

5) оставшиеся данные нужно распределить по следующим группам:

· сущности, отражающие нормативную или справочную информацию (к ним относятся ГОСТы, стандарты предприятия, классификаторы, справочники и т.д.);

· сущности, являющиеся документами (это основные информационные элементы, в которых отражается суть решаемой задачи или смысл бизнес-процесса – приказы, акты, заявления и т.д.);

· сущности, отражающие информацию о сотрудниках или организационной структуре (это стрелки-механизмы, указывающие отношение сотрудников или структурных подразделений к обработке того или иного документа);

· атрибуты вышеперечисленных сущностей, являющиеся реквизитами документов или сотрудников («номер», «дата», «подпись», «ФИО» и т.д.). Атрибуты сущностей информационной модели должны совпадать со структурными единицами информации в постановке задачи (п. 5.3.1).

После анализа отчета можно приступать к проектированию информационной модели в ERWin v. 4.0-4.1x или в IDEF1X v. 3.1-3.5 [7]. Информацию об отношениях между сущностями можно получить из функциональной модели.

Разработка программного обеспечения подсистемы

Заключительным этапом курсового проектирования является разработка программного обеспечения для пользователя функциональной подсистемы АЭИС. Этот этап выполняется по следующей схеме:

5.3.4.1. Обоснование выбора программного обеспечения для реализации подсистемы.

5.3.4.2. Разработка алгоритма работы подсистемы.

5.3.4.3. Реализация интерфейса пользователя подсистемы.

5.3.4.4. Разработка инструкции пользователя по работе с подсистемой с приведением экранных форм, отражающих последовательность получения результатной информации.