UNIT- III : Model based software architectures: A Management perspective and technical perspective.

Work Flows of the process: Software process workflows, Iteration workflows.

Checkpoints of the process: Major mile stones, Minor Milestones, Periodic status assessments.
Iterative Process Planning: Work breakdown structures, planning guidelines, cost and schedule estimating, Iteration
planning process, Pragmatic planning.

Model based software architecture

The most critical technical product of a software project is its architecture

Froma managementperspective,therearethreedifferentaspectsofarchitecture.
1. An architecture (the intangible design concept) is the design of a software system this includes
allengineeringnecessary tospecify a complete bill ofmaterials.
2. An architecture baseline (the tangible artifacts) is a slice of information across the
engineeringartifactsetssufficienttosatisfyallstakeholdersthatthevision(functionandquality)canbeachie
vedwithin theparametersof thebusinesscase(cost, profit,time, technology,and people).
3. An architecture description (a human-readable representation of an architecture, which is one of
thecomponents of an architecture baseline) is an organized subset of information extracted from
thedesignsetmodel(s).Thearchitecturedescriptioncommunicateshowtheintangibleconceptisrealizedin
the tangible artifacts.

The importance of software architecture and its close linkage with modern software development processes
canbesummarized as follows:
 Achievingastablesoftwarearchitecturerepresentsasignificantprojectmilestoneatwhichthecriticalmake/
buy decisions should have beenresolved.
 Architecturerepresentationsprovideabasisforbalancingthetrade-
offsbetweentheproblemspace(requirementsand constraints) and the solutionspace (the operational
product).
 Thearchitectureandprocessencapsulatemanyoftheimportant(high-payofforhigh-
risk)communicationsamong individuals,teams, organizations, andstakeholders.
 Poorarchitecturesandimmatureprocessesareoften givenasreasonsforprojectfailures.
 Amatureprocess,anunderstandingoftheprimaryrequirements,andademonstrablearchitectureareimporta
ntprerequisites for predictable planning.
 Architecturedevelopmentandprocessdefinitionaretheintellectualstepsthatmaptheproblemtoasolutionwi
thoutviolating theconstraints; theyrequire humaninnovationandcannot beautomated.

ARCHITECTURE:ATECHNICALPERSPECTIVE
An architecture framework is defined in terms of views that are abstractions of the UML models in the designset.

The purposesof these viewsareas follows:

 Design:describesarchitecturallysignificantstructuresand functionsofthedesignmodel
 Process:describesconcurrencyandcontrolthreadrelationshipsamongthedesign,component,anddeploy
mentviews
 Component:describesthestructureofthe implementationset
 Deployment:describesthestructureofthedeploymentset
 Therequirementsmodeladdressesthebehaviorofthesystemasseenbyitsendusers,analysts,andtesters.
 The use case viewdescribes how the system's critical(architecturally significant) use cases arerealized by
elements of the design model.
 Thedesignviewdescribesthearchitecturallysignificantelementsofthedesignmodel.Thisview,an abstraction of the
design model, addresses the basic structure and functionality of the solution.
 Theprocessviewaddressestherun-timecollaborationissuesinvolvedinexecutingthearchitectureon a distributed
deployment model
 The component viewdescribes the architecturally significant elements of the implementation set.
 The deployment view addresses the executable realization of the system, including the allocation oflogical
processes in the distribution view (the logical software topology) to physical resources of thedeployment
network (the physical system topology).

Generally,an architecturebaseline should includethe following:

 Requirements: critical use cases, system-level quality objectives, and priority relationships
amongfeatures andqualities
Design: names,attributes,structures,behaviors,groupings,andrelationships
ofsignificantclassesandcomponents
 Implementation:source componentinventoryandbillof materials(number,name,purpose,cost)
ofallprimitive components
Deployment: executablecomponentssufficienttodemonstratethecriticaluse casesandthe
riskassociatedwith achieving the systemqualities

Workflowof the process

SOFTWAREPROCESSWORKFLOWS
ThetermWORKFLOWSisusedtomeanathreadofcohesiveandmostlysequentialactivities.Workflowsaremappedto
product artifacts There are seven top-level workflows:
1.Managementworkflow: controllingthe processand ensuringwin conditions forall stakeholders
2. Environmentworkflow:automatingthe processandevolvingthemaintenanceenvironment
3. Requirementsworkflow:analyzingthe problemspaceandevolving therequirementsartifacts
4. Designworkflow: modeling thesolution andevolvingthe architectureand designartifacts
5. Implementationworkflow:programmingthecomponentsandevolvingtheimplementationanddeployment
artifacts
6. Assessmentworkflow:assessingthe trendsinprocessand productquality
7. Deployment workflow:transitioningtheend productstotheuser
Figureillustratestherelativelevelsof effortexpected acrossthe phases ineach ofthe top-levelworkflows.

shows the allocation of artifacts and the emphasis of each workflow in each of the life-cycle phases
ofinception,elaboration, construction,and transition.
ITERATIONWORKFLOWS
Iterationconsistsofalooselysequentialsetofactivitiesinvariousproportions,dependingonwheretheiteration is
located in the development cycle. Each iteration is defined in terms of a set of allocated
usagescenarios.Anindividualiteration'sworkflow,illustratedinFigure8-2,generallyincludesthefollowingsequence:
 Management: iteration planning to determine the content of the release and develop the detailed
planforthe iteration; assignment of work packages, ortasks, tothe developmentteam
 Environment: evolving the software change order database to reflect all new baselines and changes
toexistingbaselines for allproduct,test, and environment components

 Requirements: analyzing the baseline plan, the baseline architecture, and the baseline
requirementsset artifacts to fully elaborate the use cases to be demonstrated at the end of this
 iteration and theirevaluation criteria; updating any requirements set artifacts to reflect changes
necessitated by resultsofthis iteration's engineering activities
 Design: evolving the baseline architecture and the baseline design set artifacts to elaborate fully
thedesign model and test model components necessary to demonstrate against the evaluation
criteriaallocatedtothisiteration;updatingdesignsetartifactstoreflectchangesnecessitatedbytheresultsofth
is iteration's engineering activities
 Implementation: developing or acquiring any new components, and enhancing or modifying
anyexisting components, to demonstrate the evaluation criteria allocated to this iteration; integrating
andtestingall new andmodified components withexisting baselines (previousversions)
 Assessment:evaluatingtheresultsoftheiteration,includingcompliancewiththeallocatedevaluation
criteria and the quality of the current baselines; identifying any rework required anddetermining
whetherit shouldbeperformedbeforedeploymentof this releaseor allocated to thenextrelease;
assessing resultstoimprove the basis ofthe subsequent iteration's plan
 Deployment: transitioning the release either to an external organization (such as a user,
independentverification and validation contractor, or regulatory agency) or to internal closure by
conducting apost-mortemso thatlessons learnedcanbe captured and reflected inthe next iteration
Iterations in the inception and elaboration phases focus on management. Requirements, and design
activities.Iterationsintheconstructionphasefocusondesign,implementation,andassessment.Iterationsinthetransitio
n phase focus on assessment and deployment. Figure 8-3 shows the emphasis on different activitiesacross the
life cycle. An iteration represents the state of the overall architecture and the complete
deliverablesystem.Anincrementrepresentsthecurrentprogressthatwillbecombinedwiththeprecedingiterationtofro
m the next iteration. Figure 8-4, an example of a simple development life cycle, illustrates the
differencesbetweeniterations and increments.
Checkpoints ofthe process
Threetypesofjointmanagementreviews areconductedthroughouttheprocess:

1. Major milestones. These system wide events are held at the end of each development phase.
Theyprovide visibility to system wide issues, synchronize the management and engineering
perspectives,andverify that theaims of the phase have been achieved.
2. Minor milestones. These iteration-focused events are conducted to review the content of an
iterationindetail andto authorizecontinuedwork.
3. Status assessments. These periodic events provide management with frequent and regular
insightintothe progress being made.

Each of the four phases-inception, elaboration, construction, and transitionconsists of one or more
iterations.An iteration represents a cycle of activities for which there is a well-defined intermediate
result-a minormilestone-captured with two artifacts: a release specification (the evaluation criteria and
plan) and a releasedescription (the results). Major milestones at the end of each phase use formal,
stakeholder-approved evaluationcriteria and release descriptions; minor milestones use informal,
development-team-controlled versions of theseartifacts.
9.1 MAJORMILESTONES
The four major milestones occur at the transition points between life-cycle phases. They can be used in
manydifferent process models, including the conventional waterfall model. In an iterative model, the
majormilestonesareusedtoachieveconcurrence amongallstakeholdersonthe
currentstateoftheproject.Differentstakeholdershave very different concerns:

 Customers:scheduleandbudgetestimates,feasibility,riskassessment,requirementsunderstanding,progr
ess,product line compatibility
 Users:consistencywithrequirements andusagescenarios,
potentialforaccommodatinggrowth,quality attributes
 Architectsandsystemsengineers:productlinecompatibility,requirementschanges,trade-
offanalyses,completenessand consistency, balanceamong risk,quality, andusability
 Developers: sufficiency of requirements detail and usage scenario descriptions, . frameworks
forcomponentselectionordevelopment,resolutionofdevelopmentrisk,productlinecompatibility,sufficien
cyof the development environment
 Maintainers: sufficiency of product and documentation artifacts, understandability,
interoperabilitywithexisting systems, sufficiency of maintenance environment
 Others: possibly many other perspectives by stakeholders such as regulatory agencies,
independentverification and validation contractors, venture capital investors, subcontractors, associate
contractors,andsalesand marketingteams
Life-CycleObjectivesMilestone
The life-cycle objectives milestone occurs at the end of the inception phase. The goal is to present to
allstakeholders a recommendation on how to proceed with development, including a plan, estimated cost
andschedule, and expected benefits and cost savings. A successfully completed life-cycle objectives milestone
willresultin authorization fromall stakeholderstoproceed withthe elaboration phase.
Life-CycleArchitectureMilestone
Thelife-cyclearchitecturemilestoneoccursattheendoftheelaborationphase.Theprimarygoalistodemonstrate an
executable architecture to all stakeholders. The baseline architecture consists of both a human-readable
representation (the architecture document) and a configuration-controlled set of software componentscaptured
in the engineering artifacts. A successfully completed life-cycle architecture milestone will result
inauthorizationfromthe stakeholders to proceed with the construction phase.

The technical data listed in Figure 9-2 should have been reviewed by the time of the lifecycle
architecturemilestone.Figure 9-3 provides default agendas for this milestone.
 InitialOperationalCapabilityMilestone
The initial operational capability milestone occurs late in the construction phase. The goals are to assess
thereadiness of the software to begin the transition into customer/user sites and to authorize the start of
acceptancetesting. Acceptance testing can be done incrementally across multiple iterations or can be completed
entirelyduringthe transition phase isnot necessarilythe completion ofthe construction phase.
ProductRelease Milestone
The product release milestone occurs at the end of the transition phase. The goal is to assess the completion
ofthesoftwareanditstransitiontothesupportorganization,ifany.Theresultsofacceptancetestingarereviewed,andallo
penissuesareaddressed.Softwarequalitymetricsarereviewedtodeterminewhetherqualityis sufficient for
transitionto the support organization.

9.2 MINORMILESTONES
For most iterations, which have a one-month to six-month duration, only two minor milestones are needed:
theiterationreadiness review and the iteration assessment review.
 Iteration Readiness Review. This informal milestone is conducted at the start of each iteration
toreviewthe detailediteration planandtheevaluation criteria thathave beenallocatedtothis iteration.
 Iteration Assessment Review. This informal milestone is conducted at the end of each iteration
toassess the degree to which the iteration achieved its objectives and satisfied its evaluation criteria,
toreview iteration results, to review qualification test results (if part of the iteration), to determine
theamount of rework to be done, and to review the impact of the iteration results on the plan
forsubsequentiterations.
Theformatandcontentoftheseminormilestonestendtobehighlydependentontheprojectandtheorganizational
culture. Figure 9-4 identifies the various minor milestones to be considered when a project isbeing planned.
9.3 PERIODICSTATUSASSESSMENTS
Periodic status assessments are management reviews conducted at regular intervals (monthly, quarterly)
toaddress progress and quality indicators, ensure continuous attention to project dynamics, and maintain
opencommunicationsamong all stakeholders.
Periodic status assessments serve as projectsnapshots. While the period may vary, the recurring event
forcestheproject history tobecaptured and documented.Status assessments providethe following:
 A mechanism for openly addressing, communicating, and resolving management issues,
technicalissues,and project risks
 Objectivedataderived directlyfromon-going activitiesandevolvingproductconfigurations
 Amechanismfordisseminatingprocess,progress,qualitytrends,practices,andexperienceinformationto and
fromall stakeholders inan open forum
Periodic status assessments are crucial for focusing continuous attention on the evolving health of
theproject and its dynamic priorities. They force the software project manager to collect and review the
dataperiodically,forceoutsidepeerreview,andencouragedisseminationofbestpracticestoandfromotherstakeholders.

Thedefaultcontentof periodicstatusassessmentsshould includethetopicsidentifiedinTable9-2.

10. Iterativeprocessplanning
A good work breakdown structure and its synchronization with the process framework are critical factors
insoftware project success. Development of a work breakdown structure dependent on the project
managementstyle,organizationalculture,customerpreference,financialconstraints,andseveralotherhard-to-
define,project-specificparameters.
A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete work tasks.
AWBSprovides the following information structure:
  Adelineationofallsignificantwork
 Acleartaskdecompositionforassignmentofresponsibilities
 Aframeworkforscheduling, budgeting,andexpendituretracking
Many parameters can drive the decomposition of work into discrete tasks: product subsystems,
components,functions, organizational units, life-cycle phases, even geographies. Most systems have a first-
leveldecompositionbysubsystem.Subsystemsarethendecomposedintotheircomponents,oneofwhichistypicallythe
software.

10.1.1 CONVENTIONALWBSISSUES
Conventionalwork breakdown structuresfrequentlysuffer fromthree fundamentalflaws.

1. Theyareprematurelystructuredaroundtheproductdesign.
2. Theyareprematurely decomposed,planned, andbudgetedineithertoo muchortoolittledetail.
3. Theyareproject-specific,andcross-projectcomparisonsareusuallydifficultorimpossible.
Conventional work breakdown structures are prematurely structured around the product design. Figure 10-
1shows a typical conventional WBS that has been structured primarily around the subsystems of its
productarchitecture,thenfurtherdecomposedintothecomponentsofeachsubsystem.AWBSisthearchitecturefort
he financialplan.
Conventional work breakdown structures are prematurely decomposed, planned, and budgeted in either
toolittle or too much detail. Large software projects tend to be over planned and small projects tend to be
underplanned.Thebasicproblemwithplanningtoomuchdetailattheoutsetisthatthedetaildoesnotevolvewiththele
vel of fidelity inthe plan.
Conventionalworkbreakdownstructuresareproject-specific,andcross-projectcomparisonsareusuallydifficult or
impossible. With no standard WBS structure, it is extremely difficult to compare plans,
financialdata,scheduledata,organizationalefficiencies,costtrends,productivitytrends,orqualitytrendsacrossmul
tipleprojects.

Figure10-1 Conventional workbreakdown structure,followingtheproducthierarchy

Management
System requirement and
designSubsystem1
Component
11Requirements
Design
Code
Test
Documentation
…
(similarstructuresforothercomponents)Comp
onent 1N
RequirementsDe
sign
Code
Test
Documentation
…
(similarstructuresforothersubsystems)Subsy
stemM
ComponentM1

Requirements
Design
CodeTes
t
Documentation
…
(similarstructuresforothercomponents)Com
ponent MN
Requirements
Design
CodeTes
t
DocumentationInte
gration and
testTestplanning
Test procedure
preparationTesting
Testreports
Other support
areasConfiguration
controlQuality
assuranceSystemadmini
stration
10.1.2 EVOLUTIONARYWORKBREAKDOWNSTRUCTURES
AnevolutionaryWBSshouldorganizetheplanningelementsaroundtheprocessframeworkratherthantheproductframewor
k. The basicrecommendation for theWBS is to organizethe hierarchy asfollows:

 First-
levelWBSelementsaretheworkflows(management,environment,requirements,design,implementation,a
ssessment, and deployment).
 Second-levelelementsaredefinedforeachphaseofthelifecycle(inception,elaboration,construction,and
transition).
 Third-levelelements aredefined forthe focusofactivitiesthat producethe artifactsofeachphase.
AdefaultWBSconsistentwiththeprocessframework(phases,workflows,andartifacts)isshowninFigure 10-2.
This recommended structure provides one example of howthe elements of the processframework can be
integrated into a plan. It provides a framework for estimating the costs and schedules ofeachelement,
allocatingthemacross a projectorganization, and tracking expenditures.
The structure shown is intended to be merely a starting point. It needs to be tailored to the specifics of
aprojectin many ways.
 Scale.Largerprojectswillhave morelevelsandsubstructures.
 Organizational structure. Projects that include subcontractors or span multiple organizational
entitiesmayintroduce constraints that necessitate different WBSallocations.
 Degree of custom development. Depending on the character of the project, there can be very
differentemphasesin the requirements, design, andimplementation workflows.
 Businesscontext.Projectsdevelopingcommercialproductsfordeliverytoabroadcustomerbasemayrequire
much more elaboratesubstructures for the deploymentelement.
 Precedent experience. Very few projects start with a clean slate. Most of them are developed as
newgenerations of a legacy system (with a mature WBS) or in the context of existing
organizationalstandards(with preordainedWBSexpectations).
TheWBSdecomposesthecharacteroftheprojectandmapsittothelifecycle,thebudget,andthe
personnel. Reviewing a WBS provides insight into the important attributes, priorities, and structure of
theproject plan.
AnotherimportantattributeofagoodWBSisthattheplanningfidelityinherentineachelementiscommensurate with the
current life-cycle phase and project state. Figure 10-3 illustrates this idea. One of theprimary reasons for
organizing the default WBS the way I have is to allow for planning elements that rangefrom planning packages
(rough budgets that are maintained as an estimate for future elaboration rather
thanbeingdecomposedintodetail)throughfullyplannedactivitynetworks(withawell-
definedbudgetandcontinuousassessment of actual versus planned expenditures).

Figure10-2DefaultworkbreakdownstructureA
Management
AA Inception phase managementAAA
Businesscasedevelopment
AAB

ElaborationphasereleasespecificationsAAC
Elaboration phase WBS
specificationsAAD Softwaredevelopmentplan
AAE

InceptionphaseprojectcontrolandstatusassessmentsABElaborationp
hasemanagement
ABA Construction phase release
specificationsABB
ConstructionphaseWBSbaselining
ABC ElaborationphaseprojectcontrolandstatusassessmentsAC
Construction phasemanagement
ACA Deploymentphaseplanning
ACB DeploymentphaseWBSbaselining
ACC ConstructionphaseprojectcontrolandstatusassessmentsAD
Transitionphasemanagement
ADA Nextgenerationplanning
ADB TransitionphaseprojectcontrolandstatusassessmentsB
Environment
BA Inception phase environment
specificationBB
Elaborationphaseenvironmentbaselining
BBA DevelopmentenvironmentinstallationandadministrationBBB

DevelopmentenvironmentintegrationandcustomtoolsmithingBBC
SCOdatabaseformulation
BC Constructionphaseenvironmentmaintenance
 BCA

DevelopmentenvironmentinstallationandadministrationBCB
SCOdatabasemaintenance
BD Transitionphaseenvironment maintenance
BDA

DevelopmentenvironmentmaintenanceandadministrationBDB
SCOdatabasemaintenance
BDC MaintenanceenvironmentpackagingandtransitionC
Requirements
CA Inception phase requirements
developmentCCA Visionspecification
CAB Use casemodeling
 CB

ElaborationphaserequirementsbaseliningCB
A Visionbaselining
CBB Usecasemodelbaselining
CC Construction phase requirements
maintenanceCD
Transitionphaserequirementsmaintenance
DDesign
DA Inception phase architecture prototypingDB

ElaborationphasearchitecturebaseliningDBA
Architecturedesignmodeling
DBB

DesigndemonstrationplanningandconductDBC
Softwarearchitecturedescription
DC Constructionphasedesignmodeling
DCA Architecture design model
maintenanceDCB
Componentdesignmodeling
DD Transition phase design
maintenanceE Implementation
EA Inceptionphasecomponentprototyping
EB Elaborationphasecomponentimplementation
EBA CriticalcomponentcodingdemonstrationintegrationEC
Constructionphasecomponentimplementation
ECA Initial release(s) component coding and stand-alone
testingECB Alpha release component coding and stand-alone
testingECCBeta releasecomponentcodingandstand-alonetesting
ECDComponentmaintenanceF
Assessment
FA Inception phase assessmentFB
Elaborationphaseassessment
FBA Testmodeling
FBB Architecturetestscenarioimplementation
FBC DemonstrationassessmentandreleasedescriptionsFC
Construction phaseassessment
FCAInitial release assessment and release
descriptionFCBAlpha release assessment and release
 descriptionFCCBeta releaseassessment
andreleasedescription
FDTransitionphaseassessment
FDAProductreleaseassessmentandreleasedescriptionGDe
ployment
GAInception phase deployment
planningGBElaborationphasedeploymentplan
ningGCConstructionphasedeployment
GCA User manual
baseliningGDTransitionphasedeploy
ment
GDAProducttransitiontouser
Figure10-3EvolutionofplanningfidelityintheWBSoverthelifecycle

Inception Elaboration

WBS Element Fidelity WBSElement

FidelityManagement High
Management HighEnvironment
Moderate Environment
HighRequirement High
Requirement HighDesign
Moderate Design
HighImplementationLow
Implementation Moderate
Assessment Low Assessment Moderate
Deployment Low Deployment Low

WBS Element Fidelity WBSElement Fidelity

Management High Management High
Environment High Environment High
Requirements Low Requirements Low
Design Low Design Moderate
Implementation Moderate Implementation High
Assessment High Assessment High
Deployment High Deployment Moderate

Transition Construction

10.2PLANNINGGUIDELINES
Software projects span a broad range of application domains. It is valuable but risky to make specific
planningrecommendations independent of project context. Project-independent planning advice is also risky.
There is therisk that the guidelines may pe adopted blindly without being adapted to specific project
circumstances. Twosimple planning guidelines should be considered when a project plan is being initiated or
assessed. The firstguideline, detailed in Table 10-1, prescribes a default allocation of costs among the first-level
WBS elements.The second guideline, detailed in Table 10-2, prescribes the allocation of effort and schedule
across the lifecyclephases.
10-1Webbudgetingdefaults
FirstLevelWBSElement DefaultBudget
Management 10%
Environment 10%
Requirement 10%
Design 15%
Implementation 25%
Assessment 25%
Deployment 5%
Total 100%

Table10-2Defaultdistributionsofeffortandschedulebyphase
Domain Inception Elaboration Construction Transition
Effort 5% 20% 65% 10%
Schedule 10% 30% 50% 10%

10.3 THECOSTANDSCHEDULEESTIMATINGPROCESS
Project plans need to be derived from two perspectives. The first is a forward-looking, top-down approach.
Itstarts with an understanding of the general requirements and constraints, derives a macro-level budget
andschedule, then decomposes these elements into lower level budgets and intermediate milestones. From
thisperspective,the following planning sequence would occur:

1. Thesoftwareprojectmanager(andothers)developsacharacterizationoftheoverallsize,process,environment
,people, andquality required for theproject.
2. A macro-level estimate of the total effort and schedule is developed using a software cost
estimationmodel.
3. Thesoftwareprojectmanagerpartitionstheestimatefortheeffortintoatop-levelWBSusingguidelinessuch as
thosein Table 10-1.
4. At this point, subproject managers are given the responsibility for decomposing each of the
WBSelements into lower levels using their top-level allocation, staffing profile, and major milestone
datesas constraints.

Thesecondperspectiveis abackward-looking,bottom-up approach.We start withtheend inmind,analyzethemicro-

level budgets and schedules, then sum all these elements into the higher level budgets and
intermediatemilestones. This approach tends to define and populate the WBS from the lowest levels upward.
From this per-spective,the following planning sequence wouldoccur:
1. ThelowestlevelWBSelementsareelaboratedintodetailedtasks
2. Estimatesarecombined andintegratedinto higherlevelbudgets andmilestones.
3. Comparisonsaremadewiththetop-downbudgetsandschedulemilestones.
Milestoneschedulingorbudgetallocationthroughtop-downestimatingtendstoexaggeratetheprojectmanagement
biases and usually results in an overly optimistic plan. Bottom-up estimates usually exaggerate
theperformerbiases and result inan overly pessimistic plan.
Thesetwo planning approachesshouldbeused together, inbalance, throughout thelife cycle of theproject.
During the engineering stage, the top-down perspective will dominate because there is usually notenough depth
of understanding nor stability in the detailed task sequences to perform credible bottom-upplanning. During the
production stage, there should be enough precedent experience and planning fidelity thatthebottom-
upplanningperspectivewilldominate.Top-downapproachshouldbewelltunedtotheproject-
 specific parameters, so it should be used more as a global assessment technique. Figure 10-4 illustrates this life-
cycle planningbalance.

Figure10-4Planningbalancethroughoutthelifecycle

Bottom up task level planning based on metrics

frompreviousiterations

Topdownprojectlevelplanningbasedonmicroanalysisfrom
previous projects

EngineeringStage ProductionStage
Inception Elaboration Construction Transition
FeasibilityiterationArchitecture iteration Usable iteration Product
Releases

Engineering stage Production stage

planningemphasis planningemphasis

Macro level task estimation Micro level task estimation

forproductionstage artifacts forproductionstage artifacts
Micro level task estimation Macro level task estimation
forengineeringartifacts formaintenanceofengineeringartifac
ts
Stakeholderconcurrence Stakeholderconcurrence
Coarse grained variance analysis Fine grained variance analysis of
ofactualvs planned expenditures actualvsplanned expenditures
Tuning the top down
projectindependent planning
guidelines
intoprojectspecificplanning
guidelines
WBSdefinition and elaboration

10.4 THEITERATIONPLANNINGPROCESS
Planning is concerned with defining the actual sequence of intermediate results. An evolutionary build plan
isimportant because there are always adjustments in build content and schedule as early conjecture evolves
intowell-understood project circumstances. Iteration is used to mean a complete synchronization across the
project,witha well-orchestrated global assessment of theentire projectbaseline.
 Inceptioniterations.Theearlyprototypingactivitiesintegratethefoundationcomponentsofa
candidatearchitectureandprovideanexecutableframeworkforelaboratingthecriticalusecasesofthesystem.
Thisframeworkincludesexistingcomponents,commercialcomponents,andcustomprototypessufficienttod
emonstrateacandidatearchitectureandsufficientrequirementsunderstandingto establisha credible
 businesscase, vision, andsoftware development plan.
 Elaborationiterations.Theseiterationsresultinarchitecture,includingacompleteframeworkandinfrastructurefor
execution.Uponcompletionofthearchitectureiteration,afewcriticalusecasesshould
 be demonstrable: (1) initializing the architecture, (2) injecting a scenario to drive
the worst-case dataprocessing flow through the system (for example, the peak
transaction throughput or peak load
scenario),and(3)injectingascenariotodrivetheworst-
casecontrolflowthroughthesystem(forexample,orchestratingthe fault-tolerance
use cases).
 Constructioniterations.Mostprojectsrequireatleasttwomajorconstructioniterations
:analphareleaseand a betarelease.
 Transitioniterations.Most projectsusea singleiterationtotransitionabeta releaseintothe
finalproduct.
The general guideline is that most projects will use between four and nine
iterations. The typical project wouldhavethe following six-iteration profile:
 Oneiterationininception:anarchitectureprototype
 Twoiterationsinelaboration:architectureprototypeandarchitecturebaseline
 Twoiterationsinconstruction: alphaandbetareleases
 Oneiterationintransition:productrelease
Averylargeorunprecedentedprojectwithmanystakeholdersmayrequireadditionalincept
ioniterationandtwoadditional iterationsin construction, for a total of nine iterations.

10.5 PRAGMATICPLANNING
Even though good planning is more dynamic in an iterative process, doing it
accurately is far easier. Whileexecuting iteration N of any phase, the software project
manager must be monitoring and controlling against aplan that was initiated in
iteration N - 1 and must be planning iteration N + 1. The art of good
project·management is to make trade-offs in the current iteration plan and the next
iteration plan based on
objectiveresultsinthecurrentiterationandpreviousiterations.Asidefrombadarchitectures
andmisunderstoodrequirements, inadequate planning (and subsequent bad
management) is one of the most common reasons forprojectfailures.
Conversely,thesuccess of everysuccessful projectcan beattributedin partto
goodplanning.
A project's plan is a definition of how the project requirements will be transformed
into' a product within thebusiness constraints. It must be realistic, it must be current,
it must be a team product, it must be understood bythe stakeholders, and it must be
used. Plans are not just for managers. The more open and visible the
planningprocess and results, the more ownership there is among the team members
who need to execute it. Bad, closelyheldplans cause attrition. Good, open plans
canshapecultures and encourage teamwork.