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

Бытует
мнение, что первая программная ошибка
была обнаружена на заре развития ЭВМ,
когда в Массачусетском технологическом
институте окончилась неудачей попытка
запуска машины 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.
Существуют ли какие-нибудь текстовые
ошибки в выходной информации? Существуют
ли смысловые или грамматические ошибки
в тексте, выводимом программой на печать
или экран монитора? Все сообщения
программы должны быть тщательно
проверены.

Автор: Елена Иванова, консультант по управлению, руководитель консалтинговой практики ГК «Раздолье».

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

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

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

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

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

Ошибка номер один: отсутствие системного подхода

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

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

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

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

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

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

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

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

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

Ошибка номер два: некорректная система контроля

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

Любой бизнес-процесс имеет определенную длительность во времени. И чем глобальнее бизнес-процесс, тем более длительное время он выполняется. Согласование тех же договоров, по моему опыту, может проходить от нескольких дней (в небольших компаниях) до 2-3 месяцев (если речь идет о крупных гос. корпорациях). Если контролировать результат только по конечной точке (подписан/не подписан договор), через какое-то время вы можете обнаружить, что срок согласования давно прошел, а договор где-то «застрял». И через три месяца довольно сложно разобраться, где застопорился бизнес-процесс и почему это произошло. Результат — компания потеряла контракт или сорвала сроки его выполнения, т.к. позже запустила работу по контракту.

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

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

1) Научиться декомпозировать бизнес-процесс на самодостаточные логические этапы (их обычно называют «подпроцессами» и «процедурами»).

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

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

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

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

Ошибка номер три: неправильно закрепленная ответственность за бизнес-процессы

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

1) Излишняя централизация, когда несколько бизнес-процессов, влияющих друг на друга, объединяется под одного руководителя второго или ниже уровня управления.

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

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

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

2) Назначение владельцем бизнес-процесса того, кого «не жалко».

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

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

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

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

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

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

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

Ошибка номер четыре: мотивация как «параллельная реальность»

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

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

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

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

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

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

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

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

3) Дискретность оценки и выплаты премии за достижение результата должна коррелировать с длительностью его получения. Если вы премируете за промежуточные результаты бизнес-процесса – это необходимо делать ежемесячно. Если за конечный – зависит от длительности получения результата (возможны квартальные или годовые премии).

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

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

Ошибка номер пять: «есть слона целиком»

Анализ и оптимизация бизнес-процессов не может продолжаться долго. Иначе компания устает, процессы меняются и все теряет смысл. Сам анализ процессов должен занимать от нескольких недель до трех месяцев (если требуются комплексные изменения по многим направлениям деятельности), но не более. А вот оптимизация, т.е. переход к целевому состоянию может длиться дольше (по моему опыту, от полугода до года). Но при этом она должна давать какие-то осязаемые результаты каждые 2-3 месяца.Поэтапная классическая схема: «сначала описываем «как есть», потом оптимизируем «как надо», потом внедряем изменения и только потом автоматизируем» не работает.

Слишком быстро сейчас меняется окружающая нас реальность. А это означает, что нужно:

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

2) Выделять при анализе корневые проблемы. Т.е. те болевые точки, устранение которых даст максимально быстрый и полезный эффект. Но при этом учитывать связи изменяемой зоны со всей деятельностью компании, чтобы не получился неуправляемый «эффект бабочки».

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

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

В заключение, или Ошибка номер шесть

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

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

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

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

Как выстроить деятельность по регулярному мониторингу и совершенствованию бизнес-процессов? Ответ простой: подойти к этому как к бизнес-процессу:

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

2) Выделить «владельца бизнес-процесса». Обычно в компаниях это отдел организационного развития или служба управления качеством (если под управлением качеством понимается не только качество продукции).

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

4) Запустить проект по вводу нового бизнес-процесса в регулярную деятельность предприятия.

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

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

Бытует
мнение, что первая программная ошибка
была обнаружена на заре развития ЭВМ,
когда в Массачусетском технологическом
институте окончилась неудачей попытка
запуска машины 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.
Существуют ли какие-нибудь текстовые
ошибки в выходной информации? Существуют
ли смысловые или грамматические ошибки
в тексте, выводимом программой на печать
или экран монитора? Все сообщения
программы должны быть тщательно
проверены.

Суть оптимизации рабочего процесса

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

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

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

Преимущества оптимизации

Оптимизация рабочего процесса способствует:

• Повышению гибкости процесса: оптимизированные, эффективные процессы больше и быстрее подстраиваются под изменяющиеся условия; 
• Принятию решений на основе анализа данных: анализ может производиться на основании статистических данных и KPI, данных из информационных систем; 
• Улучшению отношений с клиентами: оптимизация рабочих процессов повышает качество клиентского обслуживания; 
• Снижению количества человеческих ошибок: процесс выполняется согласно разработанному регламенту и утвержденной модели to be; 
• Повышению осведомленности о результатах процесса: KPI процесса позволяют понять, насколько работа оптимизированного процесса соответствует стратегическим целям компании; 
• Упрощению понимания того, как можно беспрепятственно масштабировать процесс: масштабирование – тоже оптимизация своего рода, которая позволяет адаптировать бизнес-процесс к увеличившейся нагрузке; 
• Повышению конкурентного преимущества: как уже отмечалось выше, оптимизация ускоряет процесс и повышает качество произведенного продукта и качество клиентского сервиса. 

Шесть шагов оптимизации

Чтобы оптимизировать рабочий процесс, необходимо выполнить следующие шаги:

Шаг 1. Сформируйте понимание процесса

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

Шаг 2. Сформулируйте ожидаемые результаты от оптимизации рабочего процесса

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

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

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

Разрывы – различия между существующим и целевым процессом. Отобразите на модели, чем процесс «как должно быть» будет отличаться от «как есть». Можно также составить список или таблицу, в которой будут описаны оба процесса. Главное требование – различия должны быть четко определены.

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

Шаг 4. Упростите или оптимизируйте процесс.

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

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

Шаг 5. Ускорьте рабочий процесс

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

Шаг 6. Превратите процесс в алгоритм или автоматизируйте

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

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

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

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

Можно ли оптимизировать данный процесс и при этом снизить риски воздействия человеческого фактора? Да, можно, и вот как:

Шаг 1. Опишите процесс чистки машины

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

Шаг 2. Четко сформулируйте результаты от оптимизации рабочего процесса.

Оптимизация процесса чистки машины для молочных коктейлей должна привести к:

• Устранению ошибок в процессе ее сборки после чистки; 
• Ускорению процесса сборки. 

Шаг 3. Осуществите поиск отклонений процесса «как есть», определите разрывы.

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

Шаг 4. Упростите или оптимизируйте процесс.

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

Шаг 5. Осуществите ускорение рабочего процесса.

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

Шаг 6. Алгоритмизируйте процесс.

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

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