Глава 3: Типы тестов ... 61

Дискуссионные группы

Каждый продукт предназначается для определенного сегмента рынка. Целью данного метода анализа является определение ключевых требований этого сегмента.

Для этого аналитик отбирает небольшую группу людей, которые, по его мнению, являются наиболее типичными представителями нужного сегмента рынка. Члены группы не знают друг друга. Аналитик предлагает им обсу­дить определенную тему. (Тем может быть и несколько, но очень немно­го.) Он может направлять дискуссию, задавая наводящие вопросы и концентрируя внимание группы на заданной теме, а может и не участво­вать в обсуждении вовсе. Если аналитик не умеет грамотно направлять дис­куссию, он может нанять для этого соответствующего специалиста. Его цель — выяснить реакцию рынка на предложенную идею, но ни в коем случае ни в чем не убеждать членов группы.

Такая дискуссия может осветить самые различные аспекты обсуждаемой проблемы. Аналитик может понять, чего пользователи хотят от данного типа продуктов, как они его используют, какие функции для них наиболее важны. Можно сконцентрировать группу и на одной конкретной функции продукта или на одной цели его применения. Можно использовать группу для генерации идей еще до детального планирования, а можно проанали­зировать ее реакцию на элементы уже готового плана.

Обследование объекта

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

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

Более подробную информацию об анализе задания путем обследования автоматизируемого объекта можно найти в книгах Бейлей (Bailey, 1989),

62 Часть I: Основы

Карда, Морана и Ньюэлла (Card, Moran & Newell, 1983), Хеландера (Helander, 1991, особенно глава 38), Нормана и Дрейпера (Norman & Draper, 1986, часть IV), Рубенштейна и Херша (Rubenstein & Hersh, 1984). Кроме того, ряд интересных примеров приведен в книге Бейкера и Баксто­на (Baecker & Buxton, 1987).

Стадии проектирования

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

Разрабатывая проект, специалисты опираются на требования к продук­ту. Если этого документа нет, если он неполон или постоянно меняется, им приходится планировать функции продукта самим.

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

Хорошими учебниками по проектированию программного обеспечения являются книги Йордана (Yourdon, 1975), Джонса (Joncs, 1979) и Майерса (Myers, 1976).

Внешний дизайн

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

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