Что такое качественный программный продукт? Простейший ответ — продукт без ошибок. Но этот идеал практически недостижим: за полвека существования индустрии программного обеспечения разработчики так и не научились создавать программы, свободные от ошибок. Тем актуальней поиск методов и инструментов, помогающих приблизиться к идеалу. Например, растет популярность модели Capability Maturity Model, позволяющей оценивать зрелость процессов разработки.

Теория менеджмента качества проводит прямую зависимость между уровнем процессов создания продукта и качеством результата. В России и во всем мире растет популярность Capability Maturity Model (CMM) — модели, предназначенной для оценки зрелости процессов разработки.

Введение в CMM

Универсальная концепция качества Total Quality Management (TQM) была сформулирована в 50-е годы в Японии и к началу 80-х получила признание в западной индустрии. TQM устанавливает общие принципы, следование которым позволяет компаниям формировать организационную культуру, обеспечивающую создание качественных продуктов и сервисов. Эти основы менеджмента качества подверглись расшифровке и детализации в различных моделях качества, среди которых наиболее широкое применение получила серия стандартов ISO 9000.

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

Семен Мильман: «Отечественная программная индустрия страдает от отсутствия целенаправленной стратегии продвижения идей CMMI»

Претензии потребителей к качеству программных продуктов обусловили необходимость в создании специфической для этой отрасли модели управления качеством. Первым заказчиком стало Министерство обороны США, которое забило тревогу в связи с огромным количеством проблем, возникающих при использовании программных систем военного назначения. Разработкой модели занялся институт Software Engineering Institute университета Карнеги-Меллона. В 1991 году появилась первая версия модели зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software, CMM-SW).

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

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

Развитие CMM и расширение областей ее применения привело к появлению в 2001 году нового варианта модели — Capability Maturity Model Integration (CMMI). Она описывает уровни зрелости процессов не только для программной, но и для системной инженерии, интегрированной разработки продуктов и процессов, выбора поставщиков. К настоящему времени SEI перестал поддерживать модель CMM, и сертификация компаний проводится только по CMMI.

Кому нужна модель CMM?

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

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

Почему же не все разработчики идут на внедрение принципов процессных моделей CMM/CMMI? Дело в том, что для выстраивания процессов требуются очень серьезные усилия, время и, главное, материальные вложения. Дмитрий Дахновский, управляющий директор компании RUSSEE, которая занимается консалтингом и обучением по CMMI, сравнивает подготовку к сертификации по CMM/CMMI с внедрением на предприятиях ERP-систем. Часто эта задача решается с привлечением внешних консультантов.

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

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

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

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

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

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

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

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

Изучение модели

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

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

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

По данным RUSSEE, на начало нынешнего года 17 российских компаний получили сертификацию на соответствие разным уровням CMM/CMMI, а еще четыре готовятся к сертификации. В стране уже есть уникальный опыт получения высших уровней по обеим моделям, CMM и CMMI (компании Luxoft и Петербургский Центр разработки программного обеспечения компании Motorola), а сертификация компании Luxoft по пятому уровню CMMI была первой в Европе. Это означает, что в стране накоплен достаточный опыт для квалифицированной передачи знаний по CMMI, но необходима стратегическая программа формирования учебной инфраструктуры, позволяющая как повышать квалификацию специалистов, так и развивать академическое образование в области ИТ.

Уровни зрелости CMMI

Уровень 1: начальный (initial). Четкая организация процессов отсутствует, процессы непредсказуемы, нет определенных правил и процедур разработки, успех программных проектов обычно является заслугой отдельных лиц.

Уровень 2: управляемый (managed). Процессы определяются и документируются, но они сфокусированы на организации конкретного проекта, то есть не стандартизованы и могут различаться в разных проектах.

Уровень 3: определенный (defined). Во всех проектах процессы следуют заданному корпоративному стандарту, так называемому стандартному процессу организации.

Уровень 4: управляемый на базе количественных показателей (quantitatively managed). Процессы становятся предсказуемыми и появляется возможность управлять такими параметрами проекта, как количество ошибок, трудоемкость, объем переработок и т.д.

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

Опыт RUSSEE

Пионером систематизированного обучения отечественных разработчиков международным стандартам на организацию создания программных продуктов можно считать компанию RUSSEE, которая является официальным представителем в России института Institute for Software Research International (ISRI) Университета Карнеги-Меллона. В начале 1990-х ISRI в тесном сотрудничестве с SEI разработал магистерскую программу для менеджеров программных проектов, которая ассимилировала в себя все основные идеи, понятия и принципы модели CMM.

В RUSSEE взяли один из ее основных предметов, Managing Software Development, и создали компактный вариант, рассчитанный на обучение «без отрыва от производства». Получившаяся в результате программа «Руководитель команды разработки ПО» состоит из шести двухдневных семинаров:

  • управление техническими требованиями;
  • планирование и управление изменениями;
  • контроль над качеством;
  • управление рисками;
  • проектная оценка;
  • управление разработчиками.

Каждая сессия сочетает в себе лекционный материал и практические упражнения (в том числе домашние задания, разбор практических примеров и выполнение заданий в командах) в соотношении 50 на 50. До сих пор RUSSEE опиралась преимущественно на преподавателей Карнеги-Меллона, но с нынешнего года для всех курсов подготовлены и сертифицированы российские инструкторы. Впрочем, опыт одного из семинаров, «Управление требованиями», подтвердил, что для российских разработчиков английский язык является вполне естественной средой получения информации.

По словам Дмитрия Дахновского, эта программа прямо-таки пронизана идеями CMM/CMMI, и в случае внедрения какой-либо компанией всех рекомендаций, которые приводятся во время семинаров, она с легкостью прошла бы сертификацию минимум по второму уровню модели. Практически на каждом семинаре большой тематический блок связан со сбором и анализом метрик в данной области процессов разработки — это необходимые условия для реализации статистического контроля над процессами, которым характеризуется четвертый уровень зрелости в модели CMMI. В RUSSEE читается и официальный вводный курс Software Engineering Institute по CMMI.

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

В RUSSEE намерены расширять спектр предметов обучения и на следующий год запланирована адаптация университетского семестрового курса по архитектуре программного обеспечения. По словам Дахновского, несмотря на технологическую направленность программы, она будет независимой от поставщиков инструментария. Этому принципу следуют все курсы Карнеги-Меллона в RUSSEE, хотя в качестве иллюстраций могут рассматриваться и конкретные продукты. Например, в рамках семинара по управлению требованиями компания Borland проводит презентацию своей системы CaliberRM. Ведутся переговоры с IBM о возможности представления на семинарах продуктов линейки Rational.

В компании понимают, что программа второго высшего образования, каковой и является исходная программа Университета Карнеги-Меллона, может представлять интерес для фундаментального ИТ-образования в России. Ее реализация в вузах связана с рядом серьезных проблем, прежде всего с жесткой лицензионной политикой американского университета, а также со сложностью подготовки преподавательских кадров в России по этой программе. Ведутся переговоры с факультетом бизнес-информатики Высшей школы экономики о введении в ней одного из курсов программы по архитектуре программного обеспечения. Кроме того, в RUSSEE намерены использовать свое членство в АПКИТ для совершенствования уровня подготовки разработчиков и менеджеров процессов разработки в российских вузах.