| СТАТЬЯ |
29.11.02
|
© Ю.А. Назаренко, TelesensKSCL
Статья была опубликована журнале "Корпоративные
системы"
Модель технологической зрелости (СММ) — это описание стадий эволюции, которые проходят организации-разработчики по мере того, как они определяют, реализуют, измеряют, контролируют и совершенствуют процессы создания ПО. Эта модель помогает организации выбрать адекватную стратегию усовершенствования этих процессов, предоставляя методическую основу для определения текущего уровня их совершенства и выявления проблем, критичных для качества разрабатываемого ПО.
Рубеж 80–90-х годов двадцатого столетия принято считать началом информационно-технологической революции, давшей обществу такие инструменты, как персональный компьютер, локальные и глобальные вычислительные сети, мобильную связь, электронную почту и Internet. Успех информационных технологий во всех сферах человеческой деятельности очевиден, но отдаем ли мы себе отчет в том, какова реальная цена этого успеха и что есть обратная, скрытая от многих, сторона этой революции — «кризис» в области программного обеспечения, одной из главных составляющих информационных технологий?
По данным Standish Group [1] уже к середине 90-х годов упомянутый кризис принял «хронические» формы и выражался в следующих цифрах:
Еще в середине 70-х годов первые «симптомы» кризиса ощутили на себе военные заказчики США, столкнувшиеся с взрывоподобным ростом объема и сложности задач, возлагаемых на программное обеспечение, который был вызван появлением новейших (по тем временам) средств вычислительной техники. Новые грандиозные проекты требовали привлечения все новых и новых ресурсов для их реализации. Сроки выполнения проектов постоянно срывались, качество ПО (соответствие ожиданиям заказчика) оставалось на неприемлемо низком уровне, и Министерство обороны США начало всерьез беспокоиться об эффективности расходования бюджетных средств.
В этой ситуации, осознав реальность угрозы потери крупных заказов, многие организации-разработчики направили усилия на поиск эффективных методологий и инструментов для разрешения «сугубо технических» (как тогда казалось) проблем программного обеспечения. Почти два десятилетия обещаний поднять производительность и качество работ за счет новых методов и средств разработки ПО ушло на осознание того, что корень зла — не в технике.
В конце концов, был сделан вывод, что фундаментальная проблема «хронического кризиса ПО» состоит в неспособности организаций управлять технологическим процессом разработки программного обеспечения [2]. И тогда военные приступили к поиску формальных и объективных методов оценки способности организации-разработчика произвести ПО требуемой сложности в установленные сроки и с требуемым уровнем качества. В результате целенаправленного и плодотворного сотрудничества министерства обороны США и Питтсбургского института программной инженерии (Software Engineering Institute — SEI) в 1993 г. появляется окончательная версия т. н. «Модели технологической зрелости организации-разработчика ПО» (Capability Maturity Model for Software — SW CMM). Не вдаваясь в изнурительную дискуссию о принципиальной невозможности однозначного перевода, здесь и далее по тексту используем достаточно свободную интерпретацию основных понятий СММ, стремясь (там, где это возможно) донести суть предмета в привычной или понятной для всех терминологии.
Модель технологической зрелости (СММ) согласно определению, приведенному в [3],— это описание стадий эволюции, которые проходят организации-разработчики по мере того, как они (организации) определяют, реализуют, измеряют, контролируют и совершенствуют процессы создания ПО. Эта модель помогает организации выбрать адекватную стратегию усовершенствования этих процессов, предоставляя методическую основу для определения текущего уровня их совершенства и выявления проблем, критичных для качества разрабатываемого ПО. В основу СММ положен ряд фундаментальных понятий [2, 3]:
Разработчики модели СММ (SEI) определили пять уровней технологической зрелости, по которым заказчики могут оценивать потенциальных поставщиков (претендентов на получение контракта), а поставщики могут совершенствовать процессы создания ПО Каждому из показанных на рисунке уровней технологической зрелости внутри модели СММ дано следующее краткое определение:
Уровень 1: Начальный (Initial) — технология разработки ПО характеризуется как произвольная (импровизированная), в некоторых случаях — даже хаотическая. Лишь некоторые процессы определены, успех всецело зависит от усилий отдельных сотрудников.
Уровень 2: Повторяемый (Repeatable) — базовые процессы управления проектом ПО установлены для отслеживания стоимости, графика и функциональности выходного продукта. Необходимая дисциплина соблюдения установленных процессов имеет место и обеспечивает возможность повторения успеха предыдущих проектов в той же прикладной области.
Уровень 3: Определенный (Defined) — управленческие и инженерные процессы задокументированы, стандартизованы и интегрированы в унифицированную для всей организации технологию создания ПО. Каждый проект использует утвержденную, адаптированную к особенностям данного проекта, версию этой технологии.
Уровень 4: Управляемый (Managed) — детальные метрики (объективные данные) о качестве исполнения процессов и выходной продукции собираются и накапливаются. Управление процессами и выходной продукцией осуществляется по количественным оценкам.
Уровень 5: Оптимизируемый (Optimized) — совершенствование технологии создания ПО осуществляется непрерывно на основе количественной обратной связи от процессов и пилотного внедрения инновационных идей.
Отличительная особенность СММ по сравнению с другими моделями и стандартами аналогичного назначения состоит в том, что в основе этой модели лежит последовательно- ступенчатое или поэтапное (staged) представление эволюции организации и ее технологии. В таком представлении организация осуществляет свое восхождение к высокой культуре производства, шаг за шагом поднимаясь на новую ступень (уровень) «лестницы» технологической зрелости. Руководствуясь этой идеей, разработчики СММ определили т. н. ключевые области процессов создания ПО (Key Process Areas) для каждого уровня зрелости (см. таблицу).
В СММ ключевые области процессов — это кластеры взаимосвязанных видов работ коллектива участников проекта, надлежащее исполнение которых существенно важно для соответствия данному уровню зрелости технологии. Это означает, что для организации, стремящейся выйти на данный уровень зрелости, исключительное значение имеют только соответствующие этому уровню области процессов. Это также означает контрпродуктивность попыток «перепрыгивания» через уровни зрелости, ибо каждый нижестоящий уровень образует фундамент для перехода к следующему.
|
Уровень
|
Фокус организации
|
Ключевые области процессов
|
| 5 - Оптимизируемый | Непрерывное совершенствование процессов |
Предупреждение дефектов Управление изменениями в технологиях* Управление изменениями в процессах |
| 4 - Управляемый | Качество продукции и процессов |
Количественное управление процессами Менеджмент качества ПО |
| 3 - Определенный | Инженерные процессы и организационная поддержка |
Фокус организации на процессах Определение процессов в организации |
| 2 - Повторяемый | Управление проектом |
Управление требованиями Планирование проекта ПО |
| 1 - Начальный | Компетентность специалистов, самопожертвование и героизм** | |
|
* В данном случае речь идет как раз об инструментально-техническом
аспекте понятия технология (Technology vs. Process). |
||
Еще одним важным элементом СММ являются т. н. целевые установки (Goals), определенные для каждой из перечисленных ранее ключевых областей процессов. Целевые установки концентрированно выражают ключевую область процессов в терминах того, что организация должна практиковать в данной области, определяют ее суть, объем и границы (пример целевых установок для ключевых областей процессов организации 2-го уровня приведен в приложении).
Необходимым условием признания данной области процессов, как удовлетворяющей требованиям СММ, является соответствие действующей в организации практики целевым установкам этой области. Для того чтобы определить, выполняются ли реально целевые установки ключевых областей процессов, в СММ для каждой такой области определены т. н. ключевые элементы практики, структурированные по следующим стандартным категориям.
Обязательность исполнения (commitment to perform). Элементы практики этой категории содержат мероприятия, предпринимаемые организацией для обеспечения того, что процессы данной области установлены и неукоснительно соблюдаются. Как правило, это включает установление политики организации в данной области и надлежащую поддержку со стороны руководства.
Возможность исполнения (ability to perform). Элементы практики этой категории регламентируют необходимые условия, которые должны существовать в проекте или в организации для надлежащего исполнения соответствующих процессов. Обычно сюда включаются такие элементы практики, как привлечение необходимых ресурсов, наличие оргструктуры выполнения работ, обучение персонала.
Выполняемые работы (activities performed). Элементы практики этой категории включают описание ролей (исполнителей) и процедур выполнения процессов данной области. Выполняемые работы – это, как правило, планирование и определение процедур, собственно выполнение работ, их отслеживание, проведение необходимых корректирующих мероприятий.
Измерения и анализ (measurements and analysis). Элементы практики этой категории содержат планирование и проведение необходимых количественных измерений, а также анализ фактически достигнутых характеристик процессов данной области.
Верификация исполнения (verifying implementation). Элементы практики этой категории включают шаги, предпринимаемые организацией для подтверждения того, что работы в данной области выполняются в соответствии с установленной технологией. Верификация обычно включает проведение проверок и аудитов со стороны руководства и служб обеспечения качества.
В отличие от целевых установок, ключевые элементы практики (детально они описаны в [3]) не являются нормативными требованиями СММ и носят рекомендательный характер. Это означает, что при проведении самооценки уровня технологической зрелости, организации вполне могут применять собственные корпоративные стандарты, отнесенные к указанным ранее категориям. Единственным нормативным требованием в этом случае является адекватность этих стандартов соответствующим целевым установкам, приведенным в документе CMU/SEI-93-TR-025 «Key Practices of the Capability Maturity Model, Version 1.1» [3].
Подводя итог, приведем в сжатом виде собственно критерии оценки соответствия организации тому или иному уровню зрелости:
Логика оценки по СММ достаточно жесткая, можно даже сказать «бинарная», но в отличие от, например, стандартов серии ISO 9000, именно такая логика позволяет однозначно идентифицировать технологическую зрелость организации и достаточно точно диагностировать «узкие» места в ее повседневной практической деятельности.
По данным SEI [4] c момента появления прототипа СММ в 1987 г. по июнь 2001 г. проведено 1970 оценок технологической зрелости 1505 организаций в США и по всему миру. К проведению оценок привлекались независимые эксперты из 408 компаний. Обследованию подверглось 8134 проекта. За этот же период 379 организаций несколько раз прошли повторную оценку. По данным того же источника за последние три года оценку по СММ прошли 1018 организаций, 36,3% которых расположены за пределами США. География распространения СММ по состоянию на июнь 2001 г. охватывает более 45 стран мира.
ISO 9000. Многие организации-разработчики и заказчики ПО успешно используют широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии вышла в 2000 году и содержит в себе такие понятия, как процессы и совершенствование процессов, заимствованные из модели СММ и отсутствовавшие в предыдущих версиях ISO 9000. Следует, однако, заметить, что стандарты этой серии универсальны, не ориентированы на какую-либо конкретную отрасль и не учитывают специфики IT-сферы. Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия и, тем самым, затрудняет определение «истинных» возможностей той или иной организации (соответственно, и путей их дальнейшего развития).
SPICE/ISO15504. Другой альтернативой является модель SPICE (Software Process Improvement and Capability dEtermination) [5] и ее развитие — проект международного стандарта ISO 15504 [6]. Они сделаны на основе СММ и при непосредственном участии того же SEI. Отличительной особенностью SPICE/ISO15504 по сравнению с оригиналом является уход от последовательно-ступенчатого (staged) представления и самого понятия технологической зрелости (process maturity). Модель SPICE/ISO15504 (как и ISO 9000) не выделяет ключевых областей процессов, а лишь устанавливает общие и индивидуальные показатели уровня совершенства для всех процессов подряд. Организации, которая использует SPICE/ISO 15504, по всей видимости, будет не лишним обратиться к СММ для определения приоритетов своего развития.
CMMI. Наконец, еще одна альтернатива CMM for Software версии 1.1 — новая
интегрированная модель технологической зрелости CMMI [7].
Эта модель является результатом усилий Питтсбургского SEI по интеграции созданных
ранее моделей:
Информация к размышлению. Экономическая эффективность совершенствования процессов на основе СММ составляет в среднем $5 прибыли на каждый $1 вложений. По последним данным SEI [8] на октябрь 2001 г. в мире насчитывалось 139 организаций-разработчиков ПО высокого уровня зрелости (73 — четвертого и 66 — пятого уровня). Из общего числа высокоуровневых организаций 80 находятся за пределами США: Австралия — 2 организации (4-го уровня); Китай — 2 (5); Франция — 1 (4); Индия: 72 организации (!), из них 29 (4) и 43 (5); Израиль — 1 (4); Сингапур — 1 (4). В России уже есть одна организация, сертифицированная по пятому уровню СММ — Центр разработок фирмы Motorola в Санкт-Петербурге.
Несмотря на то, что реальный успех многих организаций в борьбе с так называемым «кризисом разработки ПО» доказал жизнеспособность СММ, сегодня в Украине, как и в других странах бывшего СССР, эта модель практически не используется. Пришло время делать правильные выводы.
«На каком же уровне зрелости находится моя организация?»
Такой вопрос после прочтения статьи, возможно, зададут себе многие руководители и профессионалы IT-индустрии. Зеркальный вопрос в отношении своего поставщика может задать и руководитель организации-заказчика ПО: «Я уже работаю с ними столько лет и постоянно имею проблемы. На каком же уровне зрелости они находятся?» Конечно, лучшим вариантом для получения однозначного и непредвзятого ответа на этот вопрос, а также детальных развернутых рекомендаций на тему «что же теперь делать», является привлечение квалифицированных независимых консультантов со стороны. Тем не менее, для получения быстрого «среза» общей ситуации хорошо осведомленный в делах своих подчиненных руководитель в состоянии дать самому себе ответ на вопрос, выполняет ли его команда целевые установки СММ хотя бы 2-го уровня зрелости? Вот эти установки:
Управление требованиями
Планирование проекта ПО
Отслеживание и контроль проекта ПО
Управление субподрядом
Обеспечение качества ПО
Конфигурационное управление ПО
Отсутствие видимых доказательств устойчивого исполнения в организации хотя бы одной из приведенных целевых установок СММ свидетельствует о том, что она пока не достигла 2-го уровня зрелости. Те целевые установки 2-го уровня СММ, с которыми «не все в порядке», и есть те самые приоритеты, определяющие, к чему должна стремиться организация.
Дополнительные материалы
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
