Три поименованных уровня цели

Три поименованных уровня цели

Цели и взаимодействия в сценарии можно развернуть в более детализированные и более разветвленные цели и взаимодействия. Это нормальное состояние, и мы хорошо с этим справляемся в повседневной жизни. Далее иллюстрируется тот факт, что наши цели содержат под- и подподцели.
Мне нужен определенный договор о продаже. Чтобы его добиться, я должен пригласить управляющего компании на обед. Адля этого мне нужна некоторая сумма наличными. Чтобы ее получить, мне придется извлечь деньги из данного банкомата. Для этого мне нужно, чтобы он признал мою идентичность. Адля этого необходимо, чтобы он прочитал мою банковскую карточку. Чтобы сделать это, я должен найти щель для карточки.
Я хочу найти клавишу табуляции, чтобы перевести курсор в поле адреса, чтобы записать мой адрес, чтобы я мог занести мои личные данные в эту программу расценок, чтобы я смогузнать цену, чтобы я смог купить автомобильный страховой полис, чтобы получить водительские права, чтобы водить автомобиль.
Хотя для повседневной жизни здесь нет ничего необычного, в качестве варианта использования это выглядит странно. Создавая варианты использования, мы в каждом предложении сталкиваемся с вопросом, какого уровня цели вариант использования следует описывать.
Помогает именование уровней целей. Далее приведены названия уровней цели и пиктограммы, которые я считаю полезными, а также описано, как определить уровень цели, необходимый в данный момент. На рис. 5.1 даны названия и зрительные образы, которыми я пользуюсь.
Рис. 5.1. Уровни вариантов использования. Набор вариантов использования обнаруживает иерархию целей — непрерывно разворачивающуюся историю.
5.1. Цели пользователя (голубые, уровня моря и ).
Наибольший интерес представляет цель пользователя. Это та цель, которую преследует основное действующее лицо, пытаясь добиться от системы выполнения определенной работы, либо пользователь, работающий с системой. Она соответствует “элементарному бизнес-процессу” в технологии бизнесс-процессов.
Цель пользователя характеризуется вопросом: “Уйдет ли основное действующее лицо удовлетворенным, выполнив это?” Для служащего этот вопрос звучит так: “Зависит ли ваша производительность труда от того, сколько вы сегодня сделаете?” Цель можно также пропустить через тест “перерыва на кофе”: “Когда это закончу, сделаю перерыв на кофе”. В большинстве случаев цель пользователя проходит тест для одного клиента за один сеанс (2 — 20 мин).
Вообще цели “Совершить покупку на онлайновом аукционе” и “Войти в систему” не считаются целями пользователя. Онлайновые аукционы требуют несколько дней и поэтому не проходят односеансовый тест. Вход в систему 42 раза подряд не отвечает (как правило) должностным обязанностям индивидуума или цели использования системы.
“Зарегистрировать нового клиента” и “Купить книгу” вполне могут быть целями пользователей. Задача регистрации 42 новых клиентов не лишена смысла для агента по продажам. Покупку книги можно совершить за один сеанс.
Пока все как будто выглядит просто. Однако, столкнувшись со множеством фраз, написанных на доске, или вариантом использования, который по какой-то причине выглядит неправильно, легко впасть в сомнения. Я считаю, что большинство.
людей будут чувствовать себя уверенно, изображая уровни целей в цвете либо применяя обозначения высоты над уровнем моря.
Цветовая гамма охватывает белый, голубой, индиго, черный цвета (в книге как оттенки серого). Цель пользователя — голубая. Долгосрочные цели, имеющие более высокий уровень, например “Завершить онлайновый аукцион” и “Получить страховое возмещение за автомобильную аварию” — белые. Краткосрочные цели, имеющие более низкий уровень, — цвета индиго. Черный указывает, что эта цель такого низкого уровня, что было бы ошибкой писать для нее вариант использования, например: “Нажать на клавишу Tab”.
Идея метафоры уровня моря состоит в следующем. Небо находится очень высоко над уровнем моря, а вода опускается ниже уровня моря на большую глубину, но существует только один уровень, где встречаются небо и море, — уровень моря. То же самое справедливо и для целей. Много уровней цели находится над целью пользователя и много под ней, но цели пользователя достаточно важны, чтобы их записать. Поэтому им соответствует уровень моря (знак волн). Облако или воздушный змей обозначают более высокий уровень, чем уровень моря, рыбка или моллюск — это значок уровня цели ниже уровня моря.
Система характеризуется поддержкой целей уровня моря. Вот одна из таких целей:.
Вы служащий, сидящий на рабочем месте. Звонит телефон, вы берете трубку. Некто на другом конце говорит: Вы поворачиваетесь к компьютеру.
В этот момент вы думаете о том, что необходимо выполнить работу G. Вы некоторое время работаете с компьютером и клиентом и, наконец, завершаете работу G. Отворачиваетесь от компьютера, прощаетесь и вешаете трубку.
G — голубая (уровня моря) цель пользователя. Выполняя G, вы выполняете ряд целей более низкого уровня (индиго). Персона, позвонившая по телефону, вероятно, имеет в виду более высокий уровень цели, и выполнение G только один шаг к ней. Цели этой персоны, имеющие более высокий уровень, белые.
Цели пользователя уровня моря (голубые) чрезвычайно важны, поэтому стоит серьезно потрудиться, чтобы их понять и усвоить. Кратчайшее изложение функций системы — это список целей пользователя, которые она поддерживает. Это основа для расстановки приоритетов, сдачи системы, разделения работ, оценки и разработки.
Варианты использования будут создаваться на уровнях выше и ниже уровня моря. Можно представить себе огромное число целей более низкого уровня и варианты использования как “подводные”, поскольку это подразумевает, что мы на самом деле не хотим описывать их или читать о них.
■ Невымышленная история.
Однажды мне переслали сотни страниц вариантов использования, все цвета индиго, или подводные. Этот документ, описывающий требования, был такой длинный и скучный, что не мог быть полезен ни его авторам, ни его читателям. Позднее отправитель выслал мне шесть вариантов использования уровня моря, которые заменили предыдущий документ, и сообщил, что все нашли новый документ более легким для понимания и работы с ним.
Два уровня голубого.
Обычно голубой вариант использования имеет один белый вариант использования выше и несколько вариантов использования цвета индиго ниже. Однако иногда он обращается к другому голубому варианту использования. Я видел это только в одной ситуации, но эта ситуация возникает многократно.
Предположим, выполняя кое-какие поручения, я иду мимо магазина видеопроката. Размышляю: “Раз уж я здесь, зарегистрируюсь”. Захожу и прошу оформить мне регистрацию. Такова моя цель пользователя, голубой вариант использования. На следующей неделе прихожу со своим членским билетом, чтобы взять напрокат видео. Я осуществил эти две цели пользователя в разные дни.
Однако вы пользуетесь видеопрокатом по-другому. Заходите в видеомагазин взять напрокат видео. Служащий спрашивает, зарегистрированы ли вы. Вы говорите, что нет, поэтому служащему приходится зарегистрировать вас в процессе выдачи напрокат первого видеофильма. Регистрация представляет собой шаг в рамках выдачи напрокат видео, хотя обе цели голубые.
Ситуация “Попутно зарегистрировать клиента” — единственная ситуация, в которой я видел один голубой вариант использования внутри другого голубого варианта использования. Когда меня об этом спрашивают, я иронически отвечаю, что оба варианта использования имеют уровень моря, но “Взять напрокат видео” сидит на гребне волны (см. рис. 5.1), а “Зарегистрировать клиента” — в ее подошве.
5.2. Обобщенный уровень (белый, облако О или воздушный змей />).
Цели обобщенного уровня включают несколько целей пользователя. При описании системы они выполняют три назначения:.
■ Показывают контекст, в котором выполняются цели пользователя.
■ Показывают жизненный цикл последовательности связанных целей.
■ Формируют перечень вариантов использования более низкого уровня, как белых, так и голубых.
Обобщенные варианты использования по шкале цветов белые. Белые варианты использования имеют шаги белого, голубого, а порой и цвета индиго (“Войти в систему” — это цель цвета индиго, которая, вероятно, будет обнаружена в белом варианте использования). Я не считаю полезным проводить различия между разнообразными уровнями белого, но иногда могут сказать что-нибудь вроде: “Этот вариант использования по-настоящему белый, белый до того, что поднялся в облака”.
*• Ранее я использовал два термина: "стратегический* и “обобщенный". Недавно я пришел к выводу, что “обобщенный” вызывает меньше путаницы, и выбрал его для этой книги.
В терминах уровня моря мы скажем, что большинство обобщенных вариантов использования похожи на воздушного змея как раз над уровнем моря, а другие поднялись до облаков.
Обобщенные варианты использования обычно выполняются в течение часов, дней, недель, месяцев или лет. Здесь представлен основной сценарий “долгоиграющего” варианта использования, задача которого — связать голубые варианты использования, разбросанные по годам. Обратите внимание, что графика помогает указать, что вариант использования касается компании, рассматриваемой как “черный ящик”, и что уровень цели очень белый (высоко в облаках). Подчеркнутые фразы представляют собой варианты использования более низкого уровня. Знак “+” в конце имени — это альтернативный способ обозначения вариантов использования обобщенного уровня (подробнее см. в разделе 5.4).
Вариант использования 18 # Выполнить операции со страховым полисом + О...
Основное действующее лицо: клиент.
Область действия: страховая компания (MylnsCo).
Уровень: обобщенный (белый).
Шаги:.
1.
Клиенту назначают цену полиса.
2.
Клиент покупает полис.
3.
Клиент делает заявление об аннулировании полиса.
4.
Клиент закрывает полис.
В этой главе приведены и другие варианты использования:.
* Вариант использования 19, Обработать заявление (бизнес).
■ Вариант использования 20, Оценить указанную в заявлении сумму.
■ Вариант использования 21, Обработать заявление (система).
Возвращаемся к предельным вариантам использования.
Ранее я рекомендовал вам написать несколько предельных вариантов использования для разрабатываемой вами системы. Ниже представлен более точный процесс обнаружения этих предельных вариантов использования:.
1.
Начните с цели пользователя.
2.
Спросите, какому (предпочтительно вне организации) основному действующему лицу, АА, служит эта цель. Действующее лицо АА — конечное действующее лицо вариантов использования, которые мы хотим собрать.
3.
Найдите предельную область действия проектирования S, такую, чтобы АА еще находился вне S. Придумайте название для области действия.
S. У меня обычно три такие предельные области действия:.
• Компания.
• Объединяемые программные системы.
• Конкретная разрабатываемая программная система.
4.
Определите все цели пользователей, для которых конечное основное действующее лицо — это АА, а область действия проектирования — S.
5.
Выработайте обобщенную цель, GG, которую действующее лицо АА имеет в отношении системы S.
6.
Напишите обобщенный вариант использования для цели GG действующего лица АА в отношении системы S. Этот вариант использования связывает ряд вариантов использования уровня моря.
Обычно таких вариантов использования наивысшего уровня (GG) набирается всего четыре-пять даже для самых больших систем. Они обобщают интересы трех-четырех конечных основных действующих лиц (АА):.
* Клиента к компании.
■ Отдела маркетинга к комплексу программных систем.
■ Отдела безопасности к самой программной системе.
Эти предельные варианты использования помогают определить границы работы, и я настоятельно рекомендую писать их по указанным выше причинам. Однако они не обеспечат вашу группу функциональными требованиями к системе, которую она будет разрабатывать, — эти требования заключены в вариантах использования для целей пользователя (голубых).
5.3. Подфункции (индиго или черный, ПОДВОДНЫЙ К3> или моллюск) в.
Цели уровня подфункции — это цели, достижение которых требуется для реализации целей пользователей. Включайте их только по мере необходимости. Они иногда нужны для легкого прочтения или потому, что их применяют многие другие варианты использования. Примеры вариантов использования уровня подфункции: Найти изделие, Найти заказчика и Сохранить в файле (см., в частности, необычный вариант использования 23 цвета индиго).
Варианты использования уровня подфункции являются подводными, цвета индиго. Некоторые даже лежат на дне. Они окрашены в черный цвет, что означает, что это слишком низкий уровень. Не вздумайте возводить его в степень варианта использования (он даже не плавает... настоящий моллюск). Удобно иметь специальное название для подобных вариантов использования ультранизкого уровня. Если кто-нибудь таковой напишет, вы укажете, что его содержимое должно в свернутом виде войти в другой вариант использования.
Голубые варианты использования имеют шаги цвета индиго, а в вариантах испо-; льзования индиго встречаются более глубинные шаги индиго, как показано ниже на рис. 5.2. Здесь для обнаружения более высокого уровня цели для вашей целевой фразы следует ответить на вопрос, почему действующее лицо это делает. Метод “как/почему” более подробно обсуждается в разделе 5.5.
Обратите внимание, что даже в самых глубинных подводных вариантах использования для подфункций самого низкого уровня основное действующее лицо находится вне системы. Я бы не стал об этом упоминать, если бы люди иногда не говорили о подфункциях так, будто их проектирование каким-то образом подлежит обсуждению, и если бы не отсутствовало основное действующее лицо. В случае подфункции действуют все правила для вариантов использования. Основным действующим лицом для подфункции может быть то же лицо, что и в варианте использования более высокого уровня, который обращается к данной подфункции.
Обобщение уровней целей.
К настоящему моменту важны три пункта относительно уровней целей:.
■ Серьезно отнеситесь к выявлению вариантов использования уровня моря. Они действительно важны.
■ Напишите несколько предельных вариантов использования, чтобы обеспечить контекст для других.
■ Не слишком беспокойтесь по поводу того, представлена ли ваша любимая фраза среди описаний требований к системе как название варианта использования.
Быть названием варианта использования — не означает быть самым важным требованием, равно как и не быть названием — не значит быть не важным. Я понимаю, что люди огорчаются, если требование, которое они считают самым важным, стало только шагом в варианте использования и не было развернуто в вариант использования, который прослеживается сам собой.
Не волнуйтесь об этом. Одно из достоинств целевой модели состоит в том, что относительно небольшое изменение превращает сложный фрагмент текста в вариант использования или задвигает тривиальный вариант использования обратно в вариант использования более высокого уровня. Каждое предложение пишется как цель, и каждая цель может быть развернута в собственный вариант использования. Глядя на написанное, мы не можем сказать, какие предложения развернуты, а какие нет (если не следовать связям), и это хорошо, поскольку оберегает целостность написанного от несущественных изменений. Цели, которым гарантируются собственные варианты использования, — это цели только голубого цвета.
5.4. Использование пиктограмм для выделения уровней целей.
Выше я продемонстрировал несколько пиктограмм, которые полезно помещать слева от названия варианта использования. Поскольку уровни цели не более одно-.
значны, чем названия, я располагаю пиктограмму уровня цели справа вверху от названия. Это в дополнение к заполнению полей шаблона. Читатели (и писатели) используют любые подсказки, чтобы распознать уровень цели.
Придерживаясь высотной терминологии, я выделяю пять высот над уровнем моря. В большинстве случаев вам хватит трех средних.
■ Варианты использования очень высокого обобщения (очень белые) обозначаются облаком, О. Используйте этот знак в тех редчайших ситуациях, когда вы видите, что шаги варианта использования сами являются белыми целями. Если нельзя добавить пиктограмму, добавьте знак плюса (+) в конце названия варианта использования (см. вариант использования 18).
■ Обобщенные (белые) варианты использования обозначаются знаком воздушногозмея, Р. Это имеетместо для большинства обобщенных вариантов использования, шаги которых представляют собой голубые цели. Добавьте + к названию варианта использования, если не можете применить пиктограмму.
■ Варианты использования для цели пользователя (голубые, уровня моря) обозначаются знаком волн, 33. Не добавляйте никакого суффикса или добавьте восклицательный знак (!) к названию, если нельзя использовать пиктограмму.
■ Варианты использования для подфункций (индиго) обозначаются знаком рыбы, К3>. Используйте его для большинства вариантов использования индиго. Вместо пиктограммы можно поставить знак минуса (-).
■ Некоторые подфункции (черные) никогда не следует описывать в виде вариантов использования. Используйте знак моллюска, @ , чтобы пометить вариант использования, который нужно слить с вариантом использования, вызывающим его.
С помощью этих пиктограмм можно пометить область действия проектирования и уровень цели даже в UML-диаграммах вариантов использования, как только поставщики инструментов начнут их поддерживать. А суффиксы можно применять сразу же. Если ваши шаблоны уже содержат поля Область действия использования и Уровень цели, можете использовать их в качестве резервных меток. Если ваши шаблоны не содержат этих полей, добавьте их.
5.5. Выявление правильной цели пользователя.
Выявление правильной цели пользователя — труднейшая вещь в вариантах использования. Сосредоточьтесь на следующих правилах:.
■ Выявите цель пользователя.
■ Используйте от трех до 10 шагов на вариант использования.
Выявление цели пользователя.
На всех уровнях цели только одна выделяется из других:.
Вы описываете систему (на уровне бизнес-процессов или компьютерную).
Вы думаете о том, кто будет систему использовать. Это лицо хочет что-то.
получить от вашей системы сейчас. Получив это, лицо может продолжить и.
сделать что-то еще. Что же теперь оно хочет от вашей системы?.
Этот уровень имеет много названий. При моделировании бизнес-процессов он называется элементарным бизнес-процессом. По-французски это raison d’etre (основание быть) системы. В вариантах использования это цель пользователя.
Спросите себя, является ли это тем, чего действительно сейчас хочет от системы основное действующее лицо? Для большей части первых наметок вариантов использования ответ будет отрицательным. Очень часто начинающие набрасывают подводные варианты использования, думая, что те находятся на уровне моря. Чтобы обнаружить цель более высокого уровня, задайте себе любой из этих вопросов:.
■ Чего на самом деле хочет действующее лицо?.
■ Почему действующее лицо это делает?.
Ответ может быть настоящей целью действующего лица, но задавайте вопрос снова, пока не будете уверены в этом. Интересно, что даже если тесты для цели пользователя субъективны, люди вскоре приходят к согласию по этому вопросу. Специалисты дают удивительно похожие ответы на вопросы о целях пользователей. Кажется, это устойчивое понятие.
Повышение и понижение уровней целей.
Шаги варианта использования описывают, как осуществляется процесс. Название варианта использования указывает, почему этот процесс представляет интерес. Можно обозначить эту связь “как/почему” во время поиска подходящего уровня цели для шага (см. рис. 5.2).
Чтобы повысить уровень цели одного или нескольких шагов, спросите, почему действующее лицо это делает. Ответом будет цель одним уровнем выше.
Способ оценить уровни целей — посмотреть на длину варианта использования. Большинство хорошо написанных вариантов использования имеют от двух до восьми шагов. Я никогда не видел варианта использования длиннее, чем 11 шагов, который бы не выигрывал от сокращения. Сомневаюсь, что в этих числах есть что-нибудь магическое, но я предполагаю, что люди не желают или не умеют думать в терминах процессов, которые требуют более 10 промежуточных шагов. Я дожидаюсь серьезного контрпримера, только чтобы доказать, что числа не оказывают глубокого влияния.
Какой бы ни была причина, имейте в виду это наблюдение, чтобы улучшить ваши варианты использования. Если у вас больше 10 шагов, вы, возможно, включили детали интерфейса пользователя или описали шаги действий на слишком низком уровне.
■ Удалите подробности интерфейса пользователя. Покажите намерение действующего лица, а не его перемещение.
■ Повысьте уровень цели, задавая вопрос “почему”, чтобы определить следующий более высокий уровень цели.
■ Объедините шаги.
■ Сравните ваши варианты использования с образцами из раздела 5.6 и из главы 19.
Рис. 5.2. Спросите "почему", чтобы изменить уровни.
5.6. Более длинный пример: "Обработка заявления” на нескольких уровнях.
Я выражаю благодарность сотрудникам страховой корпорации пожарных Fund Insurance Corporation из Новато, Калифорния, разрешивших мне включить варианты использования 19-23 в качестве примеров’. Они были написаны специалистами по обработке заявлений в этой области, работающими с бизнес-аналитиками из отдела IT и коллективом разработчиков. Специалисты предметной области глубоко понимают суть использования системы, о которой специалисты из IT не могли догадываться. В свою очередь, сотрудники из IT помогли экспертам предметной области четко сформулировать варианты использования. Оба коллектива обеспечили сочетание предметной, корпоративной и технической сторон.
Пишущая команда состояла из Кэрри Биэр, Эйлин Каррен, Брента Хаппа, Полы Айвей, Сьюзен Пассини, Памелы Пратт, Стива Сэмпсона, Джилл Шиктанц, Нэнси Джуэлл, Тришы Мадалено, Марка Гринберга, Николь Лазар, Дона Копполо и Эрика.
Иванса. Они демонстрируют, что эксперты в предметной области без навыков программирования могут работать со специалистами из IT над требованиями к системе.
Я включаю пять вариантов использования для иллюстрации того, что мы к настоящему моменту обсудили, особенно областей действия проектирования и уровней целей. Эти варианты использования также демонстрируют хороший стиль написания для шагов и расширений. Каждый вариант использования я предваряю комментарием, указывая на некоторые интересные или спорные моменты.
Набор начинается с варианта использования для бизнеса уровня облака типа “прозрачный ящик”. Посмотрите, как цели переходят на более низкие уровни и как область действия системы сжимается от “работы компании” до “всех компьютерных I систем” и далее всего-навсего до “разрабатываемой системы”. Подчеркнутые фра- j зы представляют собой обращения к другим вариантам использования. Шаблон j был немного изменен, чтобы основной сценарий успеха был ближе к началу и быст-) рее читался.
I.
КОММЕНТАРИЙ К ВАРИАНТУ ИСПОЛЬЗОВАНИЯ 19. SuD — это работа компании. Обратите внимание, что компьютерная система даже не упоминается. Вариант использования будет применяться в бизнесе, чтобы скрепить бизнес-процедуры и облегчить работу с помощью компьютера. В настоящий момент этот вариант использования находится лишь на первом этапе проектирования. Как обычно, основной сценарий выглядит тривиальным. Он показывает, как все работает в са-1 мой благоприятной ситуации. Интересные моменты откроются в ситуациях отказа ] и когда компания будет использовать эту информацию для внесения поправок в поддержку эксплуатации системы. Обратите внимание на участников.
Вариант использования 19 & Обработка заявления (бизнес) О.
Область действия: работа страховой компании
3.
Назначенный оценщик I проводит расследование.
оценивает сумму возмещения ущерба определяет резервы.
ведет переговоры по заявлению.
договаривается о сумме возмещения и закрывает заявление Расширения:.
последуют в дальнейшем.
Гарантия успеха: устанавливается сумма возмещения и дело закрывается Минимальная гарантия: нет.
Участники и интересы:.
Подразделения страховой компании, продающие ее страховые полисы Клиенты страховой компании, покупающие полисы Министерство страхования, осуществляющее руководство рынком страховых услуг.
Претенденты, понесшие ущерб в результате действия застрахованного лица Отдел заявлений страховой компании Будущие клиенты.
КОММЕНТАРИЙ К ВАРИАНТУ ИСПОЛЬЗОВАНИЯ 20. Ниже следует еще один вариант использования, в котором SuD все еще является работой компании. Однако цель находится на более низком уровне, чем в варианте использования 19. Здесь описывается работа оценщика, которая может длиться дни, недели или месяцы. Это обобщенный вариант использования уровня воздушного змея, поскольку содержит много односеансовых действий.
Автор не говорит о компьютере прямо, а только называет цели оценщика. Разработчики должны придумать, в чем может заключаться помощь компьютера в этом процессе. Этот вариант использования служит им сырьем для изобретения.
Шаг 7 был добавлен в связи с интересами Министерства страхования.
Вариант использования 20 & Произвести оценку ущерба по заявлению Z
Область действия: работа страховой компании US*.
Уровень: белый (обобщенный, выше уровня цели единичного пользователя).
Контекст использования: оценщик производит всестороннюю оценку обстоятельств понесенного ущерба.
Основное действующее лицо: оценщик Предусловия: документирование последует Триггер: документирование последует Основной сценарий:.
Обратите внимание: идеально, когда перед оценкой проведено расследование, однако глубина расследования может изменяться от заявления к заявлению.
1.
Оценщик просматривает и оценивает медицинские отчеты, документы на арестованное имущество, прибыль на данное число и другие документированные доказательства.
2.
Оценщик оценивает постоянную неплатежеспособность, используя юридическую формулу для определения процента неплатежеспособности.
3.
Оценщик определяет сумму долга при постоянной неплатежеспособности, беря кредит для авансированных сумм и платы за арестованное имущество, чтобы установить полную сумму по заявлению.
4.
Оценщик определяет окончательный диапазон суммы возмещения.
5.
Оценщик проверяет резервы, чтобы убедиться, что компания в состоянии уплатить сумму в установленных пределах.
6.
Оценщик добивается утверждения установленной суммы выплаты и увеличения резерва, если это входит в его полномочия.
7.
Оценщик приобщает к делу документы.
8.
Оценщик посылает корреспонденцию и (или) документацию заинтересованным сторонам, если это необходимо.
9.
Оценщик продолжает приобщать к делу документы, касающиеся всех действий по урегулированию.
Расширения: ...
Частота события: оценивается каждое заявление; это может происходить несколько раз в день.
Гарантия успеха: заявление оценивается и определяются пределы величины возмещения.
Минимальная гарантия: прежде чем начнется повторная оценка заявления для урегулирования претензии, будет произведено дополнительное расследование или составлено медицинское заключение.
Участники и интересы:.
Претендент — хочет получить максимальную сумму возмещения. Оценщик — хочет установить минимально допустимую сумму возмещения.
Страховая компания — то же самое.
Поверенный (защита и обвинение) застрахованных лиц.
Отдел страхования и органы государственного управления штатов (в каждом штате свой департамент, надзирающий за законностью ведения дел и выплачиваемых сумм) охраняют законность и строгое соблюдение процедур.
Открытые вопросы: при разработке бизнес-правил придется обращаться к вопросам юрисдикции.
КОММЕНТАРИЙ К ВАРИАНТУ ИСПОЛЬЗОВАНИЯ 21. Многим специалистам, заня тым в проекте, этот системный вариант использования показался расплывчатым до бесполезности. Однако время на его создание было потрачено не зря, и тому есть несколько причин.
Во-первых, он объединил ряд вариантов использования для пользователя в соответствии с бизнес-правилами. Он описывает процессы закрытия, очистки и архивирования заявления, которые ряду участников проекта просто не известны. Хотя три последних шага не сильно загружают работой программистов, они являются частью процедуры обработки заявления, полезной контекстуальной информацией для любого читателя.
Во-вторых, он записывает в служебные файлы бизнес-правила, не знакомые некоторым разработчикам. Накануне группа потратила три рабочих часа, пытаясь выяснить, что это за правила. Этот вариант использования сберег гораздо больше времени (которое иначе ушло бы на обсуждение), чем было потрачено на его создание.
Этот вариант использования служит введением и оглавлением для Читателей, от руководителей до новых работников компании. Руководители увидят, что в него вошли ключевые процессы, а новички узнают, как работает компания и углубятся в варианты использования для целей пользователя. Интересно расширение *а1, так как оно вызывает вариант использования обработки отказов, который не может быть написан оценщиками, а должен быть создан в группе разработчиков.
Вариант использования 21 0 Обработка заявления (системы) + Р.
Область действия: "система" как комплекс всех компьютерных систем 0 Уровень: обобщенный (белый).
Версия: 1-я.
Статус: готов для анализа Ревизия: текущая.
Контекст использования: клиент хочет получить возмещение за страховое событие.
Основное действующее лицо: клиент.
Предусловия: нет.
Триггер: клиент подает заявление.
Основной сценарий:.
1.
Клиент подает заявление (на бумаге, по телефону или факсу) служащему.
2.
Служащий находит полис, регистрирует заявление в системе и назначает оценщика.
3.
Оценщик расследует заявление и обновляет его с помощью дополнительной информации.
4.
Оценщик вводит информацию по ходу расследования.
5.
Оценщик корректирует записи и резервирует сумму по ходу расследования.
6.
Оценщик получает документацию, включая счета за период срока действия заявления, и вводит счета.
7.
Оценщик оценивает ущерб по заявлению и документирует процесс переговоров в системе.
8.
Оценщик решает вопрос с возмещением и закрывает дело в системе.
9.
Система удаляет заявление из базы данных спустя 6 месяцев после закрытия дела.
10. Система архивирует заявление по прошествии установленного периода.
Расширения:.
*а. В любое время система выходит из строя:.
*а1. Группа системной поддержки восстанавливает систему.
1а. Представленная информация неполна:.
1 а 1. Страховая компания запрашивает недостающую информацию.
1а2. Претендент предоставляет недостающую информацию.
1а2а. Претендент не предоставляет информацию в течение установленного периода.
1а2а1. Оценщик закрывает дело в системе.
2а. У претендента недействительный полис:.
2а 1. Страховая компания отклоняет заявление, уведомляет претендента, обновляет заявление, закрывает дело.
За. На данный момент нет свободных агентов:.
За1. (Что мы здесь делаем?).
8а. Претендент уведомляет оценщика о новых действиях по поводу возмещения:.
8а 1. Служащий открывает дело повторно. Возвращается к шагу 3. Список изменений в технологии и данных:.
Частота события: документирование последует.
Гарантия успеха: дело закрыто, урегулировано и помещено в архив. Минимальная гарантия: дело закрыто, но может быть открыто позднее. Участники и интересы:.
Компания — выплатить минимально допустимое возмещение.
Клиент — получить максимальное возмещение.
Министерство страхования — гарантировать корректность процедур. Бизнес-правила:.
Дата описаний: будет установлена в других вариантах использования. Связи с интерфейсом пользователя (UI): предстоит документировать. Открытые вопросы: период, по окончании которого следует помещать дело в архив.
КОММЕНТАРИИ К ВАРИАНТУ ИСПОЛЬЗОВАНИЯ 22. Это один из самых сложных вариантов использования, которые я видел. Он показывает, почему варианты использования следует описывать естественным языком.
Главный источник сложности — порядок следования. Служащий на телефоне, говорящий с обезумевшим клиентом, должен быть в состоянии вводить данные в любом порядке, в то же время пытаясь следовать стандартной последовательности вопросов. Одновременно компьютер использует эти данные по мере их ввода для возможной на данный момент обработки, например сбор записей по этому клиенту, присвоение заявлению номера и назначение оценщика. Авторы написали не меньше четырех полных версий этого варианта использования, добиваясь ясности, чтобы показать нормальное течение работы и то, что компьютер работает асинхронно. Возможно, на седьмой-восьмой ревизии они нашли бы что-то лучшее, но почувствовали, что дальнейшее умножение ревизий неэффективно, и остановились на этой версии.
Этот вариант использования вызывает вариант использования Найти что угодно несколько раз, задавая при каждом вызове различные объекты и критерии поиска. Разработчики придумали остроумное решение, чтобы не переписывать несколько раз стандартные шаги поиска (списки совпадений, критерии сортировки, повторная сортировка, повторный поиск, объект не найден и т.д.). Я прошу вас сделать то же самое в упражнении 5.4 в конце главы.
Обработка расширения *а. Сбой питания неожиданно стал причиной появления новых проблем с требованиями. Было введено понятие промежуточных сохранений, которые служащему пришлось потом отыскивать. Это стало сюрпризом для писателей, а дополнительная проблема хранения и поиска временно хранимых данных — сюрпризом для разработчиков. Все это вылилось в условие отказа 6Ь, которое касалось тайм-аута для временно хранимых данных и ставило перед писателями очень конкретный вопрос: “Каковы бизнес-правила для временно введенных данных? Они не могут быть зафиксированы, поскольку недостает важной информации, но и удалить их нельзя, так как они удовлетворяют минимальному критерию ввода”. Разработчики так и сяк вертели неприемлемые альтернативы (не делать промежуточных сохранений и удалять данные), пока не решили эту проблему.
Расширение 1 с демонстрирует отказы внутри отказов. Авторы могли бы превратить это в собственный вариант использования, но они решили, что это сильно усложнит набор вариантов использования (новый варийнт использования пришлось бы отслеживать, анализировать и поддерживать). Вместо этого они сделали его расширением расширения. Многие применяют расширения варианта использования по этой причине, хотя в большинстве случаев это объясняется тем, что авторам удобнее для начала сделать собственный вариант использования расширением.
Расширение 2-5а демонстрирует, как податлива среда. Условие может возникнуть на любом шаге от второго до пятого. Как его следует описывать — один раз для каждого случая возникновения? Это представляется слишком расточительным. Было решено просто написать понятные читателям расширения 2-5а и 2-5Ь.
Вариант использования 22 9 Зарегистрировать ущерб 33.
Область действия: "система" означает компьютерную систему обработки.
заявлений 33.
Уровень: голубой (цель пользователя) 0.
Версия: 2.
Статус: проанализирован Ревизия: текущая.
Контекст использования: фиксирование полной информации об ущербе. Основное действующее лицо: служащий Предусловия: служащий уже вошел в систему.
Триггер: служащий уже начал вводить данные об ущербе.
Гарантия успеха: данные об ущербе регистрируются и сохраняются. Минимальная гарантия: ничего не происходит.
Участники и интересы: как выше.
Основной сценарий: Чтобы ускорить работу служащего, система должна работать асинхронно, как только будут записаны необходимые данные. Служащий может вводить данные в любом порядке в соответствии с требованиями момента. Следующая последовательность представляется наиболее вероятной.
1.
Служащий вводит номер полиса застрахованного лица и, возможно, его имя и дату страхового события. Система анализирует доступную информацию о полисе и указывает, что заявление соответствует полису.
2.
Служащий вводит основные данные об ущербе. Система подтверждает, что не существует потенциально конкурирующих заявлений, и присваивает заявлению номер.
3.
Служащий продолжает вводить информацию об ущербе, соответствующую заявлению данного типа.
4.
Служащий использует систему для получения дополнительной информации по делу из других компьютерных систем.
5.
Служащий выбирает и назначает оценщика.
6.
Служащий подтверждает, что он закончил; система сохраняет данные и инициирует отправку уведомления агенту.
Расширения:.
*а. Сбой питания во время обработки заявления:.
*а1. Система периодически автоматически сохраняет данные (возможно, в определенных точках фиксации транзакции, открытый вопрос).
*Ь. Заявление не подлежит обработке в нашей компании:.
*Ы. Служащий указывает системе, что вводится заявление "только с целью записи" и продолжает либо завершает обработку заявления.
1а. Найденная информация о полисе не соответствует информации застрахованного лица:.
1 а 1. Служащий вводит правильные номер полиса или имя.
застрахованного лица и просит систему проверить данные с новым индексом полиса.
1Ь. По имеющимся данным система не смогла найти полис:.
1Ы. Служащий возвращается к заявлению и вводит имеющиеся данные. 1с. Служащий изменил номер полиса, дату страхового события или тип заявления по сравнению с данными предыдущего поиска:.
1с1. Система проверяет правильность изменений, анализирует страховое событие с правильной информацией о полисе, проверяет и подтверждает, что заявление соответствует полису. 1с1а. Система не может подтвердить соответствие полису:.
1с1а1. Система предупреждает служащего.
1с1а2. Служащий отыскивает полис, используя параметры поиска для полиса.
1с2. Система предупреждает служащего о необходимости пересмотреть сумму возмещения.
Id. Служащий хочет повторно запустить обработку заявления, которая была прервана и данные по которой были сохранены или которую следует завершить:.
1d1. Служащий находит дело с помощью параметров поиска для заявления.
1d2. Система открывает данные для редактирования.
2-5а. Служащий изменяет ранее введенный тип заявления и данные, относящиеся к новому типу, не вводятся:.
2-5а1. Система представляет соответствующие поля дела,.
относящиеся к нововведенному служащим типу заявления. 2-5Ь. Служащий изменяет ранее введенный тип заявления, и в связанных с типом полях появляются данные:.
2-5Ы. Система предупреждает, что данные существуют, и предлагает служащему отменить изменения либо продолжить с новым типом заявления.
2-5Ыа. Служащий отменяет изменение, система продолжает обработку заявления.
2-5ЫЬ. Служащий настаивает на новом типе заявления,.
система стирает определяемые типом данные (но сохраняет все основные данные заявления).
2с. Система обнаруживает потенциальный дубликат заявления:.
2с 1. Система показывает список возможных заявлений-дубликатов из базы данных заявлений.
2с2. Служащий выбирает и просматривает заявление из списка. Этот шаг может повторяться несколько раз.
2с2а. Служащий обнаруживает, что это заявление — дубликат: Служащий открывает заявление-дубликат из списка заявлений для редактирования, если оно не помечено как обработанное (в соответствии с уровнем безопасности данных для служащего). Служащий может удалить любые данные в ранее сохраненном файле.
2с2Ь. Служащий обнаруживает, что заявление не является дубликатом: служащий возвращается к заявлению и завершает его обработку.
2d. Предварительная информация об ущербе изменяется после первой проверки заявления-дубликата:.
2d 1. Система снова проверяет заявление-дубликат.
2е. Служащий может сохранять данные по заявлению несколько раз, пока не завершит шаги 2-6. (Иногда он может сохранять данные просто для удобства или ввод приходится по какой-то причине прервать, например, заявление должно быть немедленно передано на обработку оценщику более высокого класса.).
2е1. Служащий сохраняет данные по заявлению, чтобы завершить обработку позднее.
4-5а. Тип заявления либо описание ущерба (см. бизнес-правила) изменились, с тех пор как служащий анализировал сумму возмещения:.
4-5а1. Система предупреждает служащего, что надо пересмотреть сумму возмещения.
6а. Служащий подтверждает, что он закончил, не завершив ввод минимума информации:.
6а 1. Система предупреждает служащего, что не может принять.
заявление без даты страхового события, имени застрахованного лица или номера полиса и назначения оценщика.
6а 1а. Служащий решает продолжить ввод данных по заявлению или сохранить данные без отметки о завершении.
6а 1Ь. Служащий настаивает на выходе без ввода минимума информации, система аннулирует все сохраненные промежуточные данные и прекращает работу,.
6а2. Система предупреждает служащего, что он не может.
присваивать заявлению номер, не заполнив обязательных полей (тип заявления, дату страхового события, номер полиса или имя застрахованного лица); система фокусирует внимание служащего на полях, требующих ввода.
6Ь. Тайм-аут: служащий временно сохранил данные по заявлению, намереваясь вернуться к обработке; система решила, что самое время зафиксировать данные по заявлению, но оказалось, что не введено имя оценщика:.
6Ы. Система назначает оценщика по умолчанию (см. бизнес-правила).
Частота события: ??.
Бизнес-правила:.
*. Когда сохраненные данные по заявлению передаются главной системе (временные диаграммы)?.
1.
Минимум попей, необходимых для сохранения данных по заявлению (и чтобы их можно было потом найти): ...
2.
Номер заявления, однажды присвоенный системой, не может измениться.
3.
Бизнес-правила для ручного ввода номера заявления — понадобится?.
4.
Описание ущерба состоит из двух полей: одно свободной формы, другое — ниспадающее меню.
Три поименованных уровня цели.
5.
Система должна знать, как определить сумму возмещения, исходя из префикса полиса.
81
6.
Поля, которые необходимо заполнить, чтобы подтвердить ущерб: ... 6Ь. Правила назначения оценщика по умолчанию: ...
Используемые описания данных:.
Параметры поиска полиса, информация об индексе полиса, предварительная информация об ущербе, информация об ущербе, обусловленная типом заявления, дополнительная информация.
Параметры поиска заявления, критерий проверки на заявление-дубликат, список возможных заявлений-дубликатов, заявление из списка.
Связи с UI: предстоит документировать Владелец: Сьюзен и Нзнси Рецензенты: Элистер, Эрик ...
Открытые вопросы:.
Как часто происходит автосохранение?.
Карточки официального уведомления агентов — где и как их печатают и т.д.? Группа разработчиков решила, что было бы глупо писать почти идентичные варианты использования Найти клиента, Найти полис и т.д. Вместо этого они создали настраиваемый алгоритм, который применяла каяедая команда писателей. Любое предложение в форме Найти ..., например Найти клиента или Найти изделие, означает вызов варианта использования Найти что угодно с неявным замещением “чего-то” специальным термином. Каждому варианту использования понадобится свой критерий поиска, сортировки и вывода на экран, поэтому писатель будет записывать данные и ограничения на различных листах с гипертекстовыми связями. Поэтому пример предложения будет выглядеть как Найти клиента, используя Параметры поиска клиента.
При этом четком соглашении логику варианта использования Найти что угодно можно написать только один раз и применять во многих похожих, но неидентичных контекстах. Это очень понравилось разработчикам, так как это означает, что для всех ввдов поиска им придется разработать только один алгоритм. Попробуйте на этом примере свои силы. Пока не буду показывать данное решение. Поработайте над упражнением 5.4, преяеде чем заглядывать в решение, которое обсуледается в разделе 14.2.
Вариант использования 23 0 Найти что угодно (постановка задачи) К2>.
Заполнить в качестве упражнения.
5.7. Упражнения.
Уровни цели.
5.1. Дженни стоит перед банкоматом своего банка. Темно. Она ввела свой PIN-код и ищет кнопку “Ввод”. Назовите для Дженни цели белую, голубую и цвета индиго.
5.2.
Перечислите не менее десяти целей различных основных действующих лиц в отношении банкомата и укажите их уровни целей.
5.3.
Перечислите обобщенные цели и цели пользователей всех основных действующих лиц для программного обеспечения PAF (персонального консультанта по финансам), описанного в упражнении 4.4. Определите самый высокий уровень, предельные комбинации “действующее лицо/сфера/цель”.
5.4.
Найдите что угодно. Напишите вариант использования Найти что угодно, триггером которого является желание пользователя локализовать нечто. Вариант использования должен позволить пользователю вводить параметры поиска и сортировки. Он также должен иметь дело со всеми ситуациями, которые могут возникнуть, и в случае успеха завершиться определением компьютером этого “чего-то” независимо от дальнейшего его применения в вызывающем варианте использования.

Популярные статьи

Свежие статьи