|
Сертифицирующий орган
– организация, рассматривающая заявку
Заявителя
о
проведении
Сертификации ПО
и либо самостоятельно, либо путем формирования
специальной комиссии производящая набор процедур направленных на проведение процесса
Сертификации ПО
Заявителя
.
Наблюдательный орган
– комиссия специалистов, наблюдающих за процессами
разработки
Заявителем
сертифицируемой информационной системы и дающих заключение,
о соответствии данного процесса определенным требованиям, которое передается на
рассмотрение в
Сертифицирующий орган
.
91
Сертификация может быть направлена на получение сертификата соответствия, либо
сертификата качества.
В первом случае результатом сертификации является признание соответствия процессов
разработки определенным критериям, а функциональности системы определенным
требованиям. Примером таких требований могут служить руководящие документы
Федеральной службы по техническому и экспортному контролю в области безопасности
программных систем [4,5].
Во втором случае результатом является признание соответствия процессов разработки
определенным критериям, гарантирующим соответствующий уровень качества выпускаемой
продукции и его пригодности для эксплуатации в определенных условиях. Примером таких
стандартов может служить серия международных стандартов качества ISO 9000:2000 (ГОСТ
Р ИСО 9000-2001) [6] или авиационные стандарты DO-178B [7], AS9100 [8], AS9006 [9].
Тестирование
сертифицируемого
программного
обеспечения
имеет
две
взаимодополняющие цели:
Первая цель - продемонстрировать, что программное обеспечение удовлетворяет
требованиям на него.
Вторая цель - продемонстрировать с высоким уровнем доверительности, что
ошибки, которые могут привести к неприемлемым отказным ситуациям, как они
определены процессом, оценки отказобезопасности системы, выявлены в
процессе тестирования.
Например, согласно требованиям стандарта DO-178B, для того, чтобы удовлетворить
целям тестирования программного обеспечения, необходимо следующее:
Тесты, в первую очередь, должны основываться на требованиях к программному
обеспечению;
Тесты должны разрабатываться для проверки правильности функционирования и
создания условий для выявления потенциальных ошибок.
Анализ полноты тестов, основанных на требованиях на программное
обеспечение, должен определить, какие требования не протестированы.
Анализ полноты тестов, основанных на структуре программного кода, должен
определить, какие структуры не исполнялись при тестировании.
Также в этом стандарте говорится о тестировании, основанном на требованиях.
Установлено, что эта стратегия наиболее эффективна при выявлении ошибок. Руководящие
указания для выбора тестовых примеров, основанных на требованиях, включают следующее:
Для достижения целей тестирования программного обеспечения должны быть
проведены две категории тестов: тесты для нормальных ситуаций и тесты для
ненормальных (не отраженных в требованиях, робастных) ситуаций.
Должны быть разработаны специальные тестовые примеры для требований на
программное обеспечение и источников ошибок, присущих процессу разработки
программного обеспечения.
Целью тестов для нормальных ситуаций является демонстрация способности
программного обеспечения давать отклик на нормальные входы и условия в соответствии с
требованиями.
Целью тестов для ненормальных ситуаций является демонстрация способности
программного обеспечения адекватно реагировать на ненормальные входы и условия, иными
словами, это не должно вызывать отказ системы.
Категории отказных ситуаций для системы устанавливаются путем определения
опасности отказной ситуации для самолета и тех, кто в нем находится. Любая ошибка в
программном обеспечении может вызвать отказ, который внесет свой вклад в отказную
ситуацию. Таким образом, уровень целостности программного обеспечения, необходимый
для безопасной эксплуатации, связан с отказными ситуациями для системы.
Существует 5 уровней отказных ситуаций от несущественной до критически опасной.
Согласно этим уровням вводится понятие уровня критичности программного обеспечения.
92
От уровня критичности зависит состав документации, предоставляемой в сертифицирующий
орган, а значит и глубина процессов разработки и верификации системы. Например,
количество типов документов и объем работ по разработке системы, необходимых для
сертификации по самому низкому уровню критичности DO-178B могут отличаться на один-
два порядка от количества и объемов, необходимых для сертификации по самому высокому
уровню. Конкретные требования определяет стандарт, по которому планируется вести
сертификацию.
Do'stlaringiz bilan baham: |
