Статистика
ошибок и дефектов в комплексах программ
и их характеристики
в
конкретных типах проектов ПС могут
служить ориентирами
для
разработчиков при распределении ресурсов
в жизненном цикле ПС
и предохранять их от излишнего оптимизма
при оценке достигнутого качества
программных продуктов. Источниками
ошибок в ПС являются специалисты
— конкретные люди с их индивидуальными
особенностями, квалификацией, талантом
и опытом. При этом можно выделить
предсказуемые
модификации, расширения и совершенствования
ПС и
изменения,
обусловленные
выявлением случайных, непредсказуемых
дефектов и ошибок.
Вследствие
этого плотность потоков и размеры
необходимых корректировок
в модулях и компонентах при разработке
и сопровождении ПС могут
различаться в десяток раз. Однако в
крупных комплексах программ статистика
и распределение типов выполняемых
1С:Распознавание первичных документов — новый сервис в программах. Инструкция по работе с сервисом
изменений для коллективов разных
специалистов нивелируются и проявляются
достаточно общие закономерности, которые
могут использоваться как ориентиры при
их выявлении и систематизации. Этому
могут помогать оценки типовых дефектов,
модификаций и корректировок путем их
накопления и обобщения по опыту создания
определенных классов ПС в конкретных
предприятиях.
К
понятию
«риски» относятся
негативные события и их величины,
отражающие потери, убытки или ущерб от
процессов или продуктов, вызванные
дефектами при
проектировании требований, недостатками
обоснования проектов ПС, а также при
последующих этапах разработки, реализации
и всего жизненного цикла комплексов
программ. В ЖЦ ПС не всегда
удается достигнуть требуемого
положительного эффекта и может проявляться
некоторый ущерб — риск в создаваемых
проектах, программных
продуктах и их характеристиках. Риски
проявляются, как негатив-ные
последствия дефектов функционирования
и применения ПС, которые
способны нанести ущерб системе, внешней
среде или пользователю в результате
отклонения характеристик объектов или
процессов от заданных требованиями
заказчика, согласованными с разработчиками.
Оценки
качества программных средств могут
проводиться с двух позиций: с позиции
положительной эффективности
и непосредственной адекватности
их характеристик назначению, целям
создания и применения,
а также с негативной
позиции возможного
при этом ущерба — риска от
использования ПС или системы. Показатели
качества преимущественно
отражают положительный эффект от
применения системы или ПС и основная
задача разработчиков проекта состоит
в обеспечении высоких значений
качества. Риски характеризуют возможные
Как исправлять ошибки в бухгалтерском учете: первичные документы
негативные
последствия дефектов или
ущерб пользователей при применении и
функционировании ПС и системы, и задача
разработчиков сводится к сокращению
дефектов и ликвидации рисков. Поэтому
методы и системы управления качеством
в жизненном цикле ПС близки к методам
анализа и управления рисками
проектов комплексов программ, они должны
их дополнять и совместно
способствовать совершенствованию
программных продуктов и систем на их
основе.
Характеристики
дефектов и рисков непосредственно
связаны с достигаемой
корректностью, безопасностью и надежностью
функционирования
программ и помогают:
- оценивать
реальное состояние проекта и планировать
необходимую трудоемкость и длительность
для его положительного завершения; - выбирать
методы и средства автоматизации
тестирования и отладки программ,
адекватные текущему состоянию разработки
и сопровождения
ПС, наиболее эффективные для устранения
определенных видов дефектов и рисков; - рассчитывать
необходимую эффективность контрмер и
дополнительных
средств оперативной защиты от
потенциальных дефектов и невыявленных
ошибок;
— оценивать
требующиеся ресурсы ЭВМ по расширению
памяти и производительности, с учетом
затрат на реализацию контрмер при
модификации и устранении ошибок и
рисков.
На
практике в процессе ЖЦ ПС исходные
требования поэтапно уточняются,
модифицируются, расширяются и
детализируются по согласованию
между заказчиком и разработчиком. Базой
таких уточнений являются неформализованные
представления и знания специалистов-заказчиков
и
разработчиков, а также результаты
промежуточных этапов проектирования.
Однако установить некорректность таких
эталонов еще труднее, чем обнаружить
дефекты в сопровождаемых программах,
так как принципиально отсутствуют
формализованные данные, которые можно
использовать как исходные. В процессе
декомпозиции и верификации исходной
спецификации
требований на ПС возможно появление
ошибок в спецификациях
на группы программ и на отдельные модули.
Это способствует расширению спектра
возможных дефектов и вызывает необходимость
со-
здания
гаммы методов и средств тестирования
для выявления некорректностей в
спецификациях на компоненты разных
уровней.
Важной
особенностью процесса выявления ошибок
в программах является отсутствие
полностью определенной программы-эталона,
которой
должны соответствовать текст и результаты
функционирования разрабатываемой
программы. Поэтому установить наличие
и локализовать дефект непосредственным
сравнением с программой без ошибок в
большинстве
случаев невозможно. При отладке и
тестировании обычно сначала обнаруживаются
вторичные
ошибки
ириски,
т.е.
последствия и результаты
проявления некоторых внутренних дефектов
или некорректностей программ
(рис. 10.1). Эти внутренние дефекты
следует
квалифицировать как первичные
ошибки
или причины обнаруженных аномалий
результатов. Последующая
локализация и корректировка таких
первичных ошибок должна
приводить к устранению ошибок,
первоначально обнаруживаемых в
результатах функционирования программ.
Потери
эффективности и риски программ за счет
неполной корректности в первом приближении
можно считать прямо пропорциональными
(с
коэффициентом) вторичным ошибкам в
выходных результатах. Типичным является
случай, когда одинаковые по величине и
виду вторичные ошибки
в различных результирующих данных
существенно различаются по своему
воздействию на общую эффективность и
риски применения комплекса программ.
Это влияние вторичных ошибок, в лучшем
случае, можно
оценить методами экспертного анализа
при условии предварительной, четкой
классификации видов возможных первичных
ошибок в программах
и выходных величин. Таким образом, оценка
последствий, отражающихся
на вторичных ошибках и функционировании
программ, может, в
принципе,
производиться по
значениям ущерба —
риска
вследствие неустраненных их причин —
первичных
ошибок в программе. Вторичные
ошибки являются определяющими для
эффективности функционирования
программ, однако не каждая первичная
ошибка вносит заметный вклад в выходные
результаты. Вследствие этого ряд
первичных ошибок может
оставаться необнаруженным и, по существу,
не влияет на функциональные
характеристики ПС.
Появление
ошибок в программах, естественно,
предшествует их обнаружению и устранению
на основе вторичных проявлений. Наибольшее
число
первичных ошибок вносится на этапах
системного анализа и разработки
модификаций программ. При этом на долю
системного анализа приходятся наиболее
сложные для обнаружения и устранения
дефекты. На последующих этапах разработки
изменений ПС ошибки вносятся и устраняются
в программах в процессе их корректировки
по результатам тестирования. Общие
тенденции состоят в быстром росте затрат
на выполнение каждого изменения на
последовательных этапах процессов
модификации
программ.
При
системном анализе модификаций
интенсивность обнаружения ошибок
относительно невелика, и ее трудно
выделить из процесса проектирования
ПС. Интенсивность проявления и обнаружения
вторичных ошибок
наиболее велика на этапе активного
тестирования и автономной отладки
программных компонентов. Затем она
снижается приблизительно экспоненциально.
Различия интенсивностей устранения
первичных ошибок, на основе их вторичных
проявлений, и
внесения первичных ошибок
при
корректировках программ определяют
скорость достижения заданного качества
версий ПС. Уровень серьезности последствий
ошибок варьирует
от классов проектов и от предприятия,
но, в общем, можно разделить ошибки
на три уровня.
Небольшими
ошибками называют
такие, на которые средний пользователь
не обратит внимания при применении ПС
вследствие отсутствия их проявления
и последствия которых обычно так и не
обнаруживаются. Небольшие ошибки могут
включать орфографические ошибки на
экране, пропущенные разделы в справочнике
и другие мелкие проблемы. Такие ошибки
никогда не помешают выпуску и применению
версии системы и программного
продукта. По десятибалльной шкале рисков
небольшие ошибки находятся в пределах
от 1 до 3-го приоритета (см. ниже).
Умеренными
ошибками называют
те, которые влияют на конечного
пользователя, но имеются слабые
последствия или обходные пути, позволяющие
сохранить достаточную функциональность
ПС. Это такие дефекты,
как неверные ссылки на страницах,
ошибочный текст на экране и даже сбои,
если эти сбои трудно воспроизвести и
они не оказывают влияния на существенное
число пользователей. Некоторые умеренные
ошибки, возможно,
проникают в конечный программный
продукт. Ошибки, которые можно
исправить на этом уровне, следует
исправлять, если на это есть время
и возможность. По десятибалльной шкале
умеренные ошибки находятся
в диапазоне от 4 до 7-го приоритета.
Критические
ошибки останавливают
выпуск версии программного продукта.
Это могут быть ошибки
с высоким влиянием, которые
вызывают сбой
в системе или потерю данных, отражаются
на надежности и безопасности
применения ПС, с которыми никогда не
передается комплекс программ
пользователю. По десятибалльной шкале
— от 8 до 10-го приоритета.
Совокупность
ошибок, дефектов и последствий модификаций
проектов
крупномасштабных комплексов программ
можно упорядочить и условно представить
в виде перевернутой пирамиды в зависимости
от потенциальной
опасности и возможной величины
корректировок их последствий — рис.
10.2. В верхней части перечня расположены
модификации, дефекты
и ошибки, последствия которых обычно
требуют наибольших затрат
ресурсов для реализации изменений, и
они постепенно сокращаются
при снижении по перечню. Такое представление
величины типов корректировок программ
и данных полезно использовать как
ориентир для
учета
необходимых ресурсов при разработке и
сопровождении ПС, однако оно может
содержать значительные отклонения при
упорядочении статистических данных
реальных проектов. Каждому типу
корректировок соответствует
более или менее определенная категория
специалистов, являющихся источником
изменений данного типа (таблица 10.1).
Такую корреляцию
целесообразно рассматривать и учитывать
как общую качественную тенденцию
при анализе и поиске их причин.
Таблица
10.1
Специалисты—
источники дефектов и ошибок
Типы
первичных дефектов и ошибок программного
средства и документации
Источник: testirovanie24.ru
Первичные ошибки, вторичные ошибки и их проявления
обнаруживаемые искажения программ, данных или вычислительного процесса, равны величине, обратной интенсивности обнаружения ошибок:
(11. 4)
Если учесть, что до начала отладки в комплексе программ
содержалось N0 первичных ошибок и этому соответствовала наработка T0, то функцию наработки между проявлениями ошибок от длительно-
(11. 5)
Если известны все моменты обнаружения ошибок ti и каждый раз в эти моменты обнаруживается и достоверно устраняется одна первичная ошибка, то, используя метод максимального правдоподобия, получим уравнение для определения значения начального количества первичных ошибок N0
(11. 6)
и выражение для расчета коэффициента пропорциональности
(11. 7)
Необходимые для расчетов К и N0 экспериментальные значения ti определяются в процессе отладки данного или аналогичных комплексов программ, созданных тем же коллективом разработчиков и при такой же технологии. В результате можно рассчитать
число оставшихся в программе первичных ошибок и среднюю наработку Т до обнаружения следующей ошибки.
В процессе отладки и испытания программ для повышения наработки между проявлениями ошибок от величины Т1 до значения Т2 необходимо обнаружить и устранить D n ошибок. Эту величину можно определить, выразив число обнаруживаемых ошибок через длительность наработки на проявление ошибок, для чего подставим (11. 4) в
(11. 8)
Аналогичными несложными преобразованиями можно получить затраты времени на проведение отладки Dt, которые позволяют устранить D n ошибок и соответственно повысить наработку между очередными обнаружениями ошибок от значения Т1 до Т2:
(11. 9)
Следует подчеркнуть статистический характер приведенных соотношений.
Неравномерность выбора маршрутов исполнения программы при нормальной
эксплуатации, разное влияние конкретных типов ошибок в программах на проявление их при функционировании, а также сравнительно небольшие значения n и D n, особенно на заключительных этапах отладки, приводят к тому, что флюктуации интервалов времени между обнаружением ошибок Dt могут быть весьма значительными
1. Предназначение математических моделей?
2. Что такое первая группа допущений?
3. Что такое вторая группа допущений?
4. Что такое третья группа допущений?
ЛЕКЦИЯ 7
Первичные ошибки, вторичные ошибки и их проявления
1. Контрольный опрос
2. Алгоритмы выявления ошибок ПО
3. Процесс модернизации ИС
4. Анализ последствий применения обновлений
Рассмотрим классификацию ошибок по месту их возникновения, которая рассмотрена в книге С. Канера «Тестирование программного обеспечения». Фундаментальные концепции менеджмента бизнес-приложений. . Главным критерием программы должно быть ее качество, которое трактуется как отсутствие в ней недостатков, а также сбоев и явных ошибок.
Недостатки программы зависят от субъективной оценкой ее качества потенциальным пользователем. При этом авторы скептически относятся к спецификации и утверждают, что даже при ее наличии, выявленные на конечном этапе недостатки говорят о ее низком качестве. При таком подходе преодоление недостатков программы, особенно на заключительном этапе проектирования, может приводить к снижению надежности. Очевидно, что для разработки ответственного и безопасного программного обеспечения (ПО) такой подход не годится, однако проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы. Должна быть разработана система некоторых ограничений, которая бы учитывала эти факторы при разработке и сертификации такого рода ПО. Для обычных программ все
проблемы, связанные с субъективным оцениванием их качества и наличием ошибок, скорее всего неизбежны.
В краткой классификации выделяются следующие ошибки.
— Ошибки пользовательского интерфейса.
— Ошибки управления потоком.
— Ошибки передачи или интерпретации данных.
— Ошибка выявлена и забыта.
1. Ошибки пользовательского интерфейса.
Многие из них субъективны, т. к. часто они являются скорее неудобствами, чем
«чистыми» логическими ошибками. Однако они могут провоцировать ошибки пользователя программы или же замедлять время его работы до неприемлемой величины. В результате чего мы будем иметь ошибки информационной системы (ИС) в целом.
Основным источником таких ошибок является сложный компромисс между функциональностью программы и простотой обучения и работы пользователя с этой программой. Проблему надо начинать решать при проектировании системы на уровне ее декомпозиции на отдельные модули, исходя из того, что вряд ли удастся спроектировать простой и удобный пользовательский интерфейс для модуля, перегруженного различными функциями. Кроме того, необходимо учитывать рекомендации по проектированию пользовательских интерфейсов. На этапе тестирования ПО полезно предусмотреть встроенные средства тестирования, которые бы запоминали последовательности действий пользователя, время совершения отдельных операций, расстояния перемещения курсора мыши. Кроме этого возможно применение гораздо более сложных средств психо- физического тестирования на этапе тестирования интерфейса пользователя, которые позволят оценить скорость реакции пользователя, частоту этих реакций, утомляемость и т. п. Необходимо отметить, что такие ошибки очень критичны с точки зрения коммерческого успеха разрабатываемого ПО, т. к. они будут в первую очередь оцениваться потенциальным заказчиком.
2. Ошибки вычислений.
Выделяют следующие причины возникновения таких ошибок:
— неверная логика (может быть следствием, как ошибок проектирования, так и кодирования);
— неправильно выполняются арифметические операции (как правило — это ошибки кодирования);
— неточные вычисления (могут быть следствием, как ошибок проектирования, так и кодирования). Очень сложная тема, надо выработать свое отношение к ней с точки зрения разработки безопасного ПО.
Выделяются подпункты: устаревшие константы; ошибки вычислений; неверно расставленные скобки; неправильный порядок операторов; неверно работает базовая функция; переполнение и потеря значащих разрядов; ошибки отсечения и округления; путаница с представлением данных; неправильное преобразование данных из одного формата в другой; неверная
3. Ошибки управления потоком.
В этот раздел относится все то, что связано с последовательностью и обстоятельствами выполнения операторов программы.
— очевидно неверное поведение программы;
— переход по GOTO;
— логика, основанная на определении вызывающей подпрограммы;
— использование таблиц переходов;
— выполнение данных (вместо команд). Ситуация возможна из-за ошибок работы с указателями, отсутствия проверок границ массивов, ошибок перехода, вызванных, например, ошибкой в таблице адресов перехода, ошибок сегментирования памяти.
4. Ошибки обработки или интерпретации данных. Выделяются подпункты:
— проблемы при передаче данных между подпрограммами (сюда включены несколько видов ошибок: параметры указаны не в том порядке или пропущены, несоответствие типов данных, псевдонимы и различная интерпретация содержимого одной и той же области памяти, неправильная интерпретация данных, неадекватная информация об ошибке, перед аварийным выходом из подпрограммы не восстановлено правильное состояние данных, устаревшие копии данных, связанные переменные не синхронизированы, локальная установка глобальных данных (имеется в виду путаница локальных и глобальных переменных), глобальное использование локальных переменных, неверная маска битового поля, неверное значение из таблицы);
— границы расположения данных (сюда включены несколько видов ошибок: не обозначен конец нуль-терминированной строки, неожиданный конец строки, запись/чтение за границами структуры данных или ее элемента, чтение за пределами буфера сообщения, чтение за пределами буфера сообщения, дополнение переменных до полного слова, переполнение и выход за нижнюю границу стека данных, затирание кода или данных другого процесса);
— проблемы с обменом сообщений (сюда включены несколько видов ошибок: отправка сообщения не тому процессу или не в тот порт, ошибка распознавания полученного сообщения, недостающие или несинхронизированные сообщения, сообщение передано только N процессам из N+1, порча данных, хранящихся на внешнем устройстве, потеря изменений, не сохранены введенные данные, объем данных слишком велик для процесса-получателя, неудачная попытка отмены записи данных).
5. Повышенные нагрузки.
При повышенных нагрузках или нехватке ресурсов могут возникнуть дополнительные ошибки. Выделяются подпункты: требуемый ресурс недоступен; не освобожден ресурс; нет сигнала об освобождении устройства; старый файл не удален с накопителя; системе не возвращена неиспользуемая память; лишние затраты компьютерного времени; нет свободного блока памяти достаточного размера; недостаточный размер буфера ввода или очереди; не очищен элемент очереди, буфера или стека; потерянные сообщения; снижение производительности; повышение вероятности ситуационных гонок; при повышенной нагрузке объем необязательных данных не сокращается; не распознается сокращенный вывод другого процесса при повышенной загрузке; не приостанавливаются задания с низким приоритетом.
В этом разделе хотелось бы обратить внимание на следующее:
1) Часть ошибок из этого раздела могут проявляться и при не очень высоких нагрузках, но, возможно, они будут проявляться реже и через более длительные интервалы времени;
2) Многие ошибки из 2-х предыдущих разделов уже в своей формулировке носят вероятностный характер, поэтому следует предположить возможность использования вероятностных моделей и методов для их выявления.
6. Контроль версий и идентификаторов.
Выделяются подпункты: таинственным образом появляются старые ошибки; обновление не всех копий данных или программных файлов; отсутствие заголовка; отсутствие номера версии; неверный номер версии в заголовке экрана; отсутствующая или неверная информация об авторских правах; программа, скомпилированная из архивной копии, не соответствует проданному варианту; готовые диски содержат неверный код или данные.
7. Ошибки тестирования.
Являются ошибками сотрудников группы тестирования, а не программы.
— пропущенные ошибки в программе;
— не замечена проблема (отмечаются следующие причины этого: тестировщик не знает, каким должен быть правильный результат, ошибка затерялась в большом объеме выходных данных, тестировщик не ожидал такого результата теста, тестировщик устал и невнимателен, ему скучно, механизм выполнения теста настолько сложен, что тестировщик уделяет ему больше внимания, чем результатам);
— пропуск ошибок на экране;
— не документирована проблема (отмечаются следующие причины этого: тестировщик неаккуратно ведет записи, тестировщик не уверен в том, что данные действия программы являются ошибочными, ошибка показалась слишком незначительной, тестировщик считает, что ошибку не будет исправлена, тестировщика просили не документировать больше подобные ошибки).
8. Ошибка выявлена и забыта.
Описываются ошибки использования результатов тестирования. По-моему, раздел следует объединить с предыдущим. Выделяются подпункты: не составлен итоговый отчет; серьезная проблема не документирована повторно; не проверено исправление; перед выпуском продукта не проанализирован список нерешенных проблем.
Необходимо заметить, что изложенные в 2-х последних разделах ошибки тестирования требуют для устранения средств автоматизации тестирования и составления отчетов. В идеальном случае, эти средства должны быть проинтегрированы со средствами и технологиями проектирования ПО. Они должны стать важными инструментальными средствами создания высококачественного ПО. При разработке средств автоматизированного тестирования следует избегать ошибок, которые присущи любому ПО, поэтому нужно потребовать, чтобы такие средства обладали более высокими характеристиками надежности, чем проверяемое с их помощью ПО.
Источник: megalektsii.ru
Типы и источники дефектов и ошибок в комплексах программ
Типы и источники дефектов и ошибок в комплексах программ:
— характеристики дефектов и ошибок в комплексах программ:
· понятие дефекта и ошибки в программе;
· отсутствие полностью определенной программы-эталона;
· устранения первичных ошибок, на основе их вторичных проявлений;
· организационные дефекты при определении и использовании требований к программному продукту
· системные ошибки и недостатки требований к программному продукту;
· системные ошибки корректности выполнения требований к программному продукту;
· ошибки проектирования и производства алгоритмов программных компонентов и модулей;
· отчеты специалистов о выявленных дефектах и предложениях по корректировке комплекса программ;
— уровни ошибок сложных поставляемых программных продуктов, как ориентиры для прогнозирования длительности производства новых продуктов высокого качества.
Любое отклонение результатов функционирования программы от предъявляемых к ней требований и сформированных по ним эталонов-тестов, следует квалифицировать как ошибку – дефект в программе, наносящий некоторый ущерб. Различие между ожидаемыми и полученными результатами функционирования комплекса программ могут быть следствием ошибок не только в созданных программах, но и ошибок в первичных требованиях спецификаций, явившихся базой при создании эталонов. Тем самым проявляется объективная реальность, заключающаяся в невозможности абсолютной корректности и полноты исходных требований и эталонов для проектов крупных программных продуктов.
Изучение характеристик ошибок непосредственно связано с достигаемой корректностью, безопасностью и надежностью функционирования комплексов программ и помогает:
· оценивать реальное состояние проекта и планировать необходимую трудоемкость и длительность для его завершения и устранения ошибок;
· выбирать методы и средства автоматизации тестирования и отладки комплекса программ, адекватные текущему состоянию разработки и сопровождения, наиболее эффективные для устранения определенных видов дефектов;
· рассчитывать необходимую эффективность контрмер и дополнительных средств оперативной защиты от потенциальных дефектов и не выявленных ошибок;
· оценивать требующиеся ресурсы ЭВМ по расширению памяти и производительности с учетом затрат на реализацию контрмер при модификации программ для устранения дефектов и ошибок.
На практике исходные требования – эталоны поэтапно уточняются, модифицируются, расширяются и детализируются по согласованию между заказчиком и разработчиком. Базой таких уточнений являются неформализованные представления и знания специалистов-заказчиков и разработчиков, а также результаты промежуточных этапов проектирования и тестирования. Однако установить некорректность таких эталонов еще труднее, чем обнаружить дефекты в программах, так как принципиально отсутствуют точные, формализованные данные, которые можно использовать как исходные.
В процессе жизненного цикла комплекса программ его требования подвергаются декомпозиции на спецификации программных и информационных компонентов. Эти спецификации рассматриваются как частные эталоны для составных частей комплекса, однако они редко бывают абсолютно полными и корректными. В процессе декомпозиции и верификации исходной спецификации требований, возможно появление ошибок в спецификациях на группы программ и на отдельные компоненты. Это способствует расширению спектра возможных дефектов и вызывает необходимость создания гаммы методов и средств тестирования для выявления некорректностей в спецификациях и компонентах разных уровней детализации комплексов программ.
Важной особенностью процесса выявления ошибок в программах является отсутствие полностью определенной программы-эталона, которой должны соответствовать результаты функционирования разрабатываемой программы. Поэтому установить наличие и локализовать дефект в программе непосредственным ее сравнением с эталонной программой абсолютно без ошибок невозможно. При отладке и тестировании обычно сначала обнаруживаются вторичные ошибки, т.е. последствия и результаты проявления некоторых внутренних дефектов или некорректностей требований или функционирования программ (рис. 1).
Эти внутренние дефекты следует квалифицировать как источники – первичные ошибки или причины обнаруживаемых дефектов результатов. Последующая локализация и корректировка таких первичных ошибок должна приводить к устранению ошибок, первоначально выявляемых в результатах функционирования программ.
Потери эффективности и качества программ за счет неполной корректности в первом приближении можно считать прямо пропорциональными (с коэффициентом) вторичным ошибкам. Типичным является случай, когда одинаковые по величине и содержанию вторичные ошибки существенно различаются по своему воздействию на общую эффективность и последствия применения комплекса программ. Оценка последствий, отражающихся на вторичные ошибки при функционировании программ, может, в принципе, производиться по значениям ущерба – риска вследствие не устраненных их причин – первичных ошибок в программе. Вторичные ошибки являются определяющими для эффективности функционирования программ, однако не каждая первичная ошибка вносит заметный вклад в выходные результаты. Вследствие этого ряд первичных ошибок может оставаться не обнаруженным и, по существу, не влияет на функциональные характеристики комплексов программ.
Ошибкам в программах, естественно, предшествует их обнаружение и устранение на основе вторичных проявлений. Наибольшее число первичных ошибок вносится на этапах системного анализа, разработки или модификаций программ. При этом на долю системного анализа приходятся наиболее сложные для обнаружения и устранения дефекты.
Общие тенденции состоят в быстром росте затрат на выполнение каждого устранения ошибки на последовательных этапах процессов разработки комплекса программ. При системном анализе интенсивность обнаружения ошибок относительно не велика, и ее трудно выделять из процесса проектирования и разработки комплекса программ. Интенсивность проявления и обнаружения вторичных ошибок наиболее велика на этапе активного тестирования и автономной отладки программных компонентов. Затем она снижается приблизительно экспоненциально. Различия интенсивностей устранения первичных ошибок на основе их вторичных проявлений и внесения первичных ошибок при корректировках программ определяют скорость достижения заданного качества версий программного продукта.
Отчеты об ошибках экспертные оценки, инспекции, быстрые просмотры —
мощные инструменты для раннего обнаружения проблем в продуктах и документах любых видов, включая ошибки в программах. Полезный отчет об ошибке должен включать краткое описание, которое показывает суть и значение проблемы специалистам по управлению изменениями или комиссии по разбору ошибок. Краткое описание неоценимо при расстановке приоритетов ошибок для их устранения. Если пропускать этот этап как слишком затратный, чтобы быстрее ввести отчет об ошибке в систему управления дефектами, следует учитывать задержки и возможные срывы планов, которые могут произойти, когда разработчик потратит много времени на воспроизведение ситуации для устранения проявления ошибки.
Подготовка полезного отчета об ошибке должна начинаться с надежного, хорошо организованного тестирования. Воспроизведение проблемы (дефекта) обостряет ее понимание и позволяет фиксировать последовательность шагов, которые заново приведут к проявлению ошибки.
Иногда появляются ошибки, которые не просто воспроизводятся повторным тестированием и с большим трудом поддаются исправлению. На поведение программы могут влиять многие факторы, а некоторые из них воздействуют на симптомы ошибки. Точная локализация ошибки способствует росту доверия к тестировщику и дает преимущества при отладке. Попытка найти общее правило возникновения ошибок углубляет представление о системе и позволяет убедить разработчиков и менеджеров в том, что некоторая проблема не является единичным случаем. Отчеты об ошибках после того, как их занесли в систему управления дефектами, обычно остаются там навсегда и могут быть прочитаны людьми, не участвующими в проекте.
Источниками ошибок в комплексах программ являются специалисты – конкретные люди с их индивидуальными особенностями, квалификацией, талантом и опытом (таблица 2.1).
При этом можно выделить предсказуемые дефекты требований, модификаций, расширения и совершенствования ПС, и необходимые изменения, обусловленные выявлением случайных, непредсказуемых дефектов и ошибок. Вследствие этого, плотность потоков и размеры необходимых корректировок в требованиях к комплексу и компонентам программ могут различаться в десяток раз.
Однако в крупных комплексах программ статистика и распределение типов ошибок и выполняемых изменений для коллективов разных специалистов нивелируются и проявляются достаточно общие закономерности, которые могут использоваться как ориентиры при их выявлении. Каждому типу необходимых корректировок соответствует более или менее определенная категория специалистов, являющихся источником дефектов данного типа (см. таблицу 2.1). Такую корреляцию целесообразно учитывать как общую качественную тенденцию при анализе и поиске их причин. Этому могут помогать оценки типовых дефектов и корректировок путем их накопления и обобщения по опыту разработки определенных классов комплексов программ в конкретных предприятиях.
Одной из основных причин ошибок в комплексах программ являются организационные дефекты при определении и использовании требований к программному продукту, которые отличаются от остальных типов и условно могут быть выделены как самостоятельные. Ошибки и дефекты данного типа появляются из-за недостаточного понимания коллективом специалистов целей и функций комплекса программ, а также вследствие отсутствия четкой его организации и поэтапного контроля требований качества продуктов. Это порождается пренебрежением руководителей к организации всего технологического процесса формализации требований сложных программных продуктов и приводит к серьезной недооценке их дефектов, а также трудоемкости и сложности их выявления. При отсутствии планомерной и методичной разработки и тестирования требований может оставаться не выявленным значительное количество ошибок и, прежде всего, дефекты требований к взаимодействию отдельных функциональных компонентов между собой и с внешней средой. Для сокращения этого типа массовых ошибок активную роль должны играть лидеры – менеджеры и аналитики — системотехники, способные вести контроль и конфигурационное управление требованиями, изменениями и развитием версий и компонентов комплексов программ.
Ошибки оценки характеристик системы и внешней среды, принятых в процессе разработки комплекса программ за исходные, могут быть результатом аналитических расчетов, моделирования или исследования аналогичных систем. В ряде случаев может отсутствовать полная адекватность предполагаемых и реальных характеристик, что является причиной сложных и трудно обнаруживаемых системных ошибок и дефектов развития проекта. Ситуация с такими ошибками дополнительно усложняется тем, что эксперименты по проверке взаимодействия программного продукта с реальной внешней средой во всей области изменения характеристик зачастую сложны и дороги, а в отдельных случаях, при создании опасных ситуаций, недопустимы. В этих случаях приходится использовать моделирование и имитацию внешней среды с заведомым упрощением ее отдельных элементов и характеристик, хотя степень упрощения не всегда можно оценить с необходимой точностью. Однако полной адекватности моделей внешней среды и реальной системы добиться трудно, а во многих случаях и невозможно, что может являться причиной значительного числа дефектов.
Системные ошибки и недостатки требований к программному продукту определяются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. Кроме того, эти процессы зачастую зависят от самих алгоритмов и поэтому не могут быть достаточно определены и описаны заранее без исследования функционирования комплекса программ во взаимодействии с внешней средой. На начальных этапах разработки не всегда удается точно и полно сформулировать целевую задачу всей системы, а также целевые задачи основных функциональных групп программ, и эти задачи уточняются в процессе проектирования. В соответствии с этим уточняются и конкретизируются спецификации на функциональные компоненты и выявляются отклонения от уточненного задания требований, которые могут квалифицироваться как системные ошибки.
Во многих случаях отсутствует полная адекватность условий получения предполагаемых и реальных характеристик внешней среды, что может являться причиной сложных и трудно обнаруживаемых ошибок. Это усугубляется тем, что очень часто невозможно заранее предусмотреть все разнообразие возможных внешних условий и реальных вариантов сценариев функционирования и применения версий программных продуктов. При автономной и в начале комплексной отладки версий компонентов, относительная доля системных ошибок может быть невелика (около 10%), но она существенно возрастает (до 35 – 40%) на завершающих этапах комплексной отладки новых версий программного продукта. В процессе сопровождения системные ошибки обычно являются преобладающими (около 60 – 80% от всех ошибок).
Системные ошибки корректности выполнения требований к программному продукту считаются наиболее критичными для общего успеха его версий и системы в целом. Ошибки требований являются наиболее трудными для обнаружения и наиболее сложными для исправления. Вот почему исправление ошибок выполнения требований может быть в 15 – 70 раз дороже, чем ошибок программирования.
Требование может быть пропущено в спецификации к системе и комплексу программ. Это ведет к неудовлетворенности пользователя, и комплекс программ считается заказчиком и пользователем дефектным. Пропуск части требований – наиболее обычная проблема среди ошибок требований. Ошибки требований могут также представлять собой конфликтующие требования в спецификации.
Может проявляться неопределенность требований – такой способ формулирования требования, что даже если и не конфликтует с другим требованием, оно выражено недостаточно ясно, чтобы привести к единственному, конструктивному решению при разработке комплекса программ. Конечный пользователь часто называет это ошибкой, хотя на самом деле это выбор конструктивного решения на основе неполного или неопределенного требования. Многочисленные исследования показали, что ошибки требований труднее всего обнаруживать и дороже всего исправлять.
Воспользуйтесь поиском по сайту:
Источник: studopedia.org