5 ловушек, грозящих разработчику ПО при реализации проекта по стандарту DO-178C
Документ DO-178C «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники», выпущенный RTCA (Радиотехнической комиссией по аэронавтике), регулирует процесс разработки программного обеспечения в авиакосмической отрасли. Однако этот документ не содержит четких рецептов для практического решения проблем в конкретном проекте. Каждая проектная группа по-своему интерпретирует цели и ограничения DO-178C. Ниже перечислены пять аспектов, которые, исходя из моего опыта, вызывают больше всего споров и недоразумений. Я называю эти аспекты «ловушками», потому что их неправильная реализация окажет ощутимое негативное воздействие на ваш проект.
#1. Ловушка каскадной модели жизненного цикла
Мнение, что DO-178C предписывает тяжеловесную каскадную модель жизненного цикла, ошибочно. Любая методология подойдет, даже гибкая, если она не мешает соблюдать критерии перехода и достигать целей. Выберите то, что лучше всего подходит для вашего проекта и организационной культуры, и добавьте мероприятия, необходимые для достижения соответствия. Не стоит отказываться от деятельности, повышающей ценность вашего продукта, только потому, что ее соответствие стандарту под вопросом. Просто не отражайте такие достижения в отчетах. И наоборот, не бойтесь вносить дополнительные задачи для обеспечения соответствия формальным требованиям. Зачастую неделя, потраченная на конкретные формальные задачи, избавляет от месяца неэффективной и бесполезной работы над искусственными этапами жизненного цикла.#2. Ловушка пренебрежения устойчивостью
Часто об устойчивости вспоминают на последних этапах верификации. Это происходит примерно так: «Ой, нам ведь нужно добавить какие-нибудь тесты на устойчивость, чтобы пройти аудит этапов вовлеченности (SOI)». Программное обеспечение, созданное таким способом, есть не что иное, как колосс на глиняных ногах. Следует с самого начала оценивать устойчивость и трансформировать ее в реальные результаты в течение всего жизненного цикла проекта. Так, важно закладывать в требования аномальные ситуации и меры по их урегулированию, интегрировать соответствующие функции в проект и не позволить неуловимому защищающему коду вмешаться в процесс реализации. Если вы все сделаете правильно, проверка на устойчивость станет лишь одним из элементов стандартного тестирования на основе требований.#3. Ловушка структурного тестирования
DO-178C предписывает тестирование на основе требований. Тем не менее, в разговорах между инженерами часто можно услышать такое словосочетание, как «MC/DC-тесты». Так вот, забудьте это словосочетание. Тесты должны проверять ПО на соответствие требованиям. Покрытие операторов и альтернатив (MC/DC) позволяет лишь продемонстрировать общую взаимную согласованность между требованиями, кодом и тестами, а также их полноту. Наличие пробела в покрытии не обязательно означает, что результат теста неудовлетворительный. Часто требования могут быть неадекватными и страдать отсутствием деталей, или проблему может вызывать неотслеживаемый дополнительный код. Худшее, что вы можете сделать – это синтезировать контрольный пример просто для того, чтобы отработать определенные комбинации программных переменных.#4. Ловушка чрезмерно дотошных квалификационных испытаний инструментальных средств
DO-178C обращает дополнительное внимание на квалификацию инструментальных средств. Этот аспект регулируется специальным дополнением к стандарту DO-330. Однако в квалификации каждого отдельного программного инструментального средства нет необходимости. Кроме того, квалификация инструментального средства является дорогостоящим процессом, а разумно выбранная квалификационная стратегия поможет оптимизировать усилия. Важно понять критерии квалификации инструментальных средств и оценить расходы на каждый уровень квалификации. Иногда вместо квалификации инструментального средства лучше ввести дополнительные этапы, например проверку или анализ. Еще одна ошибка заключается в излишнем доверии к пакету поддержки квалификационных испытаний инструментальных средств, предоставленному поставщиком инструмента. Лишь в редких случаях такой пакет в его исходном состоянии может составлять доказательство успешной квалификации. Подстройка к среде проекта, прогоны квалификационных тестов и анализ результатов могут занять значительное время. Следует учесть эти трудозатраты при выработке стратегии квалификации инструментальных средств.#5. Ловушка опрометчивого использования внешних компонентов
Внедрение в собственное программное обеспечение компонента, разработанного третьей стороной или полученного из открытого источника, часто кажется заманчивой идеей. Однако при этом каждая отдельная часть кода должна соответствовать DO-178. Это означает, что вы не можете, например, подключить библиотеку к проекту без дополнительных действий по подтверждению ее соответствия. Заверения в том, что «сообщество программистов пользуется этой библиотекой давным-давно», не являются достаточно веским аргументом для официального одобрения. Необходим продуманный план адаптации таких компонентов к вашему проекту. Можете использовать пакет поддержки сертификации или проанализировать цикл реинжиниринга, чтобы собрать данные о требованиях к библиотеке кодов и выполнить необходимую верификацию. Не забывайте об этих дополнительных действиях, когда задумываетесь о подключении внешнего компонента. Иногда разработка собственной специализированной библиотеки – более эффективное решение, чем доработка стандартного компонента от третьей стороны.Приведенный выше список не является исчерпывающим. Есть много ловушек в области технологии, конструктива и процесса, в которые компания может попасть на своем пути. Разница заключается в том, что эти пять ошибок особенно дорого вам обойдутся, если будут выявлены на поздних этапах проекта. Мой совет: следите за этими аспектами с самого начала и не забывайте обсудить выбранный подход с шеф-инженером (DER – Designated Engineering Representative), контролирующим соблюдение стандарта.
