odisha computer application centre...

Proposals are invited for selection of SystemIntegrator for implementation of State Wide roll-out of e-District Mission Mode Project, Odisha.Last date for submission of proposal is26.07.2013 upto 3 PM. For details please visitthe websites www.ocac.in , tenders.gov.in ,http://www.odisha.gov.in.N.B.:- OCAC reserves the right to accept/ reject any/ allproposals without assigning any reason thereof.General Manager(Admn.), OCAC, Plot No.-N-1/7-D, Acharya Vihar,P.O.-RRL, Bhubaneswar-751013, Ph.-2567280/ 2567064/ 2567295

REQUEST FOR PROPOSALEnq.No.:- OCAC-TJ-11/2012/ENQ/13015

(Technical Directorate of I.T. Deptt., Govt. of Odisha)ODISHA COMPUTER APPLICATION CENTRE

EXCELLENCE IN IT SOLUTIONS

RFP for Selection of System Integrator for Rollout of e-district MMP – Volume I

1 | P a g e

REQUEST FOR PROPOSAL FOR

SELECTION OF SYSTEM INTEGRATOR FOR STATE WIDE ROLLOUT

OF e-DISTRICT MMP

VOLUME I

RFP No: OCAC-TJ-11/2012/ENQ/13015 Dated: 24.06.2013

General Manager, Odisha Computer Application Centre (OCAC),

(Technical Directorate under IT Department, Govt. of Odisha), OCAC Building, Plot No. N-1/7D, Acharya Vihar Square, RRL Post Office,

Bhubaneswar – 751 013, Odisha Website: http://www.ocac.in/

http://www.ocac.in/


2 | P a g e

Table of Content

1 INTRODUCTION ............................................................................................................................................. 7

2 SCHEDULE OF BID PROCESS ........................................................................................................................... 8

3 STRUCTURE OF THE RFP ................................................................................................................................ 9

4 BACKGROUND INFORMATION ....................................................................................................................... 9

4.1 BASIC INFORMATION ......................................................................................................................................... 9

4.2 PROJECT BACKGROUND .................................................................................................................................... 10

4.3 STATE INFORMATION ....................................................................................................................................... 11

4.4 KEY INFORMATION .......................................................................................................................................... 13

4.5 ABOUT THE DEPARTMENT / OCAC..................................................................................................................... 14

5 INSTRUCTIONS TO THE BIDDERS .................................................................................................................. 15

5.1 RFP DOCUMENT ............................................................................................................................................. 15

5.2 LACK OF INFORMATION TO BIDDER ..................................................................................................................... 15

5.3 FRAUDULENT & CORRUPT PRACTICE ................................................................................................................... 16

5.4 APPLICABLE LAW ............................................................................................................................................. 16

5.5 BID CURRENCY ............................................................................................................................................... 16

5.6 PERFORMANCE SECURITY .................................................................................................................................. 16

5.7 OCAC’S RIGHT TO ACCEPT BID AND TO REJECT ANY OR ALL BIDS .............................................................................. 16

5.8 NOTICES ........................................................................................................................................................ 17

5.9 PATENT RIGHTS .............................................................................................................................................. 17

5.10 TAXES AND DUTIES .......................................................................................................................................... 17

5.11 INSURANCE .................................................................................................................................................... 17

5.12 PACKING ....................................................................................................................................................... 17

5.13 DIFFERING SHIPMENTS ..................................................................................................................................... 18

5.14 RESOLUTION OF DISPUTES AND ARBITRATION ....................................................................................................... 18

5.15 ACQUAINTANCE WITH LOCAL CONDITIONS ........................................................................................................... 18

5.16 LIMITATIONS OF LIABILITY ................................................................................................................................. 19

5.17 GENERAL ....................................................................................................................................................... 19

5.18 COMPLIANT PROPOSALS / COMPLETENESS OF RESPONSE ........................................................................................ 19

5.19 PRE-BID MEETING & CLARIFICATIONS ................................................................................................................. 19

5.19.1 Pre-bid Conference ............................................................................................................................ 19

5.19.2 Responses to Pre-Bid Queries and Issue of Corrigendum .................................................................. 20

5.20 KEY REQUIREMENTS OF THE BID ......................................................................................................................... 20

5.20.1 Right to Terminate the Process ......................................................................................................... 20

5.20.2 RFP Document Fees ........................................................................................................................... 21

5.20.3 Earnest Money Deposit (EMD) .......................................................................................................... 21

5.20.4 Submission of Proposals .................................................................................................................... 21

5.20.5 Authentication of Bids ....................................................................................................................... 22

5.21 PREPARATION AND SUBMISSION OF PROPOSAL ..................................................................................................... 22

5.21.1 Proposal Preparation Costs ............................................................................................................... 22

5.21.2 Language ........................................................................................................................................... 23

5.21.3 Venue & Deadline for Submission of Proposals ................................................................................. 23


3 | P a g e

5.21.4 Late Bids ............................................................................................................................................ 23

5.22 EVALUATION PROCESS ..................................................................................................................................... 23

5.22.1 Tender Opening ................................................................................................................................. 24

5.22.2 Tender Validity................................................................................................................................... 24

5.22.3 Tender Evaluation .............................................................................................................................. 24

5.23 PROJECT SCHEDULE ......................................................................................................................................... 25

5.24 TERMS OF PAYMENT SCHEDULE ......................................................................................................................... 26

5.25 PENALTY ........................................................................................................................................................ 28

5.26 SERVICE LEVEL AGREEMENTS ............................................................................................................................. 28

5.26.1 Operation & Maintenance Support ................................................................................................... 28

6 CRITERIA FOR EVALUATION ......................................................................................................................... 32

6.1 PRE-QUALIFICATION CRITERIA ........................................................................................................................... 32

6.2 TECHNICAL QUALIFICATION CRITERIA .................................................................................................................. 34

6.3 COMMERCIAL BID EVALUATION ......................................................................................................................... 42

7 APPOINTMENT OF SYSTEM INTEGRATOR .................................................................................................... 42

7.1 AWARD CRITERIA ............................................................................................................................................ 42

7.2 RIGHT TO ACCEPT ANY PROPOSAL AND TO REJECT ANY OR ALL PROPOSAL(S) ............................................................. 42

7.3 NOTIFICATION OF AWARD................................................................................................................................. 42

7.4 CONTRACT FINALIZATION AND AWARD ................................................................................................................ 43

7.5 PERFORMANCE GUARANTEE .............................................................................................................................. 43

7.6 SIGNING OF CONTRACT .................................................................................................................................... 43

7.7 FAILURE TO AGREE WITH THE TERMS AND CONDITIONS OF THE RFP ......................................................................... 43

8 ANNEXURE .................................................................................................................................................. 44

ANNEXURE I: TECHNICAL BID TEMPLATES .................................................................................................................. 44

FORM 1: UNDERTAKING ON TOTAL RESPONSIBILITY ............................................................................................................ 45

FORM 2: PARTICULARS OF THE BIDDER ............................................................................................................................. 46

FORM 3: BANK GUARANTEE FOR EMD ........................................................................................................................... 47

FORM 4A: COMPLIANCE SHEET FOR PRE-QUALIFICATION PROPOSAL ..................................................................................... 49

FORM 4B: COMPLIANCE SHEET FOR TECHNICAL PROPOSAL .................................................................................................. 52

FORM 5: LETTER OF PROPOSAL ....................................................................................................................................... 55

FORM 6: PROJECT CITATION FORMAT .............................................................................................................................. 56

FORM 7: PROPOSED SOLUTION ....................................................................................................................................... 57

FORM 8: PROPOSED WORK PLAN ................................................................................................................................... 58

FORM 9: TEAM COMPOSITION........................................................................................................................................ 59

FORM 10: CURRICULUM VITAE (CV) OF KEY PERSONNEL..................................................................................................... 60

FORM 11: DEPLOYMENT OF PERSONNEL .......................................................................................................................... 62

FORM 12: DEVIATIONS ................................................................................................................................................. 63

FORM 13: MANUFACTURERS AUTHORIZATION FORM ......................................................................................................... 64

FORM 14: DECLARATION ON SOURCE CODE AND INTELLECTUAL PROPERTY RIGHTS .................................................................. 66

FORM 15: UNDERTAKING ON PATENT RIGHTS ................................................................................................................... 67

FORM 16: UNDERTAKING ON COMPLIANCE AND SIZING OF INFRASTRUCTURE .......................................................................... 68

FORM 17: UNDERTAKING ON SERVICE LEVEL COMPLIANCE .................................................................................................. 69

FORM 18: UNDERTAKING ON DELIVERABLES ..................................................................................................................... 70


4 | P a g e

FORM 19: UNDERTAKING ON SUPPORT TO THIRD PARTY SOLUTION ACCEPTANCE AND CERTIFICATION .......................................... 71

FORM 20: DECLARATION OF ACTIVITIES SUB-CONTRACTED ................................................................................................... 72

FORM 21: UNDERTAKING ON EXIT MANAGEMENT AND TRANSITION ...................................................................................... 73

FORM 22: DECLARATION THAT THE BIDDER HAS NOT BEEN BLACKLISTED ................................................................................. 74

ANNEXURE II: FINANCIAL PROPOSAL TEMPLATE ..................................................................................................... 75

FORM 1: COVERING LETTER ........................................................................................................................................... 75

FORM 2: FINANCIAL PROPOSAL....................................................................................................................................... 77

Form 2.1: Software Development Commercial Format....................................................................................... 78

Form 2.2: Integration Cost Commercial Format ................................................................................................. 79

Form 2.3: Commercial Format for Equipment’s at SDC, Bhubaneswar .............................................................. 80

Form 2.4: Commercial Format for Equipment’s at District Collectorate ............................................................. 81

Form 2.5: Commercial Format of Equipment’s at Sub-Collector office ............................................................... 82

Form 2.6: Commercial Format of Equipment’s at Tahsil offices of Odisha ......................................................... 83

Form 2.7: Commercial format of Equipment’s at Block offices of Odisha ........................................................... 84

Form 2.8: System Software Commercial Format ................................................................................................ 85

Form 2.9: Broadband Connectivity Commercial Format ..................................................................................... 86

Form 2.10: Training/Workshop Commercial Format .......................................................................................... 87

Form 2.11: Application Support & Maintenance Cost ......................................................................................... 88

Form 2.12: Commercial Formant for Technical Support Staff at SDC & District Level ........................................ 89

Form 2.13: Other Cost Commercial Format ........................................................................................................ 90

ANNEXURE III: TEMPLATE FOR PBG & CCN .............................................................................................................. 91

FORM 1: PERFORMANCE BANK GUARANTEE ..................................................................................................................... 91

FORM 2: CHANGE CONTROL NOTICE (CCN) FORMAT ......................................................................................................... 93

ANNEXURE IV: DEFINITION OF GO-LIVE......................................................................................................................... 95

ANNEXURE V: RESOURCES ELIGIBILITY CRITERIA .............................................................................................................. 96


5 | P a g e

List of Abbreviation

Abbreviation Description

BDO Block Development Office

BG Bank Guarantee

CDAC Centre for Development of Advanced Computing

CMS Content Management System

CSC Common Service Center

CSP Content Service Provider

DeitY Department of Electronics and Information Technology

DHQ District Head Quarter

EC Empowered Committee

EMD Earnest Money Deposit

FRS Functional Requirement Specification

GIGW Guidelines for Indian Government Website

GoI Government of India

HLD High Level Design

MCIT Ministry of Communication and Information Technology

MMP Mission Mode Project

NIC National Informatics Centre

NPI National Portal of India

NPMU National Project Management Unit

MSA Master Service Agreement

NeGP National e-Governance Plan

OBC Other Backward Class

OCAC Odisha Computer Application Center

OWASP Open Web Application Security Project

PDS Public Distribution System

PKI Public Key Infrastructure

POP Point of Presence

RFP Request for Proposal

RI Revenue Inspector

SAP Service Access Providers

SCA Service Center Agency

SDHQ Sub-divisional Head Quarter

SDC State Data Center

SEBC Socially and Educationally Backward Class

http://en.wikipedia.org/wiki/Other_Backward_Class

http://acronyms.thefreedictionary.com/Socially+and+Educationally+Backward+Class


6 | P a g e

SeMT State e-Governance Mission Team

SI System Integrator

SLA Service Level Agreement

SOAP Simple Object Access Protocol

SP Service Providers

SPF State Portal Framework

SPMU State Project Management Unit

SSDG State Services Delivery Gateway

STQC Standard Testing and Quality & Certification

SWAN State Wide Area Network

UAT User Acceptance Test

UT Union Territory Management Unit

VLE Village Level Entrepreneur

WAP Wireless Application Protocol


7 | P a g e

1 Introduction

I. Under the e-District MMP National Roll-out, System Integrators will be responsible for

providing a comprehensive solution towards Supply, Installation, Development,

Integration, Commissioning, Management & Maintenance of Application and

Computing Infrastructure pertaining to e-District in various States.

II. Odisha Computer Application Centre (OCAC), Odisha invites the eligible parties

(hereafter referred as “Bidder”) for appointment as System Integrator for the Odisha

and provide the comprehensive solution as specified in the Scope of Work Section

(Refer Volume-II) of this RFP.

III. Bidders are advised to study this RFP document carefully before submitting their

proposals in response to this Notice. Submission of a proposal in response to this

notice shall be deemed to have been done after careful study and examination of this

document with full understanding of its terms, conditions and implications. Failure to

furnish all information required as mentioned in the RFP documents or submission of

a proposal not substantially responsive to the RFP documents in every respect will be

at the Bidder's risk and may result in rejection of the proposal.


8 | P a g e

2 Schedule of Bid Process

Information Details

1. RFP No. and Date OCAC-TJ-11/2012/ENQ/13015 dated

24.06.2013

2. Last date for submission of written

queries for clarifications

01/07/2013 15:00 Hrs

Email : [email protected]

3. Date of pre-bid conference 02/07/2013& 15:00 hr

4. Release of response to clarifications 11/07/2013 & 15:00 hrs

5. Bid validity period 180 days from the last date (deadline) for

submission of proposals.

6. Last date (deadline) for submission of

bids

26/07/2013 & 15:00 Hrs

7. Opening of Pre-Qualification & Technical

Bids

26/07/2013 & 17:00 Hrs

8. Technical Presentation by the Bidders “Will be intimated later

9. Place, Time and Date of opening of

Financial proposals received in response

to the RFP notice

“Will be intimated later”

10. Contact person for queries General Manager, Odisha Computer Application Centre (OCAC), (Technical Directorate under IT Department, Govt. of Odisha), OCAC Building, Plot No. N-1/7D, Acharya Vihar Square, RRL Post Office, Bhubaneswar – 751 013, Odisha Fax +91 -674-2567842

Phone .+91-674-2567280/064/295

Email: [email protected]

11. Addressee and address at which

proposal in response to RFP notice is

to be submitted:

General Manager, Odisha Computer Application Centre (OCAC), (Technical Directorate under IT Department, Govt. of Odisha), OCAC Building, Plot No. N-1/7D, Acharya Vihar Square, RRL Post Office, Bhubaneswar – 751 013, Odisha Fax +91 -674-2567842

Phone .+91-674-2567280/064/295

Email: [email protected]

mailto:[email protected]




9 | P a g e

3 Structure of the RFP

I. This Request for Proposal (RFP) document for Appointment of the System Integrator

for e-District Mission Mode Project (MMP) for OCAC comprise of the following.

A. Volume I: Instructions on the Bid process for the purpose of responding to this

RFP. This broadly covers:

1. General instructions for bidding process

2. Bid evaluation process including the parameters for Technical

evaluation and commercial evaluation to facilitate OCAC in

determining bidder’s suitability as the implementation partner

3. Payment schedule

4. Commercial bid and other formats

B. Volume II: Functional and Technical Requirements of the project. The contents

of the document broadly cover the following areas:

1. About the project and its objectives

2. Scope of work for the Implementation Partner

3. Functional and Technical requirements

4. Project Schedule

5. Service levels for the implementation partner

The bidder is expected to respond to the requirements as completely and in as

much relevant detail as possible, and focus on demonstrating bidder’s

suitability to become the implementation partner of OCAC.

C. Volume III: This is the Master Service Agreement (MSA), Service Level

Agreement (SLA) and Non-Disclosure Agreement (NDA) to be signed between

OCAC and the SI.

The bidders are expected to examine all instructions, forms, terms, Project requirements and

other information in the RFP documents. Failure to furnish all information required as

mentioned in the RFP documents or submission of a proposal not substantially responsive to

the RFP documents in every respect will be at the Bidder's risk and may result in rejection of

the proposal.

4 Background Information

4.1 Basic Information

I. OCAC invites proposals (“Tenders”) to this Request for Proposals (“RFP”) from Systems

Integrator Agencies (“Bidders”) for the provision of State Wide Rollout of eDistrict

project as per the scope of the work given in Vol-II of the RFP.

II. Any contract that may result from this Government procurement competition will be

issued for a term of 180 days.


10 | P a g e

III. The OCAC reserves the right to extend the Term for a period or periods of up to 180

days with a maximum of 270 days such extension or extensions on the same terms and

conditions, subject to the obligations at law.

IV. Proposals must be received not later than time, date and venue mentioned in the Fact

Sheet. Proposals that are received late WILL NOT be considered in this procurement

process.

4.2 Project Background

I. NeGP was approved by the Government of India in May 2006, with the following vision:

“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 realise the basic needs of the

common man”.

II. To realize this vision, 31 Central, State and Integrated Mission Mode projects (MMPs)

along with 8 support components were identified and approved under NeGP. States

have been given flexibility to identify up to 5 additional state-specific projects, which

are particularly relevant for the economic development of the State. NeGP also

envisages creation of the core IT infrastructure in the form of SWANs, SDCs and one

lakh front ends namely CSCs in rural areas across the country to deliver public services

electronically in the local language.

III. e-District is one of the 31 MMPs under NeGP, with the Department of Electronics and

Information Technology (DeitY), Government of India (GoI) as the nodal department, to

be implemented by State Government or their designated agencies. This MMP aims at

electronic delivery of identified high volume citizen centric services, at district and sub-

district level, those are not part of any other MMP. To achieve these objectives service

levels and outcomes for each of these services will be clearly laid down by the State

concerned, with a view to improving the efficiency and effectiveness of the service

delivery. The MMP envisages leveraging and utilizing the four pillars of e-infrastructure

namely, State Data Centres (SDCs), State Wide Area Network (SWANs), State Service

Delivery Gateways (SSDGs) and Common Service Centres (CSCs), optimally to deliver

public services electronically to citizens at their door steps. Initially only those high

volume citizen-centric services will be taken up for implementation which have high

priority for the State. New services will be added to the portfolio subsequently, once

the demand for the initial set of e-enabled services increases.

IV. Detailed scope of work is provided in Volume-II.


11 | P a g e

4.3 State Information

Odisha is located between the parallels of 17.49N and 22.34N latitudes and meridians of 81.27E and

87.29E longitudes. It is bounded by the Bay of Bengal on the east; Madhya Pradesh on the west and

Andhra Pradesh on the south. It has a coast line of about 450 kms. It extends over an area of

155,707 square kms. According to the 1991 census, it has a total population of 31, 512,070 (3.73

percent of the total population of India) out of which about 16,237,000 are male and 15,275,070 are

female. On the basis of homogeneity, continuity and physiographical characteristics, Odisha has

been divided into five major morphological regions: the Odisha Coastal Plain in the east, the Middle

Mountainous and highlands Region, the Central plateaus, the western rolling uplands and the major

flood plains.

Rollout of eDistrict project will take place at 28 District Collectorate, 51 sub-division offices, 268

Tahsils, 266 Block Offices and 1790 RI offices.

District Sub-Division Tahsil BDO RI Office

Sundargarh 3 18 17 102

Jharsuguda 1 5 5 10

Deogarh 1 3 3 20

Sambalpur 3 9 9 56

Keonjhar 3 13 13 80

Angul 4 8 8 55

Bhadrak 1 7 7 76


12 | P a g e

District Sub-Division Tahsil BDO RI Office

Jajpur 1 10 10 80

Dhenkanal 3 8 8 50

Balasore 2 12 12 85

Nuapada 1 5 5 21

Bolangir 3 14 14 34

Sonepur 2 6 6 31

Boudh 1 3 3 22

Kandhamal 2 12 12 74

Cuttack 3 15 14 127

Khurda 2 10 10 67

Puri 1 11 11 128

Kendrapara 1 9 9 92

Jagatsinghpur 1 8 8 76

Bargarh 2 12 12 84

Kalahandi 2 13 13 48

Nawrangpur 1 10 10 66

Rayagada 2 11 11 81

Gajapati 1 7 7 44

Koraput 2 14 14 95

Malkangiri 1 7 7 44

Nayagarh 1 8 8 42

28 51 268 266 1790

1. This project is the Rollout of the project subsequent to the pilot implementation in Ganjam

& Mayurbhanj districts of Odisha. The pilot application has already gone live in both the

districts.

2. Application Software Developed for the pilot implementation has been tested by STQC.

STQC report for the pilot eDistrict application has also been received.

3. Pilot application has been developed in open source technology using following

Specifications

• Java • PHP • Tomcat web server • Apache web server • MySQL


13 | P a g e

TRANSACTIONS IN GANJAM & MAYURBHANJ DISTRICTS

Cert Name Applications

filed at PFC

Applications

filed at CSC

Total applications

filed Approved Rejected Processed

Residence 48061 26249 74310 69006 1877 70883

Caste 16932 5941 22873 20547 591 21138

Legal Heir 1493 405 1898 1211 85 1296

Solvency 43 12 55 20 0 20

Income 29169 13246 42415 38586 1528 40114

SEBC 382 205 587 440 3 443

OBC 250 171 421 289 5 294

TOTAL 96330 46229 142559 130099 4089 134188

As on 7th March 2013

4.4 Key Information

The objectives of the e-District Mission Mode Project are to ensure the following:

I. Providing easy, anywhere and anytime access to government services (both

information & transactional) to ensure reliability, efficiency, transparency and

accountability.

II. Delivery of all public services at district/ sub district level in electronic form through

state portals by using the SSDG.

III. Reducing number of visits of citizens to a government office / department for availing

the services and thereby eliminating harassment.

IV. Reducing administrative burden and service fulfilment time and costs for the

government, citizens & businesses.

V. Reducing direct interaction of citizen with the government and encourage ‘e’-

interaction and efficient communication through portal.

VI. Enhancing perception & image of the Government and its constituent Departments.

VII. Undertake backend computerisation of District and Tehsil level offices to ensure

electronic delivery of high volume citizen centric services at the district level.

VIII. Efficient delivery of services with improved service levels by undertaking extensive

Business Process Re-engineering (BPR) of identified services.

IX. Delivery of services through CSCs by leveraging the common infrastructure of SWAN,

SDC, and SSDG.

X. Development of applications to be hosted at the SDCs for delivery of services.

XI. Extensive capacity building and training of field level functionaries to ensure smooth

migration to electronic delivery of e-district services and phasing out manual delivery

of services.


14 | P a g e

The key stakeholders of the project are illustrated below:

4.5 About the Department / OCAC

Item Description

Name of the SDA

Odisha Computer Application Center, Technical Directorate of

IT Department, Government of Odisha will be the

implementing agency at the State Level.

Date of establishment

21st March 1985

Name and Job title of key contact

person

Shri. M. S. Padhi, IAS, Commissioner-cum-Secretary to Govt. &

Chairman-cum-CEO, OCAC

Key Functions Key functions/activities performed by OCAC includes:

a. Providing consultancy and total solutions for the

successful implementation of an enterprise

information system.

b. Implementation of computerization schemes for self-

employment whether those are meant for any specific

government department or for some or all.

c. Providing single window service for major schemes

like IT KIOSK, BPO Complex under ITES.

d. Facilitating growth of new IT/ITES industries in the

State

Operational Office Locations Bhubaneswar, Berhampur, Rourkela


15 | P a g e

5 Instructions to the Bidders

5.1 RFP Document

Bidder is expected to examine all instructions, forms, terms, specifications, and other information in

the RFP document. Failure to furnish all information required by the RFP document or to submit a

Bid not substantially responsive to the RFP document in every respect will be at Bidder’s risk and

may result in the rejection of its Bid.

5.2 Lack of information to Bidder

The bidder shall be deemed to have carefully examined RFP document to his entire satisfaction. Any

lack of information shall not in any way relieve the bidder of his responsibility to fulfill his

obligation under the bid.


16 | P a g e

5.3 Fraudulent & Corrupt Practice

“Fraudulent Practice” means a misrepresentation of facts in order to influence a procurement

process or the execution of the project and includes collusive practice among bidders (prior to or

after Bid submission) designed to establish Bid prices at artificial non-competitive levels and to

deprive the OCAC of the benefits of free and open competition.

“Corrupt Practice” means the offering, giving, receiving or soliciting of anything of value,

pressurizing to influence the action of a public official in the process of project execution.

OCAC will reject a proposal for award if it determines that the bidder recommended for award has

engaged in corrupt or fraudulent practices in competing for, or in executing, the project.

5.4 Applicable Law

The Contract shall be interpreted in accordance with the laws of the Union of India.

5.5 Bid Currency

Prices for services offered shall be quoted in Indian National Rupees only.

5.6 Performance Security

Within 7 (Seven) days of Notification of “Award of the Work” the company shall furnish

Performance Security to OCAC @ 10% of the total value of quoted bid by way of irrevocable and

unconditional Bank Guarantee in favor of OCAC for a period to be specified in the award of work.

This Bank Guarantee should be of a sufficient duration to cover the risk of OCAC. The proceeds of

the Performance Security shall be payable to OCAC as compensation for any loss resulting from the

Company’s failure to fulfill its obligations under the terms and conditions of the Work Order.

The Performance Security regarding commencement of job / task will be discharged by OCAC and

returned to the company not later than 30 (Thirty) days following the date of completion of the

company’s performance, related obligations under the terms & conditions of the Work Order.

Failure of the successful bidder to comply with the requirements shall constitute sufficient ground

for the annulment of the notification and forfeiture of the bid security in which event, the OCAC may

award the contract in accordance with its prescribed rules

5.7 OCAC’s Right to Accept Bid and to reject any or all Bids

I. Prior to expiration of the period of Bid validity, OCAC will notify the successful bidder in

writing that its Bid has been accepted.

II. Within 7 days of receipt of such intimation, the successful bidder shall give its acceptance to

the OCAC


17 | P a g e

III. Upon the successful bidder's furnishing of Performance Security pursuant to Section 5.3

acceptance by successful Bidder, OCAC will promptly notify all unsuccessful bidders and

will discharge their Bid security

5.8 Notices

I. Any notice given by one party to the other pursuant to this contract shall be sent to the

other party in writing or by telex, email, cable or facsimile to the other party’s address, and

confirmed in writing by the other party.

II. A notice shall be effective when delivered or tendered to other party whichever is earlier.

5.9 Patent Rights

The Bidder shall indemnify the tenderer against all third party claims of infringement of patent,

trademark or industrial design and intellectual property rights arising from the use of equipments

and services or any part thereof.

5.10 Taxes and Duties

I. All the taxes, duties, levies and all other charges applicable and shall be valid for delivery on

FOR basis to the designated delivery points. All payments will be subjected to tax deduction

at source as applicable/required at the prevailing tax rates.

II. Govt. of Odisha / OCAC shall not pay any increase in duties, taxes and surcharges and other

charges on account of any revision, enactment during the period of validity of the Bids and

also during the contract period. The decision of OCAC in this regard will be final and binding

and no disputes in this regard will be entertained.

5.11 Insurance

To be applicable as mentioned under Vol-III RFP.

5.12 Packing

I. The vendor shall provide packing of systems in such a manner as to prevent their damage

or deterioration during transit to the project sites. The packing shall be sufficient to

withstand, without limitation, rough handling during transit and exposures to extreme

temperatures, humidity, sleet and precipitation during transit and open storage.

II. The Vendor shall promptly replace any system that is damaged in transit. The packing,

marking and documentation within and outside the packages shall also comply strictly with

the requirements.

III. There shall be a packing list, in each case, fully itemized to show case number, contents,

gross and net weight and cubic measurement.


18 | P a g e

5.13 Differing Shipments

If OCAC shall have notified the Vendor in writing that the former is not ready to take delivery, no

system or materials shall be forwarded until intimation in writing shall have been given to the

Vendor by the OCAC that it is ready to take delivery.

5.14 Resolution of Disputes and Arbitration

I. State and the selected bidder shall make every effort to resolve amicably by direct informal

negotiation any disagreement or dispute arising between them under or in connection with

the Contract.

II. If, after thirty (30) days from the commencement of such informal negotiations, State and

the selected Bidder have been unable to amicably resolve dispute, either party may require

that the dispute be referred for resolution to the formal mechanisms, which may include,

but are not restricted to, conciliation mediated by a third party acceptable to both, or in

accordance with the Arbitration and Conciliation Act, 1996.

III. All Arbitration proceedings shall be held at Bhubaneswar, Odisha, and the language of the

arbitration proceedings and that of all documents and communications between the parties

shall be in English.

5.15 Acquaintance with Local Conditions

I. Each Bidder is expected to fully get acquainted with the local conditions and factors, which

would have any effect on the performance of the contract and /or the cost.

II. The Bidder is expected to know all conditions and factors, which may have any effect on the

execution of the contract after issue of Letter of Intent/Award as described in the bidding

documents. The Tenderer shall not entertain any request for clarification from the Bidder

regarding such local conditions.

III. It is the Bidder’s responsibility that such factors have properly been investigated and

considered while submitting the bid proposals and no claim whatsoever including those for

financial adjustment to the contract awarded under the bidding documents will be

entertained by the Tenderer. Neither any change in the time schedule of the contract nor

any financial adjustments arising thereof shall be permitted by the Tenderer on account of

failure of the Bidder to know the local laws / conditions.


19 | P a g e

5.16 Limitations of Liability

The liability of the OCAC for its obligations under the Contract shall in no case exceed the total value

of the Contract.

5.17 General

I. While every effort has been made to provide comprehensive and accurate background

information and requirements and specifications, Bidders must form their own conclusions

about the solution needed to meet the requirements. Bidders and recipients of this RFP may

wish to consult their own legal advisers in relation to this RFP.

All information supplied by Bidders may be treated as contractually binding on the Bidders,

on successful award of the assignment by the OCAC on the basis of this RFP.

II. No commitment of any kind, contractual or otherwise shall exist unless and until a formal

written contract has been executed by or on behalf of the OCAC. Any notification of

preferred bidder status by the OCAC shall not give rise to any enforceable rights by the

Bidder. The OCAC may cancel this public procurement at any time prior to a formal written

contract being executed by or on behalf of the OCAC.

III. This RFP supersedes and replaces any previous public documentation & communications,

and Bidders should place no reliance on such communications.

5.18 Compliant Proposals / Completeness of Response

I. Bidders are advised to study all instructions, forms, terms, requirements and other

information in the RFP documents carefully. Submission of the bid shall be deemed to have

been done after careful study and examination of the RFP document with full understanding

of its implications.

II. Failure to comply with the requirements of this paragraph may render the Proposal non-

compliant and the Proposal may be rejected. Bidders must:

A. Include all documentation specified in this RFP;

B. Follow the format of this RFP and respond to each element in the order as set out in

this RFP

C. Comply with all requirements as set out within this RFP.

5.19 Pre-Bid Meeting & Clarifications

5.19.1 Pre-bid Conference

I. OCAC shall hold a pre-bid meeting with the prospective bidders on 02/07/2013 at 15:00

Hrs OCAC Building, Plot No. N-1/7D, Acharya Vihar Square, RRL Post Office, Bhubaneswar –

751 013, Odisha.

The Bidders will have to ensure that their queries for Pre-Bid meeting should reach to

General Manager, OCAC, OCAC Building, Plot No. N-1/7D, Acharya Vihar Square, RRL Post

Office, Bhubaneswar – 751 013, Odisha by post, facsimile or email on or before 01/07/2013

15:00 Hrs. The queries should necessarily be submitted in the following format:


20 | P a g e

II. OCAC shall not be responsible for ensuring that the bidders’ queries have been received by

them. Any requests for clarifications after the indicated date and time may not be

entertained by the OCAC.

5.19.2 Responses to Pre-Bid Queries and Issue of Corrigendum

I. The Nodal Officer notified by the OCAC will endeavour to provide timely response to all

queries. However, OCAC makes no representation or warranty as to the completeness or

accuracy of any response; neither response nor does OCAC undertake to answer all the

queries that have been posed by the bidders. The responses to the queries from all bidders

will be distributed to all.

II. At any time prior to the last date for receipt of bids, OCAC may, for any reason, whether at

its own initiative or in response to a clarification requested by a prospective Bidder, modify

the RFP Document by a corrigendum.

III. The Corrigendum (if any) & clarifications to the queries from all bidders will be posted on

the http://www.ocac.in and emailed to all participants of the pre-bid conference.

IV. Any such corrigendum shall be deemed to be incorporated into this RFP.

V. In order to provide prospective Bidders reasonable time for taking the corrigendum into

account, OCAC may, at its discretion, extend the last date for the receipt of Proposals.

5.20 Key Requirements of the Bid

5.20.1 Right to Terminate the Process

I. OCAC may terminate the RFP process at any time and without assigning any reason. OCAC

makes no commitments, express or implied, that this process will result in a business

transaction with anyone.

II. This RFP does not constitute an offer by OCAC. The bidder's participation in this process

may result OCAC selecting the bidder to engage towards execution of the contract.

S.

No.

RFP Document Reference(s)

(Section & Page Number(s))

Content of RFP requiring

Clarification(s)

Points of

clarification

1.

2.

3.

4.

5.

6.


21 | P a g e

5.20.2 RFP Document Fees

a) RFP document can be purchased at the address & dates provided in the Section 2 by

submitting a non-refundable bank demand draft of Rs. 5000.00, drawn in favour of Odisha

Computer Application Centre, payable at Bhubaneswar, Odisha from any scheduled

commercial banks.

b) The bidder may also download the RFP documents from the website www.ocac.in. In such

case, the demand draft of RFP document fees should be submitted along with Proposal.

Proposals received without or with inadequate RFP Document fees shall be rejected.

5.20.3 Earnest Money Deposit (EMD)

a) All proposals submitted in response to the RFP document must be accompanied by an EMD

of Rs. 80, 00,000.00 (Rs. Eighty Lacs only) in the form of a Demand Draft drawn in favour of

Odisha Computer Application Centre, payable at Bhubaneswar, Odisha Bids submitted

without adequate EMD will be liable for rejection.

b) EMD of all unsuccessful bidders would be refunded by OCAC within 3 months of the bidder

being notified as being unsuccessful. The EMD, for the amount mentioned above, of

successful bidder would be returned upon submission of Performance Bank Guarantee as

per the format provided in Annexure III: Form 1.

c) The EMD amount is interest free and will be refundable to the unsuccessful bidders without

any accrued interest on it.

d) The bid / proposal submitted without EMD, mentioned above, will be summarily rejected.

e) The EMD may be forfeited:

A. If a bidder withdraws its bid during the period of bid validity.

B. In the case of a successful bidder fails to (a) accept award of work, (b) sign the Contract

Agreement with OCAC, after acceptance of communication on placement of award, (c)

furnish performance security, (d) fails to sign the Contract Agreement in time, (e) or the

bidder violates any of such important conditions of this tender document or indulges in

any such activities as would jeopardize the interest of OCAC in timely finalization of this

tender. The decision of OCAC regarding forfeiture of bid security shall be final and shall

not be called upon question under any circumstances. A default in such a case may

involve black-listing of the bidder by OCAC/Govt. of Odisha. The bidder fails to co-

operate in the Bid evaluation process

5.20.4 Submission of Proposals

a) The bidders should submit their responses as per the format given in this RFP in the

following manner

A. Pre-Qualification Proposal - (1 Original + 2 Copies + 1 CD) in first envelope

B. Technical Proposal - (1 Original + 2 Copies +1 CD) in second envelope

C. Commercial Proposal - (1 Original & 1 Duplicate) in third envelope


22 | P a g e

b) The response to Pre-Qualification Proposal, Technical Proposal and Commercial Proposal

(as mentioned above) should be covered in separate sealed envelopes super-scribing, ”Pre-

Qualification Proposal”, “Technical Proposal” and “Commercial Proposal” respectively. Each

copy of each bid should also be marked as "Original" OR "Copy" as the case may be.

c) Please Note that prices should not be indicated in the Technical Proposal and should only be

indicated in the Commercial Proposal.

d) The three envelopes containing copies of Pre-Qualification Proposal, Technical Proposal and

Commercial Proposal should be put in another single larger sealed envelope clearly marked

“Response to RFP for <Name of the assignment> - < RFP Reference Number> and the

wordings “DO NOT OPEN BEFORE 26/07/2013 at 17:00 Hrs”.

e) The outer envelope thus prepared should also indicate clearly the name, address, telephone

number, E-mail ID and fax number of the bidder to enable the Bid to be returned unopened

in case it is declared "Late".

f) All the pages of the proposal must be sequentially numbered and must contain the list of

contents with page numbers. Any deficiency in the documentation may result in the

rejection of the Bid.

g) The original proposal/bid shall be prepared in indelible ink. It shall contain no

interlineations or overwriting, except as necessary to correct errors made by the bidder

itself. Any such corrections must be initialled by the person (or persons) who sign(s) the

proposals.

h) All pages of the bid including the duplicate copies, shall be initialled and stamped by the

person or persons who is authorised to sign the bid.

i) In case of any discrepancy observed by OCAC in the contents of the submitted original paper

bid documents with respective copies, the information furnished on original paper bid

document will prevail over others.

j) Bidder must ensure that the information furnished by bidders in respective CDs is identical

to that submitted in the original paper bid document. In case of any discrepancy observed

by OCAC in the contents of the CDs and original paper bid documents, the information

furnished on original paper bid document will prevail over the soft copy.

5.20.5 Authentication of Bids

The Proposal should be accompanied by a power-of-attorney in the name of the signatory of the

Proposal.

5.21 Preparation and Submission of Proposal

5.21.1 Proposal Preparation Costs

a) The bidder shall be responsible for all costs incurred in connection with participation in the

RFP process, including, but not limited to, costs incurred in conduct of informative and


23 | P a g e

other diligence activities, participation in meetings/discussions/presentations, preparation

of proposal, in providing any additional information required by OCAC to facilitate the

evaluation process, and in negotiating a definitive contract or all such activities related to

the bid process.

b) OCAC will in no case be responsible or liable for those costs, regardless of the conduct or

outcome of the bidding process.

5.21.2 Language

The Proposal should be filled by the Bidder in English language only. If any supporting

documents submitted are in any language other than English, translation of the same in

English language is to be duly attested by the Bidders. For purposes of interpretation of the

Proposal, the English translation shall govern.

5.21.3 Venue & Deadline for Submission of Proposals

Proposals, in its complete form in all respects as specified in the RFP, must be submitted to

OCAC at the address specified in Section 2.

5.21.4 Late Bids

a) Bids received after the due date and the specified time (including the extended period if

any) for any reason whatsoever, shall not be entertained and shall be returned unopened.

b) The bids submitted by telex/telegram/fax/e-mail etc. shall not be considered. No

correspondence will be entertained on this matter.

c) OCAC shall not be responsible for any postal delay or non-receipt/ non-delivery of the

documents. No further correspondence on the subject will be entertained.

d) OCAC reserves the right to modify and amend any of the above-stipulated

condition/criterion depending upon project priorities vis-à-vis urgent commitments.

5.22 Evaluation Process

a) OCAC will constitute a Proposal Evaluation Committee to evaluate the responses of the

bidders

b) The Proposal Evaluation Committee constituted by the OCAC shall evaluate the responses to

the RFP and all supporting documents / documentary evidence. Inability to submit requisite

supporting documents / documentary evidence, may lead to rejection.

c) The decision of the Proposal Evaluation Committee in the evaluation of responses to the

RFP shall be final. No correspondence will be entertained outside the process of

negotiation/ discussion with the Committee.

d) The Proposal Evaluation Committee may ask for meetings with the Bidders to seek

clarifications on their proposals


24 | P a g e

e) The Proposal Evaluation Committee reserves the right to reject any or all proposals on the

basis of any deviations.

f) Each of the responses shall be evaluated as per the criterions and requirements specified in

this RFP.

5.22.1 Tender Opening

I. The Proposals submitted up to 15:00 Hrs on 26/07/2013 will be opened at 17:00 Hrs on

26/07/2013 by General Manager or any other officer authorized by OCAC, in the presence

of such of those Bidders or their representatives who may be present at the time of opening.

II. The representatives of the bidders should be advised to carry the identity card or a letter of

authority from the tendering firms to identify their bonafides for attending the opening of

the proposal.

5.22.2 Tender Validity

The offer submitted by the Bidders should be valid for minimum period of 180 days from the date

of submission of Tender.

5.22.3 Tender Evaluation

I. Initial Bid scrutiny will be held and incomplete details as given below will be treated as non-

responsive, if Proposals :

A. Are not submitted in as specified in the RFP document

B. Received without the Letter of Authorization (Power of Attorney)

C. Are found with suppression of details

D. With incomplete information, subjective, conditional offers and partial offers

submitted

E. Submitted without the documents requested in the checklist

F. Have non-compliance of any of the clauses stipulated in the RFP

G. With lesser validity period

II. Existing Implementing Agencies which do not get their e-District Application Software for

their respective Pilot States/UTs certified by STQC will NOT be eligible to participate in the

bidding process for that State / UT under the National Rollout of the Scheme.

III. All responsive Bids will be considered for further processing as below.

OCAC will prepare a list of responsive bidders, who comply with all the Terms and

Conditions of the Tender. All eligible bids will be considered for further evaluation by a

Committee according to the Evaluation process define in this RFP document. The decision of

the Committee will be final in this regard.


25 | P a g e

5.23 Project Schedule

Sl. No Deliverables Completion Time

1. Award of Contract & Team Mobilization T0

2. Preparation of Project Charter and project plan T0 + 1 weeks

3. Functional Design Documents, User Interface Design

Specifications, Technical Design Documents, Integration

Design Specifications Systems, Requirements

Specification (SRS) preparation and approval

T0 + 6 weeks

4. High Level Design (HLD), Low Level Design (LLD), and

Software Design Documents (SDD)

T0+ 8 weeks

5. Completion of Application Development T0+ 15 weeks

6. Testing Strategy, Performance Testing criteria, User

Acceptance Criteria, Unit Test Scripts with Results,

System Integration Test Scenarios and scripts, UAT

Scenarios and scripts

T0 + 16 weeks

7. User Acceptance Test Report T0 + 18 weeks

8. System certification by STQC T0 + 22 weeks

9. Completion of Training & Change Management activities T0 + 26 weeks

10. Go-Live of eDistrict Application T0 + 30 weeks = T1

11. End-to-end project documentation and creation of manuals

T0 + 22 weeks

12. Installation & Commissioning of Hardware at District Level Offices

T0 + 16 weeks

13. Installation & Commissioning of Hardware at SDC T0 + 12 weeks

14. Onsite support covering 3 years of warranty from the date of Go-Live

T2

15. 2 years of AMC for all the H/W, N/W equipment’s, peripherals after completion of 3 years of warranty period

T2 + 2 Years


26 | P a g e

5.24 Terms of Payment Schedule

The following schedule would be followed for payment during the Project implementation:

S. No Milestone % of Total Fee Basis of approval

1 Approval of Final SRS 5% Minutes of meeting of the Apex Committee approving the report

2 UAT of the e-District Application by Apex Committee, deployment of necessary hardware at SDC and completion of following key activities:

- Development of connectors for SSDG

- Integration with NSDG

- Integration with AADHAAR

- Integration with Payment Gateway

- Localisation of eDistrict Application

- CSC wise Transaction reports &

calculation of fee for each SCA

- Mobile enablement of eDistrict

Application

5% Minutes of meeting of the Apex Committee approving the e-District application for all services identified in the RFP.

3 Successful District Readiness for all offices, i.e. Completion of all activities/ commissioning of all hardware & networking equipment’s in a district; i.e.

- Hardware

- Network

- Training

- Placement of Technical Manager in the

district

15% Approval of the District Collector

4 STQC Certification 5% Copy of the STQC certification

5 “Go-Live” in at least 25% Districts 10% Go-live in a district would mean 1) Using the e- District application

6 “Go-Live” in at least 50% Districts 5%

7 “Go-Live” in at least 75% Districts 5%


27 | P a g e

S. No Milestone % of Total Fee Basis of approval

8 “Go-Live” in 100% Districts 5% for delivery of all services 2) Completion of training 3) Deployment of identified hardware for those Districts 4) Engagement of Technical Support Staff at SDC & District Level

9 Operations and Maintenance Phase 36% To be paid quarterly (3% per quarter) for 36 months

10 Successful Exit Management 9% Minutes of meeting of the Apex Committee

Total 100%


28 | P a g e

5.25 Penalty

In the event the bidder is unable to meet defined milestones, a penalty of 0.5% will be charged for

each week delay from payment associated to the respective milestone, maximum limit being 10% of

the respective mile stone amount. If the delay continues beyond 20 weeks, OCAC, may terminate the

Agreement.

5.26 Service Level Agreements

5.26.1 Operation & Maintenance Support

Sl. No. SLA Terms Description

1. System 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 OCAC. The selected SI will plan

scheduled downtime outside working time. In

exceptional circumstances, OCAC may allow the

SI to plan scheduled downtime in the working

hours.

2. 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.


29 | P a g e

Service

Category

Service

Level Title

/ Objective

Data Capture Measureme

nt Interval

Reportin

g Period

Hours

of

Suppor

t

Target

Servic

e

Level

Minimu

m

Service

Level

Service

Level

Dependenc

y

Increase

d Impact

Severity Weight

System

Uptime and

Performanc

e - SDC

System

uptime and

performanc

e of the

system -

SDC

No. of

recorded

hours on

server logs of

uninterrupte

d usage of the

system by

users during

working

hours

Weekly Weekly 24x7 99.9% 99% Power

Backup

Upgrades

System

Restores

To be

base

lined for

first 6

months

INR 300,000 per month for

every drop in percentage

point of uptime below 99.5 %

[The non-availability for

application service, website

measured on monthly basis

and excluding the scheduled

maintenance shutdown.

Performance of system refers

to the proper and timely

functioning of the system’s

functionalities. The

applications should be

available and performing as

per functionalities]

System

Uptime and

Performanc

e – Field

Offices

System

uptime and

performanc

e of the

system –

Field Offices

No. of

recorded

hours on

manual logs

of

uninterrupte

d usage of

each

hardware &

peripheral by

users during

working

hours

Monthly Monthly 9 x 6 >99% >99% Power

Backup

To be

base

lined for

first 6

months

INR 750 per instance of

violation for a drop in uptime

between <99% and >=98%.

Additional INR 1500 per

instance of violation for every

1% drop in percentage point

of uptime below 98%.


30 | P a g e

Service

Category

Service

Level Title

/ Objective


nt Interval

Reportin

g Period

Hours

of

Suppor

t

Target

Servic

e

Level

Minimu

m

Service

Level

Service

Level

Dependenc

y

Increase

d Impact

Severity Weight

Network

Availability

Average

LAN

Network

Availability

of

each of the

designated

office

location and

the nearest

SWAN PoP.

Recording the

no. of hours

of network

outage during

working

hours.

Monthly Monthly 6 x 9 > 99% > 99% To be

base

lined for

first 6

months

INR 50,000 per month for

every drop in percentage

point of uptime below 98%

Helpdesk

Performanc

e

98% of the

calls shall be

answered

within 45

seconds.


base

lined for

first 6

months

INR 750 per month for every

drop in percentage point of

uptime below 98%

Helpdesk

Performanc

e

98% of the

incidents

within

helpdesk

resolution

capacity

shall be

resolved in

a cycle time

of 24 hours.


base

lined for

first 6

months



uptime below 98%

Helpdesk

Performanc

e

90% of the

Level 1

Incidents


base

lined for



uptime below 98%


31 | P a g e

Service

Category

Service

Level Title

/ Objective


nt Interval

Reportin

g Period

Hours

of

Suppor

t

Target

Servic

e

Level

Minimu

m

Service

Level

Service

Level

Dependenc

y

Increase

d Impact

Severity Weight

shall be

resolved

within 6

hours from

call received

/ logged

whichever

is earlier

first 6

months

Helpdesk

Performanc

e

90% of the

Level 2

Incidents

shall be

resolved

within 24

hours from

call received

/ logged

whichever

is earlier


base

lined for

first 6

months



uptime below 98%

Helpdesk

Performanc

e

90% of the

Level 3

Incidents

shall be

resolved

within 48

hours from

call received

/ logged

whichever

is earlier


base

lined for

first 6

months



uptime below 98%


32 | P a g e

6 Criteria for Evaluation

I. The overall objective of this evaluation process is to select the capable and qualified firm in

the business domain of developing and rolling out a Portal, eDistrict Application, related

hardware and other infrastructure, providing associated capacity building, training and

handholding support as well as associated managed services and who will provide a

comprehensive solution towards Supply, Installation, Integration, Commissioning,

Development, Deployment, Operation & Management of eDistrict Application and hardware

provisioning in Odisha.

II. First the Pre-Qualification Proposal will be evaluated and only those bidders who qualify

the requirements will be eligible for next set of evaluations. Technical Proposal and

Commercial Proposal of Bidders who do not meet the Pre-Qualification criteria will be

returned without opening.

III. The technical score of all the bidders would be calculated as per the criteria mentioned

below. All the bidders who achieve at least 70 marks in the technical evaluation would be

eligible for the next stage, i.e. Financial Bid opening.

IV. Proposals of Companies would be evaluated as per Technical Evaluation Criteria (Section

6.2). Agencies / firms should clearly indicate, giving explicit supporting documentary

evidence, with respect to the above, in absence of which their proposals will be rejected

summarily at the qualification stage itself.

6.1 Pre-Qualification Criteria

Sr. No Qualification Criteria Documents/Information to be

provided in the submitted proposal

1. The responding firm / agency

a. Should have made a payment of Rs. 5000 (Rupees Five Thousands only) for the RFP document

b. Should have submitted a EMD of Rs. 80,00,000 (Rupees Eighty Lacs only)

a) Demand Draft for Rs. 5000

b) Demand Draft for Rs. 80,00,000

2. Legal Entity

Company should be registered under Companies Act, 1956

Registered with the Service Tax Authorities Should have been operating for the last

three years (FY 11-12, FY 10-11 and FY 09-10)

a) Certificate of Incorporation

b) Registration Certificate

3. The Firm / Company should be in the business as System Integrator for at least 3 years as of 31st March 2012

a) Annexure I: Form 2 Details of Responding Firm

b) Memorandum & Articles of Association


33 | P a g e

Sr. No Qualification Criteria Documents/Information to be

provided in the submitted proposal

c) Work orders confirming year and Area of activity

4. The responding firm shall not be under a

declaration of ineligibility for corrupt or

fraudulent practices.

Self-Declaration by the designated

official as per the format of the

responding firm or Annexure-I: Form

22

5. The Net Worth of the responding firm must be

positive as per the last audited Balance Sheet.

Chartered Accountant Certificate for

Net worth

6. The responding firm should be ISO 9000:2008

certified.

Copy of Relevant Certificate which is

valid on date of submission.

7. The responding firm should be minimum

CMMi Level 3.

Relevant certificate needs to be

attached which is valid on date of

submission.

Additional Requirement

Sl No Requirement State Category Requirements

Documents/ Information to be provided

1 Average Annual Sales Turnover generated from services related to System Integration (SI) during the last three (3) financial years (FY 11-12, FY 10-11 and FY 09-10) as per the last published balance sheets

Rs. 75 Crores or more

a) Extracts from the audited Balance sheet and Profit & Loss; OR

b) Certificate from the

statutory auditor. 2 Company experience in implementation of

integrated turnkey projects around application development as a System Integrator in India.

(Specifically each project should have components of Hardware, Networking, Helpdesk and Application related training necessarily for this project). Refer to the Important Note below for more details. Number of such Assignments of value (as specified for tiers) which have gone live in the past 5 years (FY 11-12, FY 10-11, FY 09-10 FY 08-09 and FY 07-08)

One 40 Crores Project

OR Two 20 Crores Projects OR Three 16 Crores Project

Completed Annexure I: Form 6: Details of Experience of responding firm/ Project Citation for projects supported with Work order and Proof of Go-live/ Project completion certificates from client


34 | P a g e

Sl No Requirement State Category Requirements

Documents/ Information to be provided

Note: Value of the project should be 40 Crores if only one project detail is given. Bidder can also provide two (2) project citations of atleast 20 Crores or Three Projects citations of atleast 16 Crores

3 The responding firm must have a minimum number of IT Staff of technically qualified personnel in the domain of systems integration, as on 31st July, 2012 on its roll.

150 Certificate from HR Department for number of technically qualified professionals employed by the company

6.2 Technical Qualification Criteria

I. Technical proposal of the bidders will be opened and evaluated who meets all the

prequalification criteria.

II. The evaluation committee will evaluate the Technical Proposals on the basis of the technical

evaluation criterion as provided below.

S. No Criteria Max Criteria/ Sub

Criteria Marks

1 Past Experience of the responding firm 30

2 Solution proposed for the e-District Project by the responding

firm

40

3 Work Plan approach and proposed methodology 10

4 Adequacy and Quality of Resources proposed for Deployment 20

Total Points 100


35 | P a g e

Sl

No.

Criteria/Sub

Criteria

Description Point System Max

Criteria

/ Sub

Criteria

Points

Form to

be used

1 Past Experience of the responding firm 30

a.

System Integration

projects

At least THREE

client

references for

implementation

of an integrated

turnkey project

around a)

network

solution and b)

software

development c)

Hardware

commissioning

and d) O&M

phase for

maintaining all

of the above.

Total Work order value

of three project

>INR 30 Crores = 15

points;

>INR 24 crores but less

than INR 30 crores=10

points;


than INR 24 crores=5

points;


than INR 18 crores

crores=2 points;


than INR 12 crores =1

point; else 0

15

Annexure-

I: Form 6,

supported

by

document

ary

evidence

b.

Hardware

Products

Installation

Whether the

Firm has

delivered

hardware

products in at

least Three

projects of

similar size in

the last 3 years.

Value of hardware only

in three work order:

> INR 60 Crores = 5

points;

>INR 50 crores but

less than INR 60

crores=4 points;

>INR 40 crores but

less than INR 50

crores=3 points;

> INR 30 crores but

less than INR 40

crores=2 points;

>INR 15 crores but

5

Annexur

e-I: Form

6,

supporte

d by

documen

tary

evidence


36 | P a g e

Sl

No.

Criteria/Sub

Criteria


Criteria

/ Sub

Criteria

Points

Form to

be used

less than INR 30

crores=1 points;

else 0

c. Software Solutions

At least TWO

completed /

ongoing

software

development

projects each

having a

minimum value

of INR 1 crore –

for software

development

component

only). The

project should

have some or all

of the following

components :

– Portal

– Web based

Application

Engine

– Workflow

> 4 Projects – 5

points;

4 Projects - 4 points;



else 0.

5

Annexure-

I: Form 6

supported

by

document

ary

evidence

d.

Maintenance Services and Helpdesk in the State

Providing Maintenance Services / Helpdesk services in the field of IT services with a minimum

In case of any one project done for the following locations : a. covers > 22

districts – 5 points

b. covers > 14

5


37 | P a g e

Sl

No.

Criteria/Sub

Criteria


Criteria

/ Sub

Criteria

Points

Form to

be used

order size of INR 2 Crores in the State

districts & less than 22 districts – 3 points

c. covers > 7 & less than 14 districts – 1 points else; 0

Note :

1. For all the above, the Completion Certificate of the projects completed

in the last 3 years (as on <31/12/2012>) need to be provided (issued to

the responding firm by the respective customers)

2. The value of the projects considered in the above criterion would be

based on the Purchase Order or the LOI issued to the responding firm. In

absence of the supporting documents, the projects would not be

considered for evaluation

2 Solution proposed 40

a. Proposed solution

Requirements

addressed as

mentioned in

different parts

of the RFP and

the quality of

the solution

Evaluation Committee

will evaluate whether

all the points/

requirements

mentioned in the RFP

are addressed well and

award points

accordingly, the

important parameters

being:-

– Solution architecture

conceptualized for

this project.

– Security architecture

– Detailed plan for

using SWAN as

connectivity

– Application

15

-


38 | P a g e

Sl

No.

Criteria/Sub

Criteria


Criteria

/ Sub

Criteria

Points

Form to

be used

deployment and

testing Strategy

– Quality Control

Procedures

suggested by

responding firm

– Comprehensiveness

of Bill of material of

all the components

(e.g. software,

hardware, etc.) along

with their quantities

b.

Proposed

Approach and

methodology

Evaluation

Committee will

evaluate

whether the

implementation

methodology is

in line with the

requirement.

The important

parameters

being:-

- Plan for

meeting the

SLA norms.

- Redundancy

and failover

options.

- Spare

equipment

In this section, the

responding firm

should:

– Explain the

understanding of the

project requirements

– highlight the

expected support

from the State

– approach to the

services, SLA

management

methodology

– methodology for

carrying out the

activities for

expected output

– Highlight the

associated risks /

problems and plans

for mitigation and

15


39 | P a g e

Sl

No.

Criteria/Sub

Criteria


Criteria

/ Sub

Criteria

Points

Form to

be used

availability

plans

explain the technical

approach it would

adopt to address

them

– Explain the

methodologies the

responding firm

proposes to adopt

and highlight the

compatibility of

those methodologies

with the proposed

approach

– Planning and

Building

Infrastructure

(assessment, design,

integration /

migration of existing

Portal infrastructure)

c Training

Proposed

Training and

Change

Management

plan description

to be looked

into

The Evaluation will be

based on:

Proposed Training Schedule

– Plan to develop Training Manuals

– Areas/domains covered

– Number & Quality of personnel to be deployed for training at the site of Implementation of the Project

5

-


40 | P a g e

Sl

No.

Criteria/Sub

Criteria


Criteria

/ Sub

Criteria

Points

Form to

be used

d

Formation/Locatio

n of Helpdesk &

other manpower

support

Proposed

methodology of

formation of the

manpower

support team.

Operating and

Maintaining

Infrastructure

The Evaluation will be

based on

– Proposed Staff

details

– Areas/domains

covered

5 -

3 Work Plan Approach & Proposed Methodology 10

a. Project

Management

The overall

approach to be

looked into

The overall project

management approach

adopted by the

responding firm to

implement the project

to meet the timelines.

5 -

b. Detailed Work

Plan

The description

and quality of

the work plan to

be looked into.

Evaluation will be

based on the detailed

Project Plan including

day wise, week wise

activities with Work

Breakdown Structures,

Project estimates,

milestones etc.

5 Form 8

4 Resource Deployment 20

a

Quality of CV of the

resources

proposed for the

project

Quality of the

resources

proposed to

work on the

project

Qualification/relevant

certification of the

People Involved

10

Annexure

-I: Form

10


41 | P a g e

Sl

No.

Criteria/Sub

Criteria


Criteria

/ Sub

Criteria

Points

Form to

be used

b

Quality of District

level as Technical

e-District managers

Quality of

Technical

Support Staff to

be deployed at

the District.

Education

Qualification/ relevant

certification of the

people involved

10

Annexure

-I: Form

10

Total Points 100


42 | P a g e

6.3 Commercial Bid Evaluation

I. The Financial Bids of technically qualified bidders (i.e. above 70 marks) will be opened on

the prescribed date in the presence of bidder representatives.

II. Only fixed price financial bids indicating total price for all the deliverables and services

specified in this bid document will be considered.

III. The bid price will include all taxes and levies and shall be in Indian Rupees and mentioned

separately.

IV. Any conditional bid would be rejected.

V. Errors & Rectification: Arithmetical errors will be rectified on the following basis: “If there

is a discrepancy between the unit price and the total price that is obtained by multiplying

the unit price and quantity, the unit price shall prevail and the total price shall be corrected.

If there is a discrepancy between words and figures, the amount in words will prevail”.

VI. If there is no price quoted for certain material or service, the bid shall be declared as

disqualified.

VII. In the event that there are 2 or more bidders having the same value in the financial bid, the

bidder securing the highest technical score will be adjudicated as the “Best responsive bid”

for award of the Project.

7 Appointment of System Integrator

7.1 Award Criteria

OCAC will award the Contract to the successful bidder whose financial proposal is the lowest and

would consider it as substantially responsive as per the process outlined above.

7.2 Right to Accept Any Proposal and To Reject Any or All Proposal(s)

OCAC reserves the right to accept or reject any proposal, and to annul the tendering process /

Public procurement process and reject all proposals at any time prior to award of contract, without

thereby incurring any liability to the affected bidder or bidders or any obligation to inform the

affected bidder or bidders of the grounds for OCAC action.

7.3 Notification of Award

I. Prior to the expiration of the validity period, OCAC will notify the successful bidder in

writing or by fax or email, that its proposal has been accepted. In case the tendering process

/ public procurement process has not been completed within the stipulated period, OCAC,

may like to request the bidders to extend the validity period of the bid.

II. The notification of award will constitute the formation of the contract. Upon the successful

bidder's furnishing of Performance Bank Guarantee, OCAC will notify each unsuccessful

bidder and return their EMD.


43 | P a g e

7.4 Contract Finalization and Award

I. The OCAC shall reserve the right to negotiate with the bidder(s) whose proposal has been

most responsive. On this basis the draft contract agreement would be finalized for award &

signing.

II. OCAC may also like to reduce or increase the quantity of any item in the Scope of Work

defined in the RFP. Accordingly total contract value may change on the basis of the rates

defined in the financial proposal.

7.5 Performance Guarantee

I. OCAC will require the selected bidder to provide a Performance Bank Guarantee, within 15

days from the Notification of award, for a value equivalent to 10% of the total cost of

ownership. The Performance Guarantee should be valid for a period of 6 months. The

Performance Guarantee shall be kept valid till completion of the project and Warranty

period. The Performance Guarantee shall contain a claim period of three months from the

last date of validity. The selected bidder shall be responsible for extending the validity date

and claim period of the Performance Guarantee as and when it is due on account of non-

completion of the project and Warranty period. In case the selected bidder fails to submit

performance guarantee within the time stipulated, OCAC at its discretion may cancel the

order placed on the selected bidder without giving any notice. OCAC shall invoke the

performance guarantee in case the selected Vendor fails to discharge their contractual

obligations during the period or OCAC incurs any loss due to Vendor’s negligence in

carrying out the project implementation as per the agreed terms & conditions.

7.6 Signing of Contract

After OCAC notifies the successful bidder that its proposal has been accepted, OCAC shall

enter into a contract, incorporating all clauses, pre-bid clarifications and the proposal of the

bidder between OCAC and the successful bidder.

7.7 Failure to Agree with the Terms and Conditions of the RFP

Failure of the successful Bidder to agree with the Terms and Conditions of the RFP shall

constitute sufficient grounds for the annulment of the award, in which event OCAC may

award the Contract to the next best value Bidder or call for new Bids.


44 | P a g e

8 Annexure

Annexure I: TECHNICAL BID TEMPLATES

The bidders are expected to respond to the RFP using the forms given in this section and all

documents supporting Technical Evaluation Criteria. Technical Proposal shall comprise of following

forms:

Form 1: Undertaking on Total Responsibility

Form 2: Particulars of the Bidder

Form 3: Bank Guarantee for Earnest Money Deposit

Form 4: Compliance Sheet for Pre-Qualification Proposal

Form 5: Letter of Proposal

Form 6: Project Citation Format

Form 7: Proposed Solution

Form 8: Proposed Work Plan

Form 9: Team Composition

Form 10: Curriculum Vitae (CV) of Key Personnel

Form 11: Deployment of Personnel

Form 12: Deviations

Form 13: Manufacturers Authorisation Form

Form 14: Declaration on Source Code and Intellectual Property Rights

Form 15: Undertaking on Patent Rights

Form 16: Undertaking on Compliance and Sizing of Infrastructure

Form 17: Undertaking on Service Level Compliance

Form 18: Undertaking on Deliverables

Form 19: Undertaking on Support to Third Party Solution acceptance and certification

Form 20: Declaration of Activities sub-contracted

Form 21: Undertaking on Exit Management and Transition

Form 22: Declaration that the bidder has not been blacklisted


45 | P a g e

Form 1: Undertaking on Total Responsibility

No. Date:

To:

General Manager, Odisha Computer Application Centre (OCAC), (Technical Directorate under IT Department, Govt. of Odisha), OCAC Building, Plot No. N-1/7D, Acharya Vihar Square, RRL Post Office, Bhubaneswar – 751 013, Odisha

Dear Sir,

Sub: Self certificate regarding Total Responsibility

This is to certify that we undertake total responsibility for the successful and defect free operation

of the proposed Project solution, as per the requirements of the RFP for eDistrict Project.

Thanking you,

Yours faithfully

(Signature of the Authorized signatory of the Bidding Organisation)

Name :

Designation :

Date :

Time :

Seal :

Business Address:


46 | P a g e

Form 2: Particulars of the Bidder

SI No. Information Sought Details to be Furnished

A Name and address of the

bidding Company

B Incorporation status of the firm

(public limited / private

limited, etc.)

C Year of Establishment

D Date of registration

E ROC Reference No.

F Details of company registration

G Details of registration with

appropriate authorities for

service tax

H Name, Address, email, Phone

nos. and Mobile Number of

Contact Person


47 | P a g e

Form 3: Bank Guarantee for EMD

To,

<Name> <Designation> <Address> <Phone Nos.> <Fax Nos.> <email id>

Whereas <Name of the bidder> (hereinafter called 'the Bidder') has submitted the bid for

Submission of RFP # <RFP Number> dated <Date> for <Name of the assignment> (hereinafter

called "the Bid") to OCAC

Know all Men by these presents that we < > having our office at <Address> (hereinafter called "the

Bank") are bound unto the OCAC (hereinafter called "the Purchaser") in the sum of Rs. <Amount in

figures> (Rupees <Amount in words> only) for which payment well and truly to be made to the said

Purchaser, the Bank binds itself, its successors and assigns by these presents. Sealed with the

Common Seal of the said Bank this <Date>

The conditions of this obligation are:

1. If the Bidder having its bid withdrawn during the period of bid validity specified by the Bidder

on the Bid Form; or

2. If the Bidder, having been notified of the acceptance of its bid by the Purchaser during the period

of validity of bid

(a) Withdraws his participation from the bid during the period of validity of bid document;

or

(b) Fails or refuses to participate in the subsequent Tender process after having been short

listed;

We undertake to pay to the Purchaser up to the above amount upon receipt of its first written

demand, without the Purchaser having to substantiate its demand, provided that in its demand the

Purchaser will note that the amount claimed by it is due to it owing to the occurrence of one or both

of the two conditions, specifying the occurred condition or conditions.


48 | P a g e

This guarantee will remain in force up to <insert date> and including <extra time over and above

mandated in the RFP> from the last date of submission and any demand in respect thereof should

reach the Bank not later than the above date.

NOTHWITHSTANDING ANYTHING CONTAINED HEREIN:

I. Our liability under this Bank Guarantee shall not exceed Rs. <Amount in figures> (Rupees

<Amount in words> only)

II. This Bank Guarantee shall be valid upto <insert date>)

III. It is condition of our liability for payment of the guaranteed amount or any part thereof

arising under this Bank Guarantee that we receive a valid written claim or demand for

payment under this Bank Guarantee on or before <insert date>) failing which our liability

under the guarantee will automatically cease.

(Authorized Signatory of the Bank)

Seal:

Date:


49 | P a g e

Form 4A: Compliance Sheet for Pre-Qualification Proposal

Sr.

No

Qualification

Criteria

Documents/Information

to be provided in the

submitted proposal

Compliance Reference & Page

Number

1. The responding firm /

agency

(a) Should have made

a payment of

Rs.5000(Rupees Five

Thousand only) for

the RFP document

(b) Should have

submitted a EMD of

Rs. 80,00,000

(Rupees Eighty Lacs

only)

a) Demand Draft for

Rs. 5000

b) BG/Demand Draft

for Rs. 80,00,000

Yes/No

2. Legal Entity

Company should

be registered

under Companies

Act, 1956

Registered with

the Service Tax

Authorities

Should have been

operating for the

last three years

(FY 11-12, FY 10-

11 and FY 09-10)

a) Certificate of

Incorporation

b) Registration

Certificate

Yes/No

3. The Firm / Company

should be in the

business as System

Integrator for at least

3 years as of 31st

March 2012

a) Annexure I: Form 2

Details of

Responding Firm

b) Memorandum &

Articles of

Association

c) Work orders

confirming year and

Area of activity

Yes/No

4. The responding firm

shall not be under a

Self-Declaration by the

designated official as per

Yes/No


50 | P a g e

Sr.

No

Qualification

Criteria



submitted proposal


Number

declaration of

ineligibility for

corrupt or fraudulent

practices.

the format of the

responding firm or

Annexure-I: Form 22

5. The Net Worth of the

responding firm must

be positive as per the

last audited Balance

Sheet.

Chartered Accountant

Certificate for Net worth

Yes/No


should be ISO

9000:2008 certified.

Copy of Relevant

Certificate which is valid

on date of submission.

Yes/No


should be minimum

CMMi Level 3.

Relevant certificate needs

to be attached which is

valid on date of

submission.

Yes/No

8. Average Annual Sales Turnover generated from services related to System Integration (SI) during the last three (3) financial years (FY 11-12, FY 10-11 and FY 09-10) as per the last published balance sheets

Extracts from the audited Balance sheet and Profit & Loss; OR Certificate from the statutory auditor.

Yes/No

9. Company experience in implementation of integrated turnkey projects around application development as a System Integrator in India. (Specifically each project should have components of Hardware, Networking, Helpdesk and Application related training

Completed Annexure I: Form 6: Details of Experience of responding firm/ Project Citation for 3 projects supported with Work order and Proof of Go-live/ Project completion certificates from client

Yes/No


51 | P a g e

Sr.

No

Qualification

Criteria



submitted proposal


Number

necessarily for this project). Refer to the Important Note below for more details. Number of such Assignments of value (as specified for tiers) which have gone live in the past 5 years (FY 11-12, FY 10-11, FY 09-10, FY 08-09 and FY 07-08) Note: Value of the project should be 40 Crores if only one project detail is given. Bidder can also provide two (2) project citations of atleast 20 Crores or Three Projects citations of atleast 16 Crores

10. The responding firm must have a minimum number of IT Staff of technically qualified personnel in the domain of systems integration, as on 31st July, 2012 on its roll.

Certificate from HR Department for number of technically qualified professionals employed by the company

Yes/No


52 | P a g e

Form 4B: Compliance Sheet for Technical Proposal

The Technical proposal should comprise of the following basic requirements. The documents

mentioned in this compliance sheet along with this form, needs to be a part of the Technical

proposal

For Technical Evaluation

S.

No.

Specific Requirements Documents Required Compliance Reference &

Page Number

1 Covering Letter for

Technical Proposal

As per Form 5 Yes / No

2 System Functionality:

Meeting the requirements

with respect to the

common functionalities

as described.

A note containing the

Mapping as per information

provided

Yes / No

3 Technology:

Demonstrated robustness

of the technology

deployed across other

installations around the

world, including

– Scalability

– Security

– Ease of

implementation

A note containing details on

a) Solution architecture

b) Security

c) System Performance

d) Supported Platform

Operating System

e) Client Hardware Operating

System

f) Database

g) System Management

h) Web Server Support

i) Application Server Support

j) Single Sign-on

k) Presentation

l) Session Management

m) Integration capabilities

n) Auditing / Reporting

features

o) Disaster recovery & back-

up

And Form 7

Yes / No


53 | P a g e

S.

No.


Page Number

4 Industry Specific

Capabilities:

Past experience of the

bidder in executing

similar assignments, size

of those assignments in

the past five years.

[The definition of

“similar” should be such

that it focuses on the

areas which are

“innovative” or where the

technical feasibility is a

challenge in the context

of the project]

Completion Certificates from

the client; OR

Work Order + Self Certificate of

Completion (Certified by the

Statutory Auditor); OR

Work Order + Phase

Completion Certificate (for

ongoing projects) from the

client

Yes / No

5 Training:

Trainings proposed by

the vendor and the

amount of emphasis laid

on Training the

employees schedule

details, locations,

sessions and their

description

A note on training containing

a) Training model

b) Approach

c) Deliverables

Yes / No

7 Profile of proposed

team members:

Relevant assignment

experience / Years of

experience / Number of

Certifications in

Technology specific to

Solution proposed

Form 9,10 and 11 Yes / No

8 Project Methodology,

Support and

Documentation

Form 8 & additional

notes/document for support &

documentation

Yes / No


54 | P a g e

S.

No.


Page Number

9 Tools and Assets As per

requirement specified in

Technical evaluation)

Tools and Assets which could

be leveraged for the

assignment [for e.g. Test Case

Builders, Effort Estimators,

PMU Tool, Load testing etc.,

depending on the relevance to

the Scope of work]

A note and demonstration of

the Tool/ Assets

Yes / No

10 Deviations (if any) Form 12 Yes / No


55 | P a g e

Form 5: Letter of Proposal

To: <Location, Date>


Subject: Submission of the Technical bid for <Name of the Systems Implementation assignment>

Dear Sir/Madam,

We, the undersigned, offer to provide Systems Implementation solutions to the OCAC on <Name of

the Systems Implementation engagement> with your Request for Proposal dated <insert date> and

our Proposal. We are hereby submitting our Proposal, which includes this Technical bid and the

Financial Bid sealed in a separate envelope.

We hereby declare that all the information and statements made in this Technical bid are true and

accept that any misinterpretation contained in it may lead to our disqualification.

We undertake, if our Proposal is accepted, to initiate the Implementation services related to the

assignment not later than the date indicated in Fact Sheet.

We agree to abide by all the terms and conditions of the RFP document. We would hold the terms

of our bid valid for 180 days as stipulated in the RFP document.

We hereby declare that we are not insolvent, in receivership, bankrupt or being wound up, our

affairs are not being administered by a court or a judicial officer, our business activities have not

been suspended and we are not the subject of legal proceedings for any of the foregoing.

We understand you are not bound to accept any Proposal you receive.

Yours sincerely,

Authorized Signature [In full and initials]:

Name and Title of Signatory:

Name of Firm:

Address:

Location: _____________________________________Date: ___________________________

_____________________________________________________________________________


56 | P a g e

Form 6: Project Citation Format

Relevant IT project experience (provide no more than 5 projects in the last 5 years)

General Information

Name of the project

Client for which the project was executed

Name and contact details of the client

Project Details

Description of the project

Scope of services

Service levels being offered/ Quality of service

(QOS)

Technologies used

Outcomes of the project

Other Details

Total cost of the project

Total cost of the services provided by the

respondent

Duration of the project (no. of months, start

date, completion date, current status)

Other Relevant Information

Letter from the client to indicate the successful

completion of the projects

Copy of Work Order


57 | P a g e

Form 7: Proposed Solution

Technical approach, methodology and work plan are key components of the Technical Proposal.

You are suggested to present Approach and Methodology divided into the following sections:

a) Solution Proposed

b) Understanding of the project (how the solution proposed is relevant to the understanding)

c) Technical Approach and Methodology

Sl.

No

Proposed Solution

(Provide the Product

Name or fill Custom

Built, in case of a new

development)

Version &

Year of

Release

OEM Feature

s &

Functio

nalities

O&M Support

(Warranty/AT

S/: as

required as

per RFP)

Reference in the

Submitted

Proposal (Please

provide page

number/section

number/ volume)


58 | P a g e

Form 8: Proposed Work Plan

No Activity1 Calendar Months

1 2 3 4 5 6 7 8 9 10 11 12 n

1

2

3

4

5

N

1 Indicate all main activities of the assignment, including delivery of reports (e.g.: inception,

interim, and final reports), and other benchmarks such as Purchaser approvals. For phased

assignments indicate activities, delivery of reports, and benchmarks separately for each phase.

2 Duration of activities shall be indicated in the form of a bar chart.

3 All activities should meet the 8/80 criteria i.e should at least take 8 hours and a maximum of 80

hours.


59 | P a g e

Form 9: Team Composition

Name of Staff with

qualification and

experience

Area of

Expertise

Position

Assigned

Task

Assigned

Time

committed

for the

engagement


60 | P a g e

Form 10: Curriculum Vitae (CV) of Key Personnel

General Information

Name of the person

Current Designation / Job Title

Current job responsibilities

Proposed Role in the Project

Proposed Responsibilities in the Project

Academic Qualifications:

Degree

Academic institution graduated from

Year of graduation

Specialization (if any)

Key achievements and other relevant

information (if any)

Professional Certifications (if any)

Total number of years of experience

Number of years with the current company

Summary of the Professional / Domain

Experience

Number of complete life cycle

implementations carried out

The names of customers (Please provide the

relevant names)

Past assignment details (For each assignment

provide details regarding name of

organizations worked for, designation,

responsibilities, tenure)

Prior Professional Experience covering:

Organizations worked for in the past

o Organization name

o Duration and dates of entry and

exit

o Designation Location(s)

o Key responsibilities

Prior project experience

o Project name


61 | P a g e

o Client

o Key project features in brief

o Location of the project

o Designation

o Role

o Responsibilities and activities

o Duration of the project

Please provide only relevant projects.

Proficient in languages (Against each language

listed indicate if speak/read/write)


62 | P a g e

Form 11: Deployment of Personnel

No Name of Staff Staff input in Months (in the form of a bar chart)2

Total

staff

man-

months

proposed

1 2 3 4 5 6 7 8 9 10 11 12 n Total

1

2

3

N

Total

1. Professional Staff the input should be indicated individually; for Support Staff it should

be indicated by category

2 Months are counted from the start of the assignment.

Full time input Part time input


63 | P a g e

Form 12: Deviations

This section should contain any assumption on areas which have not been provided in the

RFP OR any changes to the existing provisions of the RFP

A - On the Terms of Reference

[Suggest and justify here any modifications or improvement to the Scope of Work you are proposing to

improve performance in carrying out the assignment (such as deleting some activity you consider

unnecessary, or adding another, or proposing a different phasing of the activities). Such suggestions

should be concise and to the point, and incorporated in your Proposal.]

B – Any other areas


64 | P a g e

Form 13: Manufacturers Authorization Form

(This form has to be provided by the OEMs of the products proposed)

No. Date:

To:


OEM Authorization Letter

Dear Sir:

Ref: Your RFP Ref: [*] dated [*]

We who are established and reputable manufacturers / producers of ________________________ having

factories / development facilities at (address of factory / facility) do hereby authorize M/s

___________________ (Name and address of Agent) to submit a Bid, and sign the contract with you

against the above Bid Invitation.

We hereby extend our full guarantee and warranty for the Solution, Products and services offered

by the above firm against this Bid Invitation.

We hereby declare that we are not insolvent, in receivership, bankrupt or being wound up, our

affairs are not being administered by a court or a judicial officer, our business activities have not

been suspended and we are not the subject of legal proceedings for any of the foregoing.

We also undertake to provide any or all of the following materials, notifications, and information

pertaining to the Products manufactured or distributed by the Supplier:

a. Such Products as the Bank may opt to purchase from the Supplier, provided, that this option

shall not relieve the Supplier of any warranty obligations under the Contract; and

b. in the event of termination of production of such Products:

i. advance notification to the Bank of the pending termination, in sufficient time to

permit the Bank to procure needed requirements; and


65 | P a g e

ii. Following such termination, furnishing at no cost to the Bank, the blueprints, design

documents, operations manuals, standards, source codes and specifications of the

Products, if requested.

We duly authorize the said firm to act on our behalf in fulfilling all installations, Technical support

and maintenance obligations required by the contract.

Yours faithfully,

Name:

Name of Producers:

Note: This letter of authority should be on the letterhead of the manufacturer and should be signed

by a person competent and having the power of attorney to bind the manufacturer. The Bidder in

its Bid should include it.


66 | P a g e

Form 14: Declaration on Source Code and Intellectual Property Rights

No. Date:

To:


Dear Sir,

Sub: Self-certificate regarding the source code and Intellectual property rights under this

Project

I, authorized representative of _________________________, hereby solemnly affirm to the IPR and Source

Code rights as defined in Part III of this RFP document.

In the event of any deviation from the factual information/ declaration, OCAC reserves the right to

terminate the Contract without any compensation to the System Integrator.

Thanking you,

Yours faithfully


Name :

Designation :

Date :

Time :

Seal :

Business Address:


67 | P a g e

Form 15: Undertaking on Patent Rights

No. Date:

To:


Dear Sir,

Sub: Undertaking on Patent Rights

1. I/We as System Integrator (SI) do hereby undertake that none of the

deliverables being provided by us is infringing on any patent or intellectual and industrial

property rights as per the applicable laws of relevant jurisdictions having requisite

competence.

2. I/We also confirm that there shall be no infringement of any patent or intellectual and

industrial property rights as per the applicable laws of relevant jurisdictions having requisite

competence, in respect of the equipments, systems or any part thereof to be supplied by us. We

shall indemnify OCAC against all cost/claims/legal claims/liabilities arising from third party

claim in this regard at any time on account of the infringement or unauthorized use of

patent or intellectual and industrial property rights of any such parties, whether such claims

arise in respect of manufacture or use. Without prejudice to the aforesaid indemnity, the

SI shall be responsible for the completion of the supplies including spares and uninterrupted

use of the equipment and/or system or any part thereof to OCAC and persons authorized by

OCAC, irrespective of the fact of claims of infringement of any or all the rights mentioned above.

3. If it is found that it does infringe on patent rights, I/We absolve OCAC of any legal

action.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:


68 | P a g e

Form 16: Undertaking on Compliance and Sizing of Infrastructure

No. Date:

To:


Dear Sir,

Sub: Undertaking on Compliance and Sizing of Infrastructure

1. I/We as System Integrator do hereby undertake that we have proposed and sized the

hardware and all software (including perennial and enterprise wide licenses, unless

stated otherwise) based on information provided by OCAC in its RFP document and

in accordance with the service level requirements and minimum specifications

provided and assure OCAC that the sizing is for all the functionality envisaged in the

RFP document.

2. Any augmentation of the proposed solution or sizing of any of the proposed solutions

(including software and hardware) in order to meet the minimum RFP

requirements and/or the requisite service level requirements given by OCAC will

be carried out at no additional cost to OCAC during the entire period of Contract.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:


69 | P a g e

Form 17: Undertaking on Service Level Compliance

No. Date:

To:


Dear Sir,

Sub: Undertaking on Service Level Compliance

1. I/We as System Integrator do hereby undertake that we shall monitor, maintain, and

comply with the service levels stated in the RFP to provide quality service to

OCAC.

2. However, if the proposed resources and infrastructure are found to be insufficient in

meeting the RFP and/or the service level requirements given by OCAC, then we will

augment the same without any additional cost to OCAC.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:


70 | P a g e

Form 18: Undertaking on Deliverables

No. Date:

To:


Dear Sir,

Sub: Undertaking on Deliverables

1. I/We as System Integrator do hereby undertake that processes, deliverables/artifacts

submitted to OCAC will adhere to the quality and standards specified in this RFP.

2. We also recognize and undertake that the deliverables/artifacts shall be

presented and explained to OCAC and other key stakeholders (identified by OCAC), and also

take the responsibility to provide clarifications as requested by OCAC.

3. We agree to abide by the procedures laid down for acceptance and review of deliverables

/ artifacts by the Department as stated in this RFP or as communicated to us from time-to-time.

4. We also understand that the acceptance, approval and sign-off of the deliverables by

OCAC will be done on the advice of Department and any other agency appointed by the

Department for the same. We understand that while all efforts shall be made to accept and

convey the acceptance of each deliverable in accordance with the Project schedule, no

deliverable will be considered accepted until a specific written communication to that effect

is made by OCAC.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:


71 | P a g e

Form 19: Undertaking on Support to Third Party Solution acceptance and certification

No. Date:

To:


Dear Sir,

Sub: Undertaking on Support to Third Party Solution Acceptance and Certification

1. I/We understand that the System (including the application and the associated IT

systems) may be assessed and certified by a 3rd party agency (to be identified by

OCAC) before the system is commissioned.

2. I/We understand that while the certification expenses will be borne by OCAC,

the responsibility to ensure successful acceptance and certification lies with the System

Integrator.

3. I/We hereby undertake that we shall do all that is required of the System

Integrator to ensure that system will meet all the conditions required for successful

acceptance and certification.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:


72 | P a g e

Form 20: Declaration of activities sub-contracted

No. Date:

To:


Dear Sir,

Sub: Declaration on Sub-contracting

I/ We hereby declare the following list of activities which we would be sub-contracted.

S. No. Activity

1

2

3

4

I/ We would be responsible for ensuring that the sub-contracted work meets the requirements of

the Department.

Thanking you,

Yours faithfully


Name :

Designation :

Date :

Time :

Seal :

Business Address:


73 | P a g e

Form 21: Undertaking on Exit Management and Transition

No. Date:

To:


Dear Sir,

Sub: Undertaking on Exit Management and Transition

I/We hereby undertake that at the time of completion of o u r engagement with the Department, either at the End of Contract or termination of Contract before planned Contract Period for any reason, we shall successfully carry out the exit management and transition of this Project to the OCAC or to an agency identified by OCAC to the satisfaction of the Department. I/We further undertake to complete the following as part of the Exit management and transition:

a. We undertake to complete the updation of all Project documents and other artefacts and handover the same to OCAC before transition.

b. We undertake to design standard operating procedures to manage system (including application and IT systems), document the same and train OCAC personnel on the same.

c. If Department decides to take over the operations and maintenance of the Project on its own or identifies or selects any other agency for providing operations & maintenance services on this Project, then we shall provide necessary handholding and transition support, which shall include but not be limited to, conducting detailed walkthrough and demonstrations for the IT Infrastructure, handing over all relevant documentation, addressing the queries/clarifications of the new agency with respect to the working / performance levels of the infrastructure, conducting Training sessions etc.

I/We also understand that the Exit management and transition will be considered complete on the basis of

approval from OCAC.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:


74 | P a g e

Form 22: Declaration that the bidder has not been blacklisted

(To be submitted on the Letterhead of the responding agency)

{Place}

{Date}

To,


Ref: RFP Notification no <xxxx> dated <dd/mm/yy>

Subject: Self Declaration of not been blacklisted in response to the RFP for Selection of

System Integrator for Statewide Roll-out of e-District MMP.

Dear Sir,

We confirm that our company, ____________, is not blacklisted in any manner whatsoever by any of

the State/UT and/or central government in India on any ground including but not limited to

indulgence in corrupt practice, fraudulent practice, coercive practice, undesirable practice or

restrictive practice.

Place:

Date:

Bidder’s Company Seal:

Authorized Signatory’s Signature:

Authorized Signatory’s Name and Designation:

Note: The Bidder shall necessarily provide a copy of ‘Power of Attorney’ authorizing the signatory

for signing the Bid on behalf of the Bidder in its Pre-Qualification Bid.


75 | P a g e

ANNEXURE II: FINANCIAL PROPOSAL TEMPLATE

Form 1: Covering Letter

To:

<Location, Date>


Subject: Submission of the Financial bid for <Provide Name of the Implementation Assignment>

Dear Sir/Madam,

We, the undersigned, offer to provide the Implementation services for <Title of

Implementation Services> in accordance with your Request for Proposal dated <Date> and our

Proposal (Technical and Financial Proposals). Our attached Financial Proposal is for the sum of

<Amount in words and figures>. This amount is inclusive of the local taxes.

1. PRICE AND VALIDITY

All the prices mentioned in our Tender are in accordance with the terms as specified in the

RFP documents. All the prices and other terms and conditions of this Bid are valid for a

period of 180 calendar days from the date of opening of the Bid.

We hereby confirm that our prices include all taxes. However, all the taxes are quoted

separately under relevant sections.

We understand that the actual payment would be made as per the existing indirect tax rates

during the time of payment.

2. UNIT RATES

We have indicated in the relevant forms enclosed, the unit rates for the purpose of on account of

payment as well as for price adjustment in case of any increase to / decrease from the scope of

work under the contract.

3. DEVIATIONS

We declare that all the services shall be performed strictly in accordance with the Tender

documents except for the variations and deviations, all of which have been detailed out

exhaustively in the following statement, irrespective of whatever has been stated to the contrary

anywhere else in our bid.


76 | P a g e

Further we agree that additional conditions, if any, found in the Tender documents, other than

those stated in deviation schedule, shall not be given effect to.

4. TENDER PRICING

We further confirm that the prices stated in our bid are in accordance with your Instruction to

Bidders included in Tender documents.

5. QUALIFYING DATA

We confirm having submitted the information as required by you in your Instruction to Bidders.

In case you require any other further information/documentary proof in this regard before

evaluation of our Tender, we agree to furnish the same in time to your satisfaction.

6. BID PRICE

We declare that our Bid Price is for the entire scope of the work as specified in the RFP. These

prices are indicated Commercial Bid attached with our Tender as part of the Tender.

7. PERFORMANCE BANK GUARANTEE

We hereby declare that in case the contract is awarded .to us, we shall submit the Performance

Bank Guarantee as specified in the <Form 3> of this RFP document.

Our Financial Proposal shall be binding upon us subject to the modifications resulting from

Contract negotiations, up to expiration of the validity period of the Proposal, i.e., [Date].

We understand you are not bound to accept any Proposal you receive.

We hereby declare that our Tender is made in good faith, without collusion or fraud and the

information contained in the Tender is true and correct to the best of our knowledge and belief.

We understand that our Tender is binding on us and that you are not bound to accept a Tender

you receive.

Thanking you,

We remain,

Yours sincerely,

Authorized Signature:

Name and Title of Signatory:

Name of Firm:

Address:


77 | P a g e

Form 2: Financial Proposal

Summary of Total Project Cost- Component Wise

Sl No. Project Expenditure Heads Reference to other tables Cost

Software Development Cost

1. Application Software

Development Form 2.1. INR 0.00

Integration Cost

2 Integration Components Form 2.2 INR 0.00

Hardware & Networking Cost

3. Hardware Form 2.3+Form 2.4+ Form 2.5 + Form 2.6 +

Form 2.7+ Form 2.8 INR 0.00

System Software

4. System Software Cost Form 2.9 INR 0.00

Connectivity

5. Broadband Connectivity Form 2.10 INR0.00

Training Cost

6. Stakeholder Training Cost Form 2.11 INR 0.00

Application Support Cost

7. Application Support Cost for

3 years after Go-Live Form 2.12 INR 0.00

Technical Support Staff

8. Technical Support Staff Form 2.13

Other Project Related Costs

9. Other Costs Form 2.14 INR 0.00

Total e-District Solution Cost INR 0.00


78 | P a g e

Form 2.1: Software Development Commercial Format

Module

Requirement

Analysis SRS SDD Development Testing Deployment &

Implementation

Oth

er

Co

st

To

tal

Mo

du

le C

ost

R2

Spec

ify

oth

er

reso

urc

e ty

pes

R3

Spec

ify

oth

er

reso

urc

e ty

pes

R3 R4 R 9

Spec

ify

oth

er

reso

urc

e ty

pes

R3 R 10

Spec

ify

oth

er

reso

urc

e ty

pes

R 12 R5

Spec

ify

oth

er

reso

urc

e ty

pes

R6

Spec

ify

oth

er

reso

urc

e ty

pes

Module-1

En

ter

man

m

on

ths

for

reso

urc

e ty

pe

En

ter

man

m

on

ths

for

re

sou

rce

typ

e

Module-2

***

Total Cost

Unit cost per resource should be mentioned in the below table.

Resource Type Role Unit

Rate

Resource Type Role Unit

Rate

R1 Project Manager

R7 Help Desk Resource

R2 System/Business Analyst

R8 Maintenance & Support Engineer

R3 Sr. Software Engineer

R9 Solution Architect

R4 Database Expert

R10 Developer

R5 Software Testing Expert

R11 Data Migration Specialist

R6 Implementation Engineer

R12 System Integration Tester

In order to meet the project requirements, it may be necessary to carry out modification /customization to the proposed solution. The above quoted amount shall be used if State Designated Agency wants to carry out any modification/customization activities later. The rates will be applicable for the entire duration of the contract period.


79 | P a g e

Form 2.2: Integration Cost Commercial Format

A B C D

Software Item Cost/Unit Tax (If any) No. of Units Cost per Software item (A+B)xC

Development of Connectors for

SSDG

INR 0.00 INR 0.00

Mobile enablement of eDistrict

Application

INR 0.00 INR 0.00

Integration with NSDG INR 0.00 INR 0.00

Payment Gateway Integration INR 0.00 INR 0.00

E-Authentication with

AADHAR

INR 0.00 INR 0.00

Localisation of Application INR 0.00 INR 0.00

Total Cost for Integration INR 0.00


80 | P a g e

Form 2.3: Commercial Format for Equipment’s at SDC, Bhubaneswar

Sl

No. Item

Description

Unit Price

(P)

Tax

(t)

Total

amount/unit

T=(P+t)

Total Qty

(Q)

Total

amount

T*Q

Remarks

1 Server For Helpdesk and SLA INR 0.00 INR 0.00 INR 0.00 2 Nos. INR 0.00

2 Server for Antivirus INR 0.00 INR 0.00 INR 0.00 1 Nos. INR 0.00

3 Software for Helpdesk, SLA &

Asset Management INR 0.00 INR 0.00 INR 0.00 1 Nos. INR 0.00

4 Antivirus Software solution INR 0.00 INR 0.00 INR 0.00 1 Nos. INR 0.00

5 42 U Server Rack INR 0.00 INR 0.00 INR 0.00 1 Nos. INR 0.00

6 Any other (Please Specify)

Total Cost for equipment’s at SDC INR 0.00


81 | P a g e

Form 2.4: Commercial Format for Equipment’s at District Collectorate

Sl

No.

Item Description Unit Price

(P)

Tax (t) Total

amount/unit

T=(P+t)

Total Qty

(Q)

Total

amount

T*Q

Remarks

1 Laptop INR 0.00 INR 0.00 INR 0.00 56 Nos. INR 0.00

2 Desktop INR 0.00 INR 0.00 INR 0.00 224 Nos. INR 0.00

3 24 Port LAN switch INR 0.00 INR 0.00 INR 0.00 56 Nos. INR 0.00

4 LaserJet Printer INR 0.00 INR 0.00 INR 0.00 140 Nos. INR 0.00

5 Laser Jet Printer, Scanner,

Copier all in one Device

INR 0.00 INR 0.00 INR 0.00 28 Nos. INR 0.00

6 Scanner INR 0.00 INR 0.00 INR 0.00 56 Nos. INR 0.00

7 Bio-Metric Device INR 0.00 INR 0.00 INR 0.00 280 Nos. INR 0.00

8 Antivirus INR 0.00 INR 0.00 INR 0.00 280 Nos. INR 0.00

9 1 KVA offline UPS INR 0.00 INR 0.00 INR 0.00 224 Nos. INR 0.00

10 9 U Networking Rack INR 0.00 INR 0.00 INR 0.00 56 Nos. INR 0.00

11 UTP cable CAT-6 (Box of 305

Mtrs)

INR 0.00 INR 0.00 INR 0.00 56 Nos. INR 0.00

12 Jack Panel 24 Port CAT 6 INR 0.00 INR 0.00 INR 0.00 56 Nos. INR 0.00

13 Information Outlet CAT6 INR 0.00 INR 0.00 INR 0.00 420 Nos. INR 0.00

14 Surface Mount Box Single INR 0.00 INR 0.00 INR 0.00 420 Nos. INR 0.00

15 Mounting Cord 7 Ft. CAT 6 INR 0.00 INR 0.00 INR 0.00 420 Nos. INR 0.00


17 6 Core Multimode Fiber with

necessary terminator

INR 0.00 INR 0.00 INR 0.00 14000 Mtr INR 0.00


Total Cost for equipment’s at District Collectorate INR 0.00


82 | P a g e

Form 2.5: Commercial Format of Equipment’s at Sub-Collector office

Sl

No.


(P)

Tax

(t)

Total amount/

Unit T=(P+t)

Total Qty

(Q)

Total

amount

T*Q

Remarks


2. Desktop INR 0.00 INR 0.00 INR 0.00 102 Nos. INR 0.00




6 Bio-Metric Device INR 0.00 INR 0.00 INR 0.00 153 Nos. INR 0.00




10 UTP cable CAT-6 (Box of 305 Mtrs) INR 0.00 INR 0.00 INR 0.00 51 Nos. INR 0.00







Total Cost for equipment’s at Sub Collectorate INR 0.00


83 | P a g e

Form 2.6: Commercial Format of Equipment’s at Tahsil offices of Odisha

Sl

No.


(P)

Tax

(t)

Total amount/

Unit T=(P+t)

Total Qty

(Q)

Total

amount

T*Q

Remarks






6 Bio-Metric Devices INR 0.00 INR 0.00 INR 0.00 1072 Nos. INR 0.00



9 UTP cable CAT-6 (Box of 305 Mtrs) INR 0.00 INR 0.00 INR 0.00 268 Nos. INR 0.00








Total Cost for equipment’s at Tahsils INR 0.00


84 | P a g e

Form 2.7: Commercial format of Equipment’s at Block offices of Odisha

Sl

No.


(P)

Tax

(t)

Total amount/

Unit T=(P+t)

Total Qty

(Q)

Total

amount

T*Q

Remarks

1. Laptop INR 0.00 INR 0.00 INR 0.00 266 Nos. INR 0.00


3. LaserJet Printer INR 0.00 INR 0.00 INR 0.00 266 Nos. INR 0.00

4 Bio-Metric Devices INR 0.00 INR 0.00 INR 0.00 798 Nos. INR 0.00


6. 1 KVA offline UPS INR 0.00 INR 0.00 INR 0.00 532 Nos. INR 0.00

7. UTP cable CAT-6 (Box of 305 Mtrs) INR 0.00 INR 0.00 INR 0.00 266 Nos. INR 0.00

8. Information Outlet CAT6 INR 0.00 INR 0.00 INR 0.00 1330 Nos. INR 0.00

9. Surface Mount Box Single INR 0.00 INR 0.00 INR 0.00 1330 Nos. INR 0.00

10. Mounting Cord 7 Ft. CAT 6 INR 0.00 INR 0.00 INR 0.00 1330 Nos. INR 0.00

11. Mounting Cord 3 Ft. CAT 6 INR 0.00 INR 0.00 INR 0.00 1330 Nos. INR 0.00

12. Any other (Please Specify)

Total Cost for equipment’s at Block Offices INR 0.00


85 | P a g e

Form 2.8: System Software Commercial Format

A B C D

Item Description Cost/Unit Tax (If any) No. of Units Cost per Middleware

item (A+B)xC

INR 0.00 INR 0.00

INR 0.00 INR 0.00

INR 0.00 INR 0.00

INR 0.00 INR 0.00

Total Cost of System Software INR 0.00


86 | P a g e

Form 2.9: Broadband Connectivity Commercial Format

Office Category Number of Offices Broadband Bandwidth Cost/Office Total Cost/Month

Tahsil Offices 268 2 Mbps INR 0.00 INR 0.00

RI Offices 1790 512 Kbps INR 0.00 INR0.00

Total Cost for Broadband Connectivity


87 | P a g e

Form 2.10: Training/Workshop Commercial Format

A B C D

Training/Workshop Item Cost/Trainee Service Tax (If any) No. of Person Total Training Cost (A+B)xC

Training of Government Official 11200 INR 0.00

Training of CSC Operators 650 INR 0.00

Total Cost for Training/Workshop INR 0.00


88 | P a g e

Form 2.11: Application Support & Maintenance Cost

Sl No. Item Unit Price (P) Tax (t) Total Amount T=(P+t) Remarks

AMC for a Period of 3 years at 12 equal installments from date of Go-Live of all services

1. INR 0.00 INR 0.00 INR 0.00

2. INR 0.00 INR 0.00 INR 0.00

3. INR 0.00 INR 0.00 INR 0.00

4. INR 0.00 INR 0.00 INR 0.00

5. INR 0.00 INR 0.00 INR 0.00

6. INR 0.00 INR 0.00 INR 0.00

7. INR 0.00 INR 0.00 INR 0.00

8. INR 0.00 INR 0.00 INR 0.00

9. INR 0.00 INR 0.00 INR 0.00

10. INR 0.00 INR 0.00 INR 0.00

11. INR 0.00 INR 0.00 INR 0.00

12. INR 0.00 INR 0.00 INR 0.00

Total Cost for Application Support & Maintenance


89 | P a g e

Form 2.12: Commercial Formant for Technical Support Staff at SDC & District Level

Sl No. Item Unit Price (P) Tax (t) Total Amount T=(P+t) Total Qty (Q) Total amount

T*Q

1. Technical Support Staff INR 0.00 INR 0.00 INR 0.00 28 INR 0.00

2. Database Administrator

at SDC

INR 0.00 INR 0.00 INR 0.00 2 INR 0.00

3. System Administrator at

SDC

INR 0.00 INR 0.00 INR 0.00 2 INR 0.00

4. Resource Person for

Centralized Helpdesk

INR 0.00 INR 0.00 INR 0.00 2 INR 0.00

Total Cost for Technical Support Staff & Help Desk Resources


90 | P a g e

Form 2.13: Other Cost Commercial Format

A B D

Other Items Cost/Item Tax (If any) Total Cost (A+B)xC

Other Item INR0.00 INR 0.00

Total Cost for other Item INR 0.00


91 | P a g e

ANNEXURE III: TEMPLATE FOR PBG & CCN

Form 1: Performance Bank Guarantee

PERFORMANCE SECURITY:

<Name> <Designation> <Address> <Phone Nos.> <Fax Nos.>

<email id>

Whereas, <name of the supplier and address> (hereinafter called “the bidder”) has undertaken, in

pursuance of contract no. <Insert Contract No.> dated. <Date> to provide Implementation services

for <name of the assignment> to OCAC (hereinafter called “the beneficiary”)

And whereas it has been stipulated by in the said contract that the bidder shall furnish you with a

bank guarantee by a recognized bank for the sum specified therein as security for compliance with

its obligations in accordance with the contract;

And whereas we, <Name of Bank> a banking company incorporated and having its head

/registered office at <Address of Registered Office> and having one of its office at <Address of Local

Office> have agreed to give the supplier such a bank guarantee.

Now, therefore, we hereby affirm that we are guarantors and responsible to you, on behalf of the

supplier, up to a total of Rs.<Insert Value> (Rupees <Insert Value in Words> only) and we

undertake to pay you, upon your first written demand declaring the supplier to be in default under

the contract and without cavil or argument, any sum or sums within the limits of Rs. <Insert

Value> (Rupees <Insert Value in Words> only) as aforesaid, without your needing to prove or to

show grounds or reasons for your demand or the sum specified therein.

We hereby waive the necessity of your demanding the said debt from the bidder before presenting

us with the demand.

We further agree that no change or addition to or other modification of the terms of the contract to

be performed there under or of any of the contract documents which may be made between you

and the Bidder shall in any way release us from any liability under this guarantee and we hereby

waive notice of any such change, addition or modification.


92 | P a g e

This Guarantee shall be valid until <Insert Date>)

Notwithstanding anything contained herein:

I. Our liability under this bank guarantee shall not exceed Rs. <Insert Value> (Rupees <Insert

Value in Words> only).

II. This bank guarantee shall be valid up to <Insert Expiry Date>)

III. It is condition of our liability for payment of the guaranteed amount or any part thereof

arising under this bank guarantee that we receive a valid written claim or demand for

payment under this bank guarantee on or before <Insert Expiry Date>) failing which our

liability under the guarantee will automatically cease.


93 | P a g e

Form 2: Change Control Notice (CCN) Format

Change Control Note CCN Number:

Part A: Initiation

Title:

Originator:

Sponsor:

Date of Initiation:

Details of Proposed Change

(To include reason for change and appropriate details/specifications. Identify any attachments

as A1, A2, and A3 etc.)

Authorized by : Date:

Name:

Signature:

Received by the IP

Date:

Name:

Signature:

Change Control Note

CCN Number:

Part B : Evaluation

(Identify any attachments as B1, B2, and B3 etc.)

Changes to Services, charging structure, payment profile, documentation, training, service

levels and component working arrangements and any other contractual issue.

Brief Description of Solution:

Impact:


94 | P a g e

Deliverables:

Timetable:

Charges for Implementation:

(including a schedule of payments)

Other Relevant Information:

(including value-added and acceptance criteria)

Authorized by the

Implementation Partner

Date:

Name:

Signature:


95 | P a g e

ANNEXURE IV: Definition of Go-Live

Go-Live of e-District Project in a District as fulfilment of all the following four conditions

1) Go-Live of all services as mentioned in the RFP would imply there would be at least following

number of transactions per month for a period of 3 consecutive months for all services based on

the Population of the District as following:

a) Districts with population < 5 Lakhs atleast 10 transactions per month for each service

b) Districts with population > 5 Lakhs but < 10 lakhs atleast 20 transactions per month for

each service.

c) Districts with population > 10 Lakhs atleast 30 transactions per month for each service.

2) Among the services listed, at least 10 services should attain high volume of transactions for

three consecutive months in that district. High volume of transactions are defined as:

a) Districts with population < 5 Lakhs - High Volume services would be those defined as at

least 50 transactions per month per service for the entire district

b) Districts with population < 10 Lakhs but > 5 Lakhs High Volume services would be those

defined as at least 100 transactions per month per service for the entire district

c) Districts with population > 10 Lakhs High Volume services would be those defined as at

least 150 transactions per month per service for the entire district

3) At least three of the “High Volume Services” as defined above in S No. (2) Should be amenable to

delivery across the counter.

4) The aggregate transactions for all services (including High Volume services) made live, reach

the following levels for at least three consecutive months in that district

a) Districts with population < 5 Lakhs – at least 750 transactions per month for the entire

district

b) Districts with population < 10 Lakhs but > 5 Lakhs - at least 1500 transactions per

month for the entire district

c) Districts with population > 10 Lakhs - at least 2500 transactions per month for the

entire district

Note: Transaction would be defined a complete service being delivered to the Citizen which may

include submission of an application by the citizen, back end processing and service delivery. Across

the Counter service delivery will also count as a transaction.


96 | P a g e

ANNEXURE V: Resources Eligibility Criteria

Resource Type Minimum Educational

Qualification

Minimum Years

of Experience

Desired

Certification

Project Manager BE/MCA/B.Tech 8+ PMP/Prince2

Database Administrator BE/MCA/ B.Tech 5+

System Administrator BE/MCA/ B.Tech 5+

Technical Support Staff BE / B. Tech / MCA or must

be a Graduate (In

IT/Computer Stream) with

minimum 50% marks in

whole academic career. (10th,

10+2 & Graduation). Having 2

Years of Experience.

5+

Help Desk Support Any Graduation with IT

Knowledge and Good

Communication Skill in Odia

& English

4+

RFP for Selection of System Integrator for Rollout of e-district MMP – Volume II

REQUEST FOR PROPOSAL FOR

SELECTION OF SYSTEM INTEGRATOR FOR STATE WIDE ROLLOUT

OF e-DISTRICT MMP

VOLUME II

RFP No: OCAC-TJ-11/2012/ENQ/13015 Dated: 24.06.2013

General Manager,

Odisha Computer Application Centre (OCAC), (Technical Directorate under IT Department, Govt. of Odisha), OCAC Building, Plot No. N-

1/7D, Acharya Vihar Square, RRL Post Office, Bhubaneswar – 751 013, Odisha

Website: http://www.ocac.in/

http://www.ocac.in/


2 | P a g e

Table of Content

1 IMPLEMENTATION FRAMEWORK .................................................................................................... 6

2 SCOPE OF THE PROJECT .................................................................................................................... 9

2.1 INTRODUCTION ...................................................................................................................................... 9 2.2 SOLUTION & TECHNOLOGY ARCHITECTURE .............................................................................................. 9 2.2.1 Overview ..................................................................................................................................... 9 2.2.2 eDistrict Application Structure ................................................................................................. 10

2.3 SCOPE OF SERVICES – PROJECT IMPLEMENTATION PHASE ........................................................................ 11 2.3.1 Solution Design ......................................................................................................................... 12

2.3.1.1 System Study and Design ...................................................................................................................... 12 2.3.1.2 Preparation of Software Requirements Specifications (SRS) ................................................................. 13 2.3.1.3 Preparation of e-District Project Plan .................................................................................................... 14 2.3.1.4 Preparation of e-District Application Design Documents ...................................................................... 14 2.3.1.5 Sign off Deliverables ............................................................................................................................. 14

2.3.2 Software Development/Customization .................................................................................... 15 2.3.2.1 E-District Application ............................................................................................................................. 15 2.3.2.2 List of Services (e-District Functional Modules) ................................................................................... 15 2.3.2.3 Single-Sign On ...................................................................................................................................... 20 2.3.2.4 Support for PKI based Authentication and Authorization .................................................................... 20 2.3.2.5 Interoperability Standards .................................................................................................................... 20 2.3.3.6 Scalability ............................................................................................................................................. 20 2.3.2.7 Security ................................................................................................................................................ 21 2.3.2.8 Application Architecture ...................................................................................................................... 21 2.3.2.9 Proposed Application Architecture ...................................................................................................... 22 2.3.2.10 High Level Design (HLD) .................................................................................................................... 22 2.3.2.11 Detailed (Low Level) Design (LLD) ..................................................................................................... 22 2.3.2.12 Test Plan ............................................................................................................................................ 23 2.3.2.13 Requirement on Adherence to Standards ........................................................................................ 23 2.3.2.14 Compliance with Industry Standards ................................................................................................ 23 2.3.2.15 Specification ..................................................................................................................................... 23 2.3.2.16 Sign-off Deliverables ......................................................................................................................... 24

2.3.3 Obtain STQC Certification for eDistrict Application ................................................................ 24 2.3.3.1 Sign-off Deliverables ............................................................................................................................. 25

2.3.4 Alignment with Integrated Framework ................................................................................... 25 2.3.5 SSDG .......................................................................................................................................... 25 2.3.6 Payment and SMS Gateway ...................................................................................................... 26 2.3.7 UAT and Go-Live Report ........................................................................................................... 27

2.3.7.1 Sign-off Deliverables ............................................................................................................................. 27 2.3.8 Network Connectivity ............................................................................................................... 27

2.3.8.1 Sign-off Deliverables ............................................................................................................................. 27 2.3.9 Supply / Procurement of IT Infrastructure at SDC .................................................................. 28 2.3.10 Hardware Commissioning at Field Offices ............................................................................... 28

2.3.10.1 Design, Supply, Installation, Commissioning, O & M of IT Infrastructure ......................................... 28 2.3.10.2 Installation and Commissioning of IT Infrastructure ......................................................................... 29

2.3.11 Licenses ..................................................................................................................................... 29 2.3.12 Capacity Building / Training.................................................................................................... 29

2.3.12.1 Sign off Deliverables ................................................................................................................................. 30 2.3.13 Manpower requirements .......................................................................................................... 31 2.3.14 Business Continuity Planning ................................................................................................... 32 2.3.15 Others ........................................................................................................................................ 33

2.3.15.1 Information Security Management ........................................................................................................... 33 2.3.16 Project Management ................................................................................................................ 37

2.3.16.1 Project Planning and Management .......................................................................................................... 37 2.3.16.2 Project Planning and Management .......................................................................................................... 38

2.4 SCOPE OF SERVICES - OPERATION AND MAINTENANCE PHASE .................................................................. 39 2.4.1 OVERVIEW OF POST IMPLEMENTATION SERVICES ................................................................................ 39 2.4.2 WARRANTY SUPPORT ....................................................................................................................... 40 2.4.3 ANNUAL TECHNICAL SUPPORT .......................................................................................................... 41


3 | P a g e

2.4.4 HELP DESK AND TROUBLE TICKET MANAGEMENT SYSTEM .................................................................... 42 2.4.5 GENERAL REQUIREMENTS ................................................................................................................. 43 2.4.6 EXIT MANAGEMENT ......................................................................................................................... 44

2.4.6.1 Purpose ................................................................................................................................................ 44 2.4.6.2 Transfer of Assets .................................................................................................................................. 44 2.4.6.3 Cooperation and Provision of Information ........................................................................................... 45 2.4.6.4 Confidential Information, Security and Data ......................................................................................... 45 2.4.6.5 Employees ............................................................................................................................................. 46 2.4.6.6 Transfer of Certain Agreements ............................................................................................................ 46 2.4.6.7 Rights of Access to Premises ................................................................................................................. 46 2.4.6.8 General Obligations of the SI................................................................................................................. 47 2.4.6.9 Exit Management Plan .......................................................................................................................... 47

3 DETAILED IMPLEMENTATION AND ROLL-OUT PLAN ................................................................... 49

4 ANNEXURES: ..................................................................................................................................... 50

4.1 OFFICE WISE REQUIREMENTS ............................................................................................................... 50 4.2 TEMPLATE FOR CAPTURING NETWORK CONNECTIVITY REQUIREMENT ...................................................... 52 4.3 FRS FOR THE PROPOSED APPLICATION .................................................................................................. 54

4.3.1 Information Dissemination Component .................................................................................. 55 4.3.2 Forms Availability Component ................................................................................................. 57 4.3.3 Application Receipt Component ............................................................................................... 59 4.3.4 Payment Component ................................................................................................................ 60 4.3.5 Application Processing Component ......................................................................................... 62 4.3.6 Verification Component ............................................................................................................ 63 4.3.7 Approval/Rejection Component (Intermediary Approver and Final Approver) .................... 64 4.3.8 Delivery Component ................................................................................................................. 66 4.3.9 Status Component ..................................................................................................................... 68 4.3.10 Monitoring Component (MIS) ....................................................................................................... 70 4.3.11 Log in Component .......................................................................................................................... 72 4.3.12 Service Specific Functionalities ..................................................................................................... 73

4.4 BILL OF MATERIAL SUMMARY ............................................................................................................... 76 4.4.1 Requirement at Field Level Offices ........................................................................................... 76 4.4.2 Requirement at SDC ................................................................................................................. 77

4.5 TECHNICAL SPECIFICATIONS ................................................................................................................. 78 4.5.1 Server for Web, Database, Application .................................................................................... 78 4.5.2 Specification for servers for Helpdesk, SLA and Antivirus ....................................................... 79

4.5.2.1 Specification of Blade chasis ................................................................................................................ 79 4.5.2.2 Specification of Servers ........................................................................................................................ 80

4.5.2 Desktop ..................................................................................................................................... 81 4.5.3 Laptops ..................................................................................................................................... 82 4.5.4 Scanner ..................................................................................................................................... 83 4.5.5 Laser Jet Printer, Scanner, Copier all in one Device ................................................................. 84 4.5.6 Laser Printers ........................................................................................................................... 86 4.5.7 UPS – 1 KVA offline UPS ........................................................................................................... 87 4.5.8 9 U Rack .................................................................................................................................... 89 4.5.9 Biometric Device ....................................................................................................................... 90 4.5.10 24 Port Managed LAN Switch ....................................................................................................... 91 4.5.11 Specification of SLA and Helpdesk Software ................................................................................. 93 4.5.12 Specification of Antivirus software ............................................................................................... 96

4.6 NON-FUNCTIONAL REQUIREMENTS ..................................................................................................... 100 4.7 CSC ROLLOUT STATUS ........................................................................................................................ 106


4 | P a g e

GLOSSARY OF TERMS

The definitions of various terms that have been used in this RFP are as follows:

“Request for Proposal (RFP)” means all three Volumes and its annexures and any other documents provided along with this RFP or issued during the course of the selection of bidder, seeking a set of solution(s), services(s), materials and/or any combination of them.

“Contract / Agreement / Contract Agreement / Master Service Agreement” means the Agreement to be signed between the successful bidder and OCAC, including all attachments, appendices, all documents incorporated by reference thereto together with any subsequent modifications, the RFP, the bid offer, the acceptance and all related correspondences, clarifications, presentations.

“Bidder” means any firm offering the solution(s), service(s) and /or materials as required in the RFP. The word Bidder when used in the pre-award period shall be synonymous with parties bidding against this RFP, and when used after award of the Contract shall mean the successful party with whom the agreement is signed for rendering of services for implementation of this project.

“Proposal / Bid” means the Pre-Qualification, Technical and Commercial bids submitted for this project against this RFP.

“Acceptance” means the Government’s written certification that following installation, the system(s) (or specific part thereof) has been tested and verified as complete and/or fully operational, in accordance with the acceptance test defined in the Acceptance Test Documents.

“Acceptance Test Documents” means a mutually agreed document which defines procedures for testing the functioning of the e-District system, against requirements laid down in the agreement. It should define tests to be carried out, test equipments and expected test results.

“Authorized Representative” shall mean any person/agency authorized by either of the parties.

“Contract” is used synonymously with agreement.

“Documentary evidence” means any matter expressed or described upon any substance by means of letters, figures or marks intended to be used for the recording of that matter and produced before a court.

“GoI” shall mean Government of India

“Gov./GoO/Government/Govt. of Odisha” shall mean Government of Odisha.

“Law” shall mean any Act ,notification, bye law ,rules and regulations, directive, ordinance, order or instruction having the force of law enacted or issued by the Government of India or State Government or regulatory authority or political sub-division of government agency.

“LOI” means issuing of Letter of Intent which shall constitute the intention of the Tenderer to place the purchase order with the successful bidder.


5 | P a g e

“OCAC” stands for the Odisha Computer Application Centre, a Society registered under the

Societies Registration Act 1962, having its registered office at OCAC Building, Plot No. N-1/7-D, Acharya Vihar Square, RRL Post, Bhubaneswar, PIN. 751 013 (Technical Directorate of I.T. Department, Govt. of Odisha. The term includes its successors and assigns thereof. OCAC acts as the State Designated Agency for the project.

“OEM” means Original Equipment Manufacturer company, that is incorporated in India or abroad, who has management control over the manufacturing/production process, Quality Assurance, Procurement of Raw materials/manufacturing process inputs marketing and warranty services of the resultant products, of at least one manufacturing facility /factory where the manufacturing of equipment, related accessories, as required for the e- District, Odisha etc. is carried out.

“Party” shall mean Govt. or Bidder individually and “Parties” shall mean Govt. and Bidder collectively.

“PBC” means Pre-Bid Conference

“Rates/Prices” means prices of supply of equipment and services quoted by the Bidder in the Commercial Bid submitted by him and/or mentioned in the Contract

“RFP” means the detailed notification seeking a set of solution(s) ,service(s), materials and/or any combination of them

“Services” means the work to be performed by the Bidder pursuant to this Contract, as detailed in the Scope of Work

“Site” shall mean the location(s) for which the Contract has been issued and where the service shall be provided as per Agreement

“Tenderer” shall mean the authority issuing this Request For Proposal (RFP) and the authority under whom the e-District, Odisha is to be implemented, operated, managed etc. and this authority shall be the Odisha Computer Application Centre, acting on behalf of Govt. of Odisha as the implementing agency for the ‘e-District, Odisha project.

“Termination notice” means the written notice of termination of the Agreement issued by one party to the other in terms hereof.


6 | P a g e

1 Implementation Framework

I. e-District project shall be implemented in a way where the districts will play a major

role. e-District shall be implemented in alignment with the NeGP principle of

“centralized planning and decentralized implementation”. State IT Department/ Nodal

Agency shall play a key role in planning and implementation of the program in

collaboration with the district.

II. The role of the DeitY, GoI focuses primarily in planning of national level roll out, issuing

guidelines, funding support to the states, monitor and support the state in

implementation of the project. States shall drive the implementation at the state/district

level. The diagram illustrating the key stakeholders and their role in implementation and

for managing the eDistrict MMP is shown below:

III. An Integrated Service Delivery Framework has been designed by DeitY in July 2012,

and communicated to all the States. It can be accessed at (URL:

http://deity.gov.in/content/e-district-guidelines). This framework envisages a

centralized architecture for each major e-Governance application at the State level. The

application software will be hosted in the State Data Centre. Integration across States

shall be enabled, through mandatory adherence to technical specifications and e-

Governance standards, besides use of the SSDG. Compliance to latest Unicode standard

(current version is 6.0) for local language content/data encoding is also mandatory. The

Integrated Framework shall be treated as part of this RFP and shall be followed with

appropriate modifications.

http://deity.gov.in/content/e-district-guidelines


7 | P a g e

IV. Two key aspects of the Scheme are Business Process Re-engineering (BPR) and

creation of databases based on e-Governance standards for the purposes of ensuring

interoperability. BPR is intended to enable process simplification and significant value

addition to citizens.

V. The solution architecture of the e-District project envisages a centralised application

and database and will leverage the core e-infrastructure of State Wide Area Network,

State Data Centre and State Service Delivery Gateway.

VI. Further e-District service will be integrated with a mobile service delivery gateway and

Aadhaar numbers of the Unique Identification Authority of India. Localisation of the

application will be carried out as per the requirement of the state in terms of local

language and other needs. According to this, System Integrator (SI) who shall be

responsible to implement the project in the state as per the DeitY, GoI guidelines.

Integration of existing applications being used in the state shall not be possible unless

the legacy data in the local language is compliant to Unicode version 6.0 or above. In

some cases, this legacy data therefore will need to be converted to Unicode 6.0 (or latest

version).

VII. The e-District MMP envisages centralised architecture at the state level with common

application software for each of the identified services for all the districts of the state.

The application software will be hosted in the SDC.


8 | P a g e

VIII. Integration across states shall be enabled, through mandatory adherence to technical

specifications and eGovernance and localization standards. The detailed guidelines in

this regard have been issued by Department of Electronics and Information Technology

(DeitY) Government of India.


9 | P a g e

2 Scope of the Project

2.1 Introduction

I. The e-District MMP is to be implemented in 28 districts of the Odisha. The

implementation of the project will be completed in ONE year commencing from the

date of award to the SI and will be followed by 3 years of Operation and Maintenance

(O&M) phase

II. The implementation in the state of Odisha is proposed to be carried out in twenty eight

districts simultaneously. The following will be the activities to be carried out by the

selected Bidder:

a. Project Planning and Management

b. System Study and Preparation of SRS Document

c. Business Process Reengineering for the selected applications/ services

d. Development of eDistrict Application

e. Network Connectivity

f. Hardware Procurement & Commissioning

g. STQC Certification and C-DAC/TDIL Certification (for localization)

h. UAT & Go live

i. Capacity Building

j. Operation & Maintenance (O&M) support

III. List of districts and CSC roll out status is enclosed at section 4.7-

2.2 Solution & Technology Architecture

2.2.1 Overview

I. A centralized architecture (servers and processing at single and central location) has

been proposed for the e-District project. All requests from internal and external users

will be sent to this system, located in a central place for processing. All users will access

the application through local or remote terminals using a browser.

II. The overall technology solution shall be based upon most relevant and suitable

architecture standards including standards for Service Oriented Architecture (SOA), XML

services & necessary protocols for internet applications, Data Centre standards,

Localization (Unicode, Inscript, etc.) standards, W3C (WCAG for accessibility, etc.)

standards & GIGW guidelines, etc

III. The design should include integration with existing IT infrastructure created under SDC,

SWAN, CSC, State Portal, SSDG and any other MMP for the implementation of eDistrict

Project. eDistrict Application developed should be integrated with existing State Portals

and Gateways.


10 | P a g e

IV. As in the State of Odisha, State Portal / SSDG is under development, the eDistrict

architecture should be compatible with it and should get integrated when the SSDG is

operational.

2.2.2 eDistrict Application Structure

At present the eDistrict application will host the data of all services in its own database. Once

independent applications are rolled out for any service which is part of eDistrict application

then the data of that service should be migrated to that new application’s database.

However, eventually, the eDistrict application should also integrate with SSDG and provide

access to citizens for eDistrict services through State Portal. All the existing state applications

which have their own independent database and workflow and are identical to e-District should

be made available on State Portal through the SSDG. The envisaged architecture is depicted in

following diagram.


11 | P a g e

2.3 Scope of Services – Project Implementation Phase

The Government of Odisha had chosen two districts for the pilot implementation of the e-

District project. The Pilot implementation has been successfully completed in the following pilot

districts.

a. Ganjam

b. Mayurbhanj

The existing eDistrict Application developed for the pilot shall be used for State Wide Rollout for

faster replication. Application Software developed for the pilot implementation has been tested

by STQC. The bidder needs to upgrade/enhance the existing application while accommodating

the new services. It will be the responsibility of the bidder to get the STQC certification for the

entire application prior to Go-Live for the application.


12 | P a g e

2.3.1 Solution Design

2.3.1.1 System Study and Design

I. 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 DeitY, GoI and the State nodal Agency requirements.

II. The SI should prepare a detailed document on the implementation of e-District

Application with respect to configuration, customization, extension and integration.

The SI shall also prepare a change/reference document based on changes or deviations

from the base version of the e-District Application with appropriate references to all

the artifacts /documents provided by DeitY, GoI / State Nodal Agency.

III. 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 state Odisha

IV. The selected Bidder shall perform the detailed assessment of the functional

requirements (Including localization framework) and MIS requirements and prepare a

new FRS report, 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 OCAC.

V. Further as the existing application will be customized/configured to meet the needs of

the state, the SI will provide a comparative report as part of System Study document, on

the extent of functionality currently available in the pilot application and the final FRS.

A. Requirements Traceability Matrix: The SI shall ensure that developed e-

District 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), Non Functional Requirements Specification, and Technical Requirements

provided by State (updated, expanded and fine-tuned by the SI). Refer to section

4.6 for more details on the non-functional requirements.

B. Project Documentation: The SI shall create and maintain all project

documents that shall be passed on to OCAC as deliverables as per the agreed

project timelines. The documents created by the SI will be reviewed and

approved by the State Nodal Agency on advice of SPMU. Project documents

include but are not limited to the following:


13 | P a g e

i. Detailed Project Plan

a. Detailed System Study Report

b. List of services, Service Definitions, Service Levels

c. Updated/vetted FRS

d. SRS document

e. HLD documents

ii. E-District Application architecture documents.

iii. ER diagrams and other data modelling documents.

iv. Logical and physical database design.

v. Data dictionary and data definitions.

vi. Application component design including component deployment views,

control flows, etc.

a. LLD documents

vii. Application flows and logic.

viii. GUI design (screen design, navigation, etc.).

a. All Test Plans

ix. Requirements Traceability Matrix

x. Change Management and Capacity Building Plans.

xi. SLA and Performance Monitoring Plan.

xii. Design of real time tools for monitoring e-Transaction volumes and for

generating real time MIS

xiii. Training and Knowledge Transfer Plans.

xiv. Issue Logs.

The SI shall share 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 OCAC 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 State Nodal Officer on regular basis.

2.3.1.2 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 as per IEEE or equivalent standards

which meets all the Business, Functional and Technical (including localization) requirements of

the departments concerned. Concerned Departments feedback should be taken into account

before finalizing the SRS. The SI shall prepare the SRS documents and have it reviewed and

approved by the State Designated Agency or its nominated agency. State Designated Agency


14 | P a g e

will sign off on the SRS documents on the advice of SPMU. 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.

2.3.1.3 Preparation of e-District Project Plan

The SI shall prepare a comprehensive e-District implementation and deployment plan in

consultation with OCAC. This document shall also comprise of

I. Trainings to be provided to the departmental officials at different stages of the project,

procurement

II. Deployment and commissioning of required hardware and software

III. Provisioning of network connectivity etc

Further, SI will also prepare detailed work plan and estimate the timelines and resources

required for configuration, customization, extension, integration, and commissioning of the e-

District software as per the DeitY GoI / State requirements. All the plans and frameworks

prepared by SI during the duration of the contract shall be required to seek approval from

OCAC.

2.3.1.4 Preparation of e-District Application Design Documents

Detailed Design documents shall include:

I. Technical Architecture Document (Application, Network, and Security)

II. The available IT infrastructure available at state shall be a part of the document.

III. Gap infrastructure

IV. High Level and Low Level Design.

V. 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 DeitY, GoI/ Government of Odisha.

2.3.1.5 Sign off Deliverables

I. Detailed Project Plan

II. Detailed System Study Report

III. List of Services, Service Definitions, Service Levels

IV. Updated/vetted FRS

V. SRS document

VI. HLD documents

VII. E-District Application architecture documents.

VIII. ER diagrams and other data modelling documents.

IX. Logical and physical database design.

X. Data dictionary and data definitions.


15 | P a g e

XI. Application component design including component deployment views, control flows,

etc.

A. LLD documents (including but not limited to)

i. Application flows and logic.

ii. GUI design (screen design, navigation, etc.).

B. All Test Plans

i. Requirements Traceability Matrix

ii. Change Management and Capacity Building Plans.

iii. Design of realtime tools for monitoring e-Transaction volumes and for

generating realtime MIS

iv. SLA and Performance Monitoring Plan.

v. Training and Knowledge Transfer Plans.

vi. Issue Logs.

2.3.2 Software Development/Customization

2.3.2.1 E-District Application

The existing eDistrict Application developed for the pilot shall be used for State Wide Rollout for

faster replication. Application Software developed for the pilot implementation has been tested

by STQC. The bidder needs to upgrade/enhance the existing application while accommodating

the new services. It will be the responsibility of the bidder to get the STQC certification for the

entire application prior to Go-Live for the application. The bidder would be provided with

required documents related to the existing application, if the bidder needs some more

information related to existing application then they need to inform the department during

pre-bid queries.“

2.3.2.2 List of Services (e-District Functional Modules)

e-District MMP aims at electronic delivery of all public services at district / sub district level,

progressively. Initially 10 categories (5 mandatory + 5 state specific) of identified high volume

citizen centric public services at district and sub-district level will be taken up for

implementation. While doing so, the four pillars of e-infrastructure i.e. SWANs, SDCs, SSDGs and

CSCs will be leveraged and no new infrastructure would be created. Later on, new services

could be added depending on the requirements and the felt needs. Following table depicts the list

of services that are proposed to be implemented during State Wide Rollout of eDistrict.

The SI needs to use the existing e-District Application, FRS and SRS that may be updated as per

the State’s requirement for state wide roll out of eDistrict.


16 | P a g e

LIST OF SERVICES FOR STATEWIDE ROLLOUT of eDistrict MMP

Sl. # Service Categories

Sub – Services

1 Certificates

1. Issuance of Birth Certificate (Above 1 Year Case)

2. Issuance of Death Certificate ( Above 1 Year Case)

3. Issuance of Disability Certificate

2 Social Security

4. Sanction of Assistance under NFBS

5. Sanction of Indira Gandhi National Old Age Pension Scheme

6. Sanction of Indira Gandhi National Disability Pension Scheme

7. Sanction of Indira Gandhi National Widow Pension Scheme

8. Sanction of Funds under MBPY

3 Revenue Court & Cases

9. Registration of Societies

10. Certified Copies of RoR

11. Conversion of Land Under OLR-8 (A)

12. Certified copies of other Documents

4 Public Distribution System(PDS)

13. Mutation of Ration Cards (Addition/Deletion of Names)

14. Issue of Fresh/Duplicate ration card

15. Change of FPS/Dealer

5 RTI/Grievances 16. Online Grievance Registration to Collector

6 Health 17. Application for Registered Medical Practitioner Certificate

7 ST & SC Development

18. Application for Study Loan for ST/SC students

19. Scholarship for ST/SC students

8 School & Mass Education Department

20. Issue of Conduct certificate

21. Application for scholarship for students under S&ME Dept.

9 Higher Education Department

22. Application for Scholarship services for students under Higher Education Dept

10 Employment 23. Application for registration to Employment Exchange.

P.S: List of services mentioned here are indicative. There might be addition/deletion of services at a later

stage subject to the decision taken by the Government.

The application for e-District is the most critical component for e-District project. Following

things need to be taken into consideration while developing the application.


17 | P a g e

I. The design and development of the eDistrict Application as per the FRS and SRS

finalized by all stakeholders (SDA, State DIT, SPMU, etc).

II. eDistrict Application should ensure availability of all services, in accordance with the

BPR. System Integrator should focus on the following things while

developing/customizing the application for State Wide Rollout of eDistrict.

a) As State portal is not operational, front end should be designed with migration

strategy to State portal after operationalization of State portal.

b) Back end for the printing, status update and centralized MIS application.

c) Providing automatic acknowledgement with automated date and time

stamping.

d) Enabling tracking of the status of the application from any authorized office

through a unique application ID

III. Development of Role based, workflow driven Web based Content Management System

(CMS) for contribution of any type of Content to the eDistrict Application including the

metadata as specified in SRS.

IV. The user should be given a choice to interact with the system in local language in

addition to English. The application should provision for uniform user experience

across the multi lingual functionality covering following aspects:

a) Front end web portal in local language

b) E-forms (Labels & Data entry in local languages). Data entry should be provided

preferably using the Enhanced Inscript standard (based on Unicode version 6.0

or later) keyboard layout with option for floating keyboard.

c) Storage of entered data in local language using UNICODE (version 6.0 or later)

encoding standard.

d) Retrieval & display in local language across all user interfaces, forms and

reports with all browsers compliant with Unicode version 6.0 and above.

e) Facility for bilingual printing (English and the local language)

f) Sakal Bharti font (compliant to UNICODE version 6.0) to be used for local

language data and content. Latest version of the font is available on www.ildc.in

V. Application should have a generic workflow engine. This generic workflow engine will

allow easy creation of workflow for new services with minimum technical

programming support and thus enable the State government to create new services as

and when required by the various Departments without creating a change request. At

the minimum, the workflow engine should have the following features:

a) Feature to use the master data for the auto-populating the forms and

dropdowns specifically with reference to :

i. Name of District, Tehsils, Blocks & Villages

ii. Designation of officials involved in the processing of the application

b) Creation of application form, by “drag & drop” feature using meta data standards


18 | P a g e

c) Defining the workflow for the approval of the form, by providing various

options like :

i. First in First out

ii. Defining a citizen charter/delivery of service in a time bound manner

d) Creation of the “output” of the service, i.e. Certificate, Order etc.

e) Automatic reports

i. of compliance to citizen charter on delivery of services

ii. delay reports

f) The application should have a module for management of digital signature

including issuance, renewal and suspension of digital signatures based on the

administrative decisions taken by the State. In case of any change (transfer,

promotion, leave, suspension, termination, superannuation etc.) of the officials

under e-District Project, a copy of order should be marked to the State Level

digital signature management team for assigning and revoking of the access

rights.

VI. Integration of Digital Signatures with e-District Application: The eDistrict portal

should be made accessible to government official users / registered users over internet

and to CSC users through secure user id and password. The biometric/digital

signatures need to be integrated for enabling authenticity of the approving authority.

VII. Training on use of Digital Signatures: As the eDistrict project would entail significant

amount of field verification and relevant updating of records, digital signatures have to

be used by various levels of officials. These officials may also keep on changing due to

transfers/ superannuation, etc. Hence, SI would be required to impart training on the

use of Digital Signature to the concerned officials.

VIII. Transaction Report & accounting module: The e-District services are being provided

through the CSCs in the State. The payments to the CSCs are being made to the CSC

Operatos on the number of transactions made by the CSCs. The CSCs are aligned to

various organizations (SCAs). For e-District project to succeed it is important to ensure

that there is a streamlined method to calculate the fee payable to the CSC operator.

Therefore, a separate module for calculation of such fee and payments should be

developed.

IX. e-Transaction & SLA Monitoring Tools :

The SLA Performance of Server Hardware, Application, Database and Network devices

will be monitored by the existing EMS tool of the Odisha State Data Center. However

bidder has to propose additional licenses of EMS tool of the Odisha State Data Center for

helpdesk call management and SLA management of desktops, printers etc

X. It is also further envisaged that the e-District application to be deployed in all States and

UTs should have roadmap to integrate with key initiatives of DeitY namely Portal

Services, Citizen Contact Centre, Mobile Platform/ Gateway Services / National Service


19 | P a g e

Delivery Gateway (NSDG) / State Service Delivery Gateway (SSDG), National Service

Directory, Payment Gateway, Language Switch, Open Data, E-authentication including

Aadhaar, Geographical Information System/ Global Positioning System, E-Gov

Application Store, Document Repository, Certifying Authority etc. The details for

integration with other initiatives are given below. Hence the architecture of eDistrict

Application should be open standard and designed in such a way that there will not be

any problem during the integration. Contact details for integration with other initiatives

are given below.

Name of the initiative

Purpose for integration Contact Agency

Agency Person details

Deity Nodal Person Details

SSDG Integration with existing application

CDAC Mr. Zia Saquib, Executive Director, CDAC, Mumbai. Telephone:+91-22-26201606

Ms. Kavita Bhatia, Additional Director, DeitY. Telephone: +91-11-24364729

Payment Gateway

e-payment NDML Mr. Sameer Gupte, Vice-President, NDML. Telephone: +91-9820039921


MSDG Services over mobile phone



e-Authentication

Validation of beneficiary- using biometric



AADHAR Applicant authentication UIDAI Mr. Tejpal Singh, ADG, UIDAI, New Delhi. Telephone: +91-11-23462611

Mr. Gaurav Dwivedi, Director, DeitY. Telephone:+91-11-24301218

Localisation Localisation of the application as per the requirement of the State in terms of local language and other needs.

CDAC Mr. Mahesh Kulkarni, Associate Director, CDAC, Pune. Telephone: +91-20-25883261/25503402

Ms. Swaran Lata, Director, DeitY. Telephone: +91-11-24301272

XI. Complete mobile enablement of the e-District applications and services including all

appropriate channels such as SMS / USSD / IVRS and development of corresponding

mobile applications to the eDistrict applications and services leveraging the Mobile

Service Delivery Gateway (MSDG) and the Mobile App Store developed by DeitY

XII. Operation and Maintenance of eDistrict Application including the suggested changes

as indicated by the states for 3 years from the date of Go-Live


20 | P a g e

XIII. Implement / add any additional forms of State Departments as and when the depart-

ments are ready for delivering.

XIV. The Intellectual Property Rights of all the software code, data, algorithms, documenta-

tion, manuals, etc. generated as a part of implementation of this project shall solely

vest with OCAC.

XV. Detailed User and Operational Manual to be provided to each department, whose ser-

vices will be hosted on eDistrict Application.

XVI. The application should have a web interface and should publish online transaction

volume data for each service for each district & CSC.

2.3.2.3 Single-Sign On

The application should enable single-sign-on so that any user once authenticated and

authorized by system is not required to be re-authorized for completing any of the services in

the same session. For employees of the department concerned, the browser based application

accessed on the intranet, through single-sign-on mechanism, will provide access to all the

services of the departments concerned (based on their roles and responsibilities), Help module,

basic and advanced reporting etc. Similarly, for external users (citizens, etc), based on their

profile and registration, the system should enable single-sign on facility to apply for various

services, make payments, submit queries /complaints and check status of their applications.

2.3.2.4 Support for PKI based Authentication and Authorization

The solution should support PKI based Authentication and Authorization, in accordance with

IT Act 2000, using the Digital Certificates issued by the Certifying Authorities (CA) such as

MTNL or NIC. In particular, 3 factor authentication (login id & password, biometric and digital

signature) shall be implemented by the selected Bidder for officials/employees involved in

processing citizen services.

2.3.2.5 Interoperability Standards

Keeping in view the evolving needs of interoperability, especially the possibility that the

solution shall become the focal point of delivery of services, and may also involve cross-

functionality with the e-Government projects of other departments / businesses in future, the

solution should be built on Open Standards. The SI shall ensure that the application developed

should easily integrate with the existing applications of other eGovernance initiatives of the

state. Every care shall be taken to ensure that the code does not build a dependency on any

proprietary software, particularly, through the use of proprietary ‘stored procedures’ belonging

to a specific database product.

2.3.3.6 Scalability

One of the fundamental requirements of the proposed application is its scalability. The

architecture should be proven to be scalable (cater to increasing load of internal and external

users and their transactions) and capable of delivering high performance for at-least four years

from the date of deployment. In this context, it is required that the application and deployment


21 | P a g e

architecture should provide for Scale-Up and Scale out on the Application and Web Servers,

Database Servers and all other solution components.

2.3.2.7 Security

The systems implemented for project should be highly secure, considering that it is intended to

handle sensitive data relating to the citizens of the state. The overarching security

considerations are described below.

I. The security services used to protect the solution shall include: Identification,

Authentication, Access Control, Administration and Audit and support for industry

standard protocols.

II. The solution shall support advanced user authentication mechanisms including digital

certificates and biometric authentication.

III. Security design should provide for a well-designed identity management system,

security of physical and digital assets, data and network security, backup and recovery

and disaster recovery system.

IV. The solution should provide for maintaining an audit trail of all the transactions and

should also ensure the non-repudiation of audit trail without impacting the overall

performance of the system.

V. The overarching requirement is the need to comply with ISO 27001 standards of

security.

VI. The application design and development should comply with OWASP top 10 principles

2.3.2.8 Application Architecture

I. It has been proposed that the applications designed and developed for the departments

concerned must follow some best practice and industry standards. In order to achieve

the high level of stability and robustness of the application, the system development life

cycle must be carried out using the industry standard best practices and adopting the

security constraints for access and control rights. The various modules / application

should have a common Exception Manager to handle any kind of exception arising due

to internal/ external factors.

II. Similarly the modules of the application are to be supported by the Session and

Transaction Manager for the completeness of the request and response of the client

request. The system should have a module exclusively to record the activities/ create

the log of activities happening within the system / application to avoid any kind of

irregularities within the system by any User / Application.


22 | P a g e

2.3.2.9 Proposed Application Architecture

A 3-tier architecture (also referred to as multi-tier or N-tier architecture) has been proposed

for the Application Solution. The entire processing should take place in n-tier architecture:

I. Front-end software (client tier): - Existing application is running as a separate portal.

Services which are available under e-District and SSDG, the e-District application

should integrate with the e-form developed under SSDG for that service and use the

standard connectors provided for this purpose by the SSDG project to connect with

the e-District application for end to end integration.

For services under e-District project which are not taken up under SSDG project, the e-form to be developed under e-District project and should use the standard connectors provided for this purpose by the SSDG project to connect with the e-District applica-tion for end to end integration. As SSDG is not operational the Bidder will take necessary action at his end to integrate the application with NSDG.

II. Application and Web Layer – Application server would be used as middle tier for var-

ious web based applications. It would take care of the necessary workflow and Web

server would be required for the interfacing with the end user. Both the web and appli-

cation server would be seamlessly integrated to provide high availability and perfor-

mance. These servers would be installed and operated in clustered configuration to en-

sure high availability and reliability.

III. Database Layer - The application will be hosted on database which will contain all the

data of the application. Since this data will be centralized and is very critical, the server

would be installed and operated in clustered configuration to ensure high availability

and reliability. The data would be physically stored on an External Fiber Channel (FC)

based Storage (SAN).

2.3.2.10 High Level Design (HLD)

SI shall complete the High Level Designing and all HLD documents of all the functionalities,

integration with existing application and external application. The SI shall prepare the HLD

and have it reviewed and approved by the OCAC. State Nodal Office will sign off on the HLD

documents based on the advice of SPMU.

2.3.2.11 Detailed (Low Level) Design (LLD)

The LLD shall interpret the approved HLD to help application development and shall include

detailed service descriptions and specifications, application logic (including “pseudo code”) and

UI design (screen design and navigation). The preparation of test cases will also be completed

during this stage. The SI shall have the design documents reviewed and approved by the state


23 | P a g e

Nodal Agency. State Nodal Agency will sign off on the LLD documents based on the advice of

SPMU.

2.3.2.12 Test Plan

The SI shall prepare all necessary Test Plans (including test cases), i.e., plans for Acceptance

Testing. Test cases for Initial and Final User Acceptance Testing shall be developed in

collaboration with domain experts identified at the state nodal agency. Initial and Final User

Acceptance Testing shall involve Test Case development, Unit Testing, Integration and System

Testing, Functional testing of Application, Performance testing of the Application including

measurement of all Service Levels as mentioned in this RFP and finally SI shall also carryout

Load/ Stress testing. The SI will submit the test plans and test result reports to the state nodal

agency for comprehensive verification and approval.

2.3.2.13 Requirement on Adherence to Standards

eDistrict application must be designed following open standards, and in line with overall system

requirements set out in this RFP, in order to provide for good inter-operability with multiple

platforms and avoid any technology or technology provider lock-in.

2.3.2.14 Compliance with Industry Standards

In addition to above, the proposed solution has to be based on and compliant with industry

standards (their latest versions as on date) wherever applicable. This will apply to all the

aspects of solution including but not limited to design, development, security, installation, and

testing. There are many standards that are summarized below. However the list below is just

for reference and is not to be treated as exhaustive.

I. Portal development W3C specifications

II. Information access/transfer protocols SOAP, HTTP/HTTPS

III. e-District DeitY, GoI guidelines.

IV. Photograph JPEG (minimum resolution of 640 x 480 pixels)

V. Scanned documents TIFF (Resolution of 600 X 600 dpi)

VI. Biometric framework BioAPI 2.0 (ISO/IEC 19784-1:2005)

VII. Latest HTML standards

2.3.2.15 Specification

I. Finger print scanning IAFIS specifications

II. Digital signature RSA standards

III. Document encryption PKCS specifications

IV. Information Security to be ISO 27001 compliant

V. Operational integrity & security management to be ISO 17799 compliant

VI. IT Infrastructure management ITIL / EITM specifications

VII. Service Management ISO 20000 specifications

VIII. Project Documentation IEEE/ISO specifications for documentation


24 | P a g e

IX. The SI shall adhere to all the standards published by the Department of

Electronics and Information Technology, Government of India.

2.3.2.16 Sign-off Deliverables

I. System Requirement Specification (SRS)

II. Functional Requirement Specification (FRS) (if, updated)

III. High Level and Low Level Design

IV. Functional and non-functional testing

V. Fully functional eDistrict Application

VI. User and Operational Manual for e-District Application

2.3.3 Obtain STQC Certification for eDistrict Application

The SI will be responsible for engaging STQC to conduct the assessment / review for the

system before “Go Live”. The SPMU 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. SI shall ensure the following points are duly addressed for successful completion of

STQC Certification.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 sys-

tems.

C. Determine systematic measures implemented to control and secure access to the ap-

plication 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


25 | P a g e

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 defi-

nition file update

SI is also required to comply with any other Technical/Functional requirements required to

receive Final Certification of STQC.


I. Sign off from SDA

II. STQC Certification

2.3.4 Alignment with Integrated Framework

The e-District application should integrate with SSDG and provide access to citizens for e-

District services through State Portal. It is envisaged that over a period of time all the existing

state applications which have their own independent database and workflow and are identical

to e-District should be made available on State Portal through the SSDG. The application may be

States’ own applications or adopted applications. The key functionalities required are as

follows.

• The SAP and SP Connectors will need to connect the e-district Business Layer. This

would help in routing requests and responses to back-end departments within a

stipulated time period.

• Design and implement an accounting module to keep track of all the transactions service

category wise, department wise and break down of transactions VLE, DeGS wise.

• MIS of number of transactions including name of service and category of service on time

and geographical scale should be published on e-District portal.

• Use e-authentication (including Aadhaar for citizens), e-payment, Digital signature and

Mobile gateway.

• As and when required, migrate the data available in eDistrict database to newly created

respective department database.

2.3.5 SSDG

I. The Integrated Service Delivery Framework envisages centralized architecture for each

MMP at the State level. The application software will be hosted in the State Data Centre.


26 | P a g e

Integration across States shall be enabled, through mandatory adherence to technical

specifications and e Governance standards.

II. The solution architecture of the e-District project envisages a centralised application

and database and will leverage the core e-infrastructure of State Wide Area Network,

State Data Centre and State Service Delivery Gateway.

III. The e-District MMP envisages centralised architecture at the state level with common

application software for each of the identified services for all the districts of the state.

The application software will be hosted in the SDC.

IV. Integration across states shall be enabled, through mandatory adherence to technical

specifications and e Governance standards.

2.3.6 Payment and SMS Gateway

I. Provisioning of a payment gateway, SMS gateway and any other components required

to meet the functional and Quality-of-Service requirements of the RFP is also within the

scope of work of the SI.

II. Payment Gateway should allow net banking and debit card payments through atleast 20

banks in the country (including all leading banks), besides payments through credit

cards (VISA, Mastercard).

III. Any one-time charges such as those for tie-ups, development of interfaces, registration,

commissioning etc of the gateway and any fixed recurring charges such as monthly

rentals, etc will have to be borne by the SI for the Contract period and may be budgeted

for in the Total Contract Value of this Project

IV. Any applicable transaction charges for making electronic payments or using SMS based

services shall however be payable by the citizen and SDA respectively and need not be

accounted for in the Total Contract value of this Project. Any transaction charges should

be payable in Indian Rupees only.

V. The contracts that the SI does with the Payment Gateway provider and SMS gateway

provider should be structured in a manner to allow the transaction charges to be paid

directly by the citizen / SDA. However if the contract with payment gateway / SMS

gateway provider require any transactional charges to be paid by the SI, the same will

be reimbursed to the SI by the SDA every month on an actual basis. The systems

deployed by the SI should be able to provide logs of the transactions done and charges

paid. The SDA will however reserve the right to negotiate and examine the rate

contracts of the SI with the gateway providers.

VI. Payment gateway should enable receipt of all payments such as Tax, interest, penalty,

arrear and fee etc and crediting the same to the SDA/ Department account. The

payment gateway should also allow credit of any refund amount to Kiosk/CSC’s

account. It should be possible to make electronic payments through a 3G / GPRS

enabled mobile phone as well.


27 | P a g e

2.3.7 UAT and Go-Live Report

SI will assist in successful completion of User Acceptance Testing (UAT) and audit of the system

on the completion of the roll out of eDistrict pilot for each phase and will submit a Go-Live

Report for each phase.


I. Go-Live report for state and district level

II. UAT Report signed off from actual/end users

2.3.8 Network Connectivity

For Odisha, the selected Bidder will undertake the following:

I. With implementation of State Wide Area Network (OSWAN) across all the States with 2

Mbps vertical connectivity up to block level is present. All the DC offices and Block

offices are co-located to the respective SWAN PoP. The selected Bidder shall ensure last

mile connectivity from the nearest SWAN PoP to the concerned users of DC Office &

Block Office via UTP cable only.

II. For all the Tahsil offices to access the application 2 MBPS Broadband connectivity

needs to be procured and commissioned by the bidder.

III. For all the RI offices to access the application 512 KBPS Broadband connectivity needs

to be procured and commissioned by the bidder.

IV. Additionally the selected bidder will need to establish LAN connectivity to all offices as

listed in section 4.1 including IP addressing scheme, physical cabling, router/switch

configuration, V-LAN configuration, and fail over mechanism. The selected Bidder

should coordinate with the local department offices while designing and installing the

LAN.

V. All networking equipment required to provide the LAN / WAN connectivity to meet the

requirements of the Project is also to be provided by the selected Bidder as part of this

RFP


Network Connectivity report signed off by concerned District Nodal officers stating Depart-

mental offices have been connected and SWAN, wherever applicable, has been leveraged to

provide connectivity.


28 | P a g e

2.3.9 Supply / Procurement of IT Infrastructure at SDC

State Government of Odisha will provide the Data Center premises for hosting the IT

Infrastructure. Load Balancer, SAN Storage, San Switch and Firewall available at the SDC shall

be leveraged by the Bidder. Bidders are required to carefully assess the requirements of this

RFP and size the infrastructure accordingly. Bidders are free to propose any higher / additional

infrastructure that may be required as per their proposed solution to meet the project

requirements, its scope of work and SLAs as listed in this RFP.

I. Bids / proposals which do not meet the minimum IT infrastructure specifications given

in this RFP will be summarily rejected. The minimum technical specifications for the IT

Infrastructure are provided in Section 4.5: Bill of Material (Infrastructure at SDC) in

Volume 2 of the RFP. The Bidder will be responsible for sizing the hardware to support

the scalability and performance requirements of the e-District application. The Bidder

shall ensure that the servers are sized adequately and redundancy is built into the

architecture required to meet the service levels mentioned in the RFP.

II. None of the IT Infrastructure proposed is declared “End-of-Sale” by the respective OEM

in next 2 years as on date of submission of Bid.

III. The IT Infrastructure proposed should be purchased within last 2 months from the date

of deployment and documentary proof for warranty and proof of purchase should be

produced at the time of deployment of infrastructure.

IV. The IT Infrastructure proposed should be compatible with infrastructure at SDC, SSDG,

SWAN, State Portal, etc.

V. The Bidder should provide requisite licenses for all the system software required for

servers including, but not limited to industry standard operating system, enterprise

class database software, application server software, web server software, OS

hardening, and all other required software with sufficient number of licenses.

VI. The Bidder will be responsible for providing all the details of the Bill of Material (BoM)

and specifications of the IT Infrastructure proposed, licenses of the system software, all

other equipment proposed as part of its Technical Proposal. The financial quote

submitted by the Bidder should include costs for these.

2.3.10 Hardware Commissioning at Field Offices

2.3.10.1 Design, Supply, Installation, Commissioning, O & M of IT

Infrastructure

This shall consist of

I. Procurement/Supply of IT Infrastructure at Department Offices.

II. Installation and Commissioning of IT Infrastructure


29 | P a g e

2.3.10.2 Installation and Commissioning of IT Infrastructure

The selected Bidder is responsible for installation and configuration of the entire infrastructure

set-up, including but not limited to the following:

I. All IT Infrastructure including operating systems and any other system software

required for making the infrastructure operational and tuned for satisfactory

performance.

II. The IT Infrastructure will be installed and configured in accordance with the IT Policies

of the state Odisha.

The selected Bidder will ensure that the reports for monitoring of SLAs such as system uptime,

performance, etc. are generated automatically from the system.

2.3.11 Licenses

I. The system software licenses mentioned in the Bill of Materials shall be genuine,

perpetual, full use and should provide upgrades, patches, fixes, security patches and

updates directly from the OEM. All the licenses and support (updates, patches, bug

fixes, etc.) should be in the name of OCAC.

II. If the is continuing with existing platform, then only the incremental licenses/support

has to be provided for the Statewide Rollout Application from the existing application.

However, if the Bidder is proposing for a change of platform, then they shall provide

with a full use database license. All the licenses and support (updates, patches, bug

fixes, etc.) should be in the name of OCAC. SI shall provide a comprehensive warranty

that covers all components after the issuance of the final acceptance by OCAC. The

warranty should cover all materials, licenses, services, and support for both hardware

and software. SI shall administer warranties with serial number and warranty period.

SI shall transfer all the warranties to the OCAC at no additional charge at the time of

termination of the project. All warranty documentation (no expiry) will be delivered to

Department.

2.3.12 Capacity Building / Training

Bidder must impart training to the personnel identified by the State Government on the follow-ing aspects.

I. Impart training on functional use of eDistrict Application

II. Usage of Digital Signature

III. Use of Biometric Devices

The Training has to be conducted at DHQ & SDHQ as per the requirement and as agreed upon

with the district administration. The SI would be required to prepare a detailed training plan

covering at least 2 rounds of training to the target audience, dates for training, duration and

training content. Following format need to be taken into consideration while calculating the cost


30 | P a g e

of training and preparing the training plan. If required the training would be required to be

provided again to ensure that personnel are ready to use the application whenever it is rolled

out.

TRAINING OF GOVERNMENT OFFICIALS

Name of the Module Duration No of times Partici-pant/Batch

Officers Staff

Impart training on

Functional use of

eDistrict Application

4 days (5 hrs/day)

6 days (5 hrs/day)

2 rounds 20

Usage of Digital Signature

1 day (1 hr) 1 day (2 hrs)

2 rounds 20

Use of Biometric Devices

1 days (1 hr) 1 day (2 hrs)

2 rounds 20

TRAINING OF CSC OPERATORS

Name of the Module Duration Participant/Batch

Impart training on Functional

use of eDistrict Application

1 day (8 hrs) to be given in 2 sessions

(To be decided later)

It is mandatory for the all employees identified for a particular batch/module to attend training.

If because of some constraints he/she is not able to attend the same, the implementation

agency should accommodate such employee in subsequent batches. SI needs to provide user

manuals (must be printed in A4 size paper and spiral binding) to each participants. Bidder also

needs to prepare Power Point Presentations and Videos to promote self- learning and assist

training participants in undergoing the training. The Video and Power Point Presentation need

to be handed over to each participant in a CD. It is expected that in each District around 400

officials need to be trained by SI. Actual number of users to be trained in each district will be

intimated to the SI at a later stage. SI also needs to impart training to 650 CSC operators across

the state. Number of CSC operators to be trained in each district will be intimated to the SI at a

later stage. Trained CSC operators in each district in turn shall impart training to rest of the

CSC operators in the district. In case of any change in number of participants the unit rate

quoted by the bidder for imparting training will be taken into consideration and the bidder

should agree to provide the training at the same cost.

2.3.12.1 Sign off Deliverables

I. Training Plan

II. Completion of training and change management activities


31 | P a g e

2.3.13 Manpower requirements

The SI would be required to position resources to provide technical support at each of the

districts during the roll out period. This would be essential to ensure sufficient handholding is

provided to personnel in the district level offices to manage the system after the end of SI’s

Contract Period. SI is required to provide the details of the manpower for 28 districts as per the

format given below.

S.N

o.

Name

of

Resou

rce

District for which

proposed

Qualificati

on

(Highest)

No. of

Years of

Experien

ce

No. of

Years

with

respondi

ng firm

Certificati

on

Choic

e 1

Choic

e 2

Choic

e 3

1

2

3

I. The Technical support resources would be required to work closely with the eDistrict

Manager, DeGS Coordinator and SPMU in ensuring adherence to the project timelines.

II. The SI should ensure that the roster schedule of all deployed manpower for each day at

the required locations has been communicated in advance to SDA/ DeGS. No change to

the deployed staff shall be done by the SI without written approval from the SDA/DeGS

III. Adherence to all laws pertaining to personnel, labour laws, etc for any manpower

deployed by the SI on this Project shall be the responsibility of the SI

IV. The SI would issue Identity cards to each of the staff members deployed at the districts.

V. The SI will maintain adequate leave reserve for the staff, so that the work in the

respective districts remains unaffected in all cases.

VI. The State, together with the SPMU would need to devise criteria for selection of

technical support resources who will be best positioned to handle the complexities

associated with rolling out the application in the specific state, for instance, being

conversant with the local language

VII. The resource will reporting to the Collector/Nodal Officer e-District or any other

authority as will be defined by the District Authority/ SDA


32 | P a g e

Brief job description of the technical support staff is given below.

a) Coordination in supply, installation and Inspection of Hardware at the District, Tahsils,

Sub-divisions, Blocks, Revenue Inspector Office and any other location pertaining to the

project.

b) Preventive Maintenance of District IT Infrastructure supplied under e-District

c) Complaints handling - Hardware & Software Issues

d) Complaints handling through telephone or through travel to respective location & re-

solve issues.

e) Maintenance of HW & SW records and calling.

f) Monitoring LAN Connectivity

g) Providing handholding support to the users of eDistrict Application

2.3.14 Business Continuity Planning

The selected Bidder is expected to develop a Business Continuity Plan (BCP) and Disaster

Recovery Plan (DRP) for the operations carried out by the selected Bidder. An indicative list of

activities to be performed by the selected Bidder is mentioned below:

I. 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)

II. 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. While building redundancies,

it should be ensured that failure of a single component of communication link does not

result in failure of primary as well as secondary connectivity. Hence primary and

secondary connectivity should be taken from 2 separate communication link providers

and both links should not have any single point of failure. Preferably, all the redundancy

will be in auto fail over mode so that if primary component fails, secondary component

automatically takes over.

III. Ensuring data backup till the last transaction occurring in the system to ensure

enhanced service levels and following RPO and RTO objectives:

A. Peak hours: Zero RPO and Zero RTO

B. Non-Peak Hours: Zero RPO and RTO <= 60 minutes

IV. Any storage space / media required to maintain backups and other requirements of the

RFP should be provisioned for by the selected Bidder in his Bid.

V. 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.


33 | P a g e

2.3.15 Others

2.3.15.1 Information Security Management

Security of Application and the data contained therein is paramount for the success of this

Project. Hence, the selected Bidder 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 selected Bidder. 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 should not conflict with the security policy of the State

Data Centre where the infrastructure would be hosted. Interested Bidder need

to discuss with the SDC Composite Team to ensure the same.

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.

http://egovstandards.gov.in/


34 | P a g e


7. The proposed solution should support the below Integration security

standards:

Authentication

Authorization

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:

i. Layers of firewall

ii. Network IPS

iii. Enterprise-wide Antivirus solution

iv. Information and incident management solution for complete

OCAC landscape

v. Two factor authentication for all administrators i.e. system

administrators, network administrators, database administrators.

vi. Audit Log Analysis

Selected Bidder 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 OCAC. 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 OCAC 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 Selected Bidder

shall provide the OCAC’s representatives access to its facilities, installations,


35 | P a g e


technical resources, operations, documentation, records, databases and

personnel. The Selected Bidder must provide OCAC access to various

monitoring and performance measurement systems (both manual and

automated). OCAC has the right to get the monitoring and performance

measurement systems (both manual and automated) audited / assessed

without prior approval / notice to the Selected Bidder

10. The proposed solution should facilitate system audit for all the information

assets to establish detective controls. The selected Bidder is required to

facilitate this by producing and maintaining system audit logs for entire

duration of the project.

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 OCAC 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” 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 OCAC 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


36 | P a g e


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):

a) Pharming

b) Trojan

c) Domains (old/new) similar to “OCAC of Commercial Taxes,

Government of Tamil Nadu 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 selected Bidder before

commencement of the operations. Robust backup procedures to be

established for the same.

Password Requirement

1. The proposed solution should allow OCAC to define password policies. The

minimum password policies to be defined are:

a) Minimum/ Maximum password length

b) Alpha numeric combination of password

c) Compulsory use of special characters

d) Minimum password age

e) Password expiry period

f) Repeat passwords etc.

2. The proposed solution should be able to automatically check the passwords

with the password policy, which can be customized by the OCAC

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


37 | P a g e


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 (selected Bidder 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 (https) only for all level of communication for providing higher

level of security.

2.3.16 Project Management

2.3.16.1 Project Planning and Management

e-District Mission Mode Project is a geographically spread initiative involving multiple

stakeholders. Successful implementation and national roll out of the project ultimately depends

on all its stakeholders, the role of SI is very critical. Hence SI is required to design and

implement a comprehensive and effective project planning and management methodology

together with efficient and reliable tools.

Project planning exercise shall essentially commence with the start of the project, however,

project management exercise shall commence at the start of the project and shall continue till

the O&M Phase of the project...

To have an effective project management system in place, it is necessary for the SI to use a

Project Management Information System (PMIS) at State Headquarters of his respective State

to monitor the Project Progress. The SI shall address at the minimum the following using PMIS:

I. Create an organized set of activities for the project.

II. Coordinate and collaborate with various stakeholders including the Departments

concerned.

III. Nodal Agency, State IT Department, NIC, SPMU, NPMU, DeitY, GoI.

IV. Establish and measure resource assignments and responsibilities.

V. Construct a project plan schedule including milestones.

VI. Measure project deadlines, budget figures, and performance objectives.

VII. Communicate the project plan to stakeholders with meaningful reports.

VIII. Provide facility for detecting problems and inconsistencies in the plan


38 | P a g e

During the project implementation the SI shall report to the State Nodal Officer/SPMU, on

following items:

I. Results accomplished during the period;

II. Cumulative deviations to date from schedule of progress on milestones as specified in

this RFP read with the agreed and finalized Project Plan;

III. Corrective actions to be taken to return to planned schedule of progress;

IV. Proposed revision to planned schedule provided such revision is necessitated by

reasons beyond the control of the SI;

V. Other issues and outstanding problems, and actions proposed to be taken;

VI. Interventions which the SI expects to be made by the State Nodal Officer and / or

actions to be taken by the State Nodal Officer before the next reporting period. Progress

reports would be prepared by SI on a fortnightly basis. These reports may be required

to be shared with either the SDA or the SPMU, as the case may be.

VII. Project quality Assurance

VIII. Change Control mechanism

IX. Project Management activities

X. Issue Management to help identify and track the issues that need attention and

resolution from the State.

XI. Scope Management to manage the scope and changes through a formal management

and approval process.

XII. Risk Management to identify and manage the risks that can hinder the project

progress.

SI will closely work with SPMU and send the reports to the SPMU as well. SPMU will assist

Nodal Officer in acceptance of the report/ document and suggest the action plan to the Nodal

Officer. The Project plan prepared by the SI at the initial stage of the project shall be reviewed

by the SDA/Apex Committee on the advice of the State eGovernance Mission Team and SPMU.

The SI shall update and maintain the Project Plan throughout the duration of the engagement.

All changes are to be reviewed and approved by the OCAC.

2.3.16.2 Project Planning and Management

I. PMIS data update & functioning

II. Periodic Reports on on-going basis


39 | P a g e

2.4 Scope of Services - Operation and Maintenance Phase

The selected Bidder is responsible for the day to day maintenance of the system for the entire

period of Contract. For the IT Infrastructure procured as part of this RFP, the selected Bidder

will be responsible for smooth Operations and Maintenance Services for the period covering

onsite support for 3 year of warranty and followed by 2 years of AMC from the date of Go-Live

covering the following:

I. Onsite Warranty support

II. Onsite Periodic and AMC support including repair and replacement

III. Annual Technical Support (ATS) for all the licensed software

IV. Providing Help desk support with Escalation matrix for registration of

complaints related to the IT Infrastructure procured through this RFP at the

State Data Center.

2.4.1 Overview of Post Implementation Services

An indicative list of activities and nature of support to be provided is mentioned below:

I. System Administration and Trouble Shooting

A. Overall monitoring and management of all IT and Non-IT infrastructure deployed by

the selected Bidder for the Project, Departmental locations, networking equipments &

connectivity, system software, application, database, and all other services associated

with these facilities to ensure service levels, performance and availability requirements

as prescribed in the RFP are met.

B. Repair or replace infrastructure deployed for this Project, either directly or through a

third party warranty provider depending on the case

C. Replace component due to technical, functional, manufacturing or any other problem

with a component of the same make and configuration. In case the component of same

make and configuration is not available, the replacement shall conform to open

standards and shall be of a higher configuration and shall be approved by the

Department

D. Perform system administration tasks such as managing the user access, creating and

managing users, taking backups etc.

E. Performance tuning of the system to ensure adherence to SLAs and performance

requirements as indicated in the RFP.

II. Network Administration and Trouble Shooting

Coordinate with the network service providers to maintain smooth network operations

and ensure uptime and performance requirements of the IT infrastructure as indicated

in the RFP are met. The selected Bidder will be totally responsible for all networking

equipments installed by him.

III. Database Administration and Trouble Shooting

Undertake end-to-end management of database on an on-going basis to facilitate

smooth functioning and optimum utilization including regular database backup and


40 | P a g e

periodical testing of backup data, conducting configuration review to tune database,

maintaining the necessary documentation and managing schemes to database schema,

disk space, user roles, and storage.

IV. Overall

A. Undertake preventive maintenance (any maintenance activity that is required before

the occurrence of an incident with an attempt to prevent any incidents) and carry out

the necessary repairs and replacement of parts wherever needed to keep the

performance levels of the hardware and equipment in tune with the requirements of

the SLA. Such preventive maintenance shall not be attended during working hours of

the State Departments, unless inevitable and approved by the OCAC.

B. Undertake reactive maintenance (any corrective action, maintenance activity that is

required post the occurrence of an incident) that is intended to troubleshoot the system

with sufficient teams

C. Escalate and co-ordinate with its OEMs for problem resolution wherever required

D. The selected Bidder will be required to comply with various policies relating to

monitoring and management of infrastructure such as IS Policy, backup and archival

policy, system software update policy etc. of the State Odisha.

2.4.2 Warranty Support

As part of the warranty services SI shall provide:

I. SI shall provide a comprehensive 3 year of warranty and followed by 2 years of AMC

from the date of Go-Live.

II. SI shall provide the comprehensive manufacturer's warranty and support in respect of

proper design, quality and workmanship of all hardware, equipment, accessories etc.

covered by the RFP.

III. SI must warrant all hardware, equipment, accessories, spare parts, software etc.

procured and implemented as per this RFP against any manufacturing defects during

the warranty period.

IV. SI shall provide the performance warranty in respect of performance of the installed

hardware and software to meet the performance requirements and service levels in the

RFP.

V. SI is responsible for sizing and procuring the necessary hardware and software

licenses as per the performance requirements provided in the RFP. During the

warranty period SI shall replace or augment or procure higher-level new equipment or

additional licenses at no additional cost to the OCAC in case the procured hardware or

software is not adequate to meet the service levels.

VI. Mean Time Between Failures (MTBF): If during contract period, any equipment has a

hardware failure on four or more occasions in a period of less than three months, it

shall be replaced by equivalent or higher-level new equipment by the SI at no cost to

OCAC


41 | P a g e

VII. However, if the new equipment supplied is priced lower than the price at which the

original support services for all system software, DBMS (Database Management

System), EMS (Enterprise Management System), other products deployed as part of this

project will require proper arrangements of SI with OEM.

VIII. During the warranty period SI shall maintain the systems and repair / replace at the

installed site, at no charge to OCAC, all defective components that are brought to the SI's

notice.

IX. Warranty should not become void, if OCAC buys, any other supplemental hardware

from a third party and installs it within these machines under intimation to the SI.

However, the warranty will not apply to such supplemental hardware items installed.

X. The SI shall carry out Preventive Maintenance (PM), including cleaning of interior and

exterior, of all hardware and testing for virus, if any, and should maintain proper

records at each site for such PM. Failure to carry out such PM will be a breach of

warranty and the warranty period will be extended by the period of delay in PM.

XI. SI shall monitor warranties to check adherence to preventive and repair maintenance

terms and conditions.

XII. The SI shall ensure that the warranty complies with the agreed Technical Standards,

Security Requirements, Operating Procedures, and Recovery Procedures.

XIII. Any component that is reported to be down on a given date should be either fully

repaired or replaced by temporary substitute (of equivalent configuration) within the

time frame indicated in the Service Level Agreement (SLA).

XIV. The SI shall develop and maintain an inventory database to include the registered

hardware warranties.

2.4.3 Annual Technical Support

As part of the ATS services SI shall provide the following:

I. SI shall maintain data regarding entitlement for software upgrades, enhancements,

refreshes, replacements and maintenance.

II. If the Operating System or additional copies of Operating System are required to be

installed / reinstalled / de-installed, the same should be done as part of ATS.

III. SI should carry out any requisite adjustments / changes in the configuration for

implementing different versions of Application Software.

IV. Updates / Upgrades / New releases / New versions / Patches / Bug fixes: The SI shall

provide from time to time the Updates / Upgrades / New releases / New versions /

Patches / Bug fixes of the software, operating systems, etc. as required. The SI should

provide free Updates / Upgrades / New releases / New versions / Patches / Bug fixes of

the software and tools to SDA as and when released by OEM.

V. Software License Management. The SI shall provide software license management and

control. SI shall maintain data regarding entitlement for software upgrades,

enhancements, refreshes, replacements, and maintenance.


42 | P a g e

VI. SI shall have complete manufacturer’s technical support for all the licensed software

problems and/or questions, technical guidance, defect and non-defect related issues. SI

shall provide a single-point-of-contact for software support and provide licensed

software support including but not limited to problem tracking, problem source

identification, problem impact (severity) determination, bypass and recovery support,

problem resolution, and management reporting.

2.4.4 Help Desk and Trouble ticket management system

I. The selected Bidder as part of provisioning support for Department users at each

location and the SDC will setup centralized helpdesk and coordinate with the respective

OEMs of the IT Infrastructure deployed at SDC and the Department offices. For the State

Odisha the selected Bidder will undertake the following:

A. Provide Help Desk services to track and route requests for service and to assist

department users in answering questions and resolving problems related to the IT

Infrastructure installed at Data Centre and at all the Department Offices .

B. Become the central collection point for contact and control of the problem, change,

and service management processes (This includes both incident management and

service request management)

C. Shall provide a first level of support for application and technical support at e-

District implementation locations across the State where the software, hardware, and

other infrastructure will be rolled out.

D. Provide the following integrated customer support by establishing 9 hrs X 6 days

Help Desk facility for reporting issues/ problems with the software, hardware and

other infrastructure.

II. This shall be an online system deployed centrally and shall be used by the selected

Bidder extensively for management of network support activity and handling calls from

citizen, departmental staff, any other stakeholders. Service desk is an application that

facilitates the end-to-end service support. The proposed system should include

required hardware and software.

All relevant infrastructure and supporting system software required for the deployment and

operation of the help desk is to be provided by the selected Bidder as per the requirements

mentioned in the RFP. The system deployed by the SI shall be complied with ITIL and ISO

20000 service specifications.


43 | P a g e

2.4.5 General Requirements

I. Licensing Requirements

A. All system software, licenses, etc. have to be procured in the name of OCAC

B. The licenses should be perpetual and enterprise wide for the core application and

other software unless otherwise stated. The software licenses shall not be restricted

based on location and the OCAC should have the flexibility to use the software licenses

for other requirements, if required

II. Asset Management

The selected Bidder will perform the following asset management functions with

respect to the infrastructure deployed at various locations:

A. Take periodic stock of, review physical inventory and maintain stock registers of

hardware at all locations covered under this Project. The selected Bidder would

maintain stock registers as per format agreed with the OCAC.

B. Maintain documentation of the hardware assets, maintain asset Information for all

Project locations, on parameters to be mutually agreed between the OCAC and the

selected Bidder, which shall include details like -

i. Product type, model number, version number

ii. Manufacturer

iii. Office location

iv. Maintenance status, etc.

C. Update or correct the asset information following any new installations, movement,

addition, or change performed by the selected Bidder.

D. Produce periodic reports and machine readable files in agreed upon format pertaining

to some or all of the asset information.

E. Restrict movement of server/equipment/items in or out of SDC or any other location

under the Project without prior permission from the OCAC.

III. Warranty and Support

A. The selected Bidder shall warrant that the IT Infrastructure supplied to the OCAC for

this Project shall have no defects arising from design or workmanship or any act or

omission of the selected Bidder. The warranty shall remain valid for the Contract period

on all the items supplied as per the Contract.

B. The selected Bidder shall replace any parts/ components of the IT infrastructure

supplied for the Project if the components are defective and during the entire warranty

period the selected Bidder shall apply latest upgrades for all the hardware components

after appropriate testing. The OCAC will not pay any additional costs separately for

warranty and the overall IT infrastructure cost quoted by the selected Bidder shall

include the same.

C. Since the Project aims to reuse the common infrastructure created under SDC, SWAN,

CSC, SSDG Projects, the selected Bidder will also be required to coordinate with SDC,

SWAN, SSDG, CSC teams to ensure that uptime and performance requirements of the

RFP are met. However, the selected Bidder shall be held solely responsible for


44 | P a g e

performance and service levels of any infrastructure deployed by the selected Bidder as

part of this Contract.

IV. Knowledge Transfer

A. At the end of the Contract period, the selected Bidder will be required to provide

necessary handholding and transition support to designated staff or any other agency

that is selected for maintaining the system post the Contract with the selected Bidder.

The handholding support will include but not be limited to, conducting detailed

walkthrough and demonstrations for the IT Infrastructure, handing over all relevant

documentation, addressing the queries/clarifications of the new agency with respect to

the working / performance levels of the infrastructure, conducting training sessions etc.

B. Knowledge Transfer is an integral part of the scope of work of the selected Bidder. This

will have to be done even in case the Contract with the Bidder ends or is terminated

before the planned timelines.

Any other activity, over and above these, as may be deemed necessary by the selected Bidder to

meet the service levels and requirements specified in this Contract are also required to be

performed by the selected Bidder at no additional cost.

2.4.6 Exit Management

2.4.6.1 Purpose

I. This sets out the provisions, which will apply on expiry or termination of the MSA, the

Project Implementation, Operation and Management SLA.

II. In the case of termination of the Project Implementation and/or Operation and

Management, the Parties shall agree at that time whether, and if so during what period,

the provisions of this Schedule shall apply.

III. The Parties shall ensure that their respective associated entities carry out their

respective obligations set out in this Exit Management Schedule.

2.4.6.2 Transfer of Assets

I. OCAC shall be entitled to serve notice in writing on the SI at any time during the exit

management period as detailed hereinabove requiring the SI and/or its sub-contractors

to provide the OCAC with a complete and up to date list of the Assets within 30 days of

such notice. OCAC shall then be entitled to serve notice in writing on the SI at any time

prior to the date that is 30 days prior to the end of the exit management period

requiring the SI to sell the Assets, if any, to be transferred to OCAC or its nominated

agencies at book value as determined as of the date of such notice in accordance with

the provisions of relevant laws.

II. In case of contract being terminated by OCAC, OCAC reserves the right to ask SI to

continue running the project operations for a period of 6 months after termination

orders are issued.

III. Upon service of a notice under this Article the following provisions shall apply:

A. in the event, if the Assets to be transferred are mortgaged to any financial institutions

by the SI, the SI shall ensure that all such liens and liabilities have been cleared beyond


45 | P a g e

doubt, prior to such transfer. All documents regarding the discharge of such lien and

liabilities shall be furnished to the OCAC.

B. All risk in and title to the Assets to be transferred / to be purchased by the OCAC

pursuant to this Article shall be transferred to OCAC, on the last day of the exit

management period.

C. OCAC shall pay to the SI on the last day of the exit management period such sum

representing the Net Block (procurement price less depreciation as per provisions of

Companies Act) of the Assets to be transferred as stated in the Terms of Payment

Schedule.

D. Payment to the outgoing SI shall be made to the tune of last set of completed services /

deliverables, subject to SLA requirements.

E. The outgoing SI will pass on to OCAC and/or to the Replacement SI, the subsisting

rights in any leased properties/ licensed products on terms not less favorable to OCAC/

Replacement SI, than that enjoyed by the outgoing SI.

2.4.6.3 Cooperation and Provision of Information

During the exit management period:

I. The SI will allow the OCAC or its nominated agency access to information reasonably

required to define the then current mode of operation associated with the provision of

the services to enable the OCAC to assess the existing services being delivered;

II. promptly on reasonable request by the OCAC, the SI shall provide access to and copies

of all information held or controlled by them which they have prepared or maintained

in accordance with this agreement relating to any material aspect of the services

(whether provided by the SI or sub-contractors appointed by the SI). The OCAC shall be

entitled to copy of all such information. Such information shall include details pertaining

to the services rendered and other performance data. The SI shall permit the OCAC or

its nominated agencies to have reasonable access to its employees and facilities as

reasonably required to understand the methods of delivery of the services employed by

the SI and to assist appropriate knowledge transfer.

2.4.6.4 Confidential Information, Security and Data

I. The SI will promptly on the commencement of the exit management period supply to

the OCAC or its nominated agency the following:

A. information relating to the current services rendered and customer and

performance data relating to the performance of sub-contractors in relation to the

services;

B. documentation relating to Computerization Project’s Intellectual Property Rights;

C. documentation relating to sub-contractors;

D. all current and updated data as is reasonably required for purposes of OCAC or its

nominated agencies transitioning the services to its Replacement SI in a readily

available format nominated by the OCAC, its nominated agency;

E. all other information (including but not limited to documents, records and

agreements) relating to the services reasonably necessary to enable OCAC or its


46 | P a g e

nominated agencies, or its Replacement SI to carry out due diligence in order to

transition the provision of the Services to OCAC or its nominated agencies, or its

Replacement SI(as the case may be).

II. Before the expiry of the exit management period, the SI shall deliver to the OCAC or its

nominated agency all new or up-dated materials from the categories set out in

Schedule above and shall not retain any copies thereof, except that the SI shall be

permitted to retain one copy of such materials for archival purposes only.

III. Before the expiry of the exit management period, unless otherwise provided under the

MSA, the OCAC or its nominated agency shall deliver to the SI all forms of SI confidential

information, which is in the possession or control of Chairperson, PIU or its users.

2.4.6.5 Employees

I. Promptly on reasonable request at any time during the exit management period, the SI

shall, subject to applicable laws, restraints and regulations (including in particular those

relating to privacy) provide to the OCAC or its nominated agency a list of all employees

(with job titles) of the SI dedicated to providing the services at the commencement of

the exit management period.

II. Where any national, regional law or regulation relating to the mandatory or automatic

transfer of the contracts of employment from the SI to the OCAC or its nominated

agency, or a Replacement SI ("Transfer Regulation") applies to any or all of the

employees of the SI, then the Parties shall comply with their respective obligations

under such Transfer Regulations.

III. To the extent that any Transfer Regulation does not apply to any employee of the SI,

department, or its Replacement SI may make an offer of employment or contract for

services to such employee of the SI and the SI shall not enforce or impose any

contractual provision that would prevent any such employee from being hired by the

OCAC or any Replacement SI.

2.4.6.6 Transfer of Certain Agreements

On request by OCAC or its nominated agency the SI shall effect such assignments, transfers,

licences and sub-licences as the OCAC may require in favor of the Chairperson, PIU, or its

Replacement SI in relation to any equipment lease, maintenance or service provision

agreement between SI and third party lessors, vendors, and which are related to the services

and reasonably necessary for the carrying out of replacement services by the OCAC or its

nominated agency or its Replacement SI.

2.4.6.7 Rights of Access to Premises

I. At any time during the exit management period, where Assets are located at the SI’s

premises, the SI will be obliged to give reasonable rights of access to (or, in the case of

Assets located on a third party's premises, procure reasonable rights of access to) the

OCAC or its nominated agency and/or any Replacement SI in order to make an

inventory of the Assets.


47 | P a g e

II. The SI shall also give the OCAC or its nominated agency or its nominated agencies, or

any Replacement SI right of reasonable access to the Implementation Partner's

premises and shall procure the OCAC or its nominated agency or its nominated

agencies and any Replacement SI rights of access to relevant third party premises

during the exit management period and for such period of time following termination

or expiry of the MSA as is reasonably necessary to migrate the services to the OCAC or

its nominated agency, or a Replacement SI.

2.4.6.8 General Obligations of the SI

I. The SI shall provide all such information as may reasonably be necessary to effect as

seamless a handover as practicable in the circumstances to the OCAC or its nominated

agency or its Replacement SI and which the SI has in its possession or control at any

time during the exit management period.

II. For the purposes of this Schedule, anything in the possession or control of any SI,

associated entity, or sub-contractor is deemed to be in the possession or control of the

SI.

III. The SI shall commit adequate resources to comply with its obligations under this Exit

Management Schedule.

2.4.6.9 Exit Management Plan

I. The SI shall provide the OCAC or its nominated agency with a recommended exit

management plan ("Exit Management Plan") which shall deal with at least the following

aspects of exit management in relation to the MSA as a whole and in relation to the

Project Implementation, and the Operation and Management SLA.

A. A detailed program of the transfer process that could be used in conjunction with a

Replacement SI including details of the means to be used to ensure continuing provision

of the services throughout the transfer process or until the cessation of the services

and of the management structure to be used during the transfer;

B. plans for the communication with such of the SI's sub-contractors, staff, suppliers,

customers and any related third party as are necessary to avoid any material

detrimental impact on the OCAC’s operations as a result of undertaking the transfer;

C. (if applicable) proposed arrangements for the segregation of the SI's networks from the

networks employed by OCAC and identification of specific security tasks necessary at

termination;

D. Plans for provision of contingent support to OCAC, and Replacement SI for a reasonable

period after transfer.

II. The SI shall re-draft the Exit Management Plan annually thereafter to ensure that it is

kept relevant and up to date.

III. Each Exit Management Plan shall be presented by the SI to and approved by the OCAC

or its nominated agencies.

IV. The terms of payment as stated in the Terms of Payment Schedule include the costs of

the SI complying with its obligations under this Schedule.


48 | P a g e

V. In the event of termination or expiry of MSA, and Project Implementation, each Party

shall comply with the Exit Management Plan.

VI. During the exit management period, the SI shall use its best efforts to deliver the

services.

VII. Payments during the Exit Management period shall be made in accordance with the

Terms of Payment Schedule.

VIII. This Exit Management plan shall be furnished in writing to the OCAC or its nominated

agencies within 90 days from the Effective Date of Agreement.


49 | P a g e

3 Detailed Implementation and Roll-out Plan

I. SI shall prepare a detailed roll-out plan for each of the districts in the phase and get the

same approved by the OCAC. SI is also responsible for conducting workshops for the

key officers (State Mission Team, District Mission Team, and District Core Team, NIC,

SPMU, NPMU, OCAC, State DIT) of the Districts / State for presenting the District-Wise

roll-out plan and get the approval of the same.

II. Before getting the final approval of the State Nodal Officer, the SI shall also provide the

necessary assistance for the key stakeholder of the Districts / State during the design

and implementation of e-District project in the State Odisha. A detailed rollout checklist

should be maintained for migrating application to production as well as for location

readiness.

III. One of the important factors that would determine the success of the e-District

implementation in the Odisha is the continuous availability of domain experts like

Project Manager, Database Administrator, Change Management Expert, Technical

Assistance, to the implementation team which would be selected with the approval of

Odisha. SI shall put together a team of domain experts with a minimum of 10 years of

experience in the State Departments who will work on this project on a full time basis

during the entire duration of the project.


State-wide rollout of the eDistrict MMP 50 | P a g e

4 Annexures:

4.1 Office Wise Requirements

DISTRICT NO. OF SUBDIVISION NO. OF TAHSILS NO. OF BLOCKS NO. OF RI OFFICES

e-District Service being delivered from this District

Network

Availability?

(Yes/ No)

Additional H/W Required? (Yes/ No)

Sundargarh 3 18 17 102 Yes Yes Yes

Jharsuguda 1 5 5 10 Yes Yes Yes

Deogarh 1 3 3 20 Yes Yes Yes

Sambalpur 3 9 9 56 Yes Yes Yes

Keonjhar 3 13 13 80 Yes Yes Yes

Angul 4 8 8 55 Yes Yes Yes

Bhadrak 1 7 7 76 Yes Yes Yes

Jajpur 1 10 10 80 Yes Yes Yes

Dhenkanal 3 8 8 50 Yes Yes Yes

Balasore 2 12 12 85 Yes Yes Yes

Nuapada 1 5 5 21 Yes Yes Yes

Bolangir 3 14 14 34 Yes Yes Yes

Sonepur 2 6 6 31 Yes Yes Yes

Boudh 1 3 3 22 Yes Yes Yes



Kandhamal 2 12 12 74 Yes Yes Yes

Cuttack 3 15 14 127 Yes Yes Yes

Khurda 2 10 10 67 Yes Yes Yes

Puri 1 11 11 128 Yes Yes Yes

Kendrapara 1 9 9 92 Yes Yes Yes

Jagatsinghpur 1 8 8 76 Yes Yes Yes

Bargarh 2 12 12 84 Yes Yes Yes

Kalahandi 2 13 13 48 Yes Yes Yes

Nabarangpur 1 10 10 66 Yes Yes Yes

Rayagada 2 11 11 81 Yes Yes Yes

Gajapati 1 7 7 44 Yes Yes Yes

Koraput 2 14 14 95 Yes Yes Yes

Malkangiri 1 7 7 44 Yes Yes Yes

Nayagarh 1 8 8 42 Yes Yes Yes



4.2 Template for Capturing Network Connectivity Requirement

DISTRICT

NO. OF SUBDIVISION

NO. OF TAHSILS

NO. OF BLOCKS

NO. OF RI OFFICES

Swan

Available(Yes/NO)

SWAN Available

Type of

connectivity

Existing service

provider

Service level /

baseline

Sundargarh 3 17 17 102 Yes All Block Offices & Sub-divison offices

Broadband Ms Spancho Available

Jharsuguda 1 5 5 10 Yes All Block Offices & Sub-divison offices


Deogarh 1 3 3 20 Yes All Block Offices & Sub-divison offices


Sambalpur 3 9 9 56 Yes All Block Offices & Sub-divison offices

Broadband Ms Spancho Avialable

Keonjhar 3 13 13 80 Yes All Block Offices & Sub-divison offices


Angul 4 8 8 55 Yes All Block Offices & Sub-divison offices


Bhadrak 1 7 7 75 Yes All Block Offices & Sub-divison offices


Jajpur 1 9 10 80 Yes All Block Offices & Sub-divison offices


Dhenkanal 3 8 8 50 Yes All Block Offices & Sub-divison offices


Balasore 2 12 12 85 Yes All Block Offices & Sub-divison offices


Nuapada 1 5 5 21 Yes All Block Offices & Sub-divison offices


Bolangir 3 14 14 34 Yes All Block Offices & Sub-divison offices


Subarnapur 2 6 6 31 Yes All Block Offices & Sub-divison offices


Boudh 1 3 3 22 Yes All Block Offices & Sub-divison offices




Kandhamal 2 12 12 74 Yes All Block Offices & Sub-divison offices


Cuttack 3 15 14 127 Yes All Block Offices & Sub-divison offices


Khurda 2 10 10 67 Yes All Block Offices & Sub-divison offices


Puri 1 11 11 107 Yes All Block Offices & Sub-divison offices


Kendrapara 1 9 9 92 Yes All Block Offices & Sub-divison offices


Jagatsinghpur 1 8 8 76 Yes All Block Offices & Sub-divison offices


Bargarh 2 12 12 84 Yes All Block Offices & Sub-divison offices


Kalahandi 2 13 13 48 Yes All Block Offices & Sub-divison offices


Nabarangpur 1 10 10 66 Yes All Block Offices & Sub-divison offices


Rayagada 2 11 11 81 Yes All Block Offices & Sub-divison offices


Gajapati 1 7 7 43 Yes All Block Offices & Sub-divison offices


Koraput 2 14 14 99 Yes All Block Offices & Sub-divison offices


Malkangiri 1 7 7 44 Yes All Block Offices & Sub-divison offices


Nayagarh 1 8 8 50 Yes All Block Offices & Sub-divison offices




4.3 FRS for the Proposed Application

The computerization under the e-District project envisages meeting of the requirements through the e-District Application consisting of

Certificates, Pensions, Revenue Court Cases, PDS services, Grievance Redressal services etc. The following depicts the brief scope and the

indicative functional requirement specifications of the applications envisaged for development of solution under e-District. This however

does not mean that the functionalities have been captured entirely. The final scope will be documented in detail with the selected bidder.

SPMU will prepare the AS-IS, TO-BE & FRS documents and the same will be handed over to the selected Bidder after approval to carry out

necessary task at his end.

Functional Specification for Common Functionalities:

The common functionality shall address the automation of typical processes that shall be common for all the services irrespective of the

service categories. Broadly, these can be seen as the general service components which remain same for services. These general service

components along with the detailed Functional Requirement Specifications are given below.



4.3.1 Information Dissemination Component

This component deals with the Content creation, content updation and approval for the proper dissemination of information for availing

the various services

S. No. Functional Requirement Specifications - Information Dissemination

1. The system should allow the authorized user(s) to update information obtained from the departments

2.

The system should provide detailed information on the following to the user:

Scheme Name:

Eligibility Criteria:

Nodes of obtaining service:

Application Fees:

Grievance filing procedure:

Authorities to contact:

Forms and documents required:

Other locations for obtaining detailed information

3. The system should be able to add new or delete existing information components besides the above without any delay and

without jeopardizing any other existing feature

4. The system should be accessible to citizens, department officials, other government officials, e district centre operators,

SCA

5.

The authorized user(s) should be able to update the document over the e district application but this information would

not be viewable to the end user until the department head puts his digital signature, verifying its authenticity and

correctness



S. No. Functional Requirement Specifications - Information Dissemination

6. The system should not allow any unauthorized user to upload information besides authorized user(s)

7. The system should have different presentation layer for each set of users i.e. Information seekers, updaters, approvers etc.

8. The system should notify the HoD once the information is updated over the e application

9. The system should allow the HoD to either approve or reject the information update

10. The system should update information over the e-district application only after digital signatures of the HoD has been put

up on the information update

11. The system should ask for digital signature of the HoD in case of rejection also

12. The system should ask for changes from the HoD desired in case of rejection by the HoD

13. The system should notify the authorized user(s) both in case of acceptance or rejection of the information update

14. The system should allow only the authorized user(s) to make changes in the updated information hosted over the e

district application

15. The system should request authorized user(s) to put his digital signature after each updation

16. The system should have a counter at the bottom of the page to record the number of people hitting the website, this

would prove beneficial in capturing the usefulness of information

17. The system should auto generate grievances in case of HoD or authorized user(s) are not performing against their set

SLAs

18. The system should capture time stamp and IP address of the user accessing the system

19. The system should have bar-coding technology for printing and authorizing necessary documents.



4.3.2 Forms Availability Component

This component deals with the availability of latest electronic forms that will be made available in the e-District portal.

S.No Functional Requirement Specifications – Form Availability

1. The system should store all the service request form at predefined location for the selected services

2. The system should be able to retrieve service request form from the predefined location

3. The system should allow for service request form to be easily downloadable both through HTML and word format

4.

The size of the forms created for delivering the services through application shall be kept to the minimum so as to suit

bandwidth typical to dial-up Internet connections. The form filling should be easy, user friendly and shall avoid common form

filling errors (such as, ensuring all mandatory fields are entered, selecting options by checking boxes where applicable, number

entry etc.)

5. The Application shall provide Easy-to-use step-by-step guidance to fill the Forms in the form of form-wizards

6.

The system should provide for printable version of the service request form. The forms must be supported for use by the

stakeholders on all widely used web` browsers like Chrome, IE, Mozilla etc. preserving the functionality, look and feel of the

form. When printed, the eForms must preserve the appearance as on the screen”

7. The system should give an error message in case it is not able to retrieve the application from the given location

8. The system should have a provision for uploading new version of the forms as and when it is required to change the version

9. The system should maintain the version control for the service request form

10. The system should have a security feature embedded for changing the version of the form and should allow only predefined

process owners to change the form version

11. The system should maintain log for all version change with the details of the process owner making version change

12. The system should not allow to change the content of the form and should be in read only version



S.No Functional Requirement Specifications – Form Availability

13.

The system should be able to make available service request form should be through

Online / website

CSC

EDistrct Center/Facilitation Center

14. The system should allow for easy searching of the service request form

15. The system should allow for easy and user friendly layout for locating the service request form

16. The system should be able to export forms in multiple formats so as to ensure compatibility of forms

17. The system should have a life counter feature to keep track of number of forms being downloaded from the application

18. The system should support multi-lingual interface (minimum Hindi and English) as per localization and language technology

standards for National e-Governance plan defined in the e-District guidelines



4.3.3 Application Receipt Component

This component deals with the receipt of the application by the CSC/e-District centre operator and forwarding of the same to the

concerned office, depending upon the nature of the service.

S.No Functional Requirement Specifications – Application Request

1. The System should enforce secure login as per the Login process, where the CSC or e-District center operator will have to

authenticate his Username, Password to access the Application home page.

2. The System, on successful login, should display the Main page or the Home page of the Applications Services Request with links

to various services as per the Service Request Form mentioned above.

3. The System should be able to retrieve and load the online Application Form for the service as selected by the Applicant /

Operator.

4. The System should assign a Unique Application Number to every form.

5. The System should allow the Operator / Applicant to take a printout of the form before submitting it.

6. The System should allow editing of the details in the online Application form even after a printout has been taken.

7. The System should allow the Operator / Applicant to attach any scanned documents, photograph, or any other supplementary

attachments as required with the Application Form

8. The System should imprint the Unique Application Number and the ID details of the operator on the Application Form.

9. The System should allow the operator to submit the Application Form online

10. The System must display a message for Successful or Unsuccessful submissions and it should log all such events.

11. The System must refresh the page and Load a new Application form in case the previous submission attempt was unsuccessful.

12. The System should save the Application Form and all attached documents into a Database.

13. The System should be able to immediately electronically forward the Application Form and the attachments and notify to the



S.No Functional Requirement Specifications – Application Request

Process Owner, as identified in respective processes.

14. The System should be able to generate a Receipt for the Applicant, and allow it to be printed.

15. The system should support multilingual interface (minimum Hindi and English) as per Localization and Language Technology

Standards for National e-Governance Plan defined in e-district guidelines.

4.3.4 Payment Component

This component deals with the receipt of payment by the CSC/e-District kiosk operator for a particular service. The service charges and the

revenue sharing model (between the participating departments, Implementation Agency of the CSCs & the CSC operators) for each of the

services will be decided at a later stage. Each of the stakeholders should get their share as per the revenue sharing model with respect to

each service.

S.No Functional Requirement Specifications – Payment

1. The system should provide for and allow financial transaction functions

2. The system should check for all details of the service request form before initiating the payment

3. The system should enable the payment option only when all the fields of service request forms are filled

4. The system should return back and highlight the field which have inconsistencies / error for user to rectify the error

5. The system should retain all the information of the service request form besides those having inconsistencies

6. The system should return back after successful checking of the fields with the prompt of confirmation to open the payment page

7. The system should open a new page for recording payment details against the service request

8. The system should allow payment to be registered on the service application request against the following –



S.No Functional Requirement Specifications – Payment

Payment against the service Payment against the dues / payments as defined under service charter of the specific service

9. The system should record and maintain all details of payment against a unique service application number

10. The system should be able to maintain all the payment records in a database and retrieve the same as and when required.

11. The system should be able to open a page with declaration on successful payment output

12. The system should able to record specific payment details on the service request form after successful payment has been made

13. The system should be such that it should allow for part payment function

14.

The system should be able to retrieve information of first part payment during the final delivery of service output for final payment as per the overall payment specified for service request

Unique application number for requested service CSC details and unique number for CSC

15. The system should be able follow the payment cycle as mentioned above for the final payment also

16. The system should be able to maintain all records of part payments as well as consolidated payment amount against the service request

17. The system should support multi-lingual interface (minimum Hindi, Oriya and English) as per localization and language

technology standards for National e-Governance plan defined in the e-District guidelines



4.3.5 Application Processing Component

This component deals with the processing of the application by the concerned authorities.- This component deals with the preparation of

the Case file, noting and forwarding of the same to the Approver.

S.No. Functional Requirements Specifications – Application Processing

1. The System should notify the forwarder once the request has been forwarded from the CSC/e-District centre

2. The system should provide inbox, forward, noting, view attachment facilities etc. to the forwarders

3. The system should allow defined users(identified as forwarders) to login to the system for approving the service request through

a valid user ID & password and bio-metric authentication

4. The system should show a login failure screen in case the user name and password are not matched by the application

5. The system should show a login failure screen in case the biometric authentication is not correct

6. The system should highlight the pending service requests for the users on entering the application after the log-in

7. The system should allow the forwarder to view the scanned supporting documents one by one, as uploaded by the Kiosk operator

8. The system should allow ‘zoom- in’ and Zoom-out’ facilities of the scanned documents for better viewing of the same

9. The system should allow the forwarder to reject the application incase the application does not contain the required supporting

documents

10. The system should request forwarder to give comments in case of non-acceptance or forwarding

11. The system should be able to generate an auto-file number before the forwarder forwards the application to the approving

authority

12.

The System should be able to generate an auto generated note sheet before the forwarder forwards the application to the

approving authority. Auto generated note sheet should not be editable and must record the full log of the said application users

from start to end with time stamp and IP records.



S.No. Functional Requirements Specifications – Application Processing

13. The system should allow the forwarder to add to the note sheet before the submission of the application form to the approving

authority

14. The system should ask for re-confirmation of the forwarder before actually submitting the request

15. The system should allow the forwarder to forward the applications individually and all at one go

16. The system should open a page informing the forwarder of successful completion of approval/rejection

4.3.6 Verification Component

This component deals with the allocation of the field verification officers by the approving authority, if the required details are not found in

the database or if the approving authority has doubts on the genuineness of the service requests.

S.No. Functional Requirements Specifications – Verification

1. The System should be able to allow the Process Owner/proper authority to enter query parameters to search any Database

connected with the System.

2. The System should be able to query the specified Database with the specified parameters and return the result of the same to the

Process Owner.

3. The System should be able to retrieve various information from the individual databases and aggregate it before displaying it.

4. The System should allow the Process Owner to electronically, using his digital signature, forward / delegate the Application to a

Field Officer or any other Officer registered with the System.

5. The System should be able decode the digital signed data and display the details of the signatory.

6. The System should allow the Field Officer to modify the Database as per the Access rights

7. The System should allow the Field Officer to electronically forward the Application back to the Process Owner after the details in

the Database have been updated.



S.No. Functional Requirements Specifications – Verification

8. The System should notify the Process Owner after the Field Officer has marked the Application back to him.

9. The System should allow the Process Owner to either Approve or Reject the application as per the Approval or Rejection

component, using his digital signature.

10. The System should ensure that a Reason for Rejection is entered by the Process Owner if he selects to reject an application before

accepting the Rejection.

11. The System should log all the electronic movements of the application with date and time details along with the sender’s and

receiver’s information.

12. The system should support multilingual interface (minimum Hindi, Oriya and English) as per Localization and Language

Technology Standards for National e-Governance Plan defined in e-district guidelines.

4.3.7 Approval/Rejection Component (Intermediary Approver and Final Approver)

This component deals with the approval/rejection by the concerned authority.

S.No. Functional Requirements Specifications – Approval

1. The system should allow defined users to login to the system for approving the service request through a valid user ID and

password and bio-metric authentication

2. The system should show a login failure screen in case the user name and password are not verified by the application

3. The system should intimate the users through predefined channels for pending approval on a daily basis

4. The pending approvals should highlighted for the users on entering the application

5. The pending approvals should be intimated to the users through SMS on pre-defined intervals until the same is addressed and

closed by the respective process owner

6. The system should have a provision to mark the approval of service request




7. The system should allow the user to digitally sign the documents one by one

8. The system should also allow the user the digitally sign all the selected approved service request at one go

9. The system should open a page for all approved service request with a prompt of digital signature in form a button to initiate

the process of digital signing

10. The system should reconfirm from the user for initiating the digital signing before actually initiating the process

11. Upon digitally signing the document, digitally signed document should be saved in the given repository for future references and

a hard copy of the same document will be provided to the applicant

12.

System should print the unique encrypted key/code on the hard copy of the digitally signed document such that the same

printed unique encrypted key/code can be used to check the authenticity of the document. The unique encrypted key/code will

be information of the authority who digitally signed the document in the encoded form

13. System should provide a link to the page where the user can enter the unique encrypted key/code printed on the hard copy of

the document to check for the authenticity of the document

14. On clicking the link, system should display the fields as described in the section Document retrieval form such that the user can

retrieve the required information

15. System should retrieve and display the digitally signed document on the user screen once the user enters the unique encrypted

key/code printed on the document

16. System should not allow the user to make any alteration in the digitally signed document or access the database on entering the

unique encrypted key/code

17. System should display an appropriate message in case of retrieval failure or any other communication failure or in case the

document could not be found due to any reason




18. The system should allow the user to terminate the approval process at any point of time during approval

19. The system should keep and maintain the data in a data repository (database) for all the approval made

20. The system should be able to keep the records of all transaction performed and link it to the unique code of digital signature

21. The system should open a page informing the user of successful completion of approval

22. The system should open a page at any point of process in case the process termination with the request to restart the process

23. The system should not allow the user to initiate the process of digital signature in case of no selection of pending service request

for approval

24. The system should not allow the user to modify the approval once it has been digitally signed

25. The system should not allow the user to delete any service request pending for approval at his end



4.3.8 Delivery Component

This component deals with the issuance of the final output from the CSC/e-District centre to the applicant, on producing the application

receipt issued to the citizen at the time of submission of application.

S.No. Functional Requirements Specifications – Delivery

1. The system should be able to provide delivery against all service request made

2. The system should be able to link delivery against specific service request through unique service application request number

3. The system should allow delivery only when the service request has been either approved / rejected

4. The system should allow only validated predefined users to log into the e-district application for retrieving the delivery against

the service request



S.No. Functional Requirements Specifications – Delivery

5. The system should ask for unique service request number / unique application number to retrieve specific service delivery

6. The system should provide for the printable version of the service output

7. The system should be able to print the unique kiosk number, unique application number on the every service output generated

through it

8. The system should be able to print the url of the site from where the content of the service delivery could be verified

9. The system should have adequate security features built in the architecture of the system to ensure that it cannot be

manipulated

10. The system should open new page specifying error in case of incorrect digital verification

11. The system should be able to maintain the database of the all the service delivery output in a logical manner to ease the retrieval

of the same as and when required

12. The system should have a life counter to keep log of all delivery made with specific association of unique service application

number and unique CSC number





4.3.9 Status Component

This component deals with the status tracking component with which the status can be tracked by the user and the citizens for the

requested service.

S.No Functional Requirement Specifications – Status Component

1. The system should have integrated auto status tracking features embedded in the overall architecture of the system

2. The system should keep track of all the service requests from the citizens along with the respective unique application reference

id generated at the time of the application receipt

3. The system should be available in public and administrative view

4. The system should be able to keep track of the status of all the service requests with the help of the respective unique application

reference id (application id) and map the current status with the pre-defined service level against each process

5. The system should be able to detect any change in the status of a given unique application reference id

6. In case there is a change in the status of a unique application reference id , the system should update the status information in

the database

7. The system should have provisions for intimating the applicant about the current status of his/her application through SMS

and/or Email especially if there is a change in the status with respect to the final delivery of the service

8.

The system should not provide details about the internal SLAs to the applicant and only provide update about the status with

respect to the final delivery. This feature should also allow the system to update the applicant if there is any change in the service

level of the final delivery

9. System should display the link for e-district portal from where the applicant can retrieve the status information by entering the

unique application reference id




10. The system should also allow the applicant to retrieve update about his/her service request through the web portal by entering

the reference id in the link provided on the portal

11. System should display the number from where the applicant can retrieve the status information by sending SMS along-with the

unique application reference id

12. The system should also allow the applicant to retrieve update about his/her service request by sending a SMS containing the

unique application reference id to the e-District application

13.

The system should display an appropriate message if the system is unable to retrieve the details due to any reason like

connectivity issues, maintenance issues, etc and also provide contact details of the system administrator and alternate link (if

available)

14. The System should have Side Menu on each page so as to reflect the contents of the containing directory, making it easier to

navigate the site and locate the link for retrieving update against a given reference id

15. The system should be adequate security features built in the architecture of the system to ensure that it cannot be hacked or

manipulated

16. The system should not allow the users to edit the details of the application upon retrieving the status update against a given

reference id

17. The System should allow the end user to print the status update information if the applicant is retrieving the status through the

portal or email

18. The System should have provision for Calendar System, which displays the dates and time of schedule events on a page formatted

as a standard monthly calendar

19. The system should have additional capability to integrate and extend portals to support a vast array of mobile devices in addition

to PCs (WAP enabled)




20. The system should have provisions such that the System Administrator can add/remove/modify the hierarchy of the

Government officials with adequate authentication mechanism

21. If there is any modification in the hierarchy of the relevant authority against a given service (in the system), system should

automatically map the escalation levels with the new hierarchy of Government officials



4.3.10 Monitoring Component (MIS)

This component deals with the generation of various reports at various levels who are involved in the delivery of services under the e-

District project.

S. No. Functional Requirement Specifications – Monitoring Component

1. The Process Owner should be able to use the e-District Application to query the Departmental Databases using the name or

other details of the applicant.

2. Should allow the e-District Application to retrieve various information from the individual databases and aggregate it

3. The application should support the monitoring in both the occurrence, when an event or time driven activity is triggered.

4. Should be able to retrieve all information about the status of the application form of the citizen.

5. Should be able to automatically generate the following reports to the concerned authorities at regular time interval:-

6. Should be able to generate Service Report on a regular time interval, this report should include the no of application received, no

of application processed, no of application rejected and the no of application under process.

7. Should able to generate SLA Report on regular time interval, this report should give information related to centre wise details of

no of SLA met and centre wise details of no of SLA breached.



S. No. Functional Requirement Specifications – Monitoring Component

8. Should be able to generate Performance Report on regular time interval, this report should give information related to centre

wise details of no of application processed against the no of application received.

9. Should be able to generate Payment Report on regular time interval, this report should give information related to centre wise

transaction, money collected and money deposited along with date and time.

10. Should be able to generate Inventory Report on regular time interval, this report should give information related to pre-printed

stationary used and issued to each centre.

11. Should be able to generate Attendance Report on regular time interval, this report should give information related to centre wise

attendance.

12. Should provide a search option to the authorized stakeholder so that he can search the information which should be sorted

according to Date, Department/Section, Service, District, Block, Sub Division, Tehasil, RI Circle etc

13. Should allow the stakeholder to review the progress report and give his comments online.

14. Should provide the facility to print and e-mail the report.

15. Should provide a printer – friendly version automatically for all pages.





4.3.11 Log in Component

S. No. Functional Requirement Specifications – Log In Component

1.

Should allow only the authentic users (Kiosk Operators, Department Officials) to login to the system through the use of:

User id and Password combination (for kiosk operators and verification officers)

Both (for Forwarders and issuing Authorities)

2. Should display the login page as the first page when the user enters the e district application.

User id & Password Combination

1. The user login and password both should be a combination of following: Alphabets (at least 1) , Special Character, Numeric

2. The user name and password should have a minimum of 8 characters each

3. Should not create duplicate user ids or passwords

4. Should not allow the user to have the same password for more than 30 days

5. Should generate alerts for password expiry from two days of actual expiry

6. Should not allow same user id and password

7. Should not allow blank spaces while setting user id or password

8. Should notify the user in case the Caps Lock is on

9. Should notify the use if Num Lock is on

10. Should generate user id based on the criteria of - Zone, district, Circle an SCA name, kiosk number

11. Should not allow a user who forgets the password to access the password retrieval mechanism

12. Should allow only the machines whose mach id is registered with the application enter the e district application

13. Should prompt the user to change the password in case of first login at the client side i.e. after imaging

14. Should give a welcome message once the user is able to successfully login to the e district application.



S. No. Functional Requirement Specifications – Log In Component

15. Should give an error message once the user provides wrong login information and ask the user to re log in.

16. Should block the user to enter into the e-district application if he puts in wrong login info continuously thrice.

17. Should support multilingual interface (minimum Hindi, Oriya and English) as per Localization and Language Technology

Standards for National e-Governance Plan defined in e-district guidelines

4.3.12 Service Specific Functionalities

The e-District portal is envisaged to be a single point information access for all the users under the e-District project through which the

citizens can avail the specific services and get the required information of those services that are proposed to be delivered under e-District

project. This portal will provide comprehensive information about the services of District Administration, its functions and also host links to

certain specific categories of services which can be availed through the Common Service Centres (CSCs)/e-District Centres. Service Specific

functionalities comprise of functions that are specific to service categories/services and deals with the day-to-day functioning of the same.

Indicative Functional Requirement Specifications for one of the Certificate is mentioned below. SPMU shall prepare the As-Is, To-Be

Process, FRS document for the services and the same shall be handed over to the selected bidder after approval to carry out necessary task

at his end.

S. No. General Functional Requirement Specifications

1 The system should be able to display Service related page through multiple routes, Service links, Information links, District links

2 The system should be able to identify the user logging into the system using the login component.

3 The system should be able to provide information to the citizens about the relevant services both in public as well as private

domain as per the ‘Information component’

Web access to information content in public domain




e-District application access to information content

4 The system should make available the latest copy of the Application Form online (24x7) as per the Form Availability component.

5 The system should be able to retrieve the service request form for a particular service

6 The system should allow the operator to fill in the online application on behalf of citizen availing the service as per the

‘application receipt’ component

7 The system should be able to generate a unique registration number during registering an applicant with the application.

8 The system should be able to identify the applicant uniquely based on this registration number for all future references.

9 The system should be able to record the payment made by the applicant against the service as per the Payment Component

10 The system should display a message regarding successful or unsuccessful completion of any transaction.

11 The system should refresh the page in case of failure in submission of service request

12 The system should be able to issue an acknowledgement receipt once the applicant is registered with the system

13 The system should be able to notify the concerned officer about the new application and this date and time must be logged

through e-District application

14 The system should allow concerned officials to view the service request only on authenticated login as per login process

15 The system should show service request to concerned Approving authority as pending for approval till it is marked for further

action

by default the system should be able to auto escalate within the service level as per the escalation matrix defined

16 The system should be able to auto generate MIS reports for the following officials as per the requirement–

District Collector, Sub Collectors/Tehasilders/BDOs, Other concerned authorities

17 The system should be able to support the status tracking as per the status tracking component




18 The system should be able to support the monitoring and reporting as per the monitoring and reporting component

19 The system should be able to detect changes in status and send status updates to the citizen as per the Status Tracking

component.

20 The system should be able escalate the application as per the Auto Escalation matrix, defined, by notifying the next level of

authority and sending him a copy of the application.

21 The system should be able to maintain all records for the login sessions with date and time

22 The system should be able to provide date and time stamping for all transactions done with digital signature

23 The system should have a facility for forwarding of the application, with remarks and digital sign of the sender, to any person in

District administration registered with the System.

24 The system should support multilingual interface (minimum Oriya, Bengali, Hindi, English) from the first day of its operation, as

per Localization and Language Technology Standards for National e-Governance Plan defined in e-district guidelines.



4.4 Bill of Material Summary

4.4.1 Requirement at Field Level Offices

Item Name Dist. Magistrate

Office

Sub

Collector

Office

Tahsildar

Office

BDO

Office

Total

Nos.

Laptop 56 51 536 266 2699

Desktop 224 102 536 532 1394

UPS 224 102 536 532 1394

Printer 140 102 536 266 1044

All in one 28 0 0 0 28

Scanner 56 102 536 266 2750

Biometric Device 280 153 1072 798 4093

Antivirus 280 153 1072 798 4093

24 Port Managed LAN

Switch

56 51 268 0 375

9 U Networking Rack 56 51 268 0 375

UTP cable CAT-6 (Box

of 305 Mtrs)

56 51 268 266 641

Jack Panel 24 Port

CAT 6

56 51 268 0 375

Information Outlet

CAT6

420 255 1340 1330 3345

Surface Mount Box

Single

420 255 1340 1330 3345

Mounting Cord 7 Ft.

CAT 6

420 255 1340 1330 3345

Mounting Cord 3 Ft.

CAT 6

420 255 1340 1330 3345

6 Core Multimode

Fiber with necessary

terminator

14000 Mtr 0 0 0 14000

Mtr

P.S.: Number of equipment’s/peripherals displayed in the above table may vary during the actual implementation in the field. In case of variance the actual requirements needs to be presented in front of the SDA. After approval, the unit price quoted by the selected vendor will be taken into consideration for payment. Also, as per requirements, the distribution of materials across the offices may also vary during the actual course of implementation.



4.4.2 Requirement at SDC

Sl No. Item Total Qty (Q)

1 Server For Helpdesk and SLA 2 Nos.

2 Server for Antivirus 1 Nos.

3 Software for Helpdesk, SLA & Asset Management 1 Nos.

4 Antivirus Software solution 1 Nos.

5 42 U Server Rack 1 Nos.



4.5 Technical Specifications

4.5.1 Server for Web, Database, Application

Following numbers of servers were procured during pilot implementation of eDistrict Project.

Sl.No Description of Item Quantity Make/Model

1 Web Servers 1 IBM 8204 Model E8A

2 Application Servers 1 IBM 8204 Model E8A

3 Database Servers 2 IBM 8204 Model E8A

The specifications of the existing server are as follows. The bidder has to use the existing server.

If the Bidder feels that any hardware up-gradation is required in the existing servers, then they

have to propose the same and provide commercial proposal for the same in the format given in

Vol-I: Annexure 2.3.

Specification of each Server

Specified Components of Server Qty.

RIO-2 (Remote I/O-2) Cable, 3.5M 1

146GB 15K RPM SAS Disk Drive 2

4096MB (2x2048MB) RDIMMs, 667 MHz, 1Gb DRAM 4

2-core 4.2 GHz POWER6 Processor Card 2

4MM 80/160GB TAPE, SAS, (CADENZA-4 SAS) 1

Dual-Port 1Gb Integrated Virtual Ethernet Daughter Card 1

IBM 2-Port 10/100/1000 Base-TX Ethernet PCI-X Adapter 1

4 Gb Dual-Port Fibre Channel PCI-X 2.0 DDR Adapter 1

SATA Slimline DVD-RAM Drive 1

2-Port 10/100/1000 Base-TX Ethernet PCI Express Adapter 2

4 Gigabit PCI Express Dual Port Fibre Channel Adapter 1

Power Cable -- Drawer to IBM PDU, 14-foot, 250V/10A 1

Power Cord (9-foot), Drawer to IBM PDU, 250V/10A 1

IBM/OEM Rack-Mount Drawer Rail Kit 1

IBM Rack-mount Drawer Bezel and Hardware 1

Power Supply, 1700 Watt AC, Hot-swap, Base and Redundant 2

PowerVM Express 4

DASD/Media Backplane for 3.5 DASD/SATA DVD/Tape 1

Three Years Onsite Comprehensive Warranty 1



4.5.2 Specification for servers for Helpdesk, SLA and Antivirus

4.5.2.1 Specification of Blade chasis

Feature Specifications

Make Must be specified

Model Must be specified. Tower Model Required. Must be specified. All the relevant product brochures and manuals must be submitted.

Form Factor

Up-to 10 U Form factor per chassis with all redundancy features (Hard

Drives, Power, and Cable Management). The requisite number of

Enclosures to be configured to populate the Servers and

Storage/Expansion Units

Blade Bays Blade Chassis to accommodate minimum of 8 hot pluggable blade

servers with SAS HDDs.

Chassis Feature Dual network connectivity for each blade server for redun-

dancy should be provided.

Backplane should be completely passive device. If it is active,

dual backplane should be provided for redundancy

Should have the capability for installing industry standard

flavors of Windows, Linux, Unix, Solaris for x86 Operating

Environments

Single console for all blades in the enclosure or KVM Module

DVD ROM can be internal or external, which can be shared

by all the blades allowing remote installation of S/W and OS

Minimum 2 external USB connections functionality

Ethernet Switch

Modules

Two hot-plug, redundant 1Gbps Ethernet module which enable

connectivity to Ethernet via switch. Switch should be

Internal/external. The number of Ethernet ports should be

sufficient to connect fully populated chassis being offered to

network.

SAN Connectivity Two hot-plugs, redundant 4 Gbps Fiber Channel for connectivity to

the external Fiber channel Switch and ultimately to the storage

device.

Redundancy Mechanical Devices such as Hard Disks, Fans and Power Units should be

completely Hot Swappable and Redundant to ensure High Availability

Blade Management Systems Management and deployment tools to aid in Blade Server

configuration and OS deployment,

Remote management capabilities through internet browser

Blade enclosure should have provision to connect to display con-

sole / central console for local management like trouble shooting,

configuration, system status / health display

Power Hot Swap redundant power supplies to be provided

Power supplies should have N+N. All Power Supplies modules

should be populated in the chassis

KVM To be enabled Virtually over IP for Remote Access



4.5.2.2 Specification of Servers

Features Specifications Required


Model Must be specified. Tower Model Required. Must be specified. All the relevant product brochures and manuals must be submitted.

Part No Must be specified for all the required components

CPU Two numbers X86 based Processor. Processor Core Per CPU should

be Minimum Six. The Frequency should be minimum 2.0 GHz.

Processor should be latest series/generation for the server model

being quoted

Chipset Suitable Processor OEM motherboard/chipset

Form factor Half/Full Height Blade with I/O connectivity to backplane

Memory 32 GB ECC DDR3-SDRAM DIMMs

Memory Expandability Minimum 128 GB

Controllers Integrated SAS Raid Controller with RAID 0, 1

Bays Dual 2.5” SAS Hard Disk bays

Hard Disk Drives Two 146 GB 2.5” SAS Hard Disk Drive hot swappable system disk

with mirroring using integrated RAID 0,1 on internal disks

Ethernet Adapter Dual Port 1000BASE-T Gigabit Ethernet Adapter

SAN Connectivity The Blade should have redundant 4/8 Gbps Fiber Channel HBA (For

Application and Mail Messaging)

I/O Expansions I/O expansion slot for up gradation of Ethernet Adapter

Power Supply From the Blade Chassis

System Management

and Diagnostics

LED lights indicating failing component and on-board diagnostics

(via on-board system management processor)

Software Server Management software with the device drivers

OS Compatibility Microsoft Windows Server latest version Standard Edition (32 bit

and 64 bit)

Microsoft Windows Server latest version Enterprise Edition (32 bit

and 64 bit)

Red Hat Enterprise Linux latest version (32 bit and 64 bit)

Red Hat Enterprise Linux latest version (32 bit and 64 bit)

SUSE LINUX Enterprise Server latest version (32 bit and 64 bit)

SUSE LINUX Enterprise Server latest version (32 bit and 64 bit)

Warranty 3 year comprehensive warranty



4.5.2 Desktop

Features Specifications Specifications Offered

Compliance Deviations if any

Make Must be specified Model Tower Model Required. Must

be specified. All the relevant product brochures and manu-als must be submitted.

Part No. Must be specified for all the required components

Processor Intel Core i-3 Processor or equivalent AMD Processor, Minimum 3 GHz, 3-MB L3 cache.

Motherboard Intel Q57 or better OEM Chipset or OEM mother board

Bus Architecture

Integrated Graphics, Integrated (on board) High Definition Audio controller with internal speaker, 2 PCI slots

Bays 2x Internal 3.5” bays, 2xExternal 5.25” bays & 2xExternal 3.5” bays

Memory 4 GB DDR3 SDRAM

Hard Drive 320 GB SATA HDD

Removable drive

52 X Sata CD ROM drive

Network Integrated 10/100 Mbps Ethernet Adapter (RJ-45), PXE support

Key board USB 104 keys keyboard (Same make as PC) with bi-lingual keys (English and local language of the State) compliant to Enhanced Inscript Keyboard based on Unicode version 6.0 or later.

Mouse 2 button optical wheel mouse

Monitor 17” TFT Color Monitor

Interface 1 serial, 5 USB (Minimum 2 in front), 1 PS/2 Keyboard, 1 PS/2 Mouse, VGA, audio ports for Microphone & headphones in front.

OS Certification

Microsoft Windows

OS Windows 7 business Edition or higher edition preloaded

Certification For OEM:ISO 9001 and 14001. For quoted Model: FCC, UL, Energy Star 5.0, DMI



4.5.3 Laptops



Make Must be specified Model Must be specified. All the rele-

vant product brochures and manuals must be submitted.

Part No. Must be specified for all the required components

Processor Intel Core i-3 Processor or equivalent AMD processor, Minimum 3 GHz, 3-MB L3 cache

Motherboard Compatible motherboard to support the processor and memory. Motherboard from the original OEM.

Memory 4 GB DDR3 SDRAM

Hard Drive 320 GB SATA

Removable drive

Integrated DVD R/W

LAN Network Integrated 10/100 Mbps Ethernet Adapter (RJ-45), PXE support

Wireless Support

Integrated 802.11 b+g 54 MBPS Wireless LAN adapter

Key board Spill-resistant keyboard (minimum 86 keys) with bi-lingual keys (English and local language of the State) compliant to Enhanced Inscript Keyboard based on Unicode version 6.0 or later.

Graphics Intel Graphics Media Accelerator X3100, with up to 384 MB shared system memory

Display 14.1" WXGA Active TFT (1280X800) & with Integrated WEB CAMERA (1.3 MP)

Interface 3 USB 2.0, 1XLine in , 1X MIC ,1XRJ11 Modem, 1XRJ45 LAN, 1X External VGA , 1X DC In

Power Universal DC Adapter

Battery 6 Cell Li Ion Battery

OS Certification

Microsoft Windows

OS Windows 7 Business Edition or higher edition preloaded



4.5.4 Scanner

Features Specifications

Specifications Offered


Make Must be specified Model Must be specified. All the

relevant product bro-chures and manuals must be submitted.

scanner type Flatbed input modes front panel scan, copy

buttons,

speed preview speed: 10 seconds Scan speed: Photo to files: 29 secs; Text to document: 26 secs

Résolution 4800 dpi optical resolution, 4800 x 9600 dpi hardware resolution,

Imaging Technology

CCD

bit depth 48-bit scaling 10 to 2000% max document size

220 x 300 mm

interface and operating system requirements

USB – compatible with USB 2.0 Windows 7 Home and Professional Edition

power Universal AC adaptor: 100 to 240 VAC (+/- 10%), 50/60 Hz (+/- 3Hz) input (according to configuration), 12 VDC, 1.25 Amp output, Energy Star™ compliant



4.5.5 Laser Jet Printer, Scanner, Copier all in one Device






Print speed Up to 27 ppm letter Resolution Printing: upto 1200 x

1200 dpi Copying: up to 600 x 600

dpi Scanning: up to 1200 x

1200 dpi

Printing Features

Manual duplex and book-let printing

N-up printing, Collation, Watermarks, Economic mode for toner

savings

Copying Features

1 to 99 multiple copies reduce/enlarge from 25

to 400% 2-up or 4-up allowing 2

or 4 pages to be copied onto 1 page

Contrast (light-er/darker),

resolution copy quality (draft, text, mixed)

Scanning Features

Flatbed scanner up to let-ter, A4 size;

supported file types: JPEG, TIFF, PDF, GIF, and BMP

Should be able to scan Legal Documents

Control panel

2-line LCD text display, Asian character support, 16-character display, menu and navigation

buttons, copy control buttons, cancel button

Memory 32 MB RAM Paper Handling Tray

10-sheet priority input tray,

250-sheet multipurpose input tray,

125-sheet output bin, manual two-sided print-

ing






Paper Size 76 x 127 mm (3 x 5 inch-es) to 216 x 356 mm (8.5 x 14 inches);

letter, legal, index cards, postcards; A4, A5

Interfaces Hi-Speed USB 2.0 port, Ethernet port

operating systems support Required

Windows 7 Home and Professional Edition ; Windows Vista, Linux

Power 220 to 240 volts (±10%), 50/60 Hz (±2 Hz) Input Power port with required English power chord



4.5.6 Laser Printers






Print speed Up to 14 ppm A4 &letter Resolution Up to 600 x 600 dpi Printing Features

Manual duplex print-ing

N-up printing, Economic mode for

toner savings

Memory 2 MB RAM Paper Handling Tray

150-sheet adjustable main input tray,

100-sheet output bin, manual two-sided

printing

Paper Size A4, A5, A6, B5, letter, legal, postcards, envelopes

Interfaces Hi-Speed USB 2.0 port, operating systems support Required

Windows 7 Home and Professional Edition ; Windows Vista, Linux

Power 220 to 240 volts (±10%), 50/60 Hz (±2 Hz) Input Power port with required English power chord



4.5.7 UPS – 1 KVA offline UPS

Parameter Specifications Specifications Offered



Model Must be specified. All the relevant product brochures and manu-als must be submitted.

Type Line-interactive

Capacity 1 KVA

Input Voltage Range 90 – 280 V AC

Input Frequency 50 Hz +/-10%

Output Voltage 220 V +/- 10% (under line mode)

220 V +/- 5% (under battery mode)

Output Frequency 50 Hz +/- 1% (under battery mode)

Noise < 40 db at 1 m

Protection Overload, Short Circuit, Low Battery

AVR Built in Automatic Voltage Regulator (AVR)

Indicators LED indicators for AC Mains, DC, Load on Mains/Battery

Battery Type & back-up time

Batteries shall be of Sealed Maintenance Free (SMF) type The system must be capable of providing requisite battery back-up time of 60 minutes using SMF Batteries as per VAH rating below : (Minimum VAH for 60 minutes back-up = 1008 VAH) Total number of batteries offered should be clearly mentioned. Voltage of each battery offered should be clearly mentioned. Ampere-Hour rating of each battery offered should be clearly mentioned. Total Volt-Ampere-Hour rating of the Battery Bank Offered



Parameter Specifications Specifications Offered


should be clearly mentioned.

Recharge Time to 90% capacity

3 to 4 hours

Ambient Conditions Temperature: 0 to 45 deg Celsius Humidity: upto 95%

Certifications ISO 9001



4.5.8 9 U Rack

Feature Specification Specifications Offered



Model All the relevant product

brochures and manuals

must be submitted.

Dimensions 600(w)x 530(d)x 9U(h)

Weight Capacity 132 lbs (60 kg)

Side doors Complete knockdown

format for easy

installation & later

maintenance;

with lock & key

Ventilation Standard with one side

exhaust fan



4.5.9 Biometric Device

Feature Specification Specifications Offered





must be submitted.

Identification

Time (s)

<=2 Sec

Enrollment Upto ten finger prints per

user

Fingerprint

placement

Any Angle (360°)

FAR <0.0001%

FRP <1%

Transaction

storage

100,000(TA 102),

120,000(TA 103)

User Capacity 1,500 templates approx

Ethernet 10/100 Base T(UDP)

Serial

Communication

(bps)

9600/38400/115200(Rs

232/Rs 485)

Operating

Temperature

(0°C)

0-45

Operating

Humidity (%)

20 -80

Display

Language

English

Operating

Voltage

5 VDC



4.5.10 24 Port Managed LAN Switch






must be submitted.

Architecture The switch should have

24 x 10/100/1000BaseT

ports plus 2 x 1000BaseX

ports

Should support 1000

Base-SX, LX Mini-GBICs

Should have a minimum

of 14 Gbps switching

capacity

Should have switching

throughput of 20 million

pps

MAC Address table size of

8,000 entries

All the switch ports

Should offer non-

blocking, wire speed

performance

Resiliency and high availability

Should support IEEE

802.3ad Link

Aggregation Control

Protocol (LACP)

Should support IEEE

802.1s, IEEE 802.1d STP

& IEEE 802.1w RSTP

Layer 2 switching

Should support IEEE

802.1Q VLANs, up to 256

port-based VLANs

Should support GVRP or

equivalent

Security Should support MAC and

IP-based ACLs and Time-

based ACLs

Should support IEEE

802.1X user

authentication

Should support Web-

based authentication &

MAC-based





authentication

Should support

management access

securely encrypted

through SSL and SNMPv3

Convergence and QoS

Should support IEEE

802.1AB Link Layer

Discovery Protocol

(LLDP)

Should support LLDP-

MED

Should support IEEE

802.1p Traffic

prioritization

Should support IP

multicast (data-driven

IGMP) to automatically

prevent flooding of IP

multicast traffic

Should support rate

limiting

Manageability Should support

SNMPv1/v2c/v3

Should support Web

Interface for switch

configuration

Should support Port

mirroring

For each hardware, Bidder should provide the following information in a table

i. Reference of the server/storage information in the Submitted Proposal (Please provide page

number/section number/ volume)

ii. Services proposed to be hosted on the Server

iii. Quantity

iv. Year of Introduction

v. Operating System along with version (if applicable)

vi. Processor and Number of Cores Offered (if applicable)

vii. Architecture (RISC/EPIC/CISC) (if applicable)

viii. RAM/HDD/LAN Ports/ HBA (as relevant)

ix. Additional Information as required to indicate the compliance to the requirements in the RFP

(ex, Capacity, Disk Space) (if applicable)



Important Note for bidders:

i. It is mandatory to furnish complete technical specifications of the hardware & peripherals being

offered, strictly as per the format, provided here. Correct technical information of the product

being offered must be filled in.

ii. Filling the technical specifications/ information in the format using terms such as ‘OK’,

Accepted’, ‘Noted’, ‘As given in Brochure/ Manual’, ‘Complied’ is not acceptable. The offers not

adhering to these guidelines are liable to be rejected.

iii. All relevant product information such as user manuals, technical specifications sheet etc. should

be submitted along with the offer. Failure to submit this information along with the offer could

result in disqualification of the bid.

iv. In case any technical variance is offered, the same must be specified under the "Deviation, if

any" column.

v. For each item, the bidders should propose only one product.

vi. These specifications should be considered as the minimum to be fulfilled.

4.5.11 Specification of SLA and Helpdesk Software

Service Desk Functional Specifications

The proposed solution shall provide a web based service support system to automate inci-

dent, problem, change, knowledge management, interactive support, self-service and ad-

vanced root cause analysis

The proposed solution shall support request management, problem management, configu-

ration management and change order management.

The proposed solution shall provide end-users the flexibility of logging, viewing, updating

and closing service requests and incidents using a web-based interface.

The proposed solution shall provide administrators (service desk analysts) the ability to use

a fully-functional web-interface and should provide power-user tips for frequently used

functions.

The proposed helpdesk solution must have the ability to track work history of calls to facili-

tate troubleshooting.

The proposed solution shall provide the facility to register incidents via e-mail.

The proposed solution shall provide classification to differentiate the incident via multiple

levels/tiers of categorization, priority levels, severity levels and impact levels.

The proposed solution shall provide a web-based knowledge base that assists in finding,

organizing, and publishing knowledge articles that aid in self-service & faster turn-around

time.

The proposed solution shall allow analysts to create knowledge articles based on resolved

incidents/problems and shall also allow end-users to submit knowledge for consideration

(after appropriate approvals).



The proposed solution shall allow expert analysts to build knowledge trees that guide the

user through a series of questions and potential answers until they reach a resolution. This

functionality shall be achieved without the need for specialized scripting or programming

skills and should only involve an analyst working with a subject expert to create a tree de-

sign.

The proposed solution shall provide status of registered calls to end-users over email and

through web.

The proposed solution shall provide a fully functional CMDB (Configuration Management

Database) as an integral part of the service desk and should be accessible from the same in-

terface.

The proposed solution shall allow the IT team & Change Advisory Board to visualize CI re-

lationships with a specified number of relationships on single window.

The proposed solution shall support version control for defined Configuration Items.

The proposed solution shall provide multiple CI families, classes and relationships out-of-

box to reduce implementation time.

The proposed solution shall provide agent-less remote administration tools (chat, soft-

ware/hardware inventory, file transfer, registry and file-system editing, screenshot capture,

remote control and reboot/reconnect) to the analyst for faster resolution of desktop related

incidents.

The proposed solution shall automatically log all the remote desktop sharing activities into

the service desk request/incident.

The proposed solution shall provide a distributed and scalable architecture that caters to

growth in number of analysts, end-users and call volumes.

The proposed solution shall provide bi-directional integration with the proposed infra-

structure management solution (eg. An event/alarm in the infrastructure management so-

lution shall automatically create an incident in the service desk and the incident number

shall be displayed against the alarm in the event console. If the alarm is cleared, the incident

shall be closed automatically)



Integrated End-to-End Service level Management Solution

The proposed solution must provide Dashboard-based SLA performance management.

The proposed solution must provide an Integrated Dashboard integrated with the SLA

Management module shall be available within the SLM tool

The system must provide the capability to calculate the current and contractual level near

real-time. The system must also enable features around collaborative communication, e.g.

like notes (private and shared), comments, history of actions, etc

The SLM Dashboard should provide user based reports and dashboard elements and ena-

bles the configuration of individual threshold levels.

The proposed solution must enable creating and managing end-to-end business driven

SLAs for managing and ministering an efficient IT service delivery.

The proposed solution must be User-friendly. Business users with little technical knowledge

shall be able to manage SLAs & metrics (Service Level Obligations and Service Level Indica-

tors) using a user-friendly graphical user interface

The proposed solution must provide an SLA repository / End-to-End SLA Management.

Solution must be able to provide a common repository for all agreements across organiza-

tion, whether they are customer facing SLAs, internal SLAs/OLAs, or vendor underpinning

contracts.

The proposed solution must Support SLA Lifecycle Management including support for Ver-

sion Control, SLA Status, SLA Effectively and Audit Trail. The proposed Solution shall man-

age the SLA state in the life cycle (e.g. draft, current, etc.) and be able to support Effectively

dates (i SLA start date and end dates) as well as periodical revisions to the SLA (new tar-

gets, new metrics etc.).

The proposed system shall track all changes made and allow users to go back to a previous

version of a SLA.



4.5.12 Specification of Antivirus software

Anti-Virus software to protect LAN Servers

The software should be with following functionality:

Shall provide domain based central management – organize and manage computers in logical

domains

Shall support pattern file rollback – shall be able to return to past pattern file if problem with

new file

Shall be able to scan through minimum of 19 types of compression formats and shall be able to

scan through 20 levels of compression

Able to perform different scan Actions based on the virus type (Trojan/ Worm, Joke, Hoax, Vi-

rus, other)

The solution should support true file type or true file type group scanning and blocking

Shall be able to remotely uninstall the antivirus software

Shall support the following platforms: Windows NT/2000 (x86), Netware, Linux (real- time

scan), EMC Celerra & NetApp Filer

The solution shall be able to block specified ports and Network shares on all the servers to stop

the proliferation of Network viruses which use ports to spread after entering the Network

Shall be certified by the following vendors & products:

o Microsoft Windows 2000 Server, Advanced Server & Datacenter Server

o Citrix Metaframe Server

o IBM xSeries Server

o HP/Compaq Datacenter Server

System does not require restarting of the Virus Scanning service after a Pattern update

Shall be able to scan Object Linking and Embedding (OLE) File

Anti-Virus software to protect Desktops on the network

The software should be with following functionality:

Must have a Personal Firewall to protect the clients from common network based hacker at-

tacks and Intrusion detection features

Must have enhanced Spyware/Adware detection capabilities in real-time

Must have exclusion list to exclude Spyware/Adware from scanning

Virus Outbreak Monitor and Firewall Outbreak Monitor to notify the Antivirus serv-

er/Administrator when the client detects excessive network traffic or log counts from

IDS/personal firewall exceed certain thresholds respectively

Should have flexible port blocking capabilities in the Personal Firewall component which can

permit or deny traffic from a specified port or range of ports



The Client firewall should use stateful inspection to scan network traffic for profile and security

level; filters connections by IP address, port number and protocol

Should support Network Virus Scanning to detect and drop infected packets from the network

layer

Must integrate with Checkpoint VPN 1 Secure Client to ensure that all Remote clients connect-

ing via a VPN comply with the company’s antivirus policy

Outbreak Prevention option to block specific shared folders, ports, and to deny write access to

specified files and folders on selected clients from the central console during a virus outbreak

Should be able to specify CPU usage during file scans

Should have a feature to consolidate virus logs resulting from recurring infections made by the

same network virus and send them to the Antivirus server

Should provide Comprehensive Support for Network Admission Control

Should be able to deploy the Admission Control Agent along with the antivirus client deploy-

ment

Should come in-built with a Policy server which will have the ability to configure settings to

perform actions on at-risk clients to bring them into compliance with the organization’s antivi-

rus policies

Should be able to deploy the Client software using the following mechanisms:

o Support MSI in Client Packager tool

o Notify Clients to install via E-Mail

o Client Packager tool for client local install

o Web Install via Active X control

o NT Remote Install

o Via Login Script

Through disk imaging

Support MS Systems Management Server (SMS) There should be only a one-time deployment of the client Antivirus components (Antivirus,

Firewall, Spyware and Damage Cleanup) rather than deploying it separately

The update component should download all components required including the pattern file,

scan engine, program files, damage cleanup template/engine, Spyware pattern, firewall engine

and network worm engine instead of downloading every component separately

The Server component should have the flexibility to update itself from multiple update sources

Clients should get virus updates, Spyware/Adware pattern updates, network worm updates and

personal firewall updates from a single server Antivirus server

Clients should automatically look at another update source to get updates if the primary antivi-

rus server is not available



Solution must allow specified clients to act as Update Agents (sources for updated components)

so other clients can receive updates from these clients to ensure effective use of corporate

bandwidth

Should provide with Web-based centralized management through which all the clients can be

centrally managed / configured for antivirus and firewall policies

Secure remote access via Web browser (SSL-enabled)

Should have an integrated feature to back up the client’s database

Customizable client alert message for virus detection and Personal Firewall

Should generate Virus activity log, update log, Personal firewall/intrusion detection log, network

virus logs, Client connection status log and Server system event log and should be able to send

notification to the infection source

A quarantine manager to set the capacity of the quarantine folder and the maximum size of the

quarantined files

Should have a feature to scan and detect for vulnerable systems in the network and remotely

deploy the client software to them automatically

Able to automatically uninstall existing antivirus software at the desktop

Should have an option to reserve specified amount of space on the client only for updates

Solution should be capable of protecting itself from virus attacks

Protect the following Operating Systems:

o Windows Server 2008

o Windows 7/8 Desktop

o RHEL Linux Enterprise server

o ORACL Linux Enterprise server

o SUSE Linux Enterprise server

HTTP Gateway level Antivirus and URL Filtering solution

The solution should be a single product solution to provide HTTP & FTP Gateway level Antivi-

rus. The product should be software based solution

The solution should support Microsoft Windows & Linux platforms

The solution should be a fully integrated solution designed to block Web-based threats, includ-

ing Viruses, Trojans, Worms, Phishing attacks and Spywares / Adwares

The solution should be capable of preventing installed Spyware from sending confidential data

via HTTP

The solution should be capable of working in the following configurations; (1) As a standalone

proxy, (2) Integrated with upstream proxy servers, (3) Integrated with ICAP-compliant cach-



ing servers, Network Appliance, or BlueCoat, (4) It should be capable of working as a transpar-

ent proxy utilising WCCP or a Load balancer, (5) Reverse proxy

The solution should support True File type Scanning

The solution should be capable of automatically blocking Infected URLs

The solution should be capable to taking action on password-protected or encrypted files

The solution should Encrypt the Quarantined files

The solution should have the following options for handling large files: Scan first, Deferred Scan

and Scan behind

The solution should be able to selectively bypass certain MIME content types

The solution should be capable of automatically sending a customized email message on detect-

ing malicious code in a file, which a user requested

The solution should be able to define Scan limits for compressed files based on the following cri-

teria: Number of files inside the compressed file, Decompressed file size, Decompression per-

centage and decompression layers

The solution should have Inbuilt logging and reporting capabilities (Reports by User/Group,

Consolidated user reports, Blocking events report, traffic report etc.)

The solution should log performance statistics, including CPU usage, Memory usage, and num-

ber of transactions processed

The solution should support for Remote Installation

The solution should support SNMP based System and Event Notifications

The solution should have the capability to control access to the IWSS server based on IP ad-

dresses

The solution should be able to Rollback the pattern file update if required

It should allow setting of URL policies by category, group, or user and control access by time of

day, day of week, and bandwidth quotas to improve network performance, reduce legal liability,

and increase productivity

It should support Microsoft Active Directory, Linux OpenLDAP Directory and Sun Java System

Directory Server via LDAP, enabling IT administrator to easily set policies and assign rules for

single PCs or groups

Support for Customizable URL access/deny Rule Sets and additional customizable allow/deny

categories & Sites

URL, Internet resource access restriction capability based on Network, IP Address, Users,

Groups etc.



4.6 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 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.

Technical Solution Architecture Requirements

1. The e-District solution needs to be architected using robust and proven software and

hardware technologies like Service-Oriented Architecture (SOA) and open industry standards.

2. The solution architecture should be built on sound architectural principles enabling fault-

tolerance, high-performance, and scalability both on the software and hardware levels.

Software Architecture Requirements

1. Software architecture must support web services standards including XML, SOAP, UDDI and

WSDL

2. Software architecture must support appropriate load balancing for scalability and

performance

3. Software architecture must support flexibility in adding functionalities or applications.

4. 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.

5. Software architecture must support trace logging, error notification, issue resolution and

exception handling.

Hardware Architecture Requirements

1. Hardware architecture at SDC must provide redundancy and high availability capabilities at the

hardware level; this includes servers, etc. However, the hardware infrastructure for the DRC

can be as per the SDC specifications.

2. All servers and systems must be configured with no single point of failure.

3. Hardware architecture should be capable of consolidating several applications / workloads in a

number of servers as required.

4. Servers must be placed within proper security infrastructure for the Solution.

5. Hardware architecture must support existing Storage Area Network (SAN) & backup solution

(at SDC)

6. The technical solution architecture for e-District should be sound and complete with high

performance, redundancy, and scalability.

Development, Testing, Staging, and Production Requirements

1. 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 Solution.



2. 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.

3. The test, development, and staging environment should include required workstations,

desktops, and tools appropriate to support development, testing, and staging, and deployment

tasks.

4. The development, test, and staging hardware environments must include similar operating

systems, software components, products, and tools to those of production environment.

5. The development, test, and staging environments should be independent logically and

physically from the production environment and of each other.

6. The development environment should be used for development and should be configured to

allow access for developers’ workstations.

7. The staging environment should be used for functional and user acceptance testing, stress

testing, and performance benchmarking.

8. The test environment should be used as a testing environment of e-District Solution and its

software components and products. The test environment should be a scaled-down

configuration of the production environment.


1. A secure solution should be provided at the hardware infrastructure level, software level, and

access level.

2. Authentication, Authorization & Access Control

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.

3. Encryption Confidentiality of sensitive information and data of users and portal information should be

ensured.

4. Appropriate mechanisms, protocols, and algorithms necessary to protect sensitive and

confirmation data and information both during communication and storage should be

implemented.

Monitoring and Management Requirements

1. The e-District Solution should provide monitoring and management of the entire Solution

including all software components and application.

2. The monitoring and management should monitor health of software and hardware

infrastructure running the e-District Solution covering operating system, database, software

components, applications, servers, and other related software and hardware components. It

should provide proactive monitoring, alerting and reporting.

Performance and Scalability Requirements

1. The design of the e-District Solution should be scalable to handle increasing number of users.

2. e-District Solution should provide measurable and acceptable performance requirements for

users, for different connectivity bandwidths.

3. The e-District solution should provide optimal and high performance Portal Solution satisfying

response time for slow Internet connections and different browsers.



Implementation Requirements 1 The SI will be required to deploy manpower and other project resources as per the terms &

conditions of the Contract

2 The SI will be required to work closely with the SDA and perform detailed functional

requirements and analysis of e-District Solution to confirm and document functional / system

requirement specifications for the portal and its applications to fulfill its objectives.

3 The SI will be expected to carry the complete implementation and deployment of the e-District

within the timelines specified in the RFP.

4 The SI is expected to develop, test, stage, and deploy all functional modules of the e- District

software and any hardware components of technical & functional requirements

Project Management 1 Selected bidder is required to provide an implementation plan illustrating all functional analysis,

development, testing, staging, and deployment activities

2 Selected bidder is required to specify and describe the different phases and activities of the

project. It is very important for the SDA 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.

3 Selected bidder is required to use standard project management tools such as 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 Deliverables

Functional & Re-quirements 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 Docu-ments of Software solutions

Design Specifications Docu-ments of Hardware solutions

User Interface Design Specifications

Integration Design Specifica-tions

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 hard-

ware Functional modules & Portal

Solution Problem reporting

Testing System Testing Integration Testing Stress Testing Load Testing User Acceptance Test

Results

Complete Test Cases Test Plan User Acceptance Criteria Problem reporting Problem resolution testing Data Migration Testing



Completed Test Cases Data Migration tests Documentation

Deployment Training courses and sessions

Operations Planning User Manual Operations Manuals

Knowledge Transfer and training plan

Operations Plan Operations Policies and

Procedures

4 Selected bidder is required to describe in detail project management processes, methodologies

and procedures.

5 Describe what SDA resources will be necessary for the project to succeed.

6 Describe how SDA management will receive up-to-date reports on project status.

7 Describe the change management procedures to handle such things as “out-of-scope” requests

or changing business needs of SDA while the project is underway.

8 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.

9 Describe what quality assurance processes, procedures, formal reviews, etc. will be in place.

10 Describe the proposed conflict resolution / escalation process between the Bidder and SDA to

handle project or contractual disputes.

11 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.

12 Selected bidder shall provide a comprehensive warranty that covers all components after the

issuance of the final acceptance of e-District. 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. Upon final acceptance of the SDA, all OEM

warranties will be transferred to the SDA at no additional charge. All warranty documentation

(whether expired or not) will be delivered to SDA at the issuance of the final acceptance

certificate

13 Selected bidder is required to provide Premium Level warranty and support through the

vendor for all hardware and software used for e-District. Selected bidder’ warranty must cover

all equipment and work activities contained in the contract against all design, manufacturing,

and environment faults until the issuance of the final acceptance. 14 Selected bidder is required to commit to the following warranty terms:

All products / components / parts shall be covered under OEM warranty up to the

Implementation Phase and AMC support shall commence after successful implemen-

tation.

The warranty shall include the repair or replacement of the products / components /

parts during the warranty period by the bidder. The replacement products / compo-

nents shall meet the related specifications without further repair or modification.

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.

The date of manufacture or assembly of any equipment, parts or consumables, shall

not be more than six months before delivery.

Selected bidder shall state the location of his repair Centre(s) for all items not being

repaired onsite.

SDA has the right to require a replacement if the repair is deemed to be impractical.

Selected bidder ensures that replacement components shall be available for any

failed component during the warranty period.

Selected bidder shall guarantee the availability of spare parts and technical assis-



tance for all components (or appropriate alternatives) to ensure the equipment

would run for at least five (5) years, without major changes, at the completion of final

acceptance. Six months advance notice is required on any discontinued part(s) with a

suggestion for alternatives.

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 re-

solving such incidents as per the SLA.

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.

The e-District application & 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 deliv-

ery for the entire project term.

Selected bidder is required to explain their warranty, maintenance procedures, and support

to meet the terms and requirements outlined above.

Operations Requirements 1 The selected bidder is expected to provide the following in support of e-District operations:

Selected bidder shall provide procedure documentation for all operations procedures, and SLA’s (based on ITIL best practices) for all the hardware and applications provided including backup procedures, system update procedures, security procedures, failure recovery proce-dures, upgrade procedures, remote access procedures, user manual, SOP’s etc. All such procedures and documents must be submitted for review and approval by the SDA 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 SDA 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 SDA with weekly portal performance reports showing health of system operations. Selected bidder will be required to provide SDA 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 Service Level Agreements (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.

Quality Assurance & Acceptance Requirements 1 Selected bidder is required to develop and implement quality assurance processes and proce-

dures to ensure that the e-District development and operations are performed to meet the quality standards that are relevant to each area in all project phases.

2 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



3 In order to ensure that such a QA mechanism is effective and acceptance of e-District, the fol-lowing 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 assurance that it meets both functional and technical requirements Stress and Performance Testing: Load test-ing enabling understanding of performance and behaviour of Portal Solution under large number of users and high-load conditions.

4 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 minimum CMMi level 3 processes.

5 Furthermore, Selected bidder to describe their documentation standards e.g. Documentation description, documentation identification, content, nomenclature etc. as well. Sample docu-ments to be enclosed as part of the technical proposal.

Quality Assurance & Acceptance Requirements 1 Selected bidder is required to develop and implement quality assurance processes and proce-

dures to ensure that the e-District development and operations are performed to meet the quality standards that are relevant to each area in all project phases.

2 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.

3 In order to ensure that such a QA mechanism is effective and acceptance of e-District, 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 in-

tegrated Solution. This could include external integration if required or it can be sep-arated into testing phases.

UAT: User Acceptance Testing (UAT) validation of the Portal Solution and 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 condi-tions.

4 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 minimum CMMi level 3 processes.

5 Furthermore, Selected bidder to describe their documentation standards e.g. Documenta-tion description, documentation identification, content, nomenclature etc. as well. Sample documents to be enclosed as part of the technical proposal.



4.7 CSC Rollout Status

S L No

SCA Name of Dis-tricts

Total CSCs to be set up

Roll Out as on 31st Dec 2012

CSCs Connected

BSNL (1)

VSAT (2)

Data Card BSNL (3)

Oth-ers (4)

1 Zoom Developers Balasore 492 324 150 64 0 4 82

2 Zoom Developers Bhadrak 219 222 77 35 0 2 40

3 Zoom Developers Jajpur 296 143 56 36 0 1 19

4 Zoom Developers Kendrapara 257 202 87 35 0 6 46

5 SREI Sahaj Cuttack 325 236 183 89 92 2

6 SREI Sahaj Jagatsinghpur 215 126 108 84 21 3

7 SREI Sahaj Khurda 258 143 129 97 31 1

8 SREI Sahaj Nayagarh 282 140 122 91 24 7

9 SREI Sahaj Puri 286 158 115 68 45 2

10 Zoom Developers Angul 318 135 85 33 0 3 49

11 Zoom Developers Deogarh 146 35 22 10 0 0 12

12 Zoom Developers Dhenkanal 202 137 75 32 0 8 35

13 Zoom Developers Keonjhar 354 210 125 24 0 14 87

14 Zoom Developers Sundergarh 294 193 110 38 0 10 62

15 SREI Sahaj Bargarh 201 184 142 83 50 9

16 SREI Sahaj Bolangir 299 153 121 78 36 7

17 SREI Sahaj Boudh 198 60 51 21 28 2

18 SREI Sahaj Jharsuguda 58 75 62 22 36 4

19 SREI Sahaj Sambalpur 220 134 111 64 43 4

20 SREI Sahaj Sonepur 160 80 70 32 36 2

21 BASIX Gajapati 270 170 163 11 0 0 152

22 BASIX Kandhmal 424 146 110 28 0 0 82

23 BASIX Rayagada 445 190 181 10 0 0 171

24 SREI Sahaj Kalahandi 373 235 212 15 194 3

25 SREI Sahaj Koraput 338 263 236 24 208 4

26 SREI Sahaj Malkangiri 174 114 101 4 93 4

27 SREI Sahaj Nabarangpur 150 163 143 2 140 1

28 SREI Sahaj Nuapara 111 100 87 1 86

TOTAL 8558 5337 3919 1246 1163 117 1393