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