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

Хрупкость программного обеспечения — возрастающая вероятность того, что ранее надёжное программное обеспечение начинает давать сбои при столкновении с новыми, нестандартными данными, которые при изменении определённым образом выявляют невыявленные во время начального тестирования логические или семантические ошибки. Термин заимствован из металлообработки как аналог хрупкости металла^[1][2][3][4].

Учитывая разнообразие сложных систем, таких как аналоговая электроника, цифровая электроника, измерительные приборы, робототехника, проектирование программного обеспечения, эвристические алгоритмы, искусственный интеллект и другие. Любая сложная система, которая теряет управляемость при незначительных отклонениях в пределах ожидаемого диапазона работы, может считаться хрупкой, склонной к поломкам, «ломкой». Любая сложная система, выведенная за пределы своих расчётных возможностей управления, считаться хрупкой, как правило, не будет.

Дэвид Вудс, профессор интегрированных системных разработок в Университете штата Огайо, определяет хрупкость как «внезапный сбой в работе, когда события выходят за границы системы (в отличие от того, насколько хорошо она работает в пределах своих границ). … В процессе работы консультантом с быстрорастущими стартапами я усвоил одну важную вещь: сложность, возникающая как следствие успеха, становится тормозом для дальнейшего роста, если её не решать. Иными словами, чем успешнее ваша система, то есть чем больше людей хотят пользоваться созданным вами сервисом, тем сильнее вы вынуждены сталкиваться с тем, что система работает за пределами своих проектных ограничений, что приводит к увеличению числа сбоев»^[5].

Аки Какко пишет: «Искусственный интеллект демонстрирует поразительный прогресс, завораживая нас своей способностью осваивать сложные игры, создавать тексты, изображения, видео, веб-сайты и приложения, неотличимые от человеческих, а также выявлять закономерности, скрытые от нашего восприятия. Однако за этой завесой сверхчеловеческих возможностей часто кроется существенная уязвимость – хрупкость. Под хрупкостью ИИ понимается склонность системы хорошо работать с данными, схожими с теми, на которых она обучалась, но терпеть неудачу, порой катастрофическую, при столкновении даже с незначительно отличающимися, неожиданными или новыми входными данными. Эта уязвимость является серьезным препятствием для надёжного и безопасного внедрения ИИ в реальных приложениях, от беспилотных автомобилей до медицинской диагностики. Понимание причин её возникновения, последствий и способов смягчения имеет первостепенное значение для будущего искусственного интеллекта»^[6].

Пока программное обеспечение свежее, оно очень податливо, его можно изменить в соответствии с любым пожеланием заказчика. По мере роста проекта и увеличения числа пользователей с длительным опытом работы проект становится менее податлив. Подобно закалённому металлу проект становится системой с наследием, ломкой и сложной в сопровождении, поскольку это может привести в поломке всей системы^[4].

Хрупкость программного обеспечения может быть вызвана недоработанными алгоритмами, которые, возможно, хорошо работали для всего диапазона входных данных при их создании, но быстро выходят из строя при столкновении с новыми данными, которые, как ожидалось, должны были быть обработаны алгоритмом корректно^[7]. Далее приведены некоторые примеры:

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

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

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

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

• Гниение программного обеспечения
• Надёжность (компьютерные науки)
• Технический долг