3.1 跟踪项目进展
如何确定该怎么做，做到哪里了？
3.1.1 关键概念介绍
1. 项目进度 活动 milestone 项目成本
项目进度定义：通过列举项目的各个阶段，把每个阶段分解成离散的任务或活动，来描述特定的软件开发周期
项目活动（Project Activity）：项目的一部分，一般占用项目进度计划中的一段时间
里程碑（Milestone）：指特定的时间点，标志着活动的结束，通常伴随着提交物。（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）
项目成本定义：为项目开发而购买软件、硬件的成本，用于支持需求分析、设计、编码、测试、处理需求变更等活动，涉及到工作量开支
(1) 项目进度（Project Schedule）
项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。
(2) 项目活动（Project Activity）
项目的一部分，一般占用项目进度计划中的一段时间
(3) 里程碑（Milestone）
指特定的时间点，标志着活动的结束，通常伴随着提交物。（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）
(4)前驱（Precursor）
活动进行前必须完成的事件
(5)工期（Duration）
完成活动的时间
(6)截止日期（Due date）
活动必须完成的时间
3.1.2 工作分解和活动图
描述了活动和活动间依赖关系的图，其中节点表示项目的里程碑（活动结束），线表示活动。如图例中 A->B 的部分表示 A->B 的这条线代表的这个活动从 A 开始，需要做 3 天，才能结束，到达 B 里程碑（标志着 A->B 这条线代表的活动的结束）。一定要十分注意这一点，图中的点并不代表活动，并不能说活动 A 用 3 天到达活动 B，这是不准确的，如到达 I里程碑的边有两条，D->I, B->I，意思是有两个活动，完成后到达里程碑 I，并不能说 I是个活动，如果这么理解会在计算最晚开始时间时出现错误。
2-1 什么是活动图
描述了不同活动之间的依赖性、表明了执行的顺序，节点表示项目里程碑，线条表示活动
2-2 如何计算项目关键路径、冗余时间 最早最晚开始时间
关键路径：从起点到终点总花费时间最长的路径
3.1.3 估算项目完成时间
关键路径（Critical Paths）
从起点到终点总花费时间最长的路径，即这个项目的最短完成时间，因为如果这条路径无法完成那么整个项目都不能算完成。所以这条路径上的任务耽误一点都会影响最后项目完成时间。
如上图，其关键路径为 A->B->D->I->J->L = 20，其他路径都比它短。
冗余时间（Slack Time）
最早开始时间（Earliest start time ES）
最晚开始时间（Latest start time LS）
- 若起始为1：
EF = ES + 工期 -1
LS = LF - 工期 +1
- 若起始为0：
EF = ES + 工期
LS = LF - 工期
设关键路径的长度为LL
ES 最早开始时间（能到达该开始点的最长的路径所花费的时间） | 工期（参照上面的计算公式） | EF（ES+工期） |
LS（使用LL-能到达该开始点的最长的路径所花费的时间） | slack time | LF（LS+工期） |
3.2 项目人事组织
3.2.1 人员选择的要求（软件人员应具备的能力）
（1）完成工作的能力
（2）对工作的兴趣
（3）经验
- 开发类似应用的经验
- 使用类似工具或语言的经验
- 使用类似开发环境的经验
（4）培训
（5）与其他人交流的能力
（6）与其他人共同承担责任的能力
（7）管理技能
3.2.2 沟通交流
项目的进度受到以下因素的影响
- 沟通程度
- 个人交流想法的能力
软件故障可能是由于沟通和理解的中断造成的
如果在项目中有n个工作者，那就会有n(n-1)/2对交流的线
会议常见抱怨：
- 目的不明确
- 与会者毫无准备
- 关键人物迟到或缺席
- 谈话偏离了目的
- 参与者不讨论，而是争论
- 决策永远不会在事后颁布
确保会议富有成效的方法：
- 明确决定谁应该参加会议
- 制定议程
- 有人跟踪讨论
- 有人确保后续行动
3.2.3 工作方式
Extroverts（外向型）
Introverts（内向型）
Intuitives（感性的）
Rationals（理性的）
3.2.4 项目组织
3. 软件项目团队基本组织架构
(1) 主程序员负责制
(2) 忘我方法（Egoless Approach）：每个成员平等的承担责任
依赖团队成员的背景、工作风格，团队成员数，客户和开发者的管理方式
(1) 主程序员负责制
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。
优势：
使交流最小化
迅速做出决定缺点：
创造性低
对主程序员要求高，个人主观性强
(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。
(3) 项目组织的结构化和创造性
- 结构化较强的团队： 按时完成任务，单工作比较循规蹈矩，项目普通但是功能完备。适合人员较多，项目稳定性和一致性高，使用较正规的结构。
- 结构化较弱的团队： 不能按时完成任务但是创造性强，涉及大量的不确定性因素时采用较为民主的方法和相关的团队结构
3.3 工作量估计
估算项目成本是项目规划和管理的关键方面之一。
估算成本必须在项目生命周期内尽早完成
开销种类：
- 基础设施：硬件，空间，家具，电话，等
- 设计软件使用的软件工具
- 人员：最大的开销部分
估计不准确的主要原因：
- 用户频繁的修改需求
- 被忽视的任务
- 用户对需求缺乏理解
- 制定估算时分析不足
- 在开发过程中，系统开发、技术服务、运营、数据管理和其他职能缺乏协调
- 缺乏适当的估算方法或指导方针
3.3.1 专家估算法
很多工作量估算方法依赖于专家的判断。使用专家的知识和经验，对软件项目的工作量进行评估，预测的精确性基于估算者的能力、经验、客观性和洞察力。是对构建整个系统或其子系统所需的工作量做出经验性的猜测。
类推法：
通过做出三种成本估计（悲观估计：x；乐观估计：y；最可能的预测：z），通过公式（x+4y+z）/6 计算 beta 概率分布均值Delphi 技术：
几组专家预测平均值的反复修正Wolverton 模型：
通过计算 O（老问题），N（新问题）和 E（容易的），M（适中的），H（困难的）的2*3 种组合和不同编程部分的搭配系数矩阵来确定成本。
总体来说，专家估计法差异性，主观性，当前数据依赖的影响。现在大多采用算式估算法。
3.3.2 算法估算法
研究人员已经创建出表示工作量和影响工作量的因素之间关系的模型。这些模型通常用方程式描述，其中工作量是因变量，而其他因素是自变量。大部分模型认为项目规模是方程式中影响最大的因素，表示工作量的方程式是：
E 为工作量，a,b,c 都为常数，S 是估算的系统规模，X 是一个 x1…xn 维度成本因素的向量，m 是基于该因素的调整因子。
3.3.3 COCOMO model
4. COCOMO模型的三个阶段
constuction cost model
(1) 应用组合 application composition：利用原型化来解决高风险问题，用应用点来估算成本
(2) 早期设计 early design：用功能点
(3) 后架构阶段：用代码行数来评估KLOC
结构化成本模型
是目前应用最广泛的参数型软件成本估计模型
基本方法：
是软件规模，E为规模的指数，EM为工作量乘数，n为描述软件项目特征的成本驱动因子的个数
COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。
- 计划阶段：项目通过构建原型来解决用户界面、软件、交互、性能、技术成熟度等方面的高风险问题；在这一步，使用应用点AP来进行规模测量，比如估算屏幕数、报表数、组件数等。
- 早期设计阶段：已经决定将项目开发向前推进，但是设计人员必须研究几种可选的体系结构和操作的概念；在这一步，使用需求文档中的功能点FP来进行规模测量。
- 后体系结构阶段：开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素（开发已经开始，软件已经被部分构造出来）。
例题：该软件（ATM软件）涉及11个屏幕（3个简单，3个中等，5个复杂），10个报表（4简单 6困难），72构件，复用度20%，开发者经验能力高、对环境熟悉度低、劳动力价格5000元/人/月。
计算工作量E和人工成本C
OP = (3*1 + 3*2 + 5*3) + (2*4 + 8*6) + 10*72 = 800
NOP = OP*(1 - r) = 800*(1-0.2) = 640
PROD = (25 + 7 )/2= 16
E = NOP/PROD = 640/16 = 40
C = E * 人工价（元/PM） = 40*5000 = 20万
3.4 风险管理
3.4.1 什么是风险
5-1. 什么是软件风险
概念：风险是带有负面结果的，开发过程中不希望出现的事件
方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）
3.4.2 风险管理活动
5-2. 风险管理活动
评估、分析、优先级xx、控制
风险评价：风险识别，风险分析，风险优先级分配
风险控制：风险降低，风险管理计划，风险化解
3.4.3 风险控制
5-3. 降低风险的策略
(1) 三种降低风险的策略
- 避免风险（Avoiding the risk）：改变功能和性能需求，使风险没机会发生。比如用 C 语言的程序有内存泄漏的风险改用 Java，避免风险。
- 转移风险（Transferring the risk）：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。
- 假设风险（Assuming the risk）：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。
(2) 主要的风险管理活动
- 产品过大：从一个小的产品内核开始，在以后的开发循环中再添加各种功能。过难或是复杂的功能：在工程开始时化简这些功能，再考虑它们的代替品。
- 系统支持问题：建立一个早期原型或者小产品版本，以确定你了解支持系统是如何工作的。（通过对核心功能的测试，可以确定其他系统对本软件的系统支持程度）
- 测试时间：按照 TSPi 进行工作，使用规范的 PSP 方法。
- 产品控制：这就是在工程开始时进行配置管理的原因。
- 协同工作问题：工作人员合理搭配问题
3.5 项目计划（Project Plan）
与客户就风险分析和管理，项目成本估算，进度和组织结构进行交流使用的文档。这相当于这一部分内容的最后呈现方式。