Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Технологическая зрелость IT-организаций

Технологическая зрелость IT-организаций

Модель технологической зрелости (СММ) — это описание стадий эволюции, которые проходят организации-разработчики по мере того, как они определяют, реализуют, измеряют, контролируют и совершенствуют процессы создания ПО. Эта модель помогает организации выбрать адекватную стратегию усовершенствования этих процессов, предоставляя методическую основу для определения текущего уровня их совершенства и выявления проблем, критичных для качества разрабатываемого ПО.

Рубеж 80–90-х годов двадцатого столетия принято считать началом информационно-технологической революции, давшей обществу такие инструменты, как персональный компьютер, локальные и глобальные вычислительные сети, мобильную связь, электронную почту и Internet. Успех информационных технологий во всех сферах человеческой деятельности очевиден, но отдаем ли мы себе отчет в том, какова реальная цена этого успеха и что есть обратная, скрытая от многих, сторона этой революции — «кризис» в области программного обеспечения, одной из главных составляющих информационных технологий?

По данным Standish Group [1] уже к середине 90-х годов упомянутый кризис принял «хронические» формы и выражался в следующих цифрах:

• США тратит ежегодно более $200 млрд. на более чем 170 тыс. проектов разработки ПО в сфере IT;
• 31,1% из них закрываются, так и не завершившись;
• 52,7% проектов завершаются с превышением первоначальных оценок бюджета/сроков и ограниченной функциональностью;
• потери от недополученного эффекта внедрения ПО измеряются триллионами.

История появления СММ

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

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

В конце концов, был сделан вывод, что фундаментальная проблема «хронического кризиса ПО» состоит в неспособности организаций управлять технологическим процессом разработки программного обеспечения [2]. И тогда военные приступили к поиску формальных и объективных методов оценки способности организации-разработчика произвести ПО требуемой сложности в установленные сроки и с требуемым уровнем качества. В результате целенаправленного и плодотворного сотрудничества министерства обороны США и Питтсбургского института программной инженерии (Software Engineering Institute — SEI) в 1993 г. появляется окончательная версия т. н. «Модели технологической зрелости организации-разработчика ПО» (Capability Maturity Model for Software — SW CMM). Не вдаваясь в изнурительную дискуссию о принципиальной невозможности однозначного перевода, здесь и далее по тексту используем достаточно свободную интерпретацию основных понятий СММ, стремясь (там, где это возможно) донести суть предмета в привычной или понятной для всех терминологии.

Что такое СММ

Модель технологической зрелости (СММ) согласно определению, приведенному в [3],— это описание стадий эволюции, которые проходят организации-разработчики по мере того, как они (организации) определяют, реализуют, измеряют, контролируют и совершенствуют процессы создания ПО. Эта модель помогает организации выбрать адекватную стратегию усовершенствования этих процессов, предоставляя методическую основу для определения текущего уровня их совершенства и выявления проблем, критичных для качества разрабатываемого ПО. В основу СММ положен ряд фундаментальных понятий [2, 3]:

• Технология, Технологический процесс, Процесс (Process) — последовательность шагов (действий), предпринимаемых с заданной целью [IEEE-Std-610].
• Совершенство технологии/процесса (Process Capability) — диапазон результатов, которые можно ожидать от организации, соблюдающей данный технологический процесс. Это понятие имеет отношение к будущим проектам, но базируется на фактических характеристиках технологии, достигнутых на предыдущих проектах.
• Характеристики технологии/ процесса (Process Performance) — фактические результаты, достигнутые организацией, соблюдающей данную технологию/процесс. Это понятие ассоциируется с уже выполненными проектами.
• Зрелость технологии (Process Maturity) — степень определенности, управляемости, наблюдаемости, контролируемости и эффективности данной технологии. Фактически, это индикатор полноты технологии и степени последовательности (настойчивости) организации в ее применении на всех проектах. Зрелость определяет потенциал дальнейшего роста совершенства технологии/процесса.

Пять уровней технологической зрелости

Разработчики модели СММ (SEI) определили пять уровней технологической зрелости, по которым заказчики могут оценивать потенциальных поставщиков (претендентов на получение контракта), а поставщики могут совершенствовать процессы создания ПО Каждому из показанных на рисунке уровней технологической зрелости внутри модели СММ дано следующее краткое определение:

Уровень 1: Начальный (Initial) — технология разработки ПО характеризуется как произвольная (импровизированная), в некоторых случаях — даже хаотическая. Лишь некоторые процессы определены, успех всецело зависит от усилий отдельных сотрудников.

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

Уровень 3: Определенный (Defined) — управленческие и инженерные процессы задокументированы, стандартизованы и интегрированы в унифицированную для всей организации технологию создания ПО. Каждый проект использует утвержденную, адаптированную к особенностям данного проекта, версию этой технологии.

Уровень 4: Управляемый (Managed) — детальные метрики (объективные данные) о качестве исполнения процессов и выходной продукции собираются и накапливаются. Управление процессами и выходной продукцией осуществляется по количественным оценкам.

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

Ключевые области процессов

Отличительная особенность СММ по сравнению с другими моделями и стандартами аналогичного назначения состоит в том, что в основе этой модели лежит последовательно- ступенчатое или поэтапное (staged) представление эволюции организации и ее технологии. В таком представлении организация осуществляет свое восхождение к высокой культуре производства, шаг за шагом поднимаясь на новую ступень (уровень) «лестницы» технологической зрелости. Руководствуясь этой идеей, разработчики СММ определили т. н. ключевые области процессов создания ПО (Key Process Areas) для каждого уровня зрелости (см. таблицу).

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

Ключевые области процессов создания ПО

Целевые установки и ключевые элементы практики

Еще одним важным элементом СММ являются т. н. целевые установки (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].

Критерии оценки уровня зрелости

Подводя итог, приведем в сжатом виде собственно критерии оценки соответствия организации тому или иному уровню зрелости:

• Целевые установки данной ключевой области процессов считаются удовлетворенными, если действующая в организации практика соответствует всем ключевым элементам практики СММ для данной области [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 по интеграции созданных ранее моделей:

• Software (SW) CMM для организаций-разработчиков ПО (именно она описана в статье);
• Systems Engineering (SE) CMM для организаций-разработчиков систем;
• Integrated Product Development (IPD) CMM для организаций-разработчиков интегрированных продуктов и технологий;
• Software Acquisition (SA) CMM для организаций-заказчиков ПО.
  Модель CMMI является ответом на стандарт ISO 15504, гармонизирована с ним и предоставляет пользователю на выбор два варианта представления: последовательно-ступенчатое (как в SW CMM) и сплошное (как в SPICE/ISO 15504).

Нужен ли нам СММ?

Информация к размышлению. Экономическая эффективность совершенствования процессов на основе СММ составляет в среднем $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 в Санкт-Петербурге (СМ-Консалт: эта информация уже немного устарела, помоимо Моторолы СММ есть у компании Люксофт).

Несмотря на то, что реальный успех многих организаций в борьбе с так называемым «кризисом разработки ПО» доказал жизнеспособность СММ, сегодня в Украине, как и в других странах бывшего СССР, эта модель практически не используется. Пришло время делать правильные выводы.

27.01.2008

Комментарии

• lwqroBXmcjJdXPAfMaG
  Автор: z4T2p3 , [url=http://iqatrzsdctrc.com/]iqatrzsdctrc[/url], [link=http://kobapdxgnzli.com/]kobapdxgnzli[/link], http://tjbevdakurec.com/  ·  09.11.2011 18:19:42
  z4T2p3 , [url=http://iqatrzsdctrc.com/]iqatrzsdctrc[/url], [link=http://kobapdxgnzli.com/]kobapdxgnzli[/link], http://tjbevdakurec.com/
• SCysgXmLgZSienG
  Автор: 2d7qMl wuqhduxvyyrc  ·  07.11.2011 13:31:40
  2d7qMl wuqhduxvyyrc
• IKUAJnCzMkqSnvyPFov
  Автор: VfjrSi , [url=http://fiykplmomnsk.com/]fiykplmomnsk[/url], [link=http://eekuqjurwiax.com/]eekuqjurwiax[/link], http://jrlgfcvzixkr.com/  ·  06.11.2011 17:23:29
  VfjrSi , [url=http://fiykplmomnsk.com/]fiykplmomnsk[/url], [link=http://eekuqjurwiax.com/]eekuqjurwiax[/link], http://jrlgfcvzixkr.com/
• aJpspargkjbuR
  Автор: q9QVE2 eobmyqwcxdis  ·  05.11.2011 19:29:20
  q9QVE2 eobmyqwcxdis
• EeDdMBQDuNMeSoOvmZJ
  Автор: Back in school, I'm doing so much leanrnig.  ·  05.11.2011 08:59:11
  Back in school, I'm doing so much leanrnig.
• 
  Автор:   ·  08.05.2011 18:34:34
  лучшая реклама на транспорте, качественно и недорого
• 
  Автор:   ·  08.05.2011 15:19:52
  Это рекламное агентство - лучший выбор
• 
  Автор: Lamakazzz  ·  10.03.2009 10:16:58
  Хорошая статья! еще бы добавить сюда о кластерах базовых практик (методик) менеджмента для уровней технологической зрелости

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"