المواصفات من خلال المثال

📅 آخر تحديث: ٢٤ يوليو ٢٠٢٦
✍️ نُشر في: ٢٤ يوليو ٢٠٢٦
الموسوعة الحرة

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

يُعرف التحديد عن طريق المثال أيضًا باسم التطوير القائم على المثال، والمتطلبات القابلة للتنفيذ، والتطوير القائم على اختبار القبول (ATDD [ 2 ] أو A-TDD [ 3 ] )، واختبار القبول الرشيق، [ 4 ] والمتطلبات القائمة على الاختبار (TDR).

المزايا

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

الأمثلة كمصدر وحيد للحقيقة

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

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

الممارسات الرئيسية

الفرق التي تطبق المواصفات من خلال الأمثلة بنجاح تطبق عادةً أنماط العمليات التالية: [ 1 ]

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

عادةً ما تقضي فرق تطوير البرمجيات التي تطبق منهجية تحديد المواصفات بالأمثلة ضمن إطار عمل سكروم ما بين 5% إلى 10% من وقتها في تحسين قائمة مهام المنتج، بما في ذلك تحديد المواصفات بشكل تعاوني، وتوضيح المتطلبات باستخدام الأمثلة، وتحسين هذه الأمثلة. [ 3 ]

مثال على التعيين

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

قابلية التطبيق

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

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

تاريخ

يُعد مشروع WyCash+، الذي وصفه وارد كانينغهام في ورقة بحثية بعنوان "لغة الأنماط للتطوير التنافسي" [ 7 ] [ 8 ] في عام 1996، أول استخدام موثق للأمثلة الواقعية كمصدر وحيد للحقيقة، والمتطلبات، والاختبارات الآلية، في مشاريع البرمجيات. وقد صاغ مارتن فاولر مصطلح "المواصفات بالمثال" في عام 2004. [ 9 ]

يُعدّ التحديد عن طريق المثال تطورًا لممارسة اختبار العميل [ 10 ] للبرمجة المتطرفة المقترحة حوالي عام 1997 وفكرة اللغة المنتشرة [ 11 ] من تصميم المجال الموجه من عام 2004، باستخدام فكرة اختبارات الصندوق الأسود كمتطلبات وصفها وينبرغ وجاوس [ 12 ] في عام 1989.

الأتمتة

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

مراجع

  1. 1 2 3 4 5 أدزيك، جويكو (2011). المواصفات بالأمثلة: كيف تُقدّم الفرق الناجحة البرمجيات المناسبة . مانينغ. ISBN 9781617290084.
  2. ↑ بو، كين (2011). تطوير البرمجيات الرشيق الموجه باختبارات القبول: برمجيات أفضل من خلال التعاون: قصة تطوير البرمجيات الرشيق الموجه باختبارات القبول . أديسون ويسلي. ISBN 978-0-321-71408-4.
  3. 1 2 3 لارمان، كريج؛ فود، باس (2010). ممارسات لتوسيع نطاق تطوير البرمجيات الرشيقة والمرنة: تطوير المنتجات على نطاق واسع، وفي مواقع متعددة، وخارجية باستخدام سكروم واسع النطاق . بيرسون. ISBN 978-0-321-63640-9.
  4. 1 2 أدزيتش، جويكو (2009). سد فجوة التواصل: المواصفات من خلال المثال واختبار القبول الرشيق . نيوري. ISBN 978-0-9556836-1-9.
  5. ↑ وين، مات (8 ديسمبر 2015). "تقديم رسم الخرائط النموذجية" . مدونة كيوكمبر . تم الاطلاع عليه في 10 مايو 2021 .
  6. ↑ كريسبين، ليزا ؛ غريغوري، جانيت (2008). اختبار البرمجيات الرشيقة: دليل عملي للمختبرين وفرق العمل الرشيقة . أديسون ويسلي. ISBN 978-0-321-53446-0.
  7. ↑ لغات أنماط تصميم البرامج 2. أديسون-ويسلي. 1996. ISBN 978-0-201-89527-8.
  8. ↑ وارد كانينغهام. "حلقات: لغة نمطية للتطوير التنافسي - الجزء الأول" . C2.com . تم الاطلاع عليه بتاريخ 8 يناير 2014 .
  9. ↑ مارتن فاولر، ١٨ مارس ٢٠٠٤ (٢٠٠٤-٠٣-١٨). "المواصفات بالمثال" . Martinfowler.com . تاريخ الاسترجاع: ٢٠١٤-٠١-٠٨ .{{cite web}}: صيانة CS1: الأسماء الرقمية: قائمة المؤلفين ( رابط )
  10. ↑ بيك، ك. (1999). شرح البرمجة المتطرفة: تقبّل التغيير . أديسون-ويسلي. ISBN 978-0-321-27865-4.
  11. ↑ إيفانز، إريك (2004). تصميم قائم على المجال: معالجة التعقيد في صميم البرمجيات . أديسون-ويسلي. ISBN 0-321-12521-5.
  12. ↑ واينبرغ، جيرالد ؛ غوز، دونالد (1989). استكشاف المتطلبات: الجودة قبل التصميم . دار دورست هاوس. ISBN 0-932633-13-7.