Особенности процессов разработки
Стандарт ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию создан в развитие ISO 12207 с целью учета специфики жизненного цикла программных средств встроенных систем реального времени высокого качества, преимущественно для авиационных, космических и транспортных систем. В стандарте значительное внимание уделяется обеспечению качества и функциональной безопасности ПС, чем структура и рекомендации этого стандарта наиболее близки к IEC 61508 . В стандарте представлены: общие требования (п. 4), системные аспекты, связанные с разработкой ПС (п.5), и шесть крупных разделов (п.п. 6 — 11), подробно описывающие и рекомендующие основные процессы ЖЦ встроенных ПС. Последовательно, детально рассмотрены требования и методы реализации процессов жизненного цикла сложных ПC. Выделена группа процессов планирования , которые определяют и координируют для проекта действия процессов разработки и интегральных процессов. Процессы разработки , в ходе выполнения которых создается программное средство, отражены в разделах:
Интегральные процессы , которые обеспечивают корректную реализацию и качество выполнения процессов разработки и их выходных данных детально представлены в разделах:
Интегральные процессы должны выполняться частично одновременно с процессами разработки ПС. В рамках конкретного проекта должны быть установлены одна или несколько моделей жизненного цикла ПС, в соответствии, с которыми выбираются необходимые процедуры для каждого процесса, определяется последовательность их выполнения, назначаются ответственные за выполнение работ. Для конкретного проекта последовательность процессов определяется сложностью проекта в целом, функциональными возможностями разрабатываемой системы, объемом и сложностью ПС, стабильностью требований, использованием ранее полученных результатов, стратегией разработки и возможностями аппаратных средств.
Для всех работ по созданию ПС должны использоваться систематизированные, зарегистрированные методы. План разработки ПС должен содержать описание этих методов или включать в себя ссылки на источники и стандарты, в которых они описаны. Следует разработать и использовать руководства для представления требований: проекта, кода, тестовых вариантов, тестовых процедур и результатов тестирования. В документе представлены подробные рекомендации, на которых акцентируется дополнительное внимание и детализируются положения стандарта ISO 12207 . Основные требования и рекомендации стандарта сводятся к следующим.
Разработчик должен принимать участие в анализе, определении и документировании требований, которым должна удовлетворять встроенная система и ПС, и методы, которые необходимо использовать в целях гарантирования выполнения каждого требования. Эта информация может быть представлена в форме предложений, обзоров, сообщений о дефектах и изменениях, обратной связи к прототипам, интервью о потребностях пользователя или в любой другой форме.
Если системные требования предусматривают возможность модификации, осуществляемой пользователем, то они могут изменять ПС в заданном диапазоне без рассмотрения, осуществляемого сертифицирующей организацией. В этом случае системные требования должны определить механизмы, которые устраняют негативное влияние на безопасность ПС модификации, осуществляемой пользователем, независимо от того, как она выполнена. При проведении модификации пользователем последний должен нести ответственность за все аспекты модифицируемого им ПС, например, за управление конфигурацией, обеспечение безопасности и качества и верификацию.
Рекомендуется идентифицировать компоненты или части их, критические с точки зрения безопасности, сбой в которых может привести к отказовой ситуации. Если имеется такое ПС или компонент, следует предусмотреть стратегию обеспечения его защиты. Стратегия должна гарантировать методы, при которых требования, проект, реализация и эксплуатационные процедуры для ПС, минимизируют или устраняют потенциальные нарушения безопасности ПС.
Следует проанализировать требования контракта, относящиеся к использованию ресурсов аппаратных средств компьютера (например, максимально возможная производительность процессора, объем памяти, пропускная способность устройств ввода/вывода).
Разработчик должен принимать участие в определении и документировании проектных решений системного уровня. Эти решения являются прерогативой разработчика, если они формально не преобразованы в требования при выполнении контракта. Он ответствен за выполнение всех требований и демонстрацию этого выполнения посредством квалификационного тестирования. Реализация проектных решений, действующих как внутренние требования, должна быть подтверждена внутренним тестированием разработчика, выполнение которого нет необходимости демонстрировать заказчику.
Рекомендуется участие разработчика в определении и документировании проекта архитектуры ПС (идентификации компонентов, их интерфейсов и концепции их совместного выполнения) и в прослеживании соответствия между компонентами ПС и системными требованиями. В процессе оценки безопасности должно устанавливаться, как архитектурное проектирование ПС предотвращает аномальное поведение при появлении отказовых ситуаций. Должны применяться архитектурные стратегии, которые позволяют ограничивать воздействие дефектов, обнаруживать ошибки и обеспечивать приемлемую реакцию ПС для устранения их воздействия. Библиотека разработки ПС может быть частью среды разработки и среды верификации. Следует сопровождать Библиотеку разработки ПС на протяжении действия контракта.
Разработчик должен подготовить исполняемое ПС для передачи в организацию, осуществляющую сопровождение, а также файлы, необходимые для установки и эксплуатации ПС на объектной ЭВМ. Он должен принимать участие в совместных с заказчиком технических просмотрах, проводимых в течение всего периода выполнения контракта. В этих просмотрах, как со стороны разработчика, так и со стороны заказчика должны принимать участие лица с достаточными техническими знаниями о разрабатываемом ПС.
Следует осуществлять контроль за критическими для выполнения контракта ситуациями, которые могут возникнуть во время разработки ПС. Необходимо выявлять, идентифицировать и анализировать потенциальные технические, стоимостные или временные критические ситуации и риски; разработать стратегии для предотвращения или устранения таких ситуаций; регистрировать возможные риски и стратегии их предотвращения и реализовать эти стратегии в соответствии с Планом. В течение всего жизненного цикла ПС должны создаваться документы, чтобы планировать требуемые действия, управлять, объяснять, регистрировать выполнение требуемых действий. Эти документы должны отражать реализацию процессов жизненного цикла ПС, сертификацию системы и последующую модификацию ПС. Заказчик должен осуществлять выбор необходимого и экономически обоснованного состава и содержания документов для конкретной разработки из представленных в стандарте 39-и типов и структур. Их форма должна обеспечивать эффективный поиск и просмотр документов жизненного цикла ПС в процессе обслуживания системы. Состав документов и их конкретная форма должны быть определены в Плане документирования ПС. Заказчик на основании информации, полученной от разработчика, должен определить, какие руководства являются необходимыми для данной системы, и требовать разработки только этих руководств.
содержание назад вперед
