Эволюционно-инкрементная организация жизненного цикла разработки

 

Рассматриваемый подход является развитием спиральной модели Боэма [8], [40], [44], [57]. В этом случае процесс разработки программной системы организуется в виде эволюционно-инкрементного жизненного цикла. Эволюционная составляющая цикла основывается на доопределении требований в ходе работы, инкрементная составляющая — на планомерном приращении реализации требований.

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

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

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

Рис. 15.1. Типовая итерация эволюционно-инкрементного жизненного цикла

 

Рис. 15.2. Два измерения унифицированного процесса разработки

 

Как показано на рис. 15.2, в структуре унифицированного процесса разработки выделяют два измерения:

q горизонтальная ось представляет время и демонстрирует характеристики жизненного цикла процесса;

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

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

Этапы и итерации

 

По времени в жизненном цикле процесса выделяют четыре этапа:

q начало (Inception) — спецификация представления продукта;

q развитие (Elaboration) — планирование необходимых действий и требуемых ресурсов;

q конструирование (Construction) — построение программного продукта в виде серии инкрементных итераций;

q переход (Transition) — внедрение программного продукта в среду пользователя (промышленное производство, доставка и применение).

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

Рабочие потоки процесса

 

Рабочие потоки процесса имеют следующее содержание:

q Сбор требований — описание того, что система должна делать;

q Анализ — преобразование требований к системе в классы и объекты, выявляемые в предметной области;

q Проектирование — создание статического и динамического представления системы, выполняющего выявленные требования и являющегося эскизом реализации;

q Реализация — производство программного кода, который превращается в исполняемую систему;

q Тестирование — проверка всей системы в целом.

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

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

Модели

 

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

q бизнес-модель. Определяет абстракцию организации, для которой создается система;

q модель области определения. Фиксирует контекстное окружение системы;

q модель Use Case. Определяет функциональные требования к системе;

q модель анализа. Интерпретирует требования к системе в терминах проектной модели;

q проектная модель. Определяет словарь проблемы и ее решение;

q модель размещения. Определяет аппаратную топологию, в которой исполняется система;

q модель реализации. Определяет части, которые используются для сборки и реализации физической системы;

q тестовая модель. Определяет тестовые варианты для проверки системы;

q модель процессов. Определяет параллелизм в системе и механизмы синхронизации.

Технические артефакты

 

Технические артефакты подразделяются на четыре основных набора:

q набор требований. Описывает, что должна делать система;

q набор проектирования. Описывает, как должна быть сконструирована система;

q набор реализации. Описывает сборку разработанных программных компонентов;

q набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.

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

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

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

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

Набор размещения группирует всю информацию об упаковке, отправке, установке и запуске системы.

Управление риском

 

Словарь русского языка С. И. Ожегова и Н. Ю. Шведовой определяет риск как «возможность опасности, неудачи». Влияние риска вычисляют по выражению

RE = P (UO) x L (UO),

где:

q RE — показатель риска (Risk Exposure — подверженность риску);

q P (UO) — вероятность неудовлетворительного результата (Unsatisfactory Outcome);

q L (UO) — потеря при неудовлетворительном результате.

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

1. Идентификация риска — выявление элементов риска в проекте.

2. Анализ риска — оценка вероятности и величины потери по каждому элементу риска.

3. Ранжирование риска — упорядочение элементов риска по степени их влияния.

4. Планирование управления риском — подготовка к работе с каждым элементом риска.

5. Разрешение риска — устранение или разрешение элементов риска.

6. Наблюдение риска — отслеживание динамики элементов риска, выполнениекорректирующих действий.

Первые три действия относят к этапу оценивания риска, последние три действия — к этапу контроля риска [20].

 

Идентификация риска

 

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

Выделяют три категории источников риска: проектный риск, технический риск, коммерческий риск.

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

q выбор бюджета, плана, человеческих ресурсов программного проекта;

q формирование требований к программному продукту;

q сложность, размер и структура программного проекта;

q методика взаимодействия с заказчиком.

К источникам технического риска относят:

q трудности проектирования, реализации, формирования интерфейса, тестирования и сопровождения;

q неточность спецификаций;

q техническая неопределенность или отсталость принятого решения.

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

Источники коммерческого риска включают:

q создание продукта, не требующегося на рынке;

q создание продукта, опережающего требования рынка (отстающего от них);

q потерю финансирования.

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

1. Дефицит персонала.

2. Нереальные расписание и бюджет.

3. Разработка неправильных функций и характеристик.

4. Разработка неправильного пользовательского интерфейса.

5. Слишком дорогое обрамление.

6. Интенсивный поток изменения требований.

7. Дефицит поставляемых компонентов.

8. Недостатки в задачах, разрабатываемых смежниками.

9. Дефицит производительности при работе в реальном времени.

10. Деформирование научных возможностей.

На практике каждый элемент списка снабжается комментарием — набором методик для предотвращения источника риска.

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

Анализ риска

 

В ходе анализа оценивается вероятность возникновения Р _i и величина потери L_i для каждого выявленного i -го элемента риска. В результате вычисляется влияние RE_i i -го элемента риска на проект.

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

Таблица 15.1. Оценка влияния элементов риска

Элемент риска	Вероятность, %	Потери	Влияние риска
1. Критическая программная ошибка	3-5	10	30-50
2. Ошибка потери ключевых данных	3-5	8	24-40
3. Отказоустойчивость недопустимо снижает производительность	4-8	7	28-56
4. Отслеживание опасного условия как безопасного	5	9	45
5. Отслеживание безопасного условия как опасного	5	3	15
6. Аппаратные задержки срывают планирование	6	4	24
7. Ошибки преобразования данных приводят к избыточным вычислениям	8	1	8
8. Слабый интерфейс пользователя снижает эффективность работы	6	5	30
9. Дефицит процессорной памяти	1	7	7
10. СУБД теряет данные	2	2	4

Ранжирование риска

 

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

Для больших проектов количество элементов риска может быть очень велико (30-40 элементов). В этом случае управление риском затруднено. Поэтому к элементам риска применяют принцип Парето 80/20. Опыт показывает, что 80% всего проектного риска приходятся на долю 20% от общего количества элементов риска. В ходе ранжирования определяют эти 20% элементов риска (их называют существенными элементами). В дальнейшем учитывается влияние только существенных элементов риска.

Планирование управления риском

 

Цель планирования — сформировать набор функций управления каждым элементом риска. Введем необходимые определения.

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

Рис. 15.3. Кривая останова проекта

 

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

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

Теперь рассмотрим последовательность шагов планирования.

1. Исходными данными для планирования является набор четверок [ R_i P_i, L_i, RE_i ], где R_i — 2-й элемент риска, P_i — вероятность i -го элемента риска, L_i — потеря по i -му элементу риска, RE_i — влияние i -го элемента риска.

2. Определяются эталонные уровни риска в проекте.

3. Разрабатываются зависимости между каждой четверкой [ R_i P_i, L_i, RE_i ] и каждым эталонным уровнем.

4. Формируется набор эталонных точек, образующих сферу останова. В сфере останова предсказываются области неопределенности.

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

6. План управления каждым элементом риска интегрируется в общий план программного проекта.