مواصفة سير العمل
التسلسل الدقيق للخطوات ونقاط القرار والاستثناءات والتسليمات اللي الحل لازم يدعمها — مبنية على نموذج سير العمل الحالي المُنتَج أثناء الاكتشاف، لا عملية مثالية مُعاد تخيّلها.
تصميم الحل · الخطوة 03 · طريقة عملنا
المواصفة ليست تخمينًا.
الاستراتيجية والبنية بتحدد إزاي النظام لازم يتبنى. تصميم الحل بيحدد بالظبط إيه اللي هيتبنى — سير العمل والواجهات وعقود البيانات وسلوكيات الفشل المحددة اللي بتحوّل الاتجاه الهندسي لحاجة الفريق يقدر فعليًا يبنيها.
المرحلة دي ما بتبدأش بتنفيذ. بتبدأ بمواصفة اتُختبرت مقابل أدلة قبل ما يُكتب سطر واحد من الكود الإنتاجي.
مش السؤال ده
"إيه اللي المفروض نبنيه؟"
لكن السؤال ده
"هل التصميم المحدد ده فعليًا بيتصرف زي ما متوقّع، تحت الظروف اللي هيواجهها فعلاً — وهل نقدر نثبت كده قبل ما نلتزم بجهد هندسي لبنائه؟"
التصميم · النموذج الأولي · الاختبار · القياس · المواصفة
ليه التصميم بييجي بعد البنية
البنية لسه مش نظام.
البنية المرجعية من المرحلة اللي فاتت بتحدد الطبقات واختيارات التكنولوجيا والاهتمامات الشاملة. لكنها لسه ما بتحددش إزاي سير عمل معين لازم يتصرف لما طلب يكون غامض، أو إيه اللي بيحصل لما تكامل معين بيرجّع بيانات مشوّهة. تصميم الحل بيسد الفجوة دي — من غيره، "البنية" بتفضل مجرد رسم بياني، مش نظام.
البنية المرجعية → مواصفة الحل
ليه صرامة التصميم مهمة
تكلفة الخطأ بتكبر مع كل مرحلة يعدّيها من غير ما يُكتشف.
بحث Barry Boehm في اقتصاديات هندسة البرمجيات — اللي اتنشر أول مرة سنة 1976 وتوسّع في كتابه Software Engineering Economics سنة 1981 — وجد إن تكلفة تصحيح عيب بتكبر بشكل كبير كل ما اكتشافه بيتأخر.
~1×
تكلفة إصلاح عيب اتكشف أثناء التصميم.
Boehm، Software Engineering Economics (1981)؛ Boehm & Basili، IEEE Computer (2001).
10×–100×
تكلفة إصلاح نفس العيب بعد النشر الإنتاجي، حسب حجم المشروع.
Boehm، Software Engineering Economics (1981)؛ Boehm & Basili، IEEE Computer (2001).
النتيجة دي اتراجعت لاحقًا. مراجعة Boehm وBasili نفسها سنة 2001 وجدت إن المنحنى بيبقى أكثر تسطحًا للفرق الصغيرة اللي بتشتغل بتكرار سريع وباختبار قوي وتسليم مستمر. المضاعِف مش عام، وإحنا ما بنتعاملش معاه على إنه كده.
لكن اتجاه النتيجة ما اتقلبش: اكتشاف عيب في التصميم قبل ما يتبنى أرخص من اكتشافه بعد كده. لذلك OpenQCore بتعامل مع النموذج الأولي والاختبار كجزء من التصميم نفسه — مش كمرحلة بتحصل بعد ما البناء يكون بدأ فعلاً.
من البنية إلى المواصفة
تحويل الطبقات لقرارات الفريق يقدر يبني منها.
كل قرار بنية من المرحلة اللي فاتت بيتحلل لمواصفات ملموسة.
مواصفة الواجهة
إيه اللي كل مستخدم أو نظام أو وكيل فعليًا بيشوفه ويرسله ويستقبله — الشاشات، وتدفقات المحادثة، وعقود API، والحقول المهمة في كل خطوة.
مواصفة عقد البيانات
الشكل الدقيق وقواعد التحقق ومنهج الإصدارات وملكية البيانات المتحركة بين المكوّنات.
المواصفة السلوكية
إيه اللي النظام بيعمله — وما بيعملوش صراحةً — تحت الظروف العادية، والحالات الحدّية، وظروف الفشل.
المخرج
مواصفة الحل (مسودة)
تصميم سير العمل والتفاعل
صمّم العمل، لا الواجهة فقط.
واجهة تفاعلية فوق سير عمل معطّل مش بتصلح سير العمل — بتخفيه بس، لحد ما القيد الأساسي يظهر في مكان تاني.
تصميم الحل بيبدأ من أدلة سير العمل اللي اتجمعت أثناء الاكتشاف، وبيسأل سؤال بنيوي قبل سؤال الواجهة: أي خطوات في العملية دي لازم تتمتّت، وأيها لازم تفضل بشرية، وفين بالظبط المسؤولية بتتسلّم بينهم؟ بنرسم ده صراحةً، بحيث تكون نقاط الإشراف البشري قرار تصميم مقصود — لا صدفة ناتجة عن قدرة التكنولوجيا.
نقاط الإشراف البشري
نقاط تفتيش صريحة فيها لازم مراجعة أو حكم أو تفويض بشري بالتصميم — لا بالإغفال.
حدود الأتمتة
حدود محددة بدقة لما يُسمح للنظام يقرره أو ينفّذه من غير موافقة بشرية.
مسارات الاستثناءات
مسارات مصمَّمة للحالات اللي بتخرج عن المعالجة العادية — لا فشل صامت ولا معالجة افتراضية.
النماذج الأولية والتجريب
التصميم كفرضية قابلة للاختبار، لا إجابة نهائية.
OpenQCore بتعامل مع التصميم المبكر بالطريقة اللي علم التصميم بيعامل بيها أي artifact في أنظمة المعلومات: حاجة اتبنت خصيصًا عشان تُقيَّم مقابل مشكلة حقيقية، لا مجرد يُعجَب بيها لأناقتها. المنهج ده — اللي اتصاغ في بحث Hevner وزملائه المؤثر Design Science in Information Systems Research (MIS Quarterly، 2004) — بيعامل الـartifact وتقييمه كشيء واحد لا ينفصل. بنطبّق نفس الاستدلال المبني على الفرضيات اللي استخدمناه أثناء الاكتشاف، على مستوى التصميم.
01
التصميم
قرار تصميم محدد وقابل للدحض — لا اتجاه غامض.
02
النموذج الأولي
تمثيل عملي كافٍ لاختبار القرار — مش بالضرورة بجودة إنتاجية.
03
الاختبار ببيانات تمثيلية
مدخلات حقيقية أو تمثيلية واقعيًا، لا أمثلة مثالية مُختارة عشان تنجح.
04
القياس مقابل خط الأساس
مقارنة مقابل خط الأساس ومعايير النجاح اللي اتحددت أثناء الاكتشاف — لا انطباع ذاتي عن الجودة.
05
التحسين أو الرفض
التصميم بيفضل أو يتعدّل أو يُرفَض بناءً على ما أظهره الاختبار — لا بناءً على قد إيه شغل اتعمل فيه بالفعل.
هدف النموذج الأولي مش إثبات إن التصميم ممكن يشتغل. الهدف هو تحديد هل بيشتغل فعليًا وباستمرار، تحت الظروف اللي النظام النهائي هيواجهها فعلاً.
مواصفة البيانات والواجهة
الدقة هنا بتمنع الغموض لاحقًا.
فشل التكامل نادرًا ما ينشأ من قرار واحد خاطئ بشكل واضح. غالبًا بينشأ من الغموض — حقل افتُرض إنه دايمًا موجود، حالة خطأ محدش كتبها، عدم تطابق إصدارات محدش خطط له.
تعريفات المخططاتقواعد التحققمعالجة الأخطاء والاستثناءاتاستراتيجية الإصداراتحدود المعدل والحملعقود المصادقة والتفويضمتطلبات المطابقة عند التكرار
ده شغل مقصود إنه غير براق. لكنه كمان الشغل اللي بيحدد هل النظام اللي بيشتغل كويس في العرض التوضيحي هيفضل يشتغل كويس في الإنتاج، بعد 6 تكاملات و18 شهر.
التصميم للفشل، لا للنجاح فقط
كل عرض توضيحي بينجح. مش كل نظام.
أغلب فشل التصميم مش فشل في المسار السعيد. هو فشل في إيه اللي بيحصل لما حاجة تغلط — نظام سابق بياخد وقت أطول، مستند مش بيتستخرج بشكل نظيف، نموذج غير متأكد، مستخدم بيعمل حاجة غير متوقعة. OpenQCore بتصمم الحالات دي بشكل مقصود بدل ما تكتشفها في الإنتاج.
التعامل مع عدم اليقين
إيه اللي النظام بيعمله لما الثقة في مخرج معين تكون منخفضة — بما في ذلك هل وإزاي بيقول كده.
التدهور التدريجي
أي وظائف بتفضل متاحة لما تبعية معينة تفشل، بدل انقطاع كامل للنظام.
تصميم التصعيد
الظروف المحددة اللي عندها الحالة بتتسلّم لإنسان، وإيه السياق اللي التسليم ده بيحمله معاه.
السلوك تحت الحالات العدائية والحدّية
إزاي النظام بيتصرف تحت مدخلات مشوّهة، أو تسلسلات غير متوقعة، أو محاولات سوء استخدام — لا الطلبات المنظَّمة بس.
نظام محدش سأله "إيه اللي بيحصل لما ده يفشل؟" ما اتصممش فعليًا. اتعرض بس.
معايير التحقق المحددة قبل البناء
معايير القبول بتيجي قبل الكود، لا بعده.
اتساقًا مع المبدأ اللي اتأسس أثناء الاكتشاف — إن النجاح لازم يتحدد قبل التنفيذ — تصميم الحل بينتج معايير قبول صريحة ومكتوبة وخطة اختبار قبل ما يبدأ التطوير الإنتاجي.
معايير القبول الوظيفية
إيه اللي الحل لازم يعمله بشكل صحيح، مذكور بشروط قابلة للاختبار.
معايير القبول غير الوظيفية
اتساقًا مع خصائص جودة البرمجيات المعترف بها — بما فيها كفاءة الأداء والموثوقية وسهولة الاستخدام والأمان وقابلية الصيانة، كما نظّمها نموذج جودة البرمجيات ISO/IEC 25010 — محددة كأهداف قابلة للقياس لا طموحات عامة.
خطة الاختبار
السيناريوهات ومجموعات البيانات والظروف المحددة اللي الحل هيتقيَّم مقابلها قبل ما يُعتبَر جاهز للبناء بشكله الإنتاجي.
بوابة مراجعة التصميم
التصميم بينتهي بقرار — لا موافقة تلقائية.
الممارسة دي ليها سابقة: منهج Michael Fagan الرسمي لفحص التصميم والكود، اللي اتقدّم في IBM سنة 1976، أثبت إن المراجعة المنظَّمة المبنية على معايير بتكتشف العيوب أبكر وأكثر موثوقية من الموافقة غير الرسمية. OpenQCore بتطبّق نفس المبدأ على تصميم الحل.
المتابعة للبناء
المواصفة دقيقة بشكل كافٍ، والنموذج الأولي حقق معايير التقييم، والتطوير يقدر يبدأ.
تكرار التصميم
الاتجاه الأساسي صحيح، لكن عناصر محددة محتاجة مراجعة بناءً على ما أظهره الاختبار.
العودة للبنية
شغل التصميم كشف قيد ما كانتش البنية أخدته في الحسبان — الاستجابة الصحيحة هي مراجعة البنية، لا التصميم حوالين القيد.
تصعيد المخاطر
شغل التصميم كشف مخاطرة — تقنية أو تشغيلية أو أمنية أو أخلاقية — محتاجة قرار أعلى من صلاحية فريق التصميم قبل المتابعة.
بوابة تصميم دايمًا بتقول نعم مش بوابة أصلاً.
مخرجات تصميم الحل
مواصفات الفريق يقدر فعليًا يبني منها.
حسب نطاق المشروع، المرحلة دي بتنتج:
وثيقة مواصفة الحل
سير العمل والواجهات وعقود البيانات والسلوك، بتفصيل كافٍ للبناء منها من غير إعادة استنتاج القصد.
رسومات التفاعل وسير العمل
تمثيلات بصرية لتدفق العملية، بما فيها نقاط الإشراف البشري الصريحة.
عقود API والبيانات
المخططات وقواعد التحقق واستراتيجية الإصدارات لكل واجهة بين المكوّنات.
تقرير تقييم النموذج الأولي
إيه اللي اتُختبر، مقابل أي خط أساس، وإيه اللي النتائج بتدعمه أو تستبعده.
تحليل أنماط الفشل
ظروف الفشل الموثَّقة واستجابة النظام المصمَّمة لكل واحدة منها.
معايير القبول وخطة الاختبار
الظروف المحددة والقابلة للقياس اللي الحل المبني لازم يحققها قبل النشر.
من التصميم إلى التطوير والتكامل
المواصفة لسه مش برمجيات.
تصميم الحل بينتج مواصفة مُختبرة ومعتمَدة — لا نظام نهائي. المرحلة الجاية بتحوّل المواصفة دي لبرمجيات فعلية، متكاملة مع الأنظمة اللي لازم تشتغل جنبها.
مواصفة الحل → تقييم النموذج الأولي → معايير القبول → التطوير والتكامل
الخطوة 04
التطوير والتكامل
بناء الحل المحدد مقابل معايير قبول محددة — لا مقابل افتراض.
مراجع البحث والمنهجية
Boehm, B. — Software Engineering Economics (1981)؛ Boehm, B. & Basili, V. — "Software Defect Reduction Top 10 List," IEEE Computer (2001)
مصدر نتائج تكلفة التغيير المُشار إليها أعلاه، بما في ذلك المراجعة اللاحقة اللي أظهرت منحنى أكثر تسطحًا للفرق الصغيرة السريعة التكرار.
Hevner, A., March, S., Park, J., & Ram, S. — "Design Science in Information Systems Research," MIS Quarterly (2004)
إطار عمل تأسيسي للتعامل مع artifact أنظمة المعلومات وتقييمه كشيء واحد لا ينفصل — أساس دورة النموذج الأولي والاختبار والتحسين الموصوفة أعلاه.
Fagan, M. — "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal (1976)
أصل مراجعة التصميم المنظَّمة المبنية على معايير كممارسة هندسية رسمية، المُشار إليها في بوابة مراجعة التصميم أعلاه.
ISO/IEC 25010:2011 — متطلبات وتقييم جودة الأنظمة والبرمجيات (SQuaRE) — نماذج جودة النظام والبرمجيات
مصدر خصائص الجودة غير الوظيفية المُشار إليها في معايير القبول أعلاه.