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

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

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

Стандарты на разработку ПО должны предоставлять возможность единообразногопроектирования и реализации заданного программного продукта или комплекта продуктов.с. Стандарты на разработку ПО должны запрещать использование конструкций илиметодов, приводящих к результатам, не поддающимся проверке или не совместимым стребованиями безопасности.Примечание: В стандартах разработки следует учитывать предыдущий опыт.В них для контроля сложности могут быть включены ограничения и правила, относящиесяк методам разработки, проектирования и кодирования.Для улучшения робастности (сохранение внешних характеристик системы управленияпри изменении ее внутренних характеристик) могут быть учтены проверенные на практикеприёмы «надежного» кодирования.4.6.

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

Результаты процесса планирования создания ПО согласованы и соответствуютинструкциям, изложенным в Разделе 11.© НИИАО 2002.Формат А428КТ-178В________________________________________________________________________________5. ПРОЦЕССЫ РАЗРАБОТКИ ПОВ данном разделе рассматриваются цели и мероприятия процессов разработки ПО.Эти процессы выполняются так, как это определено процессом планирования созданияпрограммного обеспечения (Раздел 4) и «Планом разработки ПО» (п.

11.2).Таблица А-2 Приложения А представляет собой итоговую сводку целей и выходныхданных процессов разработки ПО для программного обеспечения разных уровней.Процессы разработки ПО следующие:• Процесс разработки требований к ПО• Процесс проектирования ПО• Процесс кодирования• Процесс интеграцииВ процессах разработки ПО формулируются требования одного или более уровней.Требования высокого уровня получаются непосредственно из анализа требований ксистеме и архитектуры её построения.Обычно на дальнейших этапах проектирования они детализируются и формулируются ввиде требований более низкого уровня или ряда последовательных более низких уровней.Однако, если Исходный код генерируется непосредственно по требованиям высокогоуровня, то принимается, что они же являются и требованиями низкого уровня, и к ним примениминструктивный материал, относящийся к последним.Разработка архитектуры ПО связана с принятием решений относительно структуры.В процессе проектирования ПО определяется его архитектура и формулируютсятребования низкого уровня.Это – такие требования, по которым непосредственно, без дополнительной информации,можно составить исходный код.Каждый процесс разработки ПО может порождать производные требования.Это такие требования, которые не трассируются непосредственно на требованиявысокого уровня.Примером производного требования является требование разработать программуобработки прерываний, зависящую от особенностей выбранного целевого вычислителя.Производные требования могут быть включены в требования как высокого, так и низкогоуровней.Влияние производных требований на требования к безопасности определяется впроцессе оценки безопасности системы.5.1.

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

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

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

Если входные данные для процесса разработки требований к ПО признанынедостаточными или неверными, то их следует вернуть на входы соответствующих процессов длявнесения ясности или поправок.с. Каждое требование к системе, отнесенное к ПО, следует включить в требованиявысокого уровня.d. Следует определить те требования высокого уровня, связанные с требованиями ксистеме и отнесенные к ПО, которые введены для предотвращения опасности применениясистемы.е. Требования высокого уровня должны удовлетворять «Стандартам на разработкутребований к ПО» и быть проверяемыми и согласованными.f. Требования высокого уровня следует устанавливать в количественной форме суказанием допусков там, где это применимо.g. В требованиях высокого уровня не следует описывать детали разработки иверификации, за исключением описания установленных и обоснованных проектных ограничений.h. Каждое требование к системе, отнесенное к ПО, должно быть трассируемо на одно илиболее требований высокого уровня.i.

Каждое требование высокого уровня ПО должно быть трассируемо на одно или болеетребований к системе, за исключением производных требований.j. Производные требования высокого уровня должны быть переданы в процесс оценкибезопасности системы.5.2.

Процесс проектирования ПОТребования к ПО высокого уровня уточняются в течение одной или более итерацийпроцесса проектирования ПО для определения его архитектуры и требований низкого уровня, покоторым можно составить исходный код.5.2.1. Цели процесса проектирования ПОЦелями этого процесса являются:а. Архитектура ПО и требования низкого уровня разрабатываются на основетребований высокого уровня;b. Производные требования низкого уровня направляются в процесс оценки безопасностисистемы.© НИИАО 2002.Формат А430КТ-178В________________________________________________________________________________5.2.2. Мероприятия проектирования ПОВходными данными для процесса проектирования ПО являются:«Требования к ПО»,«План разработки ПО» и«Стандарты на проектирование ПО».Требования высокого уровня используются для разработки архитектуры ПО и требованийнизкого уровня после того, как удовлетворяются указанные в плане критерии перехода.Это может быть связано с формулированием требований одного или нескольких болеенизких уровней.Основным результатом этого процесса является документ «Описание проекта ПО» (п.11.10), в котором дается описание архитектуры программного обеспечения и формулируютсятребования низкого уровня.Процесс проектирования ПО считается завершенным, когда его цели достигнуты идостигнуты цели интегральных процессов.Инструкции для этого процесса следующие:а.

Требования низкого уровня и архитектура ПО, разработанные в процессепроектирования, должны удовлетворять «Стандартам на проектирование ПО», бытьтрассируемыми, проверяемыми и согласованными.b. Чтобы гарантировать отсутствие нарушений требований высокого уровня, следуетустановить и проанализировать производные требования.с. Мероприятия процесса проектирования ПО могут вносить определенные типы отказовили, наоборот, предотвращать другие.Использование обособления или других архитектурных решений может изменить уровниПО отдельных его компонент.В таких случаях следует определить дополнительные производные требования иобеспечить их анализ в процессе оценки безопасности системы.d.

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