SMS GROUP — PROJECT DELIVERY PLAN
Reference: SMS-2026-002 Rev 2 | Version: 1.0 | Date: 2026-05-31 PM: Product Manager Agent | Client: ITECH Buildings Contracting — Dammam, KSA
PROJECT SUMMARY
SMS Group will build a fully custom ITECH MOH-J Lighting Tracker — a field operations management PWA — for ITECH Buildings Contracting, Dammam, KSA. The application tracks 9,766 lighting fixtures across 23 MoH health centers in Al-Lith and Adham governorates, with offline capability, bilingual AR/EN interface, role-based access control (STCE zero financial visibility), OOS claims module, and reporting. Delivery target: 3-4 weeks from confirmed deposit and receipt of client wireframes. Tech stack: Python 3.11+ / FastAPI / PostgreSQL / React PWA (Vite) / Custom JWT RS256 — fully self-hosted on client SSH server.
VALIDATION FLAGS (Must Resolve Before Build Starts)
| # | Item | Status |
|---|---|---|
| V1 | Client contact details (name, email, phone) | OPEN — required for contract |
| V2 | Project fee confirmed + deposit received | OPEN — required before development |
| V3 | Reference HTML wireframe documents from ITECH | OPEN — required before UI/UX starts |
| V4 | SSH server access from ITECH | OPEN — required before deployment |
| V5 | OOS dual approval: who are the 2 approvers? | OPEN — required before Sprint 3 |
| V6 | Tarshid compliance specific requirements | OPEN — request from client in Sprint 1 |
| V7 | Offline conflict resolution strategy (server-wins recommended) | OPEN — confirm Sprint 1 |
| V8 | Push notifications: Web Push API or in-app only? | OPEN — confirm Sprint 1 |
| V9 | Client server specs (OS, RAM, disk, open ports) | OPEN — request at contract signing |
| V10 | Fixture + site data file (Excel/CSV — 9,766 fixtures, 23 sites) | OPEN — required by Day 21 |
Timeline start \= Day 1 \= deposit received AND wireframes received. Every day these are delayed \= 1 day timeline extension, no exceptions.
ASSUMPTIONS & DEPENDENCIES
- Timeline (3-4 weeks) starts on Day 1 \= deposit confirmed + client wireframes received.
- SMS Group team is available full-time during the build window.
- ITECH provides SSH server access within 48 hours of contract signing.
- Client wireframe HTML documents are complete for all 10 modules.
- No integration with external government APIs or third-party services required.
- PostgreSQL 14+ and Python 3.11+ can be established on client server.
- The 6 field users have Android 8.0+ or iOS 13.0+ devices supporting PWA.
- Fixture + site data provided in structured format (Excel/CSV) for DB seeding.
- User training conducted remotely via video call — no on-site travel required.
- All 6 roles and permission boundaries are final as defined in the brief — no additions during build.
- STCE representative cannot request features; all change requests go through ITECH PM only.
- OOS dual approvers are Operations Director + Project Manager (to be confirmed — V5).
USER STORIES
Feature 1: Project Dashboard
As an Operations Director or Project Manager, I want a real-time overview of fixture progress, site breakdown, and team status, So that I can monitor project health without chasing field teams.
Acceptance Criteria:
- [ ] Dashboard loads within 3 seconds on mobile
- [ ] Shows % completion for all 9,766 fixtures with last-updated timestamp
- [ ] Shows per-site breakdown across all 23 sites
- [ ] Shows per-team status: Team A, B, C
- [ ] Renders correctly in AR (RTL) and EN (LTR)
Definition of Done: Accurate live data; mobile-responsive; language switch under 1 second. Assigned to: Backend Developer (API) + UI/UX Designer (screens) Estimated hours: 24h (12h backend / 12h frontend) Dependencies: DB schema, RBAC, fixture tracker APIs Priority: Core
Feature 2: Site + Fixture Tracker
As a field engineer (Team A / B / C), I want to record installation status, upload photos, and timestamp each fixture in my assigned sites, So that progress is documented without paper records.
Acceptance Criteria:
- [ ] Engineer sees and edits only their team's sites (enforced at DB query level, not frontend only)
- [ ] Fixture record: ID, site, status (pending/installed/rejected/OOS), photo, timestamp
- [ ] Photo compressed to 500KB or less before upload
- [ ] Works fully offline — records queue for background sync
- [ ] Sync fires automatically on reconnect
- [ ] Directors and PMs see all sites
Definition of Done: Fixture update survives airplane mode; syncs without data loss on reconnect. Assigned to: Backend Developer (API) + UI/UX Designer (screens) Estimated hours: 40h (20h backend / 20h frontend) Dependencies: DB schema, RBAC, PWA service worker Priority: Core
Feature 3: OOS Works Module
As an engineer or Project Manager, I want to submit Out-of-Scope work claims with dual approval (electronic in-app + paper photo), So that all OOS works are documented for contractual claims against STCE.
Acceptance Criteria:
- [ ] OOS form: location, description, photos, estimated value
- [ ] Estimated value NOT visible to STCE role (blocked at API + DB level)
- [ ] Dual approval: in-app electronic + paper approval photo upload
- [ ] OOS status flow: Draft → Submitted → Approved (pending paper) → Fully Approved → Disputed
- [ ] Full audit trail per OOS record (submitter, approvers, timestamps)
- [ ] STCE sees only: location, description, status — no financial data
Definition of Done: End-to-end OOS workflow complete; Security Auditor signs off STCE financial isolation. Assigned to: Backend Developer + Security Auditor (review) Estimated hours: 32h (24h backend/frontend / 8h security review) Dependencies: RBAC, audit log, DB schema Priority: Core
Feature 4: Role-Based Access Control
As a system administrator (Operations Director), I want each user role to have strictly enforced access boundaries, So that engineers see only their team's data and STCE cannot access any financial information.
Acceptance Criteria:
- [ ] 6 roles: Operations Director, Project Manager, Team A/B/C Engineer, STCE Representative
- [ ] STCE role: financial endpoints return 403 or omit financial fields at DB level
- [ ] Team filter applied at DB level (not frontend-only)
- [ ] Role assignment restricted to Operations Director only
- [ ] JWT payload includes role; validated on every API request
- [ ] Test: STCE JWT cannot access financial data via modified requests
Definition of Done: Security Auditor signs off RBAC design; automated tests confirm STCE 403 on all financial endpoints. Assigned to: Backend Developer + Security Auditor Estimated hours: 20h (14h backend / 6h security audit) Dependencies: JWT auth, DB schema Priority: Core
Feature 5: Offline Mode + Auto-Sync
As a field engineer in a remote area, I want to continue recording installation data offline, So that no data is lost when I have no internet.
Acceptance Criteria:
- [ ] PWA works fully offline: view fixtures, record updates, queue photo uploads
- [ ] Visual indicator shows offline status and queued item count
- [ ] Background sync fires automatically on connectivity restore
- [ ] Conflict resolution: server timestamp wins if same fixture updated by two users offline
- [ ] Sync log visible to PM and Director
Definition of Done: Full offline-to-online cycle tested; no duplicates; sync log entry created per synced record. Assigned to: Backend Developer (sync API) + UI/UX Designer (offline UX) Estimated hours: 32h (20h backend / 12h frontend) Dependencies: Service worker, IndexedDB, fixture tracker APIs Priority: Core
Feature 6: Bilingual AR/EN Interface
As any user, I want to switch between Arabic and English instantly, So that Arabic-speaking engineers and English-speaking stakeholders can both use the system comfortably.
Acceptance Criteria:
- [ ] Language switch in header on every screen
- [ ] Full RTL layout in Arabic; LTR in English
- [ ] All labels, buttons, error messages translated in both languages
- [ ] Language preference persists across sessions
- [ ] Numbers and dates formatted per locale
Definition of Done: All screens validated in AR and EN; zero untranslated strings; RTL passes visual review. Assigned to: UI/UX Designer + Backend Developer (i18n strings) Estimated hours: 20h (12h frontend / 8h UI/UX translation QA) Dependencies: All screens built, translation strings complete Priority: Core
Feature 7: In-App Notifications
As an authorized user, I want in-app alerts for OOS submissions, approvals, and progress milestones, So that I am informed of key events without manually checking the system.
Acceptance Criteria:
- [ ] Triggers: OOS submitted, OOS approved (step 1), OOS fully approved, milestone % reached
- [ ] In-app notification panel with read/unread state
- [ ] Role-filtered: STCE does not receive financial milestone alerts
- [ ] Badge count on header
Definition of Done: All trigger events verified; panel renders in AR and EN. Assigned to: Backend Developer + UI/UX Designer Estimated hours: 16h (10h backend / 6h frontend) Dependencies: OOS module, fixture tracker, RBAC Priority: Core
Feature 8: Reporting Module
As an Operations Director or Project Manager, I want to generate a weekly PDF progress report for STCE and an Excel export for internal archive, So that contractual reporting obligations are met without manual compilation.
Acceptance Criteria:
- [ ] PDF: site-by-site progress, team status, OOS summary — no financial data
- [ ] Excel: full data including financial OOS (Director/PM only)
- [ ] Reports filterable by date range and site
- [ ] PDF branded with ITECH logo and report date
- [ ] STCE cannot access Excel export endpoint (returns 403)
Definition of Done: PDF and Excel accurate; Security Auditor confirms STCE blocked from Excel endpoint. Assigned to: Backend Developer Estimated hours: 20h backend Dependencies: Fixture tracker, OOS module, RBAC Priority: Core
Feature 9: Full Audit Log
As an Operations Director, I want every data change logged with user identity, timestamp, and before/after values, So that I have a tamper-proof record for Tarshid program compliance and dispute resolution.
Acceptance Criteria:
- [ ] Records every CREATE/UPDATE/DELETE on: fixtures, OOS records, users, sites
- [ ] Each entry: user ID, role, timestamp, entity type, entity ID, field changed, old value, new value
- [ ] Append-only: no UPDATE/DELETE on audit_log table (enforced at DB level)
- [ ] Accessible only to Operations Director and Project Manager
- [ ] Security Auditor confirms append-only constraint
Definition of Done: Security Auditor signs off; 5 fixture update scenarios traced correctly through log. Assigned to: Backend Developer + Security Auditor Estimated hours: 16h (10h backend / 6h security review) Dependencies: All data entities defined, DB schema finalized Priority: Core
Feature 10: User Training
As ITECH's Operations Director, I want all 6 users trained before go-live, So that field teams operate independently from Day 1.
Acceptance Criteria:
- [ ] 6 training sessions conducted (30 min each, remote via video call)
- [ ] Covers: login, offline usage, fixture updates, photo upload, OOS submission per role
- [ ] Quick reference card produced in AR and EN
- [ ] All 6 users provide written sign-off confirming readiness
Definition of Done: All sessions complete; sign-offs received; reference card delivered. Assigned to: PM (coordination) + Backend Developer (technical demo support) Estimated hours: 12h (6h training delivery / 6h materials prep) Dependencies: Application deployed and stable on client server Priority: Core
SPRINT PLAN
SPRINT 0 — Days 1-2: Client Blockers Resolution
Goal: Remove all Day 0 blockers before any build work starts.
| Task | Agent | Hours | Dependencies |
|---|---|---|---|
| Collect client contact details | PM | 1h | None |
| Confirm project fee and deposit | PM + CEO | 1h | None |
| Receive reference HTML wireframes from ITECH | PM | — | Client provides |
| Security checklist review based on corrected brief | Security Auditor | 4h | Brief |
| Set up dev environment: FastAPI / PostgreSQL / Node.js | Backend Developer | 4h | None |
| Review client wireframes on receipt | UI/UX Designer | 4h | Wireframes received |
Acceptance Criteria:
- Deposit confirmed in writing; wireframes received and reviewed
- Dev environment verified and running
Definition of Done: PM confirms all blockers resolved. If any blocker delayed past Day 2, timeline start date is formally revised and CEO notified.
SPRINT 1 — Days 3-9: Architecture, Auth, Core APIs + UI/UX Design
Goal: Technical foundation complete; all wireframes approved; Security Auditor sign-off on auth architecture.
| Task | Agent | Hours | Dependencies |
|---|---|---|---|
| DB schema design (users, roles, sites, fixtures, installations, oos_records, audit_log, notifications) | Backend Developer | 12h | Sprint 0 complete |
| FastAPI project scaffolding (routers, middleware, error handling) | Backend Developer | 8h | Dev environment |
| Custom JWT RS256 auth: key generation, login, refresh, validation middleware | Backend Developer | 12h | DB schema |
| RBAC middleware: route guards + DB-level filtering per role | Backend Developer | 10h | JWT auth |
| Core CRUD APIs: sites, fixtures, users | Backend Developer | 12h | DB schema, RBAC |
| Adapt client HTML wireframes to all 10 screens | UI/UX Designer | 20h | Wireframes received |
| Define user flows for all 6 roles | UI/UX Designer | 8h | None |
| Security Auditor: auth architecture + RBAC design review | Security Auditor | 8h | JWT + RBAC code available |
Acceptance Criteria:
- DB schema approved by PM and Security Auditor
- Auth endpoints working: POST /auth/login, POST /auth/refresh
- STCE test token: financial endpoints return 403
- All 10 screen wireframes approved by PM
- Security Auditor sign-off on auth architecture issued
Definition of Done: Sprint 1 done when auth is live, RBAC enforced, core CRUD APIs testable, wireframes approved. Frontend work does NOT start until Security Auditor signs off.
SPRINT 2 — Days 10-16: Frontend Core + Fixture Tracker + Bilingual
Goal: React PWA shell live; fixture tracker working end-to-end in both AR and EN on mobile.
| Task | Agent | Hours | Dependencies |
|---|---|---|---|
| React PWA setup: Vite, routing, auth context, secure JWT storage | Backend Developer | 8h | Sprint 1 complete |
| Auth screens: Login, protected route wrapper | Backend Developer + UI/UX | 6h | Wireframes, JWT API |
| Dashboard screen + API integration | Backend Developer + UI/UX | 12h | Dashboard API |
| Site + Fixture Tracker screens + API integration | Backend Developer + UI/UX | 16h | Fixture APIs |
| Bilingual i18n setup (i18next) | Backend Developer | 6h | Screen components |
| RTL/LTR CSS layout system | UI/UX Designer | 8h | All screens |
| Translation strings (AR/EN) for all Sprint 2 screens | UI/UX Designer | 8h | Screens built |
| Photo upload component: compress + queue for offline | Backend Developer | 8h | Fixture tracker screen |
Acceptance Criteria:
- Login works for all 6 roles
- Dashboard shows live fixture progress data
- Fixture tracker: engineer updates status + uploads photo, data persists in DB
- Language switch renders correctly in RTL and LTR
- All Sprint 2 screens have complete AR and EN strings
Definition of Done: Fixture tracker works end-to-end (login → find fixture → update → photo → DB) in both languages on mobile.
SPRINT 3 — Days 17-21: OOS Module + Offline Sync + Reporting
Goal: OOS dual approval complete; offline mode tested; PDF and Excel generating; Security Auditor signs off OOS.
| Task | Agent | Hours | Dependencies |
|---|---|---|---|
| OOS submission form + API | Backend Developer | 10h | RBAC, DB schema |
| OOS dual approval flow: in-app electronic + paper photo upload | Backend Developer | 10h | OOS API |
| OOS screens | UI/UX Designer | 10h | OOS wireframes |
| Service worker + IndexedDB offline storage | Backend Developer | 12h | PWA setup |
| Background sync API + conflict resolution (server-timestamp-wins) | Backend Developer | 8h | Fixture APIs |
| In-app notification system: triggers, panel, badge | Backend Developer | 10h | OOS module |
| Notification screens | UI/UX Designer | 6h | Notification API |
| PDF report generation (weekly STCE report, no financials) | Backend Developer | 10h | Fixture + OOS APIs |
| Excel export (full internal data, Director/PM only) | Backend Developer | 6h | Fixture + OOS APIs |
| Reporting screens | UI/UX Designer | 6h | Report API |
| Translation strings for Sprint 3 screens (AR/EN) | UI/UX Designer | 6h | Sprint 3 screens built |
| Security Auditor: OOS module review — STCE financial isolation | Security Auditor | 8h | OOS complete |
Acceptance Criteria:
- OOS workflow completes end-to-end with both approval steps recorded
- STCE cannot see financial fields — confirmed by Security Auditor
- Offline: fixture update in airplane mode → sync fires on reconnect → no data loss, no duplicates
- PDF and Excel generate with correct data
- All Sprint 3 screens in AR and EN
Definition of Done: Security Auditor signs off OOS; offline sync tested and verified; reports generate correctly.
SPRINT 4 — Days 22-28: Audit Log + QA + Deployment + Training
Goal: Audit log complete; QA passes; Security Auditor final clearance; deployed on client server; all 6 users trained.
| Task | Agent | Hours | Dependencies |
|---|---|---|---|
| Audit log implementation: append-only, all entities, DB-level enforcement | Backend Developer | 10h | All entities complete |
| Audit log viewer screen | Backend Developer + UI/UX | 8h | Audit log API |
| Security Auditor: final full audit (auth, RBAC, OOS, audit log, all APIs) | Security Auditor | 12h | All features complete |
| QA Engineer: end-to-end test suite (all 10 features, all 6 roles) | QA Engineer | 20h | All features complete |
| Bug fixes from QA findings | Backend Developer | 12h | QA findings |
| Production deployment to client SSH server | Backend Developer | 8h | SSH access + QA passed |
| SSL/HTTPS configuration on client server | Backend Developer | 4h | Server access |
| DB seeding: 9,766 fixture records + 23 sites from client data file | Backend Developer | 4h | Client data file |
| Create 6 user accounts with correct roles | PM | 1h | Deployment complete |
| User training materials: quick reference card AR/EN | PM | 4h | None |
| Conduct 6 training sessions (30 min each, remote) | PM + Backend Developer | 6h | Deployment + accounts |
| Client final sign-off | PM | 2h | Training complete |
Acceptance Criteria:
- Audit log records all entity changes; append-only confirmed at DB level
- All QA tests pass: 0 critical, 0 high severity open bugs
- Security Auditor final clearance issued in writing
- Application live on client server via HTTPS
- All 6 users trained; written sign-offs received
- Client final sign-off received
Definition of Done: Hisham approves final delivery; client sign-off issued; final invoice triggered.
MILESTONE MAP
| # | Milestone | Target Day | Deliverable | Payment Trigger |
|---|---|---|---|---|
| M0 | Contract Signed + Deposit | Day 0 | Signed contract + deposit confirmed | YES — unlocks development |
| M1 | Architecture Approved | Day 5 | DB schema + RBAC design + Security Auditor check-in | No |
| M2 | Auth + Wireframes Approved | Day 9 | Working auth, RBAC enforced, all wireframes approved | No |
| M3 | Fixture Tracker + Dashboard Live | Day 16 | Frontend working end-to-end in AR and EN | YES — 2nd installment |
| M4 | OOS + Offline + Reporting Complete | Day 21 | OOS dual approval, offline sync, PDF/Excel; Security Auditor OOS sign-off | No |
| M5 | QA Passed + Security Clearance | Day 25 | QA sign-off + Security Auditor final clearance | No |
| M6 | Final Delivery | Day 28 | App live + 6 users trained + client sign-off | YES — final payment |
All day numbers are relative to Day 1 \= deposit confirmed AND wireframes received. Absolute dates to be set once contract is signed.
RISK REGISTER
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Client wireframes delayed beyond Day 1 | HIGH | HIGH | Timeline clock does not start until wireframes received. Each delay day \= 1 extension day. PM escalates to CEO if more than 3 days late. |
| SSH server incompatible or delayed | MEDIUM | HIGH | Request server specs at contract signing. Backend Dev builds on local staging in parallel. |
| Client requests scope additions during build | MEDIUM | HIGH | Zero-tolerance scope freeze after Sprint 1. Any change request escalated to CEO. Formal impact assessment before any acceptance. |
| Offline sync conflicts or data corruption | MEDIUM | HIGH | Server-timestamp-wins strategy confirmed in Sprint 1. Stress-tested in Sprint 3 before deployment. |
| STCE financial data leakage | LOW | CRITICAL | Security Auditor reviews RBAC before Sprint 2 starts AND reviews OOS module in Sprint 3. DB-level view permissions enforced. Automated API tests cover STCE role on all financial endpoints. |
| Fixture data file not in structured format | MEDIUM | MEDIUM | PM requests Excel/CSV at contract signing. Seeding script designed to handle common formats. |
| Field devices incompatible with PWA (older Android) | LOW | MEDIUM | UI/UX Designer tests on Android 8.0 / iOS 13.0 minimum during Sprint 2. |
| Key team member unavailable during build window | LOW | HIGH | PM escalates to CEO immediately. Timeline renegotiated with client. |
| Tarshid compliance requirements emerge mid-build | LOW | MEDIUM | PM requests compliance checklist at Sprint 0. If requirements emerge in build, Security Auditor assesses impact and PM escalates if scope change needed. |
| OOS dual approver roles not confirmed before Sprint 3 | MEDIUM | MEDIUM | PM resolves V5 by Day 9. OOS module does not start until approver roles are confirmed. |
| Sprint slippage more than 3 days | MEDIUM | HIGH | PM escalates to CEO. Client notified. Delivery date formally revised. |
AGENT HANDOFF SCHEDULE
| Agent | Receives | Trigger |
|---|---|---|
| Security Auditor | Security requirements checklist from brief | Day 1 (Sprint 0) |
| UI/UX Designer | Client HTML wireframes + user stories + role definitions | Day 1 or when wireframes received |
| Backend Developer | Dev environment brief + DB schema requirements | Day 1 |
| Security Auditor (checkpoint 2) | JWT auth + RBAC code for architectural review | Day 7 — after auth + RBAC complete |
| Backend Developer (frontend) | Approved wireframes from UI/UX Designer | Day 9 — Sprint 2 start |
| Security Auditor (checkpoint 3) | OOS module for financial isolation review | Day 19 — after OOS module complete |
| QA Engineer | Complete application for end-to-end test suite | Day 22 — Sprint 4 start |
| Security Auditor (final) | Full application for final security audit | Day 22 — Sprint 4 start, parallel to QA |
| PM | Security Auditor clearance + QA sign-off | Day 25 — triggers training scheduling |
| PM | Deployment confirmation | Day 24 — triggers user account creation |
ESCALATION TRIGGERS
The following conditions require immediate CEO escalation and client notification:
- Client wireframes not received by Day 3 — formal timeline revision issued
- SSH server access not received by Day 14 — deployment at risk
- Any sprint completes more than 3 days behind schedule
- Client requests any scope change during build — no work starts until CEO approves
- Security Auditor issues a BLOCKER finding on RBAC or STCE isolation — Sprint paused
- QA finds critical bugs in Sprint 4 that cannot be resolved within the sprint window
- Key team member unavailable for more than 2 consecutive days
MILESTONES REQUIRING HISHAM APPROVAL
| Gate | Milestone | What Hisham Reviews |
|---|---|---|
| G1 | M0 — Contract | Final contract terms + fee structure + payment schedule |
| G2 | M2 — Architecture | DB schema + RBAC design (given STCE competitor sensitivity) |
| G3 | M6 — Final Delivery | Client sign-off + final invoice release |
OPEN ITEMS
| # | Item | Owner | Deadline | Status |
|---|---|---|---|---|
| 1 | Client contact details (name, email, phone) | CEO/PM | Before contract sent | OPEN |
| 2 | Project fee amount + payment schedule | CEO | Day 0 | OPEN |
| 3 | Reference HTML wireframe documents | Client (ITECH) | Day 0-1 | OPEN |
| 4 | OOS dual approval: confirm the 2 approvers | PM | Day 9 (end Sprint 1) | OPEN |
| 5 | Tarshid compliance specific requirements | PM to Client | Sprint 1 | OPEN |
| 6 | Offline conflict resolution strategy (server-wins) | PM + Backend Dev | Sprint 1 | OPEN |
| 7 | Push notifications: Web Push API or in-app only | PM + Backend Dev | Sprint 1 | OPEN |
| 8 | Client server specs (OS, RAM, disk, ports) | PM to Client | Day 3 | OPEN |
| 9 | Fixture + site data file (Excel/CSV) | PM to Client | Day 21 | OPEN |
خطة التسليم — نظام تتبع إضاءة ITECH وزارة الصحة
المرجع: SMS-2026-002 Rev 2 | الإصدار: 1.0 | التاريخ: 2026-05-31 مدير المشروع: وكيل مدير المشروع | العميل: شركة ITECH للمقاولات — الدمام، المملكة العربية السعودية
ملخص المشروع
ستقوم مجموعة SMS ببناء تطبيق مخصص بالكامل لتتبع مشروع إضاءة MOH-J — تطبيق ويب تقدمي لإدارة عمليات الميدان — لصالح شركة ITECH للمقاولات في الدمام. يتتبع التطبيق 9,766 وحدة إضاءة عبر 23 مركزاً صحياً تابعاً لوزارة الصحة في محافظتي الليث وأضم، مع دعم العمل دون اتصال بالإنترنت، وواجهة ثنائية اللغة، وتحكم في الوصول حسب الأدوار مع حظر كامل لبيانات STCE المالية، ووحدة مطالبات الأعمال خارج النطاق، والتقارير.
مدة التسليم المستهدفة: 3-4 أسابيع من تأكيد الإيداع واستلام المخططات التفصيلية من العميل. المكدس التقني: Python 3.11+ / FastAPI / PostgreSQL / React PWA / JWT مخصص RS256 — مستضاف ذاتياً على خادم العميل.
علامات التحقق (يجب الحل قبل البدء)
| # | البند | الحالة |
|---|---|---|
| V1 | بيانات اتصال العميل (الاسم، البريد الإلكتروني، الهاتف) | مفتوح — مطلوب للعقد |
| V2 | تأكيد رسوم المشروع واستلام الدفعة المقدمة | مفتوح — مطلوب قبل التطوير |
| V3 | وثائق المخططات التفصيلية HTML من ITECH | مفتوح — مطلوب قبل تصميم الواجهة |
| V4 | صلاحية الوصول SSH من ITECH | مفتوح — مطلوب قبل النشر |
| V5 | اعتماد OOS المزدوج: من هما المعتمدان؟ | مفتوح — يجب التأكيد قبل Sprint 3 |
| V6 | متطلبات الامتثال لبرنامج ترشيد | مفتوح — طلب من العميل في Sprint 1 |
| V7 | استراتيجية حل تعارض البيانات دون اتصال | مفتوح — تأكيد في Sprint 1 |
| V8 | الإشعارات: Web Push API أم داخل التطبيق فقط؟ | مفتوح — تأكيد في Sprint 1 |
| V9 | مواصفات خادم العميل | مفتوح — طلب عند توقيع العقد |
| V10 | ملف بيانات الوحدات والمواقع (Excel/CSV) | مفتوح — مطلوب بحلول اليوم 21 |
بداية الجدول الزمني \= اليوم 1 \= استلام الدفعة المقدمة + استلام المخططات التفصيلية. كل يوم تأخير \= يوم تمديد للجدول الزمني بلا استثناء.
الافتراضات والتبعيات
- يبدأ الجدول الزمني في اليوم 1 \= تأكيد الدفعة + استلام المخططات.
- فريق مجموعة SMS متاح بدوام كامل طوال فترة البناء.
- توفر ITECH صلاحية الوصول SSH خلال 48 ساعة من توقيع العقد.
- وثائق المخططات التفصيلية مكتملة لجميع الوحدات العشر.
- لا يوجد تكامل مع واجهات برمجية خارجية أو حكومية.
- المستخدمون الستة يمتلكون أجهزة تدعم PWA (Android 8.0+ أو iOS 13.0+).
- بيانات الوحدات والمواقع متاحة بصيغة منظمة لتحميل قاعدة البيانات.
- التدريب سيجري عن بُعد — لا يوجد سفر ميداني.
- الأدوار الستة ونطاقات صلاحياتها نهائية — لا إضافات خلال البناء.
- ممثل STCE لا يطلب ميزات؛ جميع طلبات التغيير تمر عبر مدير مشروع ITECH فقط.
خطة السبرينت
السبرينت 0 — الأيام 1-2: إزالة العوائق
الهدف: إزالة جميع عوائق اليوم الأول قبل بدء أي عمل تطويري.
| المهمة | الوكيل | الساعات | التبعيات |
|---|---|---|---|
| جمع بيانات اتصال العميل | مدير المشروع | 1 ساعة | لا يوجد |
| تأكيد الرسوم والدفعة المقدمة | مدير المشروع + الرئيس التنفيذي | 1 ساعة | لا يوجد |
| استلام مخططات HTML من ITECH | مدير المشروع | — | العميل يوفرها |
| مراجعة قائمة الأمان بناءً على الوصف المصحح | مدقق الأمن | 4 ساعات | الوصف |
| إعداد بيئة التطوير | مطور الواجهة الخلفية | 4 ساعات | لا يوجد |
| مراجعة المخططات التفصيلية عند الاستلام | مصمم UX | 4 ساعات | استلام المخططات |
السبرينت 1 — الأيام 3-9: البنية التحتية، المصادقة، APIs الأساسية + تصميم الواجهة
الهدف: اكتمال الأساس التقني؛ الموافقة على جميع المخططات؛ موافقة مدقق الأمن على بنية المصادقة.
السبرينت 2 — الأيام 10-16: الواجهة الأمامية + متتبع الوحدات + ثنائية اللغة
الهدف: تشغيل تطبيق PWA الأساسي؛ متتبع الوحدات يعمل من البداية إلى النهاية باللغتين.
السبرينت 3 — الأيام 17-21: وحدة OOS + العمل دون اتصال + التقارير
الهدف: اكتمال سير عمل الموافقة المزدوجة على OOS؛ اختبار وضع عدم الاتصال؛ إنشاء تقارير PDF وExcel.
السبرينت 4 — الأيام 22-28: سجل التدقيق + ضمان الجودة + النشر + التدريب
الهدف: اكتمال سجل التدقيق؛ اجتياز اختبارات الجودة؛ الحصول على موافقة مدقق الأمن النهائية؛ النشر؛ تدريب المستخدمين الستة.
خريطة المعالم
| # | المعلم | اليوم المستهدف | المُنتَج | مُشغِّل الدفع |
|---|---|---|---|---|
| M0 | توقيع العقد + الدفعة المقدمة | اليوم 0 | عقد موقع + دفعة مؤكدة | نعم — يفتح التطوير |
| M1 | الموافقة على البنية التحتية | اليوم 5 | مخطط قاعدة البيانات + RBAC | لا |
| M2 | المصادقة + الموافقة على المخططات | اليوم 9 | مصادقة تعمل + مخططات معتمدة | لا |
| M3 | متتبع الوحدات + لوحة التحكم | اليوم 16 | الواجهة الأمامية تعمل بالكامل | نعم — القسط الثاني |
| M4 | OOS + عدم الاتصال + التقارير | اليوم 21 | سير عمل OOS + مزامنة + تقارير | لا |
| M5 | اجتياز ضمان الجودة + موافقة الأمن | اليوم 25 | تقرير ضمان الجودة + شهادة الأمن | لا |
| M6 | التسليم النهائي | اليوم 28 | تطبيق مُشغَّل + مستخدمون مُدرَّبون + موافقة العميل | نعم — الدفعة النهائية |
سجل المخاطر
| المخاطرة | الاحتمالية | الأثر | التخفيف |
|---|---|---|---|
| تأخر المخططات التفصيلية عن اليوم 1 | عالية | عالٍ | لا يبدأ العمل حتى الاستلام؛ كل يوم تأخير \= يوم تمديد |
| تعارض خادم العميل أو تأخره | متوسطة | عالٍ | طلب مواصفات الخادم عند التوقيع؛ بيئة تطوير محلية موازية |
| طلبات إضافة نطاق أثناء البناء | متوسطة | عالٍ | تجميد النطاق بعد Sprint 1؛ أي تغيير يُصعَّد للرئيس التنفيذي |
| تعارض البيانات دون اتصال | متوسطة | عالٍ | استراتيجية الخادم يفوز تُأكَّد في Sprint 1 وتُختبر في Sprint 3 |
| تسريب بيانات STCE المالية | منخفضة | حرج | مراجعة RBAC قبل Sprint 2؛ مراجعة OOS قبل Sprint 4؛ اختبارات API تلقائية |
| تأخر تسليم ملف البيانات | متوسطة | متوسط | طلب الملف عند التوقيع؛ أداة تحميل مرنة الصيغة |
| انقطاع عضو رئيسي في الفريق | منخفضة | عالٍ | تصعيد فوري للرئيس التنفيذي؛ مراجعة الجدول مع العميل |
البنود المفتوحة
| # | البند | المسؤول | الموعد النهائي | الحالة |
|---|---|---|---|---|
| 1 | بيانات اتصال العميل | الرئيس التنفيذي / مدير المشروع | قبل إرسال العقد | مفتوح |
| 2 | مبلغ الرسوم وجدول الدفع | الرئيس التنفيذي | اليوم 0 | مفتوح |
| 3 | وثائق المخططات HTML من ITECH | العميل | اليوم 0-1 | مفتوح |
| 4 | تأكيد المعتمدَين لـ OOS | مدير المشروع | اليوم 9 | مفتوح |
| 5 | متطلبات امتثال برنامج ترشيد | مدير المشروع ← العميل | Sprint 1 | مفتوح |
| 6 | استراتيجية حل التعارض دون اتصال | مدير المشروع + المطور | Sprint 1 | مفتوح |
| 7 | آلية الإشعارات | مدير المشروع + المطور | Sprint 1 | مفتوح |
| 8 | مواصفات خادم العميل | مدير المشروع ← العميل | اليوم 3 | مفتوح |
| 9 | ملف بيانات الوحدات والمواقع | مدير المشروع ← العميل | اليوم 21 | مفتوح |
أُعِدَّ بواسطة: وكيل مدير المشروع للمراجعة بواسطة: وكيل الرئيس التنفيذي للاعتماد بواسطة: هشام الهادي — المدير العام