Часть II. Технологии быстрого тестирования и советы. Строка названия темы должна совпадать с заглавным листом, помещенным на стенку

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

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

в самих плакатах не допускаются.

• Совершенная поддержка - " Наклейки"

- Полезный критицизм

- Полнота

- Четкость изложения

- Допустимая сложность

- Избыточность

- Накопление

- Классификация/определение приоритетов

Рис. 8.3. Механизмы совершенной поддержки.

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

модействовать с группой пользователей или с экспертами по исходным материалам. Такие ситуации отражаются в следующем списке:

• Организация работы рабочей группы управления взаимодействием

• Организация работы рабочей группы технического управления

• Выполнение промежуточных пересмотров программы

• Работа с опросными листами, интервью, эксплуатационными сценариями, по­ лученными от конечных пользователей (случаи использования на языке UML)

• Создание прототипов и моделей

• Наблюдение за существующей системой, средами и конфигурациями техноло­ гических процессов

• Принятие или заимствование решений и осуществление последующего выбора

• Альфа-тестирование

• Бета-тестирование

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

ПРИМЕР: УСПЕШНАЯ РАЗРАБОТКА JAR (ГЭРИ КОББ (GARY COBB))

Несколько лет назад мне довелось столкнуться с разработкой очень важного проекта по электроиной торговле, календарный план которого был очень плотным. Этот проект был явным кандидатом на применение технологий быстрого тестирования. Основная задача формулировалась как быстрая разработка интерфейса программирования приложений (API) между системой заказов товаров по Internet и стандартной системой размещения заказов компании. Выделенные руководством денежные средства предполагали ведение разработки шестью разработчиками, включая руководителя/ведущего разработчика, в течение 3 месяцев. Руководитель проекта выделил б недель из 16-недельного календар­ ного плана на документирование требований и поручил эту работу двум разработчикам, в то время как остальные должны были приступить к созданию прототипа API. Тогда я выступил с заявлением, что если бы в проекте был использован процесс JAR, то я смог бы предоставить полностью протестированный документ описания требований за 2 неде­ ли — на целый месяц раньше планового срока. При этом в нем были бы полностью уч­ тены пожелания пользователей, и было бы меньше ошибок, чем при выполнении 6-

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

В четверг руководитель проекта и его подчиненные согласились принять мое предложе­ ние по применению JAR, и пятницу я начал с проведения вводного собрания, во время которого группа составила список из 28 экспертов по исходным материалам. Во время вводного собрания было выбрано также рабочее помещение, а четыре наиболее знаю­ щих эксперта были рекомендованы как члены команды на следующую неделю (еже­ дневно с 8: 00 до 17: 00). Были расписаны также часы бесед с остальными 24-мя экспер­ тами (12 бесед с двумя экспертами ежедневно, с понедельника по среду следующей недели)

180 Часть II. Технологии быстрого тестирования и советы

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

Утром в понедельник члены комиссии мучались над созданием плакатов для ряда фун­ даментальных требований. Ряд споров велось по поводу элементов архитектуры систе­ мы, эксплуатационных характеристик и применимости, производительности и требований к внешним коммуникациям. Затем после полудня состоялись два первых интервью с экспертами по исходным материалам. По завершении интервью, во вторник состоялась первая половина заседания по совершенной поддержке. В результате вся стена окраси­ лась в розовый закатный цвет, поскольку председатель располагал только розовыми на­ клейками. До проведения первого интервью с экспертом по исходным материалам в среду авторы плакатов обработали поставленные вопросы и стена вновь стала белой. За вторую половину среды, в процессе подготовки к первому рабочему заседанию, кото­ рое должно было состояться в четверг, сеанс совершенной поддержки был завершен, и члены комиссии сложили часть плакатов под поручнями кресел, тем самым признав, что эти требования имеют более низкий приоритет и должны быть выполнены позже. Одно­ временно один из членов комиссии завершил уточнение глоссария. В полдень четверга двум менеджерам было предложено оставить свои замечания на стене с пустыми розо- ' выми наклейками. Члены комиссии были весьма горды похвальными отзывами, остав-ленными обоими менеджерами.

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

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

Наиболее примечательное замечание, впоследствии услышанное мною от одного из об­ работчиков заказов, звучало так: " После получения программы члены этой команды разработчиков учили нас выполнять работу с помощью данного программного обеспе-чения, но даже сами разработчики не смогли заставить программу работать во время обучения. Когда они поставили программу, мы и сами знали, как ее использовать, по-скольку она полностью соответствовала нашим потребностям. Удивляло лишь то, что в программе было очень мало ошибок, и что на всех этапах поставка выполнялась точно по графику." Отойдя в сторону, я сказал себе: " Да! Вот вам результат одновременного выполнения разработки и тестирования! " Иначе говоря, таков результат быстрого тести-рование в действии.