Магазины

Является структурным элементом модели смм. Модели зрелости процесса тестирования по. Документирование процессов и результатов сертификации программных продуктов

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

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

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области ПО, и членами общества разработчиков.

Начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу, и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.
Повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 1999 года лишь 20 % организаций имели 2-й уровень или выше.
Установленный. Имеют определённый, документированный и установленный процесс работы, не зависящий от отдельных личностей. То есть вводятся согласованные профессиональные стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надёжно предсказывать затраты на проекты, аналогичные выполненным ранее.
Управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений. Но нет изменений при появления новых технологий и парадигм.
Оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.

Развитие

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration) . На текущий момент последняя версия CMMi - 1.3 (опубликована в ноябре 2010) .

См. также

Ссылки

Форум студентов МТИ > Основной раздел > Тесты > Моделирование систем управления

Просмотр полной версии: Моделирование систем управления

Я про решала все модули, сдала все на 4, а итоговый на 2, теперь через три дня попробую сдать повторно, не было ни одного одинакового вопроса. Итоговый тест пыталась исправлять, но проверяйте, за правильность не ручаюсь.Выставляю всё, что есть у меня, может быть кто то сдаст лучше меня. Если есть у кого то вторая, третья попытка, выставите, если не жалко, дисциплина, действительно очень трудная.:eek:

Итоговый тест 100 из 100

итоговое каждый раз разное?

Еще вопросы, которые здесь не указаны и попались мне. Ответы не искала, тк без этого сдала на 4. Кто захочет зоморочиться, выгрузите ответы здесь для остальных 🙂

Модуль 1:
Что не следует рассматривать в качестве отличительного признака бизнес-процесса?

Наращивание стоимости

Выберите один ответ:
Продукт процесса, воплощающий в себе ранее поставленные цели

Выберите один ответ:

В итоговом (сдано на 4.

What is the Capability Maturity Model? (CMM)

Эти вопросы + те, что уже есть на форуме):
1. Выберите правильное утверждение.
Выберите один ответ:
Бизнес-процесс подразделений состоит из различных цепочек создания ценности (НЕ УВЕРЕНА)
Сквозной бизнес-процесс состоит из бизнес-процессов различных организаций
Межфункциональный бизнес-процесс, как правило, состоит из бизнес-процессов подразделений

2. Что не является элементом универсальной структурной схемы бизнес-процесса?
Выберите один или несколько ответов:
Ресурсы процесса
Риски
Деятельность по управлению бизнес-процессом
Факторы внешней среды
Деятельность по преобразованию входов в выходы

3. Материальные ресурсы как базовый элемент процессов представляют собой:
Выберите один ответ:
Активные субъекты деятельности, объединенные в системы, взаимодействующие друг с другом и другими ресурсами
Управляющие воздействия, направляемые субъектами деятельности на объекты деятельности, определяющие цели и результаты процессов
Пассивные средства и предметы деятельности, используемые для выполнения процессов (НЕ УВЕРЕНА)

28.03.2014, 10:07

Модуль 1:
Что не следует рассматривать в качестве отличительного признака бизнес-процесса?Выберите один или несколько ответов:
Преобразование входов в выходы
Поставка продукта внешнему потребителю
Наращивание стоимости
Формирование прибавочной и/или потребительной стоимости

Результаты как базовые элементы процессов представляют собой:
Выберите один ответ:
Активные субъекты деятельности, объединенные в системы, взаимодействующие друг с другом и другими ресурсами
Продукт процесса, воплощающий в себе ранее поставленные цели Пассивные средства и предметы деятельности, используемые для выполнения процессов
Совокупность материальных, энергетических и информационных объектов, необходимых для выполнения процесса

Что такое обратная связь в рамках бизнес-процесса?
Выберите один ответ:
Целенаправленное и сознательное воздействие на процесс, предназначенное для обеспечения необходимого результата
Анализ и сопоставление результатов процесса с ранее поставленными целями
Воздействие на систему объектов и факторов внешней среды, являющиеся источниками различного рода отклонений в функционировании системы
я так ответила! но все равно вышло 4

В итоговом — Эти вопросы + те, что уже есть:
1 Выберите из списка недостатки проектно-целевых структур.

2 Выберите из списка примеры использования команд.
Кружки качества
Комитеты
Рабочие команды

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

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

5 Вспомогательные процессы:
Обеспечивают эффективную реализацию основных процессов

Итоговое оценка 5
Вопрос 1
Выберите из списка примеры использования команд.

Кружки качества
Комитеты
Рабочие команды

Вопрос 2
Для чего применяются посредники в рамках функциональной структуры?

Для интеграции деятельности различных структурных подразделений

Вопрос 3
Назовите типы взаимосвязей в модели SADT:
Управление
Выход-механизм
Обратная связь по входу

Вопрос 4
Какой из перечисленных бизнес-процессов является самым коротким?
Бизнес-процесс подразделения

Вопрос 5
Какие методы, методологии и инструменты можно использовать для создания информационных моделей бизнес-процессов?

Методологию Гейна-Сарсона
Язык моделирования Чена и Баркера

Вопрос 6
Какое представление бизнес-процесса соответствует самому нижнему уровню (из перечисленных)?

Операции бизнес-процесса

Вопрос 7
Длина бизнес-процесса:

Представляет собой субъективную характеристику

Вопрос 8
Материальные ресурсы как базовый элемент процессов представляют собой:

Пассивные средства и предметы деятельности, используемые для выполнения процессов

Вопрос 9
Выберите из списка преимущества проектно-целевых организационных структур.

Реализуется прямое подчинение сотрудников руководителю проекта и таким образом достигается однозначность направленности усилий этих сотрудников

Вопрос 10
Выберите из списка преимущества матричных организационных структур.

Появляется возможность гибко «настраивать» организационную структуру в рамках широкого спектра: от слабой до сильной матрицы

Вопрос 11
Что в себя включает второй контур управления бизнес-системой?

Подсистему управления функционированием
Подсистему управления развитием

Вопрос 12
Общая процессная модель бизнес-системы включает в себя следующие элементы:

Выход
процесс
Вход
Возмущение

Вопрос 13
Какой стандарт из семейства IDEF позволяет моделировать деятельность, потоки и состояние объектов?

Вопрос 14
Каковы полномочия Руководителя проекта в сильной матричной структуре?

От средних до высоких

Вопрос 15
Что можно отнести к числу основных элементов инвестиционно-финансовых процессов?

Инвесторов
Кредиторов

Вопрос 16
Выберите из списка недостатки проектно-целевых структур.

Снижается технологичность в функциональных областях

Моделирование систем управления.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Каков порядок доминирования на диаграммах SADT?
Ответ: Наиболее доминирующие функции располагаются в верхнем левом углу.

помогите 3тренинг укого есть плиз

Добавлено через 1 минуту
прошу 3 тренинг укого есть Моделирование систем управления

Перевод: zCarot

Методология разработки ИС. Модель зрелости CMM/CMMI.

В 1991 году Институтом программной инженерии Университета

Карнеги-Меллона (Software Engineering Institute, SEI) была создана модель зрелости СММ (Capability Maturity Model) для разработки программных продуктов. С течением времени было выпущено целое семейство моделей:

SW-CMM - для программных продуктов, SE-CMM - для системной инженерии, Acquisition CMM - для закупок, People CMM - для управления людскими ресурсами, ICMM -для интеграции продуктов.

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

требованиями международных стандартов. Поэтому в 2002 году SEI опубликовал новую модель CMMI (Capability Maturity Model Integration), объединяющую ранее выпущенные модели и учитывающую требования

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

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

Следствие 1. CMMI допускает различные реализации и не является методологией разработки ПО, подобно MSF, Scrum, RUP и пр. Последние могут использоваться в его реализации. Так, существует, например, специальный шаблон процесса в VSTS для CMMI под названием MSF for CMMI.

Следствие 2. CMMI используется для сертификации компаний на зрелость их процессов. Изначально, в конце 80-х начале 90-х годов, CMM (тогда еще не CMMI) создавался именно как средство сертификации

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

Например, авиационная, аэрокосмическая индустрии. То есть разработка ПО

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

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

же как и в CMM, и непрерывное, допускающее совершенствование процессов в организации до некоторой степени в произвольном порядке. Здесь мы остановимся на последовательной модели. Она имеет 5 уровней

зрелости процессов (рис. 1).

Начальный уровень (уровень зрелости 1) - это уровень, на котором, по определению, находится любая компания. На этом уровне разработка ПО ведется более-менее хаотично.

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

Определенный уровень (уровень зрелости 3) - здесь появляется стандартный процесс на уровне всей компании в целом.

What is Capability Maturity Model (CMM)? What are CMM Levels?

Это большой и постоянно пополняющийся набор активов процесса: шаблонов документов,

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

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

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

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

Но как быть тем, кто поставляет не продукт, а услуги (например, сопровождение продукта с незначительной долей разарботки в общих трудозатратах или вообще с отсутствием таковых)? Для них тоже есть набор рекомендаций — модель CMMI for Services (CMMI-SVC). Для IT-подразделений, например, эта модель (точнее — её рекомендации) может помочь понять — что надо сделать, чтобы, например, те же рекомендации ITIL, приобрели характер нормального процесса, а не некой «сакральной практики».

Capability Maturity Model (Модель развития функциональных возможностей) (CMM)

Любопытно, что рекомендации этой модели достаточно универсальны и не «замыкаются» только на информационные технологии. Пилотное внедрение практик этой модели проходило … в одной из больниц в США (ведь медицинское обслуживание — это тоже услуги).

Однако, любой модели из перечисленных лучше обучиться. И если на всё СНГ обученных модели CMMI-DEV несколько сотен наберется (порядка 250-300 человек), то обученных модели CMMI-SVC в СНГ… 6 человек. Речь идет именно об обученных, а не об инструкторах. Это как раз и было до декабря 2011 года главной проблемой: по CMMI-DEV на весь мир был только один сертифицированный институтом SEI (разработчиком моделей CMMI) русскоязычный инструктор, а по другим моделям таковых вообще ни одного! Теперь появился такой инструктор и по модели CMMI-SVC (отсюда и первые 6 обученных). Этим инструктором является автор данной публикации, который готов ответить на любые вопросы по упомянутым моделям, и по официальному обучению. Спрашивайте!

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

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 (Киев, Украина).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Качество было легко измерить: или нам платили, или нет.
Дин Леффингуэлл, Дон Уидриг.
Управление программными требованиями

CMM/CMMI

Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 г.

Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных , методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

Таблица 1. Уровни модели CMM

№ уровня	Название уровня	Ключевые области процесса
1	Начальный	Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено
2	Повторяющийся	Управление программными конфигурациями.Обеспечение качества программных продуктов.Управление контрактами подрядчиков.Контроль за ходом проектов.Планирование программных проектов.Управление требованиями
3	Определенный	Экспертные оценки.Координация взаимодействий проектных групп.Инженерия программного продукта.Комплексный менеджмент ПО.Программа обучения персонала.Определение организационного процесса.Область действия организационного процесса
4	Управляемый	Менеджмент качества ПО.Управление процессом на основе количественных методов
5	Оптимизируемый	Управление изменением процесса.Управление технологическими изменениями.Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя - SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

Таблица 2. Развитие стандартов CMM

Название стандарта	Описание
System Engineering CMM (SE-CMM)	Ориентирован на вопросы системного инжиниринга - разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование)
Trusted CMM (T-CMM)	Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО
System Security Engineering CMM (SSE-CMM)	Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей
People CMM (P-CMM)	Рассматривает вопросы развития персонала в софтверных организациях
Software Acquisition CMM (SA-CMM)	Охватывает вопросы приобретения программных продуктов у внешних организаций
Integrated Product Development CMM (IPD-CMM)	Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого отдела компании

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI - Capability Maturity Model Integrated (CMMI) - Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления - классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

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

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