Требования к программному обеспечению бортовой аппаратуры и систем КТ-178B (1015672), страница 11
Текст из файла (страница 11)
Испытания интеграции ПО на основе требований.Этот метод испытаний должен быть сконцентрирован на взаимных связях междуотдельными требованиями к ПО и на воплощении этих требований в архитектуре программногообеспечения.Целью этого вида испытаний является гарантия того, что компоненты ПО правильновзаимодействуют друг с другом.Этот метод может быть основан на расширении состава требований припоследовательной интеграции компонент программы с соответствующим увеличением количестватестовых примеров.Типичными ошибками, выявляемыми с помощью данного метода испытаний, являются:• Неправильная инициализация переменных и констант.• Ошибки в передаче параметров.• Нарушение целостности данных, особенно глобальных данных.• Неадекватная для всей цепи вычислений разрешающая способность разрядной сетки.• Неправильное упорядочение событий и операций.с. Испытания на основе требований низкого уровняЭтот метод испытаний должен быть сконцентрирован на демонстрации соответствиякаждой компоненты ПО относящимся к ней требованиям низкого уровня.Целью этого вида испытаний является гарантия соответствия компонент ПОпредъявляемым к ним требованиям низкого уровня.Типичными ошибками, выявляемыми с помощью этого метода испытаний, являются:• Неспособность алгоритма удовлетворить требование к ПО.• Неправильные операторы циклов.• Неправильные логические решения.• Неспособность правильно обработать допустимые комбинации входных условий.• Неправильные реакции на потерю или порчу входных данных.• Неправильная обработка исключительных ситуаций – таких, как арифметические сбоиили нарушения границ массивов.• Неправильная последовательность вычислений.• Неудовлетворительные характеристики алгоритма, такие, как точность, сходимость идругие.© НИИАО 2002.Формат А443КТ-178В________________________________________________________________________________6.4.4.
Анализ полноты испытанийАнализ полноты испытаний представляет собой двухэтапный процесс, состоящий изанализа покрытия требований и анализа структурного покрытия.На первом этапе проводится анализ тестовых примеров, связанных с требованиями к ПО,с целью подтверждения, что выбранные тестовые примеры удовлетворяют установленнымкритериям.На втором этапе подтверждается, что тестовые процедуры на основе требованийпозволяют проверить структуру кода.Анализ структурного покрытия может показать несоответствие установленным критериям.Дополнительный материал по таким ситуациям, как мертвый код, изложен в п. 6.4.4.3.6.4.4.1. Анализ тестовых покрытий на основе требованийЦель данного анализа – определить, насколько хорошо испытания на основе требованийпроверили реализацию требований к ПО.Этот анализ может выявить необходимость дополнительных тестовых примеров наоснове требований к ПО.При выполнении этого анализа следует показать, что:а.
Для каждого требования к ПО есть тестовые примеры.b. Тестовые примеры удовлетворяют критериям нормальных и робастных испытаний, какопределено в п. 6.4.2.6.4.4.2. Анализ структурного покрытияЦель данного анализа – определить, какая структура кода (программы) не былапроверена тестовыми процедурами на основе требований.Тестовые примеры на основе требований могут не полностью проверять структурупрограммы, поэтому и выполняется анализ структурного покрытия и проводится дополнительнаяверификация для обеспечения структурного покрытия.Инструкции следующие:а.
Анализ должен подтвердить степень структурного покрытия, соответствующуюуровню ПО.b. Анализ структурного покрытия может быть выполнен по «Исходному коду», заисключением, когда: уровень ПО есть А и компилятор генерирует объектный код, который нетрассируется прямо на операторы «Исходного кода».В этом случае следует провести дополнительную верификацию объектного кода, чтобыубедиться в правильности таких сгенерированных последовательностей.Примером объектного кода, который не прямо трассируется в «Исходный код», являетсягенерируемая компилятором проверка границ массива.с. В результате данного анализа следует подтвердить связь между компонентами кода поданным и по управлению.6.4.4.3.
Устранение недостатков по результатам анализа структурного покрытияВ результате анализа структурного покрытия может быть выявлена структура кода, неработавшая при проведении испытаний.В этом случае требуется выполнить дополнительные мероприятия процессаверификации.
Такая неисполняемая структура может быть результатом:а. Недостатков в тестовых примерах на основе требований или процедур.Для обеспечения отсутствующего покрытия следует дополнить тестовые примеры илиизменить тестовые процедуры. Может потребоваться пересмотр методов анализа покрытия наоснове требований.© НИИАО 2002.Формат А444КТ-178В________________________________________________________________________________b. Недостаточностью требований к ПО.В этом случае такие требования следует уточнить, разработать дополнительныетестовые примеры и выполнить дополнительные тестовые процедуры.с. Наличия мертвого кода.В этом случае следует удалить такой код и оценить последствия и необходимостьповторной верификации.d.
Наличия отключенного кода.В этом случае, если отключенный код не предназначен для выполнения ни при какой изконфигураций ПО, используемых на данном воздушном судне или двигателе, следует показать спомощью сочетания анализа и испытаний, что средства, позволяющие ненамеренно включитьвыполнение такого кода, защищены, изолированы или исключены.Если отключенный код выполняется только при определённых конфигурациях среды,целевого вычислителя, то следует установить конфигурацию, необходимую для нормальноговыполнения этого кода, и разработать дополнительные тестовые примеры и процедуры дляобеспечения требуемого покрытия.© НИИАО 2002.Формат А445КТ-178В________________________________________________________________________________7. ПРОЦЕСС УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ ПОВ данном разделе рассматриваются цели и мероприятия процесса управленияконфигурацией (УКПО).Процесс УКПО осуществляется так, как это определено в процессе планированиясоздания ПО (Раздел 4) и указано в «Плане управления конфигурацией ПО» (п.
11.4).Результаты процесса УКПО заносятся в «Протоколы УКПО» (п. 11.18) или в другиедокументы жизненного цикла ПО.Таблица А-8 Приложения А представляет собой итоговую сводку целей и результатовпроцесса УКПО.7.1. Цели процесса управления конфигурацией ПОПроцесс УКПО во взаимодействии с другими процессами жизненного цикла программногообеспечения способствует достижению следующих общих целей:а. Обеспечить определенную и управляемую конфигурацию ПО в течение всегожизненного цикла.b. Обеспечить возможность тиражирования «Исполняемого объектного кода» припроизводстве ПО или воспроизведения кода в случае необходимости его исследования илиизменений.с. Обеспечить контроль входных и выходных данных процесса в течение жизненногоцикла ПО, гарантирующий согласованность и повторяемость выполняемых мероприятий.d.
Ввести известные точки для рассмотрений, оценки состояний, управленияизменениями посредством контроля единиц конфигурации и для установления базовых версий.е. Обеспечить организацию мероприятий, гарантирующих, что проблемы принимаются вовнимание, изменения регистрируются, утверждаются и реализуются.f. Обеспечить доказательство одобрения ПО посредством контроля выходных данныхпроцессов жизненного цикла ПО.g. Способствовать оценке соответствия программного продукта требованиям.h. Гарантировать, что для единиц конфигурации установлены надёжное (с точки зренияфизической сохранности) архивирование, восстановление и управление (контроль).Цели УКПО не зависят от уровня ПО.Однако, могут существовать две категории данных жизненного цикла ПО, основанные наприменяемых видах контроля УКПО (п.
7.3) к этим данным.7.2. Мероприятия процесса управления конфигурацией ПОПроцесс УКПО включает мероприятия по идентификации конфигурации, управлениюизменениями, установлению базовых версий и архивированию программного продукта вместе сотносящимися к нему данными жизненного цикла.В приведенном ниже инструктивном материале определены цели каждого мероприятияпроцесса УКПО.Процесс УКПО не завершается после выдачи Заключения о соответствии ПОтребованиям настоящего документа, а продолжается в течение всего срока эксплуатациибортовой системы или оборудования.7.2.1. Идентификация конфигурацииЦель мероприятия по идентификации конфигурации – однозначно определить каждуюединицу конфигурации (и её последовательные версии), так чтобы обеспечить основу дляуправления единицами конфигурации и ссылки на них.© НИИАО 2002.Формат А446КТ-178В________________________________________________________________________________Инструкции следующие:а.
Следует ввести идентификацию конфигурации для данных жизненного цикла ПО.b. Идентификацию конфигурации следует ввести для каждой единицы конфигурации, длякаждой отдельно контролируемой компоненты единицы конфигурации и для комбинаций единицконфигурации, образующих программный продукт.с. Единицы конфигурации следует идентифицировать в составе конфигурации до началауправления изменениями и регистрации данных трассируемости.d.
Единицы конфигурации следует идентифицировать в составе конфигурации до:ее использования в других процессах жизненного цикла ПО,ссылок в других данных жизненного цикла ПО,использования для производства и загрузки ПО.е. Если идентификация программного продукта не может быть определена с помощьюфизической проверки (например, проверки маркировочной таблички на блоке), то в этом случаеидентификация конфигурации должна содержаться в «Исполняемом объектном коде» и должнабыть доступна для других элементов бортовой системы или оборудования.Это может быть применимо и к ПО, загружаемому на месте эксплуатации (п. 2.5).7.2.2.
Базовые версии и трассируемостьЦель введения базовых версий – заложить основу для дальнейших мероприятийжизненного цикла ПО, дать возможность ссылаться на эти версии, контролировать их иобеспечить трассируемость между единицами конфигурации.Инструкции следующие:а. Базовые версии следует установить для единиц конфигурации, используемых дляполучения сертификационного зачета.(Для дополнительного контроля за мероприятиями жизненного цикла ПО могут вводитьсяпромежуточные базовые версии.).b. Следует установить базовую версию программного продукта и дать её определение в«Каталоге комплектации ПО» (п. 11.16).Примечание: ПО, модифицируемое пользователем, не включается в базовую версиюпрограммного продукта, за исключением компонент, обеспечивающих его защиту, и пограничныхкомпонент.Поэтому ПО, модифицируемое пользователем, может подвергаться модификации безвоздействия на идентификацию конфигурации базовой версии программного продукта.с.
Следует установить базовые версии контролируемых библиотек ПО (на бумажныхносителях, электронных или других) для гарантии их целостности.Если базовая версия установлена, то следует обеспечить её защиту от изменений.d. Производную версию следует разрабатывать на основе установленной базовой версиив соответствии с мероприятиями управления изменениями.е. Если требуется получить сертификационный зачет для мероприятий жизненного циклаПО или данных, связанных с разработкой предыдущей базовой версии, следует обеспечитьтрассируемость между текущей и предыдущей базовыми версиями.f.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
