Искусство бюрократии

Чтобы умно поступать одного ума мало.
Ф. М. Достоевский

В 1987 г. после 20 лет активного использования компьютерных технологий Министерство обороны США пришло к выводу, что главная причина слишком частых неудач при разработке крупных информационных проектов заключается прежде всего в отсутствии менеджеров управления процессом создания качественного ПО. Менеджеры постоянно работали в режиме аврала, сроки откладывались все дальше, бюджет проекта разбухал, а качество продукта можно было предсказать только в сторону ухудшения. Тестирование не спасало - обнаруживались ошибки, для ликвидации которых требовалось переписывать всю систему с нуля. В организациях, где царил хаос (американцы употребляют термин undisciplined), не помогали ни CASE-системы, ни дорогие средства программирования, ни самые опытные руководители и консультанты. Если иногда все же удавалось реализовать проект среднего размера с удовлетворительным качеством, то это была заслуга исключительно отдельных высококлассных специалистов. При получении следующего заказа вновь возникала проблема подбора персонала. Точно так же сегодня многие (если не все) российские компании, разрабатывающие ПО, жалуются на отсутствие грамотных менеджеров проектов, хотя корень неудач лежит в методологии разработки программ (точнее, в ее отсутствии). Есть прекрасные программисты, есть специалисты по проектированию ПО, по постановке задачи, есть бизнес-консультанты, но простое объединение всех их в команду во главе с самым лучшим менеджером проекта не дает никаких гарантий, что эта команда создаст качественный продукт. Нет в России ни одной организации, способной научить программистскую фирму, как своими силами организовать выпуск качественного ПО. Огромная ниша между бизнес-консалтингом и аутсорсингом в нашей стране совершенно пуста.

Но можно ли вообще гарантировать реализацию проекта в заданный срок с заданным бюджетом и высоким качеством? Практика показала, что можно. Имеется специальная методика, которой сегодня успешно пользуются многие крупнейшие зарубежные компании, выполняющие большие информационные заказы. В ее основе лежит управление процессами создания качественного ПО (ПСПО). Такой процесс может быть определен как набор организационных процедур, действий и методов, используемых менеджерами для управления разработкой, тестированием и сопровождением качественного ПО. Совершенствуя ПСПО, фирма может неограниченно повышать качество своих продуктов при среднем уровне квалификации менеджеров и программистов. Пойди туда - не знаю куда В конце 1987 г. Институт программной инженерии США (Software Engineering Institute, SEI) в сотрудничестве с корпорацией Mitre выпустил небольшую инструкцию, посвященную способам управления ПСПО. Тогда эта работа была воспринята скорее как очередная технология проектирования (вроде формальных методик IDEF), чем как средство улучшения качества ПО. Но SEI продолжил свои исследования, проанализировал процессы разработки множества больших КИС в разных компаниях и госструктурах и за четыре года создал модель зрелости Capability Maturity Model for Software (CMM, последняя версия - 1.1), с помощью которой удается обеспечить эффективное управление ПСПО. Соответствие уровням CMM означает, что компания созрела для новых свершений в программной индустрии.

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

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

CMM позволяет также точно оценить ПСПО и на этой основе сравнить производительность различных компаний. В CMM включен набор критериев для определения зрелости ПСПО. Эти критерии используются крупными заказчиками для оценки риска при заключении контрактов на разработку ПО.

Международная организация по стандартизации ISO применяет CMM для создания международных стандартов оценки ПСПО. Но сама CMM - не стандарт и не может им быть. Например, фирма, стоящая на нижней ступени иерархии CMM, способна выпускать ПО в соответствии с ISO 9001, но достигается это благодаря титаническим усилиям нескольких талантливых менеджеров и программистов. В таких случаях говорят: "У фирмы Х сильная команда". В идеале эта фраза должна звучать так: "Х - сильная фирма!".

CMM имеет мало общего с практическими методиками управления качеством (во всем мире их насчитывается около 150 тыс.), хотя и базируется на разработанных в последние 60 лет пяти стадиях контроля за качеством. Эти методики обычно жестко регламентированы и основаны на статистическом контроле за продуктом в соответствии с требованиями множества различных нормативов, а CMM не содержит никаких численных критериев и рекомендаций и не указывает, как оценить продукт, а только рекомендует, что надо сделать, чтобы он обладал необходимым качеством.

Наиболее близко CMM стоит к общефирменной системе управления качеством TQM Ф. Кросби, которая считается целой философией (как и CMM), настолько она сложна. Однако принципиальное отличие TQM от CMM в том, что TQM ориентирована на области, не связанные с программированием, поэтому компьютерным фирмам не удается эффективно использовать TQM из-за слишком специфического понятия "качество ПО". Кроме того, TQM большое значение придает человеческому фактору, бизнес-планированию и другим вещам, которые CMM не рассматривает. И это все работает?

CMM иногда подвергается критике за то, что она сложна и для понимания, и для практического использования. Как выразился один из пользователей CMM, она слишком "неформально формальна". Однако пока ничеголучшего в области управления ПСПО не придумано, а практика показала, что внедрение CMM дает очень большой эффект.

CMM чаще всего применяется при реализации крупных проектов, когда заказчиками выступают организации, требующие от исполнителя особо высокой надежности и качества ПО (как правило, военные и государственные структуры), поэтому работы по развитию CMM спонсируются Пентагоном. Американская компания не получит от правительства серьезный заказ, если она не прошла в SEI тестирование на соответствие как минимум третьему (из пяти) уровню CMM: программистская фирма, сертифицированная по третьему уровню, считается фирмой мирового класса. Пятому же уровню к осени 1997 г. соответствовало только пять компаний (программное отделение Boeing в Сиэтле, индийское отделение Motorola в Бангладеш и еще три другие). Интересно, что Microsoft неоднократно опровергала предположения, что она использует CMM. В оправдание Microsoft надо заметить, что применение CMM наиболее эффективно в компаниях с высоким уровнем бюрократии, когда многие процессы управления жестко формализованы.

Компании сертифицируются институтом SEI (Software Engineering Institute) по пяти уровням зрелости (УЗР), каждый из которых описывается в модели CMM (Common Maturity Model) набором целевых критериев. Эти критерии определяют, что компания должна делать, чтобы ее процессы создания ПО (ПСПО) обеспечивали надлежащее качество проекта. Фактически оценке подвергается не компания или продукты, а проекты, то есть определяется, насколько профессионально компания способна разрабатывать ПО. Чтобы компания соответствовала тому или иному УЗр, требуется, чтобы все ее проекты соответствовали этому уровню. В понятие проекта входит, конечно, не только разработка ПО, но и его сопровождение. Пять уровней CMM Первый уровень. ПСПО фирмы никак не организованы, и реальные попытки их улучшения не предпринимаются. Практически 99% отечественных программистских компаний соответствуют этому уровню. Успех проектов зависит только от индивидуальных способностей сотрудников, и обычно ни сроки, ни бюджет не укладываются в заданные границы. Сам проект представляет собой "черный ящик", когда известно только, что есть "на входе" (число программистов и их примерная производительность) и что должно быть на "выходе" (продукт в соответствии с техническим заданием).

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

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

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

Этот уровень характеризуется тем, что в фирме должна быть создана специальная группа софт-инжиниринга (software engineering process group). Теперь и менеджеры, и программисты понимают, как будут реализовываться программные блоки системы, потому что их внутренняя структура формализуется в соответствии с требованиями CMM. Каждый сотрудник - от кодировщика до руководителя - точно знает, что он должен сделать.

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

Четвертый уровень. Все ПСПО компании могут быть использованы для работы над программными проектами разной тематики. Процессы оценены по множеству критериев, максимально документированы и легко управляемы. Фактически они превращены в рабочие инструменты.

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

Фирма создает базу данных по используемым ПСПО и постоянно ее анализирует. От подобного формализованного опыта существенно зависит снижение сроков и затрат на проект. Менеджеры не только в деталях понимают структуру проекта, но и сами начинают управлять ПСПО.

Пятый уровень. На этом уровне компания осуществляет непрерывную и неограниченную оптимизацию своих ПСПО. Для каждого процесса определены сильные и слабые стороны и наиболее подходящие области применения. При работе над проектом менеджеры постоянно улучшают используемые процессы, причем степень улучшения поддается количественной оценке. В ПСПО вносятся новые идеи и технологии, анализируются и исправляются ошибки. Менеджеры не просто понимают процессы, но и осознают возможные пути повышения их эффективности. Описание уровней CMM Каждый УЗР (за исключением, конечно, первого) описывается областями ключевых процессов (ОКП), определяющими ключевые цели и действия для их достижения. Если эти действия по руководству проектами не будут исполняться, ПСПО компании не обеспечат требуемое качество ПО. Цель ОКП считается достигнутой при успешном завершении всех ориентированных на нее действий. Для сертификации компании требуется, чтобы были достигнуты все цели каждой ОКП. Какими способами, с помощью каких технологий фирма будет выполнять эти действия, значения не имеет. Некоторые ОКП уровней 2 -5 УЗР 2. Подбор сотрудников, учет производительности их труда и документирование обязанностей; контроль за соответствием создаваемого продукта требованиям заказчика; контроль качества в соответствии с внутрифирменными стандартами; контроль за работой над проектами; планирование проектов, определение их объемов и требуемых ресурсов.

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

УЗР 4. Управление качеством, производительностью и эффективностью ПСПО на базе их количественных характеристик. На этом уровне цели имеют числовые эквиваленты (реальные примеры: продукт должен иметь не более одной ошибки на 10000 строк кода; отклонение продолжительности проекта от запланированной не должно превышать 3%), поэтому менеджеры способны точно оценить результаты своих решений. Влияние любых побочных воздействий оценивается перед началом проекта.

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

УЗР 5. Непрерывное глобальное улучшение ПСПО. При этом процессы изменяться могут как постепенно, так и резко; предупреждение ошибок во избежание их повторения в будущем; управление технологиями - эффективность новых технологий оценивается количественно, и они легко интегрируются в ПСПО. Интересно, что даже творческое озарение и уникальные открытия на пятом уровне можно оценить численно и включить в план! Такие возможности дают компании огромное конкурентное преимущество.

Уровень зрелости компании - уровень взаимопониманиЯ между менеджерами и программистами

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

Переход от уровня к уровню занимает несколько лет. Чтобы перейти на второй уровень, надо стремиться формализовывать удачные ПСПО. Ключевую роль здесь играют менеджеры, которые должны собирать и документировать нужную информацию. На УЗР 2 начинается улучшение ПСПО, на УЗР 3 - интеграция процессов, анализ и обобщение результатов успешных проектов.

Четвертый и пятый уровни редко встречаются в индустрии ПО. По данным журнала CrossTalk, на май 1997 г. из 533 американских фирм, выполняющих крупнейшие коммерческие, государственные и военные заказы, к УЗР 1 относилось 328 фирм, к УЗР 2 - 124, к УЗР 3 - 70, к УЗР 4 - 9 и к УЗР 5 - только две компании. Для достижения этих уровней CMM требуется десять и более лет. Но даже УЗР 3 позволяет смело выходить на международную арену. Самое главное - для использования CMM компании не надо искать сотрудников с какими-то уникальными способностями, достаточно понять общую идею. Как уже говорилось, в руководстве, включающем все ОКП и другую информацию, детально описано, что надо делать, чтобы развиваться в соответствии с моделью CMM. Следовать регламентированным действиям CMM способен любой менеджер среднего класса. Что дальше? Текущая версия CMM 1.1 ориентирована на крупные компании, занимающиеся реализацией очень больших проектов. Но она вполне может использоваться группами из двух-трех человек или отдельными программистами для выполнения небольших проектов (продолжительностью до трех месяцев). В таких случаях CMM может сыграть жизненно важную рольпоскольку поступление новых заказов во многом определяется качеством ранее реализованных проектов. Небольшие группы вполне удовлетворятся уровнем 2, так как для небольшого проекта отклонение от срока на пару недель непринципиально. Тем не менее сейчас заканчивается работа над специальной версией SA-CMM 1.01 (Software Acquisition Capability Maturity Model) для небольших фирм, групп программистов и индивидуальных разработчиков.

В следующей, второй версии CMM модель развития будет существенно пересмотрена. Не потому, что текущее описание некорректно, просто SEI как организация пятого уровня зрелости постоянно улучшает CMM и разработала новую, более эффективную модель. В ней изменятся все уровни (с сохранением преемственности), более комплексно будут определены ОКП УЗР 2 и 3, но основной акцент будет сделан на УЗР 4 и 5 как наиболее актуальные для активно развивающейся американской индустрии ПО. Небольшой пример Группа оборонно-космических проектов компании Boeing, сертифицированная летом 1996 г. по пятому уровню CMM, выполняла заказ Минобороны США по разработке и обеспечению полного жизненного цикла ПО для системы космической транспортировки оборудования и пристыковки грузовых модулей. Это ПО использовалось как на наземных станциях слежения, так и в бортовых компьютерах космических аппаратов. Когда группа обладала УЗР 4, во время разработки выявлялось 89% ошибок (из них 70% - на этапе тестирования). Теперь выявляются практически все ошибки, причем на ранних стадиях, а за полгода, прошедщие после сертификации по УЗР 5, субъективная оценка пользователями качества ПО возросла с 97% до 100%.

Описание CMM и различные комментарии можно найти на узле www.sei.cmu.edu.