Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘ibm’

Традиционное планирование: Управление формальными проектами в Rational Team Concert 4.0

Posted by Шамрай Александр на Январь 27, 2012

Оригинал: https://jazz.net/library/article/657/

Перевод Шамрай А.В.

Традиционные планы

Компонент планирования Rational Team Concert позволяет планировать полный выпуск проекта, а также его различные фазы. Традиционная модель планирования разработана, чтобы поддерживать планирование проекта на основе формального шаблона процесса управления проектами, который включает ряд последовательных фаз (Требования, Проектирование, Реализация и Тестирование). Чтобы использовать традиционную модель планирования, используйте формальный шаблон процесса управления проектами, который поддерживает формальный или традиционный процесс планирования.

Формальный шаблон процесса управления проектами обеспечивает следующие настраиваемые задания:

  • Запрос на изменения проекта: Определяет изменение в согласованные объем и цели проекта для вставки требований, которые не были первоначально определены как часть проекта.
  • Бизнес-потребность: Описывает функцию, API или улучшения, которые добавляются к продукту. Бизнес-потребность описывает работу на высоком уровне так, чтобы все могли понять, что нужно сделать, глубоко не вникая в детали.
  • Риск: Идентифицирует возможное событие, которое может негативно повлиять на проект. Этот тип задания включает матрицу для вычисления вероятности и влияния риска.
  • Действие с риском: Определяет то, что должно быть выполнено, чтобы смягчить риск. Действие с риском – это элемент работы и оценивается в часах.
  • Проблема: Идентифицирует непредвиденные события, которые произошли в проекте.
  • Стадия: Определяет важный момент или событие в плане, где событие — возникновение чего-либо или результат.

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

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

Когда следует использовать традиционное планирование

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

Традиционные планы для формальных проектов

С шаблоном формального процесса управления проектами поставляется три типа плана:

  • План выпуска: этот тип плана является планом самого высокого уровня. Она обеспечивает краткий обзор целей проекта. Хотя можно создать для любого этапа план выпуска, лучше использовать этот тип плана для общего выпуска.
  • План этапа: этот тип плана показывает цели, которые должны быть достигнуты в этапе. Вы можете создать план этапа и назначить задания, которые должны быть завершены на этом этапе.
  • Кросс проектный план: этот тип плана отслеживает расписание заданий в других проектах. Вы можете создать кросс проектный план, создать задания для отслеживания и добавить ссылки Отслеживание на задания из различных проектов/планов.

Дополнительные сведения о различных типах плана см. в Типы планов.

Например, Интернет-магазин музыки – это проект, который имеет традиционный план со следующими артефактами:

  • Запроса на изменение проекта: Добавить возможность скопировать существующий список воспроизведения.
  • Бизнес потребность: Пользователь должен иметь возможность управлять списком воспроизведения.
  • Задачи: Реализовать удаление элементов из списка воспроизведения.
  • Стадии: Beta 1, Beta 2 и eGA

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

Зависимости и ограничения

Можно создать график зависимости между двумя заданиями. Зависимости используются для вычисления расписания заданий в плане. В настоящее время поддерживается только один тип зависимости:

  • Окончание-начало: В этой зависимости начало следующего задания зависит от завершения другого задания: предшественника.

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

Кроме того можно применять ограничения для расписания заданий. Ограничения также используются для вычисления расписания заданий в плане. Доступны три типа ограничений:

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

Критический путь

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

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

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

Пометка потенциальных проблем в плане

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

  • Отсутствуют необходимые атрибуты
  • Неверная оценка
  • Неверные данные, включая зависимости или нарушения ограничений

Предложенные моментальные копии

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

Риски и действия с риском

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

Представление График работ и расписание по умолчанию отфильтровывает все риски из представления плана. Удалите фильтр по умолчанию для просмотра рисков в плане.

После выявления и определения рисков, можно создать задание Действие с риском для отслеживания мероприятий по уменьшению риска. Вы уменьшаете риск, используя стратегию. Например, после того, как задание риск «Требуемый виджет не поддерживаются во всех браузерах» определен, можно создать задание действие с риском, такое как «Исследовать планы поставщиков для поддержки виджета в будущем». Дополнительные сведения о создании заданий действие с риском, см. Создание действий с риском.

Можно связать задания Риск и Действие с риском с помощью ссылки «Кем исправлено» и «Исправляет». Вы можете использовать эти ссылки для отслеживания какие действия с риском исправляют какие риски.

Ресурсы

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

Ресурсами управляют на вкладке Ресурсы в плане.

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

Сведения об управлении ресурсами в рамках проекта приведены в разделе Управление ресурсами проекта.

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

Доступность ресурсов и расписание плана

Доступность ресурсов является одним из критериев, которые обеспечивает расчет расписания. Если изменить доступность ресурсов или запланированное отсутствие, расписание автоматически обновляется для отражения изменений. Например, после того, как ресурс добавляет запланированное отсутствие (см. рисунок ниже)…

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

Запланированные моментальные копии

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

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

Дополнительные сведения о том, как управлять моментальными копиями, см. Эффективное планирование с использованием моментальных копий в RTC 4.0.

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

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

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

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

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

Создание итерации из плана

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

Сведения о добавлении дочерних итераций в родительской итерации из представления планов содержатся в разделе Создание дочерней итерации.

Об авторе

Sharoon Shetty Kuriyala лидер команды, которая разрабатывает компонент планирования для Rational Team Concert. С ней можно связаться по адресу sshettyk@us.ibm.com.

Реклама

Posted in IBM Rational, Team Concert | Отмечено: , , | Leave a Comment »

Дерево версий ClearCase – глюк или фича?

Posted by Шамрай Александр на Январь 5, 2012

Вот такое вот счастье получилось сделать из одной и той же вьюхи.

Posted in ClearCase | Отмечено: , , | Leave a Comment »

Сравнение концепции ClearCase UCM и RTC

Posted by Шамрай Александр на Ноябрь 15, 2010

Оригинал: Comparing concepts between ClearCase UCM and RTC

Введение

Некоторые путаются в сходствах и различиях между Rational ClearCase и Rational Team Concert. В основном это связано с изменениями в терминологии, а в некоторых случаях это связано с различными моделями использования и возможностями продуктов. Данная статья направлена на прояснение некоторых моментов.

Демонстрация будет выполняться на основе UCM, так как многие из наших клиентов используют ClearCase UCM. Если вы используете ClearCase UCM интегрированный с ClearQuest, то настоятельно рекомендуется также прочитать Сравнение концепции ClearQuest и Rational Team Concert.

Базовая терминология

Давайте рассмотрим различия между ClearCase UCM и Rational Team Concert (RTC). ClearCase является системой управления конфигурацией. Клиенты могут использовать его отдельно или с функциональностью UCM. UCM дает пользователям создавать программные Компоненты (Component), а затем создавать Базовые линии (Baseline) на эти компоненты. Файлы для изменения Извлекаются на редактирование (Checked Out), изменяются, а затем Регистрируются (Checked In) в рамках представления, которое является рабочим пространством для разработки. Наборы изменений (Change Sets) составляются из отдельных изменений, внесенных в рамках Активности (Activity). Эти Наборы изменений затем становятся общедоступными для других членов команды через операцию Доставки (Delivery) этих Наборов изменений. ClearCase хранит эти артефакты в собственном формате и сохраняет все свои данные в репозитории, который называется VOB. Каждый VOB может содержать один или более компонентов UCM. Каждый VOB может хранить артефакты в любой структуре каталогов, которую пользователь хочет использовать. ClearCase поддерживает параллельную разработку и, когда возникают конфликты между версиями одного и того же файла, то они разрешаются с помощью операции Слияния (Merge). В базовом ClearCase, VOB-файлы могут содержать Ветви (Branch), которые обеспечивают логическое «разделение» кода для параллельной разработки, которая выполняется изолированно. В UCM эти Ветви имеют некоторые формальные ограничения и называются UCM-потоки (UCM Streams). Участник команды разработки выполняет Доставку его или ее изменений из их рабочего пространства, называемого Представлением (View), в Поток (Stream). Другие члены команды будут выполнять Обновление (Rebase) их Потока и забирать изменения, которые доставлены в родительский Поток.

ClearCase есть такое понятие как Динамическое представление (Dynamic View), это рабочее пространство, которое обновляется без вмешательства пользователя, на основе пользовательских настроек. ClearCase есть также концепция Статических представлений (Snapshot View), которое является копией рабочего пространства, ассоциированного с состоянием репозитория в определенный момент времени. Статическое представление приводится к «текущему состоянию»с помощью операции Обновить (Updating) представление. В любом из этих типов представлений, Базовые линии и Наборы изменений могут быть доставлены из потока в поток, при этом любые необходимые операции Слияния по отдельным файлам будут обнаружены системой, а затем их должен будет разрешить пользователь. Также как Компоненты получают Наборы изменений, применяемые к ним, отдельные Компоненты могут иметь Базовые линии (в основном как метка для всех артефактов в рамках Компонента или VOB), применяемые к ним. «Основная базовая линия» с набором базовых линий нескольких Компонентов называется Композитная базовая линия (Composite Baseline).

В RTC SCM есть многие из этих же понятий, но есть некоторые незначительные отличия. Jazz имеет единое хранилище, в котором хранятся его артефакты как REST ресурсы. Эти ресурсы хранятся в базе данных. Jazz поддерживает использование многих баз данных, включая Oracle, DB2 и SQL Server. Это, в общем, используется как Jazz Репозиторий (Jazz Repository). В Jazz разрабатываемая программа разбивается на программные Компоненты (Component). Эти Компоненты могут содержать артефакты в любой структуре каталогов, и параллельная разработка поддерживается с использованием Jazz Потоков (Jazz Streams). Пользователи, работающие с Jazz Компонентой, присоединяются к проекту и создают своё собственное Рабочее пространство Репозитория (Repository Workspace) (которое содержит копии всех их Наборов изменений (Change Set)), а также Личное Рабочее пространство (Sandbox) на своем локальном компьютере. Все изменения файлов отслеживаются клиентом Jazz, и пользователь в дальнейшем будет Регистрировать (Check In) свои изменения. В Jazz нет понятия изъять на редактирование, но Jazz поддерживает Блокировку (Locking) ресурсов. Когда пользователь видит изменения в своем Личном рабочем пространстве, он будет Регистрировать изменения и связывать их с Набором изменений, который собирает отдельные изменения и сохраняет их в Рабочем пространстве Репозитория. Эти Наборы изменений могут быть Доставлены (Deliver) в один или несколько Потоков Jazz. Другие члены команды будут Принимать (Accept) изменения в свои Рабочие пространства Репозитория из этого потока, и поставлять сделанные изменения на Родительский поток.

Личное рабочее пространство пользователя или Рабочее пространство Eclipse (Eclipse Workspace), может иметь свой проверяемый в любое время статус, с помощью интерфейса указывающего на все потенциальные исходящие Наборы изменений (работу, которую пользователь хочет Доставить), а также входящие Наборы изменений (работа, которая выполнена другими членами команды). Пользователи имеют возможность выбрать Наборы изменений либо для Доставки (Наборы изменений становятся доступными для всех членов команды), либо для Принятия (применение Наборов изменений в Поток в свои Рабочие пространства Репозитория и Личное) на индивидуальной основе. Базовые линии (Baselines) для Компонентов также можно создавать, и набор Базовых линий для нескольких Компонентов называется Снимком (Snapshot). Его не следует путать со Статическим представлением в ClearCase, т.к. эти понятия совершенно различны.

Есть ряд тонких различий в том, как системы работают, и это отражается на механизмах взаимодействия пользователей с этими системами. В ClearCase пользователи часто создают Потоки и Ветви для изолирования своей работы. Часто пользователи создают несколько Представлений (рабочих пространств), и один набор изменений выполняется в своем Представлении. С помощью этого изменения могут быть изолированы друг от друга, и обеспечивается отсутствие зависимостей артефактов создаваемых между Наборами изменений. В Jazz пользователь выполняет одно изменение в одно время, в рамках своего Локального рабочего пространства. Пользователи, работающие с несколькими изменениями, имеют выбор, они могут либо создать несколько Локальных рабочих пространств и Рабочих пространств Репозитория или они могут Приостановить (Suspend) работу над одним Набором изменений прежде чем приступить к другим. Возможность Приостановить работу по существу принимает все изменения, связанные с Набором изменений, и сохраняет их в Репозитории, после этого пользователь может Возобновить (Resume) (или вернуться) к этим изменениям в дальнейшем. Рабочее пространство при этом возвращается в состояние, в котором оно находилось, когда был применен предыдущий Набор изменений. Это помогает сократить количество Рабочих пространств, которые разработчику нужно поддерживать.

При использовании ClearCase с ClearQuest и UCM можно связывать с Запись ClearQuest (ClearQuest Record) с Набором изменений. Это требует некоторой настройки и доступности Репозитория ClearCase (VOB) и базы данных CQ. В Jazz/RTC вся эта информация находится в том же хранилище, тут связь создается между Рабочими элементами (Work Item) и Набором изменений. Так как все это построено на основе REST, различные типы объектов Jazz могут быть связаны друг с другом, обеспечивая большую гибкость в связях между артефактами разработки.

Понятие ClearCase Эквивалент Jazz Описание
Check Out/Check In Check In Регистрация изменений в Репозиторий
Activity Change Set Собирает набор изменений файлов в один пакет изменений, обычно связанных с Записью CQ/Рабочим элементом
VOB Jazz Repository Хранит данные в системе управления версиями – один Jazz Репозиторий, несколько VOB-ов
Dynamic View n/a Виртуальное рабочее пространство, содержание которого является динамическим
View Storage Repository Workspace Это не очень хорошее сравнение для Рабочего пространства Репозитория, но хранилище представления на сервере представлений приблизительно похоже
Snapshot View Sandbox/Eclipse Workspace Рабочее пространство, основанное на копировании, используется для разработки
Updating Synchronizing/Accept Обновление рабочего пространства пользователя, когда изменения от других членов команды загружаются в личное рабочее пространство пользователя
Deliver Deliver Продвижение набора изменений из рабочей области в поток, где они становятся общими для всей команды
Rebase Accept Изменения, выполненные другими членами команды, загружаются в личный рабочий поток пользователя
Reserved Check Out Locked Возможность «зарезервировать» ресурс, вы будете являться единственным пользователем, который может изменить ресурс
Baseline Baseline Набор файлов (конфигурация) в рамках компонента в определенный момент времени
Composite Baseline Snapshot Набор различных компонентов, а также конкретная базовая линия в этих компонентах
UCM Process Templates (как Scrum) Стандартно поставляемый процесс, который определяет типы записей/рабочих элементов, связи и процессы, связанные с ними
Stream/Branch Stream Логическое «разделение» кода, обеспечивающее параллельную разработку и изоляцию
Merge Merge Взятие версий одного и того же файла в двух различных ветвях и сопоставление изменений, внесенных в эти файлы
n/a Suspend/Resume Возможность временного хранения или восстановления изменений, сделанных в рабочем пространстве, чтобы вернуть рабочее пространство в некоторую известную конфигурацию

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

Об авторе

Daniel Toczala является Техническим лидером команды Jazz Jumpstart. Он работал в прошлом с Rational Services в качестве Senior Solutions Architect. Он использовал свой опыт в оказании помощи различным клиентам в осуществлении организационных изменений, чтобы помочь построить концепции шаблонов развертывания. Он сделал многочисленные презентации о том, как организации могут использовать технологий Jazz и Agile подходы в разработке программного обеспечения для повышения качественного результата, который организации по разработке ПО поставляют своим клиентам.

Dan путешествует по миру, помогая клиентам IBM, но его дом в Нью-Хартфорд, штат Нью-Йорк. С ним можно связаться по dtoczala@us.ibm.com.

Posted in ClearCase, IBM Rational, Team Concert | Отмечено: , , , | 11 комментариев »

Почему элементы IBM Rational ClearCase помещаются в директорий lost+found и как их удалить оттуда?

Posted by Шамрай Александр на Ноябрь 12, 2010

<< Перейти в раздел «ClearCase FAQ»

Оригинал: About the lost+found directory

Почему элементы помещаются в директорий lost+found

Объект будет размещен в каталог VOB-а lost+found, когда родительский директорий был удален (в этом случае уже нет контекста, в котором отображается объект) или изменен так, что его содержание не имеет ссылки на предыдущую версию каталога. Это может произойти в следующих случаях:

  • Родительский каталог объекта был удален с помощью команды rmelem и более нигде нет прямых ссылок на объект в версионном хранилище.

Пример:

%>cleartool rmelem dir1
CAUTION! This will destroy the element, all its branches and versions,
including all data, meta-data and history, and will remove the element
from all directory versions that now contain it.  Once you destroy the
element, there will be no way to restore it to its current state.
If you want to preserve the element, but remove references to it from
future directory versions, use the «rmname» command.

Element «dir1» has 1 branches, 2 versions, and is entered
in 1 directory versions.
Destroy element?  [no] y
cleartool: Warning: Object «foo.c» no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as «foo.c.986de380d90b479db49316560deba2f2».
Removed element «dir1».

  • Родительский каталог был изъят на редактирование, были добавлены файлы и/или директории, а затем редактирование директория было отменено (выполнения операция unchecked out).

Пример:

%>cleartool co -nc dir1
Checked out «dir1» from version «/main/7».

%>cleartool mkelem -ci -nc foo.c
Created element «foo.c» (type «text_file»).
Checked in «foo.c» version «/main/1».

%>cleartool unco dir1
cleartool: Warning: Object «foo.c» no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
«foo.c.c7592f61ab0b11db83b5000180f96245».
Checkout cancelled for «dir1».

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

Пример:

%>cleartool co -nc dir1
Checked out «dir1» from version «/main/7».

%>cleartool mkelem -ci -nc foo.c
Created element «foo.c» (type «text_file»).
Checked in «foo.c» version «/main/1».

%>cleartool rmname foo.c
cleartool: Warning: Object «foo.c» no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
«foo.c.c7592f61ab0b11db83b5000180f96245».
Removed «foo.c».

Когда объект перемещается в корень каталога lost+found его OID (идентификатор объекта) добавляется к его оригинальному имени файла. Например:

Оригинальное наименование: foo.c
Наименование в lost+found: foo.c.282d5d339cba4043905da6ca201e1f3d

Если каталог перемещается в lost+found, все подкаталоги и элементы, которые он содержит, перемещаются вместе с ним (структура каталогов сохраняется). Поскольку содержание каталога не помещается в корень lost+found, файлы и директории внутри перемещенного каталога не переименовываются по правилам, описанным выше.

Удаление объектов из lost+found

Прежде чем принимать какие-либо шаги по очистке lost+found VOB-а, пожалуйста, сделайте резервную копию VOB-а.

Есть два возможных способа для удаления объекта из корня lost+found:

    1. Объект может быть перемещен на новое место в VOB-е использованием команды cleartool mv.
    2. Объект может быть полностью удален из VOB.
      • Чтобы переместить объект в новое место, необходимо изъять на редактирование каталог, в который будет помещен объект, и использовать команду cleartool mv <object>.

      См. IBM Rational ClearCase Command Reference команда mv (cleartool man mv) для дополнительной информации.

      Пример:

      % pwd
      /vobs/myvob/lost+found

      % cleartool ls
      test.c.f9e4e356252a11d0a41508000993b102@@/main/1    Rule: /main/LATEST

      % cleartool checkout -nc /vobs/myvob/src

      % cleartool mv test.c.f9e4e356252a11d0a41508000993b102 /vobs/myvob/src/test.c
      Moved «test.c.f9e4e356252a11d0a41508000993b102» to «/vobs/myvob /src/test.c».

      Примечание: Для перемещения необходимо использовать команду cleartool mv, как описано выше, поскольку операция копировать/вставить из Windows Explorer или ClearCase Explorer будет просто создавать приватный файл представления и не будет перемещать элемент.

      • Чтобы удалить объект из VOB-а, используйте команду cleartool rmelem <object>.

      ВНИМАНИЕ: прочитайте нижеприведенное перед выполнением операции

      Осторожно используйте rmelem при удалении элементов или символических ссылок из каталога lost+found. Хотя lost+found, как правило, содержит нежелательные элементы и символические ссылки, в некоторых случаях он может содержать элементы, которые содержаться в другом месте VOB-а (то есть, с родителем), с которыми связаны символические или прямые ссылки. Поэтому, не запускайте rmelem рекурсивно в lost+found без предварительной проверки его содержимого.

      Если необходимо сохранить элемент, который находится в lost+found, перенесите его в другой каталог с помощью команды mv, как описано в предыдущем разделе.

      См. IBM Rational ClearCase Command Reference команда rmelem (cleartool man rmelem) для дополнительной информации.

      Пример:

      Example:

      % pwd
      /vobs/myvob/lost+found

      % cleartool ls
      test.c.f9e4e356252a11d0a41508000993b102@@/main/1    Rule: /main/LATEST

      % cleartool rmelem test.c.f9e4e356252a11d0a41508000993b102


      CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it.  Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the «rmname» command.

      Element «test.c.f9e4e356252a11d0a41508000993b102» has 1 branches, 2 versions, and is entered in 1 directory versions.
      Destroy element?  [no] yes
      Removed element «test.c.f9e4e356252a11d0a41508000993b102».

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

      Если существуют элементы изъятые на редактирование, то изъятие на редактирование должно быть отменено до того, как элемент будет удален из lost+found, см. technote 1259118.

      Использование шаблонов для удаления объектов из lost+found

      Командная строка cleartool в сочетании с шаблонами может быть использована для удаления сразу нескольких элементов из каталога lost+found VOB-а.

      ВАЖНО: Перед выполнением нижеприведенных шагов, Вы должны проверить актуальность файлов в lost+found. Если есть шанс, что эти файлы не должны быть удалены, не используйте эти инструкции. См. раздел Руководства администратора ClearCase The lost+found Directory для дополнительной информации.

      Из представления ClearCase, перейдите в каталог lost+found, запустите командную строку cleartool и вызовите команду rmelem:

      Z:\VOB1\lost+found>cleartool
      cleartool> rmelem *.*

      CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it.  Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the «rmname» command.

      Element «nameapp.c.e83edfb9dfa042db90b83d4417fdec5c» has 1 branches, 2 versions, and is entered in 1 directory versions.
      Destroy element?  [no] yes
      Removed element «nameapp.c.e83edfb9dfa042db90b83d4417fdec5c».

      Примечание: Используйте -force для подавления подтверждения запроса «Destroy element?»:

      cleartool> rmelem -force *.*

      См. Руководство по командам ClearCase по теме rmelem (cleartool man rmelem) для получения информации о поведении rmelem при удалении символической ссылки.

      Удаление нескольких уровней каталогов

      Если существуют каталоги в lost+found, которые должны быть удалены, вам нужно запустить команду rmelem несколько раз.

      Почему?

      • После первой итерации, все элементы, которые были в удаляемом каталоге из lost+found, перемещаются в корень lost+found.
      • Последующие итерации rmelem будут удалять элементы, которые были перемещены в корень lost+found.

      Определение UCM компонента, к которому принадлежит элемент lost+found

      Следующая процедура может быть использована для определения, куда перемещать элементы в случаях, когда есть один или несколько элементов lost+found VOB-а, который содержит много компонентов UCM.

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

      1. Откройте окно командной строки (Пуск> Выполнить> набрать: cmd.exe)
      2. Перейдите в представление и каталог lost+found конкретного VOB-а
      3. Выполните «cleartool dump -l <element-name>@@», например:
        >cleartool dump -l test.txt.3a99f3b26e9d43bb87e48b981708138c@@test.txt.3a99f3b26e9d43bb87e48b981708138c@@ (3a99f3b2.6e9d43bb.87e4.8b:98:17:08:13:8c)
        M:\mra_EclipseTest\ManyComps\lost+found\test.txt.3a99f3b26e9d43bb87e48b981708138c@@
        oid=3a99f3b2.6e9d43bb.87e4.8b:98:17:08:13:8c dbid=289 (0x121)
        mtype=file element type=9
        stored fstat:
        ino: 0; type: 2; mode: 0444
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 1; size: 0
        atime: Wed Dec 31 19:00:00 1969
        mtime: Wed Sep 24 07:44:00 2008
        ctime: Wed Sep 24 07:44:00 2008
        returned fstat:
        ino: 289; type: 2; mode: 0444
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 1; size: 0
        atime: Wed Sep 24 07:44:00 2008
        mtime: Wed Sep 24 07:44:00 2008
        ctime: Wed Sep 24 07:44:00 2008
        master replica dbid=3
        source pool=33 cleartext pool=35
        crde=46
        branches:
        290 \main
        292 \main\mra_EclipseTest

      4. Найдите строку, которая имеет «crde =» и запомните число, которое будет после знака равенства. В приведенном выше примере номер «46» то, что нам нужно. Это идентификатор компонента корневого каталога элемента, который мы будем использовать, чтобы найти компонент, в который элемент должен быть перемещен.
      5. Перейдите в корень VOB-а
        >dir
        Volume in drive M is CCase
        Volume Serial Number is 0234-5789 

        Directory of M:\mra_EclipseTest\ManyComps 

         

        08/28/2007  07:13 AM    <DIR>          .
        09/18/2008  12:03 PM    <DIR>          ..
        08/28/2007  07:13 AM    <DIR>          Comp1
        09/24/2008  07:44 AM    <DIR>          Comp2
        09/24/2008  07:44 AM    <DIR>          lost+found
        0 File(s)              0 bytes
        5 Dir(s)  52,428,800,000 bytes free

      6. Выполните «cleartool dump <sub-directory-name>@@» в одном из поддиректориев компонента. Например:

        >cleartool dump -l Comp1@@ 

        Comp1@@ (ebb32a4a.46224a03.b388.40:71:64:7a:1a:7d)
        M:\mra_EclipseTest\ManyComps\Comp1@@
        oid=ebb32a4a.46224a03.b388.40:71:64:7a:1a:7d dbid=42 (0x2a)
        mtype=directory element type=6
        stored fstat:
        ino: 0; type: 2; mode: 0777
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 2; size: 0
        atime: Wed Dec 31 19:00:00 1969
        mtime: Tue Aug 28 07:13:57 2007
        ctime: Tue Aug 28 07:13:57 2007
        returned fstat:
        ino: 42; type: 2; mode: 0777
        usid: NT:S-1-5-21-141845252-1443263951-584457872-1453
        gsid: NT:S-1-5-21-141845252-1443263951-584457872-1023
        nlink: 2; size: 0
        atime: Tue Aug 28 07:13:57 2007
        mtime: Tue Aug 28 07:13:57 2007
        ctime: Tue Aug 28 07:13:57 2007
        master replica dbid=3
        source pool=33 cleartext pool=35 derived pool=34
        crde=42
        <cropped>

      7. Найдите строку, которая содержит «crde =» и сравните с числом из шага 4. В данном примере это число «42» и это не тот каталог, который нам нужен.
      8. Повторите шаги 6 и 7, пока не найдете нужный каталог. В этом примере каталог компонента Comp2 с » crde = 46″.
      9. Переместите конкретный элемент в любой каталог в рамках структуры каталогов компонента. Вы должны сделать это из командной строки, изъять на редактирование каталог назначения и установить активность. Например:
        >cleartool lsactivity -cact -cview
        2008-09-24T07:43:58-04:00 20080924test mabushee «20080924test»>cleartool checkout -nco Comp2
        Checked out «Comp2» from version «\main\mra_EclipseTest\2».
        Attached activity:
        activity:20080924test@\Projects «20080924test»

        >cleartool move «lost+found\test.txt.3a99f3b26e9d43bb87e48b981708138c» Comp2\test.txt
        Moved «lost+found\test.txt.3a99f3b26e9d43bb87e48b981708138c» to «Comp2\test.txt».

      10. После выполнения шага 9 зарегистрируйте изменения Вашего целевого каталога.

      Если у вас есть дополнительные элементы в каталоге lost+found, необходимо повторить процедуру для каждого из них.

      Дополнительно

      Posted in ClearCase FAQ, IBM Rational | Отмечено: , , , | Leave a Comment »

      Сравнение концепции ClearQuest и Rational Team Concert

      Posted by Шамрай Александр на Сентябрь 14, 2010

      Оригинал: Comparing concepts between ClearQuest and RTC

      Основная терминология

      Давайте начнем с некоторых основных терминов и сравнения с ClearQuest. В ClearQuest у Вас есть понятие Тип записи. Типы записей определяют различные типы для записей, которые Вы можете иметь в ClearQuest. Они могут без состояний или с состояниями. Каждый Тип записи имеет несколько Полей, и эти Поля могут быть различных типов (например, перечисление, текст, числовой и т.д.). Поля могут быть обязательными или необязательными, и они часто используются, чтобы помочь классифицировать работы. Они также могут быть связаны друг с другом. Записи с состояниями используются для моделирования технологического процесса разработки ПО организации. Весь набор этих различных Типов записей, а также перечисляемые данные, используемые как значения для списков, представляют собой то, что обычно называют схемой ClearQuest. CQ схемы могут быть экспортированы и импортированы, но формат информации специализирован и является проприетарным. Когда пользователи взаимодействуют с системой, они создают CQ записи, которые являются экземплярами типов с данными, специфичными для некоторых запросов на изменение или выполняемой работы.

      В Rational Team Concert (RTC) у нас есть Шаблон процесса, который используется, чтобы устанавливать структуры и операции RTC. В RTC у нас есть Типы рабочих элементов, которые эквиваленты Типам записей в ClearQuest. Рабочий элемент всегда имеет связанную с ним модель состояний, тут не существует понятия типа без состояний. Рабочий элемент Jazz имеет Атрибуты, которые эквиваленты Полям в ClearQuest. Это все определяется в процессе, который используется проектом. Когда проект RTC инициируется, он использует Шаблон процесса для определения Типов рабочих элементов. Это определяет их модели Жизненного цикла и состояний, их Атрибуты, а также различные процессные операции, которые воздействуют на эти Рабочие элементы (об этом будет немного подробнее). Все это делается на основе пользовательского интерфейса по типу «указать и нажать». Выполненные выборки и конфигурации этого интерфейса хранятся в виде XML представления этого процесса. Это представление может быть использовано для создания новых Шаблонов процессов для других проектов. Когда пользователи взаимодействуют с системой, они создают Рабочие элементы, которые являются экземплярами типов с данных, специфичных для некоторых запросов на изменение или выполняемой работы.

      В ClearQuest Жизненный цикл можно охарактеризовать как ряд состояний. Отдельные переходы записей между этими состояниями выполняется с помощью ряда действий. В RTC понятия состояния и действия те же, действия используются для перехода между различными определенными состояниями. Но далее RTC и ClearQuest начинают немного отличаться. ClearQuest позволяет пользователям просматривать различные хранящиеся записи (данные) в виде отчетов, результатов запроса или диаграмм на основе результатов запроса. Форматы этих отчетов могут быть встроенными, поставляться вместе с продуктом, но часто настраиваются и определяются в Crystal Reports. RTC позволяет пользователям просматривать различные хранящиеся рабочие элементы (данные) в виде отчетов, результатов запроса или диаграмм на основе результатов запроса. Форматы отчетов могут быть встроенными, поставляться вместе с продуктом, но они настраиваются и определяются с помощью BIRT. Он также представляет эту информацию в виде Планов. План показывает Рабочие элементы (данные) в формате, который может использоваться для планирования и мониторинга хода спринта или итераций. Отдельные Планы могут быть представлены как окна на те же данные, но которые просто показывают их по-другому. Разница между отчетами и графиками является еще одним примером представления тех же данные в разных форматах.

      ClearQuest поддерживает историю переходов CQ записей, и большинство пользователей могут использовать возможности Audit Trail в ClearQuest. Данные и отчеты истории строятся с использованием данных из отдельных записей истории. В RTC Рабочие элементы имеют свою историю с полным отслеживанием изменения полей и состояний. Еще одно дополнительное свойство, RTC собирает эти данные в свое внутренние хранилище данных в разрезе времени, получая и накапливая данные из Рабочих элементов. Это хранилище данных используется для получения данных для всех ориентированных на время отчетов и графиков отображаемых в RTC. Таким образом, когда просматривается отчет за период времени (например, диаграммы выполнения работы), данные, которые отображаются, поступают из хранилища данных RTC. Это наиболее значительная разница между RTC и ClearQuest с точки зрения основных функции представления данных.

      Настройка процесса

      Итак, что можно сказать о настройке и бизнес-логике процесса? При использовании ClearQuest, пользователи более активно реализуют бизнес-логику на основе «Хуков» написанных в Perl или Visual Basic, Perl является более популярным. Хук связан с определенными событиями, которые происходят с CQ записью или с одним из его Полей. Существует широкий набор API вызовов, которые позволяют разработчику схемы выполнять различные операции для этих CQ записей и Полей. В RTC возможность изменить поведение Рабочих элементов и Атрибутов основывается на встраивании в модель безопасности (которую также можно настроить), а также существует ряд это общих операций, которые клиенты часто выполняют. Они представляются в виде набора операционного поведения и параметров, которые разработчик Шаблона процесса может изменять. Для тех вещей, которые еще не доступны в инструменте, разработчики Шаблон процесса могут писать расширения на любом языке, Java является наиболее популярным. Существует богатый API и SDK, с которыми можно взаимодействовать и использовать для манипулирования Рабочими элементами и их Атрибутами, например, показать руководство пользователя и сообщения об ошибках.

      Следующий выпуск RTC содержит дополнительную функциональность, которая должна закрыть некоторые пробелы между RTC и ClearQuest, а также предоставит дополнительные возможности. Вы можете прочитать об этом в разделах M4 New and Noteworthy и M7 New and Noteworthy.

      Небольшой обзор того, что было сказано:

      Концепт ClearQuest Эквивалент RTC Что оно делает
      CQ схемы Шаблон процесса Определяет процесс и как инструмент предоставляет процесс
      Жизненный цикл Жизненный цикл Модель состояний, которая определяет направления и переходы артефакта
      CQ тип записи Тип рабочего элемента Определяет тип объекта для хранения данных с его собственной моделью состояний, определенными полями, а также представлением данных
      CQ запись Рабочий элемент Экземпляр типа записи / типа рабочего элемента, с его собственными уникальными данными
      CQ поле Атрибут Одно из полей ввода данных, часть записи и рабочего элемента
      Хук Расширение Код, направленный на более гибкую реализацию
      CQ база данных Репозиторий Где хранится информация
      Не применимо Планы Различные представления или визуализация данных текущих рабочих элементов, полезных при планировании проектов

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

      Об авторе

      Daniel Toczala является Техническим лидером команды Jazz Jumpstart. Он работал в прошлом с Rational Services в качестве Senior Solutions Architect. Он использовал свой опыт в оказании помощи различным клиентам в осуществлении организационных изменений, чтобы помочь построить концепции шаблонов развертывания. Он сделал многочисленные презентации о том, как организации могут использовать технологий Jazz и Agile подходы в разработке программного обеспечения для повышения качественного результата, который организации по разработке ПО поставляют своим клиентам.

      Dan путешествует по миру, помогая клиентам IBM, но его дом в Нью-Хартфорд, штат Нью-Йорк. С ним можно связаться по dtoczala@us.ibm.com.

      Posted in ClearQuest, IBM Rational, Team Concert | Отмечено: , , , , | Leave a Comment »

      Локализация схем ClearQuest

      Posted by Шамрай Александр на Август 31, 2010

      << Перейти в раздел «ClearQuest FAQ»

      Для быстрой локализации схем в ClearQuest можно использовать утилиту cqload. Эта утилита позволяет установить новые значения для текста помощи полей и надписей полей на форме без использования дизайнера схем. Для этого есть специальные подкоманды (на момент публикации заметки еще не документируемы):

      • exporttranslations – для экспорта значений текста помощи и надписей формы.
      • Importtranslations – для импорта новых значений текста помощи и надписей формы.

      Пример

      Посмотрим на примере схемы ALM, как работает этот подход.

      • Исходные значения текста помощи и надписи на форме для поля ActivitiesRelated на английском языке

      • Экспортируем в отдельный файл описание всех значений с помощью утилиты cqload exporttranslations с параметрами:
        • [-dbset dbset_name] – наименование подключения, если отличается от значения по умолчанию
        • clearquest_login – логин пользователя с правами дизайнера схем
        • clearquest_password – пароль пользователя
        • schema_name – наименования схемы
        • notranslate_pathname – файл без перевода (оставляем пустым)
        • schema_pathname – файл, в который будут выгружены все значения для текста помощи и надписей на формах

      Пример:

      cqload exporttranslations -dbset alm_test admin «» ALM «» c:\temp\schema.txt

      • В результате работы утилиты будет файл следующего формата:

      • Добавим новые значения в файл экспорта. Для этого нужно добавить структуры <target>Новое значение</target> в структуру для поля <trans-unit>. Изменения должны вноситься в формате UTF-8

      • Импортируем новые значения для поля с помощью cqload exporttranslations с параметрами:
        • [-dbset dbset_name] – наименование подключения, если отличается от значения по умолчанию
        • clearquest_login – логин пользователя с правами дизайнера схем
        • clearquest_password – пароль пользователя
        • schema_name – наименования схемы
        • schema_pathname – файл, в котором находятся новые значения для текста помощи и надписей на формах

      Пример:

      cqload importtranslations -dbset alm_test admin «» ALM c:\temp\schema.txt

      • В результате работы утилиты будет создана версия для схемы и внесены новые значения для необходимых полей.

      Posted in ClearQuest FAQ, IBM Rational | Отмечено: , , , | Leave a Comment »

      Вложенные UCM Project VOB в ClearCase

      Posted by Шамрай Александр на Август 24, 2010

      Оригинал: Understanding Nested UCM Project VOB Environments

      Введение

      IBM ® Rational ® ClearCase ® Unified Unified Change Management (UCM) позволяет делать расширение с использованием ассоциации административных проектных VOB-ов (PVOB). В этом документе приводятся детали и передовой опыт для сред, которые реализуют структуру административных VOB-ов, которая включает использование нескольких PVOB-ов (вложенные PVOB). В этом документе также рассматриваются дополнительные варианты для среды ClearCase MultiSite. Документ не отображает всех возможных конфигураций с участием UCM PVOB в среде UCM.

      Этот документ предназначен для администраторов ClearCase UCM, ответственных за организацию конфигурации UCM.

      Прежде чем приступить вы должны иметь глубокое понимание общих концепций UCM, которые приведены в разделе Understanding UCM руководства IBM Rational ClearCase Managing Software Projects.

      Обзор

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

      В этом документе будет рассматриваться следующее:

      • Стандартная разработка с одним проектным UCM VOB-ом
      • Создание структуры вложенных проектных VOB-ов
        • Использование существующего проектного VOB-а в качестве административного VOB-а для дочерних проектных VOB-ов.
        • Использование общих административных VOB-ов для нескольких проектных VOB-ов
      • Использование ucmutil link_pvob
      • Среда MultiSite и общие проблемы, которые могут возникнуть

      Стандартная разработка с одним проектным UCM VOB-ом

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

      Ниже на рисунке отображена ассоциация проектного VOB-а и компонентного VOB-а для стандартного UCM. Рисунок отображает некоторые основные данные, сгенерированные в обоих VOB-ах, что более подробно раскрывается ниже.

      Стандартная UCM разработка предполагает, что элементы данных файл и каталог будут созданы в компонентном VOB-е. Каждая версия, сгенерированная в компонентном VOB-е, связывается с UCM активностью. Каждая сгенерированная версия должна быть связана с типом ветви ClearCase.

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

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

      Базовая линия UCM является объектом, созданным в рамках проектного VOB-а. Она связана с обычным типом метки, созданным в компонентном VOB-е. Тип метки применяется для единственной последней версии для каждого элемента в выбранной конфигурации. Как правило, эта конфигурация определяется потоком, в котором создается базовая линия.

      Создание структуры вложенных проектных VOB-ов

      Данный раздел описывает добавление нового проектного VOB-а в существующую среду разработки UCM. Новый проектный VOB не содержит существующих проектов или компонентов. Целью создания нового проектного VOB-а является объединение с существующей средой UCM. Если два или более проектных VOB-а связаны в общую административную иерархию VOB-ов, то это называется вложенной структурой проектных VOB-ов. Во вложенной структуре должен быть только один общий административный VOB. Все VOB-ы в административной иерархии VOB-ов должны указывать на один высокоуровневый VOB. На верхнем уровне административный VOB содержит объекты, необходимые для обеспечения создания распределенной UCM разработки.

      На данный момент есть два способа добавления нового проектного VOB-а в существующую среду UCM.

      • Добавить новый проектный VOB и выбрать любой проектный VOB (существующий или новый) в качестве единой административного VOB-а. Однако этот вариант не очень масштабируем. Эта конфигурация представляет риск разрастания одного проектного VOB-а. Это также увеличивает значимость существующего проектного VOB-а.

      Рисунок А.1

      • Добавить новый проектный VOB и новый общий административный VOB. Эта конфигурация становится масштабируемой и предусматривает равное значение для обоих проектных VOB-ов. Это помогает сохранить специфические объекты проектного VOB-а отдельно от общих глобальных метаданных, таких как тип ветви. Такая структура также будет держать метаданные организованными в общем административном VOB-е. Такая конфигурация потребует использования утилиты поставляемой в комплекте с ClearCase. Утилита называется «ucmutil» и далее о ней будет рассказываться более подробно.

      Рисунок А.2

      Использование ucmutil link_pvob

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

      • Передать все существующие глобальные определения типов ветви существующего проектного VOB-а в административный VOB
      • Переопределить ассоциацию всех существующих потоков с глобальными определениями типов ветви перемещенными в административный VOB
      • Перенаправить связи с административным VOB-ом любых соответствующих компонентных VOB-ов к новому административному VOB-у. Как вы можете видеть на рисунке выше, компонентный VOB теперь указывает на общий административный VOB, что является результатом запуска «ucmutil link_pvob». Необходимо также отметить, что ассоциации компонентов остаются с первоначальным проектным VOB-ом.

      Утилиту «ucmutil» можно найти в следующих каталогах:

      • Windows: %CLEARCASE_HOME%\etc\utils\ucmutil.exe
      • Linux/Unix: /opt/rational/clearcase/etc/utils/ucmutil

      Для более подробной информации об этой утилите смотрите Technote 1237620 About ucmutil.

      Примечание: В приведенном ниже примере вы должны установить свой путь к утилите ucmutil в переменную среды (или обеспечить полный путь к ucmutil) и установить контекст в представление для выполнения команд.

      Пример использования:

      ——————————————————————————————————————
      M:\adminView>ucmutil link_pvob -verbose -from vob:\pvobing -to vob:\commonAdminVOB
      Checking branch type ccrc_deliver.
      Checking branch type composite_Integration.
      Checking branch type deliver_Integration.
      Checking branch type william_child_deliver.
      Checking branch type william_child2_deliver.
      Checking branch type william_deliver.
      Total of 6 global branch types in VOB \pvobing.
      Total of 6 UCM branch types checked.
      M:\adminView>
      ——————————————————————————————————————

      Как можно увидеть в приведенном выше примере, подкоманда link_pvob будет находить все глобальные определения типа ветви для дочернего проектного VOB-а. Этот пример выполнен в -verbose (предварительном) режиме. Рекомендуется всегда использовать этот инструмент в режиме предварительного просмотра, перед тем как выполнить саму операцию. Также полезно перенаправить вывод команды в лог-файл для дальнейшего анализа. Эта команда необратима. После выполнения команды запуска с флагом «-fix «, гиперссылка административного VOB изменяется, и все метаданные изменяют структуру для представления иерархических изменений. Существуют некоторые проблемы, которые могут возникнуть в процессе проведения операции, поэтому инструмент проверяет, обеспечена ли блокировка VOB-а с ключом «-nuser». Только пользователь, выполняющий команду, должны быть в состоянии получить доступ к VOB-у при запуске операции «ucmutil link_pvob». Для этого вы должны заблокировать VOB с исключением пользователя, который запустил операцию, с ключом «-nuser».

      Пример блокировки проектного VOB-а с ключом «nuser»:

      ——————————————————————————————————————
      M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
      ucmutil: Error: VOB \pvobing should be locked with «-nuser» before running this tool.

      M:\adminView>cleartool lock -nuser DOMAIN1\william vob:\pvobing
      Locked versioned object base «\pvobing».

      M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
      ucmutil: Error: VOB \commonAdminVOB should be locked with «-nuser» before running this tool.

      M:\adminView>cleartool lock -nuser DOMAIN1\william vob:\commonAdminVOB
      Locked versioned object base «\commonAdminVOB».
      ——————————————————————————————————————

      В приведенном выше примере можно увидеть, что утилита проверяет блокировку обоих проектных VOB-ов. Она будет рекомендовать, чтобы вы заблокировали VOB с ключом -nuser.

      Напомним, что перед запуском ucmutil link_pvob с ключом -fix, вы должны выполнить следующие операции:

      1. Заблокировать проектные VOB-ы с ключом –nuser
      2. Выполнить ucmutil link_pvob –verbose и перенаправить вывод в лог-файл для дальнейшего анализа. (Это также может быть полезно для устранения неполадок)
      3. Убедитесь, что все типы ветвей, перечисленные в режиме предварительного просмотра, имеют локальную мастер реплику на сайте выполняющему операции. (Эта тема будет рассмотрена в разделе Среда MultiSite далее)
      4. Убедитесь, что все компонентные VOB-ы, связанные с дочерним проектным VOB, НЕ заблокированы. Блокировка компонентных VOB не даст утилите доступ и возможность изменить необходимые данные (Вы можете заблокировать компонентные VOB-ы с ключом -nuser при блокировке проектных VOB-ов, чтобы избежать проблем).

      Ниже приведен пример запуска утилиты для связывания проектного VOB-а «\pvobing» с общим административным VOB-ом «\commonAdminVOB»:

      Вот список метаданных перед операцией:

      1. Список глобальных типов ветвей в «\commonAdminVOB»
        M:\adminView>cleartool lstype -s -kind brtype -invob \commonAdminVOB
        main
      2. Список глобальных типов ветвей в «\pvobing»
        M:\adminView>cleartool lstype -s -kind brtype -invob \pvobing
        ccrc_deliver
        composite_Integration
        deliver_Integration
        main
        william_child_deliver
        william_child2_deliver
        william_deliver
      3. Список гиперссылок на административные VOB-ы для ассоциированных компонентных VOB-ов в «\pvobing»
        M:\adminView>cleartool describe -l -ahlink -all vob:\pvobing
        Hyperlinks:
        AdminVOB@42@\brokeComp <- vob:\brokeComp
        AdminVOB@42@\cvobing <- vob:\cvobing
      4. Пример ассоциации потоков UCM с глобальными типами ветвей перед связыванием двух проектных VOB-ов
        M:\adminView>cleartool describe -l -ahlink –all stream:deliver_Integration@\pvobing
        deliver_Integration
        Hyperlinks:
        IndependentGuard@306@\pvobing -> brtype:deliver_Integration@\pvobing
        UseBaseline@114@\pvobing -> baseline:cvobing_INITIAL@\pvobing
      5. Гиперссылка на административный VOB, указывающая из ассоциированного компонентного VOB-а
        M:\adminView>cleartool describe -l -ahlink -all vob:\cvobing
        \cvobing
        Hyperlinks:
        AdminVOB@42@\cvobing -> vob:\pvobing

      Пример выполнения команды связывания двух VOB-ов

      1. Выполнение команды в режиме предварительность просмотра с флагом –verbose и перенаправление вывода в лог-файл:
        M:\adminView>ucmutil link_pvob -verbose -from vob:\pvobing -to vob:\commonAdminVOB > c:\link_pvob_log.txt
      2. Запуск инструмента для создания связи между VOB-ами с флагом –fix:
        M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
        Checking branch type ccrc_deliver.
        Moving branch type ccrc_deliver.
        Checking branch type composite_Integration.
        Moving branch type composite_Integration.
        Checking branch type deliver_Integration.
        Moving branch type deliver_Integration.
        Checking branch type william_child_deliver.
        Moving branch type william_child_deliver.
        Checking branch type william_child2_deliver.
        Moving branch type william_child2_deliver.
        Checking branch type william_deliver.
        Moving branch type william_deliver.
        Reconnecting the moved global branch types.
        There is no global type in source VOB. Do you want to redirect the AdminVOB hyperlink? [no] yes
        Redirecting AdminVOB hyperlink.Total of 6 global branch types in VOB \pvobing.
        Total of 6 UCM branch types checked.
        Total of 6 UCM branch types moved.
        Total of 6 Stream hyperlinks reconnected.
        Total of 2 VOBs has been reconnected to new Admin VOB.

        M:\adminView>

      Ниже представлен список мигрированных и измененных метаданных как результат операции:

      1. Список глобальных типов ветвей, которые сейчас существуют в «\commonAdminVOB»
        M:\adminView>cleartool lstype -s -kind brtype -invob \commonAdminVOB
        ccrc_deliver
        composite_Integration
        deliver_Integration
        main
        william_child_deliver
        william_child2_deliver
        william_deliver

        (Заметьте, что все глобальные типы ветвей, которые до этого существовали в «\pvobing», мигрировали в «\commonAdminVOB»)

      2. Список гиперссылок Admin VOB в «\pvobing» после выполнения ucmutil link_pvob
        M:\adminView>cleartool desc -l -ahlink -all vob:\pvobing
        \pvobing
        Hyperlinks:
        AdminVOB@310@\pvobing -> vob:\commonAdminVOB(Заметьте, что гиперссылки Admin VOB для всех ассоциированных компонентных VOB-ах более не указывает на проектный VOB. Существует только гиперссылка Admin VOB, которая была создана утилитой ucmutil link_pvob)
      3. Пример ассоциации потоков UCM с глобальными типами ветвей после связывания двух проектных VOB-ов:
        M:\adminView>cleartool desc -l -ahlink -all stream:deliver_Integration@\pvobing
        deliver_Integration
        Hyperlinks:
        UseBaseline@114@\pvobing -> baseline:cvobing_INITIAL@\pvobing
        IndependentGuard@306@\pvobing -> brtype:deliver_Integration@\commonAdminVOB(Заметьте, что гиперссылка IndependentGuard сейчас указывает на глобальный тип ветви мигрированный в commonadministrativeVOB)
      4. Список гиперссылок Admin VOB в «commonAdminVOB» после работы утилиты ucmutil
        M:\adminView>cleartool desc -l -ahlink -all vob:\commonAdminVOB
        \commonAdminVOB
        Hyperlinks:
        AdminVOB@43@\brokeComp <- vob:\brokeComp
        AdminVOB@310@\pvobing <- vob:\pvobing
        AdminVOB@225@\cvobing <- vob:\cvobing(Заметьте, что гиперссылки Admin VOB, ранее указывающие на «\pvobing», теперь указывают на «\commonAdminVOB», который содержит все глобальные типы ветвей.)
      5. Измененная гиперссылка Admin VOB, указывающая из компонентного VOB-а ассоциированного с «\pvobing»
        M:\adminView>cleartool desc -l -ahlink -all vob:\cvobing
        \cvobing
        Hyperlinks:
        AdminVOB@225@\cvobing -> vob:\commonAdminVOB(Заметьте, что даже этот VOB, содержащий компонентные данные ассоциированные с «\pvobing», указывает на «\commonAdminVOB» для получения любых определений глобальных типов. )

      MultiSite среды и общие вопросы, которые могут возникнуть

      На данный момент мы рассмотрели, как работает утилита ucmutil link_pvob для создания вложенные структуры проектных VOB-ов, однако, мы не обсуждали то, что может произойти если VOB реплицирован в среде ClearCase MultiSite.

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

      Ниже приводится список проблем, которые могут возникнуть, если только некоторые из VOB-ов в структуре реплицируются на альтернативные сайты. Мы будем использовать структуру, показанную на вышеприведенных примерах. Если оба проектных VOB-а и связанные с ним компонентные VOB-ы были скопированы без единого административного VOB-а:

      1. Сайт реплики не будет иметь доступ к необходимым глобальным типам ветвей связанными с потоками UCM
      2. На сайте реплики, скорее всего, будет необходимость создания потоков. Потоки не будут иметь доступ к общему административному VOB-у, где находятся связанные с ними глобальные типы ветвей.
      3. Проектный VOB и компонентный VOB будут иметь неверные гиперссылки на административный VOB, указывающие на VOB, который не существует.
        ВАЖНО: Это очень опасно. Если «cleartool checkvob –ucm или -hlinks» исполняется для VOB-а, команда увидит поврежденные гиперссылки. Checkvob фактически удалит гиперссылки для исправления. Эта операция будет реплицирована на исходный сайт. Это нарушит структуру административного VOB-а на исходном сайте и вызовет катастрофу в производственной среде. Эта ошибка не произойдет, если все VOB-ы в структуре будут реплицироваться. Как альтернатива, при необходимости, можно блокировать тип гиперссылки AdminVOB для VOB-ов с ключом -nuser. Это запретит пользователям создавать и удалять гиперссылки AdminVOB.Пример:
        cleartool lock –nuser domain\user hlink:AdminVOB@\pvobing

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

      Перед запуском ucmutil link_pvob с флагом «-fix» в среде MultiSite, вы должны предусмотреть следующие.

      1. Убедитесь, что все доступные метаданные имеют мастер реплику сайта, на котором выполняется команда ucmutil.
      2. Запустите сначала программу с флагом «-verbose» и просмотрите список вовлеченных ветвей. Убедитесь, что все потоки связаны с этими типами ветвей имеют мастер реплику сайта, на котором выполняется команда. Используйте страницу помощи «cleartool chmaster» для изменения мастер реплики потока и всех его объектов.
      3. Просмотрите гиперссылки AdminVOB, связанные с существующим проектным VOB-ом, чтобы определить для каких VOB-ов должна быть установлена мастер реплика сайта, на котором выполняется команда. Гиперссылки AdminVOB связанные с каждым компонентным VOB-ом будут заново созданы, чтобы они указывали на новый связанный общий административный VOB.
      4. При запуске ucmutil link_pvob с флагом «-fix», сохраните результаты, т.к. они могут быть использованы для устранения ошибок, которые могут произойти. Для перенаправления вывода команды вы не можете быть в командной строке ucmutil. Вы должны набирать команду из контекста представления ClearCase. Вы должны отслеживать стандартные ошибки на стандартном устройстве вывода. Пример ниже покажет только стандартный поток вывода. Стандартные ошибки будут отображаться в окне командной строки.Пример:
        M:\adminView>ucmutil link_pvob –fix –from vob:\pvobing –to vob:\commonAdminVOB > c:\linkPvob_runLog.txt

      Заключение

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

      Ссылки

      IBM Rational ClearCase Managing Software Projects manual

      В тему статьи Using multiple PVOBs

      Posted in ClearCase | Отмечено: , , , , , , | Leave a Comment »

      Проблема создания базы данных ClearQuest на сервере MS SQL

      Posted by Шамрай Александр на Июль 6, 2010

      << Перейти в раздел «ClearQuest FAQ»

      При создании мастер или пользовательской базы данных с использованием сервера MS SQL возможны следующие ошибки:

      SQLExecDirect: RETCODE=-1, State=37000, Native Error=-3504
      SQL statement=’select from master_global’
      [Microsoft][ODBC Microsoft Access Driver]The SELECT statement includes a reserved word or an argument name that is misspelled or missing, or the punctuation is incorrect.

      или

      SQLExecDirect: RETCODE=-1, State=37000, Native Error=156
      SQL statement=»select from master_global»
      [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘from’.

      Причины этой проблемы могут следующие:

      1. Схема по умолчанию для сопоставляемой базы данных не совпадет с именем пользователя, от которого выполняется работа с базами данных ClearQuest на сервере MS SQL.
      2. Пользователь sa используется для подключения к базе данных.

      Решение:

      1. Для проблемы 1: Из MS SQL Management Studio перейти к свойствам пользователя используемого для подключения к базам данных MS SQL. В свойствах пользователя перейти к пункту Сопоставление пользователей и ввести в значение схемы по умолчанию наименование пользователя, под которым будет выполняться подключение.
      2. Для проблемы 2: Использовать для подключения к базам данных MS SQL отдельного пользователя (не sa). Разрешения, необходимые для этого пользователя смотрите в инструкции по установке.

      Источник: ERROR: ‘Incorrect syntax’ or ‘The SELECT statement includes a reserved word or an argument name’, when administering databases hosted on SQL Server 2005

      Posted in ClearQuest FAQ, IBM Rational | Отмечено: , , , , , , | Leave a Comment »

      Атомарный Check In для ClearCase

      Posted by Шамрай Александр на Июнь 29, 2010

      << Перейти в раздел «ClearCase FAQ»

      Начиная с версии IBM Rational ClearCase 7.1.1, поддерживается атомарная регистрация изменений в хранилище версий. Суть ее заключается в том, что если выполняется check in для группы файлов и для одного или нескольких файлов не могут быть созданы новые версии (например, не удовлетворяют внутренним политикам организации), то новые версии ни для одного из файлов не будут зарегистрированы (не будет выполнена операция check in).

      Для того чтоб атомарный check in поддерживался, его необходимо активировать для хранилища версий, т.к. по умолчанию он отключен. Для этого необходимо выполнить команду cleartool protectvob с опцией -atomic_checkin.

      >cleartool protectvob -atomic_checkin \TestVob

      VOB «\TestVob» set to enable atomic checkin.

      Ниже представлен пример использования атомарного check-in.

      Были изъяты на изменение два файла «n1.txt» и «n2.txt». Для первого файла были выполнены изменения, а второй остался без изменений. Для обоих файлов выполняется регистрация изменений с параметром –atomic. В результате оба файла остались в состоянии check out.

      >cleartool checkin -nc -atomic n1.txt n2.txt

      cleartool: Error: By default, won’t create version with data identical to predecessor.

      cleartool: Error: Unable to complete atomic checkin.

      Если внести изменения во второй файл и повторить операцию check in, то она успешно пройдет.

      >cleartool checkin -nc -atomic n1.txt n2.txt

      Checked in «n1.txt» version «\main\3».

      Checked in «n2.txt» version «\main\3».

      Posted in ClearCase FAQ, IBM Rational | Отмечено: , , , | Leave a Comment »

      Бесплатный семинар 15 июня 2010 года — «Программное обеспечение IBM Rational для улучшения процессов разработки и сопровождения ПО»

      Posted by Шамрай Александр на Июнь 7, 2010

      Компании СМ-Консалт, IBM, и ДНА приглашают Вас посетить бесплатный семинар по теме «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО» 15 июня 2010 года. На семинаре специалисты СМ-Консалт расскажут о технологиях  IBM Rational и поделятся практическим опытом использования и внедрения методологии Rational Unified Process. Также будут представлены отдельные решения СМ-Консалт, расширяющие функциональные характеристики IBM Rational.
      Количество мест ограничено. Преимущество имеют те, кто раньше зарегистрировался.
      Место проведения: г. Москва

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

      Управление процессами разработки и сопровождения информационных систем в IT-подразделениях становится критичным направлением развития крупных компаний. Семинар посвящен вопросам эффективного управления проектами и процессами разработки прикладного программного обеспечения на основе методологии и технологий IBM Rational.

      Регистрация на семинар бесплатная (ЗАРЕГИСТРИРОВАТЬСЯ), для участия в семинаре приглашаются руководители ИТ-подразделений и отделов разработки программного обеспечения, менеджеры, аналитики, архитекторы и ведущие разработчики проектов.

      В рамках семинара будут представлены доклады по следующим направлениям:

      • Экономический эффект от внедрения IBM Rational для компаний различного масштаба;
      • Улучшение процессов разработки и сопровождения за счет качественной постановки процессов;
      • Обзор инструментов и методологии IBM Rational: теория и практика внедрения.

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

      Программа семинара:

      Наименование доклада

      Докладчик
      9:30—10:00
      Регистрация участников, кофе
      10:00 —  10:05 Открытие семинара
      10:05 11:05 Решения IBM Rational на базе Software Delivery Platform и Jazz IBM. ДмитрийЛапыгин
      Rational Technical Specialist, IBM EE/A, SWG Department
      11:05 — 12:05 Методы оценки качества требований и работы аналитика СМ-Консалт и UML2.ru. Александр Байкин
      Главный специалист отдела внедрения
      12:05-12:15 Перерыв
      12:15 13:15 Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational.
      Практика внедрения и взаимодействия с заказчиком
      СМ-Консалт. Александр Новичков
      Руководитель отдела консалтинга
      13:10 — 14:15 Сессия вопросов-ответов. Перерыв
      14:15 — 15:15 Оригинальные решения СМ-Консалт, улучшающие функциональные характеристики инструментов IBM Rational. Демонстрация решений. Практические аспекты использования и внедрения. СМ-Консалт. Александр Шамрай
      Руководитель отдела перспективных разработок
      15:15 — 15:30 Сессия вопросов-ответов
      15:30 — 16:30 Контроль качества с использованием продуктов IBM Rational СМ-Консалт. Александр Шамрай
      Руководитель отдела перспективных разработок
      16:30 — … Сессия вопросов-ответов. Закрытие семинара. Вечерний чай.

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

      Место проведения: Москва, метро Таганская кольцевая, Большой Дровяной пер. 8 стр. 1, подьезд 3, этаж 4.
      Учебный центр «Международная академия профессиональных бухгалтеров»

      Адрес

      ЗАРЕГИСТРИРОВАТЬСЯ —>

      Организаторы семинара:

      Компания «СМ-Консалт» создана в 2004 году. Основные направления деятельности компании — консалтинг в области управления проектами, поддержка и внедрение технологий и инструментария IBM Rational. Поставка, настройка и последующее сопровождение программного обеспечения IBM Rational и Microsoft.«СМ-Консалт» входит в пятерку лидирующих консалтинговых компаний России, занимающихся внедрением IBM Rational.Сотрудниками компании проведено более 20 успешных проектов внедрения IBM Rational, обучено более 600 специалистов , как в России, так и в СНГ.
      «СМ-Консалт» является бизнес-партнером IBM и имеет статус Advanced IBM Partner.
      Основу компании составляют только сертифицированные профессионалы и эксперты, чей опыт и знания не вызывают сомнений.
      В числе клиентов «СМ-Консалт» такие крупные компании как: Банк Траст, Банк Русский Стандрат, Татнефть, ВнешТоргБанк, Иркутский Авиазавод, Русский Алюминий, ЗАО «АйТи» и многие другие.
      Компания DNA Trading (http://dna.ru ), официальный дистрибьютор программного обеспечения IBM в России и СНГ, работает на рынке информационных технологий с 1998 года.
      DNA Trading успешно реализует концепцию Value Added Distribution, предоставляя своим партнерам расширенный комплекс дополнительных сервисов. Организация обучающих семинаров и тренингов для партнеров — распространенная практика для компании. Ориентируясь на долгосрочные и взаимовыгодные отношения с партнерами, DNA Trading оперативно реагирует на возникающие запросы и активно участвует в развитии бизнеса своих партнеров.

      Posted in Новости, Семинары, IBM Rational | Отмечено: , , | Leave a Comment »

       
      %d такие блоггеры, как: