1 software project management session 3: planning

Download 1 Software Project Management Session 3: Planning

Post on 31-Dec-2015




0 download

Embed Size (px)


  • Software Project ManagementSession 3: Planning

  • Today1. Phases in DetailStep-by-step of typical software project2. Lifecycle Planning3. Project plans

    Next Week: Lots of Project-ish Details: WBS, PERT, CPM, Scheduling & Estimation

  • Session 2 ReviewPMI FundamentalsPMI ProcessesProject OrganizationFunctional, Project, Matrix Orgs.Initial documentsStatement of Work (SOW)Project CharterReadings

  • Project Phases

  • Time Allocation by PhaseRemember the 40-20-40 RuleSpecification-Implementation-TestBennatan, E.M, On Time Within Budget

    PlanningCode &Unit TestIntegration & TestCommercial DP25%40%35%Internet Systems55%15%30%Real-time Systems35%25%40%Defense Systems40%20%40%

  • Time Allocation by PhaseMcConnell, Steve, Rapid Development

    ActivitySmall Project (2.5K LOC)Large Project (500K LOC)Analysis10%30%Design20%20%Code25%10%Unit Test20%5%Integration15%20%System test10%15%

  • Activities by % of Total EffortNASAs Managers Handbook for Software Development

  • Potential Deliverables by Phase

  • Concept ExplorationThe Why phaseNot a mandatory formal phaseSometimes called the pre-project phaseCollecting project ideasThen the funneling processProject JustificationROICost-benefit analysisProject Portfolio MatrixInitial planning and estimates

  • Concept ExplorationPossibly includes Procurement Management:RFP ProcessVendor selectionContract managementGathering the initial teamIncluding PM if not already on-boardIdentify the project sponsorPrimary contact for approval and decision makingPotential Phase Outputs: Concept Document, Product Description, Proposal, SOW, Project Charter

  • Concept ExplorationCharacteristics & IssuesLack of full commitment and leadershipSome frustrations:Management only getting rough estimates from developmentDevelopment not getting enough specifics from customerFinding a balanced teamBudget sign-off may be your 1st major taskAchieved via:Good concept document or equivalentDemonstration of clear need (justification)Initial estimates

  • RequirementsThe What phaseInputs: SOW, ProposalOutputs: Requirements Document (RD)a.k.a.Requirements Specification Document (RSD)Software Requirements Specification (SRS)1st Project BaselineSoftware Project Management Plan (SPMP)Requirements Approval & Sign-OffYour most difficult task in this phase

  • RequirementsPerhaps most important & difficult phaseShortchanging it is a classic mistakeCan begin with a Project Kickoff MeetingCan end with a Software Requirements Review (SRR)For Sponsor and/or customer(s) approval

  • Why are Requirements so Important?

  • RequirementsCharacteristics & IssuesConflict of interest: developer vs. customerPotential tug-of-war:Disagreement on Features & EstimatesEspecially in fixed-price contractsFrequent requirements changesAchieving sign-offProject planning occurs in parallel

  • Requirements Requirements are capabilities and condition to which the system more broadly, the project must conform

  • 2 Types of RequirementsFunctional (behavioral)Features and capabilitiesNon-functional (a.k.a. technical) (everything else)UsabilityHuman factors, help, documentationReliabilityFailure rates, recoverability, availabilityPerformanceResponse times, throughput, resource usageSupportabilityMaintainability, internationalizationOperations: systems management, installationInterface: integration with other systemsOther: legal, packaging, hardware

  • RequirementsOther ways of categorizingGo-Ahead vs. Catch-up Relative to competitionBackward-looking vs. Forward-lookingBackward: address issues with previous versionForward: Anticipating future needs of customersMust be prioritizedMust-haveShould-haveCould-have (Nice-to-have: NTH)Must be approved

  • Early Phase MeetingsProject Kickoff MeetingProject Brainstorming MeetingClarify goals, scope, assumptionsRefine estimatesWBS Meeting

  • Analysis & DesignThe How PhasesInputs: Requirements DocumentOutputs: Functional Specification Detailed Design Document User Interface Specification Data ModelPrototype (can also be done with requirements)Updated Plan (improved estimates; new baseline)

  • Analysis & Designa.k.a. Top-level design & detailed designContinues process from RDEnds with Critical Design Review (CDR)Formal sign-offCan also include earlier Preliminary Design Review (PDR) for high level design

  • Analysis & DesignCharacteristics & IssuesEnthusiasm via momentumTeam structure and assignments finalizedDelays due to requirements changes, new information or late ideasIssues around personnel responsibilitiesUnfeasible requirements (technical complexity)Resource Issues Including inter-project contention

  • DevelopmentThe Do It phaseCoding & Unit testingOften overlaps Design & Integration phasesTo shorten the overall schedulePM needs to coordinate this

  • DevelopmentOther concurrent activitiesDesign completionIntegration beginsUnit testing of individual componentsTest bed setup (environment and tools)Project plans updatedScope and Risk Management conducted

  • DevelopmentCharacteristicsPressure increasesStaffing at highest levelsOften a heads-down operationIssuesLast-minute changesTeam coordination (esp. in large projects)Communication overheadManagement of sub-contractors

  • Integration & TestEvolves from Dev. PhaseOften done as 2 parallel phasesPartial integration & initial testStarts with integration of modulesAn initial, incomplete version constructedProgressively add more components

  • Integration & TestIntegration primarily a programmer taskTest primarily a QA team taskIntegration:Top-down: Core functionality first, empty shells for incomplete routines (stubs)Bottom up: gradually bind low-level modulesPrefer top-down generally

  • Integration & TestTestsIntegration testingBlack & White-box testingLoad & Stress testingAlpha & Beta testingAcceptance testingOther activitiesFinal budgeting; risk mgmt.; training; installation preparation; team reduced

  • Integration & TestCharacteristics & IssuesIncreased pressureOvertimeCustomer conflicts over featuresFrustration over last-minute failuresBudget overrunsMotivation problems (such as burnout)Difficulty in customer acceptanceEsp. true for fixed-price contracts

  • Deployment & MaintenanceInstallation depends on system typeWeb-based, CD-ROM, in-house, etc.Migration strategyHow to get customers up on the systemParallel operationDeployment typically in your project plan, maintenance not

  • Deployment & MaintenanceMaintenanceFix defectsAdd new featuresImprove performanceConfiguration control is very important hereDocuments need to be maintained alsoSometimes a single team maintains multiple products

  • Deployment & MaintenanceCharacteristics & IssuesLack of enthusiasm Pressure for quick fixesInsufficient budgetToo many patchesPersonnel turnoverRegression testing is criticalPreferably through automated tools

  • Lifecycle Planninga.k.a. Lifecycle Management or SDLCGreatly influences your chance of successNot choosing a lifecycle is a bad optionThree primary lifecycle model components Phases and their orderIntermediate products of each phaseReviews used in each phase

  • Lifecycle PlanningDifferent projects require different approachesYou do not need to know all models by nameYou should know how that if given a certain scenario what sort of SDLC would be appropriateThere are more than covered hereA lifecycle is not a design, modeling or diagramming technique The same technique (UML, DFD, etc) can be used with multiple lifecycles

  • Pure WaterfallThe granddaddy of modelsLinear sequence of phasesPure model: no phases overlapDocument drivenAll planning done up-front

  • Waterfall RiskWhy does the waterfall model invite risk?Integration and testing occur at the endOften anyones 1st chance to see the program

  • Pure WaterfallWorks well for projects withStable product definitionWell-understood technologiesQuality constraints stronger than cost & scheduleTechnically weak staffProvides structureGood for overseas projects

  • Pure WaterfallDisadvantagesNot flexibleRigid march from start->finishDifficult to fully define requirements up frontCan produce excessive documentationFew visible signs of progress until the end

  • Code-and-FixCode-like-HellSpecification (maybe), Code (yes), Release (maybe)AdvantagesNo overheadRequires little expertiseDisadvantagesNo process, quality control, etc.Highly riskySuitable for prototypes or throwaways

  • Spiral

  • SpiralEmphasizes risk analysis & mgmt. in each phase A Series of Mini-projectsEach addresses a set of risksStart small, explore risks, prototype, plan, repeatEarly iterations are cheapestNumber of spirals is variableLast set of steps are waterfall-like

  • SpiralAdvantagesCan be combined with other modelsAs costs increase, risks decreaseRisk orientation provides early warningDisadvantagesMore complexRequires more management

  • Modified Waterfall SashimiOverlapping phasesAdvantagesReduces overall scheduleReduces documentationWorks well if personnel continuityDisadvantagesMilestones more ambiguousProgress tracking more difficultCommunication can be more difficult

  • Evolutionary PrototypingDesign most prominent parts firstUsually via a visual prototypeGood for situations with:Rapidly changing requirementsNon-committal customerVague problem domainProvides steady, visible progressDisadvantagesTime estimation is difficultProject completion date may be unknownAn excuse to do code-and-fix