Rational Unified Process

This paper has the intention to explain what Rational Unified Process (RUP) is like an IBM product and a CASE tool. After is explained what phases it has, what are the most common extensions thus what are its workflows more used. The Rational Unified Process (RUP) is a software design method created by the Rational Software Corporation and now is part of IBM developer software. This paper describes how to deploy software effectively. The Rational Unified Process (RUP) use commercially proven techniques, and is a heavy weight process, and hence particularly applicable to larger software development teams working on large projects.

Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. RUP would be taken like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development. RUP is a comprehensive software engineering tool that combine the procedural aspects of development (such as defined stages, techniques, and practices) with other components of development (such as documents, models, manuals, code, and so on) within a unifying framework.

The RUP defines the following guidelines and templates for team members to follow during a product’s lifecycle:

Given the time, it takes to develop large sophisticated software systems it not possible to define the problem and build the solution in a single step. Requirements will often change throughout a projects development, due to architectural constraints, customer’s needs or a greater understanding of the original problem. Iteration allows greater understanding of a project through successive refinements and addresses a projects highest risk items at every stage of its lifecycle. Ideally each iteration ends up with an executable release – this helps reduce a projects risk profile, allows greater customer feedback and help developers stay focused.

A documentation framework is essential for any large project; hence, RUP describes how to document functionality, constraints, design decisions and business requirements. Use Cases and Scenarios, are examples of artifacts prescribed by the process and have been found to be very effective at both capturing functional requirements and providing coherent threads throughout the development and deployment of the system.

Component Based Architecture creates a system that is easily extensible, promotes software reuse and intuitively understandable. A component often relates to an object in Object Orientated Programming. The RUP provides a systematic way to build this kind of system, focusing on producing an early executable architecture before committing full resources on a project. These components are often assembled within existing infrastructures such as CORBA and COM.

Abstracting your programming from its code and representing it using graphical building blocks is an effective way to get an overall picture of a solution. It can also allow less technically competent individuals who may have a better understanding of the problem to have a greater input. Unified Modeling Language (UML) is the industry standard way of representing projects and is hence usually used by the RUP.

Quality Assessment is the most common failing point of all software projects, often an afterthought in such projects and even handled by a different team. The RUP assists in planning quality control and assessment built into the entire process involving all members of a team.

In all software projects change is inevitable, the RUP defines methods to control track and monitor changes. As a seemingly small change can affect applications in entirely unpredictable ways, this is essential for a successful project. The RUP also defines secure workspaces allowing a programmer to be guaranteed that changes in another system will not affect his system. This ties in heavily with Component based architectures.

So far these guidelines are general, to be adhered to throughout a project's lifecycle. To capture the time dimension of a project the RUP divides a project into four distinct phases:
• Inception
• Elaboration
• Construction
• Transition

Each of these four phases are organized into a number of separate iterations that must satisfy defined criteria before the next phase is undertaken. In the inception phase, developers define the scope of the project and its business case. In the elaboration phase, developers analyze the project's needs in greater detail and define its architectural foundation. In the construction phase, developers create the application design and source code; and in the transition phase, developers deliver the system to users.

RUP would provide us a prototype at the completion of each iteration. The product also includes process support for Java 2 Enterprise Edition (J2EE), BEA (WebLogic) development or IBM (WebSphere) and supplies an HTML-based description of the unified process that an organization can customize for its own use.

The essence of RUP is iteration. The essence of iteration is that each iteration ends in a deliverable, preferably one that executes. Even in inception, users are going to want a few iterations that show growing functionality. During inception, users will gather a significant fraction of the use cases. Users will focus on those that seem to be central or key. The iterations will be implementing some of these.
During elaboration, users will tighten up their architecture and their plan. The nature of the iterations will not necessarily change much; but the longevity of the software produced will certainly increase. Early iterations (usually in the inception phase) have a tendency to be thrown out. During elaboration, you will discover the rest of the use cases (or at least their first approximations) and will implement the minimal set.

During construction, users will drive towards giving the customer the minimum system that they need. The nature of the iterations will not change much, but your focus will be on identifying the smallest possible deliverable that will still meet at least some of the customers needs. During construction, the use cases will change a bit as the customer sees the growing system and feeds changes back to you.
During transition, users will drive towards fleshing out the functionality of the system, and incorporating the mounds of customer feedback that users are surely to get. The nature of your iterations will not change much. During transition, the use cases are likely to undergo drastic changes as the customers actually use the system and realize that it is not exactly what they needed.

Again, the essence of RUP is iteration, and the essence of iteration is the production of executable deliverables. Users may also be producing UML diagrams, or some other form of model too. Such models take two forms. One is a model of the architecture, which is seeded during inception and established during elaboration. This model is likely to be a permanent document. The other kind of model is created at the beginning of each iteration, as a way to plan what the structure of the iteration will look like. These models are most likely temporary documents. You might find a few that are essential and should be retained; but many will be discardable.



To produce efficient software with the Rational Unified Process, there is a need to ensure that we know all the functionality that it can give us. Moreover, the usability of the product has to be evaluated in real world situations, because would not be useful for all companies. I can see that Rational Unified Process can provide an adequate framework for necessary multiple iterations of the development process. However, it is necessary to have a further adaptation to the particular needs of every company that would plan to use it.