В настоящем стандарте рассмотрены следующие процессы жизненного цикла ПО:

Процесс планирования, который определяет и координирует действия процессов разработки и интегральных процессов для данного проекта (раздел 6).

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

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

— процесс проектирования ПО;

— процесс кодирования ПО;

— процесс интеграции.

Процессы разработки описаны в разделе 7.

Интегральные процессы, которые обеспечивают корректную реализацию и качество выполнения процессов разработки и их выходных данных:

— процесс верификации ПО;

— процесс управления конфигурацией ПО;

— процесс обеспечения качества ПО;

— процесс сертификационного сопровождения.

Интегральные процессы выполняются одновременно с процессами разработки ПО (разделы 8-11).

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

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

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

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

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

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

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

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

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

Разработчик должен идентифицировать ЭКПО или части их, критические с точки зрения безопасности, сбой в которых может привести к отказной ситуации для системы (см. 5.2).

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

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

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

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

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