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

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

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

— описание системы и определение аппаратуры;

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

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

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

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

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

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

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

Категория А — катастрофическая: отказная ситуация, которая препятствует безопасному функционированию объекта управления.

Категория В — опасная/критическая: отказная ситуация, которая приводит к уменьшению возможностей объекта управления или способности персонала справиться с неблагоприятными эксплуатационными режимами, при которых возникают:

— большое снижение гарантийных резервов или функциональных возможностей;

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

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

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

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

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

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

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

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

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

Уровень D: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее к несущественной отказной ситуации для объекта управления.

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

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

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

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

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

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

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

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

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

Разработчик должен принимать участие в определении и документировании эксплуатационной концепции для системы. Результат данной работы должен быть представлен в качестве документа «Описание эксплуатационной концепции» (12.32).

Разработчик должен принимать участие в определении и документировании требований, которым должна удовлетворять система, и методов, которые необходимо использовать в целях гарантирования выполнения каждого требования. Результат данной работы должен быть представлен в качестве документа «Спецификация системы/подсистемы» (12.12). В зависимости от условий контракта требования относительно интерфейсов системы могут быть включены в Спецификацию системы/подсистемы или в Спецификацию требований к интерфейсу (12.14).

Если система состоит из подсистем, то предполагают, что работы, указанные в 5.3.3, будут выполнены итеративно с работами, указанными в 5.4 (проектирование системы) для определения требований к системе, проектирования системы и идентификации ее подсистем, определения требований к этим подсистемам, проектировании подсистем, идентификации их компонентов и т. д.

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

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

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

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

— обнаружение разрушенного или частично загруженного ПО;

— обнаружение загрузки несоответствующей конфигурации ПО;

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

— совместимость компонентов ПО;

— совместимость типа объекта и ПО;

— отображение потери или искажения идентификации конфигурации ПО.

Требования к ПО, загружаемому в полевых условиях:

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

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

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

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

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

В системных требованиях для прикладного ПО устанавливают следующие характеристики ПО:

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

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

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

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

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

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

Результаты должны быть включены в раздел проектных решений системного уровня документа «Описание проекта системы/подсистемы» (12.15). В зависимости от условий контракта часть проекта, имеющая отношение к интерфейсам, может быть включена в Описание проекта системы/подсистемы или в Описание проекта интерфейса (12.17), а часть проекта, имеющая отношение к базам данных, — в Описание проекта системы/подсистемы или в Описание проекта базы данных (12.18).

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

Разработчик должен участвовать в определении и документировании проекта архитектуры системы (идентификации компонентов системы, их интерфейсов и концепции их совместного выполнения) и прослеживании соответствия между компонентами системы и системными требованиями. Результат этих работ должен быть включен в документ «Описание проекта системы/подсистемы» (12.15). В зависимости от условий контракта часть проекта, имеющая отношение к интерфейсам, может быть включена в Описание проекта системы/подсистемы или в Описание проекта интерфейса (12.17).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработчик должен подготовить следующие руководства пользователя:

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

— Руководство по входной/выходной информации ПО. В данном руководстве разработчик должен идентифицировать и зарегистрировать информацию, необходимую тем, кто будет формировать входные данные и получать выходные данные при эксплуатации ПО в компьютерном центре или другой централизованной или сетевой установке ПО. Вся информация должна быть включена в документ «Руководство по входной/выходной информации ПО» (12.37).

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

— Руководство по эксплуатации компьютера. В данном руководстве разработчик должен идентифицировать и зарегистрировать всю информацию, необходимую для эксплуатации компьютера, на котором будет выполнено ПО. Эта информация должна быть включена в документ «Руководство по эксплуатации компьютера» (12.33).

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

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

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

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

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

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

Разработчик должен подготовить исходные файлы, которые должны быть переданы в организацию, осуществляющую поддержку: файлы пакетного режима, командные файлы, файлы данных и другие файлы ПО, необходимые для регенерации исполняемого ПО. Вся необходимая информация должна быть включена в раздел, описывающий исходные файлы, документа «Спецификация программного средства» (12.27).

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

Разработчик должен модифицировать описание проекта каждого ЭКПО, чтобы оно соответствовало конкретному построению ПО, и должен определить и зарегистрировать следующее: методы, которые нужно использовать, чтобы проверить копии ПО; использование аппаратных ресурсов компьютера для ЭКПО; другую информацию, необходимую для поддержки ПО; прослеживание соответствия между исходными файлами ЭКПО и модулями ПО и между объемами используемых аппаратных ресурсов компьютера и требованиями ЭКПО относительно них. Все результаты должны быть включены в разделы, посвященные аттестации, поддержке ПО и прослеживанию соответствия, документа «Спецификация программного средства» (12.27).

Разработчик должен участвовать в модификации описания проекта системы в соответствии с конкретным построением системы. Все результаты должны быть включены в документ «Описание проекта системы/подсистемы» (12.15).

Разработчик должен подготовить следующие руководства поддержки:

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

— Руководство поддержки программно-аппаратных средств. Разработчик должен идентифицировать и зарегистрировать информацию, необходимую для программирования и перепрограммирования программно-аппаратных устройств. Вся необходимая информация должна быть включена в документ «Руководство поддержки программно-аппаратных средств» (12.35).

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

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

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

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

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

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

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

— анализ и оценка предложенных технических решений;

— рассмотрение критических для выполнения контракта ситуаций, связанных с техническими, стоимостными и временными аспектами;

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

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

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

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

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

— разрешение проблем, которые не могли быть решены во время совместных технических просмотров;

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

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

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

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

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

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

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

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

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

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

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