Cuims | Chandigarh University(CU) : Architecture Explained

A research-style, engineering journal article describing CUIMS (Chandigarh University (CU) Information Management System, often written as “Cuims”): architecture, data model, end-to-end processes (marks, results, re-evaluation), APIs, deployment, operations, security, and engineering trade-offs. In short: CUIMS at Chandigarh University (CU) — Architecture Explained for practitioners. एक शोध-शैली, इंजीनियरिंग जर्नल लेख जो CUIMS (चंडीगढ़ विश्वविद्यालय (CU) सूचना प्रबंधन प्रणाली, जिसे अक्सर “Cuims” भी लिखा जाता है) का वर्णन करता है: आर्किटेक्चर, डेटा मॉडल, अंत-से-अंत प्रक्रियाएं (अंक, परिणाम, पुनर्मूल्यांकन), APIs, तैनाती, संचालन, सुरक्षा, और इंजीनियरिंग ट्रेड-ऑफ। संक्षेप में: चंडीगढ़ विश्वविद्यालय (CU) का CUIMS — आर्किटेक्चर की विस्तृत व्याख्या (Architecture Explained)।

Abstract सार

This paper presents a comprehensive, engineer-grade breakdown of CUIMS (Chandigarh University (CU) Information Management System) — the integrated student information and administration system used at Chandigarh University. The document synthesizes public, verifiable sources about CUIMS and the University’s examination policies with industry-standard architectural and operational practices to produce a reproducible, production-grade reference design. It covers: architecture (ASCII diagrams), module-level processes (admission → enrollment → internal & external marks → grade conversion → publication → re-evaluation), canonical database schema (DDL), API contracts, asynchronous job design, observability, security, performance engineering, test strategies, and runbooks for result publication. Put simply, it is Chandigarh University (CU) CUIMS — Architecture Explained for engineers and stakeholders. Where internal CUIMS implementation details are not public, we state recommended, realistic designs and label them accordingly. यह पेपर CUIMS (चंडीगढ़ विश्वविद्यालय (CU) सूचना प्रबंधन प्रणाली) का एक व्यापक, इंजीनियर-ग्रेड विश्लेषण प्रस्तुत करता है — जो चंडीगढ़ विश्वविद्यालय में उपयोग की जाने वाली एकीकृत छात्र सूचना और प्रशासन प्रणाली है। यह दस्तावेज़ CUIMS और विश्वविद्यालय की परीक्षा नीतियों के बारे में सार्वजनिक, सत्यापन योग्य स्रोतों को उद्योग-मानक आर्किटेक्चरल और परिचालन प्रथाओं के साथ संश्लेषित करता है ताकि एक पुनरुत्पाद्य, उत्पादन-ग्रेड संदर्भ डिज़ाइन तैयार किया जा सके। इसमें शामिल है: आर्किटेक्चर (ASCII चित्र), मॉड्यूल-स्तर की प्रक्रियाएं (प्रवेश → नामांकन → आंतरिक और बाहरी अंक → ग्रेड रूपांतरण → प्रकाशन → पुनर्मूल्यांकन), कैननिकल डेटाबेस स्कीमा (DDL), API अनुबंध, असिंक्रोनस जॉब डिज़ाइन, प्रेक्षणीयता, सुरक्षा, प्रदर्शन इंजीनियरिंग, परीक्षण रणनीतियाँ, और परिणाम प्रकाशन के लिए रनबुक। सरल शब्दों में, यह चंडीगढ़ विश्वविद्यालय (CU) के CUIMS का — आर्किटेक्चर की विस्तृत व्याख्या (Architecture Explained) है। जहां CUIMS के आंतरिक कार्यान्वयन विवरण सार्वजनिक नहीं हैं, हम अनुशंसित, यथार्थवादी डिज़ाइन बताते हैं और उन्हें उचित रूप से लेबल करते हैं।

Keywords: CUIMS, Cuims, Chandigarh University (CU), CUIMS marks update, CUIMS result publication, student information system, grade conversion, university ERP, architecture explained. कीवर्ड: CUIMS, Cuims, चंडीगढ़ विश्वविद्यालय (CU), CUIMS अंक अपडेट, CUIMS परिणाम प्रकाशन, छात्र सूचना प्रणाली, ग्रेड रूपांतरण, विश्वविद्यालय ERP, आर्किटेक्चर की विस्तृत व्याख्या।

Disclaimer (Important) अस्वीकरण (महत्वपूर्ण)

This document combines (a) public, verifiable facts (CUIMS portal, system of evaluation, LMS integration) and (b) engineering inferences and recommended designs for the internal architecture, database schemas, and operational practices where complete production details are not publicly published. Public sources used are cited inline. For official internal system details, contact Chandigarh University (CU) IT/Registrar. यह दस्तावेज़ (a) सार्वजनिक, सत्यापन योग्य तथ्यों (CUIMS पोर्टल, मूल्यांकन प्रणाली, LMS एकीकरण) और (b) आंतरिक आर्किटेक्चर, डेटाबेस स्कीमा, और परिचालन प्रथाओं के लिए इंजीनियरिंग अनुमान और अनुशंसित डिज़ाइनों को जोड़ता है जहां पूर्ण उत्पादन विवरण सार्वजनिक रूप से प्रकाशित नहीं हैं। उपयोग किए गए सार्वजनिक स्रोतों का उल्लेख इनलाइन किया गया है। आधिकारिक आंतरिक सिस्टम विवरण के लिए, चंडीगढ़ विश्वविद्यालय (CU) के IT/रजिस्ट्रार से संपर्क करें।

1. Introduction & Motivation 1. परिचय और प्रेरणा

Chandigarh University (CU) operates a campus-wide, integrated information management system referred to as CUIMS (also “Cuims”), which provides admission, enrollment, attendance, assessment, results, fee management, and student services functionality through web and mobile portals. The University documents and portals confirm CUIMS as the central academic/administrative system, and official university material indicates integration with Blackboard LMS for course delivery. चंडीगढ़ विश्वविद्यालय (CU) एक कैंपस-व्यापी, एकीकृत सूचना प्रबंधन प्रणाली संचालित करता है जिसे CUIMS (या “Cuims”) कहा जाता है, जो वेब और मोबाइल पोर्टल्स के माध्यम से प्रवेश, नामांकन, उपस्थिति, मूल्यांकन, परिणाम, शुल्क प्रबंधन, और छात्र सेवाएँ प्रदान करता है। विश्वविद्यालय के दस्तावेज़ और पोर्टल्स CUIMS को केंद्रीय शैक्षणिक/प्रशासनिक प्रणाली के रूप में पुष्टि करते हैं, और आधिकारिक विश्वविद्यालय सामग्री कोर्स डिलीवरी के लिए Blackboard LMS के साथ एकीकरण का संकेत देती है।

High-risk, high-visibility operations in CUIMS include: marks entry, grade conversion, and result publication. The University’s published System of Evaluation mandates departmental display of internal marks prior to submission and describes re-evaluation rules (e.g., refund of review fee when marks increase by >10% of maximum marks), underlining the need for rigorous audit, immutability, and reproducible conversion pipelines. CUIMS में उच्च-जोखिम, उच्च-दृश्यता संचालन में शामिल हैं: अंक प्रविष्टि, ग्रेड रूपांतरण, और परिणाम प्रकाशन। विश्वविद्यालय की प्रकाशित मूल्यांकन प्रणाली जमा करने से पहले आंतरिक अंकों का विभागीय प्रदर्शन अनिवार्य करती है और पुनर्मूल्यांकन नियमों का वर्णन करती है (उदाहरण के लिए, जब अंक अधिकतम अंकों के >10% तक बढ़ते हैं तो समीक्षा शुल्क की वापसी), जो कठोर ऑडिट, अपरिवर्तनीयता, और पुनरुत्पाद्य रूपांतरण पाइपलाइनों की आवश्यकता को रेखांकित करता है।

This document’s objective is to provide a full, technical reference (architecture + processes + code + runbook) that: (1) documents existing public facts about CUIMS, and (2) supplies a complete, realistic engineering design for implementing, operating, and extending a CUIMS-style system at production scale — essentially Chandigarh University (CU) CUIMS, Architecture Explained. इस दस्तावेज़ का उद्देश्य एक पूर्ण, तकनीकी संदर्भ (आर्किटेक्चर + प्रक्रियाएँ + कोड + रनबुक) प्रदान करना है जो: (1) CUIMS के बारे में मौजूदा सार्वजनिक तथ्यों को दस्तावेज़ करता है, और (2) उत्पादन स्तर पर CUIMS-शैली प्रणाली को लागू करने, संचालित करने, और विस्तार करने के लिए एक पूर्ण, यथार्थवादी इंजीनियरिंग डिज़ाइन प्रदान करता है — मूल रूप से चंडीगढ़ विश्वविद्यालय (CU) का CUIMS, आर्किटेक्चर की विस्तृत व्याख्या।

2. Methodology 2. कार्यप्रणाली

Data sources for facts in this document include the CUIMS portals and official Chandigarh University (CU) pages (admissions/portal pages, System of Evaluation, Self Study Report), plus vendor sources describing Blackboard integration. Where the original system internals are not published, recommended design choices are derived from standard, battle-tested patterns used in university ERPs and large transactional systems. Key public sources are cited at the beginning and within sections. इस दस्तावेज़ में तथ्यों के लिए डेटा स्रोतों में CUIMS पोर्टल्स और आधिकारिक चंडीगढ़ विश्वविद्यालय (CU) पेज (एडमिशन/पोर्टल पेज, सिस्टम ऑफ इवैल्यूएशन, सेल्फ स्टडी रिपोर्ट), साथ ही Blackboard एकीकरण का वर्णन करने वाले विक्रेता स्रोत शामिल हैं। जहां मूल सिस्टम आंतरिक विवरण प्रकाशित नहीं हैं, वहाँ अनुशंसित डिज़ाइन विकल्प विश्वविद्यालय ERPs और बड़े लेन-देन प्रणालियों में उपयोग किए गए मानक, युद्ध-परीक्षित पैटर्न से प्राप्त किए गए हैं। प्रमुख सार्वजनिक स्रोतों का उल्लेख शुरुआत में और अनुभागों के भीतर किया गया है।

3. High-Level System Architecture (ASCII) — CUIMS 3. उच्च-स्तरीय सिस्टम आर्किटेक्चर (ASCII) — CUIMS

This high-level architecture shows the major layers and data flows: edge, UI clients, identity, application services, async processing, storage, analytics, and backups. यह उच्च-स्तरीय आर्किटेक्चर प्रमुख परतों और डेटा प्रवाह को दर्शाता है: एज, UI क्लाइंट्स, पहचान, एप्लिकेशन सेवाएँ, असिंक्रोनस प्रोसेसिंग, स्टोरेज, एनालिटिक्स, और बैकअप।

      
+-------------------------------------------------------------------------------------------------+
|                           CUIMS — High Level Architecture (Chandigarh University(CU))           |
|                                                                                                 |
|  [ Internet / Campus Network ]                                                                  |
|            |                                                                                    |
|            v                                                                                    |
|   +----------------------------+  +--------------------+  +--------------------------------+    |
|   | SSR Public Pages (SEO)     |  | CDN (CloudFront)   |  | Marketing / Helpdesk / Docs    |    |
|   +----------------------------+  +--------------------+  +--------------------------------+    |
|            |                                                                                    |
|            v                                                                                    |
|   +-------------------------------------------------------------------------------------------+ |
|   |  Edge Security: WAF / TLS / Rate Limit / IP Allowlists (campus)                           | |
|   +-------------------------------------------------------------------------------------------+ |
|            |                                                                                    |
|            v                                                                                    |
|   +-------------------------------------------------------------------------------------------+ |
|   |  API Gateway / Load Balancer (Auth passthrough, routing, throttling)                      | |
|   +-------------------------------------------------------------------------------------------+ |
|     |       |          |           |             |              |            |                  |
|     v       v          v           v             v              v            v                  |
| +-----+ +------+  +--------+  +--------+  +------------+  +-----------+  +------------+         |
| |Web  | |Faculty| |Mobile  |  |  Admin |  |  Finance   |  |  Library/ |  |LMS GW      |         |
| |(Student)|Portal |  App   |  | Console|  |  Console   |  |  Hostel   |  |(Blackboard)|         |
| +-----+ +------+  +--------+  +--------+  +------------+  +-----------+  +------------+         |
|     |       |          |           |             |              |            |                  |
|     v       v          v           v             v              v            v                  |
|  +-------------------------------------------------------------------------------+              |
|  |                           Identity & SSO Layer (LDAP/SSO/OAuth2/2FA)       |                 |
|  +-------------------------------------------------------------------------------+              |
|     |                 |                |                   |                  |                 |
|     v                 v                v                   v                  v                 |
|  +-------------------------------------------------------------------------------------------+  |
|  |                Application Services Layer (Admissions, Academics, Exams)                  |  |
|  |  - Admissions  - Enrollment - Courses - Attendance - Assessments - Examinations           |  |
|  |  - Results Engine (grade conv) - Finance - Notifications - DocumentGen (PDFs)             |  |
|  +-------------------------------------------------------------------------------------------+  |
|     |                 |                |                   |                  |                 |
|     v                 v                v                   v                  v                 |
|  +---------+  +----------------+  +----------------+  +--------------+  +---------------------+ |
|  |Primary  |  |Analytical DW   |  |Cache (Redis)   |  |Blob Storage  |  |Message Queue/Kafka  | |
|  |RDBMS    |  |(ETL: Airflow)  |  |(sessions, ttl) |  |(pdfs, docs)  |  |(jobs, notifications)| |
|  |(Postgres|  |                |  |                |  |(S3/MinIO)    |  |                     | |
|  +---------+  +----------------+  +----------------+  +--------------+  +---------------------+ |
|     |                                                                                           |
|     v                                                                                           |
|  +----------------------------+   +--------------------------------------+                      |
|  |  Backup / WAL Archive      |   |  Background Workers / Batch Jobs     |                      |
|  |  Cross-AZ replicas         |   |  (grade conv, pdf gen, notify, ETL)  |                      |
|  +----------------------------+   +--------------------------------------+                      |
+-------------------------------------------------------------------------------------------------+
      
    

Interpretation: identity/SSO and role management are central because role-based access controls are required for marks entry, approvals, and final publication. Asynchronous workers are mandatory for heavy, non-interactive tasks (PDF generation, grade conversion, bulk notifications). CDN + SSR ensures the public pages and SEO content perform well. व्याख्या: पहचान/SSO और भूमिका प्रबंधन केंद्रीय हैं क्योंकि अंक प्रविष्टि, अनुमोदन, और अंतिम प्रकाशन के लिए भूमिका-आधारित पहुंच नियंत्रण आवश्यक हैं। भारी, गैर-इंटरैक्टिव कार्यों (PDF जनरेशन, ग्रेड रूपांतरण, थोक अधिसूचनाएँ) के लिए असिंक्रोनस वर्कर्स अनिवार्य हैं। CDN + SSR यह सुनिश्चित करता है कि सार्वजनिक पेज और SEO सामग्री अच्छा प्रदर्शन करें।

Public grounding: CUIMS is the official student portal; the University public materials and portal pages demonstrate the presence and centrality of CUIMS. सार्वजनिक आधार: CUIMS आधिकारिक छात्र पोर्टल है; विश्वविद्यालय की सार्वजनिक सामग्री और पोर्टल पेज CUIMS की उपस्थिति और केंद्रीयता को दर्शाते हैं।

4. Module-Level Deep Dive (process, data, APIs, edge cases) 4. मॉड्यूल-स्तरीय गहन विश्लेषण (प्रक्रिया, डेटा, APIs, एज केस)

This section explains each major module in depth: responsibilities, process sequences, data ownership, API contracts, and typical failure modes with remediation steps. यह अनुभाग प्रत्येक प्रमुख मॉड्यूल को गहराई से समझाता है: जिम्मेदारियाँ, प्रक्रिया अनुक्रम, डेटा स्वामित्व, API अनुबंध, और सामान्य विफलता मोड्स के साथ सुधारात्मक कदम।

4.1 Admissions & Student Records 4.1 प्रवेश और छात्र रिकॉर्ड

Responsibilities: Application intake, document verification, offer generation, student UID provisioning, SSO account creation and onboarding. जिम्मेदारियाँ: आवेदन स्वीकृति, दस्तावेज़ सत्यापन, ऑफर जनरेशन, छात्र UID प्रावधान, SSO खाता निर्माण और ऑनबोर्डिंग।

Processes & Dataflow प्रक्रियाएँ और डेटा प्रवाह

Applicant fills form → files scanned docs → system stores metadata in Applicants and binary files in secure blob storage (S3). आवेदक फॉर्म भरता है → स्कैन किए गए दस्तावेज़ अपलोड करता है → सिस्टम मेटाडेटा को Applicants में और बाइनरी फाइलों को सुरक्षित ब्लॉब स्टोरेज (S3) में संग्रहीत करता है।

Payment gateway handles application fees; payment records link to applicant. पेमेंट गेटवे आवेदन शुल्क को संभालता है; भुगतान रिकॉर्ड आवेदक से जुड़े होते हैं।

Admission decision triggers StudentProfile creation: students(uid, name, dob, contact, program_id, status). SSO account is provisioned atomically and credentials OTP is sent to student. प्रवेश निर्णय StudentProfile निर्माण को ट्रिगर करता है: students(uid, name, dob, contact, program_id, status)। SSO खाता परमाणु रूप से प्रावधानित होता है और क्रेडेंशियल OTP छात्र को भेजा जाता है।

APIs (representative) APIs (प्रतिनिधि)

• POST /admissions/applyPOST /admissions/apply
• GET /admissions/{appId}/statusGET /admissions/{appId}/status
• POST /admissions/{appId}/accept → triggers student_provision(uid)POST /admissions/{appId}/accept → student_provision(uid) को ट्रिगर करता है

Edge cases एज केस

Duplicate applications, unverified documents; resolved via a verification queue and manual review workflow. डुप्लिकेट आवेदन, असत्यापित दस्तावेज़; सत्यापन क्यू और मैनुअल समीक्षा वर्कफ़्लो के माध्यम से हल किए जाते हैं।

4.2 Enrollment & Curriculum (Course Management) 4.2 नामांकन और पाठ्यक्रम (कोर्स प्रबंधन)

Responsibilities: Program/curriculum definitions, course sections, pre-requisite enforcement, enrollment windows and waitlists. जिम्मेदारियाँ: कार्यक्रम/पाठ्यक्रम परिभाषाएँ, कोर्स सेक्शन, पूर्व-आवश्यकता प्रवर्तन, नामांकन विंडो और प्रतीक्षा सूची।

Data model highlights डेटा मॉडल हाइलाइट्स

• programs(program_id, name, duration)programs(program_id, name, duration)
• courses(course_id, code, title, credits, program_id)courses(course_id, code, title, credits, program_id)
• sections(section_id, course_id, term, capacity)sections(section_id, course_id, term, capacity)
• enrollments(enroll_id, student_id, section_id, status)enrollments(enroll_id, student_id, section_id, status)

Operations संचालन

Bulk enrollment for program cohorts; transactional guarantees required when enrollment impacts finance (invoice issuance). प्रोग्राम कोहोर्ट्स के लिए थोक नामांकन; जब नामांकन वित्त को प्रभावित करता है (चालान जारी करना) तो लेन-देन संबंधी गारंटी आवश्यक होती है।

Failure patterns विफलता पैटर्न

Over-subscription: implement transactional enrollment with capacity checks and waitlist queue. अति-सदस्यता: क्षमता जाँच और प्रतीक्षा सूची क्यू के साथ लेन-देन संबंधी नामांकन लागू करें।

4.3 Attendance 4.3 उपस्थिति

Responsibilities: Daily capture (web/mobile/biometric), aggregation, low-attendance alerting to students/HoD. जिम्मेदारियाँ: दैनिक कैप्चर (वेब/मोबाइल/बायोमेट्रिक), एकत्रीकरण, छात्रों/विभागाध्यक्ष को कम उपस्थिति की चेतावनी।

Schema स्कीमा

attendance_records(id, student_id, course_id, date, status, marked_by, source) attendance_records(id, student_id, course_id, date, status, marked_by, source)

Implementation कार्यान्वयन

Per-session records are stored (auditability). Nightly aggregation produces attendance_summary(student_id, course_id, month, percent_present). प्रति-सत्र रिकॉर्ड संग्रहीत किए जाते हैं (ऑडिट योग्यता)। रात में एकत्रीकरण attendance_summary(student_id, course_id, month, percent_present) उत्पन्न करता है।

User flows उपयोगकर्ता प्रवाह

Faculty mobile/tablet UI: quick batch marking, barcode/QR or biometric ingestion for automatic attendance. फैकल्टी मोबाइल/टैबलेट UI: त्वरित बैच मार्किंग, स्वचालित उपस्थिति के लिए बारकोड/QR या बायोमेट्रिक इनजेशन।

4.4 Assessments & Internal Marks 4.4 मूल्यांकन और आंतरिक अंक

Responsibilities: Create assessments (tests/practicals/assignments), collect marks, departmental approval, push to Controller. जिम्मेदारियाँ: मूल्यांकन बनाना (परीक्षण/प्रैक्टिकल/असाइनमेंट), अंक एकत्र करना, विभागीय अनुमोदन, नियंत्रक को भेजना।

Data lifecycle डेटा जीवनचक्र

assessments(assessment_id, course_id, type, max_marks, weight, created_by, due_date) assessments(assessment_id, course_id, type, max_marks, weight, created_by, due_date)

Faculty enters marks (UI or CSV) → records written to internal_marks with status draft. फैकल्टी अंक दर्ज करता है (UI या CSV) → internal_marks में ड्राफ्ट स्थिति के साथ रिकॉर्ड लिखे जाते हैं।

Dept coordinator reviews drafts; on approve, status → approved; only approved marks are eligible for bundling into result computation. विभाग समन्वयक ड्राफ्ट की समीक्षा करता है; अनुमोदन पर, स्थिति → अनुमोदित; केवल अनुमोदित अंक परिणाम गणना में शामिल होने के लिए पात्र हैं।

API API

• POST /faculty/assessments/{assessmentId}/marks — idempotent; accepts CSV or JSON.POST /faculty/assessments/{assessmentId}/marks — idempotent; CSV या JSON स्वीकार करता है।
• GET /dept/{deptId}/pending-assessments — for review.GET /dept/{deptId}/pending-assessments — समीक्षा के लिए।

Audit ऑडिट

Every update recorded in internal_marks_audit for compliance and re-evaluation evidence. प्रत्येक अपडेट internal_marks_audit में अनुपालन और पुनर्मूल्यांकन साक्ष्य के लिए दर्ज किया जाता है।

Observed public requirement: Chandigarh University(CU) policy requires that final internal evaluation be displayed by departments before submission. This enforces the need for a departmental preview/publish workflow within CUIMS. सार्वजनिक आवश्यकता: चंडीगढ़ विश्वविद्यालय की नीति के अनुसार जमा करने से पहले अंतिम आंतरिक मूल्यांकन को विभागों द्वारा प्रदर्शित करना आवश्यक है। यह CUIMS के भीतर विभागीय पूर्वावलोकन/प्रकाशन वर्कफ़्लो की आवश्यकता को लागू करता है।

4.5 Examinations & External Marks 4.5 परीक्षाएँ और बाहरी अंक

Responsibilities: Exam scheduling, roll generation, invigilation, scanning/entry of external marks, secure ingestion and mapping. जिम्मेदारियाँ: परीक्षा समय-निर्धारण, रोल जनरेशन, निरीक्षण, बाहरी अंकों की स्कैनिंग/प्रविष्टि, सुरक्षित इनजेशन और मैपिंग।

Process प्रक्रिया

Exam scheduling module creates exams and exam_rosters. Post-exam, external marks are uploaded via secure, authenticated APIs or scanned and entered by evaluators. परीक्षा समय-निर्धारण मॉड्यूल परीक्षाएँ और exam_rosters बनाता है। परीक्षा के बाद, बाहरी अंक सुरक्षित, प्रमाणित APIs के माध्यम से अपलोड किए जाते हैं या मूल्यांकनकर्ताओं द्वारा स्कैन और दर्ज किए जाते हैं।

Important: external marks ingestion should be validated (checksum, schema checks) and stored immutably after approval. महत्वपूर्ण: बाहरी अंकों का इनजेशन सत्यापित (चेकसम, स्कीमा जाँच) होना चाहिए और अनुमोदन के बाद अपरिवर्तनीय रूप से संग्रहीत किया जाना चाहिए।

4.6 Grade Conversion & Result Publication (the critical pipeline) 4.6 ग्रेड रूपांतरण और परिणाम प्रकाशन (महत्वपूर्ण पाइपलाइन)

This pipeline is the most sensitive; it must be reproducible, auditable, and atomic (from the Controller’s perspective). यह पाइपलाइन सबसे संवेदनशील है; यह पुनरुत्पाद्य, ऑडिट योग्य, और परमाणु (नियंत्रक के दृष्टिकोण से) होनी चाहिए।

High-level sequence (detailed) उच्च-स्तरीय अनुक्रम (विस्तृत)

1. Faculty → internal_marks (status: draft)फैकल्टी → internal_marks (स्थिति: ड्राफ्ट)
2. Department → reviews → approves (internal_marks.status = approved)विभाग → समीक्षा → अनुमोदन (internal_marks.status = अनुमोदित)
3. Controller → issues "bundle for conversion" jobनियंत्रक → "रूपांतरण के लिए बंडल" जॉब जारी करता है
4. GradeConv Worker (batch):
   - fetch internal and external marks
   - compute totals & class stats (mean, stddev)
   - apply grading policy (relative or absolute)
   - write versioned ResultSnapshot rows (immutable)GradeConv वर्कर (बैच):
   - आंतरिक और बाहरी अंक प्राप्त करें
   - कुल और कक्षा आँकड़े (औसत, मानक विचलन) की गणना करें
   - ग्रेडिंग नीति लागू करें (सापेक्ष या निरपेक्ष)
   - संस्करणबद्ध ResultSnapshot पंक्तियाँ लिखें (अपरिवर्तनीय)
5. DocumentGen Worker:
   - generate PDF marksheets for ResultSnapshot versions
   - store signed artifacts in blob storageDocumentGen वर्कर:
   - ResultSnapshot संस्करणों के लिए PDF मार्कशीट जनरेट करें
   - हस्ताक्षरित आर्टिफैक्ट्स को ब्लॉब स्टोरेज में संग्रहीत करें
6. Publish process:
   - set ResultSnapshot published flag
   - queue notifications (email/SMS)
   - create audit entry (published_by, timestamp)प्रकाशन प्रक्रिया:
   - ResultSnapshot प्रकाशित फ्लैग सेट करें
   - अधिसूचनाएँ क्यू करें (ईमेल/SMS)
   - ऑडिट प्रविष्टि बनाएँ (published_by, timestamp)

Key system properties प्रमुख सिस्टम गुण

Immutability: Published snapshots are immutable (append versioning), enabling correct historical records and legal proof. अपरिवर्तनीयता: प्रकाशित स्नैपशॉट्स अपरिवर्तनीय हैं (संस्करण जोड़ें), जो सही ऐतिहासिक रिकॉर्ड और कानूनी प्रमाण को सक्षम करता है।

Auditing: Every write to internal/external marks and every publish action is logged with actor and IP. ऑडिटिंग: आंतरिक/बाहरी अंकों में प्रत्येक लेखन और प्रत्येक प्रकाशन कार्रवाई को अभिनेता और IP के साथ लॉग किया जाता है।

Idempotency: Jobs must be idempotent; retry semantics should check ResultSnapshot.version to avoid duplicate publications. Idempotency: जॉब्स को idempotent होना चाहिए; पुन: प्रयास शब्दार्थ को ResultSnapshot.version की जाँच करनी चाहिए ताकि डुप्लिकेट प्रकाशन से बचा जा सके।

Public policy tie: CU’s System of Evaluation prescribes submission of total marks for grade conversion and mentions re-evaluation rules (e.g., refund when marks increase >10% in re-evaluation). These policy facts must be supported by workflow features (ERB flows, refund automation). सार्वजनिक नीति संबंध: CU की मूल्यांकन प्रणाली ग्रेड रूपांतरण के लिए कुल अंकों की जमा करने की सिफारिश करती है और पुनर्मूल्यांकन नियमों का उल्लेख करती है (उदाहरण के लिए, पुनर्मूल्यांकन में अंक >10% बढ़ने पर रिफंड)। इन नीति तथ्यों को वर्कफ़्लो सुविधाओं (ERB प्रवाह, रिफंड स्वचालन) द्वारा समर्थित होना चाहिए।

4.7 Re-evaluation (Evaluation Review Board) 4.7 पुनर्मूल्यांकन (मूल्यांकन समीक्षा बोर्ड)

Flow प्रवाह

Student files ReEvalRequest (form + fee) → ERB assesses answer scripts → outcome either confirms or changes marks. If the recommended increase >10% of maximum marks, refund of review fee is mandated per official policy. छात्र ReEvalRequest (फॉर्म + शुल्क) दाखिल करता है → ERB उत्तर पत्रों का मूल्यांकन करता है → परिणाम या तो अंकों की पुष्टि करता है या बदलता है। यदि अनुशंसित वृद्धि अधिकतम अंकों के >10% है, तो आधिकारिक नीति के अनुसार समीक्षा शुल्क की वापसी अनिवार्य है।

System behaviours सिस्टम व्यवहार

Review queue with versioned snapshot updates (result_snapshots.version++) and review_actions audit entries. Refund automation integrates with Finance. संस्करणबद्ध स्नैपशॉट अपडेट्स (result_snapshots.version++) और review_actions ऑडिट प्रविष्टियों के साथ समीक्षा क्यू। रिफंड स्वचालन वित्त के साथ एकीकृत होता है।

4.8 Finance, Scholarships & Refunds 4.8 वित्त, छात्रवृत्तियाँ और रिफंड

Responsibilities जिम्मेदारियाँ

Invoice generation, payments (gateway integration), scholarship eligibility, automated refunds (e.g., re-eval >10% case). चालान जनरेशन, भुगतान (गेटवे एकीकरण), छात्रवृत्ति पात्रता, स्वचालित रिफंड (उदाहरण के लिए, पुनर्मूल्यांकन >10% मामला)।

APIs APIs

• POST /finance/invoicesPOST /finance/invoices
• POST /finance/payments/webhook (payment gateway)POST /finance/payments/webhook (पेमेंट गेटवे)
• POST /finance/refunds/{paymentId}POST /finance/refunds/{paymentId}

Operational notes परिचालन नोट्स

Payment reconciliation jobs run nightly; failed webhooks are retried with idempotent logic. भुगतान समाधान जॉब्स रात में चलते हैं; असफल वेबहुक्स को idempotent तर्क के साथ पुन: प्रयास किया जाता है।

4.9 LMS Gateway (Blackboard) — Integration specifics 4.9 LMS गेटवे (Blackboard) — एकीकरण विशिष्टताएँ

Chandigarh University(CU) explicitly uses Blackboard and integrates it with CUIMS for LMS functionality (course content, attendance from sessions, assignment grades). Integration patterns include roster sync, assignment/grade exchange, and SSO mapping. चंडीगढ़ विश्वविद्यालय स्पष्ट रूप से Blackboard का उपयोग करता है और इसे LMS कार्यक्षमता (कोर्स सामग्री, सत्रों से उपस्थिति, असाइनमेंट ग्रेड) के लिए CUIMS के साथ एकीकृत करता है। एकीकरण पैटर्न में रोस्टर सिंक, असाइनमेंट/ग्रेड आदान-प्रदान, और SSO मैपिंग शामिल हैं।

Adapter responsibilities एडाप्टर जिम्मेदारियाँ

Map CUIMS uid ↔ Blackboard user id. CUIMS uid ↔ Blackboard उपयोगकर्ता ID मैप करें।

Periodic roster sync (cron + webhook), assignment grade pull/push, and single sign-on links. आवधिक रोस्टर सिंक (क्रॉन + वेबहूक), असाइनमेंट ग्रेड पुल/पुश, और सिंगल साइन-ऑन लिंक।

4.10 Document Generation & Certificate Issuance 4.10 दस्तावेज़ जनरेशन और प्रमाणपत्र जारी करना

Responsibilities: Generate signed, tamper-evident PDFs for marksheets, transcripts, and degree certificates with metadata (hash, signed_by, certificate_version). जिम्मेदारियाँ: मार्कशीट, ट्रांसक्रिप्ट, और डिग्री प्रमाणपत्रों के लिए हस्ताक्षरित, छेड़छाड़-प्रमाण PDFs जनरेट करें जिनमें मेटाडेटा (हैश, signed_by, certificate_version) हो।

Recommended approach अनुशंसित दृष्टिकोण

Background worker generates PDFs using a template engine; store artifact metadata in DB and binary in blob storage (S3) with signed URLs. बैकग्राउंड वर्कर टेम्पलेट इंजन का उपयोग करके PDFs जनरेट करता है; आर्टिफैक्ट मेटाडेटा को DB में और बाइनरी को ब्लॉब स्टोरेज (S3) में हस्ताक्षरित URLs के साथ संग्रहीत करें।

5. Canonical Data Model (Expanded DDL & ER ASCII) 5. कैननिकल डेटा मॉडल (विस्तारित DDL और ER ASCII)

Below is an ER-style ASCII schematic and a fuller set of DDL snippets for the core tables used in marks/result workflows. नीचे एक ER-शैली ASCII योजनाबद्ध और अंक/परिणाम वर्कफ़्लो में उपयोग की जाने वाली मुख्य तालिकाओं के लिए DDL स्निपेट्स का पूर्ण सेट है।

5.1 ER (ASCII) 5.1 ER (ASCII)

      
[Students]<>----<[Enrollments]>----[Sections]----<[Courses]<>----[Programs]
   |                          |
   v                          v
[InternalMarks]             [AttendanceRecords]
   |                          |
   v                          v
[Assessments]             [ResultSnapshots]<>--[ResultDocs]
   ^
   |
[ExternalMarks] <-- [Exams]
      
    

5.2 DDL Snippets (production-ready) 5.2 DDL स्निपेट्स (उत्पादन-तैयार)

      
-- Users & Roles
CREATE TABLE users (
  user_id BIGSERIAL PRIMARY KEY,
  uid VARCHAR(64) UNIQUE,          -- UID for students/staff
  username VARCHAR(100) UNIQUE,
  password_hash TEXT,
  role VARCHAR(32),
  email VARCHAR(255),
  phone VARCHAR(20),
  created_at TIMESTAMP DEFAULT now()
);

-- Students
CREATE TABLE students (
  student_id BIGSERIAL PRIMARY KEY,
  user_id BIGINT REFERENCES users(user_id),
  program_id INT,
  admission_year INT,
  status VARCHAR(20),
  created_at TIMESTAMP DEFAULT now()
);

-- Courses & Sections
CREATE TABLE courses (
  course_id BIGSERIAL PRIMARY KEY,
  code VARCHAR(20),
  title TEXT,
  credits INT,
  program_id INT
);
CREATE TABLE sections (
  section_id BIGSERIAL PRIMARY KEY,
  course_id BIGINT REFERENCES courses(course_id),
  semester VARCHAR(10),
  capacity INT,
  instructor_id BIGINT REFERENCES users(user_id)
);

-- Enrollments
CREATE TABLE enrollments (
  enrollment_id BIGSERIAL PRIMARY KEY,
  student_id BIGINT REFERENCES students(student_id),
  section_id BIGINT REFERENCES sections(section_id),
  status VARCHAR(20),
  enrolled_at TIMESTAMP DEFAULT now()
);

-- Assessments & Marks
CREATE TABLE assessments (
  assessment_id BIGSERIAL PRIMARY KEY,
  section_id BIGINT REFERENCES sections(section_id),
  kind VARCHAR(50),  -- quiz, assignment, lab, test
  max_marks INT,
  weight NUMERIC,
  scheduled_on DATE,
  created_by BIGINT REFERENCES users(user_id)
);
CREATE TABLE internal_marks (
  id BIGSERIAL PRIMARY KEY,
  assessment_id BIGINT REFERENCES assessments(assessment_id),
  student_id BIGINT REFERENCES students(student_id),
  marks NUMERIC,
  status VARCHAR(20) DEFAULT 'draft', -- draft/approved
  entered_by BIGINT,
  entered_at TIMESTAMP DEFAULT now()
);
CREATE TABLE internal_marks_audit (
  id BIGSERIAL PRIMARY KEY,
  internal_mark_id BIGINT,
  field_name TEXT,
  old_value TEXT,
  new_value TEXT,
  changed_by BIGINT,
  changed_at TIMESTAMP DEFAULT now()
);

-- External marks & exams
CREATE TABLE exams (
  exam_id BIGSERIAL PRIMARY KEY,
  section_id BIGINT REFERENCES sections(section_id),
  exam_type VARCHAR(50),
  exam_date DATE
);
CREATE TABLE external_marks (
  id BIGSERIAL PRIMARY KEY,
  exam_id BIGINT REFERENCES exams(exam_id),
  student_id BIGINT REFERENCES students(student_id),
  marks NUMERIC,
  uploaded_by BIGINT,
  uploaded_at TIMESTAMP DEFAULT now()
);

-- Result snapshots (immutable versions)
CREATE TABLE result_snapshots (
  id BIGSERIAL PRIMARY KEY,
  student_id BIGINT REFERENCES students(student_id),
  section_id BIGINT REFERENCES sections(section_id),
  semester VARCHAR(10),
  raw_internal NUMERIC,
  raw_external NUMERIC,
  total_marks NUMERIC,
  grade VARCHAR(4),
  version INT DEFAULT 1,
  published BOOLEAN DEFAULT false,
  published_at TIMESTAMP,
  published_by BIGINT
);
CREATE INDEX idx_result_student_sem ON result_snapshots(student_id, semester);
      
    

Partitioning / Indexing विभाजन / इंडेक्सिंग

Partition attendance_records and result_snapshots by semester/year. attendance_records और result_snapshots को सेमेस्टर/वर्ष के आधार पर विभाजित करें।

Index commonly queried fields (student_id, section_id, assessment_id, published). आम तौर पर पूछे जाने वाले फ़ील्ड्स को इंडेक्स करें (student_id, section_id, assessment_id, published)।

6. Grade Conversion: Algorithms, Edge Cases & Pseudocode 6. ग्रेड रूपांतरण: एल्गोरिदम, एज केस और स्यूडोकोड

Chandigarh University(CU) uses conversion of total marks to grades — many universities apply relative (norm-referenced) or absolute (criterion-referenced) systems. CU’s official documentation references relative grading & re-evaluation policies; implementable algorithms must be reproducible and parameterizable. चंडीगढ़ विश्वविद्यालय कुल अंकों को ग्रेड में बदलने का उपयोग करता है — कई विश्वविद्यालय सापेक्ष (नॉर्म-रेफरेंस्ड) या निरपेक्ष (मापदंड-रेफरेंस्ड) प्रणालियों को लागू करते हैं। CU की आधिकारिक दस्तावेज़ीकरण सापेक्ष ग्रेडिंग और पुनर्मूल्यांकन नीतियों का उल्लेख करता है; लागू करने योग्य एल्गोरिदम पुनरुत्पाद्य और पैरामीटरीकृत होने चाहिए।

6.1 Relative grading (statistical approach) 6.1 सापेक्ष ग्रेडिंग (सांख्यिकीय दृष्टिकोण)

Compute mean µ and population standard deviation σ for the class totals. कक्षा के कुल अंकों के लिए औसत µ और जनसंख्या मानक विचलन σ की गणना करें।

Convert each student total to z = (score − µ) / σ and map z to grade buckets. For small classes (n < 10), apply smoothing or blend with absolute thresholds to avoid extreme variance. प्रत्येक छात्र के कुल को z = (score − µ) / σ में बदलें और z को ग्रेड बकेट्स में मैप करें। छोटी कक्षाओं (n < 10) के लिए, अत्यधिक विचरण से बचने के लिए स्मूथिंग लागू करें या निरपेक्ष थ्रेशोल्ड के साथ मिश्रण करें।

Pseudocode स्यूडोकोड

      
import statistics

def compute_grades(student_totals, policy):
    # student_totals: list of (student_id, total_marks)
    marks = [m for _, m in student_totals]
    mean = statistics.mean(marks)
    stdev = statistics.pstdev(marks) if len(marks)>1 else 1.0
    results = []
    for sid, m in student_totals:
        z = (m - mean) / stdev
        grade = map_z_to_grade(z, policy)   # policy defines cutoffs
        results.append((sid, m, grade))
    return results
      
    

6.2 Edge cases and mitigations 6.2 एज केस और शमन

Zero σ (all scores equal): fallback to absolute thresholds. शून्य σ (सभी स्कोर समान): निरपेक्ष थ्रेशोल्ड पर वापस जाएँ।

Outliers: detect outliers with IQR and optionally cap influence on µ/σ via winsorization. आउटलायर्स: IQR के साथ आउटलायर्स का पता लगाएँ और वैकल्पिक रूप से µ/σ पर प्रभाव को winsorization के माध्यम से सीमित करें।

Small cohorts: blend relative with absolute grading to maintain fairness. छोटे कोहोर्ट्स: निष्पक्षता बनाए रखने के लिए सापेक्ष को निरपेक्ष ग्रेडिंग के साथ मिश्रित करें।

Auditability: record all intermediate stats (µ, σ, outlier flags, mapping table) with ResultSnapshot to enable reproducible re-runs and external audits. ऑडिट योग्यता: पुनरुत्पाद्य पुन: रन और बाहरी ऑडिट को सक्षम करने के लिए सभी मध्यवर्ती आँकड़े (µ, σ, आउटलायर फ्लैग्स, मैपिंग टेबल) को ResultSnapshot के साथ रिकॉर्ड करें।

7. Asynchronous Worker Design & Queueing 7. असिंक्रोनस वर्कर डिज़ाइन और क्यूइंग

Workloads for workers वर्कर्स के लिए कार्यभार

• GradeConv (heavy compute, CPU bound)GradeConv (भारी गणना, CPU बाउंड)
• DocumentGen (PDF generation)DocumentGen (PDF जनरेशन)
• NotificationDispatcher (emails/SMS/push)NotificationDispatcher (ईमेल/SMS/पुश)
• ETL Jobs (Daily/Weekly to DW)ETL जॉब्स (दैनिक/साप्ताहिक DW के लिए)

Queue & worker patterns क्यू और वर्कर पैटर्न

Use durable, partitioned queues (Kafka or RabbitMQ). टिकाऊ, विभाजित क्यूज़ (Kafka या RabbitMQ) का उपयोग करें।

Ensure idempotency (workers check if ResultSnapshot already exists with that version). Idempotency सुनिश्चित करें (वर्कर्स जाँच करते हैं कि क्या ResultSnapshot उस संस्करण के साथ पहले से मौजूद है)।

Track job metadata: jobs(job_id, type, payload_ref, status, attempts, last_error). जॉब मेटाडेटा ट्रैक करें: jobs(job_id, type, payload_ref, status, attempts, last_error)।

Scaling स्केलिंग

Autoscale workers based on queue backlog and CPU/memory usage. Pre-warm workers before result day. क्यू बैकप्लॉग और CPU/मेमोरी उपयोग के आधार पर वर्कर्स को ऑटोस्केल करें। परिणाम दिन से पहले वर्कर्स को प्री-वॉर्म करें।

8. Deployment, Backup, Disaster Recovery & Scaling 8. तैनाती, बैकअप, आपदा रिकवरी और स्केलिंग

Deployment topology तैनाती टोपोलॉजी

Multi-AZ deployment with read replicas for the database (read pool for reports), stateless app servers behind a load balancer, external file store (S3), and a background worker fleet. डेटाबेस के लिए रीड रिप्लिकास (रिपोर्ट्स के लिए रीड पूल), लोड बैलेंसर के पीछे स्टेटलेस ऐप सर्वर, बाहरी फाइल स्टोर (S3), और बैकग्राउंड वर्कर फ्लीट के साथ मल्टी-AZ तैनाती।

Backups बैकअप

Continuous WAL shipping (if Postgres) + snapshot backups daily, keep on hot and cold storage for retention policy. निरंतर WAL शिपिंग (यदि Postgres) + दैनिक स्नैपशॉट बैकअप, अवधारण नीति के लिए गर्म और ठंडे स्टोरेज पर रखें।

DR आपदा रिकवरी

Cross-region cold standby or warm standby depending on RTO targets. Test failover annually. RTO लक्ष्यों के आधार पर क्रॉस-रीजन कोल्ड स्टैंडबाय या वार्म स्टैंडबाय।每年测试故障转移।

Scaling policies स्केलिंग नीतियाँ

Database: vertical for write node; read scaling via replicas. डेटाबेस: राइट नोड के लिए वर्टिकल; रिप्लिकास के माध्यम से रीड स्केलिंग।

Application: horizontal scaling with autoscaling groups. एप्लिकेशन: ऑटोस्केलिंग समूहों के साथ क्षैतिज स्केलिंग।

Worker fleet: scale based on queue metrics. वर्कर फ्लीट: क्यू मेट्रिक्स के आधार पर स्केल करें।

9. Observability, Monitoring & Runbooks 9. प्रेक्षणीयता, मॉनिटरिंग और रनबुक

Key metrics प्रमुख मेट्रिक्स

API latency (P50/P95/P99), DB CPU & connections, queue lag (jobs waiting), worker failure rates, PDF gen throughput, publish job durations. API विलंबता (P50/P95/P99), DB CPU और कनेक्शन, क्यू लैग (जॉब्स प्रतीक्षा में), वर्कर विफलता दर, PDF जनरेशन थ्रूपुट, प्रकाशन जॉब अवधि।

Logging & tracing लॉगिंग और ट्रेसिंग

Structured JSON logs and distributed tracing (OpenTelemetry). Request IDs must flow across gateway and background workers. संरचित JSON लॉग और वितरित ट्रेसिंग (OpenTelemetry)। अनुरोध IDs को गेटवे और बैकग्राउंड वर्कर्स में प्रवाहित होना चाहिए।

Result-Day runbook (condensed but specific) परिणाम-दिवस रनबुक (संक्षिप्त लेकिन विशिष्ट)

1. Freeze grade entry (feature flag) one hour before publish.प्रकाशन से एक घंटे पहले ग्रेड प्रविष्टि को फ्रीज करें (फीचर फ्लैग)।
2. Run dry-run grade conversion and inspect anomalies (zero variance, gaps). Export diagnostics.ड्राई-रन ग्रेड रूपांतरण चलाएँ और विसंगतियों की जाँच करें (शून्य विचरण, अंतराल)। डायग्नोस्टिक्स निर्यात करें।
3. If dry-run passes, enqueue real conversion with job id; monitor job progress and queue backlogs.यदि ड्राई-रन पास होता है, तो जॉब ID के साथ वास्तविक रूपांतरण को क्यू में डालें; जॉब प्रगति और क्यू बैकप्लॉग की निगरानी करें।
4. Pre-generate top N PDFs and perform sample downloads.शीर्ष N PDFs को पहले से जनरेट करें और नमूना डाउनलोड करें।
5. Throttle notification sends (1000 SMS/min depending on gateway limits).अधिसूचना भेजने को थ्रॉटल करें (गेटवे सीमाओं के आधार पर 1000 SMS/मिनट)।
6. If critical errors occur, abort publish, revert to previous published ResultSnapshot, and notify stakeholders.यदि गंभीर त्रुटियाँ होती हैं, तो प्रकाशन रद्द करें, पिछले प्रकाशित ResultSnapshot पर वापस जाएँ, और हितधारकों को सूचित करें।

10. Security, Privacy & Compliance 10. सुरक्षा, गोपनीयता और अनुपालन

Authentication & Access प्रमाणीकरण और पहुंच

Centralized SSO (LDAP / OAuth2) for staff; student SSO with UID + OTP flows. RBAC for endpoints (only Controller can publish results). 2FA for critical operations. कर्मचारियों के लिए केंद्रीकृत SSO (LDAP / OAuth2); UID + OTP प्रवाह के साथ छात्र SSO। एंडपॉइंट्स के लिए RBAC (केवल नियंत्रक परिणाम प्रकाशित कर सकता है)। महत्वपूर्ण संचालनों के लिए 2FA।

Data protection डेटा संरक्षण

TLS everywhere; encrypt data at rest (database & blob storage). PII minimization for analytics extracts. हर जगह TLS; डेटा को रेस्ट पर एन्क्रिप्ट करें (डेटाबेस और ब्लॉब स्टोरेज)। एनालिटिक्स अर्क के लिए PII न्यूनीकरण।

Audit & non-repudiation ऑडिट और गैर-अस्वीकरण

Append-only audit logs for marks/grade changes; signed result artifacts to prevent tampering. अंकों/ग्रेड परिवर्तनों के लिए केवल-जोड़ें ऑडिट लॉग; छेड़छाड़ को रोकने के लिए हस्ताक्षरित परिणाम आर्टिफैक्ट्स।

Regulatory considerations नियामक विचार

Comply with applicable national data protection practices; apply retention policy for student records as per University rules. लागू राष्ट्रीय डेटा संरक्षण प्रथाओं का पालन करें; विश्वविद्यालय नियमों के अनुसार छात्र रिकॉर्ड के लिए अवधारण नीति लागू करें।

11. Testing & Quality Assurance 11. परीक्षण और गुणवत्ता आश्वासन

Test tiers परीक्षण स्तर

Unit tests for grade conversion, input validation, and API contracts. ग्रेड रूपांतरण, इनपुट सत्यापन, और API अनुबंधों के लिए यूनिट टेस्ट।

Integration tests for UI → API → DB (containerized test environment). UI → API → DB (कंटेनरीकृत परीक्षण वातावरण) के लिए एकीकरण परीक्षण।

End-to-end tests simulating faculty flows (marks upload, review, publish). फैकल्टी प्रवाह (अंक अपलोड, समीक्षा, प्रकाशन) का अनुकरण करने वाले अंत-से-अंत परीक्षण।

Load testing: simulate peak publish day with tools like k6 or Gatling (API throughput for grade jobs + PDF gen). लोड टेस्टिंग: k6 या Gatling जैसे उपकरणों के साथ पीक प्रकाशन दिन का अनुकरण करें (ग्रेड जॉब्स + PDF जनरेशन के लिए API थ्रूपुट)।

Security testing: SAST, DAST, and periodic penetration tests (focus on auth bypass, file upload, RCE in PDF libs). सुरक्षा परीक्षण: SAST, DAST, और आवधिक प्रवेश परीक्षण (प्रमाणीकरण बायपास, फाइल अपलोड, PDF लाइब्रेरीज़ में RCE पर ध्यान दें)।

Test dataset & reproducibility परीक्षण डेटासेट और पुनरुत्पादकता

Maintain synthetic datasets representing small, medium, and large cohorts to validate conversion algorithm behavior under variability. छोटे, मध्यम, और बड़े कोहोर्ट्स का प्रतिनिधित्व करने वाले सिंथेटिक डेटासेट्स को बनाए रखें ताकि परिवर्तनशीलता के तहत रूपांतरण एल्गोरिदम व्यवहार को सत्यापित किया जा सके।

12. Performance & Optimization Details 12. प्रदर्शन और अनुकूलन विवरण

DB indexing DB इंडेक्सिंग

Covering indexes on (assessment_id, student_id) and result_snapshots(student_id, semester); partition result_snapshots by semester. (assessment_id, student_id) और result_snapshots(student_id, semester) पर कवरिंग इंडेक्स; result_snapshots को सेमेस्टर द्वारा विभाजित करें।

Materialized views मटेरियलाइज़्ड व्यूज़

Precompute student_semester_gpa as a materialized view refreshed nightly for fast queries. तेज़ क्वेरीज़ के लिए student_semester_gpa को रात में ताज़ा किए गए मटेरियलाइज़्ड व्यू के रूप में प्री-कम्प्यूट करें।

Caching कैशिंग

CDN for SSR pages; Redis for session caches and frequently accessed aggregates (attendance summaries). SSR पेजों के लिए CDN; सत्र कैश और बार-बार एक्सेस किए गए एकत्रीकरण (उपस्थिति सारांश) के लिए Redis।

Query patterns to watch देखने योग्य क्वेरी पैटर्न

Avoid large aggregates during conversion; use batch windowing and incremental aggregation to limit DB locks. रूपांतरण के दौरान बड़े एकत्रीकरण से बचें; DB लॉक को सीमित करने के लिए बैच विंडोइंग और वृद्धिशील एकत्रीकरण का उपयोग करें।

13. Common Problems, Diagnostics & Fixes 13. सामान्य समस्याएँ, डायग्नोस्टिक्स और सुधार

Problem: Internal marks entered but not shown to students समस्या: आंतरिक अंक दर्ज किए गए लेकिन छात्रों को नहीं दिखाए गए

Diagnosis: Check internal_marks.status — if draft, surface UI to guide Department to approve per policy. निदान: internal_marks.status की जाँच करें — यदि ड्राफ्ट, तो नीति के अनुसार विभाग को अनुमोदन के लिए मार्गदर्शन करने हेतु UI को सतह पर लाएँ।

Fix: Add departmental preview/publish workflow; highlight pending approvals with timestamps. सुधार: विभागीय पूर्वावलोकन/प्रकाशन वर्कफ़्लो जोड़ें; टाइमस्टैम्प के साथ लंबित अनुमोदनों को हाइलाइट करें।

Problem: Publish fails at scale (PDF generation) समस्या: बड़े पैमाने पर प्रकाशन विफल (PDF जनरेशन)

Diagnosis: Worker OOM, library memory leaks, throughput saturation. निदान: वर्कर OOM, लाइब्रेरी मेमोरी लीक, थ्रूपुट संतृप्ति।

Fix: Use headless PDF library with streaming, scale workers, pre-generate PDFs; implement circuit-breaker on third-party font/asset calls. सुधार: स्ट्रीमिंग के साथ हेडलेस PDF लाइब्रेरी का उपयोग करें, वर्कर्स को स्केल करें, PDFs को पहले से जनरेट करें; तृतीय-पक्ष फ़ॉन्ट/एसेट कॉल्स पर सर्किट-ब्रेकर लागू करें।

      
Frontend: Next.js (SSR) for public pages + React for internal portals.
Mobile: Native Kotlin app (CUIMS mobile) or React Native for hybrid; SSO via in-app browser for security. (CUIMS mobile presence is public in app stores.) 
API / Backend: Python (FastAPI) or Node.js (Express) for services.
DB: PostgreSQL (ACID) with read replicas.
Queue: Kafka (high throughput) or RabbitMQ (simplicity).
Storage: S3 for documents/PDFs.
Auth: LDAP/SSO + OAuth2 + 2FA.
Monitoring: Prometheus + Grafana + CloudWatch (if on AWS).
CI/CD: GitHub Actions / GitLab CI; infra as code (Terraform).
Analytics: ETL to Redshift / BigQuery / Snowflake.
      
    

16. Appendix — Representative API Contracts and Scripts 16. परिशिष्ट — प्रतिनिधि API अनुबंध और स्क्रिप्ट्स

Marks upload (CSV) endpoint (contract) अंक अपलोड (CSV) एंडपॉइंट (अनुबंध)

      
POST /faculty/assessments/{assessmentId}/marks
Content-Type: multipart/form-data
Form Data:
 - file: marks.csv
 - mode: upsert
Auth: Bearer 
      
    

Result publish (controller) परिणाम प्रकाशन (नियंत्रक)

      
POST /results/publish
{
  "section_id": 12345,
  "semester": "2025-Spring",
  "dry_run": false,
  "approved_by": 9876
}
      
    

ETL Airflow DAG (pseudocode) ETL Airflow DAG (स्यूडोकोड)

      
with DAG('attendance_to_dw', schedule_interval='@daily') as dag:
    extract = PythonOperator(task_id='extract', python_callable=fetch_attendance)
    transform = PythonOperator(task_id='transform', python_callable=transform_to_dw)
    load = PythonOperator(task_id='load', python_callable=load_to_dw)
    extract >> transform >> load
      
    

17. Conclusion 17. निष्कर्ष

This document provides a complete, production-grade, research-level description of CUIMS (Chandigarh University(CU) Information Management System) suitable for publication as an in-depth technical article or internal architecture reference. It covers the entire student and administrative life cycle, detailed ASCII architectures, canonical database schemas, grade conversion algorithms, operational runbooks, security requirements, and implementable API contracts. Public, verifiable facts (CUIMS portal, System of Evaluation rules, Blackboard integration) anchor the design; where specifics were not public, the document provides pragmatic, auditable, and reproducible engineering patterns consistent with large university ERP systems. यह दस्तावेज़ CUIMS (चंडीगढ़ विश्वविद्यालय सूचना प्रबंधन प्रणाली) का एक पूर्ण, उत्पादन-ग्रेड, शोध-स्तरीय विवरण प्रदान करता है जो गहन तकनीकी लेख या आंतरिक आर्किटेक्चर संदर्भ के रूप में प्रकाशन के लिए उपयुक्त है। यह पूरे छात्र और प्रशासनिक जीवन चक्र, विस्तृत ASCII आर्किटेक्चर, कैननिकल डेटाबेस स्कीमा, ग्रेड रूपांतरण एल्गोरिदम, परिचालन रनबुक, सुरक्षा आवश्यकताएँ, और लागू करने योग्य API अनुबंधों को कवर करता है। सार्वजनिक, सत्यापन योग्य तथ्य (CUIMS पोर्टल, मूल्यांकन प्रणाली नियम, Blackboard एकीकरण) डिज़ाइन को आधार प्रदान करते हैं; जहां विशिष्टताएँ सार्वजनिक नहीं थीं, दस्तावेज़ बड़े विश्वविद्यालय ERP सिस्टम के साथ संगत व्यावहारिक, ऑडिट योग्य, और पुनरुत्पाद्य इंजीनियरिंग पैटर्न प्रदान करता है।