ITQ ICT-29-2019 Date: 29th Nov 2019 Title: Phase 2 ......b) Phase 2: Development of Corporate...

ITQ – ICT-29-2019 Date: 29th Nov 2019 Title: Phase 2: Development of Corporate Website

COPYRIGHT © 2019 ISCA ALL RIGHTS RESERVED

PAGE 1 OF 60

TABLE OF CONTENTS

1. INTRODUCTION ....................................................................................................... 2

2. SCOPE OF WORK .................................................................................................... 4

3. GENERAL REQUIREMENTS .................................................................................... 6

4. WEBSITE DEVELOPMENT ...................................................................................... 7

5. TECHNICAL REQUIREMENTS............................................................................... 12

6. SECURITY REQUIREMENTS ................................................................................. 19

7. CHANGE REQUESTS ............................................................................................ 27

8. PROBLEM ESCALATION, ANALYSIS, RESOLUTION AND MANAGEMENT ......... 32

9. PROJECT MANAGEMENT AND QUALITY ASSURANCE ...................................... 37

10. RISK MANAGEMENT ............................................................................................. 45

11. TRAINING ............................................................................................................... 45

12. DOCUMENTATION ................................................................................................. 47

13. TRANSITION AND EXIT MANAGEMENT ............................................................... 50

14. SYSTEM MAINTENANCE AND SUPPORT SERVICES ......................................... 55

15. INFORMATION IN THIS DOCUMENT .................................................................... 58

16. DISCLAIMERS ........................................................................................................ 58

17. ENQUIRIES............................................................................................................. 58

APPENDIX 1: PRICING AND CHARGES ........................................................................... 59



PAGE 2 OF 60

The purpose of this invitation to quote (ITQ) is to invite vendors to submit their quotations and

proposals for Phase 2 of the website and mobile application project.

1. INTRODUCTION

1.1. Overview

1.1.1. The Institute of Singapore Chartered Accountants (ISCA) invites tenderers to submit

a complete and comprehensive proposal for the development, customisation, supply,

delivery, installation, testing, commissioning, training and maintenance of ISCA

corporate website.

1.1.2. There are 3 phases in the website and mobile application project:

a) Phase 1: Scoping of Visual design, front end & content, Back end & Content

Management System (CMS), technical aspect and developing of ISCA digital

strategy

b) Phase 2: Development of Corporate Website

c) Phase 3: Development of Mobile Application

1.1.3. This ITQ describes the requirements for the provision of this new ISCA corporate

website (henceforth referred to as the “Website”).

1.2. About ISCA

1.2.1. ISCA is the national accountancy body of Singapore. ISCA’s vision is to be a globally

recognised professional accountancy body, bringing value to our members, the

profession and wider community. There are over 32,000 ISCA members making their

stride in businesses across industries in Singapore and around the world.

1.2.2. Established in 1963, ISCA is an advocate of the interests of the profession.

Possessing a Global Mindset, with Asian Insights, ISCA leverages its regional

expertise, knowledge, and networks with diverse stakeholders to contribute towards

Singapore’s transformation into a global accountancy hub.

1.2.3. ISCA is the Designated Entity to confer the Chartered Accountant of Singapore - CA

(Singapore) - designation.

1.2.4. ISCA is a member of Chartered Accountants Worldwide, a global family that brings

together the members of leading institutes to create a community of over 1.8 million

Chartered Accountants and students in more than 190 countries.

1.3. Current System/Website

1.3.1. The current ISCA corporate website, https://www.isca.org.sg, is hosted on-premise

in a virtualised environment installed with Windows Server 2008 R2 and Microsoft

SQL Server 2008 R2, with an allocated disk space of 160GB and 140GB

https://www.isca.org.sg/



PAGE 3 OF 60

respectively. The content management system is built on the Umbraco platform with

some additional custom development.

1.3.2. The following information is currently offered on the current website:

a) About the Institute, its history, management teams, and annual reports

b) Media centre & blog

c) Types of memberships, benefits and privileges

d) Pathways and qualification programmes leading to ISCA membership

e) Member resources and knowledge centre

f) Professional short courses and thematic large-scale conferences and events

g) Advertising and offerings by our partners

h) Career centre

i) Procurement requests

1.3.3. The current website consists of the following functions:

a) 50 landing pages and 1,000 web content pages (estimate)

b) Online forms

c) Email notifications

d) Rotating banners, photo galleries, YouTube channel,

e) Advertisements in various formats

f) Social media posts such as Facebook and Twitter

g) Shopping cart (interface)

h) Accessibility features such as text resize

1.3.4. In 2018, the current website garnered about 350,000 visits with more than 700,000

sessions. Each session duration lasts approximately three minutes. Bounce rate is

close to 57%. 70% of these visitors used desktop browsers to access our website.

1.4. Our Target Audience

1.4.1. ISCA members are the primary target audience of the corporate website. Members

range from students, junior accountants, senior accountants and owners of

accounting SMEs. There are other audience that are non-members who are

interested to find out about the accountancy industry. The different groups of

audiences possess different traits and have different needs when they come to the

website.

1.5. Research

1.5.1. A separate Tender was awarded during Phase 1 to perform an initial requirement

gathering studies, creative design concepts, and wireframes creation.

1.5.2. The new corporate website will be more member-centric focus where contents will

be re-organised according to the needs of our different member segments.



PAGE 4 OF 60

1.5.3. The research includes.

a) Persona creation and user journey maps that were created based on user interviews

b) Design concepts, digital style guide, wireframes that will reflect new ISCA website

c) Technical and functional specifications of the new website and user interface 1.5.4. The research document (from Phase 1) will be provided upon execution of non-

disclosure agreement, the final creative design concept, specification and

wireframes will be provided upon award notification.

2. SCOPE OF WORK

2.1. Base Services

2.1.1. The base scope of work shall be for the development, customisation, supply,

delivery, installation, testing, commissioning, training, maintenance and warranty of

a fully operational Website with the option for continuous improvement services

through man days.

2.1.2. The scope includes all hardware and software components required to develop the

Website and CMS (henceforth referred to as the “System”).

2.1.3. The appointed vendor is wholly responsible for the timely delivery of the System in

accordance with the Requirement Specifications. The scope of work includes the

provision of the following services in the production and staging environment:

a) Supply, development, customisation, delivery, installation, testing, training and

commissioning of all mandatory requirements specified in this Tender;

b) Purchase, delivery and installation of hardware and any related software where

applicable;

c) Provide project management services which include activities in all phases of

a project management lifecycle such as project initiation, planning, execution,

monitoring and control and closure

d) Recommend upcoming new and relevant technologies that can be

incorporated into the Website;

e) Provide professional consultancy services such as sharing of best practices

and industry practices, and advising a fit-for-purpose solution;

f) Provide professional copywriting services as optional service;



PAGE 5 OF 60

g) Manage changes and problems.

2.2. Scope of Work

2.2.1. To develop and launch the new ISCA corporate website in accordance to the design

accepted in Phase 1, and Specifications stated in this Tender. This includes but not

limited to:

a) To supply, deliver, install, design, develop, test and commission a CMS for sixty

to hundred (60 to 100) user accounts. Total concurrent users will not exceed

10.

b) To propose infrastructure specification to ensure that the System meets the

quality objectives before rollout.

c) To conduct performance, load and recovery test based on the capacity sizing

proposed to meet the system availability, performance and reliability

requirements, and backup and recovery test, system security acceptance test,

and user acceptance test.

d) To provide training and a training manual to familiarise ISCA users with the

new System so that they may operate the System independently without

assistance.

e) To carry out migration services of contents, files, and setup redirections from

existing ISCA website, up to 100 pages (a page can be assumed to be 500

words, A4 page, Font size 12). Beyond that, appointed vendor will provide

optional services by group of 50 pages.

f) To provide optional professional copywriting services to curate and customise

contents. Appointed vendor will provide optional services by group of 50 pages

(a page can be assumed to be 500 words, A4 page, Font size 12)

g) To commission and launch the Website, meeting the Specifications within the

stipulated project schedule.

h) To provide a Performance Guarantee period of three (3) months upon Go-Live.

i) To provide a System Warranty for a period of twelve (12) months upon the

completion of Performance Guarantee period.

2.3. Optional Services and Items

2.3.1. ISCA shall have the option to require the appointed vendor to carry out additional

periods of System Maintenance and Support Services after the expiry of the System



PAGE 6 OF 60

Warranty period, for additional periods of one (1) year each, by written notice to the

appointed vendor prior to the expiry of the System Warranty period or any additional

period. Such option may be exercised by ISCA up to five (5) times for up to a total of

five (5) additional periods of one (1) year each.

2.3.2. Carry out Change Requests as described in Clause 7.

2.3.3. ISCA is currently using Salesforce.com platform (Sales and Service Cloud) as its

Customer Relationship Management (CRM) system and Salesforce Marketing Cloud

for its email marketing activities and customer journeys.

2.4. Co-existence in a Multi-Vendor Environment

2.4.1. The appointed vendor is expected to work with vendors that maintain existing

systems in ISCA whenever any level of integration or interfacing with the System is

required.

2.4.2. The appointed vendor shall be responsible to work with other vendors and shall do

all that is necessary to resolve any integration, technical, or operational issues

encountered during the testing or operation of the System.

3. GENERAL REQUIREMENTS

3.1. Development Strategy and Design Considerations

3.1.1. The appointed vendor shall ensure that any modifications to the System which may

potentially impact the warranty or upgradeability shall be documented and reported

by the appointed vendor’s Project Manager, and agreed by ISCA prior to the

modification.

3.1.2. The appointed vendor shall formally document the decisions of ISCA on any

modifications to the System that may potentially affect the upgradeability of the

System solution. It shall be at ISCA’s discretion to decide on the major decision

points weighing the upgradeability of the System versus the business requirements.

3.1.3. The System shall be designed and configured to perform with high performance,

maintainability, integrity, reliability, availability, scalability, tight security and control

as the primary consideration.

3.1.4. The System should be modular and well designed, so that future enhancements can

be easily incorporated.

3.1.5. The System shall provide quick and flexible means to effect evolving changes and

amendments in the prevailing business definitions and rules.

3.1.6. The System shall enable new functions to be plugged-in and old functions to be

removed easily.



PAGE 7 OF 60

3.1.7. There shall be no hard coding of ID(s), Password(s) or any parameters in the System.

User-defined parameters, look-up tables or system configurable parameters shall be

provided as much as possible. As far as possible, the System shall be designed to

be parameter driven to allow it to be flexible to accommodate changes without

amendments to the program.

3.1.8. The appointed vendor shall avoid putting any environment specific parameters such

as IP addresses, port number, path, hostname etc. into the System. It shall also

avoid hard coding parameters to enhance the portability of the System.

3.1.9. For web pages generated by the System which contain sensitive data (e.g. personal

data), the System shall employ expiry tags so that such pages are never cached.

3.1.10. The System shall be implemented with audit trail for transaction logging and

archiving of audit trail without compromising the performance requirements of the

Website.

3.1.11. The System shall perform proper error handling and shall provide necessary error

logs for troubleshooting. Error messages shall describe the problem in plain simple

terms to assist a user in understanding the problem.

3.2. Search Capabilities

3.2.1. The system should leverage on Google Search for sitewide search.

3.2.2. The system shall also include the ability to perform an internal search for listing

content types (i.e. news listing)

4. WEBSITE DEVELOPMENT

4.1. Objectives

4.1.1. To develop the Website that is easy to navigate, fast loading, visually appealing and

responsive in all forms of devices and screen sizes, and meets the user experience

design.

4.2. Content Management System

4.2.1. Preferred Content Management System (CMS)

a) The preferred choice is Sitefinity WCMS. Appointed vendor shall propose

alternative if suitable.

4.2.2. Content Authoring and Editing

a) The System shall provide a WYSIWYG editor that gives an editing interface

which resembles how the page will be displayed in a web browser.



PAGE 8 OF 60

b) The System shall provide users the ability to add title tag and meta description

tag for each page without any coding.

c) Authorised users are able to upload media such as videos, photos, images and

documents of different file types.

4.2.3. Content Publishing

a) The System shall support previewing of webpage before publishing it.

b) The System shall provide the option of enabling approval workflows and

provide an audit trail of approval and rejection requests submitted. Such audit

trail shall be searchable and exportable to common file formats such as CSV

for compliance audit.

c) The System shall support scheduled publishing, i.e. webpages to be published

and unpublished on specific date.

d) The System shall support versioning and rollback to previous versions and

save multiple author audits for audit review. The System shall also provide the

capability to compare and highlight the differences between versions.

4.2.4. Vanity URls and Redirections

a) To provide an automated URL shortening function, and to allow ISCA to specify

its preferred custom short URL to help Website users remember and find a

specific page on the Website.

b) For campaign purposes, forwarding addresses may sometimes contain a URL

with UTM codes.

4.2.5. Compliance with Web Standards

a) Support the use of common web standards such as HTML5, XHTML, HTML,

jQuery, JavaScript, CSS, etc

b) HTML should also meet accessibility and semantic guidelines

4.2.6. Licenses

a) All licenses to use must be granted in ISCA’s name. Any license fee payable

shall be billed by the licensor or authorised reseller to ISCA directly with a

minimum credit term of 30 days.



PAGE 9 OF 60

b) The license granted to ISCA must allow for unlimited usage of page layouts,

templates, web pages and number of Website visitors.

c) The System must provide for the ability to create microsites for subdomains

and related domain names.

4.2.7. Analytics, Campaign Tracking and Conversion

a) To set up the Website with analytics tracking using ISCA’s existing Google

Analytics account to analyse data from all touchpoints in one place, for a

deeper understanding of the customer experience.

b) To set up Google Tag Manager to give ISCA the ability to add and update tags

for conversion tracking, site analytics, remarketing, and more.

c) To provide ISCA the ability to add and update tracking codes from social media

platforms including but not limited to Facebook Pixel code and LinkedIn

Insights.

4.2.8. Cookie Notice and Consent

The General Data Protection Regulation (GDPR) and ePrivacy Directive (ePR) affect

all websites located in the European Union, and websites that have EU citizens as

users. ISCA has to comply to GDPR due to the latter reason.

a) To put up a notice on the Website and to allow users to provide or withdraw

their consent for each type of cookie used in the Website.

b) Such consent must be properly recorded and securely stored as evidence that

consent has been given.

c) The System must allow the renewal of consent provided earlier on a periodic

basis.

d) Refer to https://www.cookiebot.com/en/cookie-consent/ for an example of how

the cookie consent can be implemented.

4.3. Content Types

The Website may contain contents of certain types, including but not limited to the

following:

4.3.1. Standard content type for HTML Contents and Rich Media

https://www.cookiebot.com/en/cookie-consent/



PAGE 10 OF 60

a) Images, photo gallery, sliding banners, carousel of thumbnails, and YouTube

video.

b) Integration with ISCA’s social media channels such as Facebook, LinkedIn,

Twitter, Instagram, and YouTube channel

c) Documents for downloading in various formats such as pdf, Microsoft Office

(Powerpoint, Excel, Word Doc).

4.3.2. Social Media Plugins

a) Embed posts from ISCA’s social media channels such as Facebook, LinkedIn,

Twitter, Instagram, and YouTube channel into the Website.

b) The Website shall include visible sharing buttons to allow Website users to

share pages and contents on their social media accounts.

c) Incorporate tracking codes from social media platforms such as Facebook Pixel

and LinkedIn Insights

d) Ensure the source code on website complies with requirements from social

media platforms such as Open Graph Protocol, so that headings and images

are correctly captured by social media platforms

4.3.3. Web Forms

a) Standard contact forms which will be emailed to a designated email address

b) All transactional forms will be provided by Salesforce, and it will be determined

if user will be redirected to Salesforce or the form will be embedded within the

website

4.3.4. Self-Help Services

a) To provide a self-help section on a list of frequently asked questions and to

present them by categories, topics or popularity.

b) A single questions and answer (Q&A) set may be classified in multiple

categories or tagged with multiple keywords so the Website must be able to list

such Q&As in the respective classifications.

c) To allow Website users to type in their question and the Website shall return

the matches, ranked by its relevancy to the context of the question asked.

4.4. Migration

4.4.1. The current domain name used by the existing ISCA website,

https://www.isca.org.sg, shall be retained for use by the new Website.

http://www.isca.org.sg/



PAGE 11 OF 60

4.4.2. The EV-SSL certificate from the existing ISCA website shall be migrated and

installed on the new Website (optional).

4.4.3. Selected existing contents and files will be migrated from the existing ISCA website

to the new Website. Certain URLs used by the existing ISCA website may also need

to be redirected to the new Website. Efforts for the migration shall be quoted as part

of the Proposal but the scope of work will be agreed upon during the Website

development phase.

4.4.4. The Tenderer shall quote for optional copywriting services by professionals who are

subject matter experts in the areas of accountancy, finance and business to create

quality contents to boost the Website’s relevance and search rankings.

4.5. Project Milestones

4.5.1. ISCA envisions the delivery of the major milestones based on the schedule below.

Tenderers may propose variation to this schedule.

No. Milestone Deliverable Deadline

1 Project kickoff Project Management

Plan sign-off

Within two (2) weeks of

acceptance of Phase 2

deliverables

2 Development HTML prototyping Within three (3) months

of Project Management

Plan sign-off

3 Unit test, system

integration test,

performance load test,

security acceptance

test

The System meets

System Delivery and

Acceptance

requirements


completion of

Development phase

4 Training All users are able to

operate the System

independently

without assistance


completion of system

testing phase

5 User acceptance test

(UAT)

The System is error-

free and is working

as intended

Within one (1) month of

the completion of training

6 Migration of existing

website and

copywriting services

Contents are ready

on the new Website


completion of UAT

7 Go-Live DNS records

updated

SSL certificate

installed

Within one (1) week upon

the completion of

verification of migration



PAGE 12 OF 60

No. Milestone Deliverable Deadline

New Website is live

with all contents

ready

4.6. Payment Schedule

4.6.1. The payment schedule for Phase 2 shall be as follows:

No. Milestone Percentage to be paid Cumulative Total

1 Upon sign-off of Project

Management Plan

20% 20%

2 Upon sign-off of UAT 40% 60%

3 Upon Go-Live 20% 80%

4 Upon completion of PGP 10% 90%

5 Upon completion of

System Warranty

10% 100%

5. TECHNICAL REQUIREMENTS

5.1. General Requirements

5.1.1. The System shall be designed as a standard 2-tier or 3-tier web application-based

architecture where the web, application and database servers are located in separate

tiers from each other.

5.1.2. The database tier shall be separated from the web and application tier by network

segments.

5.1.3. The System shall be hosted in the ISCA’s hosting platform which is running on

VMware. Appointed vendor may propose a cloud-based hosting such as Microsoft

Azure.

5.1.4. The System and the Website shall not use ActiveX or Flash controls.

5.1.5. The System shall be designed to have low requirements on operations support. The

appointed vendor shall automate processes required for the operation of the System

as much as possible.

5.1.6. The System shall be designed such that it is easy to operate by end-users. Where

possible, the user interface shall be self-explanatory.

5.1.7. For other categories not stipulated, the appointed vendor is free to propose the use

of any technology that is suitable for use in the System provided that such products

are certified and supported by OEMs to run on the ISCA’s hosting platform.



PAGE 13 OF 60

5.1.8. The appointed vendor shall propose all the necessary software to support the

requirements stated in this Tender.

5.1.9. The appointed vendor shall note that ISCA reserves the right to purchase all or parts

of the proposed software from other sources where applicable.

5.1.10. Media kits (manuals, CDs, drivers, etc) and license keys must be provided for all the

software and hardware where relevant.

5.1.11. The appointed vendor shall be responsible for the installation, configuration,

hardening, testing and commissioning of the hardware and software, even if the

hardware or system software are not supplied by the appointed vendor. The

appointed vendor shall be liable to ensure that the System meets the performance

requirements.

5.1.12. The appointed vendor shall also indicate if the proposed System requires additional

system resources, Facilities Management (FM) services or any other specific

resources. The appointed vendor shall propose the amount or duration for these

additional resources to meet the System and Website’s operational requirements.

5.1.13. The appointed vendor shall ensure inter-operability among the proposed servers and

software.

5.1.14. In the event of non-compatibilities or system degradation as a result of the

recommendations made by the appointed vendor, the appointed vendor shall be

responsible to propose solution(s) to make good the situation including adding

equipment or resources at no additional cost to the ISCA. If the technical solution

specified by the appointed vendor cannot meet the System requirements due to an

incorrect assessment of the technical environment, the appointed vendor shall make

good the situation at no additional cost to ISCA.

5.1.15. Notwithstanding certification by OEMs in the above clause, the appointed vendor

shall be held fully accountable for ensuring that the alternative or additional products

proposed are able to meet the System requirements of this Tender.

5.1.16. The appointed vendor shall also ensure that the software proposed will have the

necessary licensing requirement to run on the ISCA hosting platform. For alternative

or additional products proposed, the appointed vendor shall provide a detailed

breakdown of each product proposed, and its associated cost.

5.1.17. The appointed vendor shall be responsible for setting up, installing, configuring and

managing all the necessary requirements for the System. The appointed vendor shall

provide a handover session to ICT on the operations requirement of the System.

5.1.18. The Tenderer shall propose and setup a testing environment to facilitate the User

Acceptance Testing (UAT) of the System by ISCA. The staging environment shall be

hosted in the ISCA hosting platform.



PAGE 14 OF 60

5.2. System Architecture

5.2.1. The Tenderer shall provide description and diagrams of the System Architecture

proposed.

5.2.2. The System Architecture describes logical components used, the relationship

between the components and how components are deployed in the application. The

logical components shall include new services (if any), hardware, software,

interconnections and interfaces with existing environment and any other resources

used. The appointed vendor shall list the advantages and disadvantages of the

proposed architecture.

5.2.3. The appointed vendor shall provide information on the minimum and recommended

amount of CPU cores, RAM and storage (based on both thick and thin provisioning)

required by the System for an estimated number of users.


network bandwidth required by the System for an estimated number of users.


technical specifications for client workstations used to access the System (e.g. CPU,

RAM, peripherals, storage, software, etc.).

5.2.6. The appointed vendor shall brief ISCA on the proposed System Architecture upon

award and work with ISCA for any changes.

5.2.7. The System Architecture shall be subjected to the ISCA’s approval.

5.2.8. Upon approval, the appointed vendor shall ensure that the System is developed in

accordance to the designed architecture.

5.3. System Load, Response Time and Performance Testing

5.3.1. The projected growth of concurrent System user base shall be based on 10% of the

present concurrent user base per annum for up to three (3) years from

Commissioning Date.

5.3.2. The Website is expected to support an estimated capacity growth of 10% year on

year.

5.3.3. The System Response Time shall be measured as the elapsed time between the

moment a user initiates a computer process by pressing a key (<Enter> or <Submit>)

or clicking a mouse or other input device to the moment the first appearance of the

computer generated FULL intended output is displayed on an output device (e.g. the

screen of the user) or the elapsed time between two screens or, the time when a

batch process is initiated to the time the process is successfully completed. A

computer process can be a query, an update to a database/table/record, a request



PAGE 15 OF 60

of an electronic document or any other logical unit of business transactions that

involve interactive responses.

5.3.4. The System Response Times shall meet the following requirement:

Item # Function System Response Time

1 Online Services (Front End &

Non-login Services)

• Shall not exceed Five (5)

seconds for 90% of the time

• Shall not exceed Seven (7)


2 Document Submission (Upload)

*Based on transfer speed of

512Kbps

• Shall not exceed Twenty

(20) seconds for a file with

size less than 500KB

• Shall not exceed Thirty-Five

(35) seconds for a file with

size between 500KB and

1MB

• Shall not exceed Two (2)

minutes for a file with size

between 1MB and 2MB

3 Login (System owned

authentication)

• Shall not exceed Five (5)


5.3.5. The appointed vendor shall ensure that the above Response Times are maintained

throughout the contract period.

5.3.6. The appointed vendor shall perform at least one (1) round of Performance Testing in

the presence of a representative from ISCA before commissioning of the System.

The Performance test shall include the following:

a) Load Testing – To determine the behaviour of the Website under a specific load

and that the required Response Times are met.

b) Stress Testing - To determine the upper limits of the Website.

c) Endurance Testing – To give ISCA and its members the confidence that the

Website can sustain the continuous expected load and required Response

Times over an extended period of time.



PAGE 16 OF 60

5.3.7. The Tenderer shall describe the methods and calculations used for computing the

expected response time subject to the above conditions in the proposal.

5.3.8. The Tenderer shall also state all assumptions in the calculations used for computing

the expected Response Times. ISCA reserves the right to reject the assumptions if

they are deemed invalid.

5.3.9. The results of the Performance Tests shall be subject to ISCA’s acceptance.

5.3.10. The appointed vendor shall proactively monitor and fine-tune the System whenever

necessary, as requested by ISCA or when the appointed vendor deems that tuning

is required, to ensure that the System meets the performance standards.

5.3.11. In the event that the response time cannot be met, the appointed vendor shall carry

out all necessary remedial actions and remedial services at no cost to ISCA. In the

event that the appointed vendor is able to provide evidence that the problem is

caused by a component managed by ISCA, the appointed vendor shall be required

to propose the necessary recommendations to ISCA to resolve the problem.

5.3.12. The System shall be required to run unattended after normal working hours for

system operations such as running of batch jobs and backup of databases.

5.4. System Availability

5.4.1. The Website shall be required to run continuously for 24 hours a day, 7 days a week,

including Saturdays, Sundays and Public Holidays.

5.4.2. The Website Availability Level shall not be less than ninety-nine-point five percent

(99.5%) for each calendar month or part thereof commencing upon the successful

completion of the Performance Guarantee period, except during the time when the

Website is shut down for maintenance.

5.4.3. Website Availability Level is defined as the percentage of the total time during which

the Website is available to the customers and users. It is calculated as:

Website

Availability = ( Actual Total

_ Schedule Website )

X 100% Website Uptime Downtime

Planned Total System Uptime

Planned Total

Website Uptime = (

Number of days for

the calendar month x

24

hours ) -

Scheduled

Website

Downtime



PAGE 17 OF 60

Actual Total

Website Uptime =

Planned Total

Website Uptime -

Unscheduled Website

downtime

Whereby,

Scheduled Website Downtime refers to the unavailability of the System for the month

due to scheduled maintenance approved by ISCA in writing.

Unscheduled System Downtime refers to ad-hoc system maintenance not approved

by the ISCA or CMS failure caused by hardware, operating system, software, abuse,

mismanagement or human errors.

5.4.4. The Website shall be considered inoperable or partially inoperable if any one of the

following conditions is met:

a) Any of the Website server(s) becomes inaccessible;

b) Any of the crucial services on any of the Website servers becomes inaccessible

(e.g. database service becomes inaccessible on the Website server);

c) Any of the crucial services on any of the Website servers does not respond

properly (e.g. images do not load); and

d) Any of the crucial business applications on any of the Website servers becomes

inaccessible (e.g. single sign-on service failure).

5.4.5. The appointed vendor shall provide a report to ISCA with analysis of any problem(s)

that have impacted the Website Availability during the month, covering the root

cause(s), the resolution(s) and mitigation action(s) to prevent future occurrence(s)

when applicable.

5.4.6. The appointed vendor shall be expected to conduct regular System maintenance,

configuration, fine-tuning/optimisation to ensure the Website is always in good

working condition. The appointed vendor shall inform ISCA whenever necessary

upgrades and/or enhancements are required in order to achieve optimal system

performance and required Website Availability.

5.5. System Reliability

5.5.1. The Tenderer shall propose automatic recovery and restart procedures/facilities to

ensure minimum downtime of the System and Website. The Tenderer shall provide

clear instructions on such facilities in the Tender proposal.



PAGE 18 OF 60

5.5.2. All software/hardware shall be fully tested prior to implementation in order to ensure

a maximum level of reliability of the components. It is the appointed vendor’s

responsibility to ensure that the proposal meets the requirement.

5.5.3. The appointed vendor shall ensure that a hardware fault in any of the peripherals

and/or a software fault in a sub-system shall not lead to total system failure. The

System shall be maintained to handle contention and lock handling between

databases and between database tables.

5.5.4. The appointed vendor shall ensure that any failure of any transaction shall not affect

the integrity of the data captured/stored in the System. In the event of transaction

failure, the data shall be rolled back to the beginning of the failed transaction

automatically and dynamically.

5.5.5. The System shall be able to automatically recover all data stored up to the last

successfully completed transaction before a system failure occurs.

5.5.6. The appointed vendor shall ensure that all System enhancements or upgrades are

fully tested and quality assured prior to implementation in order to ensure a maximum

level of reliability of the System and Website.

5.5.7. The appointed vendor shall perform impact analysis based on the regular patches

(for operating system, middleware, etc) updated by the ISCA or changes to

infrastructure (e.g. network backbone, etc) to ensure that the System and Website

still works. If changes are required to make it work in the new environment, the

appointed vendor shall provide it as part of the base service and at no additional cost

to ISCA.

5.5.8. The System shall include online performance monitoring and error analysis reporting

to enable proper capacity planning, tuning and maintenance. Tenderer shall provide

clear illustrations of such monitoring and reporting facilities in the Tender proposal.

5.5.9. The appointed vendor shall ensure that there will be no loss or distortion of data,

interference with system functions, display of erratic information, etc, due to improper

operations by maintenance personnel.

5.6. System Monitoring

5.6.1. The appointed vendor shall propose suitable tools and/or methods to monitor, report

and, where applicable, measure System performance.

5.6.2. The appointed vendor shall closely monitor and promptly take necessary actions to

correct and improve the overall performance of the System to ensure the System is

delivered according to the agreed Response Times.

5.6.3. The System shall as much as possible automate processes required for the

operations of the Website, with the aim to minimise operational requirements.



PAGE 19 OF 60

5.6.4. The appointed vendor shall provide support services including technical advice and

assistance to ensure continuity, availability and accessibility of the Website. The

appointed vendor shall also propose improvements which may result in faster

turnaround time and increase efficiency in delivering the services.

5.7. Backup and Recovery

5.7.1. The appointed vendor shall provide the backup and restoration procedure, and

ensure that they are tested and verified before implementation. The appointed

vendor shall present the test plan/results to ISCA for confirmation.

5.7.2. The backup and restoration procedure shall cater for the recovery of all transactions

and data from the most recent backup. Details shall minimally include information

such as data retention periods, frequency of backup, types of backup (such as

incremental and full backup), what data to backup (such as application data files,

system files), and the process of system recovery from the backups following a

system failure and the relevant fall-back procedures.

5.7.3. The appointed vendor shall ensure that encrypted data shall remain encrypted when

stored to backup media.

5.7.4. The appointed vendor shall ensure that all logs (system, events, warning, etc) are

backed up for audit purposes and in accordance to retention policies.

5.7.5. The appointed vendor shall, together with ISCA ICT Team, perform yearly data

recoverability tests to ensure the recoverability of all data stored on the backup

media. The appointed vendor shall also perform system recovery test to ensure the

recoverability of the System.

5.8. Business Continuity Plan

5.8.1. The appointed vendor shall propose, implement and conduct a suitable business

continuity plan that meets the System Availability, System Reliability and System

Performance requirements.

5.8.2. An annual drill of this plan shall be conducted by the appointed vendor during the

contract period with the involvement of ISCA and their vendors where applicable.

Evidence of a successful drill shall be produced to ISCA.

6. SECURITY REQUIREMENTS


6.1.1. The appointed vendor shall ensure that the System has the capability to prevent

unauthorised access, intrusion, leakage/corruption/loss of information, Software

error and vulnerability to virus attacks.



PAGE 20 OF 60

6.1.2. The appointed vendor shall ensure that appropriate security mechanisms are in

place to protect the confidentiality and integrity of data.

6.1.3. The appointed vendor shall ensure that the System is patched on an on-going basis

when such security patches are released by the software principal in accordance to

the schedule defined in the ISCA IT Security Policies during the entire contract

duration, and maintenance contract duration should ISCA elects to exercise the

option for maintenance.

Type of Patch Deployment upon release of patch

Critical Within 24 hours

High Within 2 weeks

Medium / Low Within 4 weeks

6.1.4. The System shall be free from all known vulnerabilities prior to System

Commissioning.

6.1.5. The System and Website shall not contain any hidden functionalities that ISCA is not

aware of.

6.1.6. The appointed vendor shall ensure no unauthorised installation of software on the

servers other than the software that has been proposed for the System. Any new

software needed to be installed as a result of new requirements shall be subject to

ISCA’s approval.

6.1.7. The appointed vendor shall conduct an impact analysis to identify risks pertaining to

application security and their corresponding mitigation measures. The impact

analysis should be conducted prior to the start of development lifecycle.

6.1.8. The appointed vendor will be responsible for the daily operations management which

include server and database management, backup management, job schedule

management, operating system and database security patch management. The

appointed vendor shall provide the impact assessment of these security patches on

the application when requested by ISCA ICT.

6.1.9. The appointed vendor shall be responsible for any application and the relevant third-

party software security patch management. The appointed vendor shall adhere to

the patch management schedule stipulated above.

6.1.10. The appointed vendor shall conduct System and Website application penetration

testing and ensure all discovered vulnerabilities are rectified before the System Go-

Live.



PAGE 21 OF 60

6.1.11. The appointed vendor shall be responsible to resolve IT security related issues, such

as rectifying vulnerabilities and mitigating risks, at no additional cost to ISCA.

6.1.12. The appointed vendor shall comply with ISCA’s IT Security Policies, Singapore laws

and regulatory policies such as Cybersecurity Bill, Personal Data Protection Act 2012

(PDPA), the General Data Protection Regulation 2016/679 and any other security

policies, standards and guidelines which may be issued from time to time.

6.1.13. A copy of ISCA’s IT Security Policies can be requested from ISCA as a reference for

the purpose of this Tender. The appointed vendor shall sign an undertaking upon

receipt of the above documents declaring that it will only be used for the purpose of

this Tender and all standards/documents shall be returned to ISCA. No duplicates of

the documents are to be made without prior approval from ISCA.

6.1.14. The System shall have thorough validation rules in place to ensure that the System

will not be compromised for any SQL injections attempts or malicious security attack.

6.1.15. Directory browsing on all web servers shall be disabled to prohibit unauthorised

users from gaining information about the server setup.

6.1.16. The appointed vendor shall ensure all administration modules of the System are not

accessible via untrusted networks such as overseas IP addresses.

6.2. Application Security

6.2.1. Architecture

a) The appointed vendor shall implement the System based on a multi-tier

architecture and make sure that the presentation logic, business logic and

database access tier shall be physically separated from the other tiers if the

application software is unable to support the multi-tier architecture. This refers

to having in place a physical network firewall to monitor all incoming and

outgoing network traffic from one tier to the other. In a typical 2-tier or 3-tier

architecture, physical separation is achieved when a physical firewall is

implemented to monitor all network traffic between the application and

database tiers.

b) The appointed vendor shall note that ISCA has the necessary firewall

implemented for the physical separation between the application and database

tiers. The System shall leverage on this existing network infrastructure.

6.2.2. Authentication

a) The System shall have a maximum number of failed authentication attempts

allowed within the application. The maximum number of failed authentication

attempts shall be determined by ISCA.



PAGE 22 OF 60

b) The System shall have account lock-out when the maximum number of

attempts is reached.

c) The System shall log all authentication attempts to the application which

include success and failed logins to the System.

6.2.3. Session Management

a) The System shall have automatic time-out for sessions that are found to be

inactive for a specific period of time. This period shall be determined by ISCA.

b) The System shall have single user logon session to ensure that users cannot

logon to multiple sessions at any given time using the same credentials. A

successful attempt to logon using a user ID that is already logged-on shall

result in the System logging out the earlier logon with an appropriate error

message.

6.2.4. User Account Management and Access Control

a) The System shall provide an access control module for the management of

user access rights to the System. The access control module shall allow the

management of permissions and access privileges to individual users, user

groups or role-based groups.

b) The System shall allow online granting and revocation of user access rights

without affecting normal system operations.

c) The System shall allow the delegation of rights to administer groups of users.

It shall allow ISCA to appoint key system users to manage the access rights of

end users.

d) New user account successfully created shall be defaulted with the lowest level

of privileges. The System shall allow the key system users to grant higher level

of privileges to the end user accounts on needs basis.

e) The System shall allow menu options (functions) to be customised based on

different security profile defined for each user group. Options which the user

group does not have access rights to shall not be displayed.

f) The System shall log all successful and failed access.

g) The System shall be able to generate or export the detailed user access matrix

for the access and privileges granted to individual users, user groups or role-

based groups.



PAGE 23 OF 60

h) The appointed vendor shall ensure that applications and batch jobs do not run

under the administrator account, or have privileges that are higher than

necessary.

i) The appointed vendor shall ensure all test data, test accounts and test

credentials are removed from production system before System

Commissioning.

6.2.5. Application Validation and Protection

a) The appointed vendor shall ensure that the System is designed and

implemented with proper validations and comply with the Open Source Web

Application Project (OWASP) security risk management. The following are the

known vulnerabilities:

• Non-validated input (i.e. input fields shall conform to the desired formats

and values);

• Broken access controls;

• Broken authentication and session management (i.e. use of account

credentials and session cookies);

• Cross-site scripting (“XSS”);

• Buffer overflows;

• Injection vulnerability flaws (e.g. SQL injection, command injection etc.);

• Race condition;

• Improper error / exception handling;

• Insecure storage;

• Denial of service (DOS);

• Insecure configuration management;

• Cross-Site Request Forgery (CSRF);

• Failure to restrict URL access;

• Invalidated redirects and forwards; and

• Insufficient Transport Layer Protection.

b) The appointed vendor shall ensure checks must be carried out to make sure

that the above vulnerabilities are handled correctly in the System before it is

deployed to the ISCA staging and production environment or when major

change is made. Major change refers to a change that 1) impacts the security

function of the System (such as authentication, access controls, logging, etc.);

or 2) has medium or high impact to the System (such as those affecting key

business functions).

c) The appointed vendor shall ensure that all input fields are validated and their

failures are logged.



PAGE 24 OF 60

d) The appointed vendor shall ensure the source codes review are carried out

before System Commissioning or when there are major changes made.

e) The appointed vendor shall ensure that there is timely remediation of all the

findings for the above before System Commissioning.

f) The appointed vendor shall ensure that where applicable, the communication

channels between the System and users, and between the Website and

external systems are properly encrypted (e.g. SLIFT, SSL, TLS, IPSec, SSH,

SFTP, etc.) based on recommended standards.

g) The appointed vendor shall ensure that the software does not contain malicious

codes.

6.2.6. Encryption

a) The appointed vendor shall propose encryption/decryption mechanism for data

protection to ensure integrity and confidentiality protection. All messages and

workflow data sent from the System to users through an open messaging

mechanism, such as e-mail shall be encrypted.

b) Data in transit over the public network shall be encrypted to prevent

unauthorised interception of information via the network.

c) The Secured Sockets Layers (SSL) with key length of at least 128bits shall be

used for the encryption of data communication across public network and

Internet.

6.2.7. Error Handling

a) The appointed vendor shall ensure that the System does not disclose to the

users more information than necessary when a failure or error occurs.

b) The appointed vendor shall ensure that there is proper error handling in the

System with clear and appropriate error messages to facilitate troubleshooting

and error reporting.

6.2.8. Security Testing

a) The appointed vendor shall conduct the necessary security testing which

include system vulnerability assessment, application penetration test, source

code review and error handling and ensure that all the security vulnerabilities

are addressed before the System Commissioning. The appointed vendor shall



PAGE 25 OF 60

ensure that the scope of the security testing shall cover all the known

vulnerabilities listed above.

b) The appointed vendor shall provide the above evidence in the Security Testing

report to ISCA for review and endorsement before the System Commissioning.

6.3. Audit Requirement

6.3.1. The appointed vendor shall ensure that the System developed captures audit trails

of all ‘create’, ‘update’ and ‘delete’ transactions performed. The information to be

logged includes:

a) User ID;

b) Type of event;

c) Date and time of event (includes all failed attempts);

d) Records modified;

e) IP address of user or Computer Host Name of the user; and

f) Last login information (e.g. User ID, date and time).

6.3.2. The System shall also log the following information for all changes to user access

privileges:

a) User ID that made the change;

b) User ID for which the access privilege was changed;

c) Date and time of change; and

d) Details of change made.

6.3.3. The System shall also be able to capture and generate audit information on users

performing excessive document downloading.

6.3.4. The System shall capture audit information on attempts to unauthorised access of

data or System functions.

6.3.5. The System shall have the capability of logging user activities, attempted access,

and security violations. It shall be capable of generating reports of such information.

6.3.6. The System shall log all the activities performed by the security administrators and

audit trail reports shall also be provided.

6.3.7. The System shall have the facility to store the audit information online for varying

periods, depending on the type of audit trails, before they are archived to tapes or

other media. The general guideline would be three (3) months online for database

audit trail and six (6) months online for other audit trails.

6.3.8. The System shall provide capabilities to search/query audit logs and generate audit

log reports.



PAGE 26 OF 60

6.3.9. The System shall be able to generate account administration reports that minimally

include the following information:

a) Number of user accounts registered with the System;

b) Changes in account privileges conducted within a date range;

c) State of user accounts (e.g. dormant, active);

d) User’s abnormally activities such as excessive downloading;

e) Last login information; and

f) List of users with specific access rights.

6.3.10. Audit trail shall be read-only and alternation of such information shall be disallowed.

6.3.11. The appointed vendor shall provide detailed descriptions of the security measures

used to protect the logs from unauthorised modification and deletion and shall ensure

that these measures are implemented.

6.4. Security Measures

6.4.1. The appointed vendor shall ensure that the System is not vulnerable to attacks, by

putting in place security measures (e.g. install anti-virus and malicious code

protection for all servers, apply critical software patches promptly, etc.). For the

purpose of this Tender, appointed vendor may assume that an appropriate anti-virus

or anti-malware software will be supplied by ISCA.

6.4.2. The appointed vendor shall note that the ISCA’s standard security hardening policies

shall be applicable to the System. The appointed vendor shall make an assessment

on the impact of the hardening policies on the System and advise ISCA accordingly

before System Commissioning. A copy of such security hardening policies is

available for viewing onsite upon request.

6.4.3. The appointed vendor shall indicate in the proposal the security measures that will

be deployed in the System to protect ISCA’s data and services rendered by the

appointed vendor to ISCA. The proposal shall address data lost due to unauthorised

access, data transfer, etc.

6.4.4. The appointed vendor shall follow ISCA’s response framework to address any

security incident.

6.4.5. The appointed vendor shall bear all cost that ISCA may incur to recover from any

attack of virus or malicious code, should the source of the attack be determined to

be from the appointed vendor’s managed systems.

6.4.6. The appointed vendor shall maintain strict confidentiality and ensure that all

information pertaining to ISCA’ environment shall not be disclosed to any party

without written authorisation from ISCA.

6.5. Security Audit



PAGE 27 OF 60

6.5.1. ISCA shall engage external security consultant to perform the necessary security

scanning such as penetration testing, server vulnerability assessment and code

scan. Such security audit shall be conducted prior to System Commissioning. In

addition, ISCA may also conduct such security audit from time to time, at a frequency

to be determined by ISCA.

6.5.2. The appointed vendor shall provide all necessary support for the conduct of the audit

at no additional cost to ISCA. The appointed vendor shall also follow-up with the

audit findings, rectify and test the System within the time frame specified by ISCA.

6.5.3. ISCA may conduct surprise checks on the operating environment, operational

procedures, systems documentation, systems configurations etc. The appointed

vendor shall provide all required information and the required assistance to ISCA to

conduct the surprise checks at no additional cost to ISCA.

6.6. Security Requirement for Development Environment

6.6.1. The appointed vendor shall be responsible for the provision, setup, operation and

maintenance of the development and testing environments which will be provided by

ISCA.

6.6.2. The appointed vendor shall ensure that the development environment does not

contain any ISCA classified data or information.

6.6.3. The appointed vendor shall ensure that the development environment does not

contain any production URLs.

6.6.4. The appointed vendor shall ensure that anti-virus or anti-malware protection is

implemented in all servers in the development environment. For the purpose of this

Tender, appointed vendor may assume that an appropriate anti-virus or anti-malware

software will be supplied by ISCA.

6.6.5. The appointed vendor shall ensure that vulnerability and patch management process

is in place on all servers in the development environment.

6.6.6. The appointed vendor shall ensure that all the source codes are free from any

malicious codes or vulnerabilities before installing at the ISCA staging and production

environment.

6.6.7. ISCA may request from the appointed vendor the necessary supporting documents

as evidence of the proper anti-virus and patch management of the appointed

vendor’s development environment. The appointed vendor shall provide such

supporting documents when requested by ISCA.

7. CHANGE REQUESTS

7.1. Overview



PAGE 28 OF 60

7.1.1. The appointed vendor shall implement at the request of the ISCA, all Change

Requests for enhancement to the System.

7.1.2. A request can be considered as Change Request if it needs more than 40 hours of

work. Any request which requires 40 hours or less of work will be treated as

maintenance work.

7.1.3. The aim of the Change Request Management is to ensure that all proposals for

changes to the System and Website are properly evaluated in terms of their priorities,

costs and benefits. Such changes include amendments to the system documentation

and operational procedures.

7.1.4. The Tenderer shall propose a standard man-day rate and man-month rate for all

Change Requests during the contract period. All prices quoted shall be in

accordance with the formats specified in Appendix 1 – Pricing and Charges.

7.1.5. ISCA shall procure the man-days/man-months as and when Change Requests are

confirmed. The appointed vendor’s scope of work for service request shall include,

at minimum, the following:

a) Make an assessment on the Change Request and submit reports to the ISCA

for approval. The study shall detail the impact analysis and will be considered

as part of the operations support and therefore not chargeable;

b) Carry out design, programming and testing work to modify the System and

Website in order to meet requirements of the Change Request;

c) Support the unit testing, system integration testing, interface testing and user

acceptance test of all Change Request, e.g. conduct pre-UAT briefing,

demonstration, prepare the required test data (volume and criteria to be

determined by the ISCA), appointed vendor’s Unit Testing and SIT test results,

test scenarios, test cases, test plan, update the defect consolidated logs, set

up the testing environment(s), etc.;

d) Implement proper version control management on all changes/enhancements

and implement the changes/enhancements to the production environment

successfully;

e) Train ISCA users on the changes to enable them to be competent and self-

reliant in the operations of the System and Website after the changes;

f) Handover the system to ISCA; and

g) Prepare/update relevant documentation to reflect the changes made.



PAGE 29 OF 60

7.1.6. The appointed vendor shall work with ISCA to prioritise the Change Requests

accepted. ISCA reserves the right to re-prioritise any Change Requests given earlier

and ISCA shall not be liable for any additional costs thereby incurred.

7.1.7. All design, development/customisation changes and impact analysis shall be

identified and recorded, verified and validated by the appointed vendor and

submitted to ISCA for review and approval before implementation. The results of the

review of changes and subsequent follow up actions shall be documented at no

additional cost to ISCA.

7.1.8. The appointed vendor shall also provide suitable and adequate formal training and

technology transfer to the users nominated by ISCA after each

enhancement/upgrade to enable them to acquire the necessary knowledge. The

break-down of the cost of such training shall be clearly detailed in the related Change

Request.

7.1.9. The appointed vendor shall provide all documentation and training manuals of the

same version as the products supplied before the implementation of any

enhancement/upgrade of the System and at least two (2) calendar weeks before the

commencement of training respectively.

7.1.10. All efforts spent in the assessment of impact of Change/Service Requests shall be

accounted for under operations support and non-chargeable. All man-efforts

assessment is subject to the approval of ISCA.

7.1.11. The appointed vendor shall unconditionally guarantee that the amended System

supplied complies with the specifications and that all changes performed to the

System shall be free from all defects including defects arising out of faulty and inferior

system design, coding and shall be of the highest quality and fit for the purposes set

out in the Change Requests and the Specifications and additional requirements

agreed upon between ISCA and the appointed vendor.

7.2. Change Request Procedure

7.2.1. The Change Request Procedure that the appointed vendor shall undertake includes

the following activities:

a) Work with the requesting user to raise a Change Request after gathering the

requirements;

b) Estimate the resource costs, detail the impact of changes to the System such

as system performance, system integration, system availability, and elapsed

time for implementing the change;

c) Define and make specific changes to the applied modules of Software,

hardware elements (if any) and the documentation;



PAGE 30 OF 60

d) Provide sign-off for system testing to prove completion of the necessary

changes, unit testing, and system integration testing before releasing the

changes for UAT;

e) Provide UAT test plan, test scenarios, test base, set up UAT environment and

conduct pre-UAT briefing, walk-through and demonstration to users where

applicable. Submission of test plan shall be at least two (2) weeks prior to the

actual conduct of the test or otherwise mutually agreed by both Parties;

f) Support the UAT, rectifying any problems reported promptly and documenting

the defects reported and resolved during the UAT period;

g) Obtain approval from ISCA for migration of changes into the Production

environment;

h) Provide scripts for all program migrations to UAT and Production environments;

i) Ensure that all work carried out must not jeopardise the System availability,

performance, confidentiality, data integrity, data confidentiality and security;

j) Monitor the systems after post implementation of changes to ensure operations

are not being affected;

k) Train users on the system changes to enable them to be competent and self-

reliant in the operation of the system; and

l) Appoint Quality Assurance (QA) Officer to review all deliverables provided to

ISCA.

7.2.2. After reviewing the appointed vendor’s assessment, ISCA shall decide on one of the

following actions:

a) Approve the Change Request based on the assessment;

b) Withdraw the Change Request;

c) Reject the Change Request; or

d) Request the appointed vendor to amend the change requirement

7.3. Turnaround Time

7.3.1. The appointed vendor shall ensure that all Change/Service Requests are assessed,

completed and implemented with the given timeframe as stated below.



PAGE 31 OF 60

Estimated Efforts Assessment of Effort and Impact Analysis1

Completion Time2

Urgent Change Request

Within 1 working day Within 3 working days

Man-day <= 1 Within 1 working day Within 3 working days

Man-day > 1 and <=5

Within 3 working days Within 7 working days

Man-day > 5 and <=10

Within 5 working days Within 12 working days

Man-day > 10 Based on mutual agreement

Based on mutual agreement

1From the day the Change Request is raised to the day that the assessment of effort

is provided.

2From the day the Change Request is approved to the day the Change Request is

completed.

7.3.2. The appointed vendor is responsible for ensuring that accepted Change Requests

are successfully implemented according to agreed schedule based on agreed man-

effort. The appointed vendor shall comply with the agreed schedule strictly, even if

this would include working beyond normal working hours. ISCA shall not be liable for

any additional costs incurred by the appointed vendor.

7.3.3. The appointed vendor shall note that the implementation of a Change Request may

be carried out on a one-time basis or in phases, to be specified by ISCA.

7.3.4. A Change Request shall be considered as successfully completed by the appointed

vendor after the following conditions are met:

a) Completed User Acceptance Test;

b) Appointed vendor’s work has been accepted by ISCA;

c) All relevant documentation is prepared/updated and accepted by ISCA; and

d) Enhanced/new system has been cutover to production environment.

7.3.5. For phased implementation, the System can be cutover to production environment

in phases. The Change Request would be considered completed after all parts of

the changes have been successfully migrated to the production environment and

when all relevant documentation is prepared/updated and accepted by ISCA.

7.3.6. The appointed vendor shall prepare and maintain a Project Management Plan for

each change request that involves more than twenty (20) man-days of effort. This



PAGE 32 OF 60

plan shall detail the proposed development, delivery, installation, testing and

implementation strategy and approach, major milestones as well as how the change

request and quality of the enhancements would be managed. This plan shall be

submitted for approval by ISCA.

7.4. Payment Schedule

7.4.1. The payment schedule for accepted Change Requests shall be as follows:

No. Milestone Percentage to

be paid Cumulative

Total

1 Upon acceptance of Change/Service Request

20% 20%

2 Upon completion of UAT 50% 70%

3 Upon deployment into Production 30% 100%

7.5. System Maintenance and Support Services for Change Requests

7.5.1. All Change Requests constitute part of the System and shall be included in the

System Warranty. However, if the date of completion of the Change Request is less

than three (3) months from the completion of the System Warranty, the appointed

vendor shall provide three (3) months of warranty for all Change Requests

implemented, commencing from the date of completion of the Change Request.

8. PROBLEM ESCALATION, ANALYSIS, RESOLUTION AND

MANAGEMENT

8.1. Problem Management

8.1.1. The appointed vendor shall note that this is applicable during the Performance

Guarantee period (PGP), the System Warranty period and the System Support and

Maintenance period.

8.1.2. The appointed vendor shall provide support for the Website after System

Commissioning. The internal users will email/call the ISCA’s ICT Team, which will

route the Website specific issues to the appointed vendor for resolution.

8.1.3. On a quarterly basis, the appointed vendor shall review all the problems logged and

update the documentation such as FAQs such that they are able to handle at least

80% of the problems reported.



PAGE 33 OF 60

8.1.4. The appointed vendor shall provide a single point of contact for the ISCA to contact

and route System problems/enquiries to the appointed vendor for second level

support.

8.1.5. The second level support personnel provided by the appointed vendor shall have

good knowledge and understanding of the System and ISCA’s environment.

8.1.6. The appointed vendor shall respond to all escalated service calls from ISCA’s staff

during the Support Hours.

8.1.7. The appointed vendor shall take full ownership of all problems related to the

availability of the System; regardless the cause is related to hardware, software,

application or data. In the case that the problem is traced to component(s) not

supplied by the appointed vendor, the appointed vendor shall work closely with the

Hardware, Software, ISCA’s team, and other ISCA appointed vendors to identify the

real problem cause and ensure that the problem is resolved, within the stipulated

turnaround time. Such support from the appointed vendor shall be part of the base

maintenance services for the System and hence carried out at no additional cost to

ISCA.

8.1.8. When problems are encountered such that the System needs to be shut down as

part of the problem resolution, the appointed vendor shall schedule the ad-hoc

downtime after the business operation hours at no additional cost to ISCA.

8.1.9. The classification of the defect or errors in the System and/or Website is classified

and specified below:

Severity Level Definition

1 Impact on Business Operations

a) Inaccessibility to System (full or partial) b) Disruption to operations; or affects majority of users in

ISCA c) Disruption caused by third party services (e.g. IP

blocker) that affects the central services d) Disruptions to integrations/interfaces

Disruption to Public at Large

e) Inaccessibility to Website (full or partial) f) Disruption in the access to members contents, form

submission g) Time-critical (e.g. during campaigns) h) Erroneous transactions (e.g. duplicate deduction of

payment) i) Results or potentially results in negative image or

adverse impact on the reputation of ISCA.



PAGE 34 OF 60

Severity Level Definition

Security Breaches

j) Defacement of web pages k) Theft of restricted or confidential information l) Unauthorised transactions or activities m) Any hacking activities n) Denial of service o) Security attacks (e.g. targeted, sabotage, virus, worm,

or Trojan) which cause adverse impact on ISCA


a) Affects non-critical functionality or when a workaround is available

b) Problems affecting staging, development or training environments, including requests for restoring backups to these environments


c) Some public inconvenience but not time-critical Security Breaches

d) Security attacks (e.g. targeted, sabotage, virus, worm, or Trojan) which do not cause adverse impact on ISCA


a) Disruption of service that has minimal or no impact on ISCA’s ability to perform its function


b) No inconvenience to public Security Breaches

c) Unsuccessful attempts

8.1.10. The service level for each classification of the defect or errors in the System and/or

Website is classified and specified below:



PAGE 35 OF 60

Severity

Level

Response

Time

Target Resolution / Bypass Time

1 Within 30

mins

100% of such problems must be resolved or

provided with a bypass solution within the

recovery time of four (4) hours.

2 Within 2 hrs 100% of such problems must be provided with a

bypass solution within 24 hours and resolved

within the recovery time of one (1) working day.

3 Within 1

working day

At least 90% of such problems must be provided

with a bypass solution within two (2) working days

and resolved within the recovery time of five (5)

working days.

8.1.11. The Severity Level, which measure the overall impact of the problem, shall be jointly

assigned based on the four criteria shown below:

a) Number of users affected;

b) Availability of a bypass or fallback;

c) Type and extent of service disrupted; and

d) Extent of business and operation impact.

8.1.12. ISCA shall have the final decision on the severity level, and this shall be conclusive

and binding to all parties involved in resolving the problem/defect.

8.1.13. There are 2 measurements, namely Response Time and Recovery Time:

a) Response Time

i. The Response Time shall begin from the time or date the problem is

communicated to the appointed vendor’s single point of contact,

regardless of whether the single point of contact acknowledges receipt of

the message.

ii. The Response Time ends when a response is provided by the appointed

vendor for the problem via telephone or electronic mail to the person who

reports the defect.

b) Recovery Time

i. Recovery Time shall begin upon communication of the defect to the

appointed vendor’s single point of contact, regardless of whether the single

point of contact acknowledges receipt of the message.



PAGE 36 OF 60

ii. The Recovery Time ends when the root cause of the defect is resolved

and the system is restored to the satisfaction of ISCA.

8.1.14. The appointed vendor shall track, monitor and report on the reported problems. The

information required to be captured shall include at least the following:

a) Problem description

b) Problem severity level

c) Reporter’s details

d) Date and time of report

e) Date and time at which appointed vendor responds to the problem

f) Details of appointed vendor personnel who attended and resolved the problem

g) Date and time of problem resolution

h) Cause of the problem, components affected and scope of impact

i) Resolution details

j) Preventive recommendations / remarks

k) Highlight problems that are not resolved

l) Measures the time taken to resolve problems of different severity level to

ensure Service Levels have been met for the completion of all problem calls,

etc.

8.1.15. For Severity 1 problem, the appointed vendor shall inform ISCA immediately through

escalation process and shall brief ISCA on the causes, area of impact and lead-time

for recovery. The formal incident report shall be submitted within twenty-four (24)

hours from the time of incident. If an incident is prolonged, the appointed vendor shall

be put up progress reports every four (4) hours and a final report when the incident

is completed. The incident report shall not be sent to anyone other than those

mentioned in the escalation list without prior approval from ISCA.

8.1.16. Time is of the essence in responding to calls for Remedial Support. The appointed

vendor shall take all measures necessary to ensure that the response time stated in

this Specifications is complied with and shall, if requested by ISCA, provide its

personnel with mobile phones or any other equipment which ISCA may require to

ensure that the response time is always complied with.

8.1.17. The appointed vendor shall inform ISCA of the contact persons and contact

telephone numbers of its personnel to whom requests for Remedial Support shall be

made. Any report of a defect in the Website to any person nominated by the

appointed vendor by name or to a person answering to a telephone number supplied

by the appointed vendor pursuant to this Clause shall be deemed to be a request for

Remedial Support contemplated by this Clause.

8.1.18. ISCA may from time to time request the appointed vendor to locate specific type of

problems or calls logged by specific users. The appointed vendor shall be able to

extract and print this information.



PAGE 37 OF 60

8.1.19. All problems/defects shall be tracked. There must be proper acknowledgement of all

reported errors and problems, and monitoring of the status of such errors and

problems by the appointed vendor.

8.1.20. The appointed vendor shall also provide an analysis of the problems encountered

and propose actions to prevent these problems from recurring, and pre-empt similar

problems from occurring.

9. PROJECT MANAGEMENT AND QUALITY ASSURANCE

9.1. General Requirement

9.1.1. The Tenderer shall propose project governance and management structures to

achieve the following objectives:

a) To be overall responsible for the successful planning, transition,

implementation and maintenance of on-going operations;

b) To have clear end-to-end accountability and commitment to ISCA;

c) To recommend and review new initiatives, technology refreshes, or other

proposals to ensure ISCA benefits in terms of cost savings and/or operational

efficiency; and

d) To manage risks and resolve ongoing issues in a timely manner so as to

minimise operational disruptions and/or business impacts.

9.1.2. All sub-contractor vendors and offshore team shall be subjected to the approval of

ISCA.

9.1.3. All local personnel of the appointed vendor and of its sub-contractor vendors who

are involved in the performance of the contract shall be Singapore Citizens,

Singapore Permanent Residents or holders of valid work permits.

9.1.4. A representative of ISCA (“Representative”) shall be assigned throughout the

duration of the project to manage and oversee the contract, timelines and

deliverables.

9.1.5. The appointed vendor shall appoint a Project Manager as the single point of contact

for the overall contract and report to the ISCA’s Representatives.

9.2. Project Organisation and Team Composition

9.2.1. The Tenderer shall submit a project structure clearly defining the duties and

responsibilities and composition (local team in Singapore and/or offshore team, if

any) of all the personnel assigned to the project by the appointed vendor to ISCA.



PAGE 38 OF 60

9.2.2. The Tenderer shall assure local presence of the following critical expertise/skills and

core project roles:

a) Project management

b) User experience design

c) SEO expert

d) Copywriting in accounting, finance and business

e) Information architect

f) Infrastructure architect

g) Database design and administration

h) System integration

i) IT security

j) Tester

k) Quality assurance

l) Technical writing

m) Training

n) Helpdesk support

9.2.3. Each of the personnel in the appointed vendor’s project team shall have the following

knowledge and experience:

a) Minimum two (2) years of direct employment under the appointed vendor;

b) minimum two (2) years of business domain knowledge;

c) prior experience in managing at least one (1) implementation of project of

similar size and scale, preferably during the period of direct employment with

the appointed vendor;

d) good oral and written communication skills; and

e) conversant with the appointed vendor’s methodology, products and/or services

used for this project.

9.2.4. In addition, the appointed vendor shall designate a full-time Project Manager who

shall be overall responsible for the management and co-ordination of this project.

9.2.5. In addition to Clause 9.2.3, the Project Manager shall have the following knowledge

and experience:

a) Minimum five (5) years of project management experience;

b) prior experience in managing at least two (2) implementations of projects of

similar nature, scope, scale and contract value, preferably during the period of

direct employment with the appointed vendor;



PAGE 39 OF 60

c) excellent planning, management, supervisory and communication skills;

d) customer-oriented and possess experience in dealing with requirements from

business perspective; and

e) familiar with the appointed vendor’s adopted methodology, project and services

that the appointed vendor is offering.

9.2.6. ISCA reserves the right to conduct an interview with the designated Project Manager

prior to acceptance.

9.2.7. The appointed vendor shall submit a detailed project structure clearly defining the

duties and responsibilities of all the personnel assigned to the project for ISCA’s

approval in the Project Management Plan. The appointed vendor shall provide the

project with the right level of staffing and skill set and resources to support ISCA to

ensure smooth and timely implementation of the System, and on-going day to day

operation, maintenance and support in the use of the System.

9.2.8. The appointed vendor shall use or employ in and about the execution of the contract

only if such person are as careful, skilled and experienced in their respective

vocations, trades and callings. ISCA shall be at liberty to object to and require the

appointed vendor to remove immediately any such person employed by the

appointed vendor in or about the execution of the contract who in the opinion of ISCA

misconducts himself or is incompetent or negligent in the proper performance of this

duties and whose continued presence is undesirable or unacceptable. Such person

shall not be again used or employed in the performance of this contract without prior

written permission of ISCA.

9.2.9. The appointed vendor shall ensure that the personnel assigned are technically

competent and have good working knowledge of the hardware and software tools

and platforms used for the application systems.

9.2.10. The appointed vendor shall have an office in the Republic of Singapore and have

technical experts residing in Singapore who can provide consultancy and support to

the development and maintenance of the System. ISCA shall not bear any expenses

involved in bringing in overseas expertise to provide consultancy in problem

resolution during the contract period.

9.2.11. In the event that the appointed vendor’s personnel causes errors which may impact

or disrupt services to users (whether due to insufficient testing conducted, lack of

experience of the appointed vendor’s personnel or other reasons), the appointed

vendor shall ensure that the errors are rectified immediately. The additional cost and

man-days required by the appointed vendor to rectify the problem shall be borne

entirely by the appointed vendor.



PAGE 40 OF 60

9.2.12. The appointed vendor shall monitor and manage effectively any sub-contractor

vendor that has been selected in the discharge of their duties to meet the

requirements established. All matters that require liaising between the sub-contractor

vendors shall be coordinated by the appointed vendor.

9.2.13. The appointment of Project Manager and other key personnel, including sub-

contractor vendors, shall be subjected to ISCA’s written approval. The appointed

vendor undertakes not to change its Project Manager or key personnel assigned or

designated as listed in their submission without the prior written consent of ISCA.

9.2.14. The appointed vendor shall acknowledge the receipt of all communication within the

one (1) working day and provide a response within three (3) working days.

9.2.15. The Tenderer shall provide details on project management, team communication,

quality assurance and other liaison with offshore team, if any, as part of effort in

assuring high level quality of project deliverables.

9.3. Responsibilities of Project Manager

9.3.1. The Project Manager shall be the single point of contact to ISCA and is expected to

remain contactable by ISCA at all times. The Project Manager shall be based in

Singapore from the Effective Date to the expiry of the Performance Guarantee

period.

9.3.2. The appointed vendor shall assign a Covering Project Manager in the absence of

the primary Project Manager. This Covering Project Manager shall possess

equivalent or better qualification and experience, and shall be a person of equivalent

or higher authority than the Project Manager. He/she must have good knowledge of

the progress status and issues relating to the contract. This Covering Project

Manager shall be based in Singapore and remain contactable to ISCA during the

period when the Project Manager is absent.

9.3.3. The Project Manager’s main responsibilities include but are not limited to:

a) Assume full responsibility for the quality of services provided by the appointed

vendor’s team and/or sub-contractor vendors. This includes ensuring that there

is consistency and uniformity in the different work produced by his/her team

and sub-contractor vendors;

b) ensure that deliverables are in accordance with the specifications stated in the

contract, and are completed in accordance with the quality and schedule

established in the Project Management Plan accepted in writing by ISCA;

c) oversee the day-to-day project activities;



PAGE 41 OF 60

d) report to the ISCA Representative periodically on the progress of the project.

The frequency of progress reporting shall be determined by ISCA;

e) accountable in all aspects throughout the project life cycle;

f) coordinate and attend various project activities and meetings, including reviews

of each milestone at appropriate junctures throughout the course of the project;

g) organise progress report meeting on a fortnightly basis or such other dates as

agreed between ISCA and the appointed vendor;

h) present minutes of progress meeting within three (3) working days to ISCA for

endorsement;

i) maintain records of all meetings, functional specifications reviews,

development, user acceptance test and maintenance activities including proper

accounting and administrative records of all services performed during the

contract period;

j) manage changes within the project constraints e.g. scope, resource and

schedule; and

k) Manage and address any risks that may arise.

9.4. Project Management Plan

9.4.1. The appointed vendor shall produce and maintain a detailed Project Management

Plan showing the proposed strategy and approach of the complete software life cycle

and the dates of all identifiable activities and milestones necessary for the

commissioning of the System. The appointed vendor shall take into consideration

the deadlines stipulated by ISCA. The Project Management Plan shall be submitted

within two (2) weeks upon the issuance of the Letter of Acceptance.

9.4.2. Upon award of the Tender, the appointed vendor shall update the Project

Management Plan when required to reflect the planned and actual completion dates.

The Plan shall be made available to ISCA for review.

9.4.3. The Project Management Plan shall include activities to be carried out by ISCA as

well as all other personnel whose actions are required. The Project Management

Plan shall include a diagram depicting the reporting structure and the key personnel

who shall be involved in the project. It shall define clearly the Roles &

Responsibilities of all personnel assigned by the appointed vendor to the Project.

9.4.4. The Project Management Plan shall include, at minimum, the following:

a) Project Scope, Objective, Goals and Approach;



PAGE 42 OF 60

b) Project Description and Benefits;

c) Project Organisation including project team structure and roles and

responsibilities of persons;

d) Communications plan;

e) Resource commitment (staffing, equipment, tools);

f) Control and reporting including progress reporting and tracking, project

meetings required, project approval and acceptance;

g) Implementation and delivery schedule including all project critical dates,

milestones and activities;

h) Quality Management;

i) Resource Management;

j) Configuration/Change Management;

k) Risk Management;

l) Procurement Management;

m) Problem (issues, problems, defects) Management Framework; and

n) Project Deliverables.

9.5. Progress Reporting

9.5.1. The appointed vendor shall provide progress and status reports regularly to ISCA’s

Representatives. As a guide, the appointed vendor shall submit weekly progress

report by the first day of the week during the contract period. The final format of the

progress report shall be submitted by the appointed vendor for approval by ISCA’s

Representative(s).

9.5.2. The progress report shall include but not limited to the following:

a) Achievements and deliverables;

b) Action list;

c) Updated project schedule versus baseline project schedule, including

compliance and expected compliance with key milestones;

d) All tasks which are in progress or which were scheduled to begin or end that

week/month;

e) Problems encountered/envisaged and the appointed vendor's

recommendations;

f) Delay(s), if any, the reasons and impact;

g) Change(s), if any, to the project scope;

h) List of service requests and their statuses;

i) Resource utilisation report, such as CPU usage, memory usage, hard disk

capacity, bandwidth utilisation, etc to facilitate capacity planning;

j) Summary of system/application incident reports;

k) Summary of security alert reports;

l) Availability of System software patches, security patch fixes, updates and their

impact;

m) Meeting of service level agreement and performance indicators;



PAGE 43 OF 60

n) Service availability with the analysis of problems that have impacted the service

availability during the month;

o) Risk management; and

p) Any other details requested by ISCA.

9.5.3. The appointed vendor shall also produce ad-hoc progress reports when requested

by ISCA’s representative(s). The report shall cover all tasks which are in progress

or which were scheduled to begin or end that month.

9.5.4. The appointed vendor’s Project Manager shall be responsible for informing ISCA, as

early as possible, of any impending slippage in delivery dates and any matters likely

to impede the progress of the project. The appointed vendor’s Project Manager shall

put forth the recommendations on the alternatives available, subject to ISCA’s

approval.

9.6. Progress Meeting

9.6.1. The appointed vendor shall attend progress meetings in accordance to the frequency

determined by ISCA.

9.6.2. The appointed vendor shall be responsible for establishing the time and agenda, as

well as arranging for each progress meeting. The appointed vendor shall be prepared

for each progress meeting with the necessary details for discussion. He shall also

ensure that all relevant personnel from the appointed vendor shall be prepared for

the meeting.

9.6.3. Regular progress meeting can be expected between ISCA and the appointed vendor

to review the work done and the performance of the appointed vendor’s personnel.

Weekly or daily meetings may be required if progress or targets are not achieved.

9.7. Mobilisation/Replacement of Key Personnel

9.7.1. Replacement of key appointed vendor personnel (for example: the Project Manager)

shall be not permitted, provided that such replacement is not due to staff attrition.

9.7.2. In the event of a need for replacement of key appointed vendor personnel, the

appointed vendor shall seek approval from ISCA in writing at least one (1) month

prior to the date of replacement, indicating the personnel to be replaced, reasons for

the replacement and particulars of the new personnel who will be assuming the

responsibilities concerned. The proposed personnel must be of equal or higher

qualification and skill level of the personnel that is leaving. The appointed vendor

shall also prepare a detailed replacement/handover plan to be submitted to ISCA.

9.7.3. The appointed vendor shall be responsible for training the successor to be technically

competent to carry out the work. The replacement personnel must be available for

at least three (3) calendar weeks for the existing personnel to handover his



PAGE 44 OF 60

responsibilities and duties. The training shall be conducted concurrently with the on-

going normal maintenance support required of the appointed vendor without

affecting the service level. The cost incurred for the provision of the replacement

personnel during the handling over period shall be borne by the appointed vendor.

9.7.4. The appointed vendor shall ensure the transition period is transparent to ISCA and

does not impede the continuity of the project and/or operations.

9.7.5. The appointed vendor’s Project Manager must supply evidence to the

representatives of ISCA that the project handover is duly completed before releasing

the personnel.

9.8. Quality Assurance

9.8.1. The appointed vendor shall prepare a quality assurance (QA) plan for approval by

ISCA to ensure that the System delivered is of high quality. The appointed vendor

must execute the QA plan to the satisfaction of ISCA.

9.8.2. The QA plan shall define how the quality of the System would be assured. It shall

provide the mechanisms to ensure that the project adheres to sound technical

principles and established industry standards.

9.8.3. The QA plan shall cover, at minimum, the following areas:

a) The quality assurance activities and procedures for carrying them out;

b) The standards, practices and conventions to be applied to the project;

c) Appropriate quality assurance process for defect management, change

management, configuration management, etc. The appointed vendor shall

also include the software tools and forms used to support version control of

systems, defect and change tracking, and change management;

d) Duties and responsibilities of project personnel pertaining to quality assurance;

and

e) Fault reporting control and progress.

9.8.4. The QA plan shall include, at minimum, the design of forms or certificates for the

acceptance of the System at each delivery point.

9.9. Performance Indicator(s)

9.9.1. The appointed vendor shall establish a mechanism to collect and analyse

performance indicators (e.g. Service Level). The indicators may be proposed by the



PAGE 45 OF 60

appointed vendor, subject to the approval of ISCA. ISCA may from time to time,

introduce its own measurements for the appointed vendor to adopt.

9.9.2. In the event that the appointed vendor is unable to meet the stipulated service level,

it shall be indicated in monthly progress reports and to propose corrective or

preventive measures in the progress reports.

10. RISK MANAGEMENT


10.1.1. The appointed vendor shall identify the risk and assess security threats associated

with the proposed system and incorporate the controls to mitigate the risks.

10.1.2. The appointed vendor shall submit a Risk Management Plan together with the

Project Plan. The Risk Management Plan shall include minimally the following:

a) Risk identification;

b) Risk assessment;

c) Risk response;

d) Risk control activities; and

e) Risk monitoring and review.

10.1.3. Before the commissioning of the System, the appointed vendor shall conduct risk

assessment wherever applicable.

10.1.4. Upon the completion of the risk assessment, the appointed vendor shall submit the

Risk Assessment Report to ISCA for review and endorsement.

10.1.5. The appointed vendor shall ensure that all risks associated with the System are

addressed before the commissioning of the System.

11. TRAINING


11.1.1. The appointed vendor shall conduct training sessions for all users before the

commissioning of the System. Such training shall take place in the form of

classroom-styled, hands-on, and/or personalised for different groups of users to

enable them to carry out smooth operation and management of the System.

11.1.2. The appointed vendor shall provide training to meet these objectives:

a) To ensure all users and nominated personnel are able to operate and use

effectively the delivered System;



PAGE 46 OF 60

b) To ensure all nominated technical personnel are able to operate and maintain

the System; and

c) To ensure a smooth transfer of knowledge from the appointed vendor to the

nominated technical personnel on the project.

11.1.3. The appointed vendor shall provide suitable and adequate customised training for

staff nominated by the ISCA to enable them to carry out smooth operation and

management of the Website.

11.1.4. The training shall not be limited by the number of user licenses procured. It shall be

customised to suit the following categories of users:

a) Administrators (user and system); and

b) Content editors

c) ISCA ICT staff

11.1.5. The appointed vendor shall provide a full and comprehensive training proposal. This

shall include:

a) Training outlines;

b) Target trainees;

c) Class size;

d) Timetable;

e) Duration

f) Trainee pre-requisites, and

g) Trainer’s profile.

11.1.6. The appointed vendor shall propose the trainers who will be conducting the training

and provide the trainers’ credentials for ISCA’s approval prior to the commencement

of training.

11.1.7. ISCA shall be entitled to accept part or all of the training courses proposed by the

appointed vendor. ISCA may, in its absolute discretion, request the appointed vendor

to modify any training course and/or replace any trainer ISCA finds unsatisfactory.

Upon receipt of such a request, the appointed vendor shall do all that is necessary

to comply with the request at no additional cost to ISCA.

11.1.8. ISCA shall provide all necessary facilities, equipment as well as the premises for the

training. The appointed vendor shall make arrangements for the setup of the System

at ISCA’s premises for these training purposes.

11.1.9. The medium of instruction and training document shall be in English. The appointed

vendor shall provide each trainee with a complete set of printed training documents

and materials for his/her retention. All printing costs shall be borne by the appointed

vendor.



PAGE 47 OF 60

11.1.10. A complete set of instruction guides and training materials in hardcopy and softcopy

shall be made available to ISCA. ISCA shall approve the materials proposed and

have the right to use these training materials to conduct in-house training for its

users.

11.1.11. The appointed vendor shall update the training documents and materials in

accordance with changes made to CMS at no additional charges to ISCA.

11.1.12. The appointed vendor shall provide training to ISCA for major software release

changes or upgrades, if deemed necessary by ISCA, at no additional cost to ISCA

during System Warranty and System Maintenance and Support Periods.

11.1.13. The appointed vendor shall quote, as an option to procure, on-demand training

session(s) to be conducted during the warranty and maintenance phase of the

System. Such training could be refresher courses or introductory courses for new

staff or administrators.

11.2. Feedback and Evaluation

11.2.1. The appointed vendor shall be responsible for administering all the training sessions,

e.g. registrations of Participants, class attendance sheets, training feedback forms

collation etc.

11.2.2. Training feedback forms shall be distributed to all Participants in all training sessions.

These shall be collected and handed over to ISCA for review.

11.2.3. In the event where the feedback gathered on any training conducted by the

appointed vendor is below average rating, ISCA has the rights to request for a re-

training at no additional cost to ISCA.

11.3. Schedule

11.3.1. All training courses offered shall be completed before the commissioning of the

System. The training schedule shall be submitted in advance for discussion and

agreement with ISCA.

12. DOCUMENTATION


12.1.1. The appointed vendor shall supply and deliver a set of systems/technical and

operations documentations (e.g. functional specifications, design specifications and

technical/operations specifications) for the System at the various milestones along

the duration of the contract. The appointed vendor shall ensure that all

documentations are well managed and maintained as well as kept up-to-date at all

times with proper document management like document versioning features.



PAGE 48 OF 60

12.1.2. The appointed vendor shall be responsible for the provision of adequate and suitable

documentation with respect to the System. All documentation shall be completed

and delivered to ISCA within the specified project schedule.

12.1.3. All documentation provided and maintained by the appointed vendor shall be in good,

simple and concise English using accepted technical terms and symbols.

12.1.4. All documents shall be made available in softcopy for ready reference and

subsequent maintenance. All such documents shall have comprehensive indexes to

facilitate quick reference. For maintainability, all such documentation must be

converted to the latest version of the documentation tool in use, if so required by

ISCA. If additional tools are required for the preparation of special documentation,

the appointed vendor shall propose the appropriate tools to be used, subject to

ISCA’s approval.

12.1.5. The Tenderer shall propose the various tools (e.g. data modelling tools, document

editing tools) used for maintaining the documentations or documents covered in this

Tender. The use of such tools for this contract is subject to ISCA’s approval.

12.1.6. The appointed vendor shall provide softcopy documentations which are properly

arranged and sorted.

a) Upon any change/update to the System, the appointed vendor shall update the

existing documentation or produce new documentation. All documentation

must be updated and approved by ISCA within one (1) month from the Go-Live

date unless otherwise agreed in writing by ISCA.

12.1.7. The appointed vendor shall establish a proper document change procedure to keep

track of the changes done to the documents. The reasons for the changes, last

update date and the name of the personnel who has made the last update should be

clearly documented. Proper versions of the documents have to be kept.

12.1.8. All documentation provided shall display the date of document release and the

version number of the document release on its cover page.

12.1.9. The appointed vendor shall provide draft versions of the documentation for ISCA’s

review before delivering the final version of the documentation to ISCA for approval.

The appointed vendor shall cater at least two (2) weeks for each review, unless

otherwise agreed in writing by ISCA.

12.1.10. All initial draft versions of documents submitted to ISCA for review and acceptance

shall begin at Version 0.1, followed by Version 0.2 onwards with increments of 0.1 at

each version revision. Only signed-off versions or versions deemed accepted by

ISCA shall be set at Version 1.0 as the baseline version.



PAGE 49 OF 60

12.1.11. Each page of the document shall have its classification type stamped or typewritten

in the centre, top and bottom of the page.

12.1.12. The appointed vendor shall provide documentation and manuals of third party

hardware, software and equipment.

12.1.13. All documents produced by the appointed vendor in fulfilling this contract shall

become the property of ISCA. ISCA reserves the right to reproduce at no cost, any

documentation supplied with the proposed services for its own use. Prior approval

must be obtained from ISCA for any reproduction and distribution of documents

produced by the appointed vendor.

12.1.14. ISCA shall have the right to use any of the appointed vendor’s standards,

methodology, procedures and approaches delivered under this contract solely for the

purpose of ISCA.

12.2. Project Documentation

12.2.1. The appointed vendor shall deliver the following documentation:

a) Document Master List (which includes all manual and documentation of the

system)

b) Project Management Plan (which includes Project Risk Register, Problem

Escalation and Resolution Management);

c) System Requirement Specifications and Functional Specifications (hardcopies

to be provided);

d) Design/Configuration Specifications (which includes system interface

specification) (hardcopies to be provided);

e) Prototype Specifications;

f) Program Specifications and Source Codes for customisation;

g) Data Conversion and Migration Specifications, Test Plans and Test Reports;

h) Performance Test Plans, Test Package and Test Reports;

i) System Integration Test Plans, Test Package (Detailed Test Cases) and Test

Reports;

j) User Acceptance Test (UAT) Plans, Test Package (Comprehensive and

Detailed Test Cases) and Test Reports;



PAGE 50 OF 60

k) System Security Acceptance Test (SSAT) Plans and Test Reports;

l) Hardware and Software Configuration Management;

m) Quality Assurance Plans;

n) Deployment Plans;

o) Contingency Plans;

p) Installation Plans and Installation Manuals;

q) User Manuals and Editorial and Design Style Guides (soft and hard copies to

be provided);

r) Training Manuals;

s) Database Documentation (Including data dictionary);

t) System Architecture Documentation;

u) Code Release Management & Deployment Plans;

v) Change Management and Communication Plans;

w) System Handover Plans;

x) Exit Plans;

y) Performance Guarantee period Reports; and

z) System Support Plans and Procedures/Operations Manuals (Including System

Administration).

13. TRANSITION AND EXIT MANAGEMENT


13.1.1. This shall be applicable in the event that the System is to be handed over to a new

appointed vendor for maintenance or upon termination of the contract.

13.1.2. The appointed vendor shall be given advance notice to hand over the Services to

the new contractor appointed by ISCA, before the expiry or termination of the current

contract.



PAGE 51 OF 60

13.1.3. In the event of expiry of the contract or termination of services of the appointed

vendor, the appointed vendor shall ensure that the services to ISCA are not disrupted

and that a smooth hand-over of services is affected, either to ISCA or to the new

contractor as may be nominated by ISCA.

13.1.4. The cost of hand-over of services should not exceed $5,000.

13.1.5. The appointed vendor shall conduct a thorough review of the operational status of

the System and the prevailing service level including all outstanding project service

status. This shall be documented comprehensively to the satisfaction of ISCA. The

appointed vendor shall be required to review the status with ISCA and any persons

nominated by ISCA at such meetings as ISCA deems necessary for this purpose.

13.1.6. The appointed vendor shall comply with any direction from ISCA for assistance in

relation to any aspect of hand-over of the information systems resources, including

without limitation, human and technical assistance and the furnishing of such reports

or updates in such form as may be required by ISCA. The appointed vendor shall

give all necessary assistance to facilitate continuity in the operations of ISCA which

depend on successful maintenance of its information systems operations.

13.1.7. Upon termination of the contract, the appointed vendor shall bear all expenses

incurred, including expenses in relation to handing-over of or transitional

arrangements for or relocation of any of the Services under the contract.

13.1.8. The appointed vendor shall complete defect management and corrective

maintenance for all defects discovered during the contract period before handing

over to the new contractor.

13.2. Transition Management

13.2.1. The appointed vendor shall hand over the responsibilities of maintaining the System

to a new contractor appointed by ISCA upon the expiry or termination of the contract.

13.2.2. The appointed vendor is advised that the purpose of the transition is to ensure and

achieve a smooth hand over of responsibilities. The appointed vendor shall ensure

that the entire transition phase is as transparent as possible to ISCA’s users and the

users shall not experience any disruption of services.

13.2.3. The appointed vendor shall hand over all items owned by ISCA to the new contractor

including the following:

a) Assets (hardware, software, media, documentations, licenses, storage media

etc.)



PAGE 52 OF 60

b) Full set of up-to-date documents describing ISCA’s configuration, asset

records, operating environment, operating manuals, accounts & passwords,

contact information etc.

13.2.4. The exit transition period shall be managed and supervised by ISCA. The appointed

vendor shall conduct regular progress meeting with ISCA to track the progress of the

transition.

13.2.5. The appointed vendor shall be responsible to conduct a detailed hand-over, inclusive

of briefing and training sessions, of the complete System and relevant operational

requirements to ISCA and the new contractor.

13.2.6. The appointed vendor shall also allow the new contractor to shadow during the

transition period. However, the appointed vendor shall remain fully responsible and

accountable for ensuring the smooth on-going operation of the system and deliver

all required services according to the contractual requirements stipulated in the

contract during the transition period.

13.2.7. The briefing with the new contractor for the System shall be completed one (1)

working month before the expiry of the maintenance contract.

13.2.8. The briefing and trainings shall be conducted in Singapore and shall be conducted

in English by the appointed vendor.

13.2.9. In the last one (1) month of the System Warranty and/or Maintenance period, the

appointed vendor shall supervise the new contractor and personnel designated by

ISCA in performing the daily operations of the System.

13.2.10. The appointed vendor shall complete all outstanding tasks and activities required of

the appointed vendor. For outstanding tasks that may extend beyond the contract

period, ISCA shall decide if such tasks should be handed over to the new contractor.

13.2.11. The appointed vendor shall also perform an end-of-contract baseline update, which

shall contain all the changes to the System that have been made during the contract

period. The appointed vendor shall in accordance with the requirements of

configuration management ensure completeness and proper configuration

management of this baseline and submit it to ISCA for auditing and acceptance.

13.2.12. The appointed vendor shall work closely with the new contractor to ensure no

degradation in Service Levels or disruption to services.

13.2.13. The appointed vendor shall remain fully responsible and accountable for ensuring

the smooth on-going operations and deliver all required Services stipulated in the

current contract, while going through the transition process. The appointed vendor

shall bring in the relevant resources at no cost to ISCA to cover the daily operations

if required so as not to degrade the System performance during the transition period.



PAGE 53 OF 60

13.2.14. The appointed vendor shall duly document all items comprising the System, including

hardware, software, backup media and login account information, in both hard and

editable softcopy in Microsoft Office file format. The appointed vendor shall ensure

the accuracy and completeness of information documented and handed over to the

new contractor.

13.2.15. If the appointed vendor demonstrates unwillingness in cooperating fully with the new

contractor to achieve a smooth transition process, ISCA reserves the right to further

extend the transition period until the whole transition process is completed; the

appointed vendor shall then bear the full cost incurred as a result of the extension.

13.2.16. The appointed vendor shall complete all outstanding tasks and activities required of

the appointed vendor. For outstanding tasks that may extend beyond the contract

period, ISCA shall decide if such tasks should be handed over to the new contractor.

13.2.17. ISCA shall furnish in writing a letter to discharge the appointed vendor of their

obligations under this contract at the end of the Transition Phase.

13.3. Exit Plan

13.3.1. The appointed vendor shall propose and deliver an Exit Plan within three (3) months

after the Commissioning Date. The Exit Plan and the detailed schedule shall be

subjected to the approval of ISCA.

13.3.2. The Exit Plan shall include, at minimum, the following:

a) Processes and procedures (for example, operational, security, business

functions etc.);

b) Roles and responsibilities;

c) Definition of major milestones;

d) Schedule for completing / hand-over of outstanding tasks;

e) Updated Application and Systems documentation;

f) Updated User and Operation manuals;

g) Contact list of appointed vendors providing second level escalation support;

h) System, Hardware, Application, Systems documentation (schedule of

updates);

i) Cost implication of handling any proprietary appointed vendor’s tools with

respect to licensing;



PAGE 54 OF 60

j) Conduct briefing to the new contractor;

k) Allow shadowing to the new contractor (for example, the new contractor will be

on-site to observe how the appointed vendor execute specific tasks, reviewing

of systems logs);

l) Security procedures;

m) Deliverables like outstanding problem logs, list of tasks in progress;

n) Define the work-in-progress i.e. on-going tasks, other pending tasks and

problems that have not been resolved or followed up by the existing appointed

vendor;

o) How ISCA or new contractors appointed by ISCA will be phased in to take over

the System;

p) “parallel run” period whereby all enquiries/problem calls will be directed to ISCA

or succeeding contractor while the incumbent appointed vendor is still around.

q) Commitment of the appointed vendor before exiting.

13.3.3. The Project Manager shall ensure that the Exit Plan is developed, the team is

appropriately staffed, and the plan is executed in an orderly manner to achieve

ISCA's business objectives.

13.3.4. The Exit Plan shall be reviewed and updated at the end of each contract year as well

as three (3) months before the end of the contract.

13.3.5. The exit transition period shall be managed and supervised by ISCA.

13.3.6. The appointed vendor shall duly hand over all documentation of the infrastructure,

hardware, system software, database and application software, source codes and

records service requests and problem resolution required for the effective

maintenance of the systems, and all other properties owned by ISCA. Any missing

items shall be replaced or produced at no additional cost to ISCA.

13.3.7. The appointed vendor shall also perform an end-of-contract baseline update, which

shall contain all the changes to the System that have been made during the

maintenance contract. The appointed vendor shall in accordance with the

requirements of configuration management ensure completeness and proper

configuration management of this baseline and submit it to ISCA for auditing and

acceptance.



PAGE 55 OF 60

13.3.8. During transition, the appointed vendor shall remain fully accountable for the service

delivery and must continue to provide all Services stipulated in this Tender

professionally. Should the appointed vendor demonstrate inadequacy or

unwillingness to co-operate with ISCA and/or new contractor appointed by ISCA,

ISCA reserves the right to further extend the Transition Phase until the whole

transition process is completed to the satisfaction of ISCA. The appointed vendor

shall bear the full cost incurred as a result of this extension.

13.3.9. ISCA reserves the right to forfeit the charges payable to the appointed vendor if the

latter fail to provide the required Services to the satisfaction of ISCA during the

Transition Phase.

13.3.10. The Project Manager shall ensure all security passes and items belonging to ISCA

are returned by all personnel. Each personnel shall duly sign an exit clearance and

declaration form.

13.3.11. All accounts and rights assigned to the appointed vendor shall be handed over to

ISCA or to the new contractor appointed by ISCA to take over the Services.

13.3.12. In the last one (1) month of the System Warranty period or the Maintenance period,

the appointed vendor shall oversee the new contractor and personnel designated by

ISCA in performing the daily operations of the System.

14. SYSTEM MAINTENANCE AND SUPPORT SERVICES

14.1. General Requirement

14.1.1. The Support Hours for the System shall be 8.30 a.m. to 6.00 p.m. from Mondays to

Saturdays, exclude Sundays and Public Holidays.

14.1.2. The Operating Hours for the Website shall be twenty-four (24) hours a day, seven

(7) days a week, inclusive of Sundays and Public Holidays.

14.1.3. The appointed vendor shall provide the following types of maintenance and support

services:

a) investigation and correction of defects in the software as reported by ISCA

including temporary corrections and bypass of the defects until such time as

standard corrections and/or updates of the software are available ("Remedial

Support");

b) installation, testing and the implementation of standard corrections, updates,

supply and installation of new versions and new releases of the software and

updating of related documentation and materials;

c) rendering advice on the performance tuning of all items of Software;



PAGE 56 OF 60

d) recovering lost data, restoration and repair of damaged data and the correction

of erroneous data to the extent possible;

e) restoring the System to an operable state where System Downtime is

attributable to Software defect or error;

f) rendering advice and guidance to ISCA in the use of the System;

g) at the request of ISCA to provide training in the use of the System;

h) informing ISCA of all future updates and new releases of the System within one

(1) calendar week of their release for general distribution and, when so

requested by ISCA, supplying and installing the relevant update and releases

within four (4) calendar weeks of receipt of ISCA's request;

i) providing ISCA with all necessary documentation needed for the maintenance

of the System including all necessary updates of the same;

j) providing other software support services including technical advice and

assistance as may be required by ISCA from time to time; and

k) providing unlimited telephone and onsite support.

14.1.4. For the avoidance of doubt, cost of software or license upgrade, new versions and

updates are to be borne by the appointed vendor.

14.1.5. The appointed vendor shall provide the maintenance and support services from the

appointed vendor’s premises. ISCA shall not provide facilities for the appointed

vendor to conduct such services.

14.2. Remedial Support

14.2.1. Remedial Support shall be provided during Support Hours.

14.2.2. On receipt of information from ISCA of a defect or an error in the System, the

appointed vendor shall immediately look into the defect(s) or error(s) within two (2)

hours of the time the information from the Customer was received.

14.2.3. Time shall be of the essence in responding to calls for Remedial Support. The

appointed vendor shall take all measures necessary to ensure that the response time

stated in the maintenance contract is complied with and shall, if requested by ISCA,

provide its personnel with communication equipment. Support Hours’ rates shall

apply if the receipt of information from ISCA of the defect or error in the System is

within two (2) hours from the end of the Support Hours.



PAGE 57 OF 60

14.2.4. The appointed vendor shall inform ISCA of the contact persons and contact

telephone numbers of its personnel to whom requests for Remedial Support shall be

made. Any report of a defect in the System to any person nominated by the appointed

vendor by name or to a person answering to a telephone number supplied by the

appointed vendor pursuant to this Clause shall be deemed to be a request for

Remedial Support contemplated by this Clause.

14.2.5. Where the appointed vendor is not able to remedy the defect or error or successfully

implement a temporary correction or bypass within four (4) hours, the appointed

vendor shall, without any cost to ISCA and upon request of ISCA, engage the

services of an independent expert, who may be an employee or agent of the

developers of the particular defective Software, to remedy the defect or error and/or

effect a temporary correction or bypass. The independent expert shall arrive and

commence work within four (4) days of the request for Remedial Support.

14.2.6. Forthwith upon such remedies being completed, the appointed vendor shall update

the corrected version of the object code of the Software in machine-readable form

for loading on to the Hardware together with appropriate amendments to the

Documentation, if any, specifying the nature of the correction and providing

instructions for the proper use of the corrected version of the Software on the

Hardware.

14.3. Ad-Hoc Support

14.3.1. Ad-hoc support refers to support requests that are not covered under full

maintenance support. Ad-hoc support could include services such as one-off testing,

setup for new system functionalities or application development/support for special

events.

14.3.2. ISCA shall raise Requisition Form (RF) for the appointed vendor to carry out the ad-

hoc support.

14.4. System Maintenance and Support Plan

14.4.1. The appointed vendor shall produce and maintain a detailed System Maintenance

and prior to the date of System Commissioning, showing the scope of work, contacts,

deliverables and implementation strategies. The System Maintenance and Support

Plan shall be approved by ISCA.

14.4.2. The System Maintenance and Support Plan shall include activities to be carried out

by ISCA, as well as all other personnel whose actions are required. The System

Maintenance and Support Plan shall include a diagram depicting the reporting

structure and the key support personnel who shall be involved in the support

services. It shall define clearly the roles and responsibilities of all personnel assigned

by the appointed vendor and how each project team shall interact with one another

to deliver the desired services.



PAGE 58 OF 60

14.4.3. The appointed vendor shall maintain the System Maintenance and Support Plan

during the system maintenance phase after the delivery of the System.

15. INFORMATION IN THIS DOCUMENT

15.1. Every piece of information in this document is provided to the best of ISCA’s knowledge

and is privy to the intended recipient of this document. All Specifications are subject to

change. ISCA reserves the right to issue any addendum or corrigendum to this Tender.

15.2. No part of this document, or any information contained in this document, may be

disclosed, published, or reproduced without written permission from ISCA

16. DISCLAIMERS

16.1. ISCA shall be under no obligation to accept the quotation with the lowest quote or

enter into correspondence with any tenderer regarding the reason for non-

acceptance of quotation.

16.2. ISCA reserves the right, unless the tenderer expressly stipulates to the contrary in

its quotation, to accept only such portion(s) of a quotation as ISCA may in its sole

discretion decide and the quotation shall be adjusted accordingly.

17. ENQUIRIES

17.1. For any enquiry or submission, please email to [email protected] with the

subject "ICT-29-2019" before the closing date.

Closing date: 30th December 2019, 5pm


PAGE 59 OF 60

APPENDIX 1: PRICING AND CHARGES

TABLE 1: WEBSITE AND CMS DEVLOPMENT SERVICES

S/N Items UOM Quantity Cost in S$

(Excluding GST)

Remarks

Mandatory

1 Professional Services Unit 1

2 Analysis of completed research and designs

3 Hi-Fidelity Prototype

4 Develop CMS Templates/ Widgets

5 UAT and Content migration (First 100 pages)

6 PGP and 1-year warranty

Optional

A After office support of sixty (60) man-hours Man-hour 60

B One-year maintenance and support services after

Warranty

Year 1

C Content migration Pages 50

Note:

1. All prices are to be quoted in Singapore dollars.

2. All cost shall exclude GST.

3. All costs shall be itemized.

4. All volume discounts (if any) must be clearly stated. All costs shall be itemized.

5. Number of hours per man-day is 8 hours. In case of partial utilisation, bulk man-hour cost will be pro-rated accordingly


PAGE 60 OF 60

Table 2: MANPOWER RATES FOR ADDITIONAL WORK ORDER/SERVICE REQUESTS

S/N

Items

UOM

Unit Cost in S$/Man-

Days (Excluding

GST)

QTY Total Cost

(Excluding GST)

1 Service request man-day on a pay-per-

use basis

Man-day 1

2 Block of 100-man days to be utilized for

professional services during the

duration of the contract

Man-day 100

Note:

1. All prices are to be quoted in Singapore dollars.

2. All cost shall exclude GST.

3. All costs shall be itemised.

4. All cost shall include warranty.

5. The appointed vendor shall provide manpower rates for additional works orders / service requests required.

6. Development work is done at appointed vendor’s site and the appointed vendor shall setup their own development environment.

7. Number of hours per man-day is 8 hours. In case of partial utilization, bulk man-hour cost will be pro-rated accordingly

8. Minimum service hour chargeable is 1 hour.

ITQ ICT-29-2019 Date: 29th Nov 2019 Title: Phase 2 ......b) Phase 2: Development of Corporate...

Documents

Transcript of ITQ ICT-29-2019 Date: 29th Nov 2019 Title: Phase 2 ......b) Phase 2: Development of Corporate...