Ўзбекистон республикаси ахборот технологиялари ва коммуникацияларини ривожлантириш вазирлиги муҳаммад ал-хоразмий номидаги

Сертифицирующий орган
– организация, рассматривающая заявку 
Заявителя
о 
проведении 
Сертификации ПО
и либо самостоятельно, либо путем формирования 
специальной комиссии производящая набор процедур направленных на проведение процесса 
Сертификации ПО
Заявителя
. 
Наблюдательный орган
– комиссия специалистов, наблюдающих за процессами 
разработки 
Заявителем 
сертифицируемой информационной системы и дающих заключение, 
о соответствии данного процесса определенным требованиям, которое передается на 
рассмотрение в 
Сертифицирующий орган
. 

---

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

---

92 
От уровня критичности зависит состав документации, предоставляемой в сертифицирующий 
орган, а значит и глубина процессов разработки и верификации системы. Например, 
количество типов документов и объем работ по разработке системы, необходимых для 
сертификации по самому низкому уровню критичности DO-178B могут отличаться на один-
два порядка от количества и объемов, необходимых для сертификации по самому высокому 
уровню. Конкретные требования определяет стандарт, по которому планируется вести 
сертификацию.