TEMPLATE FOR iCAMPUS PROPOSAL.pdf

INSTITUTION LOGO

INSTITUITON NAME /ICampus v1.0 Confidential Document (Strictly only for INSTITUTION NAME)

i

Proposal for INSTITUTION NAME For Campus Management System STRICTLY CONFIDENTIAL

Date :

Version No. : 1.0

Prepared by : Consoci8 Sdn Bhd

All rights reserved.

All proposed concepts, ideas, designs and copy writing belong to Consoci8 Sdn Bhd until the

project is confirmed. No part of this documentation may be copied, photocopied, translated,

microfilmed, or otherwise duplicated on any medium without the written consent of Consoci8

Sdn Bhd. All product names referenced herein are trademarks of their respective companies

INSTITUTION LOGO


ii

Document Control

Version No.

Version Date

Description Done By Change from Previous Version

1.0 Initial document Consoci8 Sdn Bhd

-

INSTITUTION LOGO


iii

Proposal Approval

The proposal of the above title has been evaluated and approved by the evaluation

committee. It is understand that any major modification of the proposal requires approval by

the committee.

Evaluation Committee:

Name Title Signature Date

INSTITUTION LOGO


iv

Table of Contents

1 Executive Summary .......................................................................................... 1

1.1 About Consoci8 ..................................................................................................... 1

1.1 IIUM ....................................................................................................................... 1

1.2 MDeC iShare and iKlip .......................................................................................... 1

1.3 Recruitment Management System for Career Channel Sdn Bhd ........................... 2

1.4 www.socialwalk.com .............................................................................................. 2

1.5 MDeC eServices Platform (http://eservices.mscmalaysia.my) ............................... 3

1.6 MDeC Manpower Requsition System .................................................................... 3

1.7 CyberSecurity Malaysia (CSM) Project Management and Monitoring System

(PMMS) ............................................................................................................................. 3

1.8 Universiti Kebangsaan Malaysia - Psikometrik Indeks Keusahawanan Nor Aishah

(PIKEN) – www.piken.com.my ........................................................................................... 4

1.9 Sapura Social Network Intranet ............................................................................. 4

1.10 Bridges Talent Management Consultant (Brunei) Website - http://www.bridges-

tmc.com/ ............................................................................................................................ 5

1.11 Unitar Intranet ........................................................................................................ 5

1.2 Overview of Proposed Solution .............................................................................. 5

1.3 Project Assumptions .............................................................................................. 8

2 Content .............................................................................................................. 9

2.1 Proposed Scope of Work ....................................................................................... 9

2.2 Proposed Solution ............................................................................................ 2

2.2.2 Online Application .................................................................................................. 6

2.2.3 Lecturer / R&D ....................................................................................................... 7

2.2.4 Program & Courses ............................................................................................... 8

2.2.5 Finance.................................................................................................................. 9

2.8 Ruby on Rails (ROR) Framework ........................................................................ 13

3 Project Approach ............................................................................................ 14

3.1 Proposed Approach and Methodology ................................................................. 14

4 Proposed Documentation .............................................................................. 25

INSTITUTION LOGO


v

5 Proposed Project Timeline & Resource Planning ........................................ 27

5.1 Proposed Project Timeline ................................................................................... 27

5.2 Resource Planning .............................................................................................. 27

6 Project Costing ................................................................................................ 30

6.1 Introduction .......................................................................................................... 30

7 Project Organization Structure and Team Members .................................... 30

8 Attachment 1 ................................................................................................... 32

INSTITUTION LOGO

INSTITUTION NAME/iCampus Confidential Document (Strictly only for INSTITUTION NAME)

1

1 Executive Summary

1.1 About Consoci8

Company Profile

Consoci8 Sdn Bhd was incorporated in 2008 with the vision to establish our presence in

Web 2.0 world and bettering human lives through exploring ideas and technologies in

Information Technology. We were selected as the best pre-seed company in 2009 as having

the best sales performance and have grown to develop our own products in 2012. Our team

has an accumulative experience of more than 15 years in the IT industry. Our team

members have worked for huge government projects such as Immigration projects, Pension

Division project, Customs eDeclare and ePermit projects. We always believe that we would

make a difference in community and in doing that through our mission of implementation of

products that our customers enjoy using and products that our team enjoys making.

Our previous project references show an overview on our product and services offered. CS8

are very proud of the projects that we have successfully completed for our clients. The

projects are:

1.1 IIUM

Revamp of IIUM external and internal website involved rebuilding the existing

website structure that was not successfully completed by a previous vendor. It

included both logical and physical restructuring of the existing systems so that

meaningful information is presented to visitors. Careful consideration was taken

in order to make sure that the website is extensible in the future and allows for

integration that would be required by further plans of the client.

Contact Details: Hairul Laila

Head of Project Based for Applications

International Islamic University Malaysia

[email protected]

1.2 MDeC iShare and iKlip

The project was initiated with the need of a platform for MDeC personnel to

reach for up to date information of news, events and activities within MDeC. The

scopes for the iShare are to customize the content management system (CMS)

as to allow MDeC Internal Communication unit to update information such as

latest news, events and opinion polls. In addition to the news dissemination

mailto:[email protected]

INSTITUTION LOGO


2

functions, iShare also has the capabilities such as employee directory, libraries,

integrated to HR Avenue and Active Directory for single sign on. Meanwhile, the

iKlip is an extension of the iShare with the capabilities of alerts and management

shoutout.

Contact Details: Noreen Sabrina binti Mohd Noor Head of Marketing and Internal Communications Multimedia Development Corporation (MDeC) [email protected]

1.3 Recruitment Management System for Career Channel Sdn Bhd

In order to better track and manage job applications for client 's recruitment,

Career Channel Sdn Bhd has commission CS8 to implement and support the

recruitment management system. The system implemented has the capabilities

such as:

1. Having a centralized databanks of job applicants with the related information

2. The system accessed via the internet.

3. Automated workflow

4. Automatic email notification

5. Powerful searching capabilities with options for quick searching, advance

search, saved search criteria and sorting based on experience, date,

specialization or qualifications.

Contact Details:

Mr. Louis Tham

Senior Consultant

Career Channel Sdn Bhd

[email protected]

1.4 www.socialwalk.com

In collaboration with Greyattic Sdn Bhd, we successfully developed and

managed an event management and collaboration tools for event organizers to

market, capture and received payment online for their events. The project has

already being used for major events such as MSC Malaysia Kre8tif! Digital

Content Conference and Global Entrepreneurs’ Congress 2009. The product is

live and from time to time, we are improving it based on users’ feedbacks.



http://www.socialwalk.com/

INSTITUTION LOGO


3

Contact Details:

Tham Keng Yew

CEO, SocialWalk

[email protected]

1.5 MDeC eServices Platform (http://eservices.mscmalaysia.my)

The project initiated to allow mash ups of multiple applications by multiple

vendors of MDeC to serve to its clients with one single platform. The eServices

platform allows the plug and play concept of applications whereby the

applications transparently viewed by the users in the platform within a single

sign-on feature.

Contact Details:

Pn. Normarinee Mohd Nor

Head of ICT Department

Multimedia Development Corporation (MDeC)

[email protected]

1.6 MDeC Manpower Requsition System

The project is a basis for MDeC’s Managers, HOD and Division Head to reach

the human capital requisition services through:

A single authentication and profiling system through MDeC’s Active Directory.

Managers and HOD to request manpower.

Approval process to Division Head.

HCD to verify and published the manpower request to MDeC’s intranet.

MDeC’s staffs apply for the published post through the MDeC’s intranet.

Attachment of the required documents such as JD and resumes.

The lifecycle of the RFA process.

Contact Details:

Siti Saljura Shamsuddin

Manager, Internal Mobility and Rewards

Multimedia Development Corporation (MDeC)

[email protected]

1.7 CyberSecurity Malaysia (CSM) Project Management and Monitoring System

(PMMS)


http://eservices.mscmalaysia.my/



INSTITUTION LOGO


4

The project was initiated by CSM to improve the monitoring of projects within its

purview which allows CSM to:

To better control and execute projects in which it monitors

The project manager can assign project team members either from internal or

external sourced

The project members to update the status and monitor the task assigned

Project members to upload files and materials within the projects.

Contact Details:

Suzana Abd Rahman

Strategy Management, Corporate Planning & Strategy Division

CyberSecurity Malaysia

[email protected]

1.8 Universiti Kebangsaan Malaysia - Psikometrik Indeks Keusahawanan Nor Aishah (PIKEN) – www.piken.com.my

The Psikometrik Indeks Keusahawanan Nor Aishah (PIKEN) project was initiated

with the intentions to allow UKM-CESMED to offer commercialization of

education research to companies and the general public. PIKEN was a result of

years of research by Prof. Dr. Noraishah to measure the inclination of a person

to be an entrepreneur. The index would produce results based on the

categorization of:

Entrepreneur attitude dimension

Entrepreneur behaviour and thinking dimensions

Suggestions and improvements to the dimensions.

Contact Details:

Prof. Dr. Nor Aisyah Buang

Faculty of Education,

Universiti Kebangsaan Malaysia

[email protected]

1.9 Sapura Social Network Intranet

The intranet was implemented with the intention for Sapura Group and its

subsidiaries having a single platform for collaboration and communication. The

intranet was built with the capabilities for social networking such as status

updates, friending, creation of groups and becoming a member, creation of news


http://www.piken.com.my/


INSTITUTION LOGO


5

and events. Events can be private and public or based on invite only. Even

though with the social network capabilities included into the platform, the system

admin can still be able to moderate and manage the platform such as approving

groups and deleting status updates.

Contact Details:

En. Razlan Mustapha

COO

Urekalabs Sdn Bhd

[email protected]

1.10 Bridges Talent Management Consultant (Brunei) Website - http://www.bridges-tmc.com/

The website was built for Bridges TMC which is also an entrepreneur in Brunei to

disseminate their service offering such as training and talent management and

competency development to organizations.

Contact Details:

Dr. Mona Kassim

Partner, Bridges TMC

[email protected]

1.11 Unitar Intranet

The UNITAR Intranet project is an extension of the Campus Management System that is going to serve as a hub for all the interconnected applications working together. It will be the first spot for both students and staff in interacting with a slew of other systems. In addition, it will be a repository on keeping the users informed regarding news, events and upcoming activities that are related to them. The project will be built in Drupal with a variety of customizations as well as integrations with off-the-shelf and in-house systems in order to achieve a seamless experience across the CMS platforms. Client Name: UNITAR International University

Contact Details:

Zolkepli Meh

ICT Manager

[email protected]

1.2 Overview of Proposed Solution

The vendor brings together the following modules for the development of INSTITUTITION

NAME Campus Management System (hereinafter refer as “The Proposed Solution” or The

Solution or “iCampus”):


http://www.bridges-tmc.com/

http://www.bridges-tmc.com/



INSTITUTION LOGO


6

iCampus development will cover 10 modules which will enable the University to manage

day-today operations with multiple level of authority. The 10 modules to covered are as

follows:

1. Dashboard

2. Student Online Application

3. Pre-Admission Registration

4. Admission and Records

5. Program & Courses

6. Time Table

7. Finance

8. Exam

9. Accommodation

10. Transportation

1.2.1 Dashboard

User friendly and iconic display of access to functionalities

1.2.2 Student Online Application Module

First point of entry for prospects who are interested to enrol in the university / college.

This module is design to ease the application process and has a back end checking on

preliminary criteria’s of the prospect, after which a conditional offer letter can be

produced.

1.2.3 Pre Admission Module

The module covers prospects that are confirmed on their decision to enroll to the

particular institution is then required to filled in thorough details and is allowed to make

payment for registration. The details then are transferred into the admission and records

module.

1.2.4 Admission & Records

The module is designed to store information on new & recurring student. The module

stores all information for the university including next of kin details. This module also is

where the institution personnel generates matrix number for new students upon certain

checking

1.2.5 Program & Courses Module

The module covers the following

o Academic Offering

INSTITUTION LOGO


7

o Academic Period o Activities o Academic Activities o Program Course o Course to Program o Course Offering o Presented Course o Lecturer / Tutor List o Class Location o Course Registration o Credit Transfer o Deferment o Add / Drop Course

1.2.6 Timetable Engine

o Timetable scheduler engine

o Generation of semester based timetables

1.2.7 Finance Module

The module covers the following:

o Statement of Finance

1.2.8 Exam Module


o Attendance of Students (Lecturer view)

o Set up Student Type o Set up Academic Calendar o Set up Academic Calendar o Set up Other Fee o Bulk Credit Note o Bulk Debit Note o Bulk Adjustment o Student Statement o Billing o Collection / Payment o Bulk Billing o Bulk Discount o One to One Discount o Refund o Share to Revenue o Amortization o Closing (Month) End Report o Closing (Daily) Report

o Exam Schedule o Exam Location o Exam Slip Generation o Coursework Mark Update

INSTITUTION LOGO


8

1.2.9 Accommodation Module


o Basic Criteria checking on room application

1.2.10 Transportation


o Transport information on those who require them o Placement of students to respective vehicle o Payment integration

1.3 Project Assumptions

The following is a list of assumptions the vendor made when responding to this proposal

document, including for the preparation of the bill of material (BOM) for this project. Thus,

changes to the following list of assumptions may cause the project cost to vary:

Sizing Assumptions:

1. Total upload per user (student, Career Services staff, employer and System Admin)

on average is about 100mb over 7-year starting from the deployment of the solution

(if applicable).

2. Maximum concurrent users are estimated to be around 2,000.

Development Assumptions:

1. INSTITUTION NAME is to provide network access to the development and network

server.

2. All 3rd party software licenses, access to gateways and all 3rd party interface charges

shall be borne by INSTITUTION NAME separately.

3. The vendor can use INSTITUTION NAME infrastructure such as networking and

data centre’s for the provisioning of the servers and software.

4. INSTITUTION NAME have existing e-mail gateway and will provide the gateways

access for the solution to send e-mail.

Project Management Assumptions:

1. All INSTITUTION NAME’s project stakeholders are aware of the project and will give

full co-operation to the vendor to obtain proper business requirements.

2. Scope freeze will be initialized after System Design Specification session. Any

changes to initial requirements shall go through proper change management

process.

3. The project duration is estimated to take around 6-7 months starting from User

Requirement Gathering session.

4. PMO meeting will be held once every 2 weeks for the vendor the update PMO of

project’s progress and status.

5. INSTITUTION NAME will adopt big bang approach for the deployment of ICAMPUS.

o Placement of Rooms o Placement of Roommates

INSTITUTION LOGO


9

2 Content

2.1 Proposed Scope of Work

This project entails the development of iCampus and the installation of proposed hardware

and 3rd party software to facilitate the development and deployment and the said project.

The purpose of iCampus is to establish a web portal which acts as a Campus Management

System which will cover an end to end process for INSTITUTION NAME students.

2.1.1 Project Milestones

The project is estimated to take about six-seven (6-7) months from User Requirement

Gathering session to deployment. Progress milestones associated with the project are as

follows:

1. Project kick-off and project team mobilization (0%)

2. Installation of the required hardware and software for development (5%)

3. User Requirement Specification Document signed-off (10%)

4. Functional Design Specification Document and solution prototype signed-off (20%)

5. System Design Specification Document signed-off (30%)

6. Interface and Migration File Document (IMFA) signed-off (40%)

7. SIT completed and signed-off (80%)

8. UAT completed and signed-off (90%)

9. Deployment (95%)

10. Hand-over document signed-off (100%)

2.1.2 Completion Criteria

After the contract is awarded to the vendor, the vendor shall produce a detail Statement of

Work (SoW) to capture and define the work activities, deliverables and finalized timeline the

vendor must execute in performance of specified work for INSTITUTION NAME.

The vendor’s obligation for the services described in the SoW is fulfilled when any one of the

following first occurs:

1. The vendor completes the activities described in the SoW, including provision of the

deliverable materials or

2. The services are terminated by INSTITUTION NAME.

INSTITUTION LOGO

INSTITUTION NAME /iCampus Confidential Document (Strictly only for INSTITUTION NAME)

2

2.2 Proposed Solution

2.2.1 Introduction

With a vision to be acknowledged as the leading centre of excellence for quality education,

R&D and training in the field of management and technology, INSTITUTION NAME would

require an effective management system for managing the student’s information and related

activities to it.

With the online e-learning capabilities and quality materials, the student would definitely

benefit of in their education lifecycle and as a result would be well received in the job

marketplace. In addition, the opportunity for INSTITUTION NAME University by using

ICampus; it can have a cross section profile of students to offer new services for their tertiary

education. At the same time, the information of the parents and students can be used as

contact management for future reference of any new offering in INSTITUTION NAME.

ICampus would be having the capabilities of operational process from student prospecting

by the marketing personnel as well as managing and tracking of student admissions, student

profiling, timetable or scheduling, grading and fees collection. In addition, the system would

be the single window to access all the other services.

ICampus working principle will be best illustrated in flowcharts below. The flow charts cover

the explanation in a simple yet effective manner.

INSTITUTION LOGO

INSTITUTION NAME /iCampus Confidential Document (Strictly only for INSTITUTION NAME) 6

2.2.2 Online Application

INSTITUTION LOGO


2.2.3 Lecturer / R&D

INSTITUTION LOGO


1.2.1 Program & Courses

INSTITUTION LOGO


1.2.2 Finance

INSTITUTION LOGO


10

1.3 Secure User Management

iCampus has comprehensive user, role and group management. Adding, removing and

blocking users can easily be done through iCampus web interface for the number of users

defined. Groups and Roles can be defined and user access rights can be configured

extensively through security matrix.

At every page load, the basic information of each user such as their real IP address,

login time and userid will be audited.

Any changes to the user profiles will be audited. Only admin accounts will have

access to this feature

Users will be logged out at the predefined interval of inactivity, to ensure that no

tampering can be done using their access rights.

Multiple sessions based on the same USERID is not allowed

User profiles will be deactivated after X number of inactive days. An expiry date can

be set for the user profiles, exceeding which the profile will be converted to inactive

1.4 Secure Password Management

The solution has secure password management features that can be tailored to the security

requirement as follows:

Password can be configured to meet complex requirements such as including

numbers, password minimum length, etc. A password that begins with USERID,

specific phrases or repeating characters can be banned.

Password history can be configured and set to X generations, where X is

configurable from 0 to 9999. User cannot change password which is similar to the

previous password.

Password expiration can be configured and set to X days. System must enforce

change password automatically every X days. X days is configurable from 1 to 9999.

Users can change password themselves (self-service).

Password notification alert is configurable X days before the password expires.

User’s access will be blocked if they try to access with the wrong password after X

many times of retry.

Passwords are encrypted with industry level encryption techniques (SHA-512) to

ensure security and reliability of the Password Management module. None of the

User or Database connection passwords is left as plain text in any part of the system.

Standard password management practices such as password hints, protection

against weak passwords, enforce changing password at certain intervals such as first

login is provided with easy configuration screens.

Users are suspended after X failed logins, where X is configurable.

Session timeouts due to inactivity are enforced and configurable. Users can only

login to one session, and cannot create multiple sessions with the same User ID.

When user logs in, the User ID and last login date and time are shown.

INSTITUTION LOGO


11

1.5 Security Report

iCampus comes with a collection of useful monitoring and reporting tools for security related

activities. All the profile auditing activities can be viewed in related reports, any breach of

policy or suspicious activities will be reported in different screens as well. The auditing can

be enabled for webserver and SQL statement level, enabling the DBA or auditors to gain a

more thorough understanding of the different types of access for the system.

The following security audit logs and reports are available. User listing reports can be

searched by date and user:

User Logins, including failed login attempts

User Listing

User Modification History

Password Change History

Activity by User

Activity by Account

Activity by IP

Error and warnings log

Account Field Change (listing changes in values of key fields in account).

Idle Accounts Report (no activity within given time-period)

Security Matrix Report

Group Listing Report

Session Logins Report

Batch Job logs

1.6 Data Migration

The following table summarizes key activities proposed:

2. Table 0-1: Proposed Key Migration Activities

No Activity

1

A meeting involving all the relevant parties is to be conducted. The meeting shall

identify who is responsible for each party and their names and contact information

is to be documented in the meeting minutes.

2 A document called interface and migration file agreement (IMFA) is to be created

in a format agreed by all relevant parties.

3 IMFA document shall include data extraction methodology, field mapping, data

constraint, etc.

INSTITUTION LOGO


12

4 IMFA shall be verified by all the relevant parties and signoff is to be obtained

before System Integration Testing.

5

Data migration plan is to be executed during System Integration Test and the data

is to be verified by INSTITUTION NAME IT admin. A data migration sign off

document is to be prepared for IT admin to sign if the testing result is positive.

6 The data migration is to be cleaned up and re-executed before User Acceptance

Testing and user is allowed to verify the data through web interface.

2.7 Proposed Integration Strategy

To enable the interface to other external systems, interface meetings are required.

INSTITUTION NAME is expected to coordinate and ensure the availability of technical and

functional skill sets of the external systems vendors/owners. The objective of these

integration meetings are to discover and agree on the information, data flow, integration

method and frequency to be retrieved or sent between systems. Integration method and

frequency will be identified and spelled out at this phase. An Interface and Migration

Agreement (IMFA) will be delivered to the respective parties for sign off.

The following table summarizes key activities proposed:

Table 0-2: Key Integration Activities

No Activity

1

A document called Interface and Migration File Agreement (IMFA) has to be

agreed up and signed-off by the vendor, 3rd party vendor and INSTITUTION

NAME IT personnel

2

A meeting is conducted to get all the integration relevant parties involved to

discuss integration methodology and field mapping. The meeting shall identify who

is responsible for each party and their names and contact information documented

in the meeting minutes.

3 IMFA document shall include integration methodology, field mapping, data

constraint, etc.

4 IMFA shall be verified by all the relevant parties and signoff is to be obtained

before System Integration Testing.

5 The integration testing is conducted during System Integration Testing.

6 INSTITUTION NAME IT admin has to be involved to verify the integration testing

results.

INSTITUTION LOGO


13

7 A system integration testing sign off document will be prepared for INSTITUTION

NAME IT admin to signoff if the testing result is positive.

iCampus is able to connect to multiple databases for data extraction, including native

connectivity to:

Oracle

MySQL

PostgreSQL

Microsoft SQL Server

2.8 Ruby on Rails (ROR) Framework

The ROR is chosen because:

Model-View-Controller (MVC) based architecture. The MVC architecture

helps to structure applications more cleanly. When systems are developed in

Rails, there’s a place for each code and all the pieces of the application

interact in a standard way.

Rails are written in Ruby, a modern and object oriented scripting language.

Ruby is concise without being unintelligibly terse which means that the

developer can express ideas naturally and cleanly in Ruby code. This leads to

programs that are easy to write and easy to read.

Convention over Configuration. It means that Rails has sensible defaults

for just about every aspect of knitting together applications. The developer

just follows the conventions and can write Rails applications using less code

than the typical frameworks for example a Java application which uses the

XML configurations.

DRY (Don’t Repeat Yourself). Every piece of code in a system should be

expressed in just one place. Rails which uses the power of Ruby with little

duplication and code – which is usually defined in one place, often suggested

by the conventions of the MVC architecture.

2.9 Rails Versioning

The latest version of ROR includes:

Integrated web services for Service Oriented Architecture (SOA) implementation

Reception of e-mails

INSTITUTION LOGO


14

AJAX for highly interactive web applications

A full unit testing framework and

Rails is fully isolated environments for development, testing and production.

3 Project Approach

3.1 Proposed Approach and Methodology

This section highlights the vendor proposed project implementation methodology including

the overall project management strategy and approach, interface strategy, migration

strategy, training, project management and change management methodology.

3.1.1 Overall Implementation Strategy and Approach

The vendor’s solution delivery methodology follows standard software development life cycle

based on the waterfall approach. The waterfall approach is a sequential software design

process starting from requirement analysis, software design, construction, testing,

production and maintenance.

3.1.1.1 User Requirement Gathering

User requirement gathering session starts after the completion of resource mobilization and

site preparation. Requirements study for the system shall encompass all tasks that go into

validating the business needs and conditions to meet the stakeholder’s requirements.

Session will be effectively conducted based on our well-planned User Requirement

approach that focus on 4 key elements, which are define, discover, assess and finalize.

Current system functionalities, processes and exceptions will be discovered and assessed.

During this phase, the project team will proactively identify process gap and recommend

improved business processes to business users and stakeholders. An “as-is” and “to-be”

documents shall be produced alongside with User Requirement Specification document

(URS).

The vendor will work closely with the stakeholders to brainstorm and discuss new improved

business processes based on new model design. At the end of the requirement gathering

phase, User Requirement Specification documentation will be delivered for sign off to initiate

the next activity.

3.1.1.2 Functional & System Design

INSTITUTION LOGO


15

From the requirement study, the vendor will come up with a complete system design that will

include the solution architecture documentation, functional and technical specifications which

covers the framework of data, application and interface.

The Functional Design document shall consist of detail mapping of user requirement to

system specification including relevant screenshots user flows, whereas the System Design

document shall include detail specification of the system’s backend processes, system

architecture, batch processes and hardware configuration.

A detailed walkthrough of the design specification with the stakeholders will be conducted as

part of the review and approval process. The functional specifications will be described in the

standard documentation format called Functional Design Specification (FDS) and the

detailed technical specification in the System Design Specification (SDS). This

documentation will be presented to stakeholders for review and approval before

commencing on the development of the solution. The actual development of the system will

commence after the system requirement and design has been approved and signed off.

3.1.1.3 Interface, Built Configuration and Customization

To enable the interface to other external systems, interface meetings are required.

INSTITUTION NAME is expected to coordinate and ensure the availability of technical and

functional skill sets of the external systems vendors/owners. The objective of these

integration meetings are to discover and agree on the information, data flow, integration

method and frequency to be retrieved or sent between systems. Integration method and

frequency will be identified and spelled out at this phase. An Interface and Migration

Agreement (IMFA) will be delivered to the respective parties for sign off.

When requirement and design and interface have been confirmed, the development phase

will take place. In this phase, customization and the necessary parameter setup will be

defined accordingly. To ensure effective transfer of skills relevant to the solution, the vendor

will work jointly with the INSTITUTION NAME appointed personnel during this Development

Phase. Interfaces with other systems will also be developed at this phase. Strategy papers

for System Integration Test (SIT) and User Acceptance Test (UAT) will be provided at the

end of the phase

3.1.1.4 Testing

Testing is a crucial part of this system implementation to ensure that all components of the

system are reliable, robust, and the system delivered matches INSTITUTION NAME needs.

Due to this, the vendor proposes to have a separate testing environment.

INSTITUTION LOGO


16

The test strategy, plan and testing requirements will be described in the Test Plan. The Test

Plan will also include description of the specifications for the related testing environment

inclusive of hardware and software, the strategy and approach that will be used for system

testing.

The test plan will be developed such that customer and/or any appointed expert(s) will be

free to perform their own test on any deliverables using the agreed test plan. The Test Plan

will detail out the planned testing activities as below:

Table 3-1: Type of Testing

Types of Testing Remark

Installation testing To be carried out after installation. Installation checklist will be provided.

System Integration testing (SIT) To be carried out during SIT.

Integration Flow Testing (IFT) The purpose of this testing is to verify that the data flow and accuracy from other external system to the solutions are in order.

User Acceptance testing (UAT) To be carried out after SIT

Operational Readiness Testing (ORT) to include automation function readiness

To be carried out before roll out. ORT checklist will be provided.

In order to complete the tests, the vendor will provide the test scripts, test data, test code

and expected results for SIT & UAT.

The vendor will be responsible for setting up the controlled test environment for the

proposed solutions. This includes the application software and test data required to

commence the testing. The testing will be carried out in INSTITUTION NAME premise. The

scope of service and the roles and responsibilities of all parties involved in the testing phase

will be defined during the planning stage in the Test Plan.

Upon completion of a testing, the results of these tests performed will be documented in a

Test Report and submitted to PMO and PSC for review and signoff

3.1.1.5 Trial Run

Trial run will be done in production environment testing whereby the actual main end-users

(the previous UAT session’s testers) will be the testers.

Overall goals of these Trial Runs include:

Final level of discovering and correcting of errors prior to implementation;

Testing the speed of the solution in the production environment to ensure that it is up

to acceptable level and to tune the solution if required.

Testing the load handling capacity of the solution in production environment to

ensure that it is up to acceptable level and to tune the system if required.

Validate the overall readiness of the solution’s production environment for production

service to the INSTITUTION NAME users.

Document the test results, test data, and test problems encountered

INSTITUTION LOGO


17

3.1.1.6 Operational Readiness Testing (ORT)

ORT is a set of testing with checklist for the users to test on the solution’s live data and

production environment. ORT is recommended to be conducted on the day prior to the

targeted Go-Live date, and the result of the testing shall be tabulated and analyzed for the

basis to make the decision for Go-Live or to defer Go-Live. The PSC members shall be

invited for the decision making for Go-Live to proceed. If the decision is not to proceed, then

a set of roll-back activities shall be initiated to achieve data synchronization and batch jobs

are up-to-date.

3.1.1.7 Deployment

The vendor will adopt big bang approach for the solutions deployment covering. Any

variation such as pilot sites or partial phase deployment shall incur additional efforts, timeline

and costs, which can be submitted to INSTITUTION NAME whenever required. Deployment

checklist will be used to ensure the correctness and completeness, and all faults discovered

will be reported and closed before production cutover. Production environment shall be

prepared and readied at this phase. Deployment sign off will be expected to roll out the

system into production.

After the system go-live, the vendor will be available for production support for an agreed

number of days after system deployed.

3.1.2 Interface / Integration

Please refer to section 2.7

3.1.3 Migration

Please refer to section 2.6

3.1.4 Training

Training will be carried out mainly by the vendor’s professional services team and will be

conducted for a period of about 10-14 working days. INSTITUTION NAME is expected to

provide training space, required terminals for training and select designated personnel to

attend the training. Training material will be prepared and provided by the vendor.

The training objective is to provide skill transfer for the technical staff, end-users, the

management team, and other stakeholders. This is achieved by having our instructors to

coach designated personnel from INSTITUTION NAME.

Scope of training includes:

INSTITUTION LOGO


18

User flow demonstration

System conceptual explanation

Hand-on training

The vendor will implement a comprehensive, structured training program that will address all

issue pertaining to usage of the proposed solution. The objectives of the training approach

are:

To help end-users, technical personnel and management to understand, accept and

manage the implemented systems.

Meet organizational and individual needs

3.1.5 Project Management and Change Management

3.1.5.1 Project Management

INSTITUTION NAME will form and maintain a steering committee ("Steering Committee"),

which will be comprised of their management personnel representing business operations

and technology. The vendor’s Project Director is expected to have a seat on the steering

committee and will be invited in advance of such meetings to participate in each Steering

Committee meeting. The Steering Committee will:

Provide timely direction and decisions

Ensure that your necessary resources are available on a timely basis

Obtain commitment from all levels of your organization as required

Meet at regular intervals during the period in which services are provided

INSTITUTION NAME together with the vendor’s project team is responsible for defining the

project roles and the assigned role responsibilities. The project team will include

representatives from each business function affected by the project. This team will have the

knowledge and the authority to recommend necessary changes to the business to utilize the

leading practice features of the associated applications system. Any delay caused by lack of

availability of any required information or input from the INSTITUTION NAME resources may

extend the project time line and cost.

INSTITUTION NAME is expected to appoint a capable Project Manager to work alongside

the vendor’s Project Manager with the main objectives of keeping a clear line of

communication between relevant parties, meeting project objectives and ensuring the

milestone dates are adhered to. INSTITUTION NAME Project Manager is responsible for the

participation of the INSTITUTION NAME resources in the requirement gathering and

interface phases and the timely completion of all the INSTITUTION NAME’s activities based

on the project plan whereas the vendor’s Project Manager is responsible for managing the

solution’s implementation activities and resources.

INSTITUTION LOGO


19

INSTITUTION NAME will assign a full time project team and allocate the vendor’s project

team with work stations and spaces during user requirement and integration stages where

the vendor’s project team is required to be on INSTITUTION NAME premise.

3.1.5.2 Change Management

The vendor uses a rigorous scope change control procedure to control the scope and costs

of the project. Any modification or deviation from the established project scope and

requirements or changes to the project timeline or costs will be subject to the scope control

or change management procedure. INSTITUTION NAME or the vendor may initiate the

scope change control process whenever there is a perceived need for change that will affect

the overall functionality, costs or timeline of the project. The project team is responsible for

considering the impact of any user requests on the scope of the project. All change orders

must be accompanied by an estimate of services and timeline impact analysis and must be

reviewed and approved before any work may begin.

3.1.6 Support and Maintenance

Upon deployment, there will be a period of 2 weeks of offsite support to ensure the users are

familiarized with using the solution. Users are highly recommended to fully utilize this time to

clarify and seek assistance from the vendor’s deployment team to use the software to the

fullest.

The vendor’s Support Service can be contacted and rendered via email and voice calls . We

have Professional Services with years of experience to handle customer needs and issues.

On-site support is provided whenever support cannot be provided via the phone or there is a

bug fix but it is prior to top management approval.

The post-production support would be generally governed by the Warranty clauses and/or

Maintenance Agreement. The following is the scope of the software maintenance support

provided by the vendor:

Fault reporting and fixing service

Tracking and fixing reported faults as per agreed SLA

Providing emergency releases whenever appropriate

Propagating the fix to other supported versions

Response to queries

Assistance in use of the software

Technical assistance

Set-up/Configuration assistance

Maintenance releases that cover

INSTITUTION LOGO


20

Bug fixes for defects or malfunctions that occur and non conforming of the functions

stipulated in the Functional Requirement Specifications

Minor changes in software for dot releases

Product support information dissemination

Summary information about all faults fixed in various versions

Releases are categorized as: Emergency, Interim, and Major

Interim (Minor) Release: When it becomes necessary to correct faults detected on a

released version, fixes are made to the base version. This modified version is

installed as a minor release, which by definition does not contain any functional

enhancements. Minor releases are planned by the Principal and made available

periodically. According to general policy, underlying environmental software required

for the run time is not changed in this release. A minor release completely

supersedes previous minor and emergency releases and all customers are expected

to upgrade their versions to the latest release.

Major (Enhancement) Release: A major release represents significant functional

and/or technical changes in the proposed systems. Unlike with a minor release, a

customer is not required to upgrade to the next enhancement release. Planned by

product management, major releases would involve some incremental cost for the

customers when major new modules are added to the product.

Emergency Release: When a software fault prevents the system from operating

correctly, a fix (patch) is made available as an emergency release. Such action may

also be necessary when certain enhancements are urgently needed in order to

comply with external regulatory requirements. An emergency release has following

characteristics:

1. It is supplied only to the site that reported the problem. Other sites will get the fix

along with the minor (maintenance) release in which the fault is fixed.

2. It addresses only the critical problem in question.

3. The emergency fix is temporary in nature and will be replaced by the next

maintenance release.

There is also a Warranty Period of 3-month for the proposed solution, which will commence

immediately after the date of User Acceptance Test Sign-Off. The vendor also warrants that

the components supplied and installed is in accordance with this proposal shall be free of

any defects and malfunction for a period specified as per the Warranty Period (3-month).

Any defects caused by the mis-configuration and coding errors uncovered during this

Warranty Period shall be immediately responded to and resolved free of charge. Beyond this

Warranty Period, the solution is required to be covered by an active Maintenance Agreement

to be signed between INSTITUTION NAME and the vendor.

INSTITUTION LOGO


21

3.1.6.1 Respond Time and Service Level Agreement (SLA)

The vendor uses commercially reasonable efforts to provide response to support requests

according to the priority level set out in the table below:

Table 3-2: Respond Time and SLA for Issue Resolution

Priority Level Vendor’s Response

time remotely

Urgent Severity: Where critical business system is stopped or lost (total outage) and there is no workaround to achieve business continuity

2 hours

High Severity: System down or slowed and impact the Client’s business and Client’s work is stopped or so severely impacted that Client cannot reasonably continue to work.

4 hours

Normal Severity: Client’s work is continuing (not stopped); however, there is serious impact on Client’s productivity and/or service levels.

24 hours

Low Severity: Systems or sub-systems or components is not usable or hampered but is not critical to business operations of the client and client is able to perform normal business operations.

48 hours

General usage questions.

General usage questions will be responded to within two days and treated with a lower priority

3.1.6.2 Support Road Map

1. Support Road Map

The following steps of response to support will be put into place for any problems faced by

clients.

Support hours:

i. Mon- Fri (except public holiday): 9.30 am – 6.00 pm

ii. After working hours : Daily till 12.00 am ( depends on severity of the problem)

INSTITUTION LOGO


22

1) Support Roadmap during office hours.

Helpdesk to assign tickets to respective party

Clients to create tickets in the “Trac”

Manual Add-hoc bills created on case to case

CS8 Office

Incident Ticket Creation in Trac

Helpdesk Problem Solving Process

Client

Upon solving the problem, an email will be sent to the client

Problem Solved

2 4

MC & RC

1

Respective PIC will solve the problem base on the ticket severity

3

INSTITUTION LOGO


23

2) Support Roadmap after office hou

Clients to call respective PIC

Remote / On- Site

Incident Reporting Problem

Solving

Process

Client

Upon solving the problem, an email will be sent to the client

Problem Solved

2 4 1

Respective PIC will solve the problem base on the ticket severity

INSTITUTION LOGO


24

3.1.6.3 Daily Backup Plan

No. Activity Remark

1. Create export database command in production server.

This command exports the entire database including schema setting and all the data.

2. Create a tar command to tar the backup and the php source file and the exported database dump file from the production server.

Zip the backup file and the php file into one folder.

3. Create a scheduler to execute the export and tar command.

Schedule time for the scheduler depends on client’s request RPO. INSTITUTION NAME request RPO is 24 hours and CS8 recommends the backup schedule 2 times a day. If the backup fails, an email notification will be sent out to the vendor and INSTITUTION NAME IT team. The system will then automatically re-run the backup command in the next hour.

4. Create a backup folder at the physical server. It is recommended to store the backup file for 7 days. There will be a scheduler to clean up files which are more than 7 days.

5. Create a scheduler to FTP the backup file from production server to disaster recovery server.

If the ftp fails, system will send out an email notification to the vendor and INSTITUTION NAME IT team. The system will then automatically re-run the FTP command in the next hour.

3.1.6.4 Recovery Plan

No. Activity Estimated time

1. Perform a health check on the OS, Web Server and Database Server

2 hours.

2. Import the data and restore the configuration from backup file.

4-12 hours. (Subject to the data file size)

3. Verify the data and test the application flow with different user group.

4 hours.

4. Buffer 4 hours.

INSTITUTION LOGO


25

3.1.6.5 RTO & RPO Summary Table

RTO RPO Remote replication Local replication

24 hours 12 hours Yes Yes

4 Proposed Documentation

The following table provides description and of each milestone and the proposed

documentation for each milestone:

Table 4-1: Proposed Documentation by Project Milestones

Key Milestone

Description Key Deliverables

Business requirement study

Business requirement study is the process of discovering, analyzing, defining, and documenting the requirements that are related to a specific business objective. This is also the process whereby the project team and all relevant business stakeholders clearly and precisely define the scope of work. During this phase, the project team will proactively identify process gap and recommend improved business processes to business users and stakeholders. An “as-is” and “to-be” documents shall be produced alongside with User Requirement Specification document (URS).

1. User Requirement Specification document 2. URS sign-off document

Functional & system design

Functional design session involves detailing the solution prototype to stakeholders by mapping the business process defined during the business requirement study to the solution's operational flows. System design is a stage where architecture, components, modules, interfaces, data; batch jobs are properly defined and scoped. Thus, system design is a stage that requires huge involvement by the INSTITUTION NAME 's IT team.

1. Functional requirement specification (FRS) 2. System design specification (SDS) 3. Interface and Migration file agreement (IMFA) 4. Software prototype 5. Software installation manual

INSTITUTION LOGO


26

Configuration, customization and build

This stage is where the development process for the proposed solution starts.

SIT and UAT Batch

System Integration Testing (SIT) includes an end-to-end integration testing among all systems involved in the implementation. The testing sessions shall cover all possible integration scenarios to ensure that the integrations are established accordingly. UAT Batch is another testing to be done in the system to ensure that all the batch jobs are working properly and as per expected. Also, data verification shall be part of the UAT batch activities. Where SIT is to be done together with respective vendors from other systems, UAT Batch is to be done with the INSTITUTION NAME IT team.

1. SIT script 2. UAT Batch script 3. SIT sign-off 4. UAT Batch sign-off 5. Testing strategy (for

SIT, UAT Batch, UAT)

UAT

User Acceptance Testing is a very important phase of project milestone where users are expected to test all screen functionalities and display to ensure that the system is built based on what has been discussed and captured during user requirement session and functional requirement session. An end-to-end testing process inclusive of integration and running related batch job is required to ensure that the processes in the system are running smoothly and as per expected. At the end, sign-off is required to be obtained from key users as prove that the testing has been completed successfully.

1. UAT strategy document 2. UAT script 3. UAT sign-off

Training

The training objective is to provide skill transfer for the technical staff, end-users, the management team, and other stakeholders.

1. Training slides 2. User manual 3. System manual

Rollout

The vendor will adopt big bang approach for the solutions deployment. Deployment checklist will be used to ensure the correctness and completeness, and all faults discovered will be reported and closed before production cutover. Production environment shall be prepared and readied at this phase.

1. ORT checklist 2. Deployment sign-off

INSTITUTION LOGO


27

5 Proposed Project Timeline & Resource Planning

5.1 Proposed Project Timeline

The project is estimated to span over a period of 6-7 months from project kick-off date.

Starting with 6 weeks of User Requirement gathering sessions held between users from

INSTITUTION NAME and functional team from Vendor, to study and define the scope of

work.

Upon System Design Specification sign off, a scope freeze order will be issued, followed by

commencement of the System Configuration & Customization, System Integration and

Data Migration processes (if it is required, it will be additional requirements), which are

projected to be completed in the next 4-5 months. Any change request to the scope after

the scope freeze is to go through a change management process.

Upon completion of the aforementioned, System Integration Test and User Acceptance

Test (“UAT”) is to be performed. Upon UAT sign off, user trainings is to be conducted. In

the final week, the system will be deployed into production environment for a final operation

readiness testing.

5.2 Resource Planning

Key Activity

Number of

Staff from

INSTITUTION

NAME’s

Estimated

Number of

Staff from

Vendor

Key Resources

Duration

(working

Days)

User

requirement

gathering and

walkthrough

To be

determined by

INSTITUTION

NAME PM

2

Key Resource from

INSTITUTION NAME

- Business process

stakeholders

- INSTITUTION NAME IT

personnel

- Process owner

Key Resource from

Vendor

- Professional Services

Team (2)

25

INSTITUTION LOGO


28

Functional &

system design

and

walkthrough

The same

resources

allocated for

user

requirement

gathering and

walkthrough

4

Key Resource from

INSTITUTION NAME

- Business process

stakeholders


personnel

- Process owner

Key Resource from

Vendor


Team (2)

- Software engineer (2)

20

Configuration,

customization

and build

4 5

Key Resource from

INSTITUTION NAME

- Process owner (2)


personnel (2)

Key Resource from

Vendor


Team (2)


80

SIT and UAT

Batch 4 3

Key Resource from

INSTITUTION NAME


personnel (2)

- System vendor for the

specific interface (2)

Key Resource from

Vendor-


Team (2)

5

INSTITUTION LOGO


29


UAT

The same

resources

allocated for

user

requirement

gathering and

walkthrough

4

Key Resource from

INSTITUTION NAME

- Business process

stakeholders


personnel

- Process owner

Key Resource from

Vendor


Team (2)

- Software Engineer (2)

5

Training

All business

users,

employer and

System

Administrators

2

Key Resource from

INSTITUTION NAME

- All business users,

employer and System

Administrators

Key Resource from

Vendor


Team (2)

14

Rollout 4 5

Key Resource from

INSTITUTION NAME


personnel (2)

- Process owner (2)

Key Resource from

Vendor


Team (2)

- Software Engineer (3)

3

INSTITUTION LOGO


30

6 Project Costing

6.1 Introduction

Based on the requirements gathered, the estimated cost for the iCampus is as follows:

No. Description / Milestone % Amount (RM)

1 Project Acceptance and Project Award 10

2 Upon User Requirement Specification Sign-Off 15

3 Upon Systen Design Specification Sign-Off 15

4 Upon System Integration Test(SIT) Sign-Off 25

5 Upon User Acceptance Test Sign-Off 25

6 Project Closure and Commissioning 10

7 3 months warranty period

Total 100

** The vendor provides 2-month warranty upon the completion of UAT. Thus the first year

maintenance cost is 50% of the annual maintenance cost. Subsequent years' annual

maintenance cost is 20% of the entire project cost.

There will be no per user license.

7 Project Organization Structure and Team Members

It is important to have a well-defined project organization structure and an established

escalation process associated with the various levels in the structure.

The organization structure mentioned below will be the typical structure for the

implementation of the solution in the INSTITUTION NAME.

Project Steering Committee &

PMO Vendors

Management Office

InstitutionNameProject

Manager

Vendor’s Project Manager

InstitutionNameProject

Director

Vendor’s Project Director

INSTITUTION LOGO


31

The following outlines the role and responsibility of the project’s team:

Steering Committee & PMO

Sets the overall project mission

Staffed by the Taylor’s senior management personnel

Provides strategic direction and ensures all project needs are met

Conducts periodic project reviews

Resolves all escalated issues by the project team

Vendor’s Management Office

Provide functional and architecture guidance based on industry best practices

Help proactively identify and mitigate potential project risks

Conduct project meeting and issues escalation review

Coordinate among various project streams

Create and maintain overall project plan

Project Team

Project execution

Staffed by experienced functional and technical experts

Report project status to steering committee and PMO

Interact with vendor’s Management Office to seek guidance

Proactively identify and resolve issues

DBA / Sys

Admin

End Users

Technical Roles Functional Lead Technical Lead

Infra Engineer Business Analyst

System Analyst

Team Lead

Data Stewards Software Engineer

INSTITUTION LOGO


32

8 Attachment 1

Change Control Form Section A

Project Change

Number

Controlled Item Item

Version

Identification of Aspect

to be Change

For Software give Module, Screen or Report name

Change Details

Include indication of

importance and urgency

Requester of Change

Print Name

Date

Raised

Section B

Investigator of Change

Impact,

give details of

other items affected

Investigation Outcome

Reject / Action at No Cost / Action at Cost

Suggested Priority

High / Medium / Low

Date

Investigated

Section C

INSTITUTION LOGO


33

Implementor Date

Scheduled

Section D

Change Implemented Signature Date

Implementator

Project Manager

How to Use this Form

Change Requester completes ALL boxes in Section A and passes to CS8 Project Manager.

CS8 Project Manager arranges investigation of request, depending on outcome request is

rejected, or given a priority and cost, and with investigator completes Section B & C, form is

then retained in project files. Once change is implemented Section D is signed-off.

TEMPLATE FOR iCAMPUS PROPOSAL.pdf

Documents

Transcript of TEMPLATE FOR iCAMPUS PROPOSAL.pdf