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

 

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

1. Структурный анализ и структурное проектирование (Structured Analysis and Structured Design – SA/SD) является одной из самых извест-ных методик разработки информационных систем. В методике SA/SD подчеркивается, что система предоставляет своим пользователям одну или несколько функций – так называемый подход функциональной деком-позиции. SA/SD предлагает набор средств, таких как диаграммы потоков данных, диаграммы состояний-переходов, ER-диаграммы (на фазе анализа) и структурные схемы (на фазе проектирования).

2. Методика IDEF (Integrated computer aided manufacturing DEFinition) была разработана ВВС США в середине 70-х гг. На основе этой методики министерство обороны США создало федеральный стан-дарт обработки информации IDEF1X, который обеспечивает поддержку на нескольких уровнях посредством «модели бизнеса», «модели инфор-мационной системы» и «модели технологии». Моделирование бизнеса поддерживается ER-диаграммами для данных и диаграммами потоков дан-ных специального вида, что позволяет иерархически описывать функции системы.

3. Методика SADT (Structured Analisis and Design Technige) исполь-зует систему обозначений, похожую на диаграммы потоков данных IDEF, для описания функций и структур данных информационной системы на основе декомпозиции.

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

При моделировании (разработке) сложные информационные системы разбиваются на составные части, каждая из которых рассматривается отдельно от других. Такой прием, как известно, называется декомпозицией. Классический подход к разработке сложных систем представляет собой структурное проектирование, при котором осуществляется алгоритмическая декомпозиция системы по методу «сверху вниз».

Жизненный цикл разработки сложной системы в этом случае складывается из этапов анализа, проектирования, программирования, тестирования и сопровождения, которые выполняются последовательно. Такой метод, называемый каскадным, имеет следующие отличительные особенности:

- линейность выполнения этапов жизненного цикла разработки;

- четкое разделение данных и процессов их обработки;

- использование процедурных языков программирования.

Недостатки каскадного метода сразу бросаются в глаза. Главный из них – последовательное выполнение этапов. Например, программирование можно начать только по завершении анализа и проектирования. Это приводит к большим потерям времени, не позволяет быстро разрабатывать прототипы программной системы. Каскадный принцип не согласуется с итеративным характером разработки программной системы, поскольку на последних этапах может выясниться необходимость внесения изменений в решения, принятые на предыдущих этапах.

Для устранения этого недостатка Б. Боэм предложил спиральный подход. Он заключается в том, что разработка проекта ведется как бы по спирали, причем на каждом ее витке последовательно выполняются перечисленные этапы, на которых уточняется проект. Этот подход дополняет каскадный метод элементами интерактивности. Но и для него характерен ряд существенных недостатков, к числу которых можно отнести:

- трудоемкость внесения изменений;

- большой объем документации по проекту, затрудняющий про-граммирование;

- серьезные ограничения возможностей сборки системы из готовых компонентов;

- сложность переноса на другие платформы.

 

Дата: 2019-03-06, просмотров: 173.