Книга, написанная признанными специалистами в области разработки программного обеспечения, описывает унифицированный процесс создания сложных программных систем, включающий в себя как использование средств унифицированного языка моделирования UML — стандартного способа визуализации, конструирования, документирования и пересылки артефактов программных систем, — так и все фазы подготовки и управления этим процессом. Эта книга будет полезна аналитикам, разработчикам приложений, программистам, тестерам и менеджерам проектов.
Содержание
Предисловие
Что такое процесс разработки программного обеспечения?
Зачем написана эта книга
Для кого предназначена эта книга
Подход, принятый в книге
История Унифицированного процесса
Подход компании Ericsson
Язык спецификации и описания
Objectory
Подход компании Rational
Rational Objectory Process: 1995-1997
Унифицированный язык моделирования
Rational Unified Process
Благодарности
За вклад в эту книгу
За многие годы
Особые благодарности
Процесс наступает
От издательства
Часть 1. Унифицированный процесс разработки программного обеспечения
Глава 1. Унифицированный процесс:
управляемый вариантами использования, архитектуро-ориентированный,
итеративный и инкрементный
Унифицированный процесс в двух словах
Унифицированный процесс управляется вариантами использования
Унифицированный процесс ориентирован на архитектуру
Унифицированный процесс является итеративным и инкрементным
Жизненный цикл Унифицированного процесса
Продукт
Разделение цикла разработки на фазы
Интегрированный процесс
Глава 2. Четыре «П» — персонал, проект, продукт
и процесс — в разработке программного обеспечения
Персонал решает все
Процессы разработки влияют на персонал
Роли будут меняться
Размещение «Ресурсов» внутри «Сотрудников»
Проект порождает продукт
Продукт — это больше, чем код
Что такое программная система?
Артефакты
Система содержит набор моделей
Что такое модель?
Каждая модель — это самодостаточное представление системы
Модель изнутри
Связи между моделями
Процесс направляет проекты
Процесс как шаблон проекта
Связанные деятельности образуют рабочие процессы
Специализированные процессы
Похвала процессу
Средства и процесс — одно целое
Средства жестко привязаны к процессу
Процесс управляет средствами
Баланс между процессом и средствами его осуществления
Унифицированный язык моделирования поддерживает визуальное моделирование
Средства поддерживают весь жизненный цикл системы
Глава 3. Процесс, направляемый
вариантами использования
Введение в разработку, управляемую вариантами использования
Зачем нужны варианты использования?
Определение требований, приносящих ощутимый и измеримый результат, важный для заказчика
Управление процессом
Задание архитектуры
Определение вариантов использования
Модель вариантов использования отражает функциональные требования
Актанты — это среда, в которой существует система
Варианты использования определяют систему
Анализ, проектирование и разработка при реализации варианта использования
Создание по вариантам использования аналитической модели
Каждый класс должен играть все свои роли в кооперациях
Создание модели проектирования из аналитической модели
Классы группируются в подсистемы
Создание модели реализации из проектной модели
Тестирование вариантов использования
Резюме
Глава 4. Архитектуро-центрированный процесс
Введение в архитектуру
Зачем нужна архитектура?
Понимание системы
Организация разработки
Повторное использование
Развитие системы
Варианты использования и архитектура
Шаги разработки архитектуры
Базовый уровень архитектуры
Использование образцов архитектуры
Описание архитектуры
Архитектор, создающий архитектуру
Описание архитектуры
Архитектурное представление модели вариантов использования
Архитектурное представление модели проектирования
Архитектурное представление модели развертывания
Архитектурное представление модели реализации
Три интересных понятия
Что такое архитектура?
Как ее получить?
Как ее описать?
Глава 5. Итеративный и инкрементный процесс
Введение в итеративность и инкрементность
Разрабатываем понемногу
Чем не является итерация
Почему мы используем итеративную и инкрементную разработку?
Снижение рисков
Получение устойчивой архитектуры
Поддержка изменяющихся требований
Доступность тактических изменений
Достижение постоянной целостности
Достижение легкой обучаемости
Итеративный подход — управляемый рисками
Итерации снижают технические риски
За нетехнические риски отвечает руководство
Работа с рисками
Обобщенная итерация
Что такое итерация?
Планирование итераций
Последовательность итераций
Результат итерации — приращение
Итерации в жизненном цикле программы
Модели в ходе итераций совершенствуются
Итерации проверяют организацию
Часть 2. Основной рабочий процесс
Глава 6. Определение требований — от концепции к требованиям
Почему трудно определять требования
Цели процесса определения требований
Обзор процесса определения требований
Роль требований в жизненном цикле разработки программного обеспечения
Понимание контекста системы с помощью модели предметной области
Что такое модель предметной области?
Разработка модели предметной области
Использование моделей предметной области
Понимание контекста системы с помощью бизнес-модели
Что такое бизнес-модель?
Как разработать бизнес-модель
Поиск вариантов использования по бизнес-модели
Дополнительные требования
Резюме
Глава 7. Определение требований в виде вариантов использования
Введение
Артефакты
Артефакт: Модель вариантов использования
Артефакт: Актант
Вариант использования
Артефакт: Описание архитектуры
Артефакт: Глоссарий
Артефакт: Прототип интерфейса пользователя
Сотрудники
Сотрудник: Системный аналитик
Сотрудник: Спецификатор вариантов использования
Сотрудник: Разработчик интерфейса пользователя
Сотрудник: Архитектор
Рабочий процесс
Деятельность: Нахождение актантов и вариантов использования
Деятельность: Определение приоритетности вариантов использования
Деятельность: Детализация вариантов использования
Деятельность: Создание прототипа интерфейса пользователя
Деятельность: Структурирование модели вариантов использования
Рабочий процесс определения требований: резюме
Глава 8. Анализ
Введение в анализ
Кратко об анализе
Почему анализ — это не проектирование и не реализация
Цели анализа: краткий обзор
Конкретные примеры случаев, в которых следует использовать анализ
Роль анализа в жизненном цикле программы
Артефакты
Артефакт: Модель анализа
Артефакт: Класс анализа
Артефакт: Анализ реализации варианта использования
Артефакт: Пакет анализа
Артефакт: Описание архитектуры (представление модели анализа)
Сотрудники
Сотрудник: Архитектор
Сотрудник: Инженер по вариантам использования
Сотрудник: Инженер по компонентам
Рабочий процесс
Деятельность: Анализ архитектуры
Деятельность: Анализ варианта использования
Деятельность: Анализ класса
Деятельность: Анализ пакетов
Рабочий процесс анализа — резюме
Глава 9. Проектирование
Введение
Роль проектирования в жизненном цикле разработки программного обеспечения
Артефакты
Артефакт: Модель проектирования
Артефакт: Класс проектирования
Артефакт: Проект реализации варианта использования
Артефакт: Подсистема проектирования
Артефакт: Интерфейс
Артефакт: Описание архитектуры (представление модели проектирования)
Артефакт: Модель развертывания
Артефакт: Описание архитектуры (представление модели развертывания)
Сотрудники
Сотрудник: Архитектор
Сотрудник: Инженер по вариантам использования
Сотрудник: Инженер по компонентам
Рабочий процесс
Деятельность: Проектирование архитектуры
Деятельность: Проектирование вариантов использования
Деятельность: Проектирование класса
Определение обобщений
Деятельность: Проектирование подсистемы
Рабочий процесс проектирования — резюме
Глава 10. Реализация
Введение
Роль реализации в жизненном цикле разработки программного обеспечения
Артефакты
Артефакт: Модель реализации
Артефакт: Компонент
Артефакт: Подсистема реализации
Артефакт: Интерфейс
Артефакт: Описание архитектуры (Представление модели реализации)
Артефакт: План сборки
Сотрудники
Сотрудник: Архитектор
Сотрудник: Инженер по компонентам
Сотрудник: Системный интегратор
Рабочий процесс
Деятельность: Реализация архитектуры
Деятельность: Сборка системы
Деятельность: Реализация подсистемы
Деятельность: Реализация класса
Деятельность: Выполнение тестирования модулей
Рабочий процесс реализации: резюме
Глава 11. Тестирование
Введение
Роль тестирования в жизненном цикле программы
Артефакты
Артефакт: Модель тестирования
Артефакт: Тестовый пример
Артефакт: Процедура тестирования
Артефакт: Тестовый компонент
Артефакт: План тестирования
Артефакт: Дефект
Артефакт: Оценка теста
Сотрудники
Сотрудник: Разработчик тестов
Сотрудник: Инженер по компонентам
Сотрудник: Тестер целостности
Сотрудник: Системный тестер
Рабочий процесс
Деятельность: Планирование тестирования
Деятельность: Разработка теста
Деятельность: Реализация теста
Деятельность: Проведение тестирования целостности
Деятельность: Проведение тестирования системы
Деятельность: Оценка результатов тестирования
Тестирование: резюме
Часть 3. Итеративная и инкрементная разработка
Глава 12. Обобщенный рабочий процесс итерации
Необходимость баланса
Фазы, на которые предварительно разбивается работа
Фаза анализа и планирования требований определяет выполнимость
Фаза проектирования обеспечивает возможность выполнения
Фаза построения создает систему
Фаза внедрения переносит систему в среду пользователей
Еще раз об обобщенной итерации
Основные рабочие процессы повторяются на каждой итерации
Сотрудники участвуют в рабочих процессах
Планирование предваряет деятельность
Планирование четырех фаз цикла
Планирование итераций
Взгляд в будущее
Планирование критериев оценки
Риски влияют на планирование проекта
Управление списком рисков
Влияние рисков на план итераций
Выделение рискованных действий
Расстановка приоритетов вариантов использования
Риски, характерные для отдельных продуктов
Риск не создать правильную архитектуру
Риск неправильного определения требований
Требуемые ресурсы
Проекты сильно различаются
Как выглядит типичный проект
Сложный проект требует большего
Новая линия продуктов требует опыта
Цена за использование ресурсов
Оценка итераций и фаз
Критерии не достигнуты
Критерии сами по себе
Следующая итерация
Развитие набора моделей
Глава 13. Анализ и планирование требований инициирует проект
Введение
В начале фазы анализа и планирования
Перед началом фазы анализа и планирования требований
Планирование фазы анализа и планирования требований
Расширение концепции системы
Задание критериев оценки
Типичный поток работ итерации на фазе анализа и планирования требований
Введение в пять основных потоков работ
Погружение проекта в среду разработки
Определение критических рисков
Выполнение основных рабочих процессов от определения требований до тестирования
Определение требований
Анализ
Проектирование
Реализация
Тестирование
Определение исходных деловых перспектив
Формулировка бизнес-предложения
Оценка доходности инвестиций
Определение итераций в фазе анализа и планирования требований
Планирование фазы проектирования
Результаты фазы анализа и планирования требований
Глава 14. Фаза проектирования создает базовый уровень архитектуры
Введение
В начале фазы проектирования
Планирование фазы проектирования
Построение команды
Модификация среды разработки
Задание критериев оценки
Типичный поток работ итерации на фазе проектирования
Определение и уточнение большей части требований
Разработка базового уровня архитектуры
Пока команда малочисленна — ищите путь
Выполнение основных рабочих процессов —
от определения требований до тестирования
Определение требований
Анализ
Проектирование
Реализация
Тестирование
Определение деловых перспектив
Подготовка бизнес-предложения
Уточнение доходности инвестиций
Оценка результатов итераций и фазы проектирования
Планирование фазы построения
Основные результаты
Глава 15. Фаза построения приводит к появлению
базовых функциональных возможностей
Введение
В начале фазы построения
Персонал для осуществления фазы
Задание критериев оценки
Типичный рабочий процесс итерации в фазе построения
Выполнение основных потоков работ — от определения
требований до тестирования
Определение требований
Анализ
Проектирование
Реализация
Тестирование
Контроль бизнес-плана
Оценка результатов итераций и фазы построения
Планирование фазы внедрения
Основные результаты
Глава 16. Внедрение завершается выпуском продукта
Введение
В начале фазы внедрения
Планирование фазы внедрения
Персонал для осуществления фазы
Задание критериев оценки
Основные потоки работ на этой фазе не играют почти никакой роли
Что мы делаем на фазе внедрения
Выпуск бета-версии
Установка бета-версии
Реакция на результаты тестирования
Адаптация продукта к различным операционным средам
Завершение артефактов
Когда заканчивается проект
Завершение бизнес-плана
Контроль прогресса
Пересмотр бизнес-плана
Оценка фазы внедрения
Оценка итерации и фазы внедрения
Результаты экспертизы законченного проекта
Планирование следующего выпуска или версии
Основные результаты
Глава 17. Заставим Универсальный процесс работать
Универсальный процесс помогает справиться со сложностью
Цели жизненного цикла
Архитектура жизненного цикла
Базовые функциональные возможности
Выпуск продукта
Основные темы
Руководство управляет переходом на Универсальный процесс
Момент истины
Приказ о реинжиниринге убеждает в необходимости перехода
Осуществление внедрения
Специализация Унифицированного процесса
Привязка процесса
Заполнение каркаса процесса
Универсальный процесс для широкого круга лиц
Определение пользы от использования Универсального процесса
Приложение А. Обзор языка UML
Введение
Словарь
Механизмы расширения
Графическая нотация
Понятия, относящиеся к структуре
Понятия, относящиеся к поведению
Понятия, относящиеся к группировке
Понятия, относящиеся к примечаниям
Отношения зависимости
Отношения ассоциации
Отношения обобщения
Механизмы расширения
Глоссарий терминов
Приложение Б. Расширения UML, специфичные
для Универсального процесса
Введение
Стереотипы
Именованные значения
Графическая нотация
Приложение В. Основной глоссарий
Введение
Понятия
Литература
Алфавитный указатель
ОТРЫВОК
Ч а с т ь 2
Основной рабочий процесс
Теперь, когда мы разобрались с базовыми понятиями, лежащими в основе ключевых действий Унифицированного процесса, мы подробно рассмотрим каждый из рабочих процессов. В части 3 будут описаны фазы и итерации процесса разработки.
В части 2 мы рассматриваем основные рабочие процессы — по одному в каждой главе. В главах 6 и 7 описана работа с требованиями, в главе 8 — анализ, в главе 9 — проектирование, в главе 10 — реализация и наконец в главе 11 — тестирование. Понятие «рабочий процесс» — это абстракция, подробно описанная в главе 5. В ходе итераций мы сосредоточиваемся на осуществлении рабочих процессов. Этой теме будет посвящена часть 3.
Описание каждого из основных рабочих процессов отдельно от других может ввести читателя в заблуждение. Во-первых, описывая основные рабочие процессы один за другим, мы создаем у читателя впечатление, что в процессе разработки программного обеспечения от начала проекта до его конца вся последовательность рабочих процессов проходится лишь единожды. Читатель может решить, что основные рабочие процессы достаточно проделать в ходе разработки по одному разу, как в старом водопадном процессе разработки. Кроме того, неподготовленный читатель может посчитать, что базовый рабочий процесс есть нечто монолитное и неделимое.
Ни одно из этих представлений не является соответствующим истине. Мы описываем базовые рабочие процессы в отдельных главах, исходя исключительно из методических соображений, для обеспечения полноты и четкости описания каждого рабочего процесса.
Первое замечание касается схожести с водопадной разработкой. Мы осуществляем последовательно пять рабочих процессов, но делаем это по одному разу на итерацию, а не единожды для процесса в целом. То есть, если у нас есть семь итераций в четыре фазы каждая, мы можем проделать все рабочие процессы семь раз. Если вдуматься, мы не сможем использовать все пять рабочих процессов на ранних итерациях уже потому, что не дойдем до завершающих рабочих процессов, таких как реализация и тестирование, в ходе первых итераций. Принцип ясен: мы осуществляем на каждой итерации те рабочие процессы, которые нужны нам на данной итерации.
Перейдем к замечанию о монолитности и неделимости рабочих процессов. Мы описываем каждый из основных рабочих процессов совершенно независимо от остальных. Они, однако, взаимодействуют между собой, создавая и используя артефакты друг друга. В этой части книги мы попытались немного упростить каждый из рабочих процессов, сосредоточившись на основных его действиях, вновь по причинам методического характера. Мы не стали описывать чередование действий основного рабочего процесса с действиями в других рабочих процессах. Эти чередования необходимы для итерационного процесса разработки программного обеспечения, и мы, несомненно, подробно их рассмотрим — но в третьей части книги.
В части 3 мы описываем, как рабочие процессы, описанные по отдельности, объединяются в рабочий проект. Например, фазе анализа и определения требований может соответствовать лишь часть рабочих процессов, в то время как в фазе конструирования будет необходим их полный набор.
6. Определение требований — от концепции к требованиям
Поколение за поколением некоторые племена американских индейцев строили каноэ из выдолбленных стволов деревьев. Строители каноэ начинали с поисков дерева диаметром в несколько футов, лежащего неподалеку от воды. Около него они разводили костер и клали горящие угли на бревно. Обугленную древесину было намного проще удалять теми каменными инструментами, которые были в их распоряжении. После того как через несколько дней выдалбливания каноэ, казалось бы, было полностью готово, строители выталкивали его на мелководье. Более чем вероятно, что первый вариант каноэ просто переворачивался. Каноэ не было сбалансировано. Следовало проделать еще много работы этими ужасными каменными инструментами, пока у строителей не получалась лодка, которая не опрокидывалась, когда кто-то наклонял ее, чтобы вытянуть рыбу из воды. Только после этого она считалась законченной. Это умение передавалось из поколения в поколение и врастало в кровь и плоть строителей.
Когда «племя» разработчиков программного обеспечения получает заказ на разработку новой системы, они оказываются в другом положении. Прежде всего, разработчики не являются будущими пользователями системы. Они не будут иметь немедленной и полной информации относительно того, как работает их «каноэ». Во вторых, они не занимались непрерывным изготовлением таких продуктов с раннего детства, и требования к системе и ограничения не вросли в их кровь и плоть. Вместо этого они должны понять, что от них требуется.
Мы называем этот акт постижения определением требований. Это процесс выяснения, что же должно быть создано. Этот процесс затруднителен. Фактически это настолько трудно, что для разработчиков все еще является обычным делом начать писать код (что довольно просто) раньше, чем они поймут, что этот код должен делать (что значительно сложнее).
Почему трудно определять требования
Профессиональные разработчики программного обеспечения обычно создают программы не для себя, а для других людей — пользователей программного обеспечения. «Так, — говорят разработчики, — пользователи должны знать, что им нужно». Однако даже небольшой опыт получения требований от пользователей показывает, что они — не идеальный источник информации. Прежде всего, у любой системы обычно множество пользователей (или категорий пользователей), и в то время как каждый пользователь знает свою работу, никто не может увидеть картину в целом. Пользователи не знают, как работа в целом может быть сделана более эффективной. Большинство пользователей не знает, какие аспекты их работы могут быть переложены на программу. На самом деле пользователи часто не знают даже, что такое требования и как их точно изложить.
Традиционным подходом к этой проблеме было поручение выявления списка требований каждого пользователя посредникам — аналитикам — в надежде на то, что аналитик будет способен увидеть картину в целом и разработать полное, правильное и непротиворечивое техническое задание. Аналитики обычно записывают требования в документах размером в сотни, а иногда и тысячи страниц. Но абсурдно полагать, что человеческий мозг может создать полный, верный и непротиворечивый список из тысяч заявлений «система должнај». Что более важно, эти спецификации требований невозможно быстро преобразовать в проектные и рабочие спецификации.
Даже с помощью аналитиков пользователи не до конца понимали, что должна делать программная система, пока она не была почти закончена. Когда проект развивался, пользователи, посредники и сами разработчики начинали видеть, на что будет похожа система, и лучше понимать реальные потребности пользователей. Поступало множество предложений об изменениях. Многие из них действительно следовало бы сделать, но их выполнение обычно влекло за собой серьезное нарушение сроков и рост затрат.
Многие годы мы вбивали себе в голову, что пользователи знают, что такое требования, и что все, что мы должны сделать, — это расспросить их. Действительно, системы, которые мы создаем, должны быть удобны для пользователей, и мы можем изучать взаимодействие пользователя с программой, глядя на то, что делают пользователи. Однако значительно важнее то, что система должна выполнять ту задачу, для которой она создавалась. Например, система должна приносить результат, значимый для бизнеса, в котором она используется, и для клиентов системы, которые ее используют. Часто трудно понять, каким должен быть этот результат, а иногда невозможно создать систему, дающую такой результат. Более того, отражая меняющийся реальный мир, ценность этого результата сама может изменяться в ходе проекта: может измениться сам бизнес, могут изменяться технологии, при помощи которых формируется система, могут изменяться ресурсы (люди, деньги), при помощи которых формируется система и т. п.
Даже после этого озарения определение требований остается нелегким делом. В промышленности происходили длительные поиски хорошего, систематического процесса определения требований. Рассмотрением такого процесса мы и займемся в этой и следующей главах.
Цели процесса определения требований
Основная цель рабочего процесса определения требований состоит в том, чтобы направить процесс разработки на получение правильной системы. Это достигает ся описанием системных требований (то есть условий, которым должна соответствовать система). Описание требований должно быть достаточно хорошим для того, чтобы между клиентами (включая пользователей) и разработчиками могло быть достигнуто понимание по вопросу о том, что система должна делать и чего не должна.
Основное внимание следует обратить на то, что клиент, с которым мы работаем и для которого компьютеры не являются основной специальностью, должен быть способен прочесть и понять результаты определения требований. Чтобы выполнить это условие, мы должны использовать для описания результатов язык клиента. Как следствие, мы должны быть очень осторожны при включении в результаты определения требований формализмов, структуры и внутренних деталей работы программы.
Результаты рабочего процесса определения требований также помогают руководителю проекта планировать итерации и поставляемые клиентам выпуски (это обсуждается в части 3).
Обзор процесса определения требований
Каждый проект по созданию программного обеспечения уникален. Это следует из вариаций типов систем, клиентов, организаций, занимающихся разработкой, технологий и т. д. Также существуют и различные отправные точки для определения требований. В некоторых случаях мы начинаем с разработки бизнес-модели. Мы также можем получить готовую бизнес-модель, разработанную какой-нибудь другой организацией (см. подраздел «Что такое бизнес-модель?» данной главы).
В других случаях программное обеспечение создается для встроенной системы, которая не имеет прямой связи с бизнесом. Здесь уместно было бы сначала построить простую модель объекта, например модель предметной области (см. подраздел «Что такое модель предметной области?»). В некоторых случаях клиент, возможно, уже разработал полное, детальное техническое задание, не основанное на объектной модели. В таком случае мы начинаем работу, используя в качестве исходного документа это техническое задание.
В других случаях клиенты могут иметь весьма неопределенное понятие о том, что должна делать их система, полученное, может быть, из концептуальных утверждений высшего руководства. Между этими крайними положениями лежит все многообразие вариантов. Мы рассмотрим в качестве отправной точки один из вариантов — «неопределенное понятие», для чего введем пример, который будем использовать в остальной части этой книги.
Пример. Консорциум Interbank обдумывает компьютерную систему. Консорциум Interbank, гипотетическое финансовое учреждение, стоит перед серьезными изменениями в связи с отменой государственного контроля, конкуренцией и возможностями, открываемыми WWW. Консорциум планирует создать новые приложения для работы на быстро меняющихся финансовых рынках. Это заставляет его филиал, занимающийся разработкой программного обеспечения, Interbank Software, приступить к разработке этих приложений.
Interbank Software решает разработать биллинговую и платежную систему в сотрудничестве с некоторыми из крупных клиентов банка. Для пересылки заказов, счетов и платежей между покупателями и продавцами система будет использовать Интернет. Мотивацией для банка при разработке системы является привлечение новых клиентов. Новых клиентов должно привлекать предложение низких тарифов на проведение платежей. Банк будет также в состоянии уменьшить затраты на заработную плату, проводя платежные требования автоматически через Интернет вместо ручной обработки этих документов кассирами.
Мотивацией для покупателей и продавцов должно стать уменьшение затрат, документооборота и времени. Например, им больше не нужно будет посылать заявки или выставлять счета обычной почтой. Оплата счетов будет происходить между компьютером покупателя и компьютером продавца. Покупателям и продавцам будет также удобнее просматривать информацию об их счетах и платежах.
Возможность существования таких различных отправных точек, как неопределенные концепции и детальные технические задания, предполагает, что аналитики должны быть способны приспособить свой подход к определению требований в любой ситуации.
Различные отправные точки влекут за собой различные типы рисков, так что аналитики должны выбрать подход, максимально снижающий риски. Уменьшение рисков подробно обсуждается в части 3.
Несмотря на различие отправных точек, существуют шаги, которые можно сделать в большинстве случаев. Это позволяет нам предложить типовой рабочий процесс. Такой рабочий процесс включает в себя следующие шаги, которые обычно не выполняются по отдельности
Перечисление возможных требований.
Осознание контекста системы.
Определение функциональных требований.
Определение нефункциональных требований.
Мы кратко опишем эти шаги в следующих пунктах.
Перечисление возможных требований. В ходе функционирования системы клиентам, пользователям, аналитикам и разработчикам приходит в голову множество хороших идей, которые могли бы превратиться в реальные требования. Мы храним список этих идей, рассматривая его как подборку кандидатов на реализацию в будущих версиях нашей системы. Этот список предложений растет, когда в него добавляются новые пункты, и сокращается, когда кандидаты становятся требованиями или преобразуются в другие артефакты, например, варианты использования. Список предложений используется исключительно для планирования работ.
Каждое предложение имеет короткое название и содержит краткое объяснение или определение, ровно столько информации, сколько необходимо, чтобы обеспечивалась возможность обсуждать его при планировании разработки продукта. Каждое предложение содержит также набор планируемых значений, в которые могут входить:
состояние предложения (например, предложено, одобрено, включено в план, или утверждено);
сметная себестоимость выполнения (в терминах типов ресурсов и человеко-часов);
приоритет (например, критический, важный или вспомогательный);
уровень риска, связанного с реализацией предложения (например, критический, значительный или обычный, см. главу 5).
Эти планируемые значения вместе с другими аспектами (см. главу 12) используются для того, чтобы оценить размер проекта и решить, как разбить проект на последовательные итерации. Так, например, приоритет и уровень рисков, связанные с предложением, используются, чтобы решить, во время какой итерации реализовывать данное предложение (это обсуждается в части 3). Кроме того, когда мы планируем реализацию предложения, этот факт должен быть отражен в одном или более вариантах использования или дополнительных требованиях (которые мы вскоре обсудим).
Осознание контекста системы. Множество людей, вовлеченных в развитие программного обеспечения, являются специалистами в вопросах, имеющих отношение к программному обеспечению. Однако чтобы верно определить требования и правильно сформировать систему, ключевые разработчики — в частности, архитектор и некоторые старшие аналитики — должны понимать контекст, в котором работает система.
Имеется по крайней мере два подхода к описанию контекста системы в форме, доступной для разработчиков программ: моделирование предметной области и бизнес-моделирование. Модель предметной области описывает важные понятия контекста как объекты предметной области. Предметная область при этом связывает эти объекты друг с другом. Идентификация и наименование этих объектов помогают нам разработать словарь терминов, который поможет каждому, кто работает над системой, лучше ее понимать. Впоследствии, когда мы будем проводить анализ и проектирование нашей системы, объекты предметной области помогут нам распознать некоторые классы. Как мы увидим далее, бизнес-модель может быть представлена как надмножество модели предметной области. Она содержит доменные объекты, и не только их.
Цель бизнес-моделирования состоит в описании процессов — существующих или воспринимаемых — для того, чтобы понять их. Бизнес-моделирование — единственная часть бизнес-инжиниринга, которую мы будем использовать в этой книге [39]. Удовлетворимся замечанием, что бизнес-инжиниринг очень похож на бизнес-моделирование, но имеет своей целью также улучшение бизнес-процессов организации.
Когда аналитики моделируют бизнес, они получают обширную информацию о контексте программной системы и отражают ее в бизнес-модели. Бизнес-модель определяет, какие бизнес-процессы должна поддерживать система. Кроме идентификации вовлеченных в бизнес бизнес-объектов или объектов предметной области, бизнес-моделирование также устанавливает компетентности, необходимые для процессов: работников, их обязанности и действия, которые они должны выполнять. Это знание является определяющим при идентификации вариантов использования. Мы вскоре обсудим этот вопрос. Фактически подход бизнес-инжиниринга для определения требований при разработке бизнес-приложений является наиболее системным [39].
Архитектор и руководитель проекта совместно решают, ограничиться ли моделью предметной области или идти до конца и разрабатывать полную бизнес-модель, а может быть, не строить никакой модели вообще.
Определение функциональных требований. Прямой подход к выявлению системных требований основан на вариантах использования (варианты использования подробно рассматриваются в главе 7). Эти варианты использования охватывают как функциональные требования, так и те нефункциональные требования, которые специфичны для конкретных вариантов использования.
Опишем вкратце, как варианты использования помогают нам правильно определять требования. Каждый пользователь хочет, чтобы система выполняла для него какие-то действия, то есть осуществляла варианты использования. Для пользователя вариант использования — это способ, которым он взаимодействует с системой. Следовательно, если аналитики в состоянии описать все варианты использования, которые нужны пользователям, значит, они знают, что представляет из себя система с точки зрения функциональности.
Каждый вариант использования представляет собой один способ работы с системой (например, поддержку пользователя в ходе бизнес-процесса). Каждый пользователь нуждается в своих вариантах использования, каждый работает с системой по-своему. Чтобы определить варианты использования, которые необходимы в системе на самом деле, например, те, которые обслуживают бизнес или позволяют пользователям работать «удобным» для них способом, требуется, чтобы мы досконально знали потребности пользователя и клиента. Для этого мы должны разобраться в контексте системы, опрашивать пользователей, обсуждать предложения и т. д.
В дополнение к вариантам использования аналитики должны также определить, как должен выглядеть пользовательский интерфейс для реализации того или иного варианта использования. Самый лучший способ разрабатывать спецификацию пользовательского интерфейса — это набросать несколько версий представления информации, которую необходимо передать, обсудить эскизы с пользователями, сделать прототипы и отдать их пользователям на тестирование.
Определение нефункциональных требований. К нефункциональным требованиям относятся такие свойства системы, как ограничения среды и реализации, производительность, зависимость от платформы, ремонтопригодность, расширяемость, и надежность — все «-ости». Под надежностью понимаются такие характеристики, как пригодность, точность, средняя наработка на отказ, число ошибок на тысячу строк программы и число ошибок на класс. Требования по производительности налагают специфические условия на выполнение функций: скорость, пропускная способность, время отклика и используемая память. Большинство требований, связанных с производительностью, относятся лишь к нескольким вариантам использования и должны быть приписаны к этим вариантам использования как именованные значения (приложение A). Практически это означает, что эти требования должны быть описаны в правильном контексте, то есть внутри вариантов использования (возможно, в отдельном разделе «Специальные требования»).
Пример. Специальные требования к варианту использования «Оплата счета».
Требования по производительности. Когда покупатель подает счет к оплате, система должна выдать результат проверки запроса не медленнее чем за 1.0 секунду в 90 % случаев. Время проверки никогда не должно превышать 10.0 секунд, если только связь не разорвана (в этом случае пользователь должен быть уведомлен о разрыве связи).
Некоторые нефункциональные требования относятся к реальным объектам, например банковским счетам в системе, предназначенной для банка. Эти требования могут первоначально определяться в соответствующем бизнес-объекте или объекте предметной области в модели системы.
Позднее, когда будут определены варианты использования и «понятия», на основе которых они функционируют, эти нефункциональные требования будут связаны с соответствующими понятиями. Под «понятием» мы понимаем или неформальную статью в глоссарии, используемом для описания варианта использования (см. главу 7), или более формальный класс аналитической модели (см. главу 8). Для простоты в этой главе мы рассматриваем первый случай, то есть считаем, что требования связаны с понятиями из глоссария.
В заключение заметим, что некоторые нефункциональные требования являются слишком обобщенными и не могут быть привязаны к конкретному варианту использования или конкретному реальному классу. Они должны быть вынесены в отдельный список дополнительных требований (приложение В).
Резюме. Чтобы эффективно определить требования, аналитики нуждаются в наборе методов и артефактов, которые помогали бы им получить удобное изображение системы, такое, чтобы оно способствовало осуществлению рабочих процессов. Мы будем называть все эти артефакты в целом набором требований. Традиционные технические задания прошлого сменил набор артефактов: модель вариантов использования и дополнительные требования. Эти артефакты требуют, чтобы контекст системы был представлен в виде бизнес-модели или модели предметной области (рис. 6.1). Отметим, что варианты использования также содержат нефункциональные требования, специфичные для этих вариантов использования.
Унифицированный процесс разработки программного обеспечения. / А. Якобсон, Г. Буч, Дж. Рамбо - СПб: Питер, 2002. - 496 с.
|