DEVELOPMENT OF SPAKE’S MAINTENANCE MODULE FOR MINISTRY OF
DEFENCE MALAYSIA
SYED ARDI BIN SYED YAHYA KAMAL
UNIVERSITI TEKNOLOGI MALAYSIA
DEVELOPMENT OF SPAKE’S MAINTENANCE MODULE FOR MINISTRY OF
DEFENCE MALAYSIA
SYED ARDI BIN SYED YAHYA KAMAL
This thesis is submitted to fulfill the partial requirement of the Computer Science (Real
Time Software Engineering) Master Degree Award
Centre for Advanced Software Engineering
Universiti Teknologi Malaysia
TITLE
SEPTEMBER, 2004
DEDICATION
Especially dedicated to my lovely wife, Nurulhayati Md. Yusop.
To my beloved parents Tuan Syed Yahya Kamal Syed Bany and Pn. Khairiah Said.
To my wonderful parents in law Hj. Md Yusop Ayub and Hjh. Hamidah Hamid.
To my loving brothers and sisters.
For their love and best wishes.
ACKNOWLEDGEMENT
In the name of Allah the Beneficent the Merciful, I am thankful to Allah
Almighty for giving me courage, patience and strength to accomplish my thesis.
I would like to express my profound gratitude to my Academic Mentor, Associate
Professor Zailani Mohamed Sidek for always delivering his support and guidance
towards this thesis. Besides, a lot thanks to Miss Norizan Md. Zain @ Ali as Industrial
Mentor who has given guidelines in this project. Their comments and advice helped me a
lot in this project.
Not forgetting my lovely wife and beloved parents, for their prayers, support,
patience and love during my good and bad times. Their hardworking and trustworthy
natures, which have accomplished many recognized achievements, have always
influenced me to perform my very best.
Also thanks to my fellow postgraduate students for their views and tips are useful
indeed and lastly thanks to all participating individuals who are involved directly or
indirectly in supervising, giving support and guidance during this project.
ABSTRACT
Sistem Pengurusan Alat Komunikasi dan Elektronik (SPAKE) was developed to
mitigate the Ministry of Defence Malaysia especially for Royal Signal Regiment in order
to record, filter, process and search the data that have been stored in the Database
Management System (DBMS). This system has mitigated the user where every job
requirement forms, reports and information for certain data can be produced and printed
via user computers. Before the system was developed, traditional method done by using
lots of forms and reports resulted in less effective management because users need to use
lots of storing files to store all the forms and reports. Furthermore, users have difficulties
to search the past data. More than that, this manual method of course delays the job
transferring between army units around Malaysia. Following the government’s vision to
achieve electronic government or e-Government which is one of the flagship application
for vision 2020, Ministry of Defence Malaysia has take the brilliant initiative to realize
this vision. This transformation of job management will bring deep effect for the
department especially in reducing the human power, cost and time. Besides, this change
will also drive the department management and administration to be more efficient and
systematic.
ABSTRAK
Sistem Pengurusan Alat Komunikasi dan Elektronik (SPAKE) dibangunkan bagi
memudahkan Kementerian Pertahanan Malaysia khususnya Rejimen Semboyan DiRaja
untuk merekod, menyaring, memproses serta mencari data yang tersimpan di dalam
Sistem Pengurusan Pangkalan Data (DBMS). Sistem ini juga memudahkan pengguna di
mana segala borang permohonan tugas, laporan dan maklumat mengenai sesuatu data
dapat dihasilkan serta dicetak secara terus menerusi komputer pengguna. Sebelum sistem
ini dibangunkan, kaedah tradisional yang menggunakan pelbagai jenis borang dan
laporan menjadikan pengurusan tidak efektif kerana ianya memerlukan fail simpanan
yang banyak untuk menyimpan segala borang dan laporan. Ia juga menyusahkan penguna
untuk mencari data-data yang lepas. Selain itu, kaedah manual ini tentunya membawa
kepada kelewatan sesuatu tugas disampaikan diantara unit-unit tentera di seluruh
Malaysia. Sejajar dengan hasrat kerajaan untuk menjayakan kerajaan elektronik atau eGovernment yang termaktub di dalam salah satu aplikasi perdana Wawasan 2020, pihak
Kementerian Pertahanan telah mengambil inisiatif yang bijak untuk merealisasikan hasrat
tersebut. Transformasi pengurusan kerja sebegini tentunya memberi kesan mendalam
kepada jabatan terutamanya dalam mengurangkan tenaga kerja, kos dan masa. Selain itu,
perubahan ini juga pasti membawa kepada pengurusan dan pentadbiran yang lebih cekap
dan sistematik di dalam jabatan itu sendiri.
TABLE OF CONTENTS
CHAPTER 1 INTRODUCTION
1
1.0
Introduction
1
1.1
Project Overview
1
1.1.1
4
1.2
Involvement in SPAKE Project
Organization Profile
4
1.2.1
Organization Background
4
1.2.2
Nature of Business
5
1.3
Project Objectives
5
1.4
Project Scope
6
1.5
Project Team Organization
7
1.6
Project Plan
8
CHAPTER 2 LITERATURE STUDY
10
2.0
Introduction
10
2.1
Manual SPAKE System
10
2.2
Research on Existing Product
12
2.2.1
Lembaga Jurukur Tanah Online (LJTNet Online)
12
2.2.2
Sistem Pemantauan Tanah Persekutuan (SPTP)
12
2.2.3
Job Applying System (JAS)
13
TABLE OF CONTENTS (CONT…)
2.3
Problem Solving Technique
13
2.3.1
13
Software Development Models
2.3.1.1 Rapid Application Development (RAD)
Model
2.3.2
14
2.3.1.2 Waterfall Model
18
2.3.1.3 Prototype Model
21
2.3.1.4 Spiral Model
25
2.3.1.5 V-Shape Model
28
2.3.1.6 Rational Unified Process Model
30
System Platform
32
2.3.2.1 Microsoft .NET
33
2.3.2.2 J2EE
35
2.3.2.3 Comparative Analysis Between J2EE
and .NET
2.3.3
2.3.1
37
Databases
41
2.3.3.1 Microsoft SQL Server 2000
41
2.3.3.2 Oracle9i
42
Programming Languages
44
2.3.4.1 VB.NET
44
2.3.4.2 PHP
46
TABLE OF CONTENTS (CONT…)
CHAPTER 3 METHODOLOGY
47
3.0
Introduction
47
3.1
Software Process
48
3.1.1
48
Planning Phase
3.1.1
3.1.2
3.1.3
3.1.4
3.2
SPAKE Requirement Analysis Critical
Success Factors
49
Design Phase
50
3.1.2.1 Data Design
51
3.1.2.2 Architectural Design
51
3.1.2.3 Interface Design
52
3.1.2.4 Component Level Design
52
Rapid Construction Phase
52
3.1.3.1 Prototype
53
Deploy Phase
54
3.1.4.1 Quality Testing Phase
55
3.1.4.2 Delivery and Acceptance Phase
55
Problem Solving Methodology
56
3.2.1
Database Optimizing
56
3.2.2
Interface Grouping
57
3.2.3
Programming Error Handling
57
3.2.4
Filter the Information
57
3.3
Unified Modeling Language
58
3.4
Documentation Standard
59
TABLE OF CONTENTS (CONT…)
CHAPTER 4 PROJECT DISCUSSION
60
4.0
Introduction
60
4.1
SPAKE System Features
60
4.2
SPAKE User Interface
61
4.3
Output Analysis
61
4.3.1
Login
62
4.3.2
Pembaikan Swasta Sub Module
63
4.3.3
Pembaikan Dalam Jaminan Sub Module
79
4.3.4
Lawatan Sengaraan Sub Module
87
4.3.4
Kecacatan dan Ubahsuai Sub Module
94
4.4
Related Documentation
96
4.4.1
Software Requirements Specification
96
4.4.2
Software Test Description
97
4.5
Constraints
97
4.6
Problems
97
4.7
Recommendation
99
CHAPTER 5 CONCLUSION
101
5.0
Introduction
101
5.2
Lessons Learnt
102
5.3
Comments
103
REFERENCES
104
APPENDIX A
106
APPENDIX B
110
LIST OF TABLES
TABLE NO.
TITLE
PAGE
2.1
The RAD Model Advantages and Disadvantages
18
2.2
The Waterfall Model Advantages and Disadvantages
21
2.3
The Prototyping Model Advantages and Disadvantages
24
2.4
The Spiral Model Advantages and Disadvantages
27
2.5
The Rational Unified Process Model Advantages and
Disadvantages
32
LIST OF FIGURES
FIGURE NO.
TITLE
PAGE
1.1
SPAKE System Modules
3
1.2
Maintenance Sub Modules
6
1.3
Project Team for SPAKE System Development
3
1.4
Author’s SPAKE Project Gantt Chart
9
2.1
The RAD Process
16
2.2
The Waterfall Model
19
2.3
The Prototype Model
22
2.4
The Spiral Model
25
2.5
The V-Shape Model
28
2.6
The Rational Unified Process Model
30
2.7
Developing web services with Microsoft.NET
34
2.8
Developing web services with J2EE
36
4.1
Login Interface
62
4.2
Default Interface for R&I Users
63
4.3
Equipments Chooser Interface
64
4.4
Repairing Form
65
4.5
Conformation Repairing Form
66
4.6
Default Interface With New Job Status
67
4.7
Default Interface for Workshop Users
68
4.8
Workshop Job Form
69
4.9
Default Interface With New Job Status
70
4.10
Default Interface for Workshop Quality Control User
71
LIST OF FIGURES (CONT…)
FIGURE NO.
TITLE
PAGE
4.11
Approval Form
72
4.12
Default Interface With New Job Status
73
4.13
Default Interface for Semboyan Department
74
4.14
Privatize Information Form
75
4.15
Page One of Price Quotation Report
76
4.16
Page Two of Price Quotation Report
77
4.17
Default Interface With New Job Status
78
4.18
Under Warranty Pop-Up Message
79
4.19
Status Data Grid for R&I User
80
4.20
Default Interface for Testing Section User
81
4.21
Approval Form
82
4.22
Default Interface With New Job Status
83
4.23
Default Interface for Semboyan Department User
84
4.24
Default Interface for Semboyan Department User
85
4.25
Default Interface With New Job Status
86
4.26
Senggaraan Toolbar for Semboyan Department
87
4.27
Yearly Date Set Up for Maintenance Visiting Form
88
4.28
Senggaraan Toolbar for Workshop Quality Control Department
89
4.29
Searching for Maintenance Visiting Page
90
4.30
Page One of Senggaraan Visiting Form
91
LIST OF FIGURES (CONT…)
FIGURE NO.
TITLE
PAGE
4.31
Page Two of Maintenance Visiting Form
92
4.32
Page Three of Senggaraan Visiting Form
93
4.33
Defect and Maintenance Form
94
4.34
Defect and Maintenance Searching Page
95
LIST OF ABBREVIATIONS
API
-
Application Programming Interface
CORBA
-
Common Object Request Broker Architecture
DBMS
-
Database Management System
EMESYS
-
Electrical Mechanical Engineering System
ERD
-
Entity Relationship Diagram
E-Office
-
Electronic Office
GIS
-
Geographical Information System
HTML
-
Hyper Text Markup Language
ICT
-
Information Communication Technology
IDIS
-
Imatera Digital Image Services
IT
-
Information Technology
JAS
-
Job Applying System
JCA
-
J2EE Connector Architecture
JNI
-
Java Native Interface
JRE
-
Java Runtime Environment
J2EE
-
Java 2 Platform Enterprise Edition
KUTKM
-
Kolej Universiti Teknikal Kebangsaan Malaysia
LJTNet
-
Lembaga Jurukur Tanah Online
ODBC
-
Open Database Connectivity
OMT
-
Object Modeling Technique
OOP
-
Object Oriented Programming
OOSE
-
Object Oriented Software Engineering
Online
LIST OF ABBREVIATIONS (CONT…)
RAD
-
Rapid Application Development
RUP
-
Rational Unified Process
R&I
-
Receive and Issues
SISPIK-TD
-
Sistem Pengurusan Informasi Komputer – Tentera Darat
SPAKE
-
Sistem Pengurusan Alat Komunikasi dan Elektronik
SPTP
-
Sistem Pemantauan Tanah Persekutuan
SRS
-
Software Requirement Specification
STD
-
Software Test Description
UML
-
Unified Modeling Language
WWW
-
World Wide Web
XML
-
Extended Markup Language
LIST OF APPENDICES
APPENDIX
TITLE
PAGE
A
Roles and Responsibility
106
B
Overall Milestone of SPAKE Project
110
CHAPTER I
INTRODUCTION
1.0
Introduction
In this chapter, Sistem Pengurusan Alat Komunikasi dan Elektronik or SPAKE is
described. It involves the problem statements that bring to the existence of SPAKE
system. More than that, the organization background, project objectives and scopes are
also been discussed in this chapter.
1.1
Project Overview
Sistem Pengurusan Alat Komunikasi dan Elektronik (SPAKE) or translated as
Electronic and Communication Equipment Management System is a web-based system
that is developed as a sub system for the integrated Sistem Pengurusan Informasi
Komputer – Tentera Darat (SISPIK–TD). SISPIK–TD is proposed for the Rejimen
Semboyan DiRaja (RSD) or translated as Royal Signal Regiment of Malaysian Army.
SISPIK-TD is a web-based application that consists of two sub systems which are Sistem
Pengurusan Alat Komunikasi dan Elektronik (SPAKE) and Electrical Mechanical
Engineering System (EMESYS). Generally, the main idea of the system is to enhance the
Royal Signal Regiment administration and management operations. The system will
contribute to the efficiency and effectiveness in Royal Signal Regiment management.
There are five modules involved in SPAKE development while seven modules are
involved in EMESYS. The modules in SPAKE sub system are:
i.
Modul Perolehan (Acquisition Module)
ii.
Modul Senggaraan (Maintenance Module)
iii.
Modul Pemeriksaan Pakar (Specialist Inspection Module)
iv.
Modul Informasi Data dan Statistik (Statistics and Data Information
Module)
v.
Modul Sistem Pengurusan (Administration System Module)
The following are the brief descriptions for each module provided in SPAKE system:
i.
Modul Senggaraan is the most important module in SPAKE system. All
information about spare part equipment and repaired equipment will be
recorded in this module. It consists of equipments maintenance, defect
tracking, record keeping of maintenance job and usage of spare part record
in technical store.
ii.
Modul Perolehan consists of data management for equipment in the
Semboyan Department. The module is also used for archiving the data for
all equipment received and distribution among Malaysian Army bases.
iii.
Modul Pemeriksaan for recording all inspection that has been done to the
communication equipment. All inspection recorded will be used by higher
authorities to make a summary for all communication equipment.
iv.
Modul Informasi Data dan Statistik for collecting and distributing reports
within a specific format that has been introduced by the administration.
v.
Modul Sistem Pengurusan for managing all password and user ID to
ensure the system’s security.
This module is a main functionality of SPAKE subsystem. The sub modules for
every module in SPAKE system are shown in Figure 1.1.
Figure 1.1: SPAKE System Modules
1.1.1
Involvement in SPAKE Project
During the five months industrial attachment with IMATERA Digital Images
Sdn. Bhd. (IDIS), the author was required to understand the flow of Modul Senggaraan,
analyse the user requirements for the system, consult the user on the new system and
develop the system. Basically, the client for this system is the Ministry of Defence
Malaysia and it would be installed at Rejimen Semboyan DiRaja (RSD).
1.2
Organization Profile
In this part, a brief description of the organization’s profile will be discussed. It
includes the organization’s background, its structure and its experience in software
development.
1.2.1
Organization Background
Located at the Jelatek Business Park, Off Jalan Jelatek, Kuala Lumpur,
IMATERA Digital Image Services Sdn Bhd (IDIS) is a Bumiputera owned company with
many branches throughout Malaysia. IDIS is a combination of two words 'IMAN' and
'SEJAHTERA', with paid up capital of RM 5 millions and an authorized capital of RM 10
millions. The company was established as a member of the Imatera Group of Companies
on 1st October 1991.
1.2.2
Nature of Business
Imatera Digital Image Services Sdn Bhd is a growing company involves in
Information and Communication Technology (ICT) development and consultancy. IDIS
are specializing in the area of:
1.3
i.
System Integration for ICT.
ii.
Software Application and Development.
iii.
Data Conversion and Bureau Services.
iv.
Geographic Information System (GIS) / Remote Sensing Development.
v.
Electronic Office (E-Office) and Multimedia Development.
vi.
Customer Relationship Management and Maintenance.
vii.
Security and Safety Division.
Project Objectives
The main objective of this project is to increase performance, in terms of
efficiency, effectiveness, cost and time consumption by implementing the web based
application system. Hence, the project also aims to fulfil the following objectives:
i.
To propose a web-based system for the Malaysian Army. The application
will improve the Royal Signal Regiment in term of administration
management and operation.
ii.
To store all data related with communication equipments including the
spare part equipment.
iii.
To reduce time consuming in searching record from Semboyan
Department.
iv.
To enable Semboyan Department to perform online data recording and
processing through the Internet.
v.
To implement the paperless administration without using the existing
manual forms.
1.4
Project Scope
Modul Senggaraan
(Maintenance Module)
Pembaikan
Pelupusan
Produktiviti
(Repair/Overhaul)
(Disposal)
(Productivity)
Kecacatan
dan
Ubahsuai
(Defect and
Modification)
Lawatan
Senggaraan
(Maintenance
Visit)
Pembaikan Biasa
(Common Repair)
Pembaikan
Berencana
(Programmed Repair)
Pembaikan
Swasta
(Private Repair)
Pembaikan
dalam Jaminan
= Author’s project scope
(Under Warranty
Repair)
Figure 1.2: Maintenance Sub Modules
In SPAKE system development, the author concentrates in developing the
Senggaraan Module. Figure 1.2 shows the sub modules involved in Senggaraan Modules.
The scopes that has been pointed in SPAKE system development project are:
i.
Identifying the Modul Senggaraan requirements.
ii.
Analyzing and designing and developing the Modul Senggaraan which
focuses on Pembaikan Swasta, Pembaikan dalam Jaminan, Kecacatan
dan Ubahsuai and Lawatan Senggaraan components.
iii.
Developing the Senggaraan Module components consists of Pembaikan
Swasta, Pembaikan dalam Jaminan, Kecacatan dan Ubahsuai and Lawatan
Senggaraaan actual system.
iv.
Developing the SPAKE system prototype.
v.
Integrating with overall SPAKE component modules.
vi.
Writing draft of Software Requirement Specification (SRS) documents
and Software Test Document (STD) for SPAKE requirement and
documentation guidelines by applying using IDIS and DOD-DTD-2167A
(Related SPAKE’s documentation can be referred to IDIS).
1.5
Project Team Organization
One small team has been setup to develop the SPAKE system. The members of
the team consist of permanent staff and practical trainees from several universities. The
team has been setup according to the specialty of each member. The SPAKE project team
organization is shown in Figure 1.3. The roles for each position in SPAKE project team
are illustrated in Appendix A.
Amiruddin Baharuddin
Project Manager
Norizan Mohd. Zain
Mohd Fadzil Abdullah
IT Consultant
IT Consultant
Norhelda Heliani
Norhana Hanafiah
Rabaiah Jamal
Rozreen Malik
Haryaty Murni
IT Analyst
IT Analyst
IT Analyst
IT Analyst
IT Analyst
Khahlil*
Nurfauza Jali*
Wirdayu*
Tengku Aidyl*
Programmer
Programmer
Programmer
Programmer
Rozita Akmarza*
Syed Ardi*
Halimatun Sa’adah*
Programmer
Programmer
Programmer
Syawal*
Programmer
* Practical Trainees
Figure 1.3 : Project Team for SPAKE System Development
1.6
Project Plan
For the project plan, Figure 1.4 shows the task scope and timeframe that has been
done by the author during the project duration. The overall milestone of SPAKE Project
is shown in Appendix B.
Figure 1.4: Author’s SPAKE Project Gantt Chart
CHAPTER II
LITERATURE STUDY
2.0
Introduction
This chapter focuses on the literature review of the project. Firstly, it briefs on the
general overview of manual SPAKE system. Secondly, this chapter will provide some
real examples of existing system and comparison with the project proposed. The third
section will list all related software process models that exist nowadays and the different
between those models. Moreover, this chapter also discussed briefly on the Enterprise
Platform Software application being used and the comparison between those platforms.
The comparison between programming languages that can be used to developed the webbased system also been discussed in this chapter.
2.1
Manual SPAKE System
Currently the communication management system is done manually. The
Semboyan Department has to use the existing form in order to manage all requirements in
communication process. Therefore the Sistem Pengurusan Alat Komunikasi dan
Elektronik (SPAKE) was developed to cater this problem. This system will optimize the
entire task and mitigate all process involved in Semboyan Department.
By using the traditional way in managing the communication equipment, a lot of
problems occurred during the process. The problems have been identified as follow:
i.
It is hard to store and search the communication equipment stock available
in every Semboyan Workshop. If Semboyan Department personnel want a
data for every communication equipment and spare part equipment, they
need lots of time to retrieve the data from every Workshop file. Moreover,
sometimes there is human error in calculating the equipment stock.
ii.
Management in supplying, stock distribution and condemning the
equipment cannot be managed well since the records of all equipment are
handled by different bases throughout Malaysia.
iii.
There is no detail status control in every process used by Semboyan
Department. Thus, it brings a problem where every Formation Unit
requirements are not well organized.
iv.
A lot of time is involved in searching all data about communication
equipment and spare part equipment since all data is archive in each base.
v.
In information management aspect, there are no policies and technique
used to gather, organize, analyse and process the information thus bringing
the difficulties to coordinate the information.
vi.
The current system cannot provide an accurate information and statistic.
This is because there is no integrated system among all bases.
vii.
The security of data stored in a current system cannot be guaranteed
because the data can be accessed by anyone since the data recorded in
manual files.
2.2
Research on Existing Product
There are many web-based management systems available on the Internet
nowadays. IDIS also has lots of experience in developing the web based management
systems for government sector and private company. The discussion in this matter will
only concentrate in the basic idea of web-based management systems.
2.2.1
Lembaga Jurukur Tanah Online (LJTNet Online)
The LJTNet Online is an example of web-based management system, which has
been implemented by Lembaga Jurukur Tanah. The system is mainly used to manage
land issues all over Peninsular Malaysia. The system has increased the efficiency in effort
to implement the paperless administration, which is one of Wawasan 2020 target for the
government sector.
2.2.2
Sistem Pemantauan Tanah Persekutuan (SPTP)
The SPTP is a web based management system, which has been implemented by
Kementerian Tanah dan Pembangunan Koperasi. The main idea of the system is to
upgrade land administration and management system, to provide efficient service to
customers and also realizing the mission of electronic government.
2.2.3
Job Applying System (JAS)
The JAS was developed to mitigate the end user especially for Registrar Office in
Kolej Universiti Teknikal Kebangsaan Malaysia (KUTKM) to transform most of the
tasks more effective compared to the previous system that has done manually. This
system will optimize their task and will reduce in term of human power, cost and time
because the system work through the Internet.
2.3
Problem Solving Technique
The development of a web-based management system requires us to select the
best problem solving technique to assure the goals of the system can be achieved. This
section will discuss the technique used and the reason why the technique has been used to
develop the SPAKE system. In addition, a comparison with other techniques will also be
discussed in this section.
2.3.1
Software Development Models
Nowadays, there is variety of software development models that can be used to
develop a web-based management system. The models that can be used in developing the
system are as follow:
i.
Rapid Application Development (RAD) Model.
ii.
Waterfall Model.
iii.
Prototype Model.
iv.
Spiral Model.
v.
V-Shape Model.
vi.
Rational Unified Process (RUP) Model.
Every software development models has several phases. Every phase has a
mission and product. It’s only different in how they schedule and organize the activities.
IDIS has used the Rapid Application Development (RAD) Model to develop the SPAKE
system. The details of each model stated above will be elaborated deeply in the next
subsection.
2.3.1.1 Rapid Application Development (RAD) Model
The Rapid Application Development (RAD) model has been used to develop the
SPAKE system. The RAD is a technique for compressing the analysis, design, build and
test phases of a software development project into a series of short and iterative cycles.
Iteration allows for effectiveness and self-correction. Studies from the previous project
done by IDIS showed that human being almost never perform a complex task correctly at
the first tie. However, the developers are extremely good making an adequate beginning
and then making many small refinements and improvements to perfect the project later
on.
RAD projects are typically staffed with small-integrated teams comprised of
developers, end users or clients and IT technical resources. This small team will gather
benefits by a short iterative development cycle offered by RAD which would optimize
speed of the development, share the unity of vision and purpose, effective informal
communication and simple project management (Hans, 1997).
In SPAKE system development case, a group of armies from Semboyan
Department and a group of IDIS staff have been located at the same office. The army
group will guide the IT technical resources from IDIS in term of flows involved in every
module. When everyone gets together in one office and discuss, the system development
time consumption for the project phases can be decreased due to the understanding from
everyone.
There are several criteria that need to be matched before the RAD can be used in
web based management system development. The criteria are:
i.
Small integrated team comprised of developers, end users or clients and IT
technical resources must work together until the system delivered.
ii.
Need to integrate tools, methodology, people and management. The
scopes of the project need to well defined and focused.
iii.
Data for the project must already exist no matter if the data are completely
or in part.
iv.
Decisions can be made by small number of people who are available and
preferably co-located.
v.
The technical architecture of the system and flow need to be defined
clearly and the key technology components are in place and tested.
vi.
System meet user needs better with lower maintenance costs.
To implement this methodology, there are several methods to be used. The RAD
methods have a task list and a work breakdown structure designed to speed the project.
Among the most important methods are:
i.
Prototyping, which is an approach on creating the prototype or
demonstrable result as clear as possible and refining that result.
ii.
Iteration is a commitment to increase the development based on
refinement. Iteration will go hand in hand with prototyping.
iii.
Time boxing is a management technique that focuses on delivery, so that
only time box scope can be changed.
Figure 2.1 : The RAD Process
Moving to RAD process as shown in Figure 2.1, there are four phases involved in
RAD life cycle. These phases are used to ensure that each phase is delivered on time and
on budget. There are specific deliverables for each phase. The phases of the life cycle are:
i.
Planning Phase
The planning phase is used to make a functional specification. After the
functional specification has been done it will be presented to the user for
specification signoff. In this phase, the risk assessments are also created
for the project.
ii.
Design Phase
The detail design documents including the use cases, test design and data
model will be generated by the developers in design phase. At this phase,
the budget for the project is also counted to ensure the project is within
budget.
iii.
Rapid Construction Phase
The system will be developed and tested in this phase. All changes for the
system will be rapidly constructed until the user is satisfied with the
system. At this phase, the prototype of the system may be generated and
presented to the client. This phase is complete when the users test the
system and signoff each iteration made.
iv.
Deploy Phase
The deploy phase is a phase where the final test signoff and post mortem
will be made according to project deliverables. The setting up of the
system is also been done in this phase.
All phases involved in RAD model that has been use in SPAKE system
development will be discussed in detail in chapter three.
Actually the core ingredient to RAD methodology is their Joint Application
Development (JAD) process, which is used to develop requirements and turn them into
testable prototypes. System development teams need a structured JAD process to deliver
the promises of RAD methodologies. In SPAKE system development, the armies and
IDIS staff have joint hand together to ensure the requirements and success of the system
would be achieved.
Along the development of SPAKE system using the RAD model, some
advantages and disadvantages have been identified. The advantages and disadvantages of
RAD model are shown in Table 2.1.
Table 2.1 : The RAD Model Advantages and Disadvantages
Advantages
Disadvantages
1. The RAD model assures dramatic time, 1.
More speed and lower cost may lead
money and human effort savings when
to lower overall system quality. This
the developer and user work together
lower system quality can contribute to
in development life cycle.
a danger of misalignment of system
developed via RAD with the business
due to missing information.
2. Tighter fit between user requirements
2.
May have inconsistent internal designs
and system specifications due to
within and across systems.
understanding between the developers
Inconsistent internal designs
and users. More than that, the ability to
contribute to a possible violation of
rapidly change system design as
programming standards related to
demanded by users can be done using
inconsistent naming conventions and
this model.
inconsistent documentation.
3. RAD allows for system optimized for
3.
RAD that is not managed well can
users involved in RAD process. This
contribute to difficulty with module
model also concentrates on essential
reuse for future systems.
system elements from user viewpoint.
2.3.1.2 Waterfall Model
Nowadays, the Waterfall model is a popular version of the system development
life cycle for software development. It is considered as a classic approach to the system
development life cycle. The Waterfall model describes a development method that is
linear and sequential. Each phase in Waterfall development has distinct goals.
To understand the model, imagine a waterfall on the cliff of a steep mountain.
Once the water has flowed over the edge of the cliff and has begun its journey down the
side of the mountain, it cannot turn back. Of course, it is the same with waterfall
development where once a phase of development is completed; the development
proceeds to the next phase and there is no turning back.
SPAKE system development does not use the Waterfall model because of the
flow of this model. In SPAKE development, end users or clients work together with
developer, every member of the team has his/her own idea in designing the system.
Sometimes what the developer understand are not the client’s needs. If the Waterfall
model is used in SPAKE development, the design phase cannot be reversed after the
developer has presented their system design to the client. In reality, SPAKE system
consume a lot of time during the design phase since the project is divided into many
modules.
Analysis
Design
Implementation
Testing
Deployment &
Maintenance
Figure 2.2 : The Waterfall Model
The development concept of waterfall model moves through analysis, design,
implementation, testing and ends up at deployment and maintenance as shown in Figure
2.2. Each phase of development proceeds in strict order without any overlapping or
iterative steps.
The analysis phase is the first phase from the Waterfall model development
process. This phase is used to analyze the needs of the client and the needs will be record
as requirements for the system. Then the software will be designed base on the
requirements analysis that has been done. After the design phase, the process moves to
implementation phase where a fully functioning operational hardware-software system,
including such objectives as program and data conversion, installation and training will
be done.
After that, the software will be tested in the testing phases where this phase
focuses on making sure that any error is identified and that the software meets its
required specifications. The deployment and maintenance phase is a phase that are
usually the longest stage of the software. In this phase the software is updated to meet the
changing customer needs, adapted to accommodate changes in the external environment,
correct errors and oversights previously undetected in the testing phases and also
enhancing the efficiency of the software to ensure that the complete system meets the
software requirements.
Although the Waterfall phases are quite similar with RAD, the Waterfall model is
not suitable because the development of SPAKE system is not in strict order and the
development needs iterative steps.
The Waterfall model has its own advantages and disadvantages. The advantages
and disadvantages are shown in Table 2.2.
Table 2.2 : The Waterfall Model Advantages and Disadvantages
Advantages
1. Waterfall development allows for
Disadvantages
1.
Waterfall development does not allow
departmentalization and managerial
for much reflection or revision. Once
control. A schedule can be set with
an application is in the testing stage, it
deadlines for each stage of
is very difficult to go back and change
development to ensure the product be
something that was not well thought
delivered on time.
out in the concept stage.
2. Development moves from concept,
2.
The customer only sees a working
through design, implementation,
version of the product after it has been
testing, installation, troubleshooting,
coded. This may result in disaster if
and ends up at operation and
any undetected problems are
maintenance. Each phase of
precipitated to this stage.
development proceeds in strict order
without any overlapping steps.
2.3.1.3 Prototype Model
Prototype model is a cyclic version of the linear model. Once the requirement
analysis is done, the design of the system skeleton will be made. This version is called a
prototype. When the prototype has been developed, the prototype system will be given to
the client for overall evaluation and criticizes. The development of actual system will
start after the client tests the prototype system and gives his/her feed back to the
developer who refines the system according to the client’s exact expectation. After a
number of iterations, the final system is given to the user (Turner, 2984). Figure 2.3
shows the steps involved in Prototype model.
System Requirement
(typically incomplete)
Determine system
Specification Frame
Prototype Development
Plan
Evaluate Prototype
Accept as a
system component
Prototype Development
Need Improvement
Throw-away Prototype
Determine System
Specification
Component
Design & Implementation
Complete Software
System Verification
Figure 2.3 : The Prototype Model
There are three types of prototyping in Prototype model. This prototyping type is
differing by the process involved in their development. The details are as follow:
i.
Rapid Prototyping
The Rapid Prototyping is also called Evolutionary Prototyping. In Rapid
Prototyping, there is no initial detail specification of the system. User will
criticize base on the running prototype. Moreover, these types of
prototyping enforce that client or end user needs are always important.
After the feedback of the client, specification may changes to meet newly
discovered requirements.
ii.
Incremental Prototyping
The Incremental Prototyping is also called Structured Prototyping. It is a
combination of Rapid Prototyping and the Waterfall model. Using the
incremental prototyping, the prototype will be made at feasibility,
requirements, design and coding stage. The user will test the prototype
system at each stage. This means that the system is developed in
increments of functional capability.
iii.
Throw-Away Prototyping
The Throw-Away Prototyping is not itself a methodology but used to
assist another one. The prototype of the system is built to test things and
then will be throwing away. The reason to use this type of prototype is to
get the user requirements by using the exploratory and experimental
concepts.
As discussed before, the prototype is one of the RAD methods. Some of the
prototype concepts have been used in SPAKE development. By the definition, the Rapid
Prototyping style is quite similar to the methods used in SPAKE system development.
The Prototype model also contributes the advantages and disadvantages to the
web-based system development. Table 2.3 shows the advantages and disadvantages of
prototyping model.
Table 2.3 : The Prototyping Model Advantages and Disadvantages
Advantages
1. Prototype development is suitable for
Disadvantages
1.
Prototype development makes project
the system when the requirements were
management difficult because the
not well defined by the user. The user
iteration will keep looping if there are
will only give the exact requirements
no controls of it. The iteration
when the system prototype is delivered
happened since the user always
and tested.
changing his/her needs.
2. The actual system will meet the client’s
2.
The prototype system development is
satisfaction. This satisfaction is
not well structured. The requirements
achieved because the user has already
that always change by the user will
tested the prototype system and have
mess up the coding structure.
given their comments on the system.
Sometimes it also produces a system
From there, the developers will make a
with poor performance.
system functionality work as a user
needs.
3. The development of the system
3.
These approach needs a professional
contributes a good communication and
software engineer who is expertise
corporation between the client and
with a good motivation and patience
developers. Along the prototype
when dealing with fussy user who
development, the developers will
always changes the requirements along
always meet the user to ensure the
the development cycle.
system works as the user needs.
2.3.1.4 Spiral Model
The Spiral model, which is also known as the Spiral Life Cycle model, is one of
the systems development model used in developing the web-based system. This model is
originally defined by Barry Boehm, which combines the features of the Prototyping and
Waterfall model. The Spiral model is specially design for large, expensive and
complicated projects.
Figure 2.4 : The Spiral Model
The development concept of Spiral model starts when the developer determines
objectives, alternatives and constraint as an early phase deliverables. This concept will
end with the client reviewing the progress as shown in Figure 2.4. Each phase of the
development proceeds in strict order without any overlapping or iterative steps.
The Spiral model steps model can be generalized as follows:
i.
The system requirements are defined as much detail as possible. Usually
the definition of requirements involves interviewing a number of users of
the system and also other aspects of the existing system.
ii.
After the requirements are defined, a preliminary design is created for the
system. The prototype of the system is constructed from the preliminary
design. This is usually a scaled-down system and represents an
approximation of the characteristics of the final product.
iii.
The scaled-down system or the second prototype is evolved by a four
quadrants procedure which is evaluating the first prototype in terms of its
strengths, weaknesses and risks, defining the requirements of the next
prototype, planning and designing the next prototype and also constructing
and testing the next prototype.
iv.
The entire project can be aborted if the risks of the project are too risky. In
this phase, risk assessment is including the development cost overruns,
operating-cost miscalculation or any other factor that could be risk for the
project.
v.
The existing prototype is evaluated in the same manner as the previous
prototype. If the system needs to scale-down again, another prototype is
developed from it according to the four quadrants procedure outlined
before.
vi.
The preceding steps are iterated until the client satisfied that the refined
prototype represents the final product desired and lastly the final system is
constructed based on the refined prototype.
vii.
The final system again will be evaluated and tested by the user. Routine
maintenance is carried out on a continuing basis to prevent large-scale
failures of the system.
The Spiral model does not exclude from the contribution of advantages and
disadvantages to the development environment. It is shown in Table 2.4.
Table 2.4 : The Spiral Model Advantages and Disadvantages
Advantages
1. Spiral development makes budget and
Disadvantages
1.
The estimation on budget and schedule
schedule estimation more realistic as
are harder at the outset because some
work progresses because the questions
of the analyses are not done until the
have been raised within prototypes
design stage.
presented to the user.
2. This dynamic approach is good for
2.
The spiral system development was
medium to large projects where the real
excessive elaborated. It is hard and
world can be expected to change during
expensive to adopt. Moreover, the
the period of development. The
large number of intermediate stages
solution itself might have an unknown
makes documenting the processes and
effect on the real world.
training the staff more challenging.
Since the SPAKE system needs continuous iteration, the Spiral model is not
suitable for SPAKE system development. Moreover the SPAKE system is also not a
complicated system because it is only a new web-based system, which will change a
manual system. The process and requirements is already there, the developer only needs
to translate them to the system. The Spiral model also enables developer to abort the
entire project if the risks of the project are too high. The SPAKE system development
does not allow the aborted of the project because the contract has been signed before the
project been given to IDIS.
2.3.1.5 V-Shape Model
The V-Shape model is a structured model, which improved from the Waterfall
model. This model does not run into the problem that the system is impossible to be
tested because system test, integration test and unit test are plan ahead. For example,
when we plan the requirement, we also plan for testing. Therefore, when the system is
built, developer have a whole set of test cases for system testing.
The V-Shape framework emphasizes quality from the initial requirements stage
through the final testing stage. It focuses on testing throughout the development life
cycle, early development of test requirement and early detection of error. Each major
deliverable in the development is assessed, tested and verified.
Requirement
Specification
Validation
Integration
Preliminary Design
Unit Testing
Detailed Design
Coding & Debuging
Figure 2.5 : The V-Shape Model
Figure 2.5 shows processes involved in V-Shape model. The steps involved in VShape model are as follow:
i.
Requirement Specification.
ii.
Preliminary Design.
iii.
Detailed Design.
iv.
Coding and Debugging.
v.
Unit Testing.
vi.
Integration.
vii.
Validation.
The V-Shape model is a linear model and it works best in situation where the
requirements of the system are stable and the solution to meet the requirements is clear.
More than that, this model also works best if there is no pressure for immediate
implementation for the system.
As described before, V-Shape model is an improvement of Waterfall model.
Actually, this model is quite similar with Waterfall model. The difference is that each
development phase matches each test phases for example the requirement specification
with the validation or system testing, preliminary design with the integration testing and
detailed design with the unit testing.
As for SPAKE system development, V-Shape model is not the best practice. This
is because of no prototyping method involved in V-Shape model. The SPAKE
development needs prototyping as a method because the client needs to criticize the
prototype system before the actual system produced. The requirements of the system are
also not stable because the new requirements can evolve after the prototype presented to
the client. More than that, the testing is not a big concern in SPAKE development. The
system does not need be tested each phase. Only the understanding of the system works
and rapid development may help to achieve the SPAKE system goals.
2.3.1.6 Rational Unified Process Model
The Rational Unified Process or RUP model is a software development model
that suits with the Unified Modelling Language (UML). Usually the RUP model is used
to enable the production of highest quality that meets user requirements within
predictable schedules and budgets. Nowadays, RUP has become the real process for
managing, monitoring and controlling projects implementing software intensive system.
Based on it iterative and incremental approach, risk is reduced while organizations can
gather new requirements from the non stop-changing business environment.
The RUP model consists of four phases, which are Inception, Elaboration,
Construction and Transition. Within each phase, there are a number of iterations. This
iteration represents a complete development cycle from capturing the requirements to
implementation and testing. Figure 2.6 shows the RUP software life cycle and every
phase involved in this model.
Figure 2.6 : The Rational Unified Process Model
Inception phase is concerned with the scope of the project. This phase defines a
vision for the project, which includes risk assessment, estimates the resources needed and
schedule. Elaboration phase is a phase used to analyze the problem and define the project
plan. At the end of elaboration phase, the developer will have an overall understanding of
the entire project. The uses of use case models and class diagram are applied in this
phase.
Meanwhile, the construction phase is managed to produce the product. The
product is built in the same fashion as the Spiral model, which follows a series of
iterations. However, the transition phase is concerned with the final product.
The RUP is actually a good model to be used in SPAKE system development. It is
quite similar with RAD model. The phases in RUP are a bit complicated than RAD.
Unfamiliarity with RUP makes IDIS does not choose this model in SPAKE development.
The advantages and disadvantages of RUP model are further describes in Table
2.5.
Table 2.5 : The Rational Unified Process Model Advantages and Disadvantages
Advantages
1. The RUP development is based on
Disadvantages
1.
The RUP development does not cover
software engineering principles such as
the entire software process. It also does
taking an iterative, requirement-driven
not support multi-project infrastructure
and architecture-based approach to
development effort such as
development.
organization-wide architectural
modelling, missing opportunities for
large-scale reuse within organization.
2. The RUP provide several mechanisms
2.
The RUP is currently weak in areas
such as a working prototype at the end
such as metrics management, reuse
of iteration and the go/no-go decision
management, people management and
point at the end of each phase, which
testing.
provides management visibility into the
development process.
2.3.2
System Platform
There are many system platforms available to support the web-based system.
Choosing the right platform to support the system is very important to ensure the system
running smoothly in certain platform. Among the variety of system platforms available,
there are two popular choices that business always decided to use for their web-based
system, which are the Java 2 Platform Enterprise Edition or formerly known as J2EE,
built by Sun Microsystems and Microsoft .NET, built by Microsoft Corporation.
In this subsection, the comparison between these platforms will be discussed.
Although both Microsoft .NET and J2EE cover a great deal of technologies and
standards, focuses will look specifically on building server-side systems as web services
using these architecture. The SPAKE system development has chosen .Net technology as
their platform. The reason for this decision is discussed in the following subsection.
2.3.2.1 Microsoft .NET
Built by Microsoft Corporation, Microsoft.NET is a product that enables
organizations to build smart enterprise-class web services. The development of
Microsoft.NET is largely a rewrite of Windows, which was Microsoft's previous platform
for developing enterprise applications. Windows has included many proven technologies
that are in production today including Microsoft Transaction Server and the Microsoft
SQL Server database. The new .NET framework has replaced these technologies. This
framework includes a web services layer as well as improved language support to
advance the Windows technology (Wayne, 1999). Figure 2.7 shows the developer model
for building web services with Microsoft.NET.
Figure 2.7 : Developing web services with Microsoft.NET
The .NET platform is hosted within a container, which provides qualities of
service necessary for enterprise applications such as transactions, security and messaging
services. However, the business layer of the .NET application is built using .NET
managed components. The managed components factor interest the SPAKE developers to
use this platform. As discussed before, all modules involved in SPAKE system have been
divided between programmers, so that every programmer has his/her own components.
Using the .NET as a platform, at the end of the development phase, the developers should
not worry on how to manage all components because the .NET offers the easiness in
managing the components.
The most fundamental aspects of the .NET platform is .NET offers languageindependence and language-interoperability. By using a single .NET component,
developer can write a code partially in VB.NET or ASP.NET which is the .NET version
of Visual Basic and C# which is the Microsoft's new object-oriented programming
language. More than that, the .NET platform includes the following .NET Enterprise
Servers, SQL Server 2000, Commerce Server 2000, Application Centre Server 2000 and
Host Integration Server 2000 (Wayne, 1999).
SPAKE system development needs the language-interoperability elements to
ensure the web-based system runs smoothly. Using HTML as an interface and ASP.NET
as a body of system programming, this two languages need language-interoperability
elements for the project to be successful.
2.3.2.2 J2EE
The Java 2 Platform Enterprise Edition or J2EE was designed to simplify complex
problems with the development, deployment and management of multi-tier enterprise
solutions. J2EE is an industry standard and is the result of a large industry initiative led
by Sun Microsystems.
The J2EE architecture is based on the Java programming language. The
interesting part about Java is that the organizations have an opportunity to write their
code once and deploy that codes into any platform available in the market. The process
can be simplified as follows:
i.
Developers write a source code in Java language.
ii.
The Java code is compiled into byte code, which is a cross-platform
between source code and machine language.
iii.
Then the Java Runtime Environment (JRE) interprets this byte code and
executes it at run-time environment.
Historically, J2EE has been the architecture for building server-side deployments
in the Java programming language. Usually the J2EE platform is used to develop
traditional web sites and software components or even applications packages. Recently,
J2EE has been extended to include support for building XML-based web services as well.
This is the element that enables interoperability between a web services to the other web
services that may or may not have been written to the J2EE standard. Figure 2.8
summarizes the J2EE web services development model.
Figure 2.8 : Developing web services with J2EE
The J2EE application is hosted within a container. The container will provide
qualities of service for enterprise applications, such as security, transactions and
persistence services. Meanwhile, the business layer for this platform performed business
processing and data logic. The large-scale applications can also be develop by using
J2EE. For the large-scale application, business logic is built using Enterprise JavaBeans
components (Wayne, 1999).
The J2EE can also be a good choice in developing the SPAKE system. However,
there are certain factors that J2EE does not support in web-based system development
that made them choose the .NET as their platform. Those factors are discussed in the next
subsection where the comparison analysis between .NET and J2EE has been done.
2.3.2.3 Comparative Analysis Between J2EE and .NET
Before the developers choose the platform that they will use to support their webbased system, the aspects of differences, weakness and strengthen between .NET and
J2EE platform need to be considered. The comparative analysis between those platforms
is discussed as follow.
i.
Time to Market Features
Both Sun J2EE and Microsoft .NET provide runtime mechanisms that
insulate software developers from particular dependencies. J2EE offers
several features that accelerate time-to-market which are not found in
.NET. For example, state management services enable developers to write
less code and not worry about managing state, resulting in a higher degree
of rapid application development. Persistence services enable developers
to write applications without coding data access logic, resulting in leaner,
database-independent applications that are easier to build and maintain.
Microsoft.NET offers a variety of time-to-market features not found in
J2EE as well. Most notably, ASP.NET is independent of client device, and
allows for user interfaces to be rendered to alternative user interfaces
without rewriting code. Microsoft also offers Queued Components, which
are superior to MessageDriven Beans. It should be noted here that
Microsoft has tried to simplify server-side programming greatly by
removing support for features found in traditional enterprise applications,
such as state servers and simple transactions. Microsoft also provides
business process management and E-Commerce capabilities, which are
available in some J2EE implementations but not all.
ii.
Single Vendor Solution
Generally developers should always prefer to have a single-vendor
solution when building the web services. A single vendor solution is
usually more reliable, interoperable, and less error-prone than a twovendor bridged solution. One of J2EE's strengths is that it has spawned a
wide variety of tools, products and applications in the marketplace which
provide more functionality in total than any one vendor could ever
provide. However, this strength is also a weakness. J2EE tools are often
not interoperable due to imperfections in portability. This limits the
developer’s ability to mix and match tools without substantial low-level
hacking.
.NET provides a fairly complete solution from a single vendor, which is
Microsoft. This solution may lack some of the higher end features that
J2EE solutions offer but in general the complete web services vision that
Microsoft will be providing is equal in scope to that of a larger J2EE
vendor.
iii.
Market Perception
J2EE is an extremely well marketed platform because it is being marketed
by an entire industry of over fifty assorted vendors. This network of
interdependent businesses forms a virtual marketing machine and the
result is a fantastic market perception for J2EE.
.NET marketing strength stems from the fact that Microsoft knows how to
market a platform. They have put their best team on marketing .NET, as is
apparent in the industry hype surrounding the platform. This is a powerful
force not to be reckoned with. Microsoft's advantage is also that it
announced its web services strategy before the J2EE takes place which
gave it market perception. So in the marketing front, the developers give
the nod to Microsoft for doing the best job in hyping their platform.
iv.
Language Support
J2EE promotes Java-centric computing, and as such all components
deployed into a J2EE deployment must be written in the Java language. To
use J2EE, you must commit to coding at least some of your e-Business
systems using the Java programming language. Other languages can be
bridged into a J2EE solution through web services is CORBA and JNI or
JCA.
By way of comparison, .NET supports development in any language that
Microsoft's tools support. With the exception of Java, all major languages
will be supported. Microsoft has also recently introduced its new C#
language which is equivalent with the exception of portability to Java and
is also available as a programming language within the Visual Studio.NET
environment. A single .NET component can therefore be written in several
languages.
v.
Web Service Support
The future of e-Business collaboration is undoubtedly web services. For
organizations that are pursuing a web services strategy or are preparing for
the future of web services, their underlying e-Business architecture must
have strong web services support.
Today, J2EE supports web services through the Java API for XML
Parsing. Additional APIs are also under development. These are
convenience APIs to help developers perform web services operations
more rapidly such as connecting to business registries, transforming XMLto-Java and Java-to-XML.
The preview release of Microsoft.NET also enables organizations to build
web services. The tools that ship with Microsoft.NET also offer rapid
application development of web services with automatic generation of
web service wrappers to existing systems. Visual Studio.NET provides
wizards that generate web services (Wayne, 1999).
From the comparison discussed, the SPAKE system developer found that more
advantages can be achieved when using the .NET platform offered by Microsoft. Need to
be stated that J2EE advantages also need not to be declined for the future web-based
development because the platform also contributes to the variety of choices for webbased development.
2.3.3
Databases
There is a number of advantages when computerized filing system is used over
the manual system. Usually the Database Management System (DBMS) is used for
storing the information or data. As a part of the data entry process, the DBMS will assign
a unique identifier to each document record. This identifier may be used as an indexed
key for retrieval purposes and can also be used to annotate actual documents when the
data being stored. When document retrieval is required, a user may enter an identifier. In
a more likely situation, a user will enter criteria that the DBMS uses to retrieve a bounded
record subset from the user selects the records required.
Web-based systems provide immediate improvements in efficiency over manual
system but the standard DBMS approach remain compromised in a number of significant
ways such as the information is fragmented across a set of database fields. This means
each record is not recognizable entity and probably does not have a humanly readable
structure.
In this subsection, the comparison between Microsoft SQL Server 2000 and
Oracle9i Database will be discussed. Although both Microsoft SQL Server 2000 and
Oracle9i Database can be used as a database for SPAKE system, the SPAKE project team
has decided to use Microsoft SQL Server 2000 as the system database. The reason on this
matter will also be discussed in the following subsection.
2.3.3.1 Microsoft SQL Server 2000
SPAKE system make use of Microsoft SQL Server 2000 as their database because
Microsoft SQL Server 2000 is the complete database that offer for rapidly delivering the
next generation of scalable web-based system, e-commerce and data warehousing.
Microsoft SQL Server 2000 offers number of benefits that interest the SPAKE
system developer. The benefits that SQL Server 2000 offers are:
i.
Microsoft SQL Server 2000 is a fully web enable where it can make
query, analyze and manipulate data over the web. This database uses an
extensible Markup Language (XML) in SQL Server 2000 where the
database can exchange data between loosely coupled systems.
ii.
The SPAKE system needs a highly scalable and reliable database because
the system can grow without limits with enhanced scalability and
reliability features. The Microsoft SQL Server 2000 offered a partition
database workload to achieve scale-out of applications.
iii.
More than that, the Microsoft SQL Server 2000 is actually have a Fastest
Time-to-Market element where the database can rapidly builds, deploy
and manage the web-based system, e-commerce and data housing
solutions. It is also able to perform sophisticated data mining on customer
and financial data.
From the discussion on benefits offered by Microsoft SQL Server 2000, SPAKE
system developer found that the database can provide the fastest route to web-based
system development.
2.3.3.2 Oracle9i
Another well-known database that available in the market today is the Oracle9i
Database. The Oracle9i Database is the current release of Oracle’s information
management solution. It is designed to support and leverage the capabilities of the
Internet. Besides, it also provides extensive functionality to support businesses running
on the World Wide Web (WWW) as well as traditional mission critical OLTP and Data
Warehousing applications.
Oracle9i Database also supports the high scalability requirements of the most
demanding Internet-based and traditional mission-critical applications, as well as the
highest availability requirements. It is capable of handling all type of information for all
types of applications and provides outstanding, across-the-board, and transparent
scalability from low-end processor to high-end symmetric multi processor systems and
multi node clustered configurations.
The Oracle9i Database has evolved over more than 20 years. From the earliest
relational database ad hoc SQL, through to the Internet era the database now can support
the web based business applications. Oracle9i Database has been designed to provide the
most complete and low cost solution for any business information management
requirements and is the only solution available today that can:
i.
Guarantee the critical business information is available when needed.
ii.
Provide proven performance, scalability and capacity on demand for any
business requirements.
iii.
Integrate business information from disparate sources including thirdparty database and file systems.
iv.
Consolidate and manage all developer Internet content.
v.
Reduce the time takes for a business to make better business decisions by
analysing more data faster.
Although the advantages of Oracle9i Database offered also found in Microsoft
SQL Server 2000, there is no guarantee on Fastest Time-to-Market element that offered
by Microsoft SQL Server 2000. Furthermore, for those who are not familiar with
Oracle9i, they will face a difficulty in handling the data transaction between the web
based-system and the database.
2.3.1
Programming Languages
Nowadays, there is a lot of programming languages that developers can choose to
develop the web-based system such as VB.NET, PHP, ASP.NET, etc. Each language has
its own strengthens and weaknesses. It depends on the developers themselves to choose
the best for their development.
VB.NET and PHP are the most promising programming languages in web-based
development. As for SPAKE system development, the developer has chosen the VB.NET
language as their programming language.
This subsection focuses on the definition, overview of strengthens and
weaknesses of VB.NET and PHP. There are a lot of factors need to be considered before
the developer choose the languages because different projects may appeal to a different
technology.
2.3.4.1 VB.NET
VB.Net or Visual Basic.NET is the new version of Visual Basic. This language is
a major part of Microsoft .NET initiative. Responding to pressure from the Visual Basic
community, VB.NET is a significant upgrade that is far more flexible and powerful than
previous versions. Microsoft has introduced a number of new features and moves it to
full object-oriented programming and greatly enhanced web design facilities (Michael,
2002).
VB.NET that is the incarnation of Visual Basic is not completely backward
compatible with previous versions of Visual Basic as it is a complete rewrite of the
software. Previous Visual Basic technology actually has a lot more in common with PHP
but with VB.NET is a complete framework for building web-based applications. One of
the principal features of this language is the flexibility to choose programming language.
VB.NET works with scripted languages such as VBScript, JScript, Perlscript and Python
as well as compiled languages such as C#, C, Cobol, Smalltalk and Lisp (Craig, 2003).
The VB.NET framework also provides for Object Oriented Programming (OOP)
where the inheritance, polymorphism and encapsulation are supported (Daniel, 1995).
The .NET class library is organized into inheritable classes based around particular tasks
such as working with XML or image manipulation.
Besides the programming language, the methodology and database access is a
significant concern. When developer develop the system using VB.NET, integration with
databases can be accomplished through ODBC which provides a consistent set of calling
functions to access your target database. The SPAKE system development has chosen
VB.NET as programming language due to consistency and easiness in integration of the
system to the database (Dianne, 1999).
Beside the consistency and easiness in database integration, VB.NET strength lies
clearly in its clean design and implementation. The language flexibility and with
sophisticated object-oriented features supported makes SPAKE developer chosen this
language. In that sense, it is truly interoperable with every programmer existing skills.
Another strength of VB.NET is the development environment. For instance,
developers can use a community-supported tool, Visual Studio .NET or various Borland
tools such as Delphi and C++ Builder. Visual Studio has been used in SPAKE
development for instance, allows setting of breakpoints, tracing sections of code and
reviewing the call stack. It is a sophisticated debugging environment.
2.3.4.2 PHP
Different from VB.NET, PHP is a scripting language based on the model of
preprocessing HTML pages. When the PHP preprocessor in your web server notices a
PHP language tag, the PHP engine is invoked to execute that code. PHP will be familiar
to any programmers who have worked with imperative programming languages. It has a
similarity with Perl, C and Java. Frankly, Java is an imperative programming language,
but it also makes use of object-oriented constructs and concepts. PHP borrows from this
structure when it is convenient but it is not a pure OOP language (Edward, 1994).
The advantages of the PHP can be found by price of it, developer does not have to
worry about licensing issues. PHP is an open source, so an entire programming
community will keep a close eye on development, identifying bugs and making sure they
get fixed. If there is a feature programmer does not like, they can dabble with the code.
Other than that, PHP has a smaller code path, meaning there's less server-side
code executed to parse and execute your PHP page which results in more efficient
memory and usage and faster execution.
In the discussion of VB.NET above, the ODBC driver integrate the system to the
database. In PHP, you can also use ODBC to integrate the system to databases. The point
that SPAKE developer does not interested in this language is the lack of exceptions,
event-based error-handling instances that interrupt the normal flow of a program where it
will jump your code to a special error-handling section. The programmers still can
manage errors in PHP, but the structure is not standardized, so programmers are left to
their own devices on how to implement error handling, leading to less consistency and a
tendency to reinvent the wheel. Moreover, PHP function names are case insensitive. This
matters make some programmers might find this feature annoying.
CHAPTER III
METHODOLOGY
3.0
Introduction
SPAKE system development is implemented based on RAD methodology and
standard modelling technique in order to assure that the communication between
processes becomes easier to control and maintain. The SPAKE system considers a
number of aspects such as paradigm, methodology, technical requirement and suitable
tools to be used in every phase involved in the development.
This chapter will discuss the methodology and software development used in
SPAKE system. It comprises of the software development process from the first step till
the last step and the usage of software development methodology. Every phase involved
in the methodology used will be elaborated detail.
3.1
Software Process
As discussed in Literature Review, the Rapid Application Development (RAD)
model has been used to develop the SPAKE system. The RAD is a technique for
compressing the analysis, design, build and test phases of a software development project
into a series of short and iterative cycles.
There are four phases involved in RAD life cycle. These phases are used to ensure
that each phase is delivered on time and on budget (Grady, 1996). The phases involved in
RAD are:
3.3.1
i.
Planning Phase.
ii.
Design Phase.
iii.
Rapid Construction Phase.
iv.
Deploy Phase
Planning Phase
The first phase in RAD is the planning phase which is used to make a functional
specification. After the functional specification has been done it will be presented to the
user for specification signoff.
In this sub section, the explanation involving the
techniques used for planning the project is discusses. It will also specify the method that
has been used in the analysis process.
3.1.1.1 SPAKE Requirement Analysis Critical Success Factors
Requirements cover the discovery, documentation and analysis of functions to be
implemented in software. Requirements analysis is a critical activity on any software
project because if developer do not get the requirements right, project will fail no matter
how well they perform in all other activities.
Getting requirements right has proven to be one of the more difficult areas of
software engineering. This is due to requirements analysis being open ended in nature,
the interfaces with many different project participants and the fact that time spent on
requirements is often short-changed based on the mistaken idea that projects should move
on to design and construction as fast as possible.
In SPAKE system development, the requirements gathered from many methods.
The requirement analysis critical success factors for SPAKE system development are as
follow:
i.
Choose the right member of SPAKE team
Some people are great programmers and others are good with people and
have exceptional communication skills. In SPAKE development, team
member with the best people and communication skills used to find and
handling the requirements gathering. He or she needs to be able to meet
with the customer and communicate effectively with a non-technical
audience.
ii.
Meet with the customer early and often
As discussed, SPAKE has chosen a RAD as the project methodology.
Since the JAD needs client work together with the IT technical resources,
it is imperative that they are involved from the inception of the project.
Literally meeting with the client in person and on the phone is a very
important piece of the process which great for confirming and verifying
details and also getting a big picture view of the functional requirements.
iii.
Ask questions
SPAKE system developer is concern in knowing how and when to use
powerful questions to get the client to think in depth about the current and
proposed process. This will not only help project mission but can also
improve the business process.
iv.
Clarify what the system will not do
As important as clarifying what the system will do is being clear on what
it will not do. In addition, it is essential that the SPAKE developer clarify
what the users will do versus what the system itself will do. A good
practice is to clearly indicate the scope and requirements documentation
not only what functionality will be provided but also what will be
excluded. In SPAKE development, use cases and flowcharts can also be
very helpful to illustrate and document process flow while differentiating
roles.
3.1.2
Design Phase
The design process is very important in SPAKE system development. From a
practical standpoint, as a labourer, they would not attempt to build a house without an
approved blueprint thereby risking the structural integrity and client satisfaction. The
emphasis in design is on quality. This phase provides the representation of software that
can be assessed for quality.
During the SPAKE system design process, the software specifications are
transformed into design models that describe the details of the data structures, system
architecture, interface and components. Each design product is reviewed for quality
before moving to the next phase of RAD software development. At the end of the design
process a design specification document is produced. This document is composed of the
design models that describe the data, architecture, interfaces and components.
There is a number of design specification models involved in SPAKE
development such as data, architectural, interface and component level design. These
models help developer in achieving the SPAKE system goals.
3.1.2.1 Data Design
The SPAKE data design created by transforming the analysis information model
including the data dictionary and Entity Relationship Diagram (ERD) into data structures
required to implementing the software. Part of the data design may occur in conjunction
with the design of software architecture. More detailed data design occurs as each
software component is designed.
3.1.2.2 Architectural Design
Architectural design defines the relationships among the major structural elements
of the SPAKE system. It composed of the design patterns than can be used to achieve the
requirements that have been defined for the system and the constraints that affect the way
in which the architectural patterns can be applied. SPAKE system architectural design
derived from the system specification, the analysis model and the subsystem interactions
defined in the analysis model, which is in Flow Chart.
3.1.2.3 Interface Design
The interface design in SPAKE describes how the software elements
communicate with each other, with other systems and with users. The data flow and
control flow diagrams provide much of the necessary information required in interface
design.
3.1.2.4 Component Level Design
As for component level design, it is created by transforming the structural
elements defined by the SPAKE architecture into procedural descriptions of software
components using information obtained from the process specification, control
specification and state transition diagram.
3.1.3
Rapid Construction Phase
In Rapid Construction phase, the system development and testing involve directly
to SPAKE system. In SPAKE system development, RAD used the iteration element in it
development. Therefore, all changes for the system will be rapidly constructed until the
user satisfies the system. At this phase, the prototype of the system may be generate and
present to the client. This phase is complete when the users test the system and signoff
for each iteration made.
During the Rapid Construction phase, all remaining components and application
features are developed and integrated into the product. Beside, all features are thoroughly
tested. There are a number of objectives why the Rapid Construction phase is important
for the SPAKE system. The primary objectives of the Rapid Construction phase in
SPAKE development include:
i.
Minimizing development costs by optimizing resources and avoiding
unnecessary scrap and rework.
ii.
Achieving adequate quality as rapidly as practical.
iii.
Achieving useful versions such as prototype and other test releases as
rapidly as practical.
3.1.3.1 Prototype
The system prototype has been built along SPAKE system development. These
prototype are used to be the dummy system that would be the guidance for building up
the actual SPAKE system.
In SPAKE system development, prototyping in early implementation involves the
implementation of a design specification in a small number of representative pieces of
equipment for the purpose of demonstrating the feasibility of a concept or the correctness
of the specification. Making SPAKE prototype models usually requires modeling
involves hardware as well as software. The use of a SPAKE prototype model is to
validate a standard or set of standards involving the following steps:
i.
A clear agreement is reached on which parts of the standard are to be
modeled in the prototype.
ii.
A full schedule of tests to be performed and the expected results is
prepared and agreed before prototype testing begins.
iii.
Prototype models are built using parts and methods that ensure that the
models are completed as quickly and as accurately as possible within the
constraints of available resources.
iv.
Testing is performed according to the agreed schedule.
Prototyping is likely to be an iterative process where the modifications to the
standard and process as a result of the testing are incorporated into the prototype models
and retested.
3.1.4
Deploy Phase
Once the SPAKE project has been implemented, the Deployment phase will
begin. This phase consists of defining a testing plan that will be used to verify that all
features have been implemented according to the specifications defined during the
Requirements Analysis phase, which is in Planning phase of the project. All defects will
be tracked on the online web-based project portal that the client can view as well as add
defects themselves.
Once the SPAKE system has been tested and verified, developer will implement
the application or deploy the application to the client servers. As for SPAKE project, the
Deployment phase is accomplished with close contact with the client personnel. Beside,
the extensive training is provided to end-users. Historical data is prepared and transferred
into the new information system.
For the SPAKE project, the developer found that the Deployment phase is very
important, since the results of both developer and client teams is tried in a real business
environment. All critical functions are tested before they will be inserted into all
Semboyan bases involved in a real workflow.
The Deployment phase involved in SPAKE system includes the following tasks.
i.
Obtain signoffs whether pilot project will go on or not go on decision.
ii.
Train business and technical customer support.
iii.
Begin pilot deployment to selected Semboyan bases.
iv.
Monitor the pilot project.
v.
Evaluate pilot feedback and initiate change management.
vi.
Obtain signoffs from the client whether deployment will go on or not go
on decision.
vii.
Execute deployment plan.
In SPAKE system development, the deployment phase has 2 main parts, which
are the Quality Testing phase and Delivery and Acceptance phase.
3.1.4.1 Quality Testing Phase
When the development team has tested every module involved in SPAKE system,
the modules are delivered to the Quality Assurance server for integration and Quality
Assurance testing by the Tester.
Based on the comments from Quality Assurance that is from IT technical
resources and client, the modules and related documentation are adapted, retested and
released to Quality Assurance. For example modules may pass through this cycle a few
times between development and deployment in order to attain the required quality.
During Quality Assurance Testing bugs are tracked and logged as a new releases
between development and deployment. At the end of this phase the project has reached
the testing milestone and it is ready for delivery to the client.
3.1.4.2 Delivery and Acceptance Phase
Delivery and acceptance phase happened in SPAKE system development when
the project is installed in the client production environment. Since this is probably the
first time the project functions in its real environment with real interfaces and
connections, a thorough testing is important.
Bugs and problems reported during acceptance testing are collected and resolved.
At regular intervals update releases are installed and regression tested. At the end of the
acceptance the provisional acceptance of the SPAKE system is signed-off, marking the
delivering milestone.
In parallel with the acceptance testing, the documentation is finalized and
technical, administrator, training and user documents are prepared and delivered during
this phase. The signature of the provisional acceptance starts a period of extended
evaluation by the customer. Then the developer begins the maintenance and
administration training for the client with the new system.
3.2
Problem Solving Methodology
There is lots of problem occur during the development of SPAKE system. It is
important to make sure that the system runs smoothly in real system environment.
Problem solving methodology section will describes the problems occurred and the way
that developer used to solved the problem that arises in the SPAKE system development.
3.2.1
Database Optimizing
SPAKE system is a huge web-based system and the system will be implement
throughout Malaysia. In that sense, the database for the system need to be optimized and
minimized to ensure the space available is use effectively. SPAKE developer has
implemented the code involved as representative for certain information such as Gender,
State, Position and Location. Using the database-optimizing concept, the database will
only store the code for each attribute and this would bring an advantage for the SPAKE
system where it will save lots of space in the database. Need to be stated, that the code
has been defined at a first stage to avoid any miss understood if too many codes need to
be store in the database.
3.2.2
Interface Grouping
Usually for each interface, the developer will allocate a related data fields on that
particular interface. The problem arises when there are to many data fields involved in
one interface unit. The space is not enough even when we arrange them accurately. To
solve the problem, SPAKE developer have make a meeting with the client in order to
arrange the only important data fields on the main interface. The sub interface is used
when it is needed. Consultancy plays it roles where developer and client sit together to
discuss the main interface and sub interface in every module involved in SPAKE system.
3.2.3
Programming Error Handling
When SPAKE system programmers make a program for each module, sometime
there are some bugs or errors occur during the program running. Programmers handle the
problem by using the debugger embedded with the Microsoft Visual Basic. The debugger
is used for keep track the error in the system. This technique is efficient because it makes
the system reuse this component every time the debugger trap the errors or bugs occurs.
3.2.4
Filter the Information
There is lots of information need to be filter when a report been generating by
each level of users. The edited page forms also need to filter where there is some part that
certain level of user cannot edit. Therefore, filtering information is the most important
part before the system installation been done by the developer. It is also important to
ensure that certain user would not misuse the data or information involved in SPAKE
system. In order to solve this problem, the developer has to manipulate the SQL
statement based on the requirement gathered in Analysis phase.
3.3
Unified Modeling Language
The Unified Modeling Language or UML has been released by a consortium of
companies led by Rational Software Corporation and was certified as an industry
standard by the Object Management Group (OMG) in November 1997. The UML
attempts to unify the diagrams and to a degree the methodologies of Booch, Object
Modeling Technique (OMT) and Object Oriented Software Engineering (OOSE) (Grady,
1996).
In SPAKE project, UML has been used as a standard language that is used for the
purpose of software development object oriented modeling where it can identify, build
and document the artifacts in a software system. UML has been used for all process
through system development cycle and over assorted implementation. It also enables the
developer to model the system whether logically or physically. In that sense, the SPAKE
model can be represented in a consistent way.
The objectives that SPAKE system make used the UML are to determine the
increasingly and repeating development process. Beside, the UML also used for listing
the phase, product and main activities for every development process phase involved. By
using the UML, some notations and techniques have been used. The notations and
techniques including the Use Cases, Sequence Diagrams, Collaboration Diagrams and
also State Diagrams.
3.4
Documentation Standard
The documentation for all documents involved in SPAKE development is using
the IDIS standard with DOD-STD-2167A. This standard harmonizes to define a set of
activities and documentation suitable for the Malaysian Military Automated Information
System. This standard ensures the compatibility with recent changes in instructions and
standards.
Furthermore, this standard can be applied in any phase of the system life cycle. It
can be applied to contractors, subcontractors or Government agencies performing the
software development.
The standard is not intended to specify or discourage of any particular software
development method. The developer is responsible for selecting software development
methods that support the achievement of contract requirements.
This standard is compatible with non-hierarchical methods. A system is
decomposed into software units, which may or may not be related to each other in
hierarchical manner. Design, testing and configuration management are based on the
developer designated software units. That means, this standard is more flexible in term of
using a methods that best suited to project such as object oriented analysis and design.
CHAPTER IV
PROJECT DISCUSSION
4.0
Introduction
This chapter discusses the overall project discussion during the development of
SPAKE project. The project discussion will describe a brief on project flows in
Maintenance module. Need to be state that the module will not discusses in detail due to
restricted flow and information (the related documentation regarding the project can be
referred to IDIS)
4.1
SPAKE System Features
SPAKE system is introduced to help people form Semboyan Department to keep
communication equipments information instead of keeping them using forms involved in
every process. SPAKE system is actually the transition from manual to paperless
information system. It is easy to use and encourage user acceptance even for those with
no computer experience.
4.2
SPAKE User Interface
For SPAKE system development, user interface of the system is very important.
As discussed, the quality of the interface is one of critical success factor that can impact
the system successes. The reasons that make it very important are that the good user
interface increases the efficiency and productivity of user and reduces error. About half
time and effort in design stage spent on SPAKE interface as well. SPAKE system
interface is designed to make information easy to find and provide the information in a
form which is easy to use.
4.3
Output Analysis
Before the existing of SPAKE system, Ministry of Defense especially in
Semboyan department have to make a request for all processes involving the department
manually by filling a form at their bases. As for traditional and conservative ways, all
information about communication equipments that is requested has to be filled in a form
and submitted to the officer at certain department. The officer then has to manually sort
the request and archive the form into files. By introducing the SPAKE system, the
communication equipments management can be manage through the Internet.
Furthermore, all the information can also be browsed at all time to check the status of
their requested process.
This subsection focuses on the output analysis from every sub module in
Maintenance module that has been done by the author. Every sub module is discussed
detail in term of processes involved. Furthermore, the screen shots are also been shown to
ensure a clear understanding about all processes.
4.3.1 Login
Figure 4.1 : Login Interface
There are several users involved in Maintenance Module. Every user has his/her
own Login ID and Password. Users need to enter their ID and Password in order to use
the SPAKE system. If the user does not enter the correct ID or Password, they are not
allowed to enter the system. Figure 4.1 shows the interface for user login.
In Maintenance Module, people from Receive and Issues (R&I) department,
Workshop, Workshop Quality Control department, Testing Unit and Semboyan
department are involved in all process. They have their own job and authorities to access
the system.
4.3.2 Pembaikan Swasta Sub Module
Pembaikan Swasta or Private Repairing sub module is used when the
communication equipments are not under guarantee and workers from Workshop cannot
repair those equipments. Because of that, the equipments will be sending and distribute to
private sector for repairing.
For the first step, user from R&I department will enter the system because all
communication equipments are actually under their supervision. Figure 4.2 shows the
first screen appear when the R&I user enter the system. After the default screen appear,
they need to click on ‘TAMBAH’ (add new job) link to enter all data for equipments that
need to be repair.
Figure 4.2 : Default Interface for R&I Users
Figure 4.3 : Equipments Chooser Interface
Secondly the R&I will choose the equipments that need to be repaired. In this
interface user also need to choose their Unit name, equipment categories, equipment
name and equipment serial number. Need to be stated that all Units have their own
equipments, when they choose their Unit name, the equipments that they can choose are
only the equipment and serial number under their supervision. From this depended entity,
users cannot simply enter the equipments that are not under their supervision.
Figure 4.4 : Repairing Form
After the R&I user enter the serial number in equipment chooser interface as
shown in Figure 4.3, the system will automatically go to the Repairing Form interface
where the user need to enter all the data for equipments repairing request. After they enter
the field needed, user needs to click the ‘Hantar’ (sending) button where the data will be
stored in the database.
Figure 4.5 : Conformation Repairing Form
After the R&I user press on ‘Hantar’ button, the ‘Ya’ (Yes), ‘Papar’ (View) and
‘Selesai’ (End) button will replace the ‘Hantar’ button. Here, user needs to confirm that
the data enter are correct. If the data enter are correct, the ‘Ya’ button need to be press
and after that the ‘Selesai’ button also need to be press. If user needs to show and print
the report, user will press ‘Papar’ where the report will be preview before user can print
it. Figure 4.5 shows the Conformation Repairing Form.
Figure 4.6 : Default Interface With New Job Status
After the “Selesai” button has been pressed, the default interface will appears
again. Here, the new job will be listed in the data grid. Figure 4.6 shows that there is one
new job listed for Workshop action. Then, the R&I user can logout and wait for
Workshop action. To logout from the system, they need to click “LOGOUT” at the left
side of the toolbar.
Figure 4.7 : Default Interface for Workshop Users
Workers for Workshop are responsible to repair all communication equipments
send by the R&I department. When they login the system the default interface appears
are actually the jobs that need to be done. Figure 4.7 shows the data grid that lists the jobs
for Workshop. Workshop users need to click on the ‘No. Kerja’ (working number) to
access the Repairing Form requested by R&I department user.
Figure 4.8 : Workshop Job Form
When the user click the ‘No. Kerja’ link, job description from R&I will be shown.
Then they need to enter all repairing action taken for that particular job. In Private
Repairing case, Workshop user will select ‘SWASTA’ (privatize) in Repairing drop
down list to privatize the equipments. Workshop user also can print the Workshop Job
Form by pressing the ‘Papar’ button. Figure 4.8 shows the Workshop Job Form that need
to be filled up for every job that they done.
Figure 4.9 : Default Interface With New Job Status
After the “Hantar” button has been pressed, the default interface will appears
again. Here, the new status of particular job will be listed in the data grid. Figure 4.9
shows that the job status has been change to ‘SWASTA’ where it means that the
equipments need to be privatized. Then, the Workshop user can logout and wait for
Workshop Quality Control department action.
Figure 4.10 : Default Interface for Workshop Quality Control User
Next, the Workshop Quality Control department user will login the system to
approve the Workshop job. When the Workshop Quality Control user login, the default
interface will be shown where the data grid of their job are listed. They need to click on
the ‘No. Kerja’ link to access the data enter by Workshop user.
Figure 4.11 : Approval Form
Workshop Quality Control department is responsible to make a comment that
approve the Workshop job. Figure 4.11 shows the Approval Form for Workshop job
description. After the Workshop Quality Control users have made a comment, they need
to approve the form by pressing the ‘Sah’ (approve) button.
Figure 4.12 : Default Interface With New Job Status
After they approve the job, new job status will be shows to ensure the approval
job have been done by the Workshop Quality Control user. Figure 4.12 shows the new
job status has been made after the Workshop Quality Control user approve the Workshop
job. Then, the Workshop Quality Control user can logout and wait for Semboyan
department action.
Figure 4.13 : Default Interface for Semboyan Department
Figure 4.13 shows the default interface for Semboyan department. When the
Semboyan department login the system, the data grid that shows their job will be appear.
Here, the Semboyan department needs to click on ‘Pilih’ (select) link to show their job.
Figure 4.14 : Privatize Information Form
After the Semboyan department user click on the ‘Pilih’ button, the information
of the privatized equipments will be shown. Figure 4.14 shows the example of the
privatized equipment request information. Here, Semboyan department user will press the
‘Laporan Sebut Harga’ button to fill up the price quotation report.
Figure 4.15 : Page One of Price Quotation Report
Figure 4.15 shows the page one of Price Quotation Report. Here the Semboyan
department user needs to fill the basic data for Price Quotation Report. After the user
enter all information needed, they will press the ‘Hantar’ button to fill up the page two of
Price Quotation Report.
Figure 4.16 : Page Two of Price Quotation Report
Figure 4.16 shows the page two of Price Quotation Report. Here the user need to
enter all information about the company interested to repair the equipment with the price
offered. The ‘Jumlah’ (count) button is use to automatically calculate the price offered by
the company. Here, some imbedded formula has been write in the coding part for that
button. All the data will be save in the database when the user pressed the ‘Simpan’
(save) button.
Figure 4.17 : Default Interface With New Job Status
After the ‘Simpan’ button has been pressed, the default interface will appears
again. Here, the new status of particular job will be listed in the data grid. Figure 4.17
shows that the job status has been change to ‘Swasta-Call Pembekal’ where it means that
the Semboyan department user need to call the company that been offered to repair the
equipments.
4.3.3 Pembaikan Dalam Jaminan Sub Module
As for Pembaikan Dalam Jaminan or Under Warranty Repairing Sub Module, the
user for R&I department also need to enter the same process as shown in Figure 4.2 and
Figure 4.3. The different between Privatized Repairing and Under Warranty Repairing
Sub Module is when the R&I choose the equipment for repairing, the system will
automatically pop-up a message shows that the equipment are under warranty. The
example of the pop-up message is shown in Figure 4.18.
Figure 4.18 : Under Warranty Pop-Up Message
Figure 4.19 : Status Data Grid for R&I User
After the pop-up message appears and ‘OK’ button have been pressed, the R&I
user also need to follow the process as shown in Figure 4.4 and Figure 4.5. The different
is after the process involve as Figure 4.5, the status will be change to ‘Jaminan-RNI’
(Under Warranty-RNI) as shown in Figure 4.19.
Figure 4.20 : Default Interface for Testing Section User
Next, the Testing Unit user will login the system to approve that the equipment
repairing request are under warranty. When the Testing Unit user login, the default
interface will be shown such as Figure 4.20 where the data grid of their job will be listed.
They need to click on the ‘Pilih’ link to access the data enter by R&I user.
Figure 4.21 : Approval Form
Testing Unit is responsible to make a comment that approve that the equipment
repairing request are under warranty. Figure 4.21 shows the Approval Form for Testing
Unit request description. After the Testing Unit users have made a comment, they need to
approve the form by pressing the ‘Sah’ (approve) button. The user also can print the
Approval Report by pressing the ‘Cetak’ (print) button.
Figure 4.22 : Default Interface With New Job Status
After they approve the job, new job status will be shows to ensure the approval
job have been done by the Testing Unit user. Figure 4.22 shows the new job status has
been made after the Testing Unit approves the equipment repairing request are under
warranty. Then, the Testing Unit user can logout and wait for Semboyan department
action.
Figure 4.23 : Default Interface for Semboyan Department User
Next, the Semboyan department user will login the system to approve that the
equipment repairing request are under warranty. When the Semboyan login, the default
interface will be shown such as Figure 4.23 where the data grid of their job will be listed.
They need to click on the ‘Pilih’ link to access the data enter by Testing Section user.
Figure 4.24 : Approval Information Form
Semboyan department is responsible to approve the equipment repairing request.
Figure 4.24 shows the Approval Information Form for Semboyan department request
description. Semboyan department user needs to approve the form by pressing the ‘Sah’
(approve) button.
Figure 4.25 : Default Interface With New Job Status
After the ‘Sah’ button has been pressed, the default interface will appears again.
Here, the new status of particular job will be listed in the data grid. Figure 4.25 shows
that the job status has been change to ‘Jaminan - Pembekal’ where it means that the
Semboyan department user needs to call the equipment supplier to repair the equipments.
4.3.4 Lawatan Sengaraan Sub Module
Lawatan Senggaraan or Maintenance Visiting Sub Module is used for make a
report for each maintenance visiting done in every Workshop. Usually maintenance
visiting being done by Workshop Quality Control, four times a year base on date that
being set up by Semboyan department.
To set up the date for each maintenance visiting, Semboyan department need to
login the system and select ‘Lawatan Senggaraan’ item in Senggaraan toolbar as shown
by Figure 4.26.
Figure 4.26 : Senggaraan Toolbar for Semboyan Department
Figure 4.27 : Yearly Date Set Up for Maintenance Visiting Form
After the Semboyan department user click on ‘Lawatan Senggaraan’ item, the
yearly date set up for Maintenance Visiting Form such as Figure 4.27 will appear and
user need to set up the maintenance visiting date for every Workshop Quality Control
department. When the date set up being done, user will press the ‘Simpan’ button to save
the data in the database. Then the Semboyan department users can logout from the
system.
Figure 4.28 : Senggaraan Toolbar for Workshop Quality Control Department
As for Workshop Quality Control department, they need to login to search their
date for visiting the Workshop under their supervision. To do that, they need to click on
‘Jadual Lawatan Senggaraan’ item at Senggaraan toolbar as shown in Figure 4.28.
Figure 4.29 : Searching for Maintenance Visiting Page
After the Workshop Quality Control department user click on ‘Jadual Lawatan
Senggaraan’ item, the searching page for every maintenance visiting date for Workshop
Quality Control will be shown such as Figure 4.29. From the searching page, the
Workshop Quality Control department user can search the dates that have been set up by
the Semboyan department. When the user click on ‘Pilih’ link, the Maintenance Visiting
Report Form will be appear.
Figure 4.30 : Page One of Senggaraan Visiting Form
After the Semboyan department user click on ‘Pilih’ link, the first page of
Maintenance Visiting Form will be appear. Here, the users need to enter the basic data for
the visiting report such as date and inspection members. When finished, the user will
press the ‘Simpan’ button to store the data in the database and press the ‘Seterusnya’
(next) button to go to the second page of Maintenance Visiting Form.
Figure 4.31 : Page Two of Maintenance Visiting Form
After the Semboyan department user pressed ‘Seterusnya’ button, the second page
of Maintenance Visiting Form will be appear. Here, the users need to enter the
equipments checking for the visiting report such as equipments categories and
equipments name. When finished, the user will press the ‘Simpan’ button to store the data
in the database and press the ‘Seterusnya’ button to go to the last page of maintenance
visiting page.
Figure 4.32 : Page Three of Senggaraan Visiting Form
Again, after the Semboyan department user pressed ‘Seterusnya’ button, the third
page of Maintenance Visiting Form will be appear. In the third page of maintenance
visiting page, users need to put some comments in certain matters such as documentation
comment, management comment and overall comment. When finished, the user will
press the ‘Simpan’ button to store the data in the database.
4.3.4 Kecacatan dan Ubahsuai Sub Module
Kecacatan dan Ubahsuai or Defect and Modification Sub Module is used for
achieving all data regarding modification made to every communication equipments
repaired. The archiving is useful for the R&I department because they can use a correct
action for the certain equipment problems.
The Semboyan department is responsible to enter all equipments defect and
modification made. To enter the equipment defect and modification data, Semboyan
department need to login the system and select ‘New Kecacatan dan Ubahsuai’ item in
Senggaraan toolbar as shown by Figure 4.26.
Figure 4.33 : Defect and Maintenance Form
After the Semboyan department user click on ‘New Kecacatan dan Ubahsuai’
link, the defect and maintenance form will be appear as shown in Figure 4.33. Here, the
users need to enter the equipments data regarding to defect found and maintenance taken
for equipments involved. When finished, the user will press the ‘Simpan’ button to store
the data in the database.
Figure 4.34 : Defect and Maintenance Searching Page
The Semboyan department user also can search certain equipments defect and
maintenance. They only need to click on ‘View Kecacatan dan Ubahsuai’ link and the
defect and maintenance searching page will be appear as shown in Figure 4.34. Here, the
users need to choose the equipments name in the drop down list and press the ‘Cari’
(search) button. The list of equipments required and defect type will be listed in the
searching data grid. When the user click on ‘Pilih’ link, the equipment defect and
maintenance data will be appear for their information.
4.4
Related Documentation
In developing the SPAKE system there is numbers of document produced by the
developer. This section discussed the documentations done by the SPAKE developer that
using the Malaysian Military Standard. Need to be stated that the documents cannot be
shown due to the SPAKE confidentiality with the Ministry of Defense Malaysia.
4.4.1
Software Requirements Specification
Software Requirements Specification or SRS is a document that describes the
requirements of a computer system from the client point of view. In SPAKE project, SRS
document specifies the required behavior of a system in terms of input data, required
processing, output data, operational scenarios and the interfaces. Beside, the attributes of
a system including performance, security, maintainability, reliability, audit ability,
availability and safety requirements and design constraints also been discussed in SRS
document.
4.4.2
Software Test Description
The Software Test Description or STD describes the test preparations, test cases,
and test procedures to be used to perform qualification testing of a CSCI or a software
system. The STD enables the acquirer to assess the adequacy of the qualification testing
to be performed in each module in SPAKE system.
4.5
Constraints
In early deployment of SPAKE system, developer has found a constraint that
occurs in SPAKE system. The constraint found in SPAKE system is the system is
developed using the Windows environment. Therefore, the system only suits to Windows
base user only. If there is any requirement from other operating system platforms such as
UNIX and LINUX, the new system development is required.
4.6
Problems
A number of problems have been found when the developers developed the
SPAKE system. The problems detected during the development are:
i.
Pressure of limited time where the developer have to develop the actual
system in one month while the prototype system takes two months of
development. This is happened due to the dateline of the system is to close
to delivery phase.
ii.
Changes of requirements always been made by the client. When the
prototype of the system has been presented to the client, supposedly there
should be no more changes of requirement made by the client but in real
situation the client always changed their requirements. To resolve this
problem, the programmers have discussed to the project manager and a
requirements sign-off has been made at a critical stage of development.
iii.
An unrealistic dateline setting for every phases setting by someone outside
the software development teams also contributed to the pressure of
SPAKE system development. When this matter happened, it has caused a
difficulty in defining the software requirement and in designing the
system.
iv.
Underestimate of the amount of effort and number of resources that will
be required to do the job. Moreover, all programmers job have been
allocated to the practical trainees. This is not right, because the practical
trainees are supposed to help the IT technical resource not as developers of
the system.
v.
Less support from IT Analysts from IDIS because they are busy with
different project. The management has made the decision that the IT
Analysts in SPAKE development have to work with different project.
4.7
Recommendation
To resolve all the problems discussed, IDIS can take the actions that are
recommended as follows:
i.
Time management needs to be concerned on developing the system. IDIS
project leader need to have a clear understanding in which phases need a
long duration of time and which one does not. This is important because
the pressure of time constraint will contribute to the failure of the system
delivery.
ii.
The requirements sign-off needs to be done after the system has been
presented to the client. The developers have to be strict in this matter
because if the requirements are always changing, the programmers may be
confused in their design. The last minute sign-off is not advisable because
it will contribute to time constraint problem.
iii.
The project dateline of every phase need to be done by the project leader
and not the administration personnel. The administration personnel only
need to concentrate in their job and not to plan any dateline for every
phase involved in SPAKE development.
iv.
It is not ethical for a company to use only the practical trainees as their
programmers. Since the practical trainees are only university students and
still learning, it would be difficult for them to develop the huge system
such as SPAKE system. The project manager also needs to allocate
enough manpower in each module to ensure it can be done in allocated
time line.
v.
IT Analysts need to concentrate in one project at a time. If they can
concentrate only in SPAKE development, the system development phases
can meet the dateline allocated.
CHAPTER V
CONCLUSION
5.0
Introduction
The industrial attachment or industrial training is a way to maximize the
synergistic relationship between universities and industries. This relationship has given
lots of advantages to students and industries themselves. By placing students in the
industry, students would gain knowledge that sometime did not being taught in
universities while industries may channel their expertise to universities. As we know,
software engineers must be prepared to deal with advanced technologies and by having
the industrial attachment, students would benefits themselves in this aspect. Besides,
industrial exposure also would prepare students to accommodate themselves to work with
other disciplines and also to accept new engineering disciplines.
Every minute, the information technologies and knowledge takes on a new
dimension, to ensure the university students prepared in this fast changing environment,
industrial exposure will able changes the students mindsets to not only use the technology
provided by software but also be a creators who will develop the original local software.
In this last chapter, the author will share the lesson learn and comment in SPAKE
project.
5.2
Lesson Learnt
During the project duration, lots of software engineering experience has been
gathered in IDIS. The theory lessons learnt in universities combined with practically
works in IDIS have matured the author in term of experience in software engineering.
This experience gained is valuable for the author and may be used in his careers. The
numbers of experiences have been identified as follow:
i.
The developers must work in a team. The teamwork makes the
development better because more ideas may be gained from each member
of the team. The brainstorming from teammates may ensure that the right
decision will be taken for a certain matters. Need to remember that
sometimes the problems that we cannot solve can be handle by another
members of the team.
ii.
In order to solve big problems, developers are actually having lots of
method to solve them. They can refer to programming books, implements
try and error technique, surfing the programming web sites and join the
discussion forums via Internet to get the solutions for that problems. By
using this methods, developers may convenient themselves to get the best
solutions for the problems because the sharing expertise element provided
by Internet is helpful for software engineers.
iii.
Programmers need to manage their work properly. It is advisable to
accomplish the development phase before the dateline. This is because,
extra time may be need to used for debugging a minor error before the real
testing phases take place.
iv.
Communication between developer and client makes strong relationship
among them. Beside, the communication between programmers also
important to ensure the harmonize working environment may achieve.
v.
In this industrial attachment, lots of new technologies have been learnt.
The exposure of Microsoft Server 2000 and .NET platform is a most
valuable experience that never been taught in universities. This experience
may be useful for the author’s future careers.
vi.
Proper project management is most important things in system
development. Proper planning and risk management is discussed among
the SPAKE team members to ensure the process development successes
can be achieved and the system can be sustainable for a long time period.
5.3
Comments
The author believes that the objective for doing a project in industrial
environment and the expectation from Center of Advanced Software Engineering to
produce the quality software engineer is successful. Within five months of industrial
attachment, students have gain lots of experience in real life of software development.
The experience gain may help the students to maintain themselves when they enter the
working environment.
REFERENCES
1.
Craig, B. and Johnson, S. Microsoft Visual Studio .NET 2003. USA: Microsoft
Press. Feb 12, 2003
2.
Daniel,
T.R.P.
Object
Oriented
in
Application
Development.
The
Benjamin/Cummings Publishing Company Inc. 1995
3.
Dianne, S. Visual Basic Developer’s Guide to SQL Server. San Francisco : Sybex.
1999
4.
Edward, Y. Object Oriented System Design – An Integrated Approach. Prentice
Hall Inc. 1994
5.
Grady, B. and James, R. The Unified Modeling Language User Guide. Addison
Wesley. 1996
6.
Grady, B. Object Oriented Analysis and Design with Application. Addison
Wesley Longman Inc. 1994
7.
Hans, V.V. Software Engineering Principles and Practice 2nd Edition. John Wiley
and Sons Ltd. 1997
8.
Michael, H. Microsoft Visual Basic.NET Step by Step. Redmond Washington :
Microsoft Pres
9.
s. 2002
Turner, R. Software Engineering Methodology. Reston USA : Reston Publishing.
1984
10.
Wayne, S.F. Hands On SQL Server 7 With VB6. Singapore : Pirma Tech. 1999
11.
William, J.O. Visual Basic Application. Livermore, California : SAMS
Publishing. 1995
APPENDIX A
Position / Role
Responsibility
Project Manager
x Allocates resources for all programmer and IT
Consultant.
x Establishes a set of practices that ensure the integrity
and quality of project artifacts.
x Ensure the team’s progress is in accordance with the
planned activities.
x Ensure equal usage of resources for the project.
x Guides the project team in achieving the project’s
vision and goals.
A: Roles and Responsibility
APPENDIX A (CONT…)
Position / Role
IT Consultant
Responsibility
x Involves in meeting with clients to analyzing
problems, determine requirements, planning
timescales and the resources needed, making
recommendations and developing agreed solutions.
x Identifying configuration items and associated
documentations.
x Designing, testing, installing and monitoring new
systems.
x Preparing documentation and presenting progress
reports to customers.
x Liaising with staff at all levels of a client organization
the configuration.
x Defining software, hardware and network
requirements.
x Presenting solutions in written or verbal reports.
A: Roles and Responsibility
APPENDIX A (CONT…)
1.1.1.1. Responsibility
Position / Role
IT Analyst
x Applies the principles and techniques of computer
science, engineering and mathematical analysis to the
design, development, testing and evaluation of the
systems.
x Analyzes user’s needs and design.
x Create and modify software applications.
x Produces definitions, process flow documentation,
rules and instructions as a basis for the work of
designers and programmers.
x Uses data modeling to generate different possible
solutions as a means of finding the best one for the
client.
x Responsible for one or more design packages or
design subsystems, including any classes owned by
the packages or subsystems.
Programmer
x Support analysis, design and programming of systems.
x Keep the customer involved once the coding begins.
x Capable of managing an entire project from to finish.
x Write clean, well-engineered code that is readable,
adequately commented, robust and adheres to
standards.
x Solicit feedback on features of the site as soon as they
are available.
A: Roles and Responsibility
APPENDIX B