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

Существует две категории объектов обеспечения гарантии качества и связанных с ними задач: рабочие продукты и процессы жизненного цикла. Гарантируя качество рабочих продуктов нужно убедиться в том, что, все планы, требуемые по условиям договора, надлежащим образом документируются, согласовываются с договором, взаимно непротиворечивы и выполнимы. Рабочие продукты и связанная с ними документация согласуются с условиями договора и отвечают требованиям планов. Предназначенные для поставки продукты полностью удовлетворяют предъявляемым к ним требованиям и приемлемы для заказчика (потребителя).

Гарантируя качество процессов нужно убедиться в том, что: все процессы жизненного цикла программных средств, используемые в рамках проекта, согласуются с договором и следуют планам, применяемые приемы программной инженерии, среда разработки, среда тестирования и среда применения программных средств согласуются с договором. Требования договора с головным исполнителем доводятся до соисполнителей (при их наличии) и что создаваемые соисполнителями рабочие продукты удовлетворяют требованиям договора с головным исполнителем. Заказчик и другие заинтересованные стороны обеспечиваются необходимой поддержкой в соответствии с договором, устными договоренностями и планами. Метрики продуктов и процесса и приемы измерения (при наличии процесса измерения) соответствуют утвержденным стандартам и процедурам. Назначенный штат исполнителей проекта имеет опыт и знания, необходимые для достижения требований проекта, и получает любую необходимую помощь в обучении.

Перечень решаемых задач может детализироваться и уточняться в зависимости от исходных требований к программных средств, поставленных целей качества и условий среды разработки и применения программных средств. На широту спектра задач планирования, управления и контроля качества влияют, в частности, следующие факторы - состав компонентов программных средств (разрабатываемое или приобретаемое программное обеспечение). Необходимость следования специализированным стандартам разработки программных средств (например, отраслевым стандартам):

1. Наличие стандартов по качеству и соответствующего исторического опыта.

2. Наличие методов и специальных автоматизированных инструментов (или интегрированных сред) разработки и сопровождения программных средств, а также оценивания и повышения качества.

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

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

5. Сфера применения программных средств (уровень необходимой целостности и безопасности системы).

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

Группа качества , работающая в рамках проекта, принимает участие в формировании планов, подборе стандартов, методологий, методов и инструментов, которые должны использоваться в проекте программных средств и удовлетворять проектным ограничениям и общей политике организации. Участие группы SQA в этих работах способствует получению гарантий, что разработанные планы, а также стандарты и процедуры (или базовые определения процессов) отвечают нуждам проекта и применяются при проведении обзоров и аудиторских проверок в ходе жизненного цикла.

Нужно отметить, что в зависимости от выбранной модели процессов жизненного цикла для конкретного проекта (включающей определенное подмножество процессов, действий и задач), на группу качества могут возлагаться обязанности по выполнению не только собственно процесса SQA, но и других процессов жизненного цикла, в том числе процессов Измерения, V&V, Аудита и Управления решением проблем. В этом случае она совмещает сбор информации о процессе и продуктах с ее расширенным анализом, установлением причинно-следственных связей в проекте и выработкой рекомендаций для руководства проектом. В группу качества могут, например, включаться инженер по качеству, инженер по надежности, инженер по безопасности, представители группы измерения и группы тестирования. При функционировании на уровне организации группа качества осуществляет также обратную связь к базовым процессам жизненного цикла организации и контактирует с группой инженерии процесса разработки с целью усовершенствования процессов. Кроме того, организация-разработчик может пользоваться услугами органов независимой верификации и валидации (IV&V, от Independent V&V), аудита и сертификации систем качества.

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

Руководство NASA GB A201 выделяет, например, следующие категории стандартов, обеспечивающих нормативную информационную поддержку SQA:

1. Стандарты документирования. Определяют форму и содержание документации по планированию и контролю (управлению) процессов, а также документации на продукт, и обеспечивают непротиворечивость документов в проекте;

2. Стандарты проектирования. Определяют форму и содержание проекта. Обеспечивают правила и методы для преобразования требований к программным системам в проект программного обеспечения и для его представления в документации проекта;

3. Стандарты кодирования и интерфейсов. Определяют язык, на котором должен быть написан код, и любые ограничения на использование особенностей языка. Указывают принятые структуры языка, соглашения о стиле, правила представления структур данных и интерфейсов в определенной парадигме программирования.

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

• стандарты спецификации требований;
• стандарты сопровождения;
• стандарты управления конфигурацией;
• стандарты измерения (объема, сложности и других атрибутов ПС);
• стандарты оценивания качества;
• стандарты оценивания процессов;
• стандарты планирования отдельных процессов (в частности, планирования управления проектом, качеством, риском, конфигурацией, безопасностью).

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

Перечень стандартов, применяемых процедур и методов должен определяться при планировании создания программных средств и фиксироваться в плане управления проектом (SPMP, от Software Project Management Plan) , который, в частности, содержит раздел, касающийся процессов контроля разработки программных средств.

Результатом осуществления SQA являются отчеты руководству, включающие описание обнаруженных недостатков и рекомендаций по приведению разработки в соответствие со стандартами и/или процедурами.

План качества

Осуществление процесса SQA регламентируется разработанным и документально оформленным, реализуемым и сопровождаемым (а при необходимости и актуализируемым) Планом выполнения действий и решения задач по процессу гарантирования качества для жизненного цикла проекта (сокращенно, Планом качества или SQAP (от Software Quality Assurance Plan) ). План описывает, каким образом организация - разработчик гарантирует обеспечение качества программных средств. План должен включать следующее:

1. Стандарты, методологии, процедуры и инструменты для выполнения действий по гарантированию качества (или ссылки на них в официальной документации организации);

2. Процедуры для проверки (обзора) договора и условия их координации;

3. Процедуры для идентификации, сбора, накопления, сопровождения и размещения отчетов о качестве;

4. Ресурсы, план-график работ и ответственности за проведение действий по гарантированию качества;

5. Описание отдельных (избранных) действий и задач из других поддерживающих процессов, таких как Верификация, Валидация, Совместный просмотр, Аудит и Управление решением проблем. Хотя многие аспекты качества программных средств описываются в различных планах, например, в Плане управления конфигурацией, Плане верификации и валидации, Плане обеспечения безопасности функционирования программных средств и др., без единого Плана качества эти отдельные планы могут оказаться взаимно не согласованными, а некоторые аспекты качества программных средств упущенными.

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

План может существовать в виде отдельного документа или быть частью плана обеспечения гарантии качества крупной системы, включающей программные средства в качестве подсистемы. Он может ссылаться на другие планы в проекте, например, план управления риском, V&V и др. (рисунок 13.2).

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

рис.15

Рис. 13.2. Иерархия планов при разработке программных средств

Структура и содержание SQAP регламентируется IEEE Std. 730 и содержит следующие пункты:

• план обеспечения гарантии качества ПС;
• введение;
• назначение;
• сфера применения;
• определения и сокращения;
• ссылки;
• управление;
• организация;
• задачи;
• ответственности;
• документация;
• стандарты, процедуры, соглашения и метрики;
• обзоры и аудиторские проверки;
• испытания (тестирование);
• сообщения о проблемах и корректирующие действия;
• инструменты, технологии и методологии;
• контроль кода;
• контроль носителя;
• контроль поставщика;
• сбор, ведение и хранение отчетов (записей);
• обучение;
• управление риском.

План может быть дополнен другими разделами, обеспечивающими охват требований конкретного проекта программных средств. Если проект предполагает разработку нескольких программных продуктов - может быть создано несколько планов SQAP, отражающих специфику каждого из них.

Разъяснения по составлению SQAP содержатся в руководстве IEEE Std. 730-1 и вкратце приводятся ниже применительно к отдельным пунктам плана.

Организация SQA . Описывается структура SQA, основные организационные элементы SQA и связи между ними, характер организационной независимости группы SQA от организации-разработчика (группы разработки).

Задачи управления SQA. Описываются основные задачи, которые должны решаться при проведении SQA:

• определяются границы фрагмента жизненного цикла программных средств, охватываемого SQA;
• перечисляются задачи, выполняемые в рамках SQA. Эти задачи подробно описываются в разделе "Обучение" SQAP;
• устанавливаются взаимосвязи между задачами SQA и действиями по V&V в контрольных точках обзоров проекта.

Ответственности SQA. Идентифицируются организационные элементы, отвечающие за решение каждой задачи SQA. Указываются лица, отвечающие за план SQA, а также лицо, в целом несущее ответственность за качество программных средств.

Документация . Составляется перечень документов, находящихся под контролем SQA. Он должен в основном совпадать со списком, представленным в плане управления проектом программных средств. Определяется, каким образом группа SQA будет проверять адекватность каждого документа. Как минимум, перечень контролируемых документов должен включать:

• Спецификацию требований к программным средствам;
• Описание проекта программного средства; план верификации и валидации программного средства;
• Отчет о верификации и валидации программного средства; документацию пользователя; план управления конфигурацией программного средства и др.

Стандарты , процедуры, соглашения и метрики. Описываются все стандарты, процедуры, соглашения и метрики, которые будут использоваться в процессе разработки, и определяются этапы жизненного цикла программных средств, к которым они будут применены. Указывается, каким образом будет гарантироваться согласованность с каждым стандартом, процедурой, соглашением и метрикой.

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

Обзоры и аудиторские проверки . Описываются все виды проверок, проводимых в контрольных точках процесса разработки с целью обеспечения гарантии качества. Устанавливаются порядок и методы проведения каждого обзора технических аспектов разработки (технического обзора) и аспектов управления разработкой (управленческого обзора), аудиторской проверки работ по проекту. Согласно IEEE Std. 730-1 в минимальном объеме перечень проверок должен включать:

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

Фактическое множество проверок определяется совместно руководством проекта и группой SQA.

Испытания . Описываются любые необходимые испытания (тестирование) ПС, не включенные в план верификации и валидации. Устанавливается порядок их проведения.

Сообщения о проблемах и корректирующие действия. Описывается, каким образом проблемы, выявленные в ходе разработки и непосредственно касающиеся качества продукта, будут регистрироваться, отслеживаться и решаться. В частности:

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

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

Контроль кода. Описывается, как исходный и объектный код будут контролироваться в ходе разработки проекта.

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

Контроль поставщика. Описываются средства, используемые для обеспечения гарантии, что программное обеспечение, предоставляемое поставщиком, будет отвечать установленным требованиям проекта. В частности:

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

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

Полнота и правильность плана SQA должны проверяться и подтверждаться руководством проекта (или организации).

Поиск по сайту: