3、软件质量度量和配置管理.ppt

3.3.2 软件过程度量常见问题 度量的太多、太频繁 度量的太少、太迟 度量了不正确的事物或属性 度量的定义不精确 收集了数据却没有利用 错误的解释度量数据 自动化工具欠缺 * 3.3.3 基于目标的软件过程度量方法 * 如何确定哪些需要度量？ 度量是项目管理的重要手段，但度量需要成本，主要体现在数据收集和分析需要花费较大的工作量，所以要根据信息的需要和信息的优先级来决定度量和进行度量。 GQM（Goal-question-metric）方法便于识别所需的度量。 GQM的主要步骤： 确定度量的目标。 提出能够满足目标的问题。 确定回答问题所需要的度量。 * GQM度量过程 * 举例： 目标（G）：提高劳动生产率 问题（Q）： 花在返工上的时间是多少？ 开发人员是否花费了太多的时间在支持和管理活动上？ 平时劳动生产率是多少？ 劳动生产率是否和开发小组的经验相一致。 度量（M）： 每个开发花在返工上的平均人时 对支持人员可供使用的预算百分比 对项目管理或者支持任何花费的人时比例 每个PM对开发人员的比例 * 一个目标主要受几个因素的控制 ISSUES（侧重点）：度量对象的质量重点。 VIEWPOINT（立场）：信息使用者。 OBJECT（对象）：要度量对象。 PURPOSES（目的）：一般是理解、控制和改进要度量的对象。 * 获得问题可以从以下几个方面来考虑 对于特定目标陈述中的对象，应该抓住那些可以量化的特征？例如： 什么是当前同行评审的效率？ 实际同行评审过程是按照文档化的流程执行的吗？ 同行评审发现缺陷的数量与评审对象规模、评审小组人数有关系吗？ 结合模型中的侧重点，这些特征应该怎么来描述？例如： 同行评审的效率与其基线的偏差是多少？ 同行评审的效率正在提高吗？ 结合模型中的侧重点，应该如何评价度量对象的这些特征？例如： 每人时发现的缺陷数量明显提高了吗？ 项目经理能够明显觉察到评审效率的提高吗？ * 选择数据项时至少要考虑以下几个方面 现有数据的有效性 尽量利用现有数据，实在没有相关数据积累或者现有数据的可靠性太差，也要少选、精选需要进行采集的数据项。 总之，应该最大限度地利用现有数据。 度量对象的稳定性 对于成熟、稳定的度量对象，多应用客观度量。对于不成熟、不稳定的对象，可以结合主观判断和评价来获得数据。 GQM 建模的渐进性 GQM 建模是一个持续改进的过程。所选择的度量项不仅可以评价度量的对象，反之也反映了模型本身的可靠性和质量。 * GQM分解样例 GQM 目标 用途 控制、改进 对象 同行评审过程 侧重点 能力 需求方 过程改进人员 环境 符合CMMI4要求的研发规范 问题1 什么是PR的过程能力？ 度量项 PR排错能力 同行评审过程缺陷密度的均值和控制限 问题2 如何判断一次同行评审的有效性？ 度量项 有效性项目经理评价缺陷密度值状态 项目经理对评审结论的评价 缺陷密度值落在控制限之外：Y 缺陷密度值落在控制限之内：N 问题3 项目经理对评审对象质量提高的评价 问题4 …… * 3.4软件配置管理 软件配置管理作为CMM 2级的一个关键域（Key Practice Area，KPA），在整个软件的开发活动中占有很重要的位置。 正如Pressman所说的：“软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来： 标识变化； 控制变化； 保证变化被适当地实现； 向其他可能有兴趣的人员报告变化。 * 要软件产品进行配置管理(1/2) 软件项目已经成功实施了8个月，项目组已经进入编码阶段，在此过程中产生了许多的软件产品 到了编码阶段已经有了近百个软件产品(包括技术文档、管理文档、程序模块等)，项目组在管理这些产品方面感到繁琐和困难 此时，用户提出要变更需求，软件项目组同意用户的需求变更请求，为此，修改了软件需求规格说明书 项目组将更改后、新的软件需求规格说明书交给了软件设计小组，设计小组为此更改了设计。更改后的软件设计涉及诸多的软件模块和数据设计，为此导致许多的模块和源程序代码和可执行代码发生了变化 由于变化的范围太大，项目组很难清晰地了解哪些作了变化、做了什么样的变化 * 要软件产品进行配置管理(2/2) 由此带来的新的问题是，项目组未能及时将这些变化通知给相关、受影响的小组和人员，从而出现软件产品之间的不一致(设计与编码不一致)，所开发的产品没有完全符合和满足用户的需求 对于某些模块更为糟糕，因为这些模块已经经过了多达6－7次的修改，而且每次修改都有意义，从而产生了不同版本的软件模块设计，由于没有相关的有效管理措施，开发人员已经很难清晰、有效识别、区分这些软件模块，出现许多开发人员都有该模块的诸多版本 与此相对应的是，该模块的源代码也有许多版本 在实际组装软件时，项目组不能有效提取出所需的软件产