Методы и способы идентификации сбоев и ошибок презентация

1. Методы и способы идентификации сбоев и ошибок

2.

Международный стандарт ANSI/IEEE-729-83
разделяет все ошибки в разработке программ на
следующие типы.
• Ошибка (error) — состояние программы, при
котором выдаются неправильные результаты,
причиной которых являются изъяны (flaw) в
операторах программы или в технологическом
процессе ее разработки, что приводит к
неправильной
интерпретации
исходной
информации, следовательно, и к неверному
решению.

3.

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

4.

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

5. Ошибки на этапах процесса тестирования.

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

6. Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются

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

7. Процесс проектирования

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

8.

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

9. Этап кодирования

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

10. Процесс тестирования.

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

11. Процесс сопровождения.

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

Скачать материал

Скачать материал

1


Лекция 2. ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ

2


Учебные вопросы 1. Интеллектуальные возможности человека 2. Неправильный перевод как причина ошибок в программных средствах 3. Модель перевода. 4. Основные пути борьбы с ошибками

3


Вопрос 1.

4


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

5


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

6


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

7


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

8


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

9


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

10


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

11


При разработке ПС мы не всегда можем уверенно знать о всех связях между ее элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между ее элементами, т.е. n!, где n число ее элементов. Систему назовем малой, если n 7. При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования научиться делать большие системы простыми.

12


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

13


Вопрос 2.

14


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

15


Грубая схема разработки и применения ПС

16


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

17


Вопрос 3.

18


Процесс перевода информации из представления A в представление B.

19


Основные шаги перевода: он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R; он запоминает полученную информацию в своей памяти M; он выбирает из своей памяти преобразуемую информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W; с помощью этого механизма он фиксирует представление B.

20


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

21


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

22


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

23


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

24


Вопрос 4.

25


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

Слайды и текст этой презентации