Создание прототипов

Часть 2. Понимание потребностей пользователей
Глава 15
Создание прототипов
Основные положения
Прототипирование особенно эффективно для преодоления синдромов
“да, но…” и “неоткрытые руины”.
Прототип программных требований является частичной реализацией
программной системы и помогает разработчикам, пользователям и заказчикам лучше понять требования к системе.
Следует создавать прототип “неясных” требований, т.е. тех, которые хотя
и известны, но плохо определ
ены и малопонятны.
Программные прототипы, как ранние воплощения программной системы, демонстрируют часть функциональных возможностей новой системы. Принимая во внимание
то, что мы уже обсудили, можно предположить, что прототипы можно с успехом применять для выявления потребностей пользователей. Пользователи могут трогать, ощущать
прототип системы и взаимодействовать с ним, что не может обеспечить ни один другой
метод. Прототипирование исключительно эффективно в преодолении как синдрома “да,
но…” (“Это не совсем то, что я думал”), так и синдрома “неоткрытых руин” (“Теперь, после того как я ее увидел, мне бы хотелосьобавить
д
еще одно требование
”).
Виды прототипов
Существует много способов разбиения прототипов на категории. Например, Дэвис (Davis,
1995,a) в своей работе выделял следующие прототипы: отбрасываемые, эволюционирующие
и операционные; вертикальные и горизонтальные; пользовательские интерфейсы и алгоритмические; и т.д. Каким должен быть прототип в каждом конкретном случае, зависит от того,
какую проблему вы пытаетесь решить путем построения прототипа.
Например, если риск проекта связан преимущественно с применением технологического подхода — просто это никогда прежде не делалось таким способом и вы не уверены,
сможет ли применяемая технология обеспечить нужную производительность или пропускную способность — можно создать архитектурный прототип, который главным образом
демонстрирует осуществимость используемой технологии. Архитектурный прототип
может быть отбрасываемым или эволюционирующим. “Отбрасываемый”” означает, что его
задача состоит только в определении осуществимости; можно использовать всевозможные сокращения, альтернативные технологии, имитации для ее достижения. По окончании прототип просто отбрасывается, сохраняется только полученное в результате зна-
160
Часть 2. Понимание потребностей пользователей
ние. “Эволюционирующий” означает, что прототип реализуется в той же архитектуре,
которую вы намерены использовать в конечной версии системы, и можно строить рабочую версию системы, развивая данный прототип.
Если же основной риск в проекте представляет интерфейс пользователя, можно разработать прототип требований с помощью любых технологий, позволяющих создать
прототип пользовательского интерфейса как можно быстрее. На рис. 15.1 представлено
дерево решений, которое можно использовать при выборе вида прототипа, наиболее
подходящего для вашего проекта.
Узкая
Вертикальный
Ширина полосы риска
Стратегия
инвестирования?
Отбрасываемый
Широкая
Горизонтальный
Узкая
Эволюционирующий
Вертикальный
Ширина полосы риска
Требования
Широкая
Горизонтальный
Риск
проекта?
Узкая
Технология
Отбрасываемый
Вертикальный
Ширина полосы риска
Стратегия
инвестирования?
Широкая
Горизонтальный
Вертикальный
Эволюционирующий
Узкая
Широкая
Горизонтальный
Рис. 15.1. Дерево решений для выбора вида прототипа: верхняя ветвь — прототипы требований;
нижняя — архитектурные прототипы
Прототипы требований
Для выявления требований мы сосредоточим наше внимание на видах прототипов,
расположенных на верхней ветви данного дерева. Для начала рассмотрим опред
еление.
Прототип требований к программному обеспечению — это частичная реализация системы программного обеспечения, созданная с целью помочь разработчикам, пользователям и клиентам лучше понять требования к системе.
Для выявления требований зачастую можно использовать прототип в виде
“отбрасываемого горизонтального интерфейса пользователя”. “Горизонтальный” озна-
Глава 15. Создание прототипов
161
чает, что мы будем стараться создать широкий спектр функциональных возможностей
системы; в противоположность этому “вертикальный” прототип создает довольно мало
требований, но делает это качественно. “Интерфейс пользователя” означает, что мы будем создавать в основном интерфейс системы с ее пользователями, а не заниматься реализацией логики и алгоритмов, лежащих внутри программы, или созданием интерфейсов с другими устройствами или системами. В качестве средства выявления требований,
прототип выполняет свою роль нескольк
ими способами.
Созданный разработчиком прототип может использоваться для получения подтверждения заказчика, что разработчик правильно понимает требов
ания.
Созданный разработчиком прототип может быть своего рода катализатором, заставляющим заказчика подумать о дополнительных требованиях.
Созданный заказчиком прототип может помочь донести требования до разработчика.
Во всех трех случаях цель состоит в создании прототипа с наименьшими затратами.
Если его создание обойдется слишком дорого, может оказаться более эффективным сразу
создавать реальную систему!
Многие прототипы программного обеспечения являются прототипами требований и
используются в основном для фиксации элементов интерфейса пользователя создаваемой системы. Тому есть две причины.
1. Появление множества недорогих и широко доступных средств быстрого построения интерфейсов пользователя.
2. Для систем, активно взаимодействующих с пользователем, создание прототипа интерфейса пользователя выявляет также много других требований, а именно, какие
функции предоставляются пользователю, когда каждая функция доступна ему и какие функции для него пропущены.
Однако необходимо следить за тем, чтобы доступность этих средств не заставила нас
прототипировать те части системы, которые на самом деле не имеют самого высокого
риска и не нуждаются в первоочередномпрототипировании.
Что прототипировать
Как же узнать, какую часть системы нужно прототипировать? В типичной ситуации
наше понимание потребностей пользователей находится в диапазоне от хорошо понятных и легко объяснимых до совершенно неизвестных (рис.
15.2).
Хорошо известные
Неопределенные
Неизвестные
Рис. 15.2. Наше понимание потребностей пользоват
елей
Хорошо понимаемые требования могут очевидным образом вытекать из содержания
приложения и опыта пользователей и команды, полученного при работе с системами подобного типа. Например, если мы просто совершенствуем существующую систему, понятно, каким должно быть большинство новых функциональных возможностей. Хорошо
162
Часть 2. Понимание потребностей пользователей
известные и понимаемые требования не нуждаются в прототипировании, если они не
являются необходимыми для того, чтобы помочь пользователям визуализировать содержание других их потребностей. Создание прототипов таких требований будет излишней
тратой ресурсов, а поскольку они и так уже хорошо понятны, из их рассмотрения мало
что можно будет почерпнуть.
Неизвестные требования являются теми “неоткрытыми руинами”, которые мы хотели бы найти. К сожалению, мы не можем по-настоящему прототипировать их, так как в
противном случае они уже не были бы неизвестными! Таким образом в качестве объекта
прототирования остаются расположенные в середине “неясные” требования. Эти требования могут быть известны, но плохо определены и плохо пон
имаемы.
Построение прототипа
Выбор технологии, используемой для построения прототипа, зависит от принятия
дальнейших решений в правой части дерева решений на рис. 15.1. Например, для отбрасываемого GUI-прототипа можно выбрать любой метод (при условии, что он является
самым быстрым, самым недорогим способом реал
изации образцовGUI).
Если выбран эволюционирующий прототип, нужно применить тот же язык реализации и ту же среду разработки, которые будут использоваться в промышленном изделии.
Придется затратить значительные усилия на проектирование архитектуры системы, а
также применить все стандарты кодирования и программные процессы, которые вы намереваетесь использовать при создании системы. В противном случае вы будете пытаться развивать систему, которая имеет существенные недостатки в одном или нескольких
из этих аспектов. В конце концов, может оказаться, что прототип придется отбросить!
Или, что еще хуже, созданный из лучших побуждений прототип требований отрицательно повлияет на качество развертываемой системы.
Оценка результатов
После создания прототипа пользователи должны поработать с ним в среде, которая
как можно более точно имитирует производственную среду использования результирующей системы. Тогда проявятся факторы среды и другие внешние факторы, оказывающие
влияние на требования к изделию. Кроме того, важно, чтобы с продуктом поработали
пользователи, представляющие различные их классы, в противном случае результаты
могут оказаться однобокими.
Результат процессапрототипирования будет следующим.
1. Неясные требования становятся более понятными.
2. Практическая работа с прототипом неизбежно вскроет реакцию пользователя типа
“да, но…”; поэтому станут очевидны неизвестные ранее потребности. Даже то, что
пользователь просто увидит множество вариантов поведения, поможет ему понять
другие требования, которые должны быть наложены на систему.
В любом случае прототипирование практически всегда приносит свои плоды. Поэтому, как правило, следует прототипировать любое новое или инновационное приложение.
Главное, чтобы полученные в результате знания о требованиях стоили произведенных
затрат. Поэтому мы всегда стараемся использовать при создании прототипов (или, по
Глава 15. Создание прототипов
163
крайней мере, при реализации наиболее ранних прототипов) самые быстрые и недорогие методы. Ограничивая расходы, мы максимизируем отдачу от инвестиций в получение знаний о требованиях.
Заключение
Поскольку прототипы программного обеспечения демонстрируют часть желаемых
функциональных возможностей новой системы, их можно с успехом применять для
уточнения реальных требований к системе. Секрет их успеха в том, что пользователи могут взаимодействовать с прототипом в своей среде, которая близка к реальной настолько,
насколько этого можно добиться, не разрабатывая промышленнуюрсию
ве программы.
Выбирать метод создания прототипа следует в зависимости от типа риска, присутствующего в вашей системе. Недорогие и простые в разработке прототипы требований помогут вам исключить большую часть связанных с требованиями рисков в проекте.
Среди всех имеющихся возможностей следует выбрать ту, которая позволит затратить на прототип как можно меньше средств. Использование любого из существующих
методов прототипирования, а еще лучше — комбинации нескольких методов, доказало
свою исключительную эффективность в совершенствовании понимания командой проекта реальных требований к программной системе.
164
Часть 2. Понимание потребностей пользователей
Заключение части 2
Задача понимания реальных потребностей пользователей и других заинтересованных
лиц осложняется тремя “синдромами”. Описание синдромов “да, но…”, “неоткрытые
руины” и “пользователь и разработчик” помогает лучше понять предстоящие проблемы и
дает представление о том, в какой среде будут использоваться методы выявления, которые мы разработали для понимания потребностей польз
ователей.
Так как команды редко получают совершенные спецификации требований к создаваемой системе, они должны сами добывать информацию, необходимую им для успешной работы. Термин “выявление требований” очень точно отражает данный процесс, в
котором команда должна играть более активную роль.
Чтобы помочь команде решить эти проблемы и лучше понять потребности пользователей и других заинтересованных лиц, можно использовать различные методы.
Интервьюирование и анкетирование
Совещания, посвященные требованиям
Мозговой штурм и отбор идей
Создание раскадровок
Прецеденты
Обыгрывание ролей
Создание прототипов
Хотя ни один метод не является универсальным, каждый из них позволяет лучше понять потребности пользователей и тем самым превратить “неясные” требования в требования, которые “лучше известны”. Каждый из этих методов “срабатывает” в определенных ситуациях, однако мы отдаем предпочтение совещанию, посвященному требованиям, и мозговому штурму.