Журнал "Компьютерра" №713 - Компьютерра

Достаточно ли одного тести-рования для выявления всех ошибок, которые могут быть допущены в течение всего жизненного цикла? DO-178B утверждает, что этого недостаточно. Согласно стандарту, за нахождение ошибок и информирование о них отвечает процесс верификации ПО. Этот процесс кроме тестирования должен использовать такие методы верификации, как ревизия и анализ. Под ревизией понимается инспекция выходной информации исследуемого процесса в соответствии с контрольным перечнем. Анализ детально экзаменует функциональность, производительность, источники требований, полноту тестирования, безопасность компонента ПО, а также его взаимоотношения с другими компонентами бортового ПО. Анализ может выявить противоречия и несоответствия в спецификации, требованиях, дизайне и коде. Одним из инструментов анализа могут быть так называемые формальные методы, под которыми понимаются описательные нотации или аналитические методы, используемые для конструирования, разработки и оценки математических моделей поведения системы. Всего стандарт выделяет шесть типов ревизий и анализов: высокоуровневых требований, низкоуровневых требований, архитектуры, исходного кода, результатов интегральных процессов и тестирующих примеров. За тестирование в процессе верификации ПО отвечает процесс тестирования ПО, состоящий из тестов на соответствие установленным требованиям и анализа тестового покрытия, который, в свою очередь, состоит из анализа покрытия тестов и анализа структурного покрытия. Первый проверяет, что у каждого требования есть свой тестирующий пример; целью второго анализа является выявление структур кода, не охваченного тестирующими примерами. Если при анализе структурного покрытия будет выявлен не протестированный код, то решений может быть два: создание тестов, покрывающих этот код, или удаление кода как "мертвого". Конечно, в некоторых языках программирования есть конструкции, которые довольно трудно проверить. Эти особенности языка должны быть описаны в документации. Кроме нормальных тестов, использующих правильные входные данные, стандарт требует проводить тесты на устойчивость. Эти тесты включают установку неправильных начальных значений для переменных, инициализацию данных в ненормальных условиях, сбойную модель входной информации, нарушение временной синхронизации и др.

Какие документы требуются для успешной сертификации? Для сертификации ПО согласно DO-178B должен быть представлен не только исходный и выполняемый объектный код, сопровождающийся подробной документацией. Вот минимальный набор документов, который должен быть представлен сертификационной власти: план программных аспектов сертификации (ППАС), требования ПО, описание дизайна, индекс конфигурации ПО, резюме произведенного ПО. ППАС служит главным средством, используемым сертификационной властью для определения соответствия кандидата на получение сертификации на заявленный уровень ПО. План должен содержать: описание функций и назначения программных и аппаратных средств, обзор ПО, обоснование уровня ПО и методы обеспечения безопасности, описание жизненного цикла, описание всех артефактов. Резюме произведенного ПО - это основной инструмент показа соответствия программного продукта с ППАС и содержащий характеристики ПО, его идентификацию, историю изменений и отчет о соответствии с DO-178B. Производство большого количества детальных документов преследует еще одну важную цель: возможно, что в процессе создания этих документов выявятся проблемы и ошибки в ПО, а также появятся идеи по его модернизации и улучшению.

Сертификация - это дорого? Да. Сертификация ПО согласно стандарту DO-178B - довольно дорогая процедура. Она приводит к увеличению стоимости разработки ПО на 50–200% и напрямую зависит от уровня ПО, на который нацелена сертификация. Стоимость сертифицированного ПО при покупке, для установки на своем оборудовании или использование его как части своего ПО может отличаться в разы от стоимости несертифицированного ПО. Любое, даже самое незначительное изменение ПО, приводит к потере сертификационного доверия к нему сертификационной властью, и это ПО должно быть повторно сертифицировано. Поэтому любое изменение такого ПО обходится очень дорого.

Дает ли программное обеспечение, прошедшее сертификацию, стопроцентную гарантию безопасности? Конечно, нет. Невозможно утверждать со стопроцентной гарантией, что и после прохождения сертификации ПО удовлетворяет всем требованиям безопасности. Но сертификация - это именно тот путь, который напрямую ведет ПО в направлении надежности и безопасности, и эти показатели для такого ПО очень высоки. Достоинства ПО, прошедшего сертификацию, таковы:

• Высокая надежность и безопасность.

• Высокое качество, поддающееся проверке.

• Непротиворечивость.

• Возможность повторного использования.

• Низкая стоимость технического обслуживания.

• Быстрая интеграция с аппаратными средствами.

• Переносимость на другие платформы.

Предполагаются ли изменения в стандарте? Несмотря на всю эволюцию ПО, DO-178В остается основным стандартом сертификации ПО для бортовых систем. Происходит это потому, что DO-178В не содержит требований, касающихся структуры организации ПО, его операционных способностей и возможностей; в нем также отсутствуют ссылки на какие-либо конкретные национальные или международные стандарты. Этот стандарт используется не только в авиации. Например, он успешно применяется в медицине. Существуют планы его использования в атомной промышленности и робототехнике. Начиная с 2005 года ведется разработка нового стандарта сертификации бортового оборудования под названием DO-178С, который предполагается опубликовать в 2008 году. Главное отличие нового стандарта от текущего в том, что в нем будет сделан акцент на объектно-ориентированные технологии, на более широкое использование формальных методов верификации ПО, на моделирование бортовых систем с помощью ПО, будет большая согласованность между процессами жизненного цикла ПО, а также улучшится кооперация DO-178 с другими документами RTCA. Есть большая вероятность, что новая версия стандарта станет основным документом для любых критических систем, где используются программные продукты и где безопасность людей является доминирующим критерием.

FAA утверждает, что, в принципе, можно и не сертифицировать программное или аппаратное обеспечение согласно установленным ею стандартам, а можно предложить какой-либо другой стандарт и провести сертификацию согласно этому стандарту. Но тогда придется доказать сертификационной власти, что новый стандарт лучше с точки зрения надежности и обеспечения безопасности, нежели тот, который он пытается заменить.

Сертификация текста

Перед вами, пожалуй, самый многострадальный текст этого года, переживший жесточайшую авторскую и редакторскую правку. Началось все со статьи Анатолия Титова с поэтичным названием "Сертификация программного обеспечения в авиации. Вопросы по сертификации бортового программного обеспечения согласно стандарту RTCA DO-178B". Из текста было понятно, что автор прекрасно разбирается в предмете, но, по грубым прикидкам, в оригинальном виде эта статья заняла бы полос двадцать, не меньше. Причем большая часть полос состояла бы из пассажей вида "эти требования, в зависимости от их строгости, классифицируются на две категории: контрольную категорию 1 (КК1) и контрольную категорию 2 (КК2), причем КК2 представляет собой подмножество КК1". У нас не было никаких сомнений, что дочитавший статью до конца поймет, наконец, как и зачем сертифицируется программное обеспечение для самолетов, однако в том, что таких счастливчиков окажется относительно немного, сомнений тоже не возникало - тема довольно сложная, и особых скидок на читателей еженедельных журналов автор не делал. По нашей просьбе текст был значительно сокращен (более чем в четыре раза!) и упрощен; кроме того, автор изменил внутреннюю структуру текста - по большому счету, это был даже не правленный, а заново написанный материал на ту же тему. Но даже в таком виде он казался слишком сложным для периодического издания. Мы попытались смягчить самые формально описанные фрагменты, пока наконец не поняли, что чрезмерное упрощение статьи только умаляет сложность задачи, которая стоит перед программистами, работающими на авиаиндустрию. Другими словами, НОСР (не очень сообразительный редактор) вовремя перестал выкидывать из АТ (авторского текста) НК (непонятные куски) и МА (многочисленные аббревиатуры). К слову, во время жизненного цикла статьи автор проявлял поистине ангельское терпение, потому что НОСР отвечал на АП (авторские письма) нерегулярно, чем заметно усложнил процесс сертификации текста. ВГ