王辉老师课程复习

软件过程规范

1.1 过程的定义

1.1.1 过程的定义

1. IEEE-Std-610定义“过程”是为完成一个特定的目标而进行的一系列操作步骤，如软件开发过程。
2. SEI－CMM 定义过程是用于软件开发及维护的一系列活动、方法及实践!

1.1.2 软件过程的分类和组成

1. 软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。
2. 软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。
3. 软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。

1.1.3 软件过程定义的层次性

1.2 过程规范

1.2.1 什么是过程规范

过程规范 就是对输入/输出和活动所构成的过程进行明文规定或约定俗成的标准。
软件过程规范 是软件开发组织行动的准则与指南，可以依据上述各类过程的特点而建立相应的规范，如软件基本过程规范、软件支持过程规范和软件组织过程规范。

1.2.2 过程规范的内容和示例

• 任务规范
• 日常规章制度
• 软件工具

“责任人、参与人员、入口准则、出口准则、输入、输出和活动”等基本内容

1.2.3 过程规范的影响和作用

• 帮助团队实现共同的目标
• 一个规范的软件过程必将能带来稳定的、高水平的过程质量
• 过程规范使软件组织的生产效率更高

1.3 软件生命周期的过程需求

1.3.1 软件工程过程

工程过程是软件系统、产品的定义、设计、实现以及维护的过程。

• 开发过程
• 运行过程
• 维护过程

1.3.2 软件支持过程

• 文档编制
• 配置管理
• 质量保证
• 验证
• 确认
• 联合评审
• 审核（Audit）
• 问题解决

1.3.3 软件管理过程

• 项目管理过程 是计划、跟踪和协调项目执行及生产所需资源的管理过程。项目管理过程的活动，包括软件基本过程的范围确定、策划、执行和控制、评审和评价等。
• 质量管理过程 是对项目产品和服务的质量加以管理，从而获得最大的客户满意度。此过程包括在项目以及组织层次上建立对产品和过程质量管理的关注
• 风险管理过程，在整个项目的生命周期中对风险不断的识别、诊断和分析，回避风险、降低风险或消除风险，并在项目以及组织层次上建立有效的风险管理机制
• 子合同商管理过程，选择合格的子合同商并对其进行管理的过程。

1.3.4 软件组织过程

• 业务规划过程 是为组织与项目成员提供对愿景的描述以及企业文化的介绍，从而使项目成员能更有效地工作。
• 定义过程 是建立一个可重复使用的过程定义库，从而对其它过程等提供指导、约束和支持
• 改进过程 是为了满足业务变化的需要，提高过程的效率与有效性，而对软件过程进行持续的评估、度量、控制和改善的过程。
• 人力资源和培训过程，为项目或其它组织过程提供培训合格的人员所需的活动
• 基础设施过程 是建立生存周期过程基础结构、为其他过程建立和维护所需基础设施的过程。

1.3.5 软件客户－供应商的过程

客户－供应商过程 是内部直接影响到客户、外部直接影响开发、向客户交付软件以及软件正确操作与使用的过程，包括软件获得、客户需求管理、提供软件、操作软件以及提供客户服务等5个子过程

1.4 软件生命周期标准

1.4.1 ISO/IEC标准体系

ISO/IEC15504软件过程评估标准

• 能力确定模式，帮助评估并确定一个潜在软件供应商的能力。
• 过程改进模式，帮助提高软件开发过程的水平。
• 自我评估模式，帮助判断是否有能力承接新项目的开发。

1.4.2 IEEE标准体系

IEEE 1074:1997 - 生命周期过程的标准。
IEEE 1540-01 - 软件风险管理。
IEEE 1517-99 - 软件复用过程。
IEEE 1219-1998 - 软件维护过程。
IEEE Std 730-2001 -软件质量保证计划。
IEEE Std 1012 - 验证与确认。
IEEE Std 1028 - 评审。

1.4.3 标准体系全貌图

1.5 软件过程建模

1.5.1 软件过程模型

• 瀑布模型
• 螺旋模型、增量模型、迭代模型
• V模型
• 极限编程（XP）
• IBM-Rational统一过程（RUP）

瀑布模型

• 又称线性顺序模型或生存周期模型
• W.Royce于1970年首次提出
• 各个阶段的工作顺序展开
• 重要的指导思想：把逻辑设计与物理实现划分开，尽可能推迟程序的物理实现

瀑布模型的优点

• 可强迫开发人员采用规范的方法
• 严格地规定了每个阶段必须提交的文档
• 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证

瀑布模型的缺点

• 不适合需求模糊及需求变化较快的系统

螺旋模型

基本思想
使用原型及其他方法来尽量降低风险。是结合瀑布模型与快速原型模型演变而成。
螺旋模型的每一个周期都包括计划、风险分析、建立原型和用户评审4个步骤。每迭代一次，过程完成一个周期，软件开发前进一个层次，系统生成一个新的版本。
每个螺旋周期的工作步骤及各步骤的任务

• 计划
  确定本轮螺旋的目标、选择方案、设定约束条件

• 风险分析
  评估方案、标识风险和解决风险

• 建立原型
  建立一个原型来实现本轮目标

• 用户评审
  评价该阶段的工作并计划下一个阶段的工作
  螺旋模型主要适用于高风险的大规模项目

V模型

极限编程（XP）

• 极限编程（eXtreme Programming）是由Kent Beck提出的轻量级的、敏捷的软件开发方法。

• XP采用循环迭代的开发方法，将复杂的开发过程分解为一个个相对比较简单的周期。通过积极地交流使开发人员和客户都非常清楚开发的进度、变化、待解决的问题的潜在困难，并根据实际情况及时的调整开发过程。

IBM-Rational统一过程（RUP）

1.5.2 基于UML的过程建模

用户模型视图，从用户的视角来表示系统。用例（Use-case）描述使用场景，可用于用户模型视图的建模方案。
结构模型视图，从系统内部来分析数据和功能，属于静态结构建模。
行为模型视图，描述系统动态或行为方面的各种元素间交互或协作关系，属于动态结构建模。
实现模型视图，针对如何构建（实现）系统的结构和行为时的表示。
环境模型视图，表示待实现的系统环境的结构和行为。

1.5.3 基于IDEF3的过程建模

• 场景描述，通过文档记录由一个组织或系统阐明的一类典型问题的一组情况以及过程赖以发生的、重复出现的背景。场景描述的主要作用，就是要把过程描述的前后关系确定下来。

• 对象，是那些发生在软件开发过程描述中的、任何具体的或概念的事物。对象的识别和特征抽取，有助于进行过程流描述和对象状态转换描述。
  

1.5.4 基于Agent的自适应软件过程模型

过程Agent，实现任务的动态分配和分布式协同。
监控Agent，负责在本地监控任务的实施。
服务Agent，封装了任务实现的方法。
活动Agent，帮助实现过程活动的动态整合。
资源Agent，封装了活动实现的角色和方法。

1.5.5 基于SOA的软件过程模型

面向服务架构（Service-Oriented Architecture，SOA）是企业级的、按需连接资源的新型架构，它描述了一系列模式和指导方针来创建松耦合、依赖业务的服务。

软件过程成熟度

2.1 过程成熟度标准

• 软件过程能力
• 软件过程性能
• 软件过程成熟度

2.1.1 软件过程不成熟的特点

软件过程能力低，不能按预定计划开发出客户满意的产品，项目拖延、费用大大超出预算已成惯例。

过程性能的不可预见性，对进度和预算估计、产品质量的目标缺乏历史数据和有效方法的客观基础，开发的进度、成本和产品的质量都难以预测。

过程的不可视性，软件过程缺乏定义、缺乏文档和缺乏跟踪，在整个软件过程中，不清楚每个阶段进出的标准、执行的方法和规则。

过程的不稳定性，实际的、具体的操作过程是在一个项目开始后临时拼凑而成，每个项目都不一样。

过程的被动性、缺乏改进的主动性。

2.1.2 软件过程成熟的标准

软件过程能力高，具有全组织范围的管理软件开发和维护过程的能力。
软件过程性能可预见性，对进度、预算和质量做出现实的和准确的估计和预测。
软件过程规范化，可遵循的标准、规则和指导性原则。
过程的一致性
过程的丰富性
过程的可视性
过程的稳定性
过程的不断改进

2.2 能力成熟度模型概述

2.2.1 CMM的基本内容

CMM是软件过程能力成熟度模型（Capacity Maturity Model，CMM）的简称。
CMM描述一条从无序的、混乱的过程到成熟的、有纪律的过程的改进途径，描绘出软件组织如何增加对软件开发和维护的过程控制，如何向软件工程和管理的优秀文化演变等方面的指导

2.2.2 系统工程能力模型

国际系统工程委员会（International Council on Systems Engineering，INCOSE）基于各种工程标准为评估系统工程能力建立了对照表。在此期间，该对照表发展为成熟的能力模型，称为系统工程能力评估模型（Systems Engineering Capability Assessment Model，SECAM）。SECAM扩充了连续式模型——软件过程改进和能力确定模型(Software Process Improvement Capability dEtermination，SPICE)的概念，但是比SE-CMM更加明确地注重在系统工程实践上，采用EIA632标准作为过程模型设计参考的基础。

从美国国防工业协会(National Defense Industrial Association, NDIA)的许多大公司来看，IPPD概念是大型软件开发过程模型的基础，并得到国防部（Department of Defense, DOD）的鼎力相助 。

业务的相关人员的参与，这些人员包括顾客、供应商以及产品和产品相关过程的开发者，涉及的业务如测试与评价、制造、支持、培训、销售、采购、财务、合同以及处置过程。

2.3 CMMI

C Capability 能力
M Maturity 成熟度
M Model 模型
I Integration 集成

CMMI是

1. 过程评估的检查单
2. 过程改进的指导书，行业最佳实践
3. 过程审计的依据

CMMI的表达式分为两种

• Staged—阶段式
• Continuous—连续式
  

什么是PA
过程域(PA)：Process Area
简单的说就是做好一个事情的某一个方面，对应软件开发来说，就是做好软件开发的某一个方面。

如何判断一个PA达到要求?
每个PA包含几个目标(Goal),如果这个几个目标都达到要求了，就认为该PA达到要求了。

通用目标(GG): Generic Goal
适用于所有过程。达到了某个方面的通用目标，也就意味着该过程的实施和制度化是有效的、可重复的和持久的。

通用实践(GP): Generic Practice
是一些活动，通用实践适用于所有过程。通用实践提供的是制度化的特性，这些特性将确保过程的实施和制度化是有效的、可重复的和持久的!

特定目标(SG): Specific Goal
特定目标描述为了满足该过程域，必须要执行的一组活动的典型特征。一个特定目标只适用于一个过程域。

特定实践(SP): Specific Practice
是为实现对应的特定目标，所执行的一个或一组活动。

CMMI2级PA-7个
需求管理（REQM）
Requirements Management
管理项目中产品及产品构件的需求，识别项目需求和计划、产品之间的差异。

项目策划（PP）
Project Planning
开发和维护用于定义和指导项目活动的计划。

项目监控（PMC）
Project Monitoring and Control
提供对项目进度和表现状况的理解，当项目表现和计划产生较大偏差的时候，采取相应的改正措施。

供应合约管理（SAM）
Supplier Agreement Management
按照正式的协议，对供应商所提供的产品进行管理。

配置管理（CM）
Configuration Management
创建和维护产品的完整性，包括配置识别，配置控制，配置状态统计，配置审计活动。

过程及产品质量保证（PPQA）
Process and  Product Quality Assurance
向管理层和员工提供产品和过程质量的可见度。

CMMI过程成熟度等级

CMMI分为5个等级

Initial-初始级(1):过程是不可见的
Repeatable-管理级(2)：过程里程碑是可见的
Defined-定义级(3)：过程内部是可见的
Managed–量化管理级(4) ：过程可见性是定量化的
Optimizing-优化级(5) ：可见性的更高等级，自我优化的

** 共有6种能力等级：**

• 0：Incomplete（不完整级）:过程未执行或者执行不完整，特定目标中有不能满足的部分。

• 1：Performed（执行级）： 特定目标都得到满足，基本活动都得到执行。

• 2：Managed（管理级）：已管理的过程除了得到执行外，还需要得到计划，并且按照组织方针来进行实施，相关的人员得到与执行有关的培训，为了过程的执行，分配了相关的资源，生成的工作产品受到控制。

• 3：Defined（定义级）：已定义的过程除了是一个已管理的过程之外，还具有如下的特征：该过程是从组织的标准过程裁剪而来的，裁减的依据是组织的裁剪指南。

• 4：Quantitatively Managed（量化管理级）量化管理的过程除了是已定义的过程之外，还具有如下的特征：过程实施是用统计的以及其他种类的量化手段来进行管理的。

• 5：Optimizing（优化级）：优化的过程除了是一个量化管理的过程之外，还具有如下的特征：过程能够得到及时地变更和采用来满足当前的或者预期的业务目标,优化的过程聚焦于使用增量的和创新技术进步手段来达到不断改进过程性能的目的。

优化的过程除了是一个量化管理的过程之外，还具有如下的特征：
过程能够得到及时地变更和采用来满足当前的或者预期的业务目标。
优化的过程聚焦于使用增量的和创新技术进步手段来达到不断改进过程性能的目的。

能力等级和成熟度等级的对比

2.4 软件过程框架

2.4.1 软件过程环境和过程框架

2.4.2 软件过程文化

• 过程至上，奉过程为教条，一切围绕着过程，组织、质量和效率都服从于过程，过程的执行严格，过程结果可靠、稳定，认为生产的“东西”是过程的一个节点，只是全局的一部分。但效率较低，缺乏灵活性、创造性。

• 以过程为焦点，关注过程，强调过程的重要性，但不拘于过程，让过程服从于质量和效率、服从于组织的业务目标……

• 过程只能起辅助作用，人决定一切, 过程可能流于形式…..

2.4.3 PSP/TSP和CMM组成的软件过程框架

PSP/TSP/CMM之间的关系

软件过程的组织管理

3.1 组织过程焦点

• 1. 执行约定
• 2. 执行能力
• 3. 执行活动
• 4. 测量与分析
• 5. 验证实施

3.2 组织过程定义

组织过程定义的目的是开发和维护一组可用的软件过程财富（software process assets）, 这些财富可以用来改进跨越各个项目的过程性能并为组织的长期发展奠定基础。

组织过程定义-软件过程财富
软件过程财富可用于开发、执行和维护标准软件过程和项目定义软件过程。软件过程财富主要包含如下内容：

• 组织标准软件过程。
• 软件生命周期的描述。
• 过程剪裁指南和准则。
• 组织软件过程数据库。
• 软件过程的有关文档库。

3.3 PSP过程框架和成熟度模型

• PSP过程框架
  PSP过程由一系列方法、表格、脚本等组成，用以指导软件开发人员计划、度量和管理他们的工作。
  

• PSP成熟度模型
  PSP是一个具有4个等级的成熟度框架 。4个等级分别为个体度量过程、个体计划过程、个体质量管理过程和个体循环过程。
  

3.5 TSP— 小组软件过程

TSP解决的主要问题：

• 如何规划和管理一个软件开发团队。
• 如何制订团队工作所需要的策略。
• 如何定义和确定团队中每个角色的职责。
• 如何为团队中每个成员分配不同的角色。

TSP结构

TSP启动过程

TSP工作流程

软件过程的需求管理

软件需求工程

• 业务需求（business requirement)
• 用户需求(user requirement)
• 功能需求(functional requirement)

需求开发

• 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。

需求获取的方法

• 需求研讨会
• 头脑风暴
• 用例模型
• 访谈
• 角色扮演
• 原型法

需求定义

需求定义指的是解释涉众需求,并根据需求规模整理成对要构建系统的明确的说明。

• 前景文档是用一般的语言定义系统特征的文档
• 软件需求规格说明书是用更专业的术语定义系统特征的文档。

软件需求规格说明书

需求确认

为什么需要需求评审？

如何进行需求评审?
（1）分层次评审

• 目标性评审
• 功能性评审
• 操作性评审

（2）分阶段评审
如何保证需求规格说明书的质量

• 正确性
• 完备性
• 易理解性
• 一致性
• 可行性
• 健壮性
• 易修改性
• 易测试性和可修改性
• 易追溯性
• 兼容性

需求跟踪

1.需求的标识
<需求类型><需求#>
需求类型可以是：F=功能需求，D=数据需求，B=行为需求，I=接口需求；O=输出需求。
例：需求标识为F03的需求表示编号为3的功能需求。

2.需求的属性

• 创建需求的时间
• 需求的版本号
• 创建需求的作者
• 负责认可该需求的人员
• 需求状态

3. 需求状态

• 已建议
• 已批准
• 已实现
• 已删除

正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。

逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。

需求追踪矩阵

需求变更控制流程

需求变更控制策略

• 项目启动阶段的变更预防
• 项目实施阶段的需求变更
• 项目收尾阶段的总结

软件过程的项目管理

项目管理概述

• 项目的定义及项目的特性
• 项目的关键要素
• 项目生命周期
• 项目管理
• PMI项目管理知识域
• 项目管理过程
• PMI项目管理过程组

项目管理协会(PMI)的定义：项目是为完成某一独特的产品或服务所做的一次性努力。

项目实际包含3层含义：

1. 项目是一项有待完成的任务，有特定的环境和要求；

2. 项目必须在一定的组织机构内，利用有限资源(人力、物力、财力等)在规定的时间内(指项目有明确的开始时间和结束时间)完成特定目标的阶段性任务；

3. 项目任务要满足一定性能、质量、数量、技术指标等要求。
   项目的特性

• 具有明确的目标
• 具有临时性
• 具有独特性（一次性）
• 具有渐进性
• 具有有限的资源
• 具有风险

项目的关键要素

• 时间
• 成本
• 范围
• 质量

项目的生命周期
项目有时限性，有明确的开始时间和结束时间。项目有其自身的生命周期。
项目生命周期是指项目执行过程中的演化过程。确定了项目的开始和结束，描述了项目从开始到结束所经历的各个阶段。

项目生命周期的特征
成本与人力投入 在开始时较低，在工作执行期间达到最高，并在项目快要结束时迅速回落。

项目管理
项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。
成功的项目管理是指在一定的时间和成本范围内，按一定的质量标准完成项目，并得到客户的认可。

PMI项目管理知识域
Integration Management（整合管理）
包括项目章程和项目计划的制定，指导与管理项目执行，监控项目活动，控制整体需求变更，项目收尾等。
Scope Management（范围管理）
管理项目范围主要在于定义和控制哪些工作应包括在项目内，哪些不应包括在项目内。对项目的范围进行识别、核实和控制。
Time Management（时间管理）
项目时间管理保证项目按时完成。包括项目活动识别、排序、估计，调度和进度控制。
Cost Management（成本管理）
对项目成本进行估算、做预算并进行成本控制。
Quality Management（质量管理）
通过质量控制与质量保证手段，确保项目产品、服务或成果满足用户需求。
Human Resource Management（人力资源管理）
包括分配项目角色，团队组建，团队建设、绩效管理。
Communications Management（沟通管理）
保证通畅而充分的交流。
Risk Management（风险管理）
识别项目风险，在风险分析的基础上缓解风险并对项目风险进行监控。
Procurement Management（采购管理）
项目采购管理包括从项目组织外部采购或获得所需产品、服务或成果的各个过程。包括采购计划、询价、选择供应商以及合同管理。
Stakeholder Management（干系人管理）
识别能影响项目或受项目影响的全部人员、群体或组织，分析干系人对项目的期望和影响，制定合适的管理策略来有效调动干系人参与项目决策和执行。

项目管理过程

管理过程组
PMI（ PMBOK5 ）将47个管理过程归纳为5 类，即5 大项目管理过程组。
启动过程组。获得授权，定义一个新项目或现有项目的一个新阶段，正式开始该项目或阶段的一组过程。

• 规划过程组
• 执行过程组
• 监控过程组
• 收尾过程组

管理过程组之间的关系
各项目管理过程组以它们所产生的输出相互联系；在整个项目期间相互重叠

项目整合管理

• 制定项目章程 (启动过程组)
• 制定项目管理计划 (规划过程组)
• 指导与管理项目执行 (执行过程组)
• 监控项目工作 (监控过程组)
• 实施整体变更控制 (监控过程组)
• 结束项目或阶段 (收尾过程组)

制定项目章程

实施整体变更控制

软件配置管理概念

• 配置
  配置是在技术文档中明确说明最终组成软件产品的功能或物理属性。
• 配置项
  在软件生存周期内所产生的各种应纳入管理范围的系统构成成分。包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等（配置管理的资源对象）
• 基线
  基线是评审过的一个或多个软件配置项，每一个基线都是下一步开发的出发点和基础。

软件配置管理的功能

• 版本控制
• 工作空间管理
• 并行开发支持
• 过程控制
• 构建和发布管理
• 异地开发支持
• 变更请求管理

项目范围管理

• 规划范围管理 (规划过程组)
• 收集需求 (规划过程组)
• 定义范围 (规划过程组)
• 创建工作分解结构 (规划过程组)
• 核实范围 (监控过程组)
• 控制范围 (监控过程组)

创建WBS
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。

项目时间管理

• 规划进度管理 (规划过程组)
• 定义活动 (规划过程组)
• 排列活动顺序 (规划过程组)
• 估算活动资源 (规划过程组)
• 估算活动持续时间 (规划过程组)
• 制定进度计划 (规划过程组)
• 控制进度 (监控过程组)

项目进度网络图

• AOE（Activity on Edge）网络
• AOV（Activity on Vertex）网络

AOE网络
也叫箭线图
这一方法用箭线代表活动，而用节点代表活动的开始和结束。

AOV网络
这一方法用节点（方框）表示活动，而用箭线代表活动之间的关系。
在项目管理中更流行，并且能更好地表示活动之间的关系。

估算活动资源

• 估算活动资源是估算执行各项活动所需的材料、人员、设备或用品的种类和数量的过程。
• 主要作用是，明确完成活动所需的资源种类、数量和特性，以便做出更准确的成本和持续时间估算。
  

估算活动持续时间

• 估算活动持续时间是根据资源估算的结果，估算完成单项活动所需工作时段数的过程。
• 主要作用是，确定完成每个活动所需花费的时间量，为制定进度计划过程提供主要输入。
  

估算活动持续时间的方法

• 专家判断
• 类比估算
  类比估算是一种使用相似活动或项目的历史数据，来估算当前活动或项目的持续时间或成本的技术。
  类比估算通常成本较低、耗时较少，但准确性也较低（相似性，复杂度）
• 三点估算
  通过考虑估算中的不确定性和风险，可以提高活动持续时间估算的准确性。这个概念源自计划评审技术（PERT, Project Evaluation and Review Technique ）。
  最可能时间（tM）。基于最可能获得的资源、最可能取得的资源生产率、对资源可用时间的现实预计、资源对其他参与者的可能依赖及可能发生的各种干扰等，所估算的活动持续时间
  最乐观时间（tO）。基于活动的最好情况，所估算的活动持续时间
  最悲观时间（tP）。基于活动的最差情况，所估算的活动持续时间
  基于持续时间在三种估算值区间内的假定分布情况（β分布），使用公式来计算期望持续时间tE。
  

关键路径法

1. 识别完成项目的所有活动，并估计每个活动的时间及相互关系
   
2. 画出AOV网络图，其中每个节点表示一个活动，并包含活动的名称、持续时间（Duration）、最早开始时间（ES）、最晚开始时间（LS）、最早结束时间（EF）、最晚结束时间（LF），时间余量（Float）。
   
3. 从前向后计算每个活动的最早开始时间及最早结束时间!
   
4. 从后向前计算每个活动的最迟结束时间及最迟开始时间。
   
   5.为每个活动计算时间余量，并确定关键路径。
   
   关键路径：A-C-E-G-H

项目成本管理

• 规划成本管理 (规划过程组)
• 估算成本 (规划过程组)
• 制定预算 (规划过程组)
• 控制成本 (监控过程组)

估算成本的原则
不要作点估计（3）
PERT估算

• 进行3点估计
• 给出区间的置信度
  例子： 基于以下假设，项目以95%的可能性在5-7个月完成，并最有可能在6个月完成
  外包商会按时交付
  没有关键人员流失
  最新的支持文档

PERT估算

估算成本的方法
自顶向下
从整个系统开始，估计整个系统的功能并将之分解到子系统。一旦预计了整个系统的工作量和进度，那么总的估算就被分解到各个模块。
会低估一些项目管理活动的成本（集成管理，文档）

优点：

• 在不知道系统体系结构和具体模块的情况下就可以使用
• 在进行快速的早期估计时很有用
• 可以将集成管理、配置管理、写文档的成本考虑进去

缺点：

• 会低估解决具体技术问题的成本
• 由于缺乏细节而不是很准确
• 估算时产生的错误会传播给每个模块

自底向上
从模块开始，在估计了每个模块的工作量之后，将他们加起来得到最后的估算。
优点：

• 可随着设计或实现的改变而改变
• 能够了解到成本的来源
• 估算错误会局限在局部
• 是一种准确的估算方法

缺点：

• 需要有设计的细节信息
• 耗时
• 估算的准确性依赖于设计的稳定性和团队的技能
• 可能

专家判断
一个或多个在软件开发和应用领域都有经验的专家进行估算。
估算过程迭代多次直到达成共识。

优点：

• 快速，成本低
• 当缺乏细节信息时适合使用
• 缺乏历史数据时是一个好的选择
• 相对准确，如果是真正的专家

缺点：

• 真正的专家很难寻找
• 专家的估算是根据自己的水平来估- 算的，需要根据一般工作人员的水平进行调整

类比估算
优点：

• 使用了相关的历史数据
• 使用简单
• 不需要特定的工具和培训
• 提供一个大概的范围估计

缺点：

• 在项目早期要使用大的组件
• 大组件的历史数据有限
• 需要许多开发数据

控制预算的方法

• 挣值管理（Earned Value Management，EVM）是把范围、进度和资源绩效综合起来考虑，以评估项目绩效和进展的方法。它是一种常用的项目绩效测量方法。
• 计划价值（Planned Value，PV）是为计划工作分配的经批准的预算。它是为完成某活动或工作分解结构组件而准备的一份经批准的预算，不包括管理储备。
• 项目的总计划价值又被称为完工预算（Budget at Completion，BAC）。

挣值管理

• 项目经理既要监测EV的增量，以判断当前的状态，又要监测EV的累计值，以判断长期的绩效趋势。

实际成本（Actual Cost，AC）是在给定时段内，执行某工作而实际发生的成本，是为完成与EV相对应的工作而发生的总成本。
AC没有上限，为实现EV所花费的任何成本都要计算进去。

通过PV，EV，AC可以监测实际绩效与基准之间的偏差
进度偏差（Schedule Variance，SV）
成本偏差（Cost Variance，CV）
进度绩效指数（Schedule Performance Index，SPI）
成本绩效指数（Cost Performance Index，CPI）

进度偏差（Schedule Variance，SV）是测量进度绩效的一种指标，表示为挣值与计划价值之差。SV = EV – PV
进度偏差是一种有用的指标，它是指在某个给定的时点，项目进度是落后还是提前于进度基准。
SV>0 提前
SV=0 基准
SV<0 落后
由于当项目完工时，全部的计划价值都将实现（即成为挣值），所以进度偏差最终将等于零

成本偏差（Cost Variance，CV）它是测量项目成本绩效的一种指标。是某个给定时点的预算亏空或盈余量，表示为挣值与实际成本之差。CV = EV – AC
CV>0 盈余
CV=0 基准
CV<0 超支
项目结束时的成本偏差，就是完工预算（BAC）与实际成本之间的差值。由于成本偏差指明了实际绩效与成本支出之间的关系，所以非常重要。

进度绩效指数（Schedule Performance Index，SPI）是测量进度效率的一种指标，表示为挣值与计划价值之比。 SPI=EV/PV
它反映了项目团队利用时间的效率。
SPI<1 落后
SPI=1 基准
SPI>1 提前
使用SPI（SV）时还需要对关键路径上的绩效进行单独分析，以确认项目是否将比计划完成日期提前或推迟。

成本绩效指数（Cost Performance Index，CPI）是测量预算资源的成本效率的一种指标，表示为挣值与实际成本之比。CPI=EV/AC
用来测量已完成工作的成本效率。
CPI<1 超支
CPI=1 基准
CPI>1 盈余

• 随着项目进展，项目团队可根据现有项目绩效，对完工估算（Estimate at Completion，EAC）进行预测，预测的结果可能与完工预算（BAC）存在差异。如果BAC已明显不再可行，则项目经理应考虑提出变更或采取行动纠正变差。

• 在计算EAC时，通常用已完成工作的实际成本，加上剩余工作的完工尚需估算（Estimate to Complete，ETC）。估算假设
  假设将按预算单价完成ETC工作
  假设以当前CPI完成ETC工作

• 假设将按预算单价完成ETC工作
  EAC = AC + (BAC - EV)
  = BAC + (AC - EV)

• 假设以当前CPI完成ETC工作
  EAC = BAC/CPI

完工尚需绩效指数（To-complete performance index, TCPI）是一种为了达到特定的管理目标（如BAC或EAC），剩余资源的使用必须达到的成本绩效指标。
是剩余工作的成本与剩余预算之比。如果BAC已明显不再可行，则项目经理应考虑使用EAC进行TCPI计算。经过批准后，就用EAC取代BAC。
基于BAC：TCPI =（BAC – EV）/（BAC – AC）
基于EAC：TCPI =（BAC – EV）/（EAC – AC）

例:

• SV, CV, SPI, CPI ?
• EAC ?
• TCPI ?

假设将按预算单价完成ETC工作
EAC = AC + (BAC-EV)
= 1100 + (1500-900)
= 1700

假设以当前CPI完成ETC工作
EAC = BAC/CPI
= 1500/0.82
= 1829

TCPI
基于BAC
TCPI =（BAC – EV）/（BAC – AC）
= (1500-900)/(1500-1100)
= 1.5
目前CPI=0.82，不太可能将CPI从0.82提升至1.5。
基于EAC
EAC = 1700 （假设按计划单价完成剩余工作）
TCPI =（BAC – EV）/（EAC – AC）
= (1500-900)/(1700-1100) = 1.0
EAC = 1829 （假设按目前CPI完成剩余工作）
TCPI =（BAC – EV）/（EAC – AC）
= (1500-900)/(1829-1100) = 0.82

风险管理

风险指损失的可能性。风险具有两大属性：可能性和损失。可能性是风险发生的概率。损失是指预期与后果之间的差异。

项目风险是指由于项目所处的环境和条件本身的不确定性，和项目业主/客户/项目组织或项目的某个当事者主观上不能准确预见或控制的因素影响，使项目的最终结果与当事者的期望产生背离，并存在给当事者带来损失的可能性。

项目风险管理

• 规划风险管理 (规划过程组)
• 识别风险 (规划过程组)
• 定性风险分析 (规划过程组)
• 定量风险风险 (规划过程组)
• 规划风险应对 (规划过程组)
• 监控风险 (监控过程组)

风险管理计划的内容

风险列表示例

软件过程的质量管理

项目质量管理

软件质量

• 软件质量定义
• 质量保证与质量控制

质量模型

• ISO9000
• CMMI

软件项目质量管理

• 规划质量
• 实施质量保证
• 实施质量控制

质量保证与质量控制

质量保证（Quality assurance）
为使人们确信软件质量满足用户需要所必须的全部有计划有组织的活动。
关注于过程改进。

质量控制（Quality control）
对开发过程中的软件产品的质量特性进行连续的收集和反馈，通过质量管理和配置管理等机制,使软件开发过程向着既定的质量目标发展。
关注于项目软件产品。
共同点：
QC和QA都是为了保证产品的质量，都需要进行验证
区别：
QC和QA的主要区别前者是保证产品质量符合规定；后者是建立体系并确保体系按要求运作，以提供内外部的信任。
QA独立于QC之外，QA审查项目的质量控制是否按照指定的体系来完成。

质量管理八大原则

• 以顾客为中心
• 领导作用
• 全员参与
• 过程方法
• 系统的管理方法
• 持续改进
• 基于事实的决策方法
• 互利的供方关系

质量管理

• 规划质量管理 (启动过程组)
• 实施质量保证 (实施过程组)
• 实施质量控制 (执行过程组)

制定质量计划的方法和技术

• 成本效益分析
• 质量成本（COQ）
• 七种基本质量工具
• 标杆对照
• 实验设计
• 统计抽样

评审的内容

• 管理评审
• 技术评审
• 文档评审
• 过程评审

评审方法

• 临时评审（Ad hoc review）
• 轮查（Passroud）
• 走查（Walkthrough）
• 小组评审（Group Review）
• 审查（Inspection）

度量

进行度量工作，是为了了解产品开发的技术过程和产品本身。

• 度量开发过程的目的是为了改进过程。
• 度量产品的目的是为了提高产品的质量。
• 度量的作用是为了有效地进行定量管理。

基本指标（直接度量）
计算指标（间接度量）

质量度量
缺陷发现率 —— bug/KLOC
KLOC是指千行代码，而bug/KLOC的意思是每千行代码平均产生的缺陷数量 。

软件过程质量度量

• 软件需求过程的质量度量
• 软件过程生产率的度量
• 测试阶段的过程质量度量
• 维护阶段的过程质量度量

软件需求过程的质量度量
需求一致性度量
Q1 ＝ nui /nr
nui是所有复审者都有相同解释的需求数目
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, Test Case Depth）

• 每KLOC的测试用例数
• 每个功能点/对象点的测试用例数

测试用例的有效性

• 每100或1000个测试用例所发现的缺陷数

测试用例的质量（TCQ, Test Case Quality）

• 测试用例发现的缺陷数量/总的缺陷数量

测试执行的效率和质量

• 每个人日所执行的测试用例数
• 每个人日所发现的缺陷数
• 每修改的KLOC所运行的测试用例数

缺陷报告的质量

• 报告的质量不高的缺陷数/报告的总缺陷数
  质量不高的缺陷包含：
  1）状态为“需要补充信息”的缺陷
  2）状态为“不是缺陷”的缺陷

维护阶段的过程质量度量

• 平均失效时间MTTF (mean time to failure)
• 基于时间缺陷 (或用户问题数) 的到达率
• 积压缺陷管理指标 (BMI)
• 软件成熟度指标 (SMI)