Три типа процессов корректирующих ошибку

Бытует
мнение, что первая программная ошибка
была обнаружена на заре развития ЭВМ,
когда в Массачусетском технологическом
институте окончилась неудачей попытка
запуска машины Whirlwind I («Вихрь I»). Неистовая
проверка монтажа, соединений и оборудования
не выявила никаких неисправностей.
Наконец, уже отчаявшись, решили проверить
программу, представляющую собой маленькую
полоску бумажной ленты. И ошибка была
обнаружена именно в ней – в этом
программистском ящике Пандоры, из
которого на будущие поколения программистов
обрушились беды, связанные с ошибками
программ.

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

Далее
будет дана классификация ошибок, что
поможет сосредото-

чить
наши усилия в правильном направлении.

5.3.1
Классификация дефектов

Для
классификации ошибок мы должны определить
термин «ошибка».

Ошибка
– это расхождение между вычисленным,
наблюдаемым и ис-

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

Такое
определение понятия «ошибка» не является
универсальным,

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

Итак,
по
времени появления
ошибки можно разделить на три вида:

• структурные
ошибки набора;

• ошибки
компиляции;

• ошибки
периода выполнения.

Структурные
ошибки возникают непосредственно при
наборе про-

граммы.
Что это за ошибки? Если кто-то работал
в среде разработки Microsoft Visual Basic, то он
знает, что если набрать оператор If, затем
сравнение и нажать на клавишу Enter, не
набрав слова Then, то Visual Basic укажет, что
возникла ошибка компиляции. Это не
совсем верно, так как компиляция в Visual
Basic происходит только непосредственно
при выполнении команды программы. В
данном случае мы имеем дело именно со
структурной ошибкой набора.

Данный
тип ошибок определяется либо при наборе
программы (са-

мой
IDE
(Integrated
Development
Environment)
– интегрированной средой разработки)
или при ее компиляции, если среда не
разделяет первые два типа ошибок.

К
данному типу ошибок относятся такие
как: несоответствие числа

открывающих
скобок числу закрывающих, отсутствие
парного оператора

(например,
try без catch), неправильное употребление
синтаксических

знаков
и т. п.

Во
многих средах разработки программного
обеспечения данный

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

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

Ошибки
компиляции возникают из-за ошибок в
тексте кода. Они

включают
ошибки в синтаксисе, неверное использование
конструкций

языка
(оператор else в операторе for и т. п.),
использование несущест-

вующих
объектов или свойств, методов у объектов.

Среда
разработки (компилятор) обнаружит эти
ошибки при общей

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

Ошибки
периода выполнения возникают, когда
программа выпол-

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

ratio
= firstValue / sum.

Если
переменная sum содержит ноль, то деление
– недопустимая

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

Хотя
данный тип ошибок называется «ошибками
периода выполне-

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

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

В
теоретической информатике программные
ошибки классифицируют по
степени нарушения логики
на:

•
синтаксические;

•
семантические;

•
прагматические.

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

•
пропуск необходимого знака пунктуации;

•
несогласованность скобок;

•
пропуск нужных скобок;

•
неверное написание зарезервированных
слов;

•
отсутствие описания массива.

Все
ошибки данного типа обнаруживаются
компилятором.

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

GregorianCalendar.add(1,
Calendar.MONTH).

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

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

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

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

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

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

Ошибка
ввода-вывода
– ошибка, возникающая в процессе обмена

данными
между устройствами памяти, внешними
устройствами.

Ошибка
вычисления
– ошибка, возникающая при выполнении

арифметических
операций (например, разнотипные данные,
деление на нуль и др.).

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

Ошибка
обращения к данным
– ошибка, возникающая при обра-

щении
программы к данным (например, выход
индекса за пределы массива, не
инициализированные значения переменных
и др.).

Ошибка
описания данных
– ошибка, допущенная в ходе описания

данных.

Первичное
выявление ошибок

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

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

Описанные
здесь методы предназначены для периода
разработки, когда программа закодирована,
но тестирование на ЭВМ еще не началось.
Аналогичные методы могут быть получены
и применены на более ранних этапах
процесса создания программ (т. е. в конце
каждого этапа проектирования).

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

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

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

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

5.3.2
Инспекции и сквозные просмотры

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

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

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

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

определяются
поодиночке.

Ранее,
более двух десятков лет, проводились
широкие эксперименты по применению
этих методов, которые показали, что с
их помощью для типичных программ можно
находить от 30 до 70 % ошибок логического
проектирования и кодирования. (Однако
эти методы не эффективны при определении
ошибок проектирования «высокого уровня»,
например, сделанных в процессе анализа
требований.) Так, было экспериментально
установлено, что при проведении инспекций
и сквозных просмотров определяются в
среднем 38 % общего числа ошибок в учебных
программах.

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

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

Кроме
того, можно было бы утверждать, что
ручное тестирование «морально устарело»,
но если обратить внимание на список
типовых ошибок, то они до сих пор остались
прежними и увеличит ли скорость
тестирования ЭВМ не всегда очевидно.
Но то, что эти методы стали совсем
непопулярными это факт. Бесспорно, что
каждый метод хорош для своих типов
ошибок и сочетание методов ручного
тестирования и тестирования с применением
ЭВМ для конкретной команды разработчиков
представляется наиболее эффективным
подходом; эффективность обнаружения
ошибок уменьшится, если тот или иной из
этих подходов не будет использован.

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

Инспекции
исходного текста

Инспекции
исходного текста представляют собой
набор процедур и

приемов
обнаружения ошибок при изучении (чтении)
текста группой

специалистов
. При рассмотрении инспекций исходного
текста вни-

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

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

Общая
процедура заключается в следующем.
Председатель заранее

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

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

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

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

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

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

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

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

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

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

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

Сквозные
просмотры

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

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

Относительно
пятого участника имеются следующие

предположения:

1)
высококвалифицированный программист;

2)
эксперт по языку программирования;

3)
начинающий (на точку зрения которого

не
влияет предыдущий опыт);

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

5)
участник какого-нибудь другого проекта;

6)
кто-либо из той же группы программистов,
что и автор программы.

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

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

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

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

5.3.3
Проверка за столом

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

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

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

Список
вопросов для выявления ошибок при
инспекции:

Важной
частью процесса инспектирования является
проверка программы на наличие общих
ошибок с помощью списка вопросов для
выявления ошибок. Концентрация внимания
в предлагаемом списке на рассмотрении
стиля, а не ошибок (вопросы типа «Являются
ли комментарии точными и информативными?»
и «Располагаются ли символы THEN/ELSE и
DO/END по одной вертикали друг под другом?»)
представляется неудачной, так же как и
наличие неопре-

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

Ошибки
обращения к данным

Сводный
список вопросов таков:

1.
Используются ли переменные с
неустановленными значениями?

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

2.
Лежат ли индексы вне заданных границ?

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

3.
Есть ли нецелые индексы?

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

4.
Есть ли «подвешенные» обращения?

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

Этот
тип ошибок характерен для языка Си или
С++, где широко используются ссылки и
указатели. Язык Java в этом отношении
более развит, например, при потере всех
ссылок на объект, объект переходит в
«кучу мусора», где автоматически
освобождается память из-под объекта
(объект удаляется) специальным сборщиком
мусора. Последние изменения в языке
С++, выполненные командой разработчиков
Microsoft, которые преобразовали этот язык
в С#, реализуют похожий механизм.

5.
Соответствуют ли друг другу определения
структуры и ее использование в различных
методах?

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

6.
Превышены ли границы строки?

Не
превышены ли границы строки при индексации
в ней? Существуют ли какие-нибудь другие
ошибки в операциях с индексацией или
при обращении к массивам по индексу?

Ошибки
описания данных

Сводный
список вопросов таков:

1.
Все ли переменные описаны?

Все
ли переменные описаны явно?

Отсутствие
явного описания не обязательно является
ошибкой (например, Visual Basic допускает
отсутствие описания), но служит
потенциальным источником беспокойства.
Так, если в подпрограмме на Visual Basic
используется элемент массива и отсутствует
его описание (например, в операторе
DIM), то обращение к массиву может вызвать
ошибку (например, Х = А(12)), так как по
умолчанию, массив определен только на
10 элементов.

Если
отсутствует явное описание переменной
во внутренней процедуре или блоке,
следует ли понимать это так, что описание
данной переменной совпадает с описанием
во внешнем блоке?

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

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

1. Понятны
   ли имена переменных?

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

1. Нельзя
   ли обойтись без переменных со сходными
   именами?

Есть
ли переменные со сходными именами
(например, user и users)?

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

нибудь
внутри программы.

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

Ошибки
вычислений

Сводный
список вопросов таков:

1.
Производятся ли вычисления с использованием
данных разного типа? Существуют ли
вычисления, использующие данные разного
типа?

Например,
сложение переменной с плавающей точкой
и целой

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

того,
что правила преобразования, принятые
в языке, понятны. Это

важно
как для языков с сильной типизацией
(например, Ada, Java),

так
и для языков со слабой типизацией
(например, С++, хотя он тяготеет к сильной
типизации).

Например,
для языка Java код

byte
a,
b,
c;

…

c
= a
+ b;

может
вызвать ошибку, так как операция
«сложение» преобразует

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

2.
Производятся ли вычисления неарифметических
переменных?

3.
Возможно ли переполнение или потеря
промежуточного результата при вычислении?

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

4.
Есть ли деление на ноль?

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

5.
Существуют ли неточности при работе с
двоичными числами?

6.
Не выходит ли значение переменной за
пределы установленного диапазона? Может
ли значение переменной выходить за
пределы установленного для нее логического
диапазона?

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

7.
Правильно ли осуществляется деление
целых чисел? Встречается ли неверное
использование целой арифметики, особенно
деления? Например, если i – целая величина,
то выражение 2*i/2 = i зависит от того,
является значение i четным или нечетным,
и от того, какое действие – умножение
или деление выполняется первым.

Ошибки
при сравнениях

Сводный
список вопросов таков:

1.
Сравниваются ли величины несовместимых
типов? Например, число со строкой?

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

3.
Корректны ли отношения сравнения?
Иногда возникает путаница понятий
«наибольший», «наименьший», «больше
чем», «меньше чем».

4.
Корректны ли булевские выражения? Если
выражения очень сложные, имеет смысл
преобразовать их или проверять обратное
утверждение.

5.
Понятен ли порядок следования операторов?
Верны ли предположения о порядке оценки
и следовании операторов для выражений,
содержащих более одного булевского
оператора? Иными словами, если задано
выражение (А == 2) && (В == 2) || (С == 3),
понятно ли, какая из операций выполняется
первой: И или ИЛИ?

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

if
((x != 0) && ((y/x) > z))

является
приемлемым для Java (т. е. компилятор
заканчивает проверку, как только одно
из выражений в операции «И» окажется
ложным), но это выражение может привести
к делению на ноль при использовании
компиляторов других языков.

Ошибки
в передачах управления

Сводный
список вопросов таков:

1.
Может ли значение индекса в переключателе
превысить число переходов? Например,
значение переключателя для оператора
select case.

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

3.
Будет ли завершена программа? Будет ли
программа, метод, модуль или подпрограмма
в конечном счете завершена?

4.
Существует ли какой-нибудь цикл, который
не выполняется из-за

входных
условий? Возможно ли, что из-за входных
условий цикл никогда не сможет выполняться?
Если это так, то является ли это
оплошностью?

5.
Есть ли ошибки отклонения числа итераций
от нормы? Существуют ли какие-нибудь
ошибки «отклонения от нормы»

(например,
слишком большое или слишком малое число
итераций)?

Ошибки
интерфейса

Сводный
список вопросов таков:

1.
Равно ли число входных параметров
числу аргументов?

Равно
ли число параметров, получаемых
рассматриваемым методом, числу аргументов,
ему передаваемых каждым вызывающим

методом?
Правилен ли порядок их следования?

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

2.
Соответствуют ли единицы измерения
параметров и аргументов?

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

3.
Не изменяет ли метод аргументы,
являющиеся только входными?

4.
Согласуются ли определения глобальных
переменных во всех использующих их
методах?

Ошибки
ввода-вывода

Сводный
список вопросов таков:

1.
Правильны ли атрибуты файлов? Не
происходит ли запись в файлы read-only?

2.
Соответствует ли формат спецификации
операторам ввода-вывода? Не читаются
ли строки вместо байт?

3.
Соответствует ли размер буфера размеру
записи?

4.
Открыты ли файлы перед их использованием?

5.
Обнаруживаются ли признаки конца
файла?

6.
Обнаруживаются ли ошибки ввода-вывода?
Правильно ли трактуются ошибочные
состояния ввода-вывода?

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

26.1.3. Аудит процессов разработки и верификации

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

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

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

В отличие от процесса верификации, который проверяет качество разрабатываемой программной системы, аудит в составе процесса управления качеством направлен на проверку технологических процессов — как разработки, так и верификации. Так, верификация отвечает на вопрос «разработана ли программная система в соответствии с требованиями?», а аудит менеджмента качества отвечает на вопрос «соответствовали ли процессы разработки и верификации установленным нормам и схемам технологических процессов, определенных в стандартах проекта и/или предприятия?».

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

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

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

26.1.4. Корректирующие действия и коррекция процессов

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

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

Как правило, для решения выявленных и классифицированных проблем применяются три типа мероприятий: коррекция, корректирующее действие и предупреждающее действие. Термин «коррекция» имеет отношение к ремонту, переделке или регулировке и относится к устранению имеющегося несоответствия. Термин «корректирующее действие» относится к устранению причины несоответствия.

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

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

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

26.2. Конфигурационное управление

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

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

Применение процесса конфигурационного управления является основным требованием при разработке систем, к их надежности (т.е., согласно ГОСТ 13377-75 [22] — свойству объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования), к которым предъявляются повышенные требования, в частности, при разработке бортовых авиационных систем, информационных систем большого масштаба, систем безопасности (см., например, DO-178B [7]).

Основные задачи и цели процессов конфигурационного управления (КУ) состоят в следующем [16].

• Идентификация: присвоение уникальных имен объектам конфигурационного управления (ОКУ). Каждый объект в конфигурации должен отличаться от всех других объектов. Данное требование не может быть удовлетворено созданием поисковых образов объектов (поиск документов по внутреннему содержимому), т.к. одно из применений идентификации — обеспечение трассируемости объектов. При помощи трасс между документами создаются логические ссылки, позволяющие проследить зависимости между различными группами проектной документации, покрытия требований и т.п.
• Управление: управление выпуском продукта и его изменениями в течение всего жизненного цикла. В данный набор целей входит предоставление информации, которая необходима руководству для контроля изменений в данных, относящихся к выпускаемому продукту.
• Вычисление статусов: хранение и создание отчетов по состояниям объектов конфигурационного управления и запросов на изменение. Кроме вычисления статусов в виде отчетов, подобных индексам конфигурации, функция вычисления статусов должна позволять вычислять статус отдельно взятого ОКУ и определять жизненные циклы, являющиеся совокупностью статусов и правил их изменения.
• Аудит и инспекции: проверка завершенности и полноты продукта и поддержание целостности и непротиворечивости связей всех его компонент. Процесс КУ может регламентировать как процедуры проведения аудитов и их фазы, так и исключительно точки жизненного цикла, в которых проводятся аудиты конфигурации.
• Выпуск: управление сборкой и построением окончательной версии продукта. В данном процессе обычно используются индексы конфигураций, в которых перечисляются ОКУ, необходимые в процессе сборки версии для той или иной целевой платформы.
• Управление процессом: проверка соблюдения организацией правил проведения процедур и модели жизненного цикла. Управление осуществляется в виде постоянного контроля за процедурами либо в рабочем порядке, либо в виде регулярных аудитов и позволяет удостовериться в технологичности процессов разработки, что в конечном итоге положительно сказывается на качестве продукции.
• Коллективная работа: управление работой и взаимодействием между множеством пользователей, работающих над продуктом, в том числе управление проектом и распределение задач между исполнителями. Также в процессе обеспечения коллективной работы должен проводиться контроль выполнения разработчиками поставленных перед ними задач путем отслеживания статуса документа.

Рассмотрим процесс конфигурационного управления в рамках документа DO-178B (Software Considerations in Airborne Systems and Equipment Certification), определяющего требования к процессам разработки авиационного бортового программного обеспечения. Требования этого стандарта к процессу конфигурационного управления являются достаточно жесткими и в целом сопоставимы с требованиями других стандартов (ISO 10007 [23], IEEE 1042 [24]).

В стандарте DO-178B определяются шесть основных процессов программного проекта, из которых три можно отнести к производственным: планирование, разработка и верификация, а три к поддерживающим: обеспечение качества, взаимодействие с сертифицирующим органом и конфигурационное управление. Производственным процессам посвящены соответственно главы 4, 5 и 6.

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

Корректирующие действия

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

Сначала рассмотрим определения терминов, которые даны в  стандарте ИСО 9000:2015.

• Несоответствие – невыполнение требования.
• Коррекция — действие, предпринятое для устранения обнаруженного несоответствия.
• Корректирующее действие — действие, предпринятое для устранения причины несоответствия и предупреждения его повторного возникновения.

Принципиальное отличие коррекции от корректирующих действий состоит следующем:

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

Пункт 10.2 стандарта ИСО 9001 «Несоответствия и корректирующие действия» требует:

10.2.1 При появлении несоответствий, в том числе связанных с претензиями, организация должна:

a) реагировать на данное несоответствие и насколько применимо:

1) предпринимать действия по управлению и коррекции выявленного несоответствия;

2) предпринимать действия в отношении последствий данного несоответствия (это тоже часть мер коррекции);

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

1) анализа несоответствия;

2) определения причин, вызвавших появление несоответствия;

3) определения наличия аналогичного несоответствия или возможности его возникновения где-либо еще;

c) выполнять все необходимые действия;

d) проанализировать результативность каждого предпринятого корректирующего действия;

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

f) вносить при необходимости изменения в систему менеджмента качества.

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

10.2.2 Организация должна регистрировать и сохранять документированную информацию как свидетельство:

a) характера выявленных несоответствий и последующих предпринятых действий;

b) результатов всех корректирующих действий.

Рассмотрим выполнение требований данного пункта на простом примере.

«При проведении внутреннего аудита системы менеджмента качества в производственном подразделении аудитор обратил внимание на воду, разлитую на полу. Поиск источника протечки привел к батарее системы отопления, из которой капала вода. Аудитор оформил несоответствие по пункту 7.1.3 ИСО 9001, в котором указал, что элемент инфраструктуры – батарея системы отопления — не  поддерживается в должном состоянии»

Требование 10.2.1.а.1 можно выполнить путем «ремонта батареи системы отопления  и устранения протечки воды».

Требование 10.2.1.а.2 выполняется путем «уборки воды с пола».

Это была коррекция.

Теперь нужно разработать и выполнить корректирующие действия. Для этого нужно провести анализ несоответствия (10.2.1.b.1). В ходе данного анализа нужно выявить и рассмотреть факторы, которые могли привести к несоответствию. Это могли быть внешние или внутренние факторы.

Для определения внешних факторов в англоязычной литературе рекомендуют применять  «PESTLE –анализ»:

• Political (англ.) – политические факторы,
• Economical – экономические,
• Social – социальные,
• Technological – технологические,
• Legal – юридические,
• Environmental – экологические.

Для определения внутренних факторов рекомендуется использовать «7М – анализ»:

• Man — человек.
• Machine — оборудование (производственное и вспомогательное).
• Material — материал.
• Method – технология.
• Measurement  —  измерение.
• Management — управление. 
• Milieu (фр.) – условия.

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

Согласно требованию 10.2.1.b.2 нужно определить причины несоответствия. Причин может быть несколько. Они могут воздействовать на объект (батарею системы отопления) параллельно или последовательно.

Причины, которые действуют параллельно и могут привести к несоответствию за счет суммарного (синергетического) эффекта:

• Отсутствие контроля за состоянием системы отопления (факторы – Управление или Измерение),
• Недобросовестная работа при выполнении предыдущего ремонта системы отопления (фактор — Человек).
• Использование некачественных материалов при выполнении предыдущего ремонта (фактор — Материалы).
• …….

Для определения корневых причин несоответствия принято использовать метод «5 Почему». В ходе применения данного метода определяют цепочку последовательных причин (причинно-следственных связей):

1. Почему батарея протекает? – Никто не следит за ее состоянием (фактор – Измерение).
2. Почему никто не следит за состоянием батарей системы отопления? – В компании отсутствует подразделение, ответственное за обслуживание системы отопления (фактор – Управление).
3.  Почему отсутствует подразделение,  ответственное за обслуживание системы отопления? – Процесс обслуживание инженерных систем передан на аутсорсинг. Но в начале года не заключили договоры с подрядными организациями, осуществляющими обслуживание этих систем (фактор – Управление).
4. Почему не заключили договоры с подрядными организациями? —  Недостаток финансовых ресурсов (фактор – Управление).
5. Почему недостаточно финансовых ресурсов? – Экономический кризис…(фактор – Экономика).

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

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

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

Уровень анализа	Событие (причина)	Объект	Действие
5	Экономический кризис	Государство	?
4	Отсутствие финансов	Предприятие	?
3	Отсутствие обслуживания инженерных систем	Инженерные системы	Обслуживание инженерных систем собственными силами
2	Отсутствие обслуживания системы отопления	Система отопления	Обслуживание системы отопления собственными силами
1	Отсутствие контроля состояния батареи отопления	Батарея отопления	Контроль состояния батареи отопления
0 (несоответствие)	Поломка батареи отопления	Батарея отопления	Ремонт батареи
-1 (последствие)	Вода на полу	Вода	Уборка воды

Обратите внимание, что на 4 и 5 уровнях мы ушли в рассмотрение факторов, которые находятся за рамками зоны ответственности владельца  процесса — руководителя инженерной службы. Если причина №4 «Отсутствие финансов» находится в зоне ответственности руководителя предприятия и может быть устранена на высшем уровне управления, то причина №5 «Экономический кризис» находится за пределами предприятия и не может быть устранена вообще.

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

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

В рассмотренном примере рекомендуется остановиться на уровне №2 и в качестве корректирующего действия «поручить контролировать состояние системы отопления назначенным сотрудникам (подразделениям), обучить…, аттестовать… и т.п.».

Чтобы выполнить требование 10.2.1.b.3 нужно «определить наличие аналогичного несоответствия или возможность его возникновения где-либо еще».

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

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

Дальше, согласно  10.2.1.c нужно спланировать и выполнить соответствующие действия (коррекцию и корректирующие действия).

Действия бывают двух  видов: разовые или постоянные.

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

• Действия,
• Сроки их выполнения,
• Ответственные лица.

Постоянные действия отражаются в документированной информации системы менеджмента (см. 10.2.1.f): процедурах, инструкциях, регламентах…

В рассматриваемом примере нужны разовые действия:

• Назначение ответственного персонала
• Обучение и аттестация назначенного персонала.

Также требуются постоянные действия:

• Регулярный осмотр и обслуживание инженерных систем.
• Взаимодействия с ремонтными службами для проведения плановых и внеплановых ремонтов.

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

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

• Был ли в ходе идентификации рисков и возможностей (см. п.6.1.1 ИСО 9001) выявлен и оценен риск выхода из строя батареи отопления?
• Правильно ли были определены характеристики данного риска (вероятность и последствия)? – Показатель вероятности, скорее всего, был занижен.
• Насколько результативными были действия, предпринятые в отношении данного риска (см. п.6.1.2 ИСО 9001)? – Если действия были, то они явно были нерезультативными, поскольку произошла поломка батареи.
• Какие новые риски или возможности появятся при внедрении запланированных действий? —  С большой вероятностью компания столкнется с отсутствием квалифицированного персонала, необходимого для обслуживания инженерных систем.

После того, как все необходимые разовые  действия были спланированы и выполнены, а постоянные действия спланированы, внедрены и продолжают выполняться, необходимо «проанализировать результативность каждого предпринятого корректирующего действия (см. 10.2.1.d)».

Основной критерий результативности корректирующего действия это «отсутствие его повторного появления или появления в другом месте» (см.10.2.1.b). Следовательно, должен пройти определенный промежуток времени, в течение которого нужно убедиться, что несоответствие не повторяется. Чаще всего, в процедуры проверки результативности мер коррекции и корректирующих действий между выявлением несоответствия и проверкой результативности предпринятых действий закладывается промежуток времени от 3 месяцев до 1 года.

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

Вопрос: «Если выявлено несоответствие, то обязательно для него разрабатывать и выполнять коррекцию и корректирующие действия?»

Относительно «коррекции» в п. 10.2.1.a сказано «…..насколько применимо». Можно столкнуться с несоответствием, которое уже невозможно исправить. Например, несоответствие состоит в том, что «результаты измерений температуры в помещении не внесены в журнал». Если результаты  измерений восстановить невозможно, то обычная коррекция в данной ситуации неприменима.

В этом случае в качестве коррекции можно выполнить корректирующее действие 1-го уровня, которое устранит причину, выявленную на первом вопросе «Почему…?». Например, если выявлена причина 1-го уровня «Недостаточная компетентность сотрудника», то типичное корректирующее действие в такой ситуации: «Повести внеплановый инструктаж для сотрудника, не заполнившего журнал». Данное действие нельзя считать полноценным корректирующим действием, поскольку оно не устраняет возможность подобных ошибок со стороны других сотрудников, но  его можно принять в качестве «альтернативной коррекции».

В отношении «корректирующего действия» в п. 10.2.1.b сказано «оценивать необходимость действий…». Если анализ причин несоответствия показал, что вероятность его повторного возникновения пренебрежимо мала, то может быть принято решение, что «нет необходимости в корректирующих действиях». Например, несоответствие состоит в том, что «в Политике в области качества отсутствует обязательство соответствовать применимым требованиям». В данном случае достаточно провести коррекцию – «Отредактировать текст Политики».

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

Согласно требованиям пункта 10.2.2 необходимо оформлять отчетные документы (регистрировать и сохранять документированную информацию) в отношении:

• результатов анализа несоответствий (причины, последствия…),
• планов действий (коррекция и корректирующие действия),
• результатов выполнения действий и оценки их результативности (выполнены/не выполнены, достигли/не достигли результата…)

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

Вопрос: «По каким видам несоответствий должны разрабатываться и выполняться меры коррекции и корректирующие действия?»

В стандарте ИСО 9001:2015 указаны 2 вида несоответствий, по которым нужно разрабатывать и выполнять  коррекцию и корректирующие действия:

• Несоответствия по результатам внутреннего аудита (см. п. 9.2.2.е)

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

• Претензии потребителей (см. п. 10.2.1).

Согласно определению в стандарте ИСО 9000:

Претензия (complaint)  —  Выражение организации неудовлетворенности ее продукцией или услугой, или непосредственно процессом управления претензиями в ситуациях, где явно или неявно ожидается ответ или решение.

В стандарте ИСО 9001:2015 термин «претензия» не является юридическим термином,  а означает любое проявление неудовлетворенности со стороны потребителя в отношении продукции или услуги организации.

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

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

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

В предыдущей редакции стандарта ИСО 9001:2008 был указан еще один обязательный источник коррекции и корректирующих действий:

• Несоответствия по результатам мониторинга результативности процессов.

В действующей редакции стандарта ИСО 9001:2015  формулировка требования изменена (см. 4.4.1. g): «оценивать эти процессы и вносить любые изменения, необходимые для обеспечения того, что процессы достигают намеченных результатов». Такие «изменения» можно рассматривать как разновидность коррекции и корректирующих действий.

В стандарте ИСО 14001:2015 нет прямых указаний, по каким несоответствиям нужно разрабатывать и применять коррекцию и корректирующие действия.

В Руководстве по применению стандарта (Приложение А) необходимость корректирующих действий упоминается в отношении:

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

В стандарте ИСО 45001:2018 требуется проводить коррекцию и корректирующие действия по результатам несоответствий, а также по результатам «инцидентов».

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

Вопрос: «Как во время проведения внутреннего аудита правильно сформулировать несоответствие, чтобы направить проверяемого на планирование и выполнение адекватных меры коррекции и корректирующих действий?»

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

В рассмотренном примере аудитор №1 акцентировал внимание на батарее системы отопления.

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

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

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

Далее для проверки результативности корректирующих действий в подразделение пришел аудитор №3, который не принял предложенные действия, посчитав их коррекцией.

Формально, аудитор №3 прав. Аудитор №2 в формулировке несоответствия перенес объект несоответствия на два уровня причинно-следственной цепочки с «батареи отопления» на «систему отопления». Теперь любые действия  в отношении «системы отопления» нужно рассматривать как коррекцию, а корректирующие действия нужно планировать на следующих уровнях: на уровне  «инженерных систем»  или на уровне  «предприятия».

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

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

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

Система менеджмента качества

ПРЕДИСЛОВИЕ

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

Стандарт разработан службой БУСК;

При его разработке учтены требования ISO/TS 16949 раздел 8.5 «Улучшение».

СОДЕРЖАНИЕ

Предисловие

• Область применения
• Нормативные ссылки
• Определения
• Обозначения и сокращения
• Общие положения
• Корректирующие действия
• Предупреждающие действия.
• Постоянное улучшение
• Уровни принятия корректирующих, предупреждающих действий и действий по постоянному улучшению
• Организация корректирующих и предупреждающих действий в производстве
• Анализ причин появления несоответствий
• Разработка и проведение корректирующих и предупреждающих действий
• Оценка результативности корректирующих и предупреждающих действий
• ПРИЛОЖЕНИЕ А (рекомендуемое) Схема обеспечения рабочего места
• ПРИЛОЖЕНИЕ 5 (рекомендуемое) Форма плана корректирующих -предупреждающих действий

1 Область применения

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

1.2 Стандарт распространяется на все подразделения, входящие в сферу действия СМК.

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

2 Нормативные ссылки

При разработке данного стандарта учтены требования и рекомендации следующей нормативной документации:

• Системы Менеджмента качества. Особые требования по применению стандарта ISO 90012008 8 автомобилестроении и организациях, поставляющих соответствующие запасные части.
• Системы менеджмента качества. Основные положения и словарь, Инструкция. Система менеджмента качества. Ответственность руководства. Анализ СМК со стороны руководства.
• Инструкция. Система Менеджмента качества. Ответственность руководства. Анализ СМК со стороны Руководства.
• Стандарт предприятия. Система качества. Планирование качества.
• Стандарт предприятия. Система качества. Управление разработкой технологических процессов
• Стандарт предприятия. Система менеджмента качества. Управление документацией и данными. Основные положения.
• Стандарт предприятия. Система качества. Управление конструкторской документацией
• Стандарт предприятия. Система качества. Управление технологической документацией.
• Стандарт предприятия. Система качества. Порядок приема закупленной продукции на склады предприятия, проведение ее входного контроля, хранения и выдачи в производство
• Стандарт предприятия. Система менеджмента качества. Организация эксплуатации планово-предупредительного обслуживания и ремонта оборудования.
• Стандарт предприятия. Система менеджмента качества. Организация эксплуатации планово-предупредительного обслуживания и ремонта электро – энергетического оборудования
• Стандарт предприятия. Система качества. Обеспечение производства технологической- оснасткой, средствами измерения.
• Стандарт предприятия. Система качества. Организация контроля технологической дисциплины на производстве.
• Стандарт предприятия. Система менеджмента качества. Контроль и проведение испытаний. Основные положения.
• Стандарт предприятия. Система качества. Периодические и типовые испытания изделий и их составных частей.
• Организация проведения, оценка результатов. Стандарт предприятия. Система качества. Управление контрольным, измерительным и испытательным оборудованием. Основные положения.
• Стандарт предприятия. Система менеджмента качества. Управление несоответствующей продукцией. Основные положения.
• Положение о комиссии по принятию решений.
• Инструкция. Проведение погрузочно-разгрузочных и транспортировочных работ.
• Стандарт предприятия. Система менеджмента качества. Внутренние аудиты. Основные положения.
• Стандарт предприятия. Система качества. Подготовка кадров. Основные положения.
• Стандарт предприятия. Система менеджмента качества. Техническое обслуживание. Основные положения.
• Стандарт предприятия. Система качества. Статистические методы. Основные положения.

3 Определения

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

• Корректирующее действие — действие, предпринятое для устранения причины обнаруженного несоответствия или другой нежелательной ситуации.
• Предупреждающее действие — действие, предпринятое для устранения причины потенциального несоответствия или другой потенциально нежелательной ситуации.
• Постоянное улучшение — повторяющаяся деятельность по увеличению способности выполнить требования.
• Несоответствие — невыполнение требования.
• Требование — потребность или ожидание, которое установлено, обычно предполагается или является обязательным.
• Результативность — степень реализации запланированной деятельности и достижения запланированных результатов.
• Эффективность — Связь между достигнутым результатом и использованными ресурсами.
• Производственные факторы (ресурсы) — к ним могут относиться: сырье, материал, заготовки, КИ, оборудование, оснастка, инструмент, приспособления, персонал, документация, средства контроля и испытаний, программное обеспечение.

4 Обозначения и сокращения

• БУСК — бюро управления системой качества
• ДИ — должностная инструкция
• КД — конструкторская документация
• КИ — комплектующие изделия
• НД — нормативная документация
• ОТК — отдел технического контроля
• РИ — рабочая инструкция
• СИ — средства измерения
• СМК — система менеджмента качества
• СТП — стандарт предприятия
• СТО — средства технологического оснащения
• ТД — технологическая документация
• ТБ — технологическое бюро
• ТЗ — техническое задание
• ТИ — технологическая инструкция
• ТП — технологический процесс
• ТИ — техническая инструкция
• ТБ — технологическое бюро

5 Общие положения

5.1 Корректирующие действия

5.1.1 Цель применения корректирующих действий – устранение причин произошедших несоответствий для предупреждения повторного их возникновения.

5.1.2 Корректирующие действия проводятся во всех процессах СМК (включая управляющие процессы, основные и обеспечивающие процессы) при обнаружении несоответствий.

Ответственность за применение корректирующих действий несут руководители процессов, подразделений.

5.1.3 Источниками информации о несоответствиях для определения корректирующих действий являются:

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

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

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

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

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

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

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

5.1.7 Анализ результативности предпринятых корректирующих действий проводится в последующие периоды времени сравнением достигнутых показателей с показателями предыдущих периодов.

5.2 Предупреждающие действия

5.2.1 Цель применения предупреждающих действий – устранение причин потенциально возможных несоответствий и предотвращения нежелательных ситуаций.

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

Ответственность за применение предупреждающих действии несут руководители процессов, подразделений.

5.2.3 Уменьшение потерь в организации через применение предупреждающих действий необходимо планировать.

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

5.2.4 Входные данные для определения потенциально возможных несоответствий могут быть получены посредством:

• использования инструментов (средств, методов) анализа рисков (например, таких, как анализ характера и последствий отказа — РМЕА);
• анализа потребностей и ожиданий потребителей, анализа рынка;
• измерения удовлетворенности заинтересованных сторон;
• оценка тенденций изменения процессов;
• результатов самооценки.

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

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

5.3 Постоянное улучшение

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

Деятельность по постоянному улучшению снижает вероятность возникновения несоответствий и минимизирует потери.

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

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

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

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

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

Этого можно добиться посредством такой деятельности, как:

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

5.4 Уровни принятия корректирующих, предупреждающих действий и действий по постоянному улучшению

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

1) Оперативные мероприятия заводского уровня:

• совещания директоров по направлениям (Матрица совещаний).

2) Перспективные мероприятия заводского уровня:

• план технического перевооружения;
• план качества.

3) Оперативные совещания в подразделениях:

• дни качества в подразделениях;
• рабочие совещания (Матрица совещаний).

4) Плановая работа по обеспечению постоянного соответствия продукции, процессов и СМК требованиям КД, ТД, НД СМК.

6 Организация корректирующих и предупреждающих действий в производстве

6.1 Несоответствия в продукции, процессах, СМК выявляются и регистрируются в процессе ежедневного и периодического надзора за производственными факторами со стороны производственного персонала, технологов и ОТК цеха.

6.2 Несоответствия в продукции, процессах и СМК могут быть выявлены:

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

6.3 При обнаружении несоответствия в продукции, процессе, СМК лицо, обнаружившее несоответствие, оперативно доводит информацию до руководителя и регистрирует несоответствие в Журнале решения проблем, или в Журнале повседневного надзора.

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

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

6.5 Если причина возникновения несоответствия:

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

6.6 В противном случае — если:

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

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

6.7 Мастер, бригадир, технолог фиксирует в Журнале повседневного надзора, Журнале Решения проблем причины возникновения несоответствия, разработанные корректирующие и предупреждающие действия, исполнителей и сроки выполнения.

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

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

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

7 Анализ причин появления несоответствий

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

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

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

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

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

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

7.4 При проведении анализа возможного влияния производственных факторов на возникновение несоответствий оценивается:

• состояние исходного сырья, материала и КИ – проверяются сопроводительная документация с отметкой о результатах входного контроля, условия хранения, подготовка перед применением в производстве;
• соответствие НД на предмет наличия последних изменений КД и ТД, влияние изменений на качество, знание исполнителем внесенных в НД изменений, а также четкости технологических инструкций;
• соблюдение требований технологической дисциплины;
• наличие, достаточность, и исправность СТО (износ, ремонт или замена оснастки, инструмента, периодичность поверки);
• состояние оборудования — в части простоев технологического оборудования, оказывающее дестабилизирующее влияние на качество продукции — следует проанализировать наличие и причину простоев, выполнение графика планово-предупредительного и профилактического обслуживания и ремонта оборудования;
• соблюдение параметров ТП, в первую очередь, Критических;
• наличие тары и совершенство способов транспортировки;
• текучесть кадров на рабочем месте;
• знание исполнителем требований технологии, рабочей инструкции, достаточность квалификации исполнителя;
• полнота рабочих инструкций;
• полнота и соблюдение требований документов СМК;
• соблюдение требований промышленной безопасности и состояния окружающей среды (температура воздуха, уровень шума, запыленность, и т.д.).

7.5 Анализ рекомендуется проводить используя методику 8-Д с применением диаграммы Исикавы.

Результатом проведенного анализа должно быть:

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

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

Срок, в который должен быть проведен анализ не более 3-х дней.

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

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

При этом в Журналах «Решение проблем» и «Повседневного надзора» в соответствующих графах дается ссылка на данный протокол.

8 Разработка и проведение корректирующих и предупреждающих действий

8.1 Целью разработки мероприятий по устранению несоответствий является определение:

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

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

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

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

8.5 При разработке мероприятий могут быть использованы следующие рекомендации:

• изменять методы изготовления продукции, оснастки, приспособлений;
• изменять методы хранения, транспортирования продукции;
• отбраковывать, возвращать и заменять закупаемые материалы, сырье и КИ;
• заменять поставщика закупаемых материалов, сырья и КИ;
• разрабатывать совместно с поставщиком программы обеспечения и повышения качества закупаемых материалов, сырья и КИ;
• дорабатывать и регулировать ТП изготовления продукции;
• изменять методы контроля и испытаний;
• заменять оборудование, средства измерений и испытаний, изменять условия производства;
• совершенствовать процедуры наладки оборудования, регулировки процессов;
• обучать и аттестовывать персонал;
• корректировать процедуры и документы СМК;
• изменять систему оплаты труда и т.д.

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

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

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

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

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

8.11 Периодический контроль (не реже 1 раза в месяц) за ведением журнала повседневного надзора (Журнала Решение проблем) и выполнением разработанных мероприятий осуществляет технолог цеха (инженер по анализу брака).

8.12 Мероприятия корректирующего и предупреждающего действия могут иметь как оперативный, так и перспективный характер.

8.13 Мероприятия оперативного характера и сроки их выполнения после разработки отслеживаются:

• мастером — в ходе производственной деятельности;
• мастером, технологом цеха, начальником цеха – на оперативных совещаниях, цеховых «Днях качества».

8.14. Сведения о выполнении мероприятий оформляются в месячных отчетах по качеству ОТК.

8.15 Мероприятия перспективного характера следует включать в:

• «План повышения качества»;
• План технического перевооружения.

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

8.17 Предупреждающие действия должны предусматривать совершенствование процессов, методов и процедур СМК. При необходимости по результатам предупреждающих действий вносятся изменения в НД, ТИ, РИ, ДИ, другие документы СМК.

8.18 Надзор за разработкой корректирующих и предупреждающих мероприятий осуществляет начальник ОТК (директор по качеству).

9 Оценка результативности корректирующих и предупреждающих действий

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

9.2 Результативность мероприятий оценивается по результатам наблюдений за состоянием качества продукции, процессов и СМК после их проведения.

9.3 Результативным может быть признано мероприятие, после проведения которого данное несоответствие не появляется. Это может быть подтверждено данными о том, что дефект (брак) продукции, несоответствие в процессе или, СМК, по которым проведены корректирующие и предупреждающие действия, устранены и не повторяются.

9.4 Оценка результативности мероприятий осуществляется:

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

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

• B Журнале повседневного надзора, Журнале решения проблем;
• B плане корректирующих и предупреждающих действий;
• в протоколе или ином документе.

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

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