 |
Эволюционно-инкрементная организация жизненного цикла разработки
|
|
|
|
Рассматриваемый подход является развитием спиральной модели Боэма [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 и величина потери Li для каждого выявленного i -го элемента риска. В результате вычисляется влияние REi i -го элемента риска на проект.
|
|
|
Вероятности определяются с помощью экспертных оценок или на основе статистики, накопленной за предыдущие разработки. Итоги анализа, как показано в табл. 15.1, сводятся в таблицу.
Таблица 15.1. Оценка влияния элементов риска
| Элемент риска | Вероятность, % | Потери | Влияние риска |
| 1. Критическая программная ошибка | 3-5 | 30-50 | |
| 2. Ошибка потери ключевых данных | 3-5 | 24-40 | |
| 3. Отказоустойчивость недопустимо снижает производительность | 4-8 | 28-56 | |
| 4. Отслеживание опасного условия как безопасного | |||
| 5. Отслеживание безопасного условия как опасного | |||
| 6. Аппаратные задержки срывают планирование | |||
| 7. Ошибки преобразования данных приводят к избыточным вычислениям | |||
| 8. Слабый интерфейс пользователя снижает эффективность работы | |||
| 9. Дефицит процессорной памяти | |||
| 10. СУБД теряет данные |
Ранжирование риска
Ранжирование заключается в назначении каждому элементу риска приоритета, который пропорционален влиянию элемента на проект. Это позволяет выделить категории элементов риска и определить наиболее важные из них. Например, представленные в табл. 15.1 элементы риска упорядочены по их приоритету.
Для больших проектов количество элементов риска может быть очень велико (30-40 элементов). В этом случае управление риском затруднено. Поэтому к элементам риска применяют принцип Парето 80/20. Опыт показывает, что 80% всего проектного риска приходятся на долю 20% от общего количества элементов риска. В ходе ранжирования определяют эти 20% элементов риска (их называют существенными элементами). В дальнейшем учитывается влияние только существенных элементов риска.
Планирование управления риском
Цель планирования — сформировать набор функций управления каждым элементом риска. Введем необходимые определения.
В планировании используют понятие эталонного уровня риска. Обычно выбирают три эталонных уровня риска: превышение стоимости, срыв планирования, упадок производительности. Они могут быть причиной прекращения проекта. Если комбинация проблем, создающих риск, станет причиной превышения любого из этих уровней, работа будет остановлена. В фазовом пространстве риска эталонному уровню риска соответствует эталонная точка. В эталонной точке решения «продолжать проект» и «прекратить проект» имеют одинаковую силу. На рис. 15.3 показана кривая останова, составленная из эталонных точек.
Рис. 15.3. Кривая останова проекта
Ниже кривой располагается рабочая область проекта, выше кривой — запретная область (при попадании в эту область проект должен быть прекращен).
Реально эталонный уровень редко представляется как кривая, чаще это сфера, в которой есть области неопределенности (в них принять решение невозможно).
Теперь рассмотрим последовательность шагов планирования.
1. Исходными данными для планирования является набор четверок [Ri Pi, Li, REi], где Ri — 2-й элемент риска, Pi — вероятность i -го элемента риска, Li — потеря по i -му элементу риска, REi — влияние i -го элемента риска.
2. Определяются эталонные уровни риска в проекте.
3. Разрабатываются зависимости между каждой четверкой [Ri Pi, Li, REi] и каждым эталонным уровнем.
4. Формируется набор эталонных точек, образующих сферу останова. В сфере останова предсказываются области неопределенности.
5. Для каждого элемента риска разрабатывается план управления. Предложения плана составляются в виде ответов на вопросы «зачем, что, когда, кто, где, как и сколько».
6. План управления каждым элементом риска интегрируется в общий план программного проекта.
|
|
|
