هشاشة البرمجيات

في برمجة الحاسوب وهندسة البرمجيات ، تُعرف هشاشة البرمجيات بأنها زيادة احتمالية تعطل البرمجيات ، التي كانت تبدو موثوقة سابقًا، عند تعرضها لبيانات جديدة وغير مألوفة ، مُعدّلة بطريقة تُولّد خطأً منطقيًا أو دلاليًا غير مكتشف أثناء اختبار البرمجيات الأولي . يُستمد هذا المصطلح من تشبيهات بهشاشة المعادن . ^{[ 1 ] [ 2 ] [ 3 ]} ونظرًا لتنوع الأنظمة المعقدة ، مثل الإلكترونيات التناظرية والرقمية ، وأجهزة القياس ، والروبوتات ، وتصميم البرمجيات ، والأساليب الاستدلالية ، والذكاء الاصطناعي ، وغيرها ، فإن التعريف العام هو أن أي نظام معقد لا يستطيع الحفاظ على التحكم بسبب تغيير طفيف ضمن نطاق التشغيل المتوقع يُعتبر هشًا وقابلًا للكسر، وبالتالي "هشًا". أما أي نظام معقد يُدفع إلى ما وراء حدود التحكم المصممة له، فمن غير المرجح أن يُعتبر هشًا.

مع ازدياد حجم البرامج وتوسع نطاقها وعدد مستخدميها دون أي صيانة أو إعادة هيكلة ، تصبح البرامج بمرور الوقت نظامًا قديمًا ، هشًا وغير قادر على الصيانة بسهولة دون إحداث خلل في النظام بأكمله.

قد ينجم ضعف البرمجيات عن خوارزميات غير مكتملة التطوير ، ربما كانت تعمل بكفاءة مع نطاق بيانات الإدخال الكامل عند إنشائها، لكنها تتعطل فورًا عند مواجهة بيانات جديدة كان من المتوقع أن تكون ضمن قدرة الخوارزمية على العمل بشكل صحيح. فيما يلي بعض الأمثلة:

• من الأمثلة الجيدة على ذلك خوارزمية ذات آلية معالجة أخطاء غير سليمة تسمح بالقسمة على صفر ، أو معادلة مطابقة منحنى تُستخدم لاستقراء بيانات تتجاوز نطاق البيانات التي تمت مطابقتها معها. ومن أسباب الهشاشة الأخرى استخدام هياكل بيانات تُقيّد القيم. وقد شاع هذا الأمر في أواخر التسعينيات عندما أدرك المستخدمون أن برامجهم لا تتسع إلا لرقمين فقط للسنة ؛ مما أدى إلى تحديث مفاجئ لكميات هائلة من البرامج الهشة قبل عام 2000. ^{[ 4 ]}
• من أشكال الهشاشة الشائعة الأخرى واجهات المستخدم الرسومية التي تعتمد على افتراضات غير صحيحة. على سبيل المثال، قد يستخدم المستخدم شاشة عرض منخفضة الدقة ، فيلاحظ أن البرنامج يفتح نافذة كبيرة جدًا لا تتسع لها الشاشة . وقد يحدث العكس أيضًا؛ كأن تكون النافذة صغيرة جدًا ولا يمكن تغيير حجمها، أو نافذة لا تتناسب عناصرها بشكل صحيح لأن افتراض المطورين بشأن دقة الشاشة لم يعد صحيحًا. مشكلة شائعة أخرى تظهر عند استخدام نظام ألوان مختلف عن النظام الافتراضي ، مما يؤدي إلى عرض النص بنفس لون الخلفية، أو عند استخدام خط مختلف عن الخط الافتراضي، مما لا يتناسب مع المساحة المتاحة ويؤدي إلى اقتطاع التعليمات والتسميات.

في كثير من الأحيان، يتم التخلي ببساطة عن قاعدة بيانات قديمة، والتي قد تستند إلى افتراضات خاطئة أو تقنيات مهملة، لصالح قاعدة بيانات جديدة تم إنشاؤها من الصفر ( المعروفة أيضًا باسم إعادة الكتابة ) والتي قد تكون خالية من العديد من أعباء النظام القديم، ولكن هذا الحل يمكن أن يكون عملية مكلفة وتستغرق وقتًا طويلاً.

بعض الأمثلة والأسباب وراء هشاشة البرمجيات:

• يتوقع المستخدمون واجهة مستخدم ثابتة نسبيًا . بمجرد تطبيق ميزة ما وعرضها على المستخدمين، يصبح من الصعب جدًا إقناعهم بقبول تغييرات جوهرية عليها، حتى لو لم تكن الميزة مصممة بشكل جيد أو كان وجودها يعيق التقدم المستقبلي.
• قد تحتوي الوثائق على قدر كبير من المعلومات التي تصف السلوك الحالي، وسيكون تغييرها مكلفاً. إضافةً إلى ذلك، يكاد يكون من المستحيل استرجاع جميع نسخ الوثائق الموجودة، لذا من المرجح أن يستمر المستخدمون في الرجوع إلى الأدلة القديمة.
• انتقل المطورون الأصليون، الذين كانوا على دراية بجميع تفاصيل البرنامج المعقدة، إلى مراحل أخرى، تاركين توثيقًا غير كافٍ لتلك التفاصيل. وقد نُقلت العديد من هذه التفاصيل إلى الآخرين عبر التقاليد الشفوية لفريق التصميم، والتي فُقد الكثير منها في نهاية المطاف، على الرغم من إمكانية إعادة اكتشاف بعضها من خلال تطبيق علم آثار البرمجيات بجدية (وبتكلفة باهظة) .
• ربما صدرت تحديثات برمجية على مر السنين، تُغير سلوك البرنامج بشكل طفيف. في كثير من الحالات، تُصلح هذه التحديثات، رغم أنها تُعالج الخلل الظاهر الذي صدرت من أجله، أعطالًا أخرى أكثر دقة في النظام. إذا لم يتم اكتشاف هذه الأعطال الدقيقة من خلال اختبارات التراجع ، فإنها تُصعّب إجراء تغييرات لاحقة على النظام.
• تظهر أشكالٌ أكثر دقةً من الهشاشة في أنظمة الذكاء الاصطناعي . تعتمد هذه الأنظمة غالبًا على افتراضاتٍ جوهريةٍ حول بيانات الإدخال، ثم تُنشأ خوارزمياتٌ وأساليبٌ استدلاليةٌ يُعتقد أنها تعالج هذه البيانات بشكلٍ صحيح. مع ذلك، عندما لا تتحقق هذه الافتراضات، أو يُكتشف لاحقًا أنها معيبة، فإن هذه الأنظمة التي تحتوي على خوارزمياتٍ غير مكتملة ستستجيب (تتعطل) في نهاية المطاف بطرقٍ غير متوقعةٍ عند مواجهة مدخلاتٍ غير مختبرة.
• قد تصبح الأنظمة هشةً أيضاً إذا كانت تبعيات المكونات جامدة للغاية . ومن الأمثلة على ذلك صعوبة الانتقال إلى إصدارات جديدة من التبعيات . فعندما يتوقع أحد المكونات من مكون آخر إخراج نطاق محدد من القيم، ثم يتغير هذا النطاق، فقد يتسبب ذلك في انتشار الأخطاء في جميع أنحاء النظام، سواء أثناء عملية البناء ( التجميع ) أو أثناء التشغيل .
• تتوفر موارد تقنية أقل لدعم التغييرات عندما يكون النظام قيد الصيانة، بدلاً من أثناء التطوير (من حيث دورة حياة تطوير الأنظمة (SDLC) ).

• نظام هش
• إنتروبيا البرمجيات
• تدهور البرمجيات
• المتانة (علوم الحاسوب)
• الديون التقنية

• روبرت إي. فيلمان؛ تزيلا إلراد؛ سيوبان كلارك ؛ محمد أكسيت (2004). إدارة التبعية الموجهة نحو الجوانب . أديسون ويسلي بروفيشنال. ISBN 0-321-21976-7.{{cite book}}: CS1 maint: deprecated archiveal service ( link )
• فيرجينيا بوستريل (1999). "أوهام السلطة: جاذبية غريبة لخطأ عام 2000  - مشكلة الانتقال إلى عام 2000" . مجلة ريزون . مؤرشف من الأصل بتاريخ 10 سبتمبر 2005. تاريخ الاسترجاع: 25 يوليو 2008 .