Адаптация процесса: наиболее выгодное вложение в разработку
В процессе адаптации собирается уникальный процесс. Не существует такого проекта, в котором было бы эффективно применить полный масштаб RUP. Поскольку RUP является инфраструктурой, набором компонентов и принципов разработки ПО, необходимо отобрать значимые элементы для реализации конкретного проекта, «сшивая» уникальный процесс разработки с целью повышения результативности проекта разработки.
Критическим фактором эффективности разработки является соответствие процесса и проекта. И «больше не лучше», и «меньше не лучше», отклонения в любую сторону критически влияют на эффективность проекта. Важно понимать, что разработка ПО направлена на создание конечного продукта — ПО. Поэтому на сопровождение разработки необходимо направлять минимальное, но, при этом, достаточное количество усилий. При сборке процесса разработки следует руководствоваться принципом соотношения получаемого результата и затрат (Return-on-investment).
В некоторых случаях разумно собирать RUP на двух уровнях: на уровне организации и на уровне проекта. Процесс на уровне организации (конфигурация организации) подготавливается с учетом предметной области, практик и технологий, традиционных для компании. При наличии такового, процесс на уровне проекта собирается на его основе.
Определение масштаба процесса
Процесс, собранный под проект, зависит от его особенностей: предметной области, интересов заинтересованных лиц, маркетинговых планов, объемов проекта, его новизны, назначения готового продукта и других. Сводная картина факторов выбора «уровня церемонии» процесса представлена на рисунке 10.
Рисунок 10 — Факторы, влияющие на уровень формальности процесса
Безусловно, при повышении технической сложности проекта и сложности управления, повышаются уровни формальности, строгости процесса разработки.
При определении процесса следует иметь в виду следующие факторы:
× Цель разработки: работа по договору, разработка для выхода на рынок, внутренний проект или пробная разработка;
× Масштаб проекта: стоимость, объем работ, количество реализуемых функций, количество разработчиков;
× Уровень новизны и техническая сложность проекта: типовой проект или ранее не разрабатывавшаяся система;
× Тип программного обеспечения и требования к надежности: настольная программа или система управления противоракетным комплексом.
В некоторых случаях нет необходимости собирать весь процесс разработки. Если в команде разработчиков есть опытные люди, им можно передать ответственность и право принимать решения относительно их части работы, а Инженер процессов разработки будет выполнят роль ментора при сборки процесса. Например, квалифицированный аналитик может взять на себя ответственность за определение процесса в части управления требованиями на протяжении всего проекта.
RUP для небольшого проекта
Основным вопросом при внедрении методологии для разработки небольшого проекта (менее полугода) и для небольшой команды разработчиков (до 10 человек), является «А стоит ли применять RUP вообще?». Есть несколько доводов в пользу применения RUP, вытекающие из принципов методологии:
× Снижение рисков проекта и повышение вероятности его успешного завершения;
× Накопление опыта разработки;
× Сопровождение разработки при помощи различных руководств и ряда хороших практик;
× Повышение качества разрабатываемого ПО;
× Повышение эффективности проекта — снижение сроков и стоимости.
Следует также повторить, что RUP не является «тяжелой» методологией.
Традиционной особенностью маленьких проектов является низкий уровень формальности. По этой причине, при сборке процесса для небольшого проекта следует придерживаться следующих рекомендаций:
× Минимизация количества документов, а также снижение уровня их детализации. Многие из результатов работ можно представлять неформально. Исключая ненужные документы и объединяя другие, вы получите оптимальный состав;
× Объединение ролей и работ;
× Применение небольшого набора средств разработки;
× Неформальные совещания должны заменить формальные рецензии и оценки.
Набор стандартных конфигураций RMC уже имеет в своем составе готовый процесс для маленького проекта, от которого и следует отталкиваться при сборке процесса.
Сборка процесса
После того, как масштаб процесса определен, необходимо выбрать уровень сборки. Сборка процесса разработки может быть выполнена на разных уровнях, с 1 по 6. Каждый последующий уровень является более сложным и дорогим. Шесть уровней сборки представлены в таблице 2.
Таблица 2 — Шесть уровней сборки процесса разработки
| Уровень | Описание уровня сборки процесса |
| 1 | Сборка RUP во внешнем документе. Процесс описывается в отдельном документе, который ссылается на описание RUP. Описание процесса может быть выполнено, например, в виде текстового документа или набора html-страниц. Примером такого документа может быть Описание разработки (Development Case) |
| 2 | Сборка на основе сайта My RUP (как спецификация RUP). Процесс описывается в отдельном документе и включает описание RUP. |
| 3 | Сборка конфигурации при помощи платформы сборки процесса (например, RMC) |
| 4 | Сборка с добавлением специфических руководств (например, шаблонов документов, существующих в организации). Создается «тонкий плагин» |
| 5 | Сборка с разработкой готового процесса, обычно на основе доступных целевых шаблонов |
| 6 | Сборка, затрагивающая изменение элементов наполнения — работ, результатов работ, ролей («структурный плагин») |
Когда определены и масштаб процесса, и способ сборки, следует приступить к самой сборке процесса, выполняя следующие действия:
1. Создать новые или уточнить существующие элементы наполнения (при необходимости);
2. Определить конфигурацию (состав элементов) в соответствии с масштабом процесса;
3. Собрать процесс на основе подготовленной конфигурации или выбрать готовый процесс;
4. Опубликовать собранный процесс (при необходимости) или выгрузить процесс для планирования разработки.
В подавляющем большинстве сборка процесса не требует разработки нового контента или изменения старого. Достаточно выбрать подходящую конфигурацию и готовый процесс и опубликовать его (уровень сборки 3 и выполнение шагов 2-3-4 сборки процесса).
Важной частью подготовки процесса разработки является определение модели жизненного цикла проекта, определяющая последовательность выполнения работ. ЖЦ должен определять при содействии менеджера проекта, поскольку от этого выбора сильно зависит планирование работ.
Постоянное улучшение процесса
Одним из основных преимуществ итеративной разработки в том, что она позволяет постоянно улучшать сам способ разработки ПО. После сборки процесса его можно улучшать на протяжении всего жизненного цикла, учитывая освоенные уроки каждой итерации. В улучшении процесса рекомендуется участвовать всем членам команды разработки.
Кроме того, «уровень церемонии» процесса не статичен, а меняется на протяжении всего жизненного цикла. На начальной фазе разработки, когда энтропия высока и традиционно важна креативность, хорошей практикой является снижение уровня формальности и концентрация на высокоуровневых планах и оценках. На следующих стадиях необходим более четкий контроль и детализированные планы, и уровень формальности повышают.
Применение подготовленного процесса
Собранный процесс является отправной точкой для планирования проекта, процесс разработки необходимо «запустить». Эта задача находится в компетенции менеджера проекта, который составляет на основе процесса действительные планы проекта и итераций, включает в них действительные работы, результаты работ, и роли.
Важно помнить, что План разработки (Software Development Plan) и Процесс разработки (Development Process) очень тесно связаны. Поэтому эти артефакты должны создаваться при тесном взаимодействии менеджера проекта и инженера процессов разработки.
Программная платформа сборки процесса
Хотя «сшивать» процесс можно и на бумаге или в текстовом редакторе, гораздо удобнее использовать специализированное программное обеспечение. Коммерческим продуктом для решения этих задач является IBM Rational Method Composer (RMC), некоммерческим (бесплатным) — Eclipse Process Framework (EPF). И RMC, и EPF основаны на ядре Eclipse. Основным функциональным отличием EPF является отсутствие возможности интеграции с другими продуктами IBM Rational, такими как Rational Portfolio Manager и Rational Software Architect.
Программная платформа сопровождения процесса предназначена для сборки процессов разработки на основе библиотеки элементов и шаблонов готовых процессов, разработки плагинов (расширений элементов наполнения) и публикации процессов. Публикация процесса, например, в виде веб-сайта, имеет особое значение для проекта, поскольку позволяет команде проекта быть в курсе всех изменений и использовать удобную навигационную систему.
Скачать PDF-версию с оригинальным оформлением. © Для использования опубликованных на ресурсе материалов достаточно упоминания имени автора и адреса первоисточника. Дата обновления: 2008-10-23.
Комментариев нет:
Отправить комментарий