Rational Unified Process - как достичь 2-го уровня CMM

Оглавление

• КРАТКИЙ ОБЗОР CMM
• ХАРАКТЕРИСТИКИ 2-ГО УРОВНЯ, "ПОВТОРЯЕМЫЙ"
• KPA 2-го уровня:
• 2-Й УРОВЕНЬ И RATIONAL UNIFIED PROCESS
• Управление требованиями
• Планирование проекта ПО
• Отслеживание и надзор за проектом
• Управление субподрядчиками
• Обеспечение качества ПО
• Управление конфигурацией ПО

Вы хотите обойти своих конкурентов?

Значит, Вы должны гарантировать высокое качество своего программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого временного графика и бюджета. Многие компании вкладывают деньги в улучшение своего процесса разработки и получают хорошую отдачу. В статье "Современные модели качества программного обеспечения" авторы, со ссылкой на западные источники, приводят следующие цифры: средний уровень возврата вложений в улучшение процесса составляет от 5:1 до 8:1.

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

Существует множество подходов к обеспечению качества ПО и соответствующих им стандартов. Но поскольку эта статья, как я надеюсь, носит чисто практический характер, мы остановимся только на одном из них - на Модели зрелости процесса разработки ПО (Capability Maturity Model - CMM) Института системного программирования при университете Карнеги-Меллон, США (SEI - Software Engineering Institute).Далее мы остановимся только на том, как организация может использовать Rational Unified Process (RUP) и средства его инструментальной поддержки для достижения 2-го (Повторяемый) уровня зрелости CMM. О достижении 3-го (Определенный) уровня мы поговорим в следующей статье.

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

Эта первая статья "дилогии" содержит краткий обзор CMM: только то, что необходимо для понимания и использования последующего материала. Тем, кто хочет более подробно познакомиться с концепциями CMM, можно порекомендовать уже упомянутую статью "Современные модели качества программного обеспечения". Там же предлагается некоторый глоссарий. Любознательные читатели могут прочитать первоисточник: Mark C. Paulk et al, "Key Practices of the Capability Maturity Model - Version 1.1", Software Engineering Institute - Carnegie Mellon University.

Разделы, посвященные использованию RUP для достижения 2-го (эта статья) и 3-го (следующая статья) уровней CMM, представлены по одному плану:

• Краткие характеристики уровня зрелости по CMM
• Перечисление ключевых областей процесса
• Использование RUP для достижения уровня
• Название ключевой области>
• Цели ключевой области, и какие средства предлагает RUP для их разрешения

• Управление требованиями
• Планирование проекта ПО
• Отслеживание и надзор за проектом
• Управление субподрядчиками
• Обеспечение качества ПО
• Управление конфигурацией ПО

• Модель прецедентов, состоящая из прецедентов и пакетов прецедентов
• Дополнительные спецификации
• Обзор модели прецедентов
• Отчет прецедента
• Глоссарий

Артефакты RUP, описывающие прецеденты и сценарии (требования), которые разрабатываются для использования в контексте управления:

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

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

Цель 1: Системные требования, предъявляемые к программному обеспечению, управляются так, чтобы установить базовые линии для проектирования и управления программным обеспечением.

RUP поддерживает управление конфигурацией всех артефактов разработки, однако, "формальные" базовые линии соответствуют следующим главным вехам:

• Главная веха "Цели жизненного цикла" (Стадия "Начало")
• Главная веха "Архитектура жизненного цикла" (Стадия "Уточнение")
• Главная веха "Начальная работоспособность" (Стадия "Конструирование")
• Главная веха "Выпуск изделия" (Стадия "Переход")

RUP согласуется с CMM относительно соглашений по требованиям, управлению ими, отслеживанию и базированию.

Цель 2: Планы, продукты и действия при разработке сохраняются совместимыми с системными требованиями, предъявляемыми к программному обеспечению

Основное в этой цели CMM - гарантия того, что поставленные системы выполняют требования пользователя. RUP помогает организациям достигнуть этой цели двумя путями:

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

Документы управления в RUP:

• Деловые обстоятельства
• План разработки программного обеспечения
• План измерений
• Список рисков
• План проекта
• План(ы) итерации
• Оценка(ки) итерации и Оценка(ки) состояния

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

RUP рекомендует каждому проекту учредить Группу управления изменениями (CCB), которая должна решать вопросы о возможностях и воздействиях (бюджетных, технических и т.д.) предложенных изменений или выявленных дефектов. Чтобы помочь операциям CCB, RUP рекомендует использование инструмента/среды конфигурационного управления и управления версиями.

Цель планирования проекта программного обеспечения состоит в том, чтобы установить разумные планы разработки программного обеспечения и управления программным проектом. Эти планы необходимы для управления программным проектом (как описано в KPA "Отслеживание и надзор за проектом"). Без реальных планов эффективное управление проектом не может быть реализовано.

Цель 1: Оценки программного обеспечения документированы для использования в планировании и отслеживании программного проекта.

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

Rational Unified Process использует следующие классы метрик:

• Продвижение (строки кода, число классов, функциональные точки в итерации, доработка)
• Стабильность (тип доработки, изменчивость требований или выполнения)
• Адаптируемость (затраты на доработку)
• Модульность (степень влияния доработки)
• Качество (быстрота обнаружения дефектов, компактность, глубина наследования, индикатор доработки)
• Завершенность (время тестирования на неисправность)
• Профиль затрат на ресурсы (запланированные относительно фактических)

Цель 2: Действия и обязательства проекта разработки программного обеспечения запланированы и документированы.

Документы Rational Unified Process, которые фиксируют проектные планы и обязательства:

• Деловые обстоятельства
• План разработки программного обеспечения
• План измерений
• Список рисков
• План проекта
• План(ы) итерации
• Оценка(ки) итерации
• Оценка(ки) состояния

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

Цель 1: Фактические результаты и характеристики прослеживаются относительно программных планов.

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

Основные вехи RUP соответствуют концам стадий (Начало, Уточнение, Конструирование или Переход) и имеют хорошо определенные критерии завершенности. Возможности обзора существуют и в малых вехах в конце каждой итерации в пределах стадии. Эти вехи являются точками принятия решений и изучения опыта для будущих действий.

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

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

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

Цель 2: Изменения в программном обеспечении согласовываются с группой управления и с заинтересованными лицами.

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

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

Цель-1: Генеральный подрядчик выбирает квалифицированных субподрядчиков.

Цель 2: Генеральный подрядчик и субподрядчики договариваются о совместной работе.

Цель 3: Генеральный подрядчик и субподрядчик поддерживают продолжительные отношения.

Цель 4: Генеральный подрядчик отслеживает фактические результаты субподрядчика и эффективность выполнения его обязательств.

Эти цели находятся вне контекста действий RUP и зависят от организации.

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

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

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

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

Цель 1: Действия обеспечения качества ПО запланированы.

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

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

RUP содержит указания о том, кто должен делать обзор конкретных артефактов. Например, результаты "Объектного анализа", выполненного проектировщиком, должны быть рассмотрены независимым архитектором, проектировщиком, проектировщиком прецедента и рецензентом проекта. Учитывая определения RUP и критерии обзора артефакта, объективное лицо, заинтересованное в качестве продукта, должно иметь возможность легко оценить соответствие процессу и соответствие стандартам и рекомендациям по разработки.

Цель 2: Соответствие программных продуктов и действий применяемым стандартам, процедурам и требованиям объективно проверено.

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

Цель 3: Участвующие группы и лица информированы относительно действий и результатов обеспечения качества ПО.

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

• Продвижение (строки кода, число классов, функциональные точки в итерации)
• Стабильность (тип доработки, изменчивость требований или выполнения)
• Адаптируемость (затраты на доработку)
• Модульность (степень влияния доработки)
• Качество (быстрота обнаружения дефектов, компактность, глубина наследования)
• Завершенность (время тестирования на неисправность)
• Профиль затрат на ресурсы (запланированные относительно фактических)

Цель 4: Несогласованные проблемы, которые не могут быть разрешены в пределах программного проекта, разрешаются высшим руководством.

Это находится вне контекста действий RUP и зависит от организации. Однако, процесс управления изменениями, описанный в RUP, допускает механизм, посредством которого несогласованности могут быть документированы и представлены для разрешения.

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

Цель 1: Действия управления конфигурацией ПО запланированы.

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

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

• План управления конфигурацией, и
• План выполнения интеграции.

План управления конфигурацией, инициализируемый в стадии Начало, описывает следующее:

• Управление версиями и обработкой программного обеспечения;
• Сохранение моделей RUP и разделение их на конфигурационные элементы;
• Управление изменениями и выпусками с использованием метода управления изменениями

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

Цель 2: Выбранные для работы программные продукты идентифицированы, управляются и доступны.

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

Цель 3: Изменения в идентифицированных для работы программных продуктах управляются.

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

Цель 4: Участвующие группы и лица информированы относительно состояния и содержания базовых линий программного обеспечения.

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