Оценка процессов
Отсутствие в доступных публикациях по CMM явно определенных методик применения модели и нежелание SEI способствовать открытому распространению таких методик вызвали к жизни инициативу по разработке практических рекомендаций по использованию модели CMM для оценки проектных организаций, связанных с разработкой ПО, и их процессов.
В 1993 г. с одобрения ISO была создана международная Проектная Организация SPICEангл. Software Process Improvement and Capability dEtermination
(SPICE), которая к 1995 г. подготовила девять документов под общим названием "Оценка процессов, связанных с программным обеспечением" (Software Process Assessment), где рассматриваются все задачи, возникающие при проведении оценки, от построения рейтингов процессов до обучения участников проекта. Эти документы, имевшие статус проекта стандарта ISO, впоследствии действительно составили стандарт ISO/IEC TR 15504 - CMM "Information Technology. Process Assessment". В 2001 г. был опубликован русский перевод стандарта фирмы Ай-Ти (Ай-Ти, 2001), а в 2009 г. подготовлен аутентичный перевод, получивший статус стандарта ГОСТ Р ИСО/МЭК 15504 "Информационные технологии. Оценка процессов" (вводится в действие с 2010 г.). С появлением стандарта ISO название "SPICE" перешло к организации пользователей разработки группы SPICE, которая продолжает существовать и с 2000 г. проводит ежегодные пользовательские конференции.
Я использую в дальнейшем оригинальные материалы SPICE и свой собственный перевод их на русский, чтобы избежать проблем с согласованием русскоязычной терминологии стандарта ГОСТ Р ИСО/МЭК 15504 и терминологии этой книги. Надеюсь, что заинтересованным читателям не составит труда установить соответствие между терминами в разных переводах.
Авторы документов SPICE не применяют термина "аудит процессов", используя вместо него "оценку" (assessment), что затрудняет перевод на русский язык слова assessor. Я буду пользоваться терминами "оценка" и "аудитор". Дальнейшее изложение опирается на документ (SPICE, 1995), который я для краткости буду называть Отчетом SPICE.
(рис 8.1) Взаимосвязи частей Отчета SPICEНа рис 8.1 показана структура Отчета (за исключением вводной части 1 и словаря, содержащегося в части 9). Вот краткие характеристики частей.
Вводная часть. Описывает контекст деятельности по оценке и улучшению процессов и вводит пять категорий процессов.
Модель управления процессами. Определяет шесть уровней развитости процесса. Включает описания всех общих практик для всех уровней развитости и всех основных практик для всех процессов из процессных областей. Модель управления процессами принципиально отличается от модели CMM, хотя и имеет с ней общие черты (см. ниже).
Оценка процессов. Содержит практические указания по построению профиля (см. ниже) конкретного процесса.
Руководство по оценке. Содержит указания по организации проекта оценки, определяет восемь основных этапов проекта, методику выбора экземпляра процесса для оценки, определяет принципы командной работы в проекте. Изложение иллюстрируется примерами.
Построение, выбор и использование инструментов оценки. Самая объемная часть стандарта. Содержит практические советы, шаблоны, таблицы и т. п. инструменты для аудитора. Каждый инструмент предназначен для решения совершенно определенной задачи. Например, таблица "Индикаторы управления процессами" дает формальный механизм оценки того, реализованы ли общие практики на определенном уровне. Таблица структурирована по всем уровням и всем общим практикам.
Квалификация и обучение аудиторов. Даны описания ролей аудиторов в проекте, представлены профессиональные требования к аудитору, изложены методы оценки квалификации аудиторов.
Руководство по использованию оценки с целью улучшения процессов. Содержит рекомендации по инициализации процесса оценки и использованию его результатов в связи с улучшением процессов. Обсуждаются задачи согласования улучшений с бизнес-целями организации, культурные и коммуникационные аспекты улучшения процессов.
Руководство по использованию при определении развитости процессов поставщика. Содержит соображения по выполнению потребителем оценки процессов потенциального поставщика и вытекающих отсюда рисков. Может использоваться самим поставщиком для оценки того, удовлетворяет ли он требованиям потребителя.
Словарь.
Из всех перечисленных частей Отчета первостепенную важность для целей настоящей книги имеют Часть 1 (Введение), Часть 2 (Основные практики), а также отчасти Часть 7 (Улучшение процессов) и Часть 8 (Руководство). На них базируется дальнейшее изложение. Более специальные Части 3-6 не рассматриваются.
Модель процессов в Отчете SPICE
Во введении определяются пять категорий процессов, о которых дальше идет речь в Отчете (см. таблицу 8.1). Документ ориентирован на разработку ПО в проектной организации, т. е. сфера его применения та же, что и у CMM.
Пять категорий процессов
| Категория процесса |
Краткое описание |
|---|
| Потребитель-поставщикангл. Customer-Supplier
|
Процессы, непосредственно затрагивающие потребителя |
| Разработкаангл. Engineering
|
Процессы, устанавливающие требования к системе и программному продукту, процессы реализации и сопровождения |
| Управление проектамиангл. Project
|
Процессы запуска проекта и управления его ресурсами |
| Поддержкаангл. Support
|
Процессы, которые обеспечивают и повышают производительность остальных процессов проекта |
| Организационные процессыангл. Organization
|
Процессы, определяющие бизнес-цели организации и развивающие продукты, ресурсы и процессы, позволяющие достичь бизнес-целей |
Формальная структура модели процессов следующая. Процессы состоят из основных практик. Основные практики процесса обеспечивают достижение его цели и генерируют результаты процесса (в Отчете используется термин work products, который обозначает и промежуточные, рабочие результаты). Выполнение процесса - это и есть выполнение его основных практик. Кроме того, имеются общие практики, характеризующие не процесс, а организацию. Общие практики отражают управленческие действия, направленные на реализацию процесса или на управление процессом. Общие практики в равной степени применимы ко всем процессам.
Общие практики объединяются в характеристикиангл. Common Features
. Содержательно объединение ничего нового не дает, а только группирует практики, близкие по целям управления.
Наконец, определяется шесть уровней развитости процессов. Каждый уровень полностью определяется своим набором характеристик. Характеристики нумеруются так: "номер уровня, номер характеристики на уровне". Ниже приведена таблица, показывающая соответствие уровней и характеристик.
| Уровень |
Описание |
Характеристики |
|---|
| 0 |
Невыполняемый. На этом уровне основные практики процесса не выполняются. Отсутствуют промежуточные результаты и выходы процесса |
нет |
| 1 |
Выполняемый неформально. Основные практики процесса большей частью выполняются. Эффективность выполнения не планируется и не анализируется и зависит от персональных усилий. У исполнителей процесса есть общее понимание того, что, когда и как нужно делать. Имеются результаты процесса |
1.1. Выполняющиеся основные практики (Performing Base Practices) |
| 2 |
Планируемый и отслеживаемый. Выполнение основных практик процесса планируется и отслеживается. Производительность верифицируется в соответствии с определенными процедурами. Результаты удовлетворяют стандартам и требованиям |
2.1. Планируемая производительность (Planning Performance) |
| 2.2. Управляемая производительность (Disciplined Performance) |
| 2.3. Верифицируемая производительность (Verifying Performance) |
| 2.4. Отслеживаемая производительность (Tracking Performance) |
| 3 |
Вполне определенный. Основные практики выполняются в соответствии с вполне определенным процессом, который представляет собой формально утвержденную адаптированную версию стандартного документированного процесса |
3.1. Определенный стандартный процесс (Defining a Standard Process) |
| 3.2. Выполняемый определенный процесс (Performing the Defined Process) |
| 4 |
Управляемый количественно. Выполняются подробные измерения производительности и результаты анализируются. Это приводит к количественному пониманию развитости процесса и возможности прогнозирования производительности. Производительность управляется объективно. Качество результатов процесса выражается количественно |
4.1. Измеримые цели для качества (Establishing Measurable Quality Goals) |
| 4.2. Объективно управляемая производительность (Objectively Managing Performance) |
| 5 |
Непрерывно совершенствуемый. На основе бизнес-целей организации устанавливаются количественные целевые значения эффективности и результативности процесса. Непрерывное улучшение процесса с точки зрения бизнес-целей происходит благодаря количественной обратной связи и внедряемым новым идеям и технологиям |
5.1. Улучшающиеся способности организации (Improving Organizational Capability) |
| 5.2. Улучшающаяся результативность процесса (Improving Process Effectiveness) |
Как видно, описания уровней очень похожи на описания уровней в CMM. Но структуры моделей и уровней зрелости в CMM и Отчете SPICE принципиально разные.
Напомню, что в основу CMM была положена точка зрения, согласно которой уровень зрелости организации характеризуется группой ключевых процессов, причем на каждом уровне зрелости эта группа своя. В ходе развития организации и перехода ее на более высокие уровни зрелости ключевые практики, составляющие группу, и сами группы изменяются. Группы ключевых процессов, соответствующие каждому уровню, были детально описаны. Часть ключевых практик группы определяла собственно выполняемые процессы, а остальные ключевые практики описывали, насколько эти процессы внедрены в практику организации. Для того чтобы подчеркнуть это различие, ключевые практики на каждом уровне группировались в одинаковые разделы с "говорящими" названиями, по которым можно было судить о назначении входящих в раздел практик.
Что же вместо этого предлагает SPICE?
Во-первых, множество процессов организации полностью определено и не меняется в связи с развитием организации. В качестве такого множества взята модель процессов, близкая к той, которую предлагает стандарт ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207), но расширенная процессами управления проектами (таблица соответствий приведена в Приложении E к части 2 Отчета). В стандарте ISO/IEC 15504 (Ай-Ти, 2001) собственная модель процессов была отчасти перегруппирована и расширена по сравнению с эталонной моделью ГОСТ Р ИСО/МЭК 12207 за счет добавления процессов административного управления рисками, административного управления качеством, процесса организационных установок и некоторых других. Позже стандарт был сделан независимым от конкретной модели процессов и просто ссылался на эталонные модели ISO/IEC 12207 и ISO/IEC 15288.
Вместо зрелостиангл. maturity
производственного процесса организации в целом вводится понятие развитостиангл. capability
каждого процесса в отдельности. Разные процессы могут иметь разные уровни развитости; понятие зрелости организации отсутствует. Для того чтобы не придумывать для каждого процесса свои критерии развитости, была определена шкала из шести независимых от процессов уровней, которые характеризуют не процессы, а организацию в целом. Фактически уровни определяют способности организации по управлению процессами.
Довольно искусственное построение CMM, где ключевые практики входили не в процессы, а в разделы, и на каждом уровне содержание разделов было уникально (сохранялись только их названия) заменено в модели SPICE гораздо более простым. Теперь основные практики составляют собственно процессы, а общие - описания уровней. То, что общие практики сгруппированы в характеристики - не более чем удобная нотация. Описания уровней полностью независимы от процессов, описания процессов, в свою очередь, не связаны с уровнями, принадлежность процесса к категории имеет только иллюстративный смысл.
Для того чтобы пояснить сказанное, рассмотрим пример.
В категории "Потребитель-поставщик" имеется процесс CUS.1
" Приобрести программный продукт и/или услугуангл. Acquire software product and/or service
". Идентификатор процесса CUS.1 означает просто первый процесс в категории "Потребитель-поставщик". Цель процесса: "Определить действия, которые должны быть выполнены приобретателем или потребителем для получения продукта или услуги".
В процесс входят следующие основные практики (название практики выделено шрифтом).
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 " Выявить потребности потребителяангл. Identify Customer Needs
", PRO.4 " Управлять требованиямиангл. Manage Requirements
", PRO.5 " Управлять качествомангл. Manage Quality
" и SUP.3 " Выполнять аудит результатовангл. 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 пока отсутствует, а для технологии С достаточно хорошо определен. Задача совершенствования процессов в такой ситуации может быть поставлена следующим образом:
обеспечить переход со второго на третий уровень развитости для процессов, выполняемых при использовании технологии B;
обеспечить достижение второго уровня развитости для процессов, выполняемых при использовании технологии А;
начать работы по внедрению процессов управления качеством для процессов, соответствующих технологии В.
Работы должны выполняться в порядке нумерации; при этом работа 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 приводят к дополнительным сложностям при его практическом применении. Рассматривается задача улучшения процессов.
Вопросы
В чем состояла цель проекта SPICE?
Какова структура Отчета SPICE?
Какова структура процессной модели SPICE? Как модель SPICE связана с моделями, представленными в стандартах ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р ИСО/МЭК 15288?
Что такое основные и общие практики? Для чего нужны характеристики?
Чем основные и общие практики отличаются от ключевых практик CMM?
В чем принципиальные отличия модели управления процессами SPICE от модели зрелости CMM?
Какие трудности возникают при практической оценке развитости процессов?
Как в Отчете SPICE выглядит схема улучшения процессов?
Оценка процессов
Отсутствие в доступных публикациях по CMM явно определенных методик применения модели и нежелание SEI способствовать открытому распространению таких методик вызвали к жизни инициативу по разработке практических рекомендаций по использованию модели CMM для оценки проектных организаций, связанных с разработкой ПО, и их процессов.
В 1993 г. с одобрения ISO была создана международная Проектная Организация SPICEангл. Software Process Improvement and Capability dEtermination
(SPICE), которая к 1995 г. подготовила девять документов под общим названием "Оценка процессов, связанных с программным обеспечением" (Software Process Assessment), где рассматриваются все задачи, возникающие при проведении оценки, от построения рейтингов процессов до обучения участников проекта. Эти документы, имевшие статус проекта стандарта ISO, впоследствии действительно составили стандарт ISO/IEC TR 15504 - CMM "Information Technology. Process Assessment". В 2001 г. был опубликован русский перевод стандарта фирмы Ай-Ти (Ай-Ти, 2001), а в 2009 г. подготовлен аутентичный перевод, получивший статус стандарта ГОСТ Р ИСО/МЭК 15504 "Информационные технологии. Оценка процессов" (вводится в действие с 2010 г.). С появлением стандарта ISO название "SPICE" перешло к организации пользователей разработки группы SPICE, которая продолжает существовать и с 2000 г. проводит ежегодные пользовательские конференции.
Я использую в дальнейшем оригинальные материалы SPICE и свой собственный перевод их на русский, чтобы избежать проблем с согласованием русскоязычной терминологии стандарта ГОСТ Р ИСО/МЭК 15504 и терминологии этой книги. Надеюсь, что заинтересованным читателям не составит труда установить соответствие между терминами в разных переводах.
Авторы документов SPICE не применяют термина "аудит процессов", используя вместо него "оценку" (assessment), что затрудняет перевод на русский язык слова assessor. Я буду пользоваться терминами "оценка" и "аудитор". Дальнейшее изложение опирается на документ (SPICE, 1995), который я для краткости буду называть Отчетом SPICE.
(рис 8.1) Взаимосвязи частей Отчета SPICEНа рис 8.1 показана структура Отчета (за исключением вводной части 1 и словаря, содержащегося в части 9). Вот краткие характеристики частей.
Вводная часть. Описывает контекст деятельности по оценке и улучшению процессов и вводит пять категорий процессов.
Модель управления процессами. Определяет шесть уровней развитости процесса. Включает описания всех общих практик для всех уровней развитости и всех основных практик для всех процессов из процессных областей. Модель управления процессами принципиально отличается от модели CMM, хотя и имеет с ней общие черты (см. ниже).
Оценка процессов. Содержит практические указания по построению профиля (см. ниже) конкретного процесса.
Руководство по оценке. Содержит указания по организации проекта оценки, определяет восемь основных этапов проекта, методику выбора экземпляра процесса для оценки, определяет принципы командной работы в проекте. Изложение иллюстрируется примерами.
Построение, выбор и использование инструментов оценки. Самая объемная часть стандарта. Содержит практические советы, шаблоны, таблицы и т. п. инструменты для аудитора. Каждый инструмент предназначен для решения совершенно определенной задачи. Например, таблица "Индикаторы управления процессами" дает формальный механизм оценки того, реализованы ли общие практики на определенном уровне. Таблица структурирована по всем уровням и всем общим практикам.
Квалификация и обучение аудиторов. Даны описания ролей аудиторов в проекте, представлены профессиональные требования к аудитору, изложены методы оценки квалификации аудиторов.
Руководство по использованию оценки с целью улучшения процессов. Содержит рекомендации по инициализации процесса оценки и использованию его результатов в связи с улучшением процессов. Обсуждаются задачи согласования улучшений с бизнес-целями организации, культурные и коммуникационные аспекты улучшения процессов.
Руководство по использованию при определении развитости процессов поставщика. Содержит соображения по выполнению потребителем оценки процессов потенциального поставщика и вытекающих отсюда рисков. Может использоваться самим поставщиком для оценки того, удовлетворяет ли он требованиям потребителя.
Словарь.
Из всех перечисленных частей Отчета первостепенную важность для целей настоящей книги имеют Часть 1 (Введение), Часть 2 (Основные практики), а также отчасти Часть 7 (Улучшение процессов) и Часть 8 (Руководство). На них базируется дальнейшее изложение. Более специальные Части 3-6 не рассматриваются.
Модель процессов в Отчете SPICE
Во введении определяются пять категорий процессов, о которых дальше идет речь в Отчете (см. таблицу 8.1). Документ ориентирован на разработку ПО в проектной организации, т. е. сфера его применения та же, что и у CMM.
Пять категорий процессов
| Категория процесса |
Краткое описание |
|---|
| Потребитель-поставщикангл. Customer-Supplier
|
Процессы, непосредственно затрагивающие потребителя |
| Разработкаангл. Engineering
|
Процессы, устанавливающие требования к системе и программному продукту, процессы реализации и сопровождения |
| Управление проектамиангл. Project
|
Процессы запуска проекта и управления его ресурсами |
| Поддержкаангл. Support
|
Процессы, которые обеспечивают и повышают производительность остальных процессов проекта |
| Организационные процессыангл. Organization
|
Процессы, определяющие бизнес-цели организации и развивающие продукты, ресурсы и процессы, позволяющие достичь бизнес-целей |
Формальная структура модели процессов следующая. Процессы состоят из основных практик. Основные практики процесса обеспечивают достижение его цели и генерируют результаты процесса (в Отчете используется термин work products, который обозначает и промежуточные, рабочие результаты). Выполнение процесса - это и есть выполнение его основных практик. Кроме того, имеются общие практики, характеризующие не процесс, а организацию. Общие практики отражают управленческие действия, направленные на реализацию процесса или на управление процессом. Общие практики в равной степени применимы ко всем процессам.
Общие практики объединяются в характеристикиангл. Common Features
. Содержательно объединение ничего нового не дает, а только группирует практики, близкие по целям управления.
Наконец, определяется шесть уровней развитости процессов. Каждый уровень полностью определяется своим набором характеристик. Характеристики нумеруются так: "номер уровня, номер характеристики на уровне". Ниже приведена таблица, показывающая соответствие уровней и характеристик.
| Уровень |
Описание |
Характеристики |
|---|
| 0 |
Невыполняемый. На этом уровне основные практики процесса не выполняются. Отсутствуют промежуточные результаты и выходы процесса |
нет |
| 1 |
Выполняемый неформально. Основные практики процесса большей частью выполняются. Эффективность выполнения не планируется и не анализируется и зависит от персональных усилий. У исполнителей процесса есть общее понимание того, что, когда и как нужно делать. Имеются результаты процесса |
1.1. Выполняющиеся основные практики (Performing Base Practices) |
| 2 |
Планируемый и отслеживаемый. Выполнение основных практик процесса планируется и отслеживается. Производительность верифицируется в соответствии с определенными процедурами. Результаты удовлетворяют стандартам и требованиям |
2.1. Планируемая производительность (Planning Performance) |
| 2.2. Управляемая производительность (Disciplined Performance) |
| 2.3. Верифицируемая производительность (Verifying Performance) |
| 2.4. Отслеживаемая производительность (Tracking Performance) |
| 3 |
Вполне определенный. Основные практики выполняются в соответствии с вполне определенным процессом, который представляет собой формально утвержденную адаптированную версию стандартного документированного процесса |
3.1. Определенный стандартный процесс (Defining a Standard Process) |
| 3.2. Выполняемый определенный процесс (Performing the Defined Process) |
| 4 |
Управляемый количественно. Выполняются подробные измерения производительности и результаты анализируются. Это приводит к количественному пониманию развитости процесса и возможности прогнозирования производительности. Производительность управляется объективно. Качество результатов процесса выражается количественно |
4.1. Измеримые цели для качества (Establishing Measurable Quality Goals) |
| 4.2. Объективно управляемая производительность (Objectively Managing Performance) |
| 5 |
Непрерывно совершенствуемый. На основе бизнес-целей организации устанавливаются количественные целевые значения эффективности и результативности процесса. Непрерывное улучшение процесса с точки зрения бизнес-целей происходит благодаря количественной обратной связи и внедряемым новым идеям и технологиям |
5.1. Улучшающиеся способности организации (Improving Organizational Capability) |
| 5.2. Улучшающаяся результативность процесса (Improving Process Effectiveness) |
Как видно, описания уровней очень похожи на описания уровней в CMM. Но структуры моделей и уровней зрелости в CMM и Отчете SPICE принципиально разные.
Напомню, что в основу CMM была положена точка зрения, согласно которой уровень зрелости организации характеризуется группой ключевых процессов, причем на каждом уровне зрелости эта группа своя. В ходе развития организации и перехода ее на более высокие уровни зрелости ключевые практики, составляющие группу, и сами группы изменяются. Группы ключевых процессов, соответствующие каждому уровню, были детально описаны. Часть ключевых практик группы определяла собственно выполняемые процессы, а остальные ключевые практики описывали, насколько эти процессы внедрены в практику организации. Для того чтобы подчеркнуть это различие, ключевые практики на каждом уровне группировались в одинаковые разделы с "говорящими" названиями, по которым можно было судить о назначении входящих в раздел практик.
Что же вместо этого предлагает SPICE?
Во-первых, множество процессов организации полностью определено и не меняется в связи с развитием организации. В качестве такого множества взята модель процессов, близкая к той, которую предлагает стандарт ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207), но расширенная процессами управления проектами (таблица соответствий приведена в Приложении E к части 2 Отчета). В стандарте ISO/IEC 15504 (Ай-Ти, 2001) собственная модель процессов была отчасти перегруппирована и расширена по сравнению с эталонной моделью ГОСТ Р ИСО/МЭК 12207 за счет добавления процессов административного управления рисками, административного управления качеством, процесса организационных установок и некоторых других. Позже стандарт был сделан независимым от конкретной модели процессов и просто ссылался на эталонные модели ISO/IEC 12207 и ISO/IEC 15288.
Вместо зрелостиангл. maturity
производственного процесса организации в целом вводится понятие развитостиангл. capability
каждого процесса в отдельности. Разные процессы могут иметь разные уровни развитости; понятие зрелости организации отсутствует. Для того чтобы не придумывать для каждого процесса свои критерии развитости, была определена шкала из шести независимых от процессов уровней, которые характеризуют не процессы, а организацию в целом. Фактически уровни определяют способности организации по управлению процессами.
Довольно искусственное построение CMM, где ключевые практики входили не в процессы, а в разделы, и на каждом уровне содержание разделов было уникально (сохранялись только их названия) заменено в модели SPICE гораздо более простым. Теперь основные практики составляют собственно процессы, а общие - описания уровней. То, что общие практики сгруппированы в характеристики - не более чем удобная нотация. Описания уровней полностью независимы от процессов, описания процессов, в свою очередь, не связаны с уровнями, принадлежность процесса к категории имеет только иллюстративный смысл.
Для того чтобы пояснить сказанное, рассмотрим пример.
В категории "Потребитель-поставщик" имеется процесс CUS.1
" Приобрести программный продукт и/или услугуангл. Acquire software product and/or service
". Идентификатор процесса CUS.1 означает просто первый процесс в категории "Потребитель-поставщик". Цель процесса: "Определить действия, которые должны быть выполнены приобретателем или потребителем для получения продукта или услуги".
В процесс входят следующие основные практики (название практики выделено шрифтом).
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 " Выявить потребности потребителяангл. Identify Customer Needs
", PRO.4 " Управлять требованиямиангл. Manage Requirements
", PRO.5 " Управлять качествомангл. Manage Quality
" и SUP.3 " Выполнять аудит результатовангл. 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 пока отсутствует, а для технологии С достаточно хорошо определен. Задача совершенствования процессов в такой ситуации может быть поставлена следующим образом:
обеспечить переход со второго на третий уровень развитости для процессов, выполняемых при использовании технологии B;
обеспечить достижение второго уровня развитости для процессов, выполняемых при использовании технологии А;
начать работы по внедрению процессов управления качеством для процессов, соответствующих технологии В.
Работы должны выполняться в порядке нумерации; при этом работа 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 приводят к дополнительным сложностям при его практическом применении. Рассматривается задача улучшения процессов.
Вопросы
В чем состояла цель проекта SPICE?
Какова структура Отчета SPICE?
Какова структура процессной модели SPICE? Как модель SPICE связана с моделями, представленными в стандартах ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р ИСО/МЭК 15288?
Что такое основные и общие практики? Для чего нужны характеристики?
Чем основные и общие практики отличаются от ключевых практик CMM?
В чем принципиальные отличия модели управления процессами SPICE от модели зрелости CMM?
Какие трудности возникают при практической оценке развитости процессов?
Как в Отчете SPICE выглядит схема улучшения процессов?
