НАДЕЖНОСТЬ И КОРРЕКТНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

4.1. Ошибки и последствия: принципиальный вопрос разработки ПО

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

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

Рис. 4

Прежде чем анализировать процесс разработки ПО ИС, рассмотрим пример многократного перевода какого-либо текста (например, научной статьи) последовательно с одного языка на другой. Очевидно, что не все они обладают одинаковыми выразительными возможностями (особенно тематическими). В свою очередь, как бы ни был квалифицирован переводчик, он живет вне «контекста» реального языка; наконец, он может оказаться неподготовленным адекватно воспринять смысл переводимого текста. Этот перечень несоответствий может быть продолжен дальше. Если число ступеней перевода будет, скажем, 4 или 5, то, несомненно, потери информации могут быть существенными. Сверка последнего перевода с оригиналом позволит восстановить потери, если последний сам корректен, чего, вообще говоря, может и не быть. Поскольку научные публикации носят информационный характер, ущерб в случае ошибки будет минимальным. Совершенно иными будут ситуация и последствия, если в качестве «исходного текста» для последующего каскада «переводов» будет техническая документация (рис. 4). Исследование потребностей и формулировка целей создания ИС заканчиваются постановкой задач. Эта работа требует не только профессиональной ориентации в предметной области, но и определенного склада мышления для точного (формального) представления целей. Грубые ошибки здесь маловероятны, однако и незначительные неточности позже могут стоить очень дорого. Вероятность существенных ошибок возрастает при переводе - Трансляции 1 - постановок задач на формальный язык математики (дифференциальных уравнений; матричной алгебры; теории графов; математического программирования и т. д.). Заказчик, как правило, не в состоянии вникнуть в смысл этого «перевода» на забытый им (или вовсе незнакомый) язык. Исполнитель, в свою очередь, следуя правилам и ограничениям последнего, может проигнорировать некоторые особенности словесных формулировок, имеющих важное значение для заказчика. Так или иначе, вклад этапа Трансляция 1 в статистику неудачных проектов (см. введение) значителен. Функцию «транслятора» с одного языка на другой выполняют аналитики. Далее, такие результаты Трансляции 1, как, например:

(запись на языке дифференциальных уравнений);

(запись задачи на языке математического программирования) и т. д. снова требуют трансляции, т. е. преобразования записей 1) и 2) в общие решения, иначе говоря, алгоритмы (Трансляция 2).

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

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

Эти стадии и этапы охвачены обратными связями, так как процесс проектирования и разработки носит возвратный характер. Задача заключается в том, чтобы на технологических переходах типа «трансляции» количество ошибок было минимально. Именно здесь закладывается надежность будущего ПО, а не на этапе самого «тщательного» тестирования. Для больших и средних ИС эта задача, видимо, наиболее последовательно и эффективно решается методом прототипирования, т. е. последовательным уточнением целей и созданием ПО за несколько итераций [3].

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

Ошибки вносят основной вклад в затраты на разработку ПО и его сопровождение.

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >