软件过程管理与过程改进
教材与参考资料
1. CMM in Practice---Processes for Executing Software Projects at Infosys (pankaj jalote,2000)
2. Capability Maturity Model for Software, SEI-91-TR-24, 1991(. Paulk)
3. Software Project Management in Practice (pankaj jalote,2002)
第一章 绪论
主要内容
1. 软件开发与软件项目管理
2. CMM简介
3. INFOSYS公司的项目管理实践
一.软件开发与软件项目管理
1. 软件项目管理的重要性
2. 软件危机的提出
3. 世界软件产业发展现状及中国软件业的差距
1. 软件项目管理的重要性-1
软件
是使计算机能够工作的指令集合和相应的数据结构和文档，是一种产品，将计算机的硬件能力发挥出来的一种工具，是传递信息的一种工具，对信息的处理手段。
软件的特征：
软件是一种逻辑元素，而不是物理元素；
软件是开发出来的，而不是用传统的方法制造出来的。
软件不会被用坏。一般产品的失败概率都遵循浴盆曲线。但软件是另外的
工业界已经是标准化装配时代，但软件还是定制时代；创新性和人为因素更高。
1. 软件项目管理的重要性-2
软件开发是一个高风险的过程
软件过程的管理是软件成功的关键
职业的发展方向、软件企业的生存的重要性
2. 软件危机的提出-1
“软件危机” 的主要原因：
1. 用户不易准确描述对软件的需求，经常存在二义性，遗漏甚至错误
2. 大型软件往往需要成百上千人的合作，由于软件系统结构复杂，如何有效组织管理、充分发挥团队作用就成为软件开发成功的关键。
3. 缺乏有效的软件开发方法和工具的支持，过分依靠程序设计在开发中的技巧和创造性，加剧了软件产品的个性化。开发过程没有统一、规范的方法论指导，文档资料不齐全。
4. 缺乏软件开发经验及相关数据积累，无法准确估计经费和进度，导致经费严重超支，完成期限一拖再拖。
5.忽视测试阶段的工作，提交的产品质量差。
2 软件危机的提出-2
（软件项目失败的案例）
1999,10月，美国NASA火箭气象卫星失踪，耗资亿美元。软件的错误，英制和公制的转换问题导致。
1963-1966 美国IBM360机器的操作系统，5000人年的工作量，1000多人进行开发，100万行代码，新版本是在老版本中找出1000个以上的错误之后修正开发。当时的情况很不好，主要负责人brooks 把他们当时比作陷在泥潭的困兽，越挣扎越深。
1999年8月，在美国的一个大型的商业高速数据网络里，软件的缺陷影响了7000多个商业用户，时间长达8天。
1998年4月，美国的一个重要数据通讯网络出现24小时的故障，使大部分美国的信用卡业务受到影响。受影响的还有美国的一些大银行、零售商和政府的数据系统。也是软件故障。
1997年8月，美国一家最主要的信用卡报告公司的新网站开启2天就关闭了，主要是查询自己的信用卡使用情况，但看到的是别人的账单，而不是自己的。
Software disasters 网站
3. 世界软件产业发展现状及中国软件业的差距
美国
印度
爱尔兰
中国的软件现状
（与印度的比较及反思）
软件产值的比较
印度 中国 （软件产值：亿）
1999：
2000：
2001：
2002： 110 124
软件出口的比较
印度 中国 （软件出口）
1999： 39
2000： 62 4
2001：
世界软件外包市场规模（亿美元）
2004-----------334 （ 中国）
2005-----------414 （）
2006-----------519 （）
2007-----------642 （）
2008-----------781 （）
2009-----------943 （39）
软件外包份额
2006年软件外包份额
印度
爱尔兰
菲律宾
中国
二. 软件能力成熟度模型
1. CMM简介
2. CMM的成熟度级别
3. 不同级别的KPA
4. CMM 的评估方法
1. CMM简介
CMM—capability maturity model for software软件能力成熟度模型是一种描述有效软件过程的关键元素的框架，CMM描述一条从无序的不成熟的过程到成熟的、有纪律的过程的进化的改进途径。
CMM包括对软件开发和维护进行策划、工程化和管理的实践。遵循这些关键实践，就能改进组织在实现有关成本、进度、功能和产品质量等目标上的能力。
CMM的起源与发展
我国的CMM现状
几个基本概念
软件过程
软件过程能力
软件过程性能
软件过程成熟度
软件过程
人们用于开发和维护软件及其相关过程的一系列活动，包括软件工程活动和软件管理活动。
软件过程能力
描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。
软件过程性能
表示（开发组织或项目组）遵循其软件过程所得到的实际结果，软件过程性能描述的是已得到的实际结果，而软件过程能力则描述的是最可能的预期结果，它既可对整个软件开发组织而言，也可对一个特定项目而言。
2. CMM的成熟度级别
1. 成熟度等级 分为5级
2. 成熟度等级的五个级别的主要特征
3. 软件过程的可视性
4. 过程能力和性能预测
成熟度等级1-5
1级 初始级 (Initial)
2级 可重复级 (Repeatable)
3级 已定义级 (Defined)
4级 已管理级 (Managed)
5级 优化级 (Optimizing)
成熟度等级的五个级别的主要特征
初始级特征：软件过程的特点是无秩序的，偶尔甚至是混乱的，几乎没有什么过程是经过定义的，成功依赖于个人努力。
可重复级特征：已建立基本的项目管理过程去跟踪成本进度和功能，必要的过程纪律已经就位，使具有类似应用的项目能重复以前的成功。
已定义级特征：管理活动和工程活动两方面的软件过程均已文档化、标准化，并集成到组织的标准软件过程中，全部项目均采用供开发和维护软件用的组织标准软件过程的一个经批准的普及剪裁版本。
成熟度等级的五个级别的主要特征(续）
已管理级特征：已采集详细的有关软件过程和产品质量的度量，无论软件过程还是产品均得到定量了解和控制。
优化级特征：利用来自过程和来自新思想、新技术的先导性实验的定量反馈信息，使持续过程的改进成为可能。
软件过程的可视性
等级1―――一个黑盒
等级2――― 项目里程碑处具有管理可视性
等级3―――盒子的内部结构可视
等级4―――软件过程被配备上度量，并得到定量地控制
等级5―――对过程不断改进
过程能力和性能预测
随着成熟度增长，实际结果相对预定目标结果的偏差范围减小
随着成熟度增加，预定目标结果得到改善
3. 不同级别的KPA
关键过程区域（key process area）
每个关键过程区域 识别出一串相关活动，当这些活动全部完成时，能达到一组对增强过程能力至关重要的目标
CMM共有18个KPA，2级――6个；3级――7个；4级――2个；5级――3个。
KPA的特性：
A． 每个ＫＰＡ识别出一串相关活动
B． 每KPA定义在单个成熟度等级上
C. KPA鉴别出为达到某一成熟度等级所必须解决的问题
等级2的KPA
l 需求管理 RM(requirements management)
l 软件项目策划SPP(software project planning)
l 软件项目跟踪和监督SPTO(spftware project tracking and oversight)
l 子合同管理SSM (software subcontract management)
l 质量保证SQA(software quality assurance)
l 软件配置管理 SCM(software configuration management)
等级3的KPA
l组织过程焦点OPF (organization process focus)
l组织过程定义OPD(organization process definition)
l 培训大纲TP(training program)
l集成软件管理ISM (integrated software management )
l 软件产品工程SPE(software product engineering)
l 组间协调IC(intergroup coordination)
l 同行评审PR( peer reviews)
等级4的KPA
l 定量过程管理QPM
(quantitative process management)
l 软件质量管理SQM
(software quality management)
等级5的KPA
l 缺陷预防DP
(defect prevention)
l 技术改革管理TCM
(technology change management )
l 过程更改管理 PCM
(process change management )
关键过程域(KPA)的结构
目标
共同特点
（执行约定，执行能力，执行活动，测量和分析，验证实施）
目标
目标概括一个PKA中的所有关键实践，并能用于确定一个组织或项目是否已有效地实施此KPA。
目标表示每个关键过程域地范围、边界和意图。
共同特点
执行约定(Commitment to Perform)
执行能力(Ability to Perform)
执行活动(Activities Performed)
度量和分析（Measurement and Analysis）
验证实施(Verifying Implementation)
执行约定(Commitment to Perform)
执行约定是企业为了建立和实施相应KPA所必须采取的行动，这些行动主要牵涉到企业范围的政策和高层管理的责任。
执行能力(Ability to Perform)
执行能力描述为了使某软件过程得以始终如一地执行的必须在项目或企业中存在的先决条件，是企业实施KPA的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的实践活动。执行能力关注于项目计划的实践；资源的配置；责任的布置与授权；以及各种有关的培训等，这些都是为了执行这个关键过程域的活动而对特定人以及作为整体的机构的能力开发起非常重要作用的事务。
执行活动(Activities Performed)
执行活动描述了执行KPA所需求的必要行动、任务和步骤。在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。执行活动一般包括计划、执行的任务、任务执行的跟踪等。
验证实施(Verifying Implementation)
验证实施是验证执行活动是否与建立的过程一致，核实以确保所实施的过程是按照原定的计划以及达到其目标，着眼于保证过程的实现要通过独立的个人和高级管理人员验证。涉及到管理的评审和审计以及质量保证活动，包括：过程执行的确保，产品要求的确保，高层管理人员进行的审核和项目经理进行的审核。
测量和分析（Measurement and Analysis）
测量和分析关注于这个关键过程域的活动需要作的度量和度量分析要求。典型的测量和分析的要求是确定执行活动的状态和执行活动的有效性。
4. CMM 的评估方法
1. 过程评估与过程评价
2. 过程评估的方法
过程评估与过程评价
软件过程评估：用于确定一个组织的当前软件过程的状态，确定组织所面临的具有高优先级的与软件过程有关的问题，和获得组织对软件过程改进的支持
软件过程评价：用于识别合格的能完成软件工作的承包商或者监控现有软件工作中所应用的软件过程的状态
过程评估的方法
成熟度问卷
文档
面谈
三. INFOSYS公司的项目管理实践
1. INFOSYS公司的背景知识
2． SEPG对项目的支持
3． 高层经理参与项目
4． 项目经理培训
5. 项目管理过程(项目规划, 项目执行, 项目收尾)
第二章 软件项目管理概述
项目管理的概念
项目管理的主要内容
项目管理的阶段划分
1．基本概念
项目管理定义：
Badiru(1991)将项目管理定义为：
一种为高效恰当地完成某个既定的目标而对资源进行管理、分配和调度的过程。
我们也可以把项目管理定义为：
一种为实现既定目标而对技术、人力及金融资源所进行的系统集成。
项目管理的关键要素
基本要素
项目、目标、资源、项目干系人、需求
战略要素
PPP（people. problem. process）
策略层面核心要素
SSC( Scope, Schedule, Cost )
项目的定义
所谓项目，就是为创建某一独特产品或服务，在一定的环境和约束条件下进行的临时性努力，即它是利用有限的资源，在有限的时间内为特定客户完成特定目标的一次性工作。
项目的特征
一个明确的范围和目标；
一个预期的完成时间；
有可以利用的资源；
一种已定义的性能评估方法；
不是例行的任务
项目的分类
业务项目和自我开发项目
企业项目、政府其他非盈利机构的项目
盈利性项目和非盈利性项目
大项目、项目和子项目（Program, Project, Subproject ）
典型的项目类型
产品或新服务的开发项目
技术改造与技术革新项目
组织机构、组织模式的变革项目
科学技术研究与开发项目
信息系统的集成于开发项目
典型的信息系统项目特点
目标不明确
需求变化频繁
智力密集型
项目生命周期短
使用维护的技术要求高
国际项目管理的两大组织及研究体系
1. IPMA、ICB以及IPMP
IPMA（International Project Management Association, 国际项目管理协会，1965，欧洲，中国也是其成员）
ICB（国际项目管理资质标准），IPMA建立的知识体系。
IPMP（International Project Management Professional, 国际项目管理专业资质认证）分为Ａ，Ｂ，Ｃ，Ｄ四个等级。
国际项目管理的两大组织及研究体系
２.PMI、PMBOK以及PMP
PMI（Project Management Institutr,美国项目管理学会）
PMBOK（Project Management Body of Knowledge, 项目管理的知识体系）
PMP（Project Management Professional 项目管理专业人员资格认证）4500小时，大学毕业，7500小时
2. 项目管理的知识体系
项目管理的9方面内容：
范围管理 、质量管理 、
时间管理 、成本管理 、
风险管理 、人力资源管理 、
合同/采购管理 、通讯管理
项目集成管理
项目管理主要有三个大的阶段
项目规划
项目执行
项目收尾
项目规划：主要是项目经理审阅合同条款，并制定一个满足他们的计划，实际上包括：定义生命周期、估计工作量和进度、制定任务进度计划等。
项目执行：包括执行项目计划、跟踪项目的状态，并在项目的绩效偏离项目计划设定的绩效时采取措施进行纠正。
项目收尾：主要是在客户接收工作产品之后对项目进行系统的总结。数据分析是这一阶段的主要任务。
第三章 项目范围管理与需求规格和需求管理
项目管理：范围管理
软件项目管理：软件需求管理
3. 1 范围管理
一。范围管理的含义
1. 项目范围
是指为创建产品或服务所做的所有工作及过程。
2. 项目范围包括
*产品范围（表征产品或服务的特性与功能）
*工作范围（为交付具有特定属性和功能的产品、服务而必须完成的工作）
二。 项目范围管理
能够确保所做的工作既充分且必要，这些工作可以实现项目的目标。包括3层含义：
所确定的工作范围是充分的。
工作范围不包括那些不必要的工作
工作范围规定要做的工作能够实现预想的商业目标。
由项目启动、范围计划编制、范围定义、范围核实和范围变更控制构成。
1.项目启动
组织正式开始一个项目，主要的阶段输出：
项目章程
项目经理认定或任命
约束条件
假定
2.范围计划编制
是将产生项目产品所需进行的项目范围渐进明细和归档的过程。
主要的阶段输出：
范围说明
详细依据
范围管理计划
3. 范围定义
对初步 范围说明书形成的项目主要可交付成果分解成较小的、更易管理的单元。
更新项目管理计划
4. 范围核实与确认
项目干系人正式接受已经完成的项目范围的过程。
输出：正式接受的范围说明及范围管理计划。
5.范围变更控制
对项目范围的变更实施控制，以便对变更进行管理，确保变更有序进行。
需求规格和需求管理
需求过程：
需求开发（分析和产生需求的过程，
发生在软件生命周期的开始）
需求管理 （包括对需求的评审，
跟踪和控制活动，贯穿于整个生命周期）
一. 需求分析和需求规格
需求分析的过程
需求规格说明书
（需求规格说明书的要求）
二. 需求变更管理
需求是会发生变化的，而且需求的变更可以在项目生命周期的任何时间发生。越是发生在后期，对项目的影响越大。如何管理好需求变更的申请是非常重要的。
变更管理过程
变更管理过程规定如何发出变更申请、何时需要正式批准等。在出现需求变更申请时，必须执行需求变更管理过程。
一般的变更管理过程
记录变更
分析变更对工作产品的影响
估计变更申请所需的工作量
重新估计交付时间表
执行累计的成本影响风险
如果影响超出一定的限度，则与高级主管一起评审影响
客户不再提出变更申请
修改工作产品
三. 需求的跟踪管理
跟踪矩阵
跟踪矩阵的维护和使用
第四章 过程定义和过程裁剪
过程描述：是项目可以用来遵照执行某些任务的一系列步骤，以及执行这些步骤的指南。
开发过程
开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户所需的过程：
需求分析
概要设计
详细设计
编码和单元测试
集成测试
系统测试
验收测试和安装
文档整理
系统维护
概要设计
主要给出从计算机的逻辑角度开发针对用户需求的解决方案。
输入准则：需求规格文档经过评审并授权
输入：需求规格文档
输出准则：概要设计文档经过评审和授权
输出：概要设计文档、项目标准、概要设计评审记录
度量：工作量、缺陷
主要步骤：
详细设计
进一步对概要设计中的整体应用分解，分解成模块和程序，对程序进行逻辑设计。
输入准则：概要设计文档经过评审和授权
输入：概要设计文档
输出准则：详细设计文档和单元测试计划已经经过评审和授权
输出：详细设计文档和单元测试计划
度量：工作量、缺陷
主要步骤：
编码和单元测试
根据详细设计用编程语言编写所需要的程序
输入准则：详细设计文档经过评审并授权
输入：详细设计文档、项目标准、单元测试计划、程序框架
输出准则：成功执行所有单元测试计划中的测试用例
输出：源代码、可执行代码、测试数据
度量：工作量、缺陷
主要步骤：
集成测试
已通过单元测试的模块构建成一个完整软件结构的系统方法
输入准则：概要设计文档经过评审和授权
输入：概要设计文档和程序
输出准则：成功执行所有集成测试计划中的测试用例
输出：源代码、可执行代码、测试数据
度量：工作量、缺陷
主要步骤：
系统测试
是依据需求规格验证软件产品有效性的活动；目的是为了发现那些只有通过测试整个系统才能暴露的缺陷
输入准则：需求规格和概要设计文档经过评审和授权
输入：需求规格和概要设计文档
输出准则：成功执行所有集成测试计划中的测试用例
输出：源代码、可执行代码、测试数据
度量：工作量、缺陷
主要步骤：
验收测试和安装
把软件产品集成到它的操作环境中，并在这个环境中经受测试，确保它按需求执行。
输入准则：成功的完成系统测试
输入：测试后的软件和验收测试文档
输出准则：客户签署验收单
输出：安装后的软件
度量：工作量和缺陷
主要步骤：
文档
主要是操作手册，用户手册及客户需要的其他文档。
主要活动：
系统维护
输入准则：
输入：
输出准则：
输出：
度量：
主要步骤：
过程裁剪
过程裁剪是调整组织标准过程的过程，以此来获得用于项目的特定业务或技术需要的过程。
主要有：
概要裁剪指南
详细裁剪指南
概要裁剪指南
提出基于某些项目特效，在项目中应该如何执行一些通常的活动。
概要级剪裁：根据项目特征，应用总体指南标准对标准过程进行剪裁，用到如下特征。
（1） 团队和项目经理的经验和熟练程度。
（2） 团队人数最多时的人数。
（3） 需求透明度
（4） 项目持续时间
（5） 应用的关键程度
详细裁剪指南
列出过程中各种生命周期阶段的所有活动，还包括对每个活动相应的裁剪活动,指定每个步骤是必要的还是可裁剪，并给出选择的指南。
第五章 过程数据库与过程能力基线
关键要素：
过程数据库（process database, PDB）
过程能力基线(process capability baseline , PCB)
过程财富( process asset)
一. 软件度量
软件度量可以来量化地描述软件过程和软件产品的不同方面的特点。
过程度量的要素；
产品度量的要素。
软件度量的作用
项目计划
控制项目过程
分析和改进组织过程
二. 过程数据库
是存放从项目可获得的过程性能数据的数据库，这些数据可以用于项目计划、估计、生产率和质量分析等。
PDB由已经完成的项目的数据构成
PDB用途：
1. PDB内容
项目特征
项目进度
项目工作量
项目规模
故障
风险
2. PDB的建立及其访问
PDB由SEPG建立
项目经理可以阅读
二. 过程能力基线
过程能力基线（PCB）的主要内容：
已交付软件的质量
生产率
进度计划
工作量分布
故障引入率
过程中故障排除率
质量成本
故障分布
过程财富
过程财富的组成：
1、 组织标准软件过程
2、组织的软件过程数据库/过程能力基线
3、 软件生命周期描述
4、 标准软件过程的剪裁指南和准则
5、软件有关文档
第六章 工作量估计和进度安排
工作量估计模型
自顶向下的估计方法
规模估计－－整体工作量－－各阶段工作量
COCOMO 模型
自底向上的估计方法
各阶段的工作量－－整体的工作量
此方法可以直接估计工作量
自底向上的估计方法
1. 估计方法
任务分解－－每个程序单元的复杂度定义－－估计每个单元的编码工作量－－计算整个程序的编码工作量－－导出整体项目的工作量－－各阶段的工作量
2。程序单元分类的准则
2. 程序单元分类的准则
各种平台，各种语言，各种环境分类的标准不一样。
3. 方法的有效性
估计工作量与实际工作量的比较
自顶向下的估计方法
规模估计－－整体工作量－－各阶段工作量
估计的步骤：
规模估计方法
软件规模估计的主要估算方法有代码行（LOC/KLOC）和功能点法
COCOMO模型
基本COCOMO模型：
中级COCOMO模型 ：
进度计划
整体进度计划
详细进度计划（主要里程碑）
第七章 质量计划和缺陷估计
软件质量：是指软件产品满足规定的和隐含的需求的能力和有关特征的集合，软件过程质量决定了软件质量。
质量管理
量化质量管理计划
一. 质量管理
1. 软件质量和缺陷
软件质量的定义：我们用已交付软件的故障密度作为软件质量的定义――即，已交付软件中每个单位规模的故障数。
质量管理的任务是规划合理的质量控制任务，然后正确地执行和控制它们，以实现项目的质量目标。
故障排除任务包括需求评审、设计评审、代码评审、单元测试、集成测试、系统测试和验收测试。
2. 质量管理的量化方法
两个关键工作：
设定量化质量目标
量化管理软件开发过程
二. 量化质量管理计划
设定质量目标
质量过程计划
其他阶段的缺陷估计
第八章 风险管理
风险管理（Risk management）试图使由于意外事件而导致项目失败的概率降到最小。
主要包括：
风险评估
风险控制
一. 风险和风险管理概念
什么是风险：风险是那些可能发生的事件或者条件，如果它确实发生了，则它的发生会对项目产生有害的或者负面的影响。另一方面，风险是一种概率事件，可能发生也可能不发生。
风险管理的目标：旨在识别出风险，然后采取措施使它们对项目的影响最小
特点：风险管理是要付出额外的成本；风险管理的价值不容易度量
二. 风险评估
风险识别
识别风险常用的方法：
风险等级划分
根据风险暴露度划分（RE）
RE(r)=Prob (r) *Loss (r)
三. 风险控制
风险管理规划
任务是确定使风险后果最小所需的措施，也称风险缓和措施。
风险监督和跟踪
第九章 项目管理计划
项目管理计划（Project Management Plan----PMP)文档是项目经理承担的所有规划任务的核心。各种规划任务的结果都出现在该文档中，它是指导所有项目执行的基准文档。分四大部分：项目概述，项目计划，项目跟踪，团队。
项目管理计划的主要使用者：
业务主管
项目经理
项目的开发人员
一. 项目概述
项目的起止日期、项目经理、项目目标、与客户的联系、对客户的主要承诺以及所做的假设前提。
二. 项目计划
项目过程
标准过程的描述、剪裁指南、需求变更管理
工作量估计
开发环境
工具
培训计划
质量计划
里程碑
风险管理计划
三. 项目跟踪
任务跟踪
事宜跟踪
客户反馈
状态报告
升级规程
四. 项目团队
项目机构
项目组
角色和职责
第十章 配置管理
软件配置管理（software configuration management, SCM）是项目管理 中专门用于关注系统地控制项目进行中发生的变更的那些部分，由用来识别组织软件产品并控制其修改的一系列活动构成。
一. 配置管理概念
软件配置管理（software configuration management, SCM）是项目管理的一项内容，主要涉及对变更进行系统地控制，建立和维护在项目的整个软件生存周期中软件项目产品的完整性。
主要包括：标识在给定时间点上软件的配置，系统地控制对配置项的更改、并维护在整个软件生存周期中配置的完整性和可跟踪性。
配置管理的功能与机制
配置管理的功能：（1、给出程序的状态；2、给出一个程序的最新版本；3、处理并发更新申请；4、取消一个程序变更；5、防止未授权的变更或者删除；6、提供需求变更申请和程序变更之间的可跟踪性；7、取消一个需求变更；8、显示相关的变更；9、收集当前系统的所有源代码、文档和其他信息。）
配置管理的机制包括：（1、文件命名和组织的约定；2、版本控制；3、变更申请的可跟踪性；4、访问控制；5、协调过程；6、修改登记程序。）
二. 配置管理过程
主要有：
配置规划；
配置执行；
状态监控
配置管理规划和制定
1。标识出典型的配置项
2。SCM人员或者项目经理进行SCM规划。
该阶段的任务 主要有：
执行配置管理
配置控制任务主要有两个：
一个涉及程序的状态转移管理；
另一个涉及必须被实现的变更申请的管理
变更申请的步骤：1、接受变更申请（影响分析之后）；2、建立一种跟踪机制；3、检出需要进行变更的配置项；4、执行变更；5、注册配置项；6、在项目的整个生命期内维护该项目。
状态监督和审计
第11章 评 审
评审是最有效的也是最常用的标识故障的方法，可以对文档及代码进行评审。评审还可以使管理人员掌握项目的进展。
评审的功能及特点：
1、评审可以应用于软件开发各个阶段、产生的各种类型产品——范围广；
2、评审比软件测试更有效率，因为他看到的是问题本身而不是征兆；
3、通过评审不仅可能发现错误，还可以提出对软件产品的改进意见，防止再发生；
4、评审可以在产品开发阶段进行，作者对产品细节很清楚，可以及时修改；
5、不只发现错误，还有利于评审员、软件项目相关组熟悉有关产品。
一. 评审过程
小组评审的几个阶段：
评审规划、
准备和概述、
小组会议、
返工及后续修改
评审规划
标识要评审的产品；
选择评审成员及安排评审时间
作者准备好相应的材料。
概述和准备
1．此阶段的目的：是将要评审的软件包交给评审人员，并在需要时，对工作产品进行说明。
第一次会议；
在正式会议之前，各评审员独立地评审工作产品，作评审日志。
需要准备的材料：评审通知、评审标准、被评审的工作产品、正式的评审记录单、评审检查表、其他资料（如相关文档、标准等）
评审会议
评审会议的目的：最终拿出故障列表
会前检查准备工作；
会议期间提出问题；
会议结束时，给出问题和故障列表。
结论分为：可以通过、不能通过和有条件通过
返工和后续措施
作者执行返工，以改正评审会议上提出的所有故障。
作者与评审主席一起审查改正情况。
二. 数据收集
在评审的各个阶段，数据都要被记录下来，每次评审的总结数据都被保存到一个评审数据库中。
1． 自备日志
2． 小组评审会议日志
3. 小组评审总结报告
三. 监督和控制
监督和控制主要针对评审的效率。
没有效率的评审是对时间和资源的巨大浪费。
第12章 项目监督和控制
项目监督和控制的目的是：建立对项目的实际进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施。
活动包括：对照已文档化的估计和计划，评审和跟踪软件完成情况和结果，基于实际的完成情况和结果调整原有计划。
主要的两个方面的工作：
1。采集关于项目当前状态的信息或数据，并对其进行解释，以便对状态做出判断。
2。采取必要的措施，把项目调整到正确的轨道上来。
数据采集
1。工作量数据
通过日报和周报采集（活动编码），评价项目是否在预算内执行。
2。缺陷数据
缺陷数据库，缺陷类型定义，缺陷级别定义
3。规模测量
一. 项目跟踪
任务跟踪
故障跟踪
问题跟踪
状态报告
1. 任务跟踪
目的是确保任务可以按时完成。
把任务分解成合适的粒度，使其利于跟踪和管理。（1－2天）
任务状态（完成，未完成）
对更高层次的任务，计算低层次的任务完成比例，来得到高层次的任务完成率。
2. 故障跟踪
故障跟踪系统的使用
故障跟踪表及数据库
3. 问题跟踪
问题日志的使用
状态报告
状态报告是定期向高级管理人员和客户通报项目状态的主要机制，目的是为了保证项目继续按计划进展并解决未决的问题。
提供了定期监督项目的机制。
状态报告的主要内容
二. 里程碑分析
管理者监控软件活动，主要通过在所选出的软件工作产品在所选择的里程碑处，将实际的软件规模、工作量、成本和时间表与计划相比较，来确定进展情况。
工作量和进度分析
规模分析
质量监督
与风险有关的监督
1. 工作量和进度分析
设定偏差极限，
实际与计划比较，
分析进度情况，及对以后的影响。
分析指南
2. 规模分析
实际代码规模的分析
实际文档规模分析
定期精炼、监控和调整软件工作产品的整体规模预测
和受影响的组协商对软件工作产品规模估计的更改。
3. 质量监督
计划故障数与实际的故障数相比较，分析结果。
分析指南
4. 与风险有关的监督
里程碑报告应报告当前的风险以及当前的风险缓和措施的状态。
三. 故障分析和预防
故障预防旨在学习至今项目中所发现的故障，以防止项目的其余任务出现类似故障。
1. 执行帕累多分析
分类，统计
排序
找到主要的缺陷
2. 执行因果分析
石川图(鱼骨图)
找到主要原因
3. 制定和实施解决方案
采取措施减少故障发生
四. 过程监督和审计
审计的基本目标是保证遵循已定义的过程，并使高级管理人员监督过程的使用。
定期执行审计。
由其他项目的人员来审计项目。
1。审计过程
计划
策略、审计计划、进度安排
审计
项目计划检查表、需求管理检查表
后续行动
审计分析
13章 软件测试
软件测试是根据软件开发各个阶段的规约和软件的内部结构，精心设计一批软件测试用例，并利用这些测试用例去运行程序，以发现软件中不符合质量特性要求的过程。
目标： 是用尽可能少的时间发现软件产品中尽可能多的错误。
成功的测试：发现了至今为止还没有发现的错误。
软件测试过程可以看成不断进行测试、排错、修改程序和文档。然后再进行测试（回归测试），直到软件达到用户质量特性要求的一个循环往复的过程。
软件测试过程
一个规范的软件测试活动包括:
制定测试计划（内容，进度，环境，培训）
编制测试大纲（针对每个功能的要求）
根据测试大纲设计测试用例（包括测试说明文档）
实施测试
生成测试报告
软件测试原则
应该尽早地、不断地进行软件测试，把软件测试贯穿于开发过程的始终。
所有的测试都应该能追溯到客户需求。
应该从小规模测试开始，并逐步进行大规模测试
应该在测试之前制定出测试计划
根据Pareto原理，80％的错误可能出现在20％的程序中，测试成功的关键是如何找到这20％的模块。
应该由独立的第三方从事测试工作。
对非法和非预期的输入数据也要象合法的和预期的输入数据用例
检查软件是否做了应该做的事情仅是成功的一半，另一半是看软件是否做了不应该做的事情。
在规划测试时，不要设想程序中不会查出错误。
测试只能证明软件中有错误，不能证明软件中没有错误
软件测试方法的分类
1. 按照软件测试的动、静态分类；
静态测试（测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序举行检测）
动态测试（通过运行程序发现错误）
2. 按照软件开发过程的内、外分类
(内)软件开发过程中的测试，按阶段分：
单元测试， 集成测试，系统测试，验收测试
(外)软件产品测试（通常由第三方软件测试机构执行）
功能测试；性能测试；β测试（用户测试），benchmark 测试。
测试用例的设计原则
测试用例是由测试数据和预期结果构成的。一个好测试用例是其极有可能发现至今为止还没有发现的错误。
注重有效性（测试用例应该又两部分组成，输入数据和输出数据，特别对期望的输出要有非常明确的描述。）
注重经济性（要求一个测试用例能够尽可能多的分析软件缺陷）
应为排错提供有效依据
测试用例应考虑多重性（不仅要选用合理的输入数据作为测试用例，也要选用不合理的，最好选边界的数据。）
测试用例设计应分析功能完备性
白盒测试
它是根据程序的内部逻辑而设计测试用例，因此采用白盒测试技术时，必须有设计规约以及程序清单。最彻底的白盒测试时能够覆盖程序中的每一条路径，但当程序中有大量的循环语句后，路径覆盖就不现实了。
白盒测试的测试标准
语句覆盖率：程序中的每一个语句均能在测试用例执行中运行过，以此发现语句汇总的错误或缺陷；这就可能要执行若干个测试用例，一般要求100％语句覆盖。
分支覆盖率：要求执行足够的测试用例，是程序中每一个分叉至少都获得一次“真”值和一次“假”值，即每个分支都执行一次。一般要求80－90％的分支覆盖。（分支覆盖包括语句覆盖）
条件覆盖率：要求执行足够的测试用例，使程序清单中每一个条件获得各种可能的结果，因此，所需要的测试用例更多。一般要求60－80％的条件覆盖。 （条件覆盖包括语句覆盖）
分支/条件覆盖率：要求执行足够的测试用例，使程序清单中每一个条件获得各种可能的结果，并使得每个分支取到各种可能的结果。它似乎比较合理，但实际上并不一定能检查到这种程度。（条件覆盖不一定包括分支覆盖）
条件组合覆盖率：要求执行足够的测试用例，使程序清单中每个分支各种条件组合执行一次，当然，它的要求级别最高，测试用例的设计就更加困难。 （条件组合覆盖包含分支/条件覆盖）
路径覆盖：设计足够多的用例，覆盖所有可能的路径。
黑盒测试
也称为功能测试，主要在集成测试和系统及验收测试阶段，它不关心程序内部逻辑，而只是根据程序功能说明来设计测试用例，以证明每个功能是否符合要求，主要有以下几种方法：
等价分类法：
边界值分析法：
因果图法：
错误探测法：
等价分类法
将所有可能的输入数据，划分为代价的部分，然后从每个部分中选取少数有代表的数据作为测试用例。
等价类分为：有效等价类（合理、有意义）和无效等价类。
新用例选择时，尽可能多的覆盖有效等价类，但每次应只覆盖一个无效等价类。
边界值分析法
是对等价类划分法的一个补充，即选取正好等于、刚刚大于或刚刚小于边界的值为测试数据。
错误探测法
列举出程序中所有可能的错误和容易发生错误的特殊情况，根据他们选择测试用例。（凭经验进行）
因果图
是根据深入条件与输出结果之间的因果关系来设计测试用例，它首先检查输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后，为每种输出条件的组合设计测试用例。
第14章 项目收尾
项目收尾是项目管理的一个阶段。项目收尾主要通过项目收尾分析来完成，是过程改进的绝好机会。
分析的目标是“判断什么是正确的、什么是错误的、什么能有效发挥作用，什么不能，以及以后如何才能做的更好。”
一. 项目收尾分析
收尾分析的作用
执行收尾分析 （SEPG、项目经理等）
收尾分析报告 （与过程相关的通用数据、风险管理、规模、工作量、缺陷、原因分析、过程资产）
二. 归档
项目初始化
需求规格
计划文档
概要设计
程序规格
源代码
和测试相关的文档
验收
手册
配置管理
三. 一个项目分析报告 实例
WAR 分析报告
