Этапы прогнозирования ошибок

Методы прогнозирования частоты ошибок
человека основываются на классическом
анализе и включают следующие этапы:

— составление перечня основных отказов
системы;

— составление перечня и анализ действий
человека;

— оценивание частоты ошибок человека;

— определение влияния частоты ошибок
человека на интенсивность отказов
рассматриваемой системы;

— выработка рекомендаций, внесение
необходимых изменений в рассматриваемую
систему и вычисление новых значений
интенсивности отказов.

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

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

ПРИМЕР.Оператор выполняет два
задания — сначала x, а затем y. При этом
он может выполнять их как правильно,
так и неправильно. Другими словами,
неправильно выполняемые задания —
единственные ошибки, которые могут
появляться в данной ситуации. Требуется
построить дерево возможных исходов и
найти общую вероятность неправильного
выполнения задания. Предполагается,
что вероятности статистически независимы.

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

Рs — вероятность успешного выполнения
задания;

Рf — вероятность невыполнения задания;

s — успешное выполнение задания;

f — невыполнение задания;

Рx — вероятность успешного выполнения
задания x;

Рy — вероятность успешного выполнения
задания y;

— вероятность невыполнения задания x;

— вероятность невыполнения задания y.

Согласно рис. 7.2.1, вероятность успешного
выполнения задания равна Рs=Рx(Рy).
Аналогично находится выражение для
вероятности невыполнения задания:

Рf = Рx( + (Рy + ( = 1 — Рx(Рy.

Из рис. 7.2.1 следует, что единственным
способом успешного выполнения системного
задания является успешное выполнение
обоих заданий — x и y. Именно поэтому
вероятность правильного выполнения
системного задания определяется как
Рx(Рy).

Для оценки надежности работы операторов
технических систем необходимо учитывать
следующие факторы:

— качество обучения и практической
подготовки;

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

— эргономическиe показатели рабочих
мест;

— степень независимости действий
оператора;

— наличие операторов-дублеров;

— психологические нагрузки.

Рис. 7.2.1. Схема дерева исходов

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Определение

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

Прикладные методики прогнозирования получили активное развитие в 70-е гг. XX в., а бум их использования за рубежом продолжается и в наши дни. Главным образом это связано с новым направлением в исследованиях – глобальной проблематикой, основной задачей которой является решение мировых ресурсных, демографических и экологических проблем.

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

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

Цели

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

Методологическими основами для достижения таких целей являются следующие:

• анализ тенденций развития экономики и техники;
• предвидение различных вариантов;
• сопоставление сложившихся тенденций и поставленных целей;
• оценка возможных последствий принятых экономических решений.

Методы прогноза

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

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

1. Индивидуальные экспертные оценки:

• Интервью – информацию получают в ходе беседы (формализованная и неформализованная, подготовительная и независимая, направленная и ненаправленная).
• Анкетный опрос (индивидуальное, групповое, массовое, очное и заочное анкетирование).
• Разработка прогнозного сценария (применяется в сферах управленческой деятельности).
• Аналитический метод – построение дерева целей (для оценки иерархических или структурных процессов).

2. Коллективные экспертные оценки, основанные на получении согласованного мнения в группе экспертов:

• совещания;
• «круглые столы»;
• «Дельфи»;
• «мозговой штурм»;
• метод «суда».

3. Формализованные методики, основанные на использовании математических способов оценки:

• экстраполяция;
• математическое моделирование;
• морфологический метод и другие.

4. Комплексные методики, сочетающие в себе несколько вышеуказанных:

• «двойное дерево» (используется для фундаментальных исследований и НИОКР);
• прогнозный граф;
• «Паттерн» и другие.

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

Этапы

Последовательность этапов прогнозирования в общем случае представляет собой проведение работ по следующей схеме:

1. Подготовка.
2. Анализ внутренних и внешних условий в ретроспективе.
3. Выработка вариантов развития событий по альтернативному пути.
4. Экспертиза.
5. Подбор подходящей модели.
6. Ее оценка.
7. Анализ качества проведенной экспертизы (априорный и апостериорный).
8. Реализация прогностических разработок, их контроль и корректировка (при необходимости).

Ниже дано описание основных этапов прогнозирования и их характеристика.

Подготовительный этап

На первой стадии решают следующие вопросы:

1. Предпрогнозная ориентация (формулирование объекта исследования, постановка проблемы, определение целей и задач, первичное моделирование, оформление рабочих гипотез).
2. Информационная и организационная подготовка.
3. Формулировка задания на прогноз.
4. Подготовка компьютерного сопровождения.

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

Документально фиксируют следующие моменты:

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

Анализ

На втором, аналитическом этапе прогнозирования, проводят следующие виды работ:

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

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

Альтернативные варианты

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

На данном этапе выполняются такие работы:

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

Экспертиза

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

Экспертиза может проводиться различными методами:

• интервьюирование;
• анкетирование;
• одноразовый или многотуровый опрос экспертов;
• анонимный или открытый обмен информацией и другие способы.

Выбор модели

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

В экономической науке выделяют несколько видов таких моделей:

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

Существуют также другие классификации моделей:

1. По отражаемым в них аспектам – производственные и социальные.
2. Модели, предназначенные для описания доходов, потребления, демографических процессов.
3. Экономические модели различного уровня (долгосрочные для прогнозирования экономического развития, межотраслевые, отраслевые, производственные).

В прогнозных моделях выделяют следующие формы описания явлений:

• текстовая;
• графическая (методы экстраполяции);
• сетевая (графы);
• построение блок-схем;
• матричная (таблицы);
• аналитическая (формулы).

Модель формируют при помощи таких способов, как:

• феноменологический (прямое изучение и наблюдение за происходящими явлениями);
• дедуктивный (выделение деталей из общей модели);
• индуктивный (обобщение из частных явлений).

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

Оценка качества

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

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

Выделяют 2 методики для проведения оценки качества:

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

Основные факторы

На точность прогноза оказывают влияние следующие главные факторы:

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

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

Реализация

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

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

Прогнозирование ошибок программного обеспечения. Обнаружение ошибок

1

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

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

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

В общем случае отказ программного обеспечения можно определить как:

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

Из данного определения программной ошибки следует, что ошибки могут по разному влиять на надежность программного обеспечения и можно определить тяжесть ошибки, как количественную или качественную оценку последствий этой ошибки. При этом категорией тяжести последствий ошибки будет являться классификационная группа ошибок по тяжести их последствий. Ниже представлены возможные категории тяжести ошибок в программном обеспечении общего применения в соответствии с ГОСТ 51901.12 — 2007 «Менеджмент риска. Метод анализа видов и последствий отказов».

		Описание последствий проявления ошибки
	Критическая	проявление ошибки с высокой вероятностью влечет за собой прекращение функционирования программного обеспечения (его отказ)
	Существенная	проявление ошибки влечет за собой снижение эффективности функционирования программного обеспечения и может вызвать прекращение функционирования программного обеспечения (его отказ)
	Несущественная	проявление ошибки может повлечь за собой снижение эффективности функционирования программного обеспечения и практически не приводит к возникновению отказа в нем (вероятность возникновения отказа очень низкая)

В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки можно использовать условную вероятность отказа программного обеспечения при проявлении ошибки. Оценку степени тяжести ошибки как условной вероятности возникновения отказа, можно производить согласно ГОСТ 28195 — 89 «Оценка качества программных средств. Общие положения», используя метрики и оценочные элементы, характеризующие устойчивость программного обеспечения. При этом оценку необходимо производить для каждой ошибки в отдельности, а не для всего программного обеспечения.

Библиографическая ссылка

Дроботун Е.Б. КРИТИЧНОСТЬ ОШИБОК В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ И АНАЛИЗ ИХ ПОСЛЕДСТВИЙ // Фундаментальные исследования. – 2009. – № 4. – С. 73-74;
URL: http://fundamental-research.ru/ru/article/view?id=4467 (дата обращения: 06.04.2019).
Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

1. Анализ особенностей программной надежности АСОИУ и методов прогнозирования программных отказов

1.1 Основные понятия надежности программного обеспечения

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

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

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

Перед тем как анализировать надежность программного обеспечения уточним фундаментальные основные понятия теории надежности.

Надежность программного обеспечения — это свойство обеспечивать получение в соответствии с заданным алгоритмом правильных результатов в течении определенного интервала времени.

Отказпрограммного обеспечения — состояние комплекса программ связанное с нарушением работоспособности комплекса программ и прекращением дальнейшего функционирования из-за ошибок.

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

Надежность программного обеспечения АСОИУ определяется его безотказностью, восстанавлиемостью и устойчивостью.

Безотказность программного обеспечения есть его свойство сохранять способность правильно выполнять задание функции и решать задачи, возложенные на вычислительные средства АСУ в процессе обработки информации на ЭВМ в течение заданного времени. При этом состояние программного обеспечения, при котором задачи по обработке информации на ЭВМ решаются правильно (корректно), называется работоспособным состоянием. В противном случае состояние носит название неработоспособным.

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

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

Известно, что сбой в теории надежности определяется как самоустраняющийся отказ, не требующий вмешательства из вне для его устранения. Другим словом — сбой есть автоматически устраняющийся отказ, имеющий достаточно малое время восстановления. Поэтому применительно к надежности программного обеспечения АСУ следует конкретно указывать критерий, позволяющий отнести потерю работоспособности комплекса программ к отказу или сбою. В качестве такого критерия возьмем некоторое пороговое значение времени восстановления (? в пор).

Таким образом на устранение сбоя затрачивается меньше времени и ресурсов чем на устранение отказа. В формализованном виде определение сбоя и отказа программного обеспечения могут быть представлены как:

В с < ? в пор

В с — время восстановления после сбоя.

В о — время восстановления после отказа.

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

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

1.2 Основные причины и признаки выявления ошибок программного обеспечения

Основными причинами ошибок программного обеспечения являются:

Большая сложность программного обеспечения, например, по сравнению с аппаратурой ЭВМ.

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

Источниками ошибок программного обеспечения являются:

Внутренние: ошибки проектирования, ошибки алгоритмизации, ошибки программирования, недостаточное качество средств защиты, ошибки в документации.

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

Признаками выявления ошибок являются:

1. Преждевременное окончание программы.

2. Увеличение времени выполнения программы.

3. Нарушение последовательности вызова отдельных подпрограмм.

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

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

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

Неверные действия пользователя:

1. Неправильная интерпретация сообщений.

2. Неправильные действия пользователя в процессе диалога с программным обеспечением.

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

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

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

1.3 Основные параметры и показатели надежности программ АСОИУ

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

Параметр — количественные величины, в функции или математической модели выбираемая или оцениваемая в конкретных условиях.

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

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

Рис. 1.3.1. — время жизни программы.

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

1.4 Методы прогнозирования программных отказов и тестирование программ

Предупреждение ошибок — лучший путь повышения надёжности программного обеспечения. Для его реализации была разработана методика проектирования систем управления, соответствующая спиральной модели жизненного цикла программного обеспечения. Методика предусматривает последовательное понижение сложности на всех этапах анализа объекта. При декомпозиции АСОИУ были выделены уровни управления системы, затем подсистемы, комплексы задач и так далее, вплоть до отдельных автоматизируемых функций и процедур.

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

Методы прогнозирования и тестирования программного обеспечения включают в себя:

1. Методы, позволяющие справиться со сложностью системы.

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

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

Независимость. В соответствии с этой концепцией, для минимизации сложности, необходимо максимально усилить независимость элементов системы.

2. Методы достижения большей точности при переводе информации.

Методы улучшения обмена информацией базируются на введении в программное обеспечение системы различных видов избыточности:

Временная избыточность. Использование части производительности ЭВМ для контроля исполнения и восстановления работоспособности программного обеспечения после сбоя.

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

Программная избыточность включает в себя:

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

немедленное обнаружение и регистрацию ошибок;

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

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

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

Важным этапом жизненного цикла программного обеспечения, определяющим качество и надёжность системы, является тестирование. Тестирование — процесс выполнения программ с намерением найти ошибки. Этапы тестирования: контроль отдельного программного модуля отдельно от других модулей системы; контроль сопряжений (связей) между частями системы (модулями, компонентами, подсистемами); контроль выполнения системой автоматизируемых функций; проверка соответствия системы требованиям пользователей, и корректности документации, выполнение программы в строгом соответствии с инструкциями.

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

Качество подготовки исходных данных для проведения тестирования серьёзно влияет на эффективность процесса в целом и включает в себя:

1. Техническое задание.

2. Описание системы.

3. Руководство пользователя.

4. Исходный текст.

5. Правила построения (стандарты) программ и интерфейсов.

6. Критерии качества тестирования.

7. Эталонные значения исходных и результирующих данных.

8. Выделенные ресурсы, определяемые доступными финансовыми средствами.

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

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

Предлагаемых изменений.

Найденных дефектов.

Утвержденных корректировок.

Реализованных изменений.

Пользовательских версий.

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

2. Анализ моделей оценки программной надежности

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

Эти математические модели предназначены для оценки:

1. Показателей надежности комплекса программ в процессе отладки;

2. Количества ошибок оставшиеся не выявленными;

3. Времени, необходимого для обнаружения следующей ошибки в функционирующей программе;

4. Времени, необходимого для выявления всех ошибок с заданной вероятностью.

Существуют ряд математических моделей:

Экспоненциальная модель изменения ошибок в зависимости от времени отладки.

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

Модель Шумана. Исходные данные для модели Шумана собираются в процессе тестирования программного обеспечения в течение фиксированных или случайных временных интервалов.

Модель La Padula. По этой модели выполнение последовательности тестов в m этапов. Каждый этап заканчивается внесением исправлений в программное обеспечение.

Модель Джелинского — Моранды. Исходные данные собираются в процессе тестирования программного обеспечения. При этом фиксируется время до очередного отказа.

Модель Шика — Волвертона. Модификация модели Джелинского — Моранды для случая возникновения на рассматриваемом интервале более одной ошибки.

Модель Муса. В процессе тестирования фиксируется время выполнения программы (тестового прогона) до очередного отказа.

Модель переходных вероятностей. Эта модель основана на марковском процессе, протекающем в дискретной системе с непрерывным временем.

Модель Миллса. Использование этой модели предполагает необходимость перед началом тестирования искусственно вносить в программу некоторое количество известных ошибок.

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

Простая интуитивная модель. Использование этой модели предполагает проведения тестирования двумя группами программистов независимо друг от друга, использующими независимые тестовые наборы.

Модель Коркорэна. Модель использует изменяющиеся вероятности отказов для различных типов ошибок.

Модель Нельсона. Данная модель при расчете надежности программного обеспечения учитывает вероятность выбора определенного тестового набора для очередного выполнения программы.

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

2.1 Дискретно-меняющая модель

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

1. Устранение ошибок в программе приводит к увеличению времени наработки на отказ T на одну и ту же величину, равную:

T (1) =T (2) =…=T (i) = const (2.1.1)

T (i) = T (i) — T (i-1) (2.2.2)

2. Время между двумя последовательными отказами:

i = t i — t i -1 (2.1.3)

является случайной величиной, которую можно представить в виде суммы двух случайных величин:

i = i -1 + I (2.1.4)

где i — независимые случайные величины, которые имеют одинаковые математические ожидания M{} и среднеквадратические отклонения.

3. Начальный интервал времени 0 сравним со случайной величиной 0 , т.е. 0 0 , поскольку в начальный период эксплуатации программ отказы в них возникают весьма часто.

На основании второго предположения величину интервала между i-м (i-1) — м отказами можно определить соотношением:

i = i -1 + i = 0 + j (2.1.5)

из которого можно получить соотношение для определения времени наступления m-го отказа в программе:

t m = i = (0 + j) (2.1.6)

исходя из третьего предположения полученные соотношения примут вид:

i = 0 + j = j (2.1.7)

t m = (0 + j) = i j (2.1.8)

При этих предположениях средняя наработка между (m-1) — м и m-м отказами программы равна:

T 0 (m) = M{ m -1 } = M{ j } = i j = m M{}. (2.1.9)

Средняя наработка до возникновения m-го отказа может быть определена по соотношению:

T m = M{t m } = i jk) = M{}. (2.1.10)

2.2 Экспоненциальное распределение

Теперь непосредственно перейдем к анализу собственно экспоненциального распределения.

Рассматриваемое распределение характеризуется рядом свойств, такими как:

1. Ошибки в комплексе программ являются независимыми и проявляются в случайные моменты времени. Данное свойство характеризует неизменность во времени интенсивности проявления и обнаружения ошибок (т.е. ош =const) в течение всего времени выполнения программы (=t н -t 0).

2. Интенсивность проявления и обнаружения ошибок ош (интенсивность отказов) пропорционально числу оставшихся в ней ошибок:

()= Kn 0 () (2.2.1)

где K — коэффициент пропорциональности, учитывающий реальное быстродействию ЭВМ и число команд в программе.

3. В процессе исправления ошибок программы новые ошибки не порождаются. Это означает, что интенсивность исправления ошибок dn/dt будет равна интенсивности их обнаружения:

Тогда n 0 ()= N 0 — n(). (2.2.3)

Основываясь на предположениях, введенных выше, получим:

n()=N 0 (1-e — K); (2.5)

Если принять, что, получим:

2.3 Методика оценки надежности программ по числу исправленных ошибок

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

n() — количество ошибок, устраненных в ходе испытаний (тестирования) программы;

n 0 () — число оставшихся в программе ошибок на момент окончания испытаний.

Тогда n 0 ()= N 0 — n().

Основываясь на предположениях введенных в пункте 2.2.1, а именно: и ()= Kn 0 () то получим:

K — коэффициент, учитывающий быстродействие компьютера.

Решением этого дифференциального уравнения при начальных условиях t=0 и =0 является:

n()=N 0 (1-e -K); (2.3.2)

n 0 ()=N 0 — n()=N 0 e -K . (2.3.3)

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

Если ввести исходное значение среднего времени наработки на отказ перед испытанием, равного, то получим:

откуда видно, что среднее время наработки на отказ увеличивается по мере выявления и исправления ошибок.

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

Если обозначить за m — число обнаруженных отказов, а M 0 — число отказов, которое должно произойти, чтобы можно было выявить и устранить n соответствующих ошибок, то есть:

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

Если принять, что, получим:

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

Итак, оценка надежности программ по числу исправленных ошибок определяется по формуле:

2.4 Методика оценки надежности программ по времени испытания

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

где T 01 и T 02 определяются согласно формуле (2.3.9):

Оценка надежности программ по времени испытаний определяется согласно формуле:

2.5 Методика оценки безотказности программ по наработке

Наработку между очередными отказами — случайную величину T (i) можно представить в виде суммы двух случайных величин:

T (i) = T (i -1) + T (i) (2.5.1)

Последовательно применяя (3.3.1) ко всем периодам наработки между отказами, получаем:

T (i) = T (0) + T (?) (2.5.2)

Случайная величина Т n — наработка до возникновения n-го отказа программы — равна:

T n = T (i) = (2.5.3)

Введем следующие допущения:

1) все случайные величины T () независимы и имеют одинаковые математические ожидания m ? t и среднеквадратические отклонения? ? t ;

2) случайная величина T (0) пренебрежимо мала по сравнению с суммой T (?)

Основанием для второго допущения могут служить следующие соображения: в самый начальный период эксплуатации программы ошибки возникают очень часто, то есть время T (0) мало. Сумма (2.5.3) быстро растет с увеличением n, и доля T (0) быстро падает. Будем считать что T (0) ? T (0) .
В соответствии со вторым допущением имеем:

T (n) =T (?) . (2.5.4)

При одинаковых T (?) наработка между (n-1) и n отказами — случайная величина T (n) — имеет математическое ожидание:

m t (n) =M=nm ? t (2.5.6)

T (n) = ? ? t ; (2.5.7)

Для случайной величины T n математическое ожидание равно:

M ? t ; (2.5.8)

и среднеквадратическое отклонение:

T ; (2.5.9)

Чтобы вычислить значения, и, необходимо по данным об отказах программы в течение периода наблюдения t н найти статистические оценки числовых характеристик случайной разности T (i) :

n н — число отказов программы за наработку (0, t н).

Учитывая, что при t >t н число отказов n н >> 1, из (2.5.8) и (2.5.9) имеем:

m t (n) ? m ? t , (2.5.12)

T (n) = ? ? t n ; (2.5.13)

Поскольку случайные величины T (n) и T n согласно (2.5.4) и (2.5.5) равны суммам многих случайных величин, T (n) и T n можно считать распределенными нормально с математическими ожиданиями и дисперсиями, определенными по (2.5.6) — (2.5.9), (2.5.12) и (2.5.13). Так как наработка положительна, на практике используется усеченное на интервале (0, ?) нормальное распределение. Обычно нормирующий множитель с?1.

При n>n н плотность распределения наработки между очередными (n-1) и n отказами:

f (n) (?) = , (2.5.14)

где? отсчитывается с момента последнего, (n-1) отказа.

Заключение

В работе было показано, что надежность программного обеспечения, в десятки раз ниже чем аппаратурная надежность. Требования к программной надежности это определение необходимого выполнения боевых задач в течении не менее чем 1872 часов.

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

Список литературы

программный безотказность надежность прогнозирование

1. В.В. Липаев Проектирование математического обеспечения АСУ. (системотехника, архитектура, технология). М., «Сов. радио», 1977.

2. Р.С. Захарова Основные вопросы теории и практики надежности.

3. В.А. Благодатских, В.А. Волнин, К.Ф. ПоскакаловСтандартизация разработки программных средств.

4. А.А. ВороновТеоретические основы построения автоматизированных систем управления. Разработка технического задания.-М.: Наука, 1997.

5. Основы прикладной теории надежности АСУ. Учебное пособие, Тверь, ВА ПВО, 1995, н/с 32. 965,0-75. В.М. Ионов и др., инв. №8856.

6. Б.Н. Горевич. Расчет показателей надежности систем вооружения и резервированных элементов. Конспект лекций, ВА ПВО, 1998, н/с 68.501.4, Г68, инв. №9100

Размещено на Allbest.ru

Подобные документы

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

дипломная работа , добавлен 03.11.2013

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

курсовая работа , добавлен 02.07.2013

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

лекция , добавлен 22.03.2014

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

презентация , добавлен 22.03.2014

Запросы клиента по области возможных запросов к серверу. Программа для прогнозирования поведения надежности программного обеспечения на основе метода Монте-Карло. Влияние количества программ-клиентов на поведение программной системы клиент-сервера.

контрольная работа , добавлен 03.12.2010

Особенности аналитической и эмпирической моделей надежности программных средств. Проектирование алгоритма тестирования и разработка программы для определения надежности ПО моделями Шумана, Миллса, Липова, с использованием языка C# и VisualStudio 2013.

курсовая работа , добавлен 29.06.2014

Надежность системы управления как совокупность надежности технических средств, вычислительной машины, программного обеспечения и персонала. Расчет надежности технических систем, виды отказов САУ и ТСА, повышение надежности и причины отказов САУ.

курс лекций , добавлен 27.05.2008

Точные и приближенные методы анализа структурной надежности. Критерии оценки структурной надежности методом статистического моделирования. Разработка алгоритма и программы расчета структурной надежности. Методические указания по работе с программой.

дипломная работа , добавлен 17.11.2010

Постановка проблемы надежности программного обеспечения и причины ее возникновения. Характеристики надежности аппаратуры. Компьютерная программа как объект исследования, ее надежность и правильность. Модель последовательности испытаний Бернулли.

реферат , добавлен 21.12.2010

Надежность как характеристика качества программного обеспечения (ПО). Методика расчета характеристик надежности ПО (таких как, время наработки до отказа, коэффициент готовности, вероятность отказа), особенности прогнозирования их изменений во времени.

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

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

Просматривайте свои проекты

Лучшее использование вашего времени — это внимательно изучить
проект 2, чтобы понять, почему у вас такой высокий уровень
дефектов. Осмотрите свои процессы, сформируйте гипотезу, а затем
попытайтесь адаптировать свои процессы, чтобы уменьшить
дефекты.

Хороший руководитель проекта не будет тратить время на создание
«универсальной теории всего» на основе экстраполяции из двух
проектов. Вместо этого опытный руководитель проекта потратил на это
время fixing
Project 2, чтобы улучшить свои шансы на
успех, или сообщив о вероятности неудачи менеджера портфеля, чтобы
можно было принять стратегическое решение о том, проект должен быть
прекращен в качестве меры контроля затрат или качества.

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

Разработчики, которые оставили файл

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

The rules
about bugs is to test from early
stages of development, and to keep a 1:1 or 2:1 ratio of
programmers to testers. Then you can safely assume the
testing-debugging stage will take as long as the time originally
estimated to write the code.

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

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

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

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

Значительная часть производственного процесса опирается на тестирование программ. Что это такое и как осуществляется подобная деятельность обсудим в данной статье.

Что называют тестированием?

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

Эффективность

То, насколько хорошо и быстро находятся ошибки, существенным образом влияет на стоимость и длительность разработки программного обеспечения необходимого качества. Так, несмотря на то, что тестеры получают заработную плату в несколько раз меньшую, чем программисты, стоимость их услуг обычно достигает 30 — 40 % от стоимости всего проекта. Это происходит из-за численности личного состава, поскольку искать ошибку — это необычный и довольно трудный процесс. Но даже если программное обеспечение прошло солидное количество тестов, то нет 100 % гарантии, что ошибок не будет. Просто неизвестно, когда они проявятся. Чтобы стимулировать тестеров выбирать типы проверки, которые с большей вероятностью найдут ошибку, применяются различные средства мотивации: как моральные, так и материальные.

Подход к работе

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

Что такое тест?

Это немаловажный аспект деятельности проверяющего, который необходим для успешного выявления недочетов программного кода. Они необходимы для того, чтобы контролировать правильность приложения. Что входит в тест? Он состоит их начальных данных и значений, которые должны получиться как результирующие (или промежуточные). Для того чтобы успешнее выявлять проблемы и несоответствия, тесты необходимо составлять после того, как был разработан алгоритм, но не началось программирование. Причем желательно использовать несколько подходов при расчете необходимых данных. В таком случае растёт вероятность обнаружения ошибки благодаря тому, что можно исследовать код с другой точки зрения. Комплексно тесты должны обеспечивать проверку внешних эффектов готового программного изделия, а также его алгоритмов работы. Особенный интерес предоставляют предельные и вырожденные случаи. Так, в практике деятельности с ошибками часто можно выявить, что цикл работает на один раз меньше или больше, чем было запланировано. Также важным является тестирование компьютера, благодаря которому можно проверить соответствие желаемому результату на различных машинах. Это необходимо для того, чтобы удостовериться, что программное обеспечение сможет работать на всех ЭВМ. Кроме того, тестирование компьютера, на котором будет выполняться разработка, является важным при создании мультиплатформенных разработок.

Искусство поиска ошибок

Программы часто нацелены на работу с огромным массивом данных. Неужели его необходимо создавать полностью? Нет. Широкое распространение приобрела практика «миниатюризации» программы. В данном случае происходит разумное сокращение объема данных по сравнению с тем, что должно использоваться. Давайте рассмотрим такой пример: есть программа, в которой создаётся матрица размером 50×50. Иными словами — необходимо вручную ввести 2500 тысячи значений. Это, конечно, возможно, но займёт очень много времени. Но чтобы проверить работоспособность, программный продукт получает матрицу, размерность которой составляет 5×5. Для этого нужно будет ввести уже 25 значений. Если в данном случае наблюдается нормальная, безошибочная работа, то это значит, что всё в порядке. Хотя и здесь существуют подводные камни, которые заключаются в том, что при миниатюризации происходит ситуация, в результате которой изменения становятся неявными и временно исчезают. Также очень редко, но всё же случается и такое, что появляются новые ошибки.

Преследуемые цели

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

Проверка в различных условиях

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

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

Тестирование ПО: виды

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

Завершение тестирования

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

Автоматизированное тестирование

Ранее считалось, что динамический анализ разработанного ПО — это слишком тяжелый подход, который неэффективно использовать для обнаружения дефектов. Но из-за увеличения сложности и объема программ появился противоположный взгляд. Автоматическое тестирование применяется там, где самыми важными приоритетами является работоспособность и безопасность. И они должны быть при любых входных данных. В качестве примера программ, для которых целесообразным является такое тестирование, можно привести следующие: сетевые протоколы, веб-сервер, sandboxing. Мы далее рассмотрим несколько образцов, которые можно использовать для такой деятельности. Если интересуют бесплатные программы тестирования, то среди них качественные найти довольно сложно. Но существуют взломанные «пиратские» версии хорошо зарекомендовавших себя проектов, поэтому можно обратиться к их услугам.

Avalanche

Этот инструмент помогает обнаружить дефекты, проходя тестирование программ в режиме динамического анализа. Он собирает данные и анализирует трассу выполнения разработанного объекта. Тестеру же предоставляется набор входных данных, которые вызывают ошибку или обходят набор имеющихся ограничений. Благодаря наличию хорошего алгоритма проверки разрабатывается большое количество возможных ситуаций. Программа получает различные наборы входных данных, которые позволяют смоделировать значительное число ситуаций и создать такие условия, когда наиболее вероятным является возникновение сбоя. Важным преимуществом программы считается применение эвристической метрики. Если есть проблема, то ошибка приложения находится с высокой вероятностью. Но эта программа имеет ограничения вроде проверки только одного помеченного входного сокета или файла. При проведении такой операции, как тестирование программ, будет содержаться детальная информация о наличие проблем с нулевыми указателями, бесконечными циклами, некорректными адресами или неисправностями из-за использования библиотек. Конечно, это не полный список обнаруживаемых ошибок, а только их распространённые примеры. Исправлять недочеты, увы, придётся разработчикам — автоматические средства для этих целей не подходят.

KLEE

Это хорошая программа для тестирования памяти. Она может перехватывать примерно 50 системных вызовов и большое количество виртуальных процессов, таким образом, выполняется параллельно и отдельно. Но в целом программа не ищет отдельные подозрительные места, а обрабатывает максимально возможное количество кода и проводит анализ используемых путей передачи данных. Из-за этого время тестирования программы зависит от размера объекта. При проверке ставка сделана на символические процессы. Они являются одним из возможных путей выполнения задач в программе, которая проверяется. Благодаря параллельной работе можно анализировать большое количество вариантов работы исследуемого приложения. Для каждого пути после окончания его тестирования сохраняются наборы входных данных, с которых начиналась проверка. Следует отметить, что тестирование программ с помощью KLEE помогает выявлять большое количество отклонений, которых не должно быть. Она может найти проблемы даже в приложениях, которые разрабатываются десятилетиями.

Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая (после предупреждения ошибок) стратегия — включить средства обнаружения ошибок в само про-граммное обеспечение.

Большинство методов направлено по возможности на неза-медлительное обнаружение сбоев. Немедленное обнаружение имеет два преимущества: можно минимизировать влияние ошиб-ки и последующие затруднения для человека, которому придется извлекать информацию о ней, находить ее и исправлять.

{SITELINK-S405}Меры по обнаружению ошибок {/SITELINK}можно разбить на две под-группы: пассивные

попытки обнаружить симптомы ошибки в про-цессе «обычной» работы программного обеспечения и активные

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

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

Разрабатывая эти меры, мы будем опираться на следующее.

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

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

3. Избыточность.
Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).

Когда разрабатываются {SITELINK-S405}меры по обнаружению ошибок{/SITELINK}, важ-но принять согласованную стратегию для всей системы. Действия, предпринимаемые после обнаружения ошибки в программном обеспечении, должны быть единообразными для всех компонен-тов системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение — немедленно завершить выполнение программы или (в случае операционной системы) перевести центральный про-цессор в состояние ожидания. С точки зрения предоставления че-ловеку, отлаживающему программу, например системному про-граммисту, самых благоприятных условий для диагностики оши-бок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что при-останавливать работу системы нельзя). В таком случае использу-ется метод регистрации ошибок.
Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняются во внеш-нем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом.

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

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

Активные средства обнаружения ошибок обычно объединя-ются в диагностический монитор:
параллельный процесс, кото-рый периодически анализирует состояние системы с целью обна-ружить ошибку. Большие программные системы, управляющие ресурсами, часто содержат ошибки, приводящие к потере ресур-сов на длительное время. Например, управление памятью опера-ционной системы сдает блоки памяти «в аренду» программам пользователей и другим частям операционной системы. Ошибка в этих самых «других частях» системы может иногда вести к не-правильной работе блока управления памятью, занимающегося возвратом сданной ранее в аренду памяти, что вызывает медлен-ное вырождение системы.

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

Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вы-зывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время вы-полнения. Монитор может также периодически предъявлять сис-теме «пустые» или «легкие» задания, чтобы убедиться, что система функционирует хотя бы самым примитивным образом.

From Wikipedia, the free encyclopedia

The technique for human error-rate prediction (THERP) is a technique used in the field of human reliability assessment (HRA), for the purposes of evaluating the probability of a human error occurring throughout the completion of a specific task. From such analyses measures can then be taken to reduce the likelihood of errors occurring within a system and therefore lead to an improvement in the overall levels of safety. There exist three primary reasons for conducting an HRA: error identification, error quantification and error reduction. As there exist a number of techniques used for such purposes, they can be split into one of two classifications: first-generation techniques and second-generation techniques. First-generation techniques work on the basis of the simple dichotomy of ‘fits/doesn’t fit’ in matching an error situation in context with related error identification and quantification. Second generation techniques are more theory-based in their assessment and quantification of errors. ‘HRA techniques have been utilised for various applications in a range of disciplines and industries including healthcare, engineering, nuclear, transportation and business.

THERP models human error probabilities (HEPs) using a fault-tree approach, in a similar way to an engineering risk assessment, but also accounts for performance shaping factors (PSFs) that may influence these probabilities. The probabilities for the human reliability analysis event tree (HRAET), which is the primary tool for assessment, are nominally calculated from the database developed by the authors Swain and Guttman; local data e.g. from simulators or accident reports may however be used instead. The resultant tree portrays a step by step account of the stages involved in a task, in a logical order. The technique is known as a total methodology ^[1] as it simultaneously manages a number of different activities including task analysis, error identification, representation in form of HRAET and HEP quantification.

Background[edit]

The technique for human error rate prediction (THERP) is a first generation methodology, which means that its procedures follow the way conventional reliability analysis models a machine.^[2] The technique was developed in the Sandia Laboratories for the US Nuclear Regulatory Commission.^[3] Its primary author is Swain, who developed the THERP methodology gradually over a lengthy period of time.^[1] THERP relies on a large human reliability database that contains HEPs, and is based upon both plant data and expert judgments. The technique was the first approach in HRA to come into broad use and is still widely used in a range of applications even beyond its original nuclear setting.

THERP methodology[edit]

The methodology for the THERP technique is broken down into 5 main stages:

1. Define the system failures of interest
These failures include functions of the system where human error has a greater likelihood of influencing the probability of a fault, and those of interest to the risk assessor; operations in which there may be no interest include those not operationally critical or those for which there already exist safety counter measures.

2. List and analyse the related human operations, and identify human errors that can occur and relevant human error recovery modes
This stage of the process necessitates a comprehensive task and human error analysis. The task analysis lists and sequences the discrete elements and information required by task operators. For each step of the task, possible errors are considered by the analyst and precisely defined. The possible errors are then considered by the analyst, for each task step. Such errors can be broken down into the following categories:

• Errors of omission – leaving out a step of the task or the whole task itself
• Error of commission – this involves several different types of error:
  • Errors of selection – error in use of controls or in issuing of commands
  • Errors of sequence – required action is carried out in the wrong order
  • Errors of timing – task is executed before or after when required
  • Errors of quantity – inadequate amount or in excess

The opportunity for error recovery must also be considered as this, if achieved, has the potential to drastically reduce error probability for a task.

The tasks and associated outcomes are input to an HRAET in order to provide a graphical representation of a task’s procedure. The trees’ compatibility with conventional event-tree methodology i.e. including binary decision points at the end of each node, allows it to be evaluated mathematically.

An event tree visually displays all events that occur within a system. It starts off with an initiating event, then branches develop as various consequences of the starting event. These are represented in a number of different paths, each associated with a probability of occurrence. As mentioned previously, the tree works on a binary logic, so each event either succeeds or fails. With the addition of the probabilities for the individual events along each path, i.e., branches, the likelihood of the various outcomes can be found. Below is an example of an event tree that represents a system fire:

Therefore, under the condition that all of a task’s sub-tasks are fully represented within a HRAET, and the failure probability for each sub-task is known, this makes it possible to calculate the final reliability for the task.

3. Estimate the relevant error probabilities
HEPs for each sub-task are entered into the tree; it is necessary for all failure branches to have a probability otherwise the system will fail to provide a final answer. HRAETs provide the function of breaking down the primary operator tasks into finer steps, which are represented in the form of successes and failures. This tree indicates the order in which the events occur and also considers likely failures that may occur at each of the represented branches. The degree to which each high level task is broken down into lower level tasks is dependent on the availability of HEPs for the successive individual branches. The HEPs may be derived from a range of sources such as: the THERP database; simulation data; historical accident data; expert judgement. PSFs should be incorporated into these HEP calculations; the primary source of guidance for this is the THERP handbook. However the analyst must use their own discretion when deciding the extent to which each of the factors applies to the task

4. Estimate the effects of human error on the system failure events
With the completion of the HRA the human contribution to failure can then be assessed in comparison with the results of the overall reliability analysis. This can be completed by inserting the HEPs into the full system’s fault event tree, which allows human factors to be considered within the context of the full system.

5. Recommend changes to the system and recalculate the system failure probabilities
Once the human factor contribution is known, sensitivity analysis can be used to identify how certain risks may be improved in the reduction of HEPs. Error recovery paths may be incorporated into the event tree as this will aid the assessor when considering the possible approaches by which the identified errors can be reduced.

Worked example[edit]

Context[edit]

The following example illustrates how the THERP methodology can be used in practice in the calculation of human error probabilities (HEPs). It is used to determine the HEP for establishing air based ventilation using emergency purge ventilation equipment on in-tank precipitation (ITP) processing tanks 48 and 49 after failure of the nitrogen purge system following a seismic event.

Assumptions[edit]

In order for the final HEP calculation to be valid, the following assumptions require to be fulfilled:

1. There exists a seismic event initiator that leads to the establishment of air based ventilation on the ITP processing tanks 48 and 49
2. It is assumed that both on and offsite power is unavailable within the context and therefore control actions performed by the operator are done so locally, on the tank top
3. The time available for operations personnel to establish air based ventilation by use of the emergency purge ventilation, following the occurrence of the seismic event, is a duration of 3 days
4. There is a necessity for an ITP equipment status monitoring procedure to be developed to allow for a consistent method to be adopted for the purposes of evaluating the ITP equipment and component status and selected process parameters for the period of an accident condition
5. Assumed response times exist for initial diagnosis of the event and for the placement of emergency purge ventilation equipment on the tank top. The former is 10 hours while the latter is 4 hours.
6. The in-tank precipitation process has associated operational safety requirements (OSR) that identify the precise conditions under which the emergency purge ventilation equipment should be hooked up to the riser
7. The “tank 48 system” standard operating procedure has certain conditions and actions that must be included within for correct completion to be performed (see file for more details)
8. A vital component of the emergency purge ventilation equipment unit is a flow indicator; this is required in the event of the emergency purge ventilation equipment being hooked up incorrectly as it would allow for a recovery action
9. The personnel available to perform the necessary tasks all possess the required skills
10. Throughout the installation of the emergency purge ventilation equipment, carried out by maintenance personnel, a tank operator must be present to monitor this process.

Method[edit]

An initial task analysis was carried out on the off normal procedure and standard operating procedure. This allowed for the operator to align and then initiate the emergency purge ventilation equipment given the loss of the ventilation system.
Thereafter, each individual task was analyzed from which it was then possible to assign error probabilities and error factors to events that represented operator responses.

• A number of the HEPs were adjusted to take account of various identified performance-shaping factors (PSFs)
• Upon assessment of characteristics of the task and behavior of the crew, recovery probabilities were deciphered. Such probabilities are influenced by such factors as task familiarity, alarms and independent checking
• Once error probabilities were decided upon for the individual tasks, event trees were then constructed from which calculation formulations were derived. The probability of failure was obtained through the multiplication of each of the failure probabilities along the path under consideration.

HRA event tree for align and start emergency purge ventilation equipment on in-tank precipitation tank 48 or 49 after a seismic event

The summation of each of the failure path probabilities provided the total failure path probability (FT)

Results[edit]

• Task A: Diagnosis, HEP 6.0E-4 EF=30
• Task B: Visual inspection performed swiftly, recovery factor HEP=0.001 EF=3
• Task C: Initiate standard operating procedure HEP= .003 EF=3
• Task D: Maintainer hook-up emergency purge ventilation equipment HEP=.003 EF=3
• Task E: Maintainer 2 hook-up emergency purge, recovery factor CHEP=0.5 EF=2
• Task G: Tank operator instructing /verifying hook-up, recovery factor CHEP=0.5 Lower bound = .015 Upper bound = 0.15
• Task H: Read flow indicator, recovery factor CHEP= .15 Lower bound= .04 Upper bound = .5
• Task I: Diagnosis HEP= 1.0E-5 EF=30
• Task J: Analyse LFL using portable LFL analyser, recovery factor CHEP= 0.5 Lower bound = .015 Upper bound =.15

From the various figures and workings, it can be determined that the HEP for establishing air based ventilation using the emergency purge ventilation equipment on In-tank Precipitation processing tanks 48 and 49 after a failure of the nitrogen purge system following a seismic event is 4.2 E-6. This numerical value is judged to be a median value on the lognormal scale. However, this result is only valid given that all the previously stated assumptions are implemented.

Advantages of THERP[edit]

• It is possible to use THERP at all stages of design. Furthermore, THERP is not restricted to the assessment of designs already in place and due to the level of detail in the analysis it can be specifically tailored to the requirements of a particular assessment.^[4]
• THERP is compatible with Probabilistic Risk Assessments (PRA); the methodology of the technique means that it can be readily integrated with fault tree reliability methodologies.^[4]
• The THERP process is transparent, structured and provides a logical review of the human factors considered in a risk assessment; this allows the results to be examined in a straightforward manner and assumptions to be challenged.^[4]
• The technique can be utilized within a wide range of differing human reliability domains and has a high degree of face validity.^[4]
• It is a unique methodology in the way that it highlights error recovery and it also quantitatively models a dependency relation between the various actions or errors.

Disadvantages of THERP[edit]

• THERP analysis is very resource intensive, and may require a large amount of effort to produce reliable HEP values. This can be controlled by ensuring an accurate assessment of the level of work required in the analysis of each stage.^[4]
• The technique does not lend itself to system improvement. Compared to some other Human Reliability Assessment tools such as HEART, THERP is a relatively unsophisticated tool as the range of PSFs considered is generally low and the underlying psychological causes of errors are not identified.
• With regards to the consistency of the technique, large discrepancies have been found in practice with regards to different analysts assessment of the risk associated with the same tasks. Such discrepancies may have arisen from either the process mapping of the tasks in question or in the estimation of the HEPs associated with each of the tasks through the use of THERP tables compared to, for example, expert judgement or the application of PSFs.^[5][6]
• The methodology fails to provide guidance to the assessor in how to model the impact of PSFs and the influence of the situation on the errors being assessed.
• The THERP HRAETs implicitly assume that each sub-task’s HEP is independent from all others i.e. the HRAET does not update itself in the event that an operator takes a suboptimal route through the task path. This is reinforced by the HEP being merely reduced by the chance of recovery from a mistake, rather than by introducing alternative (i.e. suboptimal) “success” routes into the event-tree, which could allow for Bayesian updating of subsequent HEPs.
• THERP is a “first generation” HRA tool, and in common with other such tools has been criticized for not taking adequate account of context.^[2]

Other human reliability assessments[edit]

Other Human Reliability Assessments (HRA) have been created by multiple different researchers. They include cognitive reliability and error analysis method (CREAM), technique for human error assessment (THEA), cause based decision tree (CBDT), human error repository and analysis (HERA), standardized plant analysis risk (SPAR), a technique for human error analysis (ATHEANA), human error HAZOP, system for predictive error analysis and reduction (SPEAR), and human error assessment and reduction technique (HEART).^[7]

References[edit]

From Wikipedia, the free encyclopedia

The technique for human error-rate prediction (THERP) is a technique used in the field of human reliability assessment (HRA), for the purposes of evaluating the probability of a human error occurring throughout the completion of a specific task. From such analyses measures can then be taken to reduce the likelihood of errors occurring within a system and therefore lead to an improvement in the overall levels of safety. There exist three primary reasons for conducting an HRA: error identification, error quantification and error reduction. As there exist a number of techniques used for such purposes, they can be split into one of two classifications: first-generation techniques and second-generation techniques. First-generation techniques work on the basis of the simple dichotomy of ‘fits/doesn’t fit’ in matching an error situation in context with related error identification and quantification. Second generation techniques are more theory-based in their assessment and quantification of errors. ‘HRA techniques have been utilised for various applications in a range of disciplines and industries including healthcare, engineering, nuclear, transportation and business.

THERP models human error probabilities (HEPs) using a fault-tree approach, in a similar way to an engineering risk assessment, but also accounts for performance shaping factors (PSFs) that may influence these probabilities. The probabilities for the human reliability analysis event tree (HRAET), which is the primary tool for assessment, are nominally calculated from the database developed by the authors Swain and Guttman; local data e.g. from simulators or accident reports may however be used instead. The resultant tree portrays a step by step account of the stages involved in a task, in a logical order. The technique is known as a total methodology ^[1] as it simultaneously manages a number of different activities including task analysis, error identification, representation in form of HRAET and HEP quantification.

Background[edit]

The technique for human error rate prediction (THERP) is a first generation methodology, which means that its procedures follow the way conventional reliability analysis models a machine.^[2] The technique was developed in the Sandia Laboratories for the US Nuclear Regulatory Commission.^[3] Its primary author is Swain, who developed the THERP methodology gradually over a lengthy period of time.^[1] THERP relies on a large human reliability database that contains HEPs, and is based upon both plant data and expert judgments. The technique was the first approach in HRA to come into broad use and is still widely used in a range of applications even beyond its original nuclear setting.

THERP methodology[edit]

The methodology for the THERP technique is broken down into 5 main stages:

1. Define the system failures of interest
These failures include functions of the system where human error has a greater likelihood of influencing the probability of a fault, and those of interest to the risk assessor; operations in which there may be no interest include those not operationally critical or those for which there already exist safety counter measures.

2. List and analyse the related human operations, and identify human errors that can occur and relevant human error recovery modes
This stage of the process necessitates a comprehensive task and human error analysis. The task analysis lists and sequences the discrete elements and information required by task operators. For each step of the task, possible errors are considered by the analyst and precisely defined. The possible errors are then considered by the analyst, for each task step. Such errors can be broken down into the following categories:

• Errors of omission – leaving out a step of the task or the whole task itself
• Error of commission – this involves several different types of error:
  • Errors of selection – error in use of controls or in issuing of commands
  • Errors of sequence – required action is carried out in the wrong order
  • Errors of timing – task is executed before or after when required
  • Errors of quantity – inadequate amount or in excess

The opportunity for error recovery must also be considered as this, if achieved, has the potential to drastically reduce error probability for a task.

The tasks and associated outcomes are input to an HRAET in order to provide a graphical representation of a task’s procedure. The trees’ compatibility with conventional event-tree methodology i.e. including binary decision points at the end of each node, allows it to be evaluated mathematically.

An event tree visually displays all events that occur within a system. It starts off with an initiating event, then branches develop as various consequences of the starting event. These are represented in a number of different paths, each associated with a probability of occurrence. As mentioned previously, the tree works on a binary logic, so each event either succeeds or fails. With the addition of the probabilities for the individual events along each path, i.e., branches, the likelihood of the various outcomes can be found. Below is an example of an event tree that represents a system fire:

Therefore, under the condition that all of a task’s sub-tasks are fully represented within a HRAET, and the failure probability for each sub-task is known, this makes it possible to calculate the final reliability for the task.

3. Estimate the relevant error probabilities
HEPs for each sub-task are entered into the tree; it is necessary for all failure branches to have a probability otherwise the system will fail to provide a final answer. HRAETs provide the function of breaking down the primary operator tasks into finer steps, which are represented in the form of successes and failures. This tree indicates the order in which the events occur and also considers likely failures that may occur at each of the represented branches. The degree to which each high level task is broken down into lower level tasks is dependent on the availability of HEPs for the successive individual branches. The HEPs may be derived from a range of sources such as: the THERP database; simulation data; historical accident data; expert judgement. PSFs should be incorporated into these HEP calculations; the primary source of guidance for this is the THERP handbook. However the analyst must use their own discretion when deciding the extent to which each of the factors applies to the task

4. Estimate the effects of human error on the system failure events
With the completion of the HRA the human contribution to failure can then be assessed in comparison with the results of the overall reliability analysis. This can be completed by inserting the HEPs into the full system’s fault event tree, which allows human factors to be considered within the context of the full system.

5. Recommend changes to the system and recalculate the system failure probabilities
Once the human factor contribution is known, sensitivity analysis can be used to identify how certain risks may be improved in the reduction of HEPs. Error recovery paths may be incorporated into the event tree as this will aid the assessor when considering the possible approaches by which the identified errors can be reduced.

Worked example[edit]

Context[edit]

The following example illustrates how the THERP methodology can be used in practice in the calculation of human error probabilities (HEPs). It is used to determine the HEP for establishing air based ventilation using emergency purge ventilation equipment on in-tank precipitation (ITP) processing tanks 48 and 49 after failure of the nitrogen purge system following a seismic event.

Assumptions[edit]

In order for the final HEP calculation to be valid, the following assumptions require to be fulfilled:

1. There exists a seismic event initiator that leads to the establishment of air based ventilation on the ITP processing tanks 48 and 49
2. It is assumed that both on and offsite power is unavailable within the context and therefore control actions performed by the operator are done so locally, on the tank top
3. The time available for operations personnel to establish air based ventilation by use of the emergency purge ventilation, following the occurrence of the seismic event, is a duration of 3 days
4. There is a necessity for an ITP equipment status monitoring procedure to be developed to allow for a consistent method to be adopted for the purposes of evaluating the ITP equipment and component status and selected process parameters for the period of an accident condition
5. Assumed response times exist for initial diagnosis of the event and for the placement of emergency purge ventilation equipment on the tank top. The former is 10 hours while the latter is 4 hours.
6. The in-tank precipitation process has associated operational safety requirements (OSR) that identify the precise conditions under which the emergency purge ventilation equipment should be hooked up to the riser
7. The “tank 48 system” standard operating procedure has certain conditions and actions that must be included within for correct completion to be performed (see file for more details)
8. A vital component of the emergency purge ventilation equipment unit is a flow indicator; this is required in the event of the emergency purge ventilation equipment being hooked up incorrectly as it would allow for a recovery action
9. The personnel available to perform the necessary tasks all possess the required skills
10. Throughout the installation of the emergency purge ventilation equipment, carried out by maintenance personnel, a tank operator must be present to monitor this process.

Method[edit]

An initial task analysis was carried out on the off normal procedure and standard operating procedure. This allowed for the operator to align and then initiate the emergency purge ventilation equipment given the loss of the ventilation system.
Thereafter, each individual task was analyzed from which it was then possible to assign error probabilities and error factors to events that represented operator responses.

• A number of the HEPs were adjusted to take account of various identified performance-shaping factors (PSFs)
• Upon assessment of characteristics of the task and behavior of the crew, recovery probabilities were deciphered. Such probabilities are influenced by such factors as task familiarity, alarms and independent checking
• Once error probabilities were decided upon for the individual tasks, event trees were then constructed from which calculation formulations were derived. The probability of failure was obtained through the multiplication of each of the failure probabilities along the path under consideration.

HRA event tree for align and start emergency purge ventilation equipment on in-tank precipitation tank 48 or 49 after a seismic event

The summation of each of the failure path probabilities provided the total failure path probability (FT)

Results[edit]

• Task A: Diagnosis, HEP 6.0E-4 EF=30
• Task B: Visual inspection performed swiftly, recovery factor HEP=0.001 EF=3
• Task C: Initiate standard operating procedure HEP= .003 EF=3
• Task D: Maintainer hook-up emergency purge ventilation equipment HEP=.003 EF=3
• Task E: Maintainer 2 hook-up emergency purge, recovery factor CHEP=0.5 EF=2
• Task G: Tank operator instructing /verifying hook-up, recovery factor CHEP=0.5 Lower bound = .015 Upper bound = 0.15
• Task H: Read flow indicator, recovery factor CHEP= .15 Lower bound= .04 Upper bound = .5
• Task I: Diagnosis HEP= 1.0E-5 EF=30
• Task J: Analyse LFL using portable LFL analyser, recovery factor CHEP= 0.5 Lower bound = .015 Upper bound =.15

From the various figures and workings, it can be determined that the HEP for establishing air based ventilation using the emergency purge ventilation equipment on In-tank Precipitation processing tanks 48 and 49 after a failure of the nitrogen purge system following a seismic event is 4.2 E-6. This numerical value is judged to be a median value on the lognormal scale. However, this result is only valid given that all the previously stated assumptions are implemented.

Advantages of THERP[edit]

• It is possible to use THERP at all stages of design. Furthermore, THERP is not restricted to the assessment of designs already in place and due to the level of detail in the analysis it can be specifically tailored to the requirements of a particular assessment.^[4]
• THERP is compatible with Probabilistic Risk Assessments (PRA); the methodology of the technique means that it can be readily integrated with fault tree reliability methodologies.^[4]
• The THERP process is transparent, structured and provides a logical review of the human factors considered in a risk assessment; this allows the results to be examined in a straightforward manner and assumptions to be challenged.^[4]
• The technique can be utilized within a wide range of differing human reliability domains and has a high degree of face validity.^[4]
• It is a unique methodology in the way that it highlights error recovery and it also quantitatively models a dependency relation between the various actions or errors.

Disadvantages of THERP[edit]

• THERP analysis is very resource intensive, and may require a large amount of effort to produce reliable HEP values. This can be controlled by ensuring an accurate assessment of the level of work required in the analysis of each stage.^[4]
• The technique does not lend itself to system improvement. Compared to some other Human Reliability Assessment tools such as HEART, THERP is a relatively unsophisticated tool as the range of PSFs considered is generally low and the underlying psychological causes of errors are not identified.
• With regards to the consistency of the technique, large discrepancies have been found in practice with regards to different analysts assessment of the risk associated with the same tasks. Such discrepancies may have arisen from either the process mapping of the tasks in question or in the estimation of the HEPs associated with each of the tasks through the use of THERP tables compared to, for example, expert judgement or the application of PSFs.^[5][6]
• The methodology fails to provide guidance to the assessor in how to model the impact of PSFs and the influence of the situation on the errors being assessed.
• The THERP HRAETs implicitly assume that each sub-task’s HEP is independent from all others i.e. the HRAET does not update itself in the event that an operator takes a suboptimal route through the task path. This is reinforced by the HEP being merely reduced by the chance of recovery from a mistake, rather than by introducing alternative (i.e. suboptimal) “success” routes into the event-tree, which could allow for Bayesian updating of subsequent HEPs.
• THERP is a “first generation” HRA tool, and in common with other such tools has been criticized for not taking adequate account of context.^[2]

Other human reliability assessments[edit]

Other Human Reliability Assessments (HRA) have been created by multiple different researchers. They include cognitive reliability and error analysis method (CREAM), technique for human error assessment (THEA), cause based decision tree (CBDT), human error repository and analysis (HERA), standardized plant analysis risk (SPAR), a technique for human error analysis (ATHEANA), human error HAZOP, system for predictive error analysis and reduction (SPEAR), and human error assessment and reduction technique (HEART).^[7]

References[edit]