47593

Rational Unified Process

Книга

Информатика, кибернетика и программирование

Планирование итеративного проекта Технологические процессы 101 7 Технологический процесс управления проектом 103 Цель 103 Планирование итеративного проекта 104 Понятие риска 106 Понятие метрики 108 Что такое метрика 109 Исполнители и артефакты 110 Технологический процесс 111 Создание плана итерации 119 8 Технологический процесс моделирования производства 124 Цель 124 Зачем моделировать производство 124 Использование методов программотехники в процессе. Основные задачи книги Благодаря этой книге вы узнаете чем является Rtionl Unified...

Русский

2013-11-30

4.13 MB

63 чел.


Содержание

[0.1]
Содержание

[0.2] Введение

[0.3] Основные задачи книги

[0.4] Для кого предназначена эта книга

[0.5] Как использовать эту книгу

[0.6] Структура книги

[0.7] Дополнительная информация

[0.8] Отличия второго издания

[0.9] Благодарности

[0.10] Глава 1

[1]                  Советы по организации

[2]                     процесса разработки

[3]              программного обеспечения

[3.1] Значение программного обеспечения

[3.2] Проблемы в процессе разработки программного обеспечения

[3.3] Как лучше всего организовать процесс разработки

[3.4] Разрабатывайте итеративно

[3.5] Управляйте требованиями

[3.6] Пользуйтесь модульными архитектурами

[3.7] Используйте визуальное моделирование

[3.8] Не забывайте о проверке качества

[3.9] Следите за изменениями

[3.10] Резюме

[3.11] Глава 2

[3.12] Что такое Rational Unified Process

[3.13] Rational Unified Process как продукт

[3.14] Структура продукта процесса

[3.15] Кто использует Rational Unified Process

[3.16] Структура процесса: два измерения

[3.17] Лучшие советы по разработке в Rational Unified Process

[3.18] Итеративная разработка

[3.19] Управление требованиями

[3.20] Архитектура и использование компонентов

[4] 38 Часть I. Процесс

[4.1] Моделирование и язык UML

[4.2] Качество процесса и продукта

[4.3] Управление конфигурацией и изменениями

[4.4] Прочие ключевые свойства Rational Unified Process

[4.5] Разработка, управляемая прецедентами

[4.6] Моделирование и язык UML

[4.7] Качество процесса и продукта

[4.8] Управление конфигурацией и изменениями

[4.9] Прочие ключевые свойства Rational Unified Process

[4.10] Разработка, управляемая прецедентами

[4.11] Конфигурирование процесса

[4.12] Инструментальная поддержка

[4.13] Краткая история Rational Unified Process

[4.14] Резюме

[5] Глава 3. Статическая структура: описание процесса

[5.1] Модель Rational Unified Process

[5.2] Исполнители (в RUP 2001 — роли)

[5.3] Виды деятельности

[5.4] Этапы видов деятельности

[5.5] Артефакты

[5.6] Отчеты

[5.7] Множества артефактов

[5.8] Технологические процессы

[5.9] Основные технологические процессы

[5.10] Элементы технологических процессов

[5.11] Планы итераций

[5.12] Дополнительные элементы процесса

[5.13] Директивы

[5.14] Шаблоны

[5.15] Инструментальные наставники

[5.16] Основные понятия

[5.17] Контур процесса

[5.18] Резюме

[5.19] Глава 4

[6] Динамическая структура:                           итеративная разработка

[6.1] Последовательный процесс

[6.2] "Разумный" подход

[6.3] Риски

[6.4] Увеличение масштаба временной шкалы

[6.5] Помещение документации на полки

[6.6] Объемное планирование против временного

[6.7] Преодоление сложностей: итерируйте!

[6.8] Контроль: фазы и вехи

[6.9] Смещение акцентов в течение цикла

[6.10] Обзор фаз

[6.11] Особенности итеративного подхода

[6.12] Более высокое общее качество

[6.13] Резюме

[6.14] Глава 5

[7]         Процесс, основанный на

[8]      архитектуре

[8.1] Важность моделей

[8.2] Архитектура

[8.3] Важность архитектуры

[8.4] Определение архитектуры

[8.5] Представление архитектуры

[8.6] Процесс, основанный на архитектуре

[8.7] Цель архитектуры

[8.8] Модульная разработка

[8.9] Определение компонента

[8.10] Другие архитектурные концепции

[8.11] Резюме

[8.12] Глава 6

[9] Процесс, управляемый прецедентами

[9.1] Определения

[9.2] Сценарии

[9.3] Определение прецедентов

[9.4] Развитие прецедентов

[9.5] Организация прецедентов

[9.6] Прецеденты в процессе

[9.7] Резюме

[9.8] Глава 7

[10] Технологический процесс управления   проектом

[10.1] Цель

[10.2] Планирование итеративного проекта

[10.3] Понятие риска

[10.4] Понятие метрики

[10.5] Что такое метрика

[10.6] Исполнители и артефакты

[10.7] Технологический процесс

[10.8] Создание плана итерации

[10.9] Резюме

[10.10] Глава 8

[11] Технологический процесс моделирования производства

[11.1] Цель

[11.2] Зачем моделировать производство

[11.3] Сценарии моделирования производства

[11.4] Исполнители и артефакты

[11.5] Исполнители и артефакты

[11.6] Технологический процесс

[11.7] От моделей производства к моделям системы

[11.8] Другие источники требований к системам

[11.9] Моделирование производства программного обеспечения

[11.10] Инструментальная поддержка

[11.11] Резюме

[11.12] Глава 9

[12] Технологический процесс управления требованиями

[12.1] Цель

[12.2] Что такое "требование"

[12.3] Типы требований

[12.4] Сбор требований и управление ими

[12.5] Проектирование интерфейса, ориентированного на пользователя

[12.6] Технологический процесс управления    требованиями

[12.7] Исполнители

[12.8] Артефакты

[12.9] Инструментальная поддержка

[12.10] Резюме

[12.11] Глава 10

[13] Технологический процесс анализа и проектирования

[13.1] Цель

[13.2] Анализ против проектирования

[13.3] Модель проектирования

[13.4] Модель анализа

[13.5] Роль интерфейсов

[13.6] Артефакты систем реального времени

[13.7] Модульное проектирование

[13.8] Технологический процесс

[13.9] Инструментальная поддержка

[13.10] Резюме

[13.11] Глава 11

[14] Технологический процесс

[15] реализации

[15.1] Цель

[15.2] Конструкции

[15.3] Интеграция

[15.4] Прототип

[15.5] Технологический процесс

[15.6] Инструментальная поддержка

[15.7] Резюме

[15.8] Глава 12

[16] Технологический процесс

[17] тестирования

[17.1] Цель

[17.2] Качество

[17.3] Тестирование в итеративном жизненном цикле

[17.4] Классификация тестов

[17.5] Модель тестирования

[17.6] Исполнители и артефакты

[17.7] Технологический процесс

[17.8] Инструментальная поддержка

[17.9] Резюме

[17.10] Глава 13

[18] Технологический процесс управления конфигурацией

[19] и изменениями

[19.1] Цель

[19.2] Куб ССМ

[19.3] Исполнители и артефакты

[19.4] Технологический процесс

[19.5] Инструментальная поддержка

[19.6] Резюме

[19.7] Глава 14

[20] Технологический процесс управления средой

[20.1] Цель

[20.2] Исполнители и артефакты

[20.3] Технологический процесс

[20.4] Резюме

[20.5] Глава 1.'

[21] Технологический процесс распространения

[21.1] Цель

[21.2] Типы распространения

[21.3] Исполнители и артефакты

[21.4] Технологический процесс

[21.5] Создание версии

[21.6] Бета-тест версии

[21.7] Резюме

[21.8] Глава 16

[22] Типичные планы итераций

[22.1] Цель

[22.2] Определение видения продукта и бизнес-плана

[22.3] Создание архитектурного прототипа

[22.4] Реализация системы

[22.5] Резюме

[22.6] Глава 17

[23] Конфигурирование

[24] и реализация

[25] Rational Unified Process

[25.1] Введение

[25.2] Эффект реализации процесса

[25.3] Поэтапная реализация Rational Unified Process

[25.4] Конфигурирование процесса

[25.5] Реализация процесса — тоже проект

[25.6] Резюме

[25.7] Приложение А

[26] Список исполнителей

[26.1] Приложение Б

[27] Список артефактов

[27.1] Сокращения

[27.2] Глоссарий

Часть I. Процесс 15

1 Советы по организации процесса разработки
программного обеспечения 17

Значение программного обеспечения 17
Проблемы в процессе разработки программного

обеспечения 18

Как лучше всего организовать процесс разработки 19

Разрабатывайте итеративно 19

Управляйте требованиями 21

Пользуйтесь модульными архитектурами 22

Используйте визуальное моделирование 24

Не забывайте о проверке качества 25

Следите за изменениями 26

Rational Unified Process 27

2 Rational Unified Process 29

Что такое Rational Unified Process 29

Rational Unified Process как продукт 30
Структура процесса: два измерения

Лучшие советы по разработке в Rational Unified Process 34

Прочие ключевые свойства Rational Unified Process 39

Краткая история Rational Unified Process 41

Резюме 42

3 Статическая структура: описание процесса 44

Модель Rational Unified Process 44

Технологические процессы 51

Дополнительные элементы процесса 54

Контур процесса 56

4 Динамическая структура: итеративная разработка 58

Обзор фаз 68

Особенности итеративного подхода 76

Резюме 78

5 Процесс, основанный на архитектуре 79

Важность моделей 79

Архитектура 79

Важность архитектуры 80

Определение архитектуры 81

Представление архитектуры 82

Процесс, основанный на архитектуре 86

Цель архитектуры 87

Модульная разработка 88

Другие архитектурные концепции 89

6 Процесс, управляемый прецедентами 91

Определения 91

Определение прецедентов 96

Развитие прецедентов 96

Организация прецедентов 97

Прецеденты в процессе 99

Часть П. Технологические процессы 101

7 Технологический процесс управления проектом 103

Цель 103

Планирование итеративного проекта 104

Понятие риска 106

Понятие метрики 108

Что такое метрика 109

Исполнители и артефакты 110

Технологический процесс 111

Создание плана итерации 119

8 Технологический процесс моделирования производства 124

Цель 124

Зачем моделировать производство 124

Использование методов программотехники в процессе... 126

Сценарии моделирования производства 127

Исполнители и артефакты 128

Технологический процесс 130

От моделей производства к моделям системы 131

Моделирование производства программного обеспечения 136

Инструментальная поддержка 136

9 Технологический процесс управления требованиями 137

Цель 137

Что такое"требование" 138

Типы требований 139

Сбор требований и управление ими 141
Проектирование интерфейса, ориентированного

на пользователя 143

Технологический процесс управления требованиями 143

Исполнители 145

Артефакты 146

Инструментальная поддержка 148

10 Технологический процесс анализа и проектирования 149

Цель 149

Анализ против проектирования 149

Насколько стоит продумывать проект 150

Исполнители и артефакты 150

Модель проектирования 152

Модель анализа 152

Роль интерфейсов , 152

Артефакты систем реального времени 152

Модульное проектирование 153

Технологический процесс 153

Инструментальная поддержка 157

11 Технологический процесс реализации 158

Цель 158

Конструкции 159

Интеграция 159

Прототипы 160

Исполнители и артефакты 162

Технологический процесс 163

Инструментальная поддержка 165

12 Технологический процесс тестирования 166

Цель 166

Качество 166

Тестирование в итеративном жизненном цикле 167

Классификация тестов 167

Модель тестирования 170

Исполнители и артефакты 172

Технологический процесс 172

Инструментальная поддержка 176

13 Технологический процесс управления конфигурацией

и изменениями 178

Цель 178

Куб ССМ 179

Технологический процесс 185

Инструментальная поддержка 187

14 Технологический процесс управления средой 189

Цель 189

Исполнители и артефакты 189

Технологический процесс 191

15 Технологический процесс распространения 194

Цель 194

Исполнители и артефакты 196

Технологический процесс 198

16 Типичные планы итераций 201

Цель 201

Определение видения продукта и бизнес-плана 201

Создание архитектурного прототипа 204

Реализация системы 208

17 Конфигурирование и реализация Rational Unified Process 212

Введение 212

Эффект реализации процесса 212

Поэтапная реализация Rational Unified Process 214

Конфигурирование процесса 219

Реализация процесса — тоже проект 220

Приложение А. Список исполнителей 223

Приложение Б. Список артефактов 226

Сокращения 229

Глоссарий 230

Предметный указатель 235


Сильвии, Элис, Зо и Николасу

Введение

Rational Unified Process — это процесс разработки программного обеспечения, созданный и распространяемый корпорацией Rational Software. Это — упорядоченный подход к распределению задач и обязанностей в организации-разработчике и управлению ими. Цель этого процесса — создать в рамках прогнозируемого бюджета и графика работ программное обеспечение высокого качества, отвечающее требованиям конечного пользователя.

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

Книга, которую вы держите в руках, — это введение в понятия, структуру, содержание и мотивацию Rational Unified Process.

Основные задачи книги

Благодаря этой книге вы

узнаете, чем является Rational Unified Process;

освоите словарь Rational Unified Process и поймете его структуру;

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

поймете, как Rational Unified Process может стать путеводителем вашего проекта.

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

В этой книге неоднократно упоминается язык UML (Unified Modeling Language), но более подробно он рассматривается в таких работах, как The Unified Modeling Language User Guide и The Unified Modeling Language Reference Manual.

В данном вводном руководстве обсуждается моделирование и объектно-ориентированные технологии, а не методы проектирования, поэтому эта книга не научит вас, как нужно моделировать. Подробные руководства по всевозможным методам, встроенным в Rational Unified Process, можно найти только в продукте этого процесса.
Введение 11

В некоторых главах книги рассматриваются вопросы управления проектом, описывающие аспекты планирования итеративного развития, управления риском и т.д. При всем этом данная книга не является всеобъемлющим руководством по управлению проектом и экономике программного обеспечения. Если вам требуется информация по этим вопросам, обратитесь к работе Software Project Management: A Unified Framework.

Кроме того, можно порекомендовать книгу The Unified Software Development Process, описывающую процесс, частным, конкретизированным экземпляром которой является Rational Unified Process.

Для кого предназначена эта книга

Книга Введение в Rational Unified Process, второе издание, написана для широкого круга людей, задействованных в процессе разработки программного обеспечения: руководителей проекта, разработчиков, специалистов по качеству, технологов, методистов, системных инженеров и аналитиков.

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

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

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

Как использовать эту книгу

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

Руководители проекта могут ограничиться чтением глав 1, 2, 4 и 7, в которых рас-"крйгннетсй •суть 'йтернтинйгл'с/, 'vnf/нъииемаго "рисками, тхртщесса "ризр'сйлтсй тгръ-граммного обеспечения.

Технологам и методистам, возможно, придется адаптировать Rational Unified Process к нуждам их организаций. Эта категория людей должна внимательно изучить главы 3 и 17, в которых описана структура процесса и общий подход к реализации Rational Unified Process.

Структура книги

Книга разбита на две части.

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


12 Введение

Глава 1. Советы по организации процесса разработки программного обеспечения

Глава 2. Rational Unified Process

Глава 3. Статическая структура: описание процесса

Глава 4. Динамическая структура: итеративная разработка

Глава 5. Процесс, основанный на архитектуре

Глава 6. Процесс, управляемый прецедентами

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

Глава 7. Технологический процесс управления проектом

Глава 8. Технологический процесс моделирования производства

Глава 9. Технологический процесс управления требованиями

Глава 10. Технологический процесс анализа и проектирования

Глава 11. Технологический процесс реализации

Глава 12. Технологический процесс тестирования

Глава 13. Технологический процесс управления конфигурацией и изменениями

Глава 14. Технологический процесс управления средой

Глава 15. Технологический процесс распространения

Глава 16. Типичные планы итераций

Глава 17. Конфигурирование и реализация Rational Unified Process

Большинство глав этой части содержит шесть разделов.

Цель технологического процесса

Определения и основные понятия

Исполнители и артефакты

Типичный процесс: обзор видов деятельности

Инструментальная поддержка

Резюме

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

Дополнительная информация

Информацию о Rational Unified Process, в том числе спецификацию и загружаемую демо-версию, можно получить на узле корпорации Rational Software: wurw.ratianal.com/rup_info/.

Для тех, кто уже использует Rational Unified Process и нуждается в дополнительной информации, можно порекомендовать Центр ресурсов (Rational Unified Process Resource Center), в котором имеются дополнительные продукты, обновления и сведе-


Введение 13

ния о партнерах корпорации Rational Software. Гиперссылку на Центр ресурсов можно найти в онлайновой версии данного процесса.

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

Отличия второго издания

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

Помимо этого, существующий материал был уточнен, в том числе улучшено изложение вопросов проектирования интерфейса приложений (особенно по отношению к разработке эффективных Web-приложений) и разработки систем с использованием шаблонов и контуров. Здесь также представлен обзор разработки систем реального времени и реагирующих систем. Тестирование теперь сопровождает весь цикл разработки, начиная от утверждения архитектурных прототипов и заканчивая проверкой произведенного продукта. И наконец, в этой работе введены сетевые графики процесса, позволяющие получить общее представление о принципах применения процесса к проектам и технологиям различных типов. Кроме того, изложение материала было углублено, и теперь здесь представлены дополнительные контрольные таблицы и директивы для артефактов, видов деятельности и фаз процесса.

Благодарности

Rational Unified Process — это отражение мудрости множества профессионалов в области разработки программного обеспечения, работающих в корпорации Rational Software (и не только в ней). (История этого процесса излагается в главе 2.) Создание книги, даже такой маленькой и скромной, как эта, потребовало значительных усилий преданных своему делу людей, которых мне бы хотелось здесь назвать.

В первую очередь, это сотрудники группы разработки Rational Process Development Group, которые создали Rational Unified Process и внесли свой вклад в данную книгу. Некоторые из этих имен вы еще увидите, поскольку многие главы книги написаны совместно с этими людьми.

Курт Биттнер (Kurt Bittner) принимал участие в написании глав, посвященных
анализу и проектированию, тестированию и управлению проектом, а также
освещал вопросы проектирования данных.

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

Лесли   Пробаско   (Leslee  Probasco)   внес   свой   вклад   в  главу,   посвященную
технологическому процессу управления требованиями.

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


14 Введение

Хэкан Дирхэдж (Hakan Dyrhage) внес множество идей относительно органи
зации и структуры процесса, его реализации и конфигурации; кроме того, он
координировал развитие онлайновой версии процесса.

Джон Смит (John Smith) расширил вопросы управления проектом для RUP 2000.

Джас Медхэр (Jas Madhur) помогал в вопросах, связанных с распространением,
а также управлением конфигурацией и изменениями.

Брюс Кац (Bruce Katz) внес свой вклад в вопросы тестирования процесса.

Маргарет Чен (Margaret Chan) отвечала за интеграцию продукта и изготов
ление большинства иллюстраций к книге.

Дебби   Грей   (Debbie   Gray)   была   верным   административным   помощником
команды, разбросанной по девяти часовым поясам.

Мы крайне признательны Грейди Бучу (Grady Booch) за написание главы 1

Выражаю признательность Перу Кроллу (Per Kroll), управляющему отделом сбыта Rational Unified Process, Паэру Дженсону (Paer Jansson), управляющему производством, а также недавно присоединившемуся Мэтту Хердону (Matt Herdon). Благодарю Кристину Гисселберг (Christina Gisselberg) и Эрика Тьюрсона (Eric Turesson), спроектировавших и создавших онлайновую версию процесса. Стефан Элквист (Stefan Ahlqvist) был автором идей проектирования пользовательского интерфейса. Чинх Во (Chinh Vo) помог собрать данную книгу в единое целое.

Rational Unified Process и данная книга только выиграли от рецензирования и внесенных идей. За это я благодарю Дейва Бернштейна (Dave Bernstein), Грейди Буча (Grady Booch), Джефа Клемма (Geoff Clemm), Кэтрин Коннор (Catherine Connor), Майка Делвина (Mike Delvin), Кристиана Эренбурга (Christian Ehrenborg) (он же "доктор Прецедент"), Сэма Гукенхаймера (Sam Guckenheimer), Бьерна Густафсона (Bjorn Gustafsson), Айвара Джейкобсона (Ivar Jacobson), Рона Крубека (Ron Krubek), Дина Леффингвелла (Dean Leffingwell), Эндрю Лайонса (Andrew Lyons), Брюса Мала-ски (Bruce Malasky), Роджера Оберга (Roger Oberg), Гари Полиса (Gary Pollice), Лесли Пробаско (Leslee Probasco), Терри Кватрани (Terri Quatrani), Уокера Ройса (Walker Royce), Джима Румбаха (Jim Rumbaugh), Джона Смита (John Smith) и Брайана Уайта (Brian White).

Хотелось бы поблагодарить наших партнеров— Скотта Амблера (Scott Ambler), a также компанию Ensemble Systems, службу IBM Global Services и компанию Content Integration — за сотрудничество.

Отдельная благодарность сообществу Rational, а особенно нашим британским друзьям, для которых процесс Rational Unified Process всегда представлял особый интерес: Яну Гейвину (Ian Gavin), Яну Спенсу (Ian Spence) и Майку Тудболу (MikeTudball).

Франция и Швеция были представлены Джо Хэмпхиллом (Joy Hemphill) и Памелой Кларке (Pamela Clarke).

И наконец, огромное спасибо нашему редактору Дж. Картеру Шанклину (J. Carter Shanklin), а также Кристину Эриксону (Kristin Erickson), Мэрилин Раш (Marilyn Rash) и ее команде и сотрудникам издательства Addison-Wesley Longman за то, что эта книга вышла так быстро.

Филипп Крачтен Ванкувер, Канада


Глава 1

                 Советы по организации

                    процесса разработки

             программного обеспечения

Грейди Буч (Grady Booch)

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

Значение программного обеспечения

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

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

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

Grady Booch. Leaving Kansas. IEEE Software 15(1), January-February 1998, pp. 32-35.


18 Часть I. Процесс

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

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

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

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

Неточное понимание нужд конечных пользователей

Неспособность работы в условиях меняющихся требований

Продукт состоит из несовместимых модулей

Программное обеспечение трудно поддерживать или расширять

Позднее обнаружение существенных изъянов проекта

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

Неприемлемая производительность

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

Ненадежный процесс создания-выпуска

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

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

Неумелое управление специальными требованиями

Неопределенная и неточная связь

"Хрупкая"архитектура

Чрезмерная сложность

Необнаруженные противоречия в требованиях, проектах и реализациях

Недостаточное тестирование

Субъективная оценка состояния проекта

Неспособность справиться с реализовавшимся риском

2 Caper Jones. Patterns of Software Systems Failure and Success. London: International Thompson Computer Press, 1996; и Edward Yourdon. Death March: Managing "Mission Impossible" Projects. Upper Saddle River, NJ: Prentice-Hall, 1997.


Глава 1. Советы по организации процесса разработки... 19

Неуправляемое распространение изменений

Недостаточная автоматизация

Как лучше всего организовать процесс разработки

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

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

  1.  Разрабатывайте итеративно
  2.  Управляйте требованиями
  3.  Пользуйтесь модульными архитектурами
  4.  Используйте визуальное моделирование
  5.  Не забывайте о проверке качества
  6.  Следите за изменениями

Разрабатывайте итеративно

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

Основной проблемой описанного подхода является рост риска со временем; так что устранять ошибки предыдущих фаз становится слишком дорого. Первоначальный проект, наверняка, будет иметь изъяны в ключевых требованиях, и, более того, позднее обнаружение проектных недоработок может привести к перерасходу средств или отказу от проекта. Как сказал Том Гилб (Tom Gilb): "Если вы активно не нападете на риски вашего проекта, они активно нападут не вас"1. Водопадный подход имеет тенденцию к "маскировке" действительных рисков до тех пор, пока не будет слишком поздно на них реагировать.

3 См.  работу по лучшим  методам сети  Software Program Manager's Network no  адресу
http: //www. spmn. com.

4 Tom Gilb. Principles of Software Engineering Management. Harlaw, UK: Addison-Wesley, 1988, p.73.

Время Рис. 1.1. Водопадный жизненный цикл

Альтернативой водопадному подходу является поэлементный итеративный процесс, показанный на рис. 1.2. При таком подходе, основанном на спиральной модели Барри Боема (Barry Boehm)', установление рисков, угрожающих проекту, осуществляется на более ранних этапах жизненного цикла, когда еще можно эффективно и своевременно реагировать на них. С помощью данного подхода осуществляется непрерывное обнаружение, исследование и реализация, причем при каждой итерации группа разработчиков управляет артефактами проекта в целях их постепенного сближения.

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

  1.  Существенные недоразумения становятся очевидными на ранних этапах жиз
    ненного цикла, когда еще можно принять меры по их устранению.
  2.  Описанный подход способствует установлению обратной связи с пользовате
    лем в целях выяснения истинных требований к системе.
  3.  Группа разработчиков сосредотачивается на особо важных вопросах проекта, а
    не на тех, которые только отвлекают внимание команды от действительно
    опасных моментов.
  4.  Непрерывное итеративное тестирование позволяет объективно оценить со
    стояние проекта.
  5.  Противоречия в требованиях, проектах и реализациях выявляются раньше.

5 Barry W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, May 1988, pp. 61-72.


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

Управляйте требованиями

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

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

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

  1.  Управление требованиями позволяет упорядочить процесс разработки про
    граммного обеспечения.
  2.  Связь основывается на определенных требованиях.
  3.  


22 Часть I. Процесс

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

Пользуйтесь модульными архитектурами

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

Системная архитектура включает решения относительно

Организации программной системы;

Выбора структурных элементов и их интерфейсов при формировании системы;

Поведения этих структурных элементов, обусловленного совместной их работой;

Формирования из структурных элементов и линий их поведения постепенно
укрупняющихся подсистем;

Архитектурного стиля, направляющего структуру, состоящую из элементов и
их интерфейсов, а также их совместной работы и объединения.

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

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

Важным подходом к архитектуре программного обеспечения является модульная разработка (component-based developmentCBD), позволяющая повторно использовать или настраивать компоненты из множества коммерчески доступных источников. Модель компонентных объектов (component object model — СОМ) корпорации Microsoft, архитектура CORBA (Common Object Request Broker Architecture) группы Object Management Group и Enterprise JavaBeans (EJB) от компании Sun Microsystems — вот


Глава 1. Советы по организации процесса разработки... 23

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

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

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

  1.  Модули способствуют эластичности архитектуры.
  2.  При внесении изменений модульная структура позволяет явно разделить обя
    занности между элементами системы.
  3.  


Моделирование — это важно, поскольку оно помогает команде разработчиков визуализировать, определять, создавать и документировать структуру и поведение архитектуры системы. Использование стандартного языка моделирования, такого как UML (Unified Model Language — унифицированный язык моделирования), позволяет членам команды разработчиков однозначно доносить свои решения друг другу.

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

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


24 Часть I. Процесс

  1.  Благодаря стандартизованным конструкциям (таким, как СОМ+, CORBA и EJB)
    и коммерчески доступным компонентам возможно повторное использование
    системы.
  2.  На основе модулей естественным образом организовывается управление кон
    фигурацией.
  3.  Средства визуального моделирования автоматизируют модульную разработку.

Используйте визуальное моделирование

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


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

  1.  Прецеденты и сценарии однозначно определяют линии поведения.
  2.  Модели однозначно фиксируют структуру программного обеспечения.
  3.  Выявляются немодульные и неэластичные архитектуры.
  4.  При необходимости можно скрыть подробности.
  5.  В однозначных проектах более явно видны противоречия.
  6.  Качество приложения начинается с хорошего проекта.
  7.  Средства визуального моделирования поддерживают моделирование на
    языке
    UML.

Не забывайте о проверке качества

Как показано на рис. 1.5, поиск и исправление ошибок после распространения программного обеспечения обходится в 100-1000 раз дороже, чем до распространения. По этой причине важно постоянно определять качество системы, используя в качестве критериев ее функциональные возможности, надежность и эффективность.

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


26 Часть I. Процесс

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

  1.  Состояние проекта оценивается объективно, а не субъективно, поскольку оце
    ниваются результаты тестов, а не то, что написано на бумаге.
  2.  Эта объективная оценка показывает противоречия в требованиях, проектах и
    реализациях.
  3.  Тестирование и контроль сосредоточены в областях наибольшего риска; сле
    довательно, в этих областях повышается качество и эффективность системы.
  4.  Дефекты выявляются на более ранних этапах, что значительно снижает стои
    мость их исправления.
  5.  Автоматизированные средства тестирования позволяют тестировать функцио
    нальные возможности, надежность и производительность системы.

Следите за изменениями

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

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

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

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

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

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

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


Глава 1. Советы по организации процесса разработки... 27

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

Рабочие среды содержат все артефакты, согласовывающие процесс.

Распространение изменений поддается оценке и контролю.

Изменения можно поддерживать в устойчивых, настраиваемых системах.

             

               Rational Unified Process

Существует четыре функции процесса разработки программного обеспечения'.

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

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

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

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

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

Резюме

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

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

6 Grady Booch. Object Solutions- Managing the Object-Oriented Project. Reading, MA: Addison-Wesley, 1995.


28 Часть I. Процесс

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

Разрабатывайте итеративно
Управляйте требованиями

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

Не забывайте о проверке качества
Следите за изменениями

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


Глава 2

Rational Unified Process

В настоящей главе дается краткое введение в Rational Unified Process, выделяются основные его свойства, а также приводится описание структуры и продукта процесса.

Что такое Rational Unified Process

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

Rational Unified Process — это продукт процесса, разработанный корпорацией Rational Software. Он неразрывно связан с выпускаемым корпорацией набором средств для разработки программного обеспечения. (Получить Rational Unified Process можно на компакт-диске от корпорации Rational Software или через Internet). Данная книга также является частью Rational Unified Process, хотя в ней представлена лишь небольшая часть базы знаний Rational Unified Process. Например, здесь описана структура продукта процесса.

Rational Unified Process — это еще и контур процесса, который можно адаптировать и расширить для удовлетворения требований принявшей его организации. О том, как организовывается контур процесса, подробно рассказывается в главе 3; там же вводится понятие модели прогресса, элементов, составляющих его контур.

Rational Unified Process объединяет многие из лучших. методов разработки современного программного обеспечения, причем им придана форма, подходящая для значительного числа проектов и организаций. В частности, Rational Unified Process следует шести лучшим советам разработки, представленным в главе 1.

  1.  Разрабатывайте итеративно
  2.  Управляйте требованиями
  3.  Пользуйтесь модульными архитектурами
  4.  Используйте визуальное моделирование
  5.  Не забывайте о проверке качества
  6.  Следите за изменениями
  7.  


30 Часть I. Процесс

Rational Unified Process как продукт

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

"Процесс разработки программного обеспечения — это тоже программное обеспечение", — сказал Ли Остервейл (Lee Osterweil) . В противоположность работам в "пыльных переплетах", Rational Unified Process проектируется, разрабатывается, сдается и эксплуатируется подобно любому программному продукту. Действительно, Rational Unified Process присущи многие свойства программных продуктов.

Корпорация   Rational   Software   регулярно   выпускает   обновленные   версии
Rational Unified Process.

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

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

Он составляет единое целое с множеством средств разработки программного
обеспечения от корпорации
Rational Software, поэтому для каждого элемента
процесса предлагается подробное руководство разработчика.

Подход к процессу как к программному продукту имеет следующие преимущества.

Процесс никогда не устаревает;  через определенные промежутки  времени
компании получают новые версии, содержащие новые и исправленные методы.

Все участники проекта могут по внутренней сети получить последнюю версию
процесса.

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

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

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

В каждом проекте или отделе может использоваться собственная версия процесса.

1 Lee Osterweil. Software Processes Are Software Too. Proceedings of the Ninth International Conference on Software Engineering, pp. 2-13, Mar. 30-Apr. 2, 1987, Monterey, CA.


Глава 2. Rational Unified Process 31

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

Структура продукта процесса

Продукт состоит из следующего.

  1.  Онлайновой   версии  Rational   Unified   Process,   распространяемой   на   компакт-
    дисках или через
    Internet. Данная версия называется электронным руководством;
    она снабжена Web-описанием процесса на языке HTML.
  2.  Вводного курса, находящегося в ваших руках.

Электронное руководство может использоваться с любым из популярных Web-броузеров, таким как Netscape Navigator™ или Microsoft Internet Explorer™. Нужная информация находится легко, чему способствует следующее.

Обширная система гиперссылок

Графическая навигация (большинство графических элементов — это гипер
ссылки на изображаемые элементы процесса)

Броузер в форме иерархического дерева

Подробное оглавление

Встроенный поисковый механизм

Подробная схема Web-узла

Все это можно увидеть на рис. 2.1, представляющем собой копию экрана со страницей электронного руководства.

В электронном руководстве процесса находится не только полное описание собственно процесса. В нем также имеется следующее.

Инструментальные наставники, обеспечивающие дополнительное руководство
при работе с любым средством разработки программного обеспечения от
корпорации
Rational Software, таким как средство визуального моделирования
Rational Rose или средство управления конфигурацией ClearCase.

Шаблоны для основных артефактов процесса.

Шаблоны Microsoft Word и Adobe FrameMaker для большинства распро
страненных типов документов и отчетов

Шаблоны Rational SoDA,  позволяющие автоматизировать процесс сбора
документов из множества источников

—    Шаблоны RequisitePro, облегчающие управление требованиями

Шаблоны    Microsoft    Project,    помогающие    планировать    итеративные проекты на основе процесса RUP

- Шаблоны HTML, позволяющие расширить собственно онлайновый процесс

• Примеры артефактов простого проекта


Рис. 2.1. Электронная версия Rational Unified Process

Начиная с версии RUP 2000, электронное руководство стало вмещать различные варианты Rational Unified Process. Руководство содержит общий, стандартный процесс Rational Unified Process, который может использоваться в качестве отправной точки для многих процессов разработки программного обеспечения. Помимо этого, в руководстве имеются типовые варианты определенных классов разработки вместе с дополнительными или специализированными руководствами. Одним из таких специализированных вариантов является процесс RUP для электронной коммерг!,ии. Впрочем, в данной книге рассмотрены только общие аспекты Rational Unified Process; ни один из специализированных вариантов не рассматривается.

Кто использует Rational Unified Process

К концу 1999 года Rational Unified Process применяли многие (более тысячи) компании. Он использовался в различных прикладных областях, в больших и малых проектах, что доказывает его универсальность и широкую применимость. Назовем лишь несколько отраслей и компаний, разбросанных по всему миру, в которых применяется Rational Unified Process.

Телекоммуникация: Ericsson, Alcatel, MCI

Транспорт, авиационно-космическая отрасль, оборонная промышленность:
Lockheed-Martin, British Aerospace


Глава 2. Rational Unified Process 33

Промышленность: Xerox, Volvo, Intel

Финансы: Visa, Merrill Lynch, Schwab

Интеграторы систем: Ernst & Young, Oracle, Deloitte & Touche

Большинство из указанных компаний используют Rational Unified Process в электронной коммерции или собираются это сделать в обозримом будущем. Похоже, что в нашей промышленности постепенно начинают назревать перемены: по мере увеличения напряженности рынка и спроса на качественные продукты, компании перенимают чужой опыт и прислушиваются к полезным советам.

Все эти компании по-разному используют Rational Unified Process. Некоторые делают это формально; они развивают собственные процессы на базе Rational Unified Process и строго их придерживаются. Другие же применяют Rational Unified Process более свободно, считая его всего лишь источником советов, шаблонов и руководств, подобных электронному руководству по разработке программного обеспечения.

Структура процесса: два измерения

На рис. 2.2 показана общая архитектура Rational Unified Process. В процессе можно выделить две структуры, или, если желаете, два измерения.


34 Часть I. Процесс

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

Вертикальная ось представляет основные технологические процессы, логичес
ки объединяющие виды деятельности по их природе.

Первое измерение представляет динамическую сторону процесса, т.е. показывает, как процесс происходит. Это выражается через циклы, фазы, итерации и вехи. Подробнее эти вопросы рассматриваются в главе 4, "Динамическая структура: итеративная разработка" и в главе 7, "Технологический процесс управления проектом".

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

Лучшие советы по разработке в Rational Unified Process

В данном разделе пересматриваются советы, предложенные Грейди Бучем в главе 1, и определяется, как они реализованы в Rational Unified Process. Впрочем, отметим, что, кроме следования этим советам, Rational Unified Process имеет и многие другие преимущества, позволяющие оптимально реализовать процесс разработки программного обеспечения.

Итеративная разработка

Итеративный подход, рекомендуемый Rational Unified Process, лучше линейного, или водопадного, по следующим причинам.

Он позволяет учитывать меняющиеся требования. Дело в том, что требова
ниям свойственно меняться. Меняющиеся требования и "дрейф" требований всегда
были главными источниками неприятностей,  которые  привели  к поздней  сдаче
проекта, несоответствию графику работ, неудовлетворенным заказчикам и разоча
рованным разработчикам.

Интеграция в Rational Unified Process — это не совсем "большой взрыв" в конце,
а скорее постепенная сборка элементов. Такой итеративный подход — это процесс
практически непрерывной интеграции. То, что раньше составляло длительный этап
(и  занимало  до  40%  работ  в  конце  проекта),  теперь  разбито  на 6-9  меньших
составляющих, в каждую из которых требуется объединить уже значительно меньшее
число компонентов.

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


Глава 2. Rational Unified Process 35

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

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

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

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

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

Руководители проекта часто пренебрегают итеративным подходом, считая его чем-то сродни бесконечной, неуправляемой и нудной работе. Однако необходимо отметить, что в Rational Unified Process итеративный подход весьма управляем; число итераций, их продолжительность и цели определяются заранее. Кроме того, заблаговременно устанавливается, кто чем занимается и кто за что отвечает. Определены объективные критерии состояния процесса. Да, при переходе от одной итерации к другой существует возможность переработки сделанного, но даже это тщательно контролируется.

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


36 Часть I. Процесс

Управление требованиями

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

Давайте рассмотрим некоторые особенности эффективного управления требованиями.

Лучший контроль над сложными проектами

Для вышедших из-под контроля проектов характерно непонимание поведения разрабатываемой системы и "дрейф" требований.

Ш    Более качественное программное обеспечение и довольные пользователи

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

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

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

Улучшение связи в команде

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

К рассмотренному выше мы еще вернемся в главе 9, "Технологический процесс управления требованиями", где данные свойства Rational Unified Process будут пересмотрены и расширены. В главе 13, "Технологический процесс управления конфигурацией и изменениями", будут описаны различные аспекты, касающиеся отслеживания изменений.

Архитектура и использование компонентов

Хотя всем жизненным циклом Rational Unified Process управляют прецеденты, в основе всех проектных действий лежит другое понятие — архитектура (либо архитектура системы, либо, для преимущественно программных систем, архитектура системы программного обеспечения). Основное внимание при первых итерациях процесса обращается на создание и утверждение архитектуры системы программного обеспечения, которая в исходном цикле разработки принимает форму реализуемого архитектурного прототипа, постепенно (итерация за итерацией) эволюционирующего в окончательную систему.

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


Глава 2. Rational Unified Process 37

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

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

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

единую систему.

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

В последнее время появились коммерчески успешные инфраструктуры, под
держивающие концепцию модульного программного обеспечения, — такие как
технология
CORBA (Common Object Request Broker Architecture), Internet,
ActiveX и JavaBeans, — что дало начало индустрии готовых компонентов для
различных приложений. Это позволяет разработчикам покупать и объединять
эти компоненты, не занимаясь самостоятельно их разработкой.

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

Модульная разработка поддерживается и процессом Rational Unified Process.

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

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


38 Часть I. Процесс

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

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

К вопросам архитектуры и ее руководящей роли в Rational Unified Process мы еще вернемся в главе 5, в которой это понятие определяется и подробно объясняется.

Моделирование и язык UML

Значительная часть Rational Unified Process связана с разработкой и эксплуатацией моделей разрабатываемой системы. Модели помогают понимать и очерчивать как проблему, так и ее решение. Модель — это упрощение действительности, помогающее охватить большую, сложную систему, не поддающуюся пониманию во всей своей полноте. В данной книге представляется несколько моделей: модель прецедентов (глава 6), модели производства (глава 8), модели проектирования и анализа (глава 10), а также модель тестирования (глава 12).

Унифицированный язык моделирования UML (Unified Modeling Language) — это графический язык визуализации, спецификации и документирования артефактов преимущественно программной системы. Язык UML представляет собой стандартное средство создания чертежей системы, включающих такие абстрактные понятия, как процессы производства и функции системы, а также конкретные понятия, такие как классы, написанные на определенных языках программирования, схемы баз данных и программные компоненты с возможностью повторного использования .

UML — это стандартный язык изображения различных моделей; он не может подсказать, как разрабатывать программное обеспечение. Этот язык предоставляет словарь, но не объясняет, как написать книгу. Поэтому наряду с языком UML корпорация Rational Software разработала взаимодополняющий продукт — Rational Unified Process (например, процесс RUP 2000 используется совместно с языком UML версии 1.4). Rational Unified Process — это консультант по вопросам эффективного использования языка UML в моделировании. Он рассказывает, какие модели необходимы, почему они необходимы и как их создавать.

Качество процесса и продукта

Часто спрашивают, почему не существует исполнителя, отвечающего за качество Rational Unified Process. Ответ заключается в том, что качество продукта определяется не усилиями нескольких человек; за качество несут ответственность все сотрудники организации-разработчика. При разработке программного обеспечения основные требования к качеству относятся к двум областям: качеству продукта и качеству процесса. Рассмотрим их подробнее.

Качество продукта

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

^Crady Booch et. al. UML Users Guide. Reading, MA: Addison-Wesley Longman, 1998.


Глава 2. Rational Unified Process 39

Качество процесса

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

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

Управление конфигурацией и изменениями

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

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

Прочие ключевые свойства Rational Unified Process

Помимо шести лучших советов по организации процесса разработки, стоит указать еще три важные особенности Rational Unified Process.

Роль прецедентов в управлении многими аспектами разработки

Использование контуров процессов, которые организация, принявшая Rational
Unified Process, может расширять и адаптировать для своих нужд

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

Разработка, управляемая прецедентами

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


38 Часть I. Процесс

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

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

К вопросам архитектуры и ее руководящей роли в Rational Unified Process мы еще вернемся в главе 5, в которой это понятие определяется и подробно объясняется.

Моделирование и язык UML

Значительная часть Rational Unified Process связана с разработкой и эксплуатацией моделей разрабатываемой системы. Модели помогают понимать и очерчивать как проблему, так и ее решение. Модель — это упрощение действительности, помогающее охватить большую, сложную систему, не поддающуюся пониманию во всей своей полноте. В данной книге представляется несколько моделей: модель прецедентов (глава 6), модели производства (глава 8), модели проектирования и анализа (глава 10), а также модель тестирования (глава 12).

Унифицированный язык моделирования UML (Unified Modeling Language) — это графический язык визуализации, спецификации и документирования артефактов преимущественно программной системы. Язык UML представляет собой стандартное средство создания чертежей системы, включающих такие абстрактные понятия, как процессы производства и функции системы, а также конкретные понятия, такие как классы, написанные на определенных языках программирования, схемы баз данных и программные компоненты с возможностью повторного использования .

UML — это стандартный язык изображения различных моделей; он не может подсказать, как разрабатывать программное обеспечение. Этот язык предоставляет словарь, но не объясняет, как написать книгу. Поэтому наряду с языком UML корпорация Rational Software разработала взаимодополняющий продукт — Rational Unified Process (например, процесс RUP 2000 используется совместно с языком UML версии 1.4). Rational Unified Process — это консультант по вопросам эффективного использования языка UML в моделировании. Он рассказывает, какие модели необходимы, почему они необходимы и как их создавать.

Качество процесса и продукта

Часто спрашивают, почему не существует исполнителя, отвечающего за качество Rational Unified Process. Ответ заключается в том, что качество продукта определяется не усилиями нескольких человек; за качество несут ответственность все сотрудники организации-разработчика. При разработке программного обеспечения основные требования к качеству относятся к двум областям: качеству продукта и качеству процесса. Рассмотрим их подробнее.

Качество продукта

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

3 Crady Booch et. al. UML Users Guide. Reading, MA: Addison-Wesley Longman, 1998.


Глава 2. Rational Unified Process 39

Качество процесса

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

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

Управление конфигурацией и изменениями

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

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

Прочие ключевые свойства Rational Unified Process

Помимо шести лучших советов по организации процесса разработки, стоит указать еще три важные особенности Rational Unified Process.

Роль прецедентов в управлении многими аспектами разработки

Использование контуров процессов, которые организация, принявшая Rational
Unified Process, может расширять и адаптировать для своих нужд

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

Разработка, управляемая прецедентами

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


40 Часть I. Процесс

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

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

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

Конфигурирование процесса

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

Процессу не нужно следовать слепо, выполняя бесполезную работу и создавая артефакты, имеющие незначительную ценность. Наоборот, процесс следует максимально сжать, но так, чтобы при этом он по-прежнему осуществлял свою миссию: быстрое создание прогнозируемого высококачественного программного обеспечения. Лучшей стратегией организации, принявшей Rational Unified Process, является дополнение процесса собственными правилами и процедурами.

В число потенциально модифицируемых, дополняемых и удаляемых элементов процесса входят артефакты, виды деятельности, исполнители и технологические процессы, а также директивы и шаблоны артефактов. Все эти фундаментальные элементы процесса представлены в главе 3, "Статическая структура: описание процесса", где описывается модель процесса, лежащая в основе этого контура. В главе 17, "Конфигурирование и реализация Rational Unified Process", объясняется, как организация, принявшая Rational Unified Process, может реализовать процесс, и изображаются шаги, связанные с его конфигурированием.

Инструментальная поддержка

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


Глава 2. Rational Unified Process 41

В главе 3 вводится понятие инструментальных наставников, обеспечивающих управление, связанное с использованием инструментальных средств. По мере рассмотрения различных технологических процессов (главы с 7 по 15) будут рекомендоваться предпочтительные средства для поддержки видов деятельности каждого процесса.

Краткая история Rational Unified Process

Rational Unified Process развивался годами, и в настоящее время он отражает коллективный опыт множества людей и компаний, использующих богатое наследие корпорации Rational Software. Рассмотрим родословную процесса RUP 2000, показанную на рис. 2.3.

Рис. 2.3. Генеалогия Rational Unified Process

Обращаясь к прошлому, видим, что Rational Unified Process (версия 5) является прямым наследником Rational Objectory Process (версия 4). Rational Unified Process включает значительную часть материала из областей проектирования данных, моделирования производства, управления проектом и управления конфигурацией, причем последнее — это следствие объединения с процессом Pure-Atria. Rational Unified Proc-


42 Часть I. Процесс

ess включает элементы метода Real-Time Object-Oriented Method, разработанного создателями метода ObjecTime, приобретенного корпорацией Rational Software в 2000 году. Кроме того, корпорация Rational Software разработала для Rational Unified Process набор инструментов поддержки.

Rational Objectory Process 4.0 — это результат объединения процессов Rational Approach и Objectory Process (версия 3.8), происшедшего после слияния в 1995 году корпорации Rational Software Corporation и компании Objectory AB. От своего предка Objectory процесс унаследовал модель процесса (описывается в главе 3) и основополагающую концепцию прецедента. Со стороны Rational он получил нынешнюю формулировку итеративной разработки и архитектуры. Эта версия также объединила управление требованиями от корпорации Requisite, Inc. и подробный процесс тестирования от корпорации SQA, Inc., компаний, также объединившихся с Rational Software. И наконец, данная версия процесса была первой, в которой использовался недавно созданный язык UML (версия 0.8).

Процесс Objectory Process был создан в Швеции в 1987 году Айваром Джейкобсо-ном (Ivar Jacobson) в результате многолетней работы на шведского производителя средств телекоммуникации Ericsson AB. Этот процесс стал выпускаться компанией Objectory AB, основанной Джейкобсоном. Основанный на концепции использования прецедентов и объектно-ориентированном проектировании, этот процесс быстро получил признание в индустрии программных средств и был принят (полностью или в качестве составной части) множеством компаний по всему миру. А в 1992 году в виде учебника была издана упрощенная версия Objectory Process .

Rational Unified Process — это точный и подробный экземпляр более общего процесса, описанного Айваром Джейкобсоном, Грейди Бучем и Джеймсом Румбахом (James Rumbaugh) в работе The Unified Software Development Process1.

Резюме

Rational Unified Process — это полное описание жизненного цикла разработки
программного обеспечения.

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

М Он обеспечивает управление многими современными технологиями и подходами: объектно-ориентированной технологией и модульной разработкой, моделированием и языком UML, архитектурой и итеративной разработкой и т.д.

Это не "застывший" продукт; наоборот, Rational Unified Process — это "живой",
постоянно эксплуатируемый и непрерывно развивающийся процесс.

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

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

4 Ivar Jacobson et. al. Object-Oriented Software Engineering: A Use-Case-Driven Approach. Reading,
MA: Addison-Wesley, 1992.

5 Ivar Jacobson, Grady Booch and James Rumbaugh. The Unified Software Development Process.
Reading, MA: Addison-Wesley Longman, 1998.


Глава 2. Rational Unified Process 43

  1.  Разрабатывайте итеративно
  2.  Управляйте требованиями
  3.  Пользуйтесь модульными архитектурами
  4.  Используйте визуальное моделирование
  5.  Не забывайте о проверке качества
  6.  Следите за изменениями

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


Глава 3. Статическая структура: описание процесса

В данной главе описывается представление Rational Unified Process. Здесь вводятся ключевые понятия: исполнители, виды деятельности, артефакты и технологические процессы, а также другие элементы, используемые в описании процесса.

Модель Rational Unified Process

В процессе описывается, кто выполняет, что выполняет, как и когда. Rational Unified Process представляется четырьмя базовыми элементами моделирования.

Исполнители: кто

Виды деятельности: как

Артефакты: что

Технологические процессы: когда

Первые три элемента изображены на рис. 3.1, а на рис. 3.5 показан технологический процесс.

Глава 3. Статическая структура: описание процесса 45

Примечание. В RUP 2001 исполнители названы "ролями" для согласования с используемой промышленной терминологией.

Исполнители (в RUP 2001 — роли)

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

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

Приведем несколько примеров исполнителей.

Системный аналитик

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

Разработчик

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

Разработчик тестов

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

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

1 Далее в книге будут часто использоваться фразы наподобие "Разработчик класса X делает нечто", хотя строго нужно писать "Лицо, для класса X действующее как разработчик, делает


46 Часть I. Процесс

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

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

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

Исполнители процесса обычно называются с использованием слова "исполнитель", например Исполнитель: испытатель интеграции. В приложении А перечислены все исполнители, определенные в Rational Unified Process.

Виды деятельности

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

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


Глава 3. Статическая структура: описание процесса 47

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

Согласно объектно-ориентированной терминологии исполнитель — это активный объект, а производимые им виды деятельности — это операции, выполняемые объектом. Приведем несколько примеров видов деятельности.

Планирование итерации. Выполняет Исполнитель: руководитель проекта.

Поиск прецедентов и акторов. Выполняет Исполнитель: системный аналитик.

Рецензирование проекта. Выполняет Исполнитель: рецензент проекта.

Проведение эксплуатационных испытаний. Выполняет Исполнитель: испытатель
производительности.

Виды деятельности обычно называются с использованием слова "вид деятельности", например Вид деятельности: поиск прецедентов и акторов. Обзор всех видов деятельности Rational Unified Process дается в главах с 7 по 15.

Этапы видов деятельности

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

Этапы размышления

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

Этапы произведения

Исполнитель создает или модернизирует некоторые артефакты.

Этапы рецензирования

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

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

  1.  Найти акторов.
  2.  Найти прецеденты.
  3.  Описать способы взаимодействия акторов и прецедентов.
  4.  Сопоставить акторов и прецеденты.
  5.  Представить модель прецедентов на диаграммах прецедентов.
  6.  Разработать отчет об использовании модели прецедентов.
  7.  Оценить результаты.

Поисковая часть вида деятельности (этапы 1-3) требует некоторого размышления; производящая часть (этапы 4-6) включает фиксацию результатов на модели прецедентов; обзорная часть (этап 7) требует от исполнителя оценки результатов в целях определения полноты, устойчивости, доступности или других показателей качества.


48 Часть I. Процесс

Артефакты

Виды деятельности имеют исходные и результирующие артефакты. Артефакт— это "порция" информации, порождаемая, модифицируемая или используемая процессом. Артефакты— это вещественные продукты проекта: объекты, порождаемые или используемые проектом при работе над окончательным продуктом. Исполнителями видов деятельности артефакты используются как исходная информация и являются результатом или выходом этих видов деятельности. Согласно объектно-ориентированной проектной терминологии, где виды деятельности — это операции над активным объектом (исполнителем), артефакты — это параметры данных действий. Артефактами могут быть:

модель, такая как модель прецедентов или модель проектирования;

элемент модели (элемент в рамках модели), такой как класс, прецедент или
подсистема;

документ,  такой  как бизнес-план  или документ архитектуры  программного
обеспечения;

исходный код;

исполняемые программы.

Отметим, что артефакт— это термин, используемый в Rational Unified Process (примеры нескольких основных артефактов Rational Unified Process приведены на рис. 3.3). Другие процессы для обозначения того же понятия используют термины результат работы, рабочий блок и т.п. Отметим также, что комплектующие узлы, поступающие в руки заказчиков и конечных пользователей, — это только подклассы всех артефактов.

Глава 3. Статическая структура: описание процесса 49

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

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

Как правило, артефакты— это не документы. Многие процессы акцентируют внимание на документах, в частности печатных документах. Rational Unified Process не одобряет планомерное создание печатных документов. Самым эффективным и практичным подходом к управлению артефактами проекта является поддержка артефактов в пределах соответствующих инструментальных средств, используемых для создания артефактов и управления ими. При необходимости эти средства позволяют мгновенно создавать нужные документы (снимки процесса).

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

Приведем примеры артефактов.

• Проектная модель, сохраненная в Rational Rose
в План проекта, сохраненный в
Microsoft Project

Дефект, сохраненный в ClearQuest

База данных требований проекта в Requisite Pro

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

За артефакты отвечает один исполнитель; это является развитием того, что за каждую "порцию" информгщии должно отвечать конкретное лицо. Несмотря на то что "владеть" артефактом может только одно лицо, использовать его могут многие люди, которые, при наличии соответствующего разрешения, могут даже модернизировать этот артефакт.

Артефакты называются с использованием слова "артефакт", например Артефакт: архив прецедентов.

Отчеты

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


50 Часть I. Процесс

Множества артефактов

Артефакты Rational Unified Process сгруппированы в пять информационных множеств.

Множество управления

Множество требований

Множество проектирования

Множество реализации

Множество распространения

Множество управления объединяет артефакты, относящиеся к управлению проектом и сфере программного обеспечения.

Артефакты планирования, такие как план разработки программного обеспече
ния (
software development planSDP), бизнес-план, действительный экземпляр
процесса, используемый в проекте (план разработки) и т. д.

Операционные артефакты,  такие как описание версии,  оценка состояния,
документация по распространению и информация о дефектах

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

Документ видения

Требования в форме запросов заинтересованных сторон, модели прецедентов
и дополнительных спецификаций

Модель производства, если она нужна для понимания процессов, поддерживае
мых системой

Множество проектирования содержит описание создаваемой (или созданной) системы в форме:

модели проектирования;

описания архитектуры;

модели тестирования.

Множество реализации включает следующее.

Исходный код и исполняемые программы

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

Множество распространения содержит всю поставляемую информацию.

Материалы по установке

Пользовательскую документацию

Обучающие материалы

Артефакты не являются чем-то завершенным или хотя бы зафиксированным в одной фазе итеративного процесса разработки до перехода к следующей фазе. Напротив, за время жизненного цикла разработки пять информационных множеств эволюционируют, они растут, как показано на рис. 3.4. Все артефакты, определенные в Rational Unified Process для всех технологических процессов, перечислены в приложении Б.

Технологические процессы

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

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

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

основные технологические процессы;

элементы технологических процессов;

планы итераций.

Основные технологические процессы

В Rational Unified Process существует девять основных технологических процессов, которые представляют собой логическое разбиение всех исполнителей и видов деятельности на группы: области интересов или дисциплины (рис. 3.6). Основные технологические процессы делятся на шесть основных технических процессов и три основных процесса поддержки.

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

Техническими процессами являются

Процесс моделирования производства;

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

Процесс анализа и проектирования;

Процесс реализации;

Процесс тестирования;

Процесс распространения. Рис. 3.6. Девять основных технологических процессов

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

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

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

Процесс управления средой.

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

Элементы технологических процессов

Каждый из основных технологических процессов является достаточно объемным. Для расчленения этих процессов в Rational Unified Process используются элементы технологических процессов, выражающие определенные группы тесно связанных действий. Например, виды деятельности, совместно выполняемые или циклически повторяемые; виды деятельности, производимые группой людей, работающих в одной секции; виды деятельности, дающие интересный промежуточный результат. С помощью информационных потоков элементов технологических процессов (артефактов, являющихся исходными или результирующими объектами видов деятельности) показывается, как виды деятельности взаимодействуют посредством различных артефактов.


54 Часть I. Процесс

Планы итераций

Планы итераций— это еще одно средство представления процесса; его описание с акцентом на происходящем при типичной итерации. Планы итераций — это фактически наиболее близкое описание того, с чем будет работать механизм технологического процесса. Планы итераций можно считать реализациями процесса для данной итерации, определяющими виды деятельности, которые будут эффективно выполняться во время итерации, и воспроизводящими их при необходимости. Существует множество способов, с помощью которых можно реализовать процесс. Rational Unified Process содержит описание только нескольких характерных планов итераций. Основной целью их предоставления является учебная, как будет показано на нескольких примерах главы 16.

Дополнительные элементы процесса

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

Директивы

Шаблоны

Инструментальные наставники

Основные понятия

Как показано на рис. 3.7, они служат для улучшения основных элементов.

Глава 3. Статическая структура: описание процесса 55

Директивы

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

Информация, добавляемая к видам деятельности, этапам производства или артефактам, называется директивами. Директивы — это правила, рекомендации или эвристические советы, поддерживающие виды деятельности и этапы. Они описывают правильно сформированные артефакты, акцентируя внимание на их специфических качествах, например на том, что образует хороший прецедент или хороший класс проектирования. Директивы описывают особую технику создания определенных артефактов, преобразования одного артефакта в другой или использования языка UML (Unified Modeling Language — унифицированный язык моделирования). Кроме того, они используются для определения качества артефактов (в форме таблиц контрольных проверок директивы связываются с артефактами) или для рецензирования видов деятельности. Перечислим типы директив.

• Рабочие директивы, дающие практические советы по выполнению видов дея
тельности, особенно групповых видов деятельности.

Рабочие директивы для рецензий

Рабочие директивы для мастерской прецедентов

• Директивы артефактов, связываемые с отдельными артефактами и описываю
щие, как разрабатывать, оценивать и использовать артефакт.

— Директивы моделирования, описывающие правильно сформированные мо
дельные элементы, такие как прецеденты, классы и контрольные задачи

Директивы программирования, которые для языков,  подобных C++ или Ada, описывают правильно сформированные программы

— Директивы пользовательского интерфейса

Директивы по созданию определенных артефактов,  таких как перечень рисков или план итерации

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

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

• Директивы пользовательского интерфейса, такие как описание стиля организа
ции окон, характерного для проекта: цветовая палитра, шрифты, набор пикто-

, грамм и т. п.

• Директивы программирования, такие как описание соглашений относительно
присваивания имен, характерных для проекта


56 Часть I. Процесс

Шаблоны

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

Шаблоны Microsoft Word для документов и некоторых отчетов

Шаблоны SoDA для Microsoft Word или FrameMaker, извлекающие информа
цию из программ, подобных
Rational Rose, RequisitePro или Team Test

Шаблоны Microsoft FrontPage для различных элементов процесса

Шаблоны Microsoft Project для плана проекта

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

Инструментальные наставники

Виды деятельности, этапы производства и связанные с ними директивы дают исполнителю общее руководство. Чтобы сделать следующий шаг, требуются инструментальные наставники, показывающие, как работать со специфическим программным средством. В Rational Unified Process имеются инструментальные наставники, связывающие действия этого процесса с программами наподобие Rational Rose, RequisitePro, ClearCase, ClearQuest и TestStudio. Инструментальные наставники практически полностью инкапсулируют зависимости процесса от набора инструментов, освобождая виды деятельности от инструментальных подробностей. Организация-разработчик может расширить понятие инструментального наставника, после чего он сможет использоваться с другими инструментальными средствами.

Основные понятия

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

Контур процесса

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


Глава 3. Статическая структура: описание процесса 57

Резюме

Модель Rational Unified Process основана на трех основных элементах: испол
нителях, видах деятельности и артефактах.

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

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

Rational Unified Process — это контур процесса, организация которого позво
ляет настроить статическую структуру процесса.


Глава 4

Динамическая структура:                           итеративная разработка

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

Последовательный процесс

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

"Разумный" подход

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

  1.  Полное понимание проблемы, подлежащей решению, ее требований и ограни
    чений. Все.это фиксируется в письменном виде и передается всем заинтересо
    ванным сторонам для подтверждения корректности формулировки поставлен
    ной задачи.
  2.  Выработка решения, удовлетворяющего всем требованиям и ограничениям.
    Это решение тщательно исследуется, а все заинтересованные стороны под
    тверждают то, что данное решение является верным.
  3.  Реализация решения с использованием лучших технологических методов.
  4.  Проверка, удовлетворяет ли реализация сформулированным требованиям.
  5.  Сдача проекта. Задача решена!

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


Глава 4. Динамическая структура: итеративная разработка 59

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

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

Делаются ложные предположения.

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

Не удалось ввести некоторые человеческие факторы.

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


Часть I. Процесс

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

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

Ложное предположение 1: требования неизменны

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

Изменения в пользовательской среде

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

Изменения задачи

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

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

; Авторство высказывания "I'll Know It When I See It" иногда приписывается американскому судье Стюарт)7 Поттеру (Stewart Potter); достоверно известным случаем использования акронима IKIWISI является семинар по архитектуре систем программного обеспечения, прочитанный Барри Боемом (Barry Boehm) в University of Southern California в 1997 году.


Глава 4. Динамическая структура: итеративная разработка 61

Изменения основоположных технологий

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

Изменения рынка

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

Требования нельзя сформулировать достаточно точно и подробно

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

Ложное предположение 2: до начала работы правильный проект можно получить на бумаге

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

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


62 Часть I. Процесс

Риски

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

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

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

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

Увеличение масштаба временной шкалы

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

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

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


Глава 4. Динамическая структура: итеративная разработка 63

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

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

Помещение документации на полки

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

Объемное планирование против временного

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

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


64 Часть I. Процесс

Преодоление сложностей: итерируйте!

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

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

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

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

Как  выбирать то,   что должно  выполняться  при  каждой  итерации?  Какие
требования и какие риски рассматривать?

Как этот подход решает основные проблемы, упоминавшиеся ранее?


Глава 4. Динамическая структура: итеративная разработка 65

На эти и другие вопросы отвечает Rational Unified Process. Некоторые из ответов приводятся и в данной книге, в этой главе и главе 7, "Технологический процесс управления проектом".

Контроль: фазы и вехи

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

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

Рассмотрим четыре фазы итерационного процесса подробнее.

Исследование

Было бы неплохо задать видение конечного продукта и его бизнес-план, а также определить область действия проекта. Фаза исследования завершается вехой цели жизненного цикла (lifecycle objectiveLCO).

Уточнение плана

Планирование необходимых действий и определение требуемых ресурсов; задание свойств и проектирование архитектуры. Фаза уточнения плана завершается вехой архитектуры жизненного цикла (lifecycle architectureLCA).

2 Названия и определения вех идентичны предложенным Барри Боемом в статье Anchoring the Software Process, IEEE Software, July 1996, pp. 73-82.


66 Часть I. Процесс

Построение

Построение продукта и развитие видения, архитектуры и планов, пока продукт — полное видение — не будет готов к предоставлению пользовательскому сообществу. Фаза построения завершается вехой первоначальной работоспособности (initial operational capabilityIOC).

Развертывание

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

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

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

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

Глава 4. Динамическая структура: итеративная разработка 67

Например, для двухлетнего проекта имеем следующее.

2,5-месячная фаза исследования

7-месячная фаза уточнения плана

12-месячная фаза построения

2,5-месячная фаза развертывания

Как это соотносится с итерациями? В каждой фазе развитие идет итеративно, и каждая фаза состоит из одной или нескольких итераций . Общий жизненный цикл приведен на рис. 4.6 .

Смещение акцентов в течение цикла

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

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

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

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

^В редких случаях фаза может вообще не содержать действительных итераций.

  1.  Число итераций в фазах выбрано только с целью иллюстрации. Сколько итераций
    требуется в действительности — показано в главе 7.

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

Рис. 4.7. Важность видов деятельности в отдельном цикле разработки

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

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

Обзор фаз

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

Фаза исследования

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

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

6 Фазы разрабатывались совместно с Уокером Ройсом (Walker Royce), а данный раздел является адаптированным пересказом главы 6 его книги Software Project Management: A Unified Framework Reading, MA: Addison-Wesley Longman, 1998.


Глава 4. Динамическая структура: итеративная разработка 69

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

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

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

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

Оценка рисков (источников непредсказуемости).

В фазе исследования необходимыми являются следующие виды деятельности.

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

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

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

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

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

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

Начальный словарь проекта.

Первоначальный бизнес-план, включающий:

- среду производства;

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

- финансовый прогноз.

Первоначальная оценка риска.

План проекта, демонстрирующий фазы и итерации.

Для коммерческих программных продуктов бизнес-план должен включать набор предположений о проекте и коэффициент окупаемости инвестиций (return on investmentROI), если указанные предположения считать истинными. Например, коэффициент ROI будет равен пяти, если проект будет завершен в течение года; двум — если он будет завершен за два года; и будет отрицательным, если на завершение проекта уйдет свыше двух лет. Эти предположения повторно проверяются в конце фазы уточнения плана, когда область действия и план определяются более точно.


70 Часть I. Процесс

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

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

Первоначальная модель прецедентов (завершенная на 10-20%). В нее входят
прецеденты, создаваемые в процессе работы с начальным циклом разработки.

Модель предметной области, более изощренная, чем словарь (см. главу 9).

Если необходимо — модель производства (см. главу 8).

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

Один или несколько прототипов (см. главу 11).

Веха: цель жизненного цикла

Фаза исследования завершается первой из основных вех: вехой цели жизненного цикла. Фаза исследования оценивается согласно следующим критериям.

Принятие   заинтересованными   сторонами   определения   области   действия,
предлагаемой стоимости и графика работ

Понятность требований, вытекающих из основных прецедентов

Правдоподобие оценок стоимости,  графика работ,  приоритетов,  рисков и
процесса разработки

Глубина и широта разработанного архитектурного прототипа

Отношение действительных расходов к запланированным

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

Фаза уточнения плана

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


Глава 4. Динамическая структура: итеративная разработка 71

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

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

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

Основными целями фазы уточнения плана являются следующие.

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

Создание базовой линии видения.

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

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

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

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

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

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

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


Глава 4. Динамическая структура: итеративная разработка 73

Фаза построения

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

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

В число основных целей фазы построения входят:

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

скорейшее получение приемлемого уровня качества;

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

В фазе построения основными являются следующие виды деятельности.

Управление ресурсами, контроль ресурсов и оптимизация процесса

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

Оценка версий продукта согласно критериям приемлемого видения

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

программный продукт, реализуемый на соответствующей платформе;

руководства пользователя;

описание текущей версии.

Веха: первоначальная работоспособность

Фаза построения завершается третьей основной вехой проекта: вехой первоначальной работоспособности. В этот момент принимается решение, готовы ли к активной


74 Часть I. Процесс

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

Критерии оценки фазы построения включают ответы на следующие вопросы.

Устойчива ли данная версия проекта и готова ли она к распространению в
пользовательской среде?

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

Приемлемо ли  соотношение  между запланированными  и действительными
расходами ресурсов?

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

Фаза развертывания

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

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

Бета-тестирование, позволяющее убедиться, что новая система соответствует
ожиданиям пользователя

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

Перекодирование эксплуатационных баз данных

Подготовка пользователей и персонала поддержки

Передача продукта командам маркетинга, распространения и продаж

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

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


Глава 4. Динамическая структура: итеративная разработка 75

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

Добиться независимости от пользователя

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

Максимально быстро и рентабельно получить окончательную базовую линию
продукта

В фазе развертывания необходимыми являются следующие виды деятельности.

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

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

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

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

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

Веха: выпуск продукта

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

Основные критерии оценки фазы развертывания включают ответы на следующие вопросы.

Удовлетворены ли пользователи?

Остается ли приемлемым соотношение между запланированными и действи
тельными расходами ресурсов?


76 Часть I. Процесс

Особенности итеративного подхода

По сравнению с традиционным водопадным процессом, итеративный подход имеет следующие преимущества.

Последствия от реализации рисков смягчаются быстрее.

Проще управлять изменениями.

Выше уровень повторного использования.

Команда, работающая над проектом, может обучаться в процессе.

Высокое качество проекта.

Смягчение последствий от реализации риска

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

Если проекту по некоторым причинам суждено завершиться крахом, то пусть он "провалится" как можно быстрее, пока еще не Eiero не затрачены значительные усилия, время и деньги. Не стоит слишком долго закрывать на это глаза; нужно противостоять рискам. Среди прочих рисков, таких как создание не того продукта, существует еще две категории, последствия от реализации которых итеративный процесс позволяет рано смягчить.

Интеграционные риски

Архитектурные риски

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

Интеграция в Rational Unified Process — это не совсем "большой взрыв" в конце, а скорее постепенная сборка элементов. Такой итеративный подход — это процесс практически непрерывной интеграции. То, что раньше составляло длительный этап (и занимало до 40% работ в конце проекта), теперь разбито на 6-9 меньших составляющих, в каждую из которых требуется объединить уже значительно меньшее число компонентов.

Адаптация к изменениям

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

Изменения требований

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


Глава 4. Динамическая структура: итеративная разработка 77

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

Тактические изменения

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

Технологические изменения

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

Обучение "по ходу дела"

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

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

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

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


78 Часть I. Процесс

Более высокое общее качество

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

Резюме

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

Итеративный   процесс   разбивает   цикл   разработки   на   последовательность
итераций. Каждая итерация подобна "мини-водопаду" и включает следующие
виды деятельности: управление требованиями, проектирование, реализацию и
оценку.

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

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


Глава 5

        Процесс, основанный на

     архитектуре

 В главе дается определение архитектуры и объясняется, почему она играет ведущую роль в Rational Unified Process

Важность моделей

Значительная часть Rational Unified Process основана на моделировании. Модели помогают понимать и очерчивать как проблему, так и ее решение. Модель — это упрощение действительности, помогающее управлять большой, сложной системой, не поддающейся пониманию во всей своей полноте. От того, какие модели и технологии будут выбраны, очень сильно зависит, как будет воспринята проблема и как будет сформировано решение. Запомните, модель — это не действительность ("карта— это не территория" ), хотя лучшие модели весьма точно отображают эту действительность .

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

Архитектура

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

Предположим, вам требуется так описать систему, чтобы разработчики, программисты, пользователи и руководители смогли бы:

понять, что делает система;

понять, как работает система;

1 "The map is not the territory" — это основополагающий принцип книги С. Хаякавы
(
S. I. Hayakawa) Language in Thought and Action, впервые изданной в 1939 в издательстве Наг-
court-Brace, Нью-Йорк.

2 Grady Booch, James Rumbaugh and Ivar Jacobson.  The Unified Modeling Language Users
Guide.
Reading, MA: Addison-Wesley Longman, 1999.


80 Часть I. Процесс

поработать с частью системы;

расширить систему;

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

Предположим теперь, что решение этой задачи необходимо представить не более чем на 60 страницах. Результатом этой работы будет то, что называется описанием архитектуры системы. Как когда-то сказал мне один человек: "Архитектура — это когда удалить больше ничего нельзя, а то, что осталось, все еще делает систему понимаемой и объясняет, как она работает".

Важность архитектуры

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

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

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

Не существует общепринятого способа представления архитектуры.

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

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

Впрочем, по мере развития и роста системы, адаптируемой к новым требованиям, новые элементы добавляются разнообразными (иногда несколько странными) способами, и для описания системы уже недостаточно простого увеличения масштаба. Внедрение новых технологий требует полной перестройки системы. Другими словами, системы не очень "упруго" реагируют на изменения. Более того, у разработчиков отсутствуют интеллектуальные инструментальные средства, позволяющие осмыслить части системы. Неудивительно, что плохая архитектура (плюс непродуманный процесс) часто является причиной провала проекта. Отсутствие архитектуры или использование некачественной архитектуры — это основной технический риск для программных проектов.

Архитектура сегодня

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


Глава 5. Процесс, основанный на архитектуре 81

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

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

Понимание цели

Почему важна архитектура? Какие выгоды можно извлечь из нее? Как ею пользоваться?

Архитектурное представление

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

Архитектурный процесс

Как создается и утверждается архитектура, удовлетворяющая требованиям проекта? Кто это делает? Какие артефакты и параметры качества сопровождают эту задачу?

Некоторые ответы на эти вопросы дает Rational Unified Process. Но для начала давайте все же определимся, что мы понимаем под архитектурой программного обеспечения или, точнее, архитектурой преимущественно программной системы.

Определение архитектуры

Архитектуру можно определить по-разному. В Rational Unified Process используется

следующее определение .

Архитектура объединяет значимые решения относительно

организации программной системы;

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

объединения этих элементов в постепенно укрупняющиеся подсистемы;

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

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

определение развилось из определения, предложенного несколько лет назад Мери Шо (Mary Shaw) и Девидом Гарланом (David Garlan) из Carnegie-Mellon University. См. их работу Software Architecture - Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice-Hall, 1996.


82 Часть I. Процесс

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

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

Архитектура связана со структурой и организацией, но этим она не ограничивается. Кроме того, она имеет отношение к поведению: что произойдет на стыках, соединениях и границах интерфейсов.

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

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

Представление архитектуры

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

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

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

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

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

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

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

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

Чтобы различные заинтересованные стороны могли сообщаться и размышлять об архитектуре, требуется понятное им архитектурное представление. Архитектура и ее представление — это не совсем одно и то же: при выборе представления не учитываются некоторые наиболее нематериальные (или тонкие) аспекты системы.

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


Глава 5. Процесс, основанный на архитектуре 83

Множественные представления

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

Планы этажей

Вертикальные проекции

Планы электромонтажа кабельной проводки

Чертежи водопроводов, систем центрального отопления и вентиляции

Вид здания на фоне пейзажа (эскизы)

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

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

Отображению логической организации системы

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

Отображению аспектов параллельной работы

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

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

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

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

Какие элементы будут фиксироваться и представляться и какие между ними
существуют взаимоотношения

Какие   организационные   принципы   используются   для   структурирования
представления

Каким образом элементы данного представления связаны с элементами других
представлений

Каким способом лучше всего создать представление

4 Данный многомерный подход соответствует будущему стандарту IEEE Recommended Practice for Architectural Description, См. проект стандарта Draft 5.2 IEEE P1471, November 1999.


84 Часть I. Процесс

Модель представления архитектуры "4 + 1"

Как показано на рис. 5.1, Rational Unified Process предлагает использовать пятимерный подход5. Эти пять измерений (или представлений) кратко описываются ниже.

Рис. 5,1. Модель "4 +Г

Логическое представление

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

Примеры: рейс, схема рейса, авиалиния, аэропорт и воздушное пространство.

Реализационное представление

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

Примеры: исходный код для класса рейса и библиотека кодов для базы данных воздушного пространства.

Процедурное представление

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

s Philippe Kruchten, The 4 + 1 View of Architecture. IEEE Software, 12(6) Nov. 1995, pp. 45-50.


86 Часть I. Процесс

Таблица 5.1. Соотношения между моделями и представлениями

Модель Архитектурное представление

Модель проектирования Логическое представление

Модель проектирования* Процедурное представление

Модель реализации Реализационное представление

Модель распространения Представление распространения

Модель прецедентов Прецедентное представление

*или модель процесса для сложной системы

Архитектура — это не только чертеж

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

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

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

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

Как уже говорилось, в Rational Unified Process определено два основных артефакта, связанных с архитектурой.

Описание   архитектуры   программного   обеспечения    (software   architecture
descriptionSAD), охватывающее архитектурные представления, которые от
носятся к проекту.

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

На основе этих двух ключевых артефактов создается еще три.

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

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

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

В Rational Unified Process за архитектуру отвечает Исполнитель: архитектор. Впрочем, с архитектурой связаны не только архитекторы. В определении и реализации


Глава 5. Процесс, основанный на архитектуре 87

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

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

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

Испытатели тестируют архитектурный прототип на предмет эффективности и
устойчивости.

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

Основные виды деятельности относятся к архитектурному проектированию и описаны в технологическом процессе анализа и проектирования (см. главу 10), но при этом они переходят и в технологические процессы управления требованиями, реализации и управления проектом.

Цель архитектуры

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

Интеллектуальный контроль

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

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

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

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


88 Часть I. Процесс

Повторное использование

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

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

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

Основа для .разработки

Архитектура предоставляет основу для управления проектом.

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

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

Модульная разработка

Rational Unified Process поддерживает модульную разработку (component-based developmentCBD), представляющую собой создание и распространение преимущественно программных систем, собранных из компонентов, а также разработку и сборку таких компонентов.

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

Определейие компонента должно быть достаточно широким, чтобы охватывать как традиционные компоненты (такие, как COM/DCOM, CORBA и JavaBeans), так и альтернативные (Web-страницы, таблицы баз данных и исполняемые компоненты, использующие частные связи). В то же время определение не должно быть настолько широким, чтобы включать все возможные артефакты хорошо структурированной архитектуры.


Глава 5. Процесс, основанный на архитектуре 89

Определение компонента

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

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

Существует несколько видов компонентов.

• • Компоненты времени выполнения

К этой категории относятся поставляемые, устанавливаемые и запускаемые объекты, такие как исполняемые файлы, процессы и динамически подключаемые библиотеки (dynamic link librariesDLLs). Они активны только во время выполнения на используемой платформе.

Разработанные компоненты, видимые с точки зрения организациифазработчика

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

Коммерческие компоненты

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

Другие архитектурные концепции

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

Архитектурный стиль

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

Примеры архитектурных стилей: "труба и фильтр", "клиент/сервер" и стиль, управляемый событиями.


90 Часть I. Процесс

Архитектурный механизм

Архитектурный механизм— это класс, группа классов или шаблон, обеспечивающий общее решение общей проблемы. Этот механизм используется для предоставления "жизни" (т.е. линии поведения) другим классам. Механизмы находятся на нижних и средних уровнях архитектуры; они аналогичны стандартным системам центрального отопления и канализации, доступным архитектору здания, и позволяют быстро реализовать желаемые решения.

Примеры архитектурных механизмов: система управления базами данных (database management systemDBMS, СУБД), система трансляции событий и сервер транзакций.

Архитектурный шаблон

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

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

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

Примеры архитектурных шаблонов: Model-View-Controller (MVC) и Object Request Broker (ORB).

Резюме

Системная   архитектура,    используемая   в   Rational   Unified   Process, —   это
основной артефакт для осмысления, построения, развития разрабатываемой
системы и управления ею.

Архитектура— это сложное понятие, которое стоит представлять посредством
множественных скоординированных архитектурных представлений.

Архитектурное представление — это абстракция модели, которая акцентирует
внимание на ее структуре и необходимых элементах.

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

6 См. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerland and Michae Stahl. Pattern-Oriented Architecture: A System of Patterns. New York: John Wiley and Sons, 1996.


Глава 6

Процесс, управляемый прецедентами

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

Определения

Значительная часть Rational Unified Process акцентирована на моделировании. Как объяснялось в главе 5, модели помогают понять и очертить как проблему, которую мы пытаемся решить, так и само ее решение. Выбор моделей и способов их выражения существенно влияет на наше восприятие проблемы и то, как мы пытаемся отыскать ее решение.

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

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

; Понятие прецедента ввел Айвар Джейкобсон (Ivar Jacobson) в работе Object-Oriented Software Engineering: A Use-Case-Driven Approach. Reading, MA: Addison-Wesley, 1992. См. также более новую книгу: Ivar Jacobson, Grady Booch and James Rumbaugh. The Unified Software Development Process. Reading, MA: Addison-Wesley Longman, 1999.


92 Часть I. Процесс

Прецедент и актор

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

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

Актор—это некто или нечто вне системы, взаимодействующее с этой системой.

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

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

Действия

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

Последовательность действий

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

Последовательность действий, выполняемых системой

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

Видимый значимый результат

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

Отдельный актор

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


Глава 6. Процесс, управляемый прецедентами 93

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

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

Пример прецедентов и акторов

Рассмотрим следующий пример. Клиент банка может использовать банкомат (automated teller machineATM) для снятия денег, их перевода или для проверки состояния счета. Все эти возможности (рис. 6.1) можно представить набором прецедентов.

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

Поток событий

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

Пример потока событий

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

  1.  Прецедент начинается, когда Клиент вставляет карточку в банкомат. Система
    считывает и проверяет информацию с карточки.
  2.  Система  запрашивает   персональный   идентификационный   номер   (personal
    identification numberPIN) Клиента. Клиент вводит свой PIN-код. Система
    проверяет правильность введенной информации.
  3.  


94 Часть I. Процесс

  1.  Система запрашивает, какую операцию желает произвести Клиент. Клиент вы
    бирает "Снятие денег".
  2.  Система запрашивает о снимаемой сумме. Клиент вводит сумму.
  3.  Система запрашивает о типе счета. Клиент выбирает тип счета (чековый счет,
    депозит, кредитный счет).
  4.  Система связывается с сетью банкомата для подтверждения номера счета, PIN-
    кода и наличия на счете требуемой суммы.
  5.  Система "спрашивает" Клиента, требуется ли квитанция. Данный этап выпол
    няется только при наличии бумаги для печати квитанции.
  6.  Система  указывает   Клиенту  вынуть   карточку.   Клиент  вынимает   карточку.
    (Данное требование продиктовано соображениями безопасности и должно га
    рантировать, что клиенты не будут оставлять свои карточки в аппарате).
  7.  Система выдает запрошенную сумму.

10.  Система печатает квитанцию (если ее заказывали). Прецедент завершен.

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

Выбранный путь зависит от следующего.

Ввода со стороны актора

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

Внутреннего состояния системы

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

Блокировки по времени или ошибок

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

Сценарии

Выделять каждый возможный альтернативный поток в отдельный прецедент нежелательно; такие потоки лучше объединять с другими родственными потоками событий прецедента. Результатом такого объединения является класс прецедентов. Экземпляром класса прецедентов является отдельный поток событий или отдельный путь через прецедент. Другим названием экземпляра класса прецедентов является сценарий. Обычно достаточно (и не так громоздко) называть класс прецедентов просто прецедентом, а экземпляр прецедента— сценарием.


96 Часть I. Процесс

Определение прецедентов

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

Для упрощения рассуждений забудем на время о множественных операциях. Итак, является ли прецедентом введение карточки, ввод PIN-кода и получение его подтверждения? Значима для вас эта последовательность действий? Предположим, что вы подошли к банкомату, вставили карточку и ввели PIN-код, после чего автомат сообщил, что вы правильно ввели код, и вернул вашу карточку. Будете ли вы счастливы? Разумеется, нет! Банкомат используется для получения денег, перевода средств и т.д. Вот это именно то, что имеет значение, т.е. это и есть прецеденты — снятие денег, их перевод или внесение на счет, а также наведение справок о состоянии счета. Каждый прецедент включает завершенный диалог, начинающийся введением банковской карточки для выбора типа операции и заканчивающийся получением квитанции и возвратом карточки.

Прецеденты возникают тогда, когда внимание обращается на значимые результаты, которые система дает актору, и когда объединяются последовательности действий, которые система предпринимает для получения этих значимых результатов. Прецедент можно также рассматривать как средство достижения некоторой "цели", которую система должна дать актору. Крайне полезное обсуждение данного метода можно найти в статье Элистара Кокберна (Alistair Cockburn) .

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

Развитие прецедентов

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

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

- Alistar Cockburn. Structuring Use Cases with Goals. Journal of Object-Oriented Programming, Sept. 1997 и Nov. 1997; см. также http://niembers.aol.com/acocbum/papers/usecases.htm.


Глава 6. Процесс, управляемый прецедентами 97

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

Организация прецедентов

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

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

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

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

Включение

Расширение

Обобщение/конкретизация

Некоторые прецеденты могут включать обычный текст потока событий, организованный как прецедент. Это подобно разложению программы на подпрограммы. В рассматриваемом примере с банкоматом и прецедент Снятие денег, и прецедент Проверка баланса включают действие "Пользователь вводит PIN-код". В одной и той же модели не обязательно два-три раза выражать поток событий, связанный с введением PIN-кода. Вместо этого в оба прецедента можно включить прецедент Аутентификация пользователя (рис. 6.2).

3 Начиная с версии 1.3 языка UML отношение использование между прецедентами разбито на включение и обобщение/конкретизация; поэтому для предотвращения путаницы отношение использование мы не употребляем..

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

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

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


Глава 6. Процесс, управляемый прецедентами 99

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

Прецеденты в процессе

Rational Unified Process— это процесс, управляемый прецедентами. Это значит, что прецеденты, определенные для системы, составляют основу всего процесса разработки (рис. 6.3).

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

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

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


100 Часть I. Процесс

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

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

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

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

Резюме

Прецеденты — это средство выражения требований, относящихся к функцио
нальным возможностям системы.

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

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

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

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

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

Описанные экземпляры класса прецедентов называются сценариями.

Прецеденты управляют множественными видами деятельности Rational Unified
Process.

Созданием и утверждением модели проектирования

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

Планированием итераций

— Созданием руководств пользователя
- Распространением системы

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


Глава 7

Технологический процесс управления   проектом

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

Цель

Управление программным проектом — это искусство балансирования между конкурирующими целями, а также управление риском и преодоление ограничений. Результатом процесса должен быть продукт, удовлетворяющий потребностям заказчиков (тех, кто оплачивает счета) и конечных пользователей. О значительной сложности этой задачи свидетельствует, например, то, что 100%-ным успехом может похвастаться лишь очень малое число проектов. Цель технологического процесса управления требованиями, как он определен в Rational Unified Process, — максимально возможное облегчение поставленной задачи путем обеспечения руководства проектом. Этот процесс не является рецептом успеха; это скорее рекомендуемый подход к управлению проектом, заметно повышающий шансы на сдачу успешного программного обеспечения. Существует три основные цели процесса управления проектом.

Создать контур для управления преимущественно программными проектами

Обеспечить практическое руководство по вопросам планирования, кадрового
обеспечения, реализации проекта и наблюдения за проектом

Создать контур для управления риском

Следует отметить, что данный технологический процесс, как он определен в Rational Unified Process, не охватывает все аспекты управления проектом1. Например, не освещаются следующие вопросы.

• Управление персоналом: наем, обучение, тренировка

1 Управление проектом подробно рассматривается в книге: Walker Royce. Software Project Management: A Unified Framework. Reading, MA: Addison-Wesley Longman, 1998.


104 Часть II. Технологические процессы

Управление ресурсами: определение, распределение

Управление контрактами с поставщиками и заказчиками

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

Планирование жизненного цикла итеративного проекта в целом и планирова
ние отдельных итераций

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

Наблюдение за прогрессом итеративного проекта и метрики

Планирование итеративного проекта

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

Сколько требуется итераций?

Насколько они продолжительны?

• Как определить содержание и цели итерации?
м   Как отследить прогресс итерации?

К целям планирования проекта относятся следующие.

• Распределение задач и обязанностей в команде

• Наблюдение  за  отношением  имеющегося  прогресса  к  плану и  выявление
потенциальных проблем по мере развития проекта

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

Два уровня планов

Известны многочисленные претенциозные, но обреченные на провал попытки подробнейшего планирования крупных программных проектов (от начала и до конца) — как планируется строительство небоскреба. Виды деятельности и задачи сотрудников точно определялись и заблаговременно расписывались по дням (и это при общем объеме работ, рассчитанном на месяцы или годы!). Автор лично видел эти графики Гантта и логические сети видов деятельности, которые полностью покрывали стены нескольких комнат и приемных. Чтобы такие планы были реалистичными, нужно четко представлять, что должно быть сделано; должны быть стабильными требования и архитектура; кроме того, должна существовать подобная система, из которой можно позаимствовать подробную структуру декомпозиции работ (work breakdown structureWBS).

С другой стороны, как можно запланировать программирование сотрудником Джо модуля GGART на 37-ю неделю, если заранее неизвестно даже о существовании этого модуля?

Данный подход оправдал себя в промышленности, где декомпозиция работ более ИЛИ менее стандартна и устойчива, а распределение заданий предопределено, по-


Глава 7. Технологический процесс управления проектом 105

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

При использовании итеративного процесса разработку рекомендуется организовывать, опираясь на планы двух типов:

крупнозернистый план фаз;

набор мелкозернистых планов: планы итераций.
План фаз

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

Даты основных вех

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

Вехи первоначальной работоспособности (конец фазы построения; выпущена первая бета-версия)

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

Схема кадрового обеспечения: какие ресурсы нужны в процессе развития проекта

Даты второстепенных вех:, конец каждой итерации и ее основная цель (если она
известна)

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

План итерации

План итерации— это мелкозернистый план, который должен создаваться для каждой итерации. Как правило, в каждый момент времени "активны" два плана итерации.

Текущий план итерации (план текущей итерации), используемый для наблюде
ния за прогрессом проекта

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

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

Представить план итерации можно как окно, перемещающееся по плану фаз и действующее как лупа (рис. 7.1).

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

Понятие риска

Как сказал Тим Листер (Tim Lister): "Все надежные проекты уже сделаны" . Традиционно в процессе разработки программного обеспечения вначале рассматриваются известные аспекты разработки. Точно описать, запланировать, распределить или прорецензировать можно только то, что известно точно. Управление риском относится уже к области неизвестных (и ненадежных) аспектов разработки. В настоящее время многие организации работают в режиме "отрицания риска": оценка и планирование производятся исходя из предположения, что все переменные известны, вся работа — механическая, а персонал — взаимозаменяем.

2 Software Risk Management Is Software Project Management. Seminar at Software productivity Center, Vancouver, В. С., Canada, May 1996.


Глава 7. Технологический процесс управления проектом 107

Что такое риск?

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

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

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

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

Прямой: риск, который можно в значительной степени контролировать

Косвенный: риск, не поддающийся (или слабо поддающийся) контролю со сто
роны проекта

Кроме того, можно ввести два важных параметра.

Вероятность появления

Воздействие на проект (серьезность)

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

Стратегии: как справиться с рисками

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

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

Уклонение от риска.  Реорганизация  проекта,  при  которой  он уже  не будет
подвержен воздействию риска.

Перевод риска. Такая реорганизация проекта, при которой риску подвергается
кто-то другой или что-то другое (заказчик, поставщик, банк или другой элемент
проекта).

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

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

5 Barry W. Boehm. Software Risk Management: Principles and Practice. IEEE Software, Jan. 1991, pp. 32-41.


108 Часть II. Технологические процессы

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

Определить запасной план. Установить действия, предпринимаемые при превращении потенциального риска в актуальную проблему; другими словами, создать "план Б", план действий во внештатной ситуации.

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

Понятие метрики

Зачем проводятся измерения? В основном для того, чтобы контролировать проект, а следовательно, управлять им. Измерения проводятся для определения того, насколько близко или далеко текущее состояние проекта от поставленной цели. Это "расстояние" выражается через завершенность проекта, его качество и соответствие требованиям. Измерения нужны и для того, чтобы на основе полученного опыта можно было лучше спланировать работы, определить стоимость и качество нового проекта. И наконец, измерения выполняются для оценки эффектов изменений и определения того, как со временем можно улучшить эффективность процесса (см. главу 17)

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

Информационные цели

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

Цели изменений или свершений

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

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

Отследить отношение прогресса к плану

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

Улучшить производительность

Повысить предсказуемость

Увеличить повторное использование

4 К. Pulford, A. Kuntzmann-Combelles and S. Shirlaw. A Quantitative Approach to Software Management- The ami Handbook. Reading, MA: Addison-Wesley, 1995.


Глава 7. Технологический процесс управления проектом 109

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

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

Определить степень удовлетворенности заказчика

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

Подтвердить повышение степени удовлетворенности

Цель улучшить производительность будет включать следующие подцели.

Измерить объем произведенных работ

Определить прогресс

Вычислить производительность нескольких итераций проекта

Сравнить результаты

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

Опрос пользователей

Определение количества (серьезности) вызовов по "горячей линии" поддерж
ки пользователей

Что такое метрика

Существует два типа метрик.

  1.  Метрика— это измеряемый параметр некоторой категории. Например, объем
    работ в ходе проекта является мерой (т.е. метрикой) размера проекта. Для вы
    числения этой метрики нужно просуммировать объемы всех заказов, сделан
    ных в ходе проекта.
  2.  Примитивная метрика— это элемент необработанных данных, используемый
    для вычисления метрики. В предыдущем примере примитивными метриками
    являются заказы. Как правило, примитивная метрика— это метрика, которая
    находится в базе данных, но отдельно от этой базы данных не рассматривается.

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

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


110 Часть II. Технологические процессы

Исполнители и артефакты

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

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

•   План разработки программного обеспечения (software development planSDP), включающий следующие артефакты:

план принятия продукта;

план управления риском (и перечень рисков);

план разрешения проблем;

план измерений;


Глава 7. Технологический процесс управления проектом 111

Бизнес-план

Планы итераций (по одному на каждую итерацию)

Оценка итерации

Оценка (периодическая) состояния

Распределение работ

База данных измерений проекта

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

План управления конфигурацией разрабатывается Исполнителем: управляющий
конфигурацией
(см. главу 13)

План разработки (план процесса, используемого в проекте) разрабатывается
Исполнителем: технолог (см. главы 14 и 17)

Технологический процесс

Рассмотрим рис. 7.3, на котором в форме диаграммы видов деятельности представлена одна итерация технологического процесса управления проектом. Каждый вид деятельности, например открытие нового проекта, — это элемент процесса Rational Unified Process. И наоборот, каждый элемент процесса Rational Unified Process состоит из одного или нескольких видов деятельности. Стоит отметить, что некоторые элементы технологического процесса зависят от времени. Например, открытие нового проекта происходит всего лишь один раз, в начале проекта, а фаза закрытия имеет место только при завершении последней итерации каждой фазы.

Элементы технологического процесса

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

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

Оценка области действия проекта и риска

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

Создание плана разработки программного обеспечения

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

Разработка плана измерений

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

Разработка плана принятия продукта

Разработка плана разрешения проблем

Определение структуры проекта и обеспечение проекта кадрами

Определение процессов наблюдения и контроля


Глава 7. Технологический процесс управления проектом 113

Планирование фаз и итераций

Составление плана разработки программного обеспечения

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

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

План следующей итерации

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

Наблюдение и контроль над проектом

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

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

Непрерывное наблюдение за проектом, включающее наблюдение за активны
ми рисками и объективную оценку прогресса и качества

ш Регулярное предоставление экспертному отделу проекта (группе, которой подотчетен руководитель проекта) отчета о состоянии проекта, выполненного в форме оценки состояния

• Рассмотрение вопросов и проблем по мере их возникновения, а также снятие
их согласно с планом разрешения проблем


114 Часть II. Технологические процессы

Управление итерацией

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

Завершение фазы

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

Решены ли все основные проблемы предыдущей итерации.

Известно ли состояние всех основных артефактов (определяется при ревизии
конфигурации).

Рассмотрены   ли   все   проблемы    распространения    (например,   установка,
развертывание, подготовка).

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

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

Завершение проекта

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

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

Создание плана фаз

Чтобы начать создание плана фаз, нужно, по меньшей мере, оценить "размер горы". Например, нужно рассмотреть следующие вопросы.

Насколько велика эта гора (т.е. общий объем работ)?

Когда нужно добраться до вершины (даты финального выпуска)?


Глава 7. Технологический процесс управления проектом 115

После ответа на эти вопросы можно, исходя из даты выпуска, определить и ориентировочные даты "стоянок" — основных вех.

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

Практика (да и здравый смысл тоже) снова и снова убеждает нас в том, что ускорить выполнение запаздывающего проекта за счет привлечения дополнительного персонала нельзя. Классический пример: "Если женщине требуется девять месяцев на формирование ребенка, то почему девять женщин не могут сделать это за месяц?" Как писал Фред Брукс (Fred Brooks): "Привлечение к запаздывающему проекту дополнительных кадров делает его еще более запаздывающим". Вообще, в таких случаях можно порекомендовать использование модели затрат, такой как модель СОСОМО (constructive cost model— конструктивная модель затрат), позволяющей проверить справедливость выбранного соотношения между объемом работ, фактической их продолжительностью и уровнем кадрового обеспечения.

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

Резиновый профиль

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

Средний размер проекта и средний объем работ

Незначительное число рисков и новшеств

Находится в первоначальном цикле разработки

Не имеет предопределенной архитектуры


116 Часть II. Технологические процессы

Для удобства этот же профиль представлен и в виде таблицы (табл. 7.1). Таблица 7.1. Распределение времени и объема работ по фазам

Фазы Время работы Объем работы

Исследование 10% 5%

Уточнение плана 30% 20%

Построение 50% 65%

Развертывание 10% 10%

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

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

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

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

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

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

• В любом случае — проверяйте, не слишком ли много персонала обслуживает проект.

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

Продолжительность итерации

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


Глава 7. Технологический процесс управления проектом 117

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

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

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

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

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

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

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

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

Таблица 7.2. Длительность итерации, приемлемая для многих итеративных проектов

Количество строк кода Чис*го сотрудников Длительность итерации

5 000 4 2 недели

20000 10 1 месяц

100 000 40 3 месяца

1 000 000 150 8 месяцев

5 При исследовании этого Джо Мараско (Joe Marasko) обратил внимание, что связь продолжительности итерации D (в неделях) с размером проекта S (в тысячах строк кода) выражается формулой д = 1$ , но вы можете относиться к этому как угодно.


118 Часть II. Технологические процессы

Количество итераций

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

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

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

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

Усиления   организации-разработчика   за  счет   инструментальных   средств   и
улучшенного процесса.

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

Поэтому в фазе исследования итерации либо не выполняются вовсе, либо выполняется лишь одна.

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

Итак, в фазе уточнения плана требуется от одной до трех итераций.

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

Таким образом, в этой фазе нужны одна-три итерации.

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

Итак, в фазе развертывания нужно провести одну-две итерации.

Окончательно получаем следующее. Существует три уровня проведения полного цикла разработки [И, У, П, Р].

Низкий:         три итерации [О, 1, 1, 1] Типичный:   шесть итераций [1, 2, 2, 1] Высокий:      девять итераций [1, 3, 3, 2]


Глава 7. Технологический процесс управления проектом 119

Результат можно подать в общем виде, сказав, что "стандартный" проект имеет 6 ± 3 итерации. Это эмпирическое правило мы будем называть "шесть плюс-минус три".

Создание плана итерации

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

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

План итерации подробно описывает, что должно произойти за время итерации. Он распределяет виды деятельности исполнителям и назначает сотрудников на роль исполнителей. (Напомним, что термин исполнитель используется нами в несколько особом смысле; см. главу 3.) Для обработки подробностей плана полезно применять инструментальные средства, такие как Microsoft Project; в частности, это удобно при определении зависимостей и распределении заданий сотрудникам.

Для создания плана итерации следует пройти четыре этапа.

  1.  Определить объективные критерии успеха итерации. Эти критерии будут ис
    пользоваться в конце итерации (при ее оценке) и позволят определить, успеш
    ной или неудачной была итерация.
  2.  Определить конкретные, измеримые артефакты, которые требуется разработать
    или модернизировать, а также виды деятельности, необходимые для этого.
  3.  Взять за основу типичную итерационную декомпозицию работ и подогнать ее
    под действительные действия, которые должны производиться.
  4.  Использовать смету при определении продолжительности и объема работ для каж
    дого вида деятельности, удерживая все значения в пределах бюджета ресурсов.

А теперь, как и обещали ранее, рассмотрим изменения схемы итерации в зависимости от фазы.

Итерация в фазе уточнения плана

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

Риск

Охват

Критичность

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


120 Часть II. Технологические процессы

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

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

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

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

  1.  Если это— риск интеграции, такой как "база данных D корректно работает с
    операционной системой
    Y", то в артефакт следует выделить сценарий, содер
    жащий описание некоторого, хотя бы даже весьма скромного взаимодействия с
    базой данных.
  2.  Если это— риск выполнения, такой как "требуется много времени на вычисле
    ние траектории артефакта", то в артефакт следует выделить сценарий, содер
    жащий это вычисление, хотя бы даже для наиболее очевидного случая.

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

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

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

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

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


Глава 7. Технологический процесс управления проектом 121

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

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

  1.  Создать одну абонентскую запись на рабочей станции клиента; запись должна храниться
    в базе данных на сервере, включать диалог с пользователем, но не включать все поля; пред
    полагается, что выявление ошибок не выполняется.
    Данный сценарий объединяет
    критические функции с рисками интеграции (база данных и связное программ
    ное обеспечение) и проблемы интеграции (работа с двумя различными платфор
    мами). Также он заставляет разработчиков познакомиться с новым средством
    проектирования графического интерфейса пользователя. И последнее, данный
    сценарий приводит к созданию прототипа, который можно продемонстрировать
    конечным пользователям в целях установления обратной связи.
  2.  Обеспечить возможность поддержки до 20 000 абонентов; время доступа к отдельному
    абоненту не должно превышать 200 миллисекунд.
    Данный сценарий связан с ключе
    выми аспектами производительности (объемом информации и временем от
    клика), несоответствие которым может оказать значительное влияние на архи
    тектуру.
  3.  Аннулировать изменение адреса абонента.  В данном сценарии рассматривается
    свойство, заставляющее подумать о проектировании всех функций отмены
    действий. Это, в свою очередь, может привести к необходимости установления
    связи с конечными пользователями для определения целесообразности отмены
    других действий.
  4.  Завершить все прецеденты, имеющие отношение к управлению системой поставок. На
    помним, что одной из целей фазы уточнения плана является завершение сбора
    требований.

Итерация в фазе построения

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

Приведем примеры целей итераций для фазы построения.

  1.  Реализовать все варианты прохождения вызова, в том числе ошибочные. Набор свя
    занных функций. Одна из них могла быть реализована в фазе уточнения плана
    и впоследствии могла использоваться как прототип.
  2.  Закончить разработку всех функций телефонного оператора, за исключением относя
    щихся к ночным службам.
    Еще один набор функций.
  3.  Добиться выполнения 5 000 операций в час с помощью схемы из двух компьютеров. Це
    лью может быть увеличение производительности, полученной в ходе предыду
    щей итерации (например, всего 2 357 операций/час).
  4.  


122 Часть II. Технологические процессы

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

Итерация в фазе развертывания

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

Приведем примеры целей итераций фазы развертывания.

  1.  Решить все первостепенные проблемы,  обнаруженные при проведении бета-тестиро
    вания.
    Данная цель относится к улучшению качества и может быть связана с за
    воеванием рынка.
  2.  Устранить все аварийные отказы времени запуска, вызванные несогласованными дан
    ными.
    Еще одна цель, относящаяся к качеству продукта.
  3.  Добиться выполнения 2 000 операций в минуту. Настройка производительности и
    проведение некоторой оптимизации: изменение структуры данных, кэширова
    ние и использование более изящных алгоритмов.
  4.  Снизить число различных диалоговых окон на 30%. Повышение удобства использо
    вания путем снижения нагрузки на зрение.
  5.  Создать немецкую и японскую версии. Из-за нехватки времени и для снижения числа
    доработок бета-версия была выпущена только для англоязычных пользователей.

Подробнее о работе при итерации

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

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

Какие классы должны быть переработаны?

Какие подсистемы затрагиваются или создаются?

Какие интерфейсы могут требовать модификации?

Какие документы следует обновить?

Следующим этапом является определение видов деятельности Rational Unified Proc- ! ess, которые будут задействованы в итерации, и внесение их в план проекта. Некоторые | действия производятся один раз за итерацию (например, создание плана итерации), другие же должны  выполняться для  каждого  класса,  прецедента или  подсистемы j


Глава 7. Технологический процесс управления проектом 123

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

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

Резюме

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

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

Основным фактором, направляющим планирование, является риск.

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

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

Критерии, определяющие масштаб итераций, меняются в зависимости от фазы
проекта.


Глава 8

Технологический процесс моделирования производства

совместно с Марией Эриксон (Maria Ericsson)

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

Цель

Цели моделирования производства состоят в следующем.

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

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

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

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

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

Зачем моделировать производство

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


Глава 8. Технологический процесс моделирования производства 125

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

Это становится очевиднее при подготовке организаций к вступлению в мир е-бизнеса. Кстати, а что обозначает это модное словечко е-бизнес? Как и в случае прочих широко употребляемых жаргонных терминов, значение этого слова до некоторой степени зависит от того, кто его использует. Согласно определению, которое будем использовать мы, е-бизнес (или электронный бизнес) связан с созданием систем (иногда называемых коммерческими или производственными инструментальными средствами), автоматизирующих производственные процессы. В некотором смысле, производственные инструментальные средства— это и есть бизнес; способ определения отличий между вами и конкурентами. В качестве примера таких инструментальных средств можно привести средства электронной коммерции, автоматизирующие процесс сбыта.

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

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

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

Для бизнеса

Потребительские, приложения, позволяющие заказывать товары через Internet,
например электронные книжные магазины

Коммерческие, автоматизируют цепь поставок между компаниями

Для потребителя

Коммерческие, предоставляют для потребителей (иногда пассивных) информацию,
например, посредством распространения информационных бюллетеней

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


Сценарии моделирования производства

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

Сценарий 1. Организационная схема

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

Сценарий 2. Моделирование предметной области

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

Сценарий 3. Одно производство для нескольких систем

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


128 Часть II. Технологические процессы

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

Сценарий 4. Общая модель производства

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

Сценарий 5. Новое производство

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

Сценарий 6. Реорганизация

Если организация решает полностью пересмотреть свой способ ведения дел (с помо-1 щью исходных текстов создать новую структурную схему и алгоритм работы произвол-1 ственного процесса), то моделирование производства — это зачастую один из нескольких самостоятельных процессов. Реорганизация, как правило, выполняется в несколько этапов: представление в основных чертах нового предприятия, "переконструирование" существующего процесса, создание нового процесса и его установка.

Несколько лет назад термин реструктуризация производственного процесса (business-process reengineeringBPR) был весьма популярным и означал "революционный подход к реорганизации"".

Исполнители и артефакты

Как все сказанное выше выражается в Rational Unified Process через исполнителей, артефакты, виды деятельности и технологические процессы? Рассмотрим рис. 8.1, на котором показаны основные исполнители и артефакты процесса моделирования! производства.

В процессе моделирования производства задействованы следующие основные ис-1 полнители.

•   Аналитик процесса производства возглавляет и координирует моделирование [ производственных прецедентов. Для  этого он очерчивает и  ограничивает моделируемую   организацию.   Аналитик,   например,   устанавливает   видение нового производства, определяет, какие имеются производственные акторы и прецеденты и как они взаимодействуют.

2 См., например, популярную книгу Michael Hammer and James Champy. Reengineering thi Corporation: A Manifesto for Business Revolution. New York: Harper Business, 1993.


128 Часть II. Технологические процессы

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

Сценарий 4. Общая модель производства

При разработке приложения, которое будет использоваться несколькими организация- | ми (например, приложение организации продаж или составления счетов), полезно бу- I дет усреднить способы ведения организациями дел. Это поможет избежать слишком I больших требований к системе. Если же усреднение невозможно, то работы по модели- > рованию производства помогут уяснить, чем будет отличаться использование приложе- \ ния в разных организациях, а также помогут понять, как использовать эту информацию I и как распределить приоритеты функциональных возможностей приложения.

Сценарий 5. Новое производство

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

Сценарий 6. Реорганизация

Если организация решает полностью пересмотреть свой способ ведения дел (с помо-1 щью исходных текстов создать новую структурную схему и алгоритм работы производственного процесса), то моделирование производства— это зачастую один из нескольких самостоятельных процессов. Реорганизация, как правило, выполняется в несколько этапов: представление в основных чертах нового предприятия, "переконструирование" 1 существующего процесса, создание нового процесса и его установка.

Несколько лет назад термин реструктуризация производственного процесса (business-1 process reengineeringBPR) был весьма популярным и означал "революционный | подход к реорганизации"".

Исполнители и артефакты

Как все сказанное выше выражается в Rational Unified Process через исполнителей, артефакты, виды деятельности и технологические процессы? Рассмотрим рис. 8.1, на котором показаны основные исполнители и артефакты процесса моделирования производства.

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

•   Аналитик  процесса производства возглавляет и координирует моделирование производственных прецедентов.  Для  этого он очерчивает и  ограничивает моделируемую   организацию.   Аналитик,   например,   устанавливает   видение' нового производства, определяет, какие имеются производственные акторы и прецеденты и как они взаимодействуют.

2 См., например, популярную книгу Michael Hammer and James Champy. Reengineering the Corporation: A Manifesto for Business Revolution. New York: Harper Business, 1993.


Глава 8. Технологический процесс моделирования производства 129

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

Кроме того, в технологическом процессе участвуют следующие исполнители.

Заинтересованные стороны, организовывающие общий надзор и предоставляю
щие информацию.

Рщетент производства, представляющий рецензию на результирующие артефакты.

В процессе моделирования производства создаются ключевые артефакты.

Документ видения производства: определяет цели моделирования производства.

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

Модель  объектов  производства:   объектная   модель,   описывающая   реализацию
производственных прецедентов.

Кроме того, создаются следующие артефакты.

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

Правила производства: определение политики или условий, которые должны
удовлетворяться.

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

Словарь производства: определяет важные термины, используемые в производстве.

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

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


130 Часть II. Технологические процессы

Технологический процесс

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

Глава 8. Технологический процесс моделирования производства 131

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

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

Если решено, что полномасштабные модели производства не нужны, а дос
таточно модели предметной области (сценарий 2), то выбирается соответст
вующий путь через технологический процесс  (рис. 8.2).  В
Rational Unified
Process модель предметной области является подмножеством модели объектов
производства, включающим категории производства этой модели.

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

Если моделирование производства выполняется в целях улучшения или реор
ганизации существующего производства (сценарии 3, 4 и 6), то моделировать
нужно как текущее производство, так и проектируемое.

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

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

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

132 Часть II. Технологические процессы