Скачать презентацию Iterative Project Management Chapter 3 2 The Скачать презентацию Iterative Project Management Chapter 3 2 The

678b35920e7031c459843183e1208dc6.ppt

  • Количество слайдов: 22

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

Objectives – Major sections: • The Unified Process Phases – The UP provides a 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 Iterative Project Management / 02 - Controlling an Iterative Project 2

The Unified Process as a Management Framework Each phase in the software development life 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 Iterative Project Management / 02 - Controlling an Iterative Project 3

The Inception Phase • The goals of the Inception Phase: – – Identify and 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 Iterative Project Management / 02 - Controlling an Iterative Project 4

The Elaboration Phase • The goals of the Elaboration Phase: – – Bring architectural 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 Iterative Project Management / 02 - Controlling an Iterative Project 5

The Construction Phase • The goals of the Construction Phase: – – Bring logistical 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 Iterative Project Management / 02 - Controlling an Iterative Project 6

…a bit more on architecture… • Architecture is characterized by a set of critical …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 Iterative Project Management / 02 - Controlling an Iterative Project 7

The Transition Phase • • The goals of the Transition Phase: – Bring roll-out 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 Iterative Project Management / 02 - Controlling an Iterative Project 8

Additional views of phases and milestones • One simple way is to consider simple 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 Iterative Project Management / 02 - Controlling an Iterative Project 9

Table 1: A High-Level Overview of the RUP Project Lifecycle Inception Elaboration Risk Focus: Table 1: A High-Level Overview of the RUP Project Lifecycle Inception Elaboration Risk Focus: Business Risk Focus: Architectural 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? Key Artifacts: Vision Business case Risks Overall project plan List of critical use cases Outcome: Agreement to fund the project L C O : V i a b i l i t y A g r e e d Key Artifacts: Use-case model survey Detailed descriptions for architecturally significant usecase flows and supplementary specifications Architectural description Architectural prototypes Executed tests of the architecture Outcome: A stable, proven, executable architecture L C A : S e l e c t e d A p p r o a c h P r o v e n Construction Risk Focus: Logistical 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? Key Artifacts: Use-case descriptions Supplementary specifications Designs Code Tests Test results Training materials User documentation Outcome: A useful, tested, deployable, and documented solution 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 Risk Focus: Roll-out Questions: Is it acceptable? Is it being used? Have we finished? Key Artifacts: Installers, including data conversion Customer surveys Defects and their resolutions Outcome: The solution is in “actual use” P R : P r o j e c t C o m p l e t e d Questions / Artifacts, and Outcomes per Phase © 2005 Ivar Jacobson International Iterative Project Management / 02 - Controlling an Iterative Project 10

Views by different stakeholders • Stakeholders view the project according to their ‘domain’ of 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 Iterative Project Management / 02 - Controlling an Iterative Project 11

Table 2: An Achievement-Based Overview of the UP Project Lifecycle Inception P r o Table 2: An Achievement-Based Overview of the UP Project Lifecycle Inception P r o b l e m Problem understood Value and scope of solution established Alignment with business’ goals verified Critical requirements identified S o l u ti o n Technical feasibility assessed Solution approach agreed upon Candidate architecture selected 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 [1] Stable, but not “frozen. ” © 2005 Ivar Jacobson International P r o j e c t Elaboration L C O : V i a b il it y E s t a b li s h e d Vision agreed upon Requirements stable[1] Success evaluation criteria agreed upon Architecture proven Executable architectural baseline available Critical components defined Build/buy/reuse decisions made 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 L C A : S e l e c t e d A p p r o a c h P r o v e n Construction Requirements correct Ready to deploy Acceptance criteria agreed upon User documentation available Implementation stable Useful, quality product available Product verified Objective quality information available Transition plans in place Project under control Impact of outstanding changes understood Transition I O C : U s a b l e S o l u ti o n A v a il a b l e Product accepted Requirements complete Product deployed Users self-sufficient Product complete Design complete Code complete Maintenance and support responsibilities handed over Stakeholders satisfied Next evolution planned Project closed down P R : P r o j e c t C o m p l e t e d Stakeholder Domain Issues of Concern Iterative Project Management / 02 - Controlling an Iterative Project 12

This Table provides • Next table shows overview of key activities to be undertaken 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 Iterative Project Management / 02 - Controlling an Iterative Project 13

Table 3: An Activity-Based Overview of the UP Project Lifecycle Inception P r o Table 3: An Activity-Based Overview of the UP Project Lifecycle Inception P r o b l e m Identify the architecturally significant requirements Understand the target environments Define the problem Determine the value of solving the problem S o l u ti o n Explore possible solutions Evaluate alternative solutions Synthesize the architecture P r o j e c t Establish the project’s scope Plan lifecycle Establish project costs Build the business case Identify the critical risks Elaboration L C O : V i a b i l i t y E s t a b l i s h e d Stabilize the requirements Detail the critical requirements Elaborate on the vision Prove the architecture Develop a prototype(s) Describe the architecture Describe component interfaces Select components Track progress Improve estimates Plan development Control risks Elaborate upon the process Establish the project infrastructure Establish metrics Resource the project L C A : S e l e c t e d A p p r o a c h P r o v e n Construction Complete the requirements Author user documentation Manage changing requirements Assess user readiness Raise change requests Develop components Test and assessment Refine the architecture Optimize component design Impact analysis Monitor and control development Plan deployment Optimize process Monitor risks Collect metrics Optimize resource usage Control costs I O C : U s a b l e S o l u t i o n A v a i l a b l e Transition Perform acceptance testing Train users Market the solution Manage change in the user community Suggest improvements Report defects and deficiencies 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 Assess the impact of change Schedule changes Hand over to production support Monitor and control deployment Close down the project P R : P r o j e c t C o m p l e t e d Key Activities from Perspective of the Stakeholders © 2005 Ivar Jacobson International Iterative Project Management / 02 - Controlling an Iterative Project 14

 • Now we may understand how to correctly interpret the risks associated with • 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 Iterative Project Management / 02 - Controlling an Iterative Project 15

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

Phases and Iterations – popular misconceptions Requirements, design, testing, etc. are ‘disciplines’ and not Phases and Iterations – popular misconceptions 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. This Phase Iteration 1 …… Next Phase Milestone Review Iteration n+1 …… Iteration n+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 © 2005 Ivar Jacobson International Iterative Project Management / 02 - Controlling an Iterative Project 17

Common Misconceptions: Phases At end of phases, we do not assert: ‘planning completed; ’ Common Misconceptions: Phases At end of phases, we do not assert: ‘planning completed; ’ ‘specs completed; ’ ‘coding complete, ’ etc…. Milestones achieved as indicated below: NO! Yes! Phase Incorrect Interpretation Correct Interpretation Inception High-level requirements Business 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) Transition Acceptance testing Solution roll-out (delivery) risks © 2005 Ivar Jacobson International Iterative Project Management / 02 - Controlling an Iterative Project 18

Common Misconceptions: Milestones Still more popular misconceptions for Milestones: NO! Milestone Yes! Incorrect Interpretation Common Misconceptions: Milestones Still more popular misconceptions for Milestones: NO! Milestone Yes! Incorrect Interpretation Correct Interpretation 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 Lifecycle Objectives (LCO) [1] Typically in the form of a beta release © 2005 Ivar Jacobson International Iterative Project Management / 02 - Controlling an Iterative Project 19

Common Misconceptions: The Iterative Lifecycle • Each phase includes iterations through the phases – 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 Iterative Project Management / 02 - Controlling an Iterative Project 20

The State at the End of Each Phase Project State Outcome Inception The stakeholders The State at the End of Each Phase Project State Outcome 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). 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. Deployable solutions, that work end-to-end, are being regularly produced. Useable solution available A useful, tested, deployable, and documented solution 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. Elaboration Construction Transition 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 Handout: Overview phase to be over. Of The UP Lifecycle © 2005 Ivar Jacobson International Iterative Project Management / 02 - Controlling an Iterative Project 21

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