Rational Unified Process - как достичь 3-го уровня CMM - Программные продукты

Леонид Новиков

Характеристики 3-го уровня, "Определенный"
KPA 3-го уровня
3-й уровень и Rational Unified Process
Определение процесса в организации
Программа обучения
Интегральное управление разработкой ПО
Проектирование программного продукта
Межгрупповая координация
Экспертная оценка
Заключение

Мы продолжаем знакомиться с возможностями Rational Unified Process (RUP) , которые могут помочь Вам достичь 2-го и 3-го уровней зрелости CMM.

В предыдущей статье Вам был предложен краткий обзор CMM и описаны возможности RUP, обеспечивающие достижение 2-го уровня CMM. В этой статье говорится о возможности достижения 3-го уровня.

Характеристики 3-го уровня, "Определенный"

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

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

В CMM этот приспособленный процесс называется проектно определенным процессом разработки ПО.

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

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

KPA 3-го уровня:

Фокусирование организации на процессе
Определение процесса в организации
Программа обучения
Интегральное управление разработкой ПО
Проектирование программного продукта
Межгрупповая координация
Экспертная оценка

3-й уровень и Rational Unified Process

Фокусирование организации на процессе

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

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

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

Цель 2: Сильные и слабые стороны процесса разработки ПО идентифицированы относительно стандарта процесса.

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

Бизнес контекст (контрактный, коммерческий или внутренний)
Объем работ по разработке ПО
Степень новизны
Тип приложения

Цель 3: Развитие процесса уровня организации и действия уточнения запланированы.

Этот цель 3-го уровня полностью зависит от внедряющей организации.

Определение процесса в организации

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

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

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

Цель 2: Информация, связанная с использованием стандартного процесса проектов разработки ПО в организации собрана, рассмотрена и сделана доступной для всех проектов.

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

Рисунок ниже иллюстрирует некоторую рекомендуемую RUP инфраструктуру определения процесса в организации.

Рисунок 2. Общий и проектно определенные процессы и средства их поддержки (среда) в организации

Программа обучения

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

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

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

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

Краткий обзор Rational Unified Process и его модулей Требования, Анализ и проектирование, Выполнение, Испытания, Архитектура, Конфигурирование процесса, Управление, Инструментальные средства и Введение в объектную ориентацию
Требования с прецедентами
Управление объектно-ориентированным проектом (OOPM)
Объектно-ориентированный анализ и проектирование (OOAD)
Качество автоматизации программного обеспечения
Конфигурационное управление
Архитектура программного обеспечения и итерационный процесс

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

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

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

Интегральное управление разработкой ПО

Цель интегрального управления разработкой ПО состоит в том, чтобы интегрировать действия непосредственной разработки и управления в согласованный, определенный процесс, который приспособлен из стандартного процесса разработки ПО организации и связывает средства процесса, которые описаны в KPA "Определение процесса в организации". Это приспосабливание базируется на бизнес среде и технических потребностях проекта, как описано в KPA "Проектирование программного продукта". Интегральное управление разработкой ПО развивается из KPA "Планирование проекта ПО" и KPA "Отслеживание и надзор за программным проектом", определенных на 2-ом уровне.

Цель 1: Проектно определенный процесс разработки ПО - это приспособленная версия стандартного процесса в организации.

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

Цель 2: Проект запланирован и управляется согласно проектно определенному процессу.

Эта цель должна быть разрешена организацией, которая внедряет RUP.

Проектирование программного продукта

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

Цель 1: Задачи проектирования определены, интегрированы и последовательно выполняются для производства ПО.

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

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

Трассируемость между техническими моделями (моделью прецедентов, проектной моделью, исходным кодом и выполнимыми компонентами) поддерживается средой.

Межгрупповая координация

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

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

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

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

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

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

Экспертная оценка

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

Цель 1: Действия обзора программ запланированы.

Как описано в целях KPA "Обеспечение качества" для 2-го уровня, каждое действие в пределах RUP имеет отдельное действие обзора.

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

Цель 2: Дефекты в продуктах работы идентифицированы и удалены.

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

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

Заключение

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

За рамками этой статьи осталась проблема внедрения в организации процесса разработки ПО, базирующегося на RUP. Лучшим источником знаний по этой теме является, безусловно, сам Rational Unified Process. Русскоязычным читателям можно порекомендовать уже упоминавшийся цикл статей "Введение в Rational Unified Process" , в частности - выпуск 14 и несколько последующих, которые, я надеюсь, будут закончены и опубликованы на сайте Interface Ltd в ближайшем будущем.

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

Ссылки по теме

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

Оглавление