Презентации / Lecture05p

Обеспечение качества ПО

Основы программной инженерии

Кулямин В.В., ВМК МГУ

Качество программного обеспечения

•Программное обеспечение (ПО) – инструмент для решения каких-то задач из жизни (бизнеса, администрирования, науки, развлечений, пр.)

•Качество инструмента – пригодность для решения нужных задач

•Проблемы сложности ПО

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

•Формулировка каждой конкретной задачи обычно не слишком четкая

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

•Задачи меняются со временем – жизнь меняется, и задачи вместе с ней

•Часто при изменениях меняется сама система, а изменения в требованиях не фиксируются явно (хорошо, если остаются хотя бы в виде разрозненных запросов)

Последствия проблем сложности ПО

•Невозможно четко оценить качество ПО в отрыве от конкретной системы и требований к ней

•Невозможно четко оценить качество без четкого понимания требований и контекста использования ПО

•Аккуратная оценка качества ПО не намного проще создания этого ПО

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

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

Характеристики качества ПО

•Стандарт ISO 25010:2011

•Функциональность

•Производительность

•Надежность

•Переносимость

•Совместимость

•Защищенность

•Удобство использования

•Удобство сопровождения

•Прежние стандарты (ISO 9126) описывали немного другую структуру характеристик

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

Ошибки – терминология

•Дефект, defect – наиболее общий термин, ошибка любого рода

•Отсутствие нужного комментария и сползшая с кнопки буква тоже считаются

•Сбой, failure – конкретное нарушение какого-либо требования при работе системы в определенной ситуации

•Неверный результат, неверное действие, потеря данных, падение, зацикливание и подвисание – любое неожидаемое поведение

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

•Ошибка, fault – неверная или пропущенная конструкция/инструкция/ выражение в коде

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

•Может иметь неоднозначное расположение, если исправить код можно несколькими разными способами

•Ошибка, error

•Более общий и чаще используемый смысл – неверное понимание какого-либо вопроса/аспекта/условия/ алгоритма/операции системы разработчиком

•Более частный, используется редко – некорректное значение данных, внутренних или результирующих, возникающее в некоторой ситуации

Влияние сложности ПО на ошибки

• Практически полезные системы всегда довольно сложны

В практически полезной системе ошибки всегда есть

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

Источники ошибок

•Неверное понимание задач

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

•Некорректные решения для правильно понятых задач

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

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

•Неаккуратный перенос в код корректных решений

•Забытые символы, конструкции (иногда целые модули), опечатки, неверные использованные конструкции в коде или неудачные попытки упростить что-то при кодировании

Пример неправильного понимания

Самолет Airbus A320-200, рейс Lufthanza 2904 Франкфурт-Варшава 14.09.1993

•Приземление в аэропорту Варшавы, посадочная полоса длиной 2800 м

•Боковой ветер при посадке сменился на сильный попутный, сильный дождь

•Самолет накренился, правая стойка шасси коснулась земли на отметке 770 м, левая – на отметке 1525 м (9 с спустя)

•Только на отметке 1525 м интерцепторы были подняты и включен реверс-режим двигателей

•Тормоза на колесах включились еще через 4 с

•Самолет не успевал затормозить до конца полосы, пилот свернул с нее вправо (на скорости 133 км/ч), самолет проехал 90 м и врезался в насыпь и антенну радара левым крылом, возник пожар

•Двое погибших – член команды и пассажир

Пример неправильного понимания

•Условие включения реверса

•Нагрузка 6.3 т на каждое шасси

•Условие выпуска интерцепторов – одно из двух

•Нагрузка 6.3 т на каждое шасси

•Вращение колес 133 км/ч

•В силу обстоятельств (крен самолета и скользкая полоса) оба не сработали до отметки 1525 м

•Пример неадекватных требований,

после их формулировки в таком виде даже формальная верификация не выявила проблем

Пример некорректного решения

•Прибор радиотерапии Therac-25

•Производился Atomic Energy of Canada Limited в 1982 г

•В 1985-87 произошло 6 инцидентов, приведших к гибели пациентов, связанной с передозировкой излучения (превышение доз в сотни раз)

•Два режима работы

•Прямое облучение слабым потоком электронов

•Облучение потоком γ-лучей, получаемых при пропускании сильного потока электронов через специальную заглушку

•Переключение между режимами должно усилить поток и вставить заглушку на его пути

•В ходе инцидентов этого не происходило и пациент получал облучение сильным потоком электронов

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

•Гонка проявлялась только при быстром переключении режимов, в начале работы операторы так еще не научились переключать и проблем не было