Ну и вы все в какой-то степени правильно пишете :0)
На фазе бизнес-анализа эти вопросы мы просто еще не затрагиваем. Далее будет фаза бизнес-проектирования, на которой будет бизнес-обоснование с подсчетом денежных выгод для каждой из сторон.
Но про UCS-премьеру имелось ввиду, что у кинотеатра уже есть эта система.
Не совсем так. Приведенный нами framework, как и написано, предназначен в основном для проектирования продуктов. В заказной разработке появляются свои детали.
В нашем понимании выгода — более общее понятие в отличие от интереса. Например, «получение опыта в бизнес-анализе» — выгода, интерес — «овладение методиками и техниками анализа».
Обращаться за пояснениями можно и нужно! Это нам тоже поможет понять, что стоит улучшить в данном подходе.
Состояние «Аннулирован» — конечное состояние всех билетов, т.е. после окончания киносеанса все билеты становятся недействительными.
Про возврат — неоднозначный вопрос. Мы предполагали, что возврат билетов возможен только в случае отмены киносеанса, в этом случае после возврата билет аннулируется. Возврат в случае, когда зритель просто передумал идти не рассматривался.
Повторюсь, что «карандаш» — не главное. Это просто удобный инструмент. Такие схемы можно, скажем, рисовать в процессе интервью с заинтересованными лицами, поэтому карандаш может пригодиться.
Вопрос «Как и в чем рисовать?» не имеет особого значения. Удобно и привычно Вам в визио — рисуйте в визио. Просто было удобнее обсуждать, то как будут выглядеть эти схемы и по ходу обсуждения изображать на бумаге карандашом. Можно на доске маркером, а потом сфотографировать, главное — придти к общему мнению.
В общем случае слово «Актор» используется с целью указать всех возможных действующих лиц, если вариант использования системы выполняется несколькими ролями (скажем, оператор, администратор, незарегистрированный пользователь), то проще написать «Актор: роль1, роль2, роль3», и далее в сценарии использовать это обозначение. Примером такого кейса может быть авторизация в системе.
В приведенном нами примере действия совершает одна роль, поэтому смысл такого приема не очевиден.
Выбранный нами подход — разделить весь анализ и проектирование на 3 фазы: бизнес, продукт и система (технический уровень). На каждой фазе мы принимаем ряд решений.
И на фазе бизнес-анализа нам пока не нужны диаграммы use case (они относятся к уровню технического анализа и проектирования), нам тут нужно определиться с тем, кто наши заинтересованные лица, как устроен процесс бронирования вообще, прибыльно ли автоматизировать этот процесс, с какими понятиями мы имеем дело и т.д.
Мы намеренно рисовали обобщенный процесс, и изначально не думали о таком множестве комбинаций: сначала выбор фильма, потом времени; сначала время, потом фильм; сначала выбираем кинотеатр и время, потом из того, что сейчас идет, выбираем наилучшее.
Как раз, когда рисовали и документировали, это понимание пришло. Засовывать все эти варианты в диаграммы на уровне бизнес-анализа нам показалось нецелесообразным.
Поэтому мы приняли решение на продуктовом уровне описать контекстные сценарии для каждого вида зрителей — для киномана, который хочет непременно пойти на определенный фильм; для компании студентов, которые хотят после пар пойти в кино на какой-нибудь фильм, главное, чтобы билеты были; и для других групп зрителей.
Software-Process.ru — блог об организации разработки ПО
Maieutic.ru — записки менеджера-айтишника
На фазе бизнес-анализа эти вопросы мы просто еще не затрагиваем. Далее будет фаза бизнес-проектирования, на которой будет бизнес-обоснование с подсчетом денежных выгод для каждой из сторон.
Но про UCS-премьеру имелось ввиду, что у кинотеатра уже есть эта система.
Обращаться за пояснениями можно и нужно! Это нам тоже поможет понять, что стоит улучшить в данном подходе.
Про возврат — неоднозначный вопрос. Мы предполагали, что возврат билетов возможен только в случае отмены киносеанса, в этом случае после возврата билет аннулируется. Возврат в случае, когда зритель просто передумал идти не рассматривался.
В приведенном нами примере действия совершает одна роль, поэтому смысл такого приема не очевиден.
И на фазе бизнес-анализа нам пока не нужны диаграммы use case (они относятся к уровню технического анализа и проектирования), нам тут нужно определиться с тем, кто наши заинтересованные лица, как устроен процесс бронирования вообще, прибыльно ли автоматизировать этот процесс, с какими понятиями мы имеем дело и т.д.
Как раз, когда рисовали и документировали, это понимание пришло. Засовывать все эти варианты в диаграммы на уровне бизнес-анализа нам показалось нецелесообразным.
Поэтому мы приняли решение на продуктовом уровне описать контекстные сценарии для каждого вида зрителей — для киномана, который хочет непременно пойти на определенный фильм; для компании студентов, которые хотят после пар пойти в кино на какой-нибудь фильм, главное, чтобы билеты были; и для других групп зрителей.
Этот материал мы опубликуем через 3-4 статьи :0)
Можно и текстом описать, и как угодно. Просто, на мой взгляд, выбранный вариант в целом прост и нагляден.