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

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

194 Глава 5

а) непосредственно связан с процессом управления качеством;

б) может интегрироваться с поддерживающими процессами V&V, Совмест-

ного просмотра, Аудита и (частично) Управления решением проблем либо инкор-

порировать действия этих процессов;

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

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

Место процесса SQA в архитектуре процессов ЖЦ показано на рисунке 5.1.

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

Стрелками на линиях обозначено направление информационной связи процесса

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

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

Рис. 5.1. Место SQA в архитектуре процессов ЖЦ

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

Существует две категории объектов обеспечения гарантии качества и связан-

ных с ними задач: рабочие продукты и процессы ЖЦ.

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

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

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

нимы;

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

виями договора и отвечают требованиям планов;

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

предъявляемым к ним требованиям и приемлемы для заказчика (потребителя).

Гарантируя качество процессов нужно убедиться в том, что:

Глава 5 195

• все процессы ЖЦ ПС, используемые в рамках проекта, согласуются с до-

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

• применяемые приемы программной инженерии, среда разработки, среда

тестирования и среда применения ПС согласуются с договором;

• требования договора с головным исполнителем доводятся до соисполни-

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

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

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

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

ми;

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

цесса измерения) соответствуют утвержденным стандартам и процедурам;

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

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

мощь в обучении.

Перечень решаемых задач может детализироваться и уточняться в зависимо-

сти от исходных требований к ПС, поставленных целей качества и условий среды

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

и контроля качества влияют, в частности, следующие факторы:

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

ное обеспечение);

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

ПС (например, отраслевым стандартам);

• наличие стандартов по качеству и соответствующего исторического опы-

та;

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

интегрированных сред) разработки и сопровождения ПС, а также оценивания и по-

вышения качества;

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

выми, временными, техническими);

• категории пользователей ПС и обеспечение необходимого уровня их под-

готовки к использованию системы;

• сфера применения ПС (уровень необходимой целостности и безопасности

системы).

Ответственность за формирование перечня задач гарантирования качества

ПС и их решение возлагается на независимую группу качества (группу SQA), кото-

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

ства (планом качества). Непредвзятость в работе группы качества (на уровне орга-

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

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

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

Группа качества, работающая в рамках проекта, принимает участие в форми-

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

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

ям и общей политике организации. Участие группы SQA в этих работах способст-

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

196 Глава 5

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

при проведении обзоров и аудиторских проверок в ходе ЖЦ.

Нужно отметить, что в зависимости от выбранной модели процессов ЖЦ для

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

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

только собственно процесса SQA, но и других процессов ЖЦ, в том числе процес-

сов Измерения, V&V, Аудита и Управления решением проблем. В этом случае она

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

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

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

инженер по качеству, инженер по надежности, инженер по безопасности, предста-

вители группы измерения и группы тестирования. При функционировании на уров-

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

процессам ЖЦ организации и контактирует с группой инженерии процесса разра-

ботки с целью усовершенствования процессов. Кроме того, организация-

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

валидации (IV&V, от Independent V&V), аудита и сертификации систем качества.

Для успешного функционирования группы качества важно обеспечить над-

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

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

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

рованным процедурам.

Руководство NASA GB A201 выделяет, например, следующие категории

стандартов, обеспечивающих нормативную информационную поддержку SQA [5]:

• стандарты документирования. Определяют форму и содержание доку-

ментации по планированию и контролю (управлению) процессов, а также докумен-

тации на продукт, и обеспечивают непротиворечивость документов в проекте;

• стандарты проектирования. Определяют форму и содержание проекта.

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

программного обеспечения и для его представления в документации проекта;

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

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

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

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

рования.

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

• стандарты спецификации требований;

• стандарты сопровождения;

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

• стандарты измерения (объема, сложности и других атрибутов ПС);

• стандарты оценивания качества;

• стандарты оценивания процессов;

• стандарты планирования отдельных процессов (в частности, планирова-

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

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

приложении 3.

Глава 5 197

Все процессы, выполняемые в ЖЦ проекта, должны иметь документирован-

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

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

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

описаны в разделе 5.4, а также в главах 6, 7 и 10.

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

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

(SPMP, от Software Project Management Plan), который, в частности, содержит раз-

дел, касающийся процессов контроля разработки ПС.

Результатом осуществления SQA являются отчеты руководству, включающие

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

соответствие со стандартами и/или процедурами.

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

Осуществление процесса SQA регламентируется разработанным и докумен-

тально оформленным, реализуемым и сопровождаемым (а при необходимости и

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

рантирования качества для ЖЦ проекта (сокращенно, Планом качества или SQAP

(от Software Quality Assurance Plan)). План описывает, каким образом организация-

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

дующее:

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

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

ции организации);

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

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

размещения отчетов о качестве;

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

гарантированию качества;

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

вающих процессов, таких как Верификация, Валидация, Совместный просмотр,

Аудит и Управление решением проблем. Хотя многие аспекты качества ПС описы-

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

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

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

не согласованными, а некоторые аспекты качества ПС упущенными.

Масштаб, сфера применения и содержание SQAP должны соответствовать

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

связи с отказами системы.

План может существовать в виде отдельного документа или быть частью

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

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

управления риском, V&V и др. (рисунок 5.2).

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

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

руководства проекта.

198 Глава 5

План управления

проектом

Планы выполнения

основных процес-

сов (разработка и

сопровождение ПС)

План

качества

План

управления

риском

План

V&V

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

План измерений

План управления

разработкой

План-график

разработки

(по модели

ЖЦ)

План

кадрового

обеспечения

План

финансового

технического

обеспечения

План

обучения

Планы

тестирования

Рис. 5.2. Иерархия планов при разработке ПС

Структура и содержание SQAP регламентируется IEEE Std. 730 (рисунок 5.3).

План обеспечения гарантии качества ПС

1. Введение

1.1. Назначение

1.2. Сфера применения

1.3. Определения и сокращения

1.4. Ссылки

2. Управление

2.1. Организация

2.2. Задачи

2.3. Ответственности

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

4. Стандарты, процедуры, соглашения и метрики

5. Обзоры и аудиторские проверки

6. Испытания (тестирование)

7. Сообщения о проблемах и корректирующие действия

8. Инструменты, технологии и методологии

9. Контроль кода

10. Контроль носителя

11. Контроль поставщика

12. Сбор, ведение и хранение отчетов (записей)

13. Обучение

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

Рис. 5.3. Структура Плана качества ПС

Глава 5 199

План может быть дополнен другими разделами, обеспечивающими охват

требований конкретного проекта ПС. Если проект предполагает разработку не-

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

отражающих специфику каждого из них.

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

[6] и вкратце приводятся ниже применительно к отдельным пунктам плана.

Организация SQA. Описывается структура SQA, основные организационные

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

группы SQA от организации-разработчика (группы разработки).

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

решаться при проведении SQA:

- определяются границы фрагмента ЖЦ ПС, охватываемого SQA;

- перечисляются задачи, выполняемые в рамках SQA. Эти задачи подробно

описываются в разделе «Обучение» SQAP;

- устанавливаются взаимосвязи между задачами SQA и действиями по V&V в

контрольных точках обзоров проекта.

Ответственности SQA. Идентифицируются организационные элементы, от-

вечающие за решение каждой задачи SQA. Указываются лица, отвечающие за план

SQA, а также лицо, в целом несущее ответственность за качество ПС.

Документация. Составляется перечень документов, находящихся под кон-

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

не управления проектом ПС. Определяется, каким образом группа SQA будет про-

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

документов должен включать: спецификацию требований к ПС; описание проекта

ПС; план верификации и валидации ПС; отчет о верификации и валидации ПС; до-

кументацию пользователя; план управления конфигурацией ПС и др.

Стандарты, процедуры, соглашения и метрики. Описываются все стандар-

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

разработки, и определяются этапы ЖЦ ПС, к которым они будут применены. Ука-

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

дартом, процедурой, соглашением и метрикой.

Список стандартов, процедур, соглашений и метрик, подлежащих примене-

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

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

Обзоры и аудиторские проверки. Описываются все виды проверок, проводи-

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

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

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

кой (управленческого обзора), аудиторской проверки работ по проекту. Согласно

IEEE Std. 730-1 в минимальном объеме перечень проверок должен включать:

- обзор требований к ПС;

- обзор предварительного проекта

;

Стадии «предварительное проектирование» соответствует в отечественных стан-

дартах стадия «эскизное проектирование», а стадии «детальное проектирование» - стадия

«техническое проектирование» и, частично, «рабочее проектирование».

200 Глава 5

- обзор детального проекта (критический обзор);

- обзор плана верификации и валидации;

- функциональную аудиторскую проверку;

- физическую аудиторскую проверку;

- внутренние аудиторские проверки;

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

- обзоры плана управления конфигурацией.

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

проекта и группой SQA.

Испытания. Описываются любые необходимые испытания (тестирование)

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

проведения.

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

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

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

сти:

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

их решением;

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

мы, непосредственно касающиеся качества ПС, решены.

Инструменты, технологии и методологии. Оговариваются все специальные

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

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

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

ставлен в разделе 5.4.

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

лироваться в ходе разработки проекта.

Контроль среды. Описываются методы и средства, используемые для иден-

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

хранение, копирование и восстановление.

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

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

отвечать установленным требованиям проекта. В частности:

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

ставщики получили адекватные и полные требования;

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

сти для проекта ранее разработанного программного обеспечения;

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

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

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

идентификации, оценки, мониторинга и контроля областей риска, особенно касаю-

щихся аспектов качества ПС (надежности, безопасности функционирования и др.).

Полнота и правильность плана SQA должны проверяться и подтверждаться

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

Глава 5 201

5.1.4. Деятельность группы качества по мониторингу процессов

Одна из наиболее важных функций SQA в процессо-ориентированной про-

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

процесса программной инженерии, включающего множество процессов ЖЦ, адап-

тированных к нуждам проекта.

Ниже кратко описаны функции SQA применительно к поддерживающим

процессам ЖЦ – процессу управления конфигурацией, V&V и тестирования в ин-

терпретации руководства NASA GB A201 по обеспечению гарантии процессов [5].

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

программного обеспечения (SCM, от Software Configuration Management) выполня-

ется в соответствии с планами SCM, стандартами и процедурами. SQA проверяет

планы SCM на соответствие принципам (политике) и требованиям к SСМ и обеспе-

чивает отслеживание несоответствий. SQA проводит аудит функций SCM для оп-

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

тах проверки.

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

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

учет состояния конфигурации и установление подлинности (аутентификация) кон-

фигурации. SQA также производит контроль и аудит библиотеки программного

обеспечения.

SQA гарантирует что:

• базовые версии образованы и последовательно поддерживаются с целью

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

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

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

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

документам;

• обеспечивается совместимость конфигурации программного обеспечения,

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

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

• тщательно выполняется учет состояния конфигурации, включая регист-

рацию и сообщение о данных, отражающих подробности идентификации конфигу-

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

лизации утвержденных изменений;

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

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

фикациям требований и документам проекта;

• библиотеки поддержки разработки обеспечивают надлежащее ведение

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

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

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

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

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

Применительно к процессам Верификации и Валидации SQA обеспечивает

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

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

202 Глава 5

рассматриваются в главах 6 и 7). Роль SQA в обзорах, инспекциях, сквозном про-

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

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

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

ются.

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

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

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

обзоров - Обзор Предварительного проекта (архитектуры) (PDR, Preliminary Design

Review), Обзор Детального проекта (CDR, Critical Design Review) и Обзор готовно-

сти тестов (TRR, Test Readiness Review). По результатам обзора принимается реше-

ние о готовности (не готовности) к переходу на следующую стадию ЖЦ. Хотя ре-

шение о переходе - это решение руководства, группа SQA гарантирует соблюдение

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

следующую стадию. Она несет ответственность за достоверность информации, по-

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

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

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

ния выполнены.

В ходе формального тестирования (испытаний) ПС SQA гарантирует его

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

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

тестов, процедур и сценариев тестирования, отчетов по тестированию) на полноту

и соответствие стандартам. SQA выполняет мониторинг тестирования и обеспечи-

вает отслеживание несоответствий. Путем мониторинга тестирования SQA гаран-

тирует завершенность ПС и ее готовность к поставке.

Цели SQA при мониторинге формального тестирования ПС состоят в том,

чтобы обеспечить гарантии, что:

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

• процедуры тестирования поддаются проверке;

• тестируется правильная или «рекламируемая» версия ПС (путем монито-

ринга деятельности по SCM);

• процедуры тестирования строго соблюдаются;

• несоответствия, встречающиеся в ходе тестирования (то есть любые ин-

циденты, не ожидаемые в процедурах тестирования), регистрируются;

• отчеты о тестировании точны и полны;

• регрессионное тестирование проводится с целью обеспечения гарантии,

что несоответствия исправлены;

• решение по всем несоответствиям принимается до поставки ПС.

5.1.5. Деятельность группы качества на стадиях жизненного цикла

В дополнение к общим действиям, описанным в п. 5.1.2 и 5.1.4, существуют

специфические для отдельных стадий ЖЦ действия по SQA, которые должны вы-

полняться в ходе разработки ПС по завершении соответствующих стадий.

На стадии принятия концепции ПС группа SQA должна вовлекаться как в на-

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

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

Глава 5 203

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

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

управления проектом ПС.

На стадии определения требований к ПС группа SQA гарантирует, что требо-

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

нальных и нефункциональных (технических) требований к ПС и интерфейсных

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

Действия по SQA в ходе предварительного проектирования включают:

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

ПС, обозначенных в плане управления проектом ПС;

• обеспечение гарантии, что все требования к ПС распределены по компо-

нентам программного обеспечения;

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

содержатся в актуальном состоянии;

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

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

нию;

• обзоры PDR-документации и обеспечение гарантии, что все работы этапа

завершены;

• обеспечение гарантии, что утвержденный проект помещен в сферу управ-

ления конфигурацией.

Действия SQA в ходе детального проектирования включают:

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

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

• обеспечение гарантии, что выделенные в ходе предварительного проек-

тирования модули включены в детальный проект;

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

екта учтены в детальном проекте;

• обзоры документации CDR и обеспечение гарантии, что все работы этапа

завершены.

Действия SQA на стадии реализации включают аудиторские проверки:

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

блюдение графика, содержащегося в плане разработки ПС;

• состояния всех поставляемых компонентов ПС;

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

работки;

• системы отчетности о несоответствиях и корректирующих действиях.

Действия SQA в ходе интеграции и тестирования включают:

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

компонентов ПС;

• обеспечение гарантии, что все тесты выполняются согласно планам и

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

ется адекватное решение;

• обеспечение гарантии, что отчеты о тестировании сформированы в пол-

ном объеме и содержат достоверную информацию;

• подтверждение, что тестирование проведено полностью и программное