4)при разработке систем с равномерным распределением важности функциональных свойств;

5)при разработке проектов с низкой или средней степенью риска;

6)при выполнении проекта с применением новой технологии;

7)при разработке проектов, для которых разработка системы за один цикл связана с большой степенью риска;

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

2.1.4.Эволюционная стратегия разработки программных средств и систем

Эволюционная стратегия представляет собой многократный проход

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

требований к разрабатываемому ПС в начале процесса разработки. Требования

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

Результат

каждого

цикла

разработки

обычно

представляет

собо

очередную поставляемую версию ПС.

Следует отметить, что в общем случае для эволюционной стратегии

характерно существенно меньшее количество циклов разработки при большей

продолжительности цикла по сравнению с инкрементной стратегией. При этом

результат каждого цикла разработки(очередная

версия ПС или системы)

гораздо сильнее отличается от результата предыдущего цикла.

Зачастую

при

реализации

эволюционной

стратегии

используетс

прототипирование.

В

данном

случае

основной

целью

прототипирования

явля

обеспечение полного понимания требований. Прототипирование наиболее

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

концепция или новая технология, так как в этих случаях достаточно сложно

полностью и корректно разработать детальные технические

требования

к

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

Прототипирование позволяет итеративно уточнять требования к продукту

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

При использовании эволюционного прототипирования снижаются затраты и

оптимизируется соблюдение графиков.

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

должен принимать заказчик.

Представителями

моделей,

реализующих

эволюционную

стратегию,

являются, например, эволюционная модель быстрого прототипирования, RAD-

модель, спиральная модель (см. п. ).

Основными

достоинствами

эволюционной

стратегии, проявляемыми

при разработке соответствующего ей проекта, являются:

15

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

2)пригодность для использования промежуточного продукта;

3)возможность обеспечения управления рисками;

4)возможность гибкой разработки, основанная на преимуществах каскадной стратегии при одновременном разрешении итераций;

5)реализация преимуществ инкрементной стратегии(выпуск версий, повторное использование результатов, сокращение графика работ);

6)обеспечение разбиения большого потенциального объема работ по выполнению проекта на небольшие части; первоочередность реализации

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

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

общих затрат на разработку за счет раннего решения проблем и меньшего объема доработок;

9)	отсутствие необходимости в предварительном распределении всех
нужных для выполнения проекта финансовых ресурсов.
К недостаткам эволюционной стратегии, проявляемым при ее выборе к
несоответствующему проекту, следует отнести:
1)	сложность	определения	критериев	для	продолжения	процесс

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

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

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

4)необходимость мощных инструментальных средств и методов прототипирования;

5)необходимость в обработке дополнительной документации за счет большого количества промежуточных циклов;

6)возможность отодвигания решения трудных проблем на последующие

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

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

16

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

2)при разработке проектов, для которых нужна проверка концепции, демонстрация технической осуществимости или промежуточных продуктов;

3)при разработке больших долгосрочных проектов;

4)при разработке проектов по созданию новых, не имеющих аналогов продуктов или систем;

5)при отсутствии у разработчиков уверенности в выборе оптимальной архитектуры или применяемых алгоритмов;

6)при разработке проектов со средней и высокой степенью риска;

7)при разработке проектов, использующих новые технологии;

8)при разработке интенсивно используемых систем пользовательского интерфейса, интерактивных систем, систем обеспечения принятия решений,

бизнес-проектов, проектов в области аэрокосмической промышленности, обороны и инжиниринга.

Ниже рассмотрены модели жизненного цикла, реализующие каскадную, инкрементную или эволюционную стратегии разработки или их комбинации. Большинство из данных моделей базируется на моделях, рекомендованных к использованию Институтом качества программного обеспеченияSQI (Software Quality Institute) [20] или стандартом ГОСТ Р ИСО/МЭК15271-2002 [6].

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

СТБ ИСО/МЭК 12207-2003 [8].

2.2.Модели жизненного цикла,

реализующие каскадную стратегию разработки программных средств и систем

2.2.1.Общие сведения о каскадных моделях

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

Данная модель впервые формализовала структуру этапов разработки ПО.

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

17

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

Существуют различные варианты каскадной модели жизненного цикла.

2.2.2. Классическая каскадная модель

Рисунок 2.2 представляет вариант классической каскадной модели, ориентированный на работы процесса разработки, определенного в СТБ ИСО/МЭК 12207-2003 [8] (см. подразд. 1.2 учебного пособия). Для данного варианта модели понятие шага разработки ПС совпадает с понятием работы вышеназванного стандарта.

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

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

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

2.2.3. Каскадная модель с обратными связями

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

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

Возможны различные варианты обратных связей между любыми шагами

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

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

18

Анализ требований к системе

Проектирование системной архитектуры

Анализ требований к ПС

Проектирование программной архитектуры

Техническое проектирование ПС

Программирование и тестирование ПС

Сборка и квалификационные испытания ПС

Сборка и квалификационные испытания системы

Ввод в действие ПС

	ПС – программные средства	Обеспечение
		приемки ПС

Рисунок 2.2 – Классическая каскадная модель, ориентированная на работы процесса разработки СТБ ИСО/МЭК 12207-2003

19

Анализ требований к системе

Проектирование системной архитектуры

Анализ требований к ПС

Проектирование программной архитектуры

Техническое проектирование ПС

Программирование и тестирование ПС

Сборка и квалификационные испытания ПС

Сборка и квалификационные испытания системы

Ввод в действие ПС

		Обеспечение
ПС – программные средства		приемки ПС

Рисунок 2.3 –Каскадная модель с обратными связями

20

Рисунок 2.4 – Структура фрагмента каскадной модели

свозможностью возврата к любому шагу

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

2.2.4.Вариант каскадной модели по ГОСТ Р ИСО/МЭК ТО 15271-2002

В ГОСТ Р ИСО/МЭК ТО15271-2002 [6] приводится вариант каскадной модели, ориентированный на разработку систем(рисунок 2.5). В данном варианте модели, как и в предыдущих вариантах, понятие шага разработки совпадает с понятием работы процесса разработки, определенного в стандарте

СТБ ИСО/МЭК 12207-2003 [8].

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

21

Анализ			Анализ
требований			требований к ПС
к системе
			Проектирование
Проектиро-			программной
			архитектуры
вание сис-
темной ар-
хитектуры			Техническое
			проектирование
			ПС
			Программиро-
			вание и
			тестирование ПС

Сборка и квалификационные испытания ПС

ПО1	Сборка
	системы

ПО N
Программ-	Квалифика-
ный	ционные
объект N	испытания
	системы

Технические объекты

ПО - программный объект ПС – программное средство

Рисунок 2.5 – Вариант каскадной модели по ГОСТ Р ИСО/МЭК ТО 15271-2002

Ввод системы

в

действие

Обеспечение приемки ПС

22