Прототипирование

Прототип – это первоначальная версия системы, которая используются для апробирования возможностей дизайна и демонстрирования идей. Прототипы можно использовать на различных фазах разработки. Например, на этапе анализа требований при их нахождении и проверке; на этапе дизайна при исследовании выбора возможностей и планировании пользовательского интерфейса.

Преимущества прототипов: лучшее удобство при использовании системы, более точная совместимость с реальными потребностями пользователей; более высокое качество и более лучшее удобство сопровождения и меньше трудностей при разработке.

Рисунок 1-4 Процесс создания прототипа

Этапы прототипирования являются следующими:

• Накопление требований – это делают на более общем уровне и там же фиксируют то, что в дальнейшем необходимо начать обязательно уточнять.
• Интенсивное планирование – сосредоточение внимания на видимой части (ввод, вывод, формы и т.д.), в результате чего и создается прототип. Клиент имеет возможность оценить прототип и на этой основе уточнить свои желания.
• Затем следует итерация улучшения прототипа до тех пор, пока это не удовлетворит пользователя. В то же время разработчик получает новые идеи исходя из пожеланий клиента.

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

Прототипирование можно делать на различной основе – например, быстрое прототипирование (ühekordne prototüüpimine, Throwaway prototyping), эволюционное прототипирование (evolutsiooniline prototüüpimine, Evolutionary prototyping), инкрементное прототипирование (lisanduv prototüüpimine, Incremental prototyping).

Принципы быстрого прототипирования заключаются в следующем:

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

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

Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:

1. Прояснить не ясные требования (прототип UI)
2. Выбрать одно из ряда концептуальных решений (реализация сцинариев)
3. Проанализировать осуществимость проекта

Классификация протопипов:

1. Горизонтальные и вертикальные
2. Одноразовые и эволюционные
3. бумажные и раскадровки

Горизонтальные прототипы — моделирует исключительно UI не затрагивая логику обработки и базу данных.
Вертикальные прототипы — проверка архитектурных решений.
Одноразовые прототипы — для быстрой разработки.
Эволюционные прототипы — первое приближение эволюционной системы.

Преимущества структурной эволюционной модели быстрого прототипирования:

• конечный пользователь может “увидеть” системные требования в процессе их сбора командой разработчиков; таким образом, взаимодействие заказчика с системой начинается на раннем этапе разработки;
• исходя из реакции заказчиков на демонстрации разрабатываемого продукта, разработчики получают сведения об одном или нескольких аспектах поведения системы, благодаря чему сводится к минимуму количество неточностей в требованиях;
• снижается возможность возникновения путаницы, искажения информации или недоразумений при определении системных требований, что несомненно приводит к созданию более качественного конечного продукта;
• в процесс разработки можно внести новые или неожиданные требования пользователя, что порой необходимо, так как реальность может отличаться от концептуальной модели реальности;
• модель представляет собой формальную спецификацию, воплощенную в рабочую модель;
• модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла;
• благодаря меньшему объему доработок уменьшаются затраты на разработку;
• благодаря тому что проблема выявляется до привлечения дополнительных ресурсов сокращаются общие затраты;
• обеспечивается управление рисками;
• документация сконцентрирована на конечном продукте, а не на его разработке.

Недостатки структурной эволюционной модели быстрого прототипирования:

• с учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания.
• иногда в результате использования модели получают систему с низкой рабочей характеристикой, особенно если в процессе ее выполнения пропускается этап подгонки;
• при использовании модели решение трудных проблем может отодвигаться на будущее. В результате это приводит к тому, что последующие полученные продукты могут не оправдать надежды, которые возлагались на прототип;
• если пользователи не могут участвовать в проекте на итерационной фазе быстрого прототипирования жизненного цикла, на конечном продукте могут отразиться неблагоприятные воздействия, включая проблемы, связанные с его качественной характеристикой;
• на итерационном этапе прототипирования быстрый прототип представляет собой частичную систему. Если выполнение проекта завершается досрочно, у конечного пользователя останется только лишь частичная система;
• если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана;
• прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл “кодирование — устранение ошибок” (code-and-fix cycle), что приводит к дорогостоящим незапланированным итерациям прототипирования;
• структурные методы не используются, чтобы не помешать выполнению анализа. При прототипировании необходимо провести “реальный” анализ требований, осуществить проектирование и обратить внимание на качество с целью создания программы, допускающей сопровождение, точно так же, как и в любой другой модели жизненного цикла (хотя на эти действия может понадобиться меньше времени и ресурсов).

Область применения структурной эволюционной модели быстрого прототипирования: менеджер проекта может быть уверен в необходимости применения структурной эволюционной модели быстрого прототипирования, если:

• требования не известны заранее;
• требования не постоянны или могут быть неверно истолкованы или неудачно сформулированы;
• существует потребность в разработке пользовательских интерфейсов;
• осуществляются временные демонстрации;
• построенное по принципу структурной модели, эволюционное быстрое прототипирование можно успешно использовать в больших системах, в которых некоторые модели подвергаются прототипированию, а некоторые— разрабатываются более традиционным образом;
• требуется уменьшить неточности в определении требований; т.е. уменьшается риск создания системы, которая не имеет никакой ценности для заказчика;
• разработчики не уверены в том, какую оптимальную архитектуру или алгоритмы следует применять;
• алгоритмы или системные интерфейсы усложнены;
• требуется продемонстрировать техническую осуществимость, когда технический риск высок;
• задействованы высокотехнологические системы с интенсивным применением ПО, где можно лишь обобщенно, но не точно сформулировать требования, лежащие за пределами главной характеристики;
• разрабатывается ПО, особенно в случае программ, когда проявляется средняя и высокая степень риска;
• осуществляется применение в комбинации с каскадной моделью: на начальном этапе проекта используется прототипирование, а на последнем — фазы каскадной модели с целью обеспечения функциональной эффективности системы и качества;
• прототипирование всегда следует использовать вместе с элементами анализа и проектирования, применяемыми при объектно-ориентированной разработке. Быстрое прототипирование особенно хорошо подходит для разработки интенсивно используемых систем пользовательского интерфейса, таких как индикаторные панели для контрольных приборов, интерактивные системы, новые в своем роде продукты, а также системы обеспечения принятия решений, среди которых можно назвать подачу команд, управление или медицинскую диагностику.