Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
Методы оценки и измерения характеристик информационных систем никновение отказа функционирования системы, при- водящее к катастрофической отказной ситуации для объекта управления. Уровень В: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вы- звало бы (или способствовало бы) возникновение отказа функционирования системы, приводящее к опасной/кри- тической отказной ситуации для объекта управления. Уровень С: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение от- каза функционирования системы, приводящее к сущес- твенной отказной ситуации для объекта управления. Уровень D: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение от- каза функционирования системы, приводящее к несу- щественной отказной ситуации для объекта управления. Уровень Е: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение от- каза функционирования системы, не влияющее на экс- плуатационные возможности объекта и работоспособ- ность персонала. Если для ПО был установлен сертифи- цирующей организацией уровень Е, то в дальнейшем для сертификации такого ПО никакие требования данного документа не являются обязательными. Анализ системных требований Разработчик должен принимать участие в анали- зе требований к системе. Если систему разрабатывают для нескольких различных построений, ее требования не могут быть полностью определены до завершения конечного построения. В этом случае разработчик должен идентифицировать подмножество требований 225 Стандартизация и сертификация программного обеспечения системы, которые будут определены в каждом пост- роении, и подмножество, которое будет реализовано в каждом из построений. Анализ требований к систе- ме для данного построения следует интерпретировать так, чтобы определять требования к системе, иденти- фицированные для данного построения. Разработчик должен принимать участие в опре- делении и документировании требований, которым должна удовлетворять система, и методов, которые необходимо использовать в целях гарантирования вы- полнения каждого требования. Результат данной ра- боты должен быть представлен в качестве документа «Спецификация системы/подсистемы» (12.12). В за- висимости от условий контракта требования относи- тельно интерфейсов системы могут быть включены в Спецификацию системы/подсистемы или в Специфи- кацию требований к интерфейсу. Проектирование системы Разработчик должен принимать участие в проек- тировании системы. Если систему разрабатывают для нескольких различных построений, то ее проект не может быть полностью определен до завершения всех построений. Разработчик должен идентифицировать части проекта системы, которые будут определены в каждом построении. Результаты должны быть включены в раздел про- ектных решений системного уровня документа «Опи- сание проекта системы/подсистемы». В зависимости от условий контракта часть проекта, имеющая отноше- ние к интерфейсам, может быть включена в Описание проекта системы/подсистемы или в Описание проекта интерфейса, а часть проекта, имеющая отношение к базам данных, - в Описание проекта системы/подсис- темы или в Описание проекта базы данных. 226 Методы оценки и измерения характеристик информационных систем Разработчик должен участвовать в определении и документировании проекта архитектуры системы (идентификации компонентов системы, их интер- фейсов и концепции их совместного выполнения) и прослеживании соответствия между компонентами системы и системными требованиями. Результат этих работ должен быть включен в документ «Описание проекта системы/подсистемы» (12.15). В зависимос- ти от условий контракта часть проекта, имеющая отношение к интерфейсам, может быть включена в Описание проекта системы/подсистемы или в Опи- сание проекта интерфейса. Процесс планирования ПО Назначение процесса планирования ПО состоит в том, чтобы определить методы создания такого ПО, которое позволит реализовать системные требования и обеспечить уровень качества, соответствующий тре- бованиям настоящего стандарта. Цели процесса планирования ПО: а) определить конкретные виды работ процессов раз- работки и интегральных процессов жизненного цикла, которые позволят реализовать системные требования и создать ПО требуемого уровня; б) определить модели жизненного цикла ПО, включа- ющие в себя описание взаимосвязей между процесса- ми, последовательность их выполнения, механизмы обратной связи и критерии перехода; в) выбрать среду поддержки жизненного цикла, включающую в себя методы и инструментальные средства, которые нужно использовать для вы- полнения работ в каждом процессе жизненного цикла; г) в случае необходимости рассмотреть дополнитель- ные аспекты разработки; 227 Стандартизация и сертификация программного обеспечения д) определить стандарты разработки, позволяющие обеспечить требования по безопасности системы в части разрабатываемого ПО; е) разработать документы процесса планирования ПО; ж) координировать разработку и изменение планов ПО. Типы планов ПО Цель создания планов ПО состоит в том, чтобы определить средства для удовлетворения требованиям настоящего стандарта, в том числе определить органи- зационные подразделения, которые будут выполнять эти работы. В процессе планирования должны быть разработаны следующие типы планов ПО: - План сертификации в части ПО служит основным средством для согласования предложенных методов раз- работки с сертифицирующей организацией и определяет средства для выполнения требований данного документа. - План разработки ПО определяет используемые модели жизненного цикла ПО и среду разработки ПО. - План верификации ПО определяет средства, с помощью которых будут удовлетворены цели процес- са верификации ПО. - План квалификационного тестирования ПО определяет порядок выполнения квалификационного тестирования ПО. - План управления конфигурацией ПО определя- ет средства, с помощью которых будут удовлетворены цели процесса управления конфигурацией ПО. - План обеспечения качества ПО определяет средства, с помощью которых будут удовлетворены цели процесса обеспечения качества ПО. - План установки ПО определяет действия по ус- тановке разработанного ПО на рабочих местах поль- 228 Методы оценки и измерения характеристик информационных систем зователей, включая подготовку и обучение персонала и адаптацию существующих систем. - План передачи ПО определяет аппаратное обеспе- чение и ПО, а также другие ресурсы, необходимые для под- держки жизненного цикла передаваемого ПО, и описывает планы разработчиков для поставки передаваемых элемен- тов через организации, осуществляющие поддержку. Планы ПО должны соответствовать требовани- ям настоящего стандарта, устанавливать процедуры, используемые для реализации требуемых изменений в ПО до его применения на сертифицируемом объек- те. Такие изменения могут быть результатом обратной связи от других процессов и могут, в свою очередь, вызывать изменение планов ПО. Планы ПО должны определять критерии переходов между процессами жизненного цикла ПО путем указания: - входных данных для процесса, включая обрат- ную связь от других процессов; - действий интегральных процессов, которые мо- гут потребоваться для обработки этих входных данных; - необходимых инструментальных средств, мето- дов, стандартов и процедур. Среда разработки ПО Среда разработки - важный фактор создания ПО высокого качества. Разработчик должен установить, контролировать и сопровождать среду разработки ПО. Разработчик должен гарантировать, что каждый элемент среды корректно выполняет предназначенные функции. Основные принципы выбора методов и инструменталь- ных средств среды разработки ПО следующие: - в процессе планирования ПО должна быть вы- брана такая среда программирования, которая мини- мизирует потенциальный риск применения конечного программного средства; 229 Стандартизация и сертификация программного обеспечения - использование аттестованных инструмен- тальных средств или комбинаций инструментальных средств и частей среды разработки ПО должно обес- печивать уверенность в том, что ошибка, внесенная одной частью, будет обнаружена другой. Среда раз- работки ПО считается приемлемой, если такие части используются согласованно; - при определении работ процесса верификации ПО или стандартов разработки ПО необходимо учи- тывать уровень ПО для того, чтобы минимизировать число потенциальных ошибок, связанных со средой программирования; - если сертификационное доверие к использо- ванию определенной комбинации инструментальных средств достаточно высокое, то применение этих инс- трументальных средств должно быть определено в со- ответствующем плане; - если дополнительные возможности (опции) инструментальных средств разработки ПО выбраны для использования в проекте, то эффект их примене- ния должен быть рассмотрен и определен в соответс- твующем плане. Стандарты разработки ПО Целью стандартов разработки ПО является определение правил и ограничений для процессов разработки. К стандартам разработки ПО относят- ся стандарты на требования к ПО, проектирование и кодирование ПО. Процесс верификации ПО ис- пользует эти стандарты для оценки соответствия фактических выходных данных некоторого процес- са ожидаемым результатам. Стандарты разработки ПО должны: - удовлетворять требованиям настоящего стандарта; 230 Методы оценки и измерения характеристик информационных систем - обеспечивать единообразие разработки компо- нентов ПО данного программного продукта или необ- ходимого набора средств; - исключать использование конструкций или мето- дов, результаты которых не могут быть верифицированы или несовместимы с требованиями безопасности. Процесс управления конфигурацией ПО Процесс управления конфигурацией ПО дол- жен быть выполнен так, как определено процессом планирования ПО (документом «План управления конфигурацией ПО». Выходные результаты процесса управления конфигурацией фиксируют в Протоколах управления конфигурацией ПО или в других докумен- тах жизненного цикла. Разработчик должен осуществлять управление конфигурацией ПО в соответствии с нижеперечис- ленными требованиями. Если систему или ЭКПО разрабатывают для нескольких построений, то про- граммные средства для каждого из построений мо- гут иметь изменения или дополнения по отношению к программным средствам предыдущих построений. Управление конфигурацией ПО в каждом построении следует понимать как состояние программных средств и контроля в точке начала построения. Процесс управления конфигурацией, выполня- емый совместно с другими процессами жизненного цикла ПО, направлен на достижение основных целей, а именно на то, чтобы обеспечить: - определяемую и управляемую конфигурацию ПО на протяжении жизненного цикла; - целостность при тиражировании исполняемого объектного кода для производства ПО или, в случае необходимости, его повторной генерации для проведе- ния исследований или модификации; 231 Стандартизация и сертификация программного обеспечения - управление входными и выходными данными процесса в течение жизненного цикла, что гарантиру- ет непротиворечивость и повторяемость работ в про- цессах; - контрольную точку для проверки, оценки со- стояния и контроля изменений посредством управле- ния элементами конфигурации и определения базовой линии; - контроль над тем, чтобы дефектам и ошибкам было уделено внимание, а изменения были зарегист- рированы, утверждены и реализованы; - оценку соответствия программного средства требованиям; - надежное физическое архивирование, восста- новление и сопровождение элементов конфигурации. Процесс обеспечения качества ПО Процесс обеспечения качества ПО должен быть выполнен в соответствии с процессом планирования ПО и документом «План обеспечения качества ПО». Выходные результаты процесса обеспечения качества представлены в Протоколах обеспечения качества ПО или в других документах жизненного цикла ПО. Про- цесс обеспечения качества оценивает процессы жизнен- ного цикла ПО, их выходные результаты и гарантирует, что цели этих процессов удовлетворены, отклонения от установленных требований обнаружены, оценены, про- слежены, разрешены и что программные средства и до- кументы жизненного цикла ПО соответствуют сертифи- кационным требованиям. Работы процесса обеспечения качества должны быть выполнены разработчиком. Если систему или ЭКПО разрабатывают для не- скольких различных построений, работы и програм- мные средства для каждого построения следует оце- нивать для целей данного конкретного построения. 232 Методы оценки и измерения характеристик информационных систем Работы или программное средство, соответствующее этим целям, можно считать удовлетворительным даже в случае отсутствия информации для разработки в бо- лее поздних построениях. Планирование обеспечения качества ПО в данном случае должно быть включено в планирование разработки Цель процесса обеспечения качества - обеспе- чить уверенность в том, что: а) процессы разработки ПО и интегральные процессы выполняют по утвержденным планам ПО и стандар- там; б) критерии перехода для процессов жизненного цик- ла ПО удовлетворены; в) просмотр соответствия программного средства вы- полнен для каждого программного средства, разраба- тываемого в соответствии с требованиями настоящего стандарта и условиями контракта. Состав работ, выполняемых в процессе обеспе- чения качества ПО: а) процесс обеспечения качества должен играть актив- ную роль в работах процессов жизненного цикла ПО на всех этапах жизненного цикла, обладая при этом необходимыми полномочиями, ответственностью и независимостью, чтобы гарантировать удовлетворе- ние целям процесса обеспечения качества; б) процесс обеспечения качества должен гарантиро- вать, что планы ПО и стандарты разработаны и прове- рены на непротиворечивость; в) процесс обеспечения качества должен гарантиро- вать, что процессы жизненного цикла ПО выполнены в соответствии с утвержденными планами ПО и стан- дартами; г) процесс обеспечения качества должен включать в себя аудиты процессов разработки ПО и интегральных 233 Стандартизация и сертификация программного обеспечения процессов в течение жизненного цикла ПО, позволяю- щие гарантировать, что: 1) разработаны планы ПО; 2) обнаружены, зарегистрированы, прослежены и утверждены заказчиком отклонения в выполнении требований планов ПО и стандартов; 3) зарегистрированы принятые отклонения; 4) обеспечена среда разработки ПО в соответс- твии с определением в планах ПО; 5) отчетность о дефектах, трассируемость и кор- ректирующие действия соответствуют Плану управле- ния конфигурацией ПО; 6) ввод данных, требуемых для процессов жизненного цикла ПО, находится под контролем постоянно выполняемого процесса оценки безо- пасности системы; д) процесс обеспечения качества должен гаран- тировать, что критерии переходов для процессов жиз- ненного цикла ПО были удовлетворены в соответствии с утвержденными планами ПО; е) процесс обеспечения качества должен гаран- тировать, что для документов жизненного цикла ПО осуществлен контроль в соответствии с категориями контроля; ж) должен быть проведен просмотр согласован- ности ПО до поставки программных средств, пред- ставленных для сертификации; з) должны быть выполнены работы, связанные с отчетностью по работам процесса обеспечения качес- тва, включающие в себя результаты аудита и доказа- тельство завершения просмотра согласованности ПО для каждого программного средства, представленного для сертификации. 234 Методы оценки и измерения характеристик информационных систем Процесс сертификационного сопровождения Цель процесса сертификационного сопровожде- ния - установить взаимодействие и взаимопонимание между соискателем и сертифицирующей организаци- ей для поддержки процесса сертификации. Процесс сертификационного сопровождения выполняют так, как определено процессом планирования ПО и Пла- ном сертификации в части ПО. Соискатель предлагает средства согласования, которые показывают, что система будет удовлетворять сертификационному базису. План сертификации в час- ти ПО определяет аспекты ПО прикладной системы или оборудования применительно к предлагаемым средствам согласования. Этот план устанавливает также уровни ПО, которые определяются процессом оценки безопасности системы. Соискатель должен: - передать План сертификации в части ПО и дру- гие требуемые документы для просмотра сертифи- цирующей организации в тот момент времени, когда влияние изменений минимально, т.е. когда они могут быть проведены в рамках проектных ограничений; - разрешить разногласия, идентифицируемые сертифицирующей организацией, касающиеся аспек- тов сертификации; - получить согласие сертифицирующей организа- ции на реализацию Плана сертификации в части ПО. Соискатель должен обеспечить доказательства того, что процессы жизненного цикла ПО удовлетво- ряют требованиям планов ПО. Эти доказательства мо- гут включать в себя просмотры и обсуждения работ, составляющих процессы жизненного цикла ПО, и, в случае необходимости, документов жизненного цикла ПО, проводимые с соискателем или его поставщика- ми. Соискатель должен: 235 Стандартизация и сертификация программного обеспечения - разрешить спорные вопросы, поднятые серти- фицирующей организацией и являющиеся результа- том выполненных ею просмотров; - передать итоговый документ разработки ПО и указатель конфигурации ПО сертифицирующей орга- низации; - передать или сделать доступными другие доку- менты и доказательства соответствия, требуемые сер- тифицирующей организацией. |