> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# مشروع التخرج Graduation Project: من الفكرة إلى المناقشة
- URL: https://arabroot.io/articles/مشروع-التخرج-من-اختيار-الفكرة-الى-المناقشة/
- Published: 2026-11-01T18:43:25.000Z
- Updated: 2026-11-01T20:40:23.000Z
- Description: كيف تختار فكرة مشروع التخرج وتتحقق منها، وتكتب المقترح وتخطط لفصلين وتقيس النتائج، ثم تستعد للمناقشة وتعرض المشروع في سيرتك.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, للطلاب والخريجين, #lead

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

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

وهذا المقال هو الدليل العام لمرحلة مشروع التخرج في مسار الطلاب والخريجين، ومعه مقالات أفكار المشاريع لكل تخصص ([علوم الحاسب](https://arabroot.io/articles/%D8%A7%D9%81%D9%83%D8%A7%D8%B1-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D8%AA%D8%AE%D8%B1%D8%AC-%D9%81%D9%8A-%D8%B9%D9%84%D9%88%D9%85-%D8%A7%D9%84%D8%AD%D8%A7%D8%B3%D8%A8-computer-science/)، و[هندسة البرمجيات](https://arabroot.io/articles/%D8%A7%D9%81%D9%83%D8%A7%D8%B1-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D8%AA%D8%AE%D8%B1%D8%AC-%D9%81%D9%8A-%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%84%D9%84%D8%A8%D9%83%D8%A7%D9%84%D9%88%D8%B1%D9%8A%D9%88%D8%B3-%D9%88%D8%A7%D9%84%D9%85%D8%A7%D8%AC%D8%B3%D8%AA%D9%8A%D8%B1/)، و[تقنية المعلومات](https://arabroot.io/articles/%D8%A7%D9%81%D9%83%D8%A7%D8%B1-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D8%AA%D8%AE%D8%B1%D8%AC-%D9%81%D9%8A-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-%D9%84%D9%84%D8%A8%D9%83%D8%A7%D9%84%D9%88%D8%B1%D9%8A%D9%88%D8%B3-%D9%88%D8%A7%D9%84%D9%85%D8%A7%D8%AC%D8%B3%D8%AA%D9%8A%D8%B1/)، و[الأمن السيبراني](https://arabroot.io/articles/%D8%A7%D9%81%D9%83%D8%A7%D8%B1-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D8%AA%D8%AE%D8%B1%D8%AC-%D9%81%D9%8A-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D9%84%D9%84%D8%A8%D9%83%D8%A7%D9%84%D9%88%D8%B1%D9%8A%D9%88%D8%B3-%D9%88%D8%A7%D9%84%D9%85%D8%A7%D8%AC%D8%B3%D8%AA%D9%8A%D8%B1/)، و[علم البيانات والذكاء الاصطناعي](https://arabroot.io/articles/%D8%A7%D9%81%D9%83%D8%A7%D8%B1-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D8%AA%D8%AE%D8%B1%D8%AC-%D9%81%D9%8A-%D8%B9%D9%84%D9%85-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/)، و[نظم المعلومات](https://arabroot.io/articles/%D8%A7%D9%81%D9%83%D8%A7%D8%B1-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D8%AA%D8%AE%D8%B1%D8%AC-%D9%81%D9%8A-%D9%86%D8%B8%D9%85-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-%D9%84%D9%84%D8%A8%D9%83%D8%A7%D9%84%D9%88%D8%B1%D9%8A%D9%88%D8%B3-%D9%88%D8%A7%D9%84%D9%85%D8%A7%D8%AC%D8%B3%D8%AA%D9%8A%D8%B1/)، و[هندسة الحاسب](https://arabroot.io/articles/%D8%A7%D9%81%D9%83%D8%A7%D8%B1-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D8%AA%D8%AE%D8%B1%D8%AC-%D9%81%D9%8A-%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D8%AD%D8%A7%D8%B3%D8%A8-embedded-systems/))، و[دليل رسالة الماجستير](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D9%84%D8%A9-%D8%A7%D9%84%D9%85%D8%A7%D8%AC%D8%B3%D8%AA%D9%8A%D8%B1-%D9%81%D9%8A-%D8%A7%D9%84%D8%AA%D8%AE%D8%B5%D8%B5%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D8%A4%D8%A7%D9%84-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D9%85%D9%86%D8%A7%D9%82%D8%B4%D8%A9/) لمن يخطط للدراسات العليا. وإذا لم تكن قد قرأت ما يدرسه تخصصك ولماذا، فابدأ بمقال [أي تخصص تقني تختار؟](https://arabroot.io/articles/%D8%A7%D9%8A-%D8%AA%D8%AE%D8%B5%D8%B5-%D8%AA%D9%82%D9%86%D9%8A-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D9%85%D8%A7-%D8%AA%D8%AF%D8%B1%D8%B3%D9%87-%D9%88%D8%A7%D9%8A%D9%86-%D8%AA%D8%B9%D9%85%D9%84/) ثم دليل تخصصك.

وسوف نناقش في هذا المقال ما يلي:

- ما تطلبه الجامعات ومعايير الاعتماد ABET من مشروع التخرج، ومسار التطوير والمسار البحثي.
- من أين تأتي الأفكار الجيدة، ولماذا يتعب المشرفون من بعض الأفكار، وكيف تنقذ فكرة مستهلكة.
- كيف تتحقق من الفكرة بخمسة أسئلة وتجربة جدوى Spike قبل أن تلتزم بها.
- المقترح Proposal والنطاق Scope وأدوار الفريق والعلاقة مع المشرف.
- تجربة عملية Lab: خطة المشروع في ملف TOML وبرنامج Python يفحصها ويرسم مخطط Gantt، وما ظهر عند تشغيله.
- Git والمهام Issues، والتوثيق SRS وSDD، والاختبار والتقييم ودراسة المستخدمين.
- فصول التقرير، والمناقشة Defense مع أسئلة لجنة حقيقية الطابع، والأخطاء التي تسقط المشاريع، وكيف تعرضه في سيرتك.

## ما هو مشروع التخرج Capstone Project، وماذا تطلب الجامعة منه؟

يسمى مشروع التخرج في الأدبيات الأكاديمية مشروع التتويج Capstone Project، والاسم مأخوذ من الحجر الذي يوضع في أعلى البناء، والفكرة أن المشروع لا يعلمك مادة جديدة بقدر ما يجمع ما درسته في السنوات السابقة في عمل واحد. وهذا ليس وصفاً إنشائياً، وإنما شرط مكتوب في معايير الاعتماد، فهيئة ABET التي تعتمد كثيراً من برامج الحوسبة في الجامعات السعودية تشترط في [معايير برامج الحوسبة 2026-2027](https://www.abet.org/accreditation/accreditation-criteria/criteria-for-accrediting-computing-programs-2026-2027/?ref=arabroot.io) أن يتضمن منهج البكالوريوس مشروعاً شاملاً يبني على المعرفة والمهارات التي اكتسبها الطالب في المواد المتقدمة السابقة، وتضيف في معايير برامج علوم الحاسب تحديداً «مشروعاً كبيراً يتطلب دمج المعرفة والمهارات المكتسبة في المواد السابقة وتطبيقها». ومن نواتج التعلم Student Outcomes التي يجب أن يحققها خريج الحوسبة في المعايير نفسها أن يصمم حلاً حاسوبياً وينفذه ويقيمه، وأن يتواصل بفاعلية في سياقات مهنية مختلفة، وأن يعمل بفاعلية عضواً أو قائداً في فريق. ولاحظ أن هذه الثلاثة هي بالضبط ما تقيسه اللجنة في المناقشة: هل بنيتم شيئاً يعمل، وهل قيستم أنه يعمل، وهل تستطيعون شرحه، وهل عملتم كفريق.

أما كيف تنفذ الجامعات هذا الشرط، فيختلف في التفاصيل ويتشابه في الهيكل. ففي [دليل مشروع التخرج لقسم علوم الحاسب في جامعة الملك سعود](https://faculty.ksu.edu.sa/sites/default/files/csprojecthandbook%5F2-25-2016.pdf?ref=arabroot.io) (إصدار 2016 للشطر النسائي) يتوزع المشروع على مادتين في السنة الأخيرة هما CSC 496 في الفصل الأول وCSC 497 في الفصل الثاني، ويتكون الفريق من خمس طالبات، ويسلم الفريق مقترحاً أولياً في الأسبوع الثاني، وتقريراً في منتصف الفصل في الأسبوع الثامن، وتقرير الفصل الأول في الأسبوع الرابع عشر، ثم يقدم عرضاً شفهياً في أول أيام فترة الاختبارات. وفي [دليل طالب مشروع التخرج في كلية علوم الحاسب وتقنية المعلومات بجامعة الملك فيصل](https://www.kfu.edu.sa/ar/Colleges/Computer%5FScience/Documents/Graduation%5Fproject/2019/GP-Students%5FGuide.pdf?ref=arabroot.io) يمتد المشروع على الفصلين السابع والثامن، والفريق من ثلاثة أو أربعة طلاب، ويسجل الطلاب تسجيلاً مسبقاً في نهاية الفصل السادس بعد الاتفاق على الفكرة والمشرف، وفي كل فصل محطتان Milestones في الأسبوع الثامن والأسبوع الخامس عشر يسلم فيهما الفريق تقريراً ويعرض أمام اللجنة. وفي [دليل مشروع التخرج لقسم نظم المعلومات في جامعة الإمام محمد بن سعود الإسلامية](https://units.imamu.edu.sa/colleges/ComputerAndInformation/academic%5Fservices/Documents/Graduation%5FProjects/NEW/IS%20Dept%20GP%20Booklet.pdf?ref=arabroot.io) (ربيع 2018) يتوزع المشروع على IS497 وIS498، والفريق من طالبين إلى ثلاثة، ويشرف عليه مشرف ويقيمه عضوان في لجنة.

![خط زمني لفصلين دراسيين: التسجيل المسبق في نهاية الفصل السادس، ثم الفصل الأول وفيه المقترح الأولي في الأسبوع الثاني وتقرير منتصف الفصل في الأسبوع الثامن وتقرير الفصل الأول وعرضه في الأسبوع الرابع عشر والخامس عشر، ثم الفصل الثاني وفيه البناء وعرض النسخة العاملة في منتصفه والتقرير النهائي في الأسبوع الرابع عشر والمناقشة في نهايته، مع ما يحدث في كل محطة](https://arabroot.io/content/images/2026/11/graduation-project-guide-01-journey.webp)

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

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

### مسار التطوير Software أم المسار البحثي Research؟

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

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

## كيف تختار الفكرة Project Idea؟

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

### من أين تأتي الأفكار الجيدة Sources of Ideas؟

الأفكار الجيدة لمشاريع التخرج تأتي غالباً من خمسة مصادر، وكل مصدر له ميزة وعيب:

- مشكلة عشتها بنفسك Personal Pain: إجراء في الجامعة أو في عمل أسرتك أو في تدريبك الصيفي يضيع الوقت كل أسبوع. وميزته أنك تعرف المستخدم وتستطيع الوصول إليه، وعيبه أنك قد تظن أن مشكلتك هي مشكلة الجميع، ولذلك تحتاج المقابلات التي سنتحدث عنها بعد قليل.
- مشاريع أعضاء هيئة التدريس Faculty Projects: أغلب الأقسام تنشر قائمة أفكار من الأساتذة قبل بداية المشروع، ودليل جامعة الملك سعود ينص على أن المشرفين يرفعون أفكارهم في بوابة إلكترونية قبل الفصل، وأن الفرق ترتب المشاريع بحسب الأفضلية. وميزة هذا المصدر أن المشرف متحمس للفكرة ويعرف أدبياتها، وعيبه أن الفكرة قد تكون جزءاً من بحثه هو، فتجد نفسك تنفذ ما يريد بدل ما تريد.
- جهة خارجية Industry Partner: شركة أو جهة حكومية أو جمعية خيرية لديها مشكلة حقيقية، ودليل جامعة الإمام يسمح بالانضمام إلى مشاريع يرعاها شركاء خارجيون، ودليل جامعة الملك فيصل يذكر المشرف المساعد Co-supervisor للمشاريع التي ترعاها جهات صناعية. وميزته أن المستخدم حقيقي، وعيبه أن الجهة قد تتأخر في الرد أو في إعطاء البيانات، فلا تجعل مشروعك يعتمد على بيانات لم تستلمها بعد.
- بيانات مفتوحة Open Data: تبدأ من مجموعة بيانات منشورة ثم تسأل ما المشكلة التي تحلها، وهذا مناسب لمشاريع علم البيانات والذكاء الاصطناعي، وتجد في مقالات أفكار المشاريع لكل تخصص مصادر بيانات حقيقية تحققنا من روابطها.
- مشروع مفتوح المصدر Open Source: أن يكون مشروعك ميزة كبيرة أو أداة لمشروع مفتوح المصدر قائم، وهذا مصدر قليل الاستخدام في الجامعات مع أنه يعطيك أكثر ما يقدره صاحب العمل: كوداً في مشروع حقيقي راجعه مطورون لا يعرفونك.

### الأفكار المستهلكة Overused Ideas، وكيف تنقذ واحدة منها

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

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

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

واختار الفريق الصف الأخير، لأن مشكلته مشكلة كل طالب: لائحة الدراسة والاختبارات وثيقة طويلة، والطالب الذي يريد أن يعرف هل يحق له الاعتذار عن فصل أو كم مرة يمكنه أن يؤجل اختباراً يسأل زملاءه أو ينتظر رد شؤون الطلاب. والفرق بين هذه الفكرة وروبوت الجامعة المستهلك ليس في التقنية، فكلاهما قد يستخدم نموذجاً لغوياً، وإنما في أن هذه الفكرة لها مقياس نجاح واضح: هل ذكر النظام المادة الصحيحة؟ وهل كانت الإجابة صحيحة؟ وكم مرة رفض أن يجيب عندما لم يجد مادة تنطبق؟ وهذه الأسئلة الثلاثة ستجعل اللجنة تسأل عن التصميم والتقييم بدل أن تسأل «ما الجديد في هذا؟». وإذا أردت أن تفهم التقنية التي سيبني عليها الفريق قبل أن تكمل، فاقرأ [البحث في مستنداتك مع RAG للمبتدئين](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-%D9%81%D9%8A-%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%A7%D8%AA%D9%83-%D9%85%D8%B9-rag-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) و[البحث في النصوص العربية](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-%D9%81%D9%8A-%D8%A7%D9%84%D9%86%D8%B5%D9%88%D8%B5-%D8%A7%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9-%D9%85%D8%B9-opensearch-%D9%88-meilisearch/).

## كيف تتحقق من الفكرة قبل أن تلتزم بها Validation؟

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

### اختبار الأسئلة الخمسة Five Questions Test

1. هل المشكلة حقيقية Real Problem؟ والدليل ليس رأيك، وإنما خمس مقابلات قصيرة مع مستخدمين محتملين، أو وثيقة رسمية، أو بيانات منشورة. فإذا لم تجد خمسة أشخاص يشتكون من المشكلة فغالب الظن أنها ليست مشكلة.
2. هل تستطيع الوصول إلى المستخدم Access to Users؟ ستحتاجه مرتين على الأقل: في البداية لتفهم المتطلبات، وفي النهاية لتقيس سهولة الاستخدام، فإذا كان المستخدم طبيباً في مستشفى لا تعرف فيه أحداً، فهذه مخاطرة يجب أن تكتبها.
3. هل البيانات متاحة الآن Data Available Now؟ لا تقبل «الجهة وعدتنا بالبيانات». فإما أن تكون البيانات في يدك أو منشورة برخصة تسمح باستخدامها، وإما أن تكون لديك خطة بديلة مكتوبة إذا لم تصل.
4. هل يناسب النطاق الفريق والوقت Scope Fits؟ تذكر جملة دليل جامعة الملك فيصل: حجم العمل يتناسب مع الساعات المعتمدة مضروبة في عدد الطلاب. فالفكرة التي ينجزها طالب واحد في شهر صغيرة على فريق من أربعة، والفكرة التي تحتاج سنتين من فريق محترف كبيرة.
5. هل تستطيع أن تقيس النجاح Measurable Evaluation؟ ما الرقم الذي ستعرضه في المناقشة لتقول إن المشروع نجح؟ دقة على مجموعة اختبار، أو زمن إنجاز مهمة قبل النظام وبعده، أو درجة سهولة استخدام من دراسة مستخدمين. فإذا لم تجد رقماً، فالفكرة تحتاج إعادة صياغة.

![جدول يمرر أفكار الفريق الثلاث على خمسة أسئلة: المشكلة الحقيقية، والوصول إلى المستخدم، والبيانات المتاحة الآن، والنطاق المناسب، والقياس، فيفشل نظام الحضور في البيانات والقياس، ويفشل المتجر العام في المشكلة والنطاق، وينجح مساعد اللوائح في الخمسة مع ملاحظة على بناء مجموعة الأسئلة](https://arabroot.io/content/images/2026/11/graduation-project-guide-02-idea-filter.webp)

الأسئلة الخمسة على أفكار الفريق: فكرة واحدة تنجح فيها كلها

وعندما مرر الفريق أفكاره الثلاث على هذه الأسئلة، سقط نظام الحضور في سؤال البيانات، لأن تدريب نموذج أو تقييمه يحتاج صوراً لطلاب حقيقيين، وهذه بيانات شخصية حساسة تحتاج موافقة كل طالب، وهذا ما يناقشه مقال [أخلاقيات البحث على البشر](https://arabroot.io/articles/%D8%A7%D8%AE%D9%84%D8%A7%D9%82%D9%8A%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D8%A8%D8%B4%D8%B1-%D9%85%D9%86-%D9%84%D8%AC%D9%86%D8%A9-irb-%D8%A7%D9%84%D9%89-%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA/). وسقط المتجر في سؤال المشكلة لأنهم لم يجدوا أسرة منتجة واحدة تشتكي من غياب متجر، فأغلبها يبيع عبر حسابات التواصل الاجتماعي ومنصات جاهزة. وبقي مساعد اللوائح، وفيه ملاحظة واحدة: لا توجد مجموعة أسئلة جاهزة بإجاباتها، والفريق سيبنيها بنفسه، وهذا عمل حقيقي يجب أن يظهر في الخطة.

### تجربة الجدوى Spike في أسبوع

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

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

## المقترح Project Proposal: ماذا يكتب فيه؟

المقترح هو أول وثيقة رسمية في المشروع، وهو عقد بينك وبين المشرف واللجنة على ما ستفعله وما لن تفعله. وتتشابه الأقسام التي تطلبها الأدلة، فدليل جامعة الملك فيصل يطلب في المحطة الأولى الخلفية والدافع وتعريف المشكلة Problem Statement، ثم في المحطة الثانية الابتكار والفائدة، والنطاق ودرجة التحدي، وتحليلاً شاملاً للأعمال السابقة، والأهداف والنتائج المتوقعة والمنهجية، والحلول البديلة وسبب اختيار الحل، والمتطلبات، وخطة عمل واقعية. ودليل جامعة الملك سعود يطلب أن تكون الأهداف SMART، أي محددة Specific وقابلة للقياس Measurable وممكنة Achievable وواقعية Realistic ومحددة بزمن Time constrained، ويضيف جملة تستحق أن تعلقها فوق مكتبك: «الهدف الأقل طموحاً الذي يكتمل أفضل من الهدف الطموح الذي لا تستطيع تحقيقه».

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

- جدول الأدلة Evidence: بدل أن تكتب «يعاني الطلاب من صعوبة فهم اللوائح»، تكتب «أجرينا مقابلات مع خمسة طلاب وموظف في شؤون الطلاب، وذكر أربعة منهم أنهم سألوا زميلاً عن مادة في اللائحة بدل قراءتها، وذكر الموظف أن أكثر الأسئلة تكراراً عن الاعتذار والحرمان». الأولى رأي، والثانية دليل.
- الأعمال السابقة Related Work: ثلاثة إلى خمسة حلول أو أبحاث قريبة، ولكل واحد ما ينقصه لمشكلتك. ولا تكتب «لا يوجد حل مشابه»، فاللجنة ستجد واحداً في دقيقة، والأفضل أن تجده أنت وتقول لماذا لا يكفي.
- خطة التقييم Evaluation Plan: ما الذي ستقيسه، وكيف، وما الرقم الذي تعده نجاحاً. والفريق كتب: دقة الإجابة وذكر المادة الصحيحة على مجموعة من مئتي سؤال، ونسبة الرفض الصحيح للأسئلة التي ليس لها إجابة في اللائحة، ودرجة سهولة الاستخدام بمقياس SUS مع اثني عشر طالباً.

ولمن يريد التعمق في كتابة المقترح كوثيقة إقناع، ففي مقال [كيف تكتب مقترح البحث Research Proposal](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-research-proposal-%D8%A7%D9%84%D8%B0%D9%8A-%D9%8A%D9%82%D9%86%D8%B9-%D8%A7%D9%84%D9%85%D9%85%D9%88%D9%84/) تفصيل أكثر موجه للمقترحات البحثية وطلبات التمويل، وأغلب ما فيه ينطبق على المشروع البحثي في البكالوريوس.

## النطاق Scope: كيف تقول لا لميزة جميلة؟

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

### تقسيم MoSCoW

أبسط أداة لتقسيم النطاق هي تقسيم MoSCoW، وهو اختصار لأربع فئات: يجب Must، وينبغي Should، ويمكن Could، ولن نفعله هذه المرة Won't. والقاعدة التي تجعله مفيداً أن فئة Must وحدها يجب أن تكون مشروعاً كاملاً يستحق النجاح، فإذا تأخر الفريق ولم ينجز غيرها فما زال لديه مشروع يقدمه. وقسم الفريق قائمته كما يلي:

| الفئة          | الميزات                                                                                | لماذا هنا                                                       |
| -------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| يجب Must       | الإجابة مع ذكر المادة، ورفض السؤال الذي لا تغطيه اللائحة، ومجموعة التقييم من مئتي سؤال | هذا هو المشروع نفسه، وبدونه لا يوجد ما يقاس                     |
| ينبغي Should   | واجهة ويب متجاوبة تعمل على الجوال، ولوحة بسيطة لأكثر الأسئلة تكراراً                   | تجعل دراسة المستخدمين ممكنة، وتعطي شؤون الطلاب سبباً للاهتمام   |
| يمكن Could     | دعم أكثر من لائحة (الدراسات العليا، السكن)                                             | إضافة بيانات لا تغير التصميم، فتضاف إذا بقي وقت                 |
| لن نفعله Won't | الصوت، والإنجليزية، وتطبيق الجوال الأصلي، والربط بنظام الطالب                          | كل واحدة مشروع، والربط بنظام الطالب يحتاج صلاحيات وبيانات شخصية |

وفائدة فئة Won't أنها مكتوبة في المقترح، فعندما تسأل اللجنة في المناقشة «لماذا لا يدعم الصوت؟» يكون الجواب «لأننا قررنا ذلك في المقترح لهذا السبب، وهو في العمل المستقبلي Future Work»، وهذا جواب فريق يدير مشروعه، وليس فريقاً لم يجد وقتاً.

## أدوار الفريق Team Roles وتوزيع العمل

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

والأفضل أن يكون لكل عضو دور رئيسي يملكه ويحاسب عليه، وأن يكتب كل عضو الجزء من التقرير الذي يخص عمله، وأن يكون في الفريق دور للاختبار والتكامل من الأسبوع الأول. وهكذا وزع فريقنا الأدوار:

![أربع بطاقات لأدوار الفريق: قائد الفريق والخلفية Backend ويملك خدمة الإجابة وجدول الاجتماعات، والبيانات والتقييم Evaluation ويملك مجموعة الأسئلة والتجارب، والواجهة وتجربة المستخدم UX ويملك النموذج الأولي ودراسة المستخدمين، والاختبار والتوثيق والتكامل CI ويملك الاختبارات والمستودع والتقرير المجمع، وتحت كل بطاقة ما يكتبه في التقرير وما يسأل عنه في المناقشة](https://arabroot.io/content/images/2026/11/graduation-project-guide-03-roles.webp)

كل عضو يملك جزءاً من النظام وجزءاً من التقرير وجزءاً من أسئلة المناقشة

ولاحظ أن «قائد الفريق» ليس مديراً يوزع المهام ولا يعمل، وإنما هو من يدير الاجتماعات ويتابع المحضر ويتواصل مع المشرف، ويعمل في الوقت نفسه على جزء تقني. ولاحظ كذلك أن معايير ABET تقول «عضواً أو قائداً في فريق»، وأن اللجنة في أغلب الأدلة تقيم كل طالب بدرجة فردية، فالطالب الذي لا يستطيع أن يشرح ما عمله يخسر درجته حتى لو نجح المشروع. وإذا كان فريقك أكبر من خمسة، فاقرأ مقال [هل يسلم الفريق الأكبر أسرع؟](https://arabroot.io/articles/%D9%87%D9%84-%D9%8A%D8%B3%D9%84%D9%85-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D8%A7%D9%83%D8%A8%D8%B1-%D8%A7%D8%B3%D8%B1%D8%B9-%D9%82%D8%A7%D9%86%D9%88%D9%86-brooks/)، فقانون Brooks ينطبق على مشروع التخرج كما ينطبق على الشركات، فكل عضو إضافي يضيف قنوات تواصل أكثر مما يضيف من ساعات عمل.

## العلاقة مع المشرف Supervisor: كيف تستفيد من نصف ساعة أسبوعياً؟

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

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

### محضر الاجتماع Meeting Minutes

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

```markdown
# اجتماع 07 مع المشرف (الأسبوع 6)
الحضور: m1, m2, m3, m4, المشرف

## ما أنجز
- مجموعة الأسئلة: (عدد) سؤالاً من 200، مع رقم المادة لكل سؤال (#14)
- تجربة الجدوى: البحث النصي يجد المادة الصحيحة في أول 3 نتائج لـ (عدد) سؤالاً من 20 (#18)

## القرارات
- الإنجليزية خارج النطاق (Won't)، والسبب: اللائحة المعتمدة عربية، والترجمة تضيف خطأً لا نستطيع قياسه
- نضيف 30 سؤالاً ليس لها إجابة في اللائحة لقياس الرفض الصحيح

## المهام حتى الاجتماع القادم
- [ ] m2: إكمال الأسئلة إلى 200 (#14)
- [ ] m1: مقارنة البحث النصي بالبحث الدلالي على الأسئلة العشرين (#19)
- [ ] m3: نموذج أولي للواجهة على الورق وعرضه على طالبين (#21)
```

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

## التخطيط بالفصل الدراسي Semester Planning

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

والتقسيم الذي يعمل أفضل في الواقع هو أن يحتوي الفصل الأول على ثلاثة أشياء معاً: الوثائق المطلوبة، وتجربة الجدوى التي تثبت أن الجزء الصعب ممكن، ومجموعة التقييم التي ستقيس بها النظام في النهاية. ثم يكون الفصل الثاني للبناء على دورات قصيرة Iterations من أسبوعين، كل دورة تنتهي بشيء يعمل يعرض على المشرف، ثم التقييم ثم التقرير. وإذا كان قسمك يطلب منهجية تطوير محددة فاقرأ [Agile وScrum وKanban بلا شعارات](https://arabroot.io/articles/agile-%D9%88-scrum-%D9%88-kanban-%D8%A8%D9%84%D8%A7-%D8%B4%D8%B9%D8%A7%D8%B1%D8%A7%D8%AA/)، ولكن لا تحول المشروع إلى طقوس Scrum كاملة لفريق من أربعة طلاب يلتقون مرتين في الأسبوع، فيكفيك قائمة مهام مرتبة ودورات قصيرة ومراجعة في نهاية كل دورة.

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

## تجربة عملية Lab: خطة المشروع في ملف TOML وبرنامج يفحصها

الفكرة أن تكتب خطة المشروع كبيانات: الأعضاء وساعاتهم المتاحة، ومواعيد القسم، والمهام بمدتها ومالكها وما تعتمد عليه، ثم يقرأ البرنامج الملف ويجدول المهام ويتحقق مما يكتشفه المشرف عادة متأخراً: مهمة تنتهي بعد موعد تسليمها، أو تسليم بلا وقت احتياطي Buffer، أو عضو عليه في أسبوع ما ضعف ساعاته المتاحة، أو تقرير نهائي يبدأ قبل أن ينتهي أي تقييم، أو دائرة في الاعتماديات Dependency Cycle. ثم يخرج جدولاً وملف Mermaid يرسمه GitHub مخطط Gantt، وصورة SVG تضعها في التقرير.

واخترنا TOML وليس YAML لسبب عملي، وهو أن Python من الإصدار 3.11 فيها وحدة [tomllib](https://docs.python.org/3/library/tomllib.html?ref=arabroot.io) في المكتبة القياسية لقراءة TOML، أما YAML فتحتاج مكتبة خارجية، والبرنامج الذي يعمل دون تثبيت أي شيء يعمل على جهاز كل عضو في الفريق وعلى خادم التكامل المستمر دون مشكلات. والملفات كلها في مجلد `lab/` بجانب هذا المقال: `plan.toml` و`plan_check.py` و`proposal-template.md`، وشغلناها على Python 3.13.3.

### ملف الخطة plan.toml

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

```toml
[project]
title = "مساعد يجيب عن أسئلة لوائح الدراسة والاختبارات مع ذكر المادة"
title_en = "Regulations Q&A assistant with article citations"
weeks = 32
buffer_weeks = 1          # أقل مسافة بين نهاية آخر مهمة في تسليم وموعد التسليم

[[members]]
id = "m1"
role = "قائد الفريق والخلفية Backend"
capacity = 8              # ساعات أسبوعياً للمشروع (بقية الوقت للمواد الأخرى)

[[milestones]]
id = "midterm"
name = "تقرير منتصف الفصل الأول"
week = 8

[[tasks]]
id = "T03"
name = "جمع اللوائح وبناء 200 سؤال بإجاباتها"
owners = ["m2"]
weeks = 4
hours = 6
deps = ["T02"]
due = "midterm"
```

في الملف أعلاه لاحظ التالي:

- الأسابيع مرقمة من 1 إلى 32، الفصل الأول من 1 إلى 16 والثاني من 17 إلى 32، وبهذا يعمل الملف مع أي تقويم، وتغير مواعيد المحطات Milestones بحسب دليل قسمك.
- `capacity` هي الساعات الأسبوعية التي يستطيع العضو أن يعطيها للمشروع، ووضعنا ثماني ساعات لكل عضو لأن لديه مواد أخرى. وهذا رقم يقرره الفريق بصدق، وليس رقماً من دليل الجامعة.
- `hours` في المهمة هي الساعات الأسبوعية لكل مالك طوال مدة المهمة، فمهمة لمالكين بأربع ساعات تأخذ من كل واحد منهما أربع ساعات في كل أسبوع من أسابيعها.
- `due` تربط كل مهمة بالتسليم الذي تخدمه، وهذا ما يجعل البرنامج يعرف أن تأخر مهمة يعني تأخر تسليم.
- مهام التقييم لها `kind = "evaluation"` والتقرير النهائي له `kind = "report"`، وسنعرف بعد قليل لماذا أضفنا هذا الحقل.

### البرنامج plan\_check.py

البرنامج نحو مئتي سطر من Python بالمكتبة القياسية فقط، ويعمل في سبع خطوات، والمقطع التالي قلب الجدولة:

```python
# 3. earliest schedule (weeks are 1-based, a task of 2 weeks starting at 5 ends at 6)
start, end = {}, {}
for i in order:
    t = tid[i]
    s = max([end[d] + 1 for d in t.get("deps", [])] + [t.get("not_before", 1)])
    start[i], end[i] = s, s + t["weeks"] - 1
```

والخطوات بالترتيب:

1. يتحقق من المراجع: كل اعتمادية تشير إلى مهمة موجودة، وكل مالك عضو في الفريق، وكل مهمة مربوطة بتسليم معروف.
2. يرتب المهام ترتيباً طوبولوجياً Topological Sort بخوارزمية Kahn، فالمهمة لا تدخل الترتيب إلا بعد كل ما تعتمد عليه، وإذا بقيت مهام لم تدخل فهناك دائرة.
3. يجدول كل مهمة في أبكر أسبوع ممكن: بعد انتهاء آخر اعتمادية لها، وليس قبل `not_before` إن وجدت، وهي الجدولة المبكرة As Soon As Possible.
4. يحسب لكل مهمة الفسحة Slack، وهي الأسابيع بين نهايتها وموعد تسليمها، فإذا كانت سالبة فهي خطأ، وإذا كانت أقل من الوقت الاحتياطي فهي تحذير.
5. يجمع ساعات كل عضو في كل أسبوع، ويحذر إذا تجاوزت ساعاته المتاحة.
6. يتحقق أن مهمة تقييم واحدة على الأقل تنتهي قبل أن يبدأ التقرير النهائي.
7. يحسب المسار الحرج Critical Path، وهو سلسلة المهام التي إذا تأخرت واحدة منها أسبوعاً تأخر المشروع كله أسبوعاً، ثم يكتب `schedule.json` و`gantt.mmd` و`gantt.svg`.

### التشغيل الأول First Run: تحذير لم نتوقعه

شغلنا البرنامج على النسخة الأولى من الخطة بهذا الأمر:

```bash
python plan_check.py plan.toml
```

والجزء المهم من المخرج كان كما يلي:

```text
 1-1  T01   m1,m3             1    مقابلة 5 طلاب وموظف شؤون الطلاب
 2-2  T02   m1                0    كتابة المقترح الأولي
...
critical path: T01 → T02 → T03 → T06 → T08 → T11 → T12 → T13 → T16 → T18 → T19 → T20  (ends week 30)
  ⚠ T02 ends week 2, only 0 week(s) before proposal (buffer 1)

result: 0 error(s), 1 warning(s)
```

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

```text
plan: Regulations Q&A assistant with article citations
members: 4  tasks: 20  milestones: 6

week  task  owners          slack  name
 0-0  T01   m1,m3             2    مقابلة 5 طلاب وموظف شؤون الطلاب
 1-1  T02   m1                1    كتابة المقترح الأولي
 2-5  T03   m2                3    جمع اللوائح وبناء 200 سؤال بإجاباتها
 2-4  T04   m1,m4             4    مراجعة الأعمال السابقة Related Work
 2-4  T05   m3,m4             4    المتطلبات SRS
 5-5  T07   m4                3    تقرير منتصف الفصل
 5-7  T09   m3                8    نموذج أولي للواجهة Prototype
 6-7  T06   m1,m2             8    تجربة جدوى Spike على 20 سؤالاً
 8-10 T08   m1,m4             5    التصميم SDD
 8-9  T10   m2,m4             6    خطة الاختبار والتقييم
11-11 T11   m1,m2,m3,m4       4    تقرير GP1 وعرضه
17-20 T12   m1,m2             4    الفهرسة والاسترجاع Retrieval
17-21 T14   m3                3    الواجهة Frontend
17-22 T15   m4                2    الاختبارات والتكامل المستمر CI
21-23 T13   m1                1    خدمة الإجابة مع ذكر المادة API
24-25 T16   m2                5    التقييم الآلي على 200 سؤال
24-25 T17   m3,m4             5    دراسة مستخدمين بمقياس SUS
26-27 T18   m1,m3             3    تحسينات بعد التقييم
28-29 T19   m1,m2,m3,m4       1    التقرير النهائي
30-30 T20   m1,m2,m3,m4       2    تدريب على المناقشة والعرض الحي

load (hours/week, max per member):
  m1 قائد الفريق والخلفية Backend: total 115h, peak 6h in week 17
  m2 البيانات والتقييم Evaluation: total 95h, peak 6h in week 2
  m3 الواجهة وتجربة المستخدم UX: total 104h, peak 6h in week 17
  m4 الاختبار والتوثيق والتكامل CI: total 107h, peak 8h in week 2

critical path: T01 → T02 → T03 → T06 → T08 → T11 → T12 → T13 → T16 → T18 → T19 → T20  (ends week 30)

result: 0 error(s), 0 warning(s)
```

والآن نقرأ المخرج سطراً سطراً:

- العمود الأول هو أسبوع البداية والنهاية، فالمهمة T03 تبدأ في الأسبوع 2 وتنتهي في الأسبوع 5، أي أربعة أسابيع، وهي مدتها في الملف.
- عمود slack هو الفسحة قبل التسليم، فالمهمة T13 «خدمة الإجابة» لها أسبوع واحد فقط قبل عرض النسخة العاملة في الأسبوع 24، وهذا يعني أنها أكثر مهمة يجب أن يراقبها الفريق في الفصل الثاني. أما T09 «النموذج الأولي للواجهة» فلها ثمانية أسابيع، أي أن مالكها يستطيع أن يساعد غيره دون خطر.
- لاحظ أن T06 «تجربة الجدوى» تبدأ في الأسبوع 6 وليس قبله، لأنها تعتمد على T03 «بناء الأسئلة»، فلا يمكن قياس شيء قبل أن توجد أسئلة. وهذا اعتماد يغفل عنه كثيرون عندما يرسمون الخطة يدوياً.
- تقرير GP1 ينتهي في الأسبوع 11 وموعده في الأسبوع 15، فهناك أربعة أسابيع فسحة. وقد تبدو هذه الفسحة كبيرة، ولكن الأسابيع الأخيرة من الفصل فيها اختبارات المواد الأخرى، والفريق الذي يترك تقرير الفصل الأول للأسبوع الرابع عشر يكتبه في أسوأ وقت.
- في قسم load نرى أن أعلى ساعات أسبوعية لأي عضو ست أو ثمان ساعات، أي أن الخطة لا تطلب من أحد أكثر مما يستطيع. ومجموع ساعات الأعضاء الأربعة 421 ساعة، وهذا الرقم تستطيع أن تقارنه بما يطلبه دليل قسمك عن حجم العمل.
- المسار الحرج اثنتا عشرة مهمة من عشرين، ويمر عبر بناء الأسئلة وتجربة الجدوى والاسترجاع وخدمة الإجابة والتقييم الآلي، وهذا منطقي لأن المشروع كله قائم على البيانات وقياسها، أما الواجهة فليست على المسار الحرج. فإذا سأل أحد «بأي مهمة نبدأ إذا كان لدينا وقت إضافي؟»، فالجواب: بأي مهمة على المسار الحرج.

![مخطط Gantt من مخرج البرنامج لعشرين مهمة على 32 أسبوعاً من اليمين إلى اليسار، المهام على المسار الحرج باللون البرتقالي والباقية بالأزرق، وخطوط حمراء متقطعة لمواعيد التسليم الستة: المقترح والمنتصف وGP1 وعرض النسخة العاملة والتقرير النهائي والمناقشة](https://arabroot.io/content/images/2026/11/graduation-project-guide-04-gantt.webp)

مخطط Gantt كما كتبه البرنامج في gantt.svg: البرتقالي هو المسار الحرج

### ماذا يحدث إذا صنعنا دائرة في الاعتماديات Dependency Cycle؟

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

```text
PLAN ERRORS
  ✖ dependency cycle between: T06, T08, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20
```

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

```text
PLAN ERRORS
  ✖ dependency cycle: T06 → T08 → T06
```

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

### ماذا يحدث إذا أعطينا الواجهة Frontend لقائد الفريق؟

في كثير من الفرق يعمل العضو الأقوى تقنياً على كل شيء، فجربنا أن نجعل مالك الواجهة T14 هو m1 بدل m3، وكانت النتيجة:

```text
critical path: T01 → T02 → T03 → T06 → T08 → T11 → T12 → T13 → T16 → T18 → T19 → T20  (ends week 30)
  ⚠ m1 over capacity 8h in: w17=12h, w18=12h, w19=12h, w20=12h, w21=12h

result: 0 error(s), 1 warning(s)
```

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

### ماذا يحدث إذا بدأ التقرير Report قبل التقييم Evaluation؟

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

```text
critical path: T01 → T02 → T03 → T06 → T08 → T11 → T12 → T13 → T16 → T18  (ends week 27)
  ⚠ m1 over capacity 8h in: w26=10h
  ⚠ m2 over capacity 8h in: w24=12h, w25=12h
  ⚠ m3 over capacity 8h in: w24=11h, w25=11h, w26=10h
  ⚠ m4 over capacity 8h in: w24=11h, w25=11h
  ⚠ T19 (report) starts week 24, before any evaluation ends

result: 0 error(s), 5 warning(s)
```

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

### مخطط Gantt في المستودع Mermaid

الملف `gantt.mmd` مكتوب بصيغة [Mermaid Gantt](https://mermaid.js.org/syntax/gantt.html?ref=arabroot.io)، وهذه أول أسطره:

```text
gantt
    title Regulations Q&A assistant with article citations
    dateFormat YYYY-MM-DD
    axisFormat %d/%m
    section GP1
    T01 مقابلة 5 طلاب وموظف شؤون الطلاب :crit, T01, 2026-12-27, 7d
    T02 كتابة المقترح الأولي :crit, T02, 2027-01-03, 7d
```

والتواريخ هنا محسوبة من تاريخ بداية افتراضي في البرنامج، فمرر تاريخ بداية فصلك الأول والثاني بالخيارين `--start` و`--start2`. والفائدة أن GitHub [يرسم مخططات Mermaid](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams?ref=arabroot.io) داخل ملفات Markdown، فإذا وضعت المحتوى في كتلة `mermaid` في ملف README يرى المشرف الخطة محدثة كلما فتح المستودع. والأفضل من ذلك أن تشغل `plan_check.py` في التكامل المستمر عند كل تعديل على `plan.toml`، فإذا أضاف أحد مهمة تصنع دائرة أو تتجاوز موعداً، يفشل الفحص قبل أن تدمج.

## Git والمهام Issues: إدارة الكود من اليوم الأول

الطريقة التي ما زالت منتشرة في مشاريع التخرج هي أن يرسل كل عضو ملفاته في مجموعة المحادثة أو على قرص مشترك، ثم يجمعها أحدهم قبل العرض. وهذه الطريقة تضيع الكود، وتضيع من كتب ماذا، وتمنعك من أن تعرض المشروع لاحقاً في سيرتك. والحد الأدنى المقبول اليوم هو مستودع Git واحد للمشروع من الأسبوع الأول، فيه الكود والوثائق وملف الخطة والمحاضر. وإذا لم تستخدم Git من قبل فابدأ بمقال [إدارة النسخ وGit للمبتدئين](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D9%88-git-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) ثم [Git merge وrebase وcherry-pick](https://arabroot.io/articles/git-merge-%D9%88-rebase-%D9%88-cherry-pick/).

واستخدم المهام Issues لكل شيء له مالك وموعد، فهي كما تقول [توثيق GitHub](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues?ref=arabroot.io) طريقة لتتبع الأفكار والملاحظات والمهام والأخطاء، وتستطيع أن تجمعها في لوحة [GitHub Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects?ref=arabroot.io) بأعمدة مثل «للعمل» و«قيد العمل» و«تم». واجعل كل مهمة في `plan.toml` مقابلة لـ Issue، وكل محطة تسليم Milestone في المستودع. والقاعدة الثانية أن لا يدفع أحد إلى الفرع الرئيسي مباشرة، فكل عمل في فرع، ثم طلب دمج Pull Request يراجعه عضو آخر قبل الدمج. وهذه المراجعة ليست بيروقراطية، فهي التي تجعل كل عضو يعرف شيئاً عن جزء غيره، وهذا ما تحتاجه في المناقشة عندما توجه اللجنة سؤالاً عن جزء لم تكتبه.

![مسار العمل في المستودع: مهمة Issue مربوطة بمحطة Milestone، ثم فرع Branch باسم المهمة، ثم طلب دمج Pull Request مع فحص CI يشغل الاختبارات وplan_check، ثم مراجعة عضو آخر، ثم الدمج في الفرع الرئيسي، ثم إغلاق المهمة تلقائياً، وتحتها ما يراه المشرف في كل خطوة](https://arabroot.io/content/images/2026/11/graduation-project-guide-05-git-flow.webp)

كل مهمة تمر بالمسار نفسه، والمشرف يرى التقدم من المستودع لا من الرسائل

وفي [GitHub Student Developer Pack](https://education.github.com/pack?ref=arabroot.io) يحصل الطالب الموثق على GitHub Pro مجاناً طوال فترة دراسته، وعلى GitHub Copilot Student، إضافة إلى عروض من شركات أخرى. ولكن انتبه إلى أمرين: الأول أن المستودع العام قد يتعارض مع شرط الجهة الشريكة إذا كانت البيانات أو الكود يخصها، فاسألها قبل أن تجعله عاماً، والثاني أن قسمك قد يكون له رأي في استخدام أدوات الذكاء الاصطناعي في الكود والتقرير، وهذا ما نناقشه بعد قليل.

## التوثيق Documentation: متى تحتاج وثيقة SRS ووثيقة SDD؟

كثير من الأقسام تطلب وثائق هندسة البرمجيات التقليدية، فدليل جامعة الملك سعود يذكر ضمن الوثائق الموصى بها خطة إدارة المشروع Project Management Plan، ووثيقة متطلبات المشروع، ووثيقة التصميم Design Document التي «توثق التصميم لتكون أساساً للتنفيذ واختبار الوحدات، وتصف سبب قرارات التصميم»، ووثيقة الاختبار التي توثق كيف سيختبر المشروع وتسجل النتائج. وأسماؤها الشائعة وثيقة مواصفات متطلبات البرمجيات SRS أي Software Requirements Specification، ووثيقة تصميم البرمجيات SDD أي Software Design Description. وكانت SRS تكتب تقليدياً على قالب معيار IEEE 830، ثم حل محله المعيار الدولي ISO/IEC/IEEE 29148 لهندسة المتطلبات، أما SDD فمعيارها IEEE 1016\. ولا تحتاج أن تقرأ المعايير كاملة، ولكن اعرف أسماءها، لأن بعض اللجان تسأل «على أي قالب كتبتم المتطلبات؟».

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

| متطلب لا يختبر              | متطلب يختبر                                                                           |
| --------------------------- | ------------------------------------------------------------------------------------- |
| يجب أن يجيب النظام بدقة     | يذكر النظام المادة الصحيحة ضمن أول ثلاث مواد في 85% على الأقل من مجموعة الاختبار      |
| يجب ألا يخترع النظام إجابات | يرفض النظام الإجابة في 90% على الأقل من الأسئلة الثلاثين التي ليس لها مادة في اللائحة |
| يجب أن يكون النظام سريعاً   | يعيد النظام الإجابة خلال 5 ثوان في 95% من الطلبات على الخادم المحدد في التصميم        |
| يجب أن يكون سهل الاستخدام   | متوسط درجة SUS من اثني عشر طالباً لا يقل عن 68                                        |

والأرقام في العمود الأيمن قرار يتخذه الفريق مع المشرف في المقترح، وليست أرقاماً من مرجع، والمهم أن تكون مكتوبة قبل البناء حتى لا تختار المقياس بعد أن ترى النتيجة. وإذا أردت أن تتعلم كتابة المتطلبات من البداية ففي [هندسة المتطلبات Requirements Engineering](https://arabroot.io/articles/%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-requirements-engineering/) الأساس، وفي [من فكرة غامضة إلى متطلبات واضحة](https://arabroot.io/articles/%D9%85%D9%86-%D9%81%D9%83%D8%B1%D8%A9-%D8%BA%D8%A7%D9%85%D8%B6%D8%A9-%D8%A7%D9%84%D9%89-%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D9%88%D8%A7%D8%B6%D8%AD%D8%A9-%D9%85%D8%AB%D8%A7%D9%84-%D8%B9%D9%85%D9%84%D9%8A/) مثال عملي كامل. أما وثيقة التصميم فلا تكتبها نصاً طويلاً، وإنما مخططات معمارية بمستويات C4 وسجل قرارات معمارية ADR لكل قرار مهم، وهذا ما يشرحه [توثيق المعمارية: مخططات C4 وADR](https://arabroot.io/articles/%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-c4-%D9%88-adr/). وسجل القرارات بالذات مفيد في المناقشة، لأن أكثر أسئلة اللجنة تبدأ بـ «لماذا اخترتم…؟».

## الاختبار Testing والتقييم Evaluation: الفرق بينهما

يخلط كثير من الطلاب بين الاختبار والتقييم، ويكتبون في التقرير فصلاً واحداً اسمه «الاختبار» فيه جدول من حالات اختبار يدوية كلها «ناجحة». والفرق بينهما أن الاختبار يجيب عن سؤال: هل بنينا النظام بشكل صحيح؟ أي هل يعمل كل جزء كما صمم، وهذا ما تفعله اختبارات الوحدة Unit Tests واختبارات التكامل Integration Tests واختبارات النظام. أما التقييم فيجيب عن سؤال آخر: هل بنينا النظام الصحيح، وهل يحل المشكلة؟ وهذا ما تفعله مجموعة التقييم ودراسة المستخدمين والمقارنة بخط الأساس. والمشروع الذي فيه اختبارات فقط يثبت أن الكود يعمل، والمشروع الذي فيه تقييم يثبت أن الفكرة تعمل، واللجنة تريد الاثنين.

وللاختبارات اكتب اختبارات آلية تعمل مع كل طلب دمج، وابدأ بها من الأسبوع الأول في الفصل الثاني لا في الأسبوع الأخير، وفي [أنواع الاختبارات للمبتدئين](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-unit-%D9%88-integration-%D9%88-e2e/) شرح الأنواع ومتى تستخدم كل نوع، وإذا طلب قسمك وثيقة اختبار رسمية بحالات مرقمة فقد تفيدك أداة مثل Kiwi TCMS التي يشرحها [مقال إدارة حالات الاختبار](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%A7%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D9%85%D8%B9-kiwi-tcms/).

### كيف تثبت أن المشروع يعمل؟ خطة التقييم Evaluation Plan

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

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

### دراسة المستخدمين User Study بمقياس SUS

أبسط طريقة معروفة لقياس سهولة الاستخدام في مشروع تخرج هي مقياس سهولة استخدام النظام System Usability Scale، واختصاراً SUS، وقد [ابتكره John Brooke في شركة DEC سنة 1986](https://usabilitybok.org/sus/?ref=arabroot.io) بحسب الدليل المعرفي لجمعية محترفي تجربة المستخدم UXPA، وهو عشرة أسئلة قصيرة يجيب عنها المستخدم على مقياس من خمس درجات بعد أن يجرب النظام، ثم تحول الإجابات إلى درجة من 0 إلى 100\. وبحسب [تحليل Jeff Sauro لنتائج خمسمئة دراسة](https://measuringu.com/sus/?ref=arabroot.io) فإن متوسط درجة SUS هو 68، فالنظام الذي يحصل على أكثر من 68 أعلى من المتوسط، مع ملاحظة مهمة يكررها هو نفسه: الدرجة ليست نسبة مئوية، فدرجة 68 تعني أن النظام في منتصف الأنظمة، وليس أنه حقق 68% من الكمال.

ودراسة المستخدمين لا تعني توزيع استبانة على مجموعة الدفعة، وإنما أن تجلس مع كل مستخدم وتعطيه مهاماً محددة: «اعرف هل يحق لك الاعتذار عن الفصل الحالي»، ثم تراقبه وتسجل هل أنجز المهمة وكم استغرق وأين تردد، ثم يملأ استبانة SUS. وإذا كانت الدراسة على بشر داخل الجامعة فاسأل مشرفك هل تحتاج موافقة لجنة أخلاقيات البحث في جامعتك، وهذا يختلف بين الجامعات وبحسب نوع البيانات التي تجمعها، وتفصيله في [أخلاقيات البحث على البشر](https://arabroot.io/articles/%D8%A7%D8%AE%D9%84%D8%A7%D9%82%D9%8A%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D8%A8%D8%B4%D8%B1-%D9%85%D9%86-%D9%84%D8%AC%D9%86%D8%A9-irb-%D8%A7%D9%84%D9%89-%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA/).

## فصول التقرير Final Report: ماذا يكتب في كل فصل؟

التقرير النهائي هو ما يبقى من المشروع في مكتبة القسم بعد أن تتخرج، وهو أول ما تقرؤه اللجنة قبل أن تراك. ويحدد دليل قسم نظم المعلومات في جامعة الإمام الفصول بهذا الترتيب: المقدمة، ثم الخلفية Background، ثم تحليل المتطلبات Requirements Analysis، ثم تصميم النظام System Design، ثم تنفيذ النظام System Implementation، ثم الخاتمة والعمل المستقبلي Conclusion and Future Work، ثم المراجع والملاحق. ودليل جامعة الملك سعود يطلب في تقرير منتصف الفصل الأول مقدمة فيها المشكلة والأهداف والحل والنطاق، ثم الخلفية، ثم مراجعة الأدبيات Literature Review، ويطلب في قوالبه ملخصاً بالإنجليزية لا يقل عن 500 كلمة وملخصاً بالعربية. والذي ينقص هذا الترتيب في كثير من القوالب هو فصل مستقل للاختبار والتقييم والنتائج، فإذا لم يكن في قالب قسمك فاسأل المشرف أن تضيفه، أو اجعله جزءاً واضحاً من فصل التنفيذ.

![ثمانية فصول للتقرير مرتبة بحسب الفصل الدراسي الذي تكتب فيه: المقدمة والخلفية والأعمال السابقة والمتطلبات والتصميم في الفصل الأول، والتنفيذ والاختبار والتقييم والخاتمة في الفصل الثاني، ولكل فصل سؤال تجيب عنه والوثيقة التي يأتي منها مثل SRS وSDD وplan.toml ومجموعة التقييم](https://arabroot.io/content/images/2026/11/graduation-project-guide-06-report.webp)

كل فصل في التقرير يجيب عن سؤال واحد، ونصفه تقريباً يكتب في الفصل الأول

وهذا ما يجب أن يكون في كل فصل باختصار:

1. المقدمة Introduction: المشكلة بالأدلة، والأهداف القابلة للقياس، والنطاق بما فيه ما لن تفعله، وملخص لما حققته. واللجنة تقرأ المقدمة لتعرف هل تعرف ما تريد.
2. الخلفية Background: المفاهيم التي يحتاجها قارئ من خارج تخصصك الدقيق، مثل الاسترجاع والتضمين Embeddings في مشروع الفريق، بقدر ما يفهم ما بعدها، لا محاضرة كاملة.
3. الأعمال السابقة Related Work: الحلول والأبحاث القريبة مقارنة في جدول، وما الذي يضيفه مشروعك.
4. المتطلبات Requirements: من وثيقة SRS، المتطلبات الوظيفية وغير الوظيفية القابلة للاختبار، وحالات الاستخدام Use Cases.
5. التصميم Design: من وثيقة SDD، المعمارية والبيانات والواجهات، وقرارات التصميم مع أسبابها والبدائل التي رفضتها.
6. التنفيذ Implementation: ما بنيته فعلاً وكيف، والأدوات، وما اختلف عن التصميم ولماذا. ولا تضع الكود في التقرير، فهو في المستودع، وضع ما يشرح الفكرة.
7. الاختبار والتقييم Testing and Evaluation: الاختبارات وتغطيتها، ثم التقييم بالأرقام مقارنة بخط الأساس، ثم تحليل الأخطاء، ثم دراسة المستخدمين.
8. الخاتمة Conclusion: ما حققته مقابل كل هدف في المقدمة، والقيود Limitations بصدق، والعمل المستقبلي.

وفي أسلوب الكتابة تذكر ثلاثة أشياء. الأول أن كل فصل يكتبه صاحبه، ثم يوحد عضو التوثيق الأسلوب والتنسيق، وهذا أفضل من أن يكتب عضو واحد كل شيء. والثاني أن أغلب الأقسام تفحص التقرير بأداة تشابه، فدليل جامعة الملك سعود يذكر Turnitin وSafeAssign، ونسبة التشابه وحدها لا تعني الانتحال، وتفصيل قراءة التقرير في [نسبة التشابه Similarity وتقرير iThenticate](https://arabroot.io/articles/%D9%86%D8%B3%D8%A8%D8%A9-%D8%A7%D9%84%D8%AA%D8%B4%D8%A7%D8%A8%D9%87-similarity-%D9%88%D8%AA%D9%82%D8%B1%D9%8A%D8%B1-ithenticate/). والثالث أن استخدام أدوات الذكاء الاصطناعي في الكتابة له حدود تختلف بين الجامعات، فاقرأ سياسة جامعتك واسأل مشرفك، وفي [الذكاء الاصطناعي في الكتابة الأكاديمية](https://arabroot.io/articles/%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A-%D9%81%D9%8A-%D8%A7%D9%84%D9%83%D8%AA%D8%A7%D8%A8%D8%A9-%D8%A7%D9%84%D8%A7%D9%83%D8%A7%D8%AF%D9%8A%D9%85%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B3%D9%85%D9%88%D8%AD-%D9%88%D8%A7%D9%84%D9%85%D9%85%D9%86%D9%88%D8%B9/) ما هو مقبول عادة وما ليس مقبولاً. وأما أداة الكتابة نفسها، Word أو LaTeX، فقد قارنا بينهما في [Word أم LaTeX لكتابة الرسالة](https://arabroot.io/articles/word-%D8%A7%D9%85-latex-%D9%84%D9%83%D8%AA%D8%A7%D8%A8%D8%A9-%D8%A7%D9%84%D8%B1%D8%B3%D8%A7%D9%84%D8%A9-%D9%88%D8%A7%D9%8A%D9%86-%D9%8A%D9%82%D9%81-quarto/).

## المناقشة Defense: كيف تستعد لها؟

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

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

### أسئلة اللجنة Committee Questions

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

| نوع السؤال                   | أمثلة                                                                            | ما تبحث عنه اللجنة                         |
| ---------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------ |
| المشكلة Problem              | كيف عرفتم أن المشكلة حقيقية؟ ماذا يفعل الطالب اليوم دون نظامكم؟                  | أدلة من مستخدمين، لا رأي الفريق            |
| الأعمال السابقة Related Work | ما الفرق بين مشروعكم وما تقدمه أدوات المحادثة العامة لو أعطيناها اللائحة؟        | أنكم تعرفون البدائل وجربتموها              |
| التصميم Design               | لماذا هذه المعمارية؟ ماذا لو تغيرت اللائحة غداً؟ ما البديل الذي رفضتموه؟         | قرارات بأسبابها، وفهم للمقايضات Trade-offs |
| التقييم Evaluation           | من كتب أسئلة التقييم؟ هل رآها النظام أثناء البناء؟ ما أسوأ نوع من الأخطاء؟       | أن الأرقام لا تخدع، وأنكم حللتم الفشل      |
| التنفيذ Implementation       | اشرح هذا الجزء من الكود. ماذا يحدث إذا تعطلت الخدمة الخارجية؟                    | أن كل عضو يفهم ما كتب وما كتبه غيره        |
| الفريق Teamwork              | ماذا عمل كل واحد منكم؟ ما أكبر خلاف بينكم وكيف حللتموه؟                          | مساهمة فردية حقيقية، وتعامل ناضج           |
| الأخلاقيات Ethics            | ماذا لو أعطى النظام إجابة خاطئة وتصرف الطالب بناءً عليها؟ أين تحفظ أسئلة الطلاب؟ | وعي بالمسؤولية المهنية والخصوصية           |

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

![مخطط العرض في المناقشة في عشرين دقيقة: المشكلة دقيقتان، والحل ثلاث دقائق، والتجربة الحية ست دقائق مع فيديو احتياطي، والنتائج أربع دقائق، والقيود والعمل المستقبلي دقيقتان، ثم أسئلة اللجنة، وبجانبه ما يجب أن يكون جاهزاً قبل يوم المناقشة](https://arabroot.io/content/images/2026/11/graduation-project-guide-07-defense.webp)

توزيع مقترح لوقت العرض، وما يجب تجهيزه قبل يوم المناقشة

## أخطاء شائعة Common Mistakes تسقط المشاريع

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

## كيف تعرض المشروع في سيرتك الذاتية CV؟

بعد التخرج بأسابيع ستكتب سيرتك الذاتية، وسيكون مشروع التخرج أكبر سطر فيها إذا لم تكن لديك خبرة عمل. والطريقة المعتادة أن يكتب الطالب اسم المشروع والتقنيات: «مساعد ذكي للوائح الجامعة باستخدام Python وReact». وهذه الجملة تقول ماذا استخدمت، ولا تقول ماذا فعلت ولا ماذا حققت. والأفضل أن تكتب سطرين أو ثلاثة بهذا الشكل: ما بنيته أنت، والرقم الذي حققه، والرابط.

```text
مساعد أسئلة لوائح الدراسة مع ذكر المادة (مشروع التخرج، فريق من 4، 2026-2027)
- بنيت خدمة الاسترجاع والإجابة (Python, FastAPI)، ورفعت ظهور المادة الصحيحة في أول 3 نتائج
  من (خط الأساس)% إلى (النتيجة)% على مجموعة تقييم من 200 سؤال بنيناها
- github.com/(الحساب)/(المستودع): الكود والاختبارات وتقرير التقييم
```

والأقواس في المثال تملؤها بأرقامك الحقيقية من فصل التقييم، ولا تكتب رقماً لم تقسه، لأن أول سؤال في المقابلة سيكون «كيف قستم هذا؟». واجعل المستودع نفسه جاهزاً لمن يفتحه: ملف README يشرح المشكلة في فقرة، وصورة للنظام، وطريقة التشغيل في ثلاثة أوامر، ورابط التقرير. وفي المقابلة سيطلب منك أن تشرح المشروع في دقيقتين، ثم يسألك عن أصعب قرار وأكبر خطأ، وهذه الأسئلة نفسها التي استعددت لها للمناقشة، وتجد كيف تستعد لها في [كيف تستعد لمقابلة التدريب](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B3%D8%AA%D8%B9%D8%AF-%D9%84%D9%85%D9%82%D8%A7%D8%A8%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D8%AF%D8%B1%D9%8A%D8%A8-internship-%D9%88%D8%A7%D9%86%D8%AA-%D8%B7%D8%A7%D9%84%D8%A8/) و[كيف تستعد لمقابلة مطور برمجيات في أسبوعين](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B3%D8%AA%D8%B9%D8%AF-%D9%84%D9%85%D9%82%D8%A7%D8%A8%D9%84%D8%A9-%D9%85%D8%B7%D9%88%D8%B1-%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%81%D9%8A-%D8%A7%D8%B3%D8%A8%D9%88%D8%B9%D9%8A%D9%86/).

## قائمة تحقق Checklist لكل مرحلة

| المرحلة               | قبل أن تنتقل إلى التالية تأكد من                                                                                                       |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| قبل الفصل الأول       | قرأتم دليل مشروع التخرج في القسم، واتفقتم على المشرف، وأجريتم خمس مقابلات على الأقل، ومررتم الأفكار على الأسئلة الخمسة                 |
| المقترح Proposal      | المشكلة بالأدلة، والأهداف SMART، والنطاق بتقسيم MoSCoW مع فئة Won't، وخطة تقييم فيها أرقام، وخطة زمنية تمر من plan\_check.py دون أخطاء |
| منتصف الفصل الأول     | مستودع واحد فيه الكود والوثائق والمحاضر، والأعمال السابقة في جدول، وتجربة الجدوى بدأت أو انتهت                                         |
| نهاية الفصل الأول GP1 | SRS بمتطلبات قابلة للاختبار، وSDD بقرارات وأسبابها، ومجموعة التقييم جاهزة، وخط الأساس محسوب                                            |
| منتصف الفصل الثاني    | نسخة تعمل من طرف إلى طرف End-to-End، واختبارات آلية في كل طلب دمج، وملاحظات اللجنة من GP1 معالجة                                       |
| قبل التقرير النهائي   | التقييم منته على مجموعة لم يرها النظام، وتحليل الأخطاء مكتوب، ودراسة المستخدمين منتهية                                                 |
| قبل المناقشة          | التجربة الحية مجربة على جهاز العرض، وفيديو احتياطي، وكل عضو أجاب عن أسئلة الجدول بصوت عال، وREADME المستودع جاهز                       |

## الخلاصة Summary

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

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

[![](https://arabroot.io/content/images/2026/10/tech-majors-cover-cover.webp)دليلأي تخصص تقني تختار؟ ما تدرسه فعلاً وأين تعمل بعدهماذا تدرس فعلاً في كل تخصص تقني بحسب الخطط الدراسية السعودية، وأين يعمل خريجوه، ومتى يهم اسم التخصص ومتى تهم المهارة.](https://arabroot.io/articles/%D8%A7%D9%8A-%D8%AA%D8%AE%D8%B5%D8%B5-%D8%AA%D9%82%D9%86%D9%8A-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D9%85%D8%A7-%D8%AA%D8%AF%D8%B1%D8%B3%D9%87-%D9%88%D8%A7%D9%8A%D9%86-%D8%AA%D8%B9%D9%85%D9%84/)[![](https://arabroot.io/content/images/2026/10/major-cs-guide-cover-cover.webp)دليلتخصص علوم الحاسب Computer Science: منهج CS2023 ومواد الجامعةلماذا وضعت كل مادة في خطة علوم الحاسب بحسب منهج CS2023، وأين تقصر خطط الجامعات السعودية، وكيف تكمل ما ينقصك بنفسك.](https://arabroot.io/articles/%D8%AA%D8%AE%D8%B5%D8%B5-%D8%B9%D9%84%D9%88%D9%85-%D8%A7%D9%84%D8%AD%D8%A7%D8%B3%D8%A8-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84-%D9%85%D9%86%D9%87%D8%AC-cs2023/)[![](https://arabroot.io/content/images/2026/10/major-se-guide-cover-cover.webp)دليلتخصص هندسة البرمجيات Software Engineering: منهج SE2014ما الذي يجعل المبرمج مهندساً بحسب منهج SE2014 ودليل SWEBOK، وماذا تعطيك خطط الجامعات السعودية منه، وكيف تكمل الباقي بنفسك.](https://arabroot.io/articles/%D8%AA%D8%AE%D8%B5%D8%B5-%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84-%D9%85%D9%86%D9%87%D8%AC-se2014/)[![](https://arabroot.io/content/images/2026/10/requirements-engineering-cover-cover.webp)دليلهندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنىما هو المتطلب Requirement، وكيف تجمعه وتكتبه وتراجعه وتدير تغييره، ولماذا تفشل مشاريع كبيرة عندما تهمل هذه الخطوة.](https://arabroot.io/articles/%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-requirements-engineering/)[![](https://arabroot.io/content/images/2026/10/architecture-docs-cover-cover.webp)دليلتوثيق المعمارية: مخططات C4 وسجلات القرارات المعمارية ADRكيف ترسم نظامك بمخططات C4 يفهمها المطور الجديد، وتحفظ سبب كل قرار مهم في سجل ADR داخل المستودع.](https://arabroot.io/articles/%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-c4-%D9%88-adr/)[![](https://arabroot.io/content/images/2026/10/testing-types-cover-cover.webp)دليلأنواع الاختبارات للمبتدئين: من Unit إلى E2E مع Playwrightما الذي يكشفه كل نوع من الاختبارات وما الذي يفوته، وكم اختباراً تكتب من كل نوع، وأين يعمل كل منها في خط CI.](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-unit-%D9%88-integration-%D9%88-e2e/)[![](https://arabroot.io/content/images/2026/10/git-basics-cover-cover.webp)دليلإدارة النسخ وGit للمبتدئين: لماذا نحتاجها وكيف تعمللماذا تضيع الملفات بأسماء final\_v2 ويمسح الزملاء عمل بعضهم، وكيف يحل Git ذلك على مشروع حقيقي من أول commit.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D9%88-git-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/research-proposal-cover-cover.webp)دليلكيف تكتب مقترح البحث Research Proposal الذي يقنع الممول؟أقسام المقترح البحثي وكيف يقيمه الممولون، وأين تتقدم للتمويل في السعودية، مع قالب جاهز وسكربت يفحص ميزانيتك.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-research-proposal-%D8%A7%D9%84%D8%B0%D9%8A-%D9%8A%D9%82%D9%86%D8%B9-%D8%A7%D9%84%D9%85%D9%85%D9%88%D9%84/)

## سجل التحديثات Changelog

- نوفمبر 2026: كتابة الدليل، وقراءة أدلة مشاريع التخرج في جامعة الملك سعود (علوم الحاسب، 2016) وجامعة الملك فيصل (2019) وجامعة الإمام (نظم المعلومات، 2018) ومعايير ABET لبرامج الحوسبة 2026-2027، وتشغيل plan\_check.py على Python 3.13.3 مع ثلاث تجارب «ماذا يحدث إذا».