Марк Паулк, Билл Куртис, Мэри Бет Хриссис, Чарльз В. Вебер, Сьюзен М. Гарсия, Мерилин Буш

CMMI Product Team

МОДЕЛЬ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ПРЕДИСЛОВИЕ

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

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

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

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

Одной из наиболее популярных, востребованных и весомых методик на сегодняшний день является модель построения зрелых процессов разработки программного обеспечения SW-CMM (Capability Maturity Model for Software). До сих пор эта модель, разработанная Институтом программной инженерии при Университете Карнеги-Меллон (США), была почти неизвестна в России. Основной причиной этого было отсутствие материалов по этому стандарту на русском языке.

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

В заключение хотелось бы персонально поблагодарить тех, кто помогал нам делать данный перевод: сотрудникам компании “Аджаст Медиа”, особенно Наталье Сапрыкиной, подготовившей первую версию глоссария в соответствии с принятой в России стандартной терминологией, а также участникам форума на интернет сайте: Игорю Овсянику (EPAM Systems, Минск), Виктору Малькову (Тэлма, Нижний Новгород), Юрию Назаренко (TelesensKSCL Ukraine Itd.), Михаилу Сабурову, Максиму Локтухину, Алексею Пичкурову, Павлу Можаеву (БНТП, Москва), Александру Бузуну (Тэлма, Нижний Новгород), Александру Ефимову, Batbold Dulguun (The World Bank Junior Professional Associate), активно участвовавших в обсуждении и адаптации перевода основных терминов SW-СММ.

Владимир Рябикин, www.ryabikin.com

ГЛАВА 1. ОСНОВНЫЕ ПОНЯТИЯ ЗРЕЛОСТИ ПРОИЗВОДСТВЕННЫХ ПРОЦЕССОВ

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

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

1.1. Зрелые и незрелые организации-разработчики ПО

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

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

С другой стороны, зрелые организации-разработчики обладают широкими возможностями по управлению процессами разработки и сопровождения ПО. Сферы ответственности внутри производственного процесса точно распределены как среди имеющихся, так и недавно принятых сотрудников, а все работы проводятся в соответствии с запланированным процессом. Установленные процессы пригодны для использования [Humphrey 91b] и соответствуют реально применяемым способам проведения работ. По мере необходимости эти определенные процессы обновляются, а усовершенствования разрабатываются с помощью контролируемого пилотного тестирования и/или анализа затрат и прибылей. Распределение ролей и сфер ответственности в пределах определенного процесса четко определено на протяжении всего проекта и в рамках всей организации.

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

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

1.2. Фундаментальные концепции, лежащие в основе понятия зрелости производственных процессов

Согласно словарю Вебстера, процесс является «системой операций для производства чего-либо… последовательностью действий, изменений или функций, предназначенных для достижения окончания или результата». Комитет IEEE определяет процесс как «последовательность шагов, выполняемых для достижения заданной цели» [IEEE-STD-610]. Производственный процесс может быть определен как набор операций, методов, практик и преобразований, используемых разработчиками для создания и сопровождения ПО и связанных с ним продуктов (например, планов проекта, проектных документов, кодов, сценариев тестирования и руководств пользователя). По мере того, как организация становится более зрелой, ее производственный процесс становится все более четко определенным и последовательно применяемым в рамках всей организации.

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

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

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

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

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

1.3. Обзор модели зрелости процессов разработки

Хотя зачастую инженеры-разработчики и менеджеры хорошо осведомлены о своих проблемах, их взгляды на то, какие усовершенствования являются наиболее важными, могут быть различными. Без организованной стратегии усовершенствования трудно достичь согласия между профессионалами-разработчиками и руководством по вопросу, какие именно работы по усовершенствованию следует выполнять первыми. Для того чтобы усилия по усовершенствованию процессов принесли долговременные результаты, необходимо разработать эволюционный путь развития, поэтапно увеличивающий зрелость производственного процесса организации. Концептуальная структура зрелости производственного процесса [Humphrey 87a] упорядочивает эти стадии таким образом, что усовершенствования на каждой предшествующей стадии являются фундаментом усовершенствований последующей стадии. Таким образом, стратегия усовершенствования, предлагаемая концептуальной структурой зрелости производственного процесса, обеспечивает наиболее прямой путь постоянного улучшения производственного процесса. Эта стратегия призвана руководить усовершенствованиями и выявлять недостатки организации; она не предназначена для быстрого «латания дыр» неудачного проекта.

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

Многоуровневая структура CMM основывается на принципах обеспечения качества продукта, выработанных за последние шестьдесят лет. В начале тридцатых Валтер Шеварт (Walter Shewart) опубликовал работу, в которой изложил принципы статистического контроля качества. Его идеи были развиты, а их успешное применение было продемонстрировано в работах В. Эдвардса Деминга (W. Edwards Deming) [Deming 86] и Джозефа Джурана [Juran 88, Juran 89]. Эти принципы были развиты институтом SEI в виде концептуальной структуры зрелости процессов, формирующей управленческий и инженерный фундамент для количественного контроля над производственным процессом, что является основой для его непрерывного усовершенствования.

Структура зрелости процессов, в которую вошли эти принципы качества, была впервые намечена Филиппом Кросби в его книге «Quality is Free» [Crosby 79]. Сетка зрелости управления качеством, приведенная Кросби, описывает пять эволюционных фаз во внедрении системы управления качеством. Эта структура зрелости была адаптирована для производственного процесса Роном Радиком (Ron Radice) и его коллегами, работающими под руководством Уотса Хэмфри (Watts Humphrey) из компании IBM [Radice 85]. Хэмфри предложил свою структуру зрелости SEI в 1986 г., добавив концепции уровней зрелости и разработав основу для их текущего использования в программной отрасли.

Ранние версии структуры зрелости процессов разработки, предложенные Хэмфри, описаны в технических отчетах SEI [Humphrey 87a, Humphrey 87b], статьях [Humphrey 88] и в его книге «Managing the Software Process» [Humphrey 89]. Предварительный опросный лист для выявления уровня зрелости [Humphrey 87b] был выпущен в 1987 г. в качестве инструмента, позволяющего организациям определить уровень зрелости их производственных процессов. Для получения характеристик зрелости программного процесса в 1987 г. были разработаны методы внутренней и внешней оценки производственного процесса. Начиная с 1990 г., институт SEI с помощью многих энтузиастов из правительственных и отраслевых структур еще более развил и усовершенствовал эту модель, основываясь на опыте нескольких лет совершенствования производственных процессов.

ГЛАВА 2. ПЯТЬ УРОВНЕЙ ЗРЕЛОСТИ ПРОИЗВОДСТВЕННОГО ПРОЦЕССА

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

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

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

Рис. 2.1. Пять уровней зрелости производственного процесса

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

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

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

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

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

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

2.1. Поведенческие характеристики уровней зрелости

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

2.1.1. Уровень 1 — начальный уровень

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

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

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

2.1.2. Уровень 2 — повторяемый уровень

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

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

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

2.1.3. Уровень 3 — определенный уровень

На определенном уровне, стандартный процесс разработки и сопровождения ПО в рамках организации надежно документирован, включая как процессы программной инженерии, так и управления, и эти процессы интегрированы в единое целое. Этот стандартный процесс в материалах CMM называется стандартным производственным процессом организации. Процессы, установленные на уровне 3, используются (и, по мере необходимости, изменяются) для помощи менеджерам и техническому персоналу в более эффективном выполнении своих задач. При стандартизации своих производственных процессов организация использует эффективные практики программной инженерии. Существует группа, которая ответственна за работы по координации производственного процесса организации, т. е. группа инженерии производственного процесса (SEPG) [Fowler 90]. Реализована общая для организации программа обучения, гарантирующая, что персонал и руководящее звено обладают знаниями и навыками, требующимися для выполнения назначенных им ролей.

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

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

2.1.4. Уровень 4 — управляемый уровень

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

Эти измерения формируют количественную основу для оценки продуктов и производственных процессов проектов.

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

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

2.1.5. Уровень 5 — оптимизирующий уровень

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

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

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

2.2. Понимание концепций уровней зрелости

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

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

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

2.2.1. Понимание концепции начального уровня

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

2.2.2. Понимание повторяемого и определенного уровней

По мере роста объема и сложности проекта, внимание постепенно смещается от технических вопросов к организационным и управленческим — т. е. к вопросам, которые находятся в фокусе рассмотрения модели зрелости процессов [Siegel 90, DoD 87, GAO-92-48]. Производственный процесс на этих уровнях позволяет сотрудникам работать более эффективно благодаря созданию документированных процессов, включающих в себя опыт наилучших работников, обретения навыков, необходимых для эффективного выполнения процессов (обычно с помощью обучения), и непрерывного совершенствования за счет обучения у сотрудников, реально выполняющих работу.

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

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

На этом фундаменте управления проектом строится уровень 3, который определяет, интегрирует и документирует весь производственный процесс организации. Под интеграцией в этом случае понимается процесс автоматической передачи выходных данных одной задачи на вход другой. Несоответствия между задачами выявляются и разрешаются на стадии планирования процесса до их фактического воздействия на производственный процесс. Одной из проблем уровня 3 является построение таких процессов, которые не содержат излишних ограничений на выполнение сотрудниками своей работы [Humphrey 91b].

2.2.3. Понимание управляющего и оптимизированного уровней

Четвертый и пятый уровни зрелости относительно незнакомы для программной отрасли. Существуют лишь несколько примеров проектов разработки и организаций уровня 4 и 5 [Humphrey 91a, Kitson 92]. Для создания общей картины характеристик организаций этих уровней имеется слишком мало данных. Эти характеристики были определены по аналогии с другими отраслями промышленности и по нескольким примерам из программной отрасли, представляющими данный уровень продуктивности процессов.

Многие характеристики уровней 4 и 5 основаны на концепциях статистического управления процессами, как представлено на рис. 2.2. Основные цели управления процессами иллюстрируются трехфазной диаграммой Джурана [Juran 88].

Джуран разделяет управление качеством на три основных управленческих процесса [Juran 88]. Целью планирования качества является обеспечение разработчиков ПО средствами создания продукта, способного удовлетворить потребности заказчика. Разработчики производят продукт, но вследствие недостатка качества требуется провести некоторую доработку. Подобная трата сил носит хронический характер, потому что процесс именно так и запланирован. Для предотвращения серьезного ухудшения состояния проекта проводится контроль качества. Показанные на рис. 2.2 спорадические перепады процесса отражают операции «пожаротушения». Хроническая трата сил дает потенциал для дальнейшего усовершенствования; использование этой возможности называется улучшением качества.

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

Второй задачей и центром внимания уровня 5 является постоянное усовершенствование процесса. Производственный процесс изменяется с целью увеличения качества, а область контроля качества сдвигается. Устанавливается новая базовая линия производительности, уменьшающая хронические потери ресурсов. Опыт, извлеченный из улучшения подобного процесса, применяется в планировании будущих процессов. В этом случае используется концепция устранения общих причин отклонений. В любой системе из-за случайных отклонений существуют хронические потери ресурсов в виде необходимости доработки. Потери неприемлемы; организованные усилия по их предотвращению приводят к изменению системы, т. е. к усовершенствованию процесса путем изменения «общих причин» неэффективности.

Ожидается, что организации, достигающие наиболее высоких уровней зрелости CMM, должны обладать процессом, который способен производить ПО высокой надежности с предсказуемыми затратами и в пределах рабочих графиков. По мере роста понимания того, как достигаются наиболее высокие уровни зрелости, одни существующие группы ключевых процессов будут уточнены, а другие могут быть добавлены в модель. Концепция CMM произошла из идей о процессах, впервые появившихся в промышленности, но, в отличие от промышленных процессов, процессы разработки не заостряют внимание на тиражировании своей продукции — они нацелены на вопросы проектирования и являются наукоемкой деятельностью [Curtis 88].





Рис. 2.2. Трехфазная диаграмма Джурана: планирование, контроль и улучшение качества

2.3. Представление о производственном процессе

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





Рис. 2.3. Представление руководства о производственном процессе на каждом уровне зрелости

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

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

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

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

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

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

2.4. Продуктивность процесса и прогнозирование производительности

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

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

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

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





Рис. 2.4. Продуктивность процесса разработки ПО в соответствии с уровнями зрелости

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

2.5. Пропуск этапов развития организации

Описания уровней зрелости в СММ содержат характеристики организации, достигшей соответствующего уровня. Каждый уровень образует основу для более рациональной и эффективной реализации процессов на последующих уровнях. Однако организации могут с пользой для себя использовать процессы, описанные на уровнях зрелости, более высоких в сравнении с достигнутыми. Такие технологические процессы, как анализ требований, проектирование, кодирование и тестирование не обсуждаются в СММ вплоть до уровня 3, однако эти операции должны выполняться даже организациями первого уровня. Организации уровней 1 и 2 могут получать преимущества от проведения экспертных оценок (уровень 3), выполнения анализа Парето (уровень 4) или испытаний новых технологий (уровень 5). Предписания по переходу организации с уровня 1 на уровень 2 часто содержат рекомендации по созданию группы инженерии производственного процесса, которая является атрибутом организаций уровня 3. Измерения, хотя и описываются в основном на уровне 4, являются также неотъемлемой частью более низких уровней зрелости.

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

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

Попытки организации первого уровня внедрить определенный производственный процесс (уровень 3) раньше, чем будет установлен повторяемый процесс (уровень 2), обычно заканчиваются неудачей, поскольку менеджеры проектов попадают в крайне жесткие условия графика и бюджета. В этом кроется основная причина для того, чтобы сконцентрировать усилия на процессах управления прежде, чем заниматься инженерными процессами. Определение и внедрение инженерного процесса может показаться более простым, чем внедрение процесса управления (особенно с точки зрения технических сотрудников), но без строгой дисциплины управления инженерный процесс разваливается под давлением сроков и бюджета [Humphrey 88].

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

Успешное внедрение оптимизирующего процесса (уровень 5) без наличия управляемого процесса (уровень 4) также маловероятно из-за недостаточного понимания влияния, вносимого изменениями процессов.

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

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

ГЛАВА 3. РАБОЧЕЕ ОПРЕДЕЛЕНИЕ МОДЕЛИ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПО

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

Группы внутренней оценки могут использовать СММ для выявления сильных и слабых сторон своей организации.

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

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

Группы, связанные с усовершенствованием процесса (например, группа инженерии производственного процесса), могут использовать СММ в качестве руководства по определению и усовершенствованию производственного процесса организации.

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

3.1. Внутренняя структура описания уровней зрелости

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





Рис. 3.1. Структура CMM

3.2. Уровни зрелости

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

3.3. Группы ключевых процессов

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

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

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

Хотя производительность процесса зависит от многих факторов, группы ключевых процессов выделяются по своей эффективности в повышении продуктивности производственного процесса организации. Их можно рассматривать, как требования для достижения уровня зрелости. На рис. 3.2 показаны группы ключевых процессов для каждого уровня. Для достижения определенного уровня зрелости необходимо реализовать соответствующие группы ключевых процессов, для чего, в свою очередь, требуется достижение всех целей соответствующих групп. Цели подытоживают ключевые практики группы и могут служить критерием эффективной реализации группы ключевых процессов в организации. Они выражают объем, границы и смысл каждой группы ключевых процессов (Список целей каждой группы ключевых процессов приводится в Приложении).





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

Конкретные практики, подлежащие выполнению в каждой группе ключевых процессов, эволюционируют по мере достижения организацией более высоких уровней зрелости. Например, многие средства оценки проекта, описанные в группе ключевых процессов «Планирование проекта» на уровне 2, должны быть модернизированы для обработки дополнительных данных по проекту, доступных на уровнях 3–5. «Интегрированное управление разработкой ПО» на уровне 3 является развитием групп «Планирование проекта» и «Отслеживание хода проекта и контроль над ним» уровня 2, поскольку управление проектом осуществляется с использованием определенного производственного процесса.

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

Группы ключевых процессов уровня 2 связаны в основном с вопросами создания основных средств управления проектом. Ниже приводятся описания всех групп ключевых процессов уровня 2.

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

Цель группы ключевых процессов «Планирование проекта» — создание обоснованных планов разработки ПО и управления выполнением проекта разработки. Эти планы формируют необходимую основу для управления проектом (группа «Отслеживание хода проекта и контроль над ним»). Без реалистичных планов невозможно эффективно управлять проектом.

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

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

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

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

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

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

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

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

Цель группы ключевых процессов «Интегрированное управление разработкой ПО» — интеграция операций разработки и управления в последовательный и определенный производственный процесс, полученный путем адаптации СППО и связанных с ним основных средств, описанных в группе «Определение производственного процесса организации». Эта адаптация основывается на бизнес-среде и технических потребностях проекта (группа «Инженерия разработки программного продукта»). Группа ключевых процессов «Интегрированное управление разработкой ПО» является развитием групп второго уровня «Планирование проекта» и «Отслеживание хода проекта и контроль над ним».

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

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

Цель группы ключевых процессов «Экспертные оценки» — эффективное устранение дефектов в промежуточных программных продуктах на ранних стадиях разработки. Важным следствием этого является улучшение понимания промежуточных программных продуктов и дефектов, которые могут быть предотвращены. Экспертная оценка является важным и эффективным инженерным методом, который используется в инженерии разработки в виде инспекций программ по методу Фагана [Fagan 86], структурированных технических разборов или различных других методов коллегиальных проверок [Freedman 90].

Группы ключевых процессов уровня 4 нацелены на установление количественного понимания производственного процесса и создаваемых промежуточных программных продуктов. Как показано ниже, группы ключевых процессов этого уровня «Количественное управление процессом» и «Управление качеством ПО» являются в высшей степени взаимозависимыми.

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

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

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

Цель группы ключевых процессов «Предотвращение дефектов» — выявление причин дефектов и предотвращение их повторного появления. В ходе проекта разработки проводится анализ обнаруженных дефектов, определяются их причины и вносятся соответствующие изменения в производственный процесс проекта (группа «Интегрированное управление разработкой ПО»). Изменения процесса, имеющие общий характер, переносятся на другие проекты разработки (группа «Управление изменениями процесса»).

Цель группы ключевых процессов «Управление технологическими изменениями» — выявление новых полезных технологий (т. е. инструментов, методов и процессов) и их организованного внедрения в организации (группа «Управление изменениями процесса»). Управление технологическими изменениями нацелено на эффективное внедрение новшеств в условиях постоянно меняющейся среды.

Цель группы ключевых процессов «Управление изменениями процесса» — непрерывное усовершенствование производственных процессов, используемых в организации, с целью улучшения качества производимого ПО, повышения производительности и сокращения цикла разработки продукта. Эта группа процессов использует последовательные усовершенствования и новшества, вносимые в рамках групп «Предотвращение дефектов» и «Управление технологическими изменениями», и распространяет их на всю организацию.

3.4. Разделы

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

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

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

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

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

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

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

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

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

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

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

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

3.5. Ключевые практики

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

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

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

Ключевые практики описывают, «что» необходимо сделать, но их не следует воспринимать в виде догм, устанавливающих, «как» нужно достигать целей. Цели группы ключевых процессов можно реализовать с помощью альтернативных практик. Интерпретация ключевых практик должна быть разумной, допускающей достижение целей группы ключевых процессов эффективным, хотя, возможно, и отличающимся способом. Ключевые практики вместе с рекомендациями по их интерпретации содержатся в документе «Key Practices of the Capability Maturity Model, Version 1.1» («Ключевые практики модели зрелости процессов разработки, версия 1.1») [Paulk 93b], который входит во вторую часть данной книги.





Рис. 3.3. Построение структуры CMM: пример ключевой практики

ГЛАВА 4. ИСПОЛЬЗОВАНИЕ СММ

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

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

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

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

Этот обзор сам по себе недостаточен читателям для проведения внутренних или внешних оценок производственного процесса. Желающим применить модель СММ с использованием этих двух методов потребуется дополнительное обучение.

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

4.1. Методы внутренней и внешней оценки производственного процесса

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

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

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

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

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

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





Рис. 4.1. Общие шаги при проведении внутренних и внешних оценок производственного процесса

3 Эти оценки могут проводиться и без получения полной информации, если ее сбор затрагивает вопросы конфиденциальности или безопасности организации.

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

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

Ниже приведен краткий список общих черт внутренней и внешней оценок производственного процесса:

посещение организации опирается на результаты опросного листа для выявления уровня зрелости;

при исследовании организации группа оценки руководствуется моделью СММ;

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

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

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

4.2. Различия между внутренними и внешними оценками производственного процесса

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

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

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

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

4.3. Другие способы использования CMM при усовершенствовании производственного процесса

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

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

ГЛАВА 5. БУДУЩИЕ НАПРАВЛЕНИЯ РАЗВИТИЯ СММ

Достижение более высоких уровней зрелости производственного процесса является постепенным и требует от организации долгосрочных обязательств по непрерывному усовершенствованию процесса. На построение фундамента для непрерывного усовершенствования производственного процесса и внедрение соответствующей культуры организации-разработчики могут затратить более 10 лет. Хотя подобная десятилетняя программа усовершенствования процесса кажется чуждой для большинства американских компаний, именно такой объем работ требуется для построения зрелых организаций-разработчиков. Этот срок согласуется с опытом в других отраслях, таких, как американская автомобильная промышленность, которая добилась значительных достижений в области зрелости производственного процесса [Gabor 90].

5.1. Что находится вне области рассмотрения CMM

Модель СММ не является панацеей [Brooks 87] и не включает в себя все вопросы, значимые для успешных проектов. Например, в настоящее время СММ не рассматривает опыт в конкретных предметных областях, не пропагандирует конкретных технологий разработки и не содержит рекомендаций по выбору, найму, мотивации и сохранению компетентных сотрудников. Эти вопросы жизненно важны для успеха проекта и некоторые из них были проанализированы в другом контексте [Curtis 90]. Однако они не были интегрированы в СММ. Модель СММ была специально разработана с намерением создать упорядоченную, дисциплинированную структуру, внутри которой можно решать проблемы управления разработкой и инженерии процесса.

5.2. Ближайшие задачи

Учебные материалы и курсы по СММ должны представляться на крупных конференциях и семинарах в США, поддерживая среди специалистов программной отрасли должный уровень осведомленности о модели СММ и связанных с ней продуктах. Для включения в СММ должны быть разработаны и/ или пересмотрены новые инструменты (например, опросный лист для выявления уровня зрелости), а также программы обучения внутренней и внешней оценке производственного процесса.

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

5.3. Долговременные задачи

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

В следующей, второй версии СММ основное внимание будет уделено улучшению общей модели. Хотя пересмотру могут подвергнуться все уровни модели, основной акцент будет сделан на уровнях 4 и 5. В настоящее время группы ключевых процессов уровней 2 и 3 практически полностью определены. Поскольку по оценкам лишь немногие организации находятся на уровнях 4 и 5 [Humphrey 91a, Kitson 92], о характеристиках таких организаций известно немного. По мере сотрудничества SEI с организациями, пытающимися понять уровни 4 и 5 и достигнуть их, практики этих уровней будут уточняться. Модель СММ также может стать многомерной, объединяя вопросы технологии и человеческих ресурсов.

Институт SEI сотрудничает с Международной организацией по стандартизации (ISO) в работе по созданию международных стандартов для внутренней и внешней оценок производственного процесса и его усовершенствования. Развитие стандартов ISO повлияет на СММ версии 2, а разработки SEI в области процессов будут влиять на работу ISO.

5.4. Заключение

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

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

ГЛАВА 6. ИСПОЛЬЗОВАНИЕ СТРАНИЦ ОПИСАНИЯ КЛЮЧЕВЫХ ПРАКТИК

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

Каждая из групп ключевых процессов содержит:

краткое описание,

цели,

ключевые практики.

Ключевые практики, в свою очередь, сгруппированы по общим признакам в пять подгрупп («Обязательства по выполнению», «Необходимые предпосылки», «Выполняемые операции», «Измерение и анализ» и «Проверка внедрения»). Пример страницы описания ключевой практики приведен на рис. 3.1. Под ключевыми практиками понимают:

Ключевые практики (как таковые)

Ключевые практики, известные так же как ключевые практики верхнего уровня, устанавливают основные политики, процедуры и операции для каждой группы ключевых процессов. В тексте они выделены жирным шрифтом и пронумерованы в пределах соответствующей общей области. Так, например, первая ключевая практика в группе «Выполняемые операции» носит название Операция № 1.

Подпрактики

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





Рис. 6.1. Примеры предложений, используемых в ключевых практиках

ГЛАВА 7. ИНТЕРПРЕТАЦИЯ СММ

7.1. Интерпретация ключевых практик

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

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

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

В Приложении Б приведен глоссарий, содержащий определения терминов (включая термины, описываемые в данном разделе, равно как и в прочих).

7.2. Интерпретация разделов

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

Основные структурные термины описаны ниже и сгруппированы по разделам.

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



Положения политики

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

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

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

Лидерство

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

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



Ресурсы и финансирование

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

Использование термина «финансирование» вместо слова «бюджет» подчеркивает, что нас прежде всего интересуют собранные и использованные, а не просто «обещанные» средства.

Обучение