Модели жизненного цикла ПО

Размещено на http://www.allbest.ru/

2

Модели жизненного цикла ПО

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

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель ЖЦ ПО. Положения стандарта являются общими для любых моделей ЖЦ, методов и технологий создания ПО. Стандарт описывает структуру процессов ЖЦ ПО, не конкретизируя в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Известны следующие модели ЖЦ: каскадная, V-образная, эволюционная модель прототипирования, модель быстрой разработки приложений RAD, инкрементная модель, спиральная модель, адаптированные модели к среде разработки (4).

Любая модель включает в себя:

Стадии

Результаты выполнения работ на каждой стадии

Ключевые события - точки завершения работ и принятия решений.

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

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

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

Различные подходы к составу и наименованию стадий

ГОСТ 34	Бари У. Боэм (спиральная модель ЖЦ)	Oracle CDM	Rational Unified Process (RUP)
Формирование требований к АС. Разработка концепции АС. Техническое задание.	Анализ осуществимости системы. Планирование и анализ требований к ПО.	Стратегия. Анализ.	1. Начальная стадия (Inception).
Эскизный проект. Технический проект.	Проектирование изделия. Детальное проектирование.	Проектирование.	2. Разработка (Elaboration).
Рабочая документация.	Кодирование.	Реализация.	3. Конструирование (Constraction).
Ввод в действие. Сопровождение.	Внедрение. Функционирование (эксплуатация). Сопровождение.	Внедрение. Эксплуатация. Сопровождение.	4. Ввод в действие (Transition).

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

На каждой стадии выполняются несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью ЖЦ ПО.

Рассмотрим некоторые модели ЖЦ ПО.

КАСКАДНАЯ МОДЕЛЬ ЖЦ ПО

В 1970 году каскадная модель (рис. 1) была впервые определена как альтернативный вариант метода разработки ПО по принципу кодирование-устранение ошибок, который был широко распространен в то время. Эта модель была регламентирована множеством нормативных документов, в частности широко известным стандартом США DOD-STD-2167A и российскими стандартами ГОСТ 34.

Рис. 1. Классическая каскадная модель ЖЦ ПО

Рис. 2. Реальный процесс разработки ПО (с обратной связью)

Свойства классической каскадной модели ЖЦ:

Фиксация требований к системе до ее сдачи Заказчику.

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

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

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

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

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

На каждой стадии формируется законченный набор проектной документации.

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

Использование каскадной модели:

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

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

Но процесс создания ПО носит, как правило, итерационный характер, т.е. результаты очередной стадии часто вызывают изменения в решениях, принятых на ранних стадиях. Т.о., возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает вид каскадной модели с обратной связью (рис. 2).

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

Позднее обнаружение проблем.

Выход из календарного графика, запаздывание с получением результатов.

Избыточное количество документации.

Невозможность разбить систему на части (весь продукт разрабатывается за один раз).

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

Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами:

Пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки.

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

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

V-образная модель жизненного цикла разработки ПО

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

Рис. 3. V-образная модель ЖЦ ПО

Преимущества V-образной модели

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

предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;

определение требований выполняется перед разработкой проекта системы, а проектирование ПО -- перед разработкой компонентов;

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

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

Недостатки V-образной модели

не учтена возможность параллельных работ;

не учтены итерации между фазами;

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

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

в модель не входят действия, направленные на анализ рисков.

Область применения V-образной модели

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

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

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

Модель эволюционного прототипирования жизненного цикла разработки ПО

Описание структурной модели эволюционного прототипирования

Прототипирование -- это процесс построения рабочей модели системы.

Прототип -- это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.

Начало жизненного цикла разработки помещено в центре эллипса.

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

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

Рис. 4. Модель эволюционного прототипирования

Действия:

Создается план проекта.

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

Быстрый анализ.

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

Создание базы данных.

Разработка пользовательского интерфейса (меню).

Разработка функций.

Т.о., создается рабочая модель.

Итерационный цикл быстрого прототипирования.

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

Утверждение пользователем.

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

Производная разработка.

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

Подгонка.

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

Эксплуатация и сопровождение.

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

Преимущества структурной эволюционной модели быстрого прототипирования

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

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

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

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

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

обеспечивается управление рисками;

документация сконцентрирована на конечном продукте, а не на его разработке;

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

Недостатки структурной эволюционной модели быстрого прототипирования:

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

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

с учетом создания рабочего прототипа, качеству ПО и надежности уделяется недостаточного внимания.

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

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

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

прототипирование вызывает зависимость и может продолжаться слишком долго.

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

Область применения структурной эволюционной модели быстрого прототипирования

Менеджер проекта может быть уверен в необходимости применения структурной эволюционной модели быстрого прототипирования, если:

требования не известны заранее;

нужна проверка концепции;

пользователь требует периодические демонстрации;

выполняется новая, не имеющая аналогов разработка, при этом высокая степень риска;

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

алгоритмы или системные интерфейсы усложнены;

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

прототипирование всегда следует использовать вместе с элементами анализа и проектирования, применяемыми при объектно-ориентированной разработке.

Модель быстрой разработки приложений RAD (RAPID APPLICATION DEVELOPMENT)

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

Отличительные черты RAD:

Короткое время перехода от определения требований до создания полной системы.

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

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

Фазы модели RAD

Модель RAD проходит через следующие фазы:

Этап планирования требований -- сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач;

Пользовательское описание -- совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные средства, обеспечивающие сбор пользовательской информации;

Фаза конструирования ("до полного завершения") -- эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависит от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств;

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



Рис. 5. Модель быстрой разработки приложений

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

время цикла разработки сокращается благодаря использованию мощных инструментальных средств;

требуется меньшее количество специалистов (поскольку разработка системы выполняется усилиями команды, осведомленной в предметной области);

существует возможность произвести быстрый изначальный просмотр продукта;

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

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

обеспечивается эффективное использование имеющихся в наличии средств и структур;

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

в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

интеграции констант предотвращают возникновение проблем и способствуют созданию обратной связи с потребителем;

основное внимание переносится с документации на код, причем при этом справедлив принцип "получаете то, что видите" (What you see is what you get, WYSIWYG);

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

повторное использование компонент уже существующих программ.

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

Непостоянное участие пользователя может негативно сказаться на конечном продукте (т.е. если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конечном продукте);

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

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

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

возникает потребность в системе, которая может быть смоделирована корректным образом;

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

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

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

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

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

Область применения модели RAD

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

в системах, которые поддаются моделированию (тех которые основаны на использовании компонентных объектов), а также в масштабируемых системах;

в системах, требования для которых в достаточной мере хорошо известны;

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

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

при невысокой степени технических рисков;

при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки (как правило, не более, чем за 60 дней);

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

когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов;

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

когда затраты и соблюдение графика не являются самым важным вопросом (например при разработке внутренних инструментальных средств);

в информационных системах;

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

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

Инкрементная модель действует по принципу каскадной модели с перекрытиями.

Рис. 6. Инкрементная модель ЖЦ разработки ПО

На инкременте 1 определяются базовые алгоритмы и выходные данные.

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

На инкременте 3 добавляются различные полезные свойства к пользовательскому интерфейсу, а также к заранее определенным вычислительным свойствам системы.

Фазы инкрементной модели ЖЦ разработки ПО

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

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

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

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

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

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

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

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

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

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

ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);

снижается риск неудачи и изменения требований;

заказчики могут распознавать самые важные и полезные функциональные возможности продукта на более ранних этапах разработки;

риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);

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

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

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

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

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

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

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

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

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

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

ощутимые признаки прогресса при выполнении проекта помогают поддерживать вызванное соблюдением графика "давление" на управляемом уровне.

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

в модели не предусмотрены итерации в рамках каждого инкремента;

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

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

заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены;

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

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

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

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

Область применения инкрементной модели

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

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

если рыночное окно слишком "узкое" и существует потребность быстро поставить на рынок продукт, имеющий функциональные базовые свойства;

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

при равномерном распределении свойств различной степени важности;

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

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

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

когда однопроходная разработка системы связана с большой степенью риска;

когда результативные данные получаются через регулярные интервалы времени.

Спиральная модель жизненного цикла разработки ПО

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

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



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

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

спиральная модель разрешает пользователям "увидеть" систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки ПО;

обеспечивается определение непреодолимых рисков без особых дополнительных затрат;

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

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

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

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

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

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

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

повышается продуктивность благодаря использованию пригодных для повторного использования свойств;

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

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

можно выполнять частую оценку совокупных затрат, а уменьшение рисков связано с затратами.

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

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

модель имеет усложненную структуру, поэтому может быть затруднено ее применение разработчиками, менеджерами и заказчиками;

серьезная нужда в высокопрофессиональных знаниях для оценки рисков;

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

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

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

при выполнении действий на этапе вне процесса разработки возникает необходимость в переназначении разработчиков;

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

отсутствие хорошего средства или метода прототипирования может сделать использование модели неудобным;

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

Область применения спиральной модели

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

когда создание прототипа представляет собой подходящий тип разработки продукта;

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

когда организация обладает навыками, требуемыми для адаптации модели;

для проектов, выполнение которых сопряжено со средней и высокой степенью риска;

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

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

когда требования слишком сложные;

при разработке новой функции или новой серии продуктов;

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

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

в случае больших проектов;

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

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

когда преимущества разработки невозможно точно определить, а достижение успеха не гарантировано;

с целью демонстрации качества и достижения целей за короткий период времени;

когда в процесс вовлекаются новые технологии, такие как впервые применяемые объектно-ориентированные принципы;

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

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

Выбор приемлемой модели жизненного цикла разработки ПО

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

Проанализируйте следующие отличительные категории проекта, помещенные в таблицах 1-4:

Требования: таблица 1.

Команда разработчиков: таблица 2.

Коллектив пользователей: таблица 3.

Тип проекта и риски: таблица 4.

Ответьте на вопросы, приведенные для каждой категории, обведя кружочком слова "да" или "нет".

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

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

Отличительные категории проекта

Ниже приводится краткое описание характеристик и требований к команде разработчиков, коллективу пользователей, типу проекта и рискам.

В табл. 1-4 приведен набор матриц, предназначенных для использования на стадиях 1-5 процесса выбора модели жизненного цикла (см. предыдущую лекцию, «Основные процессы ЖЦ ПС»).

Требования. Категория требований (табл. 12) состоит из вопросов относительно требований, которые предъявляет пользователь к проекту. В терминологии их иногда называют свойствами системы, которая будет поддерживаться данным проектом.

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

Требования	Каскадная	V-образная	Прототипи-рование	Спиральная	RAD	Инкрементная
1. Являются ли требования легко определимыми и/или хорошо известными?	Да	Да	Нет	Нет	Да	Нет
2. Могут ли требования заранее определяться в цикле?	Да	Да	Нет	Нет	Да	Да
3. Часто ли будут изменяться требования в цикле?	Нет	Нет	Да	Да	Нет	Нет
4. Нужно ли демонстрировать требования с целью определения?	Нет	Нет	Да	Да	Да	Нет
5. Требуются ли для демонстрации возможностей или проверка концепции?	Нет	Нет	Да	Да	Да	Нет
6. Будут ли требования отражать сложность системы?	Нет	Нет	Да	Да	Нет	Да
7. Обладает ли требование функциональными свойствами на раннем этапе?	Нет	Нет	Да	Да	Да	Да

Команда разработчиков. По возможности, в состав команды разработчиков лучше всего отобрать персонал еще до того, как будет выбрана модель жизненного цикла. Характеристики такой команды (табл. 2) играют важную роль в процессе выбора, поскольку она несет ответственность за удачное выполнение цикла и может оказать помощь в процессе выбора.

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

Команда разработчиков проекта	Каскадная	V-образная	Прототипиро-вание	Спиральная	RAD	Инкрементная
1. Являются ли проблемы предметной области проекта новыми для большинства разработчиков?	Нет	Нет	Да	Да	Нет	Нет
2. Является ли технология предметной области проекта новой для большинства разработчиков?	Да	Да	Нет	Да	Нет	Да
3. Являются ли инструменты, используемые проектом, новыми для большинства разработчиков?	Да	Да	Нет	Да	Нет	Нет
4. Изменяются ли роли участников проекта во время жизненного цикла?	Нет	Нет	Да	Да	Нет	Да
5. Могут ли разработчики проекта пройти обучение?	Нет	Да	Нет	Нет	Да	Да
6. Является ли структура более значимой для разработчиков, чем гибкость?	Да	Да	Нет	Нет	Нет	Да
7. Будет ли менеджер проекта строго отслеживать прогресс команды?	Да	Да	Нет	Да	Нет	Да
8. Важна ли легкость распределение ресурсов?	Да	Да	Нет	Нет	Да	Да
9. Приемлет ли команда равноправные обзоры и инспекции, менеджмент (обзоры) заказчика, а также стадии?	Да	Да	Да	Да	Нет	Да

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

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

Коллектив пользователей	Каскадная	V-образная	Прототипиро-вание	Спиральная	RAD	Инкрементная
1. Будет ли присутствие пользователей ограничено в жизненном цикле?	Да	Да	Нет	Да	Нет	Да
2. Будут ли пользователи знакомы с определением системы?	Нет	Нет	Да	Да	Нет	Да
3. Буду ли пользователи ознакомлены с проблемами предметной области?	Нет	Нет	Да	Нет	Да	Да
4. Будут ли пользователи вовлечены во все фазы жизненного цикла?	Нет	Нет	Да	Нет	Да	Нет
5. Будет ли заказчик отслеживать ход выполнения проекта?	Нет	Нет	Да	Да	Нет	Нет

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

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

Тип проекта и риски	Каскадная	V-образная	Прототипиро-вание	Спиральная	RAD	Инкрементная
1. Будет ли проект идентифицировать новое направление продукта для организации?	Нет	Нет	Да	Да	Нет	Да
2. Будет ли проект иметь тип системной интеграции?	Нет	Да	Да	Да	Да	Да
3. Будет ли проект являться расширением существующей системы?	Нет	Да	Нет	Нет	Да	Да
4. Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла?	Да	Да	Да	Нет	Да	Нет
5. Ожидается ли длительная эксплуатация продукта в организации?	Да	Да	Нет	Да	Нет	Да
6. Должна ли быть высокая степень надежности?	Нет	Да	Нет	Да	Нет	Да
7. Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения?	Нет	Нет	Да	Да	Нет	Да
8. Является ли график ограниченным?	Нет	Нет	Да	Да	Да	Да
9. Являются ли "прозрачными" интерфейсные модули?	Да	Да	Нет	Нет	Нет	Да
10. Доступны ли повторно используемые компоненты?	Нет	Нет	Да	Да	Да	Нет
11. Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)?	Нет	Нет	Да	Да	Нет	Нет

Подгонка модели жизненного цикла разработки ПО

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

Согласно модели SEI СММ, не существует каких-либо четких предписаний на сей счет: "Руководящие принципы и критерии для адаптации стандартного процесса разработки ПО данной организации к выбранным проектам получают путем разработки и последующего утверждения", а также "определенный процесс разработки ПО в рамах данного проекта является адаптированной версией стандартного процесса разработки ПО для данной организации".

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

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

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

1. Ознакомьтесь с различными моделями.

2. Просмотрите и проанализируйте возможные виды работ: разработка, модернизация, сопровождение и т.д.

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

Проанализируйте, насколько выбранный жизненный цикл соответствует стандартам вашей организации, ваших заказчиков или типа проекта -- ISO, IEEE и т.д.

Сформулируйте набор фаз и действий, образующих каждую фазу.

Определите внутренние и внешние производимые продукты.

Определите шаблоны и внутреннее содержимое поставляемых продуктов.

Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта.

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

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

жизненный цикл стадия

Размещено на Allbest.ru

...