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

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

Archive for Ноябрь 2010

Руководство по управлению требованиями VS TFS 2010 – Контрольные списки для разработки требований

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

<<Содержание

  1. Планирование приемочного тестирования
  2. Оценка результатов приемочного тестирования
  3. Запросы на изменения
  4. Декомпозиция работ
  5. Рецензирование проектирования верхнего уровня
  6. Рецензирование детального проектирования
  7. Рецензирование документов
  8. Формальная проверка проекта
  9. Инспекция документации
  10. Приемка продукта
  11. Определение вех проекта
  12. Проверка требований
  13. Стиль требований
  14. Сценарии или процедуры тестирования
  15. Проектирование тестов
  16. Рецензирование плана тестирования
  17. План управления тестированием
  18. Рецензирование вариантов использования

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

Вопрос

1 Решались ли проблемы с предыдущими поставками от этого поставщика, которые могут быть включены при планировании этих приемочных тестов?
2 Определены методы проверки по каждому требованию (инспекции, анализ, демонстрации или тесты)?
3 Критерии принятия задокументированы?
4 Трассировка Требований обеспечена и все требования были учтены? (Пользовательские требования — процедура тестирования)
5 Задокументированы условия испытаний для каждой среды?
6 Определено и согласовано специальное оборудование для тестирования?
7 Если необходимо восстановление данных, то инструменты, оборудование и люди для этого определены и согласованы?
8 Есть ли люди с необходимой специализацией для проведения тестов и люди, которые имеют эту специализацию, согласованы?
9 Разработаны детальные пошаговые процедуры для каждого теста?
10 Если пользователь должен подтвердить процедуру для теста, сделал ли он это?
11 Если необходимо применение QA, запланированы ли работы для отдела QA?
12 Если пользователь (или заказчик) должен заверить тесты, это запланировано?
13 Есть ли ограничения тестирования или результатов тестирования со стороны поставщиков, которые говорят, что специальные тесты должны быть выполнены во время приемочных тестов? Если это так, они включены в план?
14 Были ли определены возможные аномалии тестирования вместе с условиями, при которых они могут возникнуть, и методы работы с ними?
15 Определены процессы работы с отклонениями от тестовых процедур?
16 Определен процесс работы с дефектами до их закрытия?
17 Процедуры и инструменты тестирования позволяют выполнять удобное регрессионное тестирование?
18 Есть ли согласованный процесс для хранения результатов тестирования, в том числе, ответственный за журнал тестирования?
19 Другое

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

Вопрос

1 Все тестовые процедуры выполнены?
2 Аномалии были проанализированы, чтобы подтвердить правильность тестов?
3 Тесты были проведены при надлежащих условиях?
4 Тесты были заверены соответствующими людьми?
5 Восстановление данных было выполнено и проверено соответствующими лицами?
6 Отклонения были проанализированы и адресованы соответствующим лицам?
7 Все необходимые повторные тесты были выполнены без ошибок?
8 Если продукт был изменен в период тестирования, соответствующие лица проверили изменения на необходимость регрессионного тестирования?
9 ПО правильно работает с ограничениями других систем или платформ?
10 Приемочные тесты демонстрируют адекватность пользовательской документации?
11 Приемочные тесты демонстрируют адекватность обучения поставщика?
12 Приемочные тесты демонстрируют все необходимые характеристики качества?
13 Другое

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

Вопрос

Информация, предоставляемая поставщиком Запроса на Изменение
1 Уникальный идентификатор для запроса
2 Дата запроса
3 Кто внес запрос?
4 Тип запроса (например, дефект, улучшение, проблема и т.д.)
5 Запрос для какого продукта?
6 Запрос для какой версии?
7 Во время какой фазы обнаружен? (например, сборка, тестирование, внедрение, эксплуатация и т.д.)
8 Описание запроса
9 Важность для пользователя (пользовательский приоритет и уровень важности)
10 Другие
Информация, заполняемая экспертом
11 Имя эксперта
12 Дата экспертизы
13 Описание экспертизы
14 Если это дефект, наименование части жизненного цикла, в которую дефект был вставлен.
15 Если это дефект, наименование части жизненного цикла, в которой дефект был обнаружен.
16 Описание исправления
17 Время на исправление
18 Основные причины
19 Влияние изменения (описать все применяемые области)
Влияние на размер
Влияние на границы
Влияние на бюджет
Влияние на разработку
Влияние на график
Влияние на качество
Другое влияние
20 Влияние, если не будет исправлено
21 Приоритет разработки (приоритет для разработчика)
22 Рекомендуемая реализация
23 Рекомендуемое распоряжение
24 Другое
Параметры отслеживания запроса
25 Состояние запроса (например, открыт, на экспертизе, утвержден/отклонен, в процессе, завершен, закрыт и т.д.)
25 Дата утверждения/отклонения
25 Кем утвержден
25 Дата завершения
25 Дата закрытия
25 Кем закрыт
25 Другое

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

Вопрос

1 Все работы представлены в плане?
2 Каждый рабочий элемент связан с одной задачей в плане?
3 Каждая задача имеет определенные критерии окончания?
4 Каждая задача имеет единственный связанный рабочий элемент?
5 Каждая задача требует небольшое количество людей для реализации?
6 Каждая задача настолько мала, что позволяет быстро обнаружить проблему для ее быстрого исправления?
7 Декомпозиция задач уточняется при выполнении проекта?
8 Задачи были декомпозированы корректно?
Элементы нижнего уровня необходимы и достаточны для выполнения декомпозируемого элемента? Если нет, составные элементы должны быть модифицированы (добавлены к, удалены из или пересмотрены).
Каждый элемент четко и полностью определен? Если нет, то описания должны быть модифицированы или расширены.
Возможно ли на каждый элемент надлежащим образом определены плановые сроки и бюджет? Возможно ли на каждый элемент соответствующим образом назначить специальную организационную единицу (например, отдел, группа или лицо), которая будет нести ответственность за удовлетворительное завершение этого элемента? Если нет, то необходимо внести изменения, чтобы обеспечить адекватный контроль для управления.
9 Элементы декомпозиции часто забываются
Верификация и валидация включены?
Управление проектом и администрирование включены?
Анализ обеспечения качества включен?
Управление конфигурациями включено?
Документация (руководства, процедуры) включены?
Разработка тренингов и тренинги включены?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует стандартам организации?
2 Стандарты Целевая аудитория определена?
Полнота и корректность
3 Неполный Все элементы проекта верхнего уровня включены?
4 Неполный Все предложения проектирования включены в спецификацию?
5 Некорректный Документ не имеет фактических ошибок?
6 Неполный Основные альтернативные пути и их оценки представлены? Компромиссные проекты и критерии выбора задокументированы?
7 Неполный Критерии или условия, необходимые для разработки эффективного решения, адекватно описаны? Разумны ли они?
8 Неполный Проект отражает действительную операционную среду, аппаратное и программное обеспечение?
9 Неполный Вопросы производительности затронуты?
10 Неполный Все возможные состояния и сценарии рассмотрены?
11 Неполный Требования к хранению данных определены?
12 Неполный Проект описывает обнаружение ошибок и восстановление?
13 Неполный Есть ли модель пользовательского интерфейса?
14 Неполный Есть ли модели для других интерфейсов?
15 Неполный Количество и сложность интерфейсов задокументированы?
16 Неполный Есть ли функциональная модель высокого уровня?
17 Неполный Есть ли концептуальное представление для всех составных элементов данных?
18 Неполный Управление и использование общих данных описано?
Последовательность и прозрачность
19 Неоднозначный Документ имеет неоднозначные и слова, имеющие различные варианты интерпретации?
20 Непоследовательный Документ последователен между своими компонентами?
21 Неоднозначный Границы и ограничения проекта ясны, и в документе четко указано, какие функции будут (и не будут) обеспечены и какие ожидания будут (и не будут) удовлетворены?
22 Неоднозначный Существуют ли ограничения и последствия, если таковые имеются, в этом решении ясно описано?
23 Непроверяемый Может проект быть поэтапно протестирован и интегрирован?
24 Непоследовательный Проект соответствует установленным бизнес практикам и стандартам?
Трассируемость
25 Другое — Трассируемость Проект имеет связь с требованиями?
26 Другое — Трассируемость Требования имеют связь с проектом?
Интерфейсы
27 Другое – Качество Дизайна Документ удовлетворяет потребности аудитории?
28 Другое – Качество Дизайна Проект адаптивен к будущим изменениям?
29 Другое – Качество Дизайна Проект модульный?
30 Другое – Качество Дизайна Модули имеют сильное зацепление и слабую связанность?
31 Другое – Качество Дизайна Проект отражает систему, которую просто поддерживать?
32 Другое – Качество Дизайна Есть разумные доводы того, что люди, которые разработали проект, задали правильные вопросы и действительно поняли потребности и проблемы клиентов?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует организационным стандартам?
2 Стандарты Документ прост в использовании и поддержке?
Полнота и корректность
3 Неполный Все компоненты или интерфейсы, которые необходимы для этой части архитектуры системы, выявлены и полны?
4 Неполный Каждый компонент проектной спецификации внутренне полон? Это задокументировано адекватно?
Последовательность и прозрачность
5 Непроверяемый Каждый элемент дизайна тестируемый или как-то иначе проверяемый?
6 Непроверяемый Каждый элемент может быть протестирован, продемонстрирован или проанализирован на соответствие требованиям и, следовательно, проверен?
7 Непоследовательный Детализируемые компоненты и их интерфейсы согласованы с друг с другом?
8 Непоследовательный Спецификация каждого компонента последовательна внутри?
Данные
9 Данные Все внутренние данные, которые необходимы для каждого компонента, определены?
10 Данные Все элементы данных имеют наименование и используются согласовано в проекте?
11 Данные Все внешнее использование общих данных идентифицировано?
12 Данные Все внешнее использование общих данных определено?
13 Данные Существуют какие-либо конфликтные использования данных?
14 Данные Переменные инициализируются и их значения проверяются перед использованием?
Интерфейсы
15 Интерфейс Детальный проект связан с проектом высокого уровня?

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

Тип дефекта

Вопрос

Организация и структура документации
1 Стандарты Цели документа определены?
2 Стандарты Технический уровень соответствует выбранной аудитории и целям?
3 Стандарты Формат документа последователен?
4 Стандарты Документ отвечает стандартам документации?
5 Стандарты Организация документа способствует простому поиску информации?
Полнота и корректность
6 Неполный Все фазы жизненного цикла документа были пройдены?
7 Неполный Отзывы пользователей были получены?
8 Неполный Адекватны ли условия для поставки документации и последующих изменений?
9 Неполный Все содержание документа адекватно?
10 Неполный Все важные темы присутствуют?
11 Некорректный Документация не имеет актуальных ошибок?
12 Неполный Есть ли глоссарий, если необходимо? Он полон?
13 Некорректный Определения верны?
14 Неполный Есть ли лист содержания, если необходимо?
15 Некорректный Лист содержания корректный и легкодоступен?
16 Неполный Разделы руководства включены, если необходимо?
17 Некорректный Примеры, диаграммы, рисунки и другие визуальные материалы корректны?
18 Неполный Есть ли индекс, если необходимо? Он легкодоступен?
19 Неполный Индекс адекватно детализирован
20 Некорректный Номера страниц в индексе совпадают?
21 Неполный Все ли элементы, которые могут искать различные пользователи, включены в индекс?
Последовательность и прозрачность
22 Неоднозначный Цели документа четко определены?
23 Непоследовательный В документе отсутствуют противоречия?
24 Неоднозначный Верна ли терминология? Она соответствует аудитории и целям?
25 Непоследовательный Терминология непротиворечива в документе?
26 Неоднозначный Стиль написания понятен? Отдельные параграфы отражают только одну мысль или связанные мысли?
27 Неоднозначный Примеры, диаграммы, рисунки и другие визуальные материалы понятны?
28 Непоследовательный Примеры, диаграммы, рисунки и другие визуальные материалы необходимы и относятся к тому месту, где используются?
29 Непоследовательный Индексы находятся под правильными разделами?

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

Вопрос

Статическая документация
1 Описание проекта (назначение, границы и цели)
2 Основные заинтересованные лица, включая спонсоров
3 Основные поставки, включая бизнес цели и выгоду
4 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
5 Команда проекта
Промежуточная версия документации
6 Описание проекта (назначение/границы/цели)
7 Основные заинтересованные лица, включая спонсоров
8 Основные поставки, включая бизнес цели и выгоду
9 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
10 Команда проекта
Документация по рискам
11 Основные проблемы и вопросы
12 Основные риски
13 Основные зависимости, особенно которые в ожидании или в риске
Планируемая на последующие шаги документация
14 Основные промежуточные корректировки, связанные с требованиями, кадровым обеспечением и зависимостью изменений
15 Основной план рисков (стратегия снижения и план последствий)
16 Следующие шаги
17 Запрос помощи от исполнителей, если требуется
18 Специализированная отчетность только по этому проекту (добавление любых необходимых отчетов для последующего использования)

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

Тип дефекта

Вопрос

1 Прозрачность Некоторые элементы документа сложны восприятия или весь документ сложно читать.
2 Полнота Некоторые необходимые компоненты пропущены.
3 Сложность Некоторые части документа необходимо упростить для целевой аудитории.
4 Последовательность Некоторые части документа конфликтуют с другими связанными документами.
5 Корректность Документ имеет ошибки.
6 Определение Определения пропущены, ошибочны или лишние.
7 Формат Документ не соответствует предопределенному формату организации для этого типа документа.
8 Грамматика Присутствуют грамматические ошибки в документе
9 Организация Порядок, в котором представлен документ, неудобен и неэффективен.
11 Излишество Некоторые части документа избыточны и не соответствуют целям документа.
12 Пунктуация Присутствуют несоответствия в пунктуации и выделениях в документе.
13 Стандарты Документ не соответствует стандарту документации для этого типа документа.
14 Стиль Документ в некоторых моментах не соответствует руководству организации по стилям документации.
15 Версия Нигде нет информации о версии или она не соответствует стандартам организации.

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

Вопрос

1 Результаты приемочных тестов проанализированы?
2 Поставляемые материалы соответствуют всем функциональным требованиям?
3 Поставляемые материалы соответствуют всем требованиям к продукту?
4 Готова ли документация по эксплуатации?
5 Соответствующие люди проверили и утвердили документацию (заказчик, покупатель и поставщик)?
6 Документация соответствует конечному продукту?
7 Информация о релизе описывает дефекты и методы их обхода?
8 Если существуют требования обязывающие принять продукт «как есть», соответствующие документы были оформлены и утверждены?
9 Все ли поставки, описанные в контракте, были предоставлены поставщиком?
10 Все ли поставки, описанные в контракте, были обновлены до последней версии?
11 Описаны ли процедуры обработки ошибок после поставки продукта?
12 Если предусмотрено контрактом, программное обеспечение и другие необходимые артефакты были помещены под условное хранение?
13 Если продукт будет поддерживаться поставщиком, существует ли соответствующие последующее соглашение, которое позволяет закрыть текущее соглашение?
14 Все ли нерешенные вопросы, связанные с продуктом или контрактом, были обработаны и закрыты?
15 Другое

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

Вопрос

Документ Границы Проекта на достаточном уровне описывает, что проект должен достичь и в какой среде? Следующие пункты должны быть определены:
1 Общие Границы Проекта
2 Элементы вне границ
3 Бизнес Цели/Потребности
4 Бизнес и Технические Ограничения
5 Разделы по Изменениям в Бизнес Процессе/Получение Подтверждения Изменений
6 Основные Интерфейсы/Интеграционные Требования
7 Основные Системные Возможности и Функции с указанными потенциальными релизами продукта
8 Затрагиваемые Организации и Подразделения
Альтернативы Продукта определены и рассмотрены? Компоненты могут включать:
9 Технико-экономическое обоснование
10 Оценка Альтернативных Решений (включая существующие приложения и/или компоненты)
11 Потенциальные Продукты Поставщика
12 Анализ необходимости Покупки или Разработки
Условия Развертывания были задокументированы и рассмотрены соответствующими участниками?
13 Все основные вопросы, поступившие от рецензентов, были решены?
План проекта это включает?
14 Высокоуровневую оценку по стоимости и трудозатратам для всего проекта
15 Детальную оценку стоимости трудозатрат, стоимости, плана и планируемых трудовых ресурсов для фазы Анализа
16 Предлагаемый жизненный цикл
17 Проектные роли и ответственности
18 Начальный набор проектных рисков и планы снижения
Анализ оценки рентабельности выполнен?
19 Какой приоритет у проекта по сравнению с другими проектами, которые находятся в очереди ожидающих разработку проектов?

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

Тип дефекта

Вопрос

Организация и структура документа
1 Стандарты Соответствующие стандарты документирования требований выдержаны?
2 Стандарты Все рисунки, таблицы и диаграммы подписаны и имеют ссылку?
3 Стандарты Все термины и единицы измерений определены?
4 Стандарты Все требования описаны последовательно и на соответствующем уровне детализации?
5 Стандарты Отдельные требования имеют ранг с описанием установленного приоритета?
6 Непроверяемое Требования обеспечивают адекватный базис для разработки и системного тестирования?
Полнота и корректность
7 Корректность Все ли внутренние перекрестные связи с другими требованиями корректны? (Для модифируемости минимизируйте перекрестные связи)
8 Неполное Все классы пользователей описаны? Все пользовательские характеристики описаны?
9 Неполное Спецификация включает все известные потребности заказчика или системы? Все ли задачи, которые необходимо выполнять пользователям, указаны?
10 Неполное Каждое функциональное требование описывает вход, выход и функцию, если это необходимо?
11 Неполное Все зависимости от других систем определены? Включены другие приложения или интерфейсы приложений, базы данных, связующие подсистемы, сеть и т.д.
12 Неполное Требования к документации и обучению определены?
13 Неполное Аппаратная и программная среда указана?
14 Неполное Все поставляемые требования были включены? Здесь включаются те, которые подразумевают системные и программные требования, которые в основном ограничивают разработку или верификациию.
15 Неполное Полный жизненный цикл определен, включая поддержку?
16 Неполное Какие либо ограничения разработки и реализации описаны?
17 Неполное Все требования к надежности, восстанавливаемости (непрерывности бизнеса) и производительности правильно указаны??
18 Неполное Все требования к безопасности правильно указаны?
19 Неполное Все требования к защищенности правильно указаны?
20 Неполное Все требования к конфиденциальности данных указаны?
21 Неполное Определены ли критичные ко времени/длительности функции, и критерии определения времени указаны для них?
22 Неполное Нормативные, законодательные и требования на основе стандартов были указаны?
23 Неполное Все атрибуты (характеристики) качества были правильно указаны (например, эффективность, гибкость, совместимость, возможность поддержки, мобильность, возможность многократного использования, удобство и доступность)?
24 Неполное Требования к непрерывности бизнес процесса и восстановлению после сбоев были учтены?
25 Интерфейс Требования к интерфейсам взаимодействия с пользователем были учтены? Они корректны?
26 Интерфейс Все внешние аппаратные, программные и коммуникационные интерфейсы определены? Они корректны?
Последовательность и прозрачность
27 Противоречивое Спецификация согласуется с соответствующими документами верхнего уровня?
28 Противоречивое Требования имеют дубликаты или конфликты с другими требованиями?
29 Противоречивое Все требования написаны последовательно, понятно и лаконично?
30 Неоднозначное Каждое требование имеет только одну интерпретацию? Если термины имеют несколько значений, это указано?
31 Непроверяемое Каждое требование может быть проверено через тест, демонстрацию, рецензию или анализ?
32 Непроверяемое Существуют измеряемые критерии приемки для каждого функционального или нефункционального требования?
Трассируемость
33 Интерфейс Каждое требование уникально и корректно идентифицировано?
34 Интерфейс Каждое требование имеет связь с его источником (включая производные требования)?
35 Другое Каждое требования в границах проекта?

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

Вопрос

1 Каждое требование должно включать слова должно быть или должно.
2 Каждое требование должно быть написано в кратком предложении и с использованием простых терминов.
3 Каждое предложение должно включать только одно требование.
4 Каждое требование должно четко совпадать с содержанием, приведенным в предложении.
5 Обобщающие термины (такие как все, каждый, никогда и всегда) не должны использоваться в требованиях, если требование должно быть проверяемым.
6 Неопределенные термины (такие как будет определено в дальнейшем, будет описано в дальнейшем и т.д.) не должны использоваться в требованиях, кроме случаев, когда будут выполнены согласования и утверждения для каждого такого термина.
7 Каждое требование должно быть написано в утвердительной форме.
8 Каждое требование должно быть грамматически правильным.
9 Объединение И показывает, что все элементы в требовании должны быть в значении «истина», чтоб удовлетворять назначению требования.
10 Каждое требование, которое включает объединение ИЛИ должно четко показывать где «включаемое или» или «исключаемое или». «Включаемое или» позволяет одному или обеим альтернативам быть в значении «истина», а «исключаемое или» позволяет только одной альтернативе быть в значении «истина».
11 Использование косой черты , например, и/или или проводник/земля не должны использоваться в требованиях.
12 Каждое требование должно быть в границах проекта.
13 Термины и сокращения должны быть определены в глоссарии, списке или в тексте.

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение сценариев тестирования и процедур тестирования?
2 Стандарты Люди, которые разрабатывают тестовые сценарии или процедуры, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Когда выполняется оценка всего пакета тестов, сценарии или процедур тестирования охватывают все типы необходимых тестов (например, тестирование функциональности приложения, тестирование производительности, тестирование удобства использования, тестирование на нескольких платформах, он-лайн помощи, тестирование документации пользователя и т.д.)
5 Неполный В каждом тесте полностью указаны все необходимые входные параметры, альтернативные пути и ожидаемый результат?
6 Другое Отдельные тесты возможны и выполнимы?
7 Неполный Описание целей каждого теста полное?
8 Другое Описание целей каждого теста точное?
9 Неполный Ожидаемый результат для каждого шага каждого теста описан, даже если входные параметры вне требуемого диапазона?
10 Неполный Тестовые сценарии демонстрируют реакцию системы на неправильные или конфликтующие входные параметры?
11 Неполный Зависимости тестовых процедур идентифицированы?
12 Неполный Каждая процедура тестирования определяет предшествование вовлеченных тестов?
Последовательность и прозрачность
13 Другое Пользовательские инструкции подробны и понятны для выполнения каждого тестового сценария?
14 Другое Инструкции для каждого теста представляют пошаговое и упорядоченное выполнение?
15 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?
16 Противоречивый Глубина и основательность тестирования (т.е. процент детального покрытия, которые обеспечивает тест) для каждой возможности совпадает с операционным профилем этой возможности?
17 Противоречивый Величина функционального покрытия соответствует рискам продукта?
18 Противоречивый Процедуры тестирования совместимы с возможностями средств тестирования?
Трассируемость
19 Интерфейс Тестовые сценарии обратно связанны с требованиями?
20 Интерфейс Есть ли перекрестная связь между сценариями тестирования и тестируемыми возможностями?

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение?
2 Стандарты Люди, которые разрабатывают тесты, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Границы проекта тестирования охватывают все типы тестов, которые необходимы, как указано в плане тестирования?
5 Неполный Проект тестирования включает методы определения ответа системы на неправильные и конфликтующие входные параметры?
6 Неполный Проект тестирования содержит критерии успешного выполнения или провала теста для каждой тестируемой возможности
7 Неполный Все ли поддерживаемые тестовые сценарии перечислены в спецификации проекта тестирования?
8 Неполный Каждый перечисленный тестовый сценарий имеет процедуры, определяющие его использование?
Последовательность и прозрачность
9 Противоречивый Глубина и основательность методов тестирования для каждой возможности совпадает с операционным профилем этой возможности?
10 Непонятный Критерии для теста «успешен-провален» понятны и однозначны?
11 Противоречивый Элементы, которые будут тестироваться, непротиворечивы с тестируемыми возможностями?
12 Противоречивый Величина функционального покрытия соответствует рискам продукта?
13 Противоречивый Возможности (или комбинация возможностей), которые будут тестироваться в этом проекте, совпадают с теми, которые были указаны в плане тестирования для этого теста?
14 Противоречивый Все тестовые элементы этого проекта тестирования соответствуют тем, которые идентифицированы в плане или планах тестирования?
15 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, с одним или более описанием требований или дизайна?
16 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, со всеми связанными описаниями требований или дизайна?

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты План тестирования соответствует шаблону плана тестирования или каким-то другим стандартам?
2 Стандарты Существуют ли перекрестные ссылки между планом тестирования и планом проекта для проекта, продукт которого будет тестироваться?
3 Стандарты Все ли заинтересованные лица вовлечены в разработку и утверждение плана тестирования?
Полнота и корректность
4 Неполный План определяет, что нужно тестировать и что не нужно тестировать?
5 Неполный План определяет критерии приемки?
6 Неполный Результирующие артефакты тестирования определены в плане?
7 Неполный Стратегия тестирования явно описана?
8 Неполный Все необходимые фазы тестирования указаны в плане тестирования?
8 Неполный План описывает ресурсы необходимые для выполнения плана?
9 Неполный Ресурсы назначены рационально по объему, доступности и уровню?
10 Неполный Риски, связанные с качеством продукта, определены в плане тестирования?
11 Неполный План содержит мероприятия по управлению рисками?
Последовательность и прозрачность
12 Противоречивый Заданные границы трассируются с требованиями к продукту?
13 Противоречивый Если некоторые возможности не тестируются или тестируются незначительно, это оправдано?
14 Противоречивый Если тест для нового релиза или обновления существующей системы, регрессионное тестирование не противоречит этой частной ситуации?
15 Противоречивый Логистика соответствует стратегии и ресурсам, определенным в плане?
16 Противоречивый Планируемый объем работ по тестированию пропорционален объему трудозатрат разработки и поддержки проекта?
Элементы, связанные с План Управления Тестированием
Полнота и корректность
17 Неполный План тестирования определяет критические факторы успешности продукта?
18 Неполный Документ явно определяет пользовательские (заказчика) критерии приемочного тестирования?
19 Неполный Общие цели тестирования явно определены?
20 Неполный План включает мероприятия по обеспечению качества для работ по тестированию?
21 Неполный План включает или ссылается на процессы управления конфигурацией?
22 Неполный План включает описание организации команды тестирования, включая структуру отчетности?
23 Неполный План явно идентифицирует какие фазы и цели тестирования должны быть выполнены?
24 Неполный Если тест для нового релиза или обновления существующей системы, опыт взаимодействия с системой и ее история предыдущих ошибок отражена в плане для тестовых сценариев?
Элементы, связанные с Детальным Планом Тестирования
Полнота и корректность
25 Неполный Задачи тестирования указаны в плане тестирования?
26 Неполный План описывает инструменты, которые должны использоваться для тестирования продукта?
27 Неполный План обучения инструментам (если необходимо) оговариваются планом?
28 Неполный Задачи по подготовке среды тестирования включены в план?
Последовательность и прозрачность
29 Противоречивый Глубина и основательность тестирования (например, процент детального покрытия, которые обеспечивает тест) совпадает с рисками продукта?
30 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?

План управления тестированием
Предполагаемое использование списка Для команды тестирования при оценке их программных (или системных) планов тестирования для определения или соответствующие элементы покрыты.
ID

Вопрос

1 План тестирования соответствует общему плану проекта?
2 Главные функции запланированы для тестирования на ранних стадиях цикла тестирования?
3 График тестирования явно определен?
4 Ресурсы тестирования (свободное место, оборудование и персонал) уже доступны или планируется их доступность, когда это необходимо?
5 Инструменты тестирования уже доступны или они будут доступны, когда будет необходимо?
6 Механизм хранения результатов тестирования установлен?
7 Все соответствующие фазы тестирования, роли и ответственности в плане установлены (тесты модульные, системные, альфа, беты, приемочные и т.д.)?
8 Если необходимо, указаны и запланированы тесты по миграции данных, больших объемов данных, нагрузочному и стрессовому тестированию?
9 Если необходимо, производительность будет выполняться согласно спецификации продукта?
10 Все требования тестирования, которые указаны в документе по требованиям, затронуты?
11 Критерии приемки для продукта были определены?
12 Риски для плана тестирования определены, и планы смягчения разработаны?
13 Существует ли планы реакции для рисков, которые могут осуществиться?
14 Мероприятия по управлению рисками отслеживаемы?
15 Есть ли полный список того, что не будет тестироваться?
16 Другое

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Вариант использования самостоятельная, дискретная задача?
2 Стандарты Вариант использования написан на необходимом уровне, а не как конкретные сценарии?
3 Стандарты Вариант использования не имеет описания разработки или реализации?
4 Стандарты Вариант использования ограничен 10 шагами или менее?
5 Стандарты Варианты использования именуются фразой в виде глагола целевого действия, что указывает на цель основного актора?
Полнота и корректность
6 Неполный Цели всех акторов затронуты?
7 Неполный Все акторы представлены (прямо или косвенно)?
8 Неполный Все ожидаемые альтернативные варианты задокументированы?
9 Неполный Все известные условия исключений задокументированы?
10 Неполный Последовательности диалога для каждого курса полны?
11 Некорректный Главный актор в каждом варианте использования подходит для выполнения этой задачи?
12 Некорректный Описанный курс в варианте использования выполним?
13 Некорректный Каждый шаг в варианте использования подходит для достижения цели варианта использования?
14 Некорректный У основного актора есть верное поведение?
Последовательность и прозрачность
15 Неоднозначный Цели или измеряемое значение варианта использования понятны?
16 Неоднозначный Понятно какой атор или акторы получают выгоду от варианта использования?
17 Неоднозначный Всевозможные общие последовательности действий были заложены в отдельные варианты использования?
18 Неоднозначный Последовательность диалога для каждого курса описана понятно и однозначно?
19 Непроверяемый Каждый курс, описанный в варианте использования, проверяем?
Реклама

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , | 1 Comment »

CMMI DEV v1.3 – Управление Конфигурацией

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

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

Процессная область Поддержки уровня зрелости 2

Назначение

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

Вступительный комментарий

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

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

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

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

  • Аппаратное обеспечение и техника
  • Рисунки
  • Спецификации продукта
  • Конфигурации инструмента
  • Код и библиотеки
  • Компиляторы
  • Средства тестирования и тестовые сценарии
  • Журнал инсталляции
  • Файлы данных продукта
  • Технические публикации продукта
  • Планы
  • Пользовательские истории
  • Журнал итерации
  • Описание процесса
  • Требования
  • Архитектурная документация и дизайн
  • Планы линейки продукта, процессов и основные активы

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

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

Управление конфигурациями для рабочих продуктов может применяться на нескольких уровнях декомпозиции. Элементы конфигурации могут быть декомпозированы на компоненты конфигурации и единицы конфигурации. В этом процессе используется только один термин – «элемент конфигурации». Поэтому в этих практиках «элемент конфигурации» в некоторых случаях может интерпретироваться как «компонент конфигурации» или «единица конфигурации». (См. определение «элемент конфигурации» в глоссарии.)

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

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

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

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

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

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

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

В среде Agile, управление конфигурацией (УК) имеет важное значение в связи с необходимостью поддерживать частые изменения, частые сборки (как правило, ежедневные), несколько базовых линий и несколько рабочих пространств УК (например, для отдельных лиц, групп и даже для парного программирования). Agile команда может увязнуть, если организация не будет: 1) автоматизировать УК (например, скрипты сборки, учет состояния, проверку целостности) и 2) представлять УК как единый набор стандартных сервисов. В самом начале, команда Agile должна определить человека, который будет отвечать за обеспечение правильности реализации УК. В начале каждой итерации выполняется подтверждение целей УК. УК максимально интегрировано в ритмы каждой команды и сфокусировано на минимизацию отвлечения команды при выполнении работ. (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессы

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

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

Перечень специальных целей и практик

  • СЦ 1 Установить Базовые Линии
    • СП 1.1 Идентифицируйте Элементы Конфигурации
    • СП 1.2 Установите Систему Управления Конфигурациями
    • СП 1.3 Создавайте или Выпускайте Базовые Линии
  • СЦ 2 Отслеживать и Контролировать Изменения
    • СП 2.1 Отслеживайте Изменения
    • СП 2.2 Контролируйте Элементы Конфигурации
  • СЦ 3 Установить Целостность
    • СЦ 3.1 Установите Записи Управления Конфигурацией
    • СЦ 3.2 Выполняйте Аудит Конфигурации

Специальные практики по целям

СЦ 1     Установить Базовые Линии

Базовые линии идентифицированных рабочих продуктов установлены

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

СП 1.1 Идентифицируйте Элементы Конфигурации

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

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

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

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

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

Пример рабочих продуктов

1. Идентифицированные элементы конфигурации

Подпрактики

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

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

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

Примеры рабочие продуктов, которые могут быть частью элемента конфигурации:

  • Технический проект
  • Планы и процедуры тестирования
  • Результаты тестирования
  • Описание интерфейса
  • Рисунки
  • Исходный код
  • Пользовательские истории или карты историй
  • Задекларированные бизнес сценарии, бизнес логика или значение для бизнеса
  • Инструменты (например, компиляторы)
  • Описание процесса
  • Требования

2. Назначьте уникальные идентификаторы для элементов конфигурации.

3. Опишите важные характеристики каждого элемента конфигурации.

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

4. Опишите когда каждый элемент конфигурации был помещен под управление конфигурацией.

Пример критериев для определения, когда рабочий продукт может быть помещен под управление конфигурацией:

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

5. Определите владельца ответственного за каждый элемент конфигурации.

6. Укажите взаимосвязь между элементами конфигурации.

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

СП 1.2 Установите Систему Управления Конфигурациями

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

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

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

Пример рабочих продуктов

1. Система управления конфигурациями с контролируемыми рабочими продуктами

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

3. База данных запросов на изменение

Подпрактики

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

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

Пример уровней управления:

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

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

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

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

4. Совместно используйте и передавайте элементы конфигурации между уровнями контроля в системе управления конфигурацией.

5. Храните и восстанавливайте предыдущие версии элементов конфигурации.

6. Храните, обновляйте и извлекайте записи управления конфигурацией.

7. Создавайте отчеты по управлению конфигурацией из системы управления конфигурацией.

8. Сохраняйте содержимое системы управления конфигурацией.

Примеры функций сохранения системы управления конфигурацией:

  • Резервное копирование и восстановление файлов управления конфигурацией
  • Архивирование файлов управления конфигурацией
  • Восстановление после ошибок управления конфигурацией

9. Пересматривайте структуру управления конфигурацией по мере необходимости.

СП 1.3 Создавайте или Выпускайте Базовые Линии

Создавайте и выпускайте базовые линии для внутреннего пользования и для поставки клиенту.

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

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

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

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

Пример рабочих продуктов

1. Базовые линии

2. Описание базовых линий

Подпрактики

1. Получите разрешение от ГКИ до создания или выпуска базовых линий элементов конфигурации.

2. Создавайте и выпускайте базовую линию только из элементов конфигурации в системе управления конфигурацией.

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

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

СЦ 2     Отслеживать и Контролировать Изменения

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

Практики в рамках этой цели обеспечивают поддержку базовых линий после того как они установлены практиками в рамках цели Установить Базовые Линии.

СП 2.1 Отслеживайте Изменения

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

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

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

Пример рабочих продуктов

1. Запросы на изменение

Подпрактики

1. Инициируйте и записывайте запросы на изменение в базе данных запросов на изменение.

2. Анализируйте влияние изменений и исправлений, предложенных в запросах на изменение.

Изменения оцениваются в рамках процедур, которые обеспечивают соответствие всем техническим и проектным требованиям.

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

Изменения оцениваются на предмет их влияния на планы выпуска.

3. Устанавливайте категорию и приоритет запросов на изменение.

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

Изменения планируются для будущих базовых линий.

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

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

5. Отслеживайте статус запросов на изменение до закрытия.

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

СП 2.2 Контролируйте Элементы Конфигурации

Контролируйте изменение элементов конфигурации.

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

Пример рабочих продуктов

1. История изменений элементов конфигурации

2. Архивы базовых линий

Подпрактики

1. Контролируйте изменение элементов конфигурации на протяжении всего жизненного цикла продукта или услуги.

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

Например, разрешение может исходить от ГКИ, руководителя проекта, владельца продукта или клиента.

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

Примеры изъятия на редактирование и регистрации изменений:

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

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

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

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

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

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

СЦ 3Установить Целостность

Целостность базовых линий установлена и поддерживается.

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

СЦ 3.1 Установите Записи Управления Конфигурацией

Создавайте и поддерживайте записи описания элементов конфигурации.

Пример рабочих продуктов

1. История изменений элементов конфигурации

2. Журнал изменений

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

4. Состояние элементов конфигурации

5. Различия между базовыми линиями

Подпрактики

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

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

Примеры мероприятий для определения доступа к информации о состоянии конфигурации:

  • Предоставление прав доступа для авторизованных конечных пользователей
  • Создание копий базовой линии доступных для зарегистрированных конечных пользователей
  • Автоматическое оповещение соответствующих заинтересованных сторон, когда элементы регистрируются, или изымаются на редактирование, или изменяются, или принято решение в отношении запросов на изменение

3. Указывайте последнюю версию базовой линии.

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

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

6. Изменяйте статус и историю (т. е. внесение изменения и другие действия) каждого элемента конфигурации по мере необходимости.

СЦ 3.2 Выполняйте Аудит Конфигурации

Выполняйте аудит конфигурации для поддержки целостности базовых линий конфигурации.

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

Примеры типов аудита:

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

Пример рабочих продуктов

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

2. Последовательность действий

Подпрактики

1. Оценивайте целостность базовых линий.

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

3. Проверяйте структуру и целостность элементов в системе управления конфигурацией.

4. Подтвердите полноту, правильность и согласованность элементов в системе управления конфигурацией.

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

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

6. Отслеживайте последовательность действий от аудита до закрытия.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

Сравнение концепции 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 »

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