Типы и источники дефектов и ошибок в комплексах программ

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

Типы и источники дефектов и ошибок в комплексах программ:

- характеристики дефектов и ошибок в комплексах программ:

· понятие дефекта и ошибки в программе;

· отсутствие полностью определенной программы-эталона;

· устранения первичных ошибок, на основе их вторичных проявлений;

· организационные дефекты при определении и использовании требований к программному продукту

· системные ошибки и недостатки требований к программному продукту;

· системные ошибки корректности выполнения требований к программному продукту;

· ошибки проектирования и производства алгоритмов программных компонентов и модулей;

· отчеты специалистов о выявленных дефектах и предложениях по корректировке комплекса программ;

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

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

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

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

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

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

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

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

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

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

Рис. 1

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

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

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

Отчеты об ошибках экспертные оценки, инспекции, быстрые просмотры -

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

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

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

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

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

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

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

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

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

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

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