Académique Documents
Professionnel Documents
Culture Documents
COMMUNICATIONS DEPARTMENT
GOVERNMENT OF ANDHRA PRADESH
HYDERABAD
RFP Structure
OVERVIEW............................................................................................................ 10
VISION.................................................................................................................. 10
VALUE PROPOSITION OF E-PRAGATI........................................................................11
MANDATORY PRINCIPLES OF E-PRAGATI..................................................................12
COMMON MANDATORY STANDARDS OF E-PRAGATI...................................................14
NUMBERING AND NAMING CONVENTIONS................................................................14
DATA ARCHITECTURE.............................................................................................78
CONCEPTUAL DATA MODELS..................................................................................78
DATA INTEGRATION VIEW.......................................................................................80
MASTER DATA....................................................................................................... 81
DATA ARCHITECTURE COMPLIANCE REQUIREMENTS..................................................81
DATA ARCHITECTURE COMPLIANCE REQUIREMENTS..................................................83
8. TECHNOLOGY ARCHITECTURE..................................................................86
8.1
8.2
8.3
8.4
8.5
9.4
9.5
TRAINING NEED..................................................................................................... 95
CHANGE MANAGEMENT.......................................................................................... 96
Annexures
ANNEXURE 1 - INTEGRATION ARCHITECTURE..............................................................................97
ANNEXURE 2 - EXISTING TEMPLE MANAGEMENT SYSTEM APPLICATIONS.........................................104
ANNEXURE 3 - TO-BE PROCESSES RECOMMENDED FOR SELECTED FUNCTIONS OF TMS (INDICATIVE
PROCESS RE-ENGINEERING)........................................................................................... 108
ANNEXURE 4 - FUNCTIONAL REQUIREMENTS OF COMMON COMPONENTS OF E-PRAGATI CONSUMED BY
TMS.......................................................................................................................... 115
ANNEXURE 5 - FUNCTIONAL REQUIREMENTS OF COMMON MODULES AND SUB-MODULES OF TEMPLE
MANAGEMENT SYSTEM.................................................................................................. 123
ANNEXURE 6 - FORMS RE-ENGINEERING REQUIREMENTS OF COMMON MODULES & SUB-MODULES OF
TMS.......................................................................................................................... 154
ANNEXURE 7 - AS-IS SAMPLE FORMS....................................................................................158
ANNEXURE 8 - MIS REPORTING REQUIREMENTS.......................................................................160
ANNEXURE 9 - EPI & KPI REQUIREMENTS...............................................................................163
ANNEXURE 10 - NON-FUNCTIONAL REQUIREMENTS OF TEMPLE MANAGEMENT SYSTEM....................164
ANNEXURE 11 - LIST OF SCHEMES IN ENDOWMENTS DEPARTMENT/ INSTITUTION.............................167
ANNEXURE 12 - LIST OF TEMPLES UNDER ENDOWMENTS DEPARTMENT.........................................168
ANNEXURE 13 SOFTWARE APPLICATION TESTING & QUALITY ASSURANCE...................................170
ANNEXURE 14 - BOM FOR PILOT IMPLEMENTATION OF TEMPLE MANAGEMENT SYSTEM.....................173
ANNEXURE 15 - GLOSSARY.................................................................................................. 181
List of Figures
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
List of Tables
e-Pragati Requirements Specification Document Temple Management System Page 8 of
216
1: PRINCIPLES OF E-PRAGATI.......................................................................................... 13
2: E-PRAGATI COMMON MANDATORY STANDARDS................................................................14
TABLE 3: E-PRAGATI OBJECT CODE TABLE...................................................................................15
TABLE 4: CLASSIFICATION OF INSTITUTIONS................................................................................16
TABLE 5: NAMES OF TMS USER DEPARTMENTS / INSTITUTIONS.......................................................16
TABLE 6: WEBSITES OF TMS USER DEPARTMENTS/TEMPLES...........................................................17
TABLE 7: KEY OBJECTIVES OF TEMPLE MANAGEMENT SYSTEM.........................................................22
TABLE 8: FACT SHEET........................................................................................................... 23
TABLE 9: DETAILED FACTSHEET...............................................................................................24
TABLE 10: PILGRIMS VOLUME.................................................................................................. 25
TABLE 11: INDICATIVE TRANSACTION SCOPE...............................................................................25
TABLE 12: DEPLOYMENT MODEL COMPONENTS............................................................................31
TABLE 13: TEMPLE MANAGEMENT SYSTEM CLOUD COMPONENTS...................................................32
TABLE 14: REVENUE MODEL OF THE ENDOWMENTS PACKAGE DEPARTMENT.......................................34
TABLE 15: DEPLOYMENT, COMMISSIONING AND GO-LIVE................................................................41
TABLE 16: OPERATIONS & MAINTENANCE...................................................................................47
TABLE 17: TMS PACKAGE DELIVERABLES.................................................................................53
TABLE 18: VIEWS OF TEMPLE APPLICATION.................................................................................62
TABLE 19: COMMON TECHNICAL SERVICES.................................................................................63
TABLE 20: LIST OF COMMON PILGRIM FACING SERVICES OF TEMPLE MANAGEMENT SYSTEM.................74
TABLE 21: LIST OF INTERNAL SERVICES OF TEMPLE MANAGEMENT SYSTEM......................................76
TABLE 22: TEMPLE MANAGEMENT SYSTEM KEY PERFORMANCE INDICATORS.....................................77
TABLE 23: TMS INTEGRATION REQUIREMENTS............................................................................81
TABLE 24: DATA ARCHITECTURE COMPLIANCE REQUIREMENTS........................................................82
TABLE 25: DATA ARCHITECTURE COMPLIANCE REQUIREMENTS.........................................................85
TABLE 26: COMPONENTS OF THE TECHNOLOGY...........................................................................87
TABLE 27: E-PRAGATI SECURITY ARCHITECTURE FRAMEWORK COMPONENTS......................................91
TABLE 28: INDICATIVE TRAINING REQUIREMENTS..........................................................................94
TABLE 29: TRAINING DELIVERABLES..........................................................................................95
TABLE 30: TRAINING MODULES AND TARGETED AUDIENCE.............................................................96
TABLE 31: CHANGE MANAGEMENT REQUIREMENTS.......................................................................96
TABLE 32: CHANGE MANAGEMENT SPECIAL CONSIDERATIONS.......................................................96
TABLE33: APPLICATIONS INTEGRATION MODES..........................................................................98
TABLE 34: INTRA-PACKAGE APPLICATION REQUIREMENTS.............................................................103
TABLE 35: APPLICATION CATEGORIES.......................................................................................104
TABLE 36: EXISTING APPLICATIONS STATUS IN TMS..................................................................104
TABLE 37: EXISTING SERVICES STATUS IN TEMPLES/INSTITUTIONS..................................................107
TABLE 38: ASSESSABLE INCOME BENEFITS TO SYSTEM................................................................110
TABLE 39: ASSESSABLE INCOME PROCESS DESCRIPTION AND RESPONSIBILITY..................................110
TABLE 40: GOOD FUND MANAGEMENT BENEFITS TO SYSTEM........................................................112
TABLE 41: GOOD FUND MANAGEMENT PROCESS DESCRIPTION AND RESPONSIBILITY..........................112
TABLE 42: TMS ACCOMMODATION BOOKING BENEFITS..............................................................114
TABLE 43: TMS ACCOMMODATION BOOKING PROCESS DESCRIPTION AND RESPONSIBILITY.................114
TABLE 44: EPIS OF TMS...................................................................................................... 163
TABLE 45: SCALABILITY PROVISIONS.......................................................................................164
TABLE 46: PERFORMANCE PROVISIONS....................................................................................164
TABLE 47: AVAILABILITY PROVISIONS.......................................................................................165
TABLE 48: RELIABILITY PROVISIONS......................................................................................... 165
TABLE 49: MANAGEABILITY PROVISIONS...................................................................................165
TABLE 50: USABILITY PROVISIONS..........................................................................................166
TABLE 51: LIST OF SCHEMES IN TMS PACKAGE DEPARTMENT.......................................................167
TABLE 52: LIST OF TEMPLES UNDER ENDOWMENTS DEPARTMENT..................................................169
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
Page
1.2. Vision
e-Pragati is not a project. It is large Program, with a long term vision for creating
a sustainable eco-system of e-Governance. The Vision of e-Pragati is stated
below:
"e-Pragati is a new paradigm in governance based on a Wholeof-Government framework, transcending the departmental
boundaries. It adopts a Mission-centric approach in its design
and implementation and seeks to realise the Vision of Sunrise
AP 2022, by delivering citizen-centric services in a coordinated,
integrated efficient and equitable manner."
e-Pragati is a framework to provide integrated services to citizens through a free
flow of information, and to usher in an era of good governance, characterised by
efficiency, effectiveness, transparency, and foresight. The different dimensions of
the vision of e-Pragati are described below:
Developmental
1. e-Pragati will be a catalyst for enhancing the effectiveness of
implementing various developmental projects and welfare schemes
undertaken by the government.
2. Planning and monitoring of public sector schemes and projects shall take
advantage of IT, GIS and satellite imaging technologies.
Aspirational
1. e-Pragati shall be an effective tool in realising the vision of Sunrise Andhra
Pradesh.
2. e-Pragati shall be rated among the best in the world and help Andhra
Pradesh achieve a high rank in global e-Governance Development Index.
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
3. Andhra Pradesh will focus on quality of life of its citizens with a special
emphasis on quality of Endowments, healthcare, skill development,
agriculture, infrastructure, and services.
Citizen-Centric
1. Citizens and businesses will have a seamless and smooth interface with
government.
2. Departments and government agencies interoperate with ease and
provide integrated services to citizens and businesses.
3. The medium of paper will be minimised in all G2C, C2G, G2B, B2G, and
G2G interactions.
Page
Inclusive
1. Digital divide will be adequately addressed, especially leveraging the
mobile technologies.
2. e-Pragati will
governance.
enhance
3. Citizen engagement
effectiveness.
will
realisation
be
of
participative
accomplished
with
and
ease
inclusive
and
cost
Technological
1. Government and citizens will be enabled to take advantage of cuttingedge technologies like SMAC and IoT.
2. Principles of open data, open standards and open APIs will be ingrained in
the designs of all information systems.
3. e-Pragati will ensure the right balance between information security and
privacy of personal data.
4. SI should propose suitable technical solution based on requirements.
Page
by
e-Pragati
would
enhance
the
2. e-Pragati will make the concept of single-window real and enhance the
ease of transacting with the Government.
3. The Certificate-Less Governance System (CLGS) will reduce significant
burden, both on the citizens and the Government departments, by
reducing/eliminating unproductive work.
4. Programs like e-Health, e-Endowments, e-Agriculture and e-Market shall
enhance quality of life and productivity as well as income of the citizens.
5. Direct Benefits Transfer will ensure hassle-free availability of the various
benefit programs of the Government.
6. Widespread use of e-Office and other productivity tools will enhance
transparency of public agencies.
Value to Society:
1. The implementation of e-Pragati will unleash a lot of potential in the
software, hardware, electronics and networking sectors. This will have a
significant extent of multiplier effect to the tune of 4 X.
2. e-Pragati, being based on open technologies, will open up new windows for
innovation and create IT and non-IT employment in various sectors.
3. The economic development of the State will be spurred by increased
productivity in all the 7 major sectors comprising the Sunrise AP Mission.
4. The successful implementation of e-Pragati is likely to motivate several
such initiatives across the country, as witnessed in respect of the CARD
and e-Seva projects pioneered by AP, and would lead to speedier national
development.
Page
A large and complex program like e-Pragati cannot make a radical impact
unless certain fundamental principles of Enterprise Architecture are adopted by
all the stakeholders, namely, the Government, the System Integrators and the
users. These are stated below. It is the responsibility of the System
Integrator selected for the implementation of the Temple Management
System, to meticulously observe and / or promote the observance of
these principles by the other stakeholders.
Principle #1: Uphold the Primacy of these Principles
These principles of information management apply to all organisations
within the Government.
Principle #2: Maximise benefit to the Government as a whole
All decisions relating to information management are made to provide
maximum benefit to the Government as a whole. Some organisations may
have to concede their own preferences for the greater benefit of the entire
Government. Applications and components should be shared across
organisational boundaries.
Principle #3: Information Management is Everybodys Business.
All organisations in the Government participate in information
management decisions needed to accomplish business objectives, and
implement such decisions with full commitment, devoting the right and
adequate resources. Respective Domain Owners and Managers shall
develop their own sub-architectures following these principles, and
federate the same to APSEA.
Principle #4: Government is a Data Trustee
Each data element has a trustee accountable for data quality. Only the
data trustee makes decisions about the content of data, and authorises its
modification. Information should be captured electronically once and
immediately validated as close to the source as possible. Quality control
measures must be implemented to ensure the integrity of the data
Principle #5: Establish Common Vocabulary and Data Definitions
Data is defined consistently throughout Government, and the definitions
are understandable and available to all users. Defining Metadata and Data
Standards (MDDS) within each domain assumes great significance.
Principle #6: Data is Shared
Data is shared across enterprise functions and organisations. It is less
costly to maintain timely, accurate data in a single application, and then
share it, than it is to maintain duplicative data in multiple applications.
Shared data will result in faster and improved decisions.
Principle #7: Data is an Asset.
Data is an asset that has a specific and measurable value to the
Government and is to be managed accordingly.
Page
1:
PRINCIPLES OF E -P RAGATI
Page
2: E-PRAGATI
Standard
Interoperability
Software Engineering
Documentation
Testing
Usability
IT Services
Mobility
Security
Document Management
Imaging
GIS
Localisation
Metadata
Master Data
Data Definition
Data
&Information
Exchange
Access, Presentation and
Style
COMMON MANDATORY STANDARDS
The technical specifications of the above standards can be accessed at the URL
http://e-pragati.ap.gov.in/bestpractices.html.
It shall also be the responsibility of the SI to upgrade the systems to the relevant
standards, whenever the standards are revised, during the currency of the
contract. It's part of the SIs responsibility to follow/specify the relevant
standards for upgradation of system.
Page
iii.
iv.
Sl.
No.
1.
2.
e-Pragati
Object
Package/
System
Module
3.
Sub-module
4.
Functional
Requirement
5.
Interface
6.
UML Diagram
7.
Report
8.
Services
Illustration / Comment
TM is for Temple Management System
TM01 for Pilgrim Service Applications in Temple
Management System
TM0101 for Pilgrim Verification Sub-Module in Temple
Management System
TABLE
3: E-PRAGATI
Page
Page
Section
classification
6(a) institutions
6(b) institutions
6(c) institutions
6(d) institutions
6(e) institutions
TABLE
4:
CLASSIFICATION OF INSTITUTIONS
Nature**
(SD/HoD/Trust/Socie
ty)
SD
Governing Body
HoD
Trust
Trust
Page
Sl.
No.
6.
Nature**
(SD/HoD/Trust/Socie
ty)
HoD
5:
NAMES OF
TMS
USER DEPARTMENTS
INSTITUTIONS
Sl.
No.
1.
Web site
http://www.apendowments.gov.in
2.
Sri
Varahalakshmi
Narasimha
Swamy
Vari
Devasthanam,
Simhachalam
http://simhachalamdevasthanam.net/
3.
http://www.apendowments.gov.in/srisa
ilam/
4.
http://www.annavaramdevasthanam.ni
c.in/
5.
http://www.durgamma.com/
TABLE
6:
WEBSITES OF
TMS
Page
FIGURE
1:
Further the integrated view of the Endowments Department stems from the
Whole of Government concept wherein there exist direct dependencies between
the primary domain departments and secondary domain departments to deliver
its services efficiently. This is shown in the below Figure:
Page
FIGURE
2:
Given below are the key objectives of the Temple Management System
departments.
Page
Sl.
No
.
Departm
ent/
Agency
Objectives
1. Endowm
ents
1.
Departm
ent
2.
3.
4.
5.
6.
7.
8.
2. Hindu
Dharmik
a
Parishad
3. State
Institute
of
Temple
Administ
ration
(SITA )
4. Institutio
ns/Templ
es
/
Mutts/ot
hers
Key Objectives
of different bodies of Endowments Department
To administer Hindu Temples, Mutts, Peetams and other
Charitable Institutions and Endowments
To ensure proper administration of these institutions and
apportioning
their revenue for which they were
established. Control, supervision and administration of
temples and charitable institutions.
To protect the properties of Hindu temples and other
charitable institutions.
Maintain 3-tier system of administration for temples and
Charitable Institutions
Temples with an annual revenue of less than Rs.2 Lakhs
are under the administrative control of Assistant
Commissioner.
Temples with an annual revenue of more than Rs.2 Lakhs
but below Rs.25 Lakhs are under the administrative
control of Deputy Commissioner.
Temples with an annual revenue of more than Rs.25 Lakhs
are under the administrative control of the Commissioner.
In the case of Mutts and Dharmadayams, the
Commissioner has administrative control irrespective of
their revenue.
1. To
7.
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
TABLE
7:
KEY OBJECTIVES OF
District
Srikakulam
Vizianagaram
Visakhapatna
m
East
Godavari
West
Godavari
Krishna
Guntur
Prakasam
Nellore
Kadapa
Kurnool
Anantapur
Chittoor
Total
6(a
)
(i)
0
1
6(a)
(ii)
6(b)
(i)
6(b)
(ii)
6(c)
(ii)
6(c)
(i)
6(
d)
6(
e)
TOTA
L
1
2
1
0
19
11
24
47
758
503
18
4
1
0
822
568
42
40
917
1013
16
52
129
149
1379
1740
13
14
138
230
1318
1716
1
1
0
1
0
0
1
0
14
11
6
9
4
6
5
7
12
12
9
6
0
7
11
1
69
72
39
42
22
37
12
31
102
131
663
1216
1581
1270
1126
1840
3701
1975
3315
2089
9
7
6
12
7
8
21
4
38
13
5
6(
d)
13
5
1
0
0
0
0
0
0
0
13
106
424
297
116
8
116
67
265
188
9
1426
2107
1633
1307
1882
3888
2075
3657
2383
4
6(a)
6(b)
6(c)
115
794
22788
Total No. of
Institutions
2
6(
e)
2
2383
4
23834
TABLE
8: FACT S HEET
Page
4.
7.
9.
11.
14.
15.
16.
17.
18.
20.
District
Name
Name of
Mutts/Trust/Temples/P
eetams
Head Office
Endowments Department
Srikakulam
DC/AC Office
Vizianagara
m
DC/AC Office
Visakhapatn
am
East
Godavari
West
Godavari
Krishna
DC/AC Office
Sri Varaha
Lakshminarasimha
Swamy Devesthanam
Sri Kanaka Mahalaxmi
Ammavari Temples,
Burujupet
DC/AC Office
Sri Veera Venkata
Satyanarayana Swamy
Devesthanam,
Annavaram
DC/AC Office
Sri Venkateswara Swamy
Devasthanam Dwaraka
Tirumala
DC/AC Office
Sri Durga Malleswara
Swamy Devesthanam
Sri Tirupathamma
Ammavari Devasthanam,
Penuganchiprolu
Guntur
DC/AC Office
Nellore
DC/AC Office
Prakasam
DC/AC Office
Kadapa
DC/AC Office
Kurnool
Ananthapur
22. Chittoor
DC/AC Office
Sri Bhramaramba
Mallikarjuna Swamy
Devasthanam, Srisailam
DC/AC Office
Sri Nettikanti Anjaneya
Swamy Devasthanam,
Kasapuram
DC/AC Office
Number of Officials/Staffs
Perman
Total
Tempora
ent
Staff
ry Staff
Staff
41
0/0
41
19
0/0
19
17
0/0
17
31
0/0
31
305
275
30
68
48
58
48
10
0/0
536
24
307
24
229
0/0
259
26
121
26
138
0/0
418
306
112
88
60
28
0/0
30
30
24
24
26
26
24
50
24
50
0/0
700
22
236
22
464
0/0
108
20
44
20
64
0/0
0/0
0/0
0/0
Page
Sri Kalahastheeswara
Swamy Devasthanam ,
Srikalahasthi
Sri Varasiddi Vinayaka
Swamy Devasthanam,
Kanipakam
TABLE
449
166
283
287
75
212
9: D ETAILED FACTSHEET
*Note:
0/0- Not Applicable
Online facilities provided through MeeSeva is not taken in account as it is not
in sync on real time basis.
Transaction Volume
Sl.
No.
1.
2.
3.
4.
5.
No. of
Institutions
Section
Total Pilgrims
Volume (Per day)
2,00,000 (25,000*8)
6(a) institutions
6(b) institutions
51
6(c) institutions
Not applicable
Not applicable
6(d) institutions
Not applicable
Not applicable
6(e) institutions
Not applicable
Not applicable
3,00,000 (6,000*50)
Total pilgrims
TABLE
5,00,000
Type of
Transaction
Seva/Darshana
m
Accommodation
Peak Load
TABLE
5,00,000
2000
9,00,000
SCOPE
*Note:
YoY growth of expected transactions is 10%. SI should design the system to meet
the requirements in the above indicative transactions peak load per day, as
mentioned in the table, and SI should meet the performance requirements
mentioned in the RFP
Page
years to facilitate the pilgrims. The Hindu religion and its institutions need to
be maintained and managed properly to provide world class facilities to
pilgrims. The development of Temple Management System is expected to
play a key role in the enhancing the pilgrim satisfaction and make the institutions
more efficient and transparent..
Andhra Pradesh has set its target to become one of the top three high
performing states in India by 2022 and achieve the status of the best state in
the country by 2029, and realise the vision of the Sunrise State of Andhra
Pradesh. Vision2029 hopes to impact the lives of every citizen in the State,
enriching and transforming it through well-coordinated small, large and mega
scale development programmes, executed as its seven development focused
missions. The endowments department aims to make Andhra Pradesh as a
preferred choice of pilgrims, creating an integrated and well managed /
maintained temples within the State. This is guided by the Honourable Chief
Minister's vision to:
Page
Page
3.2.2.
i.
ii.
iii.
iv.
Page
3.2.4.
Deployment Model
Considering the following factors, it is required that the Temple
Management System is deployed on a public cloud:
a. Elasticity of Demand: The load of Temple Management System will
be quite heavy in specific week days, Hindu festival season and
especially on sanctified days. It would taper down towards the rest of
year, as most of the services are related to the Temple Management
System.
b. Need for mobile access: The applications would be accessed by
Pilgrims/ Management staff of Temples and field department workers,
mostly on mobiles and tablets.
c. Need for cost-effectiveness: By its very nature, services in the
Endowments and allied sectors need to be less expensive to be
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
affordable, where charged. Cloud-based services would be costeffective in volumes. Therefore, cloud deployment model is suitable
and recommended for Temple Management System.
d. The nature of data: The nature of data handled in the Temple
Management System is not confidential or sensitive.
The SI shall implement a highly cost-optimised cloud-based solution, with
the following
requirements:
i.
ii.
iii.
iv.
v.
vi.
Page
FIGURE
Sl.
No
.
1.
Component
VPC & Network
Connectivity
2.
Security
Configurations
3.
Backup Operation
4.
Temple
Management
System
Deployment
VPC and BGP
Tunnels
5.
6.
7.
8.
2:
DEPLOYMENT MODEL
Comment
SI has to build a network layer for connecting
existing legacy application hosted in
SDC and
department access
SI has to study the existing security configuration to
integrate the new applications with GoAP Security
components
SI has to propose the backup strategy for service
availability and cloud access
SI has to start Temple Management System
development in consultation with Endowments
department
SI has to build secure tunnels between SDC and
Cloud provider for legacy application integration and
connectivity
with
APSWAN/AP
FiberNet
for
departmental access
SI has to coordinate with Cloud provider for
preparation of Compute and Storage block for
Endowments Package deployment. The required
compute and storage shall be elastic in nature
SI has to work with legacy application SI with help of
PMU to get the required APIs for integration, if any
Snapshot and Data Backup policy and data
availability shall be ensured and proof shall be
submitted with PMU
Page
Sl.
No
.
9.
10.
11.
Component
Comment
Directory Services
and OS Client
Temple
Management
System
applications
Monitoring
Applications
TABLE
A (To be retained)
B (To be enhanced)
Page
C (To be retired)
The existing SI shall provide required SOA interfaces for the applications
required to be retained / integrated into Healthcare Package framework
which includes support personnel, training and user manuals on these SOAs.
All green field Temple Management System applications shall be deployed on
public cloud. These have to be integrated with existing legacy applications
which were deployed in SDC. The applications deployed in cloud will
communicate with applications deployed in SDC through an aggregation
layer. Eventually, after the existing servers and storage hardware attains EOL
(End of Life), the hosted legacy applications may be migrated to cloud. SI
may propose an appropriate model for cloud migration (PaaS, IaaS). After the
PMU approves the model, the SI may raise a change request to perform the
migration. The access to State Data Centre (SDC) and applications will be
provided to System Integrator (SI) on need-basis.
Sl.
No
.
1
Component
Cloud
Endowments
Package
Applications
APSWAN
Comment
Endowments Package Applications need to be
deployed on cloud and a dedicated 10 Mbps VPN link
should be commissioned to integrate existing SDC
components. This link should be scalable as per the
demand.
The connectivity to all the existing centres, offices,
Page
Sl.
No
.
Component
Trust/
Agencies/Society
AP FiberNet
Disaster
Recovery
TABLE
Comment
and to the Internet will be made via existing APSWAN
network. After the implementation of AP FiberNet, it
will be available up to the panchayat level.
As a part of AP FiberNet project, all big Templets and
Trust offices will be connected through 10 to 100
Mbps bandwidth. All the end points like Trusts,
Agencies and Society will get connectivity to the cloud
through FiberNet to access Endowments Package
applications.
AP FiberNet shall be a highly scalable network
infrastructure to provide on demand, affordable and
end-to-end broadband connectivity of 10 to 20 Mbps
for all households and 1 to 10 Gbps for all institutions
under endowments department.
The SI should provide the BCP plan to meet the SLAs.
Page
1. The CapEx quoted shall not exceed 50% of the total cost of the
Package quoted by the bidder.
2. 100% of the CapEx will be paid component-wise, linked to the
milestones and deliverables and subject to satisfactory UAT at
each stage.
3. The OpEx, which is all-inclusive (license fee, cost of development
of the package, acceptance testing, commissioning, user training
and O&M during the project period) will be paid as per schedule VI
of Volume III of this RFP post-go live.
4. The OpEx will be linked to the SLAs to be defined for each of the
components.
5. There would be rewards and penalties defined in terms of timely
completion and performance against SLAs.
3.4.3.Revenue Model: Temple Management System is a societally
important project. Therefore as a basic state responsibility, the
expenditure is to be borne by the Government. However, it is
desirable to introduce a commercial element in some of the
components of the project for delivering premium services. Therefore,
the SI shall provide a Billing Module to measure and charge the
premium services consumed by each stakeholder through the TM
Package. The revenue model is specified in the Table 14 below:
Therefore, SI shall consider the following revenue models for
multitenant application design, application performance and
customisation requirements of Temple Management System - while
adhering to data privacy and protection standards in the global IT
industry. Please note that the revenues shall go to the department
and not to the SI, excluding incentives if any as mentioned in the
subsequent sections.
Sl.
No.
1.
Name of the
Project/Compo
nent
Sevas
2.
Description of
Revenue Model
No of
Subscribers
Tariff
Online booking of
seva tickets
Rs.5 per
transaction
Darshanam
Online booking of
Darshanam tickets
Rs.5 per
transaction
3.
Accommodation
Online booking of
Accommodation
4.
Temple
Management
System Front
Office Support
Module
Fully automated
temple
management,
Queue
management,
procurement,
auctions.
Rs.5 per
transaction
Fixed cost per
year. 6(a)
institutions-5%
6(d) institutions5%
6(e) institutions5%
Page
Sl.
No.
Name of the
Project/Compo
nent
Description of
Revenue Model
No of
Subscribers
Tariff
5.
Temple
Management
System
Integrated
Application
Module
Fully automated
accounting and
fund management,
facility
management,
Inventory
management.
6.
Departmental
services
Registration
process, DC
module, ePayments and
others
All officials of
Endowments
department will
use it.
Fixed
convenience
yearly charges of
10 Lakhs
TABLE
14:
ENDOWMENTS
PACKAGE DEPARTMENT
portal
are
e) The users who consume the chargeable services through the ePragati portal must agree to the terms and conditions set by the SI
in consultation with the Endowments Department. The Endowments
Department shall be the sole regulator of the Temple Management
System Services through the e-Pragati portal.
f) The users may consume the services directly from the TPAs viz.
tickets, bookings, content, materials and/or services (without using
the e-Pragati portal, by directly subscribing with the TPAs). In such
case, the SI or Endowments department has no role either in the
pricing and/or SLAs of TPA services.
Page
3.4.5.Incentive Model
In addition for developing the system, the system shall provide the
services specified in the service portfolio, the bidder is encouraged to
propose and develop additional revenue generating services for the
Temple Management System. These additional revenue generating
services in their proposed solution along with the projected number of
users/subscriptions/transactions that these services are expected to
attract as well as a tariff that shall be levied by GoAP. The service
charges collected will be deposited in the e-Pragati account. The
definition of revenue generated by the portal includes, but is not
limited to various charges levied on transactions conducted through
the Temple Management System and premium services offered by the
portal. The following is an indicative list of the same.
a. User convenience fees (for example, additional charges
levied for online payment transactions)
b. Registration fees
c. MIS and Analytics (for external (public) users)
d. Licensing fees for applications for private institutions
e. Advertising revenue
f. Subscription fees
The incentives will be paid to the selected System Integrator as per
the details given below:
A. Incentives for the existing services: The selected SI will earn
up to a maximum of 15% of the total contract value as incentives
of the net revenue generated from the revenue generating
services on achieving the threshold targets for the services
mentioned in Section 3.4.3. The incentive if any eligible, payments
will be computed and made at the end of each financial year.
B. Incentives for Premium Services: Revenue generated through
the premium services (Additional services which are not part of the
scope of the project) offered by the SI through Temple
Management System. These Incentives will be 20% of the total
revenue generated through premium services offered for the
entire duration of contract. For the eligible incentive if any,
payments will be computed and made at the end of each financial
year. The total incentive amount payable to the System Integrator
in any financial year shall not exceed more than 10% of the
contract value subject to maximum ceiling mentioned above.
The implications for the SI in terms of the development effort is
as follows:
1. Revenue Metering for Temple Management System shall be
developed by SI as specified below:
a) A Digital/Mobile Wallet (eWallet) facility shall be provided at the
portal level. The application shall use the Payment Gateway
application under e-Pragati framework.
b) The above eWallet shall be topped up by the users either online by
using net banking or debit/credit card services or through MeeSeva
centres.
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
3.
Page
iii.
iv.
v.
vi.
vii.
viii.
ix.
4.2.
i.
ii.
Page
iii.
iv.
v.
vi.
vii.
viii.
ix.
4.3.
ii.
iii.
iv.
4.4.
The e-Pragati Program attaches a very high importance to the process reengineering. The re-engineering shall adopt the approach provided in the ePragati portal. The result of BPR already done for identified processes is
provided in Annexure 3. In addition to the same, the SI may, during the
course of the designing SRS, identify all other areas needing BPR, especially
the customer-facing processes, and reform the same, in consultation with the
departments. Process re-engineering and forms re-engineering is
responsibility of the selected SI. The selected SI has to undertake these
activities as part of System Study phase and submit the FRS and get the
same approved by PMU.
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
4.5.
Forms Re-engineering
Page
propose the same as a Change Request and the same shall be handled by
adopting the Change Request process defined in the Terms and
Conditions of the RFP for the project. SI is responsible for provision of
licensed software to run the applications.
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
ix.
x.
xi.
xii.
xiii.
Page
xiv.
xv.
4.8.
Software Application Testing & Quality Assurance
The SI shall conduct unit testing and integration testing adopting the Use
Cases and testing methodology to be agreed upon as a part of the user
sign-off for the SRS. GoAP shall engage a panel of TPAs for conducting the
Acceptance Testing for each application. A detailed Testing and Quality
Assurance methodology to be followed by SI is given in Annexure 13.
Page
4.9.
Solution Documentation
The SI shall prepare/update the documents including the following
minimal set of Project Documentation:
1.
2.
3.
4.
5.
4.10.
User Manual
Training Manual
Operations Manual
Maintenance Manual
Administrator Manual
Details
Delivery of speedy and efficient services to the pilgrims, departmental
users and related agencies in relation to all the related services
Train the existing department users/employees (Train the Trainers) to
assist them discharge their duties effectively and efficiently
Encourage and help to improve the adoption rate for the usage of the
Temple Management System services, by employing traditional as well as
innovative techniques. To that end, implement measures:
For making it convenient for pilgrims, departmental users and related
agencies to utilise the services,
Educating the users in the relevant procedures
Use of Telugu & English in all interfaces with pilgrims
TABLE
15:
To meet the aforesaid objectives the SI will provide the Service Levels in
accordance with the performance metrics as more particularly described
in Nonfunctional requirements performance section in Annexure 8.
SI should develop the Standard Operating Procedures (SOPs), in
accordance with the ISMS, ISO 27005 & ITIL standards, for Temple
Management System. These SOPs shall cover all the aspects including
Infrastructure installation, monitoring, management, data backup &
restoration, security policy, business continuity & disaster recovery,
operational procedures. The System Integrator shall obtain sign-offs on the
SOPs from the department and shall make necessary changes, as and
when required, to the fullest satisfaction of GoAP. GoAP IT & IT related
polices and security policy shall be adhered.
SI shall deploy the TMS solution on a secured public cloud as per the
details given in section 3.2.4 meeting the requirements of TMS solution
Page
4.11.
Training need analysis of all key stakeholders must be performed and the
SI must develop the training plan in line with overall project plan. Section
9 provides detailed training and change management description .
4.12.
Implementation Strategy
The SI shall adopt a robust implementation model. In this regard, SI has to
implement the solution initially in all the 6A category temples and after
successful implementation SI has to implement in all 6B category temples.
SI has to implement the solution in 59 temples, which are classified in 6A
&6B temples
4.13.
BOM required for pilot is given in Annexure 14. SI is not responsible for
the provision of Internet Bandwidth. However, SI is responsible for
providing Wi-Fi access points. SI should provide comprehensive
warranty services for all the BOM components as specified in Annexure
14
4.14.
Data Migration: Testing of data migrated shall be carried by the SI
in coordination and supervision of PMU. Agreed defects identified during
testing shall be fixed by the SI prior to Go-live. As part of the Go-live,
Master data across all modules shall be successfully migrated. As regards
transaction data all open records as on go-live date to be migrated and all
legacy records for last 3 years prior to the go-live date and currently
25GB of data available with legacy application which needs to migrate
into new TMS application. Solution for data cleansing is also responsible
for SI for the data existing with the legacy applications
4.15.
As other e-Pragati packages may not be ready for integration by the time
TMS is ready for Go-Live, a well-defined criteria shall be in place to define
Go-Live event of TMS.
The PMU shall define different user scenarios in detail covering individual
applications and overall integrated scope of TMS application. Operational
Acceptance for the full TMS application shall be awarded by the PMU only
Page
if at least 98% of user scenarios are met by the SI ensuring the full
functionality.
In order to ensure effective completion/accomplishment of the above, the
PMU, in association with SI, shall carry out all the necessary operational
acceptance tests including but not limited to:
1.
2.
3.
4.
5.
6.
7.
8.
Functionality Test
Database Test
Integration Testing
Unit Test
System Test
Security Compliance
Stress test
Performance test
The PMU may accept and sign off on the TMS application only when it
deems that results of all tests are satisfactory, and that all requirements of
TMS application have been met with. The operational acceptance of the
system may be provided only when the proposed system has been
installed and configured at all sites as agreed upon during the design
phase, and detailed procedures of operating them have been carried out
by the SI in the presence of PMU staff.
SI should submit a report for obtaining OPERATIONAL ACCEPTANCE
after the Go-Live phase. The report should include the following:
1. All required activities for the TMS application project delivered by
the SI and accepted by the PMU
2. All required system functionalities of the TMS project delivered
by the SI and accepted by PMU
3. All required documentation for the TMS project prepared by the
SI and accepted by PMU
4. All required training for the TMS project imparted by the SI and
accepted by PMU
5. All identified shortcomings/defects in the Systems have been
addressed to PMUs complete satisfaction
6. All the required Project Documents (For example: manuals, SOP)
have been submitted and accepted by the PMU
7. No. of user that have access to the System and are using the
System for the respective functional areas
8. Any other work which is required to be complied with by the SI.
The application has to be free from any security threat and the SI
shall have to produce the third party audit certification for the
same.
Based on the above and only after being completely satisfied that at least
a minimum percentage of all the users of internal stakeholders have
access to the System and are using the System for the respective
Page
4.16.1.
II.
III.
Page
V.
V.
VI.
Since the Project aims to reuse the common infrastructure created under
AP FiberNet, APSDC, APSWAN, MeeSeva, the selected SI System
Integrator will also be required to coordinate with AP FiberNet, AP SDC,
Page
4.16.3.
Page
Tasks expected:
1. Ticket mapping and allocation: According to the severity, the ticket
should be given the priority level. Also it should map the ticket to the
appropriate personnel for the resolution.
2. Updating the status: Update the status of ticket.
3. It should be able to log and escalate user interactions and requests.
4. It should have an updateable knowledge base for technical analysis
and further help end-users to search solutions for previously solved
issues.
5. Status of registered calls with interface for Call centre, using which call
centre can inform the status to users over phone.
6. Historical report indicating number of calls, time to resolve, status for a
specified period of time.
All relevant infrastructure and supporting system software required for the
deployment and operation of the helpdesk is to be provided by the
selected Bidder.
All relevant infrastructure and supporting system software required for the
deployment and operation of the helpdesk is to be provided by the
selected Bidder as per the specifications given below. The system
deployed by the SI shall comply with ITIL and ISO 27005 service
specifications.
4.16.4.
Sl.
No.
1.
2.
3.
Details
SI shall implement and manage the Temple Management System in
accordance with the service level metrics defined for the project in SLA.
SI shall coordinate and provide complete support to the department
SPOC and/or the nominated agency in conducting the solution
acceptance testing and certification.
SI shall provide operational support and maintenance services for a
period of 5 Years from the Go-Live date of the complete roll-out for
overall operations and maintenance at Temple Management System
stabilisation,
software
solution
maintenance,
IT
infrastructure
management, system administration, security administration, database
administration, network administration and end-user problem resolution.
The operational support will have to ensure that the Temple
Management System is functioning as intended and meeting all the
desired outcomes and service levels.
Page
Sl.
No.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Details
SI is required to train the identified staff (Train the Trainers) who will be
associated with the Temple Management System, that includes all the
personnel (Private & Government) and those identified Endowments
department. SI shall also be responsible for re-training the staff
whenever changes are made in the system and/or personnel.
SI shall be responsible for preparation of documents including User
Manuals, Operations Manual, Maintenance Manuals, Administration
Manual, Security Manual, and others (if any) as per acceptable
standards.
The SI shall provide warranty for the entire Temple Management System
including all the items supplied as part of the contract, for a period of
five years commencing from the date when the system is declared Golive. The terms of warranty should include that the solution supplied
under this Contract shall have no defect arising from design or
workmanship or from any act of omission or commission of the SI or that
may develop under normal use of the supplied solution.
SI shall provide a staging environment for testing of changes/ updates/
patches before applying them on production environment
SI shall give suitable access to IT&C Department Administrators, and/or
support System Integrator designated by Endowments Department, to
tools implemented/ utilised by SI for monitoring infrastructure
components (Server, Network, SAN.), and their operations, system
related events, and SLA measurement/ monitoring.
Diagnostic reports and software programming should be available
remotely (via a browser and VPN).
The SI shall include the equipment, software, and training required,
along with a description of the software used, for administration.
The routine maintenance procedures, troubleshooting, loading hardware
and software revisions, patches shall be performed without taking the
system(s) out of service by SI. Routine maintenance functions must be
performed without causing any downtime for the system users.
The core system(s) should use self-diagnosing software for detecting and
logging of component failures. It should have the ability to initiate an
alarm that can be sent to the support System Integrator and the Temple
Management System operational technical personnel by SMS and email.
The SI is expected to up to date on changing policies, new funding
streams, innovations and best practices. In, addition, the SI can describe
any other value-added services it can provide in addition to those
specified within the RFP. It is the SIs responsibility to inform the State,
and enrolled providers if appropriate.
The system management solution must include a mechanism to monitor,
measure, and troubleshoot system and generate system performance
reports
TABLE
4.17.
16:
OPERATIONS
&
MAINTENANCE
Deliverables
The following outlines detailed deliverables expected from the SI, including
timelines. PMU will be created for each package with a Subject Matter Expert
(SME) from the Endowments Department and PMU will be made responsible
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
for the sign-off of deliverables. The deliverable time lines are defined in the
Volume III.
Sl.
No
.
Phase
Deliverable Description
Page
Sl.
No
.
Phase
Deliverable Description
Management System.
3.
f
g
h
i
j
k
(SRS)
4.
Submission
Solution
Architecture
Documents
of
5.
Submission
of
Solution
Design Documents
iii.
Page
Sl.
No
.
Phase
Deliverable Description
the Application
iv.
v.
vi.
vii.
Data Dictionary
viii.
ix.
x.
Security design
Machine Configuration
iii.
Test Assumptions
iv.
v.
Page
Sl.
No
.
Phase
Deliverable Description
components
h. Deployment architecture covering Network,
Servers, Storage, System Software
i. Data backup & recovery strategy
j. Integration approach with e-mail, Helpdesk
services of GoAP
k. Software/
Hardware
Configuration
Management Plan
Database Backup and Management Policies
Implementation Phase
6.
Submission
of
Implementation Plan
7.
Completion of TMS
Development
Unit Testing
ii.
Integration Testing
iii.
System Testing
Page
Sl.
No
.
Phase
Deliverable Description
fulfilled requirement
g. Application Readiness Report, Development
completion
report
including
minimum
following:
i.
Source code (soft copy)
ii.
Report formats (soft copy)
iii.
Test scripts (soft copy)
iv.
Databases (soft copy)
v.
Data digitized and Migrated (soft copy)
vi.
Executable files (soft copy)
vii.
Product CDs
viii.
Other relevant documents deemed
necessary
h. Configuration management strategy
8.
Completion
Migration
cleansing
of
Data
and
9.
Completion of User
Acceptance
Testing
and Third Party Audit
Expectations
from
various
Temple
Management System stakeholders, how the
change impacts them.
11. User Training
a. Updated Training Plan.
Sensitization training
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
Sl.
No
.
Phase
Deliverable Description
Basic computer awareness
Application administration training
Functional user training
b. Training manuals and schedules.
c. Training Feedback forms (Post Training
sessions).
d. Training effectiveness score (based on
feedback from participants).
Deployment Phase
12. Delivery
&
deployment of the
required IT equipment
(including
software,
hardware & network
devices)
4.18.
a.
b.
c.
d.
e.
17: TMS
PACKAGE DELIVERABLES
IT Service Delivery
Page
Page
5. Application Architecture
5.1.
The following are the design principles that have been considered while
conceptualising the Temple Management Package solution:
1. Design applications, modules, and components for REUSE
2. Develop once, use many times
3. Design customer-centric views of services
4. Design to scale
5. Develop interfaces for integration by using SOA principles
6. Use the database schemas of e-Pragati core hubs
7. Ensure maintainability of ALL Interfaces
Figure 4 illustrates a holistic view of various applications that are to be
developed, designed, and integrated for the Temple Management Package.
Note: The list of services, modules depicted in the picture is not a
complete list. Please refer to Annexure 1 Inter Package View for
complete list of Application services, and Annexure 4 for Functional
Requirements of Modules and Sub-Module.
Page
FIGURE
3:
SI shall develop only the modules identified under Tier 3 of the e-Pragati
Temple Management package (Temple Management System). The SI also
needs to develop web services/interfaces to connect and share data with
Tier 1 and Tier 2 applications as necessary.
The Logical View of Temple Management System is explained as below:
1. The Views are designed to consist of a number of customer-centric
views that interact with the 3 tiers through appropriate Service
Orchestration. The SI Selected for the Temple Management System has
to design and develop these views. Please refer Table 18 for more
details on the various views.
2. Tier I: The Tier I represents a set of 15 Applications in the Portfolio of
e-Pragati that are required to be accessed by the users of Temple
Management System in their day-to-day operations. These e-Pragati
Applications fall in different packages of e-Pragati, assigned to different
SIs for implementation. The following requirements are specified in this
regard.
a. The responsibility of the SI selected for the Temple Management
System is to configure each of the applications to suit the
requirements of the users of Temple Management System. Refer
Table -18 for more details on the various Views.
b. The users can be internal to Government, who need to, access
applications like CFMS, HRMS, Scheme Management (e-Pathakam),
DataLytics OR can be Citizens/Pilgrims, who need to access
applications like Dial.AP, Mana Rashtram and MeeSeva, OR
Businesses, who need to access applications like Works
Management.
The integration requirements are listed under Annexure 1.
c. There is a dependency of the SI of Temple Management System on
the SIs of the other packages. GoAP shall facilitate a close
coordination and sequencing of the various implementations to
avoid any issues arising out of such dependencies.
3. Tier-II: Tier-II consists of components / functionality of Temple
Management System that needs to converge with e-Pragati Portal so that
the user can access the Temple Management System Application through
the single-one-stop user interface which is the e-Pragati Portal using
Single-Sign on.
About e-Pragati Portal: e-Pragati Portal is envisaged to serve as a first
stop to discover all Government services/data and shall be an information
gateway to citizens & residents, government officials, businesses and nonresidents. It shall also serve as a repository of enterprise architecture
artefacts (State Enterprise Architecture).
The citizen shall be able to navigate to various applications such as
Temple Management System from the options available under
Government Menu of e-Pragati Portal.
Below are the components that need to converge with e-Pragati Portal and
the envisaged approach for the same.
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
User Management
i.
All the users registered in Temple Management System
Application/Portal such as pilgrim, trustees, staff and management
users of temples and so on shall converge into e-Pragati Portal user
management to facilitate Single-Sign on.
ii.
Green Field Applications - The Green field (new) applications that
are being developed as part of this Temple Management System
shall use the Global Identity and Access Management (IAM) for
authentication. This shall be made available as part of e-Pragati
Portal to the SI.
e.g. When the user registers in the respective Temple Management
System application, the application shall create the user in the
Global IAM with the user credentials, user role (pilgrim, trustee),
application
name/repository
(Temple
Management
System,
Knowledge Management, Skills Management) using the IAM APIs in
a secured manner. The same shall be used for authenticating the
user either in e-Pragati Portal or in the Temple Management System
applications. (This includes centralised APIs for updating the
passwords as well.)
iii.
Single-Sign-On needs to be configured between the e-Pragati Portal
and the Temple Management System Applications to enable the
users to navigate from e-Pragati Portal to Temple Management
System Applications without re-login.
iv.
However, the control of the pages, resources and services that are
to be rendered/served within the Temple Management System
applications will reside in the individual Temple Management
System applications/portals.
v.
The individual applications can further have granular user sub
groups defined in the application if needed for role-based access to
pages.
vi.
Brown Field Applications - For Brown Field (existing) applications,
the feasibility has to be checked if the single-sign-on can be
configured between the global IAM and the current authentication
mechanism used in the existing application. In case of infeasibility,
the existing users have to be reconciled and perhaps a
wrapper/filter has to be developed at the existing application to
facilitate, interpreting the SSO token with the processing logic to
identify/map to the right user within the existing application, so that
the user need not re-login.
(The SSO token is an encrypted token that has sufficient data to
identity the logged in user details. This is shared in the request by
the originating application).
Notifications & Alerts
i.
The critical Notifications & Alerts pertaining to Temple Management
System which are relevant to wider audience such as citizens needs
to be published in e-Pragati Portal in addition to Temple
Management System Portals.
ii.
A user interface from e-Pragati Portal or perhaps a service contract
(web service) shall be made available to the SI for publishing the
notifications/alerts. The notifications/alerts are moderated by ePragati Portal admin before publishing the same.
Services Dashboard
e-Pragati Requirements Specification Document Temple Management System
of 216
Page
i.
ii.
iii.
iv.
Page
Search
The search keywords pertaining to Temple Management System
applications shall be published as a service which shall be used by
e-Pragati Portal to direct the user to relevant Temple Management
System Application at a high level. The granular search can still be
embedded in the Temple Management System Applications.
4. Tier-III: Department-specific Modules & Sub-modules These are the
Modules specific to respective Departments. Figure 4 depicts the
Department Modules and its Sub-Module.
The Functional Requirements of the Department Specific Modules and submodules of Temple Management System are described in Annexure 5.
Refer Service Portfolio in Table 20 for the complete list of services and
their descriptions/definitions. It is the responsibility of the SI to design,
develop and deliver all these services, duly complying with the defined
service levels.
FIGURE
5.2.
4:
&
SUBMODULES
Architecture Overview
Page
Figure 5 illustrates the suggested system design for the development of all new
applications.
However, considering the futuristic vision of e-Pragati and the array of new
cutting edge technologies which will be leveraged the department SI can propose
suitable technical solution based on the requirements. Usages of COTS / industry
proven solutions are encouraged as long as they adhere to the principles &
standards of e-Pragati.
FIGURE
5:
Page
iii.
iv.
v.
vi.
vii.
viii.
ix.
The services offered via mobile shall be made available via. Mobile app
say mTemple
Services that shall be hosted in AP p Store. The APp
Store will be made available to the SI for configuration and integration of
the same.
The various modules / sub modules in Business Logic Layers shall be
developed as APIs. The API has to be designed at the granular submodule/functionality level i.e. fine grained and need not be at the module
level. The API shall operate on specific domain objects and shall not
depend on request/response objects of Presentation Layer. (E.g.
Accommodation Booking API shall accept the inputs in the form of Person
object and Accommodation object). It should be possible to easily expose
this re-usable APIs as services when required.
The APIs shall be
orchestrated as needed for Presentation Layer to form a Business Service
that is course-grained.
The APIs in the Business Logic Layer shall be re-used by the UI in mobile
apps. The APIs shall be perhaps exposed as REST APIs (supported by json)
for consumption by Mobile Apps Presentation/UI Interface. E.g. Pilgrim
Registration API shall be used by the Temple Services Mobile App for
Registration purpose.
It is suggested that the web portal be developed using responsive design
concepts and keeping in view the Mobile First Strategy.
PDAs (Hand Held devices) will be used by the staff of Temples for ticketing
and booking purpose.
An MADP (Mobile Application Development Platform) shall be used to
create cross platform mobile apps that are portable across iOS, Android
and Windows.
The Temple Application shall integrate with other e-Pragati applications
via. e-Highway for certain functionalities. Refer Annexure -1 Inter
Package Integration View for more details on the Integration View and
type of Integration.
The following section provides a brief description and suggested
guidelines for the above logical layers. SI can propose suitable technical
solution based on the requirements as per industry standards and formats.
5.2.1.
i.
ii.
iii.
iv.
v.
Presentation Layer
The presentation layer acts as the user interface layer and serves as
a single point entry to the underlying business application. It
consists of various views/pages that are accessible to various
users.
The portal shall be accessible from multiple access channels namely
desktops, smart phones, tablets and kiosks and shall support unified
electronic accessibility.
Based on the logged in user type and role, appropriate views are
displayed and accessible. This layer handles session management.
There are views common to all users and few specific based on the
user type. Role based access shall be configured to facilitate the
same.
The various categories of users (stakeholders) shall be able to
access the common services for that category or premium (paid)
services, directly from the home page of the view, through
appropriate, user-friendly navigation.
The SI in consultation with the line departments shall identify the
various premium paid services that can be offered during the SRS
Page
vi.
vii.
viii.
phase and the same will be approved by the PMU. The tariff or the
services charges levied for these services will be determined by the
government (line departments).
Usability - The Portal/UI shall have very good user experience
enabling smooth usability, customer journey and use of lean web
technologies. The users shall be able to customise their views based
on personal attributes and needs, for better organising workspace
and display of information if required.
The search shall be supported with advance search options. The
various search options shall be obtained and detailed as part of SRS
for the necessary implementation.
Localisation All citizen/pilgrim facing interfaces in the application
shall provision for bilingual support (Telugu and English).
Below is the indicative list of views in each of the Portals based on user
type.
Category
Common Views
Citizens
Pilgrims
Patashala Users
Trustees
Staff of Temples
Vendors
Department
Users
Senior
Management
Administrator
18:
Page
ii.
iii.
iv.
v.
vi.
2.
3.
4.
5.
Components
Description
Configuration
Page
Sl.
No
.
Components
6.
Caching
7.
Tagging
Metrics
8.
Personalisatio
n
&
Description
the Department.
The master/reference data should be cached during
startup of the server for better performance. This
framework component should provide APIs to put objects
in
cache,
remove
objects
from
cache
and
invalidate/refresh the cache (without the need of server
restart). SI shall propose suitable technical solution
based on the requirements.
This framework component should provide APIs to enable
the developer to invoke the necessary analytic product
APIs.
The user shall be able to personalise the site by selecting
the information and services that are of their interests
and organise the presentation in their personal
workspace.
TABLE
19:
Page
5.2.5.
5.2.6.
Page
6. Business Architecture
The state of Andhra Pradesh attaches great significance to the Endowments
Sector. The Temple Management System consists of multiple applications which
work across a score of external e-Pragati applications to deliver value to the
stakeholders in the Endowment Sector. The core stakeholders are the pilgrims
and staff of temples who are supported by the endowment institutions,
Endowment department and other departments. The end value derived to the
pilgrims is amply demonstrated by the diagram below:
Below Figure 6 illustrates the life cycle of a pilgrim who avails services of Temple
Management System:
FIGURE
6:
Page
FIGURE
7:
BIG PICTURE OF
Page
FIGURE
8:
Page
Page
6.1.
Functional Requirements
The selected SI shall coordinate with the stakeholders for detailed system study
and interact with users of the departments, who uses Temple Management
System, for the preparation of functional and system related requirement
documents. The SI has to understand that the functional requirement
specifications stated in this document are the minimum module requirements
and wherever further functionalities are required, it shall be addressed in
consultation with the stakeholders involved. Therefore, the SI shall develop
requirements and system design documents after studying the G.Os, processes,
procedures, existing forms and templates. To independently design and
implement the Temple Management System for Endowments Department- in
concurrence with the Departments that uses the Temple Management System.
The minimum functional requirements are given in the annexures as follows:
1. Functional Requirements of Common modules of e-Pragati consumed by
Temple Management System - (Annexure 4)
2. Functional Requirements of Common Modules & Sub-modules of Temple
Management System - (Annexure 5)
3. Forms Re-engineering Requirements of Common Modules & Sub-modules
of Temple Management System - (Annexure 6)
4. MIS Reporting Requirements - (Annexure 8)
Page
6.2.
The essence of e-Pragati and the Temple Management System is to deliver services to pilgrims efficiently and
conveniently. It is necessary to design all the systems and sub-systems around the services. The list of services
currently targeted, as common to all institutions of this department, or and Service Levels are given in Table 20. It is
the responsibility of the SI to design, develop and deliver all these services, duly complying with the defined service
levels.
Given below is the list of Common Services of Temple Management System, Service type and Service Levels
(mapped to Modules & sub-modules).
Sl.
Pilgrim Service
No.
Pilgrim Registration
1
Submission of
application form and
other details for
Unique ID
(Pilgrims/Donors/
NGOs)
2
Activation of "Unique
ID"(Pilgrims/Donors/
NGOs) for online
registration
Availability for tickets
3
Seva
Service
Code
Module
Type of
Service
Service Level
TMS001
Pilgrim Information
Management
Transactional
(Without
payment)
TMS002
Pilgrim Information
Management
Transactional
(Without
payment)
TMS003
Informationa
l/
Transactional
TMS004
Informationa
l/
Transactional
Darshanam
Sl.
No.
5
Pilgrim Service
Accommodation
Service
Code
TMS005
Module
Accommodation
Type of
Service
Informationa
l/
Transactional
Service Level
Registered User should be
able to access the required
information in portal within 3
minutes. The booking should
be done.
Booking for Individual or Package of services - Arjitha Seva, Darshanam, Accommodation, Tonsuring
and Annadanam
6
Advance booking
TMS006
All Pilgrim facing
Information/T Registered User should be
modules ransactional able to access the required
Accommodation , Seva
information in portal within 5
and Darshanam,
minutes. The booking should
Kalyankatta,
be done.
Annadanam, Pilgrim
Information
management, Pilgrim
tracking, Call centre,
Complaints
management
7
Current booking
TMS007
All Pilgrim facing
Informationa Registered User should be
modules l/Transaction able to access the required
Accommodation, Seva
al
information in portal within 5
and Darshan,
minutes. The booking should
Kalyankatta,
be done.
Annadanam, Pilgrim
Information
management, Pilgrim
tracking, Call centre,
Complaints
management
Information services
Accommodation module
8
Type of rooms and
TMS008
Accommodation
Informationa Registered User should be
amenities provided
module,
l
able to access the required
information within 5
minutes.
9
Room Allotted /
TMS009
Accommodation
Informationa Registered User should be
Location
module,
l/
able to access the required
Transactional information within 5
minutes.
10
Confirmation for the
TMS010
Accommodation module Informationa Registered User should be
Caution Deposit
l/
able to access the required
e-Pragati Requirements Specification Document Temple Management System Page 80 of 216
Refund
Transactional
information within 5
minutes.
Registered User should be
able to access the required
information within 5
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.
TMS011
Informationa
l/Transaction
al
12
TMS012
Informationa
l
13
TMS013
Informationa
l
14
TMS014
Informationa
l
TMS015
Informationa
l
Annadanam
16
Slot allotted
TMS016
Annadanam module
Informationa
l
Tonsuring
17
Tonsurer allotted
TMS017
Kalyankatta module
Informationa
l/
Transactional
TMS018
Transport Management
Informationa
l/
15
Transport
18
Tour Packages Places covered,
Books
20
List of
books/calendar/
Diary and associated
articles available in
different languages
and cost
Transactional
TMS019
Transport Management
Informationa
l
TMS020
Informationa
l/
Transactional
information within 5
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 5
minutes.
Laddu Coupons
21
Coupon validity for
laddu collection,
details of cost of the
Coupon, No. of
Laddu Offered,
Donors
22
Total services availed
in a year along with
details of people
accompanying
Donation Services
23
Donation by Donors
Queue management
24
Darshanam/ Waiting
time before entering
the VQC
25
26
Information on the
pilgrim inflow / total
pilgrim arrival for
Darshanam, Seva,
Accommodation,
Annadanam and
Kalyankatta
Caution Deposit refund
27
At Seva counter Based on validity
TMS021
Informationa
l/
Transactional
TMS022
Informationa
l
TMS023
Transactional
TMS024
Queue Management
Informationa
l
TMS025
Queue Management
Informationa
l
TMS026
Queue Management
Informationa
l
TMS027
Accommodation
module,
Informationa
l/
Room management
module
Transactional
information within 5
minutes.
Transaction
al
Transaction
al
TMS030
Transaction
al
TMS031
Transaction
al
32
TMS032
Transaction
al
33
Purchase of Laddu
Coupon
TMS033
Transaction
al
TMS034
Complaint
Management
Transaction
al
(Without
30
Booking for
accommodation
Complaints / Grievance
34
Lodging a
Complaint /
grievance
35
36
System generated
acknowledgment
number for the
complaint registered,
to track the status of
the complaint on
internet
Update for the action
taken
TABLE
20:
TMS035
Complaint
Management
payment)
Information
al
TMS036
Complaint
Management
Information
al
LIST OF COMMON
OF
minutes.
Registered User should be able
to access the required
information in portal within 3
minutes.
In addition to the above Pilgrim facing services, the following internal services of Temple Management System shall
be delivered by the SI as part of the solution.
Sl.
Service
Service
No.
Code
Temple Lands Management
1
Information on
TMS037
Temple Lands
Module
Type of
Service
Service Level
Informational
Estimation of Land
Value
TMS038
Informational
Verification of Land
assigned for Lease
holder
Collection of Lease
amount for Leased
Lands
Allotment of Land for
Lease holders
TMS039
Informational
TMS040
Transactional
(payment)
TMS041
Transactional
(payment)
4
5
Sl.
No.
Service
Service
Code
Module
Type of
Service
Service Level
within 3 minutes.
Informational
/
Transactional
Collection of amount
from Shops
TMS043
Informational
Verification of
allotted shops
TMS044
Informational
Informational
Informational
TMS047
Informational
/transactiona
l
Information of
Temple Revenue
TMS048
Informational
10
Information on
TMS049
Assets & Fund
Revenue
Management
expenditure
Temple Human Resources Management
11
Recruitment of
TMS050
Human Resources
Temporary staff
Management
Informational
Transactional
Sl.
No.
Service
Service
Code
Module
Type of
Service
12
Application for
Provide training for
Archakas
TMS051
Human Resources
Management
Transactional
(Nonpayment)
13
Supply of material to
staff
TMS052
Human Resources
Management
14
Application for
schemes (Archakas
welfare fund)
TMS053
Human Resources
Management
Transactional
(Nonpayment)
Transactional
(Nonpayment)
15
Application for
transfer of temple
for archakas
TMS054
Human Resources
Management
Transactional
(Nonpayment)
16
TMS055
Human Resources
Management
Transactional
(Nonpayment)
TABLE
21:
LIST OF
INTERNAL S ERVICES
OF
Service Level
and apply
User should be able to access
the required information and
process in portal within 3
minutes
User should be able to access
the required information in
portal within 3 minutes
User should be able to access
the required information and
apply in portal within 3
minutes
User should be able to access
and get the required
information and apply in
portal within 3 minutes
User should be able to access
and get the required
information in portal within
1 minutes
6.3.
FIGURE
9: E -PI
FRAMEWORK
The e-PIs are outcome oriented whereas the KPIs are process and output oriented.
SI may use balanced scorecard or any other framework to achieve the service
delivery measurement. The following table gives the list of top 6 e-PIs for the
Temple Management System:
The following table gives the list of KPIs of the Temple Management System:
Sl. No.
1.
2.
3.
4.
5.
6.
Name of the
Department
Endowments
Department
TABLE
KPIs
Pilgrim Amenities
Web pilgrim Services
Facility Management(sanitation) Services
Annadanam
Aarogyadanam
Vidyadanam
The detailed methodology for computing the KPIs and e-PIs will be provided on the
e-Pragati web site (http://e-Pragati.ap.gov.in/).
Data Architecture
Exhibits below capture conceptual data models for Temple Management System).
Conceptual model captures key data entities, concepts, and relationships in Temple
Management System. This model will inform development of detail level data
models Logical and Physical Data Models.
FIGURE
7.3.
Data integration is realised by Batch, ETL, and near real-time methods (event-driven
architecture). e-Highway will facilitate near real-time integration. The system will
adapt Service Oriented Architecture concepts and provide Data Services for
frequently used queries and updates.
FIGURE
Integration
Databases
Land Hub + GIS Hub
Temple
Management System
11: TMS
Integrati
on
Method
Web
service
Integration
Databases
People Hub
Temple Management
System
DataLytics
Temple Management
System
Health Department
Database and Other
Department-level
Databases
Integrati
on
Method
Web
service
ETL
Web
service
7.4.
INTEGRATION REQUIREMENTS
Master Data
Master data represents the business objects which are agreed on and shared across
enterprises. Department level master data includes objects that are shared between
different applications within a department. State-wide master data are objects that
are shared across departments.
Common master elements will be captured and made available on Data Hubs.
Department specific master data will be captured in department databases. Temple
Management System related master data has been identified and listed in a
separate document. This document will be made available to the System Integrator.
7.5.
Sl.
No.
8.
9.
10.
11.
12.
7.6.
Table 24 below gives Data Architecture compliance requirements and roles and responsibilities of GoAP and SI.
Please note that the term GoAP encompasses departments, existing SIs, and e-Pragati enterprise architecture
team.
Sl.
No
.
1.
Data Architecture
Compliance
Requirements
Standard schemas
shall be published for
all data entities.
2.
Data access
requirements shall be
defined clearly based
on roles,
responsibilities, and
need to access data.
3.
Providers and
consumers for each
data entity shall be
defined clearly.
GoAP Responsibilities
SI Responsibilities
Sl.
No
.
4.
5.
6.
7.
8.
Data Architecture
Compliance
Requirements
Metadata and data
standards (MDDS) shall
be followed. At each
domain level,
metadata and
reference data
standards shall be
used if available,
otherwise they shall be
defined.
Target application shall
use core data only
from e-Pragati data
hubs.
GoAP Responsibilities
SI Responsibilities
Data lifecycle
management plan shall
Sl.
No
.
9.
10.
11.
Data Architecture
Compliance
Requirements
be in place and
implemented.
Databases shall be
scalable in terms of
total space, number of
tables, views and
users.
Data integration shall
be maintained
between related
entities by defining
primary keys and
secondary keys
relationships.
The target application
shall ensure that all
relevant data specific
reference
architectures,
architecture patterns,
best practices and
standards from
national and global
level are followed,
wherever they are
applicable.
GoAP Responsibilities
SI Responsibilities
policies
2. Ensure relevant best practices are
incorporated, and standards are met
3. Create
template
for
capturing
lifecycle management requirements (
A template is provided is provided in
e-Pragati
Enterprise
Data
Architecture document)
1. Review
and
validate
scalability
requirements
specified
in
this
document
2. Ensure that the solution meets
scalability requirements
1. Develop Logical and Physical data
models
2. Ensure
referential
integrity
is
maintained between various datasets
None
None
None
TABLE
25:
1. Data Capture Methodology: The data capture methodology can be accessed at the following URL - http://epragati.ap.gov.in/projectartifacts.html
2. Data Life Cycle Management: The Data Life Cycle Management document may be referred at the following URL http://e-pragati.ap.gov.in/projectartifacts.html
8. Technology Architecture
8.1
8.2
FIGURE
13:
The components of the Technology Architecture are described in the below Table:
Technology
Component
External
Security
Layer
Requirement
Internal
Security
Application
Cluster
Database
Cluster
VNA
Repository
(PACS)
e-Highway
Centralised
Security
System
Centralised
Monitoring
System
Mobile/Tablet
users
Web Layer
Technology
Component
Data Backup
Requirement
8.3
Sizing Requirements
8.4
Security Architecture
FIGURE
12: E -P RAGATI
The following Table 27 describes the above framework briefly and scope of SI w.r.t
the aforementioned framework. In case, the deployment model has been chosen as
public cloud environment, the SI shall ensure that these requirements are met by
leveraging inbuilt security capabilities that shall be provided by the cloud service
provider, and also by procuring any third party tools in case of need at SI own cost.
Sl.
No.
Security
Layer
1.
Foundation
2.
Process
Component Description
a. Security Policies, Standards and Guidelines: These are
the high level guidelines that will govern the systems
design, development and operations that cut across
various domains of the Government. A draft/approved
on GoAP security policies document will be provided,
which needs to be adhered by SI, while implementation
of Endowments package. e-Pragati IT security standards
and guidelines are available at e-Pragati website.
b. Risk Management: This deals with the threats that
exploit the vulnerabilities against the assets possessed
by the Department/Government, by taking counter
measures.
a. ID entity Management: This component deals with
authentication, authorisation and auditing functionality
that is relevant to this package. The common ID entity
and Access Management (IAM) component will be part
of Core Package/e-Pragati Portal implementation.
However, the SI is responsible to implement/customise
Sl.
No.
3.
Security
Layer
Infrastructur
e
Component Description
authentication and authorisation functionality specific to
Endowments Package and integrate the same with Core
Package/e-Pragati Portal IAM component to enable
Single Sign-On (SSO) functionality. The section below on
Access Control describes the IAM integration approach
in detail.
b. Threat Management: This component deals with
viruses, Trojans, warms, malicious hackers, intentional
and unintentional attacks on the system, and force
majeure. The SI need to design a detailed threat model
specific to Endowments Package and deploy all required
tools and processes to address envisaged threats to the
system, namely security monitoring and incident
management, firewalls, cryptography and forensic
analysis tools.
c. Vulnerability
Management:
While
the
threat
management deals with unknown security risks at the
system, the vulnerability management deals with
known risks of the system at various levels. The SI shall
identify all vulnerabilities of the system pertaining to
data, application, host and network, and implement
processes and tools to monitor and mitigate them.
d. Software Development: The SI shall implement security
best practices and patterns across all software
development life cycle (SDLC) phases of this package,
to ensure the defined policies and processes are
implemented in various architectural components of the
system.
The Foundation and Process layer defines logically various
artefacts related to security, they need to be implemented
at physical components level concerned to data,
application, host and network level. The following section
defines these requirements at high level which needs to be
implemented by SI.
a. Data:
i.
Specialised scans to be performed on the
database hosts
ii.
Data access to be provided to only authorised
users/groups
b. Application:
i.
Application code need to be protected from
unauthorised access and modifications
ii.
Static analysis tools to be deployed to scan the
code and identify threats and vulnerabilities
iii.
Access to functional modules/components to be
provided to only authorise users/groups.
Sl.
No.
Security
Layer
Component Description
c. Host:
i.
Host intrusion detection systems to be deployed
to protect servers.
ii.
Integrity monitoring checks to be performed on
the hosts to protect files and programs.
iii.
Baseline scanners to be deployed to ensure that
hosts are in adherence to defined security
policies.
d. Network:
i.
Network intrusion detection devices, anti-virus
detection tools and firewalls to be deployed to
protect the network.
ii.
Logical boundaries of network to be defined and
deploy applications as per access requirements.
Logical boundaries can be defined based on
target
user
access
such
as
DMZ
for
internet/extranet access, protected network zone
for intranet access, and restricted network zone
for few critical business users.
TABLE
8.5
27: E -P RAGATI
The following generalised Access Control mechanism will be followed for the ePragati applications:
1. User authentication to be verified against the User Repositories through ID
entity Manager
2. Coarse Grained Authorisation is required to be provided by the Access Manager
3. Fine Grained Authorisation is required to be provided by the respective e-Pragati
application typically at portal server level.
4. e-Pragati application containers can enforce fine-grained authorisations depend
on the category of resource (e.g. Secured application resources). In such cases,
the e-Pragati application container invokes the Policy Decision Point (PDP)
through the Policy Enablement Point (PEP) for authorisation decisions.
The following Figure shows e-Pragati application components and their
interactions when a user attempts to access e-Pragati application:
e-Pragati Requirements Specification Document Temple Management System Page 108 of 216
FIGURE
13:
TMS
e-Pragati Requirements Specification Document Temple Management System Page 109 of 216
Apart from the Identity & Access Management (IAM) solution, the Access Control
mechanism requires following security components to be configured on the ePragati Application Servers:
1. Access Proxy is required to form the first line of defence for the access control.
Access Proxy must be configured on the DMZ located Web Server for the ePragati application. Access Proxy is required to perform the following actions:
a. Intercept the incoming user requests for the e-Pragati Application
b. Verify the presence of users SSO session context
c. Propagate the ID entity information to the servers to enable user access
to the resources hosted on the server
2. Policy Enforcement Point (PEP): This is required to propagate the access policy
decisions for the user access. PEPs are required to be configured on all the
servers which participate in the solution building. PEPs enable the policy driven
access control.
Access Control Flow: The e-Pragati access control flow is based on the usage
of the Single Sign-On (SSO) enablement and Policy driven authorisation. The
following sequence illustrates the envisioned access control flow:
1. User attempts to access the resources on the e-Pragati application
2. The Access Proxy component intercepts the user request and determines,
whether the User is already is authenticated and has an active SSO Session
Context
3. In case of no Active SSO Session Context exists, the following process takes
place:
a. The Access Proxy component will forward the user request to the
Authenticate & Authorise component for verifying the user credentials &
querying the authorisation details.
b. The user will be prompted to provide the user credentials.
c. The user credentials are collected and validated against the appropriate
user directory. Invalid credentials will result in access denial.
d. Multi Factor Authentication (MFA) is triggered based on the authentication
mechanism associated with the user request. In which case, the user will
be prompted to present additional authentication credentials for
verification. Invalid credentials will result in access denial.
e. The Authorisation component will query the user attributes for the
authenticated users.
f. A secured session context is created and maintained in the authorisation
component.
4. In case of an Active SSO Session Context exists, the following process takes
place:
a. The Access Proxy will forward the user request to the PDP via the PEP on
the Web Server.
b. The PDP determines the applicable access policy for the user by verifying
the policy repository.
c. If user is authorised, the Access Proxy determines how the authenticated
user information need to be communicated to the Protected Resource
(e.g., SAML token, HTTP headers, User name token, RACF pass ticket).
Access Proxy will invoke the Secure Token Services component. The
Secure Token Services component creates the requested token from the
authenticated user information. This enables the user information to be
mapped to account and attribute information the e-Pragati application
recognises based on configured trust services/policies.
5. The user request is then forwarded to the requested resource on the
application server.
9.1
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
28:
9.2
Training Deliverables
Sl.
No.
1.
Details
Training Plan
2.
3.
9.3
29:
TRAINING DELIVERABLES
The SI shall prepare training plan and contents in sync with the Endowments
department and the trainings shall be rolled out after the approval from
Commissioner Endowments department. The SI shall provide the training to the
departmental staff and others, if any, as instructed by the Endowments department.
The above trainings shall be conducted at four locations such as Vishakhapatnam,
Vijayawada, Tirupati and Kurnool. The expected duration for the training at each
location will be 10 -15 days and that should cover the suggested target audiences
as indicated in the Table 30 given in the section below.
9.4
Training Need
Table 30 lists the high level requirements of training modules and its target
audience.
Sl.
Training Modules
No.
1. e-Pragati Temple
Management System
Orientation Training
2. Specialised Computer
Training
3. Process Training
4. Temple Management
System Applications
Training - Pilgrim Service
Applications
5. Temple Management
System Applications
Target Audiences
Sl.
No.
Training Modules
Target Audiences
Note:
a) The size of each batch should not be more than 40.
b) It will be department wise training and training manuals need to be provided for each department.
c) Coverage of training of each department will not be same.
TABLE
30:
9.5
Change Management
Change Management initiative shall focus on addressing key aspects of project
including building awareness among stakeholders. Change management shall also
include development and execution of communication strategy for stake holders.
Change Management workshops shall be planned and conducted based on needs of
various stakeholders of Temple Management System. Key considerations for Change
Management Process are given below:
Sl.
Description
No.
1. Impact Assessment In the light of changes, how current functioning, Org
structures, roles and responsibilities are impacted.
2. Assess Change Readiness How ready departments and stakeholders are?
Are there potential blockers? Stakeholder issues and concerns.
3. Design Change Management Approach This is to come up with an optimal
way of implementing Temple Management System System (Phases, Pilot
Groups.) and time frames.
4. Develop Change Plan This includes creating plan, identifying milestones,
developing benefit tracking mechanisms.
5. Define Change Governance Including appropriate decision making and
review structures.
TABLE
31:
Sl.
No.
1.
Description
3.
Conduct
a
Baseline
Communication
Assessment
Develop and validate Communications
Strategy
Develop and Validate Communication Plan.
4.
5.
6.
2.
TABLE
32:
CHANGE MANAGEMENT
SPECIAL CONSIDERATIONS
FIGURE
14:
The integration per se need not be only through real time services. Other modes
of integration shall also be considered based on the detailed requirements.
Various Integration modes and scope of SI is
Sl.
Integrati
Description
No.
on mode
1. Service
This indicates that the
Level
integration
with
the
Integratio application/package
is
n
via a service. It could be
either a SOAP based
web service, RESTful
service
or
Message
based
service(asynchronous)
indicated as below.
Scope of Temple Package SI
If the TMS application is the
consumer then the scope of the
SI shall be, to co-ordinate with the
respective application SI for the
service contract/specs to use the
same. E.g. People Hub.
If the service is to be provided,
than the SI shall co-ordinate to
arrive at the service contract/specs
as needed by the other SIs. e.g.
Sl.
No.
Integrati
on mode
Description
2.
3.
Applicatio
n Level
Integratio
n
Integratio
n Service
This
is
API
based
integration where the SI
is made available with
the APIs for using the
services.
Sl.
No.
Application
Temple
Applicati
on Role
Integration
Requirement
This shall be a service level
integration.
It shall be used at all
instances where the user
details need to be prepopulated or validated. E.g.
During the process of
Registration
of
Pilgrim,
Donors etc. the basic
details shall be fetched and
auto-populated.
1.
People
Hub
Consumer
2.
Land Hub
Consumer
Module / Sub
Module
Traceability
1. Profile
Management /
User
Profile
Management
1. Institutional
Profile
Management
(Land
Pertaining to
Temple, Muts ,
Peetams,
Sl.
No.
3.
4.
Application
APp Store
Entity Hub
Temple
Applicati
on Role
Consumer
Consumer
Integration
Requirement
The input shall be Survey
number.
The output shall be owner
details and detailed land
details pertaining to survey
number.
The mobile apps pertaining
to Temple Package shall be
hosted in the APp store.
This shall be a service level
integration. This shall host
the Temple Information as
an Entity.
The input shall be the
Temple Information and its
location.
5.
6.
7.
Knowledge
Mgmt
Consumer
DataLytics
Provider
eProcureme
nt
Consumer
Module / Sub
Module
Traceability
Patashala etc.)
NA
1. Profile
Management /
Institutional
Profile
Management
(Registration
of
Temple,
Muts
,
Peetams,
Patashala etc.)
All Modules /
Sub Modules
wherever
applicable.
1. Predictive
Analytics
1. Procurement
module.
Sl.
No.
8.
Application
MeeSeva+
+
Temple
Applicati
on Role
Consumer
Integration
Requirement
platform by Vendors for
procuring
of
goods
(milk/coconut/vegetable)
needed for Temples.
Currently,
the
below
services are served in
MeeSeva
Portal
via.
MeeSeva Centers.
Module / Sub
Module
Traceability
NA
Sl.
No.
9.
10.
Application
Grievance
Mgmt
(MeeKosam)
Dial.AP
e11. Pathakam
(Scheme
Mgmt)
Temple
Applicati
on Role
Consumer
Consumer
Consumer
Project
Mgmt
(e-Pragati
12. Project
Manageme
nt
Application
)
Consumer
13. Works
Mgmt
Consumer
Integration
Requirement
be facilitated via. MeeSeva
portal.
The PMO shall
ensure the availability of
MeeSeva++ vendor for
facilitating the integration
of
the
same
in
the
MeeSeva++ Portal
This is an application level
integration
rather
than
service integration. MeeKosam shall be used to
address
various
stakeholder grievances of
Temple Staff and Pilgrims.
This is a user level service.
This shall be used for direct
inquiry
or
addressing
grievances
of
Pilgrims,
Visitors etc., by Call Centre
staff.
This is an application level
integration.
The
Department
staff
shall
leverage this e-Pathakam
for defining the various
schemes
pertaining
to
Temples and manage the
same.
This is an application level
integration.
e-Pragati
Project Management shall
be used for planning,
monitoring and tracking
the
projects
executing
under the department. This
shall be used by PMU of ePragati and the scope of
the SI is to share or coordinate with the same for
Project plans and status.
This is an application level
integration. This is used for
planning, monitoring and
tracking the construction
and all engineering works
under the department.
Module / Sub
Module
Traceability
1. Complaint
Management
1. Call Centre
NA
Sl.
No.
Application
15.
HRMS
16. Payment
Gateway
17. SMS
Gateway
18. Email
Gateway
Temple
Applicati
on Role
Consumer
Consumer
Consumer
Consumer
Consumer
Integration
Requirement
This is an application level
integration.
The
Department
staff
shall
leverage
this
CFMS
application for managing
the finance and accounted
related functionality.
This is an application level
integration. This will be
leveraged
for
Payroll,
Transfer
and
Leave
functionality.
This is an integration
platform.
The
payment
gateway (credit card/debit
card/net
banking/mobile
wallet pertaining to ePragati system needs to be
used wherever applicable
in all applications for
payments,
The
Department
shall
facilitate the SI with the
Payment Gateway.
This is an integration
platform.
The
Email
gateway pertaining to ePragati system needs to be
used wherever applicable
in all applications for
sending
SMS
and
notifications
to
the
registered Pilgrims and
who have subscribed for
Alerts.
The Department shall
facilitate the SI with the
SMS Gateway.
This is an integration
platform.
The
Email
gateway pertaining to ePragati system needs to be
used wherever applicable
in all applications for
sending
emails.
The
Department shall facilitate
the SI with the Email
Module / Sub
Module
Traceability
2. Finance
and
Accounting
1. Human
Resource
Management
1. e-Payment
module
Sl.
No.
Application
Temple
Applicati
on Role
Integration
Requirement
Module / Sub
Module
Traceability
Gateway.
TABLE
APPLICATION REQUIREMENTS
FIGURE
14: E-PRAGATI
Description
Category
A
Application retained as it is or
with minor modifications
Category
B
Category
C
Criteria
35:
APPLICATION CATEGORIES
Application Name
Category
Category
Category
Category
Category
Category
TABLE
C
C
C
C
A
IN
System
Integrator
NIC
In house Team
In house Team
In house Team
APOnline
TMS
Sl.
No.
1.
2.
3.
4.
7.
9.
11.
District
Name
Name of
Mutt/Trust/Tem
ples
Head Office
Endowments
Department
Srikakulam
DC/AC Office
Vizianagara
m
DC/AC Office
Visakhapatn
am
East
Godavari
West
Godavari
Krishna
14. Guntur
DC/AC Office
Sri Varaha
Lakshminarasim
ha Swamy
Devesthanam
Sri Kanaka
Mahalaxmi
Ammavari
Temples,
Burujupet
DC/AC Office
Sri Veera
Venkata
Satyanarayana
Swamy
Devesthanam,
Annavaram
DC/AC Office
Sri
Venkateswara
Swamy
Devasthanam
Dwaraka
Tirumala
DC/AC Office
Sri Durga
Malleswara
Swamy
Devesthanam
Sri
Tirupathamma
Ammavari
Devasthanam,
Penuganchiprolu
DC/AC Office
Y N
Y N
Y
NA
N Y
N
NA
Y N
Y
NA
N Y
Y N
Y
NA
Sl.
No.
15.
16.
17.
18.
20.
22.
Name of
Mutt/Trust/Tem
ples
District
Name
Nellore
DC/AC Office
Prakasam
DC/AC Office
Kadapa
DC/AC Office
Kurnool
Ananthapur
Chittoor
TABLE
DC/AC Office
Sri
Bhramaramba
Mallikarjuna
Swamy
Devasthanam,
Srisailam
DC/AC Office
Sri Nettikanti
Anjaneya Swamy
Devasthanam,
Kasapuram
DC/AC Office
Sri
Kalahastheeswar
a Swamy
Devasthanam ,
Srikalahasthi
Sri Varasiddi
Vinayaka Swamy
Devasthanam,
Kanipakam
37:
N Y
N
NA
Y N
Y
NA
Y N
Y N
NA - Not Applicable
Y Yes (Available)
N No (Not Available)
Table: Existing Online Services status in Temples/Institutions
FIGURE
1.2
15:
FIGURE
1.3
16:
Process Changes:
The following are the proposed changes for Assessment of seed supply and demand
process:
1. During the Income and Expenditure assessment preparation time itself, the
assessment amount should be captured by the TMS and the user should be
able to send assessment directly to Assistant Commissioner /Commissioner.
This eliminates multiple steps of verification and assessment multiple times.
2. Department should verify through TMS and the updated information,
approval/modification should be communicated using the TMS to the
concerned users.
3. After conformation on budget the admins of Temples pay funds to various
schemes in a single approval .The amount shall be transferred to different
heads of sections
Available fund at various schemes should able to monitor by Commissioner for
monitoring of various schemes and approval of beneficiary under schemes
1.4
Benefits to System:
Sl.
No.
1.
Benefits
to
System
Complete Automation of Fund Management
2.
3.
4.
5.
6.
7.
1.5
Sl.
No.
1.
2
3
4
38:
39:
Responsibi
lity
Admin of
Temples
Service
Level
Real-time
Admin of
Temples
AC/DC
Real-time
Commission
er
Real-time
Committee
Real-time
Commission
er
Real-time
2 Days
2.1
FIGURE
2.2
17:
FIGURE
18:
40: G OOD
2
3
4
Activity
a. Preparation of budget Online by using
business recommendation provided by
system
b. Submits the budget to AC/DC
a. Requests and receive requirements from
the temples for providing the CGF
a. Verifies the budget and forward to
Government
a. Verifies the budget and generates the
CGF amount automatically by using defined
system
b. Forwards to committee for approvals
a. Verifies the budget estimation and
assessment of CGF
b. Identifies the temples for CGF based on
the system recommendations
a. Amount transferred to temples Online
TABLE
41: G OOD
Responsibi
lity
Admins of
Temples
Service
Level
Real-time
Admins of
Temples
AC/DC
Real-time
Commission
er
Real-time
Committee
Real-time
Commission
er
Real-time
2 Days
FIGURE
3.2
19:
AS - IS
PROCESS
OF
MANUAL
ACCOMMODATION
BOOKING
FIGURE
3.3
Sl.
No.
Sl.
No.
1.
2
BOOKING
IN
TMS
Benefits to System:
3.4
OF ACCOMMODATION
BENEFITS
Responsibi
lity
Pilgrim
Service
Level
Real-time
Admins of
Temples
Real-time
Admins of
Temples
Real-time
RESPONSIBILITY
Enable the user to enter the details such as personal, family, interest in
social cause, spiritual interest., which includes, but not limited to the
following:
a) Records and maintains a person's details, ID proofs.
b) Records and maintains a person's interest of engagement with
Endowments Department.
c) Records and maintains a person's visits to the temples.
d) Records and maintains person's donations and contributions.
Ability to retrieve the following information of pilgrims from the Health
Department through the integration with e-Health application.
a)
Blood Group
b)
Identification Marks
c) For establishments whose data is not readily available for use, the
system shall provide the option to key in establishment details.
d) The data correction request/new data w.r.t profile entries shall be
communicated to the native application holding the master data (entity
hub for establishment related data) for updating as a batch process.
e)
For further use of any transactions/services, the complete
registration information has to be stored in the temple management
systems databases of the respective departments.
4
5
Shall
a)
b)
c)
Provision for the authorised officers of the department to lock the user
accounts of specific users under specified exceptional conditions.
8
9
10
11
2
3
4
5
Display the list of users and allow each user to be assigned roles,
privileges as well as alter or revoke them.
On successful login into the system, the user shall be displayed the
Pages, Features and Data that the user has the permission to access.
Provision for Logging off from the application accessed and termination
of the session.
Provision to control the user access in environments such as BYOD and
Cloud. Role based access is required for internal as well as external
users.
Sub-Component: Password Management
Provide facility so that the passwords should consist of a minimum of 6
alphanumeric characters and one numeric and one special characters
(no common names or phrases) the actual combination and minimum
and maximum lengths will be site configurable.
Passwords should be changed every 90 days (or other period).The
systems shall enforce password change with an automatic expiration
and prevent repeated or reused passwords.
Provide facility so that; on allocation for the first time as well as reset of
password by the system administrator for lost passwords, the user will
be forced to change the password.
Provide facility so that passwords must be stored in encrypted forms by
the system and these cannot be retrieved by the system administrator
who may only reset the password.
Provide facility so that passwords should be kept private i.e., not
shared, coded into programs, or written down.
Provide facility so that user accounts will be frozen after three failed
login attempts. All erroneous password entries will be recorded in an
audit log for later inspection and action, as necessary. Sessions will be
suspended after 15 minutes (or other specified period) of inactivity and
require the password to be re-entered.
If any user logs in to the system using one machine and then logs in to
the system using another machine, then the data that the user had
already entered will be automatically saved and the user will be logged
out of the system and asked to log in afresh. In the same system the
session time shall be configurable.
Facility of OTP authentication and credential verification should be
provided.
Component Name : Notifications & Alerts
Component Functionality: The notification services are provided on the
digital dashboard of each user whereas the alerts are delivered through
multiple channels. The calendaring ability helps to record dates and
details of sevas/pujas/Darshanam/ donation related events of the
pilgrims, staffs of temples and the other stakeholders involved.
Sub-Component: Notifications & Alerts
Facility to publish various notifications for all the stakeholders and for
general public based on user roles & privileges.
3
4
3
4
5
7
8
9
10
11
12
1
2
3
4
5
1
2
3
4
5
6
The above users should have different power and access privileges as
per the requirements of system stakeholders.
5
6
7
8
9
10
11
12
13
14
15
16
17
Provide the general common pages like About Us, Privacy Policy, Terms
& Conditions, FAQ, Contact Us, feedback.
18
Provide the basic features like Login, Logout, Forgot Password, Change
Password, Switch Language, My Profile.
19
20
21
22
23
24
25
26
27
28
29
30
The services presented to the users should vary based on the category
of the users and the privileges defined for the users in the system.
31
32
33
information
on
35
- Construction of temples,
-Establishment history
Committee of Temples,
- Year of establishment/construction
System module should be able to do Classification of Institutes:
System should capture No. of Temples District wise, Zone wise as the
case may be.
TM0102
3
4
5
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Modul
e
Code /
FR
Numbe
r
TM020
1
1
2
3
4
5
6
7
8
10
11
12
13
14
TM020
2
1
2
3
4
5
6
7
8
9
TM020
3
1
2
3
4
5
establishment history ,
Year establishment/construction
System shall update the services availed by a pilgrim (such as
Darshanam, Seva, Accommodation, Annadanam, Kalyankatta, Laddu
distribution,.), based on the unique Pilgrim ID and biometric verification
at each touch point
Ability to track the movement of pilgrims family members visiting
along with the pilgrim
The system shall capture pilgrims attendance in the activities opted by
pilgrim during booking
System shall provide interface with the other Pilgrim Service
application modules to allow tracking of internal services provided.
The system shall provide the information to the security in case of any
suspicion for the pilgrim
The system shall track the exact inflow and outflow of pilgrim at each
touch point by capturing the entry, exit and details of movement of
pilgrims
System shall provide Search option for the pilgrim booking/
allotment. This shall also provide sorting option for the search criteria
Sub-Module: Queue Management Module with Predictive
Analytics
The system shall facilitate pilgrim queue management at Pilgrim
Helpdesk counters, outside Annadanam complex, VQC. It should also
provide a system for organised entry and exit of pilgrims.
System shall provide options for pilgrim management and facilitate
with the schedule for gate openings at critical nodes
System shall be configured on the basis of departments business rule
for crowd management. The business rules or scenario would be
different for specific days or month and the software developed should
be able to adapt automatically
System shall provide automatic corrective/preventive measures based
on real time information captured from various cameras
System shall provide clear instructions for identifying which gate/node
should be closed or opened with duration & other relevant details
System shall provide alerts during any emergency and shall respond
and detect the criticality based on calibrated benchmarks or threshold.
e.g. If at a particular node the packing density increases than a
calibrated benchmark then it should provide an alert message to
centralised control room
10
11
12
13
14
15
16
17
18
19
20
21
22
23
TM020
4
1
2
3
4
5
6
7
9
TM020
5
1
2
1
2
3
4
5
TM0206
1
7
8
9
10
11
12
13
14
15
TM020
7
TM0208
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
System shall be linked with the rate master and shall enable approval
for the workflow management
18
19
System shall maintain Wage rate master which shall be linked with
the employee wise daily Wage structure
TM020
9
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
System shall maintain the life cycle of the complaint till its closure
Ability to manage and deal with all the aspects of complaints such as
solutions / actions taken for the complaint resolution, departments
involved and action taken by each department to resolve the complaint
System shall take innovative measures in handling complaint
successfully in least amount of time.
Ability to generate the report of corrective action taken by the
department to minimise a particular set of complaint.
System shall define the steps / rules that are automatically triggered to
resolve an irrelevant complaint or a frequently occurred complaint
Ability to take all the suitable steps and measures to ensure
transparent handling of the complaint
19
System shall maintain time stamp and audit trail of the complaint
20
TM021
0
TM030
1
3
4
5
6
7
8
9
10
TM030
2
1
2
3
4
5
6
7
8
10
11
12
13
14
15
16
17
18
19
20
21
TM030
3
a)
Call centre
b) Information kiosk
c)
SMS mode
d) Pilgrim Helpdesk counters
System shall enable pilgrim to access the option for accommodation
booking upon seva confirmation, for all the seva bookings. This shall be
linked with other modules such as Accommodation, Kalyankatta, so that
pilgrim shall have an option for availing a package of services under
single reference number.
For the sevas, pilgrims with privilege of free accommodation, shall have
access to the accommodation module for booking the rooms,
categorised for booking along with seva.
System shall enable pilgrims to access the details of the privileges
provided under different sevas
System shall provide Search option for the pilgrim booking/ allotment.
This shall also provide sorting option for the search criteria
Sub-Module: Hundi Management
Daily recording for the Hundi collection and counting shall be updated
with the Finance and Accounts
5
6
7
TM030
4
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
TM030
5
2
3
System shall enable the room allotment for Donors guest houses based
on the advance bookings done by donors
System shall enable pilgrims to check, if the room booking request
raised by him/her is accepted or rejected
System shall automatically notify pilgrims (through SMS, email) for the
status of room booking request
Confirmation status shall be made available to the pilgrim through call
centre / Information kiosks / Pilgrim Helpdesk counters / SMS
Rooms shall be allotted to pilgrims after verifying the authenticity of the
pilgrim, based on valid ID proofs at Pilgrim Helpdesk counters
Caution Deposit amount to be refunded to the pilgrim on check out
shall be updated to pilgrim through SMS. Instructions regarding the
location / counters to collect refund shall also be shared
System shall provide an option for refunding the Caution deposit
amount online to pilgrims account, if desired by the pilgrim.
Details regarding the amount to be refunded shall be updated on the
Temple Management System portal to be accessible for Pilgrim
Helpdesk operator
System shall enable pilgrims to get the refund for the caution deposit
from any of the Pilgrim Helpdesk counters. System shall update the
same for the Booking reference number of the pilgrim
Pilgrim shall get information regarding their queries for accommodation
- Booking / allotment / check in / checkout from Pilgrim Helpdesk
counters, Call centre and through SMS
System shall capture the room check in and checkout time on real time
basis so that pilgrims are charged on actuals for the total hours for
which room was occupied
List of room bookings done by pilgrims through website and other
channels such as Pilgrim Helpdesk counters, DD. shall be available with
the Temple management for a comprehensive data/ view of the
bookings done
System shall provide Search option for the pilgrim booking/ allotment.
This shall also provide sorting option for the search criteria
The system should block the Sevas and Accommodation. On special
days temples will be closed until they reopen, the sevas will be blocked
and the system wont allow to book the tickets
Sub-Module: Annadanam Module
The system shall display information on public display for:
Waiting time
Menu
Nutritious value of the food
Batch timing
The system shall display information in the dining area:
List of donors
Ability to book a slot for pilgrim in Annadanam, based on his/her other
bookings such as Darshanam and Seva, to reduce the waiting time for
the pilgrim
The system shall have a well-defined seating plan for the pilgrims
3
4
5
6
7
8
9
10
TM030
7
1
3
4
12
13
14
15
16
TM030
8
The system shall use single merchant identity with multiple transaction
identities to streamline Treasurer processing (e.g., merchant ID, fund
number, budget unit number)
The system shall not allow local storage or transmission of credit cardspecific information. The solution shall follow industry-standard secure
transaction between consumer and e-Payment provider only.
The system shall support automatic filters for suspicious transactions
and shall allow for manual checking of suspicious transactions.
The system shall generate notifications for fraudulent online
transaction attempts.
The system shall have user friendly web based administration Control
Panel
The system shall allow Temple Management System to build a complex
logistic request processing system to fully automate after-payment
operations using IPN.
The system should provide an interface between all bank partners'
system, Treasury and Temple Management Systems finance and
accounts ERP system.
The Payment gateway shall collect payment receipts for various
payments like donations fees, room tariff fees, other charges and fees,.
The payment gateway would collect these receipts and credit the same
to Departments bank account
All receipts shall be credited to the Department account not later than
T+2 days.
The system shall be able to provide the department an MIS to facilitate
reconciliation. A user friendly console has to be shared with
department. The MIS should clearly state
a.
Name of person / organisation money received from
b.
Money received towards (registration fees, penalty, arrear)
c.
Amount received and date
d.
Other information as communicated by the department
The after-payment operations shall include the facility to refund the
payments to the payers bank account as per Departments instructions
The system shall provide users with FAQs with answers to a list of
frequently asked questions on payment and security related issues.
Sub-Module: Donations module
4
5
6
Module
Code /
FR
Number
1
2
3
4
5
7
8
9
10
11
12
13
TM040
1
1
2
3
5
6
7
8
9
TM040
2
1
2
6
7
10
11
12
TM040
3
1
2
3
4
5
TM0404
TM040
5
Sub-Module:
System shall provide details for the staff deployed for Hundi counting
3
4
5
6
7
in a particular bank
Module
Code /
FR
Numbe
r
TM050
1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
28
29
30
31
32
33
34
35
36
37
The system shall provide the procurement details of food stock from
stores with reference to number of Dittam planned for the food
preparation in Annadanam
The system shall process indent and invoice for milk procurement in
Annadanam
The system shall maintain the list of vegetable items, requirements for
Annadanam with the options of seasonal vegetables
The system shall maintain the details of other consumables used in
Annadanam, such as number of banana leaves
The system shall maintain the details of vegetable donors with the
frequency of donation
The system shall have an option to trigger the information to other
interrelated departments such as transport for collecting the donated
vegetable from different locations
The system shall maintain the details of procurement of silver & gold
coins from treasury and selling to the Pilgrims
The system shall provide facility for the user to define and change the
minimum and Maximum inventory levels ('min-max levels') for each
inventory material in the module/
The system shall facilitate tracking the inventory levels against minmax levels for all inventory materials
The system shall provide facility for the users to define the re-order
quantities for each inventory material in the module
The system shall manage the availability of first aid kit at various heavy
rush pilgrim points such as:
Auto Stand
Railway stand
Bus stand
VQC Complexes
Darshanam booking counters
Other important points of Pilgrim interface
The system shall send alerts for managing the day to day facilities
requirement on time.
The system shall maintain details of resource requirement for all the
departments online
The system shall maintain all the records of System Integrator
managing additional Potu for laddu production:
Provision from stores
Laddu production
Payment to the System Integrator
Other day to day activities
System shall maintain a master list of the specification of the materials
required by different departments, such as Vastram., for ease in
procurement
System shall maintain a master list of the empanelled System
Integrators for procurement of raw materials., such as Vastram
The system shall compare the rates offered by different System
Integrators to finalise the System Integrator for empanelment
The system shall maintain the details of Vastram supplied by System
38
39
TM050
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
TM050
3
3
4
Module
Code /
FR
Number
TM0601
1
3
4
5
6
7
8
9
TM0602
1
2
3
4
5
6
TM0603
1
2
3
4
5
TM0604
1
2
3
4
5
6
7
8
9
TM0605
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
TM0606
1
2
3
4
TM0607
1
2
3
4
5
6
7
8
management (such as HODs and JEO). An audit trail for quota transfer
shall be maintained in the system
Staff of the(Attender) Temples shall update the details regarding the
room check in and check out through handheld device
Staff of the (Attender) Temples shall be able to update the room status
to "Dirty", to block the room from further allotment.
Temples shall automatically share the status of room (if Dirty), with
the FMS agency, so that agency can deploy people for cleaning the
room
Staff of the(Attender) Temples shall be responsible to update the
status of the room to "Clean" so that room shall be made available for
allotment
System shall enable interface between different Endowments
department, such as
Accounts for reconciliation of amount deposited in banks,
FMS agency for room maintenance
Engineering department for schedule for room maintenance
System shall maintain a log of the rooms cleaned by the FMS agency,
for reference while making payments to the FMS agency.
System shall enable information sharing with Call centre, Information
kiosk, SMS, Pilgrim Helpdesk counters, to share information regarding
the release of quota with Pilgrims
System shall provide Search option for the pilgrim booking/
allotment. This shall also provide sorting option for the search criteria
Sub-Module: Trustee/board Management
System should provide information trustee details
System should provide information on list of facilities available for
trustees/board members such as rooms, special sevas, prasadam
System should provide information about temples/institute to trustees
regarding special pujas and other events
System should display information on trustee details
Sub-Module: Lease Management System
Temple Management System application must facilitate the leasing of
temples assets i.e. Land, Shop, building, temples premises.
Temple Management System should keep track of assets of temples in
sync with financial module
System should accept the records of all lease performed for assets of
the temples.
System should keep all document as ID proofs, legal (agreement, lease
doc.). from people hub
System should allow the process to obtain departmental approval and
Treasury approval
System should track the agreed amount against each lease
System should reconcile the transaction against each lease and
generate the relevant - MIS
- Renewal of lease
- Termination of lease
Release of payment as per the payment term
Module
Code /
FR
Number
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
TM0701
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Module
Code /
FR
Number
1
2
3
4
5
6
7
TM0801
1
2
3
4
5
Module
Code /
FR
Number
TM09
4
5
6
Module
Code /
FR
Number
1
2
3
4
TM1001
1
2
3
4
5
TM1002
1
2
3
4
5
6
7
8
9
10
11
12
System shall maintain a list of attendees of the seva and the list of
privileges such as Vastram, laddu, gold / silver dollar to be offered to
the pilgrims performing the seva
System should capture the requirements for ritual inventory planning
System should provide updates on ritual inventory planning
Module Name : Institution Management
Module Code : TM10
Module Functionality: The module shall facilitate Institution profile such
as date of establishment, founder, trustee , asset details , financials
status. The institution can be mutt, Ashramas, charitable trusts and
veda patashalas
Provision to provide role based access to all types of institutions in the
state based on the requirements of the department to authorise the
information
System should capture all types of institution details such as assets,
trustee, location funding source, list of sevas
System should provide updated list of institutions
Provision to integrate with GIS portal to map all the institutions
Sub-Module: Mutts & Peetams Management
Provision for updated information on list of mutts
Should provide facility for access to Mutts based on the identification
of department
Provide updated information on trustee details and trust members
details
Provide updated information of assets for Mutts
Provide updated information on sevas details provided by Mutts
Sub-Module: Patashala Management
System should provide updated information on veda/agama patshalas
in the state sponsoring information about temples
System should facilitate in providing applications for admissions into
schools
System should provide information on no. of seats available in schools
and eligibility and application criteria, course structure, course
duration
System should provide information on assets belongs to schools
System should maintain trained candidates details after completion of
training/study
Provide information on mapped temples to schools
Provision to provide updated course material to students based on the
course structure
Provision to capture accommodation details
Provision to capture attendance details such as number days attended
for course ,total days to complete for course
Provision to provide grades for students after completion of
training/education
Provision to provide updated information on staff and student details
Support for providing the certification after completion of the course
13
TM1003
1
2
3
Mod4ul
e
Code /
FR
Number
1
2
3
4
5
6
TM1101
1
2
3
4
TM1102
1
2
3
4
5
6
7
8
Module
Code /
FR
Number
TM1201
1
2
Service inputs are accumulated with the aid of various Forms. Forms could be in
physical or non-physical format. Forms in both formats consist of various fields of
required information, which would be the basis for any process to be initiated. In
physical format, form availability becomes an important consideration as this can
depend on a variety of external factors. Lack of availability of forms would impede
the process. Non-physical or electronic forms would address the lack of availability
issue and would standardise the fields using a system approach.
Form availability would ensure that the services can be accessed. Forms once
available with the appropriate fields will not only form the basis for accessing any
particular service, but would also be used in creating an incremental database. The
purpose of the element as envisaged in the BPR has been as listed below:
To make available the relevant form available for making service request for
the selected services
To standardise the format for the form pertaining to selected services
To redesign/eliminate the existing forms as per the service integration and
CLGS traits of the e-Pragati architectural framework.
The following picture portrays the existing Room Booking application form
in the Temples Information Management System
FIGURE
21:
In the To-Be scenario the proposed forms describes in 4 parts which are shall be
approached for all forms to-be reengineered.
Part 1: Describes about pilgrims personal information which can be common for all
services in the TIMS application. Pilgrim has to select the service name Room
Booking option in under the corresponding service portfolio, after logging in to
TIMS application with the state specified unique number [the pilgrim demographic
and socioeconomic data of the pilgrim will be loaded from the People Hub, in case
the updated applicant data is not available in the TIMS databases]. The system
automatically identifies the pilgrim through the unique id and enables the applicant
to key the further details.
Part 2: This section relates to department specific information, application which
requires information as per department business rules. In Room Booking service
applicant has to provide the details for names of the Temples, Date of booking, no.
of Rooms required and room type. Part2 varies based on the service selection by
pilgrim.
Part 4: This section describes about payment details and it is common to all TMS
related services in e-Pragati, applicant has to pay the service charge as per
department business rules, he has select payment mode and has to pay the amount
Part 5: This section describes about self-declaration and digital signature of
applicant it is common for all TIMS related services
The most frequently used forms of the TIMS Package are hosted on the e-Pragati
Portal for reference. The SI is required to re-engineer these forms as part of the
BPR.
The following picture depicts that To-Be form for Room Booking
FIGURE
22:
FIGURE
23:
2. Donation to temples
FIGURE
24:
FIGURE
25:
AS - IS
Allow to generate survey reports for specific temples, district and state
level.
Facilitate the users to save customised report templates for future use.
Facilitate to generate predefined reports with set of parameters on the
following lines anytime online:
a) Enrolment/visits of pilgrims w.r.t seva/puja/accommodations/
region/ demographic background
b) Staffs/Officials Attendance
c)
Pilgrims attended Annadanam and donation received
d) Student/Faculty Ratio in Patashala
e) Occupancy report of rooms available
f)
Pilgrims foot fall analysis for planning and management
g) KPIs and e-PIs
10
11
12
13
14
Sl.
No.
e-PIs of Temple
Management
System
1.
Pilgrim Amenities
2.
Web pilgrim
Services
3.
Facility
Management
(sanitation)
Services
4.
Annadanam
5.
Aarogyadanam
6.
Vidyadanam
44:
EPIS OF
TMS
45:
SCALABILITY PROVISIONS
2. Performance Provisions:
Sl.
No
.
Description
1.The Temple Management System shall support 7000 users on average by
considering various types of users.
2.Response time shall be on average 3 seconds for 90% of transactions and
remaining transactions shall not exceed response time of 10 seconds.
Response time is defined as the time between when user sends a service
request and when user receives response (output on the screen). Service
Levels are different based on the Services availed.
3.Response time of services shall remain within operational SLA limit even
during peak usage with 2 Mbps link.
4.The users may perform different kinds of activities on the system, including
downloading or uploading large files like images, documents, multimedia.
The system must have acceptable level of performance even during peak
usage.
5.Temple Management System shall respond to user requests within
operational SLA limit. This SLA applicable to MIS and analytical reports as
well.
TABLE
46:
PERFORMANCE PROVISIONS
3. Availability Provisions:
Sl. Description
No
.
1.The network level redundancy shall be achieved through procuring leased
lines from two different service providers, alternate routing paths facilitated
at ISP backbone (MPLS), redundant network devises. Redundant ISP links at
both ends of SDC as well as Cloud Provider shall be provided.
2.Redundancy in security components and load balancers, in high-availability
mode, shall be provided to facilitate alternate paths in LAN including all
supporting systems.
3.Redundancy shall be provided to Temple Management System and all related
critical components of architecture including web, application, and database
layers. The size of each server/instance and total number of
servers/instances in a cluster shall be determined to meet the performance
requirements, even if a particular server/instance is unavailable.
4.The Temple Management System shall be available 24x7 with 99.5% of
uptime on the average and, strictly adhering to defined SLAs.
TABLE
47:
AVAILABILITY PROVISIONS
4. Reliability Provisions:
Sl.
Description
No.
1. The Temple Management System shall be a reliable system with consistent
and repeatable behaviour in terms of quality, availability, scalability, and
performance.
2. The Temple Management System shall be robust and tolerant to certain
level of faulty use. For example: The entire system should not come down if
an user accidently inputs wrong value, or uploads incorrect data.
TABLE
48:
RELIABILITY PROVISIONS
5. Manageability Provisions
Sl.
No.
1
.
Description
The Temple Management System is required to cater to stakeholders
across the country accessing it from multiple points and through multiple
channels like Desktop, Laptop, Mobile and Tablet. Hence the manageability
of this system is essential to ensure effective monitoring and timely
resolution of any issues surrounding performance, availability and security.
TABLE
49:
MANAGEABILITY PROVISIONS
6. Usability Provisions
Sl. Description
No.
1. The Temple Management System shall be made available on all major
browsers &mobile platforms and SI shall propose suitable solution.
2. The Temple Management application itself shall be user friendly and any
new user must be able to easily use functionalities offered by the system.
3. Error messages or pop ups must be helpful to an extent that user can take
next action and does not experience too much discomfort.
4. User interface must be simple yet user-friendly, and the workflow should be
intuitive so that user/Citizen can complete his work with least time and
effort.
5. All the system alerts and error messages shall be available in local
languages for understanding of Citizen,.
TABLE
50:
USABILITY PROVISIONS
3.
Dhoopa Deepa Naivedyam
4.
Veda Pathasalas
5.
6.
Agama Pathasalas
Scheme for construction of Ramalayams in Weaker Section Housing
Colonies
TABLE
51:
LIST OF SCHEMES IN
TMS
PACKAGE DEPARTMENT
District
Srikakulam
Vizianagaram
Vizianagaram
Visakhapatna
m
Visakhapatna
m
Visakhapatna
m
Visakhapatna
m
8
9
10
11
12
13
14
15
East
East
East
East
East
East
East
East
16
West Godavari
17
18
West Godavari
West Godavari
19
West Godavari
20
West Godavari
21
Krishna
22
Krishna
23
24
25
26
27
28
Krishna
Krishna
Krishna
Guntur
Guntur
Guntur
4
5
6
Godavari
Godavari
Godavari
Godavari
Godavari
Godavari
Godavari
Godavari
Ass.
Income
Cla
14-15 (in
ss
INR)
35896523 a(ii)
27520593 a(ii)
11000722 a(ii)
344861793 a(ii)
57387043 a(ii)
21662830 a(ii)
17721636 a(ii)
416501651
34122881
18541586
16392265
14056366
14013049
13234665
10709571
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
310542806 a(ii)
33479701 a(ii)
21483463 a(ii)
12311206 a(ii)
10401286 a(ii)
266393212 a(ii)
85828139 a(ii)
26655947
12457761
10800000
42617557
27022780
25155227
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
Sl.
No.
District
29
30
Guntur
Guntur
31
Guntur
32
Guntur
33
Guntur
34
Prakasam
35
Prakasam
36
Prakasam
37
Prakasam
38
Nellore
39
Nellore
40
41
Nellore
Nellore
42
Nellore
43
44
45
46
47
Nellore
Nellore
Nellore
Cuddapah
Cuddapah
48
Kurnool
49
Kurnool
50
Kurnool
51
Kurnool
52
53
Kurnool
Anantapur
Ass.
Income
14-15 (in
INR)
Cla
ss
21169245 a(ii)
19588836 a(ii)
11605447 a(ii)
10757773 a(ii)
10091838 a(ii)
42139992 a(ii)
18722299 a(ii)
11072499 a(ii)
10854811 a(ii)
44081102 a(ii)
27393044 a(ii)
20335476 a(ii)
15848663 a(ii)
14868715 a(ii)
13899028
13591635
11976917
12022354
10919455
a(ii)
a(ii)
a(ii)
b(ii)
b(ii)
605024584 a(ii)
77048653 a(ii)
72147108 a(ii)
30091898 a(ii)
19162145 a(ii)
69224572 a(ii)
Sl.
No.
District
54
Anantapur
55
Chittoor
56
57
Chittoor
Chittoor
58
Chittoor
59
Chittoor
TABLE
Ass.
Income
14-15 (in
INR)
Cla
ss
50311544 a(ii)
467416345 a(ii)
342998270 a(ii)
47904966 a(ii)
15026767 a(ii)
12974475 a(ii)
Performance Testing
Performance Testing includes but not limited to load, stress, scalability and
availability testing requirements and related criteria. To meet specific SLAs or
requirements necessary testing tools have to be used to confirm that the results
meet the defined criterion.
Security Testing
At different levels from services to products and applications, security has to be
tested. Services are to be tested not only for licensing, access, authorisation and
other aspects but also for penetration and injections for web, application and
information tiers. User interfaces have to be tested specific security requirements
like URL rewriting, bots and others. Not only the access, authorisation, auditing,
validating, confidentiality, integrity, availability aspects of an application, service,
process, product or portal but also appropriate specifications referred or listed in the
requirements document. All security protocols (SSL, HTTPS), encryptions and other
requirements have to be tested in this phase.
Acceptance Testing
This otherwise called User Acceptance Testing is the testing of the product
owners/stakeholders who validate all functionalities as per the business. Such a
subject matter expert team can also review requirements and can pass or fail using
the User Acceptance Test cases that are usually end to end in nature.
Smoke Testing
The application or services are tested after deployment in its environment to ensure
the application sanctity. Some basic test cases are identified and run to check this.
Operational Readiness Testing
The production ready infrastructure and the environments are tested for its
capacity, size, licenses, upgrades, versions and all other aspects for compatibility
including other systems for integration. All scalability, availability in terms of
redundancy, performance and all such requirements are ensured. In a cloud the
servers and environment procured initially also has to be tested to ensure the
requirements compatibility. Necessary loads may have to be generated using tools
for Scalability testing in a cloud environment.
Pre-Production Testing
This is otherwise called limited user testing. Before taking a release version to
production limited users are identified and rolled out to them to monitor the product
or application. Any fixes required are applied before taking to products.
Production Testing
A full release version is tested with full loads by end users for a limited period. This
is otherwise called the warranty state or stabilisation period.
e-Pragati Requirements Specification Document Temple Management System Page 201 of
216
It is recommend for a solution for automated testing and automated test case
generation. This ensures complete and appropriate test cases are generated,
reducing waste and enhancing application quality, as long as the scope and
coverage of test cases and their results are verified and signed off by PMU.
Item Details
Quantity
TABLE
53:
5
2
8
1
1
1
5
2
5
1
1
1
1
5
11
5
5
1
Features
Specifications
General Specifications
Sl.
No.
Features
Processor
2.
3.
4.
5.
7.
8.
9.
10.
11.
Specifications
Latest X86 or equivalent, 64-bit based Multi core
processor, with Speck CPU 2006 rating in the
range 140 or above
Memory
RAM
8 GB RAM or Higher
Storage
Hard Disk
500 GB HDD or Higher
Capacity
Platform
Operating System Windows 8.1 Professional or latest
Display
Display
19LED Colour Monitor or Higher
Input Device
Pointer Device
USB Optical Mouse
Keyboard
USB Entry Keyboard
Communication
Ethernet
10/100/1000 Gigabit or Higher
Wireless LAN
Yes
Ports/Slots
4 USB Ports with 2.0 or above , 1 HDMA Port, All other ports are as per
the Industry Norms
Certification
For OEM: ISO 9001:2000 For PC MS Windows and Linux certified.
Certification to be closed EPEAT Gold/ EPEAT India, FCC, ROHS.
Warranty
Comprehensive on-site support during the contract period
TABLE
54:
Item Details
Processor
2.
3.
4.
Memory
Power
Battery Life
5.
Display
6.
Keyboard
7.
8.
9.
10.
Program Memory
Data Memory
PC Interface
Host System
Specifications
32-bit processor operating at 100MHz or
equivalent
8 MB RAM or higher
Li-Ion, rechargeable battery
Approx. 500 charge-recharge cycles
Charger
Portable, compact AC adaptor
7-inch VGA (video graphics adapter)
128 * 64 Graphical LCD with backlight or higher
30 Key, Alphanumeric, Tactile, 10 million operable
or equivalent
512kb Flash or higher
8 MB(Expandable up to 8 GB)
USB Slave Port
All Standard OS like Windows, Unix, Linux
Sl.
No.
11.
12.
13.
14.
Item Details
Specifications
Size
Printer
Paper Width
Paper Roll
Dimension
Paper Loading
Optional Features
15.
16.
17.
Approx. 24 x 4 x 7.5 cm
24 Col Dot Matrix Printer or higher
Approx. 32/24 characters in a line
Approx. 12 14 meters
Easy Loading
Biometric Module, GPRS Module, Smartcard
Module
0C to 55C
Operating
Temperature
TABLE
55: 8
Features
Specifications
Pins
Print Speed (cps)
3.
4.
Input Buffer
Paper Handling
5.
Paper Path
6.
7.
Printer Fonts
Interfaces
8.
9.
10.
TABLE
56:
24
High speed draft 10 / 12
cpi: 300 / 360 cps Draft 10 / 12 / 15 or
equivalent
64 KB or equivalent
Standard Fraction Feed Rear,
Push Tractor Feed Rear
Optional Feeder Rear push tractor and Roll
paper holder
Tractor Rear in, Top out Roll Paper Rear in, Top
out
Bit Map, Indian, Scalable, Bar Code
Bi-directional parallel interface (IEEE-1284
nibble mode supported) USB (ver 2.0 Full
Speed) interface
10000 POH (25% Duty) or equivalent
Original + 2 copies
Minimum 3 million characters (LQ 10 cpi, 48
dots/character)
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Features
Functions
Print speed black
Print technology
Print quality black
Paper Size
Tray capacity
Print languages
Connectivity
Compatible
systems
Memory
operating
TABLE
Specification
Print, Copy, Scan
Minimum 15 ppm or higher
Laser Jet
Up to 600 x 600 dpi or higher
A4
Minimum 100
As per industry standards with Telugu
support
USB
Windows 8 or higher / Other Standard OS
Standard 64MB
57: MFP
5. Ink-Jet MFP Printer (02 numbers) For Office use & Hundi Counter
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Features
Functions
Print speed black
Print technology
Print quality black
Print languages
Connectivity
Paper size
Tray capacity
Compatible
operating systems
Memory
Scanner
Specification
12.
Copier
Specification
13.
Power
Operating
Environment
Accessories
14.
Specifications
and
TABLE
58:
INK - JET
MFP
as
per
industry
standards
for
PRINTERS SPECIFICATIONS
Features
NETWORK Technology
SIM
DISPLAY Type
Size
Multi-touch
PLATFORM
CPU
MEMORY Card slot
Memory
CAMERA
CAMERA Features
Loudspeaker
Communications
Specification
GSM, HSPA,LTE
Minimum Single SIM slot
IPS LCD capacitive touchscreen, 16M colours
Minimum 8.0 inches
Yes, up to 5 fingers
Android OS v5.0 (Lollipop) or Higher
Quad-core 1.3 GHz or higher
Micro SD, 32 GB or Higher
Internal 8 GB, 1 GB RAM or higher
Primary
5 MP, autofocus
Geo-tagging
Yes, with stereo speakers
WLAN or Higher
TABLE
59: MINIMUM 8
7. Wi-Fi Access Points (05 numbers) To connect PCs, Tablet Computers &
Hand-held devices
Sl.
No.
Parameters
Specifications
Interfaces
Powering
Options
Frequency
Wireless
Operating
modes
60: WI -FI
Feature
Sensor Type
Prism
Architecture
3. Resolutions
4. Dynamic
Range
5. Image Area
6. Operating
Temperature
Range
7. Humidity
8. Time for
scanning
Fingerprints
9. Distortion
Rate
10. Flat
Fingerprint
capture
Specifications
Optoelectronic
Single Prism
500 ppi or higher
256 Grey Scale
Min 46mm x 46mm
0 to 55 Degree Centigrade
S
Feature
l.
11. Certification
12. Operating
System
Requirement
13. Interface
14. Light
Rejection
15. Image
Quality
16. Automatic
Fingerprint
capture
17. Calibration
18. Quality
Check
19. Automatic
change
to the next
finger
20. Rolled
capture
21. Compliance
TABLE
Specifications
As per industry standards
Windows 8 / Windows 10/ Linux
USB 2.0, USB Powered
Should have Ambient Light Rejection
Complies with Standard Image Quality standards
System should detect & capture fingers Automatically
Factory calibrated and sealed with self-test / diagnostics at
start-up
The system issues a message regarding the quality of rolled
and plain fingerprint images prior to capturing next finger.
If the image quality is good, the system offers to scan the next
finger
Capability to allow the fingers to be rolled in a left to right or
right to left direction when taking the rolled impressions
1. Should be standard industry compliant with appropriately
certified.
2. Full Compliance with Wavelet Scalar
3. Quantisation Grayscale Image Compression Specification.
4. Full Compliance with ANSI Data format for the interchange
of Finger Print
5. Full Compliance with IAFIS Image Quality specification (For
Security)
Feature
Fingerprint
Capacity
Transaction
Capacity
Hardware
Platform
Sensor
Communication
Specifications
1000 templates
100,000
BioAPI 2.0 (ISO/IEC 19784-1:200 Specification / As per
industry standards
Optical Sensor
RS232/485, TCP/IP,USB-host, USB-client
S
l.
6.
7.
8.
9.
10.
11.
12.
13.
Feature
Standard
Functions
Optional
Functions
Display
Power Supply
Operating
Temperature
Operating
Humidity
Dimension
Gross Weight
TABLE
Specifications
SMS, Workcode, DLST, Scheduled-bell, Self-Service Query,
Automatic Status Switch
ID/Mifare/HID,9 digit user ID
Min 3 inches TFT Screen
5V DC 2A
0 - 45
20%-80%
Approx.181X129X51 mm
Approx. 1.50 kg
10.
PC Based Ticket Vending Machine (05 numbers) For
Ticketing/Billing Counters
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Features
Metal Enclosure
Ticket mode
Cash Acceptance
Coin Acceptance
Cash Dispensing
Cash
Dispenser
capacity
Coin Dispensing
Coin
Dispenser
capacity
User Interface
No
of
ticket
selections
All report logs
Specifications
Approximate 1.6mm MS-Powder Coated
Printed Thermal Paper ( Approximately 3 Inch)
INR Notes of All denominations
INR Coins of All denominations
Any denomination of INR 5, 10, 20, 50 or 100
1000 Notes for single cassette or higher
Any denomination of INR 1, 2, 5 or 10
800 Coins or higher
Touch Screen Monitor
20 configurable through password protected
Admin Menu or higher
Available through password protected Admin
Menu
Approximately 180 W
Power
Consumption
Power Supply
150V to 230V AC, 50Hz
Protocol
RS-232
Interfaces
LAN Port, Bluetooth, WiFi
Battery Back up
UPS
Operating
Ambient
Environment
TABLE 63: PC BASED TICKET VENDING MACHINE SPECIFICATIONS
11.
Sl.
No
.
1
2
a
b
c
d
e
3
a
b
c
d
e
f
g
4
a
b
c
d
e
5
a
b
c
d
Parameter
Capacity
Input
Parameters:
Voltage
Voltage Range
Frequency
Power Factor at
rated load
Harmonic
Distortion(THD)
Output
Parameters:
Voltage
Specifications
5 KVA
Frequency
Current Harmonic
Distortion
Overload rating
Output waveform
Crest Factor
Power Factor
Battery
Parameters:
Type
50 Hz
Less than 5%
VAH
Polarity Protection
for
Battery
connection
Battery Rack &
Connectors
Charger
15600 VAH
Should be provided
Other Features:
Display
Communication
Port
Isolation
Transformer
Compatibility
float-cum-boost
charger
with
Sl.
No
.
e
Parameter
Credential
Protection:
Intelligent
Fan
Operation
Technical
Data
Sheet:
TEST REPORT
h
i
TABLE
Specifications
ISO 9001, ISO 14001 & ISO 18001 & CE Certified.
Should furnish BIS Number
All critical source and sensitive loads should have
protection from transients, Advanced Electronic
Protection for device safety for rectifier and Inverter,
Built-in Overload protection, from short Circuits (OVCD)
Should be provided
Bidders should submit the Technical Data sheet for
proposed model with complete required details.
The bidder should enclose NTH test report and CE
certificate. STQC/BIS, ISO 9001:2000 CERTIFICATIONS
DIS Standard Certifications are ETDC/ SAMEER/
NISC/ISO 90001, ISO 140001, ISO OHSAS18001 enclose.
64: 5 KV
UPS WITH
Note: The batteries should be replaced with the VAH go down below 50% during the
entire contract period and also at the exit management
ANNEXURE 15 - GLOSSARY
Name
AC
AG
API
APTS
AWF
B2G
BCP
BGP
BOM
BPR
BYOD
C2G
CapEx
CCTV
CFMS
CGF
CLGS
CLI
CMS
COTS
CRM
CRUD
DC
DD
DLL
DR
EMD
EMS
EPABX
ePI
ePRS
ERP
ETL
FAQ
FMS
FRS
G.O
G2B
Description
Assistant Commissioner
Audit General
Application Program Interface
Andhra Pradesh Technology Services
Archakas Welfare Fund
Business to Government
Business Continuity Plan
Border Gateway Protocol
Bill of Material
Business Process Re-engineering
Bring Your Own Device
Citizens to Government
Capital Expenditure
Close Circuit Television
Comprehensive Finance Management System
Common Good Fund
Certificate-Less Governance System
Calling Line Identification
Content Management System
Commercial off the Shelf
Customer relationship management
Create/Read/Update/Delete
Deputy Commissioner
Demand Draft
Dynamic Link Library
Disaster Recovery
Earnest Money Deposit
Enterprise Messaging System
Electronic Private Automatic Branch Exchange
e-Pragati Indicators
e-Pragati Requirements Specification
Enterprise Resource Planning
Extraction Transformation and Loading
Frequently Asked Questions
Financial Management System
Functional Requirements Specification
Government Order
Government to Business
Name
G2C
G2G
GIS
GoAP
GPF
GPRS
GSM
GUI
HA
HBA
HDD
HLD
HoD
HQ
HR
HRMS
HSPA
HTML
IA
IAM
IEEE
IoT
IP
IPN
ISMS
ISO
ISP
ITE&C
ITIL
IVRS
JCB
KPI
LAN
LCD
LDAP
LED
LLD
LTE
MADP
MCA
MDDS
MIS
Description
Government to Citizens
Government to Government
Geographic Information System
Government of Andhra Pradesh
General Provident Fund
General Packet Radio Service
Global System for Mobile communication
Graphical User Interface
High Availability
House Building Allowance
Hard Disk Drive
High Level Document
Head of Department
Head Quarter
Human Resources
Human Resources Management System
High Speed Packet Access
Hyper Text Mark-up Language
Implementing Agency
ID entity and Access Management
Institute of Electrical and Electronics Engineers
Internet of Things
Internet Protocol
Instant Payment Notification
Information Security Management System
International Organisation for Standardisation
Internet Service Provider
Information Technology, Electronics & Communications Department
Information Technology Infrastructure Library
Interactive Voice Response System
Japan Credit Bureau
Key Performance Indicators
Local Area Network
Liquid Crystal Display
Lightweight Directory Access Protocol
Light Emitting Diode
Low Level Document
Long Term Evolution
Mobile Application Development Platform
Motor Car Allowance
Metadata and Data Standards
Management Information Systems
Name
MPLS
MTBF
NAC
NAS
NGO
NOFN
NVR
O&M
OEM
OpEx
OTP
OWASP
PDA
PDS
PMU
POC
PTZ
QA
QR
RAM
RDBMS
REST
RFP
RTM
RTO
RTP
SD
SDC
SI
SITA
SLA
SMAC
SME
SOA
SOAP
SOP
SPOC
SQC
SQL
SRDH
SRS
SSO
Description
Multiprotocol Label Switching
Mean Time Between Failures
Network Access Control
Network Attached Storage
Non-Government Organisation
National Optical Fiber Network
Network Video Recorder
Operation and Maintenance
Original Equipment Manufacturer
Operation Expenditure
One Time Password
Open Web Application Security Project
Personal Digital Assistant
Public Display System
Project Management Unit
Proof of Concept
Pan Tilt Zoom
Quality Assurance
Quick Response
Random Access Memory
Relational database management system
Representational State Transfer
Request for Proposal
Reverse Traceability Matrix
Recovery Time Objective
Real Time Transport Protocol
Secretariat Department
State Data centre
System Integrator
State Institute of Temple Administration
Service Level Agreement
Social, Mobile, Analytics and Cloud
Subject Matter Expert
Service Oriented Architecture
Simple Object Access Protocol
Standard Operating Procedures
Single Point of Contact
Software Quality Control
Structured Query Language
State Resident Data Hub
System Requirement Specifications
Single Sign On
Name
SWAN
TA
TM
TMS
UAT
UI
ULB
UML
USB
USSD
VGO
VIP
VPC
VPN
VQC
WCAG
XSS
YoY
Description
State Wide Area Network
Travel Allowance
Temple Management
Temple Management System
User Acceptance Testing
User Interface
Urban Local Body
Unified Modelling Language
Universal Serial Bus
Unstructured Supplementary Service Data
Video Graphics Output
Very Important Person
Amazon Virtual Private Cloud
Virtual Private Network
Visual Quick Code
Web Content Accessibility Guidelines
Cross-site scripting
Year on Year