الرئيسية/منهجيتنا الهندسية
OUR ENGINEERING PROCESS

منهجيتنا الهندسية

إحدى عشرة مرحلة من الاستكشاف إلى المراقبة. لكل مرحلة مخرجات محددة وشرط خروج لا ننتقل بعده إلا إذا تحقق — هذه هي الطريقة التي نبني بها برمجيات تعمل في الإنتاج لسنوات، لا تطبيقات تُسلَّم وتُنسى.

11
مرحلة
11
شرط خروج — واحد لكل مرحلة
37
مخرجًا موثقًا تستلمه
01

الاستكشاف

Discovery

الهدفنفهم المشكلة قبل أن نقترح حلًا.

ماذا نفعل
  • مقابلات مع أصحاب القرار والمستخدمين الفعليين
  • تدقيق الأنظمة الحالية والبيانات الموجودة
  • رسم تدفقات المستخدم والبيانات
  • تحديد القيود: الميزانية، الوقت، الأنظمة القائمة، المتطلبات التنظيمية
  • سجل مخاطر أولي
ما تستلمه
  • ملخص الاستكشاف
  • بيان النطاق (ما يدخل وما يخرج)
  • سجل المخاطر
  • نطاق تقديري للتكلفة والوقت
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

النطاق موقَّع من العميل، ولكل خطر من أعلى ثلاثة مخاطر مسؤول وخطة.

الأدوات ورش عمل FigJam Docs
02

المعمارية

Architecture

الهدفنقرر شكل النظام قبل كتابة سطر واحد.

ماذا نفعل
  • اختيار المنصة: Flutter أو أصلي، Laravel أو NestJS
  • نموذج البيانات وحدود الخدمات
  • خريطة التكاملات: الدفع، الخرائط، الرسائل، الأنظمة الخارجية
  • تصميم البنية السحابية وخطة التوسّع
  • تقدير التكلفة الشهرية للتشغيل
ما تستلمه
  • سجلات قرارات المعمارية (ADRs)
  • مخطط النظام (C4)
  • نموذج البيانات
  • خطة البنية التحتية وتكلفتها الشهرية
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

كل ADR راجعه مهندس أول ثانٍ، وتكلفة التشغيل الشهرية مقبولة من العميل.

الأدوات C4 Model ADRs AWS Pricing Calculator
03

المواصفات التقنية

Technical Specification

الهدفنكتب بالضبط ما سيُبنى، بحيث لا يبقى شيء للتخمين.

ماذا نفعل
  • قصص المستخدم مع معايير قبول لكل قصة
  • عقد الواجهة البرمجية (OpenAPI) قبل التنفيذ
  • مخطط قاعدة البيانات ومصفوفة الصلاحيات
  • المتطلبات غير الوظيفية: الأداء، التوافر، النسخ الاحتياطي، العربية وRTL
  • قائمة الحسابات الخارجية المطلوبة باسم العميل
ما تستلمه
  • وثيقة المواصفات التقنية
  • مسودة OpenAPI
  • مخطط قاعدة البيانات
  • قائمة المهام مقدّرة ومقسّمة إلى معالم
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

العميل يوقّع المواصفات، ولكل قصة معايير قبول، والتقدير النهائي ضمن ±15% من تقدير المعمارية.

الأدوات OpenAPI Linear / Jira dbdiagram
04

تصميم الواجهات والتجربة

UI/UX

الهدفنصمم الشاشات على المواصفات، لا العكس.

ماذا نفعل
  • تدفقات المستخدم والإطارات الأولية
  • نظام تصميم عربي أولًا مع دعم RTL كامل
  • شاشات عالية الدقة لـ iOS وAndroid والويب
  • نموذج تفاعلي قابل للنقر
  • مراجعة قابلية الاستخدام وإمكانية الوصول
ما تستلمه
  • ملف Figma بمكوّنات قابلة لإعادة الاستخدام
  • نموذج تفاعلي
  • جرد الشاشات مربوطًا بقصص المستخدم
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

لكل قصة مستخدم شاشة، والنموذج معتمد من العميل، وفحص RTL وإمكانية الوصول مكتمل.

الأدوات Figma Design tokens
05

التطوير

Development

الهدفنبني في زيادات قصيرة يمكن مراجعتها وتجربتها.

ماذا نفعل
  • سبرنتات من أسبوعين بهدف واضح لكل سبرنت
  • فروع صغيرة لكل ميزة ودمج يومي
  • كل تغيير في قاعدة البيانات migration مُصدَّر بالكود
  • أعلام الميزات للوظائف الحساسة
  • نسخة تجريبية على TestFlight ومسار Play الداخلي في نهاية كل سبرنت
ما تستلمه
  • برمجية تعمل في نهاية كل سبرنت
  • نسخة عرض على TestFlight / Play
  • سجل التغييرات
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

هدف السبرنت متحقق، لا أخطاء من الدرجة الأولى مفتوحة، والنسخة على TestFlight أو مسار Play الداخلي.

الأدوات GitHub Docker Flutter Laravel / NestJS
06

مراجعة الكود

Code Review

الهدفلا يصل كود إلى الفرع الرئيسي دون عين ثانية.

ماذا نفعل
  • كل Pull Request يراجعه مهندس آخر
  • قائمة مراجعة: الأمان، الأداء، استعلامات N+1، معالجة الأخطاء، RTL، الاختبارات
  • طلبات دمج صغيرة (أقل من 400 سطر) لمراجعة فعلية لا شكلية
  • تحليل ثابت آلي قبل المراجعة البشرية
ما تستلمه
  • طلبات دمج مراجَعة ومعتمدة
  • تعليقات المراجعة محلولة وموثقة
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

موافقة واحدة على الأقل، CI أخضر، التحليل الثابت نظيف، ولا تعليق مراجعة مفتوح.

الأدوات GitHub Pull Requests Larastan ESLint Dart analyzer
07

الاختبارات الآلية

Automated Testing

الهدفنلتقط الأخطاء قبل أن يلتقطها البشر.

ماذا نفعل
  • اختبارات وحدة لمنطق الأعمال
  • اختبارات ميزات لكل نقطة وصول في الواجهة البرمجية
  • اختبارات تكامل للمسارات الحرجة: الدخول، الدفع، الطلب
  • اختبارات عقد ضد مواصفة OpenAPI
  • تشغيل كل ذلك في GitHub Actions عند كل push
ما تستلمه
  • مجموعة اختبارات داخل المستودع
  • خط CI يعمل على كل تغيير
  • تقرير تغطية
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

CI أخضر على كل طلب دمج، المسارات الحرجة مغطاة، ولا اختبار متجاوَز دون تذكرة.

الأدوات PHPUnit / Pest Jest Flutter test GitHub Actions
08

بيئة التجريب

Staging

الهدفنجرّب الإطلاق قبل الإطلاق.

ماذا نفعل
  • بيئة مطابقة للإنتاج من نفس كود البنية (Terraform / Docker)
  • بيانات واقعية وحسابات اختبار لبوابات الدفع
  • اختبار قبول من العميل مقابل معايير القبول
  • اختبار أداء أولي وتجربة جافة للـ migrations
  • كتابة خطة التراجع
ما تستلمه
  • ورقة اعتماد اختبار القبول
  • خط أساس للأداء
  • ملاحظات الإصدار
  • خطة التراجع
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

كل معايير القبول ناجحة في اختبار العميل، التجربة الجافة للـ migrations نجحت، وخطة التراجع مكتوبة.

الأدوات Terraform Docker KNET / MyFatoorah sandbox k6
09

المراجعة الأمنية

Security Review

الهدفنجد الثغرات قبل أن يجدها غيرنا.

ماذا نفعل
  • قائمة OWASP Top 10
  • فحص ثغرات الاعتماديات
  • تدقيق الأسرار: لا مفاتيح في الكود
  • اختبار الصلاحيات لكل دور
  • تحديد معدل الطلبات والتحقق من المدخلات
  • تشفير البيانات أثناء التخزين والنقل ومعالجة البيانات الشخصية
  • متطلبات المتاجر: Privacy Labels وData Safety
ما تستلمه
  • تقرير المراجعة الأمنية
  • النتائج مُصلحة أو مقبولة بمسؤول محدد
  • جرد الأسرار وأماكن حفظها
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

لا نتيجة عالية أو حرجة مفتوحة، كل الأسرار في خزنة مُدارة، وMFA مفعّل على كل الحسابات السحابية.

الأدوات OWASP ZAP Dependabot composer / npm audit IAM
10

الإنتاج

Production

الهدفإطلاق ممل — وهذا هو المطلوب.

ماذا نفعل
  • قائمة إطلاق: DNS وSSL وCDN والنطاقات
  • التحقق من النسخ الاحتياطي باستعادة فعلية قبل الإطلاق
  • إطلاق تدريجي على Play وإصدار مرحلي على App Store
  • أعلام ميزات للوظائف الحساسة
  • نافذة إطلاق والفريق كله متصل
  • تسليم الحسابات وبيانات الدخول إلى خزنة العميل
ما تستلمه
  • بيئة إنتاج مُسلَّمة باسم العميل
  • دليل التشغيل (Runbook)
  • وسم الإصدار في المستودع
شرط الخروج لا ننتقل للمرحلة التالية قبل تحققه

النسخ الاحتياطي مختبَر باستعادة، التنبيهات تصل للفريق، التراجع مجرَّب، والعميل يملك كل الحسابات.

الأدوات GitHub Actions App Store Connect Google Play Console Cloudflare AWS
11

المراقبة

Monitoring

الهدفنعرف بالمشكلة قبل أن يعرف بها المستخدم.

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

هذه المرحلة لا تُغلق: التنبيهات تُستجاب خلال اتفاقية مستوى الخدمة، والتقرير الشهري يُسلَّم.

الأدوات CloudWatch Sentry Crashlytics Uptime checks
المراقبة تعيدنا إلى الاستكشاف

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

نفس المسار من زاوية العميل

النسخة المبسّطة ←

الخطوات الأربع في صفحة «آلية العمل» هي هذا المسار نفسه مختصرًا لغير التقنيين:

تريد الدليل لا الوصف؟

صفحة «الهندسة في سيجما» تعرض ما نتج عن هذا المسار: التطبيقات المنشورة، البنية السحابية، والتقنيات بتقييمها.

الهندسة في سيجما ←

مشروعك التالي يستحق هذا المسار

احجز جلسة استكشاف — نراجع فكرتك، ونحدد المعمارية والمخاطر، ونعطيك تقديرًا واضحًا قبل أي التزام.

📲 ابدأ الاستكشاف