Основы управления информационными технологиями

Зрелость проектных организаций. Методология CMM

Разбить на страницы
Показывать лекцию целиком

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

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

Структура CMM

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

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

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

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

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

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

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

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

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

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

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

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

(рис 7.1) Структура модели СММ

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

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

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

(рис 7.2) Распределение групп ключевых процессов по уровням зрелости

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка внедрения

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

Ключевые практики. Составляющие разделов, которые выше описывались словами "действия", "работы", "условия, которые должны выполняться", "шаги", "операции" и т. д., имеют в СММ общее название - "ключевая практика". Вот цитата из (Paulk, и др., 1995):

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

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

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

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

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

Стандартный производственный процесс организации. Начну опять с цитаты из СММ.

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

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

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

Как видно из этого текста, "лесенка уровней" на самом деле имеет следующий смысл.

На первом уровне организация еще не научилась выполнять проекты с предсказуемым результатом. На втором уровне организация выполняет отдельные проекты, но по-разному, в зависимости от специфики проекта. Качественный скачок происходит на третьем уровне, когда организация создает универсальный производственный процесс, единый для всех проектов и характеризующий не отдельные проектные команды, а организацию в целом.

Для этого на третьем уровне вводятся группы ключевых процессов "Определение производственного процесса организации" и "Координация производственного процесса организации". Вот что говорит СММ о первой из них.

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

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

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

Вот как выглядят в CMM цели этой группы ключевых процессов:

"Цель 1. Разработка и сопровождение стандартного производственного процесса организации.

Цель 2. Сбор, изучение и распространение информации, связанной с использованием СППО в проектах разработки ПО".

Вторая группа ключевых процессов описывается так.

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

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

У этой группы ключевых процессов три цели:

"Цель 1. Координация мероприятий по разработке и усовершенствованию производственного процесса в рамках всей организации.

Цель 2. Выявление преимуществ и недостатков используемых производственных процессов в сравнении со стандартным процессом.

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

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

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

СППО наряду с качеством продукта становится основным объектом интереса на четвертом уровне. Группы ключевых процессов на этом уровне называются "Количественное управление процессом" (имеется в виду СППО) и "Управление качеством ПО". Цели первой группы:

"Цель 1. Планирование работ по количественному управлению процессом.

Цель 2. Установление количественного контроля над выполнением производственного процесса проекта.

Цель 3. Количественное выражение продуктивности стандартного производственного процесса организации".

Цели второй группы:

"Цель 1. Планирование работ по управлению качеством ПО.

Цель 2. Определение желаемых количественных показателей качества программного продукта и их приоритетов.

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

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

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

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

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

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

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

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

Этим, однако, СММ не ограничивается. Вот что сказано в (Paulk, и др., 1995):

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

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

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

Очевидно, в том виде, в котором СММ представлена в доступных широкой аудитории материалах, она не дает исчерпывающих ответов на целый ряд практических вопросов. Например, как оценивать уровень организации, если часть практик, относящихся к этому уровню, присутствует, а часть - нет? Что вообще однозначно свидетельствует о наличии практики: документ, устное заявление исполнителя, материализованный проектный опыт или что-то еще? Ответы на такие вопросы в конечном итоге определяют объем и сложность работ, а значит, и цену услуги. Без точного и однозначного понимания состава и сложности работ исполнителем и заказчиком контракт просто невозможен. Это означает, что дополнительное обучение СММ, а может быть, и доработка модели, действительно необходимы.

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

CMM и модели процессов

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

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

Таким образом, внедрение модели процессов, предлагаемой IEEE 1074, будет разумным решением в направлении улучшения процессов управления ИТ для организаций, находящихся на первом уровне зрелости.

Для того чтобы улучшить процессы управления ИТ организации, находящейся на втором уровне зрелости, необходимо, согласно CMM, реализовать семь групп ключевых процессов, соответствующих третьему уровню зрелости:

  • координация производственного процесса организации;
  • определение производственного процесса организации;
  • программа обучения;
  • интегрированное управление разработкой ПО;
  • инженерия разработки программного продукта;
  • межгрупповая координация;
  • экспертные оценки.
    •

    Идея состоит в том, что роль стандартного производственного процесса организации при определенных допущениях может играть совокупность процессов, описанная в ГОСТ Р ИСО/МЭК 12207. Рассмотрим группы ключевых процессов по порядку.

    Координация производственного процесса организации

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

    Очевидно, деятельность по внедрению ГОСТ Р ИСО/МЭК 12207 подразумевает достижение всех перечисленных целей. Остальные ключевые практики реализуются в ходе внедрения.

    Определение производственного процесса организации

    Эта группа ключевых процессов фактически определяет, в каком объеме внедряется ГОСТ Р ИСО/МЭК 12207. Для реализации этой группы процессов можно воспользоваться ГОСТ Р ИСО/МЭК 15271.

    Программа обучения

    Реализуется в процессе обучения в ГОСТ Р ИСО/МЭК 12207.

    Интегрированное управление разработкой ПО

    Точно соответствует процессу адаптации в ГОСТ Р ИСО/МЭК 12207.

    Инженерия разработки программного продукта

    Соответствие выполняемых операций группы "Инженерия разработки программного продукта" и процессов/работ ГОСТ Р ИСО/МЭК 12207 показано в таблице 7.1.

    Соответствие СППО CMM и ГОСТ Р ИСО/МЭК 12207
    Операция раздела "Выполняемые операции" Процесс / работа процесса согласно ГОСТ Р ИСО/МЭК 12207
    Интеграция соответствующих методов и средств разработки ПО в производственный процесс проекта Процесс адаптации
    Разработка, сопровождение, документирование и проверка требований к ПО путем проведения систематического анализа установленных требований в соответствии с производственным процессом проекта Работа 5.3.2 процесса разработки, процесс адаптации
    Разработка, поддержка, документирование и проверка архитектуры ПО выполняются в соответствии с производственным процессом проекта и требованиями к ПО в целях формирования основы для создания кода Работы 5.3.4, 5.3.4, 5.3.5 и 5.3.6 процесса разработки, процесс адаптации
    Разработка, поддержка, документирование и проверка программного кода, выполняемые в соответствии с производственным процессом проекта в целях реализации требований к ПО и архитектуры ПО Работа 5.3.7 процесса разработки, процесс адаптации
    Тестирование ПО выполняется в соответствии с производственным процессом проекта Работа 5.3.7 процесса разработки, процесс адаптации
    Планирование и выполнение интеграционного тестирования ПО проводится в соответствии с производственным процессом проекта Работы 5.3.7 и 5.3.8 процесса разработки, процесс адаптации
    Планирование и выполнение системного и приемочного тестирования ПО в целях демонстрации его соответствия требованиям Работы 5.3.7, 5.3.8, 5.3.9, 5.3.10, 5.3.11, 5.3.12 и 5.3.13 процесса разработки, процесс адаптации
    Документация, используемая при эксплуатации и поддержке ПО, разрабатывается и ведется в соответствии с производственным процессом проекта Работы 5.4.1, 5.4.2, 5.4.3 и 5.4.4 процесса разработки, процесс адаптации
    Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта Работы 5.5.1, 5.5.2, 5.5.3 процесса разработки, процесс адаптации
    Поддержка согласованности всех промежуточных программных продуктов, включая планы разработки ПО, описания процессов, установленные требования, требования к ПО, архитектуру ПО, планы и процедуры тестирования Процесс разработки, процесс управления, процесс адаптации

    Межгрупповая координация

    В CMM приведен пример перечня групп участников проекта, между которыми в ходе выполнения проекта должна существовать межгрупповая координация:

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

    В ГОСТ Р ИСО/МЭК 12207 координация таких групп обеспечивается за счет точно определенного взаимодействия соответствующих процессов или участников одного процесса (в случае групп разработки, системного тестирования, оценки составляющих проекта).

    Экспертные оценки

    Полностью реализована в процессах верификации, аттестации, совместного анализа, аудита и решения проблем ГОСТ Р ИСО/МЭК 12207.

    Конечно, приведенные рассуждения нельзя считать строгими или полностью доказательными. Они предназначены только для иллюстрации того, как на практике можно подойти к выбору адекватной модели процессов для организации. Тем не менее они показывают, что внедрение скоординированной совокупности стандартов ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 15271 и какого-либо стандарта управления проектами во всяком случае помогает достичь третьего уровня зрелости организации.

    Как вариант, можно попытаться использовать для этого один стандарт - ГОСТ Р ИСО/МЭК 15288, включающий процессы управления проектами ("Процессы проекта" в терминологии этого стандарта).

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

    Краткие итоги

    В лекции рассмотрена одна из наиболее популярных методик оценки процессов - модель зрелости CMM. Подробно обсуждаются логика и структура CMM. Особое внимание уделяется вопросу применения CMM совместно с рассмотренными ранее эталонными моделями процессов, представленными стандартами IEEE 1074 и ГОСТ Р ИСО/МЭК 12207.

    Вопросы

  • В чем состоит назначение CMM?
  • Как выглядят уровни зрелости CMM? В чем их смысл?
  • Что такое СППО?
  • Чем подход к улучшению процессов, предлагаемый CMM, отличается от подхода, базирующегося на внедрении процессных стандартов (например, ГОСТ Р ИСО/МЭК 12207)?
  • Какова связь между СППО CMM и процессной моделью ГОСТ Р ИСО/МЭК 12207?
  • Как можно использовать стандарт IEEE 1074 для повышения уровня зрелости организации? Как можно использовать для этого другие ранее рассмотренные стандарты?
    •
    Страницы:

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

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

    Структура CMM

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

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

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

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

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

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

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

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

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

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

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

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

    (рис 7.1) Структура модели СММ

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

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

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

    (рис 7.2) Распределение групп ключевых процессов по уровням зрелости

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

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

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

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

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

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

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

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

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

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

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

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

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

    Проверка внедрения

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

    Ключевые практики. Составляющие разделов, которые выше описывались словами "действия", "работы", "условия, которые должны выполняться", "шаги", "операции" и т. д., имеют в СММ общее название - "ключевая практика". Вот цитата из (Paulk, и др., 1995):

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

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

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

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

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

    Стандартный производственный процесс организации. Начну опять с цитаты из СММ.

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

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

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

    Как видно из этого текста, "лесенка уровней" на самом деле имеет следующий смысл.

    На первом уровне организация еще не научилась выполнять проекты с предсказуемым результатом. На втором уровне организация выполняет отдельные проекты, но по-разному, в зависимости от специфики проекта. Качественный скачок происходит на третьем уровне, когда организация создает универсальный производственный процесс, единый для всех проектов и характеризующий не отдельные проектные команды, а организацию в целом.

    Для этого на третьем уровне вводятся группы ключевых процессов "Определение производственного процесса организации" и "Координация производственного процесса организации". Вот что говорит СММ о первой из них.

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

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

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

    Вот как выглядят в CMM цели этой группы ключевых процессов:

    "Цель 1. Разработка и сопровождение стандартного производственного процесса организации.

    Цель 2. Сбор, изучение и распространение информации, связанной с использованием СППО в проектах разработки ПО".

    Вторая группа ключевых процессов описывается так.

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

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

    У этой группы ключевых процессов три цели:

    "Цель 1. Координация мероприятий по разработке и усовершенствованию производственного процесса в рамках всей организации.

    Цель 2. Выявление преимуществ и недостатков используемых производственных процессов в сравнении со стандартным процессом.

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

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

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

    СППО наряду с качеством продукта становится основным объектом интереса на четвертом уровне. Группы ключевых процессов на этом уровне называются "Количественное управление процессом" (имеется в виду СППО) и "Управление качеством ПО". Цели первой группы:

    "Цель 1. Планирование работ по количественному управлению процессом.

    Цель 2. Установление количественного контроля над выполнением производственного процесса проекта.

    Цель 3. Количественное выражение продуктивности стандартного производственного процесса организации".

    Цели второй группы:

    "Цель 1. Планирование работ по управлению качеством ПО.

    Цель 2. Определение желаемых количественных показателей качества программного продукта и их приоритетов.

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

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

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

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

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

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

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

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

    Этим, однако, СММ не ограничивается. Вот что сказано в (Paulk, и др., 1995):

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

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

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

    Очевидно, в том виде, в котором СММ представлена в доступных широкой аудитории материалах, она не дает исчерпывающих ответов на целый ряд практических вопросов. Например, как оценивать уровень организации, если часть практик, относящихся к этому уровню, присутствует, а часть - нет? Что вообще однозначно свидетельствует о наличии практики: документ, устное заявление исполнителя, материализованный проектный опыт или что-то еще? Ответы на такие вопросы в конечном итоге определяют объем и сложность работ, а значит, и цену услуги. Без точного и однозначного понимания состава и сложности работ исполнителем и заказчиком контракт просто невозможен. Это означает, что дополнительное обучение СММ, а может быть, и доработка модели, действительно необходимы.

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

    CMM и модели процессов

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

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

    Таким образом, внедрение модели процессов, предлагаемой IEEE 1074, будет разумным решением в направлении улучшения процессов управления ИТ для организаций, находящихся на первом уровне зрелости.

    Для того чтобы улучшить процессы управления ИТ организации, находящейся на втором уровне зрелости, необходимо, согласно CMM, реализовать семь групп ключевых процессов, соответствующих третьему уровню зрелости:

  • координация производственного процесса организации;
  • определение производственного процесса организации;
  • программа обучения;
  • интегрированное управление разработкой ПО;
  • инженерия разработки программного продукта;
  • межгрупповая координация;
  • экспертные оценки.
    •

    Идея состоит в том, что роль стандартного производственного процесса организации при определенных допущениях может играть совокупность процессов, описанная в ГОСТ Р ИСО/МЭК 12207. Рассмотрим группы ключевых процессов по порядку.

    Координация производственного процесса организации

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

    Очевидно, деятельность по внедрению ГОСТ Р ИСО/МЭК 12207 подразумевает достижение всех перечисленных целей. Остальные ключевые практики реализуются в ходе внедрения.

    Определение производственного процесса организации

    Эта группа ключевых процессов фактически определяет, в каком объеме внедряется ГОСТ Р ИСО/МЭК 12207. Для реализации этой группы процессов можно воспользоваться ГОСТ Р ИСО/МЭК 15271.

    Программа обучения

    Реализуется в процессе обучения в ГОСТ Р ИСО/МЭК 12207.

    Интегрированное управление разработкой ПО

    Точно соответствует процессу адаптации в ГОСТ Р ИСО/МЭК 12207.

    Инженерия разработки программного продукта

    Соответствие выполняемых операций группы "Инженерия разработки программного продукта" и процессов/работ ГОСТ Р ИСО/МЭК 12207 показано в таблице 7.1.

    Соответствие СППО CMM и ГОСТ Р ИСО/МЭК 12207
    Операция раздела "Выполняемые операции" Процесс / работа процесса согласно ГОСТ Р ИСО/МЭК 12207
    Интеграция соответствующих методов и средств разработки ПО в производственный процесс проекта Процесс адаптации
    Разработка, сопровождение, документирование и проверка требований к ПО путем проведения систематического анализа установленных требований в соответствии с производственным процессом проекта Работа 5.3.2 процесса разработки, процесс адаптации
    Разработка, поддержка, документирование и проверка архитектуры ПО выполняются в соответствии с производственным процессом проекта и требованиями к ПО в целях формирования основы для создания кода Работы 5.3.4, 5.3.4, 5.3.5 и 5.3.6 процесса разработки, процесс адаптации
    Разработка, поддержка, документирование и проверка программного кода, выполняемые в соответствии с производственным процессом проекта в целях реализации требований к ПО и архитектуры ПО Работа 5.3.7 процесса разработки, процесс адаптации
    Тестирование ПО выполняется в соответствии с производственным процессом проекта Работа 5.3.7 процесса разработки, процесс адаптации
    Планирование и выполнение интеграционного тестирования ПО проводится в соответствии с производственным процессом проекта Работы 5.3.7 и 5.3.8 процесса разработки, процесс адаптации
    Планирование и выполнение системного и приемочного тестирования ПО в целях демонстрации его соответствия требованиям Работы 5.3.7, 5.3.8, 5.3.9, 5.3.10, 5.3.11, 5.3.12 и 5.3.13 процесса разработки, процесс адаптации
    Документация, используемая при эксплуатации и поддержке ПО, разрабатывается и ведется в соответствии с производственным процессом проекта Работы 5.4.1, 5.4.2, 5.4.3 и 5.4.4 процесса разработки, процесс адаптации
    Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта Работы 5.5.1, 5.5.2, 5.5.3 процесса разработки, процесс адаптации
    Поддержка согласованности всех промежуточных программных продуктов, включая планы разработки ПО, описания процессов, установленные требования, требования к ПО, архитектуру ПО, планы и процедуры тестирования Процесс разработки, процесс управления, процесс адаптации

    Межгрупповая координация

    В CMM приведен пример перечня групп участников проекта, между которыми в ходе выполнения проекта должна существовать межгрупповая координация:

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

    В ГОСТ Р ИСО/МЭК 12207 координация таких групп обеспечивается за счет точно определенного взаимодействия соответствующих процессов или участников одного процесса (в случае групп разработки, системного тестирования, оценки составляющих проекта).

    Экспертные оценки

    Полностью реализована в процессах верификации, аттестации, совместного анализа, аудита и решения проблем ГОСТ Р ИСО/МЭК 12207.

    Конечно, приведенные рассуждения нельзя считать строгими или полностью доказательными. Они предназначены только для иллюстрации того, как на практике можно подойти к выбору адекватной модели процессов для организации. Тем не менее они показывают, что внедрение скоординированной совокупности стандартов ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 15271 и какого-либо стандарта управления проектами во всяком случае помогает достичь третьего уровня зрелости организации.

    Как вариант, можно попытаться использовать для этого один стандарт - ГОСТ Р ИСО/МЭК 15288, включающий процессы управления проектами ("Процессы проекта" в терминологии этого стандарта).

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

    Краткие итоги

    В лекции рассмотрена одна из наиболее популярных методик оценки процессов - модель зрелости CMM. Подробно обсуждаются логика и структура CMM. Особое внимание уделяется вопросу применения CMM совместно с рассмотренными ранее эталонными моделями процессов, представленными стандартами IEEE 1074 и ГОСТ Р ИСО/МЭК 12207.

    Вопросы

  • В чем состоит назначение CMM?
  • Как выглядят уровни зрелости CMM? В чем их смысл?
  • Что такое СППО?
  • Чем подход к улучшению процессов, предлагаемый CMM, отличается от подхода, базирующегося на внедрении процессных стандартов (например, ГОСТ Р ИСО/МЭК 12207)?
  • Какова связь между СППО CMM и процессной моделью ГОСТ Р ИСО/МЭК 12207?
  • Как можно использовать стандарт IEEE 1074 для повышения уровня зрелости организации? Как можно использовать для этого другие ранее рассмотренные стандарты?
    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^