Практическое использование CMM. Проект SPICE

В процесс входят следующие основные практики (название практики выделено шрифтом).

CUS.1.1. Выявить потребность. Выявить потребность в приобретении, разработке или модернизации программного продукта.

CUS.1.2. Определить требования. Подготовить системные и программные требования для удовлетворения потребности в новом продукте/услуге.

CUS.1.3. Разработать стратегию приобретения. Разработать стратегию приобретения продукта, включающую:

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

CUS.1.4. Подготовить запрос на предложение. Подготовить тендер, включая разработку требований к поставке и плана-графика проекта.

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

Развитость этого процесса зависит от того, какие общие практики выполняются для его основных практик. Пусть, например, про процесс можно сказать только, что его основные практики как-то выполняются. Это означает, что способность организации выполнять этот процесс описывается только характеристикой "1.1. Выполняющиеся основные практики", включающей единственную общую практику "1.1.1. Выполнить процесс". Значит, процесс находится на уровне 1.

Немногим сложнее обстоит дело с выяснением того, находится ли процесс на уровне 2. Четыре характеристики второго уровня ( "2.1. Планируемая производительность", "2.2. Управляемая производительность", "2.3. Верифицируемая производительность" и "2.4. Отслеживаемая производительность" ), в свою очередь, состоят из (общих) практик. Так, например, характеристика 2.3. "Верифицируемая производительность" включает две общие практики:

2.3.1. Верифицировать соответствие. Верифицировать соответствие процесса применимым стандартам и/или процедурам;

2.3.2. Выполнить аудит результатов. Верифицировать соответствие промежуточных и окончательных результатов применимым стандартам и/или процедурам.

Необходимое условие того, что процесс находится на уровне 2, состоит в том, что он полностью соответствует применимым стандартам (реализована общая практика 2.3.1) и для всех результатов всех его основных практик выполняется аудит (реализована общая практика 2.3.2). Аналогично рассматриваются и остальные характеристики уровня 2; если все практики во всех характеристиках реализованы, то процесс достиг второго уровня развитости.

Осталось добавить, что стандарт SPICE содержит еще и связи между общими практиками и процессами. Например, выполнение общей практики 2.3.2 подразумевает выполнение связанных с ней процессов CUS.3 " Выявить потребности потребителя^{11англ. Identify Customer Needs} ", PRO.4 " Управлять требованиями^{12англ. Manage Requirements} ", PRO.5 " Управлять качеством^{13англ. Manage Quality} " и SUP.3 " Выполнять аудит результатов^{14англ. Audit work products} ". Это не жесткое требование, а скорее рекомендация. В противном случае авторы столкнулись бы с проблемой зависимости общих практик от процессов, и модель бы резко усложнилась.

Кажущаяся простота модели, однако, исчезает при попытке применить ее на практике. Продолжим наш пример. Во-первых, что делать, если не все результаты процесса верифицируются, т. е. общая практика 2.3.2 реализована не полностью? Пусть, например, стратегия приобретения (промежуточный результат, порождаемый основной практикой CUS.1.3) верифицируется (проверяется на соответствие определенным корпоративным стандартам), а потребность (CUS.1.1) - нет (например, такого корпоративного документа не существует). Будет ли в этом случае процесс относиться к уровню 2? Можно придумать и более сложные случаи, когда некоторые основные практики будут удовлетворять требованиям более чем двух уровней, и вопрос правильного позиционирования процесса станет еще более запутанным.

Во-вторых, в реальной организации сами процессы могут отличаться от предлагаемых SPICE, т. е. основные практики могут отличаться от стандартных. Как поступать в этом случае?

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

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

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

Улучшение процессов

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

увеличить изображение
Рис. 8.2. Шаги улучшения процессов

Принципиально новая идея Отчета SPICE по сравнению с CMM состоит в том, чтобы связать улучшение процессов организации с ее бизнес-целями. Вот что говорится в Отчете:

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

Я проиллюстрирую эту идею простым примером.

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

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

1. обеспечить переход со второго на третий уровень развитости для процессов, выполняемых при использовании технологии B;
2. обеспечить достижение второго уровня развитости для процессов, выполняемых при использовании технологии А;
3. начать работы по внедрению процессов управления качеством для процессов, соответствующих технологии В.

Работы должны выполняться в порядке нумерации; при этом работа 2 может выполняться параллельно с работой 1. Работа 3 может начаться только по окончании работы 1. Решение о том, будет ли работа 2 выполняться параллельно с работой 1, зависит от того, насколько это задержит (в силу ограниченности ресурсов) работу 1.

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

В Отчете SPICE задача выбора процессов для улучшения, как видно из рис. 8.2 (подробное описание приведено в Части 7), решается следующим образом. Сначала выполняется анализ потребностей и бизнес-целей (активность 1) и делается полная оценка развитости процессов организации (активность 2). По итогам оценки готовится предварительный план улучшения процессов, включающий все улучшения, которые могли бы способствовать достижению бизнес-целей. Затем результаты оценки анализируются (активность 4) и вырабатывается реальный план улучшения процессов. При создании плана могут использоваться целевые профили развитости процессов.

Целевые профили развитости тесно связаны с так называемым определением развитости процессов (Process Capability Determination, PCD). Это деятельность по систематической оценке и анализу избранных процессов организации. Анализ выполняется с целью выявить выгоды и затраты, связанные с улучшением этих процессов до нужного уровня, и оценить сопутствующие риски. Он направлен на достижение специфических целей, например, получение объективной оценки потенциального поставщика или, наоборот, оценку собственных рисков участия в тендере на поставку. Возможны и другие цели, например, поставщик может выполнять определение развитости процессов (своих и клиента) в ходе проекта для оценки проектных рисков. Целевой профиль развитости - это тот уровень развитости процесса, который спонсор задачи определения развитости считает приемлемым и наименее рискованным для достижения поставленной специфической цели. Подробнее об определении развитости см. Часть 8 Отчета.

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

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

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

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

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

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

Вопросы

1. В чем состояла цель проекта SPICE?
2. Какова структура Отчета SPICE?
3. Какова структура процессной модели SPICE? Как модель SPICE связана с моделями, представленными в стандартах ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р ИСО/МЭК 15288?
4. Что такое основные и общие практики? Для чего нужны характеристики?
5. Чем основные и общие практики отличаются от ключевых практик CMM?
6. В чем принципиальные отличия модели управления процессами SPICE от модели зрелости CMM?
7. Какие трудности возникают при практической оценке развитости процессов?
8. Как в Отчете SPICE выглядит схема улучшения процессов?