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

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

Archive for Декабрь 2010

CMMI DEV v1.3 – Обеспечение Качества Процесса и Продукта

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

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

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

Назначение

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

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

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

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

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

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

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

Примеры методов выполнения объективной оценки:

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Объективная Оценка Процессов и Рабочих Продуктов
    • СП 1.1 Объективно Оценивайте Процессы
    • СП 1.2 Объективно Оценивайте Рабочие Продукты
  • СЦ 2 Обеспечить Объективную Оценку
    • СП 2.1 Обсуждайте и Устраняйте Проблемы Несоблюдения
    • СП 2.2 Ведите Записи

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

СЦ 1 Объективная Оценка Процессов и Рабочих Продуктов

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

СП 1.1 Объективно Оценивайте Процессы

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

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

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

1. Отчеты по оценке

2. Отчеты по несоответствиям

3. Корректирующие действия

Подпрактики

1. Обеспечивайте условия (в рамках управления проектами), которые поощряют участие персонала в выявлении и отчетности проблем качества.

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

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

  • Что будет оцениваться
  • Когда и как часто будет оцениваться процесс
  • Как будет проведена оценка
  • Кто должен принимать участие в оценке

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

4. Идентифицируйте каждое несоответствие, найденное во время оценки.

5. Извлекайте опыт, который мог бы улучшить процессы.

СП 1.2 Объективно Оценивайте Рабочие Продукты

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

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

1. Отчеты по оценки

2. Отчеты по несоответствиям

3. Корректирующие действия

Подпрактики

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

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

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

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

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

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

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

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

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

4. Идентифицировать каждое несоответствие, найденное во время оценки.

5. Извлекать опыт, который мог бы улучшить процессы.

СЦ 2 Обеспечить Объективную Оценку

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

СП 2.1 Обсуждайте и Устраняйте Проблемы Несоответствия

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

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

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

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

1. Отчеты о корректирующих действиях

2. Отчеты об оценке

3. Тренды качества

Подпрактики

1. Решайте каждое несоответствие соответствующими членами команды, если это возможно.

2. Документируйте проблемы несоответствия, если они не могут быть решены в проекте.

Примеры способов решения несоответствия в проекте:

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

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

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

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

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

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

СП 2.2 Ведите Записи

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

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

1. Журналы оценок

2. Отчеты по качеству

3. Отчеты по состояниям корректирующих действий

4. Отчеты трендов качества

Подпрактики

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

2. Изменяйте состояние и историю задачи по обеспечению качества по мере необходимости.

Реклама

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

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 комментария »

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