【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）

🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客

💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光

1. 前言

2. 章节概述和章节框架

3. 计划和管理项目

3.1 时间计划

3.1.1 关键概念介绍

3.1.2 活动图

3.1.3 估算项目完成时间

3.2 工作量计划

3.2.1 专家估算法

3.2.2 算式估算法

3.3 人员管理

3.3.1 人员选择的要求（软件人员应具备的能力）

3.3.2 工作方式

3.3.3 项目（团队）组织

3.4 风险管理

3.4.1 什么是风险

3.4.2 风险管理活动

3.4.3 风险控制

4. 总结

1. 前言

在进入本篇文章前，大家可以先去看看另两篇文章：【软件工程】第一章·软件工程概述-CSDN博客

【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客

首先想带大家先来复习一下前面的内容：

第一章·软件工程概述：

1、软件工程是什么——定义、方法、作用。

2、软件工程的前世今生——出现的问题（error、fault、failure）、应对方法（问题分析方法+系统化方法+工程化方法）。

3、软件工程的未来——Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原始模型、测试代码、工具和集成环境）

第二章·软件过程与生命周期：

1、过程与生命周期是什么

过程是一系列有序的任务，涉及活动、资源和约束（过程不是步骤而是步骤的集合）。
生命周期是软件从概念、实现、交付到使用、维护的整个过程。软件开发全过程称为软件生命周期。

2、过程模型

种类：瀑布模型、原型化瀑布模型、V模型、原型化模型、阶段化开发模型、螺旋模型、敏捷方法模型
联系：
瀑布模型是基础。
原型化瀑布模型结合原型化模型与瀑布模型（设计阶段产生原型化模型，在测试阶段考虑是否返回）。
V模型（将设计与测试之间都建立起通道）。
原型化模型（不是具体模型，是一种思想，每一个步骤都可以产生原型去分析）。
阶段化开发模型（开发版本和使用版本分离，分离导致需要选择迭代开发/增量开发/迭代进化开发/统一过程开发）。
螺旋模型（是迭代思想和原型化思想的结合）。
敏捷方法模型（撇弃原型化和迭代化带来的冗余，将目标转化为：快【尽早交付】、准【持续有价值的软件交付活动】、狠【直到客服满意】）（四大原则：个体和交互胜过过程和工具、可运行软件胜过面面俱到的文档、客户合作胜过合作谈判、响应变化胜过遵循计划）
核心思想：迭代思想、增量思想、原型化思想

2. 章节概述和章节框架

明确一个点：Wasserman 规范贯穿软件开发全过程

章节联系：Wasserman 规范中第一个是抽象，抽象针对的是问题分析以及问题分析后对整个项目的把控。

思考：只有抽象去思考，才能抓住问题的重点；只有抽象去思考，才能分析整个项目的重点完成项目计划和管理。

本章在软件工程中处于前期总览全局的位置，它关系着整个项目的进度计划，人事结构和成本分析。这一部分是客户考量项目的关键，回答了客户关心的多长时间做完和花费多少预算做完的 how long and how much 问题，直接关系着预算与经费，是一个项目负责人应当格外重视的部分。这一章的工作体现在制作出项目计划文档中，通过文档内容与客户进行交流展示。从课程角度，这一部分的活动图分析和概念解析是重点，需要用心掌握。

3. 计划和管理项目

如果要开始一个项目，我们需要跟客户讲述一下我们要做哪些工作来实现这个项目，做多长时间，用多少花费。回答不上这些问题估计客户是不敢找我们干的，回答这些问题就需要我们：
        （1）首先有明确的实现项目的各个步骤活动的具体时间计划
        （2）干的时候十分清楚自己干到了哪一步
        （3）预估整体的预算是多少，凭什么值这个价。
基于这些需求，我们有了这一部分的内容，即，我们怎么跟踪项目进展到哪里了？怎么组织人去完成项目？怎么预估工作量？怎么通过风险管理节约成本？这些都是站在一个项目负责人的角度应当考虑的问题。

计划和管理项目四个方向：

        1、时间计划；

        2、工作量计划；

        3、人员管理；

        4、风险管理；

3.1 时间计划

时间上确定该怎么做，做到哪里了？

3.1.1 关键概念介绍

(1) 项目进度（Project Schedule）
项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。
(2) 项目活动（Project Activity）
项目的一部分，一般占用项目进度计划中的一段时间（活动图中的线表示项目活动）
(3) 里程碑（Milestone）
指特定的时间点，标志着活动的结束，通常伴随着提交物。（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）（活动图中的圆圈表示里程碑）

利用活动图来巧记项目进度的定义：

1、分解项目步骤、活动、阶段（活动图中一个个圆圈之间的连线）

2、描述离散活动的交互关系（活动图中将圆圈彼此相连）

3、估算各个活动完成时间，以及整个项目完成时间（活动图中每个线上面的时间）

3.1.2 活动图

描述了活动和活动间依赖关系的图，其中节点表示项目的里程碑（活动结束），线表示活动。如图例中 A->B 的部分表示 A->B 的这条线代表的这个活动从 A 开始，需要做 3 天，才能结束，到达 B 里程碑（标志着 A->B 这条线代表的活动的结束）。一定要十分注意这一点，图中的点并不代表活动，并不能说活动 A 用 3 天到达活动 B，这是不准确的，如到达 I里程碑的边有两条，D->I, B->I，意思是有两个活动，完成后到达里程碑 I，并不能说 I是个活动，如果这么理解会在计算最晚开始时间时出现错误。

3.1.3 估算项目完成时间

有了活动图后，我们想要估算项目完成时间，本质上就是要计算关键路径的完成时间。

而想要求解出关键路径的完成时间，就要求解出关键路径。

求解关键路径，就需要知道每一个活动的最早/最迟开始时间，若相等则该活动是关键路径上的。

我们的任务就转变为求解关键路径、最迟开始时间、最早开始时间、冗余时间。

定义：1、ET为最早开始时间； 2、LT为最迟开始时间

求解：

正推求最早开始时间

公式： $\mathrm{ET}_{\mathrm{B.}} =\operatorname{MAX}\left(\mathrm{ET}_{\mathrm{AB}}+\mathrm{w}_{\mathrm{AB}}\right)$
已知条件：起点的最早开始时间直接为 1

倒推求最晚开始时间

公式： $\mathrm{LT}_{\mathrm{JK}}=\operatorname{MIN}\left(\mathrm{LT}_{\mathrm{K}} \cdot-\mathrm{w}_{\mathrm{JK}}\right)$
已知条件：终点的最晚开始时间和最早开始时间相同（因为终点一定在关键路径上，关键路径上的点最早开始时间等于最晚开始时间）

估算项目时间思路：

根据起点最早开始时间为1，正推求出所有点的最早开始时间。（MAX与加）
根据终点最早开始时间和最迟开始时间相同，逆推求解出所有点的最迟开始时间。（MIN与减）
找出所有最早时间和最迟时间相同的活动，也就是冗余时间为0的活动
冗余时间为0的活动组成关键路径
关键路径所花费的时间也就是估算的项目时间

得到所有活动的最早开始时间和最迟开始时间的表格如下：

由上述表格可知，AB 、 BD 、 DI 、 IJ 、 JL活动的时差为0，即为关键节点，因此关键路径为 A → B → D → I → J → L = 20 。也就是说整个项目的估算时间也就是20。

3.2 工作量计划

工作量计划也就是工作量估算，分为两个：估、算

估的典型就是：专家估算法（乐悲观估算、Wolverton模型估算、Delphi估算）

算的典型就是：COCOMO模型

3.2.1 专家估算法

很多工作量估算方法依赖于专家的判断。使用专家的知识和经验，对软件项目的工作量进行评估，预测的精确性基于估算者的能力、经验、客观性和洞察力。是对构建整个系统或其子系统所需的工作量做出经验性的猜测。

专家可以通过下面方法完成估算：

3.2.2 算式估算法

普通算式估算法：

研究人员已经创建出表示工作量和影响工作量的因素之间关系的模型。这些模型通常用方程式描述，其中工作量是因变量，而其他因素是自变量。大部分模型认为项目规模是方程式中影响最大的因素，表示工作量的方程式是：

$E=(a+b S c) m(X)$

E 为工作量，a,b,c 都为常数，S 是估算的系统规模，X 是一个 x1…xn 维度成本因素的向量，m 是基于该因素的调整因子。

COCOMO模型：

三个阶段的COCOMO：

基本COCOMO模型

系统开发的初期，估算整个系统的工作量(包括维护)和软件开发和维护所需的时间

中间COCOMO模型

估算各个子系统的工作量和开发时间

详细COCOMO模型

估算独立的软构件，如各个子系统的各个模块的工作量和开发时间

基本COCOMO模型具体公式：

E = a * (KLOC)^b ;

E是工作量(人月) ，a和b是经验常数，KLOC为代码行数（项目规模）

D = c * E^d ;

D是开发时间(月) ，c和d是经验常数,其取值见下表：

相比于普通算式估算，COCOMO更加看重项目规模对工作量的影响

3.3 人员管理

3.3.1 人员选择的要求（软件人员应具备的能力）

（1）完成工作的能力（2）对工作的兴趣（3）开发类似应用的经验（4）使用类似工具或语言的经验（5）使用类似开发环境的经验（6）使用类似技术的经验（7）培训（8）与其他人交流的能力（9）与其他人共同承担责任的能力（10）管理技能

3.3.2 工作方式

外向，内向；感性，理性，不同性格的人搭配会产生不一样的效果。课本上只是粗略的
一个分析。

3.3.3 项目（团队）组织

项目组织的结构化和创造性的关系：

结构化较强的团队：
按时完成任务，单工作比较循规蹈矩，项目普通但是功能完备。适合人员较多，项目稳定性和一致性高，使用较正规的结构。

结构化较弱的团队：
不能按时完成任务但是创造性强，涉及大量的不确定性因素时采用较为民主的方法和相
关的团队结构。

可以参考的组织方式：

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。
优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强
(2) 忘我方法制（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

前者是专制：结构化强创造性低；

后者是民主：结构化弱创造性强

3.4 风险管理

3.4.1 什么是风险

概念：软件生产过程中不希望看到的，有负面结果的事件
方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

3.4.2 风险管理活动

风险评价：风险识别，风险分析，风险优先级分配
风险控制：风险降低，风险管理计划，风险化解

3.4.3 风险控制

(1) 风险降低
        避免风险（Avoiding the risk）：改变功能和性能需求，使风险没机会发生。比如用 C 语言的程序有内存泄漏的风险改用 Java，避免风险。
        转移风险（Transferring the risk）：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。
        假设风险（Assuming the risk）：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

(2) 风险化解（风险+应对方法）
产品过大：从一个小的产品内核开始，在以后的开发循环中再添加各种功能。

过难或是复杂的功能：在工程开始时化简这些功能，再考虑它们的代替品。
系统支持问题：建立一个早期原型或者小产品版本，以确定你了解支持系统是如何工作
的。（通过对核心功能的测试，可以确定其他系统对本软件的系统支持程度）

        测试时间：按照 TSPi 进行工作，使用规范的 PSP 方法。
        产品控制：这就是在工程开始时进行配置管理的原因。
        协同工作问题：工作人员合理搭配问题