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

Когда люди говорят «прототип ПО », они обычно имеют в виду горизонтальный прототип (horizontal prototype) предполагаемого интерфейса пользователя. Его также именуют поведенческим прототипом (behavioral prototype) или моделью. Горизонтальным прототип называется потому, что в нем не реализуются все слои архитектуры и нюансы системы, но воплощаются некоторые особенности интерфейса пользователя. Он позволяет пользователям исследовать поведение предполагаемой системы в тех или иных ситуациях для уточнения требований, а также выяснить, смогут ли они с помощью системы, основанной на прототипе, выполнять свою работу.

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

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

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

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

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

Вертикальный прототип (vertical prototype), также называемый структурным прототипом (structural prototype) или проверкой концепции, воплощает срез функциональности приложения от интерфейса пользователя до сервисных функций. Вертикальный прототип действует как настоящая система, поскольку затрагивает все уровни ее реализации. Разрабатывайте вертикальный прототип всякий раз, когда сомневаетесь в осуществимости и стабильности предполагаемого подхода к архитектуре системы или когда хотите оптимизировать алгоритмы, оценить предлагаемую схему базы данных или проверить критически важные временные требования. Чтобы получить значимые результаты, вертикальные прототипы создают, используя средства разработки в среде, аналогичной среде разработки. Вертикальные прототипы используются для исследования критически важных требований к интерфейсу и времени исполнения, а также для сокращения рисков на стадии проектирования системы.

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

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

Прежде чем создавать прототип, примите четкое и ясное решение, прекратите ли вы работать с ним после оценки или сделаете его частью выпускаемого продукта. Создайте одноразовый прототип (throwaway prototype) или исследовательский прототип (exploratory prototype), чтобы ответить на вопросы, разрешить неясности и улучшить требования к ПО (Davis, 1993). Если вы решили, что после выполнения задачи прекратите работу с прототипом[5], стройте его как можно более быстро и дешево. Чем больше усилий вы вложите в прототип, тем труднее будет участникам проекта отказаться от него.

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

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

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

Рис. 13-1. Последовательность действий от вариантов использования к дизайну интерфейса пользователя через одноразовый прототип

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

В отличие от одноразового прототипа, эволюционный прототип (evolutionary prototype) представляет собой прочный архитектурный «фундамент» для постепенного создания окончательного продукта — по мере прояснения требований. Эволюционное протатипирование — один из компонентов модели спирального цикла разработки ПО (Boehm, 1988) и некоторых процессов разработки объектно-ориентированного ПО (Kruchten. 1996). В отличие от одноразовых прототипов, создаваемы «быстро и начерно», для построения эволюционного прототипа необходимо с самого начала использовать отличный и качественный код. Поэтому на конструирование эволюционного прототипа требуется больше времени, чем на одноразовый прототип, моделирующий те же свойства системы. Эволюционный прототип следует создавать в расчете на легкий рост и частое расширение, поэтому разработчики должны уделять большое внимание архитектуре и принципам проектирования. При создании такого прототипа ни в коем случае не стоит экономить на качестве.

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

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

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

Рис. 13-2. Несколько возможных способов использования прототипов а процессе разработки ПО

Таблица 13-1. Стандартные способы применения прототипов ПО