Пользователь
0,0
рейтинг
23 декабря 2009 в 22:02

Управление → Модель CMMI

Всем здравствуйте! Наконец-то я на Хабре. Постараюсь незамедлительно начать приносить пользу если не всему сообществу, то хотя бы некоторой его части:)

Я был немало удивлён, обнаружив, что на Хабре практически нет информации о модели 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 с поясняющими комментариями.
Артур @arty87
карма
41,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (63)

  • +1
    Насколько понял CMMI — подобие PMI PMBoK, только для разработки.
    • +2
      Не так. CMMI — это и модель разработки, и модель оценки. PMBoK — это book of knowledge. Т.е. это по сути рассказз о том, что вообще есть в отрасли и как это использовать, но не более того.

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

      Ближайшим аналогом CMMI может быть RUP или MSF, только в них нет разделения на уровни и нет сторонней оценки (аттестации).
      • +1
        еще есть такая метода как PRINCE2, она очень хорошо с CMMI стыкуется — вот я ее тут описывал xariton.habrahabr.ru/blog/70051/, но не хватает кармы, чтобы опубликовать.
    • +1
      Насколько я понимаю, PMBoK — это тоже набор best practices, рекомендации. И та, и другая методология использует в своей основе процессный подход. А вот области покрытия процессов в организации различаются — некоторые пересекаются, некоторые представлены только в одной из них.

      Более похожим на CMMI является другой продукт от Project Management Institute: Organizational Project Management Maturity Model (OPM3) — модель оценки зрелости проектного управления в организации. Это своего рода переложение содержания PMBoK на формат CMMI.
    • 0
      Подобием PMBOK для разработки ПО является SWEBOK — Software Engineering Body of Knowledge
  • 0
    Вы знаете, сколько в России компаний, пятого уровня зрелости? На сколько я в курсе, пару лет назад была только одна Моторолла в Питере, да и только потому, что они привезли с собой все процессы.

    Я конечно могу ошибаться, но так понимаю, что причина отсутствия информации на хабре о CMMI в том, что данная концепция претит русскому человеку, программисту или менеджеру. Не наше оно.
    Так-что, очень интересно услышать Ваше мнение о текущем состоянии дел с CMMI именно в России. В частности о специфике её восприятия
    • +3
      Luxoft к примеру еще.Если я не ошибаюсь в России около десятка компаний данного уровня.А насчет того, что концепция не подходит русскому человеку, готов поспорить, почему то у индусов она приживается, а списывать все на менталитет как то не хорошо.Сами на фирме внедряем процессы по данной системе, самое тяжелое перейти на первый уровень=)
      • 0
        Есть такое мнение, что наш человек слишком творческая личность, чтобы позитивно воспринимать такой подход.
        Для компании да, очень хорошо. В идеале, параллельно росту плавно переходим с уровня на уровень. Незаменимых нет, красота.

        Именно по этому кстати он очень прижился в Индии. Там программинг, это конвеер. Студент приходит в контору, обучается, работает некоторое время, затем набирает опыт и вероятностью практически со 100% вероятностью уезжает в США или Европу, но, незаменимых нет и система с лёгкостью принимает нового молодого индуса
        • +3
          Вы очень удачно затронули тему менталитета. Наш человек это личность, которая верит в сказу про Ивана-дурака. В сознании масс, русский программист это такой себе прирожденный гений, который все знает, ничего не изучая, играючи напишет код любой сложности на коленке и обязательно заткнет за пояс любого иностранца, который только и знает, что прикрываться умными терминами.

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

          Отечественному IT рынку пора взрослеть и переходить от модели «Нанял программиста -> ??? -> PROFIT» к грамотному процессному подходу.
          • +1
            Пора то пора, но это будет ой как не просто. Ломать, менять самосознание людей с верху не легко.
            Хотя, вот если в рамках гос-инициативы по электронизации ввести требования, аналогичные штатовским, что к госзаказам в IT допускаются только пятого уровня конторы, то шевеление начнётся нешуточное, уверен :) Может даже и польза будет!
      • 0
        Exigen Services, не пятый уровень, правда.
        • 0
          Откуда такая информация?
          У Exigen Services пятый уровень CMMI, это даже на сайте написано.
          • 0
            Серьезно? Еще недавно вроде 3й был.
            • 0
              3й был у StarSoft, а после слияния с эксидженом получили 5ый.
              Летом прошлого года уже точно был 5ый уровень CMMI.
              • 0
                Интересно насколько сильно только коррелируют эти уровни с эффективностью компаний.
      • 0
        На первый уровень переходить не надо. Это как в VB — первый элемент массива — по индексу 1. т.е Вы уже там, нулевого уровня нет :)
        • +2
          Чтобы перейти на первый уровень надо закончить хотя бы один проект. Что тоже непросто :)
          • +1
            Теперь есть нулевой уровень! (@Kung Fu Panda)
            С него конечно лучше на первый двигаться. Попытка перейти с нулевого на пятый запросто может Вас привести снова к нулевому :)
        • +1
          я опечатался, конечно второй, первый уровень это хаотическая разработка)
      • 0
        Гдето неделю назад читали нам лекцию на работе про CMMI.
        Насколько я помню там говорилось о 2-3 компаний в России пятого уровня. И около десятка четвертого уровня.
    • +1
      Да, это по-русски:) если мы зрелые, то сразу на пятёрку!
      На самом деле, зачастую третьего уровня уже достаточно для себя, а четвёртого — для заказчиков. Если заказчик — не министерство обороны США:)

      Но даже попытка привести всё к стандарту второго уровня уже может принести свои плоды, она обнажит некоторые недостатки в организации производственных и управленческих процессов, на которые раньше, возможно, не обращалось внимание. А вот заниматься ли исправлением этих недостатков решает руководство. В зависимости от того, насколько эффективными и затратными окажутся предложенные улучшения.
    • 0
      Еще есть вопрос. Всем ли компаниям нужны эти бумажки о том, что у них пятый уровень зрелости? Какой уровень CMMI у компаний Microsoft, Google, SAP?
  • +5
    В этом прелесть и проблема наших людей, не могут обуздать свое творчество, и вместо того чтобы заниматься делом эффективно и совместно, каждый воротит носом и говорит, что он творческая личность.Если люди в возрасте 30-35 лет которых, хоть как то морально воспитывали при союзе реально могут осознать свои возможности, то большая часть молодежи думает, что она дико гениальна.Как раз отлаженные процессы CMMI позволяют остепенить молодежь и показать ей, что в наше время один далеко не уйдешь, программирование это уже давным-давно коллективная игра, а мы все еще в догонялки играем, обидно.
    Насчет конвеера согласен, но никто не запрещает нам адаптировать процессы CMMI под наши реалии, это больше рекомендации, чем готовое решение.
    Хочу заметить, что в сравнении с той же моделью ISO 9001,CMMI на порядок больше дает информации о компании как о разработчике,80% небольших и успешных компаний находятся на первом уровне, условно говоря, но справляются со своей работой благодаря большой самоотдаче и местами самопожертвованию, что тоже характерно для нашего менталитета=)
  • +2
    Хорошая обзорная статья.

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

    Кстати, дополнение — 1-му уровню CMM/CMMI в принципе соответствует любая компания, успешно закончившая хотя бы 1 проект :)
    Т.е. 1 уровень — это хаос, но хаос успешный. А вот дальнешие уровни этот хаос постепенно успокаивают и «кристаллизуют».

    Кстати, насколько я слышал, министерство обороны Штатов в качестве подрядчиков не работает с компаниями, не имеющими высокий уровень по CMM/CMMI.
  • +2
    Кстати, переноси топик в «Управление проектами» — там ему самое место.
    • 0
      Самое место ему в «Организации разработки ПО».

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


    Хотя то, что девелоперу кажется ненужными формальностями, позволяет всем процессам быть предсказуемыми и управляемыми.
    • 0
      Хм, весьма забавно, но отдельное внимание в модели уделяется управлению данными (data management) и созданию репозиториев, что, на мой взгляд, как раз позволяет снизить уровень бюрократии.
  • +1
    Обязательно пишите про механику внедрения по возможности. Лично мне будет интересно.

    И еще хотелось бы узнать как же конкретно CMMI относится к конфигурационному менеджменту? Предъявляются ли какие-то требования к процессам конфигурационного менеджмента или он просто «должен быть»? Насколько я знаю, в CMMI не предъявляется жетских требований к необходимости использования, к примеру, контроля версий. Если так, то как тогда как CMMI предлагает осуществлять конфигурационный менеджмент? Ведь контроль версий — это его основной процесс. С другой стороны я понимаю что CMMI не должен опускаться до таких деталей, но, тем не менее, всё равно интересно насколько детализированы/абстрактны описания высоких уровней зрелости.

    • +2
      Я участвовал в написании процессныйх документов именно для CM KPA.
      По сути стандарт говорит — надо иметь такие-то и такие-то практики (например, контроль версий), и иметь документы, которые эти практики описывают для участников проектов и всех stakeholders (например, документация по использованию VCS, политики ветвления, выпуская релизов, тренинги).
      Но вот конкретику — какую именно систему контроля врсию использовать, или какие готовые документы по политикам ветвления и интеграции прдложить — этого CMMI не дает. Это отдается на откуп самой организации.
      • 0
        То есть, проще говоря, нужно иметь CMP (Configuration Management Plan). Этого достаточно? Всё перечисленное можно втиснуть в рамки этого документа. Но мне всё таки интересно, есть ли требования CMMI к тому, что конкретно должно быть обязательно включено в CMP. Ведь сами по себе практики конфигурационного менеджмента вроде как опциональны. Кроме контроля версий стандарт требует наличие каких-то практик? Если да, то каких? Насколько глубоко описываются требования к использованию контроля версий и вообще специфицируется ли то, что же конкретно такое контроль версий?
        • 0
          SCMP — это итог всей работы по установлению СМ-процесса. Вообще любые документы — это лишь форма для сохранения знаний.
          Насчет практик — СММ предписывает, помимо контроля версий, вообще контроль за изменениями, куда входит и отслеживание запросов на изменения. Также внимание в стандарте уделяется определению бэйзлайнов и выпуску релизов. А вообще полный перечень есть в CM KPA — там есть подробности.
    • 0
      Читал. Не понравилось. Автор пытается совместить ужа с ежом.
      К CMMI, как части системы менеджмента качества, тема социальной ответственности и стратегия развития рынка (проблема, как не «исчерпать рынок клиентов») не имеют никакого отношения. Всё это части менеджмента стратегического. CMMI там уже не место.

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

      Я вообще не вижу противоречия в том, что молодые компании компании не могут получить крупные заказы. Может ли выпускник претендовать на должность директора? Так и на рынке разработки ПО: только опытным компаниям доверяют разрабатывать крупные проекты.
  • 0
    Интересно, на каком уровне CMMI находится Гугл? Или Facebook? Или MSN?

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

    • 0
      На мой взгляд, сертификация по модели CMMI требуется только для повышения спроса. Сомневаюсь, что командам разработчиков Google, Facebook или MSN требуется дополнительный спрос.
      А вот внедрить что-либо из этой модели они могут, но об этом вы вряд ли узнаете. Вы много знаете о процессе разработки в компании Google или других крупных компаниях? Обычно такая информация является коммерческой тайной.

      Зачем же противопоставлять стабильность и инициативность/изобретательность? Стабильность означает гарантию выполнения взятых обязательств, а изобретательность позволяет выполнить эти обязательства с меньшими затратами.

      К тому же CMMI не накладывает ограничений на инициативы и изобретения. Более того, 5 уровень требует регулярного внедрения инноваций!
      • +2
        «сертификация по модели CMMI требуется только для повышения спроса.»

        Сертификация по моделии CMMI требуется для того, чтобы участвовать в тендерах, в которых предприятия, имеющие эту самую сертификацию, имеют больше шансов выиграть. Подобные тендеры к рынку имеют довольно опосредованное отношение, поэтому о спросе тут не стоит говорить. В тендерах МО США я не участвовал, но с тендерами ЕКА знаком не по наслышке. Сертификация там — способ поднять планку и искуственно ограничить количество заявок. И агентству хорошо — меньше заявок разбирать, и участникам тендера — меньше конкурентов.

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

          Насчёт откатов… Не знал. Спасибо, что просветили. Ну неужели без этого мало способов отмывать деньги?
          • +1
            Не думаю, что у МО США с подрядчиками сложились рыночные отношения ;-) Скорее всего, тендеры выигрываются как следствие длительной и сложной подковёрной борьбы. А сама система тендеров существует лишь для того, чтобы соблюсти внешние приличия.

            Что касается видов откатов, то вы будете изумлены изобретательностью власть придержащих в странах развитого капитализма. Вот здесь habrahabr.ru/blogs/i_am_clever/63527/ я описал механизм создания новой бизнес-ниши и заполнения её «нужными» людьми. Эта история покруче Фауста Гёте будет.
    • 0
      Различайте индустрию услуг и индустрию продуктов. CMMI жизненно необходим как способ опосредованно оценить возможное качество услуги для ЗАКАЗНОГО ПО.

      Гугл и Facebook — это продуктовые компании. С точки зрения потребителя, абсолютно всё равно, как оно там внутри.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Хотите вкратце? Да запросто:)

      CMMI — это сборник рекомендаций ЧТО можно улучшить на всех этапах разработки ПО (от планирования до внедрения и сопровождения), а также в сопутствующих областях, таких как управление соглашениями с поставщиками, управление конфигурациями, контроль качества и т.п.
      Местами есть рекомендации и КАК можно улучшить, но в целом — это остаётся на усмотрение самой организации.

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

      И раз эта система зарекомендовала себя на западе — значит, она работает?:)

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

      Оба варианта приносят пользу: первый позволяет сократить производственные издержки, второй повысить спрос на продукцию.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Всё-таки это обзорная статья, и я постарался погрузить читателя на максимальную глубину понимания предмета в столь коротком объёме текста.
          Официальный документ — 573 страницы текста, и даже этого недостаточно для полного понимания, поскольку регулярно издаются книги и представляются доклады на конференциях, комментирующие и дополняющие содержание модели.

          План был простенький:

          0. Введение. Актуальность.
          1. Определение.
          2. История вопроса. Как и для чего создавалась этот модель.
          3. Два основных понятия, без которых невозможно понимание всей концепции модели:
          а) уровни зрелости
          б) процессные области
          4. Как работает модель и какую пользу приносит. Фактически, просто рекламный обзор.
          5. Заключение.

          Всё и так очень сжато.

          Можете дать какие-то рекомендации на будущее? Добавить содержание в начало, краткое изложение в конец?
          Не нарушит ли это внешнюю стройность текста и не перегрузит ли его ещё больше?
          • НЛО прилетело и опубликовало эту надпись здесь
            • +2
              По моему опыту, «ментальные карты» хорошо походят только для того, чтобы лично разобраться в новой теме. Кому-то что-то объяснять путём показа этих «ментальных карт» мне было сложно.

              ЗЫ: А чего это вы вообще о «ментальных картах» заговорили?
  • 0
    А зачем это вообще здесь? Чтобы что?
    • +1
      Я думаю полезно для понимаю, до того как с этим столкнешься. Я в свое время пришел работать в тот же Люксофт, совершенно не зная что такое CMMI 5, ни до, ни во время работы. В результате ушел, посчитав все это непонятной мне фигней. Много лет позже я все таки добрался и ознакомился с этим, и сейчас согласен что в случае Люксофта это нужно. И жалею что в то время не было возможности ознакомится (именно вот так как сейчас на хабре, пассивно. намеренно мне тогда в голову бы не пришло искать, ведь я даже не догадывался об этом). Не факт что это положительно повлияло бы, и что вообще пошел бы работать в Люксофт (или наоборот), но я, по крайней мере, понимал бы что это, и это бы очень помогло.
      В общем тут есть достаточно много различных ИТ специалистов, и это нужно иметь ввиду, не зависимо от того используешь это на практике или нет. А сайты типа вашего uml2 и пр. не все ведь ежедневно читают.
      • 0
        Игорь, расскажите пожалуйста, как именно иначе развернулась бы ваша судьба, как бы строилось ваше поведение в Люксофте, если бы вы прочитали эту статью?

        В каких именно местах вашей деятельности данное знание бы вам помогло и как?
        • 0
          Самому очень интересно как бы развернулась моя судьба. Но факт в том что я столкнулся с этим совершенно не понимал что это. Естественно мне это не понравилось. Скорее всего, если бы я понимал систему до того как попал в нее, я бы гораздо дольше проработал в Люксофте.
      • 0
        Про UML2.ru:
        Во-первых, этот сайт — не мой;
        во-вторых, он посвящён отдельным областям знаний в разработке ПО, в основном 1) разработке требований и 2) разработке моделей программных систем
        и к организации производства ПО имеет достаточно малое отношение.
        • 0
          c uml2 значит ошибся, я почему то считал что он как то с вами связан. Это был лишь пример тематического сайта, аудитория которого слабо пересекается с аудиторией хабра. Я, на самом деле, его не читаю, лишь иногда он мне попадается, но думаю что все таки близок аудитории данной темы. Ну нет так нет, это на вкус, есть и другие сайты.
    • 0
      Как минимум для того, чтобы я смог узнать о сайте uml2:)

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

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

        А CMMI — это не для начинающих и продолжающих явно инструмент.
      • 0
        На всякий случай, МОЙ сайт — это system-analysis.ru и если вы имели в виду его, то «поисковики» и не должны были на него указывать, т.к. он посвящён не организации производства ПО, а несколько более узкой, с одной стороны, а с другой перпендикулярной теме.
  • +2
    А вы не могли бы рассказать еще о PSP — такой же модели как CMMI, но для индивидуального разработчика?
  • 0
    Сколько же рабочего времени мы убили в нашей компании на эту муть.
    Imho, СММ(i) пригодна когда заказчик хочет видет 'внутренности' процесса разработки, который делает подрядчик.
    В остальном же это — мифилогизированный фетиш для больших компаний которым некуда выкинуть деньги.
    Нигде не встречал сколько-нибудь убедительных доказательств что CMM и подобные бюрократизмы повышает эффективность разработки и компании в целом.
    А накладные расходы на создание и поддержание процесса могут занимать до 30% рабочего времени (по моим очень субъективным оценкам).

    Сорри за эту ложку дёгтя.
    Сказанное, разумеется, только мое личное imho.

    • +1
      Любая более-менее крупная компания и команда требуют внедрения хотя бы минимального процесса разработки — хоть CMM, хоть XP, хоть RUP… но требует. Крупные команды не могут работать в хаосе, это непродуктивно. А внедрение любой методики требует затрат ресурсов.
      Насчет 30% — откуда цифра? Если речь о создании процесса — да, первоначальный вложения относительно велики. Однако поддержание процесса — это всего лишь следование ему и выполнение всех предписанных практик — так же, как и при любой другой методологии.
      • +1
        Ну за все крупные компании расписываться не могу, мы в нашей компанни работали с двумя крупными американскими компаниями. Обе весьма успешны. Одна из них требовала от нас введения CMM-а, хотя сама при этом внедряла его весьма небрежно, для галочки.
        Во второй компании вообще, как я понял, практически нет 'процесса', ну за исключением абсалютно необходимых вещей типа: контроля версий, баг треккинга и отчетов.

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

        По поводу 30% — цифра, как я написал, основанна на субъективных наблюдениях. Следование процессу тоже занимает много времени. Например если мы вводим классификацию ошибок, каждый разработчик, или тестеровщик должен сидеть и в отчете аккуратно классифицировать каждый баг. А это может быть настоящим pain in the ass.

        Главное при разработке процесса на каждом шаге спрашивать себя, а каковы конечные цели? Если цель — преодоление хаоса, то это один случай, здесь можно обойтись более простыми вещами и CMM, и пр. здесь избыточны.
        Если цель дать менеджерам возможность понимания что происходит на всех проектах — это другое. Если нужно чтобы руководство компаннии могло влиять на процесс в целом по компании — это третье.
        Т.е. на каждом шаге важна целесообразность — не за чем собирать по компании метрики если руководство не собирается на них смотреть.

        А вообще, такой вопрос: вы в своей компании на самом деле собрались внедрять CMMi или это был просто теоретический обзор?
        • 0
          Что ж, подпишусь практически под каждым словом — главное целесообразность, процесс ради процесса — это зло.
          К слову — в Microsoft используется MSF — он также является самостоятельной методологией со своим процессом, пусть и не таким монструозным.

          Насчет моей компании — когда я пришел, уже имелся CMM level 3. Пока работал — было движение в сторону сертификации уже на CMMI, причем на уровень не ниже 4. В общем-то, делалось это и для галочки (чтобы привлекать заказчиков), и для себя — т.к. сертифицироваться на уровень, не имея эффективного работающего процесса — это почти нереально. Однако вскоре дела у основного заказчика пошли неважно и все внимание переключили на собственно работу.

  • +1
    Давайте попробуем начать с простого вопроса — что знакомство с данной моделью может дать представителям разных рабочих ролей в компаниях, работающих на разных рынках и имеющих различные масштабы?
  • 0
    Вечер добрый… (сам хотел написать давно что-нибуть о CMMI, да всё времени не хватало :( )

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

    пару input-ов для изменения автору:
    1) было бы лучше собрать все процессные области по группам (так и людям понятнее и читабельнее)
    2) не описан процесс сертификации (что 1-2 уровни компании просто могут себе сами присвоить по сути, а начиная с 3го уровня компания должна проходить официальную сертификацию другой компанией имеющей на это право… можно и примерные цены выложить, думаю интересно будет )
    3) действительно (как замечено в других комментах) не хватает статистики — какие коммпании с каким уровнем… и т.п.

    в принципе статья неплохая (понятно что обзорная), а дальше что-то будет?:)
    • 0
      упс, «1-2 уровни компании просто могут себе сами присвоить по сути» — само-собой не могу, просто на эти уровни никто не сертифицируется…

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