Overview of OpenUP
OpenUP is for small teams who work together in the same location. The team needs to engage in plenty of daily
face-to-face interaction. Team members include the stakeholders, developers, architects, project manager, and testers.
They make their own decisions about what they need to work on, what the priorities are, and how best to address
stakeholder needs. The organization must support the team by allowing them these responsibilities.
Team members collaborate extensively. The presence of stakeholders as team members is critical to successfully
Team members participate in daily stand-up meetings to communicate status and issues. Problems are addressed outside of
the daily meetings.
OpenUP focuses on significantly reducing risk early in the lifecycle. This requires regular risk review meetings
and rigorous implementation of mitigation strategies.
All work is listed, tracked, and assigned through the Work Items List. Team members use this single repository for all
tasks that need to be recorded and tracked. This includes all change requests, bugs, and stakeholder requests.
Use cases are used to elicit and describe requirements; therefore, team members need to develop skills in writing good
use cases. Stakeholders are responsible for reviewing and certifying that the requirements are correct. Use cases are
Architecturally significant requirements must be identified and stabilized in the Elaboration phase so that a robust
architecture can be created as the core of the system. An architecturally significant requirement change that must be
addressed may arise later in development, but the risk of this happening is significantly reduced in the Elaboration
Testing is performed multiple times per iteration, every time the solution is incremented with the development of a
requirement, change, or bug fix. These tests happen after developers have developed the solution (which should have
been unit-tested) and integrate it into the code base. These tests help guarantee that a stable build is created and
always available as development progresses.
OpenUP does not include content for deployment, configuration management, or the development environment (such as
customizing this process or setting up development environments). OpenUP focuses on a singe team, and these areas are
generally addressed at an organizational or enterprise level. Look for extensions to OpenUP that address these wider
OpenUP is an iterative software development process that is minimal, complete, and extensible. It is governed by
four core principles:
People in roles perform tasks that use and produce artifacts. OpenUP describes the minimal set of roles, tasks (organized by
disciplines), and artifacts (organized by work product domains) involved in software development:
The OpenUP software development lifecycle
OpenUP is an iterative process distributed throughout four phases: Inception, Elaboration, Construction, and
Transition. Each phase consists of one or more iterations where stable, working versions of the software are developed
and released, with the completion of each iteration representing a minor milestone for the project and contributing to the successful achievement of the
phase's major milestone, where phase objectives are met.
The following diagram depicts OpenUP Lifecycle.
How to get started?
The fourth OpenUP core principle, "Evolve to continuously obtain feedback and improve", suggests an iterative and
incremental approach to adopting OpenUP.
Start with the core principles and understand the intentions behind OpenUP.
Then assess your existing process, and select one or two key areas that you would like to improve.
Begin using OpenUP to improve these areas first.
In later iterations or development cycles, make incremental improvements in other areas.
If you have little or no experience with unified processes or other iterative processes, use OpenUP in a small
pilot project, perhaps with only three to four people working for only two to three months.
While OpenUP is a ready to use as-is, you may choose to extend the process or modify the work product templates to suit
your specific needs. For example:
You may require more or less precision in your work products.
Your organization may have specific configuration management practices or safety protocols to include in your
You may simply want to put your own corporate logo on the banner.
You may want to incorporate lessons learned from a retrospective review into OpenUP.
Use EPF Composer to extend and tailor OpenUP. For more information about EPF composer, visit www.eclipse.org/epf.