7 советов и рецепт успешной квалификации инструментального программного средства

Квалификация (также называемая сертификацией) инструментальных программных средств – это общее требование в области инжиниринга, критического для обеспечения безопасности. Часто этот аспект жизненного цикла разработки порождает много вопросов и проблем. Ниже я представил свой опыт решения подобных задач в авиакосмической отрасли в виде квинтэссенции из семи советов. Мои советы достаточно тесно связаны с применением стандартов RTCA DO-178C и DO-330, но они применимы и в других критичных с точки зрения безопасности областях. Воспользуйтесь этими советами, чтобы повысить эффективность своего проекта.

Совет № 1. Правильно оцените критерии квалификации инструментального программного средства

Обычно квалификация каждого отдельного инструментального программного средства не требуется. Точно определите сценарии использования инструментальных средств и оцените их по критериям квалификации, установленным стандартами. Это напоминает судебный процесс, в котором стандарт играет роль судьи, а вы – адвоката. Вы должны обосновать, что ваше инструментальное средство не требует высокого уровня квалификации или не нуждается в ней совсем. Если ваши аргументы будут разумными и убедительными, то проблем с сертификационным органом не будет.

Совет № 2. Тщательно проанализируйте цепочку инструментальных средств

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

Совет № 3. Квалифицируйте только требуемую функциональность

Опять-таки, тщательно оцените сценарий использования инструментов. Зачастую вам нужно квалифицировать только часть функциональных возможностей. В таком случае подумайте о секционировании этой функциональности, чтобы не пришлось квалифицировать инструментальное средство полностью. Хорошим примером служит разбиение инструментального средства на приложение ГИП (графический интерфейс пользователя) и утилиту командной строки. Последняя реализует бизнес-логику и подлежит квалификации. ГИП разрабатывается менее детально. Обзор журнала командной строки служит «мостом» между этими двумя компонентами. Такой подход может существенно сократить ваши трудозатраты.

Совет № 4. Готовые пакеты квалификации инструментов (COTS) могут составлять проблему

Излишнее доверие к COTS-пакету квалификации инструментальных средств может стоить вам многих бессонных ночей. Инструментальное средство, снабженное квалификационным пакетом от разработчика, не гарантирует беспроблемное существование. В большинстве случаев вам придется проделать некоторые дополнительные операции, такие как проведение квалификационных испытаний и оценка их результатов. Такие добавочные задачи могут отнять достаточно много времени. Более того, пакет квалификации инструментальных средств может потребовать предварительных условий, которые ваша целевая система не сможет обеспечить. Например, может понадобиться файловая система на целевом объекте для хранения промежуточных данных и результатов либо возможность пошаговой отладки. При планировании использования инструментального средства примите во внимание дополнительные трудозатраты по квалификации, а также ограничения пакета.

Совет № 5. Оптимизируйте свои затраты

Оцените общие затраты на квалификацию инструмента. Подсчитайте, сколько средств сэкономит этот инструмент для вашего проекта. Иногда с точки зрения времени и бюджета более эффективно отказаться от квалификации инструментального средства и провести полный цикл верификации в отношении результатов его применения. Это особенно полезно в тех случаях, когда создается уникальный компонент и дальнейшее использование инструментального средства не планируется.

Совет № 6. Вовремя планируйте мероприятия по квалификации инструментального средства

Negotiate tool usage and qualification strategy with the authorities at the start of the project. Conduct tool qualification tasks along with system development. Evaluate COTS tool qualification package before deciding on tool usage. This advice may seem obvious. Many projects, however, start thinking about tool qualification several weeks prior deadline when there are many other functional and developmental troubles. You will not have the luxury to spend valuable time wrapping up qualification things at that time.

Совет № 7. Комбинируйте предыдущие советы

Каждый из этих семи советов ценен сам по себе. Однако вы можете достигнуть лучших результатов, творчески их объединив. Проанализируйте несколько цепочек инструментальных средств и оцените общие затраты по реализации для разных вариантов. Не стесняйтесь добавлять COTS (готовые к использованию покупные инструменты) в цепочки собственных инструментальных средств. Перенесите задачи квалификации из средств разработки в инструменты верификации, добавив дополнительные операции в жизненный цикл вашего продукта. Это похоже на музыку: нот всего семь, а мелодий – тысячи.

И наконец, позвольте мне проиллюстрировать эти семь советов на практическом примере инструментального средства элементов данных параметров. Предположим, что инструментальное средство использует определенные требования, представленные в формальной нотации, для генерации файла двоичных данных. Затем этот файл загружается в целевой объект.

Совет № 1: Это инструментальное средство определенно является инструментом разработки, раз мы используем двоичные выходные данные без дальнейшей проверки и тестирования. Оно подлежит квалификации в соответствии с DO-330 TQL1 – TQL3, в зависимости от уровня гарантии проектирования системы.

Совет № 5: Квалификация инструмента разработки – дорогостоящая задача, которая может перегрузить бюджет.

Советы № 1, № 2 и № 5: Затраты можно сократить, добавив в цепочку дополнительный инструмент верификации (DO-330 TQL5) и немного верификации вручную.

Совет № 3: Можно минимизировать квалификационные мероприятия с помощью изъятия функциональности генерации файлов данных из ГИП, настройки и других компонентов инструмента.

В результате инструментальное средство элементов данных параметров трансформируется в следующие элементы:

ГИП, настройку и другие компоненты, которые можно разрабатывать любым методом быстрой архитектуры. Эти компоненты производят нечто вроде файла базы данных (БД) для дальнейшей генерации, например, в формате .xml. Никакой квалификации не требуется.
Утилита командной строки, которая преобразует файл БД в двоичный файл для целевого объекта. Кроме того, эта утилита создает файл формата .txt, который содержит параметры БД и информацию журнала исполнения в удобочитаемой форме. Точное соответствие между файлом БД, двоичным файлом и удобочитаемым файлом формата .txt квалифицируется по критериям инструмента верификации.
Этот процесс дополняется еще одним шагом проверки. Разработчик добавляет файл БД и текстовый файл в систему управления конфигурацией вместе с двоичными выходными данными. Затем инженер по верификации удостоверяется в том, что информация в текстовом файле соответствует требованиям.

Этот пример показывает, что творческий подход может трансформировать затратную квалификацию инструмента разработки в более простую последовательность верификации и квалификации утилиты. Однако не забывайте о совете № 6 – любой креативный план должен быть одобрен сертификационным органом.