Software management disciplines

Iterative Process Planning
Work Breakdown Structures
Planning Guidelines
The Cost and Schedule Estimating Process
The Iteration Planning Process
Pragmatic Planning
Project Organizations and Responsibilities
Line-of-Business organizations
Project Organizations
Evolution Organizations
Process Automation
Tools: Automation Building Blocks
The Project Environment

1. Software Management Disciplines
•Iterative Process Planning
Work Breakdown Structures
Planning Guidelines
The Cost and Schedule Estimating Process
The Iteration Planning Process
Pragmatic Planning
•Project Organizations and Responsibilities
Line-of-Business organizations
Project Organizations
Evolution Organizations
•Process Automation
Tools: Automation Building Blocks
The Project Environment

2. Work Breakdown Structures in Iterative Process Planning
•ThedevelopmentofWBSisdependentontheprojectmanagementstyle,
organizationalculture,customerpreference,financialconstraintsandseveralother
hard-to-defineparameters.
•AWBSissimplyahierarchyofelementsthatdecomposestheprojectplanintothe
discreteworktasks.AWBSprovidesthefollowinginformationstructure:
Adelineationofallsignificantwork
Acleartaskdecompositionforassignmentofresponsibilities
Aframeworkforscheduling,budgeting,andexpendituretracking.
CONVENTIONAL WBSISSUES:
1.Theyareprematurelystructuredaroundtheproductdesign.-Allocatedto
responsiblemanagerswithbudgets,schedules,andexpecteddeliverables,aconcrete
planningfoundation.
2.Theyareprematurelydecomposed,planned,andbudgetedineithertoomuchor
toolittledetail-teamplansouteachelementcompletelyandcreatesabaseline
budgetandscheduleforeverytaskatthesamelevelofdetail.Ontheotherhand,most
small-scaleorin-housedevelopmentselaboratetheirWBSstoasinglelevelonly,
withoutsupportingdetail.
3.Theyareproject-specific,andcross-projectcomparisonsareusuallydifficultor
impossible-WithnostandardWBSstructure,itisextremelydifficulttocompare
plans,financialdata,scheduledata,organizationalefficiencies,costtrends,
productivitytrends,orqualitytrendsacrossmultipleprojects.Eachprojectorganizes
theworkdifferentlyandusesdifferentunitsofmeasure

3. Hierarchy of Conventional WBS

4. Evolutionary of Work Breakdown Structures
AnevolutionaryWBSshouldorganizetheplanningelementsaroundtheprocess
frameworkratherthantheproductframework.
•First-levelWBSelementsaretheworkflows(management,environment,
requirements,design,implementation,assessment,anddeployment).These
elementsareusuallyallocatedtoasingleteamandconstitutetheanatomyofa
projectforthepurposesofplanningandcomparisonwithotherprojects.
•Second-levelelementsaredefinedforeachphaseofthelifecycle(inception,
elaboration,construction,andtransition).Theseelementsallowthefidelityofthe
plantoevolvemorenaturallywiththelevelofunderstandingoftherequirements
andarchitecture,andtheriskstherein.
•Third-levelelementsaredefinedforthefocusofactivitiesthatproducethe
artifactsofeachphase.Theseelementsmaybethelowestlevelinthehierarchy
thatcollectsthecostofadiscreteartifactforagivenphase,ortheymaybe
decomposedfurtherintoseverallowerlevelactivitiesthat,takentogether,
produceasingleartifact.

5. Evolutionary of Work Breakdown Structures
•Scale-Largerprojectswillhavemorelevelsandsubstructures.
•Organizationalstructure-Projectsthatincludesubcontractorsorspanmultiple
organizationalentitiesmayintroduceconstraintsthatnecessitatedifferentWBS
allocations.
•Degreeofcustomdevelopment-Dependingonthecharacteroftheproject,therecanbe
verydifferentemphasesintherequirements,design,andimplementationworkflows.A
businessprocessre-engineeringprojectbasedprimarilyonexistingcomponents.

6. Evolutionary of Work Breakdown Structures
Situation-Complication-Question (SCQ)

7. Evolutionary of Work Breakdown Structures

8. Planning guidelines in iterative process planning
•Itisvaluablebecausemostpeopleinmanagementpositionsarelookingforastarting
point,askeletontheycanfleshoutwithproject-specificdetails.Theyknowthatinitial
planningguidelinescapturetheexpertiseandexperienceofmanyotherpeoplethatinstill
someconfidenceinthestakeholders.
Evolution of planning fidelity in the WBS over the life cycle

9. Planning guidelines in iterative process planning
•Two simple planning guidelines should be considered when a project
plan is being initiated or assessed.
The first guideline prescribes a default
allocation of costs among the first-level
WBS elements
Thesecondguidelineprescribestheallocation
ofeffortandscheduleacrossthelife-cyclephases
FIRST-LEVEL
WBS ELEMENT
DEFAULT
BUDGET
Management 10%
Environment 10%
Requirements 10%
Design 15%
Implementation 25%
Assessment 25%
Deployment 5%
Total 100%
DOMA
IN
INCEPT
ION
ELABORA
TION
CONSTRUC
TION
TRANSI
TION
Effort 5% 20% 65% 10%
Sched
ule
10% 30% 50% 10%

10. Planning guidelines in iterative process planning
1.Thecostofdifferentlaborcategoriesisinherentinthesenumbers.Forexample,
themanagement,requirements,anddesignelementstendtousemorepersonnel
whoareseniorandmorehighlypaidthantheotherelementsuse.
Ifrequirementsanddesigntogetherconsume25%ofthebudget(employingpeople
withanaveragesalaryof$100/hour),thissummayrepresenthalfasmanystaff
hoursastheassessmentelement,whichalsoaccountsfor25%ofthebudgetbut
employspersonnelwithanaveragesalaryof$50/hour.
2.Thecostofhardwareandsoftwareassetsthatsupporttheprocessautomationand
developmentteamsisalsoincludedintheenvironmentelement.

11. The Cost and Schedule Estimating Process in Iterative Process
Planning
•Projectplansneedtobederivedfromtwoperspectives.1.forward-looking,2.top-down
approach.
Forward-looking:
1.Thesoftwareprojectmanagerdevelopsacharacterizationoftheoverallsize,process,
environment,people,andqualityrequiredfortheproject
2.Amacro-levelestimateofthetotaleffortandscheduleisdevelopedusingasoftware
costestimationmodel
3.Thesoftwareprojectmanagerpartitionstheestimatefortheeffortintoatop-level
WBS,alsopartitionsthescheduleintomajormilestonedatesandpartitionstheeffort
intoastaffingprofile
4.Atthispoint,subprojectmanagersaregiventheresponsibilityfordecomposingeach
oftheWBSelementsintolowerlevelsusingtheirtop-levelallocation,staffingprofile,
andmajormilestonedatesasconstraints.

12. The Cost and Schedule Estimating Process in Iterative Process
Planning
Backward-looking:
1.ThelowestlevelWBSelementsareelaboratedintodetailedtasks,forwhichbudgets
andschedulesareestimatedbytheresponsibleWBSelementmanager.
2.Estimatesarecombinedandintegratedintohigherlevelbudgetsandmilestones.
Comparisonsaremadewiththetop-downbudgetsandschedulemilestones.Gross
differencesareassessedandadjustmentsaremadeinordertoconvergeonagreement
betweenthetop-downandthebottom-upestimates.
•Thesetwoplanningapproachesshouldbeusedtogether,inbalance,throughoutthe
lifecycleoftheproject.
•Duringtheengineeringstage,thetop-downperspectivewilldominatebecausethere
isusuallynotenoughdepthofunderstandingnorstabilityinthedetailedtask
sequencestoperformcrediblebottom-upplanning.
•Duringtheproductionstage,thereshouldbeenoughprecedentexperienceand
planningfidelitythatthebottom-upplanningperspectivewilldominate.
•Bythen,thetop-downapproachshouldbewelltunedtotheproject-specific
parameters,soitshouldbeusedmoreasaglobalassessmenttechnique.

13. Iteration Planning Process
Engineering Stage Production Stage
Inception ElaborationConstruction Transition
Feasibility iterationsArchitecture iterations Usable iterations Product releases
Iterationisusedtomeanacompletesynchronizationacrosstheproject,withawell-
orchestratedglobalassessmentoftheentireprojectbaseline.Othermicro-iterations,suchas
monthly,weekly,ordailybuilds,areperformedenroutetotheseproject-levelsynchronization
points.

14. Iteration Planning Process
Engineering stage planning
emphasis:
Macro-level task estimation for
production-stage artifacts
Micro-leveltask estimation for
engineering artifacts
Stakeholder concurrence
Coarse-grainedvariance analysis of
actual vs. planned expenditures
Tuning the top-down project-
independent planning guidelines into
project-specific planning guidelines.
Production stage planning
emphasis:
Micro-level task estimation for
production-stage artifacts
Macro-level task estimation for
engineering artifacts
Stakeholder concurrence
Fine-grained variance analysis
of actual vs. planned
expenditures

15. Iteration Planning Process
Inceptioniterations.Integratethefoundationcomponentsofacandidatearchitectureand
provideanexecutableframeworkforelaboratingphase.Itincludesexistingcomponents,
commercialcomponents,andcustomprototypessufficienttodemonstrateacandidate
architectureandsufficientrequirementsunderstandingtoestablishacrediblebusinesscase,
vision,andsoftwaredevelopmentplan.
Elaborationiterations.Theseiterationsresultinanarchitecture,includingacomplete
frameworkandinfrastructureforexecution.Uponcompletionofthearchitectureiteration,a
fewcriticalusecasesshouldbedemonstrable:
(1)initializingthearchitecture,(2)injectingascenariotodrivetheworst-casedataprocessing
flowthroughthesystem(3)injectingascenariotodrivetheworst-casecontrolflowthrough
thesystem.
Constructioniterations.Requireatleasttwomajorconstructioniterations:analpharelease
andabetarelease.Analphareleasewouldincludeexecutablecapabilityforallthecriticaluse
cases.Itusuallyrepresentsonlyabout70%ofthetotalproductperformanceandreliability.
Betareleaseprovides95%ofthetotalqualityattributes.
Transitioniterations.Singleiterationtotransitionabetareleaseintothefinalproduct.Small-
scaleiterationsmaybenecessarytoresolveallthedefects,incorporatebetafeedback,
incorporateperformanceimprovements.

16. PRAGMATIC PLANNING
•Goodplanningismoredynamic.WhileexecutingiterationNofanyphase,thesoftware
projectmanagermustbemonitoringandcontrollingagainstaplanthatwasinitiatedin
iterationN-1andmustbeplanningiterationN+1.Theartofgoodprojectmanagementis
tomaketrade-offsinthecurrentiterationplanandthenextiterationplanbasedonobjective
resultsinthecurrentiterationandpreviousiterations.Itoverwhelminginearlyphasesorin
projectsthatarepioneeringiterativedevelopment.
•Asidefrombadarchitecturesandmisunderstoodrequirements,inadequateplanningare
mostcommonreasonsforprojectfailures.Conversely,thesuccessofeverysuccessful
projectcanbeattributedinparttogoodplanning.Threeessentialperspectivesare:
planning,requirements,andarchitecture.Theendproductsassociatedwiththese
perspectives(softwaredevelopmentplan,requirementsspecifications,andarchitecture
descriptiondocument)arenotemphasized.Project'splandefineshowtheproject
requirementswillbetransformedintoaproductwithinthebusinessconstraints.Itmustbe
realistic,current,teamproduct,understoodbythestakeholders,andused.
•Plansarenotjustformanagers.Themoreopenandvisibleplanningprocessandresults,
moreownershipamongtheteammemberswhoneedtoexecuteit.Good,openplanscan
shapeculturesandencourageteamwork.

17. Project Organizations and Responsibilities
•Softwarelinesofbusinessaremotivatedbyreturnoninvestment,newbusiness
discriminators,marketdiversification,andprofitability.
•Projectteamsaremotivatedbythecost,schedule,andqualityofspecificdeliverables.
LINE-Of-BUSINESS ORGANIZATIONS
Mainfeaturesofthedefaultorganization:
•Responsibilityforprocessdefinitionandmaintenanceisspecifictoacohesivelineof
business,whereprocesscommonalitymakessense.Forexample,theprocessfor
developingavionicssoftwareisdifferentfromtheprocessusedtodevelopoffice
applications.
•Responsibilityforprocessautomationisanorganizationalroleandisequalinimportance
totheprocessdefinitionrole.Projectsachieveprocesscommonalityprimarilythroughthe
environmentsupportofcommontools.
•Organizationalrolesmaybefulfilledbyasingleindividualorseveraldifferentteams,
dependingonthescaleoftheorganization.A20-personsoftwareproductcompanymay
requireonlyasinglepersontofulfillalltheroles,whilea10,000-person
telecommunicationscompanymayrequire100peopletoachievethework.

18. Line-of-Business Organizations
Default roles in a software line-of-business organizations
Project A
Manager
Project B
Manager
Project N
Manager
Organization
Manager
Software Engineering
Process Authority
Software Engineering
Environment Authority
Project Review
Authority
Infrastructure
•Process definition
•Process improvement
•Process automation
•Project compliance
•Periodic risk assessment
•Project administration
•Engineering skill centers
•Professional development

19. Line-of-Business Organizations Roles
SoftwareEngineeringProcessAuthority
•TheSoftwareEngineeringProcessAuthority(SEPA)facilitatestheexchangeof
informationandprocessguidancebothtoandfromprojectpractitioners.The
organizationgeneralmanagerformaintainingacurrentassessmentoftheorganization's
processmaturityanditsplanforfutureprocessimprovements.
•TheSEPAmusthelpinitiateandperiodicallyassessprojectprocesses.Catalyzingthe
captureanddisseminationofsoftwarebestpracticescanbeaccomplishedonlywhenthe
SEPAunderstandsboththedesiredimprovementandtheprojectcontext.SEPAtakeson
responsibilityandaccountabilityfortheprocessdefinitionanditsmaintenance
(modification,improvement,technologyinsertion).TheSEPAcouldbeasingleindividual,
thegeneralmanager,orevenateamofrepresentatives.TheSEPAmusttrulybean
authority,competentandpowerful.
ProjectReviewAuthority
•TheProjectReviewAuthority(PRA)isthesingleindividualresponsibleforensuringthata
organizationalandbusinessunitsoftwarepolicies,practices,andstandards.
•Asoftwareprojectmanagerisresponsibleformeetingtherequirementsofacontractor
someotherprojectcompliancestandards.ThePRAreviewsboththeproject'sconformance
tocontractualobligationsandtheproject'sorganizationalpolicyobligations.
•Thecustomermonitorscontractrequirements,contractmilestones,contractdeliverables,
monthlymanagementreviews,progress,quality,cost,schedule,andrisk.
•ThePRAreviewscustomercommitmentsaswellasadherencetoorganizationalpolicies,
organizationaldeliverables,financialperformance,andotherrisksandaccomplishments.

20. Line-of-Business Organizations Roles
SoftwareEngineeringEnvironmentAuthority
•TheSoftwareEngineeringEnvironmentAuthority(SEEA)isresponsibleforautomatingthe
organization'sprocess,maintainingtheorganization'sstandardenvironment,training
projectstousetheenvironment,andmaintainingorganization-widereusableassets.
•TheSEEAroleisnecessarytoachieveasignificantreturnoninvestmentforacommon
process.Tools,techniques,andtrainingcanbeamortizedeffectivelyacrossmultiple
projects.Inmanycases,theenvironmentmaybeaugmented,customized,ormodified,but
theexistenceofan80%defaultsolutionforeachprojectiscriticaltoachieving
institutionalizationoftheorganization'sprocessandagoodRoIoncapitaltoolinvestments.
Infrastructure
•Anorganization'sinfrastructureprovideshumanresourcessupport,project-independent
researchanddevelopment,andothercapitalsoftwareengineeringassets.
•Thetypicalcomponentsoftheorganizationalinfrastructureareasfollows:
•Projectadministration:timeaccountingsystem;contracts,pricing,termsand
conditions;corporateinformationsystemsintegration
•Engineeringskillcenters:customtoolsrepositoryandmaintenance,bidandproposal
support,independentresearchanddevelopment
•Professionaldevelopment:internaltrainingbootcamp,personnelrecruiting,
personnelskillsdatabasemaintenance,literatureandassetslibrary,technical
publications

21. Project Organizations
Themainfeaturesofthedefaultorganizationareasfollows:
•Theprojectmanagementteamisanactiveparticipant,responsiblefor
producingaswellasmanaging.Projectmanagementisnotaspectatorsport.
•Thearchitectureteamisresponsibleforrealartifactsandfortheintegrationof
components,notjustforstafffunctions.
•Thedevelopmentteamownsthecomponentconstructionandmaintenance
activities.
•Theassessmentteamisseparatefromdevelopment.Thisstructurefostersan
independentqualityperspectiveandfocusesateamontestingandproduct
evaluationactivitiesconcurrentwithon-goingdevelopment.
•Qualityiseveryone'sjob,integratedintoallactivitiesandcheckpoints.Each
teamtakesresponsibilityforadifferentqualityperspective.

23. Project Organizations
Software Management Team
Inception Elaboration Construction Transition
Elaboration phase planning
Team formulating
Contract baselining
Architecture costs
Construction phase planning
Full staff recruitment
Risk resolution
Product acceptance criteria
Construction costs
Transition phase planning
Construction plan
optimization
Risk management
Customer satisfaction
Contract closure
Sales support
Next-generation planning
Artifacts
Business case
Vision
Software development plan
Work breakdown structure
Status assessments
Requirements set
Systems Engineering
Financial Administration
Quality Assurance
Responsibilities
Resource commitments
Personnel assignments
Plans, priorities,
Stakeholder satisfaction
Scope definition
Risk management
Project control
Life-Cycle Focus

24. Software Management Team
•Mostprojectsareoverconstrained.Schedules,costs,functionality,andquality
expectationsarehighlyinterrelatedandrequirecontinuousnegotiationamongmultiple
stakeholderswhohavedifferinggoals.
•Thesoftwaremanagementteamcarriestheburdenofdeliveringwinconditionstoall
stakeholders.
•Inthisregard,thesoftwareprojectmanagerspendseverydayworryingaboutbalance.
Figureshowsthesoftwaremanagementteamactivitiesovertheprojectlifecycle.
•Thesoftwaremanagementteamisresponsibleforplanningtheeffort,conductingtheplan,
andadaptingtheplantochangesintheunderstandingoftherequirementsorthedesign.
•Towardthisend,theteamtakesownershipofresourcemanagementandprojectscope,and
setsoperationalprioritiesacrosstheprojectlifecycle.
•Atanabstractlevel,theseactivitiescorrespondtomanagingtheexpectationsofall
stakeholdersthroughouttheprojectlifecycle.
•Thesoftwaremanagementteamtakesownershipofallaspectsofquality.Inparticular,it
isresponsibleforattainingandmaintainingabalanceamongtheseaspectssothatthe
overallsolutionisadequateforallstakeholdersandoptimalforasmanyofthemas
possible.

25. Project Organizations Roles
Software Architecture Team
Inception Elaboration Construction Transition
Architecture prototyping
Make/buy trade-offs
Primary scenario definition
Architecture evaluation
criteria definition
Architecture base lining
Primary scenario
demonstration
Make/buy trade-offs base
lining
Architecture maintenance
Multiple-component issue
resolution
Performance tuning
Quality improvements
Architecture maintenance
Multiple-component issue
resolution
Performance tuning
Quality improvements
Artifacts
Architecture description
Requirements set
Design set
Release specifications
Demonstrations
Use-case modelers
Design modelers
Performance analysts
Responsibilities
Requirements trade-offs
Design trade-offs
Component selection
Initial integration
Technical risk solution
Life-Cycle Focus

26. Software Architecture Team
•Thesoftwarearchitectureteamisresponsibleforthearchitecture.Thisresponsibility
encompassestheengineeringnecessarytospecifyacompletebillofmaterialsforthe
softwareandtheengineeringnecessarytomakesignificantmake/buytrade-offs.
•Sothatallcustomcomponentsareelaboratedtotheextentthatconstruction/assembly
costsarehighlypredictable.
•Foranyproject,theskillofthesoftwarearchitectureteamiscrucial.Itprovidesthe
frameworkforfacilitatingteamcommunications,forachievingsystem-widequalities,and
forimplementingtheapplications.
•Withagoodarchitectureteam,anaveragedevelopmentteamcansucceed.Ifthe
architectureisweak,evenanexpertdevelopmentteamofsuperstarprogrammerswill
probablynotsucceed.
Tosucceed,thearchitectureteammustincludes
oDomainexperiencetoproduceanacceptabledesignviewandusecaseview
oSoftwaretechnologyexperiencetoproduceanacceptableprocessview,componentview
anddeploymentview.

27. Project Organizations Roles
Software Development Team
Inception Elaboration Construction Transition
Prototyping support
Make/buy trade-offs
Critical component design
Critical component
implementation and test
Critical component base line
Component design
Component implementation
Component stand-alone test
Component maintenance
Component maintenance
Component documentation
Artifacts
Design set
Implementation set
Deployment set
Component teams
Responsibilities
Component design
Component implementation
Component stand-alone test
Component maintenance
Component documentation
Life-Cycle Focus

28. Software Development Team
Typicalskillsetsincludes:
•Commercialcomponent:specialistswithdetailedknowledgeofcommercial
componentscentraltoasystem'sarchitecture
•Database:specialistswithexperienceintheorganization,storage,andretrieval
ofdata
•Graphicaluserinterfaces:specialistswithexperienceinthedisplay
organization,datapresentation,anduserinteractionnecessarytosupporthuman
input,output,andcontrolneeds
•Operatingsystemsandnetworking:specialistswithexperienceinthe
executionofmultiplesoftwareobjectsonanetworkofhardwareresources,
includingallthetypicalcontrolissuesassociatedwithinitialization,
synchronization,resourcesharing,namespacemanagement,reconfiguration,
termination,andinterobjectcommunications
•Domainapplications:specialistswithexperienceinthealgorithms,application
processing,orbusinessrulesspecifictothesystem

29. Project Organizations Roles
Software Assessment Team
Inception Elaboration Construction Transition
Infrastructure planning
Primary scenario
prototyping
Infrastructure base lining
Architecture release testing
Change management
Initial user manual
Infrastructure upgrades
Release testing
Change management
User manual base line
Requirements verification
Infrastructure maintenance
Release base lining
Change management
Deployment to users
Requirements verification
Artifacts
Deployment set
SCO database
User manual
Environment
Release specifications
Release descriptions
Deployment documents
Release testing
Change management
Deployment
Environment support
Responsibilities
Project infrastructure
Independent testing
Requirements verification
Metrics analysis
Configuration control
Change management
User deployment
Life-Cycle Focus

30. Software Assessment Team
Therearetworeasonsforusinganindependentteamforsoftwareassessment.
•Thefirstisensuringanindependentqualityperspective.
•Ithasprossuchasensuringthattheownershipbiasesofdevelopersdonotpollutethe
assessmentofqualityandconssuchasrelievingthesoftwaredevelopmentteamof
ownershipinquality,tosomeextent.
•Amoreimportantreasonforusinganindependenttestteamistoexploittheconcurrency
ofactivities.
•Schedulescanbeacceleratedbydevelopingthesoftwareandpreparingfortestingin
parallelwithdevelopmentactivities.
•Changemanagement,testplanning,andtestscenariodevelopmentcanbeperformedin
parallelwithdesignanddevelopment.
Amodernprocessshouldemployuse-case-orientedorcapability-basedtestingorganizedasa
sequenceofbuildsandmechanizedviatwoartifacts:
1.Releasespecification(theplanandevaluationcriteriaforarelease)
2.Releasedescription(theresultsofarelease)

31. Evolution of Organizations
Software
management
50%
Software
assessment
10%
Software
development
20%
Software
architecture
20%
Software
management
10%
Software
assessment
20%
Software
development
20%
Software
architecture
50%
Software
management
10%
Software
assessment
50%
Software
development
35%
Software
architecture
5%
Software
management
10%
Software
assessment
30%
Software
development
50%
Software
architecture
10%
InceptionElaboration
TransitionConstruction
Staff Allotment

32. Evolution of Organizations
•Theprojectorganizationrepresentsthearchitectureoftheteamandneedstoevolve
consistentwiththeprojectplancapturedintheworkbreakdownstructure.
•Theteam'scenterofgravityshiftsoverthelifecycle,withabout50%ofthestaffassigned
toonesetofactivitiesineachphase.
Adifferentsetofactivitiesisemphasizedineachphase,asfollows:
•Inceptionteam:anorganizationfocusedonplanning,withenoughsupportfromtheother
teamstoensurethattheplansrepresentaconsensusofallperspectives.
•Elaborationteam:anarchitecture-focusedorganizationinwhichthedrivingforcesofthe
projectresideinthesoftwarearchitectureteamandsupportedbythesoftware
developmentandsoftwareassessmentteamsasnecessarytoachieveastablearchitecture
baseline.
•Constructionteam:afairlybalancedorganizationinwhichmostoftheactivityresidesin
thesoftwaredevelopmentandsoftwareassessmentteamsTransitionteam:acustomer-
focusedorganizationinwhichusagefeedbackdrivesthedeploymentactivities
•Itisequallyimportanttoelaboratethedetailsofsubteams,responsibilities,andwork
packages,butnotuntiltheplanningdetailsintheWBSarestable.Definingallthedetails
oflowerlevelteamstructuresprematurelycanresultinseriousdownstreaminefficiencies.

33. Process Automation
•Automationneedstoimprovethepredictabilityofsoftware
managementandperformanceoftheirsoftwarelinesofbusiness(in
termsofproductquality,timetomarket,returnoninvestment,and
productivity).
•Mostsoftwareorganizationsareconfrontedwiththetaskofintegrating
theirownenvironmentandinfrastructureforsoftwaredevelopment.
•Thisprocesstypicallyresultsintheselectionofmoreorless
incompatibletoolsthathavedifferentinformationrepositories,are
suppliedbydifferentvendors,workondifferentplatforms.
•Integratingsuchaninfrastructurehasproventobemuchmore
problematicthanexpected.
•Toavoidtheissuesautomationisrequiredinsoftwaredevelopment.

34. Three levels of process
Metaprocess,Macroprocess,andMicroprocess
Eachlevelrequiresacertaindegreeofprocessautomationforefficientprocess:
1.Metaprocess:
Anorganization'spolicies,procedures,andpracticesformanagingasoftware-
intensivelineofbusiness.Theautomationsupportforthisleveliscalledan
infrastructurethatincludestools,artifacttemplates,microprocessguidelines,
macroprocessguidelines,projectperformancerepository,databaseof
organizationalskillsets,andlibraryofprecedentexamplesofpastprojectplans
andresults.
2.Macroprocess:
Aproject'spolicies,procedures,andpracticesforproducingacomplete
softwareproductwithincertaincost,schedule,andqualityconstraints.The
automationsupportforaproject'sprocessiscalledanenvironment.
Anenvironmentisaspecificcollectionoftoolstoproduceaspecificsetof
artifactsasgovernedbyaspecificprojectplan.

35. Three levels of process
3.Microprocess:
Aprojectteam'spolicies,procedures,andpracticesforachievinganartifactof
thesoftwareprocess.
Theautomationsupportforgeneratinganartifactisgenerallycalledatool.
Typicaltoolsincluderequirementsmanagement,visualmodeling,compilers,
editors,debuggers,changemanagement,metricsautomation,document
automation,testautomation,costestimation,andworkflowautomation.

36. TOOLS: AUTOMATION BUILDING BLOCKS
Typical automation and tool components that support the process workflows

37. TOOLS: AUTOMATION BUILDING BLOCKS
•Management
•Therearemanyopportunitiesforautomatingtheprojectplanningand
controlactivitiesofthemanagementworkflow.
•SoftwarecostestimationtoolsandWBStoolsareusefulforgenerating
theplanningartifacts.
•Ituseson-lineversionofthestatusassessmentareadvantageous.
•Thisautomationimprovestheinsightofthemetricscollectionand
reporting.
•Environment
•Configurationmanagementandversioncontrolareessentialinamodern
iterativedevelopmentprocess.
•Muchofthemetricsdependentonmeasuringchangesinsoftwareartifact
baselines.

38. TOOLS: AUTOMATION BUILDING BLOCKS
•Requirements
•Conventionalapproachesdecomposedsystemrequirementsintosubsystem
requirements,subsystemrequirementsintocomponentrequirements,and
componentrequirementsintounitrequirements.
•Theequaltreatmentofallrequirementsdrainedawayengineeringhours
fromthedrivingrequirements,thenwastedthattimeonpaperwork
associatedwithdetailedtraceabilitythatwasinevitablydiscardedlateras
thedrivingrequirementsandsubsequentdesignunderstandingevolved.
•Lowerlevelsofrequirementsaredrivenbytheprocess-organizedby
iterationratherthanbylowerlevelcomponent-intheformofevaluation
criteria.
•Evaluationcriteriaarecapturedinthereleasespecificationartifacts,which
aretransientsnapshotsofobjectivesforagiveniteration.
•Evaluationcriteriaarederivedfromthevisionstatementaswellasfrom
manyothersources,suchasmake/buyanalyses,riskmanagement
concerns,architecturalconsiderations,implementationconstraints,quality
thresholds,andevenshotsinthedark.

39. TOOLS: AUTOMATION BUILDING BLOCKS
•Design
•Thetoolsthatsupporttherequirements,design,implementation,andassessment
workflowsareusuallyusedtogether.
•Theprimarysupportrequiredforthedesignworkflowisvisualmodeling,whichis
usedforcapturingdesignmodels,presentingtheminhuman-readableformat,and
translatingthemintosourcecode.
•Anarchitecture-firstanddemonstration-basedprocessisenabledbyexisting
architecturecomponentsandmiddleware.
•Implementation
•Itreliesprimarilyonaprogrammingenvironment(editor,compiler,debugger,linker,
runtime)withthechangemanagementtools,visualmodelingtools,andtest
automationtoolstosupportproductiveiteration.
•AssessmentandDeployment
•Requirestosupporttestautomationandtestmanagement.
•Toincreasechangefreedom,testinganddocumentproductionmustbemostly
automated.
•Defecttrackingisatoolthatsupportsassessment.Itprovidesthechangemanagement
instrumentationnecessarytoautomatemetricsandcontrolreleasebaselines.Itisalso
neededtosupportthedeploymentworkflowthroughoutthelifecycle.

40. PROJECT ENVIRONMENT
Theprojectenvironmentartifactsevolvethroughthreediscretestates:
1.Prototypingenvironment,2.Developmentenvironment,and3.Maintenance
environment.
1.Theprototypingenvironment
•Includesanarchitecturetestbedforprototypingprojectarchitecturesto
evaluatetrade-offsduringtheinceptionandelaborationphases.
•Thisinformalconfigurationoftoolsshouldbecapableofsupportingthe
followingactivities:
•Performancetrade-offsandtechnicalriskanalyses
•Make/buytrade-offsandfeasibilitystudiesforcommercialproducts
•Faulttolerance/dynamicreconfigurationtrade-offs
•Analysisoftherisksassociatedwithtransitioningtofull-scaleimplementation
•Developmentoftestscenarios,tools,andinstrumentationsuitablefor
analyzingtherequirements
2.Thedevelopmentenvironment
•Itshouldincludeafullsuiteofdevelopmenttoolsneededtosupportthevarious
processworkflowsandtosupportround-tripengineeringtothemaximum
extentpossible.

41. PROJECT ENVIRONMENT
•3.Themaintenanceenvironment
•Itshouldtypicallycoincidewithamatureversionofthedevelopment
environment.Insomecases,themaintenanceenvironmentmaybeasubsetof
thedevelopmentenvironmentdeliveredasoneoftheproject'sendproducts.
Fourimportantenvironmentdisciplinestothesuccessofamoderniterative
developmentprocess:
1.Toolsmustbeintegratedtomaintainconsistencyandtraceability.
Roundtripengineeringisthetermusedtodescribethiskeyrequirementfor
environmentsthatsupportiterativedevelopment.
2.Changemanagementmustbeautomatedandenforcedtomanagemultiple
iterationsandtoenablechangefreedom.
3.Organizationalinfrastructuresenableprojectenvironmentstobederivedfroma
commonbaseofprocessesandtools.Acommoninfrastructurepromotesinter-
projectconsistency,reuseoftraining,reuseoflessonslearned,andother
strategicimprovementstotheorganization'smeta-process.
4.Extendingautomationsupportforstakeholderenvironmentsenablesfurther
supportforpaperlessexchangeofinformationandmoreeffectivereviewof
engineeringartifacts.

42. Roundtrip engineering in project environment
Itmaintainsconsistencyamongtheengineeringartifacts.
•Theautomatedtranslationofdesignmodelstosourcecode(bothforwardandreverse
engineering)isfairlywellestablished.
•DistributedActiveXandtheCommonObjectRequestBrokerArchitecture(CORBA)
used.Compilersandlinkershavelongprovidedautomationofsourcecodeinto
executablecode.

43. Change management in project environment
Trackingchangesinthetechnicalartifactstounderstandtechnicalprogressandquality
trendstowarddeliveringanacceptableendproductorinterimrelease.
Inamodernprocess,requirements,design,andimplementationsetartifactsarecaptured
earlyinthelifecycleandevolvedthroughmultiplegenerations.
SoftwareChangeOrders(SCO)
Theatomicunitofsoftwareworktocreate,modify,orobsolescecomponentswithina
configurationbaselineiscalledasoftwarechangeorder(SCO).
SCOisakeymechanismforpartitioning,allocating,andschedulingsoftwareworkagainst
anestablishedsoftwarebaselineandforassessingprogressandquality.
Figureshowsasetofchangeprimitivesandrequiredmetrics.Byautomatingdataentryand
maintainingchangerecordson-line,thechangemanagementbureaucracyassociatedwith
metricsreportingactivitiescanalsobeautomated.
•Title.Thetitleissuggestedbytheoriginatorandisfinalizeduponacceptancebythe
configurationcontrolboard(CCB).Itisreferencetoanexternalsoftwareproblemreport
ifthechangewasinitiatedbyanexternalperson(suchasauser).
•Description.Theproblemdescriptionincludesthenameoftheoriginator,dateof
origination,CCB-assignedSCOidentifier,andrelevantversionidentifiersofrelated
supportsoftware.Itprovidesmuchdetailalongwithcodeexcerpts,displaysnapshots,
errormessages,andanyotherdata.

44. Change management in project environment

45. Change management in project environment
Metrics.Themetricsareimportantforplanning,scheduling,andassessingquality
improvement.
•Changecategoriesaretype0(criticalbug),type1(bug),type2(enhancement),type3
(newfeature),andtype4(other).
•Initialestimatesaremadeoftheamountofbreakageandeffortrequiredtoresolvethe
problem.Thebreakageitemquantifiesthevolumeofchange,andthereworkitem
quantifiesthecomplexityofchange.
•Uponresolution,theactualbreakageisnoted,andtheactualreworkeffortisfurther
elaborated.
•Theanalysisitemidentifiesthenumberofstaffhoursexpendedinunderstandingthe
requiredchange(re-creating,isolating,anddebuggingtheproblemifthechangeis
typeaor1;analysisandprototypingalternativesolutionsifitistype2or3).
•Theimplementitemidentifiesthestaffhoursnecessarytodesignandimplementthe
resolution.
•Thetestitemidentifiesthehoursexpendedintestingtheresolution,andthedocument
itemidentifiesalleffortexpendedinupdatingotherartifactssuchastheusermanual
orreleasedescription.
•BreakagequantifiestheextentofchangeandcanbedefinedinunitsofSLOC,
functionpoints,files,components,orclasses

46. Change management in project environment
Resolution.Thisfieldincludesthenameofthepersonresponsibleforimplementingthe
change,thecomponentschanged,theactualmetrics,andadescriptionofthechange.
Assessment.Thisfielddescribestheassessmenttechniqueaseitherinspection,analysis,
demonstration,ortest.Itshouldidentifyalldifferenttestconfigurations,suchasplatforms,
topologies,andcompilers.
Disposition.TheSCOisassignedoneofthefollowingstatesbytheCCB:
•Proposed:written,pendingCCBreview
•Accepted:CCB-approvedforresolution
•Rejected:closed,withrationale,suchasnotaproblem,duplicate,obsoletechange,
resolvedbyanotherSCO
•Archived:acceptedbutpostponeduntilalaterrelease
•Inprogress:assignedandactivelybeingresolvedbythedevelopmentorganization
• In assessment:resolved by the development organization; being assessed by a test
organization
• Closed: completely resolved, with the concurrence of all CCB members

47. Infrastructures in project environment
Infrastructureprovidestheorganization‘scapitalassets,includingtwokeyartifacts:
1.apolicythatcapturesthestandardsforprojectsoftwaredevelopmentprocesses,and
2.anenvironmentthatcapturesaninventoryoftools.
OrganizationPolicy
Itisusuallypackagedasahandbookthatdefinesthelifecycleandtheprocessprimitives
(majormilestones,intermediateartifacts,engineeringrepositories,metrics,rolesand
responsibilities).
Thehandbookprovidesageneralframeworkforansweringthefollowingquestions:
•Whatgetsdone?(activitiesandartifacts)
•Whendoesitgetdone?(mappingtothelife-cyclephasesandmilestones)
•Whodoesit?(teamrolesandresponsibilities)
•Howdoweknowthatitisadequate?(checkpoints,metrics,andstandardsof
performance)

48. Infrastructures in project environment
OrganizationEnvironment
Theorganizationenvironmentdefineshowthingsgetdoneaswellasthetoolsand
techniquestoautomatetheprocessasmuchaspractical.
Someofthetypicalcomponentsofanorganization'sautomationbuildingblocksareas
follows:
•Standardizedtoolselections(throughinvestmentbytheorganizationinasite
licenseornegotiationofafavorablediscountwithatoolvendorsothatprojectteams
aremotivatedeconomicallytousethattool),whichpromotecommonworkflowsand
ahigherROIontraining
•Standardnotationsforartifacts,suchasUMLforalldesignmodels,orAda95for
allcustom-developed,reliability-criticalimplementationartifacts.
•Tooladjunctssuchasexistingartifacttemplates(architecturedescription,evaluation
criteria,releasedescriptions,statusassessments]orcustomizations
•Activitytemplates(iterationplanning,majormilestoneactivities,configuration
controlboards)

49. Stakeholder environments in project environment
Manylarge-scalecontractualprojectsincludepeopleinexternalorganizationsthat
representotherstakeholderssuchasprocurementagencycontractmonitors,end-user
engineeringsupportpersonnel,third-partymaintenancecontractors,independent
verificationandvalidationcontractors,representativesofregulatoryagencies,andothers.
Thesestakeholderrepresentativesalsoneedaccesstodevelopmentenvironmentresourcesto
contributeoveralleffort.
Anon-lineenvironmentaccessiblebytheexternalstakeholdersallowsthemtoparticipatein
theprocessasfollows:
•Acceptanduseexecutableincrementsforhands-onevaluation
•Usethesameon-linetools,data,andreportsthatthesoftwaredevelopmentorganization
usestomanageandmonitortheproject
•Avoidexcessivetravel,paperinterchangedelays,formattranslations,paperandshipping
costs,andotheroverheadcosts

50. Infrastructures in project environment
Extending environments into stakeholder domains

51. •Technicalartifactsarenotjustpaper.Electronicartifactsinrigorousnotationssuchas
visualmodelsandsourcecodeareviewedfarmoreefficientlybyusingtoolswithsmart
browsers.
•Independentassessmentsoftheevolvingartifactsareencouragedbyelectronicread-
onlyaccesstoon-linedatasuchasconfigurationbaselinelibrariesandthechange
managementdatabase.Reviewsandinspections,breakage/reworkassessments,metrics
analyses,andevenbetatestingcanbeperformedindependentlyofthedevelopment
team.
•Evenpaperdocumentsshouldbedeliveredelectronicallytoreduceproduction
costsandturnaroundtime.
Infrastructures in project environment
Extending environments into stakeholder domains

52. Reference
•Software Project Management, Walker Rayce,
PEA.