Водопадная модель требует от заказчика достаточно глубокого знания технических данных, потому что необходимо в один проход жизненного цикла реализовать всю функциональность продукта, следовательно, она не подходит.
Инкрементальная модель тоже не подходит, потому что одно из важных условий состоит в том, что заказчик планирует сразу получить пусть не очень сложный, но работоспособный магазин, поэтому полумеры с точки зрения функциональности его не устраивают. Кроме того, продукт планируется расширять, поэтому использовать эту модель также нельзя. Может быть, если бы развитие было более плавным или удалось договориться о том, чтобы на первом этапе значительную часть функциональности оставить за бортом, модель была бы пригодна. Как вариант ее, наверное, рассматривать можно, но с точки зрения характера задачи это не оптимальный выбор.
Модель синхростабилизации здесь тоже в полной мере не применима, потому что она требует достаточно серьезных и специфических знаний по тестированию, предполагает частую сборку и интеграцию компонента тестирования. Так как этот проект не является достаточно большим для применения такого подхода, применять его нецелесообразно.
Нельзя сказать, что инкрементальная модель или модель синхростабилизации не подходит, но существуют ограничения, из-за которых можно лишь с оговорками применять их в данном случае.
Какие модели могут быть использованы вполне, но с некоторыми замечаниями? Модель быстрого прототипирования будет в это случае вполне уместна. Естественно, не как самостоятельная, а как сопровождающая некоторую более серьезную модель. Она применима, потому что у заказчика нет в полной мере четкого представления о функционале и недостает технических знаний, чтобы очертить требования и оговорить функциональность, которая должна быть реализована. Поэтому очень сложно организовать диалог разработчика с заказчиком: они фактически говорят на разных языках. В этом случае на помощь приходит прототип, который как раз и проявит ту функциональность, о которой, возможно, мечтал заказчик, но не формулировал ее явно в силу ограниченности своих технических знаний. С другой стороны, она даст основания разработчику для того, чтобы корректно проектировать и реализовывать программный продукт, избавит разработчика и заказчика от непроизводительных потерь времени, людских ресурсов и средств. Для создания быстрых прототипов подходят технологии Microsoft (Visual Studio). Там существуют хорошие конструкторы визуальных форм и отчетов. Возможно достаточно быстро представить заказчику вариант интерфейса, включая командные кнопки, меню в стиле Windows, привычном заказчику, и обсудить с ним детали будущей реализации, на основе которых можно четче сформулировать технические требования и, что очень важно, определить окончательный выбор модели, поскольку все еще есть различные варианты.
Теперь о моделях, которые в большей мере пригодны для решения этой задачи. Прежде всего это объектно-ориентированная модель. Понятно, что в интернет-магазине речь пойдет скорее всего об объектно-ориентированном приложении, которое реализует некоторые сценарии: взаимодействие пользователя с интерфейсом, взаимодействие компонентов системы. Понятия предметной области – корзина, заказ, товары – вполне хорошо могут быть реализованы на основе иерархии наследования. Потребуется большое количество атрибутов, соответствующих каждому артикулу товара: краткое словесное описание, полное описание, изображение, потому что если говорить об африканских редкостях, пользователю сложно оценить по словесному описанию, что же именно он хочет приобрести. Точно так же есть определенные атрибуты у корзины, заказа и т. д. При этом, конечно, объектно-ориентированную модель имеет смысл объединять с быстрым прототипированием, которое быстро реализуется и поможет при первом обсуждении проекта. При реализации полномасштабного продукта код, созданный при быстром прототипировании, необходимо будет начисто переписать.
Если планируется, что разрабатываемый продукт будет развиваться, можно будет применить инкрементальную модель, хотя и не совсем подходящую, или спиральную модель. Ее преимущества в том, что она подходит для реализации постоянно развивающегося программного средства. А в нашем случае заказчик, вероятно, потом захочет добавить дополнительную функциональность: например, подключение систем электронных платежей (WebMoney, Яндекс. Деньги и т. д.), кредитных карт (нужен будет сервер приложений, осуществляющий верификацию данных пользователей, проверку наличия достаточных средств на карте и т. д.), отслеживание пути движения заказа, sms-информирование клиента и т. д. Однако спиральная модель может не очень хорошо подходить, если этап анализа рисков очень дорог. Но для нашего проекта можем обойтись упрощенным анализом рисков – спиральная модель будет приемлемым решением.