OpenUP -The Best of Two Worlds - Part 5

Bjorn Gustafsson, GOOD Software Inc, www.goodsoftware.ca

Working with OpenUP

Normally, adopting a new software process is a major undertaking, and the transformation of the project team or organization never happens over night. Once a process has been implemented and used you want to find ways to improve it and make the organization more efficient. Process implementation and improvement involves understanding the process, defining it, and training the team on its practices, and this can take weeks, months or even years.

With OpenUP this is not the case. If you want to use it as-is - which is a good starting point for any project - you just download it from the web site and install it in your environment. It is self-contained and provides all the guidance you need to get started. Should you wish to improve the process from there, for example if your project is using a new technology and you want to add guidance specific to that technology, you will find it easy and straight-forward with EPF Composer.

OpenUP has many similarities with RUP, but choosing it is an either-or decision for RUP projects since they can not really co-exist in the same environment (and it wouldn't make sense because of their overlap). A goal with OpenUP was to create an agile process with focus only on the core software development element. This makes it manageable and easy to grasp.

Adopting OpenUP in agile projects, however, is not an either-or decision. It was designed to fit seamlessly with the work habits of agile projects. As we have seen, it balances agility with "just enough" governance, especially in the early stages of the project, to help establish the project context, fundamental structures and key principles early. Once status quo is reached - that is, when the system has taken shape and the team has found a comfortable iteration pace - OpenUP is no different than most agile methods.

OpenUP is based on four core principles, all of which have direct correspondence with the Agile Manifesto:

If you are used to working in agile projects you will find that OpenUP is no different when it comes to its underlying values and principles. Nor does it impose a different work style for your daily activities: you still do the daily stand-up meeting; iterations are planned the same way; you design, implement and test in small increments.

If you are a Scrum Master you will find striking similarities between the Scrum product backlog and OpenUP's work items list, and between the sprint backlog and the iteration plan. This is no coincidence since the inspiration for those came from Scrum. They are even used the same way in planning and performing iterations. (and - you can have your 30 day iterations too!) If you are a RUP project manager you will find that the process around the work items list and iteration plan is tangible and easy to manage.

OpenUP uses 'use cases' as envelope for requirements, but that doesn't preclude the use of user stories as a means to solicit feedback on the evolving system. Use cases and user stories are quite similar in nature, although use cases are coarser-grained than user stories are normally, and they come about in a more pro-active way.

As we have already seen, OpenUP acknowledges the value of architecture and regards it as an intentional property of the system. However, it doesn't treat it as a "large big up-front design" of the whole system. On the contrary, the activity of establishing the architecture is light-weight and focused on a small, central subset of the system's requirements and main constraints and objectives. This, too, is an iterative and incremental activity that occurs in each iteration, primarily during the inception and elaboration phases, in parallel with other project activities.

Of course, the approach to architecture taken by a particular project shall be determined by the circumstance of that project - the more complex and critical the project is, the more important becomes the architecture, and the more pro-active should the formulation of the architecture be.

The future of OpenUP

Like many other open source projects, OpenUP evolve in the direction set by the user community, so what the longer-term future has in stock for us is unclear.

We can rest assured though that, contrary to RUP and other proprietary processes, OpenUP will grow to include the practices most useful to the larger number of people in the software community.

Short-term, taking a quick peek behind the "development curtain", we see work currently being done to add the concept of 'practices' as primary building block, to replace the coarser-grained 'method plug-in' concept. This directly benefits all stakeholders of EPF and OpenUP, and ultimately serves you, the project member, with a more to-the-point process.

Other initiatives are integrating Wiki technology into EPF, to make augmenting and modifying process even easier.

Even if EPF is still young there are already integrations with project management tools available:

• Iris, Osellus Inc [10] (commercial)
• ProjectKoach, GOOD Software Inc [8] (free)
• Wilos project [12] (open source)

Also worth noting is that the future IBM Jazz [9] project incorporates EPF as one of its core components.

Summary

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 3^rd party and proprietary practice extensions, using the EPF Composer tool, to tailor the most appropriate process for each project.

If you haven't looked at OpenUP yet, I invite you to take a closer look at the EPF website [1] where you find more information and downloads.

References

Related Methods & Tools articles

• The Agile Unified Process (AUP)
• Understanding Use Case Modeling

More Unified Modeling Language UML Knowledge

• Scrum Expert
• Unified Modeling Language Portal
• UML Tools Directory

Go to part 4    Back to the archive list

This article was originally published in the Spring 2008 issue of Methods & Tools