项目管理上课

1第3章 软件质量度量和配置管理2内容提要3.1概述 3.1.1度量 3.1.2软件度量 3.1.3软件度量的作用 3.2软件质量度量 3.2.1软件质量和软件质量要素 3.2.2影响软件质量的因素 3.2.3质量保证模型 3.2.4缺陷排除效率 3内容提要3.3软件过程度量 3.3.1软件过程度量概念 3.3.2软件过程度量常见问题 3.3.3基于目标的软件过程度量方法 3.4软件配置管理 3.4.1软件配置管理的目标 3.4.2软件配置管理角色职责 3.4.3软件配置管理过程描述 3.4.4软件配置管理的关键活动 3.4.5常用的软件配置管理工具 3.5小结 43.1概述牛奶质量？如何去度量软件的质量，是一个很难回答的问题，到底通过什么标准去承诺这个软件的质量好呢？软件质量度量长度测量：米温度测量：摄氏度5软件质量是对明确陈述的功能和性能需求，明确记录的开发标准及对所有专业化开发应具备的隐性特征的符合度。它强调了以下三重意思：1.软件的需求是质量的基础，不符合需求的就是没有质量。2.软件过程必须遵循一些开发标准和行业标准。3.软件必须满足隐含需求。符合这三点的，我们就可以说是有质量的。6软件度量研究主要分为两个阵营：一部分认为软件可以度量，一部分认为软件无法通过度量分析。无论如何，研究主流是关心软件的质量和认为软件需要定量化度量。在软件开发中，软件质量度量的根本目的是为了管理的需要。利用度量来改进软件过程。人们是无法管理不能度量的事物。但应认识到软件度量的成果是非常初步的，还需要大量工作才可能真正地做到实用化，但它的实用化成就将对软件的高质量和高速发展有不可估量的影响。73.1.1度量Measure：度量（名词），是根据一定的规则赋予软件过程或产品属性的数值或类别[ISO/IEC14598-1]。数值是对软件产品、软件过程的特征的量化计数的结果，类别是特征的定性表示。Measure：度量（动词），按照度量过程中的过程定义，对软件过程或软件产品实施度量，表示实际的动作[ISO/IEC14598-1]。Measurement：测度，是按照一定的尺度用度量（名词）给软件实体属性赋值的过程[ISO/IEC14598-1]。它强调对软件实体属性进行量化的过程性，是提取软件过程或软件产品属性的度量（名词）的过程。它所蕴涵的内容是度量的过程。Metric：度量，是已定义的测量方法和测量尺度[ISO/IEC14598-1]。Metric概指软件环境中任何一个软件对象的属性的量化表现。Indicator：指示器，或称为指标。是用于评价或预测其他度量的度量。[ISO/IEC14598-1]。83.1.2软件度量软件度量或者说软件工程度量领域是一个在过去30多年研究非常活跃的软件工程领域。软件度量（SoftwareMeasurement）和软件量度（SoftwareMetrics）一样非常有名。但目前学界还没有明确这两个术语的区别。参照测量理论的相关术语，我们采用软件度量（SoftwareMeasurement）。度量是客观对象到数字对象的同态映射。9软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。103.1.3软件度量的作用可度量性是学科是否高度成熟的一大标志，度量使软件开发逐渐趋向专业、标准和科学。美国卡内基·梅隆大学(CarnegieMellonUniversity，CMU)软件工程研究所在《软件度量指南》（SoftwareMeasurementGuidebook）中认为，软件度量在软件工程中的作用有三：通过软件度量增加理解；通过软件度量管理软件项目，主要是计划和估算、跟踪和确认；通过软件度量指导软件过程改善，主要是理解、评估和包装。软件度量对于不同的实施对象，具有不同的效用。11软件度量的作用角色度量效果软件公司改善产品质量；改善产品交付；提高生产能力；降低生产成本；建立项目估算的基线；了解使用新的软件工程方法和工具的效果和效率；提高顾客满意度；创造更多利润；构筑员工自豪感项目经理分析产品的错误和缺陷；评估现状；建立估算的基础；确定产品的复杂度；建立基线；从实际上确定最佳实践；软件开发人员可建立更加明确的作业目标；可作为具体作业中的判断标准；便于有效把握自身的软件开发项目；便于在具体作业中实施渐进性软件开发改善活动；12附：软件生命周期的度量活动软件产品度量：主要用来描述软件产品的特征，用于产品评估和决策。产品度量包括软件规模大小、产品复杂度、设计特征、性能以及质量水平。本书主要讨论产品的质量度量，测量产品的各个质量指标并最终对产品整体质量做出合理的评估。软件项目度量：用来描述项目的特性和执行状态，如项目计划的有效性、项目资源使用效率、成本效益、项目风险、进度和生产力等。目的是评估项目开发过程的质量、预测项目进度、工作量等，辅助管理者进行质量控制和项目控制。软件过程度量：用于软件开发、维护过程的优化和改进，如开发过程中的缺陷移除效率、测试阶段中的缺陷到达模式以及缺陷修复过程的效率等。对于软件过程本身的度量，目的是形成适合软件组织应有的各种模型，作为对项目、产品的度量基础；以及对软件开发过程进行持续改进，提高软件生产力。13软件生命周期的度量活动软件开发生命周期中的测量活动143.2软件质量度量3.2.1软件质量和软件质量要素对于软件质量，CMM的定义是：一个系统、组件或过程符合特定需求的程度；一个系统、组件或过程符合客户或用户的要求或期望的程度。153.2.2影响软件质量的因素软件业通过多年的实践，总结出软件质量是人、过程和技术的函数，即Q={M，P，T}。其中，Q表示软件质量，M表示人，P表示过程，T表示技术。16我们不能直接来测量软件的质量，我们只能通过软件的一些具体的质量特性来测量。给这些质量特性规定标准，于是就建立起来了具体的质量度量标准。质量度量的标准也可以叫做质量模型。173.2.3质量模型McCall模型Boehm模型FURPS模型ISO912618McCall模型（11个特性）19McCall模型正确性：一个程序满足她的需求规约和实现用户任务目标的程度。可靠性：一个程序满足所需的精确度、完成它的预期功能的程度效率：一个程序完成其功能所需的计算资源和代码的度量。完整性：对未授权人员访问软件或数据的可控制程度。可用性：学习、操作、准备输入和解释程序输出所需的工作量。可维护性：定位和修复程序中一个错误所需的工作量。灵活性：修改一个运行的程序所需的工作量。可测试性：测试一个程序以确保她完成所期望的功能所需的工作量。可移植性：把一个程序从一个硬件和或软件系统环境移植到另一个环境所需的工作量。可复用：性一个程序可以在另外一个应用程序中复用的程度互连性：连接一个系统和另一个系统所需的工作量。20Boehm模型Boehm模型着手于软件总体的功效，也就是说，对于一个软件系统而言，除了有用性以外，它的开发过程必定是一个时间，金钱和能量的消耗过程。考虑到系统交付时使用它的用户类型，Boehm模型从几个维来考虑软件的效用。总功效可以被分解成可移植性，有效性，可维护性。其中，有效性可以细分为可靠性，效率，运行工程。可维护性可以细分为测试性，可理解性，可修改性。系统功效可移植性有效性可靠性，效率，运行工程可维护性测试性，可理解性，可修改性21FURPS模型功能性（Functionality）：通过评价特征集和程序的能力、交付的函数的通用性和整体系统的安全性来评估。可用性（Usability）：通过考虑人的因素、整体美学、一致性和文档来评估。可靠性（Reliability）：通过度量错误的频率和严重程度、输出结果的准确度、平均失效间隔时间、从失效恢复的能力、程序的可预测性等来评估。性能（Performance）：通过测度处理速度、响应时间、资源消耗、吞吐量和效率来评估。支持度（Supportability）：包括扩展程序的能力可扩展性、可适应性和服务性这三个属性代表了一个更一般的概念—可维护性、以及可测试性、兼容度、可配置性组织和控制软件配置的元素的能力、一个系统可以被安装的容易程度、问题可以被局部化的容易程度。22ISO9126功能性：适合性、准确性、互操作性、依从性、安全性。可靠性：成熟性、容错性、可恢复性。可用性：可理解性、易学性、可操作性。效率：时间特性、资源特性。可维护性：可分析性、可改变性、稳定性、可测试性。可移植性：适应性、可安装性、一致性、可替换性。23总而言之，这些质量特性可划分为两类，可直接测试的和间接测试的。对于功能，性能等我们可直接测试；对易用性，可靠性等，需要我们通过一定得途径寻找一条准则，这也是目前测试的盲点，当然也是质量人员需要解决的问题。24软件质量度量指标一、软件产品质量度量二、软件过程质量度量25一.软件产品的质量度量软件复杂性的度量软件缺陷度量顾客满意度度量261软件复杂性的度量McCabe环形计算复杂度复杂度计算公式为：M=V(G)=e–n+2p其中：V(G)路径图的环形数目e=边的数目n=节点数目p=图中没有连接部分的数目271软件复杂性的度量语法构造方法基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。语法构造方法可以揭示程序中单独的语法构造和缺陷率之间的关系：缺陷率=0.15+0.23DOWHILE+0.22SELECT+0.07IF-THEN-ELSE281软件复杂性的度量结构度量方法Henry给出的复杂性定义：Cp=(扇入×扇出)2其中：扇入–调用外部模块的模块数扇出–被外部模块调用的次数Card/Glass给出的度量模型：Ct=St+Dt其中：St–结构（模块间)复杂性Dt–数据（模块内)复杂性292软件缺陷度量缺陷密度——软件缺陷在规模上的分布如：每KLOC或每个功能点（或类似功能点的度量——对象点、数据点、特征点等）的缺陷数缺陷率——缺陷在时间上的分布如：对应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来。缺陷清除率DRE：整体在软件开发过程中发现的所有缺陷数/发现的总缺陷数DRE=E/(E+D)缺陷清除率DRE：阶段性DRE=Ei/(Ei+Ei+1)30缺陷密度（率）度量缺陷率-软件大小通常千行源代码数（KLOC）功能点31例子：KLOCKLOC-物理行计数？指令语句计数？是否加数据定义？注解？首次发布与更新版本后当更新版本后：更改标记法LOC重新计数缺陷跟踪—使用更改标记法（changeflagging）32例子：功能点一个应用程序5个主要成分的加权总和外部输入数（例如，事务类型）3~6外部输出数（例如，报告类型）4~7逻辑内部文件数7~15外部接口文件数5~10外部查询数（支持的联机查询种类）3~633例子：功能点第一步Wij是5个成分按复杂性级别的加权因子，Xij是应用程序中每种成分的数目34例子：功能点14个特征：数据通信分布式功能性能频繁使用的配置事务率联机数据项、最终用户效率联机更新复杂处理可重用性易安装性易操作性多站点易更改性35例子：功能点第二步将这些特征分值（从0到5）按下列公式加起来，形成价值调整因子（valueadjustmentfactor,VAF）其中Ci是通用系统特征i的分值36例子：功能点最后，得到了功能点数FP=FC*VAF已成为一个关键的生产率测度主要应用于应用软件而非系统软件37缺陷排除效率DRE缺陷排除有效性（DRE）定义：DRE=开发阶段排除的缺陷数/产品中潜伏的缺陷数DRE=E/(E+D)分母估计：在现阶段排出的缺陷数+以后发现的缺陷数该度量值越高，开发过程越有效383顾客满意度度量顾客满意度要素顾客满意度要素的内容技术解决方案质量、可靠性、有效性、易用性、价格、安装、新技术支持与维护灵活性、易达性、产品知识市场营销解决方案、接触点、信息管理购买流程、请求手续、保证期限、注意事项交付准时、准确、交付后过程企业形象技术领导、财务稳定性、执行印象软件组织的顾客满意度要素及其内容393顾客满意度度量顾客满意度要素顾客满意度度量内容软件产品功能性、可靠性、易用性、效率性、可维护性、可移植性开发文档文档的构成、质量、外观、图表以及索引、用语项目进度以及交期交期的根据、进度迟延情况下的应对、进展报告技术水平项目组的技术水平、项目组的提案能力、项目组的问题解决能力沟通能力事件记录、格式确认、问题解答运用维护支持、问题发生时的应对速度、问题解决能力软件项目的顾客满意度要素及其内容403.顾客满意度度量5级尺度非常满意满意一般不满意非常不满意413.顾客满意度度量5级尺度基础上，构造几种度量完全满意顾客百分数满意顾客百分数（满意和完全满意）不满意顾客百分数（不满意和完全不满意）非满意顾客百分数（一般、不满意和完全不满意）通常使用第二个度量，某些时候为降低非满意百分数，也使用第4个度量也可使用加权指数法42二软件过程质量度量软件需求过程的质量度量软件过程生产率的度量测试阶段的过程质量度量维护阶段的过程质量度量431软件需求过程的质量度量需求一致性度量Q1＝nui/nrnui是所有复审者都有相同解释的需求数目nr是需求说明书中需求的个数，包含功能和非功能需求需求完整性度量Q2＝nu/(ni×ns)

nu是唯一功能需求的数目ni是由需求规格定义或包含的输入的个数ns是被表示的状态的个数。需求确认程度度量Q3＝nc/(nc＋nnv)

nc是已经确认为正确的需求的个数nnv是尚未被确认的需求的个数441软件需求过程的质量度量需求稳定性度量需求稳定性度量是通过需求稳定因子RSI来表示：RSI=（所有确定的需求数-累计的需求变化请求数）/所有确定的需求数

所有确定的需求数=初始需求请求列表数+接受的需求变化请求数

452软件过程生产率的度量软件生产率的三维关系462软件过程生产率的度量度量量代码行功能点类测试用例度量单位人时（man-hour）人日（man-day）人月（man-month）人年（man-year）473测试阶段的过程质量度量测试用例的深度（TCD,TestCaseDepth）-每KLOC的测试用例数-每个功能点/对象点的测试用例数测试用例的有效性-每100或1000个测试用例所发现的缺陷数测试用例的质量（TCQ,TestCaseQuality）-测试用例发现的缺陷数量/总的缺陷数量483测试阶段的过程质量度量测试执行的效率和质量-每个人日所执行的测试用例数-每个人日所发现的缺陷数-每修改的KLOC所运行的测试用例数缺陷报告的质量-报告的质量不高的缺陷数/报告的总缺陷数质量不高的缺陷包含：1）状态为“需要补充信息”的缺陷2）状态为“不是缺陷”的缺陷493测试阶段的过程质量度量基于需求的测试覆盖-已执行的测试覆盖＝Tx／Rft-成功的测试覆盖＝Ts／Rft

Tx表示已执行的测试过程数或测试用例数Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数Rft是测试需求的总数基于代码的测试覆盖-已执行的测试覆盖＝Tc／Tnc

Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数Tnc（Totalnumberofitemsinthecode）是代码中的项目总数504维护阶段的过程质量度量平均失效时间MTTF(meantimetofailure)基于时间缺陷(或用户问题数)的到达率积压缺陷管理指标(BMI)软件成熟度指标(SMI)513.3软件过程度量3.3.1软件过程度量概念软件过程度量是对软件过程进行度量的定义、方法、活动和结果的集合。软件过程度量不是单一的活动而是一组活动的集合，它本身也是一个系统的过程。与任何系统的过程一样，它包括确定需求、制定计划、执行和结果分析等一系列完整的步骤。软件过程度量通常包括如下的活动：选择和定义度量、制定度量计划、收集数据、执行度量分析、评估过程性能、根据评估结果采取相应措施等。52软件过程度量的过程53软件过程度量概念软件过程度量的目标软件过程度量的对象软件过程度量的方法软件过程度量的结果543.3.3基于目标的软件过程度量方法GQM55一个目标主要受几个因素的控制ISSUES（侧重点）：度量对象的质量重点。VIEWPOINT（立场）：信息使用者。OBJECT（对象）：要度量对象。PURPOSES（目的）：一般是理解、控制和改进要度量的对象。56获得问题可以从以下几个方面来考虑目标：从过程改进人员的角度，分析同行评审过程，目的是提高同行评审过程的能力。对于特定目标陈述中的对象，应该抓住那些可以量化的特征？例如：什么是当前同行评审的效率？实际同行评审过程是按照文档化的流程执行的吗？同行评审发现缺陷的数量与评审对象规模、评审小组人数有关系吗？结合模型中的侧重点，这些特征应该怎么来描述？例如：同行评审的效率与其基线的偏差是多少？同行评审的效率正在提高吗？结合模型中的侧重点，应该如何评价度量对象的这些特征？例如：每人时发现的缺陷数量明显提高了吗？项目经理能够明显觉察到评审效率的提高吗？57选择数据项时至少要考虑以下几个方面现有数据的有效性尽量利用现有数据，实在没有相关数据积累或者现有数据的可靠性太差，也要少选、精选需要进行采集的数据项。总之，应该最大限度地利用现有数据。度量对象的稳定性对于成熟、稳定的度量对象，多应用客观度量。对于不成熟、不稳定的对象，可以结合主观判断和评价来获得数据。GQM建模的渐进性GQM建模是一个持续改进的过程。所选择的度量项不仅可以评价度量的对象，反之也反映了模型本身的可靠性和质量。58GQM分解样例GQM目标用途控制、改进对象同行评审过程侧重点能力需求方过程改进人员环境符合CMMI4要求的研发规范问题1什么是PR的过程能力？度量项PR排错能力同行评审过程缺陷密度的均值和控制限问题2如何判断一次同行评审的有效性？度量项有效性项目经理评价缺陷密度值状态项目经理对评审结论的评价缺陷密度值落在控制限之外：Y缺陷密度值落在控制限之内：N问题3项目经理对评审对象质量提高的评价问题4……59度量程序的例子1、摩托罗拉2、IBMRochester601、摩托罗拉摩托罗拉的软件开发质量政策（QPSD）目标1、改进项目计划制定2、提高缺陷遏制能力3、提高软件可靠性4、降低软件缺陷密度5、改进顾客服务6、降低不符合性的费用7、提高软件生产率611、摩托罗拉摩托罗拉的软件开发质量政策（QPSD）测量领域交付缺陷数和按标准大小的交付缺陷数全过程的总有效性遵循进度估计准确性未解决顾客问题数问题持续未解决的时间不符合性的费用软件可靠性621、摩托罗拉目标1：改进项目计划制定问题1.1：估计项目进度实际值的准确度是多少？度量1.1：进度估计准确度（ScheduleEstimationAccuracy,SEA）SEA=实际项目持续时间/估计项目持续时间问题1.2：估计项目工作量实际值的准确度是多少？度量1.2：工作量估计准确度（EffortEstimationAccuracy,EEA）EEA=实际项目工作量/估计项目工作量631、摩托罗拉目标2：提高缺陷遏制能力问题2.1：发布前缺陷检测过程的当前已知有效性如何？度量2.1：全部缺陷遏制有效性（TotalDefectContainmentEffectiveness,TDCE）TDCE=发布前缺陷数/（发布前缺陷数+发布后缺陷数）问题2.2：对以具体软件项目而言，在软件开发的每个构造阶段引入故障的当前一直遏制有效性如何？度量2.2：阶段i的阶段遏制有效性（PhaseContainmentEffectiveness,PCEi）PCEi=阶段i出错数/（阶段i出错数+阶段i缺陷数）641、摩托罗拉目标3：提高软件可靠性问题3.1：软件失效率是多少？怎样随时间变化？度量3.1：失效率（FailureRate,FR）FR=失效率/执行时间651、摩托罗拉目标4：降低软件缺陷密度问题4.1:过程中故障的规格化数目是多少？它和过程中缺陷数相比如何？度量4.1a:过程中故障数（In-processFaults,IPF）IPF=由增量式软件开发引起的过程中故障数/汇编等价的delta源代码大小度量4.1b:过程中缺陷数（In-processDefects,IPD）IPD=由增量式软件开发引起的过程中缺陷数/汇编等价的delta源代码大小661、摩托罗拉目标4：降低软件缺陷密度问题4.2：交付给顾客软件的当前已知缺陷量是多少？度量4.2a:总发布缺陷数total(TotalReleasedDefectstotal,TRDtotal)TRDtotal=发布缺陷数/汇编等价总源代码大小度量4.2b:总发布缺陷数delta(TRDdelat)TRDdelat=由增量式软件开发引起的发布缺陷数/汇编等价总源代码大小671、摩托罗拉目标4：降低软件缺陷密度问题4.3：交付给顾客软件的当前已知顾客发现的缺陷量是多少？度量4.3a:顾客发现缺陷数total(Customer-FoundDefectstotal,CFDtotal)CFDtotal=顾客发现缺陷数/汇编等价总源代码大小度量4.3b:顾客发现缺陷数delta(CFDdelta)CFDdelta=有增量式软件开发引起的顾客发现缺陷数/汇编等价总源代码大小681、摩托罗拉目标5：改进顾客服务问题5.1：本月期间还未解决的新问题数是多少？度量5.1：新未解决问题数（NewOpenProblems,NOP）NOP=本月未解决的新发布后问题总数问题5.2：本月末未解决的问题总数是多少？度量5.2：未解决问题总数（TotalOpenProblems,TOP）TOP=本月末仍未解决的新发布后问题总数691、摩托罗拉目标5：改进顾客服务问题5.3：本月末未解决问题的平均寿命是多少？度量5.3：未解决问题的平均寿命（AgeofOpenProblems,AOP）AOP=本月末仍未解决的发布后问题持续未解决的总时间/本月末仍未解决的发布后未解决问题数问题5.4：本月期间已解决问题的平均寿命是多少？度量5.4：已解决问题的平均寿命（AgeofClosedProblems,ACP）ACP=本月已解决的发布后问题的持续未解决的总时间/本月解决的发布后未解决问题数701、摩托罗拉目标6：降低不符合性费用问题6.1：本月期间修补发布后问题的费用是多少？度量6.1：修补问题费用（CostofFixingProblems,CFP）CFP=本月期间与修补发布后问题相关的费用711、摩托罗拉目标7：提高软件生产率问题7.1：软件开发项目的生产率是多少（按软件大小）？度量7.1a:软件生产率total(SoftwareProductivitytotal,SPtotal)SPtotal=汇编等价的总源代码大小/软件开发工作量度量7.1b:软件生产率delta(SPdelta)SPdelta=汇编等价delta源代码大小/软件开发工作量721、摩托罗拉有以上目标看到，度量3.1、4.2a、4.2b、4.3a和4.3b是最终产品质量的度量，5.1到5.4是软件维护度量，2.1、2.2、4.1a、4.1b是过程中质量度量，其余的用于进度、估计和生产率。732、IBMRochesterIBM共同软件测量委员会定义了一组标准的5-UP软件质量度量。包括：整体顾客满意度以及按CUPRIMDS参数的满意度。三年LOP跟踪的发布后缺陷率：基于报告缺陷的发布版本的TVUA/MSSI.顾客问题召唤修补响应时间有缺陷修补数74度量工具随着软件定量方法（如：软件度量）的重要性不断增加，市场上出现了许多度量工具。然而，度量工具目前还是很混乱。因为没有统一的度量标准规范，每种工具发明商家都是按照他们自己的软件度量规范。文献[44]对度量工具做了好的综述。Daich等根据分类学把度量工具分成了以下几种：

●通用度量工具；●小生境度量工具（NicheMetricsTool）；●静态分析；●源代码静态分析；●规模度量753.4软件配置管理SCM软件配置管理作为CMM2级的一个关键域（KeyPracticeArea，KPA），在整个软件的开发活动中占有很重要的位置。正如Pressman所说的：“软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来：标识变化；控制变化；保证变化被适当地实现；向其他可能有兴趣的人