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

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

Posts Tagged ‘управление’

CMMI DEV v1.3 – Количественное Управление Проектом

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

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

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

Назначение

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

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

Процессная область Количественное Управление Проектом включает в себя следующие мероприятия:

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

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

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

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

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

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

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

Таким образом количественное управление включает статистическое мышление и правильное использование различных статистических методов. (См. определение «количественное управление» в глоссарии).

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

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

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

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

Связанные процессные области

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

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

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

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

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

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

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

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

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

  • СЦ 1 Подготовить Количественное Управление
    • СП 1.1 Устанавливайте Цели Проекта
    • СП 1.2 Составляйте Определенный Процесс
    • СП 1.3 Выбирайте Подпроцессы и Атрибуты
    • СП 1.4 Выбирайте Меры и Техники Аналитики
  • СЦ 2 Количественно Управлять Проектом
    • СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов
    • СП 2.2 Управляйте Выполнением Проекта
    • СП 2.3 Выполняйте Анализ Корневых Причин

Специфические практики по целям

СЦ 1 Подготовить Количественное Управление

Проведена подготовка для количественного управления.

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

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

СП 1.1 Устанавливайте Цели Проекта

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

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

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

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

1. Проектные цели качества и выполнения процесса

2. Оценка риска не достижения целей проекта

Подпрактики

1. Анализируйте организационные цели для качества и выполнения процесса.

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

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

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

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

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

  • Продолжительность
  • Предсказуемость
  • Надежность
  • Ремонтопригодность
  • Удобство использования
  • Своевременность
  • Функциональность
  • Точность

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

Определение и документирование целей проекта включают следующее:

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

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

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

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

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

Примеры проектных целей качества и выполнения процесса включают в себя:

  • Поддержка размера журнала запросов на изменение ниже планируемого значения.
  • Улучшение производительности в гибкой среде относительно планируемого значения к планируемому сроку.
  • Сокращение время простоя на x % к установленному сроку.
  • Поддержка изменения расписания ниже указанного процента.
  • Снижение стоимости всего жизненного цикла на указанный % к установленному сроку.
  • Сокращения количества дефектов в продукте, поставляемого заказчику, на 10% без влияния на стоимость.

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

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

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

5. Определяйте риски, которые влияют на достижение проектных целей качества и выполнения процесса.

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

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

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

Разрешение конфликтов предполагает следующие виды мероприятий:

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

7. Устанавливайте трассировку проектных целей качества и выполнения процесса к их источникам.

Примеры источников цели включают следующее:

  • Требования
  • Цели качества и выполнения процесса организации
  • Цели качество и выполнения процесса заказчика
  • Бизнес-цели
  • Обсуждение с заказчиками и потенциальными заказчиками
  • Обследование рынка
  • Архитектура продукта

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

8. Определяйте и согласовывайте цели качества и выполнения процесса для поставщиков.

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

СП 1.2 Составляйте Определенный Процесс

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

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

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

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

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

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

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

2. Альтернативные подпроцессы

3. Подпроцессы, которые должны быть включены в определенный процесс проекта

4. Оценка риска, влияющего на достижение целей проекта

Подпрактики

1. Устанавливайте критерии для использования при оценке альтернатив процесса для проекта.

Критерии могут быть основаны на следующем:

  • Цели качества и выполнения процесса
  • Доступность данных о выполнении процесса и важность данных для оценки альтернатив
  • Знакомство с альтернативой или альтернативными вариантами, аналогичными составляемым
  • Наличие моделей выполнения процессов, которые могут быть использованы в оценке альтернатив
  • Стандарты линейки продукта
  • Модели жизненного цикла проекта
  • Требования заинтересованных сторон
  • Законы и правила

2. Определяйте альтернативные процессы и подпроцессы для проекта.

Выявление альтернатив может включать одно или несколько из следующих действий:

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

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

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

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

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

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

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

4. Оценивайте альтернативные вспомогательные критерии.

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

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

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

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

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

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

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

СП 1.3 Выбирайте Подпроцессы и Атрибуты

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

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

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

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

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

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

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

2. Выбранные подпроцессы

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

Подпрактики

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

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

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

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

Примеры критериев, используемых для выбора подпроцессов:

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

3. Выбирайте подпроцессы с помощью определенных критериев.

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

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

4. Определяйте атрибуты продукта и процесса, которые должны контролироваться.

Эти атрибуты были определены в рамках выполнения предыдущих подпрактик.

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

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

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

СП 1.4 Выбирайте Меры и Техники Аналитики

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

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

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

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

2. Трассировка мер с проектными целями качества и выполнения процесса

3. Цели качества и выполнения процесса для выбранных подпроцессов и их атрибутов

4. Базовые показатели выполнения процесса и модели для использования в рамках проекта

Подпрактики

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

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

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

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

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

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

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

При выборе мер, имейте в виду следующие соображения:

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

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

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

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

  • Поддержка уровня рецензирования кода от 75 до 100 строк кода в час
  • Выдерживать длительность сессий сбора требования до трех часов
  • Выдерживать скорость тестирования на указанное количество тестовых случаев в день
  • Поддержка уровень переделки ниже указанного процента
  • Поддержка производительности в генерировании вариантов использования на один день
  • Выдерживать сложность проектирования (уровень разветвления) ниже заданного порогового значения

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

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

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

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

Примеры графических отображений:

  • Диаграммы рассеивания
  • Гистограммы
  • Ящик с усами
  • Графики выполнения
  • Диаграммы Исикавы

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

  • Учетные листы
  • Схемы классификации (например, Ортогональная Классификация Дефектов)

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

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

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

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

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

Этот инструментарий основан на следующем:

  • Описании набора стандартных процессов организации
  • Описании определенного процесса проекта
  • Возможностях организационной или среды поддержки проекта

9. Пересматривайте меры и методы статистического анализа по мере необходимости.

СЦ 2 Количественно Управлять Проектом

Проект управляется количественно.

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

  • Мониторинг выбранных подпроцессов с использованием статистических и других количественных методов
  • Определение удовлетворены ли проектные цели качества и выполнения процесса
  • Выполнение анализа корневых причин выбранных проблем для устранения недостатков

СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов

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

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

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

1. Естественные границы выполнение процесса для каждого выбранного атрибута подпроцессов

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

Подпрактики

1. Собирайте данные, как это определено выбранными мерами, подпроцессов по мере их выполнения.

2. Контролируйте колебания и стабильность выбранных подпроцессов и устраняйте недостатки.

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

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

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

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

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

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

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

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

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

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

СП 2.2 Управляйте Выполнением Проекта

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

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

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

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

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

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

1. Результаты прогнозов достижения относительно целей качества и выполнения процесса проекта

2. Графическое отображение и табулирование данных для других подпроцессов, поддерживающих количественное управление

3. Оценка рисков не достижения целей качества и выполнения процесса проекта

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

Подпрактики

1. Периодически оценивайте выполнение подпроцессов.

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

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

2. Отслеживайте и анализируйте прогресс поставщиков в достижении их целей качества и выполнения процесса.

3. Периодически рассматривайте и анализируйте фактические результаты, достигнутые в отношении установленных временных целей.

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

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

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

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

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

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

Примеры источников рисков включают следующее:

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

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

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

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

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

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

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

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

СП 2.3 Выполняйте Анализ Корневых Причин

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

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

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

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

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

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

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

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

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

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

1. Измерения и анализ (включая статистический анализ) выполнения подпроцесса и проекта записанные в организационном репозитории мер

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

3. Выявленные корневые причины и потенциальные мероприятия

Подпрактики

1. Выполняйте по необходимости анализ корневых причин для диагностики недостатков выполнения процесса.

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

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

2. Выявляйте и анализируйте потенциальные мероприятия.

3. Реализуйте выбранные мероприятия.

4. Оценивайте воздействие принимаемых мер на выполнение подпроцессов.

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

Реклама

Posted in CMMI, Стандарты и методологии | Отмечено: , , , | Leave a Comment »

Правильные требования: Топ 10 ловушек

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

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

Источник: Getting requirements right: avoiding the top 10 traps

Содержание

Не попадайтесь

Ловушка 1: расползание границ

Ловушка 2: спрашивать заказчиков, чего они хотят

Ловушка 3: неспособность адаптироваться к изменениям

Ловушка 4: неспособность эффективно общаться

Ловушка 5: нечастое общение

Ловушка 6: громоздкие документы и слишком много информации

Ловушка 7: скрытые артефакты проекта

Ловушка 8: неоднозначные требования

Ловушка 9: неспособность измерить и оценить процесс требований

Ловушка 10: изоляция ваших требований

Заключение

Не попадайтесь

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

К сожалению, ловушки требований являются общими и их влияние является значительным. В исследованиях State of the IT Union Survey изучали методы управления разработкой, которые команды применяют во избежание неприятностей или используют для решения проблемы после их обнаружения. Онлайн-опрос респондентов показывает, как часто команды разработчиков предвидят, что они могут попасть в ловушки. Они дополняют бюджеты и планы. Они изменяют первоначальную смету, чтобы соответствовать фактическим результатам. И они запрашивают дополнительные ресурсы. Рисунок 1 показывает, как команды и руководители групп будут бороться с этими ловушками…

Основные моменты

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

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

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

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

Основные моменты

Фиксирование бизнес-требований может контролировать расползание границ.

Ловушка 1: расползание границ

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Уводите обсуждение подальше от возможностей.

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

Ловушка 2: спрашивать заказчиков, чего они хотят

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Неопределенности и внешние факторы могут повлиять на требования.

Планируйте изменений для уменьшения риска.

Ловушка 3: неспособность адаптироваться к изменениям

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

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

Эффективная коммуникация помогает оптимизировать время и трудозатраты.

Ловушка 4: неспособность эффективно общаться

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Заинтересованные лица часто имеют разные приоритеты.

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

Ловушка 5: нечастое общение

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Когда речь заходит о документации, думайте качественно, а не количественно.

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

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

Ловушка 6: громоздкие документы и слишком много информации

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Создайте центральное хранилище для артефактов проекта.

Централизованное управление информацией может способствовать сотрудничеству.

Ловушка 7: скрытые артефакты проекта

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Неопределенность создает риски на следующем этапе проекта.

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

Ловушка 8: неоднозначные требования

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

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

Что вызывает неопределенность? Бедное описание, неточная информация и предположение, что аудитория понимает так же, как вы и делаете.

Избегание ловушки

  • Используйте руководство по написанию, например, Элементы Стиля Вильяма Странка Младшего и Е.Б. Уайта, которое уже давно считается авторитетным справочным материалом для четкого, понятного текста — до и во время создания требований.
  • Создайте глоссарий и убедитесь, что включен каждый акроним и технический термин.
  • Представьте, что вы пишете для студента, который только что закончил колледж, или для тех, кто недавно присоединился к компании. Не ожидайте, что аудитория будет знать каждый термин и понимать каждое понятие.
  • Дополняйте текст визуальными эффектами. Это отличный способ выразить и простую, и сложную концепцию.
  • Шагните назад. После написания любого проектного документа, закройте его на некоторое время и прочитайте позже. Свежий взгляд может выявить неоднозначности.

Выигрыш

Четкие, понятные требования являются основой вашего программного проекта.

Основные моменты

Измерения результатов позволяют непрерывно улучшать процесс.

Ловушка 9: неспособность измерить и оценить процесс требований

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

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

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

Ловушка 10: изоляция ваших требований

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

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

Заключение

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

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

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

Программное обеспечение IBM Rational RequisitePro ® в сфере ИТ и программное обеспечение IBM Rational Doors ® в системной сфере обеспечивают трассировку и анализ влияния, который держит аналитиков, архитекторов, разработчиков и тестировщиков в соответствии потребностям бизнеса и требованиям на протяжении всего жизненного цикла поставки программного обеспечения.

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

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

Чтобы узнать больше о решениях для требований IBM Rational для разработки программного обеспечения, обратитесь к представителю IBM или бизнес-партнеру IBM или посетите:

ibm.com/software/rational/offerings/irm

Rational Requirements Composer software:

ibm.com/software/awdtools/rrc/

Бесплатная загрузка Rational Requirements Composer:

https://jazz.net/projects/rational-requirements-composer/

Электронный пакет лучший практик поставки программного обеспечения: Сделать больше с меньшими затратами:

ibm.com/services/forms/preLogin.do?lang=en_US&source=swg-rtl_sdekit

Топ 10 секретов поставки программного обеспечения выполняя больше с меньшими затратами:

ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14139usen/RAW14139USEN.PDF

Калькулятор ROI:

ibm.com/software/rational/offerings/testing/roi/

Читайте наш блог RDM:

rationalrdm.wordpress.com

Следуйте за нами на Twitter: @RationalRDM

Стань фаном Rational Requirements Composer на Facebook:

http://www.facebook.com/home.php?#/pages/Rational-Requirements-Composer/47378244431?ref=ts

Posted in Полезное, Разное, Требования | Отмечено: , | Leave a Comment »

CMMI DEV v1.3 –Комплексное Управление Проектом

Posted by Шамрай Александр на Декабрь 6, 2011

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

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

Назначение

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

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

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

  • Установка определенного процесса проекта на начало проекта с использованием адаптации набора стандартных процессов организации
  • Управление проектом с использованием определенного процесса проекта
  • Установка рабочей среды для проекта, основанного на стандартах рабочей среды организации
  • Создание команды, которой поручено достичь цели проекта
  • Использование и способствование активам организационного процесса
  • Обеспечение возможности соответствующим заинтересованным сторонам быть определенными, принятыми во внимание и, при необходимости, привлеченными в ходе проекта
  • Обеспечение того, чтобы соответствующие заинтересованные стороны (1) выполняли свои задачи координировано и своевременно; (2) были согласованы с требования проекта, планами, целями, проблемами и рисками; (3) выполняли свои обязательства по выполнению; и (4) выявляли, отслеживали и решали проблемы координации

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

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

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

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

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

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

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

Связанные процессные области

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

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

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

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

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

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

  • СЦ 1 Использовать Определенный Процесс Проекта
    • СП 1.1 Устанавливайте Определенный Процесс Проекта
    • СП 1.2 Используйте Активы Организационного Процесса для Планирования Проектных Мероприятий
    • СП 1.3 Устанавливайте Рабочую Среду Проекта
    • СП 1.4 Объединяйте Планы
    • СП 1.5 Управляйте Проектом Используя Объединенные Планы
    • СП 1.6 Устанавливайте Команды
    • СП 1.7 Содействуйте Активам Организационного Процесса
  • СЦ 2. Координировать и Сотрудничать с Соответствующими Заинтересованными Сторонами
    • СП 2.1 Управляйте Участием Заинтересованных Сторон
    • СП 2.2 Управляйте Зависимостями
    • СП 2.3 Решайте Проблемы Координации

Специфические практики по целям

СЦ 1 Использовать Определенный Процесс Проекта

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

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

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

СП 1.1 Устанавливайте Определенный Процесс Проекта

Создавайте и поддерживайте определенный процесс проекта от начала проекта и в течение всего срока проекта.

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

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

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

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

Определенный процесс проекта основывается на следующих факторах:

  • Требования заинтересованных сторон
  • Обязательства по выполнению
  • Потребности и цели организационного процесса
  • Набор стандартных процессов организации и принципы адаптации
  • Операционная среда
  • Бизнес-среда

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

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

1. Определенный процесс проекта

Подпрактики

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

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

  • Размер и сложность проекта
  • Стратегия проекта
  • Опыт и знания персонала в реализации процесса
  • Ограничения, такие как время цикла и приемлемые уровни дефектов
  • Наличие заказчиков для ответов на вопросы и обеспечение обратной связи для инкрементов
  • Ясность требований
  • Ожидания заказчика

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

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

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

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

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

Другие артефакты могут включать в себя следующее:

  • Документы с извлеченными уроками
  • Шаблоны
  • Примеры документов
  • Модели оценки

5. Документируйте определенный процесс проекта.

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

Примеры проектной деятельности включают следующее:

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

6. Проводите коллегиальные оценки определенного процесса проекта.

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

7. Пересматривайте определенный процесс проекта по мере необходимости.

СП 1.2 Используйте Активы Организационного Процесса для Планирования Проектных Мероприятий

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

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

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

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

1. Оценки проекта

2. Планы проекта

Подпрактики

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

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

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

Эта оценка обычно включает в себя следующее:

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

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

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

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

  • Размер рабочих продуктов или другие атрибуты рабочих продуктов
  • Трудозатраты
  • Стоимость
  • Рабочий график
  • Кадровое обеспечение
  • Время отклика
  • Сервисные мощности
  • Работы поставщиков
  • Дефекты

СП 1.3 Устанавливайте Рабочую Среду Проекта

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

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

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

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

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

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

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

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

1. Оборудование и инструменты для проекта

2. Руководства по инсталляции, эксплуатации и обслуживанию для рабочей среды проекта

3. Пользовательские опросы и результаты

4. Журналы использования, выполнения и обслуживания

5. Сервисы поддержки для рабочей среды проекта

Подпрактики

1. Планируйте, проектируйте и инсталлируйте рабочую среду для проекта.

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

Может быть необходим поиск компромисса между атрибутами качества, затратами и рисками. Ниже приведены примеры каждого из них:

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

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

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

2. Обеспечивайте текущее обслуживание и операционную поддержку рабочей среды проекта.

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

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

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

3. Поддерживайте квалификацию компонентов рабочей среды проекта.

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

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

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

  • Добавление новых инструментов
  • Получение дополнительных сетей, оборудования, обучения и поддержки

СП 1.4 Объединяете Планы

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

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

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

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

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

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

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

1. Объединенные планы

Подпрактики

1. Объединяйте другие планы, которые влияют на проект, с планом проекта.

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

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

2. Интегрируйте в план проекта определения мер и мероприятий измерений по управлению проектом.

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

  • Общие комплекс мер организации
  • Дополнительные специфические для проекта меры

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

3. Выявляйте и анализируйте риски интерфейсов проекта и продукта.

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

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

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

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

Примеры факторов, которые учитываются при планировании, включают следующее:

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

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

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

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

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

7. Устанавливайте объективные входные и выходные критерии для авторизации начала и завершения задач, описанных в структуре декомпозиции работ (СДР).

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

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

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

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

СП 1.5 Управляйте Проектом Используя Объединенные Планы

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

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

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

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

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

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

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

2. Собранные меры (например, фактические) и информация или отчеты о состоянии

3. Пересмотренные требования, планы и обязательства по выполнению

4. Объединенные планы

Подпрактики

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

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

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

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

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

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

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

3. Получайте и анализируйте выбранные измерения для нужд управления проектом и организационной поддержки.

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

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

Эта оценка включает в себя согласование с потребностями и целями процесса организации.

Примеры действий, которые обеспечивают соответствие, включают следующее:

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

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

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

СП 1.6 Устанавливайте Команды

Устанавливайте и поддерживайте команды.

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

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

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

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

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

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

1. Документальное общее видение

2. Список членов назначенных в каждой команде

3. Устав команды

4. Периодические отчеты о состоянии команды

Подпрактики

1. Устанавливайте и поддерживайте общее видение проекта.

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

2. Устанавливайте и поддерживайте структуры команд.

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

3. Устанавливайте и поддерживайте каждую команду.

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

4. Периодически оценивайте структуру и состав команды.

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

СП 1.7 Дополняйте Активы Организационного Процесса

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

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

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

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

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

1. Предложения о совершенствовании активов организационных процессов

2. Фактические меры процесса и продукта собранные из проекта

3. Документация (например, примерные описания процесса, планы, учебные программы, контрольные списки, полученные уроки)

4. Артефакты процесса, связанные с адаптацией и реализацией набора стандартных процессов организации на проект

Подпрактики

1. Предлагайте усовершенствования активов организационных процессов.

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

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

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

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

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

  • Плановые данные
  • Перепланированные данные

Примеры данных, записанных в рамках проекта, включают следующее:

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

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

Примеры документации включают следующее:

  • Примеры описания процесса
  • Материалы обучения
  • Примеры планов
  • Шаблоны контрольных списков
  • Шаблоны проектных хранилищ
  • Конфигурации инструментов

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

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

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

СЦ 2 Координация и Сотрудничество с Соответствующими Заинтересованными Сторонами

Ведется координация и сотрудничество между проектом и соответствующими заинтересованными сторонами.

СП 2.1 Управляйте Участием Заинтересованных Сторон

Управление вовлечением соответствующих заинтересованных сторон в проекте.

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

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

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

1. Программа и календарные графики для совместной деятельности

2. Рекомендации по решению проблем соответствующих заинтересованных сторон

3. Документированные проблемы (например, проблемы с требованиями заинтересованных сторон, требованиями к продукту и компонентам продукта, архитектурой продукта, проектированием продукта)

Подпрактики

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

Соответствующие заинтересованные стороны уже должны быть определены в плане проекта.

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

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

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

Эта задача обычно включает в себя следующее:

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

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

СП 2.2 Управляйте Зависимостями

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

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

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

2. Критические зависимости

3. Обязательства по выполнению для решения важнейших зависимостей

4. Состояние критических зависимостей

Подпрактики

1. Проводите обзоры с соответствующими заинтересованными сторонами.

2. Определяйте каждую критическую зависимость.

3. Устанавливайте желаемые сроки и плановые сроки для каждой критической зависимости на основе календарного графика проекта.

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

5. Документируйте критические зависимости и обязательства по выполнению.

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

  • Описание обязательства по выполнению
  • Определение кто взял на себя обязательство по выполнению
  • Определение кто несет ответственность за удовлетворение обязательств по выполнению
  • Определение, когда обязательства по выполнению будут выполнены
  • Определение критериев для определения было ли обязательство по выполнению выполнено

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

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

Отслеживание критических зависимостей обычно включает в себя следующее:

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

СП 2.3 Решайте Проблемы Координации

Решайте проблемы с соответствующими заинтересованными сторонами.

Примеры вопросов координации включают следующее:

  • Требования к продукту и компонентам продукта и дефекты проектирования
  • Запаздывающие критические зависимости и обязательства по выполнению
  • Проблемы на уровне продукта
  • Недоступность критических ресурсов или персонала

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

1. Проблемы координации с соответствующими заинтересованными сторонами

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

Подпрактики

1. Выявляйте и документируйте проблемы.

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

3. Решайте проблемы с соответствующими заинтересованными сторонами.

4. Эскалируйте на соответствующих менеджеров проблемы, которые не были решены с соответствующими заинтересованными сторонами.

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

6. Сообщайте соответствующим заинтересованным сторонам о состоянии и решении возникших проблем.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , , , | Leave a Comment »

CMMI DEV v1.3 – Управление Рисками

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

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

В Agile среде некоторые мероприятия по управлению рисками изначально встроены в используемые Agile методы. Например, некоторые технические риски могут быть решены путем поощрения экспериментов (выявление ранних «неудач») или выполнения «предварительных исследований» (spike) за пределами рутинных итерации. Тем не менее, процессная область Управление Рисками поощряет более систематический подход к управлению рисками, как технических, так и нетехнических. Такой подход может быть интегрирован в типичные итерации 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. Списки источников рисков (внешние и внутренние)

2. Список категорий рисков

Подпрактики

1. Определяйте источники рисков.

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

Типичные внутренние и внешние источники рисков включают следующее:

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

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

2. Определяйте категории рисков.

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

Следующие факторы могут быть учтены при определении категории рисков:

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

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

СП 1.2 Определяйте Параметры Рисков

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

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

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

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

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

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

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

1. Критерии для оценки риска, установки категории и приоритетов

2. Требования к управлению рисками (например, уровни контроля и утверждения, интервалы переоценки)

Подпрактики

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

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

2. Определяйте пороговые значения для каждой категории риска.

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

Примеры порогов включают следующее:

  • Пороговые значения по проекту могут быть установлены для привлечения старшего руководства, когда затраты по продукту превышают на 10 процентов целевые затраты, или когда индекс выполнения бюджета опускается ниже 0,95.
  • Пороговые значения графика работ может быть установлены для привлечения старшего руководства, когда индекс выполнения графика работ опускается ниже 0,95.
  • Пороговые значения производительности могут быть установлены для привлечения старшего руководства, когда указанные ключевые элементы (например, загрузка процессора, среднее время отклика) превышают 125 процентов установленные при проектировании.

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

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

СП 1.3 Устанавливайте Стратегию Управления Рисками

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

Всесторонняя стратегия управления рисками затрагивает такие элементы как нижеприведенные:

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

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

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

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

1. Стратегия управления рисками проекта

СЦ 2 Идентифицировать и Проанализировать Риски

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

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

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

СП 2.1 Идентифицируйте Риски

Идентифицируйте и документируйте риски.

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

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

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

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

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

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

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

Подпрактики

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

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

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

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

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

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

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

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

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

Примерами таких других рисков включают следующие риски:

  • Забастовки
  • Уменьшение источников поставок
  • Время технологического цикла
  • Конкуренция

2. Рассматривайте элементы среды, которые могут повлиять на проект.

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

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

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

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

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

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

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

СП 2.2 Оценивайте, Устанавливайте Категории и Приоритеты для Рисков

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

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

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

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

1. Список рисков и назначенные на них приоритеты

Подпрактики

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

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

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

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

Пример категории последствия, включают следующее:

  • Низкое
  • Среднее
  • Высокое
  • Незначительное
  • Маргинальное
  • Значительное
  • Критическое
  • Катастрофическое

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

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

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

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

3. Устанавливайте приоритетность рисков для смягчения их последствий.

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

СЦ 3 Смягчить Риски

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

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

СП 3.1 Разрабатывайте Планы по Смягчению Рисков

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

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

Варианты обработки рисков, как правило, включают альтернативы, такие как следующие:

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

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

Например, в случае событий, которые нарушают непрерывность деятельности, подходы в управлении рисками могут включать в себя установку следующего:

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

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

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

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

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

1. Документированные параметры обработки для каждого выявленного риска

2. Планы снижение рисков

3. Планы

4. Список тех, кто отвечает за отслеживание и устранение каждого риска

Подпрактики

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

Уровень риска (полученный с использованием модели риска) является мерой сочетания неопределенности достижения цели с последствиями неудачи для достижения цели.

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

2. Определяйте лицо или группу, ответственную за решение каждого риска.

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

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

4. Разрабатывайте общий план снижения рисков по проекту для управления реализацией отдельных планов снижения рисков и последствий риска.

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

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

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

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

СП 3.2 Реализуйте План по Смягчению Риска

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

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

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

1. Обновленные списки состояний рисков

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

3. Обновленный список вариантов обработки рисков

4. Обновленный список действий, предпринятых для обработки рисков

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

Подпрактики

1. Отслеживайте состояние рисков.

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

Должны быть использованы механизмы мониторинга.

2. Обеспечивайте методы для отслеживания действий по обработке открытого риска до его закрытия.

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

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

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

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

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

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

6. Собирайте показатели выполнения мероприятий по обработке риска.

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

CMMI DEV v1.3 – Управление Соглашениями с Поставщиками

Posted by Шамрай Александр на Февраль 24, 2011

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

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

Назначение

Назначением Управление Соглашениями с Поставщиками (УСП) является управление приобретением продуктов и услуг от поставщиков.

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

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

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

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

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

  • Определение типа приобретения
  • Выбор поставщиков
  • Установка и поддержка соглашений с поставщиками
  • Выполнение соглашений с поставщиком
  • Утверждение поставки приобретенных продуктов
  • Обеспечение успешной доставки приобретенных продуктов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Заключить Соглашение с Поставщиком
    • СП 1.1 Определяйте Тип Поставки
    • СП 1.2 Выбирайте Поставщика
    • СП 1.3 Устанавливайте Соглашение с Поставщиком
  • СЦ 2 Выполнить Соглашение с Поставщиком
    • СП 2.1 Выполняйте Соглашение с Поставщиком
    • СП 2.2 Утверждайте Приобретаемый Продукт
    • СП 2.3 Обеспечивайте Доставку Продукта

Специфические практики по целям

СЦ 1 Заключить Соглашение с Поставщиком

Соглашения с поставщиками заключены и поддерживаются.

СП 1.1 Определяйте Тип Поставки

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

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

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

Примеры типов поставки включают следующее:

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

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

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

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

СП 1.2 Выбирайте Поставщика

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

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

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

Критерии должны быть установлены для устранения факторов, которые важны для проекта.

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

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

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

1. Исследования рынка

2. Список кандидатов поставщиков

3. Список предпочтительных поставщиков

4. Торговые исследования или другая информация для оценки критериев, преимуществ и недостатков кандидата поставщиков и для рационального выбора поставщиков

5. Материалы и требования по ходатайству

Подпрактики

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

2. Выявляйте потенциальных поставщиков и распространяйте тендерные материалы и требования к ним.

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

3. Оценивайте заявки в соответствии с критериями оценки.

4. Оценивайте риски, связанные с каждым предложенным поставщиком.

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

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

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

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

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

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

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

6. Выберите поставщика.

СП 1.3 Устанавливайте Соглашение с Поставщиком

Устанавливайте и поддерживайте соглашение с поставщиком.

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

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

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

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

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

1. Устав работ

2. Контракты

3. Меморандум о соглашении

4. Лицензионное соглашение

Подпрактики

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

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

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

2. Документируйте, что проект будет предоставлять поставщику.

Включая следующие:

  • Средства для снабжения проекта
  • Документация
  • Услуги

3. Документируйте соглашение с поставщиком.

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

Как правило, эта подпрактика включает в себя следующие задачи:

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

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

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

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

5. Удостоверьтесь, что все стороны соглашения с поставщиком понимают и согласны на все требования перед началом реализации соглашения или любого изменения.

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

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

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

СЦ 2 Выполнить Соглашение с Поставщиком

Соглашения с поставщиками выполнены обеими сторонами и проектом и поставщиком.

СП 2.1 Выполняйте Соглашение с Поставщиком

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

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

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

1. Отчеты поставщика о ходе работ и измерениях выполнения

2. Рецензия поставщика для материалов и отчетов

3. Действия, отслеженные до их закрытия

4. Поставки продукта и документации

Подпрактики

1. Следите за прогрессом и выполнением работ поставщиком (например, выполнение графика, трудозатрат, затрат, технических работ), как это определено в соглашении с поставщиком.

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

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

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

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

4. Проводите анализ с поставщиком, как определено в соглашении с поставщиком.

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

Анализ охватывает формальный и неформальный анализ и включает в себя следующие шаги:

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

5. Проводите технический анализ с поставщиком, как определено в соглашении с поставщиком.

Технический анализ обычно включает в себя следующее:

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

6. Проводите управленческий анализ с поставщиком, как определено в соглашении с поставщиком.

Управленческий анализ обычно включает следующее:

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

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

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

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

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

СП 2.2 Утверждайте Приобретаемый Продукт

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

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

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

1. Процедуры приемки

2. Результаты приемочного анализа или испытаний

3. Отчеты по несоответствию или планы корректирующих действий

Подпрактики

1. Определяйте процедуру приемки.

2. Анализируйте и получайте согласие от соответствующих заинтересованных сторон на приемочные процедуры перед приемочным анализом или тестами.

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

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

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

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

5. Документируйте результаты приемочного анализа или теста.

6. Устанавливайте план действий и получайте согласие поставщика на принятие действий для корректировки приобретаемых рабочих продуктов, которые не прошли их приемочный анализ или тест.

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

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

СП 2.3 Обеспечивайте Доставку Продукта

Проверяйте доставку приобретаемых продуктов от поставщиков.

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

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

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

1. Планы доставки

2. Отчеты по обучению

3. Отчеты по поддержке и обслуживанию

Подпрактики

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

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

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

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

CMMI DEV v1.3 – Управление Требованиями

Posted by Шамрай Александр на Декабрь 2, 2010

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

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

Назначение

Назначение Управления Требованиями (УПТР) состоит в управлении требованиями продукта или компонентов продукта в проекте для обеспечения соответствия этих требований с планами проекта и рабочими продуктами.

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

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

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

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

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

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

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

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

В среде Agile, требования передаются и связываются через механизмы, такие как журнал продукта, карта истории и макеты экрана. Утверждение требований принимаются коллегиально командой или уполномоченным руководителем группы. Распределение заданий регулярно (например, ежедневно, еженедельно) корректируется на основе достижений прогресса проекта, более глубокого понимания требований и выяснения решения. Трассируемость и согласованность между требованиями и рабочими продцуктами обеспечивается механизмами, которые уже упоминались, а также во время мероприятий начало-итерации или конец-итерации, таких как «ретроспективы» и «дни демонстрации». (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессные области

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

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

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

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

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

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

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

  • CЦ 1 Управлять Требованиями
    • CП 1.1 Достигните Понимания Требования
    • CП 1.2 Принимайте Требования на Реализацию
    • CП 1.3 Управляйте Изменениями Требований
    • CП 1.4 Поддерживайте Двухстороннюю Трассируемости Требований
    • CП 1.5 Обеспечивайте Согласованность Между Рабочими Продуктами и Требованиями

Специфические практики по целям

CЦ 1 Управление Требованиями

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

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

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

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

См. практики Разрабатывайте Альтернативные Решения и Критерии Выбора процессной области Техническое Решение для получения дополнительной информации об определении реализуемости требований.

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

CП 1.1 Достигните Понимания Требования

Выработайте общее понимание значения требований с поставщиками требований

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

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

1. Список критериев, характеризующих соответствующих поставщиков требований

2. Критерии для оценки и приемки требований

3. Результаты анализов по критериям

4. Набор утвержденных требований

Подпрактики

1. Устанавливайте критерии, характеризующие соответствующих поставщиков требований.

2. Устанавливайте объективные критерии для оценки и принятия требований.

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

Примеры критериев оценки и принятия:

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

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

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

CП 1.2 Принимайте Требования на Реализацию

Получите подтверждение требований на реализацию от участников проекта.

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

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

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

1. Оценка влияния требования

2. Задокументированные подтверждения на реализацию требований и изменений требований

Подпрактики

1. Оценивайте влияние требований на существующие работы.

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

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

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

CП 1.3 Управляйте Изменениями Требований

Управляйте изменениями требований по мере их возникновения в ходе реализации проекта.

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

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

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

1. Запрос на изменение требования

2. Отчеты о влиянии изменения требования

3. Состояния требований

4. База данных требований

Подпрактики

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

2. Поддерживайте историю изменения требований, в том числе обоснования для изменения.

Сохранение истории изменений помогает отследить изменчивость требований.

3. Оценивайте воздействие изменения требований с точки зрения заинтересованных лиц.

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

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

CП 1.4 Поддерживайте Двухстороннюю Трассируемость Требований

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

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

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

Пример, какие аспекты трассируемости можно рассматривать:

  • Границы трассируемости: границы, в пределах которых трассируемость является необходимой
  • Определение трассируемости: элементы, которые должны иметь логические связи
  • Тип трассируемости: когда необходима горизонтальная и вертикальная трассировка

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

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

1. Матрицы трассировки требований

2. Системы отслеживания требований

Подпрактики

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

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

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

3. Создайте матрицу трассировки требования.

CП 1.5 Обеспечивайте Согласованность Между Рабочими Продуктами и Требованиями

Обеспечивайте соответствие планов проекта и рабочих продуктов с требованиями.

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

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

1. Документация о несоответствии между требованиями, планами проекта и рабочими продуктами, в том числе источники и условия

2. Корректирующие действия

Подпрактики

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

2. Определяйте источник несоответствия (если есть).

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

4. Инициируйте любые необходимые корректирующие действия.

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

Руководство по управлению требованиями 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 комментария »

Записки мистера Томпкинса из романа об управлении проектами «Deadline»

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

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

Безопасность и перемены

  1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
  2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
  3. Неуверенность заставляет человека избегать риска.
  4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
  5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Отрицательная мотивация

  1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
  2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
  3. Более того, если люди не справятся, вам придется выполнить свои обещания.

Части тела, необходимые для управления проектами

  1. Для руководства нужны сердце, нутро, душа и нюх
  2. Так что:
    • руководить надо сердцем;
    • чувствовать нутром;
    • вкладывать в команду и проект душу;
    • иметь нюх на всякую ерунду и бессмыслицу.

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

  1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
  2. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
  3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
  4. Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
  5. Больше слушайте, меньше говорите.
  6. И все это сработает еще лучше, если вы слегка подтасуете колоду.

Повышение производительности

  1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
  2. Повышение производительности — результат долгосрочных усилий.
  3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко» .

Управление рисками

  1. Чтобы управлять проектом, достаточно управлять его рисками.
  2. Создайте список рисков для каждого проекта.
  3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
  4. Оцените вероятность возникновения и стоимость каждого риска.
  5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
  6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
  7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Играй в защите

  1. Сокращайте потери.
  2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
  3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
  4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
  5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
  6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
  7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
  8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Моделирование процесса разработки

  1. Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
  2. Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.
  3. Предсказывайте результаты работы с помощью модели.
  4. Сравнивайте результаты, полученные в процессе моделирования, с реальными.

Извращенная политика

  1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
  2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
  3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
  4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
  5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
  6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Сбор метрических данных

  1. Определяйте размер каждого проекта.
  2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
  3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
  4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
  5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
  6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
  7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
  8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение

  1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
  2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
  3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
  4. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
  5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
  6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
  7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по-другому

  1. Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
  2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
  3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
  4. Нельзя заставить людей делать что-то по-другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.

Что дает давление сверху

  1. Люди не начнут быстрее соображать, если руководство будет давить на них.
  2. Чем больше сверхурочной работы, тем ниже производительность.
  3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
  4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
  5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Сердитый начальник

  1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
  2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
  3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Туманные спецификации

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

Конфликт

  1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
  2. Процесс создания и распространения программных систем — прямо таки рассадник всевозможных конфликтов.
  3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
  4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
  5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
  6. Тяжело договариваться. Гораздо легче выступать посредником.
  7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
  8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Кто такой катализатор проекта

  1. Существуют люди катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
  2. Посредничество — еще одна сфера, в которой люди катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
  3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Человеку свойственно ошибаться

  1. Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

О персонале

  1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую то работу).
  2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
  3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
  4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
  5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Проблемы социологии

  1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
  2. Каждому проекту нужна какая то церемония или ритуал.
  3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
  4. Защищайте людей от оскорблений и ругани Начальства.
  5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего то очень боятся.
  6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

О патологической политике (еще раз)

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

Злоба и скупость

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

Основы здравого смысла

  1. У проекта должно быть два срока сдачи — запланированный и желаемый.
  2. Эти сроки должны быть разными.

Posted in Книги, Разное | Отмечено: , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010

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

Перевел очередное руководство проекта Visual Studio ALM Rangers «Visual Studio 2010 Team Foundation Server Requirements Management Guidance«, которое рассказывает о возможностях TFS 2010 для организации эффективного процесса управления требованиями. Изначально это руководство готовилось для реализации процесса на TFS 2010 Beta1, поэтому есть один момент, который будет отличаться для релизной версии TFS 2010. Этот момент заключается в использовании рабочего элемента Возможность (Feature): в TFS 2010 Beta1 это был отдельный рабочий элемент, а уже в окончательной редакции он является просто отдельным типом Возможность рабочего элемента Требование. Поэтому при реализации у себя в организации изложенных в этом руководстве практик, учтите этот момент.

Содержание руководства:

  1. Введение в Управление требованиями с использованием Team Foundation Server. Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.
    • Общие Руководство по Разработке
    • Традиционная разработка
    • Гибкая разработка
  2. Планирование управления требованиями. План управления требованиями должен быть разработан для определения и механизмов контроля информации, которая будет собираться и использоваться для сбора метрик, отчетности и контроля изменений требований к продукту.
  3. Трассировка Требований. Трассировка, вероятно, наиболее важный аспект в инженерии требований, который обеспечивает подотчетность команды разработки. Кроме этого, она помогает:
    • Идентифицировать источник и важность требований
    • Управлять масштабом проекта
    • Управлять изменениями требований
    • Оценить воздействие на проект изменения требований или других элементов проекта
    • Оценить влияние провала тестирования требований (например, не пройденный тест может означать, что требование не выполнено)
    • Убедиться, что все требования к системе будут выполнены при реализации
    • Убедиться, что приложение делает то, для чего оно предназначено
    • Дать разработчику контекст требований для задачи
  4. Анализ и Декомпозиция. Анализ и Валидация выполняются для:
    • Установки рабочей концепции и сценариев (требования продукта – например, пользовательские цели и контекстные диаграммы; требования компонента продукта – например, технические ограничения и рабочая концепция)
    • Установки и поддержки определения необходимых функциональных возможностей (функциональная архитектура, диаграммы деятельности и сценарий использования, объектно-ориентированный анализ с идентифицированными сервисами)
    • Анализа требований (дефекность/изменчивость требований, изменения требований, технические критерии качества выполнения, оценка рисков)
    • Валидации требований со всесторонними методами (Отчет о методах анализа и результатах)
  5. Выявление требований. Этот документ описывает выявление требований на каждом из своих эволюционных уровней в рамках параметров двух различных методологий: традиционной разработки приложений и гибкой методологии. Visual Studio и Team Foundation Server обеспечивают общую технологию для двух типов методологий и служат для планирования, хранения, отслеживания и отчетности в хранилище для всех стадий выявления.
  6. Спецификация требований. Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать для определения требований и их проверки. Этот раздел рассказывает о документировании различных элементов требований в виде рабочих элементов и использовании других методов.
  7. Валидация требований. Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика, и помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют «Test-First Development» или «Requirements-Based Testing».
  8. Управление изменениями и утверждение требований. Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закону Сарбейнса-Оксли.
  9. Анализ влияния. Анализ влияния выполняется для:
    • Оценки в рамках задач, которые обеспечивают соответствие изменений всем техническим и проектным требованиям
    • Оценки влияния изменений за пределами непосредственного проекта или контракта требований (изменения в элементах, использующихся в нескольких продуктах, может решить текущую проблему, но вызывать проблему в других приложениях)
    • Определение влияния, которое изменения будут иметь для рабочих продуктов, связанных рабочих продуктов, рабочих графиков и стоимости проекта
  10. Дополнительные интеграции. Различные производители программного обеспечения и партнеры Microsoft разработали интеграции с Visual Studio, которые предоставляют возможности не очень хорошо реализованные в Visual Studio Team Suite. В частности, они имеют встроенные возможности в следующих областях: выявление, спецификации, валидации и управления изменениями. Тут список некоторых из наиболее тесно интегрированных решений.
  11. Контрольные списки для разработки требований. Контрольные списки, которые помогают улучшить качество разрабатываемых требований.

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

  • Visual Studio TFS Branching Guide 2010 – руководство по ветвлению для Team Foundation Server 2010 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.
  • TFS 2008 Branching Guide 2.0 – руководство по ветвлению для Team Foundation Server 2008 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

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