You are on page 1of 17

PART 2 REQUIREMENT SPECIFICATIONS

PART 2

CENTRAL G-CLOUD
GENERAL REQUIREMENT SPECIFICATIONS

IDA(T)-XXX Page 1 of 17
PART 2 REQUIREMENT SPECIFICATIONS

CONTENTS

1.  INTRODUCTION ................................................................................................... 3 


2.  OBJECTIVES OF CENTRAL G-CLOUD ............................................................. 3 
3.  SCOPE OF WORK .................................................................................................. 4 
4.  CENTRAL G-CLOUD DESIGN STRATEGY....................................................... 8 
5.  CENTRAL G-CLOUD DESIRED FUNCTIONALITY ....................................... 10 
6.  CENTRAL G-CLOUD ACCEPTANCE TESTS .................................................. 12 
7.  CENTRAL G-CLOUD IMPLEMENTATION SCHEDULE ............................... 14 
8.  TRANSITION AND EXIT PLAN ........................................................................ 15 
9.  DOCUMENTATION ............................................................................................ 17 
10.  CONFIDENTIALITY OF INFORMATION ........................................................ 17 

IDA(T)-XXX Page 2 of 17
PART 2 REQUIREMENT SPECIFICATIONS

1. INTRODUCTION
1.1. The purpose of this Tender is to invite Tenderers to submit a complete proposal to
provide and operate a central government cloud (Central G-Cloud) and Central G-
Cloud Services for Singapore Government which includes ministries, statutory boards,
and organs of state.

1.2. The ministries, government departments, organs of state and statutory boards, shall
hereinafter be referred to as Agencies.

1.3. Central G-Cloud shall comprise the Central G-Cloud Platform and the Central G-Cloud
Services including Infrastructure as a Service (IaaS), Software as a Service (SaaS),
Platform as a Service (PaaS), Government Common Services, Utility Services will be
offered to Agencies as potential Central G-Cloud Customers. These Central G-Cloud
Services shall be accessed by Customers via a Central G-Cloud Service Portal. The
Contractor shall also provide Managed Services as described in Part 2A Section 2. The
Government intends to leverage on proven cloud computing offerings, capabilities,
infrastructure and facilities so as to reduce implementation time and risks. All data and
processing for Customers and Central G-Cloud Services shall reside in Singapore.

1.4. The Tenderer shall submit their Tender proposal according to the format specified and
instructions in Part 1A.

1.5. The Tenderer shall provide the price for Central G-Cloud Services payable by
Customers for use of the Central G-Cloud Services in accordance with the Price
Schedule as stipulated in Part 3.

1.6. Unless stated otherwise, the Tenderer shall quote for each Option in Part 3. The
Government may or may not award any of these options. If awarded, an Option can be
exercised at any time during the Master Contract at the sole discretion of the
Government.

2. OBJECTIVES OF CENTRAL G-CLOUD


2.1. In Singapore, we started our equivalent of the “cloud journey” in 2005 with the
implementation of a central Whole-Of-Government (WOG) infrastructure, SHINE,
which provides computing resources to Agencies on a “as a service” subscription
model. The adoption of cloud computing for the next central WOG infrastructure is a
timely next step in this journey towards a new platform.

2.2. Central G-Cloud shall provide a central WOG infrastructure (including Central G-
Cloud Services) that is multi-tenanted, delivers the benefits of cloud computing and
meets the required security assurance for Agencies to reap the benefits of cloud
computing.

2.3. The fundamental benefits offered by cloud computing includes the following:

(a) No need to worry about IT infrastructure – with cloud computing virtual


infrastructure, companies do not need to invest in capital and operational costs
of building and maintaining IT infrastructure. Instead companies focus on
purchasing computing resources needed to support business needs.

IDA(T)-XXX Page 3 of 17
PART 2 REQUIREMENT SPECIFICATIONS

(b) On demand capacity – with cloud computing, there is rapid scalability since
additional computing resources can be provisioned quickly and released when it
is no longer required. Companies can thus scale up or down their computing
resources depending on their needs.

(c) On demand pricing – cloud computing allows for pricing models that are more
closely matched to computing resources utilised. This will allow companies to
get a ‘pay per use’ or utility model.

2.4. The Central G-Cloud solution provided shall deliver the fundamental cloud computing
features described in Clauses 2.2 and 2.3 of this document so that Government can in
turn enjoy the following benefits:

(a) Business agility – Agencies will enjoy greater agility and faster turn-around
time in terms of hardware and software provisioning. With cloud computing
virtual infrastructure, Agencies using Central G-Cloud do not have to procure
hardware individually. Additional capacity to cater for peak traffic volumes
can be provisioned dynamically for the peak period only. There will thus be
no capital investment required from Agencies as they will be paying for
services on a demand basis. With this rapid scalability, Agencies will thus be
able to respond more quickly to implement new business needs.
(b) Higher level of system resilience – Agencies will benefit from a higher level
of resilience as cloud computing virtual machine approach means that
processes run as virtual machines on any server. With cloud management
software, live running virtual machines can be moved from one physical
system to another while maintaining continuous service availability. Cloud
computing will also offer faster recovery times in the event of a disaster. The
cost of disaster recovery will also be reduced.
(c) Optimise utilisation of computing resources – Cloud management software
allows for fast reconfiguration and optimisation of resources across the virtual
infrastructure. This allows pooled computing resources to be used more
efficiently. As such capacity planning need not be done at physical server
level but can be done at enterprise level leading to more efficient utilisation of
computing resources as a whole. With capacity planning, the Central G-Cloud
platform will be highly scalable.
(d) Lower barrier for innovation – Agencies can leverage on the Central G-
Cloud platform as a test-bed for new and innovation applications without
incurring the cost and time of setting up a new infrastructure.

3. SCOPE OF WORK
3.1. The intent of this Tender is to award a single Tenderer to be the service provider
(Contractor) to provide and operate Central G-Cloud. The Contractor shall provide the
Central G-Cloud Platform and offer Central G-Cloud Services operated from the
Central G-Cloud Platform to Agencies. The Tenderer shall note that the provisioning
of similar Central G-Cloud platforms or Central G-Cloud Services shall not be
exclusive to the Contractor. The Government reserves the right to allow other service
providers to provide and operate similar services.

IDA(T)-XXX Page 4 of 17
PART 2 REQUIREMENT SPECIFICATIONS

3.2. The Contractor shall be responsible for all capital and operating costs incurred by the
Contractor to set up and operate Central G-Cloud under this Tender. The Contractor
will derive revenue through charging Customers for use of Central G-Cloud Services.
Agencies can sign up as Customers of a Central G-Cloud Service by raising an RFQ as
defined in Part 1 Section B.

3.3. The Tenderer shall note this Tender is based on a utility and subscription model.

3.4. In consideration of the Contractor being awarded a right to provide and operate Central
G-Cloud, the Contractor shall be responsible for the successful delivery of this Tender
and shall be fully accountable to the Adviser for all required Central G-Cloud functions
which includes the following:

(a) Provision, on-going maintenance and technology refresh of Central G-Cloud


Platform which includes all components needed to operate a Central G-Cloud
to meet the requirements of this Tender.
(b) Delivery of Central G-Cloud Services to Customers as described in this
Tender specifications. Central G-Cloud Services include IaaS, SaaS,
Government Common Services and Utility Services.
(c) Provide all ongoing support services such as Incident & Problem
Management, SLA Management, Performance Management of Central G-
Cloud and Central G-Cloud Services to ensure efficient and smooth day to day
operations.
(d) Manage provisioning of new SaaS approved for Central G-Cloud in
accordance with a SaaS Provisioning Framework defined in Part 2A Section 3:
Central G-Cloud (MAZ and HAZ) Service Management.
(e) Manage provisioning of new PaaS approved for Central G-Cloud in
accordance with the same SaaS Provisioning Framework defined in Part 2A
Section 3: Central G-Cloud (MAZ and HAZ) Service Management.
(f) Provide and operate Government Common Services as defined in Part 2A
Section 4.4: Central G-Cloud (MAZ and HAZ) Government Common
Services Requirements.
(g) Manage provisioning of Government Common Services in accordance with
established procedures; and provide monitoring and 1st level support of
Government Common Services.
(h) Provide Gateway Services for the Customers’ applications to access SHINE
Services and other third party services for the Government that are developed
and operated outside of Central G-Cloud.
(i) The Contractor shall provide all required operations and management
reporting to the Adviser as if the Adviser were the owner of Central G-Cloud
and has outsourced all Central G-Cloud operations and management to the
Contractor. The management reporting required shall include Customer
related information and overall Central G-Cloud related information.
Customer related information shall include information such as Customer
expenditure by Central G-Cloud Services; and Customer resource
purchased/utilization by Central G-Cloud Services. Overall Central G-Cloud
information shall include information such as Available Central G-Cloud

IDA(T)-XXX Page 5 of 17
PART 2 REQUIREMENT SPECIFICATIONS

capacity for resources dedicated to Government; and Resource utilization


against available Central G-Cloud capacity.
3.5. The operations and support of Central G-Cloud shall be 24 hours a day, 7 days a week,
including Sundays and Public Holidays.

3.6. The Central G-Cloud Platform shall be operated in a data centre facility (henceforth
Central G-Cloud Data Centre), sited within Singapore, that meets the facility
management requirements stipulated in Part 2A Section 4.2.

3.7. The Contractor shall be required to provide all necessary details about the locations of
the Central G-Cloud Data Centre and to obtain the necessary security clearance from
the Government for the locations to be used. This shall also apply to any changes in
the location and boundaries of any Central G-Cloud Data Centre location.

3.8. The detailed Central G-Cloud scope of work and requirements are described in:

(a) Part 2A Section 1: Central G-Cloud (MAZ and HAZ) Service Delivery
(b) Part 2A Section 2: Central G-Cloud (MAZ and HAZ) Service Support
(c) Part 2A Section 3: Central G-Cloud (MAZ and HAZ) Service Management
(d) Part 2A Section 4.1: Central G-Cloud (MAZ and HAZ) Service Orchestration
(e) Part 2A Section 4.2: Central G-Cloud (MAZ and HAZ) Infrastructure-as-a-
Service (IaaS)
(f) Part 2A Section 4.3: Central G-Cloud (MAZ and HAZ) Software-as-a-Service
(SaaS)
(g) Part 2A Section 4.4: Central Government (MAZ and HAZ) Common Services
(h) Part 2A Section 4.5: Central G-Cloud (MAZ and HAZ) Utility Services
(i) Part 2A Section 5.1: Central G-Cloud (MAZ and HAZ) Common Security
Requirements
(j) Part 2A Section 5.2: Central G-Cloud MAZ Security Requirements
(k) Part 2A Section 5.3: G-Cloud HAZ Security Requirements
(l) Part 2B: Central G-Cloud BAZ Requirements

IDA(T)-XXX Page 6 of 17
PART 2 REQUIREM
MENT SPECIF
FICATIONS

Figure 1. Overall Framework for Centrral G-Cloud


d Requirem
ments

3.9. The Mastter Contracct Period shhall be fivee (5) yearss beginningg from the date of
commenceement speciified in the Letter
L of Accceptance, with
w the Govvernment haaving the
option or options
o to exxtend for upp to another five (5) yeaars.

3.10. The Contrractor shall note


n that thee Governmeent reserves the t right to terminate orr replace
any servicces under thhis contract if they are deemed to beb no longeer relevant or
o useful
and new services
s mayy be introducced when th he need arisees.

IDA(T))-XXX Pagee 7 of 17
PART 2 REQUIREMENT SPECIFICATIONS

3.11. The Contractor shall not be allowed to terminate any services they are providing under
the Contract unless permission to do so has been given by the Government.

3.12. The Contractor shall meet all the security requirements as specified in Part 2A Section
5 in provision of Central G-Cloud Services.

4. CENTRAL G-CLOUD DESIGN STRATEGY


4.1. The Central G-Cloud infrastructure shall comprise three (3) separate zones that shall
leverage on the Contractor’s cloud infrastructure to cater to differing levels of security
assurance. Central G-Cloud shall be classified into the following logical network zones
(Refer to Figure 2: Central G-Cloud Design):

(a) Basic Assurance Zone (BAZ)


(b) Medium Assurance Zone (MAZ)
(c) High Assurance Zone (HAZ)

Figure 2: Central G-Cloud Design

4.2. The Contractor shall provide public cloud computing resources in the BAZ by
leveraging on their public cloud offerings. Agencies who wish to leverage on public
cloud computing resources from the Contractor will be able to procure BAZ resources
from the Contractor under this Master Contract. The Tenderer shall note that Agencies
can also purchase public cloud computing resources from other public cloud providers.

4.3. The MAZ and HAZ shall be segregated from the Contractor’s cloud infrastructure, in
accordance with the Tender requirements to provide private cloud computing resources
for government needs with security and governance requirements that cannot be met by
public clouds. The Contractor shall ensure that both MAZ and HAZ shall be based on
IDA(T)-XXX Page 8 of 17
PART 2 REQUIREMENT SPECIFICATIONS

the same cloud architecture in terms of the capabilities and feature-set. Customers shall
have the ability to seamlessly and efficiently move their applications hosted in MAZ to
the HAZ and vice versa. The MAZ and HAZ shall be designed to meet requirements
such as security controls and compliance requirements as stipulated in Part 2A Section
5: Central G-Cloud (MAZ and HAZ) Security Requirements. The Tenderer shall
provide details on the set up of the MAZ and HAZ.

4.4. Only the MAZ and the HAZ shall be connected to the Singapore Government Network
(SGNET). All BAZ, MAZ and HAZ shall be monitored by Cyber-Watch Centre
Monitoring Services. Refer to Central G-Cloud Network Zones stated in Part 2A
Section 4.2: Central G-Cloud (MAZ and HAZ) Infrastructure-As-A-Service (IaaS)
Requirements for more network zoning requirements.

4.5. As Customers may deploy one system across both MAZ and HAZ, Contractor shall
provide a common service portal (or Central G-Cloud Service Portal) as a single
Customer interface to Central G-Cloud Services in MAZ and HAZ. The Central G-
Cloud Service Portal shall be dedicated to Government and accessible via the
Government intranet.

4.6. The Tenderer shall propose their offerings for BAZ services. The BAZ services may
be based on their existing public cloud offerings, including their existing public cloud
service portal to procure and access BAZ services.

4.7. The Tenderer shall also provide a roadmap where Government Agencies can also
procure and access BAZ services, in addition to MAZ services and HAZ services from
the Central G-Cloud Service Portal. The integration of the service portals shall be
carried out in a manner where all other pre-requisite requirements for BAZ, MAZ and
HAZ (e.g. security, segregation, etc) shall continue to apply.

4.8. The BAZ shall not have any connections to the MAZ and HAZ.

4.9. The Tenderer shall demonstrate clearly in the Tender proposal on how the cloud
computing offering can be engineered to meet the requirements of MAZ, HAZ and to
meet the implementation requirements stated in Clause 7 of this document.

4.10. The Orchestration Engine for HAZ shall be dedicated for Central G-Cloud usage only.
The Service Orchestration for MAZ and HAZ shall be mutually separate entities such
that the resources can be allocated seamlessly, securely and transparently without any
impact to each assurance zones.

4.11. The MAZ is a Virtual Private Cloud (VPC) that is created from the Contractor’s cloud
infrastructure by putting in place logical segregation measures such that this MAZ is
separated from other non-Government tenants. The Contractor shall detail the steps and
measures to describe how this can be achieved, including the associated
processes/procedures to uphold this segregation.

4.12. The MAZ shall provide resources which can be re-allocated to/from other non-
Government, enterprise tenants of the Contractor to provide lower-priced computing
resources for processing needs such as Testing/R&D and systems with low business
impact.

IDA(T)-XXX Page 9 of 17
PART 2 REQUIREMENT SPECIFICATIONS

4.13. The HAZ is a private cloud that leverages on the Contractor’s cloud infrastructure by
putting in place more stringent segregation measures, including having physical caging.

4.14. The HAZ shall provide resources which are physically segregated from other non-
Government tenants of the Contractor for higher security requirements, such that the
HAZ resources are not physically shared and not accessible by other non-Government
tenants.

4.15. The Cloud Management for HAZ shall be for resources dedicated to Government only.

4.16. Government Common Services shall be operated in HAZ while other Central G-Cloud
offerings such as SaaS can be operated in either MAZ or HAZ depending on the
business functionality provided by the SaaS.

4.17. The Tenderer shall indicate clearly the proposed Central G-Cloud capacity they are
providing for MAZ and HAZ for Central G-Cloud IaaS offering as outlined in Part 2A
Section 2. The Tenderer shall provide agility measures to demonstrate how they can
scale-out or scale-up Central G-Cloud capacity quickly to meet additional demand.

4.18. The Government may desire enhancements and customisations to the cloud
management and Central G-Cloud Service Portal at a later stage; for example,
Government may enhance or customise the Central G-Cloud Service Portal so that
there is integrated billing for all services provided on Central G-Cloud. The Contractor
shall comply with this need and work with the Government to understand the
requirements during the Master Contract and propose a solution for the Government to
consider.

5. CENTRAL G-CLOUD DESIRED FUNCTIONALITY


5.1. Central G-Cloud shall provide all necessary functionality to deliver the benefits of
cloud computing which includes virtualisation, multi-tenancy, automated provisioning,
dynamic provisioning and rapid scalability of Central G-Cloud resources.

5.2. Central G-Cloud shall provide for the usage scenarios, which are ‘typical’ experiences
from an end-to-end user perspective, as stated in Annex A to Part 2.

5.3. During Tender evaluation, the Tenderer shall be required to provide a presentation and
demonstration of how they will leverage on and customise their existing cloud
computing capabilities to develop the proposed Central G-Cloud solution. Their
demonstration shall minimally include the automated provisioning and cloud
orchestration capabilities to deliver an efficient, scalable and resilient Central G-Cloud
platform; the end-to-end experience of the Customer; the end-to-end experience of
Customer system administrators; the configuration and setup of Central G-Cloud
Services by the Contractor.

5.4. From an end-to-end system perspective, the Central G-Cloud solution envisaged by
Government shall minimally provide the functionalities listed in Clause 5.5 of this
document. The Tenderer shall provide a detailed description of the functionalities and
features of their proposed solution and shall co-relate these to the functional layers in
this diagram. The Tenderer shall clearly indicate components that are in development

IDA(T)-XXX Page 10 of 17
PART 2 REQUIREMENT SPECIFICATIONS

and provide timelines about the availability that should meet the implementation
schedule in Clause 7 of this document.

Figure 3: Central G-Cloud Functional Architecture

5.5. The Central G-Cloud functional architecture is broadly categorised into the following
key functional layers:

(a) The Customer Interface layer shall provide the necessary capability to
Customers, to procure Central G-Cloud Services. For example, it allows a
Customer to purchase Central G-Cloud Services, provision and configure
these Services for usage, and track service consumption accordingly.
Customers shall be able to track their utilization of their procured Services via
a single dashboard. The Customer Interface layer shall also allow the
Contractor to deliver and bill Customers for use of Central G-Cloud Services.
For example, the Contractor shall be able to set up and administer Central G-
Cloud Services; track and generate bills to the respective Customers for the
services consumed.
(b) The Service Orchestration layer shall provide the necessary capability to
orchestrate and manage the dynamic resource allocation, scheduling, as well
as automated provisioning of the necessary resources. This layer shall also
provide the intelligence to manage the overall capacity, availability and
performance to deliver the Central G-Cloud Services (IaaS, SaaS, Government
Common Services and Other Services). The Contractor shall be able to define
IDA(T)-XXX Page 11 of 17
PART 2 REQUIREMENT SPECIFICATIONS

and manage templates of the different service offerings, and update the
Service Catalogue.
(c) The Software-as-a-Service (SaaS) layer shall allow third-party software
providers (including the Contractor and agency-developed service-wide
applications) to publish their software on the IaaS layer after their applications
or COTS products have been accredited by the Government as a Central G-
Cloud SaaS.
(d) The Government Common Services shall also be offered as a SaaS model.
Examples of Government Common Services include SingPass Service,
eNETS Payment Services, and People Data Service.
(e) The Other Services layer shall include any type of helper or utility services
that enable Customers to deliver their business applications. Examples of
helper or utility services are ‘hygiene’ functionalities such as Cloud Identity
Authentication Management (IAM), Backup and Restore Services or
Application Services such as load-testing. The Cloud IAM shall provide Inter
G-Cloud Identity Federation capability with future G-Clouds to have single
sign-on (SSO) functionalities.
(f) The Infrastructure-as-a-Service (IaaS) Management layer shall comprise
conventional ICT service management components and resource management
components to effectively administer and manage the underlying
Infrastructure Platform.
(g) The Infrastructure Platform shall comprise basic infrastructure commodities
including both physical and virtual infrastructure resources like hypervisors,
servers, storage, network and the data centre facilities.
(h) The Central G-Cloud End-to-End Security shall address, in a holistic
manner, all the security risks and requirements identified for the Central G-
Cloud end-to-end.

6. CENTRAL G-CLOUD ACCEPTANCE TESTS


6.1. The Contractor shall submit to the Adviser, for the latter’s review and approval, a Test
Plan for MAZ within two (2) calendar weeks from the date of the Letter of Acceptance
of Central G-Cloud Master Contract. The Test Plan shall include the scope, acceptance
criteria and schedule.

6.2. The Contractor shall propose and submit the MAZ Acceptance Test Cases within one
(1) calendar month from the date of the Letter of Acceptance of Central G-Cloud
Master Contract.

6.3. The Contractor shall submit to the Adviser, for the latter’s review and approval, a Test
Plan for HAZ within three (3) calendar months from the date of the Letter of
Acceptance of Central G-Cloud Master Contract. The Test Plan shall include the
scope, acceptance criteria and schedule.

6.4. The Contractor shall propose and submit the HAZ Acceptance Test Cases within four
(4) calendar months from the date of the Letter of Acceptance of Central G-Cloud
Master Contract.

IDA(T)-XXX Page 12 of 17
PART 2 REQUIREMENT SPECIFICATIONS

6.5. The Contractor shall undertake to go through the iterations with the Adviser in working
out all the deliverables and revise the deliverables, to the satisfaction of the Adviser.

6.6. Acceptance Tests for both MAZ and HAZ shall be conducted on the respective zones
of the Central G-Cloud to verify and demonstrate that it satisfies all the requirements
stated in this Tender. The Acceptance Tests shall comprise of:

(a) Independent Security Audit of Central G-Cloud including infrastructure and


facility;
(b) System Functionality Tests;
(c) System Performance Tests;
(d) Transition and Exit Plan; and
(e) All other tests necessary to demonstrate that the System meets the System
Availability requirements stated in this Tender.
6.7. The System shall be deemed to fail the Acceptance Tests if it fails to provide any
facility, functionality, transaction or the performance as specified in this Tender.

6.8. If the System fails to pass any of the Acceptance Tests, then the Government may, by
written notice to the Contractor elect at its sole option:

(a) To have the Contractor provide a solution and to fix (without prejudice to its
other rights and remedies) a new date for carrying out further tests on the
System on the same terms and conditions (save that all costs which the
Government may incur as a result of carrying out such tests shall be
reimbursed by the Contractor). Unless otherwise agreed in writing between the
Contractor and the Government, all such further tests shall not be construed as
any grant of extension of time by the Government and the Contractor remains
liable for any delay in complying with its obligations under the Master
Contract; or
(b) To accept the System subject to an abatement of the Contract Price such
abatement to be such amount, as taking into account the circumstances, is
reasonable. In the absence of written agreement as to abatement within
fourteen (14) calendar days after the date of such notice the Government shall
be entitled to exercise sub-clause (c) below; or
(c) To treat the Contractor as being in breach of the Master Contract and to reject
the Central G-Cloud as not being in conformity with the Master Contract in
which event the Government shall be entitled to terminate this Master
Contract (without prejudice to the Customer’s other rights and remedies) in
accordance with Liquidated Damages stated in Part 1 Section B.
6.9. All above Acceptance Tests results shall be properly documented by the Contractor and
made available to the Government for perusal or verification.

6.10. The Contractor shall submit to the Government an Acceptance Tests Report within
three (3) working days after the completion of all tests.

6.11. The Contractor shall supply all consumable items for the Acceptance Tests at no
additional cost to the Government.

IDA(T)-XXX Page 13 of 17
PART 2 REQUIREMENT SPECIFICATIONS

6.12. The Government shall not be under any obligation to accept the Central G-Cloud
Services if it does not successfully pass any of the Acceptance Tests under the Master
Contract. The Contractor shall submit a report to the Government detailing the cause
for the failure of any Acceptance Tests and the corrective action taken.

6.13. The Adviser shall reserve the final rights to decide on whether the services have been
successfully passed according to the Service Levels stipulated in this Part 2A Section 3
Annex A.

6.14. The Adviser shall reserve the right to request the Contractor to conduct additional tests,
at no additional cost to the Government.

7. CENTRAL G-CLOUD IMPLEMENTATION SCHEDULE


7.1. The figure below shows the overall implementation schedule of the Central G-Cloud.

7.2. The Contractor shall provide the deliverables listed in Table 1: Deliverables Table
below by the stipulated Completion Date.

SN Project Milestone Deliverables Completion Date


(in calendar
months)
(a) Commencement of Date of project commencement as X
Project stated in the Letter of Acceptance
Project Planning
(b) Central G-Cloud Central G-Cloud Implementation Plan X+1
Implementation Acceptance of Implementation Plan
Planning X+1

Central G-Cloud Network


(c) Central G-Cloud Commissioning & Audit Report
Connectivity to (System Architecture and Network
Government Network Design Specification) X+4
(SGNET/SOEASY)
and Internet
(d) Connectivity between Compliance Report on System X+5
MAZ to HAZ Architecture and Network Design
Specification

BAZ
(e) BAZ Acceptance Test Plan (Scope, Acceptance Criteria X+1
Test Planning and Schedule )
Acceptance Test Cases X+2
(f) BAZ Central G- All BAZ related Central G-Cloud X+3
Cloud Services Services - BAZ IaaS

(g) Commissioning of BAZ System Acceptance Test Reports X+3


BAZ

IDA(T)-XXX Page 14 of 17
PART 2 REQUIREMENT SPECIFICATIONS

SN Project Milestone Deliverables Completion Date


(in calendar
months)
MAZ
(h) MAZ Acceptance Test Plan (Scope, Acceptance Criteria X+1
Test Planning and Schedule )
Acceptance Test Cases X+2
(i) MAZ Pre- Security audit of IaaS comprising audit X+4
commissioning Audit of processes, vulnerability and
penetration tests
(j) MAZ Central G- All MAZ related Central G-Cloud X+4
Cloud Services Services including MAZ IaaS, SaaS,
and selected Utility Services – SSH &
SFTP, Backup & Restore Services
(excludes Government Common
Services and other Utility Services)
(k) Commissioning of MAZ System Acceptance Test Reports X+6
MAZ
HAZ
(l) HAZ Acceptance Test Plan (Scope, Acceptance Criteria X+1
Test Planning and Schedule )
Acceptance Test Cases X+2
(m) HAZ Pre- Security audit of IaaS comprising audit X+4
commissioning Audit of processes, vulnerability and
penetration tests
(n) HAZ Central G- All HAZ related Central G-Cloud X+5
Cloud Services Services
(o) Commissioning of HAZ System Acceptance Test Reports X+6
HAZ
Government Common Services
(p) Government Government Common Services
Common Services (SingPass and Electronic Payment X+6
gateways)
Table 1: Deliverables Table

7.3. The Contractor shall be subject to Liquidated Damages specified in Part 1 Section B
Clause 33 if the Contractor fails to meet any of the completion dates for
Commissioning of MAZ, Commissioning of HAZ, and completion of Government
Common Services as specified in Table 1, Deliverables Table in clause 7.2.

8. TRANSITION AND EXIT PLAN


8.1. The Tenderer shall propose a Transition and Exit Plan to cover the termination or
expiry of the Master Contract. The Transition and Exit Plan shall be provided as part
of the Acceptance Test Plan. The Adviser may, in the course of the Master Contract

IDA(T)-XXX Page 15 of 17
PART 2 REQUIREMENT SPECIFICATIONS

Period, require the Transition and Exit Plan and the detailed schedule to be reviewed or
require reasonable changes to be made to the Transition and Exit Plan.

8.2. The Transition and Exit Plan shall address the following transition and exit issues as a
minimum

(a) Migration and hand-over of Customer data and processing from Contractor
facility to a new Central G-Cloud facility in a manner that ensures minimum
down time;
(b) Migration of Central G-Cloud configuration management database to a new
Central G-Cloud service provider; the Contractor should export the necessary
information which the new Central G-Cloud service provider will require;
(c) Migration and hand-over of all Central G-Cloud Customer set-up information
and all Central G-Cloud Service Portal user account information;
(d) Hand-over of all Central G-Cloud customizations belonging to the
Government which includes source code, development environments, run-time
environments and documentation;
(e) Hand-over of all problem logs and resolution status;
(f) Hand-over of all Central G-Cloud technical and operational documentation;
(g) Hand-over of all other Government data and files in the possession of
Contractor;
(h) Perform secure erasure on the storage media to remove all Government data
from the Central G-Cloud System; (The Contractor shall ensure that
unauthorized personnel are unable to recover any data on the storage media).
(i) Roles and responsibilities of the Contractor and Government; and
(j) Transition and exit schedule.

8.3. The Contractor shall be given 6 calendar months to carry out any required hand-over of
the Central G-Cloud Services to the new contractor appointed by the Government,
before the expiry or termination of the Contract. The Contractor shall plan the
transition well to ensure that it will be completed on time. Any additional costs
incurred due to the delay in transition caused by the Contractor shall be fully borne by
the Contractor.

8.4. Upon notification by the Government of the start of the transition and exit period, the
Contractor shall submit the final Transition and Exit Plan for the Government’s review
and approval within one (1) calendar month. The Contractor shall ensure that there are
adequate resources assigned to carry out the transition as defined in the Transition and
Exit Plan. The Contractor shall carry out all transition and exit activities at their own
costs.

8.5. The Contractor shall carry out all transition and exit obligations in a professional and
responsible manner and work with the Government and new Central G-Cloud Services
provider to ensure that all Central G-Cloud migration is carried out successfully and all
Customers are migrated successfully to the new Central G-Cloud based on the agreed
transition schedules. The Contractor shall be responsible to bear additional charges

IDA(T)-XXX Page 16 of 17
PART 2 REQUIREMENT SPECIFICATIONS

borne by the Government as a result of any delay on their part in carrying out their
transition and exit obligations.

9. DOCUMENTATION
9.1. The Contractor shall provide and maintain documentation for all hardware, software,
configuration and processes that are used to fulfil the scope of the Master Contract. All
documentation shall be completed and delivered to the Adviser within the specified
project schedule.

9.2. All documents, except for the standard documentation that accompanies the
appropriate hardware and software, shall be made available in both hardcopy and
softcopy in the Government approved format for ready reference and subsequent
maintenance. All such documents shall have comprehensive indices to facilitate quick
reference. For maintainability, all such documentation shall be converted to the latest
version of the documentation tool in use, if so required by the Adviser or Agency.

9.3. All documentation shall come with folders and proper front/side labels. The
documentation shall be properly arranged and sorted.

9.4. The Contractor shall update all documentation no later than three (3) months after any
changes. The Contractor shall provide any revised editions, supplementary materials
or new publication relevant to the Master Contract at no additional cost to the
Government.

9.5. All documents produced by the Contractor in fulfilling this Master Contract shall
become the property of the Government. The Government reserves the right to
reproduce, at no cost whatsoever, any documentation supplied for its own use.

9.6. The Contractor shall provide satisfactory answers to any reasonable queries raised by
the Government concerning any information stated in the documentation.

9.7. The Contractor shall prepare user guides, problem resolution guides and other relevant
documents to facilitate the resolution of problems.

9.8. All documentation formats shall be subjected to approval by the Government.

10. CONFIDENTIALITY OF INFORMATION


The Contractor shall note that all Central G-Cloud information including Central G-
Cloud resource utilization and Central G-Cloud Master Contract expenditure is deemed
client confidential and should not be released without the prior approval of the
Government.

IDA(T)-XXX Page 17 of 17