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

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

Archive for Февраль 2011

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 Шамрай Александр на Февраль 21, 2011

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

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

Назначение

Назначением Разработки Требований (РТ) является выявление, анализ и установка требований заказчика, продукта и компонентов продукта.

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

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

Все проекты разработки имеют требования. Требования являются основой для проектирования. Разработка требований включает в себя следующие мероприятия:

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

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

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

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

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

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

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

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

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

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

  • Ограничения различных типов
  • Технологические ограничения
  • Затраты и управление затратами
  • Ограничение по времени и управление графиком
  • Риски
  • Рассмотрение вопросов подразумеваемых, но прямо не указанных заказчиком или конечным пользователем
  • Факторы, введенные уникальными бизнес соображениями разработки, правилами и законами

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Разработать Требования Заказчика
    • СП 1.1 Выявляйте Потребности
    • СП 1.2 Трансформируйте Потребности Заинтересованных Сторон в Требования Заказчика
  • СЦ 2 Разработать Требования к Продукту
    • СП 2.1 Устанавливайте Требования к Продукту и Компонентам Продукта
    • СП 2.2 Распределите Требования к Компонентам Продукта
    • СП 2.3 Идентифицируйте Требования к Интерфейсам
  • СЦ 3 Выполнить Анализ и Валидацию Требований
    • СП 3.1 Устанавливайте Операционную Концепцию и Сценарии
    • СП 3.2 Устанавливайте Определение Необходимой Функциональности и Атрибутов Качества
    • СП 3.3 Анализируйте Требования
    • СП 3.4 Анализируйте Требования для Достижения Баланса
    • СП 3.5 Выполняйте Валидацию Требования

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

СЦ 1 Разработать Требования Заказчика

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

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

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

СП 1.1 Выявляйте Потребности

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

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

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

  • Технологические демонстрации
  • Рабочие группы контроля взаимодействия
  • Рабочие группы технического контроля
  • Промежуточный проектный анализ
  • Анкетирование, интервью и сценарии (операционные, поддержки и разработки), полученных от конечных пользователей
  • Операционный анализ, анализ поддержки и разработки и анализ задач конечных пользователей
  • Семинары с заинтересованными сторонами по выявлению атрибутов качества
  • Прототипы и модели
  • Мозговой штурм
  • Развертывание Функций Обеспечения Качества
  • Исследования рынка
  • Бета-тестирование
  • Извлечение из источников, таких как документы, стандарты или спецификации
  • Наблюдение за существующими продуктами, условиями работы и рабочими моделями
  • Сценарии использования
  • Пользовательские истории
  • Предоставление небольших инкрементальных «вертикальных срезов» функциональности продукта
  • Анализ бизнес сценариев
  • Обратный инжиниринг (для наследуемых продуктов)
  • Исследования удовлетворенности заказчиков

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

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

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

1. Результаты деятельности выявления требований

Подпрактики

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

СП 1.2 Трансформируйте Потребности Заинтересованных Сторон в Требования Заказчика

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

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

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

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

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

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

2. Ограничения заказчика на проведение верификации

3. Ограничения заказчика на проведение валидации

Подпрактики

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

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

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

3. Определите ограничения для верификации и валидации.

СЦ 2 Разработать Требования к Продукту

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

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

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

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

СП 2.1 Установите Требования к Продукту и Компонентам Продукта

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

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

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

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

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

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

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

1. Производные требования

2. Требования к продукту

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

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

Подпрактики

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

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

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

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

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

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

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

  • Время ответа до 1 секунды
  • Доступность системы 99% времени
  • Внедрение изменений не превышает недельные трудозатраты одного сотрудника

4. Установите и поддерживайте связи между требованиями для рассмотрения в ходе управления изменениями и распределения требований.

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

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

СП 2.2 Выделите Требования к Компонентам Продукта

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

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

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

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

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

2. Предварительное распределение требования

3. Ограничения проектирования

4. Производные требования

5. Связи между производными требованиями

Подпрактики

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

2. Распределяйте требования по компонентам продукта и архитектуре.

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

4. Распределяйте требования по инкрементам поставки.

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

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

СП 2.3 Идентифицируйте Требования к Интерфейсам

Идентифицируйте требования к интерфейсам

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

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

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

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

1. Требования к интерфейсам

Подпрактики

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

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

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

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

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

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

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

СЦ 3 Выполнить Анализ и Валидацию Требований

Требования проанализированы и провалидированы.

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

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

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

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

СП 3.1 Устанавливайте Операционные Концепции и Сценарии

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

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

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

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

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

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

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

3.Концепции утилизации

4. Сценарии использования

5. Повременные сценарии

6. Новые требования

Подпрактики

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

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

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

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

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

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

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

СП 3.2 Устанавливайте Определение Необходимой Функциональности и Атрибутов Качества

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

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

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

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

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

2. Функциональная архитектура

3. Диаграммы активности и сценарии использования

4. Объектно-ориентированный анализ с идентифицированными сервисами или методами

5. Архитектурно значимые требования атрибутов качества

Подпрактики

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

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

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

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

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

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

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

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

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

8. Распределяйте требования по функциям и подфункциям (или другим логическим сущностям).

СП 3.3 Анализируйте Требования

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

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

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

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

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

1. Отчеты по дефектам требований

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

3. Ключевые требования

4. Меры технических характеристик

Подпрактики

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

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

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

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

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

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

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

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

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

СП 3.4 Анализируйте Требования для Достижения Баланса

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

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

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

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

Подпрактики

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

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

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

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

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

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

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

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

СП 3.5 Выполняйте Валидацию Требования

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

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

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

  • Анализ
  • Симуляция
  • Построение прототипов
  • Демонстрация

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

1. Записи по методам и результатам анализа

Подпрактики

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

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

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

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

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

CMMI DEV v1.3 – Измерения и Анализ

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

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

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

Назначение

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

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

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

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

Интеграция мероприятий измерения и анализа в процессы проекта предназначена для поддержки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Привести в Соответствие Мероприятия по Измерению и Анализу
    • СП. 1.1 Установите Цели Измерения
    • СП 1.2 Определите Меры
    • СП 1.3 Определите Процедуры Сбора и Хранения Данных
    • СП 1.4 Определите Процедуры Анализа
  • СЦ 2 Предоставить Результаты Измерений
    • СП 2.1 Получайте Данные Измерений
    • СП 2.2 Анализируйте Данные Измерений
    • СП 2.3 Сохраняйте Данные и Результаты
    • СП 2.4 Предоставляйте Результаты

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

СЦ 1 Привести в Соответствие Мероприятия по Измерению и Анализу

Цели и мероприятия измерений приведены в соответствие с выявленными информационными потребностями и целями.

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

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

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

СП. 1.1 Установите Цели Измерения

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Цели измерения

Подпрактики

1. Документируйте информационные потребности и цели.

2. Устанавливайте приоритеты информационным потребностям и целям.

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

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

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

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

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

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

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

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

Необходимо дать полный ответ на вопрос «Почему мы замеряем это?»

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

СП 1.2 Определите Меры

Определите меры для решения целей измерения.

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

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

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

Примеры наиболее часто используемых базовых мер:

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

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

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

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

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

Таблица ИА.1: Пример взаимосвязи измерений

Пример проектных, организационных, или бизнес-целей Необходимая информация Цели измерения Категории измерения информации Пример базовых мер Пример производных мер
Сокращение времени поставки

Быть первыми на рынке продукта

Что является расчетным временем поставки? Обеспечить понимание колебаний и прогресса графика График и прогресс Оценочные и фактические даты начала и окончания задачи Вехи выполнения

Процент проекта по времени

Оценка точности графика

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

Отклонение стоимости

Доставка специфической функциональности Границы или размер проекта выросли? Обеспечить понимание фактического размера по сравнению с планом, выявить незапланированный рост Размер и стабильность Количество требований Изменчивость требований

Точность оценки размера

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

Размер продукта

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

Плотность дефектов

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

Часы трудозатрат, потраченные для исправления дефектов

Стоимость работ

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

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

1. Спецификации базовых и производных мер

Подпрактики

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

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

2. Поддерживайте трассировку от мер к их целям измерений.

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

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

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

4. Указывайте операционные определения для мер.

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

  • Коммуникация: Что было измерено, как это было измерено, какие единицы измерения, и что было включено или исключено?
  • Повторяемость: Измерения можно повторить с учетом того же определения и так чтобы получить тот же результат?

5. Устанавливайте приоритеты, пересматривайте и обновляйте меры.

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

СП 1.3 Определите Процедуры Сбора и Хранения Данных

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

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

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

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

1. Процедуры сбора и хранения данных

2. Инструменты сбора данных

Подпрактики

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

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

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

3. Указывайте, как собирать и хранить данные для каждой необходимой меры.

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

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

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

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

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

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

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

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

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

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

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

СП 1.4 Определите Процедуры Анализа

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

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

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

1. Анализ спецификаций и процедур

2. Средства анализа данных

Подпрактики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СЦ 2 Предоставить Результаты Измерения

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

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

СП 2.1 Получайте Данные Измерений

Получайте указанные данные измерений.

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

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

1. Базовые и производные наборы данных измерений

2. Результаты тестов целостности данных

Подпрактики

1. Получайте данные для базовых мер.

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

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

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

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

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

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

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

СП 2.2 Анализируйте Данные Измерений

Выполняйте анализ и интерпретацию данных измерений.

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

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

1. Анализ результатов и промежуточные отчеты

Подпрактики

1. Проводите первичный анализ, интерпретацию результатов и делайте предварительные выводы.

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

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

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

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

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

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

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

4. Уточняйте критерии для будущих анализов.

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

SP 2.3 Сохраняйте Данные и Результаты

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

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

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

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

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

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

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

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

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

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

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

1. Оборудование хранения данных

Подпрактики

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

2. Храните данные в соответствии с процедурами хранения данных.

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

4. Предотвращайте использование хранимой информации не по назначению.

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

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

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

СП 2.4 Предоставляйте Результаты

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

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

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

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

1. Поставляемые отчеты и связанные с ними результаты анализа

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

Подпрактики

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

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

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

2. Помогайте соответствующим заинтересованным сторонам понять результаты.

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

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

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

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

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

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

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