Назовите нестандартизированную ые концепцию и моделирования бизнес процессов

Метод SADT (S tructured A nalysis and D esign T echnique) — структурный анализ и техническое проектирование разработан Дугласом Россом в 1973 г. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др.

Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEF0 (Icam DEFinition) — подмножества SADT. IDEF0 был утвержден в качестве федерального стандарта США, его подробные спецификации можно найти на сайте http://www.idef.com. Семейство стандартов IDEF мы рассмотрим боле подробно в следующем разделе. Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Семь нотаций моделирования бизнес-процессов

Основные элементы этого метода основываются на следующих концепциях.

1. Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения».

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

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

3. Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель.

Метод SADTможет использоваться для моделирования самых разнообразных систем и определения требований и функций с последующей разработкой информационной системы, удовлетворяющей этим требованиям и реализующей эти функции. В существующих системах метод SADT может применяться для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются. Здесь мы рассмотрим три технологии моделирования SADT: метод функционального моделирования IDEF0, метод описания бизнес-процессов IDEF3 и метод построения диаграмм потоков данных (DFD). Все описанные подходы входят в семейство стандартов IDEF (Integrated DEFinition), полный перечень и назначение которых приведены в следующем разделе.

Семейство стандартов IDEF во многом обязано появившейся в 80-х гг. технологии автоматизированной поддержки разработки информационных систем CASE (Computer Aided Software Engineering). В последнее время CASE-технологии приобретают все большее распространение для моделирования и анализа деятельности предприятий, предоставляя богатый набор возможностей для оптимизации или, в терминах CASE, реинжиниринга технологических процедур, выполняемых этими предприятиями — бизнес-процессов. Значительная часть SADT была принята ВВС США как часть их программы интегрированной компьютерной поддержки производства (Integrated Computer-Aided Manufacturing — ICAM). Эта технология, переименованная в IDEF0, довольно быстро стала стандартом технологии моделирования деятельности в министерстве обороны США.

Визуальное моделирование бизнес-процессов

В 1993 г. группа пользователей IDEF совместно с Национальным институтом стандартов и технологии предприняли попытку создания документированного стандарта для IDEF0, который мог бы использоваться как военными, так и гражданскими департаментами правительства США. Этот стандарт был опубликован как федеральный стандарт обработки информации (Federal Information Processing Standard — FIPS).

Несколько независимо, но с использованием аналогичных подходов технология DFD (Data Flow Diagrams — диаграммы потоков данных) завоевала популярность для структурной разработки, а впоследствии и структурного анализа проектов построения информационных систем. Диаграммы потоков данных во многом аналогичны моделям IDEF0 и могут быть использованы при проектировании информационных систем, например, после разработки моделей анализа IDEF0. Стандарт IDEF3 был специально разработан для закрытого проекта ВВС США. Это технология получения описания деталей процесса от экспертов в предметной области и разработки таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, эта технология приобрела широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0.

Семейство стандартов IDEF

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

Методики и модели концептуального проектирования IDEF (I ntegrated DEF inition) разработаны в США по программе Integrated Computer-Aided Manufacturing. В настоящее время имеются методики функционального, информационного и поведенческого моделирования и проектирования, в которые входят следующие IDEF-модели.

IDEF0 Функциональное моделирование

IDEF0 реализует методику функционального моделирования сложных систем. Наиболее известной реализацией IDEF0 является методология SADT (Structured Analysis and Design Technique), предложенная в 1973 г. Д. Россом и впоследствии ставшая основой стандарта IDEF0. Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, программное обеспечение.

IDEF1 и IDEF IX Информационное моделирование

IDEF1X и IDEF1 реализуют методики информационного проектирования баз данных. В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм «сущность-связь» (ERD — Entity-Relations Diagrams).

Разработка информационной модели по IDEF1X выполняется в несколько этапов:

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

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

• выявляются и определяются основные отношения, результаты представляются графически в виде так называемых ER-диаграмм;

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

• определяются атрибуты сущностей.

IDEF2 Поведенческое моделирование

IDEF3 Моделирование деятельности

IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: «Что делает система?», то в этих методиках детализируется ответ на вопрос: «Как система это делает». В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательности смен состояний. Перечисленные методики относятся к так называемым структурным методам.

IDEF4 Объектно-ориентированное проектирование

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

IDEF5 Систематизация объектов приложения

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

IDEF6 Использование рационального опыта проектирования

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

IDEF8 Взаимодействие человека и системы

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

IDEF9 Учет условий и ограничений

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

IDEF14 Моделирование вычислительных сетей

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

Методология SADT

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

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

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

Подход SADT относится к классу формальных методов, используемых при анализе и разработке систем. Несмотря на то, что вполне допустима независимая разработка функциональных моделей, методология SADT предполагает ведение структурированного проекта анализа, в процессе которого происходит их создание. В дополнение к функциональному моделированию SADT структурный анализ предполагает построение информационных моделей данных и диаграмм состояний (State-Transition Diagrams — STD), которые моделируют поведение системы во времени.

Основной принцип SADT состоит в том, что тщательный анализ системы обусловливает получение возможного оптимального решения. Использование SADT автоматически приводит к необходимости сбора и обработки значительного количества информации о системе. Традиционно такая информация собирается аналитиком посредством формализованного опроса экспертов предметной области — людей, владеющих информацией о механизме функционирования системы в целом или ее частей. С течением времени некоторые эксперты освоили технологию моделирования, что привело к появлению IDEF3-технологии получения знаний от экспертов. Однако роль системного аналитика в проектах SADT оставалась ключевой.

Часто разработка моделей применяется для документирования ситуации, сложившейся к определенному моменту (модели «как есть» — «as is»). Впоследствии они применяются при создании новых моделей функционирования системы (модели «как должно быть» — «to be»), а также для проверки моделей «to be», с тем чтобы удостовериться, что предлагаемые изменения действительно повлекут улучшение функционирования системы.

В дополнение к алгоритмизации процесса построения предлагаемой системы модели «to be» используются для планирования загрузки частей системы; калькуляции бюджета и распределения ресурсов; при построении плана реорганизации системы, определяющего действия по переводу системы из состояния «as is» в состояние «to be». Преимущества, получаемые от разработки моделей «as is», должны быть сопоставлены с затратами средств и времени, которые для этого необходимы. В литературе без труда можно найти многочисленные примеры систем, изначально построенных для решения несоответствующих их истинному назначению задач. «as is»-моделирование позволяет обойти подобные трудности. С другой стороны, если имеется определенный уровень понимания задачи в целом (как это часто случается при разработке информационных систем), затраты средств на разработку «as is»-моделей могут быть неоправданными.

Источник: infopedia.su

Заочное отделение ФЭМ СПбГТИ(ТУ)

(модуль) Управление проектами и формирование БМ

Тестирование он-лайн

Выполняем тестирование он-лайн для студентов ФЭМ Технологического института по дисциплине «Управление проектами и формирование бизнес-моделей».

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

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

«Управление проектами и формирование бизнес-моделей».
УПФМБ. Лекция 1. Введение в управление проектами.
УПФМБ. Лекция 2. Основы управления проектами.
УПФМБ. Лекция 3. Процессы и функции управления проектами.
УПФМБ. Лекция 4. Планирование проекта.
УПФМБ. Лекция 5. Календарное планирование проектов.
УПФМБ. Лекция 6. Управление стоимостью проектов.
УПФМБ. Лекция 7. Управление рисками проектов.
УПФМБ. Лекция 8. Информационные технологии в управлении проектами.
УПФМБ. Лекция 9. Процессный подход: концепция внедрения в организации.
УПФМБ. Лекция 10. Принципы процессного подхода (часть 1).
УПФМБ. Лекция 11. Принципы процессного подхода (часть 2).
УПФМБ. Лекция 12. Разработка системы процессов организации (часть 1).
УПФМБ. Лекция 13. Разработка системы процессов организации (часть 2).
УПФМБ. Лекция 14. Моделирование бизнес-процессов организации (часть 1).
УПФМБ. Лекция 15. Моделирование бизнес-процессов организации (часть 2).
УПФМБ. Лекция 16. Моделирование бизнес-процессов организации (часть 3).

Итоговый тест

• избежание
• диверсификация
• страхование

• жирной стрелкой
• тонкой стрелкой
• стрелкой с двумя наконечниками
• стрелкой с одним наконечником

• СОВНЕТ
• РОСНЕТ
• РУСНЕТ

• Список
• Модель
• Перечень
• Глоссарий

• Процесс
• Технология
• Цикл

• Системный подход
• Поддержание стабильности и воспроизводимости процессов
• Измеримость процессов
• Ориентация на удовлетворение потребителей
• Непрерывное совершенствование
• Четкие границы
• Выделение и управление сквозными процессами

• Квалиметрия
• Валидация
• Верификация

• косвенные издержки
• переменные издержки
• накладные расходы
• прямые издержки

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

• Рисунок Б
• Рисунок А и Б
• Рисунок А

• Изучай
• Делай
• Планируй
• Действуй
• Анализируй

• Регламентации
• Декларации
• Спецификации

• до 1 млн. долларов
• до 100 000 евро
• до 100 тыс. руб
• до 1000 долларов

• окружающая среда
• будущие поколения
• неразговорчивые заказчики
• прошлые поколения
• посредники

• в виде комбинации из двух или трех вышеназванных подходов
• по фазам проекта
• по объектам/предметам
• по видам деятельности или функциям

• Ян Грехем
• А.Шухарт
• Э.Деминг
• Дж. Бокс

• технические риски
• финансовые риски
• временные риски

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

• инкрементное проектирование
• водопад
• спираль
• прототипирование

• вручную
• автоматически

• план издержек
• структурный план
• процессный план
• план планов

• ракеты «Поларис»
• гидроэлектростанции
• нефтепровода «Дружба»

• описание операций процесса (в табличной форме) и схему процесса
• описание контура управления
• описание процесса в контуре управления
• регламентация времени

• Разработка процессной архитектуры организации
• Организация управления процессами
• Разработка системы показателей
• Запуск цикла PDCA
• Описание и регламентация процессов
• Подготовка
• Принятие решений

• графа
• таблицы
• схемы
• рисунка

• уравновешенность
• гибкость
• дерзость
• медлительность
• честолюбие
• смелость
• гордость
• вдумчивость
• заботливость

• продуктовый подход
• CBM IBM (Component Business Model компании IBM)
• подход «блюдо спагетти»
• методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ)
• структурный подход

• MS Project Web Site
• MS Project Web Access
• MS Office System (MS Outlook)
• MS Office Project Professional

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

• Профессору В. И. Воропаеву
• Энтони Уокеру
• Гарольду Оберлендеру

• Поставщик/ Вход процесса
• Управление несоответствующей продукцией
• Показатели: процесса, продукта
• Ресурсы: персонал, среда, инфраструктура, документация, связь, оборудование, материалы
• Удовлетворенность

• DFD
• IDEF0
• IDEF3

• ленточные графики
• графики Гантта
• сетевые графики

• 3
• 4
• 2

• процессы инициации
• процессы подготовительные
• предварительные процессы

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

• MS Project Web Site
• MS Office Project Professional
• MS Project Web Access
• MS Office System (MS Outlook)

• XIX
• XXI
• XX

Источник: www.ineedhelp.ru

Моделирование бизнес процессов

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

4.

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

5.

• Для
моделирования
бизнес-процессов
широко используются следующие стандарты:
– IDEF0 (Integration Definition for Function Modeling);
– BPMN (Business Process Modeling Notation).
• Эти
стандарты
представляют
собой
графическую нотацию для описания и
моделирования бизнес-процессов.
• Стандарт IDEF0 реализован в таких пакетах
как IDEF0.EM Tool, IDEF0Doctor, BPWin,
Office Visio 2007.

6. 3.2. Стандарт IDEF0

• Стандарт IDEF0
моделирования:
предназначен
для
– функций (действий, процессов,
операций), исполняемых системой или
предприятием;
– функциональных отношений и данных
(информации или объектов), которые
поддерживают интеграцию этих функций.

7.

• Применимость стандарта IDEF0:
– моделирование информационных систем
для их анализа, разработки,
реинжиниринга, интеграции и сборки;
– моделирование бизнес-процессов
предприятий для их анализа;
– моделирование процессов (методологий)
разработки программного обеспечения.

8.

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

9.

• Основные элементы стандарта IDEF0:
– функциональный блок;
– интерфейсная дуга.

10.

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

11.

• Интерфейсная дуга (Arrow):
– изображается в виде стрелки;
– обозначает элемент (объект или
документ), который обрабатывается
функциональным блоком или влияет на
функциональный блок;
– название дуги должно быть оборотом
существительного.

12.

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

13.

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

14.

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

15.

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

16.

• Модель IDEF0 всегда начинается с
представления системы как единого
целого – одного функционального блока
с
интерфейсными
дугами,
простирающимися
за
пределы
рассматриваемой области.
• Такая
диаграмма
с
одним
функциональным блоком называется
контекстной
диаграммой,
и
обозначается идентификатором “А-0”.

17.

Пример контекстной диаграммы

18.

Декомпозиция контекстной диаграммы

19.

• Ограничения сложности на диаграммы
(необязательные):
1. Ограничение количества функциональных
блоков на диаграмме тремя-шестью.
2. Ограничение количества подходящих к
одному функциональному блоку (выходящих
из одного функционального блока)
интерфейсных дуг четырьмя.
• В пояснительном тексте к контекстной
диаграмме должна быть указана цель
(Purpose) построения диаграммы в виде
краткого описания и зафиксирована точка
зрения (Viewpoint).

20. 3.3. Стандарт BPMN

• BPMN
определяет
графические
элементы для моделирования бизнес
процессов. Моделью бизнес процесса
является
графическая
диаграмма,
которая состоит из активностей
(activities,
works)
и
потоков
управления (flow controls), которые
определяют
порядок
исполнения
активностей.

21.

• BPMN
предназначена
для
моделирования
только
бизнес
процессов
и
не
поддерживает
моделирование структуры организации
и функциональных требований.
• BPMN
ориентирована
на
моделирование двух базовых типов
бизнес-процессов:
– сотрудничество (collaborations) или
публичный (public) бизнес процесс;
– внутренний (internal) или частный
(private) бизнес процесс.

22.

• Сотрудничество это бизнес процесс,
которые
представляет
собой
взаимодействие нескольких участников
этого бизнес процесса.
• Частный вид сотрудничества бизнес
процесс B2B (business to business).
• Внутренний бизнес процесс это
бизнес процесс, которые происходит
внутри организации и невидим вне этой
организации.

23.

• Графические элементы BPMN:
– элементы потока (flow elements);
– соединительные элементы (connecting
elements);
– разделители (swimlanes);
– артефакты (artifacts).

24. Элементы потока

• Активность или действие (activity) –
это работа, которая исполняется внутри
бизнес процесса.
• Обозначения для активности:

25.

• Событие
(event)
–
это
что-то
происшедшее во время исполнения
бизнес процесса и повлиявшее на
последовательность
или
продолжительность активностей.
• Различаются три типа событий:
– начальное (start);
– промежуточное (intermediate);
– конечное (end).

26.

• Обозначения событий:

27.

• Слияния-разъединения (gateway) –
используются
для
слияния
и
разъединения
потока
активностей.
Различаются следующие типы слиянийразъединений:
– слияние-разъединение (gateway)
– ветвление-соединение (fork / join);
– inclusive decision / merge

28.

• Обозначение слияний-разъединений:

29.

• Соединительные элементы включают
три типа соединений:
– последовательности потока (sequence
flow) – показывает последовательность
исполнения активностей бизнес процесса;
– потока сообщений (message flow) –
показывает поток сообщений между
участниками бизнес процесса;
– ассоциации (association) – используется
для соединения информации и артефактов
с объектами бизнес процесса.

30.

• Обозначение соединительных
элементов:

31.

• Разделители включают элементы двух
типов:
– пулы (pools) – это соглашения между
предпринимателями для устранения
конкуренции, здесь отдельная часть бизнес
процесса;
– подразделения (lanes) – это части пула
для организации активностей внутри пула.

32.

• Обозначаются подразделения
следующим образом:

33.

• Артефакты
объектов:
включают
три
типа
– объекты данных (data objects) – это
объекты, которые содержат информацию о
бизнес-процессе, но на исполнение бизнес
процесса не влияют;
– группы (groups) – используются для
группирования объектов в бизнеспроцессе;
– аннотации (annotations) – объекты для
представления дополнительной
информации о бизнес-процессе.

34.

• Обозначение артефактов:

35. Пример бизнес процесса с нормальным потоком

36. Пример бизнес процесса с пулами

37. 3.4. Моделирование бизнес процессов в UML

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

38. Профиль Эрикссона-Пенкера для моделирования бизнес процессов в UML

39.

• Для моделирования бизнес процессов в
системе SPARX EA используется
профиль Эриксонна-Пенкера (EricssonPenker),
в
котором
определены
следующие стереотипы:
– для активности определен стереотип
> — бизнес процесс;
– для объектов, которые инициируют
исполнение бизнес процесса, определен
стереотип > — событие.

40.

• — для связи бизнес-процесса с объектами, от которых
зависит его исполнение, определены следующие
стереотипы для отношения зависимости:
– > цель – связывает бизнес процесс с причиной, изза которой организация выполняет бизнес процесс;
– > обеспечить – связывает бизнес процесс с
объектами, которые содержат информацию для обеспечения
исполнения бизнес процесса;
– > ввод – связывает бизнес процесс с объектами,
которые используются (обрабатываются) в процессе
исполнения бизнес процесса.
– > вывод – отмечает объекты, которые являются
результатом исполнения этого бизнес процесса;
– > управление – связывает бизнес процесс с
объектами, которые управляют бизнес процессом.

41. Пример бизнес-процесса разработки программной системы

analysis Analysis v iew
Удовлетворение
требований
заказчика
«goal»
Спецификация
программной
системы
Разработка программной
системы
«output»
«input»
«supply»
Разработчики
«supply»
Средства
разработки
Программная
система

Источник: ppt-online.org