Уровень 3 (определенный – defined) подвергся наиболее значительным изменениям, хотя и сохранил свое прежнее название. Процесс на этом уровне характеризует уже организацию-разработчика и часто является проактивным. В модели CMMI на этом уровне 11 областей процесса вместо прежних 7 ключевых областей модели CMM. Области (8)-(10) сохранились под теми же или слегка измененными названиями, что и в модели CMM, область (11) объединила в себе 2 прежние ключевые области, и к ним добавились еще 7 новых областей, вобравших в себя прежние 3 ключевые области модели CMM.
Уровень 4 (количественно управляемый – quantitatively managed) сменил прежнее название «управляемый», чтобы подчеркнуть особую роль метрик в процессе этого уровня. Процесс этого уровня измеряем и контролируем. Прежние две области объединились в одну, и добавилась одна новая.
Уровень 5 (оптимизирующий – optimizing) сохранил свое название и сфокусирован на постоянное улучшение самого себя. Он состоит теперь из двух областей процесса вместо прежних трех ключевых областей.
Области процесса разделены на 4 категории: управление процессом, управление проектом, инженерная и поддержка (Рис. 26).
Рис. 26. Группировка процессных областей в модели CMMI
Каждая область появляется на определенном уровне зрелости и должна присутствовать на всех последующих уровнях. Распределение процессных областей по уровням зрелости показано на Рис. 27.
Такое четкое разграничение процессных областей на собственно инженерную деятельность, управление проектом, управление процессом и поддержку, помогает лучше фокусироваться соответствующим исполнителям на своих прямых обязанностях, и способствует более оперативному и профессиональному решению соответствующих производственных вопросов.
Рис. 27. Восхождение по уровням зрелости
В модели CMMI введено понятие «уровня способностей» (capability level – CL) процесса, которое характеризует степень владения данным разработчиком той или иной процессной областью. Различают четыре таких уровня, нумеруемых от 0 до 3; уровень считается достигнутым, если достижение всех общих целей отвечает ему и при этом:
0 – неполный (incomplete) – процесс либо не исполняется вообще, либо исполняется только частично; одна или более специфичных целей данной процессной области не достигается (достижение общих целей здесь не рассматривается);
1 – исполняемый (performed) – выполняется вся необходимая работа для создания рабочих продуктов и все специфические цели процессной области достигаются;
2 – управляемый (managed) – имеет место исполняемый процесс, который при этом планируется и исполняется в соответствии с политикой, в котором работает обученный персонал, имеющий адекватные ресурсы для производства контролируемых результатов, в отношении которого ведется наблюдение, контроль и обзоры, и который оценивается на соответствие своему описанию;
3 – определенный (defined) – имеет место управляемый процесс, который выводится подгонкой из набора стандартных процессов организации в соответствии с руководствами по подгонке, причем имеется поддерживаемое описание этого процесса, а накапливаемый процессный опыт вносит вклад в процессные активы организации.
Таким образом, появляется возможность оценивать уровень способностей в той или иной процессной области, независимо от общего уровня зрелости организации и построения так называемого «профиля организации» по областям процесса, который отражает текущий уровень способностей в данной процессной области и целевое значение для него. Для многих организаций такое «непрерывное» отображение состояния ее процесса может оказаться более информативным и стимулирующим к дальнейшему совершенствованию, чем пятиступенная характеристика ее общего уровня зрелости.
Пример такого представления процессного профиля организации представлен на Рис. 28. Для каждой из 22-х областей процесса указано целевое значения для уровня ее усвоения (красный кружок) и текущей значение этого уровня (столбик).
Рис. 28. Пример процессного профиля организации в модели CMMI
Для каждой отдельной области процесса модель CMMI определяет от 1 до 3 специальных целей (Specific Goal – SG), характерных именно для этой области, и 3 общие цели (Generic Goal – GG), одни и те же для всех процессных областей:
GG1. Достигать специфические цели данной процессной области;
GG2. Наладить в организации управляемый процесс;
GG3. Наладить в организации определенный процесс.
Таким образом, общие цели 2 и 3 соответствуют достижению организацией соответствующего уровня зрелости в модели CMMI; их достижение в конкретной процессной области означает заметное улучшение контроля в планировании и осуществлении деятельностей, связанных с этой областью.
Заявленные цели достигаются путем применения описанных в модели практик, специальных (Specific Practice – SP) для специальных целей и общих (Generic Practice – GP) для общих целей. Однако сами эти практики не являются обязательными, а только ожидаемыми элементами процесса разработки, которые, по мнению авторов модели CMMI, способствуют достижению целей данной процессной области. Организация-разработчик или отдельные проект в ней могут ввести собственные практики, наряду с теми, или вместо тех, какие описаны в модели, причем практики могут содержать более мелкие подпрактики (associated subpractices) или быть уточнением (elaboration) какой-либо из описанных в модели практик. Результатами исполнения практик являются определенные рабочие продукты, перечень которых также может изменяться от проекта к проекту.
Пример из определения процессной области «Планирование проекта»:
Специальная цель: SG1 Создаются и поддерживаются оценки параметров проектного плана
Специальная практика: SP1.1 Устанавливать высокоуровневую структуру разбиения работ для оценки области приложения проекта
Соответствующие подпрактики:
- Разработать структуру разбиения работ исходя из программной архитектуры
- Определить пакеты работ со степенью подробности, достаточной для задания
оценок проектных задач, ответственностей и графика
- Определить рабочие продукты, которые будут повторно использованы в
данном проекте или приобретены для него
Общие практики (Табл. 14) имеют составной номер: первое число означает номер общей цели (от 1 до 3) из приведенного выше списка, второе число – порядковый номер данной общей практики.
Табл. 14. Общие цели и практики в модели CMMI
Общие цели |
Общие практики |
GG1: Достигать специфические цели |
GP1.1 Выполнять специфические практики для достижения специфических целей данной процессной области |
GG2. Наладить управляемый процесс |
GP2.1 Устанавливать и поддерживать политику организации для планирования и исполнения процесса GP2.2 Устанавливать и поддерживать план по исполнению процесса GP2.3 Обеспечивать адекватные ресурсы для исполнения процесса, разработки его рабочих продуктов и предоставления его услуг GP2.4 Распределять ответственности и полномочия для исполнения процесса, разработки его рабочих продуктов и предоставления услуг GP2.5 Проводить переподготовку людей, исполняющих или поддерживающих процесс по мере необходимости GP2.6 Контролировать выбранные рабочие продукты процесса по соответствующим уровням контроля GP2.7 Выявлять и привлекать значимых прикосновенных лиц процесса в соответствии с планом GP2.8 Наблюдать за процессом и контролировать его исполнение в сравнении с планом исполнения и предпринимать соответствующие поправочные действия GP2.9 Объективно оценивать соответствие процесса и выбранных рабочих продуктов описанию процесса, стандартам и процедурам, и действовать при обнаружении несоответствий GP2.10 Проводить обзор деятельностей, текущего состояния и результатов исполнения процесса с руководством более высокого уровня и разрешать проблемы |
GG3. Наладить определенный процесс |
GP3.1 Создавать и поддерживать описание определенного процесса GP3.2 Накапливать связанный с процессом опыт планирования и исполнения процессов для последующего использования и улучшения процессов организации и процессных активов GP3.3 Объективно оценивать соответствие процесса и выбранных рабочих продуктов описанию процесса, стандартам и процедурам, и действовать при обнаружении несоответствий |
Перечень специальных целей и ожидаемых специальных практик, сгруппированный по областям процесса, приведен в Табл. 15.
Табл. 15. Специальные цели и практики процессных областей
Процессная область (PA) и ее назначение |
Специальные цели (SG) |
Специальные практики (SP) |
(CAR) Анализ причин и разрешение (Causal Analysis and Resolution) – Выявлять причины выбранных показателей и предпринимать действия по улучшению хода процессов |
SG1. Определить причины выбранных показателей – Determine Causes of Selected Outcomes |
SP1.1 Отбирать показатели для анализа – Select Outcomes for Analysis SP1.2 Анализировать причины – Analyze Causes |
SG2. Воздействовать на причины выбранных показателей – Address Causes of Selected Outcomes |
SP2.1 Реализовывать предложения по действиям – Implement Action Proposals SP2.2 Оценивать эффект реализованных действий – Evaluate the Effect of Implemented Actions SP2.3 Сохранять данный по причинно-следственному анализу – Record Causal Analysis Data |
|
(CM) Управление конфигурацией (Configuration Management) – Установить и поддерживать целостность рабочих продуктов, используя идентификацию, контроль и состояние конфигурации |
SG1. Установить базовые версии – Establish Baselines |
SP1.1 Выявлять элементы конфигурации – Identify Configuration Items SP1.2 Устанавливать систему управления конфигурацией – Establish a Configuration Management System SP1.3 Создавать/выпускать базовые версии – Create or Release Baselines |
SG2. Отслеживать и контролировать изменения – Track and Control Changes |
SP2.1 Отслеживать запросы на изменения – Track Change Request SP2.2 Контролировать элементы конфигурации – Control Configuration Items |
|
SG3. Установить целостность – Establish Integrity |
SP3.1 Устанавливать записи управления конфигурацией – Establish Configuration Management Records SP3.2 Проводить аудиты конфигурации – Perform Configuration Audits |
|
(DAR) Анализ и принятие решений (Decision Analysis and Resolution) – Принимать решения на основе структурного подхода, который оценивает выявленные альтернативы по установленным критериям |
SG1. Оценивать альтернативы – Evaluate Alternatives |
SP1.1 Создавать руководства по анализу решений – Establish Guidelines for Decision Analysis SP1.2 Устанавливать критерии оценки – Establish Evaluation Criteria SP1.3 Выявлять альтернативные решения – Identify Alternative Solutions SP1.4 Выбирать методы оценки – Select Evaluation Methods SP1.5 Оценивать альтернативные решения – Evaluate Alternative Solutions SP1.6 Выбирать решения – Select Solutions |
(IPM) Интегрированное управление проектом (Integrated Project Management) – Запустить ход проекта с вовлечением в него значимых прикосновенных лиц и управлять им в соответствии с интегрированным и определенным процессом, полученным подгонкой из набора стандартных процессов организации |
SG1. Использовать определенный проектный процесс – Use the Project’s Defined Process |
SP1.1 Устанавливать определенный процесс проекта – Establish the Project’s Defined Process SP1.2 Использовать процессные активы организации для планирования деятельностей по проекту – Use Organizational Process Assets for Planning Project Activities SP1.3 Создавать условия для работ по проекту – Establish the Project's Work Environment SP1.4 Интегрировать планы – Integrate Plans SP1.5 Управлять проектом по интегрированным планам – Manage the Project Using Integrated Plans SP1.6 Создавать проектные группы – Establish Teams SP1.7 Пополнять процессные активы организации – Contribute to Organizational Process Assets |
SG2. Координироваться и сотрудничать со значимыми прикосновенными лицами – Coordinate and Collaborate with Relevant Stakeholders |
SP2.1 Управлять вовлечением прикосновенных лиц – Manage Stakeholder Involvement SP2.2 Управлять зависимостями – Manage Dependencies SP2.3 Разрешать проблемы координации – Resolve Coordination Issues |
|
(MA) Измерения и анализ (Measurement and Analysis) – Развивать и поддерживать способность к измерениям для обеспечения потребностей в информации для управления |
SG1. Выстроить деятельности по измерениям и анализу– Align Measurement and Analysis Activities |
SP1.1 Устанавливать цели измерений – Establish Measurement Objectives SP1.2 Задавать метрики – Specify Measures SP1.3 Задавать процедуры сбора и хранения данных – Specify Data Collection and Storage Procedures SP1.4 Задавать процедуры анализа – Specify Analysis Procedures |
|
SG2. Поставлять результаты измерений – Provide Measurement Results |
SP2.1 Получать данные измерений – Obtain Measurement Data SP2.2 Анализировать данные измерений – Analyze Measurement Data SP2.3 Хранить данные и результаты – Store Data and Results SP2.4 Сообщать о результатах – Communicate Results |
(OPD) Определение процесса организации (Organization Process Definition) – Создать и поддерживать используемый набор процессных активов организации |
SG1. Создать набор процессных активов организации – Establish Organizational Process Assets |
SP1.1 Устанавливать стандартные процессы – Establish Standard Processes SP1.2 Устанавливать описания моделей ЖЦ – Establish Lifecycle Model Descriptions SP1.3 Устанавливать критерии и указания для подгонки – Establish Tailoring Criteria and Guidelines SP1.4 Создавать хранилище измерений для организации – Establish the Organization’s Measurement Repository SP1.5 Создавать библиотеку процессных активов организации – Establish the Organization’s Process Asset Library SP1.6 Устанавливать стандарты рабочей среды – Establish Work Environment Standards SP1.7 Устанавливать правила и руководства для проектных групп – Establish Rules and Guidelines for Teams |
(OPF) Нацеленность процесса (Organization Process Focus) – Установить и поддерживать понимание процессов и процессных активов организации, определять, планировать и осуществлять деятельности по улучшению процесса организации |
SG1. Определять возможности для улучшения процесса – Determine Process Improvement Opportunities |
SP1.1 Устанавливать потребности процесса организации – Establish Organizational Process Needs SP1.2 Оценивать процессы в организации – Appraise the Organization’s Processes SP1.3 Выявлять улучшения процесса организации – Identify the Organization's Process Improvements |
SG2. Планировать и осуществлять деятельности по процессу – Plan and Implement Process Actions |
SP2.1 Устанавливать планы действий по процессу – Establish Process Action Plans SP2.2 Реализовывать планы действий по процессу – Implement Process Action Plans |
|
SG3. Внедрять процессные активы организации и внедрять полученный опыт – Deploy Organizational Process Assets and Incorporate Experiences |
SP3.1 Внедрять активы процессов организации – Deploy Organizational Process Assets SP3.2 Внедрять стандартные процессы – Deploy Standard Processes SP3.3 Вести надзор за реализацией – Monitor the Implementation SP3.4 Воплощать опыт в процессные активы организации – Incorporate Experiences into Organizational Process Assets |
|
(OPM) Управление работой организации (Organizational Performance Management) – Проактивно управлять исполнением процессов организации для достижения ее бизнес-целей |
SG1. Управлять ходом бизнес-процессов – Manage Business Performance |
SP1.1 Поддерживать бизнес-цели – Maintain Business Objectives SP1.2 Анализировать данные о ходе процессов – Analyze Process Performance Data SP1.3 Выявлять потенциальные области для улучшения – Identify Potential Areas for Improvement |
SG2. Выбрать улучшения – Select Improvements |
SP2.1 Отбирать предложенные улучшения – Elicit Suggested Improvements SP2.2 Анализировать предложенные улучшения – Analyze Suggested Improvements SP2.3 Проверять пригодность улучшений – Validate Improvements SP2.4 Выбирать и реализовывать улучшения для внедрения – Select and Implement Improvements for Deployment |
|
SG3. Внедрить улучшения – Deploy Improvements |
SP3.1 Планировать внедрение – Plan the Deployment SP3.2 Управлять внедрением – Manage the Deployment SP3.3 Оценивать эффект от улучшений – Evaluate Improvement Effects |
|
(OPP) Исполнение процесса организацией (Organizational Process Performance) – Создать и поддерживать количественное понимание хода процессов из стандартного набора организации и обеспечивать получение данных о ходе процессов, базовых версий и моделей для количественного управления проектами в организации |
SG1. Создать базовые версии и модели хода процессов – Establish Performance Baselines and Models |
SP1.1 Устанавливать цели по качеству и ходу процесса – Establish Quality and Process Performance Objectives SP1.2 Выбирать процессы – Select Processes SP1.3 Устанавливать измерения для хода процесса – Establish Process Performance Measures SP1.4 Анализировать ход процесса и установить базовые версии хода процессы – Analyze Process Performance and Establish Process Performance Baselines SP1.5 Устанавливать модели хода процесса – Establish Process-Performance Models |
(OT) Повышение квалификации в организации (Organizational Training) – Развивать навыки и знания сотрудников, чтобы они могли выполнять свои обязанности результативно и экономно |
SG1. Установить способность организации к обучению – Establish an Organizational Training Capability |
SP1.1 Устанавливать стратегические потребности в обучении – Establish the Strategic Training Needs SP1.2 Определять, за какие потребности в обучении отвечает организация – Determine Which Training Needs Are the Responsibility of the Organization SP1.3 Создавать тактический план организации по обучению – Establish an Organizational Training Tactical Plan SP1.4 Создавать возможность для обучения – Establish a Training Capability |
SG2. Обеспечить обучение – Provide Training |
SP2.1 Предоставлять обучение – Deliver Training SP2.2 Вести учет записей об обучении – Establish Training Records SP2.3 Оценивать результативность обучения – Assess Training Effectiveness |
|
(PI) Интеграция продукта (Product Integration) – Собрать продукт из его компонентов, обеспечить его правильное функционирование и доставить продукт |
SG1. Подготовиться к интеграции продукта – Prepare for Product Integration |
SP1.1 Определять стратегию интеграции – Determine an Integration Strategy SP1.2 Создавать среду для интеграции продукта – Establish the Product Integration Environment SP1.3 Устанавливать процедуры и критерии интеграции продукта – Establish Product Integration Procedures and Criteria |
SG2. Обеспечить совместимость интерфейсов – Ensure Interface Compatibility |
SP2.1 Проводить обзор описаний интерфейсов на полноту – Review Interface Descriptions for Completeness SP2.2 Управлять интерфейсами – Manage Interfaces |
|
SG3. Собрать компоненты продукта и доставить продукт – Assemble Product Components and Deliver the Product |
SP3.1 Подтверждать готовность компонентов продукта к интеграции – Confirm Readiness of Product Components for Integration SP3.2 Проводить сборку компонентов продукта – Assemble Product Components SP3.3 Оценивать компоненты продукта в сборке – Evaluate Assembled Product Components SP3.4 Упаковывать и доставлять продукт или компонент продукта – Package and Deliver the Product or Product Component |
|
(PMC) Надзор за проектом и его контролирование (Project Monitoring and Control) – Обеспечить понимание хода проекта для принятия соответствующих мер исправления, если он существенно отклоняется от плана |
SG1. Вести надзор за проектом в отношении к плану – Monitor the Project Against the Plan |
SP1.1 Вести надзор за параметрами проектного плана – Monitor Project Planning Parameters SP1.2 Вести надзор за обязательствами – Monitor Commitments SP1.3 Вести надзор за рисками проекта – Monitor Project Risks SP1.4 Вести наблюдение за управлением данными – Monitor Data Management SP1.5 Вести наблюдение за вовлечением прикосновенных лиц – Monitor Stakeholder Involvement SP1.6 Проводить обзоры хода проекта – Conduct Progress Reviews SP1.7 Проводить обзоры этапов – Conduct Milestone Reviews |
SG2. Управлять поправочными действиями до их закрытия – Manage Corrective Actions to Closure |
SP2.1 Анализировать проблемы – Analyze Issues SP2.2 Предпринимать поправочные действия – Take Corrective Action SP2.3 Управлять поправочными действиями – Manage Corrective Action |
|
(PP) Планирование проекта (Project Planning) – Установить и поддерживать планы, определяющие проектные деятельности – Establish and maintain plans that define project activities |
SG1. Сделать оценки – Establish estimates |
SP1.1 Делать оценку охвата проекта – Estimate the Scope of the Project SP1.2 Делать оценки атрибутов для рабочих продуктов и задач – Establish Estimates of Work Product and Task Attributes SP1.3 Определять фазы жизненного цикла проекта – Define Project Lifecycle Phases SP1.4 Делать оценки трудоемкости и затрат – Estimate Effort and Cost |
SG2. Разработать проектный план – Develop a Project Plan |
SP2.1 Составлять бюджет и график – Establish the Budget and Schedule SP2.2 Выявлять риски проекта – Identify Project Risks SP2.3 Планировать управление данными – Plan for Data Management SP2.4 Планировать ресурсы проекта – Plan for Project's Resources SP2.5 Планировать необходимые знания и навыки – Plan Needed Knowledge and Skills SP2.6 Планировать вовлечение прикосновенных лиц – Plan Stakeholder Involvement SP2.7 Устанавливать план проекта – Establish the Project Plan |
|
SG3. Получить согласие на исполнение плана – Obtain Commitment to the Plan |
SP3.1 Проводить обзор планов, влияющих на проект – Review Plans That Affect the Project SP3.2 Совмещать уровни работ и ресурсов – Reconcile Work and Resource Levels SP3.3 Получать согласие на исполнение плана – Obtain Plan Commitment |
|
(PPQA) Обеспечение качества продукта и процесса (Product and Process Quality Assurance) – Предоставлять участникам и руководству объективную картину процессов и их рабочих продуктов |
SG1. Объективно оценивать процессы и рабочие продукты – Objectively Evaluate Processes and Work Products |
SP1.1 Объективно оценивать процессы – Objectively Evaluate Processes SP1.2 Объективно оценивать рабочие продукты – Objectively Evaluate Work Products |
SG2. Давать объективную картину – Provide Objective Insight |
SP2.1 Сообщать о проблемах несоответствия и решать их – Communicate and Resolve Noncompliance Issues SP2.2 Вести записи – Establish Records |
|
(QPM) Количественное управление проектом (Quantitative Project Management) – Количественно управлять определенным проектным процессом для достижения заданных целей по качеству проекта и ходу процесса |
SG1. Подготовиться к количественному управлению – Prepare to Quantitative Management |
SP1.1 Устанавливать цели проекта – Establish the Project’s Objectives SP1.2 Собирать определенный процесс – Compose the Defined Process SP1.3 Выбирать подпроцессы и атрибуты – Select Subprocesses and Attributes SP1.4 Выбирать метрики и аналитические методики – Select Measures and Analytic Techniques |
SG2. Количественно управлять проектом – Quantitatively Manage the Product |
SP2.1 Вести надзор за ходом выбранных подпроцессов – Monitor the Performance of Selected Subprocesses SP2.2 Управлять ходом проекта – Manage Project Performance SP2.3 Выполнять причинно-следственный анализ – Perform Root Cause Analysis |
|
(RD) Разработка требований (Requirements Development) – Создать и проанализировать требования заказчика к продукту и его компонентам |
SG1. Разработать требования заказчика – Develop Customer Requirements |
SP1.1 Отбирать потребности – Elicit Needs SP1.2 Преобразовывать потребности прикосновенных лиц в требования заказчика – Transform Stakeholder Needs into Customer Requirements SP1.3 Разрабатывать требования к продукту – Develop Product Requirements |
SG2. Разработать требования к продукту – Develop Product Requirements |
SP2.1 Устанавливать требования к продукту и его компонентам – Establish Product and Product Component Requirements SP2.2 Распределять требования к компонентам продукта – Allocate Product Component Requirements SP2.3 Выявлять требования к интерфейсам – Identify Interface Requirements |
|
SG3. Провести анализ и проверку пригодности требований – Analyze and Validate Requirements |
SP3.1 Создавать концепции и сценарии работы – Establish Operational Concepts and Scenarios SP3.2 Создавать определение требуемой функциональности и атрибутов качества – Establish a Definition of Required Functionality and Quality Attributes SP3.3 Анализировать требования – Analyze Requirements SP3.4 Анализировать требования для достижения баланса – Analyze Requirements to Achieve Balance SP3.5 Проводить валидацию требований – Validate Requirements |
|
(REQM) Управление требованиями (Requirement Management) – Управлять требованиями проектного продукта и его компонентов и выявлять несогласованности между этими требованиями и проектными планами с их рабочими продуктами |
SG1. Управлять требованиями – Manage Requirements |
SP1.1 Понимать требования – Understand Requirements SP1.2 Получать согласие на требования – Obtain Commitments to Requirements SP1.3 Управлять изменением требований – Manage Requirements Changes SP1.4 Поддерживать отслеживаемость требований в обе стороны – Maintain Bi-Directional Traceability of Requirements SP1.5 Обеспечивать соответствие между работами по проекту и требованиями – Ensure Alignment between Project Work and Requirements |
(RSKM) Управление рисками (Risk Management) – Выявлять потенциальные проблемы до их наступления, чтобы можно было спланировать и выполнить деятельности по управлению рисками по мере необходимости в течение всего ЖЦ для смягчения нежелательных воздействий на достижение заявленных целей |
SG1. Подготовиться к управлению рисками – Prepare for Risk Management |
SP1.1 Определять источники и категории рисков – Determine Risk Sources and Categories SP1.2 Определять параметры рисков – Define Risk Parameters SP1.3 Устанавливать стратегию управления рисками – Establish a Risk Management Strategy |
SG2. Выявить и проанализировать риски – Identify and Analyze Risks |
SP2.1 Выявлять риски – Identify Risks SP2.2 Оценивать риски, разносить их по категориям и давать им приоритеты – Evaluate, Categorize, and Prioritize Risks |
|
SG3. Смягчить риски – Mitigate Risks |
SP3.1 Разрабатывать планы смягчения рисков – Develop Risk Mitigation Plans SP3.2 Реализовывать планы смягчения рисков – Implement Risk Mitigation Plans |
|
(SAM) Управление соглашениями с поставщиками (Supplier Agreement Management) – Управлять приобретением по договорам продуктов и услуг от внешних поставщиков |
SG1. Установить соглашения с поставщиками – Establish Supplier Agreements |
SP1.1 Определять тип приобретения – Determine Acquisition Type SP1.2 Выбирать поставщиков – Select Suppliers SP1.3 Устанавливать соглашения с поставщиками – Establish Supplier Agreements |
SG2. Обеспечить выполнение соглашений с поставщиками – Satisfy Supplier Agreements |
SP2.1 Исполнять соглашение с поставщиком – Execute the Supplier Agreement SP2.2 Проводить приемку приобретенного продукта – Accept the Acquired Product SP2.3 Обеспечивать передачу продуктов – Ensure Transition of Products |
|
(TS) Техническое решение (Technical Solution) – Разработать, спроектировать и реализовать решения для требований, включающие продукты, их компоненты и связанные с ними процессы |
SG1. Выбрать решения для компонентов продукта – Select Product Component Solutions |
SP1.1 Разрабатывать альтернативные решения и критерии отбора – Develop Alternative Solutions and Selection Criteria SP1.2 Выбирать решения для компонентов продукта – Select Product Component Solutions |
SG2. Разработать проект – Develop the Design |
SP2.1 Создавать проекты продукта или компонентов продукта – Design the Product or Product Component SP2.2 Устанавливать пакет технических данных – Establish a Technical Data Package SP2.3 Проектировать интерфейсы по критериям – Design Interfaces Using Criteria SP2.4 Выполнять анализы соотношений создать/купить/повторно использовать – Perform Make, Buy, or Reuse Analyses |
|
SG3. Реализовать проект продукта – Implement the Product Design |
SP3.1 Реализовывать проект – Implement the Design SP3.2 Разрабатывать сопроводительную документацию к продукту – Develop Product Support Documentation |
|
(VAL) Валидация (Validation) – Продемонстрировать, что продукт или его компонент выполняет свое предназначение в соответствующем окружении |
SG1. Подготовиться к валидации – Prepare for Validation |
SP1.1 Выбирать продукты для валидации – Select Products for Validation SP1.2 Создавать среду валидации – Establish the Validation Environment SP1.3 Создавать процедуры и критерии валидации – Establish Validation Procedures and Criteria |
SG2. Провести валидацию продукта или его компонентов – Validate Product or Product Components |
SP2.1 Выполнять валидацию – Perform Validation SP2.2 Анализировать результаты валидации – Analyze Validation Results |
|
(VER) Верификация (Verification) – Убедиться, что выбранные рабочие продукты удовлетворяют своим специфицированным требованиям |
SG1. Подготовиться к верификации – Prepare for Verification |
SP1.1 Выбирать рабочие продукты для верификации – Select Work Products for Verification SP1.2 Создавать среду верификации – Establish the Verification Environment SP1.3 Создавать процедуры и критерии верификации – Establish Verification Procedures and Criteria |
SG2. Провести товарищеские обзоры – Perform Peer Reviews |
SP2.1 Готовиться к товарищеским обзорам – Prepare for Peer Reviews SP2.2 Проводить товарищеские обзоры – Conduct Peer Reviews SP2.3 Анализировать данные товарищеских обзоров– Analyze Peer Review Data |
|
SG3. Верифицировать выбранные рабочие продукты – Verify Selected Work Products |
SP3.1 Выполнять верификацию – Perform Verification SP3.2 Анализировать результаты верификации – Analyze Verification Results |
Нулевой уровень (неполный – incomplete) характеризуется тем, что процесс на нем либо не исполняется вообще, либо исполняется только частично. Одна или более специальных целей какой-либо процессной области не достигаются. Отсюда следует непредсказуемость и ненадежность при разработке программных продуктов на этом уровне зрелости
На первом уровне (performed – исполняемый) все специальные цели процессных областей достигаются, необходимые для успеха проекта деятельности осуществляются, и проекты доводятся до конца, однако определение проектного процесса, наблюдение за ним и его контролирование могут быть неполными. Отсюда вытекают нестабильность процесса и несогласованность в его реализации. Сам процесс хаотичен и ad hoc. Бюджет и график часто превышают первоначальные оценки.
Процесс второго уровня (управляемый – managed) является исполняемым и в дополнение к этому еще и управляемым, что означает следующее:
процесс разработки программного работки продукта планируется и исполняется в соответствии с известной политикой, принятой в организации;
к исполнению проекта привлекаются подготовленные люди, имеющие адекватные ресурсы для создания контролируемых рабочих продуктов;
в процесс производства вовлечены заинтересованные прикосновенные лица;
за проектным процессом ведется наблюдение (is monitored), он контролируется (is controlled) и проходит регулярные обзоры (is reviewed);
процесс регулярно оценивается на его соответствие своему определению.
На третьем уровне (определенный – defined) проектный процесс является управляемым и, сверх того, еще и определенным. Его описание строится на базе набора стандартных проектных процессов данной организации в соответствии с ее руководящими указаниями по подгонке (tailoring guidelines) проектного процесса, что означает следующее:
рабочие продукты процесса, измеренные количественные показатели и другие данные по улучшению процесса накапливаются в хранилище процессных данных организации-разработчика;
в организации установлении стандартный процесс, который время от времени улучшается.
Процесс четвертого уровня (количественно управляемый – quantitatively managed) является определенным и, сверх того, еще и управляемым количественно; т.е., с помощью статистических и других количественных методов. Это означает, что:
для качества поставляемых рабочих продуктов, оказываемых услуг и исполнения проектного процесса установлены количественные целевые показатели, которые используются в качестве критериев для управления процессом разработки;
достигается статистическая предсказуемость результатов исполнения программного проекта.
Наконец, проект пятого уровня (оптимизирующий – optimizing) является количественно управляемым процессом, который изменяется и адаптируется под значимые текущие и предполагаемые бизнес-цели организации. Это означает, что:
Процесс разработки нацелен на постоянное улучшение диапазона своего исполнения через пошаговые и инновационные улучшения применяемых технологий и самого процесса;
установлены количественные показатели для улучшения процесса;
результат от вносимых в процесс улучшений оценивается в измеряемых показателях.
Составьте процессный профиль Вашей организации-разработчика по модели CMMI и проанализируйте его.
Предложите план перехода на необходимый, по Вашему мнению, уровень зрелости в Вашей организации.
Управление рисками составляет важную часть в каждом проекте, в модели CMMI оно даже выделено в отдельную процессную область, а ISO разработала отдельные международные стандарты:
ISO Guide 73:2009 "Risk management. Vocabulary" (Управление рисками. Словарь);
Standard ISO 31000:2009 "Risk management – Principles and guidelines on implementation" (Управление рисками. Принципы и руководящие указания по реализации);
Standard ISO/IEC 31010:2009 "Risk Management – Risk Assessment Techniques" (Управление рисками. Методики оценивания рисков).
Управление рисками – это подход к управлению, основанный на выявлении тех областей и событий в жизненном цикле разработки, которые несут потенциальную возможность вызвать желательные или нежелательные изменения либо в процессе, либо в продукте, а также на управлении ими. Отличительными составными компонентами любого риска являются три его характерных особенности:
Событие, которое можно определить (Event, Trigger).
Вероятность наступления этого события (Probability).
Последствия наступления этого события (Impact)
Почти всегда риск рассматривается как нечто, связанное с какими-либо потерями; однако, некоторые риски могут рассматриваться и с положительной стороны; в этом случае они обычно называются возможностями (opportunities).
Каждый риск несет в себе некоторую неопределенность – он может произойти, а может и не произойти, и в случае его актуализации могут быть различные последствия для проекта; поэтому задача управления рисками – максимально снижать степень этой неопределенности. Неопределенности, связанные с рисками, можно условно разделить на три группы: описательная – в чем именно состоит рисковое событие, измерительная – вероятность наступления этого события в будущем, и результативная – каковы именно последствия наступления данного рискового события. Следует всегда помнить: «Сам риск – не проблема… Проблема – риск, время которого наступило!»
Рис. 29. Риск – функция его составляющих
Обычно различают области низких, умеренных и высоких рисков по комбинации вероятность последствий/размер последствий от наступления данного риска, как это показано на Рис. 29. Другими характерными особенностями риска являются:
Ситуационность – проявления риска существенно зависят от ситуации:
нет готовых ответов и определений;
следует полагаться на инструменты для работы с рисками.
Взаимозависимость – разные риски могут обуславливать друг друга:
одно рисковое событие может вызвать другие;
количество рисков влияет на их восприятие.
Зависимость от величины – восприятия риска зависит от количественной оценки его параметров:
приемлемость риска дихотомична, да или нет;
чем больше вознаграждение, тем приемлемее риск;
точка крушения делает любое вознаграждение неприемлемым.
Укорененность в ценностях – восприятие риска зависит от личности:
личные ценности влияют на принятие корпоративных рисков;
корпоративные ценности влияют на индивидуальный выбор.