Требования к программному обеспечению бортовой аппаратуры и систем КТ-178B, страница 5
Описание файла
PDF-файл из архива "Требования к программному обеспечению бортовой аппаратуры и систем КТ-178B", который расположен в категории "". Всё это находится в предмете "технология разработки программного обеспечения радиолокационных систем" из 11 семестр (3 семестр магистратуры), которые можно найти в файловом архиве МАИ. Не смотря на прямую связь этого архива с МАИ, его также можно найти и в других разделах. Архив можно найти в разделе "остальное", в предмете "технология разработки программного обеспечения радиолокационных систем" в общих файлах.
Просмотр PDF-файла онлайн
Текст 5 страницы из PDF
Если в системе предусмотрен режим загрузки несанкционированных программ илиданных «по умолчанию», то для каждой обособленной компоненты системы следуетсформулировать требования к безопасности использования этого режима, учитывающиевозможное отказное состояние.с. При реализации функции загрузки следует предусмотреть меры, обеспечивающиеобнаружение неправильных комбинаций «программное обеспечение/аппаратноеобеспечение/воздушное судно» и защиту, соответствующую отказному состоянию этой функции.При этом следует учитывать системы и процедуры, используемые для поддержкизагрузки.d.
Если ПО является частью бортового средства отображения, гарантирующего чтовоздушное судно соответствует сертифицированному типу, тогда либо данное ПО должно бытьразработано по уровню ПО, соответствующему самому высокому уровню загружаемого ПО, либо впроцессе оценки безопасности системы должна быть подтверждена целостность проверкиидентификатора конфигурации программного обеспечения.2.6.
Учет требований к системе при верификации ПОТребования к системе разрабатываются на основе соответствующих эксплуатационныхтребований и требований, связанных с безопасностью.Последние являются результатом процесса оценки безопасности системы.При этом учитывается следующее:а. В требованиях к системе указываются две обязательные характеристики ПО:(1) ПО должно выполнять предписанные ему функции так, как это указано в требованиях ксистеме.(2) ПО не должно приводить к ненормальной работе, определенной в процессе оценкибезопасности системы.© НИИАО 2002.Формат А419КТ-178В________________________________________________________________________________Для исключения ненормальной работы формулируются дополнительные требования ксистеме.b.
Эти требования к системе затем трансформируются в требования к ПО высокогоуровня, которые проверяются при выполнении мероприятий процесса верификации ПО.2.7. Учет ПО при верификации системыИнструктивный материал по верификации (проверкам и испытаниям) системы выходит зарамки данного документа.Однако, процессы жизненного цикла ПО поддерживают процесс верификации системы ивзаимодействуют с ним.Для поддержки верификации системы необходимы сведения о построении ПО, связанныес функционированием системы.Верификация системы может обеспечивать значительное покрытие структуры кода.Анализ покрытия испытаний при верификации системы может быть использован и длядостижения целей покрытия различных видов испытаний, рассматриваемых при верификации ПО.© НИИАО 2002.Формат А420КТ-178В________________________________________________________________________________3.
ЖИЗНЕННЫЙ ЦИКЛ ПОВ данном разделе рассматриваются процессы, образующие жизненный цикл ПО, даётсяопределение этого понятия, описываются критерии перехода от одного процесса к другому.Инструктивный материал, изложенный в данном документе, не предписываетпредпочтительный цикл, а описывает отдельные процессы, которые входят в большинство циклови взаимосвязи между ними.Разделение процессов не означает, что оно отражает структуру организации(ий),выполняющей эти работы.Для каждого программного продукта планируется его жизненный цикл(ы), состоящий изописанных ниже процессов.3.1.
Процессы жизненного цикла ПОПроцессами жизненного цикла ПО являются:• Процесс планирования создания ПО, который определяет и координируетмероприятия процессов разработки программного обеспечения и интегральных процессов врамках проекта.Процесс планирования описывается в разделе 4.• Процессы разработки ПО, в результате выполнения которых получается программныйпродукт.Эти процессы включают:- процесс разработки требований к ПО,- процесс проектирования ПО,- процесс кодирования ПО,- процесс интеграции.Эти процессы описаны в разделе 5.• Интегральные процессы, которые гарантируют корректность, управляемость и довериек процессам жизненного цикла ПО и их результатам.Интегральные процессы включают:• процесс верификации ПО,• процесс управления конфигурацией ПО,• процесс гарантии качества ПО,• процесс взаимодействия с сертифицирующим органом..Важно понимать, что интегральные процессы выполняются одновременно с процессомразработки ПО в течение всего жизненного цикла ПО.Описание интегральных процессов даётся в разделах 6...9.3.2.
Определение жизненного цикла ПОПроект, как правило, определяет один или более жизненных циклов ПО посредствомвыбора мероприятий для каждого из процессов, установления их последовательности иназначения ответственных за эти мероприятия.В конкретном проекте последовательность этих процессов определяется егохарактерными особенностями: составом выполняемых функций и сложностью системы, объёмоми сложностью ПО, стабильностью требований, использованием результатов предыдущихразработок, концепциями, положенными в основу разработки, наличием аппаратногообеспечения.Обычная последовательность процессов в цикле следующая: требования, проект,кодирование и интеграция.© НИИАО 2002.Формат А421КТ-178В________________________________________________________________________________Рис. 3-1 иллюстрирует последовательность процессов при разработке несколькихкомпонент одного программного продукта, имеющих различные жизненные циклы.Рис.
3-1. Пример проекта ПО, в котором используются четыре различныепоследовательности разработки.Компонента «W» реализует набор требований к системе посредством разработкитребования к ПО.На основе этих требований составляется проект ПО, который далее воплощается вИсходный код и интегрируется с аппаратурой.Компонента «X» иллюстрирует применение ранее разработанного ПО, используемого насертифицированном воздушном судне или двигателе.Компонента «Y» иллюстрирует применение ПО простой обособленной функции, длякоторой Исходный код можно написать прямо на основании требований к программномуобеспечению.Компонента «Z» иллюстрирует метод разработки, основанный на построении прототипа.Обычно, прототип создается для лучшего понимания требований к ПО и для уменьшенияобъёма доводочных работ и технического риска.Исходные требования используются как базис прототипа.Его работа оценивается в ожидаемых условиях эксплуатации разрабатываемой системы.Результаты оценки используются для уточнения требований.Процессы жизненного цикла ПО могут иметь итерационный характер, то есть, могутповторяться.Время выполнения и степень уточнения при совершении итерационных шаговизменяются в зависимости от степени наращивания функций в процессе разработки, сложности,степени уточнения требований, наличия аппаратуры, наличия обратной связи в предшествующиепроцессы и от других особенностей проекта.Различные этапы жизненного цикла ПО, выбранного для реализации, связаны междусобой последовательным процессом интеграции и мероприятиями процесса верификации.© НИИАО 2002.Формат А422КТ-178В________________________________________________________________________________3.3.
Критерии перехода между процессамиЭти критерии используются для определения, можно ли начинать или повторно начинатьнекоторый процесс.Каждый процесс жизненного цикла ПО определяет мероприятия, связанные с обработкойвходных данных для получения выходных данных.Процесс может порождать обратные связи в другие процессы, а также использоватьобратные связи из других процессов.Формирование обратной связи включает решение вопросов, каким образом информацияраспознается, контролируется и используется для принятия решения принимающим процессом.Примером обратной связи являются сообщения о проблемах.Критерии перехода зависят от запланированной последовательности процессовразработки ПО и интегральных процессов, на них также может влиять уровень ПО.Примерами критериев перехода могут быть следующие:- рассмотрения процесса верификации завершены,- входным объектом является идентифицированная единица конфигурации,- анализ трассируемости для входного объекта завершен.Если удовлетворены критерии перехода для данного вида процесса, то нетнеобходимости в том, чтобы к моменту его начала были получены все входные данные.Инструкции следующие:а.
Если для некоторого процесса входные данные поступают по частям, то припоступлении каждого очередного их набора следует проверить, остались ли в силе предыдущиевыходные данные процессов разработки и верификации???© НИИАО 2002.Формат А423КТ-178В________________________________________________________________________________4. ПРОЦЕСС ПЛАНИРОВАНИЯ СОЗДАНИЯ ПОВ данном разделе описываются цели и мероприятия процесса планирования созданияПО.Результатом процесса планирования являются планы и стандарты, которыенепосредственно определяют процессы разработки ПО и интегральные процессы.Таблица А-1 Приложения А представляет собой сводку целей и результатов процессапланирования для разных уровней ПО.4.1.
Цели процесса планированияНазначением процесса планирования является определение методов и средств,используемых для создания ПО, удовлетворяющего требованиям к системе, а также позволяющихполучить уровень доверия к программному обеспечению, удовлетворяющий требованиям лётнойгодности.Цели процесса планирования следующие:а.