مراجعة البرامج

مراجعة البرمجيات هي "عملية أو اجتماع يتم خلاله فحص منتج برمجي من قبل موظفي المشروع أو المديرين أو المستخدمين أو العملاء أو ممثلي المستخدمين أو غيرهم من الأطراف المعنية للحصول على تعليقاتهم أو موافقتهم". ^{[ 1 ]}

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

يمكن تقسيم مراجعات البرامج إلى ثلاث فئات:

• تُجرى مراجعات النظراء للبرمجيات من قبل واحد أو أكثر من زملاء المؤلف، لتقييم المحتوى التقني و/أو جودة العمل. ^{[ 2 ]}
• تُجرى مراجعات إدارة البرمجيات من قبل ممثلي الإدارة لتقييم حالة العمل المنجز واتخاذ القرارات المتعلقة بالأنشطة اللاحقة.
• تُجرى مراجعات تدقيق البرامج بواسطة موظفين من خارج مشروع البرنامج، لتقييم مدى الامتثال للمواصفات والمعايير والاتفاقيات التعاقدية أو المعايير الأخرى.

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

تُحدد "الرسمية" مدى خضوع نشاط ما لقواعد متفق عليها (مكتوبة). وتتفاوت عمليات مراجعة البرمجيات في درجة رسميتها، حيث تتراوح بين أنشطة غير منظمة نسبيًا مثل "مراجعة الزملاء" في أحد طرفي الطيف، وأساليب أكثر رسمية مثل الجولات التفقدية والمراجعات الفنية وعمليات فحص البرمجيات في الطرف الآخر. يُحدد معيار IEEE 1028-1997 الهياكل والأدوار والعمليات الرسمية لكل من المراجعات الرسمية الثلاث الأخيرة ("مراجعات النظراء الرسمية")، بالإضافة إلى عمليات تدقيق البرمجيات . ^{[ 1 ]} وقد حلّ معيار IEEE 1028-2008 محل معيار IEEE 1028-1997. ^{[ 3 ]}

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

يُحدد معيار IEEE 1028 مجموعةً مشتركةً من الأنشطة للمراجعات "الرسمية" (مع بعض الاختلافات، خاصةً فيما يتعلق بتدقيق البرمجيات). ويُفرّق هذا المعيار بين مراجعة الإدارة ، والمراجعة الفنية ، والتفتيش ، والجولات التفقدية ، والتدقيق ، وما إلى ذلك.

يعتمد التسلسل المحدد للأنشطة القياسية إلى حد كبير على عملية فحص البرمجيات التي طورها مايكل فاجان في شركة IBM . ^{[ 4 ]} قد تطبق أنواع مختلفة من المراجعات هذا الهيكل بدرجات متفاوتة من الدقة، ولكن جميع الأنشطة إلزامية للفحص:

• 0. [تقييم المدخلات]: يستخدم قائد المراجعة قائمة مرجعية قياسية لمعايير الدخول لضمان وجود الظروف المثلى لإجراء مراجعة ناجحة.
• 1. إعداد الإدارة: تضمن الإدارة المسؤولة أن يتم تزويد المراجعة بالموارد المناسبة من الموظفين والوقت والمواد والأدوات، وأن يتم إجراؤها وفقًا للسياسات والمعايير أو المعايير الأخرى ذات الصلة.
• 2. تخطيط المراجعة: يقوم قائد المراجعة بتحديد أو تأكيد أهداف المراجعة، وتنظيم فريق من المراجعين، والتأكد من تزويد الفريق بجميع الموارد اللازمة لإجراء المراجعة.
• 3. نظرة عامة على إجراءات المراجعة: يضمن قائد المراجعة، أو أي شخص مؤهل آخر، (في اجتماع إذا لزم الأمر) أن جميع المراجعين يفهمون أهداف المراجعة وإجراءاتها والمواد المتاحة لهم وإجراءات إجراء المراجعة.
• 4. التحضير [الفردي]: يقوم المراجعون بشكل فردي بالتحضير للفحص الجماعي للعمل قيد المراجعة، من خلال فحصه بعناية بحثًا عن "الشذوذات" (العيوب المحتملة)، والتي ستختلف طبيعتها باختلاف نوع المراجعة وأهدافها.
• 5. [الفحص الجماعي]: يجتمع المراجعون في وقت محدد لجمع نتائج نشاطهم التحضيري والتوصل إلى توافق في الآراء بشأن حالة المستند (أو النشاط) الذي تتم مراجعته.
• ٦- إعادة العمل/المتابعة: يقوم مؤلف العمل (أو أي شخص آخر مُكلّف) باتخاذ الإجراءات اللازمة لإصلاح العيوب أو استيفاء المتطلبات المتفق عليها في اجتماع المراجعة. ويتأكد رئيس فريق المراجعة من إنجاز جميع بنود العمل.
• 7. [تقييم الخروج]: يتحقق قائد المراجعة من أن جميع الأنشطة اللازمة للمراجعة الناجحة قد تم إنجازها وأن جميع المخرجات المناسبة لنوع المراجعة قد تم الانتهاء منها.

تتمثل القيمة الأبرز لمراجعات البرمجيات (وخاصةً المراجعات الرسمية) في قدرتها على تحديد المشكلات مبكرًا وبتكلفة أقل بكثير مما لو تم اكتشافها من خلال الاختبار أو الاستخدام الميداني (عملية اكتشاف العيوب). ^{[ 5 ]} قد تكون تكلفة اكتشاف عيب ما وإصلاحه من خلال مراجعة مُحكمة أقل بمقدار عشرة أو مئة ضعف من تكلفة اكتشافه من خلال الاختبار أو الاستخدام الميداني.

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

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

كقاعدة عامة، كلما تم إعداد وثيقة فنية في وقت مبكر، زاد تأثير عيوبها على الأنشطة اللاحقة ومنتجاتها. وعليه، فإنّ أكبر فائدة تتحقق من المراجعات المبكرة لوثائق مثل خطط التسويق، والعقود، وخطط المشاريع وجداولها الزمنية، ومواصفات المتطلبات. وقد أثبت الباحثون والممارسون فعالية عملية المراجعة في اكتشاف الأخطاء والمشاكل الأمنية. ^{[ 6 ]}

• جودة البرمجيات
• قائمة فلسفات تطوير البرمجيات