---

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

Литература:

Sneak Analysis and Software Sneak Analysis. S.G. Godoy and G.J. Engels. J. Aircraft Vol. 15, No. 8, 1978.

Sneak Circuit Analysis. J.P. Rankin, Nuclear Safety, Vol. 14, No. 5, 1973.

C.5.12 Тестирование на символьном уровне

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).

Цель: показать соответствие между исходным кодом и спецификацией.

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

Литература:

Formal Program Verification using Symbolic Execution. R. B. Dannenberg and G. W. Ernst. IEEE Transactions on Software Engineering, Vol. SE-8, No. 1, 1982.

Symbolic Execution and Software Testing. J. С King, Communications of ACM, Vol. 19, No. 7, 1976.

C.5.13 Формальное доказательство

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.9).

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

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

В настоящем стандарте описаны различные формальные методы, например CCS, CSP, HOL, LOTOS, OBJ, временная логика, VDM и Z (см. С.2.4).

Альтернативным методу формального доказательства является «строгий аргумент». Подготавливается процедура формального доказательства, в которой представлены основные этапы, но включены не все математические подробности. Метод «строгий аргумент» является более слабым методом верификации, устанавливающим, что доказательство было бы возможным, если бы к этому были предприняты попытки.

Литература:

Software Development - A Rigorous Approach. С. В. Jones. Prentice-Hall, 1980.

Systematic Software Development using VDM. С. В. Jones. Prentice-Hall, 2nd Edition, 1990.

C.5.14 Метрики сложности программного обеспечения

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.9 и А.10).

Цель: прогнозирование характеристик программ, исходя из свойств самих программ или их разработки, либо предыстории тестирования.

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

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

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

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

- число входов и выходов на программный модуль. Сведение к минимуму числа точек входов/выходов является ключевой особенностью методов структурного проектирования и программирования.

Литература:

Software Metrics: A Rigorous and Practical Approach. N. E. Fenton, International Thomson Computer Press, 1996, ISBN 1-85032-275-9, 2nd Edition.

A Complexity Measure. T. J. McCabe. IEEE Trans on Software Engineering, Vol. SE-2, No. 4, December 1976.

Models and Measurements for Quality Assessments of Software. S. N. Mohanty. ACM Computing Surveys, Vol. 11, No. 3, September 1979.

Elements of Software Science. M. H. Halstead. Elsevier, North Holland, New York, 1977.

C.5.15 Проверка разработки программ

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).

Цель: обнаружение ошибок на всех этапах разработки программ.

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

Литература:

Design and Code Inspections to Reduce Errors in Program Development. M. E. Fagan, IBM Systems Journal, No. 3, 1976.

C.5.16 Сквозной контроль/Анализ проектов

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).

Цель: обнаружение ошибок в различных частях проекта с высокой оперативностью и экономичностью.

Описание: МЭК опубликовал руководство по общему представлению формального анализа проектов, которое содержит общее описание представления формального анализа проектов, его цели, подробные сведения о различных типах анализа проекта, состав группы анализа проекта и относящиеся к ним обязанности и ответственности. Это руководство содержит также общие руководящие материалы по планированию и выполнению формального анализа проектов, а также конкретные подробные сведения, относящиеся к роли независимых специалистов в группе по анализу проекта [12]. Например, помимо прочего в функции специалистов входят надежность, поддержка обслуживания и доступность.

В упомянутом выше руководстве МЭК рекомендует, чтобы формальный анализ проекта проводился для всех новых изделий/процессов, применений и при пересмотрах существующих изделий и производственных процессов, влияющих на функции, производительность, безопасность, надежность, способность анализировать обслуживание, доступность, способность к экономичности и другие характеристики, влияющие на конечные изделия/процессы, пользователей или наблюдателей.

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

Литература:

Software Inspection. T. Gilb, D. Graham, Addison-Wesley, 1993, ISBN 0-201-63181-4.

C.5.17 Макетирование/анимация

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.3 и В.5).

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

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

Литература:

The emergence of rapid prototyping as a real-time software development tool. J. E. Cooling, T. S. Hughes, Proc. 2nd Int. Conf. on Software Engineering for Real-time Syatems, Cirencester, UK, IEE, 1989.

Software evolution through rapid prototyping. Luqi, IEEE Computer 22 (5), 13-27, May 1989.

Approaches to Prototyping. R. Budde et al, Springer Verlag, 1984, ISBN 3-540-13490-5.

Proc. Working Conference on Prototyping. Namur, October 1983, Budde et al, Springer Verlag, 1984.

Using an executable specification language for an information system. S. Urban et al. IEEE Trans Software Engineering, Vol. SE-11 No. 7, July 1985.

C.5.18 Моделирование процесса

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.3).

Цель: тестирование функции программной системы вместе с ее интерфейсами во внешнем окружении, не допуская модификации реального окружения.

Описание: создание системы только для целей тестирования, имитирующей поведение управляемого оборудования (EUC).

Имитация может осуществляться только программными средствами либо сочетанием программных и аппаратных средств. Она должна:

- обеспечить входы, эквивалентные входам, которые могут иметь место при фактической установке EUC;

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

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

Когда программные средства протестированы, созданная система может тестировать аппаратные средства с их входами и выходами.

Литература:

Software Testing via Environmental Simulation (CONTESSE Report). Available until December 1998 from: Ray Browne, CUD, DTI, 151 Buckingham Palace Road, London, SW1W 9SS, UK, 1994.

C.5.19 Требования к реализации

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.6).

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

Каждое требование к функционированию анализируется по очереди для того, чтобы определить:

- критерии успешности результата, который следует получить;

- возможность получения меры критерия успешности;

- потенциальную точность таких результатов измерения;

- этапы проектирования, на которых эти результаты измерения могут быть оценены и

- этапы проектирования, на которых могут быть получены эти результаты измерений.

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

- связь каждого требования к функционированию, по крайней мере, с одной мерой;

- выбор (где это возможно) точных и эффективных мер, которые могут быть использованы на самых ранних стадиях разработки;

- спецификация важных и факультативных требований к функционированию и критериев успешности результата;

- использование (по возможности) преимуществ применения одной меры для нескольких требований к функционированию.

С.5.20 Моделирование реализации

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.5, В.2 и В.5).

Цель: достаточная для удовлетворения специфицированных требований рабочая производительность системы.

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

- создания модели процессов системы и их взаимодействий;

- определения, используемых каждым процессом, ресурсов (время процессора, полоса пропускания канала связи, объем памяти и т. п.);

- определения распределения запросов, выдаваемых системе при средних и наихудших условиях;

- вычисления средних и наихудших случаев значений величин пропускной способности и времени ответа для конкретных функций системы.

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

Перед детальным моделированием может быть использована более простая проверка «бюджета ресурсов», которая суммирует требования к ресурсам всех процессов. Если сумма этих требований к системе превышает возможности спроектированной системы, проект считается нереализуемым. Даже в случае, если проект проходит эту простую проверку, моделирование выполнения может показать, что слишком большие задержки и времена ответов происходят из-за недостатка ресурсов. Для исключения такой ситуации инженеры часто проектируют системы, использующие только часть (например, 50 %) общих ресурсов для уменьшения вероятности нехватки ресурсов.

Литература:

The Design of Real-time Systems: From Specification to Implementation and Verification. H. Kopetz et al, Software Engineering Journal 72 - 82, 1991.

C.5.21 Проверка на критические и напряженные нагрузки

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.6).

Цель: подвергнуть тестируемый объект исключительно высокой нагрузке, чтобы показать, что тестируемый объект будет легко выдерживать нормальную рабочую нагрузку.

Описание: существует множество тестов для проверки на критические и напряженные нагрузки, например:

- если работа объекта происходит в режиме упорядоченного опроса, то объект тестирования подвергается в единицу времени гораздо большим входным изменениям, чем при нормальных условиях;

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

- если объем базы данных играет важную роль, то этот объем увеличивается относительно ее объема при нормальных условиях;

- имеющие решающее влияние устройства настраиваются на свои максимальные скорости или самые малые скорости соответственно;

- для экстремальных тестов все факторы, имеющие решающее влияние, по возможности вводятся одновременно в граничные условия.

Для указанных выше тестов может быть оценено поведение во времени тестируемого объекта. Можно также исследовать изменения нагрузки и проверить размер внутренних буферов или динамических переменных, стеков и т. п.

С.5.22 Ограничения на время реакции и объем памяти

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.6).

Цель: обеспечение соответствия системы требованиям к параметрам времени и памяти.