Method Overview

Classification

In terms of cycles and ceremony, UP classification is illustrated in Figure 9.1. For average projects, the recommended length of a timeboxed iteration is between two and six weeks somewhat longer than XP, for example.

Figure 9.1. UP on the cycles and ceremony scale.

cycles and ceremony

Perhaps the most noteworthy quality of the UP, in comparison with other popular IID methods, is its ability to scale up and down on the ceremony spectrum, with optional support for higher degrees of formality and documentation. Contrary to some misunderstanding, the UP encourages a relatively light footprint in terms of ceremony, although in general it recommends more documentation and modeling than in XP. It offers a set of around 50 optional workproducts for many contingencies.

In terms of the Cockburn classification, the UP covers all cells. See Figure 9.2.

Figure 9.2. UP covers all cells on the Cockburn scale

Cockburn scale

The UP can be applied to small three-person projects with no more than loss of comfort, and up to hundreds of developers working on life-critical systems. For example, the core UP practices were applied on the Canadian Air Traffic Control System project, involving many hundreds of developers.

Introduction

The UP [JBR99] is an iterative process framework a general process description that can and should be refined into a more detailed process description for an organization or project, such as the RUP [Kruchten00].^[1] A UP specialization may itself be a more detailed process framework (as is the RUP) or a concrete process description for one particular project.

^[1] IBM bought Rational in 2003, maintaining the "RUP" branding.

The UP is more of a defined process, and more broad and ambitious than the other iterative processes described in this text. However, all activities and workproducts, and their ordering, are optional and arbitrary.

See "UP as a Heavy, Defined Process versus an Agile UP Approach"

The RUP refinement of the UP is both a process framework (for creating specific processes), and a licensed product. As a product, it is a set of around 100 core Web pages of process description with several thousand detailed supporting pages and with templates for its artifacts. A customizing "RUP Builder" tool can configure the set of Web pages to describe your organization's specific tailoring of the RUP. Many organizations purchase and install a version on their intranet as a learning aid, quality assurance aid, and template resource. See Figure 9.3. It is not required to own the RUP product to adopt and apply the UP's general ideas or practices.

Figure 9.3. sample Web page from the RUP product

The UP defines a set of approximately 50 optional (non-software) artifacts (workproducts), such as the Vision. A particular project may create zero or more, and "less is better" is a guiding rule, although a couple of workproducts are usually recommended, including a Vision and Risk List. Note that workproducts in the UP are information abstractions rather than necessarily computer documents; for example, the Risk List could be realized with a poster on the wall of the project room. Nevertheless, the RUP product includes document templates (for example, in HTML) for those wishing to use them.

The workproducts are organized within disciplines such as the Requirements discipline that define major areas of concern and activity on a software project. See Table 9.1 for a sample.

Table 9.1. sample UP disciplines and workproducts

Discipline	Workproduct	Comment
Requirements	Vision	Summary of stakeholders' key needs and features.
	Use-Case Model	The set of use cases describing the intended functions and environment.
Design	Design Model	An object model describing the hardware and software realization of the use cases in terms of collaborating objects.
	Software Architecture Document	A system overview or learning aid that includes several architectural views.
Project Management	Iteration Plan	The goals and tasks for the current or next iteration.
	Risk List	A list of prioritized risks with associated mitigation plans.

In terms of disciplines and iterations, the UP envisions a project approximating Figure 9.4. In each iteration, activity occurs in most disciplines, though the relative efforts vary over time.

Figure 9.4. sample UP disciplines and iterations

The UP requires that it be tailored for each project; that is, choosing the set of practices and UP workproducts to create, from the large but optional set available. This unique tailoring is called the Development Case of the project; a simple example is shown in Table 9.2. In general, "less is better" is the guideline, and a Development Case is encouraged to contain the minimal set of workproducts needed to address the risks and goals of the project.

Table 9.2. Sample partial UP Development Case

Discipline	Techniques	Artifact	Incep.	Elab.	Const.	Trans.
		Iteration	I1	E1..En	C1..Cn	T1..Tn
Requirements	one-day timeboxed requirements workshops, prototypes, paper-based UI mock-ups.	Vision	S[a]	r
		Supplementary Specification	S	r
Design	Pair designing doing whiteboard sketches captured with camera, test-first design, reverse engineering.	Design Model		s	r
		SW Architecture Document		s
Project Mgmt	All Scrum management practices	Risk List	S	r	r	r
Implementation	Pair programming, test-first development, continuous integration	code, graphics, etc.	S	r	r	r
…	…

^[a] s = start. r = refine.