МЕЖГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ КОМИТЕТ
АВИАЦИОННЫЙ РЕГИСТР
РУКОВОДСТВО
Р-330
по квалификации
программных инструментов
Введено в действие с 22.11.16
Директивным письмом № 03-2016
Авиарегистра МАК от 22 ноября 2016 г.
2016
Руководство Р-330
3
ПРЕДИСЛОВИЕ
Основой настоящего Руководства Р-330 по квалификации программных инструментов
является документ RTCA/D0-330 «Software Tool Qualification Considerations». Документ
KT-178C и дополнения к нему, включая настоящее дополнение, развивают требования и
методические подходы, приведенные в ранее выпущенном документе КТ-178В. Термины и
определения, использованные в КТ-178В, по возможности, сохранены. Заключение
о соответствии ПО требованиям КТ-178С (включая применимые дополнения) является
обязательным при квалификации комплектующих изделий.
Руководство Р-330
4
С О Д ЕР Ж АН И Е
1.0 ВВЕДЕНИЕ....................................................................................................................................... 9
1.1 Назначение документа........................................................................................................... 9
1.2 Область применения документа........................................................................................... 9
1.3 Рекомендации относительно работы с документом..........................................................9
1.4 Структура документа............................................................................................................. 10
2.0 НАЗНАЧЕНИЕ КВАЛИФИКАЦИИ ИНСТРУМЕНТА...............................................................12
3.0 ХАРАКТЕРИСТИКИ КВАЛИФИКАЦИИ ИНСТРУМЕНТА..................................................... 13
3.1 Уровни квалификации........................................................................................................... 13
3.2 Заинтересованные в квалификации стороны................................................................... 13
4.0 ПРОЦЕСС ПЛАНИРОВАНИЯ КВАЛИФИКАЦИИ ИНСТРУМЕНТА.................................... 14
4.1 Определение необходимости квалификации инструмента...........................................14
4.2 Определение жизненного цикла инструмента.................................................................14
4.3 Цели процесса планирования инструмента..................................................................... 15
4.4 Мероприятия процесса планирования инструмента...................................................... 15
5.0 ЖИЗНЕННЫЙ ЦИКЛ И ПРОЦЕССЫ РАЗРАБОТКИ ИНСТРУМЕНТА...............................17
5.1 Процесс определения Эксплуатационных требований к инструменту....................... 18
5.1.1 Цели определения Эксплуатационных требований к инструменту.................. 18
5.1.2 Мероприятия по определению Эксплуатационных требований
к инструменту...............................................................................................................18
5.2 Процессы разработки инструмента.................................................................................... 19
5.2.1 Процесс разработки требований к инструменту................................................... 19
5.2.2 Процесс проектирования инструмента................................................................... 20
5.2.3 Процесс кодирования инструмента......................................................................... 21
5.2.4 Процесс интеграции инструмента............................................................................21
5.2.5 Трассируемость процесса разработки инструмента............................................22
5.3 Процесс эксплуатационной интеграции инструмента.................................................... 23
5.3.1 Цели процесса эксплуатационной интеграции инструмента..............................23
5.3.2 Мероприятия процесса эксплуатационной интеграции инструмента............... 23
6.0 ПРОЦЕСС ВЕРИФИКАЦИИ ИНСТРУМЕНТА..........................................................................24
6.1 Процесс верификации инструмента................................................................................... 24
6.1.1 Назначение процесса верификации инструмента................................................ 24
6.1.2 Обзор мероприятий верификации инструмента................................................... 24
6.1.3 Рассмотрения и анализы...........................................................................................25
6.1.4 Тестирование инструмента....................................................................................... 28
6.1.5 Трассируемость процесса верификации инструмента........................................ 31
6.2 Процесс эксплуатационной верификации и валидации инструмента..........................31
6.2.1 Цели процесса эксплуатационной верификации и валидации инструмента... 31
6.2.2 Мероприятия процесса эксплуатационной верификации
и валидации инструмента......................................................................................... 32
7.0 ПРОЦЕСС УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ ИНСТРУМЕНТА........................................ 33
7.1 Цели процесса управления конфигурацией инструмента..............................................33
7.2 Мероприятия процесса управления конфигурацией инструмента............................... 34
7.2.1 Идентификация конфигурации................................................................................. 34
7.2.2 Базовые версии и трассируемость...........................................................................34
Руководство Р-330
5
7.2.3 Регистрация проблем, отслеживание и корректирующие действия.................. 35
7.2.4 Управление изменениями.......................................................................................... 35
7.2.5 Рассмотрение изменений.......................................................................................... 36
7.2.6 Учет состояния конфигурации...................................................................................36
7.2.7 Хранение, воспроизведение и выпуск.....................................................................36
7.3 Категории контроля данных..................................................................................................37
7.4 Управление средой жизненного цикла инструмента....................................................... 37
8.0 ПРОЦЕСС ГАРАНТИИ КАЧЕСТВА ИНСТРУМЕНТА............................................................. 39
8.1 Цели процесса гарантии качества инструмента.............................................................. 39
8.2 Мероприятия процесса гарантии качества инструмента................................................39
8.3 Рассмотрение соответствия инструмента......................................................................... 40
9.0
ПРОЦЕСС ВЗАИМОДЕЙСТВИЯ С СЕРТИФИЦИРУЮЩИМ ОРГАНОМ
ДЛЯ КВАЛИФИКАЦИИ ИНСТРУМЕНТА................................................................................. 42
10.0 ДАННЫЕ КВАЛИФИКАЦИИ ИНСТРУМЕНТА........................................................................ 43
10.1 Данные процесса взаимодействия с Сертифицирующим органом
для квалификации инструмента и других интегральных процессов.......................... 43
10.1.1
Информация относительно инструмента в Плане сертификации ПО........ 43
10.1.2 План квалификации инструмента......................................................................44
10.1.3 План разработки инструмента............................................................................ 44
10.1.4 План верификации инструмента........................................................................ 45
10.1.5 План управления конфигурацией инструмента...............................................45
10.1.6 План гарантии качества инструмента............................................................... 46
10.1.7 Стандарты на разработку требований к инструментам.................................47
10.1.8 Стандарты на проектирование инструмента...................................................47
10.1.9 Стандарты на кодирование инструмента......................................................... 48
10.1.10 Указатель конфигурации среды жизненного цикла инструмента................48
10.1.11 Указатель конфигурации инструмента............................................................. 48
10.1.12 Сообщения о проблемах инструмента.............................................................. 49
10.1.13 Записи управления конфигурацией инструмента........................................... 49
10.1.14 Записи гарантии качества инструмента........................................................... 50
10.1.15 Итоговое заключение об инструменте.............................................................. 50
10.1.16 Информация относительно инструмента в Итоговом заключении о ПО ....51
10.1.17 Информация относительно инструмента в Указателе конфигурации
среды жизненного цикла ПО................................................................................51
10.2 Данные квалификации инструмента, производимые в процессах разработки
инструмента и соответствующих мероприятиях верификации................................... 52
10.2.1 Требования к инструментам............................................................................... 52
10.2.2 Описание проекта инструмента......................................................................... 52
10.2.3 Исходный код инструмента..................................................................................52
10.2.4 Исполняемый объектный код инструмента...................................................... 53
10.2.5 Примеры и Процедуры верификации инструмента........................................ 53
10.2.6 Результаты верификации инструмента............................................................ 53
10.2.7 Данные трассировки............................................................................................. 54
10.3 Данные квалификации инструмента, получаемые в процессе определения
Эксплуатационных требований к инструменту, в процессе эксплуатационной
интеграции инструмента, а также в ходе соответствующих мероприятий
верификации и валидации..................................................................................................54
10.3.1 Эксплуатационные требования к инструменту..................................................54
6
Руководство Р-330
10.3.2 Протокол об установке инструмента................................................................... 55
10.3.3 Примеры и Процедуры эксплуатационной верификации и валидации
инструмента............................................................................................................. 55
10.3.4 Результаты эксплуатационной верификации и валидации инструмента.... 55
11.0 ДОПОЛНИТЕЛЬНЫЕ СООБРАЖЕНИЯ ПО КВАЛИФИКАЦИИ ИНСТРУМЕНТА............56
11.1 Многофункциональные инструменты.............................................................................56
11.2 Ранее квалифицированные инструменты.................................................................... 57
11.2.1 Повторное использование ранее квалифицированных инструментов.........58
11.2.2 Изменения эксплуатационной среды инструмента......................................... 58
11.2.3 Изменения ранее квалифицированного инструмента..................................... 59
11.3 Квалификация покупного готового инструмента......................................................... 59
11.3.1 Подход к квалификации покупного готового инструмента..............................59
11.3.2 Мероприятия для разработчика инструмента................................................... 60
11.3.3 Мероприятия квалификации инструмента для пользователя
инструмента............................................................................................................. 62
11.3.4 Координация мероприятий разработчика и пользователя инструмента..... 65
11.4 История эксплуатации...................................................................................................... 65
11.4.1 Аспекты истории эксплуатации инструмента.................................................... 66
11.4.2 Мероприятия истории эксплуатации инструмента...........................................66
11.5 Альтернативные методы квалификации инструментов.............................................67
ПРИЛОЖЕНИЕ А. ЦЕЛИ КВАЛИФИКАЦИИ ИНСТРУМЕНТА.................................................... 68
ПРИЛОЖЕНИЕ В. СОКРАЩЕНИЯ И ТОЛКОВЫЙ СЛОВАРЬ ТЕРМИНОВ............................80
Справочные материалы А. ПЕРЕЧЕНЬ УЧАСТНИКОВ...........................................................88
Справочные материалы В. ПРИМЕР ОПРЕДЕЛЕНИЯ ПРИМЕНИМЫХ УРОВНЕЙ
КВАЛИФИКАЦИИ ИНСТРУМЕНТА.............................................89
Справочные материалы С. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ, СВЯЗАННЫЕ
С КВАЛИФИКАЦИЕЙ ИНСТРУМЕНТОВ ДЛЯ ВСЕХ
ОБЛАСТЕЙ...................................................................................... 91
1.0 Введение к Справочным материалам С...............................................................................91
1.1 Вопрос С.1: Что обозначает «защита» для инструмента и какие меры помогают
ее достичь?..............................................................................................................................91
1.2 Вопрос С.2: Что такое внешние компоненты и как можно оценить
их правильность?................................................................................................................... 92
1.2.1 Что представляют собой внешние компоненты инструмента?..........................92
1.2.2 Применение анализа структурного покрытия к внешним
компонентам инструмента........................................................................................ 92
1.3 Вопрос С.З: Как можно максимизировать возможность повторного
использования данных квалификации инструментов?................................................... 93
Справочные материалы D. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ, СВЯЗАННЫЕ
С КВАЛИФИКАЦИЕЙ ИНСТРУМЕНТОВ ДЛЯ БОРТОВОГО
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ СРЕДСТВ СВЯЗИ, НАВИГАЦИИ,
НАБЛЮДЕНИЯ И УПРАВЛЕНИЯ ВОЗДУШНЫМ
ДВИЖЕНИЕМ (CNS/ATM).............................................................95
1.0 Введение к Справочным материалам D...............................................................................95
7
Руководство Р-330
1.1 Вопрос D.1: Почему для описания инструментов, которые могут быть
квалифицированы, не используются термины «инструмент верификации»
и «инструмент разработки»?.................................................................................................95
1.2 Вопрос D.2: Можно ли понизить уровень квалификации инструментов (TQL)?..........96
1.3 Вопрос D.3: Когда требуется квалифицировать эмуляторы или симуляторы
целевых вычислителей?........................................................................................................ 96
1.3.1 Исходные данные и инструктивные материалы документа
КТ-178С/КТ-278А.......................................................................................................... 96
1.3.2 Использование эмулятора или симулятора........................................................... 97
1.3.3 Демонстрация эквивалентности................................................................................97
1.3.4 Подход к квалификации эмулятора или симулятора............................................98
1.4 Вопрос D.4: Какой зачет может быть выдан инструментам, квалифицированным
ранее с использованием документа KT-178B/DO-278?...................................................98
1.5 Вопрос D.5: Что является обоснованием для определения критериев
квалификации инструмента?............................................................................................... 99
1.5.1 Исходные данны е........................................................................................................99
1.5.2 Подход к определению применимого уровня квалификации инструмента
(TQL)............................................................................................................................. 100
1.5.3 Определение критериев инструментов.................................................................100
1.6 Вопрос D.6: Какие улучшения квалификации «инструментов верификации»
были сделаны в документе КТ-178С/КТ-278А?...............................................................104
1.6.1 Критерии квалификации для инструментов верификации в документе
КТ-178В........................................................................................................................104
1.6.2 Пояснения и улучшения для уровня TQL-5.......................................................... 104
1.6.3 Заключение................................................................................................................ 106
1.7 Вопрос D.7: Как можно использовать квалифицированный инструмент
для верификации выходных данных неквалифицированного инструмента?.......... 106
1.7.1 Область применения и ограничения......................................................................107
1.7.2 Обсуждение................................................................................................................ 108
1.8 Вопрос D.8: Как можно использовать квалифицированный генератор автокода?... 109
1.8.1 Терминология............................................................................................................. 109
1.8.2 Назначение и ограничения данного вопроса....................................................... 110
1.8.3 Обсуждение................................................................................................................ 110
1.9 Вопрос D.9: Требуется ли квалификация симулятора модели?..................................117
П ЕРЕЧЕН Ь РИСУНКОВ
Рисунок 1-1.
Обзор документа......................................................................................................... 11
Рисунок 5-1.
Полный жизненный цикл разработки инструмента..............................................17
Рисунок 11-1. Оценка ранее квалифицированных инструментов...............................................57
Рисунок D-1.
Пример взаимосвязи инструментов......................................................................107
Рисунок D-2.
Процесс разработки с использованием генератора автокода (ACG).............111
Руководство Р-330
8
ПЕРЕЧЕНЬ ТАБЛИЦ
Таблица 7-1.
Мероприятия процесса УК инструмента, назначенные данным категорий
КК1 и КК2...................................................................................................................... 38
Таблица 11-1. Типовые цели для разработчика инструмента.................................................... 61
Таблица 11-2. Типовые цели для пользователя инструмента.................................................... 63
Таблица Т-0.
Процессы эксплуатации инструмента.................................................................... 69
Таблица Т-1.
Процесс планирования инструмента..................................................................... 70
Таблица Т-2.
Процессы разработки инструмента........................................................................ 71
Таблица Т-3.
Верификация выходных данных процессов разработки Требований
к инструменту............................................................................................................. 72
Таблица Т-4. Верификация выходных данных процесса проектирования инструмента...... 73
Таблица Т-5. Верификация выходных данных процессов кодирования и интеграции......... 74
Таблица Т-6. Тестирование выходных данных процесса интеграции...................................... 75
Таблица Т-7. Верификация выходных данных процесса тестирования инструмента...........76
Таблица Т-8. Процесс управления конфигурацией инструмента.............................................. 77
Таблица Т-9. Процесс гарантии качества инструмента...............................................................78
Таблица Т-10. Процесс взаимодействия с Сертифицирующим органом
для квалификации инструмента..............................................................................79
Таблица D-1.
Корреляция уровней квалификации инструментов (TQL) согласно
документу KT-178B/DO-278 и документу KT-178C/DO-278A..............................98
Таблица D-2.
Сравнение между категориями инструментов документа KT-178B/DO-278
и критериями квалификации инструментов документа
КТ-178С/КТ-278А...................................................................................................... 100
Таблица D-3.
Сводка уровней квалификации инструментов (TQL)........................................ 103
Таблица D-4.
Обзор некоторых сценариев использования генератора автокода...............113
Руководство Р-330
9
1.0 ВВЕДЕНИЕ
1.1 Назначение документа
Назначение настоящего документа - предоставить руководство по квалификации
инструмента. Кроме того, предоставлен поясняющий материал в форме Часто задаваемых
вопросов.
1.2 Область применения документа
Программные инструменты широко используются во многих областях, помогая
разрабатывать, верифицировать и управлять другим программным обеспечением (ПО).
В рамках настоящего документа инструмент представляет собой компьютерную программу
или ее функциональную часть, используемую для поддержки в разработке, преобразовании,
тестировании, анализе, создании или модификации другой программы, ее данных или ее
документации. Примерами являются генераторы автокода, компиляторы, инструменты
тестирования и инструменты управления модификацией. Настоящий документ объясняет
процесс и цели квалификации инструментов.
Настоящий документ был разработан по следующим причинам:
a.
Инструменты отличаются от ПО, использующего эти инструменты, и образуют
специфическую область; поэтому требуется специальное руководство по
инструментам, как для разработчиков инструментов, так и для пользователей
инструментов.
b.
Инструменты часто разрабатываются не теми командами, которые используют эти
инструменты для разработки ПО. Часто такие команды разработки инструментов не
имеют необходимых инструктивных материалов для разработки ПО (примерами
инструктивных материалов являются КТ-178С или КТ-278А). Настоящий документ,
посвященный программным инструментам, полезен для команд разработки
инструментов и помогает им избегать путаницы и ошибочного толкования.
c.
В настоящем документе представлено руководство для инструментов, используемых
для бортового и наземного ПО. Он может использоваться также и в других областях,
таких как автомобилестроение, космос, системы разного назначения, электронная
аппаратура, аэронавигационные базы данных, и в процессах оценки безопасности.
1.3 Рекомендации относительно работы с документом
Если для области или проекта решено использовать настоящий документ, необходимо
рассмотреть следующие моменты.
a.
Для обеспечения максимальной применимости и гибкости определены пять уровней
квалификации инструментов (TQLs); однако не все уровни применимы для любой
области. Для каждой области должна быть определена применимость уровней
квалификации инструментов для конкретных потребностей. Чтобы определить,
следует ли, и если да, то до какого уровня необходимо квалифицировать конкретный
инструмент, необходимо обратиться к соответствующему специальному документу по
данной области (такие как документы RTCA, SAE или EUROCAE). В качестве примера
в Справочных материалах В (СМ) показано, как область КТ-278А определяет критерии
квалификации инструментов и применимый уровень квалификации инструментов
(TQL) для наземных средств связи, навигации, наблюдения и организации воздушного
движения (CNS/ATM). Однако каждая область может использовать разные критерии.
Например, они могут не использовать все уровни квалификации инструментов; они
могут иметь отличающиеся критерии инструментов, которые соответствуют
используемым уровням квалификации инструментов; или они могут адаптировать
некоторые цели настоящего документа для своего конкретного применения.
b.
В настоящем документе такие термины, как «жизненный цикл программного обеспече­
ния (ЖЦ ПО)», «процессы ПО», «планы ПО» и «программное обеспечение (ПО)»,
10
Руководство Р-330
используются для указания на ЖЦ, процессы, планы продукта и область, где будет
использоваться инструмент (т.е. область ПО используется в качестве примера
продуктовой области). Для других областей термин «ПО» может заменяться на
соответствующее определение, такое как «электронная аппаратура», «система»,
«аэронавигационная база данных», «авиационное ПО» и т.п.
c.
Термин «сертифицирующий орган» используется как обобщающий термин для
обозначения органа, ответственного за одобрение данных квалификации инструмента.
Аналогичным
образом
термин
«сертификация»
относится
к
одобрению
уполномоченным органом продукта, при создании которого используется данный
инструмент. Термин «заявитель» также используется для идентификации организации,
подавшей заявку на одобрение ПО и (или) квалификации инструмента.
d.
Чтобы получить одобрение соответствующего органа сертификации, должны быть
включены в соответствующие планы возможные цели, трактовки и адаптации
настоящего документа.
e.
Следует обеспечить согласование между ЖЦ инструмента
задокументировать это в следующих данных ЖЦ ПО:
и
ЖЦ
ПО
и
•
план, идентифицирующий инструменты и необходимость их квалификации.
В настоящем документе эти данные называются Планом сертификации ПО;
•
сводка и состояние всех выполненных мероприятий, включая состояние
инструментов, которые должны быть квалифированы. В настоящем документе эти
данные называются Итоговое заключение о ПО;
•
указатель конфигурации программной среды, включающий идентификацию
инструментов и данные квалификации инструментов. В настоящем документе эти
данные называются Указатель конфигурации среды ЖЦ ПО.
Вне зависимости от области ожидается, что будут созданы эквивалентные данные
(которые могут иметь отличающиеся названия).
f.
В настоящем документе предполагается, что инструмент используется для
исключения, упрощения или автоматизации некоторого процесса ЖЦ ПО без
верификации выходных данных этого инструмента, а также, что эти процессы
определяются в форме совокупности целей. Поэтому сертификационный зачет
инструмента обусловлен достижением одной или нескольких целей. Возможно, что
инструктивные материалы для некоторой области не определены в терминах
«процессы» и «цели». В таком случае определение сертификационного зачета
следует адаптировать под терминологию конкретной области.
д.
В проекте для области, в которой не существует инструктивных материалов для
определения критериев квалификации инструментов и применимых уровней
квалификации инструментов, тоже можно использовать настоящий документ.
Применимый уровень квалификации инструментов и его обоснование следует
определять в Плане сертификации ПО проекта или в эквивалентном документе.
h.
Чтобы определить применимость целей для каждого
пользователи должны обратиться к Приложению А.
уровня
квалификации,
1.4 Структура документа
На рисунке 1-1 представлен обзор настоящего документа. Следует отметить, что разделы
1, 2 и 3, а также дополнения содержат пояснительную информацию, чтобы помочь читателю
понять назначение настоящего документа (эти разделы не считаются указаниями).
Руководство Р-330
11
Назначение квалификации инструмента - Раздел 2
Характеристики квалификации инструмента - Раздел 3
Процессы жизненного цикла инструмента
Процесс планирования квалификации инструмента - Раздел 4
Процессы разработки инструмента - Раздел 5
Интегральные процессы
Процесс верификации инструмента - Раздел б
Процесс управления конфигурацией инструмента - Раздел 1
Процесс гарантии качества инструмента - Раздел 8
Процесс взаимодействия с Сертифицирующим органом
для квалификации инструмента - Раздел 9
Данные квалификации инструмента - Раздел 10
Дополнительные соображения по квалификации инструмента Разбел 11
Цели квалификации инструмента - Приложение А
Сокращения и словарь терминов - Приложение В
Вспомогательная информация - Справочные материалы A -D
Рисунок 1-1. Обзор документа
12
Руководство Р-330
2.0
НАЗНАЧЕНИЕ КВАЛИФИКАЦИИ ИНСТРУМЕНТА
Инструменты могут содействовать при разработке ПО анализу и потенциальному
усовершенствованию системы за счет автоматизации выполняемых мероприятий и за счет
предсказуемого выполнения функций, подверженных человеческим ошибкам. Однако,
ошибка в инструменте может иметь негативное влияние на функциональность ПО, если
инструмент неадекватно выполняет заданные функции. Чтобы избежать этого риска и
гарантировать
целостность
функциональности
инструмента,
инструмент
следует
разрабатывать и проверять с использованием адекватных процессов. Этой цели служит
квалификация инструментов.
Квалификация инструментов является процессом, необходимым для получения
сертификационного зачета для инструмента. Этот зачет может быть получен только в рамках
проекта, требующего одобрения.
Назначение процесса квалификации инструментов - удостовериться в функциональности
инструмента. Объем работ по квалификации инструмента варьируется в зависимости от
потенциального воздействия, которое может оказать ошибка инструмента на безопасность
системы и на использование инструмента вЖ Ц ПО в целом. Чем выше риск неблагоприятного
влияния ошибки инструмента на безопасность системы, тем строже требования для
квалификации инструментов.
Процесс квалификации инструментов может применяться к одной или нескольким
функциям инструмента, к одному инструменту или к набору инструментов (дополнительную
информацию о многофункциональных инструментах см. в разделе 11.1).
Во время квалификационных работ, используя цели этого документа, должно быть
продемонстрировано, что выходные данные всех квалифицируемых функций инструмента
являются корректными. Для инструмента, выходные данные которого могут меняться в
заданных пределах, следует продемонстрировать, что данный разброс не оказывает
неблагоприятного влияния на использование по назначению выходных данных и что
правильность выходных данных может быть подтверждена. Однако для инструмента,
выходные данные которого являются частью ПО и, таким образом, могут внести ошибку,
следует продемонстрировать, что функции квалифицированного инструмента создают одни и
те же выходные данные для одинаковых входных данных при работе в той же самой среде.
Руководство Р-330
3.0
13
ХАРАКТЕРИСТИКИ КВАЛИФИКАЦИИ ИНСТРУМЕНТА
3.1 Уровни квалификации
Требуемый уровень квалификации основывается на назначении инструмента и его
потенциальном влиянии в процессе ЖЦ ПО. Настоящий документ определяет пять уровней
квалификации инструментов (от TQL-1 до TQL-5). По мере роста потенциального влияния
инструмента на процесс ЖЦ ПО растет строгость уровня квалификации инструментов из-за
потенциального влияния на безопасность системы. Определение того, какой уровень
присваивается квалификации инструмента, выполняется путем оценки использования
данного инструмента в процессе ЖЦ ПО, как определено в связанных с конкретной областью
инструктивных материалах (например, раздел 12.2 документа КТ-178С).
Уровень строгости квалификации меняется в зависимости от уровня квалификации.
Уровень квалификации инструмента TQL-1 является самым строгим уровнем и требует
хорошо определенных и исполненных процессов разработки, верификации и интегральных
процессов инструмента с наивысшим уровнем независимости верификации. Остальные
уровни требуют меньшей строгости. Уровень квалификации инструмента TQL-5 является
уровнем квалификации с минимальной строгостью. В Приложении А определяются
применимые цели для каждого уровня квалификации инструментов.
3.2 Заинтересованные в квалификации стороны
Обычно квалификация инструментов затрагивает несколько заинтересованных сторон.
В большинстве проектов будут как пользователь инструмента, так и разработчик инструмента.
Пользователь инструмента обычно определяет используемый инструмент, оценивает его
влияние на процессы ПО, рассматривает использование данного инструмента в рамках того
процесса ПО, в котором инструмент используется, и выполняет квалификацию инструмента в
рамках одобрения ПО. Разработчик инструмента обычно описывает процессы разработки,
верификации и интегральные процессы инструмента и рассматривает разработку
инструмента
в соответствии
с
потребностями
пользователя,
выраженными
в
Эксплуатационных требованиях к инструменту.
Определенные выше заинтересованные стороны и роли могут меняться. Также могут быть
определены дополнительные заинтересованные стороны (например, интегратор инструмента
или верификатор инструмента). Документы планирования: План сертификации ПО и/или План
квалификации инструмента (в зависимости от того, что подходит) должны определять
заинтересованные стороны, а также роль и ответственность каждой заинтересованной
стороны в работе по квалификации инструмента. В конечном счете Заявитель является
ответственным за обеспечение того, чтобы были достигнуты все цели квалификации
инструментов.
Руководство Р-330
14
4.0
ПРОЦЕСС ПЛАНИРОВАНИЯ КВАЛИФИКАЦИИ ИНСТРУМЕНТА
В данном разделе рассматриваются цели и мероприятия процесса планирования
квалификации инструмента. В процессе планирования квалификации инструмента
определяется инструмент, оценивается его влияние в процессах ЖЦ ПО, а также
описываются процессы разработки, верификации и интегральные процессы ЖЦ инструмента.
Процесс планирования квалификации инструмента включает: (1) оценку квалификации
инструмента как часть процесса планирования ПО (см. часть «Процесс планирования»
таблицы Т-0 Приложения А) и (2) процесс планирования инструмента
(см. всю таблицу Т-1 Приложения А). В таблице Т-0 и таблице Т-1 Приложения А
представлены сводки целей и выходных данных процесса планирования разработки
инструментов для каждого уровня квалификации инструментов.
4.1 Определение необходимости квалификации инструмента
В процессе планирования создания ПО:
•
идентифицируются инструменты, используемые в рамках процесса ЖЦ ПО;
•
описывается предполагаемое применение каждого инструмента;
•
определяется необходимость квалификации инструмента;
•
определяются уровни квалификации инструментов;
•
идентифицируются стороны, заинтересованные в квалификации инструментов, и
назначенные им роли и ответственность;
•
описывается среда эксплуатации инструмента.
В случае наличия нескольких вариантов среды эксплуатации инструмента описываются
все такие среды. Все эти вопросы должны быть рассмотрены в разделе дополнительных
указаний Плана сертификации ПО. План сертификации ПО объясняет использование
инструментов в процессах ЖЦ ПО и необходимость квалификации инструментов. Аспекты
инструмента, которые должны быть рассмотрены в Плане сертификации ПО, см. в
разделе 10.1.1 настоящего документа.
4.2 Определение жизненного цикла инструмента
В процессе планирования инструмента проект определяет один или более ЖЦ
посредством
выбора
мероприятий
для
каждого
из
процессов,
установления
последовательности мероприятий и назначения ответственных за эти мероприятия.
Процессами ЖЦ инструмента являются:
a.
Процесс планирования инструмента, который определяет и координирует
мероприятия процессов разработки и интегральных процессов инструмента.
b.
Процессы разработки инструмента, в результате выполнения которых создается
инструмент.
c.
Интегральные процессы, которые обеспечивают правильность, управляемость и
доверие к процессам ЖЦ инструментов и их выходным данным. Интегральные
процессы включают процесс верификации инструмента, процесс управления
конфигурацией инструмента, процесс гарантии качества инструмента, процесс
взаимодействия с Сертифицирующим органом для квалификации инструмента. Важно
понимать, что интегральные процессы выполняются одновременно с процессами
разработки инструмента в течение всего ЖЦ инструмента.
Настоящий документ не предписывает предпочтительные ЖЦ инструментов и
взаимодействие между ними. Разделение процессов не определяет структуру организации
(организаций), выполняющей их. Для каждого инструмента жизненный(е) цикл(ы) включает
эти процессы.
Руководство Р-330
15
Определение ЖЦ инструмента включает критерии перехода, которые используются,
чтобы определить, можно ли начинать или повторно начинать некоторый процесс. Каждый
процесс выполняет действия над входными данными для того, чтобы получить выходные
данные. Процесс может создавать обратную связь для других процессов, а также
использовать обратные связи из других процессов. Определение обратной связи включает
решение вопросов, каким образом информация распознается, контролируется и используется
для принятия решения принимающим процессом. Примером обратной связи является
сообщение о проблеме.
Критерии перехода будут зависеть от запланированной последовательности процессов
разработки инструментов и интегральных процессов, на них также может влиять уровень
квалификации инструментов. Если установленные для процесса критерии перехода
удовлетворены, не обязательно все входные данные должны быть готовы для того, чтобы
процесс мог начаться.
Если некоторый процесс использует неполные входные данные, то следует проверить
входные данные процесса, чтобы убедиться, что они удовлетворяют критериям перехода.
Кроме того, при поступлении новых входных данных их необходимо проверить, чтобы
убедиться, что остались в силе предыдущие выходные данные процессов разработки и
верификации инструмента.
4.3 Цели процесса планирования инструмента
Цели процесса планирования инструмента следующие:
a.
Определить процесс(ы) ЖЦ инструмента в соответствии с его предполагаемым
использованием, как определено в Плане сертификации ПО, включая пункты,
указанные выше в разделе 4.1.
b.
Определить ЖЦ инструмента с указанием взаимосвязей между процессами,
последовательности их выполнения, схем обратных связей и критериев перехода.
c.
Определить среду разработки инструмента, включая методы и инструменты, которые
будут использованы для мероприятий каждого процесса ЖЦ инструмента.
d.
При необходимости учесть дополнительные указания, подобные тем, которые
обсуждены в разделе 11 настоящего документа, и необходимость квалификации
любого инструмента (инструментов), используемых в рамках процессов ЖЦ
инструмента.
e.
Определить стандарты на разработку инструмента.
f.
Обеспечить соответствие планов создания инструмента разделу 10 настоящего
документа.
д.
Скоординировать разработку и рассмотрение планов создания инструмента.
4.4 Мероприятия процесса планирования инструмента
Для достижения целей настоящего документа требуется эффективное планирование.
Мероприятия для этого процесса следующие:
а.
Должны быть разработаны План квалификации инструмента (TQP), План разработки
инструмента, План верификации инструмента, План гарантии качества инструмента и
План управления конфигурацией инструмента, которые покрывают весь ЖЦ
инструмента. Эти планы могут быть раздельными или комбинированными, что больше
соответствует потребностям конкретного проекта. В качестве примера поставщик
инструментов может предложить пригодный для квалификации инструмент и
разработать планы, которые покрывают только процесс разработки инструмента
(см. в разделе 11.3 информацию о квалификации покупного готового инструмента
(COTS)), но описание процессов определения Эксплуатационных требований к
инструменту и эксплуатационной интеграции инструмента может быть рассмотрено в
16
Руководство Р-330
отдельном комплекте планов создания инструмента. Каждый план и поддерживающие
стандарты кратко описываются ниже, а детально - в разделе 10.
1.
План квалификации инструмента (см. раздел 10.1.2) служит в качестве основного
средства представления Сертифицирующему органу предлагаемого ЖЦ
инструмента и методов разработки для согласования. План квалификации
инструмента определяет методы подтверждения соответствия настоящему
документу и любым другим применимым руководствам (например, документа
области или конкретного проекта).
2.
План разработки инструмента (см. раздел 10.1.3) определяет ЖЦ инструмента,
среду и процессы разработки инструмента, а также средства, с помощью которых
будут достигнуты цели процесса разработки инструмента.
3.
План верификации инструмента (см. раздел 10.1.4) определяет средства, с
помощью которых будут достигнуты цели процесса верификации инструмента.
4.
План управления конфигурацией инструмента (см. раздел 10.1.5) определяет
средства, с помощью которых будут достигнуты цели процесса управления
конфигурацией инструмента.
5.
План гарантии качества инструмента (см. раздел 10.1.6) определяет средства, с
помощью которых будут достигнуты цели процесса гарантии качества инструмента.
b.
Следует разработать стандарты на разработку инструментов. Назначение стандар­
тов - определить правила и ограничения для процессов разработки инструмента.
Стандарты на разработку инструментов включают Стандарты на разработку
требований к инструменту (см. раздел 10.1.7), Стандарты на проектирование
инструмента (см. раздел 10.1.8) и Стандарты на кодирование инструмента (см. раздел
10.1.9). В процессе верификации инструмента указанные стандарты используются в
качестве основы для оценки соответствия действительных выходных данных
некоторого процесса заданным выходным данным.
c.
Должна быть определена среда(ы) верификации инструмента. Должно быть
продемонстрировано, что среда(ы) верификации является репрезентативной для
среды эксплуатации инструмента. Следует позаботиться об идентификации
операционной системы, дополнительной аппаратуры, дополнительных компонентов
ПО и т.п. Следует отметить, что может потребоваться несколько сред верификации
инструмента, если потенциально существует несколько сред эксплуатации
инструмента (например, инструмент может использоваться на нескольких
платформах с различными версиями операционных систем, в зависимости от
конкретных эксплуатационных потребностей).
d.
Должны быть выполнены рассмотрения процесса планирования инструмента, чтобы
гарантировать, что в планах и стандартах соблюдены указания настоящего документа
и существуют средства для их выполнения.
e.
Чтобы определить необходимость квалификации инструментов, должна быть
проведена оценка всех инструментов, используемых в рамках процессов ЖЦ
инструмента. Квалификация инструментов требуется в тех случаях, когда процессы,
указанные в настоящем документе, исключаются, упрощаются или автоматизируются
за счет применения инструмента без верификации его выходных данных, как
изложено в разделе 6. Для инструмента, который может внести ошибку в выходные
данные другого инструмента, применяется тот же уровень квалификации
инструментов, что и для разрабатываемого инструмента. Для инструмента, который
не может внести ошибку в выходные данные другого инструмента, но может не
обнаружить ошибку в данных ЖЦ инструмента, применяется уровень квалификации
инструментов TQL-5.
Руководство Р-330
5.0
17
ЖИЗНЕННЫЙ ЦИКЛ И ПРОЦЕССЫ РАЗРАБОТКИ ИНСТРУМЕНТА
В настоящем разделе рассматриваются цели и мероприятия ЖЦ разработки инструмента.
Процессы разработки инструмента применяются так, как это определено процессом
планирования (см. раздел 4) и Планом разработки инструмента (см. раздел 10.1.3).
ЖЦ разработки для конкретного инструмента может быть адаптирован на основе уровня
квалификации инструмента. Основным назначением процесса квалификации инструмента
является подтверждение того, что инструмент соответствует требованиям к нему и
удовлетворяет потребностям процесса ЖЦ ПО. Поэтому потребности с точки зрения процесса
ЖЦ ПО определяются в Эксплуатационных требованиях к инструменту, а описание всей
функциональности и характеристик, необходимых для разработки инструмента, представлено
в Требованиях к инструменту. Весь ЖЦ разработки инструмента включает три основных
процесса, как показано на рисунке 5-1 и описано ниже. Хотя эти процессы описываются в
контексте линейной водопадной модели ЖЦ, следует отметить, что могут использоваться и
другие модели ЖЦ.
Рисунок 5-1. Полный жизненный цикл разработки инструмента
Здесь каждый процесс описывается кратко, а детальное описание см. в разделах 5.1-5.3.
a.
Процесс определения Эксплуатационных требований к инструменту (см. раздел 5.1).
Эксплуатационные требования к инструменту должны определять, как инструмент
должен использоваться в ЖЦ ПО. Они могут содержать не все требования,
необходимые для разработки инструмента. Степень подробности Эксплуатационных
требований к инструменту зависит от самого инструмента и его предполагаемого
использования. Валидация и верификация Эксплуатационных требований к
инструменту необходимы для подтверждения того, что данный инструмент
удовлетворяет
потребности
процесса
ЖЦ
ПО.
Процесс
определения
Эксплуатационных требований к инструменту описывается в Плане разработки
инструмента. Выходными данными этого процесса являются Эксплуатационные
требования к инструменту.
b.
Процессы разработки инструмента (см. раздел 5.2). Процессы разработки
инструмента применяются так, как это определено в Плане квалификации
инструмента и в Плане разработки инструмента. Процессами разработки инструмента
являются:
•
процесс разработки требований к инструменту;
•
процесс проектирования инструмента;
•
процесс кодирования инструмента;
•
процесс интеграции инструмента.
18
Руководство Р-330
В процессе разработки требований к инструменту вырабатываются Требования
к инструменту. В Требованиях к инструменту представлены требования, используемые для
разработки инструмента. Требования к инструменту должны создаваться на основе анализа
Эксплуатационных требований к инструменту. Однако некоторые инструменты будут
разрабатываться для широкого спектра применений и не основываться на каких-либо
конкретных Эксплуатационных требованиях к инструменту. Дополнительную информацию о
таких инструментах см. в разделе 11.3.
Описание Проекта инструмента включает архитектуру инструмента и может содержать
один или несколько уровней требований низкого уровня. Однако если Исходный код
инструмента может быть получен непосредственно из Требований к инструменту, тогда
Требования к инструменту также рассматриваются как требования низкого уровня, и
инструктивные материалы по требованиям низкого уровня также применимы к Требованиям к
инструменту. Исходный код разрабатывается на основании архитектуры инструмента и
требований низкого уровня.
Исполняемый объектный код инструмента генерируется в среде разработки инструмента.
В таблице Т-2 Приложения А представлена итоговая сводка целей и выходных данных
процессов разработки инструментов по уровням квалификации инструментов.
с.
Процесс эксплуатационной интеграции инструмента (см. раздел 5.3). Процесс
эксплуатационной интеграции инструмента выполняется так, как определено планами
создания инструмента. Входными данными процесса эксплуатационной интеграции
инструмента являются Исполняемый объектный код инструмента, инструкции
пользователя и инструкции по установке. Они предоставляются процессом разработки
инструмента для использования и установки инструмента в эксплуатационной среде
инструмента. Выходными данными процесса эксплуатационной интеграции
инструмента является Исполняемый объектный код инструмента, установленный в
эксплуатационной среде инструмента.
5.1 Процесс определения Эсплуатационных требований к инструменту
Эксплуатационные требования к инструменту определяют, как данный инструмент будет
использоваться в процессе ЖЦ ПО. Входными данными для этого процесса являются планы
создания ПО и инструментов. Эксплуатационные требования к инструменту являются
основными выходными данными этого процесса (см. раздел 10.3.1). В части таблицы Т-0,
описывающей определение Эксплуатационных требований к инструменту, Приложения А
приведена сводка целей и выходных данных этого процесса по уровням квалификации
инструментов.
5.1.1 Цели определения Эксплуатационных требований к инструменту
Цель процесса разработки эксплуатационных требований к инструменту:
а.
Эксплуатационные требования к инструменту определены.
5.1.2 Мероприятия по определению Эксплуатационных требований инструмента
Мероприятия для этого процесса следующие:
a.
Эксплуатационные требования к инструменту должны быть разработаны так, чтобы
включить как минимум все элементы, определенные в разделе 10.3.1.
b.
Эксплуатационные требования к инструменту должны быть верифицируемыми и
непротиворечивыми.
Они
должны
быть
достаточно
подробными,
чтобы
демонстрировать, что функциональность и выходные данные инструмента
соответствуют указанным мероприятиям ЖЦ ПО, которые выполняются этим
инструментом.
c.
Эксплуатационные требования к инструменту должны быть достаточно подробными
для
поддержки
верификации
способности
инструмента
выполнять
цели
автоматизируемого, исключаемого или упрощаемого процесса (процессов).
Руководство Р-330
19
5.2 Процессы разработки инструмента
Назначение процессов разработки инструмента - определить Требования к инструменту
и создать ПО, необходимое для их воплощения. Типовыми процессами разработки
инструмента являются:
•
процесс разработки требований к инструменту;
•
процесс проектирования инструмента;
•
процесс кодирования инструмента;
•
процесс интеграции инструмента.
В Приложении А представлена итоговая сводка целей и выходных данных процессов
разработки инструментов по уровням квалификации инструментов.
5.2.1 Процесс разработки требований к инструменту
Требования к инструменту представляют собой требования, используемые для
разработки и верификации инструмента. Входными данными для этого процесса являются
Эксплуатационные требования к инструменту, План разработки инструмента и Стандарты
разработки требований к инструменту. Требования к инструменту являются основными
выходными данными этого процесса (см. раздел 10.2.1).
5.2.1.1 Цели разработки требований к инструменту
Цели процесса разработки требований к инструменту следующие:
a.
Разработаны требования к инструменту.
b.
Определены производные требования к инструменту, если это необходимо.
5.2.1.2 Мероприятия по разработке требований к инструменту
Мероприятия этого процесса следующие:
a.
Требования к инструменту должны разрабатываться и документироваться таким
образом, чтобы можно было определить, удовлетворяет ли инструмент
Эксплуатационным требованиям к инструменту.
b.
Требования к инструменту должны включать все функциональные требования и
требования, связанные с интерфейсами, которые будут воплощены в инструменте.
c.
Требования к инструменту должны разрабатываться
описываемым в Плане разработки инструмента.
d.
Требования к инструменту должны разрабатываться с использованием Стандартов
разработки требований к инструменту.
e.
Требования к инструменту должны быть проверяемыми и непротиворечивыми.
f.
Требования к инструменту должны быть определены таким образом, чтобы
обнаруживалось ненормальное поведение и предотвращалась выдача неправильных
выходных данных. Например, для инструмента лучше не выдавать выходных данных
вообще, чем выдавать неправильные. Таким образом, Требования к инструменту
должны рассматривать отказные состояния и описывать реакцию на них.
д.
Каждое требование к инструменту должно трассироваться на одно или более из
Эксплуатационных требований к инструменту, за исключением производных
требований к инструменту.
h.
Производными требованиями к инструменту являются такие, которые не
трассируются на Эксплуатационные требования к инструменту. Существование
производных требований к инструменту должно быть обосновано, они должны быть
оценены, чтобы гарантировать, что они не влияют отрицательно на ожидаемую
согласно
процессам,
20
Руководство Р-330
функциональность и выходные
требованиях к инструменту.
данные,
определяемые
в
Эксплуатационных
L
Требования к инструменту должны содержать инструкции пользователя, перечень
сообщений об ошибках и ограничения.
].
Требования к инструменту должны идентифицировать требования, относящиеся .к
неиспользуемым
функциям
инструмента,
которые
не
трассируются
на
Эксплуатационные требования к инструменту. Руководство по многофункциональным
инструментам см. в разделе 11.1.
к.
Требования к инструменту должны быть определены до такого уровня детализации,
который обеспечивает надлежащую реализацию инструмента и возможность оценки
правильности его работы (например, определением базовых моделей или
математических методов).
5.2.2 Процесс проектирования инструмента
Требования к инструменту уточняются в ходе одной или более итераций в процессе
проектирования инструмента, чтобы определить архитектуру и требования низкого уровня до
такой степени, чтобы их можно было использовать для создания Исходного кода инструмента.
Входными данными для процесса проектирования инструмента являются Требования к
инструменту, План разработки инструмента и Стандарты на проектирование инструмента.
Когда запланированные критерии перехода удовлетворены, Требования к инструменту
используются в процессе проектирования инструмента для разработки архитектуры
инструмента и требований низкого уровня. Основными выходными данными процесса
проектирования инструмента является Описание проекта инструмента (см. раздел 10.2.2).
5.2.2.1 Цели проектирования инструмента
В процессе проектирования инструмента создается Описание проекта инструмента.
Целями являются:
a.
Разработана архитектура инструмента.
b.
Разработаны требования низкого уровня к инструменту.
c.
Определены производные требования низкого уровня, если это необходимо.
5.2.2.2 Мероприятия проектирования инструмента
Мероприятия этого процесса следующие:
a.
В процессе проектирования инструмента должна быть определена архитектура
инструмента.
b.
Проект инструмента должен определить все архитектурные особенности инструмента,
такие как защита, если это применимо. Защита может использоваться для
изолирования частей инструмента или набора инструментов с целью применения
другого подхода или другого уровня квалификации. См. раздел 11.1 для
многофункциональных инструментов.
c.
Требования к инструменту должны быть уточнены в форме требований низкого уровня
к инструменту, которые трассируются на Требования к инструменту или определяются
как производные требования низкого уровня к инструменту.
d.
Производные требования низкого уровня к инструменту не трассируются на
Требования к инструменту. Существование производных требований к инструменту
должно быть обосновано, они должны быть оценены, чтобы убедиться, что они не
влияют отрицательно на ожидаемую функциональность и выходные данные,
определяемые в Эксплуатационных требованиях к инструменту.
Руководство Р-330
21
e.
Описание проекта инструмента, включая архитектуру инструмента. и требования
низкого уровня
к инструменту, должно соответствовать Стандартам на
проектирование инструмента.
f.
Проект инструмента должен быть проверяемым и непротиворечивым.
д.
В случаях, когда инструмент использует внешние компоненты, которые не находятся
под контролем разработчика инструмента (такие как функции операционной системы
или внешние библиотеки ПО), интерфейсы с этими внешними компонентами,
используемые инструментом, должны быть указаны в Описании проекта инструмента.
Описание такого интерфейса должно определять все внешние компоненты, такие как
подпрограммы управления файлами, примитивы, вызовы распределения памяти и
подпрограммы, поддерживающие управление интерфейсом пользователя (например,
командной строкой или выводом сообщений).
5.2.3 Процесс кодирования инструмента
В процессе кодирования инструмента Исходный код инструмента реализуется на
основании Описания проекта инструмента, содержащего архитектуру инструмента и
требования низкого уровня к инструменту. Входными данными для процесса кодирования
инструмента являются Описание проекта инструмента, План разработки инструмента и
Стандарты кодирования инструмента. В процесс кодирования инструмента можно войти или
повторно войти после того, как удовлетворены запланированные критерии перехода.
Основными выходными данными этого процесса является Исходный код инструмента (см.
раздел 10.2.3).
5.2.3.1 Цели кодирования инструмента
Цель процесса кодирования инструмента следующая:
а.
Исходный код инструмента разработан на основании требований низкого уровня к
инструменту.
5.2.3.2 Мероприятия кодирования инструмента
Мероприятия для этого процесса следующие:
a.
Исходный код инструмента должен реализовывать требования низкого уровня к
инструменту и соответствовать архитектуре инструмента.
b.
Исходный код инструмента должен соответствовать Стандартам на кодирование
инструмента.
c.
Исходный код инструмента должен трассироваться на требования низкого уровня к
инструменту.
d.
Недостаточные или неправильные входные данные, выявленные в процессе
кодирования инструмента, следует передать в процесс(ы), которые создали неверные
исходные данные, для уточнения или поправок.
5.2.4 Процесс интеграции инструмента
Процесс интеграции инструмента заключается в создании инструмента в его исполняемом
формате. Обычно это достигается за счет компиляции и компоновки Исходного кода
инструмента в среде разработки инструмента. Если среда разработки инструмента
отличается от среды верификации инструмента, тогда Исполняемый объектный код
инструмента должен быть установлен в среду верификации инструмента. К процессу
интеграции можно перейти или повторно перейти после того, как выполнены
запланированные критерии перехода. Входными данными для процесса интеграции
инструмента являются Исходный код инструмента и План разработки инструмента.
Основными выходными данными процесса интеграции инструмента являются Исполняемый
объектный код инструмента (см. раздел 10.2.4) и данные компиляции и компоновки.
22
Руководство Р-330
5.2.4.1 Цели интеграции инструмента
Целями процесса интеграции инструмента являются:
a.
Сгенерирован
инструмента.
Исполняемый
объектный
код
инструмента
в среде
разработки
b.
Установлен Исполняемый объектный код инструмента в среду(ы) верификации
инструмента.
5.2.4.2 Мероприятия интеграции инструмента
Мероприятия этого процесса следующие:
a.
Исполняемый объектный код инструмента должен генерироваться из Исходного кода
инструмента по инструкциям компилятора и компоновки. Следует отметить, что
Исполняемый объектный код инструмента иногда включает другие файлы, такие как
файлы конфигураций.
b.
Недостаточные или неправильные входные данные, выявленные в процессе
интеграции инструмента, следует передать в процесс(ы), которые создали
недостаточные или неправильные входные данные.
c.
Если среда верификации инструмента отличается от среды разработки этого
инструмента или существуют несколько сред верификации инструмента, тогда
Исполняемый объектный код инструмента должен быть установлен в среду(ы)
верификации инструмента.
5.2.5 Трассируемость процесса разработки инструмента
Мероприятия трассируемости в процессе разработки инструмента включают:
a.
Разработку Данных трассировки, демонстрирующих двунаправленную связь между
Эксплуатационными требованиями к инструменту и Требованиями к инструменту,
чтобы:
1) обеспечить возможность верификации полноты реализации Эксплуатационных
требований к инструменту;
2)
b.
показать те производные требования, которые не трассируются напрямую на
Эксплуатационные требования к инструменту.
Разработку Данных трассировки, демонстрирующих двунаправленную связь между
Требованиями к инструменту и требованиями низкого уровня к инструменту, чтобы:
1) обеспечить возможность
инструменту;
2)
c.
верификации
полноты
реализации
Требований
к
показать те производные требования низкого уровня к инструменту, которые не
трассируются напрямую на Требований к инструменту и проектные архитектурные
решения, принятые в процессе проектирования инструмента.
Разработку Данных трассировки, демонстрирующих двунаправленную связь между
требованиями низкого уровня к инструменту и Исходным кодом инструмента, чтобы:
1)
обеспечить возможность верификации того, что в Исходном коде инструмента не
реализованы незадокументированные функции;
2)
обеспечить возможность верификации полноты реализации требований низкого
уровня к инструменту.
23
Руководство Р-330
5.3 Процесс эксплуатационной интеграции инструмента
Назначение процесса эксплуатационной интеграции инструмента - установить
Исполняемый объектный код в эксплуатационную среду инструмента, определенную в
Эксплуатационных требованиях к инструменту и любых дополнительных инструкциях (таких
как руководство пользователя), а также получить уверенность в том, что инструмент работает
в среде эксплуатации инструмента так, как этого ожидает пользователь инструмента.
К процессу эксплуатационной интеграции инструмента можно перейти или повторно
перейти после того, как удовлетворены запланированные критерии перехода. Входными
данными процесса эксплуатационной интеграции инструмента являются Исполняемый
объектный код инструмента (включая все сопутствующие файлы, если таковые необходимы)
и руководство пользователя (которое может быть частью Требований к инструменту).
Основными выходными данными процесса эксплуатационной интеграции инструмента
являются Исполняемый объектный код инструмента (см. раздел 10.2.4), установленный в
среде эксплуатации инструмента, и Отчет об установке инструмента (см. раздел 10.3.2).
В части «Процесса Эксплуатационной интеграции инструмента» таблицы Т-0 Приложения А
приведена сводка целей и выходных данных этого процесса по уровням квалификации
инструментов.
5.3.1 Цели процесса эксплуатационной интеграции инструмента
Целью процесса эксплуатационной интеграции инструмента является:
а.
Исполняемый
инструмента.
объектный
код
инструмента
установлен
в среду
эксплуатации
5.3.2 Мероприятия процесса эксплуатационной интеграции инструмента
Мероприятия этого процесса следующие:
a.
Должен быть установлен Исполняемый объектный код инструмента (включая все
сопутствующие файлы, такие как файлы конфигураций) в среду эксплуатации данного
инструмента.
b.
Должны быть переданы недостаточные или неправильные входные данные,
выявленные в процессе эксплуатационной интеграции инструмента, в процесс(ы),
которые создали недостаточные или неправильные входные данные.
c.
Должен быть создан Отчет об установке инструмента (см. раздел 10.3.2),
24
Руководство Р-330
6.0
ПРОЦЕСС ВЕРИФИКАЦИИ ИНСТРУМЕНТА
В настоящем разделе рассматриваются цели и описываются мероприятия всего процесса
верификации инструмента. Этот процесс состоит из двух частей:
a.
Процесс верификации инструмента (см. раздел 6.1).
b.
Процесс эксплуатационной верификации и валидации инструмента (см. раздел 6.2).
Примечание.
Верификация
выходных
данных
рассматривается в разделе 4.4,d.
процесса
планирования
6.1 Процесс верификации инструмента
Верификация - это техническая оценка выходных данных как процесса разработки
инструмента, так и процесса верификации инструмента. Процесс верификации инструмента
выполняется так, как это было определено процессом планирования инструмента (см.
раздел 4), и в соответствии с Планом верификации инструмента (см. раздел 10.1.4).
Верификация включает рассмотрения, анализы и тестирование.
Таблицы с Т-3 по Т-7 Приложения А содержат краткое изложение целей и выходных
данных процесса верификации инструментов в соответствии с уровнем квалификации
инструмента.
6.1.1 Назначение процесса верификации инструмента
Назначением процесса верификации инструмента является обнаружение и регистрация
ошибок, которые, возможно, были внесены в процессах разработки инструмента. Устранение
ошибок - мероприятия процессов разработки инструмента. Процесс верификации
инструмента проверяет, что:
a.
Эксплуатационные требования к инструменту переработаны в Требования к
инструменту, и что Требования к инструменту удовлетворяют Эксплуатационным
требованиям к инструменту и трассируются на них.
b.
Требования к инструменту переработаны в Описание проекта инструмента
(архитектуру инструмента и требования низкого уровня к инструменту), которое
удовлетворяет Требованиям к инструменту. Требования низкого уровня к инструменту
должны удовлетворять Требованиям к инструменту и трассироваться на них.
c.
Архитектура инструмента и требования низкого уровня к инструменту воплощены в
Исходном коде инструмента, который удовлетворяет Описанию проекта инструмента.
Исходный код инструмента должен удовлетворять требованиям низкого уровня к
инструменту и трассироваться на них.
d.
Исполняемый объектный код инструмента удовлетворяет требованиям к инструменту
(т.е. заданной функции) и обеспечивает уверенность в отсутствии незаданной
функциональности.
6.1.2 Обзор мероприятий верификации инструмента
Цели верификации инструмента достигаются посредством сочетания рассмотрений,
анализов, разработки тестовых примеров и процедур и последующего выполнения тестовых
процедур.
Рассмотрения
и анализы
позволяют оценить точность,
полноту и
верифицируемость Требований к инструменту, Описания проекта инструмента и Исходного
кода инструмента. Рассмотрения оценивают также соответствие применяемым стандартам
разработки. Разработка тестовых примеров и процедур может обеспечить более полную
оценку внутренней непротиворечивости и полноты Требований к инструменту и требований
низкого
уровня
к
инструменту.
Выполнение
тестовых
процедур
позволяет
продемонстрировать соответствие Исполняемого объектного кода инструмента Требованиям
к инструменту и требованиям низкого уровня к инструменту.
Руководство Р-330
25
Входные данные процесса верификации инструмента включают Эксплуатационные
требования к инструменту, Требования к инструменту, Описание проекта инструмента,
Данные трассировки, Исходный код инструмента, Исполняемый объектный код инструмента
и План верификации инструмента.
Выходные данные процесса верификации инструмента фиксируются в виде Примеров и
Процедур верификации инструмента (см. раздел 10.2.5), Результатов верификации
инструмента (см. раздел 10.2.6) и соответствующих Данных трассировки (см. раздел 10.2.7).
Указания для этого процесса следующие:
a.
Чтобы определить, что более высокий уровень требований удовлетворяется более
низкими уровнями требований (или исходным кодом), и чтобы выделить производные
требования, должна существовать следующая трассировка:
1.
Требования к инструменту должны
требования к инструменту.
трассироваться
на
Эксплуатационные
2.
Требования низкого уровня к инструменту должны трассироваться на Требования
к инструменту.
3.
Исходный код инструмента должен трассироваться на требования низкого уровня
к инструменту.
b.
Чтобы обнаружить требования, не покрытые тестовыми примерами, тестовые
примеры должны трассироваться на требования (Требования к инструменту и
требования низкого уровня к инструменту).
c.
Чтобы проверить, что все тестовые примеры применены в тестовых процедурах,
тестовые процедуры должны трассироваться на тестовые примеры.
d.
Если нет возможности верифицировать некоторые Требования к инструменту, должны
быть применены другие средства, и обоснование того, что эти средства обеспечивают
достижение целей процесса верификации, должно быть определено в Плане
верификации инструмента и/или Результатах верификации инструмента.
e.
Информация о недостатках и ошибках, выявленных в процессе верификации
инструмента, должна быть передана в соответствующие процессы разработки
инструмента для уточнения и исправления.
6.1.3 Рассмотрения и анализы
Рассмотрения и анализы должны выполняться для обнаружения и регистрации ошибок,
которые могли быть внесены в процессах разработки инструмента.
6.1.3.1 Рассмотрения и анализы Требований к инструменту
Назначением рассмотрений и анализов является обнаружение и регистрация ошибок в
требованиях, которые могли быть внесены в процессе разработки требований к инструменту.
Эти мероприятия рассмотрений и анализов подтверждают, что Требования к инструменту
удовлетворяют следующим целям:
a.
Соответствие Эксплуатационным требованиям к инструменту. Цель - подтвердить,
что все Эксплуатационные требования к инструменту переработаны в Требования к
инструменту и что производные требования и причины их введения определены
правильно.
b.
Точность и непротиворечивость. Цель - подтвердить, что каждое из Требований к
инструменту точно сформулировано, имеет однозначное толкование, достаточно
детализировано и что эти требования не противоречат друг другу. Эта цель включает
верификацию того, что выбран соответствующий уровень детализации Требований к
инструменту, обеспечивающий надлежащее воплощение и оценку правильности
инструмента (см. раздел 5.2.1.2,к).
26
Руководство Р-330
c.
Совместимость с эксплуатационной средой инструмента. Цель - подтвердить, что,
если существуют ограничения совместимости с эксплуатационной средой
инструмента, то требования по совместимости определены.
d.
Виды отказов и ошибки. Цель - подтвердить, что Требования к инструменту
определяют поведение инструмента в ответ на ошибочные состояния, а также что
определены специальные требования в части видов отказов и неправильных входных
данных.
e.
Информация для пользователя. Цель - подтвердить, что Требования к инструменту
содержат инструкции пользователя, перечень сообщений об ошибках и ограничения.
f.
ВерисЬицируемость. Цель - подтвердить, что каждое из Требований к инструменту
может быть проверено.
д.
Соответствие стандартам. Цель - подтвердить, что в процессе разработки требований
к инструменту соблюдались положения Стандартов на разработку требований к
инструменту, и что отступления от стандартов обоснованы.
h.
Трассируемость. Цель - подтвердить, что Эксплуатационные
инструменту переработаны в Требования к инструменту.
i.
Алгоритмические аспекты. Цель - подтвердить точность и правильную работу
предложенных алгоритмов, особенно вблизи точек разрыва.
требования
к
6.1.3.2 Рассмотрения и анализы требований низкого уровня к инструменту
Назначением рассмотрений и анализов является обнаружение и регистрация ошибок в
требованиях, которые могли быть внесены в процессе проектирования инструмента. Эти
мероприятия подтверждают, что требования низкого уровня к инструменту достигают
следующих целей:
a.
Соответствие Требованиям к инструменту. Цель - подтвердить, что требования
низкого уровня соответствуют Требованиям к инструменту и что производные
требования низкого уровня к инструменту и основания их появления в проекте
определены правильно.
b.
Точность и непротиворечивость. Цель - подтвердить, что каждое требование низкого
уровня к инструменту точно сформулировано, имеет однозначное толкование и не
противоречит другим требованиям низкого уровня к инструменту.
c.
ВерисЬицируемость. Цель - подтвердить, что каждое требование низкого уровня к
инструменту может быть проверено.
d.
Соответствие стандартам. Цель - подтвердить, что в процессе проектирования
инструмента соблюдались положения применимых стандартов (Стандартов
проектирования инструмента и/или Стандартов на разработку требований к
инструменту, как определено в Плане квалификации инструмента и в Плане
разработки инструмента) и что отступления от стандартов обоснованы.
е.
Трассируемость. Цель - подтвердить, что Требования к инструменту и производные
требования к инструменту переработаны в требования низкого уровня к инструменту.
f.
Алгоритмические аспекты. Цель - подтвердить точность и правильное поведение
предложенных алгоритмов, особенно вблизи точек разрыва.
6.1.3.3 Рассмотрения и анализы архитектуры инструмента
Назначение рассмотрений и анализов - обнаружить ошибки, которые могли быть внесены
в процессе разработки архитектуры инструмента, и зарегистрировать их. Мероприятия
рассмотрений и анализов подтверждают, что архитектура инструмента удовлетворяет
следующим целям:
а.
Совместимость с Требованиями к инструменту. Цель - подтвердить, что архитектура
инструмента не противоречит Требованиям к инструменту.
Руководство Р-330
27
b.
Непротиворечивость. Цель - подтвердить, что между компонентами архитектуры
инструмента установлена правильная взаимосвязь. Эта взаимосвязь реализуется
через поток данных и поток управления.
c.
Соответствие стандартам. Цель - подтвердить, что в процессе проектирования
инструмента соблюдались положения Стандартов проектирования инструмента и что
отступления от стандартов обоснованы.
d.
Защита. Цель - гарантировать, что, если в архитектуре инструмента используется
защитный механизм, то нарушения защиты предотвращены или изолированы. См.
раздел 11.1 для многофункциональных инструментов.
e.
ИнтерсЬейс с внешними компонентами. Цель - гарантировать, что интерфейс между
инструментом и внешними компонентами определен корректно и полностью (см.
раздел 5.2.2.2,д).
6.1.3.4 Рассмотрения и анализы Исходного кода инструмента
Назначением рассмотрений и анализов является обнаружение и регистрация ошибок,
которые могли быть допущены в процессе кодирования инструмента. Эти рассмотрения и
анализы подтверждают, что выходные данные процесса кодирования инструмента точны,
полны и верифицируемы. Основное внимание уделяется правильности кода по отношению к
требованиям низкого уровня к инструменту и архитектуре инструмента, а также соответствию
Стандартам на кодирование инструмента. Эти рассмотрения и анализы ограничиваются
Исходным кодом инструмента; верификация внешних компонентов рассматривается в
разделе 6.1.4.3. Мероприятия рассмотрений и анализов подтверждают, что Исходный код
инструмента достигает следующих целей:
a.
Соответствие требованиям низкого уровня к инструменту. Цель - подтвердить, что
Исходный код инструмента точен и полон по отношению к требованиям низкого уровня
к инструменту и в Исходном коде инструмента не реализовано выполнение
недокументированных функций.
b.
Соответствие архитектуре инструмента. Цель - подтвердить, что Исходный код
инструмента согласуется с данными, определенными в архитектуре инструмента.
c.
ВерисЬицируемость. Цель - подтвердить, что Исходный код инструмента не содержит
операторов и структур, которые не могут быть проверены.
d.
Соответствие стандартам. Цель - подтвердить, что разработка кода велась в
соответствии со Стандартами на кодирование инструмента и что отступления от
стандартов обоснованы.
e.
Трассируемость. Цель - подтвердить, что требования низкого уровня к инструменту
переработаны в Исходный код инструмента.
f.
Точность и непротиворечивость. Цель - оценить правильность и непротиворечивость
Исходного кода инструмента, включая переполнения и разрешающую способность
арифметики с фиксированной запятой, арифметики с плавающей точкой, конкуренцию
и ограничения в использовании ресурсов, обработку исключительных ситуаций,
использование неинициализированных переменных, неиспользуемые переменные
или константы и искажения данных в результате конфликтов задач.
6.1.3.5 Рассмотрения и анализы выходных данных процесса интеграции
инструмента
Назначением рассмотрений и анализов является обнаружение и регистрация ошибок,
которые могли быть допущены в процессе интеграции инструмента. Цель следующая:
а.
Подтвердить, что выходные данные процесса интеграции инструмента являются
полными и корректными.
Мероприятия включают выполнение детальной проверки данных
компоновки. Типовыми примерами потенциальных ошибок являются:
компиляции
и
28
Руководство Р-330
•
предупреждающие сообщения компилятора;
•
потерянные компоненты;
•
неправильный интерфейс с внешними компонентами.
6.1.4 Тестирование инструмента
Процесс тестирования инструмента используется для демонстрации с высокой степенью
достоверности того, что этот инструмент удовлетворяет требованиям к нему и что ошибки,
которые могли бы повлиять на функциональность инструмента, удалены.
6.1.4.1 Цели тестирования инструмента
Целями тестирования инструмента является демонстрация
объектного кода инструмента для подтверждения следующего:
работы
Исполняемого
a.
Исполняемый объектный код инструмента соответствует Требованиям к инструменту.
b.
Исполняемый объектный код инструмента является робастным по отношению к
Требованиям к инструменту.
c.
Исполняемый объектный код инструмента соответствует требованиям низкого уровня
к инструменту.
d.
Исполняемый объектный код инструмента является робастным по отношению к
требованиям низкого уровня к инструменту.
6.1.4.2 Мероприятия тестирования инструмента
Тестированию на основе требований уделяется повышенное внимание, поскольку эта
стратегия считается наиболее эффективной с точки зрения выявления ошибок. Мероприятия
по выбору тестовых примеров на основе требований включают:
a.
b.
Для демонстрации того, что инструмент удовлетворяет требованиям к нему, следует
разработать тестовые примеры и процедуры.
•
Каждый тестовый пример разрабатывается на основании требований (либо
Требований к инструменту, либо требований низкого уровня к инструменту) и
определяет набор входных данных, условий и ожидаемых результатов, а также
критерия проходит/не проходит.
•
Тестовые процедуры формируются из тестовых примеров.
•
Данные трассировки создаются между тестовыми примерами и тестовыми
процедурами.
Должны быть выполнены тесты в допустимом диапазоне, включая следующие:
•
Действительные и целые входные данные следует проверять с использованием
достоверных классов эквивалентности и граничных значений.
•
Для переходов между состояниями должны быть разработаны тестовые примеры
для выполнения переходов, возможных при нормальной работе.
•
Для требований, выраженных логическими уравнениями, или для требований,
которые включают входные логические комбинации, тестовые примеры в
допустимом диапазоне должны проверить использование переменных и
логических операторов. В частности, для уровня квалификации инструментов
TQL-1 тестовые примеры должны продемонстрировать, что каждое условие в
требовании независимо влияет на требуемые выходные данные за счет
изменения только данного условия, при этом все другие возможные условия из
этого требования остаются неизменными.
Руководство Р-330
29
c.
Должны быть выполнены тесты на робастность, чтобы проверить все отказные
состояния (например, ненормальные режимы включения, несовместимые входные
данные и т.п.), определенные в Требованиях к инструменту.
d.
При необходимости следует также разработать дополнительные проверки
робастность, чтобы продемонстрировать:
•
способность инструмента реагировать на ненормальные входные данные или
условия;
•
обнаружение ненормального поведения;
•
предотвращение выдачи неправильных выходных данных.
Примечание.
e.
на
Тестовые примеры проверки на робастность основаны на требованиях.
Критерии тестов на робастность не могут быть полностью
удовлетворены, если в требованиях к инструменту не указана
корректная реакция на ненормальные состояния и входные данные.
Тестовые примеры могут выявить неполноту в требованиях к
инструменту, в таких случаях требования к инструменту должны
быть изменены. Наоборот, если существует полный набор требований,
который покрывает все ненормальные состояния и входные данные,
тестовые примеры на робастность будут следовать из этих
требований к инструменту.
Чтобы продемонстрировать, что были проверены все требования (Требования к
инструменту и требования низкого уровня к инструменту), должен быть выполнен
анализ покрытия требований тестами. Этот анализ гарантирует, что для каждого
требования имеется по крайней мере один тестовый пример и что были выполнены
надлежащие проверки в допустимом диапазоне и проверки на робастность.
6.1.4.3 Анализ тестирования на основании требований
6.1.4.3.1 Цели
Цель настоящего анализа с соответствующим решением - предоставить свидетельство
того, что структура кода инструмента была проверена до степени, требуемой для
применимого уровня квалификации инструмента, а также обеспечить доверие,
соответствующее конкретному уровню квалификации инструментов, при отсутствии
незаданной функциональности.
Типичным средством для этого является использование анализа структурного покрытия.
Этот анализ может обнаружить структуру кода, которая не была выполнена во время
тестирования.
Некоторые компоненты инструмента могут находиться вне непосредственного контроля
разработчика инструмента, такие как функции операционной системы или связанное
промежуточное ПО (компоненты интерфейса между операционной системой и приложением).
Обычно этот тип компонентов поддерживает работоспособность инструмента в пределах
эксплуатационной среды. Для функций внешних компонентов, используемых инструментом,
проверки должны включать такие, которые обращаются к интерфейсу и функциональности
каждой из этих функций, как определено в Описании проекта инструмента (см. раздел
5.2.2.2,д).
. Однако следующие компоненты обычно находятся
инструмента и требуют анализа структурного покрытия:
под
контролем
разработчика
•
компоненты, разработанные для ограниченного использования или специально для
поддержки инструмента;
•
библиотеки функций, которые используются в работе инструмента (например, код,
который реализует базовые элементы модели).
Руководство Р-330
30
Библиотеки, используемые или встраиваемые в выходные данные инструмента, которые
становятся частью конечного ПО, следует проверять в мероприятии, отдельном от
квалификации инструмента (например, как часть процесса ЖЦ ПО).
6.1.4.3.2 Анализ
Мероприятия для анализа тестирования на основании требований включают:
a.
Для компонентов, находящихся под контролем разработчика инструмента, анализ
должен определить, какая структура кода, включая интерфейсы между компонентами,
не была выполнена тестовыми процедурами на основании требований. Для уровня
квалификации инструментов TQL-3 требуемым уровнем является покрытие
операторов, для уровня квалификации инструментов TQL-2 требуемым уровнем
является покрытие решений и для уровней квалификации инструментов TQL-1
требуемым уровнем является Модифицированное покрытие условий и решений. Как
и для достижения любой другой цели, Заявитель может предложить альтернативные
средства (см. раздел 11.5).
b.
Для компонентов, которые не находятся под прямым контролем разработчика
инструмента (например, функция операционной системы или внешняя библиотека
ПО), требуется дополнительный анализ, чтобы гарантировать полноту тестирования
на 'основании требований. Этот анализ должен гарантировать, что тестами
проверяется интерфейс и функциональность каждой функции внешних компонентов,
используемых инструментом.
c.
Анализ должен подтвердить, что тестированием на основе требований проверяется
связность по данным и связность по управлению между компонентами кода
инструмента.
6.1.4.3.3 Устранение недостатков
Анализ структурного покрытия может обнаружить структуры кода, включая интерфейсы,
которые не были выполнены во время тестирования. Устранение недостатков потребует
дополнительных мероприятий процесса верификации ПО. Причины непокрытой структуры
кода, включая интерфейсы, и соответствующие мероприятия для их устранения включают:
a.
Недостатки в тестовых примерах или процедурах, основанных на требованиях. Для
достижения полноты покрытия должны быть дополнены тестовые примеры или
изменены тестовые процедуры. Может потребоваться пересмотр метода (методов),
используемого для анализа покрытия на основе требований.
b.
Недостаточность в требованиях. Должны быть изменены требования, разработаны
дополнительные тестовые примеры и выполнены дополнительные тестовые
процедуры.
c.
Мертвый код. Этот код должен быть удален или должно быть подтверждено анализом
отсутствие влияния мертвого кода на функциональность инструмента.
d.
Отключенный код и неиспользуемая функция. В этом случае невыполняемый
Исходный код инструмента должен быть либо удален, либо обоснован. Назначение
такого обоснования - предоставить свидетельство того, что Исходный код
инструмента не влияет на выходные данные инструмента при любом режиме
эксплуатации.
6.1.4.4 Рассмотрения и анализы тестовых примеров, процедур и результатов
Назначением рассмотрений и анализов является подтверждение того, что тестирование
кода было подготовлено и выполнено точно и полностью. Мероприятия рассмотрений и
анализов подтверждают, что тестирование инструмента достигает следующих целей:
а.
Тестовые примеры. Цель - обеспечить, чтобы было достигнуто покрытие всех
требований (соответствующие мероприятия см. в разделе 6.1.4.2,е).
Руководство Р-330
31
b.
Тестовые процедуры. Цель - проверить, что тестовые примеры, включая ожидаемые
результаты, были правильно переработаны в тестовые процедуры.
c.
Тестовые результаты. Цель - подтвердить, что результаты тестирования корректны и
что расхождения между фактическими и ожидаемыми результатами объяснены.
6.1.5 Трассируемость процесса верификации инструмента
Мероприятия по обеспечению трассируемости процесса верификации инструмента
включают:
a.
Разработка Данных трассировки для демонстрации двунаправленной связи между
Требованиями к инструменту и соответствующими им тестовыми примерами, а также
между требованиями низкого уровня к инструменту и соответствующими им
тестовыми примерами. Назначение таких Данных трассировки - обеспечить анализ
полноты покрытия требований тестами.
b.
Разработка Данных трассировки для демонстрации двунаправленной связи между
тестовыми примерами и тестовыми процедурами. Назначение таких Данных
трассировки - обеспечить верификацию того, что полный набор тестовых примеров
переработан в тестовые процедуры.
c.
Разработка Данных трассировки для демонстрации двунаправленной связи между
тестовыми процедурами и результатами. Назначение таких Данных трассировки обеспечить верификацию того, что выполнен полный набор тестовых процедур.
6.2 Процесс эксплуатационной верификации и валидации инструмента
Процесс эксплуатационной верификации и валидации инструмента применяется так, как
определено процессом планирования инструмента. В части «Эксплуатационная верификация
и валидация инструмента» таблицы Т-0 Приложения А приведена сводка целей и выходных
данных процесса эксплуатационной верификации и валидации инструмента по уровням
квалификации инструментов.
6.2.1 Цели процесса эксплуатационной верификации и валидации инструмента
Назначением процесса эксплуатационной верификации и валидации инструмента
является обеспечение уверенности в том, что выходные данные и функциональность
инструмента соответствуют потребностям процесса ЖЦ ПО. Это мероприятие включает как
верификацию, так и валидацию.
Цели верификации процесса эксплуатационной верификации и валидации инструмента
включают обнаружение и регистрацию ошибок, которые могли быть внесены в процессах
разработки инструмента. Устранение ошибок - это мероприятие процессов разработки
инструмента. Целями верификации являются:
a.
Эксплуатационные требования к инструменту
проверяемыми и непротиворечивыми.
b.
Функциональность
и
выходные
данные
эксплуатационную
среду
инструмента,
требованиям к инструменту.
являются
инструмента,
соответствуют
полными,
точными,
установленного
в
Эксплуатационным
Целями валидации процесса эксплуатационной верификации и валидации инструмента
является анализ функциональности и выходных данных инструмента на предмет
правильности и полноты в отношении к выполняемым мероприятиям ЖЦ ПО. Целями
валидации являются:
аа. Гарантировать, что Эксплуатационные требования к инструменту достаточны и
корректны, чтобы исключить, упростить или автоматизировать процесс(ы),
определенные в Плане сертификации ПО.
bb. Гарантировать, что инструмент удовлетворяет потребностям процесса ЖЦ ПО в
эксплуатационной среде инструмента.
32
Руководство Р-330
6.2.2 Мероприятия процесса эксплуатационной верификации и валидации
инструмента
Цели эксплуатационной верификации и валидации достигаются посредством комбинации
рассмотрений, анализов и тестов. Рассмотрения, анализы и разработка тестовых примеров
обеспечивают оценку внутренней непротиворечивости и полноты Эксплуатационных
требований к инструменту. Выполнение тестовых процедур позволяет продемонстрировать
соответствие Исполняемого объектного кода инструмента Эксплуатационным требованиям к
инструменту и совместимость с эксплуатационной средой инструмента.
Интеграция инструмента в эксплуатационную среду инструмента должна обеспечить
демонстрацию правильности и полноты Эксплуатационных требований к инструменту.
Входные данные процесса эксплуатационной верификации и валидации включают
Эксплуатационные требования к инструменту, Исполняемый объектный код инструмента и
План верификации инструмента.
Выходными данными процесса эксплуатационной верификации и валидации являются
Примеры и Процедуры эксплуатационной верификации инструмента (см. раздел 10.3.3) и
Результаты эксплуатационной верификации и валидации инструмента (см. раздел 10.3.4).
Мероприятия по эксплуатационной верификации и валидации инструмента включают:
а.
Верификация Эксплуатационных требований к инструменту. Должны быть выполнены
рассмотрения и анализы Эксплуатационных требований к инструменту, чтобы
гарантировать, что:
1)
каждое требование является точным, однозначным, полным и непротиворечивым;
2)
определены требования совместимости эксплуатационной среды инструмента;
3)
определены ожидаемые реакции инструмента в ненормальных условиях работы,
таких как ненормальные режимы включения и несовместимые входные данные.
Ь-
Идентификация и демонстрация соответствующего проиесса(ов). Эксплуатационные
требования к инструменту должны продемонстрировать покрытие процесса(ов),
которые предназначены для исключения, упрощения или автоматизации за счет
использования инструмента.
с.
Верификация и валидация в эксплуатационной среде инструмента. Инструмент,
установленный в эксплуатационной среде, соответствует потребности процессов ЖЦ
ПО. Это мероприятие представляет собой как верификацию соответствия
Исполняемого объектного кода инструмента Эксплуатационным требованиям к
инструменту, так и валидацию Эксплуатационных требований к инструменту.
Мероприятия следующие:
1.
Должны быть разработаны тестовые примеры и процедуры для подтверждения,
что инструмент удовлетворяет Эксплуатационным требованиям к инструменту.
Эти тестовые примеры и процедуры должны основываться на требованиях.
2.
Тестовые процедуры должны быть выполнены после установки Исполняемого
объектного кода инструмента в эксплуатационной среде инструмента.
3.
Должно быть проведено рассмотрение результатов тестов, чтобы удостовериться,
что они корректны и что расхождения между действительными и ожидаемыми
результатами объяснены.
4.
В процессе валидации Эксплуатационных требований к инструменту инструмент
должен быть опробован. Выбранный набор входных данных должен представлять
реальное использование инструмента и его интерфейсы в эксплуатационной
среде инструмента. Эта валидация должна подтвердить, что Эксплуатационные
требования к инструменту корректны и полны.
Руководство Р-330
7.0
33
ПРОЦЕСС УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ ИНСТРУМЕНТА
В настоящем разделе рассматриваются цели и мероприятия процесса управления
конфигурацией инструмента (УК инструмента). Процесс УК инструмента осуществляется так,
как определено в процессе планирования инструмента (см. раздел 4) и в Плане управления
конфигурацией инструмента (см. раздел 10.1.5). Выходные данные процесса УК инструмента
сохраняются в Записях управления конфигурацией инструмента (см. раздел 10.1.13) или в
других данных ЖЦ инструмента.
Процесс УК инструмента, работая совместно с другими процессами ЖЦ инструмента,
содействует в:
a.
Обеспечении определенной и управляемой конфигурации инструмента в течение ЖЦ
инструмента.
b.
Обеспечении возможности корректного тиражирования Исполняемого объектного
кода инструмента или повторного его получения при необходимости исследования
или изменения.
c.
Обеспечении управления входными и выходными данными процессов в течение ЖЦ
инструмента, что гарантирует согласованность и повторяемость мероприятий
процессов.
d.
Обеспечении известной точки для рассмотрения, оценки состояния и управления
изменениями посредством контроля единиц конфигурации и установления базовых
версий.
e.
Обеспечении
принимаются
реализованы.
f.
Обеспечении свидетельства одобрения инструмента посредством контроля выходных
данных процессов ЖЦ инструмента.
д.
Оценке соответствия поставочного комплекта инструмента требованиям.
h.
Гарантировании того, что для единиц конфигурации обеспечивается надежное
физическое хранение, восстановление и управление.
процедур управления,
которые гарантируют, что проблемы
во внимание, а изменения зарегистрированы, утверждены и
7.1 Цели процесса управления конфигурацией инструмента
Цели процесса УК инструмента следующие:
a.
Каждая единица конфигурации и ее последовательные версии помечаются
однозначным образом, чтобы сформировать основу для контроля и ссылок на
единицы конфигурации.
b.
Базовые версии определены для последующих мероприятий процессов ЖЦ
инструмента и позволяют ссылаться на единицы конфигурации, управлять ими и
трассировать их друг на друга.
c.
Процесс регистрации проблем фиксирует несоответствия процессов планам и
стандартам создания инструмента, фиксирует недостатки выходных данных
процессов ЖЦ инструмента, фиксирует ненормальное поведение поставочных
комплектов инструментов и гарантирует решение этих проблем.
<± Управление изменениями обеспечивает регистрацию, оценку, решение и утверждение
изменений в течение ЖЦ инструмента.
е.
Рассмотрение изменений гарантирует, что проблемы и изменения оценены, проблемы
и изменения одобрены или не одобрены, утвержденные изменения реализованы, и
обратная связь предоставлена связанным процессам через сообщения о проблеме и
методы контроля изменений, определенные в процессе планирования инструмента.
34
Руководство Р-330
f.
Система учета состояния предоставляет данные для управления конфигурацией
инструмента в процессах ЖЦ с учетом идентификации конфигурации, базовых версий,
сообщений о проблемах и управления изменениями.
д.
Хранение и воспроизведение гарантируют, что связанные с поставочным комплектом
инструмента данные ЖЦ инструмента можно воспроизвести в случае необходимости
дублирования, повторного получения, повторного тестирования или изменения
поставочного комплекта инструмента. Цель мероприятия выпуска - гарантировать,
что в процессах ЖЦ ПО используется только разрешенный инструмент, в дополнение
к этому обеспечено его хранение и воспроизведение.
h.
Контроль среды ЖЦ инструмента гарантирует, что другие инструменты, используемые
для изготовления самого инструмента, идентифицируемы, контролируемы и
воспроизводимы.
Цели процесса УК инструмента не зависят от уровня квалификации инструмента. Однако
могут существовать две категории данных ЖЦ инструмента, основанные на применяемых
видах контроля УК инструмента к этим данным (см. раздел 7.3).
В таблице Т-8 Приложения А представлена сводка целей и выходных данных процесса УК
инструмента по уровням квалификации инструмента.
7.2 Мероприятия процесса управления конфигурацией инструмента
Процесс УК инструмента включает мероприятия по идентификации конфигурации,
управлению изменениями, установлению базовых версий и хранению поставочного комплекта
инструмента вместе с относящимися к нему данными ЖЦ инструмента. После утверждения
поставочного комплекта инструмента Сертифицирующим органом процесс УК инструмента не
завершается, а продолжается в течение всего срока эксплуатации системы или оборудования
с итоговым ПО. Если мероприятия ЖЦ инструмента будут выполняться поставщиком, тогда
мероприятия по управлению конфигурацией должны применяться к поставщику.
7.2.1 Идентификация конфигурации
Мероприятия включают:
a.
Должна быть введена идентификация конфигурации для данных ЖЦ инструмента.
b.
Должна быть введена идентификация конфигурации для каждой единицы
конфигурации, для каждого отдельно контролируемого компонента единицы
конфигурации и для комбинаций единиц конфигурации, образующих поставочный
комплект инструмента.
c.
Единицы конфигурации должны быть идентифицированы в составе конфигурации до
реализации управления изменениями и анализа трассируемости.
d.
Единица конфигурации должна быть идентифицирована до того, как эта единица
используется другими процессами ЖЦ инструмента или на нее ссылаются другие
данные ЖЦ.
7.2.2 Базовые версии и трассируемость
Мероприятия включают:
a.
Должны быть установлены базовые версии для единиц конфигурации, используемых
для
получения
сертификационного
зачета.
(Для
поддержки
управления
мероприятиями ЖЦ инструмента должны быть созданы промежуточные базовые
версии.)
b.
Должна быть установлена базовая версия поставочного комплекта инструмента и
обозначена в Указателе конфигурации инструмента (см. раздел 10.1.11).
Руководство Р-330
35
c.
Базовые версии должны быть установлены в контролируемых библиотеках ПО (на
физических, электронных или других носителях) для гарантии их целостности. Как
только базовая версия установлена, она должна быть защищена от изменений.
d.
Производная базовая версия должна быть разработана на основе установленной
базовой версии в соответствии с мероприятиями управления изменениями.
e.
Если требуется получить сертификационный зачет для мероприятий ЖЦ инструмента
или данных, связанных с развитием предыдущей базовой версии, должна быть
обеспечена трассируемость текущей базовой версии к базовой версии, из которой она
была получена.
f.
Если требуется получить сертификационный зачет для мероприятий ЖЦ инструмента
или данных, связанных с развитием предыдущей единицы конфигурации, должна быть
обеспечена трассируемость единицы конфигурации к той единице конфигурации, из
которой она была получена.
д.
Должна быть обеспечена трассируемость базовой версии или единицы конфигурации
либо на выходные данные, которые она определяет, либо на процесс, с которым она
связана.
7.2.3 Регистрация проблем, отслеживание и корректирующие действия
Мероприятия включают:
a.
Должно быть подготовлено сообщение о проблеме инструмента, которое описывает
несоответствие процесса планам, дефект выходных данных или ненормальное
поведение инструмента, а также предпринятые корректирующие действия, как это
определено в разделе 10.1.12.
Примечание.
Может быть использована отдельная система регистрации проблем.
Например, обнаруженные ошибки в процессе эксплуатационной
верификации и валидации инструмента могут быть записаны в другой
системе регистрации проблем, чем та, в которой были обнаружены
ошибки в процессе верификации инструмента.
b.
Регистрация проблем должна предусматривать идентификацию конфигурации
затронутой единицы (единиц) конфигурации или указание затронутых мероприятий
процесса, регистрацию состояния сообщений о проблемах инструмента, а также
утверждение или
c.
Сообщения о проблемах инструмента, которые требуют корректирующих действий в
отношении поставочного комплекта инструмента или выходных данных процессов ЖЦ
инструмента, должны инициировать мероприятия по управлению изменениями.
7.2.4 Управление изменениями
Мероприятия включают:
a.
Управление изменениями должно сохранять целостность единиц конфигурации и
базовых версий посредством защиты их от изменений.
b.
Управление изменениями должно гарантировать, что любое изменение в единице
конфигурации повлечет изменение ее идентификации.
c.
Изменения в находящихся под управлением изменениями базовых версиях и
единицах конфигурации для создания производных базовых версий необходимо
регистрировать, утверждать и отслеживать. Регистрация проблем связана с
управлением изменениями, поскольку решение по зарегистрированной проблеме
может привести к изменениям единиц конфигурации или базовых версий.
Примечание.
Общепризнанно, что ранняя реализация управления изменениями
улучшает контроль и управление мероприятиями ЖЦ инструмента.
36
Руководство Р-330
d.
Изменения инструмента должны трассироваться до их источников, а процессы ЖЦ
инструмента должны повторяться начиная с той точки, в которой изменение начинает
влиять на выходные данные этих процессов. Например, ошибка, оказавшаяся
результатом неправильного проектирования, потребует коррекции проекта и кода, а
также повторения соответствующих мероприятий интегральных процессов.
e.
В ходе мероприятий по внесению изменений данные ЖЦ инструмента, затрагиваемые
этими изменениями, должны обновляться, а записи должны сохраняться в ходе
мероприятия управления изменениями.
Мероприятия управления изменениями поддерживаются мероприятиями рассмотрения
изменений.
7.2.5 Рассмотрение изменений
Мероприятия включают:
a.
Подтверждение того, что все затронутые единицы кофигурации идентифицированы.
b.
Оценка влияния изменения на Эксплуатационные требования к инструменту.
c.
Оценка соответствия проблемы или изменения решениям по предпринимаемым
действиям.
d.
Обеспечение обратной связи от Сообщений о проблемах или влияния изменения и
принятых решений относительно затронутых процессов.
e.
Оценка обратной связи от процессов создания ПО на проблемы инструмента и
предложенные изменения идентифицированные в процессе инструмента.
7.2.6 Учет состояния конфигурации
Мероприятия включают:
a.
Предоставление отчетов по идентификации единиц конфигурации, идентификации
базовых версий, состояниям Сообщений о проблемах, истории изменений и
состоянию релиза.
b.
Определение данных и средств регистрации и предоставление отчетов о состоянии
этих данных.
7.2.7 Хранение, воспроизведение и выпуск
Мероприятия включают:
a.
Должна быть обеспечена возможность воспроизведения данных ЖЦ инструмента,
связанных с поставочным комплектом инструмента, из разрешенного источника
(например, из архива в разрабатывающей организации или компании).
b.
Должны быть установлены процедуры, гарантирующие целостность хранимых данных
(вне зависимости от носителя) посредством:
1)
гарантии невозможности внесения несанкционированных изменений;
2)
выбора для хранения носителя, минимизирующего ошибки или искажения при
перезаписи;
3)
предотвращение потери или искажения данных со временем. В зависимости от
носителя для хранения данных это может включать периодическую контрольную
проверку носителя или обновления архивных данных;
4)
хранения копий-дубликатов в физически отдельных архивах для минимизации
риска их утраты в случае стихийного бедствия.
Руководство Р-330
37
c.
Процесс получения дубликатов должен быть верифицирован на предмет создания
точных копий, а также должны существовать процедуры, гарантирующие
безошибочное копирование Исполняемого объектного кода инструмента.
d.
Единицы конфигурации должны быть идентифицированы
использования в рамках процессов ЖЦ ПО.
e.
Должны быть установлены
модификацию инструмента.
Примечание.
и выпущены до их
процедуры сохранения данных, чтобы обеспечить
Дополнительные соображения, связанные с сохранением данных, могут
учитывать коммерческие нужды и будущие экспертизы, проводимые
сертифицирующим органом, но эти соображения выходят за рамки
данного документа.
7.3 Категории контроля данных
Данные ЖЦ инструмента могут быть отнесены к одной из двух категорий: 1-й категории
контроля (КК1) и 2-й категории контроля (КК2). Эти категории связаны с мероприятиями
управления конфигурацией, применяемых в отношении данных. В таблице 7-1 определена
группа мероприятий процесса управления конфигурацией инструмента, связанная с каждой
из категорий контроля, где символ « •» указывает, что эти мероприятия применяются к
данным ЖЦ инструмента конкретной категории. Мероприятия КК2 представляют собой
подгруппу мероприятий КК1.
В таблицах Приложения А представлены категории контроля для каждой единицы данных
ЖЦ инструмента по уровням квалификации инструментов. Инструктивные материалы по
категориям контроля данных включают:
a. Мероприятия процесса управления конфигурацией инструмента для данных ЖЦ
инструмента, отнесенные к КК1, должны применяться в соответствии с таблицей 7-1.
b . Мероприятия процесса управления конфигурацией инструмента для данных ЖЦ
инструмента, отнесенные к КК2, должны применяться в соответствии с таблицей 7-1, как
минимум.
7.4 Управление средой жизненного цикла инструмента
Среда ЖЦ инструмента определяется процессом планирования инструмента и
идентифицируется в Указатель конфигурации среды ЖЦ инструмента (см. раздел 10.1.10).
Мероприятия включают следующее:
a.
Должна быть задана идентификация конфигурации Исполняемого объектного кода
(или его эквивалента) для инструментов, используемых для разработки, контроля,
сборки, и верификации поставочного комплекта инструмента и его данных.
b.
Процесс управления конфигурацией инструментов, используемых для создания
Исполняемого объектного кода инструмента (или его эквивалента) (например,
компиляторов, ассемблеров, компоновщиков), должен соответствовать целям,
связанным сданными КК2, как минимум.
38
Руководство Р-330
Таблица 7-1. Мероприятия процесса УК инструмента, назначенные данным категорий
КК1 и КК2
Мероприятия процесса УК инструмента
Ссылка
КК1
КК2
Идентификация конфигурации
7.2.1
•
•
Базовая версия
7.2.2,а
7.2.2,b
7.2.2,с
7.2.2,d
7.2.2,е
•
Трассируемость
7.2.2,f
7.2.2,g
•
Регистрация проблем
7.2.3
•
Управление изменениями - целостность
и идентификация
7.2.4,а
7.2.4,Ь
•
Управление изменениями - отслеживание
7.2.4,С
7.2.4,d
7.2.4,е
•
Рассмотрение изменений
7.2.5
•
Учет состояния конфигурации
7.2.6
•
Воспроизведение
7.2.7,а
•
•
Защита от несанкционированных изменений
7.2.7,Ь,1
•
•
Выбор физического носителя, обновление,
дублирование
7.2.7,Ь,2
7.2.7,Ь,3
7.2.7,Ь,4
7.2.7,с
•
Выпуск
7.2.7,d
•
Сохранение данных
7.2.7,е
•
•
•
•
Руководство Р-330
8.0
39
ПРОЦЕСС ГАРАНТИИ КАЧЕСТВА ИНСТРУМЕНТА
В настоящем разделе рассматриваются цели и мероприятия процесса гарантии качества
инструмента (ГК инструмента). Процесс ГК инструмента применяется так, как определено в
процессе планирования инструмента (см. раздел 4) и в Плане ГК инструмента (см.
раздел 10.1.6). Выходные данные мероприятий процесса ГК инструмента сохраняются в
Записях ГК инструмента (см. раздел 10.1.14) или в других данных ЖЦ инструмента.
Процесс ГК инструмента оценивает процессы ЖЦ инструмента и их выходные данные с
целью получения гарантии того, что:
a)
цели достигнуты;
b)
недостатки выявляются, оцениваются, прослеживаются и устраняются;
c)
поставочный комплект инструмента и данные ЖЦ инструмента соответствуют
настоящему документу и дополнительным обязательным требованиям, если таковые
имеются.
8.1 Цели процесса гарантии качества инструмента
Цели процесса ГК инструмента - обеспечить уверенность в том, что процессы ЖЦ
инструмента создают инструмент, удовлетворяющий предъявляемым к нему требованиям за
счет гарантии того, что упомянутые процессы выполняются в соответствии с утвержденными
планами и стандартами создания инструмента.
Целями процесса ГК инструмента являются:
a.
Получение гарантии того, что планы и стандарты
разрабатываются и пересматриваются на согласованность.
создания
инструмента
b.
Получение гарантии того, что процессы разработки инструмента и интегральные
процессы, включая выполняемые поставщиками, соответствуют утвержденным
планам и стандартам создания инструмента.
c.
Получение гарантии того, что удовлетворяются критерии перехода для процессов ЖЦ
инструмента.
d.
Выполнение рассмотрений соответствия поставочного комплекта инструмента.
Применимость этих целей по уровням квалификации инструментов (TQL) указывается в
таблице Т-9 Приложения А.
8.2 Мероприятия процесса гарантии качества инструмента
Мероприятия для достижения целей процесса ГК инструмента включают:
a.
Те, кто выполняет процесс ГК инструмента, должны играть активную роль в
мероприятиях процессов ЖЦ инструмента и иметь полномочия, ответственность и
независимость, чтобы гарантировать достижение целей этого процесса.
b.
Процесс ГК инструмента должен гарантировать, что планы и стандарты создания
инструмента составляются и рассматриваются на согласованность.
c.
Процесс ГК инструмента должен гарантировать, что процессы ЖЦ инструмента
соответствуют утвержденным планам и стандартам создания инструмента.
d.
Процесс ГК инструмента должен включать аудиты процесса разработки и
интегральных процессов в течение ЖЦ инструмента, чтобы получить гарантию того,
что:
1)
планы создания инструмента доступны, как указано в разделе 4;
2)
отклонения от планов и стандартов создания инструмента
зарегистрированы, оценены, прослежены и по ним принято решение;
выявлены,
Руководство Р-330
40
Примечание.
Общепризнанно, что раннее выявление отклонений в процессах
способствует успешному достижению целей процессов ЖЦ
инструмента.
3)
утвержденные отклонения зарегистрированы;
4)
среда разработки инструмента соответствует указанной в планах создания
инструмента;
5)
процесс регистрации и отслеживания проблем, а также корректирующие действия
соответствуют Плану управления конфигурацией инструмента.
Примечание.
Для обеспечения гарантии того,
что мероприятия Ж Ц
инструмента находятся под контролем, они могут подвергаться
мониторингу.
e.
Процесс ГК инструмента должен гарантировать, что критерии перехода для процессов
ЖЦ инструмента были удовлетворены в соответствии с утвержденными планами
создания инструмента.
f.
Процесс ГК инструмента должен гарантировать, что данные ЖЦ инструмента
управляются в соответствии с категориями контроля, как это определено в разделе
7.3 и в таблицах Приложения А.
д.
Перед поставкой поставочного комплекта инструмента, который предназначен для
использования итоговым ПО, предоставляемым как часть сертификационной заявки,
должно быть выполнено рассмотрение соответствия инструмента.
h.
Процесс ГК инструмента должен оставлять записи о мероприятиях процесса ГК
поставочного комплекта инструмента (раздел 10.1.14), включающие результаты
аудитов и свидетельства завершения рассмотрения соответствия требованиям для
каждого поставочного комплекта инструмента.
i.
Процесс ГК инструмента должен гарантировать, что любые процессы и выходные
данные поставщика соответствуют утвержденным планам и стандартам создания
инструмента.
8.3 Рассмотрение соответствия инструмента
Назначением рассмотрения соответствия инструмента является получение гарантий для
поставочного комплекта инструмента, что процессы ЖЦ инструмента завершены, данные ЖЦ
инструмента полны, Исполняемый объектный код инструмента контролируется и может быть
получен повторно.
Рассмотрение соответствия инструмента может быть дополнено или выполнено в
контексте рассмотрения соответствия ПО.
Это рассмотрение должно установить, что:
a.
Запланированные мероприятия процессов ЖЦ инструмента, включая создание
данных ЖЦ инструмента, завершены и записи об их завершении имеются.
b.
Существует подтверждение того, что данные ЖЦ инструмента получены в
соответствии с планами и стандартами создания инструмента и находятся под
контролем в соответствии с Планом управления конфигурацией инструмента.
c.
Существуют свидетельства того, что Сообщения о проблемах инструмента были
оценены и зарегистрированы.
d.
Отступления от требований к инструменту зарегистрированы и утверждены.
е.
Исполняемый объектный код инструмента может быть повторно получен из хранимого
Исходного кода инструмента.
Руководство Р-330
41
f.
Сообщения о проблемах инструмента, отложенные по результатам предыдущих
рассмотрений соответствия инструмента, оценены повторно для определения их
состояния.
д.
Если
запрашивается
сертификационный
зачет
на
использование
ранее
разработанных инструментов, то текущая базовая версия поставочного комплекта
инструмента трассируема на предыдущую базовую версию и к утвержденным
изменениям той базовой версии.
Примечание.
Для изменений, вносимых после квалификации, может выполняться
часть мероприятий рассмотрения соответствия инструмента
причем их набор обусловлен значимостью изменений.
Руководство Р-330
42
9.0
ПРОЦЕСС ВЗАИМОДЕЙСТВИЯ С СЕРТИФИЦИРУЮЩИМ ОРГАНОМ
ДЛЯ КВАЛИФИКАЦИИ ИНСТРУМЕНТА
Процесс взаимодействия с Сертифицирующим органом для квалификации инструмента
не выполняется обособленно, но в рамках процесса взаимодействия с Сертифицирующим
органом для сертификации (или его эквивалентом, в зависимости от конкретной области) ПО.
В настоящем разделе определяются аспекты квалификации инструмента в рамках этого
процесса.
Для квалификации инструмента требуется взаимодействие с Сертифицирующим органом.
План сертификации ПО определяет необходимость квалификации инструмента в
соответствии с конкретным использованием данного инструмента в процессе ЖЦ ПО.
Если План сертификации ПО, разработанный в процессе ЖЦ ПО, определяет, что
требуется квалификация одного или нескольких инструментов, процесс взаимодействия с
Сертифицирующим органом включает следующие мероприятия:
a.
Основными
входными
данными,
представляемыми
на
рассмотрение
сертифицирующему органу, является План сертификации ПО, содержащий
информацию о квалификации инструментов. Минимальный состав представляемых
сертифицирующему органу данных включает:
•
План сертификации ПО;
•
План квалификации инструмента;
•
Указатель конфигурации инструмента;
•
Итоговое заключение об инструменте;
•
Указатель конфигурации среды ЖЦ ПО;
•
Итоговое заключение о ПО.
Для уровня квалификации инструмента TQL-5 План квалификации инструмента,
Указатель конфигурации инструмента и Итоговое заключение об инструменте не требуются.
По запросу Сертифицирующего органа могут быть представлены другие данные или
свидетельства, подтверждающие соответствие из ЖЦ инструмента. Для рассмотрения
Сертифицирующим органом должны быть доступны все данные.
b.
Для
согласования
методов
подтверждения
соответствия
требованиям
сертифицирующему органу должны быть представлены как План сертификации ПО,
так и План квалификации инструмента.
c.
Как свидетельство того, что процессы ЖЦ инструмента соответствуют планам, данные
ЖЦ инструмента должны быть доступны сертифицирующему органу для
рассмотрения.
d.
Все известные проблемы и функциональные ограничения должны быть
проанализированы с точки зрения ЖЦ ПО и отчет должен быть включен в Итоговое
заключение о ПО. Должно быть определено и проанализировано влияние на
инструмент известных проблем и функциональных ограничений инструмента, чтобы
убедиться, что функциональность и выходные данные инструмента соответствуют
Эксплуатационным требованиям к инструменту.
e.
В Указателе конфигурации среды ЖЦ ПО должна быть обеспечена идентификация
всех инструментов, используемых в рамках применимого выпуска ПО. Для уровня
квалификации инструментов TQL-5 следует также включить ссылки на данные
квалификации инструментов (Эксплуатационные требования к инструменту и данные
эксплуатационной верификации и валидации). Для остальных уровней квалификации
инструментов (TQL) Указатель конфигурации среды ЖЦ ПО должен ссылаться на
Указатель конфигурации инструмента.
Руководство Р-330
43
10.0 ДАННЫЕ КВАЛИФИКАЦИИ ИНСТРУМЕНТА
Состав данных квалификации инструмента определяется по усмотрению Заявителя.
Например, единицы данных могут комбинироваться в общий документ или делиться на
несколько документов.
В настоящем разделе представлены инструктивные материалы по типовым данным ЖЦ
квалификации инструмента и минимальному содержанию каждой единицы данных.
Настоящий раздел разделен на три подраздела, относящиеся к данным ЖЦ квалификации
инструмента:
•
данные процесса взаимодействия с Сертифицирующим органом для квалификации
инструмента и других интегральных процессов (см. раздел 10.1);
•
данные квалификации инструмента, производимые в процессе разработки
инструмента и соответствующих мероприятий верификации (см. раздел 10.2);
•
данные квалификации инструмента, производимые в процессе разработки
Эксплуатационных требований к инструменту и в процессе эксплуатационной
интеграции инструмента, а также соответствующих мероприятий верификации и
валидации (см. раздел 10.3).
10.1 Данные процесса взаимодействия с Сертифицирующим органом
для квалификации инструмента и других интегральных процессов
10.1.1
Информация относительно инструмента в Плане сертификации ПО
План сертификации ПО должен включать следующую информацию о необходимости
квалификации инструмента:
a.
Идентификация инструмента и его назначения, включая его влияние на процесс ЖЦ
ПО.
b.
Детальная информация о сертификационном зачете, который предполагается
получить за счет использования инструмента для исключения, упрощения и
автоматизации процесса(ов).
c.
Обоснование зрелости и технических предпосылок любой технологии или теории
(например, математической теории), воплощаемой в инструменте для демонстрации
его применимости.
d.
Предлагаемый для инструмента уровень квалификации инструмента и обоснование
этого уровня.
e.
Источник инструмента
(например,
создаваемый
коммерческий, создаваемый третьей стороной).
f.
Заинтересованные стороны, вовлеченные в квалификацию инструмента, и
конкретные их роли и ответственности, включая определение того, кто отвечает за
достижение конкретных целей.
д.
Описание процесса определения Эксплуатационных требований к инструменту
(см. раздел 5.1), процесса эксплуатационной интеграции инструмента (см. раздел 5.3)
и процесса эксплуатационной верификации и валидации инструмента (см. раздел 6.2)
(или ссылки на то место, где эти процессы будут описаны).
h.
Описание эксплуатационной среды
использоваться.
i.
Если данные квалификации инструмента используются повторно, необходимо указать
предыдущие применения инструмента, стратегию и обоснование повторного
использования и любые применимые мероприятия по повторной квалификации.
В случае инструмента, создаваемого третьей стороной или покупного готового
инструмента, информация о предыдущем применении может быть предоставлена
своими
инструмента, в которой
силами,
готовый
инструмент будет
44
Руководство Р-330
поставщиком, поскольку ее может быть невозможно получить от пользователей
инструмента. Информацию о повторном использовании ранее квалифицированного
инструмента и покупного готового инструмента см. в разделах 11.2 и 11.3.
j.
Ссылка на План квалификации инструмента или если План квалификации
инструмента не создается (для уровня квалификации инструмента TQL-5), ссылка на
данные поддержки квалификации инструмента.
10.1.2
План квалификации инструмента
Для инструмента, квалифицируемого по уровню TQL 1, 2, 3 или 4 План квалификации
инструмента должен описывать процесс квалификации инструмента. Данный план должен
содержать следующее:
a.
Идентификацию инструмента и, если это применимо, конфигурацию пользователя.
b.
Соображения по квалификации, включая предлагаемый уровень квалификации
инструмента и средств подтверждения соответствия целям настоящего документа.
c.
Обзор функций инструмента, его интерфейсов и его архитектуры. Кроме того, должны
быть определены любые внешние компоненты.
<± Описание эксплуатационной среды (сред) инструмента и, если имеется отличие,
среды (сред) верификации инструмента.
e.
Описание средств, которые Заявитель будет использовать, чтобы представить
Сертифицирующему органу обзор мероприятий процессов ЖЦ инструмента, для того
чтобы можно было запланировать рассмотрения инструмента.
f.
Описание ЖЦ инструмента и мероприятия квалификации, которые должны быть
выполнены.
д.
Данные квалификации инструмента, которые должны быть получены.
h.
Любые дополнительные соображения, которые могут влиять на процесс
квалификации, например, отключенный код, COST инструменты, повторное
использование, квалификация инструмента (других инструментов, используемых для
разработки или верификации инструмента), альтернативные методы квалификации,
история эксплуатации инструмента и методы удостоверения в детерминизме
инструмента согласно последнему абзацу раздела 2.0 настоящего документа.
j.
Организационные ответственности в рамках процессов ЖЦ инструмента.
j.
При использовании поставщиков, средства обеспечения того, что процессы и
выходные данные поставщика будут соответствовать утвержденным планам и
стандартам создания инструментов.
10.1.3
План разработки инструмента
План разработки инструмента включает цели, стандарты и жизненный цикл(ы)
инструмента, которые должны использоваться в процессах разработки инструмента. Данный
план должен включать:
a.
Стандарты. Идентификация Стандартов на разработку требований к инструменту,
Стандартов на проектирование инструмента и Стандартов на кодирование
инструмента для проекта.
b.
ЖЦ инструмента. Описание процессов ЖЦ инструмента, которые предполагается
использовать при построении конкретных ЖЦ инструмента в проекте, включая
критерии перехода для процессов разработки инструмента. Данное описание
отличается от сводки, включаемой в План квалификации инструмента тем, что
предоставляет описание мероприятий разработки с достаточными подробностями,
необходимыми для обеспечения правильного выполнения процессов ЖЦ инструмента.
Руководство Р-330
с.
45
Среда разработки инструмента. Описание выбранной среды разработки инструмента
с указанием аппаратуры и ПО, включая:
1)
выбранные для использования метод(ы) и инструменты разработки требований;
2)
выбранные для использования метод(ы) и инструменты проектирования;
3)
выбранные для использования метод(ы) кодирования, язык(и) программирования,
инструмент(ы) кодирования;
4)
используемые компиляторы и компоновщики;
5)
идентификация выбранной рабочей станции и операционной системы.
10.1.4 План верификации инструмента
План верификации инструмента представляет собой описание мероприятий верификации,
которые должны использоваться, чтобы достичь целей процесса верификации инструмента.
Эти процедуры могут меняться в зависимости от уровня квалификации инструмента, как это
указано в таблицах Приложения А. Данный план должен содержать:
a.
Независимость. Описание методов,
с помощью
независимость верификации, когда это требуется.
которых
обеспечивается
b.
Методы верификации. Описание методов верификации, которые предполагается
использовать для каждого мероприятия процесса верификации инструмента, включая
следующее:
1)
методы рассмотрения, включая проверочные перечни и другие инструменты;
2)
методы анализа, включая трассируемость и анализ покрытия;
3)
методы тестирования, включая метод выбора тестовых примеров, используемые
тестовые процедуры и данные, которые должны быть получены.
c.
Критерии перехода. Критерии входа
определенный в настоящем плане.
в
процесс
верификации
инструмента,
d.
Аспекты, связанные с защитой. Если защита применяется, то указываются методы
верификации целостности защиты.
e.
Метод п о в т о р н о й верификации. Описание методов определения,
верификации частей инструмента, затронутых изменениями.
f.
Ранее разработанные компоненты в поставочном комплекте инструмента. Что
касается таких компонентов, если методы определения соответствия исходной
базовой версии ранее разработанного инструмента не соответствуют настоящему
документу в части процесса верификации, то приводится описание методов для
достижения целей настоящего документа.
анализа
и
10.1.5 План управления конфигурацией инструмента
В Плане управления конфигурацией инструмента устанавливаются методы, которые
предполагается использовать на протяжении ЖЦ инструмента для достижения целей
управления конфигурацией инструмента. Данный план должен содержать:
a.
Среда. Описание среды управления конфигурацией инструмента, которую
предполагается использовать, в том числе процедур, инструментов, методов,
стандартов, организационной ответственности и взаимодействия.
b.
Мероприятия. Описание мероприятий процесса управления конфигурацией
инструмента, проводимых в течение ЖЦ инструмента, включает следующее:
1.
Идентификация
конфигурации.
Единицы
конфигурации,
подлежащие
идентификации, когда они будут идентифицироваться и методы идентификации
для данных ЖЦ инструмента.
Руководство Р-330
46
2.
Базовые версии и трассируемость. Средства установления базовых версий, какие
базовые версии будут установлены, когда эти базовые версии будут установлены,
средства управления библиотеками ПО, а также трассируемость единиц
конфигурации и базовых версий.
3.
Регистрация проблем. Содержание и идентификация Сообщений о проблеме
инструмента для инструмента и процессов ЖЦ инструмента, когда они должны
быть составлены, порядок закрытия сообщений о проблемах, а также взаимосвязь
с мероприятием управления изменениями.
4.
Управление изменениями. Единицы конфигурации и базовые версии, подлежащие
управлению, когда они будут контролироваться, мероприятия по управлению
проблемами и изменениями, с помощью которых осуществляется управление
единицами конфигурации и базовыми версиями, средства управления до
квалификации, средства управления после квалификации, методы сохранения
целостности базовых версий и единиц конфигурации.
5.
Рассмотрение изменений. Метод обработки входящих и исходящих обратных
связей между процессами ЖЦ инструмента; методы оценки и назначения
приоритетов проблемам, утверждения изменений, порядок разрешения
возникающих проблем или реализации изменений; а также взаимосвязь этих
методов с мероприятиями по регистрации проблем и управлению изменениями.
6.
Учет состояния конфигурации. Данные, которые предполагается регистрировать
для обеспечения получения информации о состоянии управления конфигурацией;
определение того, где эти данные будут храниться, как они могут быть получены
для составления отчетов и когда они становятся доступными.
7.
Архивирование, воспроизведение и выпуск. Средства контроля целостности,
метод и полномочия на выпуск, а также сохранение данных.
8.
Средства контроля среды ЖЦ инструмента. Средства управления для
инструментов, используемых для разработки, производства, верификации и
загрузки инструмента с учетом разделов с 1 по 7.
9.
Средства
контроля
данных
ЖЦ
инструмента. Средства
управления,
соответствующие 1-й и 2-й категориям контроля данных (КК1 и КК2).
c.
Критерии перехода. Критерии
конфигурацией инструмента.
d.
Данные управления конфигурацией инструмента. Определение данных ЖЦ
инструмента, порождаемых процессом управления конфигурацией инструмента,
включая Записи управления конфигурацией инструмента, Указатель конфигурации
инструмента и Указатель конфигурации среды ЖЦ инструмента.
e.
Контроль поставщика. Порядок
инструмента на поставщиков.
10.1.6
перехода
для
входа
распространения
в
процесс
требований
управления
процесса
УК
План гарантии качества инструмента
План гарантии качества инструмента устанавливает методы, которые предполагается
использовать для достижения целей процесса гарантии качества инструмента. План гарантии
качества инструмента может содержать описание улучшения процесса, метрик и
прогрессивных методов управления. Данный план должен содержать:
а.
Среда. Описание среды гарантии качества инструмента, включая область применения,
распределение ответственности и взаимодействие, стандарты, процедуры,
инструменты и методы.
Ь.
Полномочия.
Положение о полномочиях
ответственности и независимости.
гарантии
качества
инструмента,
Руководство Р-330
c.
47
Мероприятия. Мероприятия гарантии качества инструмента, которые должны
выполняться для каждого процесса ЖЦ инструмента и в течение всего ЖЦ
инструмента, включая:
1)
методы гарантии качества инструмента, например, рассмотрения, аудиты,
составление отчетов, инспекции и мониторинг процессов ЖЦ инструмента:
2)
мероприятия, связанные с регистрацией
корректирующими действиями;
3)
описание мероприятия рассмотрения соответствия инструмента.
и
отслеживанием
проблем
и
d.
Критерии перехода. Критерии перехода для входа в процесс гарантии качества
инструмента.
e.
Синхронизация. Временная привязка мероприятий процесса гарантии качества
инструмента к мероприятиям процессов ЖЦ инструмента.
f.
Записи ГК инструмента. Определение записей, производимых процессом гарантии
качества инструмента.
д.
Контроль поставщика. Описание средств обеспчения того, что процессы поставщиков
и выходные данные поставщиков соответствуют утвержденным планам и стандартам
создания инструмента.
10.1.7
Стандарты на разработку требований к инструментам
Назначение Стандартов на разработку требований к инструментам - определить методы,
правила и инструменты, которые предполагается использовать для разработки Требований к
инструменту. Эти стандарты должны содержать:
a.
Методы, которые предполагается использовать для разработки Требований
инструменту, такие как методы структурирования.
b.
Нотации, которые предполагается использовать для формулирования требований,
такие как диаграммы потоков данных, языки формальных спецификаций.
c.
Ограничения
инструменту.
d.
Метод, который предполагается использовать для анализа влияния производных
требований к инструменту на Эксплуатационные требования к инструменту (см.
раздел 5.2.1.2,h).
10.1.8
на
использование
инструментов
для
разработки
Требований
к
к
Стандарты на проектирование инструмента
Назначение Стандартов на проектирование инструмента - определить методы, правила
и инструменты, которые предполагается использовать для разработки архитектуры
инструмента и требований низкого уровня к инструменту. Эти стандарты должны содержать:
a.
Используемый метод(ы) описания проекта.
b.
Используемые правила именования.
c.
Ограничения на использование инструментов для разработки Описания проекта
инструмента.
d.
Ограничения на сложность, например, на максимальный уровень вложенности
вызовов или условных структур, на использование безусловных переходов,
количество точек входа-выхода в компоненты программы.
Примечание.
В некоторых случаях Стандарты на разработку требований могут
использоваться для требований низкого уровня к инструменту, вместо
Стандартов на проектирование инструментов.
Руководство Р-330
48
10.1.9 Стандарты на кодирование инструмента
Назначение Стандартов на кодирование
инструмента определить языки
программирования, методы, правила и инструменты, которые предполагается использовать
для создания Исходного кода инструмента. Эти стандарты должны содержать следующее:
a.
Язык(и) программирования и/или его (их) подмножества, которые предполагается
использовать. Для языка программирования должна быть указана ссылка на данные,
которые однозначно определяют синтаксис, поведение конструкций языка, поведение
данных и побочные эффекты языка. Это может потребовать введения ограничений на
использование некоторых особенностей языка.
b.
Стандарты на форму представления Исходного кода инструмента (например,
ограничения на длины строк, использование отступов и пустых строк), а также
стандарты на документирование Исходного кода инструмента (например, указание
имени автора, хронологии изменений, входных и выходных данных, затронутых
глобальных данных).
c.
Правила именования компонент, подпрограмм, переменных и констант.
d.
Условия и ограничения, накладываемые на принятые соглашения о приемах
кодирования, такие как степень связности между компонентами программы, сложность
логических или численных выражений, а также обоснование их применения.
e.
Ограничения
инструмента.
на
применение
инструментов
для
разработки
Исходного
кода
10.1.10 Указатель конфигурации среды жизненного цикла инструмента
Указатель конфигурации среды ЖЦ инструмента определяет конфигурацию среды ЖЦ
инструмента. Этот указатель составляется для поддержки воспроизведения среды
разработки и верификации инструмента, для восстановления исполняемого кода, а также для
повторной верификации или модификации инструмента. Указатель должен:
a.
Определять среду разработки
операционную систему.
инструмента,
включая
рабочую
станцию
и
b.
Определять
инструменты,
используемые
для
разработки
инструмента,
представляемого для квалификации (такие, как компиляторы и компоновщики).
c.
Определить среду(ы) верификации инструмента, если имеется отличие от среды
(сред) разработки инструмента.
d.
Идентифицировать квалифицированные инструменты и соответствующие данные по
их квалификации. Это те инструменты, которые используются в рамках процессов ЖЦ
инструмента, представляемого для квалификации.
10.1.11 Указатель конфигурации инструмента
Указатель конфигурации инструмента определяет конфигурацию поставочного комплекта
инструмента. Должны быть представлены конкретные идентификаторы конфигурации и
идентификаторы версии.
Указатель конфигурации инстурмента должен идентифицировать:
a.
Поставочный комплект инструмента.
b.
Исполняемый объектный код инструмента, включая все связанные файлы.
c.
Каждую компоненту Исходного кода инструмента.
d.
Ранее разработанные компоненты, входящее в состав поставочного комплекта
инструмента, если таковые используется.
e.
Данные ЖЦ инструмента.
Руководство Р-330
49
f.
Ссылку на Указатель конфигурации среды ЖЦ инструмента (см. раздел 10.1.10), если
он составлен отдельно.
д.
Носители для хранения и выпуска.
h.
Инструкции по построению Исполняемого объектного кода инструмента (включая,
например, инструкции и данные по компиляции и компоновке), а также процедуры,
используемые для восстановления инструмента при его повторной генерации,
тестировании или модификации.
Примечание 1. Указатель конфигурации инструмента может содержать одну единицу
данных или комплект (иерархию) единиц данных. Указатель
конфигурации инструмента может содержать перечисленные выше
единицы или ссылаться на другой Указатель конфигурации
инструмента либо
на
другие
идентифицированные
данные
конфигурации, которые указывают отдельные единицы и их версии.
Примечание 2. Указатель конфигурации инструмента может быть создан для одной
версии поставочного комплекта инструмента или может быть
расширен
так,
чтобы
содержать
данные
для
нескольких
альтернативных
или последовательных версий поставочного
комплекта инструмента.
Примечание 3. Указатель конфигурации инструмента может включать только
данные, создаваемые во время процесса разработки этого
инструмента. Он может определять не все данные инструмента,
интегрированного в эксплуатационную среду инструмента. В этом
случае эти данные должен определить Указатель конфигурации среды
ЖЦПО.
10.1.12 Сообщения о проблемах инструмента
Сообщения о проблемах инструмента являются средством идентификации и регистрации
решений, принятых в отношении фактов ненормального поведения поставочного комплекта
инструмента, несоответствия процесса планам и стандартам создания инструмента, а также
недостатков в данных ЖЦ инструмента. Сообщения о проблемах инструмента должны
включать:
a.
Идентификацию единицы конфигурации и/или
инструмента, в котором обнаружена проблема.
b.
Идентификацию единицы (единиц) конфигурации, которая будет изменена, или
описание процесса, в который будут внесены изменения.
c.
Описание проблемы, позволяющее понять ее суть и найти ее решение.
d.
Описание
корректирующего
зарегистрированной проблемы.
действия,
мероприятия
предпринимаемого
процесса
для
ЖЦ
решения
10.1.13 Записи управления конфигурацией инструмента
Результаты мероприятий процесса УК инструмента регистрируются в Записях управления
конфигурацией инструмента.
Примерами являются списки идентификаторов конфигурации, базовые версии, отчеты об
истории изменений, записи хранения и выпуска. Эти примеры не подразумевают
необходимость создания записей этих конкретных типов.
Примечание.
Вследствие
интегрального
характера
процесса
управления
конфигурацией инструмента его выходные данные часто включаются
в другие данные Ж Ц инструмента как составная часть.
Руководство Р-330
50
10.1.14 Записи гарантии качества инструмента
Результаты мероприятий процесса ГК инструмента регистрируются в Записях гарантии
качества инструмента. Они могут включать отчеты о рассмотрениях или аудитах ГК
инструмента, протоколы совещаний, записи об утвержденных отклонениях от процессов или
записи рассмотрений соответствия иснтрумента.
В дополнение к Записям гарантии качества инструмента, которые рассматривают
разработку инструмента, будут предусмотрены Записи гарантии качества ПО, которые
рассматривают его использование.
10.1.15 Итоговое заключение об инструменте
Для инструмента, квалифицируемого по уровню TQL 1, 2, 3 или 4, Итоговое заключение
об инструменте является основной единицей данных для демонстрации соответствия Плану
квалификации инструмента.
Итоговое заключение об инструменте должно включать:
a.
Обзорное описание инструмента. В настоящем разделе кратко описываются основные
функции инструмента, его входные и выходные данные, а также любые отклонения от
обзорного описания инструмента, предлагавшегося в Плане квалификации
инструмента,
b.
Квалификационные аспекты. В настоящем разделе повторно указывается уровень
квалификации инструмента, предлагаемый для инструмента, описанного в Плане
квалификации инструмента. Он определяет также эксплуатационную среду(ы).
c.
ЖЦ инструмента. В настоящем разделе представляется сводка реального ЖЦ
(циклов) инструмента и объясняются отклонения от мероприятий квалификации
инструмента, определенных в Плане сертификации инструмента.
d.
Данные ЖЦ инструмента. В данном разделе описываются все отклонения от
предложений, сделанных в Плане квалификации инструмента для производимых
данных ЖЦ инструмента, связи этих данных между собой и с другими данными,
определяющими инструмент, а также средства, с помощью которых эти данные были
сделаны доступными для сертифицирующего органа. Этот раздел в прямой форме,
посредством идентификаторов конфигурации и версии, ссылается на применимый
Указатель конфигурации инструмента и Указатель конфигруации среды ЖЦ
инструмента. Детальная информация, касающаяся идентификаторов конфигурации и
конкретных версий данных ЖЦ инструмента, представлена в Указателе конфигурации
инструмента.
e.
Дополнительные аспекты. В данном разделе приведена сводка вопросов
квалификации, которые могут привлечь внимание сертифицирующего органа. В нем
объясняются любые отклонения от предложений, содержащихся в Плане
Квалификации инструмента, относительно таких соображений. Должны быть сделаны
ссылки на применимые единицы данных, такие как специальные условия или
пояснительные материалы.
f.
Контроль поставщика. В данном разделе описывается, как процессы и выходные
данные поставщика соответствуют утвержденным планам и стандартам создания
инструмента.
д.
ИдентисЬикаиия инструмента. В этом разделе идентифицируется конфигурация
инструмента в виде идентификационного номера и версии.
h.
История изменений. Если применимо, в данном разделе дается сводка изменений,
влияющих на функциональность, а также идентифицируются любые изменения и
улучшения процессов ЖЦ инструмента, имевшие место после предыдущей
квалификации.
L
Состояние инструмента. В этом разделе приводится сводка Сообщений о проблемах
инструмента, по которым на момент одобрения не приняты решения, и оценка влияния
Руководство Р-330
51
проблем на функциональность инструмента. Кроме того, он должен включать любые
ограничения функциональности инструмента.
j.
Заявление о соответствии требованиям. В этот раздел включено заявление о
соответствии требованиям настоящего документа, а также сводка методов,
используемых для демонстрации соответствия критериям, указанным в планах
создания инструмента. Кроме того, в этом разделе рассматриваются дополнительные
правила, установленные Сертифицирующим органом, а также любые отступления от
планов и стандартов создания инструментов и от настоящего документа, неучтенные
где-либо в Итоговом заключении об инструменте.
10.1.16 Информация относительно инструмента в Итоговом заключении о ПО
Для инструмента, квалифицируемого по уровню квалификации инструмента 1, 2, 3 или 4,
Итоговое заключение о ПО должно включать:
a.
Идентификацию инструмента.
b.
Детальную информацию по сертификационному зачету, который должен быть
получен за счет использования данного инструмента, т.е. процесса(ов) ПО, которые
должны быть исключены, упрощены или автоматизированы.
c.
Ссылку на Итоговое заключение об инструменте.
d.
Заявление о соответствии процессов разработки, верификации и интегральных
процессов планам создания инструмента, включая мероприятия пользователя
инструмента.
e.
Анализ открытых Сообщений о проблемах инструмента, чтобы убедиться, что
поведение инструмента все еще соответствует Эксплуатационным требованиям к
инструменту.
f.
Описание любых отклонений использования
определенным в Плане сертификации ПО.
инструмента
по
отношению
к
Для инструмента, квалифицируемого по уровню TQL-5, Итоговое заключение о ПО должно
включать следующую информацию:
аа. Идентификацию инструмента.
bb. Детальную информацию по сертификационному зачету, который должен быть
получен за счет использования данного инструмента, т.е. процесса(ов) ПО, которые
должны быть исключены, упрощены или автоматизированы.
сс. Ссылку на данные квалификации инструмента.
10.1.17 Информация относительно инструмента в Указателе конфигурации среды
жизненного цикла ПО
Для каждого инструмента, квалифицируемого по уровню TQL 1, 2, 3 или 4, Указатель
Конфигурации среды ЖЦ ПО должен включать:
a.
Идентификацию инструмента.
b.
Ссылку на Указатель
инструменте.
конфигурации
инструмента
и Итоговое
заключение
об
Для инструмента, квалифицируемого по уровню TQL-5, Указатель конфигурации среды
ЖЦ ПО должен включать в себя:
аа. Идентификацию инструмента.
bb. Ссылку на данные квалификации инструмента.
Руководство Р-330
52
10.2 Данные квалификации инструмента, производимые в процессах разработки
инструмента и соответствующих мероприятиях верификации
10.2.1 Требования к инструментам
Требования к инструменту описывают всю функциональность инструмента. Эти данные
должны содержать:
a.
Описание функций и технических особенностей инструмента, включая режимы работы.
b.
Инструкции пользователю, инструкции по установке, перечень сообщений об ошибках
и ограничения. Они часто собираются вместе в виде руководства пользователя.
Руководство пользователя может быть частью Требований к инструменту или может
быть включено в один или несколько документов.
c.
Требования по описанию возможности пользователя настраивать инструмент.
d.
Функциональные
требования,
(см. раздел 5.2.1.2,к).
e.
Специальные требования, если необходимо, для соответствия эксплуатационной
среде инструмента.
f.
Специальные требования в отношении
несовместимые входные данные.
д.
Ожидаемая реакция инструмента в ненормальных условиях работы.
h.
Для набора инструментов - требования к интерфейсам между инструментами в
пределах набора.
с
соответствующим
отказных
уровнем
состояний
детализации
и
реакции
на
10.2.2 Описание проекта инструмента
Описание проекта инструмента представляет собой определение архитектуры
инструмента и требований низкого уровня к инструменту, которые будут уточнять Требования
к инструменту. Эти данные должны содержать:
a.
Описание архитектуры инструмента, определяющей структуру инструмента для
выполнения требований.
b.
Детальное описание того, как все Требования к инструменту распределены в
архитектуре инструмента.
c.
Описание входных и выходных данных (например, словарь данных), как внутренних,
так и внешних для архитектуры ПО.
d.
Поток данных и поток управления для проекта.
е.
Процедуры диспетчеризации.
f.
Защита, если таковая используется.
д.
Описание компонентов ПО, как новых, так и ранее разработанных, и если они
разработаны ранее, то ссылка на базовые версии, из которых они получены.
h.
Требования низкого уровня к инструменту, которые реализуются и трассируются на
Требования к инструменту.
i.
Производные требования низкого уровня к инструменту, появившиеся в процессе
проектирования инструмента.
10.2.3 Исходный код инструмента
Для каждой компоненты Исходного кода инструмента эти данные состоят из: (1) кода,
записанного на языке(ах) сценариев или исходном языке(ах); (2) команды компоновки и (3)
команды компилятора для генерирования Исполняемого объектного кода инструмента из
Исходного кода инструмента (если таковой используется, что зависит от языка). Эти данные
Руководство Р-330
53
должны включать идентификацию инструмента, в том числе имя и дату изменения и/или
версии, в зависимости от того, какое из этих двух понятий применимо.
10.2.4 Исполняемый объектный код инструмента
Исполняемый объектный код инструмента состоит из формы инструмента, которая
напрямую используется процессором эксплуатационной среды инструмента. Следует
отметить, что в зависимости от выбранного языка исходного кода компилирование и
компоновка могут оказаться не нужными. Одним из примеров является инструмент,
реализованный на языке сценариев. В этом случае Исполняемый объектный код инструмента
следует понимать как инструмент в его исполняемом формате.
Считается, что связанные файлы, такие как файлы параметров и конфигураций,
необходимые для исполнения инструмента, включены в Исполняемый объектный код
иинструмента. Исполняемый объектный код инструмента генерируется в среде разработки
инструмента. Если инструмент предназначается для использования в нескольких
эксплуатационных средах инструмента, могут быть сгенерированы несколько конфигураций
Исполняемого объектного кода инструмента.
10.2.5 Примеры и Процедуры верификации инструмента
Примеры и Процедуры верификации инструмента подробно описывают, как реализуются
мероприятия процесса верификации инструмента. Эти данные должны включать:
a.
Процедуры рассмотрения и анализа. Рамки и глубина рассмотрения или
используемые методы анализа, дополняющие описание в Плане верификации
инструмента.
b.
Тестовые примеры. Назначение каждого тестового примера, набор входных данных,
условия, ожидаемые результаты для удовлетворения требуемых критериев покрытия,
а также критерии «проходит - не проходит».
c.
Тестовые процедуры. Пошаговые инструкции по подготовке и выполнению каждого
тестового примера, оценке результатов тестирования, а также используемая среда
тестирования.
10.2.6 Результаты верификации инструмента
Результаты верификации инструмента
верификации инструмента, и должны:
создаются
в ходе
мероприятий
процесса
a.
Для каждого рассмотрения, анализа и теста указывать все процедуры и их результаты
«проходит - не проходит», а также общий результат «проходит - не проходит».
b.
Идентифицировать единицу конфигурации или версию ПО, которая проходила
рассмотрение, анализ или тестирование.
c.
Включать результаты тестов, рассмотрений и анализов, включая анализ покрытия и
анализ трассируемости.
d.
Регистрировать и отслеживать любые обнаруженные отклонения с помощью процесса
регистрации проблем.
Примечание.
Эти данные не включают данные, производимые процессом
эксплуатационной верификации и валидации инструмента (они
рассматриваются в разделах 10.3.3 и 10.3.4 настоящего документа).
Руководство Р-330
54
10.2.7 Данные трассировки
Данные трассировки устанавливают связи между содержимым единиц данных ЖЦ.
Должны быть предоставлены Данные трассировки, демонстрирующие двунаправленные
связи между:
a)
Эксплуатационными требованиями к инструменту и Требованиями к инструменту;
b)
Требованиями к инструменту и требованиями низкого уровня к инструменту;
c)
требованиями низкого уровня к инструменту и Исходным кодом инструмента;
d) Требованиями к инструменту и требованиями низкого уровня к инструменту и
соответствующими им тестовыми примерами;
e) тестовыми примерами и тестовыми процедурами;
f)
тестовыми процедурами и результатами тестов.
Примечание.
Данные трассировки между тестовыми процедурами и результатами
тестов могут быть частью Результатов верификации инструмента
(см. раздел 10.2.6,с).
10.3 Данные квалификации инструмента, получаемые в процессе определения
Эксплуатационных требований к инструменту, в процессе эксплуатационной
интеграции инструмента, а также в ходе соответствующих мероприятий
верификации и валидации
10.3.1 Эксплуатационные требования к инструменту
Эксплуатационные
требования
к инструменту
определяют
функциональность
инструмента и интерфейс сточки зрения процесса ЖЦ ПО (т.е. процесса, который использует
инструмент). Эксплуатационные требования к инструменту должны включать, в зависимости
от конкретных обстоятельств:
a.
Описание контекста использования инструмента, включая интерфейсы с другими
инструментами и интеграцию выходных файлов инструмента в получаемое ПО.
b.
Описание эксплуатационной
устанавливаться инструмент).
c.
Описание входных файлов, включая формат, определение языка и т.п.
d.
Описание выходных файлов, включая формат и содержимое.
e.
Требования ко всем функциям и техническим свойствам инструмента, используемым
для удовлетворения идентифицированного процесса (процессов) ЖЦ ПО.
f.
Требования по рассмотрению ненормальных режимов активации или неправильных
входных данных, которые должны обнаруживаться инструментом. Эти требования
должны учитывать влияние этих режимов на функциональность и выходные данные
инструмента. (Этот пункт не применяется к уровню квалификации инструментов
TQL-5.)
д.
Применимая информация для пользователя, такая как руководство пользователя и
руководство по установке или ссылка на него, если оно не приведено как часть данных
Требований к инструменту.
h.
Описание использования инструмента в эксплуатации (включая выбираемые опции,
значения параметров, командную строку и т.п.).
i.
Требования к
инструмента.
среды (сред)
характеристикам,
инструмента
указывающие
поведение
(в
которой
выходных
будет
данных
Руководство Р-330
55
10.3.2 Протокол об установке инструмента
Исполняемый объектный код инструмента устанавливается в эксплуатационную среду
инструмента. Протокол данной установки должен включать:
a.
Идентификацию эксплуатационной среды инструмента {конфигурация аппаратуры,
конфигурация операционной системы, установленные опции и т.п.).
b.
Идентификацию версии Исполняемого объектного кода инструмента, включая все
файлы конфигурации и параметров.
c.
Идентификацию, если требуется, внешних компонентов.
d.
Идентификацию средств исполнения инструмента (командная строка, файл сценария
и т.п.); это может включать ссылку на руководство пользователя.
Примечание.
Эта информация может быть включены в Указатель конфигурации
среды ЖЦ ПО.
10.3.3 Примеры и Процедуры эксплуатационной верификации и валидации
инструмента
Примеры и Процедуры эксплуатационной верификации и валидации инструмента
подробно описывают,
как реализуются мероприятия процесса эксплуатационной
верификации и валидации инструмента. Эти данные должны включать:
a.
Процедуры рассмотрения и анализа. Рамки и глубина рассмотрения или
используемые методы анализа, дополняющие описание в Плане верификации
инструмента.
b.
Тестовые примеры. Назначение каждого тестового примера, набор входных данных,
условия
и
ожидаемые
результаты
для
удовлетворения
критериев
«проходит - не проходит».
c.
Тестовые процедуры. Пошаговые инструкции по подготовке и выполнению каждого
тестового примера, выбору входных данных, оценке результатов тестирования,
а также используемая среда тестирования.
10.3.4 Результаты эксплуатационной верификации и валидации инструмента
Процесс эксплуатационной верификации и валидации инструмента создает Результаты
эксплуатационной верификации и валидации инструмента, которые должны:
a) для каждого рассмотрения, анализа и теста указывать все процедуры и их результаты
«проходит - не проходит», а также общий результат «проходит - не проходит»;
b)
идентифицировать единицу конфигурации или
проходила рассмотрение, анализ или проверку;
версию
инструмента,
которая
c)
включать в себя результаты проверок, рассмотрений и анализов;
d)
регистрировать и отслеживать любые обнаруженные отклонения с помощью процесса
регистрации проблем.
Руководство Р-330
56
11.0 ДОПОЛНИТЕЛЬНЫЕ СООБРАЖЕНИЯ ПО КВАЛИФИКАЦИИ
ИНСТРУМЕНТА
В настоящем разделе представлены инструктивные материалы по дополнительным
соображениям, касающимся квалификации инструментов в отношении использования
многофункциональных инструментов, ранее квалифицированных инструментов, покупных
готовых инструментов, истории эксплуатации и альтернативных методов достижения целей,
задокументированных в предыдущих разделах настоящего документа.
11.1 Многофункциональные инструменты
Многофункциональным инструментом является такой инструмент, который выполняет
несколько функций. Примерами типов многофункциональных инструментов являются:
•
инструмент с одним исполняемым файлом с несколькими функциями;
•
инструмент, составленный из нескольких исполняемых файлов, который позволяет
отключение определенных исполняемых файлов;
•
инструмент, скомпонованный каким-либо иным способом, который позволяет
пользователю отключать или выбирать часть функциональности инструмента.
Некоторые из функций могут использоваться для исключения, упрощения или
автоматизации процесса(ов) ЖЦ ПО, а некоторые функции могут даже вообще не
использоваться в конкретном проекте. Например, инструмент может включать несколько
функций разработки и верификации; некоторые функции разработки и верификации могут
быть использованы, в то время как другие функции не нужны для конкретного проекта.
Для каждой функции многофункционального инструмента с помощью применяемых
инструктивных материалов, касающихся соответствующей области, должен быть определен
уровень квалификации инструмента. Приведенные ниже дополнительные инструктивные
материалы должны применяться, когда квалифицируются только некоторые функции или
когда к некоторым функциям применяются различные уровни квалификации инструментов.
В противном случае весь инструмент должен квалифицироваться на наивысший уровень
квалификации инструментов.
a.
Некоторые функции могут быть квалифицированы на более низкий уровень
квалификации инструментов. Это осуществимо только в том случае, если функция(и)
на более высоком уровне защищены от функции (или группы функций) на более
низком уровне(ях) квалификации инструментов. Заявителю следует оценить всю
функциональность и реализацию инструмента и определить каждую функцию (или
группу функций) с предлагаемым уровнем(ями) квалификации инструментов.
Эта оценка
включает
идентификацию
каждой
функции
инструмента,
взаимоотношения и взаимодействие функций инструмента,
использование
инструмента в эксплуатации, конфигурацию(и) инструмента, а также идентификацию
функций, предназначенных для квалификации.
b.
Должна быть продемонстрирована защита между функциями (или группами функций)
с различными уровнями квалификации инструментов. Приемлемым свидетельством
такой защиты могла бы служить демонстрация того, что выходные данные функций
(или групп функций), квалифицируемых с более низким уровнем квалификации
инструментов, не влияют на выходные данные других функций (т.е. возможности
инструмента функционально изолированы). Если реализуются различные уровни
квалификации инструментов, подход к защите должен быть обоснован для каждой
функции инструмента.
c.
Когда продемонстрирована защита между функциями (или группами функций),
защищенные функции могут квалифицироваться так, как если бы они были
отдельными инструментами.
d.
Если многофункциональный инструмент и производит выходные данные, и
верифицирует те же самые выходные данные, следует продемонстрировать, что
Руководство Р-330
57
функции инструмента были разработаны с использованием методов защиты,
предотвращающих возникновение ошибки, которая может повлиять на обе функции.
Если достигаемая инструментом цель верификации требует независимости, для
верифицирующей выходные данные функции должна быть продемонстрирована
независимость от функции, которая производит выходные данные. Независимость
обычно используется для того, чтобы гарантировать, что между функциями
инструмента не существует общих ошибок, и чтобы подтвердить, что функция
верификации полностью обнаруживает любые ошибки в выходных данных.
е.
При использовании настоящих инструктивных материалов некоторые функции в
инструменте могут не квалифицироваться. Обычно это бывает в случае, когда
некоторая функция(и) в инструменте не используется в процессе ЖЦ ПО, или
выходные данные инструмента верифицируются так, как требуют инструктивные
материалы
конкретной
области.
Необходимо
продемонстрировать,
что
квалифицированная функция не зависит от неиспользуемой функции(й) или группы
(групп) функций. Кроме того, неиспользуемые функции должны быть четко
идентифицированы, чтобы исключить случайное предположение о том, что они
квалифицированы, в последующих работах по квалификации.
Все многофункциональные инструменты должны быть описаны в соответствующих
планах создания инструментов. Эти планы должны объяснять функциональность
инструмента, оценку уровней квалификации инструментов, описание функций, которые будут
использоваться и которые не будут использоваться, а также объяснение того, как будут
удовлетворяться представленные выше инструктивные материалы.
Примечание.
Если инструмент не содержит функциональности выше уровня
квалификации инструмента TQL-5, применяется только раздел
11.2 Ранее квалифицированные инструменты
Ранее квалифицированные инструменты охватывают любой уже квалифицированный
инструмент, использование которого предполагается в последующем проекте (последующим
проектом может быть новый проект или модификация существующего проекта). Ниже в
настоящем разделе представлены инструктивные материалы для трех аспектов
квалификации инструментов: (1) повторное использование ранее квалифицированных
инструментов, которые не меняются, (2) изменения эксплуатационной среды инструмента и
(3) изменения самого инструмента. На рисунке 11-1 показаны эти три аспекта ранее
квалифицированных инструментов и порядок оценки.
Рисунок 11-1. Оценка ранее квалифицированных инструментов
Руководство Р-330
58
11.2.1 Повторное использование ранее квалифицированных инструментов
В настоящем разделе рассматривается повторное использование данных квалификации
для инструмента,
квалифицированного в предыдущем проекте,
который
будут
использоваться без изменений в следующем проекте.
Инструмент подходит для повторного использования, если удовлетворяются следующие
критерии:
a.
Инструмент был ранее квалифицирован в рамках проекта ПО, уже одобренного
Сертифицирующим органом.
b.
Уровень квалификации инструмента для повторного использования тот же самый или
ниже, чем в предыдущей квалификации.
c.
Предполагаемые к повторному использованию данные ЖЦ
изменились с момента предыдущей квалификации инструмента.
d.
Продемонстрировано, что эксплуатационная среда инструмента эквивалентна той,
что была при предыдущей квалификации.
e.
Эксплуатационные требования к инструменту те же самые, что и при предыдущей
квалификации.
f.
Заявитель имеет доступ к одобренным данным квалификации инструмента.
д.
Заявитель гарантирует, что используется та же самая версия инструмента, которая
поддерживается данными квалификации.
инструмента
не
Если любой их этих критериев не удовлетворяется, тогда следует проанализировать
разделы 11.2.2 и/или 11.2.3 на предмет изменения(й).
Если удовлетворяются все критерии, намерение и обоснование повторного
использование данных инструмента должны быть задокументированы в Плане сертификации
ПО и/или Плане квалификации инструмента и предоставлены сертифицирующему органу.
Кроме того, любое Сообщение о проблеме инструмента, все еще незакрытое, либо открытое
(даже если закрыто впоследствии) с момента предыдущей квалификации, следует оценить и
надлежащим образом решить.
11.2.2 Изменения эксплуатационной среды инструмента
В настоящем разделе рассматривается(ются) изменение(я) в эксплуатационной среде
инструмента. Примером является обновление операционной системы рабочей станции, на
которой используется инструмент.
Следует провести анализ изменений, чтобы убедиться в том, что:
a)
среда(ы) верификации инструмента является репрезентативной для эксплуатаци­
онной среды инструмента (см. раздел 4.4,с);
b)
требования к совместимости эксплуатационной среды инструмента, описываемые в
Эксплуатационных требованиях к инструменту, полны и применимы к новой
эксплуатационной среде инструмента (см. раздел 6.2.2,а,2);
c)
инструмент, устанавливаемый в новой эксплуатационной среде
соответствует потребности процессов ЖЦ ПО (см. раздел 6.2.2,с).
инструмента,
Этот анализ определяет мероприятия, которые должны быть выполнены или выполнены
повторно.
Описание изменений с момента предыдущей квалификации и поддерживающий анализ
следует изложить в Плане сертификации ПО и/или Плане квалификации инструмента и
представить Сертифицирующему органу.
Руководство Р-330
59
11.2.3 Изменения ранее квалифицированного инструмента
В настоящем разделе рассматриваются
инструмента для последующего проекта.
изменения
ранее
квалифицированного
Если имеются изменения инструмента, планов создания инструмента, требуемого уровня
квалификации инструмента или планируемого использования инструмента, требуется анализ
влияния изменения. Этот анализ должен рассматривать влияние изменения как минимум на
следующие области:
a.
Эксплуатационные требования к инструменту.
b.
Требования к инструменту.
c.
Описание проекта ПО.
<± Исходный код инструмента.
е.
Среда и процесс разработки инструмента.
Этот анализ влияния должен выявить любые необходимые мероприятия по повторной
верификации. Например, анализ трассируемости, анализ связности поданным и связности по
управлению, регрессионное тестирование, рассмотрение требований и т.п.
Предназначение, обоснование и описание изменения(й) должны быть указаны в планах и
представлены Сертифицирующему органу.
11.3 Квалификация покупного готового инструмента
В настоящем разделе инструктивные материалы данного документа адаптируются для
применения к покупному готовому инструменту. Покупной готовый инструмент обычно
разрабатывается независимо от любого проекта ПО и предназначается для использования
многими пользователями.
Инструктивные материалы настоящего раздела покрывают покупные готовые
инструменты, спроектированные для конфигурирования пользователями инструмента, как
описано
в
руководстве
пользователя.
Инструменты,
которые
модифицируются
пользователем, здесь не рассматриваются.
Покупные готовые инструменты, как и любой иной квалифицируемый инструмент, должны
достигать целей, соответствующих необходимому уровню квалификации инструмента.
Однако
чтобы
достигнуть
целей
различных
процессов
(процесса
разработки
эксплуатационных характеристик инструмента, процесса разработки инструмента и всех
связанных процессов верификации), должно быть предложено разделение ответственности
между пользователем и разработчиком инструмента.
11.3.1 Подход к квалификации покупного готового инструмента
Покупные готовые инструменты обычно разрабатываются без имеющихся в наличии
Эксплуатационных требований к инструменту, связанных с ЖЦ ПО. Чтобы донести до
пользователей
функциональность
и предполагаемое
использование
инструмента,
разработчик инструмента должен предоставить Эксплуатационные требования к инструменту
от разработчика (разработчик-TOR), которые охватывают множество эксплуатационных
требований для возможных ЖЦ ПО. Пользователь инструмента будет использовать
Эксплуатационные требования к инструменту от разработчика, чтобы определить,
соответствует ли инструмент потребностям ЖЦ ПО. Пользователь инструмента
предоставляет Эксплуатационные требования к инструменту, определяющие требования к
эксплуатации инструмента. Эксплуатационные требования к инструменту обычно
перекрывают Эксплуатационные требования к инструменту от разработчика.
Для покупных готовых инструментов мероприятия квалификации обычно выполняются
двумя сторонами:
•
разработчиком инструмента, (сторона, которая разрабатывает инструмент);
Руководство Р-330
60
•
пользователем инструмента, (сторона, которая использует инструмент в рамках
данного проекта создания ПО).
Ниже определяются мероприятия как для разработчика, так и для пользователя покупного
готового инструмента, чтобы достигнуть всех целей квалификации инструмента. Следует
отметить, что для квалификации по уровню квалификации инструментов TQL-5 цели могут
быть достигнуты без каких-либо данных квалификации инструмента от разработчика
инструмента.
11.3.2 Мероприятия для разработчика инструмента
Чтобы предоставить инструмент, который может быть квалифицирован, разработчик
инструмента должен:
•
использовать инструктивные материалы настоящего документа, чтобы выполнить
мероприятия и создать данные ЖЦ инструмента, необходимые для демонстрации того,
что все цели, назначенные разработчику инструмента, достигнуты;
•
предоставить Эксплуатационные требования к инструменту от разработчика, чтобы
идентифицировать функции, реализованные в инструменте (см. раздел 11.3.2.1);
•
предоставить комплект предварительных данных квалификации инструмента,
соответствующих конкретному уровню квалификации инструментов (см. разделы с
11.3.2.2 по 11.3.2.4).
В таблице 11-1 определяются цели, обычно применимые к разработчику инструмента.
Руководство Р-330
61
Таблица 11-1. Типовые цели для разработчика инструмента
Таблица
Цели, назначаемые
Приложения А разработчику инструмента
Т-0
Цели 2, 4 и 5:
Применимы
Примечания
•
Прочие: Неприменимы
•
•
Т-1
Все: Применимы
Цель 2: разработчик инструмента
предоставляет Эксплуатационные требования
к инструменту от разработчика
Цели 4 и 5 выполняются с помощью
Эксплуатационных требований к инструменту
от разработчика
Другие цели: это ответственность
пользователя инструмента
•
Цели 3 и 5: полностью назначаются
разработчику инструмента
•
Другие цели: область применения данных
целей ограничивается отдельными
мероприятиями, выполняемыми
разработчиком инструмента
Т-2
Все: Применимы
*
Разработчик инструмента использует
Эксплуатационные требования к инструменту
от разработчика, чтобы выполнить
мероприятия процесса разработки
инструмента
Т-3
Все: Применимы
•
Цели 1 и 8 выполняются с помощью
Эксплуатационных требований к инструменту
от разработчика
С Т-4 по Т-7
Все: Применимы
•
Все мероприятия выполняются пользователем
инструмента
Т-8
Все: Применимы
*
Область применения ограничивается
данными, получаемыми во время
мероприятий, выполняемых разработчиком
инструмента
Т-9
Все: Применимы
•
Область применения ограничивается
мероприятиями, выполняемыми
разработчиком инструмента
Т-10
Все: Неприменимы
•
Все мероприятия выполняются пользователем
инструмента
11.3.2.1 Эксплуатационные требования к инструменту от разработчика
Эксплуатационные требования к инструменту от разработчика следует разрабатывать
таким образом, чтобы пользователь инструмента мог определить, соответствует ли данный
инструмент потребностям пользователя. Эксплуатационные требования к инструменту от
разработчика должны содержать данные, на которые пользователь инструмента может
напрямую без модификации ссылаться из своих Эксплуатационных требований к инструменту.
Эксплуатационные требования
к инструменту от
разработчиком инструмента вместо Эксплуатационных
описываемых в настоящем документе.
разработчика используются
требований к инструменту,
Эксплуатационные требования к инструменту от разработчика должны включать:
а.
Описание всех предполагаемых эксплуатационных сред инструмента.
Руководство Р-330
62
b.
Описание входных файлов, включая формат, определение языка и т.п. (см. раздел
10.3.1,с).
c.
Описание выходных файлов, включая формат и содержимое (см. раздел 10.3.1,d).
d.
Требования ко всему ожидаемому функциональному поведению инструмента (с точки
зрения процесса ЖЦ ПО) (см. раздел 10.3.1,е).
e.
Требования в отношении ненормальных режимов включения или неправильных
входных данных, которые должны обнаруживаться инструментом. Эти требования
должны учитывать влияние этих режимов на функциональность и выходные данные
инструментов (см. раздел 10.3.1,f).
f.
Применимая информация пользователя, такая как руководство пользователя или
руководство по установке (или ссылка на него, если оно не приведено как часть
данных Требований к инструменту) (см. раздел 10.3.1 ,д).
11.3.2.2 План квалификации инструмента от разработчика (разработчик-TQP)
План квалификации инструмента от разработчика должен иметь то же самое содержание,
что указано в разделе 10.1.2, но должен быть ограничен мероприятиями, назначенными
разработчику инструмента. Кроме того, План квалификации инструмента от разработчика
должен описывать, как пользователь инструмента может использовать предварительные
данные квалификации.
11.3.2.3 Указатель конфигурации инструмента от разработчика (разработчик-ТС!)
Указатель конфигурации инструмента от разработчика должен иметь то же самое
содержание, что указано в разделе 10.1.11, но должен быть ограничен данными,
поставляемыми во время мероприятий, выполняемых разработчиком инструмента.
11.3.2.4 Итоговое заключение об инструменте от разработчика (разработчик-TAS)
Итоговое заключение об инструменте от разработчика должно иметь то же самое
содержание, что указано в разделе 10.1.15, но должно быть ограничено мероприятиями,
назначенными разработчику инструмента.
11.3.3 Мероприятия квалификации инструмента для пользователя инструмента
Выбор покупного готового инструмента обычно выполняется в процессе планирования ПО.
В ходе этого процесса пользователь должен оценить, сможет ли покупной готовый инструмент
удовлетворить потребности предлагаемого процесса ЖЦ ПО и будет ли он совместим с
эксплуатационной средой инструмента. Следует также оценить наличие и релевантность
данных ЖЦ покупного готового инструмента и предварительного комплекта данных
квалификации для поддержки квалификации соответствующего уровня квалификации
инструмента в рамках проекта создания ПО.
Покупной готовый инструмент, который был ранее квалифицирован, не считается
автоматически квалифицированным для других проектов, требующих одобрения
(инструктивные материалы по ранее квалифицированным инструментам см. в разделе 11.2).
Если существующих данных ЖЦ инструмента недостаточно для демонстрации
соответствия всем целям, применимым к разработчику инструмента, тогда пользователь
инструмента должен расширить данные и/или предложить альтернативные средства
(см. раздел 11.5). Этот подход должен быть описан в Плане квалификации инструмента.
Для оценки покупного готового инструмента в эксплуатационной среде инструмента
пользователь инструмента должен дополнить мероприятия разработчика. В таблице 11-2
определяются цели, обычно применимые к пользователю инструмента.
Руководство Р-330
63
Таблица 11-2. Типовые цели для пользователя инструмента
Таблица
Цели, назначаемые
Приложения А разработчику инструмента
Т-0
Цели 4 и 5:
Неприменимы
Примечания
•
Цель 2: пользователю инструмента следует
предоставить Эксплуатационные требования
к инструменту, которые дополняют
предоставленные разработчиком инструмента
Эксплуатационные требования к инструменту
от разработчика
•
Цели 4 и 5: пользователю инструмента
следует оценить Эксплуатационные
требования к инструменту от разработчика
как источник входных данных для своих
Эксплуатационных требований к инструменту
Цель 6: пользователю инструмента следует
верифицировать Эксплуатационные
требования к инструменту, чтобы оценить,
удовлетворяют ли они потребности
пользователя
Прочие: Применимы
•
•
Цель 7: это мероприятие выполняется
с помощью Эксплуатационных требований
к инструменту
Цели 3 и 5:
Неприменимы
•
Цели 3 и 5: мероприятия разработчика
инструмента
Прочие: Применимы
•
Другие цели: пользователь инструмента
дополняет данные, создаваемые
разработчиком инструмента, выполняя
мероприятия пользователя инструмента.
Следует также запланировать координацию
между мероприятиями разработчика и
пользователя инструмента
С Т-2 по Т-7
Все: Неприменимы
•
Все они являются мероприятиями
разработчика инструмента
Т-8
Все: Применимы
•
Область применения охватывает данные,
получаемые во время мероприятий,
выполняемых пользователем инструмента
Т-9
Все: Применимы
•
Цели 1 и 2: область применения ограничена
мероприятиями, выполняемыми
пользователем инструмента
•
Цель 3: соответствие инструмента
выполняется в рамках проекта Заявителем
или пользователем инструмента
•
Эти мероприятия выполняются пользователем
инструмента
Т-1
Т-10
Все: Применимы
Пользователю инструмента следует учесть все рекомендации разделов с 11.3.3.1 по
11.3.3.4 для Эксплуатационных требований к инструменту, Плана квалификации инструмента,
Указателя конфигурации инструмента и Итогового заключения об инструменте.
64
Руководство Р-330
11.3.3.1 Эксплуатационные требования к инструменту
Пользователь инструмента должен использовать Эксплуатационные требования к
инструменту от разработчика, чтобы определить, отвечает ли инструмент потребностям ЖЦ
ПО. По ситуации, пользователю инструмента следует ссылаться или встраивать данные
Эксплуатационных требований к инструменту от разработчика в Эксплуатационные
требования к инструменту и предоставить специфическую информацию, ограничения и т.п.
для ЖЦ ПО.
Назначение Эксплуатационных требований к инструменту - определить требования к
использованию инструмента в ЖЦ ПО. Эксплуатационные требования к инструменту
используются как основа для мероприятий верификации соответствия инструмента в
эксплуатационной среде инструмента.
Эксплуатационные требования к инструменту от разработчика должны включать как
минимум следующее:
•
Содержимое Эксплуатационных требований к инструменту или ссылку на применимое
содержимое Эксплуатационных требований к инструменту от разработчика.
•
Описание контекста использования инструмента, включая интерфейсы с другими
инструментами и интеграцию выходных файлов инструмента в итоговое ПО (см.
раздел 10.3.1 ,а).
•
Описание эксплуатационной среды инструмента (в которой будет устанавливаться
инструмент). Сюда входит также анализ предполагаемой эксплуатационной среды
(сред) инструмента, включенной в Эксплуатационные требования к инструменту от
разработчика (см. раздел 10.3.1,Ь).
•
Описание использования инструмента в эксплуатации (включая выбираемые опции,
значения параметров, командную строку) (см. раздел 10.3.1,h).
•
Описание
эксплуатационных входных данных
инструмента
в конкретной
эксплуатационной среде. Назначение данного описания - определить все возможные
входные данные и их структуру. Полнота и точность настоящего описания позволят
осуществить разработку данных эксплуатационной верификации инструмента,
которые включают использование инструмента в эксплуатации (см. раздел 10.3.1,с).
•
Требования к характеристикам,
инструмента (см. раздел 10.3.1 ,i).
указывающие
поведение
выходных
данных
11.3.3.2 План квалификации инструмента
В дополнение к информации, предоставленной в разделе 10.1.2, План квалификации
инструмента должен предоставлять:
•
ссылку на План квалификации инструмента от разработчика;
•
разделение ответственности между разработчиком инструмента и пользователем
инструмента в части целей и мероприятий.
11.3.3.3 Указатель конфигурации инструмента
В дополнение к информации, предоставленной
конфигурации инструмента должен предоставлять:
в
разделе
10.1.11,
•
ссылку на Указатель конфигурации инструмента от разработчика;
•
идентификацию данных, создаваемых пользователем инструмента.
Указатель
Руководство Р-330
65
11.3.3.4 Итоговое заключение об инструменте
В дополнение к информации, предоставленной в разделе 10.1.15, Итоговое заключение
об инструменте должно предоставлять:
•
ссылку на Итоговое заключение об инструменте от разработчика;
•
идентификацию всех опций, которые должны использоваться во время работы
инструмента;
•
демонстрацию (анализ и/или рассмотрение) того, что операция установки
инструмента и операция конфигурирования инструмента, выполняемые пользова­
телем инструмента, соответствуют рекомендациям руководства пользователя,
предоставляемого разработчиком инструмента;
•
отклонение от Плана квалификации инструмента в разделении ответственности
между разработчиком инструмента и пользователем инструмента в части целей и
мероприятий;
•
результаты мероприятий верификации инструмента, выполняемых как разработчиком
инструмента, так и пользователем инструмента.
Пользователь инструмента должен предоставить Сертифицирующему органу доступ ко
всем данным квалификации. Обычно пользователь инструмента будет встраивать или
ссылаться на предварительные данные, предоставляемые разработчиком инструмента, в
своих итоговых данных ЖЦ квалификации инструмента.
11.3.4 Координация мероприятий разработчика и пользователя инструмента
Цели, которые выполняются разработчиком инструмента, будут оцениваться
пользователем инструмента, поскольку пользователь инструмента в конечном итоге отвечает
за квалификацию.
План квалификации инструмента должен ссылаться на План квалификации инструмента
от разработчика и предоставлять средства для координации. Это же верно для Итогового
заключения об инструменте и Указателя конфигурации инструмента, ссылающихся на
Итоговое заключение об инструменте от разработчика и Указатель конфигурации
инструмента от разработчика.
Во время рассмотрения соответствия инструмента пользователь инструмента должен
проанализировать отчет о рассмотрении соответствия разработчиком и проверить, если
необходимо, состояние корректирующих действий, появившихся во время этого рассмотрения.
11.4 История эксплуатации
Как только Заявитель определил или разработал Эксплуатационные требования к
инструменту, история эксплуатации инструмента может быть использована для достижения
целей настоящего документа. Если история эксплуатации используется, ее релевантность
должна быть обоснована. История эксплуатации оценивается в индивидуальном порядке.
Некоторые возможные причины использования истории эксплуатации включают:
•
инструмент был использован, но не все данные, необходимые для квалификации,
доступны;
•
требуется увеличить уровень квалификации инструмента;
•
некоторые аспекты инструмента
существующих данных;
•
требуется увеличить уверенность в соответствии инструмента Эксплуатационным
требованиям к инструменту.
трудны
для
анализа
при
использовании
66
Руководство Р-330
11.4.1 Аспекты истории эксплуатации инструмента
Необходимо оценивать следующие аспекты истории эксплуатации инструмента:
a.
Доступные данные. Определить доступные данные по истории эксплуатации
инструмента и их релевантность для демонстрации соответствия Эксплуатационным
требованиям к инструменту.
b.
Регистрация проблем. Для поддержки истории эксплуатации требуются как минимум
регистрация проблем и управление конфигурацией инструмента. Регистрация
проблем должна включать непротиворечивое определение проблем, классификацию
проблем, отслеживание в отношении версий инструмента, отслеживание в отношении
решений и определение области применения системы регистрации проблем
(например, количество участвующих Заявителей).
c.
Среда. Сходство эксплуатационной среды инструмента, в которой собирались данные
истории эксплуатации инструмента, с той, что должна использоваться в предлагаемом
npoeicre, является критичным для получения зачета на основании истории
эксплуатации инструмента. Анализ среды должен включать любые ограничения на
использование инструмента, накладываемые ограничениями самого инструмента.
d-
Эксплуатация. Режимы работы или настройки, взаимодействие с пользователями, а
также процедуры являются основой для демонстрации релевантности истории
эксплуатации инструмента для предлагаемого применения инструмента. Следует
также учитывать уровень опыта и/или подготовки в использовании данного
инструмента со стороны Заявителя. Анализ эксплуатации должен включать любые
ограничения на использование инструмента, накладываемые Заявителем.
e.
Стабильность и завершенность. Следует оценить историю изменений инструмента,
чтобы определить стабильность в эксплуатации и зрелость. Следует выполнить
анализ, чтобы оценить влияние изменения на инструмент или эксплуатационную
среду инструмента, чтобы определить, следует ли начать историю эксплуатации
заново.
f.
Эксплуатация приложений. История эксплуатации приложений, разработанных с
использованием инструмента, может предоставить дополнительное обоснование для
стабильности и зрелости инструмента.
11.4.2 Мероприятия истории эксплуатации инструмента
Мероприятия по использованию истории эксплуатации инструмента включают:
a.
Заявитель должен показать, что данные истории эксплуатации инструмента
демонстрируют соответствие Эксплуатационным требованиям к инструменту.
b.
Заявитель должен продемонстрировать, что эксплуатационная среда инструмента
была определена, задокументирована и поддерживалась в течение периода
использования, для которого предполагается получение сертификационного зачета.
c.
Заявитель должен продемонстрировать, что в течение истории эксплуатации
инструмента была организована регистрация проблем, чтобы гарантировать, что:
d.
1)
имеются в распоряжении репрезентативные данные;
2)
проблемы инструмента и результирующие действия были зарегистрированы;
3)
проблемы инструмента были проанализированы, чтобы определить, как они
случились и какие проблемы были устранены. Этот анализ должен
продемонстрировать, имеет ли зарегистрированная проблема инструмента
возможное влияние на выходные данные инструмента и существует ли
приемлемое решение проблемы.
Должны быть определены изменения конфигурации инструмента в течение периода
сбора истории эксплуатации инструмента и проанализировано их влияние, чтобы
подтвердить стабильность и зрелость инструмента.
Руководство Р-330
67
e.
Должен быть выполнен анализ эксплуатационной среды инструмента,
убедиться в том, что историю эксплуатации инструмента можно применять.
чтобы
f.
История эксплуатации инструмента может использоваться для поддержки
квалификации подмножества инструмента. Следует учитывать инструктивные
материалы для квалификации многофункциональных инструментов (см. раздел 11.1).
д.
В Плане сертификации ПО или в Плане квалификации инструмента должно быть
описано планируемое использование инструмента и включать следующее:
1)
сводку данных истории эксплуатации;
2)
обоснование использования истории эксплуатации инструмента
соотносится с уровнем квалификации инструментов;
3)
анализ релевантности среды истории эксплуатации инструмента;
4)
доступность системы регистрации проблем в течение истории эксплуатации
инструмента;
5)
историю изменений
инструмента.
инструмента
для
оценки
стабильности
и как оно
и
зрелости
11.5 Альтернативные методы квалификации инструментов
Заявители могут решить использовать альтернативный метод для квалификации
инструмента. Потенциальные альтернативные методы включают, в числе прочих,
тестирование по методу полного перебора входных данных, формальные методы и
разнородные инструменты (например, два или более инструмента, разработанных отдельно,
которые удовлетворяют тем же самым эксплуатационным требованиям).
Альтернативный метод должен рассматриваться в рамках всего процесса ЖЦ ПО. Усилия,
затрачиваемые на получение сертификационного зачета альтернативного метода, зависят от
уровня ПО и от влияния, которое оказывает альтернативный метод на процессы ЖЦ ПО.
Мероприятия по использованию альтернативных методов включают:
a.
Планы создания инструмента должны описывать применение альтернативного
метода для процессов и выходных данных ЖЦ инструмента. Затем альтернативный
метод должен обеспечить подтверждение правильности реализации метода.
b.
Заявитель должен описать в Плане сертификации ПО или Плане квалификации
инструмента и согласовать с сертифицирующим органом:
1)
влияние предлагаемого альтернативного метода на процессы ЖЦ ПО;
2)
влияние предлагаемого альтернативного метода на данные ЖЦ ПО;
3)
обоснование (включая описание, правомерность и подтверждение) использования
альтернативного метода, которое демонстрирует, как достигаются цели
настоящего документа.
68
Руководство Р-330
ПРИЛОЖЕНИЕ А
ЦЕЛИ КВАЛИФИКАЦИИ ИНСТРУМЕНТА
В таблицах сведены вместе цели настоящего документа посредством указания
применимости каждой цели по уровням квалификации инструментов, должны ли эти цели
реализовываться независимо, выходные данные, которые получаются в результате
достижения этих целей, а также категории контроля для каждой единицы данных ЖЦ
инструмента. Следует отметить, что мероприятия, которые определены для достижения этих
целей, также включены в эти таблицы для справки (в колонке «Мероприятие»).
Эти таблицы не должны быть использованы в качестве проверочных перечней. Эти
таблицы не отражают все аспекты соответствия настоящему документу. Для полного
понимания смысла указаний настоящего документа необходимо изучить документ полностью.
Ниже представлен краткий обзор каждой таблицы.
•
Таблица Т-0 относится к процессам эксплуатации инструмента, включая процесс
разработки Эксплуатационных требований к инструменту, процесс эксплуатационной
интеграции инструмента и процесс эксплуатационной верификации и валидации.
•
Таблица Т-1 относится к процессу планирования инструмента.
•
Таблица Т-2 относится к целям, применимым к процессам разработки инструмента.
•
Таблицы с Т-3 по Т-7 относятся к процессам верификации инструмента.
•
Таблица Т-8 относится к процессу управления конфигурацией инструмента и
применяется ко всему ЖЦ инструмента.
•
Таблица Т-9 относится к процессу гарантии качества инструмента и применяется ко
всему ЖЦ инструмента.
•
Таблица Т-10 относится к процессу взаимодействия с Сертифицирующим органом по
квалификации инструмента.
Приведенные ниже условные обозначения относятся к колонкам «Применимость по
уровням квалификации инструментов» и «Категория контроля по уровням квалификации
инструментов» для всех таблиц:
Цель должна быть достигнута с помощью независимого
мероприятия
УСЛОВНЫЕ
ОБОЗНАЧЕНИЯ:
О
Пустая
ячейка
Цель должна быть достигнута
Цель достигается по усмотрению Заявителя
©
Данные достигают целей категории контроля 1 (КК1)
Ф
Данные достигают целей категории контроля 2 (КК2)
Руководство Р-330
69
Цель
Описание
| Пункт
Мероприя­
тие
Таблица Т-0. Процессы эксплуатации инструмента
Применимость
по уровням
квалификации
инструментов
Пункт
1
2
3
4
5
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
Описание
Пункт
1
10.1.1
Ф Ф Ф Ф Ф
2 3 4 5
Процесс планирования
1
Установлена
необходимость
квалификации
инструмента
4.1
(Приме­
О О
чание 1]
о
Информация,
касающаяся
О О инструмента,
в Плане
сертификации ПО
Процесс определения «Эксплуатационных требований к инструменту»
Определены
' Эксплуатационные
2
требования
к инструменту
5.1,1,а
5.1.2,а
5.1.2,b
5.1.2,с
Эксплуатаци онны е
О
о о О о требования
10.3.1
Ф Ф Ф Ф Ф
10.2.4
Ф Ф Ф Ф Ф
10.3.2
Ф Ф Ф Ф Ф
к инструменту
Процесс эксплуатационной интеграции инструмента
3
Исполняемый
объектный код
инструмента
установлен в
эксплуатационную
среду инструмента
5.3.1,а
5.3.2,а
5.3.2, b
5.3.2,с
О
о о
Исполняемый
объектный код
инструмента
О О
Протокол
об установке
инструмента
Процесс эксплуатационной верификации и валидации инструмента
4
Эксплуатационные
требования
к инструменту
полны, точны,
проверяемы и
непротиворечивы
6.2.1,а
Работа
инструмента
соответствует
Эксплуатационным
требованиям
к инструменту
6.2.1,Ь
6
Эксплуатационные
требования
к инструменту
достаточны
и корректны
6.2.1,аа
7
Потребности
процессов ЖЦ ПО
удовлетворены
данным
инструментом
5
6.2.1,bb
6.2.2,а
6.2.2,с
•
•
6.2.2,Ь •
6.2.2,с
О
о о О
•
•
О
О
о о
о о
о о о о
Результаты
эксплуатационной
верификации
и валидации
инструмента
Примеры и
Процедуры
эксплуатационной
верификации
и валидации
инструмента
Результаты
эксплуатационной
верификации
и валидации
инструмента
Результаты
эксплуатационной
верификации
и валидации
инструмента
Примеры и
Процедуры
эксплуатационной
верификации
и валидации
инструмента
Результаты
эксплуатационной
верификации
и валидации
инструмента
10.3.4
Ф Ф Ф Ф
10.3.3
Ф Ф Ф Ф Ф
10.3.4
Ф Ф Ф ф Ф
10.3.4
Ф Ф Ф Ф
10.3.3
ф Ф Ф Ф Ф
10.3.4
Ф Ф Ф Ф Ф
Примечание. 1. Данное мероприятие является частью процесса планирования создания инструмента
и описывается в настоящем документе не полностью. См. руководящий документ
______________ соответствующей предметной области (например, КТ-178С или КТ-278А).___________
70
Руководство Р-330
Пункт
1 2
Описание
Пункт
1
2
План
квалификации
инструмента
10.1.2
Ф Ф Ф
План разработки
инструмента
10.1.3
Ф © (D
Определены
процесс разработки
и интегральные
процессы
инструмента
4.3,а
2
Определены
критерии перехода,
взаимосвязи и
порядок процессов
создания
инструмента
4.3, Ь
4.4,а
О ОО
План верификации
инструмента
10.1.4
Ф Ф © ©
3
Выбрана и
определена среда
ЖЦ инструмента
4.3,с
4.4,с
О о о
План УК
инструмента
10.1.5
Ф Ф © ©
4
Дополнительные
аспекты
рассмотрены
4.3,d
4.4,а
4.4,е
о о о о
План ГК
инструмента
10.1.6
Ф Ф © ©
Стандарты
на разработку
требований
к инструменту
10.1.7
©
©
Стандарты
на проектирование
инструментов
10.1.8
©
4
©
Стандарты
на кодирование
инструмента
10.1.9
©
3
©
5
©
3 4
©
Пункт
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
©
Описание
Применимость
по уровням
квалификации
инструментов
©
Цель
Мероприя­
тие
Таблица Т-1. Процесс планирования инструмента
1
4.4,а
О ООо
Стандарты
разработку
5 на
инструмента
4.3,е
4.4,b
ОО о
определены
6
Планы создания
иснструмента
соответствуют
настоящему
документу
4.3,f
4.4,d
о о о
Результаты
верификации
инструмента
10.2.6
© © @
7
Разработка и
рассмотрение
планов создания
инструмента
скоординированы
4.3,g
4.4,d
о о о
Результаты
верификации
инструмента
10.2.6
© ©
5
Руководство Р-330
71
Таблица Т-2. Процессы разработки инструмента
Выходные данные
©
Применимость
по уровням
квалификации
инструментов
Категория
контроля
по уровням
квалификации
инструмента
Пункт
1 2
Описание
Пункт
1
Требования
к инструменту
10.2.1
© Ф Ф Ф
Данные
трассировки
10.2.7
Ф Ф Ф Ф
Требования
к инструменту
10.2.1
Ф © Ф Ф
Описание проекта
инструмента
10.2.2
Ф Ф Ф
Описание проекта
инструмента
10 . 2.2
Данные
трассировки
10.2.7
Описание проекта
инструмента
10.2.2
Исходный код
инструмента
10.2.3
Данные
трассировки
10.2.7
к
S
с ®
Цель
Описание
Разработаны
Требования
к инструменту
Пункт
3
4
5.2.1.2,а
5.2.1.2,Ь
5.2.1.2,с
5.2.1.2,d
5.2.1.2,е
5.2.1.2,f
5.2.1.1,а
О О О
5.2.1.2,g
5.2.1.2,h
5.2.1.2,i
5.2.1.2,j
5.2.1.2,k
5.2.5,a
Определены
производные
требования
к инструменту
5.2.1.1 ,Ь 5.2.1.2,h
Разработана
архитектура
инструмента
5.2.2.2,а
5.2.2.2,b
5.2.2.1,а 5.2.2.2,е
5.2.2.2,f
5.2.2.2,g
Требования
низкого уровня
разработаны
5.2.2.2,с
5.2.2.2,е
5.2.2.1,Ь
5.2.2.2,f
5.2.5,b
О О О
Производные
требования
низкого уровня
к инструменту
определены
5.2.2.1,с
5.2.2.2,с
5.2.2.2,d
О О О
Исходный код
разработан
5.2.3.2,а
5.2.3.2,b
5.2.3.1,а 5.3.3.2,с О О О
5.2.3.2,d
5.2.5,с
О О О
О
О О
5
2
3
4
Ф Ф Ф
Исполняемый
объектный код
инструмента
создан
5.2.4.1,а
5.2.4.2,а
5.2.4.2,b
О О О
Исполняемый
объектный код
инструмента
10.2.4
Ф Ф Ф Ф
Установлен
инструмент
в среду(ы)
верификации
инструмента
5.2.4.1,Ь 5.2.4.2,с
О О О О
Исполняемый
объектный код
инструмента
10.2.4
Ф Ф Ф Ф
5
Руководство Р-330
72
Мероприя­
тие
Таблица Т-3. Верификация выходных данных процессов разработки
Требований к инструменту
Применимость
по уровням
квалификации
инструментов
Пункт
Пункт
1
2
3
Требования
к инструменту
соответствуют
1
Эксллуата цион ным
требованиям
к инструменту
6.1.3.1,а
6.1.3.1
•
•
о о
Результаты
верификации
инструмента
10.2.6
© © © ©
2
Требования
к инструменту
правильны
и непротиворечивы.
6.1.3.1,Ь
6.1.3.1
•
•
о о
Результаты
верификации
инструмента
10.2.6
© © ©
3
Определены
требования
на совместимость
с эксплуатационной
средой инструмента
6.1.3.1,с
6.1.3.1
•
•
о о
Результаты
верификации
инструмента
10.2.6
© © © ©
4
Требования
к инструменту
определяют поведение
инструмента в ответ
на условия с ошибками
6.1.3.1,d
6.1.3.1
•
•
О
о
Результаты
верификации
инструмента
10.2.6
© © © ©
5
Требования
к инструменту
определяют инструкции
пользователю и
сообщения об ошибках
6.1.3.1 ,е
6.1.3.1
•
•
О
о
Результаты
верификации
инструмента
10.2.6
© © © ©
6
Требования
к инструменту
проверяемы
6.1.3.1,f
6.1.3.1
О О
о о
Результаты
верификации
инструмента
10.2.6
© © © ©
7
Требования к
инструменту
соответствуют
6.1.3.1 ,g
Стандартам
на разработку требований
к инструменту
6.1.3.1
О
Результаты
верификации
инструмента
10.2.6
© © ©
8
Требования
к инструменту
трассируемы
на Эксплуатационные
требования
к инструменту
6.1.3.1,h
6.1.3.1
О О
о О
Результаты
верификации
инструмента
10.2.6
© © ©
9
Алгоритмы правильны
6.1.3.1 ,i
6.1.3.1
•
о о
Результаты
верификации
инструмента
10.2.6
© © © ©
Цель
Описание
4
о о
•
5
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
Описание
Пункт
1 2
3
4
©
©
5
Руководство Р-330
73
Мероприя­
тие
Таблица Т-4. Верификация выходных данных процесса проектирования инструмента
Применимость
по уровням
квалификации
инструментов
Пункт
Пункт
1
2
3
6.1.3.2,а
6.1.3.2
•
•
2
Требования низкого
уровня правильны
и непротиворечивы
6.1.3.2,b
6.1.3.2
•
•
3
Требования низкого
уровня проверяемы
6.1.3.2,с
6.1.3.2
О О
6.1.3.2,d
6.1.3.2
О
6.1.3.2,е
6.1.3.2
Цель
Описание
Описание
Пункт
1
О
Результаты
верификации
инструмента
10.2.6
Ф Ф ф
о
Результаты
верификации
инструмента
10.2.6
Ф Ф Ф
Результаты
верификации
инструмента
10.2,6
Ф ф
о о
Результаты
верификации
инструмента
10.2.6
Ф Ф Ф
О О
о
Результаты
верификации
инструмента
10.2.6
Ф Ф Ф
4
Требования низкого
уровня соответствуют
1 Требованиям
к инструменту
4
5
Требования низкого
уровня к инструменту
соответствуют
Стандартам
на проектирование
инструмента
Требования низкого
уровня трассируемы
на Требования
к инструменту
5
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
2
3
4
6
Алгоритмы правильны
6.1.3.2,f
6.1.3.2
•
о
о
Результаты
верификации
инструмента
10.2.6
Ф Ф Ф
7
Архитектура
инструмента
совместима
с Требованиями
к инструменту
6.1.3.3,а
6.1.3.3
•
О
о
Результаты
верификации
инструмента
10.2.6
Ф
8
Архитектура
инструмента
непротиворечива
6.1.3.3,Ь
6.1.3.3
о
О О
Результаты
верификации
инструмента
10.2.6
Ф Ф Ф
9
Архитектура
инструмента
соответствует
Стандартам
на проектирование
инструмента
6.1.3.3,с
6.1.3.3
о О О
Результаты
верификации
инструмента
10,2.6
ф Ф Ф
Подтверждены
механизмы защиты,
10
если таковые
используются
6.1.3.3,d
6.1.3.3
•
о о о
Результаты
верификации
инструмента
10.2.6
Ф © Ф Ф
Интерфейс с внешними
компонентами
6.1.3.3,е
11
определен правильно
и полностью
6.1.3.3
•
О
Результаты
верификации
инструмента
10.2.6
Ф Ф
Ф
5
Руководство Р-330
74
Мероприя­
тие
Таблица Т-5. Верификация выходных данных процессов кодирования и интеграции
Применимость
по уровням
квалификации
инструментов
Пункт
Пункт
1
2
3
6.1.3.4,а
6.1.3.4
•
•
о
Результаты
верификации
инструмента
10.2.6
© © ©
2
Исходный код
инструмента
соответствует
архитектуре
инструмента
6.1,3.4,Ь
6.1.3.4
•
О
о
Результаты
верификации
инструмента
10.2.6
© © @
3
Исходный код
инструмента
проверяем
6.1.3.4,с
6.1.3.4
О
о
Результаты
верификации
инструмента
10.2.6
©
4
Исходный код
инструмента
соответствует
Стандартам
на кодирование
инструмента
6.1.3.4,d
6.1.3.4
Оо о
Результаты
верификации
инструмента
10.2.6
© © ©
5
Исходный код
инструмента
трассируем
на требования низкого
уровня инструмента
6.1.3.4,е
6.1.3.4
О
о О
Результаты
верификации
инструмента
10.2.6
© © ©
6.1.3.4,f
6.1.3.4
• Оо
Результаты
верификации
инструмента
10.2.6
©
6.1.3.5,а
6.1.3.5
о о о
Результаты
верификации
инструмента
10.2.6
© © ©
Цель
Описание
Исходный код
инструмента
1 удовлетворяет
требованиям низкого
уровня инструмента
Исходный код
6 правилен и
непротиворечив
7
Выходные данные
процесса интеграции
инструмента полны
и правильны
4
5
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
Описание
Пункт
1
2
3
©
© ©
4
5
Руководство Р-330
75
Цель
Описание
Исполняемый
объектный код
инструмента
1
удовлетворяет
Требованиям
к инструменту
2
3
4
Робастность
Исполняемого
объектного кода
инструмента
доказана по
Требованиям
к инструменту
Пункт
6.1.4.1 ,а
6.1.4.1 ,Ь
Исполняемый
объектный код
инструмента
6.1.4.1.C
удовлетворяет
требованиям низкого
уровня
Робастность
Исполняемого
объектного кода
доказана
по требованиям
низкого уровня
6.1.4.1,d
Мероприя­
тие
Таблица Т-6. Тестирование выходных данных процесса интеграции
Применимость
по уровням
квалификации
инструментов
Пункт
1
6.1.4.2,а
6.1.4.2,Ь
6.1.5
6.1.4.2,а
6.1.4.2,с
6.1.4.2,d
6.1.5
2
3
4
ООо О
ОО о О
6.1.4.2,а
6.1.4.2,Ь •
6.1.5
6.1.4.2,а
6.1.4.2,с
•
6.1.4.2,d
6.1.5
•
о
о о
5
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
Описание
Пункт
1
Примеры и
Процедуры
верификации
инструмента
2
10.2.5
Ф Ф © ©
Результаты
верификации
инструмента
10.2.6
© © © ©
Данные
трассировки
10.2.7
Ф Ф © ©
Примеры и
Процедуры
верификации
инструмента
10.2.5
Ф Ф © ©
Результаты
верификации
инструмента
10.2.6
© © © ©
Данные
трассировки
10.2.7
Ф Ф © ©
Примеры и
Процедуры
верификации
инструмента
10.2.5
Ф Ф ©
Результаты
верификации
инструмента
10.2.6
© © ©
Данные
трассировки
10.2.7
Ф Ф ©
Примеры и
Процедуры
верификации
инструмента
10.2.5
Ф Ф ©
Результаты
верификации
инструмента
10.2.6
© © ©
Данные
трассировки
10.2.7
Ф Ф ©
3
4
5
Руководство Р-330
76
Мероприя­
тие
Таблица Т-7. Верификация выходных данных процесса тестирования инструмента
Применимость
по уровням
квалификации
инструментов
Описание
Пункт
Пункт
1
2
3
1
Тестовые процедуры
правильны
6.1.4.4,b
6.1.4.4
•
О
о
Результаты
верификации
инструмента
10.2.6
© ©
2
Результаты тестов
правильны
и расхождения
объяснены
6.1.4.4,с
6.1.4.4
О
Оо О
Результаты
верификации
инструмента
10.2.6
© © © ©
6.1.4.4,а
6.1.4.4
•
О О
о
Результаты
верификации
инструмента
10.2.6
©
о о
Результаты
верификации
инструмента
10.2.6
© © ©
Цель
Достигнуто покрытие
3 тестами Требований
к инструменту
4
5
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
Описание
Пункт
1
2
3
©
4
© © ©
6.1.4.4,а
6,1.4.4
•
5
Анализ тестирования
на основе требований
внешних компонентов
выполнен
6.1.4.3.1
6.1.4.3.2
6.1.4.3.3
•
Результаты
верификации
инструмента
10.2.6
©
6
Анализ результатов
тестирования на
основе требований
(покрытия структуры
согласно уровню
«Модифициро­
ванного покрытия
условий/решений
(MC/DC)») выполнен
6.1.4.3.1
•
Результаты
верификации
инструмента
10.2.6
©
7
Анализ результатов
тестирования на
основе требований
(покрытия структуры
согласно уровню
покрытия решений)
выполнен
6.1.4.3.1
6.1.4.3.2
•
6.1.4.3.3
•
Результаты
верификации
инструмента
10.2.6
© ©
8
Анализ результатов
тестирования
на основе требований
(покрытия структуры
согласно уровню
покрытия операторов)
выполнен
6.1.4.3.1
6.1.4.3.2
•
6.1.4.3.3
•
о
Результаты
верификации
инструмента
10.2.6
© © ©
9
Анализ результатов
тестирования
на основе требований
{связность по данным
и по управлению)
выполнен
6.1.4.3.1
6.1.4.3.2
•
6.1.4.3.3
•
о
Результаты
верификации
инструмента
10.2.6
© © ©
CD
см со
со со
Достигнуто покрытие
тестами требований
низкого уровня
CD
4
5
Руководство Р-330
77
Цель
Описание
Пункт
Мероприя­
тие
Таблица Т-8. Процесс управления конфигурацией инструмента
Применимость
по уровням
квалификации
инструментов
Пункт
1
2
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
3
4
Описание
Пункт
1
о
Записи УК
О О
инструмента
10.1.13
Ф ф <2> Ф ф
Указатель
конфигурации
инструмента
10.1.11
©
Записи УК
инструмента
10.1.13 <2> ф Ф
Сообщения
о проблемах
инструмента
10.1.12
ф Ф Ф Ф
5
2
3
4
5
1
Единицы конфигурации
идентифицированы
2
Базовые версии
и трассируемость
установлены
7,1 ,Ь
Организованы
регистрация проблем,
управление
изменениями,
рассмотрение
изменении и учет
состояния
конфигурации
7.1,с
7.1,d
7.1,е
7.1,f
7.2.3
7.2.4
7.2.5
7.2.6
О
Записи УК
инструмента
10.1.13
Ф © Ф Ф
Организованы
хранение,
воспроизведение
и выпуск
7.1,g
7.2.7
УК
о о о о о Записи
инструмента
10.1.13
Ф Ф ф Ф ©
Записи УК
инструмента
10.1.13
Ф Ф Ф Ф
Указатель
конфигурации
среды ЖЦ
инструмента
10.1.10 © Ф
4
5
Организован контроль
среды ЖЦ инструмента
7.1,а
7.1, h
7.2.1
7.2.2
7.4
О О
О
О
о О о
Ф Ф ©
Ф
о о о
о о о
Ф
Руководство Р-330
78
Мероприя­
тие
Таблица Т-9. Процесс гарантии качества инструмента
Применимость
по уровням
квалификации
инструментов
Описание
Пункт
Пункт
1 2
3
Получена гарантия того,
что планы и стандарты
создания инструмента
разработаны
1
и рассмотрены
на предмет соответствия
друг другу и настоящему
документу
8.1,а
8.2,b
8.2,h
•
•
8.1,Ь
8.2,а
8.2,с
8.2,d
8.2,f
8.2,h
8.2,i
•
•
•
Цель
•
2
Получена гарантия того,
что процессы ЖЦ
инструмента
соответствуют
утвержденным планам
3
Получена гарантия того,
что процессы ЖЦ
инструмента
соответствуют
утвержденным
стандартам
8.1 ,Ь
8.2,a
8.2,с
8.2,d
8.2,f
8.2,h
8.2,i
4
Получена гарантия того,
что критерии перехода
для процессов ЖЦ
инструмента
удовлетворяются
8.1,с
8.2,e
8.2,h
•
•
•
5
Рассмотрение
соответствия
инструмента выполнено
8.1,d
8.2,g
8.2,h
8.3
•
•
•
Примечание.
4
5
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
Описание
1 2
Пункт
3
4
5
Записи ГК
инструмента
10.1.14 © © ©
Записи ГК
инструмента
[Примечания
1 и 2]
10.1.14 © © © © ©
Записи ГК
инструмента
10.1.14 © © ©
[Примечание 2]
Записи ГК
инструмента
•
•
10.1.14 © © ©
Записи ГК
инструмента
10.1.14 © © © © ©
[Примечание 1]
1. Для уровня квалификации инструментов TQL-5 Записи гарантии
инструмента могут быть частью Записей гарантии качества ПО.
2. Содержимое утверждаемых планов и стандартов создания инструмента
меняется в зависимости от уровня квалификации инструментов.
качества
Руководство Р-330
79
2
3
4
5
Ф Ф Ф Ф Ф
©
10.1.16
©
Ф
Ф
©
10.1.11
Ф
©
Ф
Ф
©
10.1.17
Ф
©
Ф
©
10.1.15
©
Ф
©
©
10.1.16
Ф
©
Ф
©
10.1.2
Ф
©
Ф
©
10.1.1
©
10.1.2
10.1.1
©
©
О О о о о
Информация
относительно
инструмента
в Итоговом
заключении о ПО
1
©
О О О о о
Информация
относительно
инструмента
в Итоговом
заключении о ПО
Итоговое
заключение
об инструменте
[Примечание 2]
Информация
относительно
инструмента
в Указателе
конфигурации среды
ЖЦ ПО
Указатель
конфигурации
инструмента
[Примечание 3]
Пункт
©
о о
Описание
Информация
относительно
инструмента в Плане
О О сертификации ПО
План квалификации
инструмента
[Примечание 1]
Информация
относительно
инструмента в Плане
О о сертификации ПО
План квалификации
инструмента
[Примечание 1]
©
Q.O.d
О
5
©
9.0,с
9.0,е
О О о
4
©
Примечание.
9.0
9.0,b
3
©
4
Влияние известных
проблем на
Эксплуатационные
требования
к инструменту
идентифицировано
и проанализировано
9.0
9.0,а
2
©
3
Обоснование
соответствия
приведено
9.0
1
©
2
Средства
определения
соответствия
требованиям
предложены
и согласование
получено
9.0
Пункт
©
Установлены
взаимодействие и
взаимопонимание
1
между Заявителем
и Сертифицирующим
органом
Пункт
Выходные данные
Категория
контроля
по уровням
квалификации
инструмента
©
Описание
Применимость
по уровням
квалификации
инструментов
©
Цель
Мероприя­
тие
Таблица Т-10. Процесс взаимодействия с Сертифицирующим органом для квалификации
инструмента
1. Для уровня квалификации инструмента TQL-5 - может быть удовлетворено Планом
сертификации ПО.
2. Для уровня квалификации инструмента TQL-5 ~ может быть удовлетворено
Итоговым заключением о ПО.
3. Для уровня квалификации инструмента TQL-5 ~ может быть удовлетворено
Указателем конфигурации среды ЖЦ ПО.
80
Руководство Р-330
ПРИЛОЖЕНИЕ В
СОКРАЩЕНИЯ И ТОЛКОВЫЙ СЛОВАРЬ ТЕРМИНОВ
Сокращение Значение
(англ.)
(англ.)
Значение
(РУС.)
Сокращение
(РУС.)
ACG
Autocode Generator
Генератор автокода
AL
Assurance Level
Уровень гарантии
СС1
Control Category 1
Категория контроля 1
КК1
СС2
Control Category 2
Категория контроля 2
КК2
CNS/ATM
Communication, Navigation,
Surveillance, and Air Traffic
Management
Связь, навигация,
наблюдение и организация
воздушного движения
СНН/УВД
COTS
Commercial Off-The-Shelf
Покупной готовый
DO-178B &
DO-178C
RTCA document entitled
“Software Considerations in
Airborne Systems and
Equipment Certification”
Документ компании RTCA,
названный «Требования к
программному обеспечению
бортовой аппаратуры и
систем при сертификации
авиационной техники»
DO-278A
RTCA document entitled
“Software Integrity Assurance
Considerations for
Communication, Navigation,
Surveillance, and Air Traffic
Management (CNS/ATM)
Systems”
Документ компании RTCA,
названный «Вопросы гарантии
сохранности программного
обеспечения систем связи,
навигации, контроля и
управления воздушным
движением (CNS/ATM)»
D0-330
RTCA document entitled
“Software Tool Qualification
Considerations”
Руководство по квалификации Р-330
программных инструментов
EUROCAE
European Organisation for Civil
Aviation Equipment
Европейская организация
по оборудованию
для гражданской авиации
FAQ
Frequently Asked Question
Часто задаваемые вопросы
MC/DC
Modified Condition / Decision
Coverage
Модифицированное покрытие
условий/решений
PSAA
Plan for Software Aspects of
Approval
План одобрения ПО
PSAC
Plan for Software Aspects of
Certification
План сертификации ПО
RTCA
RTCA, Inc. is an association
of aeronautical organizations
in the United States
Компания RTCA, Inc. ассоциация авиационных
организаций Соединенных
Штатов Америки
SAE
Formerly known as Society of
Automotive Engineers
Ранее известное как
«Ассоциация инженеров
автомобилестроения»
SAS
Software Accomplishment
Summary
Итоговое заключение о ПО
SC-205
RTCA Special Committee #205
Специальный комитет № 205
компании RTCA
КТ-178В/
КТ-178С
81
Руководство Р-330
Сокращение Значение
(англ.)
(англ.)
Значение
(РУС.)
SCI
Software Configuration Index
Указатель конфигурации ПО
SECI
Software Life Cycle
Environment Configuration
Index
Указатель конфигурации
среды ЖЦ ПО
TAS
Tool Accomplishment Summary
Итоговое заключение
об инструменте
TCI
Tool Configuration Index
Указатель конфигурации
инструмента
тем
Tool Configuration Management
Управление конфигураций
инструмента
TOR
Tool Operational Requirements
Эксплуатационные
требования к инструменту
TQL
Tool Qualification Level
Уровень квалификации
инструмента
TQA
Tool Quality Assurance
План гарантии качества
инструмента
TQP
Tool Qualification Plan
План квалификации
инструмента
U.S.
United States
Соединенные Штаты Америки
V&V
Validation and Verification
Валидация и верификация
WG-71
EUROCAE Working Group #71
Рабочая группа № 71
EUROCAE
Сокращение
(РУС.)
82
Руководство Р-330
СЛОВАРЬ ТЕРМИНОВ
Приведенные ниже определения даны для терминов, используемых в тексте этого
документа.
Алгоритм (Algorithm) - конечный набор точно определенных правил, указывающих
последовательность действий для решения конкретной задачи.
Альтернативный метод (Alternative method) - другой подход к достижению одной или
нескольких целей настоящего документа.
Анализ покрытия (Coverage analysis) - процесс определения того, в какой степени
предложенные мероприятия процесса верификации ПО достигают его целей.
Анализ структурного покрытия (Structure coverage analysis) - оценка структуры кода,
включая интерфейсы, отработавшего во время тестирования на основе требований.
Архитектура инструмента (Tool architecture) - структура инструмента, выбранная для
реализации требований к инструменту.
Аудит (Audit) - независимая проверка процессов ЖЦ инструмента и их выходных данных
для подтверждения требуемых свойств.
Базовая версия (Baseline) - утвержденная зарегистрированная конфигурация одной или
нескольких единиц конфигурации, которая используется в качестве базы для дальнейшей
разработки и которая изменяется только через процедуры управления изменениями.
Валидация (Validation) корректными и полными.
процесс
установления
того,
что
требования
являются
Верификация (Verification) - оценка выходных данных процесса для подтверждения их
правильности и соответствия входным данным и стандартам, определенным для этого
процесса.
Внешние компоненты (External components) - компоненты программного обеспечения
инструмента, которые находятся вне пределов контроля разработчика данного инструмента.
Примеры включают примитивные функции, предоставляемые операционной системой или
библиотекой программ этапа исполнения компилятора, или функции, предоставляемые
покупной готовой (COTS) или библиотекой открытых программных средств.
Выпуск (Release) - действие, формально открывающее доступ к тиражируемой единице
конфигурации и разрешающее ее использование.
Гарантия (Assurance) - запланированные и систематические действия, направленные на
достижение соответствующего уровня доверия и получение свидетельств того, что продукт
или процесс удовлетворяет определенным требованиям.
Данные истории эксплуатации (Service history data) - данные исполнения средства,
собираемые в период истории эксплуатации.
Данные трассировки (Trace data) - данные, свидетельствующие о трассируемости
данных процессов ЖЦ разработки и верификации инструмента. Данные трассировки не
обязательно представляют собой специально созданные конкретные объекты. Связь между
объектами может быть показана, например, посредством соглашения об именах, либо с
помощью ссылок или указателей на данные ЖЦ инструмента, как встраиваемых внутрь
объектов, так и внешних по отношению к объектам.
Единица конфигурации (Configuration item) - 1) один или более программных
компонентов, которые в целях управления конфигурацией рассматриваются как единое
целое; 2) данные ЖЦ инструмента, которые в целях управления конфигурацией
рассматриваются как единое целое.
Жизненный цикл инструмента (Tool life cycle) - упорядоченный набор процессов,
определяемый организацией как достаточный и адекватный для производства поставочного
комплекта инструмента.
Руководство Р-330
83
Защита (Protection) - использование механизма, который гарантирует, что одна функция
инструмента не может отрицательно влиять на другую функцию инструмента.
Заявитель (Applicant) сертифицирующего органа.
лицо
или
организация,
запрашивающие
одобрение
от
Идентификационный номер (Part number) - набор чисел, букв или иных символов,
используемый для идентификации единицы конфигурации.
Идентификация конфигурации (Configuration identification) - 1) процесс обозначения
единиц конфигурации в системе и регистрации их характеристик; 2) утвержденная
документация, которая определяет единицу конфигурации.
Инструмент (Tool) - компьютерная программа или функциональная часть таковой,
используемая для осуществления помощи в разработке, проверке, анализе, создании или
модификации другой программы, данных или ее документации.
Интегральный процесс (Integral process) - процесс, который поддерживает процессы
разработки инструмента и другие интегральные процессы и который по этой причине
выполняется в течение всего ЖЦ инструмента. Интегральными процессами являются:
процесс верификации инструмента, процесс гарантии качества инструмента, процесс
управления конфигурацией инструмента и процесс взаимодействия Заявителя с
Сертифицирующим органом.
История эксплуатации продукта (Product service history) - смежный период времени,
в течение которого данный инструмент эксплуатируется в известной среде и в течение
которого регистрируются последовательные отказы.
Исходный код инструмента (Tool source code) - код, записанный на исходных языках,
таких как язык ассемблера и/или язык высокого уровня, в форме, пригодной для машинного
считывания, для ввода в ассемблер или компилятор.
Категория контроля (Control category) - набор процедур управления конфигурацией,
установленный для данных ЖЦ инструмента. Две категории, КК1 и КК2, определяют процессы
и мероприятия управления конфигурацией ПО, применяемые для управления данными ЖЦ
ПО.
Квалификация инструмента (Tool qualification) - процесс, необходимый для получения
сертификационного зачета для программного инструмента применительно к конкретной
бортовой системе.
Класс эквивалентности (Equivalence class) - такое подмножество значений входных
данных программы, что тестирование, выполненное для репрезентативного значения из этого
класса, эквивалентно тестированию с другими значениями из этого класса.
Код (Code) - представление конкретных данных или конкретной компьютерной программы
в символьной форме, такой как исходный код, объектный код или машинный код.
Компилятор (Compiler) - программа, транслирующая операторы исходного кода,
записанные на языке высокого уровня, таком как FORTRAN или Pascal, в объектный код.
Компонент (Component) - автономная часть, комбинация частей аппаратуры или ПО,
выполняющая отдельную функцию системы.
Критерии перехода (Transition criteria) - минимальные условия, определенные
процессом планирования инструмента, которые следует удовлетворить, чтобы перейти к
какому-либо процессу.
Логическая операция (Boolean operator) - операция с логическими операндами, которая
дает логический результат.
Мероприятие (Activity) - задачи, являющиеся средствами достижения цели.
Мертвый код (Dead code) - исполняемый объектный код или данные, которые
вследствие ошибки в процессе разработки инструмента не могут быть выполнены (код) или
использованы (данные) при любой нормальной конфигурации среды целевого вычислителя.
84
Руководство Р-330
Мертвый код не трассируется на требования инструмента. Приведенные ниже исключения
необходимы для реализации проекта или требований, но часто ошибочно классифицируются
как мертвый код: встроенные идентификаторы, структуры безопасного программирования для
улучшения робастности, а также отключенный код, такой как неиспользуемые функции
библиотеки.
Модифицированное покрытие условий и решений (Modified condition/decision
coverage) - каждая точка входа и выхода в программе пройдена хотя бы раз, каждое условие
в решении в программе было выбрано при всех возможных исходах хотя бы раз, каждое
решение в программе приняло все возможные значения хотя бы один раз, а также показано,
что каждое условие в решении независимо влияет на исход данного решения. Независимое
влияние некоторого условия на исход решения демонстрируется посредством: 1) изменения
только этого условия при неизменных всех других возможных условиях или 2) изменения
только этого условия при неизменных всех других возможных условиях, которые могут влиять
на исход.
Мониторинг (Monitoring) - действие по освидетельствованию или инспекционной
проверке выбранных тестов, инспекций или других мероприятий, а также протоколов этих
мероприятий, для того чтобы гарантировать, что рассматриваемое мероприятие находится
под контролем и что зарегистрированные результаты соответствуют ожидаемым. Мониторинг
обычно связан с мероприятиями, выполняемыми в течение длительного периода времени,
когда 100-процентное освидетельствование считается невозможным или ненужным. Тем не
менее такой мониторинг позволяет получить официальное удостоверение того, что
заявленное мероприятие выполнено так, как планировалось.
Независимость (Independence) - разделение ответственности, гарантирующее
выполнение объективной оценки. 1. Для мероприятий процесса верификации инструмента
независимость достигается тогда, когда верификационное мероприятие выполняется лицом
или лицами, не участвовавшими в разработке верифицируемой единицы, а также
инструментом
(или
инструментами),
обеспечивающими
эквивалентные
человеку
верификационные мероприятия. 2. Для процесса гарантии качества независимость также
включает полномочия для обеспечения выполнения корректирующих действий.
Незаданная функция (Unintended function) - включенная в программный инструмент
функция, которая не является частью требований или проекта инструмента. Инструменты
могут содержать функции, которые используются не во всех его применениях.
Эксплуатационные требования к инструменту определяют функции, используемые в
конкретном применении, в то время как Требования к инструменту определяют все
требования, воплощаемые в инструменте. Незаданные функции могут содержать функции,
которые не определены в Требованиях к инструменту.
Ненормальное поведение (Anomalous behavior) - поведение, которое не соответствует
заданным требованиям.
Носители (Media) - устройства или материалы, которые являются средствами переноса
или хранения ПО, например, программируемые постоянные запоминающие устройства,
магнитные ленты или диски, бумага.
Одобрение (Approval) - действие или документ, представляющий собой формальное
признание или официальную санкцию.
Отключенный код (Deactivated code) - исполняемый объектный код (или данные),
трассируемый на требования и в соответствии с проектом либо (а) не предназначенный для
исполнения или использования, например, часть ранее разработанного компонента ПО,
такого как неиспользуемый унаследованный код, неиспользуемые функции библиотеки или
код, предназначенный для последующего наращивания, либо (Ь) исполняемый или
используемый только в конкретных конфигурациях среды целевого вычислителя, например,
код, который включается выбором положения перемычки в аппаратном устройстве или
программируемой
опцией
ПО.
Приведенные
ниже
примеры
часто
ошибочно
классифицируются как отключенный код, хотя их следует рассматривать как необходимые
для реализации проекта или требований: структуры безопасного программирования,
Руководство Р-330
85
используемые для улучшения робастности, включая вставляемый компилятором код для
проверок диапазонов и индексов массивов, подпрограмм обработки ошибок и исключений,
проверки границ и допустимости, средства управления очередями, отметки времени.
Ошибка (Error) - ошибка в требованиях, проекте или коде.
Повторная верификация (Reverification) - оценка результатов процесса модификации,
например, коррекции ошибок или введения новой или дополнительной функциональности,
гарантирующая правильность и согласованность по отношению к входным данным и
стандартам, относящимся к этому процессу.
Покрытие операторов (Statement coverage) - каждый оператор программы был вызван
хотя бы один раз.
Примечание.
Что считать оператором, определяется языком программирования.
Покрытие решений (Decision coverage) - каждая точка входа и выхода в программе
пройдена хотя бы раз, а также каждое решение в программе приняло все возможные значения
хотя бы один раз.
Покупной готовый инструмент (Commercial-off-the-shelf software (COTS) tool) имеющийся на рынке инструмент, продажа которого осуществляется поставщиками по
каталогам. Инструмент, созданный по контракту для конкретного проекта ПО, не является
покупным готовым инструментом.
Программный инструмент (Software tool) - см. определение для «Инструмент (Tool)».
Производные требования (Derived requirements) - создаваемые процессами
разработки требования, которые определяют поведение за пределами, указанными
эксплуатационными требованиями к инструменту или требованиями более высокого уровня,
а потому не трассируемые напрямую относительно эксплуатационных требований к
инструменту или требований более высокого уровня.
Процесс (Process) - совокупность мероприятий, выполняемых в ЖЦ инструмента для
создания определенных выходных данных или продукта.
Разрешенный источник (Approved source) - месторасположение данных ЖЦ
инструмента, указанное в указателе конфигурации инструмента. Разрешенный источник
может быть хранилищем системы управления конфигурацией, электронным архивом или
внешней организацией.
Ранее разработанный компонент (в поставочном комплекте инструмента)
(Previously developed component) - компонент, уже разработанный для использования. Он
охватывает широкий диапазон компонентов, включая покупные готовые компоненты и
компоненты, разработанные в соответствии с предыдущими или текущими инструктивными
материалами.
Рассмотрение с о о т в е т с т в и я и н с т р у м е н т а (Tool conformity review) - рассмотрение,
обычно выполняемое в конце проекта разработки инструмента, с целью гарантирования того
факта, что процессы ЖЦ инструмента выполнены, данные ЖЦ инструмента полны, а
исполняемый объектный код инструмента контролируется и может быть повторно получен.
Решение (Decision) - логическое (булево) выражение, составленное из одного или более
условий, связанных логическими (булевыми) операциями. Если некоторое условие
появляется в решении более чем один раз, каждое его появление считается отдельным
условием.
Робастность (Robustness) - предел, до которого инструмент может продолжать
работать правильно, несмотря на ненормальные входные данные и условия.
Связанность по данным (Data coupling) - зависимость компонента ПО от данных, не
находящихся под исключительным контролем данного компонента.
Связаность по управлению (Control coupling) - способ или степень влияния,
оказываемого одним компонентом программы на работу другого компонента.
86
Руководство Р-330
Сертификационный зачет (Certification credit) - признание Сертифицирующим органом
того, что процесс, продукт или демонстрация удовлетворяют сертификационным
требованиям.
Среда верификации инструмента (Tool verification environment) - среда, в которой
инструмент проверяется в его исполняемой форме. Должно быть продемонстрировано, что
среда (среды) верификации является репрезентативной для операционной среды
инструмента.
Среда жизненного цикла инструмента (Tool life cycle environment) - см. определение
для «Среда разработки инструмента (Tool development environment)».
Среда разработки инструмента (Tool development environment) - среда, в которой
разрабатывается данный инструмент, включая методы и инструменты, которые должны
использоваться для мероприятий каждого процесса ЖЦ инструмента.
Стандарт (Standard) - правило или основа для сравнения, используемое как
руководство по выполнению и оценке мероприятий, а также по наполнению и оценке
содержимого определенной единицы данных.
Тестирование (Testing) - процесс выполнения задания инструментом или его
компонентами для проверки соответствия заданным требованиям и для выявления ошибок.
Тестовая процедура (Test procedure) - подробные инструкции по подготовке и
выполнению заданного набора тестовых примеров, а также инструкции по оценке результатов
их выполнения.
Тестовый пример (Test case) - набор тестовых входных данных, условий выполнения и
ожидаемых результатов, разработанный с конкретной целью - выполнить тестирование
конкретной ветви программы или проверить соответствие конкретному требованию.
Трассируемость (Traceability) - связь между объектами, например, между выходными
данными процессов, между выходными данными и порождающим их процессом или между
требованием и его реализацией.
Требования к инструменту (Tool Requirements) - Требования к инструменту
представляют собой требования, используемые для разработки и верификации инструмента.
Они включают все функциональные требования, интерфейсные требования и требования по
безопасности, которые будут воплощены в инструменте. Требования к инструменту могут
быть представлены несколькими уровнями требований.
Требования низкого уровня к инструменту (Low-level requirements) - разработанные
на основании Требований к инструменту, производных требований и проектных ограничений,
на основании которых можно непосредственно реализовать Исходный код инструмента без
привлечения дополнительной информации. Эти требования обращаются к деталям
реализации проекта. Если Исходный код инструмента может быть напрямую реализован из
Требований к инструменту, требования низкого уровня к инструменту и Требования к
инструменту являются эквивалентными.
Управление изменениями (Change control) - 1) процесс регистрации, оценки,
утверждения или отклонения и координации изменений в единицах конфигурации после
формального введения их идентификации или аналогичных действий по отношению к
базовым версиям после их введения; 2) систематическая оценка, координация, утверждение
или отклонение, а также реализация утвержденных изменений конфигурации единицы
конфигурации, после формального введения идентификации этой конфигурации или
аналогичные действия по отношению к базовым версиям после их введения.
Примечание.
В других документах может называться «Контролем конфигурации».
Управление конфигурацией (Configuration management) - 1) процесс: а) идентификации
и определения единиц конфигурации поставочного комплекта инструмента, Ь) осуществления
выпуска и изменения этих единиц в течение ЖЦ инструмента, с) регистрации и составления
отчетов о состоянии единиц конфигурации и Сообщений о проблемах, d) проверки полноты и
правильности единиц конфигурации; 2) порядок технического и административного
Руководство Р-330
87
руководства и надзора для: а) идентификации и регистрации функциональных и физических
характеристик единиц конфигурации, Ь) управления изменениями этих характеристик, с)
регистрации и составления отчетов о ходе процесса управления изменениями и о состоянии их
реализации.
Условие (Condition) - логическое выражение, не содержащее логических операций за
исключением унарной операции «Не» («NOT»).
Учет состояния конфигурации (Configuration status accounting) - регистрация и
предоставление отчетности об информации, необходимой для эффективного управления
конфигурацией,
включая
идентификацию
утвержденной
конфигурации,
состояние
предложенных изменений конфигурации и состояние реализации утвержденных изменений.
Цель (Objective) - когда настоящий документ указывается в качестве метода оценки
соответствия нормам, цели представляют собой требования, которые должны быть
удовлетворены для демонстрации соответствия.
Эксплуатационная среда инструмента (Tooi operational environment) - среда и
контекст процесса ЖЦ, в котором этот инструмент используется. Она включает рабочую
станцию, операционную систему и внешние компоненты, например, интерфейсы с другими
инструментами и ручными процессами.
Эксплуатационные требования к инструменту (Tool Operational Requirements) Эксплуатационные требования к инструменту могут рассматриваться как «системные
требования» к инструменту. Эксплуатационные требования к инструменту рассматриваются
с точки зрения пользователя и могут не содержать все требования, необходимые для
разработки инструмента.
Руководство Р-330
88
Справочные материалы А
ПЕРЕЧЕНЬ УЧАСТНИКОВ
Раздел Справочные материалы А специально оставлен незаполненным. Он включен в
состав документа, с тем, чтобы структура настоящего документа полностью повторяла
структуру оригинального документа D0-330.
Руководство Р-330
89
Справочные материалы В
ПРИМЕР ОПРЕДЕЛЕНИЯ ПРИМЕНИМЫХ УРОВНЕЙ КВАЛИФИКАЦИИ
ИНСТРУМЕНТА
Данная информация получена из документа КТ-278А, применимого к программному
обеспечению наземного базирования, такого как программное обеспечение систем СНН/УВД.
Она служит в качестве примера, как одна область добавила критерии в свои инструктивные
материалы с целью признания настоящего документа.
Определение, требуется ли квалификация инструмента
Квалификация инструмента требуется в тех случаях, когда процессы, указанные в
настоящем документе, исключаются, упрощаются или автоматизируются за счет применения
инструмента без верификации его выходных данных согласно рекомендациям раздела 6.
Процесс квалификации инструмента нужен, чтобы подтвердить, что данный инструмент
обеспечивает уровень доверия, по крайней мере, эквивалентный тому, который
обеспечивается исключаемым, упрощаемым или автоматизируемым процессом (процессами).
Процесс квалификации инструмента может применяться к одному инструменту, их набору
или к одной или нескольким функциям инструмента. Для инструмента с несколькими
функциями, если можно продемонстрировать защиту между функциями инструмента, то
квалификация требуется только для тех функций, которые используются для исключения,
упрощения или автоматизации процессов ЖЦ ПО и чьи выходные данные не верифицируются.
Защита представляет собой использование механизма, гарантирующего, что одна функция
инструмента не может неблагоприятно влиять на другую функцию.
Инструмент квалифицируется только для использования при разработке конкретной
системы, для которой намерение его использовать объявлено в Плане сертификации ПО этой
системы. Если инструмент используется для другой системы, то он должен быть повторно
квалифицирован в рамках этой другой системы.
Определение уровня квалификация инструмента
Если требуется квалификация инструмента, то должно быть оценено влияние его
использования в процессах ЖЦ ПО, чтобы определить уровень квалификации инструмента.
Для определения влияния инструмента необходимо использовать приведенные ниже
критерии:
a.
Критерий 1. Инструмент, выходные данные которого являются частью создаваемого
ПО, и поэтому он может быть источником ошибок.
b.
Критерий 2. Инструмент, который автоматизирует процесс(ы) верификации ПО и
поэтому может не обнаружить ошибку, и выходные данные которого используются для
обоснования исключения или упрощения:
c.
1)
процесса(ов) верификации, отличного от тех, который автоматизируются данным
инструментом, или
2)
процесса(ов) разработки, который может влиять на ПО систем СНН/УВД.
Критерий 3. Инструмент, который, в рамках предполагаемого его использования,
может не обнаружить ошибку.
Если инструмент исключает, упрощает или автоматизирует процессы, указанные в
настоящем документе, и его выходные данные не верифицируются так, как указано в
разделе 6, то его TQL определяется по таблице 12-1. На основании использования
инструмента и его потенциального влияния на процессы ЖЦ ПО определяются пять уровней
квалификации. Уровень TQL-1 является наиболее строгим, а уровень TQL-5 - наименее
строгим. Оценивая влияние конкретного инструмента, необходимо последовательно
рассматривать критерии 1-3. Уровень квалификации инструмента необходимо согласовать с
Сертифицирующим органом как можно раньше.
Руководство Р-330
90
Таблица 12-1. Определение уровня квалификации инструмента
1
Критерии
2
3
АН
TQL-1
TQL-4
TQL-5
AL2
TQL-2
TQL-4
TQL-5
AL3
TQL-3
TQL-5
TQL-5
AL4
TQL-4
TQL-5
TQL-5
AL5
TQL-4
TQL-5
TQL-5
Уровень гарантии
Процесс квалификации инструмента
Цели, мероприятия, инструктивные материалы и данные ЖЦ, необходимые для каждого
TQL, описываются в документе Р-330 «Руководство по квалификации программных
инструментов».
Руководство Р-330
91
Справочные материалы С
ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ, СВЯЗАННЫЕ С КВАЛИФИКАЦИЕЙ
ИНСТРУМЕНТОВ ДЛЯ ВСЕХ ОБЛАСТЕЙ
1.0
Введение к Справочным материалам С
В настоящих СМ представлено пояснение проблем квалификации инструментов в форме
ряда часто задаваемых вопросов. Часто задаваемые вопросы различны по объему - одни
короткие и лаконичные, в то время как другие длиннее и более подробны. Часто задаваемые
вопросы не предоставляют инструктивных материалов, а просто дают пояснения.
Часто задаваемые вопросы в настоящем СМ касаются инструментов в любой области.
Часто задаваемые вопросы по инструментам для конкретных областей включены в другие
Справочные материалы или могут представлять собой документ для конкретной области.
1.1 Вопрос С.1:
Что обозначает «защита» для инструмента и какие меры
помогаю т ее достичь?
Ссылка:
Настоящий документ: разделы 5.2.2.2, 6.1.3.3, 10.2.2 и 11.1.
Ключевые слова: квалификация инструментов; защита; многофункциональный
инструмент.
Ответ:
Когда к многофункциональному инструменту или набору инструментов применяются
разные уровни квалификации, требуется обеспечение защиты между различными функциями.
Словарь терминов определяет защиту следующим образом: «Использование механизма,
который гарантирует, что одна функция инструмента не может отрицательно влиять на другую
функцию инструмента». С точки зрения практики «защита» между функциями инструмента
может представлять собой любой механизм в архитектуре, проекте или реализации
инструмента, который предотвращает вредное влияние между различными функциями
инструмента.
Защита может быть обеспечена за счет использования многообразных методов, таких как
те, что перечислены ниже.
•
Реализация двух функций может быть разнесена как в пространстве, так и во времени.
•
Аналогичным образом две функции, которые выполняют различные операции над
одним и тем же потоком входных данных, могут быть защищены друг от друга путем
создания второго потока выходных данных для второй функции. По существу, общая
обработка входных данных в эти функции разделяется на дублированные потоки,
чтобы запретить двум функциям вмешиваться в правильную работу друг друга. Этот
метод использует стратегию функционального обособления, и не обязательно
стратегию разнесения в пространстве или во времени.
•
Функции квалифицированного инструмента могут быть защищены от других функций
за счет использования метода отключения функций. За счет использования
управляющего входа запрещается выполнение инструментом второй функции, таким
образом защищая первую от вредного воздействия. Метод отключения функции
должен быть подвергнут соответствующей верификации в рамках квалификации
инструмента.
Данный перечень механизмов защиты ни в коем случае не является полным, но объясняет
значение термина «защита». Любой конкретный механизм защиты, применяемый в
квалифицируемом инструменте, должен быть отражен в Требованиях к инструменту и/или
Эксплуатационных требованиях к инструменту, и потребуется достичь соглашения с
Сертифицирующим органом по эффективности и адекватности защитного механизма.
Руководство Р-330
92
1.2 Вопрос С.2:
Что такое внешние компоненты и как можно оценить их
правильность?
Ссылка:
Настоящий документ: разделы 5.2.2, 6.1.3.3, 6.1.3.4, 6.1.3.5, 6.1.4.3,
10.1.2 и 10.3.2.
Ключевые слова: квалификация инструмента; покрытие структуры; внешняя
компонента.
Ответ:
Анализ структурного покрытия обычно выполняется на уровне Исходного кода. Для
внешних компонент этот анализ может быть трудным или невозможным. Следовательно, для
уровня квалификации TQL-1 внешних компонентов требуется дополнительная верификация,
чтобы оценить правильность их функциональности.
1.2.1 Что представляю т собой внешние компоненты инструмента?
Инструмент может содержать функциональность, которая полагается на внешние
компоненты, такие как библиотека времени исполнения компилятора (обеспечивающая такие
функции, как форматирование строк символов, математические операции и т.п.) или
примитивы операционной системы. Эти компоненты находятся за пределами контроля
разработчиков инструмента, однако должен быть обеспечен приемлемый уровень
уверенности в корректной функциональности этих внешних компонент.
Приведенные ниже компоненты не следует рассматривать как «внешние» и к ним не
применим подход, описанный в разделе 1.2.2 настоящего СМ. Этими компонентами являются:
•
компоненты, разработанные для ограниченного использования или специально для
поддержки инструмента. Эти компоненты требуется рассматривать как находящиеся
под контролем разработчика инструмента и к ним должен применяться анализ
структурного покрытия;
•
библиотеки функций, которые используются в работе инструмента (например, код,
который реализует основные символы модели). Эти библиотеки являются предметом
анализа структурного покрытия как часть работы по квалификации инструмента, с
использованием применимого уровня квалификации инструментов;
•
библиотеки, используемые или встраиваемые в выходные данные инструмента,
которые становятся частью итогового программного обеспечения. Эти используемые
библиотечные компоненты требуется верифицировать как часть процессов ЖЦ ПО.
Это также относится к библиотекам, поставляемым поставщиком инструмента.
1.2.2 Применение анализа структурного покры тия к внешним компонентам
инструмента
Применение анализа структурного покрытия к внешним компонентам может оказаться
трудным или невозможным по следующим причинам:
•
в случае наличия библиотеки времени исполнения компилятора руководство
пользователя компилятора или справочное руководство по языку могут содержать
информацию, которую можно использовать в качестве требований. Однако, может
оказаться сложным или дорогим получить Исходный код, что делает анализ
структурного покрытия трудным или невозможным;
•
в случае использования инструментом функций низкого уровня операционной
системы обычно недоступны ни требования, ни Исходный код, что делает
невозможным оценку структурного покрытия для этой области.
Руководство Р-330
93
Если для подобного ПО пришлось бы выполнить анализ структурного покрытия,
устранение недостатков по результатам анализа структурного покрытия может привести к
следующим ограничениям:
•
недостатки в тестовых примерах или процедурах проверок, основанных на
требованиях, могут оказаться не связанными с функциональностью инструмента. Для
функций, неиспользуемых инструментом, дополнение тестовых примеров для
исполнения этих функций даст незначительный вклад в безопасность;
•
неполнота требований к ПО не может быть устранена, так как эти требования
ограничены или недоступны;
•
невозможно удалить мертвый код, поскольку обычно Исходный код недоступен, либо
невозможно модифицировать Исходный код;
•
отключаемый код и неиспользуемая функция не могут быть полностью рассмотрены
из-за отсутствия требований и/или Исходного кода.
Корректная функциональность внешних компонент оценивается путем:
•
их идентификации в процессе проектирования;
•
верификации правильности
рассмотрения проекта;
•
дополнительного анализа покрытия тестами, основанными на требованиях. В ходе
этого анализа нужно убедиться в том, что тесты исполняют интерфейс и
функциональность
каждой
функции
внешних
компонентов,
используемых
инструментом.
их
идентификации
и их
интерфейсов
1.3 Вопрос С.З:
Как можно максимизировать возможность повторного
использования данных квалификации инструментов?
Ссылка:
Настоящий документ: раздел 11.
во
время
Ключевые слова: квалификация инструментов; возможность повторного
использования.
Ответ:
Максимизация
возможности
повторного
использования
данных
квалификации
инструмента требует заранее обдуманного решения и планирования во время работы по
начальной квалификации инструмента. Данные инструмента нужно скомпоновать для
повторного использования в многочисленных проектах. Необходимо убедиться в том, что для
каждого квалифицирующего проекта данные могут повторно применяться для своих проектов.
Представленные ниже советы описывают общий подход для расширения возможностей
повторного использования, но не могут считаться исчерпывающими.
a.
Данные квалификации должны быть собраны в пакет для облегчения повторного
использования. В разделе 11.3 «Квалификация покупного готового инструмента»
обсуждаются роли и ответственности за достижение целей квалификации
инструментов. Чтобы квалифицировать ранее квалифицированный инструмент без
каких-либо изменений в рамках использования инструмента, оцениваются и могут
потребовать повторения только мероприятия в рамках ответственности пользователя.
b.
Цели, назначенные под ответственность разработчика инструмента, считаются
независимыми от пользователя. Предполагается, что:
•
независимые от пользователя данные
зависящих от пользователя;
компонуются
отдельно
от данных,
•
зависящие от пользователя данные ссылаются на данные, не зависящие от
пользователя.
Эта концепция может также применяться к инструментам уровня квалификации
TQL-5, для которых не требуется иметь данные квалификации отдельно от данных
Руководство Р-330
94
сертификации ПО. Хотя не зависящие от пользователя данные сведены к минимуму в
квалификации инструментов TQL-5, независимый подход к компоновке данных
квалификации облегчает непосредственное повторное использование данных без
необходимости их повторного получения для каждой последующей квалификации.
c.
Не зависящая от пользователя квалификационная документация инструмента должна
определять всю функциональность, которую предполагается квалифицировать
любыми проектами. Зависящие от пользователя данные квалификации обязательно
определяют специфические функции, которые должны быть квалифицированы, и
ссылаются на поддерживающие не зависящие от пользователя данные.
d.
Должны быть созданы специализированные данные квалификационных тестов и
анализы, там где это возможно, чтобы специально проверить квалифицируемую
функциональность. Это служит двум целям. Во-первых, они проясняют взаимосвязь
тестового примера или анализа с проверяемым требованием(ями). Во-вторых, это
отделяет данные верификации от исходного квалифицирующего проекта. Следует
проявлять осторожность, чтобы гарантировать, что набор верификации, созданный
для инструмента, является репрезентативным для использования инструмента
квалифицирующим проектом(ами).
e.
При планировании квалификации инструмента в нескольких проектах следует
учитывать несколько моментов. Например, если функции инструмента связаны какимлибо образом так, что квалификация одной функции обязательно требует
квалификации связанной функции, тогда такая связь должна быть определена в
Плане квалификации инструмента. Аналогично любые ограничения на входные
данные инструмента должны быть включены в Итоговое заключение об инструменте.
Особенно важно четко идентифицировать в Итоговом заключении об инструменте
любые защитные меры, связанные с проектом или процессом, необходимые для того,
чтобы было возможно квалифицируемое применение инструмента.
f.
На уровне проекта План сертификации ПО должен определить любые отличия между
квалифицируемыми функциями инструмента по сравнению с доступными данными
квалификации, относящимися к инструменту. План сертификации ПО или План
квалификации инструмента на уровне проекта должны определить конкретные
мероприятия пользователя, которые должны быть выполнены для завершения
квалификации инструмента в рамках проекта. Аналогично особые соображения для
различных проектов, определенные в данных квалификации инструмента, должны
быть описаны в отношении способа, которым проект будет их воспринимать. Каждый
проект должен описывать, как он соблюдает ограничения, определяемые данными
квалификации инструмента.
д.
Если в проекте имеется много инструментов, которые должны быть квалифицированы,
может оказаться целесообразным создать План квалификации инструментов и
Итоговое заключение об инструменте для проекта, в которых можно собрать данные
квалификации, связанные с инструментами для конкретного проекта, для повторного
использования при попытке сертификации проекта в будущем.
Руководство Р-330
95
Справочные материалы D
ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ, СВЯЗАННЫЕ С КВАЛИФИКАЦИЕЙ
ИНСТРУМЕНТОВ ДЛЯ БОРТОВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СРЕДСТВ СВЯЗИ, НАВИГАЦИИ,
НАБЛЮДЕНИЯ И УПРАВЛЕНИЯ ВОЗДУШНЫМ ДВИЖЕНИЕМ (CNS/ATM)
1.0
Введение к Справочным материалам D
В настоящем СМ проясняются вопросы квалификации инструментов для области
бортового программного обеспечения по документу КТ-178С и ПО для наземных систем связи,
навигации, наблюдения и управления воздушным движением (CNS/ATM) по документу КТ278А в виде ряда часто задаваемых вопросов. Часто задаваемые вопросы (FAQ) различны по
объ ем у-одни короткие и лаконичные, в то время как другие длиннее и более подробны. Часто
задаваемые вопросы (FAQ) не предоставляют инструктивных материалов, а просто дают
пояснения.
1.1 Вопрос D.1:
Почему для описания инструментов, которые могут быть
квалифицированы, не используются термины «инструмент
верификации» и «инструмент разработки»?
Ссылка:
КТ-178С/ КТ -278А: раздел 12.2.
Ключевые слова: КТ-178В; квалификация инструментов; критерии инструмента;
инструмент верификации; инструмент разработки.
Ответ:
С момента опубликования документа DO-178B в декабре
1992 г. широко
распространилось использование инструментов в разработке, верификации и управлении ПО.
Были не только предложены новые инструменты, но новые типы инструментов, которые
выполняют мероприятия и которые не подходят безоговорочно под категории «инструмент
верификации» или «инструмент разработки», стали обычными во всей отрасли
промышленности. Ожидается, что разнообразие выполняемых инструментами мероприятий
продолжится в обозримом будущем.
Принимая во внимание это разнообразие, становится ясным, что слова «разработка» и
«верификация» слишком жестко связываются с функциональным взглядом на инструмент и
могут в то же самое время вводить в заблуждение и быть чрезмерно ограничивающими. Эта
путаница создается, в частности, обычным использованием терминов «разработка» и
«верификация» для описания конкретных этапов процессов, используемых для создания ПО.
Было ощущение, что термин «инструмент разработки» мог бы быть интерпретирован так,
чтобы включать некоторые инструменты, используемые в разработке ПО, выходные данные
которых не встраиваются в бортовое ПО (или систем СНН/УВД). Аналогично, термин
«инструмент верификации» мог бы быть интерпретирован так, чтобы исключить некоторые
инструменты, которые могли бы быть с пользой квалифицированы, потому что инструмент не
выполняет «мероприятие верификации». Кроме того, существуют инструменты, которые
нельзя четко поместить в неправильно интерпретируемые категории «инструмент
разработки» и «инструмент верификации», но которые должны быть квалифицированы, но
этого не делается из-за неправильно понимаемых ярлыков.
Таким образом, существовала четкая потребность в рассмотрении проблемы путем
постановки важного вопроса: каково влияние ненормального поведения инструмента на
программное обеспечение бортовых систем (или систем СНН/УВД)? Именно этот вопрос уже
был задан в документе КТ-178В, для того чтобы определить категорию инструмента как
«инструмент для разработки» или «инструмент для верификации».
Ответ на этот вопрос вместе с уровнем ПО бортовых систем (или систем СНН/УВД)
определяет уровень квалификации инструментов (TQL), как описано в разделе 12.2 документа
КТ-178С/КТ-278А, без присваивания названия «типа» квалифицируемого инструмента.
Руководство Р-330
96
Такой подход включает инструменты, которые не просто поместить в эти поименованные
категории, и позволяет в будущем расширить определения инструментов, которые можно
будет квалифицировать.
1.2 Вопрос D.2:
Можно ли понизить уровень квалиф икации инструментов (TQL)?
Ссылка:
КТ-178С/КТ-278А: раздел 12.2.
Клю чевые слова: квалификация инструментов; уровень квалификации инструментов;
TQL; архитектурное решение.
Ответ:
Документ КТ-178С/КТ-278А в разделе 12.2 определяет, как назначать уровень
квалификации инструментов (TQL). Для уровней с TQL-1 по TQL-4 назначаемый уровень
квалификации инструмента (TQL) может быть понижен по согласованию с Сертифицирующим
органом. На общий уровень, необходимый для квалификации инструмента, могут влиять
архитектурное решение, мониторинг, независимые оценки и т.п. Понижение уровня
квалификации инструмента (TQL) требуется тесно координировать с сертифицирующим
органом и документировать в Плане сертификации ПО. (Примечание. Для пользователей
документа КТ-278А термин «Сертифицирующий орган» является эквивалентом
«одобряющего органа», и термин «План одобрения ПО» используется вместо термина
«План сертификации ПО».)
Понижение уровня квалификации должно в значительной степени основываться на
важности мероприятия документа КТ-178С/КТ-278А, которое должно быть исключено,
упрощено или автоматизировано в отношении всего набора мероприятий верификации.
Эта важность зависит от:
•
типа мероприятия документа КТ-178С/КТ-278А, которое должно быть исключено,
упрощено
или автоматизировано.
Например,
автоматизация
верификации
соответствия Исходного кода некоторым правилам представления Стандарта на
кодирование менее важна, чем автоматизация верификации соответствия Исходного
кода правилам безопасности Стандарта на кодирование;
•
вероятности того, что другие мероприятия могли бы обнаружить ту же самую ошибку
(ошибки).
Чтобы понизить уровень квалификации инструмента, это понижение должно быть
подтверждено проведением анализа использования этого инструмента и его влияния.
Требуется, чтобы этот анализ оценил общее использование данного инструмента в процессе
разработки и его влияние на создаваемое ПО. Этот анализ должен быть включен в План
сертификации ПО (или в План одобрения ПО для пользователей документа КТ-278А).
1.3 Вопрос D.3:
Когда требуется квалиф ицировать эм уляторы или сим уляторы
целевых вы числителей?
Ссылка:
КТ-178С/КТ-278А: разделы 4.4.3, 6.4.1, 6.4.3, 12.2; и «Словарь
терминов».
Клю чевые слова: квалификация инструментов; эмулятор; симулятор; среда
тестирования.
Ответ:
Этот вопрос ограничен эмуляцией и симуляцией целевого вычислителя (включая
процессор и память) для тестирования Исполняемого объектного кода. Другие использования
эмулятора или симулятора для исключения, упрощения или автоматизации достижения целей
выходят за рамки настоящего обсуждения.
1.3.1 Исходные данные и инструктивны е материалы документа КТ-178С/КТ-278А
Документ КТ-178С/КТ-278А в разделе 6.4 определяет три типа тестирования:
тестирование интеграции аппаратуры и программного обеспечения, тестирование интеграции
Руководство Р-330
97
ПО и тестирование низкого уровня. Инструктивные материалы документа КТ-178С/КТ-278А,
связанные со средами верификации, которые могли бы включать среды эмуляции и
симуляции, представлены в разделе 6.4.1.
Документ КТ-178С/КТ-278А признает, что для достижения целей тестирования ПО может
потребоваться более чем одна среда тестирования. Документ КТ-178С/КТ-278А в разделе
6.4.3 указывает, что, за исключением тестирования интеграции аппаратуры и ПО, эти методы
не предписывают конкретную среду или стратегию тестирования. Относительно тестирования
интеграции аппаратуры и ПО четко определено, что оно должно проводиться в среде
целевого
вычислителя
с
фокусом,
основанном
на
требованиях
тестирования
функциональности высокого уровня, интерфейсов аппаратуры и ПО и источников ошибок,
связанных с работой ПО в среде целевого вычислителя, как это определено документом
КТ-178С/КТ-278А в разделе 6.4.1,а.
1.3.2 Использование эмулятора или симулятора
Когда в тестировании используются инструменты-эмуляторы или инструментысимуляторы, они считаются частью среды тестирования. Конкретные тесты, выполняемые в
этой среде, должны быть идентифицированы и отделены от тестов, выполняемых на целевом
вычислителе. Выбор тестов для исполнения в среде эмулятора или симулятора основывается
на анализе репрезентативности среды эмулятора или симулятора для среды целевого
вычислителя.
Существует два основных использования эмуляции и симуляции:
a.
Э м у л я ц и я и с и м у л я ц и я в рамках тестирования интеграции аппаратуры и программного
обеспечения. В этом случае среды эмулятора или симулятора заменяют целевой
вычислитель для тестов, которые должны быть выполнены в среде целевого
вычислителя, как определено документом КТ-178С/КТ-278А в разделе 6.4.1,а.
Использования эмулятора или симулятора таким способом можно рассматривать как
исключение, упрощение или автоматизацию достижения целей совместимости с
целевым вычислителем. В таком случае тесты, выполняемые в среде эмулятора или
симулятора проверки, могут не обнаружить ошибку, если среда эмулятора или
симулятора не является репрезентативной для среды целевого вычислителя. Поэтому
Заявителю требуется предоставить подтверждение того, что среда эмулятора или
симулятора эквивалентна среде целевого вычислителя в части аспектов, влияющих
на тесты интеграции аппаратуры и программного обеспечения, предназначенные для
выполнения в эмулируемой или симулируемой среде. Различия между средой
эмулятора или симулятора и средой целевого вычислителя, которые не влияют на
конкретные тесты, предназначенные для выполнения в среде эмулятора или
симулятора, следует задокументировать.
b.
Эмуляция и симуляция, не используемые в рамках тестов интеграции аппаратуры и
программного обеспечения. В этом случае инструменты-эмуляторы или инструментысимуляторы являются частью среды верификации и должны быть под управлением
конфигурацией. Такое достижение целей совместимости с целевым вычислителем не
считается исключаемым, упрощаемым или автоматизируемым. Однако среда
эмулятора или симулятора являются предметом рассмотрения раздела 4.4.3,Ь
документа КТ-178С/КТ-278А.
1.3.3 Демонстрация эквивалентности
Требуется рассмотреть различия между средой целевого вычислителя и средой
эмулятора или симулятора с точки зрения способности тестов, выполняемых в среде
эмулятора или симулятора, обнаруживать ошибки, обычно обнаруживаемые путем
тестирования в среде целевого вычислителя (см. раздел 6.4.1,а в документе
КТ-178С/КТ-278А), и проверять функциональность тестируемого ПО. Этого можно достичь
путем анализа (как описано в разделе 4.4.3,b документа КТ-178С/КТ-278А) или квалификацией
эмулятора или симулятора, которая включает этот анализ.
98
Руководство Р-330
1.3.4 Подход к квалификации эмулятора или симулятора
Квалификация инструмента может использоваться в качестве процесса для
демонстрации эквивалентности для тестов, предназначенных для выполнения на эмуляторе
или симуляторе. В этом случае эмулятор или симулятор попадает под критерий 3. Чтобы
достигнуть целей уровня TQL-5, Эксплуатационные требования к инструменту и
соответствующий
процесс
верификации
и
валидации
инструмента
должны
продемонстрировать эквивалентность тестов, выполняемых в среде эмулятора или
симулятора, по сравнению со средой целевого вычислителя.
1.4 В опрос D.4:
Какой зачет может бы ть выдан инструментам,
квалиф ицированны м ранее с использованием
документа KT-178B/DO-278?
Ссылка:
Настоящий документ: раздел 11.2; КТ-178С/КТ-278А: раздел 12.2.
Ключевые слова: КТ-178В; DO-278; квалификация инструментов; ранее
квалифицированный инструмент; унаследованный инструмент.
Ответ:
Нормативный
базис для
квалификации
конкретного
инструмента
связан
с
сертификационным базисом проекта, использующего инструмент. Инструмент, используемый
в
проекте,
разрабатываемом
согласно
документу
КТ-178С/КТ-278А,
должен
квалифицироваться согласно инструктивным материалам документа КТ-178С/КТ-278А и
настоящего документа.
Для
инструментов,
ранее
квалифицированных
согласно
инструктивным материалам документа KT-178B/DO-278, потребуется учесть дополнительные
факторы при установлении квалификационного базиса для инструмента, если желательно
получение зачета за прошлую квалификацию.
Инструменты,
которые
были
ранее
квалифицированы
согласно
документу
KT-178B/DO-278, могут быть способны получить по договоренности с Сертифицирующим или
одобряющим органом разрешение на использование в проектах, выполняемых по
инструктивным материалам документа КТ-178С/КТ-278А. Следует учесть инструктивные
материалы раздела 11.2 настоящего документа. Объем получаемого зачета будет зависеть
от нескольких факторов, включая, но не ограничиваясь следующим:
•
Тип ранее квалифицированного инструмента, уровень и эквивалентный уровень
квалификации инструмента fTQU по документу КТ-178С или КТ-278А, как показано
в приведенной ниже таблице.
Таблица D-1. Корреляция уровней квалификации инструментов (TQL) согласно
документу KT-178B/DO-278 и документу КТ-178С/КТ-278А
Тип квалификации
инструмента
согласно документу
KT-178B/DO-278
Уровень ПО
согласно
документу
КТ-178В
Уровень гарантии
согласно
документу
КТ-278А
Уровень квалификации
инструментов (TQL)
согласно документу
КТ-178С/КТ-278А
Разработка
А
AL1
TQL-1
Разработка
В
AL2
TQL-2
Разработка
С
AL3
TQL-3
Разработка
Не используется
AL4
TQL-4
Разработка
D
AL5
TQL-4
Верификация
Все
Все
TQL-4 или TQL-5
•
Определение
критериев
квалификации
инструмента.
Для
инструмента,
квалифицируемого как инструмент верификации согласно документу KT-178B/DO-278,
в зависимости от заявляемого зачета для использования данного инструмента,
Руководство Р-330
99
применяются критерии 2 или 3, Применимым уровнем квалификации инструментов
(TQL) будет уровень TQL-4 или TQL-5, как определено в разделе 12.2 документа
КТ-178С/КТ-278А.
•
Сходство целей. Хотя эти классификации эквивалентны, свидетельство, необходимое
для достижения конкретной цели может отличаться в документах KT-178B/DO-278 и
КТ-178С/КТ-278А. Таким образом, цели (хотя и похожи) различаются (как по
количеству, так и в деталях). Различия между сходными целями должны быть
проанализированы, а также рассмотрены отличия. См. раздел 11.2 настоящего
документа.
•
Различия целей. Для любой цели согласно документа KT-178B/DO-278, которая была
ранее достигнута, может существовать эквивалентная или сходная цель, для которой
имеется зачет. В случае существования новой цели потребуется предоставить новое
свидетельство квалификации. См. раздел 11.2 настоящего документа.
Заявителю требуется задокументировать эти факторы в своих Планах сертификации ПО
(или Планах одобрения ПО для пользователей документа КТ-278А) и четко сформулировать
запрашиваемый зачет для сертификации или одобрения. Если установлено, что требуются
изменения данных квалификации инструмента, договоренность об использовании
соответствующих процессов квалификации инструментов согласно либо документу
KT-178B/DO-278, либо документу КТ-178С/КТ-278А следует задокументировать как в Плане
сертификации ПО (или в Плане одобрения ПО для пользователей документа КТ-278А), так и
в Плане квалификации инструмента (по необходимости).
1.5 В опрос D.5:
Что является обоснованием для определения критериев
квалификации инструмента?
Ссылка:
КТ-178С/КТ-278А: раздел 12.2.
Ключевые слова: КТ-178В; DO-278; квалификация инструментов; ранее
квалифицированный инструмент; унаследованный инструмент.
Ответ:
1.5.1 Исходные данны е
В документе KT-178B/DO-278 рассматриваются две категории инструментов: инструмент
разработки (инструмент, который может внести ошибку) и инструмент верификации
(инструмент, который может не обнаружить ошибку).
На практике названия категорий инструментов вступили в противоречие с реальной
функциональностью инструментов. Как следствие, некоторые инструменты могли не
рассматриваться надлежащим образом в процессе квалификации инструментов. Кроме того,
было замечено, что не все инструменты верификации имеют одно и то же потенциальное
влияние на безопасность. Даже если они не могут внести ошибку в итоговое ПО, последствия
факта, что они могут только пропустить ошибку, могут варьироваться в зависимости от
использования инструмента в процессе ЖЦ ПО и заявленного зачета.
Ожидается, что использование формальных методов, разработки на основании моделей
и других методологий, основанных на интенсивном применении инструментов, будет расти в
будущем. Использование инструментов в этих методологиях в сочетании с послаблением
мероприятий процессов ЖЦ ПО должно быть надлежащим образом рассмотрено для
обеспечения безопасности.
Повышенный риск, который привносят эти методологии, основанные на интенсивном
применении инструментов, ведет к заключению о том, что требуется промежуточный уровень
категории инструментов между категориями инструментов по документу KT-178B/DO-278,
чтобы охватить все типы инструментов и определить соответствующие уровни квалификации
инструментов (TQL).
Этот вопрос объясняет обоснование
разделе 12.2 документа КТ-178С/КТ-278А.
критериев
инструментов,
представленных
в
Руководство Р-330
100
1.5.2 Подход к определению применимого уровня квалификации инструмента
(TQL)
Документ КТ-178С/КТ-278А не использует термины «инструмент разработки» или
«инструмент верификации». Вместо этого он фокусируется на влиянии ошибок инструмента
на итоговое ПО, а не на названии категории инструментов. Уровень квалификации
инструментов (TQL) основывается на нескольких критериях. Эти критерии связаны с влиянием
инструмента в процессах ЖЦ ПО и комбинируются с уровнем итогового ПО для определения
применимого уровня квалификации инструментов (TQL). Затем цели, применяемые к каждому
уровню квалификации инструментов (TQL), определяются в таблицах Приложения А
настоящего документа.
1.5.3 Определение критериев инструментов
1.5.3.1 Сравнение между категориями инструментов документа KT-178B/DO-278
и критериями квалификации инструментов документа КТ-178С/КТ-278А
В таблице D-2 представлено сравнение категорий инструментов документа
KT-178B/DO-278 и критериев квалификации инструментов документа КТ-178С/КТ-278А.
Критерии следует оценивать по порядку; например, для заданного инструмента критерий 2
должен рассматриваться после критерия 1, но до критерия 3.
Таблица D-2. Сравнение между категориями инструментов документа KT-178B/DO-278
и критериями квалификации инструментов документа КТ-178С/КТ-278А
Категория и определение
инструмента по документу
KT-178B/DO-278
Категория и определение квалификации инструмента
по документу КТ-178С/КТ-278А
Инструменты разработки.
Критерий 1. Инструмент, выходные данные которого
Инструменты, выходные
являются частью итогового ПО, и который, следовательно,
может внести ошибку
данные которых составляют
часть ПО бортовых систем
(или систем СНН/УВД) и таким
образом могут вносить ошибки
Инструменты верификации.
Инструменты, которые не
могут вносить ошибки, но
могут их не обнаружить
Критерий 2. Инструмент, который автоматизирует
процесс(ы) верификации и таким образом может не
обнаружить ошибку, и чьи выходные данные используются
дпя обоснования исключения или упрощения:
•
процесса(ов) верификации, отличных от тех, которые
автоматизируются данным инструментом, или
•
Процесса(ов) разработки, которые могут влиять на ПО
бортовых систем (или систем СНН/УВД)
Критерий 3. Инструмент, который в рамках
предполагаемого его использования, может не обнаружить
ошибку
1.5.3.2 Обоснование для применения критерия 2
Традиционно мероприятия верификации (рассмотрение, анализ и тест с инструментом
или без инструмента) выполняются на наборе данных ЖЦ, чтобы достигнуть целей
верификации для этих данных.
Проблема возникает, когда, основываясь на доверии к данному мероприятию
верификации, некоторое послабление заявляется для других целей или мероприятий,
которые не являются прямым назначением этого мероприятия верификации.
Руководство Р-330
101
Эти послабления не допускаются для ручных мероприятий верификации. Одним из
принципов документа KT-178B/DO-278 (который остается и в документе КТ-178С/КТ-278А)
является перекрытие мероприятий процесса верификации ПО, который применяется для того,
чтобы предотвратить внесение ошибок или увеличить способность обнаружения ошибок. То
есть различные цели верификации применяются для выявления и удаления ошибок. Чем
выше уровень ПО, тем больше целей применяется.
Однако когда верификация автоматизируется с использованием инструмента, Заявитель
может заявить, что инструмент выявляет все ошибки определенной категории. В этом случае
какой-либо механизм, встраиваемый в ПО (на этапах разработки требований, проектирования
или кодирования), или некоторые другие мероприятия верификации объявляются излишними
и бесполезными. Новые методы или технологии, такие как разработка на основе моделей и
формальные методы, в значительной мере опираются на инструменты. Эти новые
методологии были рассмотрены при документировании данного подхода в документе
КТ-178С/КТ-278А и в настоящем документе.
При применении инструктивных материалов документа KT-178B/DO-278 по квалификации
инструментов не было различия для квалификации инструментов, которые могли бы только
«не справиться с обнаружением ошибки» при использовании только для автоматизации цели
верификации, и тех, для которых заявлено, что доверие к ним позволяет облегчить другие
цели или мероприятия.
Эти расширения использования инструментов вызывают некоторую озабоченность в
отношении строгости, требуемой для квалификации. Например:
•
с точки зрения безопасности влияние этих инструментов на итоговое ПО может
меняться;
•
может оказаться, что требуемое доверие не может быть оценено за счет рассмотрения
только Эксплуатационных требований к инструменту;
•
зрелость и обоснованность математической теории и ее реализации могут оказаться
необходимыми для обеспечения требуемого доверия.
Эти аспекты на фоне растущего уровня использования инструментов привели к
добавлению критерия 2 в раздел 12,2 документа КТ-178С/КТ-278А. В следующем разделе
представлены некоторые примеры инструментов по критериям 1, 2 и 3.
1.5.3.3 Соображения о выборе критериев и примеры
Ниже представлены соображения и примеры в помощь понимания и применения
критериев инструментов в документе КТ-178С/КТ-278А. Эти ограниченные примеры
предназначены для того, чтобы помочь применению определений критериев в документе
КТ-178С/КТ-278А.
Заявителям
следует учитывать особенности своего
контекста
использования инструментов.
1.5.3.3.1 Применение критериев 1, 2 и 3
Критерий 1 применяется к инструментам, которые автоматически создают часть
выходных данных одного из процессов разработки ПО, вне зависимости от формата входных
и выходных данных. Этот критерий охватывает инструменты, которые преобразуют
требования более высокого уровня в требования более низкого уровня (или того же уровня,
но используя другой формализм), в Исходный код, в файлы данных, в файлы конфигураций
или в Исполняемый объектный код. Однако в случае создания Исполняемого объектного кода
следует также учитывать раздел 4.4.2 документа КТ-178С/КТ-278А. Следует к тому же
учитывать инструменты, используемые в рамках создания выходных данных процессов
разработки ПО, которые не преобразуют данные, но могут внести ошибку.
Критерий 2 и критерий 3 применяются ко всем инструментам, которые верифицируют
или анализируют данные ЖЦ ПО, рассчитывают характеристики ПО и т.п. Применение одного
из этих двух критериев отличается на основании зачета сертификации или одобрения,
которого добивается Заявитель.
Руководство Р-330
102
a.
Если требуется зачет сертификации/одобрения только для цели, напрямую
достигаемой конкретным мероприятием, выполняемым инструментом, применяется
критерий 3.
b.
Альтернативой для Заявителя является заявление о том, что другие цели также
полностью или частично достигаются посредством использования инструмента.
В этом случае применяется критерий 2.
1.5.3.3.2 Примеры определения критерия 2 или 3
Ниже приведено несколько примеров инструментов, к которым могут применяться
критерии 2 или 3.
a.
Пример 1. Для автоматизации некоторой верификации Исходного кода можно
использовать инструмент проверки. На основании такого использования инструмента
и искомого зачета можно применять критерий 3. Однако если Заявитель утверждает,
что мероприятие тестирования для обнаружения некоторого класса ошибок
становится ненужным на основании того, что инструмент обнаруживает
соответствующий класс ошибок, тогда становится применимым критерий 2. В этом
случае это соответствует «упрощению процесса(ов) верификации ПО, отличных от тех,
что автоматизируются с помощью инструмента».
b.
Пример 2. Для автоматизации некоторой верификации в рамках рассмотрения
Исходного кода можно использовать статический анализатор кода. На основании
использования такого инструмента и искомого зачета можно применять критерий 3.
Однако если Заявитель не собирается включать в итоговое ПО некоторые
специальные механизмы с целью обнаружения и обработки возможного переполнения
и ошибок времени исполнения на основании уверенности в инструменте, тогда
становится применимым критерий 2. В этом случае это соответствует «упрощению
процесса(ов) разработки ПО».
1.5.3.3.3 Многоуровневый подход к обеспечению безопасности и критерии
квалификации инструмента
В некоторых случаях мероприятия верификации в документе КТ-178С/КТ-278А
используют многоуровневый подход к обеспечению безопасности. Например, несоответствие
Исходного кода требованиям низкого уровня может быть обнаружено рассмотрением
Исходного кода (раздел 6.3.4,а документа КТ-178С/КТ-278А) или тестами, основанными на
требованиях (раздел 6.4.2 документа КТ-178С/КТ-278А). Анализ структурного покрытия
помогает определять неполноту требований или тестовых примеров. Данный многоуровневый
подход к обеспечению безопасности становится необходимым, поскольку исчерпывающая
верификация может быть невозможной.
Однако инструмент, отвечающий критерию 3, который удовлетворяет целям
квалификации настоящего документа, дает целостный результат верификации, так что другой
процесс или мероприятие для достижения связанной цели может оказаться более ненужным.
Это обеспечивается сочетанием двух следующих целей,
•
«Адекватность инструмента обеспечивается в Эксплуатационых требованиях к
инструменту»,
•
«Работа инструмента соответствует Эксплуатационным требованиям к инструменту».
Поэтому использование другого процесса или мероприятия для достижения связанной
цели может оказаться больше ненужным.
Для инструментов, отвечающих критерию 3, многоуровневый подход документа
КТ-178С/КТ-278А не нарушается, если квалифицированный инструмент используется, чтобы
непосредственно исключить или упростить процесс(ы) документа КТ-178С/КТ-278А в рамках
его планируемого использования. Когда инструмент используется также для исключения или
упрощения другого процесса(ов), многоуровневый подход к обеспечению безопасности не
страдает в части предыдущих соображений, если обеспечивается применением к этому
Руководство Р-330
103
инструменту критерия 2. При выполнении квалификации на использование в ПО уровня А
или В (уровней AL1 или AL2 для пользователей документа КТ-278А) применение критерия 2
ведет к более высокому уровню квалификации инструментов, чем тот, который требуется
для инструмента, планируемое применение которого удовлетворяет только критерию 3.
1.5.3.3.4 Уровни квалификации инструментов
Применимый уровень квалификации инструмента основывается на оценке критериев и
уровне ПО или уровне гарантии. В таблице D-3 представлена сводка уровней квалификации
инструментов. Представленный ниже текст кратко объясняет, как новый критерий в документе
КТ-178С/КТ-278А связан с предыдущим критерием в документе KT-178B/DO-278.
Таблица D-3. Сводка уровней квалификации инструментов (TQL)
Критерии
Уровень ПО
согласно документу
КТ-178С
Уровень гарантии
согласно документу
КТ-278А
1
2
3
А
AL1
TQL-1
TQL-4
TQL-5
В
AL2
TQL-2
TQL-4
TQL-5
С
AL3
TQL-3
TQL-5
TQL-5
Не используется
AL4
TQL-4
TQL-5
TQL-5
D
AL5
TQL-4
TQL-5
TQL-5
a.
Критерий 1. Уровень квалификации инструментов (TQL), применимый к критерию 1,
является заменой инструменту разработки в документе KT-178B/DO-278.
b.
Критерий 2. Как объяснялось выше, критерий 2 является новым для документа
КТ-178С/КТ-278А и введен как ответ на расширение использования инструментов в
новых методологиях. Критерий 2, по существу, требует повышенного уровня строгости
сверх критерия документа KT-178B/DO-278 для инструментов, используемых в ПО
уровней А и В (уровней AL1 и AL2 для пользователей документа КТ-278А), для того
чтобы повысить доверие к применению инструмента (т.е. уровня TQL-4 вместо уровня
TQL-5). Уровень TQL-4 требует, чтобы данные Требований к инструменту описывали
всю
функциональность,
реализуемую
в
инструменте,
и
предоставляли
дополнительные подробности об архитектуре инструмента. Уровень TQL-4 требует
также верификации соответствия инструмента Требованиям к инструменту. Цели
уровня TQL-4 рассматриваются как минимальные, для того чтобы заявить о доверии к
применению инструмента. Но применение уровня квалификации инструментов TQL-4
для уровня программного обеспечения А или В (уровня AL1 или AL2 для
пользователей документа КТ-278А) предусмотрено не для того, чтобы помешать
использованию данного типа инструментов. Можно рассматривать следующие
подходы к использованию инструментов:
•
в случае недостатков в данных ЖЦ инструмента, необходимых для квалификации
инструмента на уровне TQL-4, Заявитель все же может использовать этот
инструмент и квалифицировать его на уровень TQL-5; однако другой зачет
сертификации или одобрения ограничивается целями верификации данных,
которые верифицируются:
•
в случае покупного готового инструмента, если данные ЖЦ не предоставляется
поставщиком инструмента для квалификации инструмента на уровне TQL-4,
раздел 11 настоящего документа позволяет Заявителю добавить данные, чтобы
достигнуть целей для применимого уровня квалификации инструмента;
•
возможны и другие подходы к квалификации (см. раздел 11).
104
Руководство Р-330
с.
Критерий 3. Уровень TQL-5 является заменой инструменту верификации в документе
KT-178B/DO-278.
1.6 Вопрос D.6:
Какие улучшения квалификации «инструментов вериф икации»
были сделаны в документе КТ-178С/КТ-278А?
Ссылка;
КТ-178С/КТ-278А: раздел 12.2.
Ключевые слова: КТ-178В; квалификация инструментов; инструмент верификации;
TQL-5; детерминизм.
Ответ:
1.6.1 Критерии квалиф икации для инструментов вериф икации в документе КТ-178В
В документе КТ-178В инструктивные
верификации ПО, сведены в разделе 12.2.2:
материалы,
применимые
к
инструментам
«Критерии квалификации для инструментов верификации ПО должны достигаться
путем демонстрации того, что инструмент соответствует Эксплуатационным требованиям
к инструменту в нормальных условиях эксплуатации».
Однако документ КТ-178В не предоставляет детальной информации по содержанию
Эксплуатационных требований к инструменту, не определяет четко разработку данных
квалификации для инструментов верификации и не определяет применимые цели для
процесса квалификации инструмента.
Документ КТ-178В указывает также для инструмента верификации следующее:
•
данные квалификации инструментов подлежат управлению по категории контроля КК2
(раздел 12.2.3,b документа КТ-178В);
•
План квалификации инструмента и Итоговое заключение об инструменте не
требуются (требуются только включить данные в План сертификации ПО и Итоговое
заключение о ПО) (раздел 12.2.4 документа КТ-178В);
•
применяются обобщенные цели управления конфигурацией и гарантии качества
(поскольку обобщенные цели не детализированы в документе КТ-178В, их применение
непоследовательно) (раздел 12.2,с документа КТ-178В).
1.6.2 Пояснения и улучш ения для уровня TQL-5
В настоящем разделе сведены вместе улучшения, сделанные в настоящем документе для
инструментов уровня TQL-5. Эти улучшения предназначены для прояснения пунктов
документа КТ-178В (и соответственно документа DO-278).
1.6.2.1 Область квалиф икации
В разделе 5 определяется процесс разработки инструмента, который состоит из:
a)
процесса определения Эксплуатационных требований к инструменту;
b)
процесса разработки инструмента;
c)
процесса эксплуатационной интеграции инструмента.
Инструктивные материалы о процессе разработки инструмента (приведенный выше
пункт Ь) не применимы к уровню TQL-5. Таким образом, квалификация на уровень TQL-5
остается подходом, ориентированным на продукт. Два других процесса (приведенные выше
пункты а) и с)) определяются с помощью особых целей. Цели, применимые к указанным выше
процессам а) и с) и соответствующим процессам верификации, сведены в таблицу Т-0
в Приложении А настоящего документа.
Основное содержание настоящего документа предоставляет полный набор целей и
инструктивные материалы для всех уровней квалификации инструментов (TQL).
В Приложении А представлена сводка всех этих целей с их применимостью по уровням
Руководство Р-330
105
квалификации инструментов (TQL). Цели уровня TQL-5 представляют собой подмножество
общего набора целей.
1.6.2.2 Детерминизм
В разделе 12 документа КТ-178В сделано следующее заявление: «Могут быть
квалифицированы только детерминированные инструменты, то есть инструменты, которые
создают те же самые выходные данные из тех же самых входных данных при работе в той же
самой среде». Использование термина «детерминированный» имеет специфическое
значение в разработке ПО и это значение часто считается слишком ограничивающим для
инструментов.
В разделе 2.0 содержится общая цель детерминизма, но перефразированная для
рассмотрения неожиданного поведения инструментов: «Для инструмента, выходные данные
которого могут меняться в пределах ожиданий, следует продемонстрировать, что данная
вариация не влияет отрицательно на предполагаемое использование этих выходных данных
и что правильность выходных данных установлена».
1.6.2.3 Прояснение Эксплуатационных требований к инструменту
Настоящий документ проясняет, когда требуются Эксплуатационные требования к
инструменту и что они должны содержать. Цель 2 из таблицы Т-0 (которая ссылается на
раздел 5.1.1) представляет цель для Эксплуатационных требований к инструменту.
Детальная информация по содержанию Эксплуатационных требований к инструменту
представлена в разделе 10.3.1.
1.6.2.4 Интеграция инструментов в эксплуатационной среде
Определена новая цель для инструментов (цель 3 из таблицы Т-0 (которая ссылается на
раздел 5.3.1)). Она обеспечивает проведение квалификации в конкретной эксплуатационной
среде инструмента.
1.6.2.5 Вериф икация инструментов
Цель 5 из таблицы Т-0 (которая ссылается на раздел 6.2.1 ,Ь) гласит: «Работа инструмента
соответствует Эксплуатационным требованиям к инструменту и соответствует разделу 12.2.2
документа КТ-178В. Назначение данной цели - убедиться, что инструмент, установленный в
эксплуатационной среде инструмента, соответствует Эксплуатационным требованиями к
инструменту.
1.6.2.6 Валидация инструментов
В дополнение к процессу верификации, который оценивает соответствие инструмента
Эксплуатационным
требованиям
к
инструменту,
добавлены
две
новые
цели,
соответствующие мероприятиям валидации. Эти цели предназначены для оценки того, что
инструмент соответствует потребностям ЖЦ бортового ПО.
•
Цель 6 из таблицы Т-0 (которая ссылается на раздел 6.2.1,аа): «Эксплуатационные
требования к инструменту достаточны и корректны». Это нужно для того, чтобы
создать связь между Эксплуатационными требованиями к инструменту и целью,
достигаемой за счет применения инструмента. Соответствие этой цели
демонстрирует, что требования, применимые к инструменту, покрывают цель ПО
бортовых систем (или систем СНН/УВД) (полностью или частично), достигаемую за
счет применения инструмента.
*
Цель 7 из таблицы Т-0 (которая ссылается на раздел 6.2.1 ,bb): «Потребности
процессов ЖЦ ПО удовлетворяются данным инструментом». Эта цель дополняет
цель 6 из таблицы Т-0.
Она оценивает то, что инструмент, установленный в эксплуатационной среде инструмента,
удовлетворяет все потребности процесса создания ПО.
106
Руководство Р-330
1.6.2.7 Управление конфигурацией инструментов
Для уровня TQL-5 требуемые данные квалификации определяются как КК2. Поэтому как
минимум применимы следующие цели, определяемые в таблице Т-8.
•
Определены единицы конфигурации.
•
Установлен порядок хранения, воспроизведения и выпуска.
1.6.2.8 Гарантия качества инструментов
Общие инструктивные материалы, на которые ссылается цель 2 из таблицы Т-9, применимы
для всех уровней квалификации инструментов (TQL). Кроме того, цель 5 из таблицы Т-9
устанавливает необходимость рассмотрения, но считает, что это рассмотрение может быть
добавлено или выполнено в рамках рассмотрения соответствия бортового ПО (или систем
СНН/УВД). Другие цели из таблицы Т-9 не применяются к уровням TQL-4 и TQL-5.
1.6.2.9 Процесс взаимодействия с Сертифицирующим (одобряющим) органом для
квалификации инструментов
Все цели из таблицы Т-10 применяются к инструментам уровня TQL-5. Данные, которые
обычно представляются в Плане квалификации инструмента или в Итоговом заключении об
инструменте, могут быть представлены в Плане сертификации ПО (или в Плане одобрения
ПО для пользователей документа КТ-278А) и в Итоговом заключении о ПО бортовых систем
(или систем СНН/УВД) для пользователей документа КТ-278А).
Чтобы убедиться в том, что инструмент выполняет заданную ему функцию в ЖЦ ПО, даже
при известных проблемах и функциональных ограничениях, в таблице Т-10 добавлена цель,
которая применима для уровня квалификации TQL-5: «Влияние известных проблем на
Эксплуатационные требования к инструменту определено и проанализировано».
1.6.3 Заключение
В настоящем документе приводятся более точные и полные инструктивные материалы
для инструментов на уровне квалификации TQL-5, чем это делается в документе КТ-178В
(и, соответственно, в документе DO-278) для инструментов верификации. Намерение не в том,
чтобы запрашивать больше мероприятий или больше данных (например, квалификация не
требует каких-либо данных от процесса разработки инструмента). Однако проясняется
содержание Эксплуатационных требований к инструменту, соответствие инструмента
потребностям процесса создания ПО бортовых систем (или систем СНН/УВД) и цели других
интегральных процессов, применимые к уровню квалификации TQL-5.
Примечание.
Поскольку документ DO-278 ссылается на документ КТ-178В в
отношении квалификации инструментов, все ссылки на документ
КТ-178В применимы в настоящих часто задаваемых вопросах также и
для документа DO-278.
1.7 Вопрос D.7;
Как можно использовать квалифицированный инструмент для
верификации выходных данных неквалифицированного
инструмента?
Ссылка:
Настоящий документ: Весь документ КТ-178С/КТ-278А: раздел 12.2.
Ключевые слова: инструменты; квалификация инструментов; квалифицированный
инструмент; неквалифицированный инструмент.
Руководство Р-330
107
Ответ:
1.7.1
Область применения и ограничения
Когда выходные данные инструмента верифицируются так, как описано в разделе 6
документа КТ-178С/КТ-278А, квалификации инструмента не требуется. Эта верификация
может выполняться посредством комбинации рассмотрений, анализов и автоматической
верификации, выполняемой с помощью другого инструмента или нескольких инструментов
для достижения всех целей, применимых для выходных данных неквалифицированного
инструмента. Возможность инструментов достигать эти цели является ключом к выбору
общего подхода верификации.
Для некоторых инструментов, таких как генераторы автокода, достижение всех
применимых целей верификации из документа КТ-178С/КТ-278А выходных данных
инструмента с помощью другого инструмента может быть недостижимым. Поэтому, следует
определить, какие цели могут выполняться с помощью квалифицированного инструмента.
Согласно инструктивным материалам документа КТ-178С/КТ-278А и настоящего
документа План сертификации ПО (или План одобрения ПО для пользователей документа
КТ-278А) четко объясняет и обосновывает, какие цели будут частично или полностью
достигнуты за счет применения инструментов, и необходимость их квалификации. Критерии
квалификации, определенные в разделе 12.2 документа КТ-178С/КТ-278А, применяются к
верифицирующему инструменту (инструментам), чтобы определить уровень их квалификации.
На рисунке D-1 представлен пример взаимосвязи между инструментами.
{*) - данные, необходимые для верификации выходных файлов
неквалифицированного инструмента. Эти данные могут включать
входные файлы неквалифицированного инструмента.
Рисунок D-1. Пример взаимосвязи инструментов
В данном вопросе указаны некоторые факторы, которые нужно рассмотреть, чтобы учесть
возможность наличия ошибок как в квалифицированном, так и в неквалифицированном
инструменте (инструментах). Возможны два случая.
1.
Неквалифицированный инструмент (например, генератор автокода) вносит ошибку в
бортовое (СНН/УВД) ПО, которую не может обнаружить квалифицированный
инструмент.
Руководство Р-330
108
2.
Выходные данные неквалифицированного инструмента (например, генератора
тестовых примеров) ошибочны или неполны и квалифицированный инструмент не
может этого обнаружить.
Данный вопрос не предназначен для того, чтобы поощрять или препятствовать
использованию такого ЖЦ ПО, он предназначен для указания аспектов, которые нужно учесть,
чтобы избежать двух указанных выше случаев. Конкретные детали документируются в планах
сертификации или одобрения и согласовываются с Сертифицирующим (одобряющим)
органом.
1.7.2 Обсуждение
Данный вопрос обращает внимание на следующие соображения, касающиеся возможных
проблем, возникающих при использовании инструмента (инструментов) для верификации
выходных данных неквалифицированного инструмента.
•
Покрытие целей верификации, которое
неквалифицированного инструмента.
применяется
к
выходным
данным
•
Условия эксплуатации квалифицированного инструмента.
•
Предотвращение общих причин (т.е. предотвращение одной ошибки, влияющей как на
неквалифицированный инструмент, так и на квалифицированный инструмент).
•
Защита между инструментами (т.е. предотвращение вредного влияния неквалифици­
рованного инструмента на надлежащую работу квалифицированного инструмента).
Каждое из них рассматривается ниже более подробно. Кроме того, могут возникнуть
другие соображения для конкретного ЖЦ или конфигурации входных и выходных данных,
которые потребуется рассматривать для конкретного случая в рамках проекта.
1.7.2.1 Покрытие целей верификации выходных данных неквалифицированного
инструмента
Мероприятия и процессы, автоматизируемые неквалифицированным инструментом,
диктуют
применимые
цели
верификации,
которые
должны
быть
достигнуты
квалифицированным инструментом. Необходимо рассмотреть все применимые цели
верификации, чтобы определить объем работ по квалификации. План сертификации ПО
(План одобрения ПО для пользователей документа КТ-278А) указывает, какие цели
полностью или частично достигаются квалифицированным инструментом. Эти данные могут
быть далее раскрыты в отдельном Плане квалификации инструмента, на который ссылаются
в Плане сертификации ПО (Плане одобрения ПО для пользователей документа КТ-278А).
Следует отметить, что План сертификации ПО (План одобрения ПО для пользователей
документа КТ-278А) также определяет, как полностью достигаются все применяемые цели.
Когда квалифицированный инструмент используется для верификации только
промежуточных выходных данных неквалифицированного инструмента, должны быть
выполнены
дополнительные
мероприятия
на
итоговых
выходных
данных
неквалифицированного инструмента.
Важно, чтобы Эксплуатационные требования к инструменту для квалифицированного
инструмента были совместимы с целями, заявленными в Плане сертификации ПО (Плане
одобрения ПО для пользователей документа КТ-278А), как требуется таблицей Т-0 (цель 6).
1.7.2.2 Условия эксплуатации квалифицированного инструмента
Инструмент, верифицирующий выходные данные неквалифицированного инструмента,
квалифицируется для использования в «нормальных условиях эксплуатации», определяемых
в данных квалификации инструмента. Эти условия могут включать некоторые запреты,
ограничения и контекст использования неквалифицированного инструмента. Этот контекст
включает как минимум настройки конфигурации и инициализации (настройка инструмента).
Руководство Р-330
109
Необходимо верифицировать
квалифицированный инструмент.
соответствие
этим
условиям,
когда
используется
1.7.2.3 Предотвращение общих причин
Между квалифицированным и неквалифицированным инструментами требуется
выполнить разделение, чтобы избежать наличия одинаковой ошибки в обоих инструментах.
Такое разделение может принимать одну из нескольких форм, включая, среди прочих,
перечисленные ниже.
•
Независимая
разработка
инструмента:
квалифицированный
инструмент
разрабатывается независимо от неквалифицированного инструмента силами
отдельного штата разработчиков в рамках отдельного ЖЦ разработки инструмента.
Демонстрация независимости разработки инструмента может потребовать больше
данных ЖЦ разработки инструмента, чем обычно нужно для квалификации. Данный
подход к независимости не обязательно требует, чтобы квалифицированный
инструмент создавался другой организацией, чем та, что разрабатывает
неквалифицированный инструмент.
•
Отличающийся технический подход: в зависимости от функциональности
неквалифицированного инструмента может потребоваться использовать для
квалифицированного
инструмента
технический
подход,
отличающийся
от
применяемого для неквалифицированного инструмента. Это похоже на этапы
проверки ошибок, обычно используемые в решении алгебраических уравнений, когда
один математический процесс используется для поиска ответа, а второй процесс
используется для проверки того, что ответ правильный.
Вне зависимости от подхода к разделению общие компоненты кода (такие как библиотеки)
требуют специального рассмотрения.
1.7.2.4 Защита между инструментами
Словарь терминов в настоящем документе определяет защиту следующим образом:
«Использование механизма, который гарантирует, что одна функция инструмента не может
отрицательно влиять на другую функцию инструмента». Если квалифицированный
инструмент используется для верификации выходных данных неквалифицированного
инструмента, тогда степень, до которой неквалифицированный инструмент может влиять или
негативно воздействовать на надлежащую работу квалифицированного инструмента, должна
быть сведена к минимуму.
1.8 Вопрос D.8:
Как можно использовать квалиф ицированны й генератор
автокода?
Ссылка:
Настоящий документ: Весь документ КТ-178С/КТ-278А: раздел 12.2 и
Приложение А.
Ключевые слова: генератор автокода; квалификация инструментов.
Ответ:
1.8.1 Терминология
В настоящем вопросе применяются следующие термины.
•
Генератор автокода (Autocode Generator - ACG) - этот термин покрывает
программные инструменты, которые используют набор компьютерных файлов,
представляющих часть требований к ПО, таких как модель, формальная
спецификация или набор данных. Генератор автокода (ACG) использует эти файлы
для генерирования Исходного кода. Правила трансляции, а также описание входных
данных генератора автокода и формата Исходного кода представляются в
Эксплуатационных требованиях к инструменту и/или Требованиях к инструменту.
110
Руководство Р-330
•
Квалиф ицированны й генератор автокода - генератор автокода, квалифици­
рованный согласно критерию 1 раздела 12.2 документа КТ-178С/КТ-278А (поскольку
он может вносить ошибку в ПО бортовых систем (или систем СНН/УВД)).
•
Файлы входны х данны х - входные данные генератора автокода (ACG),
считающиеся требованиями низкого уровня ПО бортовых систем (или систем
СНН/УВД) в смысле того, что Исходный код может быть создан непосредственно без
какой-либо дополнительной информации.
•
Ком пилятор/компоновщ ик - инструменты, используемые для перевода Исходного
кода в Исполняемый объектный код в таком формате, который может быть
интегрирован в целевую платформу.
1.8.2 Назначение и ограничения данного вопроса
Правильность
и
полнота
файлов
входных
данных,
включая
отсутствие
непредусмотренных элементов, оценивается в процессе верификации ПО и выходит за рамки
данного вопроса. Файлы входных данных могут быть представлены в виде модели. В этом
случае следует обратиться к документу «Разработка и верификация на основании модели».
Генератор автокода (ACG), как и любой инструмент, квалифицируется в контексте,
определенном в Плане сертификации ПО (Плане одобрения ПО для пользователей
документа КТ-278А). Этот контекст включает указание целей, достигаемых посредством
использования данного квалифицированного инструмента.
Назначение настоящего вопроса - прояснить, в каких условиях некоторый зачет
сертификации/одобрения (достижение целей) может быть запрошен при использовании
данного квалифицированного генератора автокода (ACG). Однако невозможно рассмотреть
все технические проблемы, возникающие при использовании квалифицированного
генератора автокода (ACG). В данном вопросе представлена дополнительная информация,
основанная на некоторых типовых сценариях, включая наложенные и естественные
ограничения, при запросе зачета в случае использования генератора автокода (ACG). Эти
сценарии дают представление о том, на что следует обратить внимание, и потенциальные
соображения, которые следует рассматривать при использовании квалифицированного
генератора автокода (ACG). Наложенные и естественные ограничения и соображения,
приведенные в настоящем вопросе, не являются исчерпывающими.
1.8.3 Обсуждение
В настоящем вопросе обсуждается, как некоторые цели процессов разработки ПО
бортовых систем (или систем СНН/УВД) могут быть достигнуты путем использования
квалифицированного генератора автокода (ACG). Рассматриваются следующие области
целей документа КТ-178С/КТ-278А: верификация Исходного кода (см. ниже раздел 1.8.3.1),
верификация Исполняемого объектного кода (см. ниже раздел 1.8.3.2) и верификация
выходных данных тестирования ПО (см. ниже раздел 1.8.3.3). В разделе 1.8.3.2.1
представлены сценарии применения концепций, представленных в разделах 1.8.3.2 и 1.8.3.3.
На рисунке D-2 представлена точка зрения на этот часто задаваемый вопрос.
Руководство Р-330
111
Файлы
исходных
данных
Настройка
генератора
автокода ACG
Исходный
код
Исполняемый
объектный код
Рисунок D-2. Процесс разработки с использованием генератора автокода (ACG)
1.8.3.1 Цели верификации Исходного кода
Квалификация генератора автокода (ACG) может позволить упростить, автоматизировать
или исключить некоторые из повторно выполняемых процессов верификации Исходного кода
(цели с 1 по 6 таблицы А-5 документа КТ-178С/КТ-278А) с помощью однократно проводимого
мероприятия квалификации инструмента. В этом разделе рассматриваются характеристики
данных квалификации генератора автокода (ACG), необходимые для обеспечения
возможности достижения целей верификации, касающихся Исходного кода.
Согласно требованиям настоящего документа, все правила трансляции файлов входных
данных в Исходный код определяются в Требованиях к инструменту. Правильность правил
трансляции проверяется путем верификации Требований к инструменту, а правильность их
исполнения проверяется процессом тестирования инструмента, а также процессом
эксплуатационной верификации и валидации инструмента. Сюда включается верификация
того факта, что Исходный код включает только элементы, определенные в Требованиях к
инструменту. При условии, что Требования к инструменту точны и мероприятия верификации
инструмента полны и соответствуют целям верификации Исходного кода, можно сделать
запрос на зачет по целям с 1 по 6 таблицы А-5 документа КТ-178С/КТ-278А со следующими
ограничениями:
•
часть цели 6 таблицы А-5, анализы наихудшего времени исполнения или
использования стека, может быть достигнута только после генерации Исходного кода;
•
также требуется проверять, что инструмент был исполнен на полном наборе файлов
входных данных, чтобы гарантировать, что все требования низкого уровня
переработаны в Исходный код (таблица А-5, цель 5).
1.8.3.2 Цели верификации Исполняемого объектного кода
Обычно правильность Исполняемого объектного кода проверяется посредством тестов,
разработанных на основе требований (таблица А-6 документа КТ-178С/КТ-278А) и
соответствующей верификацией результатов верификации (таблица А-7 документа
КТ-178С/КТ-278А).
Руководство Р-330
112
Даже при использовании квалифицированного генератора автокода (ACG) большая часть
верификации Исполняемого объектного кода остается за рамками квалификации генератора
автокода (ACG). Сюда включается все нижеследующее:
•
тестирование интеграции аппаратуры и программного обеспечения;
•
тестирование интеграции ПО/ПО, в частности интеграция между кодом, созданным
генератором автокода (ACG) и другими частями ПО;
•
тесты на основе требований, для проверки соответствия Исполняемого объектного
кода требованиям к ПО сверх тех, что представлены как входные данные для
генератора автокода (ACG);
•
тесты на основе требований, для библиотек, которые могут быть вызваны Исходным
кодом, создаваемым генератором автокода (ACG);
•
анализ компилятора, как описано в разделе 4.4.2 документа КТ-178С/КТ-278А;
•
дополнительная верификация дополнительного кода, генерируемого компилятором,
компоновщиком или иными инструментами, которые не трассируются напрямую на
Исходный код.
Три потенциальных сценария демонстрируют, как мероприятия, выполняемые в ЖЦ ПО и
в процессе квалификации инструмента, могут достигать целей 3 и 4 таблицы А-6 документа
КТ-178С/КТ-278А (т.е. Исполняемый объектный код соответствует (с точки зрения
нормальных условий и робастности) требованиям низкого уровня).
1.8.3.2.1 Сценарии, использующие генератор автокода (ACG)
В настоящем разделе описывается, как квалифицированный генератор автокода (ACG)
может использоваться в процессе разработки ПО бортовых систем (или систем СНН/УВД).
Приводимые ниже сценарии подчеркивают, как цели документа КТ-178С/КТ-278А могут быть
достигнуты с помощью квалифицированного инструмента или процесса создания ПО
бортовых систем (или систем СНН/УВД).
•
Сценарий 1: Достижение целей тестирования на основе требований низкого уровня
посредством тестовых примеров, основанных на требованиях низкого уровня.
•
Сценарий 2: Достижение целей тестирования на основе требований низкого уровня
посредством тестовых примеров, основанных на требованиях, из которых была
разработана модель (файлы входных данных).
•
Сценарий 3: Достижение целей тестирования на основе требований низкого уровня
посредством квалификации генератора автокода (ACG) и проверки набора
репрезентативных файлов входных данных.
Воплощение этих сценариев в вашем проекте следует тесно
Сертифицирующим/одобряющим органом.
координировать с
В таблице D-4 представлен обзор целей, которые могут быть достигнуты для указанных
трех сценариев, с учетом следующих обозначений:
•
«Инструмент» означает, что цель может быть достигнута процессом квалификации
инструмента;
•
«ПО» означает, что цель может быть достигнута процессом создания ПО бортовых
систем (или систем СНН/УВД);
•
«Инструмент/ПО» означает, что цель может быть частично покрыта процессом
квалификации инструмента, а частично - процессом создания ПО бортовых систем
(или систем СНН/УВД), как описывается в приведенных ниже разделах.
Руководство Р-330
113
Таблица D-4. Обзор некоторых сценариев использования генератора автокода
Цели
Документ Документ КТ- Документ
КТ-178С/
178С1
КТ-178С/
КТ-278А,
КТ-278А,
КТ-278А,
таблица А-5 таблица А-5 таблицаА-6
(цели 1-4)
(цели 5, 6)
(цели 3, 4)
Документ
КТ-178С/
КТ-278А,
таблица А-7
(цели 1, 2, 4)
Документ
Р-330,
таблица Т-0
(цели 5, 7)
Документ
КТ178С/
КТ-278А,
таблица А-7
(цели 5-7)
ПО
Сценарий 1 Инструмент
Инструмент/
ПО
ПО
ПО
ПО
(Примечание 2)
Сценарий 2 Инструмент
Инструмент/
ПО
ПО
ПО
ПО
Инструмент/
(Примечание 2)
ПО
Сценарий 3 Инструмент
Инструмент/
ПО
Инструмент
Инструмент/
ПО
Инструмент
Инструмент/
ПО
Примечание 1. Выполнение целей документа КТ-178С/КТ-278А, не указанных в
настоящей таблице, обычно не зависит от использования генератора
автокода (ACG).
Примечание 2. Эти сценарии демонстрируют, что данные, создаваемые в процессе
разработки ПО бортовых систем (или систем СНН/УВД), могут быть
использованы для достижения целей квалификации инструмента.
Данная концепция будет дополнительно пояснена ниже.
Сценарий 1: Достижение целей тестирования на основе требований низкого
уровня посредством тестовых примеров, основанных на требованиях низкого уровня.
В настоящем сценарии «зачет», запрашиваемый при использовании квалифицированного
инструмента, ограничивается облегчением верификации Исходного кода (т.е. целями с 1 по 6
таблицы А-5 документа КТ-178С/КТ-278А). Тестирование, основанное на требованиях низкого
уровня, выполняется как часть процесса ЖЦ ПО бортовых систем (или систем СНН/УВД) (а
не посредством процесса квалификации инструмента). Основанное на требованиях низкого
уровня тестирование ПО бортовых систем (или систем СНН/УВД) гарантирует, что
«удовлетворены потребности процесса ЖЦ ПО» и что «работа инструмента соответствует
Эксплуатационным требованиям к инструменту».
В настоящем сценарии может быть предложено достигнуть двух следующих целей
процесса квалификации инструмента в рамках процесса создания ПО бортовых систем (или
систем СНН/УВД), а не в рамках процесса квалификации инструмента:
•
работа инструмента соответствует Эксплуатационным требованиям к инструменту
(цель 5 из таблицы Т-0);
•
гарантировать, что потребности процессов ЖЦ ПО удовлетворяются (цель 7 из
таблицы Т-0).
Сценарий 2: Достижение целей тестирования на основе требований низкого
уровня посредством тестовых примеров, основанных на требованиях, из которых
была разработана модель (файлы входных данных).
Файлы входных данных генератора автокода (ACG) могут создаваться в форме
«проектной модели». Документ «Разработка и верификация на основе модели» применяется
к такой проектной модели и включает следующие мероприятия:
•
разрабатывается проектная модель на основании набора требований;
•
верификация модели выполняется посредством комбинации рассмотрений, анализов
и моделирования;
•
тесты разрабатываются на основе требований, из которых была разработана и
выполнена сама модель. Эти тесты также верифицируются, чтобы достичь целей 1 и
2 из таблицы А-7 документа КТ-178С/КТ-278А;
Руководство Р-330
114
•
разрабатываются и выполняются дополнительные
производных требований, содержащихся в модели);
тесты
(специально
для
•
анализ покрытия модели выполняется посредством мероприятия верификации
(тестирования или моделирования), основанного на требованиях, из которых
создается сама модель.
Если достигаются приведенные ниже условия по завершении этих мероприятий, в
частности за счет достижения покрытия требований, содержащихся в модели (цель 4 из
таблицы А-7 документа КТ-178С/КТ-278А), может оказаться ненужным дублировать тесты на
требования, содержащиеся в самой модели, как указано в разделе 6.4 документа
КТ-17 8С/КТ-278А.
•
Примеры верификации, используемые для анализа покрытия модели, эквивалентны
тестовым примерам.
•
Анализы тестовых примеров доказывают покрытие требований, из которых была
создана сама модель.
•
Анализы этих тестовых примеров доказывают покрытие требований, содержащихся в
проектной модели (файлах входных данных) путем анализа покрытия модели,
подразумевая, что данный анализ доказывает, что удовлетворяются критерии для
нормального диапазона и критерии робастности.
Таким образом, можно заявить, что соответствие Исполняемого объектного кода целям
Проектной модели (файлам входных данных) достигнуто.
Тесты на основе требований низкого уровня гарантируют, что потребности процесса ЖЦ
ПО бортовых систем (или систем СНН/УВД) достигнуты, и что работа инструмента
соответствует Эксплуатационным требованиям к инструменту. Таким образом, может быть
предложено достигнуть двух следующих целей процесса квалификации инструмента в рамках
процесса создания ПО бортовых систем (или систем СНН/УВД) вместо процесса
квалификации инструмента:
•
работа инструмента соответствует Эксплуатационным требованиям к инструменту
(цель 5 из таблицы Т-0);
•
гарантировать, что потребности процессов ЖЦ ПО удовлетворяются (цель 7 из
таблицы Т-0).
Сценарий 3: Достижение целей тестирования на основе требований низкого
уровня посредством квалификации генератора автокода (ACG) и проверки набора
репрезентативных файлов входных данных.
1.
Исполняемый объектный код удовлетворяет требованиям низкого уровня
(цель 3 из таблицы А-6 документа КТ-178С/КТ-278А)
Цель соответствия Исполняемого объектного кода файлам входных данных может быть
достигнута в рамках процесса квалификации инструмента. Это цель процесса
эксплуатационной верификации и валидации инструмента, включающая:
•
•
определение набора репрезентативных файлов входных данных, которые включают
как минимум следующее:
о
все допустимые элементы (например, блоки, из которых модель создается) в
соответствии с применимыми стандартами;
о
репрезентативные комбинации этих элементов (классы эквивалентности);
о
пределы стандартов применимых входных данных;
о
допустимую сложность входных данных.
исполнение генератора автокода (ACG) на наборе файлов входных данных и
генерация Исходного кода;
Руководство Р-330
115
•
генерацию Исполняемого объектного кода с помощью той же среды генерации, что
используется для ПО бортовых систем (или систем СНН/УВД), включая тот же самый
компилятор/компоновщик с выбранными опциями;
•
верификацию соответствия
тативных входных данных.
Исполняемого
объектного
кода
файлам
репрезен­
Такой подход может быть предложен в качестве эквивалента тестам на основании
требований низкого уровня, выполняемых в классах эквивалентности файлов входных данных.
Мероприятие, выполняемое в рамках процесса эксплуатационной верификации и валидации
инструмента, включает как минимум разработку тестовых примеров и процедур; исполнение
процедур для получения результатов тестов; а также верификацию всех данных этих тестов
на достижение целей 1, 2 и 4 из таблицы А-7 документа КТ-178С/КТ-278А. Чтобы достигнуть
цели 4 из таблицы А-7 документа КТ-178С/КТ-278А, требуется выполнить анализ покрытия
требований, содержащихся в репрезентативном наборе файлов исходных данных.
Репрезентативный набор файлов входных данных оценивается путем верификации
тестовых данных, включая:
•
демонстрацию покрытия файлов реальных возможных входных данных. Это
выполняется посредством верификации того факта, что репрезентативный набор
файлов входных данных включает: 1) все допустимые элементы; 2) допустимая
степень комбинации допустимых элементов репрезентативна для всех комбинаций,
которые могут использоваться в ПО бортовых систем (или систем СНН/УВД);
3) ограничения на размеры и сложность;
•
необходимо выполнить дополнительный анализ сгенерированного Исходного кода,
чтобы оценить, что он включает все возможные операторы Исходного кода, которые
могут быть сгенерированы генератором автокода (ACG).
Чтобы упростить этот анализ, для файлов входных данных и сгенерированного Исходного
кода определяются меры предосторожности и ограничения в следующем виде:
•
набор допустимых элементов (например, блоки, из которых строятся файлы входных
данных), количество элементов в каждом файле входных данных и допустимые
комбинации могут быть сокращены с помощью стандарта на «файлы входных данных».
Например, в случае, когда файлы входных данных предоставляются в форме моделей,
это может потребовать ограничений моделирования, которые могли бы быть частью
Стандартов проектирования ПО бортовых систем (или систем СНН/УВД);
•
возможный набор операторов в Исходном коде, а также сложность их комбинаций,
требуется сокращать как можно больше. Сокращение требуется для облегчения
демонстрации того факта, что возможные ошибки, которые может внести
компилятор/компоновщик, будут обнаруживаться в процессе эксплуатационной
верификации и валидации инструмента. Это сокращение достигается в процессе
создания Требований к инструменту, которые определяют генерируемый Исходный
код. Например, сложные алгоритмы могут разрабатываться в отдельно
верифицируемых библиотеках, и включаться в генерируемый Исходный код в виде
внешних функций. Другой пример - сокращение числа уровней вложенности в
Исходном коде.
2.
Исполняемый
объектны й
код
является
робастным
по
отнош ению
к требованиям низкого уровня (цель 4, таблица А-6, докум ент КТ-178С/КТ-278А)
Можно предложить достигнуть этой цели с помощью комбинации анализа и тестов. Такой
анализ включает:
•
оценку полноты требований робастности, включаемых в требования к ПО сверх тех,
что являются входными для генератора автокода (ACG);
•
существование и покрытие правил Стандарта на проектирование, применимых к
файлам входных данных, чтобы включить некоторый механизм робастности внутрь
файлов входных данных;
116
Руководство Р-330
•
верификацию соответствия файлов входных данных Стандартам на проектирование,
включая правила механизма робастности;
•
идентификацию методов защитного программирования, вставляемых генератором
автокода (ACG) в генерируемый Исходный код. Эти механизмы следует определить в
Требованиях к инструменту генератора автокода (ACG).
Если потребуется, в дополнение к такому анализу могут быть разработаны тесты.
1.8.3.3 Цели структурного покрытия ПО
Согласно часто задаваемому вопросу № 43 документа DO-248C цель анализа структур­
ного покрытия заключается в том, чтобы:
1) обеспечивать свидетельство того, что структура кода была проверена до степени,
требуемой применимым уровнем ПО;
2)
обеспечить средства для поддержки демонстрации отсутствия незаданных функций, и
3) установить полноту тестирования, основанную на требованиях.
Ниже приводится объяснение того, как квалифицированный генератор автокода (ACG)
может достичь каждую из этих трех целей.
1.8.3.3.1 Верификация структуры кода ПО бортовых систем {или систем СНН/УВД)
Верификацию структуры кода ПО бортовых систем (или систем СНН/УВД) можно
выполнить
с
помощью
квалифицированного
генератора
автокода
в пределах
демонстрируемых процессом квалификации инструмента. Требования к инструменту для
квалифицированного генератора автокода определяют Исходный код, генерируемый для всех
допустимых входных данных. Поэтому процесс верификации инструмента проверяет, что:
•
требования к инструменту корректны и определяют все возможные структуры кода,
которые могут быть сгенерированы из входных данных, допускаемых Стандартами на
проектирование ПО бортовых систем (или систем СНН/УВД);
•
все генерируемые структуры Исходного кода реализуются так, как определено в
Требованиях к инструменту,
1.8.3.3.2 Отсутствие незаданных функций
В настоящем разделе термин «незаданные функции» следует интерпретировать как
функции, относящиеся исключительно к процессам перевода файлов входных данных в
Исходный код. Основное назначение процесса квалификации генератора автокода продемонстрировать, что Исходный код точно реализует файлы входных данных.
Таким образом, наличие незаданной функции, приписываемой к работе инструмента в
сгенерированном
Исходном
коде,
предотвращается
за
счет
использования
квалифицированного генератора автокода в пределах демонстрируемых процессом
квалификации инструмента:
•
требования к инструменту правильны и достаточно точны, чтобы подтвердить, что не
была сгенерирована ни одна незаданная функция;
•
сгенерированный Исходный код реализует файлы выходных данных так,
определено в применимых Требованиях к инструменту.
как
1.8.3.3.3 Полнота тестирования на основании требований
Определение полноты тестирования на основании требований требует дополнительного
мероприятия, которое может меняться в зависимости от описанных выше сценариев.
•
В Сценарии 1 анализ структурного покрытия может выполняться посредством
верификации тестов на основании требований низкого уровня.
Руководство Р-330
117
•
В Сценарии 2 анализ демонстрирует, что анализ покрытия модели предоставляет ту
же уверенность, что и анализ покрытия, выполняемый на уровне Исходного кода. Это
может включать анализ, который оценивает непосредственную трассируемость между
структурой модели и структурой Исходного кода.
•
В Сценарии 3, поскольку тестирование на основании требований низкого уровня
можно заменить на проверки, выполняемые в рамках процесса эксплуатационной
верификации и валидации инструмента, доскональность тестирования на основании
требований достигается посредством процесса эксплуатационной верификации и
валидации инструмента, включая оценку того, что используемый комплект входных
данных является: 1) репрезентативным в части требований к проекту и 2) достаточным
для достижения целей покрытия требований.
Следует отметить, что во всех сценариях анализ структурного покрытия может
выполняться путем верификации тестов на основании требований, выполняемых для
проверки реализации требований к ПО сверх тех, что являются входными данными для
генератора автокода (ACG).
1.9 Вопрос D.9:
Требуется ли квалификация симулятора модели?
Ссылка:
КТ-178С/КТ-278А: раздел 12.2.
Ключевые слова: квалификация инструментов; симулятор модели; симуляция.
Ответ:
Согласно разделу 12.2 документа КТ-178С/КТ-278А, квалификация симулятора модели,
как и для других инструментов, требуется в тех случаях, «когда процессы, указанные в
настоящем документе, исключаются, упрощаются или автоматизируются за счет применения
программного инструмента без верификации его выходных данных, как определено в
разделе 6».
Одним из назначений симуляции является обеспечение повторяемого свидетельства
соответствия модели требованиям, на основании которых данная модель была разработана.
Симуляция включает разработку примеров и процедур симуляции из требований, на
основании которых была разработана сама модель, и последующее исполнение этих
процедур симуляции в конкретной среде.
Мероприятия симуляции модели обычно включают:
1. Разработку примеров симуляции из требований, на основании которых была создана
сама модель.
2.
Разработку процедур симуляции.
3. Исполнение процедур симуляции в конкретной среде для получения результатов
симуляции. Симулятор модели является основным инструментом этой конкретной среды.
4.
Верификацию примеров и процедур симуляции.
5. Верификацию результатов симуляции и объяснение любых отклонений. Это включает
верификацию соответствия выходных данных симулятора модели ожидаемым результатам,
определенным в примере симуляции.
Когда симуляция выполняется только для достижения некоторых целей верификации
модели и выходные данные инструмента (результаты симуляции) проверяются на
корректность относительно входных данных (ожидаемые результаты, определенные в
примерах и процедурах симуляции), Заявитель может предложить не квалифицировать
данный симулятор модели. Это предложение должно основываться на анализе среды
симуляции и доскональности верификации данных симуляции.
Однако если симулятор модели включает некоторые функции, которые, например,
автоматизируют верификацию результатов симуляции или генерирование процедур
118
Руководство Р-330
симуляции, эти функции могут не обнаружить ошибку, а потому их следует квалифицировать,
если выходные данные этих функций не верифицируются.
Кроме того, когда симулятор модели используется как для верификации модели, так и для
других
мероприятий,
следует
учитывать
раздел
11.1
настоящего
документа
(о «многофункциональных инструментах»).