Прототип – это первоначальная версия системы, которая используются для апробирования возможностей дизайна и демонстрирования идей. Прототипы можно использовать на различных фазах разработки. Например, на этапе анализа требований при их нахождении и проверке; на этапе дизайна при исследовании выбора возможностей и планировании пользовательского интерфейса.
Преимущества прототипов: лучшее удобство при использовании системы, более точная совместимость с реальными потребностями пользователей; более высокое качество и более лучшее удобство сопровождения и меньше трудностей при разработке.
Рисунок 1-4 Процесс создания прототипа
Этапы прототипирования являются следующими:
- Накопление требований – это делают на более общем уровне и там же фиксируют то, что в дальнейшем необходимо начать обязательно уточнять.
- Интенсивное планирование – сосредоточение внимания на видимой части (ввод, вывод, формы и т.д.), в результате чего и создается прототип. Клиент имеет возможность оценить прототип и на этой основе уточнить свои желания.
- Затем следует итерация улучшения прототипа до тех пор, пока это не удовлетворит пользователя. В то же время разработчик получает новые идеи исходя из пожеланий клиента.
При разработке прототипа важно, чтобы он мог бы быть быстро создан, используя вспомогательные инструменты (средства) (язык быстрого прототипирования и рабочие инструменты). Прототип не должен содержать в себе всей функциональности. Он должен сосредотачиваться на том, что не очень хорошо понятно. В прототипе не должно быть контроля ошибок, и прототип направлен на функциональные требования (например, на проблемы, связанные с безопасностью)
Прототипирование можно делать на различной основе – например, быстрое прототипирование (ühekordne prototüüpimine, Throwaway prototyping), эволюционное прототипирование (evolutsiooniline prototüüpimine, Evolutionary prototyping), инкрементное прототипирование (lisanduv prototüüpimine, Incremental prototyping).
Принципы быстрого прототипирования заключаются в следующем:
Такие прототипы должны быть уничтожены после создания, поскольку они не могут служить хорошей базой для реальной системы – например, не стоит на их основе выполнять нефункциональные требования, структура прототипа не подходит для дальнейшей разработки и также не отвечает требованиям качества модели.
Вкратце, в отличие от водопадной модели согласно итеративной модели разработки документ всестороннего анализа, который содержит неизменные требования пользователей и «подписывается на крови» между заказчиком системы и исполнителем, не составляется с самого начала. Итеративные модели позволяют проще вносить изменения в систему, получать от пользователей ранние отзывы, тестировать на ранней фазе пригодность проекта разработки архитектурного решения системы и т.п.Не существует единственной и наилучшей модели разработки системы. Решение, какую модель выбрать, необходимо вынести исходя из конкретного программного проекта: результата, навыков и знаний команды, временных графиков, выяснения и стабильности потребностей клиентов.