Марк Паулк: Модель зрелости процессов разработки программного обеспечения

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

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

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

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

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

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

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