Реферат: Модели жизненного цикла информационного проекта

Недостатки спиральной модели. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее — враг хорошего». Поэтому завершение итерации необходимо проводить строго в соответствии с планом, даже если не вся запланированная работа закончена.

Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Инкрементная модель жизненного цикла

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

Рис. 5. Инкрементная модель жизненного цикла

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

С точки зрения структуры жизненного цикла модель называют итеративной (говоря о процессе). С точки зрения развития продукта – инкрементной (имеется ввиду наращивания функциональности продукта). Инкремент – приращение, увеличение (например, в языке программирование – увеличение значения переменной на 1).

Для каждого инкремента выполняется:

• анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;
• проектирование, на котором происходит проектирование архитектуры, допроектирование тех вещей, которые не были сделаны на предыдущем инкременте;
• разработка;
• тестирование.

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

Сам подход является однократным, т.е. мы весь наш проект делаем за один большой этап, имея в виду требования, но весь проект делится на инкременты, это небольшие версии продуктов, для которых заранее определена функциональность. Т.е. мы говорим, что у нас вся длительная разработка состоит, например, из 5 фаз. На первом этапе получим однопользовательскую версию, на втором инкременте (фазе) мы получим версию, которая поддерживает много пользователей, на третьем инкременте у нас появится поддержка веб-интерфейсов, а на четвертом какое-нибудь протоколирование и так далее. Т.е. хоть требования у нас все равно задаются только один раз, но на выходе у нас появляется несколько инкрементов. Различия между инкрементной и итеративной (спиральной) моделями показана на рисунке 6.

Рис. 6. Иллюстрация различий между инкрементной и итеративной (спиральной) моделями

Преимущества инкрементной модели:

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

Недостатки инкрементной модели:

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