1. المقدمة

يُعد تحديدُ مجموعة المعارف القابلة للتطبيق والمتعلقة بالموثوقية الخطوةَ الأولى في تزويد مهندسي البرمجيات بالمهارات الأساسية لبناء برامج عالية الموثوقية.

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

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

• يوفِّر الكشفُ المبكر عن مشكلات الموثوقية وحلُّها قدرًا كبيرًا من الوقت والمال في تطوير البرامج.
• يؤدي دمج قياسات المنتَج والعملية إلى إمكان تقييم التفاعل بينهما طوال دورة الحياة.
• لا بد أن يكون مهندسو البرمجيات على دراية شاملة بدور القياس في المساهمة في تطوير منتجاتٍ عاليةِ الموثوقية والعمليات التي تنتجها.

يمكن الحصول على بعض المعارف المطلوبة بواسطة التعليم الرسمي، على حين أنه لا يمكن الحصول على بعضها الآخر إلا بالخبرة أثناء العمل.

نستعمل في هذه المقالة المعايير المعمول بها باعتبارها موردًا آخر لاشتقاق متطلبات المعرفة، ونركِّز على مجالات المعرفة حيث توجد أكبر فجوة بين المعرفة القائمة واستعمال هذه المعرفة من مهندسي البرمجيات الممارسين، لأن هذه المجالات هي في الغالب ذات طبيعة كمية.

 2. طرق توصيف متطلبات المعرفة

ثمة طريقتان لتحديد المعرفة المطلوبة لتخطيط وتنفيذ موثوقية البرامج؛ هما: النهج الموجَّه على القضايا issue oriented، والنهج الموجَّه نحو مرحلة دورة الحياة life cycle phase oriented. وهذان النهجان متوافقان، لكنهما مختلفان في وجهات النظر لتحقيق نفس الهدف. وقد جرى عرض هذه الآراء لتوضِّح لمهندس البرمجيات لماذا نحتاج إلى القياس، ومتى تنشأ الحاجة إليه.

3. النهج الموجَّه على القضايا

تنشأ القضايا بسبب وجود اعتبارات هامة في تحقيق أهداف موثوقية البرامج بتكلفة مقبولة. وباستعمال هذا النهج تظهر العلاقات بين القضايا والوظائف ومتطلبات المعرفة في الجدول 1. يوضح هذا الجدول بعض الوظائف المهمة التي يمكن أن يؤديها مهندس البرمجيات في تنفيذ خطة لإدارة موثوقية موجَّهة نحو المسائل الواردة في العمود الأول. وهذا الجدول ليس شاملًا.

القضية Issue	الوظيفة Function	المعرفة Knowledge
.1 الأهداف: ما هي أهداف الموثوقية المحددة للنظام؟	تحليل أهداف الموثوقية وتحديد متطلبات الموثوقية	هندسة الموثوقية المتطلبات الهندسية
.2التكلفة والمخاطر: ما هي تكلفة تحقيق أهداف الموثوقية، وخطر عدم القيام بذلك؟	تقييم اقتصادي ومخاطر أهداف الموثوقية	التحليل الاقتصادي تحليل المخاطر
.3 السياق: ما هو التطبيق والهيكل التنظيمي الذي يدعمه النظام والبرمجيات؟	تحليل بيئة التطبيق	تحليل النظم تصميم البرمجيات
.4الملف التشغيلي: ما مدى أهمية وتكرار استعمال مكونات البرنامج؟	تحليل بيئة البرنامج	الاحتمالات التحليل الاحصائي
.5 النماذج: ما هي جدوى إنشاء أو استعمال نموذج موثوقية حالي للتقييم والتنبؤ، وكيف يمكن التحقق من صحة النموذج؟	موثوقية النموذج والتحقق من صحته	الاحتمالات النماذج الإحصائية
.6متطلبات البيانات: ما هي البيانات المطلوبة لدعم أهداف الموثوقية؟	تحديد نوع البيانات والمرحلة والوقت وتكرار جمعها	تحليل البيانات
7. أنواع القياسات ومدى تفصيلها: ما هي مقاييس القياس التي ينبغي استعمالها، وما هو مستوى التفاصيل المناسب لتحقيق هدف معين، وما الذي يمكن قياسه كميًّا أو نوعيًّا أو تقديريًّا ؟	تحديد الخصائص الإحصائية للبيانات	نظرية القياس
8. اختبار وتقييم المنتج والعملية: كيف يمكن لقياسات موثوقية المنتج أن تدعم تحسين جودة العملية؟	تحليل العلاقة بين موثوقية المنتَج واستقرار العملية	التفتيش وطرق الاختبار
9. موثوقية المنتج وتوقع جودة العملية: ما هي أنواع التنبؤات التي يجب القيام بها؟	تقييم وتنبؤ موثوقية المنتج وجودة العملية	أدوات القياس

الجدول 1: متطلبات المعرفة في قياس موثوقية البرامج

 4. توصيف وظائف القياس ومتطلبات المعرفة

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

1.4. القضية الأولى، الأهداف

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

• هندسة الموثوقية: يتم تحديد المقاييس ووضع خطط لجمع البيانات لتحقيق أهداف الموثوقية. يجري تحديد معايير قياس وتفسير التوافق مع متطلبات الموثوقية أثناء الفحص والاختبار، ويمكن العثور على منهجية كاملة لتنفيذ خطة مقاييس جودة البرنامج (الموثوقية مثلًا) في منظمة ما في المعيار  IEEE Standard 1061 ][IEE98.
• المتطلبات الهندسية: أحد العوامل في تحديد المتطلبات هو تقييم مخاطر إدخال متطلب جديد في النظام أو تغيير أحد المتطلبات الحالية. المخاطر موجودة لأن إدخال التغيير قد يقلل من موثوقية البرنامج وقابليته للصيانة. على سبيل المثال، تقوم منظمة NASA بإجراء تحليل مخاطر على جميع التغييرات في المتطلبات. لتقييم مخاطر التغيير، يستعمل مطوِّر البرمجيات المتعاقَد معه عددًا من عوامل الخطر؛ مثل: حجم وموقع التغيير، وأهمية التغيير، وعدد تعديلات التغيير، والموارد المطلوبة لإجراء التغيير (ومن ذلك الأفراد والأدوات). ولا يوافق مجلس التحكم على التغيير في المتطلبات دون إجراء تقييم مخاطر مصاحب، وذلك لكشف العيوب في المتطلبات.

2.4. القضية الثانية، التكلفة والمخاطر

على سبيل المثال، سوف نقيم المقايضة بين الزيادات في مستويات الموثوقية وزيادة في الاختبارات، وهو ما من شأنه أن يزيد من تكاليف الاختبار.

• التحليل الاقتصادي: من الأخطاء الشائعة في التحليل الاقتصادي لأنظمة البرمجيات قَصْرُ التقييم على التكلفة الإجمالية. أحد المعايير المهمة هو التكلفة الحدية فيما يتعلق بالفائدة الحدية التي تتراكم بإضافة زيادة في الموثوقية إلى البرنامج. على سبيل المثال، تتضمن مقارنة الزيادة الهامشية في الموثوقية التي نحصل عليها بزيادة الاختبار مع الزيادة الهامشية في تكلفة الاختبار. ومن الناحية النظرية يمكن أن يتوقف الاختبار عندما تتساوى الكميتان. ومع ذلك، ونظرًا لأنه من الصعب تحويل الزيادات في الموثوقية إلى أموال فإننا نستعمل المعيار )RCR( Reliability Cost Ratio وهو الحد الأقصى لنسبة الزيادة النسبية في الموثوقية إلى الزيادة النسبية في تكلفة الاختبار، ويستمر الاختبار حتى يتم تحقيق هذا المعيار.
• تحليل المخاطر: قد يكون معيار RCR غير كافٍ لبعض الأنظمة في نظام السلامة الحرج. على سبيل المثال، قد يكون من الضروري تحقيق مستوى موثوقية أعلى. في هذه الحالة قد تُستدعى معايير المخاطر الإضافية. إذا حددنا هدف الموثوقية الخاص بنا على أنه تقليل حالات الإخفاق التي قد تؤدي إلى خسائر في الأرواح أو فقدان المهمة أو إجهاض المهمة إلى مستوى مقبول من المخاطر، فعندئذٍ يكون البرنامج جاهزًا للنشر؛ بعد اختباره للوقت الإجمالي؛ وبعد استيفاء المعايير التالية [SCH971]:

-الأعطال المتبقية المتوقعة r(t) < r_c                                   (1) 

        حيث r_c قيمة حرجة محددة.

-الوقت المتوقع للإخفاق التالي  t_F(t) > t_m                                      (2)

        حيث t_m مدة المهمة.

إذا لم يُسْتَوْفَ المعياران (1) و(2) بعد الاختبار لمدة t، فإننا نواصل الاختبار حتى يتم استيفاؤهما أو إلى أن يصبح الاستمرار في الاختبار غير مجدٍ اقتصاديًّا.

3.4. القضية الثالثة، السياق

تتضمن هذه الوظيفة تحليل مجال التطبيق وتحديده وتصنيفه (على سبيل المثال: نظام السلامة الحرجة، منتَج COTS)، ويترتب على مجال التطبيق آثار بالنسبة لمتطلبات الموثوقية. قد تكون الموثوقية والأمان من الاعتبارات الرئيسية لنظام السلامة الحرج، في حين أن وقت الوصول إلى السوق يمكن أن يكون الاعتبارَ الرئيسيَّ لمنتَج COTS مع الموثوقية التي يكون لها دور أقل.

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

4.4. القضية الرابعة، الملف التشغيلي

ملف التعريف التشغيلي هو مجموعة العمليات التي يمكن للبرنامج تنفيذها جنبًا إلى جنب مع احتمالات حدوثها LYU96][. يُعد ملف التعريف التشغيلي مفهومًا مفيدًا لاستعماله في تحديد أهداف الموثوقية وقياس مدى الوفاء بها أثناء التشغيل. يتيح ملف التعريف التشغيلي لمهندسي البرمجيات تحديدَ العمليات ومدى أهميتها ومعدل التكرار النسبي لحدوثها.

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

5.4. القضية الخامسة، النماذج

النموذج هو تمثيل لعملية أو جهاز أو مفهوم في العالم الحقيقي [IEE96]. يتضمن التحقق من صحة النموذج إثباتًا بأثر رجعي أنه يتوقع باستمرار القيم الفعلية بدقة مقبولة. كمثال على تطوير نموذج الموثوقية، يمكن إنجاز هذا في نشاطين هما: التحقق من الصحة، والتطبيق. وكلا النشاطين يحدث أثناء تطوير البرمجيات. أثناء التحقق من الصحة نحدد المقاييس التي ستُستعمل للحكم على موثوقية البرنامج المُنتَج، وأثناء التطبيق نلاحظ إذا كان أحد مقاييس الوحدة على الأقل له قيمة تتجاوز قيمته الحرجة (على سبيل المثال قيمة عتبة الحجم أو التعقيد)، فيجري تحديد مشاكل الموثوقية وتصحيحها أثناء التطوير بحيث يمكن تسليم منتَجٍ عالي الموثوقية للصيانة، بدلًا من الانتظار حتى الصيانة عندما تكون تكلفة التصحيح عالية.

• الاحتمالات والنماذج الإحصائية: تنقسم نماذج قياس البرامج إلى فئتين رئيسيتين هما: النماذج الاحتمالية لتنبؤ الموثوقية، والنماذج الإحصائية التي تَستعمل مقاييس جودة البرامج كمتنبئات للجودة. تَستعمل النماذج الاحتمالية بيانات الإخفاق التاريخية لتقدير معلمات النموذج التي تتعلق بمعدل الإخفاق الأولي ومعدل التغيير في معدل الإخفاق، وبمجرد بناء النموذج يُستعمل للتنبؤ بكميات الموثوقية المستقبلية مثل الإخفاقات المتبقية ووقت الإخفاق التالي [SCH971]. تَستعمل النماذج الإحصائية خصائصَ البرنامج؛ مثل حجم وبنية الكود للتنبؤ بعوامل الجودة، مثل عدد العيوب.

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

6.4. القضية السادسة، متطلبات البيانات

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

• تحليل البيانات: ثمة حاجة إلى مهارات في الإحصاء الوصفي (حساب المتوسط والانحراف المعياري والوسيط والمدى وما إلى ذلك) وفي تحليل التوزيعات (هل البيانات موزعة توزيعًا أسيًّا أم طبيعيًّا؟ وما إلى ذلك).

7.4. القضية السابعة، أنواع القياسات ومدى تفصيلها

إن مفهومَ مقاييس القياس مهمٌّ عند إجراء تقييم لبيانات البرمجيات ][ZUS98، على سبيل المثال يمكن تقييم وحدات البرامج على المقاييس التالية:

الاسمية: موثوقية عالية أو منخفضة

ترتيبي: الوحدة A لديها موثوقية أعلى من الوحدة B

الفاصل الزمني: الفرق بين موثوقية الوحدتين A وB، خطأ واحد لكل KLOC

النسبة: موثوقية الوحدة A هي ضعف موثوقية الوحدةB

أظهرت التجربة أن معظم قياسات البرامج مناسبة فقط للمقاييس الاسمية والترتيبية، والسبب في ذلك هو أن بيانات قياس البرامج غالبًا ما تكون متفرقة ومنفصلة ولديها تنوع كبير وتفتقر إلى تعريفات وتفاصيل البيئة والتطبيقات التي جُمعت فيها البيانات. وبوجه عام لا توجد البيانات على نطاق مستمر، ومن ثَم فإن أفضل ما يمكننا فعله - في كثير من الحالات - هو وضع البيانات في فئات (مقياس اسمي) أو ترتيبها (مقياس ترتيبي) [SCH972].

8.4. القضية الثامنة، اختبار وتقييم المنتج والعملية

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

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

9.4. القضية التاسعة، موثوقية المنتج وتوقع جودة العملية

تُقيَّم بيانات الإخفاق التاريخية وتوقع الموثوقية المستقبلية من أجل تقييم مخاطر عدم الوفاء بوقت الإخفاق ومتطلبات الإخفاق المتبقية. إذا كانت هذه التنبؤات غير مواتية فهي تدل على منتَج عالي الخطورة وعملية تحتاج إلى الإصلاح SCH971][.

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

 5. النهج الموجَّه نحو مرحلة دورة الحياة

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

الشكل 1: توصيف قياسات دورة الحياة [SCH972]

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

 6. الملخص

عرضنا في هذا المقال المجموعة الأساسية للمعرفة في قياس البرامج باستعمالِ نهجٍ موجَّه نحو القضايا ونهج موجَّه نحو مرحلة دورة الحياة، يعالج الأول مشاكل القياس الرئيسية في صناعة البرمجيات، ويضع الأخير القياس في منظور زمني للمشروع.

وظائف القياس التي تم تحديدها هي: تحليل الأهداف وتحديد المتطلبات، والتقييم الاقتصادي ومخاطر الأهداف، وتحليل بيئة التطبيق والبرنامج، والتحقق من صحة النماذج، وتحديد نوع البيانات وخصائصها، وتحليل وتقييم وتنبؤ العلاقة بين المنتج والعملية.

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