Unified Process (UP)

Unified Process (UP) The Unified Process (UP) combines commonly accepted best practices, such as an iterative lifecycle and risk-driven development, into a cohesive and well-documented description. The UP is used as an example process within which to explore requirements analysis and OOA/D.

Unified Process (UP) The UP promotes several best practices, but one stands above the others: iterative development. In this approach, development is organized into a series of short, fixed-length (for example, four week) mini-projects called iterations; The outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.

Unified Process (UP) 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. The system grows incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental development

The output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production-grade subset of the final system. each iteration tackles new requirements and incrementally extends the system, an iteration may occasionally revisit existing software and improve it; for example, one iteration may focus on improving the performance of a subsystem, rather than extending it with new features.

Phases of UP Inception Elaboration Construction Transition

Inception Most projects require a short initial step in which the following kinds of questions are explored: • What is the vision and business case for this project? • Feasible? • Buy and/or build? • Rough estimate of cost: Is it $10K-100K or in the millions? • Should we proceed or stop?

Inception Defining the vision and obtaining an order-of-magnitude (unreliable) estimate necessitates doing some requirements exploration. However, the purpose of the inception step is not to define all the requirements, or generate a believable estimate or project plan. the idea is to do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility. decide if it is worthwhile to invest in deeper exploration (the purpose of the elaboration phase).

Inception Thus, the inception phase should be relatively short. on many projects, if it is more than a week long, then the point of inception has been missed. It is to decide if the project is worth a serious investigation (during elaboration), not to do that investigation.

Inception Inception in one sentence: Envision the product scope, vision, and business case. The main problem solved in one sentence: Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?

Inception: An Analogy In the oil business, when a new field is being considered, some of the steps include: 1. Decide if there is enough evidence or a business case to even justify exploratory drilling. 2. If so, do measurements and exploratory drilling. 3. Provide scope and estimate information. 4. Further steps...

Inception: An Analogy In step one people do not predict how much oil there is, or the cost or effort to extract it. It is premature— there is insufficient information. Although it would be nice to be able to answer "how much" and "when" questions without the cost and effort of the exploration, in the oil business it is understood to not be realistic.

Inception artifacts and the issues they address

Inception artifacts and the issues they address

Elaboration Elaboration is the initial series of iterations during which: . the majority of requirements are discovered and stabilized . the major risks are mitigated . the core architectural elements are implemented and proven

Elaboration Elaboration is the initial series of iterations during which the team does serious investigation, implements (programs and tests) the core architecture, Clarifies most requirements, and tackles the high-risk issues.

Elaboration Elaboration often consists of between two and four iterations; each iteration is recommended to be between two and six weeks, Elaboration is not a design phase or a phase when the models are fully developed in preparation for implementation in the construction step. During this phase, one is not creating throw-away prototypes; rather, the code and design are production-quality portions of the final system. More commonly it is called the executable architecture or architectural baseline.

In iterative development and the UP it is understood that no matter how much due diligence is given to requirements specification, some change is inevitable, and should be acceptable. It does not benefit stakeholders to "wash their hands" of attentive engagement by signing off on a frozen set of requirements and waiting for the finished product, because they will seldom get what they really needed.

Construction By construction, the major requirements both functional and otherwise should be stabilized not finalized, but settled down to minor pertubation. Therefore, the SS and Vision are unlikely to experience much change in this phase.

Elaboration is followed by the construction phase, whose purpose is essentially to finish building the application, alpha testing, prepare for beta testing (in the transition phase), and prepare for deployment, through activities such as writing the user guides and online help

Transition Construction ends when the system is deemed ready for operational deployment, and all supporting materials are complete, such as user guides, training materials, and so on. It is followed by the transition phase, whose purpose is to put the system into production use.

Transition This may include activities such as beta testing, reacting to beta test feedback, fine-tuning, data conversion, training, marketing roll-out, parallel operation of the old and new system, and the like.