PSZ19:16(Pind.1/97)
UNIVERSITI TEKNOLOGI MALAYSIA
BORANG PENGESAHAN STATUS TESISX
JUDUL :
Integrated Technical Problem Management System (ITPMS)
SESI PENGAJIAN :
Saya
.
NORZALIHA BINTI MOHAMAD NOOR
(HURUF BESAR)
Mengaku membenarkan tesis (PSM/Sarjana/Doktor Falsafah)* ini disimpan di Perpustakaan
Universiti Teknologi Malaysia dengan syarat-syarat kegunaan seperti berikut :1.
2.
3.
4.
Tesis adalah hakmilik Universiti Teknologi Malaysia
Perpustakaan Universiti Teknologi Malaysia dibenarkan membuat salinan untuk tujuan
pengajian sahaja.
Perpustakaan dibenarkan membuat salinan tesis ini sebagai bahan pertukaran antara institusi
pengajian tinggi.
**Sila tandakan ( 9 )
SULIT
TERHAD
(Mengandungi maklumat yang berdarjah keselamatan
atau kepentingan Malaysia seperti yang termaktub di
dalam AKTA RAHSIA RASMI 1972)
(Mengandungi maklumat TERHAD yang telah
ditentukan oleh organisasi/badan di mana penyelidikan
dijalankan)
TIDAK TERHAD
Disahkan oleh
(TANDATANGAN PENULIS)
(TANDATANGAN PENYELIA)
Alamat Tetap :
No 4 Jalan Puncak Setiawangsa 5,
Taman Setiawangsa,
Prof. Madya. Wardah Zainal Abidin
54200 Kuala Lumpur
Tarikh :
CATATAN
:
Nama Penyelia
Tarikh :
*
**
X
Potong yang tidak berkenaan
Jika tesis ini SULIT atau TERHAD, sila lampirkan surat daripada pihak
berkuasa/organisasi berkenaan dengan menyatakan sekali sebab dan tempoh tesis ini
perlu dikelaskan sebagai SULIT atau TERHAD
Tesis dimaksudkan sebagai tesis bagi Ijazah Doktor Falsafah dan Sarjana secara
penyelidikan, atau disertasi bagi pengajian secara kerja kursus dan penyelidikan, atau
Laporan Projek Sarjana Muda (PSM)
ii
“We hereby declare that we have read this thesis and in our opinion this thesis is
sufficient in terms of scope and quality for the award of the degree of Master of
Science in IT Management”
Signature
:
................................................
Name of Supervisor I :
PM Wardah Zainal Abidin
Date
:
................................................
Signature
:
................................................
Name of supervisor II :
Pn. Suzana Abidin
Date
................................................
:
INTEGRATED TECHNICAL PROBLEM MANAGEMENT SYSTEM
(ITPMS)
NORZALIHA MOHAMAD NOOR
A thesis submitted in fulfillment of the requirements for the award of the degree of
Master of Science Information Technology Management
Faculty of Computer Science & Information Technology
University Technology Malaysia
November 2005
iii
I declare that this thesis entitled “Integrated Technical Problem Management System” is
the result of my own research except as cited in the references. The thesis has not been
accepted for any degree and is not concurrently submitted in candidature of any other
degree.
Signature
:
…………………………………
Name
:
Norzaliha Mohamad Noor
Date
:
iv
To my beloved husband and children
v
ACKNOWLEDGEMENT
I would like to express my gratitude and special appreciation to a wonderful
group of people who have been there to support and make this project a success.
Special thanks to my project supervisor PM Wardah Zainal Abidin and Pn.
Suzana Abidin who have been encouraging and supportive throughout the moments.
They have been very supportive and generous.
Last but not least, thank you to my family, friends and AITI staffs. A millions
thanks to all that have in giving motivation and support. I hope this project would be a
success with all the help I received.
vi
ABSTRAK
System Pengurusan Masalah Teknikal Bersepadu (ITPMS) adalah merupakan
satu sistem yang di bangunkan bagi menggabungkan dua jenis pemprosesan yang
melibatkan pengendalian pemprosesan pengurusan masalah. Pemprosesan tersebut adalah
pemprosesan automasi sistem sediada (legacy system) dan pemprosesan manual.
ITPMS adalah sistem automasi yang merangkumi fungsi pengendalian
pengurusan masalah seperti pemantauan, pengagihan dan pengawalan masalah. Sebagai
satu sistem automasi, ITPMS juga berkeupayaan untuk melakukan pengwujudan rekod
baru, penghapusan rekod dan juga pengemaskinian rekod. Di samping itu sistem ini juga
menyediakan data dan maklumat statistik kepada pihak pengurusan.
vii
ABSTRACT
The Integrated Technical Problem Management System is a system that is
designed to integrate the two types of processes involved in the handling of problem
management processing. The processing are the automated legacy system and the manual
processing.
ITPMS is an automated system which also includes the functions of problem
management handling that are monitoring, escalating and controlling the problems. As
an automated system, ITPMS is able to perform the creation, deletion and updating the
record. In addition, the system also can supply the statistical data and information for the
management.
viii
TABLE OF CONTENTS
CHAPTER
1
2
TITLE
PAGE
PROJECT OVERVIEW
1
1.1
Introduction
1
1.2
Background of problem
2
1.2.1 Host Application Support (HAS)
3
1.2.2 Client Server Support (CSS)
4
1.2.3 Management Reports
5
1.3
Statement of the Problem
6
1.4
Project Objective
6
1.5
Project Scope
7
1.6
Importance of Project
8
LITERATURE REVIEW
10
2.1
Introduction
10
2.2
Definition of Integrated Problem Management
11
System
2.2.1 Problem Management
11
2.2.2
Problems Management System
12
2.2.3
Integrated Problem Management System
13
2.3
Helpdesk
14
2.4
Benefits of Problem Management
14
2.5
Framework Of Best Practices - ITIL
15
2.5.1
IT Service Management of ITIL
16
2.5.1.1 Service Support
17
ix
3
2.5.1.2 Service Delivery
18
2.5.1.3 ITIL Problem Management Process Model
19
2.6
System Application
19
2.6.1
FrontRange
20
2.6.1.1 Benefits
21
2.6.1.2 Features
22
2.6.1.3 System Requirements.
23
2.6.2 DCMS
25
2.6.2.1 Benefits
25
2.6.2.2 Features
26
2.6.2.3 System Requirements
26
2.6.3 FootPrints
27
2.6.3.1 Benefits
27
2.6.3.2 Features
28
2.6.3.3 System Requirements
29
2.7 Researcher’ s Paper
31
2.7.1 Conventional Problem Resolution
31
2.7.2
Issues In Conventional
32
2.7.3
Solutions
32
2.7.4 Features
34
2.8 Summary
35
2.8.1 Benefits of Systems
36
2.8.2 Benefits of Literature Review
37
METHODOLOGY
38
3.1
Introduction
38
3.2
Project Methodology
39
3.3
System Development Methodology
42
3.3.1
Phase 1: System Planning
44
3.3.2 Phase 2: System Analysis
44
3.3.3 Phase 3: System Design
45
3.3.4 Phase 4: System Implementation
45
3.3.4.1 Unit Testing
46
x
4
3.3.4.2 Integration Testing
46
3.3.4.3 System Testing
46
3.3.5 System Maintenance
47
3.3.6 User Acceptance Test
47
3.4
Project Schedule
47
3.5
Summary
48
SYSTEM DESIGN
49
4.1
Introduction
49
4.2
Organizational Analysis
50
4.2.1 Organizational Background
50
4.2.2 IT Department
51
4.2.3 User Support Service (USS)
55
4.2.4 Current IS/IT Systems
56
4.2.5 Problem Statement
60
4.3
As-Is Process
60
4.3.1
Automated Host Application Using Legacy System
60
4.3.2
Client Server support Manual Processing
62
4.3.3
Data Flow Diagram
63
4.3.3.1
The Overview DFD
64
4.3.3.2
DFD Diagram 1
65
4.3.3.3
DFD Diagram 2
66
4.3.3.4
DFD Diagram 3
67
4.3.4
Entity-Relationship Diagram
68
4.3.5 SWOT Analysis
70
4.4
User Requirements
72
4.5
New Business Process and Data Model
75
4.5.1 System Approach
76
4.5.2 System Process
77
4.5.3 System Functions
77
4.5.4 Context Diagram of ITPMS
79
4.5.5
81
Data Flow Diagram of ITPMS
4.5.5.1 The Overview DFD
82
xi
4.5.5.2 DFD Diagram 1 For Process Problem Recording
83
4.5.5.3 DFD Diagram 1 Process Problem Determination
85
4.5.5.4 DFD Diagram 1 For Process Problem Status
86
Verification
4.5.5.5 DFD Diagram 1 For Record Formatting
87
4.5.5.6 DFD Diagram 1 For Process Archiving And
88
Reporting
5
4.5.6
Entity-Relationship Diagram
89
4.5.7
System Architecture
90
4.5.7.1 System Requirements
91
4.7
Physical Design
92
4.7.1
Database Design
92
4.7.2
Structure Chart
93
4.7.2.1 User Login
94
4.7.2.2 Administrator Login
99
4.7.4 ITPMS Modules
100
4.8
101
Hardware and Software Requirements
4.8.1 Hardware Specification
101
4.8.2 Software Specifications
101
4.9
102
Summary
IMPLEMENTATION AND TESTING
103
5.1
Introduction
103
5.2
Implementation
104
5.2.1 Main Menu
104
5.2.2 Problem Location
106
5.2.3 Problem Rectification
107
5.2.4 Problem Tracking
108
5.2.5 Highlights
109
5.2.6 Summary Report
111
5.3
Test Results.
112
5.3.1 Unit Testing
113
5.3.2 Integration Testing
113
xii
5.3.3 System Testing
114
5.3.4
User Acceptance Test
114
5.4
Administrator User Manual
115
5.4.1 Procedure: Setting Up The Environment
115
5.4.2 Procedure: Administrator Online Processing
117
5.4.3 Procedure:
Administrator
Archiving
And
118
Reporting Processing
6
7
5.4.3.1 SQL Query
119
5.5
125
Summary
ORGANIZATIONAL STRATEGY
126
6.1
Introduction
126
6.2
Roll-Out Strategy
127
6.3
Change Management
128
6.4
Data Migration Plan
129
6.5
Business Continuity Plan (BCP)
129
6.6
Benefit of the System
130
6.7
Organizational Strategy
131
6.8
Summary
131
DISCUSSION & CONCLUSION
132
7.1
Achievements
132
7.2
Constraints & Challenges
133
7.3
Aspirations
133
7.4
Future Enhancements
134
7.5
Summary
134
xiii
LIST OF TABLES
TABLE NO
TITLE
PAGE
2.6.1.1
The summaries of benefits of both systems.
21
2.6.1.2
The system features in both system
22
2.6.1.3a
HEAT PowerDesk system requirement
23
2.6.1.3b
FrontRange Problem Management system requirement
24
2.6.3.3
System requirement for Microsoft Windows web servers
30
Summaries of platforms used by the system.
35
2.8.1
The summary of benefits offered by the system
36
4.2.4.1
Summary of current IS/IT in client server based
58
4.2.4.2
Summary of current IS/IT in host application mainframe
59
SWOT analysis for the as-is process
71
2.8
4.3.5
Users Grouping
4.4.1
4.4.2
4.5.7.1
72
Summarize User Requirement for Each Grouping
74
The proposed hardware and software requirements for
91
the system
xiv
LIST OF FIGURES
FIGURES NO
TITLE
PAGE
2.5.1
Summary of IT Service Management of ITIL framework
17
2.7.3
The structure of the system proposed by the researcher.
33
Waterfall model
43
4.2.2
IT Organizational Structure
52
4.2.3
USS Organizational Structure
56
4.3.1
Context diagram for automated INFOMAN system
61
Client server support manual processing
63
3.3
4.3.2.2
4.3.3.1
An overview DFD for INFOMAN system
65
4.3.3.2
The DFD diagram 1 for INFOMAN system
66
4.3.3.3
The DFD diagram 2 for INFOMAN system
67
4.3.3.4
The DFD diagram 3 for INFOMAN system
68
4.3.4.1
The ERD for host application support
69
4.3.4.2
The ERD for client server manual processing
70
4.5.4
4.5.5.1
Context diagram for to-be process – ITPMS
The overview DFD for ITPMS
81
83
4.5.5.2
The DFD diagram 1 for process problem recording
84
4.5.5.3
DFD diagram 1 for process problem determination
85
4.5.5.4
4.5.5.5
4.5.5.6
DFD diagram 1 for process problem status
verification
DFD diagram 1 for process record formatting
86
DFD diagram 1 fro process archiving and
reporting
88
87
4.5.6
ERD diagram for ITPMS
89
4.5.7
The system architecture for ITPMS
90
The user login structure chart main module
94
Site maps on Problem Location and Prob. Rectification
96
4.7.2.1
4.7.2.1.2
xv
4.7.2.1.3
Site maps for Problem Tracking and Highlights
97
4.7.2.1.4
The site maps of the user login page
98
4.7.2.2.1
The structure chart for the administrator page
99
4.7.2.2.2
The site maps of archiving and reporting process
100
5.2.1.1
Main Menu of ITPMS (upper)
105
5.2.1.2
Main menu of ITPMS (lower)
105
5.2.2.1
Headquarters Main Page
106
5.2.2.2
Branches Main Page
107
5.2.3
Problem Rectification (Assignee)
108
5.2.4
Problem Tracking (Current Problem)
109
5.2.5.1
List of Branches (Highlights)
110
5.2.5.2
List of IT Projects (Highlights)
110
5.2.6.1
Monthly Report Main Page
111
5.2.6.2
Quarterly Report Main Page
112
5.4.2.1
Administrator Login Page
117
5.4.2.2
Administrator Main Page
118
xvi
LIST OF APPENDIX
APPENDIX NO
TITLE
A
Technical Form
B
Daily Problem Form
C
Project Timeline
D
Sample Report Produced
E
Tables Definition
F
User Manual
G
Draft Policy of Problem Management
H
More Detail Report Generated
I
Summarized Results From User Login
J
Steps To Execute WinLamps File For Execution
K
More Snapshots On Administrator Login
L
Steps to Guide The Execution Of SQL Script
1
CHAPTER 1
PROJECT OVERVIEW
1.1
Introduction
This document is to propose the development of a management system which
is a design of an integrated technical problem management at Bank Simpanan
Nasional (BSN).
The technical problem has become an issue because it can affect the
operational and customer service in BSN. Hence, ITPMS is a system that is designed
to integrate the functions of monitoring, escalating and controlling the technical
problem management. In additions this system also is able to supply statistical data or
information for management of BSN.
The main aim of the system is to integrate the two types of processes involved
in the handling of problem management at BSN. The types of processes are:
i.
Automated legacy system
ii.
Manually process of problem management
2
1.2
Background of problem
Helpdesk Unit is one of the units in the IT Department which acts as a liaison
unit for all the technical incidents and IT problems between the IT department
(Jabatan Teknologi Maklumat) and rest of BSN. The Helpdesk Unit which is
established as a special technical support unit since January 2003 is to monitor and
fine-tune the support of the technical services provided by the IT department.
The unit is to handle the problem management process for all the incidents and
IT problems reported from Headquarters and Branches. Therefore the unit is a single
point of contact for IT department in dealing with the user reports and complaints
concerning the IT infrastructure and IT services provided by the IT department. All
incidents and IT problems are channel to this Unit for the identification and analysis
before escalating them to the proper groups or channel for further actions.
This unit will log, monitor and coordinate all technical incidents and IT
problems reported by departments and branches in BSN. As a technical support unit,
the unit also needs to provide statistical data or information to the management for the
purposes of performance evaluation of services given by IT department.
The problem management for technical incidents and IT problems are divided
into 2 categories as follows:
i.
Host Application Support
ii.
Client Server Support
The problem management for host application support is to handle any
problems involving the IT infrastructure that relates to the mainframes and application
systems.
The IT infrastructure and applications system involved are:
i.
Hardware
3
ii.
Software
iii.
Network
iv.
Environment – either production or test system
v.
Execution of application in production environment
vi.
Procedures or user operation
On the other hand, the client server support involves problems relating to
Personal Computer, notebook, servers, LAN and any request on installation of
computer or application systems.
Currently there are two scenarios or types of capturing the information and
data for both categories. The technical IT incidents which relate to client server
support is reported to the Helpdesk unit by completing the Technical Problem Form
and is emailed to the Helpdesk unit for action. Besides the form, the unit also receives
report through telephones call and memorandums.
The second scenario is the host application system involving getting
information or data from the legacy system. All problems related to host application is
registered in this system by the problem owner or problem controller.
The unit also will produce a monthly statistical report on both problems for
management to review. The reports for both categories are produced manually by
extracting data or information compiled from the system and summarized data (table
in Ms Words format) for client server problems.
1.2.1
Host Application Support (HAS)
The problem management for HAS is to handles any problems or incidents
that only relate to the mainframe and application.
4
The HAS is using the IBM system – INFOMAN for handling problem
management process. This is an automated online system that provides facility to
record, view and monitor problem related to IT infrastructure, application and
operational. The system also is used for tracking a problem from its recognition to its
solution.
INFOMAN – Information / Management version 5 release 1 is an IBM system
which started in middle 1990 and is used by the IT Operational department only.
Initially the usage of this system is emphasizing on the change management.
Beginning middle of 2002 and with the establishment of Helpdesk unit, the system is
also extensively used for problem management. The system is a mainframe based
with the support maintenance from IBM.
The user of the system is the IT personnel in the IT department. This user is
the application owner or the problem owner. Every user is given the user-id to access
this system. However, Helpdesk unit is the owner of this system and act as a Problem
Controller.
Problem Controller will monitor, track and escalate the problems
registered in the system. The user is responsible to update the status of the problems
once the problems are solved either with temporary or permanent solution.
The user-id given to IT personnel is only to authorized for creation and
updating the records in the system. The closure and deleting of record is only
authorized by Problem Controller.
1.2.2
Client Server Support (CSS)
The emphasis of problem management in client server support started in
middle 2003. This is due to the rapid growth of system developed using client server
based concept and the widely used of PC and notebook. The client server support is to
5
handles problem related to client server based, personal computer, notebook, printer,
cabling, LAN and also request for installation of computers or application system.
All related technical problems, incidents or request are reported by completing
the technical problem form. The completed form is then email to the Helpdesk unit
for actions. Besides the form, also received report via telephone calls or memo.
The technical problems for CSS are divided into two types that is the problems
from Headquarters and the problems from branches. The problems form Headquarter
is handled by Helpdesk unit. The internal user from Headquarters will email the
technical form to the Helpdesk unit for action. These problems are then escalated
manually to the support group for action by passing the printed technical form. Once
the action is taken, the form will be pass back to the Helpdesk unit for recording the
status.
On the other hand, the user from branches will report the problem through the
Technical Support Unit at branches for actions. This unit will take action and record
the status of problem in the Monthly Report Form. All problems and incidents at
branches will be recorded in this form. At the end of every month, the forms are email
to the Helpdesk unit for reviewing the status. This is one way of monitoring the status
of the problems at branches.
The information or data in the technical form is then transcribe in the excel
format table for record keeping purposes and tracking. The escalation and monitoring
of the reported problems are done manually by checking the status from the form.
1.2.3
Management Reports
The management report is prepared monthly and it is process manually. Data
and information are extracted from the INFOMAN system and excel table for
6
analyzing. Reports produced are used for trend analysis and to check the service
performance of IT to users.
1.3
Statement of the Problem
The delay in solving the technical incidents and IT problems are due to the
improper reporting of the problem to the correct channel. The escalation process of
the technical incidents and problems to the incorrect problem owner or
system/product owner will delay the solution and actions taken. This will give serious
impact to the services provided to the user or customer.
Thus, the purpose of this system is to improve the handling of problem
management and also be able to provide statistical data or information for problem
analysis on time. Often the delay in producing such report is due to the late receiving
the Monthly Form from the Branches and also the time taken to transcribe the
information or data into the Microsoft Excel table is too slow.
In addition, the system also is used for problem tracking and monitoring the
technical support given by the IT department. This is to ensure that all problems are
solved within the timeframe given.
1.4
Project Objective
The objectives of this project are as follows:
i.
To study for the improvement and expedite technical support given by
Helpdesk unit in Jabatan Teknologi Maklumat at BSN.
7
ii.
To analyze and design for the integration of two categories of problem
management, that is the host application and the client server.
iii.
To develop the consolidation of data or information captured from
Headquarters and Branches.
iv.
To formulate policy and procedure of problem management that is
align with the new system.
v.
To provides monthly statistical report for management to evaluate the
performance of the technical support given by IT department at
Headquarters and Branch levels.
1.5
Project Scope
The scopes of the project are:i.
To log and register information and data regarding technical problem
such as request for installation, operational failures to the execution of
application, operational failure to the counter services and Automated
Teller Machine in Headquarters and Branches.
ii.
To control, track and monitor all reported problems and request for
installation and operational or system failure.
iii.
To categorize the problems based on the severity level and also to
prioritize the problems.
iv.
To access and perform online inquiries on the reported problem and
requests by the Helpdesk unit, Technical Support unit at main branch
and problem owner
v.
To produce statistical data and summarize information for the
management. The data or information provided is used as a check list
and references for the management to know and evaluate the service
level of technical and IT support given to the internal and external
customers of BSN
8
vi.
To produce a summary report for the purpose of analysis in the trend
or pattern of problem.
vii.
To develop the system in the web based with the functionality of
problem management to create, update and delete problem records.
viii.
To perform the test plan for the system according the test script
prepared.
1.6
Importance of Project
The importance of this project is to be able to provide a comprehensive system
which integrates all functions of technical problem management and statistical data or
information for the management review. With this system, the service level of
technical support can be improved and actions expedited.
As a summary the system is benefited to the Helpdesk unit with the
following:i.
Improved IT services and quality
ii.
Complete resolution of problems causes are identified and corrected
iii.
Clearly defined the root cause of problems and incidents.
iv.
Expedite the troubleshooting for problem solving
v.
Avoid unnecessary escalations and inappropriate resource allocation
vi.
Avoid longer time to resolution
Integrated Technical Problem Management System is expected to automate
the problem management process and also be able to provide a statistical data or
information for problem analysis. Hopefully with this system, all technical problem
management is monitored, controlled and escalated to the proper problem channel. In
9
addition, with this system, the flow or process of handling problem would be more
systematically managed.
10
CHAPTER 2
LITERATURE REVIEW
2.1
Introduction
This chapter describe the literature reviews done pertaining to the handling
and processing of problem management. The chapter mainly contains information on
the definition of problem management and its benefits in the organizations.
The chapter also contains information pertaining framework of best practices
to use as a guide to develop a solution for handling the problem management process.
The framework studied and analyzed to seek for the compatibility in the solution of
the problem management process.
In addition, the chapter also reviewed similar solutions and software
applications which exist in the current market. The reviews are focusing on the
features and benefits to the organization. In which these applications were analyzed
and compared for better solution in problem management.
11
2.2
Definition of Integrated Problem Management System
This section contains information on definition of the project title. This is to
give more ideas and better views on the problem management system.
2.2.1
Problem Management
Incidents and problems are causes that can impacted the services of a business
especially in IT infrastructure.
a
Incidents
An incident is any event that is not part of the standard operation of a
service and cases, or may cause, an interruption to or reduction in the
quality of that service [1]. Examples of incidents are:i.
User cannot receive email
ii.
Communication line may be down
iii.
User perceive that an application is running slow
Incident management process is to restore normal service operations as
quickly as possible and to minimize the adverse impact on business
operations [2].
b
Problems
A problem is an unknown, underlying cause of one or more incidents.
A single problem may generate several incidents [1][2]. Examples of
problems are:
i.
Failure in the system
ii.
ATM (Automated Teller Machine) malfunction
12
Problem management process is to minimize the adverse impact of
errors within the IT infrastructure and to prevent recurring incidents
related to these errors [1][2]. Problem management gets to the root
cause of problems, identifies workarounds or permanently fixes and
eliminates errors.
2.2.2
Problems Management System
To efficiently and effectively conduct the problem management process, there
is a need to have a systematic process and record-keeping database to resolve any
problem arise. Therefore the systematic process can be achieved by having an
automated process of problem management.
The common process of problem management is dealing with:i.
Identifying and recording the problems encountered
ii.
Performing severity analysis
iii.
Providing for the proper support effort
iv.
Investigating and diagnosing the problems
v.
Defining solutions [3]
Thus, the problem management process is to ensure that all problems are
logged, tracked and monitored. The following section provides more information
pertaining to the problems management process [4].
a
Problems Recording
This process is the initial detection and recording of a problem which
can comes from various sources and mediums. All problems are
logged for further actions.
13
b
Problems Investigation
This process deals with the investigation of the problem and the
diagnosis of the root cause. The data can be used to assess the
resources and skills required to resolve the cause of problem.
c
Error Control
Errors control is the process involved in rectify the solutions
successfully. The objective is to change IT components or procedures
to resolve known errors affecting the IT infrastructure and thus prevent
any recurrence of incident.
d
Problem Closure
Following successful implementation of changes to resolve errors, the
relevant known error record can be closed, together with any
associated incident or problem records. Upon the problem closure, a
problem resolution details should be fully recorded.
2.2.3 Integrated Problem Management System
Integrated problem management system is referring to the integration with
other third party application. However, in this project perspective, the integrated
problem management system is referring to the integration of manual processes and
the automated process if problem management.
14
2.3
Helpdesk
Helpdesk is referring to the departments within the organization that an
information technology user can call to get help with an IT problem. It provides a
central contact point for all end-user requests, including basic questions, incidents,
problems, and change request [5].
The goals of helpdesk are:i.
Provide a unified contact point for end-user communication
ii.
Align people, process and technology to support the business
iii.
Increase end-user satisfaction
Hence, problem management complements the helpdesk in terms of handling the
problems. Helpdesk is to provide a single point of contact for customers and users to
facilitate the restoration of normal service with minimal business impact [2].
On the other hand, problem management is a process to ensure that problems
are identified, logged, tracked and monitored until the problems are solved. Therefore
problem management is a process to support the functionality of the helpdesk in the
organizations.
2.4
Benefits of Problem Management
Implementing the problem management process, organization can identify and
resolve the root cause of any significant or recurring incidents. In order to achieve
this, problem management investigates and analyzes the root cause of incidents to
resolve the underlying problem or provide a temporary solution.
The benefits of having problem management include:-
15
i.
A reduction in the number and business impact of incidents, problems
as problem management begins to resolve the root cause of incidents
ii.
Improve IT service quality as all incidents or problems are
immediately taken action
iii.
Increased knowledge capital. The recorded problems with detail
resolutions provides historic data or information for future problem
analysis
iv.
Timely identification, diagnosis and resolution of problem
v.
Complete resolution of problems as underlying causes are identified
and corrected.
2.5
Framework Of Best Practices - ITIL
The most popular and recognized best practices framework in worldwide is
the Information Technology Infrastructure Library (ITIL). ITIL is a set of detailed
process guidelines, presented in a series of books, containing recommended global
best practices, workflow, templates, and terminology, developed by the United
Kingdom’s Office of Government (OGC)[5]. ITIL was conceived in the late 1980s. It
was originally initiated to improve IT Service Management at the UK central
government; however it is relevant to all organizations; public or private sector, large
or small, centralized or distributed [10]. To date, these books are the only
comprehensive, non-proprietary, publicly available guidance for IT Service
Management [10].
Being a framework, ITIL describes the contours of organizing Service
Managements. The models show the goals, general activities, inputs and outputs of
the various processes on the best practice that can be utilized in different ways
according to the need. The ITIL can be used within organizations with existing
methods and activities in Service Management. By emphasizing the relationships
16
between the processes, any lack of communication and co-operation between various
IT functions can be eliminated or minimized [12].
2.5.1
IT Service Management of ITIL
The IT infrastructure is a term used to describe hardware, software,
procedures, computer-related communications, documentation and skills required to
support IT services. These components and their use must be managed; hence the
term IT infrastructure management is used. Overall, IT services and management of
the IT infrastructure is referred to as IT Service Management [11].
There are 10 core processes and 1 function that comprise the IT Service
Management of ITIL framework. They are grouped and categorized into 2 main areas,
which are:
i.
Service Support which provides guidance for stability and flexibility
for IT services. The main functions is the Service Desk which to
handle processes of identifying and recording IT configuration items,
incidents, problems and changes.
ii.
Service Delivery covers the management of the IT services
themselves. It involves a number of management practices to ensure
that IT services are provided as agreed between the service provider
and the customer.
Figure 2.5.1 exhibit the summary of IT Service Management of ITIL framework.
17
Figure 2.5.1 Summary of IT Service Management of ITIL framework
2.5.1.1 Service Support
ITIL identifies five core processes of service support which are [13]:
i.
Incident management focuses on restoring service to the customer as
quickly as possible to the agreed-upon service levels
ii.
Problem management explores the root cause of an incident and
focuses on determining a solutions that will eliminate it from the IT
infrastructure
iii.
Change management deals with maintaining control over the IT
infrastructure to prevent changes from creating new incidents
18
iv.
Configuration management links IT assets to their relationships, both
physical and in respect to key business processes
v.
Release management addresses how to introduce new hardware and
software into an organization as smoothly as possible without creating
new incidents and problems.
2.5.1.2 Service Delivery
ITIL identifies five core processes of service delivery which are [13]:
i.
Service level management emphasizes the importance of determining
service needs from the customer or users
ii.
Financial management focuses on understanding exactly what it costs
to supply a particular service to a customer or user.
iii.
Capacity management looks at managing both the capacity of assets
and the performance of those assets to provide the level of service the
customer needs
iv.
Availability management is all about providing service to the
customer, as well as continually examining the reliability of the IT
infrastructure to improve upon the availability of service
v.
Continuity management identifies the critical services a business
needs to stay in business and focuses on providing the right level of
service to maintain continuity during typical day-to-day operations as
well as under adverse circumstances such as disaster recovery.
The ITIL provides businesses with a customizable framework of best practices to
achieve quality service and overcome difficulties associated with the growth of IT
systems. Hewlett-Packard and Microsoft are two businesses that use ITIL as part of
their own best practices frameworks.
19
2.5.1.3 ITIL Problem Management Process Model
The ITIL problem management process model is made up of several parts that are
closely aligned with other activities from other process areas[14]. The model
components are:
i.
Problem control
ii.
Known-error control
iii.
Proactive problem management
iv.
Trend identification
v.
Reporting problem management data
vi.
Structured reviews of major problems.
The ITIL problem management process model aims to minimize the total impact of
problems on the organization [14]. Problem management plays an important role in
the detection and repair of problems to prevent their reoccurrence [14].
2.6
System Application
This section reviews similar system application for the solution of problem
management system. Often, these solutions are provided by the vendors or service
provider. There are various solutions available in the market. Normally these solution
need to customize and tailor to the organization requirements.
The reviewed solution provided by the vendors for the problem management
systems are:i.
FrontRange
ii.
DCMS
iii.
FootPrints
20
2.6.1
FrontRange
FrontRange Solutions USA Inc., is a leading international provider of Service
Management and CRM solutions that have been used by more than 130,000
companies to automate and manage IT projects and customer-facing initiatives [6].
FrontRange Solutions offering two types of product to consider for the usage
of problem management system. HEAT PowerDesk is a client based system which an
affordable and practical helpdesk solution. It increase customer satisfaction and
reduce costs at the same time specifically designed for growing organizations. On the
other hand, FrontRange Problem Management is a web based system with automated
software used to identify problem sources and resolutions. It also helps to minimize
the negative impact of problems within the IT infrastructure.
21
2.6.1.1 Benefits
Table 2.6.1.1 shows the summaries of benefits of both systems for
comparison. The overall benefit of both systems is to resolve or overcome the
problems or issues efficiently and effectively. In addition, both systems are also
aiming to improve customer satisfaction.
HEAT PowerDesk
FrontRange Problem Management
Meet service level agreements with
Improve customer and analyst
confidence
satisfaction
Increase overall operational
Lower the number of incidents
effectiveness
Proactively solve problems
Resolve issues more quickly
Streamline repetitive tasks
Share knowledge more easily within
the organization
Improve customer satisfaction
Table 2.6.1.1 The summaries of benefits of both systems.
22
2.6.1.2 Features
Table 2.6.1.2 list the system features in both system for better view of the
system. The features listed show the differences between the two systems. The
features in HEAT PowerDesk are to support the functionality as a helpdesk system,
whereas the features in FrontRange Problem Management are to support the
functionality of handling the problem management system.
No
HEAT PowerDesk
1. Autotasks – send email, print work
orders, or launch other application all
FrontRange Problem Management
Big-picture view – easily relate
problems to incidents and changes.
with single keystroke.
2. Quick features – define simple
Problem board – alert technicians to
repetitive tasks, accessible with single
the status of knows issues, easing
click.
troubleshooting and assignment.
3. Automatic ticket generator (ATG) –
Real time reporting – get immediate
automatically creates new call tickets
visibility into problems with
and update existing tickets via a
dashboard interface.
variety of sources
4. HEATBoard linked calls – save time
Extends the value of HEAT - to
and work by allowing multiple calls to
integrate ITIL best practices into the
be linked to an issues, updated and
processes to enhance the service desk
closed automatically
solution.
5. Comprehensivel reporting tools – get
the right answer wizards.
Modular architecture – to integrate
problem management with any other
FrontRange modules, as well as with
third-party applications.
6. Scalable solution – utilize the totally
compatible HEAT Service & Support
Support for industry best practices,
regulatory requirements.
software.
Table 2.6.1.2 The system features in both system
23
2.6.1.3 System Requirements.
Table 2.6.1.3a and 2.6.1.3b shows the system requirement for both systems.
HEAT PowerDesk and FrontRange Problem Management operate in a client based
platforms.
System Application
HEAT PowerDesk
Client
Server
Database
Microsoft Windows
Microsoft
Microsoft
NT 4.0 Workstation
Windows NT 4.0
Access 2000 /
Microsoft Windows
Server or
2002 / 2003
2000 Professional
Microsoft
Microsoft
Microsoft Windows
Windows 2000
SQL Server
2003 Professional
Server
2000 SP 3
Microsoft
Windows 2003
System :
Server
CPU: 166MHz Intel
Pentium
Hardisk :200 MB
System :
RAM: 32 MB
CPU: 166MHz
Intel Pentium
Hardisk :200 MB
RAM: 64 MB
Table 2.6.1.3a HEAT PowerDesk system requirement
24
System Application
Client
Server
Database
FrontRange Problem
Microsoft
Microsoft .NET
Microsoft
Management
Windows 2000
1.1
SQL Server
Pro
Microsoft Internet
2000 SP3
Microsoft XP
Services (IIS)
Oracle 9,
Prefessional
server 5.0
release 2,
Microsoft .NET
Microsoft Internet
driver 9.2.0.5
1.1
Explorer 5.5
Microsoft Internet
Services (IIS)
server 5.0
Microsoft Internet
Explorer 5.5
Systems:
Systems:
CPU: 600MHz
CPU: 1-GB Intel
Intel Pentium III
Pentium III
processor
processor
Hardisk :100 MB
Hardisk :500 MB
RAM: 512 MB
RAM: 1 GB
Table 2.6.1.3b FrontRange Problem Management system requirement
25
2.6.2
DCMS
Data Center Management Systems (DCMS) was incorporated in 1986 with a
commitment to provide complete software solutions that are useful, usable,
reasonably priced, and designed with clear understanding of the real day-to-day needs
of large-scale data processing environments [7].
DCMS is a full service IT solution development and consulting company
specializing in IBM OS/390, z/OS and Client/Server environments.
Problem Management and Reporting System (PM/RS) is a mainframe based
with comprehensive and flexible information management system designed to
coordinate and manage the life cycle of problems, complaints, questions, and requests
for changes. PM/RS is a powerful tool which provides for the automated recording,
diagnosing, assigning, tracking, reporting, and archiving of problem information.
2.6.2.1 Benefits
The benefits DCMS are as follows:
i.
Very easy to install, configure and use.
ii.
The learning curve for system administrators and users is very short.
iii.
Usage is highly intuitive and self-explanatory.
iv.
Extensive online help screens and tutorials are available with single
key stroke.
26
2.6.2.2 Features
Some of DCMS features are as follows:
i.
PM/RS automatically opens and assigns problem for production
program, JCL, CICS transaction, network, distributed software and
hardware failures.
ii.
Detailed information about each failure is automatically captured and
recorded.
iii.
PM/RS automatically assigns problems to the appropriate individual
or group based on user-customized rules.
iv.
Data entry time is minimized with the use of modifiable tables and
user-defined reusable templates.
v.
PM/RS builds customer confidence and enhances satisfactory by
tracking and scheduling customer return calls.
vi.
Historical data contained in the data base can easily be searched.
vii.
Simultaneous multi-user/multi-system access is supported
2.6.2.3 System Requirements
PM/RS is available for any processor that supports z/OS, and OS/390
operating system environments. PM/RS utilizes ISPF/Dialog Manager (DM) and
ISPF/Program Development Facility (PDF). VSAM is used as the basis for the DCMS
proprietary DBMS.
27
2.6.3
FootPrints
UniPress Software, Inc. is a privately held company that has served nearly
23,000 customers to date. Founded in 1983 by Mark Krieger and Fred Pack, the
company was initially established as a developer and distributor of PC and UNIX
connectivity solutions[8].
In 1996, UniPress created FootPrints to fill a void in the marker for a
comprehensive, affordable web-based support tool that is easy-to-use, manage,
implement, and customize.
FootPrint for eService is a comprehensive support automation system to track
and manage all the customer issues throughout the problem management life cycle.
2.6.3.1 Benefits
The benefits of FootPrints are as follows:
i.
Extremely easy-to-use, manage and customize
ii.
Enables organizations to centrally manage all request
iii.
Web-based self-service enables customer to search for their own
solutions and submit track issues.
iv.
The customer problem management process can be streamlined using
knowledge management, two-way email management, automatic
reporting on productivity and SLA compliance.
28
2.6.3.2 Features
Some of the system features are as follows:i.
Centrally manage all issues with comprehensive tracking – the system
centrally track and manage multi-channel request, i.e. phone, email,
the web, live chat, and wireless devices. It also record, assign,
escalate, and manage issues throughout their full life cycle
ii.
Save time using well-defined, easy-to-navigate web architecture – the
system work with 100% web-based architecture by design. Make the
flexible, powerful, and highly customizable user interface. The system
can archive, backup, restore, and purge ticket data with built-in
database management utilities
iii.
Fully customize FootPrints using simple, web-based forms and project
wizards – without any programming or databases administration
iv.
Improve the workflow and change management – the system support
task
automation,
including
auto-routing,
escalations,
email
notifications, and broadcast messages.
v.
Manage customer service level agreements (SLAs) – the system
automate and track customer service level agreement management
process for internal and external service agreements with fully
customizable SLA module for contract information, automated due
dates, multi-tiered escalations, and reporting
vi.
Provide customer self-service online for instant help 24/7 – empower
customers with the ability to submit and track their own issues and
keep customers informed with email status notifications
vii.
Build and access solutions knowledge for agents and users – create
separate technical and self-service solutions knowledge bases for
agent and customer access. The system also control submissions to
knowledge bases by imposing an approval process
viii.
Manage two-way support email – manage, age, query, and track all
tickets submitted via email. Send customizable email alerts and
notifications, including mass emails.
29
ix.
Track time, trends, and performance with graphical reports and
metrics – create real-time, customizable metrics and graphical reports,
plus other built-in and customizable reports. Also generate quick
reports, custom reports using templates, cross project reports, and
automatically scheduled reports
2.6.3.3 System Requirements
FootPrints supports numerous popular web servers, including Microsoft
2003/2000/NT/XP, Linux and Unix, and many databases, including Microsoft SQL
Server, MySQL, Oracle, Microsoft Access, Postgres, and the built-in FootPrints
database. Table 2.6.3.3 shows the system requirement for Microsoft Windows web
servers’ versions.
30
Database
Client
Server
Web Browser
Microsoft SQL Microsoft
Microsoft Windows NT
Microsoft Internet
Server 2000 / Windows NT 4.0
Server
Explorer 5.5
ver 7
Workstation
Microsoft Windows 2000
Netscape v 6
Microsoft
Server
Windows 2000
Microsoft Windows 2003
Professional
Server
Microsoft
Windows 2003
Professional
System :
System :
CPU: 2.4 GHz Intel
CPU: 2.4 GHz
Pentium 4
Intel Pentium 4
Hardisk :1 GB
Hardisk :300 MB
RAM: 1 GB
RAM: 512MB
Table 2.6.3.3 System requirement for Microsoft Windows web servers
31
2.7 Researcher’ s Paper
The section reviews the researcher’s paper with similar system to the proposed
topic. The paper proposes a web-based problem management system for distributed
software development projects.
The paper begins the discussion with the conventional problem resolution and
issues arise with this conventional process. In the past, problems found or arise were
communicated from group to group by circulating paper-based documents that
recorded the problem.
Then the paper proceeds to the proposed system that enabled users to
accomplish the smooth communication of problem management between groups.
2.7.1
Conventional Problem Resolution
The resolution process is described as follows [9]:
i.
When any problem is found, the discoverer writes the problem to a
document, and sends it to the manager.
ii.
The manager determines a proper group for resolutions, and assigns
the document.
iii.
The group that was assigned starts resolution work on it.
iv.
The manager has to update the master file for problems wvery time
receives a document.
32
2.7.2
Issues In Conventional
There are many issues arise pertaining to the conventional processing. The
issues arise are as follows [9]:
i.
Delay in communication of problem information – the project is
distributed geographically, so communications by paper-based
documents are slow
ii.
Difficulty of grasping the present condition of the problem resolution
work – to specify the proper group that should be requested for
resolution and it takes a lot of time to reach the proper group
iii.
Heavy load of assignment work on the manager – the problem
manager collects documents (problems) and assigned to a proper
group, which means the manager has to examine every document or
problem
iv.
Delay in assignment work – the resolution work is delayed because
problems remain at the problem manager without being processed or
they are sent wastefully round to other groups
v.
Omissions in resolution work are caused by – the improper group
requested for resolution will cause the omissions or incomplete
resolution of the problem.
2.7.3
Solutions
The researcher emphasize in the paper that important point in problem
resolution is to notify the proper group of the existence and content of the problem as
soon as possible. Therefore to achieve this, the paper proposes the following solutions
[9]:
33
i.
WWW-based System – the process of resolution work from inputting
the problem to reporting results can be operated from the WWW
browser.
ii.
Real-time Management – the problem and result information is stored
in one database.
iii.
Assignment using Bulletin Board – the manager specifies a group and
assigns the problem directly and the leader of each group takes over
the problem which is posted on the bulletin board by the manager.
iv.
Using spreadsheet as Helper Application of WWW browser – the
system can send problem data to the client side for spreadsheet
application.
The process of resolution work from inputting the problem to reporting results
can be operated from WWW browser. The problem is stored in database and a display
of status of the problem is by updating the database every time there is a user-input.
The CGI is used to connect the WWW server and database. Figure 2.7.3 illustrates the
structure of the system proposed by the researcher.
Clients
Server
Problem
Info
DBM
WWW Browser
HTTP
WWW
Server
CGI
Programs
HTML
Templates
Figure 2.7.3 The structure of the system proposed by the researcher.
34
2.7.4
Features
The researcher intention of developing this problem management system as a
WWW-based system is for the purpose of higher efficiency in problem management
resolution work.
The features of this system are summarized below [9]:
i.
This system is a WWW-based system which can control the flow of
problem information – the process of resolution work from inputting
the problem to reporting results can be operated from the WWW
browser
ii.
This system can show the progress in resolution work in real time –
the problem and result information is stored in one database, and a
display of the latest status of problems is possible by making it reflect
each input and update
iii.
This system assignment work by using the bulletin board – the
manager specifies a group and assigns the problem directly. The group
leader takes over the problem which is posted on the bulletin board by
the manager
iv.
The system has various views to match the purpose of each work –
problem information can be displayed by selecting views
v.
The system can send problem information to the client-side for
spreadsheet application – the system is using the Spreadsheet as
Helper Application of WWW browser, therefore users can make and
use macros personally creating graphs and documents
vi.
The system has authorization and logging facilities – the system has
the facility to authorize user operation such as submission, approval,
assignment and take-over. The systems also can log which records the
history of user-operations on each problem and can be used to locate
issues being wastefully moved to other group.
35
2.8 Summary
From the literature reviews done, it is found out that there are various
platforms in developing the application for problem management system. The
selection of platform in developing the system is depending to the requirement of the
organization. To align with current technology, the web based system is seen as more
competitive in developing the system. The most commonly platform used to develop
the system is the web based. Table 2.8 lists the summaries of platforms used by the
above mentioned system in developing the problem management system.
No
1.
Systems
HEAT PowerDesk
Platform
Client server
Comment
x
More reliable if the system is
only used within a department.
x
The volume of data is small to
moderate.
2.
FrontRange
Web based
x
With LAN connection
x
More reliable if the system is
Problem
used distributed.
Management
x
The volume of data is moderate
to large.
3.
Mainframe
DCMS
x
With WAN connection
x
More reliable if the system is
only centralized.
4.
FootPrints
Web based
x
The volume of data is large.
x
More reliable if the system is
used distributed.
x
The volume of data is moderate
to large.
x
With WAN connection
Table 2.8 Summaries of platforms used by the system.
36
2.8.1
Benefits of Systems
Every system is having own benefits for the users. Table 2.8.1 summarizes the
benefits offered by the system:
Benefits
HEAT
FrontRange
PowerDesk
Problem
DCMS
FootPrints
/
/
/
/
/
/
Management
Proactively solve problems
/
/
Improve customer and analyst
/
/
satisfaction
Easy to install, configure and
use
Streamline repetitive tasks and
/
/
process
Enables organizations to
centrally manage all request
Web-based self-service enables
/
customer to search for their own
solutions and submit track issues
Table 2.8.1 The summary of benefits offered by the system
/
37
2.8.2
Benefits of Literature Review
The analysis of literature review had broadened the scope of problem
management process. The information and findings collected from the literature
review is used as a guidance to develop the proposed system. Hence, the proposed
system will include the following criteria:i.
Be able to use the system as an automated tools to implement the
problem management process – the system can used to input the data,
for data storing and also to access and retrieve the data or information
ii.
Be able to use as an Executive Information System to supply statistical
data or information to the management – the system produces various
statistical data and summary reports for the management analysis
iii.
Be able to use as a Knowledge sharing among the users – the data or
information stored as archive can be access for references.
38
CHAPTER 3
METHODOLOGY
3.1
Introduction
This chapter is discussing the methodology of the project. The discussion is on
the project methodology and the system development methodology. Apart from this,
the chapter outlines the project timeline for the management of the project.
The project methodology for this project starts from defining the project goal
until the closure of the project.
On the other hand, the system development methodology of this project covers
all the phases in System Development Life Cycle (SDLC).
In analyzing and designing the problem management system, the author is
referring the literature reviews done on the similar applications as a basis for
developing the system. Hopefully with this basic guidance, it can help to come up
with an efficient and effective system so that it can benefit the users of this system.
39
3.2
Project Methodology
During the project implementation, each phase must successfully complete
before moving on to the next phase. By following this project life cycle approach, it
provides better management control of the project.
The project methodology used for developing this project is the project life
cycle which involves several phases. The phases for this project include:
a.
Planning
This phase is to describe the project plan, the need for the project and
an overview of the work involves in the project. The project plan
involves defining the objective and scope of the project. However, the
project objective and scope for problem management is already
identified in Chapter 1.
The project timeline is also catered to identified the task or activities
involved in the project. This project timeline is used as a guide to
monitor and tracking the development of the project.
b.
Development
In this development phase, a more detailed project plan is identified.
The activities or task involve in the project is reviewed and refined.
This phase also identified the platform used to develop the system.
The problem management system will operates in the web based. The
system is handled by the internal users in Headquarters and users from
main branches. The internal users in Headquarters are the Helpdesk
Unit, whereas the users from main branches are the Technical Support
Unit.
40
In this phase, the fact finding techniques are also identified. The
information gathered during the fact finding is very useful and helpful
in developing the system.
The techniques used include the following:
i.
Document review
During the document reviews, the operational procedure and
the user manual for the existing legacy system is reviewed.
The screens view and the existing processes on the legacy
system are studied.
In addition all Technical Form and Daily Problem Form used
in manual processing are also reviewed. See appendix A for
the Technical Form and appendix B for the Daily Problem
Form.
ii.
Observations
From the observation done for the current problem
management process, there is a need to change the processing
method. For example is the time taken for preparation the
monthly report is always delayed and slow. All forms which
are emailed to the Helpdesk Unit are manually compiles,
extracted and transcribe into the Microsoft Excel table for
reporting.
Thus, sometimes during the manual process, errors can occurs
and the consequence is on the reporting. The report will shown
the discrepancy on the figures reported. Hence, the report
produced is not accurate and could be wrong.
41
c.
Implementation
In this implementation phase, the project would need to obtain the
required hardware and software. The IT infrastructure for the project
requirement is checked and verified. This is to ensure that the project is
successfully implemented.
During this phase also, the system developed should be thoroughly
tested to ensure the integrity and the capability of the system. Before
actual implementation, the system should have been signoff by the
users for the acceptance.
d.
Close-out
The last phase of the project life cycle is called close-out. In this phase,
all of the work is completed with the user acceptance of the project. At
this stage, the system is ready for installation and used by the user.
42
3.3
System Development Methodology
The system development approach to use in developing the problem
management system would be the Waterfall model. The methodology describes the
activities involves in all phases.
Each of the phases will describe activities and functions that the problem
management system will perform. The phases in Waterfall model for the development
of this system is as follows:i.
System Planning
ii.
System Analysis
iii.
System Design
iv.
System Implementation
v.
System Maintenance
The model is structured sequentially and the output of each phases will
cascading to the next phases. After each phase has completed and well defined, the
next phase will be easily to proceed and accomplish.
Figure 3.3 exhibit Waterfall model. The dotted lines indicate the interaction in the
feedback to the earlier phase.
43
x
x
x
Phase 1
System Planning
Identify project
objective and
scope
Defining
general problem
Assessment on
data collected
x
x
x
Phase 2
System Analysis
x
x
x
Develop user
requirement
Documenting
system’s
functionality
Determine new
system’s
functionality
Develop system
specification
Identifies
module affected
Identifies
outputs, inputs
and processes
Phase3
System Design
x
x
x
User acceptance
Install system
and ready to use
System
monitoring
Phase 4
System
Implementation
x
x
Program coding
Performing
series of test
Figure 3.3 Waterfall model
Phase 5
System
Maintenance
44
3.3.1
Phase 1: System Planning
The main purpose of this phase is performing a preliminary investigation to
identify the objective and scope of the project. This preliminary investigation is
important because the results will affect the entire development process.
This is the initial phase which helps the developer in understanding the
priorities and important elements before proceed to next phases. In this phase, the
user’s aims and objectives specifically the Helpdesk Unit in using the system will be
considered. Therefore, besides the users requirements, the system also should be easy
to use and user friendly.
The determinations in problem management system are also derived during
the document reviews and form the observation. Form the information dan data
collected, assessment is made to see whether there is a need to change or modified the
current process. Assessment on the user of the system is also made to find out what
are the users expectations on the system.
Thus, the write is trying to align the users expectations with the objectives and
scope defined earlier.
3.3.2
Phase 2: System Analysis
This stage requires the development to come up with the specification on the
problem management system. In this phase, a detail explanation on the system is
given. The system will tell more about what the system will do and how it will be
done.
45
In this stage, also involves the documenting of the existing system’s
functionality and determining the new system’s functional requirement.
3.3.3
Phase 3: System Design
At this stage, it will identify all necessary outputs, inputs and processes. This
phase will basically to identify the software specification. The software specification
will list out the detail design of the system. The reason for this specification to be
detail is so that the developers can get more information to develop the system
efficiently.
However, there might be changes to the specification during the actual
development. But, the changes should not affect the functionality of the system. The
changes could be due to the constraints or unforeseen problems encountered during
the development of the system.
3.3.4
Phase 4: System Implementation
In this stage, the new system is constructed. The developer will develop the
system based on the design. This phase will ensure that all modules or programs
developed meet the user requirements.
This phase also conducting the testing and refining the module to validate and
verify the module meets the system specification. After performing the coding, the
system will tested to make sure that it is functioning correctly.
46
The types of testing that this system will perform are:
i.
Unit testing
ii.
Integration testing
iii.
System testing
iv.
User acceptance testing
3.3.4.1 Unit Testing
The unit testing performed is to identify and eliminate any execution errors
that could cause the program to terminate abnormally and the logic errors could also
be checked and verified.
3.3.4.2 Integration Testing
This integration testing is to verify that each module developed could integrate
each other to perform the whole process of the system.
3.3.4.3 System Testing
The system testing is done to perform a final test of all modules and verify that
all system components are integrated properly. This testing also is to demonstrate that
users can interact with the system successfully.
47
3.3.5
System Maintenance
In this phase, system is installed and ready to use. After installation and the
implementation, the system will be monitored for certain period to check for the
performance.
In system maintenance, probably there is a need for enhancement. The
enhancement is to provide new features and benefits to the system.
3.3.6
User Acceptance Test
The user acceptance test is performed to ensure that the system is functioning
well and follows the specification given. The capability of the system is also tested in
which the system should be error free when is launch.
The users will verifies and signoff the system once they satisfied with the
system.
3.4 Project Schedule
The project schedule is the project timeline prepared to list the project activities
or tasks and their corresponding start and finish dates. This timeline also used for
project tracking and monitoring. See appendix C for detail project timeline.
48
3.5 Summary
This chapter has discussed the project methodology and system development
methodology used to develop the problem management system. The chapter described
in detail the phases involves in developing the system. The problem management
system is based on Waterfall model.
49
CHAPTER 4
SYSTEM DESIGN
4.1
Introduction
This chapter is describing the analysis of the existing problem that exists in the
organization, the design of the new system with the justification on how the new
system will meet the identified requirement.
The chapter starts with detail analysis on the organizational structural and the
existing system. This will give clearer picture or scenario of the current business
process and data model of the organization. In conjunctions this chapter also outlined
the user requirement for the new system.
The organizational analysis provides general information on the organizational
particularly with the department that relate to the project.
Current process which relates to the system is studied and analyzed to get
clearer views. Information provided is used as a basis to guide in the development of
new system.
50
This chapter also will further explaining on the conceptual design and the
physical design of the system. The conceptual design of the system is explaining on
the system approach processes, the Data-Flow Diagram (DRD) , Entity-Relationship
Diagram (ERD) and also briefly on the system architecture design.
Further this chapter providing detail description on the physical design of the
system. In which it includes the detail design on the database, structure chart or site
map and detail module design with features.
4.2
Organizational Analysis
This section provides information on the organizational context that involves
with this problem management system. The information provided will help to
understand the organizational structural that relates to problem management.
4.2.1
Organizational Background
Bank Simpanan Nasional (BSN) was established in 1974 under the Act of
Parliament 146 – Law of Malaysia 1974. with the bank launching, all duties and
responsibilities under the Post Office Saving Bank Act were taken over by BSN. The
Bank is a statutory body under the Ministry of Finance.
The objectives of the Bank are:i.
To promote and mobilize savings, particularly from the small savers.
ii.
To inculcate the habit of thrift and savings.
iii.
To provide the means for savings by the general public.
51
iv.
To utilize the funds of the Bank for investment including financing of
economic development of the nation.
v.
To promote the interest of its depositors and other customers.
Bank Simpanan Nasional branches are throughout Malaysia. There are 13
main branches with over 300 mini branches at every state.
4.2.2
IT Department
The IT department in BSN is known as Jabatan Teknologi Maklumat is
headed by an IT Director. The IT departments are divided into 3 divisions and 2
sections. Each division is administered by an IT Manager and the sections are
reported direct to the IT Director.
The IT departments in Jabatan Teknologi Maklumat are as follows:
a.
IT Operations Division (Bahagian Operasi Teknologi Maklumat)
b.
System Security Division (Bahagian Keselamatan Sistem)
c.
Application Development Division (Bahagian Pembangunan
Aplikasi Sistem)
d.
IT Strategy & Architecture Section (Seksyen IT Strategi &
Senibina System)
e.
User Support Services Section (Seksyen Perkhidmatan Sokongan
Pengguna)
Figure 4.2.2 shows the IT organizational structure of an IT department.
52
Chief Exwcutif Officer
(GM)
Deputy General
Manager
(DGM)
IT Director
(JTM)
IT Operations
Division
(BOT)
System Security
Division
(BKS)
Application Dev.
Division
(BPA)
IT Strategy &
Architecture Section
(PST)
User Support Service
Section
(PSP)
Figure 4.2.2 IT Organizational Structure
a.
IT Operations Division
The IT Operations Division is to deliver stable, efficient and effective
technology operations and to manage infrastructure performance and reliability at
optimized costs.
The functions and activities of this division are:i.
Management of IT facilities.
ii.
Custodian and management of production data.
iii.
Infrastructure availability and capacity management.
iv.
Determine capacity requirements to deliver IT services, to support the
bank’s business growth.
v.
Determine availability requirements in business terms.
53
b.
vi.
Continuously monitor, review and improve availability.
vii.
Plan and implement solutions in production environment.
System Security Division
This division is to provide secured IT infrastructure and to manage quality
assurance and audit and regulatory compliance.
The functions and activities of the division are:
i.
IT Security Management.
ii.
Change Management and quality assurance.
iii.
DR coordination.
iv.
Review and develop policies and standards for improvement and to
ensure compliance.
c.
v.
Review and monitor security violations.
vi.
Manage and control user access.
Application Development Division
This division is to provide quality, secure and effective solutions to support
business plan and strategies of the Bank, at optimized cost.
The functions and activities of this division are:
i.
Design and develop IT solutions.
ii.
Management of SDLC (System Dev. Life Cycle).
iii.
Project Management
iv.
Identify new business/IT opportunities.
v.
Provide continuous support on computerized application systems and
coordinate between IT Department and business users.
54
vi.
Manage projects according to agreed project schedule.
vii.
Evaluate and recommend between ‘in-house’ development and third
party solutions.
d.
IT Strategy & Architecture Section
This section is to manage IT Strategic planning and IT enterprise architecture
to enhance the value of IT to address business needs.
The functions and activities of this section are:
i.
Strategic Planning.
ii.
Tracking of IT Business Plan, projects and contracts.
iii.
Special IT initiatives.
iv.
Review and update the IT strategic Plan.
v.
Define and develop an Enterprise Architecture using the EA Process
Model approach and aligned to business strategies.
vi.
Provide monthly status report on the progress of projects and
operational action plans.
vii.
e.
Keeps track of contract renewals and alert the owner.
User Support Service Section
This section is to provide first level support and single point of contact to users
and to manage IT related problems and assets.
The functions and activities of this section are:
i.
Problem and incident management.
ii.
Provide initial investigations and attempt first level resolution.
iii.
Monitor incidents & problems and escalate them as needed.
55
iv.
Provide timely feedback to Users.
v.
Produce monthly status reports.
vi.
Track problems until resolution.
vii.
Review problems for improvement.
viii.
Plan and organize tasks for technical support at branch and track their
delivery.
ix.
Develop and coordinate branch rollout plan for technical support at
branch.
4.2.3
User Support Service (USS)
Customer Service Support section is also known as Helpdesk Unit previously
was established in year 2004. This section acts as a liaison unit for all the technical
incidents and IT problems between the IT departments and the rest of BSN.
The section is a single point of contact for all technical incidents and IT
problems arise and reported to the IT department. All problems are centralized at this
section before the escalation to the proper channel.
The main function of this section is to handle the problem management. There
are 2 main categories of problem management that exist in BSN environment. As
mentioned before, these categories are the host application support and client server
support.
As of the result, the section is divided into 2 groups handling and managing
both categories. The section reported directly to the IT Director and lead by a Senior
System Analyst known as Head of Section. Each group in this section is control and
monitor by the System Analyst which report under the Head of Section. Figure 4.2.3
shows the organizational structure for this section.
56
IT Director
(JTM)
Head of Section
(HOS)
Host Application
Support
(HAS)
Client Server Support
(CSS)
Figure 4.2.3 USS Organizational Structure
4.2.4
Current IS/IT Systems
The current IS/IT system is divided into 2 platform that is the client server
based and mainframe. Each of the platform is having own system or application,
operating system and software.
a
Client Server Based
The current system or applications that operate in client server based
are as follows:
i.
Branch Delivery System (BDS)
This is a branch system environment which is used for
accessing and performing the financial transactions.
ii.
Sistem Kredit Bersepadu (SKS)
57
SKS is the system used to handle and process all types of loans
transactions.
iii.
Sistem Sumber Manusia (SSM)
This is a human resource system which keeps and manages all
the staff profiles.
iv.
Integrated Financial Asset System (IFAS)
IFAS is a system which used to manage all the assets in Bank
Simpanan Nasional.
v.
Executive Information System (EIS)
The system is used by the management group to access
statistical information and data on the monetary transactions
Table 4.2.4.1 shows the summary of current IS/IT in client server based.
58
System/Application
Operating
Software
Database
System
BDS – Branch Delivery
Microsoft
System
Window NT
Dec Bank
Microsoft
SQL 7
– Client /
Server
SKS – Sistem Kredit
Microsoft
Bersepadu
2000 client /
Infopro
Oracle
DB2
server
SSM – Sistem Sumber
Microsoft
Manusia
Window 98
IFAS – Integrated Financial
Microsoft
Assets System
Window XP
PeopleSoft
Microsoft
SQL 7
SAP
Microsoft
SQL 7
Pro
EIS – Executive Information
Microsoft
System
Window XP
SAS
-
Microsoft
Window
2000
Table 4.2.4.1 Summary of current IS/IT in client server based
b
Mainframe based
The current system or applications that operate in host application
mainframe are as follows:
i.
Sistem Giro Baru (SGB)
The system is to handle the BSN GIRO account which to
provides an efficient cashless collection and payment system
for both individuals and corporations.
ii.
Sijil Simpanan Tetap (SST)
59
The system is to handle the fixed deposit scheme.
iii.
Buku Akaun Simpanan (BAS)
This is the Ordinary Savings Account that operated through a
passbook which records all transactions at any BSN branch or
any Post Office.
iv.
Sijil Simpanan Premium (SSP)
This system is to handle the Premium Saving Certificates
Scheme which is another type of saving. By saving at least RM
10 in the scheme – the equivalent of 1 unit of Premium saving
Certificates a saver is eligible to participate in regular draws
with major prizes.
Table 4.2.4.2 shows the summary of current IS/IT in host application
mainframe.
System/Application
Operating
Software
Database
System
SGB – Sistem Giro Baru
IBM OS/390
CoolGen
DB2
COBOL
SST – Sistem Simpanan
IBM OS/390
Tetap
BAS – Buku Akaun
CoolGen
DB2
COBOL
IBM OS/390
COBOL
VSAM file
IBM OS/390
CoolGen
DB2
Simpanan
SSP – Sijil Simpanan
Premium
COBOL
Table 4.2.4.2 Summary of current IS/IT in host application mainframe
60
4.2.5
Problem Statement
There are two types of handling the problem management that is by using
automated legacy system and also by manual processing. Therefore, this will cause
delay in solving the technical incidents and IT problems due to improper reporting of
the problem to the correct channel.
4.3
As-Is Process
This section describes the as-is process that exists in the current environment
that relates to the system. As explained in previous chapter, the problem management
processing involved 2 categories:
4.3.1
i.
Automated host application using legacy system
ii.
Client server support manual processing.
Automated Host Application Using Legacy System
The first category is the automated processing using the legacy system that is
INFOMAN for host application support. This system is a mainframe based.
The user of this legacy system is the IT Departments. Every user is given a
user-id to access this system. Helpdesk unit is the owner of the system and is given
authority as a Problem Controller to access the system.
61
The types of problem logged into the system are IT problems that relates to the
system or application failure and also the malfunctioning of the hardware or
computers. Nevertheless the network problems are also logged.
Problem owner will track, monitor and escalate the problem to the proper
channel for action. The problem records are notified to the problem owner either
through email or telephone calls. Once action is taken either temporary or permanent
solution, the problem owner is responsible to update the record for status of the
problem.
Problem Controller will check and verify the record. If the problem is solved,
the status of record is updated to Fixed. The record will only close after monitoring
the status. The closure of problem record is only authorized by the Problem
Controller. The record is put into archive once the status is closed.
The statistical report is prepared monthly by extracting manually data and
information from the system. Figure 4.3.1 illustrates the context diagram for
automated INFOMAN system.
RECORDUPDATE
RECORDUPDATE
Helpdesk Unit
IT DIVISIONS
PROBLEM-HANDLING
LOGGED-IT-PROBLEM
0
INFOMAN
SYSTEM
MONTHLY-STATISTICALREQUIREMENTSREPORT
IT MANAGEMENT
Figure 4.3.1 Context diagram for automated INFOMAN system
62
4.3.2
Client Server support Manual Processing
The second category of problem management is for the client server support
with manual processing. Problem management for client server support is divided into
2 types, which are as follows:
i.
Problems reported from Headquarters
ii.
Problem reported from Branches
The Helpdesk unit will handle the problems, which are reported from
Headquarters, whereas the problem reported from Branches is handled by the
Technical Support Unit at main branch. However, the Technical Support units have
to compile all problems either solved or unsolved into the Daily Problem Form and
email it to the Helpdesk unit for checking and verification. The Form must email by
end of the first week every month.
As mentioned in earlier chapter, all data or information from Technical and
Daily Technical Problem Form will be extracted and transcribed in the Microsoft
Words table format. The extraction of data and information from the INFOMAN
system also will be done manually by calculating the total of problem types for the
month.
The statistical report is prepared monthly by manipulating the calculated data
derives from both host application and client server based. See The reports will shows
both categories of problem that is the host application and the client server support.
Figure 4.3.2.2 illustrates the client server support manual processing.
63
NOTIFYSTATUS
FEEDBACK COMMENT
HEADQUARTES
BRANCHES
EMAIL-MONTHLYFORM
EMAIL-TECHNICALFORM
0
MANUAL
PROCESS
RECORD-UPDATE
MONTHLYSTATISTICAL-FORM
ESCALATERECORD
PROBLEMHANDLING
IT MANAGEMENT
UPDATE STATUS
HELPDESK
IT DIVISIONS
Figure 4.3.2.2 Client server support manual processing
4.3.3
Data Flow Diagram
This section illustrates the data flow diagram (DFD) for the automated
INFOMAN system. The DFD illustrated is showing the processing of problem
management system in current system.
Following is the DFD sequence of the system:
i.
Figure 4.3.3.1 shows the overview DFD for INFOMAN system
64
ii.
Figure 4.3.3.2 shows the DFD for INFOMAN system – problem
recording
iii.
Figure 4.3.3.3 shows the DFD for INFOMAN system – determine
status
iv.
Figure 4.3.3.4 shows the DFD for the INFOMAN system – problem
status
4.3.3.1 The Overview DFD
The overview DFD shown below is the current legacy system in used. The
system comprises 3 functions:i.
Record recording is the initial processing of the problem management.
ii.
Determine status is to check the status of the problem management
record and update the solution.
iii.
Problem status is to extract the current problem management record
and update the status for monthly requirement report.
Figure 4.3.3.1 shows the overview DFD for INFOMAN system.
65
PROBLEMSREPORTED
CHECK-STATUS-PROLEM
1
PROBLEM RECORDING
CREATE-NEWRECORD
2
UPDATE-SOLUTION
DETERMINE STATUS
DETAIL-PROBLEM
EXTRACT-CURRENTPROBLEM
A
B
HISTORY-REC
PROBLEM -REC
3
UPDATE-STATUS
PROBLEM STATUS
MONTHLYREQUIREMENTS-REPORT
Figure 4.3.3.1 An overview DFD for INFOMAN system
4.3.3.2 DFD for INFOMAN – Problem Recording
This Problem-recording system comprises of 3 processes:i.
Record creation is the initial processing of the problem management.
ii.
Check problem types is the process of identifying the problem types
based on the selection given.
iii.
Check assignee is to identify and verify the assignee of the problem is
the correct channel.
Figure 4.3.3.2 shows the DFD for INFOMAN system- Problem recording.
66
PROBLEMSREPORTED
1.1
IDENTIFY-PROBLEM-TYPE
PROBLEMRECORDING
1.2
CREATE-NEWRECORD
IDENTIFY-ASSIGNEE
CHECKPROBLEM-TYPE
1.3
A
PROBLEM -REC
CHECKASSIGNEE
UPDATE-STATUS
Figure 4.3.3.2 The DFD for INFOMAN system – Problem Recording
4.3.3.3 DFD for INFOMAN system – Determine Status
This Determine-status system comprises 3 main processes:i.
Check the problem status is to check the status of the problem record
and the solution.
ii.
Check the solution is to determine the problem either it is solved with
temporary or permanent solution. The status is then updated to the
problem record.
iii.
Status update is to verify the status of the problem.
Figure 4.3.3.3 shows the DFD for INFOMAN system – Determine status.
67
CHECK-STATUSPROBLEM
2.1
DETERMINE-SOLUTION
CHECK-STATUSPROBLEM
2.2
UPDATE-SOLUTION
CHECKSOLUTION
DETERMINE-STATUSPROBLEM
A
PROBLEM -REC
ARCHIVE-CLOSEDPROBLEM
2.3
STATUS UPDATE
B
HISTORY-REC
Figure 4.3.3.3 The DFD for INFOMAN system – Determine Status
4.3.3.4 DFD for INFOMAN system – Problem Status
The Problem-status system comprises 2 main processes:i.
Check current month is to determine the problem record for the
current month.
ii.
Check status is to check and verify the status of the current month
which is not closed. This is for the purpose of reporting.
Figure 4.3.3.4 shows the DFD for INFOMAN system -Problem status.
68
B
HISTORY-REC
EXTRACT-CURRENTPROBLEM
3.1
CHECKCURRENTMONTH
DETERMINE-CURRENTSTATUS
3.2
MONTHLYREQUIREMENTS-REPORT
UPDATE-STATUS
CHECK-STATUS
A
PROBLEM -REC
Figure 4.3.3.4 The DFD for INFOMAN system – Problem Status
4.3.4
Entity-Relationship Diagram
The entity-relationship diagram (ERD) is to show the relationships between
entities. The ERD for both categories of processes are as follows:
a.
Entity-Relationship Diagram for Host Application Support using the
Legacy System Each of problems reported is registered and assigned to a unique or one
problem record. The registered problem will creates one history record.
Each problem record will updates the status in history record.
Figure 4.3.4.1 illustrates the ERD for host application support.
69
REGISTEREDPROBLEM
1
assigns
1
1
PROBLEM-REC
1
creates
updates
1
HISTORY-REC
1
Figure 4.3.4.1 The ERD for Host Application Support
b.
Entity-Relationship Diagram for Client Server Manual Processing All problems reported from Headquarters are summarized to one
summary format. The problems which were reported to branches are
also summarized to one summary format.
Figure 4.3.4.2 illustrates the ERD for client server manual processing.
70
M
HQ-DETAIL
summarizes to
1
SUMMARY-FORMAT
1
summarizes to
BRANCH-DETAL
M
Figure 4.3.4.2 The ERD for Client Server Manual Processing
4.3.5
SWOT Analysis
The analysis of the as-is process in BSN comprises of SWOT Analysis on the
implementation of current problem management process. The analysis is conducted
based on the legacy system that is used and the manual processing of handling the
problem management.
The strengths of the as-is process is dependent on the legacy system which is
an automated system used as a tool to implement the problem management handling.
On the other hand, the legacy system also portrays weaknesses. Whereby there is no
expertise within the IT personnel to maintain the system. This system is maintained
by IBM, and only utilized the existing functions provided by the system. In addition,
71
the system also does not provide any standardization to key in the description of
solution. Table 4.3.5 summarize the SWOT analysis done on the as-is process.
Strengths
Weaknesses
Is an online system which can There is no expertise within the IT
perform record creation and updating departments (internally) to maintain
directly.
the system. Therefore, only utilized
the existing functions provided by the
system without any enhancement.
Is used as an automated tool to No standardization format to key in
implement
problem
management the description of solution for the
process.
problem.
Expedite the process of problem The delay in management reporting
management to the right problem due to manual processing.
owner.
Captured historical data or record for
future references.
Opportunities
Threats
Immediate action taken as the system High cost to maintain the system due
is
used
for
escalation
to
the to the involvement of the vendor
appropriate problem, application or
system owner
Quick
retrieval
of
record
for Restriction or limitation to enhance
reverences
the system for better improvement in
problem management process
Problems are centrally control by the
Problem Coordinator for problem
tracking and monitoring.
Table 4.3.5 SWOT analysis for the as-is process
72
4.4
User Requirements
The system developed is used for the handling of problem management
process. In which the main user of the system is the Helpdesk unit. The system is also
intentionally for the user from main branches that is the Technical Support unit.
However, the users of this system are categorized according to the grouping and
functionality.
The categorization of users into grouping and functionality is to provide
comfortability and ease of use when operating the system. Table 4.4.1 shows the list
of users grouping.
No
Users
Descriptions
Grouping
1
Headquarters
Technical Support group in Headquarters.
2
Branches
Technical Support unit at state main branch.
3
Management
Management group from Jabatan Teknologi Maklumat
4
Helpdesk
Problem Controllor from Helpdesk Unit (PSP). Also act as
System Administrator.
5
Assignee
Problem Owner / System Owner / Application Owner
Table 4.4.1 Users Grouping
The user requirements of the system are:
i.
Able to integrate the 2 categories of problem management that are
host application and client server.
ii.
Able to log and record all types of problem
iii.
Able to delete record when wrong creation
iv.
Able to track the problem record
73
v.
Able to monitor the status of the record
vi.
Able to differentiate the problems based on problem types. For
example problems related to network, hardware, software, system and
application.
vii.
Able to prioritize the problems based on severity codes.
viii.
Able to group or differentiates problem reported from Headquarters
and Branches
ix.
Able to generate summary problems based on categories
x.
To view the record logged based on status and priority
xi.
To update the status of the problem
Generally, the user requirements from each grouping varied based on functionality.
Table 4.4.2 shows the summarize user requirement for each grouping,
74
No
Users
User Requirements
Grouping
1
Headquarters
i
Able to log and record all types of problem.
Branches
ii
Able to delete when wrong creation.
iii
Able to differentiate the problems based on problem
types.
iv
Able to differentiate problems reported from HQ and
Branches.
2
Management
i
Able to provide statistical data on number of problems
reported from every branches and HQ.
ii
Able to provide statistical and analysis data on number
of problems solved, pending and closed within a month.
3
Helpdesk
i
Able to integrate the 2 categories of problem
management (Host & Client Server).
ii
Able to track problem record based on status.
iii
Able to prioritize the problems based on severity levels
defined.
4
Assignee
i
To view record logged based on problem status and
types.
ii
To update the status and solutions of the problem upon
rectified.
Table 4.4.2 Summarize User Requirement for Each Grouping
75
4.5
New Business Process and Data Model
This section is describing the new process of the problem management system.
The main function of this system is to automate the problem management life cycle
and also to integrate the 2 categories of problem management. Automating problem
management process is important because it gives a systematic and structured process,
also as a record keeping the resolve problem or issues that are arise.
From the literature reviews done, it is found out that there is best practices
framework to adopt in the problem management process. As of the results, this system
is adopting the best practices framework and also referring to the trend of similar
solutions by vendors and the researcher’s paper.
This new system design is applying the ITIL best practices framework and
also adopting the previous researcher’s paper as a guideline to build the system. The
features that this new system adopting from the previous researcher’s paper is:i.
The system is a web-based which can control the flow of problem
management processes from inputting the problem report until the
resolution of problem
ii.
The system can show the progress of each problem that registered in
the system in real time
iii.
The system also capturing the data or information from various
location in one database
iv.
The system gives variety selection of views to display the problem
information
v.
The system send problem information or data for spreadsheet
application to generate or creating graphs
vi.
The system provides authorization login only to the authorized user
operation such as recording, assigning and controlling the problem
record.
76
This section is divided into few sub sections explaining in detail on the
approach taken in the system processing, the designing of the new system process and
also the database designing.
4.5.1
System Approach
The development of this system is based on the concept of online processing
and the batch online update processing. The online processing is referring to the Webbased application for handling or operating the system. On the other hand, the batch
online update processing is referring to the submission of batch script to do a mass
processing.
The browsing of this system through the BSN web sites requires the user to be
authenticated against the User ID table defined in the system. This is to ensure that
only authorized user is allowed to login the system.
The batch online update is the batch job which is schedule to run or execute
monthly for the purpose of generating the statistical data and also to perform the
housekeeping on the current records. The batch online update processing consists of 2
methods as follows:
i.
Using the SQL commands to execute the batch processing
ii.
Exporting and importing data to generate graph for the statistical data
produced.
77
4.5.2
System Process
Besides integrating the 2 categories of process (the legacy and manual
processing), the system is structuring according to the users’ requirements and the
problem management life cycle or process compliance. The system structuring assists
the Helpdesk Unit to simplified function of monitoring, escalating and controlling the
problem management process. Following is the problem management process that
being handled by the Helpdesk Unit:i.
Monitoring
To ensure that all problem are well defined and the detail description
are documented in the system. The Helpdesk unit will periodically
check on the status of the problem.
ii.
Escalating
The Helpdesk Unit will identify the root cause of problem and problem
owner. Based on the directory list of problem owner built in the
system, the Helpdesk Unit will assign the problem owner and escalate
the problem to the respective owner.
iii.
Controlling
This is to ensure that all problems will be taken action within the
agreed service level defined.
4.5.3
System Functions
The system will support the following functions:
a.
Problem Recording
78
Problems or incidents will be logged and registered in the system with
a problem number. Problems may be reported through e-mail,
telephone or from the computer operator. Types of problems logged
into the system are:i. Applications failure in production environment
ii. Interruption to computer services
iii. Technical error to the hardware
iv. Network failure or interruption
v. Complaint from users on the IT services
b.
Problem Classification
Problem classification is the process to identify the problems types. All
problems logged in the system will be classified into 7 categories as
follows:i. Hardware – any technical error such as malfunction of tape drives.
ii. Software – for example errors in back-up using VTS (virtual tape
system)
iii. Network – for example communication lines down
iv. Application – failure to the system such as in the batch run
v. Information – any incident logged without any further actions.
Only for notification.
vi. Environment – failure either in production, disaster or test
environment
vii. Documentation – any guidelines, policies or procedure that need to
improve or review.
c.
Problem Prioritize
Problems registered will be prioritizing according to the problem
severity level. The severity level shows the criticality of the failure or
interruptions. In addition, severity levels also help to ensure that action
is taken immediately to resolve. The severity levels are as follows:
i.
High
-
high risk problem
ii.
Medium
-
critical problem
iii.
Low
-
normal problem
79
d.
Problem Cause or Diagnosis
Problem cause or diagnosis is the process of documenting the cause of
problem and updating the resolution information. This process is
essential because it can be used as a references and a historical record.
e.
Problem Ownership
Problem ownership is the process of assigning the problem to the
problem owner, application owner or system owner. Once the problem
is registered and categorized accordingly, the problem record will be
assigned to the owner for corrective or further action. The owner is
responsible to update the status of the problem.
f.
Problem Status
Problem status is to determine the status of the problem. The status of
problem is categorized as follows:i. Assigned – this indicate an active record problem and need to take
action
ii. Fixed – the problem is rectified
iii. Closed – the status will be change to closed once problem had
fixed with solution and put in archived
iv. Pending / KIV – the problem is not solved or probably is link to
another exercise and the priority is low
4.5.4
Context Diagram of ITPMS
This section illustrates the context diagram for the new process in the problem
management process. The new process is the integration of the 2 categories that is the
automated and the manual process.
80
The scenarios for new process are as below:
i.
All problems from Headquarters are reported and logged in the ITPMS
system with a problem number assigned uniquely to each record.
ii.
The problems are classified and prioritize based on the directory list
provided by the system.
iii.
All record will be furnished with detail description of problem and
escalate to the problem owner for further action.
iv.
Problems at branches also will be logged and assigned problem
number. The Technical Support Unit at branches will take action and
update the status of problem in the system.
v.
The system also will provide views for Branches and Headquarters to
review and checking the status of problem.
vi.
All problems recorded need to be assigned to the Assignee, i.e.
Problem Owner / System Owner / Application Owner for further
action.
The Assignee is responsible to update the solution of the
problems in detail.
vii.
The statistical data or information will be produced and can be view
online.
viii.
All problems which relates to Host Application will also logged in this
system. The logging of host application problems are done by the
Helpdesk Unit and the users from IT department at Headquarters.
Figure 4.5.4 illustrates the context diagram for new process: ITPMS which is showing
the two environments of processes that is the web-based and archiving.
81
Archiving & Reporting
Processing
Web based System
RECORDMONITOR
BRANCHPROBLEM-LOG
HELPDESK
BRANCHES
BRANCHPROBLEMVIEW
PROBLEM HANDLING
0
ADMINISTRATOR
ITPMS
BATCH SCRIPT /
IMPORT&EXPORT
HQ-PROBLEMREPORT
VIEW SUMMARY
REPORT
IT MANAGEMENT
PROVIDE
INFORMATION
HQPROBLEMVIEW
HEADQUARTERS
Figure 4.5.4 Context diagram for to-be process: ITPMS - showing the two
environments (web-based and archiving)
4.5.5 Data Flow Diagram ITPMS
This section illustrates the data flow diagram (DFD) for the new process
system. Following is the DFD sequence of the system:
i.
Figure 4.5.5.1 shows the overview DFD for ITPMS
ii.
Figure 4.5.5.2 shows the DFD diagram 1 for process problem
recording
iii.
Figure 4.5.5.3 shows the DFD diagram 1 for process problem
determination
82
iv.
Figure 4.5.5.4 shows the DFD diagram 1 for process problem status
verification
v.
Figure 4.5.5.5 shows the DFD diagram 1 for process record formatting
vi.
Figure 4.5.5.6 shows the DFD diagram 1 for process archiving and
reporting.
4.5.5.1 The Overview DFD
The overview DFD shown below is the to-be process of the new system. The
system comprises 4 functions:i.
Record recording is the initial processing of the problem management.
ii.
Problem determination is to identify the problem classification and to
prioritize the problem. In addition, it also identifies the assignee and
the status of the problem.
iii.
Verify status is to identify the cause and diagnosis of the problem
together with the problem solution.
iv.
Produce report is to generate report for users viewing and the
summary report for management.
Figure 4.5.5.1 shows the overview DFD for ITPMS.
83
AUTHORIZED
USER LOGIN
A
USERID -REC
VALIDATING ID
PROBLEM
REPORTiING
1
PROBLEM
RECORDING
STATUS
IDENTIFICATION
2
PROBLEMDETERMINATION
PROBLEM
IDENTIFICATION
UPDATING SOLUTION
NEW
RECORD
CREATION
3
VERIFY-STATUS
B
PROBLEM -REC
UPDATING STATUS
4
RECORD FORMATTING
PRODUCEREPORT
PRODUCING BRANCH LIST
C
ARCHIVING & REPORTING
PROCESSING
CONFIRMING BRANCH
LIST
PRODUCING
LOCATION-REC
PROJECT LIST
5
Archiving &
Reporting
CONFIRMING PROJECT
LIST
D
PROJECT-REC
Figure 4.5.5.1 The overview DFD for ITPMS
4.5.5.2 DFD Diagram 1 for Process Problem Recording
The level 1 comprises 4 main processes:i.
Record recording
All problems will be logged and register in system with a problem
record number assigned automatically.
ii.
Check category
84
To identify the problem categories based on the list of categories
provided by the system.
iii.
Problem details
To specified detail description of problem.
iv.
Validate entry
Perform validation and verification on input entered of key-in the
system.
Refer figure 4.5.5.2 for further illustration on the DFD diagram process for
problem recording.
1.1
DETAIL PROBLEM RECORDING
CHECKCATEGORY
1.2
PROBLEMDETAILS
1.3
ENTRIES VERIFICATION
VALIDATEENTRY
CONFIRMING RECORD CREATION
CREATE-NEW-REC
B
PROBLEM -REC
Figure 4.5.5.2 The DFD diagram 1 for Process Problem Recording
85
4.5.5.3 DFD Diagram 1 Process Problem Determination
The level 2 comprises 4 main processes:i.
Check types
To identify problem types based on the list of problem types provided
by the system.
ii.
Check assignee
To identify the assignee (problem owner) for problem resolution by
selecting from the list provided.
iii.
Check severity
To prioritize and setting the severity types based on the list provided
by system.
iv.
Produce summary
To summarized all recorded problem for reporting purposes.
Refer figure 4.5.5.3 for further illustration on DFD diagram 1 for process problem
determination.
2.1
STATUS IDENTIFICATION
CHECKSEVERITY
2.2
CHECK-STATUS
ASSIGNEE
DETERMINATION
2.3
RECORD UPDATING
B
CHECKASSIGNEE
PROBLEM -REC
2.4
DETAIL EXTRACTION
PRODUCESUMMARY
Figure 4.5.5.3 DFD diagram 1 for Process Problem Determination
86
4.5.5.4 DFD Diagram 1 for Process Problem Status Verification
Figure 4.5.5.4 shows the DFD diagram 1 for process problem status
verification. The level 3 comprises 5 main processing:i.
Check status
To identify the status of problem based on status categories specified
by system.
ii.
Check solution
To check the documenting of resolution for the problem created.
iii.
Problem unsolved
Problem which is unsolved will be follow up and tag with unresolved
indicator if it exceeds the service level agreement.
iv.
Problem solved
To ensure all rectify problems are documented in detail and complete
solution.
v.
Problem close
All rectified problems with complete solution will be closed and put
into archive.
3.1
SOLUTION IDENTIFICATION
CHECK-STATUS
3.2
PROCESS-UNSOLVED
CHECKSOLUTION
3.3
3.4
PROBLEMUNSOLVED
PROBLEMSOLVED
STATUS
RETAINING
STATUS
UPDATING
FIXED
B
SOLUTION
VERIFICATION
PROBLEM-REC
3.5
STATUS UPDATING
CLOSED
PROBLEMCLOSE
Figure 4.5.5.4 DFD diagram 1 for Process Problem Status Verification
87
4.5.5.5 DFD Diagram 1 for Record Formatting
The level 4 comprises 3 main processing:i.
Format information
To summarized and format record for reporting.
ii.
Produce detail
Generates detail report.
iii.
Produce summary
Generate summary data or information for reporting.
Refer figure 4.5.5.5 for further illustration on the DFD diagram 1 for record
formatting.
CURRENT PROBLEM
ACCESSING
B
PROBLEM -REC
4.1
DETAIL FORMATTING
FORMATINFORMATION
4.2
DETAIL LIST
SUMMARIZATION
PRODUCEDETAIL
4.3
PRODUCESUMMARY
Figure 4.5.5.5 DFD diagram 1 for Process Record Formatting
88
4.5.5.6 DFD Diagram 1 for Process Archiving And Reporting
The level 5 is the archiving and reporting processing. This processing is to
generate the statistical data and to populate the current previous month problem
record into the archive table.
The problem record tables which contain the consolidation problem data of
client server and host application are extracted for archiving and reporting purposes.
B
PROBLEM -REC
RECORD EXTRACTION
5.1
DATA FOMATTING
DELETE AFTER
EXTRACTION
EXTRACT DATA
5.2
UPDATE
RECORD
BRANCH DATA
STATUS DATA
5.3
DELETE
RECORD
F
MONTHLY-REC
ARCHIVING
PROBLEM
RECORD
E
ARCHIVE-REC
MONTHLY
FORMATTING
G
QUARTERLY-REC
ARCHIVE
FORMATTING
QUARTERLY
FORMATTING
5.4
FORMAT
REPORT
Figure 4.5.5.6 DFD diagram 1 for Process Archiving and Reporting
89
4.5.6
Entity-Relationship Diagram
The entity-relationship diagram (ERD) is to show the relationships which are
the associations between entities.
The problem record (current table Probmgttb) is created by users either form
Headquarters or Branches. Each user can create many problem records depending on
the reported problems. The current problem records will be populated monthly into
the problem history table (Probhisttb) for archiving. The monthly data from table
Msummarytb is generated from the current problem record (Probmgttb) based on the
problem status. Table Qsummrytb is generated from the Probmgttb based on the
number of problems reported in HQ and Branches. Then, the populated record from
the current table (Probmgttb) will be deleted. This section is to illustrate the ERD
diagram for ITPMS.
LOCATIONTB
-Location_cd (FK)
M -Userid
PROBHISTTB
1
ADMINTB
-Userid_name (FK)
1
-Prob_number (FK)
- Userid
USERIDNMTB
1
1
-Userid_name (FK)
1
MSUMMARYTB
1
1
1
PROBMGTTB
M -Prob_number (FK)
- Userid
- Loc_cd
-Location_id (FK)
M
M
PROJECTTB
M
-Userid (FK)
QSUMMRYTB
1
-Location_cd (FK)
Figure 4.5.6 ERD diagram for ITPMS
90
4.5.7
System Architecture
The section is describing the system architecture and the system requirement
of the project.
The ITPMS system is a Web-based application that is accessible from the
client at the Headquarters and Technical Support Unit at Branches. The system is in
client server two-tier designs. In this two-tier design, the user interface resides on the
client, all data and application resides on the server.
The client connection at Headquarters is by joining all clients PC into local
area network (LAN). On the other hand, the branches connection to the server is by
the wide area network (WAN).
Basically the client will handle user interface, send data request to server and
receives data files from server. Meanwhile the server will receives data request from
client and send data files to client. The server also wills stores data file and manages
multi-user access. Figure 4.5.7 exhibits the system architecture for ITPMS
Server
LAN
WAN
Branch A
Client A
Branch C
Branch B
Client B
Client C
91
Figure 4.5.7 The system architecture for ITPMS
4.5.7.1 System Requirements
In order to overcome the handling of problem management process, an IS/IT
solution has to be introduced. The solution identified is to develop the problem
management system. Therefore, the requirement of software and hardware is very
essential for the success development of the system. Table 4.5.7.1 shows the proposed
hardware and software requirements for the system.
Client
Server
Microsoft XP
Microsoft Visual.Net
Prefessional
Microsoft Internet
Microsoft Visual.Net
Microsoft IIS server
Microsoft ASP.Net
Microsoft Internet
Microsoft Internet
Explorer 5.5
Database
Microsoft Access 2003
Microsoft IIS server
Microsoft Internet
Explorer 5.5
Systems:
Systems:
CPU: Intel Pentium 4
CPU: Intel Pentium 4
processor
processor
Hardisk :20 GB
Hardisk :40 GB
RAM: 256 MB
RAM: 512 MB
Table 4.5.7.1 The proposed hardware and software requirements for the system
92
4.7
Physical Design
This section is explaining the physical detail design of the system. The focus
of the physical design is delivering the detail database design, the module structure
chart and site maps. The detail description of the modules involved is also explain in
this section.
4.7.1
Database Design
The section is describing the detail design of the table definition used by the
system. Refer appendix D for further definition on each tables. The tables defined are
as follows:i
Problem record table
- PROBMGTTB
Purpose: this table is capturing all the problem details that register into
the system. This table is also known as a current problem record table.
Table 4.7.1.1 shows the data definition of Probmgttb.
ii
History record table
- PROBHISTTB
Purpose: this table contains all the problem record which has been
rectified or solved and closed. In addition, this table is also known as
an archived table for problem records. This table is an image of the
Progmgttb. The data definition of this table is the same as the
Probmgttb. Table 4.7.1.2 shows the data definition of Probhisttb.
iii
Location branch table
- LOCATIONTB
Purpose: this table is storing all the branches name and address.
Table 4.7.1.3 shows the data definition of Locationtb.
93
iv
User ID table
- USERIDNMTB
Purpose: this table is to store all the user id of the system. The input
user id will be validated against the defined user id in the table.
Table 4.7.1.4 shows the data definition of Useridnmtb.
v.
Administrator ID table
- ADMINTB
Purpose: this table is to store the administrator user id.
Table 4.7.1.5 shows the data definition of Admintb.
vi
IT project table
- PROJECTTB
Purpose: this table is keeping the record of IT projects handled by
JTM. Table 4.7.1.6 shows the data definition of Projecttb.
vii
Monthly report table
- MSUMMARYTB
Purpose: this table keeps the summarized data on problem record based
on status for the monthly reporting.
Table 4.7.1.7 shows the data definition of Msummarytb.
viii
Quarterly report table
- QSUMMRYTB
Purpose: this table keeps the summarized data on problem record
registered at branches and HQ for the quarterly reporting.
Table 4.7.1.8 shows the data definition of Qsummrytb.
4.7.2
Structure Chart
The ITPMS system consists of 2 mains pages or menus to login the system
which are as follows:
i.
User Login
- the defined group of users to use this system.
94
ii.
Administrator Login - the Problem Controller that handles the
administrative functions of the system.
4.7.2.1 User Login
a.
Structure Chart
The user login page is designed for the used of defined group of users to
register new problems, update the problems requirement and also viewing the
problems record status. Figure 4.7.2.1.1 shows the user login structure chart main
module.
USER LOGIN
Problem
Location
Problem
Rectification
Problem
Tracking
Highlights
Summary
Reports
Headquarters
Assignee
Detail Current
Problem
Branches List
Monthly
Summarized
Archived
Problems
IT Projects
List
Quarterly
Summarized
Branches
Figure 4.7.2.1 The user login structure chart main module
User login consists of 5 main modules which are as follows:i.
Problem Location – this module is used for problem recording or
registering from Headquarters and branches. The users from
Headquarters will record problems that relate to client server and host
95
application. On the other hand, users from branches are to record
problems that relate to client server.
ii.
Problem Rectification – the problem rectification module is used by
the Problem Owner or System/Application Owner to update the status
and resolutions of the problem.
iii.
Problem Tracking – this module is to track detail status of problem
records based on current and archived problems. The tracking of
problems is divided into states branch and Headquarters.
iv.
Highlights – this module is to supply information about branches and
IT projects that involves the IT department.
v.
Summary Reports – the main focus of this module is to give statistical
report to the IT management. The module provides 2 types of report
that is the monthly and quarterly reports.
b.
Site Maps
The site maps is showing the detail connection or linking of every modules
defined. Following is the list of figures that illustrate the linking of each main
module:i.
Figure 4.7.2.1.2 Site maps on Problem Location and Problem
Rectification
ii.
Figure 4.7.2.1.3 Site maps for Problem Tracking and Highlights
iii.
Figure 4.7.2.1.4 Site maps for Monthly summarized and Quarterly
Summarized.
The problem location consist 2 sub modules which differentiates two types of
users, which is from Headquarters and State Branches. All users are allowed creating
new problem records, viewing detail problem records and also tagging the problem
96
record for deletion. The reason for tagging problem record is because the system will
not allow normal users to physically delete the problem records. Only administrator is
allowed to delete the physical records.
The viewing and tagging of problem records at branches are divided into states
level. This is to enables easy management and handling of states problem records.
The sub module for problem rectification is the assignee which is meant for
the Problem Owner or System Owner or Application Owner. The assignee is
responsible to give the solution of the problem which is recorded and assigned.
Mainpage
Homepage
(User login)
A
Problem Location
Headquarters
Register
new
Display
current
Tagging
record
Problem Rectification
Branches
Register
new
Display
current
Kedah
P.P
Perak
Selangor
K.Lumpur
N. Sembilan
Melaka
Johor
Pahang
Terengganu
Kelantan
Sarawak
Sabah
Assignee
Tagging
record
View Record
Update
Solutions
Kedah
P.P
Perak
Selangor
K.Lumpur
N. Sembilan
Melaka
Johor
Pahang
Terengganu
Kelantan
Sarawak
Sabah
Figure 4.7.2.1.2 Site maps on Problem Location and Problem Rectification
97
The problem tracking module contains 2 sub modules which are current
problem and archived problem. Each sub modules is divided into states and
headquarters level for easy and fast viewing and tracking of problems record.
The highlights module also contains of 2 sub modules which is the branch list
and IT project list. The branch list is to provide information on each branch in every
state whereas the IT projects list is to provide information on any IT projects that
involves the IT departments.
Mainpage
Homepage
(User login)
A
B
Problem Tracking
Current Problem
Kedah
P.P
Perak
Selangor
K.Lumpur
N. Sembilan
Melaka
Johor
Pahang
Terengganu
Kelantan
Sarawak
Sabah
Headquarters
Highlights
Archived Problem
Kedah
P.P
Perak
Selangor
K.Lumpur
N. Sembilan
Melaka
Johor
Pahang
Terengganu
Kelantan
Sarawak
Sabah
Headquarters
Branches List
IT Project List
Kedah
P.P
Perak
Selangor
K.Lumpur
N. Sembilan
Melaka
Johor
Pahang
Terengganu
Kelantan
Sarawak
Sabah
Figure 4.7.2.1.3 Site maps for Problem Tracking and Highlights
98
The summary reports module contain 2 sub modules which to produce
monthly and quarterly summarized report. The monthly summarized report is to
provide statistical data on number of problems reported and assigned to the IT
department. From this report, the management can evaluate the performance of the IT
department based on total number of problems reported, solved or rectified and also
any pending problems which is no actions taken. The monthly summarized reports
can be view online based on the month occurred.
The quarterly summarized report which is produced every 3 months is to
provide analysis on the total number of problems reported to every states and
headquarters. From this report, the management can sees and analyze the trend of
problems reported at each locations. Comparisons among each location can be made
to sees which location is having the most problems and needs special attention to
tackle or overcome the problems.
Refer appendix E for list of sample report
produced.
Mainpage
Homepage
(User login)
B
Summary Reports
Monthly Summarized
January
February
March
April
May
Jun
July
August
September
October
November
December
Quarterly Summarized
First Quarter
Second Quarter
Third Quarter
Fourth Quarter
99
Figure 4.7.2.1.4 The site maps of the user login page
4.7.2.2 Administrator Login
The administrator login page is designed for the used of Problem Controller to
create or define the new user id, location, projects and problem record. In addition, the
administrator is also responsible to execute the SQL query for archiving and reporting
a.
Structure Chart
The administrator login page contains 4 main modules. Each module is to
perform the creation of new record, view record and delete the physical record.
Figure 4.7.2.2.1 shows the administrator login structure chart main module.
ADMINISTRATOR
LOGIN
User ID
Location
IT Projects
Create New
Create New
Create New
View Record
View Record
View Record
Delete
Record
Delete
Record
Delete
Record
Figure 4.7.2.2.1 The structure chart for the administrator page
100
a.
Site Maps
This module is to perform the group or mass processing using the SQL query
to produce the reports. Figure 4.7.2.2.2 shows the site maps of archiving and reporting
process to produced monthly and quarterly reports.
Archiving & Reporting
Processing
Probmgttb
Probhisttb
Extract data
Insert record
Msummarytb
Update record
Qsummrytb
Update record
Delete record
Figure 4.7.2.2.2 The site maps of archiving and reporting process
4.7.4
ITPMS Modules
The ITPMS with two main pages or menus to login the system consist of
several modules, which are designed to fulfill the different requirement levels of
users.
All modules designed in this system are complying with the system functions
as discussed earlier in section 4.5.5 System Functions.
101
4.8
Hardware and Software Requirements
Basically the development of ITPMS system requires two types of elements,
which are hardware and software.
4.8.1
Hardware Specifications
The hardware specification used by the developer in developing the ITPMS
system is:
4.8.2
iv.
Personal Computer with Pentium 4 processor
v.
Hard disk with 20 GB
vi.
Memory 512 MB ram
Software Specifications
Initially the proposed software for the development of the systems was from
the Microsoft product. Refer to section 4.5.7.1 System Requirements for the detail
proposed software. However, due to the fact that the Microsoft product is proprietary
and licensed software, there is a cost involved in using this software. There is no
allocation of budget in buying the required software.
102
As for other alternative, the developer found another option or alternative of
software for the development of the system. Following is the detail description of the
software specification used to develop the ITPMS:
i.
PHP is an open source application technology which can be
downloaded freely from the internet. The version of PHP used in
this system is PHP 5.
ii.
MySQL is an open source relational database management system.
MySQL has long been the database solution to use with dynamic
PHP web sites. The version use is MySQL 4.
iii.
Dreamweaver MX 2004 is a web design and development tool.
iv.
Apache is the open source web server to serve PHP and MySQL
web sites.
v.
Microsoft Internet Explorer 4.0 is the suitable browser to view the
ITPMS system.
4.9
Summary
In order to develop the good system, there is a need to study in detail the
existing process in the organization. In addition, the organizational analysis also need
to be carry out to give better and clear understanding of the requirement for the new
system.
103
CHAPTER 5
IMPLEMENTATION AND TESTING
5.1
Introduction
This part of chapter is about the implementation and testing of the system.
The chapter providing snapshoot of the main pages or menu that contains in the
system. In which this snapshoot is the main module of the system.
As for the correctness of the system and it functioning correctly, the system is
tested toughly. This chapter provides the test results of the testing that had been
conducted
In addition, the chapter also provides the user manual for administrator to
operate the system. The user manual to help and guide the users in using the system
can be referred to in Appendix F.
104
The policy of problem management is provided to the user as a guidelines and
terms of declaration when using the system. Refer to in Appendix G for the draft
policy of problem management.
5.2
Implementation
The implementation activity is carried out after the designing stage. In which
the implementation activities involves are the system coding, system compiling and
testing.
The main module component in the ITPMS system:-
5.2.1
i.
Main menu
ii.
Problem Location
iii.
Problem Rectification
iv.
Problem Tracking
v.
Highlights
vi.
Summary Reports
Main Menu
This is the main page of the ITPMS system. It provides the list of other
modules with hyperlinks to choose from. From here, users can get to other modules
just by clicking the button provided. Figure 5.2.1.1 and 5.2.1.2 shows the main menu
of ITPMS.
105
Figure 5.2.1.1 : Main Menu of ITPMS (upper)
106
Figure 5.2.1.2 : Main menu of ITPMS (lower)
5.2.2
Problem Location
Problem location is the module which categorized users from the Headquarters
and Branches to record new problems. The categorization of users is to provide
easiness and system friendly when operating the system. Figure 5.2.2.1 and 5.2.2.2
shows the menu of the users from Headquarters and Branches.
107
Figure 5.2.2.1 : Headquarters Main Page
108
Figure 5.2.2.2 : Branches Main Page
5.2.3 Problem Rectification
This module is for the usage of the assignee. The assignees of the problems
are referred to the System Owner / Application Owner and Problem Owner. The
main function of this module is to update the status of problem after it has been
rectified by the assignee. The function for updating the status and viewing detail
record can be access by clicking the hyperlinks button or option provided. Figure
5.2.3 shows the related menu.
109
Figure 5.2.3 Problem Rectification (Assignee)
5.2.4
Problem Tracking
The problem tracking is to view the problem record which is sorted by
problem status, problem priority and problem owner. The tracking of problems record
is performing separately in each branch. Each branch can track the current problem
record and also the archived problem record. Furthermore, the problem tracking also
gives option to other hyperlinks such as for updating the problem records. Figure
5.2.4 shows the main page of the problem tracking.
110
Figure 5.2.4: Problem Tracking (Current Problem)
5.2.5 Highlights
The main function of the Highlights module is to give information on the
branches in BSN and also the IT projects that relate to the Jabatan Teknologi
Maklumat (JTM). The viewing of branches in Highlights is sorted by state main
branch. Figure 5.2.5.1 shows the list of branches and figure 5.2.5.2 shows the list of
IT projects.
111
Figure 5.2.5.1 : List of Branches (Highlights)
Figure 5.2.5.2 : List of IT Projects (Highlights)
112
5.2.6
Summary Report
This module provides 2 types of report that is the monthly summarized data
and the quarterly summarized data. The monthly summarized data is focusing on the
total number of problems reported and handled by the IT department in JTM. The
data produced is based on the problem status, i.e. Assigned, Pending and Closed.
Figure 5.2.6.1 shows the monthly report main page or menu.
On the other hand, quarterly summarized data is to provide the analysis report
on the number of problems reported in every branch inclusive of Headquarters. All
data produced in the report can be compared clearly by viewing the graph provided.
Figure 5.2.6.2 shows the quarterly report main page or menu. Refer appendix H for
more example of detail report generated.
Figure 5.2.6.1 : Monthly Report Main Page
113
Figure 5.2.6.2 : Quarterly Report Main Page
5.3
Test Results.
Testing has been done on the ITPMS system to detect any problems or
malfunction of the system. The testing is an important element in order to ensure the
stability and correctness of the system. Hence, the users’ requirements also are
checked during the testing to ensure that the requirements are met.
There are a series of test that had been performed in order to checks and
knows the system capability, strength and weakness. The testing that had been done in
this system includes:
i.
Unit testing
ii.
Integration testing
114
iii.
System testing
All the testing is done separately on the user login and the administrator login.
This to ensure that the user login and administrator login is functioning well.
5.3.1
Unit Testing
The unit testing of this system is done during the development stage of every
module. Once the module completed, the unit testing is performed to identify and
eliminate any errors that could cause the module to terminate abnormally. The main
focus of this testing is to ensure that all modules developed should work out well and
functioning.
5.3.2
Integration Testing
This testing is done in phases that are upon the completion of main module
and its sub modules. The testing is to verify that each main and sub modules can
integrate each other.
5.3.3
System Testing
115
The final testing of this system is the system testing. The main objective of
this testing is to ensure and verify that all main modules and sub modules are
integrated properly and is working out fine. Refer to appendix I for tables that exhibit
the summarization results for user login and administrator login:
5.3.4
i.
Table
5.3.3.1 shows the summarization results for User Login
ii.
Table 5.3.3.2 shows the summarization results for Administrator Login
User Acceptance Test
The user acceptance test for this system is not performed because the system
produced is only a prototype. However there is a plan to perform the user acceptance
test in order to get certification and endorsement from the users once the system is
ready and complete.
The test plan for this system is divided into several grouping such as:
5.4
i.
User / Administrator login
ii.
Pages / screen linking or connectivity
iii.
Functions for Add, Update, Delete record
iv.
All pages / screen displaying correct information
v.
Populating of data after the archiving and reporting process
Administrator User Manual
116
There are two types of user manual provided to the administrator. The first
types of user manual referring to the online processing, whereas the second types is
referring to the archiving and reporting processing.
Following section in this chapter provides the procedures for administrator to
handle or operate the system.
5.4.1
Procedure: Setting Up The Environment
In order to get the system up and running, there is a need to install Apache
web server, PHP, MySQL database and the Dreamweaver MX 2004. The Apache
web server, PHP and MySQL can be downloaded from the internet. On the other
hand, the Dreamweaver MX 2004 can be downloaded from the trial version at the
Macromedia web site.
There are 2 options to select for downloading the source from internet. The
options are as follows:
a.
i.
download separately the software from the given site
ii.
download the installer packages which include all software
Download separately the software.
Following is the list of web site which is available for the downloading:
i.
PHP
-
www.php.net
ii.
MySQL
-
www.mysql.com
iii.
Apache
-
www.apache.org
iv.
Dreamweaver MX2004 trial -
www.macromedia.com
117
The steps that need to be taken when downloading the given sites are as
follows:
i.
Always get the latest version of the application, web server or database
that available in the web site.
ii.
Click ‘download’ to start the downloading process from the web site
into the computer.
iii.
In order to proceed downloading, click on ‘I Agree’ when the terms
and conditions of the License Agreement appears.
iv.
The rest of the installation process is depending on the selection of
option provided. Always click ‘Next’ to finish with the installation.
b.
Download the installer packages
There is another option to download the source from internet. This option of
downloading is to download the installer packages which include the Apache,
MySQL and PHP. The web site which available for downloading is
http://sourceforge.net.
Search for
WinLamp file list and choose to ‘download
WinLamp031 exe’. The WinLamp is an istaller for Apache, MySQL and PHP. It runs
on Windows XP and is a single executable file. Comes together with this package is
the installation of MySQL tool to administer the database.
The development of ITPMS system is by download and run the execution file
of WinLamps. Refer appendix J for the steps to be taken when execute the WinLamps
file for installation.
5.4.2
Procedure: Administrator Online Processing
118
There is a special login for the administrator where they can modify, edit,
update or delete any records from the database. The administrator login page eases the
administrator’s work since the information or data needs to be updated frequently.
Showing below are some of the figures to demonstrate the administrator login
functions. Refer appendix K for more snapshots on the administrator login.
To create new
password for first
time login
To change password
Enter the Administrator Id for
authentication against the id
defined in database.
Figure 5.4.2.1 : Administrator Login Page
119
Selection of table to perform
the functions
Figure 5.4.2.2 : Administrator Main Page
5.4.3
Procedure: Administrator Archiving And Reporting Processing
The purpose of administrator archiving and reporting processing is to perform
a mass and grouping processing on the database. The types of processing involves is
the accumulation of problem record based on status and every branch. The
accumulated figure is then updated accordingly into the monthly and quarterly table.
Other types of processing involves is to populate the previous month problem
record from current table into archived table. After the population of record into the
archive table, the affected records will be deleted from the current table.
120
The arching and reporting processing is schedule to be run monthly for the
extraction, updating and the deletion of record. The arching and reporting processing
is initiated by the submission of batch script using the SQL query. The sequence of
SQL script is as follows;
i.
To populate the previous month problem record into archive table.
ii.
The accumulation of problem record for particular month based on
problem status; i.e. Assigned, Pending and Closed.
iii.
The updating of accumulated problem record into the monthly table.
iv.
The accumulation of problem record based on state branch and
headquarters.
v.
The updating of accumulated records into the quarterly table.
vi.
The deletion of the extracted problem record from the current table.
The SQL script is run or executed via the MySQL Front. The MySQL Front is a tool
to manage the MySQL database. The MySQL tool is downloaded from the WinLamp
executable file. Refer appendix L for the steps to guide the execution of the SQL
script via MySQL-Front.
5.4.3.1 SQL Query
The SQL query script need to be submitted by administrator in order to
archive previous problem record and also to generate summarized report. The
submission of SQL script requires human intervention. This is because there is
a need to change or modify certain parameter in the SQL script before the
execution. Following is the lists of SQL query script that need to be executed
are:
i.
SQL query to accumulate number of problems reported with status
Assigned, Pending and Closed from table Probmgttb.
121
a.
Select Count(*) from probmgttb
Where status='assigned' and month_occur=1;
b.
select count(*) from probmgttb
where status='pending' and month_occur=1;
c.
select count(*) from probmgttb
where status='closed' and month_occur=1;
The variable month_occur need to change according to the month
problems recorded.
i.
SQL query to accumulate number of problem from every state from
table Probmgttb.
a.
select count(*) from probmgttb
where
branch='headquarters'
and
year_occur=2005
and
month_occur=1;
b.
select count(*) from probmgttb
where
branch='kedah'
and
year_occur=2005
and
month_occur=1;
Replace the variable for branch, year_occur and month_occur
appropriately based on the states and month the problems recorded.
ii.
SQL query to update the accumulated figure into the appropriate filed
in table Msummarytb.
a.
update msummarytb
set totl_assign_1=9, totl_pending_1=2, totl_close_1=2
where department_id='bpa';
b.
update msummarytb
122
set totl_assign_1=3, totl_pending_1=5, totl_close_1=4
where department_id='bot';
c.
update msummarytb
set totl_assign_1=12, totl_pending_1=5, totl_close_1=8
where department_id='bks';
d.
update msummarytb
set totl_assign_1=29, totl_pending_1=12, totl_close_1=42
where department_id='psp';
e.
select
department_id,
totl_assign_1,
totl_pending_1,
totl_close_1 from msummarytb;
Set the totl_assign_1 with the value generated from the accumulation
of problem based on status. Replace all field totl_assign_1,
totl_pending_1 and totl_close_1 accordingly based on the month of
problems reported.
iii.
SQL query to update the accumulated figure into the appropriate filed
in table Qsummytb.
a.
update qsummrytb
set totl_prob_1=27
where location_name='johor';
b.
update qsummrytb
set totl_prob_1=23
where location_name='kedah';
c.
update qsummrytb
set totl_prob_1=24
where location_name='kelantan';
d.
update qsummrytb
123
set totl_prob_1=31
where location_name='terengganu';
e.
update qsummrytb
set totl_prob_1=45
where location_name='kuala lumpur';
f.
update qsummrytb
set totl_prob_1=46
where location_name='melaka';
g.
update qsummrytb
set totl_prob_1=56
where location_name='n.sembilan';
h.
update qsummrytb
set totl_prob_1=77
where location_name='selangor';
i.
update qsummrytb
set totl_prob_1=67
where location_name='perak';
j.
update qsummrytb
set totl_prob_1=55
where location_name='pulau pinang';
k.
update qsummrytb
set totl_prob_1=78
where location_name='sarawak';
l.
update qsummrytb
124
set totl_prob_1=34
where location_name='sabah';
m.
update qsummrytb
set totl_prob_1=7
where location_name='headquarters';
n.
select location_name, totl_prob_1 from qsummrytb;
Replace the totl_prob_1 accordingly based on the months which the
problems are recorded.
iv.
SQL query to accumulate total number problems recorded in every
state. The accumulation is from table Qsummytb.
a.
select sum(totl_prob_1) from qsummrytb
where location_name <> 'total'
v.
SQL query to accumulate total number problems recorded in
table
Msummarytb.
a.
select sum(totl_assign_1) from msummarytb
where department_id <> 'totl';
vi.
SQL query to populate monthly the previous month of problem record.
The extraction of data is from the Probmgttb and will be insert into
archive table Probhisttb.
a.
Insert into probhisttb (prob_number, userid, assignee_id,
assignee_depart, location_cd, location_name, branch, status,
severity,
types,
year_occur,
assignee_time,
category,
issue_date,
report_by,
request_types,
month_occur,
issue_time,
assignee_date,
report_depart,
report_date,
125
report_time,
escalate_to,
escalate_date,
escalate_time,
fixed_date, fixed_time, closed_date, closed_time, descriptions,
solutions)
Select prob_number, user_id, assignee_id, assignee_depart,
location_cd, loc_name, branch, status, severity, types, category,
request_types,
issue_time,
month_occur,
assignee_date,
report_depart,
report_date,
escalate_date,
escalate_time,
year_occur,
issue_date,
assignee_time,
report_by,
report_time,
escalate_to,
fixed_date,
fixed_time,
closed_date, closed_time, description,
solutions
from
probmgttb where status = 'fixed';
update probhisttb
set status='closed'
where status='fixed';
select * from probhisttb;
vii.
SQL query to delete the previous month problem record after all
related records are populated into Probhisttb. The deletion of records
are from table Probmgttb.
a.
delete from probmgttb where status='fixed';
select * from probmgttb where status='fixed';
5.5
Summary
126
The implementation and testing phase in this chapter can helps the refining
process of ITPMS system. The procedure and guidelines provided in this section can
help to eases the administrator when handling the system.
Even though the testing part is very tedious, it does help in troubleshoot any
failure or mal function of the system. Hopefully the developed ITPMS system will
satisfy all categories of users.
The user acceptance test for this system was not performed because the system
produced is a prototype. However upon the completion of the system, the user
acceptance test (UAT) will be perform in order to get certification and endorsement.
The certification and endorsement from UAT is important before the implementation
of the system.
127
CHAPTER 6
ORGANIZATIONAL STRATEGY
6.1
Introduction
This chapter is discussing the organizational strategy for ITPMS system. The
main focus of this chapter is the roll-out strategy for the system to be implementing in
the organization.
In order to implement the system, there are a few areas which need to be
considering, that are the change management and business continuity plan (BCP).
This is to ensure that the integrity of the system and the process flow of problem
management are intact to each other.
Other issues that will be discussed in this chapter are the data migration plan
and benefits gained by the organization in implementing the ITPMS system.
6.2
Roll-Out Strategy
128
Once the system is ready for launching, there will be a cut-off to the old
system that is the Infoman legacy system. The cut over date for the old system will be
schedule at the end of the month after producing the monthly report. This is to ensure
that the new system be able to captured data from the beginning of the month.
Capturing data from the beginning of the month is essential for producing accurate
monthly reporting.
The reason of choosing cut-over strategy for legacy system is because to avoid
redundancy
of problem reporting via the existing system and new system. If the
legacy system exists or available, there is a tendency of users still using the existing
system rather than the new system. Therefore this scenario will creates duplication in
problem reporting.
Before the launching of new system, all categories of users will be given
training for handling and operating the system. Since the users of the system also
from other state branch, there is a need to properly plan and schedule for the training.
Each status is having one IT representative which is called IT Relation Officer
(ITRO). The ITRO is responsible to liaise with the IT department on the issues that
relates to technical and IT projects. In addition, the ITRO is also responsible to
troubleshoot and solve the technical problem at state level. Therefore the ITPMS
system is also helping the ITRO to systematically record, monitor, escalate and
control the problems at state level.
In order to equip the ITRO with the knowledge of the new system, they are
required to attend the training session. The training of the system will be conducted
and centralized in Headquarters (HQ). All ITRO from states will be call to attend this
training session in HQ. The training is schedule for 2 days, which includes the
overview and hands-on the system.
The agenda for the training is as follows:
i.
Overview of ITPMS
129
6.3
ii.
System Architecture
iii.
Hands on
iv.
Q&A
Change Management
Initially the owner of the legacy system (Infoman) is the IT Operation
Division even though the owner of the problem management process is the Helpdesk
Unit. With new system, the ownership of the system is transferred to the Helpdesk
Unit. This is because, Helpdesk unit as a Problem Controller need to maintain and
manage the system requirements via the administrator functions.
Hence, implementing the new system in the IT division under JTM is
challenging due to the fact that new ownership of the system needs to learn new
things in handling the problem management process.
The users of the system need to be educating sufficiently with information on
the new system. Training and transfer of knowledge (TOK) session is very important
to the users of the system. This is to built up the level of confidence in the users when
handling or operating the system.
6.4
Data Migration Plan
130
The main constraint of this new system identified is the system is not being
able to support the existing data or information of the current processing. Therefore,
there is no need for the data migration plan for this system.
This is because all data and information captured are not convertible to the
new system. Therefore the system will not be able to perform inquiries on the
previous data. Thus, the inquiry of previous data is done manually by checking from
the files.
The challenge in this system is to convince the users that the previous data is
not convertible to the system. In addition, the users also need to be informed that with
this system the printing of hardcopy is not necessary.
6.5
Business Continuity Plan (BCP)
The business continuity plan is another important aspect to consider in
implementing the new system. After the implementation of ITPMS, there is a need to
plan for the BCP in order to keep in with the problem management process intact.
The system need to be backup once if there is no changes to the system. This
backup system is to be used or restored back if the existing system corrupted or
involved in disaster.
The database used in this system is also need to backup daily. This to ensure
that there is always the latest version of data available to restore if the need arise.
6.6
Benefit of the System
131
Below are the benefits of using the ITPMS system:
i.
More systematically
The system provided gives more systematically the handling of
problem management process. The system gives the eases of use for
the users to operate the system by structuring the users group and
functionalities.
ii.
Automation
The system provides automation for the handling of problem
management process. The system is able to integrate the 2 categories
of process, that is the manual processing and the legacy system. In
addition, the basic functions of adding, edit, update and delete the
record can be performed online via this system.
iii.
Time Consuming
With this system, time taken to produce reports and statistical data is
improved. This is because the data and report can be produced online
and automatic by using the batch online processing. Furthermore, few
errors and mistake during the manual processing can be eliminate or
reduce by this system.
6.7
Organizational Strategy
The decision of having new system for problem management was decided by
the IT management. This is to overcome the issues of late reporting for problem
analysis reported from users. Furthermore, the monitoring and tracking of problem
management is also crucial due to the two types of problem handling that is legacy
system and manual processing.
132
With this system, the monitoring and tracking problem is from single source
and more systematically. The report is also produced promptly and accurately every
month. The system also helps to eliminate or reduced the human errors. The accuracy
of information and data is important because it can influence any decisions made by
the management.
6.8
Summary
The ITPMS system can be a total solution for the organization to conduct or
perform the problem management processing. This is because this system complies
with the problem management life cycle.
The modules and features provided by this system is well structure and
organized for the ease of use.
133
CHAPTER 7
DISCUSSION & CONCLUSION
7.1
Achievements
The problem management is designed based on the study held by the writer
especially in analyzing the literature reviews. The findings and information pertaining
to the problem management system gained from the studies and reviews is used as a
guidance to develop the system.
The main achievement of this project is the ability to integrate the two
processes in problem management handling for Helpdesk Unit in Bank Simpanan
Nasional. The two processes are the automated legacy system and the manual
processing. By integrating these two processes, the handling of problem management
is more systematic and efficient.
The development of this system is also aligning with the IT Department
actions plan. One of the actions plan is to review and improve the problem
management processes. This is to give an excellent service to the users.
7.2
Constraints & Challenges
134
During the development process of the system, developer faces new
challenges and constraints. The main challengers to the developer are to learn and
study the application software used to develop the system in web based.
This is because; the developers’ background for developing any application is
using COBOL. The developer found out that the concept in developing the PC based
application is different from the developing the mainframe based application.
Other constraint the developer encountered is the time, more time is needed to
develop the system as the developer needs to learn and explore the software.
7.3
Aspirations
It is hoped that the system is developed successfully and the usage of this
system can be extended. By developing the problem management system, it is also
hoped that to a certain extend the daily handling of problems are carried out smoothly
and efficient.
7.4
Future Enhancements
135
In order to ensure the system is complying with current demand and be more
competitive, it is suggested that the system be reviewed and fine-tuning.
The
consideration that need for future enhancement include the following:i.
To embed new form or button for data extraction for archiving and
reporting processing. However, this requirement needs to study in detail
because of the human intervention to modify and change the SQL script
ii.
More reports should be produced to facilitate the management with the
data and information on the performance of the IT supports and problems
reported. The suggested report that should be considered is as follows:
a
total number of problem based on problem category – to
analyze which category with highest total number of problem
reported
b
total number problem based on problem type – to see which
problem type is the most critical
iii.
To include features for catering the occurring problems. For example
display the related problems and number of occurrence.
7.5
Summary
With all the challenges and constraint, the developer manages to complete the
system. However the system can be review and fine-tuning for better performance in
future. Probably new features and enhancement can be added into the system.
In addition, the developer introduced 2 approaches of processing involved in
this system. The type of processing that being introduced with this system is the
online processing and group processing.
136
The different between this two processing is the way of handling the data in
the database. The online processing is operated by many users from different location.
The users can access online data for updating, viewing or even adding new data.
On the other hand, the group processing is to perform a mass processing of
data in the database. The processing of data is via the execution of the batch script.
The batch script is written in the SQL query to perform the functions.
137
BIBLIOGRAPHY
1
http://www.ins.com/downloads/whitepapers/ins_white_paper_incident_
Management_0403.pdf
2
http://www.remedy.com/solutions/documents/white_papers/Remedy_
ITIL_wp_en_pdf
3
http://www.auditnet.org/docs/Help%20Desk%20and%20Problem%
20Management.pdf
4
http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfprbmg.mspx
5
http://www.altiris.com/itil/Support_Extending_ITIL.pdf
6
http://www.frontrange.com
7
http://www.dcms.com/pmrsto2.htm#features
8
http://www.unipress.com/footprints
9
http://sern.ucalgary.ca/~maurer/ICSE98WS/Submissions/Kudo/
Kudo_PMS.html
10
http://www.pinkelephant.com.br/bpink/Benefits_of_ITIL.pdf
11
http:/www.pinkelephant.com.
138
12
http://www.itilfoundations.com/cat_processes
13
http://www.bmc.com/index.html
14
http://www.itilsurvival.com/ITILProblemManagementProcessModel2.html
15.
http://www.itilsurvival.com
16
http://us.foxit.net/download/intro_itil.pdf
17
Penny A.Kendall, Introduction to System Analysis & Design: A Structured
Approach, IRWIN, Third Edition,1996.
18
Shelly cashman Rosenblatt, System Analysis and Design, Fifth Edition,
Thomson Cource Technology, 2003.
i
Appendix A
BORANG LAPORAN MASALAH TEKNIKAL /
PEMASANGAN KOMPUTER
UNIT KHIDMAT BANTUAN TEKNIKAL / UNIT SOKONGAN TEKNIKAL NEGERI
BAHAGIAN KOMUNIKASI DATA
JABATAN TEKNOLOGI MAKLUMAT
BANK SIMPANAN NASIONAL
NO. LAPORAN :
/
A) BUTIRAN PELAPOR
PELAPOR :
Zalizan Bin Rajab
NO. SAMB :
5607
JAB / BAH :
Jabatan Perbankan Cawangan
TARIKH:
22.04.2005
MASA LAPORAN
DI TERIMA:
B) KETERANGAN MASALAH / GANGGUAN / PEMASANGAN
NAMA PENGGUNA
:
Mohd Syahril Fitri Bin Mohd Arif
LOKASI
:
(Sekiranya berpindah, nyatakan lokasi asal
dan baru)
Jabatan Perbankan Cawangan
JENIS PERALATAN
:
Komputer Peribadi
SISTEM PENGOPERASIAN
:
Windows XP
BARCODE
:
BSN 03748
JENIS MASALAH / GANGGUAN /
PEMASANGAN :
Mohon Pemasangan LAN. Pegawai ini adalah merupkan Pegawai dari Jabatan
Kualiti dan telah ditukarkan ke JPC. PC berkenaan telah dibawa oleh beliau
dari Jabatan yang terdahulu
C) UNTUK TINDAKAN BKD / UNIT SOKONGAN TEKNIKAL
NO. FACE PLATE
LAMA :
BARU:
NO. PORT SWITCH
LAMA :
BARU:
IP
LAMA :
BARU:
NAMA KOMPUTER
LAMA :
BARU:
NO. PATCH CORD
TINDAKAN DIAMBIL OLEH
TANDATANGAN:
NAMA:
TARIKH
30/10/2004
6
MERAH
KUNING
BIRU
Disediakan oleh
27/9/2004
5
J30022
P
CR
Wakil HP telah semak masalah
pada 28/9/2004 tetapi perlu pesan
alat ganti melalui HP KL
Wakil Mesiniaga telah semak
masalah pada 29/2/2004 tetapi
printhead perlu dipesan melalui
Mesiniaga KL
OS ditukar dari Windows 2000
server kepada Windows XP.
Catitan / Makluman
Pengguna
Lambert Ampah Mullie
4/11/2004 14:30
1/10/2004 12:00
1/10/2004 10:35
5/10/2004 17:00
28/9/2004
21/9/2005
Tarikh / Masa
selesai
Problem
Change Request
HP rep. no.
2203314826
HP rep. no. 2203116815
HP rep. no. 2203145843
Mesiniaga rep. no.
1299837
Joachim Ian
Joachim Ian
Agihan
Disahkan oleh
Joachim Ian
Joachim Ian
Mazalan Dewi
Lambert A. M
Lambert A. M
Joachim Ian
Pelaksana
INDIKATOR
I127012
I20013
I29041
I24011
I20022
No Log /
Laporan
Joachim Ian Dominic Nawe
WS05 mempaparkan error msg
“1790-disk 0 error”
LB12 printhead fail to initialize
Printhead pencetak LB12 tidak
berfungsi
Pencetak LQ1170
mengoyakkan ribbon. Disyaki
printhead bermasalah
\TM slow
Pihak SESCo tidak dapat dial
up ke server FTP Giro
Deskripsi Masalah
7 hari
Selesai tapi lebih drp 7 hari
OK
Caw. Sibu
Caw. Bintulu
Caw. Daerah Miri
30/9/2004
4
Caw. Daerah Sibu
29/9/2004
3
Caw. Marudi
Caw. Utama Kuching
Bahagian / Cawangan
24/9/2004
08:30
20/9/2004
12:10
Tarikh /
Masa
2
1
Bil
DAILY PROBLEM (SARAWAK)
Appendix B
Borang Pemantauan Indikator Kualiti
Jabatan Teknologi Maklumat
Dari 1 Mac Sehingga 31 Mac 2005
No Indikator : 9 Khidmat Bantuan Teknikal Kpd Pengguna Kitaran Masa : 7 hari bekerja
i
Docement system specification
14
Prepare unit test script
Perform unit test
Prepare integration test script
Perform integration test
Prepare system test script
Perform system test
Prepare user test script
Perform user test
21
22
23
24
25
26
27
28
Page 1
Project Summary
Progress
Milestone
Tue 9/20/05
Mon 9/19/05
Mon 9/19/05
Thu 9/15/05
Wed 9/14/05
Mon 9/12/05
Tue 8/16/05
Tue 8/16/05
Tue 8/2/05
Thu 5/12/05
Thu 5/12/05
Fri 5/13/05
Tue 5/3/05
Mon 5/2/05
Mon 3/28/05
Mon 3/28/05
Wed 4/20/05
Wed 4/20/05
Deadline
External Milestone
External Tasks
30, '05 Feb 27, '05 Mar 27, '05 Apr 24, '05 May 22, '05 Jun 19, '05 Jul 17, '05 Aug 14, '05 Sep 11, '05
T
M
F
T
S W S
T
M
F
T
S W S
T
M
F
T
S W S
T
Summary
4 days
3 days?
3 days?
3 days?
3 days?
3 days?
25 days?
14 days?
47 days?
97 days?
105 days?
1 day
4 days?
3 days?
13 days?
30 days?
3 days?
Thu 2/10/05
Mon 4/18/05
Tue 4/12/05
Mon 4/4/05
Thu 2/10/05
Start
Thu 2/10/05
Split
Task
Coding
Project: Project timelines V2
Date: Tue 11/22/05
Study and learning new software
20
System implementation
19
18
17
16
Project 1 presentation
Develop system architecture
13
15
Develop system model
System design
12
11
10
Identify user requirements
3 days?
9
System analysis
2 days?
8
Assessment observation
6
4 days?
6 days?
16 days?
Documents review
49 days?
Duration
170 days?
7
Feasibility study
5
System planning
Task Name
Integrated Technical Problem Management Syst
4
3
2
ID
1
Appendix C
Gantt Chart for ITPMS
Draft policy
33
Page 2
Project Summary
Deadline
External Milestone
External Tasks
30, '05 Feb 27, '05 Mar 27, '05 Apr 24, '05 May 22, '05 Jun 19, '05 Jul 17, '05 Aug 14, '05 Sep 11, '05
T
M
F
T
S W S
T
M
F
T
S W S
T
M
F
T
S W S
T
Progress
Milestone
Wed 10/5/05
Wed 9/21/05
Thu 9/15/05
Mon 9/19/05
Mon 9/12/05
Mon 9/12/05
Start
Summary
1 day
3 days
5 days?
5 days?
6 days?
10 days?
Duration
Split
Task
Presentation project 2
Project: Project timelines V2
Date: Tue 11/22/05
37
36
35
Review and signoff
User guide manual
32
34
Operation manual
Documentation
Task Name
31
30
ID
29
Appendix C
Gantt Chart for ITPMS
i
Appendix D
Table 4.7.1.1 The data definition of Probmgttb
Nos
Field Name
Size
Descriptions
1.
Prob_number - FK
Int(9)
Auto generated problem
numbers.
2.
User_id
Char(8)
Authorized user id to login the
system
3.
Assignee_id
Char(8)
Owner of the problem / system /
application; i.e. user id
4.
Assignee_depart
Char(4)
Department of the problem /
system / application owner; i.e.
BPA, BKS, BOT.
5.
Location_cd
Char(4)
6.
Loacation_name
Char(30)
Code assigned to the division or
mini branch; i.e. A100, C100,
C112
Department / division or mini
branch; i.e. Jab. Khidmat
Bayaran, Bah. Kad , Caw mini
Setiawangsa.
7.
branch
Char(20)
Headquarters or state location;
i.e. Ibupejabat, Kuala Lumpur ,
Sarawak
8.
Status
Char(10)
Status or the problem; i.e.
Assigned, Pending, Fixed,
Closed.
9.
Severity
Char(10)
Severity level or the problem;
i.e. High, Medium, Low.
10.
Types
Char(20)
Types of the problem; i.e. PC
desktop, notebook, LAN cable.
11.
Category
Char(20)
Category of problem; i.e.
Hardware, Software, Network,
Operating System.
ii
12.
Category
Char(20)
Category of problem; i.e.
Hardware, Software, Network,
Operating System.
13.
Request_types
Char(8)
Indicator to tag for deletion,
install or report.
14.
Month_occur
Int(2)
The month in which the problem
arised; i.e. 01,02,03.
15.
Year_occur
Int(4)
The year in which the problem
arised or reported; i.e. 2005,
2006.
16.
Issue_date
Date
The date problems key in the
system;
Format: YYYY-MM-DD
17.
Issue_time
Time
The time problems key in the
system;
Format: HH:MM:SS
18.
Assignee_date
Date
19.
Assignee_time
Time
20.
Report_by
Char(15)
The date when the problem is
escalated/assigned to the owner.
Format: YYYY-MM-DD
The time when the problem is
escalated/assigned to the owner.
Format: HH:MM:SS
The name of the problem
reporter.
21.
Report_department Char(20)
The department of the problem
reporter.
22.
Report_date
Date
Date when launch the problem
report.
23.
Report_time
Time
Time when launch the report.
24.
Escalate_to
Char(10)
25.
Escalate_date
Date
Name of the vendor when the
problem is escalated; i.e. IBM,
Acer, Heitech.
Date when the problem is
escalated.
26.
Escalate_time
Time
Time when the problem is
escalated.
27.
Fixed_date
Date
Date assigned by the assignee
iii
when problem is rectified.
28.
Fixed_time
Time
Time assigned by the assignee
when problem is rectified.
29.
Closed_date
Date
30.
Closed_time
Time
31.
Description
Char(50)
Date set by the Problem
Controller (Helpdesk) after the
verification or rectified
problems.
Time set by the Problem
Controller (Helpdesk) after the
verification or rectified
problems.
The detail description of the
problem reported.
32.
Solutions
Char(50)
The detail solution after the
problem is rectified.
iv
Table 4.7.1.2 The data definition of Probhisttb
Nos
Field Name
Size
Descriptions
33.
Prob_number - FK
Int(9)
Auto generated problem
numbers.
34.
User_id
Char(8)
Authorized user id to login the
system
35.
Assignee_id
Char(8)
Owner of the problem / system /
application; i.e. user id
36.
Assignee_depart
Char(4)
Department of the problem /
system / application owner; i.e.
BPA, BKS, BOT.
37.
Location_cd
Char(4)
38.
Loacation_name
Char(30)
Code assigned to the division or
mini branch; i.e. A100, C100,
C112
Department / division or mini
branch; i.e. Jab. Khidmat
Bayaran, Bah. Kad , Caw mini
Setiawangsa.
39.
branch
Char(20)
Headquarters or state location;
i.e. Ibupejabat, Kuala Lumpur ,
Sarawak
40.
Status
Char(10)
Status or the problem; i.e.
Assigned, Pending, Fixed,
Closed.
41.
Severity
Char(10)
Severity level or the problem;
i.e. High, Medium, Low.
42.
Types
Char(20)
Types of the problem; i.e. PC
desktop, notebook, LAN cable.
43.
Category
Char(20)
Category of problem; i.e.
Hardware, Software, Network,
Operating System.
44.
Category
Char(20)
Category of problem; i.e.
Hardware, Software, Network,
Operating System.
v
45.
Request_types
Char(8)
Indicator to tag for deletion,
install or report.
46.
Month_occur
Int(2)
The month in which the problem
arised; i.e. 01,02,03.
47.
Year_occur
Int(4)
The year in which the problem
arised or reported; i.e. 2005,
2006.
48.
Issue_date
Date
The date problems key in the
system;
Format: YYYY-MM-DD
49.
Issue_time
Time
The time problems key in the
system;
Format: HH:MM:SS
50.
Assignee_date
Date
51.
Assignee_time
Time
52.
Report_by
Char(15)
The date when the problem is
escalated/assigned to the owner.
Format: YYYY-MM-DD
The time when the problem is
escalated/assigned to the owner.
Format: HH:MM:SS
The name of the problem
reporter.
53.
Report_department Char(20)
The department of the problem
reporter.
54.
Report_date
Date
Date when launch the problem
report.
55.
Report_time
Time
Time when launch the report.
56.
Escalate_to
Char(10)
57.
Escalate_date
Date
Name of the vendor when the
problem is escalated; i.e. IBM,
Acer, Heitech.
Date when the problem is
escalated.
58.
Escalate_time
Time
Time when the problem is
escalated.
59.
Fixed_date
Date
Date assigned by the assignee
when problem is rectified.
60.
Fixed_time
Time
Time assigned by the assignee
when problem is rectified.
vi
61.
Closed_date
Date
62.
Closed_time
Time
63.
Description
Char(50)
64.
Solutions
Char(50)
Date set by the Problem
Controller (Helpdesk) after the
verification or rectified
problems.
Time set by the Problem
Controller (Helpdesk) after the
verification or rectified
problems.
The detail description of the
problem reported.
The detail solution after the
problem is rectified.
vii
Table 4.7.1.3 The data definition of Locationtb
Nos
Field Name
Size
1.
Location_cd
Char(4)
2.
Branch_name
Char(30)
3.
State
Char(20)
4.
5.
Address_1
Address_2
Char(30)
Char(30)
6.
Address_3
Char(30)
Descriptions
The code assigned to the mini
branch; i.e. A100, C112, B100.
The name of the mini branch.
State name; i.e. Kuala Lumpur,
Kedah, Sarawak.
First address line of the branch.
Second address line of the
branch.
Third address line of the branch.
Table 4.7.1.4 The data definition of Useridnmtb
Nos
Field Name
Size
1.
User_id
Char(8)
2.
Department
Char(4)
3.
password
Char(8)
4.
Password_cfrm
Char(8)
Descriptions
The defined user id to login the
system.
The acronym of the user ids’
department.
The password created by the
user id when first time login.
The confirmation of the
password key in.
Table 4.7.1.5 The data definition of Admintb
Nos
Field Name
Size
1.
User_id
Char(8)
2.
Department
Char(4)
3.
password
Char(8)
4.
Password_cfrm
Char(8)
Descriptions
The administrator user id of the
system.
The acronym of the user ids’
department.
The password created by the
user id when first time login.
The confirmation of the
password key in.
viii
Table 4.7.1.6 shows the data definition of Projecttb
Nos
Field Name
Size
Descriptions
1.
Project_nos
Int(5)
Auto generated project number.
2.
User_id
Char(8)
3.
Department_id
Char(4)
4.
Project_id
Char(10)
5.
6.
Project_name
Project_category
Char(60)
Char(30)
7.
Project_status
Char(20)
8.
Project_mgr
Char(20)
The acronym of the user ids’
name of the project owner.
The acronym of the user ids’
department.
The name of the project; i.e.
SKS, ATM, GIRO.
The description of the project.
Category of the project; i.e.
compliance, revenue generating.
Status of the project; i.e.
completed, pending, in progress.
The name of the project
manager.
9.
Owner
Char(20)
10.
Owner_depart
Char(10)
11.
Start_date
Date
12.
End_date
Date
The name of the system /
application owner of the project.
The acronym of the owners’
department.
The start date of the project.
Format: YYYY-MM-DD.
The ending date of the project.
Format: YYYY-MM-DD.
ix
Table 4.7.1.7 The data definition of Msummarytb
Nos
Field Name
Size
1.
Department_id
Char(4)
2.
Year
Int(4)
3.
Totl_assign_1
Int(7)
4.
Totl_assign_2
Int(7)
5.
Totl_assign_3
Int(7)
6.
Totl_assign_4
Int(7)
7.
Totl_assign_5
Int(7)
8.
Totl_assign_6
Int(7)
9.
Totl_assign_7
Int(7)
10.
Totl_assign_8
Int(7)
11.
Totl_assign_9
Int(7)
12.
Totl_assign_10
Int(7)
13.
Totl_assign_11
Int(7)
14.
Totl_assign_12
Int(7)
15.
Totl_pending_1
Int(7)
16.
Totl_pending_1
Int(7)
17.
Totl_pending_2
Int(7)
18.
Totl_pending_3
Int(7)
19.
Totl_pending_4
Int(7)
20.
Totl_pending_5
Int(7)
Descriptions
The acronym of the IT
department in JTM; i.e. BPA,
BOT, BKS.
The year of total problems
reported.
The accumulated total of
problems reported in January
with status Assigned.
Accumulated total in February
with status Assigned.
Accumulated total in March
with status Assigned.
Accumulated total in April with
status Assigned.
Accumulated total in May with
status Assigned.
Accumulated total in Jun with
status Assigned.
Accumulated total in July with
status Assigned.
Accumulated total in August
with status Assigned.
Accumulated total in September
with status Assigned.
Accumulated total in October
with status Assigned.
Accumulated total in November
with status Assigned.
Accumulated total in December
with status Assigned.
The accumulated total of
problems reported in January
with status pending.
The accumulated total of
problems reported in January
with status pending.
Accumulated total in February
with status Pending.
Accumulated total in March
with status Pending.
Accumulated total in April with
status Pending.
Accumulated total in May with
x
21.
Totl_pending_6
Int(7)
22.
Totl_pending_7
Int(7)
23.
Totl_pending_8
Int(7)
24.
Totl_pending_9
Int(7)
25.
Totl_pending_10
Int(7)
26.
Totl_pending_11
Int(7)
27.
Totl_pending_12
Int(7)
28.
Totl_close_1
Int(7)
29.
Totl_close_2
Int(7)
30.
Totl_close_3
Int(7)
31.
Totl_close_4
Int(7)
32.
Totl_close_5
Int(7)
33.
Totl_close_6
Int(7)
34.
Totl_close_7
Int(7)
35.
Totl_close_8
Int(7)
36.
Totl_close_9
Int(7)
37.
Totl_close_10
Int(7)
38.
Totl_close_11
Int(7)
39.
Totl_close_1
Int(7)
status Pending.
Accumulated total in Jun with
status Pending.
Accumulated total in July with
status Pending.
Accumulated total in August
with status Pending.
Accumulated total in September
with status Pending.
Accumulated total in October
with status Pending.
Accumulated total in November
with status Pending.
Accumulated total in December
with status Pending.
The accumulated total of
problems reported in January
with status Closed.
Accumulated total in February
with status Closed.
Accumulated total in March
with status Closed.
Accumulated total in April with
status Closed.
Accumulated total May with
status Closed.
Accumulated total in Jun with
status Closed.
Accumulated total in July with
status Closed.
Accumulated total in August
with status Closed.
Accumulated total in September
with status Closed.
Accumulated total in October
with status Closed.
Accumulated total in November
with status Closed.
Accumulated total in December
with status Closed.
xi
Table 4.7.1.8 The data definition of Qsummrytb
Nos
Field Name
Size
1.
Location_cd
Char(4)
2.
Location_name
Char(20)
3.
Year
Int(4)
4.
Totl_prob_1
Int(7)
5.
Totl_prob_2
Int(7)
6.
Totl_prob_3
Int(7)
7.
Totl_prob_4
Int(7)
8.
Totl_prob_5
Int(7)
9.
Totl_prob_6
Int(7)
10.
Totl_prob_7
Int(7)
11.
Totl_prob_8
Int(7)
12.
Totl_prob_9
Int(7)
13.
Totl_prob_10
Int(7)
14.
Totl_prob_11
Int(7)
15.
Totl_prob_12
Int(7)
16.
Totl_bds
Int(3)
17.
Totl_atm
Int(3)
18.
Totl_atm_off
Int(3)
Descriptions
The code assigned to the main
barnach; i.e. A100, C100, D100
The name of state branch or
Headquarters.
The year of total problems
reported.
The state accumulated total of
problems reported in January
The state accumulated total of
problems reported in February
The state accumulated total of
problems reported in March
The state accumulated total of
problems reported in April
The state accumulated total of
problems reported in Mei
The state accumulated total of
problems reported in Jun
The state accumulated total of
problems reported in Julay
The state accumulated total of
problems reported in August
The state accumulated total of
problems reported in September
The state accumulated total of
problems reported in October
The state accumulated total of
problems reported in November
The state accumulated total of
problems reported in December
The state accumulated total of
BDS facilities.
The state accumulated total of
ATM facilities.
The state accumulated total of
ATM facilities which installed
off premise.
i
Appendix E
List of sample report produced.
A.
Monthly Reporting
No
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
B.
Report Name
JTM – Reported Problem For January
JTM – Reported Problem For February
JTM – Reported Problem For March
JTM – Reported Problem For April
JTM – Reported Problem For May
JTM – Reported Problem For June
JTM – Reported Problem For July
JTM – Reported Problem For August
JTM – Reported Problem For September
JTM – Reported Problem For October
JTM – Reported Problem For November
JTM – Reported Problem For December
Quarterly Reporting
No
1.
2.
3.
4.
Report Name
First Quarterly Reporting For January, February, March
Second Quarterly Reporting For April, May, June
Third Quarterly Reporting For July, August, September
Fourth Quarterly Reporting For October, November, December
i
Appendix F
User Manual :
1.
User Login Site.
To start off the ITPMS online:
a.
Click the Internet Explorer icon on the desktop screen.
or
Find the Internet Explorer on the Start Menu toolbar. Choose Star Menu –
Programs – Internet Explorer.
b.
Type http://localhost/mainpage.php in the address space.
The browser will display the main page of the ITPMS web site.
Appendix
: ITPMS Main Page
ii
2.
Only authorized user id can use the system. Key-in the correct user id
and password.
Appendix
: User Login Page
iii
3.
The first time login page is meant for the first time user start using the
system.
Appendix
: First Time Login Page
iv
4.
This page is to change the password of the user id.
Appendix
: Change Password Page
v
5.
To start off the ITPMS:
a.
Choose the option listed from the main menu. There are 9
hyperlinks on the main menu that will link to the other pages of the
site.
b.
The selected page will appear in the browser.
vi
6.
The selected links Headquarters will appear in the browser.
a.
Choose the option listed from the Headquarters page to perform
the functions. There are 3 hyperlinks on the Headquarters page that
will link to the other pages of the site.
vii
7.
The hyperlink under Register New Problem Record will lead to the
adding new problem record.
a.
Fill in all the required filed as display in the page.
viii
8.
The hyperlink under Update Problem Record will display a list of
problem for updating.
a.
Click the >> to view more detail of the selected record.
b.
Click the the Next button to update the record. This will links
to the update page.
ix
9.
The update page will appear in the browser. Fill in the particulars for
updating the record.
x
9.
The hyperlink under Tagging Problem Record will display a list of
problem for tagging
a.
Click the >> to view more detail of the selected record.
b.
Click the the Next button to tag the record.
xi
10.
The links view more will display the detail of problem record.
a.
Click the >> to view more detail of the selected record.
b.
Click the Links button to tag the record for deletion.
xii
11.
Fill in the prolem number and click OK to update the record.
xiii
12.
The page with successful tagging message will appear in the browser.
xiv
13.
The selected links Branches will appear in the browser.
a.
Choose the option listed from the Branches page to perform the
functions. There are 14 hyperlinks on the Branches page that will link
to the other pages of the site.
xv
14.
The creation of new record page will appear. Fill in the appropriate
particular to record the problems reported..
xvi
15.
The hyperlinks to each state will appear in the browser. There are 2
other main links to perform the function of updating and tagging the
problem record.
a.
Click >> to view more detail the selected record.
xvii
16.
The hyperlinks Assignee will display the list of problem record. This is
to view the problem particulars before updating. The links under View
More will display in detail the particular record.
xviii
17.
The hyperlinks View Current Record under Problem Tracking will list
out the state branch and Heaquarters for selection of viewing the
records. Each of the listed branch is having 3 links to perform to
functions.
xix
18.
The page of every listed state branch and Headquarters can view
records based on status, priorities and problem owner. Each of the
record listed is links to the update page. Following figures will shows
the related links that associated to this page.
xx
19.
The page for Problem Tracking by Status
20.
The page for Problem Tracking by Priority
xxi
21.
The page for Problem Tracking by Assignee or Problem Owner.
22.
The hyperlinks View Archived Record under Problem Tracking are
having a similar function with hyperlinks View Current Record.
The purpose of the viewing the archived record is to track the historical
record or data of previous problems.
xxii
23.
The hyperlinks Lists of Branches under Highlights is to list out all the
name and address of mini branches in every state.
24.
The hyperlinks of every state will display the following details on mini
branches.
xxiii
25.
The hyperlinks List of Projects under Highlights will display
particulars on the IT projects handled by JTM.
xxiv
26.
The hyperlinks Monthly under Summary Reports will display a
statistical data on the total of problem reported and handled by the IT
division under JTM.
xxv
27.
The links to the monthly report will display the statistical data. This
page also will link to view the data in a bar chart.
xxvi
28.
The viewing of statistical data in bar chart..
xxvii
29.
The hyperlinks Quarterly under Summary Reports will display the
statistical data from every branch and Headquarters. This page will
eases the users to do analysis of problems by providing the quarterly
report for comparison. In addition the bar chart is also provided via the
Links from this page.
xxviii
30.
The link to the First Quarterly report will display statistical data from
each states and Headquarters for the month of January, February and
March.
xxix
31.
The viewing of quarterly data in bar chart.
Appendix G
ITPMS
Draft Policy Problem Management
Content
Content
1
SECTION A
:
Introduction
2
SECTION B
:
Technical Problem Management System
2
SECTION C
:
Genaral Terms and Definitions
4
SECTION D
:
Roles and Responsibilities
6
SECTION E
:
System ITPMS
7
SECTION F
:
General Information
7
Page 1 of 8
Appendix G
ITPMS
Draft Policy Problem Management
SECTION
1.
A:
INTRODUCTION
This draft policy of Problem Management is a document that provides
guidelines and declaration on terms and services available when using the
system. In addition, this document also will outlined the roles and
responsibilities of the users and owner of the system.
SECTION
B:
TECHNICAL PROBLEM MANAGEMENT
OBJECTIVE
2.
Draft Technical Problem Management system is to cater for the following
objectives:
a.
To have a system which enables every technical problems is reported and
registered in the system. The system can help to expedite the action taken
and also to ensure all problems are channel to the correct and proper
Problem Owner.
b.
To ensure that all problems are rectified and solved within the agreed
timeframe. Any problems which need more time to solved must have a
mutual agreement between the User, Product Owner, Application Owner,
system Owner or any Third party Vendor.
c.
To provide a single point of contact between the JTM and the Users.
Page 2 of 8
Appendix G
ITPMS
Draft Policy Problem Management
d.
To centralized the technical problem management in BSN for better and
effcient work flow within the JTM departments.
e.
To ensure that all ICT staffs are committed and accountable for any related
technical problems that arise.
f.
To assist in providing a more accurate prediction of impact on system and
computer services.
g.
To ensure that every problems are identified with root cause and severity
level. Any approach taken to resolve the problems either a temporary or
permanent solution must be accompany with detail descriptions.
h.
To create a reliable method that simplified the escalation process of the
technical problems.
SCOPE
3.
The main focus is to provide the highest availability of computerized system
with minimum failure or interruption to all users and customers of BSN. Hence,
this system is a process of registering, monitoring, controlling and escalating
the problem records systematically.
Page 3 of 8
Appendix G
ITPMS
Draft Policy Problem Management
SECTION
BSN
C:
:
GENERAL TERMS AND DEFINTIONS
Bank Simpanan Nasional.
JTM :
Jabatan Teknologi Maklumat.
BOT :
Bahagian Operasi Teknologi Maklumat.
BPA
Bahagian Pembangunan Aplikasi .
:
BKS :
Bahagian Keselamatan Sistem.
SSR
:
Section Strategi dan Rekabentuk IT.
PSP
:
Section Perkhidmatan Sokongan Pengguna
Problem Controller :
Shall mean the administrator of ITPMS system and
referring to SectionPerkhidmatan Sokongan Pengguna (previously known as
Helpdesk Unit)
Problem Owner :
Shall mean to the owner or custodian of the system or
application.
System Owner
:
Shall refer to Bahagian Operasi Teknologi Maklumat which is
a custodian of the system in production and test environment.
Page 4 of 8
Appendix G
ITPMS
Draft Policy Problem Management
Application Owner :
Shall refer to Bahagian Pembangunan Aplikasi which is
responsible in the development of any system or application.
Product Owner :
Users :
Shall mean the custodian of the product offered by BSN.
Shall mean the users of any computerized system or any IT related
operational services within BSN.
Assignee :
Shall refer to the Problem Owner, System Owner or Application
Owner.
System Users :
Mean the authorized staff to login the ITPMS system.
Vendor / Third party : IT Vendors., Consultants or IT Suppliers.
Page 5 of 8
Appendix G
ITPMS
Draft Policy Problem Management
SECTION
D:
ROLES AND RESPONSIBILITIES
PROBLEM CONTROLLER
4.
The roles and responsibilities of the Problem Controller are as follows:a.
To ensure that all problems are logged and assigend to the proper assignee
with detail and complete problem discription.
b.
To monitor the status of the problem and follow up with the assignee on
any pending or outstanding problems.
c.
Have the authority to delete any problems record which is not reliable.
d.
Is authorize to initiate or call for meeting or discussion based on the
criticallity and severity level of the problem.
PROBLEM OWNER
5.
Problem Owner is responsible to every problem which is assigned to them.
Immediate action should be taken by Problem Owner to resolve the problems.
Every problem record should be provided with a root cause of the problems and
detail solutions by the Problem Owner.
Page 6 of 8
Appendix G
ITPMS
Draft Policy Problem Management
SECTION
6.
E: SYSTEM ITPMS
The ITPMS system is only authorize to the selected group of users. Each users
will be given a user id to login the system
7.
Any data or information captured in the system is confidential and should not
be disclose to public.
8.
Any failure to the ITPMS due to errors or disaster, hence the process and work
flow of problem management will fall back to the manual system.
SECTION
9.
F:
GENERAL INFORMATION
All problems recorded in the system must be assigned with severity level. This
will help the Problem Owner to prioritize the action taken to resolve the
problems.
10.
Any quieries or further explaination on the system usage can be addressed to
the Problem Controller.
Page 7 of 8
Appendix G
ITPMS
Draft Policy Problem Management
--- End of Document ---
Page 8 of 8
i
Appendix H
Seksyen Perkhidmatan Sokongan Pengguna
Bah. Keselamatan Sistem
Bah. Operasi Teknologi Maklumat
Bah. Pembangunan Aplikasi
Figure 4.7.2.1.4a Monthly Reporting
ii
Figure 4.7.2.1.4b Graphical Monthly Reporting
iii
Department & Division at HQ
Branches level
Total number of problem reported
Figure 4.7.2.1.4c First Quarterly Reporting
iv
Figure 4.7.2.1.4d Graphical First Quarterly Reporting
of new problem
Hqddcrfm.php
display the
the password.
perform the creation
3. The browser will
create and confirm
Hqadd.php
password entered.
system, need to
(Headquarters)
match user id and
id to login the
1. This module is to
entered.
reject the miss
2. For first time user
Headquarters.php
id and password
2. The system will
database.
Problem Location
when incorrect user
entered.
defined in the
Userlog_fail.php
creation menu for
connects to the
1. The system
the user login.
homepage menu of
2. All related menu
expected.
1. Same results are
message will display
user id and password 2. A rejected login
id against the user id
Userfirst.php
expected.
accepts the correct
authenticate the user
Userchg_pword.php
1. Same results are
Actual Results
1. The system
Expected Results
(UserLogin)
1. This module is to
Objective
Userlogin.php
File Name
Main Menu
Module
Table 5.3.4.1 The summarized results of the user login.
Completed
Completed
Status
Appendix I
i
the creation menu.
After submitting the
request, the
successful message
for creation new
record is display.
3. The correct
tagging menu for
deletion will be
record.
3. The deletion of
physical record is
not allowed by the
system. Therefore,
the user need to
select request type
‘delete’ to tag the
record for deletion.
Hqtag_disp.php
Hqtag_more.php
Hqtag_delete.php
Hqtag_cfrm.php
of the record.
successful tagging
display the
4. The system will
connected.
the input requires in
before updating the
problem can be view 2. The users entered
Hqupdate.php
Hqupd_cfrm.php
and messages are
problems.
2. The detail of
Hqcurr_more.php
display correctly.
are connected well
the recording of new
record.
Hqupd_disp.php
ii
perform the creation
of new problem at
state level.
2. This module will
display the list of all
state branches for
selection.
3. Every sub module
in state branches
will display
correctly the
problem detail for
viewing before the
updating.
4. The deletion of
physical record is
not allowed by the
system. Therefore,
the branch user need
Brchadd.php
Brchadd_cfrm.php
Brch_kedah_disp.php
Brch_kedah_upd.php
Brch_kedah_updcfrm.php
Brch_kedah_tagdisp.php
Brch_kedah_tagmore.php
Brch_kedah_tagdel.php
Brch_kedah_tagcfrm.php
Brch_pp_disp.php
Brch_pp_upd.php
Brch_pp_updcfrm.php
Brch_pp_tagdisp.php
Brch_pp_tagmore.php
Brch_pp_tagdel.php
Brch_pp_tagcfrm.php
Brch_perak_disp.php
Brch_perak_upd.php
Brch_perak_updcfrm.php
(Branches)
1. This module is to
Branches.php
Problem Location
based on the state
is display correctly
4. The information
branch.
from every state
to the related request
connected properly
modules are
3. All the sub
display.
of creation will be
successful message
request, the
submitting the
input, and
2. After entering the
for selection.
the branches page
connect correctly to
1. The system will
working perfectly.
edit/update is
as add and
4. All function such
correctly.
also display
3. The messages are
state branch.
module for every
the related sub
display properly all
2. The system
expected.
1. Same results are
Completed
iii
‘delete’ to tag the
record for deletion.
Brch_perak_tagmore.php
Brch_perak_tagdel.php
Brch_ns_upd.php
Brch_ns_disp.php
Brch_kl_tagcfrm.php
Brch_kl_tagdel.php
Brch_kl_tagmore.php
Brch_kl_tagdisp.php
Brch_kl_updcfrm.php
Brch_kl_upd.php
Brch_kl_disp.php
Brch_selangor_tagcfrm.php
Brch_selangor_tagdel.php
Brch_selangor_tagmore.php
Brch_selangor_tagdisp.php
Brch_selangor_updcfrm.php
Brch_selangor_upd.php
Brch_selangor_disp.php
Brch_perak_tagcfrm.php
to select request type branch request.
Brch_perak_tagdisp.php
iv
Brch_pahang_disp.php
Brch_johor_tagcfrm.php
Brch_johor_tagdel.php
Brch_johor_tagmore.php
Brch_johor_tagdisp.php
Brch_johor_updcfrm.php
Brch_johor_upd.php
Brch_johor_disp.php
Brch_melaka_tagcfrm.php
Brch_melaka_tagdel.php
Brch_melaka_tagmore.php
Brch_melaka_tagdisp.php
Brch_melaka_updcfrm.php
Brch_melaka_upd.php
Brch_melaka_disp.php
Brch_ns_tagcfrm.php
Brch_ns_tagdel.php
Brch_ns_tagmore.php
Brch_ns_tagdisp.php
Brch_ns_updcfrm.php
v
Brch_kedah+tagcfrm.php
Brch_pahang_tagdel.php
Brch_pahang_tagmore.php
Brch_pahang_tagdisp.php
Brch_pahang_updcfrm.php
Brch_pahang_upd.php
vi
id and password
entered.
reject the miss match
admin id and
password entered.
3. The browser will
display the
2. For first time
admin id to login the
system, need to
create and confirm
the password.
Useridnmtb
accessing the UserID
Admin_useradd.php
Admin_useradd_msg.php table to perform the
1. This module is
Admin_userid.php
main page correctly.
connects to user id
1. The system
the user login.
2. The appropriate
expected.
1. Same results are
when incorrect user
2. The system will
the database.
homepage menu of
message will display
password entered.
the user id defined in
Adminlog_fail.php
2. A rejected login
admin id and
admin user id against
Adminfirst.php
Login)
expected.
authenticate the
Adminrchg_pword.php
(Administrator
1. This module is to
accepts the correct
Actual Results
1. Same results are
Expected Results
1. The system
Objective
Admin_login.php
File Name
Main Menu
Module
Table 5.3.4.2 The summarized results of the administrator login
Completed
Completed
Status
vii
Locationtb
the functions is
connected well.
dan delete record
user id.
Admin_userdel_msg.php
expected.
2. The appropriate
messages are display
correctly.
connects to location
main page correctly.
2. The linking sub
module to perform
the functions is
connected well.
accessing the
Location table to
perform the function
of create new
location, update dan
delete record
location.
Adminadd_loc.php
Adminadd_loc_msg.php
Adminupd_disploc.php
Adminupd_disploc.php
Adminupd_loc_msg.php
Admindel_loc.php
Admindel_locmsg.php
for adding new
3. All the function
1. Same results are
1. The system
1. This module is
correctly.
messages are display
Admin_loc.php
working perfectly.
delete record are
record, update and
for adding new
3. All the function
module to perform
new user id, update
Admin_userdel.php
2. The linking sub
function of create
Admin_userdisp.php
Completed
viii
Projecttb
connected well.
location.
Adminupd_disppro.php
working perfectly.
delete record are
record, update and
for adding new
the functions is
dan delete record
Admindel_promsg.php
Adminupd_pro_msg.php
module to perform
new location, update
Admindel_pro.php
3. All the function
messages are display
2. The linking sub
function of create
Admindel_disppro.php
Adminupd_pro.php
2. The appropriate
main page correctly.
table to perform the
Adminadd_pro_msg.php
correctly.
expected.
connects to project
accessing the Project
Adminadd_pro.php
1. Same results are
1. The system
1. This module is
Admin_pro.php
working perfectly.
delete record are
record, update and
Completed
ix
i
Appendix J
Steps to be taken when execute the WinLamps file for installation.
1. Check box Apache2 + PHP5 and
MySQL 4.0
2. Check Add MySQL Front installer
Figure 5.4.1.1 : WinLamp Setup Installation Options
ii
Type in the destination
folder to install.
Click next to begin the
installation
Figure 5.4.1.2 : WinLamp Setup Installation Folder
This screen shows that the
WinLamp file is automatically
executed for the installation.
Figure 5.4.1.3 : WinLamp Log
iii
The screen display status
complete when finish
successfully installed the
file.
Click close to end
the installation
Figure 5.4.1.4 : WinLamp Completed The Installation
Figure 5.4.1.5 : Test Page for Apache Successful Installation
i
Appendix K
More snapshots on the administrator login
Click to display record for
deletion
Figure 5.4.2.3 : Useridnmtb
Click to add new
user id
ii
Click OK to confirm
creating new user id
Key in new User ID
Figure 5.4.2.4 : Useridnmtb – Create New Record
Click the links to
delete selected
record
Figure 5.4.2.5 : Useridnmtb – Display Page for Deletion
iii
Mesaage display for successful
deletion.
Figure 5.4.2.6 : Useridnmtb – Successful Delete Message Display
Select option to
perform functions
Figure 5.4.2.7 : Locationtb Main Page
iv
To define a
new branch.
Figure 5.4.2.8 : Locationtb – New Creation Page
Click to links to update page.
Displaying particulars of
the branch
Figure 5.4.2.9 : Locationtb – Display Page
v
Click to delete the
selected record.
Figure 5.4.2.10 : Locationtb – Deletion of Record
Click to perform
functions
Figure 5.4.2.11 : Projecttb Main Page
vi
To define new
project record
Figure 5.4.2.12 : Projecttb – New Creation of Project Record
Click to links to update
page
Display particular of projects for
selection of update
Figure 5.4.2.13 : Projecttb – Display Particulars Record For Updating
vii
Key in particulars of
project for updating
Figure 5.4.2.14 : Projecttb – Update Page of the Record
Display details for
selection to delete
Click to delete
selected record
Figure 5.4.2.15 : Projecttb Main Page
viii
Figure 5.4.2.16 : Probmgttb Main Page
Figure 5.4.2.17 : Probmgttb – Create New Problem Record
ix
Figure 5.4.2.18 : Probmgttb – Display Problem Record
Figure 5.4.2.19 : Probmgttb – Update Problem Record
x
Figure 5.4.2.20 : Probmgttb – Display Problem For Deletion
Figure 5.4.2.20 : Probmgttb – Message Deleted Successfully
i
Appendix L
Steps to guide the execution of the SQL script via MySQL-Front
Select Query
folder
Open the MySQL- Front
to execute the query
Figure 5.4.3.1: MySQL-Front
Click to open the SQL
script.
ii
Select the file to execute
the script.
Figure 5.4.3.2: MySQL-Front – Select Batch Script
Table ID
Referring to the month problem
reported ; 1 refer to January
Year the problem
reproted
Problem Status
Use this figure to update
in the monthly table
Figure 5.4.3.3: Execute the SQL Query