Waterfall Methodology

Overview:
The first concept of the Waterfall method was introduced by W.W. Royce in 1970. Royce
then went on to redesign his 1
st
method arguing that it was flawed. In his net redesign of
the Waterfall method he introduced that the initial model could be de!eloped into an
iterati!e model" with feedbac# from each phase influencing subse$uent phases. %is
criticism of the 1
st
model was largely ignored and thus resulted in the current Waterfall
methods of today. &ost modern 'ystems (nalysts do not li#e or use the Waterfall
method because of its non)iterati!e and infleible design process. The way the waterfall
method wor#s is that each phase must be completed perfectly for the net phase to begin.
There is no o!erlap or mo!ing bac#ward in phases.
The Process steps
Requirements: they set in stone the re$uirements of the system.
Design: The system in $uestion is designed and a *blueprint* is drawn for implementers
+coders, to follow - this design should be a plan for implementing the re$uirements
gi!en.
Implementation: When the design is fully completed" an implementation of that design
is made by coders. Towards the later stages of this implementation phase" system
components produced by different teams are integrated.
Verification or Testing: (fter the implementation and integration phases are complete"
the system is tested and debugged. any faults introduced in earlier phases are remo!ed
here.
Installation Maintenance: The system components ha!e all been integrated. The
system is installed within the company and training for the system begins.
Pros!
Time spent early on in software production can sa!e a company hundreds of
thousands of dollars. Its shown that problems found too late in the life cycle of
systems de!elopment can end up costing /0 to 000 times the amount that it would
ha!e cost to fi if it were found during that particular fa1e.
It places more emphasis on documentation than some other models. If someone
from the team were to lea!e" than any new person brought aboard would be able
to easily catch up because each step in the Waterfall model is designed before it is
implemented" and nothing changes after the implementation of each step.
"ons:
It is almost impossible to #now eactly what is needed in each phase of the
software process before some time is spent in the phase *following* it. 2eedbac#
from following phases is needed to complete satisfactory preceding phases.
Re$uirements are loc#ed in too early" e!en after business conditions ha!e
changed. With no user feedbac# many of the new user re$uirements will not be
implemented.
There is so much emphasis placed on design deadlines and completion that the
system may not match the user needs. This could lead to etensi!e maintenance
and much unnecessary rewor# that could be !ery epensi!e.
e#treme Programming $#P%
Overview:
3treme 4rogramming was in!ented about 5 years ago by a man name 6ent 7ec#. 84 is
successful because it stresses customer satisfaction. The methodology is designed to
deli!er the software your customer needs when it is needed. 84 empowers your
de!elopers to confidently respond to changing customer re$uirements" e!en late in the
life cycle. 84 was created to impro!e software pro9ects in four essential ways.
communication" simplicity" feedbac#" and courage. 84 programmers communicate with
their customers and fellow programmers. They #eep their design simple and clean. They
get feedbac# by testing their software starting on day one. They deli!er the system to the
customers as early as possible and implement changes as suggested. With this foundation
84 programmers are able to courageously respond to changing re$uirements and
technology.
The Process steps $Once a pro&ect is started these go in no particular order%
Planning: :uring the planning process user stories are first collected from the customer.
;ser 'tories are written by the customers as things that the system needs to do for them.
2eedbac# is gi!en to the customer to help better understand the re$uirements.
Designing: :uring the design phase the primary focus is on #eeping the design simple.
<onstant communication with the customer is used to design and redesign o!er and o!er
again until they ha!e reached an acceptable solution.
"oding: The coding process is a !ery iterati!e process in 84. It is usually done in teams
of 0 programmers so they can constantly feed off of each others ideas. While coding the
customers feedbac# is constantly used in order to meet design re$uirements. Testing is
immediately done when the code is finished to achie!e optimum functionality.
Testing: Testing is consistently done after each portion of code is written. This is to
insure that there will be no bugs in the system" and if a bug is found the code is
immediately rewor#ed and retested.
Pros!
<ode will be de!eloped" tested" and implemented into the system within a few
hours after it has been written.
84 is go!erned by !ery simple rules and practices.
The pair programming used in 84 produce more and better communication
amound de!elopers" higher le!els of produmti!ity" higher $uality code" and
reinforcement of the other practices in 84" such as the code)and)test discipline.
"ons:
Really there are no cons to 84 besides the fact that it may not be applicable to
e!ery pro9ect.
Rational 'nified Process
Overview:
The Rational 'nified Process +R'P, is an iterati!e software de!elopment process
framewor# created by the Rational 'oftware <orporation +a di!ision of I7& since 000=,
around 1995.
Rational ;nified 4rocess +R;4, is an ob9ect)oriented and Web)enabled program
de!elopment methodology. (ccording to Rational" R;4 is li#e an online mentor that
pro!ides guidelines" templates" and eamples for all aspects and stages of program
de!elopment. The R;4 uses si #ey principles
1. (dapt the process : :ecide on the right si1e pro9ect and budget for the
organi1ation.
0. )alance sta#eholder priorities: :etermines business goals and sta#eholder needs
=. "ollaborate across teams: With a broad !ariety of sta#eholders" all !oices need to
be heard. 3!eryone within the pro9ect shares information" opinions" and ideas.
>. Demonstrate !alue iterati!ely: 4ro9ects are deli!ered" e!en though often only
internally" in an incremental and iterati!e fashion. This encourages feedbac# from
sta#eholders and allows pro9ects to ad9ust to changed re$uirements based on
customer feedbac#
/. *le!ate the le!el of abstraction: &oti!ates the reuse of software or 2ramewor#
already created.
?. +ocus continuously on $uality: 3ncourages $uality chec#s through testing not
only at the end but during the creation of the pro9ects.
The R'P consists of , phases!
Inception: (nalysts define the scope" determine the feasibility of the pro9ect"
understand user re$uirements" and prepare a software de!elopment plan. ;sually
entails a single iteration. It is short and the least resource intensi!e.
*la-oration: (nalysts detail user re$uirements and de!elop a baseline architecture.
(nalysis and design acti!ities constitute the bul# of the elaboration phase. &ay ha!e
one or two Iterations and is considered the most critical of the > phases. In this phase
an eecutable demonstration of the critical pieces will be de!eloped. It is long and has
the =
rd
most resource consumption.
"onstruction: The software is actually coded" tested" and documented. (t the end of
this phase a beta !ersion of the pro9ect is released that should ha!e operational
capabilities. It is the longest and most resource intensi!e phase.
Transition: The system is deployed" problems are corrected" and the users are trained
and supported. @nce acceptable criteria are met the product can then be scheduled
for release.
Pros:
3stablishes a better understanding and communication channel between business
engineering and software engineering.
4ro!ides pre)configured process templates for small" medium and large pro9ects"
which can be used for easier adoption.
(llows for constant feedbac# from the business as well as the sta#eholders.
3ncourages the use of reusable assets such as software pattern" >AB or
2ramewor# which in turn pre!ents software engineers from ha!ing to ma#e
custom software.
"ons:
If the users of R;4 do not understand that R;4 is a process framewor#" they
may percei!e it as a weighty and epensi!e process.
Re$uires an R;4 process epert" the pro9ectCs o!erall success is highly
dependent on the abilities of this one person.
&ay not be applicable to all situations.