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

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

Archive for Июль 2011

IBM Rational Jazz и MS Team System — одинаковые сценарии разными инструментами

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

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

  1. Создание требований
    1. IBM Rational Jazz
      Ролик демонстрирует некоторые возможности IBM Rational Requiremets Composer 3 для создания и редактирования требований, и связывания требований с элементами разработки и тестирования

    2. MS Team System
      Ролик демонстрирует некоторые возможности MS Visual Studio TFS 2010 для создания требований

  2. Создание плана работ
    1. IBM Rational Jazz
      Ролик демонстрирует некоторые возможности IBM Rational Team Concert 3 для создания плана работ на основе требований и связывания изменений с назначенными изменениями

    2. MS Team System
      Ролик демонстрирует некоторые возможности MS Visual Studio TFS 2010 для создания плана работ на основе требований и связывания изменений с назначенными изменениями

  3. Тестирование
    1. IBM Rational Jazz
      Ролик демонстрирует некоторые возможности IBM Rational Quality Manager 3 для создания тестов на основе требований, тестирования и регистрации дефектов

    2. MS Team System
      Ролик демонстрирует некоторые возможности MS Visual Studio TFS 2010 для создания тестов на основе требований, тестирования и регистрации дефектов.

Реклама

Posted in IBM Rational, Microsoft, Quality Manager, Requirements Composer, Team Concert, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

CMMI DEV v1.3 – Верификация

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

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

Инженерная процессная область уровня зрелости 3

Назначение

Назначением Верификации (ВЕР) является проверка того, что выбранные рабочие продукты удовлетворяют их указанным требованиям.

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

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

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

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

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

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

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

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

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

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

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

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

В Agile среде, верификация и валидация взаимно поддерживают друг друга вследствие вовлечения заказчиков и частых релизов. Например, дефект может быть причиной преждевременного провала валидации прототипа или раннего релиза. И наоборот, ранняя и непрерывная валидация помогает обеспечить применение верификации для разработки правильного продукта. Процессные области Верификация и Валидация позволяют обеспечить системный подход к выбору рабочих продуктов, которые будут рассмотрены и протестированы, методов и среды, которые будут использоваться, а также управление, которое поможет обеспечить раннее выявление и устранение дефектов. Чем сложнее продукт, тем более системный подход необходим для проверки совместимости между требования и решениями, а также соответствия с тем как продукт будет использоваться. (См. «CMMI при использовании Agile подходов» в части I.)

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

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

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

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

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

  • СЦ 1 Подготовиться к Верификации
    • СП 1.1 Выбирайте Рабочие Продукты для Верификации
    • СП 1.2 Устанавливайте Среду Верификации
    • СП 1.3 Устанавливайте Процедуры Верификации
  • СЦ 2. Выполнить Коллегиальные Оценки
    • СП 2.1 Подготавливайтесь к Коллегиальным Оценкам
    • СП 2.2 Проводите Коллегиальные Оценки
    • СП 2.3 Анализируйте Данные Коллегиальных Оценок
  • СЦ 3 Выполнить Верификацию для Выбранных Рабочих Продуктов
    • СП 3.1 Выполняйте Верификацию
    • СП 3.2 Анализируйте Результаты Верификации

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

СЦ 1 Подготовиться к Верификации

Проведена подготовка к верификации.

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

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

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

СП 1.1 Выбирайте Рабочие Продукты для Верификации

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

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

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

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

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

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

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

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

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

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

2. Методы верификации для каждого выбранного рабочего продукта

Подпрактики

1. Определяйте рабочие продукты для верификации.

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

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

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

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

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

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

СП 1.2 Устанавливайте Среду Верификации

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

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

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

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

1. Среда верификации

Подпрактики

1. Определяйте требования к среде верификации.

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

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

4. Приобретайте оборудование и среду для поддержки верификации (например, оборудование для тестирования, программное обеспечение).

СП 1.3 Устанавливайте Процедуры и Критерии Верификации

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

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

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

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

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

1. Процедуры верификации

2. Критерии верификации

Подпрактики

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

2. Разрабатывайте и уточняйте по мере необходимости критерии верификации.

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

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

СЦ 2 Выполнить Коллегиальные Оценки

Коллегиальные оценки выполнены для выбранных рабочих продуктов

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

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

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

СП 2.1 Подготавливайтесь к Коллегиальным Оценкам

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

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

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

1. График коллегиальных оценок

2. Контрольный список коллегиальной оценки

3. Критерии начала и окончания для рабочих продуктов

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

5. Коллегиальная оценка учебных материалов

6. Выбранные для рецензирования рабочие продукты

Подпрактики

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

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

  • Инспекции
  • Структурированный критический анализ
  • Активное рецензирование
  • Оценка соответствия архитектуры реализации

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

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

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

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

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

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

  • Правила построения
  • Руководства для проектирования
  • Полнота
  • Правильность
  • Возможность поддержки
  • Общие типы дефектов

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

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

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

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

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

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

  • Руководитель
  • Читатель
  • Записывающий
  • Автор

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

СП 2.2 Проводите Коллегиальные Оценки

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

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

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

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

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

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

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

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

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

2. Проблемы коллегиальных оценок

3. Данные коллегиальных оценок

Подпрактики

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

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

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

4. Собирайте данные коллегиальных оценок.

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

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

6. Проводите дополнительную коллегиальную оценку в случае необходимости.

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

СП 2.3 Анализируйте Данные Коллегиальных Оценок

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

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

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

1. Данные коллегиальных оценок

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

Подпрактики

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

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

2. Храните данные для дальнейшего использования и анализа.

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

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

4. Анализируйте данные коллегиальных оценок.

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

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

СЦ 3 Выполнить Верификацию Выбранных Рабочих Продуктов

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

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

СП 3.1 Выполняйте Верификацию

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

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

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

1. Результаты верификации

2. Отчеты верификации

3. Демонстрации

4. Журнал процедур запуска

Подпрактики

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

2. Записывайте результаты мероприятий по верификации.

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

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

СП 3.2 Анализируйте Результаты Верификации

Анализируйте результаты мероприятий верификации.

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

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

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

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

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

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

2. Отчеты о проблемах

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

Подпрактики

1. Сравнивайте фактические результаты с ожидаемыми результатами.

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

3. Анализируйте данные о дефектах.

4. Записывайте все результаты анализа в отчеты.

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

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

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

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

CMMI DEV v1.3 – Валидация

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

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

Инженерная процессная область уровня зрелости 3

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Подготовиться к Валидации
    • СП 1.1 Выбирайте Продукты для Валидации
    • СП 1.2 Устанавливайте Среду Валидации
    • СП 1.3 Устанавливайте Процедуры Валидации
  • СЦ 2 Выполнить Валидацию Продукта или Компонента Продукта
    • СП 2.1 Выполняйте Валидацию
    • СП 1.6 Анализируйте Результаты Валидации

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

СЦ 1 Подготовиться к Валидации

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

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

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

СП 1.1 Выбирайте Продукты для Валидации

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

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

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

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

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

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

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

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

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

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

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

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

2. Методы валидации для каждого продукта или компонента продукта

3. Требования для проведения валидации для каждого продукта или компонента продукта

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

Подпрактики

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

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

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

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

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

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

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

СП 1.2 Устанавливайте Среду Валидации

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

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

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

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

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

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

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

1. Среда валидации

Подпрактики

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

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

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

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

5. Детально планируйте наличие ресурсов.

СП 1.3 Установите Процедуры и Критерии Валидации

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

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

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

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

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

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

1. Процедуры валидации

2. Критерии валидации

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

Подпрактики

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

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

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

СЦ 2 Выполнить Валидацию Продукта или Компонента Продукта

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

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

СП 2.1 Выполняйте Валидацию

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

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

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

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

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

1. Отчеты валидации

2. Результаты валидации

3. Матрицы перекрестных ссылок валидации

4. Журнал процедур запуска

5. Операционные демонстрации

СП 2.2 Анализируйте Результаты Валидации

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

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

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

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

1. Отчеты об отклонениях валидации

2. Проблемы валидации

3. Запрос на изменение процедуры

Подпрактики

1. Сравнивайте фактические результаты с ожидаемыми результатами.

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

3. Анализируйте данные валидации на наличие дефектов.

4. Записывайте результаты анализа и выявленные проблемы.

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

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

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

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

CMMI DEV v1.3 – Анализ и Принятие Решений

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

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

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

Назначение

Назначением Анализа и Принятия Решений (АПР) является анализ возможных решений, используя формальный процесс оценки, который оценивает выявленные альтернативы на основе установленных критериев.

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

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

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

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

  • Установка критериев оценки альтернатив
  • Определение альтернативных решений
  • Выбор методов оценки альтернатив
  • Оценка альтернативных решений с использованием установленных критериев и методов
  • Выбор рекомендуемых решений из альтернатив на основе критериев оценки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Оценить Альтернативы
    • СП 1.1 Разрабатывайте Руководства для Анализа Решений
    • СП 1.2 Устанавливайте Критерии Оценки
    • СП 1.3 Определяйте Альтернативные Решения
    • СП 1.4 Выберите Методы Оценки
    • СП 1.5 Оценивайте Альтернативные Решения
    • СП 1.6 Выберите Решения

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

СЦ 1 Оценить Альтернативы

Решения приняты на основе оценки альтернатив с использованием установленных критериев.

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

СП 1.1 Разрабатывайте Руководства для Анализа Решений

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

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

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

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

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

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

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

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

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

Подпрактики

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

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

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

СП 1.2 Устанавливайте Критерии Оценки

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

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

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

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

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

1. Документированные критерии оценки

2. Ранги важности критериев

Подпрактики

1. Определяйте критерии оценки альтернативных решений.

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

Типы критериев, которые следует рассмотреть следующее:

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

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

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

3. Ранжируйте критерии.

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

4. Оценивайте критерии и их относительную важность.

5. Выявляйте критерии оценки для улучшения их достоверности.

6. Документируйте обоснование выбора и отказа от критериев оценки.

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

СП 1.3 Определяйте Альтернативные Решения

Определяйте альтернативные подходы к решению вопросов.

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

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

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

1. Выявленные альтернативы

Подпрактики

1. Выполняйте поиск существующих материалов.

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

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

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

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

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

3. Документируйте предложенные альтернативы.

СП 1.4 Выберите Методы Оценки

Выберите методов оценки.

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

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

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

1. Выбранные методы оценки

Подпрактики

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

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

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

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

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

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

3. Определите меры, необходимые для поддержки метода оценки.

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

СП 1.5 Оценивайте Альтернативные Решения

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

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

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

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

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

Подпрактики

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

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

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

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

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

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

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

6. Документируйте результаты оценки.

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

СП 1.6 Выберите Решения

Выберите решения из альтернатив на основе критериев оценки.

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

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

1. Рекомендуемые решения для решения важных вопросов

Подпрактики

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

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

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

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

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

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

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

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