《软体品质管理36228.pptx》由会员分享，可在线阅读，更多相关《软体品质管理36228.pptx（59页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、軟體品質管理IntroductionWhat is software quality?How can it be measured?How can it be measured before the software is delivered?Some key quality factorsSome measurable indicators of software qualityIntroductionThink of an everyday objecte.g.a chairHow would you measure its“quality”?construction quality?(e
2、.g.strength of the joints,)aesthetic value?(e.g.elegance,)fit for purpose?(fortable,)All quality measures are relativethere is no absolute scalewe can say A is better than B but it is usually hard to say how much betterFor software:construction quality(建造的品質)?software is not manufacturedaesthetic va
3、lue(美學上的價值)?but most of the software is invisibleaesthetic value matters for the user interface,but is only a marginal concernfit for purpose?Need to understand the purpose 軟體品質因素Measuring QualityThe Quality Concepts(abstract notions ofquality properties)Measurable Quantities(define some metrics)Cou
4、nts taken fromDesign Representations(realization of the metrics)usabilityminutes taken for some user task?time taken to learn how to use?complexitycount procedure calls?information flow between modules?reliabilityrun it and count crashes per hour?mean time to failure?examples.Four Key Quality Concep
5、tsReliabilitydesigner must be able to predict how the system will behave:completeness-does it do everything it is supposed to do?(e.g.handle all possible inputs)consistency-does it always behave as expected?(e.g.repeatability)robustness-does it behave well under abnormal conditions?(e.g.resource fai
6、lure)EfficiencyUse of resources such as processor time,memory,network bandwidthThis is less important than reliability in most casesMaintainabilityHow easy will it be to modify in the future?perfective,adaptive,correctiveUsabilityHow easy is it to use?McCalls Quality Factorsoperationrevisiontransiti
7、onCorrectness reliability usability integrity efficiencyMaintainabilityFlexibilityTestabilityPortabilityReusabilityInteroperabilityGeneral utilityportabilityAs-is utilityMaintainabilityreliabilityefficiencyusabilitytestabilityunderstandabilitymodifiabilitydevice-independenceself-containednessaccurac
8、ycompletenessrobustness/integrityconsistencyaccountabilitydevice efficiencyaccessibilitycommunicativenessself-descriptivenessstructurednessconcisenesslegibilityaugmentabilitySource:See Blum,1992,p176Product operationusabilityProduct revisionProduct transitionintegritymaintainabilitytestabilityreusab
9、ilityportabilityinteroperabilityoperabilitytrainingI/O volumeAccess controlAccess auditStorage efficiencyconsistencyinstrumentationexpandabilitygeneralitySelf-descriptivenessmodularitymachine independences/w system monalityefficiencycorrectnessreliabilityflexibilitycommunicatativenessI/O rateexecuti
10、on efficiencySource:See van Vliet 2000,pp111-3traceabilitycompletenessaccuracyerror tolerancesimplicityconcisenessdata commonalityMeasurable Predictors of QualitySimplicitythe design meets its objectives and has no extra embellishmentscan be measured by looking for its converse,complexity:control fl
11、ow complexity(number of paths through the program)information flow complexity(number of data items shared)name space complexity(number of different identifiers and operators)Modularitydifferent concerns within the design have been separatedcan be measured by looking at:cohesion(how well components o
12、f a module go together)coupling(how much different modules have to communicate)Quality and how to achieve itProduct quality always an issue After WWII,industry in the US and elsewhere has substantially improved quality via extensive testing and statistical quality controlJapanese industry has follow
13、ed a different concept,a.k.a.total quality initiative(Deming,Juran),where quality control is an intrinsic aspect of the production process,not a post-production activityIn other words,you should design the quality product and build it right,rather than build it and then make sure it has good quality
14、SEI and the Capability Maturity ModelSoftware quality improvement has led to the establishment of the Software Engineering Institute at Carnegie-Mellon UniversityCapability Maturity Model(CMM)a framework to assess the maturity level of an organizations software development and management processesCM
15、M consists of five levels of maturity as measured by a set of guidelines called the key process areasHigher levels increase competitiveness,reduce riskLevels are monotonic:level n includes all the characteristics of all the levels below,n-1,n-2,etc.Capability Maturity ModelLevel5OPTIMIZEDLevel4MANAG
16、EDLevel3DEFINEDLevel2REPEATABLERISKCOMPETITIVENESSLevel1INITIALLevel 1Initialend Software development follows no prescribed processYou dont know where you stand,or when will you finish,or what you will get when you finishYou have to be happy with what you get at the Level 2RepeatableProject manageme
17、nt processes and practices are established,in order to track project costs,schedules,and functionalityStill,you just passively track whats going on and dont know exactly what you should doLevel 3DefinedA standard system development process(sometimes called a“methodology”)purchased or developed,and i
18、ntegrated throughout the IT unit of the organizationwhich means that there is a prescribed sequence of steps to follow,plus you monitor the outcomesLevel 4ManagedMeasurable goals for quality and productivity are establishedConstant monitoring gives real-time data about the status of the process and
19、productProcess parameters adjusted in order to obtain desired outcomes(that is management,after all)Level 5OptimizingThe standardized system development process continuously monitored and improved,based on measures and data analysis established in Level 4Changes can be made to process parameters But
20、 we can make change in the process itself(e.g.,choose different sequence,change priorities,even introduce additional steps or delete some that do not contribute to the process/product quality)CMM certification processCMM assessment performed by qualified personnel from SEI,through interviews and ana
21、lysis of procedures and documents used in the organizationLevels can be awarded to organizations or specific projects/project groups within an organization.Each level has its own questionnaire,with a number of mandatory and optional questionsIn order to qualify for a specific level,Yes answers must
22、be present in each group(though minimum percentages are different)CMM certification processEach questionnaire focuses on a number of the so-called Key Process Areas(KPAs)Each level of CMM scale has an associated set of Key Process Areas(KPAs)To qualify for a specific level,issues related to KPAs for
23、 that level must be addressedTo progress from one level to the next one up,improvements in appropriate KPAs have to be madeLevels are monotonic makes no sense to concentrate on KPAs for,say,level 4,if the development process is still at level 1 or 2關鍵流程領域（Key Process Area,KPA)階層特徵關鍵流程領域（KPA）品質方法5最佳層
24、（Optimizing）持續流程改善最佳化的管理 缺陷預防技術變更管理流程變更管理 從流程變異最小化 4管理層（Managed）產品與流程品質評量定量化的管理定量流程管理軟體品質管理從預防問題發生 3定義層（Defined）流程定義與制度化定性化的管理組織流程特徵組織流程定義同等審查訓練課程整合軟體管理軟體產工程群體間協調及早發現問題與矯正2重覆層（Repeatable）專案管理使用經驗的管理 軟體專案追蹤軟體專案計畫軟體副合約管理軟體品質保證軟體構型管理需求管理專案最終的測試1初始層（Initial）個人主義，毫無章法的管理Some problems with CMM(at least in
25、itially)Focuses on project/process management,not product developmentIgnores use of certain advanced technologiesDid not incorporate risk analysis as a KPADid not define its domain of applicabilityBut things have evolved/diversified:Models that the SEI is currently involved in developing,expanding,o
26、r maintaining:Capability Maturity Model Integration(CMMISM)SW-CMM Capability Maturity Model for Software P-CMM People Capability Maturity Model SA-CMM Software Acquisition Capability Maturity Model SE-CMM Systems Engineering Capability Maturity Model IPD-CMM Integrated Product Development Capability
27、 Maturity ModelISO9000ISO9000 series of quality standards,some of which are related to software and IS developmentISO principles:Say what you will doDo as you have saidProve that you did soNOTE:this is a very simplified view the certification process and the documentation required to go through it a
28、re quite extensive and detailedISO certification is performed through national standards organizationsCMM vs.ISOPartial overlap,but doubts remainIt seems possible that an organization can be certified for ISO9000 and still be at level 1 of the CMM scale,or be at level 3 or 4 and still unable to obta
29、in ISO9000 certification Note:neither ISO nor CMM prescribe any ABSOLUTE level of quality but the improvements in process management are believed to have a beneficial effect on qualitySQA:What is SQA?SQA is the process of assuring people that every effort has been made to ensure that software produc
30、ts have the desired level of reliability,maintainability,usability,and salability.SQA是一種執行軟體評估與衡量的活動(Baker and Fisher)Set of systematic activities providing evidence of the ability of the software process to produce a software product that is fit to use(G.Schulmeyer and J.McManus,Software Quality Ha
31、ndbook,Prentice Hall,1998.)Software Quality AssuranceHow do you assure the quality of your software?Good processesGood documentation and artifactsAccountabilityLearn and improveThe Objectives of SQAMonitoring processes and products throughout the software development lifecycle to ensure the quality
32、of the delivered product(s)Monitoring the processesProvides management with objective(客觀的)feedback regarding process compliance(承諾)to approved plans,procedures,standards,and analysesMonitoring the productsFocus on the quality of product within each phase of the SDLC e.g.,requirements,test plan,archi
33、tecture,etc.Objective:identify and remove defects throughout the lifecycle,as early as possibleSQA:An SQA ProgramMinimizing number of defects in delivered s/wCreating mechanisms for controlling software development and maintenance so that costs and schedules can be metMaking certain that the deliver
34、ed product can be used in its intended marketplaceImproving the quality of future productsSoftware defectsMistakes made at any point in the software processRequirements,design,coding,maintenanceConsequencesInconvenience,loss of service,financial loss,equipment damage,injury,deathThe percentage of de
35、fects found by various methodsPersonal checking of design documentsInformal group design reviewsFormal design specificationsFormal code inspectionsModeling or prototypingPersonal desk-checking of codeUnit testing(single routines)Function testing(related routines)Integration testingField testing35%40
36、%55%60%65%40%25%35%45%50%The truth of defects1.The later in the life cycle that an error is detected the more expensive it is to repair.2.Errors remain latent and are not detected until well after the stage at which they are made.54%of errors detected after coding and unit testing.45%of these errors
37、 were requirements and design errors.3.There are numerous requirements errors.Estimates indicate that 56%of all errors are errors during the requirements stage.4.Requirements errors are typically non-clerical.Relative Cost to Repair based on when it was foundRequirements-1 timeDesign-3-6 timesCode-1
38、0 timesUnit test-15-40 timesSystem test-30-70 timesField operation-40-1000 timesWhen should quality assurance be done?At every stage in the software processThe Process of SQA定義品質需求制定SQA計畫需求評估設計評估測試評估需求分析設計測試評估客戶滿意需求程度measurementfeedbackfeedback功能與完整性系統完整性與一致性執行效率與正確性SQA PlanningIEEE Std 730-2002Stan
39、dard for Software Quality Assurance Plans12 pagesIEEE Guide for Software Quality Assurance Planningdraft P730.287 pagesSQA PlanningIEEE SQAP Purpose(Section 1 of the SQAP)Reference documents(Section 2 of the SQAP)Management(Section 3 of the SQAP)Documentation(Section 4 of the SQAP)Standards,practice
40、s,conventions,and metrics(Section 5 of the SQAP)Reviews and audits(Section 6 of the SQAP)Test(Section 7 of the SQAP)Problem reporting and corrective action(Section 8 of the SQAP)Tools,techniques,and methodologies(Section 9 of the SQAP)Code control(Section 10 of the SQAP)Media control(Section 11 of t
41、he SQAP)Supplier control(Section 12 of the SQAP)Records collection,maintenance,and retention(Section 13 of the SQAP)Training(Section 14 of the SQAP)Risk management(Section 15 of the SQAP)Contents of SQA Plan(sect 1&2)Purposelist software coveredstate portion of software life cycle coveredReference D
42、ocumentscomplete list of documents referenced elsewhereSect 3-Managementorganization-depict structure of org.responsibilitiestaskstasks to be performedrelationship between tasks and checkpointssequence of tasksresponsibilitiesof each organizational unitSect 4-Documentationidentify required documents
43、state how documents will be evaluatedminimum documentsSRS-Software Requirements SpecificationSDD-Software Design DescriptionSVVP S.Verification and Validation PlanSVVR-S.Verification and Validation ReportUser documentation-manual,guideSCMP S.Configuration Management PlanSect 5-Standards,Practices,Co
44、nventions and MetricsIdentify S,P,C,and M to be appliedHow compliance is to be monitored and assuredMinimumdocumentation standards,logic structure standards,coding standards,testing standardsselected sqa product and process metricse,g,branch,decision pointsSect 6-Reviews and Auditspurposedefine what
45、 reviews/audits will be donehow they will be accomplishedwhat further actions are requiredMinimumSoftware Requirements ReviewsPreliminary Design Reviewevaluate technical adequacy of top-level designMin Set of Reviews/Audits(cont)Critical Design Reviewacceptability of detailed designsSoftware Verific
46、ation and Validation Plan Reviewadequacy of planned verification and validationFunctional Auditall requirements in SRS have been metPhysical Auditsoftware and documents are consistent and readyIn-Process AuditManagerial ReviewsSect 7-TestAll tests that are not included in SVVPSect 8-Problem Reportin
47、gPractices and Procedures for reporting,tracking,and resolving problemsOrganizational responsibilitiesSect 9-Tools,Techniques and Methodologiesidentify the special software tools,techniques and methodologiespurposedescribe useProcess AssessmentUse of standards and process models has a positive impac
48、t on the quality of the software productDisciplined,controlled development processExamples include:ISO 9001CMMCMU SEI,5 levelsSPICE(ISO/IEC 15504)Software Process Improvement&Capability dEtermination Developing a standard for software process assessmentISO joint committee,Europe,AustraliaIEEE 1074,I
49、EEE 12207 Product AssessmentReviews,inspections,walkthroughs of Plans,reports,models,standardsProject management,quality assurance,training,test plan(s)Requirements,analysis,architecture,detailed design model,test cases Issue or problem reportsMetric reportsTraceability reportsDocumentation,coding s
50、tandardsSoftware ReviewsThey may include managerial reviews,acquirer-supplier reviews,technical reviews,inspections,walkthroughs,and audits.Inspection:A formal evaluation technique in which an artifact(e.g.,software requirements,design,or code)is examined in detail by a person or group other than th