دورة حياة تطوير الأنظمة

دورة حياة تطوير الأنظمة

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

الـ SDLC ليس منهجية صارمة واحدة. بل هو إطار مفاهيمي يصف المراحل التي يجب أن تعالجها كل جهة تطوير، بصرف النظر عن اتباع نموذج Waterfall أو Agile أو أي منهج وسيط. إن فهمه بعمق يمنحك خريطة ذهنية تعرف من خلالها أين أنت، وأي الأسئلة يجب طرحها، وما هي المخرجات التي يجب إنتاجها في كل مرحلة.

المراحل الخمس الكلاسيكية

يُقسَّم الـ SDLC التقليدي إلى خمس مراحل. في الواقع العملي تتداخل هذه المراحل وتتكرر — لكنها كخط أساس مفاهيمي لا تقدر بثمن.

المرحلة الأولى — التخطيط

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

تفحص دراسة الجدوى أربعة أبعاد:

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

تصوّر عيادة طبية خاصة تريد استبدال دفاتر المواعيد الورقية بنظام حجز رقمي. قد تشمل مخرجات مرحلة التخطيط: ميثاق المشروع الذي يسمّي الراعي (صاحب العيادة) وأصحاب المصلحة (موظفو الاستقبال، الأطباء، المرضى)، وبيان نطاق رفيع المستوى ("حجز إلكتروني مع تذكيرات بالرسائل القصيرة وتكامل مع نظام الفواتير الحالي")، وميزانية تقريبية بـ45,000 دولار، وجدول زمني مستهدف مدته 6 أشهر. والأهم من ذلك، قد تكشف دراسة الجدوى أن نظام الفواتير يستخدم تنسيقاً احتكارياً عمره 15 عاماً — وهو خطر تقني يجب رصده قبل بدء التطوير.

المرحلة الثانية — التحليل

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

الأنشطة الرئيسية تشمل:

• استنباط المتطلبات — مقابلات وورش عمل واستطلاعات ومراقبة وتحليل وثائق.
• توثيق المتطلبات — قصص المستخدم، حالات الاستخدام، أو مواصفات المتطلبات الرسمية (FRS).
• نمذجة العمليات — مخططات العمليات التجارية (BPM)، ومخططات تدفق البيانات (DFDs) للنظام الحالي.
• تحليل الفجوات — ما الذي يُتقنه النظام الحالي؟ وأين يُخفق؟
• التحقق من المتطلبات — التأكد مع أصحاب المصلحة أن ما كُتب يطابق ما قُصد.

بالنسبة لنظام العيادة، قد يكشف التحليل أن موظفي الاستقبال يتلقون حالياً 80 مكالمة لتحديد مواعيد يومياً، تستغرق في المتوسط 4 دقائق لكل منها، مع نسبة غياب 12% تُكلّف ما يقارب 6,800 دولار شهرياً من إيرادات المواعيد الضائعة. هذه أرقام ملموسة تُبرر ميزانية المشروع وتُحدد مقاييس النجاح — لا مجرد "نريد الرقمنة" المبهمة.

المرحلة الثالثة — التصميم

يجيب التصميم على السؤال: كيف سيعمل النظام؟ يُترجم المتطلباتِ إلى مخطط هندسي يستطيع المطورون تنفيذه. يعمل التصميم على مستويين:

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

بالنسبة لنظام العيادة، تشمل قرارات التصميم المادي: قاعدة بيانات علائقية (PostgreSQL) لتخزين المواعيد والمرضى والأطباء؛ وطبقة RESTful API؛ وواجهة React لموظفي الاستقبال؛ وتكامل مع بوابة الرسائل القصيرة (Twilio)؛ ونسخة قراءة مضاعفة للتقارير حتى لا تُبطئ استعلامات الحجز توليدَ التقارير.

يُوثِّق التصميم الجيد أيضاً القيود والافتراضات بشكل صريح: "يُفترض حد أقصى 20 مستخدماً من موظفي الاستقبال في آنٍ واحد. يجب أن يستوعب النظام موجة من 500 حجز بين الساعة 8:00–9:00 صباحاً عند فتح العيادة." هذه الأرقام تحكم قرارات الطاقة الاستيعابية وتمنع المفاجآت عند الإطلاق.

المرحلة الرابعة — التنفيذ

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

لا ينتهي دور المحلل هنا. خلال التنفيذ يقوم المحللون بـ:

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

المرحلة الخامسة — الصيانة

الصيانة هي المرحلة الأطول في حياة أي نظام. بمجرد تشغيل نظام الحجز في العيادة، سيُوسَّع ويُصحَّح ويُحسَّن لسنوات. تندرج أعمال الصيانة تحت أربع فئات:

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

في الواقع العملي، تستهلك الصيانة 60–80% من إجمالي تكلفة البرنامج على مدار حياته. لهذا السبب تحديداً، القرارات التي تُتخذ في مرحلة التصميم — من تطبيع قاعدة البيانات، وإصدار API، والبنية المعمارية المعيارية — لها تبعات مالية ضخمة على المدى البعيد.

لماذا المراحل ليست متتالية بصرامة؟

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

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

تُرسّخ المنهجيات كـ Agile وScrum والتطوير التكراري هذه التداخلات في دورات قصيرة صريحة تُسمى Sprints أو Iterations — لكنها جميعها لا تزال تعالج الاهتمامات الخمس ذاتها: التخطيط والتحليل والتصميم والتنفيذ والصيانة. وتختلف فقط في الكيفية والترتيب والتكرار الذي تُعالَج به تلك الاهتمامات.

منظور محلل الأنظمة

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

إن فهم الـ SDLC ليس شكليةً بيروقراطية. بل هو النموذج التشغيلي الذي يُتيح لفرق من 10 أو 50 أو 500 شخص التنسيق نحو هدف مشترك — وأن يعرف كل منهم مَن المسؤول عن ماذا، في كل مرحلة من مراحل الرحلة.