Как это делается
Прототип — не законченная программа, но он даёт возможность получить фактические данные, которые позволят принимать более удачные решения. Важнее всего — время, поэтому нужно действовать быстро. Ниже описаны этапы кратчайшего пути, который, однако, позволяет создать вполне приличный прототип.
• Определите ключевые факторы риска
Первый этап — создание списка основных вопросов, на которые нужно ответить. Изучите все вопросы, в которых нужно разобраться, чтобы разработать точный план. Если вопросов много, нужно определить приоритетные и проработать их в первую очередь. Помните: нужно сосредоточиться только на ключевых моментах, а не на всех неизвестных.
• Составьте план экспериментов
Следует создать план экспериментов, которые помогут ответить на поставленные вопросы. Можно искать ответ на каждый вопрос посредством отдельного эксперимента или решать несколько проблем одновременно, проводя ряд экспериментов.
Независимо от числа экспериментов нужно смоделировать взаимодействие любых ключевых технологий или компонентов. Здесь задача заключается в том, чтобы проработать продукт «вширь», а не «вглубь», т.е. охватить максимально возможное число функций, а не пытаться полностью воспроизвести какую-то одну из них. Вы не поверите, как часто мне приходилось встречать проекты, в которых возникали катастрофические проблемы при попытке собрать воедино все фрагменты программы. Обычно причина была в том, что в течение первых недель реализации проекта этим проблемам не было уделено внимания.
• Попробуйте сымитировать конечный результат
Одно из ключевых требований, выполнив которое, можно считать создание прототипа завершённым, — имитация конечного результата. Для этого придётся заглянуть в будущее, чтобы увидеть программу в окончательном виде и попытаться заранее смоделировать её ключевые составляющие, Чтобы преуспеть в этом, придётся ограничиться созданием модели на основе набора временных компонентов и API, имитирующих готовую программу. Возможно, часть функций придётся запрограммировать жёстко, для других вообще написать заглушки, а реальные данные заменить имитационными. Все это допустимо на данном этапе — ведь создаётся всего лишь эмулятор реальной программы. Главная задача сейчас — создать «скелет» программы, а «мясом» он обрастёт позже.
• Используйте существующие наработки
Ещё один важный способ ускорения создания прототипа — использование существующих решений. Вовсе не обязательно все писать «с нуля». Некоторые наиболее успешные прототипы появились в результате модификация копии исходного текста рабочей программы.
• Оценивайте результаты
Когда прототип готов, не забудьте оценить результаты своей работы. В частности, работая с прототипом, можно оценить производительность на макроуровне, необходимый объём памяти и то, как она используется. Можно определить и сложность внедрения, и качество технологии, а также попытаться разобраться в её принципах. Короче говоря, какими бы ни были потребности, нужно выжать из прототипа максимум пользы.
• Документируйте результаты.
Это полезно не только для сегодняшних участников группы, но и для будущих. Если при работе с прототипом обнаружились серьёзные проблемы, то они скорее всего снова возникнут и в будущем. Каждый участник группы должен знать, почему принято то или иное важное решение. Со временем у вас соберётся целая библиотека проектных заметок, которая станет историческим документом проекта.
Из собственного опыта
Во время работы над BoundsChecker 5.0 разработчикам NuMega пришлось почти полностью переписать внутренние компоненты программы. При этом работа шла в основном на двух фронтах: обновление систем сбора и анализа информации. Из-за сложности проекта мы испытывали большой соблазн сначала довести до конца конструирование системы сбора данных, а затем закончить систему анализа. Но опять же в силу сложности проекта мы пришли к выводу, что лучше создать прототипы для обеих систем, чем тратить время на создание подробных спецификаций. Было решено смоделировать сбор части нужных данных и написать лишь части кода для анализа только этих данных. Если программа функционировала нормально, выводилось простое диалоговое окно с сообщением, что все работает.
Спустя неделю один из программистов зазвал меня в свой кабинет и продемонстрировал маленькое простенькое диалоговое окно. Прототип работал! Теперь мы знали, что все задуманное осуществимо от начала до конца и серьёзных проблем с производительностью не предвидится. Следующие две недели мы по очереди наращивали все функции, обретая все большую уверенность в успехе. Таким образом, окончательная архитектура и конструкция программы были существенно улучшены. Через три недели у нас был готовый проект, который мы могли точно спланировать. В конечном итоге это позволило нам сэкономить кучу времени при его реализации. Я не говорю, что после всё было прекрасно, но без этих простых действий у нас бы не хватило уверенности, знаний и понимания, чтобы правильно спланировать проект.

Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Не торопитесь
Как уже не раз было сказано, разработчики часто пытаются работать с новыми технологиями, основываясь лишь на допущениях. Эти допущения превращают проект скорее в азартную игру, чем в серьёзную техническую работу. Не торопите события: хотя некоторые проблемы можно и должно решать с ходу, всё же следует определить ключевые потребности и убедиться, что новые технологии в состоянии удовлетворить их. В этом случае вы сможете предвидеть проблемы и лучше подготовитесь к их решению, а также отреагировать на возникшие проблемы на более ранних этапах цикла разработки проекта.
Не увлекайтесь моделированием отдельных функций
Часто возникает искушение создать прототип какого-либо компонента без учёта контекста, не принимая во внимание характер его применения. Хотя сосредоточиться на узкой задаче много проще, в этом таится большая опасность. Моделирование не должно концентрироваться на отработке какого-то одного компонента, важно отработать совместную работу всех критически важных компонентов. Я очень рекомендую создавать общесистемные прототипы, в которых собраны воедино все критически важные фрагменты системы, даже если при этом приходится использовать искусственные данные, жёстко прошивать вызовы API или подменять их заглушками. Тем не менее в этом случае удастся составить хорошее представление о проблемах с интеграцией компонентов и убедиться в проектных решений на уровне системы.
Не оставляйте анализ производительности напоследок
Большинство считает, что производительность — это что-то, что «добавляется» к программе в конце цикла работы над проектом. Хотя настройка разного рода параметров, несомненно, может и должна выполняться после сборки всех частей проекта, также верно и то, что на этом этапе объём возможных изменений весьма ограничен. Неуместно вносить фундаментальные изменения в архитектуру или внутреннюю структуру продукта в последние недели работы над проектом.
Необходимо заранее проанализировать производительность на макроуровне: сначала на прототипе, а затем после сборки всех основных фрагментов программы.

Глава 10
Пользовательский интерфейс
Думаю, ни один участник команды не станет спорить с тем, что хороший пользовательский интерфейс — ключевое условие успеха продукта. Увы, на этом согласие заканчивается. В командах, одолеваемых проблемами с пользовательским интерфейсом, нередко отсутствует работа с прототипом пользовательского интерфейса, или члены команды не могут договориться о том, как организовать эту работу. Часто проблемы с пользовательским интерфейсом — самое серьёзное испытание, грозящее сорвать план реализации проекта.
Если в этом плане ваша команда не отличается от других, то скорее всего самые горячие споры разгораются при обсуждении вопросов, касающихся пользовательского интерфейса: что и как интерфейс должен делать и на что должен быть похож. Порой эти споры длятся в течение всего времени работы над проектом и становятся причиной столкновений участников команды, задержек в работе и фальстартов. Хуже того, часто проблемы с интерфейсом, о существовании которых никто не догадывался, неожиданно всплывают на поздних стадиях реализации проекта. Чтобы что-то изменить на этом этапе, разработчикам, тестировщикам и техническим писателям приходится многое переделывать, так что в этом случае дело пахнет серьёзным срывом планов.
Решение этой проблемы заключается в создании прототипа пользовательского интерфейса на ранних стадиях цикла разработки. Прототип следует как можно быстрее тестировать, оценивать и улучшать, пока не будут решены основные проблемы. В этой главе мы обсудим значение прототипа пользовательского интерфейса, а также поговорим о способах создания прототипов при работе над самыми разными проектами. Я не буду касаться здесь всех составляющих хорошего интерфейса, так как они могут существенно варьировать в зависимости от платформы. Вместо этого мы рассмотрим, как организовать в цикле разработки ПО эффективную работу по созданию пользовательского интерфейса, которая, однако, не потребует мощного оборудования, специальных ресурсов и существенных затрат времени. В завершение мы обсудим роль специалиста по инженерной психологии и рассмотрим роль этой ключевой фигуры в руководстве работой по созданию пользовательского интерфейса.
Прототип пользовательского интерфейса
Прототип — это наглядная модель пользовательского интерфейса. В сущности это функционирующий «черновик» интерфейса, созданный на основе ваших представлений о потребностях пользователей. Прототип может принимать множество различных форм, от бумажных макетов до реальных программ, имитирующих работу пользовательского интерфейса (способы создания прототипов мы обсудим ниже). Однако независимо от формы прототип должен давать команде чёткое представление о способе взаимодействия пользователя с программой.
Почему прототип необходим?
Как сказано в главе 8, требования к продукту определяют основные задачи, которые приходится выполнять пользователям. Однако в описании требований не сказано, как пользователи будут это делать. Ответ даёт прототип пользовательского интерфейса. Им занимается команда разработчиков программы и в большей степени — специалист по инженерной психологии. После создания прототипа появляется возможность привлечь пользователей для проверки деталей выбранного вами решения. Результаты тестирования позволяют убедиться, что пользовательские потребности были поняты правильно. Важнее всего при этом возможность легко вносить изменения и пробовать новые идеи, руководствуясь результатами тестов.
Прототип даёт команде разработчиков множество преимуществ.
• Возможность сосредоточиться на решении ключевых задач.
Необходимо сосредоточить усилия команды на самых важных частях продукта. Важнейшие части продукта — это ключевые задачи, наиболее ценные, нужные и важные для пользователя. Все участники команды (разработчики, тестировщики, технические писатели и др.) должны чётко представлять себе суть ключевых задач и не жалеть усилий для их правильного понимания. Отчасти верно, что остальная функциональность просто не имеет значения, если трудно решать основные задачи или не ясно, как это делать.
Из собственного опыта
Когда в NuMega решили создать TrueTime, новую программу-профайлер, было ясно, что интерфейс для неё придётся создавать «с нуля». Но на что должен быть похож новый интерфейс? Какие действия наиболее важны для пользователя? Ознакомившись с положением в отрасли, мы обнаружили массу хороших продуктов, в целом составляющих весьма развитый набор ПО. Однако все существующие программы перегружали пользователя информацией, что, с нашей точки зрения, является недостатком, так как это очень затрудняет выполнение самой важной задачи продукта — поиск проблем с производительностью программ. Теперь мы знали, к чему стремиться: нужно сделать так, чтобы поиск проблем с производительностью с помощью нашей программы требовал не больше трёх щелчков. Вся команда сообща работала над созданием интерфейса, чтобы решить эту просто сформулированную, но такую трудную задачу. Мы решили не усложнять интерфейс и разработали новый подход к навигации по сложной иерархии функций, в которой зачастую таятся проблемы с производительностью. В результате первый выпуск TrueTime принёс нам премию «Best of Show», присуждаемую журналом Comdex/Byte Magazine. Основным фактором успеха была концентрация усилий команды на решении определённых задач.
• Точность
Одна из самых серьёзных проблем при разработке программы — переделки по причине многократных изменений конструкции и реализации пользовательского интерфейса. Чтобы уложиться в сроки, нужно исключить крупные переделки. Хотя получить совершенный продукт с первого раза практически невозможно, надо как можно раньше скомпоновать основные элементы пользовательского интерфейса. Мелкие изменения вполне допустимы, но большие изменения могут привести к катастрофическим последствиям, негативно отражаясь на времени разработки, качестве продукта и документации.
• Планирование
Нельзя составить точный план, не зная структуры пользовательского интерфейса. Если интерфейс будет изменяться по ходу цикла разработки, то в план проекта также придётся вносить соответствующие изменения. Кроме того, необходимо предохранять план от перенапряжения , которое возникает, когда работа тестировщиков и технических писателей сдерживается изменениями пользовательского интерфейса. Таким образом, перенапряжение плана ведёт к задержке работы над проектом в целом. Помните: следует вести работу над всеми частями проекта в параллели с разработкой программы. Планирование требует чёткого понимания структуры пользовательского интерфейса уже в начале работы над проектом.
• Документация
Вам обязательно понадобится документация, описывающая работу с программой. Очевидно, что документация тесно связана с интерфейсом программы. Команда технических писателей должна быть в курсе проблем, с которыми предстоит столкнуться пользователям, а также знать, как их решить с помощью программы. Если интерфейс не довести до ума в начале работы над проектом, техническим писателям придётся постоянно нагонять разработчиков, что сделает их параллельную работу невозможной.
• Тестирование
Тестирование программы также сильно зависит от её интерфейса. Традиционно тестировщики просят разработчиков предоставить им подробные спецификации функций программы, точно описывающие все особенности её работы. К сожалению, полностью описать пользовательский интерфейс, особенно современный, практически невозможно. Лучшая замена описанию — прототип. Если предоставить тестировщикам прототип интерфейса, то, ознакомившись с программой и разобравшись в основах и принципах работы её функций, предназначенных для конечных пользователей, они смогут улучшить разработанные ими планы тестирования. Это не значит, что описание функций не имеет значения или можно пренебречь им, просто я хочу подчеркнуть, что прототип — один из лучших способов демонстрации особенностей продукта. Обладая прототипом пользовательского интерфейса, тестировщики смогут изучить продукт вдоль и поперёк, а разобравшись в работе функций программы, команда сможет подготовить лучшие планы тестов и испытаний до окончания разработки программы.
Создание прототипа
Возможно, дочитав до этого места, вы спросите: «Все это здорово, но как создать прототип?» Подход к созданию прототипов пользовательского интерфейса, который исповедует NuMega, основан на трёх простых принципах. Сначала мы определяем наиболее важные задачи, которые приходится решать пользователям. Затем мы быстро моделируем эти задачи на ранних стадиях работы над проектом, ещё до подготовки плана проекта в окончательном виде: это увеличивает шансы правильно оценить объём предстоящей работы. Наконец, мы очень быстро доводим прототип, внося в него ряд последовательных изменений, демонстрируя как внутренние, так и внешние его особенности. Такой подход позволяет тестировать прототип вместе с пользователями. Возможность быстрой доработки прототипа — ключевой фактор успеха, позволяющий как можно раньше привести его к окончательному виду.
Решив эти задачи, команда получит прототип пользовательского интерфейса, понятный всем её участникам ещё до создания самой программы.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30