軟件行業(yè)的質(zhì)量管理英文

軟體品質(zhì)管理IntroductionWhatissoftwarequality?Howcanitbemeasured?Howcanitbemeasuredbeforethesoftwareisdelivered?SomekeyqualityfactorsSomemeasurableindicatorsofsoftwarequalityIntroductionThinkofaneverydayobjecte.g.achairHowwouldyoumeasureit’s“quality”?constructionquality?(e.g.strengthofthejoints,…)aestheticvalue?(e.g.elegance,…)fitforpurpose?(fortable,…)AllqualitymeasuresarerelativethereisnoabsolutescalewecansayAisbetterthanBbutitisusuallyhardtosayhowmuchbetterForsoftware:constructionquality(建造的品質(zhì))?softwareisnotmanufacturedaestheticvalue(美學(xué)上的價(jià)值)?butmostofthesoftwareisinvisibleaestheticvaluemattersfortheuserinterface,butisonlyamarginalconcernfitforpurpose?Needtounderstandthepurpose軟體品質(zhì)因素MeasuringQualityTheQualityConcepts(abstractnotionsofqualityproperties)MeasurableQuantities(definesomemetrics)CountstakenfromDesignRepresentations(realizationofthemetrics)usabilityminutestakenforsomeusertask???timetakentolearnhowtouse?complexitycountprocedurecalls???informationflowbetweenmodules?reliabilityrunitandcountcrashesperhour???meantimetofailure?examples...FourKeyQualityConceptsReliabilitydesignermustbeabletopredicthowthesystemwillbehave:completeness-doesitdoeverythingitissupposedtodo?(e.g.handleallpossibleinputs)consistency-doesitalwaysbehaveasexpected?(e.g.repeatability)robustness-doesitbehavewellunderabnormalconditions?(e.g.resourcefailure)EfficiencyUseofresourcessuchasprocessortime,memory,networkbandwidthThisislessimportantthanreliabilityinmostcasesMaintainabilityHoweasywillitbetomodifyinthefuture?perfective,adaptive,correctiveUsabilityHoweasyisittouse?McCall’sQualityFactorsoperationrevisiontransitionCorrectnessreliabilityusabilityintegrityefficiencyMaintainabilityFlexibilityTestabilityPortabilityReusabilityInteroperabilityGeneral

utilityportabilityAs-isutilityMaintainabilityreliabilityefficiencyusabilitytestabilityunderstandabilitymodifiabilitydevice-independenceself-containednessaccuracycompletenessrobustness/integrityconsistencyaccountabilitydeviceefficiencyaccessibilitycommunicativenessself-descriptivenessstructurednessconcisenesslegibilityaugmentabilitySource:SeeBlum,1992,p176ProductoperationusabilityProductrevisionProducttransitionintegritymaintainabilitytestabilityreusabilityportabilityinteroperabilityoperabilitytrainingI/OvolumeAccesscontrolAccessauditStorageefficiencyconsistencyinstrumentationexpandabilitygeneralitySelf-descriptivenessmodularitymachineindependences/monalityefficiencycorrectnessreliabilityflexibilitycommunicatativenessI/OrateexecutionefficiencySource:SeevanVliet2000,pp111-3traceabilitycompletenessaccuracyerrortolerancesimplicityconcisenessdatacommonalityMeasurablePredictorsofQualitySimplicitythedesignmeetsitsobjectivesandhasnoextraembellishmentscanbemeasuredbylookingforitsconverse,complexity:controlflowcomplexity(numberofpathsthroughtheprogram)informationflowcomplexity(numberofdataitemsshared)namespacecomplexity(numberofdifferentidentifiersandoperators)Modularitydifferentconcernswithinthedesignhavebeenseparatedcanbemeasuredbylookingat:cohesion(howwellcomponentsofamodulegotogether)coupling(howmuchdifferentmoduleshavetocommunicate)QualityandhowtoachieveitProductquality––alwaysanissueAfterWWII,industryintheUSandelsewherehassubstantiallyimprovedqualityviaextensivetestingandstatisticalqualitycontrolJapaneseindustryhasfollowedadifferentconcept,a.k.a.totalqualityinitiative(Deming,Juran),wherequalitycontrolisanintrinsicaspectoftheproductionprocess,notapost-productionactivityInotherwords,youshoulddesignthequalityproductandbuilditright,ratherthanbuilditandthenmakesureithasgoodqualitySEIandtheCapabilityMaturityModelSoftwarequalityimprovementhasledtotheestablishmentoftheSoftwareEngineeringInstituteatCarnegie-MellonUniversityCapabilityMaturityModel(CMM)aframeworktoassessthematuritylevelofanorganization’ssoftwaredevelopmentandmanagementprocessesCMMconsistsoffivelevelsofmaturityasmeasuredbyasetofguidelinescalledthekeyprocessareasHigherlevelsincreasecompetitiveness,reduceriskLevelsaremonotonic:levelnincludesallthecharacteristicsofallthelevelsbelow,n-1,n-2,etc.CapabilityMaturityModelLevel5OPTIMIZEDLevel4MANAGEDLevel3DEFINEDLevel2REPEATABLERISKCOMPETITIVENESSLevel1INITIALLevel1—Initialend…SoftwaredevelopmentfollowsnoprescribedprocessYoudon’’tknowwhereyoustand,orwhenwillyoufinish,orwhatyouwillgetwhenyoufinishYouhavetobehappywithwhatyougetattheLevel2——RepeatableProjectmanagementprocessesandpracticesareestablished,inordertotrackprojectcosts,schedules,andfunctionalityStill,youjustpassivelytrackwhat’’sgoingon……anddon’’tknowexactlywhatyoushoulddoLevel3—DefinedAstandardsystemdevelopmentprocess(sometimescalleda““methodology”)purchasedordeveloped,andintegratedthroughouttheITunitoftheorganization…whichmeansthatthereisaprescribedsequenceofstepstofollow,plusyoumonitortheoutcomesLevel4—ManagedMeasurablegoalsforqualityandproductivityareestablishedConstantmonitoringgivesreal-timedataaboutthestatusoftheprocessandproductProcessparametersadjustedinordertoobtaindesiredoutcomes(thatismanagement,afterall)Level5—OptimizingThestandardizedsystemdevelopmentprocesscontinuouslymonitoredandimproved,basedonmeasuresanddataanalysisestablishedinLevel4Changescanbemadetoprocessparameters……Butwecanmakechangeintheprocessitself(e.g.,choosedifferentsequence,changepriorities,evenintroduceadditionalstepsordeletesomethatdonotcontributetotheprocess/productquality)CMMcertificationprocessCMMassessmentperformedbyqualifiedpersonnelfromSEI,throughinterviewsandanalysisofproceduresanddocumentsusedintheorganizationLevelscanbeawardedtoorganizationsorspecificprojects/projectgroupswithinanorganization.Eachlevelhasitsownquestionnaire,withanumberofmandatoryandoptionalquestionsInordertoqualifyforaspecificlevel,Yesanswersmustbepresentineachgroup(thoughminimumpercentagesaredifferent)CMMcertificationprocessEachquestionnairefocusesonanumberoftheso-calledKeyProcessAreas(KPAs)EachlevelofCMMscalehasanassociatedsetofKeyProcessAreas(KPAs)Toqualifyforaspecificlevel,issuesrelatedtoKPAsforthatlevelmustbeaddressedToprogressfromoneleveltothenextoneup,improvementsinappropriateKPAshavetobemadeLevelsaremonotonic––makesnosensetoconcentrateonKPAsfor,say,level4,ifthedevelopmentprocessisstillatlevel1or2關(guān)鍵流流程領(lǐng)領(lǐng)域（（KeyProcessArea,KPA)階層特徵關(guān)鍵流程領(lǐng)域（KPA）品質(zhì)方法5最佳層（Optimizing）持續(xù)流程改善最佳化的管理◎缺陷預(yù)防

◎技術(shù)變更管理

◎流程變更管理從流程變異最小化4管理層（Managed）產(chǎn)品與流程品質(zhì)評(píng)量定量化的管理◎定量流程管理

◎軟體品質(zhì)管理從預(yù)防問(wèn)題發(fā)生3定義層（Defined）流程定義與制度化定性化的管理◎組織流程特徵

◎組織流程定義

◎同等審查

◎訓(xùn)練課程

◎整合軟體管理

◎軟體產(chǎn)工程

◎群體間協(xié)調(diào)及早發(fā)現(xiàn)問(wèn)題與矯正2重覆層（Repeatable）專案管理使用經(jīng)驗(yàn)的管理軟體專案追蹤◎軟體專案計(jì)畫(huà)

◎軟體副合約管理

◎軟體品質(zhì)保證

◎軟體構(gòu)型管理

◎需求管理專案最終的測(cè)試1初始層

（Initial）個(gè)人主義，毫無(wú)章法的管理SomeproblemswithCMM(atleastinitially)Focusesonproject/processmanagement,notproductdevelopmentIgnoresuseofcertainadvancedtechnologiesDidnotincorporateriskanalysisasaKPADidnotdefineitsdomainofapplicabilityButthingshaveevolved/diversified:ModelsthattheSEIiscurrentlyinvolvedindeveloping,expanding,ormaintaining:CapabilityMaturityModelIntegration(CMMISM)SW-CMMCapabilityMaturityModelforSoftwareP-CMMPeopleCapabilityMaturityModelSA-CMMSoftwareAcquisitionCapabilityMaturityModelSE-CMMSystemsEngineeringCapabilityMaturityModelIPD-CMMIntegratedProductDevelopmentCapabilityMaturityModelISO9000ISO9000seriesofqualitystandards,someofwhicharerelatedtosoftwareandISdevelopmentISOprinciples:SaywhatyouwilldoDoasyouhavesaidProvethatyoudidsoNOTE:thisisaverysimplifiedview––thecertificationprocessandthedocumentationrequiredtogothroughitarequiteextensiveanddetailedISOcertificationisperformedthroughnationalstandardsorganizationsCMMvs.ISOPartialoverlap,butdoubtsremainItseemspossiblethatanorganizationcanbecertifiedforISO9000andstillbeatlevel1oftheCMMscale,orbeatlevel3or4andstillunabletoobtainISO9000certificationNote:neitherISOnorCMMprescribeanyABSOLUTElevelofquality…buttheimprovementsinprocessmanagementarebelievedtohaveabeneficialeffectonqualitySQA:WhatisSQA?SQAistheprocessofassuringpeoplethateveryefforthasbeenmadetoensurethatsoftwareproductshavethedesiredlevelofreliability,maintainability,usability,andsalability.SQA是一種種執(zhí)行軟體評(píng)評(píng)估與衡量的的活動(dòng)(BakerandFisher)Setofsystematicactivitiesprovidingevidenceoftheabilityofthesoftwareprocesstoproduceasoftwareproductthatisfittouse(G.SchulmeyerandJ.McManus,SoftwareQualityHandbook,PrenticeHall,1998.)SoftwareQualityAssuranceHowdoyouassurethequalityofyoursoftware?GoodprocessesGooddocumentationandartifactsAccountabilityLearnandimproveTheObjectivesofSQAMonitoringprocessesandproductsthroughoutthesoftwaredevelopmentlifecycletoensurethequalityofthedeliveredproduct(s)MonitoringtheprocessesProvidesmanagementwithobjective(客客觀的)feedbackregardingprocesscompliance(承諾)toapprovedplans,procedures,standards,andanalysesMonitoringtheproductsFocusonthequalityofproductwithineachphaseoftheSDLCe.g.,requirements,testplan,architecture,etc.Objective:identifyandremovedefectsthroughoutthelifecycle,asearlyaspossibleSQA:AnSQAProgramMinimizingnumberofdefectsindelivereds/wCreatingmechanismsforcontrollingsoftwaredevelopmentandmaintenancesothatcostsandschedulescanbemetMakingcertainthatthedeliveredproductcanbeusedinitsintendedmarketplaceImprovingthequalityoffutureproductsSoftwaredefectsMistakesmadeatanypointinthesoftwareprocessRequirements,design,coding,maintenanceConsequencesInconvenience,lossofservice,financialloss,equipmentdamage,injury,deathThepercentageofdefectsfoundbyvariousmethodsPersonalcheckingofdesigndocumentsInformalgroupdesignreviewsFormaldesignspecificationsFormalcodeinspectionsModelingorprototypingPersonaldesk-checkingofcodeUnittesting(singleroutines)Functiontesting(relatedroutines)IntegrationtestingFieldtesting35%40%55%60%65%40%25%35%45%50%Thetruthofdefects1.Thelaterinthelifecyclethatanerrorisdetectedthemoreexpensiveitistorepair.2.Errorsremainlatentandarenotdetecteduntilwellafterthestageatwhichtheyaremade.54%oferrorsdetectedaftercodingandunittesting.45%oftheseerrorswererequirementsanddesignerrors.3.Therearenumerousrequirementserrors.Estimatesindicatethat56%ofallerrorsareerrorsduringtherequirementsstage.4.Requirementserrorsaretypicallynon-clerical.RelativeCosttoRepairbasedonwhenitwasfoundRequirements-1timeDesign-3-6timesCode-10timesUnittest-15-40timesSystemtest-30-70timesFieldoperation-40-1000timesWhenshouldqualityassurancebedone?AteverystageinthesoftwareprocessTheProcessofSQA定義品質(zhì)需需求制定SQA計(jì)畫(huà)需求評(píng)估設(shè)計(jì)評(píng)估測(cè)試評(píng)估需求分析設(shè)計(jì)測(cè)試評(píng)估客戶滿滿意需求程程度measurementfeedbackfeedback功能與完整整性系統(tǒng)完整性性與一致性性執(zhí)行效率與與正確性SQAPlanningIEEEStd730-2002StandardforSoftwareQualityAssurancePlans12pagesIEEEGuideforSoftwareQualityAssurancePlanningdraftP730.287pagesSQAPlanningIEEESQAPPurpose(Section1oftheSQAP)Referencedocuments(Section2oftheSQAP)Management(Section3oftheSQAP)Documentation(Section4oftheSQAP)Standards,practices,conventions,andmetrics(Section5oftheSQAP)Reviewsandaudits(Section6oftheSQAP)Test(Section7oftheSQAP)Problemreportingandcorrectiveaction(Section8oftheSQAP)Tools,techniques,andmethodologies(Section9oftheSQAP)Codecontrol(Section10oftheSQAP)Mediacontrol(Section11oftheSQAP)Suppliercontrol(Section12oftheSQAP)Recordscollection,maintenance,andretention(Section13oftheSQAP)Training(Section14oftheSQAP)Riskmanagement(Section15oftheSQAP)ContentsofSQAPlan(sect1&2)PurposelistsoftwarecoveredstateportionofsoftwarelifecyclecoveredReferenceDocumentscompletelistofdocumentsreferencedelsewhereSect3-Managementorganization-depictstructureoforg.responsibilitiestaskstaskstobeperformedrelationshipbetweentasksandcheckpointssequenceoftasksresponsibilitiesofeachorganizationalunitSect4-DocumentationidentifyrequireddocumentsstatehowdocumentswillbeevaluatedminimumdocumentsSRS-SoftwareRequirementsSpecificationSDD-SoftwareDesignDescriptionSVVP–S.VerificationandValidationPlanSVVR-S.VerificationandValidationReportUserdocumentation-manual,guideSCMP–S.ConfigurationManagementPlanSect5-Standards,Practices,ConventionsandMetricsIdentifyS,P,C,andMtobeappliedHowcomplianceistobemonitoredandassuredMinimumdocumentationstandards,logicstructurestandards,codingstandards,testingstandardsselectedsqaproductandprocessmetricse,g,branch,decisionpointsSect6-ReviewsandAuditspurposedefinewhatreviews/auditswillbedonehowtheywillbeaccomplishedwhatfurtheractionsarerequiredMinimumSoftwareRequirementsReviewsPreliminaryDesignReviewevaluatetechnicaladequacyoftop-leveldesignMinSetofReviews/Audits(cont)CriticalDesignReviewacceptabilityofdetaileddesignsSoftwareVerificationandValidationPlanReviewadequacyofplannedverificationandvalidationFunctionalAuditallrequirementsinSRShavebeenmetPhysicalAuditsoftwareanddocumentsareconsistentandreadyIn-ProcessAuditManagerialReviewsSect7-TestAllteststhatarenotincludedinSVVPSect8-ProblemReportingPracticesandProceduresforreporting,tracking,andresolvingproblemsOrganizationalresponsibilitiesSect9-Tools,TechniquesandMethodologiesidentifythespecialsoftwaretools,techniquesandmethodologiespurposedescribeuseProcessAssessmentUseofstandardsandprocessmodelshasapositiveimpactonthequalityofthesoftwareproductDisciplined,controlleddevelopmentprocessExamplesinclude:ISO9001CMMCMUSEI,5levelsSPICE(ISO/IEC15504)SoftwareProcessImprovement&CapabilitydEterminationDevelopingastandardforsoftwareprocessassessmentISOjointcommittee,Europe,AustraliaIEEE1074,IEEE12207ProductAssessmentReviews,inspections,walkthroughsofPlans,reports,models,standardsProjectmanagement,qualityassurance,training,testplan(s)Requirements,analysis,architecture,detaileddesignmodel,testcasesIssueorproblemreportsMetricreportsTraceabilityreportsDocumentation,codingstandards…SoftwareReviewsTheymayincludemanagerialreviews,acquirer-supplierreviews,technicalreviews,inspections,walkthroughs,andaudits.Inspection:Aformalevaluationtechniqueinwhichanartifact(e.g.,softwarerequirements,design,orcode)isexaminedindetailbyapersonorgroupotherthantheoriginatordetectfaults,violationsofdevelopmentstandards,andotherproblems.reviewmembersarepeers(equals)ofthedesignerorprogrammer.dataiscollectedduringinspectionsforlateranalysisandtoassistinfutureinspections.ProblemReporting,Tracking,andResolvingDescribethepracticesandprocedurestobefollowedforreporting,tracking,andresolvingproblemsWhocanreportaproblem?Howisitreported?Howisittracked?Whodeterminesifitisaproblemthatgoingtoberesolved?Howisitassignedforresolution?Howdoesthepersonindicateithasbeencorrected?Whoreviewsittodetermineifitcanbeclosed?Problemscanbeproductorprocessrelatede.g.incorrectrequirement,incompleteclassdefinition,codedefect,ambiguousdescriptioninuserdocumentation,processtoreviewdetaileddesignisnotclearlydefined,etc.SQA:6SIGMAQUALITYSigma=“StandardDeviation””Typicalsoftwarehas3to4defectsperKLOC6Sigma=3to4defectspermillionlinesofcodeAveragecompaniesaccept99.98%quality=4S6Sigma=99.9999998%levelofqualitySQA:6SIGMAQUALITYQualityImprovements:3Sigmato4Sigma=10fold4Sigmato5Ssigma=30fold5Sigmato6Sigma=70foldBest-in-Classcompaniesinsomeindustriesoperateat6Sigma(Airline=6.4Sigma;2.5M:1)Softwareorganizations