معدل عيوب البرامج المضمنة

Question

ما هو معدل العيوب الذي يمكن أن أتوقعه في قاعدة تعليمات برمجية C++ المكتوبة لمعالج مضمن (DSP)، نظرًا لعدم وجود اختبارات وحدة، ولا مراجعات للكود، ولا تحليل للكود الثابت، وأن تجميع المشروع يولد حوالي 1500 تحذير.هل 5 عيوب/100 سطر من التعليمات البرمجية تقدير معقول؟

Answer 1

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

في هذه المقالة, يستشهد المؤلف بأرقام من "مجموعة كبيرة من الدراسات التجريبية" ، المنشورة في تقييمات البرمجيات والمعايير وأفضل الممارسات (جونز ، 2000). في SIE CMM المستوى 1, ، والذي يبدو وكأنه مستوى هذا الرمز ، يمكن للمرء أن يتوقع معدل عيب قدره 0.75 لكل نقطة الوظيفة. سأتركها لك لتحديد كيف نقاط الوظيفة وقد تتصل LOC في الكود الخاص بك - ربما ستحتاج إلى ملف أداة المقاييس لإجراء هذا التحليل.

ستيف ماكونيل في الكود الكامل يستشهد بالدراسة من بين 11 مشروعًا تم تطويره بواسطة نفس الفريق ، 5 بدون مراجعات رمز ، 6 مع مراجعات التعليمات البرمجية. كان معدل العيب للرمز غير المراجعة 4.5 لكل 100 loc ، وبالنسبة للمراجعة كان 0.82. لذلك على هذا الأساس ، يبدو تقديرك عادلاً في غياب أي معلومات أخرى. ومع ذلك ، يجب أن أفترض مستوى من الاحتراف بين هذا الفريق (فقط من حقيقة أنهم شعروا بالحاجة إلى إجراء الدراسة) ، وأنهم سيحضرون على الأقل التحذيرات ؛ يمكن أن يكون معدل عيبك أعلى بكثير.

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

Answer 2

سؤالك هو "هل 5 عيوب/100 سطر من الكود تقدير معقول؟" من الصعب للغاية الإجابة على هذا السؤال ، وهو يعتمد بشكل كبير على تعقيد Codebase و Code.

لقد ذكرت أيضًا في تعليق "لإظهار الإدارة أنه من المحتمل أن يكون هناك الكثير من الأخطاء في قاعدة الكود" - هذا رائع ، مجد ، على الفور.

من أجل فتح عيون الإدارة التصويرية ، أقترح على الأقل نهجًا من 3 ذبذبات:

• خذ تحذيرات محددة للمترجم ، وأوضح كيف يمكن أن يسبب بعضها سلوكًا غير محدد / كارثي. لن تكون كل التحذيرات ثقيلة. على سبيل المثال ، إذا كان لديك شخص يستخدم مؤشرًا غير ضروري ، فهذا ذهب نقي. إذا كان لديك شخص يقوم بحشو قيمة 16 بت غير موقعة في قيمة 8 بت غير موقعة ، ويمكن إثبات أن القيمة 16 بت ستكون دائمًا <= 255 ، وأن المرء لن يساعد في جعل قضيتك بقوة.
• تشغيل أداة تحليل ثابت. جهاز الكمبيوتر (أو FlexElint) رخيصة ويوفر "Bang for the Buck" جيدًا. من المؤكد أنه سيحصل على الأشياء التي لن يقوم عليها التحويل البرمجي ، ويمكن أن يعمل أيضًا عبر وحدات الترجمة (وابضة كل شيء معًا ، حتى مع تمريران أو أكثر) ويجد المزيد من الأخطاء الدقيقة. مرة أخرى ، استخدم بعضًا من هذه المؤشرات.
• قم بتشغيل أداة تعطي مقاييس أخرى على تعقيد الكود ، مصدر آخر من الأخطاء. أوصي M spined's Resource Standard Metrics (RSM) مما سيمنحك المزيد من المعلومات والمقاييس (بما في ذلك تعقيد الكود) مما يمكن أن تأمل فيه. عندما تخبر الإدارة بذلك درجة التعقيد أكثر ولديك درجة 200 في روتين واحد ، يجب أن تفتح بعض العيون.

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

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

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

حظا طيبا وفقك الله!

Answer 3

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

رمز منظم بشكل جيد بأسلوب متسق ومن السهل فهمه سيحتوي على مشاكل أقل. يوضح الكود مقدار الجهد والتفكير الذي ذهب إليه.

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

Answer 4

هذا يعتمد أيضًا على من كتب الكود (مستوى الخبرة) ، ومدى حجم الكود.

سأتعامل مع جميع التحذيرات كخطايا.

كم عدد الأخطاء التي تحصل عليها عند تشغيل أداة تحليل ثابت على الكود؟

تعديل

قم بتشغيل CCCC ، وتحقق من تعقيد McCabe الدوري. يجب أن تخبر مدى تعقيد الكود.

http://sourceforge.net/projects/cccc/

تشغيل أدوات تحليل ثابتة أخرى.

Answer 5

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

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

Answer 6

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

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

Answer 7

تحتوي المقالة التالية على بعض الأرقام بناءً على مشاريع الحياة الواقعية التي تم تطبيق تحليل ثابت عليها: http://www.stsc.hill.af.mil/crosstalk/2003/11/0311german.html

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