RUP describes a process for developing software systems. It seems there are so many variations of RUP, how do you know which is best for you and your organization, if any? What do all those acronyms mean? Where are these things coming from?
RUP is the Rational Unified Process. This process is a combination of two earlier processes - the Rational Process and the Objectory Process. When Rational Software merged with Objective Systems in 1995, they began the work to merge their software development processes. This new merged process was released in 1997 as the Rational Unified Process or RUP.
RUP was designed to cover everything known at that time about how to develop software - from very large systems to very small systems. It was expected that users of RUP would customize it for their project and work environment.
RUP describes software development in terms of four phases: Inception, Elaboration, Construction, and Transition. RUP also describes software development in terms of nine disciplines: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.
Not everyone agreed that RUP was complete or correct. Scott Ambler in particular discussed a lot of what he thought was missing in the RUP. In 2005, he and his partners released a book called the Enterprise Unified Process or EUP. This book described the missing elements of RUP. In particular, Scott added a fifth phase - maintenance - to the project lifecycle.
Unified Process or UP, was a request for proposal issued by the Object Management Group. They were thinking of creating a standard for a meta-model process - or to put it another way, a description of how to create a process. This effort was abandoned, so there is currently no UP standard.
Some people use the term UP to refer to the core elements of RUP: risk managed, use case driven, architecture-centric, and iterative development.
OpenUP is a customized version of RUP which is designed for small and agile projects. OpenUP is an iterative software development process that is minimal, complete, and extensible. It is based on managing risk in an iterative development, use case driven, architecture-centric process.
OpenUP was donated by IBM Rational (I believe in 2005) to the Eclipse foundation and the open source communitee. You may download it free at http://www.eclipse.org/. Here you may also download EPF, the Eclipse Process Framework, which is a tool you can use to develop your own process or modify OpenUP. EPF is a free, open source subset of the IBM Rational tool Rational Method Composer.
EssUP - the Essential Unified Process - is a product of Ivar Jacobson International. It appears to have been released around 2006. EssUP is based on the idea of a Practice. These Practices are based on best practices from RUP, Agile, and process improvement. Practices are grouped into the categories of Iterative, Architecture, Use-Case, Component, Model, Product, Process, and Team.
For example, a Use-Case Practice describes the work flow of collecting requirements in a use-case driven approach. Along with the work flow, the Practice describes the competencies that are required to do the work of the Practice. So if your Use-Case practice requires the use of class diagrams, then one of the competencies required is that someone involved in this process has to understand and be able to produce class diagrams.
EssUP intends that a company would use the basic elements - Practices and Competencies - to describe their processes and to direct process improvement efforts.
RUP, EUP, UP, OpenUP, and EssUp are all variations of a risk managed, use case driven, architecture-centric, and iterative development process. RUP tends to be popular in large, high ceremony projects. EUP is popular with those involved with Enterprise level concerns. UP refers to the basic process that the rest are built on. OpenUP is an open source variation for small, agile projects. Finally, EssUP is a variation focusing on the practices and competencies of software development, each of which can be independently implemented at a company.
Author: Geri Schneider Winters
* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.