Стандарт BPMN
Нотация BPMN (Business Process Model And Notation) находит широкое применение для построения как аналитических, так и исполняемых моделей бизнес-процессов. Она стала стандартом для лидеров ИТ-рынка и широко используется в программных системах.
Нотация BPMN 2.0 является одновременно средством графического визуального моделирования бизнес-процессов и языком создания исполняемой модели бизнес-процесса. BPMN ориентирована на широкий круг специалистов, вовлеченных в описание и автоматизацию бизнес-процессов: начиная с аналитиков и разработчиков и заканчивая экспертами предметной области.
Нотация BPMN относится к классу индустриальных стандартов. Она разработана организацией Object Management Group и утверждена общим решением лидеров ИТ-рынка. Высокий статус организации разработчика, его независимость от конкретного производителя и поддержка лидеров компьютерной индустрии обеспечивают BPMN широкое распространение. В настоящее время версия 2.0 стандарта реализована в большинстве продуктов для моделирования и управления бизнес-процессами, присутствующими на рынке.
Управление IT-проектами — Лекция 7 (Описание бизнес-процессов)
При использовании Системы Управления Бизнес-Процессами исполняемая модель помогает не только раскрыть и верифицировать модель бизнес-процесса, но и испытать ее в условиях реальной эксплуатации.
Нотация BPMN 2.0
Нотация BPMN предназначена для описания:
- Порядка исполнения работ, образующих бизнес-процесс;
- Потоков данных между операциями процесса;
- Потоков сообщений между процессами;
- Ассоциации обрабатываемых объектов данных с операциями процесса.
Моделирование осуществляется с помощью визуальных диаграмм, что позволяет участникам быстрее понять логику исполнения.
Системная инженерия и моделирование
Системная инженерия (Systems Engineering) (системотехника) — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем.
Ключевые инструменты системной инженерии:
- Управление требованиями и трассируемость. Сквозная динамическая трассировка, связывающая источник информации, целевое назначение системы и требования к системе / подсистеме
- Разработка систем на основе моделей. Моделирование требований, функциональности системы, вариантов реализации, исследование затрат, исполнение моделей, валидация
- Управление изменениями и конфигурациями. Управление взаимодействием, изменениями, общим репозиторием и конфигурацией
- Автоматическое создание документов. Создание документов, содержащих информацию о требованиях, моделях, дизайне, спецификациях
- Интегрированная системная и программная инженерия. Обеспечение интеграции между артефактами (сверху-вниз) – требованиями, моделями, разработкой встроенных приложений
Урок 1 BPMN 2.0 Введение: Как моделировать бизнес процессы для разработки ИТ систем? 18+
Требования к системе
Прежде чем приступать к разработке любой системы необходимо сначала определить — для чего эта система нужна.
Большинство людей при строительстве дома даже не интересуются подрядчиками, пока в полном объеме не обсудят свои потребности и желания и не уточнят все детали. Покупатели понимают, что внесение изменений влечет за собой изменение цены. Однако люди весело ищут оправдания, когда дело касается разработки ПО. Ошибки, допущенные на стадии сбора требований, составляют от 40 до 60% всех дефектов проекта.
На переделку дефектов, связанных с недокументированными либо плохо сформулированными требованиями, расходуется от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от 70 до 85% стоимости переделки.
Основной закон: требования должны быть документированы. Не следует ожидать, что для успеха проекта хватит телепатической передачи ненаписанных требований. Требования для каждого проекта должны быть представлены в формах, которые позволят ознакомить с ними всех заинтересованных лиц и управлять ими на протяжении разработки проекта.
Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.
Системный анализ и процесс разработки
Цель рабочего потока анализа (с точки зрения объектно-ориентированного анализа) – создание аналитической модели. Данная модель фокусируется на том, что должна делать система. Детали того, как система будет это делать, предоставляются потоку проектирования.
Аналитик — это посредник в общении, проясняющий смутные представления пользователей и обращающий их в четкие спецификации.
Профессиональный аналитик помогает пользователям четко обрисовать функции системы, необходимые им для достижения бизнес-целей.
В результате формулировки требований формируется коллективный взгляд на систему.
Поскольку именно требования определяют предполагаемый исход (результат) проекта, планы, сметы и графики следует разрабатывать на основе требований.
На разработку требований в успешных проектах тратится от 10 до 30 % ресурсов.
Изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований: 11% — на сбор информации по требованиям, 10% — на моделирование, а 7% на проверку и утверждение; на разработку требований для среднего проекта необходимо 15.7% всех ресурсов и 38.6% времени.
Анализ требований закладывает фундамент всего процесса проектирования и реализации системы.
Методология Объектно-Ориентированного Анализа и Проектирования и язык UML
Системный арализ – совокупность методов и средств, используемых при исследовании и конструировании сложных и сверхсложных объектов, прежде всего методов выработки, принятия и обоснования решений при проектировании, создании и управлении социальными, экономическими, человеко-машинными и техническими системами.
Этап анализа (analysis) состоит в исследовании системных требований и проблемы, а не в поисках путей ее решения.
Выделяют анализ требований (requirements analysis) (т.е. исследование требований к системе) и объектно-ориентированный анализ (object-oriented analysis) (исследование объектов предметной области).
В процессе проектирования (design) основное внимание уделяется концептуальному решению, обеспечивающему выполнение основных требований, но не вопросам его реализации. Этот термин тоже стоит уточнить и говорить об объектно-ориентированном проектировании (object-oriented design) или проектировании базы данных (database design).
Графические (визуальные) модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. Разработка модели информационной системы (ИС) для бизнеса в такой же мере необходима, как и наличие проекта при строительстве здания.
Большинство современных методов ООАП основаны на использовании языка UML.
Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы.
UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии построения информационных систем.
Источник: system-inform.wixsite.com
