التحقق من صحة البرامج والتحقق من صحتها

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

يمكن أيضًا إخضاع مخرجات كل مرحلة من مراحل عملية تطوير البرمجيات للتحقق عند مقارنتها بمواصفات الإدخال الخاصة بها (انظر التعريف الوارد في CMMI أدناه).

أمثلة على التحقق من صحة القطع الأثرية:

• مقارنة مواصفات التصميم بمواصفات المتطلبات: هل تقوم مواصفات التصميم المعماري والتصميم التفصيلي ونموذج قاعدة البيانات المنطقي بتنفيذ مواصفات المتطلبات الوظيفية وغير الوظيفية بشكل صحيح؟
• من بين عناصر البناء التي تقارن بمواصفات التصميم: هل يقوم كل من الكود المصدري وواجهات المستخدم والنموذج المادي لقاعدة البيانات بتنفيذ مواصفات التصميم بشكل صحيح؟

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

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

ينبغي التحقق من صحة المتطلبات قبل أن يصبح منتج البرمجيات ككل جاهزًا (تتطلب عملية تطوير الشلال تحديدها بشكل مثالي قبل بدء التصميم؛ لكن عمليات التطوير التكرارية لا تتطلب ذلك وتسمح بتحسينها المستمر).

أمثلة على التحقق من صحة القطع الأثرية:

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

وفقًا لنموذج نضج القدرات (CMMI-SW v1.1)، ^{[ 2 ]}

• التحقق من صحة البرمجيات: عملية تقييم البرمجيات أثناء أو في نهاية عملية التطوير لتحديد ما إذا كانت تفي بالمتطلبات المحددة. [IEEE-STD-610]
• التحقق من البرمجيات: عملية تقييم البرمجيات لتحديد ما إذا كانت منتجات مرحلة تطوير معينة تفي بالشروط المفروضة في بداية تلك المرحلة. [IEEE-STD-610]

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

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

استخدمت هذه المقالة التعريف الدقيق أو الضيق للتحقق.

من منظور الاختبار:

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

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

يستمد نظام التحقق والتدقيق المستقل (ISVV) من تطبيق نظام التحقق والتدقيق المستقل (IV&V) على البرمجيات. يعود تاريخ التطبيق المبكر لنظام ISVV (كما هو معروف اليوم) إلى أوائل سبعينيات القرن الماضي، عندما رعى الجيش الأمريكي أول برنامج هام متعلق بنظام IV&V لنظام سيفغارد المضاد للصواريخ الباليستية . ^{[ 6 ]} ومن الأمثلة الأخرى برنامج IV&V التابع لوكالة ناسا، والذي أُنشئ عام 1993. ^{[ 7 ]}

بحلول نهاية سبعينيات القرن العشرين، اكتسبت تقنية التحقق والتدقيق المستقل (IV&V) شعبية متزايدة. وقد أدى التزايد المستمر في تعقيد البرمجيات وحجمها وأهميتها إلى زيادة الطلب على تطبيق تقنية التحقق والتدقيق المستقل عليها.

^{في غضون ذلك ، ترسخت منهجية التحقق والتدقيق المستقل} (IV&V) (وISVV لأنظمة البرمجيات) وأصبحت تُستخدم على نطاق واسع من قبل منظمات مثل وزارة الدفاع الأمريكية ، وإدارة الطيران الفيدرالية ^، ووكالة ^ناسا ، ^{ووكالة الفضاء} الأوروبية ^. وقد ^ذُكرت منهجية التحقق والتدقيق المستقل في ^معيار DO-178B ، ومعيار ISO/IEC 12207 ، وتمّ إضفاء الطابع الرسمي عليها في معيار IEEE 1012 .

يتكون نظام ISVV عادةً من خمس مراحل رئيسية، ويمكن تنفيذ هذه المراحل بالتتابع أو كنتيجة لعملية التخصيص.