System Development Methodologies
a framework for
comparison
MSIS 488 - Information Systems Analysis - Fall,
2002
By
Abdellatif Benzzine
Table of contents
Introduction
System
development methodology
Components of
a methodology
Criteria for
system development methodologies comparison
Comparison
of the waterfall methodology and SCURM methodology
Conclusion
References
The purpose of this
paper is to define what a system development methodology is? and determine a
framework for the comparison of any two system development methodologies. This
framework will determine the criteria for comparison of any given methodologies.
First, we will well define a system development methodology, its major
components and its main purpose, then we will list the criteria for the
comparison study. In this paper we have the compariosn of two methodologies as a
case study of two broads categories of system development methodologies, the
waterfall and SCRUM.
Table of
contents
System development methodology
In the
following section we will focus on the definition of a system development
methodology and give some background information on the essence of system
development methodologies.
The whole purpose of system development is the
enhancement of the productivity of the organization and the group of people
working in that organization, as system development got bigger there was a need
to systemize the process of system development and come up with a set of steps
that are required for any system development.
The system development life
cycle is a common methodology used in all most every organization, as the system
development projects got bigger and the discipline of software enginnering begun
to set some standards ot its own a lot of methodologies have seen light and were
put together by organizations seeking success according to their own measurement
of success.
Before we get to further details about various system
development methodologies, we would like to give a basic definition of a sytem
development methodology. it's " a standard process followed by an organization
to conduct all the steps necessary to analyze, design, implement, and maintain
information systems" [1]
A methodology is also defined as follows " A
method describes the activities involved in defining, building, and implementing
a system; a method is a framework. Since a method is a logical process for
constructing systems (process), it is known as a metaprocess (a process for
modeling processes). [2]
The
definition does not mention the reason why the organizations want to follow
those steps in system development, but it seems very obvious that one of the
goals was to facilitate tracking problems whenever they might occur, and build
better and successful systems.
Table of
contents
As stated in the
definitions above, the methodology is a process, a set of steps to follow in
system development, it varies from organization to organization. But the main
components of a methodology are the same. Among the components are tools ande
techniques used in all phases of the development of the system.
A
methodology has micro and macro components. The macro components define the
overall flow and time-sequenced framework for performing work. The micro
components include general design rules, patterns and rules of thumb. General
design rules state properties to achieve or to avoid in the design or general
approaches to take while building a system. Patterns are solutions that can be
applied to a type of development activity; they are solutions waiting for
problems that occur during an activity in a method. Rules of thumb consist of a
general body of hints and tips.[3]
during
the research for writing this paper we found that there are many methodologies
and that all of them claim to be for benefit to various kind of projects. We
found also that almost all methodologies was built to overcome a shortcome or a
problem that the previous methodology can't or does not address very well. Every
methodology is better than nothing and each of them improve on the
other.
As an example we will cite the problem that most organizations
have noticed about the waterfall methodology for system development. Most
organizations claimed that this methodology does not allow for change
incorporation. as stated by James Bach in his article .[4] Although the
waterfall approach mandates the use of undefined processes, its linear nature
has been its largest problem. The process does not define how to respond to
unexpected output from any of the intermediate processes.[5]
To
address this problem a research was launched at these companies ADM, and Easl to
find a methodology that manage complexity and unpredictability by allowing a
flexible incorporation of environmental changes during the project. A set of
controls is developed and the probability of success is increased.
Table of
contents
Due to the fact that there are plenty of methodologies and
some of them are proprietary, meaning that they are owned by the organization
that put them together and uses them, It's quite difficult to put together a
framework for a comparison study of methodologies.
To ovecome this
difficulty, In the following section we would list and define some criteria that
would be helpful for any IT professional involved in a system development
project to choose among the existing methodologies to determine which one would
fit the project he/she is working on based on a predefined objective.
So, all the criteria would be related to a component of a methodology or
one of its phases. As stated in the definition above, a methodology is a set of
steps to follow for a system development. One of the difference between the step
by step methodologies and the SCURM [6] methodology is that the
latter has only two defined processes planning and closure,whereas the
waterfalls admit that all processes are defined and well known, and the various
step are implemented in a linear fashion. So the first criteria of comparison
would be
Processes definition
By
process definition we mean does the methodology assume that every step in the
development life cycle is well known? and that there is no room for
environmental changes ? or does the methodology allow a big deal of flexibility
in all stages of the development cycle to incorporate those changes that needs
to be incorporated in the project before its closure.
Final product determination
Another criteria would
be related to the final product. Does the methodology define the final product
early on in the planning stage or does it define it during the project and close
to project closure time
Project
cost
This criterion is related to the estimation of the cost of
the project and at what stage of the project it's done.
Project completion date
Estimation of a schedule of
deliverable based on the estimation of the tasks to be accomplished. Is that
done up front or as the project progresses?
Responsiveness to environment
This criterion
measures the flexibility that the methodology allows to incorporate changes
during the project, changes due to the environment, technology, competiotion or
other.
Team dynamic and creativity
The
steps predefined by the methodology could be an obstacle to creativity among
teams, as the linear model suggests that some work needs to be done first by a
small group and then the project moves to the next stage.This criterion try to
measure the ability of allowing some team work and interactions among the team
members.
Role of the upper
management
Is management an obstacle in creating a better system,
or is the role of management to empower the team by taking care of any obstacles
that impact the team performance.
Training and
knowledge
Does the methodology steps allow training and knowledge
transfer during the project or does it put a limitations to what a team member
can do and learn.
Probability of
success
This criterion measures the probability of success [7]
of a project using a certain methodology by embracing a certain degree of
complexity and unpredictability.
(a successful project is defined as a system that is useful when
delivered)
Table of
contents
Before jumping into the application of the framework above for the
comparison of these two methodologies, we would like to define the waterfall
methodology as well as the SCURM methodology.
Waterfall methodology is :
" In the traditional waterfall methodology, first comes the analysis phase, then
the design phase, followed by the implementation phase, with testing completing
the process. The team that does each phase is different and there may be a
management decision point at each phase transition. This methodology is called
the waterfall methodology because each phase flows naturally into the next phase
like water over a series of falls. [8]
SCURM is " A
variation on Sashimi, an "all-at-once" approach to software engineering. Both
Scrum and Sashimi are suited best to new product development rather than
extended development. Sashimi originated with the Japanese and their experiences
with the Waterfall model. They had the same problems with the Waterfall model as
everybody else, so they adapted it to suit their own style. Realizing that speed
and flexibility are as important as high quality and low cost they reduced the
number of phases to four -- requirements, design, prototype, and acceptance --
without removing any activities, which resulted in overlap of the Waterfall
phases. Then they made the four phases overlap. (Sashimi is a way of presenting
sliced raw fish where each slice rests partially on the slice before it). Other
companies took Sashimi one step further, reducing the phases to one and calling
it Scrum. (A scrum is a team pack in Rugby, everybody in the pack acts together
with everyone else to move the ball down the field). [9]
After reviewing
the definitions of each methodology, it becomes clear that the problem with the
waterfall methodology is that the phases are almost independent and the teams
working in each phase are different which prevent the teams of taking benefit
from the input that they can give to each other and enrich the work they are
working on.
On the other hand, the SCRUM relies a lot on the process of
team empowerment, the team is given a task and it's the management duty to take
away the obstacles preventing the team from achieving their goal to realize the
work they were asked to do.
For a comprehensive comparison between the
two approaches, we will apply the framework defined in the previous section to
the waterfall methodology and the SCRUM methodology. For easiness of reading we
will combine the results in the following table.
Methodology Comparison [
10]
| Criteria of
comparison |
Waterfall
|
SCRUM
|
| Process Definition |
Required |
Planning and closure only |
| Final Product determination |
Determined during planning |
Set during project |
| Project cost |
Determined during planning |
Set during project |
| Completion date |
Determined during planning |
Set during project |
| Responsiveness to environment |
During planning only |
Throughout the project |
| Team dynamic and creativity |
Limited |
Unlimited during iterations |
| Role of upper management |
A decision point at each transition |
Eliminating obstacles is the main function |
| Training and knowledge transfer |
Before the project |
Team work during the project |
| Probability of success |
Low |
High |
Table of
contents
In this paper we tried to build a
grill of comparison for system development methodologies. We listed the criteria
we judged are important for the evaluation of a system development methodology.
methodolgies build upon each other and improve on each other, all methodologies
have commun components, implementing a methodology is always better than having
none.
The purpose of having a methodology is the increase of probability
of success of a system development project. At certain point an organization
might need to question the methodology they are using and opt for another one.
But how can the organization decide on what methodology to use?
By using
this grill of comparison IT professionals and system analyst can adopt a
methodology versus another by examinig the 9 criteria we defined in this paper.
As the example shows this framework for system development methodologies
comparison sounds useful and can help in eliminating some
alternatives.
Table of
contents
1 Hoffer, Jeffrey A.,
George, Joey F., and Valacich, Joseph S. Modern Systems Analysis & Design,
2nd ed. Addison Wesley Longman, Inc., 1999. 24 p
2
http://www.controlchaos.com/scrumwp.htm#Introduction
3
http://www.controlchaos.com/scrumwp.htm#Introduction
4 James Bach.
October 1995. "American Programmer"
5
http://www.controlchaos.com/scrumwp.htm#Introduction
6
http://www.controlchaos.com/overv.htm
7
http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/node50.html?
8
http://jeffsutherland.com/oopsla/schwapub.pdf
9
http://www.controlchaos.com/scrumwp.htm
10
http://jeffsutherland.com/oopsla/schwapub.pdf
Table of
contents