■ Вариант использования 5.

* Вариант использования 18.

* Вариант использования 19.

■ Вариант использования 20.

15.1. Моделирование или проектирование.

Утверждение “Мы применяем варианты использования для реинжиниринга бизнес-процессов” может иметь одно из значений:.

“Мы используем их для документирования старого процесса, перед тем как перепроектировать его”.

“Мы используем их для создания соответствующих проекту внешних требований к поведению”.

“Мы используем их для документирования нового процесса после повторного проектирования”.

Все это правильно. Вы должны решить, какое значение вы имеете в виду.

Рассуждая о вариантах использования, я предусмотрительно употребляю термин моделирование или документирование бизнес-процессов вместо реинжиниринга или проектирования. Вариант использования только документирует процесс. Он не модернизирует и не перепроектирует его. В процессе проектирования разработчики восходят к вершинам изобретательности. Варианты использования не сообщают им, как это делать. Каждый уровень документирования служит требованием к поведению, которое должен удовлетворить следующий уровень проектирования (на самом деле мы говорим, что данный проект удовлетворяет этим требованиям к поведению).

Внедрение новой технологии часто вносит изменения в бизнес-процессы. Вы можете заново их настроить в направлении от основного бизнеса к технологии, от нового процесса к технологии или от технологии непосредственно (одновременно порождая процесс). Работает каждый из этих методов.

Работа в направлении от основного бизнеса.

Применяя этот метод работы (сверху вниз), вы начинаете с точного определения основного бизнеса (основного вида деятельности) организации, как описано в книге Reengineering the Corporation (Hammer, 1984). Когда вы сделаете это, вам будут известны:.

Участники, заинтересованные в поведении организации.

Внешние основные действующие лица, чьи цели, как вы предполагаете,.

удовлетворяет организация.

События, на которые организация должна реагировать Услуги, предоставляемые данным бизнесом, с положительными результатами для участников.

Обратите внимание, что без единого слова о том, как ваша организация будет работать, вы теперь имеете информацию, которая устанавливает граничные условия ее поведения. Это также граничная информация для варианта использования: участники и интересы, основные действующие лица с их целями, гарантии успеха.

Контекст для проектирования бизнес-процесса можно документировать с помощью вариантов использования для бизнеса типа “черного ящика”, рассматривая компанию или организацию как разрабатываемую систему (рис. 15.1).

На этом этапе вы по-новому группируете ваши ресурсы и создаете новые процессы для наилучшего использования текущей технологии. В настоящее время компьютерные системы служат для организации активной памяти и активных каналов связи в корпорации. В книге Reengineering the Corporation приводится много примеров того, как изобретательная деятельность приводит к различным бизнес-проектам и соответствующему эффекту. Итогом является новый проект корпорации или организации (рис. 15.2).

Далее результат переосмысления и перепроектирования процесса документируется с помощью вариантов использования типа “прозрачного ящика”, показывающих людей и отделы (и, возможно, компьютеры), взаимодействующие, чтобы обеспечить внешне видимое поведение организации.

Полностью разработанные варианты использования типа “прозрачного ящика” должны демонстрировать обработку организацией всех ошибок и исключительных состояний, подобно тому, как это делает какой-либо набор вариантов использования или полная модель бизнес-процесса. В варианте использования вы можете записать (или не записать) название технологии в зависимости от вашей задачи.

Рис. 15.1. "Черный ящик" основного бизнеса

Рис. 15.2. Новый бизнес-проект как “прозрачный ящик".

Работа в направлении от бизнес-процесса к технологии.

С этой промежуточной стартовой точки вы не исследуете основную деятельность организации, а скорее определяете новый бизнес-процесс, чтобы приспособиться к новой технологии. Вы, вероятно, уже определили некоторую новую технологию, возможно, новый комплекс программных продуктов или мобильных устройств. Вам требуется поставить граничные условия для нововведений технологов.

Чтобы документировать новые предлагаемые бизнес-процессы, не упоминая новую технологию, вы должны писать варианты использования типа “прозрачного ящика” (рис. 15.3). Упоминание новой технологии в данной ситуации так же неуме-.

стно, как описание интерфейса пользователя в варианте использования системы (см., например, вариант использования 21).

Рис. 15.3. Новый бизнес-проект как "прозрачный ящик" (снова).

В принципе компьютер в описании можно заменить корзинами бумаг, перевозимыми от одного индивидуума к другому. Задача вашей группы —понять, насколько активные каналы, например большие компьютеры или множество карманных компьютеров и компьютеров с радиосвязью, улучшают процесс.

Разработчики теперь знают, какой процесс должно подаерживать их изобретение. Они напишут системные варианты использования типа “черного ящика”, чтобы показать соответствие новой системы технологически независимым вариантам использования для бизнеса типа “прозрачного ящика”. Эти системные варианты использования становятся требованиями к разработке системы (см. рис. 15.4).

Хотя на бумаге все выглядит просто, это трудоемкий и дорогостоящий процесс. Технология развивается быстро и оказывает большое воздействие на бизнес. Часто не хватает времени работать по такой схеме. Много раз я обнаруживал, что деловые эксперты, являющиеся классными специалистами в своей области, способны мысленно построить модель нового бизнес-процесса, позволяя вам сэкономить время и деньги. Это дает вам возможность идти по третьему пути, описанному ниже.

Рис. 15.4. Новый бизнес-процесс в виде вариантов использования типа "черного ящика".

Работа в направлении от технологии к бизнес-процессу.

Во-первых, соберите несколько опытных экспертов, серьезно настроенных повысить качество технологии. Убедитесь, что у вас есть по два представителя каждой части бизнес-процесса, с которым ваша система будет иметь дело.

Во время переговоров эксперты по технологии назовут возможности системы, которые смогут улучшить процесс. Будьте готовы к тому, что они назовут больше, чем ваша группа разработчиков способна реализовать (это нормально, технологам необходимо мыслить с запасом).

Пусть эксперты напишут варианты использования типа “черного ящика” для системы, которую они себе представляют. В этих вариантах использования не будет упоминаться интерфейс пользователя. Они должны описать, что система сделает, чтобы максимально эффективно поддерживать основных действующих лиц в достижении их целей в бизнесе. Разделы расширения должны включать все виды критичных или редко обсуждаемых бизнес-правил. Экспертам, возможно, придется поговорить со своими коллегами, чтобы прояснить тонкие моменты поведения системы. В ходе работы они, конечно, создадут несколько вариантов использования обобщенного уровня и вариантов использования для бизнеса, показывающих контекст и связи целей во времени.

Другими словами, в результате будет создана документация бизнес-процесса в облегченной форме как часть требований к системе. Эксперты по применению смоделируют в уме новый бизнес-процесс, обсуждая в то же время, как следует себя вести действующим лицам и новой системе в различных обстоятельствах. Я считаю такой способ работы эффективным.

■ Вариант использования 3 иллюстрирует, как в документации поведения системы можно завершить изложение фрагмента бизнес-процесса описанием исключительных состояний.

■ Обобщенный (уровня воздушного змея) вариант использования 21 показывает контекст бизнес-процесса для системы.

15.2. Связывание вариантов использования Аля бизнеса и для системы.

Вариант использования для бизнеса имеет такой же вид, как и системный вариант использования, поэтому все уроки по созданию и анализу вариантов использования применимы к обеим разновидностям. Постепенно развертывающаяся история начинается в вариантах использования для бизнеса и разворачивается в системные варианты использования. Это совместный эффект, который обеспечивают варианты использования для бизнеса и для системы.

Недостаток в том, что писатели и читатели могут случайно смешать их, привнося поведение системы в варианты использования для бизнеса, а бизнес-операции — в системные варианты использования. Это полезно, если они совершают это намеренно, но часто это делается неосознанно. Читатель, полагая, что имеет дело с системным вариантом использования, критикует вариант использования для бизнеса за слишком высокий уровень описания, не учитывая, что тот не предназначен для детализации поведения системы. Автор, работающий над вариантом использования для бизнеса, может случайно включить много подробностей поведения системы, в результате чего руководство быстро потеряет интерес к чтению этих перегруженных деталями документов.

Чтобы уменьшить путаницу, всегда записывайте область действия и уровень в поля шаблона варианта использования. Обучите своих авторов делать это, а читателей — начинать чтение с этих полей. По возможности применяйте пиктограммы. Употребляйте различающиеся шаблоны и нумеруйте варианты использования по-разному (в одной проектной группе нумерация вариантов использования для бизнеса начиналась с 1.000, а системных вариантов использования — с 1). Придумайте что-нибудь наглядное. Тогда вы получите преимущество совместного использования без путаницы в документах и потери нужных читателей.

Другой недостаток заключается в том, что редко имеет смысл полностью и надлежащим образом связывать варианты использования для бизнеса и для системы. Обычно те, кто создают варианты использования для бизнеса, описывают бизнес-процесс вплоть до применения системы, не включая последнее. Им не хватает времени, денег, сил и стимулов, чтобы написать, как используется новая система в повседневной жизни деловых людей. Авторы системных вариантов использования иногда добавляют для контекста одно-два предложения, описывающие бизнес-процесс, но у них отсутствуют побудительные мотивы переписывать варианты использования для бизнеса, чтобы включить новые функциональные возможности системы.

В результате возникает разрыв между вариантами использования для бизнеса и системными вариантами использования. Расти Уолтерс из FirePond комментирует это так:.

Я должен все же испытывать удовлетворение от полностью завершенных вариантов использования для бизнеса, которые развертываются в системные варианты использования. По моему опыту, весьма распространенной является ситуация, когда имеются три уровня вариантов использования для бизнеса. Несколько вариантов использования для бизнеса типа “черного ящика” уровня облака создаются вначале. Они быстро превращаются в варианты использования для бизнеса типа “прозрачного ящика” уровня облака, которые раскрываются, показывая тем самым, что они именуют варианты использования для бизнеса типа “прозрачного ящика” и уровня воздушного змея.

Однако я не видел ясного соединения вариантов использования для бизнеса и системных вариантов использования.

Это не слишком хорошо для тех, кто ищет способ получить требования к системе из бизнес-процессов автоматически. Не думаю, что автоматический вывод требований возможен (см. раздел 15.1).

Некоторых это беспокоит. Меня нет. Большинство людей, с которыми я работал в организациях, способны совершить переход мысленно, чтобы связать вариант использования для бизнеса самого низкого уровня с системным вариантами использования уровня воздушного змея или уровня моря. Кроме того, я должен быть уверен, что писать этот окончательный набор вариантов использования, который полностью привязывает варианты использования для бизнеса к системным вариантам использования, стоит усилий и денег, которые придется затратить. Эти две работы финансируются отдельно, и каждая соответствующим образом завершается, когда ее цель достигнута.

Пересмотрите варианты использования, начиная с варианта использования 19. Системные варианты использования действительно упоминаются в вариантах использования для бизнеса, но они были написаны специально, чтобы обеспечить контекст для группы разработчиков требований к системе, а не в качестве начала отдельной работы по реинжинирингу бизнес-процесса.

Далее Расти Уолтерс из FirePond рассказывает о своем опыте работы с вариантами использования для бизнеса.

■ Расти Уолтерс:.

Моделирование бизнес-процессов и требования к системе.

Прочитав вашу книгу, я смог усовершенствовать проблемные области с помощью прежнего опыта и вновь обретенных знаний.

Мой предыдущий опыт.

До прочтения этой книги я помогал документировать функциональные требования к нескольким приложениям комплекса программных продуктов.

Для одного приложения мы разработали системные варианты использования на обобщенном, пользовательском уровне, а также на уровне подфункции. Мы целиком сконцентрировались на функциях системы и были удовлетворены окончательной моделью вариантов использования, так как она довольно легко читалась. Мы решили, что нет необходимости разрабатывать какие-либо варианты использования для бизнес-процесса, чтобы показать контекст. Нас вполне устраивали системные варианты использования обобщенного уровня.

Для другого приложения из комплекса ситуация отличалась, несмотря на то, что за эту модель вариантов использования и за предыдущую отвечала одна группа. Оглядываясь назад, я понимаю, что основной проблемой были сотрудники, рассматривающие эту задачу под разными углами зрения. Я работал в направлении от бизнес-процесса к технологии, а другие — от технологии к бизнес-процессу. Надо ли говорить, что область действия проектирования каждого варианта использования не была согласована между сторонниками двух направлений.

Сторонники направления от бизнес-процесса к технологии так никогда и не добрались до создания системных вариантов использования, а приверженцы направления от технологии к бизнес-процессу так и не взялись за написание вариантов использования для бизнеса. Вместо этого они перетасовывали варианты использования друг друга, "сталкивая их лбами". При этом каждая группа пыталась непосредственно применять варианты использования другой группы. Поскольку разработчики не обладали в то время ни интуицией, ни должным пониманием, чтобы правильно пометить область действия и уровень вариантов использования, модель вариантов использования превратилась в настоящую мешанину. В конечном счете разработчикам никогда не везло с этой моделью вариантов использования. Они чувствовали, что с ней что-то не так, но точно не знали, в чем дело.

Опыт, полученный после прочтения книги.

Работа в направлении от основного бизнеса, похоже, вызывает меньшую неразбериху. Я понял это в группе, чьей целью было понять и документировать бизнес-процессы.

Всем было ясно, что нас собрали обсудить бизнес-процессы и способы их работы в этой отрасли бизнеса, а не системы программного или аппаратного обеспечения. Возникшие неясности были связаны с выбором области действия проектирования: бизнес-процесс либо подразделение.

Мы начали с бизнеса, создавая весьма обобщенные (уровня облака) варианты использования типа "черного ящика". Это было понятно каждому, несмотря на то, что некоторые члены группы хотели погрузиться в детали более низкого уровня. Мы быстро продвигались в создании очень обобщенных (уровня облака) вариантов использования типа "прозрачного ящика". Когда мы подошли к вариантам использования следующего, более низкого уровня, сразу возникло сомнение по поводу области действия проектирования. Говорим мы о бизнесе либо об определенном подразделении? К тому же это тесно переплелось с вопросом о том, что составляет успех варианта использования. В одном случае мы закончили тем, что удалили два последних шага после того, как осознали, что зти шаги в действительности были в вызывающем варианте использования и не должны были находиться в текущем. В настоящее время у группы нет намерения когда бы то ни было преобразовывать варианты использования для бизнеса в варианты использования, определяющие требования к системе.

После совещания проблемные области стали понятными. Документируя результаты, я употреблял контекстные диаграммы области действия проектирования, пометив область действия и уровень каждого варианта использования пиктограммами. Простые и наглядные, они действительно влияют на читабельность вариантов использования и существенно помогают последним закрепиться в памяти читателей.