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

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

662

Приложение 7. КОНТРОЛЬНЫЕ ВОПРОСЫ ДЛЯ ОЦЕНКИ

ТЕХНОЛОГИЧЕСКОЙ ЗРЕЛОСТИ ОРГАНИЗАЦИИ

Представленный в данном приложении контрольный вопросник содержит

вопросы из вопросника SEI, касающиеся ключевых направлений технологического

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

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

По каждому ключевому направлению процесса (КРА, от Key Process Area) в

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

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

Перечень вопросов предваряется кратким описание данного КРА. Ответ на каждый

вопрос может быть прокомментирован.

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

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

сте выделяются курсивом.

7.1. Инструкция по заполнению опросных листов

Ответ на вопрос дается путем внесения отметки (“+” при ручном заполне-

нии или “1” при машинном заполнении ) в соответствующую графу формы: “Поч-

ти всегда”, “Часто”, “Иногда”, “Редко”, “Никогда” и “Не используется”. До-

пускается только одна отметка по соответствующей ключевой процедуре. Ответы

должны быть даны на все вопросы. Для краткости в формах используется сокра-

щенное обозначение отметок.

Отметка “Почти всегда” (ПВ) проставляется в том случае, если упомяну-

тая в вопросе процедура внедрена, обеспечена организационной, нормативно-

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

исключением чрезвычайных и фиксируемых случаев).

Отметка “Часто” (Ч) проставляется в том случае, если упомянутая в во-

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

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

мые в ней действия, как правило, выполняются надлежащим образом.

Отметка “Иногда” (И) проставляется в том случае, если упомянутые в

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

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

тельно их официальное внедрение в технологический процесс.

Отметка “Редко” (Р) проставляется в том случае, если упомянутые в во-

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

Отметка “Никогда” (Н) проставляется в том случае, если упомянутые в

вопросе действия никогда не выполняются. Эта отметка может также проставлять-

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

элементами КРА, к которым относится вопрос (например, если при ответах на во-

просы по КРА “Управление конфигурацией ПО” респондент не имеет четкого

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

7. Отметка “Не используется” (НИ) проставляется в том случае, если рес-

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

Приложение 7 663

тает, что постановка вопроса не применима к данному проекту. На уровне 2 СММ

такая ситуация возможна только для КРА “Управление работой соисполнителя”

(поскольку в условиях отсутствия соисполнителей проекта лишены смысла все во-

просы, относящиеся к КРА “Управление работой соисполнителя”). Эта отметка не

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

расчетных формул.

Поле “Комментарий” используется для обоснования ответа на вопрос (на-

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

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

ключевой процедуры).

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

Цель данного КРА состоит в формировании согласованного взгляда со сто-

роны заказчика и исполнителя проекта на пользовательские (технические и не тех-

нические) требования, которые должны быть реализованы в проекте ПО. Достиг-

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

контроля действий в ходе всего жизненного цикла проекта. При любом изменении

системных требований в части, касающейся проекта ПО, выполняется корректи-

ровка соответствующих планов, рабочих продуктов и действий с целью обеспече-

ния их согласованности с обновленными требованиями.

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

ПВ Ч И

Р Н

НИ

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

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

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

Комментарий:

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

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

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

Комментарий:

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

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

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

Комментарий:

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

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

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

Комментарий:

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

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

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

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

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

корректировок в базовой версии и пр.)?

Комментарий:

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

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

Комментарий:

664 Приложение 7

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

Цель данного КРА состоит в формировании обоснованных планов выполне-

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

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

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

Планирование проекта ПО ПВ Ч И

Р Н

НИ

1. Документируются ли оценки (например, размера, стои-

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

и контроле выполнения проекта ПО?

Комментарий:

2. Документируют ли планы ПО действия, которые должны

быть выполнены, и принятые соглашения по проекту ПО?

Комментарий:

3. Поддерживают ли все участники (группы и отдельные

лица) принятые соглашения по проекту ПО?

Комментарий:

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

литикой в части планирования проекта ПО?

Комментарий:

5. Имеются ли адекватные ресурсы для планирования про-

екта ПО (например, реальные денежные средства и опыт-

ные специалисты)?

Комментарий:

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

ности планирования проекта ПО (например, согласуются

ли между собой сроки завершения работ и др.)?

Комментарий:

7. Производит ли менеджер проекта как периодическую

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

нированию проекта?

Комментарий:

7.4. Мониторинг проекта ПО

Цель данного КРА состоит в обеспечении надлежащего наблюдения за раз-

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

действий при значительных отклонениях в выполнении проекта от планов ПО.

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

ПО для учета реальной ситуации, перепланировании оставшейся части работ или

принятии мер по улучшению характеристик проекта. Мониторинг проекта предпо-

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

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

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

Приложение 7 665

Мониторинг проекта ПО ПВ Ч И

Р Н

НИ

Совпадают ли реальные результаты реализации проекта

(например, по срокам, размеру и стоимости) с оценками,

приведенными в планах ПО?

Комментарий:

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

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

планов ПО проекта?

Комментарий:

3. Согласовываются ли изменения в принятых соглашениях

со всеми заинтересованными группами и лицами?

Комментарий:

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

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

работке ПО?

Комментарий:

5. Есть ли в проекте лицо, несущее определенную ответст-

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

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

та)?

Комментарий:

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

го состояния дел по мониторингу (например, общих затрат

усилий на выполнение мониторинга)?

Комментарий:

7. Производит ли менеджер проекта периодическую реви-

зию деятельности по мониторингу проекта (например, эф-

фективности реализации проекта, открытых вопросов, рис-

ка)?

Комментарий:

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

Цель данного КРА состоит в подборе квалифицированных соисполнителей

разработки ПО и эффективном управлении договорами на исполнение работ соис-

полнителями. Управление деятельностью соисполнителей предполагает выбор со-

исполнителя, принятие соглашений с соисполнителем и контроль за деятельностью

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

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

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

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

вора.

666 Приложение 7

Управление соисполнителями ПВ Ч И

Р Н

НИ

Используется ли документированная процедура (инст-

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

ности выполнять работу?

Комментарий:

2. Действительно ли изменения в договор вносятся только

по соглашению обеих сторон - головного исполнителя и

соисполнителя?

Комментарий:

3. Проводятся ли технические ревизии и согласования ха-

рактеристик разрабатываемого соисполнителем ПО (на-

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

заказчика и конечных пользователей или с целью проверки

правильности интерпретации и реализации технических

требований)?

Комментарий:

4. Контролируется ли соответствие результатов выполне-

ния работ соисполнителями принятым соглашениям?

Комментарий:

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

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

нителями?

Комментарий:

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

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

ления соисполнителями?

Комментарий:

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

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

(например, соблюдение план-графика выпуска релизов и

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

полнителей)?

Комментарий:

8. Производит ли менеджер проекта как периодическую

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

полнителей по договору?

Комментарий:

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

Цель данного КРА состоит в обеспечении руководства организации досто-

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

ПО. Обеспечение гарантии качества ПО (SQA, от Software Quality Assurance)

предполагает проведение ревизий и аудиторских проверок продуктов ПО и выпол-

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

Приложение 7 667

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

екта ПО о результатах этих ревизий и аудиторских проверок.

Обеспечение гарантии качества ПО ПВ Ч И

Р Н

НИ

Является ли обеспечение гарантии качества ПО (SQA)

плановой деятельностью?

Комментарий:

2. Обеспечивает ли SQA объективную проверку соответст-

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

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

Комментарий:

3. Доводятся ли результаты ревизий и аудиторских прове-

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

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

лей работ)?

Комментарий:

4. Выносятся ли на уровень высшего руководства пробле-

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

на уровне проекта (например, отклонения от применяемых

в организации стандартов)?

Комментарий:

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

литикой в части обеспечения качества ПО?

Комментарий:

6. Имеются ли адекватные ресурсы для проведения работы

по обеспечению качества ПО (например, реальные денеж-

ные средства или ответственное лицо, принимающее меры

относительно элементов проекта, по которым в ходе про-

верок отмечены нарушения) ?

Комментарий:

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

го состояния дел по обеспечения качества ПО в плане со-

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

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

ных средств)?

Комментарий:

8. Производит ли высшее руководство организации перио-

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

ПО?

Комментарий:

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

Цель данного КРА состоит в обеспечении целостности релизов ПО в ходе

жизненного цикла ПО проекта. Управление конфигурацией ПО (SCM, от Software

Сonfiguration Management) предполагает определение конфигурации ПО (напри-

668 Приложение 7

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

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

ности и трассируемости (прослеживаемости) конфигурации в ходе жизненного

цикла ПО. К релизам, включаемым в контур управления конфигурацией, относятся

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

(или требуемые для) создания этих продуктов ПО.

Управление конфигурацией ПО ПВ Ч И

Р Н

НИ

Является ли управление конфигурацией ПО (SCМ) пла-

новой деятельностью в проекте?

Комментарий:

2. Обладает ли проект идентифицируемыми, контролируе-

мыми и доступными рабочими продуктами ПО благодаря

использованию управления конфигурацией?

Комментарий:

3. Следует ли проект документированной процедуре с це-

лью контроля изменений в элементах конфигурации?

Комментарий:

4. Предоставляются ли заинтересованным группам и лицам

стандартные отчеты о базовой версии продукта?

Комментарий:

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

литикой в части управления конфигурацией ПО?

Комментарий:

6. Прошел ли персонал проекта, ответственный за управле-

ние конфигурацией, обучение приемам SCM?

Комментарий:

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

ния управления конфигурацией ПО (например, учет затрат

усилий и потраченных денежных средств на деятельность

по SCM)?

Комментарий:

8. Выполняются ли периодические аудиторские проверки

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

занной с этими базовыми версиями (например, группой

SCM)?

Комментарий:

7.8. Определение используемых терминов

Системные требования, делегированные ПО. Подмножество системных

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

системы. Делегированные требования являются основным исходным материалом

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

ния к ПО, оформляемые соответствующим документом.

Приложение 7 669

Планы ПО. Собрание формальных и неформальных планов, описывающих,

каким образом будут выполняться действия по разработке и/или сопровождению

ПО (примеры: план разработки ПО, план обеспечения качества ПО, план управле-

ния конфигурацией ПО, план тестирования ПО, план управления риском, план

улучшения процесса разработки ПО).

Рабочие продукты ПО. Результаты деятельности или решения задач в ходе

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

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

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

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

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

формацию по проекту ПО для использования будущими проектами (например,

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

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

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

решений.

Базовая версия продукта. Элементы программного продукта (проектные

решения, код и др.), которые по согласованию сторон проходят формальную реви-

зию в определенные моменты жизненного цикла ПО и в дальнейшем служат осно-

вой (базисом) для продолжения разработки.

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

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

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

продукта или необходимые замечания.

Обеспечение гарантии качества ПО (SQA - от Software Quality Assurance).

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

ботки и/или сопровождения рабочих продуктов и обеспечения гарантий их соот-

ветствия установленным техническим требованиям.

Соглашение. Договоренность, которая будет добровольно выполняться все-

ми участниками.

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

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

либо важных событий.

Событийная ревизия/деятельность. Ревизия или другая деятельность, ко-

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

ная ревизия или завершение стадии жизненного цикла).

Документированная процедура (Инструкция). Письменное описание по-

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

Релизы. Полное множество или любой из отдельных элементов множества

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

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

670 Приложение 7

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

представляют собой релизы.

Аудиторская проверка. Независимая проверка рабочего продукта или мно-

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

соглашениям и другим критериям.

Элемент конфигурации. Агрегация аппаратного, программного или обоих

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

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