В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

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

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области ПО, и членами общества разработчиков. [1]

1. Начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу, и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.
2. Повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 1999 года лишь 20 % организаций имели 2-й уровень или выше.
3. Установленный. Имеют определённый, документированный и установленный процесс работы, не зависящий от отдельных личностей. То есть вводятся согласованные профессиональные стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надёжно предсказывать затраты на проекты, аналогичные выполненным ранее.
4. Управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений. Но нет изменений при появления новых технологий и парадигм.
5. Оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration). На текущий момент последняя версия CMMi — 1.3 (опубликована в ноябре 2010) [2].

Форум студентов МТИ > Основной раздел > Тесты > Моделирование систем управления

PDA

Просмотр полной версии : Моделирование систем управления

vBulletin® v3.8.7, Copyright ©2000-2018, vBulletin Solutions, Inc.

Перевод: zCarot

Методология разработки ИС. Модель зрелости CMM/CMMI.

В 1991 году Институтом программной инженерии Университета

Карнеги-Меллона (Software Engineering Institute, SEI) была создана модель зрелости СММ (Capability Maturity Model) для разработки программных продуктов. С течением времени было выпущено целое семейство моделей:

SW-CMM — для программных продуктов, SE-CMM — для системной инженерии, Acquisition CMM — для закупок, People CMM — для управления людскими ресурсами, ICMM —для интеграции продуктов.

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

требованиями международных стандартов. Поэтому в 2002 году SEI опубликовал новую модель CMMI (Capability Maturity Model Integration), объединяющую ранее выпущенные модели и учитывающую требования

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

области. При этом все области задаются в виде требований, определяющих не то, как они реализованы, а интерфейсные требования. Из этого имеется два следствия.

Следствие 1. CMMI допускает различные реализации и не является методологией разработки ПО, подобно MSF, Scrum, RUP и пр. Последние могут использоваться в его реализации. Так, существует, например, специальный шаблон процесса в VSTS для CMMI под названием MSF for CMMI.

Следствие 2. CMMI используется для сертификации компаний на зрелость их процессов. Изначально, в конце 80-х начале 90-х годов, CMM (тогда еще не CMMI) создавался именно как средство сертификации

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

Например, авиационная, аэрокосмическая индустрии. То есть разработка ПО

происходит вместе с инженерными работами иных видов. И часто бывает, что в одном проекте участвует более двух различных видов инженерии. Задача CMMI – предоставить таким проектам и компаниям единую платформу организации процесса разработки.

В отличии от классической модели CMM, которая была жестко иерархической и допускала только последовательное улучшение процессов по уровням, модель CMMI имеет два измерения — последовательное, такое

же как и в CMM, и непрерывное, допускающее совершенствование процессов в организации до некоторой степени в произвольном порядке. Здесь мы остановимся на последовательной модели. Она имеет 5 уровней

зрелости процессов (рис. 1).

Начальный уровень (уровень зрелости 1) — это уровень, на котором, по определению, находится любая компания. На этом уровне разработка ПО ведется более-менее хаотично.

Управляемый уровень (уровень зрелости 2) — здесь уже появляются политики и процедуры организации процессов, утвержденные на уровне компании. Но в полной мере процессы существуют лишь в рамках отдельных проектов.

Определенный уровень(уровень зрелости 3) — здесь появляется стандартный процесс на уровне всей компании в целом.

What is Capability Maturity Model (CMM)? What are CMM Levels?

Это большой и постоянно пополняющийся набор активов процесса: шаблонов документов,

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

Управляемый количественно уровень (уровень зрелости 4) подразумевает появление системы измерений в компании, которые происходят на базе стандартного процесса и позволяют количественно управлять разработкой.

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



Многим известна аббревиатура CMMI, многие знают, что это — модель, т.е. набор рекомендаций как улучшить процессы, связанные, например с разработкой ПО. Но немногие знают, что моделей CMMI несколько. Самая известная из них —  CMMI for Development (CMMI-DEV), которая действительно связана во многом с деятельностью разработческих компаний (т.е. тех компаний и организаций, которые разрабатывают и поставляют некий программный продукт или иное комплексное — программно-аппаратное решение).

Но как быть тем, кто поставляет не продукт, а услуги (например, сопровождение продукта с незначительной долей разарботки в общих трудозатратах или вообще с отсутствием таковых)? Для них тоже есть набор рекомендаций — модель CMMI for Services (CMMI-SVC). Для IT-подразделений, например, эта модель (точнее — её рекомендации) может помочь понять — что надо сделать, чтобы, например, те же рекомендации ITIL, приобрели характер нормального процесса, а не некой «сакральной практики».

Capability Maturity Model (Модель развития функциональных возможностей) (CMM)

Любопытно, что рекомендации этой модели достаточно универсальны и не «замыкаются» только на информационные технологии. Пилотное внедрение практик этой модели проходило … в одной из больниц в США (ведь медицинское обслуживание — это тоже услуги).

Однако, любой модели из перечисленных лучше обучиться. И если на всё СНГ обученных модели CMMI-DEV несколько сотен наберется (порядка 250-300 человек), то обученных модели CMMI-SVC в СНГ… 6 человек. Речь идет именно об обученных, а не об инструкторах. Это как раз и было до декабря 2011 года главной проблемой: по CMMI-DEV на весь мир был только один сертифицированный институтом SEI (разработчиком моделей CMMI) русскоязычный инструктор, а по другим моделям таковых вообще ни одного! Теперь появился такой инструктор и по модели CMMI-SVC (отсюда и первые 6 обученных). Этим инструктором является автор данной публикации, который готов ответить на любые вопросы по упомянутым моделям, и по официальному обучению. Спрашивайте!