Slide 9.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach

Slide 9.2 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 9 THE WORKFLOWS AND PHASES OF THE UNIFIED PROCESS

Slide 9.3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l The Workflows of the Unified Process l The Phases of the Unified Process l Why A Two-Dimensional Model?

Slide 9.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Workflows of the Unified Process l There are five core workflows –Requirements workflow –Analysis workflow –Design workflow –Implementation workflow –Test workflow

Slide 9.5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Workflows of the Unified Process (contd) l In each increment, part of each of these five workflows is carried out

Slide 9.6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Workflows of the Unified Process (contd) l In addition to the five core workflows, the Unified Process includes other workflows –Management (Chapter 14) –Planning (Chapter 15) l In this chapter, just the five core workflows are considered

Slide 9.7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Requirements Workflow l The aim of the requirements workflow –To ensure that the developers build the right information system l Chapters 4 and 5 describe how this is done

Slide 9.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Analysis Workflow l The aim of the analysis workflow –To analyze and refine the requirements l Why not do this during the requirements workflow? –The requirements artifacts must be totally comprehensible by the client l The artifacts of the requirements workflow must therefore be expressed in a natural (human) language –All natural languages are imprecise

Slide 9.9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Analysis Workflow (contd) l Example from a manufacturing information system: –“A part record and a plant record are read from the database. If it contains the letter A directly followed by the letter Q, then calculate the cost of transporting that part to that plant” l To what does the it refer? –The part record? –The plant record? –Or the database?

Slide 9.10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Analysis Workflow (contd) l Two separate workflows are needed –The requirements artifacts must be expressed in the language of the client –The analysis artifacts must be precise, and complete enough for the designers l Chapters 6 and 7 describe how the analysis workflow is performed

Slide 9.11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Design Workflow l The aim of the design workflow is to refine the analysis workflow until the material is in a form that can be implemented by the programmers –Many nonfunctional requirements need to be finalized at this time, including »Choice of programming language »Reuse issues »Portability issues l Chapter 8 describes the design workflow

Slide 9.12 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Implementation Workflow l The aim of the implementation workflow is to implement the target information system in the selected implementation language –A large information system is partitioned into subsystems –The subsystems consist of components or code artifacts

Slide 9.13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Test Workflow l The test workflow is the responsibility of the quality assurance group –Each component is tested as it has been implemented »Unit testing –At the end of each iteration, the completed components are compiled and linked together (integrated) and tested »Integration testing –When the product appears to be complete, it is tested as a whole »Product testing –Once the completed product has been installed on the client’s computer, the client tests it »Acceptance testing

Slide 9.14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Phases of the Unified Process l In the figure, the increments are identified as phases

Slide 9.15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Phases of the Unified Process (contd) l The four increments are labeled –Inception phase –Elaboration phase –Construction phase –Transition phase l The phases of the Unified Process are the increments

Slide 9.16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Phases of the Unified Process (contd) l In theory, there could be any number of increments –In practice, development seems to consist of four increments l Every step performed in the Unified Process falls into –One of the five core workflows and also –One of the four phases l Why does each step have to be considered twice?

Slide 9.17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Phases of the Unified Process (contd) l Workflow –Presented in a technical context l Phase –Presented in a business context

Slide 9.18 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase l The aim of the inception phase is to determine whether the proposed information system is economically viable

Slide 9.19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase (contd) l 1.Gain an understanding of the domain l 2.Build the business model l 3.Delimit the scope of the proposed project –Focus on the subset of the business model that is covered by the proposed information system l 4.Begin to make the initial business case

Slide 9.20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase : The Initial Business Case l Questions that need to be answered include: –Is the proposed information system cost effective? –How long will it take to obtain a return on investment? –Alternatively, what will be the cost if the company decides not to develop the proposed information system? –If the information system is to be sold in the marketplace, have the necessary marketing studies been performed? –Can the proposed information system be delivered in time? –If the information system is to be developed to support the client organization’s own activities, what will be the impact if the proposed information system is delivered late?

Slide 9.21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: The Initial Business Case l What are the risks involved in developing the information system, and l How can these risks be mitigated? –Does the team who will develop the proposed information system have the necessary experience? –Is new hardware needed for this information system –If so, is there a risk that it will not be delivered in time? –If so, is there a way to mitigate that risk, perhaps by ordering back-up hardware from another supplier? –Are software tools (Chapter 11) needed? –Are they currently available? –Do they have all the necessary functionality?

Slide 9.22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: The Initial Business Case l Answers are needed by the end of the inception phase so that the initial business case can be made

Slide 9.23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: Use Cases and Risks l The next step: –Identify the use cases –Prioritize them in the order of the risk that they carry l There are three major risk categories: –Technical risks »See earlier slide –The risk of not getting the requirements right »Mitigated by performing the requirements workflow correctly –The risk of not getting the architecture right »The architecture may not be sufficiently robust

Slide 9.24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: Use Cases and Risks l To mitigate all three classes of risks –The use cases need to be prioritized in order of associated risk so that the critical risks are mitigated first l Now refine the use cases –Section 4.9 (Osbert Oglesby case study) –Sections 5.5 through 5.7 (MSG Foundation case study) l This concludes the steps of the inception phase that fall under the requirements workflow

Slide 9.25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: Analysis, Design Workflows l A small amount of the analysis workflow may be performed during the inception phase –A few critical use cases are analyzed, so that the design of the architecture can begin l Thus, a small amount of the design workflow may be performed, too

Slide 9.26 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: Implementation Workflow l Coding is generally not performed during the inception phase l Sometimes a proof-of-concept prototype is build to test the feasibility of part of the information system –This is not a rapid prototype constructed to be certain that the requirements have been accurately determined »Rapid prototyping is not part of the Unified Process –A proof-of-concept prototype is more like an engineering prototype »A scale model constructed to test the feasibility of construction

Slide 9.27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: Test Workflow l The test workflow commences almost at the start of the inception phase –The aim is to ensure that the requirements have been accurately determined

Slide 9.28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: Planning l There is insufficient information at the beginning of the inception phase to plan the entire development –The only planning that is done at the start of the project is the planning for the inception phase itself l For the same reason, the only planning that can be done at the end of the inception phase is the plan for just the next phase, the elaboration phase

Slide 9.29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: Documentation l The deliverables of the inception phase include: –The initial version of the domain model –The initial version of the business model –The initial version of the requirements artifact (especially the use cases) –A preliminary version of the analysis artifacts –A preliminary version of the architecture –The initial list of risks –The initial ordering of the use cases –The plan for the elaboration phase –The initial version of the business case

Slide 9.30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Inception Phase: The Initial Business Case l Obtaining the initial version of the business case is the overall aim of the inception phase l This initial version incorporates –A description of the scope of the information system –Financial details –If the proposed information system is to be marketed, the business case will also include »Revenue projections, market estimates, initial cost estimates –If the information system is to be used in-house, the business case will include »The initial cost–benefit analysis

Slide 9.31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Elaboration Phase l The aim of the elaboration phase is to refine the initial requirements –Refine the use cases –Refine the architecture –Monitor the risks and refine their priorities –Refine the business case –Produce the project management plan l The major activities of the elaboration phase are refinements or elaborations of the previous phase

Slide 9.32 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Tasks of the Elaboration Phase l The tasks of the elaboration phase correspond to: –All but completing the requirements workflow –Performing virtually the entire analysis workflow –Starting the design of the architecture

Slide 9.33 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Elaboration Phase: Documentation l The deliverables of the elaboration phase include: –The completed domain model –The completed business model –The completed requirements artifacts –The completed analysis artifacts –An updated version of the architecture –An updated list of risks –The project management plan (for the rest of the project) –The completed business case

Slide 9.34 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Construction Phase l The aim of the construction phase is to produce the first operational-quality version of the information system –This is sometimes called the beta release

Slide 9.35 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Tasks of the Construction Phase l The emphasis in this phase is on –Implementation, and –Testing »Unit testing of modules »Integration testing of subsystems »Product testing of the overall system

Slide 9.36 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Construction Phase: Documentation l The deliverables of the construction phase include: –The initial user manual and other manuals, as appropriate –All the artifacts (beta release versions) –The completed architecture –The updated risk list –The project management plan (for the remainder of the project) –If necessary, the updated business case

Slide 9.37 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Transition Phase l The aim of the transition phase is to ensure that the client’s requirements have indeed been met –Faults in the information system are corrected –All the manuals are completed –Attempts are made to discover any previously unidentified risks l This phase is driven by feedback from the site(s) at which the beta release has been installed

Slide 9.38 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Transition Phase: Documentation l The deliverables of the transition phase include: –All the artifacts (final versions) –The completed manuals

Slide 9.39 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. One- and Two-Dimensional Life-Cycle Models

Slide 9.40 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? l A traditional life cycle is a one-dimensional model –Represented by the single axis on the previous slide »Example: Waterfall model l The Unified Process is a two-dimensional model –Represented by the two axes on the previous slide l The two-dimensional figure shows –The workflows (technical contexts), and –The phases (business contexts)

Slide 9.41 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l The waterfall model of the MSG Foundation case study l One-dimensional

Slide 9.42 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l Evolution tree model of the MSG Foundation case study l Two-dimensional

Slide 9.43 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l Evolution tree model of the Winburg mini case study superimposed on the Unified Process l Two-dimensional

Slide 9.44 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l In reality, the development task is too big for this l As a consequence of Miller’s Law –The development task has to be divided into increments (phases) –Within each increment, iteration is performed until the task is complete

Slide 9.45 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l Are all the additional complications of the two- dimensional model necessary? l In an ideal world, each phase would be completed before the next phase was started

Slide 9.46 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l At the beginning of the process, there is not enough information about the information system to carry out the requirements workflow –Similarly for the other core workflows l An information system has to be broken into subsystems l Even subsystems can be too large at times –Modules may be all that can be handled until a fuller understanding of all the parts of the information system as a whole has been obtained

Slide 9.47 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l The Unified Process is the best solution found to date for treating a large problem as a set of smaller, largely independent subproblems –It provides a framework for incrementation and iteration l The Unified Process also handles the inevitable changes well –The moving target problem –The inevitable mistakes

Slide 9.48 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why A Two-Dimensional Model? (contd) l The Unified Process is currently the best methodology available –In the future, it will inevitably be superseded by some new methodology l Based on today’s knowledge, the Unified Process is better than any other alternative available today