СМ-Консалт
 

Управление изменениями в IBM Rational - Часть 2: Усовершенствование решений по управлению изменениями в IBM Rational

Статьи Управление конфигурациями и изменениями (ALM)

иллюстрация Эта статья в двух частях иллюстрирует передовой опыт в управлении изменениями, использующийся командой разработчиков IBM Rational ClearQuest® и предлагает концептуальный пример общего процесса разработки для управления изменениями.

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

От редактора: нумерация в этой статье, второй части серии, продолжает нумерацию первой части, вышедшей в ноябрьском выпуске Rational Edge за 2007 г.

Усовершенствования процесса разработки

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

Для схемы RATLC было необходимо решение, которое помогало бы соединить приложение для поддержки заказчиков с решением по управлению изменениями в группе разработчиков. Оно получило известность как RETAIN RATLC Bridge и было описано в части 1.

Наша система управления изменениями (CM-система) в IBM Rational качественная, но все же не совершенная. Например, если запрос на изменение (change request — CR), получил оценку, если он задан, разработан и затем разрешен, закрытие CR автоматически запускает обновленную информацию в приложении RETAIN Call Center, чтобы как Отдел поддержки, так и заказчики могли видеть состояния решения. Но мы бы хотели сделать еще больше. Например, если нет способа проследить отношения между продуктом или проектом, идентифицированным заказчиком, когда проблема выявлена в совместно используемом компоненте, может возникнуть замешательство по поводу того, когда и где зафиксированы проблемы, о которых сообщали заказчики. Вот пример того, что имеется в виду:

  • Заказчик обращается в Отдел поддержки с информацией об инсталлированном ПО IBM Rational Installed Product Release, в котором была обнаружена проблема.
  • Проблема определена как дефект программного обеспечения, и Отдел поддержки создает Запрос об изменении в RATLC, который генерирует Authorized Program Analysis Report (APAR) (аналитический отчет по авторизованной программе).
  • Разработчики пытаются выявить, в чем проблема, и определить, где ее исправить.
  • Можно установить закрытый код RETAIN Call Center APAR для информирования пользователя о том, что его проблемой займутся при подготовке новой версии ПО. Однако невозможно проследить, когда этот выпуск продукта станет доступным заказчику.

Один из способов решить подобную проблему — установить метод для определения и автоматизации соотнесения местонахождения проблемы, и тем, когда и где заказчик может получить решение этой проблемы. Эта могло бы быть осуществлено отображением поля версии RETAIN Call Center в поле RATLC для версии продукта или описанного проекта.

Учет данных обстоятельств является основой для дальнейшего совершенствования схемы RATLC и общей системы управления изменениями ClearQuest организации разработки IBM Rational. Этой работой занимается команда IBM Rational Internal Deployment. Некоторые идеи усовершенствования, выдвинутые командой, связаны с тем, что мы называем общим процессом разработки (common workflow), о котором я сейчас расскажу.

Проектирование общего процесса разработки

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

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

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

Цели общего процесса разработки для IBM Rational

Модель схемы совместной программной разработки в ClearQuest начинается с концептуальной карты состояний и действий; структурных типов, полей и характера изменений, и с того, как все описанные объекты работают для пользователей базы данных ClearQuest. Роли Schema Developer (разработчика схемы) и Administrator (администратора) охватывают все варианты использования (use cases), связанные с разработкой всей модели, исполнением и развертыванием задач, необходимых для поддержки системы управления изменениями.

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

  • Заказчикам — сообщать о проблемах, связанных с продуктами, которые они устанавливают.
  • Разработчикам — выполнять действия по устранению проблем в компонентах, которые не видны заказчикам, например, в совместно используемых компонентах.
  • Формировать уведомления о том, когда и где исправленное программное обеспечение станет доступно заказчикам.
  • Специалистам IBM Rational — вести учет случаев, когда проблемы, имевшиеся у заказчика, можно решить при использовании обновленной версии того ПО, в котором они обнаружили проблему.

Дополнительные задачи:

  • Обеспечение согласованности процесса во всей организации
  • Поддержка компонентного представления работы
  • Обеспечение целостности и достоверности отчетов о показателях
  • Устранение проблем с определением приоритетов и сокращение времени на репликацию (см. также ниже)
  • Улучшение производительности приложения
  • Обеспечение управления на основе артефактов или действий (activity)
  • Идентификация и использование модели процессов на основе ролей
  • Поддержка интегрированных компонентов или каналов передачи данных в другие системы

Роли в совместной программной разработке

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

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

  • Публикатор (Submitter) (TSE, Dev/QE/Doc/Mgrs)
    Им может быть любой — например, любой из инженеров Отдела поддержки (Support engineer) (TSE), разработчик (Developer) (Dev), контролер ОТК (Quality engineer) (QE), составитель документации (technical writer — Doc) или менеджер (Mgr). Публикатор может:
    • Публиковать проблемы
    • Проверять статус проблемы
  • Проектировщики или менеджеры проекта (Eng/Proj Mgrs)
    Эти роли могут сортировать проблемы и идентифицировать цели нового релиза. Например:
    • Проверять статус проблем и объявлять их решенными, где это удостоверено
    • Проверять, сбалансирована ли должным образом рабочая нагрузка для разработчиков
    • Писать отчеты (характеристики проблем, найти/закрыть, входящие, статус версии и т.д.)
  • Эксперты (Doc Assess/Dev/QE)
    Эти роли будут:
    • Находить проблемы в порученной им области
    • Работать над разрешением проблем
  • Менеджеры Отдела поддержки
    Эти роли будут:
    • Писать отчеты (характеристики проблем, найти/ закрыть, входящие, статус проблем)
    • Проверять состояние проблемы и статус версии

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

В совместном процессе разработки изменение может быть представлено как Проблема (Issue). Запросы на изменение могут быть внутренними или внешними; то есть представлены на основании запросов заказчика, хода внутренней разработки, результатов тестов или административных решений.

Структурные типы (record types) в совместном процессе разработки

Рисунок 3 иллюстрирует возможную общую архитектуру совместного процесса разработки. Он показывает отношение подчинения (parent/child) между структурными типами, которое начинается с Проблемы, вводящей поступивший запрос на изменение.

рисунок 1

Рисунок 3: Архитектура совместного процесса разработки — первичные структурные типы

Запрос на изменение начинается с Проблемы. Она может быть связана с одной или несколькими Задачами, и каждая Задача может быть связана с одним или несколькими Действиями. Поскольку Проблема описывает запрос на изменение и ее вводит Публикатор, Задачи и Действия — это записи, отслеживающие работу, которая назначена и должна быть выполнена для решения Проблемы. Краткое описание этих отношений:

  • Проблема (Issue) — документ, сообщающий о проблеме.
  • Задача (Task) — документ, связывающий Проблему с конкретной версией ПО. Несколько задач может ассоциироваться с одной и только одной Проблемой. (Заметьте, что в этом сценарии Задача не связана с задачами, описанными в других продуктах).
  • Действие (Activity) — документ, который фиксирует действия, осуществляемые для поддержки Задачи. С одной Задачей может ассоциироваться несколько действий.
  • Комментарий (Comment) — средство общения с владельцем документа. Комментарии могут быть связаны с Проблемами, Задачами и Действиями, и используются для Вопросов (Questions), Комментариев (Comments) и Ответов (Responses).

Совместный процесс разработки

Рисунок 4 иллюстрирует возможный совместный процесс разработки. Каждая стрелка представляет отношения подчинения между записями.

рисунок 2

Рисунок 4: Совместный процесс разработки

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

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

Процесс передачи проблемы

Рисунок 5a показывает возможные состояния Проблемы, подчеркивая простоту основного процесса разработки. Рисунок 5б иллюстрирует поток работ, начиная с Проблемы в Открытом состоянии (Opened state). Когда решение принято, запись перемещается в Завершенное состояние (Completed state). Публикатор создает запись о Проблеме. Теперь запись находится в Открытом состоянии. Публикатор может удалить Проблему или пересмотреть статус соответствующей Задачи. Если задачи выполнены, и Публикатор соглашается с решением, может быть выбрано Принять Действие (Accept action), чтобы переместить запись в Завершенное состояние.

рисунок 5a

Рисунок 5a: Состояния Проблемы

рисунок 5b

Рисунок 5b: Процесс передачи проблемы

Если Публикатор не согласен с решением, тогда выбор Отказа от Действия (Reject action) перемещает запись в Отклоненное состояние. Обозреватель (Reviewer) может заново рассмотреть состояние проблемы, если появилась новая информация, и затем принять новую информацию, выбрав Принять Действие (Accept action) для перемещения записи в Завершенное состояние. Соответственно, Публикатор может удалить Проблему, выбрав Удалить Действие (Withdraw action) и переместив запись в Состояние удаления (Withdrawn state). Публикатору разрешено вновь открывать Проблему из состояний Удаления, Завершения или Отклонения.

Публикаторы обозревают состояние родственных (дочерних) (child) Задач. Если Публикатор согласен с данным решением, (например, родственная Задача в Завершенном состоянии и с кодом решения «Исправлено»), то он выберет Принять Действие для перемещения записи в Завершенное состояние. Завершенное состояние — состояние окончательное.

Сортировка проблем

Роль Менеджера проектирования/проекта (Engineering/Project Manager) в совместном процессе разработки связана с сортировкой проблем и определением целей новой версии. Эта роль может быть представлена проектировщиками, менеджерами продукта и проекта, контролерами качества (QE) или составителями документации. Эта роль отвечает за оценку Проблемы и последующую работу над ней посредством составления Задач, чтобы отслеживать решение Проблемы. Когда Задача Активирована, создаются Действия, и им предписывается осуществить Задачу. Записи действий — дочерние документы Записи задач, так же как Задачи — дочерние документы по отношению к Проблеме. Проблема может иметь одну или более Задач, с ней связанных.

Задачи

Рисунок 6 показывает возможные состояния Задачи.

рисунок 6

Рисунок 6: Состояния Задачи

В первичном процессе Задача начинается с Открытого состояния. Запись о задаче перемещается в Активное состояние, когда проводится работа. Когда решение принято, запись перемещается в Завершенное состояние.

Владелец записи о Задаче может измениться с изменением состояния записи. Например, когда задача находится в Открытом состоянии, Ведущий разработчик (Developer Lead) по умолчанию — владелец Задачи, а запись хранится в его копии сайта базы данных Dev Lead. Когда задача перемещается в Активное состояние, уже Ведущий контролер качества/тестер (QE/Tester Lead) становится владельцем задачи, и она сохраняется на сайте QE Lead.

Запись Задачи:

  • Содержит всю информацию о том, где Проблема будет решаться.
  • Вначале хранится в копии сайта базы данных Dev Lead Открытом состоянии), а затем на сайте Контролера качества (QE Lead), когда Задача находится в Активном состоянии.
  • Допускает добавление комментариев и проблем.
  • Содержит указатели на все соотвествующие Действия и на Проблему в исходном элементе.

Управление задачей

Ведущий разработчик (статус может быть эквивалентным роли Менеджера Проектирования/Проекта) запускает процесс для Задачи. Рисунок 7 иллюстрирует процесс разработки, в котором Действия для рещения Задачи создаются и затем назначаются.

рисунок 7

Рисунок 7: Процесс для управления Задачей

Действие Активации автоматически создает уникальное Действие для Разработки (Dev), для Тестирования (QE) и для Документации (Doc).

Отслеживание и закрытие Задачи включают:

  • Обзор состояния всех связанных Действий. Для действий в Завершенном состоянии проектирование уже завершено.
  • Установку действия Завершения для закрытия Задачи (Завершенное состояние).

Роль ведущего контролера качества (QE Lead) соответствует процессу, изображенному на Рисунке 8.

рисунок 8

Рисунок 8: Процесс для завершения тестирования Задачи

Действие

Рисунок 9 показывает состояния для Действия в первичном потоке.

рисунок 9

Рисунок 9: Состояния Действия

Представленное состояние — начальная точка для контролера качества (QE) или Doc Activity (Действие документирования), где оно впервые оценивается. Действия начинаются в Открытом состоянии для роли Разработчика (Developer) (Dev).

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

Разработчики (Dev), составители документации (Doc) и контролеры качества (QE), — все оценивают действия и затем работают над ними. Роль Assess/Dev/Doc/QE делает обзор переданных ей Записей о действиях, и затем завершает работу с этими действиями. Есть три типа Записей о действиях:

  • Dev activity (Действие разработки). Разработчики работают над действиями Открытого состояния, порученными им.
  • Doc Assess activity (Действие оценки документирования). Разработчики информации оценивают потребности документирования и обозревают информацию в Действии для решения того, нужна ли документация. Если работа по документированию необходима, они создают действия разработки, чтобы отразить действия в документации.
  • Действия по контролю качества (QE activity). Инженеры по качеству тестируют и подтверждают действия разработчиков (Dev). QE Activity содержит всю информацию по тестированию и результатам.

Комментарии, проблемы и ответы могут быть добавлены к любому типу Действий.

Зачем нужно создавать совместный процесс разработки?

В использовании совместного процесса разработки есть несколько преимуществ — для организации разработки программного обеспечения IBM Rational, а также для других разрабатывающих и IT-организаций. Например, Администраторы могут определить и создать набор всех поддерживаемых версий продукта (или проектов), которые Заказчик может установить, к ним могут относиться:

  • Полные версии ПО, пакеты настройки и другие средства решения проблем или опции.
  • Комплекты 1, предложения 2, коллекции 3, компоновки 4, общие компоненты 5 и компоненты совместного пользования 6.

В случае с IBM Rational, когда Заказчик в случае проблемы обращается в Отдел Поддержки, нужно, чтобы он (заказчик) подключил особую утилиту, чтобы идентифицировать, какое программное обеспечение установлено на машине, на которой обнаружена проблема. Тогда можно создать Проблему в совместном процессе разработки путем обращения к ID-записи RETAIN Call Center (Центра Вызовов).

Если создана запись RETAIN Call Center для данной проблемы и она связана с Проблемой RATLC, тогда можно автоматически сгенерировать Задачу совместном процессе разработки для каждой Проблемы. Задача может содержать информацию, которая имеет отношение к:

  • Версии Продукта (Product Release) или Проекту (Project), в котором проблема будет исправлена.
  • Идентифицированным индивидуальным продуктам, отношение которых к совместным компонентам отслеживается в Базовой записи (Baseline record). (Базовая запись содержит поле, которое допускает трассируемость отношений между комплектами или предложениями и общими компонентами.)

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

Базовую запись и Запись компоновки совместного процесса разработки могут использоваться с проектами, использующими IBM Rational ClearCase/ClearQuest Unified Change Management (UCM) (унифицированное управление изменениями), также, как с теми, которые этого не используют. Базовая запись и Запись компоновки можно также применять для обеспечения успешной доставки Проектов или Версий Продукта или информации к заказчику. Например, Базовая запись и Запись компоновки могут обеспечивать автоматический перенос информации из Разработки в QE/Тестирование качества, информируя контролеров качества о том, какие компоновки (build) продукта содержат средства разрешения специфических Проблем.

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

В этом сценарии, когда Действия записи Задачи определены как полностью завершенные и Задача Одобрена для Внешней Публикации:

  • Код разрешения Задачи может быть переключен на «Исправлено».
  • Закрывающий код может быть установлен и, в зависимости от установленного значения, RETAIN RATLC Bridge может вызвать немедленное Закрытие APAR (автоматического программирования и документирования), связанного с соответствующей Проблемой, или когда в записи Проекта продукт помечается как доставленный.

Дополнительные усовершенствования могут позволить пользователям из любого места определить, когда Средство наладки в Компоновке (Build) становится доступным, независимо от места, где было произведено исправление. Чтобы это работало, информация о конструкции может быть связана с Версией Продукта или Проектом, для того, чтобы пользователи знали, когда проблема будет исправлена в более поздней версии продукта (более поздней по отношению к той, в которой была найдена проблема). Более того, пользователи, зная имя проекта или ID, могут увидеть, доступна ли обновленная версия, и если это так, откуда ее можно инсталлировать.

Запись Проекта совместного процесса разработки может действовать как контейнер или родительская запись по отношению ко всем Проблемам для данной версии продукта. Запись Проекта может включать поля, требующие заполнения, такие, как Name, Unique ID, DefaultDev, DefaultDoc, DefaultQE, Program Manager, ProductManager и TriageAdmin. Дополнительные поля могут включать: значения, которые указывают, использует ли проект ClearCase/ClearQuest UCM Integration для осуществления доставки измененных файлов или нет; обратные ссылки на другие проекты совместного процесса разработки (например, PriorProjects или ProjectsRelated), или UCM-проекты; и поля, которые могут быть установлены для команд разработки (например, Component Team).

Совместный процесс разработки в среде ClearQuest Multisite

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

Обратите внимание на то, что:

  • Проблема должна копироваться на все сайты, чтобы быть видимой.
  • Проблема содержит ссылки на смежные Задачи, и Задачи содержат ссылку на Проблему.
  • Каждая Задача решается на сайте владельца Dev по умолчанию, если задача Открыта. Задача решается на сайте котролера качества QE Lead, если Задача Активирована.
  • Действие для смежной Задачи после того, как она Открыта или Опубликована, рассматривается на сайте Владельца. По умолчанию Разработчик — Владелец Действия Dev. Владелец Dev по умолчанию может быть определен значением поля в Проекте, Компоненте или Подкомпоненте. Владелец Doc по умолчанию — владелец Действия Оценки Документирования (Doc Assess Activity), и владелец QE по умолчанию — владелец Действия Тестирования (Test Activity).

Заключение

Схема RATLC и ее использование в организации разработки программного обеспечения IBM Rational обеспечивают идеальный вариант использования (use case) управления изменениями ClearQuest в распределенной среде разработки программного обеспечения. Эта рабочая модель также иллюстрирует достижения совершенствования передовой практики в проектировании процесса для обращения к запросам заказчиков через системную интеграцию.

Так же, как многие из наших заказчиков имеют внутреннюю группу для разработки и развертывания решений, организация разработки IBM Rational имеет внутреннюю группу развертывания для конструирования и применения, а также управления изменениями в RATLC и смежных пользовательских базах данных. Внутренняя группа развертывания (Internal Deployment group) IBM Rational просит своих пользователей, какими бы ни были их роли, выступать с замечаниями, потому что мы стремимся обеспечить наилучшее руководство идеями, проектом и исполнением, проектируя и развертывая соместный процесс разработки в IBM Rational.

Как впервые упоминалось в части 1, процесс начинается, когда Заказчик звонит в Отдел Поддержки или посылает туда сообщение по электронной почте. Отдел публикует запись в приложении о коммуникации Call Center, а там RETAIN RATLC Bridge запускает запись как новый запрос на изменение и представляет его в системе ClearQuest с соответствующей информацией, внесенной из записи RETAIN Call Center. RETAIN RATLC Bridge автоматизирует связь между соответствующими запросами на изменение от двух систем отслеживания. Владельцы ClearQuest по умолчанию (которыми могут быть группы или списки пользователей) получают по электронной почте автоматическое уведомление, касающееся представления на рассмотрение новых запросов на изменение. Запросы об изменениях сортирует и распределяет Владелец (по умолчанию). Когда запрос на изменение разрешен, часть решения — обновить информацию в ClearQuest на закладках Customer (Заказчик) и APAR. Состояние завершения задачи запускает RETAIN RATLC Bridge, чтобы обновить информацию и статус RETAIN APAR.

Концепция совместного процесса разработки, как показано в этой статье, может быть рассмотрена как общий шаблон управления изменениями и процесс с широкой применимостью в разных производствах. Его также можно рассматривать в контексте более специализированного для данной отрасли проекта и реализации, в котором обобщенная схема совместнго процесса разработки может быть модифицирована для решений по управлению изменениями в здравоохранении, финансовой сфере, банковском деле или автомобильной промышленности; для каждого случая потребуются собственные релевантные структурные типы, определенные стратегии и управление, а также специализированные для данной отрасли пользовательские роли. Однако роли ClearQuest (описанные в части 1) адекватны в различных средах управления изменениями, поскольку проектирование, исполнение и администрирование системы ClearQuest для пользователей обычно влечет за собой применение ролей Разработчика Схем (Schema Developer) и Администратора (Administrator), независимо от специфики реализации.

IBM Rational ClearQuest и организации — разработчики Rational используют систему управления изменениями ClearQuest для усовершенствования продукта, который они разрабатывают. Непрерывное совершенствование схемы RATLC, включая такие компоненты интеграции, как RETAIN RATLC Bridge, позволяет ускорить и сделать более эффективными связи между заинтересованными сторонами и более гладко осуществлять обмен данными между различными хранилищами. Целью наших постоянных усилий по улучшению функционирования является быстрое реагирование на запросы заказчика об изменении в продукте, связан ли запрос с проблемой или с необходимостью усовершенствования. В таком контексте совместный процесс разработки призван улучшить процесс решения ситуации с запросом об изменении, направляя процессы отслеживания будущих усовершенствований и обеспечивая возможность для всех заинтересованных сторон знать статус проблемы в любое время, независимо от часового пояса и размещения их офиса.

Выражаю особую благодарность Роберту В. Майерсу и команде Rational Internal Deployment (Ширли Данго, Чибузо Оби, Барб Пурчиа и Кейти Ладлоу) за разработку значительной части технической информации в этой статье. Роберт помогает проводить инициативы IBM Rational Internal Deployment для системы управления изменениями в IBM Rational.

Обратите внимание

1 Комплект (bundle) — это версия, являющаяся коллекцией скомпонованных предложений (но не общим компонентом).

2 Предложение (offering) — это версия продукта, которую покупает Заказчик. Это может быть комплект, однокомпонентный продукт, или продукт, который включает многочисленные компоненты, и/или один или более общие компоненты.

3 Коллекция (collection) — это набор компоновок и индивидуальных модулей.

4 Компоновка (assembly) — это версия, являющаяся коллекцией двух или более компонентов, обеспечивающих функцию, которая, в свою очередь, включена в предложения (offering), которым требуется данная функция.

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

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

21.02.2008

Комментарии

  • предоставление микрозаймов
    Автор:   ·  29.08.2014 01:13:44
    Семья - это та первичная среда, где человек должен учиться творить добро ------ Тинькофф кредит онлайн
  • женская одежда онлайн
    Автор:   ·  29.08.2014 00:58:37
    Тот получил настоящую выгоду, кто принес выгоду достойному человеку. ------ свободные свитера и туники
  • самые свежие новинки для геймеров
    Автор:   ·  27.08.2014 00:35:10
    Увидеть боевики онлайн на http://kinoreys.com можно просто и качественно. Посетите сайт просто зараз Чтобы сделаться настоящим геймером, посетите http://la2-anons.net/ - здесь представлены все Lineage тактики, которые Вам необходимы Обои собраны в полностью на http://top-programs.ru , чтобы сделать для Вас атмосферу уюта Все виды фильмов вы отыскать найти на http://v-efire.net и провести сеанс триллера Приключения сериалы на любой вкус на http://www.kinozal-live.ru/ Вы отыщете весело и легко Для малышей все самые сказочные мультфильмы на http://www.multyaha.com/ можно найти одним кликом. Просто перейдите на сайт и порадуйте своего малыша Хорошие сказки на http://biger-films.ru Вы можете найти легко и просто - нужно всего лишь заглянуть на этот сайт Разнообразные Аркады собраны на http://www.texttrader.org/ - на сайте у Вас не останется времени для сна У вас есть авто знаменитой марки BMW - посетите сайт http://bmw-guide.ru/ . На нем собрано множество полезной информации для владельцев авто этой фирмы Необходимые утилиты Вы можете установить с http://softik1.ru без лишних усилий
  • Проверенные торрент трекеры для кино и музыки
    Автор:   ·  27.08.2014 00:18:01
    Web-сайт http://www.candysoft.ru/ дает возможность загрузить самый новый софт без регистрации и узнать компютерные новости. На сайте http://kinovica.net/ опубликованы для загрузки фильмы и мультики - всё необходимое для настоящего отдыха с семьей и любимыми киногероями Несомненно, вам надо зайти на http://gigfile.ru/ - лишь там есть полностью всё, музыка, мультфильмы, софт. Фильмы на ваш вкус можно найти у нас на сайте http://juzer.ru/ - Заходите и смотрите бесплатно! На сайте - http://realwindows.ru/ можно найти всю подробную информацию о программах одной из самых крупных компаний - Microsoft. Смотреть сериалы на сайте можно с http://baldeem-vmeste.ru - здесь представлены самые новые киноленты Чтобы стать отличным юзером посетите страничку http://byxta.info - здесь Вы найдете лучшие видео для своих Пк На нашем портале http://daromvse.ru Вы можете увидеть самые интересные новинки для планшетов Комедия - на http://ivibox.info Вы можете быстро найти и просмотреть Самые интересные фильмы на http://kino-lives.ru можно просмотреть только в один клик
  • свежие фильмы и игры на торентах
    Автор:   ·  27.08.2014 00:04:58
    Интересные игры на любой вкус можно скачать на http://crysiswars.ru и перенестись в мир приключенческой жизни Чтобы найти новый софта необходимо перейти на http://newprogram.ru/ - здесь собраны самые свежие новинки Ждете с нетерпением выпуска нововой музыки? Тогда http://werap.ru/ поможет вам сократить ваше ожидание любимой новинки Найдите для себя интересные файлы из http://sertorrent.ru , чтобы провести неповторимым свой вечер Скоростной трекер http://torrentos.org/ предоставляет возможность скачать всё от мультиков доредких утилит на максимальной скорости Зайдите сайт http://varezik.ru , чтобы скачать много новых новых фильмов для любых предпочтений Этот торрент-трекер http://www.windows-news.ru/ дает возможность загрузить себе отборные фильмы всего лишь в один клик и без обязательной регистрации Только бесплатные проги на http://besplatnydownload.ru/ - просто перейли и качай без регистрации Интернет портал http://savetorrent.ru/ сделан для того, чтобы связать между собой пользователей с общими интересами, которые желают поделиться с другими интересными файлами Новинки для смартфонов можно установить с http://upmobile.org/ - все самое нужное для ваших гаджетов
  • Интересные факты о кино 2014
    Автор:   ·  26.08.2014 13:07:21
    Посетите наш сайт http://roomfilms.com , чтобы окунуться самые свежие сериалы этого года Самые классные сериалы на http://tiktak.su/ можно скачать бесплатно. Лишь на сайте http://www.softik.ws/ можно отыскать все самые лучшие фильмы. Этот торрент трекер http://torrent-kombo.com/ - самый известный торрент, на котором есть музыка для любых предпочтений На торрент-трекере http://torrent-movie.ru/ вы можете не только загрузить любой сериал, но и просмотреть его online перед закачкой! Увидеть сериалы можно одним кликом на http://www.planet-film.ru - самые новые предложения размещены здесь Самые новые киноленты этого лета можно увидеть на http://kinoabc.ru и почерпнуть для себя потрясающие ощущения Лучшие игры для вашего iPhone можно скачать на http://iphonster.ru - установите для себя новый мир одним кликом Отройте для себя на наш портал http://torrent-zona.ru/ и получите тонну радости от просмотра фильмов Зарубежные сборники можно легко найти на http://rapportal.net - на портале представлено все интересное для вас
  • оформить карту тинькофф
    Автор:   ·  07.08.2014 21:51:04
    Успех брака не столько в том, чтобы найти идеального партнера, сколько в том, чтобы самому быть идеальным партнером. ------ онлайн заявка на карту тинькофф
  • скачать vip-torrents
    Автор:   ·  28.07.2014 11:28:54
    Если желаете добиться успеха в этом мире, то обещайте всё и не выполняйте ничего. ----- Скачать фильмы и игры через торрент

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта