Файл: Принципы разработки безопасных программных продуктов.pdf

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

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

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

1.1.3 Причины ошибок программного обеспечения

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

Рисунок 1. Грубая схема разработки и применения ПС

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

Чтобы понять природу ошибок при переводе рассмотрим модель [3], изображённую на Рис. 2. На ней человек осуществляет перевод информации из представления A в представление B. При этом он совершает четыре основных шага перевода:

- он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R;

- он запоминает полученную информацию в своей памяти M;

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

- с помощью этого механизма он фиксирует представление B.

Рисунок 2. Модель перевода

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

1.1.4 Источники ошибок программного обеспечения

Известно, что практически во всех более или менее сложных программах (а также в ОС, которая является комплексом многих программ) есть ошибки. Причина этого очевидна-программы делают люди, а люди склонны ошибаться.

Рассмотрим источники ошибок на разных этапах проектирования.

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

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

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

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

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

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

1.1.5 Классификация ошибок программного обеспечения

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

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

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

В краткой классификации выделены следующие ошибки.

- ошибка пользовательского интерфейса;

- ошибки расчета;

- ошибки управления потоком;

- ошибки передачи или интерпретации данных;

- перегрузки;

- контроль версий;

- ошибка обнаружена и забыта;

ошибки тестирования.

1. Ошибки пользовательского интерфейса.

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

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

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

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

2. Ошибки расчета.

Существуют следующие причины таких ошибок:

- неправильная логика (может быть следствием как ошибок проектирования, так и кодирования);

- арифметические операции выполняются некорректно (как правило-это ошибки кодирования);

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

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

3. Ошибки управления потоком.

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

Выделяются подпункты:

- очевидно некорректное поведение программы;

- логика, основанная на определении вызывающей подпрограммы;

- использование таблиц переходов;

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