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

Рис. 3

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

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

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

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

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

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

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

Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Преимущества Spiral СДЛК модели являются -

· · Изменение требований могут быть размещены.

· · Позволяет широкое использование прототипов.

· · Требования могут быть захвачены более точно.

· · Пользователи видят систему рано.

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

К недостаткам Спираль СДЛК модели являются -

· · Управление является более сложным.

· · Конец проекта не может быть известен заранее.

· · Не подходит для проектов небольшой или с низким риском и может быть дорогостоящим для небольших проектов.

· · Процесс является сложным

· · Спираль может продолжаться до бесконечности.

· · Большое количество промежуточных этапов требует дополнительной документации.

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

РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ

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

На техническое задание существует стандарт (ГОСТ 19.201–78). В соответствие с этим стандартом техническое задание должно содержать следующие разделы:

* введение;

* основания для разработки;

* назначение разработки;

* требования к программе или программному изделию;

* требования к программной документации;

* технико-экономические показатели;

* стадии и этапы разработки;

* порядок контроля и приемки.

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

Рассмотрим более подробно содержание каждого раздела.

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

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

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

Раздел Требования к программе или программному изделию должен включать следующие подразделы:

* требования к функциональным характеристикам;

* требования к надежности;

* условия эксплуатации;

* требования к составу и параметрам технических средств;

* требования к информационной и программной совместимости;

* требования к маркировке и упаковке;

* требования к транспортированию и хранению;

* специальные требования.

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

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

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

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

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

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

В разделе Технико-экономические показатели рекомендуется указывать ориентировочную экономическую эффективность и экономические преимущества по сравнению с существующими аналогами.

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

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

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

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