В 1982 году Министерство обороны США образовало комиссию, основной задачей которой стало исследование проблем, возникающих при разработке программных продуктов в организациях министерства. В результате деятельности комиссии в декабре 1984 году был создан Институт инженеров-разработчиков программного обеспечения ( Software Engineering Institute, SEI ) на базе Университета Карнеги-Меллона в Питсбурге.

1987 г. SEI публикует: краткое описание структуры CMM ; методы оценки процессов разработки ПО ; методы оценки зрелости процессов производства ПО ; анкету для выявления степени зрелости процессов (для проведения самостоятельного, внутреннего аудита и внешнего аудита).

1991 г. Выпуск версии CMM v1.0.

1992 г. Выпуск версии CMM v1.1.

1997 г. Выпуск очередной (усовершенствованной) версии CMM .

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов. Для этого предполагалось создать критерии оценки зрелости ключевых процессов компании-разработчика и определить набор действий, необходимых для их дальнейшего совершенствования. В итоге методология оказалась чрезвычайно полезной для большинства компаний, стремящихся качественно улучшить существующие процессы проектирования, разработки, тестирования программных средств и свести управление ими к понятным и легко реализуемым алгоритмам и технологиям, описанным в едином стандарте.

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

Для оценки степени готовности предприятия разрабатывать качественный программный продукт СММ вводит ключевое понятие зрелость организации ( Maturity ). Незрелой считается организация, в которой:

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

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

Основные признаки зрелой организации:

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

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

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

Модели совершенствования

Совершенствование процессов работы с требованиями

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

В современной концепции процессно-ориентированной организации бизнеса процесс непрерывного совершенствования качества занимает одну из ключевых позиций.

Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Активное внедрение методов управления качеством на Западе началось в начале 1960-х годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous Process Improvement) и TQM (Total Quality Management) . Подъем экономики послевоенной Японии во многом был обусловлен идеям, заложенным в TQM.

Качество - термин, который для одних означает необходимость делать то, что желает потребитель, для других - то, что отвечает его потребностям. Менеджмент качества, как он определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если им известно то, чем они занимаются. .

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

Основные принципы ISO9000:

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

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

Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон.

Назначение стандарта - оценка уровня "зрелости" (maturity levels) организации - разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий (подробнее см. в ). Данный стандарт получил широкую известность, значительное количество западных IT-компаний сертифицировано по CMM.

В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем .

CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation) соответствует структуре SW-CMM с небольшими уточнениями наименований уровней. Пять уровней зрелости содержат 22 области технологических процессов, показанных в таблице 14.1. (CMU/SEI, 2000а). Непрерывное представление (continuous representation), содержит другой взгляд: те же 22 области структурируются по 4 категориям: управление процессами, управление проектами, конструирование и поддержка (CMU/SEI, 2000b).

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

Как и в CMM, в рассматриваемом стандарте на уровне 2 имеется область, именуемая "Управление требованиями", но, в отличие от предыдущего стандарта, на уровне 3 есть и отдельная область "Разработка требований". Размещение этой области на уровне 3 не подразумевает, что требования для проектов организации, не достигших уровня 2, собирать и документировать не нужно. Управление требованиями рассматривается как способ, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований .

Таблица 14.1.
Уровень зрелости	Название	Области процессов
	Начальный	(нет)
	Управляемый	Управление требованиями Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерения и анализ Обеспечение качества процессов и продуктов Управление конфигурацией
	Определенный	Разработка требований Техническое решение Интеграция продуктов Верификация Валидация Концентрация внимания на процессе Определение процесса организацией Организационное обучение Интегрированное управление проектом Управление риском Анализ и разрешение вопросов
	Количественно управляемый	Производительность организационных процессов Количественное управление проектом
	Оптимизирующий	Организационные нововведения и их развертывание Случайный анализ и разрешение

Область процессов "Управление требованиями"

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

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

Область процессов "Разработка требований"

В CMMI-SE/SW описаны три набора приемов разработки требований:

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

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

CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14.1).

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

Как правило, менеджмент качества программных проектов основывается на знаниях из трех источников:

Программный инжиниринг (ACM, IEEE);

Менеджмент проекта (PMI);

Качество (ASQ).

Институт программного инжиниринга (SEI, Software Engineering Institute) в Университете Карнеги Мэллон объединяет все эти три источника.

Модель зрелости функциональных возможностей (Capability Maturity Model, СММ) , служит "каркасом" процесса разработки ПО. Эта модель основана на практических действиях, и отображает лучшие результаты индивидов, работающих над усовершенствованием процесса разработки ПО и выполняющих оценочный анализ этого процесса. В дальнейшем мы будем ссылаться на то, каким образом менеджмент качества программных проектов соответствует модели СММ SEI. Поскольку модель СММ хорошо известна в сообществах разработчиков ПО, нет особой потребности приводить ее определение. Мы представим лишь краткое ее описание, чтобы продемонстрировать необходимость использования жизненного цикла в процессе разработки. Ниже приведена краткая обобщенная характеристика уровней развития функциональных возможностей модели СММ.

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

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

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

Определенный. Во всех проектах используется испытанная, адаптированная версия стандартного процесса разработки ПО данной организации.

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

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

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

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

Однако наличие повторяющегося процесса (уровень 2) заведомо не приводит к хорошо разработанному процессу. В общем, усовершенствование процессов происходит тогда, когда организация достигает уровня 3. Уровень 3 относится к решению как связанных с выполнением проекта, так и организационных вопросов, поскольку организация создает инфраструктуру, обеспечивающую эффективный программный инжиниринг и менеджмент по всем проектам. Две области КРА, определение организации процесса и интегрированный программный менеджмент, относятся к предметной области жизненных циклов.

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

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

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

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

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

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

Определенный - указывается "способ, требуемый для выполнения дела";

Документированный - разработан таким образом, что может быть известным и используемым в дальнейшем;

Изученный - обучение на основе документации;

Практичный - может применяться на практике, а не откладываться в "долгий ящик";

Поддерживаемый - доступный, пересмотренный и улучшенный;

Контролируемый - изменения одобрены "участниками совместного дела";

Верифицирован - процесс выполняется корректно;

Проверен - выполняется именно тот процесс, который необходим;

Измеренный - оцененная производительность применяется в качестве базиса для контроля и улучшения процесса;

Способность к улучшению - гибкость и способность к изменениям.

Инжиниринг программных продуктов относится к области ключевых процессов для уровня 3, т.е. "определенного". До 1968 года термин "программный инжиниринг" вообще не применялся. Программный инжиниринг представляет собой практическое приложение научных знаний к процессу проектирования и разработки компьютерных программ. Этот процесс также называется разработкой ПО или производством программ.

Первое появление широко распространенного ПО датируется 1890 годом. Именно в это время в Американских центрах по проведению переписи населения появились перфокарты Германа Холерита (1860-1929 гг.), Массачусетский технологический институт, Кембридж, штат Массачусетс.

В это же время произошел первый перерасход средств по вине "компьютеров". Результаты центров по проведению переписи населения США изначально были протабулированы с помощью вспомогательных механических средств; механических табуляторов Германа Холлерита. В это же время и начало развиваться производство перфокарт. Средства, затраченные на табуляцию данных центров переписи населения, на 98 % превышали аналогичные затраты, понесенные в прошлом. Отчасти это объясняется тем, что шаблон, используемый при табуляции данных, был разработан весьма подробно и объем табулированных данных превышал минимально необходимое количество. Хотя и сам процесс табуляции был значительно ускорен. В это же время появились перфокарты, считывание которых выполнялось электрическим способом.

Возвращаясь к модели СММ, отметим, что на уровне 2 процесс разработки ПО можно представить в виде набора "черных ящиков" с определенными контрольными точками (стадиями). Как показано на рис. 2.1, требования включаются в состав процесса и плавно "перетекают" в набор из "черных ящиков".

Рис. 2.1. Процесс уровня 2

Для каждого ящика генерируются результаты вычислений, а стадии и контрольные точки применяются с целью мониторинга процесса разработки программного продукта. Затем следует стадия внедрения политик, стандартов и процедур. Количественная оценка этого опыта производится с помощью элементарной метрической системы, применяемой в данном проекте. Контроль производится посредством применения формальных практик, задействованных в процессе менеджмента проектов. Также отслеживаются затраты, графики и набор функциональных свойств. Основными субъектами процесса являются требования к ПО и рабочие продукты, а их целостность контролируется с помощью системы менеджмента конфигурации. Для проектов характерны тесные взаимосвязи со службой поддержки заказчиков. Также вырабатывается способность к осуществлению программных процессов.

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

Рис. 2.2. Процесс уровня 3

В рамках проектов происходит подгонка стандартных программных процессов организации для их конкретизации. Также интегрируются процессы менеджмента и программного инжиниринга. Возможности по выполнению стандартного процесса являются стандартными, а группа разработчиков несет ответственность за действия, выполняемые в программном проекте. Ниже перечислены области КРА для третьего уровня зрелости:

1) область действия организационного процесса;

2) определение организационного процесса;

3) инжиниринг программных продуктов;

4) комплексный менеджмент ПО;

5) взаимодействие между группами;

6) экспертные оценки;

7) учебная программа.

На уровне 3 процесс разработки ПО осуществляется на основе хорошо определенного процесса. Требуется осознание ролей и ответственности в ходе осуществления процесса. Процесс производства программного продукта отображается в ходе выполнения программного процесса.

Уровень 4 (рис. 2.3), т.е. "управляемый", включает две области КРА: количественный менеджмент процессов и управление качеством ПО.

Рис. 2.3. Процесс уровня 4

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

На уровне 5 ("оптимизация") области КРА сосредоточены на стадиях менеджмента изменений технологии, менеджмента изменений процесса и предотвращении дефектов. Благодаря непрерывному улучшению процесса осуществляется количественная обратная связь по отношению к процессу разработки программ. На этом уровне в организации могут апробироваться новые идеи и технологии, позволяющие улучшить качество программного продукта, что схематически изображено на рис. 2.4.

Рис. 2.4. Процесс уровня 5

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

1) процесс должен соответствовать культурным традициям организации;

2) менеджмент обязан способствовать повышению степени культуры;

3) культура должна способствовать внедрению ролевых моделей и наград.

Подводя итоги, можно отметить, что модель СММ является своего рода "дорожной картой", гарантирующей успешное улучшение процесса. Ее интерпретация и применение осуществляются в контексте бизнес-целей организации. В настоящее время в организациях, занимающихся разработкой ПО, в качестве наиболее распространенного метода выступает именно модель СММ (причем эта тенденция характерна для многих стран и великого множества областей применения). Эта модель является нормативной, не предписывающей, а также характеризуется большим запасом устойчивости. Ее разработка и поддержка осуществляется многими разработчиками, объединенными в сообщество профессионалов.

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

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

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

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

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

Рис. 1. Пять уровней зрелости в модели CMM

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

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

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

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

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

При сертификации проводится оценка соответствия всех ключевых областей по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям:

• Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т. д.).
• Насколько широко данная область применяется в организации (например, оценке 4 балла соответствует фрагментное применение).
• Успешность использования данной области на практике (например, оценке 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка 8 баллов выставляется при наличии систематического и измеримого положительного результата практически по всей организации).

В принципе, можно сертифицировать только один процесс или подразделение организации; например: подразделение разработки программного обеспечения компании IBM сертифицировано на пятый уровень. Кстати, в мире существует совсем немного компаний, которые могут похвастаться наличием у них пятого уровня CMM хотя бы на одном из подразделений,– таких всего 50. С другой стороны, насчитывается несколько тысяч компаний, сертифицированных по 3-му или 4-му уровню, то есть существует колоссальный разрыв между оптимизированным уровнем зрелости и предыдущими уровнями. Однако еще больший разрыв наблюдается между количеством организаций начального уровня и числом их более продвинутых собратьев – по некоторым оценкам, свыше 70% всех компаний-разработчиков находятся на первом уровне CMM.

Интересен вопрос о соотношении уровней CMM со стандартом ISO 9001: на каком уровне CMM должна находиться организация, чтобы получить сертификат соответствия ISO 9001? На первый взгляд, для этого необходимо иметь минимум 3-й или 4-й уровень CMM. Тем не менее, существуют примеры организаций 1-го уровня, имеющих сертификат ISO 9001. Одной из причин возникновения подобных несуразиц является высокий уровень абстракции ISO 9001 и связанная с этим свобода его интерпретации аудитором. Иногда, как это ни странно, аудиторам не хватает элементарного знакомства с реальной практикой разработки программ. Более подробный отчет о соотношении ISO 9001 и CMM приведен в статье.

Некоторые важные вопросы, например отбор, повышение квалификации и сохранение компетентных сотрудников, остались за рамками CMM. Тем не менее, эти вопросы исключительно важны, ибо, как замечено в статье, "…и 20-30 лет назад было известно, что два программиста, сидящих за соседними столами и получающих одинаковую зарплату, могут писать программы, отличающиеся по скорости счета, скажем, в 10 раз". Кстати, ситуация в России еще сложнее по сравнению с западными странами – российские программисты могут не только перейти на другую работу, но и переехать в другую страну с более высоким уровнем зарплаты!

Естественно, особенно важен подбор сотрудников для организаций первого уровня, так как сотрудники для них являются естественной гарантией качества. Но и на более высоких уровнях зрелости "человеческий фактор" сохраняет свою значимость. Поэтому в 1995 году был опубликован стандарт People CMM, являющийся дополнением к Software CMM и имеющий, в целом, похожую структуру. Внедрение этого стандарта параллельно с обычным CMM обеспечивает организацию целым набором процедур по оценке и развитию всей системы найма, обучения и сохранения квалифицированных сотрудников. В интересной, хотя и несколько эксцентричной форме идеи People CMM сформулированы одним из ее ведущих авторов в статье.

Кроме People CMM, возникло еще несколько моделей, дополняющих CMM, например, в приобретении ПО или разработке крупных систем. В целях полной интеграции этих моделей и снижении общих затрат по их внедрению был предпринят проект CMM Integration (ради его выполнения в 1998 году был даже отменен выпуск CMM версии 2.0).

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

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

История возникновения СММ такова. В конце 80-х гг. прошлого века Министерство обороны США заказало Институту программной инженерии 1англ. SEI - Software Engineering Institute Университета Карнеги-Меллон работу по созданию системы критериев для выбора субподрядчиков в проектах разработки программного обеспечения. Работа была закончена в 1991 г., и результатом ее стала модель CMM . Нужно сразу оговориться, что модель не содержит никаких финансово-экономических, политических, организационных критериев выбора субподрядчика, равно как и критериев возможности допуска к секретным работам (вероятно, такие задачи и не ставились). Речь идет только о критериях, описывающих способности потенциального субподрядчика в части разработки программных систем.

Структура CMM

За основу при оценке способности организации качественно выполнять работу, которая (способность) была названа зрелостью, создатели модели взяли процессы организации. Дальше они сделали несколько нетривиальных предположений, которые впоследствии были приняты и признаны справедливыми многими ИТ-специалистами (а может быть, и большинством из них).

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

Предположение 2 . Всякая организация-разработчик заинтересована в переходе на более высокий уровень зрелости (не только для того, чтобы повысить свои шансы в борьбе за контракты Министерства обороны, но и в целях собственного совершенствования).

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

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

Уровень 1 "Начальный" . Производственный процесс в целом характеризуется как создаваемый каждый раз под конкретный проект, а иногда даже как хаотический. Определены лишь некоторые процессы, и успех проекта зависит от усилий индивидуумов.

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

Уровень 3 "Определенный" . Производственный процесс документирован и стандартизован как для управленческих работ , так и для проектирования. Этот процесс интегрирован в стандартный производственный процесс организации. Во всех проектах используется утвержденная адаптированная версия стандартного производственного процесса организации.

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

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

Несмотря на нестрогость, приведенное определение интуитивно чаще всего не вызывает возражений. Более того, опытным специалистам понятно, почему переходы возможны только на соседний уровень, как понятно и то, почему вообще стоит стремиться к такому переходу. В то же время никакого количественного или хотя бы формального обоснования такого подхода модель СММ не содержит, что, впрочем, нисколько не умаляет ее достоинств.

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

Рис. 7.1.

На рис. 7.1 присутствуют следующие понятия.

Группа ключевых процессов . Как говорится в (Paulk, и др., 1995), "каждая группа ключевых процессов определяет блок связанных работ , в результате выполнения которых достигается совокупность целей, значимых для повышения продуктивности производственного процесса. Например, для группы ключевых процессов " Управление требованиями " (см. рис. 7.2) цель состоит в том, чтобы согласовать требования, выдвигаемые к проекту разработки ПО заказчиком и разработчиком".

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

Рис. 7.2.

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

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

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

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

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

Обязательства по выполнению

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

Необходимые предпосылки

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

Выполняемые операции

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

Измерения и анализ

Раздел "Измерения и

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

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

Ключевые практики описывают, ЧТО необходимо сделать, но их не следует воспринимать в виде догм, устанавливающих, КАК нужно достигать целей. Цели группы ключевых процессов можно реализовать с помощью альтернативных практик. Интерпретация ключевых практик должна быть разумной, допускающей достижение целей группы ключевых процессов эффективным способом, хотя, возможно, формально и отличающимся от рекомендованного CMM .

Взгляд на деятельность по управлению ИТ, при котором вместо процессов рассматриваются их составляющие - ключевые практики, а процессы присутствуют только виртуально, как что-то, что может быть построено из ключевых практик, выглядит на первый взгляд несколько экзотично. До сих пор задача совершенствования управления ИТ решалась внедрением готовых процессов из эталонной процессной модели. Теперь же возникает множество уровней, содержащих разрозненные (т. е. не объединенные в процессы) ключевые практики, и рекомендуемая последовательность продвижения по уровням. Управление ИТ, согласно CMM , совершенствуется по мере продвижения на более высокий уровень зрелости. Что же происходит при таком продвижении?

В определениях уровней (см. рис. 7.2) появилось такое понятие, как "производственный процесс". Оно же присутствует и в определении группы ключевых процессов, и это не случайное совпадение. Производственный процесс, или, как он точно называется в СММ, Стандартный Производственный Процесс Организации (СППО), - одно из центральных понятий всей модели.