Определение программного инжиниринга в модели SEI CMM. Модели зрелости процесса тестирования по Модели оценки зрелости организаций разработчиков программных систем

02.05.2024

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

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

Как правило, менеджмент качества программных проектов основывается на знаниях из трех источников:

Программный инжиниринг (ACM, IEEE);

Менеджмент проекта (PMI);

Качество (ASQ).

Институт программного инжиниринга (SEI, Software Engineering Institute) в Университете Карнеги Мэллон объединяет все эти три источника.

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

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

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

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

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

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

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

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

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

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

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

Действия, формирующие процесс построения организационной структуры, включают документирование и сопровождение описательных характеристик жизненных циклов разработки ПО. Цель интегрированного программного менеджмента области КРА на уровне 3 заключается в том, чтобы объединить программный инжиниринг и управленческую деятельность в логически последовательный определенный процесс разработки ПО, полученный в результате адаптации стандартного процесса разработки ПО в данной организации и связанных с ним ценных свойств процесса, описанных в "Определении процесса на уровне его структуры".

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

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

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

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

Определенный - указывается "способ, требуемый для выполнения дела";

Документированный - разработан таким образом, что может быть известным и используемым в дальнейшем;

Изученный - обучение на основе документации;

Практичный - может применяться на практике, а не откладываться в "долгий ящик";

Поддерживаемый - доступный, пересмотренный и улучшенный;

Контролируемый - изменения одобрены "участниками совместного дела";

Верифицирован - процесс выполняется корректно;

Проверен - выполняется именно тот процесс, который необходим;

Измеренный - оцененная производительность применяется в качестве базиса для контроля и улучшения процесса;

Способность к улучшению - гибкость и способность к изменениям.

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

Первое появление широко распространенного ПО датируется 1890 годом. Именно в это время в Американских центрах по проведению переписи населения появились перфокарты Германа Холерита (1860-1929 гг.), Массачусетский технологический институт, Кембридж, штат Массачусетс.

В это же время произошел первый перерасход средств по вине "компьютеров". Результаты центров по проведению переписи населения США изначально были протабулированы с помощью вспомогательных механических средств; механических табуляторов Германа Холлерита. В это же время и начало развиваться производство перфокарт. Средства, затраченные на табуляцию данных центров переписи населения, на 98 % превышали аналогичные затраты, понесенные в прошлом. Отчасти это объясняется тем, что шаблон, используемый при табуляции данных, был разработан весьма подробно и объем табулированных данных превышал минимально необходимое количество. Хотя и сам процесс табуляции был значительно ускорен. В это же время появились перфокарты, считывание которых выполнялось электрическим способом.

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

Рис. 2.1. Процесс уровня 2

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

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

Рис. 2.2. Процесс уровня 3

В рамках проектов происходит подгонка стандартных программных процессов организации для их конкретизации. Также интегрируются процессы менеджмента и программного инжиниринга. Возможности по выполнению стандартного процесса являются стандартными, а группа разработчиков несет ответственность за действия, выполняемые в программном проекте. Ниже перечислены области КРА для третьего уровня зрелости:

1) область действия организационного процесса;

2) определение организационного процесса;

3) инжиниринг программных продуктов;

4) комплексный менеджмент ПО;

5) взаимодействие между группами;

6) экспертные оценки;

7) учебная программа.

На уровне 3 процесс разработки ПО осуществляется на основе хорошо определенного процесса. Требуется осознание ролей и ответственности в ходе осуществления процесса. Процесс производства программного продукта отображается в ходе выполнения программного процесса.

Уровень 4 (рис. 2.3), т.е. "управляемый", включает две области КРА: количественный менеджмент процессов и управление качеством ПО.

Рис. 2.3. Процесс уровня 4

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

На уровне 5 ("оптимизация") области КРА сосредоточены на стадиях менеджмента изменений технологии, менеджмента изменений процесса и предотвращении дефектов. Благодаря непрерывному улучшению процесса осуществляется количественная обратная связь по отношению к процессу разработки программ. На этом уровне в организации могут апробироваться новые идеи и технологии, позволяющие улучшить качество программного продукта, что схематически изображено на рис. 2.4.

Рис. 2.4. Процесс уровня 5

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

1) процесс должен соответствовать культурным традициям организации;

2) менеджмент обязан способствовать повышению степени культуры;

3) культура должна способствовать внедрению ролевых моделей и наград.

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

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

Руководители таких организаций не всегда могут сформировать стратегию совершенствования и развития технологии деятельности своей компании; на рынке труда специалистов необходимой квалификации явно недостаточно. Вместе с тем в области совершенствования технологических процессов разработки и эксплуатации ПО международный опыт долгие годы был недостаточно обобщен и формализован. Только в начале 1990-х годов американский Институт программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model), определив уровни технологической зрелости и их отличительные черты. В течение десятилетия СММ прошла апробацию в целом ряде организаций, ее эффективность и достоверность проверили заказывающие организации, поставщики ПО, компании, осуществляющие разработку заказного ПО, занимающиеся оффшорным программированием.

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

Оценка технологической зрелости компаний может использоваться:

· заказчиком при отборе лучших исполнителей (например, в тендере);

· компаниями-производителями ПО для систематической оценки состояния своих технологических процессов и выбора направлений их совершенствования;

· компаниями, решившими пройти аттестацию, для оценки «размеров бедствия», т.е. своего текущего состояния;

· аудиторами для определения стандартной процедуры аттестации и проведения необходимых оценок;

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

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

Зрелость процессов (software process maturity) - это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации. Реальное использование процессов невозможно без их документирования и доведения до сведения персонала организации, без постоянного контроля и совершенствования их выполнения. Возможности хорошо продуманных процессов полностью определены. Повышение технологической зрелости процессов означает, что эффективность и качество результатов их выполнения могут постоянно возрастать.

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

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

Начиная с 1990 г. SEI при поддержке правительственных структур США и организаций-разработчиков ПО постоянно развивает и совершенствует эту модель, учитывая все новейшие достижения в области создания и сопровождения ПО.

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

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

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

Рис. 1.7. Пять уровней технологической зрелости СММ

Надписи на стрелках определяют особенности совершенствования процессов при переходе с уровня на уровень.

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

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

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

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

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

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

Каждый уровень СММ, начиная со второго, характеризуется наличием ряда так называемых основных групп процессов (key process areas - КРА). Модель СММ содержит 18 таких групп, последняя версия модели CMMI - 20 групп. Уровень 2 СММ характеризуется наличием в организации следующих процессов (их наименования соответствуют CMMI):

· управление требованиями;

· управление конфигурацией;

· планирование проекта;

· мониторинг и контроль проекта;

· управление контрактами;

· измерения и анализ;

· обеспечение качества процесса и продукта.

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

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

На данном уровне к процессам уровня 2 добавляются следующие процессы:

· спецификация требований;

· интеграция продукта;

· верификация;

· аттестация;

· стандартизация процессов организации;

· обучение;

· интегрированное управление проектом;

· управление рисками;

· анализ и принятие решений.

Основным критерием использования и, при необходимости, корректировки процессов на этом уровне является помощь звену управления и техническим специалистам в повышении эффективности выполнения проектов. На этом уровне в организации создается специальная группа, ответственная за состав операций, из которых состоят процессы, - группа по разработке процессов создания ПО (software engineering process group - SEPG).

На основе единой технологии для каждого проекта могут разрабатываться свои процессы с учетом его особенностей. Такие процессы в СММ называются «проектно-ориентированные процессы создания ПО» (project"s defined software process).

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

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

На уровне 4 добавляются следующие процессы:

· управление производительностью и продуктивностью;

· количественное управление проектом.

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

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

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

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

На уровне 5 добавляются следующие процессы:

· внедрение технологических и организационных инноваций;

· причинно-следственный анализ и разрешение проблем. Процессы создания и сопровождения ПО характеризуются

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

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

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

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

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

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

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

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

Четвертый и пятый уровни редко встречаются в индустрии ПО. Так, если третьего уровня достигло в мире несколько сотен компаний, то фирм пятого уровня (по информации SEI на 2002 г.) насчитывалось 62, а четвертого - 72. При этом отметим, что объявляют о своем уровне зрелости далеко не все компании. Одни не заинтересованы в афишировании своих организационных технологий, другие выполняют сертификацию просто под давлением заказчика.

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

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

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

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

К недостаткам СММ относятся следующие:

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

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

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

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

1. Неформальный процесс. Не имеет четко выраженной модели совершенствования. Его с успехом может использовать отдельная команда разработчи-

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

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

3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными инструментальные средства поддержки проектирования и анализа процессов (CASE-средства).

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

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

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

Рис. 1.8. Применимость процессов совершенствования

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

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

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

В.Ильин.

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