Уровни зрелости процесса/проекта CMMI

1. Уровни зрелости процесса/проекта CMMI

2. Современные требования программной инженерии

1.
2.
3.
4.
5.
6.
Архитектура должна соответствовать текущим и перспективным целям и
стратегическим, функциональным задачам, создаваемой системы, быть
достаточно гибкой и допускать развитие и наращивание функций и ресурсов
системы в соответствии с расширением сфер и задач её применения;
В структуре и компонентах ПС и системы следует предусматривать
обеспечение максимально возможной сохранности инвестиций в аппаратные
и программные средства, в базы данных при длительном развитии,
сопровождении и модернизации системы;
Необходимо обеспечивать эффективное использование ресурсов в ЖЦ
системы и минимизировать интегральные затраты на обработку данных в
типовых режимах её функционирования с учетом эксплуатационных затрат и
капитальных вложений в создание системы и программного продукта;
Должны быть обеспечены безопасность функционирования системы и
надежная защита данных от ошибок, от разрушения или потери
информации, авторизация пользователей, управление рабочей загрузкой,
резервированием и оперативным восстановлением;
Предусматривать возможность интеграции гетерогенных вычислительных
компонентов и возможность переноса ПС и БД на различные аппаратные и
операционные платформы на основе концепции и стандартов открытых
систем;
Обеспечение обучения и упрощенного доступа конечных пользователей к
управлению и результатам функционирования на основе современных
графических средств и наглядных пользовательских интерфейсов.
2

3. Автоматизация процессов

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

4. Терминология

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

5. Другие модели

• PAM является одной из моделей оценки процессов, которая
фокусируется на улучшении процессов, а не на уровне зрелости
организации. Она позволяет оценить силы и слабости
процессов и рекомендовать улучшения на основе практик,
которые уже используются в организации.
• SPICE, в свою очередь, фокусируется на улучшении процессов
разработки ПО и определении способностей организации в
этой области. Он также помогает определить уровень зрелости
процессов и предлагает практики для их улучшения.
• ISO/IEC 15504 является международным стандартом для
оценки зрелости процессов. Он позволяет оценить способность
организации выполнять различные виды процессов и
определить их уровень зрелости.

6. Управление проектами

Назначение методологии СММ/CMMI – системы и модели
оценки зрелости – состоит в предоставлении
необходимых общих рекомендаций и инструкций
предприятиям, производящим ПС, по выбору стратегии
совершенствования качества процессов и продуктов,
путем анализа степени их производственной зрелости и
оценивания факторов, в наибольшей степени влияющих
на качество ЖЦ ПС, а также посредством выделения
процессов, требующих модернизации.
6

7. Создание

• CMM была создана в 1980-х годах для оценки зрелости
процессов в области программной инженерии. CMMI
была создана в 2002 году и является более
современной моделью оценки зрелости процессов.
• Для создания этой модели был проведён анализ
ключевых активностей, выполняемых при разработке
ПО, и связанных с ними рисков.
• Для каждой ключевой активности (или цели) модель
предлагает ряд практик, которые позволяют снять или
существенно уменьшить соответствующие проектные
риски.
• Все активности были сгруппированы в т.н. процессные
области.

8. Определение

Capability Maturity Model Integration (CMMI) –
Комплексная модель производительности и
зрелости – набор моделей (методологий)
совершенствования процессов в организациях
разных размеров и видов деятельности. CMMI
содержит набор рекомендаций в виде практик,
реализация которых, по мнению разработчиков
модели, позволяет реализовать цели,
необходимые для полной реализации
определенных областей деятельности.

9. Уровни зрелости

Уровень 1 Начальный
Уровень 2 Управляемый – базовое управление
Уровень 3 Определенный – стандартизация процессов
Уровень 4 Предсказуемый – количественное управление
Уровень 5 Оптимизационный – непрерывное
совершенствование и улучшение
В 2003 году американский Институт программной
инженерии (SEI) опубликовал новую комплексную модель
CMMI, уточняющую и совершенствующую
предшествовавшие модели CMM, а также частично
учитывающую основные требования существующих
международных стандартов в области менеджмента
программных средств.
9

10. Варианты модели CMMI – 1.1

Два варианта модели CMMI – 1.1 созданы для обеспечения непрерывного оценивания
комплекса процессов в определенной области создания программных средств или для
поэтапного оценивания и совершенствования зрелости предприятия, а также для
организации ЖЦ комплексов программ в целом.
Единая схема описания моделей построена по схеме, которая содержит общие разделы:
предисловие;
1. введение;
2. модель компонентов;
3. терминология;
4. содержание уровней и главные компоненты каждого варианта модели;
5. структура взаимодействия процессов. Аннотированы четыре категории процессов раздела 7,
их общий обзор и схемы взаимодействия CMMI процессов:
менеджмент процессов; менеджмент – управление проектом; инжиниринг (технология);
поддержка;
6 . использование модели CMMI – краткие рекомендации для пользователей по применению
модели и обучению; отмечается совместимость и соответствие процессов модели, с
регламентированными процессами предыдущей модели CMM в части 2 и 3 стандарта ISO
15504
7. (ок. 500 стр. из полного объема документа, который составляет свыше 700 стр.) В нем
представлены подробные рекомендации для реализации каждого из перечисленных
множества процессов, которые учитывают особенности конкретной модели
10

11. Вариант 1 (непрерывная) модель

Первый вариант отражает документ: Capability Maturity Model
Integration (CMMI) for Systems Engineering / Software
Engineering / Integrated Product and Process Development,
Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD,
V1.1, Continuous) – Интегрированная модель оценивания
зрелости инженерии систем / программной инженерии /
интегрированных продуктов и процессов разработки –
непрерывное представление.
В этой модели седьмой раздел составляют процессы:
менеджмент процессов;
управление проектом;
инженерия (технология);
поддержка.
11

12. Вариант 1 (непрерывная) модель

Планирование проекта в этой, также как и во второй модели включает:
• оценку возможного размера – масштаба программного продукта;
• оценку сложности функций и характеристик проекта ПС;
• определение модели и этапов жизненного цикла комплекса программ;
• технико-экономическое обоснование проекта – определение стоимости,
трудоемкости и длительности ЖЦ ПС;
• разработка поэтапного графика работ и бюджета проекта;
• анализ, идентификация и оценка проектных рисков;
• планирование и управление документированием процессов и продуктов в
ЖЦ проекта ПС;
• планирование и распределение технических и людских ресурсов по этапам
ЖЦ ПС;
• планирование обеспечения знаний и квалификации коллектива
специалистов для реализации проекта;
• обобщение и анализ совокупности планов проекта ПС;
• согласование работ и ресурсов по этапам ЖЦ разработчиком с заказчиком
проекта ПС;
• документирование плана работ и утверждение его менеджером
12
разработчиков проекта.

13. Вариант 1 (непрерывная) модель

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

14. Вариант 1 (непрерывная) модель

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

15. Вариант второй

Второй вариант CMMI представлен документом: Capability
Maturity Model Integration for Systems Engineering / Software
Engineering / Integrated Product and Process Development,
Version 1.1, Staged Representation (CMMI-SE/SW/IPPD, V1.1,
Staged) – Интегрированная модель оценивания зрелости
инженерии сложных систем / программной инженерии /
интегрированных продуктов и процессов разработки –
поэтапное представление.
Модель базируется на сохранении концепции пяти уровней
зрелости CMM.
15

16.

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

17. 1 уровень - Начальный (Initial)

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

18. 2 уровень - Управляемый (Managed)

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

19. 2 уровень – Процессные области

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

20. 3 уровень - Определенный (Defined)

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

21. 3 уровень – Процессные области

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

22. 3 уровень – Процессные области

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

23. 4 уровень - Управляемый на основе количественных данных (Quantitatively Managed)

Признаки:
• Применение статистических методов для измерения процессов и
управления ими.
• Использование количественных метрик для оценки эффективности
процессов.
• Управление проектами на основе количественных данных, учитывая
риски и изменения в проекте.
• Управление качеством на основе количественных данных, включая
измерение и анализ дефектов и ошибок.
• Использование данных для улучшения процессов и повышения
качества продукта.
• Разработка и внедрение процессов управления рисками и управления
изменениями.
• Управление проектами и процессами на основе доверия к
количественным метрикам и данным.

24. 4 уровень – Процессные области

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

25. 5 уровень - Оптимизируемый (Optimizing)

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

26. 5 уровень – Процессные области

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

27. Применимость CMMI

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