Достоинства эволюционной модели

Рис.2.1. Этапы жизненного цикла

2. Модели жизненного цикла ПО

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

· Каскадная (водопадная).

· Спиральная.

· Инкрементная.

· Эволюционная.

Каскадная модель – первая модель пришедшая на смену бессистемного метода – «нашел ошибку – исправил». Было это в 1970 г. Классический пример каскадной модели – рис.2.1. Начальный этап выполнения каскадной модели показан в левой верхней части рис.2.1. Продолжение процесса выполнения реализуется с помощью упорядоченной последовательности шагов. Каждая последующая фаза начинается только после завершения предыдущей фазы. Подробная схема на рис.2.2.

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

Достоинства каскадной модели:

· Логичность и простота.

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

· Удобство перехода от старой системы к новой.

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

· Необходима высокая точность определения исходных требований к системе.

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

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

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

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

Там же перечислены основные достоинства и недостатки модели по мнению специалистов.

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

Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные.

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

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

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

 

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

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

 Спиральная стратегия (автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

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

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

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

Схематическое изображение модели приведено на рис.2.3. Там же в сжатом виде сформулированы достоинства и недостатки.

Как видно из рис.2.3, развитие проекта может быть завершено не только после стадии внедрения, но и после стадии анализа риска.

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

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

 

 

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

 

Достоинства модели:

· Позволяет поэтапно показать заказчику работоспособный продукт,   

· Допускает изменение требований при разработке.

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

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

· Появляется возможность с минимальными финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

· Увеличивается неопределенность у разработчика в перспективах развития проекта.

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

 

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

Рассмотрим преимущества итерационного подхода более подробно.

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

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

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

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

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

 

 

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

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

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

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

С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.

 

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

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

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

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

Схема представлена на рис.2..4, там же достоинства и недостатки.

 

Ввод в действие и  обеспечение  приемки

                                                               Пунктиры – возможные информационные потоки

        Рис.2.4. Инкрементная модель.

   Достоинства инкрементной модели:

· Естественное разделение системы на наращиваемые компоненты (инкременты).

· Для начала работ достаточно небольших по объему исходных данных.

· Поэтапное наращивание привлекаемого персонала и средств.

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

· Оправдана для систем, требования к которым ясны изначально.

· Изменение ранее обработанных требований к системе может отменить  все последующие результаты.

· Сложности с привлечением средств и персонала на длительный срок.

 

 

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

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

 

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

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

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

 

Схема приведена на рис.2.5, там же основные достоинства и недостатки.

 

                                                            Пунктиры – уточненные информационные потоки

   Рис.2.5. Эволюционная модель

 

Применение моделей

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

 

Основные факторы влияющие на выбор модели:

· Четкость определения требований.

 

· Возможность изменений требований по ходу выполнения проекта.

 

· Возможность разбиения системы на независимые инкременты.

 

· Наличие прототипов.

 

· Финансовые и организационные ресурсы.

 

· Наличие квалифицированных кадров.

 

· Возможность ситуации прекращения проекта, если в ходе выполнения выясняется его неэффективность.

 

Перейдем к теме «Проектирование программного обеспечения».

Ранее, в Лекции 1 были рассмотрены вопросы, связанные с требованиями к программным системам.

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

    Классический пример - неудачные стандарты и технологии разработки операционной системы ОС ЕС ЭВМ, приведшие к полной утрате отечественной вычислительной техники.

Яркий пример – безобразная работа "Почты России". После «компьютеризации» и установки АСУ, необученные сотрудники (печатают двумя пальцами, причем это более продвинутые, остальные - одним). Постоянно слышны крики вроде "компьютер завис, программа выпала...".

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

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

Те же проблемы и в налоговой инспекции и в сбербанке.

Другой пример, компания «Ультра Стар» (системы безопасности, мобильные средства спецсвязи) в 2005 году сменила софт и на весь квартал, пока его настраивала, вынуждена была закрыть представительство в Москве, потому что клиентуру растеряла полностью.

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

«Уже 10 лет ведется разработка Единой системы управления тактического звена, начатая по распоряжению В.В. Путина в 2000 году.

Известна разработка АСУ воздушно-десантной дивизии (ОКР «Полет-К»), начатая еще в начале 90-х. Прошло 20 лет, а спросить не с кого. Ни в чеченских компаниях, ни в грузино-российском конфликте АСУВ даже не пахло, и на учениях 2009 года («Осень-2009», «Запад-2009» и другие) они не получили удовлетворительной оценки.

Это результат десятилетних ОКР с постоянным ростом объемов финансирования и продлением сроков.

Последние 20 лет эти и другие АСУВ жили «своей жизнью», и то, что сегодня что-то изменилось – иллюзия (2010 г.).

Справедливости ради, следует отметить, в настоящее время ситуация меняется в лучшую сторону. Это началось после радикальной смены руководства МО РФ.

В качестве положительного примера применения современных подходов к проектированию сложных программных систем приведем успешное внедрение и использование инструментов IBM Rational в системном инжиниринге на фирме «Ульяновское конструкторское бюро приборостроения».

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

«Ульяновское конструкторское бюро приборостроения» (УКБП) - одно из ведущих предприятий авиаприборостроения РФ, основная деятельность которого сосредоточена в области разработки, изготовления и внедрения:

· авиационных систем электронной индикации и сигнализации самолетов и вертолетов;

· систем управления самолетным оборудованием;

· интегрированных систем измерения и вычисления воздушных параметров и лётных ограничений;

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

Оборудование УКБП установлено на самолётах и вертолётах Президента и Правительства РФ, а также на бортах авиакомпаний Российской Федерации и зарубежных стран.

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

Рис.2.6. Месторасположение приборов, названия авиакомпаний и городов, где производится установка.

Проект стартовал в 2007 году. Тогда компания закупила 10 лицензий Rational DOORS для управления требованиями, 6 лицензий Rational Change для управления изменениями данных жизненного цикла и 10 лицензий Rational Synergy для управления версиями исходного и исполняемого кодов программного обеспечения разрабатываемых систем и приборов.

По мере необходимости приобретались дополнительные лицензии. Например, инструменты Rational DOORS, Change и Synergy применялись Ульяновским конструкторским бюро приборостроения при разработке блока-концентратора данных для нового пассажирского самолета Сухой Superjet 100.

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

 

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

DOORS и Synergy, обеспечивались с помощью Change.

Инструменты Rational позволили обеспечить конфигурационное управление данных жизненного цикла системных процессов и процессов разработки программного обеспечения в соответствии с требованиями международных стандартов. В настоящее время DOORS, Change и Synergy широко применяются для разработки требований и управления данными жизненного цикла в проектных работах по созданию авиационных систем новых самолетов ТУ-204СМ, МС-21.

 Эти продукты применяются также для разработки систем и оборудования перспективных вертолетов, разрабатываемых компаниями ОАО «МВЗ им. М.Л. Миля», ОАО «Камов» и ОАО «Казанский вертолетный завод».

Вернемся к инженерии.

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

Данная лекция посвящена этому этапу.

Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения, поэтому созданы соответствующие стандарты IEEE и ISO/ IEC, ГОСТ Р ИСО.МЭК и др. По мере необходимости будем ссылаться на них.   

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

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

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

Результат проектирования программных систем состоит из двух частей:

· Высокоуровневый дизайн (или архитектура) – описание высокоуровневой структуры и организации компонентов системы.

· Детализированная архитектура – описывает каждый компонент в объеме необходимом для конструирования.

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

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

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

В 1999 году Де Марко предложил терминологическое разделение различных видов дизайна:

 D-дизайн (D-design, decomposition design) – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонентов.

 FP-дизайн (FP-design, family pattern design) – семейство архитектурных представлений, базирующихся на шаблонах.

 I-дизайн (I-design, invention) – создание                    высокоуровневой концепции, видения того, что из себя будет представлять программная система.

Эти термины используются до сих пор.

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

Далее будем обсуждать каждый блок в соответствии с рис.2.7.

 

 

 

Рис. 2.7. Область знаний «Проектирование ПО»

 

Абстракция

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

  При этом, абстракция через специфицирование бывает трех видов:

- процедурная абстракция (динамическая, то есть в отношении поведения);

- абстракция данных (статическая, то есть в отношении информации);

- абстракция контроля (то есть управления системой и обрабатываемой ею информацией).

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

 

 

Связанность и соединение

    Связанность – определяет степень взаимного влияния между модулями. Соединение – обусловливает связь элементов  внутри модуля, внутреннюю связь.

    В зависимости от контекста, «связанность» и «соединение» могут рассматриваться как степень самодостаточности или функциональная зависимость, соответственно.

   Эти понятия важны, так как с развитием сервисно - ориентированной архитектуры (Service - Oriented Architecture, SOA), слабосвязанной по своей природе, все чаще приходится сравнивать различные подходы и решения. Которые, в свою очередь, определятся способом и степенью связанности различных модулей, компонентов и самих программных систем.

  Напомним, что Сервис – ориентированная архитектура (SOA, англ. service - oriented architecture) – это модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

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

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

 Этим обеспечивается комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов.

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

 

 

 

 

 

Инкапсуляция

  Данная концепция предполагает группирование и упаковку (для подготовки к развертыванию и эксплуатации) элементов и внутренних деталей моделей.

  Цель - сделать недоступными эти детали (как малозначимые или по другим причинам) пользователям отдельных компонентов.

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

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

 

Параллелизм (Concurrency)

 Эта тема охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, синхронизации и распределения (во времени) обработки информации.

 

Измерения (Measures)

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

Чаще всего, все метрики разделяют по двум категориям:

- Функционально-ориентированные.

- Объектно-ориентированные.

Другие методы

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

Рис.2.1. Этапы жизненного цикла

2. Модели жизненного цикла ПО

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

· Каскадная (водопадная).

· Спиральная.

· Инкрементная.

· Эволюционная.

Каскадная модель – первая модель пришедшая на смену бессистемного метода – «нашел ошибку – исправил». Было это в 1970 г. Классический пример каскадной модели – рис.2.1. Начальный этап выполнения каскадной модели показан в левой верхней части рис.2.1. Продолжение процесса выполнения реализуется с помощью упорядоченной последовательности шагов. Каждая последующая фаза начинается только после завершения предыдущей фазы. Подробная схема на рис.2.2.

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

Достоинства каскадной модели:

· Логичность и простота.

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

· Удобство перехода от старой системы к новой.

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

· Необходима высокая точность определения исходных требований к системе.

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

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

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

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

Там же перечислены основные достоинства и недостатки модели по мнению специалистов.

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

Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные.

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

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

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

 

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

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

 Спиральная стратегия (автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

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

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

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

Схематическое изображение модели приведено на рис.2.3. Там же в сжатом виде сформулированы достоинства и недостатки.

Как видно из рис.2.3, развитие проекта может быть завершено не только после стадии внедрения, но и после стадии анализа риска.

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

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

 

 

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

 

Достоинства модели:

· Позволяет поэтапно показать заказчику работоспособный продукт,   

· Допускает изменение требований при разработке.

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

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

· Появляется возможность с минимальными финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

· Увеличивается неопределенность у разработчика в перспективах развития проекта.

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

 

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

Рассмотрим преимущества итерационного подхода более подробно.

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

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

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

Данное утверждение справедливо при любой модел