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

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

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

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

Есть ли ограничения по выбору языка программирования?Стандарт не дает каких бы то ни было рекомендаций по выбору языка программирования, но выбор высокоуровневого языка предпочтителен. Высокоуровневые языки считаются более надежными, поскольку код у них прозрачнее, в нем легче прослеживается связь с требованиями дизайна, он детерминирован, устойчив, и на нем можно реализовывать синтаксически сложные конструкции. До недавнего времени для бортового ПО использовался только язык Ada, сейчас более популярны С и С++. Существует бортовое ПО, написанное на языке Java.

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

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