Целью стандартов разработки ПО является определение правил и ограничений для процессов разработки. К стандартам разработки ПО относятся стандарты на требования к ПО, проектирование и кодирование ПО. Процесс верификации ПО использует эти стандарты для оценки соответствия фактических выходных данных некоторого процесса ожидаемым результатам. Стандарты разработки ПО должны:
— удовлетворять требованиям раздела 11;
— обеспечивать единообразие разработки компонентов ПО данного программного продукта или необходимого набора средств;
— исключать использование конструкций или методов, результаты которых не могут быть верифицированы или несовместимы с требованиями безопасности.
6.6 Ответственность за выполнение планирования
Разработчик должен осуществлять планирование проекта и надзор за его выполнением в соответствии со следующими требованиями. Если систему или ЭКПО разрабатывают для нескольких различных построений, планирование для каждого построения должно предусматривать:
— полное планирование для контракта;
— детализированное планирование для текущего построения;
— планирование будущих построений, предусмотренных контрактом, с уровнем детализации, соответствующим доступной на данный момент информации.
Разработчик должен создать официальный документ, планирующий проведение работ в соответствии с требованиями настоящего стандарта и требованиями контракта, связанными с ПО. Планирование должно быть выполнено в соответствии с уровнем системы и завершено включением всей требуемой информации в документы планирования.
Примечания
1 Эта формулировка здесь и далее в настоящем стандарте предназначена для того, чтобы:
— подчеркнуть, что создание и регистрация информации о планировании и технологии разработки ― существенная часть процесса разработки ПО — должны быть выполнены независимо от требовании к поставляемому средству;
— использовать документ как контрольный список построений, которые покрываются действиями разработки или планирования;
— допустить для регистрации представления информацию, отличную от традиционных документов (например, автоматизированные инструментальные средства проектирования ПО).
2 Если контракт предусматривает передачу информации в соответствии с настоящим стандартом, в обязанности разработчика входит форматирование, сбор, маркировка, копирование и рассылка поставляемых документов, что требует дополнительного времени и усилий со стороны разработчика.
3 План разработки ПО может покрывать все виды работ, требуемых настоящим стандартом, и включать в себя описание планирования интегральных процессов, если контрактом не предусмотрены отдельные документы планирования для этих процессов.
Разработчик должен участвовать в разработке и регистрации планов проведения квалификационного тестирования системы, результаты должны быть включены в документ «План квалификационного тестирования ПО».
Разработчик должен создать и зарегистрировать план выполнения установки ПО и обучения пользователей, определенный в контракте, результаты должны быть включены в документ «План установки ПО».
Разработчик должен идентифицировать все ресурсы разработки ПО, которые будут необходимы для реализации концепции поддержки организации, осуществляющей поддержку. Разработчик должен создать и зарегистрировать планы, идентифицирующие эти ресурсы, и описать действия, необходимые при передаче поставляемых элементов агентству поддержки. Результаты данного планирования должны быть включены в документ «План передачи ПО».
После утверждения заказчиком любого из планов, указанных в данном подразделе, разработчик должен выполнить релевантные действия в соответствии с планами. Руководство разработчика и Служба обеспечения качества ПО должны осуществлять аудит процесса разработки ПО в интервалах, определенных в Плане разработки ПО, для гарантии того, что процесс будет выполнен в соответствии с контрактом и утвержденными планами. За исключением внутреннего планирования разработчика и информации, связанной с укомплектованием персонала, любая модификация планов должна быть одобрена заказчиком.
6.7 Просмотр результатов процесса планирования ПО
Просмотры результатов процесса планирования ПО проводят для гарантии того, что планы ПО и стандарты разработки ПО соответствуют требованиям настоящего стандарта и обеспечивают согласованное выполнение процессов жизненного цикла ПО.
7 Процессы разработки ПО
Процессы разработки ПО должны быть выполнены в соответствии с процессом планирования ПО (раздел 6) и Планом разработки ПО (12.2). Таблица А.2 содержит резюме целей и результатов процессов разработки ПО в зависимости от уровня ПО. Процессами разработки ПО являются следующие процессы:
— определение требований к ПО;
— проектирование ПО;
— кодирование ПО;
— интеграция.
7.1 Процесс определения требований к ПО
Разработчик должен определить и зарегистрировать требования к ПО, которые будут выполнены каждым ЭКПО, методы, которые нужно использовать, для гарантии того, что каждое требование было выполнено, и проследить соответствие между требованиями к ЭКПО и системными требованиями. Результат этих работ должен быть включен в документ «Спецификация требований к ПО». В зависимости от условий контракта требования относительно интерфейсов ЭКПО могут быть включены либо в Спецификацию требований к ПО, либо в Спецификацию требований к интерфейсу.
Примечание — Если ЭКПО разрабатывают для нескольких различных построений, требования к ЭКПО не могут быть полностью определены до завершения конечного построения. Планирование, выполняемое разработчиком, для каждого ЭКПО должно идентифицировать подмножество требований, которые будут определены в каждом построении, и подмножество, которое будет реализовано в каждом построении. Анализ требований к ПО для данного построения следует интерпретировать как определение требований к ЭКПО, идентифицированных для этого построения.
7.1.1 Цели процесса определения требований к ПО
Цели данного процесса состоят в том, чтобы:
а) разработать требования верхнего уровня;
б) оценить производные требования верхнего уровня с точки зрения безопасности системы.
7.1.2 Состав работ, выполняемых в процессе определения требований к ПО
Входными данными для процесса определения требований к ПО являются системные требования, описания аппаратного интерфейса и архитектуры системы (если они не включены в системные требования), определяемые процессами жизненного цикла системы, План разработки ПО и стандарты на разработку требований к ПО, определяемые процессом планирования. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, входные данные используют для разработки требований верхнего уровня к ПО. Требования верхнего уровня включают в себя функциональные требования, требования к эффективности, требования к интерфейсу и требования, связанные с безопасностью. Результатами данного процесса являются документы «Спецификация требований к ПО» (12.13) и «Спецификация требований к интерфейсу» (12.14). Процесс определения требований к ПО считают завершенным, когда достигнуты его цели и цели связанных с ним интегральных процессов. Процесс определения требований к ПО должен обеспечить следующее:
— анализ функциональных системных требований и требований к интерфейсам, которые предназначены для программной реализации, на отсутствие противоречий, несоответствий и неопределенностей;
— регистрацию для последующего уточнения или исправления и передачи в качестве входной информации обратной связи к исходным процессам тех входных данных процесса определения требований к ПО, которые оказались неадекватными или некорректными;
— спецификацию в документе требований верхнего уровня каждого системного требования, которое предназначено для программной реализации;
— определение всех требований верхнего уровня, соответствующих системным требованиям, которые связаны с предотвращением риска;
— верифицируемость, непротиворечивость и соответствие требований верхнего уровня стандартам на разработку требований к ПО;
— установление требований верхнего уровня в количественных показателях с погрешностями в тех случаях, когда это необходимо;
— требования верхнего уровня не должны описывать детали проектирования или верификации, исключая определения и обоснования ограничений проектирования;
— трассируемость каждого системного требования, которое предназначено для программной реализации, к одному или нескольким требованиям верхнего уровня для ПО;
— трассируемость каждого требования верхнего уровня, кроме производных требований к одному или нескольким системным требованиям;
— оценку производных требований верхнего уровня с точки зрения безопасности системы.
7.2 Процесс проектирования ПО
Требования верхнего уровня к ПО уточняют далее в процессе проектирования ПО одной или несколькими итерациями, чтобы разработать архитектуру ПО и требования нижнего уровня, которые могут быть непосредственно использованы для получения исходного кода.
7.2.1 Цели процесса проектирования ПО
Цели данного процесса состоят в том, чтобы:
а) разработать архитектуру ПО и требования нижнего уровня на основе требований верхнего уровня;
б) оценить с точки зрения безопасности системы производные требования нижнего уровня.
7.2.2 Состав работ, выполняемых в процессе проектирования ПО
Входными данными процесса проектирования ПО являются требования к ПО, План разработки ПО и стандарты на процесс проектирования ПО. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, эти входные данные используются в процессе проектирования для разработки архитектуры ПО и требований нижнего уровня. Требования нижнего уровня могут включать в себя одно или несколько требований более низких уровней. Основным выходным результатом процесса является документ «Описание проекта ПО» (12.16), который содержит описание архитектуры ПО и требования нижнего уровня. Если это предусмотрено условиями контракта, часть проекта, имеющая отношение к интерфейсам, может быть включена в документ «Описание проекта интерфейса» (12.17), а часть проекта, имеющая отношение к базам данных, может быть включена в документ «Описание проекта базы данных» (12.18). Процесс проектирования ПО считают завершенным, когда удовлетворены его цели и цели связанных с ним интегральных процессов. Процесс проектирования ПО должен обеспечивать следующее:
— архитектура ПО и требования нижнего уровня, разработанные в процессе проектирования ПО, должны соответствовать стандартам на процесс проектирования ПО и быть прослеживаемыми, верифицируемыми и непротиворечивыми;
— производные требования должны быть определены и проанализированы для гарантии того, что они не противоречат требованиям верхнего уровня;
— работы процесса проектирования ПО могут привести к появлению возможных отказов в ПО или, наоборот, предотвратить их. Использование метода разбиения или других архитектурных методов при проектировании ПО может изменить установленный уровень критичности ПО для некоторых компонентов ПО. В таких случаях должна быть определена информация о производных требованиях, позволяющая обеспечить процесс оценки безопасности системы;
— необходимо контролировать поток управления и поток данных, когда это связано с требованиями безопасности;
— реакция на отказные ситуации должна быть согласована с требованиями безопасности;
— при обнаружении в процессе проектирования ПО неадекватных или некорректных входных данных следует осуществлять обратную связь с процессами жизненного цикла системы, с процессами определения требований к ПО или с процессом планирования ПО для исследования проблемы или исправления входных данных.
Примечание — На современном уровне развития технологии разработки ПО не применяют количественную корреляцию между сложностью и достигаемой безопасностью. Тем не менее, в процессе проектирования ПО необходимо избегать сложных конструкций, поскольку с увеличением сложности ПО становятся более трудными верификация и доказательство того, что удовлетворены цели безопасности.
7.2.3 Проектирование модифицируемого пользователем ПО
Для разработки ПО, которое предназначено для модификации пользователями, необходимы дополнительные требования. Модифицируемый компонент — часть ПО, которая предназначена для изменения пользователем, а немодифицируемый компонент не допускает изменения пользователем. Модифицируемое пользователем ПО может широко варьироваться по сложности. ПО любого уровня может включать в себя модифицируемые компоненты. Требования для проектирования модифицируемого пользователем ПО следующие:
— немодифицируемый компонент должен быть защищен от модифицируемого компонента, чтобы предотвратить влияние на безопасность функционирования немодифицируемого компонента.
Эта защита может быть обеспечена аппаратными, программными, инструментальными средствами, используемыми для реализации изменений, или их комбинацией;
— нужно показать, что специально предназначенные для реализации изменений средства являются единственно допустимыми для модификации.
7.2.4 Проектные решения уровня ЭКПО
Разработчик должен определить и зарегистрировать проектные решения уровня ЭКПО. Результаты должны быть включены в раздел проектных решений уровня ЭКПО документов проектирования ПО (12.16, 12.17, 12.18).
Разработчик должен определить и зарегистрировать проект архитектуры ПО (идентифицировать модули ПО, входящие в ЭКПО, их интерфейсы и концепцию их совместного выполнения) и проследить соответствие между модулями ПО и требованиями к ЭКПО. Результат этих работ должен быть включен в разделы документа «Описание проекта ПО», посвященные архитектуре ПО и прослеживанию соответствия. В зависимости от условий контракта часть проекта, имеющая отношение к интерфейсам, может быть включена либо в Описание проекта ПО, либо в Описание проекта интерфейса.
Разработчик должен разработать и зарегистрировать описание каждого модуля ПО. Результат этих работ должен быть включен в соответствующий раздел документа «Описание проекта ПО». В зависимости от условий контракта часть проекта, которая относится к интерфейсам, может быть включена либо в Описание проекта ПО, либо в Описание проекта интерфейса. В свою очередь проект программных модулей, которые являются базами данных или осуществляют доступ к базам данных или управление ими, может быть включен либо в Описание проекта ПО, либо в Описание проекта базы данных.
Примечание — Если ЭКПО разрабатывают для нескольких различных построений, проект не может быть полностью определен до завершения последнего построения. Проект ПО для данного построения должен обязательно удовлетворять требованиям к ЭКПО, которые должны быть реализованы для этого построения.