(Rational) Unified Process vs Waterfall Model

Question

I was reading about software development model and life cycle, where I learned about waterfall model and Unified process. However both the process involves requirement gathering, design phase, development testing and deployment (inception, elaboration, construction and transition phase in unified process).

Can any one help me out with the difference between the two?

Hitandrun

So can we conclude that UP is similar to rapid application development model or phased development model ? – Hitandrun

I've answered below, although note that this is not a good format of question for SO, due to the potentially subjective nature of the question. – Modesta

I'm voting to close this question as off-topic because it isn't about programming. – Warchaw

Answer 1

You haven't specified 'which' Unified Process or 'which' Waterfall Process - there were many variants of both, so some of the comparison will be lost in generalization.

Taking for example the Rational Unified process, which differs from waterfall processes in that the disciplines (Analysis, Design, Coding, Testing etc) are done iteratively and concurrently, whereas in waterfall processes, the disciplines are generally done sequentially (e.g. Coding only starts once Requirements have been finalized and Design has been accepted).

In RUP, the term phases (inception, elaboration, construction, transition) are NOT dedicated to a single discipline or single deliverable - RUP phases are all multi disciplinary - e.g. although Inception is primarily about requirements and analysis; some design and prototype coding are also encouraged to reduce risk and improve estimates for future phases, and even in the construction phase, further analysis may be required.

RUP uses the term 'generation' to indicate another full cycle of development e.g. for a "version 2" of a project, where new work on generation 2 would begin at the inception phase.

Another major difference was that RUP pushed the concept of Visual Models (especially UML) as deliverable artifacts which described the requirements, high and class level design (and in some cases code generation was possible from detailed UML models), whereas Waterfall artifacts were typically very document heavy (e.g. the ESA / IEEE processes)

Another difference was in the approach to commercial engagement. Waterfalls typically promoted the concept of a 'contractual' Software Requirement or Software Specification document, which defined the deliverable (functionally, and non-functionally), and from which a project budget or fixed price transaction would be based. Instead, RUP promoted budgeting at a per-phase basis, e.g. and the effort / cost for the following phase would be known / iterated / improved as one of the deliverables of the preceding phase had been delivered.

In many software development operations, Agile processes have superseded both Waterfall and RUP, although many of the artifacts and learnings of Waterfall and RUP remain. Agile has the primary benefit of breaking work down into much smaller chunks (typically 2 week sprints, instead of months-long RUP phases or year-long waterfall projects). This quick turnaround allows features to be delivered on a cost vs priority basis, is better adapted to ever-changing requirements, and allows obstacles to success to be identified much sooner than either Waterfall or RUP. Agile also cuts out a lot of the waste - lets face it, only a small percentage of developers ever read detailed specification documents or pore over detailed UML diagrams.

Modesta