Рубрики

Свежие записи

Методика по дисциплине «Управление конфигурацией и изменениями» Оглавление»

GD Star Rating
loading...
GD Star Rating
loading...




Данный материал представляет собой перевод Rational Unified Process в части описания дисциплины управления конфигурациями. Это, что называется версия 0.2, то есть переведенный оригинальный материал с дополнениями.

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

К слову сказать, данный материал НЕ привязан к средствам автоматизации конфигурационного управления, так что его смело можно брать за основу при описании процессов организации, так как чем автоматизирован процесс — ClearCase, Subversion, CVS, PVCS, MS TSF — не важно.

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

Оглавление. Часть 1.

Введение

Аббревиатуры и сокращения

УЗИ
УИ
УК
ОУК
ГКИ
ГРИ
РП
ИРП
РПР
ЗИ
СДП
БВ
УП
Релиз

Дисциплина «Управление конфигурацией и изменениями»

Перефразируя модель зрелости процессов Института программной инженерии (SEI CMM), можно сказать, что дисциплина Управление конфигурацией и изменениями контролирует изменения и обеспечивает взаимосвязь артефактов проекта.


Куб УК.

Дисциплина «Управление конфигурацией и изменениями» включает:

  • идентификацию объектов УК (ОУК);
  • ограничение возможности изменения ОУК;
  • аудит изменений, произведенных с ОУК;
  • определение конфигураций ОУК и управление этими конфигурациями.

Методы, процессы и инструментальные средства, используемые для поддержки дисциплины «Управление конфигурацией и изменениями» в организации, могут рассматриваться как Система УК организации.

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

Система УК — необходимая и неотъемлемая часть всего процесса разработки.

Цели

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

Одновременная модификация

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

Ограниченное уведомление

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

Многочисленные версии

Большинство крупных систем разрабатываются последовательными релизами. Один релиз может использоваться заказчиком, второй находится на тестировании, а третий — на стадии разработки. Если в одном из релизов обнаруживается ошибка, ее исправление должно быть внесено во все остальные релизы. Неточности могут привести к удорожанию исправлений и повторным работам, если изменения не контролируются и не отслеживаются должным образом.

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

Некоторые прямые выгоды системы УК:

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

Кроме того, система УК сохраняет детальную информацию по самому процессу разработки: кто создал конкретную версию (когда и почему), какая версия исходного кода использовалась при конкретной сборке продукта и другую подобную информацию.

Взаимодействие с другими дисциплинами

Система УК организации используется на протяжении всего жизненного цикла продукта — от фазы «Начало» до фазы «Передача». В качестве репозитория рабочих материалов организации, система УК содержит текущие и предшествующие версии исходных файлов и артефактов дисциплины «Требования», дисциплины «Анализ и проектирование» и дисциплины «Реализация», что определяет определенную версию системы или компонента системы.

Структура директорий продукта, представленная в системе УК, содержит все артефакты, требуемые для разработки продукта. Таким образом, дисциплина «Управление конфигурацией и изменениями» связанна со всеми другими дисциплинами и обеспечивает сохранение в репозитории всех артефактов, получаемых в результате выполнения этих процессов.

Процесс

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

На рисунке представлена диаграмма действий процесса УКИ.


Диаграмма действий процесса Управления конфигурациями

Первые две работы (Планирование проектной конфигурации и контроля изменений, и Создание проектной среды УК) выполняются в начале проекта. Остальные в течении жизненного цикла проекта.

Связь между работами, ролями, выполняемыми задачами и артефактами.

Работы

Роли

Задачи

Артефакты

Входящие

Исходящие

Планирование проектной конфигурации и контроля изменений

Менеджер конфигурации

Ввод в действие правил УК

План создания продукта

План УК

Прецедент разработки

План УК

Создание плана УК

План создания продукта

План УК

Прецедент разработки

Менеджер изменений

Ввод в действие процесса контроля изменений

План УК

План УК

План создания продукта

Прецедент разработки

Инфраструктура разработки

Создание среды проектного УК

Менеджер конфигурации

Развертывание среды УК

План УК

Репозиторий проекта

План создания продукта

Прецедент разработки

Инфраструктура разработки

Модель реализации

План итерации

Интегратор

Создание интеграционных рабочих пространств

Репозиторий проекта

Рабочее пространство

Прецедент разработки

Проектные руководства

Управление базовыми версиями и релизами

Менеджер конфигурации

Создание инсталляционного пакета

Список версий компонент релиза

Инсталляционный пакет

Сборка

Модель развертывания системы

План развертывания

Документация поддержки пользователя

Инсталляционные артефакты

Репозиторий проекта

Описание релиза

Учебные материалы

Интегратор

Создание базовых версий

Репозиторий проекта

Рабочее пространство

Проектные руководства

План разработки продукта

Поручение

Рабочее пространство

Продвижение базовых версий системы

Рабочее пространство

Рабочее пространство

Репозиторий проекта»

Репозиторий проекта

План разработки продукта

Рабочее пространство

Репозиторий проекта»

Проектные руководства

Изменения и передача объектов УК

Участник проекта

Создание рабочего пространства разработки

нет

Рабочее пространство

Внесение изменений

Поручение

Рабочее пространство

Рабочее пространство

Передача изменений

Рабочее пространство

Рабочее пространство

Репозиторий проекта

Обновление рабочего пространства

Репозиторий проекта

Рабочее пространство

Рабочее пространство

Интегратор

Создание базовых версий

см. выше

см. выше

Продвижение базовых версий

см. выше

см. выше

Мониторинг и отчетность по состоянию конфигурации

Менеджер конфигурации

Формирование отчета о состоянии конфигурации

План УК

Данные о состоянии проекта

Репозиторий проекта

Аудит конфигурации системы

План УК

Результаты аудита конфигурации

Репозиторий проекта

Управление запросами на изменение

Участник проекта

Внесение запроса на изменение

Нет

Запрос на изменение

Модификация запроса на изменение

Запрос на изменение

Запрос на изменение

Менеджер изменений

Рецензирование запроса на изменение

Запрос на изменение

Запрос на изменение

Подтверждение состояния Отклонено или Дубликат для запроса на изменение

Запрос на изменение

Запрос на изменение

Аналитик тестирования

Верификация изменений в собранном релизе

Запрос на изменение

Запрос на изменение

Сборка

Результаты тестирования

Журнал тестирования

Менеджер проекта

Распределение работ

см. дисциплину «Управление проектом»

см. дисциплину «Управление проектом»

Концепции

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

Концепция «Управление конфигурацией и запросами на изменение»

Данная концепция описывает границы и процессы управления конфигурацией и запросами на изменение.

Ниже перечислены главные аспекты системы УК:

  • управление запросами на изменение (УЗИ);
  • отчет о статусе конфигурации;
  • управление конфигурацией (УК);
  • отслеживание изменений;
  • выбор версии;
  • производство программного обеспечения.

На рисунке ниже отражены главные аспекты Системы УК.


Куб УК

Управление запросами на изменение (УЗИ)

Требует от инфраструктуры организации оценки стоимости и графика работ, связанных с изменениями, оценки влияния требуемого изменения на существующий продукт. Управление артефактами Запрос на изменение относится к работе ГРИ или ГКИ.

Учет конфигурационного статуса (результаты измерений)

Используется для описания «состояния» продукта, основанного на типе, числе, частоте и серьезности обнаруженных дефектов, и исправленных в процессе разработки продукта. Полученные метрики являются полезными в определении общего статуса законченности проекта.

Управление конфигурацией (УК)

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

Отслеживание изменений

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

Выбор версий

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

Выбор версии основывается на «конфигурационной идентификации».

Производство программного обеспечения

При производстве программного обеспечение необходима автоматизация этапов компиляции, тестирования и изготовления программного обеспечения для распространения.

RUP описывает всеобъемлющую Систему УК, которая охватывает все аспекты УК. Эффективным процессом УК может являться процесс, который:

  • встроен в процесс разработки программного обеспечения;
  • помогает управлять развитием продуктов по разработке программного обеспечения;
  • позволяет разработчикам выполнять задания УК с минимальным вовлечением в процесс разработки.

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

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

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

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

Концепция «Рабочее пространство»

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

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

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

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

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

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

РП может быть абсолютно закрытым для отдельного разработчика, или разделенным среди коллектива разработчиков по сети.

В дополнение к предоставлению доступа к исходным версиям, РП должно предоставлять изолированное хранилище для файлов созданных во время периода разработки:

  • рабочие (взятые из под контроля) версии файлов;
  • исполняемые файлы;
  • другие закрытые объекты рабочего пространства – код, директории с тестами, файлы с тестовыми данными.

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

На рисунке ниже представлен Куб УК с точки зрения концепции «Рабочее пространство».


Куб УК с точки зрения рабочих пространств.

Рабочие конфигурации

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

Представления

Представление обеспечивает доступ к набору файлов из репозитория проекта. Более того, просмотр предоставляет доступ к соответствующему набору версий этих файлов:

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

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

Существуют два типа представлений:

  • статическое представление;
  • динамическое представление.

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

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

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

Концепция «Интеграционные рабочие пространства (ИРП) и рабочие пространства разработки (РПР)»

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

  • РПР для каждого Исполнителя;
  • ИРП подсистемы для команды;
  • ИРП уровня системы для Интегратора.

РПР

Исполнитель разрабатывает подсистемы и их компоненты в личном рабочем пространстве. Однако для компиляции, линковки, запуска и тестирования кода одной подсистемы необходимы части остальных подсистем. Так как Исполнитель не нуждается в полном коде всей системы, то другие подсистемы физически не присутствуют в его личном РП. Поэтому внутренние релизы всех подсистем находятся в общем репозитории. В случае необходимости Исполнитель указывает в отдельном файле типа «makefile» путь к данным подсистемам.


РПР

ИРП для команды

Иногда подсистему разрабатывает команда Исполнителей. В данном случае Исполнители должны провести интеграцию своих элементов в подсистему перед интеграцией полной системы. Такие интеграции производятся в ИРП для команды. В данном случае роль Интегратора выполняет один из членов команды.

ИРП уровня системы для Интеграторов

Интеграторы системы могут добавлять в ИРП элементы системы или подсистемы инкрементально.


ИРП уровня системы, в котором подсистемы добавлялись инкрементально

Концепция «Управление запросами на изменение»

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

Запрос на изменение

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

Группа контроля изменений

Группа контроля изменений (ГКИ) – коллектив, который наблюдает за процессом изменений и состоит из представителей всех заинтересованных групп, включая заказчиков, разработчиков и пользователей. В небольшом проекте эту роль может играть один член коллектива, как, например, Менеджер проекта или Архитектор системы. В RUP эта роль называется Менеджер изменений.

Совещание ГКИ

Совещание ГКИ по пересмотру – смысл этого совещания заключается в просмотре зарегестрированных
ЗИ. На совещании определяется обоснованность ЗИ. В случае если запрос обоснован, производится определение принадлежности изменения к текущей или другой версии. Определение основывается на приоритете, графике, ресурсах, уровне усилий, риске, серьезности и любого другого критерия определенного коллективом. Обычно такое совещание происходит раз в неделю. Если объем ЗИ существенно увеличивается, или приближается выпуск версии, совещания могут происходить ежедневно. Обычно во время Совещаний ГКИ обязательными его членами являются Менеджер тестирования, Менеджер разработки и представитель маркетингового отдела. Остальные участники приглашаются на встречу по мере необходимости.

Форма регистрации запроса на изменение

Эта форма появляется, ЗИ впервые регистрируется. На форме отображаются только те поля, которые необходимо заполнить регистратору запроса.

Объединенная форма регистрации запроса на изменение

Эта форма отображается, когда ЗИ, который уже был зарегистрирован, пересматривается. Она содержит все необходимые для описания ЗИ поля.

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

Пример диаграммы действий для ЗИ.


Пример диаграммы действий для ЗИ

Описание действий:

Действие

Описание

Ответственность

Регистрация ЗИ

Любое заинтересованное в разработке проекта лицо может зарегистрировать ЗИ. ЗИ регистрируется в системе отслеживания ЗИ (например, Rational ClearQuest) и помещается в очередь просмотра ГКИ, путем установки состояния запроса на изменение как Зарегистрированный.

Регистратор

Пересмотр ЗИ

Цель этой деятельности заключается в пересмотре представленных ЗИ. Начальный пересмотр содержимого ЗИ осуществляется на Совещании ГКИ для определения обоснованности запроса. В случае если запрос обоснован, производится определение принадлежности изменения к области текущей версии. Определение основывается на приоритете, графике, ресурсах, уровне усилий, риске, серьезности и любого другого критерия определенного группой.

ГКИ

Подтверждение дублирования или отклонение.

Если подозревается, что ЗИ является дубликатом или отклоняется как неправильный запрос (например, ошибка оператора, невоспроизводимость, того, как он работает и т.п.), то назначается член ГКИ для подтверждения Дублирования запроса или его отклонения и для сбора информации при регистрации, если это требуется.

Член ГКИ

Обновление ЗИ

Если требуется дополнительная информация для оценки ЗИ, или если ЗИ отклоняется на любом этапе процесса (например, как дубликат, отклоненный, и т.п.), уведомляется регистратор, который может обновить ЗИ новой информацией. Обновленный ЗИ перерегистрируется в очередь просмотра ГКИ для рассмотрения новых данных.

Регистратор

Назначение и планирование работ

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

Менеджер проекта

Выполнение изменений

Назначенный работник выполняет ряд работ, определенных внутри соответствующего этапа разработки ПО (например, этапа определения требований, анализа и проектирования, реализации, производства документации пользователя, проектирования теста и т.п.) запрошенных изменений. Эти работы включают весь обычный спектр работ и тестирование компонент в соответствии с методологией разработки ПО. После этого ЗИ помечается как разрешенный.

Назначенный член команды разработчиков

Проверка изменений в тестовой сборке

После выполнения изменений выбранным работником из коллектива разработчиков (Системным
аналитиком, Исполнителем, Тестировщиком, Техническим писателем и т.п.) изменения помещаются в очередь на тестирование, что бы быть назначенными Тестировщику и проверенными при отладочной сборке продукта.

Тестировщик

Проверка изменений в релизной сборке

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

Член ГКИ (Интегратор системы)

Пример диаграммы состояний для ЗИ

Следующая диаграмма отображает пример состояний и тех лиц, которые должны быть оповещены на протяжении жизненного цикла ЗИ.


Диаграмма состояний PB

Описание состояний ЗИ:

Состояние

Определение

Управление доступом

Зарегистрирован

Это состояние появляется как результат следующей деятельности:

  • регистрации нового ЗИ;
  • обновления существующего ЗИ;
  • рассмотрения отложенного ЗИ для новой версии.

ЗИ помещается в очередь просмотра ГКИ. В результате этого действия запросу не назначается владелец.

Все пользователи

Отложен

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

Администратор ГКИ

Менеджер проекта

Дублирован

В этот состоянии ЗИ считается повторением другого ЗИ, который уже был зарегистрирован. ЗИ могут быть переведены в это состояние администратором ГКИ или членом коллектива, назначенным для его разрешения. Когда ЗИ переводится в состояние дублирован, лицо сформировавшее этот запрос будет запомнено ( в таблице Attachments в ClearQuest). Регистратор с самого начала должен запросить базу данных ЗИ на наличие дублированных запросов, прежде чем регистрировать ЗИ. Это существенно сократит время при работе с ЗИ. Регистраторы, которые регистрирую Дублирующие
ЗИ, должны быть занесены в лист извещений первоначального ЗИ для будущего их уведомления относительно резолюций.

Администратор ГКИ

Менеджер проекта

QE Manager

Разработчики

Отклонен

ЗИ в этом состоянии определяется на совещании ГКИ или назначенным лицом на предмет: запрос обоснован или требуется более детальная информация от регистратора. Если ЗИ уже открыт, то он удаляется из очереди запросов с резолюциями и в дальнейшем снова будет пересмотрен.

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

Администратор ГКИ

Менеджер проекта

Менеджер разработки

Менеджер тестирования

Дополнительная информация

Существует недостаточно данных для подтверждения обоснованности отклонения или дублирования ЗИ.

Владелец автоматически изменяется на регистратора, которому поручается предоставить дополнительные данные.

Администратор ГКИ

Открыт

В этом состоянии ЗИ относится к текущей версии и ждет своего разрешения. ЗИ заносится в список резолюций. ЗИ определяется как назначенный в очередь. Члены совещания – единственные кто может открыть ЗИ в очереди резолюций. Если обнаружены более приоритетные ЗИ, об этом немедленно следует извести руководителя QE или разработки. В этом случае они могут решить собраться на экстренную встречу ГКИ или немедленно открыть ЗИ в очереди резолюций.

Администратор ГКИ

Менеджер проекта

Менеджер разработки

QE Department

Назначен

За Открытий
ЗИ отвечает Менеджер проекта. Он назначает работников в соответствие с типом запроса и изменяет график работ и прочее.

Менеджер проекта

Разрешен

Означает, что разрешение этого ЗИ завершено и сейчас ЗИ готов для проверки. Если регистратор был членом отдела QE, то владелец автоматически изменяется на члена QE зарегистрировавшего ЗИ; иначе владелец меняется на Руководителя QE для переназначения.

Администратор ГКИ

Менеджер проекта

Менеджер разработки

QE Manager

Отдел разработчиков

Не прошел тестирование

В данное состояние переводится ЗИ не прошедший тест или в отладочной сборке или в сборке версии. Владелец ЗИ автоматически изменяется на члена коллектива, который разрешил ЗИ.

Администратор ГКИ

QE Department

Проверен

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

Администратор ГКИ

QE Department

Закрыт

ЗИ больше не принимается во внимание. Это заключительное состояние, в которое может перейти ЗИ. Только Администратор ГКИ имеет право закрыть ЗИ. Когда ЗИ
Закрыт, регистратор получит уведомление по электронной почте с окончательным состоянием ЗИ. ЗИ Закрывают в следующих случаях:

  • после того, как проверенное разрешение утверждается при сборке версии;
  • в случае Отклонения
    ЗИ;
  • в случае когда ЗИ рассматривается как Дубликат уже существующего ЗИ.

В письме регистратор уведомляется о Дубликате
ЗИ и добавляется к этому ЗИ для будущих уведомлений (см. определения состояний Отклонение и Дублирован). Если регистратор желает оспорить закрытие ЗИ, ЗИ должен быть обновлен и перерегистрирован ГКИ.

Администратор ГКИ

Имена состояний используются для сбора информации для статистических отчетов.


Куб УК в контексте ЗИ.

Концепция «Unified change management»

Unified change management (UCM) –метод Rational Software для управления изменениями в системе разработки ПО, от требований к релизу. UCM охватывает жизненный цикл разработки, определяя как управлять ЗИ, проектировать модели, документацию, компоненты, тестовые примеры и исходный код.

Одним из основных аспектов модели UCM является то, что она унифицирует деятельности, используемые для планирования и просмотра состояния проекта и артефактов, подверженных изменению. Модель UCM реализована через процесс и инструментарий. Продукты Rational ClearCase и Rational ClearQuest являются основной технологической поддержкой UCM. ClearCase управляет всеми артефактами создаваемыми в проекте по разработке ПО, включая как системные артефакты, и артефакты проекта. ClearQuest управляет заданиями проекта, дефектами и требованиями для расширений (в основном относящихся к деятельностям) и предоставляет средства по созданию отчетов и диаграмм, необходимых для отслеживания состояния проекта.

Концепция «Отчет по статусу конфигурации»

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

Учет конфигурационного статуса (Configuration Status Accounting) – используется для описания «состояния» продукта основанного на типе, числе, частоте появления и серьезности найденных и зафиксированных ошибок во время разработки продукта. Полученные метрики являются полезными при определении состояния завершенности проекта.

Существует четыре принципиальных источника для отчетов по конфигурационному статусу ПО:

  • ЗИ;
  • Сборки;
  • Описания версий;
  • аудиты.

Отчеты по ЗИ

Имена состояний являются базой для отчета по статистике ЗИ (старение, распределение или тенденция) как описано на соответствующих этапах процесса управления запросами на изменение.

Отчеты, основанные на ЗИ, могут быть разнесены по следующим категориям:

Старение (Отчеты по времени)

Как долго различные ЗИ были открыты? Какова задержка между нахождением дефектов в версии и их исправлением?

Распределение запросов по категориям (Численные отчеты)

Число запросов в категориях: по владельцу, приоритету, состоянию исправлены?

Тренд (Отчеты по времени и количеству)

Каково общее число дефектов найденных и исправленных за все время? Какова частота обнаружения и исправления дефектов? Каков «качественный промежуток» в терминах обнаруженных дефектов против исправленных? Каково среднее время исправления дефекта?


Куб УК в разрезе отчетов по ЗИ

Отчеты по Сборкам

Отчеты по Сборкам включают список всех файлов, их местоположение, включенные в сборку изменения для конкретной версии ПО.

Отчеты по Сборкам могут поддерживаться как на системном так и на уровне подсистемы.

Отчеты по Описанию версий

Описания версии – артефакт определяющий детали версии ПО. Как минимум в это описание должно быть включено следующее:

  • носитель версии (физический носитель, документы);
  • носитель содержимого по (листинги файлов);
  • все уникальные данные;
  • инструкции по инсталляции;
  • возможные проблемы и известные ошибки.

Аудиты

Существует два вида ревизий применяемых в УК:

  • аудит физической конфигурации;
  • аудит функциональной конфигурации.

Ревизия физической конфигурации определяет составляющие продукта развернутого в репозитории проекта.

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

Детально деятельность по выполнению ревизий описана в параграфе 6.14.

Концепция «Структура директорий продукта»

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

На рисунке ниже показано, что Система «Х» состоит из «N» подсистем. Каждая подсистема, в свою очередь, состоит из «N» компонентов. СДП предоставляет общее хранилище для различных артефактов, которые необходимы для разработки каждой части всей системы.


Структура системы

В RUP артефакты сгруппированы и описаны в терминах дисциплин:

  • дисциплина Бизнес моделирование;
  • дисциплина Требования;
  • дисциплина Анализ и проектирование;
  • дисциплина Реализация;
  • дисциплина Тестирование;
  • дисциплина Внедрение;
  • дисциплина Управление конфигурацией и изменениями;
  • дисциплина Управление
    проектом;
  • дисциплина Среда.

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

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

СДП уровня системы

Хотя опытный проектировщик ПО имеет представление относительно структуры системы, основные компоненты ее появляются как результат деятельности в дисциплине Анализ и проектирование, которые затем уточняются.

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

System Requirements

Системные требования.

Models

Модели

Use-Case Model

Модель прецедентов

Use-Case Package

Пакет прецедентов

User Interface Prototype

Прототип пользовательского интерфейса

Database

База Данных.

Requirements Attributes

Атрибуты требований

Documents

Документы

Vision

Концепция

Glossary

Глоссарий

Stakeholder Requests

Запросы заинтересованных лиц

Supplementary Specifications

Дополнительные спецификации

Software Requirement Specs

Спецификации программных требований

Reports

Отчеты

Use-Case Model Survey

Обзор модели прецедентов

Use-Case Report

Отчет по прецедентам

System Design and Implementation

Системное проектирование и реализация

Models

Модели

Analysis Model

Модель стадии анализа

Use-Case Realization

Реализация прецедентов

Design Model

Модель стадии проектирования

Design Subsystem

Проектирование подсистемы

Interface

Интерфейс

Test Package

Пакет тестов

Data Model

Модель Данных

Workload Analysis Document

Документ: Анализ Рабочей загрузки

Documents

Документы

Software Architecture Document

Документ: Архитектура программного обеспечения

Design Model Survey

Обзор модели стадии проектирования

Subsystem-1

Подсистема-1

Subsystem Directory Structure

Структура директории подсистемы 1

Subsystem-N

Подсистема-N

Subsystem Directory Structure

Структура подсистемы N

System Integration

Системная интеграция

Plans

Планы

Integration Build Plan

План интеграции

Libraries

Библиотеки

System Test

Системный тест

Test Plan

План тестирования

Test Cases

Примеры Тестов

Test Procedures

Тестовые Процедуры

Test Data

Данные Теста

Test Results

Результаты Теста

System Deployment

Внедрение Системы

Deployment Plan

План внедрения

Documents

Документация

Release Notes

Примечания к версии

Manuals

Руководство пользователя

End User Support Material

Материал для конечного пользователя

Training Materials

Обучающие материалы

Installation Artifacts

Инсталляционные данные

System Management

Управление Системой

Plans

Планы

Software Development Plan

План разработки ПО

Iteration Plan

План Итераций

Requirements Management Plan

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

Risk List

Лист рисков

Risk Management Plan

План управления рисками

Development Case

Условия разработки

Infrastructure Plan

План инфраструктуры

Product Acceptance Plan

План принятия продукта

Configuration Management Plan

План управления конфигурацией

Documentation Plan

План документации

QA Plan

QA план

Problem Resolution Plan

План разрешения проблем

Subcontractor Management Plan

План управления подрядчиками

Process Improvement Plan

План усовершенствования процессом разработки

Measurement Plan

План измерений

Assessments

Оценки

Iteration Assessment

Оценка итераций

Development Organization Assessment

Оценка организации разработки

Status Assessment

Оценка Статуса

Tools

Инструментарий

Development

Environment Tools

Инструментарий разработки среды

Editors

Редакторы

Compilers

Компиляторы

Configuration Management Tools

Инструментарий управления конфигурацией

Rational ClearCase

Средство УК

Requirements Management Tools

Инструментарий управления требованиями

Rational RequisitePro

Visual Modeling Tools

Инструментарий визуального моделирования

Rational Rose

Средство моделирования

Test Tools

Инструментарий тестирования

Rational Test Factory

Средство тестирования

Defect Tracking

Отслеживание дефектов

Rational ClearQuest

Средство управления артефактами «Запрос на изменение»

Standards & Guidelines

Стандарты и рекомендации

Requirements

Требования

Requirements Attributes

Атрибуты требований

Use-Case Modeling Guidelines

Рекомендации по моделированию функций

User Interface

Пользовательский интерфейс

Design

Проектирование

Design Guidelines

Рекомендации по проектированию

Implementation

Реализация

Programming Guidelines

Рекомендации по реализации

Documentation

Документация

Manual Style guide

Руководство

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

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

СДП уровня подсистем

Информация в СДП уровня подсистемы относится непосредственно к разработке определенной подсистемы. Количество «реализаций» СДП уровня подсистемы напрямую связано с количеством подсистем полученных в результате работ в дисциплине Анализ и проектирование.

Обобщенный вид СДП уровня подсистемы имеет следующий вид:

Subsystem-N Requirements

Требования к Системе-N

Models

Модели

Use-Case Model

Функциональная модель

Use-Case Package

Пакет функций

Use-Case Storyboard

Функции пользовательского интерфейса

Use-Case (text)

Текст функций

User Interface Prototype

Прототип Пользовательского Интерфейса

Database

База данных

Requirements Attributes

Атрибуты Требований

Documents

Документация

Vision

Перспективы развития

Glossary

Глоссарий

Stakeholder Requests

Запросы заинтересованных лиц

Supplementary Specifications

Дополнительные Спецификации

Software Requirement Specs

Спецификации на Требования к ПО

Reports

Отчеты

Use-Case Model Survey

Обзор Функциональной модели

Use-Case Report

Отчет по функциям системы

Subsystem-N Design and Implementation

Проектирование и реализация Подсистемы-N

Models

Модели

Analysis Model

Модель стадии анализа

Use Case Realization

Реализация функций

Subsystem Design Model

Модель стадии проектирования

Design Packages

Пакеты модели проектирования

Interface Packages

Интерфейсные Пакеты

Test Packages

Пакеты тестов

Implementation Model

Модель этапа Реализации

Data Model

Модель Данных

Workload Model

Рабочая Модель

Documents

Документация

Software Architecture Document

Документ: Архитектуры ПО

Workload Model

Рабочая Модель

Reports

Отчеты

Use-Case Realization Report

Отчет о Реализации функций

Component-1

Компонент-1

Component-1 Directory

Директория Компонента-1

Component-N

Компонент-N

Component-N Directory

Директория Компонента-N

Subsystem-N Integration

Интеграция Подсистемы-N

Plans

Планы

Subsystem Integration Build Plan

План интегрирования подсистемы

Libraries

Библиотеки

Subsystem-N Test

Отладка Подсистемы-N

Test Plan

План Тестирования

Test Cases

Примеры тестов

Test Procedures

Тестовые Процедуры

Test Results

Результаты Тестирования

Test Data

Данные Тестирования

СДП уровня компонента

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

Component

Компонент

Source Code

Исходный Код

Object/Executable Code

Объектный/Исполняемый Код

Interfaces

Интерфейсы

Test Code

Отладочный Код

Executable Test Scripts

Исполняемые отладочные скрипты

Test Data

Тестовые Данные

Test Results

Результаты тестов

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

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

Концепция «Метод продвижения»

Метод продвижения определяет как информация о продукте связанна с уровнем продвижения, а также устанавливает набор разрешений для доступа и утверждения.

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

  • протестированная интеграция;
  • протестированная система;
  • протестированное принятие;
  • производство.

Уровни определены для отражения прогресса от низшего до высшего качества. Действие изменения уровня продвижения базовой версии называют продвижением или понижением базовой версии.

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

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

Концепция «Определение базовых версий»

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

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

Существует три главных причины для создания базовой версии, это: воспроизводимость, трассируемость и отчет.

Воспроизводимость

Возможность вернуться во времени и воспроизвести данную версию системы ПО или воспроизвести предшествующую среду разработки.

Трассируемость

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

Отчет

Основан на сравнении содержимого одной baseline с другой. Сравнение базовых версий помогает в отладке и генерации описаний версии.

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

Существует несколько преимуществ при создании базовых версий:

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

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

Базовую версию следует делать в конце каждой итерации (вспомогательная веха) и в конце каждой фазы жизненного цикла проекта.

  • Lifecycle Objectives Milestone (фаза Начало) – веха после начальной фазы или контрольная точка целей жизненного цикла;
  • Lifecycle Architecture Milestone (фаза Развитие) – веха после фазы уточнения требований или контрольная точка архитектуры жизненного цикла;
  • Initial Operational Capability Milestone (фаза Конструирование) — фаза после фазы детального проектирования или контрольная точка начальных функций;
  • Product Release Milestone (фаза Передача) — веха после фазы внедрения или контрольная точка версии продукта;

Роли

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

Роль обычно выполняет один работник, или группа людей работающая как команда. Член проектной команды обычно выполняет несколько ролей. Учтите что Роль это не человек и не всегда соответствует должностям, Роли описывают сколько работников требуется в проекте и ответственности этих работников. Назначение ролей производится Менеджером проекта при планировании работ.

В то время как многие роли выполняются внутри организации, люди вне организации играют важную роль Заинтересованное лицо продукта или проекта.

Роль «Менеджер конфигурации»

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

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


Задачи и артефакты

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

Несколько примеров, как назначать на данную роль:

  • назначение одного сотрудника на две роли Менеджер конфигурации и Интегратор подходит для маленьких и средних проектов.
  • назначение одного сотрудника на две роли Менеджер конфигурации и Менеджер развертывания. Данная стратегия подходит для маленьких и средних проектов, в которых дисциплина Развертывание слабо формализована.

Роль «Менеджер контроля изменений»

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

Менеджер контроля изменений также занимается определением процесса УЗИ, который формализован в План УК.

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


Задачи и артефакты

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

Роль «Интегратор»

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

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


Задачи и артефакты

От сотрудника выполняющего эту роль требуется:

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

Интегратор должен обладать хорошими координационными способностями, для работы с несколькими разработчиками.

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

Роль «Участник проекта»

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

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


Задачи и артефакты

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

Роль Участник проекта выполняется всеми членами проектной команды. Поэтому назначение данной роли происходит по умолчанию.

Описание дисциплины «Управление конфигурацией и изменениями». Часть 1: Концепции и Роли, 10.0 out of 10 based on 3 ratings

Связные и просто интересные записи:

Метки:change, clearcase, clearquest, CM, configuration, defect, ibm, ieee, it, management, microsoft, ms, process, project, rational, req, request, rose, rup, soda, software, sql, state, tools, unified, атрибут, версии, взаимодействие, видео, внедрение, времени, заказчик, изменение, изменениями, инструмент, инструменты, клиент, код, коммуникации, конфигурации, конфигурациями, метрики, небо, обсуждение, оператор, план, планирование, ПО, подряд, подход, поле, проект, процесс, регламент, система, сложность, состояние, специалист, стандарт, субподряд, требования, труд, УК, управление, фактор

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free