Стандарты DO178B/DO178С рекомендуют, чтобы тестовые процедуры были сфокусированы на требованиях. Каждая тестовая процедура должна адресоваться к определенному требованию или набору требований. Поэтому нельзя просто так добавить или убрать тестовую процедуру. В зависимости от того, на каких требованиях базируется тестирование, принято различить:

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

Как и какое тестирование проводить, должно быть описано в плане верификации.

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

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

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

---

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

Хорошая восприимчивость к сбоям является одной из важнейших характеристик надежного программного обеспечения.
Программное обеспечение должно ломаться "правильно"

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

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

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

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

---

Если структуры кода не покрыты тестами, то это может происходить из-за:

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

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

Для надежного ПО анализ тестового покрытия может производиться только для высокоуровневых требований. Можно также понизить требуемый процент покрытия кода или вообще не проводить структурное покрытие. Методика проведения анализа тестового покрытия должна быть оговорена на этапе планирования.
Нельзя вносить изменения без соответствующего запроса

При обнаружении ошибки в документе, требовании, коде или тестовой процедуре нельзя просто исправить ее. Неконтролируемое исправление может привести к еще большим проблемам, нежели первоначальная ошибка. Поэтом стандарты DO178B/DO178С требуют, чтобы все исправления осуществлялись только по запросу. Человек, обнаруживший ошибку, должен составить специальный рапорт на ошибку. Этот рапорт должен включать: уникальный идентификатор рапорта, чтобы за ним можно было проследить, описание проблемы, ее приоритет и возможные действия по ее устранению. Должно быть установлено, кто будет исправлять ошибку, и за какой срок. После исправления ошибки рапорт закрывается и проводится повторная верификация. Может оказаться так, что ошибся сам верификатор. В этом случае для закрытия рапорта нужно дать подробное объяснение, почему заявленная проблема не является ошибкой.

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

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

---

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

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

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

Следует также иметь в виду и человеческий фактор. Может возникнуть ситуация, когда какой-то ключевой разработчик заболеет, по той или иной причине уйдет из команды разработчиков или вообще покинет компанию. Нужно организовать процесс разработки таким образом, чтобы это не повлияло или незначительно повлияло на весь процесс разработки и сроки его выполнения. Для этого рекомендуется весь процесс делать более формальным и менее зависимым от конкретных людей.

3.2 Функциональная методология IDEF0
Наиболее популярной методологией IDEF является методология IDEF0. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique – Техника структурного анализа и дизайна). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В России приняты официальные рекомендации по применению методологии IDEEF0.

---

Целью методологии является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. Другими словами, в IDEF0 моделируемая система представляется как совокупность взаимосвязанных работ (функций, активностей). Методология IDEF0 получила столь широкое распространение в бизнес–моделировании потому, что эта методология легко представляет такие системные характеристики, как управление, обратная связь, исполнители. Кроме того, методология IDEF0 имеет развитые процедуры поддержки коллективной работы.

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

Функциональный блок, или работа (Activity Box)представляет собойнекоторую конкретную функцию ( работу) в рамках рассматриваемой системы. Блок должен иметь название в глагольном наклонении (например, "Проверить документ" или "Проверка документа"). На диаграмме функциональный блок изображается прямоугольником (рисунок 3.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль) и определяет тип интерфейса, т. е. способ взаимодействия дуги с блоком:

• 
  верхняя сторона имеет значение "Управление" (Control);
  
• 
  левая сторона имеет значение "Вход" (Input);
  
• 
  правая сторона имеет значение "Выход (Output);
  
• 
  нижняя сторона имеет значение "Механизм" (Mechanism).
  

Дуга (Arrow)отображает элемент системы,который обрабатываетсяфункциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.

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



Рисунок 3.1 – Функциональный блок
В IDEF0 различают пять типов стрелок.
Вход (Input) –материальные объекты или информация,которые используются или преобразуются

---

Смотрите также файлы

• Практикум по курсу Базы данных для студентов.docx

• Р. А.адырлов, Н.. Беристемова.docx

• Контрольная работа по дисциплине Электромагнитная совместимость и средства защиты Тема Расчет характеристик питания нагрузок в сети электроснабжения железных дорог.docx

• Цифровые компетенции Цифровая безопасность Цифровое потребление.docx

• Специальные пожарные автомобили.doc