搜索
2.1软件开发生命周期的度量活动2.2软件的项目度量2.3软件产品的规模度量2.4代码行度量方法2.5功能点分析法2.6面向对象软件的度量软件产品度量：主要用来描述软件产品的特征，用于产品评估和决策。产品度量包括软件规模大小、产品复杂度、设计特征、性能以及质量水平。本书主要讨论产品的质量度量，测量产品的各个质量指标并最终对产品整体质量做出合理的评估。软件项目度量：用来描述项目的特性和执行状态，如项目计划的有效性、项目资源使用效率、成本效益、项目风险、进度和生产力等。目的是评估项目开发过程的质量、预测项目进度、工作量等，辅助管理者进行质量控制和项目控制。软件过程度量：用于软件开发、维护过程的优化和改进，如开发过程中的缺陷移除效率、测试阶段中的缺陷到达模式以及缺陷修复过程的效率等。对于软件过程本身的度量，目的是形成适合软件组织应有的各种模型，作为对项目、产品的度量基础；以及对软件开发过程进行持续改进，提高软件生产力。软件开发生命周期中的测量活动1.规模度量(sizemeasurement)：以代码行数、功能点数、对象点或特征点等来衡量。软件规模度量是工作量度量、进度度量的基础，用于估算软件项目工作量、编制成本预算、策划项目进度的基础。2.复杂度度量(complexitymeasurement)：确定程序控制流或软件系统结构的复杂程度指标。复杂度度量用于估计或预测软件产品的可测试性、可靠性和可维护性，以便选择最优化、最可靠的程序设计方法，来确定测试策略、维护策略等。3.缺陷度量(defectmeasurement)：帮助确定产品缺陷分布的情况、缺陷变化的状态等，从而帮助分析修复缺陷所需的工作量、设计和编程中存在哪些弱点、预测产品发布时间、预测产品的遗留缺陷等。4.工作量度量(workloadmeasurement)：任务分解并结合人力资源水平来度量，合理地分配研发资源和人力，获得最高的效率比。工作量度量是在软件规模度量和生产率度量的基础上进行。5.进度度量(schedulemeasurement)：通过任务分解、工作量度量、有效资源分配等做出计划，然后将实际结果和计划值进行对比来度量。6.风险度量(riskmeasurement)：一般通过两个参数“风险发生的概率”和“风险发生后所带来的损失”来评估风险。7.其他的项目度量，如需求稳定性或需求稳定因子（RSI,RequirementStabilityIndex）、资源利用效率(ResourceUtilization)、文档复审水平（Reviewlevel）、问题解决能力（Issue-resolvingability）、代码动态增长等。1.德尔菲法◦德尔菲法(Delphitechnique)是一种专家评估技术，适用于在没有或没有足够的历史数据情况下，来评定软件采用不同的技术、新技术所带来的差异，但专家的水平及对项目的理解程度是工作中的关键点。2.COCOMO模型◦建造成本模型(COCOMO：constructivecostmodel)是一种精确、易于使用的基于模型的成本估算方法。它有分为基本COCOMO模型，中间COCOMO模型和详细COCOMO模型3.代码行度量方法4.功能点分析法5.面向对象软件的对象点方法1.每个类的加权方法(WMC-weightedmethodsperclass)假定对类C定义了复杂度为c1，c2，…cn的n个方法，所选择的特定的复杂性度量应该规范化，使得对某方法的名义上的复杂性取值1.0。WMC=Σci2.继承树的深度(DIT-DepthofInheritanceTree)3.子女的数量(NOC-NumberofimmediateChildrenofaclass)4.对象类之间的耦合(CBO-CouplingBetweenObjects)一个类的CBO是它与别的类有耦合关系的类的数目，属于系统层次级的度量。CBO值越小，表明该类影响到的类越少，独立性越强，修改所涉及的类也越少，维护的代价越小。5.对类的响应(RFC-ResponseforaClass):类的RFC越大，该类的测试和调试将越复杂，复杂度越大6.方法中缺少内聚(LCOM-LackofCohesioninMethods):Lorenz和Kidd建议的度量•类大小（CS）：可通过被封装在类中的操作的总数和属性的数量来测度。•由子类覆写的操作数量（NOO）：若NOO大，则导致了弱的类层次和可能难于测试和修改的OO软件。•由子类加入的操作的数量（NOA）：当NOA值增大时，子类漂离超类隐含的抽象。MOOD度量套件•继承因子（MIF）•耦合因子（CF）•多态因子（PF）3.1基于时间的缺陷到达模式-S曲线模型3.2PTR累积模型微软公司的缺陷到达模式缺陷数量05101520253035403-13-83-153-223-294-5缺陷达到模式的理想趋势图在测试阶段初期，缺陷率增长很快。在达到峰值后，就随时间以较慢的速率下降，降低到最低点——零点不同的缺陷统计方法：1）一定时间内的总缺陷数；2）一定时间内的严重程度前两个等级的缺陷数之和；3）一定时间内的新引进的缺陷及回归的缺陷之和；4）一定时间内的新引进的缺陷及回归的缺陷，而且严重程度在前两个等级的缺陷之和。PTR累积模型4.1软件复杂性的度量4.2软件缺陷度量4.3顾客满意度度量语法构造方法基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。语法构造方法可以揭示程序中单独的语法构造和缺陷率之间的关系：缺陷率=0.15+0.23DOWHILE+0.22SELECT+0.07IF-THEN-ELSE结构度量方法Henry给出的复杂性定义：Cp=(扇入×扇出)2其中：扇入–调用外部模块的模块数扇出–被外部模块调用的次数缺陷密度——软件缺陷在规模上的分布如：每KLOC或每个功能点（或类似功能点的度量——对象点、数据点、特征点等）的缺陷数缺陷率——缺陷在时间上的分布如：从应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来。整体缺陷清除率在软件开发过程中发现的被清除的所有缺陷数/发现的总缺陷数阶段性缺陷清除率％产品中潜伏的缺陷数开发阶段清除的缺陷数100顾客满意度要素顾客满意度要素的内容技术解决方案质量、可靠性、有效性、易用性、价格、安装、新技术支持与维护灵活性、易达性、产品知识市场营销解决方案、接触点、信息管理购买流程、请求手续、保证期限、注意事项交付准时、准确、交付后过程企业形象技术领导、财务稳定性、执行印象软件组织的顾客满意度要素及其内容顾客满意度要素顾客满意度度量内容软件产品功能性、可靠性、易用性、效率性、可维护性、可移植性开发文档文档的构成、质量、外观、图表以及索引、用语项目进度以及交期交期的根据、进度迟延情况下的应对、进展报告技术水平项目组的技术水平、项目组的提案能力、项目组的问题解决能力沟通能力事件记录、格式确认、问题解答运用维护支持、问题发生时的应对速度、问题解决能力软件项目的顾客满意度要素及其内容5.1软件需求过程的质量度量5.2软件过程生产率的度量5.3测试阶段的过程质量度量5.4维护阶段的过程质量度量需求一致性度量Q1＝nui/nrnui是所有复审者都有相同解释的需求数目nr是需求说明书中需求的个数，包含功能和非功能需求需求完整性度量Q2＝nu/(ni×ns)nu是唯一功能需求的数目ni是由需求规格定义或包含的输入的个数ns是被表示的状态的个数。需求确认程度度量Q3＝nc/(nc＋nnv)nc是已经确认为正确的需求的个数nnv是尚未被确认的需求的个数需求稳定性度量需求稳定性度量是通过需求稳定因子RSI来表示：RSI=（所有确定的需求数-累计的需求变化请求数）/所有确定的需求数所有确定的需求数=初始需求请求列表数+接受的需求变化请求数软件生产率的三维关系度量量代码行功能点类测试用例度量单位人时（man-hour）人日（man-day）人月（man-month）人年（man-year）测试用例的深度（TCD,TestCaseDepth）-每KLOC的测试用例数-每个功能点/对象点的测试用例数测试用例的有效性-每100或1000个测试用例所发现的缺陷数测试用例的质量（TCQ,TestCaseQuality）-测试用例发现的缺陷数量/总的缺陷数量测试执行的效率和质量-每个人日所执行的测试用例数-每个人日所发现的缺陷数-每修改的KLOC所运行的测试用例数缺陷报告的质量-报告的质量不高的缺陷数/报告的总缺陷数质量不高的缺陷包含：1）状态为“需要补充信息”的缺陷2）状态为“不是缺陷”的缺陷基于需求的测试覆盖-已执行的测试覆盖＝Tx／Rft-成功的测试覆盖＝Ts／RftTx表示已执行的测试过程数或测试用例数Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数Rft是测试需求的总数基于代码的测试覆盖-已执行的测试覆盖＝Tc／TncTc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数Tnc（Totalnumberofitemsinthecode）是代码中的项目总数平均失效时间MTTF(meantimetofailure)基于时间缺陷(或用户问题数)的到达率软件成熟度指标(SMI)质量度量的统计方法包含以下步骤：1)收集和分类软件缺陷信息；2)找出导致每个缺陷的原因(例如，不符合规格说明书、设计错误、代码错误、数据处理不对、对客户需求误解、违背标准、界面不友好等)；3)使用Pareto规则(80％缺陷主要是由20％的主要因素造成的，20％缺陷是由另外80％的次要因素造成的)，要将这20％的主要因素分离出来。4)一旦标出少数的主要因素，就比较容易纠正引起缺陷的问题。错误的根本原因来源于下面几个方面：说明不完整或说明错误(IES)与客户交流不够所产生的误解(MCC)故意与说明偏离(IDS)违反编程标准(VPS)数据表示有错(EDR)模块接口不一致(IMI)设计逻辑有错(EDL)不完整或错误的测试(IET)不准确或不完整的文档(IID)将设计翻译成程序设计语言中的错误(PLT)不清晰或不一致的人机界面(HCI)杂项(MIS)质量度量的统计数据收集总计(Ei)严重(Si)一般(Mi)微小(Ti)错误数量百分比数量百分比数量百分比数量百分比IES29622.3%5528.2%9518.6%14623.4%MCC20415.3%189.2%8717.0%9915.9%IDS644.8%21.0%311%315.0%VPS342.6%10.5%193.7%142.2%EDR18213.7%3819.5%9017.6%548.7%IMI822%147.2%214.1%477.5%EDL644.8%2010.3%173.3%274.3%IET14010.5%178.7%5110.0%7211.6%IID544.1%31.5%285.5%233.7%PLT875%2211.3%265.1%393%HCI423.2%42.1%275.3%111.8%MIS811%10.5%203.9%609.6%总计1330100%195100%512100%623100%PMDLicense:OpenSourceCurrentversion:5.0.2(released03.02.2013)URL:”PMDisusedfordetectingbadpracticesincode,whichisintendeddecreasethenumberof