ГОСТ Р МЭК 61508-7—2007
Литература:
Reliability of the Path Analysis Testing Strategy. W. Howden. IEEE Trans Software Engineering. Vol. SE-3. 1976.
Software considerations in airborne systems and equip certification. D0178B, RTCA. December 1992.
Structure testing, McCabe; NBS Special Publication 500-99, 1982.
A software reliability study. Walsh [USA] National Computer Conference. 1979.
C.5.9Анализ потоков управления
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).
Цель: обнаружение низкокачественных и потенциально некорректных структур программ.
Описание: анализ потока управления представляет собой метод статического тестирования для нахожде
ния подозреваемых областей программы, которые не соответствуют оправдавшей себя практике программиро
вания. Программа анализируется, формируя направленный граф, который может быть проанализирован на
наличие:
- недоступных фрагментов программы, например безусловных переходов, которые делают фрагменты
программы недостижимыми;
- запутанных кодов. Хорошо структурированный код имеет управляющий граф, допускающий сокращение
путем последовательного сокращения графа до одного узла. В отличие от этого плохо структурированный код
может быть сокращен только до группы, состоящей из нескольких узлов.
Литература:
Information Flow and Data Flow of While Programs. J. F. Bergeretti and B. A. Carre. ACM Trans, on Prog. Lang, and
Syst.. 1985.
C.5.10 Анализ потока данных
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).
Цель: обнаружение низкокачественных и потенциально некорректных структур программ.
Описание: анализ потока данных представляет собой метод статического тестирования, объединяющий
информацию, полученную из анализа потока управления, с информацией о том. какие переменные считываются
или записываются в различных частях кода. Данный метод может проверять:
- переменные, которые могут быть считаны до присвоения им значений. Такую ситуацию можно исключить,
если всегда присваивать значение при объявлении новой переменной:
- переменные, записанные несколько раз. но не считанные. Такая ситуация может указывать на пропущен
ный код;
- переменные, которые записаны, но никогда не считываются. Такая ситуация может указывать избыточный
код.
Аномальный поток данных не всегда непосредственно соответствует программным ошибкам, но если ано
малии исключены, то маловероятно, что код будет содержать ошибки.
Литература:
Information Flow and Data Flow of While Programs. J. F. Bergeretti and B. A. Carre. ACM Trans, on Prog. Lang, and
Syst.. 1985.
C.5.11 Выявление скрытых схем исполнения
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).
Цель: обнаружение неожидаемых путей или логических потоков в системе, в конкретных условиях иниции
рующих нежелательные или запрещаютщих необходимые функции.
Описание: путь паразитной схемы гложет содержать аппаратные, программные средства, операторы дей
ствий или комбинации этих элементов. Паразитные схемы не являются результатом неисправностей аппаратных
средств, а представляют собой скрытые условия невнимательного проектирования системы или кодирования
прикладных программ, что при определенных условиях может привести к неправильному функционированию
системы.
Паразитные схемы разделяют на следующие категории:
- паразитные пути, вызывающие потоки тока, энергии или логических последовательней по неожидаемому
пути или в незаданном направлении;
- паразитная синхронизация, при которой события происходят в неожидаемой или противоречивой после
довательности;
- паразитная индикация, вызывающая неоднозначные или ложные изображения условий эксплуатации
системы, что может привести к нежелательным действиям оператора;
- паразитные метки, некорректно или неточно размечающие системные функции, например системные
входы, управления, изображения, шины и т. д.. что может ввести взаблуждение оператора, который может выпол
нить в системе некорректные действия.
Анализ паразитных схем основывается на распознавании базовых топологических комбинаций в аппарат
ной или программной структуре (например, шесть базовых комбинаций были предложены для программных
средств). Анализ осуществляется с помощью контрольного списка вопросов об использовании базовых топологи
ческих компонентов и отношениях между ними.
54