The Rational Unified Process® (RUP®) was developed through the 1990's as a framework for software engineering best practices. Key features such as iterations, simplicity, focusing on value and regular feedback were identified as being important for successful software engineering. With the RUP as a starting point a number of authors have built methodologies that adapt UP to different project domains.
- Develop iteratively, with risk as the primary iteration driver
- Manage requirements
- Employ a component-based architecture
- Model software visually
- Continuously verify quality
- Control changes
- Customization
- a tailorable process that guided development
- tools that automated the application of that process
- services that accelerated adoption of both the process and the tools
Image source: http://en.wikipedia.org/wiki/File:Development-iterative.gif
As well as the core disciplines the RUP® defines supporting the disciplines of Configuration & Change Management, Project Management and Environment Support. More detail about the RUP® can be found here
Agility, for a software development organization, is the ability to adapt and react expeditiously and appropriately to changes in its environment and to the demands imposed by this environment. An agile process is one that readily embraces and supports this degree of adaptability. So, it is not simply about the size of the process or the speed of delivery; it is mainly about flexibility. In this article, I will explain how the Rational Unified Process® (RUP®) is a process framework that allows this flexibility.
The Essential Unified Process
The Essential Unified Process (EssUP) is a collection of practices that together form the essential knowledge of a complete software development lifecycle. This practice-centric approach to software development incorporates and builds on established best practices. The practices in EssUP integrate successful principles from the unified process, agile and process maturity camps, capitalizing on their different capabilities: structure, agility and process improvement
The ESSUP is delivered as a set of Essential Practices, freely downloadable documents describing each of the practices as a set of Things to Produce, Things to Do and Key Competencies, with descriptions and guidelines for each one.
OpenUP - a lean Unified Process
OpenUP also defines a set of Processes, Practices, Roles, Work Products and Tasks that are needed for delivery of a software project. OpenUP is deployed as an Eclipse Process Framework (EPF)
OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.
According to an article in Methods & Tools describing OpenUP by Bjorn Gustafsson
EPF is an open-source initiative that was started in 2006 with contributions by IBM Rational of parts of their RUP content and technology. Since its inception the project has actively involved more than 20 companies, and the first release was made available in September of 2007. Despite being an Eclipse project, EPF can be used to create process descriptions for any type of development, including J2EE on Eclipse or .NET using Microsoft Visual Studio.
In the article he explains the background to the EPF and how OpenUP is deployed. He concludes:
The new OpenUP process synthesizes the best practices from RUP and Agile methods into a light-weight and agile alternative to both. Given its RUP roots, it provides a process that is iterative and incremental, use-case driven, risk-driven, and architecture-centric, which at the same time supports the work habits of agile projects. The OpenUP process features practices suitable for many projects right out-of-the-box, but it also provides the basis for adding 3rd party and proprietary practice extensions, using the EPF Composer tool, to tailor the most appropriate process for each project
Enterprise Unified Process
Another derivative of the RUP® is Scott Ambler’s Enterprise Unified Process
Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement).
is a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. I've tried to keep the Agile UP as simple as possible, both in its approach and in its description. The descriptions are simple and to the point, with links to details (on the web) if you want them. The approach applies agile techniques include test driven development (TDD), Agile Model Driven Development (AMDD), agile change management, and database refactoring to improve your productivity.
On the website he explains the differences between the RUP disciplines and the AgileUP disciplines.
These are some of the variations and derivatives of the Unified Process.
Do you use one of these products, what have your experiences been, and how do they fit in the Agile world?
Community comments
Clear explanation...
by Mark Levison,
Re: Clear explanation...
by Julian Holmes,
Re: Clear explanation...
by Mark Levison,
Clear explanation...
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
...but I'm still confused. I've helped a few teams recover from RUP implementations gone bad. Yes it is possible to good RUP but why would anyone do it? We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative, why would anyone start with a RUP/ARUP etc. project today?
I open to hearing good reasons.
Cheers
Mark Levison
Agile Pain Relief Consulting
Re: Clear explanation...
by Julian Holmes,
Your message is awaiting moderation. Thank you for participating in the discussion.
Mark,
I sympathise with your experiences of "RUP gone bad", but equally I have seen many "Agile gone bad" scenarios too.
We all know that we need to maintain a focus on people and their interactions over any process and tools, but your statement that "We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative" highlights the most common issue:
People don't know what's good for them, and sometimes there is just too much choice.
This is what RUP originally set out to overcome, by providing a customisable framework of practices for people to choose from. Unfortunately, it became so large that few people knew how to scale-back to what they really needed. Hence the numerous "RUP gone bad" examples.
However, in the world of Unified Process described above there has been one particular "flavor" that has tried to address these issues: OpenUP.
Being a "lean" approach that also includes the best of Scrum, XP, and other Agile methods, OpenUP gives you an essential "kernel" and some optional practices for your project team.
So, and in answer to your question, I would suggest that OpenUP is an excellent starting point for a project, particularly if they are inexperienced in process selection, and they want to benefit from the opportunities to scale Agile practices to the challenges that many projects face, such as distribution, regulation, and size.
Cheers,
Julian Holmes
Unified Process Mentors
Re: Clear explanation...
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Julian - interesting points
Good point about "Agile Gone Bad", I have seen Agile gone well, my problem I've never seen RUP gone well and was associated with one attempt to implement it that created way too many work products that where write only. I've no doubt that RUP has been well I've just never seen it - even when I was inside IBM.
Yes but that's why you hire a good coach or consultant. Realistically most people pick Scrum by default (because they don't about the others), so I don't buy the claim of too much choice.
Cheers
Mark Levison
Agile Pain Relief Consulting