- •Проектирование функциональной подсистемы автоматизированной информационной системы экономического объекта
- •Составитель: н.О. Никулина
- •1 Цели и задачи курсового проектирования
- •2 Тематика и содержание курсовых проектов
- •3 Задания по курсовому проектированию
- •4 Правила оформления пояснительной записки
- •5 Методика курсового проектирования
- •5.1. Основные теоретические сведения о проектировании автоматизированной экономической информационной системы.
- •5.1.1. Структура автоматизированной экономической информационной системы.
- •5.1.2. Понятие технологии проектирования аэис
- •5.1.3. Жизненный цикл аэис.
- •1 Стадия – предпроектное обследование
- •2 Стадия – проектирование
- •3 Стадия – ввод системы в действие:
- •4 Стадия – промышленная эксплуатация:
- •5.1.4. Понятие реинжиниринга аэис.
- •5.2. Проведение предпроектного обследования.
- •5.2.1. Общая характеристика экономического объекта.
- •5.2.2. Выделение функциональной подсистемы аэис.
- •5.2.3. Технико-экономическое обоснование необходимости разработки/реинжиниринга фп аэис.
- •5.2.4. Разработка технического задания на создание функциональной подсистемы аэис
- •5.3. Проектная часть
- •5.3.1. Постановка задачи на разработку функциональной подсистемыследование бизнес-процесса)о желанию). Системы ора оптимального проектного решения.0000000000000000000000000000000000000000.
- •5.3.2. Разработка функциональной модели подсистемы
- •5.3.3. Разработка информационного обеспечения подсистемы
- •5.3.3.1. Классификаторы технико-экономической информации.
- •5.3.3.2. Разработка локального классификатора для функциональной подсистемы аэис.
- •5.3.3.3. Разработка информационной модели подсистемы.
- •5.3.4. Разработка программного обеспечения подсистемы
- •Разработка алгоритма работы подсистемы.
- •Реализация интерфейса пользователя подсистемы.
- •5.3.4.1. Выбор программного обеспечения для реализации подсистемы.
- •5.3.4.2. Разработка алгоритма работы подсистемы.
- •5.3.4.3. Реализация интерфейса пользователя подсистемы.
- •Список использованных источников
- •Приложение 1. Классификация бизнес-процессов
- •Приложение 2. Форма проведения обследования бизнес-процесса
- •Приложение 3. Формирование требований пользователя к аэис
- •Приложение 4. Техническое задание на разработку аэис
5.3.3.3. Разработка информационной модели подсистемы.
С целью соблюдения одного из принципов создания АЭИС [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. Этот отчет предоставляет информацию о совокупности данных, используемых в процессе решения задачи. Следовательно, эти же данные должны присутствовать и в информационной модели.
Для построения информационной модели сначала необходимо провести анализ отчета по следующей схеме:
выявление ошибок построения функциональной модели, связанных с нарушением стандарта проектирования SADT:
неописанные стрелки (Unnamed Arrow) – в функциональной модели присутствуют необозначенные стрелки, как правило, это стрелки, соединяющие два последовательно расположенных функциональных блока;
несвязанные элементы функциональной модели – некоторые функциональные блоки не имеют входов, выходов или механизмов управления;
неправильное именование стрелок, например, глаголом или отглагольным существительным, обозначающим действие;
стрелки, названные по-разному, но обозначающие один и тот же объект, например, «Нач.» и «Начальник», «Док-т» и «Документ»;
исправление ошибок проектирования. Эти ошибки исправляются путем возврата на указанные диаграммы функциональной модели, внесения изменений и повторным созданием отчета.
выделение и удаление «лишних» данных, служащих только для пояснения функциональной модели и не несущих смысловой нагрузки в информационной модели (к этой группе относятся также стрелки-механизмы, обозначающие ИС);
выделение данных, означающих движение информационного элемента по его жизненному циклу, например, «проект приказа», «зарегистрированный приказ», «подписанный приказ» и т.д. В этом случае необходимо оставить только один, исходный, информационный элемент – «приказ»;
оставшиеся данные нужно распределить по следующим группам:
сущности, отражающие нормативную или справочную информацию (к ним относятся ГОСТы, стандарты предприятия, классификаторы, справочники и т.д.);
сущности, являющиеся документами (это основные информационные элементы, в которых отражается суть решаемой задачи или смысл бизнес-процесса – приказы, акты, заявления и т.д.);
сущности, отражающие информацию о сотрудниках или организационной структуре (это стрелки-механизмы, указывающие отношение сотрудников или структурных подразделений к обработке того или иного документа);
атрибуты вышеперечисленных сущностей, являющиеся реквизитами документов или сотрудников («номер», «дата», «подпись», «ФИО» и т.д.). Атрибуты сущностей информационной модели должны совпадать со структурными единицами информации в постановке задачи (п. 5.3.1).
После анализа отчета можно приступать к проектированию информационной модели в ERWin v. 4.0-4.1x или в IDEF1X v. 3.1-3.5 [7]. Информацию об отношениях между сущностями можно получить из функциональной модели.