《{企业管理运营}软件工程实践9度量与配置管理》由会员分享，可在线阅读，更多相关《{企业管理运营}软件工程实践9度量与配置管理（139页珍藏版）》请在金锄头文库上搜索。
1、软件工程实践,汤铭端 中国航天科工集团公司706所,第九讲,软件度量 需求管理 软件配置管理,内容和目的,了解软件度量的概念和内容 掌握需求管理的概念 了解需求管理的过程 掌握配置管理的概念 掌握配置管理的过程,软件度量,软件度量,理解软件度量 选择软件度量指标 度量计划步骤,软件度量的理解,项目规划时，需要评估项目规模和进度等 项目跟踪时，需要明确实际的工作量和时间与计划的对比情况 判断软件产品的稳定性时，需要明确发现和纠正缺陷的速率 定量了解项目的进展，需要对当前项目的绩效进行测量，并与基线进行比较,软件度量的定义,软件度量是软件中范围广泛的测度，让你定量了解进度，工作量，产品规模，项目状
2、态以及质量性能，用于评估情况，跟踪进展，评价效率。,度量类型,过程 项目 技术,过程中的度量,战略目的 进行连续的过程改进,项目中的度量,辅助估算 质量控制 生产率评估 项目控制 战术目标,技术中的度量,评估技术工作产品的质量 在项目中进行决策,作用,软件度量是为项目估算，计划的基础数据 软件度量提供控制项目的量化信息 软件度量为质量管理提供指示 软件度量能推动企业的过程改进,度量成本,开始度量时设定度量底线：收集度量的成本应与可获得的潜在利益相平衡 防止意外成本（后果）的发生,软件度量的困难,不一定认为度量是软件工程的必备要素 很难定义和收集度量，常常被忽视。 今天的数据是明天的历史数据,选
3、择软件度量,开始实施时，选择一组数量少而且平衡的度量，有助于企业达到目标,GQM:目标-问题-度量,GQM是一个杰出的技术 用于选择适当度量来满足需求,GQM:步骤,首先选择几个项目或者几个机构的目标，尽可能将目标叙述的可以量化、可以测量。 对于每个目标，设想一下必须回答的问题，看看是否达到目标 最后，确认必须回答每个问题的度量,目标：,一年内降低50%维护成本 将进度估计的准确性实际提高到10%以内 将下一个项目的系统测试时间减少三个星期 三个月内将消灭一个缺陷的时间减少40%,问题,一年内降低50%维护成本 每个月我们花在维护上的费用是多少? 花在我们支持的每个应用软件上的维护成本是多少?
4、 我们花在调整（调整以适应变更的环境）、完善（增加、提高）和修正（纠正缺陷）上的费用是多少？,度量,我们花在调整、完善和修正上的费用是多少？ 每类维护活动所花的时间 每类维护活动所花的时间内的总维护成本,平衡的度量组,产品规模 产品质量 过程质量 工作量 项目状态 客户满意度,SEI度量指标,SEI度量指标,Process Effort Cost Quality SQA Audit Results Review Results Trouble Reports Peer Review Results Defect Prevention,Stability Requirements Stabili
5、ty Size Stability Process Stability Computer Resource Utilization Training,项目的常用关键度量,代码的行数 及时完成的预定任务 推迟完成的预定任务 测试覆盖范围 资源适合程度 故障密度 系统运行的可利用率 推向市场的时间 进度、质量和成本之间的折衷,度量对象,软件开发人员 软件项目组 软件机构,软件开发人员,工作量分布 任务持续时间和工作量的估计值和实际值 单元测试覆盖的代码 单元测试发现的缺陷数目 代码和设计的复杂性,项目组,产品规模 工作量分布 需求状态(批准的需求数，实现的需求数，核实的需求) 通过测试的测试用例百
6、分比 各主要里程碑之间相隔时间的估计值和实际值 人员水平的估计值和实际值 集成测试和系统测试中发现的缺陷数 检查发现的缺陷数 缺陷状态 需求的稳定性 计划任务数和完成任务数,机构组织,发布的缺陷水平 产品开发周期 估计准确度的进展计划和工作量 重新使用的有效性 计划成本和实际成本,数据的级别,成员级别 项目级别 机构级别,PSP的度量指标,项目计划度量 项目质量度量,项目计划总结表,项目计划总结表,项目规划度量-个人统计,项目名称：教育信息平台,项目成员：张三,成员级别系数：1.2,项目规划度量项目统计,（最好利用工具）统计出所有项目中各个任务的度量值。 统计出项目中某一类任务的工作量值：FP
7、,LOC 统计出项目中某一类任务的规模（人天）,项目规划度量项目统计例子,项目的需求分析时间：50天 项目的需求规模：100人天 项目中任务001的设计时间：10天 项目中任务001的设计规模：15人天 项目中任务001的编码时间：5天 项目中任务001的测试时间：6天 项目中任务001的编码规模：5人天,项目质量度量-个人统计,项目名称：教育信息平台,项目成员：李四,成员级别系数：0.8,项目质量度量项目统计,统计出所有项目中各个任务的度量值。 统计出某一类型缺陷的个数 统计出某一阶段缺陷的个数 统计出某一模块缺陷的个数,项目质量度量项目统计例子,项目的需求阶段的缺陷：6 项目的编码阶段的缺
8、陷：100 项目中任务001的缺陷数：20 项目中接口类缺陷数：20,开发度量计划的步骤,开发度量计划的步骤,标识目标 选择起步度量 明确工作活动 汇总历史数据 收集并分析度量， 决策中使用度量,1、标识目标,确定明确的标准目标 或者汇总一个基线,标识目标作用,让度量计划改善经营成果 执行严格定义、目标集中的计划以降低成本 奠定改善软件投资回报的基础,2、选择起步度量,进度度量 需求度量 测试覆盖的百分数 软件规模 故障密度 故障发生解决率 项目整体风险度量,2.1进度度量,计算按期完成的任务数 推迟完成的任务数 重订进计划中的任务数,2.2需求度量,已经变更需求的百分数 新需求百分数,2.3
9、测试覆盖的百分数,描述百分之几的代码已经经过测试了； 统计表明： 没有度量的测试只能测试代码的50-60% 有有度量的测试可以推动代码测试覆盖率,2.4软件规模,代码行 功能点 人月数,2.5故障密度,软件质量的基本度量:每KNCSS未解决的故障数。 例如：产品发行标准： 0.25故障/ KNCSS 数据表明： 7发现缺陷数/ KNCSS,2.6故障发生解决率,在一段固定时间内,发现并解决故障的数目.是软件可以冻结的一个稳健机制。 软件冻结的条件：故障发生率和解决率为0 故障发生解决率可以判断测试阶段的完成，有助于测试过多。,2.7项目整体风险度量,完成特定进度计划的可能性百分数,3、明确工作
10、活动,度量需要的什么特定日期 谁负责收集度量数据 何时收集、何时报告度量 度量如何报告（状态报告、季度会议、度量报告） 必要时可以赋予各种度量相应的优先级,4、汇总历史数据,已经完成的项目的度量数据 当前项目的历史数据 使用度量数据库 存储收集的度量数据,度量数据库原则,数据库应当易于使用,人们才能方便地更新并报告数据 数据库应当灵活, 数据库最好与其他工具有接口界面 数据库与图形报告工具有接口界面,便于制作图形和表格 数据库足够大,以便包含更多的历史信息 数据库避免重复 数据库应注意安全,数据库类型,电子制表软件 商用数据库软件,5、收集并分析度量,收据度量数据 与既定的目标进行跟踪比较，
11、得出相应的结论,收集并分析度量的自动化,知识 纸面模板 电子数据表 预定义报告 软件工具,6、决策中使用度量,可以判断产品的推出程度 了解客户项目的成本和进度 在估计成本和进度时考虑多少偶然因素 过程改进中投资何处能得到最到的回报 何时开始用户培训,度量管理的注意事项,软件度量成为习惯 从小开始 解释为什么 分享数据 定义数据选项及其规程 理解趋势,需求管理,Requirements Management,需求工程,定义需求 获取需求 用户需求 系统需求 分析需求 规格说明 文档化需求 评审需求,管理需求 理解需求 保管需求 实现需求 控制需求 验证需求,需求管理的目的,需求管理的目的是在顾客
12、和将处理顾客需求的软件项目之间建立对顾客需求的共同理解。,需求管理的内容,需求管理包括和顾客一起建立和维护有关软件项目需求的协议，该协议称作“分配给软件的系统需求”。 “顾客”可解释为系统工程组、销售组、另一个内部组织、或者一个外部顾客。 协议既包括技术需求、又包括非技术需求（例如交付日期）。该协议形成估计、策划和跟踪整个软件生存周期内软件项目活动的基础。,分配需求的形成,将系统需求分配给软件、硬件和其它系统成分的工作可能由软件工程组之外的组（例如系统工程组）完成，软件工程组可能对此分配无直接控制。 在项目约束范围内，软件工程组采取恰当步骤以保证对分配给软件的需求建档、并加以控制，该组负责处理
13、分配给软件的系统需求。,需求管理的目标,目标1 分配给软件的系统需求是受控的，建立供软件工程和管理使用的基线。 目标2 软件计划、产品和活动与分配给软件的系统需求保持一致。,对分配需求建立文档,分配需求包括： 1. 影响和确定软件项目活动的非技术性需求（即： 协议、条件、和（或）合同条款），如要交付的产品、交付日期、里程碑。 2. 对软件的技术需求，如最终用户、操作员、支持、或集成功能；性能要求；设计约束；编程语言；界面需求。 3. 用于确认软件产品满足分配需求的验收准则。,需求管理的过程要求（1）,活动1 在分配需求被纳入软件项目之前，软件工程组评审它们。 1. 鉴别出不完整的和遗漏的分配需
14、求。 2. 评审分配需求，确定它们是否： 用软件来实现是可行的和恰当的， 被清晰和正确地阐述， 是相互一致的，和 是可测试的。 3. 负责分析和分配系统需求的组评审任何被识别出是有潜在问题的分配需求，并作出必要的更改。 4. 和受到影响的组协商由分配需求引起的约定。,需求管理的过程要求（2）,活动2 软件工程组采用分配需求作为软件计划、工作产品和活动的基础。分配需求： 1. 被进行管理和控制。 “进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的（即版本控制），而且以受控的方式引进更改（即更改控制）。 2. 是软件开发计划的基础。 3. 是制定软件需求的基础。,需求管理
15、的过程要求（3）,活动3 评审对分配需求的更改，将其纳入软件项目。 1. 评估它对现有约定的影响，合适时协商更改。 对组织外部的个人和组所作约定的更改由高级管理者参与评审。 和受到影响的组协商组织内部约定的更改。 2. 对由于分配需求的更改所造成的对软件计划、工作产品和活动必须作的更改要加以： 识别，评价，风险评估，文档化，规划，传达到受到影响的组和个人，跟踪直到结束。,需求管理过程,任何项目都必须存在分配需求类文档 合同、任务书、立项报告、招标文件 Kick Off 会议 项目组讨论（评审）分配需求 分配需求经批准后纳入配置管理 对涉及外部承诺、约定内容的更改严格控制,需求管理的工具：双向追
16、溯矩阵,建立需求档案 检查需求的完成 设计 实现 检测 对相关的更改进行追踪,需求追溯矩阵,软件配置管理,SCM Software Configuration Management,软件开发中存在的一些问题,文文不一致 文档和文档之间不一致 文实不一致 文档和程序之间不一致 程序版本不一致 无法连接、无法安装、无法形成特定产品 问题处理的混乱,软件开发中存在的一些问题,软件项目进行中面临的一个主要问题是持续不断的变化 有效的项目管理能够控制变化，以最有效的手段应对变化 不断命中移动的目标,配置(Configuration),一计算机系统或网络按照其功能部件的特点、数量和主要特征而确定的排列。具体地讲，配置一词可以指硬件装置或软件装置。 为确定一系统或系统组成部分的特定版本而提出的
