Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

572 Глава 12

Нужно заметить, что оценивание процессов всегда должно проводиться с

учетом определенного контекста оценивания – ведь для одних целей оценивае-

мые процессы могут быть пригодны, для других – нет. Описанная здесь двумер-

ная модель оценивания является эталонной моделью и не может быть непосредст-

венно применена для оценивания, поскольку не существует «универсального» кон-

текста оценивания (не ясно, по каким именно показателям проводить оценивание).

12.2.2. Совместимая модель оценивания

Перед выполнением оценивания должна быть подобрана или разработана

уточненная модель оценивания, совместимая с эталонной моделью (рисунок 12.3).

Совместимая модель должна удовлетворять следующим требованиям.

Во-первых, она должна охватывать, по крайней мере, те процессы, которые

нужно оценивать (один или несколько).

Во-вторых, в ней должны быть подробно описаны конкретные практические

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

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

скими приемами.

В-третьих, должны быть четко определены рабочие продукты, которые су-

ществуют на входе процесса или появляются на его выходе.

ИЗМЕРЕНИЕ

ПРОЦЕССА

Уровень 1:

Выполнение

процесса

- Вносят ли вклад в достижение

цели процесса ?

- Существуют ли?

Адекватны ли?

Уровни с 2 по 5:

Мощность

процесса

- Свидетельствуют ли о

мощности процесса?

- Демонстрируют ли

достижение

атрибутов процесса ?

ИЗМЕРЕНИЕ

МОЩНОСТИ

Уровни мощности

Атрибуты процесса

Индикаторы

мощности процесса:

Процесс

Показатели

выполнения

процесса:

- Базовые

практические

приемы

- Рабочие продукты

- Характеристики

рабочих продуктов

- Практические

приемы руководства

- Характеристики

осуществления

приемов

ресурсов/

инфраструктуры

- Характеристики

Рис. 12.3. Совместимая модель оценивания

В-четвертых, в описании этих рабочих продуктов должны указываться ха-

рактеристики, по которым можно будет оценивать каждый рабочий продукт.

Кроме того, в этой же совместимой модели должны быть уточнены описания

атрибутов процесса, удовлетворяющие следующим требованиям.

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

дства процессом.

Во-вторых, для каждого приема руководства должны указываться характе-

ристики его осуществления (по которым можно судить о наличии руководства),

Глава 12 573

характеристики ресурсов и инфраструктуры (применяемые методы, инструмен-

ты), а также те процессы, с которыми может ассоциироваться данный прием руко-

водства.

12.2.3. Требования к оцениванию

Оценивание выполняет группа оценщиков во главе с ответственным оценщи-

ком. Группа пытается соотнести все, что делается по процессам, с тем, что опреде-

лено в совместимой модели, найти объективные данные относительно осуществле-

ния базовых практических приемов и приемов руководства, и в результате вырабо-

тать единое мнение о процессе.

Во входных данных для оценивания должно указываться следующее:

• личность инициатора оценивания;

• назначение оценивания;

• сфера оценивания, охватывающая:

– процессы, подлежащие исследованию;

– организационное подразделение, в котором протекают эти процессы;

– контекст (условия) применения процесса - размер и организационная

структура подразделения, предметная область, объём, критичность и слож-

ность продуктов или услуг, показатели качества продуктов.

Только учитывая контекст применения процесса, зафиксированный на

входе оценивания, оценщик сможет правильно оценить атрибуты и выста-

вить их рейтинги для конкретного процесса. Если, например, «процесс

управления проектом» выполняется в коллективе разработчиков из 5 человек,

у оценщика сформируется одно мнение относительно мощности этого про-

цесса, а если - из 50 человек – другое;

• ограничения при оценивании, касающиеся:

– доступных ключевых ресурсов (документов, которые можно читать,

людей, у которых можно брать интервью);

– максимального объёма времени, используемого при оценивании;

– особых процессов, не подлежащих оцениванию;

– прав собственности на результаты (продукты) оценивания и любых

ограничений по их использованию;

– особенностей управления информацией с учетом конфиденциальности

и др.

• идентификация совместимой модели;

• личности оценщиков, уровень их компетентности и ответственности;

• идентификация объектов оценивания и многое другое.

12.2.4. Этапы процесса оценивания

В стандарте ISO/IEC 12207 организационный процесс «оценивание процесса»

определен как компонент процесса «усовершенствование процесса». Его назначе-

ние «состоит в том, чтобы определить степень, в которой базовые процессы ЖЦ в

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

ганизации сосредоточиться на проблеме непрерывного совершенствования процес-

са. В результате успешного осуществления процесса:

574 Глава 12

• появится эффективный метод оценивания процесса, предназначенный

для определения способности организации и производственных процессов в ней

вырабатывать продукты и услуги, отвечающие целям;

• станут понятными относительные достоинства и недостатки базовых

процессов ЖЦ организации;

• будут храниться и сопровождаться тщательно подготовленные и доступ-

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

• проверки базовых процессов организации будут проводиться через над-

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

эффективности в свете результатов оценивания» [1].

В соответствии с ISO/IEC 15504-3 процесс оценивания должен включать, по

крайней мере, следующие этапы и виды деятельности [18].

Планирование. Для проведения оценивания разрабатывается и документиру-

ется план, определяющий требуемые входные данные, выполняемые действия при

проведении оценивания, ресурсы и время, выделяемое для выполнения этих дей-

ствий, состав и обязанности оценщиков, критерии для проверки выполнения требо-

ваний к оцениванию, описание продуктов, оценивание которых запланировано.

Независимо от того, как будут дальше употреблены результаты оценивания,

изначально устанавливается потребность в оценивании тех или иных процессов.

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

определенной поставленной цели. С помощью совместимой модели оценивания

устанавливается соответствие между оцениваемыми процессами и процессами, оп-

ределёнными в эталонной модели процессов в стандарте ISO/IEC 12207. Для этих

процессов далее выбираются атрибуты (важные аспекты руководства этими про-

цессами), достижение которых сможет оказать существенное влияние на выполне-

ние процессов. Указывается целевой рейтинг каждого атрибута (достаточный, для

того чтобы достичь цели) (как, например, на рисунке 12.4). Обычно рейтинги ниже

«существенного» не устанавливаются. Просто атрибуты не оцениваются.

Процесс _________________ Уровни мощности процесса

Атрибуты процесса 1 2 3 4 5

АП 1.1

Выполнимость процесса С/П П П П П

АП 2.1

Управляемость выполнением С/П П П П

АП 2.2

Управляемость рабочими продуктами С/П П П П

АП 3.1

Определенность С/П П П

АП 3.2

Используемость ресурсов С/П П П

АП 4.1

Измеримость С/П П

АП 4.2

Контролируемость выполнения С/П П

АП 5.1

Контролируемость модификации С/П

АП 5.2

Непрерывность усовершенствования

С/П

Профиль

Рис. 12.4. Рейтинги уровня мощности

Сбор данных. Каждый процесс, выбранный для оценивания, оценивается на

основании объективных сведений о его атрибутах. Стратегия и методики сбора,

Глава 12 575

анализа данных и обоснования рейтингов должны быть точно идентифицированы и

наглядны. Чтобы обеспечить основания для верификации рейтингов, объективные

сведения, поддерживающие мнение оценщика о рейтингах атрибута процесса, про-

токолируются и сохраняются.

Валидация данных. Все собранные данные, необходимые для охвата сферы

оценивания, проверяются и утверждаются.

Определение рейтинга процесса. На основании утвержденных данных каж-

дому атрибуту процесса присваивается оцененный рейтинг. Множество рейтингов

атрибута процесса протоколируется как профиль мощности процесса для опреде-

лённого организационного подразделения (см. рисунок 12.4).

Если оцененный рейтинг совпадает с целевым - делается вывод о том, что по

соответствующему аспекту руководства проблем с процессом быть не должно. Ес-

ли есть расхождения – вывод о том, что существует риск не достичь цели процесса

из-за нечеткости руководства процессом (рисунок 12.5).

Атрибуты процесса

Процесс

1.1 2.1 2.2 3.1 3.2 4.1 4.2 5.1 5.2

Целевой Выявление

требований

Оцененный

Целевой Поддержка

потребителя

Оцененный

Целевой Проектиро-

вание ПО

Оцененный

Целевой Построение

ПО

Оцененный

Целевой Испытания

ПО

Оцененный

Рис. 12.5. Целевая мощность вместе с оцененной мощностью

Для того чтобы оценить расхождения по каждому атрибуту и по совокупно-

сти атрибутов, составляющих мощность процесса в целом, стандарт ISO/IEC 15504-

3 предлагает соответствующие таблицы (таблица 12.3 и таблица 12.4).

Таблица 12.3. Расхождение по атрибуту процесса

Целевой рейтинг Оцененный рейтинг Расхождение по атрибуту

Полностью достигнут

Нет

Существенно достигнут

Малое

Частично достигнут

Большое

Полностью дос-

тигнут

Не достигнут

Большое

Полностью достигнут

Нет

Существенно достигнут

Нет

Частично достигнут

Большое

Существенно дос-

тигнут

Не достигнут

Большое

576 Глава 12

Таблица 12.4. Расхождения на уровне мощности

Количество расхождений атрибутов процесса

Расхождение на

уровне мощности

Нет больших или малых расхождений

Нет

Только малые расхождения

Незначительное

Единственное, но большое расхождение на уровне мощности со 2

по 5

Значительное

Единственное, но большое расхождение на уровне мощности 1

или более одного большого расхождения на уровне мощности со

2 по 5

Существенное

Чем выше расхождение в целевой и оцененной мощности, тем больше веро-

ятность того, что процесс неустойчив и может не соответствовать тем целям, для

которых его хотят применить.

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

и чем больше величина расхождения целевой и ожидаемой мощности, тем боль-

шими могут быть потери, связанные с тем, что процесс не будет эффективен в дос-

тижении тех целей, для которых он выбран (рисунок 12.6).

Величина расхождения на уровне мощности (вероятность)

Размещение расхождения на

уровне мощности (влияние)

Нет Незначи-

тельная

Значитель-

ная

Существен-

ная

Оптимизируемый

Риск не

обнаружен

Низкий

риск

Низкий риск Низкий риск

Предсказуемый

Риск не

обнаружен

Низкий

риск

Низкий риск Средний

риск

Установившийся

Риск не

обнаружен

Низкий

риск

Средний риск Средний

риск

Управляемый

Риск не

обнаружен

Средний

риск

Средний риск Высокий

риск

Выполняемый

Риск не

обнаружен

Средний

риск

Высокий риск

Высокий

риск

Рис. 12.6. Полный процессо-ориентированный риск

Как видно на рисунке 12.6, если оцениваемый процесс находится на высоком

уровне мощности (первая строка матрицы), небольшие отклонения в мощности не

так уж страшны, риск невелик.

Составление отчёта. Отчет о результатах оценивания включает описание

входных данных для оценивания, собранных объективных данных, использованно-

го подхода к оцениванию, а также множество профилей мощности процессов (по

одному для каждого оцененного процесса). По завершении процесса оценивания

этот отчет направляется инициатору оценивания.

Глава 12 577

12.3. Оценивание зрелости организаций-разработчиков

12.3.1. Модели зрелости

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

программных систем, предлагаемой стандартом ISO/IEC 15504, существует множе-

ство других моделей, совсем новых и относительно старых (начала 90-х годов),

стандартизованных и не стандартизованных. Они разработаны в разных странах и в

разной степени распространены. Степень их распространения (или предпочтения)

можно определять по территориальному, ведомственному и другим признакам.

Многие сайты в Интернете предлагают свои путеводители по моделям. Один

такой путеводитель представлен на рисунке 12.7. Это страничка «Frameworks

Quagmire», разработанная фирмой Software Productivity Consortium (и представлена

на сайте GDPA - http://www.tzi.de/~uniform/gdpa/director/products/jq002.htm).

Рис. 12.7. Путеводитель по моделям зрелости процессов разработки

Нужно отметить, что в связи с выходом стандарта ISO/IEC 15504, который

требует применения для оценивания моделей, совместимых с эталонной, разра-

ботчики многих моделей зрелости продолжают их развивать в направлении обес-

печения необходимой совместимости.

Наиболее известным (и широко используемым не только в Америке, но и на

других континентах) является семейство моделей зрелости CMMs (Capability Ma-

turity Models), включающее:

• SW-CMM (CMM for Software)— модель зрелости процесса разработки

программных продуктов,

• SE-CMM (System Engineering CMM) — модель зрелости процесса систем-

ной инженерии,

• SSE-CMM (System Security Engineering CMM) – модель зрелости процесса

обеспечения безопасности системы,

578 Глава 12

• SA-CMM (Software Acquisition CMM) — модель зрелости процесса заку-

пок ПО,

• People CMM — модель зрелости процесса управления кадрами,

• IPD-CMM (Integrated Product Development CMM) – модель зрелости разра-

ботки интегрированных продуктов,

• ряд других моделей, созданных при поддержке SEI и объединяющих идеи

разных моделей SEI, например, модель FAA-iCMM, разработанная Federal Aviation

Administration и охватывающая возможности SW-CMM и SE-CMM.

Однако, при таком обилии моделей, их практическое применение вызвало

проблемы, связанные со следующими факторами:

• модели имели разную структуру, форматы представления информации,

терминологию, способы измерения зрелости,

• происходила путаница при применении более одной модели и при пере-

ходе от одной модели к другой,

• сложно было определить интегральную оценку зрелости на базе оценок по

отдельным моделям и, как следствие, сложно интерпретировать оценки и исполь-

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

• сложно использовать множество моделей для выбора поставщиков про-

дукции (а это была первично основная цель разработки моделей СММ),

• модели не согласовывались с требованиями международных стандартов в

области качества.

Поэтому в 2002 году SEI опубликовал новую модель CMMI (Capability

Maturity Model Integration), объединяющую ранее выпущенные модели и учиты-

вающую требования международных стандартов.

В этом разделе мы подробнее рассматриваем только первую (исторически)

модель - модель SW-CMM (Capability Maturity Model for Software), предложенную

У. Хамфри в 1987 году и опубликованнyю SEI в 1993 году [19], а также очень сжа-

то характеризуем Интеграцию моделей СММ (CMMI).

Модель СММ уже была кратко описана в главе 1 (п.1.2.5). Напомним ее ос-

новные отличия от модели SPICE, лежащей в основе стандарта ISO/IEC 15504.

Модель SPICE может использоваться для оценивания уровня мощности и со-

вершенствования любого одного или совокупности процессов ЖЦ, выбираемых для

оценивания с определенной целью. Фактически оцениваются базовые практиче-

ские приемы процесса (характеристика их выполнения), рабочие продукты процес-

са (их наличие), характеристики рабочих продуктов (их наличие), а также приемы

руководства (характеристика их выполнения) и характеристики ресурсов и ин-

фраструктуры (их наличие). Результат оценивания – вектор - профиль мощности

процесса (уровень мощности (от 0 до 5) и рейтинги атрибутов мощности на дан-

ном уровне мощности).

Модель CMM может использоваться для оценивания и совершенствования

процесса программной инженерии (в целом) в организации (поэтому ее обычно и

называют моделью зрелости (совершенства) организации, а не отдельных процес-

сов ЖЦ).

Глава 12 579

12.3.2. Уровни зрелости процесса программной инженерии по СММ

СММ - это описательная модель в том смысле, что она описывает сущест-

венные (или ключевые) атрибуты, которыми должен обладать процесс в организа-

ции, находящейся на определенном уровне зрелости. В то же время СММ - норма-

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

должны применяться. СММ обеспечивает достаточный уровень абстракции и не

накладывает ограничений на способы реализации процесса в организации.

В любом контексте применения СММ, должна существовать разумная ин-

терпретация практических приемов. СММ нельзя считать предписывающей моде-

лью, поскольку она дает ответ на вопрос, какими свойствами должен обладать про-

цесс в организации, имеющей тот или иной уровень зрелости, но не говорит о том,

какими средствами обеспечить улучшение процесса и достижение соответствую-

щего уровня.

Модель СММ (здесь и далее имеется в виду SW-CMM) выделяет и дает стро-

гое описание 18 ключевых направлений (областей, участков) процесса KPA (Key

Process Areas) программной инженерии (схожих по назначению с поддерживаю-

щими и организационными процессами ЖЦ в ISO/IEC 15504), которые «распреде-

лены» по уровням зрелости (от 2 до 5).

Для того чтобы организация достигла определенного уровня зрелости, она

должна внедрить (институциализировать) соответствующее множество KPA и пре-

доставить экспертам (имеющим права оценивания и владеющим методами экс-

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

программной инженерии. Результат оценивания – сертификат уровня зрелости

и/или рекомендации по дальнейшему совершенствованию процесса.

Пять уровней зрелости СММ, ассоциированных с КРА, представлены на ри-

сунке 12.8. Надпись на стрелке указывает уровень достигнутой мощности процес-

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

зрелости. Названия уровней зрелости отражают сущность изменений в основном

процессе программной инженерии.

Уровень зрелости определяет проблемы, которые преобладают на этом

уровне. Например, на уровне 1 основная проблема касается управления, а осталь-

ные проблемы скрыты из-за сложности планирования и управления программными

проектами.

Каждый уровень образует фундамент для эффективной реализации процес-

сов на последующих уровнях. Пропуск уровней противоестественен.

Организации могут с успехом использовать (внедрять) направления процес-

са, описанные на вышележащих уровнях, находясь при этом на более низком уров-

не. Однако, направления, не отнесенные к, но применяемые на нижележащих уров-

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

ветствующий фундамент на нижних уровнях СММ.

Таким образом, СММ идентифицирует уровни, через которые организация

должна эволюционировать для утверждения культуры программной инженерии.

580 Глава 12

Управление изменениями в процессах

Управление изменениями в технологии

Предупреждение ошибок

Управление качеством

Управление процессом на основе

количественных оценок

Начальный (1)

Повторяемый (2)

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

Обеспечение гарантии качества

Управление работой соисполнителя

Мониторинг проекта

Планирование проекта

Управление требованиями

Коллективный просмотр

Межгрупповая координация

Инженерный подход к разработке продукта

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

Организация обучения

Определение процесса организации

Обеспечение разработки процессов

Оптимизируемый (5)

Управляемый (4)

Фиксированный (3)

Упорядо-

ченный

процесс

Установив-

шийся

процесс

Предсказуемый

процесс

Непрерывно

улучшаемый

процесс

Рис. 12.8. Уровни зрелости в модели СММ

Организации, находящиеся на 1 уровне и пытающиеся создать фиксирован-

ный процесс (уровень 3), не создав перед тем повторяемый процесс (уровень 2),

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

ны проблемами сроков и стоимости проекта. Это основная причина, по которой

нужно сначала усовершенствовать процесс управления, а затем процессы собст-

венно инженерии.

Может показаться, что определить и реализовать процесс инженерии легче,

чем процесс управления (особенно с точки зрения разработчика), но без дисципли-

ны управления процесс инженерии неминуемо скатится к проблемам сроков и

стоимости. Способность организации осуществлять деятельность по направлениям,

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

через уровни зрелости.

КРА сгруппированы по уровням зрелости таким образом, что каждое КРА

всегда относится только к одному уровню СММ. Хотя в организации, находящей-

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

правлений, относящихся к другим уровням зрелости, - заключение о том, какой

Глава 12 581

уровень зрелости занимает организация, делается только по КРА, соответствую-

щим данному уровню.

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

различий в проблемных областях или средах. Несмотря на это все цели направления

должны быть достигнуты для того, чтобы организация преуспела по данному на-

правлению. Когда цели направления достигаются безусловно по всем проектам в

организации, можно считать, что это направление имеет статус официально утвер-

жденного, а соответствующие процедуры процесса внедрены во все проекты орга-

низации.

Приставка «ключевой» говорит о том, что существуют и другие направления

процесса, которые хотя и влияют на его результативность, но не являются ключе-

выми для достижения уровня зрелости. Ключевые направления определены SEI по

результатам многолетнего опыта программной инженерии и управления и пятилет-

него опыта аналитического и экспертного оценивания процесса программной ин-

женерии.

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

рован на составные части (рисунок 12.9).

Уровни зрелости

Возможности

процесса

Ключевые направления

процесса

Цели

Разделы

Ключевые приемы

(процедуры)

определяют включают

достигают

организованы в виде

Администра-

тивные меры

Необходимые

предпосылки

Выполняемые

процедуры

Проведение

проверки

Измерение

и анализ

касаются аспектов

деятельности

содержат описание

Рис. 12.9. Структура уровня зрелости в модели СММ

Каждое направление представлено пятью разделами, а каждый раздел опре-

деляет перечень рекомендуемых практических действий (приемов, процедур). При

выполнении всех рекомендуемых действий достигаются цели, которые являются

приоритетными для соответствующего ключевого направления процесса (считают-

ся важными для расширения возможностей процесса).