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

С учетом требований к системе и уровня(ей) ПО следует определить мероприятияпроцессов разработки и интегральных процессов жизненного цикла программного обеспечения(п. 4.2).b. Следует определить жизненный(ые) цикл(ы) ПО с указанием взаимосвязей междупроцессами, последовательности их выполнения, схемы обратных связей и критериев перехода(Раздел 3).с. Следует выбрать среду жизненного цикла ПО, включая методы и инструменты, которыебудут использованы в мероприятиях каждого процесса жизненного цикла (п. 4.4).d.

При необходимости следует учесть дополнительные инструктивные материалы,подобные приведенным в Разделе 12.е. Следует установить стандарты на разработку ПО, согласованные с требованиями кбезопасности системы (п. 4.5).f. Планы создания ПО должны соответствовать требованиям, изложенным в п. 4.3 иРазделе 11.g. Следует обеспечить координацию разработки и пересмотра планов ПО (п.

4.3).4.2. Мероприятия процесса планировании создания ПОДля создания ПО, соответствующего требованиям данного документа, определяющимфактором является эффективное планирование.Рекомендации по процессу планирования следующие:а. Планы ПО следует разрабатывать так, чтобы обеспечить своевременное руководстводля персонала, участвующего в процессе разработки и интегральных процессах.Инструктивный материал приведен в п. 9.1.b. Следует сформулировать или выбрать стандарты разработки ПО для использования врассматриваемом проекте.с. Следует выбрать методы и инструменты, обеспечивающие предотвращение ошибок впроцессе разработки ПО.d.

Процесс планирования должен обеспечить координацию процессов разработки иинтегральных процессов таким образом, чтобы обеспечить последовательность стратегий,изложенных в планах.е. При планировании следует предусмотреть процедуру пересмотра планов по мереосуществления проекта.f. Если в системе используется многоверсионное разнородное ПО, то в процессепланирования следует выбрать такие методы и инструменты предотвращения или обнаруженияошибок, которые необходимы для удовлетворения требований к безопасности системы.g. Для завершения процесса планирования планы и стандарты на разработку ПО должнынаходиться под управлением изменениями, а их рассмотрения должны быть завершены (п.

4.6).© НИИАО 2002.Формат А424КТ-178В________________________________________________________________________________h. Если предусматривается наличие отключенного кода (п. 2.4), то процесс планированиядолжен описывать, как отключенный код (выбираемые опции, лётные испытания) будетопределяться, верифицироваться и как с ним нужно обращаться для того, чтобы удовлетворятьтребованиям к безопасности системы.i. Если предусматривается код, модифицируемый пользователем, то в планах и встандартах следует указать процесс, инструменты, среду и данные, доказывающие выполнениеуказаний п.

5.2.3.Некоторые процессы жизненного цикла ПО могут начинаться до завершения процессапланирования, если планы и процедуры для конкретного мероприятия процесса уже имеются.4.3. Планы создания ПОНазначением этих планов является определение средств, обеспечивающих достижениецелей данного документа.Планы определяют также организации (группы исполнителей), которые будут выполнятьуказанные в планах мероприятия.Ниже приведен перечень планов:• «План сертификации ПО» (п. 11.1) является основным документом, в которомпредлагаемые методы разработки программного обеспечения представляютсясертифицирующему органу на утверждение, и документом, в котором указываются методыопределения соответствия требованиям данного документа.• «План разработки ПО» (п.

11.2) определяет жизненный цикл(ы) и среду разработки ПО.• «План верификации ПО» (п. 11.3) определяет средства, с помощью которых будутдостигаться цели процесса верификации.• «План управления конфигурацией ПО» (п. 11.4) определяет средства, с помощьюкоторых будут достигаться цели процесса управления конфигурацией программногообеспечения.• «План гарантии качества ПО» (п. 11.5) определяет средства, с помощью которых будутдостигаться цели процесса гарантии качества программного обеспечения.Инструкции, касающиеся планов создания ПО, следующие:а. Планы следует составлять в соответствии с данным документом.b.

В планах следует определить критерии перехода между процессами цикласоздания ПО, указав при этом:(1) Входные данные процесса, включая обратные связи от других процессов.(2) Мероприятия интегральных процессов, которые могут потребоваться дляреакции на эти входные данные.(3) Доступность инструментов, методов, планов и процедур.с. В планах создания ПО следует установить процедуры внесения изменений впрограммное обеспечение до его применения на сертифицированном воздушном судне илидвигателе.Такие изменения могут быть результатами обратных связей от других процессов и онимогут приводить к необходимости внесения изменений в планы создания ПО.4.4.

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

12.3).4.4.1. Среда разработки ПОСреда, в которой осуществляется разработка ПО, является важным факторомпроизводства ПО высокого качества.Среда же различными путями может оказать и неблагоприятное влияние на бортовое ПО.Например, компилятор может внести ошибки, исказив откомпилированную программу,или редактор связей может не обнаружить ошибку, допущенную при распределении памяти.Инструкции относительно выбора методов и инструментов, используемых для разработкиПО, следующие:а. В процессе планирования следует выбрать среду, минимизирующую риск еёнеблагоприятного влияния на готовое бортовое ПО.b. Выбор квалифицированных инструментов или комбинации инструментов и элементовсреды следует осуществлять таким образом, чтобы достигался необходимый уровеньуверенности, что ошибка, внесенная в одном элементе среды, будет обнаружена в другомэлементе.Приемлемая среда формируется тогда, когда оба элемента используются согласованно.с.

Чтобы свести к минимуму ошибки, вносимые средой, следует предусмотретьмероприятия процесса верификации ПО или стандарты на разработку программного обеспечения,учитывающие уровень программного обеспечения.d. Если Заявитель планирует использовать комбинации инструментов, то всоответствующем плане следует оговорить последовательность их работы.е. Если в проекте предусматривается использование опционных особенностейинструментов разработки ПО, то влияние этих опций должно быть проверено и отражено всоответствующем плане.Примечание: Это особенно важно в тех случаях, когда инструменты непосредственногенерируют часть программного продукта.В этом отношении компиляторы, по видимому, являются наиболее важными изинструментов, подлежащих рассмотрению.© НИИАО 2002.Формат А426КТ-178В________________________________________________________________________________4.4.2.

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

6.4.4.2.b. Компиляторы ряда языков, реализуя присущие им характерные особенности, могутсоздавать объектный код, не трассируемый непосредственно на Исходный код, например,инициализация, встроенные средства обнаружения ошибок, обработчики исключительныхситуаций (п. 6.4.4.2,b).В процессе планирования ПО следует предусмотреть средства обнаружения такогообъектного кода и гарантии верификационного покрытия и определить эти средства всоответствующем плане.с. Если в течение жизненного цикла ПО вводятся новые версии компилятора, редакторасвязей или загрузчика или изменяются опции компилятора, то прежние испытания и анализпокрытия могут стать недействительными.Поэтому при планировании верификации следует предусматривать средства повторнойверификации в соответствии с инструктивным материалом, изложенным в Разделе 6 и п.