Чем выше уровень зрелости данной организации в модели CMM, тем выше вероятность успешного завершения программного проекта в срок, с заданным качеством поставляемого продукта и рамках установленного бюджета. Соответственно, тем выше производительность труда разработчиков и качество поставляемого продукта, и ниже себестоимость разработки и риск неуспеха по причинам, в той или иной мере зависящим от разработчика. Эта сравнительная характеристика уровней зрелости представлена на Рис. 22. В столбце «Структура процесса» схематично представлена структура процесса каждого уровня, а в столбце «Вероятность успеха» дан качественный график распределения вероятности успешного завершения проекта в зависимости от времени, причем вертикальная пунктирная линия означает планируемый срок завершения проекта.
Уровень зрелости
Характерис-тика
Структура процесса
Вероятность успеха
Процесс улучшения встроен в сам процесс разработки
Произ-води-тель-ность и ка-чест-во
4. Управ-ляемый – Managed
Бизнес процессы в организациях. Мастер-класс Александра Пронишина для Европейской бизнес-ассоциации
Количествен-но / Измеряемый процесс на базе метрик
3. Опреде-ленный – Defined
Качественно / Процесс определен и внедрен
2. Повто-ряемый – Repeatable
Интуитивно / Процесс пред-сказуем и за-висит от от-дельных лиц
1. На-чальный – Initial
Ad hoc / Процесс хаотичный и непредсказу-емый
Рис. 22. Характеристика уровней зрелости в модели CMM
На первом (начальном) уровне явного и внятного процесса разработки просто нет, но это не значит, что в процессе первого уровня нельзя сделать хороший проект. Такие проекты были и некоторые из них получили хорошие результаты. Но их беда в том, что они непредсказуемы. До момента, пока проект не закончился, неизвестно, закончится ли он вообще или нет, а когда закончится, только тогда можно будет узнать результат. Поэтому в столбце «Структура процесса» представлено отсутствие явной структуры, а кривая распределения вероятности успеха говорит о том, что огромная часть проектов заканчивается с большим превышением срока или не заканчивается вообще.
Второй (повторяемый) уровень говорит о том, что если исполнитель берется за новый проект, похожий на прежний, то результаты, затраты и сроки окажутся примерно такими же. Отличие второго уровня от первого еще в и том, что на первом уровне процесс вообще не имеет никакой структуры, а на втором он уже структурирован – разделен на фазы и, кроме самого процесса, есть еще и некоторое управление процессом, выделенное отдельной линией, взаимодействующей с собственно разработкой.
Если на втором уровне фазы процесса замкнуты, то на третьем (определенном) уже и они имеют некоторую структуру и управление ими более сложное; оно включает в себя дополнительные элементы, адресующиеся к структурным элементам фаз. Благодаря этому обстоятельству проекты на третьем уровне, как правило, всегда заканчиваются, хотя большинство все же по разным причинам в срок не успевают. Качественное отличие в распределении вероятности успеха на третьем уровне от предыдущего уровня в том, что пик распределения очень близок к планируемому сроку, и практически нет незаконченных проектов.
На четвертом уровне (управляемом) проекты заканчиваются в срок, только есть еще отклонения от цели. Точность планирования зависит от ряда причин, вполне возможно завышение требований или их недооценка. Но зато проекты заканчивается с приемлемым качеством. Как и на предыдущем уровне, внутренние элементы процесса имеют свою структуру, но что важно, управление процессом взаимодействует активно уже и с ними. Если на третьем уровне ведется только наблюдение за фазами разработки и снимаются необходимые метрики процесса для их ретроспективного анализа по окончании проекта, то на четвертом уровне разработчики активно воздействуют на процесс в ходе разработки по результатам регулярного анализа этих метрик.
На пятом (оптимизирующем) уровне пик распределения вероятности очень тонкий, т.е. пятый уровень идеален по части точности планирования. В процесс разработки встроена такая малоизученная вещь, как постоянное самосовершенствование процесса, что схематично представлено в столбце «Структура процесса».
Суммируя все предыдущее, можно сказать, что на первом уровне результат не предсказуем. Разные находки и удачные решения для реализации сделаны только для данного случая – ad hoc. Нет массовости и повторяемости в производстве продукта, нет продуманности: как правило, реализуется первое решение, какое приходит в голову разработчикам.
Оно может оказаться удачным для данного случая, но совершенно не годящимся для общего случая. На втором уровне результат предсказуем и имеет место управление процессом. На третьем уровне технология разработки программного продукта и управление существуют, определены и согласованно объединены.
На четвертом уровне процесс и продукты, создаваемые в этом процессе, постоянно контролируются измерениями и управляются через эти измерения. Именно поэтому четвертый уровень называется управляемым измерениями, результаты которых регулярно анализируются, по ним предпринимаются определенные управляющие воздействия на сам процесс разработки. Наконец, на пятом уровне имеет место постоянное встроенное и автоматизированное совершенствование процесса разработки.
Источник: studfile.net
Модели уровней зрелости CMM/CMMI.
Данный стандарт исходит из концепции, согласно которой существуют определенные критерии/при- знаки уровня развития процессов организации. В некотором роде он опирается на методологию зрелости систем управления СММ и ее модификацию для оценки процессов разработки ПО — CMMI.
Рис. 7.9. Обзор взаимодействия между элементами серии стандартов ИСО/МЭК 15504
СММ (Capability Maturity Model) — методология, предложенная в конце 1980-х группой специалистов Университета Карнеги — Меллон и призванная сформировать систему критериев выбора организаций-подряд- чиков для цели проектов разработки ПО. В связи с этим она называлась SE-CMM (Software Engineering Capability Maturity Model). А ее переработанная версия, посвященная целиком зрелости процессов разработки программного обеспечения, получила название CMMI (Integrated СММ).
Модели CMM/CMMI базируются на трех основных предположениях, которые применимы также и к стандарту ISO 15504.
- 1. Существуют несколько уровней зрелости проектной организации. Эти уровни зависят от ряда критериев и применимы также к разрабатывающим и внедряющим системы организациям. Всего данных уровней выделяется пять.
- 2. Любая организация заинтересована в переходе на более высокий уровень зрелости.
Это важно не только для выживания и сохранения конкурентоспособности на рынке, но и для повышения внутренней эффективности и качества выполнения проектов.
3. Переход возможен только на следующий уровень.
Нельзя «перескакивать» через уровни, так как одновременное внедрение большого числа мер для повышения зрелости резко повысит риски и может привести к непредсказуемым последствиям в случае неготовности организации к переходу.
Рассмотрим описание уровней зрелости SE-CMM в их первоначальном виде.
Схематично данный уровень зрелости представлен на рис. 7.10.
Уровень 2 — Повторяемый (repeatable). Созданы базовые способы контроля проектов: планирование и мониторинг времени, стоимости, содержания и качества (рис. 7.11).
Уровень 5 — Оптимизирующий (optimizing). Проактивное устранение существующих недостатков и «узких мест» процессов, их постоянный поиск и реализация возможностей по совершенствованию этих процессов (рис. 7.14).
Рассмотрев основные условия и особенности моделей зрелости SE-CMM, перейдем к конкретным описаниям уровней по CMMI (ISO 15504) в отношении процессов разработки. CMMI отличают более детализированные описания и использование не только терминологии пяти уровней зрелости, но и концепции «непрерывной модели» оценки процессов (дополнительные введенные на каждом уровне метрики: например, РА 2.1 «Управление производительностью»). Для большей наглядности и демонстрации применимости модели CMMI как части стандарта ISO 15504 к процессам создания и эксплуатации системы приведем по уровням соответствующие комментарии.
Уровень 1 — Выполняемый (performed). РА 1.1 Исполнение процесса. При разработке ПО используются типовые инструменты, основные процессы ЖЦ не регламентированы и исполняются в соответствии с квалификациями и опытом специалистов. Сроки неопределенны в связи с сильной зависимостью от конкретной ситуации и отсутствием методик и регламентов в качестве базы.
Уровень 2 — Управляемый (managed). РА 2.1 Управление производительностью и РА 2.2 Управление продуктом. С ростом сложности проектов по разработке и внедрению систем, ростом требований к квалификации специалистов появляются процессы управления процессом и самим продуктом. Проводится документирование проводимых работ и предпринимаются первые шаги по регламентированию и формированию методик разработки, оценки и сопровождения систем.
Уровень 3 — Устоявшийся (established). РА 3.1 Определение процесса и РА 3.2 Становление процесса. Третий уровень зрелости процессов жизненного цикла программных средств предполагает их стандартизацию, возможность доработки с учетом текущих особенностей конкретного проекта. К этому моменту процессы уже описаны, и для них сформированы четкие входные и выходные параметры, результаты, требования и условия. Онределены рекомендуемые к использованию с учетом конкретной ситуации программные средства и инструменты.
Уровень 4 — Предсказуемый (predictable). РА 4.1 Измерение/оценка процесса и РА 4.2 Контроль/мониторинг процесса. На данном уровне зрелости процессов ЖЦ организации уже способны реализовывать крупномасштабные проекты внедрения, даже с учетом жестких ограничений сроков, стоимости и заданного уровня качества. Соответственно, управление на четвертом уровне модели предполагает сформированные количественные показатели и характеристики процессов, для которых проводится мониторинг с последующим использованием полученной статистики и результатов для улучшения управления проектами и во избежание ошибок.
Уровень 5 — Оптимизирующий (optimizing). РА 5.1 Инновации процесса и РА 5.2 Непрерывная оптимизация. Наконец, на «Оптимизирующем» уровне зрелости возможно снижать совокупную стоимость создания и владения системой за счет своевременного планирования, проведения ретроспективного анализа и использования новых, более эффективных инфраструктурных ресурсов, методик организации управления проектом, выбора оптимальных с точки зрения качества, стоимости и соответствия требованиям программных решений.
Для каждого пункта вышеприведенного списка проводится оценка степени выполнения того или иного процесса. Итоговая шкала состоит всего из четырех значений:
- • не реализован (0—15%);
- • частично реализован (>15—50%);
- • в значительной степени реализован (>50—85%);
- • полностью реализован (>85—100%).
Источник: studme.org
Capability Maturity Model (Модель развития функциональных возможностей) (CMM)
Моделью Capability Maturity Model (Модель зрелости возможности) CM-CEI организационная модель, которая описывает 5 эволюционных этапов (уровней), на которых управляются процессы в организации.
Смысл Capability Maturity Model (Модель зрелости возможности), первоначально созданной для развития программного обеспечения, в том, что организация должна быть способна принять и поддерживать приложения своего программного обеспечения. Модель также предлагает конкретные шаги и инициативы, которые помогут организации развиться до следующего уровня.
5 этапов Capability Maturity Model (Модель развития функциональных возможностей)
Начальный (Initial) (процессы специальные, хаотичные или, на самом деле, немногие из них определены) Повторяемый (Repeatable) (основные процессы установлены, и существует дисциплина для того, чтобы придерживаться этих процессов) Определяемый (Defined) (все процессы определены, документированы, унифицированы и интегрированы) Управляемый (Managed) (процессы измеряются путем агрегирования подробных данных о процессах и их качестве) Оптимизирование (Optimizing) (непрерывное развитие процесса с помощью количественной обратной связи и испытания новых идей и технологий)
Модель развития программного обеспечения
CMM описывает принципы и практики, которые лежат в основе понятия зрелости программного процесса. Они предназначены для того, чтобы помочь фирмам по разработке и продаже программного обеспечения улучшить совершенность своих программных процессов эволюционным путем. Начиная от специальных, хаотичных процессов, переходя к зрелым, дисциплинированным программным процессам. Фокус делается на определение ключевых областей процессов и примерные практики, которые могут составить дисциплинированные программные процессы. Концепция зрелости CMM создает контекст, в котором:
- Практики можно повторить. Если вы не повторяете какую-то операцию, то не стоит ее улучшать. Существуют правила, процедуры и практики, которые принуждают организацию к внедрению и последовательному исполнению. Лучшие методы организации производственных работ можно быстро распространить между группами.
- Практики определены так, чтобы позволить обмен между проектами, таким образом обеспечивая некоторцю стандартизацию для организации. Отклонения в исполнении этих методов минимизируются. Количественные цели установливаются для задач; и установливаются, производятся и поддерживаются измерения для формирования основы для оценки. Практики непрерывно улучшаются для совершенствования возможности (оптимизирование).
Модель зрелости возможности полезна не только для развития программного обеспечения, но также для описания эволюционных уровней организаций в общем и описания уровня менеджмента, который организация реализовала или хочет достигнуть.
Структура Модели развития функциональных возможностей
- Уровни зрелости — многоуровневая концепция, обеспечивающая последовательность дисциплины, которая необходима для достижения непрерывного улучшения. Важно отметить здесь, что организация развивает способность оценивания последствий новой практики, технологии или инструмента.
- Следовательно, дело не в принятии этих нововведений, а скорее в том, как эти инновационные усилия оказывают влияние на существующие практики. Это оказывает поддержку проектам, группам и организациям давая им основание для обоснованного выбора.
- Ключевые области процессов — Ключевая область процессов/Key process area (KPA) определяет группу родственных операций, которые при совместном выполнении, достигают ряда важных целей. Цели — цели ключевой области процессов описывают положения, которые должны существовать для той ключевой области процессов. Положения необходимо внедрить эффективным и надежным способом.
- Объем, в котором цели выполнены, показывает какого рода возможность организация установила на этом уровне совершенности. Цели очерчивают сферы деятельности, границы, и цель каждой ключевой области процессов. Общие характеристики — общие характеристики включают практики, которые внедряют и институционализируют ключевые области процессов. Эти 5 типов общих характеристик включают: Обязателъство исполнить, Способность исполнить, Выполняемые инициативы, Измерение и Анализ, и Контроль внедрения. Ключевые практики — ключевые практики описывают элементы инфраструктуры и практики, которые вносят наиболее эффективный вклад во внедрение и институционализацию ключевых областей процессов.
Критерии для пределения процесса
Критерии для пределения процесса — это совокупность элементов процесса, которые необходимо включить в описание программного процесса для того, чтобы люди могли использовать их на практике. Для того, чтобы установить критерии вам надо задать вопрос — «Какая информация по программному процессу нужна для документирования?»
Такими Элементами процесса являются:
- Цель — почему процесс выполненяется? Вклад — какие продукты используются? Результат — какие продукты производятся? Роль — кто (или что) выполняет операции? Деятельность — Что сделано?
- Критерии для входа — когда (при каких обстоятельствах) можно начать процессы? Критерии для выхода — когда (при каких обстоятельствах) можно считать процессы завершенными? Процедура — как внедряются инициативы? Обзоры и проверки. Рабочие продукты, которыми надо управлять и контролировать (или установить в отношении них управление конфигурированием). Измерения. Тренинг.
- Инструменты.
Вид словаря:
Источник: hr-portal.ru
