Belin

Опыт Объектно Ориентированного подхода в Бизнес-Анализе

или разговариваем с разработчиками на одном языке

Опыт Объектно Ориентированного подхода в Бизнес-Анализе

или разговариваем с разработчиками

на одном языке

Александр Белин

Летний Аналитический Фестиваль 2013 ЛАФ2013

Пожелания в разработкуПлюсы

Оперативная разработка

Заказчик видит

динамику

Заказчик чувствует

себя в центре

внимания

У заказчика возникает ощущение контроля текущей ситуации

Пожелания в разработкуМинусы

Пожелания в требованияПлюсы

Есть требования, поэтому есть возможность

проводить планирование:

• ресурсов;• бюджета.

Проводить документировани

е

Осуществлять тестирование,

основанное на требованиях

Пожелания в требованияМинусы

Изучение бизнеса

Бизнес-анализ

Док-е \модел-е бизнеса

Согласование с

заказчиком

Польза для понимания

Последовательная верифика

ция

Предыдущая модель – база для

последующей

Выход из ситуацииПроведение полноценного бизнес-анализа

Roadmap

Проведение Бизнес-Анализа

1

Описание Бизнеса

Шаг 1Описание бизнеса

Описание бизнесаСо слов представителей заказчика составляется текстовое описание бизнеса

Шаг 1Описание бизнеса

1


2

Разметка описания Бизнеса

Шаг 1Описание бизнесаШаг 2


Шаг 2Разметка описания бизнеса

Разметка описания бизнесаС текстом описания бизнеса проводится разметка. В тексте отыскиваются и выделются:• Действующие лица

бизнеса (Business Actors);• Бизнес действия

(Business Actions);• Бизнес правила (Business

Rules).

1


2


Шаг 2


3

Бизнес Правила

Шаг 3


Шаг 3Описание Бизнес-Правил

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

• БП в форме Глоссария бизнес терминов позволяют общаться с заказчиком на одном языке;

• БП создают необходимый Бизнес контекст для разрабатываемого приложения;

• Не смотря на то, что БП – это не требования, они влияют на требования:– БП могут служить источником как для Use Cases, так и

для Функциональных (атомарных) требований;– БП могут выполнять роль предусловий, триггеров, точек

ветвления для Use Cases;– БП могут накладывать ограничения на функционал,

описанный в Use Case

Почему Бизнес-Правила очень важны?

3


Шаг 3


1


2


Шаг 2


4

Описание Бизнес-

Действующих лиц и их

целей

Шаг 4Описание Бизнес-Действующих Лици их Бизнес-Целей

Шаг 4Описание Бизнес-Действующих Лиц и их Бизнес-Целей

4

Описание Бизнес-

Действующих лиц и их

целей

Шаг 4Описание Бизнес-Действующих Лици их Бизнес-Целей

5

Business Use Case Diagram

Шаг 5Business Use Case Diagram


• Каждое Бизнес-действующее лицо превращаем в Business Worker;

• Действующие лица, существующие за пределами исследуемого бизнеса, превращаем в Бизнес Действующих Лиц (Business Actors);

• Каждую бизнес цель превращаем в Бизнес Вариант Использования (Business Use Cases);

• Бизнес ВИ ассоциируем с Business Worker, цели которых они описывают;

• Business Workers с пересекающимися ролями (целями) проводим через процесс Generalization.

Модель проходит согласование с заказчиком

5



6

Business Activity Diagram

Шаг 6Business Activity Diagram


• Пошагово изображаем в виде диаграммы содержание каждого Business Use Case;

• Диаграмма должна содержать шаги, которые выполняются в бизнесе для достижения Бизнес-Цели, которая описывается данным Business Use Case;

Модель проходит согласование с заказчиком

5


6



7


with Swim Lanes

Шаг 7Business Activity Diagram with Swim Lanes


• Выделяем всех Business Workers и Business Actors, участвующих в данном Бизнес Варианте Использования;

• Разделяем действия по зонам отвественности;

7


with Swim Lanes


8


with Object States

Шаг 8Business Activity Diagram with Object States

Шаг 8

Business Activity Diagram with Swim Lanes с указанием управляемого объекта

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

сущности;• используют определенное

состояние данной сущности в качестве предусловия;

• Описываем все возможные состояния данной сущности.

Заменяем управляющий поток потоком изменения статуса в тех случаях, когда два соседних действия управляют одной сущностью:• Одно изменяет состояние;• Второе использует сущность

в измененном состоянии в качестве предусловия.

Шаг 8


7


with Swim Lanes

8


with Object States


9

Business Process Diagram

Шаг 9Business Process Diagram

Шаг 9

Диаграмма бизнес процесса (BPMN)

Диаграмма бизнес процесса(пример из реального проекта)

9


Шаг 9Business Process Diagram

7


with Swim Lanes

8


with Object States



• Мы видим:• Различные состояния объекта,

управляемого в рамках данного Бизнес-Процесса;

• Действия, которые приводят к изменению состояния.

• Что еще хотелось бы увидеть:• Какие дополнительные действия

выполняются при изменении состояния;

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

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

7


with Swim Lanes

8


with Object States


10

State Machine Diagram

(статусная модель)

Шаг 10State Machine Diagram (статусная модель)

Шаг 10Диаграмма Автомата (статусная модель)

Что добавляет данная диаграмма к нашему пониманию:• дополнительные

действия выполнямые при изменении состояния;

• Условия изменения состояния;

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

Статусная модель(пример из реального проекта)

10

State Machine Diagram

(статусная модель)

Шаг 10State Machine Diagram (статусная модель)

1

Карта проведения процесса Бизнес Анализ

2

3

4

5 6 78

9

10

Где же Объектно Ориентированный

подход?

Где же объекты?

Классы давай!!!

Role MapBusiness Workers to Actors

Actors to Class Diagram

Business Use Cases to Business Entities

Объединенная Диаграмма Бизнес Классов

Бизнес-Анализ закончен.

Понять бизнес – это здорово!

Что дальше?

Как использовать собранную информацию для написания

требований?

Это все?Как собранная

информация влияет на требования?

Будет ли собранная информация полезна

разработчикам?

Следующие шаги:• Определить Actors;

• Определить Use Cases;

Начинается этап Системного Анализа.

Находим действующих лиц(Actors)

Actors




Role Map

Определяем Use Cases

Use Cases

Business Actors & Goals

Business Rules


Источник

Use Cases Diagram (model)

Структура Use Cases

Activity Diagram

Business Rules

Use Case

Precondition

Trigger

Условие логического ветвления

Бизнес Правила – это не требования. Зачем с ними работать?

Вот теперь действительно все!

Александр БелинБизнес-Аналитик, компания Люксофт.Участник инициативы по созданию Российского Отделения Международного Института Бизнес-Анализа (IIBA®)

[email protected]

Давайте обсудим ваши вопросы

Летний Аналитический Фестиваль 2013

ЛАФ2013

Design ideas: Slide:ology by Nancy Duartehttp://www.duarte.com/book/slideology/

Belin

Documents

Transcript of Belin