ScholarGate
المساعد

بناء البرمجيات وجودتها

يتعلق بناء البرمجيات وجودتها بالإنشاء المنضبط لتعليمات برمجية عاملة والتقنيات — الاختبار، والتحقق، والمراجعة، والقياس — التي تؤسس وتضمن أن البرنامج يلبي متطلباته وأهدافه النوعية.

اعثر على موضوع باستخدام PaperMindقريبًاFind papers & topics
Tools & resources
تنزيل الشرائح
Learn & explore
فيديوقريبًا

Definition

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

Scope

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

Sub-topics

Core questions

  • ما هي الممارسات التي تنتج تعليمات برمجية صحيحة، قابلة للقراءة، وقابلة للصيانة؟
  • كيف يتم اكتشاف العيوب من خلال الاختبار والمراجعة والتحليل؟
  • كيف يتم تعريف جودة البرمجيات وقياسها وضمانها؟
  • متى يمكن إثبات الصحة بالبرهان الرسمي بدلاً من الاختبار وحده؟

Key theories

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

Clinical relevance

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

Evidence & guidelines

يحدد المعيار ISO/IEC 25010 نموذج جودة منتج البرمجيات، وتوفر مجالات المعرفة SWEBOK حول بناء البرمجيات واختبارها وجودتها إرشادات مرجعية متفق عليها.

History

تم توضيح الاختبار المنهجي بواسطة مايرز في السبعينيات، والبرمجة المنظمة والتحقق بواسطة دايجسترا وهوار في نفس الحقبة، وحرفية البناء بواسطة ماكونيل في التسعينيات؛ وقد عززت نماذج ومعايير الجودة مثل ISO/IEC 25010 سمات الجودة وقياسها.

Debates

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

Key figures

  • Glenford Myers
  • Steve McConnell
  • C. A. R. Hoare
  • Edsger Dijkstra

Related topics

Seminal works

  • myers2011
  • mcconnell2004
  • swebok2014

Frequently asked questions

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

Methods for this concept

Related concepts