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.
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
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.
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]. A UP specialization may itself be a more detailed process framework (as is the RUP) or a concrete process description for one particular project.
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.
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.
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.