OpenUP -The Best of Two Worlds - Part 3

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

OpenUP - the method

This chapter is intended to give a brief introduction to OpenUP only. There are excellent resources on the EPF web site [1] for learning more about it. (including downloading and browsing the OpenUP process itself!)

OpenUP defines a set of roles, work products and tasks:

Figure3: Overview of OpenUP elements

The process described by these elements is minimal and complete; it is the smallest set of elements that still describe a project end-to-end.

Analysts formulate the intent of the system in the vision, use cases and supplementary specification products.

Managing iterative projects is largely a matter of orchestrating the activities of the team through each iteration, primarily by managing tasks against the current iteration plan. It is populated with the highest prioritized items from the work items list and risk list, and the team commits to a certain amount of work in each iteration.

The development team includes architects, developers and testers, who are responsible for the development of the solution products, which ultimately result in the operational system.

Activity models describe typical task collaborations as they occur in iterations:

 

Figure 4: Example activity model

A lifecycle model provides the governance process for iterations and micro-increments:

Figure 5: OpenUP lifecycle model

If you are a developer your process is the "analyze-code-test-integrate" cycle that you go through almost on a daily basis, as specified by the tasks in the iteration plan; if you are a manager, or Scrum Master, your focus is on how the team performs in each iteration, which is estimated and tracked in the iteration plan; and if you are a project stakeholder, you are focused on understanding what the project will deliver and when, as described in the project plan.

OpenUP is inherently iterative and incremental and the project is executed over a series of iterations, typically 2-6 weeks in duration.

Figure 6: Iteration lifecycle

Each iteration takes on a subset of the project's work items. Iterations are started with a short planning activity where the highest-prioritized items from the work items list and risk list are allocated to the iteration plan. This is followed by a short activity where the team gets involved in the detailed planning and estimation of each work item. Thereafter the iteration work commences and each feature is analyzed, designed, implemented, tested and integrated in its own micro-increment. As the iteration unfolds, task status is reported back to the iteration plan for overall project status.

The project lifecycle in Figure 5 identifies four distinct phases, each with a specific purpose and milestone criteria:

• Inception: define the scope and objectives of the project
• Elaboration: establish an understanding of the requirements and create an executable architecture for key scenarios and quality demands
• Construction: build the functionality of the system
• Transition: release the system to the end users

This lifecycle model distinguishes OpenUP from agile methods and allows us to focus early project efforts, in the inception and elaboration phases, on understanding the scope of the project and its solution before embarking on full-scale development in the construction phase. At the end of the elaboration phase we have typically spent only 20-25% of the total project budget over 30-40% of the project schedule.

With this brief introduction, let's see how OpenUP helps address the specific problems that we identified earlier:

• A shared vision is created in the inception phase. The stakeholders' key needs and features are captured in the Vision document. It describes high-level requirements and design constraints, and gives an overview of the system's functional scope.
• All project work is driven by use cases and other requirements. The Work Items List constitutes a "laundry list" of features, requirements and change requests raised on the system.
• An executable architecture is created in the elaboration phase. The Architecture Notebook along with the other development work products represent a base-lined executable architecture that demonstrates how the system supports the key scenarios and constraints, and which serves as basis for the ensuing construction phase. It is worth noting that 'architecture' is not a separate "thing" - it is the underlying organization and qualities of the system being built - and the executable architecture is just a state of the underlying design, implementation and test products. To create the right focus on the architectural concerns we prioritize those use cases and other requirements during the elaboration phase that involve the highest technical risks, as identified in the risk list.
• Each iteration is planned "just in time", and the project team is involved in the detailed estimation and planning activities. For each iteration the Iteration Plan is populated with the highest-prioritized work items from the work items list and risk list. The team is responsible for identifying and estimating tasks for each work item.
• Risks are pro-actively identified and mitigated. The Risk List identifies a prioritized list of risks that are associated with the project. All critical risks have been removed at the end of the elaboration phase.

OpenUP thus helps us remove some of the main obstacles to project success early in the project and with only a small investment.

The inception and elaboration phases also help establish and organize the key project work products and processes, so that construction can commence with a growing team and aggressive timelines with minimum friction.

Go to part 2    Go to part 4     Back to the archive list

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