|  |
| --- |
| جزء من سلسلة مقالات حول |
| عملية تطوير البرمجيات |
|  |
| نشاطات رئيسة
* التطوير
* التحليل
* التصميم
* البناء
* الفحص
* تتبع الأخطاء
* النشر
* صيانة البرمجيات
 |
| نماذج العمل
* هندسة البرمجيات
* أجايل
* تصميم الغرفة النظيفة
* تطوير متكرر وتصاعدي
* صناعة النماذج الأولية
	+ النموذج اللولبي
	+ نموذج V
	+ نموذج الشلال
 |
| منهجيات التطوير وأُطُره
* تطوير البرمجيات المُتكيِّف  (ASD)
* ديف أوبس (DevOps)
* التوصيل المنضبط وفق أجايل  (DAD)
* طريقة تطوير النظم الديناميكية (DSDM)
* تطوير مقاد
	+ بالميزات  (FDD)
	+ بالنموذج  (MDD)
* التطوير المتكرر والتصاعدي (IID)
* كانبان (Kanban)
* تطوير برمجيات مرن
* إطار عمل حلول مايكروسوفت  (MSF)
* تطوير التطبيقات السريع (RAD)
* إطار عمل أجايل المُتدرِّج  (SAFe)
* سكرم (Scrum)
* سيمات (SEMAT)
* عملية البرمجة
	+ الفردية (PSP)
	+ الجماعية  (TSP)
* عملية التطوير المُوحَّدة (UP)
	+ لراشيونال (RUP)
* المفتوحة  (OpenUP)
* البرمجة القصوى (XP)
 |
| اختصاصات داعمة
* إدارة التهيئة
* التوثيق
* ضمان الجودة
* إدارة المشروع
* تصميم تجربة المستخدم
 |
| تطبيقات بالممارسة
* تطوير مقاد
	+ بالاختبار (TDD)
	+ باختبار القبول  (ATDD)
	+ بالسلوك (BDD)
* الإدماج المُستمِر (CI)
* تسليم مستمر (CD)
* تصميم مقاد بالنطاق (DDD)
* برمجة زوجية (PP)
* بالأمثلة (SBE)
* اجتماع وقوفاً
 |
| أدوات
* المُحوِّل
* المُنقِّح
* مُنمِّط
* باني واجهة المستخدم الرسومية
* أداة نمذجة
* بيئة التطوير المُتكامِلة (IDE)
* أتمتة بناء البرمجيات
* أتمتة إصدارات التطبيق
* البنية التحتية بصيغة نص برمجي
* الاختبار
 |
| منظَّمات ومعايير
* أدلة معرفية
	+ لإدارة المشاريع (BABOK)
	+ تحليل الأعمال (PMBOK)
	+ لهندسة البرمجيات  (SWEBOK)
* تكامل نموذج نضوج المقدرة (CMMI)
* جمعية معايير معهد مهندسي الكهرباء والإلكترونيات
* أيزو 9000 (ISO 9001)
* اللجنة التقنية المشتركة الأولى  (JTC 1)
* مكتبة البنية التحتية لتقانة المعلومات (ITIL)
* المجلس الهندسي للمتطلبات الدولية  (IREB)
 |
| شعار بوابة بوابة برمجيات |
| * ع
* ن
* ت
 |

يعرف **التطوير مقاد بالسلوك** (بالإنجليزية: Behavior-driven development، واختصارًا: BDD)، في هندسة البرمجيات، على أنه عملية تطوير البرمجيات وفقًا لمنهجية أجايل تشجع التعاون بين المطورين ومختبري ضمان الجودة وممثلي العملاء في مشروع برمجي. يشجع الفرق على استخدام المحادثة والأمثلة العملية لإضفاء الطابع الرسمي على الفهم المشترك لكيفية عمل التطبيق. نشأ من التطوير المقاد بالاختبار (تي دي دي). يجمع التطوير المقاد بالسلوك بين التقنيات العامة ومبادئ التطوير المقاد بالاختبار مع أفكار من التصميم المقاد بالمجال والتحليل والتصميم كائنيا التوجه لتزويد فرق تطوير وإدارة البرمجيات بأدوات مشتركة وعملية مشتركة للتعاون في تطوير البرمجيات.

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

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

مبادئ التطوير المقاد بالسلوك
----------------------------

يعد التطوير المقاد بالاختبار منهجية لتطوير البرمجيات تنص أساسًا على أنه يجب على مطور البرمجيات، بالنسبة لكل وحدة برمجية، تطبيق ما يلي:

* تحديد مجموعة اختبار للوحدة *أولاً*؛
* جعل الاختبارات تفشل؛
* ثم تنفيذ الوحدة؛
* والتحقق أخيرًا من أن تنفيذ الوحدة يجعل الاختبارات تنجح.

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

### المواصفات السلوكية

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

يحدد التطوير المقاد بالسلوك أنه يجب على محللي الأعمال والمطورين التعاون في هذا المجال وتحديد السلوك وفقًا لقصة المستخدم، التي تدون كل منهما صراحةً في مستند مخصص. يجب أن تتبع كل قصة مستخدم، بطريقة ما، التركيب التالي:

**العنوان**

عنوان واضح.

**السرد**

قسم تمهيدي قصير وفق التركيب التالي:

   **باعتباري**: الشخص أو الدور المستفاد من الميزة؛

  **أريد**: الميزة؛

   **بحيث**: فائدة أو قيمة الميزة.

**معايير القبول**

وصف لكل سيناريو محدد للسرد وفقًا للتركيب التالي:

**نظرًا لأن**: السياق الأولي في بداية السيناريو، في بند واحد أو أكثر؛

**عندما**: الحدث الذي أطلق السيناريو؛

**بالتالي**: النتيجة المتوقعة، في جملة واحدة أو أكثر.

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

تصاغ السيناريوهات بشكل مثالي تصريحيًا وليس إلزاميًا - بلغة الأعمال، مع عدم الإشارة إلى عناصر واجهة المستخدم التي تتم من خلالها التفاعلات.

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

### المواصفات كلغة سائدة

يستعير التطوير المقاد بالسلوك مفهوم *اللغة السائدة* من التصميم المقاد بالمجال. تعد اللغة السائدة لغة (شبه) رسمية يتشاركها جميع أعضاء فريق تطوير البرمجيات -مطورو البرمجيات والموظفون غير التقنيين. يستخدم جميع أعضاء الفريق اللغة المعنية ويطوروها كوسيلة مشتركة لمناقشة المجال البرمجي المعني. وبهذه الطريقة يصبح التطوير المقاد بالسلوك وسيلة للتواصل بين جميع الأدوار المختلفة في مشروع برمجي.

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

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

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

انظر أيضًا
----------

* حالة الاستخدام (هندسة البرمجيات)

مراجع
-----

1. 1 2 3  North، Dan (مارس 2006). "Introducing BDD". Dan North. مؤرشف من الأصل في 2021-05-23. اطلع عليه بتاريخ 2019-04-25.
2. 1 2  "Behaviour-Driven Development". مؤرشف من الأصل في 2015-09-01. اطلع عليه بتاريخ 2012-08-12.
3. ↑  Keogh، Liz (7 سبتمبر 2009). "Introduction to Behavior-Driven Development". *SkillsMatter*. مؤرشف من الأصل في 2021-02-25. اطلع عليه بتاريخ 2019-05-01.
4. ↑  John Ferguson Smart (2014). *BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle*. Manning Publications. ISBN:9781617291654.
5. 1 2 3 4  Haring, Ronald (Feb 2011). de Ruiter, Robert (ed.). "Behavior Driven development: Beter dan Test Driven Development". *Java Magazine* (بالهولندية). Veen Magazines (1): 14–17. ISSN:1571-6236.
6. ↑  Solis، Carlos؛ Wang، Xiaofeng (2011). "A Study of the Characteristics of Behaviour Driven Development". *Software Engineering and Advanced Applications (SEAA), 2011 37th EUROMICRO Conference on*: 383–387. DOI:10.1109/SEAA.2011.76. hdl:10344/1256. ISBN:978-1-4577-1027-8.
7. 1 2 3 4  Bellware، Scott (يونيو 2008). "Behavior-Driven Development". *Code Magazine*. مؤرشف من الأصل في 2012-07-12. اطلع عليه بتاريخ 2019-05-01.
8. ↑  Tharayil، Ranjith (15 فبراير 2016). "Behavior-Driven Development: Simplifying the Complex Problem Space". *SolutionsIQ*. مؤرشف من الأصل في 2020-10-21. اطلع عليه بتاريخ 2018-02-15.
9. 1 2  North، Dan (11 فبراير 2007). "What's in a Story?". Dan North. مؤرشف من الأصل في 2021-03-23. اطلع عليه بتاريخ 2012-08-12.
10. ↑  Mabey، Ben. "Imperative vs. Declarative Scenarios in user stories". مؤرشف من الأصل في 2010-06-03. اطلع عليه بتاريخ 2008-05-19.
11. ↑  "nutshell — Lettuce 0.2.23 (kryptonite release) documentation". *lettuce.it*. مؤرشف من الأصل في 2020-11-01. اطلع عليه بتاريخ 2020-02-06.
12. ↑  "Gherkin". مؤرشف من الأصل في 2021-06-11. اطلع عليه بتاريخ 2020-06-07.
13. ↑  "What is JBehave?". *JBehave.org*. مؤرشف من الأصل في 2021-03-03. اطلع عليه بتاريخ 2015-10-20.
14. ↑  "behave is behaviour-driven development, Python style". مؤرشف من الأصل في 2018-01-22. اطلع عليه بتاريخ 2018-01-30.
15. ↑  "Writing Features - Behat 3.0.12 documentation". *behat documentation*. مؤرشف من الأصل في 2015-09-19. اطلع عليه بتاريخ 2015-10-20.
16. ↑  Evans، Eric (2003). *Domain-Driven Design: Tackling Complexity in the Heart of Software*. Addison-Wesley. ISBN:978-0-321-12521-7. مؤرشف من الأصل في 2021-05-07. اطلع عليه بتاريخ 2012-08-12.
17. ↑  North، Dan (31 مايو 2012). "BDD is like TDD if…". *faster organisations, faster software*. Dan North & Associates. مؤرشف من الأصل في 2021-06-08. اطلع عليه بتاريخ 2012-08-12.
18. ↑  Geneca (16 مارس 2011). "Why Software Projects Fail". مؤرشف من الأصل في 2016-12-30. اطلع عليه بتاريخ 2011-03-16.
19. ↑  Mahmudul Haque Azad (6 فبراير 2011). "Say Hello To Behavior Driven Development". مؤرشف من الأصل في 2020-01-22. اطلع عليه بتاريخ 2012-08-12.
20. ↑  Lübke, Daniel؛ van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". *IEEE Software*. ج. 33 ع. 5: 15–21. DOI:10.1109/MS.2016.117.

* أيقونة بوابةبوابة علم الحاسوب
* أيقونة بوابةبوابة برمجيات