Материал: DO178 Учебное пособие_в183

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

Уровень 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. Восхождение по уровням зрелости

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

В модели CMMI введено понятие «уровня способностей» (capability level – CL) процесса, которое характеризует степень владения данным разработчиком той или иной процессной областью. Различают четыре таких уровня, нумеруемых от 0 до 3; уровень считается достигнутым, если достижение всех общих целей отвечает ему и при этом:

0 – неполный (incomplete) – процесс либо не исполняется вообще, либо исполняется только частично; одна или более специфичных целей данной процессной области не достигается (достижение общих целей здесь не рассматривается);

1 – исполняемый (performed) – выполняется вся необходимая работа для создания рабочих продуктов и все специфические цели процессной области достигаются;

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

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

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

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

Рис. 28. Пример процессного профиля организации в модели CMMI

      1. Специальные и общие цели и практики процессных областей

Для каждой отдельной области процесса модель 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

      1. Характеристики уровней зрелости в модели cmmi

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

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

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

  • процесс разработки программного работки продукта планируется и исполняется в соответствии с известной политикой, принятой в организации;

  • к исполнению проекта привлекаются подготовленные люди, имеющие адекватные ресурсы для создания контролируемых рабочих продуктов;

  • в процесс производства вовлечены заинтересованные прикосновенные лица;

  • за проектным процессом ведется наблюдение (is monitored), он контролируется (is controlled) и проходит регулярные обзоры (is reviewed);

  • процесс регулярно оценивается на его соответствие своему определению.

На третьем уровне (определенный – defined) проектный процесс является управляемым и, сверх того, еще и определенным. Его описание строится на базе набора стандартных проектных процессов данной организации в соответствии с ее руководящими указаниями по подгонке (tailoring guidelines) проектного процесса, что означает следующее:

  • рабочие продукты процесса, измеренные количественные показатели и другие данные по улучшению процесса накапливаются в хранилище процессных данных организации-разработчика;

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

Процесс четвертого уровня (количественно управляемый – quantitatively managed) является определенным и, сверх того, еще и управляемым количественно; т.е., с помощью статистических и других количественных методов. Это означает, что:

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

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

Наконец, проект пятого уровня (оптимизирующий – optimizing) является количественно управляемым процессом, который изменяется и адаптируется под значимые текущие и предполагаемые бизнес-цели организации. Это означает, что:

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

  • установлены количественные показатели для улучшения процесса;

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

    1. Задания для самопроверки

Составьте процессный профиль Вашей организации-разработчика по модели CMMI и проанализируйте его.

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

4.Управление рисками в программном проекте

Управление рисками составляет важную часть в каждом проекте, в модели 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" (Управление рисками. Методики оценивания рисков).

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

  1. Событие, которое можно определить (Event, Trigger).

  2. Вероятность наступления этого события (Probability).

  3. Последствия наступления этого события (Impact)

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

Каждый риск несет в себе некоторую неопределенность – он может произойти, а может и не произойти, и в случае его актуализации могут быть различные последствия для проекта; поэтому задача управления рисками – максимально снижать степень этой неопределенности. Неопределенности, связанные с рисками, можно условно разделить на три группы: описательная – в чем именно состоит рисковое событие, измерительная – вероятность наступления этого события в будущем, и результативная – каковы именно последствия наступления данного рискового события. Следует всегда помнить: «Сам риск – не проблема… Проблема – риск, время которого наступило!»

Рис. 29. Риск – функция его составляющих

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

  1. Ситуационность – проявления риска существенно зависят от ситуации:

    • нет готовых ответов и определений;

    • следует полагаться на инструменты для работы с рисками.

  1. Взаимозависимость – разные риски могут обуславливать друг друга:

    • одно рисковое событие может вызвать другие;

    • количество рисков влияет на их восприятие.

  1. Зависимость от величины – восприятия риска зависит от количественной оценки его параметров:

    • приемлемость риска дихотомична, да или нет;

    • чем больше вознаграждение, тем приемлемее риск;

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

  1. Укорененность в ценностях – восприятие риска зависит от личности:

    • личные ценности влияют на принятие корпоративных рисков;

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

Источник: https://studfile.net/preview/16431019/