Не всегда для разрешения неопределенностей в требованиях нужен прототип в виде исполняемого кода. Бумажный прототип (paper prototype), иногда его называют низкокачественным прототипом, — это дешевый, быстрый и низкотехнологичный способ выяснить, как может выглядеть некий фрагмент системы (Rettig, 1994; Hohmann, 1997). Бумажные прототипы помогают установить, действительно ли пользователи и разработчики одинаково понимают требования. Они позволяют вам попробовать, практически не рискуя, сделать шаг при разработке кода продукта. Похожий метод, называемый методом раскадровки (storyboard) (Leffingwell и Widrig, 2000), показывает предлагаемый интерфейс пользователя, без привлечения пользователей к работе с ним.
Для создания бумажных прототипов требуются инструменты не сложнее, чем бумага, учетные карточки, наклейки и чистые пластиковые прозрачки. Проектировщик делает наброски экранов, как он их представляет, не заботясь о том, где точно будут располагаться элементы управления и как они будут выглядеть. Пользователи с готовностью делятся своим мнением, в результате чего возможны глубокие изменения — но на листе бумаги. В некоторых случаях, однако, они не склонны критиковать полюбившийся им компьютерный прототип, в который разработчик, по всей видимости, вложил много труда. Разработчики также иногда противятся внесению существенных изменений в тщательно выполненный электронный прототип.
При применении низкокачественного прототипа человек играет роль компьютера, пока длится оценочный сценарий. Он инициирует действия, произнося вслух, что он собирается сделать в конкретном экране: «Я хочу выбрать команду Предварительный просмотр из меню Файл». При этом пользователь показывает страницу или учетную карточку, представляющую экран, который должен появиться после выполнения действия. Это позволяет оценить, соответствует ли ответ ожидаемому и содержит ли экран необходимые элементы. Если нет, вы просто берете чистый лист бумаги или карточку и рисуете все заново.
| Ищем волшебника Команда разработчиков, создававшая копировальные устройства, однажды пожаловалась мне, что у их последнего устройства обнаружились проблемы с удобством использования. Самая обычная задача по копированию выполнялась в пять отдельных действий, что пользователям казалось ужасно неудобным. «Надо было нам сделать прототип этой задачи прежде, чем создавать продукт», — тоскливо сказал один из разработчиков. Но как же прототипировать такой сложный продукт, как копировальный аппарат? Во-первых, купите большой телевизор. Во-вторых, напишите на коробке от него «КОПИРОВАЛЬНЫЙ АППАРАТ». Потом посадите кого-нибудь внутрь коробки и попросите пользователя подойти снаружи и изображать различные операции с аппаратом. Человек внутри коробки будет отвечать так, как, по его мнению, реагировало бы устройство, а представитель пользователей должен отмечать, та ли это реакция, которую он себе представляет. С помощью простого, веселого прототипа, подобного этому, — иногда его называют «прототипом волшебника из страны Оз» — зачастую удается на ранних стадиях разработки получить реакцию пользователей, руководствуясь которой разработчики и строят решения. Плюс вы получаете большой телевизор. |
Какими бы совершенными ни были ваши инструменты прототипирования, наброски экранов на бумаге делать все равно быстрее. Бумажное прототипирование ускоряет каждый цикл, а это — ключевой фактор успеха при разработке требований. Это отличный метод уточнения требований для проектирования детализированных интерфейсов пользователей, создания эволюционных прототипов или традиционного проектирования и конструирования. Он также помогает команде лучше управлять ожиданиями клиентов.
Если вы решите создать электронный одноразовый прототип, воспользуйтесь соответствующими инструментами (Andriole, 1996). Некоторые из них перечислены здесь:
· языки программирования, такие, как Microsoft Visual Basic, IBMVisualAge Smalltalk и Inprise Delphi;
· языки подготовки сценариев, такие, как Реrl, Python и Rexx;
· коммерческие наборы инструментальных средств прототипирования, средства раскраски изображений на экране и компоновщики
· графического интерфейса пользователя; средства рисования, такие, как Microsoft Visio и Microsoft Powe Point.
Средства для Web, использующие легко модифицируемые страницы HTML (Hypertext Markup Language), годятся для создания прототипов, которые предназначены для прояснения требований. Однако они не позволяют быстро исследовать детализированный дизайн интерфейсов. Соответствующие инструменты позволят вам с легкостью реализовать и обновлять компоненты интерфейса пользователя, вне зависимости от неэффективности его кода. Конечно же, если вы создаете эволюционный прототип, то должны использовать высококачественные средства разработки с самого начала.
Оценка прототипа
Для улучшения оценки горизонтальных прототипов создавайте сценарии, проводящие пользователей через последовательность действий, и задавайте конкретные вопросы, чтобы выявить требуемую информацию. Этот метод — дополнение к общему приглашению: «Расскажите, что вы думаете об этом прототипе». Сценарии оценки составляйте на основании вариантов использования или функций, которые должен представлять прототип. Сценарий попросит пользователей выполнить определенные задачи и проведет их через наиболее неясные области прототипа. В конце выполнения каждой задачи и, возможно, в промежуточных пунктах, сценарий задает связанные с задачами вопросы. Ну и, конечно же, вы вправе задать вопросы сами.
· Реализует ли прототип все необходимые функции так, как вы этого ожидали?
· Не упущены ли какие-либо необходимые функции?
· Заметили ли вы какие-либо условия ошибки, не учтенные в прототипе?
· Нет ли в прототипе каких-либо ненужных функций?
· Насколько логичной и полной вам кажется навигация?
· Не оказалось ли выполнение каких-либо задач слишком сложным?
Удостоверьтесь, что пользователи оценивали прототип с соответствующих точек зрения. Привлекайте как опытных пользователей, так и новичков. Показывая прототип тем, кто его будет оценивать, подчеркните, что в нем воплощена лишь часть нужных функций, остальные будут реализованы в конечной системе.
| Ловушка Остерегайтесь пользователей, которые вводят реальные данные в оцениваемый прототип, потому что он им кажется реальной системой. Они будут недовольны, если по окончании работы с прототипом введенные ими данные будут потеряны. |
Вы узнаете больше, наблюдая за работой пользователей с прототипом, чем просто опрашивая их. Формальное тестирование легкости и простоты использования эффективно, но простое наблюдение за пользователями в процессе также может многое сказать. Смотрите, к каким клавишам инстинктивно тянутся пальцы пользователя. Отмечайте места, где прототип конфликтует с другими приложениями, которыми часто пользуются клиенты, или где последующие действия пользователя не очевидны. Отмечайте нахмуренные брови, свидетельствующие, что пользователь озадачен и не знает, что делать дальше, как добраться до нужной точки или открыть другую часть приложения, чтобы просмотреть еще что-нибудь.
Просите ваших помощников вслух выражать их мнение во время работы с прототипом, чтобы вы могли понимать ход их мышления и отметить требования, которые прототип обрабатывает плохо. Создайте дружелюбную атмосферу, в которой пользователи будут свободно высказывать свои идеи и замечания. Избегайте показывать им «правильный» путь реализации тех или иных функций в прототипе.
Записывайте все, что узнаете в процессе оценки прототипа. Горизонтальный прототип позволит вам уточнить спецификацию требований к ПО. Если на основе оценки прототипа были приняты какие-либо решения о дизайне интерфейса пользователя или выбраны конкретные методы взаимодействия, запишите эти выводы и то, как вы к ним пришли. Иначе вам придется снова и снова возвращаться к одному и тому же — пустая трата времени. После вертикального прототипирования задокументируйте процесс и результаты оценки, в том числе решения, которые вы приняли об исследованных технических процессах. Ищите любые несоответствия между спецификацией требований к ПО и прототипом.
Риски прототипирования
Несмотря на то, что прототипирование уменьшает риск неудачи проекта по разработке ПО, оно обладает собственными рисками. Наибольший из них заключается в том, что кто-либо из заинтересованных в проекте лиц, увидев действующий прототип, решит, что окончательный продукт почти готов. «Ого, да вы, похоже, уже все сделали! — с энтузиазмом говорит тот, кого вы попросили оценить прототип.— Выглядит отлично. Может, вы быстро доделаете его и отдадите мне?»
Если коротко, то: «НЕТ!» Одноразовый прототип ни в коем случае не предназначен для работы, как бы он ни был похож на готовый продукт. Это всего лишь модель, образец, эксперимент. Если нет жестких коммерческих обстоятельств, заставляющих немедленно застолбить место на рынке (в этом случае руководство понимает и принимает необходимость высоких затрат на сопровождение), сопротивляйтесь всем, кто настаивает на поставке одноразового прототипа в качестве готового продукта. Такой шаг в действительности лишь отдалит сроки завершения продукта, потому что и структура, и код одноразового прототипа намеренно создавались без учета качества или надежности.
| Ловушка Остерегайтесь тех заинтересованных в проекте лиц, которые думают, что прототип — это просто ранняя версия окончательного продукта. Управление ожиданиями — одна из ключевых составляющих успеха прототипирования. Каждый, кто увидит прототип, должен понимать его назначение и границы применения. |
Не позволяйте страхам, связанным с преждевременным выпуском продукта, отвратить вас от создания прототипа, объясните всем, что вы не выпустите его как окончательный продукт. Один из способов контролировать этот риск — использовать бумажные, а не электронные прототипы. Ни одному из тех, кто оценивает бумажный прототип, и в голову не придет, что продукт уже почти готов. Еще один способ — выбрать инструменты прототипирования, отличающиеся от тех, что применяются для разработки окончательного продукта. Это поможет противостоять тем, кто просит «быстро закончить» и выпустить прототип. Оставив внешний вид прототипа недоделанным и незаконченным, вы также уменьшите этот риск.
Опасайтесь также, когда пользователей начинает мучить вопрос «Как?»: как интерфейс пользователя будет выглядеть и действовать. Работая с прототипами, внешне похожими на окончательный продукт пользователи легко забывают, что на стадии уточнения требований они должны в основном думать, что же они хотят видеть в системе. Ограничьте прототип только теми демонстрациями, функциями и возможностями навигации, которые помогут вам устранить неопределенности в требованиях.
Третий риск состоит в том, что пользователи начнут делать выводы о производительности конечного продукта по производительности прототипа. Вы не будете проводить оценку горизонтального прототипа в рабочей среде продукта. Возможно, для его создания вы использовали менее эффективные средства, например интерпретируемые сценарии, а не компилируемый код. В вертикальном прототипе не всегда применяются отлаженные алгоритмы или уровни защиты, что скажется на конечной производительности. Если пользователи увидят, что прототип мгновенно реагирует на моделируемый запрос к базе данных, используя жестко закодированные результаты запроса, они могут ждать такой же поразительной производительности от продукта, включающего огромную распределенную базу данных. Подумайте о реализации в прототипе временных задержек, чтобы модель ожидаемого поведения окончательного продукта выглядела более реалистичной (а прототип — менее готовым для реализации).
Наконец, опасайтесь действий по прототипированию, требующих таких усилий, что команда разработчиков выбьется из графика и будет вынуждена выпустить прототип в качестве готового продукта или торопливо и бессистемно доделывать продукт. Относитесь к прототипу, как к эксперименту. Вы проверяете, что требования достаточно определены, и что ключевые аспекты взаимодействия человека и компьютера, а также все архитектурные вопросы решены, так что можно переходить к проектированию и конструированию. Возможностей прототипа должно быть ровно сколько, сколько необходимо для проверки гипотез, ответов на вопросы и уточнения вашего понимания требований.