下载掌阅APP，畅读海量书库
立即打开
软件项目本身是复杂的，如果没有仔细地计划，复杂的项目是不可能成功的。一个计划良好的项目将受到有效的控制，进展明显，而参加该项目的人员都会得到支持以进行其工作。软件项目本身也具有风险性，如果没有有效的风险管理也是不能成功的。
通常软件工程项目的管理比其他工程项目的管理更困难，这是因为：
● 软件产品不可见。开发的进度及产品的质量是否符合要求不明显，比较难进行把握。
● 没有标准的软件过程。尽管近几年来“软件过程改进”领域有许多进步，但由于团队、人员的个性化因素，还不存在一个放之四海皆真理的标准化软件过程。
● 大型软件项目常常是一次性项目。由于这些项目都是“前无古人”的，因此缺乏可以借鉴的历史经验。
软件工程项目管理的对象是软件工程项目，它涉及到整个软件开发过程。最核心的内容就是在成本、质量与进度之间做出平衡的取舍，如图4-8所示。
图4-8 项目管理铁三角
抽象地说，其实软件项目管理也十分简单，主要包括POIM四个方面：即Plan（计划）、Organize（组织）、Implement（实现）、Measurement（度量）。细化地说，主要包括以下一些主要的活动。
通常，在启动软件项目之前，需要确定出项目的目标和范围，并根据这些东西来考虑解决方案，然后根据解决方案进行社会、经济、技术可行性分析，以确定是否启动项目。
然后再根据合理的、精确的成本估算，对其进行切实可行的任务分解，以及管理的进度安排，也就是完成最初的项目计划。
在管理学中有一句名言：“如果不能够用数字来描述它，那么说明你还没有了解它”。在软件开发过程中也是一样，度量是帮助有效地定量管理的基础。度量的目的是为了把握软件工程过程的实际情况和它所生产的产品质量。
制定项目计划是一个十分关键、重要的活动，但要想做出合理、有效的项目计划，就必须对需要的人力、项目的持续时间、成本做出相应的估算。
估算的基础是历史数据及经验模型。估算通常可以使用“自顶向下”和“自底向上”两种模型，在估算的过程中常见的经验模型包括FP（功能点）和COCOMO系列。而要想获得更加准确、符合项目组队实际情况的估算值的话，就必须建立完整的历史项目资料库。
正如Tom Gilb在其与软件工程管理相关的一本著作中说过：“如果谁不主动攻击风险，那么它们就会主动地攻击谁。”项目中风险无处不在，但却有很多项目管理者对此熟视无睹，从而带来了许多巨大的损失。在系统开发过程中，对潜在的风险进行分析，记录下来，按其发生的可能性和影响性进行排序，并制订相应的解决方案和预防措施。
试想，如果风险按你的预料“如期而至”时，你从容不迫地按照预算设定的解决方案来解决，将会给团队多大的信心？
每一个软件项目都应该制定一个进度安排，而制定进度计划时需要考虑的问题包括：预先如何对进度进行计划？工作如何到位？如何识别定义的任务？如何监控任务的完成？如何设立分隔任务的里程碑？
进度安排通常是建立在WBS（工作任务分解）的基础上，对时间、人员、设备等资源进行统一的分配，根据估算的工作量进行计划。最常见的进度计划的工具包括甘特图、PERT图等，而Microsoft Project则可以帮助使用者更好地应用这些工具进行进度的管理。
正如拿破仑所说：“没有一场战争是按计划完成的，但没有一场战争没有计划”，这句话辩证地说明了计划与执行之间的关系。只有计划没有执行项目是不可能成功的，因此我们需要对计划进行有效的追踪和控制，根据实际的执行情况对其进行有效的调整。
如果从项目的实施过程的工作性质进行划分的话，那么整个软件项目开发过程可以分成三个主要阶段。
● 项目启动阶段：项目立项、项目初步需求调研/可行性分析、项目初步计划。
● 项目实施阶段：这个阶段的整个过程如图4-9所示。
图4-9 项目实施阶段
也就是说，项目经理在项目实施过程中的工作是：制定计划（计划），按计划布置任务（组织、实现），并在过程中不断地对进度进行监控（度量），根据实际进度情况调整计划，并处理需求变更引起的项目计划变更。
● 项目关闭阶段：组织验收测试，组织项目回顾，存储项目数据。
在计算技术发展的早期，软件的成本在整个计算机系统的总成本中占的只是一个较小的百分比，因此即使软件项目估算有很大的误差，对整个项目而言影响还是相对较小的。但随着信息化的深入普及与发展，软件在整个项目中的比重也越来越大，因此如果无法精确地进行软件项目的估算，将会给整个计算机系统的预算带来很大的麻烦。
软件项目的估算策略包括“自顶向下”和“自底向上”两种，而估算的内容主要包括：软件规模估算、软件工作量估算及成本估算三个方面。
不同的估算策略能够应用于不同的场合，也将带来完全不同的效果。
自顶向下的估算法，通常是由项目经理自身或者是以项目经理为主的一个核心小组（通常包括分析师、构架师、主程序员等主要的角色）来完成的。其工作的特点是：先根据用户、决策者的要求，确定一个时间期限。然后根据这个时间期限进行分解，将开发工作进行对号入座，以获得一个可以满足这个期限的估算。
这种方式是一种通常采用的方法，但其并不能够有效地解决项目估算的问题，经常容易使得估算值与实际值产生很大的差异。
自底向上估算法则采用了一种完全不同的策略。首先在核心小组内进行头脑风暴，完成工作任务分解，直到每一个任务块都小到能够得出合理的估算为止（通常是两周以内的工作量）。然后将每个任务根据项目成员的技能特点、兴趣特长进行分配，并要求其对此做出估算。最后将这些估算值合并在一起，得到总的项目估算。
这种方式通常能够得到较为客观的、可操作的估算结果，而且还能够使得项目组成员主动地参与，并且通常能够对自己所做的承诺全力守信，从而为项目树立了一个良好的文化。但由于其通常得到的值要远比预期的值大，时间更久，因此许多项目不能够有效地使用它。
软件规模也就是需要完成的工作范围是多少，这个估算结果是整个软件项目估算的基础。对于软件规模估算来说，最常见的是LOC和FP估算法。
也就是估算软件的代码行数（Line Of Code），通常使用KLOC（千代码行）为单位。这种估算的基础是将软件项目切分为一个个小模块，然后通过历史的项目经验数据，以及开发人员的经验，对其需要的LOC数进行估算。
FP（功能点）是一种衡量工作量大小的单位，它的计算方法是：功能点=信息处理规模×技术复杂度。其中，技术复杂度=0.65+调节因子。
（1）信息处理规模
FP方法通过外部输入数、外部输出数、外部查询数、内部逻辑文件数、外部接口文件数五个方面来衡量整个软件系统的信息处理规模。计算的方法如表4-16所示。
表4-16 FP基本功能点计算公式
（2）技术复杂度
而技术复杂度是从数据通信复杂度、分布式处理复杂度、性能复杂度、配置项负载复杂度、事务率复杂度、在线数据项复杂度、用户使用效率复杂度、在线更新复杂度、复杂处理复杂度、重用性复杂度、安装容易程度复杂度、操作容易程度复杂度、多个地点复杂度、修改容易程度复杂度14个方面进行微调。每个方面都根据其复杂程度，在0～0.05之间取值。将这些值全部相加就可以得到调节因子，再加上0.65就可以得到技术复杂度。
当通过LOC或FP估算获得了软件的规模之后，就可以进行工作量的估算了。工作量的单位通常是人月（对于大项目可以用人年，小项目则可以用人天）。从中不难得知，软件工作量的获得应该是：规模/产能=工作量。
例如，如果估算出项目需要5KLOC，而每个人一个月的产能是1KLOC的话，那很显然需要5个人月的时间来完成该项目。从中，我们也可以看出建立项目过程数据库，保存这些数字对于估算而言是十分重要的。
如果你没有足够的可类比的项目数据做参照，那么也可以借助一些经验模型来进行估算，从而获得软件的工作量和进度的值。常见的经验模型包括大名鼎鼎的COCOMO，以及相对较简单的IBM模型、普特南（Putnam）模型三种。
IBM模型是Walston和Felix在1977年发布的，是基于IBM联合系统分部负责的60个项目的数据进行总结而得到的。
E=5.2×L 0 .91 （E为工作量，单位为人月；L为源代码行数，单位为KLOC）
D=4.1×L 0 .36 =13.47×L 0 .35 （D为项目持续时间，以月计）
S=0.54×E 0 .6 （S是人员需求量，以人计）
DOC=49×L 1 .01 （DOC是文档数量，单位为页）
从上面可以看出，IBM是一个静态的模型，而其取样只有60多个项目，因此有很大的局限性，有时需要根据具体的情况，对公式的参数做一定的修改。
这是普特南在1978年提出的一种动态多变量模型。它通过建立一个“资源需求曲线模型”来导出一系列等式，模型化资源特性。而这个曲线称为Rayleigh-Norden曲线。它所导出的“软件方程”如下所示：
其中， td 是开发持续的时间，以年计； K 是软件开发与维护在内的整个生存期所花费的工作量，以人年计； L 是源代码行数，以LOC计； Ck 是技术状态常数，它因开发环境不同而不同。如果开发环境较差（没有系统开发方法，缺乏文档与评审，批处理方式），则通常取值为2 000；如果开发环境较好（有合适的系统开发方法，有充分的文档与评审，交互执行方式），则通常取值8 000；而如果开发环境较优（有自动开发工具和技术），则通常取值为11 000。
COCOMO模型是TRW公司开发的，是软件工作量估算的最有代表性的方法。在该模型中将使用到以下三个基本量：
● DSI（源指令条数）：只包括有效的代码，不包括注释语句，如果一行有两个语句，则算一条指令。1KDSI=1024DSI。
● MM（开发工作量）：单位为人月。定义1MM=19人天=152人时=1/12人年。
● TDEV（开发进度），单位为月，由MM决定。
而COCOMO模型将项目分成为三种类型：
● 组织型：相对较小、较简单的项目。通常需求不是很苛刻，开发人员比较熟悉项目目标，掌握了充分的技能，硬件约束少，规模小于5万行。多数应用程序、操作系统、编译程序属于此种。
● 嵌入型：硬件、软件和操作限制较多，常与硬件紧密结合。大型的复杂事务处理程序、操作系统、控制系统、指挥系统属于此种。
● 半独立型：要求介于以上两者之间，规模和复杂性中等以上，最大可达30万行。大多数事务处理系统、新的操作系统及数据库管理系统、简单的指挥系统属于此种。
根据考虑的因素的多少，详细程度的不同，可以将COCOMO模型分为三种：基本COCOMO模型、中间COCOMO模型和详细COCOMO模型。
● 基本COCOMO模型：也是一种静态模型。
▶ 组织型：MM=2.4（KDSI） 1 .05 TDEV=2.5（MM） 0 .38
▶ 嵌入型：MM=3.6（KDSI） 1.20 TDEV=2.5（MM） 0.32
▶ 半独立型：MM=3.0（KDSI） 1.12 TDEV=2.5（MM） 0.35
● 中间COCOMO模型：先根据基本COCOMO模型计算出工作量（MM），然后再使用下列公式对其进行调整，最后算出开发所需时间（TDEV）。
其中 f i 是指15个影响软件工程量的因素，包括软件可靠性、数据库规模、产品复杂性、时间限制、存储限制、机器、周转时间、分析员能力、工作经验、程序员能力、工作经验、语言使用经验、使用现代程序设计技术、使用软件工具及工期等。
● 详细COCOMO模型：在中间COCOMO模型的基础上，针对每一个影响因素按模块层、子系统层、系统层，做出三张工作量因素分级表，供不同层次的估算使用。
当估算出工作量（也就是人月数），以及知道的人员需求量、项目的持续时间之后，就可以进一步进行成本估算。也就是将人员的工资及相关管理费用之和，去乘以其所需要的时间，就可以得到人员成本。
最后再加上相关的资源成本（如软硬件资源）、日常相关的其他开支成本等，就可以得到一个相对准确的成本估算值。
在日常的估算活动中，还可以采用一些相关的辅助方法，最常见的包括Delphi及Standard-component两种，如图4-10所示。
● 召集一组专家，每人发一份问题描述和估算表；
● 让他们一起讨论项目目标和假设；
● 匿名提交一份项目任务列表和估算；
● 由主持人将结果绘制成一系列估算结果表；
● 在每个专家的表中，除该专家的值标明，其他的均匿名；
● 专家讨论该结果，对自己估算进行修改；
● 经过2～3回合，得到一致的结果。
图4-10 专家估算表
为了使得估算值更为准确，我们也可以借助以下公式来进行调整：
估计值=（乐观值+ 4×最可能值+悲观值）÷6
从项目经理的角度来看，整个项目实施的过程，就像驾车开往某地一样。首先要根据目的地的距离（类比项目的需求范围）、车况（类比团队的人员结构、平均产能）、时间的要求（完成期限）来制订合理的行驶计划（类比软件的项目计划）。
接着，就按照既定的计划执行。
在这个过程中，每隔一段时间检查一下进度情况，也就是通过观察里程碑，来确定自己已经行驶过的路程（即已完成的部分），并与计划进行比较，然后根据实际的情况，调整计划。例如，如果全长300千米，预计3小时完成，而1小时后，你发现由于路上遇到了一些问题，只行驶了80千米，那么，若要按计划完成，则必须提高时速。这就是监控和计划修正的过程。
另外，如果在行驶的过程中，你得到了新的指示，目的地有了改变（类比项目的需求变更），那么也需要停下来，重新制订计划。
项目计划的优劣，直接影响到是否能够准确地进行进度的监控、人员的安排等各方面的事情。因此，可以说在某种意义上项目计划直接决定项目的成败。
那么项目计划应该如何来制订、修正呢？项目计划包括两个部分：项目组计划和个人项目计划。正如表4-17所示，在整个项目过程中，项目计划是一个逐步求精的过程。
表4-17 项目计划逐步求精过程
而这些计划的编制，应该包括两个重要的图表：人员职责矩阵和甘特图（也可以用PERT图），如表4-18和图4-11所示。
表4-18 人员职责矩阵
图4-11 甘特图示例
在项目的实施阶段，需要不断地进行进度的监控，并且根据监控的结果修正项目计划，并将项目进度的实际情况通报市场部门相关人员，并且让客户了解实际的进展。
对于项目经理来说，不同的阶段中，进度监控工作有一些不同。在需求分析、系统分析与计划两个子阶段，可以将生成的文档等制品通过评审作为里程碑，跟踪完成的情况，还分析是否按进度进行。而在编码/单元测试阶段则可以基于每个开发小组（也可以是1个人）的微进度计划来做EVA分析。下面我们主要说明如何采用EVA分析法进行进度的监控。
已获值分析（EVA）是最常用的项目进度监控方法。EVA是通过计算实际已花费在项目上的工作量，来预计该项目所需的成本和完成时间日期的一种方法。它依赖于“已获值”的测量，“已获值”使用了以下3种数据。
● 对已完成的工作部分，原来预算花费的成本（BCWP），即“完成了多少工作？”；
● 对已完成的工作部分，实际花费的成本（ACWP），即“我们实际花费了多少成本？”；
● 原计划到分析日期为止的总成本预算（BCWS），即“到该日期原来应该完成多少工作？”。
你可以根据需要每周或每月计算一次，在我的实践中是采用每周计算一次的方法。
从上述的3个基本数据中，可以得到四个确定进度情况的数据。
（1）进度偏差（SV）
计算公式：SV=BCWP–BCWS
如果SV等于0，说明项目完全按进度进行；如果SV小于0，说明已落后进度；如果SV大于0，说明超前于进度。
（2）进度效能指标（SPI）
计算公式：SPI=BCWP/BCWS
如果SPI为1，说明项目按进度表进行；如果SPI小于1，说明落后于进度；若SPI大于1，说明超前于进度。
（3）成本偏差（CV）
计算公式：CV=BCWP–ACWP
如果CV等于0，说明项目按预算进行；如果CV小于0，说明超出预算；若CV大于0，说明低于预算。
（4）成本状况指标（CPI）
计算公式：CPI=BCWP/ACWP
如果CV等于1，说明项目按预算进行；如果CV小于1，说明超出预算；若CV大于1，说明低于预算。
通过这些数据，我们还可以预测项目的进度与完成时间：
● BAC：原来的总预算成本。
● EAC：预计项目的最终成本，用于在过程中估计项目的最终成本，EAC=BAC/CPI。
● SAC：预计项目的最终进度，用于在过程中估计项目的完成时间，SAC=进度/SPI（进度是指计划完成任务的时间）。
● VAC：预计总成本偏差，VAC=BAC–EAC。
下面，就将EVA分析法实际地应用到项目中去。例如，某个构件的开发人员小组制定的微进度计划如表4-19所示。
表4-19 某构件的微进度计划
（续表）
根据这样的微进度计划，我们可以得到这个构件组的计划工作量（BCWS）：
● 第1周：BCWS=5。
● 第2周：模块开发是跨2～3周的工作，预计在本周将获取15人日的价值，累计后BCWS=15+5=20。
● 第3周：模块开发的延续，获取6个人日的价值，加上单元测试、模块集成，共有6+3+4=13个人日，累计BCWS=33。
当项目进行一周后，周五下午，项目经理和构件开发组成员共同进行已获值数据采集，统计出BCWP。如表4-20所示是进行了2周后的已获值分析情况。
表4-20 已获值分析
而ACWP则是已付出的人日。第1周投入1个人工作5天，计5人日；第2周则投入了3个人，工作5天，不过其中有1个人被抽调出1天，因此合计为5*3–1=14人日，合计已投入19人日，即ACWP=19。
通过上面的分析，得到：
BCWS=20
BCWP=17.6
ACWP=19
于是：
SV=BCWP–BCWS=17.6–20=–2.4（你落后于进度）
SPI=BCWP/BCWS=17.6/20=0.88（你以进度计划的88％效能在工作）
CV=BCWP–ACWP=17.6–19=–1.4（你已超出预算1.4人日）
CPI=BCWP/ACWP=17.6/19=0.926（你以超出预算约7.4％的状态在工作）
预测：
EAC=BAC/CPI=33/0.926=35.6人日
VAC=BAC–EAC=33–35.6=–2.6人日（你将超出预算2.6个人日）
SAC=3/0.88=3.4周（原计划3周，估计你将花费3.4周）
当你遇到这样的情况时，就需要问自己：为何比计划多花费了工作量？项目计划合理吗？理解任务吗？是否有分心的事？有什么未发现的障碍？然后对项目计划进行适当的调整，并与开发人员一同寻找解决方案，然后修正项目计划。
项目经理根据监控的结果，编写项目进度周报，提交给市场部门的相关人员，并由市场部门相关人员，将其以另一种形式反馈给客户。
另外，项目经理可以根据项目的进度情况，更新跟踪甘特图。跟踪甘特图是在甘特图的基础上，加上以红色箭头一目了然地表示出进度的完成情况，如图4-12所示就是一个跟踪甘特图的实例。
图4-12 跟踪甘特图示例
在图4-12中，红色虚线代表现在的时间，左边是过去，右边是将来。而红色箭头线则表示完成情况。从上图中，我们可以发现“代码视图”工作已经落后于进度了。在实际应用中，你可以使用Project来完成甘特图和跟踪甘特图的制作。
我们为什么要在软件项目中进行风险管理呢？一是关心未来，风险是否会导致软件项目失败；二是关心变化，在用户需求、开发、技术、目标机器，以及所有其他与项目有关的实体中会发生什么变化；三是必须解决选择问题：应当采用什么方法和工具，应当配备多少人力，在质量上强调到什么程度才满足要求。
风险管理通常包括3个主要活动：风险识别、风险估计和风险驾驭。
可以用不同的方法对风险进行分类。从宏观上来看，风险可以分为项目风险、技术风险和商业风险。项目风险识别潜在的预算、进度、个人、资源、用户和需求方面的问题。技术风险包括识别潜在的设计、实现、接口、检验和维护方面的问题。而商业风险则主要来源于市场。
风险识别的重要工作就是将潜在的风险找到，文档化。
风险估计使用两种方法来估计每一种风险。一种方法是估计其发生的可能性；另一种方法是估计它可能带来的破坏性。然后根据这样的结果对其进行排列优先级，对于那种可能性大、破坏力也大的风险就应该更加重视，拟定相应的解决方案才能够有效地防范。
风险驾驭是指利用某种技术，如原型化、软件自动化、软件心理学、可靠性工程学，以及某些项目管理方法等设法避开或转移风险。