ОШИБКИ В ПО

 

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

В англоязычной литературе используется несколько терминов, часто переводящихся как «ошибка» на русский язык:

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

· failure — нарушение требований, проявляющееся при каком-то реальном сценарии работы ПО, это скорее проявление ошибки;

· fault — ошибка в коде программы, вызывающая нарушения требований при работе (failures), то место, которое надо исправить. Хотя это понятие используется довольно часто, оно, вообще говоря, не вполне четкое, поскольку для устранения нарушения можно исправить программу в нескольких местах. Что именно надо исправлять, зависит от дополнительных условий, выполнение которых мы хотим при этом обеспечить;

· error — используется в двух смыслах. Первый — это ошибка в ментальной модели программиста, которая заставляет его делать ошибки в коде (faults). Второй смысл — это некорректные значения данных (выходных или внутренних), которые возникают при ошибках в работе программы.

 

Первое место в неформальном состязании за место «самой дорого обошедшейся ошибки в ПО» долгое время удерживала ошибка, приведшая к неудаче первого запуска ракеты Ариан-5 4 июня 1996 года, стоившая около 500 M$. После произошедшего 14 августа 2003 года обширного отключения электричества на северо-востоке Северной Америки, стоившего экономике США и Канады от 4 до 10 миллиардов долларов, это место закрепилось за вызвавшей его ошибкой в системе управления электростанцией.

 

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

Дейкстра выделяет три интеллектуальные возможности человека, используемые при разработке ПО:

· способность к перебору,

· способность к абстракции,

· способность к математической индукции.

 

Способность человека к перебору связана с возможностью последовательного переключения внимания с одного предмета на другой, позволяя узнавать искомый предмет. Эта способность весьма ограничена – в среднем человек может уверенно (не сбиваясь) перебирать в пределах 1000 предметов (элементов). Человек должен научиться действовать с учетом этой своей ограниченности. Средством преодоления этой ограниченности является его способность к абстракции, благодаря которой человек может объединять разные предметы или экземпляры в одно понятие, заменять множество элементов одним элементом (другого рода). Способность человека к математической индукции позволяет ему справляться с бесконечными последовательностями.

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

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

При разработке ПО мы не всегда можем уверенно знать о всех связях между ее элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между ее элементами, т.е. n! , где n - число ее элементов. Систему назовем малой, если n < 7 (6! = 720 < 1000), систему назовем большой, если n > 7. При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования - научиться делать большие системы простыми.

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

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

 

 

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

 

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

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

 

 

Рис. 31 − Модель перевода

 

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

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

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

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

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

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

 

Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:

· сужение пространства перебора (упрощение создаваемых систем),

· обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),

· обеспечение однозначности интерпретации представления информации,

· контроль правильности перевода (включая и контроль однозначности интерпретации).