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 InstructorClass Discussions / Presentations

© 2005 Ivar Jacobson International 2Iterative 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.


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 ModelingConfiguration …


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


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


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


…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.


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 CompleteProject Completed


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:


Inception

LCO: Viability Agreed

Elaboration

LCA: Selected Approach Proven

Construction

IOC: Usable Solution Availabl e

Transition

PR: Project Completed

Risk Focus: Business Risk Focus: Architectural Risk Focus: Logistical Risk 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:VisionBusiness caseRisksOverall project planList of critical use cases

Key Artifacts:Use-case model surveyDetailed descriptions for architecturally significant use-case flows and supplementary specificationsArchitectural descriptionArchitectural prototypesExecuted tests of the architecture

Key Artifacts:Use-case descriptionsSupplementary specificationsDesignsCodeTestsTest resultsTraining materialsUser documentation

Key Artifacts:Installers, including data conversionCustomer surveysDefects 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


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:


Inception

LCO: Viability Established

Elaboration


Construction

IOC: Usable Solution Available

Transition


Problem

Problem understoodValue and scope of solution establishedAlignment with business’ goals verifiedCritical requirements identified

Vision agreed uponRequirements stable[1]

Success evaluation criteria agreed upon

Requirements correctReady to deployAcceptance criteria agreed uponUser documentation available

Product acceptedRequirements completeProduct deployedUsers self-sufficient

Solution

Technical feasibility assessedSolution approach agreed uponCandidate architecture selected

Architecture provenExecutable architectural baseline availableCritical components definedBuild/buy/reuse decisions made

Implementation stableUseful, quality product availableProduct verifiedObjective quality information available

Product completeDesign completeCode completeMaintenance and support responsibilities handed over

Project

Critical risks identified and assessedStakeholder responsibilities definedProject objectives agreed uponProject constraints establishedLow-fidelity, lifecycle plan agreed uponCosts estimatedElaboration plans in place

Risks profile well understoodRisks under controlHigh-fidelity, comprehensive lifecycle plan agreed uponConstruction plans in place Accurate estimates for completion availableResource profile agreed uponCosts well understood

Transition plans in placeProject under controlImpact of outstanding changes understood

Stakeholders satisfiedNext evolution plannedProject closed down

[1] Stable, but not “frozen.”

Table 2: An Achievement-Based Overview of the UP Project Lifecycle

Stakeholder Domain Issues of Concern


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.


Table 3: An Activity-Based Overview of the UP Project Lifecycle

Inception

LCO: Viability Established

Elaboration


Construction

IOC: Usable Solution Available

Transition


Problem

Identify the architecturally significant requirementsUnderstand the target environmentsDefine the problemDetermine the value of solving the problem

Stabilize the requirementsDetail the critical requirementsElaborate on the vision

Complete the requirementsAuthor user documentationManage changing requirementsAssess user readinessRaise change requests

Perform acceptance testingTrain usersMarket the solutionManage change in the user communitySuggest improvementsReport defects and deficiencies

Solution

Explore possible solutionsEvaluate alternative solutionsSynthesize the architecture

Prove the architectureDevelop a prototype(s)Describe the architectureDescribe component interfacesSelect components

Develop componentsTest and assessmentRefine the architectureOptimize component design

Deploy to end-usersPrepare for support and maintenance of the system once it is deliveredCorrect defectsTune the applicationParallel operation and application migration

Project

Establish the project’s scopePlan lifecycleEstablish project costsBuild the business caseIdentify the critical risks

Track progressImprove estimatesPlan developmentControl risksElaborate upon the processEstablish the project infrastructureEstablish metricsResource the project

Impact analysisMonitor and control developmentPlan deploymentOptimize processMonitor risksCollect metrics Optimize resource usageControl costs

Assess the impact of changeSchedule changesHand over to production supportMonitor and control deploymentClose down the project

Key Activities from Perspective of the Stakeholders


• 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.


Table 4: A Discipline and Artifact Overview of the UP Project Lifecycle


Phases and Iterations – popular misconceptions

Next Phase

Iteration n + 1

Iteration n + n……

This Phase

Iteration1

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.


Common Misconceptions: Phases

Phase Incorrect Interpretation Correct Interpretation

Inception High-level requirements Business risks

ElaborationDetailed requirements and/or design

Architectural/technical risks

ConstructionImplementation and development; team testing

Logistical risks, (the risk of not getting all the work done)

Transition Acceptance testingSolution 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!


Common Misconceptions: Milestones

Milestone Incorrect Interpretation Correct 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!


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 requirethe 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.


The State at the End of Each Phase

Handout: OverviewOf The UP Lifecycle

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).

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.

ConstructionDeployable 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.


Summary: Phases, Iterations and Milestones

Major Milestones: Stakeholder Decision PointsProject Viability Agreed:ElaborationApproved

Selected ApproachProven: ProductionApproved

Usable Solution Available:Initial DeploymentApproved

Project Completed: Close DownAccepted

Project Started:InceptionApproved

Life

cycl

e O

bjec

tives

Life

cycl

e A

rchi

tect

ure

Initi

al O

pera

tiona

l Cap

abili

ty

Life

cycl

e C

ompl

ete

Proj

ect S

tart

Inception

I1

= Minor Milestones, Iteration Assessments and Releases

Elaboration

E1 E2

Construction

C1 C2

Transition

T1 T2

iterative project management chapter 3.2 – the unified process modified considerably by instructor...

Documents

project manager

costs of project

management frameworkeach

ivar jacobson international

good architecture

stable architecture

architecture stuff

logistical risks