этапов.
Какие модели можно исключить и почему? Модель Build-and-fix имеет смысл исключить сразу, если решение будет расширяться, а проект необходимо сопровождать. Конечно, этот проект может выйти за рамки 1000 строк, что является пределом для этой модели. Кроме того, программный продукт – законченное решение, включающее помимо кода множество документации: техническое задание (или другой документ со спецификацией требований), большое количество сценариев использования (десятки, сотни страниц), диаграмм, описывающих динамику поведения системы (переходов состояния, потоков данных, последовательности, взаимодействия, классов). Таким образом, модель Build-and-fix существенно ограничена и для данного проекта неприменима.
Водопадная модель требует от заказчика достаточно глубокого знания технических данных, потому что необходимо в один проход жизненного цикла реализовать всю функциональность продукта, следовательно, она не подходит.
Инкрементальная модель тоже не подходит, потому что одно из важных условий состоит в том, что заказчик планирует сразу получить пусть не очень сложный, но работоспособный магазин, поэтому полумеры с точки зрения функциональности его не устраивают. Кроме того, продукт планируется расширять, поэтому использовать эту модель также нельзя. Может быть, если бы развитие было более плавным или удалось договориться о том, чтобы на первом этапе значительную часть функциональности оставить за бортом, модель была бы пригодна. Как вариант ее, наверное, рассматривать можно, но с точки зрения характера задачи это не оптимальный выбор.
Модель синхростабилизации здесь тоже в полной мере не применима, потому что она требует достаточно серьезных и специфических знаний по тестированию, предполагает частую сборку и интеграцию компонента тестирования. Так как этот проект не является достаточно большим для применения такого подхода, применять его нецелесообразно.
Нельзя сказать, что инкрементальная модель или модель синхростабилизации не подходит, но существуют ограничения, из-за которых можно лишь с оговорками применять их в данном случае.
Какие модели могут быть использованы вполне, но с некоторыми замечаниями? Модель быстрого прототипирования будет в это случае вполне уместна. Естественно, не как самостоятельная, а как сопровождающая некоторую более серьезную модель. Она применима, потому что у заказчика нет в полной мере четкого представления о функционале и недостает технических знаний, чтобы очертить требования и оговорить функциональность, которая должна быть реализована. Поэтому очень сложно организовать диалог разработчика с заказчиком: они фактически говорят на разных языках. В этом случае на помощь приходит прототип, который как раз и проявит ту функциональность, о которой, возможно, мечтал заказчик, но не формулировал ее явно в силу ограниченности своих технических знаний. С другой стороны, она даст основания разработчику для того, чтобы
