3.2. Задачи

Задачи по контролю качества включают в себя:

♦ документацию;

♦ обзорные собрания;

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

• валидацию (прежде всего тестирование);

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

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

3.3. Ответственность

В обязанности ответственного за качество входит следить за тем, чтобы зада­чи раздела 3.2 были сделаны, а требования данного документа были выполнены, в том числе чтобы были организованы обзорные собрания.

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

Обязанности ответственного за требования и ответственного за проектирова­ние описаны в разделе 6 данного документа.

4. Документация

4.1. Цель

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

4.2. Минимальные требования к документации

Должны быть созданы следующие документы.

• SQAP: План контроля качества (данный документ).

• SCMP: План управления конфигурациями.

• SPMP: План управления программным проектом.

♦ SRS: Спецификация требований к программному обеспечению.

• SDD: Проектная документация программного обеспечения.

• STD: Документация по тестированию программного обеспечения.

• Руководство пользователя.

• План сопровождения.

4.3. Прочее

План экспертизы программного обеспечения (SVVP) должен быть создан и под­держиваться независимо от SQAP.

5. Стандарты, практики, соглашения и метрики 5.1. Цель

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

5.2. Содержание

Стандарты.

Для ведения документации используются стандарты IEEE с соответствующи­ми модификациями.

Практики.

1. Все артефакты проекта подлежат инспектированию и все они доступны команде после выпуска разработчиком. Это достигается путем помещения артефактов в систему управления конфигурациями, обеспечивающей до­ступ к содержимому в любое время.

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

Соглашения.

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

Метрики.

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

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

2. Самооценка качества по шкале от 1 до 10; эти данные не могут быть ис­пользованы руководством для оценки персонала, однако их отсутствие мо­жет быть принято во внимание.

3. Количество дефектов на единицу объема (например, на тысячу строк кода).

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

• Требования: не более одного незначительного дефекта на сто детальных требований.

• Проектирование: не более одного незначительного дефекта на пять диа­грамм.

• Псевдокод: не более двух незначительных дефектов на тысячу строк.

• Код: не более двух незначительных дефектов на тысячу строк кода, не считая комментариев.

6. Обзоры и аудиты

6.1. Цель

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

6.2. Минимальные требования

План проведения обзоров описан в SPMP. Суть обзоров указана ниже.

6.2.1. Обзор требований к программному обеспечению

Данный обзор проводится по всему документу с требованиями в присутствии всей команды. Обзор ведет лидер проекта. Предполагается, что требования не были инспектированы до данного обзора. Данный обзор не подменяет инспекти­рование требований. Ответственный за требования обязан проследить, чтобы ин­спектирование требований состоялось (см. SPMP).

6.2.1А. Инспектирование требований к программному обеспечению

Все требования должны быть инспектированы в соответствии с Руководством по проведению инспектирования компании GCI, документ 345678.

6.2.2. Предварительный обзор проектных решений

Данный обзор альтернативных архитектурных решений выполняется всей коман­дой. Обзор проводится лидером проекта или его заместителем. Подразумевается, что команда даст предложения, которые будут учтены в окончательном варианте проекта. Альтернативные архитектуры не должны инспектироваться до данного обзора. Ответственный за проектирование обязан проследить, чтобы данный об­зор состоялся (см. SPMP).

6.2.3. Критический обзор проектных решений

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

6.2.4. Обзор SWP

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

6.2.5. Аудит функциональности

Лидер проекта перед поставкой продукта обязан организовать проверку того, что продукт соответствует SRS. Если необходимо сделать какие-то исключения, ли­дер проекта обязан получить предварительное разрешение на поставку от своего руководителя. Данные исключения должны быть доведены до сведения заказчи­ка с помощью соответствующих средств, в том числе файла README и сопроводи­тельного письма.

6.2.6. Аудит физических компонентов

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

6.2.7. Аудиты процесса

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

Поскольку организация движется в сторону СММ уровня 5, все рабочие ма­териалы должны быть свободно доступны аудиторам и команде в любое время. Работа должна быть четко организована, так чтобы аудиты можно было прово­дить и без предупреждения.