ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

·        Основные процессы жизненного цикла

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

·        Организационные процессы жизненного цикла

·       Каскадная стратегия разработки программных средств и систем

·        Инкрементная стратегия разработки программных средств и систем

·        Эволюционная стратегия разработки программных средств и систем

 

 

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

Процессы ЖЦ ПС делятся на три группы:

• основные;

•  вспомогательные;

•  организационные.

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

•заказ;

•  поставка;

•  разработка;

•  эксплуатация;

•  сопровождение.

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

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

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

1)  подготовка процесса разработки;

2)   анализ требований к системе;

3)  проектирование системной архитектуры;

4)   анализ требований к программным средствам;

5)  проектирование программной архитектуры;

6)  техническое проектирование программных средств;

7)  программирование и тестирование программных средств;

8)  сборка программных средств;

9)  квалификационные испытания программных средств;

10)   сборка системы;

11)  квалификационные испытания системы;

12)  ввод в действие программных средств;

13)   обеспечение приемки программных средств.

При выполнении работы 1 «Подготовка процесса разработки» выбирается модель ЖЦ ПС и систем. В данную модель структурируются процессы, работы и задачи стандарта СТБ ИСО/МЭК 12207-2003. Выбираются и адаптируются стандарты, методы, инструментальные средства разработки, языки программи­рования. Формируется план проведения работ процесса разработки.

При выполнении работы 2 «Анализ требований к системе» анализируется область применения системы. На основании результатов анализа предметной области определяются требования к ней. Выполняется оценка разработанных требований.

При выполнении работы 3 «Проектирование системной архитектуры» оп­ределяется общая архитектура системы. Осуществляется распределение требо­ваний к системе между объектами технических и программных средств архи­тектуры и ручными операциями. Производится дальнейшее уточнение требова­ний. Осуществляется оценка архитектуры системы и требований к объектам архитектуры.

При выполнении работы 4 «Анализ требований к программным средст­вам» анализируется назначение программного средства. Исходя из результатов анализа определяются и уточняются требования к программному средству. Вы­полняется оценка разработанных требований.

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

При выполнении работы 6 «Техническое проектирование программных средств» осуществляется детальное проектирование программного средства (разрабатывается технический проект для компонентов программного объекта). Компоненты проектируются до уровня их представления в виде набора про­граммных модулей. Сложность модулей должна обеспечить возможность их непосредственного кодирования в следующей работе (работе 7). Производится распределение технических требований к компонентам между программными модулями и дальнейшее уточнение требований. Выполняется оценка техниче­ского проекта.

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

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

При выполнении работы 9 «Квалификационные испытания программных средств» проводятся квалификационные испытания программного средства в моделируемой среде с моделируемыми исходными данными. Оцениваются ре­зультаты испытаний. При необходимости производится доработка программно­го продукта.

При выполнении работы 10 «Сборка системы» осуществляется сборка объектов программной и технической конфигурации, ручных операций, других подсистем в единую систему. Проводятся испытания собранной системы. Вы­полняется оценка собранной системы.

При выполнении работы 11 «Квалификационные испытания системы» проводятся квалификационные испытания собранной системы в моделируемой среде с моделируемыми исходными данными. По результатам испытаний вы­полняется оценка системы и при необходимости доработка программного продукта.

При выполнении работы 12 «Ввод в действие программных средств» про­граммный продукт вводится в действие в среде эксплуатации.

При выполнении работы 13 «Обеспечение приемки программных средств» обеспечивается проведение заказчиком приемочных испытаний. Про­граммный продукт поставляется заказчику.

В приведенной последовательности различают два вида работ: систем­ные и программные.

Системные работы начинают и завершают процесс разработки. К ним относятся работы с номерами 2, 3, 10, 11.

Работы процесса разработки с 4-й (анализ требований к программным средствам) по 9-ю (квалификационные испытания программных средств) пред­ставляют собой программные работы. Они выполняются над ПС, выделенны­ми из системы.

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

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

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

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

•документирование;

•  управление конфигурацией;

•  обеспечение качества;

•  верификация;

•  аттестация;

•  совместный анализ;

•  аудит;

•  решение проблем.

Вспомогательные процессы вызываются другими процессами ЖЦ.

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

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

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

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

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

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

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

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

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

•управление;

•  создание инфраструктуры;

•  усовершенствование;

•  обучение.

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

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

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

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

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

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

 

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

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

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

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

1)    стабильность требований в течение ЖЦ разработки;

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

3)    простота планирования, контроля и управления проектом;

4)     доступность для понимания заказчиками.

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

1)     сложность полного формулирования требований в начале процесса разработки и невозможность их динамического изменения на протяжении ЖЦ;

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

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

4)    недостаточное участие пользователя в процессе разработки ПС - толь­ко в самом начале (при разработке требований) и в конце (во время приемоч­ных испытаний); это приводит к невозможности предварительной оценки поль­зователем качества программного средства или системы.

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

1)    при разработке проектов с четкими, неизменяемыми в течение ЖЦ требованиями и понятной реализацией;

2)     при разработке проектов невысокой сложности, например:

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

•  создание новой версии уже существующего программного средства или системы;

•  перенос уже существующего продукта на новую платформу;

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

В документе рассмотрены модели ЖЦ, реализующие каскадную страте­гию разработки ПС и систем.

Резюме

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

 

Инкрементная стратегия разработки программных средств и систем

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

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

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

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

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

Особенностью инкрементной стратегии является большое количество циклов разработки при незначительной продолжительности цикла и небольших различиях между инкрементами соседних циклов. Например, данная стратегия разработки ПС и систем используется в компании Microsoft. Здесь на каждую версию программного средства разрабатывается около тысячи инкрементов. Период разработки инкремента составляет одни сутки (например, днем инкре­мент разрабатывается, ночью тестируется) [17]. В ряде организаций использу­ется недельный период разработки инкремента (чаще всего пять дней - разра­ботка, два дня - тестирование).

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

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

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

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

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

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

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

4)    снижение рисков по сравнению с каскадной стратегией;

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

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

1)      необходимость полного функционального определения системы или программного средства в начале ЖЦ для обеспечения планирования инкремен­тов и управления проектом;

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

3)      сложность планирования и распределения работ;

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

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

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

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

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

4)     при разработке проектов с низкой или средней степенью рисков;

5)    при выполнении проекта с применением новых технологий.

Резюме

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

 

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

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

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

Как и при инкрементной стратегии, при реализации эволюционной стра­тегии зачастую используется прототипирование.

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

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

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

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

1)    возможность уточнения и внесения новых требований в процессе раз­работки;

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

3)    возможность управления рисками;

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

5)    реализация преимуществ каскадной и инкрементной стратегий.

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

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

2)    сложность планирования и управления проектом;

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

4)    необходимость в мощных инструментальных средствах и методах прототипирования;

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

Очевидно, что ряд недостатков эволюционной стратегии (см. недостатки 3 - 5) характерны и для инкрементной стратегии.

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

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

2)    при разработке сложных проектов, в том числе:

•  больших долгосрочных проектов;

•  проектов по созданию новых, не имеющих аналогов ПС или систем;

•  проектов со средней и высокой степенью рисков;

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

3)    при разработке проектов, использующих новые технологии.

Резюме

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

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