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

• 1) разработку требований или технического задания;
• 2) разработку системы или технического проекта;
• 3) программирование или рабочее проектирование;
• 4) пробную эксплуатацию;
• 5) сопровождение и улучшение;
• 6) снятие с эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

• 1) исследование концепции: происходит исследование требований, разрабатывается видение продукта и оценивается возможность его реализации;
• 2) выработка требований: определяются программные требования для информационной предметной области системы, а также предназначение, линия поведения, производительность и интерфейсы;
• 3) проектирование: разрабатывается и формулируется логически последовательная техническая характеристика программной системы, включая структуру данных, архитектуру ПО, интерфейсные представления и процессуальную (алгоритмическую) детализацию;
• 4) реализация: эскизное описание ПС превращается в полноценный программный продукт, результатом является исходный код, база данных и документация; в реализации обычно выделяют два этапа: реализацию компонентов ПО и интеграцию компонент в готовый продукт; на обоих этапах выполняется кодирование и тестирование, которые тоже иногда рассматривают как два подэтапа;
• 5) эксплуатация и поддержка: подразумевает запуск и текущее обеспечение, включая предоставление технической помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов пользователя на модернизацию и внесение изменений, а также корректирование и/или устранение ошибок;
• 6) сопровождение: устранение программных ошибок, неисправностей, сбоев, модернизация и внесение изменений, что обычно приводит к повторению или итерации отдельных этапов разработки.

Исследование концепции

Выработка требований

Проектирование

Реализация компонент

Интеграция компонент

Эксплуатация

Сопровождение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение целей, альтернатив, ограничений

Суммарная

стоимость

Оценка альтернатив выявить и решить риски

разработки

Планирование следующих фаз

Разработка следующего уровня

Рис. 2.3. Спиральная модель ЖЦ ПП: АР - анализ рисков; П - прототип

• 3. Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту
• 4. Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта/ прототипа становится неоправданно высок.
• 5. Использование каскадной модели как схемы разработки очередного варианта продукта.
• 6. Активное привлечение заказчика к работе над проектом. Заказчик участвует в оценке очередного прототипа, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков.

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

• 1) определение целей, альтернативных вариантов и ограничений;
• 2) оценка альтернативных вариантов, идентификация и разрешение рисков;
• 3) разработка продукта следующего уровня;
• 4) планирование следующей фазы.

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.4.

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

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

Рис. 2.5.

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

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

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

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

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

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

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

В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ разделены на три группы (рис. 2.1).

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

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4.Тестирование.

5. Ввод в действие.

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

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

В настоящее время наибольшее распространение получили следующие основные модели ЖЦ ПО:

a) каскадная и

b) спиральная (эволюционная).

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

Преимущества применения каскадной модели заключаются в следующем:

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

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

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

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

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

Каскадную (эволюционную) модель можно представить в виде диаграммы, которая приведена на рисунке 2.5.

Одним из результатов применения спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений , или RAD (Rapid Application Development). Жизненный цикл ПО в соответствии с этим способом включает в себя четыре стадии:

1) анализ и планирование требований;

2) проектирование;

3) реализация;

4) внедрение.

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

1) Стратегия;

2) Анализ;

3) Проектирование;

4) Реализация;

5) Тестирование;

6) Внедрение;

7) Эксплуатация и техническая поддержка.

Стратегия

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

Итогом этапа определения стратегии становится документ, в котором четко сформулировано следующее:

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

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

Во сколько это ему обойдется (график финансирования этапов работ для крупных проектов).

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

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

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

a) функции - информация о событиях и процессах, которые происходят в бизнесе;

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

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

Проектирование

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

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

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

Задачами проектирования являются:

Рассмотрение результатов анализа и проверка их полноты;

Семинары с заказчиком;

Определение критических участков проекта и оценка его ограничений;

Определение архитектуры системы;

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

Проектирование хранилища данных: модель базы данных;

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

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

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

Реализация

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

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

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

Этап разработки сопряжен с этапом тестирования, и оба процесса идут параллельно. Синхронизирует действия тестеров и разработчиков система bug tracking.

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

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

Тестирование

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

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок - bug tracking, которая обеспечивает следующие функции:

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

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

Отчеты об актуальных ошибках по компонентам системы;

Информация об ошибке и ее история;

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

Интерфейс ограниченного доступа к системе bug tracking для конечного пользователя.

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

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

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

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

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

d) приемосдаточный тест ; основное его назначение - сдать систему заказчику;

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

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

Отдельного компонента информационной системы;

Группы компонентов системы;

Основных модулей системы;

Операционной системы;

Жесткий сбой (отказ питания, жестких дисков).

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

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

Внедрение

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

Ввод в эксплуатацию проходит как минимум три стадии:

2) накопление информации;

3) выход на проектную мощность (то есть собственно переход к этапу эксплуатации).

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

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

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

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

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

Процесс функционирования и сопровождения

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

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

● корректирующее (действия по обслуживанию) - выявление дефектов и ошибок, обнаруженных при работе;

● адаптивное - изменение ПО в ответ на изменения в вычислениях или в бизнес-среде;

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

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

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

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

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

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

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

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

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

● Внутренние деловые изменения (изменения в управлении, условиях работы, финансовое здоровье предприятия и т. д.).

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

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

● «водопад с обратной связью»;

● итеративный пошаговый.

1 Жизненный цикл «водопад с обратной связью»

Модель водопада - традиционный жизненный цикл, реализованный и популяризируемый в 1970-х годах. Об этой модели было сказано, что она успешно использовалась во многих больших проектах прошлого. Большинство этих проектов было связано с пакетными (то есть не диалоговыми) системами, реализованными на языке КОБОЛ. Сегодня жизненный цикл «водопад» используется менее часто.

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

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

Такой возврат может (хотя это бывает редко) продолжаться до начальной стадии - анализа требований.

Рисунок 1.3. Жизненный цикл «водопад с обратной связью»

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

Преимущества водопада с обратной связью:

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

2 Производит полную документацию для системы.

3 Требует завершения проектной документации перед переходом на следующие стадии.

4 Требует тщательного планирования проекта.

Недостатки водопада с обратной связью:

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

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

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

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

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

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

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

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

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

Этапы жизненного цикла ПО

Жизненный цикл программного обеспечения - период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: -1- возникновение и исследование идеи; -2- анализ требований и проектирование; -3- программирование; -4- тестирование и отладка; -5- ввод программы в действие; -6- эксплуатация и сопровождение; -7- завершение эксплуатации.

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

Примеры описания жизненного цикла

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

В отечественных нормативных документах (например, ГОСТ ЕСПД) принято следующее разграничение на этапы, которое приводится с указанием аналогий из списка, данного в начале раздела:

разработка технического задания (этапы 1 и 2);

технический проект (третий этап до 3.2.1 включительно);

рабочий проект (3.2.2, 4.2.1 и, частично, 4.2, 4.3);

экспериментальное внедрение (4.2 и 4.3);

сдача в промышленную эксплуатацию (этап 5);

промышленная эксплуатация (этап 6).

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

Рис. 1.1 Пример жизненного цикла программных систем

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

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

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

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

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

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

Кодирование и тестирование программного обеспечения (4.1.1 и 4.1.2). Создание, тестирование отдельных модулей, документирование и приемка программных компонентов, которые составляют программную систему.

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

Интеграция системы (4.3). Тестирование работоспособности и функциональной законченности частей общей системы в целом.

Приемка и поставка системы (5). Производится приемка системы заказчиком, и поставка ему системы.

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

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

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

этап планирования, который определяет и координирует действия по разработке программной системы (этап 1);

этап разработки, на котором создается программная система:

постановку задачи (этап 2),

проектирование (3),

кодирование (4.1.1),

получение исполняемого кода (4.1.1, 4.3);

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

Рис. 1.2 Вариант упрощенного жизненного цикла программной системы.

Отсутствие интегрированного этапа в обобщенном жизненном цикле не означает, что проверка производится только там, где это явно указано в названии этапа (например 4.2.1 и 4.2). Каждый этап может считаться завершенным только тогда, когда результаты, полученные на данном этапе, были признаны удовлетворительными, а для этого необходимо производить проверку результатов на каждом этапе. В обобщенном жизненном цикле некоторые проверки были вынесены отдельными пунктами для демонстрации повышенных объемов, сложности и важности этих проверок.

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

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

Рис. 1.3 Последовательность этапов разработки компонент программного обеспечения

Для компонента W из множества системных требований к единому продукту формируется подмножество требований, относящихся к данному компоненту, используются эти требования при формировании проекта программного компонента, реализовывают этот проект в исходном коде и тогда интегрирует компонент с аппаратурой. Компонент X показывает использование ранее разработанного программного обеспечения. Компонент Y показывает использование простой отдельной функции, которая может быть закодирована прямо на основе требований к программному обеспечению. Компонент Z показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к программному обеспечению и уменьшение технических рисков и рисков разработки при создании конечного продукта. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в окружение, типичное для конкретного использования системы при разработке. Результатом преобразований является уточненные данные, которые используются для создания конечного программного продукта.

Практически все этапы жизненного цикла объединяются с верификацией.

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

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

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

Модель ЖЦ любого конкретного ПО определяет характер процесса его создания.

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

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

В состав ЖЦ ПО обычно включаются следующие этапы:

1) формирование требований, предъявляемых к ПО;

2) проектирование структуры ПО;

3) реализация;

4) тестирование;

5) ввод в действие;

6) эксплуатация и сопровождение;

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

На каждом этапе могут выполняться несколько процессов, оп­ределенных в стандарте 1SO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных этапах.

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу.

К настоящему времени наибольшее распространение получили следующие три основные модели ЖЦ .

1) Каскадная модель (1970-1980 гг.) предполагает переход на следующий этап после полного завершения работ предыдущего этапа.

2) Поэтапная модель с промежуточным контролем (1980-1985 гг.) — итерационная модель разработки ПО с циклами обратной связи между этапами.

3) Спиральная модель (1986-1990 гг.) делает упор на начальные этапы ЖЦ (анализ требований, проектирование спецификаций, предварительное и детальное проектирование).

Основные характеристики каскадного способа :

Разбиение всей разработки на этапы;

Переход с одного этапа на следующий происходит только после полного завершения работы на текущем этапе (рис. 4.1);

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

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

Исходными для каждого этапа являются документы и решения, полученные на предыдущем этапе.

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

Рис. 4.1. Каскадная модель разработки программного обеспечения

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

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

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

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

Рис. 4.2. Модель с промежуточным контролем

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

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

Рис. 4.3. Спиральная модель жизненного цикла

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

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

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

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

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

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

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

Другими недостатками спиральной модели являются:

Трудоемкость внесения изменений;

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

Сложность переноса на другие платформы.

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

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