Автор: Кролл П. Крачтен Ф.
Теги: программирование программное обеспечение переводная литература издательство кудиц образ rational unified process разработка программного обеспечения
ISBN: 0-321-16609-4
Год: 2004
Текст
RATIONAL
Unified Process
- это ЛЕГКО
Руководство no RUP для практиков
ПЕР КРОЛЛ
ФИЛИПП КРАЧТЕН
RUP’
Вступительное слово Грэйди Буч
КУДИЦ-ОБРАЗ
OBJECT TECHNOLOGY
SERIES EDITORS
SERIES
The Rational Unified
Process Made Easy
A PRACTITIONER'S GUIDE TO THE RUP
Per Kroll
Philippe Kruchten
▼▼ Addison-Wesley
Boston • San Francisco • New York • Toronto • Montreal
London • Munich • Paris • Madrid
Capetown • Sydney • Tokio • Singapore • Mexico City
11 ер Кролл
<1>илипп Крачтен
Rational
Unified Process
- это ЛЕГКО
Руководство по RUP для практиков
Перевод с английского
КУДИЦ-ОБРАЗ
Москва • 2004
I.ЬК 32.973-02 . , . . г
I ।><>iiji 1 Крачтен Ф.
national Unified Process - это легко. Руководство по RUP. Пер. с англ. - М.: КУДИЦ-
<>1»1’АЗ, 2004.-432 с.
1 lacц> приходится слышать, что RUP - это одна из наиболее тяжеловесных, формализованных методологий
I'.iip.iooiKii программного обеспечения, требующая создания множества «бесполезных» документов и моделей.
Mi ,к.|\ |см, RUP можно вполне успешно применять даже в проекте, выполняемом безо всяких формальностей
|| Шим программистом за одну неделю. По крайней мере, так считают авторы этой книги Пер Кролл и Филипп
I рачки. Л к их мнению стоит прислушаться, ведь они - практики, активно участвовавшие во внедрении RUP во
mi ю .кос I вс ор гаиизаций.
' > г а книга не заменит последовательного изложения RUP, зато она содержит множество конкретных сове-
HHI и рекомендаций. В книге приведено сравнение RUP с другими методологиями, включая гак называемые
। IHHUIC (agile) методы (ХР и другие). Детально описаны фазы разработки. Но наибольший интерес, видимо,
>ч.| «туг разделы, посвященные настройке RUP на требования конкретного проекта или организации и описа-
нию ролей, исполняемых участниками разработки. Как выбрать из RUP именно то, что позволит ускорить
111.И1ОЛНСНИС проекта, снизить трудоемкоегь и при этом обеспечить достаточно высокое качество разработки?
I..и. определить необходимое количество итерации? Как организовать работу большой и распределенной ко-
манды'.’ Как вообще организовать внедрение RUP в большой организации? На какие моменты стоит обратить
внимание при освоении RUP специалистам разных специальностей'’ Ответы на вес эти и многие другие вонро-
i ы содержатся в книге.
Книга представляет интерес для всех, кто уже использует RUP или собирается использовать его в будущем.
ISBN 0-321-16609-4
ISBN 5-9579-0019-2
Пер Кролл, Филипп Крачтен
Rational Unified Process - это легко. Руководство по RUP
Учебно-справочное издание
Переводе англ. С. М. Лунин
Научный редактор: А. В. Закис
"ИД КУДИЦ-ОБРАЗ"
Тел.: 333-82-11; E-mail: ok@kudits.ru; http://books.kudits.ru
Подписано в печать 17.03.2004.
Формат 70x90/16. Бум. газ. Печать офс
Усл. печ. л. 3 1,6. Тираж 3000. Зака, 863
/ Л Л 3 с
ISBN 0-321-16609-4
ISBN 5-9579-0019-2 О "ИД КУДИЦ-ОЫ’АЗ", 2004
Аиторизованный перевод с англоязычного издания, озаглавленио1О*ГНЕ RAT IONAL UNIFIED PROCESS MADE EASY'
A PRACTITIONER'S GUIDE TO RUP, I" Edition, ISBN 0-32I-I6609-4, by KROLL, PER: KRUTCHTEN, PHILIPPE,
онубликовашии о Pearson Education, Inc, под изда1ельской маркой Addison Wesley Professional, Copyright © 2003 by Pearson Ednca-
lion, Inc.
All lights reserved. No part of this book may be reproduced or transmitted in any forms or by any means, electronic or mechanical, including
photocopying, recording or by any information storage retrieval system, without permission tiom Pearson Education Inc.
Все права защищены. Никакая часть этой книги не может воспроизводиться или распространяться в любой форме или любыми
। рсдствами. электронными или механическими, включая фотографирование, магнигную запись или информационно-поисковые
> ис1емы хранения информации без разрешения от Pearson Education, Inc.
1’\сское издание опубликовано издательством КУДИЦ-ОБРЛЗ, С' 2004.
Содержание
Список иллюстраций............................................................19
Список таблиц.................................................................23
вступительное слово...........................................................24
"11редисловие...................................................................26
Благодарности.................................................................31
Часть I. Введение в Rational Unified Process.........................32
Глава 1. Введение в Rational Unified Process..............................33
Что такое Rational Unified Process?...........................................33
RUP-подход....................................................................34
Базовые принципы подхода RUP................................................34
RUP и итеративная разработка ...............................................36
RUP - четко определенная технология программной инженерии ....................39
Динамическая структура Rational Unified Process.............................40
Статическая структура Rational Unified Process ....................................... 43
RUP - настраиваемый технологический продукт...................................49
Средства конфигурирования и создания собственных процессов .................50
Средства доставки ..........................................................52
Кто использует продукт RUP .................................................54
Заключение ...................................................................55
I лава 2. «Дух RUP» - путь к успеху.............................................57
11ачинайте вести наступление на главные риски раньше
и ведите его непрерывно ......................................................58
Заключение ....................................................................................................... 60
Обеспечьте выполнение требований заказчиков ..................................61
Заключение .................................................................62
6 СОДЕРЖАНИЕ
< 'концентрируйтесь на исполняемой программе ..................63
Заключение ..................................................64
I !риспосабликайтесь к изменениям с самого начала проекта ... 65
Заключение ..................................................68
Закладывайте основу исполнимой архитектуры как можно раньше ....68
Заключение ..................................................69
Стройте систему из компонентов .............................. 70
Заключение ..................................................72
Работайте вместе как одна команда .............................72
Заключение ..................................................75
Сделайте качество образом жизни, а не запоздалой идеей.........75
Заключение ..................................................77
Резюме....................................................... 78
Глава 3. Сравнение технологий: RUP, гибкие методы
и тяжеловесные правительственные стандарты..................... 79
Как мы можем сравнивать процессы? .............................80
Гибкая разработка: низкая формализованность, итеративные подходы ....80
SEI СММ, SEI СММ1.1SO/1EC, DOD-STD, M1L-STD: тенденция
к большей формализованности для большей предсказуемости .......83
SEI СММ: средство оценки процессов ..........................84
SEIСММГ. Средство оценки процессов...........................85
ISO/IEC 15504: Средство оценки процессов ....................86
DOS-STD и MIL-STD: высокоформализованные процессы ...........86
RUP: альтернативный подход с адаптируемым уровнем
формализованности ......................................... 88
Насколько все должно быть итеративным? ...................... 89
Сколько понадобится формальностей?........................... 90
। и/п 1ЧЛНИЬ
7
какой вид конфигурации Rl Т соответствует нуждам вашего процесса? ... 91
Проект «Деймос»: команда из одного человека....................91
Проект «Ганимед»: небольшой проект с плотным графиком..........92
Проект «Марс»: проект среднего размера без опыта итеративной
разработки ....................................................92
Проект «Юпитер»: большой распределенный проект ...............93
Заключение ................................................... 94
lyunta 4. RUP для команды из одного человека: проект «Деймос».....96
< >дииочный программный проект: проект «Деймос» ................97
Первоначальная идея (вечер субботы) .......................... 97
Предложение (утро понедельника) .............................. 98
Концепция .................................................... 98
План......................................................... 100
Список рисков................................................. 102
Экономическое обоснование .................................... 102
Архитектура................................................... 103
Обязательства .................................................103
Концепция (Этап второй) ...................................... 104
План (Этап второй) .......................................... 104
(’писок рисков (Этап второй) ................................. 104
Экономическое обоснование (Этап второй) ...................... 105
Работаем (вечер понедельника) .................................106
11однажмем (вторник) ........................................ 107
больше прогресс, больше изменений (среда) .....................108
11очти закончил (четверг) .....................................109
бета-версия и выпуск ..........................................109
Заключение ....................................................110
в
Содержание
Часть II. Жизненный цикл проекта
it Rational Unified Process.....................................112
I .пава 5. Через четыре фазы................................113
I лавное недопонимание .......................................113
I In каких фиксированных рабочих процессов ...............115
11икаких «замороженных» артефактов ...........................116
Типы проектов.................................................117
I лава 6. Фаза Начало...........................................119
11ели фазы Начало .......................................... 120
Фаза Начало и итерации .......................................121
1(ель 1. Понять, что создавать................................122
Создайте документ «Концепция»............................122
Создайте широкое, но неглубокое описание системы ............123
Устраивайте семинары или «мозговые штурмы» ..............124
Подробно опишите ключевые акторы и прецеденты использования .126
11ель 2. Выяснить ключевые функции системы....................128
Цель 3. Выявить хотя бы одно возможное решение................130
Цель 4. Оцепить стоимость, сроки и риски, связанные с проектом .... 133
Цель 5. Решить, какому процессу следовать и какие средства
использовать .................................................134
Рецензирование проекта. Веха целей жизненного цикла ..........136
Заключение ...................................................136
Глава 7. Фаза Проектирование....................................138
Цели фазы Проектирование .....................................139
Фаза Проектирование и итерации ...............................141
Первая итерация Проектирования ..............................142
Вторая итерация Проектирования ..............................142
Цель 1. Более глубоко понять требования.......................143
Содержание
9
Цель 2. Спроектировать, реализовать и проверить базовую
архитектуру .................................................145
Архитектура: определение подсистем, ключевых компонентов
и их интерфейсов........................................... 147
Для формирования архитектуры используйте архитектурно-значимые
прецеденты использования................................... 148
Проектируйте критичные прецеденты использования ........... 150
Объединяйте и собирайте готовые классы в пакеты ........... 151
Обеспечьте архитектурный охват............................. 154
Спроектируйте базу данных.................................. 154
Создайте схему параллельного выполнения, процессов, потоков
и физического распределения ............................... 154
Определите архитектурные механизмы ........................ 155
Реализуйте критические сценарии............................ 156
Интегрируйте компоненты ................................... 156
Тестируйте критические сценарии............................ 156
Что осталось сделать?...................................... 157
Цель 3. Снизить существенные риски и дать более точную
оценку сроков и стоимости ...................................159
Планируйте проект и оценивайте затраты .................... 159
Цель 4. Уточнить прецедент разработки и установить среду
разработки...................................................160
Рецензирование проекта. Веха архитектуры жизненного цикла.....161
Заключение ..................................................162
I лава 8. Фаза Построение......................................163
I {ели фазы Построение ......................................165
Фаза Построение и ее итерации.............................. 166
I {ель 1. Снизить стоимость разработки и добиться определенного
параллелизма ................................................168
Организация вокруг архитектуры............................. 169
Управление конфигурациями ................................. 171
10
Содержание
Укрепляйте архитектуру......................................172
Обеспечьте непрерывный прогресс ............................173
Цель 2. Разработать итеративным методом окончательный продукт,
готовый к представлению пользовательскому сообществу .........175
Опишите оставшиеся Прецеденты использования и прочие требования ...175
Завершайте проектирование ..................................176
Спроектируйте базу данных...................................177
Реализуйте код и проводите .модульное тестирование .........177
Проводите интеграцию и системное тестирование ..............178
Раннее внедрение и обратная связь...........................179
Подготовка к выпуску бета-версии ...........................180
Подготовка к окончательному развертыванию...................181
Рецензирование проекта. Веха начальной функциональной
готовности ................................................. 183
Заключение ................................................. 183
Глава 9. Фаза Внедрение..........................................184
Цели фазы Внедрение......................................... 185
Итерации внедрения и циклы разработки .........................186
Фаза Внедрение и итерации...................................186
Внедрение и циклы разработки................................188
Цель 1. Провести бета-тестирование для проверки соответс твия
программы ожиданиям пользователей ............................190
Фиксирование, анализ и реализация запросов на изменения ....190
Тестирование в фазе Внедрение ..............................191
Выпуск исправлений (patches) и дополнительные бета-релизы ..192
Показатели завершения фазы Внедрение .......................192
Цель 2. Научить пользователей и обслуживающий персонал
работать самостоятельно................................. 194
Цель 3. Подготовить площадку (сайт) для развертывания
и конвертировать рабочие базы данных .........................194
Содержание
11
I |,ель 4. Подготовить упаковку, тиражирование, маркетинговые
материалы, выпуск в дистрибуцию и продажу .................195
Упаковка, спецификация материалов и промышленное производство .... 195
Маркетинговые материалы.................................. 196
Цель 5. Достичь соглашения между заинтересованными лицами
в том, что развертывание завершено ........................196
Приемочное тестирование продукта ........................ 196
Цель 6. Повысить производительность при выполнении будущих
" проектов на основе приобретенного опыта....................197
Рецензирование проекта. Веха готового продукта ............198
Заключение ................................................198
Часть III. Внедрение Rational Unified Process................200
Глава 10. Конфигурирование, реализация и модификация
Rational Unified Process.....................................201
Конфигурирование RUP ......................................202
Создание Конфигурации процесса RUP .......................202
Создание Представлений процесса ..........................204
Модификация шаблонов в RUP ...............................206
Реализация RUP для проекта................................206
Прецедент разработки в RUP ...............................207
Web-сайт проекта..........................................210
Альтернативы созданию Прецедента разработки...............211
Модификация RUP ...........................................212
Rational Process Workbench и Process Engineering Process..213
Создание Тонких Плагинов RUP с помощью RUP Organizer......214
Создание Структурных Плагинов RUP с помощью RUP Modeler и RUP
Organizer.................................................214
Заключение .......................................... 218
12
Содержание
I лава 11. Внедрение Rational Unified Process................219
Применение RUP в проекте ..................................220
Предварительная оценка ...................................221
Планирование .............................................223
Выполнение................................................226
Оценка результатов .......................................228
Применение RUP в малых проектах...........................228
Внедрение RUP в крупных организациях.......................230
Пилотные проекты .........................................234
Проекты по разработке программного обеспечения............233
Типичная программа для умеренных изменений ................236
Типичная программа для крупных изменений...................238
Агрессивная программа для крупных изменений................240
Заключение ................................................243
Глава 12. Планирование итеративного проекта..................244
Мотивировка................................................244
Ключевые концепции ........................................245
Цикл......................................................245
Фазы......................................................246
Итерация..................................................246
Выпуск...................................................244)
Ограничение времени ......................................246
Общие и детальные планы: планы проекта и планы итераций ...247
План проекта .............................................247
План итерации.............................................248
Создание плана проекта ....................................249
Определение количества итерацгш ..........................253
Продолжительность итераций ...............................255
Цели итерации ............................................255
Кадровое обеспечение проекта..............................256
Содержание
13
Планирование итерации .......................................256
Начало и Проектирование ...................................257
Построение и Внедрение ....................................258
Определение задач .........................................258
Оценка ......................................................259
Техника итеративной оценки: широкополосная модификация
дельфийского метода .........................................260
Оптимизация плана проекта....................................261
Перекрывающиеся итерации...................................262
Параллельные итерации .....................................262
Заключение ..................................................262
I лава 13 Распространенные ошибки при внедрении
и использовании RUP, и как их избежать.........................263
Ошибки при внедрении RUP.....................................263
Внедрение слишком многого из того, что есть в RUP .........264
Внедрение всего сразу, не постепенно.......................266
Отсутствие планирования при внедрении RUP..................269
Отсутствие связи между совершенствованием процесса
и экономическими результатами .............................270
Излишне детальная и слишком ранняя настройка RUP ..........271
Пустословие ...............................................271
Ошибки при управлении итеративной разработкой ...............272
Функциональная, специализированная организация.............273
Отсутствие корректировки ожиданий заинтересованных
лиц или использование старой схемы заключения контракта ...274
Слишком большое число разработчиков в начале работы
над проектом ..............................................275
Разрешение сначала легких проблем..........................277
Расширенная первая итерация................................277
Использование перекрывающихся итераций ....................278
Слишком много изменений на поздних этапах проекта .........279
14
Содержание
< )шибки в анализе, архитектуре, проектировании и тестировании ....280
Создание слишком большого числа прецедентов использования .28I
Аналитический паралич .....................................282
Включение в требования проектных решений ..................283
Отсутствие утверждения требований заинтересованными лицами 283
Подход «это сделано не у нас» ............................284
Завершение фазы Проектирование до достижения стабильного
состояния архитектуры ....................................285
Акцент на инспектировании, а не на исполняемой программе ..287
Заключение ..................................................288
Часть IV. Руководство по Rational Unified Process
для различных ролей...........................................289
Глава 14. Руководство по RUP для менеджера проекта..........290
Миссия менеджера проекта....................................290
Сложная роль..............................................291
Один человек или команда? .................................292
Управление проектом .........................................293
Границы дисциплины «Управление проектом» в RUP............294
План разработки программного обеспечения ..................294
Итеративная разработка....................................296
Риски.....................................................296
Метрики ..................................................297
Задачи менеджера проекта.................................... 297
Начало нового проекта.....................................297
Создание Плана разработки программного обеспечения ........298
Запуск и завершение фаз и итераций ........................298
Слежение за проектом .....................................299
Найдите свой путь в RUP ....................................299
Заключение ..................................................300
Содержание
15
Ресурсы для менеджера проекта................................301
Дополнительная литература...................................301
Ресурсы WEB.................................................302
Учебные ресурсы.............................................302
Глава 15. Руководство по RUP для аналитика.....................303
Миссия аналитика ............................................303
С чего начинать?.............................................305
Поймите, как должен работать бизнес .........................305
11оймите желания заинтересованных сторон ....................308
Создайте Концепцию ..........................................309
Формулировка проблемы.......................................310
Список свойств..............................................310
Разработка модели прецедентов использования и глоссария......312
Широкое, но неглубокое описание требований .................313
Подробное описание акторов и прецедентов использования .....316
11ример: спецификация прецедента использования
для записи на курсы .........................................319
Уточнение моделей ...........................................319
Разработка прототипов пользовательского интерфейса..........321
Разработка раскадровок, или прототипов прецедентов использования . 322
Фиксирование нефункциональных требований ...................323
Обновление и уточнение требований............................324
Обеспечить выпуск и тестирование требований..................325
Роль аналитика в Rational Unified Process....................325
Ресурсы для аналитика .......................................326
Дополнительная литература.........................._........326
Образовательные ресурсы.....................................326
Глава 16. Руководство по RUP для архитектора...................327
Миссия архитектора...........................................327
На все руки мастер .........................................328
16
Содержание
Один человек или команда? .................................329
Центральная фигура общения ................................329
Архитектура.................................................330
Определение архитектуры....................................330
Модели и представления.....................................331
Описание архитектуры программы.............................333
Прототип исполняемой архитектуры ..........................333
Архитектурные механизмы ...................................334
Дополнительная архитектура.................................334
Развивающая роль ...........................................335
Что делают архитекторы? ....................................336
Концепция..................................................336
Ритм ......................................................337
Предвосхищение.............................................337
Партнерство ...............................................337
Упрощение..................................................338
Задачи архитектора в RUP ...................................338
Работа с требованиями и управление проектом ...............339
Совершенствование архитектуры..............................340
Поддержание архитектурной целостности .....................342
Роль архитектора в RUP .....................................343
Найдите свой путь в RUP ....................................344
Ресурсы для архитектора.....................................345
Дополнительная литература..................................345
Полезные Web-сайты ........................................346
Глава 17. Руководство по RUP для разработчика.................347
Миссия разработчика.........................................347
Общий обзор задач разработчика..............................349
Понять требования и проектные ограничения ..................350
Содержание
17
Спроектировать, реализовать и протестировать прецеденты
использования и компоненты ...................................351
Проектирование реализаций прецедентов использования и компонентов.352
Реализация прецедентов использования и компонентов..........359
Тестирование при разработке ................................360
Проектирование, реализация и тестирование необходимых
баз данных....................................................363
Часто осуществлять интеграцию своего приложения
с работой других разработчиков................................364
Рабочие пространства Управления конфигурациями..............365
Планирование интеграции ....................................365
Создание выпуска ...........................................366
Лучшие практические методы разработчика ....................367
Тесты вперед................................................368
Переработка кода и проектирование ..........................368
Использование шаблонов, архитектурных механизмов
и других повторно используемых решений......................369
Используйте простые решения ................................369
Парное программирование ....................................370
Роль разработчика в Рациональном унифицированном процессе...370
Ресурсы для разработчиков ....................................371
Рекомендуемая литература....................................371
Рекомендуемые учебные курсы ................................372
I лава 18. Руководство по RUP для тестировщика..................373
Миссия тестировщика.........................................373
Концепция качества продукта в RUP ..........................374
Понятия о «достаточно хорошем» .............................375
Цена качества...............................................376
А не поможет ли количественная оценка? .....................377
Соответствие стандартам ...,...,............. ,,...........378
18
Содержание
Что такое тестирование? ....................................379
Философия тестирования в RUP ...............................382
Миссия ...................................................383
Тестовые циклы ...........................................384
Дисциплина Тестирование в RUP ..............................385
Роли, связанные с тестированием в RUP.....................385
Главные артефакты тестирования ...........................385
Задачи тестировщика.......................................388
Определение миссии тестирования ..........................390
Проверка подхода к тестированию ..........................391
Проверка стабильности выпуска («тест на герметичность») ..391
Тестирование и оценка ....................................392
Достижение приемлемого результата миссии .................392
Совершенствование средств и методов тестирования .........393
Прочие задачи, связанные с тестированием..................393
Заключение .................................................394
Ресурсы для тестировщиков ..................................394
Дополнительная литература.................................394
Учебные курсы ............................................395
Глоссарий....................................................396
Литература...................................................400
Список ИЛЛЮСТРАЦИЙ
Рис. 1.1. Итеративная разработка в RUP...........................37
Рис. 1.2. Два измерения RUP......................................40
Рис. 1.3. Вехи фаз жизненного цикла в RUP .......................42
Рис. 1.4. Роли, задачи и артефакты...............................44
Рис. 1.5. Рабочий процесс дисциплины Требования (Requirements ) .47
-Рис. 1.6. Добавление шаблонов, инструкций по использованию
инструментальных средств и Руководств............................48
Рис. 1.7. Технологическая база RUP ..............................49
Рис. 1.8. Компонентная архитектура продукта RUP .................51
Рис. 1.9. MyRUP предоставляет персонализированные Представления.53
Рис. 1.10. Контекстнозависимая расширенная помощь в RUP..........55
Рис. 2.1. Кривые снижения рисков для каскадных и интеративных
разработок.......................................................58
Рис. 2.2. Как Прецеденты использования соотносятся
с другими моделями программной инженерии.........................62
Рис. 2.3. Рассматривайте RUP как «шведский стол» из лучших
практических методов.............................................65
Рис. 2.4. Стоимость внесения изменений изменяется со стадиями
жизненного цикла ................................................66
Рис. 2.5. Архитектура системы ...................................69
Рис. 2.6. Архитектура с функциональной декомпозицией.............71
Рис. 2.7. Архитектура на основе компонентов......................71
Рис. 2.8. Организация команд вокруг архитектуры..................74
Рис. 2.9. Тестирование начинается рано и расширяется
г каждой последующей итерацией...................................76
Рис. 3.1. Карта для сравнения процессов..........................81
Рис. 3.2. Гибкие процессы на карте процессов ...................83
Рис. 3.3. SEI СММ и SEI CMMI на карте процессов ................86
Рис. 3.4. Различные военные стандарты разработки программного
обеспечения на карте процессов...................................87
Рис. 3.5.Конфигурации RUP на карте процессов.....................88
20
Список ИЛЛЮСТРАЦИЙ
Рис. 3.6. Примеры проектов на карте процессов ..............93
Рис. 4.1. Создание концепции................................99
Рис. 4.2. План.............................................100
Рис. 4.3. Оценка риска.....................................102
Рис. 4.4. Примерный набросок архитектуры...................103
Рис. 4.5. Модифицированный план............................105
Рис. 4.6. Оценка риска. Этап второй .......................105
Рис. 4.7. Изображение интерфейса программы ................106
Рис. 4.8. Снимок экрана с готовым интерфейсом программы ...107
Рис. 5.1. Главные вехи.....................................115
Рис. 6.1. Фаза Начало......................................119
Рис. 6.2. Общий обзор системы: типы пользователей
и их прецеденты использования..............................125
Рис. 6.3. Три варианта архитектуры клиент/сервер...........131
Рис. 7.1. Фаза Проектирование ..................................139
Рис. 7.2. Один из возможных видов статической структуры системы.146
Рис. 7.3. Архитектурно-значимые прецеденты использования
формируют архитектуру .....................................149
Рис. 7.4. Пример диаграммы последовательностей..................152
Рис. 7.5.Группирование классов должно локализовать
влияние изменений..........................................152
Рис. 7.6. Архитектурный охват..............................153
Рис. 7.7. Архитектурные механизмы .........................155
Рис. 8.1.Фаза Построение...................................163
Рис. 8.2. Распределение работ по фазам RUP ................165
Рис. 8.3. Организация вокруг архитектуры снижает сложность
общения....................................................170
Рис. 8.4. Инкрементное создание выпусков облегчает
создание выпусков большой системы .........................173
Рис. 8.5. Эволюция компонентов во времени .................178
Рис. 9.1. Фаза Внедрение...................................184
Рис. 9.2. Число итераций во Внедрении .....................187
Рис. 9.3. Циклы разработки.................................189
Рис. 9.4. Анализ тенденции.................................193
Список ИЛЛЮСТРАЦИЙ
21
Рис. 10.1. RUP Builder создает Конфигурации процесса RUP.........204
Рис. 10.2. Представления процесса в браузере MyRUP ..........205
Рис. 10.3. Прецедент разработки - артефакты и формальности.......208
Рис. 10.4. Прецедент разработки - роли .................. 209
Рис. 10.5. Web-сайт проекта в Rational ProjectConsole............211
Рис. 10.6. UP Organizer позволяет создавать Тонкие Плагины ..215
Рис. 10.7. RUP Modeler ......................................216
Рис. 11.1. Внедрение дисциплин «Требование»,
«Анализ и проектирование» и «Управление проектом»............224
Рис. 11.2. Внедрение RUP и инструментов.................... 225
Рис. 11.3. Типичный подход к реализации умеренных изменений......237
Рис. 11.4. Типичный подход к внесению крупных изменений..........239
Рис. 11.5. Агрессивный подход к реализации RUP
и соответствующих инструментов............................. 241
Рис. 12.1. Типичное развитие во времени первоначального цикла
разработки...................................................245
Рис. 12.2. План проекта и план итерации .....................250
Рис. 12.3. Типичное распределение ресурсов в цикле разработки....251
Рис. 12.4. Пример схемы распределения людских ресурсов по фазам
жизненного цикла проекта. Затраты на каждую фазу значительно
варьируются от проекта к проекту ............................257
Рис. 13.1. Функциональные команды имеют присущие им
коммуникационные барьеры.....................................274
Рис. 13.2. Разделение работ по проекту на несколько предложений .275
Рис. 13.3. В начале проекта число разработчиков нужно ограничить. ..276
Рис. 13.4. Сходные длины итераций помогают установить
в проекте четкий ритм ..................................... 278
Рис. 13.5. Большое перекрытие итераций...........................279
Рис. 13.6. Доля изменений интерфейсов показывает, когда можно
завершать фазу Проектирование.............................. 287
Рис. 15.1.Участие аналитика в жизненном цикле RUP............304
Рис. 15.2. Модель бизнес-прецедентов использования для
производственной фирмы..................................... 307
22
Список ИЛЛЮСТРАЦИЙ
Рис. 15.3. Модель бизнес-прецедентов использования для
производственной фирмы ..................................... 307
’не. 15.4. Общий обзор системы: акторы и прецеденты использования.314
’не. 15.5.Структура потоков событий ........................ 318
’не. 16.1. Создание архитектуры ............................ 332
’не. 16.2. 4+1 Представление Архитектуры .....................333
’ис. 16.3. Обзор задач архитектора............................339
’не. 17.1. Роль разработчика в RUP............................349
’нс. 17.2. Пример представления задействованных классов ......355
'нс. 17.3. Пример диаграммы сотрудничества....................356
'нс. 17.4. Пример диаграммы последовательностей...............358
'нс. 17.5. Анализ времени выполнения может выявить «узкие места»
11 роизводительности...................................... 362
Рис. 18.1. Общий рабочий процесс тестирования ................389
Список ТАБЛИЦ
Состояние проекта в начале фазы Построения и после всех ее итераций.167
Использование инструментов для решения крупных проблем разработки... 230
Четыре фазы проекта по совершенствованию процесса и инструментов....232
( ' шпень итеративности в разных проектах.........................254
11остепенное совершенствование по всем фундаментальным направлениям. 268
Вступительное слово
Любая команда разработчиков программного обеспечения, намеренно или ней
следует определенной технологии. В небольших командах, состоящих из одного,
двух или горстки разработчиков, такая технология, как правило, достаточно лег
ковесна. Создается очень небольшое число документов (если они создаются во
обще), анализ и проектирование имеют место, но часто являются неформальны-
ми и кратковременными, а исходный код продукта служит тем центром притяже-
ния, вокруг которого вращается вся прочая деятельность, входящая в орбит)
проекта.
В больших командах из десятков и даже сотен разработчиков, обычно сидя-
щих по разным зданиям или разбросанных по всему миру, технология, как прави-
ло, расписывается гораздо более подробно. Создается намного больше формаль-
ных и официально рецензируемых документов, в анализ и проектирование вовле
кается множество сотрудничающих сторон, не имеющих отношения к разработ
ке, что проявляется в виде конференций, презентаций, документов и прочих
артефактов. И код проекта является лишь одним, хотя и наиболее важным, из ма-
териальных артефактов, составляющих развернутую систему. Нельзя сказать, ч н>
легковесные и тяжеловесные процессы стоят на противоположных полюсах диа
пазопа ценности: каждый тип задач, каждая культура разработки и каждый
конкретный проект требуют технологии, которая подходит только для данного
специфического контекста.
Говорят, что все успешные проекты имеют в общем случае определенные
привлекательные элементы, независимо от своего размера. Такие элементы прак
тически отсутствуют в проектах, не имевших успеха. Понаблюдайте за
сформировавшимся проектом, и вы почувствуете четкий ритм совместной рабо
ты, где отдельные разработчики заняты своим собственным делом и своими арте
фактами и в то же время работают целенаправленно в согласии и с другими орга
нично образующимися группами разработчиков. Такие проекты обычно очеш.
подвижны, устойчивы к изменениям и умеют адаптироваться, но они также пред
сказуемы, надежны и, что действительно важно, способны производить качес,
венный код. Коротко говоря, для таких проектов технология, которой они еле
дуют, настолько является частью труда разработчиков, что она фактически неза
метна, но тем не менее ее дух движет каждым артефактом, создаваемым дружно
работающими членами команды.
Вступительное слово
25
Дух Рационального унифицированного процесса (Rational Unified Process),
или RUP, - это именно такая невидимая технология. RUP эволюционировал мно-
гие годы и воплотил в себе опыт буквально тысяч проектов во всех мыслимых об-
ластях. Пер Кролл (Per Kroll) и Филипп Крачтен (Philipp Kruchten) особенно
хорошо подготовлены к тому, чтобы доступно и по существу объяснить RUP, по-
скольку они являются главными силами, стоящими в Rational Software за созда-
нием RUP и его внедрением в проекты по всему миру.
Если вы заговорите о технологии со многими разработчиками, то часто получите
немедленный отпор, поскольку технология зачастую рассматривается как что-то, что
снижает значение кода. С RUP это просто не так, поскольку его основной целью явля-
ется уменьшение трений между группами разработчиков, чтобы они могли скон-
центрироваться на создании представляющих ценность качественных системах. Пер
и Филипп начинают с объяснения духа RUP, а затем переходят к показу того, как
можно применить RUP к проектам разного вида и размеров.
Объяснив прагматическую сторону RUP, они обсуждают несколько основопо-
лагающих тем, в частности как можно внедри ть RUP в организации и каких под-
нодных камней нужно избегать при этом. Чтобы сделать RUP доступным для раз-
личных заинтересованных сторон, они рассматривают его с точки зрения менед-
жера проекта, аналитика, архитектора, разработчика и тестировщика.
Самый успешный проект делает технологию легкой на вид, но в реальности
и работе есть глубоководные течения. В этой книге Пер и Филипп дают доступ-
ные и практичные объяснения этих течений, так что ваши проекты также после-
дуют за «духом RUP».
Грейди Буч
Главный научный сотрудник
Rational Software Corporation
Февраль 2003
Предисловие
Rational Unified Process (RUP* 1) - это основа технологии разработки программного
ччеспечения, разработанная и продаваемая компанией Rational Software. Он
включает в себя передовой опыт разработки программного обеспечения, собранный
многими людьми за долгие годы работы в широком спектре ситуаций. Он обес-
печивает дисциплинарный подход к распределению и управлению задачами и облас-
1ямн ответственности в организации, занимающейся разработкой программного
обеспечения. Применяя этот процесс, команды разработчиков пршрамм смогут соз-
давать высококачественное программное обеспечение, отвечающее потребностям
своих конечных пользователей, и делать это в рамках предсказуемого графика
н бюджета.
RUP направляет профессионалов в области программного обеспечения на
>ффективное применение лучших современных практических методов, таких как
итеративная разработка, применение архитектурно-центрического подхода,
уменьшение риска на всех стадиях процесса и непрерывная проверка качества
программы. Хотя сегодня RUP эффективно используется в тысячах проектов,
многие команды пугает мысль о реализации новой технологии, которую они
считают большой и сложной. RUP не должен быть большим и он не сложен.
Цель этой книги - показать вам, насколько в действительности прост RUP.
В книге объясняются базовые принципы разработки программного обеспечения,
лежащие в основе RUP, и она поможет вам в применении этого процесса в вашей!
организации. Она также поможет вам выделить для вашей организации или
проекта Конфигурацию процесса RUP верного размера.
Зачем мы написали эту книгу
После более чем десятилетия применения RUP и его предшественников
в дружественных компаниях и шести лет ведения разработки RUP мы имели
возможность увидеть, что работает, а что нет. Мы видели выгоды успешного
применения RUP и проблемы, с которыми проекты и члены групп могли стал-
киваться по пути. У нас также была возможность поработать со многими веду-
। Rational Unified Process, RUP, Rational Process Workbench - это зарегистрированные торговые марки Rational
Software Corporation в Соединенных Штатах и других странах. От компании Rational Software Corporation получено
t пениальное разрешение на использование выдержек и изображений из продукта RUP в книге The Rational Unified
I Tocess Make Easy. - Примеч. авт.
Предисловие
27
шимм профессионалами в области программного обеспечения и поучиться
v них, ежедневно взаимодействуя с ними и получая практический опыт в реаль-
ных проектах.
Позже мы видели много компаний, использующих слишком много RUP.
Да, есть и такая вещь, как «слишком много RUP». Мы почувствовали, что суще-
ствует необходимость в книге по RUP, которая расскажет не только о том, что де-
ла гь и какие артефакты создавать, но также и о том, как упростить процесс и чего
не делать. Мы хотели объяснить, как применять RUP на практике, когда и какие
части RUP использовать в проекте.
С помощью этой книги мы хотим поделиться некоторыми
представлениями, которые мы и наши предшественники
приобрели за многие годы. Наша цель - обеспечить менед-
жеров проектов, аналитиков, архитекторов, разработчиков,
Мы хотели помочь вам
понять, как применять
RUP к проектам разного
размера и разного типа.
1сс1ировщиков, инженеров-технологов и других членов ко-
манды и заинтересованных лиц понятным руководством по RUP. Мы сделали это,
вычленив из нашего практического опыта работы с RUP суть того, что исполнитель
каждой роли должен знать о RUP, и объяснив его роль в нем.
Эта книга не является заменой самому продукту RUP. Хотя в ней и есть
пссколькосотен страниц практического руководства, продукт RUP предоставляет
1Ысячи страниц инструкций для широкого диапазона ролей и задач, а также шаб-
лоны для ускорения работы. Он также обеспечивает глубокую интеграцию
to средствами рабочего стола, поисковой машиной, графической навигацией
и прочими свойствами, которые можно ожидать от базы знаний, основанной на
Web. В отличие от этой книги RUP постоянно эволюционирует, давая вам для
применения в ваших проектах современные руководства. Наконец, эта книга так-
же поможет вам с настройкой RUP на ваши конкретные требования.
Что вы узнаете из этой книги
Читая эту, книгу вы узнаете:
• основные принципы RUP, которые были проверены в сотнях успешных про-
। раммных проектов;
• как применять эти принципы на практике путем рассмотрения всех фаз про-
екта RUP;
?В Предисловие
• Поли и области ответственности менеджеров проектов, аналитиков, архитек-
1оров, разработчиков, тестировщиков и инженеров-технологов в проекте RUP;
• как применять и конфигурировать RUP с минимальным риском;
• как выявить общие признаки ошибки и как избежать их.
Кому следует прочитать эту книгу?
Эта книга конкретно предназначена для:
• всех членов команды, которые используют или собираются использовать RUP,
включая менеджеров, которым требуется введение и общий обзор RUP
и которые желают понять его практическое применение;
• профессионалов программного проекта: тех менеджеров проектов, аналити-
ков, архитекторов, разработчиков, тестировщиков и инженеров-технологов,
которые хотят приобрести детальное понимание своей специфической роли
в проекте RUP;
• менеджеров, инженеров-технологов и прочих, кто желает понять, как можно
применять RUP в данной организации.
Структура и содержание книги
Данная книга подразделяется на четыре части: введение, общий обзор, приме-
нение и руководства по конкретным ролям.
В части I дается введение в RUP. В главе 1 объясняется, что такое RUP и моти-
вы, лежащие в основе его разработки и применения. Глава 2, «дух RUP», описы-
вает общие принципы RUP, базирующиеся на опыте многих успешных проектов
п скомпонованном в несколько простых инструкций. Понимание этих принципов
поможет вам лучше применять RUP в ваших собственных проектах. В главе 3 да-
ется метод сравнения процессов, и мы сравниваем RUP с другими гибкими
процессами, с более традиционными процессами и со средствами оценки процес-
сов, такими как SEI СММ и SPICE. Эти сравнения помогут попять, в проектах ка-
кого типа какой тип конфигурации RUP следует использовать. В главе 4 пред-
ставлен пример использования RUP в очень маленьком проекте - один человек
в течение одной недели. Избавившись от церемоний, необходимых для больших
проектов, вы сможете сконцентрироваться на существенных элементах RUP.
Ill’l ДИСЛОВИЕ
29
В части II RUP представляется через изучение каждой из четырех фаз RUP-
проекта: начало, проектирование, построение и внедрение. Глава 5 посвящена не-
спорым неверным представлениям об этих четырех фазах, объясняется, как
применять в них итеративный подход. В главах 6-9 каждая из фаз рассматривает-
ся подробно. Мы сконцентрируемся на том, чего планируется достигнуть, то есть
пп целях каждой фазы, и научим вас достигать этих целей. Мы поможем вам
придерживаться наиболее существенных задач конкретного проекта. Кроме того,
мы представим задачи RUP с точки зрения временной перспективы, то есть
применительно к реальному проекту, дадим совет, когда выполнять эти задачи
при продвижении по проекту.
. 11рименение RUP требует некоторой подготовки и некоторых предваритель-
ных знаний от организации, собирающейся работать с RUP. Часть III дает базо-
иыс знания в ключевых областях, что обеспечивает рациональность реализации.
II ыаве 10 изучается продукт RUP, подробно описывается, как его можно рас-
ширить и сконфигурировать для соответствия требованиям конкретного проекта
и организации. В главе 11 дается краткий обзор некоторых стратегий, которые
могут быть полезны для реализации процесса, включая инкрементное разверты-
Hiiiiiic, пилотные проекты и учебные курсы. Наш опыт показывает, что переход
। каскадной к итеративной разработке может оказаться весьма трудным для ме-
неджеров проекта, поэтому в главе 12 даются инструкции по планированию RUP-
проскта. За многие годы мы увидели характерные признаки и успеха, и неудачи
и применении RUP. В главе 13 обсуждаются признаки неудачи и то, как их избе-
гни.. Это убережет вас от повторения ошибок других людей.
11родукт RUP дает полные инструкции по широкому диапазону задач
ризработки программного обеспечения. В части IV в главах 14-18 представлены
указания для каждой из пяти ключевых ролей в любом программном проекте: ме-
неджера проекта, аналитика, архитектора, разработчика и тестировщика. Мы
представляем RUP с точки зрения каждой из этих ролей, и для каждой описываем
миссию, требуемую квалификацию, ключевые задачи, а также рекомендуемую
шпературу и способ обучения. Отметим, что нет отдельной главы, посвященной
инженеру-технологу. По большей части эта роль описывается в главах 10 и 11.
Как читать эту книгу
11а основе вашей роли в организации и на основе того, что вы хотите узнать из
пой книги, мы рекомендуем следующие способы ее чтения:
30
Предисловие
• если вы ищете краткий обзор RUP, читайте главы 1, 2, 4.
• если вы ищете подробный обзор RUP, читайте главы 1-9.
• если вам нужно подробное понимание RUP, включая области ответственности
конкретных ролей:
менеджеров проектов, читайте главы 1-14.
аналитиков, читайте главы 1-9, 13, 15 (дополнительно можно просмотреть
главы 8 и 9).
архитекторов, читайте главы 1-9, 13, 16.
разработчиков, читайте главы 1-9, 13, 17 (дополнительно можно
просмотреть главу 6).
тестировщиков, читайте главы 1-9, 13, 18.
инженеров-технологов, читайте главы 1-11, 13.
• если вы администратор, которому нужен краткий обзор RUP, и вы хотите
знать, чего будет стоить принять RUP на вооружение, читайте главы 1,2, 4, 11.
Дополнительная информация
Самую последнюю информацию, относящуюся к этой книге, включая обнов-
ления, важные статьи, форумы для обсуждения и расписание лекций авторов,
можно найти на сайте http://www.rupmadeeasy.com.
Дополнительную информацию о продукте RUP, включая спецификацию и де-
мо-версию, можно взять с сайта http://www.rational.com/products/rup.
Если вы уже используете продукт RUP, дополнительные ресурсы доступны
в RUP Knowledge Center в сети Rational Developer Network (RDN), http://www.ra-
lional.net.
Академические институты могут связаться с Rational Software и получить ин-
формацию о специальной программе по включению RUP в учебные курсы по
программной инженерии: http://www.rational.com/corpinfo/college_relations/seed/
index.jsp.
Благодарности
RUP включил в себя опыт тысяч талантливых профессионалов в области
н|><>| раммного обеспечения, и мы ценим, что имели возможность работать с ними,
pit шивать продукт RUP и писать эту книгу.
' )ia книга не была бы возможна без продукта RUP и команды, работающей над
ним: Mike Barnard, Amanda Brijpaul, Susan Buie, Margaret Chan, Fionna Chong, Erin
• inlis, Philip Denno, Carlos Goti, Debra Gray, Bjum Gustafsson, Sigurd Hopen, Kelli
Ilniision, Lars Jenzer, John Lambert, Bruce Maclssac, Bryant Macy, Glenys Maclsaac,
Min Ringoen, Dan Shiftman, Paul Szymkowiak и Chinh Vo.
'la многие годы полевые команды Rational и технические эксперты накопили
Гн ин.пюй опыт по реализации и использованию RUP. Мы благодарны этим экспертам
ш множество проницательных комментариев и идей, которые дали нам возможность
ионии., что работает, а что не работает в этих условиях. Особенно мы хотели бы
hi мп ить Goran Begic, Thomas Bichler, Kurt Bittner, Anthony Crain, Sam Courtenay, Jer-
ome Desquilbet, Maria Ericsson, Carlos Goti, Jim Heumann, Joe Marasco, Pan-Wei Ng,
Andy Phillipson, Gary Pollice, Leslee Probasco, Walker Royce, John Smith и Ian Spence.
I 1аши внешние рецензенты обеспечили нас неоценимой обратной связью, застав-
ши! нас заново продумывать структуру и содержание книги, что, будем надеяться, по-
ми1 по нам сделать книгу легкой для чтения и осветить вопросы, которые вы считаете
ihiiii к>лее важными в книге по RUP. Все это обеспечили нам Susan Burk, Celso Gonza-
les. (iary Pollice и Dan Rawsthome.
Мы также благодарны Грейди Бучу (Grady Booch) за рецензирование этой книги
н написание вступительного слова.
Гели писать книгу садятся француз и швед, не нужно и говорить о тех огромных
in 11М0ЖП0СТЯХ для улучшения языка рукописи, которые открываются в данном
। пучае. Редакторы из Rational Software Catherine Southwood, Mike Perrow и Marlene
I Ilin углубились в эту задачу с огромной энергией и профессионализмом, как и наши
niii-iiiinie редакторы Kelly Sweeney и Joseph Fatton.
Мы также хотим выразить особую благодарность и любовь нашим женам, Сьюзен
Г |ц »ил (Susan Kroll) и Сильвии Крачтен (Sylvie Kruchten), за терпение, проявленное за
мши не выходные дни и ночи, проведенные нами за написанием и переписыванием
Hull книги.
11 наконец, огромное спасибо нашему издателю Mary O’Brien, производственной
и маркетинговой группам Addison-Wesley, включая Tyrrell Albaugh и Christopher Guz-
Ikuwski, за помощь в выпуске этой книги.
ЧАСТЬ I
Введение в Rational Unified Process
и
Л А»
ГЛАВА 1
Введение в Rational Unified
Process
Что такое Rational Unified Process?
I ели вы будете задавать этот вопрос, то, как правило будете получать разные
nine гы, зависящие от того, кого вы спрашиваете, и от контекста вашего вопроса.
II (лблуждение - так это то, что Рациональный унифицированный процесс от
компании Rational (Rational Unified Process, RUP) в действительности означает
। ри разные вещи.
• RUP - это подход к разработке программного обеспечения, итеративный,
архитектурно-центрический и основанный на прецедентах использования. Он
описывается во многих официальных документах и книгах. Наиболее полную
информацию можно найти в самом продукте RUP, который содержит подроб-
ные инструкции, примеры и шаблоны, охватывающие весь жизненный цикл
программного обеспечения.
RUP - это четко определенная и четко структурированная технология
программной инженерии. В нем явно указывается, кто и за что отвечает, как
и когда все делать. RUP также обеспечивает четко определенную структуру
жизненного цикла RUP-проекта, явно выделяя важные вехи и точки принятия
решений.
• RUP - это также технологический продукт, предоставляющий настраиваемую
1схнологическую основу для программной инженерии. Продукт RUP обеспечи-
вает настройку, а также разработку авторских процессов. С его помощью можно
J IWi I
34
Глава 1
собрать много разнообразных процессов, или Конфигураций процессов. Такие
конфигурации RUP можно создавать и для больших и для малых групп, для
строго дисциплинированного и менее формального подхода к разработке. Про
дукт RUP содержит несколько готовых Конфигураций процессов и Представле-
ний (Views), которые помогут аналитикам, разработчикам, тестировщикам,
менеджерам проектов, менеджерам конфигураций, аналитикам по данным
и прочим членам группы в разработке программного обеспечения. RUP исполь
чуется разнообразными компаниями, работающими в различных отраслях про-
изводства.
В этой главе мы получим представление о том, что такое RUP путем подроб-
ного рассмотрения всех этих трех его сторон.
RUP-подход
В этом разделе мы обсудим общие принципы, используемые в RUP для об-
легчения успешной разработки программ, а также краеугольный камень приме-
нения этих принципов - итеративный подход.
Базовые принципы подхода RUP
В основе Rational Unified Process лежат несколько фундаментальных принци
нов, которые обеспечивают итеративную разработку и представляют собой суп,
«духа RUP» (см. гл. 2). Эти принципы собраны из множества успешных проектон
п образуют несколько простых инструкций. Вот эти принципы:
• Начинайте вести наступление на главные риски раньше и ведите его не-
прерывно... или они сами пойдут в наступление на вас1. Не откладывайчс
обращения к бизнес рискам, техническим рискам и прочим рискам проекта,
определяйте и начинайте наступление на главные риски как можно раньше.
• Обеспечьте выполнение требований заказчиков. Документируйте требова
ния таким образом, чтобы они были понятны заказчикам, и при этом в ходе
проектирования, реализации и тестирования строго придерживайтесь этих
требований, чтобы гарантировать их выполнение.
1. См. Gilb, 1988. - Примеч. авт.
Iiiii/H ние в Rational Unified Process
35
Дух RUP
Основные принципы
• 11ачинайте вести наступление на главные риски раньше и ведите его непрерывно...
или они сами пойдут в наступление на вас.
()беспечьте выполнение требований заказчиков
• с концентрируйтесь на исполняемой программе
• 11риспосабливайтесь к изменениям с самого начала проекта
• Рано закладывайте исполняемую архитектуру
• (' । ройте систему из компонентов
• Работайте вместе как одна команда
• ( делайте качество образом жизни, а не запоздалой идеей
• ( концентрируйтесь на исполняемой программе. Документы, схемы и пла-
ны - это все хорошо, но это лишь слабый показатель действительного про-
। росса, поскольку их оценка субъективна и их важность вторична по отноше-
нию к самому коду. Исполняемый код, который компилируется и успешно
проходит тесты - вот лучший показатель прогресса.
• Приспосабливайтесь к изменениям с самого начала проекта. Современ-
ные приложения слишком сложны, чтобы мы могли получить корректные тре-
бования, проектные решения и реализацию с первого раза. Это означает, что,
дня того чтобы создать достаточно хорошую систему, нам приходится позво-
нить изменения и приспосабливаться к ним.
Закладывайте основу исполняемой архитектуры как можно раньше.
Многие риски в проекте можно свести к минимуму путем проектирования,
реализации и тестирования архитектуры на ранних стадиях проекта. Обес-
печение стабильной архитектуры на ранних стадиях также облегчает общение
и локализует вклад изменений.
• Стройте систему из компонентов. Приложения на основе компонентов более
। пбки с точки зрения изменений, и у них радикально снижены расходы по об-
( иуживанию. Компоненты облегчают повторное использование, позволяют
i издавать более качественные приложения быстрее, чем при использовании
функциональной декомпозиции.
36
Глава 1
• Работайте вместе как одна команда. Разработка программного обеспечения
становится командным видом спорта2, и итеративный подход подчеркивает
важность хорошего общения внутри команды и командного духа, когда каж-
дый чувствует ответственность за окончательный продукт.
• Сделайте качество образом жизни, а не запоздалой идеей. Обеспечение вы-
сокого качества касается не только группы тестировщиков. Оно касается всех
членов команды и всех частей жизненного цикла. Итеративный подход кон-
центрируется на раннем тестировании и автоматизации тестов в целях боль-
шей эффективности регрессионного тестирования, что уменьшает число де-
фектов.
Эти принципы более подробно рассматриваются в главе 2.
RUP и итеративная разработка
Большая часть команд, разрабатывающих программное обеспечение, до сих
пор используют в своих проектах каскадную разработку3 (waterfall process), при
которой фазы выполняются в четкой последовательности: сначала требования,
затем анализ и проектирование, потом реализация/интеграция и затем тестирова-
ние. Или, что более обычно, модифицированную каскадную разработку с добав-
лением к вышеописанному ходу действий циклов обратных связей. Такой подход
заставляет ключевых членов группы простаивать довольно продолжительное
время, а тестирование откладывается на самый конец жизненного цикла проекта,
когда проблемы, как правило, являются серьезными, исправлять их дорого? и это
ставит под угрозу сроки выхода конечного продукта.
В противоположность этому RUP использует итеративный подход (итерация -
повторение), то есть последовательность нарастающих шагов или итераций. Каж-
дая итерация включает в себя некоторые или большую часть дисциплин разработки
(выявление требований, анализ, проектирование, реализацию и т.п.), как это можно
видеть на рис. 1.1. У каждой итерации есть четко определенный набор целей, и она
создает частично работающую реализацию конечной системы. Каждая после-
дующая итерация строится на результатах предыдущих, развивает и усовершенст-
вует систему до тех пор, пока не будет создан конечный продукт.
2. См. Booch, 2001.
3. Также используется термин «схема водопада». -Примеч. науч. ред.
lint Д1 ние в Rational Unified Process
37
Требования
Деловое Л Анализ и проектирование
моделирование
Планирование „ Реализация
Среда управления
конфигурациями ’
1*ис. f.f. Итеративная разработка в RUP. Rational Unified Process предлагает альтернативный под-
ход - при каждой итерации производится немного работы с требованиями, анализа, про-
ектирования, реализации и тестирования. Каждая итерация основывается на результатах
предыдущих итераций и производит исполняемую программу, которая на один таг при-
ближается к окончательному продукту
liojiee ранние итерации больше концентрируются на требованиях, анализе
и проектировании, более поздние - на реализации и тестировании.
I Ггеративный подход доказал свои преимущества перед каскадным по не-
i мин.ким пунктам.
• Он приспособлен к меняющимся требованиям. Изменение требований
и «расползание функциональности», - добавление свойств, определяемое за-
казчиком или нуждами технологии - всегда было самым главным источником
бед проектов. Оно приводило к опозданию с выпуском, нарушению графиков,
неудовлетворению заказчиков и раздражению разработчиков. Итеративная
разработка концентрирует внимание группы на создании и демонстрации
исполняемой программы в течение нескольких недель, что заставляет сосре-
доточиться на наиболее существенных требованиях.
• И итеграция - это не один «большой взрыв» в конце проекта. Оставить
интеграцию на самый конец означает получить переработки с большими за-
। ратами времени - иногда до 40% всего объема проекта. Чтобы избежать
38
Глава 1
>гого, итеративный подход разбивает проект на небольшие итерации, каж
дая из которых заканчивается интеграцией, при которой строительные бло
ки постепенно и непрерывно интегрируются, что сводит к минимуму позд-
нейшую переработку.
• Риски обычно обнаруживаются и устраняются на ранних итерациях.
Итеративный подход RUP минимизирует риск на ранних итерациях, когда тес
тируются все компоненты. Поскольку каждая итерация задействует многие
аспекты проекта, такие как инструменты, готовое программное обеспечение
и навыки членов группы, вы можете быстро обнаружить, является ли предпо-
лагаемый риск реальным, а также выявить новые, неожиданные риски в то
время, когда их легче и не так дорого снять.
• Менеджеры имеют возможность внесения тактических изменений
в продукт: для завершения существующих продуктов, например. Итеративная
разработка быстро создает исполняемую архитектуру (хотя и с ограниченной
функциональностью), которую можно использовать для быстрого выпуска про-
дукта с некоторыми ограничениями, чтобы ответить на действия конкурента.
• Облегчается повторное использование. Гораздо легче определить общие
части тогда, когда они уже частично спроектированы или реализованы
в итерациях, чем распознать их при планировании. Рецензирование проектных
решений на ранних итерациях позволяет архитекторам указать на потенциаль-
ные возможности для повторного использования и затем разработать в после-
дующих итерациях зрелый общий код для реализации таких возможностей.
• Дефекты можно найти и исправить за несколько итераций, что обеспечи
вает создание четкой архитектуры и высококачественного приложения. Про-
счеты обнаруживаются еще в ранних итерациях, а не в ходе массированной
тестовой фазы в конце. Узкие места производительности обнаруживаются то-
гда, когда на них еще можно повлиять, а не перед самым выпуском продукта.
• Лучшее использование персонала в проекте. Многие организации совме
щают использование каскадного подхода с организацией по типу конвейера
аналитики посылают готовые требования проектировщикам, которые отсы-
лают свой продукт программистам, которые посылают компоненты специалн
стам по интеграции, которые отсылают систему тестировщикам. Такие мно
гочисленные переходы являются источниками ошибок и недопонимания и за
ставляют людей меньше чувствовать ответственность за конечный продукт
Итеративный процесс расширяет области компетенции членов группы, разре
шая им выполнять много ролей, позволяя менеджеру проекта лучше использо
вать имеющийся персонал, и одновременно убирает вредные передачи.
inn/и ние в Rai ional Unified Process 39
• Члены команды учатся на ходу. Участники проекта на протяжении цикла
разработки получают возможность учиться па своих ошибках от одной итерации
к другой. В результате изучения более ранних итераций можно получить больше
возможностей для обучения. При использовании каскадного подхода у вас есть
юлько одна попытка для проектирования, кодирования и тестирования.
• Улучшается процесс разработки сам но себе и становится по ходу работы
более совершенным. Оценка в конце итерации позволяет не только изучить
состояние проекта с точки зрения продукта или графика, но также проанали-
зировать, что можно улучшить в организации и технологии в следующей
итерации.
11екоторые менеджеры проектов сопротивляются введению итеративного под-
хода. рассматривая его как что-то вроде бесконечного и неконтролируемого ха-
кшп а. При Rational Unified Process интегрированный подход находится иод жест-
ким контролем: количество, продолжительность и цели итерации тщательно пла-
нируются, а задачи и области ответственности участников четко определяются.
Кроме этого, фиксируются объективные показатели прогресса. Некоторая
переработка от итерации к итерации производится, но это также происходит под
яат1ким контролем.
------------------------------------------
RUP - четко определенная технология программной инженерии
Сам Rational Unified Process создавался с использованием ме- Моделирование
1ПДИКИ, похожей па используемую в проектировании программ.
II частности, моделирование производилось с помощью Software
Piocess Engineering Metamodei (SPEM)4 - стандарта моделирова-
ния процессов, основанного на Unified Modeling Language
RUP основывается
на Software Pro-
cess Engineering
Metamodei (SPEM).
(UMI.)5. На рис. 1.2 показана общая архитектура Rational Unified Process.
V процесса есть две структуры, или, если угодно, два измерения:
• динамическая структура. Горизонтальное измерение представляет собой
динамическую структуру, или временное измерение процесса. Оно показыва-
ет, как процесс, выраженный в форме циклов, фаз, итераций и вех, развертыва-
ется в ходе жизненного цикла проекта;
1 См. OMG2001.
(йандарт для определения, визуализации и документирования моделей программных систем, включая их
< । рук iypy и дизайн. Стандарт находится под управлением Object Management Group (www.omg.org).
40
Глава 1
статическая структура. Вертикальное измерение представляет собой ста-
шческую структуру процесса. Оно описывает, как элементы процесса - за-
дачи, дисциплины, артефакты и роли логически группируются в главные дис-
циплины процесса (или рабочие процессы - workflows).
')ти три измерения обсуждаются в последующих разделах.
Рис. 1.2. Два измерения RUP. Rational Unified Process организован в виде двух измерений
динамический аспект (горизонтальный) выражает циклы, фазы, итерации и вехи
Статический аспект (вертикальный) выражает задачи, дисциплины, артефакты и роли
Динамическая структура Rational Unified Process
В динамической структуре речь идет о жизненном цикле или временном
измерении проекта. RUP обеспечивает структурированный подход к итеративной
разработке, разделяя проект на четыре фазы: Начало, Проектирование, Построение
и Внедрение (см. рис. 1.3)6. В главах 6-9 эти фазы рассматриваются подробно. Цели
и вехи фаз перечисляются на врезке «Фазы жизненного цикла, цели и вехи».
б. См. Kruchten 2000а.
Hui д|-ние в Rational Unified Process
41
Фазы жизненного цикла, цели и вехи
Физа Начало (Inception)
I (ели:
• понять границы проекта
• разработать экономическое обоснование (business case)
• добиться соглашения между заинтересованными сторонами для дальнейшего
продвижения
Веха: Lifecycle Objective Milestone, LCO (Bexaa целей жизненного цикла)
Фаш Проектирование (Elaboration)
Цели:
• снести к минимуму главные технические риски
• создать базовую архитектуру
• понять, во что обойдется построение системы
Веха: Lifecycle Architecture Milestone, LCA (Веха архитектуры жизненного цикла)
Фаза nocTpoeHHe(Construction)
Цели:
• построить первую работающую версию продукта
Веха: Initial Operational Capability Milestone, IOC (Веха начальной функциональной
I ОЮВНОСТИ)
'Раза Внедрение (Transition)
I (ели:
• создать окончательную версию продукта и отправить ее заказчику
Веха: Product Release Milestone, PR (Веха готового продукта)
н Вехи также называют контрольными точками процесса, поскольку именно в них проверяется достижение целей
||>ш|юдной фазы и принимается решение о переходе (или непереходе) в следующую фазу. - Примеч. науч. ред.
Каждая фаза содержит одну или более итераций, которые направлены на соз-
цппие промежуточных компонентов системы, необходимых для достижения биз-
нес целей данной фазы. Итераций проводится столько, сколько нужно для дости-
тспня целей фазы, и не больше. Если на запланированной фазе цели достигнуть
пс удается, нужно добавить к данной фазе еще одну итерацию, что вносит
42
I ЛАЕМ *
к проект задержку. Чтобы избежать этого, убедитесь, что каждая итерация кон
центрируется строго на том, что единственно необходимо для достижения биз-
шт целей фазы. Например, слишком сильная концентрация на требованиях в фа-
iv Начало непродуктивна. В главе 12 мы обсудим планирование проекта.
Начало Проектирование •. 1 Построение J Внедрение :
__ Время
Веха целей Веха архитектуры Веха начальной Веха готового
жизненного цикла жизненного цикла функциональной продукта
Рис. 1.3. Вехи фаз жизненного цикла в RUP. Каждая из четырех фаз RUP имеет- иеху и чет ко опре-
деленный набор целей. Используйте эти цели для определения того, какие задачи выпол-
нять и какие артефакты создавать
Каждая итерация концен-
трируется строго на том,
что единственно необхо-
димо для достижения биз-
нес-целей фазы.
• Начало. Добейтесь четкого понимания того, какую
систему создавать, определив на высоком уровне все тре-
бования и установив границы проекта. Сведите к мини-
муму весь деловой риск, создайте экономическое обосно
вание построения системы и добейтесь согласия между
заинтересованными сторонами по вопросу о том, нужно
ли продолжать проект.
• Проектирование. Позаботьтесь о многих наиболее технически сложных за-
дачах: проектируйте, реализовывайте, тестируйте и закладывайте основу ис-
полняемой архитектуры, включая подсистемы, их интерфейсы, ключевые ком
поненты и архитектурные механизмы, такие как коммуникации между про
цессами и хранение данных. Обратитесь к основным техническим рискам,
таким как конфликт ресурсов, производительность и безопасность данных,
путем реализации и проверки реального кода.
• Построение. Большую часть реализации осуществляйте по мере перехода oi
исполняемой архитектуры к первой работающей версии системы. Используй-
те несколько внутренних и альфа-релизов, чтобы убедиться, что системой
можно пользоваться и она удовлетворяет потребности пользователей. Фаза за-
канчивается выпуском полностью функциональной бета-версии системы,
включающей средства инсталляции, справочную документацию и учебный
Нш дение в Rational Unified Process
43
материал (хотя система, скорее всего, будет требовать настройки функцио-
нальности, производительности и общего качества).
• Внедрение. Убедитесь, что программа соответствует нуждам пользователей.
Этот процесс включает тестирование продукта при подготовке к выпуску
и осуществление небольшой настройки на основе обратной связи с пользова-
телем. В этот момент жизненного цикла обратная связь с пользователем кон-
центрируется главным образом на проблемах тонкой настройки продукта, кон-
фигураций, процедуры инсталляции и удобства пользования. Все главные
структурные проблемы уже должны быть разрешены на более ранних стадиях
жизненного цикла проекта.
Статическая структура Rational Unified Process
Статическая структура имеет дело с тем, как элементы процесса - задачи, дис-
циплины, артефакты и роли логически группируются в основные дисциплины
процесса. Процесс описывает кто что делает, как и когда. Как показано на врез-
ке «Четыре ключевых модельных элемента RUP» и на рис. 4.1, Rational Unified
1’iocess представляется с помощью четырех ключевых модельных элементов.
Четыре ключевых модельных элемента RUP
Роли. Кто
Задачи. Как
Артефакты. Что
Рабочие процессы. Когда
1\1ЛИ
Роль (Role) - это что-то вроде «шапки», которую носит человек или группы
людей в ходе выполнения проекта. Один человек может носить несколько разных
"шапок». Это важный момент, поскольку естественно считать, что роль - это
человек в группе или фиксированное наименование работы, но в RUP роль
просто определяет, как люди должны работать, и указывает области компетенции
к о!ветственности, которые должен иметь человек (или люди), играющий дан-
ную роль. Человек, как правило, выполняет несколько ролей, а одну роль может
выполнять несколько человек.
44
Глава i
Задачи
Проектировщик
Анализ прецедента
использования
Дизайн прецедента
использования
Артефакт
отвечает за
Реализация прецедента
Рис. 1.4. Роли, задачи и артефакты. Роль показывает, кто (человек или группа) выполняет работ \
Задача определяет, как выполняется работа. Артефакт фиксирует сделанное
Задачи
Задача (Activity) конкретной роли - это та единица работы, выполнения ко-
торой можно потребовать от человека, выполняющего данную роль. Задача имееч
ясную цель, обычно определяемую как создание или обновление каких-либо
артефактов, например модели, компонента или плана. Каждая задача связывается
с конкретной ролью.На выполнение задачи обычно уходит от нескольких часов
до нескольких дней. При этом задействуется один человек, и задача влияет только
па один артефакт или на небольшое их число. Нужно, чтобы задачу можно было
использовать как элемент планирования и [оценки7] прогресса. Если задача буде i
слишком мала, ею пренебрегут, а если она будет слишком велика, то нужно
выражать прогресс в форме частей задачи. Задача может повторяться одной
ролью по несколько раз, применительно к одному артефакту, особенно при
переходе от одной итерации к другой, при усовершенствовании и расширении
системы, но это необязательно будет один и тот же человек.
I. Дополнено научным редактором.
Нш д| ние в Rational Unified Process
45
II kun
Задачи подразделяются на шаги (step), которые разделены натри главные ка-
ч<| ории:
• шаги для продумывания, когда человек, играющий определенную роль осоз-
нает суть задачи, проводит сбор и проверку входящих артефактов и форму-
лирует результат;
' исполняющие шаги, когда ролью создаются или модифицируются некоторые
артефакты;
• проверочные шаги, когда ролью выполняется оценка результатов по опреде-
иснному критерию.
11е все шаги обязательно делаются при каждом выполнении задачи, поэтому
ННп п можно выразить в форме альтернативных ветвей.
^>1 ('факты
Артефакт представляет собой объем информации, создаваемый, изменяемый
win используемый процессом. Артефакты - это материальные элементы проекта:
in, 'но проект создает или использует при своем продвижении в направлении
конечного продукта. Артефакты используются ролями как входные данные при
мыполнении задачи и являются результатом или выходом других задач.
Артефакты могут иметь разные формы:
• модель, например, Модель прецедента использования (Use Case Model) или
Модель проектирования (Design Model);
• элемент модели, то есть элемент внутри модели, например, класс, прецедент
использования (Use Case, UC) или подсистема;
• документ, например Концепция или Экономическое обоснование (Business
(’use);
* исходный код
• исполняемые файлы, например исполняемый Прототип.
Аргефакт может документироваться формально (с помощью специального ин-
< 1румента) или неформально (фиксироваться с помощью электронного письма или
ни письменной доске). Более подробно это обсуждается в главе 3 и главах 6-9.
46
Глава 1
Люди не машины,
и нельзя считать
рабочий процесс
программой,
которой люди
должны следовать
н точности и меха-
нически.
Рабочие процессы
Простой список всех ролей, задач и артефактов не составляет проект полно-
стью. Нужен способ описания осмысленных последовательностей задач, соз-
дающих какой-либо полезный результат и описывающий взаимодействия между
ролями. Именно это и делают рабочие процессы (workflows).
Рабочие процессы имеют разные виды и формы. Два наиболее общих рабочих
процесса: Дисциплины (Disciplines), которые представляют собой высокоуров-
невые рабочие процессы (см. нижеследующий раздел «Дисциплины»), и Детали
рабочего процесса (Workflow Details), являющиеся рабочими процессами
внутри дисциплины.
В терминах UML рабочий процесс можно выразить в виде
диаграммы последовательностей (sequence diagram), диаграммы
кооперации (collaboration diagram) или диаграммы деятельности
(activity diagram). На рис. 1.5 показан пример рабочего процесса.
Заметим, что не всегда возможно или практично отражать все за-
висимости между задачами. Часто две задачи переплетены более
тесно, чем это показано, особенно если они выполняются одним
человеком. Люди не машины, и нельзя считать рабочий процесс
программой, которой люди должны следовать в точности и меха-
нически.
Дополнительные элементы процесса
Роли и задачи (организованные в рабочие процессы), а также артефакты пред-
ставляют собой основу статической структуры Rational Unified Process. Но суще-
сгвуют и другие элементы, добавляемые к задачам или артефактам, которые
делают процесс более понятным и удобным для использования и которые дакп
полсе полные указания практикам. Эти дополнительные элементы таковы:
• Руководства (Guidelines) - дают правила, рекомендации и эвристику для вы-
полнения задач, шагов и обращения с артефактами.
• Шаблоны (Templates) - для различных артефактов.
• Инструкции по использованию инструментальных средств (Tool
Mentors) - для установления связи и предоставления практического руково-
дства к использованию средств разработки.
• Основные принципы (Concepts) - для представления ключевых определений
и принципов.
Пыление в Rational Unified Process
47
• Дорожные карты (Roadmaps) - для введения пользователя в RUP
с конкретной точки зрения.
11а рис. 1.6 показано, как эти элементы усовершенствуют первичные элементы.
Рис. 1.5. Рабочий процесс дисциплины Требования (Requirements ). Рабочий процесс показывает,
в каком порядке выполняются задачи для достижения измеримого результата. Рабочие
процессы RUP обычно демонстрируют наиболее существенные зависимости между за-
дачами с целью избежать перегруженности изображения
Дисциплины
И наконец, все элементы процесса - роли, задачи, артефакты и связанные
i ними концепции, руководства и шаблоны сгруппированы в логические контей-
неры, называемые Дисциплинами (Disciplines). В стандартном продукте RUP
дисциплин всего девять (см. врезку «Дисциплины RUP»).
Этот список не является окончательным, и любая компания, вносящая рас-
ширения в стандартный продукт RUP, может вводить дополнительные дисциплины.
48
Глава 1
Дисциплины RUP
• Бизнес-моделирование (Business Modeling)
• Управление требованиями (Requirements Managing)
• Анализ и проектирование (Analysis and Design)
• Реализация (Implementation)
• Развертывание (Deployment)
• Тестирование (Test)
• Управление проектом (Project Management)
• Управление изменениями (Change Management)
• Среда (Environment)
рпх ........ Т=ъ.
Руководство Инструкция по использованию
по проектированию Rational XDE
Роль Задачи
Проектировщик Анализ прецедента Дизайн прецедента
использования использования
Артефакт I j отвечает за
Реализация прецедента Шаблон прецедента
использования использования
Рис. 1.6. Добавление шаблонов, инструкций по использованию инструментальных средств и Руко-
водств. Шаблоны помогают быстрому созданию артефакта. Инструкции по использова-
нию инструментальных средств дают подробные указания по выполнению задачи или ша-
га с помощью имеющихся средств. Руководства дают подробные наставления по выпол-
нению задач, шагов и артефактов
Пиление в Rational Unified Process
49
Продукт RUP созда-
ет полную техноло-
гическую базу.
RUP - настраиваемый технологический продукт
Каждый проект и каждая организация имеют свои нужды,
<чю требует от технологии возможности адаптироваться к
конкретней ситуации. Чтобы соответствовать этому требова-
нию, продукт RUP предлагает полную технологическую базу
^м. рис. 1.7), состоящую из нескольких интегрированных частей:
• Наилучшие практические методы. RUP сопоставляется с библиотекой
лучших практических методов, созданных компанией IBM Software и ее парт-
нерами. Эти методы постоянно эволюционируют и охватывают гораздо боль-
шую область, чем можно описать в этой книге. Эти практические методы
имеют форму фаз, ролей, задач, артефактов и рабочих процессов.
he. 1.7. Технологическая база RUP. Продукт RUP состоит из широкого спектра лучших практиче-
ских методов (best practices), инструментов конфигурирования, предназначенных для вы-
бора из этих методов наиболее подходящих, средств доставки для доступа к этим средст-
вам; сюда входят также onJine-сообщества для обмена артефактами и опытом, и инстру-
менты создания собственных процессов для добавления в RUP своих собственных мето-
дов разработки
50
Глава 1
* (’родства доставки. RUP уже находится буквально в руках разработчика, по-
скольку он поставляется online с помощью web-технологии, а не через книги
и документы. Средства доставки позволяют интегрировать процесс со многи-
ми средствами разработки программ, входящими в Rational Suite, а также со
многими другими, так что разработчики могут получить доступ к инструкци-
ям по процессам прямо из используемого инструмента.
' Средства конфигурирования. Модульная и электронная форма RUP позво-
ляет сконфигурировать и подогнать его под конкретные нужды организации.
Коротко это обсуждается в разделе «Средства конфигурирования и создания
собственных процессов», а более подробно - в главе 10.
* Средства создания собственных процессов. Среда Rational Process Work-
bench (RPW) - это средство создания собственных процессов, позволяющее
вам перевести ваши лучшие практические методы в формат RUP (более
подробно в главе 10).
* Сообщество/Рынок. Online-сообщество Rational Developer Network (RDN)
позволяет пользователям обмениваться опытом друг с другом и с экспертами
и обеспечивает доступ к самой свежей информации в форме артефактов, ста-
тей и дополнительной информации.
Продукт RUP спроектирован, разработан, выпущен и обслуживается как
и любой другой программный продукт. Его обновления производятся приблизи-
1слыю два раза в год, поэтому технология никогда не устаревает и пользователи
применяют все преимущества последних разработок.
Теперь давайте подробнее рассмотрим две области возможностей RUP: сред
< | па конфигурирования и создания собственных процессов и средства доставки.
Средства конфигурирования и создания собственных процессов8
11с нужно следовать процессу вслепую, проделывая бесполезную работу,
в создавать артефакты, имеющие немного ценности. Наоборот, процесс нужно
сделать как можно более лаконичным, но вместе с тем выполняющим свою мис-
сию по помощи разработчикам в предсказуемом создании высококачественного
программного обеспечения. Усвоение лучших практических методов компании,
а также ее специфических правил и технологии должно дополнять процесс.
в Приведенное ниже описание соответствует последней доступной на момент выхода книги версии (2003) RUP.
Примеч. науч. ред.
ttiii/iHiME в Rational Unified Process
51
I кккольку Rational Unified Process - это технологическая основа9, его можно
и 'ini п ировать и расширить для соответствия потребностям использующей его
|ч1мпании. Основа RUP состоит из компонентов, которые делятся на базовый на-
пор и ряд Плагинов (расширений). Как показано на рис 1.8, создать Конфи-
I ур;щию процесса можно, выбрав набор Плагинов и добавив их к базовому на-
бору. Вы даже можете произвести тонкий отбор компонентов процесса из тех,
Вторые входят в выбранные Плагины и базовый набор. Это облегчает создание
Конфигурации процесса, соответствующей конкретным нуждам, характеристи-
кам, ограничениям, культуре и области вашего проекта или компании.
Партнеры
Технологические
плагины
Инструментальные
плагины
Доменные плагины
Ядро RUP
Плагин,
входящий в RUP
Плагин,
входящий в RUP
Плагин,
входящий в RUP
Плагин,
входящий в RUP
Заказчики
; Плагины проекта
Плагины компании
RUP-библиотека
RUP-база
RUP для систем в . I ЯиРдля I RUP
реальном времени i малых проектов > для .NET
RUP М RUP RUP
для J2EE i “ для компании X для проекта Y
Конфигурации MyRUP
hr. 1.8. Компонентная архитектура продукта RUP. Она позволяет сконфигури-ровать RUP в соот-
ветствии с требованиями проекта, выбирать пользователям из широкого разнообразия
Плагинов и использовать только те, которые соответствуют данному проекту
Т акже вы можете создавать различные Представления процесса, которые по-
июляют каждому участнику проекта увидеть Конфигурацию процесса сточки
(рения своей роли и областей ответственности. В продукт RUP также входят не-
0 См. Kroll 2001, - Примеч. авт.
52
Глава 1
сколько готовых Конфигураций и Представлений процессов, которые вы можете
использовать вначале. В главе 10 подробно описывается, как конфигурировать
продукт RUP.
Компании, использующие средства создания собственных процессов, могут
поместить свои ноухау по определенной технологии, инструменту или области
в 11лагин RUP, и сделать его доступным для пользователей внутри или вне своей
организации. Пользователи RUP могут также создавать Плагины, специфичные
для проекта, подразделения или всей организации, и, таким образом, сделать
свои ноухау доступными для всех своих инженеров по программному обес-
печению. При конфигурировании RUP можно пользоваться всеми преимущества-
ми, заключенными в своих и созданных партнерами Плагинах, и создавать кон-
фигурации, соответствующие конкретным потребностям. Как создавать Плагины
RUP, описывается в главе 10.
Средства доставки
Использование процесса может быть весьма сложным. Продукт RUP помогает
пользователям, предоставляя им MyRUP (настраиваемый Web-интерфейс),
Инструкции по использованию инструментов и Расширенную помощь. Комбина-
ция Инструкций по использованию инструментов и Расширенной помощи обес-
печивает двустороннюю интеграцию между RUP и инструментами вашего
рабочего стола. Эта интеграция помогает практикам более эффективно использо-
вать инструменты, позволяет получать больше выхода от вложений в них и об-
легчает эффективную реализацию процесса.
MyRUP
MyRUP предоставляет
основанный на ролях
браузер с древовид-
ной структурой, со-
держащий ссылки на
важные части Конфи-
!урации процесса ва-
шего проекта.
Продукт RUP может доставляться через персонализированный
Web-браузер, называемый MyRUP. Браузер MyRUP предостав-
ляет Представления процесса (Views) - персонализированный
или основанный на ролях древовидный элемент управления,
содержащий ссылки на важные части Конфигурации процесса
вашего проекта, а также ссылки на файлы или URL, внешние
по отношению к вашей конфигурации (см. рис. 1.9).
Ншдрние в Rational Unified Process
53
j S JOHNS CUSTOMIZED VIEW |
M ”
iHeouuymerls Spat
Role: Requirements Specifier
The requirements specifier role specifiers the details of one or more a
parts of (he system's functionality by describing one or the aspects of the
requirements
Topics
Description
Iriformatior,
Staffing
Further
Reading
Pe-qiiirem-eiit'S
'♦ '< « ................
h.U -f.Aiiifjits
й£| Applet RupPresenterApplet started
У My Computer
he. 1.9. MyRUP предоставляет персонализированные Представления. MyRUP это персонализиро-
ванный Web-иптерфсйс c RUP, позволяющий пользованиям ле, ко находить информацию
с помощью персонализированных Представлений, поисковой машины, графических
средств навигации и древовидного элемент а управления.
Каждый пользователь может настроить свое Представление и.ли использовать
уже настроенные Представления. MyRUP также предоставляет поисковую маши-
ну, глоссарий и учебник «Getting Started» (Введение).
Инструкции по использованию инструментальных средств
Основная часть продукта RUP независима от инструментов, хотя многие из за-
дич RUP необходимо выполнять с их помощью, а практикам нужно понимать, как
реализовывать процесс с помощью доступных средств. Инструкции по исполь-
loiiaiiino инструментальных средств (Tool Mentors) дают пошаговые инструк-
ции по решению различных задач RUP с помощью имеющихся инструментов
щписывают, какой пункт меню выбрать, что вводить в диалоговых окнах и как
рисовать диаграммы для выполнения конкретных задач.
Инструкции по использованию существуют для инструментов от Rational,
п 1пкже других инструментов, таких как IBM WebSphere Application Server и BEA
Глава 1
54
WebLogic. Клиенты и партнеры могут писать дополнительные Инструкции по ис-
ионыованию инструментов, и их можно включать в Плагины RUP как любые
I।>\ гпе элементы процесса в продукте RUP.
/! ^ширенная помощь
Расширенная помощь (Extended Help) предоставляет контекстнозависимые
инструкции для различных инструментов. Например, если вы пытаетесь исполь-
ювать редактор Диаграмм классов (Class Diagram) в Rational Rose и вы не знаете,
и к> делать дальше, вы можете открыть Расширенную помощь в меню инструмен-
к'в Rose. Вы получите список наиболее значимых тем RUP в зависимости от кон-
। скс га, то есть в данном случае - для Диаграммы классов в Rose (см. рис. 1.10).
Кто использует продукт RUP
Продукт RUP используют приблизительно 10 000 компаний. Они использую!
ск> в различных областях и в равной степени в больших и малых проектах. Эю
разнообразие показывает многогранность и широкую применимость продукта
Hl IP. Вот примеры разнообразных промышленных отраслей по всему миру, в ко-
lopi.ixRUP применяется:
• телекоммуникации
• транспорт, аэронавтика и исследования космоса, оборона
• обрабатывающая промышленность
• финансовые службы
• системная интеграция
RUP стал широко применяться в течение нескольких последних лет, что явля-
с!ся признаком изменений в нашей отрасли. С ростом требований по скорости
выпуска продуктов, а также запросов на высококачественные приложения компа-
нии стремятся учиться на опыте других и готовы применять проверенное прак-
। пчсское знание.
Способ использования Rational Unified Process в этих организациях значительно
варьируется. Некоторые используют RUP очень формализованно, и с высокой дис-
циплиной: выводят технологию своей компании из продукта RUP и следуют ей
с высокой точностью. В других организациях применение RUP менее формально
11иатформа RUP используется как хранилище советов, шаблонов и инструкций, ис-
пользуемых по мере продвижения, а также как база знаний по программной инже
перни.
Ц|ид| нйе в Rational Unihed Process
55
Рис. 1.10. Kohickci независимая расширенная помощь в RUP. Расширенная помощь обсспечивасг
кшпексгнозависимую справку ио используемым инструментам. При запуске она выдает
перечень наиболее значимых тем из RUP.
Работая с такими клиентами, наблюдая, как они используют продукт RUP,
tlblz, какие добавления они вносят в процесс в зависимости от конкретных задач,
ри фаботчики RUP в IBM Software продолжают совершенствовать продукт RUP.
Заключение
Мы выяснили, что Rational Unified Process, или RUP, означает три совершенно
ри П11.1С вещи:
• RUP - это подход к разработке программного обеспечения, итеративный,
архитектурно-центрический и основанный на прецедентах использования. Он
описывается во многих официальных документах и книгах, но наиболее пол-
ную информацию можно найти в самом продукте RUP.
56
Глава 1
• RUP - это четко определенная и четко структурированная технология
программной инженерии. В нем явно указываются все вехи проекта, кто и за
что отвечает, как нужно все делать и когда.
• RUP - это также технологический продукт, предоставляющий настраивае-
мую технологическую основу для программной инженерии. Продукт RUP
обеспечивает настройку, а также разработку авторских процессов. Сконфи-
гурировать RUP можно, и для больших и для малых групп, для строго дисцип-
линированного и менее формального подхода к разработке. Он также позволя-
ет добавлять свои собственные практические методы и обмениваться опытом
и артефактами с коллегами и экспертами.
Теперь, когда мы имеем некоторое представление о том, что такое RUP, давай-
ie пойдем дальше и поймем суть и «дух RUP», то есть фундаментальные принци-
пы, лежащие в его основе.
У
ГЛАВА 2
«Дух RUP» - путь к успеху
Нас часто спрашивают, как узнать, правильно ли мы используем RUP? Одно-
тачпого ответа на этот вопрос не существует. Бессмысленно искать ответ,
пересчитывая число выполняемых вами задач в RUP или число создаваемых
ир|ефактов. Лучше всего ответить на этот вопрос, поняв, насколько ваш проект
ыюгветствует фундаментальным принципам, отражающим суть «духа RUP».
II них фундаментальных принципах заключен наш опыт, а также опыт тысяч
клиентов и коллег в Rational Software, приобретенный за последние 20 лет. Хотя
ни принципы не дают полного представления о RUP и не отражают всей сложно-
i in проектов, понимание этих принципов приведет вас к лучшему применению
HI IP в ваших собственных проектах. Эти принципы таковы:
• Начинайте наступление на главные риски раньше и ведите его непрерывно
пли они сами пойдут в наступление на вас.
• < >беспечьте выполнение требований заказчиков.
• ( концентрируйтесь на исполняемой программе.
• 11риспосабливайтесь к изменениям с самого начала проекта.
• Закладывайте основу исполнимой архитектуры как можно раньше.
• ( гройте систему из компонентов.
’ Работайте вместе как одна команда.
• < 'делайте качество образом жизни, а не запоздалой идеей.
I Ггеративную разработку можно вести и без этих принципов, однако их использо-
вание повысит успешность проекта. Чтобы оптимизировать реализацию итеративно-
н । подхода, вы должны попытаться применить в вашем проекте как можно больше
♦nix принципов. Вы можете обнаружить, что некоторые из этих принципов не под-
58
Глава :
ходят вашему проекту - прекрасно. Даже в самой его основе RIJP следует р;к
сматривать как «шведский стол», откуда выбирают блюда по своему вкусу.
)ги принципы также определяют, в чем Rational Unified Process отличается oi
других итеративных подходов, а именно в главном акценте на рисках и в созда
ипи с самого начала исполнимой архитектуры.
Мы обсудим каждый из этих основных принципов в следующих разделах.
Начинайте вести наступление на главные риски раньше и ведите его
непрерывно
/ 1/еративный подход
позволяет выяви/ь
I //явные риски и при-
ня/ься за них досга-
/очно рано.
Как говорил Том Гилб (Tom Gilb), «если вы не будете активно
вести наступление на риски, они сами пойдут в наступление in
вас»1. Одно из главных преимуществ итеративною подхода со
стоит в том, что он позволяет выявить главные риски
и обратить на них внимание дос таточно рано (рис. 2.1.).
Рис. 2.1. Кривые снижения рисков для каскадных и итеративных разрабоюк. Главная цель при
итеративной разработке состоит в снижении рисков на ранних сиднях. )ю доспиасп
анализом, расставлением приоритетов и борьбой с паиболыиичи ронскими в каж он
и итерации.
Время
I См. Gilb 1988. - Примеч. авт.
•Дук HUP» - ПУТЬ К УСПЕХУ
59
Зачем рано обращать внимание на риски? Незамеченные риски означают, что
цы возможно инвестируете средства в ошибочную архитектуру и неоптимальный
tiaiюр требований. А это плохой способ вести дело. Кроме того, величина риска
ппнрямую коррелирует с разницей между верхним и нижним оценочным сроком
ипн ршения проекта. Чтобы провести точную оценку, нужно выявить и начать
и (ранять риски заранее.
Что же делать с рисками на ранних стадиях? RUP советует в начале каждой
вн-рацип создавать или пересматривать список главных рисков. Расположите эти
l'tn кн в порядке приоритета. Затем решите, за какие нужно взяться, обычно это
верные три-пять рисков. Например, список может выглядеть так:
• Риск 1. Исходя из имеющегося опыта, вас заботит, на основе имеющегося
опыта, что Департамент X не поймет, какие требования вы хотите реализовы-
нап>, и в результате потребует вносить изменения после выпуска бета-версии.
Риск 2. Вы не понимаете, как можно провести интеграцию с имеющейся сис-
1смой Y.
• Риск 3. У вас нет опыта в разработке на платформе Microsoft .NE T или в ис-
пользовании Rational Rose.
• Риск 4. ...и т. д.
А как использовать такой список рисков? Борьба с рисками
|о1жпа быть приоритетом для каждого участника проекта.
Проанализируйте, что вы обычно делаете в имеющейся
нк рации, а затем слегка измените план, чтобы заняться риска-
ми Как правило, риски, которые нужно устранять, возникают со
мши их сторон, в частности со стороны требований, проек-
тронапия и тестирования. По каждому направлению начинайте
। ипщего решения и последовательно детализируйте его с целью
уменьшения риска. Например, можно добавить следующие действия для сниже-
нии ранее выявленных рисков.
• Риск 1. При создании прецедента использования, относящегося к Департамен ту
X, согласуйте с ними прототип пользовательского интерфейса (U1). Проведите
совещание с Департаментом X и пройдитесь по каждому прецеденту использо-
вания, применяя прототип пользовательского интерфейса как «раскадровку».
11<>лучите формальное утверждение требований. На протяжении рабоз по про-
екту держите Департамент X в курсе дел и обеспечивайте их ранними прототи-
пами и альфа-релизами.
Внимание к рискам
должно исходить
с многих сторон,
в частности со
стороны требова-
ний, проектирова-
ния и тестирования.
60
Глава ?
Риск 2. Заставьте одно! о-двух опытных разработчиков создать действующий
проготип. который покажет, как проводить интеграцию с существующей сие
icMoii Y. Этот прото тип может быть одноразовым2, но он должен доказать воз
можность интеграции с сущест вующей системой. В ходе выполнения проект а
обеспечьте соответствующее тестирование интеграции с системой Y.
Ачьгернагивой может быть урезание проекта, чтобы не было необходимости
проводить интеграцию с системой Y. Такая стратегия называется «избегание
риска», и она, как правило, весьма эффективна. Заметим, что все прочие при
меры в пашем списке относятся к ст ратегии «снижение риска».
• Риск 3. Отправте несколько человек обучаться соответственно Microsoft .NE'I
и Rational Rose и найдите средства на то, чтобы пригласить наставника по Ra
lional Rose на первые три месяца фазы Проектирования на два дня в неделю
11аймите нового члена группы со знанием платформы .NET.
• Риск 4. ... и т. д.
Многие риски проекта связаны с его архитектурой. Вог почему главная цел:.
КНР на стадии Проектирования - получить правильную архитектуру. Для этою
iiiatio не только спроектировать архитектуру, но также реализовать и протес
шровать ее (более подробно об этом в разделе «Закладывайте основу исполни
Moii архитектуры как можно раньше»).
। hihvk рисков посюян-
hi ' меняется. Борьба
Нужно помнить об одной важной вещи: список рисков посте
янно меняется. Наступление па риски - это процесс
i рисками - это про- непрерывный. В каждой итерации вы сможете снизить или
песо непрерывный. устранить некоторые риски, а другие при этом возрасту!
и появятся новые.
Заключение
RUP обеспечивас! структурированный подход к ранней борьбе с рисками, чв>
। пн,кает общую стоимость и позволяет па ранних стадиях сделать реалистичную
п ючную оценку того, какое время требуется для выполнения проекта. Помните,
ио борьба с рисками - процесс динамический и постоянно продолжающийся.
1 -Одно[)азовый» прототип используется только для поиска какого-либо принципиального решения в отличие ы
лишюционирующих прототипов, которые развиваются в часть системы. - Примеч. науч. ред.
•Дух RUP» - ПУТЬ к УСПЕХУ
61
Обеспечьте выполнение требований заказчиков
Выполнение требований заказчиков - цель весьма очевидная, но как ее достиг-
ну и.? Паши рекомендации тесно связаны с итеративной разработкой, с постоянными
пйрашыми связями с заказчиками и с «подходом, основанным на Прецедентах ис-
HOHI.зования»3. Так что же такое прецеденты использования? Прецеденты использо-
№1Ним это способ фиксирования функциональных требований. Поскольку они опи-
il.iitnior, каким образом пользователь взаимодействует с системой, ему достаточно
прост о них рассказать. А поскольку взаимодействие описывается во временной по-
i псдовательности, то и для пользователей, и для аналитиков легче выявить «дыры»
и прецедентах использования. Прецедент использования можно рассматривать почти
кик раздел будущего руководства пользователя для разрабатываемой системы, только
пи пишется без знания о конкретном пользовательском интерфейсе. В прецеденте ис-
Ц|ин,зования не нужно документировать пользовательский интерфейс, вместо этого
иннсание прецедента использования дополняется прототипом пользовательского ин-
н’рфейса, например в форме снимков экрана (screenshot).
Многие люди научились любить прецеденты использования за их простоту
и способность облегчать быстрое достижение согласия с заинтересованными
i тропами о том, что система должна делать. Но это не главное их преимущество.
Мы считаем, главное в том, что они позволяют каждому члену группы работать в со-
к|11С1ствии с требованиями в ходе проектирования, реализации, тестирования и, на-
конец, написания руководств для пользователей (см. рис. 2.2). Прецеденты использо-
пниия заставляют концентрироваться наточке зрения пользователей и оценивать
in uiiiii и реализацию в соответствии с их требованиями. Они даже позволяют тща-
icui.iio рассмотреть нужды пользователей при планировании проекта и определении
рю । раниц.
I (оскольку прецеденты использования описывают, каким
пйразом пользователь будет взаимодействовать с системой,
иы можете использовать нотацию UML, в частности
aihii раммы последовательностей (sequence diagram)
н анаграммы кооперации (collaboration diagram), и показать,
кик ин взаимодействия будут реализованы элементами ва-
шей архитектуры. Также по прецеденту использования
Прецеденты использования
облегчают документирование
пользовательских требований
и помогают всем заинтересо-
ванным сторонам понять воз-
можности, которые должны
быть реализованы.
mi мою определить прецедент тестирования. Это гарантирует, что те свойства,
I За (юлес подробной информацией обращайтесь к Jacobson, 1992. - Примеч. авт.
62
Глава 2
Требования
Анализ и проектирован
Реализация
Тестирование
Рис.2.2. Как Прецеденты использования соотносятся с другими моделями программной инжс
нсрии. Прецеденты использования - высокоэффективное средство для фиксированнт
требований. Они также позволяют работать в близком соответствии с требованиями при
проектировании, реализации и тестировании, гарантируя выполнение требований
которые пользователь ожидает от системы, в действительности обеспечены. Посконь
ку прецеденты использования - это «руководства пользователя без знания пользой.!
тельского интерфейса», они являются мощной отправной точкой для создания полк
зовательской документации. При расстановке приоритетов среди реализуемых во;
можностей в процессе определения границ проекта производится выбор реализуй
мых прецедентов использования. И, как мы уже упоминали выше, прецеденты
использования позволяют работать в близком соответствии с требованиями на всем
протяжении цикла разработки.
Заключение
Прецеденты использования облегчают документирование пользовательски'
требований и помогают всем заинтересованным сторонам понять возможное!и
которые должны быть реализованы. Что более существенно, позволяют работа и
в близком соответствии с требованиями при проектировании, реализации и кч
гировании, гарантируя, тем самым, что вы не только продокументируете, ш
и обеспечите выполнение пользовательских требований. Вместе с итеративпмц
разработкой они помогут обеспечить выполнение требований заказчиков.
•Дух RUP» - ПУТЬ К УСПЕХУ
63
Сконцентрируйтесь на исполняемой программе
Этот третий главный принцип RUP имеет несколько аспектов. Во-первых, вы
должны по мере возможности измерять прогресс по исполняемой программе.
Отлично, если знаешь, что 10 из 20 Прецедентов использования описаны, но это
нс всегда означает, что 50% требований завершены. Позже может оказаться, что
половина этих прецедентов использования требует большой переработки, по-
скольку вы неверно поняли пользовательские требования? Это может означать,
что завершено только 25%, не так ли? Что действительно можно сказать по за-
вершению половины Прецедентов использования - это то, что сделано не более
М)%требований.
Вы всегда должны добиваться того, чтобы вам продемонстрировали работающую
программу
Лучший способ измерения прогресса - оценка того, какая часть программы гото-
иа и работает. Это позволяет проводить тестирование и на основе этих тестов и ста-
шстики ошибок оценивать действительно имеющееся продвижение. Когда обычный
разработчик заявляет, что он готов на 90%, следует сказать ему: «Отлично, но мо-
жешь ли ты показать готовую работающую демо-версию?» Это даст вам хорошее
представление о том, что действительно было сделано. Как архитектор, руководи-
1сль группы или менеджер, вы всегда должны добиваться, чтобы вам продемон-
щрировали работающую программу, рассмотреть покрытие ее тестами и их резуль-
1пгы и не впадать в ошибку из-за готовых документов, которые часто в действитель-
ности отсутствуют. Это не означает, что нужно игнорировать завершенные докумен-
H.I, но если рассматривать их изолированно, то это будет плохой показатель
прогресса.
Во-вторых, концентрация на исполняемой программе также вырабатывает
Первый взгляд на вещи в вашей группе. Меньше будет опасность излишнего анали-
III и теоретизирования, и работа будет сведена к проверке того, будет ли решение
А лучше решения В. Закрытие прений путем создания работающей программы -
но часто самый быстрый путь снижения риска.
Третий момент такого акцента на исполняемой программе - это то, что все
йргефакты, кроме работающей программы, - это вспомогательные арте-
факты. Они помогают вам создавать более хорошие программы. Скон-
центрировавшись на исполняемой программе, вы будете лучше подготовлены
к юму, чтобы решить, приведет ли создание других артефактов, таких как планы
64
Глава 2
\ правления требованиями, планы управления конфигурациями, прецеденты
использования, планы тестирования и т.д., к лучше работающей или более легкой
в обслуживании программе. Во многих случаях, но не во всех, ответом буде!
да». Нужно взвесить стоимость создания и обслуживания артефакта относи
1сльно выгоды его создания. Она как правило, возрастает с увеличением проекта,
с усложнением взаимосвязей заинтересованных сторон, с рассредоточением ва
шей группы, с увеличением проблем с качеством и с увеличением значимос ти
проекта для бизнеса. Все эти факторы направляют на создание большего числа
артефактов и на более формализованное обращение с ними. Но в каждом проекта-
нужно бороться за уменьшение числа создаваемых артефактов, чтобы снизить
общие расходы.
А спи вы сомневаетесь ХоРошее правило: если вы сомневаетесь, создавать артефаю
создавать артефакт или или ||ет’ не создавайте его. Но не используйте это правило как
ши, не создавайте его. оправдание пропуска важных задач, таких как подготовка
концепции (vision), документирование требований, проек
тирование и планирование тестов. Каждая из этих задач соч
дает артефакты, имеющие очевидную ценность. Однако если цена создания арте-
факта становится выше, чем окупаемость инвестиций (ROI), нужно ею
отбросить.
Одной из самых обычных ошибок пользователей RUP является создание артс
фактов просто потому, что в RUP описано, как их создавать. Помните, что RUP
но «шведский стол», и не очень мудро будет съесть все блюда на таком столе
(рис. 2.3.).
Заключение
Работающая программа- лучший индикатор действительного прогресса. При
оценке прогресса (насколько это возможно) смотрите, какой код готов и работаш
и какие тесты правильно выполняются. Концентрация на работающей программе
также позволяет минимизировать накладные расходы, создавая только те арте-
факты, которые добавляют ценности вашему проекту и которые стоит создавать.
До КНР» - ПУТ Ь К УСПЕХУ
65
ТЯ« 2.3. 1> ассма । рпвайic КНР как шведский с i огь д \ чши\ и раю инсскп\ мс юдов. 11с ешьте
все. спиде свои шооимыс о, но м in ко юрыс имев а емнк' i ыч в;н не; о конкрс! щи о проема
Приспосабливайтесь к изменениям с самого начала проекта
IВменение - это хорошо, далпе отломи. Ничему’.' Ноюму
что оолыпннсгво современных систем слишком и.то/ктто, чтобы
ми,г,к> было получить верные трсоования и дизайн прямо
> нерпой попытки. Изменения позволяют улучшать решения.
I । пт изменений не будет, то вы выпустите дефектное решение,
шнмо/кно, настолько дефектное, чю нрило/кеттис нс оудет имен,
никакой коммерческой ценности. Вот почему п\лтю ирлветет-
Соплеменные спае
мы шпиком сложны,
чнойы можно (1ыло по-
лу инь верные ipeCv-
вннпн н диЗс/йн прямо
с первой попытки.
ixuiaii, it поощрять изменения. А иiераiттвттын iit'iwi оттгимтнировап как раз тля
НП1 о
Но изменение может также имен. серы, них- ш>^ кдсшия. Постоянные тнмс
(в пня не дадут выпустить продукт. Исто; у.т.те ншн н "нечетнтй на iiih.tiiiix ста-
|пч\ проекта обычно ipi-oyiei он напои иерераоотihi при иом \ величивасiся
66
Глава :
стоимость, снижается качество и, возможно, возникают задержки, то есть вес
чего мы хотим избежать. Чтобы оптимизировать стратегию Управления измене
ниями, нужно понимать относительную стоимость внесения разных типов измс
нений на разных стадиях жизненного цикла проекта (рис. 2.4). Для простоты мн
разделили изменения на четыре категории.
• Стоимость изменения бизпес-решения. Для изменения бизнес-ре шенпя
нужна большая переработка требований, чтобы они удовлетворяли новым
пользователям или новому набору потребностей. На стадии Начало (Inception)
проект достаточно податлив к подобным изменениям, но с переходом к стадии
Проектирование (Elaboration) их стоимость увеличивается. Вот почему нужно
достигать соглашений по концепции системы на стадии Начало.
Рис. 2.4. Стоимость внесения изменений изменяется со стадиями жизненного цикла. Цена вне».
ния изменений изменяется в зависимости от фазы жизненного никла, и каждый тин изм.
нений имеет свой ценовой профиль. Вехи RUP в конце каждой фазы оптимизированы i ш
сведения к минимуму общей стоимости изменений при максимизации свободы их внеч
ния. По мере развития проекта нужно быть все более осторожным с внесением измен»
ний, особенно это касается изменений бизнсс-рсшений или архитектуры
• Стоимость изменения архитектуры. Следуя технологии RUP, вы сможен
малой ценой вносить весьма значительные архитектурные изменения до само
го конца фазы Проектирование. После этого существенные архитектурные и »
менения становятся все более дорогостоящими, поэтому архитектура должна
быть в основном определена к концу фазы Проектирования.
-Дух RUP» - путь к успеху 67
• Стоимость изменения проектных решений и реализации. Из-за компо-
нентно ориентированного подхода эти типы изменений, как правило, локали-
зованы, и, следовательно, их можно довольно малой ценой вносить на всем
протяжении фазы Построение. Однако стоимость таких изменений возрастает
в фазе Внедрения, поэтому в конце фазы Построения, как правило, произво-
дится «заморозка свойств».
• Стоимость сокращения границ проекта. Стоимость сокращения границ
проекта и, следовательно, откладывания реализации свойств до следующих
выпусков сравнительно невелика на всем протяжении проекта, если это дела-
ется в некоторых пределах. Сокращение границ проекта значительно облегча-
ется при итеративной разработке. Менеджерам проекта нужно использовать
его как ключевое средство обеспечения выпуска проекта вовремя.
Все эти размышления о стоимости означают, что необходимо управлять изме-
нениями. Вам понадобится: процедура утверждения вносимых изменений, воз-
можность оценить последствия изменения и надо будет снизить стоимость изме-
нения.
Утверждение изменений производится через комбинацию ручной процедуры,
щкой как совещание группы управления изменениями (Change Control Boards,
(СВ) и таких инструментов, как программные средства управления конфи-
1урациями и изменениями (Configuration and Change Management, ССМ). Оценка
последствия изменений производится в первую очередь через трассировку между
средствами управления требованиями, проектирования, создания кода и тес-
тирования. При изменении класса или требования вы должны понять, на какие
другие вещи это потенциально может повлиять. Именно здесь трассировка
убережет вас от многих неприятное гей.
Стоимость изменений минимизируется при наличии установленной проце-
дуры управления изменениями и при возможности оценки их последствий.
И опять же, правильно выбранный инструмент может дать огромный эффект.
Автоматическая синхронизация проектных решений и кода - это пример автома-
тизации, снижающей стоимость изменений, поскольку она позволяет делать не-
которые изменения кода, работая на более высоком уровне абстракции - на уров-
не дизайна.
3*
68
Глава
Заключение
HUP требует иметь согла-
шение по вопросу общей
концепции проекта к концу
фазы Начало, основу архи-
юктуры - к концу фазы
Проектирования, и «за-
мороженные свойства» -
к концу фазы Построение.
Стоимость изменений повышается с продвижением прост
та, и разные типы изменений имеют разные ценовьн
профили. Фазы RUP были созданы в целях минимизации
общей стоимости изменений при сохранении максималь
ной возможности их внесения. Вот почему использованш
правильных средств может сыграть значительную роль
в управлении изменениями и снижении их стоимости.
Закладывайте основу исполнимой архитектуры как можно раньше
Значительная часть рисков для проекта связана с архитектурой, особенно при
разработке приложения первого поколения. Вот почему архитектуру нужно делан,
правильно. Фактически способность создать стабильную функционирующую архи
гектуру (то есть спроекгировать, реализовать и протестировать ее) на ранних стали
ях проекта считается настолько важной для успеха проекта, что RUP рассматривав i
эго как самую главную цель фазы Проектирования, второй фазы нашего четырех
фазного процесса.
Что мы имеем в виду под архитектурой4? Архитектура включает в себя наибе
нее важные строительные блоки программной системы и их интерфейсы, то ecu.
подсистемы, интерфейсы подсистем и наиболее важные компоненты и их ин
юрфейсы (рис. 2.5). Архитектура образует скелет системы и содержит приблизи
1сльно от 10 до 20% всего объема кода. Архитектура также состоит из так назы
ваемых «архитектурных механизмов». Они представляют собой типовые реак-
ция типовых проблем, например, таких как сбор мусора (garbage collection) и дол
современное хранение (persistency). Создать правильную архитектуру сложно
поэтому для решения этой задачи, как правило, задействуются наиболее опытны
люди. Более подробно мы обсудим архитектуру в главах 7 и 16.
Наличие готового и должным образом протестированного скелета дает явное
понимание тех строительных блоков или компонентов, которые необходимы для
конечного продукта. Следуя итеративной технологии RUP, ваша группа уже
приобретет некоторый ценный опыт анализа, проектирования, реализации и тсс
шрования, поэтому вы будете четко понимать того, что нужно для завершения
4 Хорошее обсуждение этой темы приводится в Kruchten 2000а. - Примеч. авт.
-Ду< HUP» - ПУТЬ К УСПЕХУ
69
h>, 2.5. Архитектура системы. Архитектура обеспечивает понимание всей системы и составляет
скелет приложения. Она включает, помимо всего прочего, подсистемы и их интерфейсы
и наиболее общие компоненты и их интерфейсы
। in темы. Создание устойчивой исполнимой архитектуры также является основой
(юнее точной оценки объема необходимых ресурсов и времени, требуемого для
шнсршения проекта. Раннее понимание этого позволит оптимизировать профиль
ресурсов, управлять границами проекта и наилучшим образом решать свои дело-
вые задачи.
Рели архитектура готова, вы уже разрешили многие из наи-
(юнее сложных задач в построении системы. Теперь легче вво-
дил. в проект новых участников, границы дополнительного
вода заданы через определение ключевых компонентов и ин-
1ерфсйсов, архитектурные компоненты готовы к использова-
нию, предоставляя готовые решения типовых проблем.
Если архитектура готова,
вы уже разрешили мно-
гие из наиболее слож-
ных задач в построении
системы.
Заключение
Архитектура - это скелет системы. Проектируя, реализуя и тестируя архитек-
н ру на ранних стадиях проекта, вы боретесь с главными рисками и облегчаете
|цмсисние размеров своей группы и введение в нее менее опытных участников.
70
I лил
11 наконец, поскольку архитектура определяет строительные блоки или коме
петы системы, опа позволяет более точно оиенныяь еэтраты необходимые .
1.1 першения проекта.
Стройте систему из компонентов
Одним из аспект» функциональной декомпозиции-1 является го, что она »л >•
'1яст данные от функций. Одним из недостатков шкого разделения является .
'но обслуживание и модификация системы становятся дороже, Например, из-.,,
пение способа хранения данных может повлиять на множество функций, и, >.
правило, сложно определить, на какие именно (рис. 2 6). Эю главная прнчп...
почему так трудно было разрешить «проблему 2000 года».
С другой стороны, при разработке на основе компонентов данные и функш. 1
оперирующие с этими данными, инкапсулируются в компоненте Koi да нужно «
меннть данные, какие необходимо хранить, или io. каким образом данными пул .
манипулироват ь, эти изменения можно ограничить о/щим компонентом. Эго де.1 ><г ।
систему более устойчивой к изменениям (рис. 2.7). Компоненты можно реализован
с помощью объектно ориентированного подхода или другого метода, наприм>;
структурного программирования, и можно использовать в широком диапазоне с>г
• ем, включая переработку уже имеющихся, создание новых приложений или ы.
пуск пакетов.
Чтобы использоват ь компонент и, следовательно. пользоваться нрсимущесп -
мн всех ею возможностей и его кодом, вам нужно знать только интерфейс коми,
пента. Не нужно беспокоиться о его «внут ренней кухне». Еще лучше, компоне.и
может быть полностью переписан без всякого влияния па систему и ее код, ес и
интерфейс при этом не изменяется. Это важное свойство разработки на осно,
компонентов называется инкапсуляции Оно способствует легкости иовторн<)|.
использования компонентов.
!>. В функциональной декомпозиции сложные функции рекурсивно разбиваются на более мелкие и простые «."
пор, пока не будут получены функции, которые легко реализевагь Данные, также <;iделчюгся от функций, что •
танисимосы между функциями и дашилми по типу многне-ко-мшт;им o-uw- ж/.
“Дух RUP» - путь к успеху
71
Требования Требования Программные Общие
к системе к программе функции данные
Рис. 2.6. Архитектура с функциональной декомпозицией. Функциональная декомпозиция имеет
недостаток: изменение, например, способа хранения данных, может повлиять на многие функ-
ции. что приводит к тому, что систему становится очень трудно и дорого обслуживать
Требования
Требования
ксиыеме к программе
Мhoi оуровневая, основанная
на компонентах архитектура
i Rx
J ЙУ
jRz
Компоненты
домена
Компоненты
общего назначения
Рис. 2.7. Архитектура на основе компонентов. Разработка па основе компонентов приводит к по-
явлению системы, более устойчивой к изменениям в требованиях, технологии и данных
Компонент также может быть собран из других компонентов, что позволяет
ему иметь много дополнительных возможностей. Комбинация инкапсуляции
и больших компонентов радикально увеличивает продуктивность повторного ис-
пользования при разработке приложений.
72
Глав,'
Kt ^мпонентные технологии
’шляются также основой
разработок в области
Web-служб
Компонентные технологии являются также основой разраб.-
ток в области Web-служб, которые недавно были начаты вс,
ми основными производителями платформ на J2BK и .Ni I
л именно поэтому Web-службы вполне могут оказаться с и
дующим большим прорывом в области разработки программ
Коротко говоря, Web-службы - это интернет-компоненты. Как и все komfiohcihh
они имеют четко определенный ингерфейс. и пользоваться всеми их возможное ю
мп можно, просто зная эгог ингерфейс. Пока интерфейс не меняется, на вас нс ок.,
жу г влияние изменения в Web-с.тужбс. Главное отличие в гом, что взапмодействн ।
обычного компонента, как правило, ограничены компонентами. разработанными
।ля топ же самой платформы (а иногда компонентами, скомпилированными в ь п
же системе), а архитектура на основе Web-служб позволяет осущеегвля1ь взаим-
тействпе независимо 01 платформы через шиерфсисы компонентов в I йнерисГ
Заключение
Разработка на основе komhohchiob основываемся на принципе инкапсуляции
и позволяю создавать приложения, более усюнчивые к изменениям. Комнонеты
иноке дают возможность широко применя ть повторное использование, что позво
Biel быстрее создавать высококачественные приложения. Ike это может ради
кальпо снизить стоимость обслуживания системы. Компонентная lexnojioiiisi
основа Web-служб на плат формах J2K1- п .NPT.
Работайте вместе как одна команда
Люди - эю главный капитал проекта. Разработка программ становится ки
мандным видом спорта, и итеративный подход к разработке программ оказываю
пившие на способ организации команды, на образ общения внутри команды, пз
»редства, которые команде необходимы, и на ценность каждого члена команды
Юноше компании I радшнюпно многие компании имеют функциональную ст рут
itMcior функцио- iypy. вес аналитики находя!ся в одной группе, дизайнеры
н.п/тную структуру в другой, а юстировщики - в третьей, может быть, даже в друю-i
здании Хо1я такая opiапизация формирует центры компегенцш'
недостаток ее в юм. что эффективность общения между 'riiivn
ь I юнее подробная информация о Web- службах для пла1формы .NET дана в Thai 2001. - Примеч. авт.
Д,- HUP» - ПУГЬ К УСПЕХУ
73
Хуже функциональной
сгрукауры - огрук-
ьура мац/ичпая
||ч'мя группами нарушается. Например, спецификации требований, создаваемые ана-
иииками, не используются как входная информация разработчиками или тестиров-
щиками. Эго приводна к недопониманию, дополнительной работе п нарушению
I |н >1ч >в.
Хуже функциональной структуры -- структура матричная, где.
например, один аналитик одновременно работе? над нескольки-
ми разными проектами н реально не является полноправным чле-
ним команды. Эго ведет к тому, чт о людей - самый ценный капи-
тг1 проекта- начинают считаю взаимозаменяемыми частями.
Функциональная организация может быть приемлемой в долюерочных (18-ме-
। ичны.х и более) проектах на основе каскадной схемы. Однако при переходе
к шеративнои разработке и более коротким (9, или даже 2-3 месячным) проектам
И1тю\одимо более широкое общение между i ру ппамн. Для достижения ной цели
нт /мю:
• ор|анизова1Ь проекты на основе многофункциональных команд, включающих
аналитиков, разработчиков и тестировщиков;
• ооеснечить команды инструментами, необходимыми для ->ффек пня юг о взаи-
модействия при выполнении различных функций;
• сделать гак, чтобы члены команд имели позицию «Я сделаю, все что нужно
тая получения высококачественной работающе!) программы», а не «Я буду
телать свою небольшую часть цикла разработки».
Давайте теперь подробнее рассмофнм каждый из лих пунктов.
Команда проекта должна состоять из аналишков. разработчиков, тестировщи-
ков, менеджеров проекта, архитекторов и т.д. Вы можете сказан., что что работает
। ы небольших проектов, но что будет, если проект становится больше, скажем,
и нем будет задействовано 50 человек'? Ответ: необходимо осуществлять организа-
цию вокруг архитектуры7, создавать iруины, которые мы называем «команды
команд» (рис. 2.8). Должна быть команда архитекторов, коюрая создает архптек-
।\ру. Эта команда принимает решения по подсистемам и интерфейсам между ними.
Гнем, для каждой подсистемы должна быть создана монофункциональная комап-
1.1, состоящая из аналитиков, разработчиков и тестировщиков, которая будет рабо-
/ Ьонее подробная информация о том, как организовал, команду, и о прочих вопросах управления дана в Royce
Г ни Примеч. авг.
74
Глава
нпъ в тесном контакте, чтобы обеспечить широкое общение и быстрое принятие
решений. Эта команда общается с другими командами в первую очередь черс.
архитектуру и команду архитекторов.
Рис. 2.8. Организация команд вокруг архитектуры. Если проект слишком велик, чтобы обьединитг
всех в одну команду, организуйте команды вокруг архитектуры в «команду команд»
Команда архитекторов владеет подсистемами и их интерфейсами, а монофункциональ-
ная команда отведает за каждую из подсистем
Чтобы команда из аналитиков, разработчиков и тестировщиков работала
и тесном контакте, им требуется правильная инфраструктура. Нужно обеспечить
всех членов команды доступом к требованиям, дефектам, результатам тестирова-
ния и пр. Это в свою очередь потребует храпения требований в инструментарии,
используемом командой. Общение между разными членами команды должно
облегчаться интеграцией их инструментов. Помимо всего прочего, это также
повышает отдачу от вложений в инструменты, позволяя осуществлять цик
ипческую разработку и синхронизацию требований, элементов дизайна и тесто
пых артефактов.
Д,- HUP» - ПУТЬ К УСПРХУ
75
1акже нужно упростить процесс, то есть снизить насколько возможно объем
toio ментации. уменьшив таким образом затраты времени на ее создание и обслу-
♦ииание. Однако для этого будет нужно компенсировать ее значение для обще-
нии Один из способов - увеличить общение лицом-к-лицу. Попробуйте прово-
пи ь больше совещаний, поощрять прямое общение вместо общения по
нейронной почте и везде, где по возможно, размешать членов команды вместе
Совместная работа в одной команде также приводит к общей
ц||1С1ственности за конечный продукт. Нельзя уже будет сва-
'Шп. вину на другого в заявить: «.Эго твои требования были не-
1ИЫШ.1» или «В моем коле нет ошибок'/ Все разделяют ответ
11ценность за продукт и должны работать вместе и разрешать
CofiMeciiiasi работа
приводит к общей от-
ветственности за ко-
нечный продукт.
проблемы по мере из возникновения.
Заключение
Итеративный подход повышает потребность работать вместе как одна команда.
Ilioeraine функциональной структуры организации, используйте мноюфункцно-
1ыты1ые команды из специалистов по общим концепциям, аналитиков,
рц «работников и тестировщиков. Убедитесь, что инструментальная инфраструктура
ыитпечивает каждого члена т;оман.ды верной информацией и дает возможность ис-
нииьзовать синхронизацию и циклическую разработку артефактов но дисциплинам.
II наконец, обесиеш тс разделение сн вен гвенносгн между всеми членами команды
in результаты проекта.
Сделайте качество образом жизни, а не запоздалой идеей
< )дно из главных преимуществ итеративной разработки состоит в том, что она по-
топнет начать тестирование намного раньше, чем это возможно при использовании
1чикадиой схемы. Уже в первой фазе, фазе Начало (Inception), тестируется часть
функциональности, зафиксированная в прототипах, что обеспечивает полезную
oopainyio связь в ключевых прецедентах использования. Во второй фазе, Проек-
।iipoiiaiHic (ElaboiatioH), исполняемая цршрамма у же roiOKi и paooiaei. реализуя
нрхшекзуру (рис. 2.9). Эго • ।шачж."’. ч:о вы можете начать тесгвроваиие и проверить,
и Гм |акже Kwctiten 2000ч - Примечаю
76
Глава :
ч го архитектура действительно работает. Вы можете, например, провести для архи
юктуры тесты производительности и нагрузочные тесты. Получение ранней (вероя!
но, на третьей части пути к готовому продукту) обратной связи может привести
к значительной экономии времени и средств.
UML модель
и реализация
‘ И * ’ 11 1
| Итерация 1 н Итерация 2 !| Итерация 3 )| Итерация 4 |
Рис. 2.9. Тестирование начинается рано и расширяется с каждой последующей итерацией. RUP
способствует раннему тестированию. Программа собирается в каждой итерации и тсч
тируется после сборки. Регрессионное тестирование обеспечивает отсутствие внесении
новых дефектов при добавлении функций в последующих и терациях
Вообще говоря, RUP требует тестировать функциональные возможности
но мере их реализации. Поскольку наиболее важные возможности реализуются
на ранних стадиях проекта, к моменту, когда вы оказываетесь на завершающих
фазах, наиболее важные части программы уже готовы и работают в течение не
скольких месяцев и, скорее всего, в течение уже нескольких месяцев тес
шруются. Неудивительно, что в большинстве проектов, использующих RUP.
оказывается, что повышение качества - это первый видимый результат улучше
ним технологии.
•Дул HUP» - ПУТЬ К УСПЕХУ
77
1е ть еще одна возможность, которую мы называем «Качество от проектирова-
Нии». Это означает более тесную связь тестирования с дизайном. Если в процессе
проектирования вы учитываете, как система будет тестироваться, то это
шичптельно улучшит автоматизацию тестов, поскольку тестовый код можно бу-
нт генерировать прямо по моделям дизайна. Это экономит время, обеспечивает
ипмулы для более раннего тестирования и повышает качество тестирования,
уменьшая число ошибок в тестовых программах (в конце концов, тестовые
i крипты - это программы, и они обычно содержат массу дефектов, как и любая
нругая программа).
Итеративная разработка не только позволяет проводить
рйинее тестирование, она также заставляет тестировать
чище. С одной стороны, это хорошо, поскольку вы тестируе-
ir существующую программу (так называемое регрессион-
Итеративная разработка
заставляет проводить
тестирование раньше
и чаще.
цпе тестирование) и убеждаетесь в том, что новые ошибки не вносятся. С другой
। троны, недостаток в том, что регрессионное тестирование может стать дорого-
11ОИЩИМ. Чтобы минимизировать стоимость, постарайтесь автоматизировать как
можно больше тестов. Часто это помогает радикально снизить расходы.
11 наконец, качество - это то, что заботит каждого члена команды, и его нужно
нндавать во всех частях процесса. Нужно рецензировать артефакты по мере их
кидания, размышлять о том, как протестировать требования после их определе-
нии. проектировать с прицелом на тестируемость и т. д.
Заключение
Обеспечение высокого качества - это не только членство в группе тестиров-
щиков. Оно затрагивает всех членов команды и все части жизненного цикла
проекта. Используя итеративный подход, вы сможете проводить более раннее
нчпирование, а концепция «Качество от дизайна» позволяет дизайнерам автома-
Пппровать создание тестового кода для более раннего и высококачественного
нч । прования, снижая таким образом число дефектов в тестовом коде.
78
Глава г
Резюме
Мы изучили фундаментальные принципы, представляющие собой «дух RUP».
Их понимание облегчит правильное применение RUP. Не концентрируйтесь
на простом создании некоторого набора артефактов или выполнении некоторой’
набора задач, описанных в RUP. При таком подходе вы, скорее всего, потеряетесь
в широком разнообразии имеющихся задач и артефактов, предлагаемых в RUP
Вместо этого дайте «духу RUP» направить вас и применяйте только те задачи
и артефакты, которые лучше всего помогут вам придерживаться этих принципов
в вашем проекте.
Теперь, когда вы имеете представление о «духе RUP», перейдем к следующей
ыаве и рассмотрим, насколько RUP сравним с другими процессами, сколы."
итераций вам можсг понадобиться и какая с iепепь формализации вам нужна.
ГЛАВА 3
Сравнение технологий: RUP, гибкие методы
и тяжеловесные правительственные стандарты
В этой главе вы лучше узнаете о том, как нужно применять Rational Unified
1'iocess. Мы обсудим свойства подхода RUP и отличия его от:
• других гибких подходов, таких как Экстремальное программирование (Extreme
Programming, ХР)1, ScrumI 2, Динамический метод разработки систем (Dynamic
Systems Development Method, DSDM)3, Crystal4 и Адаптивная разработка (Adap-
tive Development)5;
• средств оценки процессов, таких как Модели зрелости процесса разработки
(Capability Maturity Models), Software Engineering Institute (SEI) (SEI CMM
и SEI CMMI) и ISO/IEC 155046;
• более тяжеловесных подходов к разработке, часто связываемых с такими
стандартами, как DOD-STD-2167a и MIL-STD-498.
Эти процессы и средства оценки процессов сравниваются с помощью «карты
процессов», имеющей два измерения: низкая формализованность/высокая формали-
юпанность и каскадный подход (схема водопада)/итеративный подход. Мы будем ис-
пользовать такую карту, чтобы понять, за что нужно бороться в смысле улучшений
I См. Beck 2000. - Примеч. авт.
7 См. Schwaber 2002. - Примеч. авт.
3 См. Stapleton 1998. - Примеч. авт.
4 См. Cockbum 2002. - Примеч. авт.
h См. Highsmith 2000. - Примеч. авт.
6 Международный стандарт оценки зрелости процессов создания программных средств. - Примеч. науч. ред.
I ГЛНП1 HUE ТЕХНОЛОГИИ ВСЯ’. ГИЬЬИЕ МЕТОДЫ »Т*гЖД1 ,О.Е еравидльственные стандарты 80
।(Апологии, чтобы примени।ь RUP с нужных! обьемом формальностей и с верным
дншнем и герагнвнос। и рюрабо!кн и 1побн техноов ия наилучншм образом соотво
( । н<шала ну ждам ваше <> нроо<|а п о|ч aiiirximui.
Как мы можем сравнивать процессы?
Мы даем процессам характерно шку па основе двух измерений, обсуждаемых
ниже н показываем их на нашей <• xapie процессов» (рис. 3.1).
• Низкая форма.ш ювзнпос 1 ь/высокая формализованное!ь7 откладываем i
но горизонтальной осн При низкой формализованности производится мини
му м служебной доку мен lamin. и в icxiie.ioi ни наблюдается минимум форм ।
1пзма. При высокой формализованноеiи служебная документация полна, под
тержниаеiся iрлсспрус«<к11. epi чфиюн. управление и щенениями (Chair >
( ontrol Boardsj и i. i
• Каскадный иодход/нгератнвнын подход откладывается но вертикально!!
оси. Каскадный подход но .пшейный подход с поздней интеграцией и тес
шрованием. I* icpai пвныи подход подход. управляемый рисками, с рашки
реализацией армнекыры. ранней ниici рацией и icciнрованием.
Гибкая разработка: низкая формализованность, итеративные подходы
I ибкая разраооим! n:i. 13 очеш, пои\ r>ipnoii. особенно среди отдельны'
p.i '.работников и небел i-а пи \ групп, и на популярность продолжает paciii
К । покпм подходам можно ornecin ХР, Scrum 11 адат нвпую разработку. Заметим
но мы намеренно не включили в итог список RUP: мы вернемся к нему почты
п > юй же главе.
'Ыишер Когберн (Ahsiaii 'лб-пел-; нжьтетч формализованность ((методологический вес» (Methodd*ч,
Cockburn 200?. С, 123) Прм » же
(И
Глава 3
j Карта процессов
| Каскадный подход
} Мало внимания рискам, последовательная разработка,
j поздняя nutip ш »и тонирование
j
। Низкая формализованное™
Документации немного,
процесс обленен
Sb-coxas: формализованное™ >
Хо^юшо документирован,
трассируемость, ССВ j
Итеративный подход
Направляется рисками,
непрерывная интеграция и тестирование
hr 3.1. Карта для сравнения процессов. Расположив процессы и средства их оценки но двум iu-
мсрениям - пизкая/высокая формачизованноегь и каскадный подход/итер.ативпый по.чхоч
вы можете сравнивать их и определять, какой наиболее соочвстствхег вашему проекту
и организации
Гибкая разработка в некоторой степени приносит
мрогость и формализованное™ в жертву гибкости и
ыюсобности адаптироваться к меняющейся деловой
(рсде. Она ставит создание работающей программы
ni.liнс создания подробной и полной документации. Од-
ной из главных доктрин гибкой разработки является не
Гибкая разработка в некоторой
степени приносит строгость
и формапизованность в жертву
гибкости и способности адап
тироваться к меняющейся депо-
ной среде
рдоога по строгому плану, а восприимчивость к изменениям, появляющимся по
мщу процесса. Это не означает, что планирование п документация не важны; они
просто не так важны, как обеспечение работы программы и адаптация планов
г реальности и меняющимся нуждам.
I Гшулярность ХР, Scrum, Crystal и адаптивной разработки выросла в конце де-
1Ш11ОСГЫХ, но они изначально основаны на лучшем практическом опыте, который
< \ шествует уже многие годы, в частности на итеративной разработке, непрерыв-
ной интеграции, концентрации на исполняемой программе, а не на побочных
продуктах, на регулярной переработке кода, на использовании стандартов ко-
шронания и на информации от пользователей. В качестве примера: итеративная
ршработка существует с середины 1980-х8гг, и уже многие годы компания Ratio-
I ^РАВНЕНИЕ ТЕХНОЛОГИЙ: RUP, ГИБКИЕ МЕТОДЫ И ТЯЖЕЛОВЕСНЫЕ ПРАВИТЕЛЬСТВЕННЫЕ СТАНДАРТЫ 82
ii.il Software активно продвигаетВ 9 итеративную разработку с концентрацией на
исполняемой программе, а не на побочных продуктах. Движение «За гибкую
разработку» проделало огромную работу по поддержке и популяризации этих
а\чших практических методов и предложило свои собственные, такие как
парное программирование (pair programming) и разработка «тестами вперед»
(ivst-first design), а также по снижению формализованное™, окружающей
ра (работку программного обеспечения, ставя главный акцент на программе, а не
на сопутствующих ей артефактах.
Пе/мятно, одним из наибо-
v1 ножных вкладов движе-
нии «За гибкую разработку»
чинимся принятие таких
мищеиций, как «процесс»
и «практические методы».
Вероятно, одним из наиболее важных вкладов движения
«За гибкую разработку» является принятие таких концеп-
ций, как «процесс» и «практические методы»10 11 темп
группами разработчиков, которые ранее осуждали их!
«Процесс» - это стало «круто», и разработчики признали
значимость обучения на опыте других.
Гак в какое же место на нашей карте процессов мы поместим гибкие процессы9
11а рис. 3.2 все гибкие процессы помещены в нижний левый квадрат, поскольку они
.шляются итеративными, низкоформализованными подходами, создающими мини-
мум документации.
11оскольку движение «За гибкую разработку» насчитывает только несколько
io, многие гибкие подходы являются новыми и непроверенными и предостав
1яюг не так много рекомендаций по практической реализации. Вследствие этого
многие организации затрачивают много усилий для эффективного применения
и их методов.
Некоторые гибкие процессы, такие как ХР, Scrum и Crystal ”, в настоящее
время используются в больших и сложных проектах. С увеличением размера
проекта для его успешного выполнения требуется все больше и больше инструк
ций. Если мы переведем это в нашу карту процессов, то будет видно, что исполь
вшапие гибких процессов для сложных проектов требует дополнительных указа
iniii и формализованное™, процесс при этом сдвигается вправо, что соответству
л высокой формализованное™.
В Гм. Boehm 1986. - Примеч. авт.
9 См. Booch 1996; Kruchten 1996- Примеч. авт.
К). В английском языке это называется «best practices» и подразумевает наилучшие практические методы
ра.|[)аботки. - Примеч. пер.
11 Crystal - это семейство процессов. На рис. 3.2 показано, где на карте располагается Crystal Lite, а стрелка
указывает положение более формализованных версий Crystal. Crystal - один из нескольких гибких процессов,
развивающихся в направлении более формализованных версий. - Примеч. авт.
пз
Г пава 3
Каскадный подход
Мало внимания рискам, последовательная разработка,
поздняя интеграция и тестирование
Низкая формализованное™ j
Документации немного, / Н
процесс облегчен / DSDM р
/ Адаптивная I
I разработка ss j
Crystal Ute /' j - С
\ XP / I
\ Scrum у
_ z Итерагивкий подход
Высокая формализованное™
Хорошо докуметирован,
тряссируемость, ССВ
Направляйся рисками, неотрывная ишнрация и геоирондние
№.3.2. Гибкие процессы па карте процессов. Гибкие процессы разрабшки >..|рактсризую1ся высо-
кой степенью тсрагивноетн, минимумом докумыпацтш г, формлли >;.:а. -iru дсласг их иде-
альными для небольших, не очень сложных о роек юн ! ккогорыс ! иб>.це процессы содержат
дополнительные указания для более сложных простои, что повышаю их форматом
8EIСММ, SEI CMMI, ISO/IEC, DOD-STD, MIL STD: тенденция к большей
формализованное™ для большей предсказуемости
Параллельно с движением «За гибкую разработку» существует тенденция
и направлении к более формализованному подходу « разрабод.е нршрамм.
h нон ориентации относятся средства оценки программ, такие как SEI СММ,
M l СММ1 и ISO/IEC, а также процессы, такие как DOD-STD и MIL-STD. Компа
нпп псе чаще рассматривают программное обеспечение как стратегическое вло-
жение и более не могут позволить себе непредсказуемость результатов, в смысле
перерасхода средств и проблем с качеством. В результате мипгчс организации
\(>сждаются в важности использования четко расписанною и тщательно доку-
минированного процесса разработки программ для обеспечения успеха своих
iipoi раммных проектов.
СГЛННЕНИЕ ТЕХНОЛОГИЙ: RUP, ГИБКИЕ МЕТОДЫ И ТЯЖЕЛОВЕСНЫЕ ПРАВИТЕЛЬСТВЕННЫЕ СТАНДАРТЫ 84
К характеристикам высокоформализованного проекта относятся следующие:
• подробные планы тщательно документируются;
• создается много артефактов, относящихся к управлению, требованиям, проек
। прованию и тестированию;
• артефакты, относящиеся к управлению, требованиям, проектированию и тес
гпрованию подробны, документированы и кладутся под средство контроля
версий;
• создаются и поддерживаются связи для трассировки требований, элементов
проектирования и тестовых артефактов;
• для изменений требуется одобрение Совета по управлению изменениями
(Change Control Board);
• результаты инспектирования аккуратно записываются и отслеживаются.
Кисот формализован- Высоко формализованные подходы лучше всего соответсг
uno подходы лучше всего вуют разработке сложных систем, большим командам
<чо!№тствуюгразработ- и распределенным командам. Такие подходы часто создаю!
л е I ложных систем, боль-
высококачественные легкие в обслуживании системы, но
шим командам и распре- J ’
цененным командам. стоимость их создания как правило выше, а время до выпус
ка в продажу больше, чем в случае низкоформализованных
подходов. Если время до выпуска -- главная забота, то высокоформализованные
по дходы могут в реальности привести к более низкому качеству, поскольку будо
просто не хватать времени на правильное выполнение работ, предписанных тех
оологией.
SEI СММ: средство оценки процессов
i мм - это не тех- Первое, что нужно понять компании в поисках лучшей предска
непчия, это сред- зуемости и более высокого качества - это насколько хороша
' имеющаяся технология и что нужно искать в будущем процессе.
чтобы достигнуть более высокого уровня зрелости. Модель
ipcnocти процесса разработки (Capability' Maturity Model)12, созданная в Software
I ni’.iiiccring Institute, разработана специально для этой цели. СММ - это не техно
1о|пя, а средство оценки, используемое для определения зрелости технологии
в ор> аиизации по пятибалльной шкале. СММ не скажет вам, как разрабатывая ь
программное обеспечение, для этого вам необходим процесс, например RUP, ХР
u ni MIL-STD-498.
I.' См. http://ww.sei.cmu.edu/cmm - Примеч. авт.
115
Глава 3
('ММ дает очень подробный обзор всего, что могло бы
(ш> необязательно должно; это зависит от специфики проекта
и организации) быть частью процесса разработки или допол-
нения программы в зрелой организации. К сожалению, мно-
। нс организации и СММ-оценщики интерпретируют это в
н>м смысле, что чем больше артефактов и задач используется
(приравнивание к высокой формализованное™), тем лучше
Прибавление к процессу
ненужных артефактов
и задач просто для того,
чтобы получить более
высокую оценку по шка-
ле SEI СММ, ведет
к перегрузке процесса.
процесс. Однако прибавление к процессу ненужных артефактов и задач просто
цпи того, чтобы получить более высокую оценку по шкале SEI СММ, ведет
и перегрузке процесса, который становится громоздким и неэффективным. Из-за
чрезмерного акцента на рецензировании, инспектированиях, традиционных
•плачах по оценке качества и подробном планировании СММ имеет нежелатель-
ный эффект, заключающийся в поощрении использования каскадного, а нс
нн-ративного подхода13, поскольку он не заставляет определять проблемы на ран-
них стадиях и проводить интеграцию и тестирование непрерывно.
8EICMMI: Средство оценки процессов
Ч тобы разрешить эту проблему, SEI была предложена SEI
( ММ114, которая более эффективно приспособлена к лучше-
му современному опыту, такому как проведение управляе-
мой рисками разработки и итеративный подход. Вместо по-
ощрения создания большей формализованное™ (как это Де-
нис гея в СММ), CMMI поощряет пользователей делать ак-
цент на отдельных областях для улучшений, которые лучше
SEI СММ! более эффек-
тивно приспособлена
к лучшему современно-
му опыту, такому как
проведение управляе-
мой рисками разработки
и итеративный подход.
иссго отвечают деловым целям организации и минимизируют присущие органи-
ШЦ1Н1 области риска. На рис. 3.3 показано, где на нашей карте процессов распола-
ННО1СЯ СММ и CMML
1.1 См. Royce 2002 - Примеч. авт.
14 См. http://www.sei.cmu.edu/cmmi/general/genl.html; CMMI - Capability Maturity Model Integration -
инициированная модель зрелости процесса разработки. Включает дополнительные дисциплины по сравнению с
СММ. - Примеч. науч. ред.
Сравнение технологий: RUP, гибкие методы и тяжеловесны!, правительственные стандарты
SEI СММ и SEI CMMI
Каскадный подход
Мало внимания рискам, последовательная разработка,
поздняя интеграция и тестирование
/' СММ 4
Низкая
формализованиость
Документации немнот о,
процесс облегчен
ХР, Scrum,
адаптивная разработка
I Высокая
z формализованиость
z Г Хорошо документирован, i
Ы трассируемое! ь, ССВ |
I i
Итеративный подход
Направляется рисками,
непрерывная интеграция и тестирование
Рис. 3.3. SET СММ и SEI СММТ на карте процессов. СММ и CMMI от SET пропагандируют выси
неформализованный подход к разработке программ СММ имеет небольшой ук.н’н
в сторону каскадной разработки, тогда как более новая CMMI - некоторый уклон в сюро
ну итеративной разработки
ISO/IEC15504: Средство оценки процессов
Как и CMMI, ISO/IEC
15504 - это средство,
которое оценивает зре-
лость программной тех-
нологии.
Как и CMMI, ISO/IEC 15504 - это средство, которое оценива
ет зрелость процесса разработки программного обеспеченна
по шкале от 1 до 6. Происходит оно от проекта Software Pro
cess Improvement and Capability Determination (SPICE). ISO
IEC 15504 имеет много сходств c SEI CMMI, включая сенег-
тивную оценку только тех областей проекта, которые имеют наибольшую цен
пость для организации. ISO/IEC 15504 можно поместить приблизительно на том
же месте нашей карты процессов, что и CMMI.
DOS-STD и MIL-STD: высокоформализованные процессы
К стандартам, обеспечивающим высокоформализованный подход к разрабоi м
программного обеспечения в целях уменьшения затрат и выполнения график.!
относятся DOD-STD-2167, DOD-STD-2167Л, MIL-S'I D-1521B и MIL-STD-49X
II/
me разработанные Министерством обороны Соединенных Штатов. Все эти стаи-
Tiipibi склоняют' пользователей к высокоформализованному подходу, за ис-
► |||о'|епием MIL-STD-498, в котором подчеркивается, что пользователи должны
• ощипать только те артефакты, которые необходимы для конкретного проекта.
Анюры стандартов 2167 и2167А внимательно разбирают некоторые трудности
i целью с самого начала избежать интерпретаций с точки зрения каскадного под-
мы.т, по, к сожалению, эти стандарты, как правило, объединяются с M1L-STD-
I'i.’IB, в котором, предписывается последовательность высокоформализовапных
рецензий (рецензия требований, предварительная рецензия дизайна, критическая
рецензия дизайна и т. д.), делать которые настолько дорого, что все, кроме каскад-
ною подхода, оказывается непрактичным. Стандарт MIL-STD-498 несколько бо-
лте открыт к использованию итеративной разработки, но все же не идет доста-
iii'iiio далеко (рис. 3.4). Интересно, что сейчас Министерство обороны поощряет
in пользование итеративной разработки.
( Стандарты Министерства обороны
Каскодный подход
Мачо внимания рискам, последовательная разработка,
поздняя nmol рация и тссгиронэние
DOD-STD-2167A
4 MIL-STD-1521B
Низкая
формализованность
। MIL-STD-498
' Высокая
'фармализовакностъ
Документации немного,
процесс облегчен
Хорошо докумшнировэн.’
грассируемссть ССВ
Итеративный подход
Направляется рисками,
непрерывная интеграция и тестирование.
hn.. 3.4. Различные военные стандарты разработки программного обеспечения па карте процес-
сов. DOD-STD-2167 n DOD-STD-2167A, объединенные с MIL-STD-1521B, предусматри-
вают’ высокоформализопапный подход к разработке нршрамм на основе каскадного под
хода. Стандарт MIL-STD-498 способствует несколько более итеративному полхплу
к разработке
гглннение технологий: RUP, ГИБКИЕ МЕТОДЫ и тяжеловесные правительственные стандарты
88
RUP: альтернативный подход с адаптируемым уровнем
формализованное™
ж </ /фигурации RUP
л»и у/ расположиться
ь /поОом месте шкалы
Ф рммизованности
Rational Unified Process - это настраиваемая технологнчсск.-ri
основа, позволяющая пользователям создавать широкое разш.
образце процессов, или конфигураций RIJP (см. гл. 10) '..Ъч
конфигурации могут расположиться в любом месте шкали
формализованное™ в зависимости от нужд проекта. На рис. 3
показано, где располагаются различные конфигурации RUP на карте процессов
KUP обеспечивает итеративный, направляемый рисками подход кразрабопч
программного обеспечения с непрерывным тестированием и интеграцией. Сунг,
окует, однако, некоторая гибкость и но оси каскадный/итеративный подход, и н-
коюрые компании используют RUP в манере, схожей е каскадным подходом
(мы против этого возражаем).
i Основа Rational Unified Process
’ Каскадный подход
| Мало внимания к рискам, последовательная разработка,
{ поздняя интеграция и тестирование
С’
Низкая
формализованность
i Документации немного,-
процесс облегчен^
Основа техноло
-Ии RUP
Легкая X /
А. конфигурация ) I
RUP / '
Средояя /
конфигурация ; (
Высокая
формализованное™
. .ф Хорошо документировав
Большая, трассируемое) ь, ССВ |
более формальная > '' I
конфит урация RUP J
Итеративный подход
Направляется рисками,
непрерывная интеграция и тестирование
Рис. 3.5. Конфигурации RUP на карте процессов. Основа RUP позволяет создавать разнооб;
иые конфигурации процессов: от очень низко- до очень высокоформализоваипых
09
Глава 3
Насколько все должно быть итеративным?
Среди лидеров программной индустрии13 существует достаточное единоду-
шие в вопросе поддержки преимуществ итеративной, управляемой рисками
р.пработки (многие из этих преимуществ подробно описаны в гл. 2). Использова-
ние такого подхода дает весьма значительную выгоду в более низкой стоимости
и ы>блюдепии графиков, чем использование каскадного подхода. Увеличивается
предсказуемость, что позволяет вовремя выявлять превышение стоимости
и нарушение сроков и позволяет урезать границы проекта, депая возможным вы-
ше i in ь хотя бы и ограниченный набор необходимых функций вовремя и в рам-
пах оюджета.
Чю мешает орюннзациям использовать высокоитератнвный, направляемый
рш ками подход с непрерывной интш рацией и тестированием? Знание дела,
шрошая технологическая и инструментальная поддержка.
1 Для неопытной команды может оказаться сложно использовать иысокоитера-
пшный подход. Такие команды, если они не имеют хорошей поддержки
к форме обучения, могут начать свой первый итеративный проект с экспери-
ментирования слить несколькими итерациями.
• I ребуется хорошая поддержка со стороны процесса, поскольку итеративная
разработка вводит множество новых задач, особенно для менеджеров проекта
и архитекторов. Процесс должен направлять этих и других членов группы
и юм, каким образом уменьшить основные риски на ранних стадиях, как вве-
i iii верную практику управления конфигурациями и изменениями и как с са-
мою начала создавать исполнимую архитектуру.
• Хорошая инструментальная поддержка также критична. Очень трудно вести
шеративную разработку без поддержки автоматизированного тестирования,
\ правления конфигурациями и изменениями. (В гл. 11, помимо прочего, обсу-
/г чается связь автоматизации и итеративной разработки.)
П< за преимуществ итеративной разработки, желательно, чтобы проекты pac-
in' i.ii алпсь как можно ниже по оси каскадный подход/птеративный подход. Одна-
может оказаться, что, чтобы попасть туда, группе будет необходимо
приоорести опыт, поддержку со стороны процесса RUP, а также улучшить свои
Hill ipyMCHTbl.
г. । м (нН) 1988, Boehm 1996, Highsmith 2000, McCormack2001.
ГШНгНИЕ: ТЕХНОЛОГ Ий: RUP, 1И13КИЕ МЫОДЫ И ГЯЖЫСШЕСНЫЕ ПРАВИТ ЕЛЬСТВИННЫГ. СТАНДАРТЫ 90
---------------------
Сколько понадобится формальностей?
Мы знаем, что итеративный, управляемый рисками подход более желак-лен
чем каскадный, и. следовательно, проекты должны располагаться в нижней пол"
I'.niie оси каскадный 1юдход/нтеративный подход Меньше определенности в н>м
। ic должен располагаться проект на оси формализованное! и.
В книге «Get Ready for Agile Methods, with Care»10 профессор Барри 1м> >>
(Barry Boehm) описывает, как потребность в быстрой адаптации к меияюиить ।
icjiobom среде можно соотносить с потребностью в предсказуемое гп и дпецип н,
не путем выбора верного уровня формализоианности, соответствующего ну-г i.r
проекта, (Гюэ.м использует термины «гибкий» (agile) и «днецинлииировапы ш
(disciplined), имея в виду приблизительно го же что и мы в терминах -пн
^формализованный» и «высокоформализованшяй».)
Кру/ ттюмасштабнач разработка, f>acp.pe-
j те пенная разработка, техническая слож-
ность прост и сложные взаимоотноше-
нии заинтересованных сторон - это фак-
торы, направляющие проект в сторону
т ’I итытюй формэлизованности
Факторы проект, говорящие г. пользу ыримоп-
пня низкоформализоваппого подхода - это ..
та в быстро меняющихся рыночных условия
близко расположенные небольшие группы и и
большая техническая сложность. Исгюльзов.нш
низкоформалнзованного подхода озиач.н
уменьшение объема документации по системе, в частности нс документирую г
и не отслеживаются изменения требований, дизайна и тестов. Ограничение до
ментации означает меньшее число необходимых обновлений при внесении п ог
нений, что приводит к экономии времени и снижению стоимости изменения. и
может оказаться очень важным для компании, работающей в быстро меняюпш
ся рыночных условиях.
Факторы, направляющие проект в сторону большей формализованности "
крупномасштабная разработка, распределенная разработка, техническая с ю
иость проекта и сложные взаимоотношения заинтересованных сторон. Для гш-
। их таких проектов отсутст вие необходимой документации может оказан
очень дорогостоящим, поскольку при этом невозможно эффективное обшепи.
и становится крайне сложно и дорого обслуживать технически сложные и
оольшие программные системы. 16
16. См. Boehm, 2002
Ul
Глава 3
Нужно заметить, чю в некоторых случаях правильная автоматизация может
принести те же преимущества, что и применение высоко-формализованного под-
мыл, без всяких расходов на документы. К примерам таких инструментальных
технологий можно отнести:
• < редства управления конфигурациями и изменениями, которые могут об-
легчить жизнь разработчиков и дать им «более легкую» технологию.
• Поддержку визуального моделирования, обеспечивающую синхронизацию
между требованиями, проектированием и реализацией. Также она известна
под названием «круговое проектирование» (round-trip engineering).
• Средства автоматического сбора результатов измерений17, которые облегчают
разработчикам создание отчетов, а менеджерам - анализ. * 11
Какой вид конфигураций RUP соответствует нуждам вашего процесса?
Исе, о чем мы говорили выше, приводит к постановке ряда важных для
определения необходимого вида конфигурации RUP вопросов: В каком месте
карты процессов должен располагаться проект? В какой степени должен исполь-
тонагься итеративный подход? Насколько формализованным должен быть
процесс? Чтобы ответить на эти вопросы, давайте рассмотрим четыре разных
проекта.
Проект «Деймос»: команда из одного человека
Проект «Деймос»’8 - это проект с участием одного человека, ко-
торый разрабатывает простое приложение при жестко установлен-
ном сроке в одну неделю (См. гл. 4).
Понижение на карте процессов: крайне малый размер, краткая
продолжительность и относительно небольшая сложность - все это указывает на
io. что в проекте должен использоваться чрезвычайно итеративный, гибкий
процесс (рис. 3.6).
11 Имеются в виду автоматическое вычисление метрик, характеризующих процесс разработки ПО, как например,
ыничества реализованных прецедентов использования или обнаруженных программных ошибок. - Примеч. науч.
ю/
III Но.тможно, проект назван гак по аналогии с известным проектом полета на Марс, который также назывался
Д|«м(х; и был разработан одним человеком, Филиппом Боно (Philip Bono). - Примеч. науч. ред.
( Сличение технологий: RUP, гибкие методы и тяжеловесные правительственные стандарты 5
Проект «Ганимед»: небольшой проект с плотным графиком
'Проект «Ганимед» — это проект, в котором участвуют четыре чело'
г\к ка, разрабатывающие основанное на базе данных централизованно
• бизнес-приложение. Команда работает в условиях жестких врсмго
ных ограничений и должна выпустить первую версию приложен
в течение трех месяцев. Что еще хуже, команда ожидает некоторых изменен'и
в проекте из-за быстро меняющихся деловых условий. К счастью, некотор' •,
чнепам команды приходилось создавать сходные системы ранее.
Положение на карте процессов: небольшой размер, жесткие времени ы
ограничения, меняющиеся требования, централизованная среда, позволяющая бы
про вводить исправления, и опытная команда - все это показывает, что в проел г
чолжен использоваться высоко-итеративный, гибкий процесс (рис. 3.6).
Проект «Марс»: проект среднего размера без опыта итеративной разработке
Проект «Марс» - это проект с 15 участниками, разрабатывающими
. . Web-приложение. Э го третье Web-приложение, которое эта кома:гы
I»' разрабатывает па платформе J2EE. Никто из членов команды не заии
мался итеративной разработкой, и финансирование на обучение ичн
\ частие консультанта в области итеративной разработки не предусмотрено. Гр.'. и
па использует очень простую инструментальную среду, включающую неслож
ную систему Управления конфигурациями и изменениями. Группе известно, чш
сие гема будет использоваться в течение нескольких лет, поэтому нужно создавши
устойчивую систему. Команда должна разработать систему в условиях жестки
временных ограничений, балансируя между построением легкой в обслуживают
системы и быстрым ее созданием.
Положение на карте процессов: проект среднего размера, а также баланс ж
жду скоростью и легкостью сопровождения указывает, что система должна р;и
полагаться где-то посередине на оси формализованное™. Принимая во внимать
жесткие временные рамки и необходимость создания правильной архитектуры
команда выиграла бы от использования высокоитеративного подхода, но отсу н i
пне опыта, обучения и консультанта, а также неадекватная инструменталы гы
среда указывают, что группа не сможет справиться со слишком многими
июрациями в этом своем первом итеративном проекте, (см. рис. 3.6).
03
Глава 3
Проект «Юпитер»: большой распределенный проект
Проект «Юпитер» - это большой проект со 150 участниками,
рпспределенный по трем местам на двух континентах (разница часо-
пых поясов в 11 часов осложняет общение). Взаимоотношения заин-
к’рссованных сторон весьма сложны, и некоторые лица требуют обеспечения
хорошей наблюдаемости проекта. В проекте будет разрабатываться вторая версия
н-хпически очень сложной системы. Систему нужно будет сопровождать многие
юлы. Кроме этого, особое внимание уделяется качеству. К счастью, есть несколь-
ко очень опытных членов команды, включая первоклассных менеджеров проекта
н । руппу архитекторов.
Положение на карте процессов: размер, техническая сложность, сложные от-
ношения заинтересованных сторон, долгосрочная система, забота о качестве
и опытная команда — все это указывает на то, что в проекте нужно использовать
нысокоитеративный и высокоформализованный процессы (рис. 3.6).
И®. З.в. Примеры проектов на карте процессов. Разные проекты, как это показано для этих че-
тырех RUP-проектов, требуют разных конфигураций процесса. Проект «Деймос» - про-
ект с одним участником и сроком в неделю, Проект «Ганимед» - небольшой проект с же-
сткими ограничениями по времени, Проект «Марс», проект среднего размера без опыта
итеративной разработки и Проект Юпитер, очень большой проект со сложными взаимо-
действиями заинтересованных сторон и сложной технологией
( ТЛВНЕНИЕ lEXHO/Wtll. RUP ГИБКИЕ МЕТОДЫ И i ЯЖЫЮВьСиЫЕ ПРАВИТЕЛЬСТВЕННЫЕ СТАНДАРТЫ
•м
Заключение
Многш проемы могут пользоваться преимуществами итеративного нид..-"
п использования конфигураций RUP, находящихся в нижней части оси каш п
пый/итеразивный подход. Для достижения этой цели jрунпа должна лриобрч ш
опыт итеративной разработки, иметь хорошую технологическую поддер,
обучение и шефство и усовершенствовать свою инструментальную среду. Bi.ii"
ды ci иерсАГда к итеративной разработке часто весьма существенны, по знаки,
дела, icxiiojiGi ическая п инструментальная поддержка являются ограничиваюшп
ми (факторами
Количество необходимых формальностей варьирует' от проекта к проекту. . ।
вися от размеров проекта, гслиичсской сложности, регулирующих и договоры,
условий, ав1омагизацин. времени жизни системы и распределения команды.
«Старая» школа совершенствования процесса кип
центрировалась ла смещении проекта в сторону больиг "
формализованное'™. Нежелательный побочный эффект mio
тих таких попыток, например MIL-STD-1521В и SEI СММ
заключался в (енденции направлять проекты в сторону к.г
кадныо подхода по причине дорогостоящего ипснектирою
ния и докуткшто-цептричсского подхода. Улучшение качества и предсказуемое ш
проис-ходили ценой шромною роста стоимости и неспособности быстро адан
тироваться к изменениям. Ьолее новые подходы, такие как SEI CMMI напр.тп
ляют группы в первую очередь в сюрону высокоформализованных подходов, с
ощряя при этом и итеративную разработку.
«Новая» школа совершенствования процесса концентрнруо
ся ла смещении проекта в сторону итеративного, направэ-.ь
мого рисками подхода с непрерывной интеграцией и io
тированном. Такое смещение дает много преимуществ »-
есть и недостаток -- необходимость дополнительны'
обучения и улучшения процесса и инструментальной сре.п
Многие, но не все проекты выиграют от небольшого передни
жения в сторону менее формализованного подхш.
к разработке. 1акс>й подход, как правило, снижает стоимость разработки, но можы
по крайней мере в более сложных проектах, стоить снижения качества. Тем не мен<
использование итеративного подхода, а также инвестирование в верную инструмеп
тальпую грело гложет битее чем скомпенсировать эту’ проблему. К «новой» ивы
шкила IV -
вершснствования про-
цесса концентрирова-
лась на смещении' i троем
/г/ в сторону бояыпей
формализованное!и.
«Новая» школа совершен
ствования процесса кон-
центрируется на смеще
нии проекта в сторону
итеративного, направляв
мого рисками подхода,
с непрерывной интеграци-
ей и тестированием.
95
Глава 3
ишершенствования процесса мы относим RUP и некоторые другие гибкие процес-
i ы, такие какХР, Scrum и адаптивную разработку. Командам, однако, следует думать
оптимальном положении на оси формализованности. Слишком большое смеще-
ние в сторону высокой формализованности может увеличить стоимость разработки
и снизить гибкость при довольно ограниченных приобретениях, тогда как слишком
большое приближение к низкой формализованности может вызвать проблемы
с качеством и общением, особенно в случае больших и сложных проектов.
Rational Unified Process - это технологическая основа, по-
шоляющая создавать настраиваемые конфигурации итератив-
ных, направляемых рисками процессов с непрерывной ин-
fо рацией и тестированием. Конфигурации RUP можно размес-
ти. почти в любом месте оси формализованности. Для каждо-
Н1 проекта сначала следует решить, где его нужно расположить
пи пой оси, а только потом настраивать продукт RUP.
Для каждого проекта .
сначала следует решить,
где его нужно располо-
жить на этой оси, а толь-
ко потом настраивать
продукт RUP.
При чтении этой книги и работе с продуктом RUP важно помнить о гибкости
й смысле положения на карте процессов, которую дает RUP. В главе 2 описыва-
лись базовые принципы RUP, которые применяются как для более гибких, так
II для более формализованных вариантов RUP. В главе 4 рассматривается чрез-
нычайно низкоформализованная и гибкая реализация Rational Unified Process.
Н главах 6-9 изучается RUP и соотношение высоко- и низкоформализованпого
Подхода к разработке, а в главах 10 и И рассказывается, как настраивать и реали-
ишывать продукт RUP, чтобы верно найти пропорцию между высокой и низкой
формализованностью.
Мы увидели, что RUP можно сконфигурировать под проекты с разнообразны-
ми размерами и требованиями. В следующей главе мы увидим, как это можно ис-
пользовать в самой простой реализации - проекте «Деймос».
I ЛАВА 4
RUP для команды из одного человека:
проект «Деймос»
Мы рассмотрели, какому месту на карте процессов соответствуют различи!.г
конфигурации RUP. Но как же использовать RUP? Перед тем как мы приступи ш
к подробному описанию фаз RUP и методам осуществления итератишюи
разработки, давайте изучим самую простую возможную реализацию - RUP .тн
мокшды из одного человека: проект «Деймос». Этот пример даст вам общи
представление об использовании процесса и лежащих в его основе нринщинч'
о позволит почувствовать итеративную разработку.
Для некоторых фраза «процесс разработки программного обеспечения» асс^
циируется с огромным количеством пыльных скоросшивателей, толстых мс ы
шческих пособий, инструкций и формуляров, пересыщенных администра!ш
пым жаргоном. Но все ото материалы, которые скорее используются в очет
больших компаниях, со скоростью улитки выпускающих программное оби
печение для правительственных организаций и самых богатых фирм. Тамг
программы разрабатываются целой армией программистов, сидящих в многочп'
тепных комнатах-ячейках и ведомых лысоватыми управляющими, как в знамени
I ых комиксах Скотта Адамса о Дплберте.
Целью процесса разработки программного обсспечсии <
не является сделать несчастной жизнь разработчики,
или раздавить творческий процесс огромной грмюи
бумажной работы. Его единственной реальной це n.i-
является обеспечение того, чтобы организация, запн
мающаяся разработкой программ, могла предсказуемы 1
Целью процесса разработки
и/ юграмк того обеспечения нс
является сделать несчастной
жизнь разработчиков или раз-
давить творческий процесс
огромной грудой бумажной
работок
НИР для команды из одного человека: проект «Деймос» 97
оьразом разрабатывать и выпускать высококачественные программы, соответст-
иукнцие всем нуждам и требованиям пользователей, вовремя и в рамках бюджета.
В этой главе мы увидим, что процесс разработки программного обеспечения
не должен быть таким ужасным. Мы объясним, как «дух RUP» (см. гл. 2) можно
применить к очень маленькому проекту. Мы будем следить за работой Ника -
придуманного нами инженера-программиста с 12-летним стажем работы
и разработке ПО. Хотя Ник предпочитает работать один, он сознательно
н добросовестно следует четко определенной технологии. Давайте заглянем
и дневник, который он вел в ходе работы над недельным проектом, который он
недавно выполнял для Гарри, своего старого друга.
Одиночный программный проект: проект «Деймос»
Первоначальная идея (вечер субботы)
('егодня вечером я встретил в нашем любимом баре моего друга
I арри. Он менеджер по разработке программ в небольшой компании.
11с|«>1 орые служащие его компании, пытаясь улучшить эффективность гл
и предсказуемость процесса разработки, в последнее время закончили
вурсы по Персональному процессу разработки программного обеспечения (Person-
ill Software Process)1. Но у Гарри есть проблема: главный элемент этого подхода со-
той г в том, что отдельные разработчики следят за временем, которое они
«припивают на выполнение каждого типа задач, таких как сбор требований, проек-
шрование, тестирование и администрирование. Каждый из разработчиков исполь-
iyei свою стратегию слежения, и конец недели, когда нужно собрать и консоли-
дировать данные, превращается в настоящий кошмар. Ассистент вынужден обхо-
ди и. всех, собирая все наклеенные где попало записки, электронные письма и голо-
юные сообщения, которые используют члены команды для оценки затрачиваемого
времени. Это огорчает, поскольку для организации, разрабатывающей ПО, точное
|цмерение затрат на разные задачи является ключевым для оценки продуктивности,
определения возможных областей для улучшений и, самое главное, для эффектив-
ною планирования будущих проектов.
I Humphrey 1997.
98
ГЛАВА -I
Я предложил Гарри попробовать автоматизировать утомительную работу по <>i
слеживанию трудозатрат. Разработчики могли бы иметь на экране небольшие таи
меры, которые они могли активировать, связывать с названием задачи, приостанан
пивать в период обеденного или какого-нибудь другого перерыва, продолжать но
окончанию перерыва и закрывать по завершению выполнения задачи. Эти данные
можно было бы хранить в безопасном месте, извлекать и сводить в таблицу в коши
недели. «Великолепная идея! — сказал Гарри. — Ник, не мог бы ты придумать таке»
утя меня? Это лизбавило бы меня от кучи трудностей и, следовательно, сэкономило
оы массу денег. Я заплачу, сколько захочешь. Ну, почти. Что тебе нужно, чтобы еде
п;п ь это?» Я сказал Гарри, что мне нужно подумать. На следующую неделю плапои
у меня не было, и, возможно, я мог бы придумать что-нибудь и за несколько часоп
11о я быстро исправился: «Хм, лучше я подумаю пару дней. Приходи ко мне в оф1 к
в понедельник около 11 часов, и у меня будет, что тебе предложить».
Предложение (утро понедельника)
Чю я буду создавать я думал о проекте таймера в воскресенье, утром у меня бы те
и сколько ресурсов его «мысленная концепция», а также две возможных идеи но
нобросить? реализации. Но это была серьезная бизнес-задача, поэтому мп,
нужно было серьезное экономическое обоснование. Что я буи
создавать и сколько ресурсов мне потребуется на это бросил ь'
Прежде всего это потребует от меня времени и, может быть, приобретения кое-
каких программ. И наконец, сколько денег я буду просить у Гарри? Так что сею
дня рано утром я появился в своем офисе, разобрался на своем столе и положие
не него четыре листа бумаги. В верхней части каждого я написал один из сле-
дующих заголовков:
• Концепция
• План
• Риски
• Экономическое обоснование
Концепция
Я начал с концепции (Vision). Мне нужно описать для Гарри и для себя, нк
я конкретно хочу получить, т. е. основную проблему, которую Гарри нужне,
решить, как будет выглядеть данный инструмент и как он будет использовал ы и
(рис. 4.1)
hili' для команды из одного человека: проект «Деймос;
99
Инструмент персональный таймер: концепция
Проблема
Для организации Гарри невозможность собирать согласующиеся данные о затратах времени на решение
различных задач разработки ПО препятствует сравнению реального хода проекта с планом,
правильной выписке счетов заказчикам, оплате труда работников и в конечном итоге
точной оценке трудоемкости будущих проектов
Формулировка концепции
Персональный таймер (Personal Timer Tool, РТТ), измеряющий затраты времени и сохраняющий эти данные
для последующей сортировки и извлечения (в отличие от произвольно составленных записей и смутных догадок)
легко позволит организации Гарри проводить систематические, согласованные измерения производимых
затрат, прослеживать действительные временные затраты в проекте относительно ожидаемых I
и лучше проводить работу по оценке объема работ для будущих проектов
\ Основные участники
| - Отдельные разработчики I
- Помощник по административной работе »
- Менеджеры проекта |
Прецеденты использования |
I ‘ Измерение времени для задачи
* - Еженедельное составление таблиц >
| - Объединение данных по проекту |
\ - Настройка инструмента и базы данных для проекта f
bfc.4.1. Создание концепции.
В плане я набросаю распорядок нескольких следующих дней, указав основные
мни: точки, в которых мне нужно будет принимать решения либо самому, либо,
чн» более вероятно, вместе с Гарри.
Сегодня во время обеда мне нужно будет придти к соглашению с Гарри по
Иоиросу дальнейшего продвижения и получить от него какое-нибудь обязательство,
||н/. ,s на начало выплат мне по этому проекту. Мне нужно будет согласовать с ним
концепцию, план и смету. Что касается меня самого, то мне нужно экономическое
нСюыювание (которое Гарри не увидит), в котором я определю, сколько времени мне
ну*но на завершение проекта. Если я сделаю все это - добьюсь утверждения общей
Концепции, плана и цены и обеспечу отсутствие денежных потерь - тогда я достигну
ШосП первой вехи, Вехи целей жизненного цикла, и подойду к концу фазы Начало.
Чтобы Гарри легче было проглотить пилюлю, а также, чтобы прикрыться,
fi ли у меня возникнут какие-нибудь непредвиденные трудности, я предложу, что-
бы он выполнил свои обязательства по оплате только при создании чернового
прототипа, который я покажу ему во вторник вечером. Только тогда, если ему
Поправится то, что он увидит (и если я буду уверен, что закончу проект в пятни-
цу). я попрошу его выполнить обязательства по всему проекту.
100
ГЛАНЛ !
План
Мне нужен черновой
пиан, в котором я рас-
пределю мое время по
нескольким фазам.
Сейчас только 9:30, поэтому я могу поработать над планом
Тяжелая артиллерия в виде программного обеспечения дчч
создания планов с использованием диаграмм Гантта (Gann
charts) не нужна, но мне нужен черновой план, в котором
я распределю мое время по нескольким фазам.
Набросав план на листе бумаги, я решил перенести его в мой карманный opi .1
пайзер (рис. 4.2).
Персональный таймер: план
I Понедельник,
; Начало
1 Концепция 1
План
Экономическое
обоснование
Риски
ЦЩ
одобрение от Г.
\ Проектирование
1 Прототип
। Вторник
'Прототип
^Уменьшение
I рисков
j
ад
одобрение от Г.
\ Прецеденты
Iиспользования
Песты
1 Среда
^Построение
^Проектирование
^Код
I Тест
Проектирование
Код
Тест
н Четверг р Пятница
Ь Проектирование н
Г Код
Тест ц
I i
I
IПРФ: показать I
। первую j
। бета-версию |
1 Выпуск I
(Улучшения г
I Окончательный !
....
Суббота
I ।
j Воскресенье;
Рис. 4.2. План.
Начало. Я работаю над этими задачами с раннего утра и рассчитып.и,
закончить сразу после обеда с Гарри. Если я получу обязательство заплати!!, и
демонстрационный прототип, тогда эта фаза будет представлять собой день ра<"
ты над проектом. Если он не согласится, то тогда мы закончим и останом, ч
хорошими друзьями.
Проектирование. Я думаю, что могу завершить эту фазу к обеду во вторшп
Я создам черновой прототип, который позволит мне усовершенствовать2 трс<„,
вания, решение и план, а также исследовать некоторые мои идеи. Затем я снопа
попрошу Гарри проверить все вместе со мной во время обеда. Прототип дасз и,
сколько возможностей.
2. Название фазы Elaboration (Проектирование) можно перевести также, как «развитие»
«усовершенствование». - Примеч. науч. ред.
full* для команды из одного человека: проект «Деймос;
101
• Показать Гарри что-то более конкретное, чтобы я имел лучшую обратную
связь с ним по вопросу требований (ну, вы знаете: «Я пойму, когда увижу»),
I !ока все что ему будет нужно для продолжения - это обсуждение за бокалом
светлого пива и кое-какие черновые планы.
• Что более важно для меня, я смогу проверить, есть ли у меня на моем жестком
диске все что нужно для выполнения этой работы, и выяснить не недооцени-
ваю ли я объем работ. Пока я брился сегодня утром, я думал, что у меня есть
идея об архитектуре и разных частях, которые я буду использовать, но сейчас
я уже не так уверен. Могу ли я использовать ту небольшую базу данных, ко-
юрую я применял в предыдущем проекте, и смогу ли я заставить ее взаимо-
действовать с апплетом Java? Куда я засунул руководство пользователя по
API? Будет ли все это работать в их операционной системе?
• Больше информации для создания более хорошего плана и более подробного
1 рафика.
• Отправную точку для построения чего-то реального с возможностью отбро-
сить все, что я сделал неправильно.
' Возможность освежить мои навыки в разработке баз данных, а также мой
пиль программирования на Java.
Я думаю, что этот важный обед во вторник будет вехой Архитектуры жизненно-
И1 цикла. К этому моменту и Гарри, и я будем иметь возможность отказаться от
нрискга, существенно переработать или спокойно продолжать его.
Построение. Я думаю, что если Гарри даст свое добро на продолжение,
подкрепленное бутылочкой прекрасного «Божоле», тогда в среду утром я начну
шидавать реальную программу чисто и аккуратно, тщательно тестируя ее. Потом
I Попрошу Гарри придти ко мне около 14 часов в четверг и привести с собой од-
ною из своих программистов, чтобы он попробовал ее на своем портативном
Ш1мныотере. Это даст мне еще полдня на устранение того, что мне не понравится.
Я думаю, что эта операция в четверг будет вехой Начальной функциональной
Нновпости, поскольку это будет первый раз, когда пользователь будет пробовать
Нрш рамму.
Выпуск. Это будет последний этап, и я надеюсь, что он займет всего несколь-
ко часов. Закончится он релизом, скорее всего, я отправлю им программу
Ни шсктронной почте вместе со своим счетом к концу делового дня в четверг.
102
Гллнл i
Список рисков
в список рисков я включу
все, что, может привести
к неудаче этого проекта,
к нарушению сроков или
выходу за рамки бюджета.
Я уже упоминал, что у меня есть несколько мыслей, вы и >
вающих беспокойство и сомнения. Не пряча голову в печи
я запишу их на листе бумаги под заголовком «Риски». Сю 11
я включу все, что, как я думаю, может привести к неуд.гн
этого небольшого проекта, к нарушению сроков или вых<> г.
за рамки бюджета. Писать этот список я буду карандашом, поскольку список pi к
ков всегда требует постоянной реорганизации и сортировки (рис. 4.3).
। Персональный таймер: риски
• Закончилась лицензия на нужные мне средства разработки
! • База данных стоит слишком дорого
i
। • Механизм обмена между узлами сети в организации Гарри не поддерживается
I • Машины некоторых программистов Гарри не соединены с сетью
Рис. 4.3. Оценка риска.
Экономическое обоснование
Сейчас 10:30, и у меня есть вся нужная мне информация для создания перш' {
начального экономического обоснования (Business Case), так что можно начап j
заполнять этот последний листи. Я уже подсчитал, что проект будет заним.т ।
ежедневно четыре часа моего времени. Мне может потребоваться обновлены J
компилятора Java и базы данных, так что я помечу эти пункты как «нужно ш.пь t
пить». Я думаю, что при моей загруженности и с небольшим запасом на устраы
пие ошибок, которое может потребоваться позже, это будет вполне реально.
Если Гарри будет плохо поддаваться, я могу даже создать убедительное <>(><>•
пование с его точки зрения. Если он сможет освободить полчаса в неделю па щ
кого разработчика, плюс два часа на ввод данных и подведение итогов для ы>
мощника по административной работе, то он вернет свои деньги менее -и м
за шесть месяцев (я даже думаю, что я мог бы продавать эту небольшую npoi рам
му другим по схеме раздела прибыли с Гарри, но этим я займусь в другой ра>
Времени мало).
ШН' дня команды из одного человека: проект «Деймос»
103
Архитектура
Поскольку Гарри еще не появился, я буду двигаться дальше. На пятом листе,
МШлавленном «Архитектура», я быстро нарисовал карандашом схему главных
MiMiioiicHTOB программы: Апплет Java, браузер, база данных и компонент из-
учения данных. Выглядит это так, как показано на рис. 4.4.
ЙИ 4.4. Примерный набросок архитектуры.
Iciicpb я добавлю пару других компонентов, используя UML. Поскольку схема
•Mi лидит интересно, а сам Гарри разбирается в программах, я покажу ему также
И но.
Обязательства
Короче говоря, Гарри все понравилось. За обед заплатил он. Я принес свои пять
ик( iob и карманный органайзер, и мы подписали все, пока ожидали главное блюдо.
104
ГЛАНЛ 4
Плохо то, что я неполностью понял требования. Гарри хочет, чтобы все сн
разработчики держали данные в одной базе, доступной через их локальную сен
Он не хочет, чтобы каждый держал данные в своей собственной базе, поскольм
их трудно объединять. Также они не всегда работают на одной и той же машшн
особенно когда проводят тестирование. Мы также сделали несколько друнп
поправок в требованиях, но это сетевое свойство вызвало у меня беспокойство
Оно влияет на мою архитектуру и требует гораздо больше настроек и тестеров,,
пня. Еще нам нужен администратор для обслуживания базы данных.
Так что более или менее быстро я подправил документы, подготовленны'
ним утром.
Концепция(Этап второй)
Я исправил концепцию, добавив упомянутое сетевое свойство. Также мы он
судили пару идей для дальнейшей разработки на которых можно сделать день, в
Хотя я и не хочу реализовывать их на этом этапе, они могут повлиять на нек<>
юрые проектные решения.
План (Этап второй)
Я решил не брать на себя слишком много. Чтобы свести к минимуму болыпоп
риск в архитектуре, я сдвинул веху АЖЦ (конец фазы Проектирования) ко времени
ужина во вторник. Я планирую выполнить Построение в течение двух дней за ды
итерации. В первой итерации, в среду, я протестирую «однопользовательскую
версию и удостоверюсь в том, что она работает хорошо, а в четверг разработаю клв
ент/серверное решение для сети и протестирую его. Это передвинет фазу Выпуск
на пятницу, а выход готового продукта- на вечер пятницы. Гарри также хочет, чтопы
я пришел к нему в офис в пятницу утром, проинсталлировал бета-версию и попробо
нал се там, где она будет работать (рис. 4.5).
Список рисков (Этап второй)
11ужно теперь добавить пять новых рисков (рис. 4.6).
Какой самый большой риск? Если все пойдет не так, я рискую туристически!!
поездкой, которую запланировал на этот уик-энд.
hili’ для команды из одного человека: проект «Деймос;
105
Персональный таймер: план, версия 2
[ Понедельник и
; Начало
| Концепция
/План
Экономическое
обоснование
Риски
цм
‘ одобрение от Г.
i
1
\ Проектирование
| Прототип
Вторник
Прототип
Уменьшение
рисков
i Среда
Построение
Однопользователь-
ская версия \
Дизайн
Код
Тест
Четверг
Построение
Клиент/Сервер
Дизайн
Код
Тест
Пятница
Выпуск
Улучшения
Суббота
Прецеденты
использования
Тесты
' ЛЖЦ одобрение от Г .
: Дизайн
Код
:Тест
Дизайн
Код
Тест
НФГ: показать
первую
бета-версию
Окончательный
выпуск
Воскресенье
I
hr, 4.5. Модифицированный план.
I Персональный таймер: риски, версия 2
\ • Синхронизация обновлений базы данных
; • Соответствие задач, проектов и пользователей на множестве машин
t • Политика прав доступа администратора и обычных пользователей
\ • Один и тот же пользователь соединяется с двух разных машин
j Каковы будут последствия?
| • Диалог у одного из пользователей по какой-то причине «зависает»
i и блокирует других пользователей _ __
Нс, 4.6. Оценка риска. Этап второй.
Экономическое обоснование (Этап второй)
Теперь мы говорим о полной рабочей неделе, поэтому я поднимаю свои рас-
цепки. Гарри окупит свои вложения только за восемь с половиной месяцев, но он
считает разумным заплатить мне две пятых всей суммы, если я достигну вехи
ЛЖЦ к вечеру вторника. Он обещает послать мне заказ на фазу Проектирование
кик только вернется в офис.
106
Глава 4
Работаем (вечер понедельника)
Вернувшись в свой офис, я начинаю более подробно разрабатывать два глав
пых прецедента использования:
• Хронометраж времени для задачи
• Учет
Я несколько расширяю их еще на два листа и на письменной доске строю
диаграмму последовательности.
У меня также начинает появляться представление о том, как я буду прост
шровать код апплета, используя три класса. Я делаю рисунок, изображающий ю
как таймер будет выглядеть на экране (рис. 4.7)
Рис. 4.7. Изображение интерфейса программы.
По мере продвижения, мне приходят в голову все новые и новые вопросы
и проблемы. Список задач заранее определен и статичен? (Скорее всего, nei )
Может ли каждый разработчик создавать новый список или же только исполню
вать имеющийся? Обратиться к Гарри я не могу, есть только его автоответчик, ч ат
что я записываю свои вопросы на завтра.
НОР для команды из одного человека: проект «Деймос»
107
1*ис. 4.8. Снимок экрана с готовым интерфейсом программы.
К утру у меня уже есть апплет (рис. 4.8).
Я также сделал запись в текстовый файл кое-каких данных для задачи
и протестировал все, что только смог придумать (в истинном стиле ХР). Неплохо
для одного дня работы.
Поднажмем (вторник)
Эго поистине тот день, когда холодный душ чередуется с горячим. Каждый раз,
ы>|да я вычеркиваю один риск из своего списка, я вынужден добавлять два новых.
Ссп)дня я сделал немало открытий. Я решил продолжать работу и в обеденное
премя. Я остался на работе и заказал пиццу, поскольку не могу связаться с базой
данных. Эта штука «зависает», поскольку моя версия базы данных слишком старая.
Л я еще недостаточно внимательно прочитал спецификацию API. Я потерял час,
общаясь со службой технической поддержки, потом скачивая нужную версию,
и потом изучая документацию.
Я недалеко продвинулся и начинаю уже думать, что вся эта затея никуда не го-
дится. Столько всего может пойти не так в таком смехотворно маленьком апплете!
Я, однако, построил UML-модель. Только одна диаграмма классов и две
диаграммы кооперации. Здесь же я построил диаграмму компонентов на основе
твоего рисунка архитектуры, который я теперь могу выбросить. Оставшиеся листы
и прикрепил на стену. Поскольку мой список рисков начинает выглядеть бес-
108
Глава 4
порядочно, я перенес его на компьютер в лист Excel. Я не изменял концепцию, но о
i еперь сопровождает 17 записей со всеми вопросами и проблемами. Я начинаю л<>
। >аилять ограничения, например такие:
• код будет работать в Windows NT или UNIX;
• база данных работает под Windows NT 4.0 и выше.
Когда к ужину появился Гарри со своим коллегой Эриком, я наносил последит
штрихи на не такой уж и бестолковый прототип. Все данные фиксированы, ecu
iojibko один пользователь («Гарри») и одна задача («Обдумывание»), И я смог «пл
негу» сделать расширение «приостановить-продолхсить» к прецеденту использовя
пня «Хронометраж времени для задачи». База данных работает на моем настольном
компьютере, а апплет - на моем портативном через сеть. Список рисков уменьши i
с я до нескольких простых случаев.
Мы погоняли прототип около пяти минут, после чего Эрик его «повесил». < hi
в шоке, но я объясняю, что надежность и полнота не были целью. Затем мы обс\
ждаем внешний вид и общее ощущение от апплета и несколько реорганизуем по
ня. Просматриваем мой список вопросов. Эрика очень заботит проблема потери
чанных, в случае если кому-то придется перезагружать компьютер в процесс
работы счетчика. Я обещаю рассмотреть это, хотя надеялся, что он скажи ।
и забудь». Наверное, мне не следовало касаться этого вопроса.
Заканчиваю добавлением пары рисков в мой список и еще полдюжины требо
вапий в концепцию, но все не так уж плохо. План я решаю оставить как ecu.
В концепцию я добавляю дополнительные прецеденты использования для Сш
।«много администрирования:
• Очистка базы данных
• Добавление пользователя
• Очистка списка задач
Хорошая новость: Гарри доволен увиденным и говорит, что надо продолжат
проект. Он не возражает и против ограничений.
Больше прогресс, больше изменений (среда)
Я нашел решение проблемы Эрика. Ура!
В процессе работы я помещаю весь свой код и тесты под контроль средства управ
нения конфигурациями, поскольку боюсь сделать ошибку и потерять контроль па i
изменениями. План простой - делать полный «снимок» каждой итерации.
WDP для команды из одного человека: проект «Деймос» 109
Гакже по прецедентам использования я делаю более полный набор тестов.
( ейчас я работаю над диалогом, предназначенным для извлечения данных,
нч сортировки и представления в таком виде, чтобы их можно было обрабатывать
й I xcel и делать красивые графики.
Около 11:30 позвонил Эрик. Он забыл одно требование: хеловек может рабо-
ниь более чем над одной задачей одновременно, и ему может быть необходимо
«мсп. одновременно несколько активных счетчиков.
Ой! Изменение концепции. Это может оказаться трудным, поэтому я вставляю
но в список рисков.
Почти закончил (четверг)
Тестирование. Работаю с сетью. Проблемы.
1лце раз согласовываю требования с Гарри, пытаясь обменять то новое, которое
Эрик обрушил на меня вчера, на другое, имеющееся у меня в списке. Мне все-таки
Н1чи)ется реализовывать свойство задача + проект, поскольку большинство людей
V Гарри работают над несколькими проектами одновременно.
11а основе прецедентов использования я начинаю создавать на HTML неболь-
шое Web-руководство для пользователей.
Мне нужно исправлять столько всяких мелочей, что нужна лучшая организован-
ное н>. Я делаю список, чтобы все это можно было отсортировать. Я объединяю
Imipocbi на изменения, полученные от Гарри и Эрика, и также добавляю несколько
илей но улучшению.
Опять тестирование. Для начала тестирую производительность. Без проблем.
1и1ем ввожу элемент параллелизма - попытка обновить базу данных одновремен-
но с двух машин. Плохо. Нужно опять серьезно продумать синхронизацию.
Ошибка: один и тот же пользователь с двух машин на одной задаче+проекте.
|1<>1сря одной записи.
11оздно ночью проблема решена. Теперь почти все работает.
1ета-версия и выпуск
V гром я отправляюсь в компанию Гарри со своей первой бета-версией. Мы ин-
шип пируем ее на нескольких машинах, я устанавливаю базу данных, провожу крат-
кую беседу с людьми, и они начинают работать. Я бегаю от одного к другому с блок-
1Н»н>м, записывая предложения по улучшению.
110
Глава и
Записываю в список ошибок две большие проблемы и 12 маленьких
(п<> большей части вкусовых предпочтений).
К обеду я опять в своем офисе. Исправляю все критические проблемы и ш
порпрую три мелкие. Сам нахожу еще четыре проблемы в основном путем систе-
матического тестирования. Наконец следующий релиз готов. В моей системе
Управления конфигурациями он имеет номер 0.9. Думается, что мне придется
пройти и через 0.91 и через 0.92. Начинаю приходить в отчаяние.
11оздно ночью делаю перерыв для написания нескольких комментариев
к продукту (Release Notes) и готовлю небольшую утилиту инсталляции. К часу
ночи я готов. Записываю CD-ROM и кричу «Есть версия 1.0!!»
Открываю светлое пиво (шампанского в холодильнике нет).
Кончено. Во всяком случае на этот раз.
Заключение
История о Нике и его проекте длиной в одну неделю показывает, что четки
определенный процесс можно применять и в очень маленьких проектах.
Ник следует «духу PUP» и при- Ника очень заботят риски, как технические (техноло
меняет только те части RUP, гические, языковые, интерфейсные и связанные с произно
коюрые важны в контексте его дительностью) так и деловые (график, накладные расходы
недельного проекта. ч _
и невыполненные ожидания). Он использует итеративнын
процесс с целью минимизировать эти риски, быстро проб}
ci идеи в целях их проверки, чтобы не загнать самого себя в угол, и для поддержашы
обратной связи с заказчиком. Он также составляет план с четко определенными вех.,
мн, хотя проект и будет длиться всего одну неделю.
У Ника есть простое экономическое обоснование для начала работ по проск
гу, где указана его реальная оценка как собственных расходов, так и потенциал!
пой выручки. Он пересматривает экономическое обоснование, когда обнаружив.!
с 1, что основные требования изменились.
Ник начинает проектирование с общей архитектуры, которую проверяв
очень рано. Он проводит более детальное проектирование в тех обласпо»
в которых решение не столь очевидно. Ник старается убедиться, что он подноси.в-
понимает нужды Гарри, и наоборот, пытается сделать так, чтобы Гарри точно пре i
ставлял, что он получит. Не хватаясь сразу за то, что, как он думает, нужно Гарри
Пик тратит некоторое время на то, чтобы записать требования, свойспы
Ill IP для команды из одного человека: проект «Деймос;
111
иограничения. После чего перепроверяет их несколько раз вместе с Гарри, чтобы
попять, что их концепция продукта одинакова.
11ик старается тратить время на задачи, имеющие наивысший приоритет,
и следит за тем, чтобы никакие проблемы не остались «за кадром» и не игнорирова-
лись слишком долго. Если с помощью теста обнаруживается проблема в продукте
пли если приходит Гарри с новым запросом или лучшей идеей, Ник фиксирует это
и виде запроса на изменение и осуществляет управление и расстановку приорите-
та в этих запросах в целях постоянного контроля над своим графиком.
11омимо кода продукта, Ник создает набор тестов, соответствующих многим
фсбованиям, и благодаря используемому им итеративному процессу многие тес-
ня - зрелые, уточненные и ставшие еще лучше за время работы над продуктом.
Чтобы избежать случайной потери кода (например, из-за аварии жесткого дис-
ки или из-за собственной ошибки), Ник использует простую стратегию управле-
ния программой, храня историю версий своих файлов и делая «снимки» версий
те гируемых наборов файлов. По этим версиям он следит за развитием програм-
мы и вносимыми изменениями, чтобы можно было вернуться к известной кон-
фигурации, если будет допущена ошибка.
И наконец, Ник пишет простую пользовательскую документацию
с разделом, описывающим данный релиз, процесс его инсталляции и известные
шрапичения, то есть с комментариями к релизу (Release notes), и с описанием
loin, как использовать продукт, то есть с руководством пользователя.
Гакова суть используемого Ником очень «легковесного» процесса разработки,
коюрый он с любовью называет своим «персональным унифицированным процес-
сом» (PUP). Это низкоформализованный процесс, концентрирующийся лишь на не-
большом количестве артефактов и побочных продуктов. Здесь нет огромных объемов
бумажной работы, поскольку многие артефакты хранятся в различных средствах
разработки: в средствах управления конфигурациями, в средствах проектирования,
й офисных программах и т.д. Эти несколько артефактов представляют ценность не
пыько для первоначальной разработки, но также и для дальнейших релизов. Если бы
I нрри вернулся через два месяца и попросил Ника разработать вторую версию, эти
прюфакгы снабдили бы Ника бесценными сведениями и помогли бы ему сделать
м нот раз все еще лучше. Они дадут ему важную оценку стоимости, часть проектных
решений или код для повторного использования, а также много практических уроков,
|о есть ошибок, повторения которые он теперь может избежать.
В следующих главах мы увидим, насколько это применимо к более серьезным
проектам.
ЧАСТЬ II
Жизненный цикл проекта в Rational Unified
Process
и
V
ГЛАВА 5
Через четыре фазы
Цикл разработки в RUP проходит через четыре фазы: Начало (Inception),
Проектирование (Elaboration), Построение (Construction) и Внедрение (Transi-
tion). Цикл завершается выпуском готового программного продукта. Что же вы
будете делать на каждой из четырех фаз RUP? Что происходит при Начале,
Проектировании, Построении, Внедрении? Чего вы стараетесь достигнуть в каж-
дой фазе? Какие создаются артефакты? Какие выполняются задачи? Следующие
•len.ipe главы дадут вам почувствовать динамику проекта RUP. Каждая глава по-
хищена одной фазе. Но прежде чем перейти к рассмотрению этих фаз, необходи-
мо предостеречь вас от ошибок.
Главное недопонимание
Разные фазы не являют-
ся переименованными
(для благозвучия или из
желания отличиться)
классическими фазами
каскадного процесса.
Хотя четыре фазы проекта RUP (Начало, Проектирование,
Построение и Внедрение) выполняются последовательно,
нужно постоянно помнить, что жизненный цикл RUP в осно-
Н своей итеративен и направляем рисками. Существует
Лнлыпое недопонимание,о которм мы хотим предупредить в
НМом начале нашего обсуждения: разные фазы не являются
переименованными (для благозвучия или из желания отличиться) классическими
фй1дми каскадного процесса. От практиков, впервые знакомящихся с RUP, мы часто
епышим: «Ага, я понял! В фазе Начало мы разрабатываем все требования, при
Проектировании создается высокоуровневый дизайн, входе Построения пишется
м»д, а при Внедрении завершается тестирование».
114
Глава
Пытаясь совместить RUP с имеющимся у них опытом, они полностью уп\ч
кают момент итеративной разработки. Да, в первые недели или месяцы рабоп-i
над проектом акцент, скорее всего, будет делаться на требованиях, а в последшк
недели или месяцы - больше на тестировании и шлифовке. Такое изменепш
фокуса на протяжении жизненного цикла указывается положением «горбов
на графике итераций жизненного цикла (см. рис. 1.3). Высота «горбов»изменяю
ся в ходе продвижения проекта. Но внутри каждой фазы планируются итерации
(см. гл. 12), а каждая из этих итераций включает множество задач по разраболы
программы, и в результате создается код в виде внутреннего, а позже и внешнею
релиза.
Главные вехи
Назначением фаз RUP, таким образом, не является разделение задач на типы
анализ, кодирование и т. п. (это достигается с помощью понятия дисциплин). 11а
значением фазы является выполнение как раз стольких задач, сколько нужно для
осуществления целей данной фазы к моменту достижения вехи, которая эти цели
завершает. А то, чего нужно достигнуть в каждой фазе, определяется главным
образом риском. Иными словами, фазы определяют состояние проекта, тогда как
состояния в свою очередь определяются конкретными рисками, с которыми веде н ч
борьба, или вопросами, на которые дается ответ.
• В фазе Начало (рис. 5.1) мы сконцентрируемся на работе с рисками, относя
щимися к экономическому обоснованию. Является ли проект прибыльным
с финансовой точки зрения? Является ли он реальным?
• В фазе Проектирование мы сконцентрируемся в основном на архитектурные
рисках и, может быть, еще раз обратимся к границам проекта, поскольку трс
бования теперь стали более понятны.
• В фазе Построение внимание переключится на «организационные» риски
и будет проделана большая часть работы. Это та фазы, на которой в проекп
задействуется больше всего персонала.
• В фазе Внедрение будет проводиться работа с рисками, связанными с логиков
выпуска продукта в пользовательское сообщество.
Эти главные вехи являются ключевыми точками принятия бизнес-решепип
по проекту, а главные решения нужно принимать по поводу продолжения pa6oi
над проектом, его границ, финансирования, стратегии, выпуска или графика.
'll 1'1:3 ЧЕТЫРЕ ФАЗЫ
115
Снижены ли
бизнес-риски?
Выполним ли
проект и выгоден ли он?
Уменьшены ли
организационные риски?
Достигли ли мы момента,
когда систему уже можно
использовать?
Можем ли мы выпустить
Уменьшены ли бета-версию?
технические риски?
Есть ли у нас подробный план
выполнения этого проекта?
Готовы ли мы к выпуску готового
надежного продукта?
Рис. 5.1. Главные вехи. Главные вехи RUP выражаются нс в каких-нибудь готовых артефактах или
документах, как во многих других методах, а в уменьшении рисков и в завершении про-
дукта
Также, поскольку эти фазы не связаны с одним типом ролей, проект RUP не
выполняется по принципу конвейера, когда команда аналитиков перебрасывает
1|>сбования через стенку группе проектировщиков, которые перебрасывают свой
дизайн разработчикам, те передают его тестировщикам, а последние оказываются
ишюваты во всем. Проект RUP - это сотрудничество всех этих людей, от бизнес-
шшлитиков до тестировщиков. Все роли RUP задействованы на протяжении
Польшей части цикла (за исключением, может быть, самого начала совершенно
Нового проекта).
Никаких фиксированных рабочих процессов
HUP не определяет фик-
сированный рабочий про-
нгкд, постоянный «рецепт»,
мранее определенный
набор задач, которые нужно
пнюлнять в каждой фазе.
Неизменными во всех проектах RUP остаются главные ве-
хи. То, что нужно получить в конце каждой фазы, должно
заботить всех членов команды. Но это не означает, что
в RUP существуют фиксированный рабочий процесс, по-
стоянный «рецепт», заранее определенный набор задач,
которые нужно выполнять в каждой фазе. RUP предлагает
пплитру возможностей, но именно контекст вашего проекта определяет, что
конкретно будет использоваться в ходе фазы для достижения ее целей. Контекст
может отличаться от одного цикла разработки или проекта к другому, и риски
116
Глава в
будут разные. Так что, с какого набора артефактов вы начнете, размеры проекы
его продолжительность, число вовлеченных сторон - все это сыграет свою рои
в определении, что конкретно нужно выполнять и какие артефакты нужно созди
вать или пересматривать.
Конечно, в RUP существуют некоторые общие фрагменты процесса, которьк
повторяются на протяжении жизненного цикла:
• задачи по запуску и закрытию проекта, фазы или итерации; и рецензирование
• задачи, относящиеся к деталям проектирования, кодирования, тестировании
и интегрирования программы;
• задачи, относящиеся к управлению конфигурациями, созданию релизов и упран
лению изменениями.
Все это, однако, является вспомогательным по отношению к тому, чего нужп.
достичь в данной конкретной фазе проекта.
Наихудшей является ситуация, когда команда пытается выполнить весь RI 'Г
слепо создавая все возможные артефакты и делая все задачи. Забыв о точной по i
гонке RUP к своему контексту, такая команда работает над очень дорогостоящи''
проектом, который очень рано станет перегруженным и рискует завершит ы и
провалом. Вы должны упростить RUP, чтобы он был настолько низкоформалнзо
ванным, насколько это соответствует вашему проекту (см. гл. 3 и 10).
Никаких «замороженных» артефактов
Существует искушение облегчить себе планирование или создать ощущешь
завершения или прогресса, попытавшись завершить артефакт RUP (модеш.
документ, код) в один прием, за одну фазу или даже за одну итерацию, и ы
морозить его. «Давайте создадим требования, подпишем их, и покончим с эт им
или «Дизайн теперь готов».
В целях фазы записано
не завершение артефак-
та, а выведение его на
нужный уровень зрело-
сти, чтобы иметь воз-
можность принять по
нему верное решение.
Нет ничего дурного в том, чтобы рано сделать совершенны'
работу и не иметь необходимости возвращаться к ней bihhu.
Хорошо, что некоторые артефакты становятся по мср>
продвижения стабильными. Но в целях фазы записано не .о
вершение артефакта, а выведение его на нужный уроиеш
зрелости, чтобы иметь возможность принять по нему всрн<н
решение. Когда проект развивается и становятся лучше и"
иятны его цели, когда обнаруживаются трудности и вносятся внешние изменении
артефакты нужно пересматривать, обновлять и исправлять. Следовательно, те ы
Hl РЕЗ ЧЕТЫРЕ ФАЗЫ
117
Дичи, которые уже выполнялись, нужно выполнять вновь. И если вы слишком
рппо зайдете слишком далеко в отшлифовке артефакта, позже это приведет
к большим переработкам.
Концепция и Экономическое обоснование будут разработаны в фазе Начало,
И, будем надеяться, останутся неизменными до конца цикла. Требования соз-
дшотся постепенно в ходе фаз Начало и Проектированиея, и завершить их нужно
К концу фазы Проектирование. Архитектура будет создана или избрана постепен-
но, и она должна к концу фазы Проектирование быть достаточно стабильной.
Но эти артефакты не являются чем-то священным и неприкосновенным. Возмож-
но, вам позже придется поменять Концепцию, сменить требования или изменить
•рхитектурный дизайн.
И, как мы уже говорили ранее, хотя все описанные в RUP арте-
фнкты потенциально могут сыграть какую-то роль в проекте, вам
Нс нужно создавать все артефакты. Более того, для некоторых
Не нужно созда-
вать в проекте
все артефакты.
Конкретных видов артефактов, например Прецедентов использования, одни мож-
но разрабатывать полностью, поскольку они очень тонкие и рискованные,
• другие могут оставаться в форме кратких описаний, поскольку они тривиальны
И сходны с существующими. Например, не все Прецеденты использования одина-
ково важны для успеха проекта, и можно принять решение не создавать полного
«писания незначительных.
Типы проектов
В следующих четырех главах, для того чтобы вам были лучше понять задачи,
Присутствующие на каждой фазе, мы будем использовать три различных проекта
Жир.
।
Проект «Ганимед», «зеленая»1 разработка небольшого приложе-
ния. Первоначальный цикл разработки совершенно нового прило-
жения, где все, включая требования, нужно делать с нуля.
11роект «Марс», «зеленая» разработка более крупной системы, что-
бы можно было подчеркнуть главное отличие от предыдущего
проекта.
I •Зеленая» разработка обозначает разработку нового приложения. Альтернативой такой разработки является
М/1Нвие новой версии существующего приложения («коричневая» разработка). - Примеч. авт.
118
Глава !>
• Проект «Юпитер», цикл развития существующего большою
приложения («версия 2.0»). Это более типичный представитель
большого числа RUP-проектов, в которых имеющаяся система раз
нивается, а не создается с нуля.
Типов проектов существует гораздо больше, их комбинации - бесконечны,
но данных трех типов должно хватить, чтобы дать вам представление о динамике
развития проекта RUP в его жизненном цикле.
Изучая четыре фазы, помните, что цель каждой фазы - достижение определен
пых ключевых вех. Эти вехи касаются уменьшения рисков и достижения конкрез
кого, объективного продвижения в направлении к высококачественному программ
пому обеспечению, а не просто завершения широкого диапазона артефактов.
ГЛАВА 6
Фаза Начало
В этой главе мы дадим вам базовые знания о том, что же представляет собой
Начало, первая фаза жизненного цикла RUP. Многие новички в RUP теряются
и богатом наборе предоставляемых RUP задач и руководств и часто не знают, чге
они хотят получить. Подход RUP на самом деле очень прост: добейтесь четкого
представления целей каждой из четырех фаз (рис. 6.1) и поймите, что эти
конкретные цели означают в вашей ситуации. Понимание того, что нужно еде-
на гь в фазе, поможет более эффективно применять подход RUP. Вы отберете
и выполните только те задачи, которые будут полезны для достижения целей
конкретною проекта.
i Проектирование
Построение Внедрение
Время
Веха целей Веха архитектуры
жизненного цикла жизненного цикла
Веха начальной
функциональной
готовности
Веха готового
продукта
Рис. 6.1. Фаза Начало. Начало - э го первая фаза жизненного цикла RUP. Она имеет четко опрел.>
ленные цели и завершается Вехой целей жизненного цикла. Ориентируйтесь на эти цел
и это поможет вам реши ть, какие задачи выполнять и какие артефакты создавать
120
ГЛАВА I'
Прежде чем приступить к изучению этой фазы,мы должны вспомни и
о нысокоформализованной и низко-формализованной разработке (см. гл. 3). Здесь мн
описываем такой подход к разработке программного обеспечения, который должен
помочь вам создавать более качественные программы, и показываем, какие типы
артефактов вам нужно создавать. Применяя эти руководства к своему проекту, вы
io гжпы решить, насколько формально вы хотите фиксировать артефакты: это можно
н-лать в уме, на письменной доске, в модели или документе. Насколько формалин •
ванным вы хотите видеть рецензирование? Мы постараемся указать наиболее очевн i
пые способы ускорить работу, если вы работаете с небольшим или низкоформали ю
ванным проектом, но в конце концов ничто не может заменить здравый смысл, и вы
ВП1ЖНЫ будете решить, что лучше всего подходит вашему конкретному проекту. Таг
же помните о том, что мы обсуждали в предыдущей главе относительно отсутствия
в КНР фиксированных рабочих процессов и избегания «замороженных» артефактов
Цели фазы Начало
/>'фазе Начало - Начало - это первая из четырех фаз жизненного цикла RUP. Она
на; о границах про- посвящена границам проекта и его целям, получению доем
емаицелях. точного количества информации, чтобы подтвердить продолжс
ние работ, или, возможно, убедиться в ненужности их проведс
ния. Пять главных целей фазы Начало таковы:
I Понять, что создавать. Определить концепцию, границы системы (то ecu.
то, что входит, а что не входит в нее); уточнить, кому нужна система и во чю
она обойдется.
.’ Выяснить ключевые функции системы. Решить, какие прецеденты исполь
зования (то есть способы использования системы) являются наиболо
критичными.
5 Выявить хотя бы одно возможное решение. Определить хотя бы одну во ',
можную архитектуру.
I Оценить стоимость, сроки и риски, связанные с проектом.
> Решить, какому процессу следовать и какие средства использовать.
Заметим, что номера целей не обозначают ни их приоритета, ни указании
на выполнение в определенном порядке. Совсем наоборот, работа со всеми целя
ми будет вестись параллельно. В этой главе мы опишем, как достигнуть каж/юн
и f пяти целей.
Фл 1л Начало
121
Фаза Начало и итерации
В большинстве проектов фаза Начало имеет только одну
терапию. Некоторым проектам, однако, для достижения целей
Может потребоваться более одной итерации (см. также гл. 12).
К причинам проведения нескольких итераций можно отнести
В большинстве про-
ектов фаза Начало
имеет только одну
итерацию.
i ||сдующие:
• проект велик и команде трудно понять границы системы;
• система не имеет аналогов, и трудно точно указать, что она должна делать;
• сеть множество заинтересованных сторон, их взаимоотношения сложны, как и их
контрактные соглашения;
• । рудно получить экономическое обоснование с первого раза или трудно опреде-
лить оптимальный баланс между границами проекта и требуемыми инвести-
циями. При создании новых коммерческих приложений часто все именно так
н бывает.
• существуют большие технические риски, которые нужно уменьшить при помощи
прототипа, или нужно создать «подтверждение концепции»1, прежде чем будет
получено «добро» от спонсоров. В частности, может понадобиться создать прото-
IIIH предполагаемой архитектуры, чтобы лучше оценить ее производительность,
стоимость и прочие характеристики.
I'.cjih у вас больше одной итерации, то первая итерация, как правило, кон-
цы 11 рируется на целях 1-3 (то есть на том, что создавать), тогда как оставшиеся-
и большей степени на целях 4 и 5 (на том, как создавать).
В трех наших учебных проектах, скорее всего, будет следующий набор
терапий.
• Проект «Ганимед», небольшой «зеленый» проект: поскольку прило-
жение невелико, вы в достаточно короткие сроки поймете, что нужно
создавать. Скорее всего, потребуется только одна итерация. I
• Проект «Марс», большой «зеленый» проект: поскольку приложение
более сложное, а вам никогда не приходилось создавать такие системы
ранее, нужно потратить какое-то время на получение одобрения всех М
заинтересованных сторон. Возможно, для фазы Начало потребуется
две итерации.
I "Подтверждение концепции» может иметь разную форму. Это может быть список применимых технологий,
нй6|хх:ок проектного решения или работающий прототип программы. - Примеч. науч. ред.
122
Гллнл I.
• Проект «Юпитер», второй этап большого проекта: вы начинать
с имеющейся системы, характеристики которой понятны, п у вас *ч и
представление о том, что нужно сделать в ее второй версии. У вас е* 11
некоторое количество прецедентов использования, расширяющих уже имеющие* *
пли полностью новых, и некоторые нефункциональные требования, а также p i ।
дефектов первой системы, которые нужно устранить. Необходимо все же со*-ы
вить список того, что нужно делать, чтобы не пропустить высокоприоритстнм
усовершенствований. Достаточно сделать одну итерацию, н эта итерация мот< ।
вероятно, оказаться несколько короче, чем большинство оставшихся итераюш
проекта.
Цель 1. Понять, что создавать
Может показаться странным, но это факт, что во многих проектах отсутствуем '"
шее понимание того, что нужно создавать. Хотя все члены команды могут думать,.
чип знают это, но часто один имеет совершенно другое представление, чем друн'и
I cjiii вы хотите преуспеть, все заинтересованные стороны должны придти к соглаш*
пню, что считать успехом. Нужно обеспечить, чтобы заказчики, менеджеры, ......
кп, разработчики, тестировщики, инженеры-технологи и прочие ответственные лю ш
* ч| ласплись между собой в том, какую систему строить.
I Согласовать высокоуровневую Концепцию.
’ Сформировать широкое, но неглубокое описание системы. Кратко опиши i*
что система должна делать, не вдаваясь в детали, в которых вы увязнете пли < *
которыми часть заинтересованных лиц, такие как заказчики и менеджерн
перестанут представлять то, что создается, поскольку ключевая информа...
потеряется в массе документации по требованиям.
i Составить подробные описания ключевых акгоров (actors) и прецеден кш
использования, чтобы все заинтересованные лица могли легко их пены и
а члены команды использовать как готовую вводную информацию для работы
Создайте документ «Концепция»
Согласно пункту А вы создаете документ «Концепция». Для очень неболыпи-
проектов это может быть неформальный документ, даже электронное письмо.
♦мл Начало
123
цн-ппего размера сначала можно написать Концепцию, содержащую несколько
и||иипц. Формат неважен, Концепция должна прояснить для заинтересованных
пироп следующие вещи:
• нозможности и преимущества, которые обеспечит создание приложения;
• нроблему(ы), решаемую приложением;
• к i<> будет конечным пользователем;
• 'ho продукт будет делать, на самом высоком уровне (Выражается в форме высо-
коуровневых свойств или обзора ключевых прецедентов использования);
• некоторые наиболее существенные нефункциональные требования, такие как
поддерживаемые операционные системы, базы данных, требуемая надежность,
масштабируемость и качество, а также лицензирование и расчет цены (если это
нижпо).
Концепция образует основу для общего понимания мотивов
Нин роения системы, а также высокоуровневое определение соз-
/ШНпемой системы. Концепция должна быть полной и стабильной
к концу фазы Начало, но вы будете продолжать совершенство-
Концепция образует
основу для общего
понимания системы.
Mi I. ее в ходе всего проекта, особенно в ходе Проектирования и начальных этанов
line।роения (при наличии существенного изменения границ проекта). Важно, что-
fii.i концепция была общедоступна, разделяема и постоянно рецензировалась, чтобы
ннкю не мог сказать, что не знает или не понимает ее. Широко используемое поня-
Н1г Техническое задание (Statement Of Work, SOW) в чем-то частично совпадает
к концепцией (подробнее см. гл. 15).
Создайте широкое, но неглубокое описание системы
В соответствии с пунктом В нужно предоставить хорошее описание границ
ни 1смы, не слишком вдаваясь в подробности. Для такого описания потребуется
И1.1Полнить две главные задачи.
• Определить и кратко описать акторов (actor). Выявите типичных пользовате-
iieii вашей системы и классифицируйте их на основе того, что они делают и каких
услуг они ожидают. Выявите также другие системы, с которыми будет взаимодей-
пвовать ваша система. Опишите эти типы пользователей и внешние системы как
акторов.
• Определить и кратко описать прецеденты использования. Определите и опи-
шите, каким образом каждый актор будет взаимодействовать с системой. Если
актором является человек, опишите типичные случаи использования актором
124
Глава (>
системы. Описание таких типичных взаимодействий с системой и называется
прецедентом использования.
/«' Фазе Начало для
большинства прецеден-
та использования дос-
1,но‘шо пары абзацев
। >ш;ания.
На этом этапе не слишком вдавайтесь в детали: для большин
ства прецедентов использования достаточно пары абзацев
описания. Однако можно потратить несколько больше времс
ни на прецеденты использования, которые вы считаете наибо
лее критичными (их должно быть не более 20% общею
количества), чтобы иметь твердое представление о них.
Устраивайте семинары или «мозговые штурмы»
Гак, как же создать такое широкое, но неглубокое описание? В случае малых
проектов можно на несколько часов собрать членов команды, заказчиков и, можо
ныть, других заинтересованных лиц, на «мозговой штурм». Для больших проекюп
можно провести двухдневный семинар с участием всех заин тересованных сторон
менеджера проекта, архитектора, ведущего разработчика, заказчика и пары анали
Юков. В ходе этого семинара выполняются приводимые ниже семь шагов. Заметим
чю выполнять эти шаги нужно итеративно, то есть возвращаться к ним несколько
раз на протяжении фазы Начало. Часто полезно выделить на каждый шаг фпк
т ированный объем времени. Как только время, отведенное на шаг истекает, перехо
ине к следующему, а к предыдущим возвращайтесь на более поздних этапах
' )iо не даст слишком увлечься одной проблемой, забыв, что нужно двигаться бо
и.ше вширь, чем вглубь. Заметим, что при наличии «мозговых штурмов» вы буден
ipaniTb меньше времени на каждый шаг, особенно на шаг 4. Заставьте люден
поработать над шагом 4 после «штурма», а затем проведите дополнительные
нс । речи, вернувшись к шагам 4-7 (подробнее см. гл. 15 раздел «Широкое ,
по неглубокое описание требований).
Шаг 1. Выявите как можно больше акторов (помните, что акторами мшу i
оы । ь как пользователи, так и внешние системы, с которыми данная система взап
модействует). В ходе фаз Начало и Проектирование вы уберете некоторых не
нужных акторов, объедините тех, которые имеют сходные нужды и добавите ы
"Minx. Создавайте описания акторов длиной в одну фразу.
Шаг 2. Свяжите каждого актора с прецедентами использования, фиксируй
взаимодействия его с системой в форме краткого описания прецедента исполь «>
нация.
Фаза Начало
125
Шаг 3. Для каждого из прецедентов использования определите, требуется ли
Нынмодеиствие с другими пользователями или системами. Это поможет выявить
дополнительных акторов. Продолжайте двигаться туда и сюда, обнаруживая
йк коров и прецеденты использования, пока не почувствуете, что выявили доста-
ючпо для понимания границ системы. Скорее всего, вы их все не собрали, но для
ной стадии и это достаточно хорошо.
Когда вы закончите с этими первыми тремя шагами, ваши результаты будут
выглядеть примерно так, как показано на диаграмме прецедентов использования
пи рис. 6.2.
Передача баланса
Управление ссудой
Менеджер по ссудам
Кассир
Запрос на ссуду
Изучение кредитной истории
Открытие счета
Одобрение большой транзакции финансовый менеджер
Вис. 6.2. Общий обзор системы: типы пользователей и их прецеденты использования. При прове-
дении семипара по прецедентам использования запишите (на письменной доске) группы
пользователей и системы (акторов), которые будут взаимодействовать с вашей системой,
и услуги (прецеденты использования), которые ваша система будет предоставлять этим
акторам
Шаг 4. Напишите один абзац описания для каждого актора и пару абзацев опи-
гйппя для каждого прецедента использования. Сделать это можно, временно рас-
пушив группу и дав каждому участнику два часа на описание, например, одного ак-
inpa и двух-трех прецедентов использования. Обеспечьте перекрытие, то есть дай-
if описать одного и того же актора и прецедент использования нескольким участни-
кпм. После этого снова соберите группу и проверьте все описания. При этом вы
гюлкнетесь с интересным явлением: хотя все будут согласны с названиями преце-
126
Глава в
дентов использования, у каждого будет своя интерпретация того, что повлечь
за собой данный прецедент использования. В детальных письменных описаниях
эти различные интерпретации будут ясно видны. Сравнивая их, вы сможете поня и.
нужно ли подумать о большем числе прецедентов использования, чтобы охвати и.
все необходимые функции.
Шаг 5. Создайте глоссарий, содержащий ключевые «элементы», которые ecu.
в приложении. Для приложения, связанного, например, со страхованием, вам попа
добится дать определения таким сущностям, как иски, разные типы полисов и г i
Также добавьте общую терминологию, е которой могут оказаться незнакомы члены
команды или заинтересованные лица. Такой глоссарий поможет согласовать общ) ю
терминологию, отсутствие которой часто является причиной сбоев в общении и нс
допонимания.
Шаг 6. Просмотрите ключевые элементы, с которыми имеет дело система
и убедитесь, что вы создали прецеденты использования, подробно опредс
ляющие, как каждый элемент создается, обслуживается и удаляется. Есть ли у в,к
прецедент использования, описывающий, как открывать полис? Как вносить m
менения в полис? Как отказываться от него? Это отличный способ нахождения
«дыр» в модели прецедентов использования.
Шаг 7. На этом этапе нужно выявить наиболее существенные или критичные
прецеденты использования (один или два, но не более 20% от общего их числа»
(см. раздел «Цель 2. Выяснить ключевые функции системы»).
Подробно опишите ключевые акторы и прецеденты использования
Еще один шаг к пониманию того, что нужно создавать, - это уточнение неко
торых прецедентов использования. К концу семинара или «мозгового штурма» вы
отдаете каждому аналитику один или несколько прецедентов использования, и он
описывает более детально наиболее существенные или критичные прецеденты in
пользования, выявленные в шаге 7. Как правило, будет создана пара страниц по ка
модему из прецедентов. Чем выше степень формализованное™, тем более подробно
описание, (подробнее см. лл. 15 раздел «Подробное описание акторов и прецедсн
тов использования»).
Параллельно нужно Параллельно с созданием описаний прецедентов использовании
такжеразрабаты- нужно также разрабатывать прототипы пользовательского пи
ватьпрототипы терфейса. Это позволит визуализировать ход событий, гарап
пользовательского
интерфейса тируя, что вы, пользователи и прочие заинтересованные липа
фллд Начало
127
Понимаете и соглашаетесь с ним (подробнее см. гл. 15 раздел «Разработка прого-
tuiioB пользовательского интерфейса»).
Нужно ограничивать время, отводимое на задачи, связанные с прецедентами
Использования, во избежание увязания в излишних деталях. Нужно также скон-
центрироваться на фиксировании наиболее существенного потока событий
И обратить внимание на существование альтернативных потоков событий
(Поскольку это поможет оценить, насколько сложно будет реализовать прецедент
использования), а не описывать детали всех событий.
Часто, особенно в малых проектах, один и тот же человек будет выполнять и роль
циплитика, и роль разработчика. Это означает, что тот, кто описывает прецедент ис-
пользования, будет также и реализовывать его. Если это так, вы захотите тратить
Меньше времени на документирование детальных требований, а потом возвращаться
к ним при реализации. Но все же не помешает выявлять альтернативные потоки со-
бытий, поскольку это будет полезно при определении объема оставшейся работы.
В трех наших учебных проектах команды делают следующее:
• Проект «Ганимед», небольшой «зеленый» проект: менеджер/архитск-
гор проекта тратит день на то, чтобы составить трехстраничный доку-
мент «Концепция». Команда тратит полдня на «мозговой штурм» для I
обдумывания первоначального набора акторов и прецедентов исполь-
зования. Выявлено тринадцать прецедентов использования, и каждый член коман-
ды берет 4—5 прецедентов и тратит 30 минут на детальное описание каждого из
них. Потом они собираются вместе и понимают, что им нужно еще четыре преце-
дента. Они объединяют два прецедента использования и убирают один. Еще два
часа уходят на описание каждого из четырех наиболее критичных прецедентов
(см. раздел «Цель 2. Выяснить главные функции системы»),
• Проект «Марс», большой «зеленый» проект: в ходе первой итерации
аналитики, привлекая, если нужно, основных заинтересованных лиц,
тратят около недели на создание первого варианта Концепции, зани- IVI
мающего восемь листов. Массу времени занимает получение одобре-
ния от всех заинтересованных лиц. Команда совместно с шестью заинтересован-
ными лицами тратит два дня на семинар по прецедентам использования, что по-
зволяет создать неплохой первый вариант модели прецедентов использования
и глоссарий. Во второй итерации Концепция совершенствуется, и совершенст во-
вание будет происходить и позже, особенно в фазе Проектирование. Тратится око-
ло четырех часов на описание восьми наиболее критичных прецедентов использо-
вания (см. раздел «Цель 2. Выяснить главные функции системы»). Вместе с этим
вносится несколько изменений в модель прецедентов использования.
128
ГЛАВА I,
’Проект «Юпитер», второй этап большого проекта: команда вноси ।
некоторые изменения в имеющуюся Концепцию, явно обозначая, чи
I'-' будет сделано в следующей версии. Это занимает один или два дн ।
Большая часть времени тратится на создание перечня дополнительных возможна
cieii, которые нужно реализовать, и известных проблем первой версии, которьи
нужно устранить. Команда пытается определить прецеденты использования, кп
горые требуется добавить, и наиболее критичные из этих новых прецедента
подробно описываются. На каждый уходит от двух до четырех часов. Перечж
ляются запланированные улучшения имеющихся прецедентов использован h i
но подробности этих улучшений на этой стадии, как правило, не описываются.
Цель 2. Выяснить ключевые функции системы
Камю изначально тра- Это вторая цель фазы Начало, и над ней нужно работать пос ь
шп, больше времени выявления прецедентов использования. Важно решить, каме
на наиболее кри- прецеденты наиболее существенны или важны с apxnici
ипные прецеденты „ ~ с
турнои точки зрения, чтобы изначально тратить больше врсм>
//< поимования. J
ни на наиболее критичные прецеденты.
11ад этой задачей должны совместно работать менеджер проекта и архитектор
привлекая (если это необходимо) другие заинтересованные стороны (например
ыказчика) и применяя для определения наиболее важных прецедентов исполью
нация ряд критериев.
1 Функциональность является ключевой для приложения или использм ।
ключевые интерфейсы системы и, следовательно, имеет огромное вли>.........
на архитектуру. Как правило, архитектор определяет такие прецеденты испои
зования путем анализа стратегии резервирования управления, рисков, связан
in.IX с конкуренцией за ресурсы, рисков производительности, CTpaieinn
безопасности данных и т.д. Например, в системе кассового терминала преш
депт использования «Подсчет стоимости и оплата» будет ключевым, посколы
он использует интерфейс с системой проверки кредитных карт и также ян и,
С1ся критичным с точки зрения производительности и нагрузки.
Функциональность обязательно должна быть реализована. Такая ф\ш
цпопальность определяет суть системы, и выпуск приложения без нее б\ и >
бессмысленным. Как правило, эксперты по предметной области и облашн
задачи знают, какая функциональность попадает в эту группу с точки зреии"
пользователя (главные действия, пиковая транзакция данных, критически'
Фаза Начало
129
управляющие транзакции и т.п.). Например, вы не можете выпустить систему
ввода заказов, если нельзя ввести заказ.
1 Функциональность охватывает область архитектуры, не охваченную ника-
ким другим критичным прецедентом использования. Чтобы обеспечить
обращение ко всем главным техническим рискам, нужно иметь достаточно
хорошее понимание всех областей системы. Если даже некоторая область
архитектуры, кажется, не создает особой опасности, опа может скрывать неожи-
данные технические трудности, которые можно выявить при проектировании,
реализации и тестировании части функций внутри этой области.
I !ункты А и С будут - в основном забота архи тектора. Менеджеры проекта будут
1м сцентрироваться, как правило, на пунктах А и В.
Для системы с 20 прецедентами использования критичными
iiOi.piiio являются З-Д2. В ходе фазы Начало важно осмыслить
w<(' выявленные критичные прецеденты и предоставить весьма
.'Ичальное их описание. Однако, можно отсрочить описание не-
шнорых альтернативных потоков событий до поздних стадий
Для системы с 20 пре-
цедентами использова-
ния действительно кри-
тичными обычно, яв-
ляются 3-4.
проекта, пока они не оказывают большого влияния па архитектуру. Критические
прецеденты использования перечисляются в Описании архитектуры программы
(Sollware Architecture Document, SAD. см. гл. 16).
В наших учебных проектах происходит следующее.
• Проект «Ганимед», небольшой «зеленый» проект: один и гот же чело-
век является архитектором и менеджером проекта, архитектор/менед- _
/кер проекта считает критичными 4 из 15 выявленных прецедентов ис- I
пользования. После обсуждения с заказчиком добавляется пятый прецедент. Архп-
।ектор/менеджер проекта собирает всю команду и тратит час на разъяснение того,
почему критичными являются именно эти прецеденты использования. Команда
соглашается с ним, возможно, внося изменения, и архитектор/мснеджер заппсыва-
с! критические прецеденты в SAD.
• 11роект «Марс», большой «зеленый» проект: архитектор предлагает
синеок, содержащий 8 наиболее архитектурно значимых прецедентов М х,
использования из 40, напрямую исходя из уменьшения технических М
рисков. Менеджер проекта предлагает набор из 9 наиболее критичных прецедеи-
Заметим, что для некоторых систем один или два прецедента использования могут составлять ядро
П|1И1111жения, а гораздо большее число "вспомогательных" прецедентов обеспечивают выполнение ключевых.
И iiiHiii ситуации архитектурно значимыми являются 20-30% прецедентов использования, и, как правило,
н|»ы>ди!ся реализовывать несколько сценариев для каждого ключевого прецедента. - Примеч. авт.
* 1
130
Глава i
гов заинтересованным лицам. Менеджер проекта хотел бы, чтобы «добро» на и
функциональность было получено как можно быстрее. Пять прецедентов ncim.ii.
зования перекрываются. После нескольких дней обсуждения этого архитектором и
менеджером проекта менеджер убирает 2 прецедента из списка (может возит
путь задержка в проекте пока будет получена обратная реакция пользователей И"
этому поводу). Архитектор находит способ снизить некоторые риски в 8 преш
дейтах использования с помощью некоторых прецедентов, которые были добан к
ны менеджером. В итоге они останавливаются на объединенном списке из 9 пр>
цедентов использования, которые архитектор помещает в SAD.
• Проект «Юпитер», второй этап большого проекта: масса времени
i/-yx\ будет потрачена па усовершенствование имеющихся прецедентов и.
I'-' пользования, что означает, что критичных прецедентов будет менып.
чем в «зеленом» проекте. Архитектор определяет один из имеющихся прецедсн
гои использования как критический, поскольку в нем задействуется иеисследовэн
пая новая технология. Архитектор т акже определяет 2 из 9 новых прецедентов т.п
архитектурно значимые. Менеджер проекта с точки зрения пользователя онре и
ляет еще один прецедент использования как критический. Архитектор заноси i i
критических прецедента использования в SAD.
Цель 3. Выявить хотя бы одно возможное решение
Vtxyimecb, что существует
возможная архитектура,
мнорая позволит построй 1ь
I чютему с разумной долей
риска за разумную цену.
Поскольку общей целью фазы Начало является опредс в
нис того, имеет ли смысл продолжать проект, нужно V"
диться, что существует’ по меньшей мере одна возможна ।
архитектура, которая позволит построить систем1,
с разумной долей риска за разумную цену. В качссш'
примера можно рассмотреть три варианта архитектуры клиент/сервер (см. рис. 6 < i
Анализируя желаемую функциональность (в первой версии, а также в будупш-
версиях приложения), совместимость с другими приложениями и требования к и .
плуатации и поддержке, можно понять, какие из этих трех вариантов жизнеспосо"
ны. Исследуя эти варианты, задайте себе следующие вопросы.
• Какие другие сходные системы вы создавали и какую технологию и архитекпр
использовали? Какова была стоимость?
• Существующая архитектура с точки зрения эволюции имеющейся системы, янт,
стся все еще удовлетворительной или ее нужно развивать?
Ф*и Начало
131
Тоньше клиент, толще сервер
Клиент А Г'............. i
| Приложение
г-----! (Объектно-реляционная
j | ( служба
‘ (Объектно-реляционное
( ядро
Клиент В (.............. 1
j Приложение
[ ( (Объектно-реляционная
служба
Клиенте J...........
" ' ( Браузер VWWV
ИНкереер! HTML (; HTML
Сервер бизнес-объектов
j
Сервер(ы) реляционной базы данных
Объектно-реляционный!
i ORB
! Объектно-реляционная,
I служба (
(Объектно- реляционная
служба
(Объектно-реляционное
ядро
Ml в.З. Три варианта архитектуры клиснт/ссрвер. В холе фазы Начало определите тип архи тек-
туры, которую вы хотите использовать, и создайте реализацию необходимых элементов
архитектуры, чтобы попять, с какими рисками вы столкнетесь. Здесь приводится три
варианта архитектуры клиснт/ссрвер. с совершенно разными требованиями к инструмен-
там, компетентности и сложности и с разными возможностями соответствия имеющимся
и будущим требованиям к функциональности и стоимости эксплуатации и поддержки
• Какие технологии вы должны будете использовать в системе? Нужно ли вам обза-
вестись новой технологией? Какая стоимость и какие риски связаны с этим?
• Какие программные компоненты требуются для системы (базы данных, промежу-
|очное программное обеспечение (middleware) и т.д.)? Можно ли их приобрести?
Можно ли их будет использовать в другом вашем проекте? Какова будет стои-
мость, связанные с этим риски?
В некоторых случаях может потребоваться приобрести или реализовать неко-
шрыс ключевые элементы архитектуры, или разных предполагаемых архитектур,
411>(>ы лучше понять риск с которым вы столкнетесь, и имеющиеся альтернативы.
Дач icx приложений, где для заинтересованных лиц может оказаться трудным пред-
> вшить себе конечный продукт, вам придется потратить какое-то время на реализа-
цию достаточно проработанных функциональных прототипов, для того чтобы под-
(иердить, что Концепция имеет смысл.
132
ГЛЛ! л I
/> конце фазы Начало у
н и: должно быть при-
мерное представление
о юм, с какими риска-
ми вы столкнетесь.
В конце фазы Начало вы должны иметь примерное представ в
ние о том, с какими рисками вы столкнетесь, особенно в об л.в
ти овладения технологиями и в плане повторного испольяч..
ния таких ценностей, как архитектурная основа, программны,
пакеты и т.п. В ходе фазы Проектирование вы можете соз ып
лучшую архитектуру, и это будет великолепно. Именно в фазе Проектирование ни
оудетс иметь дело с подавляющим большинством архитектурных и техно ы
। пческих рисков, которые вы выявили в фазе Начало.
В наших трех учебных проектах происходит следующее.
• Проект «Ганимед», небольшой «зеленый» проект: команда сози. .
функциональный прототип прецедента использования, признашнт
наиболее критичным. Функциональный прототип позволяет выяви о
некоторые ключевые архитектурные компоненты, в том числе те, которые пршв >
ся приобрести. Команда создает фрагменты функциональности, чтобы понять i .в
можно использовать новую технологию, что позволяет лучше представить, ч ю в-
обще можно создать.
• Проект «Марс», большой «зеленый проект»: команда в первой и ну.
irsx ции создает абстрактный прототип. Это облегчит общение мел. ।
командой и заказчиком, и команда лучше сможет зафиксировать im.i .
лания заказчика. Во второй итерации внимание будет сосредоточено в перв\ .
очередь на том, чтобы понять, какую использовать технологию, и какие с >пв.
связаны риски. Намечаются ключевые строительные блоки, и частично реализм .
ся пара критичных прецедентов использования, чтобы лучше понять, в пользу । ।
кой технологии сделать выбор.
• Проект «Юпитер», второй этап большого проекта: команда соз:i.i. .
опытные макеты двух критичных прецедентов использования из ..
тырех выявленных. Половина кода будет отброшена, но макет убсл ы
ет команду в том, что прецеденты использования реализовать возможно н пр.'
этом приобретается опыт работы с новыми технологиями, которые команда б\ i..
применять. Макеты демонстрируются заказчикам. Оценивается реакция а\ ш
тории, и выясняются ее ожидания.
ю
♦a ia Начало
133
Цель 4. Оценить стоимость, сроки и риски, связанные с проектом
Экономическое
обоснование описы-
вает экономическую
ценность продукта.
Попять что создавать -- это главное, но столь же критично
Йудсi определить как создавать и с какими затратами. Чтобы
Понять, нужно ли продолжать проект, требуется грубо прики-
ну и., в какую сумму он обойдется. Большая часть стоимости
(Низана с требуемыми ресурсами и с тем, сколько времени занимает выполнение
Проекта. Совместите это со знанием требуемой функциональности и ее ценности
дли заказчика, и вы сможете создать Экономическое обоснование проекта. Эко-
номическое обоснование описывает экономическую ценность продукта, выражая
Н в количественных единицах, таких, например, как окупаемость инвестиций
Itrlurn on investment, ROI). Экономическое обоснование - это инструмент для по-
лучения адекватного финансирования проекта. В нем также обрисовываются
|лл11пые еще не снятые риски и, следовательно, степень неопределенности, ос-
1и«нцейся в проекте.
Во многих организациях, особенно во внутренних ['[-подразделениях, бюджет
устанавливается еще до того, как проект попадает в подразделение. В гаком
улучае нужно определить, что можно выпустить в рамках установленного
Лю.чжета и сроков.
В организациях, разрабатывающих программное обеспечение с использова-
нием низкоформализованного подхода, экономическое обоснование может
Имен» форму короткой записи или сообщения по электронной почте, а в высо-
Ш»формализованных проектах требуется весьма обширное экономическое
Обоснование.
В грех наших учебных проектах происходит следующее.
• Проект «Ганимед», небольшой «зеленый» проект: менеджер/архитек-
к>р проекта пишет куратору проекта записку на двух страницах, вы-
полняющую роль экономического обоснования. Эта записка дает
спонсору информацию для определения ценности предполагаемых
инвестиций.
• I [роект «Марс», большой «зеленый» проект: менеджер проекта созда-
ci 8-страничное Экономическое обоснование и 12-страннчный План
разработки программного обеспечения (Software Development Plan,
SDP), указывая в нем планы проекта, список рисков и прочие ключевые управ-
ленческие артефакты. Менеджер проекта назначает обзорное совещание
с участием ключевых заинтересованных лиц, занимающее полдня и посвященное
134
Глл1 <
рецензированию Экономического обоснования, Списка рисков. Концепции и 11 ।
на разработки программы (см. ниже раздел «Рецензирование проекта. Веха цс г >
жизненного цикла»).
•Проект «Юпитер»: второй этап большого проекта: по сравнена
1Л\\ с первой версией приложения, разработка второй, как правило, свя '..in.
I'-' с меньшим деловым риском. Процесс применяется практически toi ।
самый, но следуют ему менее строго. Менеджер проекта пишет 4-страничное ' >ь
комическое обоснование и создает План разработки программы, в котором ука и ।
наст планы проекта, список рисков и прочие ключевые управленческие артеф.и
1ы. Менеджер проекта назначает двухчасовое обзорное совещание сучаспн
ключевых заинтересованных лиц, посвященное рецензированию Экономически
обоснования, списка рисков. Концепции, и Плана разработки программа
(см. ниже раздел «Рецензирование проекта: Веха целей жизненного цикла»).
Цель 5. Решить, какому процессу следовать и какие средства
использовать
(Хшзательно следует
уи/юстить процесс, что-
оы свести к минимуму
ненужные накладные
расходы.
Важно, чтобы члены команды имели общий вя ы'
на разработку программы, то есть на то, какому процсч
следовать. Обязательно следует упростить процесс, чин'»
свести к минимуму ненужные накладные расходы и убеди и
ся, что процесс направлен на специфические нужды ван» и
проекта. В небольших проектах принять решение о том, какому конкрсиь
процессу следовать, можно и на ходу, но в более крупных проектах необходим'
шранее потратить какое-то время на выбор процесса.
Идея в том, чтобы взять тот процесс и ту инструментальную среду, которы.
как вы считаете в первой итерации, работают. Процесс и инструменты разверн ।
каются во второй итерации и немедленно выясняется, что работает, а что ш ।
На основе полученной информации вы обновляете процесс и инструментально
среду, переносите их в следующую итерацию и продолжаете такой прою
до тех пор, пока среда не станет вас удовлетворять.
Во многих организациях выбор процесса доверяют «интуитивному чувству». ' l.i.
ю это заканчивается тем, что ведется борьба с симптомами, а не с причинами. I ор»
до лучше провести оценку вашей организации и понять, где вы находитесь ceiri.b
|дс вы хотите быть, и после этого решать, как оказаться в желаемой точке постепенна
В главе 10 мы опишем, как можно настроить R.UP на конкретные нужды своих iipi ।
Начало
135
fun н как создать прецедент разработки (development case) - должным образом на-
Цроепное руководство, описывающее, какие части RUP использовать и как.
Выбрав процесс, вы можете выбирать, какие использовать инструменты.
| некоторых случаях инструментальная среда может уже быть определена,
Щцример, корпоративным стандартом. Если это не так, тогда вам нужно выбрать,
Мкую интегрированную среду разработки (IDE), какое средство управления
Требованиями, средство визуального моделирования, средство управления кон-
фигурациями и изменениями и т.п. вы будете использовать. Как мы уже говорили
ранее, важно, чтобы эти инструменты могли автоматизировать выбранный
Процесс. Это может потребовать настройки инструментов и шаблонов, создания
|ирекюрий для проекта и т.д.
11ужно также и реализовать в проекте процесс и инструменты.(см. гл.11).
В наших трех примерах проектов происходи! следующее.
Проект «Ганимед», небольшой «зеленый» проект: команда собирает-
ся вместе и тратит час на согласование общего представления о том, _
как все должно работать. После совещания менеджер/архитектор про- I
скга создает Конфигурацию RUP, которая соответствует достигнуто-
му соглашению, и пишет одностраничный прецедент разработки для фазы Нача-
ло, очерчивая в нем, какие артефакты будет нужно создать, какие шаблоны ис-
пользовать и как документировать информацию. Подробное описание работы
па стадии Проектирование откладывается на начало стадии Проектирование, ме-
педжер/архитектор проекта, будучи более опытным, выполняет роль наставника
для остальных членов команды, помогая им применять процесс п инструменты.
Проект «Марс», большой «зеленый» проект: менеджер проекта
н архитектор некоторое время работают с наставником, который на- h x
правляет их при выборе процесса. Как только наставник поймет нуж- * * *
ды проекта, он потратит несколько дней на создание Конфигурации RUP и напи-
сание прецедента разработки для данного проекта. Прецедент разработки охваты-
вает весь проект (хотя фаза Начало описывается детальнее). Сделав это, наставник
использует этот прецедент для того, чтобы определить, чему обучать членов
команды.
• 11роект «Юпитер», второй этап большого проекта: большая часть чле-
нов команды участвовала в создании первой версии приложения. Они 1/Э Х
пыли довольны процессом и инструментальной средой, но внесли не-
сколько предложений, которые были записаны в конце предыдущего проекта.
' )гп предложения теперь реализуются и передаются команде.
136
Глл 1
Рецензирование проекта. Веха целей жизненного цикла
В конце фазы Начало располагается первая из главных вех (контрольпн
1очск) проекта, называемая Вехой целей жизненного цикла (Lifecycle Objci i
Milestone). В этой точке вы проверяете цели жизненного цикла проекта. I < ।
проект не может удовлетворить критерии контрольной точки, от него следуем -
казаться или пересмотреть его. Если проект обречен на неудачу, лучше это поп п
раньше, чем позже, и итеративный подход вкупе с этой вехой могут способен '
вагь такому раннему прозрению. Рецензия для Вехи целей жизненного цш .
включает оценку следующих моментов:
• согласие заинтересованных сторон по вопросу определения границ прог,
и первоначальной оценки его стоимости/сроков (которая будет уточняться в <и к
поздних фазах);
• согласие в том, что зафиксирован верный набор требований и существует очи
точка зрения па эти требования;
• согласие в том, что оценка стоимости/сроков, приоритеты, риски и процесс ра у
ботки приемлемы;
• согласие в том, что были выявлены первоначальные риски и существует стран п
борьбы с каждым из них.
Можно отказаться от проекта или пересмотреть его, если он не может дек ни
путь этой вехи.
Заключение
Начало - это первая из четырех фаз жизненного цикла R.UP. Она, во<»'1п
говоря, полностью посвящена пониманию проекта и получению достаточной
количества информации для обоснования того, что проект нужно продола.п
(или, возможно, что этого делать не следует). Все это можно перевести в пян.
повных целей.
• Понять, что создавать.
• Определить ключевую функциональность.
• Выявить хотя бы одно возможное решение.
• Выяснить стоимость, сроки и риски, связанные с проектом.
• Решить, какому процессу следовать и какие средства использовать.
♦» 1л Начало
137
( концентрировавшись на этих целях, вы сможете не затеряться в большом на-
варе задач и руководств, предоставляемых в RUP. Используйте эти руководства,
tioni.i достигнуть целей и избежать распространенных ошибок. Применяйте
руководство, которое мы даем в главе 3, и оно будет направлять вас в определе-
нии loro, насколько формализованным должен быть ваш проект. Не пытайтесь
йнданать все артефакты RUP, сконцентрируйтесь на тех, которые помогут вам
|/ц>с1Нженин ваших целей.
ГЛАВА 7
Фаза Проектирование
В фазе Проектирован,
осуществляется боры
с основными рисками
создается начальный
архитектурный каркас
системы, совершенст
вуются и развивают
планы проекта.
В этой главе дается общее введение в Проектирование (Elaboi.i
tion), вторую фазу жизненного цикла в RUP. Именно в этой фл
становятся наиболее очевидными различия итеративного и к.и
кадного подходов. В частности, между ними имеется радикалы,...
различие в типах выполняемых задач. Станут явными главш.1.
преимущества итеративного подхода: при его использовании о< \
ществляется борьба с основными рисками, создается началып.111
архитектурный каркас системы, совершенствуются и развиваю и и
планы проекта, созданные в фазе Начало. Эти планы будут пересматриваться и.,
всем протяжении проекта. Короче говоря, итеративная разработка позволяет ванн
му проекту адаптироваться к обнаружению новых или неизвестных проблем.
Вместо того чтобы описывать все возможные задачи, которые можно выпю
пять в фазе Проектирование, мы уделим основное внимание тому, что мы хошм
получить, то есть целям данной фазы, и расскажем, как их достигнуть. Это пом.,
жет вам сконцентрироваться на наиболее существенных задачах конкретном,
проекта, снизив вероятность его крушения или впадения в «аналитически!!
паралич», то есть увязания в несущественных задачах, препятствующих реальн..
му продвижению. Или, что еще хуже, вы могли бы направить силы на разрабоп \
неверного или бесполезного артефакта просто из-за того, что он описан в RUP
При чтении этой главы помните, что вам необходимо решить, насколы."
формально вы хотите подходить к разработке артефактов. Это можно делать в ум.
на письменной доске, в модели или документе. Насколько формально вам нужно
рецензировать эти артефакты? Мы постараемся указать наиболее очевидные спою
бы ускорить работу, которые можно использовать при работе с небольшим или пш
♦am Проектирование
139
(^формализованным проектом, но в конце концов ничто не может заменить
|Л|Ьшый смысл, и вам будет нужно решить, что лучше всего подходит для вашего
Ироекга. Именно это фиксируется в Плане разработки программы в ходе фазы
Нимало.
Цели фазы Проектирование
Проектирование - это вторая фаза подхода RUP (рис. 7.1). Целью фазы Проек-
|Нрование является выбор и создание основы архитектуры системы, которая должна
цОсспечить стабильный фундамент для основной массы работ по проектированию
И реализации в фазе Построение. Архитектура определяется исходя из самых суще-
Vщепных требований (тех, которые оказывают самое большое влияние на архитек-
|уру системы) и оценки рисков.
Веха целей
жизненного цикла
Веха готового
продукта
Веха архитектуры
жизненного цикла
Веха начальной
функциональной
готовности
Рис. 7.1, Фаза Проектирование. Проектирование - вторая Фаза жизненного цикла в RUP. Она име-
ет четко определенный набор целей и завершается Вехой Архитектуры жизненного цикла.
Эти цели помсиут вам решить, какие задачи выполнять и какие артефакты создавать
Эта основная цель разделяется на четыре крупные цели, каждая из которых
нпиравлена на определенную крупную область рисков. Это риски, связанные
г |ребованиями (действительно ли создается нужное приложение?), и риски, свя-
мииые с архитектурой (действительно ли создается нужное решение?). Это также
риски, связанные со стоимостью и сроками (действительно ли мы идем по верному
iivih?), и, наконец, риски, связанные с процессом и инструментальной средой
(действительно ли для работы имеется правильный процесс и подходящие ин-
i (рументы?). Работа над рисками гарантирует, что вы сможете перейти к фазе По-
I Iроение с минимумом рисков и проблем.
140
Глл|-<
Кам нужно понять
« шболее критичные
цюбования, чтобы
оценить, охватывает
пи архитектура все
(КЛЮВЫ.
1.Болеее глубоко попять требования. В ходе Проекторов,
ния нужно хорошо понять подавляющее коли-чество требив,
ний, поскольку многие из них лишь кратко описаны вф.,
Начало. Это позволит создать более подробный план. Нули,
также получить одобрение от заинтересованных лиц, Ч1и<ч
убедиться в правильности этих требований. И наконец, нутн
всесторонне попять наиболее критичные требования, чтобы оценить, охватыв.и .
ли архитектура все основы. Этого можно достигнуть только путем частичном
реализации этих требований.
(’проектировать, реализовать и проверить базовую архитектуру. Вам нуяш.'
спроектировать, реализовать и протестировать структурный каркас системы
Па уровне приложения функциональность будет неполная, но поскольку бон
шинство интерфейсов между строительными блоками реализуются в хот
Проектирования, вы можете скомпилировать и протестировать архитектуру. ')н
называется «исполняемая архитектура» (см. раздел «Цель 2. Спроектирован,
реализовать и проверить базовую архитектуру») в том смысле, что вы можсь
проводить с архитектурой некоторые первоначальные нагрузочные тесты и тес 111
производительности. Вам нужно принять ключевые проектные решенпч
включая выбор технологий, главных компонентов и их интерфейсов, оцени и
альтернативы типа «купить или сделать» и спроектировать и реализован
архитектурные механизмы и модели.
Обращение к большинству
технических рисков будет
проходить как следствие
детализации требований,
а также проектирования,
реализации и тестирования
архитектуры.
3. Снизить существенные риски и дать более точке к,
оценку сроков и стоимости. В ходе Проектирования вы
боретесь с основными рисками. Обращение к болыпин
ству из них будет проходить как следствие детализации
требований, а так же проектирования, реализации
и тестирования архитектуры. Также совершенствуем сч
и детализируется план проекта (подробнее см. гл. 12).
I. Уточнить прецедент разработки и установить среду разработки. На основ,
приобретенного опыта совершенствуется процесс, определенный в фазе Начали
Продолжается внедрение программных инструментов разработки, необходимых
для проекта.
*й1а Проектирование
141
фвза Проектирование и итерации
В «разе Проектирование многие риски снижаются при создании исполняемой
ектуры, то есть укороченной версии, реализующей наиболее существенные
Цйскты системы, которая позволяет очень конкретно продемонстрировать
КЦючевые возможности и, следовательно, недвусмысленно показать, что риски
(hl'iii устранены. Если вы уже создавали какую-нибудь систему при помощи тех-
нологии, которую вы используете в данном проекте, тогда можно достигнуть дан-
ной цели за одну итерацию, поскольку количество рисков ограничено. Можно по-
llopno использовать прошлые решения и таким образом быстро продвинуться
•перед.
Если же вы не имеете опыта в области, к которой относится приложение, если
ИВюма очень сложна или вы используете новую технологию, тогда для создания
Верной архитектуры и снижения ключевых рисков может потребоваться две или
tpn итерации. К другим факторам, которые могут заставить вас использовать не-
ItaHii.KO итераций, можно отнести распределенную разработку, наличие многих
1йшпересованных сторон или сложных договорных отношений между ними, не-
обходимость соблюсти правила безопасности или другие внешние стандарты.
В наших трех учебных проектах, как правило, будет наблюдаться такой набор
Hi граций.
• Проект «Ганимед», небольшой «зеленый» проект: поскольку при-
ложение невелико, сделать правильную архитектуру можно за
короткое время. Скорее всего, потребуется только одна итерация, I
однако если используется много новых технологий или создается
приложение, не имеющее аналогов, их может потребоваться и две.
• Проект «Марс», большой «зеленый» проект: поскольку приложе- "ч-
пие более сложное, и вы новичок в создании систем такого типа, »
может потребоваться некоторое время для понимания и уменьше-
пия технических рисков и создания верной архитектуры. Для этой фазы может
потребоваться две или даже три итерации.
• Проект «Юпитер», второй этап большого проекта: в первую
очередь добавляются новые функции и исправляются ошибки.
больших изменений в архитектуру не вносится. Будут использо-
ваться новые технологии и разрабатываться новые подсистемы, но одной
итерации должно хватить. Если вы вносите лишь небольшие изменения
в архитектуру, может вообще не потребоваться ни одной итерации.
142 Гллил
I'ели предположить, что наш большой «зеленый» проект будет иметь ir
терапии, то общей целью будет реализация прецедентов использования, наибо в.
существенных для заказчиков, а также тех, которые связывались в первой итерации
с наибольшими техническими рисками. Особенно в первой итерации (а в некоторж
с । епсни и во второй) начинайте с частичной реализации прецедентов использован и .
( ю сеть реализуйте только некоторые сценарии прецедента) для того, чтобы убран
как можно больше рисков и получить приемлемую реализацию еще до детализации
прецедентов использования. Итерации могут выглядеть примерно так, как описын.1
шея ниже.
Первая итерация Проектирования
• Спроектируйте, реализуйте и протестируйте небольшое число критичных сы
париев для определения необходимого типа архитектуры и архитектурных м.
ханизмов. Сделайте это как можно раньше, чтобы снизить самые критически,
риски.
• Определите, реализуйте и протестируйте небольшой первоначальный nat><.|.
архитектурных механизмов.
• Выполните предварительный логический дизайн базы данных.
• Опишите последовательность событий для примерно половины из тех прей,
центов использования, которые вы планируете разрабатывать входе Пр<» ।
гирования, в порядке снижения приоритета.
• Тестируйте столько, сколько нужно, чтобы подтвердить уменьшение архи на
турных рисков. Достигнут, например, нужный уровень производительное i и ’
Вторая итерация Проектирования
• Исправляйте все, что было не в порядке при первой итерации.
• Спроектируйте, реализуйте и протестируйте оставшиеся важные с архитектуры и
точки зрения сценарии. Акцент в этой итерации должен делаться на архи к,
турком охвате (см. раздел «Обеспечьте архитектурный охват»).
• Проработайте и реализуйте параллельное выполнение, процессы, потоки и фи
зическое распределение, как это необходимо при обращении с наиболее и '
нически рискованными проблемами. Сконцентрируйтесь на тестировании пр"
изводительности, нагрузочном тестировании и проверке интерфейсов меж и
подсистемами и внешними интерфейсами. (Заметим, что планирование тою
и когда делать основывается на раннем снижении рисков проекта. Для нгь.
Фаза Проектирование
143
горых систем решение проблем параллельного выполнения, процессов, потоков
п т.п. сопряжено с очень большим риском. Если это так, то вы должны начать
работать с этими проблемами уже в первой фазе Проектирование.)
• Определите, реализуйте и протестируйте оставшиеся архитектурные механизмы.
• ('проектируйте и реализуйте черновую версию базы данных.
• Подробно распишите вторую половину прецедентов использования, которые
нужно специфицировать в фазе Проектирование.
• I (ротестируйте, оцените и усовершенствуйте архитектуру так, чтобы она могла
выступать в роли основы. Выступать в роли основы означает, что архитектура
используется как стабильный базис. В нее все же можно вносить изменения, но
нужно избегать больших переработок, если это не связано с решением критиче-
ских проблем. Если у вас не получается прийти к стабильному состоянию архи-
тектуры, нужно добавить в фазу Проектирование еще одну итерацию. Это, воз-
можно, замедлит выполнение проекта, но продолжение работ при отсутствии
фундамента, то есть дальнейшие вложения в архитектуру, в которую продол-
жают вноситься крупные изменения, обойдется вам еще дороже.
Цель 1. Более глубоко понять требования
К концу фазы Начало вы уже должны были создать достойную Концепцию,
й |пкже подробное описание 20% (или около того) наиболее важных прецедентов
использования, хотя бы архитектурно-значимую часть этих прецедентов. У вас
1йкжс есть краткое описание (возможно, два-три абзаца) оставшихся прецеден-
I1HI использования.
К концу фазы Проектирование вам нужно будет завершить
описание большинства прецедентов использования. Некоторые
in них могут быть такими простыми или схожими с другими
Прецедентами использования, что их можно будет спокойно от-
ножпть на конец фазы Построение или же вообще формально не
описывать. Подробное их расписывание не скажется ни на ка-
К концу фазы Проек-
тирование вам нужно
будет завершить опи-
сание большинства
прецедентов исполь-
зования.
них крупных рисках. Следует также, если это необходимо, создать прототип поль-
||>1иггсльского интерфейса для главных прецедентов использования, чтобы заин-
1сресованные лица могли понять, какие функции реализует данный прецедент.
Просмотрите и протестируйте все прецеденты использования совместно с пользе-
144
naieJicM, используя для этого прототип пользовательского интерфейса. Вы увидпь
как пользователь будет обращаться с приложением, какая информация бу i> >
и।поражаться и вводиться.
Подробно описав прецеденты использования, вы, скорее всего, обнаружите 'ю
волнительные прецеденты, которые нужно добавить и расположить в поря ю
приоритета.
Следует также постоянно обновлять глоссарий. В некоторых случаях моли >
понадобиться графически выразить, как разные термины глоссария соотнося н ч
яруг с другом. Сделать это можно, выразив наиболее важные элементы глоссарп ।
и форме «объектов предметной области» в небольшой модели предметной облж
hi (подробнее см. раздел RUP «Детали рабочего процесса. Разработка моде i и
предметной области» (Workflow Detail: Develop a Domain Model).
Мы уже говорили в главе 6 («Подробно опишите ключевых акторам
и прецеденты использования»), что, как правило, при работе с прецедентами ш
пользования нужно выделять на задачи фиксированное время, чтобы не уня <
п\ль в деталях. Также заметим, что особенно в малых проектах роль анализ ini
и разработчика часто выполняет один человек, то есть один и тот же челокп
описывает прецеденты использования и реализует их. Если в вашем случае Л"
1лк, можно тратить меньше времени на детальное документирование требонл
niiii и возвращаться к ним по мере реализации и проверки прецедентов испо.п.
юиапия.
К концу фазы Проектирование у вас будет подробное описание подавляюще! о
оольшинства требований (вероятно, около 80%). В ходе того, как в фазе Постриг
ппе будут реализовываться все новые и новые прецеденты использования, вы о\
тс।е уточнять по мере необходимости каждый прецедент. Дополнительные ирг
цеденты использования могут быть обнаружены и в ходе Построения, но но
должно быть скорее исключением, чем правилом.
В трех наших учебных проектах происходит следующее.
’Проект «Ганимед», небольшой «зеленый» проект: команда он
наруживает еще один прецедент использования и еще одного аь
I тора. Тратится еще по два часа на каждый на описание 9 из 12 npi
цедентов использования, которые еще не описаны (см. гл. 15 разде ।
«Подробно описывайте акторов и прецеденты использования»),
• Проект «Марс», большой «зеленый» проект, в первой итерации
»jjXx команда совершенствовала Концепцию и обнаружила еще 3 прет
дента использования, что делает общее их число равным I '
Подробно описывается еще 12 прецедентов, которые добавляю к я
Фа ia Проектирование
145
к 9 уже готовым (см. гл. 15 раздел «Подробно описывайте акторов и прсцедсн-
1ы использования»). Во второй итерации обнаруживается еще один прецедент
использования, но принимается решение вывести два имеющихся за рамки
проекта. Подробно описываются еще 13 прецедентов, которые добавляются
к уже готовым 21.
• Проект «Юпитер», второй этап большого проекта: производится
обновление Концепции, добавлен прецедент использования,
подробно описано большинство еще не описанных прецедентов
(см. гл. 15 «Подробно описывайте акторов и прецеденты использования»).
Подробно проанализированы решения для дефектов, которые должны быть
исправлены, и оценено их влияние на архитектуру.
Цель 2. Спроектировать, реализовать и проверить базовую архитектуру
Архитектура программы и связанные с ней артефакты и задачи описываются
Ниже в главе 16. А сейчас давайте сведем архитектуру к нескольким ключевым
Проектным решениям, которые необходимо принять:
• выбор наиболее важных строительных блоков системы и их интерфейсов,
а также принятие решения по созданию, покупке или повторному использова-
нию части этих строительных блоков;
• описание, как эти строительные блоки будут взаимодействовать друг с другом
и ходе выполнения программы реализация наиболее важных из определенных
сценариев;
• реализация и тестирование прототипа архитектуры с целью оценить, работает
ли он, сняты ли главные технические риски проверка основных качественных
характеристик - производительности, масштабируемости и стоимости.
В RUP архитектура - это не только чертеж на бумаге. Чтобы проверить архи-
нч» гуру нужно не только провести рецензирование бумажных документов, нужна
исполняемая архитектура, которую можно проверить и убедиться, что она co-
in не гствует вашим нуждам и является надежным фундаментом для реализации
шпальной системы.
1 (сполняемая архитектура - это частичная реализация системы, созданная для
нпс», чтобы продемонстрировать, что архитектура может обеспечить ключевые
функции и, что более важно, демонстрирует нужные показатели в смысле произво-
ди 1сльности, пропускной способности, мощности, надежности, масштабируемости
II прочих способностей. Создание основы исполняемой архитектуры позволяет при
146
Гллол
Построении возводить полнофункциональную систему на солидном фундамент
не заботясь о возможности ее обрушения. Исполняемая архитектура строится к.и
эволюционирующий прототип. При этом стремятся аккумулировать проверен! н.п
свойства, а также те, которые с большой вероятностью станут удовлетворять тры >.
нациям, когда система будет уже зрелой, что сделает их частью готового продувы
(рис. 7.2).
Код, специфичный
для оборудования
или нужд заказчика
Процессы и другой
код приложения
5
Главные абстракции,
классы и т.п.
Механизмы, службы
(например, ORB, MQS,...)
Прилс»ение
3
Основа приложения
Аппаратно-специфичный
код, платформенно-
специфичный код,
код общего применения
Рис. 7.2. Один из возможных видов статической структуры системы. Архитектура состоит пи >
мых важных строительных блоков и их интерфейсов и определяет общие решения ча> >
встречающихся проблем. Она образует структурный каркас приложения, оставляя ши
можность заполнять свободные места в стабильной, четко определенной основе
В организованной в виде слоев архитектуре нижние слои либо уже существую!
либо будут созданы в ходе фазы Проектирование. Слои уровня приложения обрей ।
плоть в виде кода в фазе Построение, а в фазе Проектирование реализованы лини
частично (скорее всего, только до создания каркаса подсистем). Тем не менее к копи.
(разы Проектирование нужно проводить тесты производительности и нагрузочшт
Фаза Проектирование
147
ici-гы критических сценариев, а чтобы можно было выполнять такое сквозное
I тегирование, нужно писать «заглушки» (если вы не пишете собственно код прило-
жения). К концу фазы Проектирование закладывается архитектурная основа.
К концу фазы Проектирование вы закладываете архитектурную основу, что оз-
начает, что архитектура становится стабильным базисом для построения осталь-
ной системы. С этого момента архитектуру следует менять с осторожностью
н юлько при наличии веских оснований. Такая основа создает определенную ста-
бильность для команды разработчиков. Заметим, что, чем больше команда и тех-
нически сложнее проект, тем более важно закладывать архитектурную основу.
•1см меньше команда и чем менее сложна архитектура, тем более свободно мож-
но подходить к ее изменению (подробнее см. гл. 16).
Архитектура: определение подсистем, ключевых компонентов и их интерфейсов
К концу фазы Начало вы создали или по крайней мере определили одну воз-
можную архитектуру, которая позволит построить систему с приемлемым уров-
нем риска и за разумную цену. В некоторых случаях были также реализованы
ключевые элементы архитектуры в разделе «Цель 3. Определить хотя бы одно
возможное решение» (см. гл. 6).
К концу фазы Начало у вас было грубое представление о рисках, с которыми вам
предстояло столкнуться, особенно в области приобретения технологий и повторного
использования архитектурной базы (architectural framework), программных пакетов
н гл. Большинство вопросов оставались без ответов. Ответы на другие вопросы бы-
1111 предварительными и требовали завершения в фазе Проектирование.
В силу этих причин на ранних этапах Проектирования вы Вместо того чтобы сра-
цолжны неплохо понимать того, какую систему вы строите.
Вместо того, чтобы сразу придумывать архитектуру, следует
сначала рассмотреть возможность использования сущест-
вующей архитектурной базы. Может быть, существует гото-
вая коммерческая база (например, IAAA от фирмы IBM для
приложений, связанных со страхованием) или, возможно, вы
зу придумывать архи-
тектуру следует снача-
ла рассмотреть воз-
можность использова-
ния существующей
архитектурной базы.
создавали такие системы раньше и можете взять архитектуру из предыдущей
работы. Если такой возможности нет, нужно определить главные строительные
блоки, то есть подсистемы и основные компоненты. Подбирать их можно на базе
основных абстракций, зафиксированных в объектной модели предметной облас-
1П пли глоссарии (см. гл. 6). Например, для онлайновой торговой системы, как
правило, требуется компонент или подсистема1, реализующая каждую из основ-
148
Глава i
пых сущностей - Корзину, Заказчика и Политику скидок. Для каждой выявлен
ной подсистемы или компонента опишите ключевые возможности, которые онл
должна обеспечивать, а именно интерфейсы с остальной частью системы.
Параллельно с определением ключевых компонентов и подсистем вам нужно
щучить все ценное, что есть внутри компании и вне нее. Можете ли вы обзавсс
।нсь набором компонентов, реализующих концепцию Корзины? Удовлетворяю!
ли эти компоненты вашим нуждам? Каковы будут правовые и финансовые но
следствия? Будет ли проводиться поддержка этих компонентов по мере развины
юхнологии и пользовательских требований? Имеете ли вы доступ к исходном\
коду для внесения необходимых изменений? Хорошо ли документирован кот
имеются ли руководства по дизайну компонентов и способам их использованич
и юстирования?
Для формирования архитектуры используйте архитектурно-значимые
прецеденты использования
В ходе фазы Начало вы должны были определить некоторые прецеденты in
пользования (вероятно от 20 до 30%2, которые являются особенно критичными
для системы (см. гл. 6 раздел «Цель 2. Выяснить главные функции системы")
Скорее всего, они также важны и для формирования архитектуры.
Нужно также определить наиболее сложные, неизвестные или рискованна
элементы требований, возможно, относящихся к нефункциональным требованн
ям. и найти прецеденты использования (или их фрагменты), которки
проиллюстрировали бы трудные места и чья реализация могла бы устрани и
противоречия и убрать риск. Все это технические сложности, которые отжили
к инфраструктурной части архитектуры. Например, если имеется очень жесп><"
фебование на время ответа или на нагрузку, определите один прецедент исиош
зования (или просто последовательность событий внутри одного прецеден1.п
который проиллюстрировал бы это требование, а также требование на ожид.к
мую производительность. В качестве других примеров можно назвать страто ню
преодоления ошибок или начало работы системы.
I. Подсистема соответствует компоненту или набору компонентов. - Примеч. авт.
?. Заметим, что для некоторых систем один или два прецедента использования могут составлять яде
приложения, а гораздо большее число "вспомогательных" прецедентов обеспечивают выполнение ключгпи-
П ;акой ситуации архитектурно значимыми являются 20-30% прецедентов использования, и, как пщню
цюбуется реализовать несколько сценариев для каждого ключевого прецедента. - Примеч. авт.
Фаза Проектирование
149
Архитектурно значимые
прецеденты использования
he. 7.3. Архитектурно-значимые прецеденты использования формируют архитектуру. В большин-
стве систем вы сможете справиться с большинством технических рисков и направлять
реализацию архитектуры, правильно выбрав 20-30% прецедентов использования и спро-
ектировав, реализовав и протестировав одии-два сценария для каждого прецедента. Что-
бы реализовать определенный прецедент использования, нужно определить, какие эле-
менты программы требуются для обеспечения его функциональности
11аконец, нужно определить прецеденты использования, которые, хотя и не яв-
ляются критичными или технически сложными, обращаются к еще не охваченным
чпегям системы. Тогда к концу фазы Проектирование вы получите хорошее понима-
ние всей архитектуры системы. Например, убедитесь, что все основные «бизнес-сущ-
ноети» используются хотя бы одним архитектурно значимым прецедентом использо-
(11111114.
Вы должны убедиться, что архитектура позволяет реализо-
Hiiib все архитектурно значимые прецеденты использования.
Дня этого нужно спроектировать, реализовать и протестировать
только прецедентов использования, сколько необходимо для
уменьшения связанных с ними рисков (рис. 7.3). В то же самое
время не нужно реализовывать больше возможностей, чем это
В фазе Проектирование
нужно сконцентрировать-
ся только на одном или
двух сценариях преце-
дента использования.
150 Гллю
необходимо для уменьшения рисков, поскольку это отнимет время у других зад.г,
посвященных снижению рисков, которые и есть одна из ваших главных целей в ф .
Проектирование. Как правило, это подразумевает, что в фазе Проектировано
нужно сконцентрироваться только на одном или двух сценариях или последовал-и ।
ностях событий прецедента использования. Обычно выбирается основная после ю
нагельность событий, то есть сценарий «успешного развития событий». Если но-
ходимо, реализуйте сценарий (или сценарии) неожиданного хода собы i ни
Например, можно реализовать сценарий, посвященный снятию риска, связашюн
с обработкой исключений, но нет никакого смысла в том, чтобы реализовын,ш
К) сценариев, посвященных этому риску.
Проектируйте критичные прецеденты использования
Представление прецедента использования в проектной модели называется реа ш
задней прецедента использования (см. рис. 7.4). Она описывает, как конкретно
прецедент использования реализован внутри проектной модели в виде объектов
нерации (collaboration objects). Вы можете разделить эту работу на аналитически’
часть и проектирование. Ниже дается обзор пяти наиболее важных шагов по реа ш
з.-щии прецедента использования. Нужно заметить, что эти шаги полезны для ы -
разработчиков, но нужно в каждом проекте определять, насколько формализован
будут документироваться результаты каждого шага, например на письменной в к ।
или в средстве визуального моделирования, (подробнее см. гл.17 раздел «При- >
трование реализаций прецедентов использования и компонентов»),
1. Создайте предварительную схему объектов аналитической модели
которые задействуются в кооперации. RUP предоставляет веско и ।
хороших руководств, которые помогут разработчикам, не имеющим оный
в объектно ориентированной разработке, правильно определить классы апл
литической модели.
2. Распределите действия по классам аналитической модели. Toon
определите полную область ответственности каждого класса аналитичен- и
модели (analysis class), чтобы понять, как эти классы вместе смсп.
обеспечить функциональность прецедента использования.
3. В ходе разработки ПО в соответствии с RUP разрабатывается несколько моделей. В их число
аналитическая модель (analyses model), или модель анализа, и проектная модель (design model), называемая
дизайн-модель, или модель проектирования. Аналитическая модель может не оформляться как отдельная мод,,.
В этом случае она является просто стадией разработки проектной модели. - Примеч. науч. ред.
Фаза Проектирование
151
1. Подробно опишите классы аналитической модели. Это поможет понять
область ответственности каждого класса. Проведите рецензирование ана-
литической модели, чтобы гарантировать, что функции никаких двух классов
не перекрываются и взаимоотношения между разными классами имеют
смысл.
4 Спроектируйте прецеденты использования. Иными словами, укажите,
в каком точно порядке и как каждый класс проектной модели (design class)
будет взаимодействовать с другими классами проектной модели для реализа-
ции архитектурно значимой функциональности прецедента использования.
Такой способ разбиения функциональности прецедента использования на набор
взаимодействующих друг с другом элементов дизайна можно использовать
и в объектно ориентированных, и в не объектно ориентированных системах.
V Доработайте классы аналитической модели до классов проектной
модели. Во многих случаях несколько классов проектной модели реализуют
один класс аналитической модели. Детализируйте каждый класс проектной
модели, указав методы (operations) и атрибуты (attributes), отрецензируйте
проектную модель, чтобы обеспечить отсутствие дублирования функцио-
нальности в нескольких классах, и убедитесь, что все взаимоотношения
между классами имеют смысл.
I !ростые прецеденты использования с ограниченным взаимодействием между
классами, особенно реализуемые с помощью мощных языков программирования
(нппример, Visual Basic или другие языки четвертого поколения) как правило, не
•рсбуют выполнения всех этих шагов, особенно шага 4.
Объединяйте и собирайте готовые классы в пакеты
Следующий шаг - сгруппировать готовые классы в соответствующие подсисте-
мы. Команда архитекторов уже выявила некоторые подсистемы (см. раздел «Архи-
fcKiypa: определение подсистем, ключевых компонентов и их интерфейсов»).
Ипсгрукции по созданию пакетов классов представлена далее:
• локализуйте влияние будущих изменений, собрав те классы, которые, скорее
всего, будут изменяться все вместе, в одну подсистему, (рис. 7.5). Например,
если вы ожидаете, что интерфейс какого-нибудь актора радикально изменится,
поместите в одну подсистему все классы, реализующие интерфейс этого
пкгора;
152
Глава i
Рис. 7.4. Пример диаграммы последовательностей. Реализация прецедента использования показывай ।
как элементы проектной модели взаимодействуют друг с другом для создания фупкцион., и
ности архитектурно значимых частей прецедента использования. Один из способов noKat.ui
это взаимодействие - это диаграмма последовательностей
Рис. 7.5. Группирование классов должно локализовать влияние изменений. Вы можете локали зои.и1
влияние изменений, поместив все классы, зависящие от некоторой базы данных или ни
терфейса актора, в одну подсистему
Фаза Проектирование
153
• введите некоторые правила видимости. Например, введите правила, опреде-
ляющие границы между слоями в клиент/серверном приложении. Не нужно
помещать в одну подсистему классы из разных слоев;
• подумайте о размещении классов в соответствии с тем, как вы будете конфи-
гурировать будущее приложение/продукт. Это означает, что вы можете со-
бирать разные конфигурации конечного приложения, включая и исключая раз-
ные подсистемы.
Более подробные рассуждения в отношении объединения классов приводятся
и продукте RUP - Guidelines: Design Packages (Руководства: проектные пакеты).
Рис. 7.6. Архитектурный охват. Прецедент использования Е можно и не считать архитектурно-
значимым, по его добавляют в список для проектирования, реализации и тестирования,
чтобы обеспечить архитектурный охват тех частей архитектуры, которые иначе окажутся
незатронутыми
154
Глава /
Обеспечьте архитектурный охват
Важной целью при создании исполняемой архитектуры является обп
печение того, чтобы архитектура обязательно включала в себя прецеденты ш
пользования, затрагивающие все главные области системы. Это гарантирую
чю кажущаяся совершенно простой часть системы не будет скрывать в себе п<
ожиданных проблем. Особенно важно это при построении принципиально но
вых, ранее не создававшихся систем. Как только вы осуществили консолидл
цию пакетов и подробно расписали реализацию прецедентов использовалия
нужно проверить, все ли области системы были охвачены. Если к концу фазы
Проектирование вы обнаружите «незатронутые» области, нужно определи и
дополнительные сценарии и реализовать их, чтобы обеспечить архитектуры.!и
охват (рис. 7.6). Это часть стратегии снижения рисков в целях сведения к мини
муму неожиданных проблем в будущем. Хороший охват также покажет, что в.,
шп оценки стоимости и сроков были верны.
Архитектурный охват Архитектурный охват, как правило, является большей забои и,
шшяетсябольшей в больших проектах, чем в малых, а в малых проектах его часы
.иботойв больших можно и не принимать в расчет.
проектах.
Спроектируйте базу данных
Многие системы используют базу данных, и нужно понять, как данш.в
предназначенные для долговременного хранения, будут сохранялгю
и извлекаться. Полное руководство по проектированию базы данных можп"
найти в Rational Unified Process (см. в RUP задачу «Проектирование базы дан
пых» (Database Design) и руководство «Модель данных» (Data Model). Поле,
ную информацию можно также найти у Ambler 2000.
Создайте схему параллельного выполнения, процессов, потоков
и физического распределения
Теперь нужно будет описать архитектуру времени выполнения в термин.!
параллельного выполнения, процессов, потоков, коммуникаций между процессами
и г.п. В случае распределенных систем, нужно описать распределение, составт,
t чему физических узлов. Такое описание включает определение сетевой конфи
тип и сопоставление процессов и узлов.(подробнее см. гл.16).
Фаза Проектирование
155
Определите архитектурные механизмы
Архитектурные механизмы представляют собой типовые
конкретные решения часто встречающихся проблем (рис. 7.7).
(•ни являются архитектурными шаблонами, дающими стан-
диргные решения таких проблем, как сбор мусора, постоянное
мрппсние, управление списками, реализации «Корзины для по-
купок» или общения с внешними системами по определенному
протоколу.
Классы
Архитектурные механизмы
Архитектурные меха-
низмы представляют
собой типовые кон-
кретные решения
часто встречающих-
ся проблем.
Полет
Самолет
'^Хранение данных
Миссия
^Коммуникация
График
^Анализ
Маршрут
Аутен гификация
I Загрузка
ЙК. 7.7. Архитектурные механизмы. Архитектурные механизмы дают решения типовых проблем.
Можно иметь один или несколько механизмов для хранения данных, коммуникаций, ана-
лиза и аутентификации. Каждый из них может использоваться в системе несколько раз
I (роектируя, реализовывая, тестируя и документируя архитектурные механиз-
мы, вы можете один раз решить самые общие и трудные проблемы, а потом все
Миены команды будут пользоваться этими готовыми решениями, когда это им
Пшребуется. Такой подход позволяет разработчикам повысить производитель-
ность и значительно ускоряет работу в фазе Построениея, когда к проекту, как
привило, подключается много людей (см. также гл. 16).
156
Глава i
Реализуйте критические сценарии
Каждый класс проектной модели служит спецификацией кода. В болыцинспь
случаев реализация такого класса производится итеративно, по мере того, как кл:к .
проектируется. Сначала проектируется небольшая часть, затем эта часть реализус!
ся, выявляются недостатки, затем дизайн совершенствуется. По мере реализации
компонентов нужно производить модульное тестирование (unit-testing) компонешл
чтобы гарантировать, что компонент работает согласно спецификации и не внесена
никаких утечек памяти или узких сточки зрения производительности мс< i
(подробнее см. гл. 17 раздел «Тестирование, проводимое разработчиком»).
Спроектировав и реализовав класс, нужно подумать, как тестировать систем'
Может потребоваться также спроектировать и реализовать тестовые классы
представляющие собой тестовые драйверы и интерфейсы автоматизированны',
инструментов тестирования.
Интегрируйте компоненты
При проведении
игеративной разра-
(югки постепенно
становится все слож-
нее планировать вы-
пуски и интеграци-
онное тестирование.
При проведении итеративной разработки постепенно становш
ся все сложнее планировать выпуски (builds) и интеграционно,
тестирование. Параллельно с определением классов анали
тической модели нужно определять, какие компоненты и в ли
ком порядке будут интегрироваться. При проектировании кл.и
са нужно выполнять проектирование и реализацию функции
необходимых для интеграции и компиляции развивающей
системы и дальнейшего ее тестирования.
Интегрирование - задача непрерывная. Если итерации занимают у в,и
например, по четыре недели, как правило, нужно создавать выпуски ежедневно шш
хотя бы дважды в неделю. По мере роста системы и размера команды может бы и.
придется увеличить интервал между выпусками (а также и продолжительно'и
итерации). Заметим, что объем имеющейся поддержки управления конфигурации
ми, включая автоматизированное управление выпусками, оказывает значительно,
влияние на планирование и частоту создания выпусков.
Тестируйте критические сценарии
Тестирование - чрезвычайно важный аспект Проектирования. Наилучпшм
способом убедиться в снятии риска является тестирование исполняемой архи нт
iypw. Среди прочего нужно проверить следующее.
Фаза Проектирование
157
• Критические сценарии были должным образом реализованы и обеспечивают
желаемую функциональность.
• Архитектура обеспечивает приемлемую производительность. Как прави-
ло, есть пара сценариев, наиболее критичных для производительности.
Их производительность и нужно тестировать. Для онлайновой торговой систе-
мы может оказаться необходимым проверить, приемлемо ли выполняется пре-
цедент использования «Оформление покупки». Если производительность не-
достаточна, может потребоваться переработка архитектуры.
• Архитектура может выдержать необходимую нагрузку. Обычно к нагрузке
чувствительно небольшое число сценариев, и именно их нужно протестировать
нагрузочными тестами. В онлайновой торговой системе может оказаться необ-
ходимым проверить, что прецеденты использования «Просмотр каталога»,
«Поместить покупку в Корзину» и «Оформление покупки» выдерживают на-
грузку в 1 000 пользователей одновременно. Если такая нагрузка не выдержива-
ется, наверняка следует пересмотреть кое-какие архитектурные решения.
• Интерфейсы с внешними системами работают так, как ожидается. Рабо-
тает ли API должным образом? А как насчет вопросов производительности
и синхронизации?
• Протестированы все требования в дополнительной спецификации (нефунк-
циональные требования), которые не были охвачены ранее. В эту категорию
могут попасть такие сценарии, как преодоление сбоев, переконфигурирование
и восстановление. Дополнительная спецификация — важный источник требова-
ний, которые нужно протестировать с архитектурной точки зрения и которые для
эффективного тестирования могут потребовать наличия специальных сценариев.
Некоторые тесты можно автоматизировать при помощи тестовых инструмен-
Н)в: это позволяет понять, есть ли у вас необходимые инструменты и компетент-
ность в обращении с ними. Таким образом, итеративный подход заставляет вас
рппо «протестировать» свои возможности тестировать, чтобы можно было
Исправить все проблемы пока не стало слишком поздно.
Что осталось сделать?
Список задач, которые мы только что охватили, весьма полон, так что же нам еще
осталось сделать? Хотя мы и выполнили в проекте задачи многих типов, спроек-
шровали, реализовали и протестировали только 10-20% процентов системы. Мы час-
1)1чио реализовали 20-30% прецедентов использования, а в каждом из них только
158
ГЛАВЛ !
один или два сценария успешного развития событий. Среди всего прочего вы, можс i
bi.ni>, реализовали некоторые архитектурно-значимые альтернативные последов.,
1елыюсти событий для тестирования механизмов обработки исключений.
ходе Проектирова-
нии выделаете не-
(хппмую часть целого,
i чнаеюя создать еще
I поло 80% кода.
Но в общем, большая часть кода проекта будет работать с а и
тернативными или неожиданными реакциями пользователей
и обработкой исключений. Так что в ходе Проектирования вы ;ic
лаете лишь небольшую часть целого, и на следующие фазы жн
ценного цикла - Построение и Внедрение - остается около 80"
кода. Положительно, однако, то, что реализованный и протестированный код пре i
с । авляет собой наиболее сложные части системы и позволяет снизить большую час 11
рисков проекта.
В трех наших учебных проектах происходит следующее.
• Проект «Ганимед», небольшой «зеленый» проект: команда разни
вает функциональный прототип, созданный в фазе Начало, ин.
лучает более полную исполняемую архитектуру, которая позволяю
продемонстрировать часть ключевых функций системы: (поддерживаюи
только некоторые четко определенные функции (если это зависит от разрл
ботчиков). Что более важно, архитектура обеспечивает необходимую прои ию
дительность, масштабируемость, надежность и т.п. Архитектура протестщю
вана и используется как основа для дальнейшей работы.
• Проект «Марс», большой «зеленый» проект: команда развивает коп
цептуальный прототип, созданный в фазе Начало и получает боне,
полную исполняемую архитектуру, которая позволяет продемон
стрировать часть ключевых функций системы: (поддерживаются только пеги
горые, четко определенные функции (если это зависит от разработчиков). Чю
более важно, архитектура обеспечивает необходимую производительность, м;ь
пггабируемость, надежность и т.п. Поскольку производительность и масшы
бнруемость представляли большую проблему, тратится значительное время пл
нагрузочные тесты и тесты производительности архитектуры. Внесено мною
исправлений, что сохранит в будущем массу времени. Архитектор прошено!
вместе с командой по всей архитектуре, чтобы убедиться, что все ее понимаю!
• Проект «Юпитер» - второй этап большого проекта: команда моли ।
быстро закончить фазу Проектирование, поскольку крупные нл
нические риски не встречаются. Технические риски снижены пун м
реализации и апробирования некоторых новых технологий. Проделана что
л ичная реализация нескольких ключевых прецедентов использования, hioih.i
убедиться, что новые функции не ухудшат архитектуру.
Фаза Проектирование
159
Цель 3. Снизить существенные риски и дать более точную оценку сроков
И стоимости
В ходе фазы Проектирование производится снижение подавляющего боль-
шинства технических рисков - рисков, связанных с пониманием и получением
одобрения на требования, а также рисков, относящихся к организации и исполь-
юнаиию среды проекта, (подробнее см. гл. 14).
Планируйте проект и оценивайте затраты
К концу фазы Проектироване у вас есть более точная информация, которая позво-
ни i провести обновление плана проекта и оценки затрат (подробнее см. гл. 12).
• Вы подробно расписали требования, которые позволяют понять, что за систе-
му вы строите. Соответствующим образом обновляется и Концепция.
• Реализуется каркас системы (исполняемая архитектура). Это подразумевает,
что разрешены многие наиболее трудные проблемы. Осталось в основном
только заполнить «дыры» в большом количестве четко определенных облас-
тей. (Не нужно недооценивать оставшийся объем работ, но по крайней мере
пы знаете, что еще нужно сделать.)
• Вы уменьшили подавляющее большинство рисков. Это радикально сокращает
разрыв между нижним и верхним пределами оценки сроков и затрат.
• Вы понимаете, насколько эффективно вы работаете с людьми, инструментами
п имеющейся технологией, поскольку вы уже поработали со всем этим и как
минимум один раз прошлись по всему жизненному циклу (один раз на каж-
дую итерацию фазы Проектирование).
В наших трех учебных проектах происходит следующее.
• Проект «Ганимед», небольшой «зеленый» проект: менеджер/архи-
гсктор проекта тратит пару часов на обновление оценки сроков и за- г-''<к
। рат и пишет записку о рисках и о том, как их уменьшить. Менеджер/ I
архитектор проекта тратит 30 минут на разъяснение этой информа-
ции команде и отсылает ее по электронной почте спонсору проекта.
• 11роект «Марс», большой «зеленый» проект: менеджер проекта
проводит обновление Экономического обоснования и Плана разра- »
богки программы, добавляя туда дополнительные планы, списки 1*1
рисков и прочие ключевые управленческие артефакты. Менеджер проводит
совещание с основными заинтересованными лицами, занимающее половину
160
Гллс.л .
дня, с целью рассмотрения Экономического обоснования, Списка рисков, Кои
цепции и Плана разработки программы (см. раздел «Рецензирование проеки
Веха Архитектуры жизненного цикла»).
’Проект «Юпитер» - второй этап большого проекта: Менед>ы р
проекта проводит обновление Экономического обоснования и 1I ы
на разработки программы, добавляя туда дополнительные план, ।
списки рисков и прочие ключевые управленческие артефакты. Менеджер ир-
водит двухчасовое совещание с ключевыми заинтересованными лицами с ш
лью рассмотрения Экономического обоснования, списка рисков, Концепции
и Плана разработки программы (см. ниже раздел «Рецензирование проеки
Веха архитектуры жизненного цикла»).
Цель 4. Уточнить прецедент разработки и установить среду разработки
В ходе фазы Начало вы определили, какому процессу вы будете следов.! и
н описали свой способ использования RUP в прецеденте разработки (develop
ment case). Вы также определили, какие инструменты вы будете применять, и ш
строили эти инструменты должным образом. В фазе Проектирование ин
прошлись по всему жизненному циклу, производя проектирование, реализации
и тестирование архитектуры. Вы также поставили свой базовый код н.ч
Контроль конфигураций.
Для выполнения этих задач вы провели инсталляцию и развертывание прош
са п инструментов, с которыми начали работать, и по мере прохождения цш. о
определили, что хорошо, а что не очень хорошо работает в вашем случае. Вы и-
пнмаете, как улучшить процесс и какая дальнейшая настройка необходима i
ваших инструментов. Вы производите соответствующее обновление прецедгп! ।
разработки и проводите тонкую настройку инструментов.
15 наших трех учебных проектах происходит следующее.
• Проект «Ганимед», небольшой «зеленый» проект: члены ком;.
собираются вместе и тратят час на обсуждение того, как они о, и-
I сятся к процессу и инструментальной среде, которые исполь яч’
лись в фазе Начало. После совещания менеджер/архитектор проекта вши и.
изменения в прецедент разработки, чтобы включить туда и результаты i|>.i ч
Проектирование. Описывается, какие артефакты нужно создать, какие ..
зовать шаблоны, как документировать информацию. Также в этой фазе меш >
Фл.чл Проектирование
161
жер/архитектор выступает в роли наставника для остальной команды, помогая
ей применять процесс и инструменты.
• I (роект «Марс», большой «зеленый» проект: наставник общается
с разными членами команды и узнает, что работало в фазе Начало в
хорошо, а что не очень. На основе этой информации наставник I* *’
вносит изменения в прецедент разработки проекта. Наставник учитывает дан-
ный прецедент разработки в ходе любого обучения, которое проводится в фазе
I (роектирование.
• 11роект «Юпитер» - второй этап большого проекта: менеджер проек-
ia общается с разными членами команды и узнает, что работало
в фазе Начало хорошо, а что не очень. На основе этой информации
менеджер вносит изменения в прецедент разработки проекта и проходится
по всем внесенным изменениям вместе с командой. Большая часть членов ко-
манды знакомы с процессом и инструментами, так что обучения не требуется.
Рецензирование проекта. Веха архитектуры жизненного цикла
Завершает фазу Проектирование Веха (контрольная точка) архитектуры жиз-
ненного цикла. В этой точке проводится подробная проверка целей и границ систе-
мы, принятого архитектурного решения и снятия основных рисков. Если проекту не
удается удовлетворить критерии контрольной точки, от него следует отказаться или
|И> меньшей мере серьезно пересмотреть, и лучше сделать это раньше, чем позже.
|||сративный подход вкупе с этой вехой заставляют принять такое решение. Рецен-
зирование для Вехи архитектуры жизненного цикла включает в себя оценку сле-
дующих моментов.
• Являются ли Концепция и требования проекта стабильными?
• Является ли стабильной архитектура?
• I (роверепы ли основные подходы, которые будут использоваться при тестиро-
вании и оценке системы?
• I (оказало ли тестирование и оценка исполняемых прототипов, что борьба с ос-
новными рисками привела к их устранению?
• Являются ли планы итераций на фазу Построение достаточно подробными
и точными, чтобы можно было продолжать работу?
162
ГЛАНЛ /
• Согласны ли все заинтересованные лица с тем, что текущая концепция, г.и
опа определяется в документе «Концепция», может быть реализована, есип
для разработки всей системы будут использоваться текущий план и текучим
архитектура?
• I (риемлема ли разница запланированных и реальных расходов?
В больших проектах такое рецензирование может продолжаться как один
день, так и несколько. В малых проектах оценку можно провести за время часов, >
i о совещания.
Заключение
К концу фазы Проектирование, второй из четырех фаз подхода RUP, вы мож,
ic увидеть, что уже сделаны значительные успехи по сравнению с тем, что бы м
в конце фазы Начало. Вот главные достижения.
• Вы перешли от общего знания наиболее важных требований к подробному но
пиманию около 80% всех требований.
• Вы перешли от возможной и, вероятно, концептуальной архитектуры
к базовой исполняемой архитектуре. Это означает, что была спроектирован.,
реализована и проверена архитектура, структурный каркас системы, которач
затем стала базисом будущей системы.
• Вы уменьшили большинство архитектурно значимых рисков и произвели *><>
лее точную оценку графика и затрат для оставшихся частей жизненного цнк
ла. Веха архитектуры жизненного цикла была использована для принятия ре-
шения о продолжении проекта, отказе от него или же о радикальном его изм,
пении.
• Вы усовершенствовали прецедент разработки и установили среду разрабоз mi
♦ Вы дали небольшой команде наиболее опытных сотрудников заняться напн"
лее сложными задачами, вы заложили основу для успешного продолжен in
проекта и для расширения его с минимальным финансовым, деловым и к \
ническим рисками.
ГЛАВА 8
Фаза Построение
В этой главе описывается, что представляет собой Построение (Construction),
1ретъя фаза жизненного цикла в Rational Unified Process (рис. 8.1). Читая эту гла-
ву, помните, что вам необходимо решить, насколько формально вы хотите подхо-
дить к разработке артефактов: это можно делать в уме, на письменной доске, или
*с в модели или документе. Ничто не может заменить здравый смысл, и вам нуж-
но самим решать, что лучше всего подходит для вашего проекта.
Начало
Проектирование
Построение
Внедрение
Время
Веха целей
жизненного цикла
Веха архитектуры
жизненного цикла
Веха начальной
функциональной
готовности
Веха готового
продукта
Ьк.8.1. Фаза Построение. Построение - третья фаза жизненного цикла в RUP. Она имеет четко
определенный набор целей и завершается Вехой архитектуры жизненного цикла’. Эти це-
ли помогут вам решить, какие задачи выполнять и какие артефакты создавать
* Опечатка авторов. Должно быть «вехой начальной функциональной готовности». - Примеч. науч. ред.
164
Глдвл н
в Фазе Построение акцент
и первую очередь делается на
детальном проектировании,
реализации и тестировании,
которые и призваны воплотить
п жизнь готовую систему.
Фаза Проектирование заканчивается выпуском базовой
исполняемой архитектуры, которая позволила разобраться
с основными техническими рисками, такими как риски
связанные с производительностью, с конкуренцией ы
ресурсы и с безопасностью данных, написав и проверни
конкретный код. В фазе Построение акцент в первую
очередь делается на детальном проектировании, реальна
ции и тестировании, которые и призваны воплотить в жизнь готовую систему.
Что же нам еще осталось сделать? На самом деле подавляющую часть всей раГю
1Ы. Многие прецеденты использования еще не реализовывались вообще, а те. к<>
горые реализованы, как правило, реализованы лишь частично, просто для проверки
гипотезы или оценки какого-то риска. Были определены подсистемы и реализованы
интерфейсы, но написан лишь очень небольшой объем кода (который обрабатывав
бизнес-логику, альтернативные потоки событий и ошибки). По мере реализации пи-
новых и новых функций вы будете уточнять требования. Так что, помимо всен>
прочего, в фазе Построение осуществляется масса работы по уточнению требова
пий, детальному проектированию, реализации и тестированию (рис. 8.2).
На деле фаза Построение, как правило, требует больше всего времени
(подробнее см. гл. 12 раздел «Персонал проекта»). В среднем 65% всей рабслы
и более 50% времени, отведенного на проект, тратится на фазу Построение (заме-
тим, что от проекта к проекту эти цифры могут значительно меняться).
Хотя наиболее крупные технические риски устранялись в ходе Проектирования
при Построении постоянно всплывают новые, с которыми вам нужно бороться
Однако в общем эти риски должны оказывать меньшее влияние на общую архитек
гуру. Если этого не произойдет, значит, в ходе Проектирования вы потрудились
В ходе фазы Построение акцент делается на том, чтобы
разработать высококачественный код экономически эффск
тивно. Гарантией успеха, особенно для больших проектов
становится обеспечение архитектурной целостности, парал
дельной разработки, автоматизированного тестирования
и управления конфигурациями и изменениями. Базовая
архитектура, созданная в ходе фазы Проектирование, позво
ляет расширять проект и привлекать по мере надобности но
вых людей.
недостаточно.
Гарантией успеха стано-
вится обеспечение архи-
тектурной целостности,
параллельной разработ-
ки, автоматизированного
тестирования и управле-
ния конфигурациями
и изменениями.
По мере проектирования, реализации и тестирования все новых и новых функ
пий вы будете постоянно проводить согласование все более детализированных
требований, чтобы определять, какая же функциональность действительно нужна
заказчику. Все больше внимания будет уделяться достижению правильного сот
Фаза Построение
165
Ношения между качеством, границами системы, временем и «отполированно-
Г1ыо» функций (баланс между созданием просто полезных функций и доведени-
ем до блеска функций, которые и так достаточно хороши).
Рис. 8.2. Распределение работ по фазам RUP. В стадии Построение фокус сдвигается к доводке тре-
бований, а также детальному проектированию, реализации и тестированию. К последним
стадиям этой фазы сильный акцент делается на развертывании. Управление конфигурация-
ми и изменениями теперь применяется постоянно ко всем составляющим проекта
Цели фазы Построение
Фаза Построение по сути представляет собой экономически эффективную
разработку окончательного продукта, т.е. работающей версии системы, которая
может быть представлена сообществу пользователей. Цели следующие.
I, Снизить стоимость разработки и добиться определенного параллелизма
в работе команд разработчиков. Оптимизируйте использование ресурсов и избе-
гайте создания ненужного кода и переработок. Даже в небольших проектах
обычно бывают компоненты, которые можно разрабатывать независимо друг от
друга, что допускает естественный параллелизм между разработчиками или
командами разработчиков (если имеются необходимые ресурсы).
166
ГЛА1
2. Разработать итеративным методом окончательный продукт, roioui.ui
к представлению пользовательскому сообществу. Описывая оставит >
прецеденты использования и прочие требования, проектируя де и и.
конструкции, завершая реализацию и тестируя программу, создайте первм-
работающую версию системы (бета-релиз). Выясните, готова ли программ,
площадка (сайг), а так же пользователи к развертыванию приложения.
Фаза Построение и ее итерации
Число требуемых итераций для фазы Построение изменяется от про<т. i>
к проекту, но в большинстве случаев Построение содержит больше итераций, ч, ,
любая другая фаза (обычно от двух до четырех) (см. гл. 12 раздел «Определена
числа итераций»).
Планирование итераций Что же включает в себя каждая итерация? Планирование и icp
и высокой степени обу- в ВЬ|СОКОй степени обусловливается тем, какие группы ир
с.ловливается наиболее
важными для заказчика
труппами прецедентов
цедентов использования должны быть реализованы. Желаю и
но реализовывать те прецеденты, которые наиболее важны ,i ы
использования, а также заказчика или связаны с наибольшими техническими рисками
теми группами, которые Особенно в первой итерации (а в определенной степени и и.
связаны с наибольшим второй) начинайте с частичной реализации прецедентов исио и
техническим риском.
зования (то есть реализуйте только некоторые сцснарп
в прецеденте) с целью побыстрее избавиться от возможно большего числа piiiri,
и получить приемлемую реализацию, до того как вдаваться в детали. Приняв рспи
пне о том, какие прецеденты реализовывать или частично реализовывать, опрсдеш
тс, взаимодействие каких компонентов требуется для обеспечения функционалы^
сти выбранных прецедентов использования. Именно эти компоненты должны oi.m
спроектированы, реализованы и протестированы в этой итерации. Это позволш в.г>
лучше понять, какое время потребуется для реализации прецедентов использовали
и нужно ли (на основе имеющихся ресурсов) изменять границы работ для .......
итерации.
Давайте предположим, что у вас есть 15 прецедентов использования и в <]>л „
Построение планируется три итерации. Как нужно действовать? В таблиц,
приведенной ниже, показан возможный план, описывающий, что уже имею.’
в начале фазы Построение (т.е. результаты на конец фазы Проектирование) и чв
происходит в каждой из трех итераций Построения.
Фаза Построение
167
Тип 8.1 Состояние проекта в начале фазы Построения и после всех ее итераций.
Уточнение требований, разработка компонентов и тестирование выполняются во всех
итерациях. К концу фазы Построение у вас будет первая работающая версия (бета-
1>е.’1чз) системы
Требования Компоненты Тесты Конец Проектирования
Выявлено 15 прецеден- • Определено 18 главных компонентов • Проведены первичные
гов использования (ПИ)’ • В 4-х из них реализовано 50% кода, включая нагрузочные тесты и тесты
8 ПИ описаны 1 детально, 4 довольно шубоко и 3 кратко все интерфейсы производительности. ;• В 10 реализованы интерфейсы и минимум Тестировались главным логики (приблизительно 10-20% образом ! окончательного объема кода) архитектурнозначимые ПИ ' • Нижние уровни архитектуры практически Должным образом . полностью реализованы протестирована функциональ- • Реализованный код прошел модульное ность4-х тестирование архитекгурнозначимых ПИ
, 12 ПИ описаны ; детально, Конец первой итерации фазы Построение !• Определено 18 главных компонентов (один ;• Продолжаются нагрузочные оказался ненужным из-за того, что был уда- ! тесты и тесты производитель-
3-достаточно глубоко; лен ПИ) • ности, чтобы гарантировать
• 10 практически полностью реализованы , стабильность качества 1 • В 8 реализовано 50% кода, включая все архитектуры ; интерфейсы ,• Проводятся функциональные • В 8 есть реализованные интерфейсы тесты ПИ по мере их ' и минимум логики (приблизительно, завершения 10-20% окончательного объема кода) • • Нижние уровни архитектуры практически полностью реализованы i • Реализованный код прошел модульное ; тестирование Конец второй итерации фазы Построение
168
Гллг.л
iabue 8.1 Состояние проекта в начале фазы Построения и после всех ее нтеращ',.
Уточнение требований, разработка компонентов и тестирование выполняются во ,
итерациях. К концу фазы Построение у вас будет первая работающая версия (йти..
/'< hi:) системы (Продолжение)
Требования Компоненты Тесты
Один из 3-х еще не описанных ПИ, выве- ден за рамки проекта из-за ограничений времени • Остальные 14 ПИ опи- саны подробно • Определены 18 главных компонентов (один • Продолжаются нагрузочный оказался ненужным из-за того, что был уда- тесты и тесты производи лен ПИ) тельности, чтобы • 10 практически полностью реализованы гарантировать стабильносп. • В 8 реализовано 50% кода, включая все качества архитектуры интерфейсы • Проводятся функциональны! • Реализованный код прошел модульное тесты ПИ по мере их тестирование завершения Конец третьей итерации фазы Построение
• 14 ПИ описаны подробно • Определены 18 главных компонентов Продолжаются нагрузочные • Система полностью функциональна. Готов тесты и тесты производи бета-релиз тельности, чтобы • Все 18 компонентов практически полностью гарантировать стабильносп реализованы (тонкая доводка и исправление качества архитектуры ошибок будут проводиться в ходе фазы • Проводятся функциональные Внедрение) тесты ПИ по мере их • Реализованный код прошел модульное ’ завершения тестирование
Цель 1. Снизить стоимость разработки и добиться определенного
параллелизма
Экономически эффективная разработка программного обеспечения является н<
чью всех фаз. Если вы начали думать об этом только в фазе Построение, вы не с\ю
жете достигнуть этого. Однако если вы верно провели Проектирование, то есть се
дали базовую надежно исполняемую архитектуру, вы можете создавать программ'
более экономически эффективно, чем в любом другом случае. Это возможно, пи
скольку вы можете повторно использовать архитектурные механизмы, рабо!ап
параллельно, организуя работу вокруг архитектуры (см. следующий раздел «Ори
низания вокруг архитектуры»), и вы встретитесь с меньшим числом неожиданна
с гей, поскольку вы снизили многие крупные технические риски. В этом разделе мп
Фаза Построение
169
рассмотрим некоторые существенные моменты, которые нужно учитывать в фазе
Построение (а возможно, и раньше) особенно для больших команд, чтобы обес-
печить успешное создание программного обеспечения.
Организация вокруг архитектуры
Одним из многих преимуществ надежной архитектуры явля-
йся то, что опа явным образом разделяет област и ответственно-
сти в системе на четко определенные подсистемы. У вас есть
архитектор или команда архитекторов), заботящийся об архи-
1скгуре и о том, как все в системе связано, а остальные люди мо-
Организация вокруг
архитектуры дает
людям возможность
не наступать на ноги
друг другу.
IVI сконцентрироваться на выделенных им подсистемах. Конечно, нужно, чтобы
разработчики понимали всю систему, но они могут сконцентрироваться в первую
очередь на своей части системы, то есть на одной или нескольких выделенных им
подсистемах. Организация вокруг архитектуры даст людям возможность не на-
щупать на ноги друг другу.
Организация вокруг архитектуры также облегчает общение. Естественно, что
Нпиболее эффективным общением является общение лицом клицу, но по мере
роста проекта вам приходится понижать необходимость общения, поскольку ме-
н>д «лицом к лицу» плохо масштабируется. Верхняя половина рис. 8.3 ноказыва-
ei, как много существует возможных ну гей коммуникации между членами коман-
ды (заметим, что с ростом команды это число растет в геометрической прогрес-
сии1). Для команды, размером в N, число путей коммуникации будет составлять
N.x(N-l)/2. Это означает, что в команде, состоящей из двух человек, есть один
Путь коммуникации, в команде из трех - 3 пути, а в команде из 6 человек - 15 пу-
icii коммуникации.
Рост числа путей коммуникации разрушает эффективность команды, рабо-
Iтощей над проектом, и нужно искать лучшие способы общения (иные, нежели
и*, где каждый общается с каждым). Этого можно достигнуть, если есть одна ко-
Мппда, отвечающая за архитектуру, и несколько небольших команд, каждая из ко-
1орых отвечает за одну или несколько подсистем. Общение между этими несколь-
кими командами осуществляется через команду архитекторов, которая занимает-
ся проблемами общего характера и вопросами взаимодействия между подсисте-
мами. Как можно видеть из нижней части рис. 8.3, это приводит к упрощению
I Опечатка авторов. Такая зависимость называется «квадратичной». - Примеч. науч. ред.
170
Глава ii
Команда
Команда
разработчиков
Команда
разработчиков
Команда
разработчиков
Команда
разработчиков
Команда
разработчиков
Рис. 8.3. Организация вокруг архитектуры снижает сложность общения. Число возможных пу н и
коммуникации между членами команд с увеличением размера команды растет в ни
метрической прогрессии. Организация вокруг архитектуры радикально снижает число m
тей коммуникации. Проблемы, касающиеся взаимодействия подсистем, решаются коман
дой архитекторов, которая владеет интерфейсами между подсистемами
общения, и делает его более эффективным даже в больших проектах. По тем же
самым причинам нужно иметь одну команду для интеграции.
Фаза Построение
171
Управление конфигурациями
Система управления конфигурациями
Систему управления конфигурациями (УК) нужно настроить в ходе фазы
Начало и усовершенствовать настройки в фазе Проектирование, когда закладыва-
лся основа архитектуры. Здесь мы расскажем, зачем нужна система УК и как она
поможет вам при Построении.
11о мере развития проекта он становится все более
сложным с точки зрения слежения за всеми версиями мно-
жества создаваемых и изменяемых файлов. Вы постоянно
создаете новые версии файлов, особенно при использова-
нии итеративной разработки, и вам потребуется помощь
11|>и выполнении таких задач.
• Итеративная разработка подразумевает частое создание
По мере развития проекта
он становится все более
сложным с точки зрения
слежения за всеми версия-
ми множества создаваемых
и изменяемых файлов.
выпусков, возможно,
даже ежедневное. Нужно отслеживать, какие версии файлов входят в каждый
выпуск. Иногда это последняя версия, иногда - более ранняя, поскольку работа
над новой версией еще не завершена.
• Итеративная разработка подразумевает, что вы будете пробовать разные реше-
ния и смотреть, можно ли улучшить то, что имеется. Потребуется объединять ус-
пешные решения в основном потоке разработки.
• По мере роста проекта важно уметь скрыть изменения, внесенные одной коман-
дой, от других команд, чтобы на них не повлиял негативно код, который пра-
вильно еще не работает. Вам понадобится иногда делать вашу работу видимой
для остальных несколько раз в день, а иногда-только каждые несколько дней.
• В больших проектах может понадобиться управление доступом к изменениям
определенного типа2.
• Если вы замечаете внесенный дефект, нужно иметь возможность вернуться на-
зад по времени и понять, когда этот дефект был внесен. Может также потребо-
ваться возможность быстро вернуться к более старым выпускам (builds)
и получить именно тот, который работает (если, например, внесенные накануне
вечером изменения в сайт электронной коммерции привели к сбою в системе).
2 Заметим, что хотя многие ведущие специалисты нашей индустрии предлагают открывать любому доступ
к изменению проектных решений или любого кода системы, наш опыт показывает, что такая практика не может
аффективно применяться, когда в проекте участвует больше 10 человек. - Примеч. авт.
172
ГЛАВА II
Решением будет использование системы управления конфигурациями, которлч
все это отслеживает. Нужно создать в такой системе «модули ответственности/ви
димости»3. Надежная архитектура окажется полезной и здесь, поскольку «моду ш
огветственности/видимости», как правило, привязаны к структуре подсистем
Ча настройку системы УК отвечает менеджер по конфигурациям.
Как только система УК настроена, члены команды могут меньше обращай
внимания на тысячи файлов кода и документов с их версиями и больше кон
центрироваться на главных задачах разработки, повышая таким образом свою
>ффективность.
Планирование интеграции
При использовании итеративной разработки постепенно становится все сложнее
планировать выпуски (builds) и тестирование интеграции. Для каждой итерации
нужно разработать План интеграции (Integration Build Plan), в котором указан
какие возможности можно будет протестировать в каждом выпуске, какие компо
центы потребуется интегрировать, чтобы получить эти возможности, к которым oi
носятся, например прецеденты использования, части прецедентов использование
и другие тестируемые функции. Набор тестов может включать в себя функционале,
иые, нагрузочные, стрессовые и другие типы тестов.
Во многих случаях выпуск создается путем постепенной интеграции несколе.
ких меньших выпусков. Как правило, это осуществляется методом движения спи
iy вверх по организованной слоями структуре подсистем в модели реализации
Для каждого выпуска определяйте, какие подсистемы должны входить в нсе<>
а какие нужно иметь в виде «заглушек» (т.е. кода, имитирующего необходимы!
возможности подсистемы) (рис. 8.4).
Укрепляйте архитектуру
Чтобы воспользоваться всеми плодами разработанной архитектуры, нужн"
активно укреплять ее. В небольших командах вы можете достичь этого с пом<>
щыо частых обсуждений вариантов конструкции. В больших командах этому с ь
дует уделять еще больше внимания.
Вы определили архитектурные механизмы, то есть повторно используем i.и
решения часто встречающихся проблем, таких как долговременное хранение и ш
взаимодействие между процессами. Теперь нужно удерживать всех разработчик ш
3 В Rational ClearCase это называется Versioned Object Bases (VOB). - Примеч. авт.
Фаза Построение
173
Прецеденты использования
и сценарии для текущей
итерации
з —Прикладной уровень
С
2 з —Реализация бизнес логики
Требуются «заглушки» \--------->. 2 --------Промежуточное
программное обеспечение
0 Л' > и
1 1 --------Системное
программное обеспечение
Ямс. 8.4. Инкрементное создание выпусков облегчает создание выпусков большой системы. Вы-
пуски больших систем часто образуются путем интеграции нескольких малых выпусков,
начиная снизу. На рисунке показан процесс интеграции трех выпусков: создать выпуск I,
протестировать, добавить выпуск 2, протестировать, добавить выпуск 3, протестировать
от своевольного изобретения собственных решений для таких проблем. Это можно
сделать путем проведения занятий по архитектуре и имеющимся архитектурным
механизмам, совмещенных с рецензированием проектных решений, при участии
архитекторов и разработчиков.
Нужно также гарантировать, что интерфейсы между подсистемами не будут
произвольно меняться и что обо всех изменениях будет сообщаться остальным
командам, чтобы свести к минимуму влияние на них. Такое информирование
можно производить с помощью системы Управление конфигурациями, под кон-
троль которой вы, как и другиее, помещаете свои изменения.
Обеспечьте непрерывный прогресс
Чтобы обеспечить непрерывное продвижение, нужно устанавливать крат-
ковременные цели и непрерывно показывать, что вы их достигаете. Приводимые
руководства являются доказанными рецептами успеха.
174
Глава я
• Создавайте одну команду, имеющую одну задачу. Нужно избегать создан in
функциональноориентированных команд, где аналитики организованы в одп\
группу и перебрасывают требования через стенку разработчикам, которые про
ектируют и реализуют требования и в свою очередь перебрасывают код черс
стенку тестировщикам, которые пытаются понять, что же нужно тестирован.
Вместо этого команды должны быть многофункциональными, где каждый член
команды чувствует ответственность за приложение и за успехи всей команды
Облегчить командную работу также поможет проведение кратких ежедневных
совещаний, на которых обсуждается текущее состояние и решается, на чем еде
Постоянные демон-
страции и тестирова-
ние исполняемого
кода - единственный
путь к прогрессу.
лать акцент дальше.
• Ставьте разработчикам четкие, достижимые цели. Каждый разработчик до i
жен иметь ясное представление о том, что нужно сделать в данной итерации
и даже в части итерации. Разработчики должны быть согласны с тем. что ожп
даемые результаты достижимы.
• Постоянно демонстрируйте и тестируйте код. Оценивап
те прогресс в первую очередь по тому, какой код скомнн
лирован и протестирован. Не удовлетворяйтесь фразами in
па «мы готовы на 90%». Постоянные демонстрации и ич
тирование исполняемого кода - единственный путь к про
грессу.
• Проводите интеграцию непрерывно. Если возможно, делайте выпуски еже
дневно. В больших проектах, проектах без системы УК или с плохой системки
УК ежедневное создание выпусков может оказаться нереальным. Частое cot
дание выпусков обеспечивает частое интеграционное тестирование, которое
позволяет оценить свежий код, написанный со времени последнего выпуск.i
Постоянная интеграция, как правило, также снижает увлечение лишней по
лировкой.
В наших трех учебных проектах происходит следующее.
• Проект «Ганимед», небольшой «зеленый» проект: как только бы ।
определен главный компонент (еще в фазе Проектирование), комап'ы
приняла решение о том, кто будет главным ответственным за его про
ектирование, реализацию и тестирование. Члены команды часто собираю h i
вместе, обсуждают архитектурные проблемы и проводят рецензирование про
сктных решений и их реализации друг у друга. В фазе проектирования они пл
строили систему УК, которая используется при создании ежедневных выпусков
Фаза Построение
175
• Проект «Марс», большой «зеленый» проект: группа разработчиков
разделена на три команды, каждая из которых отвечает за одну или
две главные подсистемы. Внутри команд также ясно, кто отвечает за
проектирование, реализацию и тестирование каждого компонента. В командах
проводятся еженедельные совещания, на которых обсуждаются архитектурные
проблемы. Архитектора постоянно привлекают к рецензированию работы раз-
ных команд и разрешению проблем по мере их возникновения. Система УК бы-
ла настроена в фазе Начало и мы используется при создании новых выпусков раз
в две недели.
• Проект «Юпитер», второй этап большого проекта: персонал разде-
лен на три команды, каждая из которых отвечает за одну или две X
главные подсистемы, которые были добавлены или в которых сдела- I'-'
ны крупные изменения. Внутри команд также ясно, кто отвечает за проектирова-
ние, реализацию и тестирование каждого компонента. Архитектора постоянно
привлекают к рецензированию работы разных команд и разрешению проблем
по мере их возникновения. Поскольку построение ведется на основе стабильной
архитектуры, решить придется лишь небольшое число архитектурных проблем.
Система УК в момент начала проекта уже была настроена и используется для
создания новых выпусков раз в две недели.
Цель 2. Разработать итеративным методом окончательный продукт,
готовый к представлению пользовательскому сообществу
Опишите оставшиеся Прецеденты использования и прочие требования
По мере реализации и тестирования прецедентов исполь-
зования вам часто будет нужно пересматривать по крайней
мере некоторые из детализированных требований и во мно-
гих случаях может даже понадобиться пересмотреть весь
прецедент использования, если вы нашли лучшее решение.
Если роли аналитика и разработчика выполняют разные
люди, им будет нужно совместно обсудить, каким образом
Для создания действи-
тельно хороших прило-
жений важно, чтобы
был открытый диалог
между аналитиками
и разработчиками
и нтерп рети ро вать
1ребования, если они не ясны или их формулировку можно улучшить. Аналитики
должны иметь хорошо понимать деловые нужды, но у них могут возникнуть
проблемы с поиском оптимального решения (у них может быть «зашоренный»
пзгляд на то, как делается бизнес сегодня). Во многих случаях разработчики мо-
176
Глава
n । посмотреть свежим взглядом и предложить новые, передовые методы решс
пня выявленных деловых задач. Для создания действительно хороших приложс
miii важно, чтобы был открытый диалог между аналитиками и разработчиками
ынорый позволит не потерять свежую точку зрения, которую могут дан
ра фаботчики.
При Проектировании обычно опускаются неглавные прецеденты использования
а иноке те, которые не оказывают влияния на архитектуру. Например, если общая
функция печати уже реализована и есть прецедент использования, описываюпцш
р.п югу с некоторой информацией, вы можете быть практически уверены, что добаи
и нне прецедента использования для печати этой информации нс окажет существен
1юк1 влияния на архитектуру. Также в некоторых системах есть много сходны,
прецедентов использования, обеспечивающих в общем одну и ту же функционал,
носи,, но для разных элементов или акторов, с разными пользовательскими ин
1срфейсами. Детальное описание таких типов прецедентов использования час",
опавляется на фазу Построение вместе с частично описанными прецедентами
io есть такими, в которых был подробно расписан только основной поток событии
H ili несколько потоков, но не все.
Многие нефункциональные требования, такие как требования к производитель
нос । и или к стабильности приложения, существенны для создания правильной архи
|смуры, и большая часть их должна быть хорошо описана к концу фазы Прост
шровапие. Вам, однако, может понадобится добавить или расширить некоторые
и них по мере того, как вы больше узнаете о системе.
Завершайте проектирование
В фазе Проектирование вы определили подсистемы и их интерфейсы, ключевьн
компоненты и их интерфейсы и архитекгурные механизмы. Если ваша архитекту р.>
opi анизована слоями, то вы реализовали или приобрели наиболее сложную час и
нижних слоев - инфраструктуру, а также архитектурно значимые прецеденты ш
поиьзования.
б и, ки/ьных итерациях
//, г т/хю/ия делайте акцент
м lx >рьбе с самыми круп-
ными рисками, в более
м I. дних итерациях концен-
ц iH/iytiiecb на полноте.
Во всех итерациях Построения сконцентрируйтесь на зл
вершении проектирования набора компонентов и подсишем
и набора прецедентов использования. (Подробнее см. гл. I '
разделу «Проектирование реализаций прецедентов исно и.
зования и компонентов»). Когда вы будете реализовыв.п i
компоненты (состоящие первоначально из интерфейс!т
и «заглушек»), то в результате улучшения понимания сны с
Фаза Построение
177
мы вы почувствуете необходимость создать дополнительные вспомогательные ком-
поненты. В начальных итерациях Построения делайте акцепт на борьбе с самыми
крупными рисками, в частности теми, которые связаны с интерфейсами, прончноли-
И'льностью, требованиями и удобством применения. В более поздних итерациях
Построения концентрируйтесь на полноте, пока вы в конечном итоге не спроек-
тируете, реализуете и протестируете все сценарии выбранных прецедентов исполь-
зования.
Спроектируйте базу данных
В фазе Проектирование вы создали первую, черновую, реализацию базы дан-
ных. В ходе Построения можно добавить к таблицам новые колонки, можно соз-
дпгь представления, чтобы упростить выполнение т ребованпн к запросам и отче-
И1М, можно сделать индексы для оптимизации производителыюсги. но крупной
реструктуризации таблиц быть не должно (это было бы знаком того, что архшек-
iypa не стабилизирована, и переход к фазе Пост роение был преждевременным).
Реализуйте код и проводите модульное тестирование
Планирование итераций в первую очередь определяется гем, какие нрецедешы
Использования решено реализовывать и тестировать и когда. Реализация прецеден-
тов использования осуществляется покомпонентно. Вообще говоря, к тому време-
ни, когда вы переходите к Построению, некоторые компоненты уже реализованы
Полностью или частично. Если архитектура системы организована слоями, уже реа-
лизовано большинство компонентов нижних слоев. На рис. 8.5 показано, как реали-
1Пцпя компонентов обычно развивается со временем.
Разработчики должны постоянно тестировать результаты своей разрабтки
Н убеждаться в том, что их поведение соответствует ожидаемому. Для тестирова-
ния компонентов может потребоваться реализация тестовых драйверов и тесто-
йых «заглушек» для эмуляции других компонентов, которые будут взаимоденст-
Цопать с данным. Автоматически сгенерировать такие тестовые драйверы и «за-
глушки» может средство визуального моделирования. Получив «заглушки», вы
Сможете прогнать множество тестовых сценариев. Обычно тестовые сценарии
Создаются па основе сценариев прецедентов использования, в которых задейст-
вуются данные компоненты, поскольку сценарии прецедентов определяют то.
Клкпм образом компоненты будут взаимодействовать е пользователями, рабо-
178
ГЛАПЛ II
нпощими с приложением. Также нужно проверить нефункциональные требонл
пня и понять, какие еще ограничения необходимо протестировать.
Рис. 8.5. Эволюция компонентов во времени. Со временем компоненты становятся все более н ш.
лее полными, притом компоненты нижних слоев завершаются быстрее. Нужно реалии,
вать некоторые высокоуровневые компоненты, которые позволят получить доступ к ни >
ним слоям, и провести эффективное тестирование низкоуровневых компонентов
Проводите интеграцию и системное тестирование
11ри создании выпуска компоненты интегрируются в порядке, указанном в Пиши
шнеграции. Как правило, перед тем как будет выполняться полное тестировано,
выпуск подвергается минимальному интеграционному тестированию, котор...
проводит группа интеграции (подробнее см. гл. 18).
Для повышения качества проводите интеграцию и тестирование системы поен,
явно. Чтобы снизить стоимость, тестов нужно автоматизировать регрессионно,
юстирование, что позволит проводить сотни и тысячи регрессионных тестов им
щего выпуска ежедневно или еженедельно. Это обеспечит быстрое обнаружени.
новых дефектов. При тестировании будет полезно выполнить следующие шаги:
Фаза Построение
179
• Проанализируйте план итерации и выявите цели тестирования, чтобы убедить-
ся, что вы надлежащим образом тестируете то, что создается в данной итерации.
• Выявите идеи тестирования, т.е. составьте список идей, в котором перечислите
потенциально полезные тесты. Идеи ищутся в различных источниках, таких как
список рисков, запросы на изменения, прецеденты использования, другие арте-
факты-требования, модели UML и т.д.
• Проанализируйте идеи тестирования и выберите из них часть, по которой соз-
дайте прецеденты тестирования. Определите входные и выходные данные, усло-
вия выполнения, точки наблюдения и контроля. Анализируя все прецеденты тес-
тирования, вы определите общую архитектуру автоматизации тестов, включая
общую структуру важных тестовых компонентов и тестовых скриптов. Вы так-
же поймете, как распределить тесты (создаваемые на основе прецедентов тес-
тирования) по наборам.
• Реализуйте тесты (вручную или автоматически) для каждого прецедента тес-
тирования. Распределяйте тесты по наборам тестов и затем выполняйте их.
• Анализируйте неудачи при тестировании и зарегистрируйте дефекты и запросы
на изменения.
Раннее внедрение и обратная связь
Частое создание выпусков заставляет постоянно проводить
интеграцию и проверять работоспособность кода. Интеграция и
Тестирование системы также выявляют многие проблемы
качества. Кроме этого, крайне важно иметь обратную связь, по-
казывающую, что приложение можно использовать и оно рабо-
тает' так, как нужно. Для этого его предъявляют реальным
Крайне важно иметь
обратную связь. Для
этого приложение
предъявляют реаль-
ным пользователям.
пользователям.
Например, может быть так, что приложение работает в соответствии с требования-
ми, но требования не совсем осмысленны. Это особенно важно при разработке
приложений, не имеющих аналогов, или приложений из незнакомой области, когда
|рудно оценить, в чем состоят реальные требования.
Часто будущие пользователи системы не хотят или не имеют возможности
Тратить время на ранние версии приложения. Может, например, оказаться трудно
убедить даже одного пользователя потратить время на обратную связь с вами, по-
скольку выгоды этого для пользователя неочевидны. Так часто бывает при создании
коммерческих продуктов, когда характерные признаки будущих пользователей неиз-
180
Глава и
иестны. На ранних стадиях Построения приложение может быть сложным в испош.
«танин, тяжелым для инсталляции и переполненным запретными действиями h.i
сюлько, что трудно отдать его в руки конечным пользователям без того, чтобы ни
с юянно не держать их за руку.
Исходя из своей потребности в обратной связи и возможностей заказчик, >«
предоставить ее, вам следует выбрать правильный подход к ее получению, котор|.ш
иуде г полезен как команде разработчиков, так и будущим пользователям системы
К 1аким подходам можно отнести следующие:
• привести нескольких пользователей туда, где проводится разрабоны
и продемонстрировать ключевые возможности;
• привести нескольких пользователей туда, где проводится разработка, и дать им
какое-то время попользоваться продуктом;
• установить программу на тестовой площадке и сидеть рядом с пользователями
при их работе с программой;
• предоставить некоторым пользователям ранний доступ для приложений, доем,
к которым возможен по сети. Вам, вероятно, потребуется направлять пользою
юля в его работе с приложением, которое может быть нестабильным и не очсш
интуитивно понятным на этой стадии.
Типичными результатами раннего внедрения и наличия обратной связи являсп „
проверка, верны ли требования или их нужно изменить, сведения от пользователе!!
но удобству применения и производительности, атакже выявление недостающи'
возможностей.
Тестирование в той же среде, в которой осуществляется разработка, коюр.н!
часю ие совпадает с целевой (рабочей) средой, может дать обманчивые резуи
iaii.i. Организациям, осуществляющим тщательный контроль качества, мо*о
понадобиться вложить средства в отдельную среду, которая эквивалент.,
рабочей среде. Такая имитационная среда позволяет часто тестировать выпуски
п получать более точные результаты.
Подготовка к выпуску бета-версии
Ныпуск бета-версии -
, по «нредрелизное» тес-
тропание, при котором
целевой ауди-
юрии проводит апро-
бирование продукта.
Выпуск бета-версии - это «предрелизное» тестирование, при
котором часть целевой аудитории проводит апробировапи,
продукта. Развертывание бета-версии проводится в кони,
фазы Построение и является сутью фазы Внедрение. Уснсн!
ную бета-версию программы нужно подготовить в <|>.т
Построение.
Фаза Построение
181
Бета-тестирование служит двум целям: во-первых, тестируется контролируе-
мая реальная реализация приложения, во-вторых, обеспечивается предваритель-
ный просмотр готовящегося релиза. Менеджер по развертыванию (deployment
manager) должен следить за программой бета-тестирования и обеспечить выпол-
нение обеих этих целей.
Важно иметь представительную выборку из целевой аудитории, в ней обяза-
|сльно должны быть новички и опытные пользователи, пользователи, рабо-
цнощие в разных средах и имеющие разные нужды. Такое разнообразие обес-
печит хорошее тестирование всех аспектов продукта.
Также важна полнота продукта, которая оценивается на основе управления
1раиицами, которое проводилось в ходе итераций. Притом что должны быть реа-
лизованы все свойства, допускается наличие некоторых нерешенных проблем,
например нестабильного элемента (если он не вызывает потерю данных), не
очень четких инструкций в файле помощи или диалоговом окне или частичной
реализации редко используемой функции. Нужно включить в комплект инструк-
ции по инсталляции, руководства пользователей, учебные пособия и обучающий
материал, иначе вы не получите по ним обратной связи от бета-тестировщиков.
|акой сопроводительный материал важен, но к сожалению его часто не предос-
11111ЛЯ1ОТ.
Подготовка к окончательному развертыванию
Во многих проектах подготовку к окончательному развертыванию нужно вес-
III в фазе Построение (а иногда и раньше, в фазе Проектирование). Такая нодго-
|ивка, как правило, включает (подробнее см. гл. 9).
• Создание материалов для обучения пользователей и обслуживающего персона-
ла, чтобы в дальнейшем пользователи могли быть уверены в своих силах.
• 11одготовка площадки (сайта) для развертывания и конвертирование рабочих баз
данных. Чтобы запустить новую систему, может понадобиться закупить новое
аппаратное обеспечение, выделить для аппаратуры место или конвертировать
данные из прежних систем в новую.
• 11одготовка к запуску: подготовка упаковки и тиражирования; подготовка
к передаче материалов подразделениям маркетинга, к распространению,
н продажам; подготовка к обучению «полевого»4 персонала. Такой набор задач
4 Персонал, который будет выезжать к заказчикам на установку и запуск продукта. - Примеч. науч. ред.
182
Глава в
поможет выпуску продукта, особенно в случае коммерческого программное,
обеспечения.
Для трех наших учебных проектов работа в фазе Построение, касающаяся ко
шрования, интеграции и тестирования, по сути, не различается, за исключением
числа задействованных людей. Однако существуют различия в задачах, относя
щихся к развертыванию, которые приводятся ниже.
• Проект «Ганимед», небольшой «зеленый» проект: команда рабою
ет в тесном контакте с будущими пользователями системы и грани
I довольно значительное время на демонстрацию заказчикам прси>
дентов использования после их завершения и тестирования. При ы
ком взаимодействии команда получает множество идей по улучшению прило/i
пня. Поскольку число пользователей системы будет невелико, и команда ради
ботки будет активно привлекаться к развертыванию и поддержке приложения
па подготовку к бета-релизу и выпуску окончательной версии время почт ю
тратится.
• Проект «Марс», большой «зеленый» проект: поскольку продую
» Гхх дет поставляться в 37 офисов по всему миру, важно получать давши
IV' из разных офисов. Команда разработки определила восемь челов, <
па трех разных континентах, представляющих как большие, так и малые офш и
и сделала их дополнительной частью команды. Ежемесячно они проходишь >
по достигнутому и демонстрировали новые возможности. Такой процесс о<»<
печил полезную обратную связь, особенно для понимания того, насколько р.п
личны нужды пользователей в разных офисах и в разных странах. К концу фа и1
Построение была назначена неделя обучения для этой дополнительной чаши го
манды, чтобы люди смогли приобрести навыки для работы с локальной нем
версией программы в каждом из восьми офисов.
*4^ • Проект «Юпитер», второй этап большого проекта: поскольку up"
дукт коммерческий, нужно, войдя в тесный контакт с продави.пш
определить несколько ключевых заказчиков, которые пожелали
провести развертывание бета-версии продукта. Некоторым из этих бета-зам го.
ков предъявляется внутренняя (альфа) версия. Для облегчения работы с ней ч
ны группы разработки выезжают на место, инсталлируют и помогают saiiv imi
ее. Это обеспечивает достаточно раннюю и весьма полезную обратную свя л.
Фаза Построение
183
Рецензирование проекта. Веха начальной функциональной готовности
Фаза Построение завершается важной вехой (контрольной точкой), Вехой
Начальной функциональной готовности, которая используется для определения, го-
тов ли продукт для выпуска в бета-тестирование. Для этого нужно ответить (среди
Прочего) на следующие вопросы:
• Является ли данный релиз стабильным и зрелым настолько, что его можно
предъявить сообществу пользователей?
• Готовы ли все заинтересованные лица к передаче продукта в сообщество пользо-
вателей?
• Приемлемо ли все еще соотношение реальных и запланированных расходов?
Если проект не может достигнуть данной вехи, может потребоватся отложить
фичу Внедрение и добавить еще одну итерацию к фазе Построение.
1аключение
В ходе Построения, третьей из четырех фаз RUP, вы продвинулись очень дале-
по сравнению с тем, что было в конце фазы Проектирование. Если фаза
Построение была успешной, у вас уже сделано следующее.
• Вы экономически эффективно разработали программное обеспечение, восполь-
зовавшись преимуществами архитектурной основы (включающей в себя архи-
тектурные механизмы), созданной в фазе Проектирование. Организовав коман-
ды вокруг архитектуры, вы достигли высокой степени параллелизма в их работе.
• Вы смогли расширять проект, включая в него по мере необходимости новых
людей, поскольку имели надежную архитектурную основу в качестве отправной
точки, и поскольку организовывали работу вокруг архитектуры.
• Вы создали и проверили несколько внутренних релизов, обеспечив удобство ис-
пользования системы и соответствие ее нуждам пользователей.
I Вы перешли от исполняемой архитектуры к первой работоспособной версии
системы. У вас есть полнофункциональная бета-версия системы, включая сред-
ства инсталляции, документацию и учебный материал.
л i
4'
ГЛАВА 9
Фаза Внедрение
/.’ Фазе Внедрение
hi I, наводится тонкая
и. л т{юйка функций
и производительности
и i овершенствование
к гк 'шва системы.
В этой главе мы представляем четвертую и последнюю <|>.i ч
жизненного цикла RUP, фазу Внедрение (Transition) (рис. '» I i
Читая эту главу, помните, что вам нужно решить, насколы"
формально вы хотите подходить к разработке артефактов: ни
можно делать в уме, па письменной доске, в модели или дом
менте. Фазу Построение вы закончили созданием полнофуш
шюпальной бета-версии системы, включающей программу установки, докумсн
laiuiio и обучающие средства. Вы знаете, что эта версия не конечный про,т\ш
в пей необходимо провести тонкую настройку функций и производительно»iи
и совершенствование качества системы.
Начало t . Проектирование
Построение
Внедрение J - ; )
Время
Веха целей Веха архитектуры
жизненного цикла жизненного цикла
Веха начальной Веха готового
функциональной продукта
готовност и
Рис. 9.1. Фаза Внедрение. Внедрение - четвертая и последняя фаза жизненного цикла в RUP ' ы >
имеет четко определенный набор целей и завершается вехой Готового продукта. r-)i и н> и.
помогуз нам решить, какие задачи выполнять и какие артефакты создавать
Фаза Внедрение
185
В фазе Внедрение акцент делается на обеспечении полного соответствия
Программного обеспечения нуждам пользователей. Фаза Внедрение, как правило,
унимает одну-две итерации, в которые входят тестирование продукта для подго-
товки к выпуску и внесение небольших усовершенствований па основе обратной
•инзи с пользователями. К этому моменту жизненного цикла должны быть решены
(кт крупные архитектурные проблемы, и общение с пользователем должно иметь
Щипшой целью тонкую доводку, конфигурирование, настройку процедуры инстал-
йлнии и устранение сложностей с использованием. В более сложных проектах фаза
Нпсдрение может иметь несколько итераций, каждая из которых создает все более
«ннсршенную, все более готовую к выпуску версию системы. Часто в фазе
внедрение приходится завершать реализацию какого-нибудь свойства, отложенную
jyiH того, чтобы успеть к какому-то более раннему сроку.
Следует отметить, что фаза Внедрение в RUP радикально отличает ся ог тради-
упонной разработки в первую очередь потому, что вы входите в фазу с прак-
тически стабильной, интегрированной и протестированной версией системы.
||ря традиционном каскадном подходе, напротив, конечная фаза интеграции час-
то начинается с больших проблем. Иногда даже не удается скомпилировать систе-
му целиком, интерфейсы между подсистемами оказываются несовместимы или
I гпегеме часто происходят сбои. Это приводит к необходимости крупных
Переделок и нескольким неделям задержки, прежде чем система заработает и бу-
Де। готова к тестированию. Получившаяся задержка заставляет менеджеров
Трпгпть массу времени на повторное согласование требований и сроков
| основными и заинтересованными лицами.
Цели фазы Внедрение
Фаза Внедрение имеет следующие цели.
I Провести бета-тестирование для проверки соответствия программы
ожиданиям пользователей. Это обычно требует выполнения задач по
настройке, например, таких как исправление ошибок и внесение усовершен-
ствований для повышения производительности и удобства использования.
|. Научить пользователей и обслуживающий персонал работать самостоя-
тельно. Эти задачи гарантируют, что в организациях, применяющих
программное обеспечение, будет достаточно квалифицированный персонал
для использования системы, для переноса всех необходимых данных из
186
Гллнл 'I
прежних систем и будут предприняты все меры, необходимые для успешной
работы новой системы.
Подготовить площадку (сайт) для развертывания и конвертирован,
рабочие базы данных. Для запуска новой системы в производство можш
потребоваться закупка нового оборудования, подготовка места для него или
перевод данных из старых систем в новую.
I. Подготовить упаковку, тиражирование, маркетинговые материалы,
выпуск в дистрибуцию и продажу. Обучить «полевой» персонал. Такой
набор задач поможет выпуску продукта, особенно в случае коммерческою
программного обеспечения.
' Достичь соглашения между заинтересованными лицами в том, что базис
для выпуска готов и соответствует критериям оценки, определенным
в концепции.
(>. Повысить производительность при выполнении будущих проектов на
основе приобретенного опыта. Сюда входит документирование опыта и
внесение улучшений в процесс и инструментальную среду.
Итерации внедрения и циклы разработки
Фаза Внедрение и итерации
/ ’> и :д/)оние может пред-
пона/агь параллельную
/ т Нюту старой и новой
тчнмй, перенос дан-
ник, обучение пользова-
н лей и корректировку
hii.nюс процессов.
Фаза Внедрение может быть как очень простой, так и крайне
сложной, в зависимости от продукта (рис. 9.2). Новый рели»
программы для настольного компьютера может быть очень
простым, требующим лишь исправления небольших ошибок,
сделать это можно за одну итерацию. Однако замена системы
контроля за движением воздушного транспорта может ока
заться чрезвычайно сложной, требующей нескольких
шераций, в ходе которых приходится добавлять новые функции и проводить пн
lei рацию с другими системами, выполнять сложные задачи по переводу веек»
отвеса со старой на новую систему. Такой перевод может включать параллель
пую работу старой и новой версий, перевод данных, обучение пользователей
и корректировку бизнес процессов.
Задачи, выполняемые в итерациях Внедрения, зависят от целей проекы
В большинстве проектов фаза Внедрение достаточно проста - работа над иенраи
пением ошибок, при акценте, в первую очередь на реализации и тестировании
Фаза Внедрение
187
Время от времени приходится добавлять новые свойства, и тогда итерация сгапо-
Иигся похожа на итерации фазы Построение в том, что требуется некоторая рабо-
III над требованиями, анализом, дизайном и т. п.
Простая система
Рис. 9.2. Число итераций во Внедрении. Число требуемых итераций фазы Внедрение может быть
различным: В простой системе, в которой нужно исправить только небольшие ошибки,
может хватить одной итерации. В сложной системе, например такой, как система управле-
ния движением воздушного транспорта, может понадобиться несколько итераций, для то-
го, чтобы добавить новые свойства и выполнить сложные задачи по переводу бизнеса со
старой системы на новую
При разработке коммерческих продуктов, а также иногда и приложений для
широкого внутреннего использования, нужно заниматься подготовкой упаковки,
। нражированием, маркетингом и возможной передачей продукта организации, зани-
188
Глава ч
мающейся продажей и поддержкой продукта. Более подробно все это описываем '
в разделе «Цель 4: Подготовить упаковку, тиражирование, маркетинговые материн и
выпуск в дистрибуцию и продажу».
При разработке приложений, для которых требуется много нового оборудовать,
например, крупных систем обработки финансовой информации, или если требуем ।
перенос данных со старых систем на новые, нужно заняться задачами, описываемы
ми в разделе «Цель 3: Подготовить площадку (сайт) для развертывания и ып
вер тировать рабочие базы данных».
Дня очень сложных проек- Д;|Я очень сложных проектов может потребоваться поэтапна.
юн может потребоваться передача, при которой каждый новый этап обеспечивает все •
/ к и/энная передача, при лее полную и качественную версию системы. Такой подход м< ’
ко юрой каждый новый жет быть необходим в тех случаях, когда единственным сшч"
э/ан обеспечивает все бОм TOHKOfl настройки системы является получение сведении
(кшее полную -г
о ее реальном использовании. 1акои метод ооыкновенно ...
и качественную версию
оие/емы пользуется в крупномасштабных информационных систем.,
управления, командных и контрольных системах, когда нужн'
производить тонкую настройку и интеграцию в системах, требующих распределен
ного развертывания и наличия сложного оборудования. Итерации Внедрения в таки -,
случаях будут выглядеть во многом сходно с одной-двумя последними итерациями
11осгроения (гл. 8) еще и при дополнительной сложности из-за необходимости унр;ш
ияп> распределенным развертыванием. Описание сложностей проектов такого ним
выходит за рамки этой книги.
Внедрение и циклы разработки
К концу фазы Внедрение цели фазы должны быть достигнуты, и проект должен
подойти к завершению. В некоторых проектах завершение текущего жизненною
цикла может совпадать с началом следующего, ведущего к созданию следующею
поколения этого же продукта. В других проектах конец фазы Внедрение может сон
падать с полной передачей артефактов третьей стороне, которая будет отвечаю ы
функционирование, поддержку и совершенствование выпущенной системы.
Один проход по всем четырем фазам RUP (Начало, Проектирование, Пострю
пне, Внедрение) называется Циклом разработки1 (Development Cycle). К коню
Внедрения вы завершаете цикл разработки (рис. 9.3). Каждый цикл разрабоп и
создает поколение (generation) программного обеспечения. Если продую и.
I. Для больших систем употребляется также название «Этап развития». - Примеч. науч. ред.
Фаза Внедрение
189
} Начало У Проектирование i[ Построение li Внедрение Ь Развитие ! :
Время - " /“"х ‘‘К
_ _ . - j Поколение 1
Начало-цикла разработки । 4 ч
; • Начало и Проектирование h Построение '•< Внедрение ц Развитие s i
। Время ’
- - t Поколение 2 4
I '
* Продолжение цикла разработки j
ЙС. 9.3. Циклы разработки. Цикл разработки состоит из ординарного прохода через четыре фазы
RUP, обычно разбитые на от пяти до девяти итераций, за которыми следует другой Цикл
разработки (эволюционный цикл). Во многих случаях фаза Начало эволю-циошюго цикла
перекрывается с фазой Внедрение существующего цикла
«умирает», начинается разработка следующего поколения продукта. При этом
повторяется та же самая последовательность фаз Начало, Проектирование, По-
строение и Внедрение, но с другими акцентами в каждой фазе, как того требуют
Новые цели проекта. Такие последовательные циклы называются эволюционны-
ми циклами (см. также гл. 12).
Между двумя циклами разработки часто бывают перекрытия, когда фаза Начало
Следующего цикла накладывается на фазу Внедрение предыдущего. Можно не соз-
давать перекрытий вообще или делать их большими, но запуск следующего цикла
«долго до фазы Внедрение текущего вносит значительную сложность, разрешение
Шпорой требует наличия зрелой организации разработки и продвинутых техноло-
гий Управления конфигурациями.
Притом что основное развитие системы обычно выполняется в форме проек-
тов, использующих жизненный цикл RUP с его четырьмя фазами, многие систе-
мы затем просто переходят в иной режим, в котором функционирование системы,
Се поддержка и обслуживание осуществляются на постоянной основе, и зависят
Главным образом от внешних запросов, а не от заранее определенных фаз и вех.
Релиз, выпущенный в целях исправления ошибок, может принимать форму очень
Простой итерации, сходной с теми, которые выполняются в фазе Внедрение. При
Тюм решается небольшое число задач RUP по реализации, тестированию
И развертыванию2.
? См. Kruchten 2000b.
190
Глм .л ч
Цель 1. Провести бета-тестирование для проверки соответствия
программы ожиданиям пользователей
Фиксирование, анализ и реализация запросов на изменения
Первая работающая версия системы — бета-релиз - к концу фазы Построены
ынершена и развернута. На протяжении фазы Внедрение вы выполняете бета-io
шрование, которое дает массу сведений о точке зрения пользователей, получаемы
!>i бета-тестировщиков. Чтобы эта обратная связь оказалась полезной, проводите .и
ппшый сбор сведений посредством опросов, онлайновых консультаций, анализ
представленных запросов на изменения и прочими способами. Нужно потрашп
время на анализ этой информации, на рецензирование запросов на изменения, ч пте ।
еще до окончательного выпуска продукта понять, какие нужно сделать изменения
Запросы на изменения (главным образом выявленные дефекты и информация
не га-тестировщиков) являются главными исходными данными для продолжеши
разработки. В первую очередь запросы на изменения касаются лишь небольших и.,
с i роек системы, например исправления мелких ошибок, улучшения документации
и учебного материала или настройки производительности. Иногда приходится т*
опалять дополнительные свойства, что требует работы с требованиями, ана.чп' ।
и проектирования (см. гл.8 раздел «Разработать итеративным методом окончат в
ный продукт, готовый к представлению пользовательскому сообществу»).
11ужно заметить, что добавление новых свойств на таких поздних стадиях прост i.
может указывать на ошибки в ранних фазах, но может быть и вполне мотивировяп
ним, особенно для очень больших и сложных систем. В большинстве случаев еле i,
ci воздерживаться от добавления новых свойств, сдвигая их на следующий цикл ( ны
пюционный) разработки. Однако в некоторых случаях систему нельзя успешно но
пустить без дополнительного свойства.
При реализации запросов на изменения необходим хороший процесс Упраии
пня конфигурациями, а также исчерпывающее регрессионное тестирование Н>
этой стадии обычными источниками дефектов являются выпуски с неверным!'
версиями файлов или с пропущенными файлами. Хорошая практика управлении
конфигурациями и хорошие инструменты радикально уменьшают число oiuiii>"i
ткого типа, а исчерпывающее регрессионное тестирование быстро выявляет ыв
сенные дефекты.
Фаза Внедрение
191
В фазе Внедрение нужно потратить довольно много времени на улучшение
документации, онлайновой справочной системы, учебного материала, руководств
Пользователя, справочных руководств и прочей документации поддержки. Важ-
но, чтобы реальные бета-тестировщики должным образом протестировали все
»ги элементы в среде, в которой система будет функционировать.
Тестирование в фазе Внедрение
В фазе Внедрение акцент тестирования смещается на повышение качества
Н контроль регрессии. Кроме того, часто существует требование проведения
формального приемочного тестирования, в которое может входить повторение всех
Или же части тестов системного уровня. При планировании тестов фазы Внедрение
Нужно направить силы и средства на следующее:
• продолжение проектирования и реализации тестов с целью поддержать веду-
щуюся разработку;
• регрессионное тестирование, которое потребует различных усилий и средств
в зависимости от избранного подхода. (Например - протестировать все заново
или протестировать заново функциональный профиль);
» приемочное тестирование, которое может не потребовать создания новых тестов.
По мере того как ошибки исправляются и используется информация от бета-
Тестировщиков, последовательные выпуски тестируются с использованием стан-
дартного тестового цикла.
• Проверка стабильности выпуска. Выполните набор тестов и убедитесь, что
выпуск достаточно стабилен для того, чтобы начать более подробное тестиро-
вание и оценку.
Тестирование и оценка. Реализуйте и выполняйте тесты, оценивайте их ре-
| зультаты.
» Достижение целей тестирования, или, говоря терминологией RUP, прием-
лемое выполнение миссии. Оценивайте результаты тестов с точки зрения це-
лей тестирования и, если необходимо, проводите дополнительные тесты.
• Совершенствование тестового инвентаря. Улучшайте тестовые артефакты
по мере их необходимости для следующего цикла тестирования.
। Когда система считается готовой к приемочному тестированию, выполняется от-
ельный тестовый цикл с акцентом на исполнении тестов и оценке их результатов.
192
Выпуск исправлений (patches) и дополнительные бета-релизы
Б'.сли обнаруживаются серьезные дефекты, препятствующие эффективном' -
и юстированию, может потребоваться выпустить исправление программы (р.т И
(специальный релиз для устранения ошибок, устанавливаемый поверх текут и
^нового релиза) и сделать его доступным для заказчиков. Часто такие рели и
।вправления делаются доступными для отдельных бета-тестировщиков, ......
исправить что-либо в специфической области, вызывающей у них беспокойк ।н<.
... чюбы блокировать дефекты, с которыми они столкнулись (хотя, как праг.н с
1лкие заплатки направляются всем бета-тестировщикам).
Как мы уже говорили (см. разделе «Фаза Внедрение и итерации». <j>o
Внедрение может включать в себя более одной итерации. В таком случае обычи
i о’.даются и передаются бета-тестировщикам новые релизы в виде Бета-1. !>с и
и гд. Чтобы обеспечить достаточный объем сведений, нужно убедиться, что ш.
I.и очное число тестировщиков выполнило обновления до новых релизов.
Показатели завершения фазы Внедрение
Момент, когда можно заканчивать фазу Внедрение, не всегда очевиден. Чин.и
определить момент завершения данной фазы, можно проанализировать (щи ш
прочего), количественные показатели (метрики), характеризующие выявленн.
и устранение дефектов и результаты тестирования. Такой анализ поможет вам о
впить па такие вопросы: когда качество будет достаточным?, Сколько дефеш"н
можно еще ожидать? и Когда все функции будут протестированы?
Давайте рассмотрим для примера небольшой набор показателей, который мю. .
оказаться для вас полезным, - показатели, характеризующие выявление и устрансин
н-фсктои и результаты тестирования.
Показатели, характеризующие выявление и устранение дефектов
Для анализа процесса выявления и устранения дефектов нужно следи и.
следующими показателями:
• сколько новых дефектов обнаруживается ежедневно:
• сколько дефектов исправляется ежедневно.
Важно концентрироваться не на конкретном числе дефектов, а на теп ни
ниц. 11а рис. 9.4 показано, что число открытых дефекюв повышалось до 10 фепрч и
а когда на их исправление стало перебрасываться все больше и 6e.ii.in.
p.i ’.работников, качество кода начало повышаться. Закрывалось дефектов бо'п.ю
Фаза Внедрение
193
чем открывалось, что привело к быстрому уменьшению количества открытых
дефектов. Проанализировав тенденции по этому рисунку, можно сделать вывод, что
к 20 марта будет достигнут уровень в 20 открытых дефектов, и еще одна неделя
потребуется для достижения уровня в 5 дефектов. Однако, как правило, при прибли-
жении к нулевому уровню дефектов скорость их исправления замедляется, это сле-
дует учитывать при оценках.
j Закрытые и прошедшие
i проверку дефекты
$ Открытые дефекты
Точки - Тенденция
Дата
ЛК. 8.4. Анализ тенденции. Анализируя изменение количества дефектов, вы можете предсказать,
когда будет достигнут определенный порог числа открытых дефектов. Если вы планируе-
те выпустить продукт, когда в нем будет менее 20 дефектов, график покажет, что это,
скорее всего, произойдет приблизительно 9 марта
Показатели тестирования
1лце один чрезвычайно ценный набор показателей - это показатели тестирова-
нии, например количество выполненных тестов. Если, например, выполнено
Только 60% запланированных тестов, можно ожидать, что к окончанию тес-
тирования вы найдете дополнительные ошибки. Можно предсказать количество
ожидаемых новых дефектов, определив, сколько дефектов обычно выявляется
йодном прецеденте тестирования, и умножив это число на количество прецеден-
1оп тестирования, которые еще нужно выполнить и проанализировать. Это можно
выразить следующей формулой:
< • Доставш = Дсредп х (ПТоб|1(-ПТвыполн), где
• Доставш - число дефектов, которые еще предстоит найти
194
Глл1'.л (i
’ Дсредн ~ среднее число дефектов, обнаруживаемых в одном прецеденте к>
пирования
' ' * । общ _ общее число прецедентов тестирования
’ * * * выполи ~ число прецедентов тестирования, выполненных на данный молен,
Вряд ли вы захотите выпускать недостаточно протестированную сисл см \
Анализируя тенденции изменения числа завершенных и успешных прецеде...
юстирования, вы сможете предсказать, когда процесс тестирования буде, ы
копчен, что даст дополнительную информацию для принятия peiueiin>
по вопросу о разумных сроках завершения фазы Внедрение.
Цель 2. Научить пользователей и обслуживающий персонал работать
самостоятельно
В ходе Внедрения обеспечьте соответствующее обучение всех пользован
ней, обслуживающего персонала и команд поддержки. Такое обучение так.ы
позволяет провести дополнительное бета-тестирование учебных материи юр
пользовательской документации и инструкций по применению.
Если вам приходится обучать большое количество пользователей, например при
развертывании новой системы в масштабах предприятия, или если вам требуется им
сококачественный учебный материал, например, как для многих коммерчески
продуктов, вам, как правило, приходиться начинать выполнение задач такого ром
юраздо раньше, в фазе Построение (а часто и в фазе Проектирование). Ну/ми
разрабатывать учебный материал и проводить подготовку инструкторов в х<и.
I loc i роения (а в фазе Проектирование уже начать его планировать). Одновременно
с выпуском бета-релиза нужно провести тестирование процесса обучения, и убеди и
ся, иго он выполняет свои задачи. Для коммерческих продуктов, а также в дрын
случаях, когда требуется подготовить большое число инструкторов, может потри»
на । вся несколько раз провести «инструктаж для инструкторов» за время бета-релп м
Цель 3. Подготовить площадку (сайт) для развертывания
и конвертировать рабочие базы данных
Если проводится замена существующей системы, обеспечить «глады»
внедрение может оказаться весьма сложно. Нужно переносить данные, при
может потребоваться, чтобы старая и новая системы некоторое время рабоа н>
Фаза Внедрение
195
нпраллельно, чтобы можно было убедиться в правильности работы новой систе-
мы. Это привести к массы дополнительной работе в части ввода информации
И обе системы и проверке соответствия результатов их работы.
В некоторых случаях может потребоваться дополнительное место или условия
для размещения новой аппаратуры, нужно позаботиться о подводке основного
Или резервного питания, может понадобится подключить сети, системы
резервного копирования и т.п. Сдаваемые под ключ системы может потребоватся
рнзвернуть на многих настольных компьютерах и серверах.
Нужно заметить, что во многих сложных случаях развертывания может начать
выполнение этих задач гораздо раньше (обычно в фазах Проектирование или
Построение).
Цель 4. Подготовить упаковку, тиражирование, маркетинговые материалы,
выпуск в дистрибуцию и продажу
Хотя этот раздел предназначен в первую очередь для независимых
ризработчиков программ, создающих готовые программные продукты, так назы-
йпемые, «коробочные продукты», некоторые из приводимых ниже задач окажутся
Полезны и для прочих видов разработки, особенно для приложений, передавае-
мых большому числу внутренних заказчиков.
Нужно заметить, что в случаях масштабных процессов развертывания ком-
мерческих продуктов, нужно будет начать выполнение этих задач гораздо раньше
(и фазах Проектирование или Построение).
Упаковка, спецификация материалов и промышленное производство
Спецификацию материалов (Bill of Materials) однозначно определяют все состав-
ляющие части продукта. Готовый продукт в упаковке будет представлять собой
программное обеспечение на каком-нибудь носителе, набор документов и руко-
водств, формы лицензионных соглашений и собственно упаковку.
Обязательно нужно, чтобы на момент передачи в промышленное производство
(тиражирование) все элементы, подготовленные для производства, были в своем
Окончательном, одобренном состоянии. Одобренную версию приложения и инстал-
ляционное программное обеспечение нужно проверить на вирусы и сохранить на
носителе, пригодном для массового тиражирования (например, на эталонном CD).
196
ГЛАНЛ 'I
Руководства и все печатные материалы должны быть в форме оригинал-макеюн
Как только все компоненты готовы и находятся на своих местах, их передают в с< >
oi ветствующую организацию, которая и осуществит тиражирование.
Маркетинговые материалы
Если вы создаете коммерческий продукт, то вам придется обратить внимашк
на следующие артефакты.
• Казовое описание (Core Message Platform, CMP): одно-двух страничное они
сание, в котором даются краткое, среднее и пространное описание ироду к и
его назначения, ключевых свойств и преимуществ. СМР — это краеуголыи.111
камень любого успешного запуска в производство. Его используют в качеспн
основы или шаблона при выяснении любых вопросов, касающихся продукт
’ Вспомогательные материалы, для заказчиков: спецификации, офицшин.
пые документы, техническая информация, материалы на вашем web-сапн
пробные демо-версии, демонстрационные скрипты и мультимедийные презсп
тации, в которых дается общее представление о продукте.
• Вспомогательные материалы для продаж: торговые презентации, технпчг
ские презентации, материалы для обучения в «полевых» условиях, рекламны-
проспекты, информация о предполагаемой области применения, рекламньн
статьи, обучение тому, как противостоять критике, ссылки, рекламные н<
тории об успешном применении продукта и т.п.
• Материалы по запуску в производство: пресс-релизы, другие материалы дчи
прессы, аналитические брифинги и внутренние информационные бюллетени
Цель 5. Достичь соглашения между заинтересованными лицами в том,
что развертывание завершено
Приемочное тестирование продукта
Приемочное тестирование продукта является последним тестированием пер, i
развертыванием программного обеспечения. Целью приемочного тестировании
является проверка того, что программа готова и способна выполнять все те фуиь
цпп и задачи, для которых она создавалась.
Существует три обычных стратегии проведения приемочного тестировании
формальная приемка, неформальная приемка, бета-тестирование.
Фаза Внедрение
197
Формальная приемка - это в высокой степени управляемый процесс,
И котором между поставщиком и покупателем существуют четкие взаимоотноше-
ния по типу один на один. Такая приемка часто является расширением процесса
Гсстирования системы. Тесты тщательно планируются и проектируются с той же
огепенью детализации, как и системные тесты. Выбираемые прецеденты тес-
тирования могут представлять собой часть тех, которые использовались при тес-
тировании системы. Важно никоим образом не отклоняться от избранных преце-
дентов тестирования. Во многих организациях формальная приемка полностью
цпоматизирована. Формальная приемка чаще всего выполняется организацией-
поставщиком под контролем заказчика, самим заказчиком или третьей стороной,
указанной заказчиком.
При неформальной приемке тестовые процедуры определены менее строго, чем
при формальной. Выявляются и документируются функции и бизнес-задачи, которые
нужно проанализировать, но конкретные прецеденты тестирования отсутствуют. Тес-
тировщик сам определяет, что ему делать. Такой подход к приемочному тестирова-
нию не так управляем, как формальная приемка, и более субъективен. Неформаль-
ную приемку часто выполняет организация-конечный пользователь.
Бета-тестирование описывалось выше в разделе «Цель 1. Провести бета-тес-
1нрование для проверки соответствия программы ожиданиям пользователей».
Вне зависимости от избранного подхода нужно достигнуть соглашения по
прецедентам тестирования и по тому, как их следует оценивать, еще до того, как
Приемочное тестирование будет реализовано и выполнено.
Приемочное тестирование продукта - это часто больше, чем проверка исполняе-
мой программы на готовность. Сюда также входят все передаваемые заказчику арте-
фнкты, такие как учебные материалы, документация и упаковка. Методы оценки
нспрограммных артефактов сильно варьируются в зависимости от вида артефакта
(Подробнее см., например, Руководства (Guidelines) и Перечни контрольных
Нопросов (Checklists) по артефактам «Прецедент использования» (Use case)
И «Описание архитектуры программы» (Software Architecture Document) в RUP.)
Цель 6. Повысить производительность при выполнении будущих
проектов на основе приобретенного опыта
В конце каждого проекта мы советуем потратить некоторое время на анализ
Н документирование того, что было сделано хорошо, а что не очень. Какие улучше-
ния вы бы порекомендовали внести в свой процесс или в среду разработки? Какие
198
Гллили
еще уроки вы извлекли? Часто такой анализ производится именно post mortem' 11.,
основе этих результатов вы можете обновить свой прецедент разработки в KIT
улучшить среду разработки, отразив в них полученный опыт.
Следует также понять, можно ли какую-либо часть работы использован
в других проектах. Если можно, обязательно уберите все конфиденциальные олп
иые и сохраните все, что можно повторно использовать так, чтобы это могли ни
йогом легко найти и использовать другие команды.
Рецензирование проекта. Веха готового продукта
Фаза Внедрение заканчивается четвертой главной вехой (контрольной точили
проекта - Вехой готового продукта, которая определяет, были ли достигнуты неш и
нужно ли начинать новый цикл разработки. (Несколько циклов разработки moi ч
быть уже запланированы в фазе Начало.) В некоторых случаях эта веха может cohh.i
дать с концом фазы Начало следующего цикла. Главными критериями оценки i н
фазы Внедрение являются ответы на следующие вопросы.
• Удовлетворены ли пользователи?
• Приемлемо ли соотношение запланированных и реальных затрат, и если нсг
то какие действия следует предпринять в будущих проектах для решения эюн
проблемы?
В момент Вехи готового продукта продукт находится в эксплуатации
и начинается процесс его обслуживания, функционирования и поддержки. ( ю о
1акже можно отнести начало нового цикла разработки для внесения noiu.i'
улучшений или создания дополнительных релизов с целью устранить ошибоки
Заключение
В ходе Внедрения, четвертой и последней из фаз жизненного цикла RHI'. их
обеспечили соответствие программы пожеланиям пользователей, а также ее м
пешное развертывание в рабочей среде. Вы достигли следующих целей.
• Вы выполнили одно или более бета-тестирований новой системы в неболь.и
группе реальных пользователей и провели необходимую тонкую настройм
3. post mortem (лат.) - посмертно. В данном случае - по завершению проекта. - Примеч. пер.
Фаза Внедрение
199
• Вы научили пользователей и обслуживающий персонал, работать самостоя-
тельно.
• Вы подготовили площадку для развертывания, конвертировали рабочие базы
данных и предприняли все прочие меры, необходимые для успешной работы
новой системы.
• Вы выпустили систему, обратив внимание на упаковку и массовое тиражиро-
вание, на маркетинговые материалы, на дистрибуцию и на подготовку продав-
цов, на обучение «полевого» персонала. Особенный акцент на этом делается
в коммерческих продуктах.
• Вы достигли соглашения всех заинтересованных лиц в том, что базис для раз-
вертывания готов и соответствует критериям оценки, определенным в Концепции.
• Вы проанализировали и использовали приобретенный опыт для улучшения
производительности будущих проектов.
ЧАСТЬ III
Внедрение Rational Unified Process
и
о. .<»
*Z -4s
ГЛАВА 10
Конфигурирование, реализация и модификация
Rational Unified Process
В этой главе мы обсудим, как можно сконфигурировать RUP для вашей орга-
низации или проекта. Конфигурирование RUP включает в себя два этапа.
I. Создание Конфигурации процесса RUP (Process Configuration), то есть выбор
используемых частей RUP.
2. Создание Представлений процесса (Process View), то есть создание в Кон-
фигурации процесса RUP персонализированных представлений или
представлений на основе ролей.
Мы увидим, что можно выбрать одну из готовых Конфигураций процесса RUP
имеете с соответствующими Представлениями процесса или с помощью RUP
Builder быстро создать свои собственные представления и конфигурации.
Также мы рассмотрим, как эффективно реализовать1 RUP для вашего проекта,
разработав прецедент разработки (development case), который представляет собой
краткое описание использования в поекте Конфигурации RUP.
И наконец, мы обсудим, каким образом модифицировать2 RUP, то есть
иключить в него свои собственные наилучшие практические методы, чтобы их
можно было легко вставлять в Конфигурации RUP. Исследуя процесс конфи-
I В оригинале используется слово «instantiate», которое также можно перевести как «создать экземпляр» -
Примеч. пер.
? В оригинале используется слово «customizing», которое также можно перевести как «подгонять» или
пе|х;делывать». - Примеч. пер.
202
Глава in
। \ рпрования, реализации и модификации RUP, мы подробно расскажем о комы
йен । ах и инструментах, входящих в технологическую основу RUP (RUP Frame
work), которые будут нами применяться.
Конфигурирование RUP
Создание Конфигурации процесса RUP
/ ш нужно указать, Технологическая основа процесса RUP (RUP Process Frame
какую часть Основы work) содержит в себе огромное количество руководств, apie
/,/// ныбудетеис- фактов и ролей. Поскольку ни в одном проекте все эти аргефак
ш чнмвать в своем
! к/е ты использоваться не должны, то вам нужно указать, какую
часть RUP вы будете использовать в своем проекте. Это делап
ея путем выбора или создания Конфигурации процесса RUP, которая представая
ei собой полный процесс с точки зрения требований конкретного проекта. Вы
можете использовать одну из готовых конфигураций или взять готовую конфи
। урацию за отправную точку или создать конфигурацию процесса с нуля.
Чтобы понять, как создается Конфигурация RUP, нужно определить такие кон
цеиции, как Компонент процесса (Process component), Библиотека RUP (RUP I i
bi ary), RUP-база (RUP Base) и Плагины RUP (Plug-In).
• Компонент процесса RUP - это связная, относительно независимая «порция
пли модуль информации о процессе, которой можно дать имя, скомпоновать, сме
пить или объединить с другими компонентами.
• Библиотека RUP - это набор Компонентов процесса, из которых можно с помо
щыо RUP Builder «скомпилировать» набор Конфигураций процесса. В RUP-бно
лпотеку можно добавлять новые компоненты в виде RUP Плагинов.
• RUP-база -это набор Компонентов процесса, который можно расширить с но
мощью Плагинов для генерирования Конфигураций процесса (располагает я
в RUP-библиотеке).
• Плагин RUP - это развертываемый модуль для одного или нескольких Компо
центов процесса, который можно легко «спустить» в RUP-базу и таким образом
расширить ее. Плагин RUP можно скомпилировать в один файл (с расширением
«.cfu»), что позволит перемещать его и добавлять в RUP-библиотеку с совмесш
мой RUP-базой.
Конфигурирование, реализация и модификация Rational Unified Process
203
Если объяснить все это с помощью простой аналогии, то Плагин RUP - это на-
бор «заранее скомпилированных» Компонентов процесса RUP, готовых
К «сборке» в RUP-базу для создания одной или более Конфигураций RUP.
Конфигурация процесса создается с помощью RUP Builder, используяRUPBuilder,
RUP Builder поставляется с некоторым числом уже определен- вы можете добавлять
Иых конфигураций, а вы по мере необходимости можете созда- содержимое в свою
1«ть дополнительные (рис. 10.1). На основе выбранных плаги-
нов вы можете делать процесс меньше или крупнее и застав-
лять его работать с технологией, предметной областью и ин-
Библиотеку RUP путем
включения в нее
плагинов.
струментами, которые необходимы для вашего проекта или набора проектов. Также
*ы можете указать, насколько формализованной вы хотите видеть работу.
Например, использовать более полные шаблоны документов или же более «лег-
кие», что больше подходит для небольших команд. Как только вы определили,
Какие плагины будут относиться к конфигурации и какие компоненты процесса
внутри этих плагинов и RUP-базы вы будете использовать, RUP Builder проверяет
совместимость этих компонентов и публикует на основе вашей конфигурации Web-
сайт Конфигурации RUP.
Плагины RUPимеются в RDN: Используя RUP Builder, вы можете добавлять содержимое
ht(p://www.rational.net в свою Библиотеку RUP, включая в нее плагины. Это со-
держимое затем можно будет использовать при построении
Конфигураций процесса RUP, которые наилучшим образом соответствуют требова-
ниям вашего проекта. Есть масса компаний, оформляющих свои ноухау в виде Плаги-
нов RUP и открывающих их для пользователей RUP с помощью RUP Exchange, раз-
дела сайта Rational Development Network (RDN), где плагины и прочие материалы,
относящиеся к процессу, доступны для сообщества пользователей. Посетив RUP Ex-
change, вы сможете загрузить интересующие вас плагины. Вы также можете созда-
вать собственные плагины, (см. раздел «Реализация RUP» ниже в этой главе.
Создание Конфигурации процесса RUP занимает всего несколько минут.
Хитрость в том, чтобы знать, что выбрать. Осмысление того, что имеется в на-
личии, может занять некоторое время. Если вы используете RUP впервые, вам
нужно сначала сконцентрироваться на обзоре уже определенных конфигураций
процессов и использовать их в качестве отправной точки.
204
Глава in
S®l
В
1 > Uesabe Cort igur мюп
j j) Eat Views
RUP
i VI Formal_Resources
Vi lnforrriai_Resourc8s
> 'up_doinel_piuQin
i-z V ruoj2ee_piug_m
[v: lOm.WS
Selectable Process Components
!X RUP
♦ g Lifecycle
* '' » Disciplines
» ' Ss flrzsrnesi Modeling
th Requirements
it- >- g-Architedure
m *•' "Ф Design
Designer
' rw_tecfln*ra/_rev>ewer_de4
- rw_wftware_a/cn)!ecL«*«
,*» rvp_cfe4ijn_/7>otfe/.<fes
л v Analysis Model
rw_enaj^&s_dewsf^.«*4c>pAne_des
'Д. 'up_rose_class<c^aes
rup_saaa_des
♦F. rvp_*oe_ec/pse_de4
jr. rup_x<fe_v4neL«*s
« i. GUI Design
* Real-Time Design
r- DataBase Design
» Design with Use Cases
• <- £ implementation
jy assessment
t-i i Production
" l-‘ C- Management
- •' « Tools
V Informal Resources
sT#i J2tE Piug-ln
V] ibM®WebSphere’“ Application Server Solutions
For more process plugins go lo (LA'.r.LuJb
status Opened Configuration Smail_Project
Рис. 10.1. RUP Builder создает Конфигурации процесса RUR RUP Builder позволяет сделать про
цесс большим или маленьким, низко- или высокоформализованным. Это делается путем
выбора включаемых в Конфигурацию RUP плагинов и компонентов, а затем - публики
ции конфигурации
Создание Представлений процесса
Ваша Конфигурация процесса RUP содержит те части технологической основы
RUP (RUP Process Framework), которые применимы к вашему проекту. Однако бо
лее чем вероятно, что не вся эта информация нужна именно вам как менеджер)
проекта, аналитику, архитектору, разработчику, тестировщику или менеджеру
по конфигурациям. По этой причине вы в зависимости от вашей роли и области oi
петственности захотите иметь свое собственное «окно», или «взгляд», на вашу Коп
фигурацию RUP, которое мы называем Представлением процесса (Process View).
Представление процесса -
это базирующийся на ро-
ли или персонализирован-
ный древовидный элемент
управления.
Представление процесса - это базирующийся на роли или
персонализированный древовидный элемент управления, со
держащий ссылки на файлы или URL, внешние по отношению
к вашей конфигурации. В больших проектах создаются, как
правило, Представления процесса, базирующиеся на ролях.
которые члены команды затем могут настроить под себя и свои конкретные нужды
В небольших проектах можно предпочесть создание персонализированных Пред-
Конфигурирование, реализация и модификация Rational Unified Process
205
(давлений для разных членов команды напрямую. Представления процесса соз-
даются с помощью RUP Builder. Каждый член группы затем может настраивать
Представление процесса под себя, применяя MyRUP, то есть Web-браузер, исполь-
ууемый для навигации по RUP. На рис. 10.2 показаны Представления процесса
и MyRUP (в данном случае персонализированное представление, созданное на осно-
ве общего Представления для аналитика).
U/riHed Р<кеи
[ ce«mD started | Tool Mentor: Personalize the RUP Website using
Analyst Oeveiopet j M R(.p
I Team Teste. j Hl/nyr
I Manaoet Production and Suooortl
I > JOHNS CUSTOMIZED VIEW i Purpose
MyRUP is lhe personalization feature of the RUP browser Process views that
provide a focused, uncluttered look into RUP have been created by your organization
and project manager will appear as tabs within the RUP browser tree control You
can create new labs containing an even more personally focused view of the RUP
process, tailored to your particular roles, needs and interests You can even add naw
elements that provide value in context
This tool mentor relates to lhe following RUP infoimahon
Overview
The following steps are performed >r> this too) mentor
Г
•gj Applet RupPresent er Applet started
Рис. 10.2. Представления процесса в браузере MyRUP. MyRUP позволяет иметь базирующиеся на
роли или персонализированные Представления процесса. Представления процесса соз-
даются с помощью RUP Builder или в MyRUP и содержат в себе ссылки на содержимое
вашей Конфигурации RUP, а также внешние ссылки, подобранные на основе вашей роли,
интересов, текущих задач и вашего вкуса
Помните, что хотя каждый член команды может использо-
вать персонализированное Представление, вся команда проек-
та все-таки использует один и тот же процесс, то есть одну и
ту же Конфигурацию процесса. Тем не менее каждый член ко-
манды может иметь свое собственное персонализированное
Представление этой общей Конфигурации. Все уже готовые
Все готовые Конфи-
гурации в RUP постав-
ляются с базирующи-
мися на ролях Пред-
ставлениями процесса.
206
Глава io
Конфигурации в RUP поставляются с базирующимися на ролях Представление
мп процесса, которые вы можете использовать в качестве отправной точки л i-i
создания своих собственных Представлений процесса.
Модификация шаблонов в RUP
Вы можете также изменять шаблоны документов, содержащиеся в RUP, ,з п
ют чтобы они соответствовали нуждам вашей организации. Как минимум вам
может понадобится включить в них логотип своей компании и, возможно, убран,
разделы, которые вы не считаете необходимыми для ваших проектов.
Реализация RUP для проекта
Используйте ровно
< -юлько формализма,
сколько необходимо
д/m обеспечения успе-
ха, но не настолько
много, чтобы это за-
медлило работу.
В каждом проекте нужно решить, как проводить реализацию
то есть как в данном проекте следует применять Конфигурации
процесса. Конфигурация процесса может содержать больна
артефактов, чем вы будете создавать в данном конкретном
проекте, и команда должна понять, какие артефакты будут сот
даваться и как информация будет фиксироваться: в документ
в программном средстве или на письменной доске в случа«
«'одноразовых»3 артефактов. Такая информация документируется в пределен к
разработки (development case). Обязательно упростите реализуемый процест
шесть сделайте его настолько низкоформализованным, насколько это возможна
в вашем случае (см. гл. 3). Распространенной ошибкой является реализация
процесса, имеющего слишком высокий уровень формализованности, что вноси i
в проект больше формализма, чем это необходимо. Используйте ровно столько
формализма, сколько необходимо для обеспечения успеха, но ненастолько мною
чтобы это замедлило работу.
3 Артефакты, которые не требуют длительной разработки и не включаются в проектную документацию
Примеч. науч. ред.
Конфигурирование, реализация и модификация Rational Unified Process
207
Прецедент разработки в RUP
Прецедент разработки со-
держит конкретные указания
1ю выполнению проекта или
набора проектов со сходными
характеристиками.
Прецедент разработки - это артефакт, в котором даются
конкретные указания по выполнению проекта или набора
проектов со сходными характеристиками относительно
того, какие артефакты должны создаваться в вашем
проекте, какие документы и шаблоны будут использо-
ваться, когда их следует создавать и с каким уровнем
формализма. В прецеденте разработки может также указываться, кто какую роль
будет выполнять в данном проекте, что может сделать прецедент разработки
ключевым артефактом для обеспечения эффективной реализации Конфигурации
КНР для вашего проекта.
Заметим, что прецедент разработки не содержит никакой информации о том, как
создавать артефакт, поскольку это было бы повторением того, что уже есть в RUP.
Вместо этого даются ссылки на используемую в вашем проекте Конфигурацию
КНР, в которой и дается информация о том, как создавать артефакт. Это позволяет
прецеденту разработки быть весьма кратким (обычно от четырех до шести
страниц) и поэтому быстро создаваемым. Мы рекомендуем, чтобы прецедент
разработки содержал как минимум, краткий перечень, описывающий одну ти-
пичную итерацию для каждой из четырех фаз (Начало, Проектирование, Построе-
ние и Внедрение), и показывал, какие артефакты будут создаваться, с каким уров-
нем формальности и как следует проводить их рецензирование. На рис. 10.3 пока-
зан пример такого перечня, в котором указаны создаваемые артефакты и уровень
формализованности при их рецензировании. Чтобы получить руководство, описы-
вающее определенный артефакт и как его разрабатывать, вы переходите по ссылке,
когорая приводит вас к вашей Конфигурации RUP.
Прецедент разработ- Прецедент разработки подробно определяет, какой набор арте-
ли определяет, какой фактов из вашей Конфигурации следует создавать. Например,
набор артефактов из в Конфигурации RUP могут содержаться руководства по двум
кашей Конфигурации артефактам, - Запросу заинтересованного лица (Stakeholder Re-
шюдуетсоздавать. qUest) и Концепции (Vision), но вы можете захотеть использо-
вать в своем проекте только документ Концепция. В прецеденте разработки сле-
дует указать, что вы создаете документ Концепция в фазе Начало, пишете,
насколько формализованным он должен быть и кто его будет рецензировать.
Поскольку вы не планируете создавать документ Запрос заинтересованного лица,
208
ГЛЛЕ^Л HI
Рис. 10.3. Прецедент разработки - артефакты и формальности. Прецедент разработки - это ари
факт, определяющий, какие артефакты создавать, в какое время и с каким уровнем форм.1
лизованпоети. Может быть также указана дополнительная информация, например кы н.
шаблоны использовать и как проводить рецензирование артефакта
и прецеденте разработки он указан не будет (в качестве альтернативы можно ука
тать в прецеденте разработки, что Запрос заинтересованного лица создаваться ы
будет).
На рис. 10.4 представлена еще одна часть прецедента разработки. В ней пока
тано, кто какую роль выполняет в проекте. И опять, если вы щелкните мышкой но
роли, то перейдете на Web-сайт вашей Конфигурации с описанием различных
ролей.
В первом своем проекте вам следует подумать о создании очень простою
прецедента разработки. Наибольшую ценность, как правило, представляю!
первые четыре-восемь часов затраченного времени. RUP предоставляет шабло
пы, которые позволяют быстро создать прецедент разработки для вашего проеь
ia. Также очень полезно достаточно часто обновлять прецедент разработки
лучше в конце каждой итерации или хотя бы в конце каждой фазы. Такой под.хо i
позволит вам улучшать используемый процесс па основе приобретаемого опыта
В конце каждого проекта нужно подумать об обновлении шаблона прецедент
разработки и включить в него информацию, полученную в ходе работы на i
проектом, с целью применить ее в будущем в проектах, использующих похожие
прецеденты разработки. Мы слишком часто видим специалистов по процессу, ко
Конфигурирование, реализация и модификация Rational Unified Process
209
he. 10.4. Прецедент разработки - роли, В прецеденте разработки может содержаться информация
по персоналу, в частности кто какую роль RUP выполняет в проекте
к>рые тратят неделю за неделей на прецедент разработки перед началом первого
проекта. Написание хорошего прецедента разработки похоже на написание
программы: с первого раза все правильно не получится, так что сначала потрать-
ic не слишком много сил, опробуйте, усовершенствуйте, опробуйте еще раз и т. д.
Естественно, бывают случаи, когда стоит потратить несколько недель на соз-
днпие хорошего прецедента разработки. В больших проектах, когда путаница
И решениях об использовании процесса может обойтись очень дорого, или в сис-
1смах, где для выполнения правил требуется высокий уровень дисциплины,
й также везде, где качество является критичным, - во всех этих случаях дополни-
1слыюе время может принести впоследствии высокие дивиденды.
Web-сайт проекта
Web-сайт проек-
та должен со-
держать преце-
дент разработки.
Все члены проекта должны иметь свободный доступ к прецеденту
разработки. Одним из способов достигнуть этого является наличие
Web-сайта, обеспечивающего доступ ко всей информации по проекту,
включая сведения о персонале, протоколы совещаний, ссылки на цен-
ную информацию, ссылки на созданные артефакты, информацию о том, когда будут
пиовы определенные типы выпусков, и т.п. Также мы рекомендуем, чтобы Web-сайт
Проекта содержал прецедент разработки и к нему был свободный доступ для всех
•iiiciiOB команды проекта. Ссылку на Web-сайт проекта следует поместить в Пред-
210
Глава 10
i 1.1нлсние процесса (Process View) каждого участника. При разработке Web-сай i а
проекта вы можете использовать в качестве основы Web-шаблон (Project Web Тен,
plate), входящий в состав RUP.
В качестве альтернативы можно подумать об использовании Rational Project
( onsole, компонента Rational Suite, который автоматически извлекает информа
пню из инструментальных средств фирмы Rational и других производителен
и строит за вас Web-сайт проекта, содержащий информацию обо всех текущих
цисфактах. Также Rational ProjectConsole может предоставлять обширный набор
показателей, позволяющий анализировать ход проекта. Он поставляется с тип<>
ним набором показателей и отчетов для каждой из четырех фаз RUP.
В Web-сайте проекта даются соответствующие ссылки на Конфигурацию RIH1
)io позволяет изменять базовую Конфигурацию с минимальным влиянием
иа прецедент разработки (рис. 10.5). Вы можете обнаружить, что некоторые in
пересылки больше не работают или что вам нужно добавить или удалить не
сколько артефактов в прецеденте разработки, чтобы отразить изменение Конфи
। урации, но как правило, реализация этих изменений займет всего несколько мп
ну । (предполагая, что ваш прецедент разработки не слишком обширен).
Рис. 10.5. Web-сайт проекта в Rational ProjectConsole. Rational ProjectConsole может автоматически
сгенерировать Web-сайт текущего проекта, предоставляя доступ ко всей информации по про
екту, включая прецедент разработки, протоколы совещаний и ссылки па созданные артефакт ы
Конфигурирование, реализация и модификация Rational Unified Process 211
Альтернативы созданию Прецедента разработки
Создание прецедента разработки дает членам вашей команды четкое пред-
ставление о том, какие точно артефакты следует создавать, кто их будет создавать
и как они будут рецензироваться. Однако такую информацию можно распростра-
нять и другими способами. Менеджер проекта или наставник могут рассказать
участникам о том, что делать и как рецензировать артефакты. Или же участники
могут обратиться к плану проекта и выяснить, что же им предстоит создать.
После этого они могут перейти к Конфигурации RUP и выяснить, каким образом
можно сделать эту работу. Такие подходы оправдывают себя в небольших проек-
тах при наличии опытного наставника.
Модификация RUP
У некоторых организаций может возникнуть необходимость
создавать Конфигурации RUP отличные от тех, которые можно
сделать с помощью имеющихся Плагинов RUP, от компании IBM
Software и ее партнеров. Такие организации могут модифи-
цировать RUP с учетом соответствующих нужд, характеристик,
Модификацию RUP
предпочтительно
осуществлять пу-
тем создания Пла-
гинов RUP.
ограничений, исторических традиций организации, ее культуры и области рабо-
ты. Возможно, такой организации требуется разрабатывать программное обес-
печение в соответствии с определенным стандартом качества или при наличии
определенного цикла управления. В таком случае можно модифицировать RUP
п включить в него примеры или повторно используемые приемы и подходы из
предыдущих проектов. Модификацию RUP следует осуществлять путем созда-
ния Плагинов RUR Это позволяет создавать разные наборы Конфигураций
процесса RUP. Плагины - мощное средство, их можно разделить на две основные
категории: Тонкие Плагины RUP и Структурные Плагины RUP.
• Тонкие Плагины - изменение файлов с описаниями, относящихся к сущест-
вующим элементам процесса. Плагины этого типа позволяют пользователям
добавлять, изменять и удалять файлы, связанные с существующими элементами
процесса. Это позволяет, например, изменить на основе приобретенного опыта
руководство по созданию документа Концепция, модифицировать шаблоны для
определенного артефакта, добавить примеры из вашей конкретной области рабо-
ты или добавить повторно используемые приемы, разработанные при выполне-
212
Глава К)
пии предыдущих проектов. Изменения такого типа вносятся при помощи компо
пента Rational Process Workbench (RPW) под названием «RUP Organizer».
• Структурные Плагины - изменение элементов процесса и их взаимоотно
шений. Плагины такого типа позволяют хорошо знакомым с процессом
пользователям, которые разработали какие-то компоненты вне RUP, интегриро
вать их в RUP. Вы можете добавлять, изменять и удалять элементы процесс.!
такие как артефакты, задачи, роли, дисциплины, рабочие процессы и инструк
ции по использованию инструментов. Такая гибкость позволяет вноси и
крупные изменения в RUP-библиотеку, например, добавив в RUP свои собствен
пые руководства о том, как проводить реализацию пакетов или интеграцию
наследственной системы4. Такие типы изменений производятся с помощью
RPW. Изменения в элементы процесса и их взаимоотношения вносятся при по
мощи компонента RPW под названием «RUP Modeler». Изменения в файлы
связанные с каждым элементом модели, вносятся при помощи RUP Organizer.
Не следует производить модификацию RUP, непосредственно изменяя RU1’
базу или существующие плагины. Если вы измените их напрямую, вам придет ю/
проделывать всю эту работу заново при выходе очередных версий RUP. Если мо
дпфикация производится при помощи плагинов, вам будет гораздо легче перепо
сигь изменения в будущие версии RUP. Такая стратегия снижает стоимость сю
служивания, поскольку вы не меняете напрямую файлы, создаваемые компанией
IBM Software и ее партнерами. Вместо этого вы указываете, какие изменения еле
дует вносить в них.
Rational Process Workbench и Process Engineering Process
ПлагиныRUPсоз- Плагины RUP создаются с помощью Rational Process Workbench
даются с помощью инструмента создания собственных процессов, KOTopi.ni
Rational Process включает в себя следующие компоненты:
Workbench. . rup Modeler. Это средство позволяет инженеру-техноло! \
визуально моделировать элементы процесса, такие как задачи
артефакты, роли, дисциплины и инструкции по использованию инструмент,!
и их взаимоотношения, и компилировать в Компоненты процесса RUP. Rl В'
Modeler представляет собой расширение Rational XDE и работает совмес пю
с RUP Organizer.
4. Legacy system - система, оставшаяся «в наследство» от прежних времен. - Примеч. науч. ред.
Конфигурирование, реализация и модификация Rational Unified Process
213
• RUP Organizer. Этот инструмент позволяет привязывать содержимое файлов
к элементам процесса, таким как задачи, артефакты, роли, дисциплины и ин-
струкции по использованию инструментов, которые вместе составляют Компо-
нент процесса, и компилировать эти Компоненты процесса в Плагины RUP с но-
выми или измененными файлами. Эти файлы (среди прочего) могут представлять
собой примеры, руководства или повторно используемые приемы. RUP Organizer
также позволяет изменять Расширенную справку (Extended Help).
• RUP Process Library. Содержит модели процесса со всеми элементами, таки-
ми как задачи, артефакты, роли, дисциплины и инструкции по использованию
инструментов, определенными в RUP, а также с файлами для каждого элемен-
та модели.
• Process Engineering Process. Предоставляет руководство по модификации,
реализации и усовершенствованию процесса, а также шаблоны для разработ-
ки своих собственных файлов, например HTML-шаблоны для описаний и ру-
ководств, шаблон для создания плагинов и всю необходимую для создания
процесса графику.
Большинству организаций следует рассмотреть возможность
использования RUP Organizer для постоянного пополнения опи-
сания процесса с помощью Тонких Плагинов RUP, сохраняя, та-
ким образом, опыт и достижения, накопленные в предыдущих
проектах. Но разрабатывать Структурные Плагины с помощью
RUP Organizer по-
зволяет связывать
содержимое фай-
лов с элементами
процесса.
RUP Modeler и RUP Organizer должны только организации со зрелой технологи-
ей, поскольку такие действия требуют весьма солидной квалификации.
Создание Тонких Плагинов RUP с помощью RUP Organizer
RUP Organizci - простой в использовании инструмент. Вы
создаете страницы с информацией в редакторе HTML, создаете
шаблоны и собираете примеры и повторно используемые прие-
мы. RUP Organizer позволяет связать эти файлы с соответст-
Тонкие Плагины
не меняют струк-
туры элементов
процесса.
кующими элементами процесса в Компоненты процесса путем простого перетас-
кивания их мышкой на элемент процесса (рис. 10.6). Затем вы можете создать
Тонкий плагин, содержащий все сделанные вами изменения в одном или несколь-
ких компонентах процесса. Таким образом, вы можете создать плагин, состоящий
лишь из пары файлов или из большого их количества. Как правило, большая
чисть времени тратится на Плагин, требующий редактирования самого содержи-
мого файлов. Заметим, что Тонкие Плагины не меняют структуры элементов
214
Глава in
процесса, то есть не изменяют имеющихся артефактов, задач, ролей, рабочих
процессов, инструментов или инструкций по их использованию, а также не мг
пню г и их взаимоотношений друг с другом, например какие артефакты для какою
। ппа задач являются входными и выходными.
Layout Expbrer
1 .. X .vser i cwfO'ijj, cur jUrrl h»j .jR'JP i S Litsc/cle
SUU 7 .Jinaqes 1 УР- Fc der 1 '-1 ad 'i 9/5.-2I .d C-2 09:58 AM AU. • Oki-p гм ю P'ooess Сэгг>:эегт<
л*. gudehe .1/2/2С-Э: 16:17 PM R • RiH.r#»*:* Mr dp Inc
WTiv.-'.Ht qi. rl Л1- ’1/3/?( C3 1 :4i'i Pfz F. £• Rscarenerts
,ljv,q ini'- I-П qi, dsHv ’1,7/Д'Т 1t:17 PM R ♦ R^qi.rvТг-лГч '.// Ik»»
slloy Jevwj. il и yr. d .-k ic lU/hM.J. AI< к । Requ reTents Maragerrent
йЯ1-,у ГЫ .lit n yi d .'kic 11/77СЛ 16:1/ 1 ’-! к * 2 Re.qi.rpTPn^ %ргпрг (or’ini
iv,g_nt"v.htT gedehe -1X2/20 : 16:17 PM p, i _• Systen Ancvst [contrioutsc 1.
i5v,g_Tinttst5te.Ttn qc dehe _i;2,'2CPE 16:17 PM R ♦ .5 rjp tP.-bnlT- I PX, r?n i'j .«
qi.d?h₽ • 1;?/. 1C:17 PM R i д Cta-ieioide'
,tlv,q_i=v.'i'.hrT qi. ilr-h* '1,7/. •t. :b H :1.- PM К ♦ " Vi^inr
s*|v,y t- ,-ilr i yi d .i ic 11,7/. •<:p lt:l.' l"-1 к i. 5: Clcssav
-qtvsh.it-n qi dihe О )CB 12:50 atf R ♦ j" S'A-fPinHe1 •
;5tag_'vise.- tin gedehe CD fip2 It: 17 PM R । b 5o~ ;are Kequire-neit
1г: CJv,g_5tx.htr Jv,q_ jrvTtri j5wi|_ л л J .111 II gid she CD iLn 16:17 PM R ♦ Дт fip.'jHirv win Зррг ।
qi. rIMv l|l. ll.’lrl<• id Drop " К? 16:1PM ИИ ••'д/ .*1 R H rjp_rcqurc'n<nt5_dBcpre_ * ’’ Ф-Г’М’1 (СЛГП hl 'ff*- rjp_sjfc£_3ncV5t_s:Ldk:_req * £/ .SnrhrF.i лт=
Рис. 10.6. UP Organizer позволяет создавать Тонкие Плагины. RUP Organizer позволяет связан. пи
формационные файлы, такие как примеры, руководства, шаблоны или повторно ясно и.
зуемые приемы, с элементами процесса и создать Тонкие Плагины, содержащие эти и пи
нения. Это позволяет быстро включать приобретенный опыт в будущие Конфигурации
процесса
Создание Структурных Плагинов RUP с помощью RUP Modeler и RUP Organizer
RUP Modeler - это инструмент продвинутого инженера-технолога. Это среде i
во позволяет создавать или развивать объектно ориентированную модель прощч
са с использованием UML. В частности, можно вводить новые элементы процш
са - роли, задачи, артефакты, а также связи между этими элементами:
• какие артефакты для каких задач являются входными и выходными;
• какие роли за какие артефакты отвечают (рис. 10.7);
Конфигурирование, реализация и модификация Rational Unified Process
215
• какие руководства, шаблоны и примеры сопровождают артефакты и задачи.
RUP Modeler позволяет определить, как эти элементы про-
цесса должны дополнять или переписывать элементы процесса,
содержащиеся в RUP-базе и других плагинах. Он позволяет ви-
зуализировать многие тысячи связей, которые могут существо-
Ингь между всеми этими элементами, которые будут храниться
RUP Modeler - это
средство оперирова-
ния базовой объектно
ориентированной мо-
делью RUP на UML.
И библиотеке RUP. Позже вся эта модельная информация будет использоваться
RUP Builder для автоматической генерации тысяч гиперссылок при публикации
Конфигурации RUP.
Хотя инженеры-технологи, применяющие RUP Modeler,
ценят его мощность, использование этого инструмента требу-
ет определенного уровня навыков. Для создания Структурных
Плагинов нужно быть знакомым с объектно ориентирован-
ным моделированием, Rational XDE и самим RUP. Создание
Плагина требует довольно много времени, и нужно подходить
К этой работе разумно. Мы рекомендуем поработать с RUP в нескольких проек-
I'lix, перед тем как браться за создание Структурного Плагина. Убедитесь, что вы
Понимаете, какие изменения необходимы, а какие можно отложить или вообще
отбросить.
Мы рекомендуем пора-
ботать с RUP
в нескольких проектах,
перед тем как браться
за создание Струк-
турного Плагина.
йк. 10.7. RUP Modeler. RUP Modeler - это инструмент моделирования, который использует всю
мощь визуального моделирования и UML для моделирования процесса. Он позволяет гра-
мотному инженеру-технологу вносить в RUP крупные изменения
216
Глава m
Создание плагина с помощью RUP Modeler и RUP Organizer может заиян
hi нескольких педель до нескольких месяцев в зависимости отимеющекн ।
персонала и сложности плагина. Ниже перечислены основные требования к ш;
данию Структурных Плагинов RUP.
Поймите RUP. Убедитесь, что вы действительно понимаете, что уже имеен
n RUP и как это используется на практике. Если у вас нет практического опыта рэ
бот ы с RUP, вам следует подумать о том, чтобы поработать с кем-нибудь, в идет и
с наставником, у которого этот опыт есть. То, что есть в RUP, может не совсем < >
о 1 ветствовать вашим желаниям, но эта информация может оказаться приемлемо!!
в сравнении с усилиями и гратами на ее изменение или расширение.
• Поймите те изменения, которые вносятся в RUP. Перед тем как вы пачнсн
проводить модификацию, добейтесь ясного понимания процесса, который буи ।
использоваться в вашей организации или проекте. Четко привяжите свой жен.и
мый процесс к тому, что уже содержится в RUP. Используйте шаблон Прецедст >
разработки, который поможет вам осуществить такую привязку. Что точно вы in ।
хотели добавить, убрать или изменить? Эти изменения можно сделать или немо i
ленно, или подождать до тех пор, пока вы сначала не поработаете с RUP в н<
скольких проектах. Многие новички в RUP имеют склонность вносить много и ,
менений просто потому, что они привыкли использовать другую терминолт пы
пли немного отличающийся набор артефактов и задач. Однако затраты на висы
пне таких изменений могут быть довольно велики, а ценность изменений - опт
стельно низка. Вместо этого попробуйте сделать простую привязку ciapou
1ерминологии, артефактов и задач к новой терминологии, артефактам и зада'1,1-.!
п разместить это в своем прецеденте разработки.
• Наметьте, какие элементы процесса будете добавлять, изменять или ды
.пять. Создав краткую спецификацию добавляемых, изменяемых и удаляемы
элементов процесса (дисциплин, ролей, артефактов, деталей рабочих процесс ш
инструментов и инструкций по их применению), вы лучше поймете границы p.i
бог по модификации. При наличии такой упорядоченной схемы элементов ш,
сможете расставить изменения в порядке приоритета и выполнить работу в ш
сколько итераций, как это пропагандируется в RUP. Также вам нужно реши и.
будете ли вы создавать один или несколько Плагинов процесса. Если их буи ।
больше, чем один, вам, скорее всего, придется создавать их по одному, чтобы и,
браться в большом проекте за все сразу.
• Создайте Плагин RUP без содержимого. Используя RUP ModcL ।
п имеющиеся шаблоны, создайте новые элементы процесса и опишите, г.и
они должны замещать элементы в RUP-базе или других плагинах. Избенши
Конфигурирование, реализация и модификация Rational Unified Process
217
внесения прямых изменений в RUP-базу или Плагины RUP, поставляемые
компанией IBM Software и ее партнерами. В противном случае вам придется
делать всю модификацию заново, когда появится новый выпуск RUP-базы или
Плагинов RUP.
• Разработайте содержательную часть процесса. Разработайте (запишите) со-
держимое процесса. Пока это, задача, требующая наибольшего времени. Есть
огромная разница между знать, как сделать что-то, и создать подробное и чет-
кое пошаговое описание этого. Если у вас уже есть что-то конкретное, записан-
ное в какой-либо форме, например в виде документов и технических описаний,
вы сэкономите массу времени. Вы можете вводить информацию прямо
в текстовом формате или непосредственно в редакторе HTML. Другие информа-
ционные файлы могут представлять собой примеры из предыдущих проектов
или накопленные повторно используемые приемы и подходы.
• Внесите в плагин созданную информацию. Следующий шаг - эго связат ь ин-
формационные страницы с нужным элементом процесса. Используйте для этого
возможности RUP Organizer по перетаскиванию мышкой. Затем нужно тщатель-
но протестировать плагин. RUP Modeler проверит семантическую правильность
плагина. Используя RUP Builder, вы можете опробовать свой плагин, создав не-
которое число разных Web-сайов Конфигураций RUP и протестировав их, чтобы
гарантировать, что содержимое выглядит так, как и ожидает ся.
Создав Плагины RUP, вы можете импортировать их в RUP Builder и создавать
Конфигурации RUP со своим собственным содержимым.
Заключение
Организация или менеджер проекта должны принять реше-
ние о том, какие конфигурации и какой первоначальный набор
Представлений процесса использовать. RUP поставляется с не-
сколькими готовыми конфигурациями и Представлениями,
й дополнительные конфигурации и Представления можно бы-
стро создавать при помощи RUP Builder и Плагинов RUP.
Имеющийся набор доступных Плагинов RUP можно найти
через RUP Exchange в Rational Developer Network.
Организация или менед-
жер проекта должны
принять решение о том,
какие конфигурации и
какой первоначальный
набор Представлений
процесса использовать.
218 Глава in
Многие проекты весьма выиграют, если инженер-технолог потратит по меш.
шей мере несколько часов на создание прецедента разработки, что даст кратюг
инструкцию по применению или реализации Конфигурации RUP в проекте.
Во многих проектах стоит подумать о создании Тонких Плагинов с помоип.п
Kill* Organizer. Тонкие Плагины позволяют добавлять, изменять и удалять диспн
плины, примеры, шаблоны и повторно используемые приемы.
Пользователи с опытом работы и со специфическими нуждами, приложи!'
усилия могут создать Структурные Плагины с помощью RUP Modeler и RUI'
Organizer. Структурные Плагины позволяют вносить в RUP крупные измене
ния. 11лагины импортируются в RUP Builder и используются для создания Кон
фигураций RUP.
% t
ГЛАВА 11
Внедрение Rational Unified Process
В этой главе мы обсудим мотивы внедрения RUP, способы внедрения RUP
и проект, а также различные подходы и стратегии внедрения RUP в серию проек-
тов, выполняемых в организации.
Мотивом внедрения RUP и инструментальных средств явля-
ется получение экономической выгоды, выраженной в повыше-
нии результативности проектов. Чтобы вложения окупались,
усовершенствования процесса, достигаемые благодаря эффек-
тивному применению RUP и связанных с ним технологий,
должны в конечном итоге приводить к созданию систем более
Если цели не будут
четко усвоены каж-
дым, то время, по-
траченное на улучше-
ние процесса, легко
превратится в беспо-
лезные траты.
высокого качества, снижению затрат и более быстрому выходу на рынок. Если
эти цели не будут четко усвоены каждым, то время, потраченное на улучшение
процесса, легко превратится в бесполезные траты. Обычная ошибка - использо-
вание слишком «тяжеловесной» версии RUP, когда создается больше артефактов.
чем это нужно команде проекта. Это не даст вам получить те результаты, которые
вы ожидаете. Везде, где это возможно, нужно минимизировать число создавае-
мых артефактов, если это не снизит качество.
Внедрение RUP означает, что вам нужно поменять технологию своей работы,
в такие перемены весьма затруднены. У вас должно быть четкое понимание моти-
вации изменений, какие изменения имеют смысл, какие менее приоритетны, ка-
ким образом вносить изменения и как измерить успех в единицах повышения
результативности.
220
Глава 11
Чтобы добиться улучшения результатов, часто нужно применять не только усе
исршенствованный процесс, но также и сопутствующие инструменты. Организа
цпя, которая не понимает связи между процессом и инструментами, скорее всего ш-
сможет извлечь осязаемой выгоды из усовершенствования процесса. Улучшении
н процессе будет ровно столько, сколько вы сможете получить без усовершенстно
наций в использовании инструментов (см. ниже раздел «Добивайтесь эффективно, ।
окупаемости вложений с помощью использования инструментов»). Если ваш
проект является пилотным, выполняемым в рамках внедрения процесса и ни
с । рументальных средств, в нужно внимательно изучить приводимый ниже раздсп
«11илотные проекты», где даются более подробные инструкции.
Применение RUP в проекте
Гораздо легче применять RUP с самого начала проекта, чтобы избежать in
лишней сложности при переходе в середине проекта с имеющегося процесса
па RUP. Используя пять шагов, вы можите ввести RUP с самого начала работы
над проектом.
I. Предварительная оценка. Оцените, с какими проблемами ваша команда сталки
валась в прошлом, какое влияние эти проблемы имели на бизнес и какие из них
имеют наибольший приоритет с точки зрения бизнеса. Четко выделите ожидас
мые экономические выгоды, в идеале - в виде экономического обоснования.
2. Планирование. Спланируйте задачи по вводу RUP в эксплуатацию, такие как
модификация процесса, тренинг (то есть структурированные занятия1)
и наставничество (то есть наличие среди членов проекта эксперта, который буде,
работать бок о бок с командой и осуществлять обучение по ходу работы)
Запланируйте приобретение необходимых инструментов. Обеспечьте треншп
по принципу «Точно к нужному сроку» (Just-In-Time, JIT), чтобы обучаемые
имели мотивацию, поскольку обучение идет быстрее, если вы знаете, что знании
вскоре будут применены на практике.
I. Конфигурирование и модификация. Осуществите необходимое конфигуриро
вание и модификацию процесса, инструментальной среды и учебного материала
I Structured lessons - занятия, проводимые по строгому плану. Обычно это обзор занятия, изложение первой теми
упражнения по первой теме, изложение второй темы..., упражнения по последней теме, подведение итогов
Примеч. науч. ред
Внедрение Rational Unified Process
221
Ограничьтесь только той модификацией, которая оправдана с экономической
точки зрения, то есть находится в соответствии с экономическим обоснованием.
4. Выполнение. Внедрите процесс и инструменты в свой проект, проведите обуче-
ние участников проекта, обеспечьте наставничество и запустите проект. Скон-
центрируйте внимание команды на результатах и используйте наставников,
чтобы использование процесса и инструментов находилось в соответствии с эко-
номическими целями.
5. Оценка результатов. Оцените производительность, достигнутую в проекте,
и сравните ее с ожидаемой, записанной в экономическом обосновании.
Выявите возможности для будущих улучшений.
Теперь рассмотрим каждый шаг более подробно.
Предварительная оценка
Важно иметь четкое понимание целей изменения. Зачем вы хо-
тите ввести у себя RUP? Чтобы понять цели, составьте в порядке
приоритета список проблем, с которыми вы сталкиваетесь, и
определите их влияние на бизнес, например так: «расползание
требований вызывает нарушение сроков», «ненадежный процесс
В идеале внедрение
RUP должно основы-
ваться на ясном
и кратком экономиче-
ском обосновании.
сборки опять вносит дефекты, которые уже были устранены», «хрупкость архитек-
туры повышает стоимость обслуживания», «несистематизированные и ручные мето-
ды тестирования приводят к снижению качества» и т.д. Чем лучше вы сможете
количественно оценить результативность возможных улучшений процесса в едини-
цах повышения качества, уменьшения сроков выхода на рынок и снижения затрат,
а также того эффекта, который эти улучшения окажут на итоговый результат, тем
точнее вы сможете сконцентрироваться на наиболее приоритетных областях усо-
нершенствования процесса. Это поможет простимулировать мотивацию людей к из-
менениям (поскольку они поймут выгоду для себя и организации), получить средства
для необходимых вложений (поскольку менеджеры увидят практические улучшения
н результате инвестиций) и получить согласие от заинтересованных лиц (поскольку
они увидят, что это пойдет на пользу организации). Также это поможет определить
и расставить в порядке приоритетов вносимые улучшения процесса, иными словами,
какие части RUP применять и в каком порядке. В идеале внедрение RUP должно ос-
новываться на ясном и кратком экономическом обосновании.
Рассмотрим два примера.
222
Глава 11
Проект «Меркурий»
Начинается работа над проектом «Меркурий». В предыдущих проек-i.i
у команды были крупные проблемы с расползанием требований и apxHiei.
iyрой. Комбинация этих двух проблем считается главной причиной трехмс
сячной задержки. Проект «Меркурий» - это важный проект, и время являенч
критичным фактором. Аналогичная задержка в этом проекте обойдется komii.i
нпи в 200 000 долл., а если производительность останется на прежнем урони,
io подразделению это обойдется по приблизительным оценкам в 300 000 до 11
в год. Проведя анализ RUP, менеджер проекта решает, что проект весьма ни
играет от применения таких дисциплин, как «Требование» (Requirement i
«Анализ и проектирование» (Analysis & Design) и «Управление проектом
(Project Management). Для поддержки процесса команда решает купить срс;н ।
ва управления требованиями и средства визуального моделирования. Решен.,
чго будет слишком рискованно вводить сразу много изменений, так что ника
ких изменений в таких областях, как тестирование и управление изменениями
не будет.
Проект «Гэнезис»
Начинается работа над проектом «Генезис», набрана команда из участников
имеющих разный опыт работы. Разные участники проекта имеют опыт рабоп.1
с различными процессами (или без процессов) и инструментами. Менеджер и.,
разработке хочет добиться того, чтобы у всех членов команды было общее пре i
сгавление о разработке программного обеспечения и чтобы все они использова ш
современные практические методы и инструменты. Менеджер рассчитывает, чю
пи улучшения приведут к 5%-ному повышению производительности и 15%-и..
му снижению числа дефектов в выпускаемых продуктах (на основе опьпл
приобретенного при улучшении процесса в прошлых проектах), что в июк
приведет к экономии 170 000 долл, в год. Решено принять стандарт в виде R11Г
п единого набора инструментов и что все члены команды будут использован
К UP на всем протяжении проекта.
В обоих приведенных примерах цели введения RUP сделаны явными
с количественно оцениваемыми выгодами, и на основе этих целей принимаю,. .,
решения о том, какие части RUP использовать.
Внедрение Rational Unified Process
223
Планирование
Второй шаг - спланировать внедрение процесса и инструментальной среды.
Нужно спланировать, когда и как производить конфигурирование и модификацию
процесса, инструментальной среды и обучения. Нужно спланировать обучение
«к сроку» и наставничество. Нужно спланировать физическое развертывание ин-
струментов и возможный перенос имеющихся данных в новые инструменты. Осу-
ществление обучения «к сроку» - это только один пример того, как следует направ-
лять все действия по усовершенствованию на то, чтобы получить максимум выго-
ды. А зачем сегодня обучать людей тому, что они не будут использовать в течение
трех месяцев? У обучаемых не будет мотивации, они могут забыть выученное,
в некоторые уйдут из команды до того, как смогут применять знания. Рассмотрим
паши два примера проектов.
Проект «Меркурий»
В бюджете проекта «Меркурий» предусмотрено приобретение Rational Unified
Process, а также инструментов для управления требованиями и визуального моде-
лирования. Используя RUP Builder, команда проекта создает подходящую Конфи-
гурацию RUP (подробнее см. гл. 10). Наставнику поручено написать прецедент
разработки и провести внедрение инструментов (рис. 11.1). Поскольку у команды
нет опыта в итеративной разработке, а управление конфигурациями и автомати-
зация тестирования все еще не очень хороши, решено, что команда справится
«лучшем случае с четырьмя итерациями проекта. Средства, выделенные на
обучение, весьма ограничены, так что на курсы по основам RUP, по принципам
управления итеративной разработкой и по Объектно ориентированному анализу
и проектированию посылается только по одному человеку. В ходе проекта все
получат доступ к Web-курсам по RUP. Решено выделить средства на наставника
с частичной занятостью, который поможет эффективно использовать инструмен-
ты и процесс в таких дисциплинах, как «Требование», «Анализ и проектирова-
ние», «Управление проектом».
Проект «Генезис»
В проекте «Генезис» выделяются средства на приобретение Rational Unified Pro-
cess и инструментов. Используя RUP Builder, команда проекта создает подходящую
Конфигурацию RUP (подробнее см. гл. 10). Наставнику поручено написать преце-
дент разработки и провести развертывание инструментов (рис. 11.2). Команда сво-
бодно чувствует себя при использовании итеративного подхода, поскольку несколь-
224
Глава li
к<> участников имеют соответствующий опыт работы, и в проекте будет задействован
опытный наставник. В проекте «Генезис» были выделены значительные средства и.,
обучение, и участники прошли обучение как на месте, так и на курсах. Впоследс i
вии все они получат доступ к Web-обучению R.UP. Решено выделить средства на
полную ставку наставника, который поможет эффективно использовать инструмен
н.| и процесс.
п • Прецедент разработки охватывает требования
h - Внедрение инструментов управления требованиями и визуального моделирования
К • Руководство по моделированию прецедентов использования - первый набросок
р - Шаблоны артефактов, относящихся к требованиям
У П - Руководства по моделированию прецедента использования - базовая версия
г р У - Руководства по пользовательскому интерфейсу - первый набросок
У Ц ‘ - Прецедент разработки расширен на анализ и проектирование
h П - Руководства по проектированию - первый набросок
П И i- И • Руководства по пользовательскому интерфейсу - базовая версия
У у • Руководства по проектированию - базовая версия
Н И й г - Шаблоны для проектирования
ИтеращляН-1 П Итерация Пр-1 и ИтераояПр-2 у Итерация Пост-1 Итерация Пост-2 ц ИтерацияВ-1
Начало / \ Проектирование / \ Построение / \ Внедрение
Рис. 11.1. Внедрение дисциплин «Требование», «Анализ и проектирование» и «Управление upon,
том». Совершенствование прецедента разработки, связанных спим руководств, а такт,
сопутствующих инструментов для дисциплин Требование, Анализ и Проектирован!!,
и Управление проектом
Как можно видеть, планирование внедрения весьма различается в разных прост
nix. Опытность команды, финансирование проекта, готовность команды к измене
пням - ключевые факторы, учитываемые при планировании. Мы, однако, отметим
то и в том, и в другом проекте задействован наставник, то есть эксперт, что будо
способствовать ускорению передачи знания. Наш опыт показывает, что использонл
пне наставников (внешних либо внутренних) является ключевым фактором для уч
псха по улучшению проекта.
Внедрение Rational Unified Process
225
li • Прецедент разработки охватывает требования
н - Внедрение инструментов управления требованиями и визуального моделирования
п • Руководство по моделированию прецедентов использования - первый набросок
и • Шаблоны артефактов, относящихся к требованиям
<’ - Руководство по моделированию прецедентов использования - базовая версия
‘ и- Прецедент разработки - добавлены управление конфигурациями и изменениями и анализ и проектирование
р и - Руководства по пользовательскому интерфейсу - первый набросок
к- Внедрение инструментов управления конфигурациями и изменениями
1 ь и-Руководства по проектированию-первый набросок
р i н Руководства по пользовательскому интерфейсу - базовая версия
' р 1' • Руководства по проектированию - базовая версия
' и и • Шаблоны для проектирования
' , • Прецедент разработки расширенна тестирование и управление меняющимися требованиями
. • Автоматизация тестирования
Ц d U И Si
" [р Прецедент разработки расширен на развертывание
ИтерацияН-t |.= ИтерацияПр-1 п ИтерацияПр-2 П Итерация Пост-1 Н Итерация Пост-2 ц ИтерацияВ-t I
Начало / \ Проектирование \ Построение /. Внедрение /
Рис. 11.2. Внедрение RUP и инструментов. Совершенствование Прецедента разработки, связанных
с ним руководств, а также сопутствующих инструментов
Конфигурирование и модификация При конфигурировании и модификации
требуется выполнить подгонку RUP, оставив только те части, которые нужны для
проекта; разработать дополнительные руководства, которые могут понадобиться;
настроить соответствующий учебный материал; подогнать и интегрировать ин-
струменты, а также шаблоны.
В главе 10 мы обсудили, каким образом проводить конфигурирование, реали-
зацию и модификацию Rational Unified Process. Практически в любом случае
применения RUP только в одном проекте нужно концентрироваться на создании
Конфигурации RUP и Представлении процесса с помощью RUP Builder, а также
па создании прецедента разработки. И то и другое можно сделать при не-
значительных затратах времени. Если вы используете RUP во втором или треть-
ем проекте, вам можно подумать о создании Тонких Плагинов, но о создании
Структурных Плагинах должны, как правило, думать лишь участники очень
крупных проектов (более 80 человек) или организаций (см. гл. 10). Модификация
R 863
226
Глава 11
Rl И* также включает в себя модификацию поставляемых с RUP шаблонов, таки'
как шаблоны Описания прецедентов использования, Описания архитектуры
программы и т.п.
Пеане, где это возможно,
еырайтесь уменьшать
чиспо создаваемых арте-
Факюв, если это не по-
вредит качеству.
Настраивать нужно только то, что необходимо и что прям-
приведет к улучшению результатов проекта. Обычная оцпю
ка - применять слишком «тяжеловесную» версию Rl'P
со слишком большим числом артефактов, создавать которые
бесполезно. Везде, где это возможно, старайтесь уменьши! в
число создаваемых артефактов, если это не повреди!
качеству. Если вы сомневаетесь, нужен ли вам данный артефакт, обычно включи! i.
cio не следует (вы всегда сможете добавить его позже, когда поймете, что были не
нравы). Однако следует принимать во внимание ценность артефакта не только при
отдании первой версии системы, но и при ее обслуживании и улучшении.
Во многих случаях вы сможете снизить необходимость в крупных модифика
цнях, задействуя наставников. Опытный в RUP эксперт может направлять вас, in >
называя как и какие части процесса применять, что по ходу значительно повыша
ci гибкость реализации процесса. Выяснив, что работает для вашего случая, нм
можете выбрать время и задокументировать эти сведения.
Важно, чтобы обучение соответствовало вашему модифицированному процес
су. В большинстве случаев не нужно физически изменять учебный матерная
Иучше, чтобы инструктор понял прецедент разработки и решил, какие разделы
опустить, какие быстро просмотреть, а на какие потратить дополнительно!
время.
Модификация инструментальной среды может включать в себя интеграцию пн
с грументов между собой, модификацию шаблонов и настройку инструментов.
Выполнение
Теперь пора внедрять процесс и инструменты в проект. Следуя плану, вы
обучаете людей, публикуете прецедент разработки и Конфигурацию RUP, раз
вертываете инструменты и запускаете проект. Одним из преимуществ итератив
пой разработки является то, что она позволяет улучшать процесс и инструменты
па всем протяжении работы над проектом, как только выясняется, что работае,
а что нет. Итеративная разработка означает, что на ранних стадиях проекта вы
выполняете небольшую часть работы с требованиями, небольшую часть проск
шрования. реализации и тестирования. Однако одновременный ввод в действие
всех инструментов в «день икс» может оказаться непосильным, поэтому нужно
Внедрение Rational Unified Process
227
заранее позаботиться о «легких» вариантах использования инструментов. Напри-
мер, вы можете использовать в фазе Начало только некоторые очень ограничен-
ные возможности вашего средства визуального моделирования или вообще про-
ектировать на письменной доске. Возможно, вы начнете заниматься автоматиза-
цией тестирования во второй итерации фазы Проектирование.
Ниже приведем краткий обзор того, что происходит в проекте
• Перед началом проекта. Перед тем как проект действительно начнется, нужно
обучить основных исполнителей, как правило, инженеров-технологов (process
engineers), архитекторов, лидеров команды и менеджеров проекта. Эти люди
должны запустить проект, нанять нужных людей и сформулировать правильные
планы на фазу Начало и далее. Как правило, до начала фазы Начало требуется
создать инструментальную инфраструктуру, в частности средства для управле-
ния требованиями и изменениями, а также средства для отслеживания дефектов.
Наставник может помочь с составлением прецедента разработки, обучением,
планированием проекта и реализацией процесса.
• Фаза Начало. В ходе этой фазы акцент обычно делается на том, чтобы по-
нять, как можно улучшить управление требованиями (дисциплина Требова-
ния) и как управлять проектом (дисциплина Управление проектом). Вам нуж-
но создать инфраструктуру для управления конфигурациями до начала фазы
Проектирование и провести обучение «к сроку» в этих областях. Наставник
может проводить обучение «к сроку», а также работать бок о бок с членами
команды, показывая, как работать с таким дисциплинами, как Требования
и Управление проектом. Специалист по инструментам или наставник могут
помочь настроить стабильную среду управления конфигурациями.
• Фаза Проектирование. К концу фазы Проектирование все процессы и ин-
струменты уже установлены. Наиболее критичные процессы в этой фазе Ана-
лиз и Проектирование и Управление конфигурациями, поскольку нужно соз-
дать базовую версию требований и архитектуры и иметь хорошо функцио-
нирующую инфраструктуру Управления конфигурациями, которая позволит
командам разработчиков работать параллельно. Начало и Проектирование-
это две фазы, во время которых наличие наставника наиболее желательно. На-
ставник направляет людей на решение наиболее существенных задач
и применение наиболее важных практических методов. Наставник осуществ-
ляет обучение «к сроку», которое позволяет обучать быстро и не перегружать
людей информацией. В ходе фазы Проектирование вы будете тестировать
архитектуру и ключевые функции. Следовательно, вам необходимо удосто-
вериться. что среда тестирования установлена и работает. Также необходимо
в-
228
Глава 11
уделить особое внимание эффективности управления итеративной разработ-
кой, поскольку осуществление инкрементной разработки архитектуры, как
правило, является не совсем очевидной задачей.
• Фаза Построение. В этой фазе не вводится никаких новых процессов и ин-
струментов. Акцент здесь делается на создании продукта, поэтому среда
разработки должна быть стабильной. Важный момент в фазе Построение
ввод в курс дела новых членов команды. Наставник поможет провести тонкую
настройку процесса, познакомить с процессом новых членов команды и заста-
вить команду сконцентрироваться на результатах проекта.
• Фаза Внедрение. Новые процессы и инструменты не вводятся. В этой фак-
акцент сдвигается от специфичных для проекта усовершенствований процесса
к формулированию завершающих проект выводов, которые позволят усо
вершенствовать процесс и средства в будущих проектах. Опыт, приобретен
ный в текущем проекте, собирается, обобщается и сохраняется в такой форме,
чтобы его можно было использовать в будущих проектах.
Оценка результатов
Оценка производительности команды и эффективности внедрения RIH’
и инструментов должна проводиться непрерывно, чтобы можно было совершено
вовать процесс по ходу работы над проектом. Тем не менее в конце проекта вам
следует потратить время на общую оценку работы, подтверждение правильное i и
жономического обоснования применения RUP и сопутствующих инструментов
Достигли ли вы поставленных целей? Проведите оценку труда людей, процесса
и инструментов и поймите, на какие области нужно обратить внимание в будущих
проектах. Занесите все свои выводы в окончательный отчет.
Применение RUP в малых проектах
При применении RUP в малых проектах, в которых занято немного людей, m
пользуется тот же самый подход, что и в больших проектах. Различие не во вин
мании к процессу и не в том, что вы делаете, а лишь в степени формальности до
кументирования решений и в строгости используемого подхода при передаче ин
формации. Рассмотрим наши пять шагов и укажем на некоторые различия.
I. Предварительная оценка. Как и в более крупных проектах, нужно поняи.
каких целей вы хотите достичь, используя RUP, а также решить, что будш
иметь наивысший приоритет. Однако это, скорее всего, не будет вноситься
в экономическое обоснование, а будет иметь форму устного соглашешы
Внедрение Rational Unified Process
229
в команде проекта или служебной записки, используемой в качестве основы
для принятия инвестиционных решений.
2. Планирование. Здесь также нужно спланировать, как проводить внедрение
улучшений процесса. Поскольку усилий потребуется меньше, не нужно доку-
ментировать данный план также строго, как в проектах большого размера.
3. Конфигурирование и модификация. Конфигурируйте RUP, по избегайте
создания Структурных Плагинов, поскольку они. скорее всего, не будут того
стоить. Проведите минимальную модификацию инструментальной среды.
Вместо модификаций учебного материала используйте наставника, который
будет управлять применением процесса и инструментов в проекте и поможет
понять, чем ваш подход должен отличаться от того, которому учат на любых
формальных курсах.
4. Выполнение. Внедрите в проект процесс и инструменты, обучите участников
проекта, задействуйте наставника и наконец начните работу над проектом.
Главное отличие между большими и малыми проектами в том, что в больших
проектах в передаче знания вы можете больше полагаться на наставников (и не
зависеть исключительно от формального обучения), по несколько человек, все
же следует отправить учиться.
5. Оценка результатов. Проведите совещание всей команды, на котором оце-
ните производительность работы и сравните ее с ожидаемой в начале работы
над проектом. Выявите возможности для будущих улучшений.
Добивайтесь эффективной окупаемости инвестиций с помощью использования
инструментов
Итеративная разра-
ботка сама по себе
создает сильную по-
требность в средст-
вах автоматизации.
Когда вы сталкиваетесь с проблемами в ходе разработки
программного обеспечения, вам приходится анализировать
проблему, ее влияние на бизнес и определять, как лучше всего
с ней справиться. Очень часто вы будете обнаруживать, что для
того чтобы в итоге получить улучшение, вам придется усо-
вершенствовать практические методы и средства автоматизации (инструментальные
средства) или и то и другое. Итеративная разработка сама по себе создает сильную
потребность в средствах автоматизации. Поскольку каждая итерация является пол-
ным циклом разработки, выполняемым за очень короткое время, для нес требуются
инструменты с поддержкой таких коротких циклов, которые к тому же достаточно
гибкие. Отсутствие нужных инструментов может означать потерю части потенци-
альных преимуществ итеративной разработки.
230
Глава 11
Вее это объясняет, почему Rational Unified Process тесно интегрирован с ни
> । рументами, используемыми в различных частях жизненного цикла. Тем не мс
псе RUP не заставляет вас применять эти инструменты, но если вы решили
in пользовать их, то в RUP вы найдете руководства по использованию инструмен
1.ЫЫ1ЫХ средств от компании IBM Software или других производителей.
В таблице 11.1 мы привели несколько примеров того, как можно соотнеси!
проблему с ее влиянием на бизнес и какой вид автоматизации может помочь
। правиться с данной проблемой и, следовательно, улучшить результаты.
' )го не означает, что вы должны использовать все описанные средства автома
шзации. Но когда вы сталкиваетесь с ранее где-нибудь описанной проблемой,
нам нужно понять ее влияние на бизнес и, в какой мере ее можно исправить, усо-
вершенствовав практические методы и/или внедрив средства автоматизации.
Внедрение RUP в крупных организациях
Реализация процесса разработки программного обеспечения в крупных органп-
1.ПЩЯХ, включающих сотню и более человек, - задача сложная, и проводить ее нуж-
но управляемым способом. Мы рекомендуем рассматривать ее как программу с яс
UI.IMH бизнес-целями, четко определенными вехами и выделением людских
ресурсов. Управлять такой программой следует в соответствии с целями и вехами.
тали 11.1 Использование инструментов для решения крупных проблем разработки. Чтобы
ar hinib максимальной окупаемость инвестиций при использовании RUP, нужно подумать о
применении инструментов, которые полностью поддерживают итеративную разработку,
например средств для создания персонального рабочего пространства, автоматизированной
, порки, автоматизированного тестирования, управления требованиями и отслеживания
а фсктов
Обнаруженные проблемы
И выпуске некоторые файлы
пропущены или присутствуют
старые версии файлов
Разработка основывается на
ыарых файлах
Влияние на бизнес
Снижено качество
Тратится время на повторный
поиск уже выявленных
дефектов
Возможные решения
• Внедрить систему Управление
конфигурациями и измене-
ниями.
, • Пример: Rational ClearCase
и Rational ClearQuest
Внедрение Rational Unified Process
231
Table 11.1 Использование инструментов для решения крупных проблем разработки. Чтобы
сделать максимальной окупаемость инвестиций при использовании RUP, нужно подумать о
применении инструментов, которые полностью поддерживают итеративную разработку,
например средств для создания персонального рабочего пространства, автоматизированной
сборки, автоматизированного тестирования, управления требованиями и отслеживания
дефекпiов (Продолжа/ие)
Обнаруженные проблемы
. • Разработчики идут друг за
' другом, нет параллельной
! работы
Влияние на бизнес
Больше задержка, больше
время до выхода на рынок
Итеративная разработка
увеличивает нагрузку
на регрессионное
тестирование
Трудно разобраться, какие
требования являются теку-
щими, и когда они были
изменены
Непонятно, какие запросы на
изменения нужно реализовы-
вать, а какие - нет.
Изменения, которые нужно
реализовывать не
реализуются и наоборот
Повышается стоимость
тестирования или дефекты
выявляются поздно, и их
исправление стоит дороже
Инвестиции в разработку
делаются на основе
устаревших требований, что
повышает стоимость
разработки и приводит к недо-
вольству заказчика
Снижение качества и повыше-
ние стоимости разработки
Возможные решения
• Внедрить систему Управлениу
конфигурациями и измене-
ниями, дающую возможность
создавать персональные
рабочие пространства и
активно работать с версиями.
• Пример: Rational ClearCase
и Rational ClearQuest
• Автоматизация тестирования
• Пример: Rational Suite
TestStudio
• Управление требованиями
с помощью Средства управле-
ния требованиями.
• Пример: Rational RequisitePro
• Внедрение системы слежения
за изменениями и дефектами.
• Пример: Rational ClearQuest
Когда вы видите в своей организации проблемы, вы можете почувствовать силь-
ное желание исправить их все сразу, особенно, когда многие из них проявляются
одновременно. Организации, как и отдельные люди, могут справиться лишь
с ограниченным числом изменений, и одни организации могут быть лучше готовы
к изменениям, чем другие. Мы рекомендуем вам опросить людей и выяснить их от-
ношение и готовность к изменениям.
232
Глава 11
Программа усовершенствования процесса представляет собой комбинацию
проектов следующих типов.
• Проекты по совершенствованию процесса и инструментов (ПСПИ)2, целью
которых является создание новых базовых версий процесса и инструментальной
среды, предназначенных для развертывания в организации. В таких проектах
создается инфраструктура, облегчающая последующее внедрение процесса
н инструментов.
• Пилотные проекгы, представляющие собой проекты по разработке программно
ю обеспечения с дополнительной целью - исследовать возможности организации
по применению определенного процесса и инструментальной среды и проверти,
чю представляЮт собой этот процесс и инструментальная среда.
• Проекты по разработке программного обеспечения, в которых и использую к я
процесс и инструментальная среда.
11иже мы изучим каждый тип проектов, и обсудим в разделах «Типичная програм
мл для умеренных изменений», «Типичная программа для крупных изменений-
и -Агрессивная программа для крупных изменений» разные схемы программ
инсдрения RUP в зависимости от ваших возможностей адаптации к изменениям,
нремепных ограничений, желания рискнуть и многих других факторов.
Проекты по совершенствованию процесса и инструментов (ПСПИ)
I (елью проектов по совершенствованию процесса и инструментов является соз
ынис следующего поколения процесса и сопутствующей ему инструментальной
। реды (в идеале вместе с повторно используемыми приемами и подходами),
ii.ici роенного на специфические нужды данной организации.
Как и в случае проекта RUP, мы делим ПСПИ на четыре фазы, каждая из ко
inpi.ix носит то же название и имеет те же самые бизнес-цели, что и проект но
ра (работке программного обеспечения с помощью RUP (см. таблицу 11.2).
Аш пинская аббревиатура - РТЕР (Process and Tool Enhancement Projects). - Примеч. пер.
Внедрение Rational Unified Process
233
Table 11.2 Четыре фазы проекта no совершенствованию пронесса и инструментов. ПС ПИ
состоит из четырех фаз, имеющих i/eiu, очень сходные с целями обычного проекта
по разработке программного обеспечения с помощью RUP
| Фазы Цели Описание и итог каждой фазы
I Начало Понять цели и • Провести оценку работы организации и решить, какие улучшения
границы следующей I версии процесса и будут способствовать наибольшей окупаемости инвестиций. Например, нужно ли сконцентрироваться на Управлении требова-
ниями, Анализе и проектировании или на Управлении конфигурациями
j ИНЫ pyMtJHldJIbHUH । • Разработать экономического обоснование. Получить одобрение этого
среды 1 : 1 1 • обоснования от всех заинтересованных сторон, а также решение о продолжении или прекращении проекта от всех заинтересованных лиц • Разработать высокоуровневый план и бюджет проекта. Создать подробный план следующей фазы и определить ресурсы
J Проектирование Доказать осуществи-; • Создать подробный план и расставить приоритеты реализации
j мость следующей ; настроек процесса, учебного материала и инструментальной среды. Создать каркас для наиболее важных/спорных настроек
ии и и II |-1и |дииии и • Если вы будете разрабатывать Плагины RUP, создать Плагин без
инструментальной содержимого (см. гл. 10 раздел «Разработка Плагинов RUP»)
: среды в условиях • Создавать и выполнять пилотные проекты, чтобы проверить способ-
1 вашей организации । , i ность организации применять описанный процесс и инструмен- тальную среду • В случае проведения крупных настроек, может возникнуть необходи- мость разделить фазу Проектирование на несколько итераций, где борьба с наиболее существенными рисками, связанными с модифика- циями будет вестись в первой итерации • Планировать следующую фазу
iПостроение
Создать приме-
нимую бета -версию
следующего поколе-
ния процесса
и инструментальной
среды
।
Создать полную версию настроенного процесса (включая все разрабо-
танные вами Плагины RUP), сопутствующей инструментальной среды
и обучающего материала. Материал должен иметь качество бета-
версии, что означает возможность проведения тонкой доводки до
внедрения в масштабах организации.
Если модификации были крупные, попробуйте их на практике с
помощью одного или нескольких пилотных проектов или их частей.
Эго даст вам необходимые сведения по требующимся улучшениям
настроек
Выявите риски и проблемы в процессе, учебном материале и исполь-
зуемых инструментах
Создайте план проведения обучения в организации. Большая часть
обучения должна проводиться непосредственно перед тем, как эти
знания будут востребованы, но некоторых ключевых участников, таких
как наставники, преподаватели, менеджеры проекта и лидеры команд,
возможно, придется обучать вне контекста проекта
В случае крупных настроек может возникнуть необходимость разде-
лить фазу Построение на несколько итераций, в которых сначала
ведется борьба с наиболее существенными рисками
Планируйте следующую фазу
234
Глава 11
iaiiii 11.2 Четыре фазы проекта по совершенствованию процесса и инструментов. ПСПП
тапчшп из четырех фаз, имеющих цепи, очень сходные с целями обычного проекта
а, > ра работке программного обеспечения с помощью RUP (Продолжение)
Фазы Цели Описание и итог каждой фазы
|||||’Д|х;ние
Тонкая настройка
следующей версии ,
процесса
и инструментальной
среды, подготовка
к внедрению в мас-
штабах организации
' и по мере необходи-.
мости планирование
следующих проек-
тов, направленных
на их совершенство-
вание
Оценить потенциальные проблемы, связанные с процессом
и инструментальной средой, путем внедрения в одном или нескольких
пилотных проектах или их частях изменений, внесенных в процесс,
учебный материал и инструментальную среду в фазе Построение.
Заметим, что начинать новые пилотные проекты необязательно,
можно внедрить изменения в пилотные проекты, начатые в фазах
Проектирование или Построение
Подготовить организацию к внедрению нового процесса и инструмен
тальной среды, для чего проводить обучение наставников, преподава
телей, менеджеров проекта и лидеров команд. Внести в документы,
каким образом будет внедряться новый процесс и инструментальная
среда, включая способы установки и развертывания инструменталь-
ных средств, способы использования наставников и обучения, а также
способы обратной связи для получения информации о работе среды
Определить необходимость дополнительных проектов по улучшению
процесса и инструментальной среды
Пилотные проекты
Пилотные проекты - это проекты по разработке программного обеспечения
< кчюлнительной целью - проверкой и сбором сведений о новом процессе и пн-
' i рументальной среде, включая сопутствующие материалы, в частности учебный
мак-риал. Что следует принять во внимание при запуске пилотного проекта?
• Цель и сроки. Пилотный проект должен снижать наиболее существенные
риски, связанные с вашим процессом и инструментальной средой. В больший
cine организаций самые большие опасности связаны е применением главных
практических методов RUP: итеративной разработки, управления требования-
ми, управления конфигурациями и изменениями и инструментов, поддержи
кающих эти методы. Эти риски нужно свести к минимуму в фазе Проектпро
ванне ПСПП. Это означает, что в этой фазе нужно работать с пилотными про
сктами. Если вы производите крупные модификации RUP, вам, скорее всего,
захочется их испытать. Это делается с помощью пилотных проектов в фазах
11остроение и Внедрение ПСПП.
• Размер команды. Лучше всего большинство пилотных проектов работает, если
в команду входит шесть-восемь человек. Этого достаточно, чтобы внести неко
юрый элемент сложности, но недостаточно, чтобы присутствовал риск провала
11погда может понадобится задействовать больше людей, например, потому чю
Внедрение Rational Unified Process
235
главный риск, который вы хотите уменьшить (или главная неопределенность), --
это будут ли процесс и инструментальная среда работать в случае больших
проектов.
• Длительность и временные ограничения. Вам нужно иметь быструю цепь
обратной связи с работой процесса и инструментальной среды. Часто не требуется
выполнять весь пилотный проект, чтобы получить искомую информацию. В боль-
шинстве случаев для получения требуемой информации нужно пройти как
минимум одну итерацию фазы Построение пилотного проекта, поскольку к этому
моменту будут внедрены все инструменты и опробовано большинство аспектов
процесса разработки. В других случаях может быть достаточно только одной
итерации пилотного проекта. В идеале длительность пилотного проекта - от двух
до шести месяцев, что достаточно много для внесения некоторой сложности,
нодостаточно мало, чтобы можно было продвигаться вперед и внедрять опыт
в другие проекты. К тому же не нужно, чтобы временные ограничения были
слишком жесткими. Нужно иметь возможность уделить достаточно времени тому,
чтобы научиться правильно применять процесс и инструменты.
• Подбор персонала. Выбирайте для участия в пилотном проекте таких людей,
которые хотят научиться чему-то новому и которые имеют способности и воз-
можности выполнять функции наставников в будущих проектах. Члены
команды пилотного проекта, выполняющие роль внутренних наставников, -
самый быстрый способ передачи знаний. Также убедитесь, что менеджер про-
екта и архитектор достаточно квалифицированы и работают как одна команда,
поскольку они выполняют две наиболее важные роли.
• Важность и сложность. В пилотном проекте должно создаваться реальное про-
граммное обеспечение, имеющее достаточно большое деловое значение. Если
приложение не будет достаточно важным и сложным, люди скажут: «Ну, созда-
ние этого приложения ничего не доказывает. Теперь мы делаем настоящую про-
грамму и не думаем, что это можно сделать с помощью RUP». Скорее всего, вы
не захотите, чтобы проект был настолько критичным или сложным, чтобы по-
ставить под угрозу провала весь бизнес. Это ничего не докажет, а вы после тако-
го пилотного проекта не станете лучше, чем вы были до него. Вы лишь поймете,
что, когда используете RUP впервые и в неоптимальных условиях, он не сможет
спасти обреченный проект. Однако во многих случаях вы действительно можете
выбрать очень заметный, критичный проект. Как правило, это будет тот случай,
когда терять больше нечего или вам нужно провести быстрое усовершенствова-
ние процесса и инструментальной среды, чтобы добиться успеха в бизнесе.
Преимущество выбора критичного проекта в том, что в таких проектах, скорее
ZIG
Глава 11
hccio, участвуют самые талантливые люди, им оказывается самая серьезная пол
к-ржка со стороны менеджмента и на них выделяются самые большие ресурсы
и.। необходимое обучение, наставничество и инструменты.
Проекты по разработке программного обеспечения
Внедрение RUP в проекты по разработке программного обеспечения было
ОН1К.1ПО выше в разделе «Применение RUP в проекте». Перечислим еще раз пяи.
III.II ок.
I Предварительная оценка. Оцените, с какими проблемами ваша команда
с।ачкпвалась в прошлом и какие проблемы наиболее приоритетны в расчен-
па иуду шее.
’ Планирование. Спланируйте задачи по развертыванию процесса, такие как
сю модификации, обучение и наставничество, приобретение необходимые
ине । рументов.
i Конфигурирование и модификация. Выполните необходимое конфигурирова
пне и модификацию процесса, инструментальной среды и учебного материала.
I Выполнение. Внедрите процесс и инструменты в проект, обучите участии
кон, привлеките наставников и запускайте работу над проектом.
Оценка результатов. Оцените, как выполнялся проект, и сравните резуль
i.iii.i с ожиданиями. Выявите возможности для будущих улучшений.
Замс । им, что при внедрении RUP в конкретный проект в рамках проводимы!
в npi апизации программы ио применению RUP, основная работа по трем первым
in.нам (Предварительная оценка, планирование, конфигурирование и модифика
пня) можс! уже быть выполненной в этой самой общей программе. Например
н поп программе может уже быть определена потребность организации в усе
исршспсгвований RUP путем разработки дополнительных руководств по по
< । роению систем с особыми требованиями к безопасности. Это весьма облегчав i
и i.iiiiipoBanne, поскольку описано, каким образом внедряется процесс и ин
। । р\ мен । ы, и в рамках программы, возможно, уже проведена необходимая моди
фпкация и конфигурирование. Инфраструктура поддержки, то есть наставничес!
по и службы обучения, уже могут присутствовать, что облегчит стадию Выполис
пис конкретного проекта. Тот факт, что проект по совершенствованию процесса
и ине । рументов, как правило, уменьшает объем работ, связанных с предварителк
поп оценкой, планированием, конфигурированием и модификацией RUP, указы
Внедрение Rational Unified Process
237
нает на один важный аспект программы - повышение вероятности успеха при
снижении общей стоимости отдельных проектов, а также при совершенствова-
нии в них процесса и инструментальной среды.
Типичная программа для умеренных изменений
В нашем первом сценарии программы по применению RUP мы предположим,
что в организацию входит приблизительно 10 проектных команд с 10 участника-
ми в каждой. Планируется использовать все дисциплины RUP и ввести новые
средства для управления требованиями и визуального моделирования. Уже
имеются хорошие средства для автоматизации тестирования и для управления
конфигурациями. Хотя некоторые люди в организации и имеют опыт работы
с RUP, у большинства его нет. Многие являются новичками в итеративной
разработке, но несколько человек все же имеют опыт работ с другими струк-
турными подходами. На основе описанных размеров команды, целей и уровня
опыта была выбрана схема программы, показанная на рис. 11.3.
• ПСПИ. Ожидается, что команде удастся применить RUP и сопровождающие
инструменты с проведением лишь небольших настроек. Будут созданы три кон-
фигурации RUP для типичных проектов, модифицированы некоторые шаблоны,
созданы типичные прецеденты разработки и запущены рекомендованные про-
граммы обучения и наставничества. Не планируется создавать Плагины RUP
или вносить крупные изменения в учебный материал. Инструменты будут
использоваться с минимумом настроек, так что потребуется только один проект
ПСПИ. (Конечно, мы по-прежнему рекомендуем, чтобы в организации проводи-
лось непрерывное совершенствование процесса. См. раздел «Непрерывное
совершенствование процесса».)
• Пилотные проекты. Нужно убедиться, что в проекте успешно применяется
как RUP, так и новые для данной организации инструменты. По этой причи-
не необходимо выполнить один пилотный проект. Поскольку не требуется
проверка крупных настроек, пилотный проект запускается в самом начале
фазы Проектирование ПСПИ. Если возникает ощущение, что три разрабаты-
ваемые конфигурации RUP серьезно отличаются друг от друга и их приме-
нение связано с большой степенью риска, можно провести три пилотных
проекта, что позволит поработать со всеми тремя конфигурациями и протес-
тировать их.
238
Глава 11
Обычный - 10 проектных команд. Модификация небольшая
i Создана концепция Риски сведены к минимуму. RUP внедрен в организацию.
i программы внедрения RUP Есть детальное понимание того, Проведена оценка
как внедрять RUP в организацию успешности программы
I > ; пени ; • :
| j I Пилотный проект
i ; : i Проект | ;
I ! : Г”'"........... .....т :
| > j Проект :
| ' Проект | ;
[ : : i Проект I
I : 1......................... :
I ; : . ;
I ; ; ; Проект I
i : • •
Рис. 11.3. Типичный подход к реализации умеренных изменений. Когда реализация RUP и сопро-
вождающих его инструментов связана для организации с небольшими изменениями,
обычно достаточно в ходе ПСПИ выполнить один пилотный проект, а к концу ПСПИ вне-
дрить новый процесс и инструментальную среду во все проекты
• Проект по разработке программного обеспечения. По окончании ПСПИ
RUP и соответствующие инструменты внедряются в один проект за другим.
Типичная программа для крупных изменений
В нашем втором сценарии программы по применению RUP мы предположим,
что в организацию входит приблизительно 10 проектных команд с 10 участника-
ми в каждой. Планируется внедрить весь RUP и все инструменты на весь жизнен-
ный цикл. У организации нет предварительного опыта работы с RUP, есть специ-
фические нужды, которые заставляют производить весьма крупную модифика-
цию RUP, чтобы он соответствовал потребностям. Многие являются новичками
Внедрение Rational Unified Process 239
в итеративной разработке, ио некоторые все же имеют опыт работ с другими
структурными подходами. Опыт работы с инструментами, которые планируется
внедрить, довольно ограничен, и, чтобы RUP соответствовал специфическим
потребностям, необходимо создавать Плагины.
Решено развертывать RUP и связанные с ним инструменты постепенно, в дна
этапа. На первом внедрять итеративную разработку, свои внутренние Плагины,
дисциплины Управления требованиями и Управления конфигурациями и измене
ниями и сопровождающие их инструменты, а во втором - все остальные чао и
RUP и связанные с ними инструменты. Поэтому была выбрана схема программы,
показанная на рис. 11.4.
Обычный -10 проектных команд. Модификация крупная
I Создана Риски сведены к минимуму. В большинство проектов внедрена RUP внедрен в организацию.!
. концепция Есть детальное понимание итеративная разработка и инфраструктура Проведена оценка :
’ программы того, как внедрять управления требованиями, успешности программы <
j внедрение RUP RUP в организацию конфигурациями и изменениями
| I : пспи : i i пспи i
’ ‘ ^Пилотный проект ।
I I -Пилотный проект; '
; • , Проект 1 : -
! Проект ; , j
; ; • I ; Проект i >t
j , ^Пилотный проект; :
i ; ; I Проект ;
I : ' .. ' *
। : , ...............................................
’ । Проект г :
Рис. 11.4. Типичный подход к внесению крупных изменений. Когда внедрение RUP и сопровож-
дающих его инструментов связано для организации с крупными изменениями, часто бы
вает необходимо их постепенное введение. Это достигается при помощи двух ИСТJH, ка-
ждый с одним или несколькими пилотными проектами. К концу каждого ПСПИ иронию
дится внедрение текущего процесса и инструментальной среды
• ПСПИ. Для каждого этапа внедрения требуется один проект ПСПИ. В первом
проекте ПСПИ разрабатываются Плагины RUP, и RUP подгоняется для cootbci
ствия имеющемуся процессу в части анализа и проектирования, реализации,
тестирования и управления конфигурациями и изменениями. Во втором проеме
240
Глава 11
ПСПИ добавляются дисциплины RUP «Анализ и проектирование», «Реализация»
и «Тестирование», а также соответствующие инструменты. (Конечно, мы
попрежнему рекомендуем, чтобы в организации проводилось непрерывное
совершенствование процесса. См. раздел «Непрерывное совершенствование
процесса».)
• Пилотные проекты. Нужно убедиться, что в проекте успешно применяется
RUP, инструменты управления требованиями, управления конфигурациями и из-
менениями и соответствующие руководства. Поэтому запустить пилотный проект
нужно на ранних стадиях фазы Проектирование ПСПИ. Мы настойчиво рекомен-
дуем, чтобы те люди, которые будут проводить модификацию в пилотных проек-
тах, выступали в роли наставников. Так команда не только узнает, какие модифи-
кации необходимы, но также поймет и идеи, стоящие за апробируемыми модифи-
кациями процесса. Как только будут определены модификации и созданы черно-
вые Плагины RUP, к концу фазы Построение проекта запускается второй
пилотный проект. Третий пилотный проект запускается по завершению модифи-
каций, проводимых во втором ПСПИ, к концу фазы Построение в целяхсбора ин-
формации по функционированию модификаций.
• Проекты по разработке программного обеспечения. Как только будет за-
вершен первый проект ПСПИ, созданный процесс и инструменты внедряются
в серию проектов. По завершению второго ПСПИ полная (модифицирпован-
пая) версия R.UP внедряется во все проекты.
Агрессивная программа для крупных изменений
11аш третий сценарий предполагает, что, как это иногда бывает, у вас нет столько
времени, сколько требует ранее описанный подход. Например, когда организация
орадает от таких серьезных проблем, что любое изменение оказывается к лучшему,
вам может подойти более радикальная программа, где, иначе говоря, потенциал для
улучшений будет больше, чем неизбежные проблемы. При агрессивном подходе
(рис. 11.5) процесс и инструменты используются прямо в критических проектах
I акой проект (проекты) будет считаться пилотным проектом (проектами), посколькх
ею целью будет выявление возможностей организации применять определенный
процесс и инструментальную среду.
• ПСПИ. Все изменения вносятся за один проект ПСПИ, скорее всею.
в нескольких итерациях его фаз Проектирование и Построение. Чтобы снизпн.
риск и сэкономить время, задействуются люди, как правило, контрактники, ко
Внедрение Rational Unified Process
241
Агрессивный - 10 проектных команд. Модификация крупная
Создана концепция В ключевом
программы внедрения проекте успешно
RUP применен RUP
RUP внедрен в организацию.
Проведена оценка
успеха программы
ПСПИ ' |
Пилотный проект !
[ Проект
: [ Проект
; I Проект
. ! Проект
Рис. 11.5. Агрессивный подход к реализации RUP и соответствующих инструментов. Когда вгггг ы
организация сталкивается с крупными проблемами и время является критическим фаг
тором, вы можете использовать агрессивную реализацию, когда проект ПСПИ тесно свя
зывается с пилотным проектом. Выбрав ответственный и критичный пилотный проект, ни
получаете гарантию, что в нем участвуют наиболее талантливые люди. Если hh.ioihi.hi
проект можно считать успешным, новый процесс и инструментальная среда внедрякш ч
во всей организации
торым ранее приходилось работать с ПСПИ. (Конечно, мы по-прежнему реки
мендуем, чтобы в организации проводилось непрерывное совершенствование
процесса. См. раздел «Непрерывное улучшение процесса».)
• Пилотный проект. В качестве пилотного берется критический проект, чю
гарантирует участие самых талантливых людей, самую серьезную поддержку
со стороны менеджмента и самую лучшее финансирование необходимого об\ пе-
ния, наставников и инструментов. Пилотный проект ежедневно взаимодейс гнус i
с проектом ПСПИ. Задачи ПСПИ подчиняются нуждам пилотного проекта, и ре-
зультатом является непрерывная обратная связь и информация о том, что работ а-
ет, а что нет.
242
Глава 11
• Проекты по разработке программного обеспечения. Когда пилотный про-
ект можно будет считать успешным, RUP и сопровождающие инструменты
внедряются в один проект за другим. Используется «не совсем окончательная»
версия процесса и инструментальной среды, созданная в ПСПИ.
Непрерывное улучшение процесса
Нужно определить Совершенствование результативности проектов вследствие
процедуры, которые применения RUP должно производиться непрерывно. Это оз-
Оудут использоваться Ha4aeTi что вы должны постоянно совершенствовать применяе-
дня совершенствова-
ния процесса и инстру-
ментальной среды.
мый процесс, используемые инструменты, а также свои способ-
ности по введению в курс дела новых участников команд и но-
вые команды. Завершив свою первоначальную программу
внедрения RUP, нужно определить процедуры, которые будут использоваться для
совершенствования процесса и инструментальной среды. Такие процедуры могуч
включать в себя следующее:
• создание команды, которая будет отвечать за совершенствование процесса
и инструментов. Эта команда будет непрерывно исправлять мелкие ошибки
и инициировать по мере необходимости дополнительные проекты ПСПИ;
• установление обратной связи с каждым проектом. Этого можно добиться, если
сделать стандартным создание отчета по завершению проекта или путем час-
того проведения опросов членов команд. Также вы можете воспользоваться
свойством обратной связи в самом продукте RUR Оно позволяет участникам
проекта предлагать улучшения составлять сообщения об ошибках и посылал,
эти предложения и замечания команде разработки RUP в IBM Software
В качестве альтернативы, вы можете перенаправить все эти сообщения в свою
внутреннюю команду разработки.
Наличие повторно используемых приемов и подходов может радикально уве-
личить ваши возможности в разработке программного обеспечения. Вам следуем
подумать об определении процедур, которые позволят использовать разработан
ные подходы в разных проектах. Можно создать документ и внести свои нарабоч
кп в пакет в соответствии со спецификацией Reuse Asset Specification (RAS)!
которая представляет собой стандарт документирования и создания пакетов гю
вчорно используемых приемов и подходов. Следует постоянно следить за па
лнчием повторно используемых активов, создаваемых другими компаниями.
3. См. http://www.rational.com/rda/index.jsp. - Примеч. авт.
Внедрение Rational Unified Process
243
Заключение
В качестве причин внедрения продукта RUP и
сопровождающих инструментов можно назвать по-
лучение экономических выгод, определяемых улучше-
нием результатов проектов в смысле получения систем
более высокого качества, снижения стоимости или ус-
корения выхода на рынок. Временные затраты на со-
вершенствование процесса быстро станут бесполезны-
ми, если эти цели не будут ясны каждому.
В качестве причин внедрения
продукта RUP и сопровох
дающих инструментов мох ш'
назвать получение экономен1
ских выгод, определяемы'
улучшением резуль тативнос/и
проек юн
При внедрении RUP в проект вы проходите пять главных шагов: пре i
варительная оценка, нужно ли применять RUP полностью или частично; ила
нирование внедрения; конфигурирование и модификация RUP, инструмент аль
ной среды и обучающего материала; выполнение проекта и оценка результант
внедрения RUP.
Реализация RUP в крупной организации - задача сложная, и лучше всего прово-
дить ее в виде программы, включающей в себя проекты трех типов: проекты по со-
вершенствованию процессов и инструментов (ПСПИ), пилотные проекгы
и обычные проекты по разработке программного обеспечения. Объем организаци-
онных изменений, ваша готовность к риску и объем настроек RUP и сопровож-
дающих инструментов - все это может оказать существенное влияние на програм-
му по внедрению RUP.
Чтобы получить значительное повышение результативности проекта, процесс
нужно автоматизировать. Итеративная разработка требует, помимо всего прочего,
инструментальной поддержки Управления конфигурациями и изменениями,
автоматизированного тестирования и Управления требованиями, которые обес
печивают экономическую эффективность. Другие аспекты RUP требуют наличия
других инструментальных средств. Если автоматизацию не рассматривать как
часть совершенствования процесса, это, скорее всего даст, разочаровывающие
результаты.
Совершенствование процесса и инструментов должно осуществляться постоян-
но. Это даст вам возможность непрерывно настраивать процесс с учетом разви-
вающихся требований.
A t
ГЛАВА 12
Планирование итеративного проекта
Мотивировка
Планировать итеративный проект и легче, и сложнее, чем каскадный.
• Это труднее и требует гораздо больше работы, поскольку планирование боле,
динамичное и непрерывное.
• Это легче, поскольку оно гораздо точнее соответствует целям проекта. Ни
гервал планирования краткосрочный, и есть масса возможностей корректоре
вать планы.
/ [панирование в RUP
больше концентрирует-
ся на разбиении процес-
са, то есть на том, что
нужно сделать, чтобы
достигнуть к определен-
ному моменту опреде-
ленных целей.
в
Традиционное планирование технических проектов слпш
ком часто строится по принципу «сверху вниз» и основыин
ется на разбиении продукта, то есть на разбиении систем и
на компоненты и различные артефакты (спецификации, с.хг
мы, подсистемы и т. п.) - стиль планирования, унаследован
ный от промышленности и строительства. Хотя в некоторои
степени план должен учитывать артефакты и структур»
продукта, в разработке программного обеспечения это часп>
делается слишком рано, в тот момент, когда еще мало извес i
но о продукте.
RUP больше концентрируется на разбиении процесса - ш
нужно сделать, чтобы достигнуть к определенному моменц
Планирование
есть на том, что
определенных целей. Именно здесь можно видеть в действии концепции ф.н
и итераций, а также сопровождающих их больших и малых вех. Здесь исполь
зуются задачи и детали рабочих процессов. При планировании в RUP испольп
ется как подход «сверху вниз», так и подход «снизу-вверх». Подход «сверху вин ।
Планирование итеративного проекта
245
па ранних стадиях (фазы Начало и Проектирование) дополняется подходом
«снизу вверх» на поздних (фазы Построение и Внедрение)1. При подходе «сверху
вниз» используются определенные артефакты и архитектурная база. Однако на
практике подход к планированию не столь черно-белый, и в цикле разработки
осуществляется постепенный переход.
Такой динамический и итеративный подход к планированию позволяет лучше
достигнуть равновесия между целями (что вы хотите получить в конце проекта)
и обязанностями (что команда должна сделать, чтобы получить это). Этот подход
является адаптивным и направляемым рисками, а также тем, что уже удалось
узнать как о продукте, так и о процессе его разработки.
Ключевые концепции
Рассмотрим еще раз ключевые концепции.
которые выпол-
Мы часто отделяем
циклы первоначаль-
ной разработки от цик-
лов развития или цик-
лов поддержки
Цикл
Цикл разработки - это период времени от самого начала проекта до выпуска
продукта (или отказа от проекта). В него входят все задачи,
ияются за это время.
Не все циклы имеют одинаковый вид. Значение фаз и число
итераций, необходимых для достижения целей фаз, могут
сильно варьироваться. Мы часто отделяем циклы первоначаль-
ной разработки от циклов развития или циклов поддержки.
Первоначальный цикл разработки, который приводит к созда-
нию самого первого выпуска системы, часто называется «зеле-
ной разработкой». На рис. 12.1 показано типичное развитие во времени перво-
начального цикла разработки.
Нач I Пр Постр Вн
10% 30% 50% 10%
Время
Рис. 12.1. Типичное развитие во времени первоначального цикла разработки. Длительность каждой
фазы значительно отличается от проекта к проекту.
1. См. Royce 1998. Глава 10. - Примеч. авт.
246
Глава 1?
Фазы
Каждый цикл RUP разделяется на последовательность из четырех фаз, назы
васмых Начало (Inception), Проектирование (Elaboration), Построение (Construe
lion) и Внедрение (Transition). Помните, что эти фазы присутствуют всегда и и\
значение определяется не тем, что выполняется, и не их длительностью, а тем
какие цели достигаются к моменту главной вехи, которая завершает фазу.
Итерация
Внутри каждой фазы может быть одна или несколько итераций. Программное
обеспечение разрабатывается в каждой итерации, которая завершается малой2 вс
хой, включающей в себя релиз (внешний или внутренний), являющийся точкой
оценки прогресса проекта. Программный продукт растет постепенно по мере вы
полнения задач в итерациях.
Выпуск
В каждой итерации различные разработчики или команды разработчиков мо
гут создавать выпуски (build) (иногда довольно часто - ежедневно или даже
несколько раз в день), что способствует непрерывной интеграции, тестированию,
регрессионному тестированию и показывает общий прогресс. Часто последнип
выпуск итерации является частью релиза этой итерации.
Ограничение времени
Ограничение времени (time boxing) - это метод используемый в подходе
«сверху вниз», при котором делается попытка ограничить достижение определен
ной цели небольшим временным интервалом. Это позволяет сконцентрироваться
на наиболее важных целях и заставляет достигать компромиссов3. При этом нс
ставятся невозможные или нерациональные цели и не форсируется создание низ
кокачественных продуктов. Это средство, используемое для достижения равновс
сия между границами проекта и сроками, а также для достижения сходимости
процесса и ограничения возможностей для впадения в аналитический паралич
и излишнее шлифование.
2. Minor milestone переводится также как вспомогательная контрольная точка. - Примеч. науч. ред.
3. См. Highsmith 2000. стр. 303. - Примеч. авт.
Планирование итеративного проекта
247
Общие и детальные планы: планы проекта и планы итераций
Поскольку итеративный процесс является в высокой степени динамичным
и адаптивным и подразумевает подгонку изменений под цели и тактические
решения, будет бессмысленно тратить много времени на создание подробных
планов, выходящих за рамки текущего круга задач. Такие планы трудно под
держивать, они быстро устаревают и, скорее всего, будут отброшены через не-
сколько недель. В таких планах, как правило, делаются попытки предсказывай,
будущее, а вместо крупных вех может использоваться масса мелких. Более того,
разработка программного обеспечения — это задача творческая, а не только
промышленная или административная с более или менее фиксированным
рабочим процессом. Поэтому весьма трудно будет принять план до того, как вы
наделе выясните, что вы хотите планировать.
При использовании итеративного процесса рекомендуется применять два вида
планов.
• Общий план, план проекта с акцентом на фазах и итерациях, их целях и об-
щее кадровое обеспечение.
• Серия детальных планов, планы итераций, по одному на каждую, которые
вводят в рассмотрение задачи RUP и конкретные ресурсы.
План проекта
Старших менеджеров и ключевых заинтересованных лиц редко интересуют
подробности того, кто что и когда делает. Они заинтересованы в конечном
продукте. Следовательно, их в первую очередь заботит да<а релиза, даты всех
вех, во время которых принимаются крупные решения, и на какой стадии они
смогут увидеть продвижение, границы, трудности и ресурсы проекта.
План проекта - это общий (coarse grained) план, и для
одного проекта по разработке программного обеспечения
существует только один такой план. Он выполняет роль все-
объемлющего «конверта» для проекта на один цикл (и, если
нужно, для последующих циклов). В план проекта входит
следующее.
План проекта - это об-
щий план, И ДЛЯ ОДНО! о
проекта по разработка'
программного обес-
печения существует
только один такой план.
• Даты главных вех:
- Веха целей жизненного цикла, ЦЖЦ (Lifecycle Objective Milestone). Конец
фазы Начало. Четко определены границы и финансирование проекта.
248
Глава l?
- Веха архитектуры жизненного цикла, АЖЦ (Lifecycle Architecture Mill-
stone). Конец фазы Проектирование. Завершена архитектура, заложен.i
основа набора требований.
- Веха начальной функциональной готовности, НФГ (Initial Operation.il
Capability Milestone). Конец фазы Построение. Первый бета-релиз.
- Веха готового продукта, ГП (Product Release Milestone). Конец фалл
Внедрение и всего цикла разработки.
• Кадровый состав. Какие ресурсы и когда потребуются.
• Даты вспомогательных вех. Окончания итераций (включают также первичш.п
цели итераций, если таковые известны).
План проекта (обычно одна-две страницы) создается в самом начале фа чы
Начало и обновляется столько раз, сколько это необходимо. Для определенна
границ и исходных посылок проекта план ссылается на документ «Концепция
Данный план проекта является разделом более общего Плана разрабопчи
программного обеспечения (Software Development Plan) (см. раздел 4.2 в шаблон.
RUP).
План итерации
План итерации - это де-
льный план с фиксиро-
ванным временем выполне-
ния. На одну итерацию при-
ходится один такой план.
План итерации - это детальный план с фиксированным
временем выполнения. На одну итерацию приходию
один такой план. Поскольку данный план концентрирую
ся только на одной итерации, и соответствующий см\
промежуток времени достаточно мал, он дает членам ьо
манды возможность обдумать и осуществить ту форм\
подробного планирования, с которой они уже знакомы, - планирование с трсби
мым уровнем детализации задач и их распределением по членам команды.
В проекте в любой данный момент обычно «активны» два плана итераций:
• план текущей итерации, используемый для отслеживания продвижения;
• план следующей итерации, который создается со второй половины текущсп
итерации и готов к ее концу.
Пока команда выполняет план текущей итерации, менеджер проекта nniuci
план следующей. Менеджер проекта должен быть достаточно дальновидным
и уметь быстро изменять этот второй план в ходе текущего цикла, чтобы комани
могла иметь жизнеспособный план следующей итерации, даже если получеп1ыи
позже информация заставила вносить некоторые изменения. Если что-то
Планирование итеративного проекта
249
наруживается в поздние сроки, менеджер проекта должен среагировать таким
образом, чтобы команде не пришлось остаться на начальной стадии из-за за-
держки планирования.
План итерации строится с помощью традиционных методов и средств пла-
нирования (диаграмм Гантта и пр.). В нем определяются задачи, и он помогает
распределять их между отдельными людьми и группами. В плане содержатся не-
которые важные даты, в частности даты крупных выпусков, даты поступления
компонентов от других организаций и даты наиболее важных рецензий. В нем
определяются критерии объективного успеха итерации. План составлен из задач
RUP или иногда наборов задач, таких как детали рабочего процесса. Поскольку
задачи однозначно связаны с ролью, а в компетенцию конкретных людей может
входить выполнение определенной роли, план будет привязан к людским
ресурсам. В простых проектах можно использовать просто список того, что нуж-
но сделать.
План итерации можно изобразить в виде увеличительного окна, движущегося
но плану проекта (или плану фазы) (рис. 12.2).
План итерации - это отдельный артефакт RUP, и он не поддерживается после
итерации.
Создание плана проекта
Чтобы создать план проекта, потребуется провести первоначальную оценку
общего объема проекта (рис. 12.3). (см. ниже раздел «Оценка»), Получив перво-
начальное представление об объеме, вы можете правильно прикинуть кадровый
состав с помощью общеизвестных методов (например, модели СОСОМО4).
Большинство проектов не будет функционировать эффективно при постоян-
ном числе занятых людей. Обычно есть кривая кадрового состава, которая подни-
мается от фазы Начало к фазе Построение, выходит на некоторое время на плато,
А затем к концу фазы Внедрение несколько опускается.
Как и со многими прочими аспектами RUP, рассматривайте эту кривую лишь
Как пример. Ее необходимо подкорректировать в соответствии с вашим опытом
И вашей ситуацией. Например:
4. Конструктивная модель стоимости (Constructive Cost Model - СОСОМО), разработана в конце 70-х годов
' Берри Боэмом. Устанавливает соответствие между размером системы в тысячах условных строк кода и «классом»
Проекта, с одной стороны, и трудоемкостью разработки системы - с другой. - Примеч. науч. ред.
250
Глава i?
Детальный план: план итерации
Рис. 12.2. План проекта и план итерации. План проекта - эго общий план, выполняющий роль «и«
верта» проекта на один цикл. План итерации-это подробный план с фиксированным q".
ком выполнения на одну итерацию, (см. Kruchten 2000а)
• при наличии многих неизвестных факторов и рисков и при введении в проч i
новых людей и технологий фаза Проектирование может продолжаться дольше
• в эволюционных циклах фазы Начало и Проектирование можно сократить.
После того как вы запланируете по календарю даты основных вех, встанх >
следующие вопросы: сколько нужно итераций и какой они будут длительное i п
Мнения практиков итеративной разработки здесь очень расходятся. Во-перны-
помните, что нельзя путать выпуск (например, еженедельный) с итерацией. Мп"
гие скупые фанаты итеративной разработки считают, что итерация длится от двх
до пяти недель. Это подходит для большинства небольших и средних проеккщ
по не для больших и очень больших, где нужно координировать работу соп и
людей, подчас распределенных по разным местам.
Планирование итеративного проекта
251
Ресурсы
Начало Проектирование Построение
Время
Рис. 12.3. I 'ипичное распределение ресурсов в цикле разработки. Количество ресурсов, используе-
мых в каждой фазе, сильно различается от проекта к проекту. Э тот график даст вам отпра-
вную точку для обсуждения потребностей в ресурсах (см. Kruchten 2000а и Royce 1998)
Скорость прохождения итераций в первую очередь зависит от размеров
разрабатывающей программное обеспечение организации.
• 5 человек, 1 неделя. Команда из пяти человек может провести часть планиро-
вания утром в понедельник, затем ежедневно встречаться за обедом, отслежи-
вать прогресс, перераспределять задания, утром в четверг начать готовить вы
пуск и завершить итерацию вечером в пятницу. Итерация займет одну неделю
• 20 человек, от 3 до 4 недель. Если в проекте задействовано 20 человек, вылол
нить работу за одну неделю сложно. Требуется больше времени на распределе
ние заданий, синхронизацию работы подгрупп, на интегрирование и т.п. Поло
му итерация займет 3-4 недели.
• 40 человек, 8 недель. Когда в проекте участвуют 40 человек, потребуется уже
неделя только на то, чтобы заработали все «синапсы» между «мозгом»
и «конечностями» организации. Имеются промежуточные уровни управления,
общее понимание целей требует наличия более формализованной документа
ции, большего числа формальностей. Наиболее реалистичная продолжится!,
ность итерации - восемь недель.
252
Глава 12
i 'м/юсть прохождения
пираний в первую
। '/< редь зависит от раз-
л» ров разрабатывающей
npo/раммное обеспече-
ние организации.
Имеют значение и некоторые другие факторы: уровень зна
комства организации с итеративной разработкой, включая
стабильность и зрелость организационной структуры:
уровень автоматизации, применяемой для управления кодом
(например, распределенные системы управления конфи
гурациями); доступность информации (например, внутреп
ний Web сайт); автоматизация тестирования и т.п.
• Все продукты от Rational создаются с использованием синхронизированных рели
зов, при участии 700 человек и в итерациях, продолжительностью до 8 недель.
• Крег Лерман (Craig Larman) из компании Valtech приводит информацию о про
ектах, использующих 10 и более итераций и занимающих чуть больше года.
Также помните о том, что в итерации присутствуют некоторые фиксированные
юполпительные затраты: при планировании, синхронизации, анализе резулыа
юн и т.д.
Гак что, когда вы, убедившись в огромных преимуществах итеративнон
разработки, начнете радостно проскакивать одну итерацию за другой, ваш пы i
।>ыс । ро охладят ограничения в людских ресурсах.
• 11ри итерациях, занимающих менее 1 месяца, необходимо очень тщательно
подумать о границах. Как правило, короткие итерации наиболее подходя!
для фазы Построение, когда количество новых включаемых функций и ст с
пень новизны невелики. Короткие итерации могут включать лишь небольшоп
обьем формального анализа и проектирования или не включать его вообще
Может просто выполняться последовательное совершенствование имеющихся
хорошо понятных функций.
• /(ля итераций продолжительностью более 3-х месяцев могут потребоваться
промежуточные вехи, создаваемые для того, чтобы удерживать проект па
правильном курсе. Подумайте о сужении границ итерации для уменьшения о
продолжительности и определения четкой цели.
• Итерации продолжительностью более 12 месяцев в многолетних проекте
создают дополнительные бизиес-риски, поскольку итерация охватывает вес i.
годовой цикл финансирования. Проект, в котором не будет создано ничего ни
днмого в течение 12 месяцев, рискует лишиться финансирования. Вы не но
лучите от итеративной разработки ничего полезного. Продумайте стратегии>
еще раз.
Не требуется, чтобы все итерации были одинаковой продолжительное i и
11.\ длина варьируется в зависимости от их целей. Как правило, итерации Прося
шрования будут длиннее, чем итерации Построения. Внутри одной фа .и
Планирование итеративного проекта
253
итерации, как правило, имеют одинаковую длину (это облегчает планирование),
а постоянная скорость выполнения проекта со многими итерациями создает
среду, благоприятную для сбалансированных жизненных циклов.
Определение количества итераций
С продолжительностью итераций связан деликатный вопрос количества
итераций.
В очень простом проекте в одной фазе может быть всего одна итерация:
• Начало: 1 итерация, в которой может быть создан прототип, под-
тверждающий концепцию, или экспериментальная модель пользовательского
интерфейса, или же этой итерации нет вообще, например, в случае эволюци-
онного цикла.
• Проектирование: 1 итерация, в которой создается архитектурный прототип.
• Построение: 1 итерация, в которой создается продукт (в виде бета-релиза).
• Внедрение: 1 итерация, в которой продукт завершается (окончательный релиз).
Для более основательного проекта при первоначальном цикле разработки
нормой будет следующее количество итераций:
• Начало: 1 итерация, в которой может быть создан прототип.
• Проектирование: 2 итерации, одна для разработки первоначального архитек-
турного прототипа, вторая - для завершения создания архитектурной основы.
• Построение: 2 итерации, одна для создания частичной реализации системы,
вторая для доведения ее до бета-тестирования.
• Внедрение: 1 итерация, для перехода от бета-релиза к конечному продукту.
В большом проекте при наличии многих неизвестных факторов, новых техно-
логий и т.п., может найтись повод для дополнительных итераций:
• Начало: дополнительная итерация, позволяющая посвятить больше времени
прототипу (итого 2 итерации).
• Проектирование: дополнительная итерация, позволяющая изучить различные
технологии или ввести в действие архитектурные решения, (всего в фазе будет
3 итерации).
• Построение: дополнительная итерация, исключительно из-за размеров продукта,
(итого 3 итерации).
• Внедрение: дополнительная итерация, позволяющая в середине работы по-
лучить обратную связь.
254
Глава 12
Вследствие этого в цикле разработки (см. таблицу 12.1) возможна различная
с гепень итеративности.
Лучше планируйте от 3 до 10 итераций. Однако помните, что верхняя
и нижняя границы связаны с необычными обстоятельствами. В большинстве
проектов используются 6—8 итераций.
Table 12.1 Степень итеративности в разных проектах. Данную таблицу можно взять
в качестве отправной точки при принятии решения о том, сколько итераций
использовать. Количество итераций и их длительность зависит от многих
рашообразных факторов
Размер ; проекта > (число людей) Длительность проекта (месяцы) Длительность ; итераций ; (недели) Начало Число итераций в фазах Проектирование Построение Внедрение i I
3 i 4 2-3 1 1 i 3 1
10 8 4 1 1 ; 2 j 3 2
80 ! 1. 20 7-8 2 ! 3 j 4 : L. ... i 2
В зависимости от рисков проекта, его размеров и сложности возможно очсш.
много вариантов:
• если продукт относится к совершенно новой области, может потребоватся до
бавить несколько итераций к фазе Начало, чтобы дать устояться концепции
предъявить различные экспериментальные модели представительной выборке
заказчиков и пользователей или дать обоснованный ответ на запрос или требо
вание;
• если нужно разработать новую архитектуру или необходимо много моде-
лировать прецеденты использования, или присутствуют очень серьезные
риски, нужно запланировать 2-3 итерации Проектирования.
• если продукт крупный и сложный и его нужно разрабатывать в течение при
должительного времени, нужно запланировать 3 и более итераций фазы
Построение;
• если вы чувствуете, что может потребоваться масса мелких настроек под пользе
вателей после некоторого периода применения продукта, нужно запланировать нс
сколько итераций фазы Внедрение;
Планирование итеративного проекта
255
• простой эволюционный цикл или цикл поддержки можно выполнить за не-
сколько итераций: итерации фаз Начало и Проектирование отсутствуют, есть 1
итерация Построения и 1 итерация Внедрения;
• организация, которой никогда не приходилось заниматься итеративной разработ-
кой, может начать с небольшого числа итераций, например с трех.
В качестве альтернативы вы можете определить длительность итерации, ко-
торая наиболее удобна для вашей организации, и работать, взяв для каждой фазы
столько итераций этой длины, сколько сможете. Очевидно, что так легче, но нуж-
но проделать это заранее в своей организации или в организации со сходными
размерами и опытом, чтобы иметь уверенность относительно продолжительно-
сти итерации. Помните, не существует одного, подходящего на всех размера. Не
занимайтесь излишней оптимизацией. Сделайте первую пробу и вносите измене-
ния по мере накопления опыта.
Продолжительность итераций
В первом приближении вычислите продолжительность итерации, разделив
длительность фазы на число итераций. Если полученная длительность итерации
будет не совсем соответствовать эмпирическим правилам, описанным выше,
пересмотрите процесс. Теперь пора выполнить небольшую подгонку либо по
длительности фазы, либо по числу итераций. Потом примите во внимание празд-
ничные дни, запланированные отпуска или закрытие предприятия и подгоните
план проекта к реальному временному распорядку. Например, совсем плохо пла-
нировать крупные вехи на промежуток между рождественскими и новогодними
праздниками.
Необязательно делать верный на 100% план за один день, поскольку этот план
будет несколько раз пересматриваться на протяжении цикла разработки. Начните
с чего-то реального, сделайте основу плана проекта и пересматривайте его
в конце каждой итерации.
Цели итерации
Получив представление в общем плане о числе итераций, нужно определить
содержание каждой итерации. Лучше придумать какое-нибудь название, или
заголовок, которое определит то, что будет получено в конце каждой итерации,
и поможет людям лучше сконцентрироваться на следующей цели.
Пример: названия итераций для частного телефонного коммутатора
Итерация 1. Локальный вызов от станции к станции
256
Глава I?
Итерация 2. Добавление внешних вызовов и управления абонентами
Итерация 3. Добавление голосовой почты и конференций ...и т.д.
И опять же, не тратьте на это слишком много сил. В ходе цикла разработки вы
будете пересматривать это несколько раз. Планирование - итеративно и адаптивно
Кадровое обеспечение проекта
Следующий шаг - выделить на проект верный объем людских ресурсов и.,
всем протяжении жизненного цикла. На рис. 12.4 показана типичная диаграмм.,
кадрового обеспечения.
Реальная схема кадрового обеспечения будет варьироваться в зависимости о,
проекта.
• В цикле первоначальной разработки, т.е при «зеленой» разработке, не нужно
начинать проект, задействовав очень много людей в фазах Начало и Проел
тирование. Поскольку ничего еще не подготовлено, вы просто будете искан,
для всех занятие. Пятьдесят человек не создадут документ «Концепция .
Кадровое обеспечение достигает пика в фазе Построение.
• В эволюционном цикле или цикле поддержки кривая кадрового обеспеченнч
будет более ровной. В проекте могут быть постоянно заняты одни и те же ня,
человек, и проделываемая работа будет выглядеть как фаза Внедрение или 11<>
строение и Внедрение.
Модели, такие как СОСОМО, помогут вам определить для различных фаз он
гимальное число людей по продолжительности фазы, принимая во внимание ра,
личные параметры (факторы затрат5).
Для распределения задач по конкретным исполнителям вам потребуемч
правильно сочетать области компетенции. Этого можно добиться, сие п
в таблицу всех членов команды и роли в RUP, которые они могли бы выполнять
Планирование итерации
Разработка плана итерации состоит из четырех шагов:
I. Определение границ итерации. Определите свои цели: чего вы холин
добиться в итерации?
!> Факторы затрат (cost drivers) - это событие или деятельность, влекущие за собой затраты. - Примеч. пер.
Планирование итеративного проекта
257
I1 Ресурсы
10%
Построение Внедрение
Время
Легенда
| э% [ 20%
10% __________30%.
Начало Проектирование
Длительность
(% от длительности проекта)
Рис. 12.4. Пример схемы распределения людских ресурсов по фазам жизненного цикла проекта.
Затраты на каждую фазу значительно варьируются от проекта к проекту.
2. Определение критериев оценки итерации. Определите, как вы будете объ-
ективно оценивать завершение итерации. Укажите, какие артефакты будут
разрабатываться.
3. Определение задач для итерации. Укажите, что и с какими артефактами
нужно сделать.
4. Распределение ответственности. Распределите выполнение задач
по имеющимся людским ресурсам.
Выполнение первых трех шагов значительно изменяется в ходе жизненного
цикла.
Начало и Проектирование
В начале работы над проектом, особенно «зеленым» проектом, у вас еще не
определены проектные элементы и нет элементов, специфичных для данной но-
вой системы, на которых можно было бы строить обоснования для планирования
итерации. В качестве основы для своих планировочных построений используйте
подход «сверху вниз» и грубые оценки, полученные на основе опыта других
проектов. Вам, возможно, уже приходилось делать это для плана проекта.
Ч R63
258
Глава 1?
/’искиопределят, какие
прецеденты использо-
вания, сценарии, ал-
/оритмы и т.п.
< яанугразрабатываться
и ходе итерации.
Однако, если вы имеете дело с эволюционным циклом суще
ствующего программного продукта («коричневый» проскн
фазы Начало и Проектирование, скорее всего, он буд\ i
короче: вам придется бороться с меньшим числом рисков
и планирование итераций будет во многом похоже
на описание раздела, «Построение и Внедрение».
Цели итерации будут в первую очередь определяться рисками. Именно риски
в свою очередь определят, какие прецеденты использования, сценарии, алгорш
мы и т.п. станут разрабатываться в ходе итерации, а также способы оценки
•ффективности борьбы с рисками.
Построение и Внедрение
Теперь у вас есть готовая архитектура и кое-какие измерения, сделанные
в предыдущих итерациях, как для артефактов (количество строк кода, число
юфектов и т.п.), так и для процесса (время выполнения определенных задач)
Надеемся, вы справились и с большей частью рисков. Всю эту информацию вы
можете использовать для совершенствования способов планирования итераций.
Можно продолжить работу, используя основанное на артефактах планирова
пне по принципу «снизу-вверх», применяя такие проектные элементы, как класс
компонент, подсистема, прецедент использования, прецедент тестирования и т.п
л также все способы проведения измерений из предыдущих итераций для оценки
работы. Предупреждаем: при использовании подхода «снизу вверх», как права
ио, нужно пессимистично относиться к срокам, особенно при суммировании ин
дннидуальных оценок десятков людей. Также известно, что разработчики-но
пнчки имеют склонность переоценивать свои возможности.
//< 'пи и терации будут
I чтределяться в первую
I "/< '/юдь выполнением по-
< 7, тленных задач и дос-
прением определенного
цюння качества.
Цели итерации будут определяться в первую очередь вы
полнением поставленных задач и достижением определен
ного уровня качества. Сюда также входит исправлсшв
конкретных дефектов, в первую очередь тех которые
препятствуют использованию наиболее существенных
функций или вызывают сбои в системе, а всякие излишесны
можно оставить на будущее.
Определение задач
Используйте прецедент разработки как справочную таблицу по задачам, ко
юрые необходимо выполнить в итерации. Если вы считаете, что задачи слишком
мелкие, можете заменять их деталями рабочего процесса (workflow details), осо
оспно на ранних стадиях.
Планирование итеративного проекта
259
Есть некоторые задачи, которые нужно выполнить только один раз
за итерацию (или за фазу, или даже за цикл). Например, такие задачи RUP как
1 (лакирование итерации (Plan an Iteration) или Рецензирование вехи жизненного
цикла (Lifecycle Milestone Review).
Но есть также и другие задачи, которые нужно повторять для каждого элемен-
та, и этот элемент обычно и является основным выходом данной задачи.
Например, задача Написать код класса (Code a Class) должна выполняться для ка-
ждого класса, задача Интегрировать подсистему (Integrate Subsystem) - для каж-
дой подсистемы, а задача Описать прецедент использования (Describe Use Case) -
для каждого прецедента использования.
Поэтому в самых первых итерациях нового проекта, когда проектные элемен-
ты еще не определены, вы сможете дать для этой задачи лишь общую приблизи-
тельную схему. Например:
• написать код классов (всех): 10 человекодней или просто указать артефакт
более высокого уровня;
• разработать прототип-подтверждение концепции: 42 человеко-дня.
В более поздних итерациях, когда проектные элементы определены, задачу
можно связать с этими элементами и более точной оценкой. Например:
• написать код класса Покупатель: 2 человекодня;
• написать код класса Счет: 1 человекодень.
Оценка
Еще один ключевой компонент, который мы пока не рассматривали, - это
вопрос оценки. Насколько велик проект? Сколько для него требуется человек?
На данный момент наилучшим инструментом, ко-
торый может использовать менеджер проекта для оцен-
ки проекта, фазы, итерации или простой задачи,
являются исторические сведения. Самый фундамен-
тальный подход - записать оценки затрат, продолжи-
тельности или размеров, а также методы оценки и все
использованные предположения, а затем зафиксировать
конкретные результаты по каждой оцениваемой задаче. Сравнение реальных и ожи-
даемых результатов поможет более точно проводить оценку в будущем. Процедуры
оценки и шаблоны, в которых по пунктам перечисляются задачи, помогут избежать
обычной проблемы, когда пропускается какая-нибудь необходимая работа. RUP
представляет собой как раз такой арсенал задач.
На данный момент наилучшим
инструментом, который может
использовать менеджер проекта
для оценки проекта, фазы,
итерации или простой задачи,
являются исторические сведения.
9*
260
Глава 12
Существуют средства оценки, такие как СОСОМО, однако они не скажут вам.
каких затрат потребует новый проект. Они лишь помогут оценить продолжитель-
ность проекта и необходимое количество людей, настроив поправочные коэффи-
циенты, проинтегрировав производительность вашей команды и оценив слож-
ность проекта. На ранних этапах фазы Начало нужно проводить калибровку пла
на проекта относительно другого проекта, для которого вам уже известны общие
пираты. Затем с помощью такой модели, как СОСОМО, можно будет провести
оценку продолжительности и уровня кадрового обеспечения. Помните, что
разработчики программного обеспечения, как известно, не взаимозаменяемы.
' )io несколько осложняет планирование проектов по разработке программ.
Когда работа над проектом запущена, вам может понадобится совмещать под-
ходы «сверху вниз» и «снизу вверх» и применять не только свои собственные
растущие знания, но также и знания своего персонала. Скорее всего, они уже
начали работу по созданию ранних прототипов и используют свои знания ин
С1рументов, вследствие чего могут дать более точные оценки. В следующем раз-
деле рассказывается о простом, но эффективном подходе - использовании всего
лучшего, что могут дать ваши люди и уже имеющиеся у вас данные.
К более изощренным методам относится использование метода функциональ-
ных точек (function-points method) и его разнообразных производных. В качестве
отравной точки для применения таких методов и оценки «высоты горы» можно
использовать прецеденты использования6.
Техника итеративной оценки: широкополосная модификация
дельфийского метода
Этот метод был предложен в 70-х годах Барри Боэмом7 (Barry Boehm), он име-
сг несколько вариантов. Часто его называют «широкополосной модификацией
дельфийского метода». Идея в том, чтобы собрать для решения одной проблемы
имеете несколько «голов» и постаратся достичь согласия. Когда в качестве этих
«голов» выступает реальная команда разработчиков, они скорее достигнут своей
цели, чем некоторое случайное число людей сверху.
I. Менеджер проекта определяет предмет оценки, единицы измерения
и допущения. Потом собирает информацию о сходных задачах и проектах,
если таковые имеются (например, данные предыдущих итераций или преды-
дущих проектов). Выбираются участники.
G См. Albrecht 1979. - Примеч. авт.
/ см. Boehm 1981,- Примеч. авт.
Планирование итеративного проекта
261
2. Всем участникам выдается информация о процедуре и целях и все доступные
данные.
3. Участники формируют свои собственные оценки (каждый сам по себе), жела-
• тельно, непересекающиеся.
... 4. Менеджер проекта собирает все данные, сводит их в таблицу и сравнивает.
5. Все участники собираются снова. Там, где цифры совпадают, оценка призна-
ется вероятной. Если наблюдается большой разброс, имеет смысл провести
обсуждение, где участники обоснуют более высокие и более низкие оценки.
На чем основывалась их оценка? Когда одни участники объясняют свои
; предположения, другие члены команды могут так или иначе реагировать на
это: был забыт такой-то важный параметр, проявился такой-то риск и т.п.
6. Участникам дается возможность подправить свою оценку с учетом обсуждения.
7. Эти новые числа становятся рабочей оценкой.
На протяжении итерации или фазы производится сбор реальных данных по
этим задачам, которые используются при следующей оценке. При следующем за-
ходе (например, в следующей итерации), когда приходит время провести оценку,
участникам раздаются предыдущие оценки и реальные цифры, что поможет им
подкорректировать свой естественный оптимизм или пессимизм.
Как можно догадаться, существует масса вариантов и улучшений. Можно по-
вторять (итерировать) шаги 5 и 6 (хотя это часто и не является необходимым).
Можно избрать неформальный путь и использовать электронную почту или
| просто походить по комнатам с блокнотом и обсудить гипотезы по планированию
с теми людьми, чья оценка наиболее отличалась от прочих. Можно подойти к это-
) му формально, использовать шаблоны и средства обсчета диапазонов и неопреде-
i ленностей, даже применить моделирование методом Монте-Карло для получения
i распределения вероятностей возможных оценок на основе значений окончатель-
] ных оценок, (подробнее см. Wiegers 2000).
Оптимизация плана проекта
В добавление к только что описанной базовой методике планирования
итеративного проекта смелый менеджер может попытатся оптимизировать план
проекта.
262 Глава 1?
Перекрывающиеся итерации
Две последовательные итерации могут перекрываться между собоп
и. наверное, это полезно (все были заняты делом). Планирование следующем
шерации не нужно откладывать до тех пор, пока вы дойдете до полной останов
кл. Не теряйте из виду и тот факт, что, чтобы извлечь пользу из преимущесш
шсративной разработки, к моменту итерации N+1 вы должны иметь опьн
приобретенный в итерации N. Слишком большое перекрытие нарушит это,
вс 1 роенный механизм совершенствования требований, целей и процесса.
Параллельные итерации
Когда продукт имеет много частей или если он разрабатывается распределен
ной командой, может возникнуть искушение заставить каждую команду или
подрядчика самому планировать свою работу. Это будет правильно, если рабочие
модули достаточно независимы. Если же это не так, то лучше, чтобы все орисп
। провались на «общие часы», а в конце каждой итерации проводилась ни
iciрация разных подсистем. В некоторых случаях команда к концу итерации мп
жс1 и не создавать ничего нового, если того, что они создали в прошлом
шсрации, достаточно для продолжения работы других групп.
Например, группа может отвечать за инфраструктурный код, а инфраструк
i\ ра достаточно зрелая, ее интерфейс стабильный. Команде может в таком случае
и ис понадобится выпускать в каждой итерации новую инфраструктуру.
Помните, что ограничивающим фактором будет наиболее медленно рабе
ыющая команда или группа. Она станет замедлять работу всех остальных
и другие команды должны будут подлаживаться под ее график.
Заключение
В заключение этой главы приведем совет нашего коллеги Уокера Ройса (Walkci
Ro> се)8:
Планы нужны не только менеджерам. Чем более открытым и явным будш
процесс планирования, тем больше будет чувство причастности утех членов
команды, которым приходится выполнять планы. Плохие, закрытые планы из
иуриют. Хорошие, открытые планы могут формировать культуру и поощрять со
нмсс гную работу.
и См. Royce 1998 - Примечание авторов.
п
*»1Н**'
ГЛАВА 13
Распространенные ошибки при
внедрении и использовании RUP,
и как их избежать
В этой главе мы укажем нанекоторые наиболее распространенные ошибки,
которые команда может допустить при внедрении и использовании RUP, и рас-
смотрим, как их избежать. Список ошибок основывается на наблюдениях, которые
мы и специалисты по эксплуатации компании Rational сделали в ходе работы с ты-
сячами заказчиков в течение многих лет. Мы делим ошибки на три группы.
• Ошибки при внедрении RUP.
• Ошибки при управлении итеративной разработкой.
• Ошибки при проведении анализа, построении архитектуры, осуществлении
проектирования, реализации и тестирования.
Ошибки при внедрении RUP
Целью применения такого подхода, как RUP, является помощь в создании
работающего программного обеспечения, содержащего меньше дефектов, в мак-
симально короткие сроки. Применение RUP потенциально может иметь для
внедряющей его организации далеко идущие последствия. Эти последствия
могут быть как технические (внедрение новых инструментов автоматизации
определенных аспектов процесса), так и социальные (введение новой практики
264
Глава lл
раоогы и новой культуры). Поэтому внедрение RUP нужно рассматривать как
проект или программу. Ниже приводятся некоторые распространенные ошибки
ынорые мы обнаружили в организациях, внедряющих у себя RUP.
• Внедрение слишком многого из того, что есть в RUP может замедлить раб<>
iy, снизить гибкость и повысить стоимость разработки.
• Внедрение всего сразу, в отличие от постепенного внедрении, может слиш
ком перегрузить участников проекта и, скорее всего, привести к неудаче вис
дрспия RUP.
• Отсутствие планирования при внедрении RUP может, помимо всего прочею
привести к тому, что заинтересованные лица не дадут добро, финансирование
будет недостаточным и не хватит ресурсов для обучения и наставничества.
• Отсутствие связи между совершенствованием процесса и экономическими
результатами затрудняет получение одобрения от заинтересованных лиц и мо
же г вызвать неудачу внедрения RUP и отсутствие ожидаемых результатов.
• Излишне детальная и слишком ранняя настройка RUP ведет к появлению
излишне разработанного процесса или трате времени на бесполезные на
стройки из-за отсутствия понимания действительно необходимого процесса
настройки.
• Пустословие о RUP может заставить заинтересованных лиц считать, что вы
уже внедрили RUP, в то время как это было сделано лишь поверхностно
Вы можете утратить доверие, а в неудаче будут обвинять RUP, хотя в дсйстви
щльности вина лежит на процессе, который ему предшествовал.
• Отсутствие управления внедрением RUP как проектом или программой,
состоящей из серии проектов, г.е. внедрение RUP без измерения и оценки
успеха этого внедрения, без внесения изменений и без тонкой подгонки сю
в ходе эксплуатации.
Рассмотрим некоторые способы, позволяющие избежать этих ошибок.
Внедрение слишком многого из того, что есть в RUP
i аман распространенная
11И1и('жа, которую совершают
люди при внедрении RUP -
. но использование слишком
о ЧЦ.ПЮГО числа артефактов
инн выполнение слишком
I к >лмного числа задач,
имеющихся в RUP.
Вероятно, самая распространенная ошибка, которую со-
вершают люди при внедрении RUP, - это использование
слишком большого числа артефактов или выполнение
слишком большого числа задач, имеющихся bRUP
Внедрение слишком многого из RUP замедляет работу ио
разработке, и вместо того чтобы дать вам больше гибко-
сти, уменьшить время до выпуска продукта и снизим.
Распространенные ошибки при внедрении и использовании RUP, и как их избежать
265
стоимость, скорее всего, даст противоположный результат и в конечном итоге
приведет к общей неудаче. Основа процесса RUP подобна «шведскому» столу:
вам лучше не есть всех блюд на нем, чтобы остаться здоровым и счастливым.
Применяйте только те аспекты RUP, которые представляют ценность для вашего
проекта, (см. гл. 10, 11).
В целом информационная база RUP содержит множество артефактов,
и в большинстве проектов не нужно и пытатся использовать. Что нужно сделать -
это решить, какие из этих артефактов имеют смысл для вашей организации и кон-
кретного проекта. Например, вы можете решить не использовать ни один из 8 арте-
фактов бизнес-моделирования, а использовать только 4 из 14 артефактов для опре-
деления требований (скажем, Концепцию (Vision), Актора (Actor), Прецедент ис-
пользования (Use Case) и Прототип пользовательского интерфейса (User-Interface
Prototype) и т.д. В итоге, вы можете обнаружить, что наиболее полезны для вашей
организации 15 или 20 артефактов RUP. Эго число может показаться большим, но
помните, что RUP рассматривает как артефакты многие проектные элементы,
которые вы обычно артефактами не считаете, например: Компонент (Component),
Выпуск (Build), Запрос на изменение (Change Request), Класе проекгной модели
(Design Class) и Подсистема (Subsystem). В RUP все это считается артефакгами,
даже если вы записываете их только на письменной доске или, даже, на салфетке.
Заметим, что степень формализованности, с которой вы подходите к документиро-
ванию и рецензированию артефактов, часто более важна, чем их количество.
Применение слишком большого числа артефактов замедляет
работу. Люди могут начать уделять больше внимание па доведе-
ние разных артефактов до совершенства, чем на правильное по-
строение системы. С другой стороны, если число артефактов не-
достаточно, вы можете обнаружить, что постоянно решаете одни
и те же проблемы, что повышает объемы переработки из-за недо-
понимания. То же самое может получиться, еелн вы докумен-
тируете артефакты неформально. Например, вы можете создать
Выбирайте в сво-
ем проекте
верный баланс
между высокой
и низкой форма-
лизованностью.
великолепную
реализацию постоянного хранения данных, но если ваши решения записаны
только на письменной доске, их не смогут использовать члены команды, находя-
щиеся в других местах. Вам необходимо формализовать документацию,
например, с помощью средства визуального моделирования. Поэтому важно не
только выбрать верные артефакты, но также и сделать их доступными для всех
членов команды. Как уже говорилось в главе 3, вам нужно выбрать в своем проек-
те верный баланс между высокой и низкой формализованностью.
Когда вы сталкиваетесь с необходимостью решить, включать ли в проект
конкретный артефакт, задайте себе следующие вопросы: Каковы будут последст-
266
Глава 13
впя сейчас или в будущем, если этого артефакта не будет?, Какие риски снижао
ыпный артефакт? Даже когда вы хотите использовать минимальный набор арте
фактов, в RUP они используются по определенным причинам. Важно, чтобы вы
подумали о ценности артефакта и степени его формализованное™, а также о бу
|\ щих проектах, связанных с обслуживанием программного обеспечения.
Внедрение всего сразу, не постепенно
(тнцентрируй-
к ч:ь на внедре-
нии iex частей
HUP, которые при-
н< су/ самый боль-
///< >и результат.
Мы настоятельно рекомендуем, чтобы внедрение RUP произво
дилось постепенно. Если вы еще не применяете простейший под
ход, попытка внедрить весь процесс сразу окажется непомерной
и, скорее всего, приведет к снижению производительности и в ко
нечном итоге к отказу от RUP. Следовательно, мы рекомендуем
сначала сконцентрироваться на внедрении тех частей RIJP.
которые принесут самый большой результат.
Предположим, у вас есть набор целей на 18 месяцев, и вы хотите получи и.
руководства и логику создания 15-20 артефактов, наиболее подходящих для ва
uieii организации. Как добиться этого? Рассмотрим пример.
Ваша команда в течение следующих 18 месяцев будет работать над тремя 6-ме
i ячпыми проектами. Вы выбираете, какие артефакты создавать в первом проекче.
какие нужно будет добавить в следующем и т.д. План может выглядеть следующим
поразим (курсивом выделены артефакты).
Проект 1. Основное внимание управлению требованиями и итеративной разработке
Цель: зафиксировать требования и начать использовать итеративный, управляй’
мый рисками подход. Эти цели являются критичными для успеха многих проектов.
Чтобы достигнуть данной цели, в проект вводится семь артефактов.
• Определите акторов (actor) и прецеденты использования (use case), создай i с
прототипы пользовательского интерфейса (user-interfaceprototypes).
• Внедрите итеративный, базирующийся на компонентах процесс.
• Выявите риски (risk) и обеспечьте сведение к минимуму крупных рисков
в ранних итерациях.
• 11е создавайте формальную проектную модель, а создайте четко определенные
компоненты (component), организованные в подсистемы реализации (imple
mentation subsystem), и проведите в команде их рецензирование.
• ('издавайте в проекте выпуски (build) еженедельно.
Распространенные ошибки при внедрении и использовании RUP, и как их избежать 267
Проект 2. Основное внимание управлению конфигурациями и изменениями, а также
тестированию
Цель: повысить качество путем работы с Управлением конфигурациями и из-
менениями, а также с тестированием. Оценивать прогресс в первую очередь по
тому, работает ли код, как ожидалось, а не по завершенным артефактам.
Чтобы достигнуть данной цели, в проект вводится семь артефактов.
• Введите план тестирования (test plan) и прецедент тестирования (test case),
разработайте для совершенствования процесса тестирования тестовые скрип-
ты (test script). Артефакты, связанные с тестированием, должны основываться
на требованиях.
• Фиксируйте запросы на изменения (change request) (например, на исправление
дефектов) по мере поступления и следите за этими запросами в целях оценки
своей работы.
• Введите в действие средства Управления конфигурациями, поддерживающие
проектный репозиторий (project repository), а также рабочее пространство
(workspace) для разработчика и для интеграции.
• Создавайте выпуски (build) ежедневно в последние два месяца работы над про-
ектом, , используя автоматизированный процесс создания выпусков.
Проект 3. Основное внимание проектированию и архитектуре
Цель: сконцентрироваться на проектировании и компонентных архитектурах,
чтобы убедиться, что вы действительно реализуете требования и что система лег-
ка в обслуживании.
Чтобы достигнуть этой цели, в проект вводится четыре артефакта.
• Введите классы проектной модели (design class) и подсистемы проектной мо-
дели (design subsystem) для построения компонентной архитектуры. Обеспечь-
те разработку основы архитектуры к концу фазы Проектирование.
• Введите реализации прецедентов использования (use-case realization), то есть
создайте диаграммы последовательностей или диаграммы кооперации, чтобы
обеспечить включение требований в проектную модель.
• Усовершенствуйте процесс управления требованиями путем создания доку-
мента «Концепция».
При постепенном внедрении вам часто приходится изменять первоначальный
план, поскольку вы можете не добиться продвижения или приоритеты могут по-
меняться. Но как решить, с чего начинать?
268
Гланд i
В главе 2 мы обсудили восемь фундаментальных принципов RUP. В таблиц
13.1 мы обрисовали проведение постепенного совершенствования в трех наши
проектах с использованием многих из этих принципов.
table чзл Постепенное совершенствование по всем фундаментальным направлениям. В каждом из трех
проектов мы производили все большие улучшения, используя некоторые из фундаментальных принципов,
составляющих «дух RUP». Каждая организация должна решить, какие принципы дадут наибольший выигрыш
и в соответствии с этим расставить приоритеты в совершенствовании процесса.
।Принцип ,Проект 1
Проект 2
। Проект 3
Начинайте наступление на Вводились риски как способ I
главные риски раньше и ' определения необходимых в 1
ведите его непрерывно или ! каждой итерации действий i
они сами пойдут в наступ- i I
ление на вас
Обеспечьте выполнение ! Требования были внесены в
|ребований заказчиков ^документ
Сконцентрируйтесь на | Еженедельное создание
исполняемой программе । выпусков и итеративная
jразработка
Г 1риспосабливайтесь к . С самого начала ведется
изменениям с самого итеративная разработка
начала проекта ;
Закладывайте основу
исполнимой архитектуры
как можно раньше
Ci ройте систему из компо- Компоненты неформальным
центов i образом определены
Для требований в форме
। прецедентов использовании
! были разработаны проект
; ные решения в форме так
I называемых реализаций
, прецедентов использования
' Ежедневное создание выпус-
' ков др конца проекта. Силь-
ный акцент на тестировании :
i Формализованный процесс :
(Управления изменениями
( ; К концу фазы Проекгиров; i
• ; ние создана основа
i i архитектуры
i • Формализованная
; - разработка с использова-
1 | нием компонентов
(Требования были
। протестированы
Распространенные ошибки при внедрении и использовании RUP, и как их избежать 269
Table 13.1 Постепенное совершенствование по всем фундаментальным направлениям. В каждом из трех
проектов мы производили все большие улучшения, используя некоторые из фундаментальных принципов,
составляющих «дух RL/Р». Каждая организация должна решить, какие принципы дадут наибольший выигрыш,
и в соответствии с этим расставить приоритеты в совершенствовании процесса. (Продолжение)
Принцип Проект 1 Проект 2 Проект 3
Работайте вместе как одна Итеративная разработка Предпочтение отдается
команда потребовала более тесного встречам «лицом к лицу» для : сотрудничества команды. быстрого разрешения Практика работы с проблем । меняющимисятребованиями ’ * способствовала более тес- ному контакту с заказчиками.
Сделайте качество образом
жизни, а не запоздалой
идеей
На всем протяжении проекта
осуществляется обеспечение
качества
Оцените работу своей организации и поймите, где вы сталкиваетесь
с наибольшими трудностями, а где ваши потребности максимальны (см. гл. 11).
Какие из восьми принципов главы 2 нужно внедрить, чтобы получить наибольшую
отдачу? Организация в приведенном выше примере внедряла принципы в опреде-
ленном порядке. Для вашей организации приоритеты могут выглядеть иначе.
Отсутствие планирования при внедрении RUP
Попытка внедрить Rational Unified Process без должного пла-
нирования, скорее всего, приведет к неудаче. Внедрение Rational
Unified Process нужно само по себе рассматривать как проект
или программу, с экономическим обоснованием и четкими целя-
ми, такими как снижение стоимости разработки программного
обеспечения, повышение качества и снижение длительности
проектов. Вам нужно выяснить, какой способ внедрения будет
Попытка внедрить
Rational Unified Pro-
cess без должного
планирования,
скорее всего, при-
ведет к неудаче.
наилучшим для вашей организации. Например, описанное выше постепенное
внедрение. Такой способ внедрения не получается «с налету». Для успешного вы-
полнения проекта требуется постоянное планирование и поддержка. Также вам
нужно подумать о том, чтобы начать внедрение RUP с пилотного проекта,
в котором вы сможете применить RUP и сопровождающие его инструменты,
обеспечить успех внедрения и провести обучение процессу и инструментам.
270 Глава 13
Деликатные вопросы, такие как получение подтверждения высшего руководства
и менеджеров среднего звена, а также обеспечение мотивации перехода на новый
процесс для менеджеров проекта являются критическими для успеха внедрения
KI II’. В некоторых организациях особенно затруднительно получить подтверждение
менеджеров среднего звена, поскольку они имеют дело не только с рисками самою
проекта, но и с риском нового способа управления проектом. Существуют такжх
финансовые вопросы, а вам потребуются деньги на наставников, на обучение и
возможно, на приобретение программных средств. Кроме того, вам нужно убедить
ся, чю вы обладаете квалификацией или можете приобрести квалификацию, необ
мнимую для настройки RUP, включающей разработку специфичных для проекта
инн организации руководств по моделированию прецедентов использования
проектированию, программированию и т.п.
I (аличие человека (или группы), ответственного за внедрение RUP, значите.!),
по повышает вероятность успешного внедрения, по крайней мере если у этою
к-товека (или группы) есть мандат на проведение необходимых действий, неоо
ходпмое финансирование и проводится оценка эффективности внедрения. Такой
чс1|овек (или группа) продвигает проект по внедрению, обеспечивает «перекрес!
пос опыление» между группами, что гарантирует отсутствие повторения ошибок
и выдает предупреждения менеджерам по мере необходимости. Такой человек
(и in । руппа) должен являться активным и ценным участником проекта, а не быю
осснолезным подгонялой. Нужно заметить, что вы очень много выиграете от на
шчия опытного наставника, который поможет вам с внедрением RUP и не даю
। овершить обычные ошибки, (ем. гл. 11).
Отсутствие связи между совершенствованием процесса
и экономическими результатами
I ь // п 'делитесь с тем,
экономических
/ * tym, тагов вы хотите
ill >i у и/ путь, и сообщите
.на t кидаемые резуль-
тат всем заинтересо-
ванным лицам.
Совершенствование процесса путем внедрения Rational Uni
Tied Process требует большой работы и затрат на обучение
наставничество и приобретение инструментов. Важно, чтобы
ваша организация определилась с тем, каких экономических
результатов вы хотите достигнуть, и эти ожидаемые резуль
тэты нужно должным образом сообщить всем заинтересован
ным лицам. В противном случае внедрение RUP, скорее
ы си), окончится ничем из-за отсутствия одобрения заинтересованных лиц (помп
мп всею прочего), и вы так и не увидите ожидаемых результатов.
Гели вы делаете акцент на экономических результатах, вам будет легче ни
в чип. одобрение от старшего менеджмента и от участников проекта. Крайпе
Распространенные ошибки при внедрении и использовании RUP, и как их избежать 271
трудно осуществить внедрение RUP, не получив одобрения всех этих люден,
поэтому важно разработать основательное экономическое обоснование. В нем
должны определяться будущие выгоды от развертывания RUP и проводиться
анализ внедрения.
Излишне детальная и слишком ранняя настройка RUP
Точно так же, как мы рекомендуем использовать при
разработке программного обеспечения итеративный подход, мы
рекомендуем использовать итеративный, поэтапный подход к
настройке и внедрению RUP. Не начинайте настраивать RUP в
Используйте итера-
тивный, поэтапный
подход к настройке
и внедрению RUP.
шестимесячном проекте до того, как вы опробуете его на меньших проектах.
До того как вы попробуете RUP на практике, у вас не будет достаточно информа-
ции, чтобы точно говорить о преимуществах, которые вы получите от внесения
изменений в RUP. Проведите минимальную настройку и конфигурирование,
апробируйте RUP в проекте, сделайте несколько более детальную настройку
и конфигурирование в пропущенных ранее областях и т.д. Например, в первом
вашем проекте вас может удовлетворить генерация Конфигурации RUP, создание
«легкого» прецедента разработки (см. гл. 10) и добавление внешних ссылок на
имеющиеся у вас до выполнения проекта по включению внешних материалов
в Плагин RUP руководства по процессу.
Пустословие
Rational Unified Process становится очень популярным, и многие организации
находят большой экономический смысл в том, чтобы заявлять, что они используют
RUP. Обратная сторона этого состоит в том, что некоторые заказчики, кажется, более
заинтересованы в том, чтобы увидеть штамп «Мы используем RUP», чем в по-
лучении реальных усовершенствований процесса. Могут применяться некоторые
артефакты RUP и кое-какая терминология, но «дух RUP» (см. гл. 2) не внедряется.
Это это негативно отражается на организации. Как только заинтересованные лица
понимают, что организация не получает ожидаемых выгод, они теряют веру в орга-
низацию и в ее способность эффективно разрабатывать программное обеспечение.
К некоторым симптомам пустословия относятся следующие.
• Вы переименовываете функции в прецеденты использования, что позволяет
вам необоснованно утверждать, что вы используете разработку, основанную
на прецедентах использования, вместо того, чтобы создавать завершенные
?72
Глава 13
прецеденты использования, обеспечивающие значимый результат для одного
пли нескольких акторов.
• Вы создаете список рисков, но не используете его для определения порядка
в котором вы будете бороться с проблемами, с которыми вы всегда встречас
iccb в проекте.
• Вы подробно описываете все требования перед началом проектирования, а не не
пользуете итеративный подход со сбалансированной работой с требованиями, ана
лнзом, проектированием, реализацией и тестированием в каждой итерации.
• Вы подробно планируете проект заранее, от начала до конца, а не создаете
подробный план итерации прямо перед ее началом.
• Вы используете каскадный подход вместо итеративного или ваши итерации
с голь длинны, что вы теряете практически все преимущества итеративной
разработки.
• Вы измеряете прогресс в первую очередь числом созданных описаний преце
центов использования и завершенностью проектных документов, а не испод
пяемой программой и успешно пройденными тестами.
• Вы игнорируете в своем проекте архитектуру, включая ее тестирование, до тех пор
пока не будет слишком поздно и переработка архитектуры не станет чрезвычайно
дорогой, что приведет к задержкам в проекте и выходу за рамки бюджета.
Заметим, что есть большая разница между пустословием и поэтапным
внедрением RUP. Когда вы постепенно внедряете RUP, вам следует ожидать, чю
вы столкнетесь с некоторыми из этих симптомов. Но при постепенном внедрении
КНР вы сознаете, что еще не работали с ними и либо у вас уже есть на них cooi
впсгвующий план либо решение, что для вашей организации борьба с этим сим
и юмом (симптомами) невозможна или нежелательна.
Ошибки при управлении итеративной разработкой
11ереход от каскадного подхода к итеративной разработке требует от всех членов
команды изменения рабочих процедур, а это иногда особенно трудно для менед
жеров проекта и архитекторов. Организации, осуществляющие такой переход, час
ю придерживаются определенной схемы и процесса, которые приводят к нс
корректному выполнению проекта. Среди распространенных ошибок мы наблюди
ин следующие.
• Функциональная, специализированная организация как противоположное 11.
многофункциональным командам.
Распространенные ошибки при внедрении и использовании RUP, и как их избежать 273
• Отсутствие корректировки ожиданий заинтересованных лиц или использо-
вание старой схемы заключения контракта, что приводит к тому, что заин-
тересованные лица ожидают те же самые продукты и тот же самый жизненный
цикл, что и при использовании каскадного подхода.
• Слишком большое число разработчиков в начале работы над проектом еще
до того, как вы поймете, что, собственно, нужно делать.
• Разрешение сначала легких проблем, а не атака на наиболее крупные риски.
• Расширенная первая итерация. Попытка сделать слишком многое в самом
начале.
• Использование перекрывающихся итераций. Запуск следующей итерации
до того, как вы воспользуетесь всеми преимуществами предыдущей.
• Слишком много изменений на поздних этапах проекта. Это приводит к круп-
ным задержкам, выходу за рамки бюджета и, возможно, к снижению качества.
Рассмотрим эти ошибки подробно и изучим некоторые приемы, позволяющие
избежать их.
Функциональная, специализированная организация
Итеративный подход подразумевает, что итерация проходит
весь жизненный цикл - анализ, проектирование, реализацию,
интеграцию и тестирование. Если команды разработчиков орга-
низованы вокруг соответствующих функциональных областей,
тогда между этими командами нужно будет передавать массу
информации. Это повышает риск сбоев при общении (рис. 13.1)
Функциональная
организация, как
правило, подразу-
мевает трату массы
времени на непро-
дуктивные задачи.
и, как правило, подразумевает трату массы времени па непродуктивные задачи,
щкие как документирование, управление и рецензирование всего на свете.
Конечно, до некоторой степени документация - это хорошо, но функциональ-
но ориентированные команды имеют тенденцию тратить на нее слишком много
ценного времени, забирая его у продуктивных задач, например у разработки ис-
полняемой программы.
В идеале команда должна быть многофункциональной, с несколькими уни-
версальными специалистами, имеющими квалификацию более чем в одной об-
ласти. Фазу Начало начинают с небольшой командой, от 3 до 5 человек (для тех
проектов, в которых затем будет задействовано 15 человек). Например, в команду
могут входить:
• менеджер проекта, который помогет делать анализ;
• один или два аналитика;
274
Глава 13
Аналитик
Дизайнер/
Разработчик
Тестировщик
STOP
' -(STOP
Рис. 13.1. Функциональные команды имеют присущие им коммуникационные барьеры. Итеративный
подход требует широкого общения, чего трудно достигнуть, если аналитики, разработчи
ки и тестировщики работают в разных командах. Для решения этой проблемы, создавай!с
многофункциональные команды с несколькими универсальными специалистами
архитектор, помогающий писать архитектурный код;
• ведущий разработчик, осуществляющий проектирование и реализацию;
• один тестировщик с частичной занятостью на всю систему.
Каждый член команды должен нести ответственность за качество своего продукта.
Отсутствие корректировки ожиданий заинтересованных
лиц или использование старой схемы заключения контракта
Важно, чтобы у заинтересованных лиц были правильные ожидания. Если руко
водство, заказчики и прочие заинтересованные лица привыкли к иному жизненно
му циклу проекта, вы можете столкнуться с массой проблем. От вас, например,
могут потребовать:
• полный детальный план проекта заранее, а не первоначальный общий план,
который дополняется планами текущей и следующей итераций;
• создать полную спецификацию требований к концу фазы Начало, до того, как
поступит финансирование для оставшейся части проекта;
• зафиксировать бюджет на весь проект к концу фазы Начало, до того как у вас
будет вся необходимая информация. Борьба с крупными рисками будет начаы
в фазе Проектирование, и любые оценки общих затрат, до того как крупные
риски будут сведены к минимуму, окажутся весьма неопределенны.
Эти ограничения могут заставить вас использовать вместо итеративного но
дхода каскадный со всеми его недостатками. Очень распространенной ситуацией,
ныкающей людей к каскадному образу мышления, является старая схема за-
ключения контракта, когда в конце фазы Начало вы выдвигаете фиксированное
предложение на основе фиксированных требований, планов и стоимости всею
Распространенные ошибки при внедрении и использовании RUP, и как их избежать
275
проекта. Вместо этого вам нужно разделить проект на два предложения
(рис. 13.2), в котором одно приходится на фазу Проектирование, а другое (воз-
можно, фиксированное) - на фазы Построение и Внедрение. Это сделает жизнен-
ный цикл проекта более экономичным и устойчивым и позволит избежать круп-
ных рисков, таких как позднее обнаружение выходов за рамки сроков и бюджета
и отсутствие реализации требований.
Онреддшь
‘общую
юнцепиро
ПОДО1ОВИ1Ь
предложение.
Согласовать
юн трал
Первое предложение
Выполнить контрал.
Провести испытания
Подготовить
предложение
Согласовать
контракт
Второе предложение
Выполнить контракт.
Провести испытания
Начало
Проектирование -
Построение
Внедрение
Рис. 13.2. Разделение работ по проекту на несколько предложений. Выполнение работ но контракту
в итеративных проектах лучше всего производить в нескольких предложениях. Например,
одно предложение может относиться к фазе Проектирование, а другое - к фазам Построение
и Внедрение
Слишком большое число разработчиков в начале работы над проектом
Несколько лет назад к нам пришел один наш коллега и пожаловался на проект,
в котором он начал работать. Менеджеры поставили на проект с самого начала 40
разработчиков и группу из 7 или 8 аналитиков и архитекторов для анализа требова-
ний и разработки архитектуры. В офис к нашему коллеге, который был ведущим
аналитиком, постоянно приходили разработчики и требовали от него заданий, что
заставляло его тратить больше времени на придумывание этих фиктивных заданий,
чем на анализ требований. Нет никакого смысла вводить в проект большое число
разработчиков, до того как у вас будет основа архитектуры и до того как вы пойме-
276
Глава i:i
ie, какие проблемы вы будете стараться решить1. Все что будет построено, будю
построено на песке, и в конце концов вы станете переписывать практически все на
писанное, а выпущенная система будет подобна лоскутному одеялу.
Заметим, что вам все же потребуется некоторое количество людских ресурсом
и фазе Начало и особенно в фазе Проектирование. Поскольку вам нужно разрабат ы
нагь, реализовывать и тестировать архитектуру, скорее всего, нужно будет задейп
новать в фазе Проектирование наиболее опытных разработчиков, поскольку они
дуг строить каркас, на котором базируется вся будущая разработка. Так что, создан
ie небольшую высококвалифицированную команду для фазы Проектировать
и расширяйте ее по мере того, как архитектура стабилизируется (рис. 12.3).
Ресурсы
5% 20'1/ т
10%. .30%........ ,50%
Начало Проектирование Построение
10%
Внедрение
Время
Легенда m
Запланированные
(% от всех в проекте)
Рис. 13.3. В начале проекта число разработчиков нужно ограничить. Нужно избегать привлечении
слишком большого числа людей в самом начале проекта. На этом рисунке показано............
фаза Начало начинается с небольшой команды, которая несколько увеличивается в ф.> .
Проектирование, и еще больше разработчиков и тестировщиков присоединяю!. .
к команде в фазе Построение
I. Бывают естественные исключения. В одном проекте мы предложили группе разработчиков независим,
[«□работать основу для дальнейшего использования, в то время как мы выясняли, что должно делать приложен..
В чем-то это оказалось успешным, поскольку разработчики были знакомы с данной областью и смогли едги.и.
хорошие предположения о тех компонентах, которые им потребуются позже. Однако опасность такого пода>ю
в гом, что вам, может быть, придется отбросить многие ненужные компоненты, которые не соответ с i ну».
|ребованиям. - Примеч. авт.
Распространенные ошибки при внедрении и использовании RUP, и как их избежать
277
Разрешение сначала легких проблем
Часто возникает искушение сказать: «Это вопрос деликатный, на его обдумыва-
ние нужно много времени. Давайте отложим его решение на потом, когда у нас будет
время на обдумывание». Проект начинается с выполнения легких задач, а на труд-
ные никто не обращает внимания. Когда дело доходит до их выполнения, прини-
маются быстрые необдуманные решения или же проект просто терпит крах.
Вам нужно делать прямо противоположное - распутыват ь
сложные проблемы немедленно. Нужно иметь постоянно об-
новляемый список рисков, который и должен давать направле-
ние вашим действиям на протяжении данной итерации. Если
только возможно, всегда боритесь сначала с самыми крупны-
Если только возмож-
но, всегда боритесь
сначала с самыми
крупными рисками.
ми рисками. Если проект по каким-то причинам проваливается, отказывайтесь от
него как можно быстрее, до того как вы потеряете время и деньги.
Еще одна обычная ошибка - когда не проводится непрерывного обновления
списка рисков. В фазе Начало вы проводите анализ рисков и используете его
результаты при планировании, однако вы забываете о рисках, появляющихся поз-
же, и они возвращаются, чтобы больно ударить по вам. Повторную оценку рисков
нужно проводить постоянно, ежемесячно, а может и еженедельно. Первоначаль-
но составленный список рисков был только пробным. Только когда команда
начинает выполнять реальную разработку, откроются многие другие риски.
Расширенная первая итерация
Рискованно пытаться сделать слишком много в первой итерации. Как правило,
в фазе Начало содержится одна (или две) итерации, и нужно быть уверенным, что
эти итерации будут успешны. Это означает, что вам нужно выпустить именно то.
что вы обеша н! выпустить, и вовремя. Конечно, небольшие задержки могут быть
приемлемы, но не очень крупные. Они создают для команды плохие прецеденты,
что повышает вероятность провала всего проекта. В фазе Начало нужно устано-
вить четкий*ритм проекта: «Мы создаем выпуск каждые шесть недель, мы созда-
ем выпуск каждые шесть недель, мы создаем ...» Грейди Буч (Grady Booch) назы-
вает это «задать равномерный пульс»2.
Если вы начинаете опаздывать, не позволяйте первой итерации длится беско-
нечно. Сузьте границы и, если нужно, добавьте еще итераций, но заставьте команду
принять определенную длину итерации - две, четыре или шесть недель, например.
2. См. Booch 1996.
278
Глава 13
’к-гкий ритм позволит следить за чем, чтобы проект не отклонялся от маршрута
а пресс равномерно распределялся на каждую вторую, четвертую или шестую не
ie.ilю. а не ввергал команду в панику за два месяца до выпуска (рис. 13.3). Заметим
чк> длительность итерации может варьироваться в зависимости от ее целей и от то
io. н какой фазе вы находитесь, но в общем случае осуществлять планировать
проще, если итерации имеют сходную длину (по крайней мере, в пределах одной
фазы), (см. гл. 12).
4 недели
4 недели
4 недели
4 недели
Рис. 13.4. Сходные длины и тераций помогают установить в проекте четкий ри тм. Важно, чтобы
первая итерация не была слишком длинной. В идеале, чтобы установить четкий ритм, ik >
итерации внутри одной фазы должны иметь одинаковую длину
Использование перекрывающихся итераций
Глце одна очень распространенная ловушка - чересчур перекрывающие!, я
терапии (рис. 13.4). Начать планирование следующей итерации где-то до >ю
i иедней четверти текущей, с попыткой получить значительное перекрытие задач
(например, начать детальный анализ или проектирование и кодирование для еле
чующей итерации до завершения текущей и до извлечения из нее уроков) moaci
показаться заманчиво при взгляде на диаграмму Гантта, но это приводи!
к проблемам. Некоторые люди не станут доводить до конца свою долю рабой а
н текущей итерации. Они могут оказаться не очень ответственными, чтобы вы
полнить все исправления, или же они просто решат принять во внимание всю по
пленную информацию лишь в следующей итерации. Некоторые чаю и
npoi раммного обеспечения окажутся не соответствующими ушедшей впец ।
раооте и т.д.
Хотя и возможно переключить часть персонала на работу, не связанны'
с 1екущей итерацией, такую практику нужно свести к минимуму ипримсиян
н виде исключения. Такая проблема часто инициируется узкой специализацш и
некоторых членов организации или очень строгой организационной струк-iy р>ч।
। е. «Джо - аналитик, и это все, что он умеет и желает делать. Он не жеаао
принимать участие в проектировании, реализации или тестировании». Еще один
о, рнцательный пример: в большом проекте системы управления итерации
Распространенные ошибки при внедрении и использовании RUP, и как их избежать
279
перекрываются настолько, что идут практически параллельно, это заставляет ме-
неджеров разбрасывать весь персонал по итерациям без всякой надежды восполь-
зоваться уроками предыдущих итераций.
Слишком большое перекрытие-» Нет петли обратной связи
Рис. 13.5. Большое перекрытие итерации. Большое перекрытие итераций вызывает iioicpio ориента-
ции команды, может' сделат ь членов команды менее склонными к завершению тскуттт'
задач и более предрасположенными к перескакиванию к самым последним. Перекрытие
итераций может также значительно увеличить нагрузку на менеджеров и нарушить
эффективность цепи обрат ной связи
Слишком много изменений на поздних этапах проекта
В главе 2 мы говорили о том, что следует соглашаться на из-
менения, особенно па ранних этапах проекта. Изменения - эго,
вообще, хорошо. Они позволяют совершенствовать решения.
Однако итеративная разработка не означает, что в каждой
Количество отходов и
объем переработки
должны снижаться си
итерации к итерации
итерации все нужно выбрасывать. Количество отходов и объем переработки
должны снижаться от итерации к итерации, особенно после т шо как в конце фазы
Проектирование была заложена основа архитектуры. Если вы позволите вносить
слишком много изменений на поздних этапах проекта, вам, скорее всего, грозит
задержка, выход за рамки бюджета и, возможно, низкое или неудовлетворитель-
ное качество. Это означает, что нужно тщательно продумывать, какие изменения
стоит вносить особенно ближе к концу проекта.
Часто разработчики хотят использовать преимущества итеративной разработ-
ки для доведения продукта до совершенства: для введения еще более хорошей
техники, для переделки и т.п. Менеджеру проекта нужно быть бдительным
и предотвращать переработку элементов, которые итак уже отличны или доста-
точно хороши. Также, по мере того как команда разработчиков растет в размерах,
и нее вступают новые люди. У них можег быть свое представление о том, как все
должно быть сделано.
280
Глава I.в
Также и заказчики (или их представители в проекте - менеджеры по продажам
или менеджеры по продукту) могут захотеть злоупотребить свободой, которою
дает итеративная разработка, для коррекции изменений или для бесконечных до
давлений новых требований. Такой эффект называют «расползанием требова
пий». Менеджеру проекта нужно быть жестким в компромиссах и в согласовании
приоритетов. Иначе говоря, к концу фазы Проектирование основа требований за
ложена, и если бюджет и сроки не пересматриваются, любое изменение имею
свою цену: добавление одного означает отказ от другого. Помните, что лучшее
враг хорошего.
Ошибки в анализе, архитектуре, проектировании и тестировании
Переход от каскадного подхода к итеративному требует от всех членов кома и
ды изменения рабочих процедур. Это означает, что аналитики, разработчики
архитекторы и тестировщики должны поменять свой образ действий и обре
мышления. Среди наиболее распространенных ошибок мы выделяем следующие
• Создание слишком большого числа прецедентов использования, что дс i.i
ет требования непонятными и является проявлением разбиения на функции
под именем прецедентов использования.
• Аналитический паралич, который вызывается излишним вниманием к дсы
лям, и нарушает эффективность итеративной разработки.
• Включение в требования проектных решений приводит к тому, что проем
ные решения принимаются преждевременно.
• Отсутствие утверждения требований заинтересованными лицами привонн
к тому, что создается система, которую, скорее всего, придется отбросить или ра
дикально переработать на поздних этапах проекта.
• Подход «это сделано не у нас», как правило, повышает стоимость разраб» ни
и обслуживания, а также снижает качество.
• Завершение фазы Проектирование до достижения стабильного состоянии
архитектуры приводит к большому объему переработок, что вызывает вы»> ।
за рамки бюджета и снижение качества.
• Акцепт на инспектировании, а не на исполняемой программе. Резулы.п
неэффективный процесс оценки качества и акцент на побочных продую.।
разработки программы, а не на самой программе.
Рассмотрим некоторые из этих ошибок и изучим методы, позволяющие и
избежать.
Распространенные ошибки при внедрении и использовании RUP, и как их избежать
281
Создание слишком большого числа прецедентов использования
Распространенная ошибка - разбиение прецедентов использования на фрагменты
функций, настолько маленькие, что теряются все преимущества принципа прецеден-
тов использования. Как правило, в 6-месячном проекте с участием 8 человек будет
приблизительно от 10 до 30 прецедентов использования. Дальнейшее разбиение
функций не даст ни вам, ни кому-то еще никаких выгод.
Сначала рассмотрим, чего вам нужно старатся достигнуть при помощи преце-
дентов использования. Каждый из них должен выполнять следующие функции:
• описать взаимодействие, имеющее смысл для пользователя системы
и представляющее для него ценность;
• описать полное взаимодействие или последовательность событий, происходя-
щих между системой и пользователем. Например, в системе банкомата, снятие
денег является полным взаимодействием, а простое введение PIN-кода, (один из
этапов этой процедуры, нет);
• направить работу по проектированию, прояснив, какие элементы будут взаи-
модействовать при решении конкретной задачи пользователя. Одно компо-
нентное моделирование часто оставляет в дизайне зияющие пустоты. Акцент
на получении требуемой пользовательской функциональности обеспечивает
работоспособность и полноту дизайна;
• направить работу по тестированию, описав типовые пути взаимодействия
пользователя с системой и способы, которыми их можно протестировать;
• служить в качестве средства управления, определяя набор функций, разработку
которых менеджеры могут закрепить за одним или несколькими членами
команды.
Если у вас слишком много прецедентов использования, может произойти сле-
дующее:
• поскольку подход к созданию функций слишком фрагментарный, пользовате-
лям будет трудно изучить прецеденты использования и сказать, представляют
ли они для них какую-нибудь ценность;
• поскольку в прецедентах использования будут описываться фрагменты функ-
циональности вне контекста полезных для пользователя сценариев, проек-
тирование будет сосредотачиваться на одной-двух операциях, а не на необхо-
димом взаимодействии при решении задач пользователя;
• тестирование увязнет в необходимости комбинировать множество прецеден-
тов тестирования (созданных по прецедентам использования), и созданные
тесты станут бессмысленны;
282
Глава I
• люди, которым поручено работать над разными прецедентами использования
будут постоянно натыкаться друг на друга и идти по следам друг друга, и< >
скольку прецеденты использования связаны слитком тесно.
Чтобы избежать всего этого, попробуйте поискать у себя следующие признаки
показывающие, ч то ваши прецеденты использования чересчур фрагментированы
• Вы не можете сказать, какую ценность ваш прецедент использования пре i
ставляег для пользователя. Это показывает, что он представляет собой слшп
ком мелкую часть полного взаимодействия.
• За прецедентом использования А всегда идут прецеденты использования В и <
Эю показывает, что они, вероя тно, представляют собой один прецедент испольк
вания и их нужно объединить.
• Два или более прецедентов использования имеют почти идентичное описать
ш исключением небольших вариаций. Это показывает, что они являкню
скорее всего, одним прецедентом использования п их нужно объединить.
• Число «включений» и «обобщений»3 превышает число прецедентов иегюльс
вания. Нужно взять за принцип никогда не использовать более одного урони ।
абстракции и совсем никогда - больше двух.
• Вы не можете придумать описаний прецедентов использования (последоватс и
востсй событий), которые были бы длиннее нескольких абзацев.
Аналитический паралич
KUP - процесс итеративный. Это означает, что время для детализации трет,
ваний позже у вас будет. Не тратьте слишком много времени на детализацию
|ребоваиий в фазе Начало, поскольку вам нужно быстро продумать исполни,
мую архитектуру, чтобы как можно раньше снять основные риски. А посколы >
основа исполняемой архитектуры будет закладыват ься в следующей фазе, Проа
шрование, то ваша цель - закончить работу в фазе Начало и двигаться дальше
Цель фазы Начало - определить границы и понять наиболее важные требою
ння. Вы закончите работу с требованиями для фазы Начало, если будете имет ь
• довольно полно составленный список ожидаемых акторов и прецеден к>н
использования. Нормально вносить небольшие корректировки в набор преп.
центов использования и позже, но, как правило, некрупные. Например, если ни
3 Включения (includes) и обобщения (generalizations) представляют собой отношения между имеющими
п|юцедентами использования, используемые для структурирования модели прецедентов использования (use ।
model). Информацию о том, когда используются эш взаимоог ношения, можно найти у Bittner 2003. - Примет
Распространенные ошибки при внедрении и использовании RUP, и как их избежать
283
определили в фазе Начало 20 прецедентов использования, в фазе Проектирова-
ние вы можете добавить один, а один удалить;
• подробное описание сути, т. е. критических прецедентов использования
(приблизительно 20-30 от общего числа), - чтобы у вас было о них по настояще-
му твердое представление, в идеале, - с экранными протот ипами или с чем-то
подобным. 4-7 из 20 прецедентов использования должны иметь одно-двухстра-
ничное описание. Для остальных можно ограничиться парой абзацев.
Нужно отметить, что небольшие команды, расположенные в одном месте,
могут составлять менее подробную документацию прецедентов использования
для экономии времени.
Включение в требования проектных решений
Распространенной практикой, особенно при написании требований в форме
прецедентов использования, является то, что аналитики включают в них проект-
ные решения, например описание графического интерфейса пользователя (GUI)
или реализацию различных алгоритмов. Это приводит к фиксации неверных
проектных решений, а также к тому, что аналитики и пользователи отклоняются
от цели - фиксирования и согласования требований.
Ниже приводится пример требования, включающею в себя проектные решения.
Система производит поиск свободных в данное время конференц-залов в базе
данных, используя в качестве ключей поиска время начала и время окончания. Сво-
бодные комнаты в списке обозначаются зеленым цветом, а занятые - красным.
Из такого требования нужно убрать проектные решения, указывающие на спо-
соб представления информации и используемые поисковые алгоритмы.
Система выясняет, какие конференц-залы свободны в данное время. Система
выдает список всех имеющихся конференц-залов и. где можно, производит
графическое разделение конференц-залов, чтобы определить, какие из них сво-
бодны, а какие — заняты.
Отсутствие утверждения требований заинтересованными лицами
Когда вы подробно распишите концепцию, прецеденты использования и не-
функциональные требования, вам будет нужно утвердить их при участии всей ко-
манды проекта, включая заказчиков, разработчиков и тестировщиков, чтобы быть
уверенным, что данные требования верны. Если этого не сделать, то вы будете
284
Глава i
делать инвестиции в требования, которые возможно придется радикально менян-
что приведет к ненужной переработке. Это вовсе не означает, что нужно разраб.i
1ывать все требования заранее или что все общение должно поддерживаты
через спецификации требований, но вам нужно четко понять, что за систем.!
будет разрабатываться.
Подход «это сделано не у нас»
Архитектурные компоненты или их части часто используются повтори!'
Интегрированные среды разработки (IDE) позволяют использовать архи ген
ирные механизмы и шаблоны, доступные через Web или имеющиеся в книгах1
Вам и вашим коллегам по компании, возможно, уже приходилось ранее создавай
системы сходного типа, вы знаете, что работает, а что нет и можете найти готовы!
коммерческие компоненты (Commercial OtT-the-Shelf, COTS) или паке и.।
программ, подходящие для ваших целей. Везде, где это возможно, нужно стара!
ся применять готовые работающие решения, будь то компоненты, схемы, процш
сы, планы тестирования или другие артефакты.
К сожалению, многие разработчики скептически относятся к чужим, возмот
но, не очень оптимальным решениям и предпочитают разрабатывать свои собе,
венные, «нуля». Важно помнить, что лучшее - враг хорошего. Вы сможете Haiini
сами лучшее решение, но какой ценой?
Вам нужно обеспечить (особенно если вы архитектор), чтобы архитектурпы.
схемы, которые были разработаны в фазе Проектирование, не изобретались учж i
пиками проекта заново на более поздних этапах проекта. Этого можно добиты ч
проводя обучение и рецензирование проектной модели. Важно правильно донеси!
имеющиеся схемы и архитектурные механизмы до всех участников проекта.
Если вы подумываете об использовании компонентов, созданных сторонними
производителями, нужно принять во внимание такие моменты.
• Нужно понять, каким требованиям должны удовлетворять указанные комп<>
ненты. Затем надо определить, соответствуют ли компоненты этим требовани
ям или можно ли их сделать соответствующими. Если нет, необходимо ншпи
компромисс между величиной экономии средств и степенью нарушения i р,
бований.
• Нужно проверить качество используемого компонента. Хорошо ли он докумсп
тирован и протестирован? Если нет, стоимость его использования может окл
заться выше, чем стоимость написания «с нуля».
4 См. Gamma 1995. - Примеч. авт.
Распространенные ошибки при внедрении и использовании RUP, и как их избежать
285
• Будет ли сторонний производитель осуществлять поддержку компонента или
вам необходимо делать это самостоятельно?
• Нужно изучить юридическую сторону и возможную оплату. Будет ли эконо-
мически рентабельным использование стороннего компонента? Будете ли вы
полным собственником конечного продукта? Каковы будут ваши финансовые
обязательства?
Как видно, необходимость в использовании существующих компонентов не
всегда бесспорна, но в принципе преимуществ в повторном использовании на-
много больше, чем недостатков. Помните также и о том, что в проектах часто не-
дооценивается сложность самостоятельного создания компонентов и есть ощу-
щение, что лучше и быстрее все создать самим. Много лет назад мы посетили
конференцию, на которой выступающий попросил одну половину зала написать,
сколько времени, по их мнению, заняло бы у них решение определенной пробле-
мы. Другую половину зала выступающий попросил написать, сколько времени,
по их мнению, заняло бы решение этой проблемы у сидящего с ним рядом чело-
века. Довольно забавно, что в среднем человек считает, что он мог бы решить
проблему почти в два раза быстрее, чем другой.
Завершение фазы Проектирование до достижения стабильного состояния
архитектуры
В создании основы исполняемой архитектуры к концу фазы Проектирование
сеть ряд преимуществ:
• это позволяет снизить технические риски;
• это дает вам стабильную основу, на которой строится система;
• это способствует эффективному повторному использованию крупномасштаб-
ных компонентов;
• это облегчает ввод в проект большего числа разработчиков в том числе, более
молодых, поскольку многие наиболее сложные структурные задачи уже реше-
ны, и разработчики могут работать в четко определенных областях;
• это позволяет точно оценить время, необходимое для завершения проекта.
• это позволяет вести больше параллельной работы.
Если вы будете забегать вперед и начнете фазу Построение, до того как архи-
тектура разработана, реализована и протестирована, вы потеряете многие, если
не все преимущества, и это в конечном итоге приведет к выходу за рамки бюдже-
та и снижению качества. Нужно решить, добавлять ли в фазу Проектирование
еще одну итерацию и, следовательно, согласиться с задержкой в проекте или
286
Глава 13
переходить к Построению и строить приложение на непрочной архитектуре. Boi
некоторые руководства, когда и какой подход выбирать.
• Если вы добавите итерацию к фазе Проектирование, будет меньшая верояя
ность позже столкнуться с крупными перестройками в проекте из-за архитек
турных проблем. Получающуюся задержку из-за введения итерации можно
компенсировать, например, сужением границ проекта или понижением уровня
качества. В качестве альтернативы можно примириться с тем, что задержка
для доведения архитектуры до ума приведет к задержке выпуска конечною
продукта. В больших проектах, системах со сложной архитектурой и сисзс
мах, использующих много новых технологий, нужно подумать о выборе по
следней альтернативы.
• Если вы решили переходить к Построению, несмотря на нестабильность архн
тектуры, вы рискуете тем, что вам придется перестраивать архитектуру позже
что приведет к задержкам в проекте, которые могут оказаться существенными
Вы рискуете не получить и других упомянутых преимуществ, которые даю
базовая архитектура. В проектах меньшего размера или проектах с просюи
архитектурой, знакомой технологией и знакомой предметной областью можно
подумать о выборе такой альтернативы.
Нужно заметить, что чем более нестабильна архитектура, тем более рискован
ним будет второй подход. Нужно также отаметить, что такой процесс, ып.
Экстремальное программирование (Extreme Programming, ХР) в общем поощряю
использование второго подхода, что объясняет, почему ХР больше подходит :i ।,
малых проектов и проектов среднего размера с ограниченным числом архи к i
гурных рисков. В ХР предполагается, что переработка кода позволит эволющюн
по достичь качественной архитектуры, не вызывая при этом крупных или беси.'
лезных переработок. Мы считаем, что делать такие предположения рискованно
Этот момент, вероятно, является одним из наиболее крупных разногласий меж ।
КИРиХР.
Но как узнать, что работа над архитектурой в основном завершена? Кое-как.,,
переработка архитектуры еще потребуется, но она будет приблизительно соотвс i > ,
вовать 5-15% архитектуры (измеряемой, например, по изменениям, вносимы.,
в интерфейсы компонентов и подсистем). Лучший способ определить готово, >. и
архитектуры - посмотреть на долю изменений в коде и интерфейсах. Ближе к кони
фазы Проектирование доля изменений интерфейсов (операций, определяемых ,,>
ключевых компонентов и подсистем) должна снижаться. Экстраполируя кривы"
показанную на рис. 13.5, вы сможете оценить, когда вы достигните такого сое ни
ния, когда будущие изменения будут составлять менее 15%.
Распространенные ошибки при внедрении и использовании RUP, и как их избежать 287
При проведении итеративной разработки вы обнаружите, что доля изменений
кода, требований, проектной модели и т.п. является отличным показателем за-
вершения. Спросите себя: являются ли требования и архитектура к концу фазы
Проектирование стабильными? является ли стабильным код к концу фазы По-
строение?
График А
Интенсивность изменений упала - фаза
проектирование завершена
График В
Интенсивность изменений нестабильна - фаза
проектирование не завершена
Рис. 13.6. Доля изменений интерфейсов показывает, когда можно завершать фазу Проектирование. Па
графике Л мы видим явную постоянную тенденцию к уменьшению числа дефектов, ч то
убеждает нас в стабильности архитектуры. На графике В мы такой четкой 'тенденции не
видим, это предупреждает пас о том, что мы не продвигаемся в направлении стабильной
архитектуры. Фазу Проектирование завершать нельзя
Акцент на инспектировании, а не на исполняемой программе
Сильный акцент на инспектировании является признаком каскадного образа
мышления, когда большая часть усилий по оценке качества направлена на по-
бочные продукты разработки программного обеспечения, такие как планы,
требования, проектные решения, а не на первичные продукты (программное
обеспечение и его качество).
Старая школа оценки качества сравнивает каскадный подход без инспекций
с каскадным подходом с инспекциями и обнаруживает, что в последнем случае
создается код намного более высокого качества. Такое наблюдение верно, но при
этом не распознается фундаментальная проблема - само использование каскадно-
го подхода к разработке программного обеспечения.
Лучше сравнить каскадный подход с инспекциями и итеративный подход,
и котором акцент делается на непрерывной интеграции и тестировании. Исполь-
зуя автоматизированное тестирование, в частности, анализ во время выполнения
288
Dial- i
(для тестирования производительности приложения и обнаружения утечек нам ।
hi), разработчики могут обнаруживать дефекты до того, как они закопан
разработку. Технология автоматизированного тестирования и применспи
непрерывной интеграции и тестирования позволяют выявлять и исправлять мш
гие дефекты меньшей ценой, чем это было бы сделано с помощью инспекции
Это не означает, что при использовании итеративного подхода инспекции и
нужны. Они все же полезны во многих ситуациях. Но концентрироваться их л и
па нужных вещах, например, согласованы ли требования со всеми заинтересш..ш
пыми лицами, выполняются ли проектные руководства (правильно ли пени и
зуются архитектурные механизмы), есть ли возможности для повторного пени и
зования. Однако большую часть классических инспекций проектной модели м.. ।
по автоматизировать при помощи соответствующих инструментов, в пропшш .
случае они будут обнаруживать дефекты, которые вполне могли бы быть паи >
пы разработчиками и тестировщиками с помощью менее дорогих методов ш
наличии должной! автоматизации.
В конце концов действительно важным будет вопрос, насколько хорош в и.,
код, а не насколько хороши побочные продукты создания программною о...
печения.
Заключение
При применении и внедрении RUP команды могут допустить pacnpocip.i..
ные ошибки. Основываясь на нашем опыте и опыте специалистов по экспих.и •
ции из компании Rational, приобретенном при работе с тысячами зака'.’1ш.-
в течение многих лет, мы делим ошибки на три группы.
• Ошибки при внедрении RUR
• Ошибки при управлении итеративной разработкой.
• Ошибки при проведении анализа, построении архитектуры, осуществлении пр
екгнрования, реализации и тестирования.
Умение обнаруживать такие ошибки и знание, как их избежать, пом..'-,
применять RUP более эффективно.
ЧАСТЬ IV
РУКОВОДСТВО ПО RATIONAL UNIFIED
PROCESS ДЛЯ РАЗЛИЧНЫХ РОЛЕЙ
III W. I
I ЛАВА 14
Руководство по RUP для менеджера
проекта
Вы - менеджер проекта и только начинаете применять RUP. Эта глава помп
/м-i вам понять свою роль в проекте, связанным с разработкой программно!и
оисспечения и использованием RUP. Мы определим роль менеджера проекта и ее
иыпмодействие с другими ролями. Мы познакомим вас с некоторыми главными
арк-фактами, которые менеджер проекта будет разрабатывать и применя ть. И на
гонец, мы дадим обзор некоторых ключевых задач RUP, в выполнении которьi\
s час гвуег менеджер проекта.
Миссия менеджера проекта
Ecu. много причин, по которым проект может потерпеть неудачу или привес
hi к появлению низкокачественного продукта. Многие из этих причин можно
<и>1и1сп1ггь техническими факторами, и мы часто очень быстро к этому приходим
1е\иология -- удобный и безымянный козел отпущения. Однако авторы и кон
оплаты, например Роджер Прессман (Roger Pressman), бывшие свидетелями
множества проектов, могут заявить: «Если бы можно было для каждого проем а
пронес ти расследование post mortem, весьма вероятно, что выявился бы стойкий
н-111 мот ив: слабо оказалось управление проектом»1.
I См Picssman 2001. р. 55. - Примеч. авт.
Руководство по RUP для менеджера проекта
291
Сложная роль
Если кому- то и нужно
полностью понимать
процесс разработки
программного обес-
печения, то это ме-
неджеру проекта.
«Персонал, продукт, процесс, проект - именно в таком
порядке» - так Роджер Прессман определяет обязаннос ти ме-
неджмента проекта.
• Персонал. Разработка программного обеспечения в высо-
кой степени связана с людьми и очень сильно зависит от
их навыков и координации их работы. Многие задачи ме-
неджера проекта вращаются вокруг людей и сконцен-
трированы в основном на команде разработчиков.
• Продукт. Ничего нельзя спланировать, исследовать или произвести, если цели
и границы создаваемого программного обеспечения четко не определены,
и хотя менеджер проекта и не определяет всех деталей требований, ваша роль
состоит в обеспечении того, чтобы цели были установлены и продвижение
оценивалось по этим целям. При этом необходимо интенсивное общение с за-
интересованными лицами, внешними по отношению к команде разработчиков,
а также с самой командой разработчиков.
• Процесс. Если кому-то и нужно полностью понимать процесс разработки про-
граммного обеспечения, то это менеджеру проекта. Менеджмент проекта - это
олицетворение процесса. Не будет разницы между наличием или отсутствием
RUP, если менеджер проекта не имеет технологической квалификации или не
направляет процесс. Процесс, поддерживаемый правильным набором инстру-
ментов-это общая дорожная карта, которую понимают и используют все члены
команды.
• Проект. И теперь, находясь на этой дороге, менеджер проекта управляет са-
мим проектом, планируя, контролируя, отслеживая и корректируя по мере не-
обходимости траекторию. Менеджер проекта - ведущий и направляющий.
Однако в самом конце менеджера программного проекта
не будут оценивать ни по затраченным усилиям, ни по благим
намерениям, ни по использованию правильного процесса, ни
по тому, что все было сделано «по книге», а только лишь по
результатам. Так что на всем протяжении жизненного цикла
На всем протяжении
жизненного цикла
проекта менеджер
должен концентриро-
ваться на резуль тэтах
менеджер проекта должен концентрироваться на результатах
или на промежуточных результатах, которые приближают проект к успеху.
Проект RUP - это совместный труд нескольких сторон, включая и менеджера
проекта. А в очень динамичном контексте итеративной разработки роль менед-
жера проекта больше «ведущая и направляющая», чем «планирующая и следя-
щая» (как это часто бывает в других областях).
10"
292
Глава l i
Поэтому роль менеджера проекта сложна и требует многих различных наны
ков, чтобы уметь вести и направлять.
• Технические навыки, чтобы понимать имеющиеся вопросы - технологии и при
нимаемые решения. Слишком часто нам приходилось сталкиваться с органы '..i
циями, в которых все еще считается, что менеджер проекта просто управляе, р,
сурсами (включая людские) и ему не нужно понимать продукт или процеы
Если вы - менеджер проекта, вам не нужно быть техническим эксперт,
во всем, а следует довериться нужным людям, которые помогут вам с технич,
ской стороны (см. гл. 16 ). Но хороший уровень знаний технических вопросом
все же необходим для достижения наилучших результатов.
• Коммуникативные навыки, чтобы иметь дело с множеством заинтересованны
лиц и иметь способность быстро переходить от одного стиля общения к дрс ю
му. Например, от личного общения (лицом к лицу, в беседе или на совещани
ях) к неличному (отчеты), от формального (аудиты и ревизии заказчика) к и
формальному («мозговые штурмы» в небольшой группе или просто обхо и.,
с целью проверки настроения).
Один человек или команда?
Весьма вероятно,
что в больших про-
ектах роль менед-
жера проекта могут
выполнять несколь-
ко человек.
Мы привыкли думать о менеджере проекта, как об одном челок,
ке, и в большинстве проектов от небольшого до среднего размер.,
(3-15 чел.) с этой ролью способен полностью справи т ,
и одиночка. Однако в RUP менеджер проекта описывается не ь.н
человек, а как роль, которую выполняет человек, и весьма
вероятно, что в больших проектах эту роль могут выполнять нс
сколько человек. Все же есть основания иметь в проекте одного четко выраженной'
лидера, но этот человек не должен чувствовать необходимость выполнять все ы
дачи RUP, относящиеся к дисциплине менеджмента проекта.
Во-первых, возможно наличие небольшой команды, выполняющей функции
менеджмента проекта. Один человек может сконцентрироваться на планиронл
нпи, другой заниматься ключевыми коммуникационными взаимодействиями
с менеджерами продукта и заказчиками, еще один может следить за внутренним
продвижением. Заметим, что некоторые их этих специализаций уже признаны
в RUP, в котором определяется более чем одна роль менеджера. Существуют рои,
со специализированными компетенциями, например менеджер по конфигурации
менеджер по развертыванию, менеджер по тестированию и инженер-технолог
Руководство по RUP для менеджера проекта 293
Кроме того, в более крупных организациях, занимающихся разработкой
программного обеспечения, состоящих, скажем, из 25 и более человек,
распространена практика разбиения их на небольшие команды, и лидер каждой
команды будет выполнять часть роли менеджера проекта, относящуюся к одной
команде. Иными словами, менеджер проекта передает часть своей работы другим
и получает «глаза и уши» по всему проекту.
И наконец, в больших проектах некоторым группам можно поручить роль
помощников менеджеру более формализовано, которые могут выполнять сле-
дующую часть задач по администрированию проекта:
• следить за продвижением проекта: группа рецензирования проекта (Project
Review Authority, PRA) и группа управления изменениями (Change Control
Board, ССВ);
• настраивать и совершенствовать процесс: группа процесса разработки (Soft-
ware Engineering Process Authority, SEPA, иногда также называемая SEPG);
• направлять определение и внедрение инструментов: группа среды разработки
(Software Engineering Environment Authority, SEEA).
Такие группы составляются из людей с нужной квалификацией, имеющих
авторитет работающих иногда, с полной занятостью. Они помогают группе
менеджеров по мере необходимости или когда это определяется процессом.
Управление проектом
«Управление проектом - это приложение знаний, навыков, инструментов и ме-
тодов к задачам проекта в целях удовлетворения и предвосхищения желаний
и ожидании заинтересованных лиц»2.
Удовлетворение и предвосхищение ожиданий непременно связано с балан-
11 сированием между конкурирующими требованиями, например:
j • границы, время, стоимость и качество;
j • заинтересованные лица, внешние и внутренние, имеющие разные нужды
j и ожидания;
j • выявленные требования (нужды) и невыявленные требования (ожидания).
f
|
s:
2. См. PMI 2000.
294
ГЛАНД I'I
Границы дисциплины «Управление проектом» в RUP
/У RUP сознательно
не охвачены все ас-
пекты управления
проектом, и акцент
делается на тех-
нических аспектах.
RUP сознательно нс охвачены все аспекты менеджмента проч
та и акцент делается на технических аспектах.
Несмотря на все то, что мы пишем о первом «П», Персона.к
дисциплина «Управление проектом» (Project Management!
в RUP не охватывает многие из аспектов работы по управлешп-
людьми, т.е. всего управления людскими ресурсами. Так чю
и КНР вы не найдете руководства о том, как нанимать, обучать, оплачивать раои
i n, оценивать и дисциплинировать людей.
Точно так же RUP нс имеет дела с финансовыми вопросами, такими к.,,
оюджет, ассигнования, бухгалтерия и отчеты. Не затрагивает он и юридически'
вопросы, контракты, вопросы приобретения и продажи, лицензирования и cv
подрядов. Кроме того, в RUP пет некоторых административных вопроси,
касающихся людей, финансов и проектов.
На эти темы по всему миру есть масса практических руководств и много ни
формации, не связанной с разработкой программного обеспечения.
Одним из великолепных источников информации является киша «Guide to th.
Project Management Body ofKnowledge» (PMBOK), созданная иод покровнтельс ,
пом Института проектного управления (Project Management Institute, PMIt
и одобренная 1EF.B в качестве стандарта 1990—1998 «Adoption of the PMI Guide to
РМВОК».
PUP же концентрируется на про, раммпо-епецпфнческих аспектах управления
проектом, то сеть на тех областях, на которые оказывает свое влияние природ.।
программного обеспечения, делая их отличными от прочих. Те задачи, которьк
в RUP не охвачены, занимают значительный объем времени и работы и требую,
определенных навыков. Поэтому их не следует упускать из виду при составлении
пиана работ для тех, кто управляет проектом.
План разработки программного обеспечения
Трудно свести управление проектом по разработке программного обеспечения
к нескольким рецептам, но давайте попробуем показать общую схему, то ecu.
хороший практ ический способ.
Вот наилучшие действия для менеджера проекта, которые мы пока выявили.
I Составлять планы проекта (т.е. формулировать ожидания, как они выглядя,
сточки зрения менеджера проекта) для рашых областей границ, времени
стоимости, качества, процесса.
Руководство по RUP для менеджера проекта
295
2. Понимать, что может негативно повлиять на эти планы со временем, то есть
каковы будут риски проекта, если планы не станут выполняться.
3. Следить за продвижением и за тем, насколько ход проекта соответствует
плану, используя где это возможно какие-либо объективные показатели.
4. Проводить пересмотр любого плана, если проект значительно отклоняется
от курса.
5. И наконец, учиться на своих ошибках, чтобы организация не повторила их
в следующей итерации или в следующем проекте.
Поэтому основным артефактом, на котором будет концентрироваться менеджер
проекта, будет План разработки программного обеспечения (Software Develop-
ment Plan), который представляет собой широкий артефакт, содержащий множество
различных планов, каждый из которых соответствует одному направлению деятель-
ности:
• План проекта и планы итераций (см. гл. 12).
• План тестирования.
• План управления конфигурациями.
• План проведения измерений.
• Риски.
• План составления документации.
• Конкретный процесс, который будет использоваться в проекте, то есть преце-
дент разработки.
Для большей ясности, видимости и отчетности План разработки программного
обеспечения может быть одним из немногих формальных артефактов в проекте.
По мере развертывания проекта эти планы уточняются, корректируются и со-
вершенствуются, как этого и можно ожидать в случае итеративной разработки,
а для обеспечения этого создаются и другие тактические артефакты. Обычно они
фиксируют состояние проекта, давая информацию для принятия необходимых
тактических решений:
• рецензии (протоколы);
• списки проблем;
• оценка состояния.
Одним из важных аспектов Плана разработки программного обеспечения
является более точное определение используемого в проекте процесса. Эго функ-
ция прецедента разработки (см. гл. 10, II). Менеджер проекта устанавливает
и поддерживает подходящий для данного проекта уровень формализованное™,
или «степень церемонности», как называет его Грейди Буч (Grady Boocli). Преце-
296
Главл i i
iciit разработки также будет совершенствоваться по мере выполнения простю
и.। основе опыта, приобщаемого в каждой итерации.
Итеративная разработка
’ )ю лейтмот ив данной книги, повторим еще раз. В итеративной разработке r.i 1
нс составляете план сразу и не стараетесь изо всех сил придерживаться сь'
попой ценой. Вы планируете азатем, если нужно, перепланируете, снова и chot..i
В конечном итоге вы можете прийти совсем к иному, чем намеревались в своем
камом первом плане, но вы оказываетесь в лучшем положении или в ситуации
попсе умеренной, но и более реалистичной, что лучше, чем вообще никуда н<
iipnii ги.
1'сли вам никогда не приходилось управлять итеративным проектом, поначалх
но может показаться устрашающим'’.
Риски
। ицнтть проектом -
:к.1чи1 быть всегда осве-
7< и 'иным и быстро реа-
шр in, нь на новые риски,
и, ыые события, ситуации
и и менения, которые мо-
। / нонпиять на проект.
Чтобы эффективно управлять итеративной разработкоп
начинающий менеджер проектов RUP должен освой и-
и постоянно держать в уме и вторую концепцию - конце!i
цию рисков. В реальности существует множество рискон
различной величины и вероятности, которые могут нов. ш
ять на проект по разработке программного обеспечения
Управление программным проектом - это не слепое приме
псине набора рецептов и шаблонов для создания высекаемых в камне всликолеп
пых планов и передачи их команде для исполнения. Управлять проектом -значп!
ni.nK всегда осведомленным и быстро реагировать на новые риски, новые собы
ны. ситуации и изменения, которые могут повлиять на проект. Успешный менел
<кср проекта - это тот, кто всегда присутствует, кто любопытен, кто общается
। членами команды, задает вопросы о tcxiio.toihh, спрашивает «почему» и «как-
и i нова «почему», выявляет новые, неожиданные риски, а потом применяет сот
иен.чнующие методы для их уменьшения.
('.м Ktuchten 2000b.
Руководство по RUP для менеджера проекта
297
Метрики
Еще одно ключевое слово менеджера RUP-проектов - это метрики (количествен-
ные показатели). Чтобы не оказаться в тупике из-за субьективпости, чтобы не засти-
лали глаза предубеждения, недостаток опыта и знаний, менеджер проекта устанавли-
вает объективные критерии для слежения (более пли менее автоматизированного)
за определенными аспектами проекта. Некоторые измерения можно проводит ь
на месте, что позволит вам следить за такими параметрами, как расходы, завершен-
ность (насколько готова функциональность), тестовый охват (насколько полно тес-
тирование) и число дефектов (выявленных и исправленных), а также тенденции из-
менения всего этого со временем. К другим полезным метрикам можно отнести изме-
нения со временем числа «отходов», объема переработок, «перетряхивания» требова-
ний. Это можно отслеживать с помощью хорошей системы управления
конфигурациями. Умный менеджер проекта постарается как можно больше автомати-
зировать сбор таких показателей, что высвободит время для задач, требующих боль-
шого вмешательства человека.
Именно метрики текущего и предыдущих проектов помогут команде
сформировать оценки, в частности оценки объема работ (см. гл. 12). Ответствен-
ность за эти оценки менеджер проекта разделяет вместе со всей остальной коман-
дой он, не может односторонне возлагать ее на команду.
Задачи менеджера проекта
Так что же конкретно должен делать менеджер проекта согласно RUP?
Вы обнаружите, что в RUP задачи группируются по темам.
• Задачи для начала нового проекта.
• Задачи для определения и совершенствования всех элементов плана разработ-
ки программного обеспечения.
• Задачи для обеспечения запуска, работы и завершения проекта, ([тазы или
итерации.
• Задачи для слежения за проектом.
Начало нового проекта
Основываясь на начальной! версии документа «Концепция», менеджер проекта
разрабатывает первое Экономическое обоснование (Business Case), которое
очерчивает границы проекта (а также его предполагаемую продолжительность
298
Глава 14
и сюимость) и потенциальную окупаемость. Концепция содержит список требо
ваннй, то есть того, чего вы хотите достигнуть. Экономическое обоснование
определяет главную причину выполнения данного программного проекта. Кои
цепцию и Экономическое обоснование нужно пересматривать много раз, прежде
чем проект можно будет утвердить и приступить к его выполнению. И никогда не
< чапает слишком рано для выявления рисков, то есть тех событий, которые Moryi
iiei атнвно повлиять на проект и вызвать его провал. Эти риски будут первым,
па чем должно концентрироваться внимание в следующей итерации.
Создание Плана разработки программного обеспечения
В зависимости от границ и размеров проекта менеджер проекта создает либо
весь Илан разработки программного обеспечения (ПРПО4), либо некоторые его
•чементы. Возможно, в организации уже созданы готовые к употреблению шаб
ионы, являющиеся более специфичными, чем те, которые можно найти в RUP, где
многие разделы уже заполнены.
В ПРПО есть две важные части:
• запланированные в плане проекта и в плане кадрового обеспечения (см. гл. 12)
время и ресурсы;
• определение процесса, который будет использоваться в данном проекте
разрабатываемые артефакты, уровень формализованное™, записанные в Пре-
цеденте разработки (см. гл. 10). Сюда входят и специфические руководства,
руководства по стилю и соглашения, которые будут применяться в данном
проекте.
Запуск и завершение фаз и итераций
Менеджер проекта более подробно планирует содержание и цели фаз
п шераций. указывая критерии успешности, используемые для оценки работы
и моменты заключительных вех (контрольных точек). Эти задачи потребую!
...снеивного взаимодействия со всеми членами команды и их нельзя выполнить,
i ичя в башне из слоновой кости. Каждая фаза и итерация должны иметь необхо-
шмое кадровое обеспечение, а задачи должны быть распределены по членам
команды.
4 Английская аббревиатура - SDP (Software Development Plan). - Примеч.пер.
Руководство по RUP для менеджера проекта
299
Когда итерация (или фаза с ее главной вехой) завершается, менеджер проем а
оценивает ее результаты и сравнивает их с ожидаемыми, указанными в IIPI1O.
Расхождения должны превести к пересмотру планов или изменению границ
проекта. Можно улучшить и сам процесс.
Например, глядя па ранее выявленный риск («Интеграция технологии X
с промежуточным программным обеспечением Y»), вы констатируете, что гем нс
менее вам удалось успешно проинтегрировать и протестировать прототип, убрав
таким образом данный риск.
Слежение за проектом
Менеджер проекта должен постоянно следить за продвижением работ, псполь
зуя какие-нибудь индикаторы и сравнивая результаты с планом. Эго можно де
лать с разной степенью формальности, применяя комбинацию метрик (например,
скорости обнаружения и исправления дефектов) и рецензирования (формальною
или неформального) и оценивая таким образом соответствие проекта план}
и качество продукта.
Например, если скорость обнаружения дефектов резко падает, то это сигнали-
зирует о том, что либо тестирование отстает, либо новые выпуски ие внесли ни-
каких существенных функций, либо продукт просто стал стабильным.
Оценку следует производить как минимум один раз за итерацию и несколько
более формально - по завершению фазы, поскольку в моменты главных вех
принимаются стратегические решения, касающиеся продолжения рабш
по проекту. Здесь вы можете отказаться от проекта или существенно изменить ею
границы.
Найдите свой путь в RUP
Чтобы начать работать в RUP, жизненно важно, чтобы менеджер проекта пол
ностыо понимал концепцию итеративной разработки и жизненный цикл RI
(фазы и итерации). Еще есть некоторые ключевые концепции: управление риска-
ми, качество, метрики, способ описания процесса (роли, задачи, артефакты). При
необходимости обращайтесь за разъяснениями к глоссарию RUP. Если вы знако-
мы с управлением проектом вообще, но не с итеративным проектом в част нос in,
больше всего вам следует обратить внимание па планирование, особенно
на планирование итеративною проекта (см. гл. 12).
300
Глава М
Вы можете входить в RUP-’ через роль менеджера проекта и работа,ь
с различными задачами, которые определяет эта роль. В качестве альтернативы
ны можете исходить от артефакта «План разработки программного обеспечения»
(его шаблона и некоторых примеров) и отсюда переходить к различным задачам
выполняемым для его разработки, или, что более точно, к задачам разработки
разнообразных планов, содержащихся в нем. Это приведет вас к более специали
шрованным ролям менеджера конфигураций (Change Control Manager), Менед
жера тестирования (Test Manager) и т.п.
В небольших проектах или в небольшой организации, занимающейся разрабо,
кой программного обеспечения, весьма вероятно, что тот, кто выполняет роль ме-
неджера проекта будет также и инженером-технологом, который определяет преце
ic-нг разработки проекта, помогает внедрять процесс и вовлекается в выполнение
<адач по совершенствованию процесса по результатам оценки итерации
(пли проекта), (см. гл. 10, II, роли инженера-технолога (Process Engineer).
Не забывайте, что менеджер проекта взаимодействует со многими другими
ролями и участвует в той или иной форме в выполнении их задач. В частности
менеджеру проекта нужно будет почти ежедневно взаимодействовать и коорди
пировать свою работу с архитектором (ами) и участвовать в разнообразных
рецензированиях.
Заключение
При следовании определенному процессу например, конкретной реализации
RHP, менеджеру проекта будет трудно отбросить ответственность и здравии
смысл. Данная работа - это не слепая разработка всех и каждого артефакта, они
санного в RUP, в надежде, что все получится правильно. Это не распределение
всех задач RUP по членам команды, чтобы потом говорить: «Я же просто следи
ван RUP! Я не понимаю, почему мы потерпели неудачу!» Помните, что вы дола,
ны выбрать из RUP нужный набор артефактов, нужные методы и техники и по
тш нать их под вашу ситуацию. Вы должны полностью понимать проем
и продукт и работать совместно с архитекторами, аналитиками, проектировщика
мн п тестировщиками.
'» Имеется в виду работа с Web сайтом RUP. - Примеч. науч. ред.
Руководство по RUP для менеджера проекта
301
Вас будут оценивать по конкретным результатам, а не по
применяемым методам. Ваша роль - направлять и постоянно
корректировать процесс по мере продвижения проекта и решать,
какие артефакты и задачи дают конкретные результаты. Для это-
го вам нужно глубоко окунуться в жизнь проекта с технической
Вас будут оцени-
вать по конкрет-
ным результатам,
а не по применяе-
мым методам.
точки зрения, быстро понимать, какие ключевые решения нужно принять, ухва-
тываться за возможности получить результаты быстрее, управлять границами
проекта, «размерами» процесса. Эффективно делать это можно только при совме-
стной работе, не разводя бюрократии и не создавая дистанции между менедж-
ментом проекта и остальной командой.
Помните также, что все управленческие задачи, не описанные в R.UP, тоже
очень важны. Вы управляете не машинами, вы управляете не режимами работы,
вы управляете людьми. Недост аточно просто обежать всех, рассказать, что делат ь
и указать на R.UP. Вы ставите цели и формируете культуру разработки программ-
ного обеспечения, культуру сотрудничества и доверия, а это делается путем тес-
ного и постоянного общения.
Обобщим сказанное.
• Менеджер проекта - не сторонний наблюдатель, а часть команды и работает
вместе с командой.
• Менеджер проекта отвечает за разработку и модификацию Плана разработки
программного обеспечения.
• План основывается на сконфигурированном процессе, настроенном на нужды
конкретного проекта.
• Менеджер проекта отвечает за формирование необходимых компромиссов
в управлении границами проекта и каждой из итераций.
• Менеджер проекта всегда сконцентрирован на рисках, любых рисках и на том.
как их снизить, если они встанут на пути успешного продвижения.
• Менеджер проекта концентрируется на реальных результатах, а не на проме-
жуточных и иногда абстрактных артефактах.
Ресурсы для менеджера проекта
Дополнительная литература
Murray Cantor. Software Leadership: A Guide to Successful Software Development.
Boston: Addison-Wesley, 2002.
302
Глава l-i
Tom Gilb. Principles of Software Engineering Management. Reading, MA: Addi
«m-Wesley, 1988.
.lames A. Highsmith. Adaptive Software Development: A Collaborative Approach
Managing Complex Systems. New York: Dorset House Publishing, 2000.
IEEE Standard 1490-1998. “Adoption of the PMI Guide to the Project Management
Body of Knowledge.” New York: IEEE, 1998.
IEEE Standard 1058-1998. “Standard for Software Project Management Plans
New York: IEEE, 1998.
Steve McConnell. Software Project Survival Guide. Redmond, WA: Microsoft Pres*.
I ‘>97.
Fergus O’Connell. How to Run Successful Projects. Upper Saddle River, NJ: Preu
ticc-Hall, 1994.
PMI. Guide to the Project Management Body of Knowledge (PMBOK Guide). Will
lain R. Duncan (editor). Newton Square, PA: Project Management Institute (PMI)
.’000.
Ресурсы WEB
I [осетите сайт Rational Edge (www.therationaledge.com) co статьями no менедл
мешу и в, частности, с яркими произведениями Joe Marasko о его опыте управления
программными проектами. Посмотрите раздел «Franklin’s Kit».
Посмотрите статью Philippe Kruchten «From Waterfall to Iterative Development
A lough Transition for Project Managers» в Rational Edge, Декабрь 2000 http
www.therationalcdge.com/content/dec_00/in _iterative.html.
Учебные ресурсы
Следующий учебный курс был разработан с целью поддержки пользователе и
Rl IP н поставляется компанией IBM Software и ее партнерами (более подробная
информация приводится на www.rational.com):
• Mastering the Management of Iterative Development (3 дня).
ГЛАВА 15
Руководство по RUP для аналитика
Вы - бизнес-аналитик, менеджер по продукту или кто-то еще, кто занимается
бизнес-моделированием, управлением требованиями или созданием прототипа
пользовательского интерфейса. В данной главе дается обзор обязанностей анали-
тика в проекте R.UP. Мы также расскажем о таких ресурсах, как обучающие
курсы и дополнительная литература, которые помогут вам усовершенствовать
свои навыки как аналитика.
Миссия аналитика
Как аналитик вы выполняете множество функций и вам
требуется широкий диапазон навыков. Главной вашей целью
является определение и донесение до всех заинтересованных
лиц того, что система должна делать. Эту цель можно разбить
па четыре высокоуровневые задачи.
• Понять желания пользователей.
Главной целью анали-
тика является опреде-
ление и донесение
до всех заинтересован-
ных лиц того, что сис-
тема должна делать.
• Понять желания других заинтересованных лиц.
• Документировать, расположить в порядке приоритета и донести требования
до всех.
• Согласовать требования и способствовать приему пользователем приложения.
Для выполнения этих задач обычно требуется следующее.
• Уметь осуществлять взаимодейс i вне с разными заинтересованными лицами.
• Хорошо понимать область проблемы пли быть способным быстро приобрести
эти знания.
304
Глав I
• Иметь великолепную коммуникабельность, способность ясно и четко излш .и ।
свои мысли как письменно, так и устно.
• Иметь способность написать точные и лаконичные требования.
• Иметь общее понимание жизненного цикла программного обеспечения и шы
какое место занимает в нем работа аналитика.
/>’ первую очередь аналитик
1'/, ютвует в таких дисципли-
нах RUP, как бизнес-моде-
лирование, требования
и анализ и проектирование.
В первую очередь аналитик участвует в таких дисцип nt
нах RUP, как бизнес-моделирование (Business Modeliir.'i
Требования (Requirements) и анализ и проектироваии.
(Analysis & Design). На рис. 15.1 показано, как меняю. ,
акцепт на этих дисциплинах в четырех фазах.
Фазы
Рабочие
процессы Начало Проектирование и Построение и Внедрение
Бизнес-моделирование |
Требования : -у -л
Анализ и проецирование
Реализация
Тестирование
Развертывание
Управление конфигурациями
и изменениями
Управление проектом
Среда
Начальная цПроегтир! ’ Пооапир.2 ? Псстаен.1 ТЬстроеи.2 ПссцхенМ Втйрш.?
- —......- --------- Итерации —................—....................
Рис. 15.1. Участие аналитика в жизненном цикле R.UP. В первую очередь аналит ик участвует в там,
дисциплинах RUP. как бизнес-моделирование, требования и анализ -и просктировяни.
Это означает, что он большую часть своей работы выполняет в (разах Начало и Flpoci
тированис. Аналитики т акже могут играть важную роль в (разах Построение и Внедрена.
Наибольший вклад аналитик вносит в фазах Начало и Проектирование, коны
определяются и стабилизируются требования. Аналитик отвечает здесь за ю
чтобы создавалось нужное приложение.
Руководство по RUP для аналитика
305
• В фазах Построение и Внедрение участие аналитика меньше, однако и у него
будет работа, связанная с уточнением требований и анализом последствий
любых изменений требований и бизнес-моделей.
С чего начинать?
Объем работы, требуемый для определения верной системы, варьируется
чрезвычайно широко. В зависимости оттого, какое влияние новые программные
системы будут иметь на ваш бизнес, анализ бизнес-процесса будет меняться от
работ по крупномасштабному перепроектированию бизнеса до небольшой иссле-
довательской работы. Ррассмотрим несколько различных ситуаций.
• Бизнес не очень понятен. Перед тем как разрабатывать
поддерживающее программное обеспечение, бизнес нужно
понять. Именно здесь приходится делать проектирование
бизнеса. Проектирование бизнеса - очень широкая об-
ласть, мы проведем обзор только небольшой ее части, на-
зываемой бизнес-моделированисм1. В разделе «Поймите,
как должен работать бизнес» вкратце описано бизнес-моделирование и то, как
перевести бизнес-модели в требования к программному обеспечению.
• Бизнес хорошо знаком. Большинство приложений разрабатывается для под-
держки существующего, хорошо знакомого бизнеса, (см. разделы «Поймите
желания заинтересованных лиц» и «Создайте Концепцию»).
Перед тем как разра-
батывать поддержи-
вающее программное
обеспечение, бизнес
нужно понять.
Поймите, как должен работать бизнес
RUP предлагает для проектирования бизнеса нотацию и процесс, очень сход-
ные с теми, которые используются в разработке программного обеспечения.
Такой подход значительно облегчает общение между командами, занятыми ана-
лизом бизнеса и разработкой программного обеспечения. Проектирование бизне-
са в первую очередь выполняется в больших проектах и организациях. Заметим,
что некоторые из его методов могут применяться и меньшими командами, по
с акцентом только на тех частях бизнеса, которые являются наиболее неясными
1. Подробно подход, используемый в RUP для бизнес-моделирования, описан в Jackobson 1994.
306
Гланд i
пли критичными для тех программных систем, которые вы планируете разртн.
гать. Информацию здесь можно фиксировать не столь формально, но процесс
Какие бизнес-про-
цессы требуются
/Via нужд заин-
юресованных лиц?
дет выглядеть так же.
Нужно понять, какие бизнес-процессы требуются для нужд заии
тересованпых лиц. Эти процессы отражаются в бизнес-прецсдсн
тах использования, в которых описываются услуги, которые н.ш
бизнес будет предоставлять заказчикам. Определение бизпт
прецедентов использования и способ их описания сходны с оиш
пнем прецедентов использования, применяемых для разработки программного
печения, за исключением того, что описываемая «система» представляет собой ш т
бизнес-действительность (бизнес-систему), а не только автоматизируемые ее част
Для примера, если ваш бизнес - торговля, то бизнес-прецсденты использования м-
। ут быть такими:
• предоставление информации об имеющихся продуктах. Позже это будез pc ,
лизовываться продавцами в магазине или через Web-сайт;
• прием и обработка заказа. Для поддержки данного бизнес-прецедента иыю и
зования может применяться множество различных программных прецедентов ш
пользования - от интернет-магазинов до информационных систем, помогаюпш
персоналу обычных магазинов.
Рабочий процесс бизнес-прецедента использования можно описать т.п
в текстовом виде в форме описания прецедента использования, так и с помоги в
визуальных средств, таких как диаграммы UML2 (рис. 15.2). Описывается iаки •
и реализация этих рабочих процессов в терминах взаимодействия ролей в opi .i
шпации при выполнении бизнес-процесса. Роли и продукты процесса предо ып
впотея в виде классов и объектов модели бизнес-объектов (рис. 15.3).
Вам также нужно определить приложения, необходимые для поддержки oio
нес-процессов. RUP предоставляет простой способ создания требований н,
программной системы по бизнес-прецеденту использования и по объектной М“
дели бизнеса3. Связь разработки программных функций с бизнес-процессами
которые они обслуживают, поможет вам понять значение различных cboikiu
программного обеспечения для бизнеса.
Понимание важности программных возможностей помогает расставпп
приоритеты в работе и с умом распределить ресурсы проекта для получения м.п
епмальной выгоды при построении программных систем. Именно эта обл.и и
часто упускается во многих подходах к проектированию бизнеса.
2 UML - Unified Modeling Language - Унифицированный язык моделирования. - Примеч. пер.
3 См. Руководства "Going from Business Models to Systems under Business Modeling" в RUP. - Примеч. авт.
Руководство по RUP для аналитика
307
Рис. 15.2. Модель бизнес-прецедснтов использования для производственной фирмы. Данная модель
показывает, какие бизнес-процессы (бизнес-прецеденты использования) для каких заказчи-
ков/деловых партнеров (бизнес-акторов) предоставляются
Рис. 15.3. Модель бизнес-прецедентов использования для производственной фирмы. Данная модель
показывает, какие бизнес-процессы (бизнес-прецеденты использования) для каких заказчи-
ков/дсловых партнеров (бизнес-акторов) предоставляются
308
Глава I'.
Поймите желания заинтересованных сторон
3 мнтересованное
ницо - это индивидуум
ипи группа, материаль-
но заинтересованные
н конечном результате
создания системы, на-
пример пользователь,
спонсор, покупатель или
менеджер продукта.
Заинтересованное лицо - это индивидуум или группа, мл
териально заинтересованные в конечном результате со ил
ния системы, например пользователь, спонсор, покупан и
или менеджер продукта. В фазе Сначало нужно собран
запросы от заинтересованных лиц и понять, каковы их пли
более существенные потребности. Собранные запросы мол
но рассматривать как «список потребностей», который
используется как первичная информация для определен!! ।
высокоуровневых свойств системы, как они описываю н ч
в Концепции и которые служат основой для создания более детальных требовл
iiiiii к программному обеспечению.
Вам следует создать небольшую команду заинтересованных лиц (скажем, ш
двух до пяти человек), которые будут представлять различные группы, заинтерсы>
ванные в результате проекта. Если эта команда будет слишком велика, вы будс»
гратить больше времени на управление ею, чем на понимание потребносп и
пирон. В то же время нужно удерживать равновесие. Если команда будет слишком
мала, вы можете не включить всех, кого затрагивают результаты проекта.
Список потребностей заинтересованных лиц можно составить либо путем п
сед, либо путем назначения и проведения двух- четырехчасового совещания с вы
шсу помянутой командой. На этом совещании обсудите, что должна делать сие и
ма, и задокументируйте запросы участников. Часто нужно направлять ход д1в
куесии, задавая наводящие вопросы типа: «С какими проблемами вы сейчас с ia i
кпваетесь в имеющейся системе?», «На какие задачи вы тратите в день болып.
всего времени?», «Какие из ваших текущих задач можно автоматизировать?»
Занеся запросы в документ, расположите их в порядке приоритета и oih>
шачьте, кто какой запрос сделал. Можно подумать о том, чтобы при учаспш
представительной группы заказчиков и пользователей прорецензировать резу 'и.
ни ы совещания на следующей встрече. На этой встрече выявите все вопросы, m
юрые нужно прояснить, и все задачи, которые нужно решить, и поручите эти ы
дачи персоналу.
Руководство по RUP для аналитика
309
Запросы заинтересованных лиц можно документировать Запросы заинтересо-
формально и неформально в зависимости от размеров и сложно- ванных лиц можно до-
сти проекта. В небольших проектах можно просто составить спи-
сок потребностей, который используется как основа для перво-
начальной работы над требованиями, а затем отбрасить. В более
кументировать
формально и не-
формально в зависи-
мости от размеров
крупных проектах, особенно, если в них задействуются контракт- и сложности проекта
ные соглашения, можно предпочесть работу с отдельным доку-
ментом Запрос заинтересованных лиц (Stakeholder Request).
Как уже упоминалось, сбор запросов заинтересованных лиц в первую очередь
осуществляется в фазе Начало, а в фазе Проектирование вносятся многочислен-
ные корректировки. Однако на всем протяжении работ над проектом вы будете
получать от заинтересованных сторон полезные запросы. Они документируются
в виде Запросов на изменения (Change Request) и должны постоянно рецен-
зироваться на предмет возможности их включения в проект.
Так же и при совершенствовании уже существующей системы: рецензирова-
ние запросов на изменения дает великолепные сведения о нуждах заинтересован-
ных лиц. Просмотрите все запросы на изменения и определите, какие из них мо-
iy г быть включены в следующую версию системы.
Создайте Концепцию
Концепция определяет представление заинтересованных лиц о разрабатываемом
продукте, выраженное в форме их основных потребностей и создающее дого-
ворную основу для более подробных технических требований. Наиболее сущест-
венные вещи, фиксируемые в Концепции таковы.
• Список заинтересованных лиц: заказчики, пользователи, инвесторы, менед-
жеры по продукту, проектировщики, тестировщики и др.
• Ограничения: бюджетные ограничения, список выбранных технологий,
операционных систем, необходимость сосуществования или совместимости с
имеющимися системами.
• Формулировка проблемы: четкое описание проблемы, которую вы пытае-
тесь решить (подробнее см. ниже).
• Список свойств: список услуг, предоставляемых системой пользователям
этой системы (подробнее см. ниже).
310
Глава lа
Как мы уже отмечали в главе 6. в очень малых проектах Концепция можо
|'ыть неформальным документом, возможно даже сообщением по электроники
почте, в котором фиксируется то, что записывалось на письменной доек,
В проектах среднего размера можно написать документ Концепция, состоящий и
нескольких страниц. В больших проектах может потребоваться очень обширпыи
юкумент Концепция. Рассмотрим подробнее его разделы:
Формулировка проблемы
Формулировка проблемы заставляет команду конкретно указать проблемх
Koiopyio нужно решить. Для этого можно использовать следующий формат.
Проблема <oiincarine проблемы>
{атрагивает -^заинтересованные лица, на которых влияет проблемам
Проблема приводит к <влияние, оказываемое данной проблсмой>.
Успешное решение проблемы привело бы к <список основных выпи
успешного решениях
Формулировка проблемы может выглядеть, например, следующим образом.
Проблема несвоевременного и неправильного решения задач службы по,
держки
затрагивает наших заказчиков, службу поддержки и техников служб.
Проблема приводит к неудовольствию заказчиков, устойчиво низком',
качеству, недовольству служащих, потере доходов.
Успешное решение проблемы привело бы к обеспечению доступа предо ы
вителей службы поддержки к базе данных по неисправностям в режим*
реального времени и к своевременной отправке техников только гуда, i ь
действительно требуется помощь.
Список свойств
Свойство - это услуга, предоставляемая системой, которая видна для ноль .и
1Ы1сля системы и напрямую удовлетворяет какую-либо потребность заинтерио
ванных лиц. Чтобы определить верный набор свойств, нужно проанализирован
’..тросы заинтересованных сторон и понять, как они могут помочь пола чин
преимущества, описанные в формулировке проблемы.
У каждого свойства должно быть:
• Краткое описание.
• Атрибут Значимость, показывающий, какое значение для бизнеса iiMeei ын
пос свойство (например, низкое, среднее или высокое).
Руководство по RUP для аналитика
311
• Атрибут Стоимость, показывающий, насколько сложной/дорогой будет реали-
зация данного свойства.
Глядя на признаки значимости и стоимости, вы сможете рас-
положить свойства в порядке приоритета. Можно, например,
выбрать пятибалльную шкалу приоритета (от 1 до 5). Обычная
ошибка в проектах - назначение Приоритета 1 практически всем
свойствам. Это делает расстановку приоритетов бессмыслен-
ной4. Чтобы избежать этого, вы можете насильно разделить
требования, чтобы не все они имели один и тот же уровень
приоритета. Существует много способов сделать это. Вот ти-
пичный подход к определению приоритетов.
Обычная ошибка
в проектах - назначе-
ние Приоритета /
практически всем
свойствам. Это делает
расстановку приори-
тетов бессмысленной.
• Представьте, что вам доступно только 50 или менее процентов ресурсов.
Назначьте наивысший приоритет, Приоритет 1, тем свойствам, которые, как
вы считаете, вы сможете разработать с этими ресурсами (конечно, это будет
гадание на кофейной гуще, но при сомнениях держитесь пессимистичной
точки зрения).
• Представьте, что вам доступно только 80% ресурсов. Назначьте Приоритет 2
следующему набору высокоприоритетных свойств, которые, как вы считаете, вы
сможете разработать с этими ресурсами.
• Представьте, что вам доступно 100% ресурсов. Назначьте Приоритет 3 сле-
дующему набору высокоприоритетных свойств, которые, как вы считаете, вы
сможете разработать с этими ресурсами.
• Назначьте оставшимся свойствам Приоритеты 4 и 5 (т.е., считайте их кандида-
тами в будущие проекты).
Расстановка приоритетов заставляет принимать неко-
торые предварительные, но жесткие решения, касающиеся
использования ресурсов. Если продвижение оказывается
медленнее, чем ожидалось вами, и, например, нужно
отбросить 20 процентов свойств, в нашем примере можно
отбросить все свойства с Приоритетом 3, перенеся их на бу-
дущие проекты. Список приоритетов будет многократно
пересматриваться и уточняться в ходе фаз Начало и Проек-
Расстановка приорите-
тов заставляет прини-
мать некоторые пред-
варительные, но жесткие
решения, касающиеся
использования ресурсов.
4. Нужно заметить, что в некоторых редких случаях, особенно во встроенных системах, все свойства
действительно должны иметь Приоритет 1, поскольку система просто не может быть выпущена без какого-либо из
указанных свойств. - Примеч. авт.
312
Глл! i
шрование. Этот список будет использоваться в фазах Построение и Внедрсни
дня принятия верных решений, если потребуется изменить границы проект пр
непредвиденных задержках.
Аналитик, как правило, предлагает первоначальную расстановку приоршс нч
рецензирует ее совместно с менеджером проекта, архитектором и командой занп
1ересованных лиц, а затем модифицирует список на основе получепно!.....
формации.
Разработка модели прецедентов использования и глоссария
Модель прецедентов использования описывает функциональные требон.шн .
системы в форме акторов и прецедентов использования. Актор (Actor) пре;к । н
пяет собой тип пользователя системы или другую систему, которая взаимодсн.
вуег с данной. Прецедент использования (Use Case) описывает, как каждый ак i-i
оудет взаимодействовать с системой.
Ниже приводятся 10 чрезвычайно полезных шагов - инструкция по создании
верной модели прецедентов использования.
Шаг 1. Выявить акторы.
Шаг 2. Выявить прецеденты использования.
Ш аг 3. Проделать шаги 1 и 2 снова и определить, нужны ли вам дополнит и
ные акторы для вновь выявленных прецедентов использования и наоборот.
Шаг 4. Написать один абзац описания для каждого актора и пару абзац. ,
л каждом из прецедентов использования.
Шаг 5. Выявить ключевые «предметы», с которыми работает сиенм,
и включить их в глоссарий или в модель предметной области. Модель предм. ,
ной области (domain model) - это часть бизнес-модели, показывающая ины.
наиболее важные понятия и их отношения (рис. 15.3).
Шаг 6. Убедиться, что в одном или более прецедентах использована>
содержатся действия по созданию, поддержанию и удалению каждого из «пр. ।
MCioB», с которыми работает система.
Шаг 7. Выявить наиболее существенные или критичные (архитекiу pm
(начимые) прецеденты использования (обычно, 20-30%).
Шаг 8. Описать самые существенные и критичные прецеденты ис пользе в. и и । >
। н>лее подробно.
Шаг 9. Проводить корректировку глоссария или модели предметной оба.к ш
и выполнять анализ важных понятий в ходе жизненного цикла.
РУКОВОДСТВО ПО RUP ДЛЯ АНАЛИТИКА
313
Шаг 10. Структурировать модель прецедентов использования.
В разделе «Широкое, но неглубокое описание требований» более подробно
расшифровываются шаги 1-7, в разделе «Подробное описание акторов и преце-
дентов использования» расписывается шаг 8, а в разделе «Уточнение модели»
описываются шаги 9 и 10.
Широкое, но неглубокое описание требований
В фазе Начало вы должны понять границы системы, не особо
вдаваясь в детали. Именно это мы называем «широким, но неглу-
боким» пониманием системы (см. также гл. 6). Делать это нужно
параллельно или чуть позже сбора запросов заинтересованных
пиц и создания документа Концепция.
В фазе Начало вы
должны понять
границы систе-
мы, не особо вда-
ваясь в детали.
Так как же создать такое широкое, но неглубокое описание? В небольших
проектах вы собираете вместе свою команду, заказчика и, может быть, других
внштересовапных лиц на «мозговой штурм», занимающий несколько часов.
I) более крупных проектах можно провести двухдневное совещание со всеми
основными заинтересованными лицами: менеджером проекта, архитектором, ве-
дущим разработчиком, заказчиком и несколькими аналитикками. На этом сове-
щании нужно пройтись по шагам 1-7 следующим образом.
Шаг 1. Проанализируйте свойства и запросы заинтересованных лиц и выявите как
можно больше акторов (помните, что к акторам относятся как пользователи, так
и внешние системы, с которыми взаимодействует данная система). Убедитесь, что ак-
к>ры представляют собой роли, а не должности и не конкретных людей. Каждый
конкретный человек, как правило, выполняет несколько ролей, а одну роль могут вы-
полнять несколько человек. Пишите описания акторов (длиной в одну фразу) по мере
их выявления. Не тратьте на это слишком много времени. К этому шагу вы будете
возвращаться неоднократно.
Шаг 2. Для каждого актора фиксируйте его взаимодействия и использование нм
системы в форме прецедентов использования. Прецедент использования - это услуга
или последовательность действий, представляющих определенную ценность для ак-
тора. Он должен иметь смысл сам по себе. Пишите описания прецедентов использо-
вания (длиной в одну фразу) по мере их выявления.
Шаг 3. Для каждого из прецедентов использования определяйте необходимость
взаимодействия с другими пользователями или системами. Этого можно добиться,
если вслух проговаривать то, что будет происходить при выполнении прецедента ис-
пользования. Таким образом вы можете определять дополнительных акторов.
Продолжайте перемещаться между обнаружением акторов и прецедентов использо-
314
Глава г,
П.1ННЯ до тех пор, пока не почувствуете, что модель стабилизировалась. Скорее bcch>
hi.। выявите 80% акторов и прецедентов использования за первые 20% потрачешки>
времени. Поэтому можно прервать процесс обнаружения, когда скорость выявлении
iKiopoB и прецедентов использования упадет. К этой модели вы еще вернетесь позли
I ’е '.упл аты будут выглядеть примерно так, как показано на рис. 15.4.
Шаг 4. Напишите по одному абзацу описания для каждого актора и несколько
.пнацсв - для каждого прецедента использования. Это можно сделать во время
i пениального перерыва, когда каждому участнику дается два часа на описание
> кажем, одного актора и двух-трех прецедентов использования. Соберите груши
и проверьте все описания. В этот момент вы скорее всего столкнетесь с интерст
ним явлением - притом: что все будут согласны с названиями прецедентов ш
пользования, у каждого будет своя интерпретация того, что за ними стоит, к
ncpi., когда есть действительные подробные описания, различия в интерпретаии
ч \ будут очевидны. В результате вам может потребоваться добавить еще неско и.
ко прецедентов использования в целях охвата всех требуемых функций.
Рис. 15.4. Общий обзор системы: акторы и прецеденты использования. В ходе «мозгового ппурм.1-
или совещания, посвященного прецедентам использования, запищите (на письменной дщм i
группы пользователей и системы, которые будут взаимодействовать с вашей системы»
(т.е. акторы), и услуги (прецеденты использования), которые ваша система будет прелой.ш
пять этим акторам
Система *
выписывания счетов i
РУКОВОДСТВО ПО RUP ДЛЯ АНАЛИТИКА
315
Шаг 5. Создайте Глоссарий, содержащий в себе основные «предметы»,
с которыми имеет дело приложение. Например, в приложении, связанном со
страхованием, определите такие предметы, как заявления, типы полисов и т.п.
Кроме того, добавьте общую терминологию, используемую в дайной предметной
области, которую команда или заинтересованные лица могут не знать. Этот глос-
сарий должен помочь всем участникам согласовать общую терминологию, по-
скольку часто это служит источником сбоев в общении и недопонимания.
Во многих системах может оказаться крайне полезно графически изобразить, ка-
ким образом одни понятия соотносятся с другими. Это можно осуществит ь путем
моделирования важных понятий в модели предметной области (рис. I5.3).
Модель предметной области позволяет зафиксировать более широкий объем ин-
формации о понятии, в частности о том, как это понятие соотносится с другими,
что позволит вам ответить на такие вопросы: «Какие бывают типы полисов и как
они соотносятся друг с другом?», «Может ли владелец полиса иметь любое ко-
личество полисов?», «Должно ли заявление быть связанным с полисом?» Модель
предметной области может использоваться для того, чтобы каждый смог понять,
какая ключевая информация записывается для каждого полиса. Некоторый
формализм в ключевых понятиях, особенно в случае сложных систем, значитель-
но ускоряет определение требований. Заметим, что иногда бывает полезно вы-
полнить этот шаг перед Шагом I.
Шаг 6. Проверьте глоссарий или модель предметной области и убедитесь, что
для каждого ключевого «предмета» существуют прецеденты использования, описы-
вающие то, каким образом эти «предметы» создаются, поддерживаются
и удаляются. Есть ли у вас прецедент использования, определяющий, как выписыва-
ется полис? Как в полис вносятся изменения? Как осуществляется отказ от полиса9
Это отличный способ выявить «дыры» в модели прецедентов использования.
Шаг 7. На этом этапе вам нужно выявить наиболее существенные или
критические прецеденты использования (до 20% от общего их числа).
В некоторых системах суть системы может концентрироваться в одном-двух
прецедентах использования, а большая часть оставшихся являются лишь вспомо-
гательными. Если это так, то критичной и существенной окажется меньшая доля
прецедентов использования. Данную задачу обычно выполняет архитектор, по
аналитик также должен в этом участвовать (подробнее см. гл. 6 раздел «Цель 2.
Выяснить ключевые функции системы»).
316
Гллнл г
Подробное описание акторов и прецедентов использования
Л’ фазе Проектирование
заканчивается описание
п/юцедентов использова-
ния, начатое в фазе Нача-
ло, и подробно описыва-
йся большинство прочих
прецедентов.
Шаг 8. Для наиболее существенных и критичных преце.к н
тов использования выполняйте этот шаг в фазе Начало. (> i
нако большая часть этой задачи выполняется в фазе Прш ।
тирование, когда завершается описание прецедентов и-
пользования, начатое в фазе Начало, и подробно описывав ।
ся большинство прочих прецедентов. Можно описать и ш
завершить небольшую часть прецедентов использования и
в фазе Построение (подробнее см. гл. 8 раздел «Опиши,
ошавшиеся Прецеденты использования и прочие требования»).
Важно понимать, что прецедент использования содержит в себе множество ин
париев. Например, прецедент использования «перевод средств» может позволял
переводить средства с чекового, депозитного или брокерского счета на чековый, в
позитный или брокерский счет. Так что существует девять возможных комбинации
перевода. Каждый из этих девяти переводов может иметь любое число резулыакы
в юм числе, успех или недостаток средств. Так же можез' существовать некоторым
набор ошибок, например «Невозможность соединения с сервером», и альтерната
пых последовательностей событий, например «Получение счета в другом баны
(с потенциальной возможностью переключиться на другой прецедент использова
пня - «Телеграфный перевод»).
Обычно создание чернового варианта самых существенных и типичных сш
париев прецеденза использования занимает всего несколько часов. Для большнп
ста систем такой черновик занимает одну-две страницы. Значительно больпт
времени требуется на завершение прецедента использования с подробным опт а
пнем всех его сценариев. Подробное описание прецедента использования, к.и
правило, занимает от двух до шести страниц, но для систем со сложными пос в
юна вольностями событий, например телекоммуникационных систем, оно мо/ы ।
оыгь значительно больше, а для систем с ограниченным числом последовал с и
постой событий и небольшим числом бизнес-правил (например, просмотр, по и
и(менение) короче. В небольших проектах, где анализ и проектирование прец.
чепгов использования выполняет один и тот же человек, или при построении
приложений, где обслуживание не считается важной задачей, можно не докумсп
। кровать для экономии времени все возможные сценарии.
/ Уководства по описанию прецедентов использования
Вот некоторые инструкции, которые при описании прецедентов использова
пня могут оказаться вам полезными:
Руководство по RUP для аналитика
317
• Выявите в цепи событий те этапы (рис. 15.5), которые можно считать самым
простым сценарием или сценарием основного хода событий, т.е. ту ситуацию,
когда все идет как ожидалось, (в приведенном выше примере это перевод
средств с чекового на депозитный счет при достаточных средствах).
• Опишите каждый из этапов данного сценария.
• Выявите для каждого из этих этапов, все возможные места ошибок или отклоне-
ний от сценария основного хода событий. Задокументируйте эти альтернатив-
ные пути развития событий таким образом: «если XX, тогда YY» (в форме
структуры подпунктов под соответствующими этапами).
• Продолжайте подробно описывать альтернативные пути развития событий.
Если альтернативный путь начинает занимать больше абзаца, вынесите его
в отдельный раздел в конце описания прецедента использования и сделайте на
него ссылку из того этапа, где он изначально был описан. Такая реструктури-
зация позволит легко выделить основной ход событий, поскольку иначе описа-
ние прецедента использования разбилось бы на слишком большое число длин-
ных параллельных потоков.
• Если в вашем проекте много бизнес-правил, определите их вне прецедента ис-
пользования, как это делалось в глоссарии. Если вы используете средства от
компании Rational, вы можете, например, создать тип требований под названи-
ем Business Rule (бизнес-правило). В описании прецедента использования
дайте ссылку на применимый к данному случаю раздел бизнес-правил. Такой
способ работы с бизнес-правилами особенно хорош, если обращение к одним
и тем же бизнес-правилам осуществляется из многих разных прецедентов ис-
пользования.
• Добавьте пред- и постусловия, то есть укажите, чем начинается и чем заканчи-
вается прецедент использования. Предусловие - это состояние системы, ко-
торое необходимо получить перед тем, как запустить прецедент использова-
ния. Постусловие - это состояние системы после завершения прецедента ис-
пользования 5.
Заметим, что для многих систем описания прецедентов ис-
пользования должны дополняться прототипом пользователь-
ского интерфейса (см. ниже раздел «Разработка прототипов
пользовательского интерфейса»).
Нужно сделать еще одно важное предупреждение: всегда
помните о «духе RUP», особенно о «Концентрации на исполняе-
Для многих систем
описания прецеден-
тов использования
должны дополняться
прототипом пользова-
тельского интерфейса.
5. См. Bittner 2003 и Cockbum 2001. - Примеч. авт.
318
Глава l'.
мой программе» (см. гл. 2). Легко слишком уж увлечься совершенствованием трсч».
наний. Мы наблюдали неудачи многих проектов, вызванные тем, что весь акцент т
палея на академические дискуссии о том, как документировать требования, a ш
на документировании требований достаточно хороших для успешной реализации
и тестирования системы. Вам как аналитику нужно работать в тесном контакт
с разработчиком, проектирующим и реализующим прецедент использована
(обе эти роли может выполнять даже один человек). Поработайте вместе с этим ш
донском и поймите, как нужно оптимизировать требования, (см. также гл. в разде ।
«Опишите оставшиеся Прецеденты использования и прочие требования»).
Начало прецедента использования
Альтернативный
ход событий 3
Альтернативный
ход событий 4
Альтернативный
ход событий 1
Основной
ход событий
Альтернативный
ход событий 2
Конец прецедента
использования
Конец прецедента
использования
Конец прецедента
использования
Рис. 15.5. Структура потоков событий. Типичная структура потоков событий: прямая стрелка <>iip.
деляет основной ход событий, а искривленные стрелки - альтернативные по othohiciihi-
к «нормальному» потоку. Некоторые альтернативные потоки событий возвращаются к
новному, тогда как другие завершают прецедент использования. Сценарий представ нп
собой комбинацию основного и альтернативных потоков от начала до завершения преп.
депта использования
РУКОВОДСТВО ПО RUP ДЛЯ АНАЛИТИКА
319
Пример: спецификация прецедента использования для записи на курсы
Спецификация прецедента использования подробно расписывает последователь-
ность событий в прецеденте использования, не затрагивая деталей реализации, та-
ких как планирование и точный способ представления информации, или то, как
функциональность должна быть реализована. Спецификация должна быть понятна
пользователям и давать достаточно информации для разработчиков, реализующих
прецедент использования.
Уточнение моделей
К концу фазы Начало, а иногда и в более поздние фазы, будет неплохо
потратить какое-то время на внесение изменений в модель прецедентов исполь-
зования и глоссарий.
Шаг 9. Параллельно с созданием подробных описаний прецедентов использова-
ния обновляйте глоссарий или модель предметной области. Хороший глоссарий
спасет вас от многих огорчений впоследствии и ускорит написание прецедентов ис-
пользования. Встречались ли вы при написании прецедентов использования с важ-
ными понятиями, которые необходимо добавить в глоссарий? Ссылаются ли ваши
прецеденты использования на нужные элементы глоссария или объекты модели
предметной области, или уже определенные понятия изобретаются заново?
При работе с глоссарием/моделью предметной области следует также поду-
мать о том, чтобы еще раз вернуться к Шагу 6. Пройдитесь по жизненному циклу
всех выявленных новых понятий и убедитесь, что у вас имеются прецеденты ис-
пользования, которые позволяют создавать, поддерживать и удалять эти понятия.
Шаг 10. Вы можете структурировать модель прецедентов использования пу-
1см создания связей между акторами и прецедентами использования, как,
например, наследование между акторами и включения, расширения или обобще-
ния между прецедентами использования. Наш первый совет - использовать эти
конструкции только в том случае, если вы являетесь экспертом по моделям
прецедентов использования. Мы видим, что эти конструкции чаще всего исполь-
зуются неверно, а вы можете создать великолепные системы и без них.
Если вы заинтересованы в их использовании, мы рекомендуем вам подождать
до фазы Проектирование или по крайней мере до самого конца фазы Начало. Так-
же мы советуем не использовать отношения, если для этого нет убедительных
Глава is
Система записи на курсы
К раткое описание
1..ИШЫЙ прецедент использования позволяет Студенту записаться на предлагаемый курс на текущий
> ‘ । р. Также Студент может изменить свой выбор или отказаться от него, если изменения производятся и
пт определенного периода в начале семестра. Система каталога курсов предоставляет список всех
। mi немых на текущий семестр курсов.
I 1.ПИ1ЫЙ актор данного прецедента использования - Студент. Система каталога курсов представляй i
"п акгора в пределах данного прецедента использования.
Ход событий
11рсисдент использования начинается, когда Студент выбирает Запись на курсы.
М. Основной ход событий
1. Студент выбирает Запись на курсы.
2. Система отображает нустон бланк расписания.
3. Система получает список предлагаемых курсов от Системы каталога курсов.
4. Студень выбирает одни или более основных и альтернативных курсов из списка предложен*
пых. Пользователь в любой момент может добавить или удалить пункт из списка выбранных
курсов. Сделав свой выбор. Студент подтверждает его.
5. По каждому из выбранных курсов система проверяет наличие необходимых предварительных
условий и заполненность курса:
а), если все предварительные условия у данного Студента соблюдены, и курс еще не заполнен, система
записывает Студента на данный курс, В расписании курс помечается как «посещаемый»..
Ь). если предварительные условия нс соблюдены или если курс уже заполнен, отображается сообщение
об ошибке. Студент может либо выбрать другой предлагаемый курс, или отказаться от операции В но
следнем случае прсцедеп) использования перезапускается.
6. Система сохраняет расписание.
V2.Альтернативные потоки событий
2.2.1. Изменение записей на курсы.
I, Студент выбирает изменение текущего расписания посещаемых курсов
2. Система получает и отображает текущее расписание для данного Студента (расписание на текущий се
местр).
3. Система получает список предла»аемых курсов от Системы каталога курсов. Список демонстрируем
Студенту
4 Студент может изменить выбранные курсы путем удаления имеющихся или добавления новых курсов
Студент выбирает добавляемые курсы из списка предлагаемых. Также Студент может удалить любые
курсы из имеющеюся расписания По завершению редактирования Студент подтверждает свои правки
показывая, таким образом, завершение процесса выбора курсов
5. Для каждого из выбранных курсов выполняется подпункт 2.1.5
6. Система сохраняе! расписание.
2.2.2. Удаление записей на курсы.
I. Студент выбирает удаление расписания
2.. Система получает и огображаепекушее расписание для данного Студента,
3 . Студент выбирает удаление расписания,
4 Система предлагает Студенту' подтвердить удаление
5 , Студент подтверждает удаление,
6 Система удаляет расписание.
2.2.3. Сохранение расписания.
।; nttuoii момент Студент может выбрать сохранение расписания без ею подтверждения. Сохраняется текущее распи
• ни ('каши не занисывасюя пи на один из выбранных курсов В сю расписании курсы помечаются как «выбран
Руководство по RUP для аналитика
321
предлогов. Если сомневаетесь, выбирайте простые решения. После реструк-
туризации модели прецедентов использования вам нужно будет пересмотреть все
описания всех прецедентов использования.
Разработка прототипов пользовательского интерфейса
Аналитики либо сами разрабатывают прототипы пользовательского интерфей-
са, либо работают в тесном контакте с теми, кто этим занимается. Разрабатывас
мые прототипы пользовательского интерфейса (User Interface, U1) можно раздс
лить на две основные группы: концептуальные прототипы и раскадровки, или
прототипы прецедентов использования.
• Концептуальный прототип. В фазе Начало параллельно с разработкой Конце))
ции, описанием наиболее существенных прецедентов использования и созла
нием экономического обоснования для системы нужно разработать концеиы
альный прототип, визуализирующий и демонстрирующий ключевые конце, i
ции и возможности, которые позволят заинтересованным лицам лучше ионян.
создаваемую систему. Часто концептуальные прототипы содержат не только
прототипы пользовательских интерфейсов, но также и некоторые базовые
функции.
Прототип должен отвечать на такие вопросы, как: «Предлагаете ли вы новый
для пользователей принцип?», «Какие возможности будет предоставляй,
приложение?», «Для каких типов пользователей предназначено данное прнло
жение?», «Каковы возможные функции наиболее критичных прецедентов ис-
пользования?»
Ответы или потенциальные ответы на все эти вопросы облегчат приняшс
крупного] решения, которое предстоит в конце фазы Начало: нужно ли
разрабатывать задуманный продукт?
• Раскадровка прецедентов использования, или прототип прецедента использо
вания. В конце фазы Начало, на протяжении фазы Проектирование и в начале
фазы Построение вам нужно разрабатывать параллельно с описаниями прецс
деитов использования прототипы прецедентов использования, которые позво
лят лучше понять прецеденты использования. Временные затраты на эю
значительно варьируют в зависимости от приложения.
11-863
322
Глава i'>
Разработка раскадровок, или прототипов прецедентов использования
Для приложений технического плана с сильным акцентом на последовательное i я
событий и взаимодействиях с другими системами можно создать раскадровку прет
тентов использования только для некоторых ключевых прецедентов с целью показа 11
несколько различных изображений.
Для приложений, ориентированных на работу с базами данных типа «Создан.
Прочитать, Изменить, Удалить», нужно попробовать сделать прототипы пользоиа
юльского интерфейса для каждого прецедента использования, не так много, чк"н.1
уменьшать риски, связанные с UI, но столько, сколько нужно для повышения точ1ю
с in и скорости создания описаний прецедентов использования (см. Шаг 8). Принс
.чимая ниже процедура успешно применяется для ускорения разработки прецеден ню
использования при усилении обратной связи с пользователями и заказчиками.
I. Сделайте одного человека (проектировщика UI) ответственным за прототипы
UI, чтобы обеспечить согласованность прецедентов использования. В бон
ших проектах, при наличии более пяти восьми аналитиков, может потрсос
ватьея и более чем один проектировщик UI.
.’. Когда аналитик создал первый вариант описания прецедента использовали я
просмотрите его совместно с проектировщиком UI. Прикиньте вместе, как) ю
информацию нужно будет выводить и какие окна нужно отображать. Почт,
проектировщик UI может объединить или разделить некоторые окна, исхо п
из их размера, так что пока не слишком обращайте внимание на детали
Проведение такой работы позволит аналитику раньше организовать важную
обратную связь по данному прецеденту использования. Скорее всего, вы
обнаружите несоответствия в составе информации в прецедентах использоы
ния, а также в потоках событий.
» Проектировщик UI создает модели окон. Это можно быстро осуществи и
с помощью средства построения пользовательского интерфейса из используе
мой вами Интегрированной среды разработки. Это даст разработчикам
отправную точку для проектирования, реализации и тестирования прецеденion
использования. Не помещайте в эти окна никакой логики, просто распечатан и
пх для проведения последующих рецензирований. Параллельно аналитик пн
дает описания прецедентов использования.
•I Проектировщик UI и аналитик просматривают скриншоты и с их помощью
проходятся по прецеденту использования. При обнаружении упущении
и несоответствий в скриншоты и описания прецедентов использования шю
сятся корректировки.
Руководство по RUP для аналитика
323
5. Аналитик на встрече с пользователями и/или заказчиками проходится по
прецеденту использования. Обзор оформляется в виде раскадровки, где
скриншоты используются как пояснения к потокам событий. Часто полезно
оставить материал на сайте на один-два дня после встречи, чтобы можно
было провести более тщательный анализ.
6. Внесите изменения по полученным результатам в прецеденты использования
и скриншоты.
Как правило, такой подход дает следующие преимущества:
• повышается согласованность пользовательского интерфейса;
• ускоряется завершение описания прецедентов использования;
• совершенствуется обратная связь с пользователями;
• ускоряются проектирование, реализация и тестирование прецедентов исполь-
зования.
Нужно заметить, что существует очевидный риск, что пользователи, проек-
тировщик UI и аналитики займутся поисками совершенных прототипов UI, что
приведет к аналитическому параличу. Вашей целью не является создание за-
вершенного пользовательского интерфейса. Ваша цель - получить пользователь-
ский интерфейс, достаточно хороший, чтобы он помог вам, совместно с пользова-
телями решить, что система должна делать. Это позволит вам быстрее завершить
прецеденты использования.
В проектах с очень сильным акцентом на проектирование поведения пользовате-
лей (User Experience?) можно решиться на формальное моделирование пользователь-
ского интерфейса с помощью моделей UML. Это делается через представление окон
с помощью классов аналитической модели со специальными стереотипами, которые
позволяют показать взаимодействия между пользователями (акторами) и окнами на
диаграммах UML, например диаграммах последовательностей. (Более подробно это
описывается в Плагине The User-Experience Modeling Plug-In for the RUP, который
можно найти в Rational Developer Network, а также в Conallen 2000.)
Фиксирование нефункциональных требований
Нефункциональные требования, как правило, оказывают значительное влияние
и на архитектуру, н на удовлетворенность пользователя. Такие требования могут,
однако, не указываться пользователями и заинтересованными сторонами так же явно,
как функциональные требования. Это значит, что аналитику нужно выявлять, доку-
ментировать и утверждать нефункциональные требования, например:
1 -I •
324
Глава l г
• атрибуты качества, включающие требования к удобству использования, надеж
ности, производительности и поддержке;
• юридические и инструктивные требования и стандарты приложений;
прочие требования, такие как требования к операционным системам и окр\
жению, совместимость и проектные ограничения.
Iлавной целью фазы Проектиро- Нефункциональные требования фиксируются главным
ваннеявляется проверка того, образом в фазе Начало и на ранних этапах фазы Прост
сможете ли вы обеспечить вы- тирование, но на протяжении проекта они moi с i
/кишениемногихнефункцио- пересматриваться. Они документируются в артефакте ИНГ
ымьных требований, такихкак п названием Дополнительные спецификации (Supplemcn
/ребования к удобству истюльзо- г ,
нания, производительности и т.п. tar? Specification). Нужно заметить, что главной целью фазы
Проектирование является проверка того, сможете ли вы
обеспечить выполнение многих нефункциональных требований, таких как требова
пня к удобству использования, надежности, производительности, к операционным
системам, окружению и совместимости с другими системами.
Обновление и уточнение требований
При итеративной разработке требования развиваются поэтапно. Больным
часть работы по определению требований выполняется в фазах Начало и Проск
шрование. Как уже упоминалось в разделе «Опишите оставшиеся Прецедешы
использования и прочие требования» (гл. 8), некоторые не очень критичные
прецеденты использования впервые описываются в фазе Построение. Однако
нужно заметить, что при проектировании, реализации и тестировании различных
прецедентов использования, при предъявлении системы пользователям, при вы
большем знакомстве с предметной областью и реализуемыми решениями вам
но требуется постоянно уточнять требования.
Современные системы слишком сложны, чтобы можно было сразу описать п\
верно. Вот почему нужно быть открытым к разумным модификациям требовании
в (разах Начало и Проектирование. Крупные модификации («Вы меняете границы
или концепцию проекта?», «Вам нужно это?») нужно тщательно обдумыван.
н обсуждать.
Но мере того как вы делаете вложения в проектирование, реализацию
и1сстирование системы, а дата выпуска продукта становится все ближе, вам
нужно более осторожно вносить изменения в требования. Нужно тщателыю
обдумать вклад каждого изменения с точки зрения риска, стоимости, сроков
и ресурсов в сравнении с той пользой, которую данное изменение принесо
Руководство по RUP для аналитика 325
Во многих случаях нужно будет сказать: «Эго отличное предложение, и мы
абсолютно точно подумаем о его реализации в следующей версии системы».
Но если заказчик настаивает, вам следует дать ему понять, какова будет стои-
мость этого изменения, и позволить решить - урезать или расширять границы
проекта. Однако во многих проектах решения о позволительности внесения изме-
нений в требования на поздних стадиях проекта принимает группа управления
изменениями (Change Control Board) или менеджер проекта. Аналитики также
должны понимать общий подход к изменениям требований, чтобы иметь возмож-
ность нацелить людей на принятие верного решения.
Обеспечить выпуск и тестирование требований
В фазе Внедрение, последней из четырех фаз жизненного цикла RUP, вы
передаете продукт пользователю в рабочую среду. Одним из этапов этого раз-
вертывания является приемочное тестирование, которое проверяет готовность
программного обеспечения и возможность его применения пользователями для
решения тех задач, для которых оно предназначено. Приемочное тестирование
продукта - это часто не просто запуск программы для проверки готовности.
Сюда входят также все передаваемые заказчику артефакты, такие как учебные
материалы, документация и упаковка.
Отвечает за приемочное тестирование тестировщик, но аналитик должен ак-
тивно привлекаться к этому процессу, чтобы обеспечить выполнение требований
пользователя и должное тестирование.
Роль аналитика в Rational Unified Process
RUP дает более детальное изображение роли аналитика, описывая более спе-
циализированные роли.
• Системный аналитик
• Бизнес-проектировщик
• Рецензент бизнес-моделей
• Аналитик бизнес-процесса
• Рецензент требований
• Разработчик требований
• Аналитик тестов
• Проектировщик пользовательского интерфейса
326
Глава 1!>
В этой главе мы охватили все эти специализированные роли, за исключением
Аналитика тестов, в одной супер-роли аналитика. Также нужно заметить, что в<>
многих организациях можно подумать о том, чтобы отнести задачи проектировщи
м пользовательского интерфейса к компетенции разработчика, а не аналитика.
Ресурсы для аналитика
Ниже приведены некоторые ресурсы для аналитиков, которые хотят лучше по
нить, как вести работу в RUP-проекте.
Дополнительная литература
Kurt Bittner and Ian Spence. Use Case Modeling. Boston: Addison-Wesley, 2003.
Alistair Cockburn. Writing Effective Use Cases. Boston: Addison-Wesley, 2001.
Ivar Jacobson, Maria Ericsson, and Agneta Jacobson. The Object Advantage: Busi
ness Process Reengineering with Object Technology. Reading, MA: Addison-Weslex
1994.
Philippe Kruchten. The Rational Unified Process: An Introduction, Second Edition
Boston: Addison-Wesley, 2000.
Dean Leffingwell and Don Widrig. Managing Software Requirements: A Unifies
\pproach. Boston: Addison-Wesley, 2000.
Образовательные ресурсы
Ниже приведены учебные курсы, разработанныедля поддержки пользователе,,
RUP. Созданы они компанией IBM Software и ее партнерами (подробнее см
л ww.rational.com).
• Principles of the Rational Unified Process: Web-based training.
• Essentials of the Rational Unified Process (два дня).
• Principles of Use-Case Modeling with UML: Web-based training.
• Mastering Requirements Management with Use Cases (два дня).
ГЛАВА 16
Руководство по RUP для архитектора
Вы - архитектор программного обеспечения и собираетесь начать применять
RUP. Эта глава поможет вам понять свою роль в проекте, связанном с разработ-
кой программного обеспечения и использованием RUP. Вы найдете здесь опреде-
ление роли архитектора и ее взаимодействия с другими ролями. Мы дадим
определение архитектуры и познакомим вас с некоторыми главными артефакта-
ми, которые архитектор может разрабатывать. И наконец, мы дадим обзор неко-
торых ключевых задач RUP, в выполнении которых участвуют архитекторы.
Миссия архитектора
Архитектор программного обеспечения направляет
и координирует решение технических задач и разработку
артефактов во всем проекте, а также координирует приня-
тие ряда ключевых проектных решений, касающихся тех-
нологий, структуры и организации программной системы.
В противоположность другим ролям, определяемым
в RUP, взгляд архитектора более широк, нежели глубок.
Архитек гор программного
обеспечения направляет
и координирует решение iex-
нических задач и разработку
артефактов во всем проекте.
328
Гло и
На все руки мастер
Как можно охарактеризовать идеального архитектора? Приблизительно в 25 >
ю и.), римский архитектор Витрувий написал: «Идеальный архитектор ди ।
ui.in, литератором н математиком, быть знакомым с историческими иа>г., и
прилежно учиться философии, знать музыку, не быть невежей в медицине. ......
|р;)мотным в вопросах права, быть знакомым с астрономией и астроиомичсы « >
вычислениями». Какова задача?!
I/ липекюр программно-
/ < > < Юеспечения должен
решать пробле-
мой поносить грамотные
а/ чнические суждения
при оюугствии полной
информации.
Точно так же и архитектор программного обеспечения д« ш
быть широко образован, обладать зрелостью, видением и i ।
боким опытом, который позволит быстро решать нро'и
и выносить грамотные критические суждения при отс\ о и ш
полной информации. Если более конкретно, то apxuici ;
программного обеспечения или члены команды архтсм, ;
должны обладать следующими качествами.
• Опыт, как в предметной области (приобретенный путем тщательного авали u t;
бовапий), так и в области разработки программного обеспечения. Если > -
команда архитекторов, то эти качества могут быть распределены среди ч ш
команды, но хотя бы один архитектор должен обеспечивать глобальное видит
проекта. Архитектор программного обеспечения должен знать ociohu
имеющиеся технологии или имет ь возможность быстро приобрест и такие зн.иш ,
• Лидерство необходимое для того чтобы направлять техническую работу в ра .ш ।
командах, принимать под давлением критики решения и заст авлять выполняи. , ,
решения. Чтобы работа была эффективной, архитектор и менеджер проект а г и
ни работать в тесном контакте, при этом архитектор руководит решением ।
иических вопросов, а менеджер проекта руководит решением деловых и админе
противных задач.
- Коммуникабельность необходима, чтобы завоевывать доверие, убежми
стимулировать и наставлять. Архитектор не может действовать директивами
а только лишь с согласия всей остальной команды. Чтобы действовать эфф, ।
швно, архитектор должен заслужить доверие команды, менеджера просю >
таказчика, сообщества пользователей и менеджмента.
Ориентация па цели и предусмотрительность с непреклонной ориентации। н
результат. Архитектор программного обеспечения - эго техническая дишии
сила проекта, а не фантазер и мечтатель. Жизнь успешного архитектора
длинный ряд субоптимальных решений, часто принимаемых в «темноте» и и
давлением. Перфекционист, тратящий на проблемы массу времени, не под».
для такой работы.
Руководство no RUP для архитектора
329
Один человек или команда?
Если проект достаточно велик, то данную роль могут выполнять несколько
человек, объединенных в архитектурную команду. Создавать команду архптек-
юров имеет смысл в проектах с участием 30 и более человек. Если ваш случай
именно таков, то цель - создания такой команды получить группу талантливых
людей с широким спектром опыта и общим пониманием процесса разработки
программного обеспечения. Команда архитекторов не должна быть просто
собранием представителей разных команд, предметных областей или наемных
работников. Создание архитектуры программного обеспечения - это работа для
людей с полной занятостью, решающих именно эту задачу. Мы часто пишем:
«Архитектор программного обеспечения делает...» Помните, что мы в данном
случае имеем в виду всех людей, выполняющих данную роль в данный момент
времени.
Центральная фигура общения
Архитектор - это не проектировщик-одиночка, работающий в башне из слоно-
вой кости. Он играет важную роль в процессах общения внутри организации.
Связующее звено между менеджерами проекта и разработкой
В киноиндустрии режиссер отвечает за художественное содержание фильма,
за управление актерами. Крайне редко бывает так, что режиссер выполняет помимо
этого роль исполнительного продюсера, который больше занимается планировани-
ем, финансами, бюджетом картины, персоналом, снабжением, декорациями и т.п.
Нов то же самое время эти две роли должны тесно координировать свою работу.
()ни должны постоянно общаться друг с другом, особенно в движущейся и все время
меняющейся среде. Точно так же и в проекте но разработке программного обес-
печения архитектор и менеджер проекта должны поддерживать постоянное общение
(по в то же время стараться не выполнять работу друг друга). Позже мы увидим, что
архитектор играет главную роль в планировании содержания итерации, в выявлении
зехнических рисков и борьбе с ними, и помогает менеджеру проекта вносить с трате-
гические и тактические изменения.
Связующее звено между внутренними участниками проекта и внешними
заинтересованными лицами
Архитектор также служит связующим звеном между внешним миром
и командой - командой архитекторов и остальными участниками - по техниче-
ским вопросам. Документ Концепция и требования, разработанные аналитиками,
330
Глава 16
служат главной входной информацией для работы архитектора. Из нее архитек
юр выделяет архитектурно значимые требования, важные для формирования
системы. При наличии многих внешних участников - заказчиков, наемных рабо,
пиков и др., данный аспект работы может начать отнимать очень много времени.
Связующее звено между разными командами разработчиков
Кроме того, архитектор, особенно в крупных организациях, также выполняс!
функцию связи и координирования работы разных команд разработчиков в сс
юхническом аспекте. Он обеспечивает создание интерфейсов и заставляю
придерживаться их. Он изыскивает возможности для повторного использования
()н участвует в рецензировании и борется за постоянство стиля разработки систе-
мы, храня то, что Фредерик Брукс (Frederick Brooks) называл «архитектурной
целостностью». Эта роль часто является постоянной и неформальной. Когда ста
повнтся трудно, архитектор играет роль арбитра в спорах между командами
и участвует в принятии решений в группе управления изменениями* 1, если тако
пая в проекте присутствует.
Архитектура
ДВ этом разделе расскажем подробнее о том, что мы подразумеваем под «архи
1скгурой программы», а также о некоторых других ключевых концепциях. «Архи
।ск гура» (начинается с заглавной буквы «А») - это дисциплина, искусство, а «архи
п-кгура» (пишется со строчной буквы «а») - это «вещь», свойство всех систем, ю,
над чем работает архитектор.
Определение архитектуры
Программная архитектура представляет собой набор существенных решении
касающихся организации программной системы, таких как:
• выбор структурных элементов и их интерфейсов, из которых слагается система;
• поведение, определяемое взаимодействием этих элементов;
• объединение этих структурных и функциональных элементов в более крупные
подсистемы;
• архитектурный стиль, исповедуемый в данной организации.
I Группа управления изменениями (Change Control Board) - это небольшая группа людей, осуществляю!цап
I типизирование и утверждение изменений, которые предлагается внести в базисные артефакты. - Примеч. аш
Руководство по RUP для архитектора
331
Архитектура программного обеспечения также имеет дело с:
• применением
• функциональностью
• производительностью
• гибкостью
• повторным использованием
• удобством для понимания
• экономическими и технологическими ограничениями и компромиссами
• эстетическими вопросами.
Это не просто определение в одну строчку, это целое
меню! Да, архитектура и как артефакт, и как дисциплина -
предмет весьма трудный, и если вы новичок в роли архитек-
тора, готовьтесь к тяжелой работе. Архитектура- очень
сложная вещь. Однако заметим, что архитектор кон-
центрируется только на архитектурно значимых требованиях
и соответствующих им архитектурно значимых проектных решениях (рис. 16.1).
Под «архитектурно значимым» мы имеем в виду то, что оказывает длительный
эффект на производительность, качество и масштабируемость системы, в противо-
положность мириаду прочих проектных решений, которые реализуются в ходе по-
строения системы. Архитектор не несет ответственности за все проектные решения.
Архитектор концентриру-
ется только на архитек-
турно значимых требова-
ниях и соответствующих
им архитектурно-значи-
мых проектных решениях.
Модели и представления
Поскольку описать архитектуру системы бывает весьма сложно и поскольку она
является центром внимания множества сторон или заинтересованных лиц, одним из
подходов к ее описанию будет использование множества точек зрения. Описание
архитектуры организуется в виде представлений, каждое из которых фокусируется
на одном аспекте архитектуры, не затрагивая прочих. В свою очередь каждое пред-
ставление может быть описано с помощью UML-модели или просто в текстовом
виде.
В зависимости от природы конкретного проекта архитектура будет иметь одно
из следующих представлений.
• Логическое представление (имеющееся в любой системе). Показывает раз-
личные элементы программного обеспечения и их структуру - классы, пакеты
и т.п.
332
Глава 16
Функциональность
Процесс
Технология
Качество <=!
Сложность
Навыки
Вопросы
бизнеса
Организация
и культура
Рис. 16.1. Создание архитектуры. Искусство компромисса. Архитектор при принятии решений до ।
жен иметь в виду множество различных измерений и сохранять равновесие между ними
Это заставляет архитектора постоянно идти па трудные компромиссы
• Представление процессов. В случае распределенных систем и систем с парад
дельной обработкой информации показывает параллелизм между различными
сущностями и способы их связи и синхронизации.
• Представление реализации. Показывает, как элементы реализации (файлы
исходного кода, исполняемые файлы и т.п.) организуются в среде разработки.
• Представление развертывания. Показывает, как во время выполнения фи
зически размещаются и тиражируются различные компоненты времени вы
волнения, а кроме того, как осуществляется связь между ними.
• Представление прецедентов использования. Фиксирует самые существенные
требования: прецеденты использования или их части, наиболее важные с точки
зрения архитектуры, а также важные нефункциональные требования (рис. 16.2)
Сюда могут входить реализации прецедентов использования, иллюстрирующие
работу системы.
Четыре первых представления располагаются в пространстве решении
а последнее связывает их с пространством проблемы.
Руководство по RUP для архитектора
333
Конечные пользователи
Функциональность
Логическое
представление
Разработчики
Управление программным обеспечением
j Представление
; реализации
АналитикиДестировщики
Поведение
Представление
прецедентов
.использования.
Представление ! , Представление
процессов ' I развертывания
Инженеры по производительности
Производительность
Масштабируемость
Пропускная способность
Инженеры-системщики
Топология системы
Выпуск, Инсталляция
Связь
Рис. 16.2. 4+1 Представление Архитектуры. Представление прецедентов использования содержит
архитектурно значимые прецеденты использования и представляет область проблемы.
Оно связано с четырьмя другими представлениями пространства решений. (Из Kruchten
1995)
Описание архитектуры программы
Главной обязанностью архитектора является описание архитектуры системы
водном из главных артефактов RUP, называемом «Описание архитектуры
программы» (Software Architecture Document, SAD). Во многих проектах в этом
документе может описываться лишь часть проектной модели, поскольку боль-
шинство аспектов дизайна может фиксироваться в виде UML-моделей и в виде
собственно кода. Чем больше лиц интересуются или затрагиваются архитек-
турой, тем более важным будет этот документ. Документ SAD организован в виде
набора представлений, выбранных из перечисленных нами ранее, или любых
других, подходящих для данного проекта. Шаблон SAD в RUP весьма общий, так
что первой задачей архитектора будет подогнать его под конкретный контекст
и нужды проекта. В частности, архитектор выбирает важные артефакты и способ
их документирования.
Прототип исполняемой архитектуры
SAD - это просто декларация о намерениях, документ.
Архитектурные решения оцениваются по прототипу архи-
тектуры, и архитектор должен управлять реализацией такого
прототипа, чтобы впоследствии он (прототип), развиваясь,
превратился в готовую систему. Прототип используется для
Архитектурные реше-
ния оцениваются по
прототипу архитектуры.
334
Глава ir
• щенки архитектуры, демонстрации устранения крупных рисков, служит основ, ш
ин последующей разработки. Его разработка - это хороший способ держан
,'|>| апизацию в курсе новых инструментов, языков, технологий, процессов, a i,u
же проводить калибровку производительности.
Архитектурные механизмы
Архитектурные механизмы представляют собой общепринятые конкретны,
решения часто встречающихся проблем. Это могут быть образцы структуры
образцы поведения или и то и другое сразу. Они предоставляют стандартны,
решения таких проблем, как сбор мусора, постоянное хранение, управление спи
, ками, реализация Корзины в электронной торговле, связь с внешними система
мп по определенному протоколу и т.п. Они играют важную роль в описании
архитектуры.
Дополнительная архитектура
Архитекторы могут разрабатывать и другие артефакты RUP, например, аналп
шровать выбор между возможными решениями или готовить руководства (guide
lines) для всех остальных разработчиков. Архитекторы участвуют в создании
1ЛКПХ артефактов RUP, как списки рисков, план проекта, концепция, требования
прецеденты использования и т.п.
Пне пределов конкретного проекта архитекторы могут создавать произволе!
пенную архитектуру, в которую входит выбор технологических решений и прин
пинов разработки. Вы организуете работу с повторным использованием? Как вы
собираетесь этого достичь? Следует ли разрабатывать все приложения на нлаi
форме J2EE, где все взаимосвязи между строительными блоками осущесн,
чиются через очереди сообщений? Каковыми будут эти главные строительны,
опоки и как приблизительно они будут развиваться на протяжении серии проеь
юн? Или же вместо этого вы воспользуетесь расширяющимися возможностями
Web-служб, которые разрешают повторное использование разных приложений и.,
р.ыпых платформах?
Руководство по RUP для архитектора
335
Развивающая роль
Описать RUP для архитектора несколько сложно, поскольку эта роль меняется
в ходе жизненного цикла, в фазах Начало, Проектирование, Построение,
Внедрение, а также в ходе развития проекта и циклов поддержки.
В фазе Начало, работая с появляющейся концепцией, архитектор оценивает
возможные стратегии реализации, выясняет осуществимость требований и стои-
мость управления. По мере того как система формируется, определяется возмож-
ная архитектура, а иногда даже создаются прототипы для оценки ее эффективно-
сти - прототипы «подтверждения концепции» (proof-of-concept prototypes) потен-
циальной архитектуры. Можно также создавать прототипы некоторых сложных
частей системы - для подтверждения концепции или для того, чтобы помочь
с принятием решения о разработке системы, или (в некоторых случаях), об отказе
от нее. Например, если вы сомниваетесь, создайте черновой прототип и покажи-
те, что ваша распределенная система будет поддерживать ожидаемое число тран-
закций.
Но наиболее важную роль архитектор играет в фазе Проек-
тирование, и здесь часто задействуется несколько человек. Целью
фазы Проектирование является воплощение Описания архитек-
туры программы и проверка выбранных решений путем разработки
Наиболее важную
роль архитектор
играет в фазе
Проектирование.
прототипа исполняемой архитектуры. Веха (контрольная точка), которая завершает
эту фазу, называется Вехой архитектуры жизненного цикла, и будем надеяться, что
архитекторы смогут к этому моменту создать основу архитектуры. Когда создание
архитектуры встречается с более вещественными элементами, чем просто
набросанные на бумаге требования, может возникнуть необходимость в пересмотре
требований и концепции. Например, прототип может показать, что нужно что-то
делать с проблемами производительности. Однако роль архитектора не заканчива-
ется Вехой архитектуры жизненного цикла.
В фазе Построение, как и при создании архитектуры, архи- В фазе Построение
текторы осуществляют надзор за реализацией оставшихся час-
тей системы, заставляя разработчиков не отклоняться от
первоначальных архитектурных планов. Часто бывает необхо-
димо вносить в архитектуру изменения и дополнения. Архи-
архитекторы осущест-
вляют надзор за реа-
лизацией оставшихся
частей системы.
тектор выполняет роль посредника и арбитра в отношениях между командами.
определяя место, где реализуется конкретный аспект системы, следя за выполне-
нием руководств и фиксируя в руководствах новую информацию. Принимая
участие в рецензировании проектной модели, архитекторы будут иметь хорошую
возможность привлечь внимание менеджмента проекта к кадровым проблемам:
336
Глава н
нарушению равновесия между командами, недостатку людских ресурсов, о i ex ।
i ।вию обучения и т.п. Они также могут выявлять дополнительные возможное, ш
1пя повторного использования или приобретения готового программного ши<
печения.
Кто-то может подумать, что в фазе Внедрение роль архитекторов становии ।
практически нулевой и они могут спокойно почить на лаврах или начать выпс.
1ынать новичков. Не совсем! Когда перед датой выпуска начинается аврал. ар\н
1скгор участвует в принятии критических решений по крупным дефектам: ...
исправлять и как и особенно бдительно следит за тем, чтобы не принимались по
спешные или безосновательные решения, которые, исправляя одну подсис1С'1\
могут нарушить работу другой. Масса неприятных ошибок делается ими......
па финишном рывке, сводя на нет все выгоды работы над архитектурой.
Что делают архитекторы?
Давид Дикел (David Dike!) и его коллеги, авторы книги «Software Architectin'
< )rganizational Principles and Patterns», ухватили самую суть деятельности ар\и
icKiopa в своей модели, которую они назвали VRAPS, что является аббрсшы
iy рой слов Vision (концепция), Rhythm (ритм). Anticipation (предвосхищение 1
Partnering (партнерство) и Simplification (упрощение).
Концепция
«Концепция - это согласование будущих выгод и архитектурных ограничении
измеряемое по тому, насколько структура и цели архитектуры ясны, убедительны
соразмерны и гибки»2. Разработка архитектурной концепции способствует н>м\
чю границы работ по созданию архитектуры определяются более w............
и устанавливается верный уровень ожиданий заинтересованных лиц (внешни
и внутренних). Также это позволяет рано определять нарушения требовании
и получать неявную информацию о пользовательском видении архитектуры.
Архитектурная концепция явным образом определяется в Описании архи и i
।уры программы, которое должно соответствовать общему документу Концеппп ।
проекта. Многие задачи фазы Проектирование, связанные с архитектурой, вши н
свой вклад в архитектурную концепцию.
2. См. Dikel 2001. - Примеч. авт.
Руководство по RUP для архитектора
337
Ритм
«Ритм - это периодически повторяющийся, предсказуемый обмен продуктами
деятельности в группе архитекторов, а также между заказчиками и поставщика-
ми»3. Сюда относится жизненный цикл, циклы и итерации, развитие архитектуры
но времени, развертывание и интеграция различных компонентов. Сюда относятся
и сроки и содержание релиза, а также качество этого содержания. Сюда же отно-
сится согласование оценочной деятельности заинтересованных лиц. В RUP присут-
ствует трехуровневый «темп»: циклы, итерации и выпуски. В первоначальном цик-
ле разработки явный акцент на архитектуре делается в фазе Проектирование. В по-
следующих эволюционных циклах также будет фаза Проектирование, в которой
архитектура развивается, совершенствуется и упрощается. Каждый цикл и каждая
фаза делятся на итерации, которые используются как точки синхронизации деятель-
ности в масштабе организации, с акцентом на выпуске продукта, и которые из-
начально ведут к созданию архитектурной основы, а затем к разработке постепенно
усложняющегося продукта при повышении его качества. А затем регулярное созда-
ние выпусков в каждой итерации заставляет сконцентрироваться на наиболее
значимом и на устранении конкретных проблем.
Предвосхищение
«Предвосхищение - это то, в какой степени тот, кто строит архитектуру, может
предсказать, оценить и приспособить ее к конкуренции, к меняющейся техноло-
гии, и к желаниям заказчика»4. Самое трудное для архитектора - это согласовать
долгосрочную концепцию с сиюминутными нуждами в условиях постоянной
перетряски технологии. Так как же при этом избежать хождения по лезвию ножа
и слишком узкого взгляда на вещи? Здесь вы видите, как разные принципы
начинают взаимодействовать друг с другом: здоровый ритм заставляет проводить
регулярный пересмотр и переоценку архитектурной концепции.
Партнерство
«Партнерство — это то, в какой степени затрагиваемые архитектурой лица
придерживаются своих совместных ролей и, максимально используя все получае-
мое, дают максимальный результат»5. Не делайте всего сами. Создавайте совме-
3. Там же. - Примеч. авт.
4. Там жеПримеч. авт.
5. Там же. - Примеч. авт.ъ
338
Глава l в
с пиле группы, как внутренние, так и внешние. Максимально увеличивайте выхо ।
01 деятельности ключевых заинтересованных лиц, а не локальные объемы paGoi
Обеспечьте формирование четкого и устойчивого соглашения различных занп
1срссованных лиц на основе проповедуемого Барри Боэмом (Barry Boehm) прин
цппа «общего удовлетворения». Архитектор - это посредник, примиритель, спя
цющее звено, арбитр. Архитектор - пропагандист повторного использования.
Упрощение
«Упрощение - это разумное видоизменение и минимизация как архитектуры, i.u
и организационного окружения, в котором она функционирует»6. Архитеки p.i
продолжает использоваться, но в то же самое время стоимость ее использования п
следовательно, сложность необходимо уменьшить. Никаких ошибок, никаких излит
них обобщений, которые ведут к слишком общим решениям. Архитектор понимаю
минимально необходимые требования и встраивает их в ключевые элементы архи
icKiypw. Общее экономическое обоснование развития архитектуры остается четким
I (ропзводится только небольшая архитектурная переработка.
Задачи архитектора в RUP
Трудно свести задачи архитектора к небольшому набору рецептов. Слишком
много будет зависеть от контекста, природы системы, ее размера, от того, «зеле
пая» ли это разработка, расширение существующей системы или переработки
спсюмы, оставшейся в наследство.
Помимо Описания архитектуры программы и расписанных в нем архитектур!и.о.
представлений, в RUP описано еще несколько задач архитектора (рис. 16.3). Мы р;н
ic’iiijhi их натри группы.
• Работа с требованиями и управление проектом.
• Совершенствование архитектуры.
• 11оддержание архитектурной целостности.
(> Там же. - Примеч. авт.
Руководство по RUP для архитектора
339
i j
Архитектор
1рограммного
обеспечения
Оценка жизнеспособности
архитектурного
«подтверждения концепции»
Архитектурный
анализ
Определение
механизмов
проектной модели
Определение элементов
проектной модели
Описание
распределения
Создание
архитектурного
«подтверждения
концепции»
Объединение
имеющихся
элементов
проектной модели
Описание архитектуры
времени выполнения
Рис. 16.3. Обзор задач архитектора. Архитектор отвечает за выполнение широкого диапазона задач,
включающих задачи, связанные с требованиями и управлением проектом, совершенство-
ванием архитектуры и поддержанием архитектурной целостности
Работа с требованиями и управление проектом
Эти задачи выполняются обычно на ранних стадиях проекта, когда роль архи-
тектора охватывает управление проектом, управление требованиями, анализ
и проектирование.
Расстановка прецедентов использования в порядке приоритета
Эту задачу архитектор выполняет совместно с менеджером проекта при пла-
нировании итераций. Основываясь на рисках, которые нужно снять в данной
итерации, и на том, какую часть системы необходимо закончить (когда мы нахо-
димся на поздних стадиях цикла разработки), архитектор выбирает, какие части
каких прецедентов использования нужно реализовать в предстоящей итерации.
Мы уже описывали это в главе 6, «фаза Начало».
Архитектурный анализ
На основе концепции и ключевых прецедентов использования архитектор соз-
дает архитектурную концепцию, как мы описывали ранее, разрабатывая общий
обзор архитектуры. Он выявляет, какие имеющиеся методы и приемы могут быть
использованы для уменьшения объемов работы и придает структуру логическому
представлению архитектуры.
340
Глава I в
Эта структура заселяется ключевыми абстракциями, обычно взятыми из пре ।
мегной области. Часто они представляют собой классы, например Покупавсш.
Заказ, Склад и т.п., и основные части, то есть атрибуты этих классов. Также ар\и
1ектор выявляет фундаментальные аналитические механизмы и шаблоны
которые связываются с этими классами и описывают их поведение. Эти апаш
шческие механизмы не зависят от реализации. Они охватывают такие вопросы
как долговременное хранение, связь, синхронизация и безопасность. Позже они
оудут связываться с конкретными реализациями.
После этого можно описать выбранные прецеденты использование
в реализациях прецедентов использования (use-case realizations), применяя по, в о
ювленные абстракции (классы и модели).
И наконец, все эти отдельные решения должны быть объединены в одну coi ил
сованную архитектуру. При этом нужно устранять избыточность и выявлять и н<
пользовать сходство.
Конструирование архитектурного прототипа «подтверждения концепции»
В главе 6, мы видели, что в новых рискованных проектах с массой «белых пятен-
которые нужно исследовать до того, как будут приниматься решения, может оказан,
ся необходимым создавать прототипы в целях уяснения границ системы, проверки <
осуществимости и оценки реальности риска или эффективности решения.
Совершенствование архитектуры
Именно здесь принимаются, проверяются и документируются технологически!
решения. Эти задачи вносят свой основной вклад в разработку исполняемой архи
)екгурной основы системы, и их результат документируется главным образом
в SAD. Данные задачи проиллюстрированы в главе 7«Фаза Проектирование».
Определение механизмов проектной модели
Теперь архитектор должен выбрать соответствующие проектные решения и реа
ннзовать описанные ранее аналитические механизмы. Например, будет ли постояв
пос хранение осуществляться на жестком диске или в памяти? В базе данных в ш
в простом файле? Часто выбор инфраструктуры (промежуточного программно!
обеспечения) определяет выбор возможных проектных решений. После этого реви
пня нужно сопоставить с конкретными механизмами реализации.
Руководство по RUP для архитектора
341
Определение элементов проектной модели
Архитектор обязан знать, как различные ключевые элементы будут определе-
ны в программе. Это главная задача, в которой архитектор может использовать
все свои навыки проектирования, а также все возможности руководств по проек-
тированию, содержащихся в RUP. Единственная опасность состоит в возможно-
сти выйти за рамки и потеряться в данной задаче, зайдя слишком далеко, слиш-
ком глубоко, или увязнув в деталях.
Объединение имеющихся элементов проектной модели
Очень часто эту работу нельзя выполнить в вакууме. Есть масса возможностей
по повторному использованию материалов для других платформ, из других сход-
ных проектов, из доставшихся в наследство систем. Часто это принимает форму
переработки имеющихся элементов и интеграции их в новую систему.
Структурирование модели реализации
После принятия нескольких крупных решений нужно структурировать модель
реализации. Где будут храниться связанные с реализацией артефакты, исходный
код, исполняемые файлы, документация, модели? Что нужно поставить под
контроль конфигураций и версий? Где будут находиться повторно используемые
элементы? Такая система должна позволить разработчикам работать эффективно
и не мешать друг другу. Такие вопросы, как индивидуальные и командные рабочие
пространства, пространства интеграции и управление конфигурациями, также сле-
дует принимать во внимание при разработке этого аспекта архитектуры.
Описание распределения и архитектуры времени выполнения
Кроме того, если система является распределенной и параллельной, то нужно
принять решения по потокам, задачам и прочим аспектам параллелизма и орга-
низовать их в отдельные представления - Представление процессов и Представ-
ление развертывания.
Архитектор описывает архитектуру времени выполнения следующим образом:
• анализируя требования к параллелизму;
• определяя процессы и потоки;
• определяя механизмы взаимодействий между процессами;
• распределяя ресурсы для координации между процессами;
• определяя жизненный цикл процессов;
• связывая процессы со средой, в которой осуществляется реализация;
• распределяя элементы моделей среди процессов.
342
Глава щ
В случае распределенных систем архитектор описывает распределенп<
ооозначая физические узлы. Сюда относятся определение сетевой конфигурации
и распределение процессов по узлам.
Несколько лет назад наш коллега Грейди Буч (Grady Booch) участник.i ।
к проекте, который иллюстрирует важность параллелизма и распределен!п
н;п рузки. Он разрабатывал модернизированное программное обеспечение ;ih
ноною поколения ракетных установок, которое должно было осуществлять ма
искры двигателем и анализировать ведущийся по устройству огонь. Рецензирова
нпе проектной модели показало наличие нескольких крупных просчетов: koi ы
мнройство находилось под огнем, оператор с трудом мог маневрировать, не ю
поря о том, чтобы быстро оторваться и скрыться. Решением проблемы бы ы
чрмос распределение элементов модели по процессам, а процессов - по фи
шческим узлам, определение иных приоритетов для процессов времени выпи ।
нспня, чтобы одни и те же процессы и одни и те же процессоры не осуществля ш
о ^повременно маневры двигателем и анализ огня.
Поддержание архитектурной целостности
Есть несколько вспомогательных, но важных задач, которые тоже принад п
ж.и к компетенции архитектора. Они относятся к оценке архитектуры и к hoi
к ржанию архитектурной целостности на всем протяжении цикла разработки
/ 'наработка руководств по проектированию
Архитектор должен не только проектировать или выбирать архитекпрх
но п донести до всех информацию о том, как правильно использовать элемснн ।
архитектуры. Кроме того он должен определить правила расширения и измен,
нпя архитектуры. Архитектура может основываться на скрытых допущения
па которые нужно ясно и четко указать всем прочим разработчикам, тестирован,
кам и интеграторам, чтобы архитектура не была разрушена.
/ ’наработка руководств по программированию
' )та функция сходна с руководствами по проектированию, но здесь для доп и
-кспня некоторых архитектурных целей используются свойства выбранного я я,пы
iipoi раммирования.
РУКОВОДСТВО ПО RUP ДЛЯ АРХИТЕКТОРА
343
Рецензирование архитектуры
Цель рецензирования архитектуры.
• Выявить все неизвестные или предполагаемые риски для сроков и бюджета.
• Определить все недостатки архитектурного проекта. Как известно, архитек-
турные недостатки труднее всего исправлять, и они наносят наибольший урон
в долгосрочной перспективе.
• Выявить потенциальные несоответствия требований и архитектуры: избы-
точность конструкции, нереалистичные требования или пропуск требований.
В частности, можно проверить некоторые часто не замечаемые аспекты функ-
ционирования, администрирования и обслуживания. Как система инсталлирует-
ся и как проводится ее обновление? Как осуществляется конвертация имеющих-
ся баз данных?
• Оценить одно или несколько специфических качеств архитектуры: производи-
тельность, надежность, легкость внесения модификаций, безопасность и за-
щищенность.
• Выявить возможности для повторного использования.
Это рецензирование проводится в конце фазы Проектирование, в момент Вехи
(контрольной точки) архитектуры жизненного цикла. Архитектор также должен
принимать участие и в других рецензированиях, определенных в дисциплине
RUP Управление проектом (Project Management), и быть ключевой фигурой груп-
пы Управления изменениями (Change Control Board) и определять, как и когда
должны решаться критические вопросы.
Роль архитектора в RUP
Если вы являетесь архитектором программного обеспечения, вам, скорее все-
го, придется выполнять несколько ролей, определяемых в RUP. Первая и самая
главная роль RUP, которую выполняет архитектор - это роль архитектора
программного обеспечения (Software Architect). Однако архитектор часто оказы-
вается и проектировщиком (Designer), и рецензентом Архитектуры (Architecture
Reviewer).
Часто архитектор оказывается разработчиком (Implementer), особенно если он
принимает участие в разработке прототипа архитектуры на начальных этапах фа-
зы Проектирование или прототипа «подтверждения концепции» в фазе Начало.
Предпочтительно, чтобы роль аналитика (Analyst) исполнял другой человек,
чтобы обеспечивалось естественное разделение задач и требования не смешива-
лись с проектной моделью, и наоборот. В идеале аналитик должен быть адвока-
344
ГЛЛ‘ и
him заказчика (хотя и адвокатом просвещенным, т.е. понимающим техничен । и
проблемы и получившуюся проектную модель). Истиной, однако, являеня
по во многих малых проектах грань между аналитиком и архитектором размь: । >
Вряд ли будет правильным заставлять архитектора исполнять роль мене,и ' р
проекта, разве что в очень малых проектах.
Нередко можно наблюдать, как архитектор исполняет роль инженера-зехно ,
ia (Process Engineer), поскольку у него часто имеется достаточный для испо и,
нпя этой роли опыт работы с процессом разработки программного обеспеченп
Найдите свой путь в RUP
будучи архитектором, перед гем как начать работать с RUP. поймите iiei<oiopn
фундаментальные концепции: концепции итеративной разработки, жизненною пи >
RHP (фазы и итерации), управления рисками, а потом - некоторые концепции
напрямую относящиеся к архитектуре: компоненты и различные архптекури
представления. Обращайтесь по мере необходимости к глоссарию.
После этого вы сможете войти в RUP через роль архитектора программна.
обеспечения (Software Architect) и рассмотреть различные задачи, заданные i ।
ной роли. В качестве альтернативы вы можете начать с артефакта «Оппе.пт
архитектуры программы» (Software Architecture Document) (его шаб юн ।
и примера). От него переходите к различным задачам, связанным с его разряди
кой. Третий путь в Rl.JP- начать с дорожной карты (road map) «Разработка i." ।
попентных решений» (Developing Component Solutions).
Затем, как того требует ваш конкретный случай, вы можете потрут i к '
в более специализированные вопросы или Основные принципы (Concept.'
Параллелизм (Concurrency) и использование капсул (Capsule), моделирована
данных (Data Modeling), бизнес-архитектура (Business Architecture) и т.п.
Не забывайте, что архитектор взаимодействует со многими другими ро.гот
и в гой или иной форме принимает участие в решении их задач. Введите в поп.
ковой машине слово Architecture или Architect.
Руководство по RUP для архитектора
345
Ресурсы для архитектора
Дополнительная литература
Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice.
Reading. MA: Addison-Wesley, 1998.
Jan Bosch. Design and Use of Software Architecture: Designing and Evolving
a Product-Line Approach. Boston: Addison-Wesley, 2000.
Frank Buschmann, Regine Meunier. Hans Rohnert, Peter Sommerlad, and Michael
Stal. Pattern-Oriented Software Architecture: A System of Patterns. New York: John
Wiley & Sons, 1996.
Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little.
Robert Nord, and Judith Stafford. Documenting Software Architectures: Views and Be-
yond. Boston: Addison-Wesley, 2002.
Paul Clements, Rick Kazman, and Mark Klein. Evaluating Software Architecture.
Boston: Addison-Wesley. 2002.
Paul Clements and Linda Northrop. Software Product Lines: Practice and Patterns.
Boston: Addison-Wesley, 2002.
David M. Dikel. David Kane, and James R. Wilson. Software Architecture: Organi-
zational Principles and Patterns. Upper Saddle River, NJ: Prentice-Hall, 2001.
Christine Hofmeistcr. Robert Nord, and Dilip Soni. Applied Software Architecture.
Boston: Addison-Wesley, 2000.
IEEE 1471:2000. “Recommended Practice for Architectural Representation.” Los
Alamitos, CA: Software Engineering Standards Committee of the IEEE Computer So-
ciety, 2000.
1SO/IEC 10746:1995. Reference Model of Open Distributed Processing (RM-ODP)
(ITU Rec. X901). Geneva, Switzerland: ISO. 1995.
Ivar Jacobson. Martin Griss. and Patrik Jonsson. Software Reuse: Architecture, Pro-
cess and Organization for Business Success. Reading, MA: Addison-Wesley, 1997.
Philippe Kruchten. “Common Misconceptions About Software Architecture,” in
The Rational Edge, April 2001.
Philippe Kruchten. “The Tao of the Software Architect,” in The Rational Edge,
March 2001.
Philippe Kruchten. “The 4+1 View of Architecture,” in IEEE Software 6 (12), 1995.
Eberhardt Rechtin and Mark Maier. The Art of System Architecting. Boca Raton,
FL: CRC Books, 1997.
Bran Selic, Garth Gullekson, and Paul Ward. Real-Time Object-Oriented Modeling.
New York: John Wiley & Sons. 1994.
346
Глава 16
Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerging
I hscipline. Upper Saddle River, NJ: Prentice-Hall, 1996.
Marcus Vitruvius Pollio, De Architecura, circa 25 B.C. at http://www.ukans.edu/
liis(ory/index/europe/ancient_rome/L/Roman/Texts/Vitruvius/l*.html.
Bernard I. Witt, F. Terry Baker, and Everett W. Merritt. Software Architecture and
I tvsign: Principles, Models, and Methods. New York: Van Nostrand Reinhold, 1995.
Полезные Web-сайты
Вот некоторые отправные точки для поиска в интернете информации
<> программной архитектуре:
• Software Engineering Institute: http://www.sei.cmu.edu/architecturc
sw architecture.html.
• Worldwide Institute of Software Architects: http://www.wwisa.org.
• Ресурсы для архитекторов программного обеспечения от Dana Bredemeyer: http://
www.bredemeyer.com.
ГЛАВА 17
Руководство по RUP для разработчика
Вы - разработчик, привлекаемый к анализу, проектированию, реализации, ин-
теграции или к теетированию при разработке (developer testing). Эта глава помо-
жет вам использовать RUP. Вы найдете здесь обзор обязанностей разработчика
в RUP-проекте и ресурсы, такие как рекомендуемые курсы обучения и дополни-
тельную литературу. Все это поможет вам стать более опытным разработчиком.
Миссия разработчика
Когда мы говорим о разработчике, мы говорим о роли. В RUP-проекте
несколько людей могут исполнять одну роль, а один человек может исполнять не-
сколько ролей (полностью или частично). Таким образом можно исполнять часчь
роли разработчика и часть обязанностей аналитика. Заметим, что в данной главе
мы коротко опишем интеграцию и проектирование баз данных. Во многих проек-
тах, особенно в крупных проектах, интеграцию может производить тот, кого на-
зывают «менеджер по конфигурационному управлению» (Configuration Manager),
который может не участвовать в таких задачах, как анализ, проектирование, реа-
лизация и тестирование. Также и проектирование баз данных может осуществ-
лять администратор баз данных (Database Administrator, DBA), а не тот, кто носит
название «разработчик».
348
Глава 1 i
Наша основная цель как
разработчика - перевод
любований в достаточно
качественный исполняе-
мый код.
Ваша основная цель как разработчика - перевод требовании
в достаточно качественный исполняемый код. Осуществля 11.
это нужно в тесном контакте с архитектором (см. гл. 16)
чтобы обеспечить соответствие проектных решений и архи
тектуры. Деятельность разработчика можно разбить на in-
сколько задач высокого уровня.
• Понять требования и проектные ограничения.
• Спроектировать, реализовать и протестировать программное обеспечение
удовлетворяющее этим требованиям.
• Спроектировать, реализовать и протестировать все необходимые базы данных
• Часто осуществлять интеграцию своего приложения с работой других разрл
ботчиков.
Для эффективного решения этих задач вам нужно обладать следующими iu
ныками:
• необходимо понимать, как документируются требования;
• нужно иметь твердые знания технологии реализации и используемых инсгрх
ментов, например, J2EE, .NET, интегрированной среды разработки (IDI )
средств визуального моделирования и платформы, для которой предназначено
программное обеспечение;
• нужно обладать творческим потенциалом и быть организованным, уметь coxp.i
пять равновесие между поиском изящных решений трудных проблем и диецнп
линой разработки;
♦ нужно постоянно помнить о качестве и сдавать только протестированный ко i
Вклад разработчика особенно велик в фазе Построение (рис. 17.1), копы
проектируется, реализуется и тестируется большая часть кода. Кроме тон>
разработчик участвует в фазе Проектирование, в которой проектируются, рсачи
|уюгся и тестируются архитектурно значимые сценарии, помогающие убеди in ч
в гом, что архитектура достаточно хороша. В фазе Проектирование разрабо) чш
шкже реализует архитектурные механизмы, т.е. повторно используемые решенпч
распространенных проблем, таких как долговременное хранение и взаимодеш i
нпя между процессами. В фазе Внедрение совершенствование приложеиич
продолжается в части устранения дефектов, а в фазе Начало вы можете потрач и 11
некоторое время на создание концептуальных прототипов.
Руководство по RUP для разработчика
349
Дисциплины
Бизнес-моделирование
Требования
Анализ
и проектирование
Реализация
Тестирование
Развертывание
Управление конфигурациями
и изменениями
Управление проектом
Среда
Фазы
Проектирование
Начало
Построение
Внедрение
li-
Начальная ’5 Проектор 1 Проектор 2 Построен 1, ’Построен2 Построен.N ,Веден1 Веден 2 '
Итерации
Рис. 17.1. Роль разработчика в RUP. Разработчик в первую очередь участвует в дисциплинах «Ана-
лиз и проектирование» и «Реализация». Это означает, что он делает большую часть своей
работы в фазах Проектирование и Построение. Разработчики также играют важную роль
в фазе Внедрение и незначительную - в фазе Начало
Общий обзор задач разработчика
Задачи разработчика можно разделить на следующие категории (каждая из ко-
торых описывается в последующих разделах).
• Понять требования и проектные ограничения.
• Спроектировать, реализовать и протестировать программное обеспечение,
удовлетворяющее этим требованиям.
• Спроектировать, реализовать и протестировать все необходимые базы данных.
• Часто осуществлять интеграцию своего приложения с работой других разра-
ботчиков.
350
Гллнл I
После рассмотрения этих задач в нижеследующем разделе «Лучшие пр.и
шческие методы разработчика» мы предоставим вам арсенал методов, которг»
можно подбирать под цели вашего проекта.
Все задачи разработчика решаются итеративно, как указывается в раз, к ,
«Часто осуществлять интеграцию своего приложения с работой дрын
разработчиков». При чтении данной главы нужно об этом постоянно помни и
Как правило, вы выполняете часть проектирования, часть реализации, часп> в
шрования, обдумываете реализованные идеи, азатем проводите обратное прол
шрование вашей проектной модели на основе реализации. Для наших учеипы
целей мы опишем мыслительный процесс в более последовательном поря и
чем это осуществляется на практике.
Заметим, что вы можете документировать некоторые описанные артефакт
(особенно промежуточные) менее формально (например, на письменной дол <
\ чптывая размеры вашего проекта и выбранный уровень формализованности
Понять требования и проектные ограничения
Вам, как разработчику, необходимо понимать требования. Первый шаг - hii.i
iciibHO прочитать Концепцию, которая дает высокоуровневую информации
о юм, что система должна делать, вводя вас в тот контекст, который соотвезс i
ci месту вашей части проекта в общем решении.
Функциональные тре Функциональные требования записаны главным образом, в преш
(ювания записаны центах использования. Вам могут поручить реализацию как чж и
f навным образом, прецедента использования, так и нескольких прецедентов. Чн
и прецедентах познакомиться с прецедентом использования, прочитайте его они
использования. , , _ г
сание. (см. гл. 15 раздел «1 юдробное описание акторов и прецс к и
нт использования»). Также необходимо, чтобы вы приняли участие в рецензирою
инн или разработке прототипа пользовательского интерфейса. Это даст вам возм>> ,
пость лучше понять, каких возможностей пользователь ждет от прецедента исполь
нания. (см. гл. 15 раздел «Разработка прототипов пользовательского интерфейс., ,
В небольших проектах один и тот же человек может выполнять и аналн, и щю, ,
шрование прецедента использования. Это автоматически обеспечивает разрабо i « i,,,
глубоким пониманием прецедента использования, поскольку он участвует в сое iaг. ।
пип его описания.
Руководство по RUP для разработчика
351
Нефункциональные требования документируются в RUP в
Дополнительных спецификациях (Supplementary Specification),
которые содержат требования к производительности, удобству
использования, поддержке платформ, технические и прочие
ограничения. Например, может быть запрещено использовать
в приложении программы с открытым исходным кодом (open-
source). Важно внимательно прочитать этот документ, чтобы
Нефункциональные
требования докумен-
тируются в RUP
в Дополнительных спе-
цификациях (Supple-
mentary Specification).
выбрать правильное техническое решение в тех рамках, которых ваша реализация
должна придерживаться. Заметим, что в небольших не очень формализованных
проектах могут документироваться не все нефункциональные требования. В таком
случае вам нужно связаться с аналитиками и прочими заинтересованными лицами
и убедиться, что вы правильно понимаете нефункциональные требования.
Как разработчик вы отвечаете за архитектурный контроль над той частью сис-
темы, которую вы разрабатываете. Это означает, что вам нужно работать бок
о бок с архитектором, чтобы ваши проектные решения соответствовали общей
архитектуре. Информацию о том, какие архитектурные механизмы (общие реше-
ния распространенных проблем) предполагается использовать, можно найти
в Описании архитектуры программы (Software Architecture Document). Здесь вы
можете найти готовые решения вопросов взаимодействия с внешними система-
ми, долговременного хранения, сбора мусора и т.п. Описание архитектуры
программы также содержит информацию об основных «строительных блоках»
и их интерфейсах - информацию, которая поможет вам понять архитектуру,
внутри которой будет существовать ваш код. В небольших неформальных проек-
тах архитектурные решения и архитектурные механизмы могут докумен-
тироваться неполностью. В таком случае вам нужно работать совместно с архи-
тектором, чтобы полностью понимать архитектуру.
Когда вы проектируете, реализуете и тестируете свои реше-
ния, важно поддерживать связь и демонстрировать свои успе-
хи расширенной команде, включающей представителей поль-
зователей. Продемонстрировав частично реализованные
решения, вы быстро получите обратную связь, которая позво-
лит вам сделать необходимые улучшения именно тогда, когда
это сделать легче всего.
Когда вы будете проектировать, реализовывать и тес-
тировать свои решения, вы скорее всего заметите несоответствия или «дыры»
втребованиях. Важно сообщать об этом аналитику, чтобы он мог исправить или
доработать прецеденты использования.
Когда вы проектируе-
те, реализуете и тес-
тируете свои реше-
ния, важно поддержи-
вать связь и демон-
стрировать свои
успехи расширенной
команде.
352
Глава l <
Спроектировать, реализовать и протестировать прецеденты
использования и компоненты
Вам нужно обеспечить проектирование, реализацию и тестирование всех во:
можностей, о которых вы договорились с пользователем. Главным образом эти во:
можности зафиксированы в описаниях прецедентов использования и в связанны-
с ними прототипах пользовательского интерфейса. Как уже говорилось выпи
вы можете найти ограничения, накладываемые на реализацию прецедентов исполь
ювапия, в Дополнительной спецификации (Supplementary Specification) и в Oniic.i
инн архитектуры программы (Software Architecture Document).
Проектировать, реализовывать и тестировать наиболее существенные препс
1С1ИЫ использования нужно в фазе Проектирование. (Подробнее мы говорили ш.
ном вгл. 7 разделе «Для формирования архитектуры используйте архитектур, ы
шачимые прецеденты использования».) Заметим, что в фазе Проектировать
реализуются только наиболее важные, а не все сценарии этих прецедентов ш
пользования. С каждой итерацией фазы Построение вы будете реализовывать ы ।
Польше и больше прецедентов использования, которые ранее были реализованы
цинь частично. К концу фазы Построение все прецеденты использования доли-
ны быть полностью реализованы, но в фазе Внедрение в них можно вносить in
оолыпие модификации, основываясь на обнаруживаемых дефектах и информ.>
цпн, получаемой в результате обратной связи.
Проектирование реализаций прецедентов использования и компонентов
Представление прецедента использования в проектной модели называем ।
реализацией прецедента использования (use-case realization). В ней описывай к ч
каким образом конкретный прецедент использования реализуется впроекннш
модели в виде взаимодействующих компонентов. Разные разработчики пре i
почитают разные подходы к созданию реализаций прецедентов использовано ।
В чанном разделе мы опишем подход, который доказал свою эффективность, оо
ici чая взаимодействие между аналитиками и разработчиками, давая пошагово,
руководство по выявлению правильных компонентов и обеспечивая еоответс i пи.
проектной модели требованиям, но не более того. Давайте рассмотрим .....
нягишаговый подход к созданию реализаций прецедентов использования, pat и
ши всю работу на анализ и проектирование.
Шаг 1. Создание объектам аналитической модели первого наброска всею и.
обходимого для осуществления взаимодействия.
Руководство по RUP для разработчика
353
Шаг 2. Распределение поведения по классам аналп i пческой модели.
Шаг 3. Описание классов аналитической модели п ее унификация.
Шаг 4. Проектирование прецедентов использования.
Шаг 5. Описание каждого класса проектной модели и ее унификация.
Нужно заметить, что в случае очень простых прецедентов использования, опи-
сывающих работу с данными, особенно если они реализуются с помощью мощ-
ных языков программирования четвертого поколения (4GL, например, Visual Ba-
sic, PowerBuilder), необязательно выполнять все эти шаги (более подробно об
этом ниже).
Заметим, что для проекта нужно правильно избрать уровень формализовапио-
сти. Некоторые разработчики предпочитают фиксировать информацию, создавае-
мую в Шагах с 1 по 3, на письменной доске или даже в уме. Другие пред-
почитают фиксировать ее прямо в инструменте визуального моделирования.
Некоторые разработчики вообще склонны переходить сразу к Шагу 4. Это застав-
ляет переходить прямо от высокоуровневых требований к конкретным проект-
ным решениям. Эго осложняет также, общение с аналитиком и проверку
правильности понимания требований (часть Шага 1) и затрудняет создание
и унификацию проектной модели, которая соответствовала бы архитектуре, по-
скольку вы не выполняете Шаг 3. Это означает, что если вы пропускаете шаги с 1
по 3, вам нужно будет бороться с этими рисками либо с помощью опытных
разработчиков, или путем создания менее сложной системы, пли с помощью
разработчиков, хорошо понимающих требования, или включив в команду силь-
ных архитекторов.
Наконец, предлагаемый подход работает независимо от того, используете ли
вы объектно-ориентированные или другие языки программирования, лишь бы
язык поддерживал реализацию компонентов путем инкапсуляции.
Давайте рассмотрим эти шаги подробнее.
Шаг 1. Создание объектам аналитической модели первого наброска всего необходи-
мого для осуществления взаимодействия
Многие новички в объектно-ориентированном программировании затруд-
няются в выборе правильных объектов. RIJP содержит конкретные руководства,
которые значительно облегчают эту задачу, деля классы на три категории, так на-
зываемые «стереотипы».
Граничные классы (Boundary classes). Предоставляют интерфейсы
к акторам и протоколам для взаимодействия с внешними системами.
Примеры: Пользовательские окна пли протоколы http://
12- 863
354
Глава I i
Управляющие классы (Control classes). Инкапсулируют последов.!
тельности событий или поведение прецедента использования.
Примеры: Планировщик или Регистратор.
Классы-сущности (Entity classes). Хранят (обычно долговременно) пи
формацию о некоем явлении, например, событии, человеке или объекп
реального мира, а также содержат бизнес-правила, связанные с этой
информацией.
Примеры: Студент, Расписание, Предлагаемый курс.
При реализации прецедентов использования обычно придерживаю н я
1П1П1ЧНОЙ аналитической схемы. Как правило создается:
• один граничный класс для каждого актора, задействованного в прецедент
использования, инкапсулирующий интерфейс к этому актору;
• один управляющий класс для каждого прецедента использования, инкапсх
пирующий последовательность событий в этом прецеденте использования;
• столько классов-сущностей, сколько необходимо, чтобы хранить информа
цию о различных явлениях, которые должны быть представлены.
Возможно, что многие классы-сущности уже созданы (по крайней мерс
конторой половине фазы Построение), но на этом этапе вы можете добавляп.
в дополнительные объекты-сущности. Разместите объекты необходимых классом
па диаграмме, часто называемой «Представление задействованных классов-
(View of Participating Classes, VOPC), и нарисуйте отношения, показывающие
как эти экземпляры взаимодействуют друг с другом. Па рис. 17.2 приведен при
мер такой диаграммы. Работайте в тесном контакте с аналитиком, который oi
нечаст за прецедент использования. Создание диаграммы VOPC часто выявляы
•дыры» в описаниях прецедентов использования. Также нужно подумать о взап
модействии с архитектором, который может помочь вам быстро создать хороший
черновой набросок модели, находящийся в соответствии с остальной системой
Привлечение архитектора может значительно уменьшить объем времени, за
|рачпваемый на Шаг 3. Наш опыт также показывает, что новичкам в объектно
ориентированных технологиях при выполнении этого шага впервые несколько
раз может понадобиться помощь.
Шаг 2. Распределение поведения по классам аналитической модели
Чтобы удостовериться в наличии всех необходимых классов и понять облает
о। всгственности каждого класса, вам нужно описать, каким образом выявлении!
ооьекты взаимодействуют друг с другом. Новичкам в компонентной разработке мы
можем сказать, что мы обнаружили отличное средство обучиться этому - метод за
Руководство по RUP для разработчика
355
Рис. 17.2. Пример представления задействованных классов. Представление задействованных классов
показывает классы аналитической модели, экземпляры которых задействованы в данном пре-
цеденте использования. Оно дает высокоуровневую информацию о том. какие классы исполь-
зуются, без учета подробностей того, какие операции и когда выполняются в целях обеспече-
ния функциональности прецедента использования
бавного группового упражнения, похожий на технику «картСИС»1, предложенную
Кентом Беком (Kent Beck) и Уордом Каннинхэмом (Ward Cunningham)1 2 3. Соберите
всю команду и дайте каждому сыграть роль одного из объектов или одного из ак-
торов. Для представления операций, проводимых над объектами^, один человек
(акгор/объект) передает предмет (например, мяч) тому человеку (актору/объекту).
от которого он желает получить услугу. Помощник записывает данное взаимодепс i -
вие и выявленную область ответственности актора/объекта. Теперь человек с мячом
в свою очередь делает запрос и т.д. Давайте рассмотрим пример, показывающий,
как такая ролевая игра будет выглядеть в случае прецедента использования «Запись
на курсы» в системе записи студентов на курсы (рис. 17.3).
1. Карта CRC (Class-Responsibility-Collaboration card) - карточка с описанием обязанностей класса и объектами,
взаимодействующими с данным классом при выполнении этих обязанностей. - Примеч. науч. ред.
2. См. Beck 1998. - Примеч. авт.
3. «Провести операцию» означает, что один объект посылает другому сообщение, говорящее, что нужно сделать.
Примеч. авт.
12-
356
Глава 17
I Человек, представляющий актора «Студент», передает мяч человеку,
представляющему экземпляр граничного класса «Форма для записи на курс»,
и объявляет, что актор желает составить расписание.
Человек, представляющий экземпляр граничного класса «Форма записи на
курс», посылает запрос «получить список предлагаемых курсов» человеку,
представляющему экземпляр класса «Контроллер регистрации».
1. Человек, представляющий экземпляр класса «Контроллер регистрации» ...
•I. ...Итак далее.
В ходе этой ролевой игры вы узнаете области ответственности каждого клас-
са. Пропущенные классы будут очевидны, когда у вас окажется мяч и не окажет-
ся класса, которому вы могли бы послать запрос на нужную услугу.
В этом описании дается чрезвычайно упрощенный взгляд на данную задаче
Дополнительные руководства вы можете найти в RUP, в задаче Анализ прецедеп
и использования (Use-Case Analysis). Как правило, выявляемые на этой стадии
операции будут высокоуровневыми, и многие из них впоследствии будут разби
пагься на несколько более мелких операций с участием большего числа объектов.
5'7/ вывести предлагаемые курсы))
6:// вывести бланк расписания))
1:// создать расписание)
: Форма записи на курсы
2:// получить список предлагаемых курсов
: Контроллер регистрации
37/ получить список предлагаемых курсов на семестр()
: Система каталога курсов
4:// получить список предлагаемых курсов
Каталог курсов
Рис. 17.3. Пример диаграммы сотрудничества. Диаграмма сотрудничества показывает динамику попе
дения прецедента использования. В ней указывается порядок проведения операций оГхч
печивающих функциональность прецедента использования (или части прецедента испо и.
зования). В данном примере, для того чтобы записаться на курсы, (1) Студент вызывает мс
тод «Создать расписание» экземпляра класса «Форма записи на курсы», (2) «Форма заиш и
на курсы» вызывает метод «Получить список предлагаемых курсов» «Контроллера pci и
страции» и т. д.
Руководство по RUP для разработчика
357
Шаг 3. Описание классов аналитической модели и ее унификация
В ходе ролевой игры нужно документировать обязанности (методы) каждого
класса, описывая эти методы и данные (атрибуты), которые этот класс должен
обрабатывать.
Следующий шаг - рецензирование обязанностей и связей выявленных классов.
Для этого нужно поработать с другими разработчиками и архитекторами и понять об-
щий стиль. На данном этапе необходимо удостовериться, что разные разработчики не
определили разные классы аналитической модели, делающие почти одно и то же
(в таком случае вам нужно будет решить, нужно ли эти классы объединять), а также
перестроить аналитическую модель, чтобы она укрепляла, а не разрушала архитек-
туру вашей системы. Нужно ответить на следующие вопросы.
• Существуют ли классы, которые нужно объединить или разделить?
• Какие требуются взаимодействия между классами?
• Есть ли возможности для повторного использования?
• Нужно ли обобщить некоторые классы?
В последующих шагах совершенствование аналитической модели будет
продолжено, и если вы захотите в будущем поддерживать данную аналитическую
модель отдельно, сделайте на этой стадии ее «моментальный снимок», чтобы
к ней можно было обращаться.
Шаг 4. Проектирование прецедентов использования
В ходе проектирования прецедента использования продолжается детализация
диаграммы кооперации, созданной в Шаге 2. Выполняйте эту работу параллельно
с Шагом 5. Подробно описывайте каждую операцию и ее параметры. Часто вы бу-
дете замечать, что ранее выявленные высокоуровневые операции следует разбить
на несколько более мелких операций, в которых, возможно, будут задействованы
дополнительно выявленные классы (один класс аналитической модели часто может
быть реализован двумя или более классами проектной модели см. ниже).
В тех прецедентах использования, для которых важен порядок выполнения
операций, вы, как правило, можете описать взаимодействие диаграммой последова-
тельностей, а не диаграммой кооперации (рис. 17.4). При реализации простых
прецедентов использования (таких, например, как онлайновый просмотр записей
в базе данных или обновление этих записей с учетом нескольких бизнес-правил)
и при использовании мощных языков программирования четвертого поколения,
таких как Visual Basic или PowerBuilder, как правило, не столь уж необходимо доку-
ментировать точную последовательность выполнения операций, поскольку об этой
логике (например, о синхронизации значений в разных полях окна с соответст-
358
Глава i
н\ ющими таблицами базы данных) заботится среда языка. В таких случаях вы М"
/Асю не беспокоиться о создании документации по взаимодействию для преце.к п
юн использования более подробной, чем Представление задействованных класич
(View of Participating Classes, VOPC) (рис. 17.2).
Студент
Форма записи вэ курсы Контроллер регистрации \ ' Сис1ема каталога курсов ,
Каталог кур ш
' 1://создать расписание^ ‘ 2:1/ получить список
f I------------предлагаемых курсов ’ 3;// получйв> предлагаемь„
- курсов на семестре
1 W'mt желает создать 1 jl 4://полупить список
.«„к. расписание . . j|----------------------------предлагаемых курсов
I ((ЛЮДИ ТСН список
гци-дл<инемых на этот
г ГМ1-1ЧР курсов
Выводится бланк
р-н,писания, чтобы
< гудечт мог выбрав
предложенные курсы
57/ вывести предлагаемые курсы()
6 // вывести бланк расписаниям
1’нс. 17.4. Пример диаграммы последовательностей. В диаграмме последовательностей даь ь
гаже информация, что и в диаграмме кооперации, по представленная в виде, даопь ।
лучшее представление о последовательности событий. Ход времени направлен спер
вниз. В каждой колонке представлен экземпляр класса, а стрелки указывают выполы-г.
мыс операции
Вы можете также использовать выявленные архитектурные механизмы, к •
|орые предоставляют решения таких проблем, как долговременное хранение
иыпмодействие процессов, управление транзакциями, безопасность, маршрут
шипя сообщений, сообщения об ошибках и т.п. (см. гл. 7, 16).
Шаг 5. Описание каждого класса проектной модели и ее унификация
Параллельно с разработкой прецедентов использования углубляйте описания
iii'cx классов проектной модели. Указывайте все операции, необходимые ;т
ключевых сценариев, а также необходимые атрибуты. Степень детализации
ючжпа быть достаточной для реализации класса. Часто один класс аналп
Руководство по RUP для разработчика
359
тической модели реализуется одним или более классом проектной модели.
Например, для реализации класса аналитической модели «Система каталога
курсов» вам может понадобиться несколько классов проектной модели, реали-
зующих долговременное хранение набора таблиц базы данных, и бизнес-прави-
ла, применяемые для обновления этих таблиц.
Поскольку класс проектной модели может задействоваться в нескольких разных
прецедентах использования, несколько разработчиков могут иметь свои собствен-
ные мнения о том, как должен выглядеть класс. Вам нужно решить, следует ли по-
зволять нескольким людям вносить изменения в класс проектной модели (и, следо-
вательно, совместно отвечать за реализацию и модульное тестирование компонен-
та). Если вы решите не допускать коллективной ответственности, то тем не менее
должен быть разработчик, ответственный за проектирование, реализацию и тес-
тирование каждого прецедента использования, чтобы возможности вашей системы
соответствовали ожиданиям пользователей. Нужно заметить, что коллективная от-
ветственность, как правило, хорошо работает в случае малых систем с опытными
разработчиками. При разработке более крупных систем разработчики не будут зна-
комы с крупными частями системы, и слишком велик риск, что они не смогут по-
нять сложностей необходимых изменений компонента. Такое также возможно
и в случае небольших систем с неопытными разработчиками, которые могут внести
много дефектов при изменении проектной модели или реализации компонента.
При проектировании классов помните о проектных шаблонах (design patterns),
например, шаблонах, разработанных так называемой «Бандой 4eTbipex»(Gang of
I-our)4. Эти и другие шаблоны могут оказаться полезными для решения обычных
проблем проектирования.
Как и в Шаге 3, при унификации проектной модели вам нужно работать со-
вместно с другими разработчиками и архитекторами. Нужно убедиться, что раз-
ные разработчики не определили разные классы, делающие одно и то же (в таком
случае вам нужно будет решить, нужно ли эти классы объединять), а также обес-
печить укрепление, а не разрушение архитектуры вашей системы проектной мо-
делью. Для примера, в многоуровневой архитектуре вам нужно не только решить,
на каких уровнях располагается тот или иной компонент, но также убедиться,
что взаимоотношения между компонентами не нарушают никаких установлен-
ных вами правил видимости между уровнями.
4. См. Gamma 1995. - Примеч. авт.
360 Глава I <
Реализация прецедентов использования и компонентов
Поскольку реализация прецедентов использования осуществляется по одном)
компоненту, некоторые из нужных вам компонентов могут уже быть реализованы
полностью или частично. В зависимости оттого, используете вы коллективнхю
ч|нетственность или нет, вы разрабатываете или совершенствуете компоненты
шбо самостоятельно, либо работая совместно с другими разработчиками, добп
каясь того, чтобы они поняли, что должно быть сделано. Проектная модель
может значительно облегчить такого рода общение.
В проекте должны присутствовать руководства по программированию на ие
пользуемом языке (языках), и вам, как разработчику, нужно следовать этим руко
но щтвам, чтобы в проекте присутствовала согласованность и оптимально^
использование языка. RUP предоставляет руководства по программированию для
некоторых языков (и вы можете использовать свои собственные руководства).
Некоторые разработчики обладают хорошим абстрактным мышлением
и всегда предпочитают сначала создать проектную модель, а затем реализовы
пап. ее. Другие разработчики считают более продуктивным выполнять основной
ооьем низкоуровневого проектирования в процессе написания кода. Все это
прекрасно. Делайте то, что максимально эффективно для вас, но не забывайте мо
шфпцпровать проектную модель в соответствии с изменениями кода, чтобы ко i
можно было легко обслуживать и он был понятен другим. Делать это гораздо
ил че с помощью среды визуального моделирования, которая позволяет разраба
и.шать код, используя «круговое» (round-trip) проектирование-^. С помощью
пчратиого проектирования вы можете фиксировать статическую проектную мо
le u., по вам еще нужно воссоздать динамику, то есть показать, каким образом
раыичные компоненты взаимодействуют друг с другом для обеспечения необхо
inмой функциональности.
Важно также осуществлять непрерывную интеграцию кода (см. ниже раздс i
Часто осуществлять интеграцию своего приложения с работой других
ра (работников»).
Во многих случаях проведение рецензирований кода может значительно
\ тучшить качество кода. Некоторые разработчики считают очень полезным
парное программирование, когда два разработчика пишут код, работая бок о бок.
(см. ниже раздел «Лучшие практические методы разработчика»).
’> Hound-trip engineering - подход, сочетающий периодическую генерацию кода из модели, его изменение
и п()рашое проектирование кода в визуальную модель. - Примеч. науч. ред.
Руководство по RUP для разработчика
361
Тестирование при разработке
Вы, как разработчик, должны постоянно тестировать написанный код, чюоы
убедиться, что он обеспечивает требуемую функциональность и производи!ель
ность. Как уже упоминалось ранее, рецензирования кода могут выявить некоюрыс
дефекты при помощи статического тестирования и анализа файлов исходного кода
но вам помимо этого нужно понять, ведет ли себя приложение так, как ожидасп. я
Единственным способом выяснить это является наблюдение за работой прюкъкс
ния входе его выполнения. Анализ времени выполнения (runtime analysis) lapan
тирует эффективность и правильность использования памяти вашим приложением
масштабируемость и скорость работы компонентов, и то, что вы протестирона ш
все перед тем, как положить файл в версионное хранилище.
Чтобы проверить, обеспечивают ли компоненты требуемую фупкцпоиа.и.
ность, вы можете спроектировать и реализовать тестовые драйверы и тестовые
заглушки, эмулирующие другие компоненты, которые будут взаимодепствоиа! ь
с вашим компонентом. Некоторые среды визуального моделирования могут аню
матически создавать такие драйверы и заглушки. Когда заглушки готовы, вы мо
жете выполнить несколько тестовых сценариев. Как правило, такие тестовые сне
нарии создаются по сценариям прецедентов использования, которые использхю!
данный компонент, поскольку в сценариях прецедента использования обычно
определяются типичные пути взаимодействия компонентов друг с другом при ис
пользовании приложения пользователем. Также, загляните в Дополнительные
спецификации (Supplementary Specification), чтобы узнать о прочих ограничен!!
ях, которые также необходимо протестировать.
Есть много других проблем, которые трудно будет вы-
явить на более поздних этапах проекта (например, такие как
утечки памяти и проблемы с производительностью). Вы, как
разработчик, можете значительно уменьшить количество
времени, необходимого для интеграции и тестирования сис-
темы, проводя для кода анализ времени выполнения. Анализ
Анализ времени вьин w
нения может зналI
тельно уменьшнн.
количество времена
необходимогодля инн
грации и тестировании
системы
времени выполнения проводится с помощью инструментов,
которые могут исследовать детально выполнение приложения для метода, обтек
та или строки исходного кода. Неадекватное использование памяти може,
значительно уменьшить возможности для масштабирования, и его очень трудно
оптимизировать на поздних этапах цикла разработки. В некоторых случаях
утечки памяти могут привести к сбою приложения, когда заканчивается доступ-
ная память. Еще одно основание для проведения анализа времени выполнения
это выявление «узких мест» производительности. Инструменты анализа времени
выполнения могут выявить в коде фундаментальную причину проблем произво-
362
Глава 1 /
дигслыюсти (рис. 17.5). Используя эти средства параллельно с рецензированием
прецедентов использования, вы сможете убедиться, что все часто используемые
сценарии использования имеют достаточно хорошую производительность.
Автоматизированные средства тестирования также помочь с определением ю
ю, какая часть кода протестирована. Это позволит оптимизировать тестирование
модулей и компонентов, охватив больше сценариев прецедентов использования
и обеспечить, таким образом, безошибочность кода. Если вы не тестировали коз
как вы можете узнать, функционирует ли он так, как ожидалось?
Highlight:
Functions with Source
IhowResult d
EnterCriticalSection
iBubbleSort! -
|ShowElapsedTime i н
4 !“*“-1
1lnew|Ehit
V— \
** delete iHb, 4.
i ...r % ч
isprintf -
SetDIgttemTerctA
LeaveCriticalSection
^output -
;free_dbg_lk':z
lock -
|malloc_dbg|;+’
Tree dl.g <-
Рис. 17.5. Анализ времени выполнения может выявить «узкие месит» производительности. Такие
средства, как Rational Purifyl’lus, отслеживают выполнение приложения или компонента и вы
являют ошибочное или излишнее использование памяти, «узкие места» производительноеш
и иетестированпый код. На этом снимке экрана мы видим потенциальные «узкие места», обо
зпаченные жирными линиями и показывающие, что выполнение этих операций осуществляв ।
ся намного медленнее, чем выполнение остального приложения. В случае каждого потении
ального «узкого места» разработчик может определить, действительно ли оно предсгавляе!
проблему, сравнив полученное изображение с часто используемыми сценариями, данными
в прецеденте использования
Руководство по RUP для разработчика
363
Проектирование, реализация и тестирование необходимых баз данных
В большинстве систем присутствует база данных, и вам нужно понять, как
данные будут храниться в ней и извлекаться из пес. Первое предложение - соз-
дать таблицу базы данных для каждого сохраняемого класса проектной модели,
с колонкой для каждого атрибута, содержащего сохраняемые данные. Это даст
очень упрощенный первый набросок логического уровня базы данных.
Если вы используете реляционные базы данных и выполняете обьектпо-ориен-
тированную разработку, вам нужно обратить особое внимание на то, когда и как
хранимые данные будут извлекаться из базы и помещаться в экземпляры объектов,
а также на то, как спроектировать физическую базу данных так, чтобы получить
нужный уровень производительности. Использование объектно-ориентированной
базы данных может существенно облегчить установление соот ветствий между клас-
сами и таблицами, поскольку многие действия выполняются автоматически.
В ходе фазы Проектирование вам нужно решить, каким образом осуществлять
в системе долговременное хранение, а потом разработать, реализовать и протес-
тировать один или несколько архитектурных механизмов, которые могут быт ь ис-
пользованы для решения вопросов долговременного хранения. Определите так-
же, основные структуры базы данных (таблицы, индексы, колонки первичных
и внешних ключей), необходимые для обеспечения архитектурно значимых сце-
нариев. Кроме того, в базу данных следует ввести репрезентативные данные для
тестирования производительности архитектуры. По результатам тестирования
производительности может потребоваться оптимизация модели данных,
включающая денормализацию (но не сводимая к ней), оптимизация физических
атрибутов хранения, распределение или индексация.
В фазе Построение к таблицам можно добавить дополнительные колонки, создан,
представления, чтобы упростить выполнение требований к запросам и отчетам, соз-
дать индексы для оптимизации производительности, но крупную реструктуризацию
таблиц проводить не следует. Это будет признаком нестабильности архитектуры,
слишком раннего начала фазы Построение или того, что в результате эволюции
требований в проект внесены архитектурные риски. Вы можете найти исчерпы-
вающее руководство в области проектирования баз данных в RUP (см. задачу Проек-
тирование баз данных (Database Design) и руководство Модель данных (Data Model).
Полезную информацию можно также найти в Ambler 2000.
364
Глава 1 /
Часто осуществлять интеграцию своего приложения с работой других
разработчиков
Нынуск демон- Частое проведение интеграции - это основной принцип итера
etpupyer часть на- тивной разработки. Когда вы интегрируете приложение, вы со ;
со/»возможностей, даете выпуск (build), представляющий собой рабочую версию
мнорые будет иметь системЬ1 или ее части демонстрирующей часть набора возмож
конечный продукт. „ „
ностеи, которые будут иметь конечный продукт.
Однако выпуск - это не то же, что релиз (release), который является
конечным результатом итерации. Если ваша итерация занимает месяц, вы можезе
создавать выпуски ежедневно, и каждый выпуск будет небольшим шагом
к релизу, запланированному на конец каждой итерации. Частые выпуски способ
с ту ют прогрессу разработки, поскольку позволяют проверить, что код, создан
ni.iii после последнего выпуска, правильно работает совместно с другим кодом
Выпуск может быть в чем-то нестабильным и обеспечивать ограниченный объем
(или вообще не обеспечивать) пользовательской функциональности. Напротив
релиз должен быть стабильным, предоставлять новую функциональность и спи
жать технические риски - все в соответствии с планом итерации.
Как правило, нужно старатся минимизировать время между выпусками, чтобы
обеспечить себя быстрой обратной связью, особенно на поздних этапах Построе
пия и Внедрения, но каждый выпуск имеет определенную стоимость. Чем боль
ше размер вашей системы и чем больше и распределеннее ваша команда, тем
юроже будет обходиться частое создание выпусков. Хорошая Система управле
пия конфигурациями с поддержкой автоматического управления выпусками мо
жег значительно снизить цену частого создания выпусков. Также заметим, чю
чем больше времени между выпусками, тем дороже будут сами выпуски
поскольку придется решать больше интеграционных проблем.
Команда из трех сидящих в одном месте разработчиков с очень примитивным
средством Управления конфигурациями, возможно, сможет делать выпуски еже
чиевно, но команда из сотни человек, разбросанная по нескольким разным мег
him, может создавать выпуски только еженедельно - в фазах Начало и Проск
шрование, раз в две недели - в фазе Построение и ежедневно - в фазе Внедре
пне. Та же самая распределенная команда из 100 человек без эффективной сиос
мы Управления конфигурациями сможет делать выпуски только раз в месяц, чн>
па практике существенно осложняет проведение итеративной разработки. При
мер того, чего можно достичь с помощью хорошей автоматизации и хорошел о
процесса Управления конфигурациями и изменениями - продукты компании Ra
Руководство по RUP для разработчика
365
tional, которые как правило, разрабатываются с использованием ежедневных вы-
пусков, по крайней мере в течение последних 100 дней до выхода крупного рели-
за. Эти выпуски объединяют работу нескольких сотен разработчиков (разбросан-
ных по многим местам на трех континентах), создающих различные редакции
Rational Suite.
Рабочие пространства Управления конфигурациями
По мере того как проекты становятся больше, все бо-
лее важным становится создание индивидуальных
рабочих пространств (workspaces). Рабочее пространство
обеспечивает каждого участника проекта средой, в ко-
торой и представлены соответствующие версии всех фай-
Рабочее пространство обес-
печивает каждого участника
проекта средой, в которой
и представлены соответа -
вующие версии всех файлов.
лов. Рабочие пространства позволяют управлять коллективным и индивидуаль-
ным использованием кода, чтобы разработчики могли не зависеть от изменений.
которые делают другие, но в то же самое время могли проводить модульное тес-
тирование своих изменений вместе с некоторыми чужими. Рабочее пространство
также выполняет роль «капсулы времени», позволяющей разработчику, анали-
тику, тестировщику и другим членам команды видеть предыдущие версии
двоичных файлов, документов, тестов, инструментов и прочих объектов. Эю
чрезвычайно полезно при сопровождении системы.
После того как разработчик реализовал и протестировал компонент или набор
компонентов и они оказались стабильными, разработчик помещает их в общее
рабочее пространство, часто называемое интеграционным рабочим простран-
ством. Тот, кто отвечает за создание выпусков, работает именно с компонентами
из интеграционного рабочего пространства. Это гарантирует, что выпуски будут
создаваться из компонентов, которые были проверены разработчиком.
Заметим, что средства Управления конфигурациями полезны для всех членов
команды, а не только для разработчиков, поскольку обеспечивают слежение за
всеми артефактами проекта.
Планирование интеграции
При использовании итеративной разработки постепенно становится все слож-
нее планировать выпуски и интеграционное тестирование. Для каждой итерации
нужно разработать План интеграции (Integration Build Plan), в котором указывает-
ся, какие возможности можно будет протестировать в каждом выпуске и какие
366
Глава 1 /
компоненты потребуется интегрировать, чтобы получить эти возможности, к ко
|орым относятся, например, прецеденты использования, части прецедентов
использования и другие тестируемые функции.
Планирование интеграции важно потому, что компоненты часто каким-то
о!>разом зависят друг от друга. Можно, например, по реализации прецедента ис-
пользования выяснить, что для обеспечения определенной возможности необходим
компонент А, но для компиляции компонента А может потребоваться наличие ком
понсптов В и С, а для компонента С может оказаться необходим компонент D и т. т
Но многих случаях может оказаться достаточно сделать лишь частичную реализа
пшо компонентов В, С и D. Это сэкономит вам массу времени, поскольку вы скоп
центрируетесь на существенных функциях и все равно будете иметь возможность
провести интеграцию системы. В Плане интеграции указывается, какие компонеп
пт должны быть разработаны. Он позволяет усовершенствовать План итерации
и попять, какие заглушки необходимо будет создавать.
Также нужно решить, какие версии компонентов должны быть включены
в выпуск. Это не всегда будут последние версии, поскольку разработчик може>
раоогать над реализацией следующих функций компонента, переведя его времен-
но в нестабильное состояние. Вам, как разработчику, необходимо сверяться
( IIчаном интеграции, чтобы разработка компонентов велась в правильном
порядке и они переносились в интеграционное рабочее пространство.
Создание выпуска
При создании выпуска разработчик отвечает за выпуск компонентов и их ни-
трацию в интеграционном рабочем пространстве согласно Плану интеграции
Н швисимости от сложности и количества интегрируемых компонентов часто бо
н с продуктивным будет пошаговое создание выпуска, когда с каждым Шагом
нюавляются новые компоненты и создается серия «мини-выпусков». Эти мини
выпуски подвергаются небольшому интеграционному тестированию (обычно
! осюящему из части тестов, описанных в Плане интеграции для всего выпуска),
ыпорое проверяет совместимость добавленных компонентов с тем, что уже име
оси в интеграционном рабочем пространстве. При таком подходе намного легче
и нитровать и диагностировать проблемы.
И/ и t числом создании
винусков нужно авто-
мо! и. /ировать регрес-
। чо! нюе тестирование,
•и, Ч'ы снизить стои-
МОСН, ! ОСТОВ.
После создания выпуска, все разработчики должны
перестроить свои рабочие пространства, добавив в них
разработки других членов команды. Выпуск передается па
тестирование, чтобы тесты производились по ходу работы над
следующим выпуском. При частом создании выпусков нужно
Руководство по RUP для разработчика
367
автоматизировать регрессионное тестирование, чтобы снизить стоимость тестов.
| Таким образом сотни и тысячи регрессионных тестов могут проводиться еже
| дневно или еженедельно, что гарантирует быстрое обнаружение появляющихся
f дефектов.
। Лучшие практические методы разработчика
; В данном разделе мы опишем некоторые наиболее популярные практические
методы проектирования, реализации и модульного тестирования кода. Кроме к>
го, мы покажем, к чему применимы эти методы. Многие из них уже были иону
лярны ранее, но они подверглись дальнейшему усовершенствованию и иону
ляризации со стороны Движения за гибкую разработку (Agile Movement), оси
бенн со стороны ХР6. Некоторые их этих практических методов мы описывачн
ранее в этой главе:
• Частое тестирование (см. разделы «Тестирование при разработке» и «Со via
ние выпуска»).
• Непрерывная интеграция (см. раздел «Часто осуществлять интеграцию сво
его приложения с работой других разработчиков»),
• Проведение анализа времени выполнения (см. раздел «Тестирование при
разработке»).
Из других практических методов можно назвать следующие.
• Тесты вперед.
• Переработка кода.
• Использование схем, архитектурных механизмов и других повторно hcikhii.
зуемых средств и методов.
• Упрощение проектной модели.
• Парное программирование.
Тесты вперед
Идея подхода «тесты вперед» (Test First)7 состоит в том,
чтобы сначала написать и реализовать прецеденты тестирова-
ния (test cases), а потом писать код. Код пишется так просто,
как только возможно, а потом совершенствуется пока не будут
выполнены все прецеденты тестирования. Программист вы-
бирает задачу, пишет один-два простых модульных прецеден-
Идея подхода «п чзы
вперед» состои! в том.
чтобы сначала написан,
и реализовать прецеде1иы
тестирования, a not ом
писать код
6. См. Beck 2000. - Примеч. авт.
368
Глава I
1.1 юстирования, которые не выполняются, поскольку модуль не выполняет задаю
a зшем модифицирует программу так, чтобы тесты выполнялись. Программист ы>
егоянно добавляет все новые и новые прецеденты тестирования и заставляй
программу выполнять их до тех пор, пока программа не будет делать все, для чею
<>на предназначена. Если вы применяете данный подход, вам лучше комбинирован
по с переработкой кода (refactoring), или вы в результате придете к чрезмерно слоя
ной реализации. Подход «тесты вперед» хорошо работает при использовании под»
ал, основанного на прецедентах использования, поскольку они дают хорошую ба
дня раннего выявления прецедентов тестирования. Кент Бек (Kent Beck) идрхыь
i.iiokc работают над подходом, называемым Test-First Design (Проектирование на о<
ноне подхода «тесты вперед»), который описывает механизм ин теграции мсти । •
ice гы вперед» в процесс проектирования.
Переработка кода и проектирование
Переработка кода (refactoring)* 8 - это создание компонента или набора комн»
пен iob путем внесения многочисленных небольших четко определенных измен>
iniii. направленных на совершенствование их структуры без изменения их (])\ in
циоиальности. Целью является упрощение п совершенствование имеющей ю ।
решения для получения более высококачественного и легкого в обслуживании
mi ia. После каждого небольшого улучшения нужно пройти тесты и убеди in ।
в 1ом. что ничего не нарушилось. Это означает, что нужно комбипирон.т
переработку кода с методом «тесты вперед». Комбинация этих двух мело нч
\ спешно применяется во многих проектах.
Заметим, что переработку кода нельзя использовать как замену хорошей проем
ной модели и архитектуры. Возможности переработки кода ограничены. Так о
важно помнить, что лучшее - враг хорошего9. Бывает так, что компонент дос । .1
।очно структурирован и дальнейшие улучшения будут очень плохо окупаться.
I См. Beck 2000. - Примеч. авт.
В См. Newkirk 2001 и Fowler 1999. - Примеч. авт.
'I См. Glib 1998. - Примеч. авт.
Руководство по RUP для разработчика
369
Использование шаблонов, архитектурных механизмов и других
повторно используемых решений
Подход «эго сделано не у нас» - главное препятствие на пути к тому, чнюы
стать хорошим разработчиком. Вместо того чтобы вставать на эту позицию, iivzk
но поискать возможности для повторного использования работающих решении
Вы должны знать используемые в ваших проектах архитектурные механизм!.!
шаблоны, предлагаемые производителем платформы и другими источниками'1
Естественно, вы можете также применять такие источники, как библиотеки клас
сов, и другие компоненты сторонних производителей. Заметим, что для уменыне
ния возможных обязательств некоторые компании вводят четкие ограничения
на использование условно-бесплатных компонентов.
Тесное сотрудничество с архитектурной командой и периодическое обрате
ние к Описанию архитектуры программы должны помочь вам максимизирован,
повторное использование кода. Если ваша компания производит повторно не
пользуемые компоненты и другие активы (assets), вам нужно подумать о том. ч н>
бы документировать и размещать их в пакетах в соответствии со стандартом, на
зываемым Reuse Asset Specification11 (RAS). В этой спецификации содержа кя
руководства по структурированию и документированию этих активов таким
образом, чтобы их можно было легче понять и использовать. Повторно исполь
зуемые компоненты стандарта RAS легко распознаются и распаковываются
другими инструментами, такими как Rational XDE.
Используйте простые решения
Основная идея, стоящая за использованием простых
решений, - это проектировать только то, что нужно в данный
момент. Исходная посылка состоит в том, что когда вы
проектируете будущие возможности, вы не имеете доста-
точной информации для выбора верных решений. И это, как
правило, заканчивается использованием более сложных
Вам нужно сохранчи.
равновесие между ///»< •
имуществами проа /./1
решений и выгодами <н
продумывания будущих
проблем.
решений, это нужно для той проблемы, которую вы стараетесь решить.
С другой стороны, если вы создаете проектную модель, не принимая во вни-
мание будущие возможности системы, вы можете выбрать неоптимальное реше-
ние, требующее существенной переработки. Вам нужно сохранять равновесие
между преимуществами простых решений и выгодами от продумывания пред- 10 11
10. См. Gamma 1995. - Примеч. авт.
11. Спецификация многократно используемого кода. - Примеч. науч. ред.
370
Глава I /
поящих ходов. Чем более вы опытны и чем лучше вы знаете, как будет вьпля
чегь будущее приложение, тем дальше вперед вы сможете просчитать ходы
Однако будьте осторожны и не вносите ненужной сложности, что сделает ваш
продукт запутанным и сложным для поддержки.
При проектировании всегда работайте совместно с архитектором, чтобы
проектные решения соответствовали общей архитектуре. Архитектор также мо
/ке । помочь с равновесием между простотой и расчетом на будущие возможное! н
Парное программирование
11арное программирование12 - это метод, когда два разработчика работают па i
созданием кода вместе, на одной рабочей станции. Один разработчик сидит за ма
шиной, а другой наблюдает и внимательно просматривает создаваемый ko i
I йппущий мыслит тактически, и его в первую очередь заботит код. Наблюдатс п
проверяет синтаксис и думает о стратегии всей программы. Важно, чтобы
разработчики почаще менялись ролями.
Многие проекты, а также предварительные исследования показали, что при
парном программировании код пишется с меньшим количеством ошибок, чем ко
|да его пишет один разработчик13. Однако многим людям данный метод нс
правится, они считают, что это замедляет работу опытных программискш
Как и в других практических методах, вам нужно выяснить, что будет соотвею
вовать вашему проекту, культуре организации и личным особенностям
разработчиков.
Роль разработчика в Рациональном унифицированном процессе
В RUP дается более детальное представление роли р азработчика через опнеа
пне более специализированных ролей. В данной главе описываются области m
негственности специализированных ролей (в приведенном списке курсивом!
Роли архитектора программного обеспечения и рецензента архитектуры описаны
в 1лаве 16, а роль проектировщика тестов - в главе 18. Мы не описываем в данноп
книге роль проектировщика капсул, поскольку эта роль применима только к еп<
1емам реального времени.
• 11роектировщик капсул (Capsule Designer)
• Рецензент кода (Code Reviewer)
12. См. Martin 2001 - Примеч. авт.
I3. См. Williams 2000 - Примеч. авт.
Руководство по RUP для разработчика
371
Проектировщик баз данных (Database Designer)
Программ ист (I mр le mе nter)
Интегратор (Integrator)
Архитектор программного обеспечения (Software Architect)
Рецензент архитектуры (Architecture Reviewer)
Рецензент проектной модели (Design Reviewer)
Проектировщик (Designer)
Проектировщик тестов (Test Designer)
Ресурсы для разработчиков
Ниже приводятся некоторые ресурсы для разработчиков, желающих лучше
понять, как работать в RUP-проекте.
Рекомендуемая литература
Scott Ambler and Larry Constantine. The Unified Process Construction Phase.
Lawrence, KS: CMP Books, 2000, pp. 163-170.
Kent Beck. Extreme Programming Explained: Embrace Change. Boston: Addison-
Wesley, 2000.
Grady Booch. Object-Oriented Analysis and Design with Applications, Second Edi-
tion. Menlo Park, CA: Addison-Wesley, 1994.
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns:
Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley.
1995.
Philippe Kruchten. The Rational Unified Process: An Introduction, Second Edition.
Boston: Addison-Wesley, 2000.
James Newkirk and Robert Martin. Extreme Programming in Practice. Boston: Ad-
dison-Wesley, 2001.
372 Глава l i
Рекомендуемые учебные курсы
Ниже приведены учебные курсы, разработанные в целях поддержки пользова
юлей RUP. Созданы они компанией IBM Software и ее партнерами (более подрой
ную информацию см. на www.rational.com).
• Principles of the Rational Unified Process: Web-обучение.
• I essentials of the Rational Unified Process: с инструктором (два дня).
• Principles of Visual Modeling: Web-обучение.
• Principles of Use-Case Modeling with UML: Web-обучение.
• Principles of Analysis: Web-обучение.
• Object-Oriented Analysis Using UML: с инструктором (три дня).
• Object-Oriented Design Using UML: с инструктором (четыре дня).
а. л
л £
ГЛАВА 18
Руководство по RUP для тестировщика
А что хорошо, Федрус,
И что плохо -
Зачем кого-то спрашивать об этом?
(Платон, ок. 370 до н.э.)
Вы - тестировщик и отвечаете в своей организации за какой-то из аспектов
проверки качества. Эта глава поможет вам начать использовать RUP. Вы найдете
здесь описания основных концепций, используемых в RUP и относящихся к тес-
тированию, нашу философию тестирования, описание ключевых артефактов,
за которые вы можете быть ответственны. Мы познакомим вас с основными
задачами, в которых принимает участие тестировщик1.
Миссия тестировщика
| Главная цель тестировщика - это, в первую очередь, объективная оценка. Тес-
( тировщики предлагают свои услуги по оценке программного продукта на основе
определенных критериев, таких как воспринимаемое качество1 2, соответствие стан-
дартам и выявление дефектов, прочим частям организации, разрабатывающей
программное обеспечение. Такая оценка помогает другим членам команды
(разработчикам, менеджерам и даже заказчикам) принимать правильные решения
1. Эта глава была подготовлена совместно с Полом Шимковяком (Paul Szymkowiak). - Примеч. авт.
2. Perceived quality - иногда переводится также как ожидаемое или субъективное качество. Характеризует оценку
качества товара покупателями или возможными покупателями. - Примеч. науч. ред.
374 Глава i«
о дальнейших действиях на основе подтверждаемой и объективной информации
Всякий, кто серьезно относится к созданию отличного продукта, сталкиваем <
и частности, с двумя проблемами.
• Как узнать, когда продукт «достаточно хорош»?
• Если продукт недостаточно хорош, как добиться того, чтобы ваши соратники
это поняли?
Ответ на первый вопрос определяет время, когда организация выпустит продх к ।
( Ивет на второй вопрос не дает выпустить некачественный продукт.
Концепция качества продукта в RUP
Вы можете думать так: «Я не хочу выпускать просто удовлетворительный
продукт. Я хочу выпустить великолепный продукт». Давайте разберемся. lli«
произойдет, если вы скажете своим сотрудникам, менеджерам или инвесторам
чю у вас высокие стандарты качества и вы хотите выпустить великолепный
продукт? Если это начало проекта, они, скорее всего, покивают и улыбну пи
Качество нравится всем. Однако, если это поздние стадии проекта, вы, скоры
всего, окажетесь под сильным давлением в направлении завершения проем.।
а создание великолепного продукта потребует массированного тестирования
исправления множества ошибок (даже мелких), добавления функций и д:ьы
о1брасывания и переписывания большого объема кода. Вам также придем т
разрешать конфликты различного видения «хорошего» качества. Великолепна
ipeoycT тяжелой работы. Совершенство - еще более тяжелой. В конечном счен
ie, кто управляет проектом, придут к вам и скажут что-нибудь вроде: «Совершен
। ню было бы замечательно, но нам нужно быть практичными. Мы ведем бизпш
качество - это хорошо, но не качество любой ценой. Вы знаете, что ошибки сс 11
по всех программах».
Совершенство может быть стимулом. Оно выражает гордость, которую мы in
пыгываем за свою работу. Однако проблематично определить, какая доза принципа
«если качество хорошо, то больше качества - лучше» оправданна в погоне за со
нсршснством. С одной стороны, приводя такой аргумент, вы будете выглядеть тон
фанатик, а не как уравновешенный мыслящий человек. С другой стороны, здесь ш
вирируется фактор стоимости. Без внимания к стоимости аргумент «чем болыы
м'м лучше» игнорирует снижение окупаемости. Чем лучше продукт, тем сложны
оправдать дальнейшие улучшения. Пока вы до блеска отшлифовываете один аснск i
продукта, вы должны игнорировать прочие аспекты и потенциальные возможное i и
If
it Руководство no RUP для тестировщика 375
которые дают другие проекты. Ежедневно в бизнесе приходится принимать реше-
ния, как лучше использовать ресурсы, нужно принимать во внимание и другие фак-
торы помимо качества.
В RUP использована и расширена концепция Достаточно хорошего качест ва
(Good Enough Quality, GEQ) из работы Джеймса Бэча (James Bach)3. Парадок-
сально, но эта концепция предлагает более эффективный тезис, чем «чем больше,
тем лучше», поскольку она создает цель, достижимую или недостижимую, где
в последнем случае она становится аргументом de facto за отказ от проекта или
его пересмотр.
Понятия о «достаточно хорошем»
| В большинстве фирм практикуется какая-нибудь форма обоснования того, что
| свои продукты «достаточно хороши». И только те, которые считают, что достигли
| совершенства, этого не делают, поскольку не обладают достаточной фантазией и иа-
| выками, чтобы увидеть, как их продукты можно улучшить.
J Вот некоторые образцы «достаточно хорошего». Некоторые из них более эффск-
I тивны, чем прочие, в зависимости от ситуации, но во всех есть свои слабости.
j • Не слишком плохо («Еще пока не умерли»). Качество наших продуктов долж-
| но быть достаточным лишь для того, чтобы мы могли по-прежнему оставаться
J в бизнесе. Сделаем его хорошим настолько, чтобы нас не засудили.
( • Абсолютная непогрешимость («Хорошо все, что мы делаем»). Наша орга-
5 низация - лучшая в мире. Поскольку мы такие хорошие, все что мы делаем -
( это хорошо по определению. Думай об успехе. Не думай о неудаче, потому что
i «негативное» мышление способствует плохому качеству.
J • Праведное изнеможение («Совершенство или смерть»). Ни один продую
| не бывает достаточно хорош. Ценны только усилия. И только полное изнемо-
t жение будет достаточно хорошей степенью усилий. Бизнес - не наша забота.
| Мы сделаем все, что возможно для совершенства. Поскольку совершенствова-
| ние продукта никогда не прекратится, кто-то должен придти и «выдрать» его
| из наших рук, если это им надо. И на них, а не на нас ляжет вина за проблемы
| с качеством.
| • Заказчик всегда прав («Кажется, заказчику нравится»). Если продукт нра-
вится заказчику - значит он наверняка достаточно хорош. Конечно, нельзя
Ё угождать всем и всегда, и если заказчику, действительному или потенциалыю-
3. См. Bach, 1997. - Примеч. авт.
376
Глава
му, продукт не нравится, именно он должен дать нам знать об этом. Мы не м<>
жем читать его мысли. Что значит «качество определяется твоей долей на
рынке»?
• Установленный процесс («Мы применяем хороший процесс»). Качество
это результат того процесса, который мы используем при создании продукт
Мы определили свой процесс и мы думаем, что это хороший процесс. По м о
му, пока мы следуем этому процессу, качество будет неизбежным результатом
• Статические требования («Мы выполняем требования»). Мы определяем
качество в форме объективных, количественно измеримых и бесспорных не
лей. Если мы достигнем этих целей, получим достаточно хороший продукт нс
зависимо от того, какие субъективные, количественно неопределяемые н т
спорные цели могли подразумеваться.
• Отчетность («Мы выполняем наши обещания»). Качество определено i
контракте. Мы обещаем сделать определенные вещи и достигнуть определен
пых целей. Если мы выполним наш контракт, это будет достаточно хорошо.
•Адвокаты («Мы сделали все, что было нужно ст-
лать»). Мы - сторонники совершенства. На всем при
тяжении проекта мы искали способы предотврати
проблемы и найти и исправить все те, которые цель ।
предотвратить. Если мы честно работали, двигая нр--
дукт к совершенству, это достаточно хорошо.
•Динамические компромиссы («Мы взвесили мн<>
жество факторов»), В соответствии с нашей мисси,-и
и конкретной ситуацией продукт будет достаточно хорош, если он дает с\ ив
ственные преимущества и не имеет критических проблем. Его существенны,
преимущества значительно перевешивают его некритические проблемы
и дальнейшее улучшение принесет больше вреда, чем пользы.
Цена качества
Обязательно ли более высококачественный продукт будет более дорогое и и
щпм? Приняв во внимание множество факторов, таких как процесс, профессии
папизм, технология, инструменты, окружение и культура, вы можете создан, n.i
много более высококачественный продукт за ту же самую цепу, чем это было оы
возможно в ином случае. Совершенствование более удобного для тестирован,и
Однако в некоторых типах
приложений, для которых
безопасность является кри-
тическим фактором и которые
метут подвергать опасности
человеческую жизнь, аварии
/а точнее, некоторые типы
аварий) просто недопустимы.
Руководство по RUP для тестировщика
377
и поддержки продукта обходится дешевле в дол! осрочпой перспективе. И на-
оборот, плохое качество имеет свою цепу, например стоимость обслуживания
и стоимость для заказчика.
Цена качества - проблема сложная, и здесь зрудно делать
широкие обобщения. Тем не менее мы можем с определенно-
стью сказать, что всегда можно потратить больше времени на
более хорошие тесты, на работу над ошибками и на исиравле-
Цена качества - про-
блема сложная,
и здесь трудно делать
широкие обобщения.
ние и переписывание частей продукта. Независимо от того, насколько хорошо вы
работаете, качество имеет какую-то цену. А если вы не можете придумать ника-
ких улучшений, то, скорее всего, вы достигли пределов своей фантазии, а не
качества. Должна существовать «точка неокупаемости», когда «окупаемость
(ROI) теста» становится отрицательной.
В программной индустрии «достаточно хорошее качество» рассматривается
чаще как ответ на ситуацию, когда одна цена превышает все прочие - цена невы-
хода продукта в достаточно короткие сроки. Призрак ниши на рынке или внешне
установленные сроки налагают' на нас вполне материальные наказания, если мы
не можем выпустить продукт вовремя. Вот почему окончание проекта так часто
характеризуется яростными доделками. Если вы хотите узнать, что организация
считает достаточно хорошим и насколько она готова к этому, понаблюдайте за по-
следними тремя днями шестимесячного проекта. Посмотрите, что произойдет,
когда в последний день всплывет новая проблема.
А не поможет ли количественная оценка?
Может показаться заманчивым свести качество к цифрам и
установить количественный порог, отражающий достаточно
хорошее качество. Проблема состоит в том, что вы можете из-
мерить только параметры, относящиеся к качеству, но не само
качество. Частично это объясняется тем, что «качество» - это
Вы можете измерить
только параметры, от-
носящиеся к качеству
но не само качество.
просто название для взаимоотношений между человеком и предметом. Сказать «энн
продукт имеет высокое качество», это все равно что сказать «этот продукт кому-то
нравится». Эта сентенция не только о продукте, но также и о людях, и о конкретном
контексте. Если даже продукт остается одним и тем же, меняются люди и ситуации,
поэтому нет и не может быть одной статичной и истинной меры качества. Прочитaii-
те (или перечитайте) книгу Роберта Перспга (Robert Pirsig) «Дзен и искусство обсл\ -
живания мотоцикла» («Zen and the Art of Motorcycle Maintenance»), в которой
378
Глава l
н'воригся: «На переднем крае нет субъектов и объектов, а есть лить путь качесим
и если у вас нет формальных способов оценить, нет способа осознать это качеспи
и, поезд не сможет узнать, куда ехать»4.
Существует много показателей, позволяющих почувствовать качество, даю
«е ли вы не можете измерить его объективно и полностью. И даже при л ом
вопрос о том, какое качество будет достаточно хорошим, требует искушенною
ни тяда. Вы не можете убежать от того факта, что в конечном итоге нужно 6y.ici
нес продумать и вынести оценку. Для простого продукта такую оценку можно вн
।к с । и легко, для большого, многоярусного продукта - очень сложно. Такое репы
пне нс входит в обязанности тестировщика, но тестировщик предоставляе, пп
формацию для этого решения. Наконец, определение качества также зависш ю
оитасги проблемы. Качество для NASA или для хирургической автоматики очеш
и пинается от качества для рабочей станции службы работы с клиен тами и ю
качества для фондовой биржи.
Соответствие стандартам
Оценка подразумевает сравнение продукта с определенным стандартом и ш
пилоном. Образец для сравнения, который часто приходит на ум, - это снецифп
мини на систему. Могут существовать и другие стандарты: либо формальные. । .1
кие как стандарт удобства использования (Usability standard) пли стандарт yw
i ны обслуживания (Accessibility standard), либо неявные стандарты, такие к.и
внешний вид и общее впечатление (например, желание, чтобы продукт coohu-i
। 1 повал соглашениям Windows 2000). Бывают также стандарты, спсцифич 1111.
гы отраслей промышленности, например стандарты биомедицинской отрае ш
фармацевтической отрасли, аэрокосмической отрасли и т.д.
На практике оценка - это не только сравнение программного прадии
। i реновациями и прочими артефактами-спецификациями. Мы используем (яг. и.'
ипп неявно) и другие стандарты, показывающие приемлемость качества. Пси, и
важные проблемы, которые часто требуют более широкого рассмотрения, чем т
к\монтируется в спецификациях.
• Являются ли сами спецификации полными? По своей природе спецификации
эго нечто абстрактное и развивающееся на протяжении жизни проекта по мор
того, как растет понимание проблемы и находятся подходящие решения. Io,
ли еще что-то, что нужно оценить и что может оказаться двусмысленным и и
упущенным в спецификациях?
I См. Pirsig, 1977, р. 277.
Руководство по RUP для тестировщика
379
• Какие исключительные события или условия могут привести к сбою
в программе? В спецификациях часто не указывается множество исключи тель-
ных ситуаций, которые, бесспорно, более очевидны для тестировщика. Это ино-
гда объясняется тем, что составитель требований (аналитик) не знаком с неко-
торыми аспектами или областью проблемы или с тем, что требования к исключи-
тельным ситуациям являются подразумеваемыми.
Прилежный тестировщик может придумать тесты, которые помогут выявить
проблемы, возникающие из-за неявных или пропущенных требований.
В Плане обеспечения качества (Quality Assurance Plan), который является
частью Плана разработки программного обеспечения и входит в компетенцию
менеджера проекта, полностью описывается подход к достаточно хорошему
качеству (GEQ), а также методы, которые будут использоваться для оценки дос-
тижения приемлемого уровня качества (см. также гл. 12).
Что такое тестирование?
Дисциплина Тестирование (Test) в RLJP во многих отношениях похожа иа по-
ставщика услуг для других дисциплин. Тестирование концентрируется в первую
очередь на оценке или проверке качества и реализуется с помощью нескольких
основных практических методов.
• Выявление и документирование ошибок в концепции достаточно хорошего
качества.
• Общие консультации для членов команды по воспринимаемому качеству про-
граммного обеспечения.
• Подтверждение с помощью конкретной демонстрации допущений, сделанных
в проектной модели и спецификациях.
• Проверка того, что программный продукт функционирует так, как он должен
функционировать.
• Проверка того, что требования были реализованы должным образом.
Любопытное, но тонкое различие между дисциплиной Тестирование
и прочими дисциплинами RUP состоит в том, что тестирование имеет целью об
наружение и демонстрацию слабостей программного продукта. Чтобы доишься
успеха, тестирование использует несколько негативный, деструктивный, а не кон
структивный подход. «Как вывести из строя эту программу?». Проблема в том.
380
Глава Hi
чтобы избежать такого подхода, который не будет правильно и эффективно
нагружать программу и демонстрировать ее скрытые проблемы и слабости, и ы
кого, который окажется слишком негативным и вряд ли когда-либо сочтет качес i
во продукта приемлемым.
Информация, представленная в различных обзорах и статьях, говорит, чю
иатестирование программного обеспечения уходит от 30 до 50% всех расходив
на разработку. Поэтому достаточно удивительно, что большинство людей думас i
что программное обеспечение перед выпуском тестируется плохо. Это прош
воречие является следствием нескольких главных причин.
• Тестирование обычно проводится на поздних стадиях жизненного цикла, а н<
в каждой итерации, как пропагандируется в RUP, поэтому число рисков проев
та и неизвестных факторов слишком долго остается очень высоким.
• Удобство для тестирования не принимается во внимание при проектировании
продукта (в отличие от того, что пропагандируется в RUP), и, следовательно
многократно повышается сложность тестирования, затрудняется автоматизация
тестов, а некоторые тесты делаются вообще невозможными.
• Планирование тестов осуществляется без связи с тестируемой системой, ю
проведения конкретных тестов, когда о тестируемой системе известно меныж
всего. В RUP же пропагандируется подробное планирование тестов по итера
циям, с применением опыта предыдущих итераций.
Даже не принимая во внимание эти проблемы, мы должны признать, что ici
гирование программного обеспечения - дело чрезвычайно сложное. Разные m ш
развития событий в данной программе не поддаются количественном \
измерению, и число возможных тестов для данной программы ограничено тольм
фантазией тестировщика.
Как правило, тестирование производится без всякой методологии, что приво;нп
к различному уровню успеха от проекта к проекту и от организации к организации
Успех является в основном функцией качества, профессионализма и oiii.h.i
конкретного тестировщика. Тестирование страдает также от недостаточного m
пользования инструментов повышения производительности, которые позволяй и
управлять трудоемкостью тестирования. Часто тестирование производится без пи
струментов, которые позволяют эффективно управлять накопленными средствами
и методами тестирования, например объемными тестовыми данными (Test Dalai
без инструментов подробной оценки результатов тестирования и без соотвекч
вующей поддержки автоматического выполнения тестов. Хотя богатство возможно
стей применения и сложность программ делает «полное» тестирование вообще нс
Руководство по RUP для тестировщика
381
достижимой целью, но в большинстве обычных программ при правильно по-
добранной методологии и при использовании верных инструментов поддержки
можно улучшить производительность и эффективность тестирования.
В системах, для которых безопасность является критическим фактором, где
авария может причинить вред людям (например, авиадиспетчерские системы,
системы наведения ракет или медицинские системы), высокое качество
программного обеспечения является необходимым условием успешной работы.
Для информационных систем критичность может быть не столь очевидна, как
для предыдущих, но вполне вероятно, что серьезный дефект может обернуться
для предприятия, использующего программное обеспечение, значительными
затратами в виде потерянных доходов или возможных судебных издержек. В наш
век информации, с его возрастающими требованиями к электронному предостав-
лению услуг через такие среды, как интернет, многие информационные системы
рассматриваются как критичные для работы, то есть когда в таких системах
происходит программный сбой, компании не могут функционировать нормально
и терпят крупные убытки.
Во многих проектах до самого конца цикла разработки не
уделяется достаточного внимания тестированию производи-
тельности. В системах, которые будут использоваться не-
прерывно (24 часа в сутки, 7 дней в неделю), в распределенных
системах и в системах, которые должны будут расширяться
и поддерживать параллельную работу с множеством пользова-
телей, важно с самого начала и непрерывно проверять, будет ли
Важно с само/о
начала и непрерыв
но проверять, бу/1<ч
ли производитель
ность соответсш)
вать ожиданиям
производительность соответствовать ожиданиям. Начинать тестировать систему
с разной нагрузкой нужно уже в фазе Проектирование, когда достаточная час i ь
архитектуры уже создана.
Постоянное стремление к качеству, начиная с ранних
стадий жизненного цикла, может существенно снизить
стоимость создания и поддержки программного обес-
печения. Это значительно снижает риск создания не-
качественной программы.
Постоянное стремление л
качеству, начиная с ранних
стадий жизненного цикла,
может существенно снизив,
стоимость создания и под
держки программного обее
печения.
Философия тестирования в RUP
В традиционном каскадном подходе до 80% времени тестирования в проекк-
может уйти на планирование тестов и определение прецедентов тестирования
(а не на проведение собственно тестирования). Затем, ближе к концу жизненно! <>
382
Глава 18
цикла, 20% усилий тратится на запуск и отладку тестов. Часто еще 20% (да, за
границы мы уже вышли!) требуется на исправление тех частей продукта, которые
не прошли тестирование.
Философия тестирования RUP использует другой подход, который можно
описать небольшим набором принципов.
• Итеративная разработка. Тестирование начинается не только с планов тес
тирования. Сами тесты разрабатываются и выполняются рано, и полезная час и
их накапливается в наборах для регрессионного тестирования, от итерации
к итерации. Это дает возможность рано установить обратную связь и получаи.
важную информацию от остальной команды разработчиков, что позволяет са
мим тестам становиться все более зрелыми по мере того, как углубляется пони
мание области проблемы и решений, а также позволяет включать в разви
вающуюся проектную модель необходимые механизмы, обеспечивающие удои
ство тестирования. Чтобы принять во внимание смену тактических целей геч
I ировщика в ходе цикла разработки, мы вводим понятие «миссия».
• Уменьшение объемов готовящейся заранее документации. Подробное ила
пирование тестов проводится от итерации к итерации в соответствии с основ
ным Планом тестирования с учетом нужд команды и целей итерации. Например
в ходе фазы Проектирование акцент делается на архитектуре, и тестирование
должно концентрироваться на главных архитектурных элементах, развивающих
ся с каждой следующей итерацией. Нужно оценивать производительность глав
ных сквозных сценариев (обычно под нагрузкой), даже если пользовательский
интерфейс пока рудиментарный. Другой заранее создаваемой документации, по
мимо этого полуформального артефакта, не должно быть много.
• Холистический подход5. Подход к выявлению необходимых тестов не основы
вается прямо и единственно лишь на создании тестов по имеющимся требоваии
ям. В конце концов в требованиях редко указывается, что система не должна де
лать. В них не перечисляются все возможные сбои и источники ошибок. Эн>
нужно брать откуда-то еще. В RUP тесты создаются на основе требований и др\
гих источников. Мы рассмотрим этот принцип позже вместе с концепцией егш
ска идей тестов.
• Автоматизация. Тестирование начинается на ранних этапах жизненного цик
ла RUP, повторяется снова и снова и может занимать очень много времени, таг
что многие аспекты должны иметь инструментальную поддержку, то ecu.
!). См. Pirsig, 1977, стр. 277
Руководство по RUP для тестировщика
383
должны быть инструменты для проектирования тестов, для запуска тестон
и для анализа результатов.
Миссия
Концепция миссии оценки в том виде, в каком она используется в RUP, основан а
на работе Джеймса Бэча (James Bach), в которой приводятся различные миссии,
обычно используемые командами тестировщиков программного обеспечения. 1> >ч
выступает за использование простой эвристической модели планирования icciob
В этой модели признается, что миссия определяет задачи и продукты тестирования
и что выбор соответствующей миссии является ключевым аспектом планирования
тестов6.
Миссия оценки представляет собой простое утвержде-
ние, которое группа тестирования должна помнить, что-
бы удерживать акцент на общей цели и соответствующих
продуктах в каждой итерации. Это особенно важно в тех
ситуациях, когда команда сталкивается с несколькими,
возможно, конфликтующими миссиями. Тестировщики,
не использующие миссию, часто описывают свои цели,
Миссия оценки предстаи/м ч
собой простое yieepMeiuit •
которое группа тестир >и. ним
должна помни и,,
удерживать акцент на <Х>Щ1 -и
цели и соответствующих нр>
дуктах в каждой шер тцип
например, таким образом: «Мы тестируем все» или «Мы просто занимаемся >сс
тированием». Их заботит простое выполнение тестовых задач, и они упускаю i п
виду то, как эти задачи можно подогнать под контекст конкретного проема ч ня
достижения соответствующей цели.
Эти формулировки миссий не должны быть слишком сложными НЛП ы
ключать в себе слишком много конфликтующих целей. Самые лучшие формх
лировки просты, лаконичны и достижимы. Вот некоторые примеры форм\
лировок миссий, которые можно применять в конкретной итерации.
• Найти как можно больше дефектов.
• Быстро определить существенные проблемы.
• Определить воспринимаемые риски для качества.
• Давать консультации по воспринимаемым рискам проекта.
• Давать консультации по воспринимаемому качеству.
• Подтвердить соответствие данному стандарту.
• Оценить соответствие продукта спецификации (требованиям, проектной модени
или притязаниям).
6. Целостный, рассматривающий явление полностью. - Примеч. науч. ред.
384
Глава 18
Тестовые циклы
Тестовый цикл - это период выполнения независимой тестовой задачи
включающей помимо всего прочего выполнение тестов и оценку их результатов.
В каждой итерации может быть несколько тестовых циклов. Большинство
шераций содержат как минимум один. Каждый тестовый цикл начинаемся
с оценки стабильности программного выпуска перед тем, как он будет передан
в । руппу тестирования для проведения более тщательных тестов.
RUP рекомендует, чтобы каждый выпуск рассматривался как потенциально
фебующий проведения тестового цикла, но прямой связи между выпуском и тес
юным циклом нет. Если бы каждый выпуск тестировался «на герметичноеть-
в целях проверки процесса его создания, то тестовый цикл мог бы оказаться
дольше создания выпуска. Как правило, в итерациях фазы Начало новых прост
iob выпуски не производятся, но в итерациях других фаз они есть. Хотя каждый
выпуск является потенциальным кандидатом на тестовый цикл, в силу разно
<юразных причин можно и не тестировать каждый выпуск. Иногда может бы и.
полезно распределить работу по тестированию одного выпуска по нескольким
।ссговым циклам.
Дисциплина Тестирование в RUP
Теперь мы обратимся к RUP и рассмотрим, как в нем описывается тестирова
иче. Описание главным образом заключено в дисциплину Тестирование (Testin'
Discipline). Мы рассмотрим различные задействованные роли (roles), создавав
мыс артефакты (artifacts), задачи (activities) и их рабочие процессы (workflows)
Роли, связанные с тестированием в RUP
В RUP представлено четыре роли, связанные с задачами тестирования.
• Менеджер тестов (Test Manager)
• Аналитик тестов (Test Analyst)
• I (роектировщик тестов (Test Designer)
• Тестировщик (Tester)
Руководство по RUP для тестировщика
385
Эти роли отражают естественное и полное разбиение навыков и областей
ответственности на группы. Вам, как тестировщику в небольшой организации,
могут поручить выполнение всех четырех ролей. В крупных организациях може1
иметь место специализация с назначением этих ролей разным людям.
Важно помнить, что данные роли RUP представляют соответствующую группу
обязанностей, определяемых задачами RUP, которые разделены в соответствии с на-
выками, необходимыми для их выполнения. Такое разделение позволяет иметь мно-
жество альтернатив распределения этих ролей среди членов команды. Эти роли
основаны на четырех фундаментальных наборах навыков: управление, анализ,
разработка и тестирование.
Главные артефакты тестирования
• Сводная оценка результатов тестирования (Test evaluation summary).
Поскольку целью тестирования является получение объективной оценки выну с
ка, наиболее важным артефактом, даже более важным, чем План тестирования,
будет Сводная оценка результатов тестирования. В идеале одна такая сводная
оценка создается для каждого тестового цикла или для каждого протестирован
ного выпуска, или хотя бы для каждой итерации. В этом артефакте представим
ется объективная оценка выпуска с точки зрения согласованной миссии. Приво-
дятся непрямые ссылки на дефекты и прочие аномалии (часто сохраняемые в ба-
зе данных запросов на изменения) и подчеркиваются наиболее важные из них.
Оцениваются результаты выполнения задач, связанных с устранением рисков,
которые направляют всю итерацию; представляется оценка самого тестирования
с точки зрения широты (часто называемой «охватом») в сравнении с планом,
а также оценка относительной эффективности тестирования. Таков ваш наибо-
лее важный артефакт для общения с остальной командой.
• План тестирования (Test Plan). В соответствии с двухуровневым Планом про-
екта и Планом итерации, описанным в главе 12, мы имеем Общий план тестиро-
вания (Master Test Plan), управляющий всем проектом, а также План тестирова-
ния (Test Plan), определяющий миссию и конкретные цели тестирования для ка-
ждой итерации. Общий план тестирования может быть связан с Планом обес-
печения качества (Quality Assurance Plan) (если таковой имеется), который
можно найти в Плане разработки программного обеспечения (Software Develop-
ment Plan). Схожим образом отдельные Планы тестирования для каждой итера-
ции связаны с Общим планом тестирования.
13-863
386 Глава hi
• Список идей тестов (Test idea list). Представляет собой неформальный спи
сок, создаваемый в ходе обдумывания различных ситуаций, которое можез и.,
казать необходимость создания тестов (и, опять же, не обязательно связанны-
с требованиями). Такой список часто создается путем совместного «мозговою
штурма» с другими членами команды, например разработчиками и аналитик.।
ми. Этот список впоследствии будет использоваться для задания направлении
тестирования после его сортировки по различным параметрам: затратам bjh
мени и усилий, важности для заказчика, вероятности обнаружения проблем
и т.п. В организации может вестись один или несколько каталогов абстрам
ных идей тестов, чтобы их можно было повторно использовать от итерации
к итерации и от проекта к проекту. В RUP содержится несколько примеров ьл
талогов идей тестов и руководств по их созданию и ведению.
• Комплект тестов (Test suite). Представляет собой группу взаимосвязанных пч
тов, которые, будучи выполненными вместе, дают оценку общей области пробт
мы. Комплект тестов - это реализация одной или более идей теста или пределен
та тестирования, и состоит он из тестовых сценариев и тестовых данных.
• Тестовые сценарии (Test scripts). Это процедурные аспекты тестирован h i
т.е. пошаговые инструкции по выполнению теста. Тестовые сценарии moi \ i
выполняться вручную или (в той или иной степени), автоматически. Тестоны,
сценарии и комплекты тестов - это те области, в которые все больше внедри
стся автоматизация, что дает тестировщикам возможность снова и снова ни
поднять множество тестов, управлять ими и автоматизировать создание бо н.
шей части сводок проведенных тестов.
• Прецеденты тестирования (Test cases). Связывают тестовую задачу с кч
тируемой программой, что дает возможность наблюдать прогресс. Каждый <н
вег на вопрос «что мы собираемся тестировать?» является мотивом теста ((<.- л
motivator), а каждый ответ на вопрос «как мы собираемся проводить тестеров.।
нис?» представляет собой прецедент тестирования. Прецеденты тестировании
более абстрактны, чем сценарии. Кроме того, в них определяются предусловии
условия выполнения и постусловия: они представляют собой высокруровневм.
спецификацию одного или более тестов. Чаще всего они создаются на основ,
тестовых мотивов, например требований, а в RUP многие из них создаются н.>
основе прецедентов использования (use cases)7. Прецеденты использовании
являются одним из главных, но не единственным источником для прецедетоп
тестирования, и могут дополняться другими идеями тестов. Для многих прось
/ См. Капег 2002 - Примеч. авт.
Руководство по RUP для тестировщика
387
тов существует очевидная опасное 1ь пог pai in ь на формализацию спецификаций
прецедентов тестирования слишком мною времени, которое можно было бы
иначе использовать на конкрепюе юстирование. Однако спецификации прсце
дснтов тестирования весьма полезны, и даже необходимы для некоторых типов
разработки, особенно для разработки систем, для которых безопасность или дос
тижение результата являются кри тическим фактором, а также для особо слож-
ных тестов и для тестов, в которых требуется тщательно учитывать использова-
ние многочисленных ресурсов (как людских, так и аппаратных), например при
тестировании производительности системы. Замел им, что не каждый тестовый
сценарий должен быть связан с прецедентом тестирования.
• Дефект (Defect). К сожалению (или к счастью, это зависит от вашей точки зре-
ния), тестирование выявляет дефекты. Дефект - это что-то вроде запроса на из-
менение, и он может вызвать внесение исправлений в последующем выпуске
или итерации. Дефекты являются полезным источником метрик, которые менед-
жер проекта может использовать не только для того, чтобы со временем по
лучить информацию об эволюции качества продукта, но также и о качестве
и эффективности самого процесса тестирования. Нужно, однако, быть осторож-
ным и не пугать дефект в приложении с дефектом в самом тесте.
• Модель рабочей нагрузки (Workload Model). Для обеспечения тестирования
производительности можно разработать модель рабочей нагрузки, харак-
теризующую типичные и исключительные нагрузочные условия, которые систе-
ма должна выдерживать.
В R.UP вы найдете и другие артефакты, относящиеся к тестированию. Специфика-
ция тестового интерфейса (test interface specification) содержит дополнительные тре-
бования, налагаемые на программный продукт, чтобы его можно было эффективно
тестировать. Это свойство часто называют тестируемостью (testability). Архитектура
автоматизации тестов (test automation architecture) описывает проектную модель тес-
тового инвентаря и различные тестовые инструменты и механизмы, которые приме-
няются для автоматизации тестирования разрабатываемого программного продукта.
Такая архитектура автоматизации тестов должна реализовывать различные архитек-
турные механизмы, например параллельность (одновременное автоматическое вы-
полнение двух и более тестов), распределенность (распределение автоматизирован-
ных тестов для выполнения на удаленных узлах), обслуживаемость (легкость под-
держки автоматизированных тестов на протяжении их развития) и т.п.
388
Глава П!
Задачи тестировщика
Теперь, когда мы знаем основные артефакты, связанные с тестированием, да-
вайте рассмотрим главные задачи, в которых создаются, изменяются и исполь
лютея эти артефакты. В RUP существует шесть главных групп задач по тес
шрованию (рис. 18.1) .
Определение миссии тестирования8.
11роверка подхода к тестированию.
11роверка стабильности выпуска («тест на герметичность»).
Тестирование и оценка.
Достижение приемлемого результата миссии.
Совершенствование средств и методов тестирования.
Эти задачи выполняются как минимум один раз за итерацию. Однако их ак
цен г в течение жизненного цикла будет изменяться.
• В фазе Начало выполнение этого процесса может быть очень поверхностным
Миссия для нового проекта, в котором не создано ни одного выпуска, можсч
состоять только в «разогреве», апробировании идей тестов, объединении ип
струментов и тестового инвентаря, и составлении совместно с другими разра
ботчиками требований, касающихся тестируемости. Кое-какое тестирование
можно провести, просто пройдясь по проектной модели.
• В фазе Проектирование акцент в основном, делается на тестировании архи
гскгуры и ключевых архитектурно значимых требований, многие из которых
являются нефункциональными (производительность, масштабируемость, ин-
юграция с другими продуктами), а также на проверке снятия основных архи
гекгурных рисков. Так же будет проверяться стратегия тестирования и тесто-
вая архитектура (имеющиеся инструменты для поддержки тестирования).
• В фазе Построение акцент тестовой миссии смещается к функциональному
тестированию, к проверке всей функциональности, описанной в прецедентах
использования. Это приводит к появлению осмысленной бета-версии. Про
должается нефункциональное тестирование, особенно, тестов производитель
пости, чтобы можно было отслеживать прогресс в настройке производитель-
ности или быстро определить, что развитие системы привело к потере произ
водительности.
в !ермины «миссия» тестирования и «миссия» оценки употребляются в RUP как синонимы. - Примеч. науч. ред.
Руководство по RUP для тестировщика
389
Определение
миссии тестирования
Проверка подхода
к тестированию
Проверка
стабильности выпуска
Другой метод
Тестирование
и оценка
Достижение приемлемого
результата миссии
Совершенствование средств
и методов тестирования
Другой тестовый цикл
Рис. 18.1. Общий рабочий процесс тестирования. Высокоуровневые тестовые задачи, приведенные
на данном рисунке, выполняются как минимум один раз в каждой итерации. Кроме того,
внутри итерации тестирование осуществляется итеративным методом (как показываю!
возвратные стрелки)
390
Глава 18
• В фазе Внедрение, на финишном рывке к релизу, акцент делается на общем
качестве и удобстве использования, а также на достижении ожидаемого уров-
ня качества, позволяющего выпустить продукт.
Иными словами, тестовая миссия полностью соответствует целям фазы, а не
предс тавляет собой, как в традиционных процессах, долгий период ленивого пла-
нирования и разработки тестов, за которым следует бурный и торопливый период
юг । прования.
1енерь мы рассмотрим эти задачи более подробно.
Определение миссии тестирования
Вам нужно верно определить акцент тестирования для предстоящей итерации
и согласовать с заинтересованными лицами те цели, которые будут направляю
процесс тестирования.
В каждой итерации эта деятельность концентрируется главным образом на:
• определении целей тестирования и создаваемых артефактов;
• определении правильной стратегии использования ресурсов;
• пирном определении области и границ тестирования;
• определении подхода, который будет использоваться, включая инструменты
автоматизации.
• определении способа отслеживания и оценки продвижения.
Мы уже видели, как миссия может изменяться на протяжении жизненною
никла.
Проверка подхода к тестированию
11ужно показать, что разнообразные методы тестирования и инструменты, описан-
ные в подходе к тестированию действительно, облегчат процесс тестирования.
11роиеряется это путем демонстрации того, что подход работает, дает точные резуль-
i.iin и соответствует имеющимся ресурсам. Цель задачи состоит в том, чтобы по-
палить представление об ограничениях каждого из инструментов и методов в контек-
( ie вашего конкретного проекга и либо найти соответствующее реализующее реше-
ние для каждого метода, либо подыскать альтернативный метод, который можно реа-
лизовать. Это позволяет уменьшить риск того, что слишком поздно обнаружится
неработоспособность подхода к тестированию.
I? каждой итерации эта деятельность концентрируется главным образом на:
Руководство по RUP для тестировщика
391
• проверке на ранней стадии проекта работоспособности подхода к тестирова-
нию и его способности давать полезные результаты;
• установке базовой инфраструктуры, обеспечивающей и поддерживающей
данный подход к тестированию;
• получении с команды разработчиков обязательства обеспечить и поддержи-
вать требуемую для реализации подхода тестируемость;
• определении области, границ, пределов и ограничений каждого средства и метода.
Проверка стабильности выпуска («тест на герметичность»)
Сначала нужно проверить, достаточно ли выпуск стабилен, чтобы можно бы-
ло начать его детальное тестирование и оценку. Такую работу еще называю!
«тест на герметичность»9, тест верификации выпуска, регрессионный тест вы-
пуска, санитарная проверка или прием к тестированию. Это помогает не тратить
напрасно ресурсы на ненужные и бесполезные усилия.
В каждом тестируемом выпуске такая деятельность позволяет:
• провести оценку стабильности и тестируемости выпуска: можно ли его ин-
сталлировать, загрузить и запустить;
• получить исходную информацию (или подтвердить ожидаемую)
о проведенной для данного выпуска работе: какие компоненты были успешно
интегрированы в выпуск;
• принять решение о возможности считать данный выпуск подходящим для
дальнейшего использования в тестировании (на основе миссии оценки) или
для тестирования в сравнении с предыдущим выпуском: не нужно проводить
тестовые циклы для каждого выпуска, нет смысла тратить время и силы на не-
удовлетворительный выпуск.
Тестирование и оценка
Это собственно процесс тестирования. Вы должны провести его с доста-
точной широтой и глубиной, и в соответствии с миссией оценки на данной
итерации, чтобы ваша оценка была обоснованной. Эта работа, как правило,
производится один раз за тестовый цикл, после приема выпуска к тестированию,
и сюда относится основная часть тактической работы по тестированию и оценке,
а именно: реализация, выполнение и оценка результатов конкретных тестон,
а также создание отчетов о замеченных инцидентах. Тестовые инструменты по-
могут выбрать подходящие тесты и выполнить их, если их можно выполнить ав-
томатически.
9. "smoke test" - метод проверки герметичности (трубопроводов) при помощи дыма. - Примеч. пер.
392
Глава 18
В каждом тестовом цикле эта деятельность концентрируется главным
образом на:
проведении текущей проверки и оценки тестируемых элементов (Target Test
Items);
• фиксировании информации, необходимой для диагностики и разрешения всех
выявленных проблем;
• достижении необходимой широты и глубины тестирования и оценки;
• установлении обратной связи с областями наиболее вероятного риска для
качества.
Достижение приемлемого результата миссии
В то же время вы должны получить полезные для заинтересованных сторон
результаты проверки. Полезность результатов оценивается относительно миссии.
В большинстве случаев это означает, что вы должны помочь команде проекта
юстичь целей Плана итерации, которые применимы к данному тестовому циклу.
В каждом тестовом цикле эта деятельность концентрируется главным образом на:
• активной расстановке приоритетов в минимальном наборе необходимых для
достижения целей миссии оценки;
• помощи в разрешении важных проблем, негативно влияющих на выполнение
миссии оценки;
• помощи в достижении необходимого качества продукта;
• выявлении отступлений от качества, сделанными между тестовыми циклами;
• пересмотре по мере необходимости миссии оценки с учетом полученных дан-
ных, чтобы обеспечивать полезной информацией команду проекта.
Совершенствование средств и методов тестирования
Как и при любом хорошем процессе, в конце каждого тестового цикла, или по
меньшей мере в конце каждой итерации нужно завершить цикл, обеспечить ин-
формацией обратной связи сам процесс и воспользоваться преимуществами
итеративной природы жизненного цикла для поддержки и совершенствования
средств и методов тестирования. Это особенно важно, если существует на-
мерение повторно использовать средства и методы, разработанные в текущем
।остовом цикле, в последующих циклах и даже в другом проекте.
Руководство по RUP для тестировщика
393
В каждом тестовом цикле эта дея1елыюс1ь концентрируется главным образом и;г
• добавлении небольшого числа дополни тельных тестов, которые будут исполь
зоваться для проверки стабильноети последующих выпусков;
• сборке тестовых сценариев в подходящие дополнительные комплекты тестов;
• удалении средств и методов тестирования, которые более не могут выполнять
полезной работы или становятся неэкономичными в поддержании;
• поддержании конфигураций среды тестирования (Test Environment Configura
tions) и наборов Тестовых данных;
• изучении возможностей для повторного использования и улучшения произво
дительности;
• проведении общего обслуживания и повышении удобства обслуживания
средств автоматизации тестирования;
• документировании полученного в тестовом цикле опыта, как положительною,
так и отрицательного. Это необходимо делать как минимум, один раз в конце
итерации.
Прочие задачи, связанные с тестированием
Старайтесь не ограничивать изучение RUP одной дисциплиной. Тестировщи-
ки и инженеры по качеству, скорее всего, будут привлекаться ко многим другим
задачам RUP. Например к:
• составлению Плана обеспечения качества (Quality Assurance Plan), который
является частью Плана разработки программного обеспечения (Software De
velopment Plan);
• участию в рецензировании требований и проектной модели, которые служат не
точниками идей тестов;
• участию в работе группы контроля за изменениями (Change Control Board)
в целях проведения обзора дефектов и решения их дальнейшей судьбы.
Заключение
В RUP тестирование постоянно снабжает руководство и коман.п
разработчиков объективной оценкой качества продукта. Это не расстановка i а
лочек напротив требований за один «навал» в конце жизненного цикла проема
(даже если это и имеет место).
394
Глава 18
( Ькидаемый уровень качества и требования меняются на протяжении жизнен-
но! о цикла, и тестирование должно меняться вместе с ними. Тестирование можно
।ычипагь на ранних этапах проекта, поскольку при итеративной разработке код,
мпорый можно тестировать, создается рано и это может способствовать установ-
н ппю очень полезной обратной связи как для продукта, так и для процесса,
и поэтому они могут правильно развиваться. Эта обратная связь обычно упуска-
йся из вида в традиционных подходах.
Роль тестировщика и инженера по качеству в RUP состоит главным образом
не в поиске дефектов, а в обеспечении разработчиков и руководства объективной
информацией о качестве продукта. Тестирование - это не самодостаточный, ot-
ic явный рабочий процесс, выполняемый параллельно или после разработки
npoi раммного обеспечения, а процесс, полностью интегрированный в итератив-
ni.ni цикл RUP. Пользуясь преимуществами итеративного подхода, тестирование
i ыиовится почти непрерывным процессом, который постоянно связан цепью
порапюй связи с требованиями, проектной моделью и руководством проекта.
11о пому эта задача основана на сотрудничестве, а не на соперничестве, и не сво-
и11ся к простановке штампа «принято». Ее также можно более эффективно авто-
м,и тировать с помощью инструментов. Тестирование в RUP использует прак-
। ччсское и гибкое понятие «достаточно хорошее качество», которое принимает
iu> внимание равновесие между стоимостью тестирования и желаемым уровнем
качества, в зависимости от контекста.
Ресурсы для тестировщиков
Дополнительная литература
Janies Bach. “Good Enough Quality: Beyond the Buzzword,” in IEEE Computer,
<() (X), August 1997, 96-98.
Boris Beizer. Black Box Testing. New York: John Wiley & Sons, Inc., 1995.
Rex Black. Managing the Testing Process. Redmond, WA: Microsoft Press, 1999.
Jim 1 leumann. “Generating Test Cases from Use Cases,” in The Rational Edge, June
'001. http://www.therationaledge.com/content/jun_01/m_cases_jh.html.
('em Kaner, James Bach, and Bret Pettichord. Lessons Learned in Software Testing.
New York: John Wiley & Sons, Inc., 2002.
( 'em Kaner, Jack Falk, and Hung Qnoc Nguyen. Testing Computer Software, Sec-
mid Edition. New York: John Wiley & Sons, Inc., 1999.
Руководство по RUP для тестировщика
395
Brian Marick. “Faults of Omission,” in Software resting and Quality Engineering
Magazine, January 2000.
Glenford J. Myers. The Art of Software Testing. New York: John Wiley & Sons, 1979.
Robert Pirsig, Zen and the Art of Motorcycle Maintenance. New York: Bantam
Books, 1977.
Connie U. Smith and Lloyd Williams. Performance Solutions: A Practical Guide to
Creating Responsive, Scalable Software. Boston: Addison-Wesley, 2002.
Учебные курсы
Следующие учебные курсы были разработаны в целях поддержки пользовате-
лей RUP и поставляются компанией IBM Software и ее партнерами (более
подробная информация приводится па www.rational.com):
• Principles of Software Testing for Testers (два дня).
• Essentials of Functional Testing (два дня).
• Essentials of XDE Jester, Java, and Web Edition: The Basics of Performance J est-
ing (четыре часа).
А Я
О. S?
Глоссарий
В данном глоссарии даются определения только тех терминов, которые являются спе-
цифичными для RUP или имеют в RUP несколько иное значение. Термины, выделенные
рейвом, определены в другом месте глоссария.
Задача1 (Activity). Единица работы в RUP, которая может быть предложена роли для
1ч.1нолнения. Задача может быть разложена на шаги. Результатом задачи обычно является
i о панне или изменение артефакта.
Актор2 (Actor). Кто-то или что-то вне системы (или бизнеса), взаимодействующее
< сие।смой (или бизнесом).
Артефакт (Artifact). Объем информации, созданный, измененный или использован-
ный процессом, определяющий область ответственности и подлежащий контролю
версии. Артефакт может представлять собой модель, элемент модели или документ.
1>:иа (Base). См. RUP-база.
Казне, базовая линия3 (Baseline). Отрецензированная и одобренная версия набора
ipiсфактов, составляющая согласованную основу развития и разработки, которая можем
in.hi. изменена только путем формальной процедуры, в частности с помощью управ
в-нческой процедуры изменения и конфигурирования.
Выпуск (билд, сборка) (Build). Функционирующая версия системы или части систе-
мы. демонстрирующая набор возможностей, которые должны присутствовать в конечном
продукте.
Builder. См. RUP Builder.
Компонент (Component). Нетривиальная, практически независимая и заменяемая
м.к и. системы, выполняющая конкретную функцию в контексте точно определенной
.|р\|нектуры. Компонент соответствует и обеспечивает физическую реализацию набора
ин u-рфейсов. (см. также Компонент процесса).
11остроение (Construction). Третья фаза цикла разработки в RUP, на которой главным
пора юм и разрабатывается программное обеспечение4.
I В литературе по RUP встречаются и другие переводы, но термин «задача» используется в ГОСТ Р ИСО МЭК
I;ТО/ и в других стандартах. - Примеч. науч. ред.
.' В литературе по RUP встречаются также переводы: исполнитель, эктор, актант и другие. - Примеч. науч, ред
.1 1ермин «базовая линия» используется в ГОСТ Р ИСО МЭК 12207. -Примеч. науч. ред.
Глоссарий
397
Цикл (Cycle). Полное прохождение всех че i i.ipex фаз RUP (Начало, Проектирование.
Построение и Внедрение), приводящее к выпуску продукта по внешний мир.
Развертывание (Deployment). В RUP - дисциплина, цель которой - обеспечение ус-
пешности передачи разработанной системы пользователям.
Прецедент (вариант) разработки (Development Case). Конкретный процесс, исполь-
зуемый в работе организации. Прецедент разрабатывается как конфигурация или на-
стройка продукта RUP и адаптируется под требования конкретного проекта.
Дисциплина (Discipline). Логическая группа из ролей, задач, артефактов и других
средств управления процессом в описании процесса.
Проектирование (Elaboration). Вторая фаза цикла разработки RUP, на которой пол-
ностью определяются концепция продукта, требования к нему и его архитектура4 5.
Расширенная помощь (Extended Help). Свойство RUP, позволяющее связанным
с ним средствам разработки создавать для RUP контекст, что приводит к тому, что RUP
отображает соответствующие темы на основе данного контекста.
Начало6 (Inception). Первая фаза в цикле разработки RUP. на которой определяются
границы проекта и его мотивировка.
Итерация (Iteration) Четкая последовательность задач с планом и критерием оценки,
приводящая к выпуску релиза (внутреннего или внешнего).
Веха (Milestone). Момент времени, в который итерация, или стадия, формально за-
вершается. Соответствует выпуску версии.
Modeler.CM. RUP Modeler
MyRUP. RUP-браузер, позволяющий просматривать процесс, производить поиск, ис-
пользовать указатель, осуществлять графическую навигацию и создавать собственные
представления процесса для своей Конфигурации процесса RUP.
Organizer. См RUP Organizer.
Фаза (Phase). Время между двумя вехами проекта, в ходе которого преследуется
строго определенный набор целей, создаются артефакты и принимаются решения о том.
переходить или не переходить к следующей фазе проекта.
Плагин (Plug-in). В RUP Плагин - это развертываемый модуль для одного или не-
скольких Компонентов процесса, который можно легко «спустить» в RUP-базу и таким
образом расширить ее. Плагин RUP можно скомпилировать в физический файл, что по-
зволит перемещать его и добавлять в RUP-библиотеку с совместимой RUP-базой.
4. Примерно соответствует стадии Рабочая документация ГОСТ 34.601-90. -Примеч. науч. ред..
5. Примерно соответствует стадиям Эскизный проект и Технический проект ГОСТ 34.601 -90. -Примеч. науч. ред.
6. Иногда первую стадию называют также Анализ и планирование требований. Примерно соответствует стадиям
Формирование требований, Разработка концепции ПС, Техническое задание ГОСТ 34.601 -90. - Примеч. науч, ред
398
Глосс. И I
Компонент процесса (Process component). С квази-независимая «порция данны
irui модуль информации о процессе, которому можно присвоить имя, разместить в н.п
ie, сменить или объединить с другими компонентами процесса.
Конфигурация процесса (Process Configuration). Конфигурация процесса RUP и.
набор Компонентов процесса, которые можно просматривать и которые составляю! пр >
iii.iii процесс (полный с точки зрения конкретного использования). Это web-сайт, распо 11
1.ПОЩПЙСЯ на машине пользователя или на сервере. Конфигурации процесса компн
inp\юзся при помощи RUP Buider.
Представление процесса (Process View). Свойство браузера MyRUP, позволяют'
нас, роить на то, какие части Конфигурации процесса RUP, а также какие внешние сач и
вы бы хотели видеть в браузере. Представления процесса могут быть основаны на рн ш
(например, аналитик, разработчик, тестировщик) или же персонифицированы для н\ а
koi । крстного п ользователя.
Прототип (Prototype). Релиз, который необязательно является объектом управлснн
изменениями и версионного контроля. Прототип может быть отброшен или можсз р.>
ншься. пока не станет частью системы.
Rational Process Workbench (RPW). Набор средств для авторской разработки прош >
t а Представляет собой комбинацию инструментов, процессов и прочего, что дает шы..
пиру-технологу возможность разрабатывать Плагины RUP. В RPW входят RUP Models
KI IP Organizer, RUP Library и руководство по созданию собственных процессов.
Релиз (Release). Часть конечного продукта, являющаяся объектом оценки в момеш ьт»
Релиз - это стабильная, исполняемая версия продукта со всеми артефактами, необхош
мымн для ее использования, такими как выходные замечания или инструкции по инет ап н
iiiiii. Релизы могут быть внешними и внутренними. Внутренний релиз используется толы ..
организацией-разработчиком как часть вехи или для демонстрации пользователям или ..i
к.нчнкам. Внешний релиз (отправляемый) отправляется конечным пользователям.
Puck (Risk). Имеющийся или возможный в будущем фактор, который со значпго и.
ной вероятностью может повлиять на успешность достижения основных вех.
Роль (Role). Определяет поведение и ответственность индивидуума или ряда индивн
дуумов, работающих совместно, в команде.
RPW. См. Rational Process Workbench.
RUP-база (RUP Base). Набор Компонентов процесса, который расширяется с помоип н
И теинов для генерирования Конфигураций процесса. Располагается в RUP-библиотеке.
RUP Builder. Инструмент RUP, используемый для создания Конфигураций прощу...
ns RUP-базы и любого количества Плагинов.
RUP Exchange. Место в сети Rational Developer Network, где Плагины и прочие опт
сящиеся к процессам материалы доступны для сообщества пользователей.
Глоссарий
399
RUP-библиотека (RUP Library). Набор Компонентов процесса, из которых можш
с помощью RUP Builder скомпилировать набор Конфигураций процесса. В RUP-библио
теку можно добавлять новые компоненты средствами Плагинов.
RUP Modeler. Компонент среды Rational Process Workbench. Позволяет инженеру- i е.\
нологу визуально моделировать элементы процесса, такие как задачи, артефакты, роли,
дисциплины, мастера инструментов и их взаимоотношения. Собирает их в Компоненты
процесса и компилирует в Плагины RUP. RUP Modeler является расширением Rationa
XDE и работает совместно с RUP Organizer.
RUP Organizer. Компонент среды Rational Process Workbench. Позволяет связывап
содержимое файлов с элементами процесса, такими как задачи, артефакты, роли, дисцн
тины и мастера инструментов, и компилировать эти Компоненты процесса для созда-
ния Плагинов на основе новых или модифицированных файлов. Файлы могут представ
лять собой примеры, руководства или повторно используемые вещи. RUP Organizer также
позволяет вносить изменения в Расширенную помощь (Extended Help).
Сценарий (Scenario). Описанный экземпляр прецедента использования или часп
прецедента использования.
Шаг (Step). Часть задачи. Необязательно все Шаги выполняются при каждом выпол-
нении задачи.
Мастер инструмента (Tool Mentor). Описание, дающее практическое руководстве
к тому, как осуществлять конкретные задачи процесса или шаги с помощью конкретной
программного инструмента.
Внедрение7 (Transition). Четвертая и последняя фаза цикла разработки RUP, приводя
щая к выпуску релиза продукта.
Прецедент (вариант) использования (Use case). Последовательность действий, выпол
няемых системой и приводящих к видимому ценному результату для конкретного актора
Класс use-case содержит в себе все главные, дополнительные и исключительные последона
дельности событий8, связанные с получением «видимого полезного результата».
Концепция (Vision). Представление пользователя или заказчика о продукте, которьп
должен быть разработан, суммарно определяемое на уровне ключевых потребностей за
интересованных лиц и главных свойств системы.
Рабочий процесс (Workflow). - Последовательность действий, осуществляемы'
в бизнесе, которая приводит к получению видимого полезного результата для конкре| но
го актора бизнеса. В процессе разработки программного обеспечения рабочий пропей
можно выразить в форме последовательности задач.
7. Примерно соответствует стадии Ввод в действие ГОСТ 34.601 -90. - Примеч. науч. ред.
8. То есть прецедент содержит все возможные сценарии его выполнения. - Примеч. науч. ред.
Литература
I'he Rational Edge can be found at http://www.therationaledge.com.
Albrecht 1979 Allan J. Albrecht. “Measuring Applications Development Productivity,” in
Proceedings of IBM Applications Development Joint SHARE/GUIDE Symposium, Monterc\
< A: 1979, 83- 92.
Ambler 1998 Scott Ambler. Process Patterns: Building Large-Scale Systems Using Objeu
technology. New York: SIGS Books/Cambridge University Press, 1998.
Ambler 1999 Scott Ambler. More Process Patterns: Delivering Large-Scale Systems Usi>y
i >bject Technology. New York: SIGS Books/Cambridge University Press, 1999.
Ambler 2000 Scott Ambler and Larry Constantine. The Unified Process Construction Phase
I awrence, KS: CMP Books, 2000, 163-170.
Bach 1997 James Bach. “Good Enough Quality: Beyond the Buzzword,” in IEEE Computer,
'0 (8), August 1997, 96-98.
Bach 2001 James Bach. “What Is Exploratory Testing? (And How It Differs from Scripted
1 esting),” in Software Testing and Quality Engineering Magazine, January 29, 2001.
Bass 1998 Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice
Reading, MA: Addison-Wesley, 1998.
Beck 1998 Kent Beck. CRC: The Essence of Objects. Upper Saddle River, NJ: Prentice-Hall
1998.
Beck 2000 Kent Beck. Extreme Programming Explained: Embrace Change. Boston: Addi
son-Wesley, 2000.
Beck 2001 Kent Beck and Martin Fowler. Planning Extreme Programming. Boston: Addison
Wesley, 2001.
Beizer 1995 Boris Beizer. Black Box Testing. New York: John Wiley & Sons, Inc., 1995.
Binder 2000 Robert V. Binder. Testing Object-Oriented Systems: Models, Patterns, and
Pools. Boston: Addison-Wesley, 2000.
Bittner 2003 Kurt Bittner and lan Spence. Use Case Modeling. Boston: Addison-Wesley,
.’003.
Black 1999 Rex Black. Managing the Testing Process. Redmond, WA: Microsoft Press, 1999.
Bochin 1981 Barry W. Boehm. Software Engineering Economics. Upper Saddle River, NJ
Prentice-Hall, 1981.
Литература
40
Boehm 1986 Barry W. Boehm. “A Spiral Model of Software Development and Enhance
ment,” in ACM SIGSOFTSoftware Engineering Notes, 11, August 1986, 22-42.
Boehm 1991 Barry W. Boehm. “Software Risk Management: Principles and Practices,” i
IEEE Software, 8 (1), January 1991, 32-41.
Boehm 1996 Barry W. Boehm. “Anchoring the Software Process,” in IEEE Software, 13 (4
July 1996, 73-82.
Boehm 2001 Barry W. Boehm, et al. Software Cost Estimation with COCOMO II. Upper Sad
die River, NJ: Prentice-Hall, 2001.
Boehm 2002 Barry W. Boehm, “Get Ready for Agile Methods, with Care,” in IEEE Comput
er, 35 (1), January 2002, 64-69.
Booch 1994 Grady Booch. Object-Oriented Analysis and Design with Applications, Secant
Edition. Menlo Park, CA: Addison-Wesley, 1994.
Booch 1996 Grady Booch. Object Solutions: Managing the Object-Oriented Project. Menk
Park, CA: Addison-Wesley, 1996.
Booch 1999 Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Lan-
guage User Guide. Reading, MA: Addison-Wesley, 1999.
Booch 2001 Grady Booch. “The Illusion of Simplicity,” in Software Development Magazine.
February 2001,57-59.
Bosch 2000 Jan Bosch. Design and Use of Software Architecture: Adopting and Evolving a
Product-Line Approach. Boston: Addison-Wesley, 2000.
Brooks 1995 Frederick P. Brooks, Jr. The Mythical Man-Month (Anniversary Edition). Read-
ing, MA: Addison-Wesley, 1995.
Buschmann 1996 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and
Michael StaL Pattern-Oriented Software Architecture: A System of Patterns. New York: John
Wiley & Sons, Inc., 1996.
Cantor 2002 Murray Cantor. Software Leadership: A Guide to Successful Software Develop-
ment. Boston: Addison-Wesley, 2002.
Charette 1989 Robert Charette. Software Engineering Risk Analysis and Management. New
York: McGraw-Hill, 1989.
Clements 2002a Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed
Little, Robert Nord, and Judith Stafford. Documenting Software Architectures: Views and Be-
yond. Boston: Addison-Wesley, 2002.
Clements 2002b Paul Clements, Rick Kazman, and Mark Klein. Evaluating Software Archi-
tecture. Boston: Addison-Wesley, 2002.
Clements 2002c Paul Clements and Linda Northrop. Software Product Lines: Practice and
Patterns. Boston: Addison-Wesley, 2002.
Cockburn 2001 Alistair Cockburn. Writing Effective Use Cases. Boston: Addison-Wesley.
2001.
14-863
402
Литература
< ockburn 2002 Alistair Cockburn. Agile Software Development. Boston: Addison-Wesley,
'tio
< onallcn 2000 Jim Conallen. Building Web Applications with UML. Boston: Addison-Wes-
l.-\, 2000.
< onstantine 1999 Larry Constantine and Lucy Lockwood. Software for Use. Reading, MA:
\ Oil ison-Wesley, 1999.
< ooper 1999 Alan Cooper. The Inmates Are Running the Asylum. Indianapolis, IN: Sams,
IhTiiiame 1999 Jean-Claude Derniame, Badara Ali Kaba, and David Graham Wastell. Soft-
ir.ii i- Process: Principles, Methodology’, and Technology. LNCS #1500. Berlin, Germany:
Spiinger-Verlag, 1999.
Itikcl 2001 David M. Dikel, David Kane, and James R. Wilson. Software Architecture: Orga-
m aiional Principles and Patterns. Upper Saddle River, NJ: Prentice-Hall, 2001.
I i les 2003 Peter Eeles, Kelli Houston, and Wojtek Kozaczynski. Building J2EE Applications
и-//// the Rational Unified Process. Boston: Addison-Wesley, 2003.
I i iksson 2000 Hans-Erik Eriksson and Magnus Penkcr. Business Modeling with UML: Busi-
ness Patterns at Work. New York: John Wiley & Sons, Inc., 2000.
I owler 1997 Martin Fowler and Kendall Scott. UML Distilled: A Brief Guide to Applying the
Mandat'd Object Modeling Language. Reading, MA: Addison-Wesley, 1997.
I-owler 1999 Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. Re-
lactoring: Improving the Design of Existing Code. Reading, MA: Addison-Wesley, 1999.
I reed in an 1990 Daniel P. Freedman and Gerald M. Weinberg. Handbook of Walkthroughs,
Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products, Third Edi-
imii. New York: Dorset House, 1990.
..... 1995 Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Pat-
irnns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.
< .ill» 1988 Tom Gilb. Principles of Software Engineering Management. Reading, MA: Addi-
son-Wesley, 1988.
Graham 1997 lan Graham, Brian Henderson-Sellers, and Houman Younessi. The Open Pro-
, css Specification. Reading, MA: Addison-Wesley, 1997.
Ileinnann 2001 Jim Heumann. “Generating Test Cases from Use Cases,” in The Rational
I dye, June 2001.
Highsmith 2000 James A. Highsmith. Adaptive Software Development: A Collaborative Ap-
proach to Managing Complex Systems. New York: Dorset House, 2000.
Ilolineister 2000 Christine Hofineister, Robert Nord, and Dilip Soni. Applied Software Ar-
• hitccture. Boston: Addison-Wesley, 2000.
1 1 nmphrey 1989 Watts Humphrey. Managing the Software Process. Reading, MA: Addison-
Wesley, 1989.
Литература
403
Humphrey 1995 Watts Humphrey. A Discipline for Software Engineering. Reading, MA
Addison-Wesley, 1995.
Humphrey 1997 Watts Humphrey. Introduction to the Personal Software Process. Reading
MA: Addison-Wesley, 1997.
IEEE 1991 IEEE Standard 829-1991. “Standard for Software Test Documentation.” New
York: IEEE, 1991.
IEEE 1998a IEEE Standard 1490-1998. “Adoption of the PMI Guide to PMBOK.” New
York: IEEE, 1998.
IEEE 1998b IEEE Standard 1058-1998. “Standard for Software Project Management Plans ”
New York: IEEE, 1998.
IEEE 2000 IEEE Standard 1471-2000. “Recommended Practice for Architectural Description
of Software-Intensive Systems.” Los Alamitos, CA: IEEE Computer Society, 2000.
ISO/IEC 1995 ISO/IEC 10746:1995. Reference Model of Open Distributed Processing (RM
ODP) (ITU Rec. X901). Geneva, Switzerland: ISO, 1995.
ISO/IEC 1998 ISO/IEC 15504:1998. Information Technologies—Software Process Assess
ment. Geneva, Switzerland: ISO, 1998.
Jacobson 1992 Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar L(vergaaid
Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, MA: Addison
Wesley, 1992.
Jacobson 1994 Ivar Jacobson, Maria Ericsson, and Agneta Jacobson. The Object Advantage
Business Process Reengineering with Object Technology. Reading, MA: Addison-Wesley. 1994.
Jacobson 1997 Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse: Architec-
ture, Process and Organization for Business Success. Reading, MA: Addison-Wesley, 1997.
Jacobson 1999 Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software
Development Process. Reading, MA: Addison-Wesley, 1999.
Jeffries 2001 Ron Jeffries, Ann Anderson, and Chet Hendrickson. Extreme Programming In
stalled. Boston, MA: Addison-Wesley, 2001.
Kaner 1999 Cent Kaner, Jack Falk, and Hung Quoc Nguyen. Testing Computer Software. Sec
ond Edition. New York: John Wiley & Sons, Inc., 1999.
Kaner 2002 Cent Kaner, James Bach, and Bret Pettichord. Lessons Learned in Software Test
ing. New York: John Wiley & Sons, Inc., 2002.
Kroll 2001 Per Kroll. “The RUP: An Industry-Wide Platform for Best Practices,” in The R.i
tional Edge, December 2001.
Kruchten 1995 Philippe Kruchten. “The 4+1 View Model of Architecture,” in IEEE Soft
ware, 6(12), 1995,45-50.
Kruchten 1996 Philippe Kruchten. “A Rational Development Process,” in CrossTalk, 9 (7)
July 1996, 11-16.
14*
404
Литература
Kruchten 1999 Philippe Kruchten. “The Software Architect, and the Software Architecture
I earn,” in Software Architecture, P. Donohue (ed.). Boston: Kluwer Academic Publishers, 1999,
M.5 583.
Kruchten 2000a Philippe Kruchten. The Rational Unified Process: An Introduction, Second
Edition. Boston: Addison-Wesley, 2000.
Kruchten 2000b Philippe Kruchten. “From Waterfall to Iterative Development: A Tough
transition for Project Managers,” in The Rational Edge, December 2000.
Kruchten 2001a Philippe Kruchten. “What Is the Rational Unified Process?” in The Rational
Edge, January 2001.
Kruchten 2001b Philippe Kruchten. “The Tao of the Software Architect,” in The Rational
Edge, March 2001.
Kruchten 2001c Philippe Kruchten. “Common Misconceptions About Software Architec
lure,” in The Rational Edge, April 2001.
Kruchten 2002 Philippe Kruchten. “A Software Development Process for a Team of One,” in
///<’ Rational Edge, February 2002.
1 effingwell 2000 Dean Leffingwell and Don Widrig. Managing Software Requirements: .1
I hi fied Approach. Boston: Addison-Wesley, 2000.
Marick 2000 Brian Marick. “Faults of Omission,” in Software Testing and Quality Engineer-
ing Magazine, January 2000.
Martin 2001 Robert C. Martin and Robert S. Koss. An Extreme Programming Episode. Ver-
non Hills, IL: Object Mentor, 2001.
McCarthy 1995 Jim McCarthy. Dynamics of Software Development. Redmond, WA: Mi-
crosoft Press, 1995.
McConnell 1993 Steve McConnell. Code Complete: A Practical Handbook of Software Con-
struction. Redmond, WA: Microsoft Press, 1993.
McConnell 1997 Steve McConnell. Software Project Survival Guide. Redmond, WA: Mi-
i losoft Press, 1997.
McCormack 2001 Alan McCormack. “Product-Development Practices That Work: How Inter-
nci Companies Build Software,” in MIT Sloan Management Review, 42 (2), Winter 2001, 75-84.
Myers 1979 Glenford J. Myers. The Art of Software Testing. New York: John Wiley & Sons,
Inc., 1979.
Newkirk 2001 James Newkirk and Robert Martin. Extreme Programming in Practice. Bos-
ton: Addison-Wesley, 2001.
O’Connell 1994 Fergus O’Connell. How to Run Successful Projects. Upper Saddle River,
NJ: Prentice-Hall, 1994.
OMG 2001 Object Management Group. Software Process Engineering Metamodei (SPEM).
()MG, doc ad/01-03-08, April 2, 2001. http://cgi.omg.org/cgi-bin/doc7ad/01-03-08.
Osterweil 1987 Leon J. Osterweil. “Software Processes Are Software Too,” in Proceedings
4th ICSE, 1987, 2-13.
Литература
405
Pirsig 1977 Robert Pirsig. Zen and the Art of Motorcycle Maintenance. New York: Bantan
Books, 1977.
PMI 2000 Project Management Institute. Guide to the Project Management Body of Know!
edge (PMBOK Guide). W. Duncan (editor). Newton Square, PA: PMI, 2000.
Pressman 2001 Roger S. Pressman. Software Engineering: A Practitioner’s Approach, Fiji)
Edition. Boston: McGraw-Hill Higher Education, 2001.
Probasco 2000 Leslee Probasco. “Ten Essentials of RUP,” in The Rational Edge, Decembei
2000.
Quatrani 1998 Terry Quatrani. Visual Modeling with Rational Rose and UML. Reading, MA
Addison-Wesley, 1998.
Rechtin 1997 Eberhardt Rechtin and Mark Maier. The Art of Systems Architecting. Boca Ra-
ton, FL: CRC Books, 1997.
Robillard 2003 Pierre Robillard and Philippe Kruchten. Software Engineering Process wit),
the UPEDU. Boston: Ad di son-Wes ley, 2003.
Royce 1998 Walker Royce. Software Project Management: A Unified Framework. Reading
MA: Addison-Wesley, 1998.
Royce 2002 Walker Royce. “CMM vs. CMMI: From Conventional to Modern Software De-
velopment,” in The Rational Edge, February 2002.
Rumbaugh 1991 James Rumbaugh, Michael Blaha, William Lorensen, Frederick Eddy, and
William Premerlani. Object-Oriented Modeling and Design. Upper Saddle River, NJ: Prentice-
Hall, 1991.
Rumbaugh 1998 James Rumbaugh, Ivar Jacobson, and Grady Booch. UML Reference Manu-
al. Reading, MA: Addison-Wesley, 1998.
Schwaber 2002 Ken Schwaber and Mike Beedle. Agile Software Development with SCRUM
Upper Saddle River, NJ: Prentice-Hall, 2002.
Selic 1994 Bran Selic, Garth Gullekson, and Paul Ward. Real-Time Object-Oriented Model-
ing, New York: John Wiley & Sons, Inc., 1994.
Shaw 1996 Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerg
ing Discipline. Upper Saddle River, NJ: Prentice-Hall, 1996.
Smith 2002 Connie U. Smith and Lloyd Williams. Performance Solutions: A Practical Guide
to Creating Responsive, Scalable Software. Boston: Addison-Wesley, 2002.
Stapleton 1998 Jennifer Stapleton. DSDM, Dynamic Systems Development Method: The
Method in Practice. Reading, MA: Addison-Wesley, 1998.
Thai 2001 Thuan Thai and Hoang Q. Lam. .NET Framework Essentials. Sebastopol, CA
O’Reilly, 2001.
Thayer 1997 Richard H. Thayer (ed.). Software Engineering Project Management, Second
Edition. Los Alamitos, CA: IEEE Computer Society Press, 1997.
Wiegers 2000 Karl Wiegers. “Stop Promising Miracles,” in Software Development, February
2000.
406
Литература
Williams 2000 Laurie Williams, Robert R, Kessler, Ward Cunningham, and Ron Jeffries.
'Strengthening the Case for Pair Programming,” in IEEE Software, 17 (4), 2000, 19-25.
Witt 1994 Bernard I. Witt, F. Terry Baker, and Everett W. Merritt. Software Architecture and
Design: Principles, Models, and Methods. New York: Van Nostrand Reinhold, 1994.
Yourdon 1997 Edward Yourdon. Death March: Managing "Mission Impossible" Projects.
I Ipper Saddle River, NJ: Prentice-Hall, 1997.
Предметный
указатель
А
Adoption оГthe PMI Guide to РМВОК,
стандарт 294
В
Bach, James (Бэч, Джеймс), 375
Beck, Kent (Бек, Кент), 354,368, 371
Boehm, Barry, (Боэм, Барри) 90, 260,338
Booch, Grady, (Буч, Грейди), 277,
296,342,371, xxxv
Brooks, Frederick (Брукс, Фредерик), 330
Builder. См. RUP Builder
С
Capability Maturity Model (SEI CMM)
(Модель зрелости процесса разработки),
84-86
CCBs (Change Control Boards), Группа
контроля за изменениями
и роль тестировщика, 393
помощь менеджеру проекта, 293
управление стоимостью, 66
ССМ (Configuration and Change
Management) (Управление
конфигурациями и изменениями)
и высокая формализованное! ь, 91
инкрементное внедрение RUP, 267
управление стоимостью, 66
Change Control Boards (Группа контроля
за изменениями). См. CCBs (Change
ControlBoards)
СММ (Capability Maturity Model) (Модель
зрелости процесса разработки), 84-86
CMMI, 85-86
CMP (Core Message Platform)
(Базовое описание), 196
CMS (Configuration Management Sy stein
(Система управления
конфигурациями)
использование в бета тестировании) , и
Внедрение, 190-191
общий обзор, 171-172
рабочие пространства, 305
Core Message Platform (CMP)
(Базовое описание), 196
COTS (Commercial Off-tlie-Shelf)
Готовые коммерческие компоненты. ?81
Crystal, 80-81
Cunningham, Ward (Капнипхэм, Уорт). 351
D
DBA (Database Administrator),
Администратор баз данных, 347
Dikel, David, Дикел Дэвид, 336-338
DOD, Department of Defense
(Министерство обороны), 87
DOD-STD, 86-87
G
GEQ (Good Enough Quality), Дос>а ><>чн<>
хорошее качество, концепция
и количественная оценка. 377-378
п соответствие стандартам, 378-379
и стоимость, 377
общий обзор, 375
представления о. 375-376
Gilb, Tom, (Глиб, Том), 58, 302
I
IBM, 147
IDEs (Integrated Development
Environments), Интегрированные
среды разработки, 284
ISO/IEC 15504,86
408
предметный указатель
j
.12 ЕЕ, платформа, 72, 92
Jacobson, Ivar, (Якобсон, Ивор), 326,345
L
I ifecycle Architecture (LCA) Milestone,
(Архитектуры жизненного цикла, веха), 41
I ifecycle Objective (LOC) Milestone, (Целей
Жизненного Цикла, веха) 41
м
Microsoft.NET, 59, 72
MIL-STD, 86-87
Modeler. Си. RUP Modeler
MyRUP
общий обзор, 52-53
определение, 397
Представления процесса в, 204-205
N
NE T, платформа, 59, 72
О
Organizer. Си. RUP Organizer
Р
I’trsig, Robert, (Персиг, Роберт) 377-378
I’MBOK (Guide to the Project Management
Body of Knowledge), 294
I’M I (Project Management Institute), 294
Pi cssman, Roger, (Прессман, Роджер), 290
Process Engineering Toolkit, 213
Pi ocess Library, 213
Pioduct Release Milestone. Си. Готового
продукта, веха (Product Release Milestone)
l‘i ojcct Management Institute (PMI), 294
Pioject Review Authority (PRA) Группа
рецеп шрования проекта, 293
R
It IS (Reuse Asset Specification), 242,369
Rational ClearCase, 172
Rational ClearQuest, 230
Rational Developer Network (RDN), 50,204
Rational Process Workbench (RPW), 51,
212-213,398
Rational RequisitePro, 231
Rational Rose, 59
Rational Suite TestStudio, 231
Rational Unified Process. Си. RUP
(Rational Unified Process)
Rational XDE
RUP Modeler как дополнение к, 212
и Структурные Плагины RUP, 215
как руководство по использованию
инструментов, 48
распаковка средств и методов стандарта RAS,
369
RDN (Rational Developer Network), 50
Reuse Asset Specification (RAS), 242,369
ROI (return on investment), Окупаемость
инвестиций
и инструменты автоматизации, 229-230
и создание артефактов, 63
Royce, Walker, (Ройс, Уокер) 262
RPW (Rational Process Workbench), 50,
212-213,398
RUP (Rational Unified Process)
внедрение. См. Внедрение
итеративный подход к разработке, 36-39
как модифицируемый технологический
продукт. См. RUP продукт
конфигурация. См. Конфигурация
(Конфигурация процесса RUP)
определение, 33-34
плагины. См. Плагины
подход, 34-39
процесс разработки программного
обеспечения. См. Программное
обеспечение, процесс разработки
ресурсы. См. Ресурсы
технологическая основа, 49-51
RUP Builder
внедрение RUP в проект, 225-226
импортирование Плагинов RUP в, 217-218
общий обзор, 202-204
определение, 398
RUP Exchange
скачать Плагины RUP, 204
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
4(
RUP Library
и конфигурации процесса RUP, 202,204
определение, 399
RUP Modeler
как дополнение к Rational XDE, 212
общий обзор, 212
определение, 399
создание Структурных Плагинов
с помощью,
214-218
RUP Modeler и RUP Organizer, 212-213
RUP Organizer
общий обзор. 213
определение, 399
создание Структурных Плагинов
с помощью,
214-218
создание Гонких Плагинов с помощью,
213-214
RUP Process Library, 213
RUP продукт, 49-56
добавление расширений к, 49
компании, использующие, 54-55
общий обзор, 49-50
средства доставки, 52-54
средства создания собственных процессов
и конфигураций, 50-52
RUP, Глоссарий, 299
RUP, Конфигурация процесса. См.
Конфигурация (Конфигурация процесса
RUP)
RUP, подход
RUP-база
и Конфигурации процесса RUP, 202
определение, 398
S
SAD (Software Architecture Document),
Описание архитектуры программы
общий обзор, 333-334
перечисленные критические прецеденты
использования, 129
Проектирование с применением, 335
роль разработчика, 351,370
Scrum, 80-81
SDP (Software Development Plan), План
разработки программного обеспечен!
общий обзор, 294-296
разработка менеджером проекта, 298,
299-300
SEEA (Software Engineering Environmei
Authority), 293
SEI СММ (Capability Maturity Model),
84-86
SEI CMMI, 85-86
SEPA (Software Engineering Process
Authority), 293
Software Engineering Environment
Authority (SEEA), 293
Software Engineering Process Authority
(SEPA), 293
Software Process Engineering Metamodel
(SPEM), 39
SPEM (Software Process Engineering
Metamodel), 39
Statement of Work (SOW), Техническое
задание, 123
т
The User-Experience Modeling Plug-In for
the RUP, 323
u
UML-модели, 323
Users
акцент фазы Внедрение. 185
выполнение желаний, 61-62
выпуск бета-версии, 180-181
готовность к неожиданным реакциям.
157-158
и бета-тестирование фазы Внедрение.
190-191
и итерации фазы Внедрение, 188
и раннее создание цепей обратной спя ш
179-180
избегание большого числа поздних
изменений, 279-280
определение области проекта. 123
подготовка к самостоятельной работке, 1’И
410
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
X (И’С. Представление задействованных
классов, создание, 353-354
X RAPS модель, 336-338
W
\\ еЬ-ресурсы
Web-службы, 72
для архитекторов, 346
менеджеров проекта, 301-302
XX eb-сапт проекта, 209-211
X
\ Р (Extreme Programming)
как гибкий процесс, 80-81
сравнение с архитектурой RUP, 286
Хбс । ракцин, ключевые, 340
Хи iоматизация тестирования,
архитектура, 388
X иоматизация,инструмент
оорьба с главными проблемами, 229-230
и выеокоформализоваипын подход, 90-91
\п । оматизация, тестирование
роль разработчика, 361
философия RUP, 382-383
цель. 287-288
Х и...иная разработка, 80-81
X 1ми||пстратор баз данных, Database
Administrator, DBA 347
X кiopi.1
кыявление/оиисаннс в фазе Начало, 123-126.
313-315
легализация в фазе Начало, 126-127, 316
определение, 396
Хиализ времени выполнения
описание архитектором, 341-342
описание в фазе Проектирование, 154
тегирование, проводимое разработчиком,
361-362
Хна in писи, 303-326
и би шее-операции, 305-307
и желания заинтересованных лиц, 308-309
и у ючненпе моделей, .319-324
миссия, 303-305
обновлепие/уточпепис требований, 324
отправная точка для, 305
пример спецификации прецедента
использования, 319-321
разработка Концепции, 309-312
разработка модели прецедентов
использования/глоссария, 312-318
ресурсы для, 326
роль, 325
тестирование требований, 325
Аналитический паралич, 282-283
Артефакты
главные тесты, 385-387
и внедрение RUP, 264-269
и методика оценки SE1 СММ. 84-85
и приемочное тестирование продукта,
196-197
и создание исполняемой программы, 63
и фазы жизненного цикла RUP, 116-117
общий обзор, 45
определение, 43, 396
составление прецедентов разработки,
206-209
Архитектор, 327-346
задачи, 338-344
и архитектура, 330-334
миссия, 327-330
разработчик работает в тесном контакте с.
348,351
ресурсы для, 345-346
роль. 335-336, 343-344
функции, 336-338
Архитектура, 330-334
автоматизации тестирования, 388
внедрение RUP, 267-269, 272
и итеративный подход, 38
и модели/иредставлепия, 331-333
и Описание архитектуры программы
(Software Architecture Document). 333-334
н Проект Деймос, 103
и риски. 59
и тестирование. 75-77
компонентная против функциональной
декомпозиции, 70-71
многослойная, 146-147
определение ключевых функций системы,
128, 130-132
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
411
определение, 68, 330-331
организация команд вокруг, 73-74
повторное использование, 284
прототипы,333
рецензирование, 343
стоимость изменений в, 66
укрепление в фазе Построение, 172-173
Архитектура, в фазе Проектирование,
145-158
архитектурные механизмы, 155
архитектурный охват, 153-154
и критические прецеден ты использования.
148-151
и подсистемы/ключевые компоненты, 147-148
и реакции пользователя, 157-158
интеграция, 156
итерации в, 141-143
общий обзор, 145-147
объединение и сбор классов в пакеты, 151-153
описание архитектуры времени выполнения,
154
проектирование баз данных, 154
разработка основы, 285-287
реализация, 156
тестирование, 156-157
Архитектурная основа
к концу фазы Проектирование, 285-287
общий обзор, 147
определение, 396
ранняя разработка в проекте, 35, 68-69
Архитектурная целостность
и связь между командами, 330
обеспечение в фазе Построение, 164
роль архитектора в поддержании, 343
Архитектурные механизмы (шаблоны)
выявление в фазе Проектирование, 155
общий обзор, 334
определение, 68
роль разработчика, 351, 369
укрепление в фазе Построение, 172
Архитектурный охват, 153-154
Архитектуры Жизненного, Цикла,
веха, 41
Б
База. См. RUP-база
Базис. См. Архитектурный базис
Базы данных
проектирование в фазе Построение. 177
проектирование в фазе Проектирование. I '• I
развертывание в фазе I locipoeniie, 181-18.’
развертыванис/конвертировапис в фазе
Внедрение, 194-195
реализация/тестироваппе разработчиком, 36 ’>
Бета-релиз
подготовка к развертыванию, 166. 180-1X1
проект Деймос, 109-110
тестирование. 185, 190-192, 197
Библиотеки
RUP Library, 204
RUP Process Library, 213
Бизнес-моделирование, 304,305-307
В
Вехи
включение в план проекта. 247-248,
250-252
и фазы жизненного цикла RUP, 40-43.
114-115
определение, 397
роль менеджера проекта в проверке. 299
стоимость изменений, 66
Витрувий,328
“Включения”, определение, 282
Внедрение RUP, 219-243
в крупных организациях, 230-237
в программах с крупными изменениями,
238-242
в программах с умеренными
изменениями, 237-238
выполнение, 226-228
и автоматизация с помощью
инструментов, 229-230
и пустословие о RUP, 272
конфигурирование/реализация. 225-276
общий обзор, 219-221
оценка, 221-222
планирование, 223-224
проверка, 228
412
првдменый УКАЗАТЕЛЬ
Внедрение RUP, ошибки
внедрение слишком многого, 264-266
псинкремептпое внедрение, 266-269
общий обзор, 263-264
отсутствие планирования, 269-270
пустословие, 271-272
реализации, 271
совершенствования процесса и бизнес-
результатов, 270-271
Внедрение, фаза, 184-199
бета-тестирование в, 190-191, 192
веха Готового продукта, 198
выпуск исправлений/бста-версий. 192
п артефакты, 116-117
и итерации, 186-188, 253-254
и Проект Деймос, 101
н совершенствование грядущих проектов,
197-198
и фаза Построение, 258
конвертирование рабочих баз данных,
194-195
метрики,193-194
минимизация рисков, 114-115
неверные представления о, 113-114
несколько предложений, 275-276
обучение пользователей, 194
общий обзор, 184-185
определение, 43, 399
подготовка к выпуску и упаковка, 195-196
подготовка маркетинговых материалов, 196
подготовка площадки для развертывания,
194-195
приемочное тестирование продукта, 196-197
проекты по совершенствованию процесса и
инструментов, 234
рабочие процессы, 115-116
роль аналитика в, 325
роль архитектора в, 338
роль тестировщика в, 390
тестирование в, 191, 388-390
цсли/вехи, 41, 185-186
цена изменений, 66
цикл разработки, 188-189
Военные стандарты разработки
программного обеспечения, 87
Временные ограничения
задач, относящихся к прецедентам
использования, 127
и цели фазы Начало. 123, 126
общий обзор, 246
Выполнение
и внедрение RUP, 220-221, 228-229
развертывания RUP. 236
Выполнение требований
постепенное совершенствование, 268
принципы,34
руководство по, 61 -62
Выпуск исправлений (patches), 192
Выпуск продукта, упаковка , 195-196
Выпуски
и внедрение RUP, 266, 269
и итеративная разработка, 364
и релизы, 364
определение, 246, 396
планирование интеграции, 365-366
роль разработчика, 366-367
роль тестировщика, 391
Высоко-формализованный подход
в сравнении с Каскадным/Итеративным,
80-81
использование в RUP, 88-89
факторы, заставляющие использовать,
90-91
Г
Глоссарий
модификация в фазе Проектирование, 144
разработка аналитиком,312
создание в фазе Начало, 126, 319
этой книги, 396-399
Готового продукта, веха (Product Release
Milestone), 41
включение в план проекта, 248
общий обзор, 198
Готовые коммерческие компоненты
(Commercial Off-the-Shelf (COTS)
components), 284
Границы
и длительности итераций, 252
и несколько итераций, 121
и планирование итераций, 256
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
413
и управление проектом, 294
определение в фазе Начало, 123
стоимость изменения, 67
Граиичные классы, 353
Группа рецензирования проекта (Project
Review Authority), 293
д
Движение «За гибкую разработку» (Agile
Development Movement), 80-83
Детали рабочего процесса, 46
Детальный план проекта, 247-249
Дефекты
итеративный подход к, 38
метрики для анализа фазы Внедрение,
192-193
определение, 388
Диаграмма сотрудничества, 356
Динамическая структура процесса
общий обзор, 40-43
определение, 39-40
Дисциплины
как высокоуровневый рабочий
процесс, 46
определение, 397
перечень, 47-48
Доведение до совершенства, 279
Документация
запросы заинтересованных лиц, 309-312
и философия тестирования RUP, 382-383
и функционально-ориентированные
команды, 273-274
написание Концепции, 309-310
оценка проекта RUP, 228-229
Документация, фаза Внедрение
и приемочное тестирование продукта, 196-197
обучение пользователей, 194
продукт в упаковке, 195-196
совершенствование, 191
Долговременное хранение, 363
Дополнительная литература для
аналитиков, 326
архитекторов, 345-346
менеджеров проекта, 302
разработчиков, 371
тестировщиков, 394
Дополнительная спецификация
(Supplementary Specification), 350
Дорожные карты, 47
Достаточно хорошее качество. См. GEQ
(Good Enough Quality), Достаточно
хорошее качество, понятие
“Дух RUP.” См. также Руководства
и пустословие, 271-272
инкрементное совершенствование, 268
общий обзор, 35
роль аналитика в следовании, 317-318
Ж
Жизненный цикл, фазы, 40-43
3
Заглушки
разработка, 366
эмуляция компонентов с помощью, 361
Заглушки 147
Задачи
архитектора, 338-344
жизненного цикла RUP, 114-117
итерации, 258-259
менеджера проекта, 297-299
методика оценки SE1 СММ, 84-85
общий обзор, 44
определение, 44, 396
тестировщика, 388-393
шаги, 45
Заинтересованные лица
деловой акцент, 270-271
документирование запросов от, 308-309
и детализация требований, 283-284
и несколько итераций, 121
и партнерство, 337-338
неспособность сформировать правильные
ожидания, 274-276
определение, 308
роль архитектора, 330
соглашение о том, что создавать, 122-128
Запросы на изменения
акцепт на управлении изменениями, 267
по дефектам и бета тестам, 190
проект Деймос, 111
414
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
Зеленая разработка
п планирование итераций,257
кадровое обеспечение, 256
определение, 245
И
и итеративная разработка, 36-39
Идеи тестов, список
и философия тестирования RUP, 382-383
общий обзор. 386
II ииспення
взгляд с точки зрения гибкой
разработки, 51
п бета-тестирование, 190-191
и внедрение RUP, 219
избегание большого числа на поздних
папах, 279-280
преимущества итеративной
разработки, 38
признаки завершения фазы Проектирование,
286-287
ранее приспособление в проекте к. 35
реализация крупных, 258-262
реализация умеренных, 237-238
руководства ио, 65-68
создание структурных Плагинов, 215-217
Индивидуальные рабочие пространства,
365
Инженер-технолог (Process Engineer), 344
Инкапсуляция, 70
Ппсгрукции по использованию
инструментов (Tool Mentors)
использование в процессе, 48
общий обзор, 53-54
определение, 46, 399
планирование процесса и инструментальной
среды, 224-225
Инструменты автоматизации
выявление протестированного кода, 361
достижение окупаемости инвес тиций с
помощью, 220, 229-230
и итеративный подход, 88
и эффективность разработки, 90-91
реализация в фазе Начало, 135-136
тестирование критических сценариев,
156-157
тестирование при недостаточном
использовании, 380-381
Инструменты. См.также ПСПИ
(Проекты по совершенствованию
процесса и инструментов)
доставки, 50,52-54
настройки среды под
оценка эффективности, 228
планирование, 223-224
реализация в фазе Начало, 135-136
создания собственных конфигураций
и процессов, 50-52
тестирование при недостаточном
использовании, 380-381
Интеграционные рабочие пространства,
267,365
Интеграция
в фазе Проектирование, 156
итеративный подход к, 37-38
планирование в фазе Построение, 172
продвижение в фазе Построение, 174
рабочие пространства, 365
роль разработчика в планировании,
364-367
тестирование в фазе Построение,
178-179
Интерфейс, компонент
выявление в фазе Проектирование,
147-148
набросок/завершенный вид в Проекте
Деймос, 106-107
определение, 70
Исполняемая архитектура
инкрементное совершенствование, 268
общий обзор, 120-121
Исполняемая программа
и пустословие о RUP, 272
инкрементное совершенствование, 268
концентрация на, 63-65, 287-288
Использование шаблонов, 369
Итеративная разработка
и RUP, 36-39
концентрация на, 266
неверное представление о, 113-114
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
Итеративная разработка, ошибки,
272-280
введение в заблуждение заинтересованных
лиц, 274-275
использование функциональной,
специализированной организации,
273-274
количество разработчиков в начале проекта,
275-277
общий обзор, 272-273
перекрывающиеся итерации. 278-279
поздние изменения, 279-280
расширенные первые итерации, 277-278
решение сначала легких проблем, 276-277
Итерации
борьба с главными рисками, 58-60
длительность, 255, 277-278
и командный дух, 36
и фаза Внедрение, 186-188
и фаза Начало, 121-122
и фаза Построение, 165-169
и фаза Проектирование, 141-143
и фазы жизненного цикла RUP, 41-42
избегание перекрытии, 278-279
количество, 253-254
определение, 246, 397
роль менеджера проекта, 295-296, 298-300
совершенствование процесса/инструмснтов в.
226-228
совершенствование средств и методов
тестирования после, 393
философия тестирования, 382-383
К
Кадровое обеспечение. См. также
Команды
включение в план проекта, 248
возможные степени итеративности, 254
и создание плана проекта, 249-252
планирование, 256
Карта процессов
СММ/СММ1, 84-86
военные стандарты разработки
программного обеспечения, 87
Гибкие процессы, 82-83
информация о совершенствовании
процесса с помощью, 79
размещение на, 92-93, 95
сравнение процессов, 81
технологическая основа RUP
и конфигурации, 88. 91
Каскадная разработка
акцепт па пнепектпроваипях в, 287-288
п невозможность внедрения RUP. 272
и Нпзкоформализованпый/
Высокоформалпзовапный подход. 8(1
и фаза Внедрение. 185
к чему ведут неверные ожидания. 274-275
кривая снижения риска, 58
определение, 36
подход к тестированию при, 382-383
поощрение со стороны СММ, 84-85
против итеративного подхода, 36-39. 8
113-114
Качество
акцент фазы Внедрение, 191
п количественная опенка, 377-378
инкрементное улучшение, 268. 381
понятие о, 374-375
представления о, 375-376
принципы подхода к, 36
руководства по. 75-77
соответствие стандартам. 378-379
увеличение системного тестирования
и интеграционного тестирования. 17
цена, 376-377
“Качество от проектирования”, 76
Классы. См. также проектная модел
прецеденты
использования/компоненты
архитектурный анализ, 339-340
объединение и сборка в пакеты
выявленных. 151-153
реализация критических сценариев I
Классы-сущности, 354
Клиент/Сервер, архитектура, 130-132
Ключевые абстракции, 340
Код
непрерывное тестирование, 174
принципы подхода, 35
416
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
реализация/модульпое тестирование, 177
рецензирование, 360-361
количественная оценка и качество,
177-378
Команды
архитекторов, 329
и высоко-формализованные проекты, 84
и шеративный подход, 38-39. 88
и каскадный процесс разработки, 36
и несколько итераций. 121
и пилотные проекты, 234-236
и принципы подхода, 36
о продвижение, 174
набегание функциональной
ориентированности. 273-274
инкрементное внедрение, 267
организация вокруг архитектуры, 169-170
роль менеджера проекта. 291-293
руководства, 73-75
Комплект тестов, 386
Компоненты процесса
общий обзор, 202
определение, 398
Компоненты, фаза Построение
1аперщепие проектирования, 176-177
интеграция, 178-179
шерации, 167-168
|есгирование, 177
Компоненты. См. также Проектная
модель прецеденты
исиользования/компоненты; Процесс,
компоненты
инкрементное совершенствование, 268
интегрирование в фазе Проектирование, 156
описание в фазе Проектирование, 147-148
определение, 396
повторное использование сторонних
средств, 284
принципы подхода, 35
развитие, 178
роль разработчика, 359-360
руководства, 70-72
с тоимость изменения, 66
|муляция при помощи заглушек, 361
Конвейерная организация, 38
Контрактные проблемы, 294
Конфигурация (Конфигурация процесса
RUP)
внедрение RUP, 220, 225-226.
228-229, 267
и карта процессов, 88, 91
и Прецедент разработки, 206-208
инструменты, 50-52, 108-109
модификация шаблонов, 206
определение, 398
развертывание, 236
создание Представлений процесса,
204-205
создание, 202-204
ссылки с Web-сайта проекта. 209
Концептуальный прототип, 321
Концепция
архитектурная, 338-339, 339-340
и внедрение RUP, 267
изменение, 116-117
определение. 399
Проект Деймос, 98-99, 104, 107-108
разработка, 309-312
роль менеджера проекта, 297-298
согласование высокоуровневой, 122
создание документа, 122-123
Л
Лидерство, и архитекторы, 328
Логические представления, 331
Людские ресурсы, 294
м
Маркетинговые материалы, 196
Матричная организационная структура, 73
Менеджер по конфигурациям, 347
Менеджер проекта, 290-302
задачи, 297-299
заключение, 300-301
и планы итераций, 249
и управление проектом, 293-297
избегание слишком поздних изменений,
279-280
миссия, 290-293
найти своп путь, 299-300
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
417
работа совместно с архитектором, 329.
338-340
ресурсы, 301-302
техника оценки, 259-261
Метрики
и завершение фазы Внедрение, 192-194
роль менеджера проекта, 297. 299
Министерство обороны (Department of
Defense, DOD), 87
Миссия
аналитиков. 303-305
архитекторов, 327-330
менеджеров проекта, 290-293
разработчиков, 347-349
тестирования, 373-379, 390, 392
формулировки, 383-384
Многослойная архитектура, 146-147
Модификация, 211-218. См. также RIJP
внедрение RUP, 220, 225-226, 228-229
и Process Engineering Toolkit, 212-213
и Rational Process Workbench. 212-213
итеративный подход к. 271
общий обзор, 211-212
развертывание'. 236
структурные плагины RUP. 214-218
тонкие плагины RUP, 213-214
шаблонов RUP. 206
Модульное тестирование, 177
Мозговые штурмы, 123-126
Мотивировка, 244-245
н
Нагрузкой, тестирование, 157
Начало, фаза
задание ритма проекта. 277-278
и артефакты, 116-117
и руководства по тестированию, 76
и Целей жизненного цикла, веха, 136
избегание излишней детализации
требований в, 282-283
краткий обзор. 227
неверные представления о, 113-114
общий обзор, 119-120
определение архитектуры. 130-132
определение функциональности спск'ми
128-130
определение, 42, 397
планирование итераций, 121-122,
253-254, 257
принятие решений о процессе.
инструментах. 134-136
принятие решений о том, что создав,! i >.
122-128
Проект Деймос, 100
проекты по совершенствованию ирои,,. ,
и инструментов, 233
рабочие процессы. 115-116
разбиение проекта иа несколько
предложений, 275-276
риски, 114-115, 133-134
роль аналитика, 313-316
роль архитектора. 335
роль тестировщика. 388-390
стоимость внесения изменений. <><>
цели/вехп, 41, 120, 136
цена, сроки, риски, 114-115. 13 ’ 1 51
Начальной функциональной
готовности, веха, 41
включение в план проекта. 247-.’ 18
Инспекции, 287-288
общий обзор, 183
Недочеты. См. Дефекты
Нефункциональные требования,
323-324
Низко-формализованный подход
в сравнении с Каскадным/Итер.-ппвным
80-81
и движение «За гибкую разработ ь\
80-83
использование в RUP. 88-89
факторы, заставляющие применял,. HO-'il
О
Обобщения, определение, 282
Обратная связь
и бета-тестирование фазы Внедрение,
190-191
и непрерывное совершенствование
процесса, 242
418
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
и ранняя установка в фазе Построение,
179-180
Обслуживаемость, определение, 388
Обучение
и внедрение RUP, 223-224
и итеративный подход, 38-39
п окончательное развертывание, 181-182
п реализация, 225-226
и схема проекта RUP, 226-228
пользователей/обслуживающего персонала,
194
(Кипение
организация вокруг архитектуры, 169-170
роль архитектора, 328-330
роль менеджера проекта, 292
Общие планы проекта, 247-249
< »бя imhhocth, определение, 245
<) рапичеиия
добавление к формулировке Концепции, 108
н ожидания заинтересованных сторон,
274-275
< >купаемость инвестиций (Return on
investment, ROI)
и создание артефактов. 63
и средства автоматизации, 229-230
Описание архитектуры программы. См.
SAD (Software Architecture Document)
Оплошности. См. Ошибки
Ошимизации, 261-262
< >пыт архитектора, 328
Ортпизации
внедрение RUP в крупных, 230-237, 293
избегание функционально-ориентированной
структуры, 273-274
получение подтверждения от руководства, 270
Оценка
высокоформализовапный подход к, 84-87
и внедрение RUP, 220-222, 228-229, 236
и итеративный подход, 39
против акцента на инспекциях, 287-288
цель тестировщика в, 373
Оценка результатов
и внедрение RUP, 220, 228-229
и планирование итераций,256
и развертывание RUP, 236
миссия, 383-384
роль тестировщика в, 392
сводная оценка результатов тестирования,
385
Оценки,планирование проектов
и Широкополосная модификация
Дельфийского метода, 260-261
общий обзор, 259-260
роль менеджера проекта, 297
Ошибки
аналитический паралич, 282-283
включение проектных решений в
требования, 283
завершение фазы Проектирование без
стабильной архитектуры, 285-286
итеративной разработки. Си. Итеративная
разработка, ошибки
нет оценки исполняемой программы,
287-288
нет повторного использования
компонентов/решений, 284-285
при внедрении RUP. Си. Внедрение RUP,
ошибки
слишком много прецедентов
использования, 281-282
утверждение заинтересованными лицами.
283-284
п
Параллелизм
обрисовка в фазе Проектирование, 154
определение, 388
Параллельная разработка, 164
Парное программирование, 82,370
Партнерство, 337-338
Первоначальный цикл разработки
кадровое обеспечение, 256
общий обзор, 245-246
планирование итерации, 257
Переработка кода Refactoring, 368
Персонал. См. Команда
Пилотные проекты
внедрение RUP, 270
выполнение, 234-236
определение, 232
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
419
реализация крупных изменений, 240-241
реализация умеренных изменений, 237
Плагины
внедрение RUP с помощью, 225-226
инструменты создания собственной
конфигурации/процесса, 50-52
определение, 397
откуда скачать, 204
построение Конфигурации процесса RUP с
помощью, 202-203
создание, 212-213
Структурные, 212, 214-218
Тонкие, 211,213-214
План интеграции (Integration Build Plan),
365-366
План разработки программного
обеспечения. См. SDP (Software
Development Plan)
Планирование. См. также Планы
проекта
внедрения RUP, 220, 228-229
и риски,159-160
развертывания RUP, 236
роль менеджера проекта, 300
роль разработчика, 365-366
Планы итераций. См. Итеративная
разработка, ошибки, Планы проекта
Планы проекта, 244-262. См. также
Планирование
и длительности итераций, 255, 278-279
и количество итераций, 253-254
и пустословие о RUP, 272
и Широкополосная модификация
Дельфийского метода, 260-261
кадровое обеспечение, 256
мотивировка, 244-245
общий обзор, 247-253
общий/детальный, 247-250
оптимизация, 261-262
основные понятия, 245-246
оценка, 259-261
разработка итераций, 256-259
роль менеджера проекта, 295-296
Планы тестирования, 386
Повторное использование
итеративный подход к, 38
максимизация при разработке, 369
Подсистемы
завершение проектирования, 176-177
обеспечение архитектурного охвата,
153-154
объединение выявленных классов
в пакеты,151
определение, 147-148
Подтверждение концепции, прототип, 340
Подход, направляемый прецедентами
использования, 61-62
Поколения программного обеспечения, 188
Пользовательского интерфейса (UI),
прототипы
дополнения к описанию прецедентов
использования, 317
разработка, 319-323
рецензирование разработчиком,350
снижение рисков с помощью, 59
Последовательностей, диаграмма, 358
Последовательность событий,
структурирование, 317-318
Потоки,154
Практические методы. См. также
Руководства
концепция, 82
определение, 49
разработчика, 367-371
Предложения, проект, 275-276
Предметной области модель
модификация к концу фазы Начало, 319
определение, 312
получение важной информации с
помощью, 315
Представление задействованных
классов (View of Participating classes),
создание, 353-354
Представления
Представление процессов, 52
типы архитектурных представлений, 332-33'
Представления процесса
MyRUP, 52-53
общий обзор, 52
420
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
определение, 331, 398
создание, 204-205
11 рецедент разработки
альтернативы, 211
доступ к Web-сайту проекта, 209-211
определение, 397
подход менеджера проекта к, 295-296
принятие решений по процессу, 134
создание, 206-209
уточнение в фазе Проектирование, 140,160-162
Прецедентов использования, модели
пример спецификации, 319-321
роль аналитика в разработке, 312, 314-316
руководства по детализации, 316-318
тонкая настройка, 319
Прецеденты использования,
представления, 333
Прецеденты использования, прототипы,
322-323
Прецеденты использования, реализации.
См. также Проектирование,
прецедентов
пспользования/компонентов
инкрементное внедрение RUP, 267
общий обзор, 150-151
Прецеденты использования. См. также
Проектирование, прецедентов
использоваиия/компоиентов
«мозговые штурмы» по выявлению, 125-126
архитектура на основе, 148-154
детализация, 126-127, 143-144, 316-318
задачи в фазе Построение, 175-176
описание границ проекта, 123
определение ключевых функций системы,
128-130
определение, 123, 399
планирование итераций на основе, 166-168
приоритеты,339
разработка модели прецедентов
использования, 312-316
распространенные ошибки, 272
реализация разработчиком, 359-360
решения при разработке, 116
создание слишком большого числа, 281-282
требования, 283, 350-351
Прецеденты тестирования, 111,387
Приемочное тестирование. См. Продукт,
приемочное тестирование
Принципы
движения «За гибкую разработку» (Agile
Development Movement), 82
определение, 46
основные, 245-246
Приоритеты, 311-312
Проблема, формулировка, Документ
Концепция, 309-310
Программирование
парное, 370
роль архитектора в, 342
руководства по реализации, 359-360
Программное обеспечение, процесс
разработки. См. также Статическая
структура процесса
RUP, 33
динамическая структура процесса, 40-43
и исполняемая программа, 63-65
и прецеденты использования, 62
цели, 96
Программное обеспечение, разработка,
подход к
и итеративная разработка, 36-39
определение RUP, 33
основные принципы, 34-36
руководства, 63-65
циклы разработки, 188-189
Программное обеспечение, разработка,
проекты
внедрение RUP в, 236-237
реализация крупных изменений, 240, 242
реализация умеренных изменений, 237
Продукт
понятие качества, 374-375
разбиение, 244
цели менеджера проекта, 291
что такое RUP, 33-34
Продукт, приемочное тестирование
общий обзор, 196-197
определение, 191
роль аналитика в, 325
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
421
Продукт, релизы. См. также
Бета-релиз
определение, 398
Проект Деймос, 108-110
сравнение с выпусками, 364
Проект Ганимед
описание, 92
подготовка к выпуску в фазе Построение,
181
продвижение в фазе Построение, 174
сравнение типов проектов, 93
Проект Гаиимед, фаза Начало
ключевые акторы и прецеденты
использования, 126-127
количество итераций, 121
критические прецеденты использования, 129
реализация процесса/инструментов, 135-136
стоимость, сроки и риски, 133
формирование архитектуры, 132
Проект Гаиимед, фаза Проектирование
и итерации, 141
подробное описание требований, 144
снижение существенных рисков, 159
тестирование исполняемой архитектуры, 158
уточнение Прецедента разработки, 160-161
Проект Генезис
мотивировка внедрения RUP в, 223-224
планирование внедрения RUP, 223-224
Проект Деймос, 96-111
внесение изменений, 107-108
набросок/завершенный интерфейс продукта,
106-107
общий обзор, 96-97
обязательства по, 103-105
описание, 91
первоначальная идея, 97-98
поставка бета-версии, 109-110
предложение, 98-103
сравнение типов проектов, 93
тестирование, 108-110
Проект Марс
описание, 92
подготовка к выпуску в фазе Построение,
181
продвижение в фазе Построение, 174
сравнение типов проектов, 93
Проект Марс, фаза Начало
ключевые акторы и прецеденты
использования, 127
количество итераций, 122
критические прецеденты использования,
130
реализация процесса/инструментов, 135
стоимость, сроки и риски, 133-134
формирование архитектуры, 132
Проект Марс, фаза Проектирование
и итерации, 141
подробное описание требований, 144
снижение существенных рисков, 159
тестирование исполняемой архитектуры,
157-158
уточнение Прецедента разработки,
160-161
Проект Меркурий
мотивировка внедрения RUP в, 221-222
планирование внедрения RUP, 223
Проект Юпитер
описание, 92-93
подготовка к выпуску в фазе
Построение, 183
продвижение в фазе Построение, 175
сравнение типов проектов, 93
Проект Юпитер, фаза Начало
ключевые акторы и прецеденты
использования, 128
количество итераций, 122
критические прецеденты использования,
130
реализация процесса/инструментов, 136
стоимость, сроки и риски, 134
формирование архитектуры, 132
Проект Юпитер, фаза Проектирование
и итерации, 141
подробное описание требований, 145
снижение существенных рисков, 159
тестирование исполняемой архитек'1 \ры,
158
уточнение Прецедента разработки,
160-161
Проект, Web-сайт, 209-211
Проект, рецензирования, 293
422
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
веха Готового продукта, 198
веха начальной функциональной готовности
Milestone, 183
веха Целей жизненного цикла, 136
Группа рецензирования проекта, 293
Проект Марс, 133-134, 159
Проект, управление, 293-297
границы,294
итеративная разработка, 296
общин обзор, 293-294
План разработки программного
обеспечения,
294-296
риски, 296
11 роектироваиие
базы данных в фазе Построение, 177
базы данных в фазе Проектирование, 154
дополнительный акцент в фазе Построение,
165, 176-177
избегание формулировки проектных
решений в требованиях, 283
инкрементное внедрение RUP, 267
исполняемая архитектура, 145-146
классы, 156
миссия аналитика, 304
реализация/тестирование базы
данных, 363
роль архитектора, 340, 342
роль разработчика, 350-351, 370
связь с тестированием, 76
стоимость внесения изменений в, 67
Проектирование, фаза, 138-162. См.
также Архитектура, в фазе
Проектирование
артефакты, 116-117
итерации, 141-143, 253-255, 257
набросок, 226-228
неверные представления, 113-114
общий обзор, 138-139
определение, 42, 397
подробное описание акторов/прецедентов
использования, 316-318
подробное описание требований, 143-145
проверка нефункциональных требований в,
323-324
Проект Деймос, 100-101
проекты по совершенствованию процесса
и инструментов, 233
рабочие процессы, 115-116
разбиение проекта на несколько
предложений, 275-276
риски в, 59, 114-115, 159-160
роль архитектора, 335-336
роль разработчика, 348, 352
роль тестировщика, 388-390
руководства по тестированию, 76
стоимость изменений в, 66
уточнение Прецедента разработки,
160-162
цели/вехи, 41, 139-140
Проектная модель, 358-360
Проектная модель, прецеденты
использования/компонеиты, 352-359
классы аналитической
модели/аналитическая модель,
356-357
классы проектной модели/проектная
модель, 358-360
общий обзор, 352-353
проект прецедента использования,
357-358
распределение функций по аналитическим
классам, 354-356
черновой набросок, 353-354
Проекты по совершенствованию
процесса и инструментов. См. ПСПИ
(Проекты по совершенствованию
процесса и инструментов)
Производительность
и RUP-процесс, 228
и анализ времени выполнения, 361-362
оценка, 221
совершенствование будущей, 197-198
тестирование в фазе
Проектирование, 157
Промышленность, отрасли, 54-55
Прототипы
архитектурные, 333
определение, 398
прецедента использования, 322-323
создание архитектурного подтверждения
концепции, 340
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
42
Прототипы пользовательского
интерфейса. См. Пользовательский
интерфейс, прототипы
Процесс, зрелость, основа оценки,
84-85
Процесс, инструменты
конфигурирования,
50-52,108-109
Процесс, Конфигурации. См.
Конфигурация (Конфигурация процесса
в RUP)
Процесс, совершенствование
непрерывное, 242
связь с бнзнес-результатами, 270-271
Процесс, средства доставки
общий обзор. 52-54
определение, 50
Процессы
набросок в фазе Проектирование. 154
понятие о, 82
разбиение, 244-245
разработка содержательной части,
217-218
реализация в фазе Начало, 134-136
роль менеджера проекта, 291-292
уточнение в фазе Проектирование.
140, 160-162
Процессы времени выполнения, 341-342
Процессы, сравнение, 79-95
высоко-формализованный подход, 83-87
и степень формализованное™, 89-91
насколько итеративный, 89
нпзко-формалнзованный подход, 80-83
общий обзор, 79-80
определение конфигурации RUP, 91-93
Процессы, средства создания собственных
общий обзор, 52
определение, 50
ПСПИ (Проекты по совершенствованию
процесса и инструментов), РТЕР
и пилотные проекты, 234-236
непрерывное совершенствование, 242
определение, 232
реализация крупных изменений. 238-7 I ’
реализация умеренных изменений. 237
фазы, 232-234
Р
Рабочей нагрузки модель, 387
Рабочие пространства
и парное программирование, 360
управление конфигурациями, 365
Рабочий процесс
нефиксированный, 115-116
общий обзор, 46
определение, 43, 399
Развертывание
Внедрение, 194-195
определение, 397
планирование, 223-224
подготовка к выпуску на рынок. 19и
Построение, 179-182
представления, 333
Разработчики, 347-372
и частое проведение интеграции.
364-367
миссия, 347-349
общий обзор задачи. 349-350
ограничения в начале проекта. 771-7 '
ограничения в требованиях/проек ..
модели, 350-351
практические методы, 367-371
проектирован!., прецедента
использования/компонента. 357-
проектирование, реализация и
тестирование баз данных, 361
реализация прецедента
использования/компонента. 359- и>о
ресурсы для, 371
связь с архитектором, 330
тестирование, 360-362
Распределенность
определение, 388
физическая, 154
Расширенная справка (Extended Help)
общий обзор, 54
определение, 397
424
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
Реализация (instantiation), 206-211
альтернативы Прецедентам разработки, 211
и Web-сайт проекта, 209-211
и Прецеденты разработки, 206-209
Реализация. См. также внедрение
как избежать промахов, 269-270
модульное тестирование в фазе Построение,
177
представления, 332
роль архитектора, 341
роль разработчика, 349, 359-360
стоимость внесения изменений в, 67
целей фазы Построение. 165
Регрессионное тестирование
акцент фазы Внедрение, 191
общий обзор, 77
уменьшение стоимости, 178
Релизы. См. Продукт, релизы
Ресурсы для
аналитиков, 326
архитекторов. 345-346
менеджеров проекта, 301-302
разработчиков, 371
тестировщиков, 394-395
Ресурсы для обучения
аналитиков, 326
разработчиков, 371
тестировщиков, 395
Рецензирования
архитектуры, 343
Группа рецензирования проекта (Project
Review Authority), 293
кода, 360-361
Риск
и длительность итераций, 252
и завершение проектирования в фазе
Построение, 177
и инкрементное совершенствование, 268
и исполняемая архитектура, 63
и несколько итераций, 121
и пилотные проекты, 234
и фазы разработки, 114-115
итеративный подход к. 38
менеджер проекта и, 296
определение, 398
понимание в фазе Начало, 133-134
принципы подхода к, 34
руководства, 58-60
Риск, снижение
борьба с рисками, 140
и внедрение RUP, 266, 270
и итерации, 141-143
и критические прецеденты использования.
150
планирование проекта и оценка
стоимости, 159-160
цели, 139-140
Риски,список
и пустословие о RUP. 272
неспособность справиться с трудностями.
293-277
Проект Деймос, 101, 105, 107-108
Ритм, 337
Роли
аналитика, 325-326
архитектора, 335-336, 343-344
п главные вехи, 115
менеджера проекта, 291-292
общий обзор, 43
определение, 43, 398
разработчика, 371
составление Прецедента разработ ки. 208
тестировочныс, 385
Руководства, 57-78
борьба с рисками, 58-60
добавление, 48
исполняемая архитектура, 68-70
исполняемая программа
качество,75-77
компоненты, 70-72
общий обзор, 57-58
определение, 46
польза, 61-62
приспособление к изменениям, 65-68
работа в команде, 73-75
разработка архитектором, 334, 342
языки программирования, 360
Рынок/сообщество пользователей, 50
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
421
С
Сводная оценка результатов
тестирования,385
Свойств список, 310-311
“Сделано не у нас”, подход
общий обзор, 284-285
практические методы разработчика, 369
Семинары, 124-125
Синхронизация, 157
Система управления конфигурациями
(Configuration Management System,
CMS), 171-172,190-191
Система, определение ключевых функций,
128-130
Система, тестирование, 178-179
Слежение, 299
Сообщество пользователей/рынок, 50
Спецификации. Си. Стандарты
Спецификация материалов (Bill of
Materials, BOM), 195
Средства доставки. Си. Средства
доставки процесса
Сроки, 133-134
Стандарты
и высокая формализованпость, 86-87
соответствие, 378-379
Статическая структура процесса,
43-48. Си. также Программное
обеспечение, процесс разработки
артефакты, 45
дисциплины, 47-48
дополнительные элементы процесса. 46
задачи, 44
общий обзор, 43
определение, 40
рабочие процессы, 46
роли, 43-44
Стереотипы, 353
Стоимость
RUP не имеет дело с такими проблемами,
294
внесения изменений, 66-68
и качество, 376-377
и тестирование программного
обеспечения, 380
минимизация регрессионных тестов, 178
оценка в фазе Проектирование, 159-160
понимание в фазе Начало, 133-134
цели фазы Построение, 165-166, 168
Структурные плагины RUP
внедрение RUP в проект, 225-226
определение, 212
создание, 214-218
Сценарии
определение, 399
реализация/тестирование критических, 156
т
Терминология
глоссарий книги, 396-399
создание глоссария проекта, 126
Тест на герметичность, 391
Тестами вперед, разработка, 82, 368
Тестирование
бета-, 185, 190-191, 197
и внедрение RUP, 267, 272
и оценка, 287-288
и производительность, 146-147
критичные сценарии, 156
необходимость, 88
определение, 279-381
прецедентов использования в фазе
Проектирование, 143-144
Проект Деймос, 108-110
роль разработчика, 360-362, 367-368
руководства по, 75-77
Тестирование, в фазе Внедрение
метрики. 193-194
общин обзор, 191
приемочное тестирование продута. 196-19"?
роль аналитика, 325
Тестирование, в фазе Построение
акцепт, 165
итерации, 167-168
обеспечение продвижения, 173-174
реализации, 177
системы, 178-179
Тестирование, подход, 391
426
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
I <ч1прованне, средства и методы, 393
1 eciпровщики, 373-395
задачи, 388-393
ключевые артефакты тестирования,
385-387
миссия, 37.3-379
определение тестирования,379-381
различные роли, 385
ресурсы для, 394-395
философия тестирования RUP, 382-384
I ссшруемость, 388
I истового интерфейса спецификация, 388
Типовые заглушки. См. Заглушки
I eciовые сценарии, 386
I ее । овые циклы
общий обзор, 384
определение, 393
роль тестировщика, 392
I схиическое задание, (Statement of Work,
SOW), 123
1 ихнологическая база (Process
l iainework), 49-51
I пшене Плагины RUP
внедрение RUP с помощью. 225-226
определение, 211
сощаиие, 213-214
Iребования
детализация в фазе Проектирование, 140,
143-145
и внедрение RUP, 266, 269
обычные ошибки, 272, 282-284
принципы подхода к, 34, 37
продвижение в фазе Построение, 167-168,
175-176
роль аналитика, 304, 313-316, 324-325
роль архитектора, 338-340
роль разработчика, 350-351
У
Упаковка, 195-196
Управление итеративной разработкой, 38
Управление конфигурациями и
шменениями. См. ССМ (Управление
конфигурациями и изменениями)
Управление. См. также Управление
проектом
отсутствие корректировки ожиданий, 274-276
получение утверждения от, 270
Управляющие классы, 353
Упрощение архитектуры, 338
Утверждение
бизнес-результатов, 271
внедрения RUP, 270-271
детализации требований, 283-284
Ф
Фаза Построение, 163-183
артефакты, 116-117
внедрение, 179-180, 181-182
завершение проектирования, 176-177
и множественные предложения, 275-276
и прецеденты использованпя/требования,
175-176
интеграция/тестированис системы,
178-179
итерации, 166-169, 253-255, 258
набросок, 228
Начальной функциональной готовности.
веха, 183
неверное представление о, 113-114
общий обзор, 163-165
определение, 42, 397
организация вокруг архитектуры.
169-170
перепроектирование баз данных в. 363
подготовка к выпуску бета-версии,
180-181
Проект Деймос, 101
проектирование баз данных, 177
проекты по совершенствованию процесса
и инструментов, 233-234
рабочие процессы в, 115-116
рсализация/модулыюе тестирование всего
кода. 177
роль архитектора, 338
роль разработчика, 352
роль тестировщика, 388-390
Система управления конфигурациями,
171-172
снижение рисков в, 114-115
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ
4:
стабилизация архитектуры перед. 284-287
стоимость изменений в, 66
укрепление архитектуры. 172-175
цели/вехи, 41, 165-166
Фазы
общий обзор, 113-118
определение, 246, 397
роль аналитика, 304-305
роль менеджера проекта, 298-299
Физическое распределение, 154
Формализованность, определение, 79
фундаментальные принципы, 34-36
Функциональная декомпозиция,
архитектура, 70-71
Функциональная структура организации, 73
Функциональность, системы основная,
128-130
Функциональные требования, 62, 350
ц
Целей Жизненного Цикла, веха, 41
Целей жизненного цикла, Веха, 41,136,247
Цели
архитектора, 328
и фаз жизненного цикла RUP и, 40-43
инкрементное внедрение RUP, 266-269
итерации, 255-256
мотивировка внедрения RUP, 219, 221
обеспечение прогресса в фазе Построение,
173-174
ограничение времени (time-boxing), 246
фаз жизненного цикла RUP, 116
фазы Внедрение, 185-186
фазы Начало, 120
фазы Построение, 165-166
фазы Проектирование, 139-140
Цели, 245
Цикл
общий обзор, 245
определение, 397
Цикл разработки
возможные степени итеративности, 254
и фаза Внедрение, 188-189
общий обзор. 188-189. 245
Циклы поддержки
кадровое обеспечение, 256
определение, 245
ш
Шаблоны
Process Engineering Toolkit. 213
добавление, 48
модификации RUP, 206
определение, 46
Шаги
в задачах, 45
определение, 399
Широкополосная модификация
Дельфийского метода, 260-261
э
Эволюционирующий прототип,
145-146
Эволюционные циклы
и кадровое обеспечение, 256
и планирование итераций,257
определение, 189, 245
Экономическое обоснование
акцент, 270-271
и множественные итерации, 121
изменение, 116-117
мотивировка внедрения RUP, 221-222
проверка, 228
проект Деймос, 99, 102-103, 105
роль менеджера проекта в. 297-298
стоимость, сроки и риски в. 133-134
Экстремальное программирование
(Extreme Programming, ХР)
архитектура RUP в сравнении с, 286
как гибкий процесс, 80-81
ю
Юридические проблемы, 294
och)
1223803
"Пер Кролл (Per Kroll) и Филипп Крачтен (Philipp Kruchten) Научная библиотека зны
к тому, чтобы объяснить RUP... поскольку они являюто тульского государственного университета 1ии
в Rational Software за созданием RUP и его внедрением в г
- из вступительного <
Эта книга является полным руководством по современным практ
программного обеспечения, воплощенным в Rational Unified Proc _____
практические советы и понятия, даваемые в этой книге, практикующие специалиыы
создания программного обеспечения научаться тому, как преуспеть в выполнении сложных проектов,
как крупных, так и небольших, используя доказавший свою эффективность итеративный,
направляемый рисками подход.
Книга "Rational Unified Process - это легко" даст вам представление о ключевых моментах
планирования и управления итеративным проектом, об основах компонентного дизайна
и архитектуры программы и о правильном применении прецедентов использования.
Все члены команды, от менеджеров проекта до аналитиков, от разработчиков
до тестировщиков, узнают, как можно немедленно начать применять RUP в своей работе. Вы
увидите, что RUP - это гибкая, разносторонняя технологическая основа, которую можно настроить
на нужды конкретных проектов любого типа и размера.
Охватываются следующие основные темы:
Как использовать RUP для итеративной разработки, для того, чтобы внедрить архитектурно-
центрический подход, снизить риски и проконтролировать качество программного обеспечения.
Задачи, связанные с четырьмя фазами RUP: начало, проектирование, построение
и внедрение.
Роли и области ответственности менеджеров проекта, архитекторов, аналитиков, разработчиков,
тестировщиков и инженеров-технологов в проекте с использованием RUP.
Инкрементное внедрение RUP с минимальным риском.
Распространенные ошибки внедрения и использования RUP, и как их избежать.
Используя эту книгу, вы быстро войдете в курс дела, и сможете легко воспользоваться значительной
мощью этого процесса для повышения производительности работы своей команды.
Пер Кролл (Per Kroll) - директор в Rational Software Corporation, он отвечает за разработку
и руководство Rational Unified Process. Мистер Кролл имеет пятнадцатилетний опыт разработки
программного обеспечения, включая десять лет работы в качестве инструктора, наставника
и консультанта по RUP и его предшественникам. Кроме того, он проводит сертификацию
компаний-партнеров и обучает персонал компании Rational выполнению работ, связанных с RUP.
Филипп Крачтен (Philippe Kruchten) - ведущий архитектор Rational Unified Process. У мистера
Крачтена - более чем двадцатисемилетний опыт создания крупных программных систем
в телекоммуникационной, оборонной, аэрокосмической и транспортной отраслях, и в области
инструментов для разработки программного обеспечения. Он также является автором книги
"The Rational Unified Process, An Introduction" (Addison-Wesley), которая была переведена на семь
языков, и выпущена тиражом более 150000 экземпляров в двух изданиях.
I
ISBN 5-9579-0019-2
По вопросу приобретения книг обращайтесь в издательство по тел. 333-82-11
с II00 до 1700. Наш адрес: ул. Профсоюзная, д. 84/32, под. б, эт. 11
Изяункиая
КУДИЦ-ОБРАЗ
тел./факс: (095) 333-82-11, 333-65-67 1 |
E-mail: ok@kudits.ru; |
http://books.kudits.ru ........... |
121354, Москва, а/я 18, "КУДИЦ-ОБРАЗ"
http://www.awprofessional.com/otseries, http://www.rupmadeeasy.com
9
785 95 7
900191
Addison-Wcslev