ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию
- Название:ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию
- Автор:
- Жанр:
- Издательство:ИПК Издательство стандартов
- Год:2002
- Город:Москва
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию краткое содержание
Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» с целью учета специфики разработки и документирования программного обеспечения встроенных систем реального времени
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
б) точность и непротиворечивость: гарантировать, что каждое требование нижнего уровня является точным, однозначным и достаточно детализированным и что требования нижнего уровня не противоречат друг другу;
в) совместимость с объектным компьютером: гарантировать, что не существует никаких противоречий между требованиями к ПО и возможностями аппаратных и программных средств объектного компьютера, особенно по использованию ресурсов (таких, как загрузка шины, время реакции системы и аппаратуры ввода/вывода);
г) верифицируемость: гарантировать, что каждое требование нижнего уровня может быть верифицировано;
д) соответствие стандартам: гарантировать, что процесс проектирования ПО полностью соответствует стандартам на процесс проектирования ПО и что отклонения от этих стандартов обоснованы;
е) трассируемость: гарантировать, что требования верхнего уровня и производные требования были реализованы в требованиях нижнего уровня;
ж) алгоритмические аспекты: гарантировать точность и корректность поведения предложенных алгоритмов, особенно в областях отсутствия непрерывности.
8.3.4 Просмотры и анализы исходного кода
Цель этих просмотров и анализов — выявление и регистрация ошибок, которые могли быть внесены в процессе кодирования ПО. Эти просмотры и анализы подтверждают, что выходные результаты кодирования являются точными, полными и могут быть верифицированы. Прежде всего проверяют корректность кода по отношению к требованиям к ПО и архитектуре ПО и соответствие стандартам на кодирование. Эти просмотры и анализы обычно ограничиваются исходным кодом. На данном этапе необходимо показать:
а) согласованность с требованиями нижнего уровня: гарантировать, что исходный код является корректным, полным и соответствует требованиям нижнего уровня, а также то, что исходный код не содержит неописанных функций;
б) согласованность с архитектурой ПО: гарантировать, что исходный код соответствует потоку данных и потоку управления, которые определены архитектурой ПО;
в) верифицируемость: гарантировать, что исходный код не содержит операторов и структур, которые не могут быть верифицированы, и что код не подвергался изменениям в целях тестирования;
г) соответствие стандартам: гарантировать, что процесс разработки кода ПО полностью соответствует стандартам кодирования ПО и отклонения от этих стандартов обоснованы, особенно в случаях ограничения сложности и использования конструкций кода, предназначенных для удовлетворения целей безопасности системы (сложность в данном контексте — степень связности программных компонентов, уровень вложенности управляющих структур и сложность логических или числовых выражений); этот анализ также должен гарантировать, что отклонения от стандартов оправданы;
д) трассируемость: гарантировать, что требования нижнего уровня к ПО были воплощены в исходный код;
е) точность и непротиворечивость: гарантировать правильность и непротиворечивость исходного кода, включая реализацию стеков, переполнение и разрешающую способность для арифметики с фиксированной точкой, конкуренцию ресурсов, синхронизацию выполнения самых сложных случаев, обработку особых ситуаций, использование неинициализированных переменных или констант, неиспользуемые переменные или константы и нарушения целостности данных из-за конфликтов прерываний или задач.
8.3.5 Просмотры и анализы выходных результатов процесса интеграции
Цель этих просмотров и анализов — гарантировать, что результаты процесса интеграции ЭКПО являются полными и корректными. Это может быть выполнено путем детального исследования информации о редактировании связей, загрузке и картах памяти. Должны быть проконтролированы и исключены:
— неправильные аппаратные адреса;
— перекрытия памяти;
— отсутствующие компоненты ПО.
8.3.6 Просмотры и анализы тестовых вариантов, процедур и результатов
Цель этих просмотров и анализов — гарантировать, что тестирование кода было разработано и выполнено точно и полностью. Должны быть рассмотрены следующие вопросы:
а) тестовые варианты: верификация тестовых вариантов представлена в 8.4.4;
б) тестовые процедуры: проверить, что тестовые варианты правильно представлены в процедурах тестирования и ожидаемых результатах;
в) результаты тестирования: гарантировать, что результаты тестирования корректны и что расхождения между фактическими и ожидаемыми результатами объяснимы.
8.4 Цели и методы тестирования ПО
Тестирование ПО систем управления имеет две взаимодополняющие цели. Первая цель — показать, что ПО удовлетворяет требованиям к нему. Вторая цель — продемонстрировать с высокой степенью доверия, что были устранены ошибки, которые могли бы привести к возникновению отказных ситуаций, определенных процессом оценки безопасности системы. Выделяют три уровня тестирования:
— тестирование интеграции ЭКПО/ЭКА, верифицирующее корректность функционирования ПО в среде объектного вычислителя;
— тестирование интеграции ЭКПО, верифицирующее взаимосвязи между требованиями и компонентами ПО и реализацию требований и компонентов в рамках архитектуры;
— тестирование нижнего уровня (модульное тестирование), верифицирующее реализацию требований нижнего уровня.
Примечание — Если разработан тестовый вариант и выполнена соответствующая процедура для тестирования интеграции ЭКПО/ЭКА или тестирования интеграции ЭКПО и удовлетворены критерии покрытия, базирующиеся на требованиях и структуре, то нет необходимости дублировать этот тестовый вариант для тестирования нижнего уровня. Замена тестов верхнего уровня номинально эквивалентными тестами нижнего уровня может быть менее эффективной из-за меньшего объема тестированных функциональных требований.
Для удовлетворения целей тестирования ПО:
— тестовые варианты должны быть основаны, прежде всего, на требованиях к ПО;
— тестовые варианты должны быть разработаны так, чтобы верифицировать корректность функционирования и сформировать условия, которые выявляют потенциальные ошибки;
— анализ покрытия требований к ПО должен определить, какие требования к ПО не были тестированы;
— анализ структурного покрытия должен определить, какие структуры ПО не были выполнены при тестировании.
8.4.1 Среда тестирования
Для достижения целей тестирования ПО может потребоваться более одной среды тестирования. Идеальная среда тестирования включает в себя ПО, загруженное в объектный вычислитель и тестируемое в среде, которая имитирует среду объектного вычислителя с высокой точностью.
Читать дальшеИнтервал:
Закладка: