Информационные
технологии
СРАВНИТЕЛЬНЫЙ АНАЛИЗ ПОДХОДОВ К
ПРОЕКТИРОВАНИЮ ИС
Рябышева И.В.
Новосибирский Государственный Технический
Университет (Новосибирск)
ВВЕДЕНИЕ В ПРОБЛЕМУ
На сегодняшний момент статистика успешности
ведения проектов автоматизации не утешительна, только 25 процентов проектов
заканчиваются успехом. В то же время, обязательным условием успешности
развития, работы и конкурентоспособности любого крупного предприятия
является наличие корпоративной информационной системы.
Высокая динамика изменения ситуации на рынке
предъявляет жесткие требования, как к функциональности ИС, так и к процессу
создания ИС.
Современные средства позволяют достаточно быстро
создавать (внедрять) ИС по готовым требованиям. Но очень часто оказывается, что
эти системы не удовлетворяют заказчиков. Основной причиной такого положения
является неправильное, неточное или неполное определение требований к ИС.
Проблема формирования требований к ИС остается до настоящего времени одной из
наиболее трудно формализуемых и наиболее дорогих и тяжелых для исправления в
случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ создания
ИС, когда эти требования должны быть выявлены и формализованы, в получении
конечного результата.
Поэтому для создания адекватной информационной
системы нужна технология, которая бы помогла сформировать требования к ИС,
спроектировать и разработать систему, отвечающую этим требованиям. Наличие
такой технологии (особенно при параллельном ведении большого количества
проектов) является решающим фактором успеха при создании ИС.
Поскольку этапы анализа и
проектирования вне
зависимости от модели ЖЦ[1] являются определяющими при построении корпоративных
информационных систем, в работе представлен анализ современных методик
анализа и проектирования на предмет их применимости в различных типах проектов.
Важность такого исследования обусловлена, с одной стороны, тем, что
разработчики обычно регламентируют свои средства (подходы, нотации), как
универсальные, а с другой, тем, что полноценная информация по методологии
использования подходов практически отсутствует.
Сравнительный анализ подходов проводился на основе
анализа сильных и слабых сторон подходов, а также опыта их практического
применения в проектах автоматизации.
ПОДХОДЫ
К ПРОЕКТИРОВАНИЮ ИС
В настоящее время используется большое
количество подходов, которые позволяют, так или иначе, создавать модели
бизнес-процессов предприятий. Как бы то ни было, их использование гарантирует
стандартизированный подход к описанию, позволяет накапливать опыт и
практические навыки и на протяжении длительного времени обеспечивать понимание
созданных моделей другими сотрудниками.
Важнейшими
из подходов являются структурный (функциональный),
объектно-ориентированный, отдельно выделяется методология ARIS.
1.
Структурный
(функциональный) подход
Сущность подхода
Сущность
структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении)
на автоматизируемые функции: система разбивается на функциональные подсистемы,
которые в свою очередь делятся на подфункции, подразделяемые на задачи и так
далее.
В качестве средств структурного анализа и
проектирования, наиболее распространенны следующие нотации:
·
SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF0) применяется для определения
требований (функций) для разработки системы, реализующей выделенные функции.
Для уже существующих - IDEF0 может быть использована для анализа функций,
выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность
иерархически упорядоченных и взаимосвязанных диаграмм (рис.1). Вершина этой
древовидной структуры, представляющая собой самое общее описание системы. После
описания системы в целом проводится разбиение ее на крупные фрагменты
(функциональная декомпозиция).
Рис.1 Модель в нотации IDEF0
·
DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD
обычно строятся для наглядного изображения текущей работы системы
документооборота организации. Как правило, диаграммы DFD используют в качестве
дополнения модели бизнес-процессов, выполненной в IDEF0.
·
IDEF3. Методология моделирования IDEF3
позволяет описать процессы, фокусируя внимание на течении этих процессов,
позволяет рассмотреть конкретный процесс с учетом последовательности
выполняемых операций.
·
ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология
описания данных (IDEF1X).
Выводы по практическому использованию
Общие выводы: применение
универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает
логическую целостность и полноту описания, необходимую для достижения точных и
непротиворечивых результатов на этапе анализа.
Выводы по диаграммам:
Наиболее существенное различие между разновидностями
структурного анализа заключается в их функциональности.
Модели SADT (IDEF0) наиболее удобны при построении функциональных
моделей. Они наглядно отражают функциональную структуру объекта: производимые
действия, связи между этими действиями. Таким образом, четко прослеживается
логика и взаимодействие процессов организации. Главным достоинством
нотации является возможность получить полную информацию о каждой работе,
благодаря ее жестко регламентированной структуре. С ее помощью можно
выявить все недостатки, касающиеся как самого процесса, так и то, с помощью
чего он реализуется: дублирование функций, отсутствие механизмов,
регламентирующих данный процесс, отсутствие контрольных переходов и т.д.
DFD позволяет проанализировать информационное
пространство системы и используется для описания документооборота и
обработки информации. Поэтому диаграммы DFD применяют в качестве
дополнения модели бизнес-процессов, выполненной в IDEF0.
IDEF3 хорошо приспособлен для
сбора данных, требующихся для проведения анализа системы с точки зрения
рассогласования/согласования процессов во времени.
Нельзя говорить о достоинствах
и недостатках отдельных нотаций. Возможны ситуации, при
которых анализ IDEF0 не обнаружил недостатков в деятельности организации
с точки зрения технологического или производственного процесса, однако это не
является гарантией отсутствия ошибок. Поэтому в следующем этапе анализа
необходимо перейти к исследованию информационных потоков с помощью DFD и затем объединить эти пространства с
помощью последней нотации - IDEF3.
Что
касается IDEF1X, наряду со многими достоинствами, существенным недостатком является
невозможность адекватно и полно описать предметную область. Поэтому, код
клиентского приложения, генерируемый в дальнейшем на основе информации о
структуре БД, не позволяет построить эффективное приложение со сложной бизнес –
логикой. Это вызвано тем, что данные для хранения в БД необходимо представить в
таблицах, к структуре которой предъявляются требования нормализации.
2.
Объектно-ориентированный
подход
Сущность подхода
Принципиальное различие между структурным и
объектно-ориентированным (ОО) подходом заключается в способе декомпозиции
системы (рис.2). ОО подход использует объектную декомпозицию, при этом
статическая структура системы описывается в терминах объектов и связей между
ними, а поведение системы описывается в терминах обмена сообщений между
объектами
Рис. 2 Сравнительный
анализ объектно-ориентированной и функционально-ориентированной декомпозиций
В 90-е годы появилось большое количество различных
методологий с собственными наборами нотаций. Самые популярные – ОМТ (по Рамбо),
Booch (по Бучу) и OOSE (по Джекобсону).
UML (Unified Modeling Language) –стандартная нотация визуального моделирования
программных систем, принятая консорциумом Object Managing Group (OMG) в 1997г.
UML предоставляет средства для создания визуальных
моделей, которые единообразно понимаются всеми разработчиками, вовлеченными в
проект, и являются средством коммуникации в рамках проекта. Диаграмма
в UML - это графическое
представление набора элементов. Диаграммы рисуют для визуализации системы с
разных точек зрения. При визуальном моделировании на UML используются восемь
видов диаграмм, каждая из которых может содержать элементы определенного типа.
Выводы по практическому
использованию
Общие выводы: в настоящее время объектный подход стал особенно
популярен и характеризуется разработчиками как универсальное средство
проектирования. Однако методология применения UML на этапах анализа и проектирования описана
достаточно слабо (т.е. можно найти описание диаграмм, но логика их
использования регламентируется слабо), поэтому рано говорить о UML как о действительно полноценной замене
всем другим подходам.
Выводы по диаграммам:
В языке UML для этапов анализа предназначены следующие виды
диаграмм:
·
use case diagram (диаграммы прецедентов);
·
activity
diagram (диаграммы описаний технологий, процессов, функций);
·
sequence
diagram (диаграммы последовательностей действий);
·
collaboration diagram (диаграммы взаимодействий).
Проанализируем их функциональную пригодность для этих целей.
Use case
diagram – рекламируется
разработчиками как альтернативный инструмент анализа вместо стандартных
структурных нотаций. Однако, описывая функции системы (прецеденты)
и их исполнителей (актеры), не позволяет проанализировать существующую модель
бизнес-процессов и выявить ее недостатки, также к другим минусам можно отнести
недостаточную степень регламентации описания функции (невозможно проследить
механизмы и управление процессом) и невозможность проследить их логику
взаимодействия.
Плюсом диаграммы является ее простота, наглядность
и читабельность неспециалистами. Фактически является некоторым аналогом
нотации IDEF0 (прецедент –
работа, актер – один из механизмов).
Activity diagram – представляют собой схемы потоков
управления в системе от действия к действию, а также параллельные и
альтернативные потоки, с является неким аналогом нотаций IDEF0 и IDEF3. Т.е. понятие «перекресток» заменяется
элементами «линия синхронизации» и «выбор», а «работа» - «действием». Диаграмма
не очень приспособлена для отображения сложной логики, но возможно ее
использование в качестве доступного для понимания аналога заказчику.
Дуги Use Case и
Activity диаграмм не имеют смысловых типов, которые указаны для дуг IDEF0.
Использование данных диаграмм требует установления дополнительных
синтаксических соглашений, т.к. UML нежесткий язык и
допускает построение синтаксически корректных Activity-диаграмм, не имеющих
смысла или не поддающихся объяснению. Например, чтобы определить тип входящей
стрелки, различать документы, можно их выделять цветом, использовать пунктирные
и сплошные стрелки и т.п.
Sequence diagram – иллюстрирует события, инициированные в
системе исполнителями. Если изобразить диаграмму на абстрактном уровне в
терминах предметной области, а систему рассматриваются как "черный
ящик", то она является достаточно удобным инструментом для построения
общей информационной модели. Т.е. входное сообщение является входной
информацией в терминах IDEF0,
а отклик системы (объекта) – выходной информацией.
Является удобной диаграммой при переходе на
физический уровень, как при проектировании графического интерфейса, так и при
переходе к классам и физической реализации (сообщения становятся методами
соответствующего класса).
Для этапа проектирования однозначно определены:
·
State
diagram (диаграммы состояний);
·
Class
diagram (диаграммы классов).
·
Component diagram (диаграммы компонент);
·
Deployment diagram (диаграммы развертывания).
Основной диаграммой UML является Class diagram, которая является основой
для генерации кода и основной целью проектирования. Является визуальным
представлением идеи объектно-ориентированного проектирования и программирования.
Действительно плюсом является легкость исправления проектного решения в
соответствии с изменившейся бизнес-логикой, т.к. в динамически построенной
модели нет необходимости полной перестройки, присущей нотациям структурного
подхода. В частности, изменение отдельных классов и связей между ними не
затронет общей концепции модели.
3.
Методология
ARIS
Сущность подхода
Методология ARIS определяет принципы моделирования
различных аспектов деятельности организаций, основывается на концепции интеграции,
предлагающей целостный взгляд на бизнес-процессы, и представляет собой
множество различных методологий, интегрированных в рамках единого системного
подхода. Графически такой подход представлен на рис. 3.
Рис. 3 Взаимосвязь
видов моделей ARIS (здание ARIS)
Методология ARIS включает
большое количество методов моделирования, в том числе известных как диаграммы
Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling
Technique), BSC (Balanced Scorecard) и т.п.
К преимуществам
методологии ARIS разработчики относят следующие:
·
возможность рассматривать
объект с разных точек зрения: при анализе деятельности каждому аспекту можно
уделять достаточное внимание и только после детального изучения всех
аспектов можно перейти к построению интегрированной модели, отражающей все
существующие связи между подсистемами организации;
·
богатство методов,
позволяет моделировать широкий спектр систем;
·
все модели и объекты
создаются и хранятся в единой базе проекта, что обеспечивает построение
интегрированной и целостной модели предметной области.
Выводы по практическому использованию
1. Часто у аналитиков знакомящихся с
методологией ARIS возникает чувство, что ARIS может все, она решает все
проблемы. Это ошибочное мнение. Методология ARIS решает совершенно конкретный
круг задач[2].
Если потребности сильно отличаются от возможностей ARIS (например, сбор
требований), то подойдет более специализированное и дешевое решение. ARIS в
значительно большей степени предназначен для целей управленческого
консалтинга и последующей поддержки решений. Использование ARIS в рамках
проекта автоматизации противоречит целям, положенным в основу этой методологии
ее создателем.
2. Действительно, если в проекте
автоматизации этап анализа вырастает в отдельный консалтинговый этап
(например, организации современных схемы управления на основе процессного
подхода, в котором цели деятельности определяет совокупность процессов для
их достижения, а процессы формируют требования к ресурсам
и оргструктуре), то подобный подход является необходимым. А модель, ограничивающаяся
описанием бизнес-процессов, будет неполной и не обеспечит
потребностей управления.
3. Стоит достаточно осторожно подходить к
использованию ARIS. В настоящее время некоторые фирмы используют ARIS при
проектировании ИС, но, как правило, используют 1-2 модели, что противоречит
методологии. Он нацелен именно на рынок анализа бизнеса и предназначен для
больших компаний, внутри которых существуют свои собственные
аналитические подразделения.
4. В случае принятия решения о качественной
необходимости использования методологии необходимо иметь ввиду, что ARIS нельзя
отнести к интуитивно понятным, она требует времени на изучение, на
осмысленное применение (вопрос хотя бы в том, что методология содержит больше
100 моделей!). Для успешного применения должны быть разработаны внутренние
соглашения о моделировании и документировании
СРАВНИТЕЛЬНЫЙ
АНАЛИЗ ПОДХОДОВ К ПРОЕКТИРОВАНИЮ ИС
Очевидно, что выбор
методов определяется целями проекта и в значительной мере влияет на весь его дальнейший
ход. Рациональный выбор возможен при понимании нескольких аспектов:
1. Целей проекта;
2. Требований к информации необходимой для
анализа и принятия решений в рамках конкретного проекта;
3. Возможностей подхода с учетом
требований п. 2;
4. Особенностей разрабатываемой/внедряемой
информационной системы.
Например, между сторонниками структурного и ОО-подходов в настоящее время
ведутся ожесточенные споры, как и в самом начале эры ОО-подхода. При этом не
существует решающих аргументов, доказывающих несостоятельность того или иного
из методов.
Сравнение
подходов должно дать ответы на следующие вопросы:
1.
На сколько сам подход и его
нотации применимы для того или иного этапа проектирования ИС.
2.
Что является критерием для
выбора подхода в случае, когда возможно применение более одного подхода (какой
подход применить лучше).
Т.к. каждый подход регламентируется
разработчиками как методология, подходящая для анализа и проектирования,
то имеет смысл подробнее остановиться на нотациях. В Таблице 1 представлено
сравнение нотация применяемых для анализа ИС.
Таблица 1
Сравнительный анализ нотаций eEPC, IDEF, Sequence и Activity diagram
|
№ |
Критерии сравнения |
eEPC |
IDEF0 |
IDEF3 |
Sequence diagram |
Activity diagram |
|
1 |
Принцип построения диаграммы |
Последовательность выполнения |
Принцип иерархической упорядоченности |
Последовательность выполнения |
Последовательность выполнения |
Последовательность выполнения |
|
2 |
Описание процедуры процесса |
Объект на диаграмме |
Объект на диаграмме |
Объект на диаграмме |
Объект на диаграмме |
Объект на диаграмме |
|
3 |
Входящий документ |
Используется отдельный объект для описания («документ») |
Стрелка слева, стрелка сверху |
Нет (может быть отражен привязкой объекта) |
В зависимости от принятого соглашения может быть объектом или стрелкой |
Может быть объектом или стрелкой |
|
4 |
Входящая информация |
Используется объект для описания («кластер», «технический термин») |
Стрелка слева, стрелка сверху |
Нет (может быть отражен привязкой объекта) |
Может быть объектом или стрелкой |
Может быть объектом или стрелкой |
|
5 |
Исходящий документ, информация |
Используется объект для описания («документ», («кластер») |
Стрелка справа |
Нет (может быть отражен привязкой объекта) |
Может быть объектом или стрелкой |
Может быть объектом или стрелкой |
|
7 |
Исполнитель процедуры |
Используется объект для описания («позиция», «организационная единица») |
Стрелка снизу |
Нет (может быть отражен в модели только привязкой объекта-комментария) |
Используется отдельный объект «Actor» |
Разграничение зон на диаграмме |
|
8 |
Используемое оборудование |
Используется отдельный объект для описания |
Стрелка снизу |
Нет (может быть отражен привязкой объекта) |
- |
- |
|
9 |
Управление процедурой |
Нет. Может быть отражено только последовательностью выполнения |
Стрелка сверху |
Только логика процесса |
Только логика процесса |
Только логика процесса |
|
10 |
Контроль выполнения процедуры |
Нет. Может быть отражен указанием входящих документов |
Стрелка сверху |
Нет |
Нет. Может быть отражен указанием входящих документов |
Нет. Может быть отражен указанием документов |
|
11 |
Обратная связь по управлению/контролю |
Нет. Может быть отражена последовательностью выполнения |
Стрелка сверху |
Нет |
Нет. Может быть отражен указанием входящих документов |
Нет. Может быть отражен указанием входящих документов |
|
12 |
Наглядность модели |
Модель наглядна и есть возможность использования визуальных образов с последующей конвертацией |
Модель нечитабельна неспециалистами |
Модель нечитабельна неспециалистами |
Модель наглядна, но несколько громоздка |
Модель очень наглядна |
Функциональные
возможности подходов можно корректно сравнивать только по отношению к
определенному кругу задач. В данном исследовании рассматривается задача
формирования моделей бизнес-процессов предприятия при анализе и проектировании.
Каждый из рассматриваемых подходов имеет свои преимущества и недостатки. В
зависимости от решаемых задач эти преимущества могут как усиливаться, так и
наоборот, ослабевать. Например, отсутствие четких соглашений по моделированию управляющих
воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих
на поставленные вопросы, в то время как нотация IDEF0 позволяет решить эту
задачу (хотя данная задача решается довольно редко). С другой стороны,
процедура, выполняемая одним сотрудником, может быть более адекватно описана
при помощи eEPC ARIS, чем при помощи IDEF0 или IDEF3.
Следует подчеркнуть,
что модель - не самоцель, это лишь инструмент, именно понимание того, что
нужно описывать и какие аспекты функционирования реальной системы при этом
отражать, определяет успех проекта по моделированию бизнес-процессов.
Сравнение структурного, объектно-ориентированного
подходов и методологии ARIS
приведено на рис. 4 - 6.
Рис.4 Анализ структурного подхода
Рис.5 Анализ объектно-ориентированного
подхода
Рис.6 Анализ методологии ARIS
ВЫВОДЫ
Позиционирование подходов можно провести по
отношению к решению задачи моделирования бизнес-процессов на этапе
анализа и проектирования (в соответствии с проведенным выше анализом)
следующим образом (табл. 2).
Таблица 2
Позиционирование подходов относительно типов проектов
|
Подход
Тип проекта [3] |
Структурный подход |
Объектно-ориентированный подход |
Методология ARIS |
|
Типовое проектирование |
|
▼ ∆ |
|
|
Оригинальное проектирование |
▼ |
∆ |
▼ ∆ |
|
Смешанное проектирование |
▼ |
▼ ∆ |
▼ ∆ |
▼ - анализ
∆ -
проектирование
Типовое проектирование – этап анализа сводится к сбору
информации и утверждении ее полноты и адекватности у Заказчика для
настройки системы, для этого замечательно подходят средства
объектно-ориентированного подхода. Благодаря наглядности моделей сотрудники
Заказчика понимают модели и могут участвовать в их обсуждении (добиться таких
результатов при использование нотация структурного подхода практически
невозможно). Выбор обуславливается еще и тем, что легко перейти к этапу
проектирования и инструмент будет единый. Проектирование
- непосредственно проработка настроек системы, т.е. реализация бизнес-процессов
Заказчика в рамках внедряемой системы. Использование структурных нотаций или
моделей АРИС нецелесообразно и избыточно. Примером такого проекта может служить
внедрение системы «Галактика» или «1С».
Оригинальное проектирование – этап анализа имеет
классический вид, необходимо качественное и полное построение бизнес-процессов
организации с проведением их реинжиниринга. Для правильного и точного выявления
и формализации требований хорошо подходят нотации структурного подхода и ARIS. Выбор будет обуславливаться:
1.
Потребностями и целями
проекта (либо это комплексное обследование и моделирование с масштабными
преобразованиями, либо качественный сбор информации и небольшие изменения),
аспектами анализа и требованиями к информации;
2.
Предпочтениями аналитиков и
наличием инструментальных средств.
Главной целью формирования
моделей ИС является обеспечение перехода от моделей описания организации к
системе моделей, описывающих конкретные компоненты проекта, такие как
приложения, базы данных, при котором обеспечивается отображение задач
организации в функции и компоненты ИС (этап проектирования ИС). Этап
проектирования в обоих случаях основан на использовании языка UML и наиболее удачной методики Лармана.
Смешанное
проектирование – новые
модули разрабатываются по схеме оригинального проектирования, в
остальном - типового проектирования.
Проведенный
анализ сильных и слабых сторон структурного, объектно-ориентированного подходов
и методологии ARIS является
основой технологии проектирования ИС с использованием CASE – технологий.
Предложенная
схема использования подходов к проектированию ИС обеспечивает снижение
сложности процесса создания ИС, существенно повышает эффективность проекта и
помогает избежать ненужных, избыточных действий благодаря оптимальному выбору
инструментов в зависимости от типа проекта.
ЛИТЕРАТУРА
1.
Буч Г., Рамбо Д., Джекобсон
А. Язык UML: Руководство
пользователя: Пер. с англ. – М.: ДМК, 2000. – 432 с.
2.
Вендров А.М. Проектирование
программного обеспечения экономических информационных систем: Учебник. – М.:
Финансы и статистика, 2000. – 352 с.
3.
Калянов Г.Н. Теория и
практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнеса». – М.:
СИНТЕГ, 2000, 212 с.
4.
Каменнова М., Громов А.,
Ферапонтов М., Шматалюк А. Моделирование бизнеса. - М.: Весть-Метатехнология,
2001
5.
Кватрани Т. Rational Rose 2000 и UML. Визуальное
моделирование: Пер. с англ. – М.: ДМК Пресс, 2001. – 176 с.
6.
Ларман К. Применение UML и шаблонов проектирования. Введение в
объектно – ориентированный анализ и проектирование :Пер. с англ. – М.:
Издательский дом «Вильямс», 2001. -496 с.
7.
Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001 – 304
с.
8.
В. Репин, С. Маклаков ARIS
Toolset/BPwin: выбор за аналитиком. - http://www.compress.ru/Temp/2878/index.htm
9.
С.Д.Паронджанов, Компания Аргуссофт Методология
создания корпоративных ИС. - http://www.neic.nsk.su/rus/tech/cit/kbd96/43.htm
10.
Смирнова Г.Н., Сорокин А.А.,
Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник.-М.:
Финансы и статистика, 2002.-512 с.
11.
Шеер А.-В. Бизнес-процессы. Основные понятия.
Теория. Методы. — М.: Весть-МетаТехнология, 1999.
12.
Хотяшов Э. Н. Основы
проектирования систем машинной обработки данных. – М.: ФиС, 1981.
[1] Совокупность стадий и этапов,
которые проходит ИС в своем развитии от момента принятия решения о создании
системы до момента прекращения функционирования системы, называется жизненным
циклом ИС.