OpenUP Development Scenario

The OpenUP process is an instance of the Unified Process that is iterative, agile and tool independent. It is for small co-located teams that have plenty of face to face interactions. This process is collaborative and outlines the roles, artifacts and activities of the process in a consistent and extensible way.

The OpenUP process organizes its activities in to disciplines.

• Architecture
• Development
• Project Management
• Requirements
• Test

Architecture

The architect (primary actor) is responsible for the refinement of an architecture (possibly from an existing asset) into a concrete set of artifacts that can be used to access technical risks early on. The architecture is captured in a document the Architecture Notebook. This artifact describes the software architecture, its design decisions, issues, motivations, as well as use of known patterns, and other assets.

The Architecture Notebook outlines the guidelines and constraints that the development team must follow when designing and constructing software elements for the system. It explains the rationale and reasoning behind them, so that the team can understand them and apply those same principals to the rest of the system design.

The OpenUP process does provide a simple template for a notebook, however in general it does not prescribe specific structure or mechanism for capturing the information in an Architectural Notebook. Most architects communicate architecture through a set of views, where the exact set of view is slightly variable depending on the context of the system and architecture. Most however some type of logical, process, development, physical and a scenarios (use case) view.

The Architects Notebook makes heavy use of modeling alongside a textual narrative. It references specific requirements. It provides priorities and development decision guidance for use of known patterns and mechanisms.

An architecture may include prototypes, including functional prototypes (i.e. exhibiting subsets of functionality of the desired system). These prototypes are used to access architectural and technical risk. Some may evolve into actual system components.

Changes in the system architecture are usually settle out by the time construction is in full swing. However, as with most artifacts in the development process, it is may require changes in iteration, early or late.

Development

The OpenUP process describes the activity, Develop Solution Increment; as an activity where developers take on a work item, with a goal for the developer to contribute to the overall solution. The work item request the worker to perform some specific task that has measurable output. The activity is tracked, and used by managers to access project status.

Development tasks may have a context for what is being developed. A context is something like a requirement to be developed, and the scope to which it should be developed. The developer is responsible for the design and implementation of the work items goals. Not all tasks require formal design artifacts (to be persisted). For example a work item to fix a defect may only require the changing of a few lines of code. However work items to provide a REST service for accessing resources will probably require a formal design, one that can be reviewed iterated over.

A formal design can be a text document, or it can be a model, or any combination. The purpose of a formal design is to describe the elements of the system so they can be examined and understood before it is implemented, and with abstractions that make it more comprehendible than the reading the source code.

Model elements in the design should reference elements in the Architecture Notebook, as well as requirements to explain the decisions made in it.

Development tasks also include Implementation. In Implementation the goal is to produce the artifacts that compose the system to be build (i.e. source code). The artifacts of the implementation are the last set of artifacts that are manually crafted, and incorporate individual design decisions by the developer. During the build process these artifacts automatically compiled into the actual runtime artifacts.

The OpenUP process outlines the typical steps in implementing and increment as:

1. determine a strategy: reuse assets, use MDA/MDD, write code, etc.
2. identify opportunities for reuse: both to use as well as provide.
3. transform design into implementation: if models and tooling are available.
4. write source code: examine requirements (and other input), create and debug code.
5. evaluate the implementation: pair programming, reviews, code visualization and analysis tools.
6. communicate significant decisions: when potentially significant decisions are made in the implementation ensure that the rest of the team are aware of them.

Individual testing is also a task of the developer. Frameworks like JUnit are an excellent means of organizing such tests.

Integration with Requirements, Test and Project Management

Artifacts in the requirements discipline are used as input to activities in development and architecture. Artifacts that are outputs of development are used as input to test activities.
Project management artifacts specify and organize the discrete activities in development and architecture. Results of activities in architecture and development can result in the creation of work items (i.e. discovery of defect, specification of new component or integration, etc.)

-- JimConallen - 03 Aug 2009