|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМСтр 1 из 14Следующая ⇒
ОБЩИЕ ТРЕБОВАНИЯ К РАЗРАБОТКЕ И ДОКУМЕНТИРОВАНИЮ ГОССТАНДАРТ РОССИИ Москва Предисловие
1. РАЗРАБОТАН Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации.
ВНЕСЕН Научно-исследовательским институтом стандартизации и унификации
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 июня 2002 г. № 247-ст
3. Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» с целью учета специфики разработки и документирования программного обеспечения встроенных систем реального времени.
ВВЕДЕН ВПЕРВЫЕ.
5. ПЕРЕИЗДАНИЕ. Октябрь 2005 г.
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ Общие требования к разработке и документированию E mbedded system software. General requirements for development and documentation Дата введения 2003-07-01 Область применения Н астоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения. Н астоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предусмотрено использование специальных стандартов для определенных заказчиком типов ПО. Стандарт неприменим для аппаратных элементов программно-аппаратного обеспечения. Нормативные ссылки В настоящем стандарте использована ссылка на следующий стандарт: ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных с редств. Определения и сокращения В настоящем стандарте применяют термины с соответствующими определениями по ГОСТ Р ИСО/МЭК 12207, а также приведенные ниже: 3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий для выполнения конкретной задачи. 3.2 анализ полноты покрытия: Определения степени, до которой работы процесса верификации ПО удовлетворяют поставленной цели. 3.3 аномальное поведение: Поведение, которое не соответствует заданным требованиям. 3.4 аппаратные средства: Материальная часть вычислительной системы, включающая в себя электрические и электронные элементы (например, приборы и схемы), электромеханические элементы (например, дисководы) и механические элементы (например, стойки). 3.5 архитектура: Организационная структура системы или ЭКПО, в которой идентифицированы компоненты, их интерфейсы и концепция взаимодействия между ними. 3.6 аттестация инструментальных средств: Процесс получения сертификационного доверия к программному инструментальному средству применительно к конкретной встроенной системе. 3.7 база данных: Совокупность взаимосвязанных данных, сохраненных в одном или более компьютерных файлах в виде, позволяющем обращаться к ним пользователям или компьютерным программам с помощью системы управления базой данных. 3.8 библиотека разработки ПО: Контролируемая совокупность документов, промежуточных и конечных программных продуктов, а также инструментальных средств и процедур, используемых для управления текущей разработкой и последующей поддержкой ПО. 3.9 верификация: Оценка результатов процесса с целью гарантии корректности и непротиворечивости в отношении входов и стандартов, существующих для данного процесса. 3.10 заплата: Исправление, вносимое непосредственно в объектную программу на языке программирования. 3.11 изменение ПО: Модификация исходного кода, исполняемого объектного кода или сопутствующих документов относительно их базовой линии. 3.12 имитатор: Устройство, компьютерная программа или система, используемая при верификации ПО, которая принимает те же входные данные и производит те же выходные данные, что и объектная система. 3.13 интегральный процесс: Процесс разработки ПО, который остается активным на протяжении жизненного цикла ПО. 3.14 интеграция аппаратуры и ПО: Процесс объединения ПО с объектным компьютером. 3.15 интеграция ПО: Процесс объединения компонентов кода. 3.16 интерфейс: Взаимосвязь между двумя или более объектами (типа ЭКПО/ЭКПО, ЭКПО/ЭКА, ЭКПО/пользователь или между модулями ПО), которые совместно используют и обеспечивают данные или обмениваются ими. 3.17 инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них. 3.18 инструментальный компьютер: Компьютер, на котором разрабатывают ПО. 3.19 исходный код: Код, написанный на исходном языке программирования, таком как язык ассемблера и/или язык высокого уровня, в машинно-читаемой форме, пригодной для ввода в ассемблер или компилятор. 3.20 квалификационное тестирование: Тестирование, выполняемое с целью убедить заказчика, что ПО соответствует заданным требованиям. 3.21 класс эквивалентности: Такое разбиение входной области программы, при котором тестирование для представительного значения класса эквивалентно тестированию для любого другого значения из этого класса. 3.22 код: Реализация конкретных данных или конкретной компьютерной программы в символьной форме, такой, например, как исходный, объектный или машинный коды. 3.23 коммерчески доступное ПО: Коммерчески доступное программное средство, продаваемое производителем по официальным каталогам. Коммерчески доступное ПО не предназначено для переделки или усовершенствования. ПО, разработанное по специальным контрактам для специализированных приложений, не является коммерчески доступным ПО. 3.24 компонент: Замкнутая часть, комбинация частей или элемент, которые выполняют в системе отдельную функцию. 3.25 контракт: Соглашение о разработке ПО, установленное между заказчиком и разработчиком. 3.26 критерии перехода: Минимальные условия, определенные процессом планирования ПО, которые должны быть выполнены для входа в процесс. 3.27 мертвый код: Исполняемый объектный код (или данные), который в результате ошибки проектирования не может быть выполнен (код) или использован (данные) в функциональной конфигурации среды объектного компьютера и не может быть прослежен в системных или программных требованиях. Исключение составляют встроенные идентификаторы. 3.28 многоверсионное неидентичное ПО: Множество из двух или более программ, разработанных отдельно по одним и тем же функциональным требованиям. Ошибки одной версии обнаруживают путем сравнения выходных результатов разных программ. 3.29 модифицированное покрытие условий/ решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз, и для каждого условия в решении должно быть показано его независимое влияние на результат решения. Независимость влияния условия на результат решения демонстрируют путем рассмотрения всех возможных комбинаций условий. 3.30 непоставляемое программное средство: Программное средство, которое в соответствии с контрактом не требуется поставлять заказчику или другому обозначенному получателю. 3.31 объектный код: Представление компьютерной программы на низком уровне, обычно не в форме, непосредственно пригодной для объектного компьютера, а в форме, включающей в себя, помимо информации о процессорных командах, информацию о размещении программы. 3.32 объектный компьютер: Компьютер, на котором эксплуатируют ПО. 3.33 отказоустойчивость: Свойство системы продолжать правильное выполнение функций при наличии ограниченного числа аппаратных или программных дефектов. 3.34 отключенный код: Исполняемый объектный код (или данные), который согласно проекту предназначен для выполнения (код) или использования (данные) только при определенных условиях. 3.35 оценка безопасности системы: Систематическая, всесторонняя оценка предлагаемой системы с целью показать, что она удовлетворяет требованиям, предъявленным к обеспечению безопасности. 3.36 ошибка: Неправильность в требованиях, проекте или коде. 3.37 передача ПО: Последовательность действий, определяющих ответственность за передачу разработанного ПО организацией, имеющей право на эти действия (обычно организацией, которая выполняет разработку ПО), в организацию, осуществляющую поддержку ПО. 3.38 перепроектирование: Процесс исследования и изменения существующей системы для преобразования ее в новую форму. 3.39 поддержка ПО: Набор действий, гарантирующий, что установленное для эксплуатационного использования ПО продолжает выполнять все функции в соответствии с предназначением системы. Поддержка ПО включает в себя сопровождение ПО, помощь пользователям и связанные с этим действия. 3.40 покрытие операторов: Такое выполнение программы при тестировании, при котором каждый оператор в программе должен быть выполнен хотя бы один раз. 3.41 покрытие решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении должно быть выполнено с каждым возможным результатом хотя бы один раз. 3.42 покрытие условий/решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз. 3.43 поставляемое программное средство: Программное средство, требуемое по контракту, которое будет поставлено заказчику или другому обозначенному получателю. 3.44 построение: Версия ПО, отвечающая определенному подмножеству требований, которые должны быть обеспечены в конечном ПО. 3.45 прерывание: Приостановка задачи, например выполнения компьютерной программы, вызванная событием, внешним для этой задачи. Прерывание позволяет обработать возникшее событие и вернуться к прерванной задаче. 3.46 программная система: Система, состоящая из ПО и, возможно, компьютерного оборудования для его выполнения. 3.47 программное обеспечение (ПО): Совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих программ. 3.48 программное средство: ПО и связанные с ним документы, вновь созданные, модифицированные или сгруппированные для удовлетворения требованиям контракта. 3.49 программное средство многократного использования: Программное средство, разработанное для конкретного применения, но с возможностью другого применения, или разработанное специально для многократного использования в различных проектах или для многофункционального использования в одном проекте. 3.50 производные требования: Дополнительные требования, появившиеся в результате выполнения процессов разработки ПО, которые не являются непосредственно связанными с требованиями верхнего уровня. 3.51 процедура тестирования: Детальные инструкции для того, чтобы генерировать и выполнить множество тестовых наборов и оценить результаты их выполнения. 3.52 разработка ПО: Набор действий, результатом выполнения которых являются программные средства. Разработка ПО может включать в себя новую разработку, модификацию, многократное использование, перепроектирование или любое другое действие, требуемое для создания программных средств. 3.53 решение: Логическое выражение, состоящее из условий и, возможно, логических операций. Решение без логических операций - это условие. Если условие включено в решение более одного раза, то каждое его вхождение считают отдельным условием. 3.54 связность по данным: Зависимость программного компонента от данных, которые используются не только исключительно в этом компоненте. 3.55 связность по управлению: Степень влияния одного программного компонента на выполнение другого программного компонента. 3.56 сертификационное доверие: Принятие сертифицирующей организацией того факта, что процесс или средство удовлетворяет сертификационным требованиям. 3.57 система: Набор аппаратных и программных компонентов, созданный для выполнения определенной функции или множества функций. 3.58 словарь данных: Детальное описание данных, параметров, переменных и констант, используемых в системе. 3.59 совместный просмотр: Совещание с участием представителей и заказчика и разработчика, в процессе которого проверяют и обсуждают состояние проекта, программные средства и/или проблемы проекта. 3.60 соискатель: Человек или организация, претендующая на получение утверждения от сертифицирующей организации. 3.61 соисполнитель разработки: Организация, которая не является ни главным подрядчиком, ни субподрядчиком данной разработки, но которая принимает участие в разработке системы или проекта. 3.62 среда разработки ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для разработки ПО. 3.63 среда верификации/тестирования ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для выполнения верификации/тестирования ПО. Элементами данной среды могут являться имитаторы, статические анализаторы, генераторы тестовых данных, анализаторы путей и т.п., а также элементы, используемые в среде разработки ПО. 3.64 средства достижения согласования: Специальные методы, используемые соискателем для удовлетворения требованиям, заданным в сертификационном базисе. 3.65 статический анализатор: Программное инструментальное средство, которое позволяет получать определенные характеристики программы без ее выполнения. 3.66 тестирование: Процесс выполнения системы или компонента системы в целях проверки того, что она/он удовлетворяет заданным требованиям, и обнаружения ошибок. 3.67 тестовый набор: Множество тестовых входных данных, условий выполнения и результатов, разработанных для определенных целей, например для выполнения конкретного пути в программе или для верификации согласованности с заданными требованиями. 3.68 трассируемость: Доказательство связи между элементами, например между входной и выходной информацией процесса, между требованием и его реализацией. 3.69 требование: Характеристика того, чем система или ЭКПО должны обладать, чтобы быть приемлемыми для заказчика. 3.70 требования верхнего уровня: Требования к ПО, разработанные на основании анализа системных требований и требований, связанных с безопасностью системы. 3.71 требования к ПО: Описание того, что должно производить ПО, с заданием входных условий и ограничений. Требования к ПО включают в себя как требования верхнего уровня, так и требования нижнего уровня. 3.72 требования нижнего уровня: Требования к ПО, разработанные на основании требований верхнего уровня, производных требований и ограничений проекта, по которым исходный код может быть реализован непосредственно, без какой-либо дополнительной информации. 3.73 управление конфигурацией: Процесс идентификации и обеспечения целостности элементов конфигурации системы. 3.74 условие: Логическое выражение, не содержащее логических операций. 3.75 устойчивость к ошибкам входных данных: Свойство, благодаря которому ПО может продолжать корректно выполняться, несмотря на ошибки входных данных. 3.76 файл разработки ПО: Сохраняемая совокупность данных, необходимых для разработки конкретного ПО. Содержит обычно (либо непосредственно, либо путем ссылок) сведения, связанные с анализом требований, проектированием и реализацией; информацию о тестировании, проводимом разработчиком, а также план и информацию о состоянии разработки. 3.77 элемент конфигурации аппаратуры (ЭКА): Совокупность компонентов аппаратных средств, которая обеспечивает конечную функцию использования и предназначается заказчиком для независимого от других элементов управления конфигурацией. 3.78 элемент конфигурации ПО (ЭКПО): Совокупность компонентов ПО, которая обеспечивает конечную функцию использования и предназначается заказчиком для независимого от других элементов управления конфигурацией. 3.79 эмулятор: Устройство, компьютерная программа или система, которая принимает те же входные данные и производит те же выходные данные, что и данная система, и использующая тот же объектный код. Предназначен для выполнения на одном компьютере программ, написанных для другого компьютера.
4. Общие требования Жизненный цикл ПО 4.1.1 Процессы жизненного цикла ПО В настоящем стандарте рассмотрены следующие процессы жизненного цикла ПО: П роцесс планирования, который определяет и координирует действия процессов разработки и Интегральных процессов для данного проекта (раздел 6 ). П роцессы разработки, в ходе выполнения которых создается программное средство. Этими процессами являются: - процесс определения требований к ПО; - процесс проектирования ПО; - процесс кодирования ПО; - процесс интеграции. П роцессы разработки описаны в разделе 7. И нтегральные процессы, которые обеспечивают корректную реализацию и качество выполнения процессов разработки и их выходных данных: - процесс верификации ПО; - процесс управления конфигурацией ПО; - процесс обеспечения качества ПО; - процесс сертификационного сопровождения. И нтегральные процессы выполняются одновременно с процессами разработки ПО (разделы 8 - 11 ).
4.1.2 Установление модели жизненного цикла ПО В рамках конкретного проекта создания ПО должны быть установлены одна или несколько моделей жизненного цикла ПО, в соответствии с которыми выбирают необходимые работы для каждого процесса, определяют последовательность их выполнения, назначают ответственных за выполнение работ. Д ля конкретного проекта последовательность процессов определяется сложностью проекта, функциональными возможностями разрабатываемой системы, объемом и сложностью ПО, стабильностью требований, использованием ранее полученных результатов, стратегией разработки и возможностями аппаратных средств. Обычная последовательность процессов разработки ПО – определение требований, проектирование, кодирование и интеграция. П орядок представления в настоящем стандарте процессов и отдельных видов работ внутри процессов не предназначен для определения последовательности их выполнения в конкретном проекте. Многие работы могут быть выполнены одновременно; разные программные средства могут поступать (находиться) на разных этапах разработки. Если ПО разрабатывают для нескольких построений, некоторые работы могут быть выполнены для каждого построения, другие же - только для отдельного построения. Проект, включающий в себя одно построение, должен выполнять все требуемые для данного построения работы. 4.1.3 Критерии перехода между процессами К ритерии перехода используют для определения возможности первичного или повторного перехода к выполнению процессов. Каждый процесс жизненного цикла ПО выполняет некоторые виды работ над исходными данными с целью получения результирующих данных. Процесс может иметь обратную связь с другими, ранее выполненными процессами и, в свою очередь, получать обратную связь от тех процессов, которые будут выполнены позже. Под обратной связью понимают получение, распознавание и обработку информации, которая требует повторной активизации ранее выполненного процесса. Примером обратной связи может служить получение сообщения об ошибке. Критерии перехода зависят от запланированной последовательности выполнения процессов разработки ПО и интегральных процессов, а также от уровня ПО. Возможные примеры критериев перехода: выполнение верификационного просмотра выходных результатов; получение в качестве входных данных идентифицированного элемента конфигурации; выполнение анализа трассируемости для входных данных. Процесс может быть инициирован только после того, как получены все исходные данные для этого процесса и удовлетворен критерий перехода, установленный для этого процесса.
4.2 Общие требования для разработки ПО 4.2.1 Методы разработки ПО Р азработчик должен использовать для всех работ по созданию ПО систематизированные, зарегистрированные методы. План разработки ПО должен содержать описание этих методов или включать в себя ссылки на источники, в которых они описаны. 4.2.2 Стандарты ПО Р азработчик должен разработать и использовать стандарты для представления требований, проекта, кода, тестовых вариантов, тестовых процедур и результатов тестирования. План разработки ПО должен содержать описание этой информации или ссылки на источники, в которых они описаны. 4.2.3 Программные средства многократного использования Р азработчик должен рассмотреть и оценить возможность применения ранее разработанных программных средств многократного использования для выполнения требований контракта. Область исследования и критерии, используемые для оценки, должны быть описаны в Плане разработки ПО. Выбранные для применения программные средства должны отвечать требованиям контракта по правам собственности. Р азработчик должен рассмотреть возможность многократного использования программных средств, разработанных по контракту, оценить и идентифицировать для заказчика выгоды и издержки такого использования в случае его совместимости с задачами проекта. П римечание - В контракт может быть включено требование на разработку программных средств, пригодных для многократного использования.
4.2.4 Отработка критических требований Р азработчик должен идентифицировать ЭКПО или части их, критические с точки зрения безопасности, сбой в которых может привести к отказной ситуации для системы (см. 5.2 ). Р азработчик должен идентифицировать ЭКПО или их части, критические с точки зрения защиты, сбой в которых может привести к нарушению защиты системы. Если имеется такое ПО, разработчик должен предусмотреть стратегию обеспечения защиты. Эта стратегия должна гарантировать, что требования, проект, реализация и эксплуатационные процедуры для идентифицированного ПО минимизируют или устраняют потенциальные нарушения защиты системы. Разработчик должен описать стратегию в Плане разработки ПО, реализовать стратегию и провести доказательство как в части требуемых программных средств, так и в части выполнения стратегии обеспечения защиты. Р азработчик должен идентифицировать ЭКПО или части их, критические с точки зрения секретности, сбой в которых может привести к нарушению секретности системы. Если имеется такое ПО, то разработчик должен представить стратегию обеспечения секретности. Стратегия должна гарантировать, что требования, проект, реализация и эксплуатационные процедуры для идентифицированного ПО минимизируют или устраняют потенциальные нарушения секретности системы. Разработчик должен описать стратегию в Плане разработки ПО, реализовать стратегию и провести доказательство как в части требуемых программных средств, так и в части выполнения стратегии обеспечения секретности. В случаях, когда система возлагает на ПО реализацию каких-либо требований, которые в соответствии с контрактом или спецификациями системы считаются критическими, разработчик должен идентифицировать те ЭКПО или их части, сбой в которых может привести к нарушению этих критических требований; разработать стратегию для гарантирования того, что требования, проект, реализация и эксплуатационные процедуры для идентифицированного ПО минимизируют или устраняют потенциал для таких нарушений; описать стратегию в Плане разработки ПО; выполнить стратегию и провести доказательство как в части требуемых программных средств, так и в части выполнения стратегии. 4.2.5 Использование ресурсов аппаратных средств компьютера Р азработчик должен проанализировать требования контракта, относящиеся к использованию ресурсов аппаратных средств компьютера (например, максимально возможная производительность процессора, объем памяти, пропускная способность устройств ввода/вывода). Разработчик должен распределить аппаратные ресурсы компьютера между ЭКПО, контролировать использование этих ресурсов при выполнении контракта и перераспределить их или идентифицировать потребность в дополнительных ресурсах по мере необходимости, чтобы удовлетворить требования контракта. 4.2.6 Доступ для проверки заказчиком Р азработчик должен обеспечить заказчику или его полномочному представителю доступ к средствам разработчика и субподрядчика, включая среды разработки и верификации ПО, для проверки программных средств и работ, требуемых в соответствии с контрактом. |
Последнее изменение этой страницы: 2017-05-05; Просмотров: 828; Нарушение авторского права страницы