Всем здравствуйте! Наконец-то я на Хабре. Постараюсь незамедлительно начать приносить пользу если не всему сообществу, то хотя бы некоторой его части:)
Я был немало удивлён, обнаружив, что на Хабре практически нет информации о модели CMMI, если не считать пары упоминаний здесь и здесь.
На западе уже давно крупные заказы по разработке ПО доверяются только компаниям, прошедшим сертификацию на соответствие какому-либо международному стандарту, зачастую им становится модель CMMI. Хотя сами авторы этой модели неоднократно повторяют, что это не стандарт, а всего лишь сборник рекомендаций по улучшению процессов внутри организации.
Википедия даёт следующее определение:
Собственно, сначала появилась просто CMM, а CMMI явилась результатом последовательного развития первоначальной модели, поглотившей при этом ряд других. В середине 1980-х годов перед министерством обороны США встала проблема повышения качества разрабатываемого по их заказу ПО. Согласитесь, вам и самим было бы спокойнее жить, зная, что ни одна американская ракета не полетит случайно в сторону вашего дома? Кроме того, поскольку деньги были бюджетные, а бюджет обычно плановый и не резиновый, помимо качества разработки от исполнителя требовалось ещё и выполнение заказа точно в срок и в рамках установленного бюджета.
Проблема была решена следующим образом: созданием модели, на соответствие которой оценивались все потенциальные исполнители заказа министерства обороны. Задача разработки этой модели была возложена на Software Engineering Institute, созданный на базе Carnegie Mellon University, который в свою очередь расположен в славном городе Питтсбурге штата Пенсильвания.
Для создания этой модели был проведён анализ ключевых активностей, выполняемых при разработке ПО, и связанных с ними рисков. Анализировались как best practices – практики, которые позволили успешно избежать или смягчить тот или иной риск, так и worst practices – типичные ошибки, совершение которых приводит к проблемам в качестве, срыву сроков и превышению бюджетов. Для каждой ключевой активности (или цели) модель предлагает ряд практик, которые позволяют снять или существенно уменьшить соответствующие проектные риски. И все активности были сгруппированы в т.н. процессные области. В 1987 году появился прообраз будущей модели – на самом деле анкета, которая содержала всего 85 процессных и 16 технологических вопросов, ответы на которые и определяли оцениваемую компанию к одному из пяти уровней зрелости.
Со временем менялось только количество и содержание процессных областей. А вот концепция уровней зрелости – это как раз то, что за 20 с лишним лет в этой модели не изменилось.
Уровень зрелости – это главный, итоговый показатель оценки по модели CMMI.
Процессы первого уровня зрелости характеризуются хаотичностью, реактивностью, непредсказуемостью. Несмотря на это, очень часто организации, находящиеся на данном этапе развития, производят довольно качественные продукты. При этом, как правило, превышается бюджет и время разработки данных продуктов. Качественные продукты данных организаций производятся не за счет устойчивых и отлаженных процессов, а благодаря титаническим усилиям отдельных личностей. В случае ухода таких людей очень тяжело повторить успешные проекты. На данном этапе очень тяжело предсказать производительность процессов, протекающих в организации. На уровне 1 производственный процесс (а вместе с ним и все процессы) представляется аморфной сущностью, практически черным ящиком, представление о процессах очень ограниченное, чрезмерно много усилий тратится на выяснение статуса развития проекта и текущего хода работ.
В принципе, для небольших компаний, разрабатывающих собственные проекты или небольшие проекты по заказу – это приемлемо. Но для них и не нужна никакая модель CMMI. Эта модель показывает себя во всей красе при разработке действительно больших проектов. И поэтому мы идём дальше по лестнице уровней зрелости.
Уровень зрелости 2 – управляемый уровень. На данном этапе основные процессы описаны, их, возможно, использовать неоднократно. Другими словами, проекты, выполняемые организацией, отвечают требованиям. Процессы управляемы, они планируются, выполняются, измеряются и контролируются. Однако процессы все же имеют некоторую долю реактивности в своей сущности. На уровне 2 контролируются требования заказчиков и промежуточные продукты, а также установлены основные практики управления проектом. Эти средства позволяют управлять проектом, однако дают фрагментарное представление о нем. Фактически, производственный процесс можно представить последовательностью черных ящиков и реальное видение проекта присутствует лишь на промежуточных этапах.
Уровень зрелости 3 – определенный уровень. В этом случае процессы определены. Установлены стандарты в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Присутствует более детальное описание всех процессов, в котором лучше раскрываются связи и зависимости, знание которых позволяет улучшить управление. На этом уровне – уровне 3 — становится видимой внутренняя сторона наших черных ящиков. Это внутренняя структура отражает способ, применения стандартного производственного процесса организации.
Уровень зрелости 4 – количественно-управляемый уровень. На данном этапе достигнуты все цели предыдущих уровней. Выбраны субпрактики, которые при использовании статистических методов и других количественных техник позволяют контролировать качество выполнения процессов. Самое главное отличие этого этапа от предыдущего заключается в предсказуемости эффективности процессов и возможности ею (эффективностью) управлять. На уровне 4 определенные процессы количественно контролируются с помощью соответствующих средств и техник.
Уровень зрелости 5 – уровень постоянного улучшения (оптимизации) процессов. На данном этапе мы имеем точные характеристики оценки эффективности бизнес процессов, что позволяет нам постоянно и эффективно улучшать бизнес процессы путем развития существующих методов и техник и внедрения новых.
Процессные области — это то, из чего состоит вся модель. CMMI определяет 22 процессные области. Для каждой из процессных областей существует ряд целей, которые должны быть достигнуты при внедрении CMMI в данной процессной области. Некоторые цели являются уникальными — они называются специальными. Общие цели применяются к нескольким процессным областям. Цели достигаются при помощи выполнения практик; так же, как цели, практики делятся на специальные и общие.
А вот и список процессных областей с краткой расшифровкой названия каждой:
Использование модели CMMI позволяет организации оценить эффективность процессов, установить приоритетные направления их усовершенствования, а также внедрить данные усовершенствования.
Внедрение СММ/CMMI позволяет улучшить структуру и качество процессов (основные проблемы в программных разработках — это проблемы управления, а не технические проблемы), обеспечить стабильно высокое качество разработок и освоить процессы, которые могут служить основой для повышения конкурентной способности и дальнейшего развития и расширения компании.
В основе CMM/CMMI лежит понятие процесса. Принятие этой концепции помогает избежать естественной для многих организаций тенденции винить в неудачах людей. Увольнение сотрудников — не решение проблемы. За последние десятилетия произошли революционные изменения в технологии, однако проблемы успешного выполнения проекта остались. В этом аспекте технология также не решение проблемы. Ценность процесса в том, что он помогает уловить и использовать наивысшие достижения в будущих проектах. Именно на этой предпосылке и базируется CMMI.
СММ/CMMI — это модели, т.е. упрощенное представление мира. Модели СММ/CMMI содержат существенные элементы процессов, обеспечивающих разные стороны деятельности, и могут быть использованы как руководство для разработки и улучшения производственных процессов. В официальных изданиях модели подчеркивается, что она не представляет собой процессы или их описание. Реальные процессы в любой организации зависят от множества факторов, включая специфику бизнеса, структуру и размер организации.
Подводить итоги рано. Это скорее рекламная, обзорная статья, не описывающая механику внедрения модели. Если возникнет заинтересованность, я начну описывать подробнее её структуру. Скорее всего, статьи будут представлять собой несколько вольный перевод официальной документации от SEI с поясняющими комментариями.
Я был немало удивлён, обнаружив, что на Хабре практически нет информации о модели CMMI, если не считать пары упоминаний здесь и здесь.
На западе уже давно крупные заказы по разработке ПО доверяются только компаниям, прошедшим сертификацию на соответствие какому-либо международному стандарту, зачастую им становится модель CMMI. Хотя сами авторы этой модели неоднократно повторяют, что это не стандарт, а всего лишь сборник рекомендаций по улучшению процессов внутри организации.
Что такое CMMI?
Википедия даёт следующее определение:
Capability Maturity Model Integration (CMMI) – Комплексная модель производительности и зрелости – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.
Откуда появилась эта модель?
Собственно, сначала появилась просто CMM, а CMMI явилась результатом последовательного развития первоначальной модели, поглотившей при этом ряд других. В середине 1980-х годов перед министерством обороны США встала проблема повышения качества разрабатываемого по их заказу ПО. Согласитесь, вам и самим было бы спокойнее жить, зная, что ни одна американская ракета не полетит случайно в сторону вашего дома? Кроме того, поскольку деньги были бюджетные, а бюджет обычно плановый и не резиновый, помимо качества разработки от исполнителя требовалось ещё и выполнение заказа точно в срок и в рамках установленного бюджета.
Проблема была решена следующим образом: созданием модели, на соответствие которой оценивались все потенциальные исполнители заказа министерства обороны. Задача разработки этой модели была возложена на Software Engineering Institute, созданный на базе Carnegie Mellon University, который в свою очередь расположен в славном городе Питтсбурге штата Пенсильвания.
Для создания этой модели был проведён анализ ключевых активностей, выполняемых при разработке ПО, и связанных с ними рисков. Анализировались как best practices – практики, которые позволили успешно избежать или смягчить тот или иной риск, так и worst practices – типичные ошибки, совершение которых приводит к проблемам в качестве, срыву сроков и превышению бюджетов. Для каждой ключевой активности (или цели) модель предлагает ряд практик, которые позволяют снять или существенно уменьшить соответствующие проектные риски. И все активности были сгруппированы в т.н. процессные области. В 1987 году появился прообраз будущей модели – на самом деле анкета, которая содержала всего 85 процессных и 16 технологических вопросов, ответы на которые и определяли оцениваемую компанию к одному из пяти уровней зрелости.
Со временем менялось только количество и содержание процессных областей. А вот концепция уровней зрелости – это как раз то, что за 20 с лишним лет в этой модели не изменилось.
Кстати, уровни зрелости…
Уровень зрелости – это главный, итоговый показатель оценки по модели CMMI.
Процессы первого уровня зрелости характеризуются хаотичностью, реактивностью, непредсказуемостью. Несмотря на это, очень часто организации, находящиеся на данном этапе развития, производят довольно качественные продукты. При этом, как правило, превышается бюджет и время разработки данных продуктов. Качественные продукты данных организаций производятся не за счет устойчивых и отлаженных процессов, а благодаря титаническим усилиям отдельных личностей. В случае ухода таких людей очень тяжело повторить успешные проекты. На данном этапе очень тяжело предсказать производительность процессов, протекающих в организации. На уровне 1 производственный процесс (а вместе с ним и все процессы) представляется аморфной сущностью, практически черным ящиком, представление о процессах очень ограниченное, чрезмерно много усилий тратится на выяснение статуса развития проекта и текущего хода работ.
В принципе, для небольших компаний, разрабатывающих собственные проекты или небольшие проекты по заказу – это приемлемо. Но для них и не нужна никакая модель CMMI. Эта модель показывает себя во всей красе при разработке действительно больших проектов. И поэтому мы идём дальше по лестнице уровней зрелости.
Уровень зрелости 2 – управляемый уровень. На данном этапе основные процессы описаны, их, возможно, использовать неоднократно. Другими словами, проекты, выполняемые организацией, отвечают требованиям. Процессы управляемы, они планируются, выполняются, измеряются и контролируются. Однако процессы все же имеют некоторую долю реактивности в своей сущности. На уровне 2 контролируются требования заказчиков и промежуточные продукты, а также установлены основные практики управления проектом. Эти средства позволяют управлять проектом, однако дают фрагментарное представление о нем. Фактически, производственный процесс можно представить последовательностью черных ящиков и реальное видение проекта присутствует лишь на промежуточных этапах.
Уровень зрелости 3 – определенный уровень. В этом случае процессы определены. Установлены стандарты в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Присутствует более детальное описание всех процессов, в котором лучше раскрываются связи и зависимости, знание которых позволяет улучшить управление. На этом уровне – уровне 3 — становится видимой внутренняя сторона наших черных ящиков. Это внутренняя структура отражает способ, применения стандартного производственного процесса организации.
Уровень зрелости 4 – количественно-управляемый уровень. На данном этапе достигнуты все цели предыдущих уровней. Выбраны субпрактики, которые при использовании статистических методов и других количественных техник позволяют контролировать качество выполнения процессов. Самое главное отличие этого этапа от предыдущего заключается в предсказуемости эффективности процессов и возможности ею (эффективностью) управлять. На уровне 4 определенные процессы количественно контролируются с помощью соответствующих средств и техник.
Уровень зрелости 5 – уровень постоянного улучшения (оптимизации) процессов. На данном этапе мы имеем точные характеристики оценки эффективности бизнес процессов, что позволяет нам постоянно и эффективно улучшать бизнес процессы путем развития существующих методов и техник и внедрения новых.
…и процессные области.
Процессные области — это то, из чего состоит вся модель. CMMI определяет 22 процессные области. Для каждой из процессных областей существует ряд целей, которые должны быть достигнуты при внедрении CMMI в данной процессной области. Некоторые цели являются уникальными — они называются специальными. Общие цели применяются к нескольким процессным областям. Цели достигаются при помощи выполнения практик; так же, как цели, практики делятся на специальные и общие.
А вот и список процессных областей с краткой расшифровкой названия каждой:
- Менеджмент требований (Requirements Management)
Управление требованиями предъявляемым к продуктам проекта или компонентам продукта, с целью выявления несоответствия между требованиями и планами проекта. - Планирование проекта (Project Planning)
Разработка и поддержание планов определяющих развитие проекта. - Мониторинг и контроль проекта (Project Monitoring and Control)
Обеспечение понимания стадии разработки проекта с целью принятия корректирующих действий в случае серьезного отклонения от плана. - Менеджмент договоров с поставщиками (Supplier Agreement Management
Управление приобретением товаров и услуг от внешних поставщиков, с которыми заключены договоры. - Измерение и анализ (Measurement and Analysis)
Разработка и поддержание возможности измерения, используемой для поддержки нужд информационного менеджмента. - Оценка (гарантирование) качества товаров и процессов (Process and Product Quality Assurance)
Обеспечение поддержки и управления в соответствии с целями процессов и связанными с ними продуктами работы. - Конфигурационный менеджмент (Configuration Management)
Установка и поддержание целостности продуктов работы (work products) в результате использования идентификации конфигураций, конфигурационного контроля и конфигурационного аудита. - Разработка требований (Requirements Development)
Сбор и анализ требований потребителей к продуктам и компонентам продуктов. - Техническое решение (Technical Solution)
Разработка, дизайн и внедрение решений по соответствующим требованиям. Решения, дизайн и внедрения выражены продуктами, компонентами продуктов и связанными с данными продуктами процессами. - Интеграция продукта (Product Integration)
Сборка (монтирование) продукта из его составляющих, проверка качества интеграции, ее функциональности и выпуск продукта. - Верификация (Verification)
Гарантирование того, что выбранные продукты работы отвечают предъявляемым требованиям. - Валидация (Validation)
Демонстрация того, что продукт и его компоненты соответствуют его предполагаемому использованию в предполагаемой среде. - Фокусирование на процессах организации (Organization Process Focus)
Установление и поддержание понимания процессов организации и процессных активов, идентификация, планирование и внедрение улучшений связанных с данными областями. - Описание процессов организации (Organization Process Definition)
Установление и поддержание возможного к использованию массива процессов организации. - Организационный тренинг (Organizational Training)
Повышение знаний и способностей людей для выполнения ими своих ролей эффективно и рационально. - Менеджмент интеграции проектов (Integrated Project Management)
Установка и управление проектом и вовлечение всех заинтересованных лиц в интегрированный и определенный процесс. Данная область также затрагивает общее видение проекта командой разработчиков. - Менеджмент рисков (Risk Management)
Определение потенциальных проблем до их появления. В связи с этим процессы по снижению рисков могут планироваться и осуществляться на любом этапе разработки продукта или процесса. - Интегрированные команды (разработчиков) (Integrated Teaming)
Формирование и поддержание интегрированных команд для разработки продуктов работы (work products). - Интегрированное управление поставщиками (Integrated Supplier Management)
Мониторинг новых продуктов, оценка источников продуктов, которые могут удовлетворить требованиям к проекту и использование данной информации для выбора поставщиков. - Анализ решений и разрешение(Decision Analysis and Resolution
Разработка решений на основе структурированного подхода, который позволяет оценить альтернативные решения на основе установленных критериев. - Организационная среда для интеграции (Organizational Environment for Integration)
Предоставление инфраструктуры для интегрированной разработки продуктов и процессов и управление людьми (персоналом) в целях интеграции - Производительный организационный процесс (Organizational Process Performance)
Установление и поддержание количественного понимания производительности набора стандартизированных процессов организации и обеспечение информацией о производительности процессов и моделей для количественного управления проектами организации. - Количественный менеджмент проекта (Quantitative Project Management)
Количественно управлять определенным процессом в целях достижения установленного в рамках проекта качества и целей производительности. - Организационные инновации и внедрение(Organizational Innovation and Deployment)
Выбор и внедрение инноваций и улучшений, которые измеряемо, улучшают организационные процессы и технологии. - Анализ причин и разрешение (Causal Analysis and Resolution)
Идентификация причин дефектов и других проблем и принятие действий предотвращающих их появление в будущем
И зачем эта модель нам?
Использование модели CMMI позволяет организации оценить эффективность процессов, установить приоритетные направления их усовершенствования, а также внедрить данные усовершенствования.
Внедрение СММ/CMMI позволяет улучшить структуру и качество процессов (основные проблемы в программных разработках — это проблемы управления, а не технические проблемы), обеспечить стабильно высокое качество разработок и освоить процессы, которые могут служить основой для повышения конкурентной способности и дальнейшего развития и расширения компании.
В основе CMM/CMMI лежит понятие процесса. Принятие этой концепции помогает избежать естественной для многих организаций тенденции винить в неудачах людей. Увольнение сотрудников — не решение проблемы. За последние десятилетия произошли революционные изменения в технологии, однако проблемы успешного выполнения проекта остались. В этом аспекте технология также не решение проблемы. Ценность процесса в том, что он помогает уловить и использовать наивысшие достижения в будущих проектах. Именно на этой предпосылке и базируется CMMI.
СММ/CMMI — это модели, т.е. упрощенное представление мира. Модели СММ/CMMI содержат существенные элементы процессов, обеспечивающих разные стороны деятельности, и могут быть использованы как руководство для разработки и улучшения производственных процессов. В официальных изданиях модели подчеркивается, что она не представляет собой процессы или их описание. Реальные процессы в любой организации зависят от множества факторов, включая специфику бизнеса, структуру и размер организации.
Итог?
Подводить итоги рано. Это скорее рекламная, обзорная статья, не описывающая механику внедрения модели. Если возникнет заинтересованность, я начну описывать подробнее её структуру. Скорее всего, статьи будут представлять собой несколько вольный перевод официальной документации от SEI с поясняющими комментариями.
