Comparing Waterfall and Rational Unified Process

Contrary to popular opinion, not every IT project can successfully adopt agile practices. Location of resources, team structure, corporate culture and even technology used, can all play a key factor in determining which development practices will work in an organization. While many companies are actively seeking to use agile practices, such as XP or Scrum to help streamline production with fast, effective development practices that can give their customers what they want in the shortest time possible, elements of some of the traditional software development methods such as the “Waterfall” or “Rational Unified Process (RUP)” are often required to bridge the gaps that some of these new practices have. In the end, most organizations must adopt a blended approach that bests fits their software project, business culture, and development environment.

In this blog, I compare the strengths and weakness of some of the traditional software development practices – Waterfall and RUP – along with providing guidelines for adopting them. In a subsequent blog will compare these process to agile practices.

Waterfall

The traditional software development process, is often referred to as “Waterfall”, is a highly structured and sequential process that relies heavily on up-front planning and prescribed tasks that flow from one to another like a waterfall.[1] Typical phases in a project using Waterfall development are shown below.

Each phase usually requires its own set of subject matter experts (SME) responsible for creating the deliverables (requirements documents, design document, test plans, detailed designs, etc…) to meet carefully scripted milestones. In Waterfall, the next phase typically cannot be started until the previous one has been completed. The goal is to gather and analyze all the detailed requirements early in the process so that a complete solution can be architect-ed and build with highly predictable results.

Waterfall development can work well for complex or mission-critical systems or for and for organizations that require the highest levels of fault tolerance (such as the military or aerospace). However, projects using Waterfall processes take too long, in many cases months or years, to produce results that can be verified by the user and often and lacks the flexibility for today’s environment. In addition, because Waterfall projects require that all the requirements be defined upfront (often referred to as Big Up Front Requirements – BUFR), these projects often do not provide business value in today’s fast-paced software market as in many cases requirements changes result in expenses change requests or buggy systems.

Rational Unified Process

The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. RUP is “use-case driven, architecture-centric, and incremental and iterative”.

Software projects that use RUP divide the project time-line into four consecutive phases.

Inception, where the project’s scope, estimated costs, risks, business case, environment and architecture are identified.

Elaboration, where requirements are specified in detail, architecture is validated, the project environment is further defined and the project team is configured.

Construction, where the software is built and tested and supporting documentation is produced.

Transition, where the software is system tested, user tested, reworked and deployed.

Each phase is concluded with a well-defined milestonee—a point in time at which certain critical decisions must be made and therefore key goals must have been achieved. Iterations occur in each phase. Activities in iterations are focused on one of the four activities: gathering requirements, analyzing, designing, implementing, and testing. Each of these activities place a more or less important role as the project moves from phase to phase.

RUP also defines the roles and activities of team members in-depth and relies at each stage on the production of visual models, which are rich graphical representations of software systems, and specific use cases rather than the large amounts of documentation required for each stage of Waterfall. All team members have access to the same large knowledge base of guidelines, templates, tools, and other items to ensure that they share the same language and perspective on the project.[2]

Proponents stress that it enhances team productivity by providing each team member with guidelines, templates and tool mentors for all critical development activities. While critics consider it to be too heavy, sighting the large number of documents and other artifacts that must be created to successfully adopt RUP properly. Also while RUP is an iterative approach, the Inception and Elaboration, still provide plenty of opportunity for BUFR to be produced and the remaining development cycles follow somewhat of a waterfall approach to code development and doesn’t stress the need to produce working code as fast as possible.

RUP has been around for 20+ years and has evolved into a proven software development method that has been used by many different teams in many different situations. It is easy to find resources and skills and has many advantages over traditional waterfall approach

Reference

Waterfall, RUP and Agile: Which is Right for You? (n.d.). Retrieved 03-02-2011 from http://www.ebizq.net/topics/dev_tools/features/11821.html
Philippe Kruchten, The Rational Unified Process, An Introduction, Second Edition, Addison-Wesley, 2000.
David Kohrell, Using RUP to manage small projects and teams, retrieve 03-01-2011, http://www.ibm.com/developerworks/rational/library/jul05/kohrell/?S_TACT=105AGY82&S_CMP=MAVE
Goran V. Grahn, Boris Karlsson, Implementing RUP in an organization, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/rup_volvo.pdf