OpenUPBasic

OpenUP/Basic

OpenUP is an open-source process framework that over time is expected to cover a broad set of development needs. ^[19] OpenUP/Basic is a subset of OpenUP, and provides a simplified set of artifacts relative to RUP and a much smaller set of roles, tasks, and guidelines. Let's look briefly at the key artifacts, the essentials of the process, and how these relate to the practices in this book.

^[19] At the time of this book's printing, OpenUP is almost equivalent to OpenUP/Basic, and we have chosen to primarily refer to OpenUP/Basic for the remainder of this book. OpenUP is expected to grow over time, while OpenUP/Basic will continue to be a small process.

OpenUP/Basic is an agile and iterative process focusing on the needs of small collocated teams.

The project team maintains a work item list^[20] of all work that needs to be done, including requirements and change requests to be addressed and random tasks, such as delivering training. At the beginning of each iteration, the team prioritizes which work items should be addressed within that iteration, and that subset of the work item list is called the Iteration Plan (see Figure 1.5). The team prioritizes work items to drive down risks and to deliver high-priority end-user capabilities in each iteration.

^[20] Work item list corresponds to product backlog in Scrum; see Schwaber 2002.

Figure 1.5. Managing an OpenUP/Basic Project.

The project manager is responsible for producing a high-level project plan, maintaining a work item list of all things to be done, prioritizing work items into an iteration plan, and assessing the result of the iterations. The entire team is typically involved in producing each of these artifacts.

See Practice 19.

See Practices 1 and 10.

An iteration is typically a few weeks long, and each iteration will deliver an executable that is one step closer to the final product, with the potential exception of the first iteration. During an iteration, the team will work on defining, designing, implementing, and testing the requirements listed in the iteration plan, as well as any other planned work items. At the end of each iteration, the team will assess what was accomplished and demonstrate the executable to stakeholders. The resulting feedback will enable the team to improve upon the solution and understand what are the most important work items for the next iteration. Lessons learned during the retrospective improve the process for the next iteration.

See Practices 2, 3, 4, and 20.

A vision outlines stakeholder needs and high-level features, establishing a common understanding of the domain. Functional requirements are documented as use cases and scenarios, and other requirements are documented as supplementary requirements. The requirements are incrementally implemented by growing the design and implementation in stages, while continuously testing and integrating the code into builds. A strong emphasis is placed on test-and-build automation to enable frequent and high-quality builds.

See Practices 56, 810, 14, and 18.

OpenUP/Basic is steeped in the belief that the team needs to take responsibility for the end product, to which everybody chips in as needed. To improve productivity and quality, the team should reuse existing assets, such as patterns and common components, as appropriate. OpenUP/Basic also puts a strong emphasis on the architecture; a stable architecture is established early in the project and evolves continuously along with the application. Components and services are leveraged as appropriate, and the architecture also impacts how responsibilities are divided within the team.

See Practices 7, 1113, and 1517.

OpenUP/Basic is a subset of OpenUP, and is delivered through the EPF (see Appendix A). It is also the basis for RUP.