Общие особенности дефектов, ошибок и рисков в сложных программных средствах

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

К понятию «риски» относятся негативные события и их величины, отражающие потери, убытки или ущерб от процессов или продуктов, вызванные дефектами при проектировании требований, недостатками обос­нования проектов ПС, а также при последующих этапах разработки, реа­лизации и всего жизненного цикла комплексов программ. В ЖЦ ПС не всегда удается достигнуть требуемого положительного эффекта и может проявляться некоторый ущерб — риск в создаваемых проектах, программ­ных продуктах и их характеристиках. Риски проявляются, как негативные последствия дефектов функционирования и применения ПС, кото­рые способны нанести ущерб системе, внешней среде или пользователю в результате отклонения характеристик объектов или процессов от задан­ных требованиями заказчика, согласованными с разработчиками.

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

Характеристики дефектов и рисков непосредственно связаны с дос­тигаемой корректностью, безопасностью и надежностью функционирова­ния программ и помогают:

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

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

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

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

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

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

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

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

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

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

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

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

Критические ошибки останавливают выпуск версии программного продукта. Это могут быть ошибки с высоким влиянием, которые вызывают сбой в системе или потерю данных, отражаются на надежности и безопас­ности применения ПС, с которыми никогда не передается комплекс про­грамм пользователю. По десятибалльной шкале — от 8 до 10-го приоритета.

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

Таблица 10.1