To be called a UP project, it arguably should illustrate at least the following:
Follow the UP guidelines and best practices.
Create at least a couple of UP artifacts, such as the Vision and Risk List.
- Conform to the UP workproduct names rather than use other or prior names, to establish a common vocabulary.
Organize the iterations and milestone goals according the goals of inception, elaboration, construction, and transition.
Although the original UP creators had in mind a preference for a relatively light approach to process, this was not well communicated in their early learning aids. In their more recent material, this has improved. For example, [KK03] presents the "spirit of the RUP" guidelines for success core attitudes to hold on a UP/RUP project:
Attack risks early and continuously, or they will attack you.
Deliver value to your customer early and often.
Stay focused on developing executable software in early iterations, not specifications or other documents.
Accommodate change early in the project. Provoke and managing change via early development, multiple requirements workshops, change management tools, and so on.
Baseline an executable architecture early.
Prefer component-oriented architectures and the reuse of existing components.
Work together as one team (e.g., cross-functional teams)
Quality is a way of life, not an afterthought.
The Six Best Practices
The UP is not really limited to only six best practices, but these are an important minimal set to focus on. UP adopters should understand these practices, and most or all should be applied on UP projects:
The most important of the UP practices is to develop using timeboxed iterations, recommended between two and six weeks. In other words, do not apply a waterfall lifecycle or attempt to do thorough requirements analysis first. Rather as with all iterative lifecycle processes start programming early, when only a portion of the most significant requirements are understood in detail. Refine the requirements and design based on feedback and adaptation from the programming effort instead of attempting large, up-front requirements analysis or speculative "Power Point architectures."
Emphasize programming the high-risk and high-value elements, and a cohesive architecture in early iterations, and strive to re-use existing components large and small to reduce new code and defects. For large projects, ideally the requirements analysis and core architecture is developed by a co-located small team; later, the early team members divide into subproject leaders coaching subteams doing parallel development.
Continuously verify quality. Test early, often, and realistically by integrating and testing all the software each iteration unit, system, and load testing. This best practice includes techniques such as test-driven development and continuous integration, both promoted in XP. Plus, it extends beyond code to include early verification of usability, the quality of non-code artifacts (such as requirements), and of the process itself via regular team meetings to reflect on the value or lack thereof in different activities.
Before starting programming in an iteration, do at least a little visual modeling, such as sketching at the whiteboard for an hour, to explore and communicate creative design ideas while ignoring low-level code details. Oftentimes, sketches will be loosely based on the industry-standard Unified Modeling Language (UML). Practices promoted by Agile Modeling, such as creating multiple visual models in parallel, using digital cameras to capture sketches, and so on, are applicable to this best practice. Sometimes, CASE tools for visual modeling can add value, to regularly reverse engineer the growing code base into UML diagrams that offer a big-picture view of the software.
Manage requirements through skillful means to find, organize, and track them. Find and refine requirements iteratively and incrementally rather than via major up-front analysis for example, through a series (once per iteration) of short timeboxed one-day requirements workshops in the early phases of the project. Where suitable, find functional requirements by writing use cases to record functional requirements, rather than older-style function lists. Using a tool, organize requirements with attributes, such as risk, priority, and status (e.g., new, assigned), and with traceability to other dependent requirements, so that they can be analyzed; using a tool for this task is especially valuable on large projects where it is difficult for any one person to envision and reason about all the requirements. And using a tool, track the status of requirements so that we know what's finished, underway, and so forth.
Manage change through disciplined configuration management and version control, a change request protocol, and baselined releases at the end of each iteration.
The workproduct diagram (p. 184) shows a subset of common UP workproducts (artifacts). There are approximately 50 in total. The details are outside the scope of this introduction; see [Larman01] for many examples, or the RUP product.
Important overarching points regarding the UP workproducts:
Unfair criticism? Some have criticized the UP as having too many workproducts in comparison with some other IID methods. Yet, when you examine the full UP list, it contains workproducts such as Release Notes, Bill of Materials, Training Materials, and so forth. These are workproducts that a team makes for many products, regardless of method. It is just that the UP has identified them, whereas XP and Scrum, for example, have not. And, all are optional.
Common vocabulary For larger organizations, especially those with hundreds of developers or multiple offices, it is useful to have a common vocabulary of workproducts (Vision, Software Architecture Document, etc.). It helps communication between people and offices. It helps during scavenging for reusable artifacts from prior projects.
Information abstractions The UP artifacts are information abstractions rather than concrete computer documents, although the RUP product provides sample document templates. The Risk List can be a poster on the wall; the Software Architecture Document can be a video; the Design Model can be UML-ish whiteboard sketches captured on a digital camera.
Other Practices and Values
Absorbing practices The UP is a broad and general IID process definition. It defines or endorses many detailed practices, both "local" to the UP or adopted from other methods, such as XP testing or Scrum meetings. Note that many practices, such as XP's test-driven development, are specializations or variations of the UP practices, such as continuously verify quality. If the RUP product is used, the "RUP Builder" can configure the process definition to include documentation on absorbed practices.
Use-case driven The UP does not require the application of use cases to capture functional requirements; feature lists and feature-driven development are possible. However, when use cases are suitable for the problem domain, their use is encouraged in the UP. In that case, the UP recommends organizing iterations by scenarios of use cases, tackling the most architecturally significant, risky, and highest business value scenarios early. Then, one designs and implements to fulfill use case scenarios. Further, the UP recommends basing system-level acceptance tests on these scenarios. Thus, use cases drive the iterative development and acceptance testing.
iteration planning with use cases and scenarios