هندسة البرمجيات

هندسة البرمجيات الرشيقة: المناهج الرشيقة، سكروم، والبرمجة المتطرفة

نتيجة تعلم المقرر

CLO1: التعرف على مبادئ هندسة البرمجيات، مراحل دورة الحياة، العمليات، والأنشطة.

الفصل 2: عمليات البرمجيات

عملية البرمجيات هي مجموعة منظمة من الأنشطة المطلوبة لتطوير نظام برمجي.

هناك العديد من عمليات البرمجيات المختلفة، لكن جميعها تتضمن أربعة أنشطة أساسية:

1. تحديد المواصفات – تعريف ما يجب أن يفعله النظام
2. التصميم والتنفيذ – تعريف تنظيم النظام وتنفيذ النظام
3. التحقق – التأكد من أنه يفعل ما يريده العميل
4. التطور – تغيير النظام استجابةً لمتطلبات العملاء المتغيرة

ملاحظة: نموذج عملية البرمجيات هو تمثيل مجرد لعملية. يقدم وصفًا لعملية من منظور معين.

أوصاف عملية البرمجيات

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

قد تتضمن أوصاف العمليات أيضًا:

العمليات المخططة والرشيقة

العمليات المخططة (الوصفية)

عمليات يتم فيها تخطيط جميع أنشطة العملية مسبقًا ويتم قياس التقدم مقابل هذا الخطة.

  • تخطيط مسبق مفصل
  • مراحل منظمة
  • توثيق شامل
  • قياس التقدم مقابل الخطة

العمليات الرشيقة

التخطيط تدريجي ومن السهل تغيير العملية لتعكس متطلبات العملاء المتغيرة.

  • تخطيط تدريجي
  • تكيف مرن
  • استجابة سريعة للتغيير
  • تعاون مع العملاء

مهم: في الممارسة العملية، معظم العمليات العملية تتضمن عناصر من النهجين المخطط والرشيق. لا توجد عمليات برمجيات صحيحة أو خاطئة.

نماذج عملية البرمجيات التقليدية/المخططة

نموذج عملية الشلال

نموذج مخطط مع مراحل منفصلة ومميزة للمواصفات والتطوير.

تعريف المتطلبات
تصميم النظام والبرمجيات
التنفيذ واختبار الوحدات
الدمج واختبار النظام
التشغيل والصيانة

مراحل نموذج الشلال

تحليل وتعريف المتطلبات
تصميم النظام والبرمجيات
التنفيذ واختبار الوحدات
الدمج واختبار النظام
التشغيل والصيانة

ملاحظة: كل مرحلة رئيسية يتم تمييزها بمعالم ونتائج (مخرجات).

متى يتم استخدام نموذج الشلال

  1. يعمل للمشاكل المفهومة جيدًا مع تغييرات قليلة أو معدومة في المتطلبات، مثل المشاريع الحكومية
  2. بسيط وسهل الشرح للعملاء

المزايا

  • هيكل ومعالم واضحة
  • سهل الفهم والإدارة
  • يعمل جيدًا للمتطلبات المستقرة
  • توثيق شامل

العيوب

  • صعوبة استيعاب التغيير بعد بدء العملية
  • غالبًا ما يكون من الصعب على العملاء تحديد جميع المتطلبات بشكل صريح
  • التقسيم غير المرن يجعل من الصعب الاستجابة للمتطلبات المتغيرة
  • مناسب فقط عندما تكون المتطلبات مفهومة جيدًا

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

النموذج التزايدي

النموذج التزايدي: بدلاً من تسليم النظام كتسليم واحد، يتم تقسيم النظام إلى زيادات حيث تضيف كل زيادة جزءًا من الوظائف المطلوبة.

يجمع النموذج التزايدي عناصر التدفق الخطي والمتوازي للعملية. يركز نموذج العملية التزايدية على تسليم منتج تشغيلي مع كل زيادة.

عملية التطوير التزايدية

قائمة ميزات المنتج
اختر الميزات
صقل الأوصاف
التنفيذ والاختبار
دمج الميزة
تسليم الزيادة

أنشطة النموذج التزايدي

1. اختيار الميزات المراد تضمينها في زيادة

باستخدام قائمة الميزات في المنتج المخطط، اختر الميزات التي يمكن تنفيذها في زيادة المنتج التالية.

2. صقل أوصاف الميزات

أضف تفاصيل لأوصاف الميزات حتى يكون لدى الفريق فهم مشترك لكل ميزة ويكون هناك تفاصيل كافية لبدء التنفيذ.

3. التنفيذ والاختبار

نفذ الميزة وطور اختبارات آلية لتلك الميزة، اختبارات ستتحقق من أن سلوك النظام متوافق مع وصفه.

4. دمج الميزة واختبارها

دمج الميزة المطورة مع النظام الحالي واختبارها للتحقق من أنها تعمل مع الميزات الأخرى.

5. تسليم زيادة النظام

تسليم زيادة النظام لمدير المنتج للفحص والتعليقات. إذا تم تنفيذ ميزات كافية، أطلق نسخة من النظام لاستخدام العميل.

المزايا

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

المشاكل

  • هيكل النظام يميل للتدهور مع إضافة زيادات جديدة
  • ما لم يتم إنفاق الوقت والمال على إعادة الهيكلة لتحسين البرمجيات، فإن التغيير المنتظم يميل لإفساد هيكلها

الفرق الرئيسي: يتم ترتيب متطلبات المستخدم حسب الأولوية، ثم يتم تضمين أعلى المتطلبات أولوية في الزيادات المبكرة. بمجرد بدء تطوير زيادة، يتم تجميد المتطلبات، رغم أن متطلبات الزيادات اللاحقة يمكن أن تستمر في التطور.

الفرق مع النماذج التطورية: يتم تعريف قائمة الميزات من البداية في النموذج التزايدي الكلاسيكي.

النماذج التطورية

النماذج التطورية تكرارية. يتم توصيفها بطريقة تمكنك من تطوير إصدارات أكثر اكتمالًا من البرمجيات تدريجيًا.

يستخدم عندما تكون المتطلبات الأساسية أو متطلبات النظام مفهومة جيدًا لكن متطلبات النظام الإضافية لم يتم تعريفها بعد.

نموذج النماذج الأولية

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

التواصل
تخطيط سريع
تصميم سريع
بناء النموذج الأولي
التسليم والتغذية الراجعة

عملية النمذجة الأولية

  1. يبدأ نموذج النماذج الأولية بـ التواصل. الالتقاء مع أصحاب المصلحة لتحديد الأهداف العامة، تحديد المتطلبات المعروفة، ورسم المناطق التي تحتاج لمزيد من التعريف.
  2. يتم تخطيط تكرار النموذج الأولي بسرعة، ويحدث النمذجة ("التصميم السريع") (مثل تخطيط واجهة المستخدم أو تنسيقات عرض المخرجات).
  3. يقود التصميم السريع إلى بناء نموذج أولي.
  4. يتم نشر النموذج الأولي وتقييمه من قبل أصحاب المصلحة، الذين يقدمون تغذية راجعة تستخدم لصقل المتطلبات بشكل أكبر.
  5. يحدث التكرار حيث يتم ضبط النموذج الأولي لتلبية احتياجات أصحاب المصلحة مع تمكين فهم أفضل للمتطلبات.

المزايا

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

العيوب

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

ملاحظة: يمكن أن يخدم النموذج الأولي كـ "النظام الأول". رغم أن بعض النماذج الأولية تُبنى كـ "يتم التخلص منها"، إلا أن البعض الآخر تطوري بمعنى أن النموذج الأولي يتطور ببطء إلى النظام الفعلي.

النموذج الحلزوني

يجمع النموذج الحلزوني الطبيعة التكرارية للنماذج الأولية مع الجوانب المتحكم فيها والمنهجية للشلال. يوفر إمكانية التطوير السريع لإصدارات أكثر اكتمالًا من البرمجيات.

النموذج الحلزوني هو مولد نموذج عملية مدفوعة بالمخاطر. له ميزتان رئيسيتان مميزتان:

  1. طبيعة دورية لنمو درجة تعريف النظام وتنفيذه تدريجيًا مع تقليل درجة المخاطرة
  2. لديه مجموعة من المعالم لضمان التزام أصحاب المصلحة بحلول نظامية ممكنة ومشبعة للطرفين

أنشطة النموذج الحلزوني

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

نقاط رئيسية:

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

نماذج العمليات المتخصصة

1. التطوير المعتمد على المكونات

مبني على إعادة استخدام البرمجيات حيث يتم دمج الأنظمة من مكونات موجودة أو أنظمة تطبيقات (تسمى أحيانًا COTS - أنظمة جاهزة تجاريًا).

العملية لتطبيقها عندما يكون إعادة الاستخدام هدفًا للتطوير. تريد استخدام مكونات مصنوعة مسبقًا أو تريد صنع مكونات قد يعاد استخدامها.

أنواع البرمجيات القابلة لإعادة الاستخدام

  1. أنظمة تطبيقات مستقلة تم تكوينها للاستخدام في بيئة معينة
  2. مجموعات من الكائنات تم تطويرها كحزمة لدمجها مع إطار مكون مثل .NET أو J2EE
  3. خدمات الويب التي تم تطويرها وفقًا لمعايير الخدمة والمتاحة للاستدعاء البعيد

المزايا

  • تقليل التكاليف والمخاطر حيث يتم تطوير برمجيات أقل من الصفر
  • تسليم ونشر أسرع للنظام
  • تقليل وقت التطوير
  • تقليل تكلفة المشروع إذا أصبح إعادة استخدام المكونات جزءًا من الثقافة التنظيمية

العيوب

  • التنازلات في المتطلبات حتمية
  • قد لا يلبي النظام الاحتياجات الحقيقية للمستخدمين
  • فقدان السيطرة على تطور عناصر النظام المعاد استخدامها

ملاحظة: يمكن تكوين العناصر المعاد استخدامها لتكييف سلوكها ووظيفتها مع متطلبات المستخدم. إعادة الاستخدام هي الآن النهج القياسي لبناء العديد من أنواع أنظمة الأعمال.

2. العملية الموحدة (UP)

العملية الموحدة هي عملية تطوير تكرارية وتزايدية. يتم تقسيم مراحل التفصيل، البناء، والانتقال إلى سلسلة من التكرارات المحددة زمنيًا. كل تكرار يؤدي إلى زيادة، وهي إصدار من النظام يحتوي على وظائف مضافة أو محسنة مقارنة بالإصدار السابق.

مراحل العملية الموحدة

البداية

تحديد متطلبات الأعمال، موصوفة كحالات استخدام
اقتراح بنية نظام تقريبية

التفصيل

صقل وتوسيع حالات الاستخدام الأولية
توسيع البنية لتشمل خمسة أوجه مختلفة:
  • نموذج حالة الاستخدام
  • نموذج التحليل
  • نموذج التصميم
  • نموذج التنفيذ
  • نموذج النشر

البناء

تطوير أو اكتساب مكونات البرمجيات لإنجاز إصدار أولي

الانتقال

يتم إعطاء البرمجيات للمستخدمين للاختبار التجريبي لجمع العيوب والتغييرات اللازمة
إنشاء معلومات دعم، مثل دليل المستخدم، إجراءات التثبيت، أدوات استكشاف الأخطاء

الإنتاج

مراقبة الاستخدام المستمر للبرمجيات، وتقييم تقارير العيوب وطلبات التغيير

خاصية رئيسية: تدمج العملية الموحدة أنشطة التخطيط، النمذجة، البناء، والنشر خلال جميع المراحل، مع تركيز متغير في مراحل مختلفة من التطوير.

هندسة البرمجيات الرشيقة

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

تركز هندسة البرمجيات الرشيقة على:

  • تسليم الوظائف بسرعة
  • الاستجابة لمواصفات المنتج المتغيرة
  • تقليل النفقات العامة للتطوير

عقلية الرشاقة: القيم، المبادئ، والممارسات

الرشاقة هي عقلية محددة بأربع قيم، موجهة باثني عشر مبدأً، وتتجلى من خلال العديد من الممارسات المختلفة. يختار ممارسو الرشاقة الممارسات بناءً على احتياجاتهم.

القيم الأربع لبيان الرشاقة

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

القيمة 1

الأفراد والتفاعلات

بدلاً من

العمليات والأدوات

القيمة 2

برمجيات عمل

بدلاً من

توثيق شامل

القيمة 3

تعاون العميل

بدلاً من

تفاوض العقد

القيمة 4

الاستجابة للتغيير

بدلاً من

اتباع الخطة

أي أنه بينما هناك قيمة في العناصر على اليمين، فإننا نقدّر العناصر على اليسار أكثر.

المبادئ الاثنا عشر وراء بيان الرشاقة

1. إرضاء العميل

أعلى أولوياتنا هي إرضاء العميل من خلال التسليم المبكر والمستمر لبرمجيات قيمة.

2. الترحيب بالمتطلبات المتغيرة

الترحيب بالمتطلبات المتغيرة، حتى في مراحل التطوير المتأخرة. عمليات الرشاقة تستغل التغيير لمصلحة العميل التنافسية.

3. تسليم برمجيات عمل بشكل متكرر

تسليم برمجيات عمل بشكل متكرر، من بضعة أسابيع إلى بضعة أشهر، مع تفضيل المقياس الزمني الأقصر.

4. العمل معًا يوميًا

يجب أن يعمل رجال الأعمال والمطورون معًا يوميًا طوال المشروع.

5. بناء المشاريع حول أفراد متحمسين

بناء المشاريع حول أفراد متحمسين. أعطهم البيئة والدعم الذي يحتاجونه وثق بهم لإنجاز العمل.

6. محادثة وجهًا لوجه

الطريقة الأكثر كفاءة وفعالية لنقل المعلومات إلى وداخل فريق التطوير هي المحادثة وجهًا لوجه.

7. البرمجيات العاملة هي المقياس الأساسي

البرمجيات العاملة هي المقياس الأساسي للتقدم.

8. التطوير المستدام

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

9. التميز التقني

الاهتمام المستمر بالتميز التقني والتصميم الجيد يعزز الرشاقة.

10. البساطة

البساطة - فن تعظيم كمية العمل غير المنجز - أساسية.

11. فرق التنظيم الذاتي

أفضل البنى، المتطلبات، والتصميمات تنبثق من فرق التنظيم الذاتي.

12. التأمل والتعديل

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

مناهج الرشاقة

الرشاقة مصطلح شامل للعديد من المناهج، بما في ذلك:

سكروم

البرمجة المتطرفة (XP)

كانبان

لين

كريستال

التطوير الموجه بالميزات (FDD)

DSDM

العملية الموحدة الرشيقة (AUP)

مصفوفة ميزات العمليات

العملية مراحل مميزة تسليم تدريجي تكرارية مواصفات متطورة تكرارات محددة زمنيًا إدارة المخاطر
الشلال
تزايدي
تطوري
حلزوني
العملية الموحدة
الرشاقة العامة
سكروم

ملخص النقاط الرئيسية

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