Файл: Анализ и оценка реализации структурных методов анализа и проектирования экономической информационной системы.pdf

Рисунок 2. Структура каскадной модели жизненного цикла программного обеспечения [13]

При завершении определенных фаз проекта происходит формировании базовой линии, которая в данной точке осуществляет фиксацию состояния АИС. При возникновении потребности во внесении изменения в проект, используется формальный процесс изменений [4].

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

С ростом объема коммерческих проектов разработки программных продуктов было установлено, что детальная проработка проекта разрабатываемой системы не всегда удается на этапе анализа, потому что многие аспекты функционирования АИС в динамических сферах деятельности меняются во время создания информационной системы. В связи с этим потребовалось внесение изменений в процесс разработки АИС таким образом, чтобы гарантировалось внесение необходимых исправлений после завершения какого-либо этапа разработки. Это послужило созданию итерационной модели жизненного цикла программного продукта [12].

Итерационную модель также называют моделью с промежуточным контролем или моделью с циклическим повторением фаз. Структура итерационной модели представлена на рисунке 3.

Рисунок 3. Итерационная модель жизненного цикла программного обеспечения

При использовании итерационной модели жизненного цикла разработки программного обеспечения существует возможность устранения недостатков проектирования и программирования на более поздних стадиях при частичном возврате на предыдущие стадии. При этом чем позже будет выявлена ошибка, тем дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше [7].

Спиральная модель жизненного цикла программного продукта была разработана Б. Боэмом в 1988. Основу модели составляют лучшие свойства каскадной модели жизненного цикла с учетом процесса макетирования, к которым был добавлен новый элемент – анализ риска, который отсутствовал в этих моделях. Спиральная модель состоит из четырех этапов, которые представлены четырьмя квадрантами спирали. Структура спиральной модели представлена на рисунке 4 [12].

---

Рисунок 4 – Схема спиральной модели жизненного цикла разработки ПО

Рассмотрим этапы спиральной модели:

1. На этапе планирования осуществляется определение целей, вариантов и ограничений проекта.
2. На этапе анализа риска осуществляется анализ вариантов и распознавание/выбор риска проекта.
3. На этапе конструирования осуществляется разработка программного продукта следующего уровня.
4. На этапе оценивания происходит оценка текущих результатов разработки заказчиком.

На каждой итерации спирали разрабатываются все более полные версии АИС. На первом витке спирали происходит определение начальных целей, вариантов и ограничений, а также распознаются и анализируются риски. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, используемое в квадранте конструирования.

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

Если проект не приостанавливается, продолжается движение по спирали и с каждым шагом разработчики приближаются к более общей модели разрабатываемой системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием [6].

Представленные модели жизненного цикла программного продукта имеют отличия. Однако между ними есть одно сходство: все они содержат этап проектирования программного продукта. Значение этапа проектирования в процессе разработки программного продукта было описано в каскадной модели. Оно заключается в том, что стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше, чем на стадии кодирования. Поэтому важным становится тщательно и всесторонне описать систему на стадии проектирования.

---

1.3 Сущность структурных методов анализа и проектирования ЭИС

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

Характерными чертами структурных методов являются:

1. Разбиение системы на уровни с ограничением количества элементов.
2. Ограниченный контекст, который содержит только существенные детали каждого уровня.
3. Использование сторонних формальных правил записей.
4. Последовательность приближения к конечному результату.

Рассмотрим принципы структурного подхода:

• принцип «разделяй и властвуй» заключается в разбиении большой задачи на ряд подзадач;
• принцип «иерархического упорядочивания» заключается в подчинении подзадачи одной большой задаче;
• принцип абстрагирования заключается в выделении существенных аспектов системы и отвлечение от несущественных;
• принцип непротиворечивости заключается в том, что компоненты системы не должны противоречить друг другу;
• принцип структурирования данных заключается в упрощении системы для понимания.

В процессе реализации методов структурного анализа и проектирования используется нотация IDEF0, которая была разработана Дугласс Роузом в 1969 году. Нотация IDEF0 представляет собой топологию описания системы в целом в виде множества взаимозависимых действий или функций [8].

Нотация IDEF0 применяется в следующих случаях:

• В процессе проектирования ЭИС на логическом уровне;
• на ранних этапах разработки проекта до моделирования процесса «как есть».

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

Рассмотрим этапы построения модели IDEF0. Сначала необходимо определить назначение модели. Границы моделирования служат обозначением ширины охвата предметной области и глубины детализации и являются логическим продолжением уже определенного назначения модели. Следующим качеством указывается предполагаемая целевая аудитория, для нужд которой создается модель. Затем необходимо определить главную функцию системы. Функции изображаются на диаграммах как поименованные прямоугольники или функциональные блоки, которые носят название глаголов или отглагольных существительных. Любой блок может быть декомпозирован на составляющие его блоки [9].

---

На рисунке 5 представлена схема модели в нотации IDEF0.

Рисунок 5. Схема модели IDEF0

Рассмотрим компоненты модели:

• Вход - это нечто, что употребляется в ходе выполнения процесса.
• Управление - это ограничение инструкций, виляющих на ход выполнения процесса.
• Выход - результат выполнения процесса.
• Механизм исполнения - нечто, что используется для выполнения процесса, но не потребляется само по себе.

Для названия стрелок употребляются имена существительных. Стрелки могут представлять собой людей, места, вещи, идеи или события:

• Стрелки входа. Вход представляет собой сырье или информацию, потребляемую или преобразуемую в функциональных блоках, для производства выхода. Стрелки входа всегда направлены в правую сторону. Наличие входных стрелок на диаграмме не является обязательным.
• Стрелки управления отвечают, как и когда выполняется функциональный блок, и если он выполняется, какой выход получается в результате его выполнения. Каждый функциональный блок должен иметь как минимум одну стрелку управления. Стрелки управления всегда входят в функциональный блок управления.
• Стрелки выхода. Выход - это продукция или информацию, получаемая в результате работы функционального блока. Каждый блок должен иметь как минимум один выход.
• Стрелки механизма исполнения - являются ресурсом, который непосредственно исполняет моделируемое действие.

Также в моделях нотации IDEF0 применяются комбинированные стрелки действия:

• Стрелка выход-вход применяется, когда один из блоков должен полностью завершить работу перед началом работы другого блока.
• Выход – управление применяется, когда результат одной функции становится управлением следующей функции [5].

2. Сравнение инструментов структурных методов анализа и проектирования ЭИС

2.1 Обзор инструментальных средств структурного подхода

Рассмотрим инструментальные средства, которые применяются для создания моделей в рамках структурного подхода.

---

Программный продукт «BPwin process modeler» от компании «Computer Associates» представляет собой достаточно развитое средство моделирования, которое позволяет проводить анализ, документирование и улучшение бизнес процессов. С помощью этого программного продукта можно осуществить следующие действия:

• моделирование действий в процессах;
• определение порядка выполнения действий;
• определение необходимых ресурсов для выполнения действий.

Модели в CASE-средстве «BPwin» образуют структуру, которая необходима для того, чтобы сделать бизнес-процессы понятными, выявить управляющие события и порядок взаимодействия элементов процесса между собой.

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

• функциональное моделирование (IDEF0);
• моделирование потока работ (IDEF3);
• моделирование потока данных (DFD).

Для того, чтобы осуществить анализ работы организации в комплексе и построить большие модели в CASE-средстве «BPwin» предусмотрена детализация. Модели могут быть разбиты на группы. Каждая модель представляется на более низком уровне детализации с сохранением взаимосвязи между моделями и их элементами. Также каждую модель можно разделить на составляющие части, провести работу отдельно с каждой из них, а затем интегрировать обратно в единую модель.

Рассмотрим функциональные возможности программного продукта «BPwin»:

• Моделирование бизнес-процессов с помощью нескольких методологий. Моделирование процессов с помощью стандартов IDEF0, IDEF3 и DFD позволяет пользователям осуществить детальное и всестороннее описание бизнес процессов;
• Имитационное моделирование доступно с помощью средств экспорта моделей, это позволяет отследить изменение рассматриваемых бизнес-процессов в динамике;
• Документальное сопровождение моделей возможно с помощью встроенных средств. Они позволяют организовать связь моделей с документами по процессу и дают возможность взаимодействия с этими документами непосредственно из среды моделирования;
• Интеграция процессных моделей и моделей данных позволяет организовать единый репозиторий для моделей и составляющих эти модели объектов.

Модель бизнес-процесса, разработанная в CASE-средстве BPwin представлена на рисунке 6.

Рисунок 6. Модель процесса в CASE-средстве BPwin

Следующим CASE-средством является «Ramus Educational». Это программное обеспечение предназначено для описания бизнес-процессов предприятия с помощью нотаций IDEF0 и DFD с созданием систем классификации и кодирования. Ramus используется при реинжиниринге бизнес-процессов, внедрении процессного подхода к управлению построении систем менеджмента качества, построению систем управления знаниями и др.

---