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

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

Archive for Сентябрь 2011

CMMI DEV v1.3 – Определение Организационных Процессов

Posted by Шамрай Александр на Сентябрь 26, 2011

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Установить Организационные Активы Процессов
    • СП 1.1 Устанавливайте Стандартные Процессы
    • СП 1.2 Устанавливайте Описания Модели Жизненного Цикла
    • СП 1.3 Устанавливайте Критерии и Руководства по Адаптации
    • СП 1.4 Устанавливайте Хранилище Измерений Организации
    • СП 1.5 Устанавливайте Библиотеку Активов Процесса Организации
    • СП 1.6 Устанавливайте Стандарты Рабочей Среды
    • СП 1.7 Устанавливайте Правила и Руководства для Команд

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

СЦ 1 Установить Организационные Активы Процессов

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

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

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

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

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

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

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

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

1. Набор стандартных процессов организации

Подпрактики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СП 1.2 Устанавливайте Описания Модели Жизненного Цикла

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

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

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

1. Описания моделей жизненного цикла

Подпрактики

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

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

  • Водопадная или Последовательная
  • Спиральная
  • Эволюционная
  • Инкрементальная
  • Итерационная

2. Документируйте описания моделей жизненного цикла.

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

3. Проводите коллегиальные оценки моделей жизненного цикла.

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

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

СП 1.3 Устанавливайте Критерии и Руководства по Адаптации

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

Критерии и руководства по адаптации описывают следующее:

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

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

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

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

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

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

Критерии и руководства адаптации могут позволять использование стандартного процесса «как он есть» без какой-либо адаптации.

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

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

Подпрактики

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

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

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

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

  • Изменение модели жизненного цикла
  • Сочетание элементов различных моделей жизненного цикла
  • Изменение элементов процесса
  • Замена элементов процесса
  • Изменение порядка элементов процесса

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

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

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

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

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

6. Пересматривайте руководства по адаптации по мере необходимости.

СП 1.4 Устанавливайте Хранилище Измерений Организации

Устанавливайте и поддерживайте хранилище измерений организации.

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

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

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

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

2. Проектирование хранилища измерений организации

3. Хранилище измерений организации (например, структура хранилища, среды поддержки)

4. Данные измерений организации

Подпрактики

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

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

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

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

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

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

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

3. Разрабатывайте и внедряйте хранилище измерений.

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

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

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

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

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

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

6. Вводите указанные меры в хранилище.

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

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

8. Пересматривайте хранилище измерений, общий набор мер и процедур при изменении потребностей организации.

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

  • Добавляются новые процессы
  • Процессы пересмотрены и необходимы новые меры
  • Требуется более подробная детализация данных
  • Требуется повышение прозрачности процесса
  • Меры удаляются

СП 1.5 Устанавливайте Библиотеку Активов Процессов Организации

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

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

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

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

1. Проектирование библиотеки активов процессов организации

2. Библиотека активов процессов организации

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

4. Каталог элементов в библиотеке активов процессов организации

Подпрактики

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

2. Указывайте критерии для включения элементов в библиотеку.

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

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

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

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

6. Периодически пересматривайте использование каждого элемента.

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

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

  • Добавляются новые элементы
  • Элементы удаляются
  • Изменились текущие версии элементов

СП 1.6 Устанавливайте Стандарты Рабочей Среды

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

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

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

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

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

1. Стандарты рабочей среды

Подпрактики

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

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

СП 1.7 Устанавливайте Правила и Руководства для Команд

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

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

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

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

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

1. Правила и руководства для структурирования и формирования команд

2. Операционные правила для команд

Подпрактики

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

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

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

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

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

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

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

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

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

CMMI DEV v1.3 – Организационное Обучение

Posted by Шамрай Александр на Сентябрь 19, 2011

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СЦ 1 Установить Возможности для Организационного Обучения

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

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

СП 1.1 Устанавливайте Стратегические Потребности в Обучении

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

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

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

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

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

1. Потребности в обучении

2. Оценочный анализ

Подпрактики

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

2. Документируйте стратегические потребности обучения в организации.

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

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

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

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

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

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

СП 1.2 Определяйте Какие Потребности в Обучении в Ответственности Организации

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

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

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

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

1. Общие потребности обучения для проектов и групп поддержки

2. Обязательства по обучению

Подпрактики

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

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

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

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

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

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

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

СП 1.3 Устанавливайте Тактический План Обучения Организации

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

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

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

1. Тактический план обучения организации

Подпрактики

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

Тактические планы обучения организации обычно содержат следующее:

  • Потребности в обучении
  • Темы обучения
  • Расписания на основе учебной деятельности и их зависимостей
  • Методы, используемые для обучения
  • Требования и стандарты качества учебных материалов
  • Задачи обучения, роли и обязанности
  • Требуемые ресурсы, включая инструменты, оборудование, персонал, навыки и знания

2. Устанавливайте обязательства выполнения к плану.

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

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

СП 1.4 Устанавливайте Возможности для Обучении

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

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

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

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

Подпрактики

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

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

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

  • Обучение в классах
  • Компьютерное обучение
  • Руководства для самостоятельного обучения
  • Формальное ученичество и наставничество
  • Обучающее видео
  • Обучение с помощью доски и мела
  • Семинары во время обеда
  • Структурированное по месту в работе обучение

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

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

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

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

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

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

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

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

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

  • Курсы
  • Компьютерное обучение
  • Видео

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

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

5. Описывайте обучение в программе обучения организации.

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

  • Темы, затрагиваемые в обучении
  • Целевая аудитория
  • Предварительные требования и подготовка для участия
  • Цели обучения
  • Длительность обучение
  • Планы занятий
  • Критерии завершения курса
  • Критерии для предоставления отказа от обучения

6. Пересматривайте учебные материалы и артефакты поддержки по мере необходимости.

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

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

СЦ 2 Обеспечить Обучение

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

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

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

СП 2.1 Проводите Обучение

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

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

1. Проведенные обучающие курсы

Подпрактики

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

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

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

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

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

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

3. Проводите обучение.

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

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

СП 2.2 Устанавливайте Протоколы Обучения

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

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

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

1. Протоколы обучения

2. Обновления обучений в хранилище организации

Подпрактики

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

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

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

3. Ведите учет всех студентов, успешно окончивших их необходимое обучение.

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

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

СП 2.3 Оценивайте Эффективность Обучения

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

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

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

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

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

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

1. Оценка эффективности обучения

2. Оценки выполнения программы обучения

3. Форма оценки инструктора

4. Экзамены по обучению

Подпрактики

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

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

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

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

CMMI DEV v1.3 – Интеграция Продукта

Posted by Шамрай Александр на Сентябрь 16, 2011

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Подготовиться к Интеграции Продукта
    • СП 1.1 Устанавливайте Стратегию Интеграции
    • СП 1.2 Устанавливайте Среду Интеграции Продукта
    • СП 1.3 Устанавливайте Процедуры и Критерии Интеграции Продукта
  • СЦ 2. Проверить Совместимость Интерфейсов
    • СП 2.1 Оценивайте Полноту Описания Интерфейсов
    • СП 2.2 Управляйте Интерфейсами
  • СЦ 3 Собрать Компоненты Продукта и Поставить Продукт
    • СП 3.1 Подтверждайте Готовность Компонентов Продукта к Интеграции
    • СП 3.2 Соберите Компоненты Продукта
    • СП 3.3 Оценивайте Собранные Компоненты Продукта
    • СП 3.4 Упаковывайте и Поставьте Продукт или Компонент Продукта

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

СЦ 1 Подготовиться к Интеграции Продукта

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

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

СП 1.1 Устанавливайте Стратегию Интеграции

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

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

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

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

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

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

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

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

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

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

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

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

1. Стратегия интеграции продукта

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

Подпрактики

1. Определяйте компоненты продукта для интеграции.

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

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

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

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

4. Выберите лучшую стратегию интеграции.

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

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

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

6. Записывайте обоснование принимаемых решений и задержек.

СП 1.2 Устанавливайте Среду Интеграции Продукта

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

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

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

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

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

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

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

Подпрактики

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

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

3. Решите, следует ли сделать или купить необходимую среду для интеграции продукта.

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

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

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

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

6. Утилизируйте те части среды, которые больше бесполезны.

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

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

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

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

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

  • Уровень тестирования сборки компонентов
  • Верификация интерфейсов
  • Пороговые значения отклонения производительности
  • Производные требования для сборки и ее внешних интерфейсов
  • Допустимые замены компонентов
  • Тестирование параметров среды
  • Ограничения на стоимость тестирования
  • Компромиссы для качества/стоимости операций интеграции
  • Вероятность правильного функционирования
  • Скорость доставки и ее вариации
  • Время от заказа до поставки
  • Наличие персонала
  • Наличие средств/линии/среды интеграции

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

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

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

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

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

1. Процедуры интеграции продукта

2. Критерии интеграции продукта

Подпрактики

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

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

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

СЦ 2 Проверить Совместимость Интерфейсов

Интерфейсы компонентов продукта и внутренние и внешние совместимы.

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

СП 2.1 Оценивайте Полноту Описания Интерфейсов

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

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

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

1. Категории интерфейсов

2. Список интерфейсов в каждой категории

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

Подпрактики

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

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

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

  • Механические интерфейсы (например, вес и размер, центр тяжести, чистота деталей в эксплуатации, пространство, необходимое для обслуживания, стационарные связи, мобильные связи, удары и вибрации, полученные от несущей конструкции)
  • Шумовые интерфейсы (например, шум передаваемый структурой, шум передаваемый по воздуху, акустика)
  • Климатические интерфейсы (например, температура, влажность, давление, соленость)
  • Тепловые интерфейсы (например, тепло, теплопередача несущей конструкции, характеристики кондиционирования)
  • Жидкостные интерфейсы (например, пресная вода на входе/выходе, морская вода на входе/выходе для морских/прибрежных продуктов, кондиционирование воздуха, сжатый воздух, азот, топливо, смазочные масла, отработавшие газы)
  • Электрические интерфейсы (например, потребляемая мощность сети с переходными и пиковыми значениями; нечувствительный управляющей сигнал для питания и связи; чувствительный сигнал [например, аналоговые связи]; нарушающий сигнал [например, микроволны]; сигнал заземления для соблюдения стандарта TEMPEST)
  • Электромагнитные интерфейсы (например, магнитное поле, радио- и радиолокационные связи, руководства по длине оптических волн, коаксиальные и оптические кабеля)
  • Человеко-машинные интерфейсы (например, аудио синтез или синтез речи, распознавание аудио или голоса, дисплей [аналоговый циферблат, жидкокристаллический дисплей, светодиодные индикаторы], ручное управление [педаль, джойстик, трекбол, клавиатура, кнопки, сенсорный экран])
  • Интерфейсы сообщений (например, происхождение, место назначения, стимул, протоколы, характеристики данных)

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

3. Периодически пересматривайте адекватность описания интерфейсов.

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

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

СП 2.2 Управляйте Интерфейсами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Задачи для обновления интерфейсов

6. Программный интерфейс приложения (API)

7. Обновленное описание или соглашение по интерфейсу

Подпрактики

1. Проверяйте совместимость интерфейсов на протяжении всей жизни продукта.

2. Решайте конфликты, несоответствия и проблемы изменений.

3. Поддерживайте хранилище для данных по интерфейсам доступным для участников проекта.

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

СЦ 3 Собрать Компоненты Продукта и Поставить Продукт

Верифицированные компоненты продукта собраны и интегрированные, верифицированные и валидированные продукты поставлены.

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

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

СП 3.1 Подтверждайте Готовность Компонентов Продукта к Интеграции

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

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

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

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

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

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

2. Акты о поставке

3. Проверенные упаковочные списки

4. Отчеты по исключениям

5. Отказные листы

Подпрактики

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

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

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

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

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

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

СП 3.2 Соберите Компоненты Продукта

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

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

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

1. Собранный продукт или компоненты продукта

Подпрактики

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

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

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

3. Пересматривайте по мере необходимости стратегию интеграции продукта, процедуры и критерии.

СП 3.3 Оценивайте Собранные Компоненты Продукта

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

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

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

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

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

1. Отчеты по исключениям

2. Отчеты оценки интерфейсов

3. Итоговые отчеты интеграции продукта

Подпрактики

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

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

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

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

СП 3.4 Упаковывайте и Поставьте Продукт или Компонент Продукта

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

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

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

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

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

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

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

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

2. Документация по поставке

Подпрактики

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

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

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

  • Магнитная лента
  • Дискеты
  • Печатные документы
  • Компактные диски
  • Другие пути электронного распространения, такие как Интернет

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

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

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

  • Типы хранилищ и средства поставки
  • Хранилища основных и резервных копий
  • Необходимые документы
  • Авторское право
  • Положения лицензий
  • Безопасность программного обеспечения

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

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

5. Поставляйте продукт и соответствующую документацию и подтверждайте получение.

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

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

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

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