Если Вы не можете описать то, что Вы делаете как процесс, Вы не знаете то, что Вы делаете. (Э. ДЕМИНГ)
ISO 9000, CMM, CMMI - что выбрать?
В.Ильин.
Руководитель Службы качества Компании TopSBI
"Если делаешь что-нибудь
неправильно - не нужно
рассчитывать на правильный результат."
Народная китайская мудрость
Комплексное решение задач обеспечения качества программных средств предполагает разработку и внедрение той или иной системы управления качеством (Системы Менеджмента Качества - СМК). В мировой практике наибольшее распространение получила именно система, основанная на требованиях международных стандартах серии ISO 9000, потому что она определяет именно наиболее общие требования, и к ПС в том числе, и тем самым, в целом, уже предопределяет ту начальную зрелость процессов, которая необходима для соответствия многим отраслевым моделям и стандартам в ИТ - области.
Но на вопрос, гарантирует ли внедрение системы качества и успешная сертификация выпуск качественного продукта, необходимо ответить честно - "нет".
Подчеркивая, что ISO 9000 - "превосходная идея", Gartner Group рекомендует рассматривать сертификацию на ISO 9001 только, как исходную точку на пути к качеству {1}.
Он закладывет как-бы "скелет" системы качества, а наполнение этой системы "мышцами" ( профессиональным содержанием на основе уже специальных, отраслевых стандартов и методологий, как, например CMM ) может обеспечить уровень качества, соответствующий растущим требованиям рынка.
В связи с вышеизложенным и с методологической, и с практической точек зрения многие специалисты в области менеджмента качества считают целесообразным строить стратегию развития ИТ-компаний следующим образом:
Сначала разработать и внедрить СМК по модели ISO 9001:2000. (Ведь большинство компаний, которые сейчас находятся на 4-ом и 5-ом уровнях SW-CMM, сначала прошли через приведение своих процессов в соответствие по модели ISO. Как показывает практика, это оптимальный вариант в плане управления развитием СМК и снижения рисков).
И только затем начать разрабатывать и внедрять ключевые процессы модели SW-CMM и далее, при необходимости, модели CMMI.
Для того, чтобы понять, насколько это действительно правильно, проведем сравнение этих моделей.
1. Обзор претендентов.
Проведем краткий обзор наиболее популярных стандартов, которые могут быть использованы ИТ-компанией для оптимизации своих бизнес-процессов.
ISO 9001. Наиболее популярным, и особенно, в Европе, является ISO 9001 {2}
При этом методически, в полном соответствии с дисциплиной построения сложных систем, стандарт ISO 9001 предусматривает, с одной стороны, построение организационной системы "сверху вниз": от целей предприятия и его политики - к организационной структуре и формированию бизнес процессов, и с другой - итеративное развитие организационной системы через механизмы измерения и улучшения.
Упрощенно "качество", согласно серии стандартов ISO 9000, это ситуация, при которой потребители получают от производителя продукцию соответствующую их прямым требованиям и подспудным ожиданиям. Поэтому управление качеством, в соответствии с ISO 9000, предполагает применение т.н. "процессного подхода", когда моделируется и внедряется наиболее оптимальная цепь "преобразований-процессов", гарантирующая, что потребности потребителей воспринимаются производителем и воплощаются в любой продукт без искажений.
Многие организации -разработчики ПО успешно используют именно эту широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии вышла в 2000 году и уже содержит в себе такие понятия, как процессный подход, анализ и измерения, совершенствование процессов, заимствованные из модели СММ и ранее отсутствовавшие в предыдущих версиях ISO 9000. Правда, следует заметить, что стандарты этой серии универсальны - они не ориентированы на какую либо конкретную отрасль, не учитывает специфики IT-сферы и, в этом смысле, конечно по степени конкретизации, заметно уступают СММ. Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия и, тем самым, затрудняет определение "истинных" возможностей той или иной организации и, соответственно, - путей их дальнейшего развития.
CMM (Capability Maturity Model ) разработана Software Engineering Institute при университете Карнеги-Меллона (США) и описывает модель зрелости процессов разработки программного обеспечения на предприятиях {3}. В рамках этой модели для каждой компании может быть сопоставлен некоторый уровень (один из пяти возможных), свидетельствующих о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались, прежде всего, в целях упорядочивания процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО проектам, в то время как технические аспекты разработки освещены меньше.
В версии SW-CMM v.1.1 (Capability Maturity Model for Software) имеется 316 Key Practices. Key Practices - это то, что должно быть внедрено на предприятии и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области - Key Practices Areas ( KPA ) - это уже совокупности взаимосвязанных процессов, которые при совместном выполнении и приводят к достижению определенного набора целей.
CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее приемлемой для разработчиков программных систем, - количество Key Practices достигает уже 417.
Увеличение Key Practices связано с самой целью разработки CMMI - модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей CMM.
(Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:
- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software - SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard - EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model - IPD-CMM)
На основе этих моделей и был построен CMMI. Он вобрал в себя лучшее из этих моделей, устранив неоднозначность трактования некоторых понятий ввиду наличия множества моделей - поэтому и число ключевых практик значительно выросло).
Понятно, что это получилась уже существенно более "тяжелая" модель- см. Рис. 1, которая, к тому-же, еще не достаточно проверена на практике ( вышла только в 2002 году ). В связи с этим, по моему мнению, при внедрении модели возможны большие риски, связанные, как с неоправданными потерями скорости разработки ПО, так и с одновременным однозначным возрастанием трудозатрат на функционирование ( и поддержку) внедренных KPA - cм. Рис 1. Мне, как практику уже построившему СМК в трех различного профиля ИТ-компаниях, кажется, что в модели CMMI явно нарушен баланс необходимого и достаточного - персонал ИТ-компании (а это, как правило, большей частью- "художники кода " ) просто "не примет к исполнению" такое количество контроллируемых регламентов ( здесь есть очень большой риск построить "потемкинскую деревню" ) !
Рис. 1 Сравнение состава KPA в моделях CMM и CMMI.
Кроме того Assessment для CMMI будет значительно дороже, так как авторизованных SEI Lead Assessor'ов будет пока очень мало, и услуги эти будут значительно более дорогие, чем при оценке на соответствие модели CMM.
Более того, многие зарубежные специалисты в области менеджмента качества, (к мнению которых я на данный момент полностью присоединяюсь), довольно скептически отзываются о CMMI в контексте полезности ее для реализации в небольших и средних организаций (именно такие организации, как раз и характерны для России). Высказывается даже мнение, что через некоторое время SEI придется либо выпустить адаптированную SW-CMM v.2, либо произвести какие-то подобные шаги. Т.е. если рынок не примет модели, а такие предпосылки уже на момент написания этой статьи есть, то SEI надо будет адаптироваться к требованиям рынка.
В связи с вышеизложенным представляется целесообразным провести анализ уже упомянутого баланса необходимого и достаточного во всех этих основных моделях СМК.
Проведем его в следующих координатах ( см. Рис. 2) :
степень регламентируемости процессов разработки - обозначим это понятие - RP,
вероятность достижения запланированных результатов- обозначим это понятие -PQ.
На Рис. 2 показана экспертная оценка баланса степени регламентируемости и вероятности достижения при этом запланированных результатов, проведенная автором по результатам практики внедрения требований этих моделей в процессы разработки и внедрения ПС ( программных средств).
Выражаясь математическим языком, величина производной: F(Q) = dPQ \ dRQ (прирост эффективности в достижении качества dPQ при приросте затрат рабочего времени на поддержку выполнения требований dRQ), уменьшается,соответственно, в следующей последовательности: ISO 9000, CMM, CMMI.
Поэтому Рис. 2 наглядно и просто объясняет :
популярность именно модели ISO 9000,
правильность методики: сначала ISO, и только потом, при необходимости, CMM,
определенный скепсис в отношении эффективности модели CMMI.
Рис. 2 Анализ баланса степени регламентируемости и вероятности достижения при этом запланированных результатов ( по экспертной оценке автора)
Расмотрим теперь еще одно руководство, которое широко используется в ИТ-компаниях и будет упомянуто ниже при анализе вопросов практики внедрения СМК.
Это PMBoK (Guide to the Project Management Body of Knowledge) - это проект Project Management Institute, вобравший в себя накопленные знания в области управления проектами. Последняя версия документа вышла в 2000 году и тогда же получила статус стандарта американского института стандартизации ANSI (хотя стандарты ANSI и IEEE формально считаются американскими, большинство из них носит де-факто международный характер). Важной особенностью PMBоK является то, что он рассматривает управление проектами в общем смысле, без привязки к конкретным предметным областям, таким как ИТ, и потому не может применяться самостоятельно - ниже мы рассмотрим, какой это дает эффект при его использовании совместно с ISO 9000.
Рассмотрим теперь, как соотносятся требования уже популярного стандарта ISO 9001:2000 с общими свойствами становящейся все более популярной модели СММ {3}-см. Рис. 3.
Рис. 3. Соответствие между общими свойствами СММ и элементами ISO 9001:2000
Каждый уровень СММ, как было уже упомянуто выше, характеризуется набором областей ключевых процессов- KPA (Key Process Areas ) -см. Рис.3. Достижение всех целей в рамках KPA для определенного уровня СММ определяет соответствие организации данному уровню. Если хотя бы одна цель хотя бы одной KPA для уровня СММ не достигнута, то организация не может соответствовать данному уровню CMM. KPA можно разбить на три категории: управляющие, организационные и обеспечивающие (см. Рис. 4 ).
Рис. 4. Категории ключевых процессов CMM
СММ не определяет все процессы, имеющие отношение к разработке программного обеспечения; в ней выделяются только те, которые необходимы для достижения уровня СММ, они и включаются в KPA. Каждая KPA разбивается на 5 общих свойств (Common Features): Обязательство выполнить (Comment to perform); Способность выполнить (Ability to Perform); Выполняемые действия (Activities Performed); Измерение и анализ (Measurement and Analysis); Проверка реализации (Verifying Implementation)
Общее свойство "Выполняемые действия" описывает действия, которые необходимо выполнить для достижения целей KPA, остальные четыре общих свойств описывают формальные факторы, делающие процесс частью организационной культуры. Полное выполнение всех ключевых приемов (key practice) из всех общих свойств обеспечивает достижение целей KPA. Ключевые приемы работы описывают, каким должен стать рабочий процесс (или элемент процесса, или часть инфраструктуры), но не определяют способ достижения (конкретные технологии или методики), хотя для некоторых приемов даются общие рекомендации. Для различных условий один и тот же результат может достигаться различными способами. Это скорее общие принципы работы, чем конкретные действия.
Последовательное выполнение общих свойств фактически реализует цикл улучшения бизнес-процессов (Buisness-process Improvement -BPI -см. Рис. 5.), т.е. непрерывное улучшение бизнес-процессов ( БП ).
Рис. 5. Цикл непрерывного улучшения бизнес-процессов по модели CMM и ISO 9000:2000.
2. Практические рекомендации
Желание получить сертификат соответствия в самые короткие сроки вынуждает консалтинговые компании и специалистов, занимающихся управлением качества, использовать гибкость и рамочность требований всех перечисленных высокоуровневых моделей в своих "корыстных" целях.
В результате такого форсирования событий у организации, например, получившей сертификат по ISO 9000:2000, определен только минимально-необходимый набор процессов для соответствия ISO 9001, а не все процессы, которые требуются компании для эффективного функционирования- см. Рис. 2. Кроме того - уровень детализации процессов может быть не достаточен для четкого понимания того, что творится внутри процессов и кто, за какие задачи внутри процесса отвечает.
В лучшем случае через новые процедуры прошли лишь несколько тестовых проектов и через какое-то время становятся ясным необходимость их корректировки и дополнения. Часто, сразу после сертификации СМК о процессах забывают до следующего наблюдательного аудита, забывая при этом и о затраченных финансовых ресурсах и энтузиазме сотрудников.
И действительно, когда выступаешь в роли независимого аудитора, очень сложно доказать, что принятый уровень детализации процесса явно не достаточен для эффективного функционирования СМК компании. Но и доказать обратное за время, которое выделяется на аудит по ISO 9000, крайне сложно (этим очень успешно можно воспользоваться при оппонировании аудитору). Практика показывает, что быстро построить эффективные процессы даже 3-го уровня зрелости (также, по-хорошему, как и процессы на основе ISO 9000) невозможно.
Для того, чтобы этого добиться, недостаточно просто описать процессы с учетом требований выбранной модели. Самая главная сложность заключается в том, что необходимо перепроектировать культуру производства внутри организации.
И сделать это волевым решением руководства невозможно. Именно поэтому подход, который определен в СMM, просто более жизнеспособен и реалистичен, чем в моделях ISO 9000 -см. Рис. 5.
Рассмотрим теперь, как на практике можно построить СМК совместимую с обоими моделями.
Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000, в соответствии с оценкой самих авторов CMM {4}, показана на Рис.6.
Собственно оценка ими проводилась по двум координатам:
степень обеспечиваемости ( в % ) соответствия процессов разработки (SWP) уровню зрелости в рамках CMM -"обеспечиваемость";
степень возможности ( в % ) такой обеспечиваемости, которую дает ISO 9000:2000 - "возможность".
Как видно из Рис. 6, требования ISO 9000:2000 создают реальную возможность для достижения даже верхнего (CMM Level 5) уровня зрелости SWP.
Однако в смысле уже обеспечения зрелости SWP хотя-бы третьего (CMM Level 3) уровня, СМК по модели ISO 9000:2000 необходимо немного доработать- а именно разработать и внедрить еще две организационные процедуры (Organization process definition and focus) и процедуру общего управления (Integrated software management), содержание которых не представляют сложности для любой ИТ-компании.
Но можно и нужно пойти дальше (CMM Level 4) - например, в скобках показана оценка автора этой статьи (в тех-же коорддинатах -обеспечиваемости и возможности ), которая соответствует СМК по модели ISO 9000:2000, в которой процессный ландшафт СМК дополнен процессами управления проектами в соответствии с уже требованиями другого упомянутого выше стандарта PM Bok - это поможет вам существенно увеличить зрелость еще таких SWP, как :
Контроль за ходом выполнения проектов (Software project tracking and oversight);
Планирование проектов (Software project planning);
Общее управление ПО ( Integrated software management);
Управление процессами через количественные оценки (Quantitative process management).
Рис. 6. Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000
Как видно из Рис.6., модель СММ по заложенным в ней принципам очень близка к СМК построенной по стандарту ИСО 9001:2000 и дополненной процессами управления проектами в соответствии с PM BoK..
Для того, чтобы не делать лишней работы при одновременных сертификации по ISO 9000 и последующей оценке по CMM, я рекомендую при определении ваших производственных процессов включить ( а может и ими ограничиться - ведь это для ИТ-компании и есть производственные процессы !) в их число все необходимые в модели CMM KPA. Таким образом компания одновременно:
выполняет требования ISO 9001:2000 по внедрению процессного подхода ;
документирует все необходимые CMM процессы ( KPA);
реализует при этом ряд таких важных требований ISO 9001:2000 как :
управление процессами на основе метрик ( Quantitative process management);
управление Поставщиками на основе управления субконтрактами (Software subcontract management);
анализ требований Потребителей на основе управления требованиями (Requirements management);
управление человеческими ресурсами на основе Программы обучения персонала ( Training program);
управление коммуникациями на основе создания формальных моделей организационных процессов ( Organization process definition);
запускает механизм улучшения ( Plan-Dо-Check -Action) всех описанных процессов (SWP) посредством последовательной реализации всех пяти их Common Features -см.Рис. 5.
Таким образом, если в качестве БП использовать KPA CMM и использовать для процедур управления проектами разработки ПС требования PM BoK, то построенная таким образом СМК, может вполне быть оценена на CMM Level 4 - см. Рис. 7.
Рис. 7. Cхема достижения CMM Level 4 при совместном использовании модели СМК по ISO 9000 и руководства PM BoK 2000.
В заключении, исходя из соображений наглядности (в стилизации автора), представляю схему функционирования СМК ИТ-компании при последовательном внедрении моделей ISO 9000 и CMM - см. Рис. 8.
Рис. 8. Схема функционирования СМК при последовательном внедрении моделей ISO 9000 и CMM ( стилизация автора)
Здесь важно понять, что и СММ и ISO 9001:2000 сами по себе являются всего лишь инструментами для непрерывного улучшения деятельности.
Таким образом, сертификация по стандарту ИСО 9001:2000 и подтверждение сертификата должны способствовать росту именно качества процессов компании, где критерий оценки роста качества процессов - выход предприятия на новый уровень BPI, то есть оценка их уже по модели именно CMM {3}.
Литература
"Оценка качества Програмных средств", В. Липаев, Синтег, 2001 г.
ISO 9001:2000. Система менеджмента качества. Требования.
Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model for Software ( SW-CMM), version 1.1. // CMU/SEI-93-TR-024, - Februaru, 1993.
Paulk M.C. A Comparison of ISO 9000 and SW-CMM // CMU/SEI-94-TR-12, - July, 1994.
Также на сайте:
Практический опыт внедрения и сертификации Системы Менеджмента Качества (СМК) по требованиям ISO 9001:2000
Причины трудностей при внедрении системы менеджмента качества и как их решать
О проекте
quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.
Нам более 7 лет, и все это время ресурс пополняется новыми и новыми материалами, почти ежедневно. Если вы ищете информацию о менеджменте вообще и управлении качеством в частности, скорее всего, вы найдете эту информацию здесь.
Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.