Unified Process


 * Inception
 * Elaboration
 * Construction
 * Transition

Unified Process is very flexible and open, and encourages including skillful practices from other iterative methods, e.g. Extreme Programming (XP), Scrum, etc.

Still, how to think and design with objects, apply UML, use design patterns, agile modeling, evolutionary requirements analysis, writing use cases, and so forth, are independent of any particular process. It will apply to many modern iterative, evolutionary, and agile methods, e.g. Scrum, Lean development, DSDM, Feature-Driven Development, and more.

Iterative and Evolutionary Development
Iterative development is organized into a series of short, fixed-length (e.g. three-week) iterations. The outcome is a tested, integrated, and executable partial system, including its own requirements analysis, design, implementation, and testing activities.

The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The result of each iteration is an executable but incomplete system.

Each iteration involves choosing a small subset of the requirements, and quickly designing, implementing, and testing. In addition to requirements clarification, activities such as load testing will prove if the partial design and implementation are on the right path, or if in the next iteration, a change in the core architecture is required. Better to resolve and prove the risky and critical design decisions early rather than late.

Consequently, work proceeds through a series of structured build-feedback-adapt cycles. Over time, the system converges towards the most appropriate requirements and design. In late iterations, a significant change in requirements is rare, but can occur. Such late changes may give an organization a competitive business advantage.

A key idea is that iterations are time-boxed, or fixed in length. If it seems that it will be difficult to meet the deadline, remove tasks or requirements from the iteration, and include them in a future iteration, rather than slip the completion date.

Risk-Driven and Client-Driven Iterative Planning
The UP encourage a combination of risk-driven and client-driven iterative planning. The goals of the early iterations is to identify and drive down the highest risks, and build visible features that the client cares most about.

Risk-driven iterative development includes more specifically the practice of architecture-centric iterative development, meaning that early iterations focus on building, testing, and stabilizing the core architecture. Not having a solid architecture is a common high risk.

Agile Modeling
Modeling should provide a way to better understand the problem or solution space, and the purpose of doing OOA/D (or UML) is to quickly explore the path to good OO design. Agile modeling implies a number of practices and values:
 * The purpose of models is to understand and communicate, not documentation.
 * Model and apply the UML for the smaller percentage of unusual, difficult, tricky parts of the design. Solve simple or straightforward design problems while programming.
 * Use the simplest tool possible, supporting rapid input and change. __Guideline:__ Sketch UML on whiteboards and capture it with a digital camera.
 * Model in pairs or triads. Start sketching a dynamic-view UML interaction diagram, and on another whiteboard, start sketching the complementary static-view UML class diagram. Develop the two models (two views) together, switching back and forth.
 * Exact UML details aren’t important, as long as the modelers understand each other. Stick to simple, frequently used UML elements.
 * All models will be inaccurate, and the final code or design different than the model. Only tested code demonstrates the true design; all prior diagrams are incomplete hints, best treated lightly as throw-away explorations.
 * Developers themselves should do the OO design modeling, for themselves, not to create diagrams that are given to other programmers to implement.

Adapt and apply UP in the spirit of adaptability and lightness, an agile UP:
 * Prefer a small set of UP activities and artifacts, keep it simple. Don’t create them unless they add value. Focus on early programming, not early documenting.
 * Requirements and designs are not completed before implementation. They adaptively emerge through a series of iterations, based on feedback.
 * Apply the UML with agile modeling practices.
 * There is a high-level Phase Plan that estimates the project end date and other major milestones, but it does not detail the fine-grained steps to those milestones. A detailed planning, an Iteration Plan, is done adaptively from iteration to iteration.

Development Case
A team should select a small subset of artifacts that address its problems and needs. Focus on a small set of artifacts that demonstrate high practical value.

The choice of practices and UP artifacts for a project may be written up in a short document called the Development Case (an artifact in the Environment discipline).