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

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

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

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

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

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

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

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

 

Содержание

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

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

 

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

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

    

      
 

      

      
 
 

      

      
 
 

      

      
 
 
 
 
 
 
 
 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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