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

Software brittleness

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

Причины

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

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

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

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

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

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

Рекомендации

  • Роберт Э. Филман; Цилла Эльрад; Сиобхан Кларк; Мехмет Аксит (2004). Аспектно-ориентированное управление зависимостями. Эддисон Уэсли Профессионал. ISBN 0-321-21976-7.
  • Анастасиос Манессис, Адриан Хилтон, Фил Маклаухлан и Фил Палмер (2000). «Статистическая геометрическая основа для реконструкции моделей сцены» (PDF). Британская конференция по машинному зрению.CS1 maint: несколько имен: список авторов (связь)
  • Вирджиния Пострел (1999). «Энергетические фантазии: странная привлекательность ошибки 2000 года - проблема перехода к 2000 году». Причина. Архивировано из оригинал на 2005-09-10. Получено 2008-07-25.