PosobieASOIU0_5

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

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

Методология RAD хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если разрабатывается типовая система, не являющаяся законченным продуктом, а представляющая комплекс типовых компонент, то на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Требования к компонентам информационной системы могут отражать:

•централизованное сопровождение;

•адаптируемость к программно-техническим платформам, СУБД, средствам телекоммуникации;

•организационно - экономические особенности объектов внедрения;

•интегрируемость с существующими разработками.

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

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

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

Косновным принципам методологии RAD относятся:

•разработка приложений итерациями;

•необязательность полного завершения работ на каждом из этапов жизненного цикла;

•обязательное вовлечение пользователей в процесс разработки информационной системы;

•необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

•необходимое использование генераторов кода;

•использование прототипирования, позволяющее выяснить и удовлетворить потребности конечного пользователя;

•тестирование и развитие проекта, осуществляемые одновременно с разработкой;

•ведение разработки немногочисленной, хорошо управляемой командой профессионалов;

•грамотное руководство разработкой системы, четкое планирование

иконтроль выполнения работ.

2.6Унифицированный процесс Rational

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

1.Фаза начала проекта (Inception). Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта. На этой фазе определяются основные цели проекта, руководитель проекта и бюджет проекта, основные средства его выполнения – технологии, инструменты, ключевой персонал, а также происходит, возможно, апробация выбранных техно-

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

2.Фаза проработки (Elaboration). Основная цель этой фазы – на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы.

3.Фаза построения (Construction). Основная цель этой фазы – детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.

4.Фаза передачи (Transition). Цель этой фазы – сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгон-

ка мелких деталей под нужды пользователей.

Кроме того, RUP определяет следующие виды деятельности, которые в разных комбинациях и с разной интенсивностью, выполняются на разных фазах:

1.Моделирование предметной области (бизнес-моделирование, Business Modeling). Цели этой деятельности – понять бизнесконтекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают его одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельности (представляющий бизнесоперации и бизнес-процессы).

2.Определение требований (Requirements). Цели – понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем. Требования принято фиксировать в виде модели вариантов использования (use cases).

3.Анализ и проектирование (Analysis and Design). Цели – выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться проектная модель, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий ме-

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

4.Реализация (Implementation). Цели – определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое

5.Тестирование (Test). Цели – найти и описать дефекты системы (проявления ее недостаточного качества), оценить ее качество в целом, оценить выполнение гипотез, лежащих в основе проектирования, оценить степень соответствия системы требованиям

6.Развертывание (Deployment). Цели – развернуть систему в ее рабочем окружении и оценить ее работоспособность

7.Управление конфигурациями и изменениями (Configuration and Change Management). Цели – определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений

8.Управление проектом (Project Management). Цели – планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта

9.Управление средой проекта (Environment). Цели – подстройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте

Первые пять деятельностей считаются рабочими, остальные —

поддерживающими. Распределение объемов работ в ходе проекта выглядит примерно так.

Основные техники, используемые в RUP таковы

•выработка концепции проекта (project vision) в самом его начале для четкой постановки задач;

•управление по плану;

•снижение рисков и отслеживание их последствий, работа по преодолению рисков должна начинаться как можно раньше;

•тщательное экономическое обоснование всех действий, делается только то, что нужно заказчику;

•выявление требований и их фиксация в виде вариантов использования (use cases);

•формирование базовой архитектуры как можно раньше;

•использование компонентной архитектуры;

•прототипирование, инкрементная разработка и тестирование;

•регулярные оценки текущего состояния;

•управление изменениями, постоянная отработка изменений извне проекта;

•создание продукта, работоспособного в реальном окружении;

•нацеленность на качество;

•адаптация процесса под нужды проекта.

2.7 Экстремальное программирование

Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх» [5]. Этот подход является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, Метод разработки динамичных систем), Feature-Driven Development (Разработка,

управляемая характеристиками результата) и пр.

Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки.

•люди их общение более важны, чем процессы и инструменты;

•работающая программа более важна, чем исчерпывающая документация;

•сотрудничество с заказчиком более важно, чем обсуждение деталей контракта;

•отработка изменений более важна, чем следование планам.

Тем не менее, XP имеет свою схему процесса разработки (хотя широко используемое понимание «процесса разработки» противоречит «живости» разработки).

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

1.Живое планирование (planning game) Его задача как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в первую очередь, бизнес приоритетов заказчика и, во вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.

2.Частая смена версий (small releases). Самая первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.

3.Метафора (metaphor) системы. Метафора в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.

4.Простые проектные решения (simple design). В каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Не надо добавлять функции «заранее» — только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

5.Разработка на основе тестирования (test-driven development). Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.

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

7.Программирование парами (pair programming). Весь код пишется двумя программистами на одном компьютере. Объединение в пары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытается наилучшим способом решить текущую задачу. Второй программист обдумывает последствия, новые тесты, менее прямые, но более гибкие возможности решения.

8.Коллективное владение кодом (collective ownership). В любой момент любой член команды может изменить любую часть кода, но он же несет ответственность за эти изменения.

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

10.40-часовая рабочая неделя. Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверх-

урочная работа 2 недели подряд – это истощает программистов и делает их работу значительно менее продуктивной.

11.Включение заказчика в команду (on-site customer). В составе команды разработчиков постоянно находится представитель заказчика, который доступен в течении всего рабочего дня и способен отвечать на все вопросы о системе.

12.Использование кода как средства коммуникации. Код рассматривается как важнейшее средство общения внутри команды. Ясность кода – один из основных приоритетов. Следование стандартам кодирования, обеспечивающим такую ясность, обязательно. Такие стандарты, помимо ясности кода, должны обеспечивать минимальность выражений (запрет на дублирование кода и информации) и должны быть приняты всеми членами команды.

13.Открытое рабочее пространство (open workspace). Команда размещается в одном, достаточно просторном помещении, для упрощения коммуникации и возможности проведения коллективных обсуждений при планировании и принятии важных технических решений.

14.Изменение правил по необходимости (just rules). Каждый член команды должен принять перечисленные правила, но при воз-

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

Как видно, XP рассчитано на использование в рамках небольших команд (не более 10 программистов), так как больший размер команды разрушает легкость коммуникации.

3Технологииреинжинирингабизнес-процессов

3.1CASE технологии

CASE-технология (Computer Aided Software Engineering)

представляет собой методологию проектирования информационных систем, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, производить ее анализ на всех этапах разработки и сопровождения информационных систем и разрабатывать приложения в соответствии с информационными требованиями пользователей [10, 11, 20, 22, 45]. Большинство существующих CASE-средств основано на методологиях структурного и объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями

системы, динамики поведения системы и архитектуры программных средств.

CASE-средства – это программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки АСОИУ.

При использовании CASE-технологий необходимо учитывать следующее:

•CASE-средства не обязательно дают немедленный эффект;

•реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

•понимание ограниченности существующих возможностей и способность принять новую технологию;

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

•четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

Для того, чтобы принять взвешенное решение относительно

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

•достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки программного обеспечения;

•внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи.

Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;

•отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

•CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;

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

•негативное отношение персонала к внедрению новой CASEтехнологии может быть главной причиной провала проекта.

Пользователи CASE-средств должны быть готовы к

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

Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASEсредств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

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

•положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

•приемлемый уровень отдачи от инвестиций в CASE-средства.

3.2Методология структурного анализа и проектирования

SADT

SADT (Structured Analysis and Design Technique, методология Росса) – методология структурного анализа и проектирования,

основанная на графическом представлении системы разными языковыми средствами. Основные положения данной методологии зафиксированы в стандарте IDEF0 [10, 17, 30-33].

В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Описание системы с помощью IDEF0 называется функциональной моделью.

Модель (model) – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов.

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

Под субъектом понимается сама система, при этом необходимо точно определить, что входит в систему, а что лежит за ее пределами.

Точка зрения (viewpoint) – указание на должностное лицо, с позиции которого разрабатывается модель. У модели может быть только одна точка зрения. Изменение точки зрения приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на этот объект.

Формулировка цели (purpose) выражает причину создания модели, то есть содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру.

Таким образом, модель IDEF0 представляет собой графическое описание системы, разработанное с определенной целью и с выбранной точки зрения.

Определение области моделирования является основой построения модели. Область моделирования (scope) описывает круг функций, которые включаются в модель. При формулировании области необходимо учитывать два компонента: широту и глубину. Широта подразумевает определение границ модели, а глубина определяет, на каком уровне детализации модель является завершенной.

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

Модель может содержать 4 типа диаграмм: контекстную диаграмму, диаграммы декомпозиции, диаграммы дерева узлов, диаграммы только для экспозиции (For Exposition Only, FEO).

Контекстная диаграмма (context diagram) является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

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

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

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

Каждая IDEF0 диаграмма декомпозиции содержит работы и стрелки.

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

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

Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелка (arrow) – направленная линия, состоящая из одного или нескольких сегментов, которая моделирует канал, передающий данные от источника (начальная точка стрелки) к потребителю (конечная точка с «наконечником»). В IDEF0 различают пять типов стрелок:

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

•выход (output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Выходные стрелки рисуются как исходящая из правой грани работы;

•управление (control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелки управления рисуются как входящие в верхнюю грань работы;

•механизм (mechanism) – ресурсы, которые выполняют работу. Стрелки механизма рисуются как входящие в нижнюю грань работы;

•вызов (call) – специальная стрелка, указывающая на другую модель. Стрелка вызова рисуется как исходящая из нижней грани работы.

Стрелка обычно представляет набор объектов. Поэтому они

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

Граничные стрелки служат для описания взаимодействия системы с окружающим миром. Идентификация граничных стрелок осуществляется с помощью ICOM-кодов. Коды ICOM содержат префикс, соответствующий типу стрелки (Input, Control, Output, Mechanism).

Внутренние стрелки используются для связи работ между собой. В IDEF0 требуется только пять типов взаимосвязей между блоками с помощью стрелок для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выходмеханизм (см. рис. 3.1).

Рис. 3.1. Типы взаимосвязи между работами

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

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

2.Процесс (бизнес-процесс) – совокупность последовательно или/и параллельно выполняемых операций, преобразующих информационный поток с изменением его свойств. Процесс протекает в соответствии с управляющими директивами, вырабатываемыми на основе целей деятельности.

3.Операция – совокупность последовательно или/и параллельно выполняемых действий, преобразующих объекты с изменением их свойств.

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

5.Субдеятельность – совокупность нескольких процессов в составе деятельности, объединенных некоторой частной целью.

6.Подпроцесс – группа операций в составе процесса, объединенных

технологически или организационно.

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

Проектирование по методологии SADT может быть произведено с помощью CASE-средства AllFusion Process Modeler (Computer Associates), поддерживающего нотации IDEF0, IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram).

3.3 Описание информационных потоков. DFD

Диаграммы потоков данных (Data flow diagramming, DFD)

описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией как внутри системы между бизнесфункциями, так и системы в целом с внешней информационной средой. DFD позволяет построить наглядную модель системы документооборота – описать механизмы передачи и обработки информации [10, 30-33].

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

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

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

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

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

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов

(external entities)

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

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

Хранилище данных - это место накопления информации внутри системы. Хранилища данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между работами. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Хранилище данных может содержать информацию длительного хранения или временную информацию. Имя хранилища должно идентифицировать его содержимое. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных. В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В

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

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И, наконец, строится физическая модель, на основе которой должна быть построена новая система.

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

Затем модель окружения (environment model) описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один прямоугольник работы, изображающий систему в целом, и внешние сущности, с которыми система взаимодействует.

Наконец, модель поведения (behavior model) показывает, как система обрабатывает события. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник изображает каждое событие из модели окружения. Хранилища могут быть добавлены для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения.

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

В данном пособии больший акцент делается на методологии IDEF0, однако стоит также отметить возможность дополнения функциональной модели диаграммами DFD

3.4 Описание бизнес-процессов. IDEF3

Методология моделирования IDEF3 (workflow diagramming)

предназначена для описания логики взаимодействия информационных потоков. Диаграммы IDEF3 позволяют сфокусировать внимание на течении процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов. [10, 30-33].

Диаграммы Workflow могут быть использованы при моделировании бизнес-процессов для анализа завершенности процедур обработки информации. При этом особе внимание уделяется последовательности выполнение процессов.

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

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

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

•определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий процесса;

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

•содействовать принятию оптимальных решений при реорганизации процессов;

•разрабатывать имитационные модели процессов, по принципу «КАК БУДЕТ, ЕСЛИ...».

IDEF3 предполагает построение двух типов моделей:

•модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует система (Process Flow Description Diagrams, PFDD);

•модель может показывать «сеть переходных состояний объекта», описывая последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс

(Object State Transition Network, OSTN).

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

Диаграмма является основной единицей описания в IDEF3. Диаграммы должны наглядно и достоверно отображать информацию о бизнес-процессах.

Единицы работы - Unit of Work (UOW), также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы. Каждая UOW должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов и фактов, связанных с работой, ограничений, накладываемых на работу, и дополнительное описание работы. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не должен вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

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

•связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией;

•связь отношения (Relational) – показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией;

•поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект

производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.

Связь предшествования (старшая связь) показывает, что работаисточник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект.

Отношение показывает, что стрелка является альтернативой предшествованию или потоку объектов в смысле задания последовательности выполнения работ – работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (см. рис. 3.2).

Рис. 3.2. Временная диаграмма последовательности выполнения работ

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

•перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса;

•перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.

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

Таблица 3.1 – Типы перекрестков

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

1.Каждому перекрестку для слияния должен предшествовать перекресток для разветвления;

2.Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ»;

3.Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ»;