Управление ошибками виды управления ошибками

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

Виды ошибок

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

• Пользовательские ошибки: здесь под пользователем подразумевается человек, сидящий перед компьютером и действительно «использующий» программу, а не какой-то программист, дёргающий ваш API. Такие ошибки возникают тогда, когда пользователь делает что-то неправильно.
• Системные ошибки появляются, когда ОС не может выполнить ваш запрос. Иными словами, причина системных ошибок — сбой вызова системного API. Некоторые возникают потому, что программист передал системному вызову плохие параметры, так что это скорее программистская ошибка, а не системная.
• Программистские ошибки случаются, когда программист не учитывает предварительные условия API или языка программирования. Если API требует, чтобы вы не вызывали foo() с 0 в качестве первого параметра, а вы это сделали, — виноват программист. Если пользователь ввёл 0, который был передан foo(), а программист не написал проверку вводимых данных, то это опять же его вина.

Каждая из описанных категорий ошибок требует особого подхода к их обработке.

Пользовательские ошибки

Сделаю очень громкое заявление: такие ошибки — на самом деле не ошибки.

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

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

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

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

Системные ошибки

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

Но как их обрабатывать, как исправимые или неисправимые?

Это зависит от обстоятельств.

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

Но падение программы из-за того, что ОС не может выделить сокет, — это не слишком дружелюбное поведение. Так что лучше бросить исключение и позволить catch аккуратно закрыть программу.

Но бросание исключения — не всегда правильный выбор.

Кто-то даже скажет, что он всегда неправильный.

Если вы хотите повторить операцию после её сбоя, то обёртывание функции в try-catch в цикле — медленное решение. Правильный выбор — возврат кода ошибки и цикличное исполнение, пока не будет возвращено правильное значение.

Если вы создаёте вызов API только для себя, то просто выберите подходящий для своей ситуации путь и следуйте ему. Но если вы пишете библиотеку, то не знаете, чего хотят пользователи. Дальше мы разберём подходящую стратегию для этого случая. Для потенциально неисправимых ошибок подойдёт «обработчик ошибок», а при других ошибках необходимо предоставить два варианта развития событий.

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

Программистские ошибки

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

При работе с плохими параметрами есть две стратегии: дать им определённое или неопределённое поведение.

Если исходное требование для функции — запрет на передачу ей плохих параметров, то, если их передать, это считается неопределённым поведением и должно проверяться не самой функцией, а оператором вызова (caller). Функция должна делать только отладочное подтверждение (debug assertion).

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

В качестве примера рассмотрим получающие функции (accessor functions) std::vector<T>: в спецификации на operator[] говорится, что индекс должен быть в пределах валидного диапазона, при этом at() сообщает нам, что функция кинет исключение, если индекс не попадает в диапазон. Более того, большинство реализаций стандартных библиотек обеспечивают режим отладки, в котором проверяется индекс operator[], но технически это неопределённое поведение, оно не обязано проверяться.

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

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

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

Но конечное решение зависит от многих других факторов, так что очень трудно дать какой-то общий совет. По умолчанию я стараюсь свести к неопределённому поведению и использованию только подтверждений. Иногда бывает целесообразно обеспечить оба варианта, как это делает стандартная библиотека с operator[] и at().

Хотя в ряде случаев это может быть ошибкой.

Об иерархии std::exception

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

Я предлагаю наследовать только от одного из этих четырёх классов:

• std::bad_alloc: для сбоев выделения памяти.
• std::runtime_error: для общих runtime-ошибок.
• std::system_error (производное от std::runtime_error): для системных ошибок с кодами ошибок.
• std::logic_error: для программистских ошибок с определённым поведением.

Обратите внимание, что в стандартной библиотеке разделяются логические (то есть программистские) и runtime-ошибки. Runtime-ошибки — более широкое определение, чем «системные». Оно описывает «ошибки, обнаруживаемые только при выполнении программы». Такая формулировка не слишком информативна. Лично я использую её для плохих параметров, которые не являются исключительно программистскими ошибками, а могут возникнуть и по вине пользователей. Но это можно определить лишь глубоко в стеке вызовов. Например, плохое форматирование комментариев в standardese приводит к исключению при парсинге, проистекающему из std::runtime_error. Позднее оно ловится на соответствующем уровне и фиксируется в логе. Но я не стал бы использовать этот класс иначе, как и std::logic_error.

Подведём итоги

Есть два пути обработки ошибок:

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

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

Есть три основных источника ошибок, каждый требует особого подхода:

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

Гибкие методики обработки ошибок в C++

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

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

В C++ есть два основных подхода: коды возврата ошибок и исключения. Сегодня широко распространено использование исключений. Но некоторые не могут / думают, что не могут / не хотят их использовать — по разным причинам.

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

Проблема

Я работаю над проектом foonathan/memory. Это решение предоставляет различные классы выделения памяти (allocator classes), так что в качестве примера рассмотрим структуру функции выделения.

Для простоты возьмём malloc(). Она возвращает указатель на выделяемую память. Если выделить память не получается, то возвращается nullptr, то есть NULL, то есть ошибочное значение.

У этого решения есть недостатки: вам нужно проверять каждый вызов malloc(). Если вы забудете это сделать, то выделите несуществующую память. Кроме того, по своей натуре коды ошибок транзитивны: если вызвать функцию, которая может вернуть код ошибки, и вы не можете его проигнорировать или обработать, то вы тоже должны вернуть код ошибки.

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

Это можно расценить как недостаток.

Но в подобных ситуациях исключения имеют также очень большое преимущество: функция выделения памяти либо возвращает валидную память, либо вообще ничего не возвращает. Это функция «всё или ничего», возвращаемое значение всегда будет валидным. Это полезное следствие согласно принципу Скотта Майера «Make interfaces hard to use incorrectly and easy to use correctly».

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

Каламбур детектед.

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

Так что же делать?

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

К счастью, я могу определить, что вы делаете, когда обнаруживаете ошибку нехватки памяти: чаще всего вы журналируете это событие и прерываете программу, поскольку она не может корректно работать без памяти. В таких ситуациях исключения — просто способ передачи контроля другой части кода, которая журналирует и прерывает программу. Но есть старый и эффективный способ передачи контроля: указатель функции (function pointer), то есть функция-обработчик (handler function).

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

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

Решение 1: обработчик исключений

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

Сначала дополним класс и добавим функции для настройки и, возможно, запрашивания функции-обработчика. Я предлагаю делать это так же, как стандартная библиотека обрабатывает std::new_handler:

class my_fatal_error
{
public:
    // тип обработчика, он должен брать те же параметры, что и конструктор,
    // чтобы у них была одинаковая информация
    using handler = void(*)( ... );

    // меняет функцию-обработчика
    handler set_handler(handler h);

    // возвращает текущего обработчика
    handler get_handler();

    ... // нормальное исключение
};

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

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

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

If```cpp #if EXCEPTIONS #define THROW(Ex) throw (Ex) #else #define THROW(Ex) (Ex), std::abort() #endif

> Такой макрос throw также предоставляется [foonathan/compatiblity](https://github.com/foonathan/compatibility).

Можно использовать его и так:

```cpp
THROW(my_fatal_error(...))

Если у вас включена поддержка исключений, то будет создан и брошен объект-исключение, всё как обычно. Но если поддержка выключена, то объект-исключение всё равно будет создан, и — это важно — только после этого произойдёт вызов std::abort(). А поскольку конструктор вызывает функцию-обработчика, то он и работает, как требуется: вы получаете точку настройки для журналирования ошибки. Благодаря же вызову std::abort() после конструктора пользователь не может нарушить постусловие.

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

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

А если я хочу продолжить работу после бросания исключения?

Методика с обработчиком исключений не позволяет этого сделать в связи с постусловием кода. Как же тогда продолжить работу?

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

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

Для примера снова возьмём функцию выделения памяти. В этом случае я использую такие функции:

void* try_malloc(..., int &error_code) noexcept;

void* malloc(...);

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

void* malloc(...)
{
    auto error_code = 0;
    auto res = try_malloc(..., error_code);
    if (!res)
        throw malloc_error(error_code);
    return res;
}

Не делайте этого в обратной последовательности, иначе вам придётся ловить исключение, а это дорого. Также это не даст нам скомпилировать код без включённой поддержки исключений. Если сделаете, как показано, то можете просто стереть другую перегрузку (overload) с помощью условного компилирования.

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

Решение 2: предоставить две перегрузки

Если недостаточно обработчика исключений, то нужно предоставить две перегрузки. Одна использует код возврата, а вторая бросает исключение.

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

Пожалуйста, не используйте глобальную переменную errno или что-то типа GetLastError()!

Если возвращаемое значение не содержит недопустимое значение для обозначения сбоя, то по мере возможности используйте std::optional или что-то похожее.

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

std::system_error

Подобная система идеально подходит для работы с кодами ошибок в С++ 11.

Она возвращает непортируемый (non-portable) код ошибки std::error_code, то есть возвращаемый функцией операционной системы. С помощью сложной системы библиотечных средств и категорий ошибок вы можете добавить собственные коды ошибок, или портируемые std::error_condition. Для начала почитайте об этом здесь. Если нужно, то можете использовать в функции кода ошибки std::error_code. А для функции исключения есть подходящий класс исключения: std::system_error. Он берёт std::error_code и применяется для передачи этих ошибок в виде исключений.

Эту или подобную систему должны использовать все низкоуровневые функции, являющиеся закрытыми обёртками ОС-функций. Это хорошая — хотя и сложная — альтернатива службе кодов ошибок, предоставляемой операционной системой.

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

std::expected

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

А глобальные переменные вообще не вариант!

В № 4109 предложено решение: std::expected. Это шаблон класса, который также хранит возвращаемое значение или код ошибки. В вышеприведённом примере он мог бы использоваться так:

std::expected<void*, std::error_code> try_malloc(...);

В случае успеха std::expected будет хранить не-null указатель памяти, а при сбое — std::error_code. Сейчас эта методика работает при любых возвращаемых значениях. Комбинация std::expected и функции исключения определённо допускает любые варианты использования.

Заключение

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

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

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

Теория управления ошибками (EMT ) — это обширная теория искажений восприятия и познания, созданная Дэвид Басс и Марти Хэзелтон. То, как люди думают и принимают решения с использованием эвристики и предубеждений, может быть заложено в человеческий мозг. Обучение управлению ошибками — это смежная область, в которой используется эта теория. Его цель — побудить обучаемых совершать ошибки и побудить их размышлять над тем, чтобы понять причины этих ошибок и определить подходящие стратегии, чтобы избежать их в будущем.

Круги Эббингауза-Титченера

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

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

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

Содержание

• 1 Тип ошибки
• 2 Предвзятость сексуального чрезмерного восприятия
  • 2.1 Мужчины
  • 2.2 Манипуляции
  • 2.3 Исключения
    • 2.3.1 Эффект сестры
    • 2.3.2 Сексуальные интересы и приверженность личным интересам
    • 2.3.3 «Лиса и виноград»
    • 2.3.4 Предвзятость мужской нечувствительности
• 3 Предвзятость сексуального недоверия
  • 3.1 Самки
    • 3.1.1 Скептическая предвзятость
  • 3.2 Исключения
    • 3.2.1 «Скептически папа »и гипотеза« ободрения мамы »
    • 3.2.2 Женщины в постменопаузе
• 4 Альтернативные объяснения
  • 4.1 Культура
  • 4.2 Индивидуальные различия
  • 4.3 Прогноз
  • 4.4 Взаимность
• 5 Другие примеры
• 6 Примечания
• 7 Дополнительная литература

Типовые ошибки

В процессе принятия решения, столкнувшись с неопределенностью, субъект может сделать два возможные ошибки: тип I или тип II.

A ошибка типа I — это ложное срабатывание, предполагающее, что эффект есть, когда его нет. Например, срабатывание пожарной тревоги, которая оказывается ложной. Когда кто-то делает вывод о сексуальном интересе там, где его нет, это означает ложноположительную ошибку.

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

Предвзятое сексуальное чрезмерное восприятие

Мужчины

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

Манипуляция

Различия в восприятии сексуального интереса между мужчинами и женщинами могут эксплуатироваться обоими полами. Мужчины могут представить себя более эмоционально вложенными в женщину, чем они есть на самом деле, чтобы получить к ней сексуальный доступ; 71% мужчин сообщают об участии в этой форме манипуляции, а 97% женщин сообщают, что испытали эту форму манипуляции. Женщины могут представить себя более сексуально заинтересованными в мужчине, чем они есть на самом деле, чтобы удовлетворить другие потребности и желания. Манипуляции создают конфликты между мужчинами и женщинами относительно статуса их отношений. Женщины, подвергшиеся эмоциональным манипуляциям, могут жаловаться на то, что отношения развиваются слишком быстро, в то время как мужчины, подвергающиеся сексуальным манипуляциям, могут жаловаться на то, что их «ведут на»

Исключения

Эффект сестры

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

Сексуальный и личный интерес

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

«Лиса и виноград»

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

предвзятость мужской нечувствительности

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

Предвзятое сексуальное восприятие

Женщины

Женщины также становятся жертвами неправильных представлений во время взаимоотношений мужчины и женщины. Haselton и Buss (2000) утверждают, что эти ошибки в первую очередь проистекают из предполагаемого стремления женщин к преданным отношениям со стороны партнера-мужчины. Женщины разработали стратегии защиты от обмана. Одна из этих эволюционирующих стратегий — совершить предвзятое отношение к скептическим обязательствам.

Скептическая предвзятость

Скептицизм женщин к приверженности возникает из-за высокой цены ложного вывода о приверженности партнера отношениям. Предполагается, что женщины приспособились к когнитивной предвзятости, не воспринимающей мужской интерес и приверженность. Это связано с дороговизной ложного срабатывания (когда мужчина не совершает никаких действий, а женщина принимает его), что может привести к воспитанию ребенка без помощника-инвестора, репутационному ущербу и риску снижения шансов на будущие ухаживания. Цена ложноотрицательного результата — когда мужчина предан, а женщина его отвергает — для женщины обходится гораздо дешевле. Женщины ограничены тем, сколько детей они могут иметь за всю жизнь, однако мужчины не ограничены и могут воспроизводить несколько раз, поэтому для женщин издержки чрезмерного восприятия выше. Эта гипотеза кратко упоминается Бассом (2012).

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

Исключения

«Скептический папа» и «Ободряющая мама» гипотеза

Раньше скептицизм в отношении приверженности и чрезмерное восприятие считались специфическими для пола. Женщины недооценивают или не могут вывести психологическое состояние, которое существует, чтобы предотвратить ложноотрицательную ошибку. Мужчины будут чрезмерно воспринимать женский интерес, потому что репродуктивные издержки сексуального недоверия для мужчин выше, чем для женщин. Аль-Шаваф (2016) заявил, что это не то, что предполагает основная логика теории управления ошибками (EMT). ЕМТ заявляет, что изначальная матрица затрат и выгод как ложноположительных, так и ложноотрицательных ошибок — это то, что движет когнитивными предубеждениями и процессами принятия решений, а не пол, которым он был определен.

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

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

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

Женщины в постменопаузе

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

Альтернативные объяснения

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

Культура

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

Индивидуальные различия

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

Проекция

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

Взаимность

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

Другие примеры

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

Примечания

Дополнительная литература

• Дарвин, Чарльз (1871). Происхождение человека и выбор в отношении пола (2-е изд.). Джон Мюррей. ISBN 978-0-8014-2085-6.
• McKay, R.; Эфферсон, К. (2010). «Тонкости управления ошибками» (PDF). Эволюция и поведение человека. 31(5): 309–319. doi : 10.1016 / j.evolhumbehav.2010.04.005. Архивировано из оригинала 11.06.2016. CS1 maint: BOT: статус исходного URL-адреса неизвестен (ссылка )
• Johnson, DDP; Blumstein, DT; Fowler, JH; Haselton, MG (2013). «Эволюция ошибок: управление ошибками, когнитивные ограничения и предубеждения при принятии адаптивных решений». Trends in Ecology Evolution. 28 (8): 474–481. doi : 10.1016 / j.tree.2013.05.014. PMID 23787087.

Понятие об ошибке – одно из фундаментальных
понятий Управления Ресурсами Экипажа
(СRМ).

Полностью исключить ошибки из деятельности
человека невозможно. Ошибки – стиль
жизни. Мы изучаем реальность методом
«проб и ошибок», воспринимаем ее не
объективно, под влиянием чувств,
настроений, состояния. 2 тысячи лет назад
Цицерон сказал: «Человеку свойственно
ошибаться».

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

• предупреждать;

• обнаруживать;

• исправлять
  ошибки.

Американский ученый Джеймс Ризон считает
ошибками случаи, когда плановая умственная
или физическая деятельность, не достигает
результата. Ошибка– «незапланированное
действие». Мы или делаем то, что не должны
(ошибка исполнения), или не делаем то,
что должны сделать (пропуски). В любом
случае, результат не соответствует
намерениям.

4.8.1 Теория и модель ошибок человека

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

Основные
категории ошибок:

• Латентные
  — (скрытые) ошибки (условия или события
  в прошлом, например, ошибки в конструкции
  ВС).

• Активные
  – непосредственные ошибки или
  действия, ставшие причиной ошибок
  (пусковые события).

Активные ошибки подразделяют на
3 вида – ошибки, связанные:

• с
  навыками;

• правилами;

• знаниями.

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

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

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

Ошибки, связанные с навыками.

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

Навык формируется многократным
повторением. Осознанное исполнение
повышает качество обучения.

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

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

Ошибки, связанные с правилами.

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

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

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

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

Ошибки, связанные со знаниями

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

Ошибки, основанные на знаниях, связаны
с неполными или неверными знаниями, или
неверной интерпретацией ситуации.

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

Концепция «цепи ошибок»

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

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

Если «разорвать» любое звено цепи, то
ее развитие прекратится и ситуация
нормализуется. «Разрывают» цепь с
помощью системных инструментов:

• Стандартных Процедур (СП);

• Карт Контрольных Проверок (ККП);

• Правил CRMи т.д.

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

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

• упущения– неумышленные действия
  по причине провалов памяти, когда
  забываются

собственные намерения, возникает
дезориентация или не выполняются
запланированные

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

• заблуждения– преднамеренные
  действия, вызванные плохим планированием,
  а не

умышленным решением нарушить
установленные правила или процедуры
(например,

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

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

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

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

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

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

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

Ошибки, ориентированные на
эксплуатационные условия:

• процедурная
  ошибка— непреднамеренная ошибка,
  которая может проявляться в виде

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

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

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

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

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

• преднамеренное несоблюдение—
  намеренное отклонение от авиационных
  правил и/или эксплуатационных процедур
  авиакомпании. Если экипаж испытывает
  повышен- ную рабочую нагрузку или
  совершает ошибку только один раз,
  это, скорее всего, будет процедурной
  ошибкой. Однако если экипаж совершает
  одну и ту же ошибку неоднократно, или,
  если ошибка вызвана халатностью, тогда
  это преднамеренное несоблю- дение (т.е.
  нарушение).

Условия, способствующие совершению
ошибок

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

Например:

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

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

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

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

Условия, способствующие совершению
нарушений

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

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

• давление со стороны руководства
  авиакомпании (например, «Если ты не
  можешь делать это, то я найму кого-нибудь,
  кто сможет»);

• давление, инициируемое внутри самого
  себя и со стороны коллег (например,
  «Прежний командир воздушного судна
  хорошо справлялся с этим, и я смогу»);

• конфликт между командиром ВС и
  руководством авиакомпании;

• ненадлежащие надзор и контроль;

• не отвечающие требованиям нормы
  (например, применение опасной практики
  коллегами по работе);

• ошибочное восприятие риска;

• безразличие, проявляемое руководством
  (например, молчаливое согласие с тем,
  что

отклонения от правил приемлемы);

• вера в то, что «авиационное происшествие
  не может случиться со мной»;

• нечеткие или бессмысленные правила;

• культура поведения «все могу»,
  требующая отклонений от правил.

4.8.2 Обратимые
и необратимые ошибки

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

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

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

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

Дж. Ризон классифицирует ошибки по
«намерениям»:

• Предшествовало ли намерение действию?

• Выполнялись ли действия по плану?

• Достигли ли они результата?

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

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

Ошибочные намерения–
специфический тип ошибок, когда человек
что-либо делает, полагая, что действия
правильные, а фактически – это не так.
Например, выключает не тот двигатель.

Нарушения.

К 4-му типу можно отнести ошибки,
традиционно, называемые нарушениями.
С точки зрения системы нарушения —
результат ошибок профотбора, обучения,
оценки персонала, качества разработки
и внедрения процедур или других системных
недостатков. Нарушения могут быть
следствием стремления лучше выполнить
работу или некомпетентности и лени.

Различают три типа нарушений:

• Привычные;

• Ситуативные;

• Оптимизирующие.

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

сэкономить время.

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

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

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

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

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

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

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

• ошибки носят ненамеренный характер –
  никто не планирует ошибаться.

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

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

Управление ошибками на уровне
экипажа

Заметить ошибку другого человека проще,
чем свою собственную.

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

● Коммуникации,

● Правила радиообмена с диспетчером
ОВД,

● Стандартные команды и доклады,

● Стандартные процедуры,

● Перекрестный контроль,

● Брифинг,

● Применение Карт Контрольных Проверок.

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

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

Особую опасность
представляют ошибочные действия экипажа
при компенсировании уже допущенной
ошибки. Это может привести к трагическому
финалу.

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

Безопасность
полетов это общая и абсолютная ценность
авиации. Главная обязанность всего
персонала развить и поддерживать на
высоком уровне культуру безопасности
в авиакомпании.

Возможности
управления ошибками

а)
Избегание ошибок.

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

б)
Защита от
ошибок.

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

в)
Уменьшение
последствий ошибки (компенсация).

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

Соседние файлы в папке приборы + электрообор

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

  12.01.20186.26 Mб379Силовые установки ВС. Учебное пособие.pdf

В таком случае, как менеджер тестов, что вы будете делать?

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

Для разрешения конфликта, вы (менеджер проекта) берете на себя роль судьи, который решает, является ли проблема продукта дефектом или нет.

Категории ошибок

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

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

Высокий – дефект негативно влияет на основные функции продукта
Например: производительность сайта слишком низкая.

Средний – дефект вносит минимальные отклонения от требований к к продукту
Например: не корректно отображается интерфейс на мобильных устройствах.

Низкий – минимальное не функциональное влияние на продукт
Например: некоторые ссылки не работают.

Решение

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

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

Верификация

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

Закрытие

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

Составление отчетов

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

Как измерить и оценить качество выполнения теста?

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

В приведенном выше сценарии можно рассчитать коэффициент отклонения брака (DRR), равный 20/84 = 0,238 (23,8%).

Другой пример: предположительно, в продукте всего 64 дефекта, но ваша группа по тестированию обнаружила только 44 дефекта, т.е. они пропустили 20 дефектов. Следовательно, можно рассчитать коэффициент утечки дефектов (DLR), равный 20/64 = 0,312 (31,2%).

Вывод, качество выполнения теста оценивается по следующим двум параметрам.

Defect reject ratio (DRR) – 23,8%
Defect leakage ratio (DLR) – 31,2%

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

В рассматриваемом нами проекте рекомендуемое значение показателей качества тестирования должно составлять 5 ~ 10%. Это означает, что качество выполнения теста низкое.

Чтобы уменьшить эти коэффициенты:

• Улучшите навыки тестирования участников проекта.
• Тратьте больше времени на выполнение тестов и на просмотр результатов.