• 13.1 Использование ранее разработанного ПО
  • 13.1.1 Модификация ранее разработанного ПО
  • 13.1.2 Изменение системы или объекта управления
  • 13.1.3 Изменения среды применения или среды разработки
  • 13.1.4 Обновление базовой линии разработки
  • 13.1.5 Управление конфигурацией ПО
  • 13.1.6 Обеспечения качества ПО
  • 13.2 Аттестация инструментальных средств
  • 13.2.1 Критерии аттестации для инструментальных средств разработки ПО
  • 13.2.2 Критерии аттестации для инструментальных средств верификации ПО
  • 13.2.3 Документы по аттестации инструментальных средств
  • 13.2.4 Согласие сертифицирующей организации на использование инструментального средства
  • 13 Дополнительные вопросы

    В этом разделе представлены дополнительные аспекты сертификации ПО в случаях использования ранее разработанного ПО и аттестации инструментальных средств ПО.

    13.1 Использование ранее разработанного ПО

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

    13.1.1 Модификация ранее разработанного ПО

    Модификация ранее разработанного в соответствии с требованиями настоящего стандарта ПО может быть следствием изменения требований, обнаружения ошибок и/или расширения функциональных возможностей ПО. Анализ предполагаемой модификации заключается в следующем:

    — пересмотр результатов оценки безопасности системы с учетом предполагаемой модификации;

    — выполнение требования 13.1.4, если уровень ПО пересмотрен;

    — анализ воздействия изменений требований к ПО и воздействия изменений архитектуры ПО;

    — анализ последствий воздействия изменений требований к ПО на другие требования;

    — учет связей между несколькими компонентами ПО, что может привести к повторной верификации дополнительного объема информации, включающей в себя также неизмененные участки кода;

    — определение области, на которую воздействует изменение, что может быть выполнено с помощью анализа потока данных, анализа потока управления, временного анализа и анализа трассируемости;

    — повторная верификация областей, на которые воздействует изменение, должна быть выполнена с учетом требований раздела 8.

    13.1.2 Изменение системы или объекта управления

    Система или объект, содержащий ПО, которое было ранее сертифицировано в соответствии с определенными уровнем ПО и сертификационным базисом, могут быть использованы на другом объекте. При использовании ранее разработанного ПО на другом объекте необходимо:

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

    — если требуются функциональные модификации для новой установки, то необходимо учесть требования 13.1.1;

    — если действия предыдущей разработки не обеспечивали выходных результатов, требуемых для подтверждения безопасности новой установки, то необходимо учесть требования 13.1.4.

    13.1.3 Изменения среды применения или среды разработки

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

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

    — если новая среда разработки использует инструментальные средства разработки ПО, то может быть необходимо применить требования 13.2;

    — строгая оценка изменения среды применения должна включать в себя рассмотрение сложности и возможностей языка программирования. Например, строгость оценки для родовых функций Ада должна быть большей, если родовые параметры отличны в новом приложении. Для объектно-ориентированного языка строгость должна быть большей, если объекты отличны в новом приложении;

    — когда используют другой компилятор или другой набор опций компилятора, что приводит к различиям в объектном коде, результаты предыдущих работ процесса верификации ПО, использующие объектный код, не могут быть рассмотрены как правильные и не должны быть использованы для нового применения. В этом случае предыдущие тестовые результаты больше не могут быть допустимы для критериев структурного покрытия в новом приложении. Точно так же соглашения относительно оптимизации компилятора не могут быть допустимы;

    — когда применяют другой процессор, результаты предыдущих работ процесса верификации интерфейса аппаратных средств/ПО не могут быть использованы для нового применения; должны быть выполнены все ранее выполняемые тесты интеграции аппаратных средств/ПО; должна быть повторена проверка совместимости аппаратных средств/ПО; могут потребоваться дополнительные тесты интеграции аппаратных средств/ПО и просмотры;

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

    13.1.4 Обновление базовой линии разработки

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

    — коммерчески доступного ПО;

    — прикладного ПО, разработанного в соответствии со стандартами, отличными от настоящего стандарта;

    — прикладного ПО, разработанного до принятия настоящего стандарта;

    — ПО, ранее разработанного в соответствии с настоящим стандартом, но как ПО более низкого уровня.

    При обновлении базовой линии разработки необходимо руководствоваться следующим:

    — для удовлетворения требованиям настоящего стандарта могут быть использованы те документы жизненного цикла ПО предыдущей разработки, которые соответствуют требованиям нового применения;

    — сертификация в части ПО должна регламентироваться отказными ситуациями и уровнями ПО, определенными процессом оценки безопасности системы. Сравнение с отказными ситуациями предыдущего применения позволит определить области, которые могут потребовать изменения;

    — документы жизненного цикла ПО из предыдущей разработки должны быть оценены заново, чтобы гарантировать, что цели процесса верификации ПО требуемого уровня удовлетворены для нового применения;

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

    — необходимо определить стратегию, обеспечивающую соответствие Плана сертификации в части ПО с настоящим стандартом.

    13.1.5 Управление конфигурацией ПО

    Если используют ранее разработанное ПО, то процесс управления конфигурацией ПО для нового применения должен включать в себя дополнительно к рекомендациям раздела 9 следующее:

    — трассируемость от программного средства и его документов для предыдущего применения к программному средству и документам для нового применения;

    — контроль изменений, который позволяет регистрировать дефекты, выяснять причины их появления и прослеживать изменения к программным компонентам, используемым в более чем одном приложении.

    13.1.6 Обеспечения качества ПО

    Если используют ранее разработанное ПО, то процесс обеспечения качества для нового применения, в дополнение к рекомендациям раздела 10, должен включать в себя обеспечение того, что:

    — компоненты ПО удовлетворяют или превышают критерии соответствующего уровня ПО для нового применения;

    — изменения в процессах жизненного цикла ПО отражены в планах ПО.

    13.2 Аттестация инструментальных средств

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

    Цель процесса аттестации — гарантировать, что инструментальное средство обеспечивает доверие, по крайней мере, эквивалентное доверию к тем процессам, которые будут исключены, сокращены или автоматизированы. Если возможна демонстрация разбиения инструментальных средств по функциям, то должны быть аттестованы только те средства, которые будут использованы в целях устранения, сокращения или автоматизации работ в процессах жизненного цикла, или те средства, выходные результаты которых не были аттестованы.

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

    Инструментальные средства могут быть классифицированы одним из двух типов:

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

    — Инструментальные средства верификации ПО: инструментальные средства, которые не могут внести ошибки, но могут пропустить последние при их выявлении. Например, статический анализатор, который автоматизирует работы процесса верификации ПО, должен быть аттестован, если функции, которые он выполняет, не верифицируются другим способом; средства контроля типов данных, средства анализа и средства тестирования являются другими примерами подобных инструментальных средств.

    Требования к аттестации инструментальных средств:

    — инструментальные средства должны быть аттестованы в соответствии с их типом, определенным выше;

    — комбинированные инструментальные средства разработки и верификации должны быть аттестованы в соответствии с требованиями 13.2.1, даже если может быть продемонстрировано разделение этих двух функций;

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

    Цели процесса верификации для инструментальных средств разработки ПО представлены в 13.2.1, перечисление г).

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

    13.2.1 Критерии аттестации для инструментальных средств разработки ПО

    Критерии аттестации для инструментальных средств разработки ПО следующие:

    а) если инструментальное средство разработки ПО должно быть аттестовано, то процессы разработки ПО для этого средства должны удовлетворять тем же самым целям, что и процессы разработки прикладного ПО, при разработке которого предполагается использовать это инструментальное средство;

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

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

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

    — вероятности того, что другие верификационные работы выявят те же самые ошибки;

    в) соискатель должен продемонстрировать, что средства соответствуют эксплуатационным требованиям к инструментальным средствам (13.2.3); эта демонстрация может включать в себя период испытаний, во время которого выполняют верификацию выходных результатов инструментального средства и анализируют, регистрируют и корректируют ошибки, связанные с работой средства;

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

     1) просмотра документа «Эксплуатационные требования к инструментальному средству», как описано в 8.3.1, перечисления а), б);

     2) демонстрации того, что инструментальное средство удовлетворяет Эксплуатационным требованиям к инструментальному средству для нормального рабочего режима;

     3) демонстрации того, что средство соответствует Эксплуатационным требованиям к инструментальному средству для внештатных рабочих условий, включая внешние помехи и выборочные отказы, возникающие в инструментальном средстве и среде его функционирования;

     4) анализа покрытия, основанного на требованиях, и дополнительного тестирования для завершения покрытия требований;

     5) анализа структурного покрытия, соответствующего уровню ПО для инструментального средства;

     6) тестирования на устойчивость к ошибкам в соответствии с уровнем ПО инструментального средства, как описано в 8.4.2;

     7) анализа потенциальных ошибок, возникающих из-за использования средства, чтобы подтвердить достоверность Плана аттестации инструментального средства.

    13.2.2 Критерии аттестации для инструментальных средств верификации ПО

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

    13.2.3 Документы по аттестации инструментальных средств

    Требования к документам по аттестации инструментальных средств:

    а) в случае аттестации инструментальных средств План сертификации в части ПО для прикладного ПО должен определить те инструментальные средства, которые должны быть аттестованы, и иметь ссылки на документы по аттестации этих средств;

    б) документы по аттестации инструментальных средств должны иметь 1-ю категорию контроля для средств разработки ПО и 2-ю категорию контроля для средств верификации ПО;

    в) документы по аттестации инструментальных средств разработки ПО должны соответствовать документам раздела 11, иметь те же характеристики и содержать ту же информацию, что и для прикладного ПО, с учетом того, что:

     1) План аттестации инструментального средства решает те же задачи, что и План сертификации в части ПО для прикладного ПО;

     2) Эксплуатационные требования к инструментальному средству соответствуют Спецификации требований к ПО для прикладного ПО;

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

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

    — идентификацию конфигурации для инструментального средства;

    — описание полученного в результате применения инструментального средства сертификационного доверия, т. е. тех работ процесса верификации, которые будут исключены, сокращены или автоматизированы;

    — указание уровня ПО, присваиваемого для инструментального средства;

    — описание архитектуры инструментального средства;

    — работы, которые должны быть выполнены для аттестации инструментального средства;

    — документы по аттестации инструментального средства.

    Документ «Эксплуатационные требования к инструментальному средству» описывает инструментальное средство на функциональном уровне. Этот документ должен включать в себя:

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

    — информацию для пользователя, такую как руководство для установки и руководство пользователя;

    — описание операционной среды, необходимой для работы инструментального средства;

    — ожидаемую ответную реакцию средств разработки ПО в случаях внештатных условий работы.

    13.2.4 Согласие сертифицирующей организации на использование инструментального средства

    Выдача согласия сертифицирующей организации на использование инструментального средства включает в себя два этапа:

    — для средств разработки ПО — согласие с Планом аттестации инструментального средства; для средств верификации ПО — согласие с Планом сертификации в части ПО для прикладного ПО;

    — для средств разработки ПО — согласие с Итоговым документом разработки инструментального средства; для средств верификации ПО — согласие с Итоговым документом разработки ПО для прикладного ПО.







     

    Главная | В избранное | Наш E-MAIL | Добавить материал | Нашёл ошибку | Наверх