Т ребования верхнего уровня к ПО уточняют далее в процессе проектирования ПО одной или несколькими итерациями, чтобы разработать архитектуру ПО и требования нижнего уровня, которые могут быть непосредственно использованы для получения исходного кода.
7.2.1 Цели процесса проектирования ПО
Ц ели данного процесса состоят в том, чтобы:
а) разработать архитектуру ПО и требования нижнего уровня на основе требований верхнего уровня;
б) оценить с точки зрения безопасности системы производные требования нижнего уровня.
7.2.2 Состав работ, выполняемых в процессе проектирования ПО
В ходными данными процесса проектирования ПО являются требования к ПО, План разработки ПО и стандарты на процесс проектирования ПО. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, эти входные данные используются в процессе проектирования для разработки архитектуры ПО и требований нижнего уровня. Требования нижнего уровня могут включать в себя одно или несколько требований более низких уровней. Основным выходным результатом процесса является документ «Описание проекта ПО» (12.16), который содержит описание архитектуры ПО и требования нижнего уровня. Если это предусмотрено условиями контракта, часть проекта, имеющая отношение к интерфейсам, может быть включена в документ «Описание проекта интерфейса» (12.17), а часть проекта, имеющая отношение к базам данных, может быть включена в документ «Описание проекта базы данных» (12.18). Процесс проектирования ПО считают завершенным, когда удовлетворены его цели и цели связанных с ним интегральных процессов. Процесс проектирования ПО должен обеспечивать следующее:
- архитектура ПО и требования нижнего уровня, разработанные в процессе проектирования ПО, должны соответствовать стандартам на процесс проектирования ПО и быть прослеживаемыми, верифицируемыми и непротиворечивыми;
- производные требования должны быть определены и проанализированы для гарантии того, что они не противоречат требованиям верхнего уровня;
- работы процесса проектирования ПО могут привести к появлению возможных отказов в ПО или, наоборот, предотвратить их. Использование метода разбиения или других архитектурных методов при проектировании ПО может изменить установленный уровень критичности ПО для некоторых компонентов ПО. В таких случаях должна быть определена информация о производных требованиях, позволяющая обеспечить процесс оценки безопасности системы;
- необходимо контролировать поток управления и поток данных, когда это связано с требованиями безопасности;
- реакция на отказные ситуации должна быть согласована с требованиями безопасности;
- при обнаружении в процессе проектирования ПО неадекватных или некорректных входных данных следует осуществлять обратную связь с процессами жизненного цикла системы, с процессами определения требований к ПО или с процессом планирования ПО для исследования проблемы или исправления входных данных.
П римечание - На современном уровне развития технологии разработки ПО не применяют количественную корреляцию между сложностью и достигаемой безопасностью. Тем не менее, в процессе проектирования ПО необходимо избегать сложных конструкций, поскольку с увеличением сложности ПО становятся более трудными верификация и доказательство того, что удовлетворены цели безопасности.
7.2.3 Проектирование модифицируемого пользователем ПО
Д ля разработки ПО, которое предназначено для модификации пользователями, необходимы дополнительные требования. Модифицируемый компонент - часть ПО, которая предназначена для изменения пользователем, а немодифицируемый компонент не допускает изменения пользователем. Модифицируемое пользователем ПО может широко варьироваться по сложности. ПО любого уровня может включать в себя модифицируемые компоненты. Требования для проектирования модифицируемого пользователем ПО следующие:
- немодифицируемый компонент должен быть защищен от модифицируемого компонента, чтобы предотвратить влияние на безопасность функционирования немодифицируемого компонента. Эта защита может быть обеспечена аппаратными, программными, инструментальными средствами, используемыми для реализации изменений, или их комбинацией;
- нужно показать, что специально предназначенные для реализации изменений средства являются единственно допустимыми для модификации.
7.2.4 Проектные решения уровня ЭКПО
Р азработчик должен определить и зарегистрировать проектные решения уровня ЭКПО. Результаты должны быть включены в раздел проектных решений уровня ЭКПО документов проектирования ПО (12.16, 12.17, 12.18).
Р азработчик должен определить и зарегистрировать проект архитектуры ПО (идентифицировать модули ПО, входящие в ЭКПО, их интерфейсы и концепцию их совместного выполнения) и проследить соответствие между модулями ПО и требованиями к ЭКПО. Результат этих работ должен быть включен в разделы документа «Описание проекта ПО», посвященные архитектуре ПО и прослеживанию соответствия. В зависимости от условий контракта часть проекта, имеющая отношение к интерфейсам, может быть включена либо в Описание проекта ПО, либо в Описание проекта интерфейса.
Р азработчик должен разработать и зарегистрировать описание каждого модуля ПО. Результат этих работ должен быть включен в соответствующий раздел документа «Описание проекта ПО». В зависимости от условий контракта часть проекта, которая относится к интерфейсам, может быть включена либо в Описание проекта ПО, либо в Описание проекта интерфейса. В свою очередь проект программных модулей, которые являются базами данных или осуществляют доступ к базам данных или управление ими, может быть включен либо в Описание проекта ПО, либо в Описание проекта базы данных.
П римечание - Если ЭКПО разрабатывают для нескольких различных построений, проект не может быть полностью определен до завершения последнего построения. Проект ПО для данного построения должен обязательно удовлетворять требованиям к ЭКПО, которые должны быть реализованы для этого построения.
Процесс кодирования ПО
В процессе кодирования ПО на основании архитектуры ПО и требований нижнего уровня создают исходный код.
Р азработчик должен разработать и зарегистрировать исходный код ПО, соответствующий каждому модулю ПО в проекте ЭКПО. Реализация ПО должна включать в себя, если это применимо, кодирование машинных команд и определение данных, создание базы данных, заполнение базы данных и других файлов данных значениями данных, а также другие работы, необходимые для реализации проекта. Если для кодирования поставляемого ПО предполагается использовать язык программирования, отличный использование этого языка.
7.3.1 Цели процесса кодирования ПО
Ц ели процесса кодирования ПО состоят в том, чтобы разработать исходный код, который должен быть прослеживаемым, верифицируемым, непротиворечивым и корректно реализующим требования нижнего уровня.
7.3.2 Состав работ, выполняемых в процессе кодирования ПО
В ходными данными процесса кодирования ПО являются требования нижнего уровня, архитектура ПО, План разработки ПО и стандарты кодирования ПО. Когда указанные в плане критерии перехода удовлетворены, может быть осуществлен первичный или повторный переход к процессу кодирования ПО. Исходный код, полученный при выполнении этого процесса, базируется на архитектуре ПО и требованиях нижнего уровня. Результат этого процесса - исходный код (12.19) и объектный код. Процесс кодирования ПО является завершенным, когда реализованы все его цели и цели интегральных процессов, связанных с ним. Требования для этого процесса следующие:
- исходный код должен реализовывать требования нижнего уровня и соответствовать архитектуре ПО;
- исходный код должен соответствовать стандартам кодирования ПО;
- исходный код должен быть трассируемым к описанию проекта;
- для неадекватных или некорректных входных данных, обнаруженных при выполнении процесса кодирования ПО, необходимо обеспечить обратную связь с процессами определения требований к ПО, проектирования ПО или планирования ПО для исследования или исправления.
Процесс интеграции
О бъектный компьютер, исходный код и объектный код, полученные в процессе кодирования ПО, используют при редактировании связей и загрузке с целью создать интегрированную систему.
7.4.1 Цели процесса интеграции
Ц ели процесса интеграции состоят в получении интегрированной системы.
7.4.2 Состав работ, выполняемых в процессе интеграции
П осле того как указанные в Плане разработки ПО критерии перехода будут удовлетворены, может быть осуществлен первичный или повторный переход к процессу интеграции. Входными данными процесса интеграции являются описание архитектуры ПО из процесса проектирования ПО, а также исходный и объектный код из процесса кодирования ПО.
В ыходной результат процесса интеграции - исполняемый объектный код, описанный в 12.20, и информация о редактировании связей и загрузке. Процесс интеграции является завершенным, когда удовлетворены его цели и цели интегральных процессов, связанных с ним. Требования для этого процесса:
- исполняемый объектный код должен быть генерирован на основе исходного кода и информации о редактировании связей и загрузке;
- ПО должно быть загружено в объектный компьютер для интеграции аппаратных средств и ПО;
- для неадекватных или некорректных входных данных, обнаруженных в процессе интеграции, необходимо обеспечить обратную связь с процессами определения требований к ПО, проектирования ПО, кодирования ПО или планирования ПО для исследования или исправления.
7.4.3 Дополнительные задачи интеграции
Д алее рассмотрены задачи, связанные с отключенным кодом и заплатами в ПО. Управляющая система или оборудование могут быть предназначены для включения нескольких вариантов конфигураций, не все из которых предназначены для использования в каждом приложении. Это может привести к появлению отключенного кода, который может быть не выполнен, или данных, которые могут быть не использованы. Такой код отличается от мертвого кода, который определен в разделе 3 и объяснен в 8.4.4. Требования для отключенного кода и заплат следующие:
- должно быть приведено доказательство того, что отключенный код заблокирован для среды, где его использование не предусмотрено. Непреднамеренную активацию отключенного кода, возникающую в аварийных ситуациях системы, следует рассматривать также как непреднамеренную активацию обычного активизированного кода;
- должны быть использованы методы работы с отключенным кодом в соответствии с планами ПО;
- нельзя использовать заплаты в ПО, предназначенном для поставки в сертифицируемый объект, для выполнения изменения в требованиях или архитектуре, или изменений, оказавшихся необходимыми в результате работ процесса верификации ПО. Заплаты следует использовать в ограниченных случаях, например, чтобы устранить замеченные неточности среды программирования, типа обнаружения ошибки компилятора и др.;
- при использовании заплаты необходимо подтвердить, что процесс управления конфигурацией ПО может эффективно прослеживать эту заплату; провести регрессионный анализ для доказательства того, что включение заплаты удовлетворяет всем требованиям к ПО, разработанному с помощью обычных методов; обосновать использование заплаты в Итоговом документе разработки ПО.
Трассируемость
Т ребования трассируемости включают в себя обеспечение соответствия:
- между системными требованиями и требованиями к ПО, чтобы гарантировать полноту реализации системных требований и видимость производных требований;
- между требованиями нижнего уровня и требованиями верхнего уровня, чтобы гарантировать полноту реализации требований верхнего уровня и видимость производных требований и архитектурных решений, принятых при выполнении процесса проектирования ПО;
- между исходным кодом и требованиями нижнего уровня, чтобы верифицировать отсутствие неописанного исходного кода и полноту реализации требований нижнего уровня.
Процесс верификации ПО
В ерификация ПО обеспечивает техническую оценку всех средств разработки ПО, в том числе и результатов верификации ПО. Верификацию ПО выполняют в соответствии с Планом верификации ПО (12.3) и Планом квалификационного тестирования ПО (12.4), которые разрабатывают в процессе планирования ПО.
Т аблицы А.3 - А.7 содержат резюме целей и результатов верификации в зависимости от уровня ПО.
П римечание - Чем ниже уровень ПО, тем меньше внимания уделяют:
- верификации требований нижнего уровня;
- верификации архитектуры ПО;
- полноте покрытия тестами;
- контролю процедур верификации;
- независимости работ процесса верификации ПО;
- перекрытию работ процесса верификации ПО, т.е. выполнению различных верификационных работ, каждая из которых обнаруживает ошибки одного и того же класса;
- тестированию отказоустойчивости;
- верификационным работам, обнаруживающим ошибки, которые оказывают лишь косвенное влияние на результаты разработки, например отклонение от стандартов разработки ПО.
Цели верификации ПО
Н азначение верификации ПО состоит в том, чтобы обнаружить и зарегистрировать ошибки, которые могли быть внесены в ПО во время его разработки (устранение ошибок является задачей разработки ПО). Основное назначение верификации ПО - проверить что:
- системные требования, предназначенные для программной реализации, были должным образом переработаны в требования верхнего уровня к ПО, которые удовлетворяют этим системным требованиям;
- требования верхнего уровня были переработаны в архитектуру ПО и требования нижнего уровня, которые удовлетворяют требованиям верхнего уровня; если разработано несколько уровней требований к ПО между требованиями верхнего уровня и требованиями нижнего уровня, то каждый последующий уровень требований разработан так, чтобы удовлетворять требованиям более высокого уровня;
- архитектура ПО и требования нижнего уровня должным образом преобразованы в исходный код, удовлетворяющий им;
- исполняемый объектный код удовлетворяет требованиям к ПО;
- инструментальные средства, используемые для выполнения указанных работ, являются технически корректными и полными для заданного уровня ПО.