22
- разработать и обосновать требования, предъявляемые к подсистемам;
- разработать и обосновать требования, предъявляемые к
информационной системе, программному и математическому обеспечению;
- установить общие требования к проектируемой информационной
системы и определить перечень исполнителей;
- провести предварительный расчёт затрат на создание системы и
определить уровень экономической эффективности внедрения.
Технический проект включает в свой состав техническую
документацию, отражающую общесистемные проектные решения,
алгоритмы решения задач, а также результаты экономической оценки
эффективности автоматизированной системы. На этом этапе проводится
научно-исследовательские и экспериментальные работы по выбору
проектных решений. На стадии рабочего проектирования выполняется
создание программного продукта и подготовка комплекта сопровождающей
документации [19, c.60].
В состав сопровождающей документации входит вся информация по
обеспечению выполнения работ и ввода информационной системы в
эксплуатацию.
Для информационной системы проводят предварительные, опытно-
эксплуатационные и приемочные испытания.
На стадии предварительных испытаний определяют работоспособность
системы и решают вопросы по приемке в опытную эксплуатацию. Опытная
эксплуатация предусматривает определение фактических качественных и
количественных показателей по ее функционированию, корректировку в
случае необходимости документации. На стадии приемочных испытаний
определяют соответствие разработанного программного продукта
техническому заданию.
Типовое проектирование отличается от канонического проектирования
тем, что в его основе находится декомпозиция проектируемой
23
информационной системы, выделение в ней программных модулей,
подсистем, комплексов задач.
Для разработки компонентов применяют типовые решения,
позволяющие увеличить функциональность программного продукта. Типовое
проектирование предусматривает обязательное наличие документации,
позволяющей описать процедуру разработки и настройки системы.
На первом этапе определяется область, в отношении которой
производится разработка. На втором этапе выбираются средства для
реализации пилотного проекта по разработке программного обеспечения,
составляется график выполнения работ [26, c.105].
На заключительном этапе разрабатываются модуля, организовываются
их взаимосвязь с базой данных и подготавливается документация,
позволяющая сопровождать автоматизированную информационную систему.
При типовом проектировании автоматизированной информационной
системы используют несколько классов, характеристика которых приведена
в таблице 3.
Таблица 3
Классы типовых решений
Класс типового
решения
Описание
Элементарные
типовые
решения
В их основе находится информационное, программное,
техническое, организационное, математическое
обеспечение
Подсистемные
типовые
проектные
решения
Их элементами выступают подсистемы разработанного
программного продукта с учетом полноты и
минимизации внешних связей
Объектные
типовые
решения
Отраслевые проекты, в состав которых входят
обеспечивающие и функциональные подсистемы
программного продукта
Для реализации типового проектирования можно использовать один из
подходов: параметрическое ориентированное проектирование или модельно-
ориентированное проектирование.
24
Параметрическое ориентированное проектирование предусматривает
выделение критериев оценки для решения поставленных задач, выбор и
закупку много пакета для разработки программного обеспечения.
В основе модельно-ориентированного проектирования находится
адаптация состава программного продукта к типовой модели объекта
автоматизации. В этом случае при проектировании обеспечивается
взаимосвязь между типовой и концептуальной моделью [31, c.23].
Типовые модели позволяют описать конфигурацию
автоматизированной информационной системы, определить ее
функциональность и особенности работы. Реализация типового проекта
предусматривает выполнение операций по установке глобальных
параметров, заданию структуры объекта автоматизации, определению
перечня функций и процессов, описание интерфейсов и отчетов, настройку
параметров доступа и защиты данных.
На основании рассмотренных теоретических основ разработки и
использования корпоративных автоматизированных информационных
систем можно сделать следующие выводы:
1) автоматизированная информационная система является системой,
выполняющей функции по сбору, обработке и предоставлению пользователю
результирующей информации в графическом или фактографическом виде;
2) в состав автоматизированной системы управления входят блоки
ввода информации из внутренних и внешних источников, обработки и
вывода информации. Для работы автоматизированной информационной
системы применяется информационное, программное, техническое,
математическое и правовое обеспечение;
3) исследования показали, что в настоящее время выделяют MRP-
системы для минимизации складских запасов и производственных
мощностей, MRPII-системы, ERP-системы и CSRP-системы;
25
4) в соответствии с международным стандартом ISO/IEC 12207 все
процессы жизненного цикла в автоматизированной информационной системе
разделяются на три основные группы с выделением основных,
вспомогательных и организационных процессов;
5) в работе рассмотрены такие модели жизненного цикла как каскадная
модель, каскадная модель с обратной связью, каскадная V-образная модель,
итерационная модель с перекрытием итераций и спиральная модель;
6) Проектирование автоматизированной информационной системы
включает выполнение канонического и типового проектирования. Во время
проектирования автоматизированной информационной системы выполняется
разработка технического задания, подготавливается комплект технической
документации.
Проведенные исследования и полученные выводы позволяют перейти к
рассмотрению второй главы, посвященной рассмотрению основных
принципов разработки автоматизированных информационных систем.
26
ГЛАВА 2. ОСНОВНЫЕ ПРИНЦИПЫ РАЗРАБОТКИ
АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
2.1 Методологии и стандарты для разработки АИС
Методологической основой разработки IT-проекта является
моделирование, выступающее процессом исследования реальной системы и
предусматривающее разработку модели.
Стандарты разработки АИС включают:
1) ГОСТ 34.601-90 применяется на этапах разработки и определения
этапов работ. В нем описываются модели жизненного цикла;
2) ISO/IEC 12207 для определения процессов жизненного цикла.
Применяется в отношении заказного программного обеспечения;
3) Методика Oracle используется для разработки прикладного
программного обеспечения;
4) Методика RUP применяется в случае использования итеративной
модели разработки, в которой каждый цикл предусматривает генерацию
новой версии системы;
5) Методика MSF применяется в случае разработки бизнес-
приложений;
6) Методика XP применяется при разработке и доработке прототипов
программного обеспечения.
Модель представлена в виде логической конструкции, позволяющей
воспроизвести различные характеристики объекта исследования с учетом
сформированных требований к разработке. Модель предметной области
представляет собой некоторую систему, отражающую функционирование
объекта исследования. Предварительное моделирование предметной области
позволяет сократить время и сроки разработки и исключить ошибки на
первоначальном этапе проектирования [4, c.70].
К моделям предметной области предъявляются следующие требования:
27
- однозначность при описании структуры предметной области;
- понятность для заказчика и разработчика;
- выбор средств описания модели предметной области;
- оценка эффективности реализации модели с определением
показателей.
Проведение моделирования находится в основе структурного анализа,
в результате которого отображается объектная структура, функциональная
структура и структура управления. К функциональным методикам
моделирования относятся методы IDEF, позволяющие представить объект
исследования в виде набора функций. Среди наиболее известных нотаций
методов IDEF выступают нотации IDEF0, IDEF3 и DFD.
Методология IDEF0 применяется для исследования функций
разрабатываемой автоматизированной информационной системы.
При разработке модели в нотации IDEF0 создается диаграмма,
представленная в виде набора взаимосвязанных между собой бизнес-
процессов. Каждый процесс или функция представлена в виде блока,
имеющего с четырех сторон входящие в его состав интерфейсы управления,
механизма и входов и выходов [9, c.55].
Контекстная диаграмма модели бизнес-процессов в нотации IDEF0
приведена на рисунке 7.
Рисунок 7 – Контекстная диаграмма модели бизнес-процессов в
нотации IDEF0
28
Как видно из рисунка 7, верхняя стрелка функционального блока
означает управление и отображает регламенты и правила выполнения
бизнес-функции. Левая стрелка имеет значения «Вход» и с ее помощью
отображаются информационные и материальные потоки, поступающие на
вход бизнес-функции. Правая стрелка обозначает «Выход» и она отображает
результирующие информационные и материальные потоки. Нижняя стрелка
имеет значение «Механизм» и с ее помощью отображаются ресурсы,
позволяющие привести в исполнение процесс.
Важным понятием нотации IDEF0 является декомпозиция, основанная
на разбиении сложного процесса на несколько составляющих. Уровень
детализации определяется разработчиком модели и позволяет представить
модель в виде иерархической структуры нескольких диаграмм.
Можно сказать, что в процессе декомпозиции функциональный блок
верхнего уровня разбивается на несколько функциональных блоков,
отражающих подфункции главной контекстной диаграммы.
Схема выполнения декомпозиции модели бизнес-процессов в нотации
IDEF0 приведена на рисунке 8.
Рисунок 8 – Схема выполнения декомпозиции модели бизнес-
процессов в нотации IDEF0
При выполнении декомпозиции существует возможность каждой из
подфункций дочерней диаграммы детализировать на следующих уровнях
декомпозиции.
29
Расширением нотации IDEF0 является модель потоков данных DFD.
Основными понятиями модели DFD являются процессы, преобразованные
входные потоки данных, внешние сущности, накопители [11, c.54].
Потоки данных являются абстракциями и позволяют передавать
информацию из одной части системы в другую. Для отображения потоков на
диаграмме используется стрелки. Назначением работ является отражение
выходных и входных потоков в соответствии с действиями, позволяющими
реализовать процесс.
Для указания данных, которые будут находиться во внешней памяти
или базе данных в состав модели DFD входят хранилища, а для
представления материальных объектов или пользователей подсистемы
применяется внешняя сущность. Кроме основных элементов в состав модели
DFD входит миниспецификация и словарь данных. Словарь данных
применяется для описания элементов системы, а с помощью мини
спецификации описываются алгоритмы и задачи нижнего уровня.
Для описания последовательности действий и логики взаимодействия
информационных потоков применяется нотация IDEF3.
Модель в нотации IDEF3 дополняет нотацию IDEF0 и включает в свой
состав сценарии действий пользователей в автоматизированной
информационной системе (например, описание последовательности
обработки события или заказа) [6, c.40].
Работы в нотации IDEF3 отображаются в виде прямоугольников, а
связи в виде стрелок. Кроме работ и связей в нотации IDEF3 применяются
перекрестки, отображающие последовательное или параллельное
выполнение работ.
Схема разработки модели в нотации IDEF3 приведена на рисунке 9.
30
Рисунок 9 – Схема разработки модели в нотации IDEF3
Для реализации функционально-ориентированного подхода
выполняется разработка диаграммы «сущность-связь». В этой диаграмме
сущность представлена в виде экземпляров абстрактных или реальных
объектов, имеющих характеристики и общие атрибуты.
При разработке диаграммы «сущность-связь» или ER-диаграммы
необходимо учитывать, что каждая сущность должна иметь уникальное имя,
атрибуты и наследовать связь с другими сущностями.
Атрибут сущности представлен в виде характеристики или свойств
ассоциированных с абстрактными сущностями или объектами. Каждый
атрибут имеет экземпляр, позволяющий определить характеристику
отдельного элемента или множества [17, c.280].
Нотация IDEF1X позволяет описать диаграмму «сущность-связь». В
этой нотации сущность может быть зависимой и определяться отношениями
с другой сущностью. Схема разработки модели в нотации IDEF1X приведена
на рисунке 10.
Между сущностями применяются идентифицирующие и не
идентифицирующие связи. Идентифицирующая связь используется, когда
необходимо показать связь между сущностью-родителем и сущностью-
потомком. Если сущность-потомок независима от родителя, то тогда
применяется не идентифицирующая связь.
31
Рисунок 10 – Схема разработки модели в нотации IDEF1X
Объектно-ориентированные подходы к проектированию
автоматизированных информационных систем реализованы в
унифицированном языке моделирования UML. В соответствии с концепцией
UML модель сложной системы включает элементы, которые можно
представить в статике и динамике.
Можно сказать, что язык UML имеет сложную иерархическую
структуру взаимосвязанных диаграмм, позволяющих описать процессы,
происходящие в разрабатываемой информационной системе. С помощью
унифицированного языка UML можно выполнить разработку диаграмм
прецедентов, классов, компонентов, развертывания, а также отобразить
поведения системы на основании диаграмм состояний, деятельности,
последовательности, кооперации [22, c.49].
Каждая из этих диаграмм позволяет получить различное представление
о разрабатываемой автоматизированной информационной системе.
Диаграмма прецедентов применяется для отображения
функциональности моделируемой системы. Ее основными компонентами