Embed Size (px)
Citation preview
Page 1 of 106
Request for Proposal (RFP) for Selection of SI for
Continuity of eDistrict Project and Design,
Development, Implementation and
Maintenance of
CG e-District 2.0
Project
(Volume I) Functional, Technical and Operational
Requirements
Chhattisgarh infotech Promotion Society (CHiPS)
Page 2 of 106
State Data Centre Building, Near Police Control Room, Civil
Lines, Raipur, Chhattisgarh–492001 Tel.: +91-771-4014158
Email: [email protected], Website: www.chips.gov.in
DISCLAIMER The information contained in this Request for Proposal (hereinafter referred to as "RFP")
document provided to the Bidders, by the Chhattisgarh infotech Promotional Society Raipur,
hereinafter referred to as CHiPS, or any of their employees or advisors, is provided to the
Bidder(s) on the terms and conditions set out in this RFP document and all other terms and
conditions subject to which such information is provided.
The purpose of this RFP document is to provide the Bidder(s) with information to assist in the
formulation of Proposals. This RFP document does not aim to hold all the information each
Bidder may require. This RFP document may not be appropriate for all persons, and it is not
possible for the CHiPS, their employees or advisors to consider the business/investment
objectives, financial situation and particular needs of each Bidder who reads or uses this RFP
document. Each Bidder should conduct its own investigations and analysis and should check
the accuracy, reliability and completeness of the information in this RFP document and where
necessary obtain independent advice from appropriate sources.
CHiPS, their employees and advisors make no representation or warranty and shall incur no
liability under any law, statute, rules or regulations as to the accuracy, reliability or
completeness of the RFP document. CHiPS may, in its absolute discretion, but without being
under any obligation to do so, update, amend or supplement the information in this RFP
document.
Page 3 of 106
Contents 1 About This RFP.............................................................................................................. 5
1. Fact Sheet ..................................................................................................................... 6
2 About Chhattisgarh ........................................................................................................ 8
3 About CHiPS .................................................................................................................. 8
4 Background information ................................................................................................. 9
4.1 About existing e-District application ........................................................................ 9
4.1.1 Salient features of Chhattisgarh present e-District Project ............................... 9
4.1.2 E-District Current Environment ...................................................................... 10
4.1.3 The critical elements of e-District Application ................................................. 11
4.1.4 Service delivery mechanism .......................................................................... 14
5 Objective ...................................................................................................................... 15
5.1 Ensure the Continuity ............................................................................................ 16
5.2 Enhancement of e-District 2.0 Portal ..................................................................... 16
5.3 Knowledge Transfer from existing SI .................................................................... 16
6 Scope of Work ............................................................................................................. 19
6.1 Takeover of Existing Applications and Hardware .................................................. 23
6.2 Design and Development of e-District 2.0 Application ........................................... 24
6.2.1 System Study and Design .............................................................................. 24
6.2.2 Requirements Traceability Matrix ................................................................... 25
6.2.3 Project Documentation ................................................................................... 25
6.2.4 Proposed Document Structure ....................................................................... 27
6.2.5 Preparation of Software Requirements Specifications (SRS) ......................... 27
6.2.6 Preparation of e-District 2.0 Project Plan ....................................................... 28
6.2.7 e-District 2.0 Application ................................................................................ 28
6.2.8 Solution Architecture ...................................................................................... 29
6.2.9 Development of e-District 2.0 ......................................................................... 33
6.2.10 Solution Testing ............................................................................................. 34
6.2.11 Solution Documentation ................................................................................. 40
6.2.12 New e-District 2.0 Application ........................................................................ 41
6.3 Non Functional Requirements ............................................................................... 56
6.4 Migration of Existing Applications into New Architecture ....................................... 65
6.5 Infrastructure ......................................................................................................... 65
6.6 Backup Management Services.............................................................................. 66
6.7 Maintenance ......................................................................................................... 66
6.8 Business Continuity Plan ...................................................................................... 66
6.9 Scope of Services - Operation and Maintenance Phase ....................................... 67
Page 4 of 106
6.10 list of Resources ................................................................................................... 68
6.11 Information Security Management ........................................................................ 68
6.12 Contract Performance Guarantee ......................................................................... 71
6.13 Statutory Requirements ........................................................................................ 71
6.13.1 Contract administration .................................................................................. 71
6.13.2 Right of Monitoring, Inspection and Periodic Audit ......................................... 72
6.14 Chhattisgarh infotech & Biotech Promotional Society’s Obligations ...................... 72
6.15 Manpower deployed by SI ..................................................................................... 72
6.16 Information Security .............................................................................................. 73
6.17 Ownership of Equipment ....................................................................................... 73
6.18 Risk Management ................................................................................................. 74
6.19 Indemnity .............................................................................................................. 75
7 Sign-off Deliverables .................................................................................................... 75
8 Compliance to Standards and Certifications ................................................................. 77
8.1 Preference for Open standards ............................................................................. 77
8.2 Compliance with Industry Standards ..................................................................... 77
9 Delivery Schedule ........................................................................................................ 79
9.1 Delivery schedule for e-Form development (D=Issuance of CR for new e-Form) . 80
10 Prices ....................................................................................................................... 80
11 Payment Schedule ................................................................................................... 80
12 Service Levels .......................................................................................................... 83
12.1 Implementation Phase SLAs ................................................................................. 84
12.2 Manpower SLAs ................................................................................................... 88
12.3 Operational SLAs .................................................................................................. 90
12.4 Operational SLAs for Helpdesk ............................................................................. 93
12.4.1 Categorization of Call ..................................................................................... 93
12.4.2 Limitation of Penalties .................................................................................... 94
Annexure 6: – Infrastructure available at CG State Data Centre ......................................... 96
Annexure 7: Existing e-District Solution ............................................................................ 101
Annexure 8: List of Chhattisgarh e-District Services .......................................................... 102
Page 5 of 106
1 About This RFP CHiPS is the state nodal agency for implementing e-Governance Project in the state of
Chhattisgarh. CHiPS invites on behalf of Department of Electronics and Information
Technology, Government of Chhattisgarh, sealed bids (Pre-Qualification bid/ Technical bid/
Commercial bid) from eligible & reputed System Integrators for IT Solution provider for
“Design, Development, Implementation, and Maintenance of e-District 2.0 solution in the State
of Chhattisgarh” and provide support for a maximum total period of 2 years 3 months from the
day of Go-Live of applications.
Through this RFP, CHiPS intends to:
• Engage Software solution provider to design, develop, and maintain Public service
workflow digitization application, Grievance management application, web portal,
mobile app, document management system and helpdesk services. These
components have been bundled under the umbrella of e-District 2.0
• All the components mentioned above can be developed afresh or can be part of a
solution developed on open source standards. CHiPS has an existing e-District
solution which is currently being used to provide online G2C services in the state. The
bidders should aim to use open source products as much as possible for their
proposed solution.
• Project will involve receiving a knowledge transfer from the existing e-District vendor
of CHiPS.
• Consider the existing systems of short-listed public services, which include
126Government to Citizen services. Onboard these shortlisted public services onto the
new applications developed as a part of e-District 2.0 for Go-live.
• Assist in training, capacity building and change management of different stakeholders
for user adoption of the systems developed as a part of this initiative.
• The overall aim of the state is to enhance citizen and user experience in availing and
delivering of public services. This will be enabled through development of the above
systems, which would cover the entire service delivery life cycle. This will include public
service delivery access, discovery, application, approval, output/benefit and grievance
management.
Note:
1.CHiPS reserves the right to extend the Term for further period of up to three (3) Years on
the same terms and conditions and rate, if required.
Page 6 of 106
2. The term CHiPS in this RFP have been used for interchangeably for CHiPS or any
nominated agency by CHiPS.
1. Fact Sheet
1 Tender Number 77226/CEO/CHiPS/eDistrict 2.0/2021
2 Name of the Work Request for Proposal for ensuring continuity of e-District
project and Design, Development, Implementation &
Maintenance of Chhattisgarh e-District 2.0 Project
3 Name of the issuer of this tender CEO, CHiPS
4 Date of issue of tender document 21/05/2021
5 Last Date for Submission of
written queries by bidders
27/05/2021 at 04:00 PM
6 Pre-Bid Meeting 29/05/2021 – 03:00 PM to 05:00 PM, at Office
of CHiPS, Civil Line, Raipur
7 Publishing of pre-bid
queries Response
04/06/2021
8 Last Date for Submission of Bids 11/06/2021 up to 05:00 PM
9 Date of Opening of Technical Bids 11/06/2021 up to 05:30 PM
10 Date of Technical presentations To be informed later
11 Date of Commercial Bid opening To be informed later
12 Place of Opening of Bids The CEO, CHiPS, State Data Center
Building, Near Police Control Room, Civil
Lines, Raipur, Chhattisgarh–492001
13 Address of Communication The CEO, CHiPS, State Data Center
Building, Near Police Control Room, Civil
Lines, Raipur, Chhattisgarh–492001
14 Cost of Tender Document Should have made online payment of Rs.
25,000/- (Rupees Ten Thousand Only)
15 Earnest Money Deposit (EMD) Rs. 50,00,000/- (Rupees Fifty Lakh only) to be
paid online through e-procurment portal
Download from www.chips.gov.in or
Page 7 of 106
16 Purchase of Tender Document https://eproc.cgstate.gov.in and the bidders are
required to submit the tender fees online along with
the proposal.
17 Validity of Proposal Proposals must remain valid 180 days after
the Submission date.
18 Method of Selection Quality and Cost Based Selection (QCBS)
19 Bid Submission • Bid Submission will be online through
https://eproc.cgstate.gov.in only.
• Bidders are required to submit One Original
Hard Copy of Pre-Qualification & Technical
Evaluation Documents, along with Power of
Attorney, Pre-Contract Integrity Pact and
proof of Earnest Money Deposit in sealed
cover separately between 03:00 PM to 05:00
PM on last date of bid submission. Financial
Proposal should not be submitted in hard
copy.
• Please note that only online bids will be
considered for evaluation of offers.
• Certification by the bidder that online and
offline offer are identical in all respects as per
Annexure-24.
20 Contact person for queries CEO, CHiPS
Office of CHiPS, Civil Lines Opposite New
Circuit House, Raipur- 492001
Phone: 0771-4014158
Email : [email protected]
Page 8 of 106
2 About Chhattisgarh
Chhattisgarh, a 21st century State, came into existence on November 1, 2000. Larger than
Tamil Nadu, it is just the right size, and is also fortunate to have a low population density.
Good Governance is the highest priority in this Fast Track State. There is both policy stability
as well as political stability. Government has been kept small and the State is in excellent fiscal
health. Chhattisgarh is truly a land of opportunities. With all major minerals including diamonds
in abundance, it is the richest State in mineral resources. There are mega industries in Steel,
Aluminium and Cement. Chhattisgarh contributes substantially to the Human Resources of
India.
Several hundred students from the State qualify for admissions in prestigious academic
institutions every year. Bhilai, the knowledge capital of the State, alone sends over 50 students
to the elite Indian Institutes of Technology every year. It is large power surplus is attracting
power-intensive industries, and the State is poised to become the power-hub of the nation. Its
central location helps easy power transmission to any part of the country. 12% of India's
forests are in Chhattisgarh, and 44% of the State's land is under forests. Identified as one of
the richest bio¬diversity habitats, the Green State of Chhattisgarh has the densest forests in
India, rich wildlife, and above all, over 200 nontimber forest produces, with tremendous
potential for value addition. One third of Chhattisgarh's population is of tribes, mostly in the
thickly forested areas in the North and South. The central plains of Chhattisgarh are known as
the “Rice Bowl” of Central India. Female literacy has doubled in the last decade, and male
literacy is higher than India's average. Gender ratio is next only to Kerala. Bastar is known the
world over for its unique and distinctive tribal heritage. The Bastar Dashera is the traditional
celebration of the gaiety of tribal. Many virgin, unexplored tourism destinations are there is all
the parts of Chhattisgarh.
3 About CHiPS
CHiPS, a Registered Society promoted by the Government of Chhattisgarh, is the nodal
agency and prime mover for propelling IT growth and implementation of IT plans in the State.
The Hon’ble Chief Minister heads the High Powered Governing Council of CHiPS It includes
Minister for Finance & Commercial Taxes, Minister for Commerce & Industry, Minster of IT,
and Minister for Education, Minister for Panchayat & Rural Development, Chief Secretary, and
a representative from the Ministry of Information Technology in Government of India and
eminent persons from IT industry. CHiPS is involved as State Designated Agency (CHiPS) in
NeGP MMP’s implementation of some mega IT Projects like Bastar Net, Bharat Net, SKY,
Shaalakosh, CHOiCE, e-Procurement, SWAN, SSDG, eDistrict and GIS, CSC’S. A
Page 9 of 106
professional approach is being adopted for the implementation of IT Projects u sing the
services of e-governance experts and consultants from corporate and academia.
4 Background information
4.1 About existing e-District application
Government of India had approved the National e-Governance Plan (NeGP) in pursuance of
its policy of introducing e-Governance on a massive scale. The NeGP vision aims to
“Make all Government Services accessible to the common man in his locality, through
common service delivery outlets and ensure efficiency, transparency and reliability of such
services at affordable costs to realize the basic needs of the common man”.
To realize this vision, 27 Central, State and Integrated Mission Mode Project (MMPs) along
with 8 support components had been identified and approved, to enable and facilitate rapid
introduction of e-Governance in the country, with focus on electronic service delivery.
e-District is one of the MMPs identified under NeGP, which is aimed at strengthening the
District administration to provide Government services, in a cohesive manner leveraging ICT,
to the citizens. The project aims to target certain high-volume services and undertake ‘Back
end computerization’ to e-enable the delivery of these services through Common Service
Centres (CSCs)/Lok Sewa Kendra (LSKs), in a sustainable manner.
Chhattisgarh e-District project is an important enhancement of the State’s e-Governance
implementation programme, in which majority of the G2C services are delivered by the district
administration leveraging Information, Communication and Technology. Government of
Chhattisgarh believes that the automation of workflow and internal processes of different
departments would considerably reduce the troubles of the citizens in their interface with the
government machinery in their day to day life.
.
4.1.1 Salient features of Chhattisgarh present e-District Project
• Chhattisgarh e-District project had gone live on 27th Feb 2015
• Currently delivering government to citizen services across 27 districts and 148
Tehsils of CG
• More than 1.47 Crores applications have been received through portal, out of which
more than 1.39 Croresrequests has already been processed (Source:
https://edistrict.cgstate.gov.in)
• Accessible through Web, CSC/LSK centre and Mobile (iOS/Android)
• Access to e-district portal is also provided to all CSCs (From April 2016)
Page 10 of 106
• Chhattisgarh e-District Portal is accessible to 10,000+ VLEs
• Integration - The existing e-district Application follows the integrated service delivery
architecture. The e-district application is integrated with various DeitY and State level
e-Governance initiatives as below:
a. e-Taal
b. Rapid Assessment System
c. Integrated with State Service Delivery Gateway
d. Integration with Food Dept for Ration Card Services
e. Integration with e-Court Services
f. Technical Education
g. DigiLocker - PUSH and PULL Integration
4.1.2 E-District Current Environment
Service Delivery Channel CSC/LSK centre, Web and Mobile App
Service Category G2C
Project Component e-District, CHOiCE, SSDG, mCHOiCE App,
mCHOiCE Dashboard App
Number of Kiosks 10,000+
Hardware At Chhattisgarh State Data Center
Network CG-SWAN
Page 11 of 106
e-District Application The entire development of e-District is based on
n-tier architecture which supports
i. Linux environment
i i. Localization (Unicode) support
iii. Authentication framework through Smartcard
and Biometric (Fingerprint) devices
iv. Public Key Infrastructure (PKI) along with
smart card for Privacy, Authenticity, Integrity &
Non-repudiation;
v. MVC (Module View Controller) Payment
gateway Support for Payment Services.
vi. ENS (Electronic Notification Server) for alert
messaging.
vii. NMS (Network Management System) for
network monitoring.
Database The e-District system utilizes a DB2 database on the
Linux operating system and is integrated with the
back-end applications of 4 Government
departments. Robust authentication features ensure
the security of confidential information.
Servers • Application Server – Web sphere Application
Server 8.5
• Web Server – IBM HTTP Server 8.5
Database- IBM DB2 Standard 10.5 with
PureScale
4.1.3 The critical elements of e-District Application
The current e-District Architecture (as below), as shown in the schematic below, include front-
end for e-District application, enterprise application layer, service components, channels of
delivery, integrated “To-Be‟ processes, application layer and back end. These elements
provide for incorporating a comprehensive functionality in the proposed solution for e-District.
Each element of the BPR framework depicted above is detailed as below:
Page 12 of 106
Front end
In the framework, front end is a single-window multiple service delivery facility for the citizen
from where the citizen can request for a service and also receive the documents duly signed
by the respective authorities. To facilitate “Anytime Anywhere‟ accessibility and to ensure
convenience to the citizen, following delivery channels are available:
· Common Service Centre (CSCs and CHOiCE)
· Lok Sewa Kendra (At Collectorate/Tehsil)
· Mobile App
· Department counters such as Collectorate, Tehsil etc. owned by the government
Enterprise application layer
The enterprise application layer is integrated with the front end with the service delivery
components through a secured gateway. The gateway ensures standard based
interoperability between various departmental applications at the back end and connect the
CSC’s and other channels of delivery at the front end. Acting as the nerve centre, the gateways
would handle a large number of transactions across the entire network; provide a common set
Page 13 of 106
of specifications and a single point access for departments. Such an infrastructure would also
facilitate inter- departmental working in a coordinated and synchronized manner.
This enterprise application layer grants free access to the citizens for information related
services, form availability, status tracking and authentication of the issued documents as
defined under the application. A central message processing mechanism would also help in
tracking all the transactions.
Service components
Service components forms the basic building blocks of the entire BPR framework and the
“To Be” processes in the present system. These elements define the way in which the
service request will be entertained, processed and finally delivered back to the applicant.
These components are designed to handle all functionalities of the proposed e-District
application.
Channels of delivery
The Channels of delivery facilitate the customers in demanding and availing services. Some
of the channels of delivery include the following:
- Common Service Centres
- Government Office
- Offices of respective departments
- Short Messaging Service (SMS) – Status Tracking, Service Information - Online (web-
based service)
- Mobile App (iOS/Androids)
Multiple channels of services delivery will facilitate the citizens for demanding and availing
the services under e-District conveniently.
Application layer
This layer interacts directly with the application process and perform common application
services based on the service request. It also ensures effective communication between the
components and the service owners and the users using the network.
Back end
The back end of the e-District application includes the District Administration and the State
Government as a core decision making body of the service delivery mechanism. This
component focuses on the decision-making ability of the concerned department head and
Page 14 of 106
other government officers in performance of their delegated responsibilities. The data storage
and handling is also a backend task as defined by the system in specified structure.
The solution architecture of the present system is as given below: -
4.1.4 Service delivery mechanism
The overall workflow for provisioning services to the citizen/applicants through the Web
(edistrict Portal) CSC’s/CHOiCE/LSK centres and Mobile App (mCHOiCE) is described below:
At Public Kiosks (CSCs /CHOiCE/LSK)
• The citizen goes to the centres
• The citizen makes a request for a service to the operator
• Public Kiosk operator logs in to the e-District
• The kiosk operator accesses the relevant service application on the portal
• The operator read instruction/information, fills up the online form and scans the
documents
• Operator then takes a print out of the filled up form and asks the citizen to verify the
details
• The citizen examines the printed form and verifies the details.
• The citizen then manually signs or puts his thumb impression on the printed-out Form
Page 15 of 106
• The operator also issues a copy of the application to the citizen and an
acknowledgement receipt which mentions the date of delivery and a unique receipt
number.
• The process owner receives the online application and starts processing it.
• The process owner verifies the details in the e-District database (if any) and uploaded
documents.
• If the details are correct, he enters his comments/approves the application by digitally
signing it and submits it back to the e-District Application. The process owner also
issues the relevant document using his digital signature or a reason for rejection. The
issued certificate/receipt document contains a unique ID and a website address to
verify its authenticity
• The citizen visits the Public Kiosk (CSC/LSK/CHOiCE) on the specified date of delivery
and requests the document
• The operator logs into the e-District portal and retrieves the digitally signed document,
prints it out. Operator handover the document to citizen.
Through Web or Mobile App
• User Registration
• User fills up the online form and uploads the scanned documents.
• After successful submission citizen gets the Application Reference Number for tracking
the application.
• The process owner receives the online application and starts processing it.
• The process owner verifies the details in the e-District database (if any) and uploaded
documents.
• If the details are correct, he enters his comments/approves the application by digitally
signing it and submits it back to the e-District Application. The process owner also
issues the relevant document or a reason for rejection using his digital signature. The
issued certificate/receipt document contains a unique ID and a website address to
verify its authenticity
• The citizen can download the digitally signed document
5 Objective
The Chhattisgarh e-District is one of the flagship project of Government of Chhattisgarh, and
plays very important role in delivery of G2C services. In the existing portal, more than 1.47
Crore service requests has been received, and in the last six month average monthly
transaction is reached to 2.89 Lakh transaction/month.
Page 16 of 106
Considering the growth and efforts made to make it Single Window for all Government
Services, Chhattisgarh e-District 2.0 project has been envisioned. The objective of
Chhattisgarh e-District Project 2.0 will cover following aspects:
5.1 Ensure the Continuity
The primary objective is to ensure the continuity of Chhattisgarh e-District Portal which
includes renewal of IT support and other software and hardware subscriptions and licences.
5.2 Enhancement of e-District 2.0 Portal
• To enhance the portfolio of citizen centric services.
• To promote rapid replication and integration of various e-governance applications.
• To expand the geographical expansion of Common Service Centres/Lok Sewa Kendra
to ensure the government services accessible to the common man in his/her locality.
• Exploring and facilitating Departments to provide end-to-end integrated service
delivery.
• Implementing the best practices and standards to facilitate integration of services and
enhance interoperability of services for seamless, single-window delivery of services.
• Effective enactment of ‘Chhattisgarh Lok Sewa Guarantee Act-2011’ which includes
online facility for making appeal in case of breach of Service Levels defined in
Chhattisgarh Lok Sewa Guarantee Act-2011.
• Enabling Digital Payments at Citizen Counters.
• Customization and enhancement of MIS Dashboard including BI tool.
• Review and fine tuning of existing IT infrastructure and Storage optimization by
implementing the best practices.
• Enhanced Helpdesk and SLA Monitoring
5.3 Knowledge Transfer from existing SI
1. The SI will have to take a detailed business knowledge transfer from the incumbent
SI managing e-District project. The SI will have to undertake guided System Study
from the existing e-District SI and CHiPS officials to understand the existing e-District
functioning, Portal functionalities, manpower structures and any other business
information required to formulate the project plan. Studying of codebase is optional,
as the SI will go for fresh deployment and implementation of Open Source Solution
or tested product of same nature and prepare a plan accordingly.
2. Responsibilities of the SI during the Knowledge Transfer Phase shall include the
Page 17 of 106
following (including but not limited to):
i. The new SI will be required to submit a detailed Knowledge Transfer plan at the
start of the KT phase, listing all the activities from their end, including the
expectations from existing SI and CHiPS. A checklist (as part of knowledge
transfer plan) needs to be prepared by the new SI for ensuring proper knowledge
transfer. This shall be reviewed and subject to approval by CHiPS.
ii. The existing SI shall provide all knowledge transfer of the system to the incoming
SI to the satisfaction of CHiPS as per the specified timelines.
iii. The knowledge transfer shall include initial and ongoing training on existing e-
District, training materials, operations manuals, procedure manuals, source
code control and deployment/ installation guide.
iv. The existing SI shall conduct detailed Knowledge Transfer sessions for the new
SI (such sessions should be recorded by the new SI for future playback) and
shall concentrate on the following:
a) Study of the functional specification documents including the SRS,
enhancements log, user manual documentation of business processes,
presentations to CHiPS to confirm understanding.
b) Identification and deep dive into all available documents (like SRS,
enhancement log, design documents, User Manual etc.)
c) Details of integration with other systems/applications (Central & State)
d) Details and access to the codes, scripts, jobs, etc. for study and assist
in understanding the documentation of existing e-District and its various
components, understanding of development, support processes,
configuration management processes, etc.
e) Understanding of various environments (development, UAT, Production
etc.), and obtain training on all the existing tools used, processes
followed, and activities performed is optional as the SI will be expected
to set up its own environment in any of the meity empanelled cloud.
f) Understanding of existing client end infrastructure and network
management, including the role of SPOCs and other stakeholder’s
profiles
g) Walkthrough of the helpdesk setup and solution.
h) Understand the applicable IT policies and their respective status
i) Understanding of all existing issues in existing e-District IT landscape
and their impact; the issues faced by the existing SI while implementing
and managing the existing solutions and the resolutions for the same;
and also, of any special behaviour (if any) exhibited by the overall
Page 18 of 106
solution or the integrated applications.
3. It is clarified that new SI is required to deploy technically competent resources, in
the specific solution areas of existing e-District, during the KT phase and Transition
phase. The existing SI shall not be responsible for imparting any basic technical
skillset to the resources of the new SI, which would be deemed as a pre-requisite.
4. The new SI is required to utilize this time in the most efficient and effective manner,
to ensure complete business knowledge of existing e-District. The new SI should
deploy its project management, domain as well as technical manpower to absorb
the KT sessions. They should conduct site visits to get an understanding of the
requirements as and when required.
5. The new SI will be required to submit a weekly status report on the progress of KT
activities
6. During this phase, the new SI shall be required to submit a report on the detailed
understanding of existing e-District system and operations, which will be reviewed
by CHiPS and this will form the basis of start of the design phase.
7. The SI needs to prepare an Integrated Project Plan for the entire project. Project
plan should provide a detailed drill down and interdependencies of all activities to
be undertaken. This includes details of tasks, assigned teams for undertaking
responsibilities for the task, schedule of deliverables and milestones, key
assumptions and dependencies, associated risks and mitigation plans.
8. The SI’s work plan should be synchronized with the staff deployment plan
proposed; the deployment plan shall clearly define onsite and offsite deployment
plan and personnel under each deployment category along with engagement
period for the project.
9. The SI should preferably use Open Source cloud-based project management tool
and provide access to the same to key stakeholders identified by CHiPS. The tool
should provide all features related to project management requirements of the
project. Also, the PM tool should preferably have function to auto update
stakeholders over Email/SMS.
10. SI at any point of time during project cycle may have to adopt and use project
management tools provided by CHiPS.
11. The prepared project plan should allow teams to track the progress of various
deliverables and milestones, through the scheduled review mechanisms.
12. The acceptance of the Integrated Project Plan by CHiPS is necessary before
proceeding to the next phase of the project.
13. Approval by CHiPS of the proposed plan shall not relieve the SI of any of his duties
or responsibilities under the Contract. However, if the SI’s work plans necessitate a
Page 19 of 106
disruption/shutdown in project operation, the plan shall be mutually discussed and
developed so as to keep such disruption/shutdown to the unavoidable minimum.
14. .
15. The plan so submitted by the SI shall conform to the requirements and timelines
specified in the RFP.
16. Any time and cost arising due to failure of the SI to develop/adhere such a work
plan shall be to his account.
Deliverable(s):
1. Integrated Project Plan including:
a) Milestones
b) Resource deployment
c) Risks and their mitigation plan
d) Dependencies
e) Responsibility matrix
2. Configuration of Project Management Tool
3. Submission of Project Charter to include:
a) Risk Management and Mitigation plan
b) Information Security Plan
c) Communication Plan
d) Data Migration plan
e) Training and change management Plan
f) SLA Monitoring and reporting plan
g) Exit Management Plan including transition management
4. Project Plan Presentation to CHiPS
5. Other deliverables include O&M Plan, Test Plan along with User Acceptance Test
Plan, Training Plan, Exit Management & KT Plan and Security Matrix/Plan.
6 Scope of Work
The scope of the SI will include ensuring and delivering all the functional, technical and
operational requirements by co-ordinating with CHiPS and user departments. The SI shall
perform System Study to understand the existing e-District, SSDG, Portal functionalities and
code base as part of the scope.
Page 20 of 106
The existing e-District portal needs to be aligned as per the proposed Application
Architecture. e-District Portal, SSDG, and various other services need to be migrated to e-
District 2.0. The integration requirements and any further scope if needed are explicitly
mentioned against the requirement wherever needed to retain the context. The scope also
includes taking over and development of mCHOiCE and mCHOiCE Dashboard mobile App.
The minimum specified Scope of Work that needs to be undertaken by the SI is to Ensure
the smooth migration to the newly implemented solution over cloud and thereby continuity of
e-district 2.0 application and enhancing the application to improve User Experience,
managing change requests as per departments requirement, ensuring scalability, security of
the application and must comply the interoperability standards in the newly implemented
system. However, the SI is expected to conduct a detailed requirement gathering for
validation of requirements already enlisted as a part of this RFP. The SI will have to meet
any other requirements, not listed in the scope of work that may be required in order to
establish the fully functional e-District 2.0 system.
e-District 2.0 is an umbrella term given to the multiple technology components that will be
developed and is under the scope of work. All the components should be based on
microservices based architecture and be API enabled.
The newly implemented system should migrate the legacy database and beneficiaries.
Stakeholder department should able to access the supporting documents and citizens should
be able to access issued certificates by e-District Portal.
The brief scope of work of the System Integrator is categorised into two stages as follows:
i. Ensuring the continuity of existing e-district application by complete takeover and
run the of existing e-District application, infrastructure including necessary licenses
at SDC, in as-is condition along with all developments, enhancements, databases,
source codes, user manual, SRS, Design Documents, integrations and all other
components required to run the system effectively without any interruption and
operate it till the new Product or the Solution (preferably open source) is being
implemented and the whole e-district application have been migrated to e-district
version 2.0 as per the timelines mentioned in this RFP. SI has to renew the existing
licenses (refer Annexure-8) being used in existing e-District solution till the system
migrated to new environment. The SLA of current existing system will be applicable
as per the current SLAs mentioned in secion 12.2 Operational SLA.
Page 21 of 106
ii. Design, Configure/ Customize and Deploy microservices based application
eDistrict 2.0
iii. Provide cloud services as per network, security, hosting and compute requirements
of the different technology components from Meity empanelled Cloud Vendor. SI
should make sure that the empanelment of the Cloud Vendor with Meity should
remain till the time period of this project or otherwise if the empanelment expires
then the SI has to move the whole system DC and DRC of the proposed solution to
a new Meity empanelled Cloud vendor CSP (Cloud Service Providers).
iv. Migrate the existing applications, data into the new cloud based architecture
v. Configure, Implement and Maintain a document management system to support the
workflow digitization application.
vi. Configure, Implement and Maintain a grievance management solution which will be
used for ticketing, tracking and assigning of grievances from citizens and will be
integrated to the workflow digitization application for backend processing
vii. Operation and Maintenance of the New e-district 2.0 for the specified period
viii. Solution Design, Software Customization and development
ix. Application Support and general awareness Training
x. Functional changes in the application software
xi. System administration
xii. Development of new form / report
xiii. Design, Develop, Implement and Maintain a set of standard reports (as per
CHiPS/Department requirement) and dashboards that provide analytical insights
based on transaction data.
xiv. On-board all existing e-District services to the new e-District solution. This involves
the public services leveraging all technology components built under e-District 2.0.
There might be exceptions, wherein the respective state government line
department may want to continue with its legacy system. In this scenario necessary
API based integrations will have to be undertaken and selective technology
components under e-District 2.0 might be used by the respective state government
line department.
xv. Integrate with the existing set of state and central government applications and be
future ready for API based integration with upcoming software applications of
CHiPS, APIs for which will be provided to the SI by CHiPS
xvi. Any changes in the workflow and core application framework
xvii. Any new integration with other State or Meity Application (at no extra cost)
xviii. Other API integration as per project requirement (at no extra cost)
Page 22 of 106
xix. SI will provide Business Continuity Plan (BCP) and Disaster Recovery (DR) support
over cloud on two different seismic zones from Meity empanelled CSP (Cloud
Service Providers)
xx. Implementation of digital signature with PKI
xxi. Implementation of Chatbot solution within eDistrict
xxii. Implementation of Chatbot on whatsapp for eDistrict
xxiii. Testing on Periodic Basis
xxiv. Bugs / Issues fixing in the Application Software
xxv. The present e-District system till date has received 1.37 crore applications out of
which 1.27 crores have been approved. Every application has multiple annexures
and supporting documents. This system experiences more than 2 lakh transactions
per month. Therefore, there are a huge number of documents that need to be input,
indexed, searched, versioned and securely stored. At present there is no document
management system inbuilt in e-District system. Therefore, as a part of e-District
2.0, there is a need for cloud enabled, web-based document management system.
DMS should support maximum possible file types like PDF, Doc, Docx, ODT,
Google Docs, TIFF, JPEG etc. There should be no limitation on file size of the
documents that can be input in the DMS. DMS should support versioning of
documents and store all the versions of one document that is input.
xxvi. Any other work assigned by CHiPS related to the project. The bidder shall make
their own composition of support team w.r.t. category of manpower and provides
detail in Technical document with the Bid. The bidder will provide manpower with
as per qualification and experience mentioned in RFP.
The following will be the broad activities to be carried out by the System Integrator as part of the above scope:
a) Transition Plan
b) Takeover and maintenance (running) of Existing Applications till migrating to
the newly proposed solution along with Cloud.
c) Project Planning and Management
d) System Study and Design
e) Migration of the existing applications
f) Business Process Reengineering for the applications/ services
g) Development of new e-district 2.0 Application in line with the new Architecture
h) STQC Certification (The STQC audit is part of the SI scope for closing the non-
compliances as reported by agencies. The payment to be paid to STQC for
quality certification will be borne by bidder).
Page 23 of 106
i) UAT & Go live
j) Capacity Building: CHiPS will provide the details of for total number of users
and location within agreed time period (after acceptance of solution) to awarded
Bidder. CHiPS/Department will provide Space, Power, Projector,
Desktop/Laptop and connectivity for the training.
Type of Training Location Batch
Size
User Count
Classroom Training State Capital 15 250
Virtual (Online Training) District and Block HQ 15 500
k) Operation & Maintenance (O&M)
l) Integration and Support for other Government Initiatives
m) Any other activities as deemed
n) Design Document Management System with document indexing as per the
industry standards
6.1 Takeover of Existing Applications and Hardware
The SI has to perform the following list of activities as part of takeover of existing applications
a) Takeover of entire e-district application (Web application, Mobile application, all
integrations etc) in as-is condition from the existing service provider within
period as specified in the RFP.
b) SI has to take over both the Software, as well as Hardware and the
documentation pertaining to the applications. Also, SI has to maintain OS
patch, antivirus, network software upgrade etc in terms of operations.
c) The SI has to document all the activities pertaining to the application.
d) The SI has to maintain the applications as well the infrastructure which have
been taken over till the migration to the new architecture.
e) Any issues pertaining to the applications and infrastructure has to be handled
by the SI.
f) SI has to take Care the existing SDC infrastructure
g) SI will bear the cost for ATS/AMC of existing software/licenses till migration to
cloud.
h) List of Infrastructure available at CG State Data Centre Existing e-District
mentioned in Annexure 7.
Page 24 of 106
6.2 Design and Development of e-District 2.0 Application
The SI shall carry out a detailed systems study to prepare/refine the Functional Requirements
Specifications and formulate the System and Software Requirements Specifications
documents incorporating the functional specifications and standards provided by the
CHiPS/Government of Chhattisgarh. The SI has to Design and Develop the New e-district 2.0
Cloud ready (Chhattisgarh SDC or Meity empanelled) Application Architecture of e-District 2.0
which is in compliance with microservices based Architecture. The SI has to perform the
following activities as part of Solution Design for the e-District 2.0
6.2.1 System Study and Design
a) As part of the requirement gathering activity, the SI should study the existing e-District
application mainly from the business, process and stakeholder point of view.
b) SI needs to work closely with the existing SI for e-District and CHiPS officials to get all
the business knowledge of existing e-District solution.
c) Need to provide the cloud hosting (MeitY empanelled)
d) The SI will have to complete the cloud sizing exercise after gathering the requirements
and will provide detailed cloud requirements, deployment architecture and any other
required information. CHiPS would validate the same and provide permission to go
ahead.
e) The SI should prepare a detailed document on the implementation of e-District 2.0
Application with respect to configuration, customization, extension, Migration and
integration as per the requirement of CHiPS. The SI shall also prepare a
change/reference document based on changes or deviations from the base version of
the e-District 2.0 Application with appropriate references to all the facts/ documents
provided by CHiPS.
f) As part of the System Study, the SI shall be responsible for Preparation of a
comprehensive System Study document by studying the legislation, business
processes and organization design of the e-District 2.0 and its Stakeholders
g) The System Integrator shall perform the detailed assessment of the functional
requirements and MIS requirements and prepare a new Refined FRS covering the
functional requirements, data integration requirements, data management
requirements etc. as part of the System Study document incorporating list of additional
features that shall result in further improvement in the overall application performance
for consideration of the CHiPS.
Page 25 of 106
h) Development of FRS with respect to the newly developed Services to be Rolled out for
the various departmental Services or Schemes and their Approval along with the UAT
of the developed Service will be an on going process throughout the tenure of the
Project as per the defined scope and timelines in this RFP
i) In case an existing application is being customized/ configured to meet the needs of
the CHiPS, the SI will provide a comparative report as part of System Study document,
on the extent of functionality currently available in the application and the final FRS.
j) The proposed application to be developed for e-District 2.0 should be cloud ready from
day one.
k) The SI has to submit following documents as part of system study
• Refined FRS covering the functional requirements, data integration
requirements, data management requirements etc.
• UAT Test Cases
• Data Flow Diagram (DFD)
6.2.2 Requirements Traceability Matrix
The SI shall ensure that developed e-District 2.0 application is fully compliant with the
requirements and specifications provided in the RFP such as functional, non-functional and
technical requirements. For ensuring this, the SI shall prepare a Requirements Traceability
Matrix on the basis of Functional Requirements Specifications (FRS), on Functional
Requirements Specification, and Technical Requirements provided by State (updated,
expanded and fine-tuned by the SI).
6.2.3 Project Documentation
The SI shall create and maintain all project documents that shall be passed on to the State
as deliverables as per the agreed project timelines.. The System Integrator shall prepare
all necessary documentation for the project, and provide them to department or its
designated Consultant for review, approval, record, reference etc as mentioned in this RFP.
Any other document(s) deemed necessary for implementation, operations and
maintenance of the hardware and network equipment’s and the overall system. The SI shall
create and maintain all project documents that shall be passed on to the CHiPS as
deliverables as per the agreed project timelines. The documents created by the SI will be
reviewed and approved by the CHiPS.
Project documents include but are not limited to the following:
1. Detailed Project Plan
a. Detailed System Study Report
Page 26 of 106
b. List of services, Service Definitions, Service Levels
c. Updated/vetted FRS
d. SRS document (Master SRS framework of e-District 2.0 application.)
e. Subsequent SRS documents only for the new services to be developed
f. HLD documents
2. e-District 2.0 Application architecture documents.
3. Documents related to Migration of Application
i. Data migration to e-District 2.0
ii. E-District application migration to cloud.
4. ER diagrams and other data modelling documents.
5. Logical and physical database design.
6. Data dictionary and data definitions.
7. Application component design including component deployment views, control
flows, etc.
a. LLD documents
8. Application flows and logic.
9. GUI design (screen design, navigation, etc.).
a. All Test Plans
10. Requirements Traceability Matrix
11. Change Management and Capacity Building Plans.
12. SLA and Performance Monitoring Plan.
13. Design of real time tools for monitoring e-Transaction volumes and for
generating real time MIS
14. Training and Knowledge Transfer Plans.
15. Issue Logs.
16. Any other document as part of SDLC or as per requirement
17. Load Testing Report
18. Security Testing and Certificate
The SI shall submit a list of deliverables that they shall submit based on the methodology
they propose. The SI shall prepare the formats/templates for each of the deliverables
upfront based upon industry standards and the same will be approved by CHiPS prior to
its use for deliverables.
All project documents are to be kept up-to-date during the course of the project. The SI
shall maintain a log of the internal review of all the deliverables submitted. Soft copy of logs
shall be submitted to CHiPS on regular basis.
Page 27 of 106
6.2.4 Proposed Document Structure
In responding to the architecture requirements in this RFP, bidders should explicitly
respond in terms of design and development, testing and implementation, and operational
phases of the project. The bidders shall necessarily include following in their technical
proposal:
a) Describe how the functional requirements will be translated into
technical implementations
b) The bidder can estimate based on existing infrastructure details provided in RFP.
c) Propose how availability, performance rates for the system will be measured and
maintained
d) Propose the details of how the existing infrastructure would be utilised and
Provide details of all hardware and networking equipment’s and off-the-shelf
software proposed for the improved system
6.2.5 Preparation of Software Requirements Specifications (SRS)
• As part of the preparation of SRS the selected SI shall be responsible for preparing
and submitting detailed requirement specification documents containing the
business scope and the detailed description of business and system functions as
per IEEE or equivalent standards which meets all the Business, Functional and
Technical (including localization) requirements of the departments concerned.
• The document should contain the requirements providing visual screen shots,
portal designs, login pages, reporting formats etc. for various functions and layouts
as part of the system, including the functions of the systems. The scope should
include for at-least 50 reporting formats as part of the scope.
• The SI should provide detailed wireframes and prototypes demonstrating the User
Interface and User Experience of the proposed e-District 2.0 system.
• The SI has to consult all the concerned stakeholders and design detailed workflows
for all the system requirements. Detailed workflows need to be designed and
signed off from CHiPS. The integration requirements have already been provided
but furthermore integration points may also have to be diagnosed, diagrams
charted out by the SI and accordingly systems will have to be implemented.
• The SI shall prepare the SRS documents and have it reviewed and approved by the
CHiPS. The State Nodal Agency will sign off on the SRS documents.
Page 28 of 106
• The SI is required to update the FRS/SRS as and when any enhancements/
modifications are made to the e-District application till the duration of the Contract
or till extensions , if required.
• Note: The SRS defined here also covers the SRS of the Services which shall be
rolled out from various departments from time to time and for which the delivery
system shall be developed for the delivery of the various schemes and services to
the beneficiaries as envisaged here in the RFP
6.2.6 Preparation of e-District 2.0 Project Plan
SI will prepare detailed work plan and estimate the timelines and resources required for
configuration, customization, extension, integration, migration and commissioning of the e-
District 2.0 software as per the State requirements. All the plans and frameworks prepared by
SI during the duration of the Contract shall be required to seek approval from CHiPS. The
documents required to be updated as per changes and progress of the project.
6.2.7 e-District 2.0 Application
Functionality and features of existing e-district application may be leveraged. It may be noted
that the e-district application has been tested (both functional and non-functional by STQC).
Likewise e-District, e-district 2.0 aims at electronic delivery of all public services at district / sub
district level, progressively. Currently 126 service are available from e-district Portal. Later on,
new services could be added depending on the requirements and the felt needs.
The Application for e-District 2.0 is the most critical component. States has already developed
e-district applications. The existing e-District application should be enhanced for state wide
rollout of e- District 2.0 project. The Integrated Service Delivery Framework released by DeitY
shall be leveraged for developing the application architecture for the State. The details on final
reference architecture for the state have been provided in this section in addition to generic
requirements.
6.2.7.1 Preparation of e-District 2.0 Application Design
SI shall prepare Detailed Design documents which will include:
a. Technical Architecture Document (Application, Network, and Security)
b. The available as well as proposed IT infrastructure shall be a part of the document.
c. Gap infrastructure
d. High Level and Low Level Design.
Page 29 of 106
e. Database architecture, including defining data structure, data dictionary as per
requirements of data storage in English and the local language with compliance to
standards defined by GoI/ State Government.
The following are the sign off deliverables for the e-District 2.0 Application Design
a. Detailed Project Plan
b. Detailed System Study Report
c. Migration Plan
d. List of Services, Service Definitions, Service Levels
e. Updated/vetted FRS
f. SRS document (Master SRS framework of e-District 2.0 application.)
g. Subsequent SRS documents only for the new services to be developed
h. HLD documents
i. e-District 2.0 Application architecture documents.
j. ER diagrams and other data modelling documents.
k. Logical and physical database design.
l. Data dictionary and data definitions.
m. Application component design including component deployment views, control flows,
etc.
n. LLD documents (including but not limited to)
o. Application flows and logic.
p. GUI design (screen design, navigation, etc.).
q. All Test Plans
r. Requirements Traceability Matrix
s. Change Management and Capacity Building Plans.
t. Design of real-time tools for monitoring e-Transaction volumes and for generating
real-time MIS
u. SLA and Performance Monitoring Plan.
v. Training and Knowledge Transfer Plans.
w. Issue Logs.
x. Any other document as part of SDLC or as per requirement.
6.2.8 Solution Architecture
The SI will develop a detailed design document that meets the users’ requirements. SI shall
be required to perform at least the below mentioned activities:
a. Preparation of e-District 2.0 Solution Architecture specifying the Functional,
Infrastructure, Data, Deployment, Network and Security Architecture for the
Page 30 of 106
proposed application.
b. Preparation of e-District 2.0 System Design Document specifying the construction
details of the system, each system component’s interaction with other components
and external systems, and the interface that allows end users to operate the system
and its functions
c. Development of Security Plan
d. Dashboard and Analytical Report design
e. Exceptions and Business Alerts definitions
General
Guidelines
1. The proposed Product/ Solution should be built on Open-
Source technologies.
2. The proposed Product/ Solution should have minimum 50%
functionality available out of the box as per RFP requirement
for e District 2.0 software.
3. The functionalities/ services of the proposed Product/
Solution should be configurable only. It means new
development/ customization is not required for the 50% of
the functionalities/ services.
4. The proposed Open-Source Product/ Solution should have
Enterprise/ OEM level support.
5. The solution design should be based on open industry
standards and protocols
6. The solution should be centrally deployed and globally
accessed
7. The solution should provide interoperability across Cloud and
on premise providers, platforms.
8. The solution should utilize “best practices” and should
preferably follow design driven architecture.
9. The solution will have to use microservices based Architecture.
( Please justify )
10. The solution should be modular, scalable and may be flexible
as a true ‘Cloud Deployable’ solution.
11. Mobility services (mobile applications) should be a key solution
component i.e. all the features can be accessed through
Page 31 of 106
mobile applications
Application 1. The solution design should be on microservices based
architecture for all environments.
2. The solution design should focus on developing workflow and
business transaction, rules management, configuration
management.
3. The SI should ensure that addition, removal, failure or update of
one component has a minimum impact on other components.
4. The SI should ensure that services should be written in such a
way that they can be automated for testing. Test automation is
necessary to ensure services can be upgraded, re-factored, etc.
without breaking other services that use them. The SI should
ensure that all services should be inherently versioned, and all
invocations must specify the version of service.
5. The SI should ensure that new versions of services should be
backward compatible with at least one or two previous versions
so that users of the service can start using new version of the
service without mandatorily making changes to their code.
6. The solutions design should provide for service abstraction, to
control what part of the service logic of an application needs to
be private (hidden) and which parts need to be made public
(consumable).
7. The solution should not only be modular in nature but be
adaptive to converse with other technology components such as
platforms and databases, complete with management suites or
with the induction of adaptors and interfaces or even smaller
bespoke solutions to support the same.
8. All applications must take into account appropriate security,
performance, efficiency and maintainability issues based on the
functional, technical and non-functional requirements and the
defined SLAs.
9. The SI needs to set up, operationalize and maintain system for
APIs and web services.
10. While doing application development and maintenance the SI
is expected to follow and comply with the processes as per
CMMi Level 5 standards.
Page 32 of 106
11. IPR of the customized codes of the e-district 2.0 build by the SI
as a solution to the requirement mentioned in this RFP shall be
with CHIPS. (The IPR (Intellectual Property Rights ) mentioned
in the RFP is covering the Software and the Code developed
by the System Integrator and supplied to the Chips. As during
the development of the software there may be collaterals like
logos, UI, Mission & Vision , Names , Schemes , Designs and
other artifacts used in the software with permissions/approvals
from various departments which can not be reused or utilized
further anywhere and are to be submitted to the CHiPS hence
IPR of all those collaterals shall belong to CHiPS and
Government of Chhattisgarh)
12. The solution must be supported by at least ‘N-1’ versions of
any underlying products. This will be required in case some /
other functionalities become non-functional upon deployment
on the latest version, or in case a roll-back is required.
13. Any proprietary software which would be part of the solution
must be of the latest commercially available version.
a. Proprietary software must be supported in terms of
upgrades, bug fixes, functionality enhancements and
patches to cater to changes to statutory requirements by
their respective OEM for the entire duration of the
contract plus 6 months after end of contract.
b. OEM support should be made available on all deployed
versions for the contract period.
14. The SI shall provision for following environments –
a. Development environment
b. Testing /UAT / Pre-Production/Staging environment
c. Sandbox (for API deployment)
d. Production environment
Data 1. Data will be owned, shared, controlled and protected as a
corporate asset of the CHiPS.
2. Data should only be accessed through application / interfaces
for create, update and delete. There should not be any direct
access to the data layer for users.
Page 33 of 106
3. The SI shall provide the details of data synchronization strategy
both in batch mode and in real time. CHiPS, in consultation with
SI, shall decide on the methodology of data synchronization
based on service requirements.
The deliverables for this activity are mentioned below:
1. High Level Solution Architecture Document (including ER Diagram and Data Flow
Diagram)
2. High Level Design Document and Low-Level Design Document (including Schema
Diagram)
3. Detailed Solution Architecture, including:
• Application architecture
• Data flow architecture
• Enterprise architecture
• Database structures
• Security architecture
• Integration architectures
• Network architecture
4. Use Cases
5. Application delivery checklist
6. UI/UX prototypes and wireframes
7. All Policy, Plan & Methodology Documents covering aspects mentioned above
6.2.9 Development of e-District 2.0
1. The SI shall deploy the Solution/ Product in accordance with the approved requirement
specifications, design specifications, and according to the project plan and carry out the
unit testing of the Customized version of the Solution/Product in accordance with the
approved test plans. The overall e-District 2.0 setup shall be implemented in following
environments i.e.
i. Development environment
ii. Testing environment/UAT environment/ Pre-Production/Staging
environment
iii. Sandbox (for API deployment)
iv. Production environment
2. The SI needs to provide software solution/product configuration, customization and
installation reports to CHiPS. In case of any COTS products, the SI should follow disciplined
Page 34 of 106
approach (as per the best practice defined by the OEM) for configuration and customization
which should not restrict CHiPS for any future upgrades to its solution.
3. The SI should ensure solution sustainability to meet all RFP requirements, any additional
procurement required will have to be taken by the SI with no additional cost to CHiPS
4. Other related requirements are mentioned below:
a) The application software developed by the SI must be user friendly so that users
can access it without having extensive training.
b) The lifecycle for each phase should be independent, i.e. different teams should
work in parallel to complete the track activities per the given timelines.
c) The SI shall also supply any other tools required to complete the integrated
solution requirements. For the integrated solution, the SI shall supply:
I. Software & perpetual licenses
II. Tools, documentation and prepare a list of items supplied. Tools shall be
part of the solution. SI should provide technologies matrix.
III. Supply latest supported version of all software to support the solution and
any
other software, tools and bolt-on/add-on application.
IV. System Documentation both in hard copy and soft copy.
Note: All licenses supplied by the SI for the purpose of this project shall be perpetual in
nature and shall be in the name of CHiPS.
The deliverables for this activity are mentioned below:
a) Development of all components of e-District 2.0 as explained at the start of scope
of work section
b) Delivery of Software along with Licenses, Operational/ Technical manuals, Library
Files, Setup Programs etc.
c) Integration of all standalone systems developed and enhanced. Also, integration
with other strategically important applications or systems identified during
requirement gathering phase.
d) Unit testing results.
6.2.10 Solution Testing
Planning for testing
1. Once the SRS is approved and design has started, the SI would refine all necessary
Test Plans (including test cases), i.e., plans for Unit Testing, Performance Testing,
Integration and System Testing and User Acceptance Testing.
Page 35 of 106
2. Test cases for UAT would be refined by SI and approval of the same is to be obtained
by CHiPS.
3. The Test Plans also include planning for the testing to demonstrate the ability to
integrate with 3rd party solutions. The Test Plans should also specify any assistance
required from CHiPS and should be followed upon by the SI.
4. The SI is required to get a sign-off / approval on the Test Deliverables (Strategy, Plan,
Designs and Specifications etc.) in order to commence the testing for the proposed
solution.
5. The SI is required to make all necessary arrangements for testing (integration, system,
functional and user acceptance) including the preparation of test data, scripts where
necessary; and procurement and setup of test environments and shall be the
responsibility of the SI.
Deliverable(s):
• Refined Test Plan
• Refined Test Design
• Final Test Case Specification
System Testing, Integration Testing, UAT
1. The SI shall run the test cases and test data and get them validated by CHiPS. The
test cases shall be comprehensive covering all scenarios according to
specifications, requirements, and design. The test data shall be comprehensive and
address all scenarios identified in the test cases. The SI should also prepare the test
data for all required integrations.
2. There should be provision for all kinds of testing viz. performance, system,
integration, load, performance, stress etc.
3. User Acceptance Testing needs to be performed for all the systems developed,
enhanced and integrated
• CHiPS will nominate representatives from different user groups based on
inputs from the SI and would facilitate UAT. The SI would make the necessary
changes to the solution to ensure that it successfully passes through UAT.
• It is mandatory for SI to incorporate / consider test cases as part of UAT test
cases for those customized and/or extensions and/or configured
functionalities identified from traceability matrix.
Page 36 of 106
• CHiPS would issue certification of acceptance for which it shall verify
availability of all the defined services as per the contract signed between the
SI and CHiPS. The System Integrator shall be required to demonstrate all the
services / features / functionalities as mentioned in the agreement.
Prerequisite for carrying out UAT activity shall be:
a) All documentation related to solution and relevant acceptance
test document should be completed & submitted before the final
acceptance test to CHiPS.
b) The training requirements as mentioned should be completed before
the final acceptance test.
c) Licenses/ Manuals/ Brochures/ Data Sheets/ CD/ DVD/ Media for all
the supplied components should be provided to CHiPS.
Deliverable (s):
1. Test Data
2. Testing Reports
3. Necessary modification in software for passing the UAT
Performance Testing & Security Certifications
1. Performance testing of the solution would be carried out using the envisaged peak
load with a multiplier, to monitor the application response times and other
performance parameters. Performance testing would be carried out every 6 months
to ensure the application performance is as per requirement. Any additional
hardware, software and any other components required to meet the performance
SLAs, would be provided by the SI at no extra cost.
1. SI is required to submit the report for the performance testing to CHiPS; the testing
will be monitored by CHiPS or any agency appointed by CHiPS.
2. Performance testing would include load / stress testing. This would need to be carried
out on the exact architecture as would be used in the production environment
(solution architecture as well as computing capacity). All necessary tools to carry out
testing would be provided by SI.
3. SI is required to obtain ISO27001 certifications within 6 months of Go-live of all
services and must maintain the same throughout the contract duration
Deliverables:
Page 37 of 106
1. Performance Test Reports
2. Security Certifications
Go – Live
Definition of Go-Live
For the purpose of RFP, “Go-Live” has been divided into two phases. Go-live phase 1 is
defined when the components of workflow digitization application, document management
system and acceptance of different modes of digital payment is enabled for all relevant
services listed in Annexure- 8 , is accepted by CHiPS and are in conformance with all the
requirements of this RFP.
Go-live phase 2 is defined when the components of Web portal, Mobile app and grievance
management solution is enabled for all services in Annexure – 8, is accepted by CHiPS and
in conformance with the requirements of this RFP. The below describe the criteria of
acceptance:
Requirement Criteria of acceptance
Functional
Requirements
Review
• The e-District 2.0 system developed/customized by SI shall
be reviewed and verified by the CHiPS or its nominated
agency against the functional requirements signed-off
between CHiPS and SI.
• One of the key inputs for this testing shall be the traceability
matrix to be developed by the SI for e-District 2.0 system.
• Apart from Traceability Matrix, SI may develop its own
testing plans for validation of compliance of system against
the defined requirements.
• The acceptance testing w.r.t. the functional requirements
may be performed by CHiPS or independent third-party
agency (external auditors) as well as the selected internal
department users (for User Acceptance Testing).
Security review The software developed for e-District 2.0 system shall be audited
by the CHiPS or its nominated agency from a security and
controls perspective. Following are the broad activities to be
performed by
CHiPS or its nominated agency as part of Security Review. The
Page 38 of 106
Requirement Criteria of acceptance
security review shall subject thee-District 2.0 system to the
following activities:
• Audit of Network, Server and Application security
mechanisms
• Assessment of authentication and user control in
application, component or modules
• Assessment of data encryption mechanisms implemented
for the solution
• Assessment of data access privileges, retention periods
and archival mechanisms
• ·Server and Application security features incorporated etc.
Performance • ·Performance is another key requirement for e-District 2.0
system and CHiPS or its nominated agency shall review
the performance of the deployed solution against certain
key parameters defined in requirements and the service
level metrics described in this RFP and/or agreement
between CHiPS and SI.
• Such parameters include request response time, work-flow
processing time, concurrent sessions supported by the
system, Time for recovery from failure, Disaster Recovery
drill etc.
• ·The performance review also includes verification of
scalability provisioned in the e-District 2.0 system for
catering to the requirements of application volume growth
in future.
Page 39 of 106
Requirement Criteria of acceptance
Availability • e-District 2.0 system should be designed to remove all single
point of failures.
• Appropriate redundancy shall be built into all the components
to provide the ability to recover from failures.
• The CHiPS or its nominated agency shall perform various tests
including network, server, security, DC/DR failover tests to
verify the availability of the services in case of
component/location failures. (Annexure-check)
• CHiPS or its nominated agency shall also verify the availability
of e-District 2.0 services to all the users in the defined locations.
Manageability
review
• CHiPS or its nominated agency shall verify the
manageability of the e-District 2.0 system
• The manageability requirements such as remote
monitoring, administration, configuration, fault identification
etc shall have to be tested out
Service level
monitoring system
• The Acceptance Testing and Certification agency shall
verify the accuracy and completeness of the information
captured by the Service Levels monitoring system
implemented by the SI and shall certify the same.
• The solution deployed for service levels measurement shall
be configured to calculate the penalties as defined in the
SLA. The SI shall provide complete access to the Service
Levels
• Reporting System/BI tool including the manner in which the
configuration of the system has been done.
• The SI shall provide full access to generate reports from the
systems to CHiPS officials or its nominees.
Project
Documentation
• CHiPS or its nominated agency shall review the project
documents developed by SI including requirements,
design, source code, installation, training and
administration manuals, version control etc.
• Any issues/gaps identified by CHiPS or its nominated
agency, in any of the above areas, shall be addressed by
the SI to the complete satisfaction of CHiPS.
Page 40 of 106
Requirement Criteria of acceptance
Data quality • CHiPS or its nominated agency shall perform the Data
Quality Assessment for the entire data
• The errors/gaps identified during the Data Quality
Assessment shall be addressed by SI before moving the
data into production environment, which is a key milestone
for Go-live of the solution.
1.
In case there is any shortcoming (which does not impact any of the Service levels) in the
deliverables as above, CHiPS may, at its discretion, permit Conditional Go-Live. However, SI
is responsible for completion of all related pending activities identified within 3 months or
earlier of conditional GO-LIVE. It is to be noted that the next phase timelines shall be initiated at
time of Conditional Go-Live approval.
Deliverable(s):
1. Defect Reports
2. At the end of Go-Live:
i. Updated system design documents, specifications,
ii. Latest source code, application deployment files, configuration files for entire
solution
iii. Updated user manuals, administration manuals, training manuals etc.
iv. Software change logs etc.
6.2.11 Solution Documentation
1. The SI shall document all the installation and commissioning procedures and provide the
same to the CHiPS within one week of the completion of the go-live.
2. The SI shall be responsible for preparing process documentation relating to operation and
maintenance of the solution. The process documents shall be formally signed off by
CHiPS.
3. All documentation will be supplied both in Hardcopy and Softcopy format.
4. Each process document shall clearly define the roles and responsibilities, detailed
steps for execution the defined task, detailed configuration steps etc.
Page 41 of 106
5. CHiPS expects the SI to document the operations and management processes as
per standards defined in “Compliance to Standards and Certifications” in section 8 of
this RFP
6.2.12 New e-District 2.0 Application
The following enhancements should be taken up by SI as part of the development.
a. Functional Enhancements
b. Operational Enhancements
c. Technical Enhancements
d. Non-Functional Enhancements
The broad list of activities/enhancements as part of the Scope of the RFP is explained in
sections further.
6.2.12.1 Functional Enhancements
The SI shall Co-ordinate with
a) Existing System Integrators for the Migration of existing application
b) Shall co-ordinate with the respective departments for designing the business process
and implementing the same in e-District 2.0
c) Shall Coordinate with existing SI and departments for Integration requirements
CHiPS will support the new SI for coordinating with the existing SI and departments.
The enhancements pertaining to business process re-engineering, addition of new services
and other potential B2C & G2C services which can be offered in e-District 2.0 are given in
detail below:
# Requirement
1
General • e-District 2.0 Portal should be developed according to GIGW
Guidelines, e-Gov Standards (egovstandards.gov.in) and all other
guidelines as published by Government of India and Government
of Chhattisgarh.
• Multilingual: The portal would primarily be available in Hindi &
English.
2
Single point for
G2C Services
• There are certain services offered by various department and
is not part of e-District Portal.
Page 42 of 106
• The objective is to have all such department use Uniform
Interface (UI) which is e-District 2.0 portal to provide all G2C
services.
• SI shall do Web Service/API integration for all G2C services
available.
• The details would be shared with the successful bidder.
3
Business/
Government
Process Re-
engineering
• Certain services require multiple requests from citizens for
various certificates and visits to Departments for servicing of
a one logical service.
• The services have to be assessed, checked for the feasibility
of re-engineering from the business process perspective. The
re-engineered process needs to be taken forward for
implementation in e-District 2.0.
• The SI shall interact and discuss with the concerned
departments for the below optimization possibilities –
➢ Can the Business process be simplified by eliminating
few steps/verifications?
➢ Can the overall SLA in fulfilling the service be
reduced?
4 Re-engineering
of Forms
• Some of the services have huge number of fields that are
captured as part of inputs while servicing the request. The SI shall
re-assess the forms and check the feasibility of reducing the
number of fields/attributes, supporting documents required.
Wherever possible, the basic personal details shall be auto-
fetching of data. The SI shall co-ordinate with departments for the
possible optimizations in the above and incorporate the changes
in e-District 2.0 application.
5 SLA The services should be assessed and checked for optimizing the
SLA’s. The SI shall co-ordinate with the respective departments to
check if they can be achieved in less number of days. It shall be either
by optimizing the process or eliminating any redundant steps. The
optimized process shall be implemented into the e-District 2.0
application.
Page 43 of 106
SI should also deploy the tools for monitoring the uptime of e-District
2.0 Application.
6 Self Help Chat Bot for Self Help for Citizens – basic queries (not limited to) like
Status tracking, document checklist, CSC/LSK Locator, Application
Fee etc. Chat bot will be enhanced during the contract period based
on the queried received from citizens.
7 General • Update relevant documents (like User Manual, Service Manual
etc.) of e-District according to e-District 2.0 Application
• Bi-Lingual Portal
• OTP based email/contact number updation of portal users
• Feedback form for Citizens/Government Users
8 Enactment of
LSG Act-2011
• SI has to study the Lok Sewa Guarantee Act – 2011 and should develop the system to enact the Lok Sewa Gurantee Act – 2011 effectively. Some of the primary requirement is to make a provision for appeal in case of breaching of timelines as per the act.
• Email/SMS alerts will be generated on breaching of service levels of LSG Act.
• System should also able to issue digitally signed Show Cause Notice (Pre-defined template with maker and checker) on breaching of service levels of LSG Act on breaching of SLAs as mentioned in LOK SEWA GUARANTEE ACT - 2011, system should notify the competent authority along with SCN template to be issued to concerned officer.
9 Analytical
Dashboard
• e-District should have analytical dashboard (textual and visual),
as it helps to process data to find trends which also help in
forecasting future events.
• Should include all the reports available in existing e-District
portal and also generate customised reports as per the
requirement of Districts/State Departments.
10 Centralized
Ticketing
Management
Tool
Helpdesk support staff receives daily requests for service through
multiple channels, including web, email, phone, mobile and in
person. Without a centralized system for requests, tickets get lost in
the fray. A centralized portal automates the process and takes
human error out of the equation. This tool can also be used by citizen
for reporting any issue.
Centralized Ticketing Management Tool should follow standard
business rules and should also have following functionality in addition
to modules present in existing e-district helpdesk
Page 44 of 106
• Ensure timely resolutions by defining response and resolution
SLAs with defined escalation paths.
• Automate every step of the ticket life cycle
• Make sure that no ticket is left unassigned by automatically
assigning tickets
• Communicate better with end users with automated SMS/email
notifications
• Assigning incidents to concerned resources as soon as they are
logged into the help desk software.
• Prevent SLA violations by enabling multi-level proactive
response and resolution escalations.
• Keep end users informed at every step of the incident
management process using automated notifications.
• Tracking of status and progress of incident reported.
• Publish knowledge base articles in the self-service portals to
reduce the flow of incidents into the help desk.
• Improve turnaround times and resolution quality by maintaining
a knowledge base of advanced technical solutions exclusively
for, and limited to, technicians.
11 Escalation
Mechanism
Helpdesk should have escalation mechanism as when applicant expectations are not met, or they feel that their views have not been heard, it is human nature to want to “intensify” and escalate to the next level. There is a general belief among many applicants that if they escalate to a senior leader, then action will happen faster
12 Digital Payment
enablement
SI will support the banking partner of CHiPS for following facilities. SI will customize the application in order to enable the digital payments from e-District Portal.
• Digital Payments at all Channels (LSK/CSC/Web/ /Mobile)
• Mobile Payment
• Mobile Wallet Payment
• Online collecting the departmental fee and transferring it to concerned department or concerned office.
• Provision for detailed MIS for reconciliation of payments.
13 Module for Change Request Management
SI will develop the module to raise the change request from District/CHiPS. The process for raising change request and its approval workflow will be decided mutually. The proposed e-district 2.0 Application should record and store all change request made by CHiPS/Districts/Department.
14 Enhancement
of Generic
Work Flow
Engine of
This generic workflow engine will allow easy creation of workflow for new services with drag and drop feature and minimum technical programming support and thus enable the State government to create new services as and when required by the various Departments. At the minimum, the workflow engine should have the following features:
Page 45 of 106
existing e-
District
Application
• Feature to use the master data for the auto-populating the forms and dropdowns specifically with reference to :
o Name of District, Tehsils, Blocks & Villages o Designation of officials involved in the
processing of the application
• Creation of application form, by “drag & drop” feature using meta data standards
• Tool for applying Validation
• Defining the workflow for the approval of the form, by providing various options like :
o First in First out o Multilevel Workflow o Defining a citizen charter/delivery of service in
a time bound manner
• Creation of the “output” of the service, i.e. Certificate, Order etc.
• Automatic reports o of compliance to citizen charter on delivery of
services o delay reports
• Customization of Generic Workflow Engine as per States Requirement
15 District Web
Page and
Dashboard
Personalised district webpages which should display the Key Performance indicators like
• District Dashboard
• Service wise analysis of transaction data.
• List of Government Users for particular districts and details of appellate Officers
• Top 5 and Bottom 5 Government User list (based on in time and beyond time approval).
• Top 5 and Bottom 5 LSK/CSC Operators (Based on the quality of application submitted)
• Top 5 and Bottom 5 Services for District and State
• Any other information required by District Administration
16 Citizen
Registration
SI has to study the existing application forms and will identify the exhaustive list of fields of application forms. Every new user/citizen coming to LSK/CSC/Web-Portal/ Mobile app of e-District 2.0, should be first registered with the details required in various application form of existing e-District Services. Based on the registration application field should be auto populated.
17 Notifications to
Stakeholders
There should be a system to circulate/broadcast the information or communication to all project stakeholders (CSC/LSK/CHOiCE/Citizen/Departmental User etc.) in the form of SMS or Web Based Information Broadcasting System.
18 State Admin
Module
State Admin Module should have following functionality in addition to
modules present in existing e-district application plus
• Dashboard – Portal Statistics
• User Management
• User Profile Management
Page 46 of 106
• Users DSC Validity Status
• FIFO Status (District and State Wise)
• Display Number/email of Users
• Display Number of Concurrent Users
• Number of Registered Users (Kiosk/Government User/Mobile
App User)
• Real time Status of Call Logged and Resolution status, analysis,
reason for delay resolution/non-resolution
• PUSH SMS/email for registered Users/Citizens
• Display of feedback received from Citizen/Government Users
• District Admin Module Management
19 District Admin
Module
State Admin Module should have following functionality in addition to modules present in existing e-district application plus
• User Management
• User Profile Management
• FIFO Status (District Specific)
• Users DSC Validity Status
• Display Number/email of district users
• Real time Status of Call Logged and Resolution status, analysis,
reason for delay resolution/non-resolution
• PUSH SMS/email for registered Users/Citizens
• District wise display of feedback received from
Citizen/Government Users.
20 HRMS and
PMIS for DeGS
(for e-District
Manager, District
Technical
Manager and
person deployed
by CHiPS )
This module should include basic role based HRMS and PMIS component. The indicative list (not limited to) is as below:
• Managing payroll
• Recruitment and on boarding
• Gathering, storing, and accessing employee information
• Keeping attendance records and tracking absenteeism
• Leave Management
• Travel Management
• Performance evaluation
• Benefits administration
• Learning management
• Employee self-service
• Employee scheduling Analytics and informed decision making
Salient features of eDistrict 2.0
1. Scheme/service discovery
a. Scheme/service discovery – A resident of Chhattisgarh who wishes to avail any
scheme or service should be able to find eligible schemes/ relevant services
and the system should identify schemes and services proactively based on
unique citizen profile. The profile should be able to build incrementally with the
use of application for different schemes and services.
i. Scheme and service search
Page 47 of 106
1. For a user who already knows the scheme or service they wish
to apply for, the system should allow them to search for the
scheme
2. The user should be shown the scheme benefits and documents
required on the search result page
3. The user should be asked scheme/service specific questions to
check exact eligibility before citizen is allowed to apply for the
scheme
ii. Proactive scheme and service recommendation
1. The platform should be able to proactively help citizens identify
the scheme or service best suited for them.
2. For schemes, the citizen would be required to provide few
demographic details about themselves and the platform should
identify all the schemes they are eligible for.
3. The schemes should be organized in a logical manner
4. The user should be able to save schemes for applying later
5. The user’s exact eligibility should be checked on the system
before he is allowed to apply.
6. All additional information provided by the citizen should be used
to update the schemes and services the user is eligible for
7. The system should also alert the user in case new schemes or
services are added to the platform
2. Scheme Application by Citizen
The new system is expected to make the application process easier for citizens.
Citizens would not be required to provide any document for which values are available
in electronic databases. Citizens will only have to provide reference to the databases
which have been integrated with the platform. Platform should help citizens track the
applications submitted by them. In case the residents application is incomplete or
approving authority requires additional information, the resident should be able to
provide the information through the platform. Additionally, if some action is pending on
the resident, he/she should be informed via the app or SMS and be able to complete
the application.
3. Workflow system
The current eDistrict platform provides a workflow mechanism for approval of a
citizen’s application should continue for the existing schemes and services. The
platform provides multiple levels for approval of a particular application. Each user may
have the right to approve, reject or send back to previous stage. The platform should
also allow officers to add comments on the received application before sending it to
the next stage.
4. Application approval
Any application submitted must be approved in an automated manner. The objective
of the application approval is to only verify the values submitted by the citizen.
Verification would be done as follows:
a. Electronic Database with unique identifier – Citizen should not be expected to
provide any documents if the documents are available in an electronic
Page 48 of 106
database. For example, information available on the PDS database will be
verified based on ration card number and consent by the citizen.
b. Electronic database without unique identifier – The data will be verified based
on entity resolution from the source system.
c. Documents not available in any electronic database will be verified by the
document issuer or at panchayat level.
5. Key functionality for bureaucrats/Government officials
a. Government officials should be able to view the applications that are assigned
to them. Once they identify the applications and corresponding actions, they
must be able to complete the actions on eDistrict 2.0.
b. Government officials should be able to approve or reject applications based on
the merits of the applications. They should be able to provide the reason for
approval or rejection within the platform.
c. Government officials should be able to filter the applications which are pending
based on multiple filtering criteria.
d. For deficient applications or clarifications, the government officials should be
able to update the system and therefore the applicant about pendency in the
application.
e. Government officials should be able to track the consumption of welfare
schemes, number of applications pending, average time to process an
application, demographic profile of applicants etc through intelligent
dashboards.
6. Easy on-boarding of schemes and services without the need for any code changes to
core platform.
a. Scheme and service configuration
i. Administrative users should be able to configure any scheme or service
on the platform by only configuration changes and no program changes.
ii. A scheme or service should undergo a workflow for approval and
verification to be made active.
iii. Access to different functionality should be restricted
iv. Users should be able to attach relevant documents while configuring a
scheme or service
v. Users should be able to download the scheme information as a PDF
document
b. Scheme and service updates
i. In case of any changes to the scheme or service rules, the system
should allow users to modify the information
ii. Updates should not be reflected to production without approval
iii. Modifications should be tracked and an audit trail must be maintained
for the same.
c. Scheme view
i. Authorized users must be able to see data related to scheme or service
ii. Authorized users should be able to download the scheme related
information from the scheme management platform
iii. System should generate reports on scheme and service usage
d. User management
i. Administrators should be able create users and give them specific
access
Page 49 of 106
ii. Each user should be assigned a role and corresponding privileges
e. Scheme search
i. enable user to search schemes basis various filtering criteria of the
schemes.
7. Key features for government appointed agents
Agents such as volunteers or CSC operators or NGO partners should be able to
assist people who are unable to access the eDistrict 2.0 on their own.
a. Agents should be able to apply on behalf of people based on consent. The
consent may be taken through mobile OTP of the applicant or Aadhaar
biometric based authentication or any other secure mechanism.
b. The agent should be able to view applicants information only based on consent
taken each time there is a request to view data about the applicants
application(s).
c. The agents activities should be tracked by the system and any abnormalities
must be highlighted.
d. The government may allow agents to charge an assistance fee and the system
should be able to track the charges permissible.
e. Agent should not be able to store any information locally for security and
privacy purposes.
f. Agent should be able to generate reports on the applications submitted by
them.
8. Key features of admin console
a. It is proposed that an administrative console should be provided to added,
delete and deactivate schemes and services. This feature will also be used to
configure scheme/service details including scheme/service rules, benefits
calculations, procedure to apply and other details about a scheme/service.
b. The admin console should allow privileged users to create scheme and service
and configure workflows on the platform. The mechanism to develop workflows
should be intuitive and not require any programming.
c. The admin console will be used to maintain master data for the system
d. The admin console will be used to manage translations of text to Hindi
e. The admin console will be used for user creation, deactivation and deletion
6.2.12.2 Technical Enhancements
Given below are the technical enhancements of e-District 2.0. The enhancements pertain to
the existing e-District application with respect to having a refined user interface, integration
and adherence to standards
# Requirement
1 General • Proposed e-District 2.0 application should be IPV6 Compliant.
2 Uniform UI
Interface and
Multi-Channel
Access
• The User Interface needs to be re-designed to follow a responsive
design in order to adapt to various devices (tab, smart phone,
desktop) without maintaining redundant code bases for
presentation layer to fit each device. The portal must run in Hindi
and English.
Page 50 of 106
# Requirement
• GIGW compliance
3
Integration
1. e-District 2.0 integration with various Departments for fulfilling the
services follows for the following scenarios based on Department
interfaces –
a. If the Department had web services exposed, E-District 2.0
application consumes the same to provide the appropriate
services.
b. If the Department had a well-defined UI interface already
available, E-District 2.0 application navigates to the
department User Interface which further processes the
complete request at its side and updates e-District 2.0
application about the status.
c. If the Department had no technical staff or any web services
exposed, e-District 2.0 code base has the entire flow from
User Interface to backend (database).
2. Integration with e-Sign
3. AUA and KUA Integration to enable the AADHAR based
authentication and fetching of basic information
4 SSDG & e-
District
Services
1. The SSDG and existing e-District services need to be migrated
to the e-District 2.0.
2. The Scope of the SI shall include the transition from e-District
Service Providers to study the existing code base and
functionality supported.
5
mCHOiCE
Mobile APP
• All the services being offered as part of the e-District and e-District
2.0 will need to be developed and should be available through
mCHOiCE and mCHOiCE Dashboard Mobile APP.
• The scope of the SI shall include developing the new/upgrade Mobile App in Android/iOS. The list of services would be provided by CHiPS. The citizen will use E-District 2.0 Mobile App for the following use cases.
• Service Discovery – To discover the list of all enlisted public services in the State
• Service Eligibility – To check the eligibility of a resident for all enlisted public services being delivered in the State
• Status check – To check the status of an applied and onboarded public service
• Data Correction or Aadhaar seeding – To update Aadhaar or data in an already availed and onboarded public service
• Grievance – To lodge or check the status of a lodged grievance
Page 51 of 106
# Requirement
• During the contract period, the Implementation Agency will provide
all updates, patches/fixes, version upgrades and new versions.
6 Integration
with IPeG
(Integrated
Pro-active e-
Governance
System)
E-District 2.0 shall integrate with Integrated Pro-active e-Governance
System which will be developed soon by CHiPS for other citizen centric
services. (At no extra cost)
7 Integration
with Digi
Locker
E-District 2.0 shall integrate with Digi-Locker and for integration of
already issued certificates.
8 Integration
with e-
Governance
Application of
GOI and GoCG
E-District 2.0 shall integrate with the GOI and Government of
Chhattisgarh e-Governance Application. The SI has to integrate with
the e-Governance Application as and when suggested by CHiPS. (At
no extra cost)
9 Adherence to
Standards
The E-District 2.0 Portal should adhere to the guidelines specified in
SPF (State Portal Framework). Also, refer the best practices at for the
recommended IT and e-Governance Standards and Architecture
compliance.
10 Cross browser
compatibility
All the features developed as part of this Web Portal shall be cross-
browser compatible. The site should be viewable in the major browsers
available. (IE 9 and above, Chrome, Mozilla).
11
Security
1. Secure Design and coding practices should be
adopted to ensure the modified UI is developed and
implemented securely. (as per industry standards)
2. The portal shall be implemented with proper
validations and checks to ensure the following
known vulnerability are handled properly in the
application system.
a. Non-validated input (i.e. input fields shall conform to the
desired formats and values)
b. Broken access control
Page 52 of 106
# Requirement
c. Broken authentication and session management (i.e use of
account credentials and session cookie)
d. Cross-site scripting("XSS")
e. Buffer overflows
f. Injection vulnerability flaws (e.g SQL injection, command
injection etc.)
g. Improper error/exception handling
h. Insecure storage
i. Denial of service
j. Insecure configuration management
3. The Portal shall not disclose to users more
information than necessary when a failure or error
occurs.
4. Password shall not be hard-coded into any software
or programs
5. The portal system shall have the facility for
deactivation of the access rights of the user who
have resigned/ retired from services in a timely
basis to prevent unauthorized access.
6. The Security Audit support has to be provided by
the SI and should close any non-compliances as
reported by the Third Party auditor.
12
Privacy
Personal data of the individual captured and stored in Database is to
be secured and not compromised during the complete span of
development and maintenance.
13
Configuration
The application should be deployable in various environments (say
development, staging/testing, pre-prod, prod) with changes only in
configurations. The various department users who are authorized to
approve/reject (if any) should be configurable.
14 Storage
Study of existing system and cater the issues of increasing Database
size and shall propose Document Management System.
6.2.12.3 Operational Enhancements
Given below are the Operational enhancements to be done in e-District 2.0 to improve the
efficiency of service delivery.
Page 53 of 106
The SI shall co-ordinate with the respective departments and CHiPS for ensuring the initiatives
that are being taken up. Resources for O&M are proposed which includes the resources for
development of any new service as per the requirement of Department.
# Requirement
1 Effective
tracking of
rejected/
Beyond SLA
The objective is to enforce initiatives that shall ensure, department
officials act on the service request (either approve or reject with
appropriate reason).
1. The reject reasons shall be further enhanced with more
exhaustive list so that the department official would be able to
select the right option for rejection.
2. The SI shall co-ordinate with department officials to
expand/modify the reject reason list (displayed as drop down) to
include all possible appropriate reason descriptions.
3. If the service was rejected due to missing document, the citizen
should be able to re-submit the same request as amended
request with just paying some minimal charges. As of now, the
citizen is submitting a new request and paying the complete
charges once again. The SI shall make the appropriate changes
in the application to facilitate the retrieval of the earlier
request/transaction and enable the re-submission flow.
4. Department shall review the rejected cases (other than missing
documents) and Beyond SLA cases to ensure that officials
concerned acted upon the pending requests. The scope of SI
shall be to facilitate the generation of this report on a scheduled
basis and make it available in MIS dashboard for CHiPS and
departments.
5. Applying Strong Validation – Study of existing e-District
Application and send back/rejected cases and implementation of
strong validation while submission and verification/approval level
in order to reduce the Sent Back and Rejected application
2 Citizen
Satisfaction
Index
1. The focus is to find more effective mechanisms in capturing the
Citizen feedback such as -
a. Having a system for capturing the feedback from citizens
on the service availed.
b. Having an online channel to capture descriptive feedback
& rating.
Page 54 of 106
# Requirement
c. Have a mechanism to capture the rating via SMS.
2. The scope of SI shall include
d. Integration with Jansamvad to facilitate addressing of
grievances from citizens.
e. Facilitate a web interface to enable the user to submit
descriptive feedback
f. Develop SMS Channel - asking for a rating (1-Not
Satisfied, 2-Satisfied, 3-Good, 4-Very Good) when the
transaction is closed (approved/rejected)
g. The SMS Gateway that exists in e-district shall be re-
used for this purpose
3 Monitoring
and Ranking
of VLEs /
Capturing
and feedback
at VLE level
1. Ensure mechanisms to monitor the operations of VLE/Citizen
Service centres (LSK/CSC/CHOiCE) for tracking of the below -
a. Ranking of Operators based on Send Back/Reject Cases. b. Service Denial to citizens for low revenue generated services. c. Capture feedback from citizens through online, SMS channels
and helpline numbers for tracking the above.
4 Operational
Support Unit
(OSU)
Bidder has to deploy the Operational support unit. The bidder shall make
their own composition of OSU team w.r.t. category of manpower and
provides detail in Technical document with the Bid. The OSU team
should comprise of minimum 10 technical manpower on bidder’s payroll
and will be responsible for below mentioned task:
• Functional changes in the application software/Mobile App
• System administration
• Modification or Enhancement in application software
• Migration of transactional data
• Generation of MIS report as per the District/CHiPS Requirement
• Supervision of Project
• Data back up
• Any changes in the workflow and core application framework
• Any new integration with other system as per project requirement
• Bugs / Issues in the Application Software/Mobile App
. The CHiPS won't pay any extra cost for
development/customization/service integration after Go-Live of
Page 55 of 106
# Requirement
application software. Any additional development/customization in
application software will be done by OSU team.
Also bidder has to develop (including its O&M) new services (if any
requirements received from any department/Government of
Chhattisgarh) during the contract period without any cost implication as
therefore the team at onsite has been asked to be present during the
tenure mentioned against each resource at Vol-II. However,
development of any new service during any quarter of contract during
the O&M period will be mutually discussed and agreed by CHiPS and
selected bidder. The new service development by OSU should include
• AS IS Study and preparation of SRS
• Verification of Master Data and creation of Master Data
• Development and Testing of Electronics form along with required validation (Simple/Special/Complex/Web Service validation)
• Workflow Creation and Mapping of Users/DSC
• Certificate Designing
• Training
• Quality Certification
• Other associated task required to make the service live in e-District 2.0
• Inclusion of new medium of service delivery like social meda platform, Mobile applications as mentioned in the scope
The CV for OSU team will be provided with the bid. Bidder should
ensure that OSU team deployed will be of equivalent experience and
competency to the profiles shared at the time of Bid submission.
Seating space and internet may be provided as per project requirement
at Raipur/Naya Raipur. Bidder has to arrange the required
Laptop/Desktop and alternate internet connections by his own.
6.2.12.4 Obtain Quality Certification for e-District 2.0 Application
The SI will be responsible for engaging STQC to conduct the assessment/review for the
system before “Go Live”. The CHiPS shall have the right to audit and inspect all the procedures
and systems relating to the provisioning of the services. If there is any change/addition in the
application’s functionality then the SI will have to obtain the STQC Certification for the
changes/additions.
Page 56 of 106
SI shall ensure the following points are duly addressed for successful completion of STQC
Certification:
I. Successful completion of Application Audit. Application audit will include:
A. Functionality audit that will map the functionality delivered to the FRS
agreed upon during development phase.
B. Identify the nature and type of transactions being processed by
the application systems.
C. Determine systematic measures implemented to control and secure
access to the application programs and data including password controls,
user authentications, roles and responsibilities, audit trails and reporting,
configuration and interface controls, etc.
D. Review of database structure including:
1. Classification of data in terms of sensitivity & levels of access
2. Security measures over database installation, password policies and
user roles and privileges
3. Access control on database objects –tables, views, triggers,
synonyms, etc.
4. Database restoration and recoverability
5. Audit trails configuration and monitoring process
6. Network connections to database
E. Review of Network and Website will include:
1. Penetration and vulnerability testing
2. Security exposures to internal and external stakeholders
F. Definition and Implementation of Security Policies and Controls will include:
1. Define and implement backup process, including schedule,
storage, archival and decommissioning of media
2. Define physical access controls review (over DC and other
critical area)
3. Define IT Change Management process, Incident
Management process – covering identification, response,
escalation mechanisms
4. Define and implement Anti-virus (malware) controls –
patching, virus definition file update
6.3 Non Functional Requirements
The non-functional requirements relating to performance, availability, deployment,
implementation, operations and others are listed in the subsequent subsection. Based on the
Page 57 of 106
assessment of the requirements listed below, SI shall prepare System Requirement
Specifications (SRS) and obtain a formal sign-off before proceeding with the design and
implementation of the solution.
# Requirement
1 Performance
As e-district 2.0 is an enhancement of existing e-District
application, all enhancements should comply with existing SLAs.
2
Scalability
1. System should be able to handle the increase load as the user
base is expected to increase by each year.
2. The system provides for horizontal scalability in such a manner
that a new server can be added (or removed) dynamically, as
and when required in future, without disturbing the normal
functioning of production system
3 Availability
The system shall provide 24 X 7 availability and with 99% uptime
(Application and Hardware Both).
4
Reliability
1. E-District 2.0 Portal must be a reliable system with consistent
and consistent behaviour in terms of quality, availability,
scalability, and performance.
2. The system should be robust and tolerant to certain level of
faulty use. For example: The entire system should not
collapse/crash if an user accidently inputs wrong value, or
uploads incorrect data.
3. System should be able to handle the unavailability of any
service. If the service is “core” to the use case an outage
message can be displayed. If the service is “non-core” then the
transaction should be able to be completed.
4. Exception handling needs to be built into all components so that
all exceptions and errors are trapped and handled properly.
Error information should include enough details to accurately
describe and debug the problem.
5. All data that is accepted from the end-user or sent in via HTTP
request will be validated on the server before it is used in
processing to ensure that the data type and ranges are
appropriate.
5 Manageability
E-District 2.0 Portal is required to cater to stakeholders across the
state accessing it from multiple points and through multiple
channels. Hence the manageability of this system is essential to
Page 58 of 106
# Requirement
ensure effective monitoring and timely resolution of any issues
surrounding performance, availability and security.
6
Usability
1. The application must be user friendly and any new user must be
able to easily use functionalities offered by the system.
2. Error messages or pop ups must be helpful to an extent that user
can take next action and does not experience too much of
discomfort.
3. User interface must be simple yet user-friendly, and the workflow
should be intuitive so that user can complete their work with least
time and effort.
7
Acceptance Testing, Audit & Certification
The primary goal of acceptance testing, audit and certification is to
ensure that the E-District 2.0 system meets requirements,
standards, and specifications as set out in this document and as
needed to achieve desired outcomes. The basic approach for this
will be ensuring that the following are associated with clear and
quantifiable metrics for accountability:
a. Functional requirements
b. Infrastructure Compliance Review
c. Availability
d. Performance
e. Security
f. Manageability
g. SLA reporting system
h. Project Documentation
i. Data Quality Review
This assessment shall be done by CHiPS/Third Party Auditor. Contracting Authority will bear the third party auditing charges.
8
Technical Solution Architecture Requirements
• The e-District 2.0 solution needs to be architected using robust
and proven software and hardware technologies like
Microservices based architecture and open industry standards.
• The solution architecture should be built on sound
architectural principles enabling fault-tolerance, high-
performance, and scalability both on the software and hardware
levels.
9 Software Architecture Requirements
• Software architecture must support web services standards
including XML, SOAP, UDDI and WSDL
• Software architecture must support appropriate load balancing
for scalability and performance
Page 59 of 106
# Requirement
• Software architecture must support flexibility in adding
functionalities or applications.
• Software architecture components should utilize the high
availability, clustering, and load balancing features available in
the proposed hardware architecture to increase system
performance and scalability features.
• Software architecture must support trace logging, error
notification, issue resolution and exception handling.
11
Development, Testing, Staging, and Production Requirements
• Appropriate development, test, and staging hardware
environments should be provided and explained how they are
related to production environment. This must be supported by
explanations on how the development, test, and staging
environment support the implementation activities of e-District
2.0 Solution.
• Development and test environment should include configuration
management capabilities and tools for system configuration,
versioning scheme, documentation, change control processes
and procedures to manage deployment of solution deployment.
• The test, development, and staging environment should include
required workstations, desktops, and tools appropriate to
support development, testing, and staging, and deployment
tasks.
• The development, test, and staging hardware environments
must include similar operating systems, software components,
products, and tools to those of production environment.
• The development, test, and staging environments should be
independent logically and physically from the production
environment and of each other.
• The development environment should be used for development
and should be configured to allow access for developers‟
workstations.
• The staging environment should be used for functional and user
acceptance testing, stress testing, and performance
benchmarking.
• The test environment should be used as a testing environment
of e-District 2.0 Solution and its software components and
products. The test environment should be a scaled-down
configuration of the production environment.
• Development, Test, Staging & Production at DC/Cloud. Only
Development and Production will have DR.
12
Security
• A secure solution should be provided at the hardware
infrastructure level, software level, and access level.
• Authentication, Authorization & Access Control
Page 60 of 106
# Requirement
3 factors (User ID & Password, Biometric, and Digital Signature)
security mechanisms should be implemented to enable secure
login and authorized access to portal information and services.
• Confidentiality of sensitive information and data of users and
portal information should be ensured.
• Appropriate mechanisms, protocols, and algorithms necessary
to protect sensitive and confirmation data and information both
during communication and storage should be implemented.
13
Monitoring and Management Requirements
• The e-District 2.0 Solution should provide monitoring and
management of the entire Solution including all software
components and application.
• The monitoring and management should monitor health of
software and hardware infrastructure running the e-District 2.0
Solution covering operating system, database, software
components, applications, servers, and other related software
and hardware components. It should provide proactive
monitoring, alerting and reporting.
14
Performance and Scalability Requirements
• The design of the e-District 2.0 Solution should be scalable to
handle increasing number of users.
• e-District 2.0 Solution should provide measurable and
acceptable performance requirements for users, for different
connectivity bandwidths.
• The e-District 2.0 solution should provide optimal and high
performance Portal Solution satisfying response time for slow
Internet connections and different browsers.
15
Implementation Requirements
• The SI will be required to deploy manpower and other
project resources as per the terms & conditions of the
Contract
• The SI will be required to work closely with the CHIPS and
perform detailed functional requirements and analysis of e-
District 2.0 Solution to confirm and document functional /
system requirement specifications for the portal and its
applications to fulfil its objectives.
• The SI will be expected to carry the complete
implementation and deployment of the e-District 2.0 within
the timelines specified in the RFP.
• The SI is expected to develop, test, stage, and deploy all
functional modules of the e-District 2.0 software and any
hardware components of technical & functional
requirements.
16
Operations Requirements
• The selected bidder is expected to provide the following in
support of e-District 2.0 operations:
• Selected bidder shall provide procedure documentation for all
operations procedures, and SLA‟s (based on ITIL best practices)
Page 61 of 106
# Requirement
for all the hardware and applications provided including backup
procedures, system update procedures, security procedures,
failure recovery procedures, upgrade procedures, remote
access procedures, user manual, SOP‟s, etc.
• All such procedures and documents must be submitted for
review and approval by the CHIPS prior to adoption. Such
documentation shall be updated by the during the project term
by the bidder as and when required along with the necessary
approval.
• Selected bidder will be required to provide CHIPS with weekly
statistics reports on the various services provided to users a
mechanism as well as track and log all related statistical reports
on the various delivery channels and access patterns.
• Selected bidder will be required to provide CHIPS with weekly
portal performance reports showing health of system operations.
• Selected bidder will be required to provide CHIPS with Helpdesk
for recording all the day to day problems and other technical
incidents occur during the O&M phase. This shall also record the
resolution of such incidents & problems.
• Selected bidder will be required to commit to SSLAs (SLAs) that
show, among other metrics, appropriate escalation procedures
and guarantee corrective actions within a pre-determined time.
Selected bidder is required to respond to required levels of
accuracy, quality, completeness, timeliness, responsiveness,
cost-effectiveness, productivity and user satisfaction that are
equal to or higher than the SLA system requirements.
17
Quality Assurance & Acceptance Requirements
• Selected bidder is required to develop and implement quality
assurance processes and procedures to ensure that the e-
District 2.0 development and operations are performed to meet
the quality standards that are relevant to each area in all project
phases.
• Selected bidder is required to use various tools and techniques
that can make tests run easily and the results are automatically
measured. In this way, testing tools provide a more cost-effective
and efficient solution than their manual counterparts. Plus, they
minimize the risk of human error during testing.
• In order to ensure that such a QA mechanism is effective and
acceptance of e-District 2.0, the following tests are required for
acceptance: Unit Testing: Basic validation of developed
components by developers. Functional / Internal Integration
Testing: Validation of developed components against functional
requirements and design specifications. System Testing:
Validation of both functional and technical requirements for the
integrated Solution. This could include external integration if
required or it can be separated into testing phases. UAT: User
Acceptance Testing (UAT) validation of the Portal Solution and
Page 62 of 106
# Requirement
assurance that it meets both functional and technical
requirements Stress and Performance Testing: Load testing
enabling understanding of performance and behaviour of Portal
Solution under large number of users and high-load conditions.
• Selected bidder is required to describe their QA and testing
approaches and procedures as well as testing tools for
conducting various tests in support of the acceptance of the
Portal Solution. Selected bidder is expected to follow CMMi level
5 processes.
• Selected bidder is required to describe their QA and testing
approaches and procedures as well as testing tools for
conducting various tests in support of the acceptance of the
Portal Solution. Selected bidder is expected to follow CMMi level
5 processes.
18
Mobile Application Platform Capability
• e-District 2.0 applications and services including all appropriate
channels and development of corresponding mobile applications
to the E-District 2.0 applications and services leveraging the
Mobile Service Delivery Gateway (MSDG) and Mobile App
Store.
• Application platform should support the following smart phone
mobile OS (Android, 7.0 and above, iOS 7 and above)
• Support the target packaging components like (Mobile Website,
Hybrid App, Native App, Web App and Application Development,
Eclipse tooling platforms)
• Support the ability to write code once and deploy on multiple
mobile operating systems.
• Support integration with native device API
• Support utilization of all native device features
• Support development of applications in a common programming
language
• Support integration with mobile vendor SDKs for app
development and testing
• Support HTML5, CSS3, JS features for smartphone devices
• Support common protocol adapters for connection to back
office systems (i.e. HTTP, HTTPS, SOAP, XML for format)
• Support JSON to XML or provide XHTML message
transformations.
• Support multi-lingual and language internalization
• Support encrypted messaging between server and client
components
• Support flexible API framework to build offline apps and enable
offline usage
• SI should have all required developer licence etc to test and host
mobile apps in various app stores.
Page 63 of 106
6.3.1.1 Non Functional Requirements – Project Management
• Selected bidder is required to provide an Project Management Plan for taking over of
existing e-District Application, implementation plan for e-District 2.0 illustrating all
functional analysis, development, testing, staging, and deployment activities.
• Selected bidder is required to specify and describe the different phases and activities of the
project. It is very important for the CHiPS that the selected bidder provide a quality
implementation plan covering all aspects of the project. The plan shall clearly specify the
start and end dates (relative to contract signing) of each of the project phases specifying
key milestones allowing visibility of project progress.
• Selected bidder is required to use standard project management tools such as Work
Break Down Structure (WBS), Gantt Chart, PERT Chart, precedence diagrams, critical path
charts, etc. to create and manage implementation plan and schedule. The table below
shows the minimum stages and deliverables:
Stage Activities Deliverable
Functional & Requirements Analysis
• Define Functional Requirements
• Requirements management
• Prototyping
• Documentation
• Data Migration Preparation
• Software Requirements and Specifications Document
• Detailed Scope of Work
• Work Breakdown Structure
• Detailed Project Schedule
• Data Migration Plan
Design • Detailed Software Solution Architecture design
• Detailed Hardware Solution Architecture Design
• Data Schema design
• User Interface Design
• Integration & Interfaces Design
• Prototyping design Validation
• Documentation
• Design Specifications Documents of Software solutions
• Design Specifications Documents of Hardware solutions
• User Interface Design Specifications
• Integration Design Specifications
• Data design and migration
Development • Software installation, configuration, and customization
• Hardware installation and configuration
• Development
• Unit Testing
• Documentation
• Development Plan
• Updated Design Document
• Installed software and hardware
• Functional modules & Portal Solution
• Problem reporting
Testing • System Testing • Complete Test Cases
Page 64 of 106
• Integration Testing
• Stress Testing
• User Acceptance Test Results
• Completed Test Cases
• Data Migration tests
• Documentation
• Test Plan
• User Acceptance Criteria
• Problem reporting
• Problem resolution testing
• Data Migration Testing
Deployment • Training courses and sessions
• Operations Planning
• User Manual
• Operations Manuals
• Knowledge Transfer and training plan
• Operations Plan
• Operations Policies and Procedures
• Selected bidder is required to describe in detail project management processes,
methodologies and procedures
• Describe how CHiPS management will receive up-to-date reports on project status.
• Describe what procedures will be used to keep the project on track, and what escalation
procedures will be employed to address any problems with project progress.
• Describe what quality assurance processes, procedures, formal reviews, etc. will be in place.
• Selected bidder is required to describe the proposed project structure identifying all project
individuals including project manager, business analysts, software developers, QA
engineers, hardware / network engineers, administrators, Change Management experts, and
others.
• Selected bidder shall provide a comprehensive warranty that covers all components during
entire contract period e-District 2.0. The warranty should cover all materials, licenses,
services, and support for both hardware and software. Selected bidder shall administer
warranties with serial number and warranty period. During exit process and final acceptance
by CHIPS, all OEM warranties will be transferred to the CHIPS at no additional charge. All
warranty documentation (whether expired or not) will be delivered to CHIPS based on which
final acceptance and project closure certificate will be issued to bidder.
• Selected bidder is required to provide Premium Level warranty and support through the
vendor for all hardware and software used for e-District 2.0 which should be adhere to the
SLA requirement of the RFP. Selected bidder‟ warranty must cover all equipment and work
activities contained in the contract against all design, manufacturing, and environment faults
during the contract period.
• Selected bidder is required to commit to the following warranty terms:
Page 65 of 106
o All products / components / parts shall be covered under OEM warranty up to
the Implementation Phase and AMC support shall commence after successful
implementation.
o The warranty shall include the repair or replacement of the products/
components/parts during the warranty period by the bidder. The replacement
products / components shall meet the related specifications without further
repair or modification.
o Selected bidder shall be liable for all costs including, but not limited to, the costs
of material, labour, travel, transport and living expenses associated with the
collection and return of the units covered by the warranty.
o .
o Selected bidder need to define the process & methodology in their proposal,
for achieving the response time of engineers to respond to an incident and also
for resolving such incidents as per the SLA.
o Selected bidder is required to provide additional training if the satisfaction
levels/ learning does not reach 80% in evaluation/feedback from trainees, and
expected to provide additional training, if required.
o The e-District application Solution/ Product & supporting infrastructure being
provisioned by the bidder shall be insured. The Goods supplied under the
Contract shall be fully insured against loss or damage incidental to manufacture
or acquisition, transportation, storage and delivery for the entire project term.
o Selected bidder is required to explain their warranty, maintenance procedures,
and support to meet the terms and requirements outlined above.
6.4 Migration of Existing Applications into New Architecture
The SI shall develop and migrate all the existing applications, e-forms, MIS dashboard of
SSDG, e-District to the new Architecture of e-District 2.0.
6.5 Infrastructure
The SI will provide the MeitY empanelled Cloud (Tier III) hosting for e District 2.0 including
staging, production and development throughout the period of contract. The SI will migrate the
entire existing database in to cloud with smooth operation with e District 2.0 Application.
CHiPS will provide the Secured VPN for accessing the Cloud for Operational Support unit
(OSU) team deployed at CHiPS through SDC/SWAN. System Integrator shall be responsible
for hosting the e District 2.0 application and all ancillary in-scope applications on Virtual
Private Cloud (VPC) or Government Community Cloud (GCC) from MeitY empanelled Cloud
Service Providers (CSPs) only, which are empanelled as on the last date of bid submission.
In no case, System Integrator shall host the application on Cloud of any company which is not
empanelled with MeitY and has a history of data loss and security breaches. During the
Contract period, if the chosen CSP is no longer empanelled with MeitY, SI shall choose
another MeitY empanelled CSP and switch the Hosting services at no additional cost to
CHiPS. The SI shall be responsible for installation of all the software and licenses required for
the successful hosting of the District 2.0 application and all ancillary in-scope software. The
Cloud, where the newly developed system will be hosted should comply with the all
requirements as per RFP. System Integrator shall perform the detailed assessment of the
Page 66 of 106
existing transaction and database for propose a cloud-based solution for proposed eDistrict
2.0 application software. Proposed solution shall be with MeitY empanelled CSP. The SI shall
also ensure that the application shall be portable to another CSP (lift and shift) without any
changes to application code.
The proposed solution for the deployment of e-District 2.0 solution is
a) Development environment b) Testing environment/UAT environment/ Pre-Production/Staging environment c) Sandbox (for API deployment) d) Production environment e) Disaster Recovery
6.6 Backup Management Services
The SI shall provide backup management services to conduct regular backups and restoration
as required, of critical data and systems to achieve the required service level.
The activities shall include:
a) Backup of operating system, database and application as per best industry standards.
b) Monitoring and enhancement of the performance of scheduled backups, schedule
regular testing of backups and ensure adherence to related retention policies.
c) Ensuring prompt execution of on-demand backups of volumes, files and database
applications whenever required by CHiPS/Departments or in case of upgrades and
configuration changes to the system.
d) Real-time monitoring, log maintenance and reporting of backup status on a regular
basis. Prompt problem resolution in case of failures in the backup processes.
e) Ongoing support for file and volume restoration requests.
6.7 Maintenance
The SI should define and indicate the Preventive maintenance schedule and procedure. Any
special tools/ instruments/ equipment’s required for carrying out the preventive and break down
maintenance of the system offered should be clearly indicated and offered to CHiPS by the SI
at no extra cost.
6.8 Business Continuity Plan
The SI is expected to develop a Business Continuity Plan (BCP) and Disaster Recovery Plan
(DRP) for the operations carried out by the SI. An indicative list of activities to be performed by
the SI is mentioned below:
1. Designing and implementing adequate data backup, business continuity and
restoration procedures for the e-District application data (including but not
limited to the database, attachments and all other data elements created in and
generated by the system and users)
Page 67 of 106
2. Ensuring that there is no single point of failure and adequate level of redundancy
is built in to meet the uptime and other requirements of this RFP. Preferably, all
the redundancy will be in auto fail over mode so that if primary component fails,
secondary component automatically takes over.
3. Ensuring data backup till the last transaction occurring in the system to ensure
enhanced service levels and following RPO and RTO objectives:
• Peak hours: Zero RPO and Zero RTO
• Non-Peak Hours: Zero RPO and RTO <= 60 minutes
4. Any storage space/media required to maintain backups and other requirements
of the RFP should be provisioned for by the SI in his Bid.
5. Designing and implementing data synchronization procedures for the DR Site.
Periodic testing may be done to ensure that all replication and data
synchronization procedures are in place all the time. Replication between Data
Centre and DR Site as well as change- over during disaster should be automatic
and real-time for minimal impact on user experience
6.9 Scope of Services - Operation and Maintenance Phase
a) The SI shall be responsible for the overall operation and management of e-District till
Go-Live of e-District 2.0 (from the effective date of Contract). The operation and
maintenance phase of e-District 2.0 shall commence after Go-Live for a period of
2years and 3 months.
b) SI has to work with CHiPS/Departments for data collection and design of new models
for implementation of new use case scenarios, if any.
c) SI should develop the Standard Operating Procedures (SOPs), in accordance with
the Information Security Management System (ISMS), ISO 27005 & ITIL standards.
These SOPs shall cover all the aspects including Infrastructure installation,
monitoring, management, data backup & restoration, security policy, business
continuity & disaster recovery, operational procedures etc. The SI shall obtain sign-
offs on the SOPs from the CHiPS/Department and shall make necessary changes,
as and when required, to the fullest satisfaction of CHiPS. CHiPS, CG-State Data
Center & IT related polices and security policy shall be adhered.
d) SI shall provide automated tool based monitoring of all performance indices and
online reporting system for SLAs defined in Volume III of RFP. The tools should have
the capability for the ESD to log in anytime to see the status.
Page 68 of 106
6.10 list of Resources
Bidders has to propose the list of resources to be deployed On-Site and Off-Site to meet the
requirements of CHiPS as mentioned in the RFP. In addition to this bidder has to deploy
District Technical Manager (DTM) for each District.
Educational Qualification required for DTM:
All resources must be BE / B. Tech / MCA and minimum 2 years of work experience in IT/e-Governance
6.11 Information Security Management
Security of Application and the data contained therein is paramount for the success of this
Project. Hence, the SI should take adequate security measures to ensure confidentiality,
integrity and availability of the information.
Security Requirements
Overall Solution
1. The proposed solution should include design and implementation of a comprehensive IS
security policy in line with ISO 27001 standards to comply with the security requirements
mentioned in this section. All the necessary procedures / infrastructure / technology
required to ensure compliance with IS security policy should be established by the SI and
should be approved by the CHiPS before they are implemented. The IS Policy shall include
all aspects such as physical and environmental security, human resources security,
backup and recovery, access control, incident management, business continuity
management etc.
2. The designed IS policy is not in conflict with the security policy of the State Data Centre
where the infrastructure would be hosted.
3. The proposed solution should ensure proper logical access security of all the information
Assets.
4. The proposed solution should be able to classify information assets according to criticality
of the information asset.
5. The proposed solution should provide security including identification, authentication, authorization, access control, administration and audit and support for industry standard protocols
6. The proposed solution should have a security architecture which adheres to the security
standards and guidelines such as
• ISO 27001
• Information security standards framework and guidelines standards under e-
Governance standards (http://egovstandards.gov.in)
• Information security guidelines as published by Data Security Council of India
(DSCI)
• Guidelines for Web Server Security, Security IIS 6.00 Web-Server, Auditing and
Logging as recommended by CERT-In (www.cert-in.org.in)
• System shall comply with IT (Amendment) Act 2008.
• Any other standards deemed necessary
7.
The proposed solution should support the below Integration security standards: • Authentication • Authorization
Page 69 of 106
Security Requirements
• Encryption • Secure Conversation • Non-repudiation • XML Firewalls • Security standards support • WS-Security 1.0 • WS-Trust 1.2 • WS-Secure Conversations 1.2 • WS-Basic Security Profile
8.
The proposed solution should a multi-layered detailed security system covering the overall solution needs having the following features:
• Layers of firewall • Network IPS • Enterprise-wide Antivirus solution • Information and incident management solution for complete CHiPS landscape • Two factor authentication for all administrators i.e. system administrators,
network administrators, database administrators. • Audit Log Analysis
SI must ensure that the security solution provided must integrate with the overall system architecture proposed
9.
The proposed solution should be monitored by periodic information security audits / assessments performed by or on behalf of the CHiPS. The scope of these audits / assessments may include, but are not limited to, a review of: access and authorization procedures, physical security controls, backup and recovery procedures, and program change controls. To the extent that the CHiPS deems it necessary to carry out a program of inspection and audit / assessment to safeguard against threats and hazards to the confidentiality, integrity, and availability of data, the SI shall provide the CHiPS‟s representatives access to its facilities, installations, technical resources, operations, documentation, records, databases and personnel. The SI must provide CHiPS access to various monitoring and performance measurement systems (both manual and automated). CHiPS has the right to get the monitoring and performance measurement systems (both manual and automated) audited / assessed without prior approval / notice to the SI
10. The proposed solution should facilitate system audit for all the information assets to establish detective controls. The SI is required to facilitate this by producing and maintaining system audit logs for a period agreed to with CHiPS.
11. The proposed solution should ensure that data, especially those to pertaining to registration process, transaction process as well as the data that is stored at various points is appropriately secured as per minimum standard 128 Bit AES/3DES encryption.
12. The proposed solution should provide database security mechanism at core level of the database, so that the options and additions to the database confirm the security policy of the CHiPS without changing the application code.
13. The proposed solution should support native optional database level encryption on the table columns, table spaces or backups.
14. The database of the proposed solution should provide option for secured data storage for historic data changes for compliance and tracking the changes.
15. The proposed solution should be able to ensure the integrity of the system from accidental or malicious damage to data
16. The proposed solution should be able to check the authenticity of the data entering the system
17. The proposed solution should be able to generate a report on all “Authorization Failure”
Page 70 of 106
Security Requirements
messages per user ID
18. The proposed solution should be able to monitor the IP address of the system from where a request is received.
19. The proposed solution should be able to differentiate between the systems of the CHiPS network and other external systems
20. Retention periods, archival policies and read-only restrictions must be strictly enforceable on all logs maintained in the system
21. The proposed solution should provide ability to monitor, proactively identify and shutdown the following types of incidents through different modes of communication (email, SMS, phone call, dashboard etc):
i. Pharming
ii. Trojan
iii. Domains (old/new) similar to Chhattisgarh e-District, Government of
Chhattisgarh etc.
22. The proposed solution should be able to monitor security and intrusions into the system and take necessary preventive and corrective actions.
23. The proposed solution should have the option to be configured to generate audit-trails in and detailed auditing reports
24. The proposed solution must provide ACL objects and a security model that can be configured for enforcement of user rights
25. The proposed solution should be designed to provide for a well-designed security of physical and digital assets, data and network security, backup and recovery and disaster recovery system.
26. The proposed solution should have tamper proof data storage to prevent unauthorised data tampering
27. The proposed solution should have a Business Continuity Plan and a Disaster Recovery Plan prepared and implemented by the SI before commencement of the operations. Robust backup procedures to be established for the same.
Password Requirement
1.
The proposed solution should allow the CHiPS to define password policies. The minimum password policies to be defined are:
• Minimum/ Maximum password length
• Alpha numeric combination of password
• Compulsory use of special characters
• Minimum password age
• Password expiry period
• Reset passwords
• Repeat Password etc.
2.
The proposed solution should be able to automatically check the passwords with the password policy, which can be customized by the CHiPS
3.
The proposed solution should enforce changing of the default password set by the system (at the time of creation of user ID) when the user first logs on to the system. The proposed solution should enforce all password policies as defined at the time of first change and thereafter.
4.
The proposed solution should store User ID's and passwords in an encrypted format. Passwords must be encrypted using MD5 hash algorithm or equivalent(SI must provide details)
5.
The proposed solution should be capable of encrypting the password / other sensitive data during data transmission
6 The proposed solution should ensure that the user web access shall be through SSL
Page 71 of 106
Security Requirements
. (https) only for all level of communication for providing higher level of security.
6.12 Contract Performance Guarantee
Within 21 days after the receipt of notification of award of the Contract from the CHiPS, the
successful Bidder shall furnish Contract Performance Guarantee to the CHiPS, Raipur (CG),
which shall be equal to 10% of Contract Value and shall be in the form of a Bank Guarantee
Bond/DD from a Nationalized Bank/Scheduled Bank in the Performa given here-in-after in this
document valid for entire contract period.
1. The proceeds of the performance guarantees shall be payable to the Purchaser as
compensation for any loss / penalties resulting from the Selected Bidder failure to
complete its obligations under the contract.
2. The performance guarantee will be discharged by the purchaser and returned to the
Selected Bidder within 60 days following the date of completion of the Selected Bidder
performance obligations, including any warranty obligations under the Contract.
6.13 Statutory Requirements
1. During the tenure of this contract, nothing shall be done by the Selected Bidder in
contravention of any law, act and/ or rules/regulations, thereunder or any amendment
thereof governing inter-alia customs, stowaways, foreign exchange etc. and shall keep
CHiPS indemnified in this regard.
2. The Selected Bidder and their personnel/representative shall not alter / change /
replace any hardware component proprietary to the CHiPS and/or under warranty or
AMC of third party without prior consent of the CHiPS.
3. The Selected Bidder and their personnel/representative shall not without consent of
the CHiPS install any hardware or software not purchased / owned by the CHiPS.
6.13.1 Contract administration
1. Either party may appoint any individual / organization as its authorized representative
through a written notice to the other party. Each Representative shall have the authority
to:
(a) Exercise all of the powers and functions of his/her Party under this contract, other
than the power to amend this contract and ensure proper administration and
performance of the terms hereof; and
(b) Bind his or her Party in relation to any matter arising out of or in connection with this
Contract.
2. The Selected Bidder shall be bound by all undertakings and representations made by the
authorized representative of the Selected Bidder and any covenants stipulated hereunder,
with respect to this contract, for and on their behalf.
Page 72 of 106
3. For the purpose of execution or performance of the obligations under this Contract, the
CHiPS representative would act as an interface with the nominated representative of the
Selected Bidder. The Selected Bidder shall comply with any instructions that are given by
the CHiPS representative during the course of this contract in relation to the performance
of its obligations under the terms of this contract and the Tender.
4. A committee comprising of representatives from the CHiPS and the Selected Bidder shall
meet on a fortnightly/quarterly basis to discuss any issues / bottlenecks being
encountered. The Selected Bidder shall draw the minutes of these meetings and circulate
to theCHiPS.
6.13.2 Right of Monitoring, Inspection and Periodic Audit
The CHiPS reserves the right to inspect and monitor / assess the progress / performance at
any time during the course of the Contract, after providing due notice to the Selected Bidder.
The CHiPS may demand, and upon such demand being made, the selected bidder shall
provide with any document, data, material or any other information required to assess the
progress of the project. The CHiPS shall also have the right to conduct, either itself or through
any other agency as it may deem fit, an audit to monitor the performance by the Selected
Bidder of its obligations/functions in accordance with the standards committed to or required
by the CHiPS and the Selected Bidder undertakes to cooperate with and provide to the
CHiPS/any other Consultant/ Agency appointed by the CHiPS, all documents and other details
as may be required by them for this purpose. Any deviations or contravention identified as a
result of such audit/assessment would need to be rectified by the Selected Bidder failing which
the CHiPS may, without prejudice to any other rights that it may have, issue a notice of default.
6.14 Chhattisgarh infotech & Biotech Promotional Society’s Obligations
The CHiPS representative shall interface with the Selected Bidder, to provide the required
information, clarifications, and to resolve any issues as may arise during the execution of the
Contract.
CHiPS shall ensure that timely approval is provided to the selected Bidder, where deemed
necessary, which should include diagrams / plans and all specifications related to services
required to be provided as part of the Scope of Work. The CHiPS shall approve all such
documents as per the above Clause.
6.15 Manpower deployed by SI
• Replacement of resources shall generally not be allowed. The replacement of the
resource by the bidder will be allowed (with penalty as per Manpower SLA) only in
case, the resource leaves the organization by submitting resignation with the present
employer or physically unfit.
• In case of failure to meet the standards of the CHiPS, (which includes efficiency,
cooperation, discipline and performance) CHiPS may ask the bidder to replace the
resource without any penalty for the replacement / exit.
Page 73 of 106
• The replaced resource will be accepted by the CHiPS only if he/she qualification /
experience is same or more mentioned in this RFP and is found suitable to the
satisfaction of the CHiPS. The outgoing resource should complete the knowledge
transfer with the replaced resource as per the satisfaction of the CHiPS. The Selected
Bidder shall be allowed maximum of 30 days to replace the resource.
• The penalty per resource would be imposed in case of exit/replacement of resource
from the project. After expiry of 30 calendar days of exit, a penalty of Rs. 1500 per
working day per resource will also be imposed till suitable replacement is not being
provided by the bidder.
• However CHiPS is free to relieve any resource at any time (beyond the minimum
committed period) during the contract period without any penalty by serving 15 days
advance notice.
6.16 Information Security
The Selected Bidder shall not carry and/or transmit any material, information, layouts,
diagrams, storage media or any other goods/material in physical or electronic form, which are
proprietary to or owned by the CHiPS, out of the premises, without prior written permission
from the CHiPS.
The Selected Bidder shall, upon termination of this agreement for any reason, or upon demand
by CHiPS, whichever is earlier, return any and all information provided to the Selected Bidder
by CHiPS, including any copies or reproductions, both hard copy and electronic.
Selected Bidder acknowledges that Govt. of Chhattisgarh business data and other Govt. of
Chhattisgarh proprietary information or materials, whether developed by CHiPS or being used
by CHiPS pursuant to a license agreement with a third party (the foregoing collectively referred
to herein as ―proprietary information) are confidential and proprietary to CHiPS ; and
Selected Bidder agrees to use reasonable care to safeguard the proprietary information and
to prevent the unauthorized use or disclosure thereof, which care shall not be less than that
used by Selected Bidder to protect its own proprietary information. Selected Bidder recognizes
that the goodwill of CHiPS depends, among other things, upon Selected Bidder keeping such
proprietary information confidential and that unauthorized disclosure of the same by Selected
Bidder could damage CHiPS, and that by reason of Selected Bidder‘s duties hereunder.
Selected Bidder may come into possession of such proprietary information, even though
Selected Bidder does not take any direct part in or furnish the services performed for the
creation of said proprietary information and shall limit access thereto to employees with a need
to such access to perform the services required by this agreement. Selected Bidder shall use
such information only for the purpose of performing the said services.
Selected Bidder shall, upon termination of this agreement for any reason, or upon demand by
CHiPS , whichever is earliest, return any and all information provided to Selected Bidder by
CHiPS , including any copies or reproductions, both hard copy and electronic. However
Selected Bidder shall be entitled to retain its working papers.
6.17 Ownership of Equipment
Page 74 of 106
The CHiPS shall own all the equipment, Licenses and any solution supplied by the Selected
Bidder arising out of or in connection with this Contract.
Notwithstanding the above, it is agreed that nothing contained herein above shall be applicable
to Selected Bidder‘s pre-existing materials (i.e Materials owned by the Selected Bidder‘s which
were created and developed prior to this Agreement without direct reference to the
deliverables under this Agreement) which may now be incorporated by the Selected Bidder‘s
into the final deliverables/reports or the like, supplied to the CHiPS hereunder in the course of
delivering the Services pursuant to this Agreement. However, in the event any such pre-
existing material is used in the deliverables/reports provided to the CHiPS by the Selected
Bidder, the Selected Bidder hereby agrees to grant the CHiPS an non-exclusive, paid-up,
royalty free and perpetual license to use such pre-existing material as it exists in the
deliverable/ reports prepared by the Selected Bidder as a part of this Agreement.
6.18 Risk Management
The Selected Bidder shall at his own expense adopt suitable Risk Management methodology
to mitigate all risks assumed by the Selected Bidder under this Contract. Selected Bidder shall
underwrite all the risk related to its personnel deputed under this Contract as well as
equipment and components of the project, procured for the project, equipment, tools and any
other belongings of the Selected Bidder or their personnel during the entire period of their
engagement in connection with this Contract and take all essential steps to reduce and
mitigate the risk. CHiPS Government will have no liability on this account. Selected Bidder
shall, at his own expense, arrange appropriate comprehensive insurance to cover all risks
assumed by the Selected Bidder under this Contract. In connection with the provision of the
Services, the Service Provider must have and maintain for the Agreement Period, valid and
enforceable insurance coverage for:
(i) Public liability;
(ii) Either professional indemnity or errors and omissions;
(iii) Product liability;
(iv) Workers‘ compensation as required by law; and
(v) Any additional types specified in Schedule I; and
The Implementation Agency must, on request by the CHiPS, provide current relevant
confirmation of insurance documentation from its insurance brokers certifying that it has
insurance as required. The Service Provider agrees to replace any coverage prior to the date
of expiry/cancellation. CHiPS or its nominated agencies may, at its election, terminate this
Agreement upon the failure of Implementation Agency, or notification of such failure, to
Page 75 of 106
maintain the required insurance coverage. Inadequate insurance coverage for any reason
shall not relieve Implementation Agency of its obligations under this Agreement.
6.19 Indemnity
The Selected Bidder shall execute and furnish to the CHiPS, a Deed of Indemnity in favor of
the CHiPS, in a form and manner acceptable to the CHiPS, indemnifying CHiPS from and
against any costs, loss, damages, expense, claims, including those from third parties or
liabilities of any kind how-so-ever suffered including patent, copyright, trademark and trade
secret, arising or incurred interalia during and after the Contract period out of:
a. Negligence or wrongful act or omission by the Selected Bidder or it‘s team or any
Agency/ Third Party in connection with or incidental to this Contract; or
b. Any breach of any of the terms the Selected Bidder‘s Proposal as agreed, the Tender
and this Contract by the Selected Bidder, its Team or any Agency/ Third Party.
c. The indemnity shall be to the extent of 100% of project cost in favor of the CHiPS.
7 Sign-off Deliverables
The following are the broad list of deliverables that the SI has to submit. However, the detailed
list of deliverables would depend on the Project Plan submitted by SI. Some specific
deliverables are also mentioned at relevant section of RFP.
• Inception Report
• Software Requirement Specification (SRS) study and the document containing
detailed requirement capture and analysis including functional requirement,
Interface Specifications, application security requirements.
• Functional Requirement Specification (FRS)
• Process Flow, Work Flow.
• Software Design Document including Software Architecture Design, Logical and
Physical Database Design.
• Development of Software
• Complete Source Code with documentation.
• Test Plans and Test cases (including Unit Test Plan, System/Integration Test Plan,
User Acceptance Test Plan, Security Test Plan, Load Test Plan).
• Software Testing Documentation (including details of defects/bugs/errors and their
resolution).
• Tools to monitor the SLA should be supplied by the Implementing Agency.
• Trial Run, Test Run, User Acceptance Test.
• Training Manuals and literature.
Page 76 of 106
• User Training.
• Manuals – Systems Administration Manuals, User Manuals, Installation Manuals,
Operational Manuals, Maintenance & Support Manuals, and Stake-holder
reference Manuals.
• Periodic Status and Review Reports.
• Internal Review and testing documents of the Implementation Agency.
• Remote Support.
• Exit Plan.
• High Level and Low Level Design
• Functional and non-functional testing
• User and Operational Manual for e-District 2.0 Application
• Detailed Project Plan
• Detailed System Study Report
• List of services, Service Definitions, Service Levels
• Software Application architecture documents.
• ER diagrams and other data modelling documents.
• Data dictionary and data definitions.
• Application component design including component deployment views, control
flows, etc.
• Application flows and logic.
• GUI design (screen design, navigation, etc.).
• Requirements Traceability Matrix
• Change Management and Capacity Building Plans.
• SLA and Performance Monitoring Plan.
• Detailed manuals for each appropriate unit of the supplied equipment and services.
• The training manuals and administration manuals.
• Inspection and testing procedures manual including QA Policy, procedures for the
software/hardware equipment’s.
• Any other document(s) deemed necessary for implementation, operation and
maintenance of the hardware and network equipment and the overall system.
• Backup Policy & Security Policy
• Source Code (The Source Code of the complete solution would be owned by
Government of Chhattisgarh)
• Design of real-time tools for monitoring e-Transaction volumes and for generating
real-time MIS
Page 77 of 106
• Training and Knowledge Transfer Plans.
• Issue Logs.
• Any Other document deemed necessary ore relevant
8 Compliance to Standards and Certifications
8.1 Preference for Open standards
The e-District 2.0 system must be designed following open standards, to the extent feasible
and in line with overall system requirements set out in this RFP, in order to provide for good
interoperability with multiple platforms and avoid any technology or technology provider lock-
in.
8.2 Compliance with Industry Standards
For a big set up like e-District 2.0, it is imperative that the highest standards applicable are
adhered to. In this context, the SI will ensure that the entire e-District 2.0 solution is certified,
wherever applicable, and is in compliance with the applicable standards. Following table
depicts the standards which CHiPS intends to get certified within 18 months of Go-Live .
However, the list below is just for reference and is not to be treated as exhaustive.
Solution Element Standards
Information access/transfer protocols W3C Specifications
Portal Development W3C, GIGW
Software Development Process Management CMMI Level 5
Interoperability API, Web Services, Open
Standards
Scanned documents PDF (Image Format)
Document encryption PKCS specifications
Information Security/ Operational Integrity & Security
Management ISO 27001 certification (or above) *
Page 78 of 106
Solution Element Standards
Operations ISO 9001 certification (or above) *
IT Infrastructure management EITM specifications
Service Management ISO 20000 specifications (or
above)
Project Documentation IEEE/ISO/CMMi (where applicable)
specifications for documentation
Business Continuity Management ISO 22301
IT Governance COBIT
IT Operations ISO 20000/ITIL
Document the Operations and Management Standards ISO 20000-1:2011 or relevant latest
standard
a) The Standard/Certification will be the latest version as at the time of implementation. In
case any standard/certification is withdrawn or replaced with a new
standard/certification, the SI has to ensure that the new standard/certification is taken
within defined timelines or within 6 months of declaration of such change. Cost relating to
compliance with the above standards/certification including documentation and
certification fees etc. to be borne by the SI.
b) Apart from the above the SI need to ensure compliance of the project with Government
of India’s IT security guidelines including provisions of:
The Information Technology Act, 2000” (revised 2008) and amendments thereof
and Guidelines and advisories for information security published by Cert-In/MeitY
(Government of India) issued till the date of publishing of tender notice. Periodic changes
in these guidelines during project duration need to be complied with.
c) The SI shall also adhere to the relevant guidelines and standards (as applicable) issued
by CERT-IN, MeitY and Government of India including the following –
➢ CERT-In security guidelines for Indian Government websites (http://www.cert-
in.org.in/)
Page 79 of 106
➢ E-SAFE Guidelines for Information Security (http://egovstandards.gov.in/ )
➢ e-Governance Standards for Preservation Information Documentation of e-
Records (http://egovstandards.gov.in/ )
➢ e-Governance standards on Biometric standards (http://egovstandards.gov.in/ )
➢ Framework and Guidelines for Use of Social Media for Government Organisations
(http://meity.gov.in/writereaddata/files/Approved%20Social%20Media%20Framework
%2 0and%20Guidelines%202.pdf)
➢ Guidelines for Indian Government Websites (http://egovstandards.gov.in/ )
d) Along with the guidelines of GoI, the SI should ensure compliance with State guidelines
and acts, inclusive of and not limited to, Open API policy and Chhattisgarh Aadhaar Act,
2018 along with Aadhaar Act, 2016.
e) SI should register that, changes should be made in the system, in accordance with any
Central/State Government Act - concerning data security and privacy, and data sharing
- passed during the period of system development/implementation.
9 Delivery Schedule
# Activity Time of Completion
1. PBG Submission, Signing of Contract and Inception Report LOI + 7 Days (T)
2. Takeover the existing application including infrastructure at SDC
(In As Is condition) and Support, O&M of Applications and SDC
infrastructure (including all Hardware, Software and licenses) till
Go-Live of e-District 2.0
Deployment of OSU and District Managers
T+15 Days
3 Signoff of SRS,FRS and Systems Design Documents T+30 Days
4 Operation and Maintenance of existing e-District Application and
H/w
Up to Go-Live of e-
District 2.0
5 Completion of Application development, testing, and
Deployment at Cloud and Integration with Central and State e-
Governance initiative for any 3rd party integration available at
the time of deployment.
Deployment of 50 schemes/
services on cloud
T + 12 weeks
Deployment of another 50
schemes/ services on cloud
T + 20 weeks
Deployment of remaining 37
schemes/ services of e-District
T + 24 weeks
T+32 weeks
Page 80 of 106
2.0 on cloud (total number is
137)
Go live of all schemes/ services
covered under the scope of RFP
(end to end)
T + 32 weeks
6 Study, Assessment and Submission of Migration Plan and 100%
completion of Data Migration T+120 Days
7 Training T+180 Days
8 Quality Certification T+180 Days
9 Go-Live T+180 Days
10 Operation and Maintenance for from the date of Go live Till 2 years and 3
months from the
date of Go-Live
9.1 Delivery schedule for e-Form development (D=Issuance of CR for new e-Form)
# Activity for New service Time of Completion
1 SRS Submission D+3 Days
2 Completion of Development D+7 Days
3 UAT, Workflow Creation and Mapping of Users/DSC and
Certificate Designing and Training D+13 Days
4 Quality Certification D+15 Days
5 Go-Live D+15 Days
# Activity for Integration Time of Completion
1 Study and Assessment of Integration D+3 Days
2 Completion of Development/Integration D+7 Days
3 UAT, Workflow Creation and Mapping of Users/DSC and
Certificate Designing and Training D+10 Days
4 Quality Certification D+13 Days
5 Go-Live D+15 Days
10 Prices
Prices quoted must be firm and shall not be subject to any upward revision on any account
what-so-ever throughout the period of contract. CHiPS however, reserve the right to review
and negotiate the charges payable
11 Payment Schedule
All bills will be submitted to CHiPS accordance to procedure mentioned in this tender
document. The fee amount will be equal to the amount specified in Format for Tender
Page 81 of 106
Response – Commercial Proposal. Payments will be released only on satisfactory acceptance
of the deliverables for each Task as per the following schedule:
The indicative mode of payments to be made in consideration of the work to be performed by
the Bidder shall be as follows:
# Milestone % of
Project Cost
Basis for Approval
1
• Takeover the existing application including infrastructure
at SDC (In As Is condition) and Support, O&M of
Applications and SDC infrastructure (including all
Hardware, Software licenses and there renewal) till Go-
Live of e-District 2.0
• Deployment of OSU and District Managers
5% of
Project
Cost
+
1% of
Project
Cost for
every
Quarter
(2
Quarter)
• Against the milestone and delivery plan subject to verification and confirmation.
• Server and Application Uptime Report.
• Sign-off of completion of takeover process of existing application including all kind of renewals as mentioned in the RFP
2
Submission and Sign-off on SRS, FRS and Design Documents of e-district 2.0
4% of
Project
Cost
Sign-off on SRS,
FRS and Design
Documents
3
100% completion of Data Migration 3% of
Project
Cost
Data Migration Completion Sign-off
4
Completion of Application Configuration/ customization, testing, and Deployment at Cloud and Integration with all existing Central and State e-Governance initiative e.g. Open Data, e-Pramaan, UMANG, e-authentication including Aadhaar etc.
5% of
Project
Cost
• Test Report
• Application Deployment at SDC/Cloud
5
User Acceptance Test - PoC for 15 high volume existing and 5 new services in the new architecture or PoC for 25 high volume existing services in the new architecture
Deployment of 50 schemes/
services on cloud
T + 12 weeks
Deployment of another 50
schemes/ services on cloud
T + 20 weeks
Deployment of remaining 37
schemes/ services of e-District
T + 24 weeks
16% of
Project
Cost
On Deployment of e-District 2.0 at Chhattisgarh SDC/Cloud and Successful User Acceptance Test
Page 82 of 106
# Milestone % of
Project Cost
Basis for Approval
2.0 on cloud (total number is
137)
Go live of all schemes/ services
covered under the scope of RFP
(end to end) and Deployment of
HRMS and PMIS for DeGS
T + 32 weeks
6
Quality Certification 5% of
Project
Cost
Issuance of Quality Certificate
7
Training 5% of
Project
Cost
Training Feedback and attendance
8
Go-Live 15% of
Project
Cost
On Successful Launch of all Services
9
Operation and Maintenance for from the date of Go live
32% of
Project
Cost
On submission of Invoice and Server and Application Uptime Report. For 8 Quarter (4% every quarter)
10
Project Exit 8% of
Project
Cost
Project Closure Report
Note:
1. Payment will be released on submission of invoice. 2. SI will submit the invoice as per payment schedule only. 3. Project cost excluding cost quoted for new e-forms development and Web Service
integration. 4. CHiPS will sign the end user license agreement for the software brought from any 3rd party
(if any) for the purpose of this Project however Implementation Agency shall be solely responsible to make payment for the cost of software to such third party software vendor.
Note: Payment will be made only if the invoice submitted is as per payment terms and after
completion of respective deliverables.
Note:
1. After the UAT & Go-Live of new form developed, further maintenance and
Customization/modification will be done by OSU Team without any extra cost.
Page 83 of 106
12 Service Levels
The following measurements and targets shall be used to track and report performance on a
regular basis. The targets shown in the following tables are applicable for the duration of the
contract.
The Successful Bidder should provide post implementation support for 2 years and 3 month.
The Selected Bidder shall provide a Help Desk support software for logging of complaints by
the CHiPS, and the end user of e-district 2.0 application. The system should be able to
acknowledge a receipt as a proof of having lodged a complaint by the CHiPS, and the end
user of e-district 2.0 application. The Selected Bidder shall provide a Call Centre Help Desk
Supports at which complaints can be lodged. The Selected Bidder should ensure uptime of
99%. The Selected Bidder would be the first point of contact for the CHiPS & S/he in turn
would be responsible to co-ordinate with the Chhattisgarh State Wide Area Network
(CGSWAN) Operator, Meity CSP Operator and CGSWAN bandwidth service provider or any
other bandwidth provider to resolve downtime issues. The tools to monitor the SLA (Server
uptime and Application Uptime) should be supplied by the System Integrator. The penalties
would be levied on the Selected Bidder in the event of downtime attributable to the Selected
Bidder exceeds 1%. The Selected Bidder should submit the downtime reports for every quarter
clearly indicating the reasons for the downtime and attributing the downtimes to the CGSWAN
operator, CGSWAN bandwidth service provider or any other bandwidth service provider, SDC
operator and the Selected Bidder.
SLA Terms Description
Uptime • Time for which user is able to access the applications, website and other components of the IT solution during the working hours. The system can be down due to any of the reasons including failure of hardware, network, system software, application etc.
• Scheduled downtime for example, backup time, batch processing time, routine maintenance time will not be considered while evaluating the system uptime. However, the selected SI will be required to schedule such downtime with prior approval of CHiPS. The selected SI will plan scheduled downtime outside working time. In exceptional circumstances, CHiPS may allow the SI to plan scheduled downtime in the working hours.
Bugs / Issues in the Application Software / Hardware device/Network Equipment
• Critical bugs / issues – Bugs / issues affecting more than one division or more than one user in a division.
• Non-critical bugs / issues – Bugs / issues affecting at most one user in a division
Page 84 of 106
12.1 Implementation Phase SLAs
# Milestone Deliverables Timeline Penalty
1 Takeover the existing application including infrastructure at SDC (In As Is condition) and Support, O&M of Applications and SDC infrastructure (including all Hardware, Software Licenses and there renewal) till Go-Live of e-District 2.0
Entire Application Takeover Report Application and Server Uptime report till Go-live
T+30 Days T+31 Days to T+45 Days Rs. 1.5 lakh/Week.
Greater than T+45 Days 0.25% of the project cost for every 2 weeks of delay.
2 Submission and Signoff on FRS & SRS and Systems Design Documents
• Detailed system study Validation of the system study document
• Validated FRS document including integration requirements from the department
• System Requirement Specifications (SRS) Document
• Technical Architecture Document
• Security architecture & policies
• Integration/ interface design mechanism with other departments
• Software deployment model
• Quality Assurance Plan, Testing Plan/ Strategy and test cases
• Submission of Data Schema (soft copy) • Backup Policy
T+90 Days T+91 Days to T+105 Days Rs. 1.25 lakh/Week.
Greater than T+105 Days - 0.15% of the Project Cost for every 2 weeks of delay.
• Design documents for all Application Modules and Sub-modules for Disaster Management Applications
• Data migration strategy report
Page 85 of 106
3 Study, Assessment and Submission of Migration Plan and 100% completion of Data Migration
Data Status Migration Report Acceptance Report from Data
T+120 Days T+121 Days to T+125 Days Rs. 1.25 lakh/Week.
Greater than T+125 Days - 0.25% of the Project Cost for every 2 weeks of delay.
4 Completion of Application development, testing, and Deployment at SDC and Integration with Central and State e-Governance initiative e.g. Open Data, e-Pramaan, UMANG,
• Functional Requirement Traceability Report
• Application Readiness Report
• Development completion report including results of Unit testing, Integration testing
• Report on System Testing Results, Integration Testing Results, User Sign off, Deployment plan, Back-out or Rollback plan, Contingency plan and Updated Risk Plan.
T+180 Days T+181 Days to T+195 Days Rs. 1.25 lakh/Week.
Greater than T+195 Days - 0.5% of the Project Cost for every 2 weeks of delay.
5 User Acceptance Test - PoC for all existing/new services in the new architecture
Test Cases and UAT Plan T+240 Days T+241 Days to T+241 Days Rs. 1.25 lakh/Week.
Greater than T+241 Days - 0.5% of the Project Cost for every 2 weeks of delay.
6 Quality Certification Quality Certificate T+180 Days T+181 Days to T+181 Days Rs. 1.25 lakh/Week.
Greater than T+181 Days - 0.5% of the Project Cost for every 2 weeks of delay.
7 Training Training Plan User Manual User Feedback/assessment document
T+180 Days T+181 Days to T+181 Days Rs. 1.25 lakh/Week.
Greater than T+181 Days - 0.5% of the Project Cost for every 2 weeks of delay.
Page 86 of 106
8 Go-Live Submission and sign-off of UAT Successful Launch of e-district 2.0
T+180Days T+181 Days to T+181 Days Rs. 2.5 lakh/Week.
Greater than T+181 Days - 0.5% of the Project Cost for every weeks of delay.
9 Adding New scheme / service
Complete end to end configuration of a scheme after receiving complete information from department in required format.
8 working hours
1% of the quarterly payment calculated per transaction basis for the new scheme or service addition not meeting the SLA during the quarter.
Complete end to end configuration of a service after receiving complete information from department in required format
8 working hours
1% of the quarterly payment calculated per transaction basis for the new scheme or service addition not meeting the SLA during the quarter.
Terminating New scheme /
service Terminate/end/discontinue a scheme from the technology platform after receiving written approval from head of department.
1 working hour (for at least 95% of number of such requests)
1% of the quarterly payment.
Terminate/end/discontinue a service from the technology platform after receiving written approval from head of department
1 working hour (for at least 95% of number of such requests)
1% of the quarterly payment.
Modification in a scheme Rules – eligibility, benefits calculation, payment etc. after receiving complete information from department in required format
8 working hours (for at least 95% of number of such requests)
1% of the quarterly payment.
Page 87 of 106
Form – field classification, additions, enhancements after receiving complete information from department in required format
8 working hours (for at least 95% of number of such requests)
1% of the quarterly payment.
Attachment – type, numbers, size etc. after receiving complete information from department in required format
8 working hours (for at least 95% of number of such requests)
1% of the quarterly payment.
Modification in a service Rules – eligibility, benefits calculation, payment etc. after receiving complete information from department in required format
8 working hours (for at least 95% of number of such requests)
1% of the quarterly payment.
Form – field classification, additions, enhancements after receiving complete information from department in required format
8 working hours (for at least 95% of
number of such
requests)
1% of the quarterly payment.
Attachment – type, numbers, size etc. after receiving complete information from department in required format
8 working hours (for at least 95% of
number of such
requests)
1% of the quarterly payment.
Changes in user profile – addition, access control etc. after receiving complete information from department in required format
8 working hours (for at least 95% of
number of such
requests)
1% of the quarterly payment.
Page 88 of 106
Note:
1. Penalty will be applicable only if the delay is attributable to SI. 2. Deliverables list is indicative CHiPS may ask additional documents which are evident for completion of milestone.
12.2 Manpower SLAs
Team mobilization, Setting up of Project Management Office and commencement of work
Definition Details
Service Level
Requirement
Deployment of key resources within prescribed time-limit from the date of signing of the contract. Deployment
would mean reporting of SI’s team at CHiPS’s office in Raipur for project planning and kick-off.
Measurement of Service
Level Parameter
To be measured in number of days from the prescribed time-limit from the date of signing (see implementation
schedule).
Liquidated damage for
Non-achievement of SLA
Requirement
• No delay: No Liquidated damage
• Every week (or part thereof): INR 1,00,000 per resource per week (or part thereof from the milestone
payment)
Minimum Tenure of Manpower
Definition Details
Service Level
Requirement
The resources should be deployed for a minimum defined period and should not be replaced before this
prescribed period.
Measurement of Service
Level Parameter
To be measured in number of months of actual deployment. This SLA will be calculated separately for each
resource of SI
Liquidated damage for
Non-achievement of SLA
Requirement
• At least 6 months: No Liquidated damage
• Less than 6 months but more than or equal 4 Months: INR 1,00,000 per resource
• Less than 4 months but more than or equal 2 Months: INR 2,00,000 per resource
Page 89 of 106
Definition Details
• Less than 2 months: INR 3,00,000 per resource
Non-Availability of Acceptable Resource
Definition Details
Service Level
Requirement
At all times the SI should have required resources deployed on the project
Measurement of Service
Level Parameter
In case SI is not able to provide approved replacement of resource in a timely manner. Upon replacement of
resource, the number of days for which a position remains vacant due to unavailability of resource acceptable to
CHiPS
Liquidated damage for
Non-achievement of SLA
Requirement
• Zero days: No Liquidated damage
• Every week (or part thereof from the milestone payment): INR 50,000 per resource
Page 90 of 106
12.3 Operational SLAs
#
SLA Parameter
Average Response Time
Method of Measurement
Penalty Baseline
Low
Performance Breach
1 Operation and
Maintenance for
from the date of Go
live
Uptime of e-District
2.0
Application,
Mobile app
and Server
>= 99% 98% Equal to
95% or
less
Automated measurement as
part of SLA tool will be adopted
For every 1% drop in uptime (for
both Server Uptime and
Application Uptime) in each
quarter over the required Uptime
of 99% a penalty up to 0.1% of
the Project Cost would be liable
to be deducted.
If the uptime in any quarter is
95% or less due to conditions
which are wholly attributable to
the Bidder then the purchaser
may terminate the contract.
A penalty up to 0.5% of the
Quarterly Payment would be
liable to be deducted for every
day delay in response time or
call fixing time for any problem
logged by the CHiPS/end user.
The Selected
Bidder will provide Help Desk
call logged report every quarter
2 Time to load login less than 3 less than or more than 5 Automated measurement as part Exceeding 10% of instances over a
page or any other Sec equal to 5 sec of SLA tool will be adopted and period of 24 hrs, 1% of the
Page 91 of 106
quarterly
page (other than sec frequency decided by the CHiPS. fees for each such day till the
home page) of the Measurement shall be executed instances are rectified, subject to
portal that can be between 9 AM to 9 PM on any 10% of the quarterly fees payable.
viewed by the users day.
(over web)
3 Request-Response
Time for online transaction either through portal or gateway where such services are made available (over web)
less than 3 sec
less than or equal to 5 sec
more than 5 sec
Automated measurement as part of SLA tool will be adopted and frequency decided by the CHiPS. Measurement shall be executed between 9 AM to 9 PM on any day.
Exceeding 10% of instances over a period of 24 hrs, 1% of the quarterly fees for each such day till the instances are rectified, subject to 10% of the quarterly fees payable.
4 Request-Response Time for transactions with document retrieval and rendering from cloud (over web)
less than 5 sec
less than or equal to 8 sec
more than 8 sec
Automated measurement as part of SLA tool will be adopted and frequency of measurement shall be executed between 8 AM to 3 P M on any day
Exceeding 10% of instances over a period of 24 hrs, 1% of the quarterly fees for each such day till the instances are rectified, subject to 20% of the quarterly fees payable.
5 Recovery Time Objective (RTO)
<=4 hours <=8hours >8 hours Measured once in 3 months through a mock drill.
For any violation penalty will be 2% of the annual O&M cost.
6 Concurrent User Sessions Supported for Services used by e-District 2.0 system
Minimum of 6000 concurrent user sessions
Measured once in 3 months through a load test or actual usage.
For any violation penalty will be 3 % of the annual O&M fees.
Concurrent User Sessions Supported for Services used by e- District 2.0 system
Minimum of 7500 concurrent user sessions
Page 92 of 106
7 Availability of all
applications of e- District 2.0
>= 99.9% <99.9% and
>= 99%
<99% Monthly availability through Total
uptime/ (Total calendar time- Scheduled Downtime)
For any violation penalty will be 3 % of the annual O&M fees.
Note:
1. SI will submit the uptime report on completion of every quarter. 2. For monitoring of server and application uptime SI shall have to provision for monitoring and measurement
tools, licenses, etc. required for this purpose
Page 93 of 106
12.4 Operational SLAs for Helpdesk
Support calls to the helpdesk should be answered in:
# Call Type Description Response Time
1 Critical Calls Incidents which impact the overall solution like outage of e-district 2.0 Application and which has a high impact on the service delivery to citizens and respective departments. Incidents whose resolution shall require additional investment in components or time or shall involve coordination with OEMs. Incidents for which no work around is available. Any incident which is affecting a majority of users (over 80% of users including Department users and CSCs).
(within 15 min)
2 Medium Incidents which impact a limited number of users. The main application at SDC is available but the productivity of a limited number of users is getting affected. For e.g., e-District application is up and running but certain users are unable to login/access/submit request/process citizen service requests etc. Incidents whose resolution shall require replacement of hardware or software parts, requiring significant interruption in working of that individual component. Acceptable work around is available. For example, installation of operating system, patches, etc.
(within 30 min)
3 Low Incidents whose resolution shall require changes in configuration of hardware or software, which will not significantly interrupt working of that component. Incidents like functionality enhancement and/or support for modification or maintenance of source code, application version enhancement etc.
(within 45 min)
12.4.1 Categorization of Call
The calls would be defined in the following categories:
A. Severity level: The severity level of a service call is defined by the extent of impact the problem
has on the overall state portal solution performance.
a. S1-Very high severity: Business can't Work – Issue in which significant portion of business is non-operational and for which there is no work around.
b. S2-High Severity: Application is not down but there is a serious problem affecting user's productivity. Work around if provided is awkward and inefficient.
c. S3-Medium Severity: Application is not down but there is an issue affecting small number of users or customers. Acceptable work around is available.
d. S4-Low Severity: Functionality enhancement and/or support for modifications or maintenance of source code, training documentation or user documentation.
B. Priority level: The priority level of a service call is defined by the priority in which the calls
would be handled in case of queuing.
a. P1-High Priority: Total failure of critical systems, services, applications or underlying hardware Hosting centre failure Network failure External attack on network Immediate investigation and status reports.
b. P2-Medium Priority: Partial failure of critical systems, services, applications or underlying hardware failure in standard operating procedures. Non-critical hardware defect, Operating system failure of backup system, hourly reporting of investigations.
c. P3-Low Priority: Total or partial failure of non-critical services or applications, standard
Page 94 of 106
operational, Standard operating procedures, Routine password changes, Errors in hosted content, Updating hosted content, Report of initial investigations within four hours.
The resolution time should be as per the matrix defined below:
* Time by which the calls have to be resolved
12.4.2 Limitation of Penalties
Note: Breaching of above resolution time will lead to penalty of 0.5% of O&M Cost.
After Starting of the work and services the maximum penalty should be levied as described below:
i. The total deduction should not exceed 10% of the total applicable fee for the total Project
Cost, post which CHiPS has right to terminate the contract agreement.
ii. If bidder fails to deliver the services in stipulated time-frame on account of any reasons will be
deemed to be an event of default and termination. This shall be governed by the terms &
conditions defined in subsequent sections in General Conditions of the Contract.
Severity/Priority P1 P2 P3
S1 2 Hrs 4 Hrs 6 Hrs
S2 2 Hrs 6 Hrs 8 Hrs
S3 8 Hrs 16 Hrs 24 Hrs
S4 16 Hrs 24 Hrs 32 Hrs
Page 95 of 106
Page 96 of 106
Annexure 6: – Infrastructure available at CG State Data Centre Existing e-District (At SDC) Infrastructure Details
S/N Server HS23- Blade
Type CPU Details
Total
Processor
Cores
Physical
HDD
Physical
RAM
1 Blade Server
Type- 7875 Xeon E5-
8 300GB 64 GB
2 Blade Server 8 300GB 64 GB
3 Blade Server 8 300 GB 32 GB
4 Blade Server 8 300 GB 32 GB
5 Rack Server Lenovo System x3850x6 Model -
6241AC1
Intel® Xeon®CPU E7-
4809 [email protected]
16 300 GB 128GB
6 Rack Server
Intel® Xeon®CPU E7-
4809 [email protected]
16 300 GB 128GB
7
Dell Poweredge R 630 , Rack Server-2P , 2X Intel 8core E5 2620 V4 ( 2.1 Ghz ), 256 GB DDR III RAM, 3*600 GB SAS Hot Swap HDD (10 K or higher RPM), and other specification for Server as per technical Specification
6 Nos.
8 Load Balancer(Hardware based for application) 1
9
SAN Storage with SAS HDD with 10500 RPM in RAID 5, and all allied devices like Storage System Switch, Storage System caballing, Storage system Chassis, Switch SAP module and other related licenses. SAN shall have Online replication capability either inbuilt or through additional software.
2
10 Tape Library 1
11 LTO4 (800 GB compressed, 1.6 TB raw) 100
Software License Description
# Software License Description Qty
1 IBM WebSphere Application Server Network Deployment Processor Value Unit
(PVU) 840
2 IBM App Connect Enterprise Standard Edition Processor Value Unit (PVU) 350
3 IBM MobileFirst Platform Foundation Application 1
4 IBM Db2 Advanced Enterprise Server Edition Processor Value Unit (PVU) 1,120
5 IBM Spectrum Protect Extended Edition 10 Processor Value Units (PVUs) 280
6 IBM Spectrum Protect for SAN 10 Processor Value Units (PVUs) 112
7 IBM SmartCloud Application Performance Management Entry Managed Virtual
Server 6
Page 97 of 106
# Software License Description Qty
8 IBM SmartCloud Application Performance Management Standard Managed
Virtual Server 6
9 IBM Tivoli Netcool Network Management Entry Device Resource Value Unit 226
10 IBM Tivoli Application Dependency Discovery Manager Resource Value Unit 600
11 IBM Tivoli Business Service Manager Tier 1 Resource Value Unit 12
12 IBM Control Desk Concurrent User Annual SW Subscription & Support Renewal 4
13 IBM BigFix Starterkit for Lifecycle Resource Value Unit 72
14 IBM BigFix Starterkit for Lifecycle Client Device 1,761
15 IBM Db2 Developer Edition Authorized User 2
16 RHEL 6.5 6
17 VM Ware 5.5 with vCenter 12
e-District Virtualization
S/N Bare Metal Blade Name Processor Sockets
Processor Cores per
Socket
Logical Processor
VM's Name
1 Blade-9 1 8 16 Staging Server
2 VM Esxi Blade-10 1 8 16 edistdb1
edistcf1
3 VM Esxi Blade-11 1 8 16 edistdb2
edistcf2
4 VM Esxi Blade-12 1 8 16 edistas1
edist_PentahoApp
5 VM Esxi Blade-13 1 8 16 edistas2
edistbkpsrv
6 VM Esxi Blade-14 1 8 16 edistweb2
edist_PentahoWeb
7 VM Esxi 2 Blade 2 4 8 backup_DB1
backup_CF1
8 VM Esxi 4 Blade 2 4 8 edistweb1
edisthelpdesk
9 VM Esxi 8 Blade 2 4 8 backup_DB2
backup_CF2
Network Component
# Unique Asset Tag Module Module Sr. No. Make Model
1 Load Balancer APV 2600 1324G3695 Array APV 2600
Storage Component
# Equipment Description
Device Type
Make
Model Usabl
e Space
Allocated Space
Total HDD/Tap
e
Rack No.
1 IBM Storwize Storage IBM V3700 17TB 16.5TB 24 7
Page 98 of 106
2 IBM Storwize Storage IBM V3700 21TB 19TB 24 7
3 Tape Library Tape Library
IBM TS320
0 - - 2 7
Details of life of servers
S/N
Blade Name
OEM
Processor Sockets
Cores per Socket
Total CPU Cores
CPU Cores
Physical RAM
Core in VMs
RAM per VM
HDD Details
CPU Details
Blade Details
Serial No
Warranty Expired
VM's Name
1 Blade-02 IBM
2 4 8 8CPUsx2.399Ghz
64GB
8 64 300 Intel® Xeon® CPU [email protected]
7875-AC1 06FPNAV
Details with SDC
Not in Use
2 Blade-08 IBM
2 4 8 8CPUsx2.399Ghz
64GB
4 40 130 Intel® Xeon® CPU [email protected]
7875-AC1 06FPNAX
Details with SDC
PostgesWeb_Server 4 18 130
3 Blade-09 1 8 8 32 GB
8 32 300 06ZYPD9
Details with SDC
Not in Use
4 Blade -10
IBM
1 8 8 8CPUsx2.399Ghz
64GB
6 40 130 Intel® Xeon® CPU [email protected]
7875-AC1 06VLKH6
Details with SDC
PostgesDataBase
2 20 130
5 Blade-11 IBM
1 8 8 8CPUsx2.399Ghz
64GB
6 39 132 Intel® Xeon® CPU [email protected]
7875-AC1 06VLKH9
Details with SDC
Staging Web Srv
2 20 130
6 Blade-12 IBM
1 8 8 8CPUsx2.399Ghz
64GB
6 45 170 Intel® Xeon® CPU E5-
7875-AC1 06ZYPD8
Details with SDC
edistas1
2 10 90 edist_PentahoApp
7 Blade-13 IBM
1 8 8 8CPUsx2.399Ghz
64GB
6 45 170 Intel® Xeon® CPU [email protected]
7875-AC1 06ZYPB0
Details with SDC
edistas2
2 11 90 UAT /edistbkpsrv
8 Blade-14 IBM
1 8 8 8CPUsx2.399Ghz
32GB
4 20 140 Intel® Xeon® CPU [email protected]
7875-AC1 06ZYPE1
Details with SDC
edistweb2
4 8 110 edist_PentahoWeb
9 Blade-4 IBM
2 4 8 8CPUsx2.399Ghz
32GB
4 20 85 Intel® Xeon®
7875-AC1 06VLKMB
Details with SDC
edistweb1
4 8 130 edisthelpdesk
Page 99 of 106
10
CG EDIST SVR-01
Lenovo
2 8 16 16CPUsx1.995Ghz
128GB
20 71 130 Intel® Xeon®CPU E7-4809 [email protected]
Lenovo System x3850x6 Model -6241AC1
J31DKHD
Details with SDC
edist-db1
10 51 130 edist-cf1
11
CG EDIST SVR-02
Lenovo
2 8 16 16CPUsx1.995Ghz
128GB
20 71 130 Intel® Xeon®CPU E7-4809
Lenovo System x3850x6 Model -6241AC1
J31DKHC
Details with SDC
edist-db2
10 51 130 edist-cf2
Details of life of Storage and other equipments
S/N
Equipment Description
Device Type
Make
Machine Type & Model
Part No/Product ID
Serial Number
Quantity
Discription AMC Details
1 IBM Storwize Storage V3700
IBM 2072-24C
00Y2613/2072S2C
7844603 1 IBM Storewize V3700 SFF Dual controller
Warranty needs to be renewed
2 IBM Storwize Storage V3700
IBM 2072-24C
00Y2613/2072S2C
7844575 1 IBM Storewize V3700 SFF Dual controller
Warranty needs to be renewed
3 IBM Tape Library
Tape Library TS-3200
IBM 3573 4UL
3573 4UL 78W2315 1 Two LTO drive Warranty needs to be renewed
4 IBM SAN Switch A1
SAN Switch
IBM SAN24B-4
249824E 10329EC 1 Express IBM System Storage SAN24B-4
Warranty needs to be renewed
5 IBM SAN Switch A2
SAN Switch
IBM SAN24B-4
249824E 10329FK 1 Express IBM System Storage SAN24B-4
Warranty needs to be renewed
6 Array Application Load Balancer
APV 8.4.0.92
Array
APV 2600
960002 1324G3695
1 Application Load Balancer
Warranty needs to be renewed
7 SFP 8 Gbps SW 8-Pack
SFP Port 45W0501 16 Warranty needs to be renewed
8 Storage HDD Details
IBM SAS HDD 1.2 TB 10K 6GB FRU P/N- 00Y2432
Warranty needs to be renewed
Details of Licenses
S/N SW Description
OEM Part No. License Purchased
No. of Core to be used
RemarK Start Date
End Date Version
Page 100 of 106
1 IBM WebSphere Application Server Network Deployment
IBM D55WJLL 840 12 Application Server
21-Mar-14
30-Jun-18 8.5.5
2 IBM DB2 Advanced Enterprise Server Edition
IBM D0ZUTLL 1120 16 Pure Scale 21-Mar-14
30-Jun-18 10.5
3 IBM DB2 Developer Edition
IBM D58N5LL 2 License for Database Software developer.
21-Mar-14
30-Jun-18
4 Red Hat Enterprise Linux Server, Standard (1-2 Sockets) (Upto 1 guest)
RedHat RH0101594 6 Linux OS 25-Jun-14
24-Jun-18 RHEL 6.5
5 VMware VSphere 5 Enterprice Plus for 1 Processor
VMware VS5-ENT-PL-C
12 Virtualization 24-Jun-14
19-Sep-18 ESXi 5.5.0
6 VMware vCenter Server 5 Standared for vSphere 5(Per Instance)
VMware VCS5-STD-C
1 Monitoring of VMs
24-Jun-14
19-Sep-18 vCenter Server 5.5
7 IBM SmartCloud Application Performance Management Entry
IBM D0Q3VLL 6 Monitoring availability and Performance of Servers.
21-Mar-14
30-Jun-18 TM_6.2.3
Note:- The prospective Sizing for the proposed solution utilizing the pre-existing
keeping in view that the whole system has to be moved over cloud and therefore
required to be cloud compatible. Bidders are requested to fill the Cloud sizing in
Volume –II of the RFP in section 6.2 as per the 5 years load projection Annexure-3
Page 101 of 106
Annexure 7: Existing e-District Solution a. Logical Deployment
Inte
rne
t
State Portal/
e-District Portal/
Mobile App
Inte
rne
t/
SW
AN
Lo
ad
Ba
lan
ce
r
Citiz
en
De
pa
rtm
en
t U
se
r
We
b S
erv
er
Ap
p S
erv
er
(J2
EE
)A
pp
Se
rve
r
(Mo
bile
Ap
p)
Inte
gra
tio
n S
erv
er
(SO
A)
SS
DG
/MS
DG
& o
the
r
De
pa
rtm
en
ts
Da
tab
ase
Se
rve
r
SDC
b. Functional Architecture
User Community
CSC/LSK Operator Citizen Department USer
e-District
Portale-District Portal/
Mobile App
e-District
Portal
Access Channel
Internet/CGSWAN
From e-District Portal
Enterprise Service Bus
Routing Transformation Messaging QoS Policy
State Applications
Employment
Transport
Other
e-District Workflow
Birth Death Income SC/ST
Pension MIS Marriage OBC
NoC Grievance RTI Gomasta
External Application
SSDG
MSDG
AADHAR
Email Gateway
Payment Gateway
From State Portal
For e-District
Page 102 of 106
Annexure 8: List of Chhattisgarh e-District Services DEPARTMENT NAME SERVICE NAME
1 Urban Administration Marriage Registration & Certificate
2 Revenue SC/ST Certificate
3 Revenue OBC Certificate
4 Revenue Income Certificate
5 Revenue Domicile Certificate
6 Revenue RTI filling at District Collectorate
7 Urban Administration RTI filling at Municipalities/Panchayat
8 Urban Administration Public Grievance Municipal Corporation/Municipality/Town Panchayat
9 Urban Administration Public Grievance Collectorate
10 Social Welfare Application for inclusion in Indira Gandhi Old age Pension
11 Social Welfare Application for inclusion in Samajik Suraksha Pension Yojana
12 Social Welfare Application for inclusion in Sukhad Sahara Yojana
13 Social Welfare Application for inclusion in Widow Pension
14 Revenue Application for Case listing (Revenue Court)
15 Revenue Court Order Certificate (Revenue Court)
16 Urban Administration Issuance of Ration card
17 Urban Administration Property Tax Payment
18 Urban Administration Water Bill/Tax Payment
19 Urban Administration Issuance of Trade License
20 Labour Shop and Establishment Registration
21 Food and Medicine administration
Food Registration (Application for Small Cottage)
22 Urban Administration Water Tap Connection
23 Urban Administration NoC For Building (Plan)construction
24 Urban Administration Name transfer (Mutation)of Property Municipal area
25 Revenue Request for Nakal of document From Bhuiyan (copy of land record etc)
26 Manpower Planning Registration for Employment
27 Transport New Permanent Driving License for Motor Vehicle
28 Transport New Learner License
29 Transport Application for fitment certificate (vehicle)
30 Social Welfare Application for Indira Gandhi Disability Pension Yojna
31 Food and Medicine administration
Food Registration(Application for Hawker Stall)
32 Economics and Statistic Birth Certificate Correction
33 Revenue Revenue Services (Agricultural Land/Diverted For Demarcation)
34 Revenue Revenue Services (Nazul Land Patta Renewal)
Page 103 of 106
35 Revenue Revenue Services (Nazul Land Patta NOC)
36 Revenue Revenue Service (Solvency Between 5 Lac To 25Lac)
37 Economics and Statistic Death Registration & Certificate Correction
38 Urban Administration Land Use Information
39 Economics and Statistic Marriage Registration & Certificate Correction
40 Higher Education Branch Change for Government Engineering/PolyTe College
41 Higher Education Institute Change for Government Engineering/ Polytechnic College
42 Higher Education Fee Refund For Government Engineering/PolyTechnical College
43 Higher Education Fee Refund For Government Engineering/PolyTechnical College Persons With Disability
44 Economics and Statistic Choice Birth Correction
45 Economics and Statistic Choice Death Correction
46 Higher Education Transfer Certificate For Government Engineering/PolyTechnical College
47 Higher Education Transfer Certificate For Government Engineering/PolyTechnical College Persons With Disability
48 Higher Education Complaint For Government Engineering/Polytechnic College Persons With Disability
49 Economics and Statistic Choice Marriage Correction
50 Revenue Revenue Service (Solvency Less Than 5 Lac)
51 School Education Transfer Certificate For Government High School
52 Manpower Planning Transfer Certificate For Janshakti Training
53 School Education Character Certificate For Government High School
54 School Education Marksheet For High School
55 Manpower Planning Transfer Certificate For Janshakti Training For Person With Disability
56 Manpower Planning Marksheet For Janshakti Training
57 Manpower Planning Marksheet For Janshakti Training For Person With Disability
58 Revenue Revenue Services (Nazul Land Patta Mutation)
59 Food and Medicine administration
Application for new license under Chhattisgarh Motor and High Speed Diesel Oil (License and Control) Order, 1980
60 Food and Medicine administration
New Petrol Diesel Application-Renewal
Page 104 of 106
61 Food and Medicine administration
Kerosene Entry-New
62 Food and Medicine administration
Kerosene-Renewal
63 Food and Medicine administration
From Mandatory Things Manual
64 Food and Medicine administration
From Mandatory Things for Renewal
65 Revenue Revenue Court CG
66 Revenue Revenue Services (Nazul Land Patta Demarcation)
67 Revenue Revenue Services (Agricultural Land/Diverted For Mutation)
68 Village industry Sericulture - aid under Mulberry plantation
69 Forest Forest -Registration of Wood
70 Sports & Youth Welfare Financial Aid for Sportsperson
71 Agriculture Equipment loan
72 Revenue Revenue Services (Agricultural Land/Diverted For Kisaan Kitaab)
73 Agriculture Pesticide license
74 Agriculture Horticulture -New Seed License
75 Agriculture Seed Trading
76 Revenue Revenue Services (Agricultural Land/Diverted For RBC 6(4) - Relief Support (Natural Calamity))
77 Agriculture Seed Processing
78 Women and Child Development Women and Child Development - Swavalamban scheme
79 Agriculture Fertilizer License
80 School Education Transfer Certificate for Government High School
81 School Education Transfer Certificate for Government School
82 Culture Culture- Request for record copy
83 School Education Mark sheet For Government School
84 Revenue Request for Nakal of document Non-Digitized (copy of land record etc)
85 Village industry Handicraft-Application for sanction of tools / workshop construction grant from C.G. Handicraft Development Board
86 Village industry Handicraft-Registration of self-help groups / co-operative societies
87 Water Resources Department Irrigation -Water Purify
88 Village industry Handicraft-Registration of businessmen working in the field of handicrafts
89 Panchayat & Rural Development
Panchayat & Rural - Cleaning system
90 Panchayat & Rural Development
Panchayat & Rural - change of street light bulb
Page 105 of 106
91 Village industry Handicraft-Application form for participating in State Level Handicrafts Award Competition
92 Village industry Handicraft-Application for registration for artisans
93 Public Works PWD- registration of Unemployed Engineer
94 Village industry Handicraft-Application for joining Janshree Group Insurance
95 Village industry Handicraft-Application for giving monthly financial assistance/benefits to artisans
96 Public Health & Family Welfare Ayush - Permanent Registration Form
97 Village industry Handloom- Financial aid to weavers
98 Public Health & Family Welfare Ayush -Temporary Registration Form
99 Public Health & Family Welfare Ayush - Application for Qualification Registration
100 Fisheries Insurance Fisheries
101 Jail Jail- Request to meet Prisoner
102 Forest Forest -Application for sanctioning license for running established Sawmill
103 Animal Husbandry Animal Disease
104 Forest Forest -Application for sanction of retail sale for forest produce
105 Fisheries Application for loan for fisheries
106 Home Police -No. of cases registered in the station
107 Home Police - Application for Insurance Claim Compensation of Unnatural Death
108 Home Police - Relief to the casualties in road accident
109 Home Police - Road accident under motor vehicle act
110 Home Application to get the information of proceedings of previous application
111 Home Police - Case relief for SC/ST Discrimination
112 Home Police - Application for assistance to families suffering from natural calamities
113 School Education Fee Refund for Government High School
114 Agriculture Horticulture -Renewal of Seed License
115 Agriculture Horticulture - Inclusion of New variety seed license
116 Fisheries Fisheries - Allocation of Reservoir on royalty basis
117 Fisheries Fisheries Training
118 Fisheries Fisheries - Allocation of reservoir for lease
119 Home Permanent Cracker license
120 Home Temporary Cracker license
121 Home NOC Required for setting up Petrol Pump
122 Home Cinema license under the cinematography Act
Page 106 of 106
123 Home NOC For Sale, Transport and Construction of Explosive Materials
124 Forest Forest Department NOC
125 Forest Distance from Forest Land
126 SUDA Hotel Business License
