ابدأ مجانًا

جودة البرمجيات ونضج العملية

عملية تطوير البرمجيات لدينا وامتثال SPICE

تغرس UDENTIVA نضج العملية المطلوب في برمجيات الصحة داخل المعمارية نفسها. تعرض هذه الصفحة بالأدلة دورة حياة التطوير لدينا، ومستويات قدرة SPICE / ISO-IEC 15504، وآليات التسجيل والمراقبة المستمرة للأخطاء، ومعايير الإصدار والأمان، وسجل التطوير.

المستند: لائحة أنظمة إدارة المعلومات الصحية (رقم اللائحة 39682) المادة 6 والمادة 20 — اشتراط اعتماد جودة البرمجيات (CMMI/SPICE).

بنية عمليات UDENTIVA هي نهج لإدارة جودة البرمجيات والعمليات جاهز للتدقيق ومتوافق مع مبادئ SPICE / ISO/IEC 15504.

تعريف العملية وتطبيقها ومنتجات العمل القابلة للتتبّع مُهيكلة؛ وتُشغَّل في الإنتاج آليات القياس الكمّي ومنع العيوب والتحسين المستمر. يخضع أي إعلان رسمي عن مستوى القدرة لنطاق التقييم المستقل (appraisal).

مستويات قدرة SPICE

يقيّم SPICE العمليات على مستويات قدرة من 0 إلى 5. صُمّمت UDENTIVA لتلبية توقعات المستويات 1-3 على مستوى تعريف العملية وتطبيقها ومنتجات العمل القابلة للتتبع؛ أما المستويان 4-5 فتُشغَّل لهما آليات القياس الكمي والتحسين المستمر. يخضع الإعلان الرسمي عن المستوى لتقييم مستقل.

Eksik (Incomplete)

العملية غير مُطبَّقة/لا تبلغ الهدف.

مُنفَّذ (Performed)

العملية موجودة وتنتج مخرجاتها.

مُدار (Managed)

العملية مُخطَّطة ومُراقَبة؛ ومنتجات العمل مُدارة.

راسخ (Established)

العملية القياسية المُعرَّفة مُطبَّقة باتساق في المشروع بأكمله.

قابل للتنبؤ (Predictable)

العملية مُتحكَّم بها كميًا (بالقياس).

Optimize Eden (Optimizing)

تحسين مستمر + منع العيوب + ابتكار العملية.

تُشغَّل آليات الضبط الكمي والتحسين المستمر الخاصة بالمستويين 4-5 مع أدلتها أدناه (قياس حي، وسجل الأخطاء/CAPA، وسجلات النشر).

مجالات عملية SPICE → التطبيق → الدليل

يقابل كل مجال عملية تطبيقًا ملموسًا ودليلًا قابلًا للتدقيق في UDENTIVA. فالعملية ليست وثيقة، بل هي كود يعمل فعليًا.

مجال العملية	تطبيق UDENTIVA	الدليل
ENG.1 استخلاص المتطلبات	خريطة المراحل + تعريف متطلبات الشريحة الرأسية (vertical slice)؛ ويثبّت عقد المشروع UDENTIVA.md المتطلبات.	UDENTIVA.md (القواعد الذهبية)، 02_tech_spec/ المواصفة الفنية، خريطة المراحل/الوحدات
ENG.4 تصميم البرمجيات	monolith معياري؛ حزم السياق (context) لا تتشارك جداول بعضها البعض؛ التواصل عبر interface؛ الخدمة الخارجية = adapter.	قاعدة حدود internal/{identity,patient,billing,export,...}؛ ADR-001..008
ENG.5 بناء البرمجيات	SQL صريح (sqlc، لا ORM)؛ context هو المعامل الأول في كل دالة؛ تغليف الأخطاء بـ %w؛ المال = numeric.	تجاوز النوع في sqlc.yaml (numeric←string)، db/queries/*.sql، gofmt/golangci-lint
ENG.6 تكامل البرمجيات	سلسلة loopback بين PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis؛ واجهة عامة واحدة فقط.	web/core/ApiClient، /healthz صحة المكوّنات (db+redis)
ENG.7 اختبار البرمجيات	اختبار عزل عبر المستأجرين (الأكثر أهمية)، idempotency، تعارض المواعيد، دقة المال، 2FA/OTP، متجه TOTP RFC6238، QR (التحقق عبر OpenCV+ISO).	internal/integration/*_test.go, platform/totp/totp_test.go, go test ./...
SUP.1 ضمان الجودة	كل PR ملزم بالتوافق مع القواعد الذهبية؛ lint نظيف؛ إن كان اختبار العزل أحمر في CI فلا دمج.	golangci-lint, Definition of Done kontrol listesi
SUP.8 إدارة التكوين	التحكم بالإصدارات عبر Git (branch core)؛ إصدار المخطط المتسلسل عبر goose؛ تُنسخ احتياطيًا مُخرجات البناء (artifacts).	git, goose_db_version tablosu, .tools/deploy yedekleri
SUP.9 حل المشكلات	سجل تدقيق append-only + صندوق صادر للبريد/SMS (سجل لكل إرسال) + انضباط النسخ الاحتياطي/rollback للنشر.	audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback
SUP.10 إدارة طلبات التغيير	كل تغيير في المخطط هو migration جديد مُرقَّم؛ قابل للتراجع (goose Down)؛ موافقة مصنّف النشر.	db/migrations/0001..0027, +goose Up/Down
MAN.3 إدارة المشروع	تسليم بالشرائح الرأسية (كل شريحة تعمل من طرف إلى طرف)؛ ملاحظات تسليم الجلسة.	super-devam.md, faz tablosu (DoD per dilim)
MAN.6 القياس	فحص الصحة، قياس السعة، مقاييس إرسال البريد/SMS، حجم التدقيق، القياس عن بُعد للأحداث الحية.	/healthz، لوحة مراقبة العمليات والجودة (الأحداث/الأخطاء/النشر/KPI)

معمارية متعددة الطبقات وأمان البيانات

المسؤوليات مقسّمة إلى طبقات؛ وسلطة النطاق (domain) في نقطة واحدة معزولة عبر loopback. لا يرى المتصفح سوى الـ BFF الرقيق، ولا يمكنه أبدًا الوصول مباشرة إلى طبقة النطاق والبيانات.

طبقة	المسؤولية والأمان	الموقع
Sunum (BFF)	PHP 8.4 — BFF رفيع: الجلسة، العرض، CSRF، التوجيه. لا قواعد أعمال/DB. الواجهة العامة الوحيدة (IIS:443).	web/
Uygulama / Domain	monolith معياري بلغة Go — السلطة الوحيدة للنطاق (domain). RBAC، قواعد الأعمال، transaction. يستمع إلى 127.0.0.1 فقط.	api/internal/
Veri	PostgreSQL — كل جدول به tenant_id + RLS FORCE؛ SQL صريح (sqlc)، ذو معاملات. المال numeric.	api/db/
التخزين المؤقت / الطابور	Redis — الجلسة، idempotency، القفل الموزّع، طابور asynq (SMS/e-fatura).	platform/redisx
Nesne Depolama	متوافق مع S3 — الملفات الكبيرة (الأشعة) presigned/stream؛ الـ blob لا يكون أبدًا في DB.	platform/storage
خدمة خارجية (adapter)	e-Fatura، SMS(NetGSM)، البريد الإلكتروني(SMTP)، (لاحقًا e-Nabız/MEDULA/DICOM) — مجرّدة خلف interface.	internal/notify

القياس الكمّي وKPI — قياس عن بُعد حيّ للعملية

القياس ليس إعلانًا، بل نظام يعمل. تُعَدّ جميع العمليات حيًّا (نجاح/فشل)، وتُلتقَط أخطاء الإنتاج في سجل دائم، ويُربَط إطار KPI أدناه بإجراءات دورية. مصادر البيانات جداول حقيقية: event_counter (عدّاد عمليات حيّ)، error_log (سجل أخطاء دائم)، deploy_log (سجل النشر).

مجال القياس	KPI	الهدف	مصدر البيانات	الفترة	الإجراء
أمان عزل المستأجرين (tenant)	cross-tenant test fail	0	CI / izolasyon testi	her PR	حجب الدمج (Merge)
خطأ في الإنتاج	خطأ مكشوف (5xx/panic)	0	error_log (دائم)	مستمر/حيّ	RCA + CAPA zorunlu
معدل نجاح العمليات	success / toplam event	≥ 99%	event_counter (حيّ)	مستمر/حيّ	السبب الجذري عند الانخفاض
زمن الحل	MTTR (متوسط زمن الحل)	↓ اتجاه متناقص	error_log (resolved)	شهري	Trend incelemesi
موثوقية النشر	معدل rollback	< %5	deploy_log	30 يومًا	Rollback review
أمان الهوية	2FA/OTP kritik olay	0	audit + event_counter	شهري	التقوية (Hardening)
موثوقية المراسلة	SMS/e-posta failure	↓ منخفض	*_outbox	يومي	مراجعة المزوّد
الاستعداد للاستعادة	نجاح اختبار الاستعادة (restore)	%100	DR test (hedef)	ربع سنوي	تحديث Runbook

تُراقَب مؤشرات KPI هذه في الوقت الفعلي من لوحة "مراقبة العمليات والجودة" الحية التي يصل إليها مشغّل المنصة: معدّل نجاح العمليات، وعدد الأخطاء المفتوحة، وMTTR (متوسط زمن الحل)، وعدد عمليات النشر، ومعدّل الـ rollback.

دورة منع العيوب والتحسين المستمر (RCA/CAPA)

يمرّ كل خطأ إنتاجي بدورة تحليل جذري قياسية (RCA) وإجراء تصحيحي/وقائي (CAPA)؛ ويُمنَع تكرار الخطأ نفسه بفحص الانحدار وتتبّع الاتجاه.

سجل الحادثة / الخطأ

يُلتقَط خطأ الإنتاج (5xx/panic) آليًا ← error_log دائم (عند تكرار التوقيع نفسه count++، اتجاه العيوب).

التصنيف

يُحدَّد المستوى (error/panic) والأثر وعدد التكرار؛ يُقاس الانتشار عبر عدّادات الأحداث الفاشلة.

السبب الجذري (RCA)

يُجرى تحليل السبب الجذري في لوحة مراقبة العمليات ويُسجَّل.

الإجراء التصحيحي/الوقائي (CAPA)

يُعرَّف الإجراء التصحيحي + الإجراء الوقائي (الكود، الاختبار، قاعدة migration، ضابط الأمان) ويُسجَّل.

ضبط الانحدار (Regression)

يُضاف اختبار/قاعدة تمنع تكرار الخطأ نفسه؛ ويُراقَب عبر القياس عن بُعد المستمر.

Trend incelemesi

تُقيَّم اتجاهات KPI (MTTR، معدل الأخطاء، rollback) دوريًا؛ ويُفتح إجراء على مستوى العملية للأخطاء المتكررة.

الآليات المُشغَّلة — التسجيل والمراقبة والتحسين المستمر للأخطاء

جوهر SPICE المستوى 5: تسجيل الأخطاء باستمرار، وإبقاؤها تحت السيطرة، ومنع العيوب، والتحسين المستمر. تُشغّل UDENTIVA هذه الآليات في بيئة الإنتاج.

تسجيل الأخطاء المستمر

يسجّل audit_log (غير قابل للتغيير، append-only) كل عملية حرجة بشكل دائم؛ ويسجّل email_outbox/sms_outbox كل إرسال (status، attempts، error). لا يضيع أي حدث بصمت.

audit_log, *_outbox (status/error/attempts)

ضبط الأخطاء والتراجع

غلاف خطأ متسق {error:{code,message}}؛ لا يُسرَّب أبدًا الخطأ الداخلي/الـ stack. قبل كل نشر يُؤخَذ نسخ احتياطي للـ binary + web؛ وعند حدوث انقطاع يمكن الـ rollback خلال ثوانٍ عبر bin/server.exe.bak-*.

httpx.Error, deploy yedek/rollback runbook

منع العيوب (Defect Prevention)

بنية fail-closed: بلا سياق RLS تعود 0 صفوف؛ يمنع idempotency العملية المزدوجة؛ يجعل المال numeric خطأ الـ float مستحيلًا؛ تمنع القائمة البيضاء (whitelist لمجموعة بيانات export) حقن SQL. تُمنع الأخطاء من البداية بالتصميم.

RLS FORCE, Idempotency-Key SETNX, numeric, view whitelist

التحقق المستقل

تُتحقَّق المكوّنات الحرجة بطريقتين مستقلتين: متجه اختبار TOTP RFC6238، وفكّ ترميز QR عبر OpenCV cv2 + codeword مرجعي ISO/IEC 18004، واختبار العزل عبر المستأجرين.

اختبارات التكامل + التحقق عبر مفكّك ترميز خارجي

دورة التحسين المستمر

في كل جلسة: تدقيق أمني ← نتائج ← تقوية (مثل إضافة RBAC للمرحلة 2/المرحلة 3، 2FA، Export API). تُحفَظ الذاكرة المؤسسية عبر ملاحظات العملية (super-devam.md).

دورة التدقيق الأمني ← التقوية

ابتكار العملية

يُحوَّل طلب تنظيمي جديد (عرض VEM) مباشرةً إلى ميزة منتج ودليل؛ وتُراقَب تغييرات التشريعات باستمرار وتُدرَج في خريطة الامتثال.

Export API/VEM views، خريطة الامتثال /mevzuat

التحكم في الإصدار (Edition)

قاعدة شيفرة واحدة، تضييق بعَلَم — دون فرع (fork).

يحدّد العلَم EDITION=base نسخة MVP للعيادة الواحدة؛ وتقرأ رؤية القائمة (app.php) والوصول إلى المسارات (index.php) من قائمة السماح Edition::allows().
Go RBAC هو السلطة؛ وEdition مجرد تضييق للواجهة/السطح — تُفرَض الصلاحية الحقيقية في طبقة API (الرؤية ≠ الأمان).
في النسخة full جميع الوحدات مفعّلة؛ وفي النسخة base وحدات النمو للمرحلة 2/المرحلة 3 مخفية. لا Fork — قاعدة كود واحدة، التضييق بالعلَم.
تُقاس حدود السعة عبر خطة/باقة على مستوى المستأجر (نموذج اشتراك المنصة)؛ وعند التجاوز يظهر تحذير مرن (لا يمنع).

آليات إدارة الإصدارات

إصدار قابل للتتبّع على مستوى المخطط والمصدر والنشر وطبقة API.

إصدار المخطط

migration متسلسل عبر goose (0001 ← 0027)؛ كل تغيير مُرقَّم + قابل للتراجع (Up/Down). يُتتبَّع الإصدار المُطبَّق في جدول goose_db_version. يُتحقَّق من migration الإنتاج على DB نظيفة.

إصدار المصدر

التحكم بالإصدارات عبر Git (branch: core)؛ مستودع bare مركزي معزول. يُعمل commit لكل عمل ذي معنى؛ الأسرار (connection.md، .tools) في gitignore — لا يُعمل commit لكلمة المرور أبدًا.

إصدار النشر

يُترجَم Go binary (-ldflags "-s -w")، ويُبدَّل bin/server.exe فقط (لا wrapper الخاص بـ WinSW أبدًا). قبل كل نشر نسخة احتياطية للـ binary + web (بختم زمني). كسر التخزين المؤقت للأصول الثابتة ?v=N.

إصدار API

بادئة /v1 للنقاط العامة؛ Export API عبر /export/v1. تُحفَظ التوافقية الرجعية؛ التغيير الكاسر يعني إصدارًا جديدًا.

استخدام Git، والاسترجاع (Rewind) والتراجع (Rollback)

عملية التطوير كاملة تحت التحكم بالإصدار؛ كل نشر قابل للتراجع (rewind/rollback).

التحكم بالإصدارات

Git (branch: core)؛ مستودع bare مركزي معزول. يُعمل commit لكل عمل ذي معنى؛ التاريخ قابل للتتبّع.

إدارة الأسرار

كلمة المرور/المفتاح/معلومات الاتصال في gitignore — لا يُعمل لها commit أبدًا (connection.md، .tools، *.zip).

العزل

يُخضَع للإصدار دليل هذا المشروع فقط؛ لا يُمسّ مصدر مشاريع أخرى.

قابلية التتبّع

تُبنى الـ commits على أساس الشريحة الرأسية/الميزة؛ يربط سجل النشر (deploy_log) سلسلة commit←release←prod.

الاسترجاع / التراجع: قبل كل عملية نشر، يُؤخذ نسخ احتياطي للـ binary والويب وقاعدة البيانات (مع طابع زمني). يُتراجَع عن المخطط عبر migration قابلة للتراجع (goose Down)؛ ويُعاد الـ binary العامل إلى الإصدار السابق (bin/server.exe.bak-*) خلال ثوانٍ؛ ويُستعاد الويب من الأرشيف السابق. وعند وقوع حادث، يمكن إرجاع الإنتاج إلى حالته السليمة السابقة.

معايير الأمان (القواعد الذهبية)

الأمان ليس ميزة، بل المعمارية نفسها. قواعد غير قابلة للتفاوض، ومخالفتها ترفض دمج طلب السحب (PR):

العزل على مستوى الصف (RLS FORCE، fail-closed)

كل جدول به tenant_id؛ بلا سياق تعود السياسة بـ 0 صفوف. اختبار العزل عبر المستأجرين هو بوابة CI.

Atomik & idempotent yazma

العملية متعددة الكيانات في transaction واحد (إما الكل أو لا شيء)؛ كل mutation عبر Idempotency-Key يمنع العملية المزدوجة.

Para = numeric

الـ Float ممنوع؛ التقريب في مكان واحد، خانتان. الخطأ المالي مستحيل بالتصميم.

الهوية والجلسة

كلمة مرور argon2id؛ session_key معتم (opaque) في Redis (TTL متحرّك)؛ التحقق بخطوتين (TOTP)؛ لا يُكشَف session_key للمتصفح.

Topoloji izolasyonu

يستمع Go إلى 127.0.0.1 فقط؛ الواجهة العامة الوحيدة هي PHP/BFF. منافذ الواجهة الخلفية (DB/Redis) مغلقة أمام الخارج.

تدقيق غير قابل للتغيير

audit_log من نوع append-only؛ لا يُسجَّل PII/secret أو يُخفَّى؛ TCKN/البيانات الصحية ذات طبيعة خاصة.

استعلام بمعاملات

كل SQL ذو معاملات (sqlc/pgx) — حقن SQL مستحيل؛ أسماء مجموعات البيانات في قائمة بيضاء.

توطين البيانات

البيانات الصحية داخل تركيا فقط؛ لا نقل إلى الخارج (KVKK م.9، لائحة KSV م.16).

سجل التطوير (Development History)

بُنِي النظام بشرائح رأسية يعمل كلٌّ منها من طرف إلى طرف. أدناه المراحل وتسلسل أعمال الأمان/الامتثال الأخيرة.

Faz 0 الهيكل الأساسي

pgx+sqlc، goose، اختبار RLS fail-closed، WithTenantTx، middleware الجلسة، تسجيل الدخول+RBAC، التدقيق، loopback بين PHP↔Go، أساس asynq، الصحة.

Faz 1 نواة العيادة (9 شرائح رأسية)

CRUD المريض + اختبار العزل عبر المستأجرين ← المواعيد (exclusion constraint + قفل Redis) ← Odontogram/خطة العلاج (FDI، append-only) ← التحصيل/الحساب الجاري/الصندوق (اشتقاق، idempotent) ← e-Fatura adapter (fast-follow) ← المخزون ← الأشعة (S3) ← تذكير SMS (asynq backoff).

Platform وحدة تحكم إدارة المنصة

طبقة مشغّل المنصة (super-admin) (X-Platform-Key، مستوى هوية منفصل)؛ إدارة المستأجرين، نموذج الاشتراك/الفوترة، قياس السعة، محرّر الإصدارات القانونية، reCAPTCHA، إعدادات NetGSM.

النمو تعدد اللغات وموقع العيادة الإلكتروني

i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.

2026-06 أمان الهوية والاتصالات

عنصر OTP مشترك؛ إعادة تعيين كلمة المرور + magic-link + تفعيل الحساب (SMTP فعلي)؛ نواة SMS عبر NetGSM؛ مصادقة عامة متعددة المستأجرين؛ إدارة مستخدمي العيادة.

2026-06 التحقق بخطوتين (2FA)

TOTP (RFC6238) + رموز احتياطية؛ QR إلزامي (مستقل عن الخارج، qr.js خالٍ من CSP؛ تم التحقق منه بشكل مستقل عبر OpenCV+ISO)؛ التحقق من الهاتف عبر SMS (موافقة KVKK).

2026-06 الامتثال التنظيمي

عرض VEM (نموذج الحد الأدنى للبيانات) 12 export view + Export API (مُعرَّف من SuperUser، مقفول على المستأجر، fail-closed)؛ خريطة التشريعات والامتثال؛ مراجعة العقود القانونية بنسبة 100% نحو التشريعات.

2026-06 الدعم والعملية

مركز دعم بتتبّع التذاكر؛ توثيق عملية SPICE (هذه الصفحة)؛ تدقيق أمني مستمر + تقوية.