Dhte DPR Revised

2.
DETAILED PROJECT REPORT

February 2024
Final Report
Provision of IT Advisory Services to
Department of Higher & Technical Education
Government of Jharkhand
Submitted by
National Institute for Smart Government
Department of Higher and Technical Education - Government of Jharkhand
This page has been intentionally left blank
Common Digital System of DHTE – Detailed Project Report 1

Table of Contents
Abbreviations............................................................................................................................................................. 5
1. Scope of this Document ............................................................................................................................... 6
2. Synopsis of the Detailed Project Report (DPR) .................................................................................... 7
2.1 Project Background ........................................................................................................................................ 7
2.1.1 Modules Common for DHTE and Universities ............................................................................ 7
2.1.2 Module for DHTE ................................................................................................................................... 7
2.1.3 Modules for Universities and Colleges .......................................................................................... 7
2.2 Implementation Model ................................................................................................................................. 7
2.3 Assessment and Estimation for Solution Sizing .................................................................................. 8
2.3.1 Number of Users .................................................................................................................................... 8
2.3.2 Number of Concurrent Users ............................................................................................................ 8
2.3.3 Storage Requirement ........................................................................................................................... 9
2.4 Implementation Timeline ............................................................................................................................. 9
2.5 Training Requirements .................................................................................................................................. 9
2.5.1 Estimated Number of users to be trained .................................................................................... 9
2.6 Helpdesk Support ........................................................................................................................................ 10
2.7 Monitoring of Service Level Agreement (SLA) .................................................................................. 10
2.8 Project Governance ..................................................................................................................................... 10
2.8.1 Steering Committee ........................................................................................................................... 10
2.8.2 Program Management Unit ............................................................................................................ 11
2.9 Operation & Maintenance Phase........................................................................................................... 11
2.10 Estimation of Project Cost ........................................................................................................................ 11
3. Stakeholders In Higher and Technical Education Ecosystem ...................................................... 13
4. Functional Requirement ............................................................................................................................ 13
4.1 Modules Common for DHTE and Universities .................................................................................. 13
4.1.1 Human Resources Management System (HRMS) .................................................................. 13
4.1.2 Office Management ........................................................................................................................... 18
4.2 Modules specific to DHTE ......................................................................................................................... 28
4.3 Modules specific to universities ............................................................................................................. 31
5. Non - Functional/ Technical Requirements ....................................................................................... 59
5.1 Solution Architecture .................................................................................................................................. 59
5.2 Users ................................................................................................................................................................. 59
5.3 Gateways ......................................................................................................................................................... 61
5.4 Presentation Layer ....................................................................................................................................... 62
5.4.1 Security Layer and Strategic Controls ......................................................................................... 62
5.4.2 Data Layer .............................................................................................................................................. 62
5.4.3 Monitoring Services ........................................................................................................................... 63
5.4.4 Architectural Requirements ............................................................................................................ 63
5.4.5 Storage Requirement: ....................................................................................................................... 64
5.4.6 Network requirement ........................................................................................................................ 65
5.4.7 Server(s) requirement ........................................................................................................................ 65
5.4.8 Security Requirement ........................................................................................................................ 65
5.4.9 Email Service ......................................................................................................................................... 68
5.4.10 Content Management System ....................................................................................................... 68

5.4.11 Host Based Security System ........................................................................................................... 69

5.5 Hardware and Software Requirements (Item wise)......................................................................... 70
6. Implementation Model .............................................................................................................................. 72
7. Timelines ......................................................................................................................................................... 73
8. Scope of Work for the Implementation Agency .............................................................................. 74
8.1 Requirements Gathering and SRS Preparation................................................................................. 74
8.2 Design, Development and Testing of Common Digital System of DHTE ............................... 74
8.3 Migration of legacy data ........................................................................................................................... 74
8.4 Setting Up of Data Center and Disaster Recovery Center ............................................................ 75
8.5 Procurement, Installation, Configuration and Commissioning of Server-Side Hardware 75
8.6 Implementation of Various Change Management Initiatives ..................................................... 75
8.7 Operations and Maintenance (O&M) .................................................................................................. 75
8.7.1 Application Management ................................................................................................................ 76
8.7.2 Infrastructure Management ............................................................................................................ 76
8.7.3 Network management ...................................................................................................................... 77
8.7.4 Implementation of SLA Monitoring System ............................................................................. 79
8.8 Data and Information Security Requirements................................................................................... 79
8.9 Documentation Requirements ................................................................................................................ 80
8.10 Warranty .......................................................................................................................................................... 80
8.11 Support for Acceptance Testing and Certification .......................................................................... 81
9. DHTE Strategic Control Requirements................................................................................................. 82
9.1 Requirements of Strategic Control Over Application..................................................................... 82
9.1.1 Retention of Ownership and Control Over Core and Configurable Modules ............. 82
9.1.2 Application Audit ................................................................................................................................ 83
9.1.3 Version Control.................................................................................................................................... 83
9.1.4 Role Segregation ................................................................................................................................ 83
9.2 Requirements of Strategic Control Over Database......................................................................... 83
9.2.1 Retention Of Ownership and Control Over the Database .................................................. 83
9.2.2 Process Controls on Database Administration ........................................................................ 84
9.2.3 Audit of DBA Actions......................................................................................................................... 84
9.2.4 Protection of Confidentiality and Integrity of Data ............................................................... 84
9.2.5 Role Segregation ................................................................................................................................ 84
9.3 Requirements of Strategic Control Over Security Administration and Network
Administration ........................................................................................................................................................ 85
10. Acceptance of System for Go-Live ........................................................................................................ 86
11. Program Governance.................................................................................................................................. 87
11.1 Steering Committee .................................................................................................................................... 87
11.2 Program Management Unit ..................................................................................................................... 87
11.3 IA Program Management Requirements ............................................................................................ 87
12. Audit Requirements (Quality Control).................................................................................................. 89
13. Requirements for Adherence to Standards ....................................................................................... 90
14. Exit Management ......................................................................................................................................... 91

Table of Figures
FIGURE 1: RECRUITMENT /POSTING/TRANSFER OF STAFF AND FACULTY ............................................................................ 14
FIGURE 2: PROMOTION PROCESS ................................................................................................................................. 15
FIGURE 3: LEAVE MANAGEMENT PROCESS .................................................................................................................... 16
FIGURE 4: PAYROLL MANAGEMENT PROCESS ................................................................................................................ 17
FIGURE 5 PENSIONS ................................................................................................................................................... 18
FIGURE 6: ONLINE FILE PROCESSING ............................................................................................................................ 19
FIGURE 7: INVENTORY MANAGEMENT .......................................................................................................................... 20
FIGURE 8: DAK MANAGEMENT PROCESS...................................................................................................................... 21
FIGURE 9: GRIEVANCE RESOLUTION ............................................................................................................................. 22
FIGURE 10: RIGHT TO INFORMATION ........................................................................................................................... 23
FIGURE 11: FINANCE (BUDGE AND ACCOUNTS).............................................................................................................. 24
FIGURE 12: TRACKING OF COURT CASES ....................................................................................................................... 24
FIGURE 13: ONLINE FEE PAYMENT............................................................................................................................... 24
FIGURE 14: EXAMINATION FEE .................................................................................................................................... 25
FIGURE 15: APPROVAL OF NEW UNIVERSITY ................................................................................................................. 29
FIGURE 16: USER REGISTRATION/ CREATION................................................................................................................. 30
FIGURE 17 UNIVERSITY INTERACTION CELL ..................................................................................................................... 31
FIGURE 18: STUDENT REGISTRATION ............................................................................................................................ 32
FIGURE 19: SELECTION OF COURSE .............................................................................................................................. 33
FIGURE 20: SUBMISSION OF FEE .................................................................................................................................. 33
FIGURE 21: GENERATION OF MERIT LIST....................................................................................................................... 34
FIGURE 22: GENERATION OF ENROLMENT NUMBER ........................................................................................................ 34
FIGURE 23: AFFILIATION OF COLLEGES .......................................................................................................................... 35
FIGURE 24: HOSTEL MANAGEMENT ............................................................................................................................. 36
FIGURE 25: RESEARCH WORK MANAGEMENT ............................................................................................................... 37
FIGURE 26: ATTENDANCE MANAGEMENT ..................................................................................................................... 38
FIGURE 27: EXAMINATION MANAGEMENT .................................................................................................................... 42
FIGURE 28: EXAMINATION ONLINE/ OFFLINE MODE ...................................................................................................... 43
FIGURE 29: EXAMINATION TIMETABLE ......................................................................................................................... 44
FIGURE 30: EVALUATION OF EXAMINATION PAPERS ....................................................................................................... 45
FIGURE 31: CERTIFICATE MANAGEMENT ....................................................................................................................... 46
FIGURE 32: CHALLENGES IN MARKSHEET ...................................................................................................................... 47
FIGURE 33: CORRECTION PROCESS AND RE-ISSUANCE OF CERTIFICATES .............................................................................. 48
FIGURE 34: END OF COURSE ....................................................................................................................................... 49
FIGURE 35: TRANSFER CERTIFICATES ............................................................................................................................ 50
FIGURE 36: MIGRATION CERTIFICATE ........................................................................................................................... 51
FIGURE 37: ACADEMIC STAFF RECRUITMENT PROCESS ................................................................................................... 52
FIGURE 38: ENROLMENT OF ACADEMIC STAFF ............................................................................................................... 53
FIGURE 39: NON- ACADEMIC POST CREATION ............................................................................................................... 54
FIGURE 40: ENROLMENT OF NON-ACADEMIC STAFF ....................................................................................................... 55
FIGURE 41: LIBRARY MANAGEMENT ............................................................................................................................ 56
FIGURE 42: SECURITY REQUIREMENTS .......................................................................................................................... 66
FIGURE 43: PROJECT TIMELINE .................................................................................................................................... 73
FIGURE 44: PROGRAM GOVERNANCE ........................................................................................................................... 87

Abbreviations
Abbreviation Explanation
API Application Programming Interface
DHTE Department of Higher and Technical Education, Government of Jharkhand
JUT Jharkhand University of Technology
RU Ranchi University
DC Data Centre
DRC Disaster Recovery Centre (Also referred as DR)
IA Implementation Agency
3PAA Third Party Audit Agency appointed by the Department to audit the project
PoP Point of Presence
DPR Detailed Project Report
SRS Software Requirement Specifications
SLA Service Level Agreement
UAT User Acceptance Testing

1. Scope of this Document

As a part of the deliverables under its engagement with DHTE, NISG has previously submitted
‘As-Is Report”, ‘Best Practices Study’ and ‘To-Be Report’. This Detailed Project Report (DPR) is
the final document in this series and the topics covered under it are as given below:
(i) Synopsis of the DPR
(ii) Stakeholders In Higher and Technical Education Ecosystem
(iii) Functional Requirement
(iv) Non - Functional/ Technical Requirements
(v) Implementation Model
(vi) Timelines
(vii) Scope of Work for the Implementation Agency
(viii) DHTE Strategic Control Requirements
(ix) Acceptance of System for Go-Live
(x) Program Governance
(xi) Audit Requirements (Quality Control)
(xii) Requirements for Adherence to Standards
(xiii) Exit Management

2. Synopsis of the Detailed Project Report (DPR)

A brief of this Detailed Project Report is placed in this chapter for reference.
2.1 Project Background

DHTE plans to leverage the technology to streamline its processes for managing the Higher
Education Institutes and improve the quality of the services provided by these institutes.
This is planned to be achieved by implementing an integrated Common Digital System of
DHTE to automate the services provided by DHTE, Ranchi University and the other Universities
of Jharkhand. For this purpose, the following online modules are proposed to be implemented.
2.1.1 Modules Common for DHTE and Universities

(i) Human Resources Management System (HRMS)
(a) Recruitment of Staff and Faculty
(b) Service Record (Transfer, Posting, Promotion, Leave, Training and Retirement)
(c) Payroll (Including Payroll management, Pay fixation etc.)
(ii) Office Management
(a) Online File Processing
(b) Inventory Management
(c) Dak Management
(d) Grievance Resolution
(e) Right To Information (RTI)
(f) Finance (Budget and Accounts)
(g) Tracking of Court Cases
(h) Online Fee Payment
2.1.2 Module for DHTE

(i) Approval for New Universities
(ii) User Registration/ Creation
2.1.3 Modules for Universities and Colleges

(i) Student Life Cycle Management (Registration and Admission)
(ii) Affiliation of colleges
(iii) Hostel Management (Admission/ NOC)
(iv) Research Work Management
(v) Classroom Management
(vi) Attendance Management
(vii) Examination Management
(viii) Evaluation of Answer Sheet
(ix) Certificate Management (Marksheet, Degree, Diploma etc.)
(x) Library management
2.2 Implementation Model

The Common Digital System of DHTE is planned to be built and operated in an outsourced
model. Such a model would allow DHTE to address important factors such as DHTE’s

ownership of the Common Digital System of DHTE and to benefit from specialized expertise
of private sector. An Implementation Agency (IA) shall be selected to implement the project.
2.3 Assessment and Estimation for Solution Sizing
2.3.1 Number of Users

The expected number of users using the DHTE Common Digital Platform are estimated as
below
# Group Total No. of Users Estimated

at present Annual increase
1. DHTE 50 10%
2. Faculty Total-3,000 10%
(For all 8 Govt. Universities (From Ranchi University,
and all constituents’ Jharkhand University of
colleges whose salaries are
Technology and the other
paid by the respective
6 Universities)
University)
3. Non-Faculty Total-1,000 10%
(For all 8 Govt. Universities (From Ranchi University,
and all constituents’ Jharkhand University of
colleges whose salaries are
Technology and the other
paid by the respective
6 Universities)
University)
4. College 250 10%
One user id will be given to
each of the college for
uploading the attendance
of the students
5. Students 5,00,000 (per year) 10%
2.3.2 Number of Concurrent Users

The number of concurrent users is one of the important criteria for deciding the
hardware sizing of the project. It is expected that there would be around 4000 official
users approximately and the students who would be using the Common Digital system
of DHTE. A concurrency of 200 users is envisaged during the non-peak months. The
peak months would be the month of July- August when a large no. of applicants may
be using the Common Digital System of DHTE for registration for new admissions.
Apart from that there could be another peak season in the months of November and
March during the submission of Examination Form. During this peak season, a
concurrency 500 users is envisaged at this stage. In case of concurrency of users

increases from the envisaged numbers, the system would require the increase in
hardware capacity.
# Description Number
1 No. of Concurrent users (except for peak season) 400
2. No. of Concurrent users (during the peak season) 800
2.3.3 Storage Requirement

# Item Requirement Total
(DC and DR)
1 Storage on use (for all requirements 25 TB each at 50 TB
except point 2 below) DC & DR
2 Storage for scanned answer sheets 200 TB each at 400 TB
(Scanned Answer sheets beyond 3 years DC & DR
of age shall be purged/deleted)
In case, any such archival information requires to be extracted, the Past Backup (from
the Tape Library) may be relied upon.
2.4 Implementation Timeline

The overall implementation of the project could take approximately 14 months from the date
of signing of the contract with the identified Implementation Agency. The implementation of
the project can be done in phased manner and the various modules, or the components of
the modules can be rolled out at an earlier date. For example, it is envisaged that components
like Student Registration, Online Fee Payment, Online File Processing, and Dak Management
etc. can be rolled out by the six months of the contract signing.
2.5 Training Requirements

Training is one of the critical aspects for the successful adoption of the Common Digital System
of DHTE. The purpose of this component shall be to equip the end-users with the adequate
knowledge to be able to use the Common Digital System of DHTE. The Implementation
Agency shall create a training plan for the users and the material for the target users. For the
training following consideration shall be applicable –
2.5.1 Estimated Number of users to be trained

# Group Total No. of Users
1 DHTE 50
2 University (Faculty) [Module wise training to be provided] 1,000
3 University (Non-Faculty) [Module wise training to be provided] 1,000
Total 2,050
(i) DHTE and various Universities shall identify the users from various Department for the
training. The users trained by the Implementation Agency shall further train the users in
their respective Departments.

(ii) Training shall be conducted at the premises of the DHTE and the Universities. All the
facilities such as training room, projector etc. are to be arranged by the DHTE/
Universities. Implementation Agency shall require to deliver the training through their
instructor using the training material prepared by them.
2.6 Helpdesk Support

Implementation Agency shall set up an appropriately staffed and centralized helpdesk for
providing helpdesk support to various users of the Common Digital System of DHTE. The
broad set of activities as part of helpdesk support includes:
(i) Receiving incidents/requests through phone or email. Entering of the incidents in the
helpdesk application and informing the user of the unique incident id generated
through email
(ii) Routing incidents internally between teams and tracking till resolution
(iii) Providing updates to users on incidents logged
(iv) Periodic reporting of incidents providing details including (but not limited to) number of
incidents reported, reporting mechanism (phone/ email)
(v) Escalation of any untoward incidents to DHTE on an immediate basis for reporting
purposes / action from DHTE.
2.7 Monitoring of Service Level Agreement (SLA)

Implementation Agency shall design and implement an SLA measurement & reporting system
to measure and report performance of the Common Digital System of DHTE against the service
levels. The system shall also allow calculation of scheduled payments to Implementation
Agency and any rewards and penalties as specified by DHTE. The SLA measurement &
reporting system shall be reviewed and certified by a Third-Party Audit Agency (TPAA) before
project go-live and start of operations. DHTE officials and PMU personnel shall be provided
real-time access to the system. Additionally, DHTE designated personnel should be provided
administrative privileges to the system as per the agreed role assigned for them.
2.8 Project Governance

The DHTE project envisages transforming University Management into a simple, transparent,
and orderly process. Implementing such a program that would impact citizens in a direct
manner and has linkages with a wide-ranging set of stakeholders is likely to encounter various
challenges. Therefore, an appropriate governance structure comprising of a Steering
Committee (SC) and a Program Management Unit (PMU) shall be put in place by DHTE to
ensure the long-term success of the project.
2.8.1 Steering Committee

The steering committee would be responsible for providing guidance and requisite resources
to the project. The committee would comprise senior DHTE officials and may have
representatives from other Departments and/ or agencies as deemed necessary by DHTE. The
committee would meet on a monthly basis with the PMU to monitor the project and help in

overcoming the obstacles encountered during the project implementation. The chairperson (a
senior DHTE official, to be decided by DHTE) may also convene ad-doc meetings, if required.
2.8.2 Program Management Unit

The PMU shall comprise experts who would be helping DHTE monitor the project’s
implementation as per objectives and requirements laid down. The functions of PMU shall
include:
(i) Monitoring project implementation in terms of quality, time, scope, and budget
(ii) Providing guidance to IA and helping DHTE in decision making and issue resolution
(iii) Reviewing deliverables and providing recommendation for signoffs
(iv) Coordinating with various internal and external stakeholders
(v) Reporting to the steering committee on project matter
The Implementation Agency shall report to the PMU on an ongoing basis.
2.9 Operation & Maintenance Phase

Implementation Agency shall provide Operations and Maintenance (O&M) support for
envisaged for Common Digital System of DHTE and related components from the date of
declaration of Go Live of the Application and shall continue to support for the subsequent 5
years and up-to 2 years of extended period.
2.10 Estimation of Project Cost

Implementation of the project shall involve the following, after onboarding of the
Implementation Agency to be selected through RFP and competitive open tender process.
(i) Development of Software Application (i.e., Bespoke Software) or customization of any
COTS (Commercially Off the Shelf) Application, as per the requirement of DHTE.
(ii) Hosting and deployment of the software application. Following 3 options were assessed
for hosting the proposed Common Digital Platform for DHTE.
a. Co-located DC/DR setup at Jharkhand State Data Center (SDC)
b. Third Party on-premises DC/DR setup
c. Cloud based DC/DR Setup
After examining the above three options, the option of CLOUD based hosting is found to be
a preferable option as compared to the other two options, even though the cost of cloud-
based hosting may be slightly higher as compared to the SDC. However, the Cloud hosting
would be more efficient in terms of availability of services, resource utilisation, performance,
and scalability. Also, it might be easier to enforce SLA on a private cloud service provider than
on SDC. MeitY has also empanelled a set of Cloud Service Providers which further validates
the preference for cloud in the Government of India. In view of the above, the cost estimation
for Cloud based hosting is suggested below.

S. No Budget estimate for Cost of project with hosting on Cloud Cost

1. RFP & Bid Process Management ₹ 0.15 Cr
2. Cost of Application software to be developed/ Customized by the ₹ 15.00 Cr
Implementation Agency - Bespoke/ COTS
3. Cost for Software Changes after Go-Live ₹ 5.00 Cr
4. Application Support cost after Go-Live ₹ 18.00 Cr
5. CLOUD Hosting charges (1 year for implementation, 5 years of ₹ 12.00 Cr
operations and maintenance and 1 year for transition)
6. Training/Capacity Building (Allocation One time) ₹ 1.00 Cr
To be consumed through the complete project cycle
7. Digitization and Data Migration One time ₹ 1.50 Cr
8. PMU – Cost for 7 Years ₹ 11.58 Cr
st
[1 year for Implementation phase
5 years for Operations & maintenance phase and
1 year for transition from the incumbent implementation agency to
the other]
Total ₹64.23 Cr
• the above total estimated cost may be rounded up slightly higher for budgeting purpose.

3. Stakeholders In Higher and Technical Education Ecosystem

The Key stakeholders and their roles in Higher and Technical education ecosystem are
highlighted below-
S. No Stakeholder Role/ Services provided in Higher and Technical Education

1. DHTE Approval for new Universities
2. University Approval for new Colleges
Admission of new Student
Conduct of Examination
Preparation and Declaration of Result
3. Student Studies
4. Functional Requirement
Baseline functional requirement of the project is outlined in this section.
4.1 Modules Common for DHTE and Universities
4.1.1 Human Resources Management System (HRMS)

(i) Office of the Registrar
Objective - Registrar of the University is the administrative head of the University, with
responsibilities
1. Hire, supervise and evaluate the Records and Registration staff
2. Organize and administer the academic functions, in order to provide maximum
service to students while ensuring efficient and effective workflow.
3. Participate and serve as part of the Student Services Team. Lead initiatives as
determined by the University
4. Supervise the coordination, evaluation and certification of all graduation
applications, while overseeing the complete graduation process to include all
elements of the rehearsal and ceremony
5. Responsible for collecting, recording, maintaining and reporting of student records
within UGC guidelines, e.g., grades, registration data, transcripts, mid-term
verification, athletic eligibility and other associated audits
6. Provide leadership and develop appropriate recommendations for the
implementation of related technology application in support of enhanced services
offered through Registration and Records
7. Develop and administer the departmental budget
8. Research, analysis and resolution of student disputes as they relate to records and
registration
9. Collaborate with administrators, deans, faculty, IT and counsellors to facilitate and
improve services to students, including catalogue and registration/records policy
questions

10. Coordinate, control and regulate all activities of administration, human resources,
Finance & Accounts and other related matters for efficient functioning of the
University
11. Execute and administer the outsourcing contracts for various services of the
University
12. Serve as ex-officio member of Academic and Administrative Committees as per the
Act
Being the Administrative Head of the Institution, Automation of Administrative functions
for the University will be overseen, supervised by the Registrar / Registrars.
(ii) Recruitment of Staff and Faculty
Objective: To maintain the record of the new recruitment
Process Flow:
(a) A request is initiate by appropriate department in DHTE for new recruitment.
(b) Copies of the relevant documents are uploaded, and the request is forwarded to
the approving authority.
(c) In case any offline processing is required at any stage, the relevant file no. and DAK
Number can be noted, and the initiated request can be closed.
(d) The details of newly recruited/ posted employees are entered in the system by
appropriate Division in DHTE. System shall automatically create a user id for such
staff.
(e) The same process holds similar in case of Posting/Transfer of employees
Creation of Post – by University
Academic Post Creation
University
University No Action Sent for
Study
Study reveals,
reveals, there
there concurrence from POST(s)
Starts
Starts the
the N needed
isis requirement
requirement ofof Other departments, Created
process End of process
process academic
academic posts
posts CMO etc
University
No need of posts
University
University
University
University conducts
conducts aa Moots
Moots up
up aa
Outcome Posts
study proposal
proposal
study on
on requirement
requirement forfor of study
Required
academic For
For such
such Posts
Posts
academic positions
positions
Seeks
Clarifications from
University sends proposal University
with concurrence Re-submit
No Yes
Proposal from higher authorities N
Merit
received by
DHTE
DHTE
DHTE Examines the Merit
Proposal Clarifications
In
proposal status Proposal if any
No Clarification needed
Chancellors office
Yes
No N
Proposal received Merit Seeks
from DHTE Chancellor’s office inputs from Approval for Posts
Proposal Clarifications Accorded
By Examines the status If any DHTE/
Hon’ble proposal University
Chancellor
No-(All clear)
Figure 1: Recruitment /Posting/Transfer of Staff and Faculty

(iii) Service Record (Promotion, Leave, Deputation, Retirement and Pension)

Objective: To maintain data of employees of an organization (DHTE/ University)
Process Flow:
(a) Records of employees such as Promotion, Leave, Deputation, and Retirement can
be updated in the system by concern division.
(b) On Transfer or Retirement user id of the employees shall be deactivated.
(c) In case of the Retirement, details of Pension can be updated by the concerned
division.
(d) Leave request can be initiated by an employee and can be approved by the
concerned authority
Promotions
Academic Staff Promotions
Logs
Logs into
into to
to portal
portal 1.
1. Fill
Fill application
application details
details
with
with Faculty
Faculty ID/
ID/ 2.
2. Verify
Verify credentials
credentials (Digilocker,
(Digilocker, PAN,
PAN, UID)
UID) Candidate
Submit
Submit Notified
3.
3. Upload
Upload photo,
photo, signature,
signature, LTI
LTI
Candidates
Promotion
Direct
Direct Applicants
Applicants –– 4.
4. upload
upload abstracts
abstracts (if
(if available)
available)
Application
Application list declared
to
to create
create ID
ID and
and 5.
5. Upload
Upload research
research works
works (to
(to some
some limits
limits by University
then
then submit
submit
Last
No
date?
Yes
Notification
Notification of
of Collation of all
Application Publishes in
(Administration)
vacancies Vacancy at
vacancies applications for received by
Approve
portal junior level (on)
University
scrutiny University Physical copy

account of
to University
Senate Promotion
Scrutiny
Constitution Shortlisting of applicants Syndicate
of Panel Considered for Assess
promotoins
University Finance
Scrutiny
Scrutiny of Candidate
Assessment/Panel
of Yes: Information
applications
applications face-to-Face Received by
University
Finance for
by
by Panel
Panel Pay-Fixation
Need 1. Merit List

Thorough
Candidate 2. Recommendation
Need any Yes: Seeks inputs face-to-face Scrutiny to University
Inputs?
No
Information sent
DHTE
to
DHTE
Figure 2: Promotion Process

Staff Leave Management

Academic/NonAcademic Staff
Logs
Logs to
to the
the Checks
Checks the
the System Staff submit
Staff
Staff
Staff Plans
Plans to
to
take
University
University staff
staff available
available forms
forms suggests types Leave
take leave
leave portal of
portal of leaves
leaves of leaves Application
Approval Alert
Sent to Suggestion by officer for change in leave
Employee System
U
Update
Designated Leave application System evaluates the
Designated
Grants
OK officer sent to designated eligibility and
Officer
Leave Evaluates officer availability of leaves
U
No- Alert
General Administration
Information to General
Administration
Update Employee
Any Update For Service Book Service Book
Record
If its leave having finance impact

University
Finance
Update
Information to Finance
Payroll
Administration
System
Figure 3: Leave Management Process
(iv) Payroll
Objective: To maintain salary data of employees of an organization (DHTE/ University)
Process Flow:
(a) Monthly pay details of every employee shall be prepared by the system in the basis
of details of existing employees such as Grade pay, Attendance/ Leave record etc.
(b) Managing & implementation of Pay-revisions, pay-fixations etc.

Payroll Management
Academic Staff
(Administration) Payroll
Payroll process
process General
Administration gets
University
starts
starts
alert & can view on
MIS
Staff
Staff Receives
Receives
Information
Information asas
Letter
Letter
Copy
Copy of
of Joining
Joining Bank
Bank eMail
eMail
PAN
PAN
Report Account
Account
Staff
Report Details
Details SMS
SMS
Details
Details
Other
Other SM
SM platforms
platforms
Included
Copy
Copy of
of Joining
Joining Finance
Finance Seeks
Seeks from
information Y Details of
Report
Report information Current
Payroll,
University
(Finance)
from
from Staff
Staff Month
Pay-fixation
Possible? Date of Joining
Etc
Included
Verify
Verify ifif can
can be
be included
included in
in Sent
N from next
payroll
payroll of of current
current month
month Month
onwards?
onwards?
DHTE
DHTE
DHTE DHTE gets
Takes
Takes details
details on
on record
record alert & can
view on MIS
Figure 4: Payroll Management Process
(v) Pension Management

Objective: An employee/faculty making an exit from the University ecosystem on
account of any reasons, if found to be eligible for pension, the pension process gets
initiated
Process Flow:
(a) When a faculty or non-faculty or other employee exits the system on account of
retirement or any other reason and if found to be eligible for pension, the pension
process gets initiated through the Pension cell.
(b) As a process, the complete record books of the employee are packed and sent to
Pension cell of the university. The employee’s financial proceeds are transferred to
the employees account. In context of a Common Digital platform, the digital
content with respect to the specific employee gets moved to the pension Database.
(c) The pension cell initiates the pensioners process and fixes the Pension
(d) On completion of service due to retirement or any other reason, the exit process
for the staff/faculty gets initiated by collation of employees soon to retire list,

followed by scrutiny by University Committee, approval from VC's Office (or) the
competent authority in case of non-faculty and communication to admin, finance,\
(e) The pensioner interacts with the PENSION CELL (in case of University staff).
Employee Exit Management/Movement to Pension
Employees moves out of the system
Employee
Employee eligible
eligible Orders from University
Exit
Exit plan
plan starts
starts
Staff
to
to exit
exit Process Admin to employee
Process End
End
E
University receives and collates information Approval

Approval from
from
University collages
(Administration)
University
University
list of faculty retiring Voluntary Vigilance Premature Unnatural Superann authorities
authorities
University
6 months ahead Retirement Case Termination Death of uation (designated

(designated
of service employee by
by VC)
VC)
(end of academic
session)
Approved
Prepares
Prepares detailed
detailed Report
Authority/VC)
(Committee/
Scrutiny
Scrutiny of
of on list of
University
assessment
assessment report
report in
in
details
details exits
cases
cases other
other than
than Category
received
received retirements
retirements wise
Seeks clarification as required
Detailed list received by DHTE

Absconders / offenders list
Departments
DHTE
DHTE List
List of
of Vacancy
Vacancy
Other
Takes
Takes details
details on
on record
record absconders
absconders created
created out
out
to
to Police
Police &
& of
of retirement
retirement Information
Media
Media Pension Cell For pension fixation
PENSION CELL Pay

PENSION CELL
Assessment of
Creates/appends to
the case of the Is the case Fixation / Pensioners
the Yes
designated clean? Pension ’ Databsae
Pensioners’ register
pensioner Fixation
(on the system)
File returned back to
E
Administration /Establishment
Figure 5 Pensions
4.1.2 Office Management

(i) Online File Processing
Objective: To online process any request within an organization (DHTE/ University/
College) or for processing any approval/ query between two organizations
Process Flow:
(a) An official user can access the ‘Initiate Request’ in his login and select the type of
the request from the dropdown menu and choose the name of the Department/
Officer to whom it is to be addressed. Upload required document, fills details of
the request, and forwarded it to the concerned official in his own division for
concurrence, if required.
(b) The concerned official can send it back to initial user/ any other user.

(c) Receiving user sees in its login and add his remarks, upload documents forward for
approval/ concurrence, if required.
(d) System should have the provision to create a table under remark column. Data from
outside can also be copied as text, word table or excel.
(e) Name of the document uploaded, shall be typed by the user uploading it, for
identification by the other users.
Online File Processing
Universities want to interact with DHTE for any requirement
University
University user
user
Requests
Requests raised
raised by
by
Universities
Universities request
request through
through universities
universities are
are forward
forward toto
want
want to
to raise
raise aa the
the portal.
portal. the
the concerned
concerned division
division of
of
Universities
request
request for
for Requests
Requests isis DHTE,
DHTE, choosen
choosen byby University
University
query/
query/ processed
processed
feedback/
feedback/
user
user
internally
internally before
before
approval
approval forwarded
forwarded to to DHTE
DHTE
No Action needed
Sent back to University
DHTE
Personnel (GOJ)
Department
Department collates
collates
Department of
processes
all
all demands/
demands/ DHTE
DHTE assesses
assesses the
the the details
Requirement
Requirement requirement
requirement Takes
Takes action?
action? from GoJ
Request
Request from
from
different
different universities
universities Action taken
Sent to Govt
(if required)
Government of
Jharkhand /
Action
DHET
Action
initiated
initiated
Figure 6: Online File Processing
(ii) Inventory Management

Objective: To simply the process of inventory
Process Flow:
(a) A Division needs certain items from the stock.
(b) Create online request for items.
(c) Stores process the requests and release item, if stock is available.
(d) The stock register is updated.
(e) If the quantity of an item falls below to the certain number, concern users in Stock
Division are alerted through email.
(f) Stock Division users wants to create a request to order items from the outside, User
creates an order through ‘Create Order’.

(g) Stock Division user can add/ remove the name of the item in/ from the master data
has the available quantities of the items selected by the Stock Division user. It also
has a column to mention the quantity for order.
(h) Stock Division user can update the quantity of the items received from outside
vendors and also the quantity received back from Division user.
(i) Division user can periodically update the quantity of the items received from the
store. It shall be mandatory for them to update this information before the next
request.
BUDGET & PLANNING
BUDGET DIVISON AUTOMATION
Division/Section 1 Division/Section 2 Stores Central System Stores Division
User Login
START START START Requirement
based on
collection
Credentials
Collate Collate Collate Data entry

requirement of requirement of requirement of on the item
stock/items stock/items stock/items Evaluation of
Request requirement
form
Assess & Assess & Assess & System

No No No
Tabulate Tabulate Tabulate validates
allocation Approved?
Get Internal Get Internal Get Internal

Approval for Approval for Approval for Validated?
submission submission submission
to Budget to Budget to Budget
YES
No
Submit
Approval Approval Approval Rejection of

request
Release of stock
Yes Yes DB Update on
Stocks
item (as per
eligibility)
YES
Rejection/ Issuance
PROCESS ENDS Slipl / Report
Sections/Division can DOWNLOAD Stock Status report
Figure 7: Inventory Management
(iii) Dak Management

Objective: To record the movement of DAK received by DAK Cell
Process Flow:
(a) Dak Cell user logs to the system and create a new entry
(b) System generates a DAK-Number against this entry. DAK Cell official
and filling the details about the Dak received like addressee, sender, date and time
of receiving and submit. System generates printable slip and contains the DAK
No and a few other key details like Sr. No of DAK register. The slip can be printed
and pasted on the DAK

(c) Alternatively, Marks the dak to the concerned office/officer/ division & makes an
entry in the system
(d) The Dak Number will be the tracing number for file movements in the File
management system, address, if from with the organization, shall be required to
update the receiving of the Dak on receiving it.
Chooses DAK
New Dak received at Dak Cell user Logs Starts Entry to DAK
Management
Dak Cell In to the Syste Module
Module
Dak Marked
to the Inward User stamps/ System allocates/
concerned writes the dak DAK-Number.
END Inward/ User update the
number on the
outward details of the Dak
Marked for letter received/
Dispatch Outward sent being processed.
process
Figure 8: DAK Management Process
(iv) Grievance Resolution

Objective: To address the grievances being received by DHTE from
various stakeholders, including their own employees
Process Flow:
(a) Students/ employee, or the family of employee’s staff shall submit a grievance by
choosing a category adding description and uploading supporting documents.
(b) A Public user has also need to select the name of the office to whom grievance is
addressed.
(c) Grievance is received in the login of the nodal officer in the Grievance Cell/
Helpdesk.
(d) Grievance Cell/ Helpdesk user can forward it to another user in any of the
department available under the list.
(e) Concerned users can update their remarks/ upload
(f) User holding grievance can forward to any other departments update status.
(g) In case a grievance is received by DHTE as physical letters/ email/ Phone Call, the
same can be registered by DHTE officials.
(h) A grievance can be update by any internal user, irrespective of any other person
holding it.

GRIEVANCES to DHTE & Redressal
Segregated
Grievance grievance based Grievance status &
received by on the subject/ action taken details
Start DHTE through content and
sent to aggreived
Source forward to
Portal
concerned
Grievance Grievance filled to section
received by the portal in End
DHTE as a prescribed format
physical Letter by Operator
Section/Division
Takes corrective action Division/Section
Grievance Assessment
Information
& update response or Assess the updated in
forward to any other grievance system
user id
Action taken
Figure 9: Grievance Resolution
(v) Right to Information (RTI)

Objective: To handle the RTI applications/ response and tracking
Process Flow:
(a) Applicants submit RTI query online on Common Digital System of DHTE and
deposits fee online
(b) All RTI queries are seek initially by RTI Cell and then routed to the DHTE concerned
officer/ CIO by RTI Cell
(c) Concerned officer updates the response
(d) Officers can see pending RTIs in their login
(e) RTI response once submitted by concerned officer can be seen online by applicant
and an email/ alert also goes to applicant
(f) RTI officer can also forward the RTI request to any other officer in
the organization to any other officer who is on Common Digital System of DHTE
but is from outside organization
(g) On receiving a RTI request through DAK section, the concerned RTI officer shall
register the request on the Common Digital System of DHTE, with details and fee
paid of applicant
(h) RTI response, can also be printed and send to the applicant through DAK
(i) RTI fees collected through postal order, shall be forwarded to the department
concerned for deposit in Treasury

Right to Information
Handling RTI applications

Applicant DHTE CIO
Routing the RTI to correct

Physical RTI Officer
Application Data
Data Entry
Entry
Postal Order
to
to
Central
Central System
System
$
CIO
Response Generation
Application Payment
submitted Gateway
online
Payment
APPS Central
Central System
System
like
BHIM
Figure 10: Right To Information
(vi) Finance (Budget and Accounts)

Objective: To enable Budget division to handle their requirements and budget demand
in a systemized manner
Process Flow:
(a) Division submits its budget requirements.
(b) Request submit approved from division head/ section head and forward to Budget
Division.
(c) Budget Division processes it. Recommend for approval, rejection or amendments.
(d) Competent authority in DHTE/ Budget department approve it.
BUDGET REQUESTS – PROCESSING AND APPROVAL
BUDGET DIVISON AUTOMATION
GoJ
Division/Section BUDGET DIVISION
FMS
START
Entry to FMS
Submits Assessment of
requirement
Budget
Requirement
Approval No
No Division/
Section and Yes
submission Approved?
to Budge
Approved
Division
Headt
NO
Approval
YES
Updates
approved
figures

Figure 11: Finance (Budge and Accounts)
(vii) Tracking of Court Cases

Objective: To allow the DHTE/ university officials to track the status of court cases.
Process Flow:
(a) Details of court cases can be maintained in the system. Relevant documents can
also be uploaded by the concern division.
(b) DAK movement of files related to court cases can be tracked through the DAK
module of the system.
(c) Department-wise reports on the Court case status can be generated from the
system.
Figure 12: Tracking of Court Cases
(viii) Online fee Payment

Objective: To facilitate the online payment for faster processing of various applications.
Process Flow:
(a) DHTE system shall be integrated with the payment gateway to accepting payment
form various users such as students, new universities applying for approval etc.
Student logs into the Course
START Central Portal using Course/ subjects finalized confirmation to
credentials and TFA Student
Fee paid by
Generate Payment
Student at Offline
Challan Option
Bank
Acknowledgement
Receipt received by
END
Student (email, PDF,
Inputs
SMS) Online
payment
details in
Admission
No Portal
University
Tuition Fee credited to Proceed to Fee
Finance Scroll Payment Success
University Account Payment Gateway
Yes
Figure 13: Online Fee Payment

Exam Fee
Student System Payment Gateway
Student gets alert System

Payment
on payment of shows the
Initiated by
exam fee student
Student
credential
Student Logs List of papers Payment

into the for which Mode
portal student has to
pay
Online
System Student Student

shows the chooses all submits challan
student papers or some Confirmation
credential Online details on
papers
Payment Exam Portal
System
calculates exam
fee + late fee if
any Payment
confirmation /
Receipts of
exam fee to System
student Update
Completion of
process
Pays Challan
Challan
amount to Bank
Takes
Acknowledgement
Student prints
Challan
Goes to Bank
Fee for Eams
Figure 14: Examination Fee
(ix) Scholarship Management

Objective: To enable monitoring and managing scholarships being given to students.

Students availing various forms of scholarships shall get registered to the scholarship
module. University shall assess, manage and moderate the portal.
Process: It is aimed to interact with the various portals that offer scholarships to students
under various schemes. While it may be challenging to directly integrate the proposed
platform with the scholarship portals, it is envisaged that the portal shall have varied
forms of interactions with external portals/stakeholders through APIs to monitor the
scholarships being availed. At the same time, the scholarships being issued by the
universities shall be part of the proposed system.

Student’s application for Scholarships

Students Final Mark update
Student
Student
Student
Identifies Internal
A Or
Scholarship National or
others
scheme
Info to
Applicant (student)
University
Speciifc
National Scholarship Portal
Registers UIDAI/ As defined by Universities from

AADHAR (as time to time
mandate
Scholarship Process
Criteria
Validation by
NATIONAL SCHOLARSHP PORTAL
University
Policy
Rejected
Validation Granted/
Process Rejected
National
National
Scholarship
Scholarship Granted
System
System
Common Digital
Platform
Digilocker
Digilocker
Common
Common Digital
Digital Platform
Platform
Different universities have different scholarship plans apart from the National
Scholarship schemes
a. The University/college updates their students for availability of
scholarships in various schemes (or) Students approaches the University
and the National Scholarship portal to avail such scholarships

b. For Adult students (18+) Government of India has mandated to update

their UIDAI( AADHAR) number as the registration key
c. As of now (January 2024), the applications are received and scrutiny is
conducted independently.
d. The University portal shall conduct the basic scrutiny of the credentials
(from its Common digital platform and enable the students to know their
position on their application for scholarship(s)
e. Whence any such applicant gets approved for any scholarship at the
University level (or from the National Scholarship portal’s process), the
same is updated to the Common digital platform (CDP)
f. As on date, the National Scholarship Portal does not inform the universities
of any such approvals via their own portal. In the proposed CDB, it is
envisaged that the CDP and the National scholarship portal shall
handshake through any feasible means to contain the latest update of any
grant/rejection of scholarship to any applicant
4.2 Modules specific to DHTE

(i) Approval for New University
Objective: To enable an interested entity to apply for establishment a new university
Processes Flow:
(a) Applicant applies in the Common Digital System of DHTE in prescribed format.
(b) Interested entity to be submitted requisite necessary document as DPR and fees.
(c) Scrutiny by DHTE.
(d) Approval/ Rejected by Chancellor Office.
(e) Track application status

Approval for New University
University Formulation PROPOSAL DHTE ASSESSMENT CHANCELLOR
Receives
Receives Review
Review byby
Intended
Intended party
party
starts
starts process
process
Application
Application ASSESSMENT
ASSESSMENT office
office of
of
OF
OF Proposal
Proposal Chancellor
Chancellor
Scrutiny
Scrutiny of
of
Application
Application && No
DPR
DPR
Accepted?
Accepted? Accepted?
Accepted?
Any
Any Yes
Applies
through Portal
Shortcomings?
Shortcomings? No Yes
with relevant APPROVAL
APPROVAL
Data for
Uploads the
for University
University
Returned to requisite Listing
Listing of
of
documents
Applicant short
short Forward
Forward
comings
comings Recommend
Not
Recommend Accepted
Queries ations
ations to
to
Queries & &
Clarifications Chancellor
Chancellor
Clarifications
from
from
Applicant
Applicant
Download
Download
Letter NOTIFIES
NOTIFIES on
on portal
Letter of
of portal
&
& Sends
Sends SMS/Email
SMS/Email
Confirmation
Confirmation to Applicant
to Applicant
(or)
(or) Rejection
Rejection
END
END REJECTED
REJECTED
Figure 15: Approval of New University
(ii) User Registration/ Creation

Objective: To facilitate the Registration/ Creation of a new user of DHTE/ University in
the system
Process Flow:
(a) User register with the Common Digital System of DHTE as employee.
(b) Fills credentials (Name, Unique Identification no./AADHAR, DoB, Mobile No.,
Address, email id and Name of Organization)
(c) System receives the user online application, and create a Reference no.
(d) User would be categorized by supervisor as: General User or Administrator
(e) System transmits data to supervisor for approval/ concurrence
(f) Supervisor approves/ rejects and mention the validity
(g) Username/ password created and emailed to registered mail id.
(h) Alternatively, a user can be created/updated by the System Admin of the respective
organization.

First time user logs Fills his/her details Application submitted

Start into the Common for creating of user successfully and reference
Portal id no. is generated & sent on
user email id.
NO
Password USER NAME / Approval from Supervisor at

Y APPROVED Policy PASSWORD DHTE
invoked Created
Figure 16: User Registration/ Creation
(iii) University Interaction Cell

Objective: Periodic interactions with Universities for all Administrative purposes are
being held in person or through video conferencing (GOOLE MEET).
g. All communications are sent either by email or by letter or both email & letter
h. There is no defined workflow-based interactions between Universities and
Government
i. Interactions between universities for any reason is also managed manually
Process Flow
1. University intends to raise some request to DHTE, and wishes to interact with the
DHTE (specific division) (or) DHTE wishes to interact with any or multiple
universities
2. Request initiated either by University or universities or DHTE
3. Plans for a one-to-one or group interaction with the University or
university/universities plan for an interaction with DHTE
4. Interaction cell/division manages the coordination with university/universities for
any such discussion(s)
5. All such discussions/interactions are logged through the system
6. Proceedings of such meetings, decisions and outcomes are available in the central
system for DHTE to track
7. DHTE shall track all details of all universities.
8. Universities shall track all details specific to that university and details with respect
to those stakeholders involved.

Logs
Logs into
into the
the
Universities
Universities Raise
Raise central
central system
system to
to
Request
Request ForFor raise
raise such
such request
request
meeting
meeting // on the defined
on the defined
interaction
Universities
interaction module
module
Universities
Universities desire
desire Requests
Requests raised
raised by
by
to
to know
know any
any detail
detail universities
universities or
or universities
universities get
get
posted
posted to
to the
the DHTE
DHTE through
through
Rejection notice system
system
sent by DHTE
Proceedings/
Proceedings/ Decisions
Decisions
Published
Published through
through
No Request/
Central
Central System
System
Considered? Requests
received
Yes
DHTE
DHTE intends
intends to
to
DHTE schedules the
DHTE
invite
invite one
one or
or many
many DHTE
DHTE posts
posts an
an Process
meeting concludes
universities
universities for
for any
any Online or on-site or
circular/notice
circular/notice
discussion/
discussion/ workshop
interaction Discussion Online/offline
interaction
Figure 17 University Interaction Cell
4.3 Modules specific to universities

(i) Office of the Registrar
Registrar of the University is the administrative head of the University. As the
Head of the Overall Administration of the University, responsibilities of the
Registrar are listed below ;
1. Hire, supervise and evaluate the Records and Registration staff
2. Organize and administer the academic functions, to provide maximum
service to students while ensuring efficient and effective workflow.
3. Participate and serve as part of the Student Services Team. Lead initiatives
as determined by the University
4. Supervise the coordination, evaluation and certification of all graduation
applications, while overseeing the complete graduation process to include
all elements of the rehearsal and ceremony
5. Responsible for collecting, recording, maintaining and reporting of student
records within UGC guidelines, e.g., grades, registration data, transcripts,
mid-term
6. verification, athletic eligibility and other associated audits 6. Provide
leadership and develop appropriate recommendations for the
7. implementation of related technology application in support of enhanced
services offered through Registration and Records
8. Develop and administer the departmental budget

9. Research, analysis and resolution of student disputes as they relate to

records and registration
10. Collaborate with administrators, deans, faculty, IT and counsellors to
facilitate and improve services to students, including catalogue and
registration/records policy
11. questions
12. Coordinate, control and regulate all activities of administration, human
resources, Finance & Accounts and other related matters for efficient
functioning of the
13. University
14. Execute and administer the outsourcing contracts for various services of the
University
15. Serve as ex-officio member of Academic and Administrative Committees as
per the Act
Being the Administrative Head of the Institution, Automation of Administrative
functions for the University will be overseen, supervised by the Registrar /
Registrars. The Functions under the registrar are explained in subsequent chapters.
(ii) Student Life Cycle (Registration and Admission)
Objective: To make smooth admission process
The applicant will be registered in Common Digital System of DHTE as a student. The
applicant will fill in the mandatory details mentioned in the registration form and upload
the necessary documents. After successful registration with Common Digital System of
DHTE, applicant will get login id and password in on registered email id and mobile no.
Process flow:
(a) Applicants who are willing to apply for admission in a course offered by Ranchi
University, shall visit the Common Digital System of DHTE and fill the registration
form.
(b) After submitting the registration form, a temporary application reference number
shall be generated by the system. The details of the form submitted, and temporary
application reference number can be used for tracking the application status.
Fills his/her credentials-

First time user logs into the Receives authentication OTP
Start mandatory details and uploads
Central Portal via email/mobile (TFA)
necessary documents
NO Password Policy USERNAME /

APPROVED Approval from Supervisor
invoked PASSWORD Created
END YES
Figure 18: Student Registration

(c) Applicant is required to pay the fee online or through the challan. Once the online
application fees is paid, the Registration Number shall be generated by the system.
The fees paid through the challan shall be marked as paid by Ranchi university.
(d) Master data for the name of courses available, number of seats - category wise,
Tuition fees and the eligibility criteria has to be created by Ranchi university, prior
to the beginning of the admission process.
(e) A candidate can select more than one course based on his/ her eligibility
Student logs into the Central

Selects courses/ subjects of
Start Portal using credentials and Selects secondary subject
choice
TFA
NO
Proceed to Fee Approval from Apply for the selected

END YES APPROVED
Payment Process Supervisor courses/ subjects
Figure 19: Selection of Course
(f) The data related to the temporary application reference number shall be deleted
from the system after the admission list is released or if fees is not paid by the
applicant, within a certain time period.
Student logs into the Course
START Central Portal using Course/ subjects finalized confirmation to
credentials and TFA Student
Fee paid by
Generate Payment
Student at Offline
Challan Option
Bank
Acknowledgement
Receipt received by
END
Student (email, PDF,
Inputs
SMS) Online
payment
details in
Admission
No Portal
University
Tuition Fee credited to Proceed to Fee
Finance Scroll Payment Success
University Account Payment Gateway
Yes
Figure 20: Submission of Fee
(g) Admission list shall be generated by the system based on the criteria prescribed by
the University

System auto-generates list of

Review of list by concerned Automated generation of
Start Registered Students and their
Department/ College Provisional Merit List
choice of courses
Student log in
to track
application
status
Publication of
Approval and Provisional Merit List
Merit List
End release of Final approved by the University/
Merit List College
Figure 21: Generation of Merit List
(h) List of the students who have paid the tuition fees, shall be published on the
Common Digital System of DHTE and a enrollment no. shall be generated for such
students.
Verification Failure
Student logs into the Students course, college,

Start Central Portal using fee payment details
credentials and TFA verified for onboarding
Digilocker/
Student Academic
other
credential verfication
verification
END
Success
Digilocker
Update confirmation to Unique Registration

Student logs in their
Student via email, SMS, Student Profile created Number auto-allocated
email, phone number
others by the system
Figure 22: Generation of enrolment number
(iii) Affiliation of colleges

Objective: Affiliation of College to University
Process Flow:
(a) College seeking affiliation shall access a form on Common Digital System of DHTE
and fills it and online pays the requisite fee paid online.
(b) User shall select the name of the university from dropdown with whom it wants to
get affiliated with university
(c) The application form shall appear in the list of nodal officers of the universities
selected by the applicant.
(d) If required, the nodal officer can reassign the application to the nodal officer of
another university. (In case the applicant does not belong to the jurisdiction of this
university).

(e) Nodal officer update his remark/ upload documents/ or notifies the applicant, if
any additional details/ documents are required from him.
(f) Nodal officer can forward the application to any other officer in its organization.
(g) User holding the application, updates the date for inspection (if decided).
(h) All existing colleges will need to create their profile on Common Digital System of
DHTE for facilitation of their reapplication for temporary affiliation. Profile details
shall include – Name of college, courses offered, course-wise intake, numbers of
Lecturers/ Readers/ Assistant Professors/ Professors, No. of classrooms, seating
capacity of each room, No. of labs (faculty wise), existing number of students in
each coerces, name of the members in managing committee, affiliation number,
affiliation validity and latest inspection date.
Affiliation of College
No
End
College (Applicant)
College fills Temporary

(prescribed format) of affiliation 1. Portal updated
application for Yes expring? 2. College
affiliation and uploads Alerts sent and
receives approval
DPR & other relevant clarification
letter
supporting documents sought from
College
Nodal officer update his

remark/ upload
User holding
Nodal document/ or notifies Approval of
the
Officer the application are Inspection report is Temporary
application,
University
verifies required from him. uploaded affiliation of

upload the Yes-Seek Clarification
details of Nodal officer can College
data for
application forward the apllication communicated
inspection (if
received to any other officer in its to portal
decided)
organisation
Observes
NO
any lacuna
University Senate
Report from Senate

Syndicate
Inspection Syndicate
Clarification if any?
committee is approval
examined
Recommendations accepted
DHTE can see the application submitted by

DHTE
each applicant and the action being taken/

Update sent by University
recorded
UGC/AICTE
Information received by UGC/AICTE/

Other bodies
Update sent by University to UGC/ AICTE/ Other nodal bodies
Figure 23: Affiliation of Colleges
(iv) Hostel Management (Admission/ NOC)

Objective: Under the Hostel management allocation of the hostel room to student, no.
of vacant rooms, exist of students from hostel room, and penalty impose to the students
will be recorded online
Process Flow
(a) Initially, Hostel management of each of the hostel shall be required to create the
Hostel profile by providing following details - Name of the Hostel, Address, No. of
Rooms, Name of the room wise occupants, Room wise occupancy type – single/
double/ triple bedded. These details can be updated by the hostel management at
any time of the year.
(b) New students can apply for hostel through the Common Digital System of DHTE
using their enrollment no. and user id.
(c) Details of students who were allotted the hostel shall be published.
(d) Any student vacating the hostel room shall initiate an online request for NOC.
Hostel Allotment, Management
Hostel
Process Ends
Can Apply for
Hostel Student Receives
Student
Student
Accommodation Application Accepts/ Confirmation
After tuition fees is process No Chooses Moves into
paid terminates Location Hostel
Yes
NO Accommodation
Results Search for Shows Hostel wise

System
Is
Availability of Accommodation
Yes Choices of room
Accommodation Available nos.
Administration
Hostel
Admin Approves
Student asked to System Gets
Payment Update Accommodation
pay fee
Payment Gateway
Pays Fee Online If not approved within

Pay fee 21 days room is released
Online/or
opts for Visits Bank Logs in to Fills in Challan paid Details in
Portal and submit the challan
Challan Pays Fee Hostel to Admin, Room selected by
Gets Challan management student is blocked for him
Figure 24: Hostel Management
(v) Research work Management:

Objective: To maintain the record of the research done by the university of Jharkhand
Process Flow:

(a) Research related documents and publications can be uploaded by the faculty/
researcher on the Common Digital system of DHTE.
(b) Registered users can access the research work uploaded by the faculty/ researcher.
Research Publication
Publication
Author/Researcher
End Receives information
Researcher
Researcher
From University
Or Academic
initiates
initiates research
research
Researcher
work
work Rejected Accepted
Creates
Creates ABSTRACT
ABSTRACT Researcher Receives
of acknowledgement
of the
the article/work
article/work
Updated
Link published
Full Research work /

Department
Department Full article
article ready
ready Status Updated in
Guide’s
Guide’s fore
fore Article sent to
receives
receives for
for sending
sending to
to Journal/forum
ward?
ward? University Portal
Abstract
Abstract journal
journal // forurm
forurm
University
Yes
Library
Library Guide
Guide gives
gives External
Research Database
Receives
Receives inputs
inputs // of University
Abstract
Abstract recommendations
recommendations
Other Common
Copy of
schemes
View permission for assessment

abstract moved
PDS
Mandatory submission to PDS/GOI

to PDS
Framework & Policy
NAAC View permission for assessment

Bodies
NIRF View permission for assessment
UGC View permission for assessment Others

Function
Journals
Forums Accept/
External Accepted
Totally External entities that Reject
receive Research works
Rejected
Rejected Accepted
Figure 25: Research Work Management
(vi) Classroom Management (Scheduling of Classes)

Objective: To create and maintain the scheduling of the classes
Process Flow:
(a) Timetable of the classes for entire semester/ year can be created by the respective
faculty/ department
(b) The classes scheduled in the timetable shall be available for making the attendance.
(c) The timetable once created for a particular course can also be used as a template
for any other course or in future for same course. The name of the teacher can be
assigned to a subject or to a class scheduled on a particular day, by the
faculty/department.
(d) The classes can be rescheduled/ cancelled by the faculty/ department.

(e) Students in their login can see the classes scheduled for their course and updates
made regarding change in faculty name/ rescheduling or cancellation of the class.
(vii) Attendance Management
Objective: To enable attendance of students' process
Process Flow:
(a) Respective teacher subject wise shall update the attendance of the student.
(b) Students can see the details of their attendance in their login
(c) Teachers/ Administration can see the attendance of the student's course-wise/
subject-wise/ class-wise
(d) Date of making of the attendance shall also be captured in the system
Central
Central System
System // DHTE
DHTE System
System (DC)
(DC)
University/College
University/College Server
Server
Class Observation system
University
University /College
/College Network
Network
Class Attendance Marker
Learning
management
System
Biometric
Biometric
Student
Student
After
After Biometric
Biometric at
at Reaches
Reaches Study
Study point
point
Entry,
Entry, student
student moves
moves toto class
class
Netram
Netram
Professor
Professor
Figure 26: Attendance Management
(viii) Proctoring Solutions

Objective: The objective of the Proctoring Solutions is envisaged at conducting

examination in online mode and to observe the student behavior during the conduct of
examinations thereby arriving at a seamless and effective examination process with
optimal integrity.
The aim of this exercise is to enable conduct of ONLINE PROCTORED EXAMS for students
Process Flow:
(a) Students enroll / register to taking part in online proctored exams (if being
conducted by the university) (Provided the University declares any proctoring
examination)
(b) Registered students logs-in to the online proctored exam module
(c) System takes consent of acceptance to the rules with “I Agree” button on the screen
(d) System enables the Question paper as per the time and slot defined for the student
for the designated subject
(e) System checks for the ability of the host system to take part in online exam with
checks on the camera, light etc
(f) Camera monitors the candidate for his behaviour during the conduct of exam
(g) Any deviation in behaviour gets captured by the host-camera and submits to the
central system. Such unacceptable behaviour (not conforming to the defined SOPs)
get tagged
(h) System pushes the final answer only of those answer books/sets where the students
comply to the defined rules for exams
(i) The proctoring module gives the desired reports, status , alerts to the central
monitoring module
Jharkhand
Jharkhand
DHTE
DHTE
System
System
Exam
Exam System
System
Proctored
Proctored monitoring
monitoring
Internet
Proctoring
Proctoring System
System
Proctored response

Decision on
Warning or
Exam
Stoppage
Question
Question Bank
Bank
(Examination
(Examination System)
System)
Triggers Alert
Connected via & Controls
Internet or examination
Local LAN/WAN process
Central
Central Proctoring
Proctoring System
System
Proctoring
Monitoring
System
Any deviations
Netram
Netram
Deviations in
Candidate
Behavior or
other findings
Student opts for online proctored

examination
(ix) Examination Management

Objective: To facilitate the setting up the examination paper and activities related to the
exam paper
Process Flow:
(a) University user can use the function ‘New Task’ for initiating the process for
approval of the committee to finalize the question paper.
(b) Each teacher in his login shall have the option to ‘Add Question’ for creating a
question bank for the subject he/ she is teaching.
(c) At the time of adding the question, the teacher shall specify choice for option (an
answers) identify the option as correct answer(s), specify the Topic Name, difficulty
level, Question Type (Subjective, Multi Choice Question, fill in the Blanks), marks
and specify the name of classes (by selecting one or more classes) he/she is
teaching.
(d) Examination Department/ Head of Department can create the question paper by
adopting any of following logic, after deciding the number of questions –
1. Percentage (%) of questions to be selected from each topic
2. Percentage (%) of questions to be selecting from each teacher
3. Percentage (%) of questions to be selected for each difficulty level

4. Percentage (%) of questions to be selected for each mark denomination

(e) The Head of Department shall also specify the mode of exam offline/ online.
(f) In case of online exam mode is selected, the exam paper shall appear in the login
of the student at the designated date and time, when the exam for that subject is
scheduled as per the exam timetable.

Question creation for Universities
Preparation of Questions/ Committee setup by University

Repository
University Academecians Colleges
Bank
Start
Receives
University invites Invitation
academicians,
Receives
Departments,
Invitation
Colleges to become Accepts Secure
Secure
NO
part of committee Invitation Question
Question Bank
Bank
Accepts No action Repository
Repository
NO
Invitation End
University
receives Yes
Yes
responses
from all
Notification
received from
Identification of University
Notification
members of the
received from
committee for Individual
University
each subject members start
preparing their
University gives access Individual Questions
rights for submission to members start (specific to their
members preparing their domain)
Questions
(specific to their
Finalization of domain)
Committee
constituents
Question
bank
Committee
constituted
Committee
Committee
Permits
Permits question
question
Extraction
Extraction
University
University Colleges
Colleges
Extracts/chooses
Extracts/chooses Extracts/chooses
Extracts/chooses
Question
Question from
from Bank
Bank Question
Question from
from Bank
Bank
Figure 27: Examination Management

(g) In case the offline exam mode is selected by the Head of Department, the question
paper shall be available for the printing in the login of the exam department (or
any other concerned department) at the date and time specified by the Head of
Department at the time of specify offline mode. The question paper shall be in
printable format. The question paper shall also have the system generated code
and other details such as duration, max. Marks, name of the subject, name of the
university.
(h) In case of online exam, department can decide to conduct exam on intranet or
internet
Printing/Publishing of Question Paper
Conduct of Examination phase

University System
Question
Question bank
bank
Question
Question bank
bank Committee Committee coordinator
approves Committee
Committee approves coordinator
Allows
Server
Server Extraction
Allows
Extraction Question/
Question/
Paper
Paper
extraction
extraction
Authorized QP
Authorised
Authorised
Creator
QP
QP creator
creator
Logs
Logs In
In
Chooses
Questions
Or
Question Paper
For
For Online
Online candidates
candidates
For
For
Students
Onsite/
Onsite/
offline
offline
Candidates
Candidates
Computer
Based
Examination
Students taking examination on paper
Figure 28: Examination Online/ Offline Mode
(x) Examination Timetable

Objective – Preparation of examination timetable
Process flow-
(a) University Informs Departments
(b) University informs affiliated colleges
(c) Colleges & Departments offer inputs
(d) University finalizes the timetable
(e) University releases draft Timetable to colleges/departments
(f) Publication of Timetable

The timetable of examination, will be visible to student as per course/ subject and same
will be communicated with student via email and mobile no.
EXAMINATION TIME TABLE
Timetable
University issues
notification to Release of Draft
departments & Affiliated Collating inputs Time table for Release of
UNIVERSITY
colleges for enabling from sources Concurrence TIME TABLE

Examinations
Inputs from
Department
Faculty & Discussions Publication

Department Clarifications of Time table
Head (if any) Interactions at University
Finalization of Dates
Etc
From
Inputs from Faculty & Department & Publication
Colleges
Department Head (if any) Affiliated Colleges of Time table

of respective affiliated at College
colleges (if any)
Publication
to Public
domains
End of
process
Figure 29: Examination Timetable
(xi) Evaluation of Answer Scripts –

Object: The online evaluation system enables evaluators to mark a scanned script or
online response on the computer screen itself, rather than on paper.
Process Flow –
(a) Exams get concluded each day
(b) Once exams are complete, the answer sheets are collected by invigilator and
submitted to the respective office
(c) The bundled answer books are sent for central scanning
(d) Allocate bar coded numbers to each answer Book
(e) Scanning of answer books at a defined quality
(f) Scanned document sent to central system
(g) Evaluator’s login to evaluate scanned answer books

Evaluation of Examination – Secure process

Evaluation
Examination Answer Book Fetching Sheets Evaluation
Start of
Answer University
Examination books get identifies
secure EVALUATORS
numbers (subject wise)
Question
Papers Printed
and distributed Allocation of
to students Evaluators Marks based
(SECURELY) on
Login to
performance
System
Sheets
Sheets get
get SCANNED
SCANNED Secure Connectivity
And
And loaded
loaded to
to Central
Central Server
Server
Marks given to
System paper gets
allocates recorded in server
Exams Online/offline
Answer sheets
of students
RANDOMIZED Marks get
consolidated for
Each Exam Secure
Secure Server
Server each answer
get For
For Scanned
Scanned && book and data
Evaluator gets fed to Data
concluded tagged
tagged answer book Base in Server
documents
documents (randomized)
Answer Marks scored by
Controlled Access & display
sheets students are
collected available for secure
From Logging in extraction by
to Closing each University from
Safe
Safe Lockers
Lockers file, every central Server
transaction is
tracked
Sealed
&
Docked Evaluator
Logs out
Figure 30: Evaluation of Examination Papers
(xii) Certificate Management (Marksheet, Degree, Diploma etc.):

Objective: To facilitate the creation and issuance of the certificates such as Marksheet,
Degree etc.
Process Flow
(a) The Marksheet, Degree and any other certificate can be generated by the
concerned user based on the details available in the system such as marks, result
status etc.
(b) The certificate issued from Common Digital System of DHTE can be verified suing
the enrollment no. and other specific details of the student.

Tabulation
Data entry of Marks Tabulation of Marks Publication of Results
Marks given Publication

Publication of
of
by evaluator Result
Result
(Secure
(Secure format)
format)
Secure
Secure Server
Server
For
For Scanned
Scanned &&
tagged
tagged
documents
documents
Score
Score /Marks
/Marks of
of each
each
student
student extracted
extracted Student
Student checks
checks
securely
securely by
by Tabulation
Tabulation Result
Result via
via login
login
System
System credentials
credentials
Tabulated
Tabulated marks
marks Student
Student
printed
printed on
on designated
designated satisfied
satisfied with
with
mark-sheet marks?
marks?
mark-sheet format
format No
Mark
Mark sheet
sheet printed
printed
Facsimile/ Signature
Facsimile/ Signature by
by Student
Student
designated
designated authorities
authorities moves
moves to
to
YES
challenge
challenge the
the
evaluation
evaluation
Proceeds
Proceeds to
to
Process
Process Ends
Ends receive
receive Mark
Mark
sheet
sheet
Hard
Hard copies
copies of
of mark
mark sheet
sheet
Bundled/packed
Bundled/packed
Sent
Sent to
to university
university ,,
respective
respective colleges
colleges
Figure 31: Certificate Management
(xiii) Challenge in Marksheets

Objective - On verifying the result, a student may not be satisfied on the mark scored,
vis a vis his expectations. Students are given a chance to appeal for re-verification of
their marks towards totalling (or) for re-evaluating their answer-books
Process Flow-
(a) Student logs-in to the result portal with secure login-credentials (as defined by the
University)

(b) Student is not satisfied with the score and has doubts either on totalling or on the
evaluation
(c) Student initiates the verification /challenge process
(d) University accepts the appeal application and verify
(e) Student satisfied with response by university (or) not satisfied, wishes to get
scanned copy. On payment of fee, university extracts scanned answer copy, secures
with password, sends link/attachment to student
Challenging the result
Student not satisfied with score
Applies for 1 No
Contented
with marks?
Re Verification
Asks student
Of marks If they need
Student
Student checks
checks marks
marks Scanned copy?
Student
Response
Proceeds
Proceeds Pays University
Yes by email to
Process
Process Ends
Ends to
to collect
collect Applicable accepts
student
Fee application Pays
marksheet
marksheet To access
Applicable
1
Fee
University does not accept applicaton
Concerned Concerned
authority, authority,
extracts Yes extracts
students students
answer book Response by email to student answer book
No “No fault found”
University
System based
Checks the Discrepancy password
mark scored & observed in protection on
Answer book totalling Answer book
YES Attach to email

(or) enable
Corrections Response by email to student access for
to Records on Action taken by University download
Marks
Marks (initiated)
Database
Database
Figure 32: Challenges in Marksheet
(xiv) Correction process and Re-issuance of certificates

Objective- when a student’s appeal application for re-totalling / re-evaluation gets
accepted by the department, the student is entitled to receive corrected marksheet, in
the event of changes in the values (or) any other discrepancy.
Process Flow –
(a) Student appeals through application for re-total/re-evaluation/correction
(b) University conducts re-total (or) re-evaluation (or) correction in certificate details,
as per the request and genuineness of the case
(c) Depending on the case, the student gets a corrected certificate

Correction of student’s certificate

Student not satisfied with score /finds error in certificate data. Applies for correction/re-evaluation
Information
Information
Student receives corrected certificate/marksheet Sent
Sent to
to
Student
student
student
Student
Student appeals
appeals
For
For correction
correction
End
End of
of process
process No
University No
No action
action needed
needed Correction
Correction
University
to
to details
details in
in
verifies
verifies Any
Any correction
correction in
in
No the
the Central
Central
certificate
certificate Database
Database
Observes
Observes that
that
Students
Students Yes
Any
Any evaluation
evaluation
appeal
appeal is
is Print
discrepancy
discrepancy Print
University
genuine
genuine Initiates
Initiates Revised
Revised
correction
correction toto Certificate
Certificate or
or
No certificates
certificates Mark
Mark Sheet
Sheet
Yes
Correction
Marks
Marks
Initiates Correction
Any
Any total
total mistake
mistake Initiates to Database
Database
Re- to details
details in
in
Re- the
Evaluation the Central
Central
Evaluation Database
Database
Initiate
Initiate refund
refund of
of fee
fee
to
to student
student
Figure 33: Correction Process and Re-issuance of certificates
(xv) End of Course

Objective - After successful end of course, student can apply for higher course or
transfer certificate. When a student completes the course, in a college/university, the
student will get a course completion certificate apart from a TRANSFER certificate.
Process Flow –
(a) System identifies that the student had completed his/her course of prescribed
duration
(b) System generates a course-completion certificate
(c) Enables student to download the said certificate
(d) Hard copy of the certificate gets posted to university admin for disbursement to
student
(e) For students in colleges, the hard copy gets disbursed to the college administration

Course Completion certificate

University automatically issues course completion certificate
University initiates
Course completion
certification process
Identifies
Identifies list
list of
of
students
students who
who
Student
Student had
had completed
completed
Database
Database their
their respective
University
respective
courses
courses
Generates
Generates
Prints
Prints
Course
Course
Certificates
Certificates
Completion
Completion
Certificates
Certificates
Certificate
Certificate
Database
Database Creates
Creates digital
digital copy
copy
of
of the
the certificate
certificate
Student
Student
Student downloads
downloads Sends
Sends hard
hard copy
copy to
to
Course
Course completion
completion certificate
certificate Admin/
Admin/ Colleges
Colleges
From
From
System
System
Figure 34: End of Course
(xvi) Transfer Certificates

Objective - Transfer certificate enables a student to pursue education further at a
different university/college and TC is also one of the final documents that a student
would possess as a proof of ending relationship with the educational institution
Process Flow –
(a) Student approaches University/college for getting a Transfer certificate
(b) University/college verifies student credentials and checks if student has to pay any
dues to the college/university
(c) Applicable dues are collected
(d) On ensuring that the University/college has no objection to issue of TC, a TC is
issued.

Transfer Certificate
University issues Transfer Certificate to Students
Student Completion
Completion of
of process
process
Student Submits
Submits
Student requests
requests for
for TC
TC Student
Student
Student
Student proof
proof of
of
In
In prescribed
prescribed clearing
receives
receives TC
TC
pays
pays dues
dues clearing Downloads
Downloads
application
application format
format dues
dues
University
University
Receives
Receives
application
application Student
Student Yes
Conducts
Conducts Database
Database
scrutiny
scrutiny
Any
Any Dues?
University
Dues?
No
Generates
Generates
Certificate Transfer
Transfer
Certificate
Certificate
Certificate
Database
Database
Prints
Prints
Creates
Creates digital
digital copy
copy Certificates
Certificates
of
of the
the certificate
certificate
Sends
Sends hard
hard copy
copy to
to
Admin/
Admin/ Colleges
Colleges
Figure 35: Transfer Certificates
(xvii) Migration Certificate Process

Objective - When a student completes course successfully in any university, the student
needs to get a MIGRATION CERTIFICATAE in order to apply for any other course in any
other University.
Process Flow –
(a) Student approaches University/college for getting a Migration certificate
(b) University/college verifies student credentials and checks if student has to pay
any dues to the college/university
(c) Applicable dues are collected
(d) On ensuring that the University/college has no objection to issue of Migration
certificate, the Migration certificate is issued.

Close
After issuance of
Migration
Certificate
University verifies Recommendation for the

Student completes
University assesses 1. Leaving Migration certificate by the
course in university/
student credentials Certificate Principal or the Head of the
college
2.Marksheet Respective Divsion
NO
Scrutiny Starts
Student
Details of Course Leaving
Admit Card asked to
Registration YES Certificate YES Any Pending? Yes
available or not? Complete
available or not ? available?
formalities
No- File sent back No-File sent back
No-File Sent back
Figure 36: Migration Certificate
(xviii) Academic Staff recruitment process

Objective – When an Academic post is approved by the competent authority (Chancellor
in case of universities), filling up of the post requires support and assistance from various
departments of the Government, namely the “Public Service Commission of the State”,
Process Flow –
(a) The Vacant Academic Post gets notified in the Gazette(s)
(b) With due approvals, the vacant post /posts are listed as advertisements (through university
website, DHTE website, Employment News, other Newspapers), essentially, to give wide
publicity to the position.
(c) The task of recruitment of such posts are managed by the State Public Service
Commission. The JPSC takes charge of filling up of the post.
(d) Advertisement for specific posts are released to public
(e) Applications are received by the JPSC which are subsequently scrutinized and
filtered for eligible candidates.
(f) Eligible candidates are subjected to various degrees of evaluation viz., written
examination, face-to-face-interview etc., At the end of the exercise, the selected
candidates are given appointment letters and asked to report to the University.
(g) There are prescribed timelines under which the candidates report to the University.
In the event of non-reporting of any candidate, within specified timeline, the
appointment stands withdrawn and the next in line candidate who was assessed as
fit-for-job would be asked to report,

Filling of Academic Post – University

Academic Post Recruitment
Personnel
University
University No Action
Identified
Starts
Starts the
the N needed
(Notified)
process
University
Attaches/
Attaches/
reference
reference ofof all
all
University
University documents
documents
University OK
University refers
refers the
the Decides to Moots
Moots up up aa against
against
POST
POST CREATION
CREATION Fill the proposal
proposal creation
creation of
of
gazette
gazette post To
To fill
fill Post
Post post
post
Seeks
Clarifications
Proposal sent to JPSC from University
Yes Re-submit
JPSC Examines the
Proposal
received by proposal No
Merit N Selection
JPSC OK
complete?
Not complete
Proposal
JPSC
status
JPSC
1. Advertisement
Merit
Clarificati 2. Exams
In N
Proposal ons if any 3. Interviews
4 Merit list
5. Selection
Yes
Proposal
Proposal forfor
No action needed Personnel
filling,
filling,
DHTE
Clarificati File placed on Identified

informed
informed to to ons if any
No clarifications needed
(Notified)
OK
record
DHTE
DHTE
Figure 37: Academic Staff Recruitment Process
(xix) Enrolment of Academic & allocation of college/ department

Objective - once the Academic staff gets onboarded with a letter of “JOINING”, the staff
becomes part of the University’s academic community. Based on their respective
appointment and the availability of vacancy in the University or at the affiliated college(s)
the appointed staff gets posted in the level of Lecturer, which is now referred as the
“Assistant Professor”.
Process Flow –
(a) Staff gets onboarded to the university roll
(b) Gets confirmation of joining with a JOINING REPORT
(c) The “General Administration” Division under the REGISTRAR of university formally
initiates all other formalities including
a. Creation of Service Book
b. Enrolment to the Payroll
c. Issuance of Identity card etc.
(d) The staff becomes enabled to be posted against a defined post.

Academic staff gets formally enrolled to Unviersity

Enrolment process
Joining
Joining University
University ADMIN
ADMIN University
University FINANCE
FINANCE Information
Information to
to
Report
Report issued
issued (Registrar)
(Registrar)
University
Initiates
Initiates all
all finance
finance Other
Other Departments
Departments
to
to staff
staff Initiates
Initiates Admin
Admin related
related formalities
formalities of
of University
University
formalities
formalities
End
List
List of
of newly
newly joined
joined
staff
staff received
received by
by DHTE
DHTE Takes
Takes details
details on
on Process at DHTE
DHTE
(From
(From university)
university) DHTE’s
DHTE’s record
record ends
List
List of
of newly
newly joined
joined
staff received
staff received byby DHTE
DHTE Takes
Takes details
details on
on
JPSC
Process at JPSC
(From JPSC’s
JPSC’s record
record
(From university)
university) ends
Whether to be Gazette
Gazette of
of Government
Government
Jharkhand
Published
Gazette
Y of Jharkhand
of Jharkhand Publication ends
On
Gazette?
Not to be published
Figure 38: Enrolment of Academic Staff
(xx) Non- Academic Staff Recruitment Process

Objective – When any Non-Academic post is approved by the competent authority
(Vice-Chancellor in case of universities), filling up of the post requires support and
assistance from various departments of the Government, namely the “Staff Selection
Commission of the State”
Process Flow-
(a) The Vacant Post gets notified in the Gazette(s)
(b) With due approvals, the vacant post /posts are listed as advertisements (through
University website, DHTE website, Employment News, other News papers),
essentially, to give wide publicity to the position.
(c) The task of recruitment of such posts are managed by the State Public Service
Commission. The JSSC takes charge of filling up of the post.
(d) Advertisement for specific posts are released to public
(e) Applications are received by the JSSC which are subsequently scrutinized and
filtered for eligible candidates.

(f) There are prescribed timelines under which the candidates report to the University.
In the event of non-reporting of any candidate, within specified timeline, the
appointment stands withdrawn and the next in line candidate who was assessed as
fit-for-job would be asked to report,
Filling of Academic Post – University

Academic Post Recruitment
Personnel
University
University No Action
Identified
Starts
Starts the
the N needed
(Notified)
process
University
Attaches/
Attaches/
University
University reference
reference ofof all
all
Moots
Moots up up aa documents
documents
University OK
University refers
refers the
the Decides to proposal
proposal against
against
POST
POST CREATION
CREATION Fill the To
To fill
fill Post
Post creation
creation of
of
gazette
gazette post post
post
Seeks
Clarifications
Proposal sent to JSSC from University
Yes Re-submit
JSSC Examines the
Proposal
received by proposal No
Merit N Selection
JSSC OK
complete?
Not complete
Proposal
JSSC
status
JSSC
1. Advertisement
Merit
Clarificati 2. Exams
In N
Proposal ons if any 3. Interviews
4 Merit list
5. Selection
Yes
Proposal
Proposal forfor
No action needed Personnel
filling,
filling,
DHTE
Clarificati File placed on Identified

informed
informed to to ons if any
No clarifications needed
(Notified)
OK
record
DHTE
DHTE
Figure 39: Non- Academic Post Creation
(xxi) Enrolment of Non-Academic staff & allocation of Department

Objective - once the Academic staff gets onboarded with a letter of “JOINING”, the staff
becomes part of the University’s non-academic staff community. Based on their
respective appointment and the availability of vacancy in the University or at the
affiliated college(s) the appointed staff gets posted in the level at which the staff has
been recruited for. It may be Junior assistant, senior assistant.
Process Flow –
(a) Gets confirmation of joining with a JOINING REPORT
(b) The “General Administration” Division under the REGISTRAR of university formally
initiates all other formalities including
a. Creation of Service Book
b. Enrolment to the Payroll
c. Issuance of Identity card etc.
(c) The staff becomes enabled to be posted against a defined post.

Academic staff gets formally enrolled to Unviersity

Enrolment process
Joining
Joining University
University ADMIN
ADMIN University
University FINANCE
FINANCE Information
Information to
to
Report
Report issued
issued (Registrar)
(Registrar)
University
Initiates
Initiates all
all finance
finance Other
Other Departments
Departments
to
to staff
staff Initiates
Initiates Admin
Admin related
related formalities
formalities of
of University
University
formalities
formalities
End
List
List of
of newly
newly joined
joined
staff
staff received
received by
by DHTE
DHTE Takes
Takes details
details on
on Process at DHTE
DHTE
(From
(From university)
university) DHTE’s
DHTE’s record
record ends
List
List of
of newly
newly joined
joined
staff Takes
Takes details
details on
on
received
staff received byby DHTE
DHTE Process at JSSC
JSSC
JSSC’s
JSSC’s record
record
(From
(From university)
university) ends
Whether to be Gazette
Gazette of
of Government
Government
Jharkhand
Gazette
Published
Y of
of Jharkhand
Jharkhand Publication ends
On
Gazette?
Not to be published
Figure 40: Enrolment of Non-Academic Staff
(xxii) Library Management

Objective: To manage the records related to the library.
Process Flow:
(a) The enrollment number of the student shall be sufficient for getting him books
issued from library
(b) Students approach library desk with the book he desires to get issued.
(c) Library officer checks in the DHTE application Common Digital System of DHTE, if
student is eligible for issuing a book.
(d) Common Digital System of DHTE shows the books issued to the student in past.
(e) If no. of books issued to the student in the past are less than the no. of books
entitled, the officer makes an entry of the book against the enrollment number of
the student.
(f) Common Digital System of DHTE automatically update the return data in system
based on the information fed in the system earlier.

(g) Common Digital System of DHTE shows the delay in weeks/ days in returning the
book by the student.
(h) When student returns the book, the officer mark as the book returned against the
enrollment number of the student
(i) Name based used id shall be issued to library officer.
System triggers Student’s basic details
Student gets captured from system
issuance of Library
Registration number • Registration Number
Card for Student
• Name
Student gets alert in • Year of Joining
his Department
Library Card • Validity of Card
email & through
Generated in the • Card Sequence (No.½,
System No. 2/2)
SMS, SM
• Subject /Course
Acknowledges the
Student reaches the
Receives Library Card receipt through
Library Counter
email & on register
System
System
Card usable at On Course
Student is active Disable Card
library completion
Figure 41: Library Management
(xxiii) Learning Management System & Training Module

Objective: Learning Management system has become one of the many core
components in educational institutions that helps in enhancing learning process, by
supplementing the traditional learning tools. A Learning Management System not only
delivers content, but also handles registering courses, course administration, skill gap
analysis, tracking, and reporting. LMSs also include a performance management system
which encompasses employee appraisal, competency management, and skill gap
analysis. It is envisaged to have a Learning management system as part of the overall
Central system to enable students & faculty to take maximum benefits of online modules
in their continued learning process.
Process Flow:
(a) Student or faculty or employee or visiting faculty logs to the designated LMS portal
of the Common Digital Platform.
(b) Search for any module of their interest either to learn or to just browse through.
(c) Take advantage of the available resources including audio, video, visuals,
diagrams, animations in the chosen module for their knowledge enhancement
(d) This Learning management tool to be a continuously updated and upgraded
system for the benefit of students , faculty, employees

The facility of Online Classes using Digital Platform, enables the end users to enhance their
knowledge and skills, without venturing physically to a different location. The offerings
through such online mode and also enables learners to break free from the time-barriers.
(Students in case of this Common Digital Platform – CDP) and the non-students including
faculty and non-faculty member who prefer to enhance their knowledge and skills.
LMS Portals provides our learners with varied modes of Learning Management System (LMS).
Given the Governments push for cloud base application and locally hosted applications, the
CDP may extend extensive learning system through hybrid mode. Tools for robust course
development with support for multiple formats, including MP4, HTML5, YouTube, Vimeo,
documents, images are feasible at present.
Deploy an optimized algorithm to collect and analyze critical data regarding students usage
and performance. While learning is one of the key factors in any LMS or any Digital Platform,
the facility for reporting to ensure user engagement, performance, and course completion are
the key to such LMS.
During deployment, the best of solutions at that instance is expected to benefit the end users
and the universities.
(xxiv) Training of Faculty, Non-Faculty – Capacity Building

Objective: New modules and systems are being implemented by the Government,
Universities and colleges. For those processes & modules for which experienced employees
including faculty are the consumers, the training needs (capacity building needs) are not
addressed adequately. Depending on the requirement to various stakeholders viz., the faculty,
non-faculty, employees in the DHTE, regular capacity building is found to be a serious wanting.
The Learning Management System (as a tool referred above) will enable the end users to
enroll in specific modules for their learning process. The LMS’s being implemented in any eco
system offers modes for knowledge seeking users to demand for courses and subjects. Apart
from the LMS, a regular training calendar for DHTE employees, Faculty, NonFaculty and other
users needs to be formulated by the Government, based on which requisite capacity building
process shall be implemented.

Start Populate the Enable

Create batches based
needs and ANNUAL
on commonality and
segregate into TRAINING PLAN for
exclusivity
sectors Faculty & Non-Faculty
Access Faculty &
Non Faculty to
engage with the
Univeristy Identify the right
Align trainings at the
training partner to Configure/Customize
designated institute /
offer training to courses for the
Conduct a univeristy/ including
Faculty & Non- targeted users
TRAINING NEED IIT, IIM, ISB etc
Faculty
ANALYSIS (TNA)
Refine & Repeat until

Assess end-user Mandate the users to
the complete user
performance complete the courses
base is covered
END

5. Non - Functional/ Technical Requirements
5.1 Solution Architecture

The key aspects of the architecture shall include:
(i) Users
(ii) Access channels
(iii) Gateways
(iv) Presentation layer
(v) Business services layer
(vi) Security layer
(vii) Data layer
(viii) Monitoring services
5.2 Users
The below table details the various types of users who shall interact with the core Common
Digital System of DHTE. Apart from the users described in this section or elsewhere in this DPR,
there is also a need for data/information exchange with various other agencies within India
and from abroad. The proposed system shall be capable of such data/ information exchange.
User Type and Type of Usage Approximate
Connectivity Users
Mode
Public (i) Accessing information which is available without
(Internet) user id and password
(ii) Track/Verify application status using keyword
(iii) Accessing information using OTP
(iv) Apply for University/ College Affiliation
(v) Apply for Student Registration
(vi) Right to Information (RTI)
(vii) Make online payment
(viii) Reset Password for registered users
(ix) Submit Feedback/ Grievance
Student (i) Apply for hostel 5,00,000
(Internet) (ii) Online fees payment
(iii) Access documents
(iv) Apply for semester/annual examinations
Colleges (i) View registration related/ profile details Total: 250
(Internet) (ii) Apply for Affiliation Renewal (One user id will
(iii) Apply for Affiliation Cancellation be given to


Connectivity Users
Mode
(iv) Apply for Change in registered details (College each of the
Name, Trust details, Address etc.) college)
(v) Apply for capacity enhancement
(vi) Apply for additional User Id
(vii) View and Update grievances assigned
(viii) Reply to Show Cause notice
(ix) View details of applications and documents
submitted
(x) Make payment/ bulk Payment
(xi) Track/Verify application status
University There are two types of privileges to the University Users Faculty Staff
(Internet) who requires user id and password for login Total - 3000
1. Scrutiny level – Scrutiny level users, performs RU –
following tasks – JUT –
(i) View and Update applications submitted, for: Other 6
(a) College Registration Universities –
(b) College Affiliation
(c) College Affiliation Renewal (Faculties of 8
(c) College Affiliation Suspension/ Cancellation Govt.
(d) Change in College Affiliation details Universities,
(e) College Capacity enhancement faculties of all
(f) Grievances received constituents’
(g) View reports/ details of applications submitted colleges whose
(h) Upload documents salaries are
(ii) Create and forward applications for college paid by the
suspension/ cancellation / grievance respective
2. Approval level – Approval level users (Universities) University)
approves College Affiliation related application
received from colleges. Non- Faculty
Staff
Total - 1000
RU –
JUT –
Other 6
Universities –


Connectivity Users
Mode
DHTE There are two types of privileges to the DHTE Users who 200
(Internet) requires user id and password for login -
1. Scrutiny level – Scrutiny level users, after scrutinizing
the applications, shall forward the application to
another DHTE user (either scrutiny or approval level)
or to Head of Department. Such users shall be
Receiving and processing applications for
(i) University Registration
(ii) University Affiliations
(iii) University Renewal
(iv) University Suspension/ Cancellation
(v) Change in University details
(vi) Registering, Processing, and closing of the
Grievances
(vii) Issuing Show cause notices
(viii) Updating College Details
(ix) view reports/ details of applications
submitted
(x) Upload documents
2. Approval Level – Approval level users process
applications received and approve/ reject/ send back.
DHTE - Other (i) Generating MIS reports for analysis / policy planning
Official Users
(Internet)
Helpdesk (i) Registering issues related to unavailability of software
(Internet) application / queries/ request reported by users
(ii) Checking details regarding application/ registration
status
(iii) Examining / analyzing issues registered online by
stakeholders and forward to the concerned team
member/ official.
5.3 Gateways
The core application shall need to employ the following gateways:
(i) Web gateway

(ii) XML gateway

(iii) SMS gateway
(iv) SMTP gateway
(v) Payment gateway
5.4 Presentation Layer

The key components of the presentation layer include:
(i) Personalization: The core Common Digital System of DHTE re to provide users with a
customized and personalized front-end. It allows users to view the information &
services based on the user category (public/University/College/government official) and
user preferences (colour, presentation theme) providing the user with a better quality
and richer experience.
(ii) Content Management: The Common Digital System of DHTE serves as a platform for
delivery of official information on education to various stakeholders. The Common
Digital System of DHTE shall require to employs content management processes to
ensure that the content delivered through the application are adhering to the uniform
standards across the application.
(iii) Cache Management: Web caches are maintained on the web servers to store previous
responses. Web caches reduce the amount of information that needs to be transmitted
across the network, as information previously stored in the cache can often be re-used,
especially in the case of large files like images. This reduces bandwidth & processing
requirements of web server ensuring improved responsiveness.
5.4.1 Security Layer and Strategic Controls

The core Common Digital System of DHTE shall have a centralized security management
foundation that would enable delivery of application and data to registered and public users
in a secure manner. The users would be required to login using a username and password to
access the application. Access to only those application resources would be provided that the
user has authority to. The DHTE shall have strategic control on the application and shall control
actions and access to resources of all users including privileged users such as
application/database administrators. A host-based security solution allowing policy-based
control would be deployed for the same. The solution would intercept security-sensitive events
in real-time and would evaluate their validity before passing control to the operating system.
The solution would enable administrators to only have subsets of ‘root’/’super user’ authority
and would thus prevent risk of information/data being misused by the administrators.
5.4.2 Data Layer

The key components of the data layer include:
(i) Content repository:
The content repository stores the official information (announcements, new updates,
content for the Common Digital System of DHTE etc.)

(ii) Document repository:

The document repository stores the scanned documents uploaded by various users
(DHTE/ University/ College/ Student/ Public)
(iii) Data aggregation:
Stores data about a large number of students. For the purposes of reporting and analysis
of large amounts of data, aggregation processes/tools shall be implemented. This results
in significant performance benefits, opening up the opportunity for DHTE to enhance its
analysis and reporting capabilities and aid policy planning.
5.4.3 Monitoring Services

Suitable monitoring services/tools shall be required to track performance issues and
transactions failures. The monitoring service would help in analysing if the root cause of
performance issues is in the monitored application, in connected back-end systems or at the
network layer.
5.4.4 Architectural Requirements

The table below presents the architectural requirements:
S. No Specification(s)
1. Scalability:
All components of the Common Digital System of DHTE must support scalability to
provide continuous growth to meet the requirements and demand of education
environment. A scalable system is expected to handle increasing numbers of
requests without adversely affecting the response time and throughput of the
system.
The solution should support both vertical (the growth within one operating
environment) and horizontal scalability (leveraging multiple systems to work
together on a common problem in parallel) to provide continuous growth to meet
the requirements and demand of DHTE.
A Storage solution (SAN) to cater to a 25 TB usable (excluding required for backup,
replication etc) capacity with scalability depending on the needs, arises in future
needs to may be planned. IA shall also plan for data migration and metadata and
documents related to DHTE/ University/college staff/students from existing
applications to the new core Common Digital System of DHTE shall be required to
be migrated.
A 3rd party audit agency appointed by the division shall audit and approve the
migration of data
2. Inter-operability: The entire Common Digital System of DHTE needs to be
interoperable, in order to support information flow and allow integration with
multiple heterogeneous applications and services offered by various Jharkhand
Government departments and private service providers and should allow

S. No Specification(s)
integration with various such applications. Considering the legacy database, there
may also be a need to operate the core Common Digital System of DHTE
simultaneously with multiple storage technologies from different OEMs. The system
should use open standards such as REST, SOAP, WSDL, XML, W3C etc. and other
API gateway services to ensure easier integration with other applications, as per the
need of the division.
3. Architecture: Architecture of the core Common Digital System of DHTE is
important because it enables an application to meet and fulfil the non-functional
requirements. The non-functional requirements define the runtime qualities such as
scalability, deploy-ability and reliability. They also define development time qualities
including maintainability, testability, extensibility, and scalability. The architecture
that IA choose for the application shall determine how well it meets these quality
requirements.
The goal of the architecture is to structure the application as a set of loosely coupled
services. The components or services and the connectors or the communication
protocols, enable those services to collaborate. Each service can correspond to a
different business function and can communicate using REST APIs, messaging, RPC
etc. and should be independently deployable by fully automated deployment
machinery and can be separately audited.
Automation in every step like build automation, test automation, deployment
automation etc. should be the key-enabler for establishing well-functioning
architecture.
4. Performance:
The system is expected to be designed to ensure high performance and compliant
to the defined service levels
Performance considerations are paramount as poor performance of the Common
Digital System of DHTE would directly impact the end user experience. If the system
performance degrades the queue time for various would increase exponentially.
Hence, it is essential that the Common Digital System of DHTE should be responsive
to meet the expectation of various stakeholders
5.4.5 Storage Requirement:

Common Digital System of DHTE shall keep the information/ documents processed online by
its users in addition to that information related to the employees including the old staff shall
be kept.
There are 5 Lakh students studying at any point of time in all government Universities/
Colleges in Jharkhand State. For a period of 5 year there will be a requirement of keeping the
records and certificates of 30 Lakh students. In addition to this, there is also a need for
migrating/ keeping the records and certificates of 30 Lakh students for previous 5 years

# Item Requirement (DC and DR)

1. Storage (for all project requirement except point 2 25 TB for DC & DR each
below)
2. Storage for scanned answer sheets 200 TB for DC & DR each
(Scanned Answer sheets beyond 3 years of age shall be
purged/deleted)
5.4.6 Network requirement

Various users of application shall be accessing it over internet. For this, a high-capacity
bandwidth of 8 MBPS shall be made available at Data Center and Disaster Recovery site with
redundant link of equal capacity. Overall following are the Network requirements of the project
S. No Specification
1. The network level redundancy shall be achieved through two different PoPs or
through different telecom link providers
2. The networking devices including routers, switches shall be procured with sufficient
number of ports for addressing the required bandwidth for the whole duration of the
project
5.4.7 Server(s) requirement
S. No Requirement
1. Redundancy of N+1 shall be made available with respect to servers hosting all the
critical components of architecture including web, application, database, and DNS
in high-availability mode
2. Server clusters shall be implemented in active-active mode.
3. Size of each server or total number of servers in a cluster implemented for the
solution shall be determined in a manner to ensure that no performance
degradation happens, even if a particular server is unavailable.
4. System shall provide for horizontal scalability in such a manner that a new server
can be added (or removed) dynamically, as and when required in future, without
disturbing the normal functioning of production system
5. The vertical scalability in servers in terms of additional processors and RAM will
have to be provided for handling future growth in transactions
5.4.8 Security Requirement

The overall system shall adhere to highest security standards at all layers namely
(i) User layer
(ii) Application Layer
(iii) Network Layer

(iv) Infrastructure Layer

The diagram below depicts the requirement
USER
USER LEVEL
LEVEL SECURITY
SECURITY NETWORK
NETWORK LEVEL
LEVEL SECURITY
SECURITY
Infrastructure
Infrastructure level
level Security
Security
INTERNET
Database
Database SErver
SErver
IPS
User
User
FIREWALL
FIREWALL
DNS
DNS Server
Server
APPLICATION
APPLICATION LEVEL
LEVEL SECURITY
SECURITY
Figure 42: Security Requirements
S. No Specification
1. User Machine Level Security
1.1. Restricted areas of the application should be accessible only for the users
having user id and password. For 2 factor authentication mobile/ email OTP.
1.2. System shall maintain an access audit log entry when this form of
authentication is used to access the system.
2. Application-level security
2.1. Authentication and authorization
2.1.1. System should prompt the user to provide username/password to access
restricted areas of the application
2.1.2. Each user shall maintain unique user id.
2.1.3. The password complexity parameters are recommended to be
specified as follows:
(i) Minimum password length – 8 Characters
(ii) Mixed case – Mandatory
(iii) Alpha-numeric – Mandatory
(iv) Special character – mandatory
(v) Password expiry – 45 days
(vi) Password history – 5
(vii) Account lock out – After 3 successive wrong password attempts
(viii) Account lock out period – 45 Minutes
(ix) Consecutive characters should not be allowed
(x) Session time out – 30 minutes
All the above should be configurable.
2.1.4. System shall have the functionality to allow formation of user groups. Users
may be assigned to one or more user groups

S. No Specification
2.1.5. System shall allow the administrator to define the access groups/policies in the
system.
2.1.6. Users shall be required to log in only once to access the functions they are
authorized to access. Once logged in all functions to which the user has access
should be visible to the user
2.1.7. System should only store encrypted user credentials in the database
2.1.8. System shall have a strong audit function. The log files shall be available in a
flat file format.
The log files shall be maintained for a time period as defined in log retention
guidelines
The log files shall be systematically backed up which shall be required in times
of any forensic examination
2.1.9. System shall track and report any suspicious user actions (e.g. multiple login
attempts)
2.2. Encryption of Aadhar details
2.2.1. The following Aadhar details should be stored in an encrypted format in the
database:
(i) Aadhar number
(ii) User Name
(iii) Date of Birth
(iv) Address
2.2.2. Only the Common Digital System of DHTE should be able to access the above
mentioned Aadhar details —other applications should not be able to decrypt
the data.
2.2.3. Robust symmetric encryption algorithms should be employed (e.g. DAES)
3. Infrastructure level security
3.1. The application infrastructure should be hosted in a Demilitarized Zone (DMZ)
set up by using firewall
3.2. The application server and database servers should be accessed only through
a firewall.
3.3. Firewalls and IPS devices should be hosted on separate servers.
3.4. Firewall should support a zero-day attack prevention mechanism.
3.5. CERT-IN guidelines shall be complied with for Server hardening
3.6. Gateway level anti-virus system should be deployed to defend virus and worm
attacks
Antivirus shall be up to date at any given time
4. Network level security

S. No Specification
4.1. All transactions conducted on the network shall be encrypted using SSL.
Industry standard/ IT Act compliant encryption techniques/ technology shall be
used for this purpose.
5.4.9 Email Service

The functional specifications of the email service are provided below –
S. No Specification
(i) System should use a reliable SMTP server for sending and receiving emails
(ii) System should allow creation and configuration of various mailboxes (around 10
functional mailbox accounts with minimum mailbox size of 50 MBs)
(iii) System should allow templates to be created for composing emails. System should
provide a user interface to create and manage the actual emails that is used for
sending mails from the application
(iv) System should provide standard functions for sending mails from the application
(v) System should support HTML and RTF messages
(vi) System should be able to generate reports on email delivery and able to publish
the metrics based on email tags.
(vii) System should allow debugging of any issues encountered while routing emails
(viii) System should maintain a copy of the emails sent from the Common Digital System
of DHTE
(ix) System should support periodic archiving of emails
5.4.10 Content Management System

The functional specifications of the content management system are provided below –
S. No Specification
(i) System should allow content management on the Common Digital System of DHTE
(ii) System should allow management of the complete content and document
management lifecycle processes including content creation, updating and approval
(iii) System should allow creation of templates that could be directly used for creating
content
(iv) System should allow content creation and management using tools like a browser
etc.
(v) System should be capable of working simultaneously with multiple database
instances and should interoperate with multiple databases for content retrieval.
system will be integrated with the content management system such that important
alerts and notifications appear on the home page of the user.
(vi) System should allow management of contributor, managerial rights and privileges
according to the predefined roles for security and to ensure that participants are
undertaking suitable and appropriate tasks.

S. No Specification
(vii) System should tag content with metadata to allow easy and quick access
(viii) System should store content as reusable XML, HTML etc.
(ix) System should be able to provide support for managing content in XML or other
format via Common Digital System of DHTE and for exposing content and
functionality within the system as standard XML
(x) System should be able to import and export content and template objects for
deployment and replication between servers
(xi) System should support controlled access to the content
(xii) System should provide integration with external web-based applications
(xiii) System should be able to organize the contents on the basis of topics
(xiv) System should provide centrally controlled auditing, expiration & retention policies.
(xv) System should be able to provide a full-text search option to search content based
on text.
(xvi) System should be able to provide a single sign-in feature for accessing the
application and content management Common Digital System of DHTE
(xvii) System should allow Content management system user to have access to a web
page repository containing all types of media files-images, PDFs, videos, word files
etc
(xviii) System should be able to maintain error logs and provide audit trail logs to improve
content availability
(xix) System should be able to maintain archives folder-wise based on year of
publication. User can access any of these by accessing the respective folder.
(xx) System should allow all popular file formats (like images, PDF, doc and some format
of videos) can be uploaded and downloaded. Print feature should be available for
content in doc and PDF format.
5.4.11 Host Based Security System

The specifications of the host-based security system provided below are not exhaustive. IA will
be required to document detailed requirements related to host-based security in consultation
with DHTE and as per industry standards.
S. No Specification
(i) System should allow controlling of access to all system resources including data
files, devices, processes/daemons and audit files.
(ii) System should intercept security-sensitive events in real-time and evaluate its
validity before passing control to the OS.
(iii) System should be the first layer of security for the system, and any access prevented
it should not be overridden by the OS, even if OS permissions directly permit such
access.

S. No Specification
(iv) System should be non-intrusive. It should make no changes to the operating system
kernel or binaries. Software must allow for quick uninstall if necessary.
(v) System should provide fine grained user control and should allow controlling
actions and access to resources of all users including privileged accounts such as
root / administrator
(vi) System should enable the administrators to share subsets of root authority among
different administrators based on their functional roles
(vii) System should provide network source controls. It must be able to restrict user login
from specific machines / hosts / terminals for network access or physically
connected terminals such as dumb terminals.
(viii) System should provide Operating System (OS) security hardening and extra levels
of access control to the platform.
5.5 Hardware and Software Requirements (Item wise)

An indicative table of Hardware and System software to be provided by Cloud service provider
is listed below
S. No Name Count
1. Server: Cores 30, Local Disk in GB 100 (DC - 8; DR -7) 15
2. Blade Chassis (DC - 2; DR -2) 4
3. Back-Up Software Solution (DC - 1; DR - 1) 2
4. Tape Library (DC - 1; DR - 1) 2
5. SAN Storage DC (usable) 25 TB
6. SAN Storage DR (usable) 25 TB
7. SAN Switch (2 DC & 2 DR) 4
8. Network Devices - External Zone LAN Switch (2 DC & 2 DR) 4
9. Network Devices - Internal Zone LAN Switch (2 DC & 2 DR) 4

10. ILL Router - 2 DC & 2 DR 4
11. Server Load Balancer (2 DC & 2 DR) 4
12. Link Load Balancer (2 DC & 2 DR) 4
13. External Firewall + SSL VPN + Gateway Anti-Virus, Content 4
Filtering, App control (DC - 2 & DR - 2)
14. UTM (DC - 2 & DR - 2) 4
15. Internal Firewall with NIPS (DC -2 & DR -2) 4
16. Syslog Server (DC -2 & DR -2) 4
17. SIEM (DC -2 & DR -2) 4

S. No Name Count
18. SSL 2
19. Internet Bandwidth of 8 Mbps at DC with redundancy 16 Mbps
20. Internet Bandwidth of 8 Mbps at DC with redundancy 16 Mbps
21. MPLS connectivity between DC & DR for database replication To be assessed by
the IA
22. Internet link for SLA monitoring - DC 2 Mbps with redundancy 4 Mbps
23. Internet link for SLA monitoring - DR 2 Mbps with redundancy 4 Mbps

6. Implementation Model
The Common Digital System of DHTE is planned to be built and operated in an outsourced
model. Such a model would allow DHTE to address important factors such as DHTE’s
ownership of the Common Digital System of DHTE and to benefit from specialized expertise
of private sector. The following responsibility matrix depicts the broad aspects of the
implementation model:
S. No Aspect/Component Responsibility/ Ownership

IA DHTE
1. Implementation and operation of the Yes -
project
2. Strategic control over the project - Yes
3. Ownership of all IT infrastructure, - Yes
Common Digital System of DHTE, system
software and all related components
4. Certification of the Common Digital - Yes (through

System of DHTE and infrastructure prior to a 3rd party
go-live audit agency)
5. Program governance - Yes (through

a PMU)
6. Procurement and setup of client-end No (though IA would Yes
hardware, software and LAN be required to advise
DHTE on suitability of
the items being
procured with respect
to those being installed
by the IA and any other
technical aspect related
to the procurement &
installation process)
7. Setup of office infrastructure for DHTE or No Yes

any other agency created by DHTE

7. Timelines
DHTE’s Common Digital Platform is envisaged to be developed, implemented and rolled out
in a phased manner. The project timelines are depicted below:
Figure 43: Project Timeline
The Operations and Maintenance of the project will be for a period of 5 years from the date
of declaration of Go-Live.
Operations & Maintenance Phase

Year YEAR 1 YEAR 2 YEAR 3 YEAR 4 YEAR 5
Quarters 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Months 60 Months

8. Scope of Work for the Implementation Agency

The project needs to be developed and deployed by a Professional Agency, referred as the
Implementation Agency (IA). The scope of work for the implementation agency as part of the
Common Digital System of DHTE project shall include:
8.1 Requirements Gathering and SRS Preparation

The IA shall gather and document the Software requirements in a comprehensive manner for
the services listed by DHTE and prepare a Software Requirements Specifications (SRS)
document based on the functional requirement specified by DHTE in consultation with DHTE
and its representatives. It is planned that the IA shall have detailed interactions with various
stakeholders at following sites:
(i) Ranchi (Interactions with DHTE, Additional Secretary, Universities, Colleges, any other
agency/ group that DHTE may desire to add)
(ii) Two Universities locations, in addition to DHTE, as identified by DHTE (Interactions with
Registrar of Universities, Academic Faculty and Non- Academic officials, any other
agency/ group that DHTE may desire to add)
8.2 Design, Development and Testing of Common Digital System of DHTE

IA shall design, develop, and test the Common Digital System of DHTE for meeting the system
requirement specifications finalized for the services.
The solution design shall include the design of application architecture, information
architecture, network architecture, deployment architecture, security architecture etc. On the
basis of the application design signed off by DHTE or its representative, the applications shall
be modelled and designed using relevant modelling and design languages like UML. The IA
shall use the signed off design for the development of the Common Digital System of DHTE.
IA shall also be responsible for designing the testing strategy including preparation of test
plan and test cases and conducting unit testing of various modules, integration testing, load
testing, performance testing etc.
The acceptance testing of the Common Digital System of DHTE shall be done by a 3rd party
audit agency appointed by DHTE. IA shall provide all necessary support, including setting up
the required test environment, making seating arrangements and providing suitable computer
systems & peripherals, to the agency for conducting acceptance testing. DHTE shall own the
data and the IPR for the Common Digital System of DHTE and all its related components.
8.3 Migration of legacy data

IA shall be responsible for digitization and migration of data from existing data sources to the
Common Digital System of DHTE being developed as part of this project. A 3rd party audit
agency appointed by DHTE shall audit and approve the migration strategy, plan, process
adopted and results of the migration.

8.4 Setting Up of Data Center and Disaster Recovery Center

IA shall be responsible for establishing the Data Center (DC) and Disaster Recovery Center
(DRC) of Tier-3 or above norms of TIA 94. Space for housing the data centre and disaster
recovery centre shall need to be procured/ leased by the IA. IA shall also provide adequate
staff to operate and manage the functioning of DC and DRC at desired levels.
8.5 Procurement, Installation, Configuration and Commissioning of Server-

Side Hardware
IA shall supply all necessary hardware (servers, load balancers, SAN storage systems etc.) and
related software for the DHTE data centre and disaster recovery centre and shall also be
responsible for commissioning the hardware ready to host the Common Digital System of
DHTE. IA shall also supply all necessary hardware and software for setup of DHTE application
staging environment. IA shall need to perform an independent assessment of the
infrastructure requirements for the Common Digital System of DHTE and shall provide a
detailed BOM meeting the SLA requirements specified by DHTE.
3rd party audit agency appointed by DHTE shall review the conformity of the specifications
provided and/or as proposed in the proposal submitted by the IA.
It must be noted that the software would be owned by DHTE.
8.6 Implementation of Various Change Management Initiatives

IA shall be responsible for implementing various change management interventions as
detailed –
(i) IA shall conduct the trainings for following stakeholders:
(a) DHTE Officials
(b) University and College Staff
(ii) IA shall be responsible for developing the training content for all the trainings mentioned
above. The training content shall focus on scenarios and examples of transactions
relevant for the stakeholders.
(iii) IA shall also be responsible for retraining the DHTE, University and College personnel
whenever the staff is replaced, or changes are made to the Common Digital System of
DHTE.
(iv) IA shall also develop training modules/ video for:
(a) DHTE Officials
(b) University Staff
(c) College Staff
8.7 Operations and Maintenance (O&M)

IA shall be responsible for operations and maintenance of the Common Digital System of
DHTE, Data Center and Disaster Recovery Center, network, and any other component or facility
being established by IA as part of this project. IA shall also deploy adequate staff for operating
the Common Digital System of DHTE. The following sections detail the O&M requirements.

8.7.1 Application Management

IA shall be responsible for defect free operation of the Common Digital System of DHTE during
the O&M period and ensuring its 24x7 availability at all the end-user locations and across
all the channels of access. Any bugs reported in the application shall need to be fixed within
a time frame mutually agreeable to both DHTE and IA.
IA shall also be responsible for version control of the application files and shall need to
update application documentation to reflect the current features and functionality of the
application.
IA shall provide a staging environment in the Data Center for testing of changes/ patches
before applying them on production environment.
8.7.2 Infrastructure Management

Infrastructure management includes overall management and administration of entire IT and
non-IT infrastructure including servers (including server operating system), network
components, storage devices, UPS, DG sets, air-conditioners, etc. IA shall be responsible for
the following activities as part of infrastructure management:
(i) Incident management
• Provide resolution to incidents as per the resolution time limit agreed upon with
DHTE
(ii) Problem management
• Perform root cause analysis for infrastructure problems/recurring incidents and
initiate request for change
• Schedule and complete preventive maintenance activities
(iii) Business continuity management
• Provide necessary support in ensuring business continuity at end-user locations
(iv) Configuration management
• Maintain a database of server count and configurations
(v) Change management
• Ensure that any component change due to any fault is replaced with a component
of the same make and configuration
• Maintain records of all hardware, software installation, movement, upgrade, addition
and change (IMAC) in the configuration database.
• Perform impact analysis, create test plan, develop rollback plans
(vi) Availability management
• Review key monitoring parameters (to be finalized in consultation with DHTE) from
availability point of view
• Performance tuning of the system to enhance system’s performance and comply to
SLAs on a continuous basis
• Provide prior communication on outages as per agreed communication processes

• Ensure availability of sufficient critical spares, sufficient consumable spares at all

relevant locations
• Ensure availability of consumable spares.
(vii) Monitoring management
• Preparation of monthly dashboard on monitoring coverage, alerts generated/
closed, alerts escalated and other hits/ misses
(viii) Backup management
• IA should evolve a backup and archival strategy
• Regular backups of project related data
• Media management like inter and intra city tape transfers
• Handling service requests on backup and restoration
• Generation of monthly report on the backup/restoration performance
(ix) Security management
• 100% antivirus coverage with patterns not more than one week old on any given
system
• Reporting and resolution of security incidents
• Maintaining secure domain policies
(x) Vendor management
• Escalation and co-ordination with other vendors for problem resolution
(xi) Disaster recovery management
• Managing Disaster Recovery activities pertaining to data center operations
(xii) General administration and support
• Providing suitable access to PMU, designated by DHTE, to tools implemented for
monitoring infrastructure components
• Creation/deletion/modification of user accounts at the OS level
• Periodic review of user privileges at the OS level
• Password management
• Any other day-to-day administration and support activities required
• Clean up / archival of Common Digital System of DHTE logs
• Operation
8.7.3 Network management

The broad activities would include:
(i) Incident management
• Provide resolution to incidents as per the resolution time limit agreed upon with
DHTE
(ii) Problem management
• Root cause analysis for infrastructure problems/recurring problems and initiate
request for change
• Scheduling of maintenance activities

(iii) Asset and configuration management

• Maintain database of configuration of all network elements, links and equipment
(iv) Change and release management
• Maintain records of all hardware and software installation (new networks and
network devices, initial routes, Policy configuration), movement, addition and change
(IMAC) in a configuration database.
• Perform impact analysis, create test plan, rollback plans
• Post implementation review and documented closure for all changes and tracking all
changes implemented
(v) Availability management
• Review of key monitoring parameters from availability point of view
• Provide communication on outages as per agreed communication processes
• Ensure availability of critical network spares
(vi) Monitoring management
• Monitoring critical parameters of all network elements (CPU and memory utilization),
links availability and utilization, latency and reporting
(vii) Backup management
• Backup of application data
• Backup of configurations of all devices
• Media management like inter and intra city tape transfers
• Handling service requests on backup and restoration
• Generation of monthly report on the backup/restoration performance
(viii) Security management
• Daily Review of logs daily that are of significance such as abnormal traffic,
unauthorized penetration attempts, any sign of potential vulnerability, Security alerts
and responses. Proactive measures in the event a problem is detected.
• Policy management (firewall users, rules, hosts, access controls, daily adaptations)
• Modify security policy, routing table and protocols
• Troubleshooting firewall/anti-spamming/web security hardware related issues and
coordinating the replacement of hardware
(ix) Vendor management
• Escalation and co-ordination with other vendors for any problem resolution
(x) Disaster recovery support
• Support in Disaster Recovery activities pertaining network links.
(xi) General administration and support
• Providing suitable access to PMU, designated by DHTE, to tools implemented for
monitoring infrastructure components
• Disabling/enabling services/ports
• Any other day-to-day administration and support activities required

8.7.4 Implementation of SLA Monitoring System

(i) IA shall design and implement an SLA measurement & reporting system to measure and
report performance of the Common Digital System of DHTE against the service levels
specified by DHTE.
(ii) The system shall also allow calculation of quarterly payments to IA and any rewards and
penalties as specified by DHTE.
(iii) The SLA measurement & reporting system shall be reviewed and certified by a third-
party audit agency before project go-live and start of operations. DHTE officials and PMU
personnel shall be provided real-time access to the system. Additionally, other DHTE
designated personnel should be provided administrative privileges to the system as per
the agreed role assigned for them.
(iv) Whenever monitoring of services of core application services are required, services which
are figuring in top 20 in terms of high usage, shall be monitored at all ties, in terms of
usage.
8.8 Data and Information Security Requirements

Given the need to maintain confidentiality of data about students, a strong and comprehensive
information security policy based on leading standards such as ISO 27001 and guidelines from
Department of Information Technology (DIT) would need to be defined and implemented by
the IA. The same should be approved by DHTE and must be adhered by IA at all times during
the currency of the contract.
At the minimum the policy should define the following guidelines:
(i) Inventory of asset
• An inventory of all hardware and software assets should be maintained and updated
periodically
(ii) Information classification
Information within the system should be classified as:
• Public
• Confidential
• Restricted
Access to the information should be provided based on the classification of the
information. Data owners should nominate appropriate information classification on
their data and should review information classification periodically to determine if
current classification levels are valid.
(iii) Human resource security
Background check should be performed on all individuals for whom access to the
Common Digital System of DHTE is requested. Access should be revoked when a user
leaves the organization or does not require access to the application.

User accounts of any outsourced agency personnel should include an automatic account
expiration date, set at no longer than 6 months from their start date or till expiry of
contract whichever is earlier.
Any personnel who become aware of any loss, compromise, or possible compromise of
information, or any other incident which has information security implications, will
immediately report the incident to the designated IT in-charge.
Any personnel found violating the IS policy would be penalized.
(iv) Physical and environmental security
The Common Digital System of DHTE should be hosted in a secure Data Center facility
to prevent unauthorized access and damage to information resources. All physical entry
and exit points should be controlled using access control mechanism. The facility should
be monitored 24 hours a day using cameras. Signs indicating “Authorized Personnel
Only”, or a similar message should be prominently displayed at all facility entrances. All
information storage media (e.g., hard disks, floppy disks, magnetic tapes and CD-ROMs)
containing sensitive or confidential data will be physically secured, when not in use.
Security inspections should be made periodically.
(v) Communications and operations management
All operations performed by third parties should be monitored periodically. Backup of
all critical data should be taken periodically.
(vi) Access control
Access to Common Digital System of DHTE should be given only after approval from
application owner and the competent authority. The access should be on a role basis
rather than designation. The access control policy should cover:
• Identification
• Authentication
• Authorization and Access Control
• Administration
• Audit
8.9 Documentation Requirements

IA shall be responsible for preparation of documents including User Manuals, Operations
Manual, Administration Manual, Security Manual, Application Support Guide and others (if
any) as per industry best practices and acceptable standards (e.g. IEEE/ISO specifications
for documentation).
8.10 Warranty
IA shall provide comprehensive warranty for all IT and non-IT infrastructure, provided as part
of the project, for a period of 5 years from the go-live date.

8.11 Support for Acceptance Testing and Certification

IA shall provide adequate support to the 3rd Party Audit Agency, or any other agency/ group
appointed by DHTE for acceptance testing and certification of IA’s deliverables
Note: IA shall be responsible for obtaining any statutory approval required for executing any
part of his work. DHTE may extend possible help in facilitating such approvals.

9. DHTE Strategic Control Requirements

As the DHTE project involves handling sensitive data about DHTE, Universities, Colleges and
Students DHTE requires that it retains a strategic control over the application solution to
ensure that:
• Any change to the application, database, infrastructure is made under the due authority of
DHTE
• DHTE has supervisory control over system, network and database administration
• Security of the application/data is not compromised (not even by the administrators)
• DHTE has the understanding of the system and is in a position to scale up and take over
the system, whenever required
IA will be required to document detailed policy and procedures related to strategic control
and get it reviewed and approved by DHTE. This document should be finalized during SRS
preparation stage and certainly before the start of design.
Few high-level requirements of strategic control are specified below:
9.1 Requirements of Strategic Control Over Application

The high-level requirements of strategic control over the application are specified below.
9.1.1 Retention of Ownership and Control Over Core and Configurable Modules
(i) DHTE shall exercise ownership of core and configurable modules. To this end, the system
shall be designed to ensure that:
(a) DHTE or their authorized representatives are associated with the design and
development phases of the Common Digital System of DHTE. Specifically, the IA shall
obtain signoff on all design documents
(b) The Common Digital System of DHTE modules and their source code are stored in a
repository with the DHTE after the modules are developed in accordance with the
procedures laid down or approved by DHTE
(c) Any subsequent changes to the application are incorporated in the application
repository on an incremental basis, after the process of approval prescribed is
undergone.
(ii) Any changes to the application, required to enhance the functionality, or to improve
performance or to cover security gaps, shall first be documented by the IA in detail such
as the proposed change, the reasons necessitating the change, the impact of change on
application, effort and time required in effecting the change. Thereupon a request shall
be referred to the Application Administrator(s) or equivalent personnel designated by
DHTE for the purpose, to approve the proposed changes. IA shall first host the changes
in the application staging environment and test it for consistency, integrity and
performance. IA will then refer the changes made in the application, together with its
test cases and test results, to the personnel of DHTE for their review and final approval
before the changes are deployed in the production environment.

(iii) No change to the application shall be affected by the IA unless the process defined at
(a) above is adhered to.
(iv) The source code shall not be shared with or provided to any other party.
9.1.2 Application Audit

The following requirements shall be met in regard to application audit.
(i) The system shall allow conducting post-implementation review and audit in select cases
that have resulted in a major change to check the completeness and correctness of the
administrative tasks performed and ensuring that all and only the necessary components
have been installed on the system. This acts against both malicious programs and faulty
administrative actions.
(ii) DHTE may undertake comprehensive application audits at regular intervals through a
designated third party to ensure application functionality and integrity.
9.1.3 Version Control

(i) The Common Digital System of DHTE shall be version controlled, adopting the industry
standard practices like Version Control System (VCS), Source Code Management System
and Software Configuration Management (SCM) in this regard.
(ii) The system shall permit the latest versions of the application and source code to be
stored in a repository with the DHTE, with appropriate logs maintained for each change.
9.1.4 Role Segregation

(i) The roles of different personnel responsible for designing, coding, accepting the changes
and authorizing the changes to be carried out into the production environment shall be
clearly defined by the IA and shared with DHTE.
(ii) The role segregation shall cover all the administrators.
9.2 Requirements of Strategic Control Over Database

The high-level requirements of strategic control over the database system are specified below.
9.2.1 Retention Of Ownership and Control Over the Database

(i) DHTE shall exercise ownership of the database, through a database control module. To
this end, the Common Digital System of DHTE shall be designed to ensure that
(a) The entire database, including the table structures, schemas and master data are
stored in repository with DHTE after data entered/ migrated by the IA is validated by
DHTE.
(b) Any subsequent changes to the database system are incorporated in the database
repository on an incremental basis, after the process of approval prescribed herein
is undergone.
(ii) Any changes to the database, required to enhance the functionality, or to improve
performance or to cover security gaps, and any changes to the master data, shall first be
documented by the IA in detail such as the proposed change, the reasons necessitating

the change, the impact of change on database and application, effort and time required
in effecting the change. Thereupon a request shall be referred to the Database
Administrator(s) or equivalent personnel designated by DHTE for the purpose, to
approve the proposed changes. IA shall first host the changes in the database staging
environment and test it for consistency, integrity and performance. IA will then refer the
changes made in the database, together with its test cases and test results, to the
personnel of DHTE for their review and final approval before the changes are deployed
in the production environment.
(iii) No change to the database or to the master data shall be affected by the IA unless the
process defined at (a) above is adhered to. To this end, all the actions of the database
administrator of the IA shall be logged.
(iv) Any direct access to database must be avoided and the database administration activities
(especially all those actions that result in modification of data, schema and master data)
shall be executed through an application which verifies, and audits users, code and
actions done on the database.
(v) The primary owner of the entire information captured in the database shall be DHTE.
9.2.2 Process Controls on Database Administration

(i) DHTE’s DBA(s) shall have the right to oversee the actions executed by the IA, by their
physical presence, till the later logs out to ensure that the actions are as per the approved
procedure
(ii) IA shall ensure that frequency of DBA activities is restricted to as minimum as possible.
9.2.3 Audit of DBA Actions

(i) All DBA actions and any action on the database by any user must be logged
automatically by the database server/ profiling tools and audit logs should be preserved
securely
(ii) DHTE may conduct a comprehensive third-party audit on the database audit logs from
time to time to verify the set of actions performed within a given period.
9.2.4 Protection of Confidentiality and Integrity of Data

Confidential data in the database must be encrypted by the application and the data which
must not be modified shall be hashed and digitally signed by the application at the time of
original data population itself.
9.2.5 Role Segregation

(i) Database Owner (DHTE), IA DBAs and application users must be kept as separate users/
user groups. The access privileges for each of the three must be defined in detail and it
must be approved by DHTE before the start of operations.
(ii) The user management part of DBA role shall be segregated and assigned to individuals.

9.3 Requirements of Strategic Control Over Security Administration and

Network Administration
The high-level requirements of strategic control over the security and network management
are specified below.
(i) The Common Digital System of DHTE shall be designed and developed in compliance to
the security requirements as specified.
(ii) The core activities relating to security and network administration like assigning roles
and privileges, configuration management in relation to all the security assets like
firewalls, routers, switches, IPS (Intrusion Prevention System) and IDS (Intrusion
Detection System), shall be carried out only after the prior approval of the security and
network administrator or equivalent personnel designated by the DHTE for this purpose.
(iii) Monitoring System Access and Use
(iv) DHTE or its designated agency will have full access to all the logs to supervise and review
the system activities
(v) System should provide the capability to centrally monitor the content of audit records
generated by individual components throughout the system.
(vi) System must have automatic provision to send alerts and notifications to the respective
administrators when account creations, deletions, modifications etc are done.

10. Acceptance of System for Go-Live

Date on which the Common Digital System of DHTE is made operational on the production
environment and becomes available for use to all the identified stakeholders of the project
post successful completion to the satisfaction of DHTE of acceptance testing by the 3rd party
audit agency or any other agency/ group designated by DHTE.

11. Program Governance

The ‘Common Digital System of DHTE’ project envisages transforming education into a simple,
transparent, orderly, and humane process. Implementing such a program that would impact
students in a direct manner and has linkages with a wide-ranging set of stakeholders is likely
to encounter various challenges. Therefore, an appropriate governance structure comprising
of a Steering Committee (SC) and a Program Management Unit (PMU) shall be put in place by
DHTE to ensure the long-term success of the project.
Figure 44: Program Governance
11.1 Steering Committee

The steering committee would be responsible for providing guidance and requisite resources
to the project. The committee would comprise senior DHTE officials and may have
representatives from other departments and/ or agencies as deemed necessary by DHTE.
The committee would meet on a monthly basis with the PMU to monitor the project and help
in overcoming the obstacles encountered during the project implementation. The chairperson
(a senior DHTE official, to be decided by DHTE) may also convene ad-doc meetings if required.
11.2 Program Management Unit

The PMU would be led by a senior Government official appointed by DHTE and empowered
to take decisions in line with the guidelines and sanction provided by the Steering Committee.
The PMU shall comprise experts who would be helping DHTE monitor the project’s
implementation as per objectives and requirements as specified. The functions of PMU shall
include:
• Monitoring project implementation in terms of quality, time, scope and budget
• Providing guidance to IA and helping DHTE in decision making and issue resolution
• Reviewing deliverables and providing recommendation for sign-offs
• Coordinating with various internal and external stakeholders
• Reporting to the steering committee on project matter The IA shall report to the PMU on
an ongoing basis
11.3 IA Program Management Requirements

IA would be required to have a full-time program management team in place for the entire
duration of the project. The team should be manned with the right mix of personnel with
project management and technical skills. The team would be required to support work in

tandem with the PMU set up by DHTE, in program governance activities. The program
management team of IA shall be responsible for interacting with the program management
unit of DHTE with regard to submission of deliverables, getting sign-off on deliverables and
other operational issues.

12. Audit Requirements (Quality Control)

A 3rd Party Audit Agency (3PAA) shall be appointed by DHTE to review all aspects of the
project and certify compliance with DPR before the system is rolled out and declared “Go-
Live”. The 3PAA shall certify the following aspects:
(i) Functional review: The 3PAA would conduct acceptance testing of the Common Digital
System of DHTE and review and verify the Common Digital System of DHTE against the
functional requirements as specified and/or signed-off with IA. This would include the
review and verification of SLA Management methodology and tools as well as the quality
of data migration.
(ii) Non-functional review: The 3PAA would review the Common Digital System of DHTE
against the non-functional requirements and specification as specified/ signed-off with
IA for:
• Security – including audit of network, server, application, and host security
mechanisms, assessment of encryption mechanisms, and compliance with ISO 27001
etc.
• Performance – including testing to ascertain request-response time, document
upload time, disaster recovery time and other performance parameters as specified
and/ or as signed off with IA.
• Availability – including network, server fail-over tests and other industry standard
parameters
• Scalability – infrastructure and application, both horizontal and vertical
• Interoperability – system design to facilitate interoperability with other systems
(present or future) as desired by DHTE
• Standards – compliance with standards as specified e.g., ITIL/ITSM
• Strategic Control of DHTE – provision for necessary checks and facilities specified or
any other document post-DPR
(iii) Infrastructure review: The 3PAA would verify the conformance of infrastructure
provided by IA against the requirements, specifications and bill of material as specified
and/or as signed-off with IA.
(iv) Project documentation: The 3PAA would review and verify for being of acceptable
standard the project documents developed by IA including design documents, source
code, operation manuals, training manuals etc.
Note: The IA will be required to ensure that the testing & audit of Common Digital System of
DHTE is completed and certified by the 3PAA in a maximum of three iterations.

13. Requirements for Adherence to Standards

IA will be required to adopt the best practices and acceptable standards prevalent in the
industry in all areas of the project. Few standards applicable to key activity groups have been
mentioned here for example and the list below is not to be treated as exhaustive:
Areas Standard to be Considered

Data Center design TIA-942
Data element encryption AES
Digital certificates X.509, RSA
Information security ISO 27001
Interoperability Web services, open standards, e-governance
standards (http://egovstandards.gov.in)
Photograph JPEG
Common Digital System of DHTE W3C specifications
Development
Scanned document PDF (Minimum resolution of 300 dpi)
Workflow design WFMC or BPEL standards
Information system management ITIL/ ITSM
ITIL/ ITSM IEEE/ISO specifications for documentation
Information access/transfer SOAP, HTTP/HTTPS
protocols

14. Exit Management

(i) An Exit Management plan shall be furnished by Implementation agency in writing to the
DHTE or its nominated agencies within 90 days from the Effective Date of this
Agreement, which shall deal with at least the following aspects of exit management in
relation to the MSA and the SLA.
(a) A detailed program of the transfer process that could be used in conjunction with a
Replacement Implementation agency including details of the means to be used to
ensure continuing provision of the services throughout the transfer process or until
the cessation of the services and of the management structure to be used during the
transfer
(b) plans for the communication with such of the Implementation agency's sub-
contractors, staff, suppliers, customers and any related third party as are necessary
to avoid any material detrimental impact on Project’s operations as a result of
undertaking the transfer
(c) (If applicable) proposed arrangements for the segregation of the Implementation
agency's networks from the networks employed by PROJECT and identification of
specific security tasks necessary for an effective termination
(d) Plans for provision of contingent support to DHTE and its Replacement
Implementation agency for a reasonable period after transfer.
(ii) The Implementation agency shall re-draft the Exit Management Plan annually thereafter
to ensure that it is kept relevant and up to date.
(iii) Each Exit Management Plan shall be presented by the Implementation agency to and
approved by the DHTE or its nominated agencies.
(iv) The terms of payment as stated in the Terms of Payment Schedule are deemed to include
the costs of the Implementation agency complying with its obligations under this
Schedule.
(v) In the event of termination or expiry of the MSA or the SLA, each Party shall comply with
the Exit Management Plan.
(vi) During the exit management period, the Implementation agency shall use its best efforts
to deliver the services as before the onset of exit management period.
(vii) Payments during the Exit Management period shall be made in accordance with the
Terms of Payment Schedule.
-----[End of Document] -----

Dhte DPR Revised

Uploaded by

Copyright:

Available Formats

You might also like

Dhte DPR Revised

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dhte DPR Revised

Uploaded by

Copyright:

Available Formats

2.

DETAILED PROJECT REPORT

This page has been intentionally left blank

Common Digital System of DHTE – Detailed Project Report 1

Common Digital System of DHTE – Detailed Project Report 2

5.4.11 Host Based Security System ........................................................................................................... 69

Common Digital System of DHTE – Detailed Project Report 3

Common Digital System of DHTE – Detailed Project Report 4

Common Digital System of DHTE – Detailed Project Report 5

1. Scope of this Document

Common Digital System of DHTE – Detailed Project Report 6

2. Synopsis of the Detailed Project Report (DPR)

2.1 Project Background

2.1.1 Modules Common for DHTE and Universities

2.1.2 Module for DHTE

2.1.3 Modules for Universities and Colleges

2.2 Implementation Model

Common Digital System of DHTE – Detailed Project Report 7

2.3 Assessment and Estimation for Solution Sizing

2.3.1 Number of Users

# Group Total No. of Users Estimated

2.3.2 Number of Concurrent Users

Common Digital System of DHTE – Detailed Project Report 8

2.3.3 Storage Requirement

2.4 Implementation Timeline

2.5 Training Requirements

2.5.1 Estimated Number of users to be trained

Common Digital System of DHTE – Detailed Project Report 9

2.6 Helpdesk Support

2.7 Monitoring of Service Level Agreement (SLA)

2.8 Project Governance

2.8.1 Steering Committee

Common Digital System of DHTE – Detailed Project Report 10

2.8.2 Program Management Unit

2.9 Operation & Maintenance Phase

2.10 Estimation of Project Cost

Common Digital System of DHTE – Detailed Project Report 11

S. No Budget estimate for Cost of project with hosting on Cloud Cost

Common Digital System of DHTE – Detailed Project Report 12

3. Stakeholders In Higher and Technical Education Ecosystem

S. No Stakeholder Role/ Services provided in Higher and Technical Education

4.1 Modules Common for DHTE and Universities

4.1.1 Human Resources Management System (HRMS)

Common Digital System of DHTE – Detailed Project Report 13

Figure 1: Recruitment /Posting/Transfer of Staff and Faculty

Common Digital System of DHTE – Detailed Project Report 14

(iii) Service Record (Promotion, Leave, Deputation, Retirement and Pension)

scrutiny University Physical copy

Need 1. Merit List

Figure 2: Promotion Process

Common Digital System of DHTE – Detailed Project Report 15

Staff Leave Management

Leave Evaluates officer availability of leaves

If its leave having finance impact

Figure 3: Leave Management Process

Common Digital System of DHTE – Detailed Project Report 16

Figure 4: Payroll Management Process