软件项目管理期末复习（看这一篇就够了）

软件项目管理考试复习

加了的是考点

第一章软件项目管理概述

1.1.1项目及其特征

项目定义：

• 项目就是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力；
• 是以一套独特而互相联系的任务为前提，有效地利用资源，在一段时间内满足一系列特定目标的多项相关工作的总称。

日常运作和项目的区别：

1. 项目是一次性的，而日常运作是重复进行的。
2. 项目是以目标为导向的，日常运作是通过效率和有效性体现的。
3. 项目是通过项目经理及其团队工作完成的，日常运作是职能式的线性管理。
4. 项目存在大量的变更管理，日常运作基本保持持续的连贯性。

项目特征：

1. 目标性。
2. 相关性。
3. 临时性。
4. 独特性。
5. 资源约束性。
6. 不确定性。
7. 结果不可逆性。（早期教材中有）

1.1.3软件项目

特点：

1. 软件是一种逻辑实体而非具体的物理实体，具有抽象性，这使软件与其他的诸如硬件或者工程类项目有很多的不同之处。
2. 软件的生产与硬件不同，开发过程中没有明显的制造过程，也不存在重复生产过程。
3. 软件没有硬件的机械磨损和老化问题，然而，软件存在退化问题。在软件的生存期中，软件环境的变化导致软件的失效率提高。
4. 软件的开发收到计算机系统的限制，对计算机系统有不同程度的依赖。
5. 软件开发至今没有摆脱手工的开发模式，软件产品基本上是“定制的”，无法利用现有的软件组装成所需要的软件。
6. 软件本身是复杂的，其复杂性来自应用领域实际问题的复杂性和应用软件技术的复杂性。
7. 软件的成本相当高昂，软件开发需要投入大量资金和高强度的脑力劳动，因此成本比较高。
8. 很多软件工作涉及社会的因素，例如，许多软件开发受到机构、体系和管理方式等方面的限制。

软件项目是一种特殊的项目，她所创造的唯一产品或服务是逻辑载体，没有具体的形状和尺寸，只有逻辑的规模和运行的效果。

1.3.1项目管理的知识领域

1. 项目集成管理
2. 项目范围管理
3. 项目进度管理
4. 项目成本管理
5. 项目质量管理
6. 项目资源管理
7. 项目沟通管理
8. 项目风险管理
9. 项目采购管理
10. 项目干系人管理

1.3.2项目标准化过程组

1. 启动过程组：

   ​ 主要确定一个项目或一个阶段可以开始了，并要求着手实行；定义和授权项目或者项目的某个阶段

2. 计划过程组：

   ​ 为完成项目所要达到的商业要求而进行的实际可行的工作计划的设计、维护，确保实现项目的既定商业目标。计划基准是后面跟踪和监控的基础。

3. 执行过程组：

   ​ 根据制定的基准计划，协调人力和其他资源，执行项目管理计划或相关的子计划。执行过程存在两个方面的输入，一个是根据原来的基准来执行，另一个是根据监控中发现的变更来执行。主要变更必须在整体变更控制得到批准后才能够执行。

4. 控制过程组：

   ​ 通过监督和检测过程确保项目达到目标，必要时采取一些修正措施。集成变更控制是一个重要的过程。

5. 收尾过程组：

   ​ 去的项目或阶段的正式认可并且有序地结束该项目或阶段。向客户提交相关产品，发布相关的结束报告，更新组织过程资产并释放资源。

关系：

​ 各个过程通过其结果进行连接，一个过程组的结果或输出是另一个过程组的输入。其中，计划过程组、执行过程组和控制过程组是核心管理过程组。

1.5.2敏捷宣言

4个核心价值：

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

12个敏捷原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。（持续交付）
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。（拥抱变化）
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。（时间盒）
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。（客户合作）
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。（信任团队）
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。（沟通方式，个体与互动）
7. 可工作的软件是进度的首要度量标准。（交付产品价值，可工作的软件）
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。（团队节奏）
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。（持续改进）
10. 以简洁为本，它是极力减少不必要工作量的艺术。（简洁）
11. 最好的架构、需求和设计出自自组织团队。（自组织，自管理）
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。（检视与调整）

第一章课后习题

第二章项目确立

2.2项目立项

2.2.1立项流程

立项阶段:

明确项目的目标、时间表、项目使用的资源和经费，而且得到项目发起人的认可。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S4qwFacL-1652110626063)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509174335486.png)]

2.2.2自造-购买决策

在立项阶段，产品负责人进行自造-购买决策，确定待开发产品的哪些部分应当采购、外包开发或自主研发。

流程如下：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gkhdn1sC-1652110626064)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509174623462.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yrSNeH2b-1652110626065)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509174650230.png)]

2.3项目招投标

我们来梳理下甲方和乙方两者各自的区别：

甲方（需方） —— 提供需求方，一般是企业，作为客户。

乙方（供方） —— 满足需求方，一般是软件开发商。

甲方和乙方的职责：

甲方（需方） —— 招标书定义，供方选择，合同签署。

乙方（供方） —— 项目分析，竞标，合同签署。

2.4项目章程

项目章程，也可以称为是授权书。它包含以下两个部分：

（1） 一份正式批准项目并且授权项目经理在项目活动中使用组织资源的文件。

（2） 确认项目存在的文件，包括对项目的确认、对项目经历的授权和项目目标的概述等。

2.4.3项目经理的能力和职责

能力：

• 领导力
• 技术项目管理
• 战略和上午管理

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0skzalEG-1652110626068)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509175310809.png)]

职责：

• 开发计划
• 组织实施
• 项目控制

第二章课后习题

第三章生存期模型

软件生存期模型的基本特征：

• 描述开发的主要阶段
• 定义每一个阶段要完成的主要过程和活动
• 规范每一个阶段的输入和输出

3.1.2生存期模型的类型

生存期的模型的分类有以下四种，分别是：

• 预测型 —— 需求固定，项目活动只执行一次，提交一次，目标是成本可管理。
• 迭代型 —— 需求变化，重复执行直到正确为止，提交一次，目标是得到正确的解决方案。
• 增量型 —— 需求变化，特定增量的活动只执行一次，频繁地小增量提交，以速度为目标。
• 敏捷型 —— 需求变化，重复执行知道正确为止，频繁地小增量提交，通过频繁提交和反馈来体现客户价值。

选择生存期模型的步骤如下：

①熟悉各种生存期模型→②评审、分析项目的特性→③选择适合项目的生存期模型→④表示生存期模型与项目不一致地方，并进行裁减。

3.2预测型生存期模型

提前进行大量计划工作，然后一次性执行；执行是一个连续的过程。

3.2.1瀑布模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OTxGdXfO-1652110626073)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509180419153.png)]

只能从上往下，不能返回。编码阶段不能修改需求和设计。

优点：

管理方便，只需要严格控制项目的执行顺序。

缺点：

项目的可变性无法适应瀑布模型的要求。

适用范围：

一般对需求很明确，且方案也很明确的项目使用，短期项目比较适应。

3.2.2v模型

V模型是瀑布模型的一个变种，但强调测试与开发的利益关系，对系统性能、安全等有严格要求。

3.3.迭代型生存期模型

运行对未完成的工作进行反馈，从而改进和修改该工作

原型模型：

通过构建不断构造原型来设计方案，最后确定了项目需求和系统设计。

优点：

可以应对需求的变化

适用范围：

适应于需求不明确，复杂度高，变更频繁的项目b

3.4增量型生存期模型

不同时开发项目需求，而是将需求分段，使其成为一系列增量产品，每一个增量可以分别实施。

每一个增量都是一个可交付成果，第一个往往是实现基本需求的核心产品。

①需求基本明确，但也有可能发生变化；②对于市场和用户把握需要逐步了解；③系统改造需要一步步实施。

适用范围：

• 对已有的产品升级或者新版本开发
• 对于完成期限要求严格的产品
• 对于所开发的领域比较熟悉而且已经有原型模型
• 对市场和用户把握不是很准

渐进式阶段模型

渐进式阶段模型是一种特殊的增量型生存期模型，每一个增量就是一个比较完整的系统

优点：

• 阶段式提交一个可运行的产品，而且每个阶段提交的产品是独立的系统
• 关键的功能更早出现，可以提高开发人员和客户的信心
• 通过阶段式的提交，可以早期预警问题，避免后期发现问题的高成本
• 通过阶段式提交可以运行的产品来说明项目的实际进展，减少项目报告的负担
• 阶段性完成可以减少估计失误，因为通过阶段完成的评审，可以重新估算下一阶段的计划
• 阶段性完成均衡了弹性与效率，提高开发人员的效率和士气

缺点：

• 需要精心规划各个阶段的目标
• 每一个阶段提交的是正式版本，所以工作量会增加

3.5敏捷型生存期模型

3.5.1Scrum

核心是迭代和增量

一个迭代就是一个Sprint（冲刺），Sprint的周期被限制在一个月左右。Sprint是Scrum的核心。

• 团队角色
  • 产品负责人
  • Scrum主管
  • 开发团队
• 工件
  • 增量
  • 产品待办事项列表
  • Sprint待办事项列表
  • 燃尽图
• Scrum活动
  • 产品待办事项列表梳理
  • Sprint计划会议
  • 迭代式软件开发
  • 每日站立会议
  • 持续集成
  • Sprint评审会议
  • Sprint回顾会议

第三章课后习题

第四~五章软件项目范围计划

软件需求是值用户对软件的功能和性能要求，就是用户希望软件能做什么事情，完成什么功能，达到什么样的性能。软件需求的层次有以下三个方面的内容：

业务需求→用户需求→功能需求

4.2需求管理过程

可以保证软件需求以一种形式描述一个产品应该具有的功能、性能等。需求过程的一个重要活动是系统需求，并建立相应的文档，好处是在开发后期和整个维护阶段的返工的工作量可以大大减少。

软件需求管理过程包含两个方面的内容，分别是需求开发和需求管理。

需求开发的路径是：需求获取→需求分析→需求规格编写→需求验证；而需求管理指的是：需求变更。

4.2.1需求获取

软件的需求具有模糊性、不确定性、变化性和主观性的特点。

首先我们要先分析用户的要求，分析完成之后，那么我们就要去获取这个用户的要求，并让软件去实现它。随之，软件就得到了软件需求。如下图所示：

4.2.2需求分析

任务是借助当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统”做什么“的问题

需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 如下图所示：

4.2.3需求规格编写

需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。

4.2.4需求验证

在确定了需求之后，我们需要进行以下验证：

• 需求是正确的吗？正确性
• 需求是一致的吗？一致性
• 需求是完全的吗？完整性
• 需求是实际可行的吗？可行性
• 需求是必要的吗？必要性
• 需求是可检验的吗？可检验性
• 需求是可跟踪的吗？可跟踪性
• 最后的签字

4.2.5需求变更

是软件项目一个突出的特点，也是软件项目最为普遍的一个特点，是导致项目失败的主要原因之一

在软件的某些周期，我们总会遇到需求变更的问题。那对于需求变更来说，主要需要了解以下内容。

需求变更管理的主要工作有：

• 建立需求基线
• 确定需求变更控制过程
• 建立变更控制委员会 (SCCB)
• 进行需求变更影响分析
• 跟踪所有受需求变更影响的工作产品
• 建立需求基准版本和需求控制版本文档
• 维护需求变更的历史记录
• 跟踪每项需求的状态
• 衡量需求稳定性

需求变更控制流程

• 

4.3软件需求分析方法

4.3.1原型分析方法

原型分析方法是一种需求模型建模方法，需要经过三个步骤，分别是需求分析→原型方法→原型评价。如下图所示：

结构化分析法（基于数据流建模）

（1）定义

• 20世纪70年发展起来的面向数据流的方法
• 是一种自顶向下逐步求精的分析方法
• 根据软件内部数据传递、变换的关系进行分析的
• 是结构化分析的主要方法

（2）结构化分析方法的技术

• 数据流图 (DFD)
  • 是一种描述软件系统逻辑模型的图形符号，无法判断活动的时序顺序
• 数据字典 (DD)
  • 用来描述系统中涉及的每个数据，是数据描述的集合，通常和DFD配合使用
• E-R 图
  • 用来描述系统需求要存储的数据信息
• 系统流程图
  • 表示操作顺序和信息流动过程的图标

3、面向对象的用例分析法（基于UML建模）

（1）定义

• 基于面向对象的情景分析方法
• 从用户角度出发考虑的功能需求
• 用例是系统向用户提供一个有价值的结果的某项功能
• 功能规范说明可以描述为对“需要系统做什么”的问题回答。
• 用例分析可以通过在该问题中添加几个字来描述：“需要该系统为每个用户做什么”

（2）UML需求视图

• 用例视图 - Use case Diagram
• 顺序图 - Sequence Diagram
• 状态图 - State Diagram
• 活动图 - Activity Diagram

4.3.4基于功能列表的实例

现在，我们来看一个基于功能列表的实例。如下图所示：

4.4敏捷项目需求分析

4.4.3用户故事

敏捷分析法包含以下三个部分，分别是：

• 用户故事模板

  As a,
  I want,
  So that.
  123
  

  用户故事常常写在卡片上，然后将其部署到墙上，便于讨论。

• 评价用户故事

• 用户故事迭代优先级

  第一组：
  ①must have;②should have;③could
  第二组：
  have/want to have
  

5.1任务分解定义

5.1.1WBS

（1）定义

• 任务分解指的是将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。

（2）WBS和工作包

• WBS ，即 Work Breakdown Structure ，表示任务分解结构。WBS 是任务分解的结果。
• 工作包，是 WBS 最低层次的可交付结果，是 WBS 的最小元素。

（3）WBS和工作包的区别

WBS 和工作包的区别如下：

• WBS 是对项目由粗到细的分解过程；
• WBS 是面向交互结果的；
• 同时，WBS 组织定义了整个项目范围；
• 而工作包是 WBS 中最低层次的可交付成果（如下图所示）；
• 且工作包应当由唯一主体负责。

5.1.3任务分解的形式

任务分解主要有两种形式，分别为：

• 提纲式WSB

  • 将任务分解的结果以清单的表述形式进行层层分解的方式

  • 类似于下方这样：

    1 变化计数器
          1.1 比较两个版本的程序
             1.1.1
             1.1.2
             1.1.3
            1.2 找出修改后的程序中增加和删除的代码行
               1.2.1
               1.2.2
            1.3 统计修改后的程序中增加和删除的代码行数
               1.3.1
               1.3.2
    

• 图表形式WBS（组织机构图式WBS）

• • 以图表的形式进行层层分解的方式
  • 

5.2.1任务分解过程

五大步骤

任务分解的过程要经过三个过程，输入→分解→ WBS 。有以下步骤：

• 确认并分解项目的主要组成要素
• 确认分解标准
• 确认分解是否详细
• 确认项目交付成果（可以编写 WBS 字典 ）
• 验证分解正确性

分解标准

任务分解的过程有两大标准，分别是：

• 分解标准应统一；
• 不能同时使用两种标准进行分解。

5.2.2任务分解方法

任务分解有4种方法，分别是：

• 模板参照
  • 用该项目的领域WBS参照分解
• 类比
  • 有些项目在某种程度上具有相似性；
  • 可以采用类似的 WBS 作为参考。
• 自顶向下
  • 最好的方法
  • 
• 自底向上
  • 如果对于项目人员来说，这个项目是一个崭新的项目，则可以采用自底向上方法开发WBS
  • ​

5.3任务分解结果

（1）检验分解结果标准

• 最底层要素是否是实现目标的充分必要条件；
• 最底层要素是否有重复的；
• 每个要素是否清晰完整定义；
• 最底层要素是否有定义清晰的责任人；
• 是否可以进行成本估算和进度安排。

（2）WBS任务分解建议

• 最低层是可控的和可管理的，但是不必要过细；
• 每个Work package 必须有一个提交物；
• 定义任务完成的标准；
• 有利于责任分配；
• 推荐任务分解到40小时以内。

5.3.2任务分解的重要性

WBS重要性：

• WBS明确了完成项目所需的工作
• WBS建立时间观念
• WBS提供了一种控制手段
• WBS是范围基线的重要组成部分
• WBS可以即使提示是否更变

第四五章课后习题

第六章软件项目成本计划

6.1.2成本估算的定义

• 成本估算是成本管理的核心，是预测开发一个软件系统所需要的总工作量的过程。
• 软件项目成本是指软件开发过程中所花费的工作量及相应的代价。
• 成本估算应该以软件项目管理、分析、设计、编程、测试等过程所花费的代价作为依据。
• 成本估算贯穿于软件的生命周期。

估算的基本概念

1、关于估算

• 估算不是很准确，会有误差；
• 项目经验数据非常重要；
• 不要太迷信某些数学模型。

2、软件项目规模

• 软件项目规模即工作量；
• 例如：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。

3、软件规模单位

• LOC (Line of Code) → 表示源代码长度的测量；
• FP (Function Point) → 用系统的功能数量来测量；
• 人月；
• 人天；
• 人年。

4、软件项目成本

• 完成软件规模相应付出的代价；
• 待开发的软件项目需要的资金；
• 人的劳动的消耗所需要的代价是软件产品的主要成本。

5、成本单位

成本单位通常是各种货币单位，比如：

• 人民币元
• 美元
• 英镑
• ……

6、软件规模和软件成本的关系

• 规模是成本的主要因素，是成本估算的基础；
• 有了规模就确定了成本。

7、成本估算结果

直接成本： 与具体项目相关的成本（如：人员工资、材料费、外包外购成本等）

间接成本： 可以分摊到各个具体项目中的成本（如：培训、房租水电、员工福利、市场费用、管理费、其他等等）

项目成本的组成

直接成本：

与开发的项目具体直接相关的成本（如人员的工资、材料费、外包外购成本等）

间接成本：

不能归属于一个具体的项目，是企业的运营成本，可以分摊到各个具体项目中的成本（如房租、水电、员工福利、税收等）

6.1.3成本估算过程

1、估算输入

需求、资源要求、资源消耗率、进度规划、历史项目数据、学习曲线等

2、估算处理

采用一定的估算方法进行，包含直接成本和间接成本的估算。

3、估算输出

以简略或详细的形式表示，对项目所需的所有资源的成本均需要加以估计。

6.2成本估算方法

1、代码行估算法

（1）定义

• 从软件程序量的角度定义项目规模。
• 与具体的编程语言有关。
• 分解足够详细。
• 有一定的经验数据（类比和经验方法）。

（2）代码行估算的优点

代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。

（3）代码行估算的缺点

• 对代码行没有公认的可接受的标准定义。
• 代码行数量依赖于所用的编程语言和个人的编程风格。
• 在项目早期、需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。
• 代码行强调编码的工作量，只是项目实现阶段的一部分。

2、功能点估算法（重点）

（1）定义

• 与实现的语言和技术没有关系；
• 用系统的功能数量来测量其规模；
• 通过评估、加权、量化得出功能点。

（2）功能点公式

• FP = UFC * TCF
• UFC：未调整功能点计数
• TCF：技术复杂度因子

（3）UFC-未调整功能点计数

从处理逻辑的角度出发， UFC 可以分为 5 个功能计数项。分别是：

• 外部输入
• 外部输出
• 外部查询
• 外部接口文件
• 内部逻辑文件

接下来我们将依据这 5 个功能计数项进行详细细述。

（4）功能计数项详述

1）外部输入(External Inputs:EI)

给软件提供面向应用的数据的项（如屏幕、表单、对话框、控件，文件等）；在这个过程中，数据穿越外部边界进入到系统内部。 如下图所示：

2）外部输出(External Outputs:EO)

向用户提供（经过处理的）面向应用的信息，例如，报表和出错信息等。 如下图所示：

3）外部查询(External Inquiry:EQ)

外部查询是一个输入引出一个即时的简单输出，没有处理过程。 如下图所示：

4）外部接口文件（External Interface Files :EIF’s）

用户可以识别的一组逻辑相关数据，这组数据只能被引用。用这些接口把信息传送给另一个系统。 如下图所示：

5）内部逻辑文件(Internal Logical Files:ILF’S)

用户可以识别的一组逻辑相关的数据，而且完全存在于应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目。 如下图所示：

（5）功能计数项的复杂度等级

下面给出功能计数项的复杂度等级，如下图所示：

（6）UFC计算实例

下面，我们用一个例子来举例。

某外贸订单项目的需求评估为：

外部输入： 3 项；外部输出： 1 项；外部查询： 1 项；外部接口文件： 1 项；内部逻辑文件： 2 项。请计算出该项目的 UFC 。

他们的复杂程度如下表所示：

		功能点
项	简单	一般	复杂
外部输入	2 * 3	1 * 4	0 * 6
外部输出	0 * 4	0 * 5	1 * 7
外部查询	0 * 3	1 * 4	0 * 6
外部接口文件	0 * 5	1 * 7	0 * 10
内部逻辑文件	1 * 7	1 * 10	0 * 15
总计	13	25	7
UFC	45

（7）TCF-技术复杂度因子

TCF = 0.65 + 0.01(sum(Fi))，其中 Fi 为技术复杂度因子，其范围是 0-5 ， TCF 的取值范围是 0.65-1.35 。

Fi 技术复杂度因子有 14 项，如下表所示：

	技术复杂度因子
F1	可靠的备份和恢复	F2	数据通信
F3	分布式函数	F4	性能
F5	大量使用的配置	F6	联机数据输入
F7	操作简单性	F8	在线升级
F9	复杂界面	F10	复杂数据处理
F11	重复使用性	F12	安装简易型
F13	多重站点	F14	易于修改

技术复杂度因子的取值范围，如下表所示：

调整系数	描述
0	不存在或者没有影响
1	不显著的影响
2	相当的影响
3	平均的影响
4	显著的影响
5	强大的影响

（8）TCF计算实例

同样，我们用外贸订单项目的例子来计算 TCF 。假设 14 个复杂度因子的影响值都是平均，计算出该项目的功能点。

① U F C = 45 UFC=45UFC=45

② T C F = 0.65 + 0.01 ( 14 ∗ 3 ) = 1.07 TCF=0.65+0.01(143)=1.07TCF*=0.65+0.01(14∗3)=1.07

③ F P = U F C ∗ T C F = 45 ∗ 1.07 = 48 FP=UFCTCF=451.07=48F**P=UFC∗TCF=45∗1.07=48

④ 如 果 P E = 15 工 时 / 功 能 点 ， 那 么 ： E f f o r t = 48 ∗ 15 = 720 工 时 如果PE=15工时/功能点，那么：Effort=4815=720工时如果PE*=15工时/功能点，那么：*Effort*=48∗15=720工时

（9）功能点与代码行的转换

语言	代码行/FP
Assembly	320
C	150
COBOL	105
FORTRAN	105
PASCAL	91
ADA	71
PL/1	65
PROLOG/LISP	64
SMALLTALK	21
SPREADSHEET	6

3、用例点估算法（重点）

（1）图例

用例模型如下图所示：

（2）基本步骤

用例点估算方法的基本步骤为：

• 计算未调整的角色的权值 UAW ;
• 计算未调整的用例的权值 UUCW ;
• 计算未调整的用例点 UUCP ;
• 计算技术和环境因子 TCF 和 ECF ;
• 计算调整的用例点 UCP ;
• 计算工作量 ( man－hours ) 。

接下来将依据这几个内容进行展开介绍。

（3）计算未调整的角色的权值UAW

公式： U A W = ∑ C = c a W e i g h t ( c ) × a C a r d i n a l i t y ( c ) UAW=∑_{C=c}aWeight© × aCardinality©UAW=∑C=caWeigh**t(c)×aCardinalit**y(c)

下面给出 Actor 权值定义表，如下表所示：

序号	复杂度级别	复杂度标准	权值
1	simple	角色通过API与系统交互	1
2	average	角色通过协议与系统交互	2
3	complex	用户通过GUI与系统交互	3

（4）计算未调整的用例的权值UUCW

公式： U u c w = ∑ C = c u W e i g h t ( c ) × u C a r d i n a l i t y ( c ) Uucw=∑_{C=c}uWeight© × uCardinality©Uuc**w=∑C=cuWeigh**t(c)×uCardinalit**y(c)

下面给出 Use Case 权值定义表，如下表所示：

序号	复杂度级别	事务/场景个数	权值
1	simple	1-3	5
2	average	4-7	10
3	complex	>7	15

（5）计算未调整的用例点UUCP

公式： U U C P = U A W + U U C W UUCP=UAW+UUCWUUC**P=UAW+UUC**W。例如：

表1： Actor 权值

序号	复杂度级别	权值	参与角色数	UAWi
1	simple	1	2	2
2	average	2	4	8
3	complex	3	5	15

表2：Use Case 权值

序号	复杂度级别	权值	用例数	UUCWi
1	simple	5	5	25
2	average	10	2	20
3	complex	15	3	45

（6）计算技术因子TCF

公式： KaTeX parse error: Expected group after ‘_’ at position 19: …=0.6+(0.01×\sum_̲\limits{i=1}^{1…_W e i g h t i × V a l u e i Weight_i×Value_iWeighti×Value**i 。

假设现有某项目的复杂度因子如下图表所示：

序号	技术因子	说明	权值
1	TCF1	分布式系统	2.0
2	TCF2	性能要求	1.0
3	TCF3	最终用户使用效率	1.0
4	TCF4	内部处理复杂度	1.0
5	TCF5	复用程度	1.0
6	TCF6	易于安装	0.5
7	TCF7	系统易于使用	0.5
8	TCF8	可移植性	2.0
9	TCF9	系统易于修改	1.0
10	TCF10	并发性	1.0
11	TCF11	安全功能特性	1.0
12	TCF12	为第三方系统提供直接系统直接系统访问	1.0
13	TCF13	特殊的用户培训设施	1.0

具体的 TCF 值为：

T C F = 0.6 + 0.01 × ( 2.0 × 3 + 1.0 × 5 + 1.0 × 3 + 1.0 × 5 + 1.0 × 0 + 0.5 × 3 + 0.5 × 5 + 2.0 × 3 + 1.0 × 5 + 1.0 × 3 + 1.0 × 5 + 1.0 × 0 + 1.0 × 0 ) = 1.02 TCF=0.6+0.01×(2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+0.5×3+0.5×5+2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+1.0×0)=1.02TCF=0.6+0.01×(2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+0.5×3+0.5×5+2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+1.0×0)=1.02

其中，调整系数为给定数值。

（7）计算环境因子ECF

公式： KaTeX parse error: Expected group after ‘_’ at position 20: …1.4+(-0.03×\sum_̲\limits{i=1}^{8…_W e i g h t i × V a l u e i ) Weight_i×Value_i)Weighti×Value**i) 。

假设现有某项目的环境因子如下表所示：

序号	环境因子	说明	权值
1	ECF1	UML 精通程度	1.5
2	ECF2	系统应用经验	0.5
3	ECF3	面向对象经验	1.0
4	ECF4	系统分析员能力	0.5
5	ECF5	团队士气	1.0
6	ECF6	需求稳定度	2.0
7	ECF7	兼职人员比例高低	1.0
8	ECF8	编程语言难易程度	1.0

假设调整系数已给定，那么具体的 ECF 值为：

E C F = 1.4 + ( − 0.03 × ( 1.5 × 3 + 0.5 × 3 + 1.0 × 3 + 0.5 × 5 + 1.0 × 3 + 2.0 × 3 + 1.0 × 0 + 1.0 × 0 ) ) = 0.785 ECF=1.4+(-0.03×(1.5×3+0.5×3+1.0×3+0.5×5+1.0×3+2.0×3+1.0×0+1.0×0))=0.785ECF=1.4+(−0.03×(1.5×3+0.5×3+1.0×3+0.5×5+1.0×3+2.0×3+1.0×0+1.0×0))=0.785

（8）计算调整的用例点UCP

公式： U C P = U U C P × T C F × E C F UCP=UUCP×TCF×ECFUCP=UUC**P×TCF×ECF 。

依据上面所给出的结果，那么最终 U C P = U U C P × T C F × E C F = 115 × 1.02 × 0.785 = 92 UCP =UUCP×TCF×ECF = 115×1.02×0.785 = 92UCP=UUC**P×TCF×ECF=115×1.02×0.785=92。

（9）计算工作量

公式： E f f o r t = U C P × P E Effort=UCP×PEEffor**t=UCP×P**E 。

依据上面的数据，假设 PE=20工时/用例点 。那么： E f f o r t = U C P × P E = 92 × 20 = 1840 工 时 = 230 人 天 Effort=UCP×PE=92×20=1840工时=230人天Effor**t=UCP×P**E=92×20=1840工时=230人天

4、类比（自顶向下）估算法

（1）定义

对于类比估算法来说，估算人员根据以往完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件总成本（或工作量），然后按比例将它分配到各个开发任务单元中。

是一种自上而下的估算形式。

（2）什么时候使用

• 有类似的历史项目数据；
• 信息不足（例如市场招标）的时候；
• 要求不是非常精确估算的时候。

（3）主观判断举例

假设现在要开发某个证券交易网站，它的需求与往常开发的网站项目类似，且其历史数据是10万的开发成本。因此，用类比估算法来进行估算，它也是10万的开发成本。

5、自下而上估算法

（1）定义

利用任务分解图（WBS），对各个具体的工具包进行详细的成本估算，然后将结果累加起来得出项目总成本。如下图所示：

大家可以看到，左下方是一些估算的内容，自下而上的原则，右上方是估算的结果。

（2）特点

• 相对比较准确，它的准确度来源于每个任务的估算情况。
• 花费时间。

三点估算法

使用三种估算值来界定活动成本的近似区间，

• 最可能成本（CM）：与现实比较估算出来的结果

• 最乐观成本（CO）：基于活动最好情况所得到的结果

• 最悲观成本（CP）：基于活动最差情况所得到的结果

• 三角分布：CE=(CO+CM+CP)/3

• 贝塔分布: CE=(CO+4CM+CP)/6

6、参数模型估算法（重点）

（1）定义

通过参数模型来估算（规模）成本的方法。

（2）使用条件

使用该模型的条件如下：

• 具有良好的项目数据为基础；
• 存在成熟的项目估算模型。

（3）特点

• 比较简单，而且也比较准确。
• 如果模型选择不当或者数据不准，也会导致偏差。

（4）参数模型：规模（成本）模型

1）面向LOC驱动的

• W a l s t o n − F e l i x ( I B M ) : E = 5.2 ∗ ( K L O C ) Walston-Felix(IBM):E= 5.2*(KLOC)Walston−Felix(IBM):E=5.2∗(KLO**C)^0.91 ⭐⭐⭐
• B a l l e y − B a s i l i : E = 5.5 + 0.73 ∗ ( K L O C ) Balley-Basili:E=5.5+0.73*(KLOC)Balle**y−Basil**i:E=5.5+0.73∗(KLO**C)^1.16
• 基 本 C O C O M O : E = 3.2 ∗ ( K L O C ) 基本COCOMO:E=3.2*(KLOC)基本COCOM**O:E=3.2∗(KLO**C)^1.05 ⭐⭐⭐
• D o t y : E = 5.288 ∗ ( K L O C ) Doty:E=5.288*(KLOC)Dot**y:E=5.288∗(KLO**C)^1.047

2）面向FP驱动的

• A l b r e c h t a n d G a f f n e y : E = − 12.39 + 0.0545 F P Albrecht and Gaffney:E=-12.39+0.0545FPAlbrechtandGaffne**y:E=−12.39+0.0545F**P
• M a t s o n , B a r n e t t : E = 585.7 + 15.12 F P Matson,Barnett:E=585.7+15.12FPMatso**n,Barnett:E=585.7+15.12F**P

3）整体公式

整体公式为：E = a + b ∗ S C E=a+bS^CE*=a+b∗S**C

E：以人月表示的工作量

a,b,c：经验导出的系数

S：主要的输入参数（通常是 LOC ，FP 等）

Walston-Felix模型

• 工作量：E=5.2×（L的0.91次方）L是源码行数（以KLOC计），E是工作量
• 项目时间：D=4.1×（L的0.36次方）D是项目持续时间（以月计）
• 人员需要量：S=0.54×（E的0.6次方）S是项目人员数量（以人计）
• 文档数量：DOC=49×（L的1.01次方）DOC是文档数量

7、专家估算法（重点）

（1）定义

由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值，最后得出综合的估算值。

（2）专家估算法—Delphi

• 组织者确定专家，这些专家互相不见面；
• 组织者发给每位专家一份软件规格说明；
• 专家以无记名对该软件给出3个规模的估算值；
  • 最小a i a_ia**i
  • 最可能的m i m_im**i
  • 最大b i b_ib**i
• 组织者计算每位专家的E i = ( a i + 4 m i + b i ) / 6 E_i=(a_i+4m_i+b_i)/6E**i=(a**i+4m**i+b**i)/6；
• 如果各个专家的估算差异超出规定的范围（例如：15%），则需重复上述过程；
• 最终可以获得一个多数专家共识的软件规模：E = ( E 1 + E 2 + … E n ) / n E=(E_1+E_2+…E_n)/nE=(E1+E2+…E**n)/n（N: 表示 N 个专家）。

敏捷项目成本估算

故事点估算

故事点是用来度量实现一个故事需要付出的工作量的相对估算值

估算标准有两种：

Fibonacci数列等级标准：

0，1，2，3，5，8，13，21，34，55，89，144，233，377，610，·······

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B2qeC0DR-1652110626091)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509213925275.png)]

2的n次方数列等级标准：

0，1，2，4，8，16，32，64，128，256，512，1024，2048，4096，8192，·······

第六章课后习题

第七章软件项目进度计划

7.2进度及任务的定义

7.1进度

所谓进度，是对执行活动和里程碑制定的工作计划日期表。

时间是一种特殊的资源，其单向性、不可重复性、不可替代性而有别于其它资源

2. 任务

所谓任务，是为了完成项目的各个交付成果所必须进行的各项具体活动。

3. 产品和任务的关系

产品和任务的关系如下图所示：

7.2.2任务关联关系

1. 定义

所谓任务关联关系，就是项目各项活动之间存在相互联系与相互依赖关系。之后，根据这些关系安排任务之间的顺序。

2. 任务(活动)之间的关系

任务（活动）之间的关系如下图所示：

3. 任务关系矩阵

如下图所示：

4. 任务关联关系的依据

有以下4种关系：

• 强制性依赖关系：与客观限制有关，是工作任务中固有的依赖关系，不可违背。
• 选择性依赖关系：是人为的主观的是一种根据主观意志调整和确定的项目活动关系。
• 外部依赖关系：项目活动与非项目活动之间的依赖关系
• 内部依赖关系：这是一个内部的强制性依赖关系

7.3进度管理图示

1. 甘特图

具有直观简明、容易学习、容易绘制的优点。可以显示任务的基本信息，工期，开始和结束时间，资源信息。不能反映某项任务变化对整个项目的影响，不能明显地表示各项任务彼此间的依赖关系，也不能明显地表示关键路径和关键任务。

甘特图有两种类型，分别是：

• 棒状甘特图
• 三角形甘特图

2. 网络图

用于展示项目中各个活动及活动之间的逻辑关系，很容易识别关键路径和关键任务

（1）定义

• 网络图是活动排序的一个输出
• 展示项目中各个活动以活动之间的逻辑关系

（2）常用的网络图

Ⅰ. PDM(Precedence Diagramming Method)

PDM ，即优先图法，是一种节点法（单代号）网络图。具体图例如下：

---

下面我们来看一下 PDM 的特点：

• 构成 PDM 网络图的基本要素是节点(BOX)
• 节点(Box) 表示活动（任务）
• 用箭线表示各活动（任务）之间的逻辑关系
• 可以方便的表示活动之间的各种逻辑关系

---

现在我们用 PDM 来演示下某个项目的流程。具体如下：

Ⅱ. ADM(Arrow Diagramming Method)

ADM，即箭线法，是一种箭线法（双代号）网络图。具体图例如下：

下面我们来看一下 ADM 的特点：

• ADM 也称为双代号项目网络图
• 用箭线表示活动（任务）
• 两个代号唯一确定一个任务
• 代号表示前一任务的结束，同时也表示后一任务的开始

---

下面我们来了解 ADM 中的虚活动。虚活动主要用途为：

• 为了定义活动
• 为了表示逻辑关系
• 不消耗资源

具体图例如下：

3. 里程碑图

（1）定义

里程碑事件的定义为：

• 时间要求为 0 的任务
• 不是一个要实实在在完成的任务
• 是一个标志性的任务

（2）图例

具体图例如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zOKvUbLK-1652110626100)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509220009087.png)]

4. 资源图

（1）定义

资源图，用来显示项目进展过程中资源的分配情况。

（2）图例

资源图图例如下：

5. 燃尽图

（1）定义

燃尽图，描述随着时间的推移剩余的工作数量，可表示开发进度。

（2）图例

燃尽图图例如下：

6. 燃起图

（1）定义

燃起图，描述随着时间的推移已完成的工作数量，可表示开发进度。

（2）图例

燃起图图例如下：

7.5任务历时估计

1. 定义

所谓任务历时估计，即估计任务的持续时间。

2. 历时估算的基本方法

历时估算的基本方法包含 4 种，分别是：

• 定额估算法
• 经验导出模型
• PERT(工程评估评审技术)
• Jones的一阶估算准则

下面将依据这几种基本方法进行一一讲解。

（1）定额估算法

公式

定额估算法的公式为：T=Q/(R*S)

其中： T 为活动历时； Q 为任务工作量； R 为人力数量； S 为工作效率（贡献率）。

举例

例子①：

假设Q=6人天，R=2人，S=1。所以：T=3天

例子②：

假设Q=6人天，R=2人，S=1.5。所以：T=2天

（2）经验导出模型

公式

定额估算法的公式为：D=a*Eb

其中： D 为进度（已月为单位）； E 为工作量（以人月为单位）； a 的范围在 2-4 之间； b 的值在 1/3 左右，依赖于项目的自然属性。

举例

假设： 导出模型D=3*E1/3，E=65人月，请计算出D值。

解： D=3*651/3=12月

（3）PERT（工程评估评审技术）

定义

• PERT，即 Program Evaluation and Review Technique 。
• 它是利用网络顺序图的逻辑关系和加权历时估算来计算项目历时，适用于估计历时存在不确定时。
• 它是基于对某项任务的乐观，悲观以及最可能的概率时间来估计。

计算

PERT采用加权平均得到期望值 E=(O+4M+P)/6 ，其中：

① O 是最小估算值：乐观(Optimistic)；

②P 是最大估算值：悲观(Pessimistic)；

③M 是最大可能估算（Most Likely）；

举例

假设现有某项目，乐观值是8天，最大可能值是10天，悲观值是24天。采用 PERT 方法，计算出其加权期望值 E 。

解： 加权平均期望值 E 为 8 + 4 × 10 + 24 6 = 12 天 \frac{8+4×10+24}{6}=12天68+4×10+24=12天

PERT的风险指标

标准差δ =(最大估算值-最小估算值)/6

方差δ2 = [(最大估算值-最小估算值)/6] 2

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gzsobnHw-1652110626101)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509220753451.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QpPc6Geq-1652110626103)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509220809356.png)]

（4） Jones的一阶估算准则

定义

• 估算项目功能点；
• 从幂次表中选择合适的幂次来将功能点升幂

幂次表

Jones一阶估算准则的幂次表如下表所示：

软件类型	最优级	平均	最差级
系统软件	0.43	0.45	0.48
商业软件	0.41	0.43	0.46
封装商品软件	0.39	0.42	0.45

举例

假设现有某平均水平的商业软件，其功能点为 FP=350 。请计算出其粗略的进度。

解：粗略的进度=3500.43=12月

五、进度计划编排

1. 关键路径法

（1）CPM基本概念

• 最早开始时间 Early start
• 最晚开始时间 Late start
• 最早完成时间 Early finish
• 最晚完成时间 Late finish
• 总浮动 Total Float
• 自由浮动 Free Float
• 超前 Lead
• 滞后 Lag

（2）ES、EF、LS、LF关系图

对于 ES 、 EF 、 LS 和 LF 这四个概念来说，它们之间的关系如下图所示：

（3）浮动时间

浮动时间是一个任务的机动性，它是一个任务在不影响其它任务或者项目完成的情况下可以延迟的时间量。

（4）总浮动与自由浮动

• 总浮动(Total Float)是，在不影响项目最早完成时间的前提下，一个任务可以延迟的时间。
• 自由浮动(Free Float)是，在不影响后置任务最早开始时间的前提下，一个任务可以延迟的时间

（5）关键路径(Critical Path)

• 时间浮动为 0 (Float=0) 的路径
• 网络图中最长的路径
• 关键路径是决定项目完成的最短时间
• 关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟
• 关键路径可能不止一条

（6）计算

关于关键路径的计算，查看这篇文章：软件项目进度安排与跟踪，一招学会计算关键路径

2. 时间压缩法

（1）定义

时间压缩法，即在不改变项目范围的前提下缩短项目工期的方法。

（2）方法

一般有两种方法，具体为：

• 应急法——赶工（Crash）
• 平行作业法——快速跟进

下面将依据这两种方法来进行一一详述。

（3）应急法

Ⅰ. 定义

• 在最小相关成本增加的条件下，压缩关键路径上的关键活动历时的方法
• 赶工也称为时间-成本平衡方法

Ⅱ. 压缩时间与追加成本关系图

压缩时间与所追加成本的关系图如下所示：

Ⅲ. 关于进度压缩与费用增加的关系

• 进度压缩单位成本方法（时间成本平衡法）——线性关系
• Charles Symons(1991)方法（进度压缩因子方法）——进度压缩比普通进度短的时候，费用迅速上涨

下面将依据这两种方法来进行一一讲解。

（4）进度压缩单位成本方法

I. 定义

前提条件：活动的正常与压缩

• 项目活动的正常值 —— 正常历时和正常成本
• 项目活动的压缩值 —— 压缩历时和压缩成本

II. 计算

计算公式： 进度压缩单位成本=（压缩成本-正常成本）/(正常进度-压缩进度)

例如： 假设现有任务A，正常进度7周，成本5万；压缩到5周的成本是6.2万。

解： 那么进度压缩单位成本为：(6.2-5)/(7-5)=6000元/周=0.6w/周 ；

如果压缩到 6 周的成本是：5+0.6=5.6万 。

III. 最短进度

项目存在一个可能的最短进度，如下图所示：

（5）Charles Symons(1991)方法

I. 计算公式

进度压缩因子=压缩进度/正常进度

压缩进度的工作量=正常工作量/进度压缩因子

II. 举例

例如： 初始进度估算是12月，初始工作量估算是78人月，如果进度压缩到10月，请计算出其进度压缩因子和压缩进度的工作量。

解： 进度压缩因子= 10/12=0.83 ，则进度压缩后的工作量是：78/ 0.83=94人月 。

总结： 进度缩短17%，增加21%的工作量。

研究表明： 进度压缩因子 >0.75 ，最多可以压缩 25% 。

（6）平行作业法

平行作业法，即改变活动间的逻辑关系，并行开展某些活动。

3. 资源优化法

（1）方法

资源优化有两种方式：

• 资源平衡法（可能会导致关键路径的改变）
• 资源平滑法（可能无法实现所有资源的优化）

（2）资源平衡法

资源平衡法，即资源优化配置，形成最有效的利用资源。目的在于使资源闲置的时间最小化，尽量避免超出资源能力。

（3）资源平滑法

假设现有某项目，具体活动周期如下：

用资源平滑发分配的话，有以下两种方式：

第一种：所有活动都在同一天开始

第二种：活动C延迟两天进行

第七章课后习题

第八章软件项目质量计划

8.1质量概述

1. 质量与软件质量

• 质量是满足要求的程度，包括符合规定的要求和满足顾客的需求。
• 软件质量是软件产品满足明确说明或隐含的需求程度。

2. 质量成本

• 质量成本包括预防成本和缺陷成本。
• 预防成本：为确保项目质量而进行预防工作所耗费的费用（评估费用+预防费用）。
• 缺陷成本：为确保项目质量而修复缺陷工作所耗费的费用（内部费用+外部费用）。

8.2质量模型

1. 定义

人们通常把影响软件质量的特性用软件质量模型来描述。

2. 几种模型

主要有几种模型：

• 1976年 —— Boehm 质量模型
• 1979年 —— McCall 质量模型
• 1985年 —— ISO/IEC 9126 质量模型
• 2002年 —— ISO/IEC 25010 质量模型

3. 模型解读

（1）Bohem质量模型

如下图所示：

（2）McCall质量模型

如下图所示：

（3）ISO/IEC 9126质量模型

如下图所示：

（4）ISO/IEC 25010质量模型

如下图所示：

4. 例子阐述

假设下图是某调度指挥通信系统的各项指标，请设计出其质量模型。

解： 该系统的质量模型如下图所示：

8.3质量管理活动

总是围着QA质量保证和QC质量控制两个方面进行

1. 步骤

质量管理过程包含三个步骤，分别是：

• 质量计划
• 质量保证
• 质量控制

2. 步骤解读

下面将对上面三个步骤进行解读，具体如下：

• 质量计划 —— 确定与项目相关的质量标准及如何满足标准
• 质量保证 —— 通过定期评估项目整体性能以确保项目满足相关的质量标准
• 质量控制 —— 通过控制项目的状态保证项目按照标准完成，确定改进质量的方法

3. 再剖析

下面我们对质量保证和质量控制进行深入剖析。

（1）质量保证

• 质量审计是质量保证的主要方法；
• 审计(Audit) 是对过程或者产品的一次独立评估；
• 质量保证的主要活动：项目执行过程审计和项目产品审计。

（2）质量控制

• 质量控制方法：技术评审、走查、测试、返工（焦点是产品推出前的质量把关）；
• 质量保证的焦点：过程和产品提交之后的质量监管。

如下图所示：

8.4敏捷项目的质量活动

敏捷项目的质量管理特征如下：

• 敏捷项目提成全程质量审查
• 敏捷项目提成早发现问题
• 不断进行质量方法评估和改进

1.结对编程

两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。有助于提升代码设计质量；研究表明结对生产率比两个单人总和低15%，但缺陷数少15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高，同时结对编程能够大幅促进团队能力提升和知识传播。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rQUWsQRB-1652110626113)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509222900082.png)]

2.测试驱动开发

3.持续集成与测试

4.不同层面自动化测试

5.验收测试驱动开发

6.迭代评审

7.迭代回顾会议

8.重构

8.5.2软件项目质量计划编制方法

1. 编制方法

编制方法包括：

• 试验设计
• 基准对照
• 质量成本分析
• 测试与检查的规划
• 各种数据分析图示（因果分析图、流程图、思维导图）

因果分析图

如下图所示：

软件质量改善的建议

对于软件质量改善的建议，有以下措施：

• 把想法落实到实际工作中
• 质量活动必须经过规划，必须明文规定
• 树立提高质量就是尊重客户的思想
• 质量活动必须尽早开始
• 质量小组尽可能独立存在
• 质量小组的人应该经过必要的培训
• 软件质量是软件产品满足需求的程度
• 软件质量成本包含预防成本和缺陷成本
• 软件质量模型是影响软件质量的特性，是评价软件质量的标准
• 软件质量管理过程包含质量计划、质量保证和质量控制
• 质量保证的焦点是过程和产品提交之后的质量监管，质量控制的焦点是产品推出之前的质量把关

第八章课后习题

第十章软件项目团队计划

10.1.1项目组织结构类型是

⚪ 职能型组织结构

是一种常规的线性组织结构

适用范围：

这个组织结构适用于主要由一个部门完成的项目或技术比较成熟的项目。

优点：

1. 可以充分发挥职能部门的资源集中优势，有利于保障项目所需资源的供给和项目可交互成果的质量，在人员的使用上具有较大的灵活性。
2. 职能部门内部的技术专家可以被该部门承担的不同项目共享，节约人力，减少了资源的浪费。
3. 同一部门的专业人员便于交流、相互支援，对创造性的解决问题很有帮助。同部门的专业人员易于交流知识和经验，项目成员在事业上具有连续性和保障性。
4. 当项目人员调离项目或离开公司时，所属职能部门可以增派人员，保持项目的连续性。
5. 项目成员可以将完成项目和完成本部门职能工作融为一体，可以减少因项目的临时性而给项目成员带来的不确定性。

缺点：

1. 客户利益和职能部门的利益常常发生冲突，职能部门会为本部门的利益而忽略客户的需求，只集中与本职能部门的活动，项目和客户的利益往往得不到优先考虑。
2. 当项目需要多个职能部门共同完成，或者一个职能部门内部有多个项目需要完成时，资源的平衡就会出现问题。
3. 当项目需要多个部门共同完成时，权力分割不利于各职能部门之间的沟通交流、团队协作。项目经理没有足够的权力控制项目的进展。
4. 行政隶属关系使项目经理没有完全的权利。

⚪项目型组织结构

是一种单目标的垂直组织方式。

存在一个项目就有一个类似部门的项目组，项目完成了就解散了，项目人员的去向是一个问题。

适用范围：

适用于开拓型等风险比较大的项目或进度、成本、质量等指标有严格要求的项目，不适合人才匮乏或规模小的企业。

优点：

1. 项目经理对项目可以全权负责，可以根据项目需求随意调动项目组织的内部外部资源
2. 组织结构单一，完全以项目为中心安排工作，决策的速度加快，可以对客户的要求做出及时响应，有利于项目的顺利完成。
3. 项目经理对项目成员有全部权利，项目成员支队项目经理负责，避免了职能型项目组织下的多重领导局面。
4. 组织结构简单，易于操作，项目成员直接属于一个部门，彼此之间交流简单、快速，提交了沟通效率，加快了决策速度。

缺点：

1. 资源不能共享给其它项目型组织，即便某个项目的专用资源闲置了，也无法共享给另一个同时进行的类似项目，会有一定程度的资源浪费。
2. 各个独立的项目处于相对封闭状态，不利于公司政策的贯彻，可能会影响公司的长远发展。
3. 项目完成后，项目人员的去向让项目组织的成员缺少一种事业上的连续性和安全感。
4. 项目组织之间处于分割状态，缺少信息交流，不同的项目组很难共享知识和经验。

⚪ 矩阵型组织结构

使职能型和项目型组织结构的混合体，两类的特征都具有。

根据项目需求，从不同部门选择合适的人员组成一个临时项目组，项目组解体后，人员回原来的部门。

适用范围：

这种组织结构适用于管理规范、分工明确的公司或者跨职能部门的项目。

优点：

1. 专职的项目经理负责整个项目，以项目为中心；在最短时间内调配人才，组成一个团队，把不同职能的人才集中在一起。
2. 公司的多个项目可以共享各个职能部门的资源。
3. 即利于项目目标的实现，又利于公司目标方针的贯彻。
4. 项目成员的顾虑减少了。项目完成后，可以回去，不要担心被解散，还有更多机会接触不同部门。

缺点：

1. 容易引起职能经理和项目经理权力的冲突。
2. 资源共享可能引起项目之间的冲突。
3. 项目成员有多位领导，即员工必须接受双重领导，因此有焦虑和压力。两个领导的命令发生冲突时，得自己做出决策来分配自己的时间。

10.1.2人员职责计划

责任分配矩阵：

责任分配矩阵（RAM），即 Responsibility Assignment Matrix ，即用来对项目团队成员进行分工，明确其角色与职责的有效工具 。

RAM（责任分配矩阵）以图形方式展示项目团队成员及其报告关系，这样可以减少沟通渠道，减少沟通成本。

10.3.1沟通方式

• 项目沟通的基本原则是：及时性、准确性、完整性、可理解性。

• 项目经理80%以上的时间都是用于沟通管理。

• 对于紧急的信息，应该通过口头的方式进行沟通；对于重要的信息，应该采用书面的方式进行沟通。

沟通是一种人与人之间的信息交流活动，所采用的方式应该是双方都可以理解的通用符号和技巧，这样可以保证信息的传送与接受畅通。

• 书面沟通和口头沟通
• 语言沟通和非语言沟通
• 正式沟通和非正式沟通
• 单向沟通和双向沟通
• 网络沟通

沟通活动可以按照多种维度进行分类：

1.内部沟通和外部沟通

• 内部沟通：针对项目内部或组织内部的相关方
• 外部沟通：针对外部相关方，如客户、供应商、其他项目、组织、政府，公众和环保倡导者。

2.正式沟通和非正式沟通

• 正式沟通：包括报告、正式会议（定期及临时）、会议议程和记录、相关方简报和演示。
• 非正式沟通：包括采用电子邮件、社交媒体、网站，以及非正式临时讨论的一般沟通活动。

3.官方沟通和非官方沟通

• 官方沟通：呈交监管机构或政府部门的报告。
• 非官方沟通：采用灵活（往往非正式）的手段来建立和维护项目团队及其相关方对项目情况的了解的认可，并在它们之间建立强有力的关系。

此外沟通还有口头沟通（用词和音频变化）及非口头沟通（肢体语言和行为），以及层级沟通等。

层级沟通：

• 向上沟通：针对高层相关方。
• 向下沟通：针对承担项目工作的团队和其他人员。
• 横向沟通：针对项目经理或团队的同级人员。

10.3.2沟通渠道

沟通渠道公式[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KEnqRFsm-1652110626119)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509103810895.png)]

I是沟通渠道，E是人数

10.4.2敏捷团队

敏捷团队中的角色主要有三类：产品负责人、团队促进者、跨职能团队成员，分别对应Scrum的三个角色，即产品负责人（product owner）、Scrum主管（Scrum master）及开发团队。

Scrum团队的人数一般少于9人。

10.4.3敏捷沟通

在敏捷开发中,要进行频繁沟通,主要的三个沟通会议是每日站立会议（一般是15分钟）、Sprint计划会议、Sprint复审会议。

第十章课后习题

第十一章软件项目风险计划

11.1.1风险的定义及特征

特征：

风险的两个基本特征是不确定性和损失。

定义：

风险是对潜在的、未来可能发生损害的一种度量，如果风险发生了，则会对项目产生有害的或者负面的影响。

软件风险是指对软件开发过程及软件产品本身可能造成的伤害或损失。

风险的三要素：

⚪风险事件、⚪风险事件发生的概率、⚪风险造成的影响。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hoWyncxp-1652110626128)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509125550905.png)]

11.1.2风险的类型

⚪预测角度：

• 已知风险

  • 通过仔细评估项目计划、开发项目的商业与技术环境及其他可靠的信息来源（如不现实的交付时间、没有需求或软件范围的文档、恶劣的开发环境）之后可以发现的那些风险。

• 可预测风险

  • 是指能够从过去项目的经验中推测出来的风险（如人员调整，与客户无法沟通）。

• 不可预测风险

  • 是指可能、也许会真的出现，但很难实现识别出来的风险。

  只能对已知风险和可预测风险进行规划，不可预测风险只能靠企业的能力来承担

⚪范围角度：

• 商业风险
  • 是指管理或市场所加诸的约束相关的风险
• 管理风险
  • 是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，如时间和资源分配的不合理、资金不足等
• 人员风险
  • 是指参与项目的软件人员稳定性、整体技术水平及项目经验相关的风险。
• 技术风险
  • 是指与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
• 开发环境风险
  • 与用来开发产品的工具的可用性及质量相关的风险
• 客户风险
  • 与客户的素质及开发者和客户沟通的能力相关的风险
• 过程风险
  • 与软件过程被定义的程度及他们被开发组织所遵守的程度相关的风险
• 产品风险
  • 与质量低下的不可接受的产品相关的风险

11.1.3风险管理过程

风险管理过程就是分析风险3个要素的过程。旨在识别出风险，然后采取措施使他们对项目的影响最小化。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ryVdVsFN-1652110626129)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509130702561.png)]

11.2风险识别

定义：

风险识别是试图系统化地确认对项目计划（估算、进度、资源分配）的威胁，识别已知和可预测的风险。

风险识别包括确定风险的来源、确定分析产生的条件，描述风险特征和确定哪些风险事件有可能影响本项目。风险识别相当于确定风险三要素中的风险事件。

风险识别不是一次性行为，而应有规律地贯穿于整个项目中。

风险识别方法：

• 德尔菲方法：专家调查法，信息收集技术
• 头脑风暴方法：以专家的创造性思维来获取未来信息的直观预测和识别方法
• 情景分析法：根据发展趋势的多样性，通过系统分析，设计多种可能的未来前景。
• 风险条目检查表法：最常用且比较简单的风险识别方法
  • 7 个条目分别为：
    • 产品规模
    • 商业影响
    • 客户特征
    • 过程定义
    • 开发环境
    • 技术情况
    • 人员数目及经验

11.3风险评估

定义：

对风险发生的概率进行估计和评价，对项目风险后果的严重程度进行估计和评价，对项目风险影响范围进行分析和评价，以及对项目风险发生时间进行估计和评价。

步骤：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cI1YpAS8-1652110626130)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509132009571.png)]

风险评估的方法：

有两种方法，分别为：定性风险评估方法和定量风险评估方法。

定性风险评估：

风险概率度量： 极高、高、中、低、极低

风险影响度量： 灾难，严重，轻微，可忽略

风险概率及后果估计，矩阵图如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DWmSWAe1-1652110626132)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509132214878.png)]

定量风险评估:

定量风险评估有五种方法，分别为：

• 访谈
• 盈亏平衡分析
• 模拟法
• 决策树分析
• 敏捷性分析

决策树分析

定义：

• 决策树分析是一种图表分析方法
• 提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率
• 提供选择一个最佳方案的依据。

EMV：

• EMV，即损益期望值，是决策树的一种计算值；
• EMV 根据结果、发生的概率计算出一种期望的损益。
• 例如：某行动方案成功的概率是 50%，收益是 10 ，那么 EMV = 10×50% = 5 。

11.4项目风险应对策略

有以下 4 种策略，分别为：

• 回避风险
• 转移风险
• 损失控制
• 自留风险

⚪回避风险

定义：

• 回避风险是对可能发生的风险尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案。
• 例如：放弃采用新技术。

注意事项：

• 对风险要有足够认识；
• 当其他风险策略不理想的时候，可以考虑；
• 可能产生另一种新的风险；
• 不是所有的情况都适用的。

⚪转移风险

• 转移风险是为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法。
• 例如：保险。

⚪损失控制

定义：

• 消除风险因素，减少风险损失；
• 是最主动的风险应对策略。
• 根据不同目的，分为损失预防和损失抵制。
• 如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0SCHpOJR-1652110626133)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509142650690.png)]

实例：

人员的频繁流动是一项风险，基于过去的历史和管理经验，频繁流动可能性的估计值为 70% ，开发时间增加 15% ，总成本增加 12% ，为了缓解这一风险，项目经理采取的策略如下：

• 与现有人员讨论人员流动的原因；
• 建立良好的项目组织和通信渠道，以使大家能够了解每个有关的开发活动的信息；
• 指定文档标准并建立相应的机制，以保证文档能够及时建立；
• 对所有工作组织细致的评审，使大多数人能够按计划进度完成自己的工作；
• 项目启动时，做好会出现人员流动的准备，采取一些技术以确保人员的一旦离开后，项目仍然能继续。

⚪自留风险

• 由项目组织自己承担风险事故所致损失的措施。
• 例如：工程运营超支则接受低于预期利润的风险。

第十一章课后习题

第十二章软件项目合同计划

12.2项目合同

合同是具有法律效力的协议

• 双方自愿达成的协议
• 签订者具有相应的法律能力
• 有充分的签约理由
• 具有合法的目的

甲方是买方；乙方是卖方；

12.2.2合同条款

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nK2b1mIw-1652110626146)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509151959428.png)]

12.3合同类型

合同类型通常分为总价合同和成本补偿合同两大类，此外还有第三种常用的混合类型，即工料合同。

总价合同

• 固定总价合同（FFP）
  • 最常用的合同类型。货物采购价格在一开始就已经确定，并且不允许改变。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cg7NIMF4-1652110626148)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509155707013.png)]
• 总价加激励费用合同（FPIF）
  • 为买方和卖方提供了一定的灵活性，允许一定的绩效偏离，并对实现既定目标有钱奖。
  • 会有价格上限，高于此价格上线的全部成本将由卖方承担。
  • 即卖方节约成本有奖励，超出成本自己承担。
  • 总付款=实际成本+目标利润-（实际成本-目标成本）*卖方分成比例。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ViOrJoHr-1652110626149)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220509155801500.png)]
• 总价加经济价格调整合同（FPEPA）
  • 在一个基本的总价基础上根据特殊情况进行最后总价的调整。
  • 使用情况：
    • 卖方履约期将跨越几年时间。
    • 将以不同货币支付价款。

成本补偿合同

• 成本加固定费用（CPFF）

  • 为卖方报销履行合同工作所发生的一切可列支成本，并向卖方支付一笔固定费用，该费用以初始项目成本估算的某一百分比估算。费用只针对已完成的工作来支付，并且不因卖方的绩效而变化，除非项目范围发生变更，费用金额维持不变。

• 成本加激励费用合同（CPIF）

  • 为卖方报销履行合同工作所发生的一切可列支成本，并在卖方达到合同规定的绩效目标时，向卖方支付预告确定的激励费用，在CPIF合同中，如果最终成本低于或高于原始估算成本则买方和专访需要根据事先商定的成本分摊比例来分享节约部分或分担超出部分。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HPBKGPPX-1652110626151)

• 成本加奖励费用合同（CPAF）

  • 在卖方报销履行合同工作所发生的一切合法成本，只在满足了合同中规定的某些主观的绩效标准的情况下，才能向卖方支付大部分费用。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r6ZY3LUn-1652110626152)

工料合同

也称单价合同，即只规定了卖方所提供产品的单价，根据卖方在合同执行中实际提供的产品数量计算总价，工料合同是兼具成本补偿合同和总价合同的某些特点的混合型合同，它与成本补偿合同的相似之处在于，它们是开口合同，合同价因成本增加而变化。适用范围：短期服务和小金额；工作范围未明确就要立即开始工作时，增加人员、聘请专家以及寻求其他外部支持。

合同风险

看表格比较好

合同类型	属性	风险
总价合同
成本加固定费用(CPFF)	实际成本加上卖方利润	买方承担成本超出的风险。买方风险比较大。
成本加激励费用(CPIF)	实际成本加上卖方利润，有奖励机制。	买方承担成本超出的风险。
成本加奖励费用(CPAF)	实际成本加上卖方利润，有奖励机制。	买方承担成本超出的风险。
成本补偿合同
固定总价(FFP)	双方就合同产品协商价格。	卖方承担风险
总价加激励费用(FPIF)	双方就合同产品协商价格，其中包括对卖方的奖励金。	卖方承担风险
总价加经济价格调整(FPEPA)	双方就合同产品协商价格，其中包括价格的调整要求。	卖方承担风险
工料	按照卖方使用的时间和材料来计算价格	没有最大开销约束的合同可以导致成本超支

第十二章课后习题

第十四章项目核心计划执行控制

14.1范围计划执行控制

范围核实

• 是指对项目范围的正式认定，项目主要干系人要在这个过程中正式接受项目可交付成果的定义
• 这个过程是范围确定之后，执行实施之前各方相关人员的承诺问题。一旦承诺表明已经接受该事实， 这也是确保项目范围能得到很好的管理和控制的有效措施

变更控制

• 在既定的项目范围之内：就需要评估变更所造成的影响，以及如何应对的措施，受影响的各方都应该清楚明了自己所受的影响；
• 在既定的项目范围之外：需要与用户(甲方)进行谈判，看是否增加费用和工期，或者放弃变更

*范围控制的要点*

防治不合理的范围扩张，包括范围蔓延和范围镀金。

14.2进度与成本执行控制

• 第一个要点：
  • 保证项目进度计划是现实的。
• 第二个要点
  • 要有纪律，遵守并达到项目计划的要求。

图解控制法

• 图解控制方法是一种偏差分析方法

• 优点是可以一目了然的确定项目状况，缺点是只能提供视觉影响，不能提供其它重要量化信息

• 利用时间图、进度图、成本图、资源图等对项目的性能进行偏差分析，审查目标绩效与实际绩效之间的差异或偏差

• 在监控项目工作过程中，通过偏差分析对成本、时间、技术和资源偏差进行综合分析，以了解项目的总体偏差情况，便于采取合适的预防或纠正措施

**挣值分析法（重点）**

• 也称为已获取价值分析法，是一种计算实际花在一个项目上的工作量，以及预计该项目所需成本和完成该项目的日期的方法
• 挣值分析法是对项目的实施进度、成本状态进行绩效评估的有效方法
• 挣值分析法综合了范围、进度、成本的绩效，是对项目实施的进度、成本状态进行绩效评估的有效方法
• 挣值分析法既可以用于偏差分析，也可以用于趋势分析

Goal是项目希望花费的数额，或者预期将花费的数目。

难点在于计算BCWP

• 第一种方法：及时并连续的计算挣值
• 第二种方法：利用公式计算
  • 50/50规则
  • 0/100规则
  • 经验加权法

实例：

14.3质量计划执行控制

• 质量保证是在项目过程中实施的有计划、有系统的活动，确保项目满足相关的标准
• 质量控制指采取适当的方法监控项目结果，确保结果符合质量标准，还包括跟踪缺陷的排除情况

14.3.1质量保证管理

• 质量保证管理分类

  • 内部质量保证.
  • 外部质量保证.

• 要点

  • 在项目进展过程中定期对项目各方面的表现进行评价.
  • 通过评价来推测项目最后是否能够达到相关质量指标.
  • 通过质量评价来帮助项目相关的人建立对项目质量的信心.

• 主要活动

  • 产品审计：例如需求文档、设计文档、源代码、测试报告等.
  • 执行过程审计：例如需求过程、设计过程、编码过程、测试过程等.

14.3.2质量控制的管理

• 质量控制是通过检查项目成果，以判定它们是否符合有关的质量标准，并找出方法消除造成项目成果不令人满意的原因
• 它应当贯穿于项目执行的全过程
• 由质量控制部门的组织执行
• 要点
  • 检查控制对象是项目工作结果
  • 进行跟踪检查的依据是相关质量标准
  • 分析质量问题，找到产生的原因，确定采取何种措施来消除这些问题
• 方法和手段
  • 技术评审、代码走查、测试、返工等
  • 控制突发、趋势分析、抽样统计、缺陷跟踪等
• 技术评审
  • 尽早发现工作成果中的缺陷，帮助开发人员及时消除缺陷，从而有效地提高产品的质量
• 技术评审过程
  • 1、召开评审会议：一般应有3至5相关领域人员参加，会前每个参加者做好准备，评审会每次一般不超过2小时；
  • 2、在评审会上，由开发小组对提交的评审对象进行讲解；
  • 3、评审组可以对开发小组进行提问，提出建议和要求，也可以与开发小组展开讨论
  • 4、会议结束时必须做出以下决策之一：
    • 接受该产品，不需做修改；
    • 由于错误严重，拒绝接受；
    • 暂时接受该产品，但需要对某一部分进行修改。开发小组还要将修改后的结果反馈至评审组
  • 5、评审报告与记录：所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审报告
• 代码走查
  • 是指在代码编写阶段，开发人员检查自己代码的过程、
  • 代码走查是非常有效的方法，可以检查到其他测试方法无法监测的错误
  • 代码走查是开发人员的个人质量行为，而代码评审是更高一层的质量控制，是一种技术评审
• 测试
  • 由于很多项目流程在实施中非常不规范，因此软件测试对把好质量关非常重要
  • 软件测试的重点是做好测试用例设计。
  • 测试用例设计是开发过程必不可少的
  • 在项目实施中设计测试用例应该根据进度安排，优 先设计核心应用模块或与核心业务相关的测试用例
• 返工
  • 返工是将有缺陷的、不符合要求的产品变为符合要求和设计规格的产品的行为
  • 返工也是质量控制的一个重要的方法，用于将有缺陷的项和不合格项改造为与需求和规格一致的项
  • 预料之外的返工，在大多数应用领域中是导致项目延误的常见原因
• 数据分析手段
  • 控制图法
  • 趋势分析
  • 抽样统计
  • 缺陷跟踪

第十四章课后习题