The Importance of a Software Development Methodology in IT Project Management: An Innovative Six Sigma Approach - A Case Study of a Malaysian SME Organization

Abstract

An adoption of a software development methodology (SDM) has always been perceived to be a useful and helpful framework which helps the project team to structure, plan and control the development of IT Processes, Products and Services. There are a wide variety of SDMs. A SDM adopted in one industry is not necessarily suitable for use in other IT projects. Each SDM is best suited to specific kinds of projects that will put the business in the best possible position to be competitive. This research aimed to lay out the evolution of an SDM for a small-medium enterprise (SME) in Malaysia to better manage scarce resources, control and track IT projects using the Six Sigma approach. A Six Sigma case study was carried out at a software services and consulting company (Syndes Technologies Sdn Bhd) to explore how evolution (from V-Model to W-Model) and customization of SDM can achieve optimum resource utilization in the context of IT project management.

Full text

The Importance of a Software Development
Methodology in IT Project Management: An
Innovative Six Sigma Approach
A Case Study of a Malaysian SME Organization
Whee Yen Wong1, Chan Wai Lee2, Kim Yeow Tshai3
Department of Mechanical, Materials & Manufacturing Engineering
The University of Nottingham, Semenyih, Malaysia
keyx1wwn@nottingham.edu.my1; Chan-Wai.Lee@nottingham.edu.my2; Kim-Yeow.Tshai@nottingham.edu.my3
Abstract—An adoption of a software development methodology
(SDM) has always been perceived to be a useful and helpful
framework which helps the project team to structure, plan and
control the development of IT Processes, Products and Services.
There are a wide variety of SDMs. A SDM adopted in one
industry is not necessarily suitable for use in other IT projects.
Each SDM is best suited to specific kinds of projects that will put
the business in the best possible position to be competitive. This
research aimed to lay out the evolution of an SDM for a small-
medium enterprise (SME) in Malaysia to better manage scarce
resources, control and track IT projects using the Six Sigma
approach. A Six Sigma case study was carried out at a software
services and consulting company (Syndes Technologies Sdn Bhd)
to explore how evolution (from V-Model to W-Model) and
customization of SDM can achieve optimum resource utilization
in the context of IT project management.
Keywords—Software Development Methodology, Six Sigma,
SME Malaysia, Resource Utilization, V-Model, W-Model.
I. INTRODUCTION
Project delays are amongst the most common problems
faced by most IT projects. According to a Standish group study
in 2009 [1], 32% of all projects are delivered on time and on
budget, 44% were challenged late or over budget, while 24%
failed are cancelled prior to completion or delivered and never
used. On top of this, nearly one-third of all IT projects
commenced would be an average of three months late. In many
cases, the failure is the result of either not using a methodology
or using the wrong methodology [2]. Therefore, nearly three
quarters of all IT projects suffered from one or more of the
following: total failure, cost overruns, time overruns, or a
rollout with fewer features or functions than promised [3].
SDMs are always concerned with the activities involved
during the project life cycle in delivering the end result (i.e. IT
Processes, IT Services and IT Products) within schedule,
budget and meeting requirements. There are many SDMs
available and each methodology takes a different approach to
developing software. Among them are the waterfall model,
rapid application development (RAD), and joint application
development (JAD), all of which follow a series of prescribed
steps. Without a methodology, it is extremely likely that
something will be overlooked, omitted, or improperly linked to
the rest of the system.
The key differences between these methodologies are to do
with the way how the development activities among the Project
Life Cycle (PLC) balance features against limited resources.
More specifically, different methodologies suit different types
of teams, software and business environments. Therefore, it is
vital to customize the SDM in particular if the existing
methodologies result in too much rework, schedule slippage,
scope creep, increased number of reported high-impact bugs,
etc.
In this paper, an in-depth analysis of existing SDM for the
case company was carried out to highlight its ineffective and
inefficient in resource allocation by adopting and implementing
the Six Sigma DMAIC (Define, Measure, Analyze, Improve
and Control) approach as quoted in “The Roadmap and Tools
of Six Sigma” by Pande [4]. Six Sigma is a structured
knowledge-acquisition approach which provides a well-
rounded quality improvement methodology (QIM) allowing
the research team to further explore opportunities in
customizing the case company’s SDM to aid its operational
improvements with limited resources. The quality focus for IT
projects should target every stage of the PLC as cost-of-
correction at the latter stages of the project could possibly
costing 20-times more than at the initial stage [1].
II. CASE COMPANY BACKGROUND
The case study company is an independent provider of
network and data management tools and services in Malaysia.
It is a software services and consulting company that offers the
core benefits of knowledge, technology and best practices in
the capacity of a solution provider. The case company falls into
the category of “Small Enterprise” [5, 6] and its’ main focus is
on defining, optimizing and aligning their clients business
strategy with IT initiatives; at the same time striving to assist
clients to build robust business architectures, reliable and
scalable infrastructures that meet the mission of clients’ critical
systems.
In the past three years, the case company has completed a
few projects covering different areas of technologies such as
Human Resource Management System (HMS), Fleet

Management System (FLM), Website Portal, WiFi and WiMax
related applications and performance tools etc. The “big
picture” of the case company’s business and cross-functional
activities can be described in a broader overview using the
PLC. PLC refers to a logical sequence of activities (initiation,
planning, execution, monitoring, closure or exit) to accomplish
the project’s goals or objectives [7].
Regardless of scope and complexity, every software
development required to go through a series of stages during its
life cycle. The System Development Life Cycle (SDLC) aims
to produce a high quality system that meets or exceeds
customer expectations, reaches completion within time and
cost estimates, works effectively and efficiently in the current
and planned Information Technology infrastructure, and is
inexpensive to maintain and cost-effective to enhance.
The business nature of the case company is heavily
resource-driven and IT-focused. The support processes rely
heavily on human resources (developer, technical staff,
business lead, technical lead, project leader, project manager
etc.) in supporting all its core processes. As a result, the case
company is constantly under pressure to better manage scarce
resources and faces a critical need to maximize existing
resource utilization. At the current stage, the case company has
segmented its resources in the manner as shown in Fig. 1 and
adopts an operation framework where different resources are
assigned to different phases throughout the PLC.
Fig. 1 SDM of the Case Company
Figure 1 outlined the phases involved in the SDLC as part
of the PLC. During the Execution phase, the operational
activities of the case company include (not in a chronological
order as it greatly depends on the characteristics and nature of
the IT project): (1) System Infrastructure – responsible for
designing and analysis of infrastructure consisting of
infrastructure setup and as a solution provider covering
virtualization and failover; (2) Database – constitutes of
database designing and planning where stored procedure are
produced and creating SQL jobs; (3) System Core – the heart of
the system where system framework is designed and
developed; (4) System Integrator – the building hub of business
logics. This is the place where business logic and user interface
are integrated under a single system platform; and (5) System
Interface – a critical phase for testing user friendliness where a
user interface layout template will be designed and developed.
III. SIX SIGMA DMAIC PROCESS
A. Define Phase
The scope of activities in the Define phase is to analyze and
investigate IT operational processes (i.e. Project Management
methodology) to minimize redundancy, rework, budget
overrun, resource under-utilization and schedule slippage for
upcoming IT projects. It aims to find out the mistakes, risks
and lessons learnt from the past completed projects; and to
explore potential improvement opportunities for up-coming
projects. The outcome of the preliminary analysis on resource
utilization collected via interviews (structured and semi-
structured) and focus groups with the Managing Director
(MD), Software Architect and Team Leaders shown that: (1)
Majority of the past IT projects do not deliver on time; (2)
Despite proper planning, cost overrun, rework, scope creep and
bugs after bugs are the common challenges of the case
company; (3) There exist gaps between planned and actual
performance.
The next step is to identify Critical-To-Quality (CTQs) as a
result of poor resource utilization. The preliminary
investigation creates awareness among the project teams and
the negative quality-related consequences of “Resource
Allocation Defects” would be the core CTQ in this case study.
B. Measure Phase
The case company is an IT Service Provider which is
heavily involved in IT product (software) development.
Software quality has been the main concern especially to the
development team and it has always been an exceptionally
difficult topic to define [8]. However, software quality can only
be measured after customers put the system into use; any
corrective actions after system implementation cost 20-times
more than the initial stage [1]. Therefore, the authors are
focusing on factors which affect the outcome of software
development and software production of the case company.
The case company experienced a lack of document version
configuration for most projects, the data collection involved
retrieving and analyzing data/documents from archives of past
projects.
The line chart of “Level of Changes Made to System
Requirement specification (SRS)” (Fig. 2) and “Project
Delivery Performance” (Fig. 3) showed a consistent line
pattern and this means that there exists a strong linear
relationship between these two variables. When a scatter
diagram was plotted using this pair of two variables, the
authors observed a positive correlation between them. The
observation concluded that an increase in percentage of
“Changes to user requirements” will result in an increase in
days taken to deliver a project. This concludes that
“Percentage of changes to user requirement” is an important
factor contributing to project performance.
The next step is to perform six sigma calculations on
software quality defects and delivery defects. Since it is
common that many ordinary businesses actually operate in

between two to three sigma performance [9], any business
performing below two sigma may require special attention as a
means to improvement. The calculated 0.774 sigma in software
quality indicated that the case company required immediate
attention to streamline its investigation into root-cause analysis
contributed to high-severity in software quality defects. This
reflects a significantly high percentage of 77.5% of total
reported bugs which required immediate and ad-hoc attention
where re-shuffling of technical staff(s) was necessary to give
priority to fix the bugs within shortest time-span possible
(normally within two hours from the time the bug was
reported).
Fig. 2 Project Delay (%) By Project
Fig. 3 Changes To SRS (%) By Project
On the other hand, the overall project delivery performance is
disappointing where five out of eights projects were reportedly
delayed with a computed sigma level of 1.181. In summary,
there is only 38% chance that case company project will be
delivered on time; other delayed projects were observed with
high percentage of SRS changes where only minimal time was
spent on planning the project. Therefore, there is an urgent
need to investigate “changes to SRS as an important factor
contributing to project delay”.
C. Analyze Phase
Despite data observation in the measure phase, the authors
opted to further the investigations into the workflow processes
using a high-level process map, input-process-variables process
map as well as looking into the case company’s operational
framework and ways of resource allocation. The main
objectives are to ensure all incidents are investigated and root
causes are identified. In support of the investigation, the
authors aim to find out the root-causes contributing to SRS
changes which have a positive relationship with project
performance.
The team started with a brainstorming session with the case
company’s technical and support teams and the possible causes
of defections or hypotheses are: (1) Most of the IT projects are
delayed due to existence of SRS changes; (2) One of the
possible reason to SRS changes could be the way resources are
assigned throughout the PLC; (3) Tendency of the project team
to omit or prepare brief project documentation during the PLC;
(4) Lack of planning during project start-up; and (5) Despite
project delays, the project team faces significant rework from
the large number of reported bugs.
In view of the results obtained related to “changes to SRS as
an important factor contributing to project delays” from the
Measure phase, the research team decided to focus the analysis
on the impact of resource utilization as a result of the case
company’s Software Development Model as shown in Fig. 1.
We can observe from Fig. 1 that there are a total of THREE
groups (green, blue and pink) of full-time employees (FTEs)
involved in the PLC, with each handling different phases at
different time frame. Blue-team is the dominant group at the
start of the project in System Analysis phase; as well as in the
Testing phase. During the System Analysis phase, analysis of
user requirements will later be transformed into SRS. The
Blue-team will then prepare a draft schedule to be used by the
Green-team and Pink-team as a baseline to benchmark in
project scheduling and budgeting. Green-team consists of
technical staff who carry the development responsibility in the
execution phase where the product/service is actually
“produced” or “developed”. Since the Green-team is the sole
FTEs that know the complete architecture of the end
product/service, they are the best candidates for deployment
and implementation. On top of these two groups, there exists
the Pink-team given the responsibility as “Software Quality
Assurance (SQA)” for verifications of user requirements in
SRS against the end product.
It can be observed that the current way of resource allocation
is obviously lacking of FTEs continuous involvement in the
PLC. The Blue-team which was assigned to gather user
requirements are not involved in the development phase. As a
result, SRS information especially related to business-
knowledge was not systematically documented and
transformed into SRS. The next in-line group (Green-team) is
executing the project solely based on individual assumptions
and doubts from the aspects of client business operations and
knowledge. Hence, the introduction of different teams handling
different project tasks throughout PLC is indeed an unhealthy,
inefficient and ineffective way of resource utilization.
According to Schwalbe [1], it is important to create
awareness among the PM/PL about the importance to embark
on ‘continuous’ client’s business and operational knowledge
within the project team throughout the PLC. This “continuous”
effort is important to broaden crossed-team knowledge sharing
among technical and support teams throughout different phases
of PLC specifically for projects duration which normally
exceeds 3 months. Therefore, this ‘continuous’ effort is vital
especially during the project startup where SRS is an iterative
task where changes and updates are required to be completed
before the start of the execution phase. By doing so, the team is
producing “what suits the customer” but not “what the project
team can do”. As a result, most of the completed tasks in the
execution phase did not comply with SRS which led to further
rework. The “finger-pointing war” was declared between the
Blue-team and Green-team where “corrective actions” are

needed in SRS processes, Database Design, System Core,
System Integrator, System Interface as well as all the related
system documentations and system specifications. The matter
get worsens as the Pink-team only comes into the picture
during the PLC when both coding and testing has completed.
Another round of major modifications is expected which leads
to further erosion of team morale. This ineffective and
unproductive way of resource allocation has proven a failure
when Project-B encountered 30% changes in SRS, 10 weeks of
delays in project delivery and 100 high-impacting bugs
reported.
In view of the Software Development Mode, the case
company is adopting the Modified Waterfall model, which is a
step ahead of the traditional Waterfall approach. However, this
“modified model” uses the same phases as the pure waterfall
approach where it does not adopt the resource allocation in a
continuous basis throughout the PLC. As a result, the lack of
inter-dependencies between tasks/activities among phases
throughout the PLC created problems; which in turn led to
rework, project delays, cost overrun and changes to
requirements.
In the real-world of IT development, however, one can
discover issues during the database design or system core
stages that point out errors or gaps in the user requirements.
Although this modified waterfall method allows the case
company to return to an earlier phase; this involves costly
rework and affects team motivation. The problems with the
case company Software Development Model created an
awareness of needing to adopt a new software development
model which would allow better planning in resource
utilization in return for minimizing the occurrence of SRS
changes.
D. Improve Phase
Upon completion of the Analysis phase, the team produced a
list of possible actions and ideas addressing the root causes.
The team shared the possible actions and/or ideas with the MD
and the shortlisted suggestions includes ways to improve the
efficiency and effectiveness of operational flow of project
management in better resource managing, controlling and
allocation among team members.
In view of the importance of continuous business knowledge
sharing among the team members from the start of the project,
it is always a productive measure having fixed or the same FTE
involved from the start of the PLC towards the project
execution phase. In Fig. 5, Blue-team (i.e. Red-A and Blue-A)
are the two FTEs who are involved from the start of the PLC in
gathering user requirements, project planning and scheduling,
project development, testing, deployment as well as
implementation. This way of “continuous” business knowledge
sharing among the team members has indirectly eliminated
task redundancies as well as assumptions in understanding
client’s day-to-day operational activities. As a result, rework is
minimized, team motivation is encouraged and team morale is
improved. These overall factors have a close relationship with
work performance and work productivity. The project quality
matters will be overseen by the same Blue-team and/or the QA
staff (Red-D). QA responsibility should be a continuous effort
throughout the PLC; as a development task is made up of
several smaller manageable tasks.
It is believed the V-model will improve the product/service
delivery performance; at least shortening project delays and
most importantly targeting to reduce quantity of high-impact
bugs. The V-model allows the flexibility of resource allocation
between phases in the PLC. In the event where more resources
are needed in the execution phase, the case company has the
freedom to add-in any developer(s) either experienced or in-
experienced; as the model has a minimum of ONE FTE (i.e.
Red-A or Blue-A) who are aware of the overall project status
and health. Even though allocating an inexperienced team
member does NOT burden or affect the project schedule, the
assigned team members only need to carry out the task as
specified in the system specifications or functional
specifications. In short, transparency of staff dependencies has
increased and the team member’s mobility among different
projects is now improved with little impact on overall project
performance.
Fig. 4 Customized V-Model
Action Plan 1: From V-Model to W-Model. Despites the V-
model’s weaknesses in its rigidity, inflexibility and the expense
in coping with scope of adjustments, it is important to note that
the V-model has evolved over time and supports flexibility and
agility throughout the development process [10]. As such, the
research team is proposing a W-Model, a model invented by Dr
Andrea Spillner, a German professor at the Hochschule
Bremen [11]. The W-model was derived from the V-Model
(Fig. 4) retaining the same advantages of the V-Model and thus
providing the importance of testing and a clearer sequence of
the individual activities for testing.
In this improvement project, the research team has
identified the following weaknesses of the initial SDM of the
case study company (Fig. 1) which need to be addressed
carefully in the proposed model to minimize negative impact
on end product delivery:
 Obvious business and technical knowledge gap
between system analysis and execution phase
 Business knowledge acquired during system analysis
are not shared throughout PLC

 Non-continuous staff allocation throughout PLC. Each
phase is assigned with different group of resources.
 Team members perform tasks based on assumption
In view of the lack of “connectivity between phases”, the
existing operational model of the case company can be
customized and adjusted to V-Shaped (Fig. 4) and then to a W-
Model (Fig. 5). With the expansion of V-Model to W-model,
there is no change to resources allocation, i.e. it is still the same
Blue-team (Blue-A and Red-A) with an additional staff (Red-
B) in the execution phase and a QA staff (Red-D) throughout
the PLC. The W-Model attempts to address shortcomings in
the V-Model. Rather than focus on specific dynamic test
stages, the W-Model focuses on the development products
themselves. Essentially, every development activity that
produces a work product is shadowed by a test activity. The
purpose of the test activity is to determine whether the
objectives of a development activity have been met and the
deliverables meet its requirements. The respective testing phase
parallel to the development process is carried out in a tighter
sense. This is to ensure that output from each phase is validated
before passing as an input to the next phase. In its most generic
form, the W-Model presents a standard development lifecycle
with every development stage mirrored by a test activity [12].
Fig. 5 Customized W-Model
Action Plan 2: Broadening Crossed-Team Knowledge
Sharing. In order to further justify the efficiency and
effectiveness of resource utilization with the proposed W-
model, the team performed an analysis of team knowledge
sharing among the available resources as in Fig. 1. Table I
outlines the resources utilization and knowledge sharing
between the current Software Development Model against the
proposed W-Model. Since the customized W-Model is more
effective and efficient in resources allocation and knowledge
sharing as compared to existing SDM, the W-Model has three
FTEs being 100% utilized whereas a developer/programmer is
33.33% involved in product development. Though this person
(Red-B) is not 100% involved in the PLC, he/she is 100%
involved in product development. In contrast, the existing
SDM for the case company involved six persons where “all”
are underutilized (5 persons with 33.33% utilization and 1
person with 16.67% utilization). None of the resource has full-
time involvement in the PLC and this creates a “knowledge
gap” and/or “non-continuous” knowledge sharing among team
members, which further complicates the testing and QA
activities. Rework arises as team members are required to
“pick-up” project status midway and have a steep learning
curve.
It is often the case that many IT organizations go on for years
misusing, underutilizing, or even over utilizing their resources.
Therefore, it is important for the case company to achieve
optimum utilization of available resources. This leads to
efficacy in project management as the project manager could
optimize the allocation of technical experts, business analyst in
according to their skills, knowledge to avoid wastage. Besides,
it is important to realize that there exist a minimum “cost”
associated with the learning curve; and yet we are unable to
expect optimum performance from the team members.
Therefore, it is always wise to keep “cost to learning curve” to
minimum by strategizing available resources efficiently and
effectively into projects.
TABLE I. Team Knowledge Sharing and Resource Utilization
Current Crossed Team Knowledge Sharing and Resource Utilization
Resources
Planning
Requirement Analysis
Design
Testing
QA
Implementation
Red-A (33.33%)
Blue-A (33.33%)
Red-B (33.33%)
Red-C (33.33%)
Blue-B (33.33%)
Red-D (16.67%)
Total Resources : 6 persons ; Resource Utilization: 5 persons 33.33% ; 1 person 16.67%
Proposed Crossed Team Knowledge Sharing and Resource Utilization
Planning
Requirement Analysis
Design
Testing
QA
Implementation
Red-A (100%)
Blue-A (100%)
Red-B (33.33%)
Red-D (100%)
Total Resource: 4 persons ; Resource Utilization : 3 FTE 100% resource utilization ; 1 person 33.33%
In order to investigate the effect of the proposed W-model for
the case company, this methodology was applied on two projects (Project-X and Project-Y). Project-X is a software
extension (Phase-II) of Project-B. Project-Y is a new project

where the research team benchmarked its’ project achievement
against the basis of 8 projects. Project-X kicked off in February
2013 and Project-Y was initiated in October 2012. Following
adoption of the W-Model, the case company assigned a full-
time business lead and a full-time technical lead throughout
PLC for both projects. An additional technical staff is assigned
(i.e. Project-X with one FTE and Project-Y with two FTEs)
during the product development phase to ensure and transform
business ideas into viable system.
In summary, Project-X and Project-Y have improved
resources utilization of the business lead and technical lead to
100% as compare to 33.33% previously. Quality Assurance
Testing is now a continuous task throughout the PLC; not
limited to the end of the PLC. To-date, only 5% SRS changes
was reported in Project-X as compared with 40% in Phase-I;
showing an improvement of 87.5%. Similarly, Project-Y only
required 6% changes to SRS as compare to an average of 24%
in the past (based on historical data of 8 projects). Most
importantly, the adoption of the W-Model allows the project
team (business lead and technical lead) to have a hands-on
approach with project sponsors and they are in a better position
to deliver an end product which fits the sponsors’ business
needs. As a result, the case company has established a highly
motivated project team, who are reliable, responsible and
trustworthy in handling the entire project. In particular, the
adoption of the W-Model allows the management team to
spend more time (60% as compared to 30% in the past)
exploring business opportunity locally as well as regionally.
Other positive project implications as a result of better resource
utilization are:
 The gap between business knowledge and technical
knowledge among the business and technical leads has
been reduced. The Business Lead is now capable of
handling some technical issues confidently and
independently; and vice versa for the technical lead.
 All user requirements are carefully analysed and
recorded into the SRS which was mapped into the
project schedule. The team handling the SRS is the
same team executing the SRS. A sense of ownership
was established among the project team which further
cultivates team motivation.
IV. CONCLUSION
Six Sigma is a business management process that provides
tangible business results to the bottom line by continuous
process improvement and variation reduction. Although Six
Sigma originated from the manufacturing industry, for the past
decade Six Sigma has proven its great potential in other
industry areas such as banking, healthcare, internet service
provider etc. The capability of Six Sigma as a proactive and
consistent data-driven approach has allowed the team to drill-
down to the root causes of problems by analyzing the software
development methodology of the case company which proved
to be inefficient and ineffective in terms of resource utilization
for its business activities. Because Six Sigma is a statistical
based problem-solving methodology which delivers data
(Measure phase) to drive solution, a dramatic bottom-line
result of customized SDM was achieved.
In the world of IT, handling defects and problems in software
development projects is a difficult task. Most of the time,
organizations may ended up making bad decisions and
problems are left unsolved; or it can even be aggravated by
rework, employees become de-motivated and there is a lack of
work satisfaction. Many companies have spent a huge amount
of their budget on finding, and adopting a software
development methodology that can improve its product,
service or process quality. Therefore, the case company
inevitably places great emphasis on managing quality as its
needs to focus and direct its resources, money and time on a
software development methodology which drives operational
excellence.
The proposed of W-Model is by no means a substitute for
sound project management but rather as a guideline which best
suits the case company with its limited resources. The W-
Model has its advantages and disadvantages too; and it is
always worth remembering that newer methodologies draw on
those that came before them. This improvement in resource
allocation is proven and demonstrated by coupling Six Sigma
DMAIC approach into the SDLC of a project life cycle. This
success should be viewed as a continuous effort especially if
there exist a change in business directives, resource volume
and level of project hierarchy. As a means of continuous
improvement initiatives, Project-X and Project-Y will be
monitored throughout the PLC to ensure the effectiveness and
efficiency of W-Model in coping with limited-resources.
REFERENCES
[1] K. Schwalbe, Information Technology Project Management, 6th ed.
Boston, MA: Thomson Course Technology, 2009.
[2] T. Hoffman, "Value of Project Management Offices questioned," in
Computerworld. vol. 37, 2003, p. 7.
[3] S. Berinato, "The Secret to Software Success," 2001.
[4] P. S. Pande, R. P. Neuman, and R. R. Cavanagh, The Six Sigma Way;
How GE, Motorola, and other top companies are honing their
performance. New York: McGraw-Hill Companies, 2000.
[5] S. S. Shahawai and R. Idrus, "Research Methodology for Assessing
Malaysian SMEs perspective on ERP," in Third Asia International
Conference on Modelling & Simulation, 2009.
[6] SMECorp, "Productivity Performance of SMEs," National SME
Development Council, Kuala Lumpur, Malaysia 2007.
[7] J. T. Marchewka, Information Technology Project Management :
Providing Measurable Organisational Value, 4th Ed ed.: John Wiley &
Son, 2011.
[8] http://www.compaid.com/caiinternet/ezine/Capers-Defining-2.pdf,
"Software Quality ": The Computer Aid Inc
[9] http://www.businessballs.com/sixsigma.htm. vol. 2011.
[10] R. Turner, "Toward Agile Systems Engineering Processes," 2007.
[11] A. Spillner, "From V-Model to W-Model – Establishing the Whole Test
Process," in Proceedings Conquest: 4th Conference on Quality
Engineering in Software Technology, 2000.
[12] S. Gaur, "From V-Model to W-Model." vol. 2012: Software Test
Analyst and Consultant, 2007.