Exam essay: Rational Unified Process
January 2, 2009
I give an overview of the Rational Unified Process (RUP).
Exam essay: Rational Unified Process
A popular software development methodology is the Rational Unified Process (RUP). Give an overview of the process. When is its use indicated, when it is counter-indicated? What business implications does the use of RUP have? What aspects of software development does it address, what does it not address.
In this article, I give an overview of the Rational Unified Process (RUP), show when it its use is indicated and counter-indicated, and discuss the business implications of RUP. RUP is a software methodology which is both iterative and incremental. By iterative, I mean that it produces many intermediate solutions which over time converge on the solution that is closest to what the users want. Development in RUP is split up into timeboxed iterations: constant length time periods which each contain a requirements gathering, design and implementation phase, and importantly, each result in a working system (this is the intermediate solution I was referring to). By incremental I mean that we do not start out building the entire project with the full functionality of the desired end solution. We instead start by building a partial solution and add functionality to it throughout the iterations.
RUP has three primary characteristics. It is use case driven, it is risk focused, and it architecture centric. Use cases are stories that describe a user using the system to be developed. An example of a use case for a Point of Sale system would be “Process Sale: a cashier records items in the system that the customer wants to buy and produces a receipt.” Use cases are documents produced jointly by the programmer and end users and which describe an action and a goal for using the system. Use cases cause development to be user-driven: we define the system by the goals that the users have in using the system, and by the actions that the user must perform in order to achieve those goals. RUP is risk-focused in that effort is expended early in the development process to identify the use cases that are most important to the users are worked on in the early iterations. By “highest risk” I mean highest risk to project success: if we don’t have them successfully implemented, the users won’t consider the system to be successful. RUP is architecture-centric in that it considers the architecture of the system to be developed to be very high risk and thus it should be stabilized early in the development process. The software architecture is a high-level, strategic view of the system: what language we’re going to use, how we’re going to break the software into components, what other systems are going to be involved.
As I said before, RUP is an iterative and incremental methodology. The development project is divided up into a series of fixed length time periods called timeboxes. Each timebox may incorporate requirements gathering (gathering and elaboration of use cases), design, and implementation and always ends with a working system which is presented to the end users. Design is accomplished via fairly heavy use of UML, a visual software modeling language, chosen because it can allow developers and users to communicate design decisions without having to resort to code. The end users try out the software, and give feedback to the project team as to what works and what doesn’t, and the team incorporates that feedback into the next iterations. Further, the team itself reflects on what worked in their process, and adjusts the process accordingly (single and double loop learning).
Iterations in a RUP project go through four phases in order: inception, elaboration, construction, and transition. Inception phase iterations are concerned with establishing project scope, business modeling (understanding the concepts in the business domain), gathering all use cases at a basic level and stabilizing the system architecture. The elaboration phase is concerned with fleshing out the use cases, starting with the highest risk ones, analyzing those use cases and designing parts of the system related to them, doing some implantation of that design, particularly that related to the high-risk use cases and system architecture. By the construction phase, most of the use cases are fleshed out, and we’ve done a lot of our design; this phase is about implementation and testing. Transition is about users and developers deciding when the project is done, and releasing the software to production.
RUP is most applicable when business needs (our system requirements) are not well known in advance, or where they may change throughout the development cycle. Secondly, RUP is a work product heavy methodology: as fully specified, it is a large methodology with many non-software work products and much ceremony (many work products are required). In terms of staffing, RUP has well defined tasks and roles (skills, knowledge) that are associated with those tasks. Thus, like in the waterfall process, we can use teams of specialists (analysts, designers, project managers, programmers, DBAs) with RUP , and RUP can work with large teams, and can be made to work with large projects.
In terms of counter-indications for RUP, there are three areas where we may have trouble: staffing, estimation, and user accessibility. RUP is a more difficult methodology to staff for two reasons: it requires more expert workers, and it is difficult to schedule workers. Since RUP is iterative and we expect to alter our product and process with feedback at the end of each iteration, we need workers who are adaptable and can deal with change. Junior staff typically cannot deal with change well because they lack the deep knowledge and expertise to deal with project requirements that change rapidly. They need well defined procedures and clear requirements to be effective. Thus, if you have mostly junior staff, waterfall may be better indicated for your project. Secondly with staffing, we may not know when we will need certain roles to work; we could need designers, analysts and programmers at any point. If scheduling staff time is problematic, again the waterfall methodology may be more appropriate because we can typically look at the project schedule and identify the days that a person will be needed. In terms of estimation, iterative processes can be difficult since we don’t necessarily know when we will be done or how much work it will take to get there. Experienced RUP project managers can develop the estimation skill, but it does take substantial experience with the problem domain and with the methodology. Thus if the project is deadline driven, RUP may not be indicated. Thirdly, RUP, being user-centric, means that we need frequent access to and input from users. If we can’t get that, we may not be able to use RUP. Outsourcing parts of a RUP project can be very difficult, and it can be difficult for an outsourcer to do RUP.
One major part of the software development lifecycle that RUP does not address is software maintenance: bug fixes, feature enhancements after the product has been deployed. RUP is fundamentally a creational methodology – we use it to make new software and hand off to another group to maintain.
From an enterprise perspective, in the triad of cost, quality, and time, RUP is a methodology that emphasizes quality over cost and time. Firm staffing requirements (and thus cost) increase because we need relatively expert staff. Project scheduling becomes more difficult because project estimation is more difficult; we typically don’t know when we’ll be done, how much the project will cost, or when we’ll need to schedule staff. But, RUP can lead to increased project success rates in areas where business needs (goals) change rapidly, are not known well, or in business and project domains in which the project team has little experience. When I say project success rates here I mean successful from the point of view of business utility: RUP should produce software that is more closely aligned with business needs than does waterfall in such cases.
My self critique:
Does RUP necessitate expert staff or not? This is actually an important point because I’m going to be saying in my article on agile software methodology that agile methodologies necessitate experts, and I want to know whether I can say that RUP does not require that. Some say that segmentation allows specialists. I can imagine situations in which your programmers receive fully fleshed out class diagrams and operational contracts, and in that case, you don’t necessarily need expert programmers: junior programmers will do just fine. I suppose that you can say that RUP does allow junior staff in some roles, but expert staff in most. There is the point that RUP incorporates both uncertainty and change and I think that more expert people will be able to handle that better.
Is RUP a more complex methodology than waterfall? In its full form it is heavy, as heavy as waterfall perhaps, but it is perhaps more difficult because of the necessary team self-reflection, incorporating user feedback and the uncertainty, especially early on, of what the final product will do.