Требования к программному обеспечению бортовой аппаратуры и систем КТ-178B, страница 8

Проектирование ПО, модифицируемого пользователемНиже изложен инструктивный материал, относящийся к ПО, предназначенному длямодификации пользователем.Модифицируемой компонентой является такая компонента ПО, которая предназначенадля внесения в неё изменений пользователем, немодифицируемой – та, которая непредназначена для этой цели.© НИИАО 2002.Формат А431КТ-178В________________________________________________________________________________Сложность модифицируемого пользователем ПО может быть разной.Примерами являются: отдельный бит памяти, используемый для выбора одной из двухопций оборудования, таблица сообщений, а также область памяти, которая может бытьпрограммируемой, (с последующей компиляцией и редактированием связей) для реализациифункций технического обслуживания воздушного судна.Модифицируемые пользователем компоненты могут быть составными частями ПОлюбого уровня.При проектировании ПО, модифицируемого пользователем, следует руководствоватьсяследующими инструкциями:а.

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

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

Цель процесса кодированияЦель процесса кодирования следующая:а. Должен быть разработан исходный код, трассируемый, верифицируемый,непротиворечивый и правильно реализующий требования низкого уровня.5.3.2. Мероприятия процесса кодированияВходными данными процесса кодирования являются требования низкого уровня иархитектура ПО, полученные из процесса проектирования, а также «План разработки ПО» и«Стандарты на кодирование».К процессу кодирования можно перейти или повторно перейти после того, какудовлетворены запланированные критерии перехода.Исходный код создается этим процессом на основе архитектуры ПО и требований низкогоуровня.Основными результатами процесса кодирования являются «Исходный код» (п.

11.11) иобъектный код.Процесс кодирования является завершенным, когда его цели и цели соответствующихинтегральных процессов достигнуты.Инструкции для этого процесса следующие:а. «Исходный код» должен реализовывать требования низкого уровня и соответствоватьархитектуре ПО.b. «Исходный код» должен соответствовать «Стандартам на кодирование».с. «Исходный код» должен быть трассируемым на «Описание проекта ПО».d. Недостаточные или неправильные входные данные, выявленные в процессекодирования, следует возвратить в процесс разработки требований к ПО, процесс проектированияПО или в процесс планирования создания ПО для внесения ясности или поправок.© НИИАО 2002.Формат А432КТ-178В________________________________________________________________________________5.4.

Процесс интеграцииВ процессе интеграции используется целевой вычислитель, а также Исходный код иобъектный код из процесса кодирования, данные редактирования связей и загрузки.В результате создается интегральная бортовая система или оборудование.5.4.1. Цель процесса интеграцииЦель процесса интеграции следующая:а. Исполняемый объектный код загружается в целевой вычислитель для интеграции ПО иаппаратных средств.5.4.2. Мероприятия процесса интеграцииПроцесс интеграции состоит из интеграции ПО и интеграции ПО и аппаратных средств.К процессу интеграции можно перейти или повторно перейти после того, какудовлетворены запланированные критерии перехода.Входными данными процесса интеграции являются архитектура ПО, полученная изпроцесса проектирования, а также исходный код и объектный код из процесса кодирования.Результатами процесса интеграции являются:«Исполняемый объектный код», описанный в п.

11.12, иданные для редактирования связей и загрузки.Процесс интеграции является завершенным, когда его цели и связанные с ним целиинтегральных процессов достигнуты.Инструкции, относящиеся к этому процессу, следующие:а. «Исполняемый объектный код» должен генерироваться из «Исходного кода» иданных для редактирования связей и загрузки данных.b. Для интеграции ПО и аппаратных средств программное обеспечение должно бытьзагружено в целевой вычислитель.с.

Недостаточные или неправильные входные данные, выявленные в процессеинтеграции, следует возвратить в процесс разработки требований к ПО, процесс проектированияПО, процесс кодирования или в процесс планирования создания ПО для внесения ясности илипоправок.5.4.3. Обстоятельства, которые следует учитывать в процессе интеграцииНиже изложены соображения, касающиеся отключенного кода и «заплат» в ПО.Бортовая система может быть спроектирована таким образом, чтобы предусматривалосьсразу несколько ее конфигураций, не все из которых предназначены для использования в каждомконкретном применении такой системы.В связи с этим в ней может быть предусмотрен отключенный (невыполняемый) код илинеиспользуемые данные.Указанные разновидности кода отличаются от «мертвого кода», определение которогодано в Приложении В и который рассмотрен в п.

6.4.4.3.Инструкции по вопросу отключенного кода и «заплат» следующие:а. Следует предоставить достаточное доказательство того, что в условиях, для которыхэто не предусмотрено, отключенная программа не будет выполняться.Ненамеренное выполнение отключенного кода вследствие ненормальных длясистемы условий - это то же самое, что ненамеренное исполнение включенногокода.b. Методы обращения с отключенными программами должны соответствовать указаниям,изложенным в планах создания ПО.© НИИАО 2002.Формат А433КТ-178В________________________________________________________________________________с.

«Заплаты» не следует использовать в ПО, предлагаемом для использования насертифицированном воздушном судне или двигателе с целью реализации изменений втребованиях или архитектуре, а также изменений, признанных необходимыми в результатеверификации программного обеспечения.«Заплаты» можно использовать в ограниченных конкретно рассматриваемых случаях,например, для исправления известных недостатков среды разработки ПО, например, известногонедостатка компилятора.d. Если «заплата» всё же используется, то:(1) Следует подтвердить, что процесс управления конфигурацией ПО позволяетотслеживать эту «заплату»;(2) Следует провести регрессивный анализ, позволяющий доказать, что «заплата»удовлетворяет всем целям ПО, разработанного принятыми методами;(3) Обосновать применение «заплат» в «Итоговом заключении о ПО».5.5.

ТрассируемостьИнструкции по вопросу трассируемости следующие:а. Следует обеспечить трассируемость между требованиями к системе и требованиями кПО для того, чтобы дать возможность проверки полной реализации требований к системе исделать обозримыми производные требования.b. Следует обеспечить трассируемость между требованиями низкого и высокого уровнейдля того, чтобы сделать обозримыми производные требования и архитектурные решения,принятые в процессе проектирования ПО, а также дать возможность проверки полной реализациитребований высокого уровня.с. Следует обеспечить трассируемость между «Исходным кодом» и требованиями низкогоуровня для того, чтобы сделать возможной проверку отсутствия незадокументированных частей в«Исходном коде» и проверку полной реализации требований низкого уровня.© НИИАО 2002.Формат А434КТ-178В________________________________________________________________________________6.

ПРОЦЕСС ВЕРИФИКАЦИИ ПОВ данном разделе рассматриваются цели и мероприятия процесса верификации ПО.Верификация – это техническая оценка результатов как процессов разработки ПО, так исобственно процесса верификации.Процесс верификации выполняется согласно тому, как это было определено процессомпланирования создания ПО (Раздел 4), и согласно «Плану верификации ПО» (п. 11.3).Верификация – это не просто испытания.Испытания, вообще говоря, не могут доказать отсутствие ошибок.Вследствие этого, в последующих подразделах используется термин «верификация»вместо термина «испытания», когда рассматриваемые цели процесса верификации, в общемслучае, являют собой сочетание рассмотрении, анализов и испытаний.Таблицы от А–3 до А–7 Приложения А представляют собой итоговую сводку целей ирезультатов для процесса верификации ПО с учетом уровня ПО.Примечание: Для ПО более низкого уровня меньшее внимание уделяется:• верификации требований низкого уровня,• верификации архитектуры ПО,• полноте испытаний (степени покрытия тестами),• контролю процедур верификации,• независимости мероприятий процесса верификации ПО,• перекрытию мероприятий верификации ПО, т.е.