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

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

ابدأ بنطاق فصل واحد

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

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

فرّق بين القيد الصلب والتفضيل

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

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

مرّر مثالاً صغيراً عبر النظام

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

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

اعرض سبب الحل للمراجع

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

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

اختبارات تكشف الحلول الخاطئة

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

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

ما الذي يسلمه الفريق؟

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