还剩77页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
SOFTWAREENGINEERINGLABORATORYSERIESSEL-84-101ManagersHandbookforSoftwareDevelopmentRevision1NOVEMBER1990NationalAeronauticsandSpaceAdministrationGoddardSpaceFlightCenterGreenbeltMaryland20771FOREWORDTheSoftwareEngineeringLaboratorySELisanorganizationsponsoredbytheNationalAeronauticsandSpaceAdministration/GoddardSpaceFlightCenterNASA/GSFCandcreatedforthepurposeofinvestigatingtheeffectivenessofsoftwareengineeringtechnologieswhenappliedtothedevelopmentofapplicationssoftware.TheSELwascreatedin1977andhasthreeprimaryorganizationalmembers:NASA/GSFCSystemsDevelopmentBranch;UniversityofMarylandComputerSciencesDepartment;ComputerSciencesCorporationFlightDynamicsTechnologyGroup.ThegoalsoftheSELare1tounderstandthesoftwaredevelopmentprocessintheGSFCenvironment;2tomeasuretheeffectofvariousmethodologiestoolsandmodelsonthisprocess;and3toidentifyandthentoapplysuccessfuldevelopmentpractices.TheactivitiesfindingsandrecommendationsoftheSELarerecordedintheSoftwareEngineeringLaboratorySeriesacontinuingseriesofreportsthatincludesthisdocument.TheManagersHandbookforSoftwareDevelopmentwasoriginallypublishedinApril
1984.ContributorstotheoriginalversionincludedWilliamAgrestiComputerSciencesCorporationFrankMcGarryGoddardSpaceFlightCenterDavidCardComputerSciencesCorporationJerryPageComputerSciencesCorporationVictorChurchComputerSciencesCorporationRogerWerkingGoddardSpaceFlightCenterTheneweditioncontainsupdatedmaterialandconstitutesamajorrevision.TheprimarycontributorstothecurrenteditionareLindaLandisEditorComputerSciencesCorporationFrankMcGarryGoddardSpaceFlightCenterSharonWaligoraComputerSciencesCorporationRosePajerskiGoddardSpaceFlightCenterMikeStarkGoddardSpaceFlightCenterRushKesterComputerSciencesCorporationTimMcDermottComputerSciencesCorporationJohnMillerComputerSciencesCorporationSinglecopiesofthisdocumentcanbeobtainedbywritingtoSystemsDevelopmentBranchCode552GoddardSpaceFlightCenterGreenbeltMaryland20771iiiABSTRACTMethodsandaidsforthemanagementofsoftwaredevelopmentprojectsarepresented.TherecommendationsarebasedonanalysesandexperiencesoftheSoftwareEngineeringLaboratorySELwithflightdynamicssoftwaredevelopment.Themanagementaspectsofthefollowingsubjectsaredescribed:organizingtheprojectproducingadevelopmentplanestimatingcostsschedulingstaffingpreparingdeliverabledocumentsusingmanagementtoolsmonitoringtheprojectconductingreviewsauditingtestingandcertifying.vTABLEOFCONTENTSSection1—IntroductionHandbookOverviewIntendedAudienceSoftwareLifeCycleActivitiesSpanningPhasesSection2—OrganizingandPlanningOrganizingtheProjectProducingtheSoftwareDevelopment/ManagementPlanExecutingtheSoftwareDevelopment/ManagementPlanSection3—CostEstimatingSchedulingandStaffingEstimatingDevelopmentCostandScheduleProjectStaffingOtherSoftwareDevelopmentCostsCostofComputerUtilizationCostofSystemDocumentationCostofRehostingSoftwareCostofReusingSoftwareCostofSoftwareMaintenanceSection4—KeyDocumentsandDeliverablesSuggestedDocumentContentsGuidelinesforEvaluatingCompletedDocumentsSection5—VerificationTestingandCertificationCodeReadingUnitTestingIntegrationTestingBuild/ReleaseTestingSystemTestingAcceptanceTestingTestManagementGuidelinesCertificationSection6—MetricsandKeyManagementAidsMetricsManagementMetricsandTheirUseSourceCodeGrowthRateEffortDataSystemSizeEstimatesComputerUsagevii1-11-11-21-31-52-12-12-22-53-13-13-43-53-53-73-73-73-84-14-14-115-15-15-15-25-25-35-35-45-56-16-16-26-36-46-66-7TABLEOFCONTENTSContdSection6—MetricsandKeyManagementAidsContdErrorRatesReported/CorrectedSoftwareDiscrepanciesRateofSoftwareChangeDevelopmentActivityStatusAdditionalManagementMetricsDataCollectionAutomatingMetricsAnalysisGeneralIndicatorsofProjectStatusWarningSignalsandCorrectiveActionsBasicSetofCorrectiveActionsSection7—ReviewsandAuditsReviewsSystemRequirementsReviewSoftwareSpecificationsReviewPreliminaryDesignReviewCriticalDesignReviewOperationalReadinessReviewAuditsAppendixA—SELSoftwareDevelopmentEnvironmentGlossaryReferencesStandardBibliographyofSELLiteratureviii6-86-96-106-116-126-136-136-156-166-187-17-17-27-47-67-87-107-13LISTOFILLUSTRATIONSFigurePage1-11-22-13-13-23-34-14-24-34-44-54-64-74-84-94-105-16-16-26-36-46-56-66-76-86-96-106-116-126-136-146-156-166-176-186-196-207-17-27-37-47-57-6ActivitiesbyPercentageofTotalDevelopmentStaffEffortReuseandPrototypingActivitiesWithintheLifeCycleSoftwareDevelopment/ManagementPlanContentsCostEstimationScheduleTypicalComputerUtilizationProfileFORTRANProjectsTypicalComputerUtilizationProfileAdaProjectsKeyDocumentsandDeliverablesbyPhaseRequirementsandFunctionalSpecificationsContentsOperationsConceptDocumentContentsRequirementsAnalysisReportContentsPreliminaryDesignReportContentsDetailedDesignDocumentContentsContentsofTestPlansUsersGuideContentsSystemDescriptionContentsSoftwareDevelopmentHistoryContentsExampleofUnitDesignCertificationManagementThroughMeasurementSELSoftwareGrowthProfileExampleofCodeGrowth—GROAGSSSELStaffingProfileModelSELEffortDistributionModelsEffortDataExample—ERBSAGSSSELSizeEstimatesModelSampleSizeEstimates—UARSAGSSSELComputerUsageModelExampleofComputerUsage—ERBSAGSSSELErrorRateModelSampleErrorRates—COBEAGSSSELSoftwareDiscrepancyStatusModelExampleofDiscrepancyTracking—TCOPSSELChangeRateModelChangeRateExample—GOESAGSSSELDevelopmentStatusModelforaSingleBuildDevelopmentProfileExample—GOADAExampleSMEOutputBuildCorporateMemoryIntoaToolSchedulingofFormalReviewsSRRHardcopyMaterialSSRHardcopyMaterialPDRHardcopyMaterialCDRHardcopyMaterialORRHardcopyMaterialix1-31-52-33-23-63-64-14-24-34-44-54-64-74-84-94-105-66-26-36-36-46-46-56-66-66-76-76-86-86-96-96-106-106-116-116-146-157-17-37-57-77-97-11LISTOFTABLESTablePage3-13-23-33-43-53-63-73-85-16-1DistributionofTimeScheduleandEffortOverPhasesProceduresforReestimatingSizeCostandScheduleDuringDevelopmentComplexityGuidelineDevelopmentTeamExperienceGuidelineTeamSizeGuidelineGuidelineforDevelopmentTeamCompositionCostofRehostingSoftwareCostofReusingSoftwareExpectedPercentageofTestsExecutedThatPassSELRecommendedMetricsx3-13-33-33-43-53-53-73-85-56-12SECTION1—INTRODUCTIONThishandbookisintendedtobeaconvenientreferenceonsoftwaremanagementmethodsandaids.Theapproachistoofferconciseinformationdescribing····WhatthemethodsandaidscanaccomplishWhentheycanbeappliedHowtheyareappliedWherethemanagercanfindmorebackgroundorexplanatorymaterialThemanagementmethodsandaidsincludedherearethosethathaveprovedeffectiveintheexperiencesoftheSoftwareEngineeringLaboratorySELReference
1.ThecharacteristicsofsoftwareprojectsintheflightdynamicsenvironmentmonitoredbytheSELappearintheappendixtothisdocument.Theapplicationsincludeattitudedeterminationandcontrolorbitadjustmentmaneuverplanningandgeneralmissionanalysis.HANDBOOKOVERVIEWThisdocumentconsistsofsevensectionsorganizedbyspecificmanagementtopics:Section1presentsthehandbookspurposeorganizationandintendedaudience.Thesoftwarelifecycleandkeydevelopmentactivitiesaresummarized.Section2discussesthebasicmanagementconcernsoforganizingandplanninginthecontextofsoftwaremanagement.Theproductionofthesoftwaredevelopmentmanagementplaniscoveredindetail.Section3describesresourceestimationandallocation.Techniquesarepresentedforestimatingsizecostsandeffort.Guidelinesaregivenforprojectschedulingandforstaffallocationandcomposition.Section4outlinescontentstimingandevaluationofkeydocumentsanddeliverablesinasoftwareproject.Section5discussesthemanagementaspectsofsoftwareverificationtestingandcertification.Section6summarizesmanagementmeasuresandaidsusedinmonitoringandcontrollingasoftwareproject.Keyindicatorsofprogressarelistedalongwithwarningsignalsandcorrespondingcorrectivemeasures.Section7presentsboththegeneralfunctionofprojectreviewsandthespecificimplementationofthefivemajorreviews.Guidelinesforauditingaprojectarealsointroduced.AnappendixglossaryreferencesandabibliographyofSELliteratureconcludethehandbook.1-1INTENDEDAUDIENCETheintendedaudienceofthisdocumentisthesoftwaremanagerwhoasdefinedinthishandbookservesaseitheranadministrativeortechnicalmanager.Thepositionsoverlapsomewhatintheirinformationneeds.Theadministrativemanagerhasoverallresponsibilityfordevelopingsoftwarethatmeetsrequirementsandisdeliveredontimeandwithinbudget.IntheSELenvironmentaGovernmentTechnicalOfficerorAssistantTechnicalRepresentativeATRgenerallyservesinthiscapacity.Typicallythismanagerisnotinvolvedwiththeday-to-daytechnicalsupervisionoftheprogrammersandanalystswhoaredevelopingthesoftware.Theadministrativemanagerwillbeinvolvedintheactivitieslistedbelow;thecorrespondinghandbooksectionsarelistedalongside.·······OrganizingtheprojectEstimatingresourcesrequiredEstimatingcostsEvaluatingdocumentsanddeliverablesMonitoringprogressEvaluatingresultsofreviewsandauditsCertifyingthefinalproductSectionSectionSectionSectionSectionSectionSection2334675Thetechnicalmanagerisresponsiblefordirectsupervisionofthedevelopers.ThepositionisfrequentlyfilledbyacontractormanagerintheSELenvironment;althoughonsomeprojectsaGovernmentmanagerwillfillthisroleinstead.Thispersonsharessomeoftheactivitieslistedfortheadministrativemanagerespeciallywithregardtomonitoringdevelopmentprogress.Thetechnicalmanagersactivitiesandthecorrespondinghandbookreferencesarepresentedbelow.·Producingandexecutingthesoftwaredevelopment/managementplan·Estimatingcosts·Schedulingtheproject·Staffingtheproject·Directingtheproductionofdocumentsanddeliverables·Usingautomatedmanagementaids·Monitoringdevelopmentprogress·Supervisingtechnicalstaff·Ensuringsoftwarequality·PreparingforreviewsSectionSectionSectionSectionSectionSectionSectionSectionSectionSection2333466657Asecondaryaudienceforthehandbookconsistsofthosewhoserveaparticularperipheralfunctionbutdonotactineitherofthetwomanagerialcapacities.Twoexamplesofsuchspecificfunctionsareparticipatingasanexternalrevieweratascheduledreviewandconductinganauditoftheproject.GovernmentmanagersshouldnotethatthereisnoidentifiableconflictbetweenthematerialpresentedinthishandbookandmajorNASA/GSFCstandards.1-2SOFTWARELIFECYCLETheprocessofsoftwaredevelopmentisoftenmodeledasaseriesofstagesthatdefinethesoftwarelifecycle.Intheflightdynamicsenvironmentthelifecycleisdefinedbythefollowingphases:·Requirementsdefinition·Requirementsanalysis·Preliminarydesign·Detaileddesign·lmplementation·Systemtesting·Acceptancetesting·MaintenanceandoperationAsshowninFigure1-1thephasesdividethesoftwarelifecycleintosequentialtimeperiodsthatdonotoverlap.Howevertheactivitiescharacteristicofonephasemaybeperformedinotherphases.Forexamplealthoughmostofthestaffeffortinanalyzingrequirementsoccursduringtherequirementsanalysisphasesomeofthatactivitycontinuesatlowerlevelsinlaterphases.SRRSSRPDRCDRORRACCEPTANCETESTINGSYSTEMTESTINGIMPLEMENTATIONDESIGNREQUIREMENTSANALYSISREQUIREMENTSDEFINITIONPHASEDETAILEDDESIGNPHASEIMPLEMENTATIONPHASESYSTEMTESTPHASEACCEPTANCETESTPHASEMAINTENANCEANDOPERATIONPRELIMINARYDESIGNPHASEREQUIREMENTSCALENDARTIMEPHASEANALYSISPHASEFigure1-
1.ActivitiesbyPercentageofTotalDevelopmentStaffEffortExample:Attheendoftheimplementationphase4thdashedlineapproximately46%ofthestaffareinvolvedinsystemtesting;approximately15%arepreparingforacceptancetesting;approximately7%areaddressingrequirementschangesorproblems;approximately12%aredesigningmodifications;andapproximately20%arecodingcodereadingunittestingandintegratingchanges.DataareshownonlyforthephasesofthesoftwarelifecycleforwhichtheSELhasarepresentativesample.1-3PERCENTAGEOFTOTALSTAFFEFFORTThelifecyclephasesareimportantreferencepointsforthesoftwaremanager.Forexampleinmonitoringaprojectthemanagermayfindthatthekeyindicatorsofprojectconditionatonephasearenotavailableatotherphases.Milestonesintheprogressofasoftwareprojectarekeyedtothereviewsdocumentsanddeliverablesthatmarkthetransitionsbetweenphases.Managementaidsandresourceestimatescanbeappliedonlyatcertainphasesbecausetheirusedependsontheavailabilityofspecificinformation.Intherequirementsdefinitionphaseaworkinggroupofanalystsanddevelopersidentifiespreviouslydevelopedsubsystemsthatcanbereusedonthecurrentprojectandsubmitsareuseproposal.Guidedbythisproposalarequirementsdefinitionteampreparestherequirementsdocumentandcompletesadraftofthefunctionalspecificationsforthesystem.TheconclusionofthisphaseismarkedbythesystemrequirementsreviewSRRatwhichtherequirementsforthesystemareevaluated.Duringthenextphaserequirementsanalysisthedevelopmentteamclassifieseachspecificationandperformsfunctionalorobject-orientedanalysis.Workingwiththerequirementsdefinitionteamdevelopersresolveambiguitiesdiscrepanciesandto-be-determinedTBDspecificationsproducingafinalversionofthefunctionalspecificationsdocumentandarequirementsanalysisreport.ThisphaseisconcludedwithasoftwarespecificationsreviewSSRatwhichtheresultsoftheanalysisarepresentedforevaluation.Thebaselinedfunctionalspecificationsformacontractbetweentherequirementsdefinitionteamandthesoftwaredevelopmentteamandarethestartingpointforpreliminarydesign.Duringthisthirdphasemembersofthedevelopmentteamproduceapreliminarydesignreportinwhichtheydefinethesoftwaresystemarchitectureandspecifythemajorsubsystemsinput/outputI/Ointerfacesandprocessingmodes.ThepreliminarydesignreviewPDRconductedattheendofthisphaseprovidesanopportunityforevaluatingthedesignpresentedbythedevelopmentteam.Inthefourthphasedetaileddesignthesystemarchitecturedefinedduringthepreviousphaseiselaboratedinsuccessivelygreaterdetailtothelevelofsubroutines.ThedevelopmentteamfullydescribesuserinputsystemoutputI/Ofilesandintermoduleinterfaces.Animplementationplanisproduceddescribingaseriesofbuildsandreleasesthatculminatewiththedeliveredsoftwaresystem.Thecorrespondingdocumentationincludingcompletebaselinediagramsmakesupthedetaileddesigndocument.AtthecriticaldesignreviewCDRthedetaileddesignisevaluatedtodetermineifthelevelsofdetailandcompletenessaresufficientforcodingtobegin.Duringtheimplementationcodeunittestingandintegrationphasethedevelopmentteamcodestherequiredmodulesusingthedetaileddesigndocument.Thesystemgrowsasnewmodulesarecodedtestedandintegrated.Thedevelopersalsoreviseandtestreusedmodulesandintegratethemintotheevolvingsystem.Implementationiscompletewhenallcodeisintegratedandwhensupportingdocumentssystemtestplananddraftusersguidearewritten.Thesixthphasesystemtestinginvolvesthefunctionaltestingoftheend-to-endsystemcapabilitiesaccordingtothesystemtestplan.Thedevelopmentteamvalidatesthecompletelyintegratedsystemandproducesapreliminarysystemdescriptiondocument.Successfulcompletionofthetestsrequiredbythesystemtestplanmarkstheendofthisphase.Duringtheseventhphaseacceptancetestinganacceptancetestteamthatisindependentofthesoftwaredevelopmentteamexaminesthecompletedsystemtodetermineiftheoriginalrequirementshavebeenmet.Acceptancetestingiscompletewhenalltestsspecifiedintheacceptancetestplan1-4havebeenrunsuccessfully.FinalversionsoftheusersguideandsystemdescriptionarepublishedandanoperationalreadinessreviewORRisconductedtoevaluatethesystemsreadinesstobeginoperationalsupport.Theeighthandfinalphasemaintenanceandoperationbeginswhenacceptancetestingends.Thesystembecomestheresponsibilityofthemaintenanceandoperationgroup.Thenatureandextentofactivityduringthisphasedependsonthetypeofsoftwaredeveloped.Forsomesupportsoftwarethemaintenanceandoperationphasemaybeveryactiveduetothechangingneedsoftheusers.ACTIVITIESSPANNINGPHASESIntheflightdynamicsenvironmentreuseandprototypingarekeyactivitiesinseveralphasesofthelifecycle.Intherequirementsdefinitionandrequirementsanalysisphasesreuseanalysisisperformedtodeterminewhichmajorsegmentssubsystemsofexistingsoftwarecanbeutilizedinthesystemtobedeveloped.Inthedesignphasesdevelopersconductaverificationofthisanalysisbyexaminingeachreusableelementindividually.Duringthepreliminarydesignphasedevelopersstudymajorcomponentstodetermineiftheycanbereusedverbatimormodified.ExtractionofindividualunitsfromareusablesoftwarelibraryRSLisconductedduringthedetaileddesignphase.AfinalreuseactivityoccursattheendofthesystemtestphaseatwhichtimedevelopersselectpiecesofthedevelopedsoftwareascandidatesforinclusionintheRSL.Prototypingactivitiesareusuallybegunduringrequirementsanalysisandcompletedbytheendofdetaileddesign.Aprotoypeisanearlyexperimentalmodelofasystemsystemcomponentorsystemfunctionthatcontainsenoughcapabilitiesforittobeusedtoestablishorrefinerequirementsortovalidatecriticaldesignconcepts.Intheflightdynamicsenvironmentprototypesaregenerallyusedtomitigaterisksbyresolvingunknownsrelatedtonewtechnology.Figure1-2showsthespanofthesetwocategoriesofactivityintheSELenvironment.SRRSSRPDRCDRORRREUSEANALYSISsubsystemlevelREUSEVERIFICATIONcomponentunitlevelEXTRACTIONOFRSLCANDIDATESPROTOTYPINGREQUIREMENTSDEFINITIONPHASEDETAILEDDESIGNPHASEPRELIMINARYIMPLEMENTATIONPHASESYSTEMTESTINGPHASEACCEPTANCETESTINGPHASEMAINTENANCEANDOPERATIONPHASEDESIGNPHASEREQUIREMENTSANALYSISPHASECALENDARTIMEFigure1-
2.ReuseandPrototypingActivitiesWithintheLifeCycleThemanagementmethodsandaidsinthishandbookareassociatedwiththephasesfromrequirementsdefinitionthroughacceptancetesting.Reference2containsamoredetailedexplanationoflifecyclephasesandactivities.1-5SECTION2—ORGANIZINGANDPLANNINGThekeytosuccessfulsoftwaremanagementistogeneratearealisticusableplanandthenfollowit.Thecriticalearlystagesoforganizingandplanninglaythefoundationforeffectiveprojectmanagementandcontrol.ORGANIZINGTHEPROJECTTogetstartedthemanagermustgainaclearunderstandingofthescopeoftheprojectandmustestablishthebasisforcontrol.Themajorinitialconcernsrelatetoclarifyingtherequirementsthedeliverablesandtheorganizationalframework.Byaddressingthefoursetsofquestionsbelowthemanagerwillacquireanunderstandingofthekeyelementsthatwillaffectprojectplanning.IdentifyingtheRequirementsWhatfunctionsmustthesystemperformHowwillthesystembeoperatedAretheboundariesofthesystemvisibleInwhatformdoesthejobdefinitionexistIsthecurrentjobdefinitionunderstandableDoestheprojectdependonexternaleventsoractivitiesIdentifyingtheProductsandDeliverablesWhatdocumentsprogramsandfilesarespecifiedasdeliverableproductsWhenmusttheybedeliveredInwhatformarethedeliverablese.g.draftcopiesorontapeWhowillreceivethedeliverablesandacceptthefinalproductWhatcriteriawillbeusedtojudgetheacceptabilityofthefinalproductPreparingforControlIsthereatimetableforperiodicreportingofprojectstatusWhatistheprocedureforincorporatingrequirementschangesthataffectthescopeoftheworkWhatreviewswillbenecessarytomarkthetransitionsbetweenphasesAretheretechnicalormanagerialriskstosuccessfulcompletionoftheprojectWhatmeasureswillbeusedtoassessprojecthealthEstablishinganOrganizationalIdentityWhowillbethekeycontactpeoplefromthecustomerdeveloperandsupportgroupsDothedifferentgroupsunderstandtheirareasofprojectresponsibilityWherewillthedevelopmentworkbedoneWhichdevelopmentcomputerswillbeusedWhatlevelofaccesstothecomputerswillberequired2-1PRODUCINGTHESOFTWAREDEVELOPMENT/MANAGEMENTPLANInmanyenvironmentsthesoftwaremanagementplanandthesoftwaredevelopmentplanareseparatepolicydocumentswithdifferentorientations.Themanagementplanisdirectedtowardthebroaderaspectsofadministrationandcontrole.g.project-levelmonitoringofresourceexpendituresandthefunctioningoftheconfigurationcontrolboardCCB.Thedevelopmentplanfocusesmoreonmethodsandapproachestosoftwareproductione.g.testingstrategiesandprogrammingmethodologies.Althoughthesedifferencesexistbetweenthetwoplansthereisgenerallysomematerialincommon.lntheflightdynamicsenvironmentoftheSELthetwoplansarecombinedintoasingledocumentthesoftwaredevelopment/managementplan.Althoughtheremainderofthissectiondescribesthecontentsofasinglecombinedplanthereaderisencouragedtoseparatethecontentsintotwoplansifthatismoreappropriatetotheneedsofhis/herenvironment.Ineithercasetheitemsinthissectionmustbeformallyaddressedforaprojecttobesuccessful.Thesoftwaredevelopment/managementplanprovidesadisciplinedapproachtoorganizingandmanagingthesoftwareproject.Asuccessfulplanservesas·Astructuredchecklistofimportantquestions·Consistentdocumentationforprojectorganization·Abaselinereferencewithwhichtocompareactualprojectperformanceandexperiences·AdetailedclarificationofthemanagementapproachtobeusedBycompletingtheplanearlyinthelifecyclethemanagerbecomesfamiliarwiththeessentialstepsoforganizingthedevelopmenteffort:·Estimatingresources·Establishingschedules·Assemblingastaff·SettingmilestonesTheplanshouldconcentrateoninformationthatisuniqueortailoredtotheprojectathand.Ifstandardpoliciesguidelinesorprocedureswillbeappliedtoanaspectoftheprojecttheplanshouldreferencethedocumentsinwhichthesearedefinedratherthanrestatingthemindetail.Writingtheplancanbeginassoonasanyinformationabouttheprojectdefinitionandscopebecomesavailable.Theplanshouldbecompletedbytheendoftherequirementsanalysisphaseexceptforinformationavailableonlyatlaterphases.Ifitemsinthesoftwaredevelopment/managementplanaremissingforanyreasonthemanagershouldindicatewhowillsupplytheinformationandwhenitwillbesupplied.Copiesoftheplanshouldbeprovidedtoalllevelsofprojectmanagementandtheprojectstechnicalstaff.Figure2-lpresentsthesuggestedformatandcontentsforthesoftwaredevelopment/managementplanincludingseveralreferencestosectionsofthishandbookfordetaileddescriptions.Theformatisintendedasaguide.Dependingontheapplicationenvironmentadifferentarrangementofitemsortheadditionofnewmaterialmaybeappropriate.2-2SOFTWAREDEVELOPMENT/MANAGEMENTPLANSectionsinitalicsdescribematerialthatistoberegularlyaddedtotheplanduringthelifeoftheproject.Othersectionsshouldberevisedandreissuedifcircumstancesrequiresignificantchangesinapproach.TITLEPAGE—documentnumberprojectandtasknamesreporttitleandreportdate.LEADSHEET—documentidentificationnumbersprojectandtasknamesreporttitlecustomernamepreparerscontractandtaskidentifiersandreportdate.TABLEOFCONTENTS—listofsubsectiontitlesandpagenumbers.
1.INTRODUCTION
1.1Purpose—briefstatementoftheprojectspurpose.
1.2Background—briefdescriptionthatshowswherethesoftwareproductsproducedbytheprojectfitintheoverallsystem.
1.3OrganizationandResponsibilities
1.
3.1ProjectPersonnel—explanationanddiagramofhowthedevelopmentteamwillorganizeactivitiesandpersonneltocarryouttheproject:typesandnumbersofpersonnelassignedreportingrelationshipsandteammembersauthoritiesandresponsibilitiesseeSection3forguidelinesonteamcomposition.
1.
3.2InterfacingGroups—listofinterfacinggroupspointsofcontactandgroupresponsibilities.
2.STATEMENTOFPROBLEM—briefelaborationofthekeyrequirementsthestepstobedonethestepsnumberednecessarytodoitandtherelationifanytootherprojects.
3.TECHNICALAPPROACH
3.1ReuseStrategy—descriptionofthecurrentplanforreusingsoftwarefromexistingsystems.
3.2AssumptionsandConstraints—thatgovernthemannerinwhichtheworkwillbeperformed.
3.3AnticipatedandUnresolvedProblems—thatmayaffecttheworkandtheexpectedeffectoneachphase.
3.4DevelopmentEnvironment—targetdevelopmentmachineandprogramminglanguages.
3.5ActivitiesToolsandProducts—foreachphaseamatrixshowing:athemajoractivitiestobeperformedbthedevelopmentmethodologiesandtoolstobeappliedandctheproductsofthephaseseeSection
4.Includesdiscussionofanyuniqueapproachesoractivities.
3.6BuildStrategy—whatportionsofthesystemwillbeimplementedinwhichbuildsandtherationale.Updatedattheendofdetaileddesignandaftereachbuild.
4.MANAGEMENTAPPROACH
4.1AssumptionsandConstraints—thataffectthemanagementapproachincludingprojectpriorities.
4.2ResourceRequirements—tabularlistsofestimatedlevelsofresourcesrequiredincludingestimatesofsystemsizenewandreusedLOCandmodulesstaffeffortmanagerialprogrammerandsupportbyphasetrainingrequirementsandcomputerresourcesseeSection
3.Includesestimationmethodsorrationaleused.Updatedestimatesareaddedattheendofeachphase.Figure2-
1.SoftwareDevelopment/ManagementPlanContents1of22-
34.
34.
44.5MilestonesandSchedules—listofworktobedonewhowilldoitandwhenitwillbecompleted.Includesdevelopmentlifecyclephasestartandfinishdates;build/releasedates;deliverydatesofrequiredexternalinterfaces;scheduleforintegrationofexternallydevelopedsoftwareandhardware;listofdatainformationdocumentssoftwarehardwareandsupporttobesuppliedbyexternalsourcesanddeliverydates;listofdatainformationdocumentssoftwareandsupporttobedeliveredtothecustomeranddeliverydates;andscheduleforreviewsinternalandexternal.Updatedschedulesareaddedattheendofeachphase.Metrics—atableshowingbyphasewhichmetricswillbecollectedtocaptureprojectdataforhistoricalanalysisandwhichwillbeusedbymanagementtomonitorprogressandproductqualityseeSection6andReference
3.Ifstandardmetricswillbecollectedreferencestotherelevantstandardsandprocedureswillsuffice.Describesanymeasuresordatacollectionmethodsuniquetotheproject.RiskManagement—statementsofeachtechnicalandmanagerialriskorconcernandhowitistobemitigated.Updatedattheendofeachphasetoincorporateanynewconcerns.
5.PRODUCTASSURANCE
5.
15.
25.3AssumptionsandConstraints—thataffectthetypeanddegreeofqualitycontrolandconfigurationmanagementtobeemployed.QualityAssuranceQA—tableofmethodsandstandardsusedtoensurethequalityofthedevelopmentprocessandproductsbyphase.Wherethesedonotdeviatefrompublishedmethodsandstandardsthetablereferencestheappropriatedocumentation.Meansofensuringorpromotingqualitythatareinnovativeoruniquetotheprojectaredescribedexplicitly.IdentifiesthepersonsresponsibleforQAontheprojectanddefineshis/herfunctionsandproductsbyphase.ConfigurationManagementCM—tableshowingproductscontrolledtoolsandproceduresusedtoensuretheintegrityofthesystemconfiguration:whenthesystemisundercontrolhowchangesarerequestedwhomakesthechangesetc.Uniqueproceduresarediscussedindetail.IfstandardCMpracticesaretobeappliedreferencestotheappropriatedocumentsaresufficient.IdentifiesthepersonresponsibleforCManddescribesthisrole.UpdatedbeforethebeginningofeachnewphasewithdetailedCMproceduresforthephaseincludingnamingconventionsCMdirectorydesignationsreuselibrariesetc.
6.
7.REFERENCESPLANUPDATEHISTORY—developmentplanleadsheetsfromeachupdateindicatingwhichsectionswereupdated.Figure2-
1.SoftwareDevelopment/ManagementPlanContents2of22-6EXECUTINGTHESOFTWAREDEVELOPMENT/MANAGEMENTPLANTheplanwillbeaneffectivemanagementaidonlytotheextentthatitisfollowed.Themanagermustdirectandcontroltheexecutionoftheplanby····MaintainingitMeasuringprogressandperformanceRecognizingdangersignals.TakingcorrectiveactiontosolveproblemsAttheendofeachdevelopmentphaseorbuildthemanagershouldreestimateprojectsizeeffortandscheduleforinclusioninthesoftwaredevelopment/managementplan.Earlierestimatesshouldnotberemovedfromtheplan.TheyprovidearecordoftheplanningprocessthatwillbeneededforthesoftwaredevelopmenthistorySection
4.Fromthisinformationtheorganizationcandeterminewhichestimationmethodswereeffectiveandshouldbeusedagain.Whenitiseffectivelymaintainedthedevelopmentplandocumentsthecurrentstrategyforthesoftwaredevelopmenteffort.Byprovidingauniformcharacterizationoftheprojecttheplancanbeinvaluableifchangesoccurinteamleadership.Significantrevisionstotheplanshouldnotbeconsideredroutinemaintenance.Effortshouldbeinvestedwhentheplaniswrittentoensurethatitisrealisticratherthancontinuallymodifyingittoagreewithactualdecisionsorexperiences.Majorshiftsintechnicalapproachoruseofmethodologiesforexampleshouldoccuronlyifnecessary.Bymeasuringprogressthemanagerdiscoverswhetherthedevelopment/managementplaniseffectiveornot.Section6ofthishandbookaddressesthetypesofmetricdatathatshouldbecollectedandmaintainedasarecordofprojectstatus.Metricdataalonearenotsufficientforgaugingtheeffectivenessoftheplanbutbycomparingthesedatatonominalvaluesfromrelatedapplicationssomeassessmentispossible.Section3providesguidelinesonresourcesandstaffingthatenablesomecomparisonwiththeactualprojectdata.TheuseofaprojecthistoriesdatabaseasexplainedinSection6isanothermanagementaidformeasuringprogress.2-5SECTION3—COSTESTIMATINGSCHEDULINGANDSTAFFINGThissectionpresentsmethodsformanagingandestimatingtheresourcesrequiredforthesoftwareproject.Twoofthemostcriticalresourcesaredevelopmentstaffandtime.Thesoftwaremanagerisconcernedwithhowmuchtimewillberequiredtocompletetheprojectandwhatstaffinglevelwillbenecessaryoverthedevelopmentcycle.Bothstaffandtimeareestimatedusingtheproceduresdiscussedinthissection.Issuesofstaffsizeandcompositionoverthelifecycleareconsidered.Guidelinesareprovidedforestimatingsomeadditionalimportantcostelementssuchascomputerutilizationandsystemdocumentation.Reference4providesthebackgroundandrationaleforsoftwarecostestimation.Acautionarynoteappliestothecostfactorsthroughoutthissection.ThevaluessummarizedintheappendixtothisdocumentreflectSELexperiencesindevelopingsoftwarefortheflightdynamicsenvironment.Readersofthishandbookshouldassesshowwellthatsummarymatchestheirownsoftwaredevelopmentenvironmentasanindicationofthedegreeofconfidencetoplaceintheparticularcostvaluespresented.AprudentplanistousethevalueshereasafirstapproximationandbegincollectingdataseeReference3toobtaincostfactorsthatarerepresentativeofthereadersenvironment.ESTIMATINGDEVELOPMENTCOSTANDSCHEDULEAnunderstandingoftheexpectedscheduleconsumptionandeffortexpenditureineachphaseofthelifecycleisessentialtomanagers.Figurel-landTable3-lpresentthesedistributionsastheyreflectprojectsmonitoredbytheSEL.Becausethecostofdevelopingsoftwareisoftenexpressedinunitsofefforte.g.staff-monthstoavoidtheeffectsofinflationandsalaryvariationcostandeffortwillbeusedinterchangeablyinthissectionwhenaccountingfortheexpenditureofstaffresources.Table3-
1.DistributionofTimeScheduleandEffortOverPhasesPHASERequirementsAnalysisPreliminaryDesignDetailedDesignImplementationSystemTestingAcceptanceTestingPERCENTOFTIMESCHEDULE12815302015PERCENTOFEFFORT6816402010Althoughitisthemostuncertaintheinitialestimateisinmanywaysthemostimportant.Itoccursatsuchanearlystageaftertherequirementsdefinitionactivitythatthetemptationisstrongtoignoreit;todosoisamistake.Makingtheinitialestimatehasthewelcomesideeffectofleadingthemanagertoconsiderthevariousfactorsbearingonthesizeandcomplexityofthedevelopmenttask.Theinitialestimateseedstheestimationprocessservingasareferencevaluewithwhichtocomparelaterestimates.Inviewofthissingularrolethefollowingstepsaresuggestedforachievinganinitialestimate3-1·Decomposetherequirementsasfaraspossible.Thedecompositionunitatthispointwillprobablybethesubsystem.·Foreachdecompositionunitidentifysimilaritieswithfunctionalunitsinpreviouslydevelopedsystemsanduseanyhistoricalsizedataavailablefromthesecompletedsystems.·Fordecompositionunitsnotstronglyrelatedtothoseofpreviousprojectsusepersonalexperiencetoestimatethesizeofunits.·Formthesizeestimateinlinesofcodefortheentireprojectbyaddingtheestimatesforallthedecompositionunits.·Fromhistoricaldataandpersonalexperienceestimatetheworkrateinlinesofcodeperstaff-month.·Dividethesizeestimatebytheworkratetoobtainanestimateoftheeffortinstaff-months.·Applytheuncertaintyproportionofl.0tothesizeandeffortestimatestoobtainarangeofpossiblevaluesSeeFigure3-1andTable3-
2.Aftertheinitialestimateismadeaminimumoffivereestimatesnumbered2through6inFigure3-lareprescribed.ThesereestimatesaredetailedinTable3-
2.Theyarebasedontheincreasinggranularityintherepresentationofthesystemduringthelifecycle.TheuncertaintiesfromFigure3-1arerepeatedinTable3-2becauseoftheirimportanceintransformingtheindividualestimatesintorangesofestimatedvalues.TheestimationfactorsinTable3-2representaveragevaluesfortypicaldevelopmentprojectsmonitoredbytheSEL.Theestimatesshouldbeadjustedbeforetheuncertaintyproportionisappliedwhenthemanageridentifiescertainaspectsoftheproblemprocessorenvironmentthatvarysignificantlyfromcustomarydevelopmentconditions.Forexamplewhenmanymoduleswithinthesystemwillbeunusuallylargeorsmallduetotheirspecializedfunctione.g.ingeneratinggraphicstheirestimatedsizeshouldbebasedonpreviouslydevelopedmoduleswithsimilarfunctions.Inadditionanyofthefollowingconditionsmaystronglyaffecttheeffortnecessarytocompletetheproject:useofanewanddissimilarprogramminglanguagedevelopmentbyacompletelyinexperiencedteamortheuseofanewanddissimilarcomputersystem.TheeffectsofsomeoftheseconditionshavebeenestimatedbytheSEL.Table3-3providestherecommendedpercentageadjustmenttotheeffortestimateduetothecomplexityoftheproblem.Table3-4providesanadjustmenttotheeffortestimatefortheeffectofdifferentteamexperiencelevels.LIFECYCLEPHASESREQUIREMENTSDEFINITIONANDSPECIFICATIONREQUIREMENTSANALYSISPRELIMINARYDESIGNDETAILEDDESIGNaIMPLEMENTATIONSYSTEMTESTACCEPT-ANCETESTESTIMATESUNCERTAINTYPROPORTION
11.
0020.
7530.
4040.
2550.
1060.05aReestimatesshouldalsobemadeattheendofeachbuildorreleaseofastagedimplementation.Figure3-
1.CostEstimationSchedule3-2Table3-
2.ProceduresforReestimatingSizeCostandScheduleDuringDevelopmentESTIMATIONPOINTendofRequirementsAnalysisendofPreliminaryDATAREQUIREDNumberofsubsystemsNumberofunitseSIZEESTIMATEUse11000SLOCpersubsystemcUse190SLOCperunitcCOSTEFFORTESTIMATEUse3000hourspersubsystemdUse52hoursperunitdSCHEDULE/STAFFINGESTIMATEaUse83weekspersubsystemperstaffmemberdUse
1.45weeksperunitperstaffUNCERTAINTYPROPORTIONb
0.
750.40DesignmemberdendofDetailedDesignNumberofnewandextensivelyComputenumberofdevelopedunits=Use
0.31hoursperdevelopedSLOCdUse.0087weeksperdeveloped
0.25modifiedunitsNNumberofreusedunitsRslightlymodifiedandverbatimN+
0.2RUsedevelopedSLOC=200xnumberofdevelopedunitsSLOCperstaffmemberdendofImplementationCurrentsizeinSLOCAdd26%tocurrentsizeforgrowthAdd43%toeffortalreadyexpendedAdd54%totimeschedule
0.10EffortexpendedtodateTimescheduleexpendedtodateduringtestingforefforttocompleteexpendedfortimetocompleteendofSystemTestingEffortexpendedtodateFinalproductsizehasbeenreachedAdd11%toeffortalreadyexpendedAdd18%totimeschedule
0.05forefforttocompleteexpendedfortimetocompleteNOTE:ParametervaluesarederivedfromthreeattitudegroundsupportsystemsAGSSs:GOESGROandCOBE.abcdeSchedule/staffingvaluesarebasedonafull-timeemployeesaverageworkweekwithadjustmentsforholidaysleaveetc.1864hoursannually.Thevaluesprovidedcanbeusedtodetermineeitherscheduleorstaffleveldependingonwhichparameterisgiven.Ofsizeandeffortestimates:Upperlimit=sizeoreffortestimatex
1.0+uncertainty.Lowerlimit=sizeoreffortestimate/
1.0+uncertainty.ToallowforTBDrequirementsstaffturnoveretc.conservativemanagementpracticedictatestheuseofestimatesthatliebetweentheestimatedvalueandtheupperbound.SELmanagersforexamplegenerallyplanfora40%increaseinestimatedsystemsizefromPDRtoprojectendduetochangingrequirements.Sourcelineofcode:asinglelineofexecutableornonexecutablesourcecodeincludingcommentsandembeddedblanklines.Estimatesoftotaleffortortime.Subtracteffortortimealreadyexpendedtogeteffortortimetocomplete.Unit:anamedsoftwareelementthatisindependentlycompilablee.g.asubroutinesubprogramorfunction.3-3Table3-
3.ComplexityGuidelinePROJECTTYPEaOldOldNewNewENVIRONMENTTYPEbOldNewOldNewEFFORTMULTIPLIER
1.
01.
41.
42.3aApplicatione.g.orbitdeterminationsimulator.Theprojectorportionoftheprojecttypeisoldwhentheorganizationhasmorethan2yearsexperiencewithit.bComputingenvironmente.g.IBM4341VAX
8810.Theenvironmenttypeisoldwhentheorganizationhasmorethan2yearsofexperiencewithitonaverage.Table3-
4.DevelopmentTeamExperienceGuidelineTEAMYEARSOFAPPLICATIONEXPERIENCEa1086421EFFORTMULTIPLIER
0.
50.
60.
81.
01.
42.6aAverageofteammembersyearsofapplicationexperienceweightedbymembersparticipationontheteam.Applicationexperienceisdefinedaspriorworkonsimilarapplicationse.g.attitudeandorbitdetermination.Membersparticipationisdefinedastimespentworkingontheprojectasaproportionoftotalprojecteffort.PROJECTSTAFFINGAlthoughtheaveragelevelofstaffisprovidedbytheeffortestimatemorespecificguidelinesareavailableforthreeaspectsofstaffing—teamsizestaffingpatternandteamcomposition.TypicalstaffingprofilesareprovidedinSection
6.Table3-5presentsguidelinesforteamsizeintermsoftheteamleadersexperience.Table3-6addressesteamcompositionlistingrecommendedpercentagesofseniorpersonnelandanalysts.3-4Table3-
5.TeamSizeGuidelineTEAMLEADER:MINIMUMYEARSOFEXPERIENCEaMAXIMUMTEAMSIZEEXCLUDINGApplicable654Organization432Leadership310TEAMLEADER724221aApplicable=Applicableexperiencerequirementsdefinitionanalysisdevelopmentmaintenanceandoperation.Organization=Experiencewiththeorganizationanditsdevelopmentmethodology.Leadership=Experienceasateamleaderormanager.Examples:Ateamleaderwithnoleadershipexperienceshouldnotbeaskedtomanageateamwithgreaterthanthreemembers.Ateamofseventoninemembersshouldbeprovidedwithaleaderwhohassixyearsormoreofexperiencewiththeapplicationprimarilywithintheorganization.Table3-
6.GuidelineforDevelopmentTeamCompositionPROJECTTYPEaOldOldNewNewENVIRONMENTTYPEaOldNewOldNewPERCENTAGEOFSENIORPERSONNELb25-3333-5033-5050-67PERCENTAGEOFANALYSTSc25-3325-3333-5033-50aTheprojectandenvironmenttypesareoldwhenthedevelopmentteamhasonaveragemorethan2yearsexperiencewiththem.bSeniorpersonnelarethosewithmorethan5yearsofexperienceindevelopment-relatedactivities.cAnalystsarethosepersonnelwhohavetrainingandaneducationalbackgroundinproblemdefinitionandsolutionwiththeapplicationprojecttype.OTHERSOFTWAREDEVELOPMENTCOSTSEstimatesandguidelinesarepresentedforothersoftwarecostelements:computerutilizationsystemdocumentationsoftwarerehostingsoftwarereuseandsoftwaremaintenance.CostofComputerUtilizationThiscostmaybeexpressedintermsofsystemsize.TheestimateoftotalhoursofCPUtimeHinaNAS8040environmentisH=
0.0008LwhereListhenumberoflinesofsourcecodeinthesystem.TheNAS8040iscomparabletoanIBM
3033.TheestimatednumberofrunsRinthesameSELenvironmentisR=
0.29L.Figures3-2and3-3showcomputerutilizationoverthelifecyclesofrecentprojectsmonitoredbytheSEL.3-5RequirementsPreliminaryAnalysisDesignDetailedDesignImplementationSystemTestAcceptanceTest200%100%AVERAGEWEEKLYCOMPUTERUSE0255075100PERCENTOFDEVELOPMENTSCHEDULEFigure3-
2.TypicalComputerUtilizationProfileFORTRANProjectsRequire-Pre-mentsAnalysisliminaryDesignDetailedDesignImplementationSystemTestAcceptanceTest·IncomparisontoFORTRANAdaprojectsutilizealargerpercentageofCPUearlyinthelifecycle·PDLandprologarecompiledduringthedesignphases200%·Integrationtestingisconductedthroughouttheimplementationphase100%AVERAGEWEEKLYCOMPUTERUSE0255075100PERCENTOFDEVELOPMENTSCHEDULEFigure3-
3.TypicalComputerUtilizationProfileAdaProjects3-7COMPUTERUSEPERCENTOFAVERAGEWEEKLYUSECOMPUTERUSEPERCENTOFAVERAGEWEEKLYUSECostofSystemDocumentationDocumentationcostisincludedinthecostestimatesofTable3-
2.TheaveragequantityofdocumentationforagivensoftwaredevelopmentprojectcanbeestimatedusingtheformulaP=120+
0.026LwherePispagesofdocumentationandLissourcelinesofcode.Thiscostcoversarequirementsanalysisreportdesigndocumentssystemdescriptionandusersguide.Foraseparatedocumentationtask4staff-hoursperpagemaybeusedtoestimatethetotalcostofsystemdocumentation.CostofRehostingSoftwareRehostingmeansmodifyingexistingsoftwaretooperateonanewcomputersystem.Testingwillrequireahighpercentageofthetotaleffortofanyrehostproject.Table3-7providesthecostofrehostinghigh-levellanguagesoftwareasapercentageoftheoriginaldevelopmentcostinstaff-hours.Table3-
7.CostofRehostingSoftwareaPercentoforiginaldevelopmentcost.bPercentoftotalrehostingcost.cPercentofcodethatmustbenewlydevelopedorextensivelymodified.dCompatible:Systemsdesignedtobeplugcompatiblee.g.IBMS/360and
4341.eSimilar:Somekeyarchitecturalcharacteristicse.g.wordsizearesharedandsomearedifferente.g.IBM4341andVAX
8810.fDataextractedfromReference
5.gDissimilar:Differencesinmostcharacteristicsofarchitectureandorganizatione.g.IBMS/360andPDP11/
70.CostofReusingSoftwareReusablemodulesshouldbeidentifiedduringthedesignstage.AsshowninTable3-8theestimatedcosttoreuseamoduledependsontheextentofthechanges.3-7SYSTEMSRELATIONSHIPdCompatibleeSimilargDissimilaraRELATIVECOSTbTESTINGEFFORTSNEWcCODE0-34-1415-32SYSTEMSRELATIONSHIPdCompatibleeSimilargDissimilarFORTRAN10-1615-1820-40ADA5-11f10-1518-30FORTRAN55-70f45-5540-50ADA36-40f30-3525-30NEWcCODE0-34-1415-32Table3-
8.CostofReusingSoftwareMODULECLASSIFICATIONNewExtensivelyModifiedSlightlyModifiedOldPERCENTOFMODULESCODEMODIFIEDORADDED100251-250RELATIVECOSTa1001002020aCostasapercentofthecosttodevelopanewmodule.CostofSoftwareMaintenanceSoftwaremaintenancereferstothreetypesofactivitiesoccurringafterthesoftwareisdelivered—correctingdefectsdetectedduringoperationalusemakingenhancementsthatimproveorincreasefunctionalityandadaptingthesoftwaretochangesintheoperationalenvironmentsuchasanewoperatingsystemorcompiler.Expectedmaintenancecostsvarywidelydependingonthequalityofthedeliveredsoftwareandthestabilityoftheoperationalenvironment.IntheenvironmentmonitoredbytheSELalargepercentageofthemaintenanceeffortofFORTRANsystemsisexpendedinenhancingthesystem.Thisincludesmodifyingexistingcomponentsretestingregeneratingandrecertifyingthesoftware.Fewnewcomponentsareaddedandnewdocumentationisgenerallynotproduced.Averageannualmaintenanceeffortrangesfrom1to23%ofthetotaldevelopmentcostinstaff-hoursoftheoriginalsystem.Totalmaintenanceoverthelifeoftheprojectcostsfrom
1.5to24staff-yearspermillionLOCseeReference
6.BecausemaintenanceeffortvariessowidelytheSELrecommendsthatestimatesoftheannualcostofmaintenancebeadjustedbasedonprojecttype.TheSELuses5%oftotaldevelopmentcostastheestimateofannualmaintenanceofstablesystemswithashortlifeexpectancylessthan4years.Annualmaintenanceoflargerlongerlivedsystemsisestimatedat15%ofdevelopmentcost.3-8SECTION4—KEYDOCUMENTSANDDELIVERABLESDocumentsanddeliverablesprovideanongoingsystemdescriptionandserveaskeyindicatorsofprogress.Theyareacentralconcernofsoftwaremanagersbecausetheymarkthetransitionsbetweenlifecyclephases.Thefollowingdocumentsanddeliverablesareofspecificinteresttothesoftwaremanager:······RequirementsandfunctionalspecificationsOperationsconceptdocumentSoftwaredevelopment/managementplanRequirementsanalysisreportPreliminarydesignreportDetaileddesigndocument·····TestplansUsersguideSystemdescriptionSoftwaredevelopmenthistorySystemdeliverytape—softwareproductandsupportingfilesandtoolsThedocumentsanddeliverablesassociatedwithasoftwaredevelopmentprojectarekeyedtolifecyclephases.Figure4-lshowsthephaseswhentheyshouldbecompleted.Insomeinstancespreliminaryversionsarepreparedfollowedbyupdates.Foranypointinthelifecyclethesoftwaremanagercandeterminewhatdocumentsanddeliverablesshouldbeinpreparation.Thissectionpresentstherecommendeddocumentcontentsaswellasmanagementguidelinesforevaluatingcompleteddocuments.ATENDOFPHASEBELOWDOCUMENTSANDDELIVERABLESREQUIREMENTSDEFINITIONREQUIREMENTSANDFUNCTIONALSPECIFICATIONSOPERATIONSCONCEPTDOCUMENTPRELIMINARYSOFTWAREREQUIREMENTSACCEPTANCESOFTWAREREQUIREMENTSANALYSISPRELIMINARYDESIGNBASELINEDSPECMODSDEVELOPMENT/MANAGEMENTPLANUPDATEANALYSISREPORTPRELIMINARYDESIGNREPORTTESTPLANDRAFTDEVELOPMENTHISTORYDRAFTUPDATEDETAILEDDESIGNSPECMODSUPDATEDETAILEDDESIGNDOCUMENTaBUILDTESTPLANSANALYTICALTESTPLANUPDATEIMPLEMENTATIONFINALUPDATEUSERSGUIDEDRAFTCODEANDSUPPORTINGFILESRESULTSSYSTEMTESTPLANUPDATEUPDATESYSTEMSYSTEMTESTFINALUPDATEDESCRIPTIONDRAFTUPDATERESULTSFINALUPDATEACCEPTANCETESTFINALFINALFINALSYSTEMDELIVERYTAPERESULTSFINALaThepreliminarydesignreportevolvesintothedetaileddesigndocument.Descriptivematerialinthedetaileddesigndocumentprovidesthebasisforthesystemdescription.UpdatedprologsandprogramdesignlanguagePDLfromthedetaileddesignaredeliveredwiththefinalsystemandoperationsscenariosandperformanceinformationareincludedintheusersguide.Figure4-
1.KeyDocumentsandDeliverablesbyPhaseSUGGESTEDDOCUMENTCONTENTSForeachdocumentasuggestedformatandcontentsaregivenseeFigures4-2through4-10withtheexceptionofthesoftwaredevelopment/managementplanwhichwascoveredseparatelyinSection
2.Theactualcontentsofthedocumentsmayvaryfromtheoutlinespresentedhere.Specificfeaturesoftheapplicationenvironmentmayleadthemanagertoexercisejudgmentinselectingthematerialthatismostappropriateandeffective.Thisallowanceforflexibilityshouldbeunderstoodwhenexaminingthefollowingfigures.4-1REQUIREMENTSANDFUNCTIONALSPECIFICATIONSThisdocumentisproducedbytherequirementsdefinitionteamasthekeyproductoftherequirementsdefinitionphase.Itisoftenpublishedinmultiplevolumes:volume1definestherequirementsvolume2containsthefunctionalspecificationsandvolume3providesmathematicalspecifications.ThedocumentisdistributedpriortotheSRR.FunctionalspecificationsareupdatedduringrequirementsanalysisandbaselinedfollowingtheSSR.
1.Introductiona.Purposeandbackgroundoftheprojectb.Documentorganization
2.Systemoverviewa.Overallsystemconceptb.Expectedoperationalenvironmenthardwareperipheralsetc.c.High-leveldiagramsofthesystemshowingtheexternalinterfacesanddataflowsd.Overviewofhigh-levelrequirements
3.Requirements—functionaloperationalinterfaceresourceperformanceetc.anddatarequirementsa.Numberedlistofhigh-levelrequirementswiththeirrespectivederivedrequirementsderivedrequirementsarenotexplicitlycalledoutintherequirementsdocumentbutrepresentconstraintsIimitationsorimplicationsthatmustbesatisfiedtoachievetheexplicitlystatedrequirementsb.Foreachrequirement:1Requirementnumberandname2Descriptionoftherequirement3Referencesourcefortherequirementdistinguishingderivedfromexplicitrequirements4Interfacestoothermajorfunctionsorexternalentities5Performancespecifications—frequencyresponsetimeaccuracyetc.
4.Functionalspecificationsa.Discussionanddiagramsshowingthefunctionalhierarchyofthesystemb.Descriptionanddataflowdiagramsofthebasicfunctionsofeachmajorsubsystemc.Descriptionofgeneralconventionsusedmathematicalsymbolsunitsofmeasureetc.d.Descriptionofeachbasicfunction1Input2Process—detaileddescriptiononhowthisfunctionshouldwork3Output4Identificationofcandidatereusablesoftware5Acceptancecriteriaforverifyingsatisfactionofrelatedrequirements6Datadictionary—indicatingnameofitemdefinitionstructuralcompositionoftheitemitemrangeitemtype
5.Mappingoffunctionalspecificationstorequirements—alsodistinguishesproject-uniquerequirementsfromstandardrequirementsfortheprojecttypeAGSSdynamicssimulatoretc.
6.Mathematicalspecifications—formulaeandalgorithmdescriptionstobeusedinimplementingthecomputationalfunctionsofthesystema.Overviewofeachmajoralgorithmb.DetailedformulaeforeachmajoralgorithmFigure4-
2.RequirementsandFunctionalSpecificationsContents4-2OPERATIONSCONCEPTDOCUMENTThisdocumentprovidesatop-downviewofthesystemfromtheuser’sperspectivebydescribingthebehaviorofthesystemintermsofoperationalmethodsandscenarios.Itshouldbeprovidedbyanalyststothedevelopmentteambytheendoftherequirementsdefinitionphase.Thesuggestedcontentsareasfollows:
1.Introductionincludingpurposeandbackgroundofthesystema.Overallsystemconceptb.Systemoverviewwithhigh-leveldiagramsshowingtheexternalinterfacesanddataflowc.Discussionanddiagramsshowingthefunctionalhierarchyofthesystemd.Documentorganization
2.Operationalenvironmentdescriptionandhigh-leveldiagramsoftheenvironmentinwhichthesystemwillbeoperateda.Overviewofoperatingscenariosb.Descriptionanddiagramsofthesystemconfigurationhardwareandsoftwarec.Descriptionoftheresponsibilitiesoftheoperationspersonnel
3.Operationalmodesa.Discussionofthesystemsmodesofoperatione.g.criticalvs.normallaunchvs.on-orbitoperationsb.Volumeandfrequencyofdatatobeprocessedineachmodec.Orderfrequencyandtypee.g.batchorinteractiveofoperationsineachmode
4.Operationaldescriptionofeachmajorfunctionorobjectinthesystema.Descriptionandhigh-leveldiagramsofeachmajoroperationalscenarioshowingallinputoutputandcriticalcontrolsequencesb.Descriptionoftheinputdataincludingtheformatandlimitationsoftheinput.Samplescreensi.e.displaysmenuspopupwindowsetc.depictingthestateofthefunctionbeforereceivingtheinputdatashouldalsobeincludedc.Process—high-leveldescriptiononhowthisfunctionwillworkd.Descriptionoftheoutputdataincludingtheformatandlimitationsoftheoutput.Samplesi.e.displaysreportsscreensplotsetcshowingtheresultsafterprocessingtheinputshouldalsobeincludede.Descriptionofstatusandpromptmessagesgeneratedduringprocessingincludingguidelinesforuserresponsestoanycriticalmessages
5.RequirementstraceabilitymatrixmappingeachoperationalscenariotorequirementsFigure4-
3.OperationsConceptDocumentContents4-3REQUIREMENTSANALYSISREPORTThisreportispreparedbythedevelopmentteamattheconclusionoftherequirementsanalysisphase.Itsummarizestheresultsofrequirementsanalysisandestablishesabasisforbeginningpreliminarydesign.Thesuggestedcontentsareasfollows:
1.
2.
3.
4.
5.
6.
7.
8.
9.Introduction—purposeandbackgroundoftheprojectoverallsystemconceptsanddocumentoverviewReuseproposal—keyreusecandidatesandoverallarchitecturalconceptforthesystemOperationsoverview—updatestooperationsconceptsresultingfromworkperformedduringtherequirementsanalysisphasea.Updatedoperationsscenariosb.Operationalmodes—includingvolumeandfrequencyofdatatobeprocessedineachmodeorderandtypeofoperationsetc.c.UpdateddescriptionsofinputoutputandmessagesSpecificationanalysisa.SummaryofclassificationsmandatoryderivedwishlistinformationonlyorTBDassignedtorequirementsandfunctionalspecificationsb.Problematicspecifications—identificationanddiscussionofconflictingambiguousinfeasibleuntestableandTBDrequirementsandspecificationsc.Unresolvedrequirements/operationsissuesincludingthedatesbywhichresolutionsareneededd.AnalysisofmathematicalalgorithmsSystemconstraintsa.Hardwareavailability—executionstorageperipheralsb.Operatingsystemlimitationsc.SupportsoftwarelimitationsDevelopmentassumptionsRisksbothtocostsandschedules.TheseshouldincluderisksrelatedtoTBDorchangingrequirementsaswellastechnicalrisksPrototypingeffortsneededtoresolvetechnicalrisksincludingthegoalsandscheduleforeachprototypingeffortDatafloworobject-orienteddiagrams—resultsofallfunctionaldecompositionorobject-orientedanalysisoftherequirementsperformedduringtherequirementsanalysisphase
10.Datadictionary—fortheupdatedprocessesdataflowsandobjectsshowninthediagramsFigure4-
4.RequirementsAnalysisReportContents4-4PRELIMINARYDESIGNREPORTThisreportispreparedbythedevelopmentteamastheprimaryproductofthepreliminarydesignphase.Itpresentsthefunctionaldescriptionofthesystemandformsthebasisforthedetaileddesigndocument.Thesuggestedcontentsareasfollows:
1.Introduction—purposeandbackgroundoftheprojectoverallsystemconceptsanddocumentoverview
2.Designoverviewa.Designdriversandtheirorderofimportancee.g.performancereliabilityhardwarememoryconsiderationsoperatingsystemlimitationslanguageconsiderationsetc.b.Resultsofreusetradeoffanalyses;thereusestrategyc.Critiqueofalternativedesignsd.Discussionandhigh-Ieveldiagramsoftheselectedsystemdesignshowinghardwareinterfacesexternaldatainterfacesinterconnectionsamongsubsystemsanddataflowe.Atraceabilitymatrixofthesubsystemsagainsttherequirementsf.Designstatus1Listofconstraintsconcernsandproblemareasandtheireffectsonthedesign2Listofassumptionsandpossibleeffectsondesigniftheyarewrong3ListofTBDrequirementsandanassessmentoftheireffectonsystemsizerequiredeffortcostandschedule4ICDstatus5Statusofprototypingeffortsg.Developmentenvironmenti.e.hardwareperipheraldevicesetc.
3.Operationsoverviewa.Operationsscenarios/scriptsoneforeachmajorproductthatisgenerated.Includestheformandvolumeoftheproductandthefrequencyofgeneration.Panelsanddisplaysshouldbeannotatedtoshowwhatvariousselectionswilldoandshouldbetracedtoasubsystemb.Systemperformanceconsiderations
4.Designdescriptionforeachsubsystemormajorfunctionalbreakdown:a.Discussionandhigh-leveldiagramsofsubsystemincludinginterfacesdataflowandcommunicationsforeachprocessingmodeb.High-Ieveldescriptionofinputandoutputc.High-leveldescriptionofprocessingkeyedtooperator-specifiedinputandactionsintermsofpointsofcontrolfunctionsperformedandresultsobtainedbothnormalandabnormali.e.errorprocessingandrecoveryd.Structurechartsorobject-orienteddiagramsexpandedtotwolevelsbelowthesubsystemdrivere.Prologsspecifyingthemodulespurposeoperationcallingsequenceargumentsexternalreferencesetc;AdaprojectsshouldprovidepackagespecificationsfortheprincipleobjectsinthesystemandprogramdesignlanguagePDLforeachmodulethroughthefirstIevelbelowsubsystemdriver.PrologsandPDLarenormallypublishedinaseparatevolumebecauseofsize.
5.Datainterfacesforeachinternalandexternalinterface:a.Descriptionincludingnamefunctionfrequencycoordinatesunitsandcomputertypelengthandrepresentationb.Format1Organizationanddescriptionoffilesi.e.datafilestapeetc.2Layoutofframessamplesrecordsblocksand/ortransmissions3StoragerequirementsFigure4-
5.PreliminaryDesignReportContents4-5DETAILEDDESIGNDOCUMENTThisdocumentistheprimaryproductofthedetaileddesignphase.Tocompletethedocumentthedevelopmentteamupdatessimilarmaterialfromthepreliminarydesignreportandaddsgreaterdetail.Thesuggestedcontentsareasfollows:
1.Introduction—purposeandbackgroundoftheprojectoverallsystemconceptsanddocumentoverview
2.Designoverviewa.Designdriversandtheirorderofimportanceb.Reusestrategyc.Discussionandhigh-Ieveldiagramsoftheselectedsystemdesignshowinghardwareinterfacesexternaldatainterfacesinterconnectionsamongsubsystemsanddataflowd.Traceabilitymatrixofmajorcomponentsagainstrequirementsandfunctionalspecificationse.Designstatus1Listofconstraintsconcernsandproblemareasandtheireffectsonthedesign2Listofassumptionsandpossibleeffectsondesigniftheyarewrong3ListofTBDrequirementsandanassessmentoftheireffectonsystemsizerequiredeffortcostandschedule4ICDstatus5Statusofprototypingeffortsf.Developmentenvironment
3.Operationsoverviewa.Operationsscenarios/scriptsb.Systemperformanceconsiderations
4.Designdescriptionforeachsubsystemormajorfunctionalbreakdown:a.Overallsubsystemcapabilityb.Assumptionsaboutandrestrictionstoprocessingineachmodec.Discussionandhigh-Ieveldiagramsofsubsystemincludinginterfacesdataflowandcommunicationsforeachprocessingmoded.High-Ieveldescriptionofinputandoutpute.Detaileddescriptionofprocessingkeyedtooperator-specifiedinputandactionsintermsofpointsofcontrolfunctionsperformedandresultsobtainedbothnormalandabnormali.e.errorprocessingandrecoveryf.Structurechartsorobject-orienteddiagramsexpandedtothesubprogramIevelshowinginterfacesdataflowinteractivecontrolinteractiveinputandoutputandhardcopyoutputg.Internalstoragerequirementsi.e.descriptionofarraystheirsizetheirdatacapacityinallprocessingmodesandimpliedIimitationsofprocessingh.Detailedinputandoutputspecifications1Processingcontrolparameterse.g.NAMELISTS2Facsimilesofgraphicdisplaysforinteractivegraphicsystems3Facsimilesofhardcopyoutputi.Listofnumberederrormessageswithdescriptionofsystemsandusersactionsj.DescriptionofCOMMONareasorotherglobaldatastructuresk.PrologsorAdapackagespecificationsandPDLforeachunitnormallykeptinaseparatedocumentbecauseofsize
5.Datainterfaces—updatedfromdescriptioninpreliminarydesignreportFigure4-
6.DetailedDesignDocumentContents4-6TESTPLANSBUILD/RELEASETESTPLAN·Preparedbythesystemtestteamduringthedetaileddesignphase·Designedtotestthefunctionalcapabilityofeachbuildorreleasefunctionalsubsetsofthecompletesoftwaresystemasdefinedinthesoftwaredevelopment/managementplanandtoidentifylimitations·Executedduringtheimplementationphasebythesystemtestteamassoonasunittestingandintegrationofeachbuild/releaseiscompleteANALYTICALTESTPLAN·Preparedpriortotheimplementationphasebytheanalystswhowillusethesystem·Designedtoassistdevelopersinverifyingtheresultsofcomplexmathematicalandastronomicalcalculationsperformedbythesystem·Unitleveltestsareexecutedduringtheimplementationphasebydevelopers;end-to-endtestsareexecutedasapartofsystemtestingSYSTEMTESTPLAN·Preparedbythesystemtestteamduringtheimplementationphase·Designedtoverifythesystemsend-to-endprocessingcapabilityasspecifiedintherequirementsdocumentandtoidentifylimitations·ExecutedduringthesystemtestingphasebythesystemtestteamACCEPTANCETESTPLAN·Draftedbytheacceptancetestteamfollowingtherequirementsdefinitionphasebasedontherequirementsandfunctionalspecificationsdocument·Designedtodemonstratethesystemscompliancewiththerequirementsandfunctionalspecifications·ExecutedduringtheacceptancetestingphasebytheacceptancetestteamTESTPLANOUTLINE
1.IntroductionincludingpurposetypeandIeveloftestingandschedule
2.Traceabilitymatrixmappingeachrequirementandfunctionalspecificationtooneormoretestcases
3.TestdescriptionnormallytheIengthneednotexceed1to2pagesforeachtesta.Purposeoftesti.e.specificcapabilitiesorrequirementstestedb.Detailedspecificationofinputc.Requiredenvironmente.g.datasetsrequiredcomputerhardwarenecessaryd.Operationalprocedurei.e.howtodotheteste.Detailedspecificationofoutputi.e.theexpectedresultsf.Criteriafordeterminingwhetherornotthetestresultsareacceptableg.Sectionfordiscussionofresultsi.e.forexplainingdeviationsfromexpectedresultsandidentifyingthecauseofthedeviationorforjustifyingthedeviationFigure4-
7.ContentsofTestPlans4-7USERSGUIDEThedevelopmentteambeginspreparationoftheusersguideduringtheimplementationphase.Items1and2andportionsofitem3representupdatedmaterialfromthedetaileddesigndocumentalthoughsomerewritingisexpectedtomakeitmoreaccessibletotheuser.Adraftiscompletedbytheendoftheimplementationphaseandisevaluatedduringsystemtesting.Atthebeginningoftheacceptancetestphaseanupdatedversionissuppliedtotheacceptancetestteamforevaluation.Correctionsareincorporatedandafinalrevisionisproducedattheendofthephase.Thesuggestedcontentsareasfollows:
1.lntroductiona.Overviewofthesystemincludingpurposeandbackgroundb.Documentorganizationc.Discussionandhigh-leveldiagramsofsystemshowinghardwareinterfacesexternaldatainterfacessoftwarearchitectureanddataflow
2.Operationsoverviewa.Operationsscenarios/scriptsb.Overviewandhierarchyofdisplayswindowsmenusreportsetc.c.Systemperformanceconsiderations
3.Descriptionforeachsubsystemormajorfunctionalcapability:a.Overallsubsystemcapabilityb.Assumptionsaboutandrestrictionstoprocessingineachmodec.Discussionandhigh-Ieveldiagramsofsubsystemsincludinginterfacesdataflowandcommunicationsforeachprocessingmoded.High-leveldescriptionofinputandoutpute.Detaileddescriptionofprocessingkeyedtooperator-specifiedinputandactionsintermsofpointsofcontrolfunctionsperformedandresultsobtainedbothnormalandabnormali.e.errorprocessingandrecoveryf.Forinteractivesubsystemsfacsimilesofdisplaysintheorderinwhichtheyaregeneratedg.Facsimilesofhardcopyoutputintheorderinwhichitisproducedannotatedtoshowwhatparameterscontrolith.Listofnumberedmessageswithexplanationofsystemsandusersactionsannotatedtoshowthesubroutinesthatissuethemessage
4.Requirementsforexecutiona.Resources—discussionhigh-leveldiagramsandtablesforsystemandsubsystems1Hardware2Datadefinitionsi.e.datagroupingsandnames3Peripheralspaceconsiderations—datastorageandprintout4Memoryconsiderations—programstoragearraystorageanddatasetbuffers5TimingconsiderationsaCentralprocessingunitCPUtimeintermsofsamplesandcyclesprocessedbI/OtimeintermsofdatasetsusedandtypeofprocessingcWall-clocktimeintermsofsamplesandcyclesprocessedb.Runinformation—controlstatementsforvariousprocessingmodesc.Controlparameterinformation—bysubsystemdetaileddescriptionofallcontrolparameterse.g.NAMELISTSincludingnamecomputertypelengthandrepresentationanddescriptionofparameterwithvalidvaluesdefaultvalueunitsandrelationshiptootherparametersFigure4-
8.UsersGuideContents4-8SYSTEMDESCRIPTIONDuringtheimplementationphasethedevelopmentteambeginsworkonthesystemdescriptionbyupdatingdataflow/objectdiagramsandstructurechartsfromthedetaileddesign.Adraftofthedocumentiscompletedduringthesystemtestingphaseandafinalversionisproducedbytheendofacceptancetesting.Thesuggestedcontentsareasfollows:
1.Introduction—purposeandbackgroundoftheprojectoverallsystemconceptsanddocumentoverview
2.Systemoverviewa.Overviewofoperationsscenariosb.Designdriverse.g.performanceconsiderationsandtheirorderofimportancec.Reusestrategyd.Resultsofprototypingeffortse.Discussionandhigh-Ieveldiagramsoftheselectedsystemdesignshowinghardwareinterfacesexternaldatainterfacesinterconnectionsamongsubsystemsanddataflowf.Traceabilitymatrixofmajorcomponentsagainstrequirementsandfunctionalspecifications
3.Descriptionofeachsubsystemormajorfunctionalbreakdown:a.Overallsubsystemcapabilityb.Assumptionsaboutandrestrictionstoprocessingineachmodec.Discussionandhigh-Ieveldiagramsofsubsystemincludinginterfacesdataflowandcommunicationsforeachprocessingmoded.High-Ieveldescriptionofinputandoutpute.Structurechartsorobject-orienteddiagramsexpandedtothesubprogramIevelshowinginterfacesdataflowinteractivecontrolinteractiveinputandoutputandhardcopyoutput
4.Requirementsforcreationa.Resources—discussionhigh-Ieveldiagramsandtablesforsystemandsubsystems1Hardware2Supportdatasets3Peripheralspaceconsiderations—sourcecodestoragescratchspaceandprintout4Memoryconsiderations—programgenerationstorageanddatasetbuffers5TimingconsiderationsaCPUtimeintermsofcompilebuildandexecutebenchmarktestbI/Otimeintermsofthestepstocreatethesystemb.Creationinformation—controlstatementsforvariousstepsc.Programstructureinformation—controlstatementsforoverlayingorloading
5.Detaileddescriptionofinputandoutputbystep—sourcecodelibrariesforsystemandsubsystemsobjectcodelibrariesexecutioncodeIibrariesandsupportIibraries
6.lnternalstoragerequirements—descriptionofarraystheirsizetheirdatacapacityinallprocessingmodesandimpliedIimitationsofprocessing
7.Datainterfacesforeachinternalandexternalinterface:a.DescriptionincludingnamefunctionfrequencycoordinatesunitscomputertypeIengthandrepresentationb.Format—organizatione.g.indexedtransfermediume.g.diskIayoutofframessamplesrecordsblocksand/ortransmissionsandstoragerequirements
8.DescriptionofCOMMONblocksincludinglocationsofanyhard-codedphysicalconstants
9.Prologs/packagespecificationsandPDLforeachsubroutineseparatevolume
10.AlphabeticalIistofsubroutinesfromsupportdatasetsincludingadescriptionofeachsubroutinesfunctionandareferencetothesupportdatasetfromwhichitcomesFigure4-
9.SystemDescriptionContents4-9SOFTWAREDEVELOPMENTHISTORYMaterialforthedevelopmenthistoryiscollectedbytheprojectleaderthroughoutthelifeoftheproject.Attheendoftherequirementsanalysisphaseprojectdataandearlylessonslearnedarecompiledintoaninitialdraft.Thedraftisexpandedandrefinedattheendofeachsubsequentphasesothatbytheendoftheprojectallrelevantmaterialhasbeencollectedandrecorded.Thefinalversionofthesoftwaredevelopmenthistoryisproducedwithin1monthofsoftwareacceptance.Thesuggestedcontentsareasfollows:
1.Introduction—purposeofsystemcustomerofsystemkeyrequirementsdevelopmentmachinesandlanguage
2.Historicaloverviewbyphase—includesproductsproducedmilestonesandotherkeyeventsphasedurationimportantapproachesanddecisionsstaffinginformationandspecialproblemsa.Requirementsdefinition—ifrequirementswereproducedbythesoftwaredevelopmentteamthissectionprovidesanhistoricaloverviewoftherequirementsdefinitionphase.Otherwiseitsuppliesinformationabouttheoriginanddocumentationofthesystemsrequirementsandfunctionalspecificationsb.Requirementsanalysisc.Detaileddesignd.Implementation—codingthroughintegrationforeachbuild/releasee.Systemtestingf.Acceptancetesting
3.Projectdataa.Personnelandorganizationalstructure—listofprojectparticipantstheirrolesandorganizationalaffiliation.Includesadescriptionofthedutiesofeachrolee.g.analystdevelopersectionmanagerandastaffingprofileoverthelifeoftheprojectb.Schedule—tableofkeydatesinthedevelopmentoftheprojectandachartshowingeachestimateoriginalplusreestimatesateachphaseendvs.actualschedulec.Projectcharacteristics1Standardtablesofthefollowingnumbers:subsystems;totalnewandreusedcomponents;totalnewadaptedandreusedverbatimSLOCstatementsandexecutables;totalmanagerialprogrammerandsupporteffort;totalproductivity2Standardgraphsorchartsofthefollowingnumbers:projectgrowthandchangehistories;developmenteffortbyphase;developmenteffortbyactivity;CPUusage;systemtestprofile;errorrates;originalsizeestimatepluseachreestimatevs.finalsystemsize;originaleffortestimatepluseachreestimatevs.actualeffortrequired3Subjectiveevaluationdatafortheproject—copyoftheSELsubjectiveevaluationformSEForreportofSEFdatafromtheprojectdatabaseseeReference
74.Lessonslearned—descriptionsofthemajorstrengthsandweaknessesofthedevelopmentprocessandproductwhatwaslearnedfromthemandwhatspecificrecommendationscanbemadetoimprovefutureprojectsa.Planning—developmentplantimelinessandusefulnessadherencetodevelopmentplanpersonneladequacynumberandqualityetc.b.Requirements—completenessandadequacyfordesignchangehistoryandstabilityandclarityi.e.weretheremisinterpretationsetc.c.Development—lessonslearnedindesigncodeandunittestingd.Testing—lessonslearnedinsystemandacceptancetestinge.Productassurance—adherencetostandardsandpractices;QAandCMlessonslearnedf.Newtechnology—impactofanynewtechnologyusedbytheprojectoncostsschedulesqualityetc.asviewedbybothdevelopersandmanagersrecommendationsforfutureuseofthetechnologyFigure4-
10.SoftwareDevelopmentHistoryContents4-10GUIDELINESFOREVALUATINGCOMPLETEDDOCUMENTSThesoftwaremanagerwillbecriticallyreviewingcompleteddocuments.Thegeneralguidelinespresentedhereinvolvecheckingthedegreetowhichfivebasicattributesofasuccessfuldocumentarepresentinthedocumentunderreview:Accuracy—IsthedocumentcorrectArethereobviousmistakesAreassumptionsaboutresourcesandenvironmentvalidIsthereevidenceofalackofunderstandingofimportantaspectsoftheproblemorprocessClarity—IsthedocumentexpressedinaformthatisaccessibleandunderstandableAretablesanddiagramsusedwherepossibleinsteadoftextCompleteness—IstherightinformationincludedconsideringthepurposeofthedocumentHaveanynecessaryitemsbeenomittedWhenthedocumentreflectscontinuingdevelopmentfromapreviousdocumentdoesitcontainalltheelementsfromtheearlierdocumentConsistency—DopassagesinthedocumentcontradictotherpassagesinthesamedocumentDoallsymbolsconformtoastandardnotationLevelofdetail—DothecontentsreflectalevelofdetailappropriatetothepurposeofthedocumentIsmoreelaborationneededinaspecificareaThefollowingquestionscanbeusedtoanalyzethedocumentfortheexistenceandqualityofessentialfeatures.RequirementsandFunctionalSpecificationsAreallassumptionsaboutrequirementsdocumentedinthefunctionalspecificationsAreallrequirementsandfunctionalspecificationstestableaswrittenAreperformancerequirementsincludedIsitclearwhichrequirementsandspecificationsareidenticalorcloselysimilartothoseinexistingsystemsOperationsConceptDocumentAreoperatingscenariosrealisticIsitclearwhichoperationsconceptsmaptowhichrequirementsRequirementsAnalysisReportHastheeffectofTBDrequirementsbeenunderestimatedArethereadditionalsourcesofreusablesoftwareAreresourcessufficient4-11PreliminaryDesignReportHaveallfunctionalspecificationsbeenallocatedtosubsystemsAreallinterfacesunderstoodIstherationaleforthechosendesignjustifiableIsthesubsystempartitioningsensibleDetailedDesignDocumentArebaselinediagramsprovidedtothesubroutinelevelAreallexternalfilesdescribedincontentandformattothebytelevelAreallTBDrequirementsresolvedIfthedesignisfollowedwillthesystemmeetitsrequirementsIsthereevidenceofinformation-hidingi.e.localizingthedatausageandaccessIsthecouplingbetweenmoduleslowandarethemodulescohesiveTestPlansDothetestsdescribeexpectedresultsArethetestsrepeatablei.e.dothetestspecificationsadequatelydescribethesetupandenvironmentsothattwodifferentpeoplewouldproducethesametestsfromthetestdescriptionsHowwelldothetestscovertherangeofcapabilitiesArethereexplicitcriteriafordeterminingwhethertestresultsareacceptableIstheschedulereasonableinlightoftestresourcesUser’sGuideWillitbeunderstandabletotheusersIsitorganizedsothatitcanservedifferentuserpopulationssimultaneouslyAreexamplesprovidedIsinputdescribedinsufficientdetailArestatusmessageserrormessagesandrecoveryexplainedSystemDescriptionIsthedocumentstructuredtoaccommodateboththosewhowantonlyahigh-levelviewofthesystemandthosewhoseekadetailedviewIsthescopeofthesystemclearAretherelationshipstoothersystemsexplainedSoftwareDevelopmentHistoryIsthereanupdatelistthatshowswhenestimatesofsystemsizeeffortscheduleandcostweremadeHavealloftheproblemareasbeendiscussed4-12SECTION5—VERIFICATIONTESTINGANDCERTIFICATIONThissectionsummarizesrecommendedmethodsofverifyingvalidatingandcertifyingthesoftwaredevelopmentprocessandproduct.Bothtestingandnon-testingverificationtechniquesareusedtoevaluatethesoftwaresfunctionandperformancesothatproblemscanberepairedbeforetheireffectsbecometoocostly.Certificationsubjectstheproductandprocesstoindependentinspectionandevaluation.CODEREADINGCodereadingisasystematicprocedureforreadingandunderstandingtheoperationofaprogram.StudieshaveshownthatcodereadingdetectsmoreerrorsatalowercostthaneitherfunctionaltestingorstructuraltestingaloneReference
8.IntheexperienceoftheSELthemostpowerfulverificationcombinationishumaninspectionfollowedbyfunctionaltesting.Purpose—Codereadingisdesignedtoverifythatthecodeofaprogramunitiscorrectwithrespecttoitsintendedfunction.Participants—Codemustbereadbyanexperienceddeveloperwhoisnottheoriginalprogrammer.TheSELrecommendsthattwocodereadersbeassignedtoeachunitsincestudieshaveshownthatonlyonequarterofthetotalerrorsfoundincodereadingarefoundbybothreadersindependentlyReference
9.Activities—Alldevelopedcodemustberead.UnlesstheprojectisusingcleanroommethodologyReference9thecodeshouldbecleanlycompiledbeforehand.Eachreaderreviewsthecodeindependently.InadditiontocheckingfunctionalitythereaderensuresthecodeisconsistentwiththedesignspecifiedintheprologandPDLandthatitconformstostandardsandconventions.DetailedguidelinesforcodereadingareprovidedinSection2ofReference
10.Monitoring—Tomeasureprogressusetotalnumberofunitscodedversusnumbersuccessfullyread.UNITTESTINGUnittestingtakesplaceonlyafterthecodehasbeenread.Allnewlydevelopedorextensivelymodifiedunitsmustbeverifiedviaunittesting.NOTE:Ongoingresearcheffortsareexaminingsignificantlydifferentapproachestotestingattheunitlevel;seeReference
9.Aspectrumofformalityandrigorexistsforunittestingandintegration.Especiallycomplexorcriticalunitsmayneedtobetestedinisolationusingtestdriversandstubs.InothercasesitmaybemoreefficienttoconductunittestingonacollectionofrelatedunitssuchasanAdapackage.Themanagershouldselectthelevelofformalityandrigorthatismostcosteffectivefortheproject.Purpose—Unittestingverifiesthelogiccomputations/functionalityanderrorhandlingofaunit.Plan—Usuallywrittenbytheunitdeveloperunittestplansareinformal.Proceduresfortestingcomplexalgorithmsattheunitlevelarecontainedintheanalyticaltestplan.5-1Participants—TheunitdevelopergenerallyteststheunitunlessthecleanroommethodwithitsseparatetestteamisusedseeReference
9.Activities—Thetesterpreparestestdataandanynecessarydriversorstubs.He/shethenexecutesthetestplanverifyingalllogicpathserrorconditionsandboundaryconditions.Testresultsarereviewedforaccuracyandcompletenessbythetaskleaderordesignatedtechnicalauthority.Monitoring—Usenumberofunitsplannedversusnumbersuccessfullyunittestedtomeasureprogress;tracknumberoferrorsfoundtogaugesoftwarereliability.INTEGRATIONTESTINGPurpose—Integrationtestingverifiestheinternalintegrityofacollectionoflogicallyrelatedunitscalledamoduleandchecksthemodulesexternalinterfaceswithothermodulesdatafilesexternalinputandoutputetc.Plan—Althoughaformaltestplanisgenerallynotrequiredintegrationtestingismorecarefullycontrolledthanunittesting.Participants—Integrationtestingisusuallyperformedbythemembersofthedevelopmentteamresponsibleforthemodulesbeingintegrated.Activities—Duringintegrationtestingthesoftwareisslowlybuiltupbyaddingafewunitsatatimetoacoreofmodulesthathavealreadybeenintegrated.Integrationmayfollowatop-downapproachinwhichlowerlevelmodulesareaddedtothetop-leveldriverlevelbylevel.Alternativelyanend-to-endfunctionalpathorthreadmaybeconstructedtowhichothermodulesarethenadded.Monitoring—Usenumberofunitsplannedversusnumbersuccessfullyintegratedtomeasureprogress;tracknumberoferrorsfoundtogaugesoftwarereliability.BUILD/RELEASETESTINGAbuildisaportionofasoftwaresystemthatsatisfieswhollyorinpartasubsetoftherequirements.Abuildthatisacceptancetestedandsubsequentlydeliveredforoperationaluseiscalledarelease.Build/releasetestingisusedwhenthesizeofthesystemdictatesthatitbeimplementedinmultiplestages.Purpose—Buildtestingverifiesthattheintegratedsoftwarefulfillsapredeterminedsubsetoffunctionaloroperationalsystemrequirements.Plan—Theteststobeexecutedaredefinedinabuild/releasetestplan.BuildtestsareoftensubsetsofsystemtestsseeFigure4-
7.Participants—Buildtestingisgenerallyperformedandevaluatedbymembersofthesystemtestteam.Activities—Theactivitiesconductedduringbuildtestingarebasicallythesameasthoseofsystemtesting.5-2Monitoring—Usenumberoftestcasesidentifiedversusnumbersuccessfullytestedtomeasureprogress;formallytrackerrorsfoundtogaugereliability;trackeffortrequiredtofixtopredictmaintainability.SYSTEMTESTINGSystemtestingverifiesthefullend-to-endcapabilitiesofthesystem.Thesystemtestingphasefollowstheimplementationtestphase;itbeginsafterthelastbuildofthesystemhasbeensuccessfullycompleted.Wherehighreliabilitysoftwareisrequiredforaparticularmissionapplicatione.g.flightorsignificantreal-timesoftwareitisrecommendedthatsystemtestingbeplannedandperformedbyanindependentverificationandvalidationIVVteam.ExperiencewithintheSELenvironmenthasfoundtheuseofIVVaddsbetween5and15percenttototalprojectcosts.Purpose—Systemtestingverifiesthatthefullsystemsatisfiesitsfunctionalandoperationalrequirements.Thesystemmustbedemonstratedtobebothfunctionallycompleteandrobustbeforeitcanbeturnedovertoacceptancetesters.Plan—ThetestandverificationapproachisspecifiedinthesystemtestplanFigure4-
7.Asystemtestplanmaybedevelopedbasedonananalyticaltestplandesignedtoshowhowthecomputationalaccuracyofthesystemcanbeverifiedorbasedontheacceptancetestplan.Participants—Thesystemtestteamiscomposedofdeveloperssupportedbyoneormoreanalystsandisledbyaspecialistinthedevelopedapplication.Intheflightdynamicsenvironmentmissioncriticalapplicationsaretestedbyanindependentteam.Activity—Testexecutionfollowsthepatternprescribedinthesystemtestplan.Discrepanciesbetweensystemrequirementsandthetestresultsareidentifiedandassignedtomembersofthedevelopmentteamforcorrection.EachchangetothesystemishandledinaccordancewithestablishedCMprocedures.Regressiontestsareperformedafterrepairshavebeenmadetoensurethatthechangeshavehadnounintendedsideeffects.Systemtestingcontinuesuntilnomoreerrorsareidentified.Monitoring—Usenumberoftestcasesidentifiedversusnumbersuccessfullytestedtomeasureprogress;formallytrackerrorsfoundtogaugereliability;trackeffortrequiredtofixtopredictmaintainability.ACCEPTANCETESTINGAcceptancetestingisbegunaftersystemtestinghasbeensuccessfullycompleted.Completedraftsoftheusersguideandsystemdescriptionareprovidedtoacceptancetestersbythebeginningoftheacceptancetestphase.Purpose—Acceptancetestingverifiesthatthesystemsatisfiesitsrequirements.Plan—AllacceptancetestsexecutedarebasedontheacceptancetestplanwrittenbyanalystspriortothestartofthephaseseeFigure4-
7.5-3Participants—Testsareexecutedbytheacceptancetestteamsupportedbymembersofthedevelopmentteam.Testingmaybeobservedbyproductassurancerepresentativesandtheuser.Activity—Afterpreparationsfortestingarecompletedthetestteamattemptstoexecutealltestsintheplanworkingaroundanyerrorstheyuncover.Thisensuresthatmajorproblemsarediscoveredearlyinthephase.Onlywhenexecutionofaloadmodulei.e.anexecutableimageistotallyobstructeddoestestingceaseuntilanewloadmodulecanbeinstalled.Eachnewloadmoduleisregressiontestedtoensurethatpreviouslydemonstratedcapabilitieshavenotbeenadverselyaffectedbyerrorcorrections.Monitoring—Usenumberoftestcasesidentifiedversusnumbersuccessfullytestedtomeasureprogress;trackerrorsfoundtogaugereliability;trackeffortrequiredtofixtopredictmaintainability.TESTMANAGEMENTGUIDELINESAsummaryofessentialmanagementguidelinesonsoftwaretestingispresentedbelow.TheobservationsabouttheplanningandcontroloftestingarederivedfromSELexperience.Realizethattestingisimportant—30percentofdevelopmenteffortintheflightdynamicsenvironmentisdevotedtosystemandacceptancetestingApplyadequateresources·Time—35percentofthetimeschedule·Staff—experiencedwell-trainedindefectdetection·Computer—peakuseintestingphasesofFORTRANprojectsseeFigure3-2Planforitearly—aspartofthesoftwaredevelopment/managementplanPlanforitexplicitly—usingformattedtestplansseeFigure4-7TestcontinuallyduringthelifecyclewithfivemajortypesoftestingReference10—unitintegrationbuild/releasesystemandacceptancePreparefortesting—usetestabilityasacriterionforevaluatingrequirementsstatementsdesignsandbuild/releaseplansApplytestingaidsReference2·Requirementsallocationmatrices·Decisiontablesandtestsummarytables·TestlibraryMonitortestingcostsReference3—collectdataon·Calendartimeandstaffeffortspenttestingandverifyingsoftware·Costofdiagnosis—findingthedefect·Costofrepair—makingallthenecessarycorrectionstocodeanddocumentation5-4Measuretestingprogress·Comparetestingcostsandnumberofdefectswithpastprojects·Recorddefectdetectionrateastestingeffortisapplied·Tracknumberoftestsidentifiednumberexecutedandnumberpassed.ThepercentageofexecutedteststhatfailshouldbenearlyhalvedforeachsubsequentloadmoduletestedseeTable5-1Table5-
1.ExpectedPercentageofTestsExecutedThatPassLOADMODULEVersion1Version2Version3Version4AVERAGEPASSRATE50%77%88%99%PASSRATERANGE35-70%75-80%85-90%95-100%CERTIFICATIONBroadlydefinedcertificationisastatementattestingtosomething.Forexampleanindividualmaybechargedwithcertifyingthat·····CodingstandardswerefollowedCodeagreeswithPDLCMprocedureshavebeenfollowedSpecifictestcaseswererunAllcontractualitemshavebeendeliveredAlthoughthereisconsiderablediversityinwhatisbeingcertifiedtherearecommonaspectsaswell.Certificationisabinarydecision—eitherthematerialsoractivitiesarecertifiedortheyarenot.Itisperformedbyindividualswhocanbeobjectiveabouttheircertificationassignment.Thisobjectivityisakeyreasonforintroducingcertificationintothesoftwaredevelopmentprocess.Certificationcontributestoqualityassurancebyprovidinganindependentcheckondevelopment.Confidenceinthefinalsoftwareproductisenhancedifboththeprocessandproductarecertified.Essentialmanagementguidelinesforcertificationaresummarizedbelow.Determinetheobjectiveofthecertificatione.g.toensurethat·Designcodeordocumentationiscorrect·Standardsproceduresorguidelinesarebeingfollowed·SystemperformancemeetsoperationalrequirementsDefineentrycriteria—whatmaterialsmustbesubmittedforcertification·Establishproceduresforobtainingdocumentsorcodethatwillberequired·Identifytheindividualsresponsibleforcertification5-5Defineexitcriteria—certificationisabinarydecision.HowwillsubmittedmaterialsbeevaluatedtomakethecertificationdecisionSpecifythecertificationproceduredocumentitandfollowitMoredetailedrecommendationsdependontheobjectofcertification.Forexampleincertifyingintermediateproductslikedesignstestplansorunitcodethematerialssubmittedforcertificationandtheevaluationcriteriawillvary.Figure5-1showsthegeneralguidelinesappliedtoanexampleofunitdesigncertification.
1.CertificationObjectives:a.Ensurethedesigncorrectlyprovidesthefunctionalityrequiredoftheunitb.CheckforconformancewithstandardsandconventionsregardingprologandPDLc.Identifyvisibleweaknessesinthedesignearlysothatdefectscanberepairedwithminimumcostd.Encouragedeveloperstothoroughlyspecifyallunitinterfaces—callingargumentsparameterspecificationsetc.
2.EntryCriteria—thefollowingmaterialsmustbesubmitted:a.SourcelistingofprologandPDLb.Structurechartorobject-orienteddiagramofthesubsystemormajorcomponenttowhichtheunitbelongsc.Designcertificationformcontainingauthorsnamedatesubmittedforcertificationunitnameandsubsystemname
3.ExitCriteria—somequestionswillbespecifictothedesignmethodologyused.Thefollowingaremoregeneralquestionstypicallyusedtoevaluatesubmittedmaterialsanddecideoncertification:a.DotheprologandPDLadheretoallprevailingstandardsandconventionsb.Areallnecessaryelementsoftheprologcompletee.g.arealldataelementsdescribedc.DoesthePDLdescribeavalidprocessforprovidingthefunctionassignedtotheunitd.IsitclearfromthePDLwhentheunitoutputwillbegeneratede.IsthedependencyclearbetweeneachinputparameterorexternalreferenceandtheprocessingdescribedinthePDLf.DoesthePDLdefineenougherrordetectionlogicg.DoesthePDLaccountfortheupperandlowerboundsofunitinput
4.CertificationProcedure—recommendedstepsforthecertification:a.Meetwiththedevelopmentteamleadertoestablishthepositionofunitdesigncertificationintheprojectslifecycle;allunitsmusthavetheirdesigncertifiedbeforetheyareimplementedb.Issuewrittendescriptionsofentrycriteriawithexamplesoftherequiredformforsubmittedmaterialsc.Prepareaunitdesigncertificationchecklistbasedonexitcriteriatorecordevaluationresultsd.Documenttheprocedureforobtainingmaterialscompletingthecertificationchecklistandpresentingresultstothedevelopmentteame.ImplementtheprocedureretainingcertificationresultsintheprojectlibraryFigure5-
1.ExampleofUnitDesignCertification5-6SECTION6—METRICSANDKEYMANAGEMENTAIDSEffectivesoftwareprojectmanagementandcontroldependsonanaccurateassessmentofaprojectshealthatanypointinthelifecycle.Thisassessmentmustbebasedonup-to-datemetricsthatreflectthestatusoftheprojectbothinrelationtotheprojectplanandincomparisontomodelsofexpectedperformancedrawnfromhistoricalexperiencewithsimilarprojects.Thissectionpresentsusefulmetricsforprojectevaluationandcontrolanddiscussesseveraltoolsdesignedtoaidmanagersinperformingthesecriticalfunctions.METRICSSoftwaremetrics/measurescanprovidethemanagerwithkeyindicatorsofprojectperformancestabilityandquality.Bothobjectiveandsubjectivemeasuresareimportanttoconsiderwhenassessingthecurrentstateofaproject.Objectivedataconsistofactualcountsofitemse.g.staff-hoursSLOCcomponentstestitemsunitscodedchangeserrorsetc.thatcanbeindependentlyverified.Theyareusuallycollectedthroughaformaldatacollectionprocess.Subjectivedataarebasedonanindividualsoragroupsfeelingorunderstandingofacertaincharacteristicorconditione.g.levelofdifficultyoftheproblemdegreeofnewtechnologyinvolvedstabilityoftherequirementsetc..Togetherthesedataserveasasystemofchecksandbalancesthroughouttheproject.Thewisemanagerdependsonbothobjectiveandsubjectivedatatogetanaccuratepictureofprojecthealth.Subjectivedataprovidecriticalinformationforinterpretingandvalidatingtheobjectivedatawhiletheobjectivedataprovidetruecountsthatmaycausethemanagertoquestionhissubjectiveunderstandingandinvestigatefurther.Becausecollectingmaintainingandreportingmetricdatacanbeasignificantundertakingeachdataitemmustserveawell-definedpurpose.Theprojectsoftwaredevelopmentplanshoulddefinewhichdatawillbecollectedandhoweachdataitemwillbeused.Toachievethemaximumbenefitmetricdatamustbeaccuratecurrentandaccessibletothemanager.Theavailabilityofprojectmetricswillbeofnoorlittlevalueunlessthemanageralsohasaccesstomodelsormetricsthatrepresentwhatshouldbeexpected.Thisinformationisnormallyinthemindoftheexperiencedsoftwaremanager.Ideallysuchhistoricaldataandexperienceshouldalsobestoredinanorganizationalmemorydatabaseaccessibletonewmanagers.Usinginformationextractedfromsuchadatabasemanagerscangaugewhethermeasurementtrendsinthecurrentprojectdifferfromsimilarpastprojectsandfromtheexpectedmodelsforthelocalenvironment.ThecostsandbenefitsofsuchadatabasearefurtherdiscussedinReferences3and11respectively.TheSELprojecthistoriesdatabaseholdskeycharacteristicsandperformancemodelsofsoftwaredevelopmentintheSELenvironmentaswellasthreeclassesofdataforeachpastproject:costprocessandproductdata.Costdataareconfinedtomeasuresofeffort.Theuseofeffortdataremovestheeffectsoflaborratesandhardwarecostsallowingthemanagertofocusonthemoreaccuratelymodeledcostsofsoftwaredevelopmentandsystemengineering.Processdataincludeinformationabouttheprojectsuchasmethodologytoolsandtechniquesusedandinformationaboutpersonnelexperienceandtraining.Productdataincludesizechangeanderrorinformationandtheresultsofstatisticalanalysesofthedeliveredcode.6-1Figure6-1suggeststhepossibilitiesforusefulcomparisonwhenaprojecthistoriesdatabaseisavailable.Modelsbasedoncompletedprojectshelpthemanagerinitiateandrevisecurrentplansandestimates.Asperformancedataaregatheredforanewprojectthemanagercancomparethesevalueswiththoseforrelatedprojectsinthedatabase.ThecomparisonsinFigure6-1shouldbeviewedcollectivelyasonecomponentofafeedbackandcontrolsystem.Comparisonsleadtorevisionsindevelopmentplans.Toexecutetherevisedplansthemanagermakeschangesinthedevelopmentprocesswhichresultinadjustedmeasuresforthenextroundofcomparisons.CURRENTPROJECTMETRICSPLOTSComparewithorganizationalmemoryPROJECTHISTORIESANDMODELSCURRENTAssesshealthPLOTSComparewithprojectplanexpectationsCURRENTPROJECTPLANSUBJECTIVEDATAREVISEDPLANANDPROJECTADJUSTMENTFigure6-
1.ManagementThroughMeasurementMANAGEMENTMETRICSANDTHEIRUSEAnendlesslistofmetricscanbeproposedformanagementuserangingfromhigh-leveleffortandsoftwaresizemeasurestodetailedrequirementsmeasuresandpersonnelinformation.Qualitynotquantityshouldbetheguidingfactorinselectingmetrics.Itisbesttochooseasmallmeaningfulsetofmetricsthathavesolidbaselinesinthelocalenvironment.IntheSELeightkeymetricscontributetothesuccessfulmanagementofsoftwaredevelopmentprojects:1sourcecodegrowthrate2effortdata3systemsizeestimates4computerusage5errorrates6reported/correctedsoftwarediscrepancies7softwarechangerateand8developmentactivitystatusdata.Managersanalyzethemetricsindividuallyandinsetstogetanaccuratereadingofthehealthoftheirprojectswithrelationtocostscheduleandquality.Manyofthesemetricsprovidecriticalinsightintothestabilityofaproject—insightthatislackinginstandardperformancemeasurementsystems.Thefollowingpagesdescribetheseeightkeysoftwaremanagementmetrics.ThemodelspresentedhavebeendevelopedandrefinedbasedonthesoftwareheritagethatisrecordedintheSELdatabase.Ineachcasearealprojectexampleispresentedthatdemonstratestheuseofthemetric.6-2SOURCECODEGROWTHRATE–1DESIGNCODE/TESTSYSTEMTESTACCEPTANCETEST10090Deviation:Growthdataabovemodelbounds·Strongprogressindicatorduringimplementation807060PossibleCauses:aVeryexperiencedteambHighreusecMinimalQA·Keystabilityindicatorduringtestingphases50Deviation:Growthdatafall40belowmodelboundsPossibleCauses:·TracksamountofcodeSLOCinconfiguredlibrary302010aIncompletedesignbChangingrequirementscSmallerteamthannormal102030405060708090100%OFSCHEDULENOTE:OveralltrendisthesameforbothAdaandFORTRANsystems.AdasystemsshowmoregrowthinthedesignphaseascompiledPDLisproduced.Figure6-
2.SELSoftwareGrowthProfileThegrowthofsourcecodeintheconfiguredlibrarycloselyreflectsrequirementscompletenessandthesoftwaredevelopmentprocess.IntheSELenvironmentperiodsofsharpgrowthinSLOCareseparatedbyperiodsofmoremoderategrowthFigure6-
2.ThisisareflectionoftheSELpracticeofimplementingsystemsinbuilds.Themodelshowsthatinresponsetorequirementschanges10percentofthecodeistypicallyproducedafterthestartofsystemtesting.Adeviationfromthegrowthmodelsimplyemphasizesthattheprojectisdoingsomethingdifferently.Forexampleaprojectthatisreusingalargeamountofexistingcodemayshowasharpjumpearlyinthecodephasewhenreusedcodeismovedintotheconfiguredlibrary.Figure6-3showsanexamplefromtheSELenvironmentwherecodegrowthoccursinastep-wisefashionreflectingbuilds.TheGammaRayObservatoryGROAGSS250KSLOCdevelopedfrom1985to1989wasimpactedbytheshuttleaccident.Beginningwiththeimplementationphasetheschedulewasstretchedover3yearsandthestaffreducedaccordingly.100DESIGNCODE/TESTSYSTEMTESTACCEPTANCETEST9080BUILD3Explanation:Build1showsearly70605040302010BUILD2BUILD1rapidgrowthduetoahighlevelofcodereuse.Build3showsalongdelaybeforecompletingcodeinthemiddleofthesystemtestphase.Thiswasduetomajorspecificationproblemsintwoofthethreesubsystemsinvolved.102030405060708090100%OFSCHEDULEFigure6-
3.ExampleofCodeGrowth—GROAGSS6-3%OFTOTALLOC%OFTOTALLOCEFFORTDATA–2·Staffingprofilesshouldreflecttheenvironmentandprojecttype·Effortisakeyindicatorofprogressandquality·EffortdataarecriticalreplanningaidsTIMEFigure6-
4.SELStaffingProfileModelThetypicalstaffingprofilecloselyreflectsthenatureoftheprojectenvironmentandthetypeofproblembeingsolved.IntheSELenvironmentwhereasubstantialportionofrequirementsdetailsarenotknownuntilmid-implementationmanagersplanforaparabolicstaffingprofileinsteadofthetraditionalwidelyusedRayleighcurveseeFigure6-
4.Howeveronceaprojectisunderwaytheyexpecttoseethedoublyconvexcurveshownabove.Thecauseofthistrendisnotwell-understoodbutitoccursrepeatedlyonflightdynamicsprojectsinthisenvironmentandthereforeistheSELmodel.Anotherimportantprofileistheexpectedeffortdistributionamongsoftwaredevelopmentphasesandamongsoftwaredevelopmentactivities.TheSELeffortdistributionmodelsFigure6-5showsomedifferencesbetweenFORTRANandAdaprojects.FORTRANEffortDistributionbyPhaseDateDependentFORTRANADAOTHER26%DESIGN23%ACCEPT-ANCETEST20%DESIGN30%ACCEPT-ANCETEST20%DESIGN32%TEST30%CODE21%SYSTEMTEST16%CODE/TEST34%SYSTEMTEST19%CODE/TEST29%OTHERADADESIGN19%30%CODE16%TEST35%EffortDistributionbyActivityNotDateDependentNOTE:TheprojectssampledforthisfigurewereselectedforthepurposeofcomparingFORTRANtoAdaanddifferfromthoseusedtogenerateTables3-1and3-
2.Figure6-
5.SELEffortDistributionModels6-4DESIGNCODE/TESTSYSTEMTESTACCEPTANCETESTDeviation:MorestaffPossiblecauses:aMorecomplexproblembUnstablerequirementscInexperiencedteamRAYLEIGHCURVEDeviation:LessPossibleaVerybPoorqualitycEasyproblemtomeetschedulesextensivereworkSELEXPECTEDSELPROFILEstaffrequiredtomeetschedulesteamPLANNINGEFFORTTheSELhasfoundthesemetricstobekeyfactorsincharacterizingtheirenvironment.Theyarealsousedasayardstickforassessingtheimpactofnewtechnology.Utilizingtheexpectedeffortdistributionsandstaffingprofileamanagercanpredictthetotalcostandschedulebasedoneffortspenttodate.Ifmoreeffortisrequiredtocompletethedesignofasystemthanwasplanneditislikelythattheremainingphaseswillrequireproportionatelymoreeffortaswell.Afterinvestigatingwhythedeviationhasoccurredthemanagercanmakeaninformedchoiceastowhetherstafforschedulemustbeincreasedandcanplanaccordingly.Deviationsineffortexpenditurecanalsoraisequalityflags.Ifallmilestonesarebeingmetonanunderstaffedprojecttheteammayappeartobehighlyproductivebutproductqualitymaybesuffering.Inthiscasethemanagershouldnotautomaticallyreducefutureeffortpredictionsbutbasedonanauditofthedesignandcodemayneedtoaddstafftocompensateforworknotthoroughlycompletedinearlierphases.Figure6-6presentsanexampleoftheuseofmetricsdatainbothplanningandmonitoringaproject.TheEarthRadiationBudgetSatelliteERBSAGSS160KSLOCdevelopedduringthe1982-1984timeframeisconsideredtobeahighlysuccessfulproject.Effortdatawereakeyfactorinmanagementsdetectionandtimelycorrectionofseveralproblemsthatwouldhaveseriouslyjeopardizedprojectprogress.REQMTSPRELIMDETAILEDBUILDBUILDBUILDSYSTEMACCEPT-SYSTEM26ANALYSISDESIGNDESIGN123TESTINGANCETESTINGDELIVERY221814106SECONDREPLANFIRSTREPLANACTUALDATA2PDRCDRAUDIT0102030405060708090100110120Explanation:Theoriginalstaffingplanwasbasedonanunderestimateofthesystemsize.Towardtheendofthedesignphase40%moreeffortwasrequiredonaregularbasis.Thiswasoneofmanyindicatorsthatthesystemhadgrownandtheprojectwasreplannedaccordingly.Howevereffortcontinuedtogrowwhenthesecondplancalledforittoleveloffanddecline.Whenitwasclearthatstillmorestaffwouldberequiredtomaintainprogressanauditwasconducted.TheauditrevealedthattheprojectwasplaguedwithanunusuallylargenumberofunresolvedTBDsandrequirementschangesthatwerecausinganexcessiveamountofreworkandthat—aspartofthecorrectiveaction—anotherreplanwasnecessary.Figure6-
6.EffortDataExample—ERBSAGSS6-5FULL-TIME-EQUIVALENT40-HOURSWORKWEEKSOFSTAFFSYSTEMSIZEESTIMATES–3TrackschangeinestimatesoffinalsystemsizeinSLOCIs·akeyindicatorofsystemstabilitySizewilltypicallybeupto40%largerthanPDRestimatesEstimatesshouldbemademonthly5040302010DESIGNDeviation:SizeestimategrowsaboverangePossibleCauses:aIncompletedesignbSubstantiallychangingornewrequirementsCODE/TESTSYSTEMTESTACCEPTANCETESTby·projectmanagerMetricusedmustbeconsistent—eitherexecutabletotalornoncommentlines0-10PDRDeviation:SuddendecreaseinestimatePossibleCause:RequirementsremovedornegotiatedoutDeviation:LittleornogrowthfollowingPDRPossibleCauses:-20aVerystablewell-understoodrequirementsbTeamveryfamiliarwithapplication-30NOTE:AlthoughAdasystemsareusuallylargerthanFORTRANequivalentsnoappreciabledifferenceshavebeennotedinthegrowthpercentage.Figure6-
7.SELSizeEstimatesModelThegrowthofsoftwaresizeestimatesshouldreflectrequirementsstabilityandcompletenesswithintheenvironment.Theprofilemusteitherbebasedonheritageoronameasureofrequirementsclarityandcompleteness.IntheSELenvironmentalargenumberofTBDsintherequirementsandspecificationscombinedwithasubstantialnumberofrequirementschangestypicallycauseasystemtogrowupto40percentlargerthanisestimatedatthetimeofPDR.Asthedetailsoftheunknownportionsofthesystembecomeclearthesizeestimategrowsmorerapidly.TherangeofacceptedgrowthnarrowsasthesystemisclearlydefinedseeFigure6-
7.IntheexampleshowninFigure6-8investigationrevealedthattheprojectrequirementsweregrowingsubstantiallyandthatadditionalfundingwasneededtocompletethework.Symptom:Systemsizeexceeds40300000260000220000180000140000percentgrowththresholdmidwaythroughimplementation
1.Cause:Excessiverequirementschanges;entirelynewcapabilitiessubsystemsadded;andineffectivechangecontrolmechanism.CorrectiveActions:ReviewcostforrequirementssubmittedsinceCDRonacase-by-casebasis.Enforcechangecontrolproceduresonfuturespecificationmodifications.Requestmorebudgetandreplanbasedonresultingsystemsize
2.100000Figure6-
8.SampleSizeEstimates—UARSAGSS6-6DESIGNCODE/TESTSYSTEMTESTACCEPTANCETEST21Warningsign—estimatesunstableduetofollowsafterSIZEESTIMATEGROWTHPERCENTAGELINESOFCODE···COMPUTERUSAGE–4100CPUisakeyprogressindicatorfordesignandimplementationUseofCPUshouldreflectenvironmentandprocessphaseEitherCPUtimeornumberofrunsmaybeused0TIMENOTE:AdasystemsrequiremoreCPUtimethroughoutthedevelopmentlifecycle.HowevertheoveralltrendexpressedaspercentofthetotalisthesameforsimilarFORTRANandAdasystems.Figure6-
9.SELComputerUsageModelTheuseofCPUisdirectlyrelatedtotheparticularprocessbeingappliedbuttrendshavebeenfoundtobeheavilyenvironmentdependent.Theprofilemusteitherbebasedonheritageoraspecificprojectplan.UseofadevelopmentmethodologythatcallsforextensivedeskworksuchasthecleanroommethodologyReference9willinevitablycreatesignificantdeviations.OnatypicalSELflightdynamicsprojectasmallamountofCPUtimeisusedduringthedesignphaseforprototypingandenteringPDLmoretimeisusedinAdasystemsforwhichPDLiscompiled.ThesteepupwardtrendearlyintheimplementationphasereflectsanincreaseinonlinedevelopmentactivitiesseeFigure6-
9.SystemtestingisCPU-intensivecontinuingthetrend.Furtherbutslowerincreasesduringacceptancetestingareduetoextensivenumericaltestingandanalysis.Figure6-10isanexampleofCPUmetricstakenfromtheERBSAGSSdevelopedfrom1982to1984160KSLOC.ThisprojectdeviatedfromtheSELmodelandraisedaredflag.Inthiscaseinvestigationshowedthattheprojectwasbeingadverselyaffectedbyunstablerequirements.12001000Symptom:Computerusagezeromidwaythroughimplementation
1.800Cause:Projectdoingredesigninresponseto600excessiverequirementschangesinsteadofimplementation.400CorrectiveAction:Replanprojectbasedonnew2000scopeofwork
2.020406080100WEEKSFROMSRRFigure6-
10.ExampleofComputerUsage—ERBSAGSS6-7DESIGNCODEANDUNITTESTSYSTEMTESTACCEPTANCETESTDeviation:CPUPossibleCauses:aSignificantstaffingbExtensiveoverlapincreasingtooearlyincreaseaboveplanofdesignwithcodingabLowTeamcomputerToomuchhoursthanmodelCause:resourceshoursatstarttrainedonDESIGNCODE/TESTSYS.TESTACC.TEST12PERCENTOFTOTALCOMPUTERHOURSCPUHOURS360/75···ERRORRATES–5DESIGNCODE/TESTSYSTEMTESTACCEPTANCETEST·Trackerrorsvs.totalestimatedsizeofprojectindevelopedSLOC7Deviation:ProjectserrorrateisabovemodelboundsPossiblecauses:·Errorratesshouldcontinually6aUnreliablesoftwarebMisinterpretedrequirementscExtremelycomplexsoftwaredecreaseinsubsequentphases.TheSELhasfoundthehalvingmodelreasonableinwhichratesarecutby50%eachphase54·Accountingfordifferencesincoding3Deviation:ProjectserrorrateisbelowmodelboundsPossiblecauses:styleratesaresimilarforFORTRANandAdaalthoughclassesoferrorsdiffer21aReliablesoftwarebEasyproblemcInadequatetesting0SCHEDULEFigure6-
11.SELErrorRateModelTherearetwotypesofinformationintheerrorratemodelshowninFigure6-
11.Thefirstconsistsoftheabsoluteerrorratesexpectedineachphase.Theratesshownherearebasedonprojectsfromthemid-1980s.TheSELexpectsaboutfourerrorsperthousandSLOCduringimplementationtwoduringsystemtestandoneduringacceptancetesting.Analysisofmorerecentprojectsindi-catesthaterrorratesaredecliningasthesoftwaredevelopmentprocessandtechnologyimprove.Thesecondpieceofinformationisthaterrordetectionratesreduceby50percentineachsubsequentphase.Thistrendseemstobeindependentoftheactualvaluesoftheerrorrates.Itisstilltrueinrecentprojectswhereoverallerrorratesaredeclining.Howeveriftheerrorrateislowandthedetectionratedoesnotdeclinefromphasetophaseinadequatetestingandalessreliablesystemarelikely.Figure6-12isanexamplefromtheCosmicBackgroundExplorerCOBEAGSSsoftwaredevelopedfrom1987to1988175KSLOC.7654DESIGNCODE/TESTSYSTEMTESTACCEPTANCETESTSymptom:Lowererrorrateandlowererrordetectionrate.Cause:Earlyindicationofhighquality.Smoothprogressobservedinuncoveringerrorsevenbetweenphaseswell-plannedtesting.32Result:Provedtobeoneofthehighestqualitysystemsproducedinthisenvironment.10SCHEDULEFigure6-
12.SampleErrorRates—COBEAGSS6-8ERRORSPERKSLOCERRORSPERKSLOCREPORTED/CORRECTEDSOFTWAREDISCREPANCIES–6100%Observation:Projectscountofopendiscrepancyreportsisgrowing·KeyinformationisintheslopeoftheOpenReportscurvePossiblecauses:aInadequatestaffingtocorrecterrorsbSoftwareveryunreliableDiscrepanciesFoundDiscrepanciesFixedcAmbiguousorvolatile·ExpectsharpererrorincreasesatstartofeachphaseTrendsratesineachofthe·threecurvesprovideinformationModelissimilarforbothFORTRANandAdaprojects·0requirementsObservation:ProjectscountofopendiscrepancyreportsisdecreasingPossiblecauses:aStabledevelopmentbTesting/developmentprogressingcReliablewell-designedsoftwareeasytofixerrorsOpendiscrepancyreportsTIMEStartofTestingPhaseEndofTestingPhasFigure6-
13.SELSoftwareDiscrepancyStatusModelByconsistentlyrecordingreportedvs.fixeddiscrepanciesthemanagerwillgaininsightintosoft-warereliabilityprogressinattainingtestcompletionstaffingweaknessesandtestingquality.Theopenreportsshoulddeclineastestingprogressesunlessthereareinadequatestaffcorrectingpro-blemsorthesoftwareisexceptionallybuggy.Thepointatwhichtheopenandfixedcurvesintersectisthepointatwhichdefectsbecomecorrectedfasterthantheyarereported.AtthistimethemanagercanmoreconfidentlypredictthecompletionofthetestingphaseseeFigure6-
13.Thiserrordata—combinedwithtestexecutionsandpassrates—willenablethemanagertopredictqualityandcompletiondates.Whenthenumberoferrorsfoundislowerthanexpectedwhilethetestrateisatorabovenormalthesoftwareisofhighquality.TheexampleshowninFigure6-14isfromtheTrajectoryComputationandOrbitalProductsSystemTCOPSdevelopedfrom1983to
1987.Thetotalsizeofthissystemwas
1.2millionSLOC.1Symptom:Earlyintestingerrorswerenotgettingcorrectedfirst15weeks.
0.
80.
60.
40.20FoundOpenFixedCause:Lowerqualitysoftware.Errorswerenotfoundduringsystemtesting.CorrectiveActions:Staffingwasincreasedatweek20tohelpaddressopenerrors.Results:Systemattainedstabilityatweek35witherrorsbeingcorrectedfasterthantheywerebeingreported.0510152025303540WEEKSOFTESTINGFigure6-
14.ExampleofDiscrepancyTracking—TCOPS6-9NUMBEROFFAILUREREPORTSINTHOUSANDSRATEOFSOFTWARECHANGE–
79.00DESIGNCODE/TESTSYSTEMTESTACCEPTANCETEST
8.
007.00Deviation:ActualchangeratesareabovemodelupperboundsPossibleCauses:aRapidlychangingrequirementsReportedchangesincludeerrorsChangerateisakeystabilityindicatorBothabsoluterateandweeklyincrementsaresignificant
6.
005.
004.
003.
002.
001.00bInexperiencedteamcMorethoroughtestinghighqualitydErroneousspecificationsDeviation:ActualchangeratesfallbelowmodelboundsPossibleCauses:aStablerequirementsbCompletedesigncInadequatetesting
0.00NOTE:NodifferenceinchangeratehasbeennotedbetweensimilarFORTRANandAdasystemswhenadjustmentsaremadefordifferencesincodingstyle.Figure6-
15.SELChangeRateModelTherateatwhichthesoftwareischangingstronglyreflectsthesoftwaredevelopmentprocessandstabilityofprojectrequirementssoanymodelusedforcomparativeanalysismustbebasedonasolidunderstandingoftheenvironment.Twokeypiecesofinformationareshowninthemodel:atheabsolutevalueofthechangerateandbtheweek-to-weektrend.IntheSELenvironmenttheexpectedchangeratehasbeendeterminedthroughpastprojectmeasurement.ThemodelFigure6-15reflectsasteadyevengrowthofsoftwarechangesfrommid-implementationthroughacceptancetesting.Exaggeratedflatspotsperiodswithoutchangeoralargejumpmanychangesmadeatthesametimeinthedatashouldraiseflags.Somedeviationsofthisnaturemaybenormale.g.duringthetestingphasecodeCMproceduresoftencausechangestobeheldandrecordedasagroup.Howeveranydeviationisawarningsignthatshouldspurinvestigation.Figure6-16presentsanexamplefromtheSELenvironmentofaprojectthatexperiencedahigherthannormalchangerate.ThespecificationsfortheGeostationaryOperationalEnvironmentalSatelliteGOESAGSS129KSLOCdevelopedfrom1987to1989wereunusuallyproblematic.Manychangestotherequirementsweremadethroughouttheprojectevenafterimplementationhadbegun.EarlyrecognitionofthechangerateallowedmanagerstocompensateforthisbytighteningCMprocedures.
10.00DESIGNCODE/TESTSYSTEMTESTACCEPTANCETESTSymptom:Changeratehigherthannormalrangebeginningmidwaythroughimplementation.
9.
008.
007.
006.
005.
004.
003.
002.00Cause:Unusuallyhighnumberofspecificationerrorsandrequirementschanges.CorrectiveAction:StronglyenforcedCMprocedurestodealwithchanges.Result:High-qualityprojectdeliveredonschedule.
1.
000.00Figure6-
16.ChangeRateExample—GOESAGSS6-10CUMULATIVECHANGESPERKSLOCCUMULATIVECHANGESPERKSLOC···DEVELOPMENTACTIVITYSTATUSDATA–8·Keyprogressindicator·Indirectsoftwarequalityindicator·ModelmustreflectUnitsCodedUnitsReaddevelopmentmethodologyusedUnitsTested·MonitoronlymajoractivitiesStartofBuild1IMPLEMENTATIONEndofBuild1Figure6-
17.SELDevelopmentStatusModelforaSingleBuildDevelopmentstatusmeasuresprovideinsightintotheprogressofindividualdevelopmentactivitiesthatcompriseaparticularphase.Theseactivitiesshouldrepresentthemajorsequentialstepsrequiredtocompletedevelopmentofsoftwareunits.Developmentstatusmeasuresarevaluableindesignimplementationandtestingphases.IntheSELenvironmentmanagerstrackthesemeasuresindividuallytoseethatallactivitiesareprogressingsmoothlyandinparallel.Figure6-17presentsanidealisticmodelfortheactivitiesrequiredtoimplementasoftwarebuild.Figure6-18presentsanexamplefromtheSELenvironmentshowingdevelopmentstatusdatafortheentireimplementationphase.TheGOESDynamicsSimulatorinAdaGOADA171KSLOCwasdevelopedbetween1987and
1990.Theprojectfinishedcodeandunittestingnearlyonschedule.Whensevereproblemswereencounteredduringsystemintegrationandtestingitwasfoundthatinsufficientunittestinghadresultedinpoorqualitysoftware.800700600Symptom:Miraclefinish1—codereadingandunittestingactivitiescatchuptocodingneardeadlinewhena3-4weeklagwasstandardearlierinthephase.5004001Cause:Somecrucialtestinginformationwasnotavailable;shortcutsweretakenincodereadingandunittestingtomeetschedules.300TargetResult:Projectenteredthesystem200100UnitsCodedUnitsReadUnitsTestedtestingphasewithpoorqualitysoftware.Tobringthesoftwareuptostandardthesystemtestphasetook100%longerthanexpected.0IMPLEMENTATIONPHASEFigure6-
18.DevelopmentProfileExample—GOADA6-11UNITSADDITIONALMANAGEMENTMETRICSAsmentionedearliereachenvironmentmustdeterminewhichmetricsandindicatorsaremostusefulforsupportingthemanagementprocess.ObviouslytheeightSELmetricsjustdescribedarenotuniversallyapplicable.Inadditionothermeasuresmaybeusedforparticularprojectsbymanagersinenvironmentswithuniquecharacteristics.AlthoughnumerousadditionalmetricsaredefinedintheliteratureonlythosemeasuresthathavebeenusedsuccessfullyasmanagementaidsintheSELaredescribedbelowTable6-
1.Noneoftheserecommendedmeasuresareusefulwithoutsomebaselineorexpectationofwhatthevaluesmaybeinaparticularenvironment.Ifnoempiricaldataexistanorganizationmayproposebaselinesderivedfromsubjectiveestimates.Howeverassoonasametricsprogramisinstitutedthesubjectivebaselinesmustbesubstantiatedorrefinedusingobjectivedata.Table6-
1.SELRecommendedMetricsMETRICChangestosourceSOURCEToolFREQUENCYCOLLECT/ANALYZEWeekly/weeklyTYPICALLYUSEDINDETERMINING…Qualityofconfigurationcontrolstabilityofspecifications/designChangestospecificationsChangesclassesofCMDevelopersByevent/biweeklyByevent/monthlyQualityofspecificationstheneedtoreplanGoldplatingdesigninstabilityspecificationsvolatilityComputerusageToolBiweekly/biweeklyProgressdesigninstabilitiesprocesscontrolDiscrepanciesreported/openEfforttotalEffortperactivityTestersanddevelopersTimeaccountingDevelopersandByevent/biweeklyWeekly/weeklyWeekly/monthlyAreasofstaffingneedsreliabilityofsoftwareschedulesQualityofplanning/managingSchedulestheneedtoreplanmanagersEfforttorepair/tochangeErrorsperinspectionDevelopersDevelopersWeekly/monthlyByevent/monthlyQualityofdesigncostoffuturemaintenanceQualityofsoftwarelackofdeskworkErrorsclassesofErrorstotalDevelopersDevelopersByevent/monthlyByevent/monthlySpecificdesignproblemsSoftwarereliabilitycostoffuturemaintenanceSizemodulesplanned/ManagersBiweekly/biweeklyProgressdesigned/inspected/codedSizemanagersestimateoftotalSizesourcegrowthManagersToolMonthly/monthlyWeekly/weeklyStabilityofspecificationstheneedtoreplanQualityofprocessdesigncompleteness/qualityTBDsspecifications/ManagersBiweekly/biweeklyLevelofmanagementcontroldesignTestsplanned/TestersWeekly/weeklyCompletionschedulesprogressexecuted/passed6-12DATACOLLECTIONToproducethemetricsdescribedaccuratedatamustbeextractedfromthedevelopmentproject.Itisimportanttodeterminewhichmanagementmeasuresaregoingtobeutilizedduringthedevelopmentprocesssothateffortisnotexpendedincollectingextraneousdata.Table6-1includestherecommendedfrequencyforwhichdatausedforthemanagementmeasuresshouldbecollected.Italsocontainstherecommendedsourceofeachoftherequiredmetrics.Onceagainitshouldbenotedthatmostprojectswouldprobablyuseonlyasubsetofthemeasureslistedinthetable.Thecostinprojectoverheadtodefinecollectandutilizethemetricsdescribedisrelativelysmallprovidingthatonlythosemetricstobeusedinmanagementactivitiesareactuallycollected.Normallythreecategoriesofcostareassociatedwithametricsprogram:–––OverheadtoadevelopmentprojectfillingoutformsCostofprocessingthedataQAdataentrystoringfilingCostofanalyzingthedataresearchandprocessimprovementprogramsTheoverheadtothesoftwaredevelopmenttaskitselfforprovidingthelistedmetricsisminimal—wellunder
0.5%oftheprojectcost—whilethedataprocessingcostforthemanagementmetricsprogramshouldbenomorethan2%ofthecostoftheprojectinquestion.ThisincludesdataentrydataprocessinggeneratingsummaryoutputandroutineQA.Thethirdcategoryanalyzingdataisminimalforroutineuseinsoftwaredevelopmenteffortsandshouldbeconsideredanormalmanagerialresponsibility.Theanalysisfunctioncanbemuchmoreextensiveinenvironmentsthatareinvolvedwithafullprocessimprovementand/orsoftwareengineeringresearchprogram.Inthesecasesanalysiscostscouldrunashighas10to20percentofthetotaldevelopmenteffort.AUTOMATINGMETRICSANALYSISTHESOFTWAREMANAGEMENTENVIRONMENTAsthecorporatehistoryofanenvironmentgrowsandasthecharacteristicsofthesoftwareprocessarebetterunderstoodthroughthecollectionandapplicationofmetricsanorganizationshouldevolvetowardautomatingthestructurerepresentationandevenanalysisofthesemeasures.TheSELhasbuiltsuchatooltoaidintheuseofrelevantmetricstowardimprovedmanagementawareness.TheSoftwareManagementEnvironmentSMEReference12isanintegratedsetofsoftwaretoolsdesignedtoassistamanagerinmonitoringanalyzingandcontrollinganongoingsoftwareproject.ThemajorfunctionsoftheSMEincludetheabilitytotracksoftwareprojectparameters;tocomparethesefactorstopastprojects;toanalyzethedifferencesbetweenthecurrentprojectsdevelopmentpatternsandtheexpecteddevelopmentpatternwithintheenvironment;topredictcharacteristicssuchasmilestonescostandreliability;andtoassesstheoverallqualityoftheprojectsdevelopmentprocess.Toprovidethesefunctionsthetoolexaminesavailabledevelop-mentdatafromtheprojectofinterestincludingmanpowersoftwarechangescomputerutilizationandcompletedmilestones.Figure6-19depictsthearchitectureandtypicalusesofanautomatedtoolsuchasSME.Thebasisforthemodelsandinformationavailabletosuchatoolmustcomefromthecollectionofdatawithin6-13thedevelopmentenvironmentandshouldresultinsuchsummaryinformationaseffortdistributioninthelifecyclerelationshipequationsandtheimpactthatvaryingtechnologieshaveonthedevelopmentprocess.ExamplesareshowninFigure6-
20.PREDICTSystemSizeCurrentSizFinalSysteSizeErrors/1000KSLOCCTTimeSTATFinalErroRateSELDataBase·PastprojectdataANALYZECTCurrentErroRateCurrentProjectSTAT·ProductestimatesCurrentData·Projectcharac-teristicsSME#ofErrorsTimeErrorsbelownormabecauseof:
1.Insufficienttestin
2.Experienccedte
3.Problemlessdiffthanexpected·ProjecterrordataModelsandMeasures·ProfilesofpastperformanceRuleBase·RulesofS/WCTASSESSAboveTimeProjectAssessmEnd·Definitionsofkeyparameters·Modelandrela-tionshipsdevelopment·Problemandprojectcharac-teristics·Rulesforeval-NormaBelowuatingqualityGUIDANCEReliabilMaintainabiQualityCurrentProjectModel#ofErrorsCTTimeEndProjectwillbeveryunreliable;tocorrectyo
1.Improvecodereading
2.Tightenconfigurationc
3.EnforcecodingstandaFigure6-
19.ExampleSMEOutput6-14ModelEstimateComparisonofInterfaceErrorsDesign27%Testing28%Other20%Code25%4030%2010Adavs.FORTRAN342615FORTRAN1stAda2ndAda3rdAda·Knowledgeofsoftwaredevelopmentenvironment·HowdonewtechniquesormethodologiesimpactsoftwaredevelopmentModelofMeasureEffort=
1.48KSLOC.98ThistrendmeansDurationmonths=
4.6KSLOC.26CodeChangestestingisnotadequateNumberofComputerRuns=–
108.27+
150.88KSLOCCurrentProject·EvaluationofstrengthsandweaknessesAverageStaffSize=.24Effort.73·EstimationoffinalprojectparametersFigure6-
20.BuildCorporateMemoryIntoaToolGENERALINDICATORSOFPROJECTSTATUSThemetricsdescribedthusfarfunctionasobjectiveyardsticksagainstwhichthemanagercangaugeprojectprogressandquality.Thefollowingisalistofgeneralcharacteristics—somesubjective—thatsupplementthesemetricsasindicatorsoftrueprojectcondition.Frequencyofschedule/milestonechangesFrequencyandmagnitudeofchangesshouldbedecreasingthroughoutthedevelopmentprocess.ConsistencyinorganizationalstructurecomparedtooriginalplansMinoradjustmentstotheorganizationoftheprojectteamareexpectedbutmajorchangesindicateproblems.FluctuationinprojectstafflevelandsystemsizeestimatesFluctuationsshouldbewithinuncertaintylimitsthatbecomenarrowerasprojectdevelopmentevolves.EaseofaccesstoinformationonprojectstatusschedulesandplansRapidresponsestoquestionsaboutprojectstatusandschedulesreflectwellonthequalityofthesoftwaredevelopmentplan.NumberofovertimehoursrequiredorplannedtoattaincertainobjectivesRelyingonovertimehoursmayindicateproblemswiththestaffsqualificationsortheteamleadership.6-1524LevelofdetailunderstoodandcontrolledbytheprojectmanagerandprojectleaderManagersresponsestoquestionsaboutdevelopmentprogressindicatethedegreeofcontrolexercisedbyleadership.DiscrepanciesinstafflevelandworkloadMajordifferencesbetweenplannedworkloadandactualworkloadmayindicatelackofunderstanding.DiscrepanciesincomputerusageAdecreaseorslowstartinusingthecomputermayindicateincompletedesign.WARNINGSIGNALSANDCORRECTIVEACTIONSWhenaprojectisintroublethemanagermusttakeimmediatecorrectivemeasurestomoveitbackonasuccessfulcourse.ThefollowinglistsofwarningsignalsandcorrespondingcorrectiveactionsitemizemanyofthecommonproblemsidentifiedbytheSEL.ProblemsWithRequirementsandSpecificationsNumberofTBDrequirementshigherthannormornotdecliningIfcriticalspecificationsaremissingdesignoftheaffectedportionsofthesystemshouldnotproceeduntiltheinformationisobtained.Innoncriticalcasesdevelopmentmaycontinuedespitetheincompleteness.Assesstheeffectofmissingrequirements/specificationsanddeterminewhetherrelativelysafeassumptionsaboutthemissinginformationcanbemade.Beforestartingthenextphaseprepareariskmanagementplan.ForallTBDspecificationsassignduedatesforresolutionofTBDsandnotifyhighermanagementifschedulesarenotmet.Numberofrequirementsquestionssubmittedvs.questionsansweredishighandincreasingIndicatesinconsistentorconfusingspecifications.Difficultiesbecomecompoundedifdevelopmentispermittedtocontinue.Stopdevelopmentactivityandresolveinconsistencyorconfusioninconsultationwiththeuserorganization.Negotiateareductioninthescopeofthesystembydefininganunderstandablesubsetoftheoriginalsystem.Documentallassumptionsaboutrequirementsinthefunctionalspecification.Highnumberofspecificationmodificationsreceivedvs.numbercompletedIfmajorchangesoradditionstorequirementsareunavoidablethedesignoftheaffectedportionofthesystemmustbepostponed.Splitdevelopmentintotworeleaseswiththelatespecificationsincludedinthesecondrelease.HoldaseparateCDRforthesecondrelease.ProblemsWithSystemDesignActualnumberofcomponentsdesignedisfewerthanestimatedataparticularpointinthedetaileddesignphaseLackofdesigngrowthmaybeduetopoordirectionfromtheteamleaderinexperiencedstaffuseofnewtechnologyorchangingrequirements.Determinethecauseoftheslowgrowth.Basedonthecauseeitherreplacejuniorpersonnelwithseniorpersonnelprovidetrainingdecreasestaffsizetoamanageablelevelsetupaprototypingefforttoimprovetechnicalunderstandingordecreasethescopeofthesystem.6-16ProblemsWithImplementationActualnumberofunitscodedtestedandintegratedisfewerthanthoseestimatedataparticularpointintheimplementationphaseLackofcodegrowthmaybeduetopoordirectionfromtheteamleaderinexperiencedstaffchangingrequirementsorincompletedesign.Determinethecauseoftheslowgrowth.Basedonthecauseeitherreplacejuniorpersonnelwithseniorpersonnelstopstaffgrowthorholdchangesandcompleteimplementationofabuildfirst.NumberofcompletedunitsincreasesdramaticallypriortothescheduledendofabuildorreleasethemiraclefinishIndicatesthatcodereadingand/orunittestingwereinadequatelyperformedandmanycodingerrorshavenotbeenfound.Rescheduletheeffortsothatcodereadingisperformedproperly;otherwisesubstantiallymoretimewillbeconsumedduringsystemtestinginisolatingandrepairingerrors.ProblemsWithSystemorAcceptanceTestingTestingphasewassignificantlycompressedTestingmaynothavebeenascompleteorasthoroughasnecessary.Reviewtestplanandresultsclosely;scheduleadditionaltestingifindicated.ThenumberoferrorsfoundduringtestingisbelowthenormTestresultsmayhavereceivedinadequateanalysis.Usepersonnelexperiencedintheapplicationtoreviewtestresultsanddeterminetheircorrectness.Reruntestsasnecessary.ProblemsWithSystemConfigurationMorethanonepersoncontrolstheconfigurationSharingofconfigurationcontrolresponsibilitiescanleadtowastedeffortandtheuseofwrongversionsfortesting.Selectonepersonastheprojectlibrarianwhowillorganizeconfiguredlibrariesimplementchangestoconfiguredcomponentsandissuedocumentationupdatesaboutthesystem.ComponentchangesmustbeauthorizedbythetechnicalleaderresponsibleforQA.CorrectederrorsreappearThecorrectedversionmaynothavebeenusedbecausemorethanonepersoncontrolledtheconfigurationorthestaffwasnotawareoftherippleeffectofotherchangesthatshouldhavebeenmadewhentheoriginalerrorwascorrected.Consolidateconfigurationcontrolresponsibilityinoneperson.Assignmoreseniorstafftoanalyzetheeffectoferrorcorrectionsandotherchanges.ProblemsWithDevelopmentSchedulesContinualscheduleslippageStaffabilitymayhavebeenmisjudgedorthestaffneedsfirmerdirection.Bringinsenior-levelpersonnelexperiencedintheapplicationtodirectjunior-levelpersonnelandprovideon-the-jobtraining.Decreasethescopeofthesystem.6-17Developmentactivityisunevenandragged;effortdropsdramaticallyimmediatelyafteramilestoneisreachedPersonnelhavebeenassignedtoworkpart-timeontoomanyprojects.Staffwilltendtoconcentrateonasingleprojectatatimesometimestothedetrimentofotherprojectschedules.Reassignpersonnelpreferablytooneprojectbutnevertomorethantwoatatime.PersonnelturnoverthreatenstodisruptdevelopmentscheduleTheeffectofturnoverisnotdirectlyproportionaltothenumberofstaffinvolved.Foreachkeypersonwholeavesaprojecttwoexperiencedpersonnelshouldbeadded.Ajuniorprojectmembershouldbereplacedbyapersonatleastonelevelhigherinexperience.Onlyinthiswaycanamanagerbalancetheeffectsonthescheduleofthetrainingandfamiliarizationtimenewstaffwillrequire.CapabilitiesoriginallyplannedforonetimeperiodaremovedtoalatertimeperiodIfacorrespondingmoveoflatercapabilitiestoanearliertimeperiodhasnotbeenmadethedangeristhatthedevelopmentteamwillnotbeabletohandletheadditionalworkinthelaterperiod.Obtainjustificationforthechangewithdetailedscheduleinformationforthenewandoldplans.Iftheshiftofcapabilitiesisextensivestopdevelopmentactivityuntilthedevelopment/managementplancanberevisedthenproceed.ChangeordecreaseinplanneduseofmethodsorproceduresoccursThemethodsorprocedureshadsomeuseorexpectedbenefitortheywouldnothavebeenincludedinthedevelopmentplan.Obtainjustificationforthechangetoincludeshowinghowtheexpectedbenefitfromtheplanneduseofthemethodwillberealizedinlightofthechange.BASICSETOFCORRECTIVEACTIONSSomeconsistentthemesappearinthelistsofcorrectiveactionsregardlessofproblemarea.TheserecommendationsconstitutetheSELsbasicapproachtoregainingcontroloftheprojectwhendangersignalsarise:········StopcurrentactivitiesontheaffectedportionofthesystemandassesstheproblemCompletepredecessoractivitiesDecreasestafftomanageablelevelReplacejuniorwithseniorpersonnelIncreaseandtightenmanagementproceduresIncreasenumberofintermediatedeliverablesDecreasescopeofworkanddefineamanageabledoablethreadofthesystemAuditprojectwithindependentpersonnelandactontheirfindings6-18SECTION7—REVIEWSANDAUDITSReviewsandauditsaremethodsforassessingtheconditionoftheproject.Althoughbothtechniquesaddressqualityassurancebyexaminingtheplansmethodsandintermediateproductsassociatedwiththedevelopmentprocesstheyareconductedfordifferentreasons.Reviewsareroutinelyscheduledaspartofthedevelopmentprocess;theymarkkeyphasetransitionsinthesoftwarelifecycle.Auditsaregenerallynotpredeterminedbutareconductedwhenneededtoevaluatetheprojectsstatus.REVIEWSReviewsaredesignedtoprovideregularlyscheduledmonitoringofprojectstatus.Thefollowingfourquestionscanserveasgeneralguidelinesregardlessofthetypeofreview:IsthedevelopmentplanbeingfollowedIstheprojectmakingsatisfactoryprogressArethereindicationsoffutureproblemsIstheteampreparedtoproceedwiththenextphaseofdevelopmentReviewsmaybecharacterizedinvariouswayssuchasformalityortiming.Informalreviewsmaybeheldtobriefhigherlevelmanagersonthecurrentstateoftheproject.IntheSELenvironmentaninformalreviewisgenerallyheldfollowingcompletionofeachbuild.Itcoversimportantpointsthatneedtobeassessedbeforethenextphaseofimplementationisbegunsuchaschangestothedesignschedulesandlessonslearned.Aformalreviewgenerallyinvolvesamoredetailedpresentationanddiscussionandfollowsaprescribedagenda.Somereviewsmayresembleprogressreportsdeliveredatfixedintervalse.g.weeklyormonthly.IntheSELenvironmentfiveformalreviewsarerecommended—systemrequirementsreviewSRRsoftwarespecificationsreviewSSRpreliminarydesignreviewPDRcriticaldesignreviewCDRandoperationalreadinessreviewORR.ThesereviewsarescheduledatkeytransitionpointsbetweenlifecyclephasesseeFigure7-
1.LIFECYCLEPHASESREQUIREMENTSDEFINITIONANDSPECIFICATIONREQUIREMENTSANALYSISPRELIMINARYDESIGNDETAILEDDESIGNIMPLEMENTATIONSYSTEMTESTACCEPT-ANCETESTREVIEWSSRRSSRPDRCDRORRFigure7-
1.SchedulingofFormalReviewsTheremainderofthissectionexaminesthefivereviewsinorderofoccurrenceanddescribestheformatofthereviewpresentersparticipantsandagendakeyissuestobeaddressedatthereviewinadditiontothegeneralquestionsaboveandhardcopymaterialoutlineandsuggestedcontents.ThehardcopymaterialwillcontainsomeofthesameinformationfoundinthedocumentsdescribedinSection
4.Forexamplewhenpreparingthehardcopymaterialforthe7-1PDRsomeofthecontentsfromthecompletedpreliminarydesignreportcanbeused.ThemanagershouldalsokeepinmindthataswiththedocumentsinSection4thereissomeflexibilityinselectingthemostappropriateinformationtoincludeinthehardcopymaterial.Thecontentssuggestedinthissectionareintendedasaguideline.SYSTEMREQUIREMENTSREVIEWSRRFormatPresenters—requirementsdefinitionteamParticipants·Customerrepresentatives·Userrepresentatives·CCB·Seniordevelopmentteamrepresentatives·QArepresentativesTime—afterrequirementsdefinitioniscompleteandbeforetherequirementsanalysisphasebeginsAgenda—selectivepresentationofsystemrequirementshighlightingoperationsconceptsandcriticalissuese.g.TBDrequirementsMaterialsDistribution·Therequirementsandfunctionalspecificationsdocumentisdistributed1to2weekspriortoSRR·Hardcopymaterialisdistributedaminimumof3daysbeforetheSRRKeyIssuesToBeAddressedWhatistheeffectoftheTBDitemsWhattimetablehasbeenestablishedforresolvingTBDitemsHaveallexternalinterfacerequirementsbeendefinedAreoperationalmethodsandperformanceconstraintsunderstoode.g.timingaccuracyIstheprojectfeasiblegiventheconstraintsonandassumptionsaboutavailableresourcesSRRHardcopyMaterialAnoutlineandsuggestedcontentsoftheSRRhardcopymaterialarepresentedinFigure7-
2.7-
21.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.Agenda—outlineofreviewmateriallntroduction—purposeofsystemandbackgroundoftheprojectRequirementssummary—reviewoftop-levelbasicrequirementsdevelopedtoformthefunctionalspecificationsa.Backgroundofrequirements—overviewofprojectcharacteristicsandmajoreventsb.Derivationofrequirements—identificationofinputfromprojectofficesupportorganizationandsystemengineeringorganizationusedtoformulatetherequirements:supportinstrumentationrequirementsdocumentSIRDmemorandaofinformationMOIsandmemorandaofunderstandingMOUsc.RelationshipofrequirementstoIevelofsupportprovided—typicalsupportcriticalsupportandspecialorcontingencysupportd.Organizationsthatprovidesystemandsupportinputandreceivesystemoutpute.Dataavailability—frequencyvolumeandformatf.Facilities—targetcomputinghardwareandenvironmentcharacteristicsg.Requirementsforcomputerstoragefailure/recoveryoperatorinteractionsystemerrorrecoveryanddiagnosticoutputh.Requirementsforsupportandtestsoftware—datasimulatorstestprogramsandutilitiesi.Overviewoftherequirementsandfunctionalspecificationsdocument—itsevolutionincludingdraftdatesandreviewsandoutlineofcontentslnterfacerequirements—summaryofhumanspecial-purposehardwareandautomatedsysteminterfacesincludingreferencestointerfaceagreementdocumentsIADsandinterfacecontroldocumentsICDsPerformancerequirements—systemprocessingspeedsystemresponsetimesystemfailurerecoverytimeandoutputdataavailabilityEnvironmentalconsiderations—specialcomputingcapabilitiese.g.graphicsoperatingsystemIimitationscomputerfacilityoperatingproceduresandpoliciessupportsoftwarelimitationsdatabaseconstraintsresourcelimitationsetc.Derivedsystemrequirements—IistofthoserequirementsnotexplicitlycalledoutintherequirementsdocumentbutrepresentingconstraintsIimitationsorimplicationsthatmustbesatisfiedtoachievetheexplicitlystatedrequirementsOperationsconceptsa.High-leveldiagramsofoperatingscenariosshowingintendedsystembehaviorfromtheusersviewpointb.Sampleinputscreensmenusetc.;sampleoutputdisplaysreportsplotsetc;criticalcontrolsequencesRequirementsmanagementapproacha.Descriptionofcontrolleddocumentsincludingscheduledupdatesb.Specifications/requirementschangecontrolproceduresc.Systemenhancement/maintenanceproceduresPersonnelorganizationandinterfacesMilestonesandsuggesteddevelopmentscheduleIssuesTBDitemsandproblems—acharacterizationofalloutstandingrequirementsissuesandTBDsanassessmentoftheirrisksincludingtheeffectonprogressandacourseofactiontoresolvethemincludingrequiredeffortscheduleandcostFigure7-
2.SRRHardcopyMaterial7-3SOFTWARESPECIFICATIONSREVIEWSSRFormatPresenters—softwaredevelopmentteamParticipants·Requirementsdefinitionteam·Customerrepresentatives·Userrepresentatives·QArepresentativesforbothteams·CCBTime—afterrequirementsanalysisiscompletedandbeforepreliminarydesignisbegunAgenda—selectivepresentationoftheresultsofrequirementsanalysisdirectedprimarilytowardprojectmanagementandtheend-usersofthesystemMaterialsDistribution·Therequirementsanalysisreportandsoftwaredevelopment/managementplanaredistributed1to2weekspriortoSSR·Hardcopymaterialisdistributedaminimumof3daysbeforetheSSRKeyIssuesToBeAddressedHaveallrequirementsandspecificationsbeenclassifiedasmandatoryderivedwishlistinformationonlyorTBDIsthereuseproposalrealisticinviewofsoftwareavailabilityandcostdriversIstheselectedsystemarchitectureanappropriateframeworkforsatisfyingtherequirementsAretherequirementsandfunctionalspecificationstestableaswrittenHaveallrequirementsissuesandtechnicalrisksbeenaddressedIsthefoundationadequatetobeginpreliminarydesignSSRHardcopyMaterialAnoutlineandsuggestedcontentsoftheSSRhardcopymaterialarepresentedinFigure7-
3.7-
41.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.Agenda—outlineofreviewmaterialIntroduction—backgroundoftheprojectandpurposeofsystemAnalysisoverview—analysisapproachdegreeofinnovationrequiredinanalysisspecialstudiesandresultsRevisionssinceSRR—changestooperationsconceptsrequirementsandfunctionalspecificationseffectedfollowingtheSRRReusablesoftwaresummarya.Keyreusecandidates—identificationofexistingsoftwarecomponentsthatsatisfyspecificsystemfunctionalspecificationsexactlyorthatwillsatisfythemaftermodificationb.Overallarchitecturalconceptforthesystemc.MatrixofrequirementstobefulfilledbyreusedcomponentsClassificationsummarya.ListofrequirementsandfunctionalspecificationswiththeirassignedclassificationsmandatoryderivedwishlistinformationonlyorTBDb.Problematicspecifications—identificationanddiscussionofconflictingambiguousinfeasibleanduntestablerequirementsandspecificationsc.Unresolvedrequirements/operationsissuesincludingthedatesbywhichresolutionstoTBDsareneededFunctionalspecificationsa.High-leveldataflowdiagramsshowinginputtransformingprocessesandoutputb.DatasetdefinitionsforinterfacestothesystemDevelopmentconsiderationsa.Systemconstraints—hardwareavailabilityoperatingsystemlimitationsandsupportsoftwarelimitationsb.Utilitysupportandtestprograms—Iistofauxiliarysoftwarerequiredtosupportdevelopmente.g.datasimulatorsspecialtestprogramssoftwaretoolsetc.c.Testingrequirementsd.DevelopmentassumptionsRisksbothtocostsandschedules—includesrisksrelatedtoTBDorchangingrequirementsaswellastechnicalrisksSummaryofplannedprototypingeffortsneededtoresolvetechnicalrisksincludingthegoalsandscheduleforeacheffortPersonnelorganizationandinterfacesMilestonesandschedules—includesdevelopmentlifecyclephasestartandfinishdatesscheduleforreviewsinternalandexternalbuild/releasedatesdeliverydatesofrequiredexternalinterfacesscheduleforintegrationofexternallydevelopedsoftwareandhardwareFigure7-
3.SSRHardcopyMaterial7-5PRELIMINARYDESIGNREVIEWPDRFormatPresenters—softwaredevelopmentteamParticipants·Requirementsdefinitionteam·QArepresentativesfrombothgroups·Customerinterfacesforbothgroups·Userrepresentatives·CCBTime—afterthefunctionaldesigniscompleteandbeforethedetaileddesignphasebeginsAgenda—selectivepresentationofthepreliminarydesignofthesystem.ThematerialspresentedatPDRdonotnecessarilyshowthetechnicaldepththatthedevelopmentteamhasachievedduringthepreliminarydesignphasee.g.presentationofoperatingscenariosshouldbelimitedtothenominaloperatingandsignificantcontingencycases.FulldetailsofthetechnicaleffortaredocumentedinthepreliminarydesignreportMaterialsDistribution·Thepreliminarydesignreportisdistributedatleast1weekpriortoPDR·Hardcopymaterialisdistributedaminimumof3daysbeforePDRKeyIssuesToBeAddressedHavealternativedesignapproachesbeenexaminedAreallrequirementstraceabletosubsystemsinthefunctionaldesignIsthesubsystempartitioningsensibleinviewoftherequiredprocessingAreallinterfacedescriptionscompleteatboththesystemandsubsystemlevelAreoperationalscenarioscompletelyspecifiedIstheerrorhandlingandrecoverystrategycomprehensiveIstheestimateofresourcesrealisticIstheschedulereasonableHavetechnicalrisksincludinganyremainingTBDrequirementsbeenadequatelyaddressedHasthedesignbeenelaboratedinbaselinediagramstoasufficientlevelofdetailReference2presentsinformationonlevelofdetailDoesthedesignfacilitatetestingPDRHardcopyMaterialAnoutlineandsuggestedcontentsofthePDRhardcopymaterialarepresentedinFigure7-
4.7-
61.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.Agenda—outlineofreviewmaterialIntroduction—backgroundoftheprojectandsystemobjectivesDesignoverviewa.Designdriversandtheirorderofimportancee.g.performancereliabilityhardwarememoryconsiderationsprogramminglanguageetc.b.Resultsofreusetradeoffanalysesatthelevelofsubsystemsandmajorcomponentsc.ChangestothereuseproposalsincetheSSRd.Critiqueofdesignalternativese.Diagramofselectedsystemdesign.Showsproductsgeneratedinterconnectionsamongsubsystemsexternalinterfaces.Emphasisshouldbeonthedifferencesbetweenthesystemtobedevelopedandexistingsimilarsystemsf.MappingofexternalinterfacestoICDsandICDstatusSystemoperationa.Operationsscenarios/scripts—oneforeachmajorproductthatisgenerated.Includestheformoftheproductandthefrequencyofgeneration.Panelsanddisplaysshouldbeannotatedtoshowwhatvariousselectionswilldoandshouldbetracedtoasubsystemb.SystemperformanceconsiderationsMajorsoftwarecomponents—onediagrampersubsystemRequirementstraceabilitymatrixmappingrequirementstosubsystemsTestingstrategya.Howtestdataaretobeobtainedb.Drivers/simulatorstobebuiltc.SpecialconsiderationsforAdatestingDesignteamassessment—technicalrisksandissues/problemsinternaltothesoftwaredevelopmenteffort;areasremainingtobeprototypedSoftwaredevelopment/managementplan—briefoverviewofhowthedevelopmenteffortisconductedandmanagedSoftwaresizeestimates—oneslideMilestonesandschedules—oneslideIssuesproblemsTBDitemsbeyondthecontrolofthesoftwaredevelopmentteama.ReviewofTBDsfromSSRb.DatesbywhichTBDs/issuesmustberesolvedFigure7-
4.PDRHardcopyMaterial7-7CRITICALDESIGNREVIEWCDRFormatPresenters—softwaredevelopmentteamParticipants·Requirementsdefinitionteam·QArepresentativesfrombothgroups·Customerinterfacesforbothgroups·Userrepresentatives·CCBAttendeesshouldbefamiliarwiththeprojectbackgroundrequirementsanddesign.Time—afterthedetaileddesigniscompletedandbeforeimplementationisbegunAgenda—selectivepresentationofthedetaileddesignofthesystem.Emphasisshouldbegiventochangestothehigh-leveldesignsystemoperationsdevelopmentplanetc.sincePDR.SpeakersshouldhighlightthesechangesbothontheslidesandduringtheirpresentationssothattheybecomethefocusofthereviewMaterialsDistribution·Thedetaileddesigndocumentshouldbedistributedatleast10dayspriortoCDR·CDRhardcopymaterialisdistributedaminimumof3daysinadvanceKeyIssuesToBeAddressedAreallbaselinediagramscompletetothesubroutinelevelAreallinterfaces—externalandinternal—completelyspecifiedatthesubroutinelevelIstherePDLorequivalentrepresentationforeachsubroutineWillanimplementationofthisdesignprovidealltherequiredfunctionsDoesthebuild/releasescheduleprovideforearlytestingofend-to-endsystemcapabilitiesCDRHardcopyMaterialAnoutlineandsuggestedcontentsoftheCDRhardcopymaterialarepresentedinFigure7-
5.7-
81.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.Introduction—backgroundoftheprojectpurposeofthesystemandanagendaoutliningreviewmaterialstobepresentedDesignoverview—majordesignchangessincePDRwithjustificationsa.Designdiagramsshowingproductsgeneratedinterconnectionsamongsubsystemsexternalinterfacesb.MappingofexternalinterfacestoICDsandICDstatusResultsofprototypingeffortsChangestosystemoperationsincePDRa.Updatedoperationsscenarios/scriptsb.SystemperformanceconsiderationsChangestomajorsoftwarecomponentssincePDRwithjustificationsRequirementstraceabilitymatrixmappingrequirementstomajorcomponentsSoftwarereusestrategya.ChangestothereuseproposalsincePDRb.New/revisedreusetradeoffanalysesc.Keypointsofthedetailedreusestrategyincludingsoftwaredevelopedforreuseinfutureprojectsd.SummaryofRSLuse—whatisusedwhatisnotreasonsstatisticsChangestotestingstrategya.Howtestdataaretobeobtainedb.Drivers/simulatorstobebuiltc.SpecialconsiderationsforAdatestingRequiredResources—hardwarerequiredinternalstoragerequirementsdiskspaceimpactoncurrentcomputerusageimpactsofcompilerChangestothesoftwaredevelopment/managementplansincePDRImplementationdependenciesAdaProjects—theorderinwhichcomponentsshouldbeimplementedtooptimizeunit/packagetestingUpdatedsoftwaresizeestimatesMilestonesandschedulesincludingawellthought-outbuildplanIssuesrisksproblemsTBDitemsa.ReviewofTBDsfromPDRb.DatesbywhichTBDsandotherissuesmustberesolvedFigure7-
5.CDRHardcopyMaterial7-9OPERATIONALREADINESSREVIEWORRFormatPresenters—operationssupportteamanddevelopmentteamParticipants·Useracceptancetestteam·Requirementsdefinitionsoftwaredevelopmentandsoftwaremaintenancerepresentatives·QArepresentativesfromallgroups·Customerinterfacesforallgroups·CCBTime—afteracceptancetestingiscompleteand90daysbeforeoperationsstartAgenda—selectivepresentationofinformationfromthehardcopymaterialomittingdetailsthataremoreeffectivelycommunicatedinhardcopyformandhighlightingcriticalissuese.g.items7and8fromFigure7-6MaterialsDistribution·ORRhardcopymaterialisdistributedaminimumof5daysbeforeORRKeyIssuesToBeAddressedWhatisthestatusofrequiredsystemdocumentationWhatisthestatusofexternalinterfaceagreementsWerethemethodsusedinacceptancetestingadequateforverifyingthatallrequirementshavebeenmetWhatisthestatusoftheoperationsandsupportplanIstheresufficientaccesstonecessarysupporthardwareandsoftwareAreconfigurationcontrolproceduresestablishedWhatcontingencyplanstoprovideoperationalsupporthavebeenaddressedORRHardcopyMaterialAnoutlineandsuggestedcontentsoftheORRhardcopymaterialarepresentedinFigure7-
6.7-
101.
2.
3.
4.
5.Introduction—purposeofthesystemandoutlineofreviewmaterialSystemrequirementssummary—reviewoftop-levelbasicrequirementsa.Backgroundofrequirements—overviewofprojectcharacteristicsmajoreventsandsupportb.DerivedrequirementsupdatedfromSRRc.Relationshipofrequirementstosupportprovided—typicalcriticalandspecialorcontingencysupportd.Operationalsupportscenariose.Relationshipofrequirementsmatrixe.g.oftop-levelrequirementstooperationalsupportscenariosf.Organizationalinterfacese.g.thatprovidesystemandsupportinputandreceivesystemoutputg.Dataavailabilityfortheoperatingscenarios—frequencyvolumeandformath.Facilities—computinghardwareenvironmentcharacteristicscommunicationsprotocolsetc.i.Generalsystemconsiderations—high-leveldescriptionofrequirementsforcomputerstoragegraphicsandfailure/recovery;operatorinteraction;systemerrorrecoveryanddiagnosticoutput;etc.j.Supportandtestsoftwareconsiderations—high-IeveldescriptionofrequirementsfordatasimulatorstestprogramsandsupportutilitiesSummaryandstatusofIADs—statusofallinterfacedocumentswithexternalorganizationsSupportsystemoverviewa.Majorsoftwarecomponents—purposegeneralcharacteristicsandoperatingscenariossupportedbyprogramsandsubsystemsb.Testingphilosophyc.Requirementsverificationphilosophy—demonstrationofmethodsusedtoensurethatthesoftwaresatisfiesallsystemrequirements;matrixshowingrelationbetweenrequirementsandtestsd.Testingandperformanceevaluationresults—summaryofsystemintegrationandacceptancetestresults;evaluationofsystemperformancemeasuredagainstperformancerequirementse.Systemsoftwareanddocumentationstatus—summaryofcompletedworkpackagesandlistofincompleteworkpackageswithscheduledcompletiondatesandexplanationofdelaysStatusofoperationsandsupportplana.Organizationalinterfaces—diagramsandtablesindicatingorganizationalinterfacespointsofcontactandresponsibilities;dataflowandmediaformstapesvoiceIogb.Dataavailability—nominalscheduleofinputandoutputdatabytypeformatfrequencyvolumeresponsetlmeturnaroundtimec.Facilities—nominalscheduleofaccesstocomputerssupportandspecial-purposehardwareoperatingsystemsandsupportsoftwarefornormalcriticalemergencyandcontingencyoperationsd.Operatingscenarios—top-levelproceduresprocessingtimelinesandestimatedresourcesrequirede.Documentationofoperationsprocedures—operationsandsupporthandbooksandupdateproceduresFigure7-
6.ORRHardcopyMaterial1of27-
116.
7.
8.
9.Systemmanagementplana.Configuratloncontrolprocedures—explanationofstep-by-stepproceduresformaintainingsystemintegrityrecoveringfromlossfixingfaultsandenhancingsystemb.Enhancement/maintenanceprocedures—initiationformsreviewsapprovalandauthorizationc.Reporting/testingevaluationprocedures—formsreviewsapprovalauthorizationdistributiond.Systemperformanceevaluationprocedures—forongoingevaluationlssuesTBDitemsandproblems—acharacterizationofallthoseitemsaffectingnormaloperationsasperceivedbythedevelopersandusers;anassessmentoftheireffectonoperations;andacourseofactiontoresolvethemincludingrequiredeffortscheduleandcostContingencyplans—apriorityIistofitemsthatcouldpreventnormaloperationsincludingthestepsnecessarytoworkaroundtheproblemsthedefinedlevelsofoperationsduringtheworkaroundsandtheprocedurestoattempttoregainnormaloperationsMilestonesandtimelineofevents—diagramstablesandscriptsofevents;operatingscenarios;maintenance;enhancement;reviews;trainingFigure7-
6.ORRHardcopyMaterial2of27-12AUDITSThepurposeofanauditistoprovideanindependentassessmentofthesoftwareproject—itsconditionitsproblemsanditslikelihoodofreachingsuccessfulcompletion.Theauditmaybepromptedbyindicationsofproblemsorbylackofprogressoritmaybefulfillingaroutinecontractualrequirement.Occurrenceofoneormoreofthefollowingconditionsonaprojectshouldautomaticallytriggeranaudit:······Therearesignificant25%deviationsfromplannedstaffingresourcesorscheduleafterCDRThereisahighturnoverofstaff30%ItisapparentthatadeliveryschedulewillnotbemetThenumberoffailedtestsincreasestowardtheendofsystemoracceptancetestingItisdeterminedthatthesystemdoesnotfulfillacriticalcapabilityThereisevidencethatsysteminterfaceswillnotbemetatdeliveryAnindividualorpreferablyagroupoutsidethedevelopmentteamischargedwithconductingthisexamination.Itisessentialfortheauditteamtoobtainaclearwrittenstatementofthespecificobjectiveoftheauditatthestart.Whenpreparingtoconductanauditseveralkeyquestionsmustbeaddressed:WhatisthescopeoftheauditIstheentiredevelopmenteffortbeingexaminedoronlysomeparticlarcomponentoftheprojectWhatisthefinalformtheauditshouldtake—apresentationawrittenreportorbothTowhomwilltheresultsbepresentedWhatisthetimetableforcompletingtheauditWhatstaffandsupportresourceswillbeavailablefortheauditworkHavethedevelopmentteamanditsmanagementbeeninformedthatanauditisscheduledHavespecificindividualsonthedevelopmentteambeenidentifiedasprincipalcontactsfortheauditgroupWhatconstraintsexistontheworkoftheauditteamregardingaccesstodocumentsorindividualsWherearethesourcesfordocumentationrelatedtotheprojectrequirementsstatementsplansetc.AretherespecificauditingstandardsorguidelinesthatmustbeobservedTheanswerstothesequestionswillformthebasisforplanningtheaudittask.Sourcesofinformationincludepersonalinterviewswithmanagersteammembersandindividualswhointeractwiththedevelopmentteam.Documentationmustbereviewedtounderstandtheoriginoftherequirementsandtheplansandintermediateproductsofthedevelopmentteam.Fourstepsareinvolvedinconductingtheauditofasoftwaredevelopmentproject:····DeterminethecurrentstatusoftheprojectDeterminewhetherthedevelopmentprocessisundercontrolIdentifykeyitemsthatareendangeringsuccessfulcompletionIdentifyspecificactionstoputtheprojectontoasuccessfulcourse7-13AUDITSTEP#1—DETERMINETHECURRENTSTATUSOFTHEPROJECTAuditQuestionGiventhesizeandnatureoftheproblemwhereshouldAuditTeamsChecklist·ConsultTable3-1andprojecthistoriesdatabaseseeSection6forcomparisondataonsimilarprojects:theprojectbe—Percentageofeffortandscheduleconsumedthusfar—Percentageofeffortbytypeofactivity—PercentageofcodedevelopedthusfarAccordingtothedevelopment/managementplanwhere·Refertothesoftwaredevelopment/managementplanfortheproject:shouldtheprojectbe—Whatactivitiesshouldbecurrent—Howshoulditbestaffed—Whatintermediateproductsshouldhavebeendelivered—WhatmilestonesshouldhaveoccurredWheredoestheprojectactuallystandnow·Frominterviewsanddocumentationidentifythefollowing:currentphasemilestonesreacheddocumentsdeliveredactivitylevelsstaffcompositionprojectbudgetandactualexpendituresAUDITSTEP#2—DETERMINEWHETHERTHEDEVELOPMENTPROCESSISUNDERCONTROLAuditQuestionAuditTeamsChecklistIstheproblemwellunderstood·RefertoreviewhardcopymaterialsFigs.7-27-37-47-5andandstabletheRequirementsAnalysisReportFigure4-4forsignificanceofTBDitems·Determinethenumberoftimesprojectsizehasbeenreestimatedandtheextentoftheserevisions·FromthetechnicalmanageridentifythenumberandextentofspecificationmodificationsreceivedbythedevelopmentteamIsthedevelopment/management·Comparethedevelopment/managementplantoactualplanbeingfollowedIsadequatedirectionbeingprovideddevelopmenttodeterminewhether—Thescheduleisbeingfollowed—Milestoneshavebeenmet—TheplanisbeingupdatedseeSection2—Actualandplannedstaffinglevelsagree·Interviewteamleaderstechnicalmanagersandadministrativemanagerstodeterminewhetherthereisagreementon—Projectscopeandobjectives—Expectationsandresponsibilitiesateachlevel—Progressofthedevelopmentefforttodate7-14AUDITSTEP#3—IDENTIFYKEYITEMSTHATAREENDANGERINGSUCCESSFULCOMPLETIONAuditQuestionAreresourcesadequateIsthedevelopmentprocessadequateAretheorganizationandplanningadequateAuditTeamsChecklist·Time—determineiflackofscheduletimeregardlessofstaffisaconcernbycomparisontopastprojectsSection6andbytimeestimatesSection3·Staff—compareactualwithdesiredstaffingcharacteristicsastolevelofeffortSection3staffingpatternFigure6-4teamsizeTable3-5andcompositionTable3-6·Computer—compareactualwithexpectedutilizationFigures3-2and3-3;frominterviewsandcomputerfacilityschedulesdeterminedegreeofaccesstocomputerandlevelofserviceprovided·Support—compareactuallevelofsupportservicestotypicallevels·Determinewhethertechnicalstandardsandguidelinesarebeingfollowedfordesigncodingandtesting·Determinewhetheravailabletoolsandmethodologiesarebeingused·Frominterviewsdeterminetheproceduresforreportingandresolvingproblems·Frominterviewsassessthereportingrelationshipsthatexisttheteammoraleandturnoverandthepatternofdelegatingwork·Assessthequalitycompletenessandpracticalityofthesoftwaredevelopment/managementplanseeSection2·FrominterviewsanddocumentationSections2and7identifytheextentofcontingencyplanningAUDITSTEP#4—IDENTIFYSPECIFICACTIONSTOPUTTHEPROJECTONASUCCESSFULCOURSE·Recommendedactionsmustbebasedonresultsofauditsteps12and3·Forgeneralproblemofinadequateprogresssomeoptionsareasfollows–Stopdevelopment;generatearealisticplanbeforecontinuing–Replacejuniorpersonnelwithseniorstaff–Increasevisibilitybyimprovingidentificationandreviewofintermediateproducts–Providetraining7-15APPENDIXA—SELSOFTWAREDEVELOPMENTENVIRONMENTPROCESSCHARACTERISTICSDurationmonthsEffortstaff-yearsSize1000sourcelinesofcodeAVG.2414107HIGH4332246LOW19331StafffulltimeequivalentAveragePeakIndividuals81322153044456ApplicationExperienceyearsManagersTechnicalStaff9415742OverallExperienceyearsManagersTechnicalStaff146199104NOTES:TypeofsoftwareScientificground-basedinteractivegraphicMachine:sIBM4341andDECVAX7808600and8810Sample:10FORTRANwith15%inAssemblerand3AdaprojectsStaff-year=1864efforthoursA-1:GLOSSARYAGSSATRCCBCDRCMCOBECPUERBSGOADAGOESGROIADICDI/OIVVLOCMOIMOUORRPDLPDRQARSLSEFSELSIRDSLOCSMESRRSSRTBDTCOPSattitudegroundsupportsystemAssistantTechnicalRepresentativeconfigurationcontrolboardcriticaldesignreviewconfigurationmanagementCosmicBackgroundExplorercentralprocessingunitEarthRadiationBudgetSatelliteGOESDynamicsSimulatorinAdaGeostationaryOperationalEnvironmentalSatelliteGammaRayObservatoryinterfaceagreementdocumentinterfacecontroldocumentinput/outputindependentverificationandvalidationlinesofcodememorandumofinformationmemorandumofunderstandingoperationalreadinessreviewprogramdesignlanguagepseudocodepreliminarydesignreviewqualityassurancereusablesoftwarelibrarysubjectiveevaluationformSoftwareEngineeringLaboratorysupportinstrumentationrequirementsdocumentsourcelinesofcodeSoftwareManagementEnvironmentsystemrequirementsreviewsoftwarespecificationsreviewtobedeterminedTrajectoryComputationandOrbitalProductsSystemG-1REFERENCESl.SoftwareEngineeringLaboratorySEL-81-104TheSoftwareEngineeringLaboratoryD.N.Cardetal.February
19822.—SEL-81-205RecommendedApproachtoSoftwareDevelopmentF.E.McGarryG.PageS.Eslingeretal.April
19833.—SEL-81-101GuidetoDataCollectionV.E.ChurchD.N.CardandF.E.McGarryAugust
19824.—SEL-83-001AnApproachtoSoftwareCostEstimationF.E.McGarryG.PageD.N.Cardetal.February
19845.—SEL-90-003AStudyofthePortabilityofanAdaSystemintheSoftwareEngineeringLaboratoryL.O.JunS.R.ValettJune
19906.H.D.RombachB.T.UleryMeasurementBasedImprovementofMaintenanceintheSELProceedingsoftheFourteenthAnnualSoftwareEngineeringWorkshopSEL-89-007November
19897.SoftwareEngineeringLaboratorySEL-87-008DataCollectionProceduresfortheRehostedSELDatabaseG.HellerOctober
19878.—SEL-85-001AComparisonofSoftwareVerificationTechniquesD.N.CardR.W.SelbyJr.F.E.McGarryetal.April
19859.—SEL-90-002TheCleanroomCaseStudyintheSoftwareEngineeringLaboratory:ProjectDescriptionandEarlyAnalysisS.Greenetal.March
199010.—SEL-85-005SoftwareVerificationandTestingD.N.CardC.AntleandE.EdwardsDecember
198511.F.E.McGarryWhatHaveWeLearnedin6YearsProceedingsoftheSeventhAnnualSoftwareEngineeringWorkshopSEL-82-007December
198212.SoftwareEngineeringLaboratorySEL-89-003SoftwareManagementEnvironmentSMEConceptsandArchitectureW.DeckerandJ.ValettAugust1989R-1。