ГОСТ Р МЭК 61508-7—2007
Описание: «формальный» аудит гарантирующих качестводокументов, направленный на отыскание ошибок.
Процедура проверки состоит из пяти этапов: планирование, подготовка, исследование, анализ и учет. Каждый из
этих этапов имеет свои конкретные цели. Должна быть проанализирована вся разработка системы (специфика
ция. проектирование, кодирование и тестирование).
Литература:
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. Т. Gilb. D. Graham. Addison-Wesley. 1993. ISBN 0-201-63181-4.
C.5.17 Макетирование/анимация
П р и м е ч а н и е — Ссыпка на данный метод/средство приведена в МЭК 61508-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 Vertag. 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 (таблица В.З).
Цель: тестирование функции программной системы вместе с ее интерфейсами во внешнем окружении, не
допуская модификации реального окружения.
Описание: создание системы только для целей тестирования, имитирующей поведение управляемого обо
рудования (EUC).
Имитация гложет осуществляться только программными средствами либо сочетанием программных и ап
паратных средств. Она должна:
- обеспечить входы, эквивалентные входам, которые могут иметь место при фактической установке EUC:
- реагировать на выходные результаты тестирования программных средств способом, точно отражающим
объект управления:
- обладать средствами для входных данных оператора, обеспечивающими любые нарушения, с которыми
должна справиться тестируемая система.
Когда программные средства протестированы, созданная система может тестировать аппаратные сред
ства с их входами и выходами.
56