Читаем Модель зрелости процессов разработки программного обеспечения (ЛП) онлайн бесплатно


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

Данный текст является переводом на русский язык описания одного из самых популярных стандартов постановки процесса разработки программного обеспечения (ПО). Я публикую книгу на своем сайте в открытом доступе для того, чтобы все интересующиеся данным вопросом могли прочитать ее и получить необходимую информацию совершенно свободно и бесплатно. Причина в том, что те методики, которые описаны в данном стандарте, как я считаю, просто обязаны взять на вооружение те разработчики ПО, которые этим занимаются серьёзно. По крайней мере, это касается 2-го и 3-го уровней CMM, так как применение этих практик дает существенное повышение в производительности и устойчивости процесса разработки ПО.

Чарльз В. Вебер , Сьюзен М. Гарсия , Владимир Рябикин

Компьютеры и Интернет / Программирование, программы, базы данных / Программирование
<p>Марк Паулк, Билл Куртис, Мэри Бет Хриссис, Чарльз В. Вебер, Сьюзен М. Гарсия, Мерилин Буш</p><p>CMMI Product Team</p><p>МОДЕЛЬ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ</p><p>ПРЕДИСЛОВИЕ</p>

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

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

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

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

Одной из наиболее популярных, востребованных и весомых методик на сегодняшний день является модель построения зрелых процессов разработки программного обеспечения 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожие книги