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

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

Причины

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

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

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

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

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

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

См. также

Ссылки

^ «Определение хрупкости программного обеспечения» . ПКМАГ . Проверено 19 мая 2023 г.
^ «Ошибка 2000 года» . Education.nationalgeographic.org . Проверено 19 мая 2023 г.

Роберт Э. Фильмман; Цилла Эльрад; Шивон Кларк; Мехмет Аксис (2004). Аспектно-ориентированное управление зависимостями . Эддисон Уэсли Профессионал. ISBN 0-321-21976-7 . Архивировано из оригинала 30 января 2013 года.
Вирджиния Пострел (1999). «Фантазии власти: странная привлекательность проблемы 2000 года – проблема перехода к 2000 году» . Причина . Архивировано из оригинала 10 сентября 2005 г. Проверено 25 июля 2008 г.

[1] «Определение хрупкости программного обеспечения» . ПКМАГ . Проверено 19 мая 2023 г.

[2] «Ошибка 2000 года» . Education.nationalgeographic.org . Проверено 19 мая 2023 г.

[1]

[2]