10.2: نموذج دورة حياة تطوير الأنظمة (SDLC)

نموذج دورة حياة تطوير الأنظمة (SDLC)

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

SDLC هو نموذج يحدد عملية مجموعة من المراحل للتخطيط والتحليل والتصميم والتنفيذ والصيانة. يناقش الفصل الأول أن نظام المعلومات (IS) يتضمن الأجهزة والبرامج وقاعدة البيانات والشبكات والعمليات والأشخاص. تم استخدام SDLC كثيرًا لإدارة مشروع IS الذي قد يتضمن عنصرًا واحدًا أو بعضًا أو كل عناصر IS. لنستعرض كل مرحلة من المراحل الخمس لـ SDLC كما هو موضح في الشكل 10.1:

الشكل 10.1 - نموذج دورة حياة تطوير البرمجيات. الصورة من لي-هيونغ فام، حاصل على درجة الدكتوراه مرخصة بموجب CC BY NC

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

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

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

• تحديد وإجراء مقابلات مع أصحاب المصلحة الرئيسيين.
• توثيق الإجراءات الرئيسية
• تطوير متطلبات البيانات
• لإنتاج مستند متطلبات النظام كنتيجة لهذه المرحلة. يحتوي هذا على التفاصيل لبدء تصميم النظام.

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

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

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

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

5. صيانة. تتم هذه المرحلة بمجرد اكتمال مرحلة التنفيذ. في هذه المرحلة، يجب أن يكون لدى النظام عملية دعم منظمة من أجل:

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

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

نموذج الشلال

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

الشكل 10.2 نموذج الشلال لتطوير النظام. الصورة من بيتر كيمب/بول سميت مرخص بـ CC BY 3.0

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

مزايا وعيوب SDLC والشلال

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

تم تطوير نماذج أخرى بمرور الوقت لمعالجة هذه الانتقادات. سنناقش نموذجين آخرين: تطوير التطبيقات السريعة و Agile، كنهج مختلفة لـ SDLC.

تطوير التطبيقات السريعة (RAD)

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

الشكل 10.3 نموذج تطوير التطبيقات السريعة للصور مرخص في المجال العام.

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

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

مزايا وعيوب RAD

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

منهجيات التطوير الرشيقة

المنهجيات الرشيقة هي مجموعة من المنهجيات التي تستخدم التغييرات التدريجية التي تركز على الجودة والاهتمام بالتفاصيل. يتم إصدار كل زيادة في فترة زمنية محددة (تسمى المربع الزمني)، مما يؤدي إلى إنشاء جدول إصدار منتظم بأهداف معينة. على الرغم من اعتبارها منهجية منفصلة عن RAD، إلا أنها تشترك في بعض المبادئ نفسها: التطوير التكراري وتفاعل المستخدم وقابلية التغيير. تعتمد المنهجيات الرشيقة على «Agile Manifesto»، الذي صدر لأول مرة في عام 2001.

تشمل خصائص الأساليب الرشيقة ما يلي:

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

في الأساس، يضع نهج Agile قيمة أعلى للمهام التي تعزز التفاعل، وبناء إصدارات عمل متكررة، وتعاون العملاء/المستخدمين، والاستجابة السريعة للتغيير وتقليل التركيز على العمليات والوثائق. هدف المنهجيات الرشيقة هو توفير مرونة النهج التكراري مع ضمان جودة المنتج.

هناك مجموعة متنوعة من النماذج التي تم إنشاؤها باستخدام منهجيات Agile. أحد الأمثلة على ذلك هو نموذج تطوير Scrum.

نموذج تطوير سكروم

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

الشكل 10.4. طريقة إدارة مشروع سكروم. تم ترخيص الصورة من Lakeworks باستخدام CC BY-SA 4.0

1. تراكم المنتجات. هذه قائمة تفصيلية بالعمل الذي يتعين القيام به. يتم تحديد أولويات جميع الأعمال بناءً على معايير مثل المخاطر والتبعيات والمهام الحرجة وما إلى ذلك، ويقوم المطورون بتحديد مهامهم الخاصة والتنظيم الذاتي لإنجاز العمل.
2. تراكم سبرينت. هذه قائمة بالعمل الذي يتعين القيام به في السباق التالي.
3. عدو سريع. هذا وقت محدد، مثل يوم واحد أو أسبوعين أو 4 أسابيع، وفقًا لما اتفق عليه الفريق. يُطلق على اجتماع التقدم اليومي اسم سكروم يومي، وعادة ما يكون اجتماعًا قصيرًا مدته 10-15 دقيقة يتم تسهيله من قبل خبير سكروم الذي يتمثل دوره في إزالة حواجز الطرق أمام الفريق.
4. زيادة العمل في البرنامج e. هذه نسخة صالحة للعمل تم إنشاؤها بشكل تدريجي مع قوائم التفصيل في نهاية السباقات.

منهجية الليّن

إحدى المنهجيات الأخيرة التي سنناقشها هي مفهوم جديد نسبيًا مأخوذ من أفضل الكتب مبيعًا في مجال الأعمال The Lean Startup، من تأليف Eric Reis.

الشكل 10.5. منهجية الليّن. ديفيد تي بورجوا، دكتوراه مرخص من CC BY-SA 2.0

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

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

المراجع:

بيان لتطوير البرمجيات الرشيقة (2001). تم استرجاعه في 10 ديسمبر 2020 من http://agilemanifesto.org/

بدء التشغيل المرن. تم استرجاعه في 9 ديسمبر 2020 من http://theleanstartup.com/