Итеративный пошаговый жизненный цикл

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

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

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

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

Рис. 4. демонстрирует, что каждая итерация — маленький «водопад» типичных стадий жизненного цикла. Различия лишь в масштабе, как сказано выше. Теперь пользователь может часто и полностью использовать основной цикл стадии функционирования и сопровождения. Уроки предыдущей итерации немедленно используются в следующей итерации. Пользователь, вооруженный опытом использования предыдущей конструкции, может быть очень полезен в уточнении требований для следующей итерации. Текущий проект конструкции — отправная точка для проекта системы в следующей итерации. Внедрение итерации 2 продукта является началом итерации 3 и т. д.

Классическая модель итеративного жизненного цикла — спиральная модель. Современным представителем итеративного жизненного цикла является IBM Rational Unified Process® (RUP®) который создан из Rational Unified Process (RUP).

Рисунок 1.4. Итеративный жизненный цикл

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

Спиральная модельв действительности является метамоделью, в которой могут содержаться все другие модели жизненного цикла. Модель состоит из четырех секторов диаграммы в декартовых координатах (рис. 5). Сектора следующие: планирование, анализ рисков, инженерия и оценка проекта клиентом. Первая петля спирали начинается в секторе планирования и связана с начальным сбором требований и планированием проекта. Затем проект входит в сектор анализа рисков, где проводится анализ стоимости/выгоды и угроз/благоприятных случаев, чтобы принять решение «да-нет» относительно того, следует ли входить в сектор инженерии (или отказаться от проекта как слишком опасного). Сектор инженерии — это то, где происходит разработка ПО. Результат этой разработки (конструкция, опытный образец или даже конечный продукт) подвергается оценке клиентом, после чего начинается вторая петля спирали. Фактически спиральная модель имеет отношение к разработке ПО только в одном из этих четырех секторов — секторе инженерии. Акцент на повторном планировании проекта и оценке проекта клиентом дает всему этому явно итеративный характер. Анализ рисков уникален в спиральной модели. Частые исследования рисков позволяют провести раннюю идентификацию любых появляющихся рисков в проекте. Риски могут быть внутренние (находящиеся под управлением организации) и внешние (риски, которыми организация не может управлять). В любом случае задача анализа рисков состоит в том, чтобы смотреть в будущее, и если ясно, что риски неустранимы, проектирование должно быть прекращено безотносительно к затратам, уже израсходованным.

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

Рисунок 1.5. Спиральная модель ЖЦ

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

Литература

1 Технологии разработки программного обеспечения: Учебник/ С. Орлов. — СПб.: Питер, 2002. — 464 с.: ил.

2 Практическая программная инженерия на основе учебного примера/ Л.А.Мацяшек, Б.Л. Лионг: пер. с англ.. – М.:БИНОМ. Лаборатория знаний, 2011. – 956 с.

3 Программная инженерия. Методологические основы: Учеб. / В. В. Липаев ; Гос. ун-т — Высшая школа экономики. —М. : ТЕИС, 2006. — 608 с.

^[1] Понятие безнадежного проекта введено Эдвардом Йорданом. См. Эдвард Йордон. Путь камикадзе. 2-е изд. – М.: Лори, 2004

^[2] Брукс Ф. Мифический человеко-месяц или как создаются программные системы. – СПб.: Символ-Плюс, 1999