Добавлен: 25.10.2018
Просмотров: 4932
Скачиваний: 12
61
Помимо этих документов в исходном коде на Java будет использоваться Javadoc и, таким об-
разом, можно будет генерировать документацию на уровне пакетов, классов и функций.
4.3. Прочее
План экспертизы программного обеспечения (SVVP) должен быть создан и поддерживаться
независимо от SQAP.
5. Стандарты, практики, соглашения и метрики
5.1. Цель
[Данный раздел описывает стандарты, практики, соглашения и метрики, используемые в проекте.
Эти материалы призваны не только обеспечить качество проекта, но и получить количественные
данные о самом процессе контроля качества.]
5.2. Содержание
Стандарты.
Для ведения документации используются стандарты IEEE с соответствующими модификациями.
Практики.
1. При проектировании поощряется применять процедуры обеспечения качества.
2. Все артефакты проекта подлежат инспектированию и все они доступны после выпуска. Это дости-
гается путем помещения артефактов в систему управления конфигурациями, обеспечивающей доступ
к содержимому в любое время.
3. Для всех процессов должен быть проведен обзор возможности улучшения хотя бы раз, и результа-
ты этого обзора в письменной форме должны быть направлены в лабораторию технологии програм-
мирования (раздел 6.2.10).
Соглашения.
Служба контроля качества организует трехчасовые курсы по изучению принятых соглашений
ежемесячно. Присутствие на этих курсах оплачивается из накладных расходов организации.
Метрики.
Для каждого процесса и каждого документа должны измеряться по меньшей мере три показа-
теля.
1. Время, затраченное сотрудником, на выполнение каждой подзадачи.
2. Самооценка качества по шкале от 1 до 10.
3. Количество дефектов на единицу объема (например, на тысячу строк кода).
Автор данного проекта ставит перед собой цель достичь следующих показателей качества
своих продуктов.
[Числа, использованные ниже, должны опираться на собранные ранее данные и отражать требуе-
мый уровень соответствия ПЗ требованиям (см. табл. 8 на стр. 45).]
Ограничения на число дефектов, обнаруживаемых в течение двух месяцев после поставки.
• Анализ требований: не более одного незначительного дефекта на сто детальных требований.
• Проектирование архитектуры: не более одного незначительного дефекта на пять диаграмм.
• Детальное проектирование: не более двух незначительных дефектов на тысячу строк.
• Кодирование: не более двух незначительных дефектов на тысячу строк кода, не считая ком-
ментариев.
Фактические данные по проекту должны быть представлены в приложении 1 к данному доку-
менту.
6. Обзоры и аудиты
6.1. Цель
[Цель обзоров и аудитов состоит в том, чтобы привлечь внимание разработчиков к качеству при-
ложения в ходе разработки. Обзоры проводятся на плановой регулярной основе. Объекты аудита
выбираются случайным образом.]
6.2. Минимальные требования
[В больших проектах требуется полный список обзоров и аудитов, приведенный здесь. В рамках кур-
сового проекта необходимо как минимум провести инспектирование требований и проектирования.]
План проведения обзоров описан в SPMP. Суть обзоров указана ниже.
6.2.1. Обзор требований к программному обеспечению
Данный обзор проводится по всему документу с требованиями в присутствии всей команды.
Обзор ведет лидер проекта. Предполагается, что требования не были инспектированы до данного об-
зора. Данный обзор не подменяет инспектирование требований. Ответственный за требования обязан
проследить, чтобы инспектирование требований состоялось (см. SPMP).
6.2.2. Предварительный обзор проектных решений
62
Данный обзор альтернативных архитектурных решений выполняется всей командой. Обзор
проводится лидером проекта или его заместителем. Подразумевается, что команда даст предложения,
которые будут учтены в окончательном варианте проекта. Альтернативные архитектуры не должны
инспектироваться до данного обзора. Ответственный за проектирование обязан проследить, чтобы
данный обзор состоялся (см. SPMP).
6.2.3. Критический обзор проектных решений
Это инспектирование предложенной архитектуры в присутствии всей команды. Ответствен-
ный за проектирование обязан проследить, чтобы это инспектирование состоялось. Архитектура не
должна инспектироваться до данного обзора. Если это возможно, архитектура должны быть разложе-
на на составные части и по каждой из них должен быть проведен критический обзор проектных ре-
шений.
6.2.4. Обзор SVVP
Поскольку верификация и валидация должны выполняться независимой командой, в данном
плане не предусматривается обзор SVVP.
6.2.5. Аудит функциональности
Лидер проекта перед поставкой продукта обязан организовать проверку того, что продукт со-
ответствует SRS. Если необходимо сделать какие-то исключения, лидер проекта обязан получить
предварительное разрешение на поставку от своего руководителя. Данные исключения должны быть
доведены до сведения заказчика.
6.2.6. Аудит физических компонентов
До поставки ответственный за качество обязан организовать проверку того, что программное
обеспечение и документация, предназначенные для поставки, физически включены в пакет поставки.
6.2.7. Аудиты процесса
Персонал проекта должен быть готов к внезапным аудитам своей работы. Аудит состоит в по-
сещении рабочих мест командой, назначенной руководством отдела. Об аудитах следует предупреж-
дать накануне. Предметом аудита является текущая работа отдельного разработчика или команды.
Поскольку организация движется в сторону СММ уровня 5, все рабочие материалы должны
быть свободно доступны аудиторам и команде в любое время. Работа должна быть четко организова-
на, так чтобы аудиты можно было проводить без предупреждения.
6.2.8. Обзор управления
Высшее руководство должно проводить обзор проекта в первую неделю каждого месяца. Ли-
дер проекта ответственен за организацию таких обзоров.
6.2.9. Обзор SCMP
Ответственный за качество должен проводить обзор состояния управления конфигурациями
не реже раза в месяц независимо от процедур, установленных в плане управления конфигурациями.
6.2.10. Заключительный обзор
Команда проекта должна проводить заключительный обзор после выполнения каждой фазы,
для того чтобы накопить данные для последующих проектов. В заключительный обзор включается
как обзор только что завершенной фазы, так и обзор самого процесса контроля качества. Ответствен-
ный за качество обязан составлять отчет об улучшении процесса по каждой фазе и предоставлять его
руководству.
6.3. Инспектирование
[В учебном проекте инспектирование проводится опекуном. В данном разделе описывается процесс
инспектирования, который включает выполнение следующих шагов: (i) планирование; (ii) подготов-
ка; (iii) проведение инспектирования; (iv) анализ причин появления дефектов; (v) коррекция; (vi) со-
ставление отчета]
7. Тестирование
[Здесь определяется, как будет осуществляться управление тестированием. Данный текст может
ссылаться на STD, но не должен дублировать ее.]
На первых трех итерациях все функции по контролю качества выполняет ответственный за
качество. На последующих итерациях отдел контроля качества должен выделить команду по контро-
лю качества и передать ей эти функции. Описание команды по контролю качества будет представле-
но. Команда проекта несет ответственность за тестирование отдельных методов и комбинаций мето-
дов в классе (модульное тестирование). Ответственный за качество (в дальнейшем — команда по
контролю качества) ответственен за все остальные виды тестирования.
8. Отчеты о проблемах и коррекционная деятельность
63
[В этом разделе объясняется, каким образом дефекты становятся известными, описываются и
устраняются. Для отслеживания дефектов и их состояния, как правило, используется специальное
программное обеспечение.]
Форма отчета об обнаруженном дефекте в программном обеспечении, которую должна ис-
пользовать команда проекта, представлена на рис. Ж.1. Для заполнения этой формы разработчики
используют специальное приложение describeDefect. Номер дефекта определяется автоматически, и
приложение гарантирует заполнение всех необходимых полей.
1. Номер дефекта: 2.
Кто обнаружил:
3. Затрагивает документы:
Затрагивает исходный код* 4.
Пакет(ы)
5. Класс(ы)
6.
Метод(ы)
7. Серьезность:
8.
Тип:
9. Фаза появления**
Треб □ Арх □ Дет. проект. □
Реализ. □ Интегр. □
10. Детальное описание:
11. Решение: 12.
Статус открыт/закрыт:
13. Подписи: описание и план инспектированы:
14. Код решения и план тестирования инспектированы:
15. Изменение одобрено:
*Для дефектов в исходном коде **Самая ранняя фаза, на которой дефект уже существовал
Рис. Ж.1 Форма отчета об обнаруженном дефекте в программном обеспечении
Различаются следующие значения уровня серьезности дефектов:
• Серьезный дефект: наличие такого дефекта влечет невыполнение требований к программному
обеспечению.
• Тривиальный дефект: такой дефект не влияет на выполнение или сопровождение приложения.
• Незначительный дефект: дефект, который не относится к двум предыдущим категориям.
В случае обнаружения тривиального дефекта разработчик не обязан создавать отчет о дефекте —
достаточно послать сообщение по электронной почте тому, кто наиболее вероятно может устранить
этот дефект.
В документах могут встречаться дефекты следующих типов: отсутствие материала, неясность,
неоднозначность, неполнота, повтор (в том же документе или в другом) и противоречие.
В исходном коде могут встречаться следующие типы дефектов: синтаксические, логические,
ошибки в данных (то есть переменная принимает недопустимое значение) и нарушения режима безо-
пасности (то есть возможен недопустимый обход правил безопасности).
Ответственный за качество (а в дальнейшем команда по контролю качества) создает и поддержи-
вает базу данных дефектов, в которой собраны отчеты о дефектах, описывающих все проблемы, не-
соответствия и аномалии проекта. Ответственный за качество должен обеспечить систематическую
фиксацию найденных дефектов по указанной форме, направление их на рассмотрение и устранение.
Направление дефектов на рассмотрение должно производиться в соответствии с SCMP.
9. Инструменты, технологии и методики
Методы управления качеством включают использование стандартов, прослеживание требова-
ний, верификацию проектирования, инспектирование программного обеспечения и верификацию
формальными методами. Инструменты управления качеством включают в себя программы верифи-
кации программного обеспечения, списки контрольных вопросов, наклейки на носителях и штампы о
приемке. Списки контрольных вопросов будут получены в лаборатории технологии программирова-
ния и адаптированы для проекта в соответствии с рекомендациями NASA.
Дополнительные инструменты, технологии и методы управления качеством описаны в SPMP.
10. Контроль программного кода
Методы и средства, используемые для поддержки, хранения и документирования версий ком-
пилируемого программного кода на всех фазах жизненного цикла, определены в SCMP. Команда по
контролю качества должна убедиться, что процедуры, указанные в SCMP, действительно выполня-
ются.
64
11. Контроль носителей
[Здесь описываются правила обращения с дисками, лентами и т. п.]
Команда по контролю качества проверяет, что носители, используемые для управления кон-
фигурациями, установлены и протестированы. Факт проверки носителя командой по контролю каче-
ства удостоверяется с помощью штампа на наклейке. По результатам проверки носителей представ-
ляется отчет.
12. Контроль поставщиков
[Данный раздел регулирует взаимоотношения с поставщиками программного и аппаратного обеспе-
чения. Здесь описывается, как и кто осуществляет эти отношения.]
Команда по контролю качества проверяет закупленные коммерческие программные продукты
во время начальной проверки, удостоверившись, что имеются документы, подтверждающие целост-
ность и версию продукта. Продукты валидируются в процессе установки и приемосдаточного тести-
рования.
13. Сбор, сопровождение и хранение протоколов
[Здесь определяется, как физически будут храниться записи и кто за них отвечает. Сюда же отно-
сятся файлы, которые не находятся под управлением конфигурациями.]
Записи, которые собирает и хранит команда по контролю качества, включают в себя:
• отчеты о выполненной работе;
• отчеты об обнаруженных аномалиях, которые составлены не по обычной форме отчетов о де-
фектах;
• ….
Помимо проверки того, что процедуры архивирования, предписанные SCMP, выполняются,
команда по контролю качества должна архивировать свои собственные материалы не реже раза в не-
делю. Эти записи должны храниться и на фазах сопровождения и эксплуатации.
14. Обучение
Для участников команды разработчиков должен быть организован вводный курс по качеству
на 4 часа. Курс должен включать описание метрик, которые будут использоваться, и лабораторное
занятие по изучению инструментов для сбора метрик. Далее, должны быть организованы ежемесяч-
ные трехчасовые занятия для того, чтобы поддерживать у разработчиков знания инструментов и ме-
тодов контроля качества. Разработчики могут не присутствовать на этих занятиях, если они получают
оценку «отлично», пройдя тест на сайте по адресу GCI/monthly/SQA/quiz.
15. Управление рисками
Команда контроля качества должна стараться обнаружить факторы риска как можно раньше. Проце-
дуры управления рисками описаны в разделе 3.3 SPMP.
65
ПРИЛОЖЕНИЕ И
(справочное)
IEEE 1058.1-1987 ПЛАН УПРАВЛЕНИЯ ПРОГРАММНЫМ ПРОЕКТОМ (SOFTWARE PROJECT
MANAGEMENT PLAN – SPMP)
Утверждаю
Дата
05.01.09 А. Мелихов: Создание первой версии
02.02.09 А. Мелихов: Рецензирование и различные предложения по улучшению
16.05.09 А. Мелихов: Детализация плана-графика
29.05.09 А. Мелихов: Проверка для выпуска
1. Введение
1.1. Обзор проекта
Данный проект организован для разработки информационно-справочной системы (ИСС).
Система будет разработана в несколько этапов, поскольку заказчиком специфицирование проекта
будет выполняться последовательно с учетом результатов предыдущего этапа. Первые версии созда-
ются в целях обучения, чтобы разработчики могли попрактиковаться в технологии разработки, и в
качестве базы, на которой студенты могут создавать свои собственные проекты. Последующие вер-
сии, как ожидается, будут либо свободно распространяемыми, либо коммерческими продуктами.
1.2. Результирующие артефакты проекта
Следующие материалы должны быть поставлены в указанные сроки.
Версия 1 (прототип) с документацией — вторая неделя второго месяца.
Версия 2 с документацией — третья неделя пятого месяца.
Документация включает в себя SPMP, SQAP, SCMP, SRS, SDD (с использованием стандартов IEEE).
Аббревиатуры определены в разделе 1.5.
1.3. Развитие SPMP
[В этом разделе объясняется, как будет поддерживаться и развиваться данный документ.]
Данный документ поддерживается лидером проекта. Лидер проекта должен поместить дан-
ный документ под управление конфигурациями и обязан поддерживать документ в актуальном со-
стоянии, еженедельно внося необходимые изменения.
1.4. Ссылочные материалы
Все необходимые стандарты IEEE опубликованы в сборнике стандартов IEEE: Schmidt M. Im-
plementing the IEEE Software Engineering Standards / M. Schmidt. – Indianapolis : SAMS, 2000. – 255 p.
1.5. Аббревиатуры
CI (Configuration Item) – элемент конфигурации.
СММ (Capability Maturity Model) – модель зрелости возможностей.
IEEE (Institute of Electrical and Electronics Engineers) – институт инженеров по электротехнике и ра-
диоэлектронике.
QA (Quality Assurance) – контроль качества.
SEI (Software Engineering Institute) – институт технологий разработки программного обеспечения.
SCMP (Software Configuration Management Plan) – план управления конфигурациями программного
обеспечения.
SPMP (Software Project Management Plan) – план управления программным проектом (данный доку-
мент).
SRS (Software Requirements Specification) – спецификация требований к программному обеспечению.
SDD (Software Design Document) – проектная документация программного обеспечения.
STP (Software Test Plan) – план тестирования программного обеспечения.
USDP (Unified Software Development Process) – унифицированный процесс разработки программного
обеспечения.
2. Организация проекта
2.1. Модель процесса
Первые две версии проекта будут выполнены с использованием спирального процесса разра-
ботки, по одной итерации на версию. Итерации проводятся в соответствии с USDP. Согласно USDP,
итерации классифицируются на начальные итерации, итерации проектирования, конструирования и