Цели прототипирования

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

Рассмотрим основные цели, требующие применения прототипов [10.1-10.2]:

• прояснить неясные требования к системе;
• выбрать одно из различных концептуальных решений;
• проанализировать осуществимость.

1. Неясные требования. Часто Заказчику бывает трудно сформулировать требования к тому, что он ожидает от системы. В этом случае прототип интерфейса пользователя (User Interface, UI), оперативно созданный по результатам интервью, дает ему возможность увидеть схематичную реализацию того, как Исполнитель увидел соответствующую часть системы. Что интересно - в данном случае полезен любой исход прототипирования: если Исполнитель понял требования хорошо - польза очевидна; если не очень - польза заключается в том, что Заказчик может указать, в чем заключается непонимание, тем самым решив основную задачу - сделать неясное ясным.
2. Разные варианты решения. Любую техническую задачу можно решить различными способами. Это касается как задачи формулировки требований, так и ее реализации в UI.

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

А) Сценарий последовательной обработки требований.

• А1. Система отображает реестр требований, имеющихся во входной очереди.
• А2. Пользователь выбирает очередное требование.
• А3. Система отображает перечень материалов требования и справочник поставщиков.
• А4. Пользователь сопоставляет каждой из позиций требования поставщика из справочника поставщиков.
• А5. Система придает требованию статус "обработано", высылает по электронной почте автору требования уведомление.
• А6. Продолжать с шага А1, пока очередь не опустеет.

Б) Сценарий группировки по материалам.

• Б1. Система отображает позиции всех требований и справочник поставщиков.
• Б2. Пользователь группирует позиции по типу (так, чтобы однотипные позиции, поставляемые одним и тем же поставщиком, находились рядом).
• Б3. Пользователь выбирает группу позиций и сопоставляет ей поставщика.
• Б4. Система проверяет - не появились ли полностью обработанные требования. При положительном исходе проверки присваивает этим требованиям статус "обработано" и высылает по электронной почте автору требования уведомление.
• Б5. Продолжать с шага Б1, пока очередь не опустеет.

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

После реализации прототипов UI по первому и второму сценариям Заказчик, оценив их достоинства и недостатки, смог в диалоге с Разработчиком сформулировать третий, комбинированный сценарий, сочетающий достоинства первых двух.

1. Анализ осуществимости. Часто бывает так, что комбинация функциональных, нефункциональных требований и ограничений такова, что возникает риск невозможности их реализации. Как правило, такой риск связан с требованиями к быстродействию системы при известных ограничениях среды ее реализации. В этом случае создаются прототипы (не обязательно, связанные с UI), реализующие соответствующую часть системы, имитирующие потоки данных, поступающие на ее вход и их обработку.