Модели зрелости процесса тестирования по. Зрелость проектных организаций. Методология CMM Совершенствование процессов работы с требованиями

Эволюцию моделей обеспечения качества рассмотрим на основе "модели зрелости процесса", или "модели совершенствования возможностей" СММ (Capability Maturity Model). Несмотря на то что модель СММ направлена на обеспечение качества программного обеспечения, ее методологические аспекты применимы к моделям обеспечения качества любой продукции (товаров, работ, услуг).

Главным в модели СММ является понятие зрелости организации.

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

Зрелой считается организация, в которой выполняются следующие условия:

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

Итак, стандарт СММ – это модель обеспечения качества, которая состоит из критериев оценки зрелости организации и рецептов улучшения существующих процессов. В модели СММ определено пять уровней зрелости организаций, характеристики которых представлены на рис. 5.3.

Рис. 5.3. Пять уровней зрелости модели СММ

Начальный уровень (initial level) является основой для развития предприятия на следующих уровнях. Считается, что на предприятии начального уровня организации не существует стабильных условий для создания качественного программного обеспечения. Следовательно, результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов. Это означает, что успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Если же получившие в проектах опыт менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимого программного обеспечения.

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

Достижение второго, повторяемого уровня (repeatable level ) определяется внедрением на предприятии технологии управления проектами. Планирование и управление проектами на предприятии основывается на накопленном опыте, существуют и используются стандарты на разрабатываемое программное обеспечение, соблюдение которых контролируется специальной группой обеспечения качества. Считается, что второй уровень может как обеспечить возможности для дальнейшего совершенствования (перехода на третий уровень), так и не исключает вероятность в критических условиях регрессивного возврата качества процесса создания программного обеспечения на начальный уровень.

Третий, определенный уровень (defined levet) характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения полностью задокументирован, начиная от разработки программного обеспечения и заканчивая управлением проектами. Гипотеза внедрения этого уровня состоит в том, что в процессе стандартизации происходит переход предприятия на наиболее эффективные практики и технологии. Для создания и поддержания функционирования стандартов разработки программного обеспечения и управления проектами в организации должна быть создана специальная группа. Обязательным условием для достижения третьего уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Считается, что начиная с этого уровня организация перестает зависеть от качеств конкретных разработчиков и не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.

На четвертом, управляемом уровне (managed level) на предприятии устанавливаются количественные показатели качества – как на программные продукты, так и на процессы их создания в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных проектных показателей. При этом разделяются осмысленные (сигнальные) вариации реализуемых процессов создания программного обеспечения и случайные (шумовые) вариации процесса.

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

В 1982 году Министерство обороны США образовало комиссию, основной задачей которой стало исследование проблем, возникающих при разработке программных продуктов в организациях министерства. В результате деятельности комиссии в декабре 1984 году был создан Институт инженеров-разработчиков программного обеспечения ( Software Engineering Institute, SEI ) на базе Университета Карнеги-Меллона в Питсбурге.

1987 г. SEI публикует: краткое описание структуры CMM ; методы оценки процессов разработки ПО ; методы оценки зрелости процессов производства ПО ; анкету для выявления степени зрелости процессов (для проведения самостоятельного, внутреннего аудита и внешнего аудита).

1991 г. Выпуск версии CMM v1.0.

1992 г. Выпуск версии CMM v1.1.

1997 г. Выпуск очередной (усовершенствованной) версии CMM .

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

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

Для оценки степени готовности предприятия разрабатывать качественный программный продукт СММ вводит ключевое понятие зрелость организации ( Maturity ). Незрелой считается организация, в которой:

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

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

Основные признаки зрелой организации:

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

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

Каждый из уровней, кроме первого, состоит из нескольких ключевых областей процесса (Key Process

05.04.2007 Вячеслав Панкратов

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

Очевидно, что качество программного обеспечения напрямую зависит от качества процесса его производства. Управляя процессом производства и контролируя показатели эффективности всех его технологических этапов, можно влиять на качество производимого продукта. Говоря о характеристиках программ, можно выделить простые для понимания и анализа количественные метрики, относящиеся к качеству программного кода (цикломатическая сложность кода - сложность структуры модуля, например, количество независимых маршрутов в нем); количество строк кода, отнесенное к артефактам проектного репозитория и т.п.; тесты (покрытие веток и модулей кода сценариями тестов, соотношение количества ошибок, найденных до и после выпуска продукта, динамика обнаружения ошибок и др.); покрытие требований на соответствие рекомендациям к интерфейсу приложений и операционным платформам. Однако, при переходе на процессный уровень обеспечения качества разрабатываемых программ возникают определенные трудности в понимании качества этого процесса. В самом деле, как, например, оценить и измерить эффективность того или иного способа разработки, если практически не существует проектов разработки двух одинаковых программных систем, и тем более не встречаются две идентичные по опыту и навыкам команды разработчиков? Судить по конечному результату не представляется возможным: кроме процессных условий производства программного обеспечения (применяемая методология, структура проектной команды, способы коммуникации с заказчиком) зачастую сильно разнятся и условия проекта (сроки, стоимость и объемы ресурсов). Более детальное рассмотрение процесса тестирования программного обеспечения - технологической составляющей процесса производства - выявляет проблему выбора метрик эффективности тестирования.

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

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

В 1980 году в Институте программной инженерии при Университете Карнеги-Меллона была разработана модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software, CMM), которая впоследствии получила развитие в CMMI (Capability Maturity Model Integration), де-факто признанном в индустрии производства программного обеспечения сертификате уровня зрелости процесса разработки. По аналогии с миром разработки программного обеспечения и существующими моделями зрелости их процессов, рассмотрим модели зрелости процесса тестирования.

Модель зрелости тестирования

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

Консультант по вопросам тестирования Терри Везерил в 2001 году одним из первых сравнил существующие модели зрелости тестирования и выделил шесть моделей:

Testability Maturity Model (TMM);

Software Testing Maturity Model (TMMSW);

Test Process Improvement (TPI);

Test Organization Maturity (TOM);

Testing Assessment Program (TAM);

Proposed Evaluation and Test SW-CMM Key Process Areas (SW-CMM KPA).

Затем в некоторые модели были внесены принципиальные изменения; так, модель ТОМ (ее создала и развивает компания Gerrard Consulting) предлагает обновленный набор метрик, описывающих непосредственно процесс тестирования (длительность тестовых итераций, соотношение тестовых сценариев и функциональных требований и др.), которые собираются и анализируются на этапе описания существующего процесса.

Среди шести моделей зрелости тестирования программного обеспечения практики и консультанты выделяют две: TMMSW, разработанную в Технологическом институте штата Иллинойс, и TPI, предложенную в компании Sogeti. Обе модели получили распространение в первую очередь благодаря своей простоте, а также предлагаемым практикам внутренних аудитов, которые могут производиться специалистами компании, вставшей на путь процессных улучшений. Рассмотрим структуру моделей зрелости тестирования программного обеспечения на примере модели TMM.

Модель TMMSW, выбранная Томасом Стаaбом , одним из ведущих консультантов в области тестирования программного обеспечения, является наиболее интересной для применения, поскольку наряду с простотой понимания и использования практик позволяет организациям собственными силами проводить оценки (assessment) и постепенно приближаться к поставленным целям развития, контролируя промежуточные результаты. В своей работе мы также остановили выбор на этой модели, учитывая непопулярность у отечественных ИТ-компаний практики привлечения сторонней компетенции (компании стараются экономить на инвестиционных проектах, каковыми по сути являются проекты консалтинговые, а также на проектах, приносящих непрямые выгоды, к которым относят процессные изменения), и предлагаем познакомиться с нашим опытом, демонстрирующим готовность компаний самостоятельно проводить внутренние изменения силами собственных специалистов. Итеративность подхода является для многих компаний ключевым моментом при выборе той или иной модели зрелости, так как она позволяет контролировать сроки исполнения проекта по внедрению процессных изменений.

Модель TMMSW разработана группой специалистов под руководством Илен Барнштейн в 1996 году как расширение и дополнение к модели SW-CMM. К ее преимуществам можно отнести соответствие уровней зрелости процессов тестирования программного обеспечения и уровней зрелости процессов разработки в модели SW-CMM. Также модель TMMSW может быть использована в интеграции с CMMI, рекомендациями ISO-9001 и стандартом ISO/IEC Std 12207, которые позволяют пройти формальную сертификацию и при постоянном контроле в виде аудитов и переаттестаций оставаться на заданном уровне качества. С одной стороны, эта особенность TMMSW позволяет внедрять процессные изменения в подразделении тестирования программного обеспечения в формате выделенного проекта меньшего масштаба, чем внедрение CMMI во всей организации (что экономит средства и обеспечивает прозрачность); с другой стороны, при таком подходе исключаются затраты на адаптацию и сопряжение нескольких моделей. Говоря о своеобразном родстве с CMMI, хотелось бы подчеркнуть, что эта модель достаточно широко распространена в мире ИТ и заслужила высокую степень доверия к себе, что намного облегчает мотивацию руководства к затратам на проект по внедрению процессных изменений.

Модель TMMSW предлагает облегченное планирование, внедрение и мониторинг процесса улучшения. Из недостатков модели можно отметить ограниченность литературы: книга Practical Software Testing: A Process-oriented Approach, выпущенная Springer Professional Computing, - пожалуй, единственный значительный труд по данной тематике.

Модель TMMSW, как и CMM, предусматривает пять уровней зрелости.

Уровень 1 - хаотический. Процесс тестирования программного обеспечения имеет хаотический характер, что отличает большинство начинающих компаний. Процесс тестирования не определен как выделенная активность и не отделен от процесса отладки кода. Тестирование выполняется по факту создания кода и построения или сборки системы. Цель тестирования - показать, что приложение работает. Этот уровень характеризуется неподготовленным персоналом, недостатком ресурсов и инструментов. Программное обеспечение выпускается без формального согласия со стороны тестировщиков. Цели уровня не определены.

Уровень 2 - фаза разработки. Тестирование программного обеспечения отделено от кодирования и выделяется как следующая фаза. Главная цель тестирования - показать, что приложение соответствует требованиям. Имеются базовые подходы и практики тестирования. Цели уровня: определить задачи разработки и тестирования, создать соответствующие процедуры, инициировать процесс планирования тестирования, зафиксировать и описать базовые процедуры и методики тестирования.

Уровень 3 - интегрированный. Процесс тестирования интегрирован в жизненный цикл разработки программного обеспечения. Цели тестирования базируются на требованиях. Имеется организация тестирования, а само тестирование выделено в профессиональную деятельность. Цели уровня: выделить тестирование в отдельную группу и определить программу технического обучения, интегрировать процесс тестирования в жизненный цикл разработки, а также контролировать непосредственно процесс тестирования.

Уровень 4 - управление и измерение . Тестирование является измеряемым и контролируемым процессом. Процессы критических осмотров (review) проектных артефактов (тестовые планы и сценарии, сообщения об ошибках, итоговые отчеты о состоянии версии и т.д.) относятся к тестовым активностям. Продукт тестируется на соответствие таким качественным метрикам, как надежность, удобство, сопровождаемость. Тестовые сценарии записаны, хранятся в системе управления тестированием и могут быть многократно использованы вместе с тестовыми наборами данных. Обнаруженные дефекты не только фиксируются, но и анализируются по формальным признакам: критичность, «вес» дефекта, важность, время жизни и т.д. Цели уровня: внедрение программ критических пересмотров и аудитов на уровне всей организации/подразделения наравне с программой измеряемого тестирования. Проводится оценка качества программных продуктов.

Уровень 5 - оптимизация процесса, предотвращение ошибок и контроль качества. Тестирование является определенным и управляемым процессом. Стоимость тестирования наравне с показателями эффективности может быть определена. Тестирование как процесс поддается изменениям, которые однозначно положительно на него влияют. Внедрены и используются практики предотвращения ошибок и контроля качества. Автоматизированное тестирование применяется как основной подход в тестировании. Проектирование тестов, анализ полученных результатов, обработка описаний ошибок, а также метрик, связанных с тестированием, осуществляется при помощи соответствующих инструментальных средств. Широко распространен подход повторного использования процессных практик. Цели уровня: оптимизация процесса тестирования, предотвращение ошибок и контроль качества.

Все перечисленные уровни зрелости, кроме первого, включают цели развития, которые, в свою очередь, содержат подцели, то есть позволяют оперировать не только высокоуровневыми задачами менеджмента качества процесса разработки программного обеспечения, но и формулировать оперативные задачи для всех исполнителей в проекте. Контроль и анализ выполнения задач достигаются покрытием так называемых ATR-матриц (Activities - Tasks - Responsibilities) - артефактов проектного уровня, с которыми могут работать участники проекта без предварительной подготовки или длительного обучения. ATR-матрицы определяют активности и задачи, которые должны быть выполнены на каждом конкретном этапе внедрения модели, и служат одновременно и «дорожной картой», и своеобразным «контрольным листом» процесса внедрения изменений. Наличие предлагаемых самой моделью проектных артефактов зачастую является существенным критерием успешности проекта по адаптации и внедрению модели. Каждой активности в ATR-матрице назначается задача контроля, которая выполняется менеджерами, разработчиками/тестировщиками или же клиентами/пользователями. Особо отметим, что контроль над проектом по внесению изменений не возлагается на выделенную группу людей или конкретного человека в проекте, а является общей проектной функцией, в выполнении которой заинтересованы участники проекта всех уровней.

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

Применение конкретных методик или следование любой из выбранных методологий (RUP, MSF или Scrum) также не дает гарантий достижения качества продукта или успешности проекта, так как методология разработки программного обеспечения работает только для конкретного типа проектов. Аналогично для процесса тестирования программного обеспечения ни одна методология без адаптации к условиям конкретного проекта не дает гарантированного результата. Модель зрелости процесса - именно тем и интересная для применения практика достижения определенных уровней качества процесса, что представляет собой структуру целей и подходов для их достижения, позволяя использовать «внутри» практически произвольную методологию разработки (при правильной адаптации) и набор инструментария. Модель объясняет, «что и как» делать, но не «чем и в каком порядке».

Практика

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

Контролируемый по срокам процесс выпуска версий с заданным уровнем качества. Здесь не говорится об идеальном качестве выпускаемого продукта или полном отсутствии дефектов - речь идет об уверенности в состоянии выпускаемой версии, со стороны как проектной команды, так и группы тестирования.

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

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

Литература

Terry Weatherill, In the Testing Maturity Model Maze. Journal of Software Testing Professionals, 2001.

Thomas Staab, Using SW-TMM to Improve the Testing Process. Wind Ridge International.

Вячеслав Панкратов ([email protected] ) - генеральный директор компании QAExpert (Киев, Украина).

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

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

История возникновения СММ такова. В конце 80-х гг. прошлого века Министерство обороны США заказало Институту программной инженерии 1англ. SEI - Software Engineering Institute Университета Карнеги-Меллон работу по созданию системы критериев для выбора субподрядчиков в проектах разработки программного обеспечения. Работа была закончена в 1991 г., и результатом ее стала модель CMM . Нужно сразу оговориться, что модель не содержит никаких финансово-экономических, политических, организационных критериев выбора субподрядчика, равно как и критериев возможности допуска к секретным работам (вероятно, такие задачи и не ставились). Речь идет только о критериях, описывающих способности потенциального субподрядчика в части разработки программных систем.

Структура CMM

За основу при оценке способности организации качественно выполнять работу, которая (способность) была названа зрелостью, создатели модели взяли процессы организации. Дальше они сделали несколько нетривиальных предположений, которые впоследствии были приняты и признаны справедливыми многими ИТ-специалистами (а может быть, и большинством из них).

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

Предположение 2 . Всякая организация-разработчик заинтересована в переходе на более высокий уровень зрелости (не только для того, чтобы повысить свои шансы в борьбе за контракты Министерства обороны, но и в целях собственного совершенствования).

Предположение 3 . Переход возможен только на следующий по порядку уровень. "Перескочить" через уровень нельзя (точнее, риски для организации при этом резко возрастают).

Таким образом, уровни образуют "лесенку", по которой подымается организация по мере собственного развития. Каждый уровень характеризуется определенными составом и свойствами процессов организации. "Лесенка уровней" СММ получила широкое признание и распространение. Вот как она выглядит.

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

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

Уровень 3 "Определенный" . Производственный процесс документирован и стандартизован как для управленческих работ , так и для проектирования. Этот процесс интегрирован в стандартный производственный процесс организации. Во всех проектах используется утвержденная адаптированная версия стандартного производственного процесса организации.

Уровень 4 "Управляемый" . Собираются подробные количественные показатели производственного процесса и качества создаваемого продукта. Как производственный процесс, так и продукты оцениваются и контролируются с количественной точки зрения.

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

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

Дальнейшее, как говорится, - дело техники. Определяется структура модели ( рис. 7.1), даются определения и начинается кропотливая работа по точному описанию каждого процесса на каждом уровне. Для того чтобы оценить практическую ценность сделанного, пройдем часть этого пути.

Рис. 7.1.

На рис. 7.1 присутствуют следующие понятия.

Группа ключевых процессов . Как говорится в (Paulk, и др., 1995), "каждая группа ключевых процессов определяет блок связанных работ , в результате выполнения которых достигается совокупность целей, значимых для повышения продуктивности производственного процесса. Например, для группы ключевых процессов " Управление требованиями " (см. рис. 7.2) цель состоит в том, чтобы согласовать требования, выдвигаемые к проекту разработки ПО заказчиком и разработчиком".

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

Рис. 7.2.

Группы ключевых процессов в CMM сопоставляются уровням зрелости ( рис. 7.2), т. е. все практики на уровне взаимодействуют только друг с другом и не взаимодействуют с практиками других уровней. Это позволяет гарантировать полную работоспособность всех процессов на конкретном уровне и, значит, соотносить уровень с законченным этапом развития организации.

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

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

Если эти цели реализуются для всех проектов, то это означает, что организация достигла того уровня зрелости производственного процесса, которому соотнесена данная группа ключевых процессов.

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

Обязательства по выполнению

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

Необходимые предпосылки

Описывают предварительные условия, которые должны выполняться в проекте или организации для компетентного внедрения производственного процесса; обычно касаются ресурсов, организационных структур и требуемого обучения.

Выполняемые операции

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

Измерения и анализ

Раздел "Измерения и

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

Каждая ключевая практика состоит из одного предложения, часто раскрываемого более подробным описанием, в которое могут входить примеры и уточнения. Ключевые практики, иногда называемые ключевыми практиками верхнего уровня, устанавливают основные политики, процедуры и операции для группы ключевых процессов. Компоненты подробного описания часто называются субпрактиками".

Ключевые практики описывают, ЧТО необходимо сделать, но их не следует воспринимать в виде догм, устанавливающих, КАК нужно достигать целей. Цели группы ключевых процессов можно реализовать с помощью альтернативных практик. Интерпретация ключевых практик должна быть разумной, допускающей достижение целей группы ключевых процессов эффективным способом, хотя, возможно, формально и отличающимся от рекомендованного CMM .

Взгляд на деятельность по управлению ИТ, при котором вместо процессов рассматриваются их составляющие - ключевые практики, а процессы присутствуют только виртуально, как что-то, что может быть построено из ключевых практик, выглядит на первый взгляд несколько экзотично. До сих пор задача совершенствования управления ИТ решалась внедрением готовых процессов из эталонной процессной модели. Теперь же возникает множество уровней, содержащих разрозненные (т. е. не объединенные в процессы) ключевые практики, и рекомендуемая последовательность продвижения по уровням. Управление ИТ, согласно CMM , совершенствуется по мере продвижения на более высокий уровень зрелости. Что же происходит при таком продвижении?

В определениях уровней (см. рис. 7.2) появилось такое понятие, как "производственный процесс". Оно же присутствует и в определении группы ключевых процессов, и это не случайное совпадение. Производственный процесс, или, как он точно называется в СММ, Стандартный Производственный Процесс Организации (СППО), - одно из центральных понятий всей модели.

В.Ильин.

Руководитель Службы качества Компании 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 ).

СММ не определяет все процессы, имеющие отношение к разработке программного обеспечения; в ней выделяются только те, которые необходимы для достижения уровня СММ, они и включаются в 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.

Желание получить сертификат соответствия в самые короткие сроки вынуждает консалтинговые компании и специалистов, занимающихся управлением качества, использовать гибкость и рамочность требований всех перечисленных высокоуровневых моделей в своих "корыстных" целях.
В результате такого форсирования событий у организации, например, получившей сертификат по 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 softwaremanagement), содержаниекоторых не представляют сложности для любой ИТ-компании.

Но можно и нужно пойти дальше (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.

Модели зрелости процесса тестирования по. Зрелость проектных организаций. Методология CMM Совершенствование процессов работы с требованиями

Структура CMM

В.Ильин.

Народная китайская мудрость

Планирование проектов (Software project planning);

Литература