«Пятерка» за разработку

По данным исследования российской индустрии офшорного программирования, проведенного Outsourcing-Russia.com, в российской индустрии разработки программного обеспечения популярность сертификации по стандарту SEI CMM и новейшей версии модели зрелости CMMI неуклонно растет

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

В Москве прошла серия семинаров Марка Полка, автора модели зрелости процессов разработки программного обеспечения (Capability Maturity Model, CMM). Полк, в течение полутора десятилетий занимавшийся развитием модели СММ, — признанный гуру в области оценки качества индустриальной разработки программных продуктов. Сегодня он ведет исследования практик высокого уровня зрелости разработки программного обеспечения, а также работает над созданием модели зрелости процессов в ИТ-аутсорсинге eSourcing Capability Model (eSCM).

По данным исследования российской индустрии офшорного программирования, проведенного некоммерческим Internet-порталом Outsourcing-Russia.com, в российской индустрии разработки ПО популярность сертификации по стандарту SEI CMM и новейшей версии модели зрелости CMMI неуклонно растет. По прогнозам, число компаний, планирующих провести оценку своих процессов по CMM, в этом году должно превысить количество желающих получить сертификат качества ISO 9001. Неудивителен поэтому большой интерес российской аудитории к теме семинаров Полка. Организатором семинаров выступила компания RUSSEE, которая проводит обучение моделям CMM/CMMI. В течение четырех рабочих дней Полк рассказывал о возможностях совершенствования процессов разработки и поддержки программного обеспечения, внедрении моделей зрелости процессов, преимуществах достижения высших уровней зрелости, взаимосвязи новейших методик и качества разработки. При сходном звучании тем каждый день семинаров был ориентирован на свою аудиторию, от руководителей проектов и менеджеров по качеству до менеджеров высшего звена и ИТ-директоров. В напряженном графике семинарских дней Марк Полк нашел время побеседовать с редактором журнала «Открытые системы» Натальей Дубовой.

Расскажите, пожалуйста, об истории создания модели CMM.

Основным заказчиком модели был Пентагон, в проектах которого постоянно возникали серьезные проблемы — превышение бюджетов и сроков, низкий уровень качества программных продуктов. Было принято решение усовершенствовать инженерию разработки программного обеспечения. Эта миссия была возложена на Software Engineering Institute (SEI), созданный в 1984 году в Университете Карнеги—Меллона. На базе этого университета, подобно ряду других американских университетов, ведутся научно-исследовательские работы, финансируемые из бюджета федерального уровня и позволяющие решать научные проблемы в интересах американского правительства. Выбор Университета Карнеги—Меллона был не случаен — это одна из ведущих научных школ мира в области программной инженерии, компьютерных наук.

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

Первый опыт применения модели СММ для оценки подрядчиков проектов Министерства обороны оказался успешным, что привлекло внимание к ней других организаций, например компании Boeing. Использование принципов, описанных в CMM, позволило повысить качество разработки, сократить производственные циклы, поднять продуктивность в проектах по созданию высококритичных систем. Идеи CMM стали получать все более широкое распространение в ряде отраслей, в том числе аэрокосмической и телекоммуникационной. Однако то, что инициатором проекта улучшения процессов разработки было Министерство обороны, имело ряд негативных последствий. Так, многие коммерческие компании довольно долго отвергали идеи CMM, считая подходы Пентагона к организации процессов программной инженерии слишком формализованными, хотя модель CMM сама по себе не имеет этих ограничений. Но в последние годы все больше самых разных организаций берут на вооружение базовые принципы CMM. Достигают успеха в первую очередь те, кто создает процессы, соответствующие их роду деятельности. Если вы разрабатываете Web-сайты, то вполне можете применить общие принципы CMM, но их реализация, скорее всего, будет совершенно отлична от процессов, используемых при разработке высококритичных систем. Но в обоих случаях будут внедряться процессы, которые помогут компании извлечь уроки из своих успехов и неудач и реализовать свои бизнес-цели. В этом состоит главное достижение создателей CMM.

А какие цели преследовались при разработке CMMI? На семинаре вы заметили, что не являетесь большим приверженцем этой модели. Почему?

CMMI охватывает гораздо более широкий круг проблем, чем CMM, включая разработку системного программного обеспечения, интегрированную разработку продуктов и процессов, выбор поставщиков и т. д. Эта модель отвечает задачам крупных организаций, которые занимаются созданием как программных, так и аппаратных систем. Но, по моему мнению, для организаций меньшего масштаба, специализирующихся именно на разработке программных продуктов, CMMI предлагает не самый эффективный способ улучшения процессов. Для огромного большинства пользователей модели CMM в области разработки переход на новую модель сопряжен с рядом серьезных проблем, поскольку CMMI больше, сложнее и дороже в реализации. Однако Министерство обороны США сделало выбор в пользу CMMI, и по этой причине в SEI были прекращены работы по созданию новой версии СММ и теперь обеспечивается поддержка только модели CMMI. Я бы предпочел, чтобы продолжалось развитие обеих моделей, поскольку они отвечают требованиям разных типов компаний, но для этого у SEI нет достаточных ресурсов.

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

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

Какие обязательные шаги должна предпринять компания, чтобы подняться с одного уровня модели CMM на другой?

Если говорить конкретно, например, о переходе с первого уровня на второй, то в соответствии с моделью CMM обязательным условием является планирование проекта. То есть вы должны уметь составлять расписание, оценивать и отслеживать риски проекта и т. д. Однако в модели даются абстрактные рекомендации, и при конкретной реализации процессов необходимо будет выбрать определенные методы и инструментарий для такого планирования. От того, разработкой каких продуктов вы занимаетесь, будет зависеть, остановите вы свой выбор на методике COCOMO, методике функциональных точек или других. Другой пример — управление конфигурациями, которое необходимо в организации, соответствующей второму уровню модели CMM. Процессы и инструменты управления конфигурациями в проекте с участием 500 разработчиков будут сильно отличаться от процессов и инструментов управления конфигурациями в проекте с командой разработчиков из трех человек. Конкретная реализация — выбор инструментария и методов — должна соответствовать тому, чем занимается компания. CMM говорит, что должно быть сделано, но не говорит, как это должно быть сделано. Ответ на второй вопрос компания ищет самостоятельно.

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

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

Что вы думаете о взаимосвязи методологий разработки и уровня зрелости компании в этой области? Я имею в виду прежде всего Rational Unified Process, а также методы agile-программирования, в частности XP.

Специалистами Rational написана статья, посвященная тому, как RUP и связанные с ним инструментальные средства поддерживают различные процессы CMM/CMMI. Процессы RUP не конфликтуют с процессами CMM, а взаимно дополняют друг друга. Возможно, RUP не охватывает всех проблем, которые рассматриваются в CMM, но может решать те задачи, которые не учтены в CMM. И очень часто организации, которые используют CMM для улучшения процессов разработки, применяют RUP и соответствующий инструментарий в качестве средства реализации требований модели.

Это один из возможных способов реализации, но есть и другие, например agile-методики, экстремальное программирование (XP). Это определенный, довольно специфичный стиль создания программного обеспечения. Его основные характеристики: маленькие команды разработчиков, которые обязательно находятся одном помещении; представители заказчиков сотрудничают с разработчиками для обеспечения постоянной обратной связи; очень маленькие итерации. При правильном применении методик XP можно получить очень дисциплинированный способ организации работ.

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

Какого максимального уровня зрелости может достигнуть компания, использующая agile-методики?

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

Производители инструментальных средств разработки активно продвигают концепцию управления жизненным циклом приложений (application lifecycle management, ALM). Что вы думаете о влиянии этих идей на уровень зрелости процессов разработки?

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

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

Каковы основные компоненты качества программного продукта?

Самое простое определение качества — это свобода от дефектов. Но для клиентов качество — гораздо более сложное понятие. Обычно они оценивают программный продукт по таким критериям, как стоимость, доступность, производительность, функциональность, возможности использования, элегантность пользовательского интерфейса. Из всех этих свойств складывается представление пользователя о том, что такое высококачественный продукт. Некоторые из этих атрибутов качества могут меняться со временем. Microsoft, например, в течение 25 лет ставила во главу угла функциональность, но в последние несколько лет фокус в понимании качественного продукта начал смещаться. В 2002 году Билл Гейтс в своем ме?морандуме говорил о том, что наибольшее значение для клиентов Microsoft в современном мире Internet имеет такая характеристика программных решений, как безопасность. Это отражает общую тенденцию рынка: если раньше пользователей при приобретении системы прежде всего интересовали ее возможности, то теперь гораздо больше внимания уделяется проблемам безопасности и надежности.

Расскажите, пожалуйста, о своем новом проекте — модели e-Sourcing Capability Model.

Четыре года назад Университет Карнеги—Меллона получил запрос на разработку модели зрелости процессов для поставщиков услуг, компаний, которые занимаются аутсорсингом, офшорными проектами. В процессе работы мы обнаружили, что это дает нам шанс формализовать процессы прежде всего для тех компаний, в услугах которых присутствует сильный ИТ-компонент. Например, центры обработки запросов клиентов. Для того чтобы узнать состояние своего банковского счета, вы из Питтсбурга обращаетесь в контакт-центр, расположенный в Индии, России или Китае. Специалист на другом конце телефонной линии имеет доступ к серверу базы данных, может посмотреть соответствующие финансовые записи в интерактивном режиме и ответить на ваш запрос. В такой услуге именно информационные технологии дают возможность реализовать запросы клиента. Подобных сервисов существует очень много в банковской и финансовой сфере, медицине, энергетике, транспорте, включая специализированные ИТ-услуги, такие как центры поддержки клиентов, ITSM, управление приложениями и т. д. Мы строим модель зрелости, включающую 84 области процессов, которые должны быть реализованы поставщиками услуг для того, чтобы обеспечить качественное обслуживание. В модели будет стандартизирован полный цикл — от начального обращения к поставщику услуг до предоставления услуги и вплоть до завершения отношений клиента с поставщиком.

В ходе нашей работы возникла также необходимость разработки аналогичной модели зрелости сервисов с точки зрения клиентов. Таким образом, мы работаем над совершенствованием взаимоотношений в рамках аутсорсинга с обеих сторон — поставщика услуг и клиента. В консорциум, который поддерживает наш проект, входят представители обеих сторон. Среди его членов — Accenture, IBM Global Service, EDS, правительственное агентство, которое занимается аутсорсинговыми проектами в Индии, и ряд других.

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

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

Систематизация стандартов

До недавнего времени любой более или менее влиятельный в своей сфере орган издавал стандарты на программное обеспечение и системные процессы, рекомендовал те или иные методы работы, модели достижения зрелости и многочисленные другие модели. Соответственно множилось и количество организаций, следивших за соблюдением того или иного стандарта или выполнявших проверку на соответствие той или иной модели (см. Sarah Sheard, Evalution of the Frameworks Quigmare, IEEE Computer, July 2002).

Модели достижения зрелости. Первой в серии моделей достижения зрелости была Capability Maturity Model for Software (SW-CMM), созданная и поддерживаемая институтом Software Engineering Institute (SEI) в составе Университета Карнеги—Меллона еще в 1993 году. В 2003-м место этой модели заняла модель Capability Maturity Model-Integrated (CMMI).

Для поддержки закупок программного обеспечения государственными органами была разработана Software Acquisition CMM (SA-CMM).

SEI предложила также две методологии проектирования программного обеспечения. Personal Software Process (PSP) имеет своей целью повысить предсказуемость и качество результатов труда отдельного разработчика. Зазор между PSP, ориентированным на индивидуальных программистов, и SW-CMM, ориентированным на корпоративный уровень, заполняет Team Software Process (TSP). Он указывает специалистам, как организовать управление работой и держать под контролем собственные планы и процессы.

Стандарты на программное обеспечение. В 1994 году Министерство обороны США создало стандарт MIL-STD-498, объединивший в себе стандарт на разработку программного обеспечения (DOD-STD-2167A), стандарт качества программного обеспечения (DOD-STD-2168) и требования к ведению документации (DOD-STD-7935A). Рабочая группа IEEE и ассоциация Electronics Industries Association (EIA) предложили «демилитаризованный» вариант этого стандарта — J-STD-016, который отличался главным образом мягкостью формулировок.

В 1995 году ISO и International Electrotechnical Commission выпустили ISO/IEC 12207, стандарт, регламентирующий процессы, связанные с жизненным циклом программного обеспечения. Затем рабочая группа IEEE-EIA добавила приложение к этому стандарту, в результате сформировался стандарт IEEE/EIA 12207. Новый документ отличало требование совместимости с ISO 9000, наличие полной поддержки объектно-ориентированных и аналитических методов, автоматизированного инструментария разработчика и описания жизненных циклов программного обеспечения, отличных от типовой «каскадной» модели.

RTCA DO-178B регламентирует различные уровни безопасности программных систем. В нем перечислены требования к процессам планирования, разработки, управления конфигурацией, обеспечению качества и верификации.

Модели для системного проектирования. Модель Systems Engineering Capability Maturity Model (SE-CMM) и связанные с ней методы SE-CMM Appraisal Method (SAM) были предложены ассоциацией, в которую входил и SEI. Международный совет по системной инженерии INCOSE разработал Systems Engineering Capability Assessment Model (SECAM), в которую вошли как сама модель, так и методы оценки, в том числе способы измерения эффективности процессов и качества продуктов.

Модель Systems Engineering Capability Model (EIA/IS 731) охватила оба стандарта. CMMI заняла место EIA/IS 731 в 2003 году.

Стандарты системной инженерии. В 1993 году EIA финансировала небольшую группу исследователей и разработчиков, которые должны были внести минимальные изменения в проект стандарта MIL-STD-499B. Этот стандарт системной инженерии был предложен Пентагоном в 1992 году, но отвергнут гражданскими организациями. В результате изменений был сформирован стандарт EIA/IS 632, получивший статус международного в 1994 году. В это же время IEEE, базируясь на обширных отраслевых данных, создала IEEE 1220, который был окончательно оформлен в 1998 году. Он был в большей степени ориентирован на особенности коммерческих продуктов. После достижения консенсуса в отрасли, в 1999 году была предложена полная версия EIA 632, которая лишь незначительно напоминала EIA/IS 632.

Подкомитет ISO создал стандарт жизненного цикла ПО ISO/IEC 12207 для рабочих групп. Новейшая разработка этой организации — стандарт жизненного цикла систем ISO/IEC 15288.

Оценка степени зрелости. Наиболее распространенным методом оценки в SW-CMM является CMM-Based Appraisal for Internal Process Improvement (CBA IPI), предполагающий помощь уполномоченного SEI эксперта для самостоятельной оценки. Согласно другому методу проверки соответствия требованиям SWCMM, степень зрелости компании должны оценивать внешние организации.

Метод Standard CMMI Assessment Method for Process Improvement (SCAMPI), используемый для внутренних оценок CMMI, основывается главным образом на CBA IPI. Одной из целей запланированной в 2001 модернизации было сведение к минимуму расходов на выполнение оценки SCAMPI. Стандарт ISO/IEC TR 15504, называвшийся ранее Software Process Improvement Capability dEtermination (SPICE), регламентирует оценку в целом.

Стандарты качества. В 1994 году ISO выпустила набор стандартов и руководящих указаний ISO 9000. Документ ISO 9000-3 определяет их применение к программным продуктам. Расширенная версия этого стандарта ISO 9000:2000 в большей степени ориентирована на использование в корпоративной среде.

American Society for Quality предлагает свою версию ISO 9000 под названием Q9000 и TL 9000 для отрасли связи.

Стандарты измерения. Выпущенная в 2001 году версия Practical Systems and Software Measurement, содержащая указания по выполнению программ изменений, дополнена измерениями, направленными на совершенствование системной инженерии и процессов.

В 80-х годах компания Motorola выступила с программой качества Six Sigma, которая сейчас применяется к программным системам. Имеется много различных ее реализаций, поскольку ни один орган стандартизации не взял на себя адаптацию этого стандарта.

Другие стандарты и методики. Systems Security Engineering CMM (SSE-CMM), включающая в себя метод оценки — адаптированную версию SAM, расширяет SE-CMM процессами, ориентированными на безопасность. В 1995 году SEI выпустила People CMM, ориентированный на вопросы управления человеческими ресурсами.

Модель зрелости СММ

Предложенная в 1987 году модель Capability Maturity Model стала в наши дни стандартом де-факто для оценки качества процессов разработки программного обеспечения. CMM задает схему совершенствования процессов, которая базируется на постепенном развитии корпоративной культуры компании и предполагает поступательное движение «вверх» по пяти уровням зрелости процессов. Чем более высокого уровня зрелости достигает компания, тем более предсказуемыми и управляемыми становятся процессы и, как следствие, более качественно будут реализованы проекты.

Уровни модели CMM имеют следующие характеристики.

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

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