Марк Паулк, Билл Куртис, Мэри Бет Хриссис, Чарльз В. Вебер, Сьюзен М. Гарсия, Мерилин Буш
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
Не секрет, что до недавнего времени типичный способ разработки ПО в России был ориентирован на программистов-одиночек, программистов-кустарей. Интереса к индустриальному производству ПО почти не было из-за низкого платежеспособного спроса на сложные программные комплексы. Разработка программного обеспечения велась спонтанно, не уделялось особого внимания вопросам организации самого процесса: планированию, тестированию, межгрупповому взаимодействию, управлению конфигурацией.
Однако в последние годы наблюдается взросление экономики страны, а вслед за ней и технологий производства. Возросшая конкуренция на внутреннем рынке и попытки выхода на мировой резко повысили интерес к повышению производительности труда в экономике России, рост которой сейчас напрямую связывают с информатизацией. Возросла ценность программного обеспечения и, таким образом, интерес к постановке индустриального процесса разработки ПО заметно усилился. Отрасль производства программного обеспечения растет и переходит от кустарных разработок к промышленным методам, так как первые просто становятся невыгодны экономически. Кроме того, активно развивается отрасль “оффшорного” программирования, при которой непосредственно производство программ передается в страну, имеющую квалифицированных недорогих специалистов. Таким образом, конкуренция и работа с западными заказчиками стали подталкивать отечественных программистов к совершенствованию своих методов работы.
На сегодняшний день существует множество разнообразных методологий построения процесса разработки ПО, и у каждой из них есть свои плюсы и минусы, области применения, в которых определенные из них наиболее эффективны. Все эти методологии преследуют своей первой целью улучшение производственного процесса, который позволил бы наиболее эффективно и качественно производить программные продукты. Кроме того, некоторые из них предоставляют методику оценки уже существующего технологического процесса, для того чтобы объективно сравнивать разные компании-разработчики по их уровню и производительности. Такие методики оценки используются компаниями-заказчиками для определения уровня исполнителей для своих проектов при принятии решения о заключении контракта.
Одной из наиболее популярных, востребованных и весомых методик на сегодняшний день является модель построения зрелых процессов разработки программного обеспечения 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] и соответствуют реально применяемым способам проведения работ. По мере необходимости эти определенные процессы обновляются, а усовершенствования разрабатываются с помощью контролируемого пилотного тестирования и/или анализа затрат и прибылей. Распределение ролей и сфер ответственности в пределах определенного процесса четко определено на протяжении всего проекта и в рамках всей организации.
В зрелой организации, управляющее звено непрерывно следит за качеством программного продукта и за тем, удовлетворен ли заказчик созданным решением. Существует объективная, количественная основа для вынесения решения о качестве продукта, а также анализа проблем, возникающих с продуктом или процессом. План-графики и бюджеты реалистичны и основаны на показателях производительности предыдущих проектов; как правило, достигаются ожидаемые результаты по затратам, срокам разработки, функциональности и качеству продукта. Кратко говоря, соблюдается точное следование упорядоченному процессу, так как все участники проекта понимают важность его соблюдения, а для поддержки процесса разработки существует необходимая инфраструктура.
Реализация этих наблюдений о зрелых и незрелых организациях требует создания структуры, обеспечивающей достижение зрелости производственных процессов. Эта структура предназначена для описания эволюционного пути от специально создаваемых, хаотических процессов к зрелым, упорядоченным производственным процессам. Без этой структуры программы улучшения процессов могут стать неэффективными, вследствие отсутствия необходимых предпосылок для поддержки последовательных усовершенствований. Структура поддержки зрелости производственных процессов представляет собой интеграцию концепций самого производственного процесса, его возможностей, производительности и зрелости. Каждая из этих концепций будет обсуждена далее.
В незрелых организациях не существует объективной основы для вынесения решения о качестве продукта или для решения проблем, связанных с процессами и разрабатываемым продуктом. Вследствие этого качество разработанного программного продукта является трудно предсказуемым. Работы, нацеленные на улучшение качества, такие как экспертные оценки и тестирование, зачастую урезаются или вообще отбрасываются по мере того, как проект выходит за пределы своего графика.
С другой стороны, зрелые организации-разработчики обладают широкими возможностями по управлению процессами разработки и сопровождения ПО. Сферы ответственности внутри производственного процесса точно распределены как среди имеющихся, так и недавно принятых сотрудников, а все работы проводятся в соответствии с запланированным процессом. Установленные процессы пригодны для использования [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 с помощью многих энтузиастов из правительственных и отраслевых структур еще более развил и усовершенствовал эту модель, основываясь на опыте нескольких лет совершенствования производственных процессов.
Модель зрелости процессов разработки ПО предоставляет организации-разработчику руководящие принципы управления своими процессами разработки и сопровождения ПО, а также развития культуры управления и программной инженерии. 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 организация CMM по пяти уровням зрелости определяет приоритеты работ по развитию производственного процесса. Помеченные стрелки на рис. 2.1 указывают на тип продуктивности процесса, устанавливаемый организацией на каждом шаге его структуры.
Рис. 2.1. Пять уровней зрелости производственного процесса
Последующие характеристики пяти уровней зрелости раскрывают основные изменения процессов, проводимые на каждом из них.
1) Начальный Производственный процесс характеризуется как создаваемый каждый раз под конкретный проект, а иногда даже как хаотический. Определены лишь некоторые процессы и успех проекта зависит от усилий индивидуумов.
2) Повторяемый Установлены основные процессы управления проектом, позволяющие отслеживать затраты, следить за графиком работ и функциональностью создаваемого программного решения. Установлена дисциплина процесса, необходимая для повторения достигнутых ранее успехов в проектах разработки подобных приложений.
3) Определенный Производственный процесс документирован и стандартизован как для управленческих работ, так и для проектирования. Этот процесс интегрирован в стандартный производственный процесс организации. Во всех проектах используется утвержденная адаптированная версия стандартного производственного процесса организации.
4) Управляемый Собираются подробные количественные показатели производственного процесса и качества создаваемого продукта. Как производственный процесс, так и продукты оцениваются и контролируются с количественной точки зрения.
5) Оптимизирующий Постоянное совершенствование процесса достигается благодаря количественной обратной связи с процессом и реализации передовых идей и технологий.
2.1. Поведенческие характеристики уровней зрелости
Уровни зрелости от 2 до 5 могут характеризоваться работами, выполняемыми организацией в целях установления или совершенствования производственного процесса, работами по каждому проекту, а также итоговой продуктивности процессов во всех выполняющихся проектах. Поведенческая характеристика уровня 1 включена в целях создания основы для сравнения усовершенствований процессов на более высоких уровнях зрелости.
2.1.1. Уровень 1 — начальный уровень
Находясь на начальном уровне, организация обычно не может обеспечить устойчивый процесс разработки и сопровождения ПО. Когда в организации отсутствует культура управления, преимущества применения хороших решений в процессе проектирования исчезают из-за неэффективного планирования и плохой работы систем согласования.
Во время кризисных ситуаций в проектах зачастую отбрасываются запланированные процедуры и все усилия фокусируются на написании кода и тестировании. Успех целиком зависит от наличия исключительно эффективного менеджера и наличия опытного и квалифицированного коллектива разработчиков. Иногда талантливые и влиятельные менеджеры могут противостоять соблазну игнорировать стандартные плановые процедуры производственного процесса; но если такие менеджеры покидают проект, то они уносят вместе с собой и свое стабилизирующее влияние. Даже самый устойчивый процесс проектирования не сможет противостоять нестабильности, вызванной отсутствием надёжных практик управления.
Продуктивность производственного процесса организаций уровня 1 непредсказуема, что вызывается постоянными изменениями или модификациями производственного процесса по мере выполнения работ (т. е. процесс специально создается для каждого проекта). Графики работ, бюджеты, функциональность и качество продукта, как правило, непредсказуемы. Производительность зависит от возможностей отдельных сотрудников и изменяется в зависимости от присущих им навыков, знаний и мотивации. Существует лишь несколько стабильных производственных процессов, а производительность можно прогнозировать только на уровне отдельных сотрудников, но не для организации в целом.
Во время кризисных ситуаций в проектах зачастую отбрасываются запланированные процедуры и все усилия фокусируются на написании кода и тестировании. Успех целиком зависит от наличия исключительно эффективного менеджера и наличия опытного и квалифицированного коллектива разработчиков. Иногда талантливые и влиятельные менеджеры могут противостоять соблазну игнорировать стандартные плановые процедуры производственного процесса; но если такие менеджеры покидают проект, то они уносят вместе с собой и свое стабилизирующее влияние. Даже самый устойчивый процесс проектирования не сможет противостоять нестабильности, вызванной отсутствием надёжных практик управления.
Продуктивность производственного процесса организаций уровня 1 непредсказуема, что вызывается постоянными изменениями или модификациями производственного процесса по мере выполнения работ (т. е. процесс специально создается для каждого проекта). Графики работ, бюджеты, функциональность и качество продукта, как правило, непредсказуемы. Производительность зависит от возможностей отдельных сотрудников и изменяется в зависимости от присущих им навыков, знаний и мотивации. Существует лишь несколько стабильных производственных процессов, а производительность можно прогнозировать только на уровне отдельных сотрудников, но не для организации в целом.
2.1.2. Уровень 2 — повторяемый уровень
На повторяемом уровне установлены политики управления проектом разработки и процедуры их применения. Планирование и управление новым проектом базируется на опыте работы с подобными проектами. Целью достижения уровня 2 является институционализация таких процессов эффективного управления проектами разработки, которые позволяют организациям воспроизводить успешные практики прежних проектов, хотя конкретные процессы различных проектов могут различаться. Эффективный процесс может быть охарактеризован как проверенный на практике, документированный, обязательный к выполнению, обучаемый, измеряемый и открытый для дальнейшего усовершенствования.
В проектах организаций второго уровня устанавливаются основные средства управления программным проектом. Реалистичные обязательства по проекту базируются на результатах прежних проектов и на требованиях текущего. Менеджеры проекта отслеживают производственные затраты, выполнение графиков и функциональность продукта; проблемы выполнения обязательств выявляются сразу после их возникновения. Требования к ПО и созданные на их основе рабочие продукты отслеживаются в системе управления конфигурацией, а их целостность контролируется. Определены стандарты проекта разработки и обеспечено их строгое соблюдение в рамках организации. В ходе проекта разработки проводится работа с субподрядчиками (при их наличии) по налаживанию надежных связей между заказчиком и субподрядчиком.
Продуктивность производственного процесса организаций уровня 2 может быть охарактеризована как дисциплинированная, так как планирование и отслеживание проекта разработки стабильно и возможно воспроизведение прежних достижений. Производственный процесс проекта находится под эффективным управлением системы управления проектами и следует реалистичным планам, основанным на результатах прежних проектов.
В проектах организаций второго уровня устанавливаются основные средства управления программным проектом. Реалистичные обязательства по проекту базируются на результатах прежних проектов и на требованиях текущего. Менеджеры проекта отслеживают производственные затраты, выполнение графиков и функциональность продукта; проблемы выполнения обязательств выявляются сразу после их возникновения. Требования к ПО и созданные на их основе рабочие продукты отслеживаются в системе управления конфигурацией, а их целостность контролируется. Определены стандарты проекта разработки и обеспечено их строгое соблюдение в рамках организации. В ходе проекта разработки проводится работа с субподрядчиками (при их наличии) по налаживанию надежных связей между заказчиком и субподрядчиком.
Продуктивность производственного процесса организаций уровня 2 может быть охарактеризована как дисциплинированная, так как планирование и отслеживание проекта разработки стабильно и возможно воспроизведение прежних достижений. Производственный процесс проекта находится под эффективным управлением системы управления проектами и следует реалистичным планам, основанным на результатах прежних проектов.