Хрупкость программного обеспечения

В компьютерном программировании и программной инженерии хрупкость программного обеспечения — это возросшая сложность исправления старого программного обеспечения , которое может казаться надежным, но вместо этого дает сбой, когда ему предъявляют необычные данные или данные, измененные, казалось бы, незначительным образом. Фраза происходит от аналогий с хрупкостью в металлообработке . ^[1]

Причины

Когда программное обеспечение новое, оно очень пластично; его можно сформировать так, как захотят разработчики. Но по мере того, как программное обеспечение в данном проекте становится все больше и больше и приобретает большую базу пользователей с большим опытом работы с программным обеспечением, оно становится все менее и менее пластичным. Подобно металлу, который был закален, программное обеспечение становится устаревшей системой , хрупкой и неспособной легко обслуживаться без разрушения всей системы. ^{[ необходима цитата ]}

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

Хорошим примером является алгоритм, который позволяет производить деление на ноль , или уравнение подгонки кривой , которое используется для экстраполяции за пределы данных, к которым оно было подогнано. Другой причиной хрупкости является использование структур данных , которые ограничивают значения. Это часто наблюдалось в конце 1990-х годов, когда люди осознали, что их программное обеспечение имеет место только для записи года из 2 цифр ; это привело к внезапному обновлению огромного количества хрупкого программного обеспечения до 2000 года. ^[2]
Другая более часто встречающаяся форма хрупкости — это графические пользовательские интерфейсы , которые делают неверные предположения. Например, пользователь может работать на дисплее с низким разрешением , может стать свидетелем того, как программное обеспечение открывает окно, слишком большое для отображения на дисплее . Может быть и наоборот; скажем, окно слишком маленькое для отображения без возможности изменения размера или окно, в котором элементы не вписываются правильно, поскольку предположение разработчиков о разрешении больше не соответствует действительности. Другая распространенная проблема выражается, когда пользователь использует цветовую схему, отличную от цветовой схемы по умолчанию , в результате чего текст отображается тем же цветом, что и фон, или пользователь использует шрифт, отличный от шрифта по умолчанию, который не помещается в допустимое пространство и обрезает инструкции и метки.

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

Некоторые примеры и причины нестабильности программного обеспечения:

Пользователи ожидают относительно постоянного пользовательского интерфейса . После того, как функция была реализована и представлена пользователям, очень сложно убедить их принять серьезные изменения в этой функции, даже если функция была плохо спроектирована или ее существование блокирует дальнейший прогресс.
Значительная часть документации может описывать текущее поведение и будет дорого изменяться. Кроме того, по сути невозможно отозвать все копии существующей документации, поэтому пользователи, скорее всего, продолжат ссылаться на устаревшие руководства.
Первоначальные разработчики, которые знали все сложные детали программного обеспечения, ушли и оставили недостаточно документации по этим сложным деталям. Многие из таких деталей передавались другим только через устные традиции команды разработчиков, многие из которых в конечном итоге безвозвратно утеряны, хотя некоторые могут быть заново открыты посредством усердного (и дорогостоящего) применения программной археологии .
Вероятно, на протяжении многих лет выпускались исправления , которые тонко изменяли поведение программного обеспечения. Во многих случаях эти исправления, исправляя явный сбой, для которого они были выпущены, вносят в систему другие, более тонкие сбои. Если их не обнаружить с помощью регрессионного тестирования , эти тонкие сбои затрудняют последующие изменения в системе.
Более тонкие формы хрупкости обычно встречаются в системах искусственного интеллекта . Эти системы часто полагаются на существенные предположения о входных данных. Когда эти предположения не выполняются, возможно, потому что они не были заявлены (как это часто бывает), то система будет реагировать совершенно непредсказуемым образом.
Системы также могут быть хрупкими, если зависимости компонентов слишком жесткие . Одним из примеров этого являются трудности перехода на новые версии зависимостей . Когда один компонент ожидает, что другой выведет только заданный диапазон значений, и этот диапазон изменяется, это может привести к распространению ошибок по системе либо во время сборки ( компиляции ), либо во время выполнения . ^{[ требуется цитата ]}
Меньше технических ресурсов доступно для поддержки изменений, когда система находится в стадии обслуживания, чем во время разработки (с точки зрения жизненного цикла разработки систем (SDLC) ^{[ необходима ссылка ]} ).

Смотрите также

Ссылки

^ "Определение хрупкости программного обеспечения". PCMAG . Получено 2023-05-19 .
^ "Ошибка Y2K". education.nationalgeographic.org . Получено 2023-05-19 .

Роберт Э. Филман; Цилла Элрад; Сиобхан Кларк ; Мехмет Аксит (2004). Аспектно-ориентированное управление зависимостями. Addison Wesley Professional. ISBN 0-321-21976-7. Архивировано из оригинала 30 января 2013 года.
Вирджиния Пострел (1999). "Фантазии о власти: странная привлекательность ошибки Y2K – проблема перехода к 2000 году". Причина . Архивировано из оригинала 2005-09-10 . Получено 2008-07-25 .