(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

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

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

Оглавление

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

Значит, Вы должны гарантировать высокое качество своего программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого временного графика и бюджета. Многие компании вкладывают деньги в улучшение своего процесса разработки и получают хорошую отдачу. В статье "Современные модели качества программного обеспечения" авторы, со ссылкой на западные источники, приводят следующие цифры: средний уровень возврата вложений в улучшение процесса составляет от 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 используются те же русскоязычные термины, которые автор использует в цикле статей "Введение в Rational Unified Process". Кстати, читатели, не имеющие у себя RUP или испытывающие затруднения при чтении английских текстов, могут воспользоваться этим циклом для более подробного знакомства с концепциями RUP.

Краткий обзор CMM

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

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

CMM имеет пять уровней зрелости организации от 1-го до 5-го (см. рис. 1).

Рисунок 1. Пять уровней зрелости процесса в организации, определяемых CMM SEI

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

Характеристики 2-го уровня, "Повторяемый"

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

Проекты в организации 2-го уровня устанавливают базовые средства управления процессом разработки. Реальные возможности проекта основываются на результатах, полученных в предыдущих проектах и на требованиях данного проекта. Руководители разработки проекта намечают затраты на разработку, графики и функциональные возможности; идентифицируют возникающие проблемы. Требования к программному обеспечению и результирующий продукт разрабатываются так, чтобы удовлетворять их основам и контролировать их целостность. Стандарты разработки определены, и организация гарантирует следование им. Спланированы работы с субподрядчиками, если они есть, установлены отношения с основным заказчиком и поставщиками.

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

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

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

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

Управление требованиями

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

Одна из главных особенностей RUP состоит в том, что он управляется прецедентами. Прецеденты обеспечивают систематический подход к выявлению, организации и связыванию требований пользователей. Они обеспечивают способ документирования функциональных требований, служащих базой для разработки проекта, его тестирования и итеративного планирования. В 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. Изменения проекта и выполнения, которые имеют меньший контекст, рассматриваются на соответствующем уровне технических полномочий. Утверждения, уровни управлений и пути, которыми они связываются, описаны в Плане управления конфигурацией и в Плане разработки программного обеспечения.

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


 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 23.10.2001 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
IBM Rational Functional Tester Floating User License
IBM RATIONAL Clearcase Floating User License + Sw Subscription & Support 12 Months
IBM RATIONAL Clearcase Floating User From Rational Clearcase Lt Floating User Trade Up License + Sw Subscription & Support 12 Months
Rational ClearCase Multisite Floating User License
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Один день системного администратора
Мастерская программиста
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Помощь по MS Access (332)
Доброе время суток. Случайно оказался на этом сайте, искал статьи по OLAP. Вижу, что...
 
Как выбрать матрас (3)
Подскажите как правильно выбрать матрас и на что в целом следует обратить внимание на ваш...
 
Беговая дорожка (1)
Купила беговую дорожку вот здесь https://4gym.com.ua/product/technogym-artis-run Очень классная,...
 
Отличается ли ДрифтКазино от беттинга? (12)
Друзья, давно заметил, что на Дрифте уже несколько месяцев во всю рекламируется и предлагается...
 
Как подключить файлы ost в отлуке (3)
Проблема в следующем . База почты (входящие, исходящие, удаленные, отправленные) и адресная...
 
 
 



    
rambler's top100 Rambler's Top100