Комментарии 32
С трудом помню времена, когда билет в кино нельзя было купить по интернету :)
Что делать если схема которая получается в итоге очень большая?
Есть несколько вариантов.
1. Использовать VAD-диаграммы, которые разбивать на более мелкие EPC. EPC также декомпозировать.
2. Рисовать обобщенный вариант диаграммы — например, в данном случае диаграмма EPC не включает все возможные ветвления. Тут не описан случай, когда зритель изначально выбирает не фильм, а кинотеатр, ближайший к его дому, после чего идет туда, и на месте определяется, какой фильм ему сейчас посмотреть. Раскрытие этих ветвлений будет происходить на продуктовом уровне. Там будут рассмотрены виды зрителей (киноман, который хочет посмотреть определенный фильм; групповой поход, когда важно, чтобы в наличии было достаточное количество билетов, и др.).
3. Использовать структурированное текстовое описание, как описано в примере.
1. Использовать VAD-диаграммы, которые разбивать на более мелкие EPC. EPC также декомпозировать.
2. Рисовать обобщенный вариант диаграммы — например, в данном случае диаграмма EPC не включает все возможные ветвления. Тут не описан случай, когда зритель изначально выбирает не фильм, а кинотеатр, ближайший к его дому, после чего идет туда, и на месте определяется, какой фильм ему сейчас посмотреть. Раскрытие этих ветвлений будет происходить на продуктовом уровне. Там будут рассмотрены виды зрителей (киноман, который хочет посмотреть определенный фильм; групповой поход, когда важно, чтобы в наличии было достаточное количество билетов, и др.).
3. Использовать структурированное текстовое описание, как описано в примере.
Хотелось бы сделать несколько замечаний.
Во-первых, ARIS — это не нотация, а методология и платформа. VAD, EPC — это типы диаграмм. IDEF0 — стандарт методологии SADT, даже наверное тип диаграмм. Что касаетс BPMN — я бы тоже не стал называть это лишь нотацией. Нотация — это набор значков и правил для рисования диаграмм.
Во-вторых, использовать диаграмму VAD в качестве workflow мягко говоря неуместно, если имеется в виду диаграмма методологии ARIS. Эта диаграмма (VAD — диаграмма цепочки добавленного качества) используется для описания процессов верхнего уровня и подпроцессов, но не до такой детализации.
ИМХО
Во-первых, ARIS — это не нотация, а методология и платформа. VAD, EPC — это типы диаграмм. IDEF0 — стандарт методологии SADT, даже наверное тип диаграмм. Что касаетс BPMN — я бы тоже не стал называть это лишь нотацией. Нотация — это набор значков и правил для рисования диаграмм.
Во-вторых, использовать диаграмму VAD в качестве workflow мягко говоря неуместно, если имеется в виду диаграмма методологии ARIS. Эта диаграмма (VAD — диаграмма цепочки добавленного качества) используется для описания процессов верхнего уровня и подпроцессов, но не до такой детализации.
ИМХО
Да, ARIS, буквально, не нотация, можно сказать «нотации семейства ARIS».
Чем отличается нотация от типа диаграмм?
Что по-вашему означает последняя буква в аббревиатуре BPMN?
Чем отличается нотация от типа диаграмм?
Что по-вашему означает последняя буква в аббревиатуре BPMN?
1. тип диаграмм определяет точку зрения, в том же ARIS'e. Нотация — набор элементов и правила их использования в диаграмме. Тип диаграммы определяет контекст создания диаграммы. В определённом приближении, конечно, можно сказать, что нотация и тип диаграммы — одно и то же
2. Business Process Model and Notation, так что речь тут не только о нотации.
2. Business Process Model and Notation, так что речь тут не только о нотации.
Почему вы считаете, что данном случае VAD показывает не процесс верхнего уровня?
Я считаю, что процессы верхнего уровня соответствуют миссии компании, стратегии, а ни как не бронированию и покупке билетов. Если речь идёт о компании.
А с точки зрения пользователя, пожалуй да… процесс верхнего уровня — это просмотр фильма, покупка билета, если в этом случае уместна VAD, впрочем, и микроскопом колоть орехи можно.
А с точки зрения пользователя, пожалуй да… процесс верхнего уровня — это просмотр фильма, покупка билета, если в этом случае уместна VAD, впрочем, и микроскопом колоть орехи можно.
Мы исходили из того, что процесс покупки билета надо каким-то образом описать, для этого была выбрана диаграмма VAD, т.к. я таких много рисовал :0)
Можно и текстом описать, и как угодно. Просто, на мой взгляд, выбранный вариант в целом прост и нагляден.
Можно и текстом описать, и как угодно. Просто, на мой взгляд, выбранный вариант в целом прост и нагляден.
Вот Вы пишете. что «процесс покупки билета надо каким-то образом описать, для этого была выбрана диаграмма VAD», а каким образом объект «просмотр фильма» на диаграмме имеет отношение к «процесс покупки билета»? =)
По поводу VAD, я понимаю и согласен, что выбранный вариант довольно нагляден и прост для понимания. Но, моё мнение, что в данном случае это не тот инструмент. Как вариант, не менее наглядно можно было нарисовать с помощью IDEF0, BPMN, да и просто прямоугольничками в любом графическом редакторе. И какбэ со своей стороны спорить на эту тему я дальше не хочу, Вы автор, Вы выбрали и аргументировали свой выбор, мне всё ясно...))
По поводу VAD, я понимаю и согласен, что выбранный вариант довольно нагляден и прост для понимания. Но, моё мнение, что в данном случае это не тот инструмент. Как вариант, не менее наглядно можно было нарисовать с помощью IDEF0, BPMN, да и просто прямоугольничками в любом графическом редакторе. И какбэ со своей стороны спорить на эту тему я дальше не хочу, Вы автор, Вы выбрали и аргументировали свой выбор, мне всё ясно...))
Интересно, а как нарисовать такую диаграмму, когда выбор фильма может быть осуществлен 2 способами:
1. Сначала выбираем фильм, а потом время.
2. Сначала выбираем время («что там у нас сегодня вечером будет?»), а уже потом фильм.
1. Сначала выбираем фильм, а потом время.
2. Сначала выбираем время («что там у нас сегодня вечером будет?»), а уже потом фильм.
Мы намеренно рисовали обобщенный процесс, и изначально не думали о таком множестве комбинаций: сначала выбор фильма, потом времени; сначала время, потом фильм; сначала выбираем кинотеатр и время, потом из того, что сейчас идет, выбираем наилучшее.
Как раз, когда рисовали и документировали, это понимание пришло. Засовывать все эти варианты в диаграммы на уровне бизнес-анализа нам показалось нецелесообразным.
Поэтому мы приняли решение на продуктовом уровне описать контекстные сценарии для каждого вида зрителей — для киномана, который хочет непременно пойти на определенный фильм; для компании студентов, которые хотят после пар пойти в кино на какой-нибудь фильм, главное, чтобы билеты были; и для других групп зрителей.
Этот материал мы опубликуем через 3-4 статьи :0)
Как раз, когда рисовали и документировали, это понимание пришло. Засовывать все эти варианты в диаграммы на уровне бизнес-анализа нам показалось нецелесообразным.
Поэтому мы приняли решение на продуктовом уровне описать контекстные сценарии для каждого вида зрителей — для киномана, который хочет непременно пойти на определенный фильм; для компании студентов, которые хотят после пар пойти в кино на какой-нибудь фильм, главное, чтобы билеты были; и для других групп зрителей.
Этот материал мы опубликуем через 3-4 статьи :0)
И ещё вопрос, как документировать бизнес-процессы с помощью use case (пункт IV)? Насколько я понимаю, use case используется для описания того, что предоставляет проектируемая система по запросу пользователя. Вот для проектирования веб-сервиса самое оно использовать именно диаграмму use case на начальном этапе.
И ещё, чем продиктован выбор именно диаграмм ARIS'a для моделирования и описания бизнес-процессов при разработке веб-сервиса? Не кажется ли несколько неуместным выбор методологии моделирования бизнес-деятельности предприятия для проектирования веб-сервиса, по сути, создания системы?
Мне кажется Вы ушли в другую область — начинали с проектирования веб-сервиса, а ушли в бизнес-процессы.
Имхо, могу ошибаться.
И ещё, чем продиктован выбор именно диаграмм ARIS'a для моделирования и описания бизнес-процессов при разработке веб-сервиса? Не кажется ли несколько неуместным выбор методологии моделирования бизнес-деятельности предприятия для проектирования веб-сервиса, по сути, создания системы?
Мне кажется Вы ушли в другую область — начинали с проектирования веб-сервиса, а ушли в бизнес-процессы.
Имхо, могу ошибаться.
Как документировать — мы же дали пример? На фазе бизнес-анализа мы описываем не проектируемую веб-систему, а существующую — кинотеатр, с соответствующими способами его применения.
То, что диаграмму use case нужно использовать на начальном этапе — это популярное программистское заблуждение. Пока мы не выяснили, кто будет аудиторией и для каких целей будет использовать проектируемую систему и какие из целей нам стоит поддерживать — use case'ы рисовать рано. У нас это вообще технический уровень, когда уже известна концепция продукта. А тут мы пока на бизнесовом.
То, что диаграмму use case нужно использовать на начальном этапе — это популярное программистское заблуждение. Пока мы не выяснили, кто будет аудиторией и для каких целей будет использовать проектируемую систему и какие из целей нам стоит поддерживать — use case'ы рисовать рано. У нас это вообще технический уровень, когда уже известна концепция продукта. А тут мы пока на бизнесовом.
Я не говорил, что диаграмму use case нужно использовать.
А вот аудиторию то выяснили в предыдущей статье.
«У нас это вообще технический уровень, когда уже известна концепция продукта. А тут мы пока на бизнесовом.» можно пояснить, я что-то вас не понял.
А вот аудиторию то выяснили в предыдущей статье.
«У нас это вообще технический уровень, когда уже известна концепция продукта. А тут мы пока на бизнесовом.» можно пояснить, я что-то вас не понял.
Выбранный нами подход — разделить весь анализ и проектирование на 3 фазы: бизнес, продукт и система (технический уровень). На каждой фазе мы принимаем ряд решений.
И на фазе бизнес-анализа нам пока не нужны диаграммы use case (они относятся к уровню технического анализа и проектирования), нам тут нужно определиться с тем, кто наши заинтересованные лица, как устроен процесс бронирования вообще, прибыльно ли автоматизировать этот процесс, с какими понятиями мы имеем дело и т.д.
И на фазе бизнес-анализа нам пока не нужны диаграммы use case (они относятся к уровню технического анализа и проектирования), нам тут нужно определиться с тем, кто наши заинтересованные лица, как устроен процесс бронирования вообще, прибыльно ли автоматизировать этот процесс, с какими понятиями мы имеем дело и т.д.
В предыдущей статье были ключевые заинтересованные лица проекта и продукта.
Заинтересованные лица и потребитель — это не одно и то же. Сказать, что потребителем будет зритель — почти ничего не сказать. Нужно знать аудиторию гораздо лучше, попытка это сделать будет показана на продуктовом уровне.
Заинтересованные лица и потребитель — это не одно и то же. Сказать, что потребителем будет зритель — почти ничего не сказать. Нужно знать аудиторию гораздо лучше, попытка это сделать будет показана на продуктовом уровне.
Раскладка работ по уровням (это НЕ простая последовательность):
Бизнес
Б1. Бизнес-анализ (понятия, процессы, состояния, правила, заинтересованные лица, проблемы)
Б2. Бизнес-проектирование (изменения в процессе, затраты, выгоды, прибыль)
Продукт
П1. Продуктовый анализ (потребители, деятельность потребителя, проблемы, интересы, потребности, конкуренты)
П2. Продуктовое проектирование (формула продукта, ключевые свойства, устройство интерфейса)
Технология
Т1. Технологический анализ (технические ограничения, технологические возможности, детальные сценарии взаимодействия потребителя с продуктом)
Т2. Технологическое проектирование (устройство системы внутри, подсистемы, структуры, потоки данных, состояния системных объектов, протоколы взаимодействия)
Мы сейчас в Б1.
Бизнес
Б1. Бизнес-анализ (понятия, процессы, состояния, правила, заинтересованные лица, проблемы)
Б2. Бизнес-проектирование (изменения в процессе, затраты, выгоды, прибыль)
Продукт
П1. Продуктовый анализ (потребители, деятельность потребителя, проблемы, интересы, потребности, конкуренты)
П2. Продуктовое проектирование (формула продукта, ключевые свойства, устройство интерфейса)
Технология
Т1. Технологический анализ (технические ограничения, технологические возможности, детальные сценарии взаимодействия потребителя с продуктом)
Т2. Технологическое проектирование (устройство системы внутри, подсистемы, структуры, потоки данных, состояния системных объектов, протоколы взаимодействия)
Мы сейчас в Б1.
Здесь диаграммы ARIS'а используются для функционального описания предметной области, что является полезным входом для последующего бизнес-, продуктового и технического проектирования веб-сервиса.
Любой веб-сервис автоматизирует деятельность — либо существующую, либо новую. Чтобы её автоматизировать, её надо изучить. Деятельность может быть описана с применением диаграмм процессов. Для некоторых видов деятельности такие диаграммы могут быть не полезны, например, для описания работы дизайнера в Photoshop.
Тут мы имеем пограничный случай — с одной стороны, кинотеатр со своим стандартным бизнес-процессом закупка кино-продажабилетов-показ, с другой — человек, с не очень стандартизованной деятельностью, в которой возможны перестановки.
Да, можно было и просто прямоугольнички со стрелочками нарисовать, без ссылки на нотацию, но хочется показать связь с практиками, принятыми в B2B.
Любой веб-сервис автоматизирует деятельность — либо существующую, либо новую. Чтобы её автоматизировать, её надо изучить. Деятельность может быть описана с применением диаграмм процессов. Для некоторых видов деятельности такие диаграммы могут быть не полезны, например, для описания работы дизайнера в Photoshop.
Тут мы имеем пограничный случай — с одной стороны, кинотеатр со своим стандартным бизнес-процессом закупка кино-продажабилетов-показ, с другой — человек, с не очень стандартизованной деятельностью, в которой возможны перестановки.
Да, можно было и просто прямоугольнички со стрелочками нарисовать, без ссылки на нотацию, но хочется показать связь с практиками, принятыми в B2B.
Всегда удивляюсь, почему в описании use cases используют неблагозвучное для русского языка слово Актор.
Ведь аналитика пишется для простых заказчиков и разработчиков, которым гораздо более понятны фразы «Зритель называет номер брони» и «Зритель передает оператору плату за билет», а не «Актор называет номер брони».
Ведь аналитика пишется для простых заказчиков и разработчиков, которым гораздо более понятны фразы «Зритель называет номер брони» и «Зритель передает оператору плату за билет», а не «Актор называет номер брони».
В общем случае слово «Актор» используется с целью указать всех возможных действующих лиц, если вариант использования системы выполняется несколькими ролями (скажем, оператор, администратор, незарегистрированный пользователь), то проще написать «Актор: роль1, роль2, роль3», и далее в сценарии использовать это обозначение. Примером такого кейса может быть авторизация в системе.
В приведенном нами примере действия совершает одна роль, поэтому смысл такого приема не очевиден.
В приведенном нами примере действия совершает одна роль, поэтому смысл такого приема не очевиден.
Согласен, это правильно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кейс «Проектирование веб-сервиса бронирования билетов». Бизнес-анализ. Описание существующих бизнес-процессов (AS-IS)