5.11.1 Совместные технические просмотры
Р азработчик должен принимать участие в совместных с заказчиком технических просмотрах, проводимых в течение всего периода выполнения контракта. В этих просмотрах как со стороны разработчика, так и со стороны заказчика должны принимать участие лица с достаточными техническими знаниями о разрабатываемом ПО. Время и место проведения совместных просмотров должны быть запланированы разработчиком и одобрены заказчиком. Назначение совместных технических просмотров:
- просмотр и оценка состояния разработки ПО;
- анализ и оценка предложенных технических решений;
- рассмотрение критических для выполнения контракта ситуаций, связанных с техническими, стоимостными и временными аспектами;
- достижение согласованных стратегий предотвращения критических ситуаций в рамках предоставленных полномочий;
- идентификация проблем, которые будут рассмотрены на совместных административных просмотрах;
- гарантия постоянной связи между заказчиком и техническим персоналом разработчика.
5.11.2 Совместные административные просмотры
Р азработчик должен принимать участие в совместных с заказчиком административных просмотрах, проводимых в течение периода выполнения контракта. В этих просмотрах как со стороны разработчика, так и со стороны заказчика должны принимать участие лица, обладающие полномочиями для принятия решений о стоимостных и временных затратах. Назначение совместных административных просмотров:
- информирование администрации разработчика и заказчика относительно состояния проекта, о выбранных направлениях, о достигнутых технических соглашениях и общем состоянии разработки ПО;
|
|
- разрешение проблем, которые не могли быть решены во время совместных технических просмотров;
- достижение согласованных стратегий предотвращения критических ситуаций, которые не могли быть выработаны во время совместных технических просмотров;
- идентификация и решение проблем административного уровня и критических ситуаций, не рассмотренных во время совместных технических просмотров;
- получение заключения и одобрения заказчика, необходимого для своевременного выполнения проекта.
Другие действия
5.12.1 Контроль критических ситуаций
Р азработчик должен осуществлять контроль за критическими для выполнения контракта ситуациями, которые могут возникнуть во время разработки ПО. Разработчик должен выявить, идентифицировать и проанализировать потенциальные технические, стоимостные или временные критические ситуации; разработать стратегии для предотвращения или устранения таких ситуаций; зарегистрировать возможные критические ситуации и стратегии их предотвращения в Плане разработки ПО и реализовать эти стратегии в соответствии с Планом.
5.12.2 Показатели управления разработкой ПО
Р азработчик должен использовать показатели управления разработкой ПО для поддержки управления процессом разработки ПО и уведомления заказчика о состоянии разработки. Разработчик должен идентифицировать данные, необходимые для определения показателей, методы, которые нужно использовать для интерпретации и применения этих данных, и механизм регистрации.
Р азработчик должен включить эту информацию в План разработки ПО и использовать показатели управления разработкой в соответствии с Планом.
|
|
5.12.3 Защита и секретность
Р азработчик должен удовлетворять требования защиты и секретности, определенные в контракте.
5.12.4 Управление субподрядчиком
Е сли в проекте принимают участие субподрядчики, разработчик должен включить в контракт все договорные требования, необходимые для гарантии, что ПО будет разработано в соответствии с требованиями контракта.
5.12.5 Связь с агентством независимой верификации ПО
Р азработчик должен поддерживать постоянную связь с агентством независимой верификации ПО, если это определено в контракте.
5.12.6 Координация действий с соисполнителями
Р азработчик должен координировать действия соисполнителей, рабочих групп и групп связи в соответствии с контрактом.
5.12.7 Изменения в выполнении процессов проекта
Р азработчик должен периодически оценивать процессы жизненного цикла ПО, используемые в данном проекте, для определения их пригодности и эффективности. Основываясь на этих оценках, разработчик должен идентифицировать любые необходимые и полезные изменения в выполнении процессов, идентифицировать эти изменения для заказчика в форме предлагаемых модификаций к Плану разработки ПО и в случае их одобрения должен реализовать эти изменения в проекте.
6 Процесс планирования ПО
6.1 Цели процесса планирования ПО
Н азначение процесса планирования ПО состоит в том, чтобы определить методы создания такого ПО, которое позволит реализовать системные требования и обеспечить уровень качества, соответствующий требованиям настоящего стандарта. Таблица А.1 содержит резюме целей и результатов процесса планирования ПО в зависимости от уровня ПО.
|
|
Ц ели процесса планирования ПО:
а) определить конкретные виды работ процессов разработки и интегральных процессов жизненного цикла, которые позволят реализовать системные требования и создать ПО требуемого уровня (6.2);
б) определить модели жизненного цикла ПО, включающие в себя описание взаимосвязей между процессами, последовательность их выполнения, механизмы обратной связи и критерии перехода (4.1);
в) выбрать среду поддержки жизненного цикла, включающую в себя методы и инструментальные средства, которые нужно использовать для выполнения работ в каждом процессе жизненного цикла (6.4);
г) в случае необходимости рассмотреть дополнительные аспекты разработки, обсуждаемые в разделе 13;
д) определить стандарты разработки, позволяющие обеспечить требования по безопасности системы в части разрабатываемого ПО (6.5);
е) разработать документы процесса планирования ПО в соответствии с 6.3 и разделом 12;
ж) координировать разработку и изменение планов ПО(6.3).
6.2 Состав работ, выполняемых в процессе планирования ПО
В процессе планирования ПО должны быть выполнены следующие работы:
- разработка планов создания ПО и передача их исполнителям, осуществляющим процессы разработки и интегральные процессы (см. требования 11.1);
- определение и выбор стандартов разработки ПО, которые будут использованы для данного проекта;
- выбор методов и инструментальных средств, которые позволят в процессах разработки предотвратить внесение ошибок в ПО;
- обеспечение координации между планами разработки ПО и планами интегральных процессов для получения согласованных стратегий выполнения различных процессов жизненного цикла;
- определение процедуры пересмотра и уточнение планов по мере развития проекта;
- выбор методов и инструментальных средств, позволяющих предотвратить и обнаружить
ошибки и обеспечивающих безопасность системы в случае использования многоверсионного неидентичного ПО;
- если предполагается использование отключенного кода (7.4.3), то в процессе планирования должно быть описано, как отключенный код будет определен, верифицирован и обработан для обеспечения требований безопасности системы;
- если предполагается использовать модифицируемый пользователем код, то в стандартах и планах ПО в соответствии с требованиями 7.2.3 должны быть указаны используемые инструментальные средства и элементы данных;
- процесс планирования считают завершенным, если были выполнены контроль изменений и просмотры для всех планов ПО и стандартов разработки ПО (6.7).
Д о завершения процесса планирования могут быть инициированы другие процессы жизненного цикла ПО, если разработаны планы и стандарты для этих процессов.
6.3 Типы планов ПО
Ц ель создания планов ПО состоит в том, чтобы определить средства для удовлетворения требованиям настоящего стандарта, в том числе определить организационные подразделения, которые будут выполнять эти работы. В процессе планирования должны быть разработаны следующие типы планов ПО:
- План сертификации в части ПО (12.1) служит основным средством для согласования предложенных методов разработки с сертифицирующей организацией и определяет средства для выполнения требований данного документа;
- План разработки ПО (12.2) определяет используемые модели жизненного цикла ПО и среду разработки ПО;
- План верификации ПО (12.3) определяет средства, с помощью которых будут удовлетворены цели процесса верификации ПО;
- План квалификационного тестирования ПО (12.4) определяет порядок выполнения квалификационного тестирования ПО;
- План управления конфигурацией ПО (12.5) определяет средства, с помощью которых будут удовлетворены цели процесса управления конфигурацией ПО;
- План обеспечения качества ПО (12.6) определяет средства, с помощью которых будут удовлетворены цели процесса обеспечения качества ПО;
- План установки ПО (12.7) определяет действия по установке разработанного ПО на рабочих местах пользователей, включая подготовку и обучение персонала и адаптацию существующих систем;
- План передачи ПО (12.8) определяет аппаратное обеспечение и ПО, а также другие ресурсы, необходимые для поддержки жизненного цикла передаваемого ПО, и описывает планы разработчиков для поставки передаваемых элементов через организации, осуществляющие поддержку.
П ланы ПО должны соответствовать требованиям настоящего стандарта, устанавливать процедуры, используемые для реализации требуемых изменений в ПО до его применения на сертифицируемом объекте. Такие изменения могут быть результатом обратной связи от других процессов и могут, в свою очередь, вызывать изменение планов ПО. Планы ПО должны определять критерии переходов между процессами жизненного цикла ПО путем указания:
- входных данных для процесса, включая обратную связь от других процессов;
- действий интегральных процессов, которые могут потребоваться для обработки этих входных данных;
- необходимых инструментальных средств, методов, стандартов и процедур.
Планирование среды жизненного цикла ПО
Ц ель планирования среды жизненного цикла ПО состоит в определении методов, инструментальных средств, процедур, языков программирования и аппаратных средств, которые будут использованы для выполнения процессов жизненного цикла ПО и подготовки документов жизненного цикла ПО (раздел 12). Основными элементами среды жизненного цикла ПО являются среда разработки ПО и среда верификации ПО.
6.4.1 Среда разработки ПО
С реда разработки - важный фактор создания ПО высокого качества. Разработчик должен установить, контролировать и сопровождать среду разработки ПО. Разработчик должен гарантировать, что каждый элемент среды корректно выполняет предназначенные функции. Основные принципы выбора методов и инструментальных средств среды разработки ПО следующие:
- в процессе планирования ПО должна быть выбрана такая среда программирования, которая минимизирует потенциальный риск применения конечного программного средства;
- использование аттестованных инструментальных средств или комбинаций инструментальных средств и частей среды разработки ПО должно обеспечивать уверенность в том, что ошибка, внесенная одной частью, будет обнаружена другой. Среда разработки ПО считается приемлемой, если такие части используются согласованно;
- при определении работ процесса верификации ПО или стандартов разработки ПО необходимо учитывать уровень ПО для того, чтобы минимизировать число потенциальных ошибок, связанных со средой программирования;
- если сертификационное доверие к использованию определенной комбинации инструментальных средств достаточно высокое, то применение этих инструментальных средств должно быть определено в соответствующем плане;
- если дополнительные возможности (опции) инструментальных средств разработки ПО выбраны для использования в проекте, то эффект их применения должен быть рассмотрен и определен в соответствующем плане.
6.4.2 Язык программирования и компилятор
В процессе планирования ПО должна быть оценена допустимость использования конкретного языка программирования и компилятора. Необходимо учитывать следующее:
- некоторые компиляторы имеют возможности оптимизировать эффективность объектного кода. Если тестовые варианты дают покрытие, требуемое в соответствии с уровнем ПО, правильность оптимизации не нуждается в проверке, в противном случае воздействие этих возможностей на структурное покрытие должно быть определено в соответствии с требованиями 8.4.4;
- для реализации определенных возможностей компиляторы для некоторых языков могут производить объектный код, который не является непосредственно трассируемым к исходному тексту, например инициализация, встроенное обнаружение ошибок или обработка исключительных ситуаций (8.4.4.2, перечисление б); процесс планирования ПО должен определить в соответствующем плане средства, обнаруживающие этот объектный код, и гарантировать его тестовое покрытие;
- если в течение жизненного цикла ПО вводится новая версия компилятора, редактора связей или загрузчика или изменены опции компилятора, результаты предыдущих тестов и анализ покрытия больше не могут быть рассмотрены как адекватные. Планирование верификации должно предусматривать средства повторной верификации в соответствии с требованиями раздела 8.
6.4.3 Среда верификации ПО
Ц ель планирования среды верификации ПО состоит в том, чтобы определить методы, инструментальные средства, процедуры и аппаратные средства, которые будут использованы, чтобы проверить выходные результаты процессов разработки. Разработчик должен установить, контролировать и сопровождать среду верификации ПО. Разработчик должен гарантировать, что каждый элемент среды корректно выполняет предназначенные функции. Верификационное тестирование может быть выполнено на объектном компьютере, эмуляторе объектного компьютера или с использованием моделирования на инструментальном компьютере (интерпретатора). Основные требования следующие:
- эмулятор или интерпретатор в некоторых случаях требуется аттестовать как описано в 13.2;
- должны быть рассмотрены различия между результатами, полученными на объектном компьютере и эмуляторе или интерпретаторе, и воздействие этих различий на способности обнаруживать ошибки и проверять функциональные возможности; обнаружение тех ошибок, которые остаются невыявленными, необходимо обеспечивать другими процессами верификации ПО, которые должны быть определены в Плане верификации ПО.
Стандарты разработки ПО
Ц елью стандартов разработки ПО является определение правил и ограничений для процессов разработки. К стандартам разработки ПО относятся стандарты на требования к ПО, проектирование и кодирование ПО. Процесс верификации ПО использует эти стандарты для оценки соответствия фактических выходных данных некоторого процесса ожидаемым результатам. Стандарты разработки ПО должны:
- удовлетворять требованиям раздела 11;
- обеспечивать единообразие разработки компонентов ПО данного программного продукта или необходимого набора средств;
- исключать использование конструкций или методов, результаты которых не могут быть верифицированы или несовместимы с требованиями безопасности.
6.6 Ответственность за выполнение планирования
Р азработчик должен осуществлять планирование проекта и надзор за его выполнением в соответствии со следующими требованиями. Если систему или ЭКПО разрабатывают для нескольких различных построений, планирование для каждого построения должно предусматривать:
- полное планирование для контракта;
- детализированное планирование для текущего построения;
- планирование будущих построений, предусмотренных контрактом, с уровнем детализации, соответствующим доступной на данный момент информации.
Р азработчик должен создать официальный документ, планирующий проведение работ в соответствии с требованиями настоящего стандарта и требованиями контракта, связанными с ПО. Планирование должно быть выполнено в соответствии с уровнем системы и завершено включением всей требуемой информации
П римечания
1 Эта формулировка здесь и далее в настоящем стандарте предназначена для того, чтобы:
- подчеркнуть, что создание и регистрация информации о планировании и технологии разработки - существенная часть процесса разработки ПО - должны быть выполнены независимо от требований к поставляемому средству;
- использовать документ как контрольный список построений, которые покрываются действиями разработки или планирования;
- допустить для регистрации представления информацию, отличную от традиционных документов (например, автоматизированные инструментальные средства проектирования ПО).
2 Если контракт предусматривает передачу информации в соответствии с настоящим стандартом, в обязанности разработчика входит форматирование, сбор, маркировка, копирование и рассылка поставляемых документов, что требует дополнительного времени и усилий со стороны разработчика.
3 План разработки ПО может покрывать все виды работ, требуемых настоящим стандартом, и включать в себя описание планирования интегральных процессов, если контрактом не предусмотрены отдельные документы планирования для этих процессов.
Р азработчик должен участвовать в разработке и регистрации планов проведения квалификационного тестирования системы, результаты должны быть включены в документ «План квалификационного тестирования ПО».
Р азработчик должен создать и зарегистрировать план выполнения установки ПО и обучения пользователей, определенный в контракте, результаты должны быть включены в документ «План установки ПО».
Р азработчик должен идентифицировать все ресурсы разработки ПО, которые будут необходимы для реализации концепции поддержки организации, осуществляющей поддержку. Разработчик должен создать и зарегистрировать планы, идентифицирующие эти ресурсы, и описать действия, необходимые при передаче поставляемых элементов агентству поддержки. Результаты данного планирования должны быть включены в документ «План передачи ПО».
П осле утверждения заказчиком любого из планов, указанных в данном подразделе, разработчик должен выполнить релевантные действия в соответствии с планами. Руководство разработчика и Служба обеспечения качества ПО должны осуществлять аудит процесса разработки ПО в интервалах, определенных в Плане разработки ПО, для гарантии того, что процесс будет выполнен в соответствии с контрактом и утвержденными планами. За исключением внутреннего планирования разработчика и информации, связанной с укомплектованием персонала, любая модификация планов должна быть одобрена заказчиком.
6.7 Просмотр результатов процесса планирования ПО
П росмотры результатов процесса планирования ПО проводят для гарантии того, что планы ПО и стандарты разработки ПО соответствуют требованиям настоящего стандарта и обеспечивают согласованное выполнение процессов жизненного цикла ПО.
Процессы разработки ПО
П роцессы разработки ПО должны быть выполнены в соответствии с процессом планирования ПО (раздел 6) и Планом разработки ПО (12.2). Таблица А.2 содержит резюме целей и результатов процессов разработки ПО в зависимости от уровня ПО. Процессами разработки ПО являются следующие процессы:
- определение требований к ПО;
- проектирование ПО;
- кодирование ПО;
- интеграция.