1.2. Модели жизненного цикла программного обеспечения

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

Каскадная (водопадная) модель 

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

Водопад, как Каскадная модель жизненного цикла ПО

Поэтапная модель с промежуточным контролем еще известна как итерационная модель или «водоворот»

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

 Модель характеризуется следующими свойствами взаимодействия этапов:

 - модель состоит из последовательно расположенных этапов (точно так же, как и «водопад»);

 - каждый этап имеет обратную связь с предыдущими этапами;

 - исправление ошибок происходит на каждом из этапов, сразу при выявлении проблемы -- это промежуточный контроль;

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

 - результат появляется только в конце разработки, как и в модели «водопад».

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

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

Развитием идеи итераций является спиральная модель ЖЦПО, предложенная Боэмом. - модель состоит из последовательно расположенных этапов (как и «водопад») в пределах одного витка спирали;

 - внутри витка спирали этапы не имеют обратной связи. Анализ результата осуществляется в конце витка и инициирует новый виток спирали;

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

 - этапы могут перекрываться во времени в пределах одного витка спирали;

 - результат появляется в конце каждого витка спирали и подвергается подробному анализу, анализируются новые требования заказчика и инициируется новый виток спирали;

 - при переходе от витка к витку происходит накопление и повторное использование программных средств, моделей и прототипов;

 - процесс ориентирован на развитие и модификацию системы в процессе ее проектирования, на анализ рисков и издержек в процессе проектирования.

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). Подход RAD предусматривает наличие трех составляющих:

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

 • короткого, но тщательно проработанного производственного графика (до 3 месяцев);

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

 

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