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

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

582 Глава 12

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

ответствующего участка процесса. В СММ выделены следующие пять разделов

КРА [20]:

• административные меры. В этом разделе описаны действия, которые

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

ность. Административные меры обычно касаются формирования политики и обес-

печения финансовой поддержки;

• необходимые предпосылки. В этом разделе описаны условия, которые

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

сти процесса (необходимые ресурсы, организационные структуры и система обу-

чения);

• выполняемые процедуры. В этом разделе описаны правила и процедуры,

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

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

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

сировке) и необходимой корректировке;

• измерение и анализ. В разделе описаны требования к проведению изме-

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

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

ределения состояния и эффективности процесса. Ключевые процедуры этого раз-

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

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

процедуры». Примеры предлагаемых метрик приводятся в качестве дополнитель-

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

метрики и подходы к измерению;

•

проведение проверки. В разделе описаны меры, предпринимаемые для

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

цесса. К методам проверки обычно относят обзоры и аудиторские проверки (реви-

зии) в ходе управления и обеспечения гарантии качества ПС. В этот раздел входят

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

и руководства проекта, а также каких либо действий по проверке надлежащего вы-

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

Только те практические действия, которые приводятся в разделе «выполняе-

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

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

делах, в целом образуют основу для их проведения в жизнь (внедрения).

Описание каждой процедуры (или приема) содержится в одном предложении

текста. Описанные таким образом процедуры называют также основополагающими

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

политики и практики по соответствующему ключевому направлению. Процедуры

предписывают «что» должно быть сделано для достижения целей, и не касаются

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

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

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

ли ключевая процедура, а также дополнительной информацией, включающей при-

меры и ссылки на другие КРА.

Глава 12 583

Предписанные СММ ключевые процедуры процесса не предъявляют каких-

либо требований к модели ЖЦ ПС, организационной структуре, распределению

обязанностей и ответственностей, подходам к управлению и разработке ПС. Они

акцентируют внимание на описании существенных элементов эффективного про-

цесса.

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

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

разработчиков. Эти критерии могут использоваться организациями-

разработчиками для улучшения процессов разработки и сопровождения ПС, а так-

же государственными и коммерческими организациями-заказчиками для оценки

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

ными организациями-исполнителями.

На базе СММ SEI разработал 2 метода оценивания зрелости процесса:

• метод SPA (от Software Process Assessment) - оценивание текущего со-

стояния процесса. Используется для обследования процесса программной инжене-

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

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

выработки соответствующей стратегии улучшения и получения поддержки со сто-

роны руководства [21];

• метод SCE (от Software Capability Evaluation) - оценка способностей ор-

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

занного с определенным проектом или контрактом с организацией-исполнителем

на разработку высококачественного ПО в соответствии с установленными сроками

и бюджетом. Может использоваться при определении потенциальных организаций-

исполнителей программных проектов или для управления эффективностью про-

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

разработки [22].

Методы SPA и SCE отличаются мотивацией, целями, структурой результи-

рующих данных и способами интерпретации результатов. А это, в свою очередь,

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

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

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

оценивания.

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

полняется регулярно (с периодичностью 18 - 36 месяцев) в условиях открытости и

сотрудничества с руководством и коллективом разработчиков.

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

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

дежных исполнителей проектов.

Основные шаги выполнения оценок по СММ методами SPA и SCE.

Шаг 1. Выбор группы экспертов, обученных основам СММ и специфике ме-

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

зации. Члены группы должны быть профессионалами в программной инженерии и

менеджменте.

584 Глава 12

Шаг 2. Получение от оцениваемой организации ответов на вопросы кон-

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

(приложение 7) [23].

Шаг 3. Анализ ответов и идентификация тех участков процесса, которые тре-

буют дальнейшего обследования. Эти участки соответствуют КРА в модели СММ.

Шаг 4. Посещение организации. Его цель - произвести интервьюирование

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

результатами анализа по вопроснику. Руководящими материалами в этом процессе

служат описание КРА и практических приемов СММ. В своей работе группа ис-

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

мере КРА удовлетворяют целям процесса по каждому направлению. В том случае,

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

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

своих решений по каждому направлению.

Шаг 5. По завершении работы в организации группа формирует перечень

«находок» (обнаруженных отклонений), которые идентифицируют сильные и сла-

бые стороны процесса в организации. Если целью работы группы является оцени-

вание текущего состояния и возможностей улучшения процесса в организации -

она дает руководству организации соответствующие рекомендации, если же цель -

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

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

Шаг 6. Группа готовит отчет, в котором в разрезе КРА показывает, по ка-

ким направлениям и в какой степени организация достигает или не достигает целей

КРА. Цели могут считаться достигнуты и в том случае, когда отмечены отдельные

недочеты, но они не касаются основных решений, по которым оценивается дости-

жимость целей.

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

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

по методу SPA, институтом SEI был предложен метод IP (от Interim Profile) - ме-

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

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

исполнителей проектов [24]. Условием применения этого метода является предва-

рительная оценка по методу SPA и наличие официально утвержденного плана ме-

роприятий по улучшению процесса в организации.

12.3.4. Иерархия оценок зрелости процесса по модели СММ

В общем случае, оцениванию подлежат (в приведенной последовательности):

• ключевые процедуры (если их оценка предусмотрена в плане работ по

SPA или SCE);

• разделы (если их оценка предусмотрена в плане работ по SPA или SCE);

• цели ключевого направления (всегда);

• ключевые направления уровня (всегда);

• уровень зрелости (если целью оценивания является определение уровня

зрелости).

Цель определенного КРА считается достигнутой (оценка «удовлетворитель-

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

Глава 12 585

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

тически и внедрены во все проекты организации. Оценка «не удовлетворительно»

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

и внедрении оцениваемых элементов СММ. Каждый метод оценивания может

предлагать расширенную шкалу ранжирования, учитывающую частичность реали-

зации целей КРА.

Ключевое направление процесса получает оценку «удовлетворительно», если

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

ному направлению. Если хотя бы одна из целей КРА не достигается (с оценкой

«удовлетворительно») - КРА получает оценку «не удовлетворительно».

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

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

СММ, а также все ключевые направления нижележащих уровней получили оценку

«удовлетворительно».

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

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

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

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

существования организации.

Организациям-разработчикам, совершенствование процессов в которых бу-

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

СММ, целесообразно:

• детально изучить цели и процедуры КРА второго уровня [20] (его описа-

ние доступно на сайте SEI);

• получить административную и финансовую поддержку;

• создать соответствующие организационные структуры и другие элементы

процесса, рекомендуемые СММ (см. главу 1, п.1.1.4 о требованиях к базовому про-

цессу организации);

• подготовить нормативно-методическую и учебную базу. Перечень необ-

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

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

ключевым направлениям, представлен в приложении 3;

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

• составить глобальный план работ по совершенствованию процесса орга-

низации, рассчитанный на 6 - 8 лет;

• обеспечить надлежащее управление работами.

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

Предлагаемая ниже процедура оценивания зрелости организаций-

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

(SPA, SCE, IP). Цель ее разработки авторами книги - предоставить организации-

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

проектов, концептуально согласующийся с СММ и адекватный уровню отечест-

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

586 Глава 12

Процедура ориентирована на ранжирование зрелости организации-

исполнителя по шкале от 0 до 2, где рейтинг 2 соответствует второму уровню зре-

лости по модели СММ.

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

вопросника SEI в части, касающейся уровня 2 СММ (приложение 7), и включает

следующую последовательность шагов:

Шаг 1. Организация-заказчик составляет проект паспорта программного

(системного) продукта, подлежащего разработке, по форме, представленной на ри-

сунке 12.10;

Паспорт программного продукта

___________________________________

(название)

разработанного _________________________________________

(название организации)

Класс системы

(например, АСУ ТП, АИС и др.)

Прикладная область

(например, бухгалтерский учет)

Масштабность:

• продолжительность

• количество исполнителей

• объем (размер) продукта

• степень повторного ис-

пользования

(в месяцах)

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

ботке)

(объем ПО в строках исходного кода или УЕФ)

(___% исходного кода, ___% модифицированного ко-

да, ___% повторно используемого кода)

Примечание (например, большое количество COTS -

большие затраты на разработку)

Долевое участие в работе

(например, головной исполнитель, все виды работ и

др.)

Организационный подход

(например, временный трудовой коллектив, интегри-

рованная группа и др.)

Языки и среды программи-

рования

используемые языки (среды) программирования

Заказчик

наименование организации-заказчика

Применяемые стандарты

(группа применяемых отечественных и международ-

ных стандартов)

Наличие соисполнителей

(да/нет, количество организаций-соисполнителей)

Новизна

(например, взамен действующей системы)

Платформа функционирова-

ния

характеристика аппаратной, программной и телеком-

муникационной среды

Другие требования

Ответственный исполнитель проекта: ________________ Подпись _________

Телефон __________________

Дата _______________

Рис. 12.10. Структура паспорта программного продукта

Глава 12 587

Шаг 2. Организация-заказчик рассылает претендентам на роль исполнителей

форму паспорта и контрольный вопросник;

Шаг 3. Организация-претендент, ознакомившись с проектом паспорта зака-

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

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

«схожих» с проектом, предлагаемым к разработке;

Шаг 4. Разработчик проекта заполняет паспорт разработанного (разрабаты-

ваемого) продукта по форме паспорта и отвечает на все вопросы контрольного

вопросника (приложение 7). Ответы на вопросы по каждому направлению простав-

ляются посредством отметки (знак «+» при ручном заполнении формы или число

«1» при машинном заполнении) в соответствующих колонках интервальной шка-

лы;

Шаг 5. Организация-претендент отсылает заполненные паспорта и контроль-

ные вопросники организации-заказчику;

Шаг 6. Эксперт организации-заказчика обрабатывает все паспорта и кон-

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

ганизации.

Обработка контрольных вопросников для получения оценок включает вы-

полнение следующих действий:

каждой оценке присваивается эквивалентный числовой коэффициент

(таблица 12.5).

Таблица 12.5. Коэффициенты для оценки ответов на вопросы

Оценка частоты выполнения процедур Коэффициент

Почти всегда 1

Часто 0.75

Иногда 0.5

Редко 0.25

Никогда 0

обрабатывается один вопросник для одного проекта: подсчитывается ко-

личество ответов по каждой оценке одного направления процесса (количество от-

меток «+» или «1» в столбце). Это количество ответов умножается на соответст-

вующий коэффициент и вычисляется их сумма. Затем эта сумма делится на коли-

чество вопросов, касающихся данного направления, и умножается на 100% (для

получения оценки достижимости целей направления в процентах).

Ниже приведен пример заполнения опросного листа по направлению «Управ-

ление требованиями» и оценка уровня достижимости целей по данному направле-

нию. Соответствующий опросный лист содержит 6 вопросов. Пример заполнения

опросного листа приведен в таблице 12.6. Вычисленная оценка КРА по ответам на

вопросы по данному направлению составляет

1 + 1

0.75 + 1

0.5 + 2

0) / 6 = 0.54

или в процентном отношении - 0.54

100% = 54%

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

проснике.

588 Глава 12

Таблица 12.6. Пример заполнения опросного листа

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

Почти

всегда

Часто

Иногда

Редко

Никогда

Не исполь-

зуется

1. Используются ли системные требования, делеги-

рованные ПО, в качестве основы для выполнения

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

2 Выполняется ли корректировка планов ПО, рабочих

продуктов и действий при изменении системных тре-

бований, делегированных ПО?

3. Руководствуется ли проект принятой в организа-

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

бованиями, делегированными ПО?

4. Прошли ли лица, которым поручено управление

делегированными требованиями, обучение приемам

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

5. Проводятся ли измерения с целью определения

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

делегированными требованиями (например, есть ли

учет общего числа предложенных изменений в тре-

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

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

версии и пр.)?

6. Подвергаются ли действия по управлению требо-

ваниями в проекте ревизиям с целью обеспечения

гарантии качества ПО?

3) подобным образом обрабатываются ответы на вопросы по всем проектам;

4) по завершении обработки опросных листов оценки по каждому направле-

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

Усредненная оценка направления по всем проектам вычисляется как медиана

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

правлению для пяти проектов были получены такие оценки:

54 58 75 79 80

то медианой ряда будет значение 75 и это будет средняя оценка данного на-

правления по представленным проектам.

5) полученные суммарные оценки проектов в процентах по каждому направ-

лению заносятся в итоговый отчет по форме, представленной в таблице 12.7.

6) для расчета уровня зрелости Lзр организации применяется формула:

)100/%(6/2

∑

⋅=

КРАLзр

где КРА%

- полученные суммарные оценки i-го проекта в процентах.

Глава 12 589

Таблица 12.7. Оценка уровня зрелости по КРА

КРА

Почти

всегда

>90%

случаев

Часто

60-90%

случаев

Почти

поровну

40-60%

случаев

От случая

к случаю

10-40%

Крайне

редко

< 10%

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

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

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

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

ми

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

ства

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

12.3.6. Интеграция моделей СММ (СММIntegration)

Модель CMMI выпущена в двух вариантах — стадийное представление (как

в SW-СММ) и непрерывное представление (как в SPICE) (рисунок 12.11).

- Обеспечение процессного подхода в организации

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

- Обучение в (на уровне) организации

- Выполнение процесса в организации

- Инновации и внедрение в организации

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

- Мониторинг и контроль проекта

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

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

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

- Количественное управление проектом

- Интегрированное обучение в проекте

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

- Разработка требований

- Технические решения

- Интеграция продукта

- Верификация

- Валидация

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

- Гарантия качества процесса и продукта

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

- Анализ причин и решение проблем

- Анализ и принятие решений

- Условия и среда в организации для интеграции

Управление

процессом

Управление

проектом

Инженерия

Поддержка

Уровень 5

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

Уровень 4

Количественно

управляемый

Уровень 3

Определенный

Уровень 2

Управляемый

Уровень 1

Начальный

К управлению проектом

К стандартизации

процесса

К количественному

управлению

процессом

К непрерывному

совершенствованию

процесса

Непрерывное представление Стадийное представлениеОбласти процессов

(Категории

процессов)

Рис. 12.11. Модель CMMI

В основе стадийного представления лежит концепция зрелости базового про-

цесса программной инженерии в организации в целом (5 уровней зрелости), а в ос-

нове непрерывного - концепция мощности процессов из четырех категорий (6

уровней мощности). В концепции мощности процессов рассматривается комплекс

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

а в концепции зрелости - комплекс процессов в масштабах всей организации.

590 Глава 12

Модель CMMI не предписывает, какие именно процессы должны быть учре-

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

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

качестве основы для улучшений.

Модель CMMI описана специалистами из SEI в [25, 26], а также достаточно

детально представлена в [27, 28].

12.4. Сертификация систем менеджмента качества

12.4.1.Стандарты для построения и проверки систем менеджмента каче-

ства

Под системой качества любого предприятия (организации) понимается со-

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

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

доставляемых услуг [29].

Побудительными причинами создания системы качества могут послужить:

• факторы государственного регулирования (необходимость лицензирова-

ния, подтверждения производителем современного научно-технического уровня);

• факторы гражданско-правовых отношений (необходимость получения

госзаказа, субподрядов и соответствия условиям тендеров);

• факторы рыночного регулирования (требования сертификации системы

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

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

безопасностью продукции));

• желание совершенствовать модель бизнеса (устранить «скрытое» произ-

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

требителей, реструктурировать управление организацией (улучшить управляе-

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

качества всех процессов и др.);

• необходимость продемонстрировать финансовую привлекательность и

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

Сфера действия системы качества определяется ее моделью. В 2004 году пре-

кратили действие стандарты серии ISO 9000 версии 1994 года, которые рекомендо-

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

ва и, соответственно, трех схем их сертификации. Действующая версия этой серии

стандартов (2000 года) основана не на бизнес–функциях (элементах качества), а на

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

ориентированного подхода.

В редакции 2000 года серия ISO 9000 регламентирует построение, внедрение

и использование эффективной системы менеджмента качества (СМК) в органи-

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

чества

Это же касается и стандартов ДСТУ, гармонизированных с соответствующими

стандартами ISO.

Глава 12 591

Нужно отметить, что ISO не только реструктурировала серию стандартов

9000, но и пересмотрела общую часть их названия. Теперь это стандарты не для

«систем качества» (quality systems), а для «систем менеджмента качества» (quality

management systems). Это еще раз подчеркивает важность гибкого управления каче-

ством с ориентацией на «удовлетворение потребностей потребителя относительно

качества продукции», а не просто обеспечения гарантий «соответствия продукции

установленным требованиям к качеству» (см. отличие определений процессов

«обеспечение гарантии качества» и «управление качеством» в начале главы 5).

Серия ISO 9000 включает следующие стандарты:

• ISO 9000:2000 (или ДСТУ ISO 9000:2001) «СМК. Основные положения и

словарь» – определяет основную терминологию в области качества и обеспечивает

ввод в действие системы менеджмента качества. Полный текст документа доступен

в Интернет, например, по адресу [30].

• ISO 9001:2000 (ДСТУ ISO 9001:2001) «СМК. Требования» – устанавли-

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

ветствие которым подтверждает способность организации обеспечить надлежащее

качество продукции [31].

• ISO 9004:2000 (ДСТУ ISO 9004:2001) «СМК. Руководящие указания по

улучшению деятельности» – обеспечивает руководство по внедрению широко раз-

витой СМК с целью постоянного совершенствования деловой деятельности [32].

Стандарты ISO 9001 и ISO 9004 разработаны как согласованная пара допол-

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

Стандарт ISO 9001:2000 устанавливает требования к СМК, которые предна-

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

заключения договоров (контрактов). Он формулирует минимальный набор усло-

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

дукции, отвечающей установленным требованиям и чаяниям потребителей. Преду-

сматривает 4 группы процессов связанных с СМК:

–

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

–

процессы обеспечения ресурсами,

–

процессы жизненного цикла продукции,

–

процессы измерения, анализа и улучшения.

Как видно из этого перечня, кроме процессов, непосредственно касающихся

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

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

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

ресурсы. Отмечается также усиление роли высшего руководства организации в раз-

витии и улучшении системы менеджмента качества.

Стандарт ISO 9004:2000 предоставляет руководство по внедрению и приме-

нению СМК для совершенствования работы организации в целом. Может исполь-

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

поскольку содержит рекомендуемую структуру СМК, характеристики ее основных

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

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

СМК. В стандарте также рассматриваются экономические аспекты качества, раз-

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