Iterative Project Management Chapter 3.2 – The Unified Process Modified considerably by Instructor Class Discussions / Presentations

© 2005 Ivar Jacobson International 2 Iterative Project Management / 02 - Controlling an Iterative Project Objectives – Major sections: The Unified Process Phases –The UP provides a control framework for establishing objectives for iterations and to allow objective assessment of progress.

© 2005 Ivar Jacobson International 3 Iterative Project Management / 02 - Controlling an Iterative Project The Unified Process as a Management Framework Each phase in the software development life cycle (sequential) ends in the achievement of a major milestone for planning and control. Business Modeling Configuration …

© 2005 Ivar Jacobson International 4 Iterative Project Management / 02 - Controlling an Iterative Project The Inception Phase The goals of the Inception Phase: –Identify and mitigate business, project, and funding risks. –Assess the viability of the project, both technically and financially. –Agree to the scope and objectives of the project. –Form an overall plan for moving ahead. Main focus is on mitigating risk. Team explores benefits and costs of project so as to support a go / no-go decision to proceed. At end, stakeholders must agree –project is feasible, –business case is indeed achievable, –project is viable and worth doing, and –time and cost estimates are credible. Milestone: Lifecycle Objectives (LCO) Project Viability Agreed

© 2005 Ivar Jacobson International 5 Iterative Project Management / 02 - Controlling an Iterative Project The Elaboration Phase The goals of the Elaboration Phase: –Bring architectural and technical risks under control. –Establish and demonstrate a sound architectural foundation. –Establish a credible plan for the further development of the product –To stabilize the requirements  Here, we must ‘prove’ the architecture’  What does this mean to you?? Discuss!!  What is all this architecture stuff all about???? Must verify that the architecture will support the solution and eliminate the project’s highest risk items. At end, project manager may now plan activities and estimate required resources for the project. Risks are under control and architecture is stabilized (not frozen). Milestone: Lifecycle Architecture (LCA) Selected Approach Proven

© 2005 Ivar Jacobson International 6 Iterative Project Management / 02 - Controlling an Iterative Project The Construction Phase The goals of the Construction Phase: –Bring logistical risks under control. Logistical Risks?? –Develop the solution. –Ensure that the solution is ready for delivery to its user community. –Achieve adequate quality as rapidly as is practical. Most work centered here – at least 50%. Staff increased; work is in parallel (due to good architecture). –Not possible to work in parallel without a stable architecture.  At end, product is sufficiently complete and of sufficient quality to deliver to end users – in a beta deployment – with intent of having real users evaluate suitability for final release. To conclude: users must also be ready to accept the release. Milestone: Initial Operational Capability (IOC) Usable Solution Available

© 2005 Ivar Jacobson International 7 Iterative Project Management / 02 - Controlling an Iterative Project …a bit more on architecture… Architecture is characterized by a set of critical choices the development team makes about the solution. The team addresses: –Concurrency –Distribution –Security –Physical organization of the software components –Logical organization of the components –More…. Without a firm, stable architecture, changes later may cause major disruptions to schedule and may cause project failure.

© 2005 Ivar Jacobson International 8 Iterative Project Management / 02 - Controlling an Iterative Project The Transition Phase The goals of the Transition Phase: –Bring roll-out risks under control. –Deliver the solution to it’s end users. –Achieve user satisfaction and self-sufficiency Starts with beta deployment and concludes with final delivery. Here we fix remaining bugs, train users, provide for customer service, convert to new system, transition (run parallel, total ‘switch,’ parts at a time, etc.) to facilitate full deployment. Maintenance and support now handed off to others… Note: In the Unified Process the final milestone is called ‘Product Release’ – [the authors] have always found this to be confusing as the product is actually released before the end of the project. [The authors] find it easier to just call the milestone Lifecycle Complete as it represents the end of the project to develop the current major release. Milestone: Lifecycle Complete Project Completed

© 2005 Ivar Jacobson International 9 Iterative Project Management / 02 - Controlling an Iterative Project Additional views of phases and milestones One simple way is to consider simple questions that need to be addressed by each phase and what artifacts need to be produced to answer these questions. Consider the following tables:

© 2005 Ivar Jacobson International 10 Iterative Project Management / 02 - Controlling an Iterative Project Inception LCO:ViabilityAgreedLCO:ViabilityAgreed Elaboration LCA:SelectedApproachProvenLCA:SelectedApproachProven Construction I O C : U s a b l e S o l u ti o n A v a il a b l e Transition PR:ProjectCompletedPR:ProjectCompleted Risk Focus: BusinessRisk Focus: ArchitecturalRisk Focus: LogisticalRisk Focus: Roll-out Questions:  Are we building the right thing for the customer?  Is the solution feasible?  How much is it worth? Questions:  Do we know what we are building?  Do we know how we will build it?  Do we agree on what it is?  How much will it cost?  How will the technical risks be mitigated?  Can we prove that we can mitigate the technical risks? Questions:  Are we getting it done?  Will it be done on time?  Is it good enough?  Do our assumptions and earlier decisions hold?  Are the users ready? Questions:  Is it acceptable?  Is it being used?  Have we finished? Key Artifacts:  Vision  Business case  Risks  Overall project plan  List of critical use cases Key Artifacts:  Use-case model survey  Detailed descriptions for architecturally significant use- case flows and supplementary specifications  Architectural description  Architectural prototypes  Executed tests of the architecture Key Artifacts:  Use-case descriptions  Supplementary specifications  Designs  Code  Tests  Test results  Training materials  User documentation Key Artifacts:  Installers, including data conversion  Customer surveys  Defects and their resolutions Outcome:  Agreement to fund the project Outcome:  A stable, proven, executable architecture Outcome:  A useful, tested, deployable, and documented solution Outcome:  The solution is in “actual use” Table 1: A High-Level Overview of the RUP Project Lifecycle Questions / Artifacts, and Outcomes per Phase

© 2005 Ivar Jacobson International 11 Iterative Project Management / 02 - Controlling an Iterative Project Views by different stakeholders Stakeholders view the project according to their ‘domain’ of interest. Each stakeholder needs to feel good about the project and views the project via his/her perspective. Consider the achievements required in each domain to successfully complete the milestones for each stakeholder:

© 2005 Ivar Jacobson International 12 Iterative Project Management / 02 - Controlling an Iterative Project Inception L C O : V i a b il it y E s t a b li s h e d Elaboration LCA:SelectedApproachProvenLCA:SelectedApproachProven Construction I O C : U s a b l e S o l u ti o n A v a il a b l e Transition PR:ProjectCompletedPR:ProjectCompleted ProblemProblem  Problem understood  Value and scope of solution established  Alignment with business’ goals verified  Critical requirements identified  Vision agreed upon  Requirements stable [1]  Success evaluation criteria agreed upon  Requirements correct  Ready to deploy  Acceptance criteria agreed upon  User documentation available  Product accepted  Requirements complete  Product deployed  Users self-sufficient S o l u ti o n  Technical feasibility assessed  Solution approach agreed upon  Candidate architecture selected  Architecture proven  Executable architectural baseline available  Critical components defined  Build/buy/reuse decisions made  Implementation stable  Useful, quality product available  Product verified  Objective quality information available  Product complete  Design complete  Code complete  Maintenance and support responsibilities handed over ProjectProject  Critical risks identified and assessed  Stakeholder responsibilities defined  Project objectives agreed upon  Project constraints established  Low-fidelity, lifecycle plan agreed upon  Costs estimated  Elaboration plans in place  Risks profile well understood  Risks under control  High-fidelity, comprehensive lifecycle plan agreed upon  Construction plans in place  Accurate estimates for completion available  Resource profile agreed upon  Costs well understood  Transition plans in place  Project under control  Impact of outstanding changes understood  Stakeholders satisfied  Next evolution planned  Project closed down [1] Stable, but not “frozen.” Table 2: An Achievement-Based Overview of the UP Project Lifecycle Stakeholder Domain Issues of Concern

© 2005 Ivar Jacobson International 13 Iterative Project Management / 02 - Controlling an Iterative Project This Table provides Next table shows overview of key activities to be undertaken for each area and each phase – each taken from the perspective of the three stakeholder perspectives. We can see how they all unify the elements of our iterative project and we can start to understand the activities and achievements required in the iterations that will take place.

© 2005 Ivar Jacobson International 14 Iterative Project Management / 02 - Controlling an Iterative Project Table 3: An Activity-Based Overview of the UP Project Lifecycle Inception LCO:Viability EstablishedLCO:Viability Established Elaboration LCA:Selected Approach ProvenLCA:Selected Approach Proven Construction IOC:Usable Solution AvailableIOC:Usable Solution Available Transition PR:ProjectCompleted PR:ProjectCompleted ProblemProblem  Identify the architecturally significant requirements  Understand the target environments  Define the problem  Determine the value of solving the problem  Stabilize the requirements  Detail the critical requirements  Elaborate on the vision  Complete the requirements  Author user documentation  Manage changing requirements  Assess user readiness  Raise change requests  Perform acceptance testing  Train users  Market the solution  Manage change in the user community  Suggest improvements  Report defects and deficiencies S o l u ti o n  Explore possible solutions  Evaluate alternative solutions  Synthesize the architecture  Prove the architecture  Develop a prototype(s)  Describe the architecture  Describe component interfaces  Select components  Develop components  Test and assessment  Refine the architecture  Optimize component design  Deploy to end-users  Prepare for support and maintenance of the system once it is delivered  Correct defects  Tune the application  Parallel operation and application migration ProjectProject  Establish the project’s scope  Plan lifecycle  Establish project costs  Build the business case  Identify the critical risks  Track progress  Improve estimates  Plan development  Control risks  Elaborate upon the process  Establish the project infrastructure  Establish metrics  Resource the project  Impact analysis  Monitor and control development  Plan deployment  Optimize process  Monitor risks  Collect metrics  Optimize resource usage  Control costs  Assess the impact of change  Schedule changes  Hand over to production support  Monitor and control deployment  Close down the project Key Activities from Perspective of the Stakeholders

© 2005 Ivar Jacobson International 15 Iterative Project Management / 02 - Controlling an Iterative Project Now we may understand how to correctly interpret the risks associated with the phases and the achievements needed with the phase milestones needed to construct and to validate your iterative project plans Select certain activities to perform and artifacts to produce to demonstrate that risks have been mitigated and that you have achieved milestones for each phase. Much more later in other chapters.

© 2005 Ivar Jacobson International 16 Iterative Project Management / 02 - Controlling an Iterative Project Table 4: A Discipline and Artifact Overview of the UP Project Lifecycle

© 2005 Ivar Jacobson International 17 Iterative Project Management / 02 - Controlling an Iterative Project Phases and Iterations – popular misconceptions Next Phase Iteration n + 1 Iteration n + n …… This Phase Iteration 1 Iteration n …… Iterations take place within phases. The phases end in a go / no go milestone review. Also, time to evaluate and assess state of the project Milestone Review Requirements, design, testing, etc. are ‘disciplines’ and not phases. All disciplines are applied in every phase – to a greater or lesser degree. Purpose of a phase:mitigate some set of risks, not produce/complete a deliverable. More correct and easier to remember the risks associated within each phase.

© 2005 Ivar Jacobson International 18 Iterative Project Management / 02 - Controlling an Iterative Project Common Misconceptions: Phases PhaseIncorrect InterpretationCorrect Interpretation InceptionHigh-level requirementsBusiness risks Elaboration Detailed requirements and/or design Architectural/technical risks Construction Implementation and development; team testing Logistical risks, (the risk of not getting all the work done) TransitionAcceptance testing Solution roll-out (delivery) risks At end of phases, we do not assert: ‘planning completed;’ ‘specs completed;’ ‘coding complete,’ etc…. Milestones achieved as indicated below: NO! Yes!

© 2005 Ivar Jacobson International 19 Iterative Project Management / 02 - Controlling an Iterative Project Common Misconceptions: Milestones MilestoneIncorrect InterpretationCorrect Interpretation Lifecycle Objectives (LCO) Planning completed Project viability has been confirmed by stakeholders Lifecycle Architecture (LCA) Specification completed The selected approach has been proved via developer testing Initial Operational Capability (IOC) Coding completed A useable solution is available [1] Lifecycle Complete (LCC) Product available/deployed The project is complete [1] Typically in the form of a beta release Still more popular misconceptions for Milestones : NO! Yes!

© 2005 Ivar Jacobson International 20 Iterative Project Management / 02 - Controlling an Iterative Project Common Misconceptions: The Iterative Lifecycle Each phase includes iterations through the phases –Iterations – smallest time period that is measured. You can’t build any software unless you are in construction –False –Some software is built in every phase. –In Inception, prove solution is viable; elaboration: focus on technical approach is viable…. You can be in more than one phase at a time –Simply NOT TRUE! Phases are achievement-oriented and require the phase’s milestones to be achieved before moving on. You can’t change the architecture after the end of elaboration –Yes, but: further changes may be subjected to a rigid change control process….. Phases can be time boxed – simply not true. The phases don’t apply to all projects –They do, but not necessarily to the same extent.

© 2005 Ivar Jacobson International 21 Iterative Project Management / 02 - Controlling an Iterative Project The State at the End of Each Phase Handout: Overview Of The UP Lifecycle PhaseProject StateOutcome Inception The stakeholders are discussing the value and feasibility of the solution. The approach to be taken is been agreed. Project viability agreed. Agreement to fund the Project (Elaboration at least). Elaboration Demonstrable, executable versions of the system are being produced to actively mitigate the most serious project risks and prove the approach selected. Selected approach proven. A stable, proven, executable architecture. Construction Deployable solutions, that work end-to-end, are being regularly produced. Useable solution available A useful, tested, deployable, and documented solution Transition The new system is being supported in the live environment. Feedback is being generated from actual system use. Project complete. The solution is in ‘actual’ use. A common mistake is to consider the phases to be time boxes, just bigger boxes than iterations. This is incorrect because the phase is not over until you have achieved it’s milestone. as opposed to an iteration, which is shut down when the time runs out and the next iteration starts, Phases do not end just because you have the scheduled milestone review or the end of phase date passes. The project is still in Elaboration phase until Lifecycle Architecture milestone is accommodated, if, in fact, it is accommodated - regardless of what the schedule says or how much you want the phase to be over.

© 2005 Ivar Jacobson International 22 Iterative Project Management / 02 - Controlling an Iterative Project Summary: Phases, Iterations and Milestones Major Milestones: Stakeholder Decision Points Project Viability Agreed: Elaboration Approved Selected Approach Proven: Production Approved Usable Solution Available: Initial Deployment Approved Project Completed: Close Down Accepted Project Started: Inception Approved Lifecycle Objectives Lifecycle Architecture Initial Operational Capability Lifecycle Complete Project Start Inception I1 = Minor Milestones, Iteration Assessments and Releases Elaboration E1E2 Construction C1C2 Transition T1T2