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

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

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

2.3. Рекомендации по формированию перечня категорий

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

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

3 Зак. М35

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

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

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

2.4. Идентификация категории ошибки

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

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

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

Проведенное исследование позволяет сделать следующие выводы относительно процедур классификации ошибок:

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

- классификация ошибки должна проводиться во время разрешения проблемы, но ке после;

- определение категории ошибки должно основываться на Уведомлении о проблеме и Сообщении о закрытии проблемы;

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

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