Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

возможные технические приемы. Прототипы позволяют на рабочих

образцах

показать,

насколько осуществимы требования;

1 создание конечного продукта. Используемый в качестве инстру-

мента разработки прототип — не что иное, как функциональная реа-

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

в готовый продукт, осуществляя последовательную цепочку неболь-

ших циклов разработки.

Основная цель создания прототипа — устранение неясностей на

ранних стадиях процесса разработки. Именно исходя из них следует

решать, для каких частей системы необходим прототип и что вы надее-

тесь выяснить, оценивая его. Прототип полезен для выявления и

устра-

нения двусмысленных и неполных утверждений в требованиях. Пользо-

ватели, менеджеры и другие заинтересованные в проекте лица, не об-

ладающие техническими знаниями, считают, что прототип дает им

понимание некой

конкретики,

пока реальный продукт документируется

и разрабатывается. Прототипы, особенно наглядные, легче понять, чем

технический жаргон

разработчиков.

Горизонтальные прототипы

Когда люди говорят «прототип

ПО»,

они обычно имеют в виду горизон-

тальный

прототип (horizontal prototype) предполагаемого интерфейса

пользователя. Его также именуют поведенческим прототипом (behav-

ioral prototype) или моделью. Горизонтальным прототип

называется

потому, что в нем не реализуются все слои архитектуры и нюансы сис-

темы, но воплощаются некоторые особенности интерфейса

пользова-

теля. Он позволяет пользователям исследовать поведение предпола-

гаемой системы в тех или иных ситуациях для уточнения требований, а

также выяснить, смогут ли они с помощью системы, основанной на

прототипе, выполнять свою работу.

Горизонтальный прототип, подобно кинофильму, создает види-

мость функциональности, не обеспечивая ее действительного вопло-

щения. Он показывает внешний видэкранов пользовательского интер-

фейса и позволяет осуществлять частичную навигацию между ними,

но не содержит никакой или почти никакой действительной функцио-

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

выходит из конюшни,

но

он не заказывает выпивку и не видит лошадей,

потому что за фасадами декораций ничего нет.

Горизонтальные прототипы демонстрируют функциональные воз-

можности, которые будут доступны пользователю, внешний вид поль-

Глава 13. Прототипы как средство

уменьшения

риска

;'55

зовательского

интерфейса

{цвета,

планировку, графику, элементы

управления) и структуру доступа к информации (структуру навигации).

Перемещение между

объектами

интерфейса возможно, но вместо не-

которых элементов пользователь увидит лишь краткое сообщение о

том, что будет здесь находиться.

Информация,

появляющаяся в ответ

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

постоянной,

а со-

держание отчетов — жестко

закодированным.

Старайтесь использо-

вать реальные данные в образцах отчетов, диаграмм и

таблиц—

это

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

Горизонтальный прототип не выполняет полезной работы, хотя ино-

гда и кажется, что должен. Зачастую имитации вполне

достаточно,

что-

бы пользователи могли решить, нет ли каких-либо упущений, невер-

ных или ненужных функций. Некоторые прототипы выражают концеп-

цию реализации конкретных вариантов использования, как ее видят

разработчики. Оценивая

прототип,

пользователи могут указать на аль-

тернативные возможности их реализации, пропущенные шаги взаимо-

действия или дополнительные условия исключений.

Работая с горизонтальным прототипом, пользователь должен кон-

центрироваться на общих требованиях и последовательности выпол-

няемых действий, не отвлекаясь на особенности внешнего вида эле-

ментов экрана (Constantine,

1998).

На этой стадии не беспокойтесь о

точном расположении элементов экрана, шрифтах, цветах, рисунках и

элементах управления. Время детализации интерфейса пользователя

наступит после того, как прояснятся требования к системе и будет оп-

ределена общая структура интерфейса.

Вертикальные прототипы

Вертикальный прототип (vertical prototype), также называемый структур-

ным

прототипом

(structural prototype) или проверкой

концепции,

вопло-

щает срез функциональности приложения от интерфейса пользователя

до сервисных функций. Вертикальный прототип действует как настоящая

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

вайте вертикальный прототип всякий раз, когда сомневаетесь в осущест-

вимости и стабильности предполагаемого подхода к архитектуре системы

или когда хотите оптимизировать алгоритмы, оценить предлагаемую

схему базы данных или проверить критически важные временные требо-

вания. Чтобы получить значимые результаты, вертикальные прототипы

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

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

256 Часть II. Разработка требований к ПО

критически важных требований к интерфейсу и времени исполнения, а

также для сокращения рисков на стадии проектирования системы.

Однажды я работал с командой, которая занималась реализацией

необычной клиент-серверной архитектуры для стратегии перехода от

мэйнфрейм-системы к программной среде, основанной на серверах и

рабочих станциях, работающих под UNIX и объединенных в сеть

(Thompson и Wiegers, 1995). Вертикальный прототип, реализовавший

небольшую часть клиента пользовательского интерфейса (на мэйн-

фрейме) и соответствующую часть функциональности сервера (на ра-

бочей станции под UNIX), позволил нам оценить коммуникационные

компоненты, производительность и надежность предлагаемой ар>и-

тектуры.

Эксперимент прошел успешно, как и построение решения на

основе этой архитектуры.

Одноразовые прототипы

Прежде чем создавать прототип, примите четкое и ясное решение,

прекратите ли вы работать с ним после оценки или сделаете его частью

выпускаемого продукта. Создайте одноразовый прототип

(throwaway

prototype), или исследовательский прототип (exploratory

prototype),

чтобы ответить на вопросы, разрешить неясности и улучшить

требова-

ния

к ПО (Davis, 1993). Если вы решили, что после выполнения

задачи

прекратите работу с

прототипом*,

стройте его как можно более быстро

и дешево. Чем больше усилий вы вложите в прототип, тем труднее бу-

дет участникам проекта отказаться от него,

Создавая одноразовый прототип, разработчики пренебрегают

боль-

шинством известных им методов конструирования качественного ПО. В

одноразовом прототипе предпочтение отдается быстроте реализации

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

долговременному удобству сопровождения. Поэтому внимательно сле-

дите, чтобы низкокачественный код одноразового прототипа не попал в

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

технического обслуживания будут страдать от последствий этого в те-

чение всего срока эксплуатации продукта.

* Не стоит уничтожать прототип, если возможно его повторное применение в будущем.

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

нереализуемый прототип.

Глава 13. Прототипы как средство

уменьшения

риска

,57

Одноразовый прототип наиболее уместен, когда команда разработ-

чиков сталкивается с неизвестностью,

двусмысленностью,

неполно-

той или неопределенностью в требованиях к ПО. Разрешение этих

вопросов уменьшает риск продолжения разработки. Прототип, помо-

гающий пользователям и разработчикам визуально представить реа-

лизацию требований, позволяет выявить пробелы в документации, а

также решить, годятся ли требования для создания продукта, поддер-

живающего необходимые бизнес-процессы.

Ловушка Не делайте прототип более сложным, чем это необходимо для целей

его создания. Не поддавайтесь искушению - или давлению

пользователей

- доба-

вить в прототип больше функций.

На рис. 13-1 показана последовательность шагов разработки от ва-

риантов использования до детализированного проекта интерфейса

пользователя через построение одноразового прототипа. Каждое опи-

сание варианта использования включает последовательность дейст-

вий субъекта и реакцию системы, которые вы можете смоделировать

посредством схемы диалогов, чтобы отразить особенности архитек-

туры интерфейса пользователя. Одноразовый прототип представляет

элементы диалога в виде экранов, меню и диалоговых окон. Когда его

оценивают пользователи, возможны изменения в описании вариантов

использования (если, например, обнаруживается альтернативный

путь) или изменения в карте диалогов. Каждый раз, когда требования

уточняются и создаются наброски экранов, элементы интерфейса

пользователя оптимизируется для удобства и простоты использова-

ния. Такой метод постепенного уточнения обходится дешевле, чем ес-

ли вы скакнете прямо от описаний вариантов использования к закон-

ченному интерфейсу пользователя, а потом обнаружите серьезные

проблемы в требованиях, исправление которых потребует глобальной

переделки продукта.

Описание

варианта

использования

~А

Карта диалогов

обратная

связь

1 1

Одноразовый

прототип

обратная связь

Детализированный

дизайн

пользовательского

интерфейса

Рис.

13-1.

Последовательность действий от вариантов использования к дизайну

интерфейса пользователя через одноразовый прототип

258 Часть II. Разработка требований к ПО

Эволюционные прототипы

В отличие от одноразового прототипа, эволюционный прототип (evolu-

tionary prototype) представляет собой прочный архитектурный «фунда-

мент»

для постепенного создания окончательного продукта — по

мере

прояснения требований. Эволюционное

прототипирование

— один

из

компонентов модели спирального цикла разработки ПО

(Boehm,

1988)

и некоторых процессов разработки объектно-ориентированного ПО

(Kruchten,

1996). В отличие от одноразовых прототипов,

создаваемы*

«быстро и начерно», для построения эволюционного прототипа необ-

ходимо с самого начала использовать отличный и качественный код.

Поэтому на конструирование эволюционного прототипа

требуется

больше времени, чем на одноразовый прототип, моделирующий те же

свойства системы. Эволюционный прототип следует создавать в рас-

чете на легкий рост и частое расширение, поэтому

разработчики

должны уделять большое внимание архитектуре и принципам проек-

тирования. При создании такого прототипа ни в коем случае не стоит

экономить на качестве.

Считайте первый цикл в создании эволюционного прототипа проб-

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

требований. Уроки, извлеченные из реакции пользователей на

тести-

рование и первоначальное использование продукта, учитываются при

модификации в следующем цикле. Окончательный продукт — это куль-

минация серии эволюционных прототипов. Такие прототипы позволя-

ют пользователям быстро получить действующие образцы. Эволю-

ционные прототипы хорошо подходят для приложений, которые, как

вы знаете, со временем будут расширяться; к ним относятся, напри-

мер, проекты постепенной интеграции различных информационных

систем.

Эволюционное прототипирование годится и для проектов разра-

ботки Интернет-приложений. В одном из таких проектов, которым я

руководил, моя команда создала серию из четырех прототипов на ос-

нове требований, полученных в результате анализа вариантов исполь-

зования. Каждый прототип оценивали несколько пользователей, и мы

вносили изменения на основе их ответов на наши вопросы. Исправле-

ния, которые мы внесли после оценки четвертого прототипа, стали

окончательным вариантом нашего Интернет-сайта.

На рис. 13-2 показано несколько способов комбинирования раз-

личных видов прототипирования. Например, информацию, получен-

ную в результате выполнения серии одноразовых прототипов, вы мо-

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

Глава 13. Прототипы как средство уменьшения риска 259

шагом реализовать через последовательность эволюционных

прото-

типов. Другой способ, показанный на рис. 13-2, — применение гори-

зонтального одноразового прототипа для прояснения требований пе-

ред разработкой окончательной версии дизайна пользовательского

интерфейса, в то время как одновременно с помощью вертикального

прототипирования проверяется архитектура системы, компоненты

приложения и алгоритмы ядра. Что вам совершенно точно не удастся

так это превратить намеренно низкокачественный одноразовый прото-

тип в удобный для сопровождения выверенный код, необходимый для

построения окончательной системы. Кроме того, рабочие прототипы,

которые демонстрируют возможности продукта нескольким

пользова-

телям, привлекаемым к разработке

системы,

скорее всего нельзя мас-

штабировать для тысяч пользователей без серьезных архитектурных

изменений. Втабл. 13-1 суммированы некоторые стандартные вариан-

ты применения одноразовых, эволюционных, горизонтальных и верти-

кальных прототипов.

Разработка

одноразового

горизонтального

прототипа

Рис.

13-2.

Несколько возможных способов использования прототипов

а процессе разработки ПО

260

Часть II. Разработка требований к ПО

Таблица

13-1.

Стандартные способы применения прототипов ПО

Одноразовые

Эволюционные

Горизонтальные

Вертикальные

Прояснение и уточнение

примеров использования

и функциональных

требова-

ний

Выявление пропущенных

функций

Исследование возможных

вариантов интерфейса

пользователя

Демонстрация технической

осуществимости

Реализация базовых вариантов

использования

Реализация дополнительных

вариантов использования

по приоритетам

Реализация и доработка

Web-сайтов

Адаптация системы к быстро ме-

няющимся требованиям бизнеса

Реализация и наращивание ключе-

вой клиент-серверной функцио-

нальности и уровней

коммуникации

Реализация и оптимизация основ-

ных алгоритмов

Тестирование и настройка

произво-

дительности

Бумажные и электронные прототипы

Не всегда для разрешения неопределенностей в требованиях нужен

прототип в виде исполняемого кода. Бумажный прототип

(paper

proto-

type),

иногда его называют низкокачественным прототипом, — это де-

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

выглядеть

некий фрагмент системы

(Rettig,

1994;

Hohmann, 1997). Бу-

мажные прототипы помогают установить, действительно ли пользова-

тели и разработчики одинаково понимают требования. Они

позволяют

вам попробовать, практически не рискуя, сделать шаг при

разработке

кода продукта. Похожий метод, называемый методом

раскадровки

(storyboard)

(Leffingwell

и Widrig, 2000), показывает предлагаемый ин-

терфейс пользователя, без привлечения пользователей к работе с ним.

Для создания бумажных прототипов требуются инструменты не слож-

нее, чем бумага, учетные карточки, наклейки и чистые пластиковые

про-

зрачки. Проектировщик делает наброски экранов, как он их представля-

ет, не заботясь о

том,

где точно будут

располагаться

элементы управле-

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

своим мнением, в результате чего возможны глубокие

изменения—

но

на листе бумаги. В некоторых случаях, однако, они не склонны критико-

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

Глава 13. Прототипы как средство уменьшения риска

261

по всей видимости, вложил много труда. Разработчики также иногда

противятся внесению существенных изменений в тщательно выполнен-

ный электронный прототип.

При применении низкокачественного прототипа человек играет

роль компьютера, пока длится оценочный сценарий. Он инициирует

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

экране: «Я хочу выбрать команду Предварительный просмотр из меню

Файл». При этом пользователь показывает страницу или учетную кар-

точку, представляющую экран, который должен появиться после вы-

полнения действия. Это позволяет оценить, соответствует ли ответ

ожидаемому и содержит ли экран необходимые элементы. Если нет, вы

просто берете чистый лист бумаги или карточку и рисуете все заново.

Ищем волшебника

Команда разработчиков,

создававшая

копировальные устройства, однажды пожало-

валась мне, что у их последнего устройства обнаружились проблемы с удобством

использования.

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

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

лать прототип этой задачи

прежде,

чем создавать продукт», - тоскливо сказал один

из

разработчиков.

Но как же прототип

ровать такой сложный

продукт,

как копировальный аппарат? Во-

первых,

купите большой телевизор. Во-вторых, напишите на коробке от него

«КОПИРОВАЛЬНЫЙ АППАРАТ». Потом посадите кого-нибудь внутрь коробки и

попросите пользователя подойти снаружи и изображать различные операции с ап-

паратом. Человек внутри коробки будет отвечать так, как, по его мнению, реагиро-

вало бы устройство, а представитель пользователей должен отмечать, та ли это ре-

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

подобного этому, - иногда его называют «прототипом волшебника из страны Оз» -

зачастую удается на ранних стадиях разработки получить реакцию пользователей,

руководствуясь которой разработчики и строят решения. Плюс вы получаете боль-

шой телевизор.

Какими бы совершенными ни были ваши инструменты

прототипи-

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

Бумажное прототипирование ускоряет каждый цикл, а это — ключевой

фактор успеха при разработке требований. Это отличный метод уточ-

нения требований для проектирования детализированных интерфей-

сов пользователей, создания эволюционных прототипов или традици-

онного проектирования и конструирования. Он также помогает коман-

де лучше управлять ожиданиями клиентов.

262 Часть II. Разработка требований к ПО

Если вы решите создать электронный одноразовый прототип, вос-

пользуйтесь соответствующими инструментами

(Andriole,

1996).

Неко-

торые из них перечислены здесь:

I языки программирования,

такие,

как Microsoft Visual Basic, IBM

Visu-

alAge

Smalltalk

и Inprise Delphi;

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

Perl,

Python и Rexx;

I коммерческие наборы инструментальных средств

прототипирова-

ния, средства раскраски изображений на экране и компоновщики

графического интерфейса пользователя;

средства рисования, такие, как Microsoft Visio и Microsoft Powe -

Point.

Средства для Web, использующие легко модифицируемые страни-

цы HTML (Hypertext Markup Language), годятся для создания прото-

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

Однако

они не позволяют быстро исследовать детализированный дизайн ин-

терфейсов. Соответствующие инструменты позволят вам с легкостью

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

зависимости от неэффективности его кода. Конечно же, если вы

соз-

даете эволюционный прототип, то должны использовать высококаче-

ственные средства разработки с самого начала.

Оценка прототипа

Для улучшения оценки горизонтальных прототипов создавайте сцена-

рии, проводящие пользователей через последовательность

действий,

и задавайте конкретные вопросы, чтобы выявить требуемую информа-

цию. Этот метод — дополнение к общему приглашению:

«Расскажите,

что вы думаете об этом прототипе». Сценарии оценки составляйте на

основании вариантов использования или функций, которые должен

представлять прототип. Сценарий попросит пользователей

выполнить

определенные задачи и проведет их через наиболее неясные области

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

проме;-

жуточных

пунктах, сценарий задает связанные с задачами вопросы. Ну

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

1 Реализует ли прототип все необходимые функции так, как вы этого

ожидали?

1 Не упущены ли какие-либо необходимые функции?

1 Заметили ли вы какие-либо условия ошибки, не учтенные в про-

тотипе?

I Нет ли в прототипе каких-либо ненужных функций?

Глава

13.

Прототипы как средство уменьшения риска 263

Насколько логичной и полной вам кажется навигация?

I Не оказалось ли выполнение каких-либо задач слишком сложным?

Удостоверьтесь, что пользователи оценивали прототип с соответст-

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

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

ните, что в нем воплощена лишь часть нужных функций, остальные бу-

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

Ловушка Остерегайтесь пользователей, которые вводят реальные данные в

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

недовольны, если по окончании работы с прототипом введенные ими данные будут

потеряны.

Вы узнаете больше, наблюдая за работой пользователей с прототи-

пом,

чем просто опрашивая их. Формальное тестирование легкости и

простоты использования эффективно, но простое наблюдение за

пользователями в процессе также может многое сказать. Смотрите, к

каким клавишам инстинктивно тянутся пальцы пользователя. Отме-

чайте места,

где

прототип конфликтует с другими приложениями, ко-

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

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

тельствующие, что пользователь озадачен и не знает, что делать даль-

ше, как добраться до нужной точки или открыть другую часть приложе-

ния, чтобы просмотреть еще что-нибудь.

Просите ваших помощников вслух выражать их мнение во время ра-

боты с прототипом, чтобы вы могли понимать ход их мышления и отме-

тить требования, которые прототип обрабатывает плохо. Создайте дру-

желюбную атмосферу, в которой пользователи будут свободно высказы-

вать свои идеи и замечания. Избегайте показывать им «правильный»

путь реализации тех или иных функций в прототипе.

Записывайте все, что узнаете в процессе оценки прототипа. Гори-

зонтальный прототип позволит вам уточнить спецификацию требова-

ний к ПО. Если на основе оценки прототипа были приняты какие-либо

решения о дизайне интерфейса пользователя или выбраны конкрет-

ные методы взаимодействия, запишите эти выводы и то, как вы к ним

пришли. Иначе вам придется снова и снова возвращаться к одному и

тому же — пустая трата времени. После вертикального прототипиро-

вания задокументируйте процесс и результаты оценки, в том числе ре-

шения, которые вы приняли об исследованных технических процессах.

Ищите любые несоответствия между спецификацией требований к ПО

и прототипом.

264 Часть II. Разработка требований к ПО