Проведем итоговое сравнение преимуществ и недостатков рассмотренных моделей. В концентрированном виде, в табличной форме они представлены на слайде. Что мы здесь можем отметить? По моделям, по каждой из моделей. Модель «Build-and-Fix», как уже отмечалось, хороша для небольших, не превышающих 1000 строк, продуктов. И совершенно не подходит для нетривиальных программных проектов. Что касается водопадной модели. Она является документноуправлемой. Насколько мы помним, по завершению каждой стадии разработчик и заказчик подписывают тот или иной документ, скажем, технические требования, техническое задание, акт о вводе в эксплуатацию и т. д. И таким образом она требует четкой дисциплины проекта. При несоблюдении это дисциплины вполне тот продукт, который мы разрабатываем, может не устроить заказчика, а сам жизненный цикл вырождается в, по сути дела, подход проб и ошибок. Что касается модели быстрого прототипирования. Эта модель не приводит к созданию полно масштабного продукта с точки зрения эксплуатационных характеристик. Естественно, в данном случае при прототипировании мы, как правило, не имеем возможности провести исчерпывающее тестирование, обеспечить безопасность, обеспечить надежность, обеспечить отказоустойчивость, обеспечить в ряде случаев достаточную эргономику, обеспечить доступность, производительность и т. д. Поэтому то, что мы производим, на самом деле обладает лишь отдельными характеристиками, которые имитируют продукт, но не являются продуктом. В этой связи рекомендуется, настоятельно рекомендуется использовать модель быстрого прототипирования, для того чтобы понять, каким путем нам нужно развивать продукт и для того чтобы нам предпринимать правильные шаги по его развитию, но не для того чтобы этот продукт производить. И, вообще говоря, тот код, который разработан при производстве прототипа, рекомендуется выбросить и заново переразработать при производстве полно масштабного продукта. Что касается других моделей. Инкрементальная модель. Та самая, при разработке которой релизы напоминают матрешки, когда функциональность каждой версии вкладывается в предыдущие. Что здесь хорошо? Что является преимуществом? Обеспечивается ранний возврат инвестиций, поскольку заказчик может достаточно быстро получить отдачу от того первого релиза, который уже введен в эксплуатацию, и использовать те средства, которые возвращаются, для оплаты производства последующих релизов. Другое преимущество — это сопровождаемость, хорошая сопровождаемость, поскольку вводится в эксплуатацию не вся функциональность, а она вводится порелизно, поэтапно. Заказчик имеет возможность спокойно освоить небольшими порциями ту функциональность, начиная с самой важной, которая ему необходима, и заканчивая теми дополнениями, которые так же требуются для обеспечения конкурентоспособности. Ну какие недостатки у этой модели? Она требует открытой архитектуры. В случае если продукт требует революционного развития, она вполне может выродиться в Build-and-Fix, в непредсказуемую разработку. И этой является существенным недостатком. Что касается следующих моделей. Они в определенном смысле представляют сложность для разработки. Модель синхронизации и стабилизации включает 2 упомянутых процесса, которые являются достаточно сложными для реализации и технологически, и организационно. В этой связи модель достаточно редко используется вне Microsoft. И ее реализация в ряде случаев приводит к существенным проблемам. Что касается спиральной модели. Спиральная модель требует оценки рисков и потому, что это дорогостоящее мероприятие, и потому, что в ряде случаев требуется раскрывать существенную информацию экспертам, которые работают вне корпорации, это может вызывать проблемы. Таким образом, спиральная модель наиболее подходит для крупных проектов, поскольку оценка рисков — это мероприятие затратное. Общая экономика проекта должна быть достаточно внушительной. Но тех крупных проектов, которые реализуются внутри корпорации. Что касается объектно-ориентированной модели. За счет того, что возможно и зачастую требуется перекрытие фаз и интенсивный параллелизм между ними, здесь также необходима существенная дисциплина при разработке. Недисциплинированная разработка, не вполне точное соответствие стандартам может привести к тому, что жизненный цикл превращается в, опять-таки, модель кодируй и фиксируй, в модель проб и ошибок.
