На ранней стадии планирования проекта создайте таблицу с названиями вариантов использования и основных действующих лиц в двух левых столбцах. В третий столбец заказчики проекта занесут приоритет каждого варианта использования. В четвертую колонку поместите степень сложности реализации данной функции. Это естественное развитие списка Действующее лицо/Цель (см. раздел 3.1).

В книге Extreme Programming Explained: Embrace Change (l 999) есть хорошая вариация на эту тему: разработчики оценивают стоимость разработки, в то время как заказчики решают, какой приоритет присвоить камедому варианту использования. Заказчики имеют возможность изменить приоритеты, посмотрев, как оценена работа, но не могут изменить оценки. В свете этой идеи вы можете заполнить столбцы таблицы планирования в два этапа.

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

Вы можете проанализировать эту таблицу и манипулировать ею в процессе проектирования.

Таблица 17.1. Пример таблицы планирования

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

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

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

■ Список названий обеспечивает структуру для работы с учетом приоритета разработки и временных рамок.

■ Невымышленная история.

Разработчик должен был решить, какие бизнес-процессы поддерживать в следующих версиях программного продукта. Он выдал список Действующее лицо/Цель на 7 страницах! Сметная стоимость, сложность, триггер и прочее. При участии руководителя проекта список был урезан до половины странички. Затем разработчик написал основной сценарий для этих бизнес-процессов и вместе с руководителем проекта сократил перечень шагов, чтобы проанализировать примерно полстраницы целей уровня системы. С этой информацией разработчик посетил филиалы компании. После этого у него сложилась ясная картина того, какие части бизнес-процессов наиболее разумно адресовать работникам филиалов. Разработчик и заказчик наметили подготовить в течение полугода четыре варианта использования.

Управление пересекающимися версиями вариантов использования.

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

Такой вариант использования, как Заказать товар, выявляет все виды специальной обработки, которая может быть предоставлена со временем. Типичная поэтапная стратегия:.

■ Реализовать простой случай в версии 1.

■ Добавить управление рисками в версии 2.

■ Реализовать предпочтительную для клиента обработку в версии 3.

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

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

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

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

Вам придется выбрать методику работы, учитывая, что каждая имеет недостатки.

Имейте в виду, что все подходы предполагают, что организация использует поэтапную (итерационную) разработку и сдачу системы с этапами длительностью до четырех месяцев. Итерационная разработка стала стандартной в современном проектировании программного обеспечения и подробно обсуждается в моей книге Surviving Object Oriented Projects (1998) и в статье VW Staging (https://тетbers.aol.com/acockburn/papers/vwstage.htm).

Реализация полных сценариев.

■ Невымышленная история.

Менеджер по тестированию и интеграции очень большого проекта расспрашивал меня об опасностях итерационной разработки. Оказалось, что группа разрабатывала и сдавала приложение, используя наборы функций (features), а не варианты использования. Его группа не могла тестировать эти куски, так как они не поддерживали никакого "сюжета", представляя собой кучу алгоритмов. В конце концов руководители проекта перестроили план так, чтобы результатом работы на каждом этапе была приемлемая сюжетная линия.

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

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

Это кажется тривиальным, но если это проигнорировать, возможен ущерб, как показывает вышеприведенная история.

17.2. Варианты использования и списки задач или функций.

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

Для иллюстрации приведу следующее электронное письмо от коллеги.

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

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

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

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

Это основное противоречие между поведением системы, описанным в вариантах использования, и задачами проектирования, которые ставятся перед отдельным разработчиком. Разработчик трудится над одним элементом строки или функцией, определенной в глубине одного варианта использования, или, возможно, проходящей через несколько вариантов использования. Это могут быть алгоритмы “отменить” (Undo), “регистрация транзакций в журнале” (Transaction Logging) или “структура экрана поиска” (Search Screen Framework). Разработчики не могут описывать свою работу на языке вариантов использования, поскольку они не имеют дела с поведением системы. В лучшем случае разработчик скажет, что он работает над частью варианта использования 5, посвященной структуре экрана поиска.

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

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

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

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

Вариант использования 34 О Зафиксировать встречную продажу кз>.

Цель в контексте: у покупателя есть тележка с товарами и он хочет произвести встречную продажу, чтобы посмотреть, как это повлияет на стоимость.

Область действия: программная система торговли Уровень: подфункция.

Предусловия: тележка должна содержать товар (товары).

Гарантии успеха: встречная продажа оценена, добавлена к товарам.

в тележке, стоимость товаров в тележке сокращена.

Минимальная гарантия: если цель не достигнута, встречная продажа не.

фиксируется и не добавляется к содержимому тележки.

Основное действующее лицо: покупатель (любой пользователь Сети).

Триггер: покупатель решает зафиксировать встречную продажу.

Основной сценарий:.

1.

Покупатель решает зафиксировать встречную продажу.

2.

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

3.

Система регистрирует навигационную информацию и информацию о встречной продаже в рабочем порядке.

4.

Покупатель просматривает и анализирует сводку и стоимость встречной продажи.

5.

Покупатель добавляет ее к тележке.

6.

Система добавляет к тележке встречную продажу и навигационную информацию.

7.

Система показывает обзор тележки со всеми ее товарами и встречной продажей, а также пересчет общей стоимости с учетом встречной продажи (продаж).

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

Расширения:.

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

5а. Покупатель решает не добавлять встречную продажу к тележке; система сохраняет навигационную информацию на будущее.

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

Таблица 17.2 представляет сформированный список работ.

Таблица 17.2. Список работ для фиксации встречной продажи

17.3. Варианты использования и проектирование.

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

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

Переход от вариантов использования к проектированию имеет как хорошие, так и плохие стороны. Плохо то, что:.

■ В проекте отсутствует группирование по вариантам использования.

■ Слепое следование структуре варианта использования ведет к проектам функциональной декомпозиции (это реально касается тех команд разработчиков, которые занимаются объектно-ориентированным и компонентным проектированием).

Хорошо то, что:.

■ Некоторые методы проектирования используют преимущества всех сценариев.

■ Варианты использования выявляют понятия, необходимые при моделировании предметной области.

Рассмотрим сначала недостатки.

В ПРОЕКТЕ ОТСУТСТВУЕТ ГРУППИРОВАНИЕ ПО ВАРИАНТАМ ИСПОЛЬЗОВАНИЯ. Задачи проектирования не отображаются точно в единицы вариантов использования. Задача проектирования приводит в результате к бизнес-объекту или к механизму поведения, который будет применяться в нескольких вариантах использования. Вариант использования, который планируется выпустить в более поздний срок, вероятно, будет содержать важную информацию для задачи проектирования, выполненной ранее. Это означает, что когда к разработчикам поступит эта информация, им придется изменять проект в более поздних версиях.

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

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

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

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

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

■ Невымышленная история.

Эта мысль пришла в голову во время работы над одним проектом, когда руководитель группы пожаловался, что ему не позволили "завершить" классы после 20-процентной отметки готовности, хотя разработанное приложение выполняло все, что хотел пользователь! Нам потребовалось много времени, чтобы понять, что он говорил с точки зрения культуры проектирования баз данных, а работал над проектом, где применялся метод итерационной разработки.

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

ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ И ФУНКЦИОНАЛЬНАЯ ДЕКОМПОЗИЦИЯ. Если вы при меняете методы структурной декомпозиции, будет полезна функциональная декомпозиция в вариантах использования. Однако если вы занимаетесь объектно-ориентированным проектированием, примите во внимание следующее.

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

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

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

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

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

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

Противоположная опасность подстерегает специалистов по объектно-ориентированному проектированию, которым требуется моделировать предметную область непосредственно, не заботясь о функциях, которые необходимо поддерживать. Эти разработчики упускают из вида роль функциональных требований. Варианты использования указывают тому, кто моделирует предметную область, какие аспекты представляют интерес для анализа. Без этой информации потребуется слишком миого времени для моделирования частей предметной области, не существенных для данной системы. Варианты использования обеспечивают граничные условия надежного и полного моделирования (подробнее см. в статье Ап Open Letter to Newcomers to 00,

).

Ясно, что во всех случаях варианты использования и объекты разделяют среду на различные организующие схемы. Имейте это в виду при проектировании.

Теперь перейдем к преимуществам.

ПРОЕКТЫ ПОЛЬЗУЮТСЯ СЦЕНАРИЯМИ. Варианты использования служат легкодоступными сценариями при проектировании программы. Они особенно полезны при проектировании на основе обязанностей’ (Responsibility-Driven Design), когда проектирование осуществляется в соответствии с шагами сценария. Варианты использования также весьма полезны при других методах проектирования, показывая, когда проектирование завершено, и обрабатывая все ситуации (расширения).

ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ ВЫЯВЛЯЮТ ПОНЯТИЯ ПРЕДМЕТНОЙ ОБЛАСТИ. Варианты использования довольно четко называют имена объектов предметной области. Рассмотрим фразу варианта использования:.

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

добавляет налог и стоимость доставки и подсчитывает сумму. Нижний.

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

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

17.4. Варианты использования и проектирование интерфейса пользователя.

В книгах Software for Use и GUIs with Glue вопросы проектирования интерфейса пользователя изложены Лучше, чем это могу сделать я. Однако при написании вариантов использования большинство проектных групп спрашивает, как осуществить переход от вариантов использования без интерфейса пользователя к действительному проектированию интерфейса пользователя.

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

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

Хотя описание интерфейса пользователя не предназначено для документа о требованиях, полезно расширить документ примерами проектирования интерфейса пользователя. Такая информация по проектированию может улучшить восприятие документа о требованиях, так как дает и текстуальное (абстрактное), и визуальное (конкретное) описание поведения системы.

Проект интерфейса пользователя имеет три уровня точности (низкий, средний и высокий):.

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

■ Описание интерфейса пользователя средней точности — это рисунок или уменьшенный снимок экрана. Поместите его в конце варианта использования, чтобы читатели могли и читать о предлагаемом проекте, и видеть его.

■ Описание высокой точности перечисляеттипы, длину и проверки всех полей для каждого экрана и никак не соответствует документу о требованиях.

17.5. Варианты использования и тестовые варианты.

Варианты использования обеспечивают готовое описание функционального теста системы. Большинство тестировщиков приветствует работу с вариантами использования. Ведь они впервые получают что-то, с чем так легко работать. Более того, этот комплект тестов предоставляется им как раз во время сбора требований! Лучше всего, если они помогают писать варианты использования.

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

Все это обычно касается команды тестирования. Таблицы 17.3 и 17.4 предоставлены Питом Мак-Брином (

Cases.html). Первым идет вариант использования, а затем — набор тестов приемки. Я оставляю этот пример вашей команде тестирования. Проанализируйте его для совершенствования навыков работы.

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

Вариант использования 35 9 Заказать товары, сформировать счет (пример тестирования) ЗА.

Контекст: клиент размещает заказ на товары, счет формируется и отправляется вместе с заказанными товарами.

Минимальные гарантии:.

В случае неудачи товары не будут выделены клиенту, учетная информация клиента останется неизменной и попытка транзакции будет записана в журнал.

Гарантии успеха:.

Товары будут выделены клиенту.

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

Список выбора будет отослан для распределения.

Основной сценарий:.

1. Клиент выбирает товары и указывает их количество.

2.

Система выделяет для клиента требуемое количество каждого товара.

3.

Система добывает заверенное разрешение на выписку счета.

4.

Клиент указывает место доставки.

5.

Система посылает инструкции по выбору товаров для распределения. Расширения:.

2а. Количество товара на складе не достаточно для выполнения заказа:.

2а 1. Клиент отменяет заказ.

2Ь. Товара нет на складе:.

2Ы. Клиент отменяет заказ.

За. Высокий кредитный риск у клиента (используйте тест приемки для этого исключительного состояния).

4а. Неправильное место доставки: ??.

Для каждого расширения, приведенного выше, необходим по крайней мере один тестовый пример. Для полного тестирования нужно больше тестов для разных наборов значений данных. Тест основного сценария (таблицы 17.3 и 17.4) следует прогонять первым, поскольку полезно показать, как работает система в полном объеме. Часто его можно создать прежде, чем станут известны все условия расширения и пути восстановления.

Таблица 17.3. Тесты основного сценария (низкий кредитный риск)

Таблица 17.4. Тесты основного сценария (высокий кредитный риск)

17.6. Реальное создание вариантов использования.

Вашей группе придется освоить определенные навыки работы. В следующем разделе показан процесс ветвления и соединения (branch-and-join), который является моим излюбленным способом работы. Энди Краус из IBM описывает с удивительной ясностью опыт своей команды по координации работы большой разнородной группы пользователей. Весьма полезно почитать его отчет и поучиться.

Процесс ветвления и соединения.

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

1.

Сформировать описание системной функции низкой точности:.

• Согласовать описание использования в свободной форме (группа).

• Согласовать область действия и выявить путем “мозгового штурма” действующих лиц и цели (группа).

• Разработать описания (раздельно).

• Объединить описания (группа).

2.

Сформировать представление высокой точности в виде вариантов использования:.

• Создать варианты использования методом “мозгового штурма” (группа).

• Согласовать форму варианта использования (группа).

• Написать варианты использования (раздельно).

• Просмотреть варианты использования (раздельно).

• Просмотреть варианты использования (группа).

Этап 1. Сформировать представление системной функции низкой ТОЧНОСТИ.

Этап 1 выполняется за четыре цикла.

ЦИКЛ 1.1. СОГЛАСОВАТЬ СТИЛЬ ОПИСАНИЯ ИСПОЛЬЗОВАНИЯ (ГРУППА). Члены команды вместе изучают описание (см. раздел 1.6). Каждый член команды пишет один документ, возможно, все документы на одну тему. Затем группа читает и обсуждает написанное, чтобы выработать общий взгляд на то, как должно выглядеть приличное описание, каков его объем и какие подробности оно должно содержать. Это может занять несколько часов. В конце цикла команда получает конкретное представление о том, что проектируется (или его части).

ЦИКЛ 1.2. СОГЛАСОВАТЬ ОБЛАСТЬ ДЕЙСТВИЯ И ВЫЯВИТЬ ПУТЕМ "МОЗГОВОГО ШТУРМА" ДЕЙСТВУЮЩИХ ЛИЦ И ЦЕЛИ (ГРУППА). Группа тратит столько времени, сколько нужно, для выявления общей цели, области действия и основных действующих лиц системы. Сотрудники составляют концептуальное изложение, список ввода/вывода, диаграмму области действия проектирования, список основных действующих лиц и участников, а также список важнейших начальных наборов целей пользователей. Каждый из этих элементов касается других, поэтому обсуждение одного влияет на восприятие других. Таким образом, все элементы создаются одновременно. Если группа знает, что она собирается проектировать, это может занять от нескольких часов до одного дня. Если пока не знает, может потребоваться несколько дней. В итоге достигается согласие относительно предмета обсуждения, того, что надо создавать и состава основных действующих лиц.

ЦИКЛ 1.3. РАЗРАБОТАТЬ ОПИСАНИЯ (РАЗДЕЛЬНО). Группа разделяется, чтобы создать описания использования для выбранных функций разрабатываемой системы. Члены группы работают индивидуально и потом обмениваются документами. Затем они предоставляют результаты на суд группы в полном составе.

ЦИКЛ 1.4. ОБЪЕДИНИТЬ ОПИСАНИЯ (ГРУППА). Команда собирается для обсуждения содержания (не стиля) описаний. Задается вопрос: “Это действительно пример того, что мы хотим построить?” Может состояться еще одна дискуссия о природе системы и пройти еще один цикл создания описания, пока члены группы не решат, что описание отражает их взгляды на систему.

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

■ Концепция системы.

■ Список того, что лежит в функциональной области действия, области действия проектирования и вне их.

■ Диаграмма системы в ее окружении.

■ Список ключевых основных действующих лиц.

■ Список участников системы и их основных интересов.

■ Список наиболее важных целей пользователей.

■ Набор описаний (каждое менее, чем в полстраницы).

Этап 2. Сформировать представление высокой точности в виде вариантов использования.

Этап 2 выполняется за пять циклов.

ЦИКЛ 2.1. “МОЗГОВОЙ ШТУРМ" с ЦЕЛЬЮ СОЗДАНИЯ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (ГРУППА). В первом цикле создается более точный список вариантов использования, которые следует написать. Группа использует облегченные методы анализа, “мозгового штурма” и выявления всех основных действующих лиц, которые могут встретиться системе на протяжении ее жизненного цикла. Затем группа методом “мозгового штурма” создает список всех целей пользователей, которые только можно вообразить, для всех основных действующих лиц. Для этой работы группа может разделиться на подгруппы.

Полезная практика для больших разнородных групп — разделиться на рабочие группы по 3-5 человек. Обычно существует несколько предметных областей или групп по интересам, знания которых необходимо объединить, чтобы рабочие группы имели по одному специалисту в каждой области. Каждая группа обладает всеми необходимыми знаниями для решения задач, и каждый специалист имеет возможность высказаться. Небольшая группа способна продвигаться быстрее, чем крупная. Разделение основной группы на несколько маленьких групп означает, что за одно и тоже время охватывается большая область.

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

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

ЦИКЛ 2.2. СОГЛАСОВАТЬ ФОРМУ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (ГРУППА). Этот цикл начинается с написания группой варианта использования. Можно писать индивидуально, а потом сдать личные версии в группу. Члены группы обсуждают уровень и стиль изложения, шаблон, участников и интересы, минимальные гарантии и пр. По окончании сеанса группа имеет начальную версию стандарта вариантов использования.

ЦИКЛ 2.3. НАПИСАТЬ ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ (РАЗДЕЛЬНО). В этом цикле группа реорганизуется в подгруппы по специализации, возможно, по 2-4 человека на подгруппу. Для каждой специализированной подгруппы отбираются варианты использования.

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

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

ЦИКЛ 2.4. АНАЛИЗ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (РАЗДЕЛЬНО). Писатели пускают по кругу черновики, электронные или написанные на бумаге. Интересно, что бумажный вариант имеет своеобразное преимущество: можно собрать комментарии каждого читателя, и автор за один редакторский проход варианта использования учтет все предложения. В одной группе рассказывали, что когда они пытались работать с замечаниями в режиме реального времени, им пришлось сделать намного больше проходов — сначала редактируя текст, чтобы реализовать предложение одного лица, затем аннулируя это изменение, чтобы учесть предложение другого. В любом случае, экспертная группа должна проверить уровень цели вариантов использования и бизнес-правила внутри них.

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

ЦИКЛ 2.5. АНАЛИЗ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (ГРУППА). Наконец, проводится групповой анализ, на котором присутствуют разработчики программного обеспечения, эксперты по бизнесу, эксперты по использованию и разработчики интерфейса пользователя. То, что происходит после того, как создатели вариантов использования закончили свой лучший черновик, зависит от проекта, его политики и механизма анализа. Писатели должны быть уверены, что шаги понятны, правильны и достаточно детализированы для реализации. Это можно сделать с помощью официальных и неофициальных просмотров, просмотров пользователей или просмотров разработчика.

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

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

■ Назвать все условия расширения.

■ Продумать политику, связанную с обработкой ошибок.

■ Удостовериться, что интересы участников соблюдены.

■ Удостовериться, что все названия вариантов использования являются только действительными требованиями.

■ Обеспечить, чтобы каждый вариант использования был читабельнымдля пользователей или экспертов по использованию и достаточно ясным, чтобы разработчики знали, что реализовывать.

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

Я считаю, что на черновик варианта использования требуется несколько часов, и несколько дней уйдет на продумывание обработки расширений. Одна группа из десяти человек выдала 140 кратких описаний вариантов использования за неделю (2,8 кратких описаний вариантов использования на человека в день) и затем потратила еще четыре недели, работая над ними и добавляя новые требования. Это увеличило время на один вариант использования и связанные с ним расширения до двух рабочих недель. Группа, работающая над разными проектами, затрачивала на один вариант использования в среднем 3-5 рабочих недель. Окончательные варианты использования были исключительно высокого качества.

Как создать варианты использования, работая с большими группами.

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

■ Энди Краус.

Как создать варианты использования, работая с большой разнородной непрофессиональной группой.

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

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

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

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

Плывите в одной лодке с руководством. Административное лицо вместе с руководителем проекта присутствовало на различных стадиях процесса сбора информации.

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

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

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

Нужен секретарь. Важность быстрой аккуратной записи трудно переоценить... У нас было несколько секретарей, работавщих на ранних сеансах и доказавших свою бесценность...

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

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

Приложению все равно, кто вы такой; важно, какую шляпу вы носите. Поняв, что исполнение роли действующего лица в компьютерной системе похоже на "ношение шляпы", мы купили бейсбольные кепки и на каждой вышили имя действующего лица. На следующем сеансе кепки были выложены в ряд на столе организатора. Как только началась работа над вариантом использования, организатор взял кепку с надписью "Задающий вопросы" и надел ее на голову. Результаты были весьма благоприятны. Пользователи поняли, что не имеет значения, как называется их работа. Когда они используют систему, они носят определенную "шляпу" (играют определенную роль).

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

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

Не надейтесь получать варианты использования в больших количествах. Как любая творческая деятельность, процесс создания вариантов использования имеет подъемы и спады. Попытки торопить творческий процесс не приносят успеха.

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

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

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

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

Будьте минималистом. Сохраняйте свой шаблон варианта использования в минимальном объеме.