Что такое вторичные ошибки ис

10.1. Общие
особенности дефектов, ошибок и рисков
в сложных программных средствах

10.2. Причины
и свойства дефектов, ошибок и модификаций
в сложных программных средствах

10.3. Риски
в жизненном цикле сложных программных
средств

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

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

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

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

Характеристики
дефектов и рисков непосредственно
связаны с достигаемой
корректностью, безопасностью и надежностью
функционирования
программ и помогают:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица
10.1

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

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

Вторичная ошибка

Cтраница 1

Вторичные ошибки являются определяющими для эффективности функционирования программ, и не каждая первичная ошибка заметно искажает выходные результаты. Вследствие этого ряд первичных ошибок может оставаться необнаруженным и, no — существу, не влияет на функциональные характеристики программ. В худшем случае вторичная ошибка проявляется как полный отказ — потеря работоспособности КП ( см. § 4.4) на длительное время. Значительное искажение программ, данных или вычислительного процесса может также вызвать отказовую ситуацию, которая или превращается в отказ, или может быть быстро исправлена, так что нормальное функционирование программ почти не нарушится. Кроме того, первичные ошибки могут вызывать обнаруживаемые искажения выходных данных, не влияющих на работоспособность КП.
 [1]

Одинаковые по величине вторичные ошибки в различных результирующих данных существенно различаются по своему воздействию на общую эффективность КП. Это влияние для вторичных ошибок в каждой / — и переменной может быть учтено коэффициентом х /, который позволяет взвешивать последствия ошибок. Формальная оценка значений X; и А / в настоящее время затруднительна, в лучшем случае их можно оценить методами экспертного опроса при предварительной четкой классификации т типов первичных ошибок в программах и q выходных величин.
 [2]

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

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

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

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

Описаны несколько математических моделей [4, 17, 18], основой которых являются различные гипотезы о характере проявления вторичных ошибок в программах. Эти гипотезы в той или иной степени апробированы при обработке данных реальных разработок, и их можно разделить на три группы. В первую группу входят очевидные допущения, статистическая проверка которых невозможна и нецелесообразна. Вторую группу составляют допущения, определяющие специфические характеристики модели и требующие статистической проверки и обоснования на базе экспериментальных исследований. В третью группу включены второстепенные допущения, расширяющие и уточняющие возможности применения модели и частично доступные экспериментальной проверке.
 [8]

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

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

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

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

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

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

Страницы:  

   1

   2

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

По величине ущерба проявление вторичных ошибок делятся на 3 группы:

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

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

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

Поделитесь с Вашими друзьями:

С этим файлом связано 1 файл(ов). Среди них: Rekun.docx.
Показать все связанные файлы

Подборка по базе: Тема 3. Преступность и ее основные характеристики.Файл.pdf, Библиотековедение. Основные виды деятельности в библиотечном дел, Локализация поражений мозга и основные принципы локализации высш, Радиационные аварии виды, причины, основные опасные факторы и ис, Реферат Основные акушерско 2022.doc, Нефтяные битумы. Основные показатели качества нефтяных битумов.d, Расположите основные этапы мировоззрения в порядке их становлени, Структура социокультурного пространства ночного города и ее осно, Анализ учебников с 1 по 4 класс по русскому языку и основные пон, Приорнтетные цели и основные механизмы воздействия органов госуд

1. CALS-технологии

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

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

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

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

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

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

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

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

К преимуществам интегрированной среды можно отнести:

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

Перспективы применения CALS на промышленных предприятиях заключаются в формировании специализированной организационно-информационной среды, позволяющей:

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

Применение основ CALS-технологий крайне важно для соответствия уровня развития предприятия современным тенденциям на международной промышленной арене.

Примерами CALS-технологий являются цифровые методы проектирования производств, поддерживающие контроль жизненного цикла продукции (Product LifecycleManagement) — так называемые PLM-системы. К ним относят следующие классы систем:

• CAD – (Computer Aided Design) – решение задач проектирования изделий и элементов; моделирование объектов на плоскости (2D-модель) и в пространстве (3D-модель); средства получения чертежей; архивы данных по элементам конструкций и создание шаблонов документов.
• CAE – (Computer Aided Engineering) – исследование свойств объектов (при изготовлении и эксплуатации); создание проверочных систем анализа объекта по разработанной модели; оптимизация параметров объекта по заданным условиям и ограничениям.
• CAM — (Computer Aided Manufacturing) – программирование контроллеров станков с ЧПУ; исследование вариантов траектории инструмента по алгоритмам обрабатываемой поверхности; анализ геометрических конфликтов; подгонка к оборудованию.
• PDM — (Product Data Management) — хранение данных и контроль документации; создание архива образцов; обеспечение доступа к информации и ее защита.

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

Еще одной важной функцией вычислительных методов является управление различными ресурсами и потоками предприятия в реальном времени — материально-техническими, финансовыми, процессами складирования, персоналом, планированием и сбытом продукции. Системы, реализующие выполнение перечисленных задач относятся к ERP-системам (Enterprise Resource Planning − управление ресурсами предприятия).

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

К типовым функциям данного класса программных продуктов относят:

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

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

2 Первичные ошибки, вторичные ошибки и их проявления

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

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

Распределение выявленных ошибок

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

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

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

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

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

• системные ошибки;
• ошибки в выборе алгоритма;
• алгоритмические ошибки;
• технологические ошибки;
• программные ошибки.

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

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

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

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

При автономной и в начале комплексной отладки ПО доля найденных системных ошибок в нем невелика (примерно 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки. В процессе эксплуатации преобладающими являются системные ошибки (примерно 80% всех ошибок). Следует отметить также большое количество команд и групп программ, которые корректируются при исправлении каждой системной ошибки.

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

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

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

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

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

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

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

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

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

Дефекты. Ошибки, сбои, отказы

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

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

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

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

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

Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.

Дефекты могут быть в документации, настройках, входных данных и т.д.

Сбой или отказ — отклонение поведения системы от ожидаемого.

В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :

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

Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

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

Отчёт о дефекте и его жизненный цикл

При обнаружении дефекта тестировщик создаёт отчёт о дефекте .

Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению

Отчёт о дефекте пишется со следующими основными целями:

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

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

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

• Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт.
• Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто — то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на основе определённых правил.
• Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.
• Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте.

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

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

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

• Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.

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

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

• В некоторых средствах одного из состояний нет (оно поглощается другим)

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

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

• Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
• Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
• Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
• Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).

Атрибуты (поля) отчёта о дефекте

Общий вид всей структуры отчёта о дефекте представлен на рисунке

• Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
• Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».

Например: «Отсутствует логотип на странице приветствия, если пользователь

является администратором»:

— Что произошло? Отсутствует логотип.

— Где это произошло? На странице приветствия.

— При каких условиях это произошло? Если пользователь является

администратором.

Заполнение поля « краткое описание », которое одновременно должно:

— содержать предельно краткую, но в то же время достаточную для

понимания сути проблемы информацию о дефекте;

— быть достаточно коротким, чтобы полностью помещаться на экране;

— при необходимости содержать информацию об окружении, под

которым был обнаружен дефект;

— по возможности не дублировать краткие описания других

дефектов (и даже не быть похожими на них), чтобы дефекты

было сложно перепутать или посчитать дубликатами друг друга;

— быть законченным предложением русского или английского (или

иного) языка, построенным по соответствующим правилам

грамматики.

Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:

• Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
• Сформулировать подробное описание
• 3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.

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

5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.

6. Если предложение получилось слишком длинным, переформулировать

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

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

предложение почти всегда будет короче русского аналога.

Пример применения этого алгоритма.

Тестированию подвергается некое веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что этого ограничения нет.

• Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
• Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.

• Конечный вариант подробного описания:

— Фактический результат: в описании товара (поле «О товаре»,

http://testapplication/admin/goods/edit/) отсутствуют проверка и

ограничение длины вводимого текста (MAX=250 символов).

— Ожидаемый результат: в случае попытки ввода 251+ символов

выводится сообщение об ошибке.

• Определение «что, где и при каких условиях случилось»:

— Что: отсутствуют проверка и ограничение длины вводимого текста.

— Где: описание товара, поле «О товаре»,

http://testapplication/admin/goods/edit/.

— При каких условиях: – (в данном случае дефект присутствует всегда, вне

зависимости от каких бы то ни было особых условий).

• Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
• Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.

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

Пример подробного описания :

Если в систему входит администратор, на странице приветствия отсутствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу страницы. Ожидаемый результат: логотип отображается в левом верхнем углу страницы. Требование: R245.3.23b.

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

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

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

Пример шагов воспроизведения :

• Открыть http://testapplication/admin/login/.
• Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).

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

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

• Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).

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

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

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

— Средняя — существование дефекта слабо влияет на типичные

сценарии работы пользователей, и/или существует обходной путь

достижения цели, например: диалоговое окно не закрывается

автоматически после нажатия кнопок «OK»/«Cancel», при распечатке

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

«Двусторонняя печать», перепутаны направления сортировок по

некоему полю таблицы.

— Низкая — существование дефекта редко обнаруживается

незначительным процентом пользователей и (почти) не влияет на их

работу, например: опечатка в глубоко вложенном пункте меню

настроек, некоторое окно при отображении расположено неудобно

(нужно перетянуть его в удобное место), неточно отображается время

до завершения операции копирования файлов.

• Срочность показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие виды срочности:

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

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

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

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

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

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

• Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
• Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
• Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).