2.4 Выбор модели жц по

Жизненный цикл программного обеспечения — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

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

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

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

Первой во времени появления и самой распространённой явилась каскадная модель (водопад). Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, атте­стация и модернизация ПО), представляются как отдельные этапы этого процесса.

Последовательность фаз водопадной модели: анализ требований, проектирование, реализация, интеграция.

Каскадная модель характеризуется следующими основными особенностями:

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

• началом последующего этапа только после завершения предыдущего;

• отсутствием обратных связей между этапами;

• получением результата только в конце разработки.

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

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

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

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

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

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

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

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

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

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

1. анализ отличительных категорий проекта, помещенных в таблицах ниже;

2. ответьте на вопросы, приведённые для каждой категории, обведя кружочком слова «да» или «нет»;

3. Расположите по степени важности категории или вопросы, относящиеся к каждой категории, относительно выбранного проекта;

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

Таблица 2 – Выбор модели жизненного цикла на основе характеристик требований

Требования	Каскадная	Прототипирование	Спиральная	Инкрементная
Являются ли требования легко определимыми и хорошо известными	Да	Нет	Нет	нет
Могут ли требования заранее определяться в цикле	Да	Нет	Нет	да
Часто ли будут изменяться требования в цикле	Нет	Да	Да	нет
Нужно ли демонстрировать требования с целью определения	Нет	Да	Да	нет
Требуется ли для демонстрации возможностей проверка концепции	Нет	Да	Да	нет
Будут ли требования отражать сложность системы	Нет	Да	Да	Да
Обладает ли требование функциональными свойствами на раннем этапе	Нет	Да	Да	Да

Таблица 3 – Выбор модели жизненного цикла на основе характеристик участников команды разработчиков

Команда разработчиков проекта	Каскадная	Прототипирование	Спиральная	Инкрементная
Являются ли проблемы предметной области проекта новыми для большинства разработчиков	Нет	Да	Да	Нет
Является ли технология предметной области проекта новой для большинства разработчиков	Да	Нет	Да	Да
Являются ли инструменты, используемые проектом, новыми для большинства разработчиков	Да	Нет	Да	Нет
Изменяются ли роли участников проекта во время жизненного цикла	Нет	Да	Да	Да
Могут ли разработчики проекта пройти обучение	Нет	Нет	Нет	Да
Является ли структура более значимой для разработчиков чем гибкость	Да	Нет	Нет	Да
Будет ли менеджер проекта строго отслеживать прогресс команды	Да	Нет	Да	Да
Важна ли лёгкость распределения ресурсов	Да	Нет	Нет	Да
Приемлет ли команда равноправные обзоры и инспекции, менеджмент/обзоры заказчиков, а также стадии	Да	Да	Да	Да

Таблица 4 – Выбор модели жизненного цикла на основе характеристик коллектива пользователей

Коллектив	Каскадная	Прототипирование	Спиральная	Инкрементная
Будет ли присутствие пользователей ограничено в жизненном цикле	Да	Нет	Да	Да
Будут ли пользователи знакомы с определением системы	Нет	Да	Да	Да
Будут ли пользователи ознакомлены с проблемами предметной области	Нет	Да	Нет	Да
Будут ли пользователи вовлечены во все фазы жизненного цикла	Нет	Да	Нет	Нет
Будет ли заказчик отслеживать ход выполнения проекта	Нет	Да	Да	Нет

Таблица 5 – Выбор модели жизненного цикла но основе характеристик типа проектов и рисков

Тип проекта и риски	Каскадная	Прототипирование	Спиральная	Инкрементная
Будет ли проект идентифицировать новое направление продукта для организации	Нет	Да	Да	Да
Будет ли проект иметь тип системной интеграции	Нет	Да	Да	Да
Будет ли проект являться расширением существующей системы	Нет	Нет	Нет	Да
Будет ли финансирование проекта стабильным на всём протяжении жизненного цикла	Да	Да	Нет	Нет
Ожидается ли длительная эксплуатация продукта в организации	Да	Нет	Да	Да
Должна ли быть высокая степень надёжности	Нет	Нет	Да	Да
Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения	Нет	Да	Да	Да
Является ли график ограниченным	Нет	Да	Да	Да
Являются ли «прозрачными» интерфейсные модули	Да	Нет	Нет	Да
Доступны ли повторно используемые компоненты	Нет	Да	Да	Нет
Являются ли достаточными ресурсы (время инструменты, персонал)	Нет	Да	Да	Нет

Методические рекомендации

В рамках ранее созданных проектных групп необходимо выбрать наиболее подходящую для вашей группы модель разработки программного обеспечения. Для обеспечения квалифицированного выбора участникам группы необходимо изучить предложенные модели, их преимущества и недостатки. При осуществлении выбора стоит ответить на вопросы, в значительной степени обуславливающие выбор. Каковы основные характеристики требований к проекту (сформулированы ли требования в полном объёме, насколько они изменяемы и т.д.)? Каков состав проектной группы и какова компетенция участников (все ли члены команды владеют предметной областью? Все ли знакомы с предполагаемым инструментарием и т.д.)? Какие ограничения на модель возлагает выбранный тип проекта?

Сделанный группой выбор следует обосновать. Также по результатам реализации проекта требуется рассмотреть моменты отклонения этапов процесса от эталонных этапов модели.