Реферат: Нижегородский государственный университет им. Н. И

Нижегородский государственный университет им. Н.И. Лобачевского

Факультет вычислительной математики и кибернетики ННГУ


Учебно-исследовательская лаборатория
"Математические и программные технологии для современных компьютерных систем (Информационные технологии)"

Обзор моделей жизненного цикла разработки программного обеспечения


Куратор мини-проекта:

Карпенко С.Н.

Составители:

Вершинина Е.В.

Гонченко М.С.


Содержание
Содержание 3

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

^ Определение модели ЖЦ разработки ПО 4

Жизненный цикл – это своего рода «карта-путеводитель» для всех участников проекта, которая помогает им понять, не выходят ли они за определенные для них границы. Для управления программным проектом возникает необходимость в некотором роде карты для планирования действий и хронологий их выполнения. 5

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

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

Краткое описание фаз каскадной модели 9

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

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

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

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

Фазы V-образной модели 13

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

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

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

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

Определения прототипирования 16

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

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

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

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

^ Модель быстрой разработки приложений RAD (Rapid Application Development) 22

Фазы модели RAD 22

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

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

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

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

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

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

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

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

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

Стадии разработки спиральной модели 28

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

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

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

^ Адаптированные модели жизненного цикла разработки ПО 32

Быстрое отслеживание 32

Параллельный инжиниринг 33

Спиральная модель "Win-Win" 33

Эволюционный/инкрементный принцип 34

Принцип V-образной инкрементной модели 34

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

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

Ниже приводится краткое описание характеристик и требований к команде разработчиков, коллективу пользователей, типу проекта и рискам. В табл. 1-4 приведен набор матриц, предназначенных для использования на стадиях 1-5 процесса выбора модели жизненного цикла, описание которого было приведено в предыдущем разделе. 35

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

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

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

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

Резюме 38
^ Модели жизненного цикла разработки ПО


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

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

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


Жизненный цикл


Процесс



















Рис. 1. Обобщенная схема процесса


Модель жизненного цикла разработки ПО является единственным видом процесса, в котором представлен порядок его осуществления. Модель жизненного цикла разработки ПО (Software Life Cycle Model, SLCM) схематически объясняет, каким образом будут выполняться действия по разработке программного продукта, посредством описания «последовательности» этих действий. Такая последовательность может быть или не быть линейной, поскольку фазы могут следовать друг за другом, повторяться или происходить одновременно. На рис. 1 представлена простая обобщенная схема процесса.

^ Модель SLCM – это схема (или основа), используемая разработчиком ПО для определения повторяющегося процесса при создании программного продукта. Она определяет точные инструкции, которые разработчик может использовать для создания только высококачественных программных систем. Понятие жизненного цикла ПО относится ко всем программным проектам, причем независимо от их размеров.
Жизненный цикл – это своего рода «карта-путеводитель» для всех участников проекта, которая помогает им понять, не выходят ли они за определенные для них границы. Для управления программным проектом возникает необходимость в некотором роде карты для планирования действий и хронологий их выполнения. В стандарт, разработанный для немецких ИТ-систем, были включены описания причин, объясняющих необходимость выполнения стандартизированного процесса. Этот стандарт помогает достичь следующих целей.
Улучшение и обеспечение качества:

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

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

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

Возможность проверки затрат на выполнение полного жизненного цикла:

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

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

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

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

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

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

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

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

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

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

«Каркасом» процесса разработки ПО служит модель зрелости функциональных возможностей (Capability Maturity Model, CMM). Она основана на практических действиях, отображает лучшие результаты и определяет потребности индивидов, работающих над усовершенствованием процесса разработки ПО и выполняющих оценочный анализ этого процесса. Модель СММ представляет собой схему, по которой этапы разработки соответствуют пяти уровням развития функциональных возможностей, на основе которых осуществляется непрерывное усовершенствование процесса разработки.

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

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

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

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

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

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

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

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

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

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

В первые годы практики программирования сначала записывался программный код, а затем происходила его отладка. Общепринятым считалось правило начинать работу не с разработки плана, а с общего ознакомления с продуктом. Без лишних формальностей можно было спроектировать, закодировать, отладить и протестиро­вать ПО еще до того, как оно будет готово к выпуску. Это напоминало процесс, изо­браженный на рис. 2. В структуре такого процесса есть несколько "неправиль­ностей" (или недостатков). Во-первых, поскольку изначально не существовало офи­циального проекта или анализа, невозможно было узнать о моменте завершения про­цесса. Также отсутствовал способ определения соответствия требованиям относи­тельно достижения качества.

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


Кодирование и тестирование



Делать, пока не будет сделано



Рис. 2. Модель процесса "делать, пока, не будет сделано”

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




Рис. 3. Классическая каскадная модель с обратной связью


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

она отличается стабильностью требований;

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

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

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

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

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

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

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

стадии модели довольно хорошо определены и понятны;

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



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

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

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

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

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

она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" — не несет никакого смысла и не является показа­телем для менеджера проекта;

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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




Рис. 4. V –образная модель жизненного цикла разработки ПО

^ Фазы V-образной модели

Ниже подано краткое описание каждой фазы V-образной модели, начиная от планирования проекта и требований вплоть до приемочных испытаний:

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

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

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

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

разработка программного кода – выполняется преобразование алгоритмов, определенных на этапе детализированного проектирования, в готовое ПО;

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

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

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

производство, эксплуатация и сопровождение – ПО запускается в производство. На этой фазе предусмотрены также модернизация и внесение поправок;

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



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

При использовании V-образной модели при разработке проекта, для которого она в достаточной мере подходит, обеспечивается несколько преимуществ:

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

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

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

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

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

модель проста в использовании (относительно проекта, для которого она является приемлемом).



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

При использовании V-образной модели в работе над проектом, для которого она не является в достаточной степени приемлемой, становятся очевидными ее недостатки:

с ее помощью непросто справиться с параллельными событиями;

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

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

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

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


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

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

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

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

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

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

^ Модель прототипирования жизненного цикла разработки ПО
Ставшее классикой произведение Фреда Брукса (Fred Brook) под названием "Легендарный человек-месяц" (The Mythical Man-Month) сегодня столь же актуаль­но, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки менеджмента программных проектов по-прежнему те же. Десятки лет тому назад Брукс сказал:

"В большинстве проектов первая построенная система едва ли пригодна к упот­реблению. Она может быть слишком медленной, слишком объемной, неудобной в ис­пользовании или обладать всеми тремя перечисленными недостатками. Нет другого выбора, кроме как начать с самого начала, приложив все усилия, и построить модер­низированную версию, в которой решались бы все три проблемы...

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

Следовательно, вопрос менеджмента заключается не в том, создавать или нет экс