مخاطر البرامجيات

مخاطر البرامجيات

لقد عطلت الأخطاء البرامجية الخدمات الهاتفية وأخرت إطلاق المكوكات الفضائية،

ويمكن أن يحد الغموض المتأصل في اعتمادية reliability الحاسوب من دوره ولا سيما

في المنظومات التي تكون برامجياتها متعلقة بالأمان.

<B. ليتلوود> ـ <L. ستريجيني>

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

يطلق صاروخ باتريوت شعاعا فوق تل أبيب ليعترض صاروخ سكود قادما من العراق خلال حرب الخليج عام 1991.

يمكن في بعض الحالات أن تتعطل البرامجيات المتحكمة في منظومة التعقب لصواريخ باتريوت فتمنعها بذلك

من تحديد مواقع أهدافها من السكود وتدميرها. لقد أدى أحد هذه الأعطال فعلا إلى مقتل 28 جنديا أمريكيا.

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

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

يمكن، نظريا على الأقل، صنع برامجيات خالية من العيوب. وعلى نقيض المواد الأولية والآلات فإن البرامجيات لا تتعرض للبلى. كما توجد عيوب التصميم كافة منذ لحظة تحميل البرامجيات في الحاسوب. ومن حيث المبدأ يمكن التخلص من هذه العيوب إلى الأبد، إضافة إلى ذلك فإن البراهين الرياضياتية يمكنها مساعدة المبرمجين على ضمان صحة برامجياتهم.

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

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

إن أخطاء البرامجيات تبقى حتى في البرامج التي تمت إزالة الأخطاء منها إلى حد كبير.

وقد وجد <N .E. آدمز> من الشركة IBM أن الأخطاء التي تبقى في منظومة ما غالبا ما تكون

من نوع أخطاء الـ 5000 سنة؛ أي إن كل واحد منها يسبب فشلا واحدا كل 5000 سنة (الشكل العلوي)

وهذه النوعية من الأخطاء تجعل العائد من إزالتها عديم الجدوى: في اختبار منظومة

عسكرية للقيادة والتحكم (الشكل السفلي) يظهر أن الزمن اللازم لإزالة الأخطاء يتجاوز

بدرجة عالية سرعة التحسن الناتجة في تقدير الاعتمادية، التي تقاس بالزمن التقديري المتوسط للعطل.

ولزيادة الإيضاح تم رسم الأشكال البيانية بمقاييس زمنية مختلفة.

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

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

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

وفضلا عن الأخطاء الطفيفة غير المقصودة في التصميم فإن إدخال أخطاء عمدا بهدف توفيق منظومة ما يمكنه أن يسبب سلوكا غير مقبول للمنظومة. إن موضوع الأمان الحاسوبي والسرية والتعمية يتطلب اعتبارات خاصة تقع خارج نطاق هذه المقالة [انظر: "حماية خصوصية الفرد الإلكترونية"،مجلة العلوم ، العدد6/7 (1995)، ص 22].

فإذا سلّمنا بأن البرامجيات البالغة حد الكمال غير ممكنة عمليا، فكيف يمكننا إذًا أن نقرر ما إذا كان برنامج ما لديه الاعتمادية المطلوبة؟ أولا، يجب اختيار متطلبات الأمان بعناية لتعكس طبيعة التطبيق. ويمكن لهذه المتطلبات أن تختلف اختلافا كبيرا من تطبيق إلى آخر. فمثلا تتطلب الولايات المتحدة ألا تتعطَّل المنظومة الجديدة للتحكم في الطيران أكثر من 3 ثوان في العام. أما في خطوط الطيران المدني، فيجب ألا يكون احتمال حدوث عطل يؤدي إلى كارثة أكثر من 9-10 في الساعة.

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

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

وللأسف، فإن هذه الطريقة تنجح فقط عندما تكون متطلبات الاعتمادية متواضعة نسبيا (لنقُل بحدود فشلٍ واحد كل عدة سنوات) عند مقارنتها بالمتطلبات التي توضع للتطبيقات الخطرة. ولكي نحصل على مستوى ثقة يصل إلى 9-10 فشل في الساعة فإننا نحتاج إلى تنفيذ البرنامج لعدد من مضاعفات 9-10 ساعة عمل (أي 100000 سنة). ويتضح بالتأكيد أن هذه الطريقة غير ممكنة. وفي المجالات الزمنية التي يمكن خلالها إجراء الاختبار، فإن ضمانات الأمان ستنخفض بدرجة كبيرة جدا عن القيمة المطلوبة.

تكمن المشكلة هنا في قاعدة تناقص العائدات. عندما نستمر في إزالة أخطاء برنامج ما لفترة طويلة جدا، فإن الأخطاء التي سنجدها ستكون قليلة لدرجة أن إيجادها لا يؤثر في الاعتمادية الإجمالية أو الأمان. وقد قام <N .E. آدمز> (من مركز<J .T. واطسون> للبحث العلمي التابع للشركة IBM) بتحليل تجريبي empirical "لأحجام الأخطاء" على أساس قاعدة بيانات واسعة النطاق تكافئ استخدام منظومة برامجيات معينة آلاف السنين.

يساعد الاختلاف في التصميم على زيادة اعتمادية منظومات البرامجيات. وكل إصدار للبرنامج يتطور

بشكل مستقل بوساطة مجموعة تصميم مختلفة. يقرر الحَكَم المخرج الفعلي للمنظومة

باستخدام (على سبيل المثال) القيمة المتوسطة الناتجة من الإصدارات المختلفة أو القيمة "المنتخبة" بالأغلبية.

ويمكن أن يكون الحكم منظومة إضافية أخرى أو أن يتألف من تقانة غير حاسوبية مثل محفازات actuators هيدروليكية

كان الاكتشاف الأكثر عجبا أن نحو ثلث جميع الأخطاء التي وجدت كان من نوع أخطاء الـ 5000 سنة: أي يسبب كل خطأ منها فشلا واحدا فقط كل 5000 سنة تنفيذ تقريبا (اختلفت معدلات الأخطاء الأخرى بدرجة كبيرة). وقد شكلت تلك الأخطاء النادرة نسبة كبيرة من الأعطال، حيث إن الأخطاء المسببة لمعدلات عطل عالية قد اكتشفت، ومن ثم أزيلت مسبقا. إن أخطاء الـ 5000 سنة هي فقط التي ستجعل المنظومة غير موثوق بها، وإزالة واحد منها سيعطي تحسنا مهملا في الاعتمادية.

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

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

طبيعة عطل البرامجيات

اقتباس

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

ولمعرفة السبب نأخذ في الاعتبار جميع المدخلات الممكنة (تسمى فضاء المدخلات input space) التي يمكن للبرامجيات أن تصادفها أثناء عمرها (في الأعلى). إن المدخلات لعملية تشغيل البرامجيات هي مجموعة بيانات رقمية (أعداد) تقرأ من الوسط الخارجي ومن معلومات سبق تخزينها في ذاكرة الحاسوب. نشاهد في الشكل أعلاه فضاء المدخلات على بعدَيْ الصفحة المطبوعة ولكن عمليا يتكون هذا الفضاء من عدة أبعاد.

وهنا يحوي فضاء المدخلات ثلاث مناطق خلل مرقمة من 1 إلى 3. توجد المدخلات x في منطقة الخلل 2 وهذا يعني أن هذه المدخلات ستجعل البرنامج يعطي مخرجات غير مقبولة. ومن ناحية أخرى يمكن للبرنامج أن ينفذ بنجاح المدخلات y. التي لا تقع في أي منطقة خلل.

يُختبر البرنامج بتنفيذه باستخدام عدة مدخلات والتحقق في كل مرة من صحة النتائج. فإذا نتج جواب صحيح خلال الاختبار فإن هذا

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

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

لهذا يجب أن نحدد ما نعتقده حول سلوك العطل المستقبلي للبرنامج عن طريق الاحتمالات. ويمكننا أن نتساءل عن احتمال إمكانية بقاء البرنامج بدون عطل إذا نفذ على عدد محدد من المدخلات، أو يمكننا أن نسأل ما احتمال تسبب مدخل مختار عشوائيا في عطل ما. ويمكن تحويل كلا السؤالين بسهولة إلى قياس للاعتمادية مبني على الزمن. ونعني بذلك احتمال تنفيذ البرنامج بدقة لفترة زمنية محددة. وأخيرا نكون مجبرين على اعتبار عملية تتابع الأعطال لبرنامج ما عملية عشوائية كما هي الحال في المكونات المادية. لذا فإن استخدام مقياس اعتمادية مبني على الاحتمالات عملية حتمية.

وفي الواقع، إن مسألة تقدير الأمان أكثر خطورة من ذلك. وللحصول على أي قدر من الثقة في النتائج الرقمية، يجب أن نخضع البرنامج لحالات يمكن أن يصادفها في الواقع. وتضمن هذه الطريقة أن تقابل المدخلات المسببة للفشل بالتكرر frequency نفسه الذي يظهر في الواقع. إضافة إلى ذلك، فإن على المخْتَبِر أن يكون قادرا دوما على أن يقرر ما إذا كانت مخرجات البرنامج صحيحة. وتشبه هذه المشكلات تلك التي تحدث أثناء تصميم وتنفيذ البرامجيات ذاتها. ولتكوين بيئة اختبار دقيقة، يجب أن نتأكد من أننا قد فكرنا بالظروف كافة التي ستواجهها البرامجيات. وتماما كما تُعجِزنا أحيانا أقل الأشياء توقعا في تصميم المنظومة، فإن ذلك سيحدث أيضا في تصميم الاختبار. ومن الحكمة أيضا إبقاء نسبة من الشك حول مدى تمثيل الاختبار للواقع وبالتالي حول دقة الأرقام الناتجة.

سيكون المفاعل SIZEWELL B المفاعل الذري الأول

في المملكة المتحدة الذي يحوي كلتا المنظومتين التقليدية ومنظومة الحماية المؤسسة

على البرامجيات للتوقف الطارئ. ينتقد بعض الأشخاص تعقيد منظومات البرامجيات ـ الحاوية

مئات المعالجات الصغرية وأكثر من مئة ألف من الخطوط المكودة ـ التي تكوّن صعوبات لضمان

أمن المفاعل.

إن مشكلة إثبات الوثوقية الفائقة أو الأمان لأي وحدة برامجيات هي ببساطة نقص في المعرفة الضرورية. وبالنسبة للبرامجيات المعقدة فإن الحقيقة المرة هي وجود قيود صارمة على الثقة التي يمكن وضعها في البرنامج. إن مجرد مراقبة أداء البرنامج ليست الطريقةَ التي تؤكد لنا أنه سيعمل كما ينبغي لمدة 000 100سنة. فكيف لنا إذًا أن نحصل على مثل هذه الثقة؟.

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

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

ثمة طريقة أخرى (في تطبيقات التحكم في الطرق الجوية والسكك الحديدية مثلا) لتحقيق الاعتمادية العالية، ألا وهي طريقة سماحية الخطأ fault tolerance أو الحماية الفائضة protective redundancy. والطريقة النموذجية لتطبيق الحماية الفائضة هي تكوين فرق تصميم مختلفة تنتج عدة إصدارات للبرنامج. ويؤمل من ذلك أنه إذا أخطأت هذه الفرق فإن تلك الأخطاء ستكون مختلفة. وسيعطي كل إصدار من إصدارات البرنامج "رأيه" في المخرجات الصحيحة. تمرر المخرجات على مرحلة تحكيم ـ تسمى الحَكَم ـ تعطي مخرجا واحدا يكون صحيحا إذا أعطت معظم الإصدارات النتيجة الصحيحة.

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

لقياس اعتمادية البرامجيات السامحة بالخطأ، يجب معايرة gauge الارتباط الإحصائي statistical correlation بين أخطاء الإصدارات المختلفة. وللأسف، ستكون المهمة صعبة مثلما حدث عند محاولة قياس الاعتمادية باعتبار المنظومة وكأنها كيان واحد. وقد رأينا مدى صعوبة تحقيق ذلك.

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

هناك ثلاثة أساليب. أولها، أن تُصنف أنواع الفشل الناتج من التصميم كأخطاء "غير قابلة للقياس" ويُتجنّب تحديد متطلبات خاصة للبرامجيات. وتستعمل هذه الطريقة حاليا بشكل معقول. مثلا، في مجال الطيران المدني فإن النشرة الاستشارية للإدارة الاتحادية الجوية الأمريكية تصف "المقبول" بأنه ما يتماشى مع بعض تعليمات الطيران الاتحادي. وتنص النشرة على أن شروط الفشل المأساوي (وهو أسوأ الأنواع) في هذه الحالات تكون مستبعدة الحدوث لدرجة ألا نتوقعها خلال العمر التشغيلي operational life لجميع الطائرات ذات الطراز الواحد. والتعبير الكمي المقترح هو أن احتمال الفشل لا يزيد على 9-10 لكل ساعة طيران. وتُستثنى البرامجيات بوضوح من هذه النشرة حيث إنه "من غير الممكن تحديد عدد مرات أو نوع خلل البرامجيات، إن وجد، الذي قد يتبقى بعد إتمام تصميم المنظومة وتطويرها واختبارها."

وكذلك فإن الوثيقة الواسعة الانتشار في هيئة تقنية راديو علم الطيران RTCA/DO - 178A تتجنب وضع مقاييس للبرامجيات. وهذه الوثيقة، التي تعطي إرشادات للمصنعين الذين يطلبون شهادات من السلطات الجوية، ترفض بوضوح الاعتماد على عبارات كمية أو طرق لحساب اعتمادية البرامجيات أو مدى الأمان بها. وبدلا من ذلك فإن الوكالة تعتبر الطريقة الهندسية الصحيحة (إدارة حازمة ومراجعات واختبارات دقيقة وتحليل للأخطاء السابقة) أكثر أهمية من الطرق الكمية. والرسالة الأساسية لهذه الوكالة هي أنه "على المصممين أن يسلكوا سبلا منظمة في البرامجيات: تعريف المتطلبات والتصميم والتطوير والاختبار وإدارة الشكل العام configuration management والتوثيق." أي إن أفضل طريقة لضمان الاعتمادية هي التحقق من أن أقصى درجات الحذر قد استخدمت في التصميم.

ما مدى جودة هذا الضمان؟ نقول جدلا: ليس جيدا. فلا يوجد دليل على أن الطرق الفذة للتصميم والإنتاج ستعطي بالضرورة منتجا فذا. ولا يمكننا حتى أن نتأكد من أن أفضل الطرق المتداولة حاليا تنتج اعتمادية كافية للتطبيقات الأكثر تعقيدا.

إن تجنب وجود تقديرات كمية لأمان البرامجيات يضع قيودا شديدة على معظم المنظومات ذات الأخطار الكامنة لا سيما تلك المنظومات التي تحتاج إلى حساب شامل لتقدير المخاطر الاحتمالي probabilistic risk assessment قبل بدء التشغيل. يمكن التكهن بالاحتمالات إلى حد مقبول من الدقة للأعطال المادية الحاصلة من الإجهاد أو البلى. ولكن لا يمكن أن يُستَخدم هذا الحد من الدقة في الجهود المبذولة لحساب احتمال فشل المنظومة بأكملها (مكونات مادية وبرامجيات). حيث لا يكفي أن نقول إننا بذلنا ما في وسعنا لتلافي الأخطاء. إن الإلزام باستخدام ما يسمى "أحسن طريقة عملية" لا يمكن أن يحل المشكلة. ونحن نضيف بسرعة: إنه قد يكون من التهور ترك التقنيات المعروفة بتحسين الاعتمادية والأمان لمجرد أننا لا نعلم بالتحديد كم ستساعدنا. والمعيارية المشجعة على استخدام تلك التقنيات مفيدة لكنها لن تحل مشكلة معرفة وصول البرامجيات إلى درجة الأمان المطلوبة.

والأسلوب الثاني ـ وهو الأفضل في رأينا ـ يتطلب أن يكون تصميم المنظومة بحيث يكون دور البرامجيات فيها "ليس شديد الخطورة"، ومعنى "ليس شديد الخطورة" هو أن اعتمادية البرامجيات المطلوبة يجب أن تكون متواضعة إلى حد ما بحيث يمكننا إثبات الاعتمادية قبل استخدام المنظومة. ولقد طبقت هذه الطريقة على المفاعل النووي Sizewell B في المملكة المتحدة حيث احتمال الفشل المطلوب من منظومة الحماية المبنية على البرامجيات هو فقط 4-10.

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

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

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

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

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

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

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

المؤلفان

Bev Littlewood - Lorenzo Strigini

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

مراجع للاستزادة

EVALUATION OF SAFETY-CRITICAL SOFTWARE. David L. Parnas, A. John van Schouwen and Shu Po Kwan in Communications of the ACM, Vol. 33, No. 6, pages 636-648;June 1990.

SOFTWARE SAFETY IN EMBEDDED COMPUTER SYSTEMS. Nancy G. Leveson in Communications of the ACM, Vol. 34, No. 2, pages 34-46; February 1991.

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS. Moderated by Peter Neumann. Available as the usenet newsgroup comp.risks, or by request on the internet from

risks-request@csl.sri.com.

RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS. Regular column edited by Peter Neumann in Communications of the ACM.