Sie sind auf Seite 1von 43

INSTITUTION LOGO

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

INSTITUITON NAME /ICampus v1.0

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

Document Control
Version
No.
1.0

Version
Date

Description

Done By

Change from Previous


Version

Initial document

Consoci8
Sdn Bhd

INSTITUITON NAME /ICampus v1.0

Confidential Document (Strictly only for INSTITUTION NAME)

ii

INSTITUTION LOGO

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

INSTITUITON NAME /ICampus v1.0

Signature

Date

Confidential Document (Strictly only for INSTITUTION NAME)

iii

INSTITUTION LOGO

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

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

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


3.1

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

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


INSTITUITON NAME /ICampus v1.0

Confidential Document (Strictly only for INSTITUTION NAME)

iv

INSTITUTION LOGO

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


5.1

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

5.2

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

Project Costing................................................................................................ 30
6.1

Introduction.......................................................................................................... 30

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

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

INSTITUITON NAME /ICampus v1.0

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

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
hairul_laila@iium.edu.my
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
INSTITUTION NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

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)
noreen@mdec.com.my
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.
2.
3.
4.
5.

Having a centralized databanks of job applicants with the related information


The system accessed via the internet.
Automated workflow
Automatic email notification
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
louis@careerchannel.com.my
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.

INSTITUTION NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

Contact Details:
Tham Keng Yew
CEO, SocialWalk
thisiskengyew@gmail.com
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)
normarinee@mdec.com.my
1.6 MDeC Manpower Requsition System
The project is a basis for MDeCs Managers, HOD and Division Head to reach
the human capital requisition services through:

A single authentication and profiling system through MDeCs Active Directory.


Managers and HOD to request manpower.
Approval process to Division Head.
HCD to verify and published the manpower request to MDeCs intranet.
MDeCs staffs apply for the published post through the MDeCs 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)
sitisaljura@mdec.com.my
1.7 CyberSecurity Malaysia (CSM) Project Management and Monitoring System
(PMMS)
INSTITUTION NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

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
suzana@cybersecurity.my
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
norais@ukm.my
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
INSTITUTION NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

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
razlan@urekalabs.com
1.10 Bridges Talent Management Consultant (Brunei) Website - http://www.bridgestmc.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
mona.kassim@bridges-tmc.com
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
zolkepli@unitar.my

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):
INSTITUTION NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

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 criterias 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 NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

o
o
o
o
o
o
o
o
o
o
o
o
o

Academic Period
Activities
Academic Activities
Program Course
Course to Program
Course Offering
Presented Course
Lecturer / Tutor List
Class Location
Course Registration
Credit Transfer
Deferment
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
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o

Set up Student Type


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

1.2.8 Exam Module


The module covers the following:
o
o
o
o
o

Exam Schedule
Exam Location
Exam Slip Generation
Coursework Mark Update
Attendance of Students (Lecturer view)

INSTITUTION NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

1.2.9 Accommodation Module


The module covers the following:
o
o
o

Placement of Rooms
Placement of Roommates
Basic Criteria checking on room application

1.2.10 Transportation
The module covers the following:
o
o
o

Transport information on those who require them


Placement of students to respective vehicle
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 centres 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 NAMEs 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
projects progress and status.
5. INSTITUTION NAME will adopt big bang approach for the deployment of ICAMPUS.
INSTITUTION NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

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 vendors 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 NAME/iCampus

Confidential Document (Strictly only for INSTITUTION NAME)

INSTITUTION LOGO

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 students 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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
2

INSTITUTION LOGO

2.2.2 Online Application

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)

INSTITUTION LOGO

2.2.3 Lecturer / R&D

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)

INSTITUTION LOGO

1.2.1 Program & Courses

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)

INSTITUTION LOGO

1.2.2 Finance

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)

INSTITUTION LOGO

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.
Users 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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
10

INSTITUTION LOGO

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
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.
A document called interface and migration file agreement (IMFA) is to be created

in a format agreed by all relevant parties.


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

constraint, etc.

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
11

INSTITUTION LOGO

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

before System Integration Testing.


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.
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
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
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.
IMFA document shall include integration methodology, field mapping, data

constraint, etc.
IMFA shall be verified by all the relevant parties and signoff is to be obtained

4
5

before System Integration Testing.


The integration testing is conducted during System Integration Testing.
INSTITUTION NAME IT admin has to be involved to verify the integration testing

results.

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
12

INSTITUTION LOGO

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

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, theres 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 (Dont 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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
13

INSTITUTION LOGO

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 vendors 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 stakeholders 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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
14

INSTITUTION LOGO

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 systems 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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
15

INSTITUTION LOGO

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 To be carried out before roll out. ORT checklist will be
(ORT) to include automation provided.
function readiness
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 sessions 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 solutions production environment for production
service to the INSTITUTION NAME users.
Document the test results, test data, and test problems encountered
INSTITUTION NAME /iCampus
Confidential Document (Strictly only for INSTITUTION NAME)
16

INSTITUTION LOGO

3.1.1.6 Operational Readiness Testing (ORT)


ORT is a set of testing with checklist for the users to test on the solutions 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 vendors 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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
17

INSTITUTION LOGO

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 vendors 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 vendors 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 vendors 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 NAMEs activities based
on the project plan whereas the vendors Project Manager is responsible for managing the
solutions implementation activities and resources.
INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
18

INSTITUTION LOGO

INSTITUTION NAME will assign a full time project team and allocate the vendors project
team with work stations and spaces during user requirement and integration stages where
the vendors 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 vendors deployment team to use the software to the
fullest.
The vendors 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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
19

INSTITUTION LOGO

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 NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
20

INSTITUTION LOGO

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

Vendors Response
time remotely

Priority Level
Urgent Severity:
Where critical business system is stopped or lost (total outage)
and there is no workaround to achieve business continuity
High Severity:
System down or slowed and impact the Clients business and
Clients work is stopped or so severely impacted that Client
cannot reasonably continue to work.
Normal Severity:
Clients work is continuing (not stopped); however, there is
serious impact on Clients productivity and/or service levels.
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.

General usage questions.

2 hours

4 hours

24 hours

48 hours
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.
ii.

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


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

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
21

INSTITUTION LOGO

1) Support Roadmap during office hours.

CS8 Office
Manual Add-

Clients to
create tickets
in the Trac

Helpdesk to
assign tickets
to respective
party

Respective
hoc bills PIC
will solve
the
created
on
problem
case base
to case
on the ticket
severity
MC & RC

Client

Incident
Ticket
Creation in
Trac

INSTITUTION NAME /iCampus

Helpdesk

Problem
Solving
Process

Confidential Document (Strictly only for INSTITUTION

NAME)
22

INSTITUTION LOGO

2) Support Roadmap after office hou

Remote /
On- Site
Clients to
call
respective
PIC

Respective
PIC will solve
the problem
base on the
ticket severity

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

Client
1

Incident
Reporting

INSTITUTION NAME /iCampus

Problem
Solving
Process

Confidential Document (Strictly only for INSTITUTION

Problem
Solved

NAME)
23

INSTITUTION LOGO

3.1.6.3 Daily Backup Plan


No.
1.

2.

3.

4.

5.

Activity
Remark
Create export database command in production This command exports the
server.
entire database including
schema setting and all the
data.
Create a tar command to tar the backup and the php Zip the backup file and the
source file and the exported database dump file from php file into one folder.
the production server.
Create a scheduler to execute the export and tar Schedule time for the
command.
scheduler
depends
on
clients
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.
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.
Create a scheduler to FTP the backup file from If the ftp fails, system will
production server to disaster recovery server.
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.
1.
2.
3.
4.

Activity
Perform a health check on the OS, Web Server and
Database Server
Import the data and restore the configuration from
backup file.
Verify the data and test the application flow with
different user group.
Buffer

INSTITUTION NAME /iCampus

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

Confidential Document (Strictly only for INSTITUTION

NAME)
24

INSTITUTION LOGO

3.1.6.5 RTO & RPO Summary Table


RTO
24 hours

RPO
12 hours

Remote replication
Yes

Local replication
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 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
Business
clearly and precisely define the scope of
requirement
work.
study
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).
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
Functional &
operational flows. System design is a
system
stage where architecture, components,
design
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.

INSTITUTION NAME /iCampus

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

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

Confidential Document (Strictly only for INSTITUTION

NAME)
25

INSTITUTION LOGO

Configuration,
This stage is where the development
customization
process for the proposed solution starts.
and build
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
1. SIT script
integrations are established accordingly.
2. UAT Batch script
SIT and UAT UAT Batch is another testing to be done
3. SIT sign-off
Batch
in the system to ensure that all the batch
4. UAT Batch sign-off
jobs are working properly and as per
5. Testing strategy (for
expected. Also, data verification shall be
SIT, UAT Batch, UAT)
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.
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
1. UAT strategy document
functional requirement session. An endUAT
2. UAT script
to-end testing process inclusive of
3. UAT sign-off
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.
The training objective is to provide skill
1. Training slides
transfer for the technical staff, endTraining
2. User manual
users, the management team, and other
3. System manual
stakeholders.
The vendor will adopt big bang
approach for the solutions deployment.
Deployment checklist will be used to
ensure
the
correctness
and
1. ORT checklist
Rollout
completeness, and all faults discovered
2. Deployment sign-off
will be reported and closed before
production
cutover.
Production
environment shall be prepared and
readied at this phase.

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
26

INSTITUTION LOGO

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

Estimated

Staff from

Number of

INSTITUTION

Staff from

NAMEs

Vendor

Duration
Key Resources

(working
Days)

Key Resource from


INSTITUTION NAME
- Business process
stakeholders
User

To be

requirement

determined by

gathering and

INSTITUTION

walkthrough

NAME PM

- INSTITUTION NAME IT
2

personnel

25

- Process owner
Key Resource from
Vendor
- Professional Services
Team (2)

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
27

INSTITUTION LOGO

Key Resource from


INSTITUTION NAME
- Business process
The same
Functional &
system design
and
walkthrough

stakeholders

resources

- INSTITUTION NAME IT

allocated for
user

personnel
4

requirement

- Process owner

20

Key Resource from

gathering and

Vendor

walkthrough

- Professional Services
Team (2)
- Software engineer (2)
Key Resource from
INSTITUTION NAME
- Process owner (2)
- INSTITUTION NAME IT
Configuration,
customization

personnel (2)
4

80
Key Resource from

and build

Vendor
- Professional Services
Team (2)
- Software engineer (3)
Key Resource from
INSTITUTION NAME
- INSTITUTION NAME IT
personnel (2)
SIT and UAT
Batch

- System vendor for the


specific interface (2)

Key Resource from


Vendor- Professional Services
Team (2)

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
28

INSTITUTION LOGO

- Software engineer (2)


Key Resource from
INSTITUTION NAME
- Business process
The same

stakeholders

resources

- INSTITUTION NAME IT

allocated for
UAT

user

personnel
4

requirement

- Process owner

Key Resource from

gathering and

Vendor

walkthrough

- Professional Services
Team (2)
- Software Engineer (2)
Key Resource from
INSTITUTION NAME

Training

All business

- All business users,

users,

employer and System

employer and

Administrators

System

Key Resource from

Administrators

Vendor

14

- Professional Services
Team (2)
Key Resource from
INSTITUTION NAME
- INSTITUTION NAME IT
personnel (2)
- Process owner (2)
Rollout

3
Key Resource from
Vendor
- Professional Services
Team (2)
- Software Engineer (3)

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
29

INSTITUTION LOGO

6 Project Costing
6.1 Introduction
Based on the requirements gathered, the estimated cost for the iCampus is as follows:

No.
1
2
3
4
5
6
7

Description / Milestone
Project Acceptance and Project Award
Upon User Requirement Specification Sign-Off
Upon Systen Design Specification Sign-Off
Upon System Integration Test(SIT) Sign-Off
Upon User Acceptance Test Sign-Off
Project Closure and Commissioning
3 months warranty period
Total

%
10
15
15
25
25
10

Amount (RM)

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

InstitutionNameProject

Vendors
Management Office

Vendors Project Director

Director

Vendors Project Manager


InstitutionNameProject
INSTITUTION
NAME /iCampus
Manager

Confidential Document (Strictly only for INSTITUTION

NAME)
30

INSTITUTION LOGO

Team Lead
Functional Lead

Technical Roles

End Users

DBA

Sys

Technical Lead

Business Analyst

Infra Engineer

Admin
Data Stewards

System Analyst

Software Engineer

The following outlines the role and responsibility of the projects team:
Steering Committee & PMO

Sets the overall project mission


Staffed by the Taylors 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

Vendors 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 vendors Management Office to seek guidance
Proactively identify and resolve issues

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
31

INSTITUTION LOGO

8 Attachment 1
Change Control Form
Section A
Change

Project

Number
Item

Controlled Item

Version

Identification of Aspect

For Software give Module, Screen or Report name

to be Change
Change Details
Include indication of
importance and urgency

Date

Requester of Change

Raised

Print Name

Section B
Investigator of Change
Impact,
give details of
other items affected

Investigation Outcome

Suggested Priority

Reject / Action at No Cost / Action at Cost

High / Medium / Low

Date
Investigated

Section C
INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
32

INSTITUTION LOGO

Date

Implementor

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.

INSTITUTION NAME /iCampus

Confidential Document (Strictly only for INSTITUTION

NAME)
33

Das könnte Ihnen auch gefallen