V -образная («шарнирная») модель.

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

Рис. 4. Структура V-образной модели ЖЦ АИС (ПО) на ранних стадиях разработки (пунктирные линии на рисунке указывают на зависимость этапов постановки задачи и приемки).

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

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

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

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

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

Инкрементная модель.

Является классическим примером применения инкрементной стратегии и представляет собой повторяющийся цикл линейных последовательностей каскадной модели.

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

Рис.5. Схема инкрементной модели ЖЦ

 

Спиральная модель.

Каждый виток спирали соответствует созданию нового фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и

планируются работы следующего витка спирали (рис. 6). Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также «продолжающимся проектированием». Позднее в проектный цикл дополнительно стали включать стадии разработки и апробации прототипа системы. Это называлось: «быстрое прототипирование», «rapid prototyping approach» или «fast-track».

               Спиральная модель Рис.6

Спиральная модель была предложена Б. Боэмом (Barry Boehm) в 1988 г. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Сам Б. Боэм так характеризует спиральную модель разработки: «Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время, ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта».

Спиральная модель обладает рядом преимуществ:

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

Модель «фазы-функции».

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

Одно из наиболее последовательных таких дополнений классических схем реализовано в модели Гантера в виде матрицы «ф а з ы - ф у н к ц и и», которая имеет две координаты (табл. 2.):

• фазы — отражает этапы выполнения проекта и сопутствующие им события;

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

Таблица 2.. Матрица «фазы-функции» модели Гантера

В данной модели жизненный цикл распадается на следующие перекрывающие друг друга фазы (этапы):

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

На протяжении фаз жизненного цикла разработчики выполняют следующие технологические (организационные) функции (классы функций):

• • планирование;
• • разработку;
• • обслуживание;
• • выпуск документации;
• • испытания;
• • поддержку;
• • сопровождение.

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

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

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