Модели жизненного цикла программного продукта

За десятилетия опыта построения программных систем был наработан ряд типичных схем выполнения работ при их проектировании и разработке. Такие схемы получили название моделей ЖЦ.

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

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

- разработку системы или технического проекта;

- программирование или рабочее проектирование;

- пробную эксплуатацию;

- сопровождение и улучшение;

- снятие с эксплуатации.

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

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

При выборе общей схемы модели ЖЦ для конкретной предметнойобласти решаются вопросы включения или не включения отдельныхработ, очень важных для создаваемого вида продукта. В настоящеевремя основой формирования новой модели ЖЦ для конкретнойприкладной системы является стандарт ISO/IEC 12207, которыйописывает полный набор процессов (более 40), охватывающий всевозможные виды работ и задач, связанных с построением ПС.

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

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

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

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

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

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

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

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

Каскадная модель. Каскадная (водопадная – waterfall) модельвключает в себя выполнение следующих фаз (рисунок 2.2):

 

Рисунок 2.2. Каскадная модель ЖЦ ПП.

 

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

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

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

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

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

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

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

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

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

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

При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее недостатки:

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

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

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

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

Каскадная модель была впервые четко сформулирована в 1970 г. У. Ройсом. На начальном периоде она сыграла ведущую роль какметод регулярной разработки сложного ПО. В 70 – 80-х годов XX в. модель была принята как стандарт министерства обороны США.

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

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

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

Рисунок 2.3. Спиральная модель ЖЦ ПП:

АР – анализ рисков; П– прототип.

 

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

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

2. Создание прототипов ПО как средства общения с заказчикомдля уточнения и выявления требований.

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

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

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

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

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

1) определение целей, альтернативных вариантов и ограничений;

2) оценка альтернативных подходов, идентификация и разрешениерисков;

3) разработка продукта следующего уровня;

4) планирование следующей фазы.

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

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

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

На фазе разработки выполняется проектирование и создается демо-версия, отражающая основные проектные решения.

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

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

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

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

- сложность анализа и оценки рисков при выборе вариантов;

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

- сложность оценки точки перехода на следующий цикл;

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

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

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

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

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

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

Итерационная модель. Эта модель жизненного цикла являетсяразвитием классической каскадной модели, но предполагает возможность возвратов на ранее выполненные этапы (рисунок 2.4).

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

Рисунок 2.4. Итерационная модель ЖЦ ПП.

 

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

V-образная модель. Данная модель также была предложена какитерационная разновидность каскадной модели (рисунок 2.5).

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

 

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

 

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

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

Рисунок 2.6. Инкрементная модель ЖЦ ПП.

 

На первом шаге (инкремент 1) необходим полный, заранее сформулированный набор требований, которые разделяются по некоторому признаку на группы. Далее выбирается перваягруппа требований и выполняется полный «проход» по каскадноймодели. После того как первый вариант системы, выполняющийпервую группу требований, сдан заказчику, разработчики переходятк следующему шагу (инкременту 2) по разработке варианта, выполняющего вторую группу требований, и т. д.

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

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