《软件项目管理》课件第6章

第6章软件项目进度管理6.1软件项目进度管理概述

6.2软件项目进度安排图示方法

6.3软件项目进度估算方法

6.4软件项目进度计划编制6.5软件项目进度跟踪和控制6.6小结

案例：上大学需要做好时间管理

小刚于2008年考入X大学，攻读计算机科学与技术专业学士学位。报到之后，和同学们一起参加了新生入学教育，知道了该专业的培养目标，而且从学校提供的资料中看到了该专业的培养计划，表6-1是该培养计划的一部分。表6-1计算机科学与技术专业本科培养计划(部分内容)

有了专业培养目标和培养计划，小刚觉得自己只要认真上课就行了。谁曾想大一第一学期，英语考试不及格。第二学期，他的情绪低落，不好好上课，不按照要求学习，结果期末考试，有三门主课不及格，他想主动退学。

后来，在老师的开导和帮助下，小刚认真反思自己存在的问题、分析自己的兴趣和优缺点，以专业培养计划为蓝本，制定了自己的年度学习计划，再以此为基础制定了每学期的学习计划，在每学期开学之初，以本学期课表为参考，制定每月和每周的学习计划，最后将学习任务细分到每天，例如，2009年3月6日的计划如表6-2所示。表6-22009年3月6日(星期五)学习生活计划显然，表6-2所示的计划具有极强的可操作性，关键的问题是能否严格按照计划执行，落实其中的每项任务，并努力实现相应的目标。

为此，小刚给自己制定了奖励和惩罚措施，并将自己的计划告诉同班学习认真的几位同学，还有自己的班主任，获取他们无形的监督，断掉自己不好好学习的退路，很快他就能够严格按照计划开展自己每天的学习和生活，进步非常迅速，学期期末考试的总分及平均成绩在班上名列前茅。后面的大学三年，他一如既往，学会了更好地制定计划、控制进度和追求质量，最终以优异的成绩获得了计算机科学与技术专业的本科毕业证书和工学学士学位证书。小刚对自己的大学四年进行了认真总结，其中包括了以下内容：

1)要做好可行的学习计划、管好时间

为了提高效率，在制定计划时，要适当给自己“压力”，对每一科目的预习、听课和温习要考虑时间、速度、质量的限制，要学会三者之间的协调。这种目标明确、有压力的学习，可以使注意力高度集中，提高学习效率。同时每学习完一部分时，都有一种轻松感、愉悦感，便会更充满信心地学习下去。

2)要注重计划的落实、跟踪与反馈

学习计划一旦制定，就要注重落实。若有完不成的，也应在次日立即加倍补上。同时要反省自己，当天的计划为什么没有完成？明天先干什么？再干什么？怎么干？如果完成的好可自我奖励一下；如果完成的不好必须自我惩罚一次。这样做，既有约束力又有可操作性，每天都会感到进步。一段时间后，还应该根据自己的学习情况，对计划做出进一步调整和完善，以更好地促进学习。每天的上课不算项目，只是日常活动，但是从案例中仍然可以清晰地看到，时间、质量和成本之间相互影响、相互制约的关系，做好时间管理即进度管理在项目实施过程中就显得尤为重要。

进度估算及其管理也是软件项目管理的重要内容之一，也是在软件项目的早期开展的一项重要工作。

6.1软件项目进度管理概述

案例：软件项目延期，原因何在？

W是一家专门从事应用软件开发的公司，目前有员工45人，下设销售部、软件开发部和技术服务部等业务部门，其中销售部主要负责将公司现有的产品推销给客户，同时也会根据客户的具体需要，承接应用软件的研发项目，然后将承接的项目移交给软件开发部，进行软件的研发工作。软件开发部共有开发人员16人，主要进行软件产品的研发，以及客户委托的应用软件开发。技术服务部主要负责本公司售出软件系统的维护与技术支持工作。

2013年1月4日，销售部与×制造公司签订了一个企业内部物流管理系统开发的软件项目，经双方洽谈，2013年6月10日之前必须完成系统开发和测试，并投入试运行，这些都明确地写入了合同中。

合同签订后，销售部将合同移交给软件开发部，公司决定由大李作为项目经理，负责该项目的实施。软件开发部为此项目配备了1名系统分析员、2名程序员(曾参与了2个软件系统的编程工作)和1名技术专家(不太熟悉制造企业内部物流管理的业务)，要求这些成员必须全程参加项目的实施工作。大李是一名经过全国考试认证的系统分析师，作为软件研制的骨干先后参与了10多个应用软件的研发工作，曾担任过系统分析员、系统设计员和程序员，具有比较丰富的软件研制经验。在此之前从未作为项目负责人直接管理过任何软件项目，所以他暗下决心一定要干好这个项目。

于是，大李很快制定了项目的进度计划，如表6-3所示。表6-3×制造公司内部物流管理系统项目进度计划但是，需求分析工作并未在1月7日开始，而是在1月9日正式开始。2月初，大李检查工作时发现需求分析进行的不尽人意，他再三强调需求分析的重要性，同时要求项目组成员努力做好各自的工作。3月初，他再次细致检查系统设计工作的进展，让他感到意外的是总体设计刚刚做完，详细设计还未开始。“这个项目要拖期了？很有可能按时完不成任务？现在该怎么办呢？……？”他的心里开始打鼓，感觉没有什么做的不太合适的地方，一时没了太好的主意。有人积极地帮助他分析了其中的问题。

(1)项目进度计划过粗

(2)人力资源配置欠合理

(3)部分子任务工作量估算不合理

(4)项目疏于进度控制

(5)缺少风险控制措施

……

下面来进一步了解软件项目进度延期频发的一些主要原因，以便今后可以避免这类问题的发生。6.1.1软件项目进度延期的主要原因

1.项目进度本身不合理

当项目进度延迟时，应该首先分析进度计划本身是否合理？影响项目进度计划和安排的因素较多，主要从进度估算、关键资源、人力资源等方面进行分析和考虑。

1)进度估算不准确

估算的准确性是项目进度计划安排中最关键的影响因素之一。估算不准确的原因很多，主要有两个方面：即缺少有经验的估算专家和缺少项目历史数据的收集。对于这两点只有通过多个项目的积累才可能得以改善。另外，估算过程中还需要考虑一些特殊因素的影响，例如项目增加了几名新员工可能会降低项目的平均生产率，项目过程中因为需要采用某种新技术而需要投入额外的预研时间等。

2)关键资源安排不合理

在进度计划安排中未能优先保证项目关键路径上所需的资源，没有通过人员技能矩阵对项目关键资源进行分析和安排。在任务安排过程中要对关键资源进行保护，以尽量减少为关键资源安排非关键任务。在进度计划安排时适当考虑10%～15%的余量，有利于项目遇到突发事件或项目风险转变为实际问题时有能力进行应急处理。

3)人力资源未充分利用

由于存在关键路径和岗位角色矩阵，导致为项目配置的人力资源往往不能得到充分的利用。尤其在中小型项目实施过程中更应该采用敏捷和迭代的开发方法，以充分利用有限的人力资源，例如项目前期开发人员可以参与需求分析和公有组件的开发，而在后期他们也可以参与软件测试。对软件项目而言需要保证项目组成员的整体利用程度达到70%以上，否则就应该考虑采用新的开发模式和生命周期模型。

2.团队及其成员存在负面影响

软件项目中的编程人员的角色类似于建筑工程项目中的泥瓦工和钢筋工等，经常从事创造性的工作，因此软件项目人员的流失往往给项目或软件开发机构带来短时间难以弥补的损失，因为新成员的培训和学习需要较长的时间，个体生产率在短期内很难提高到较高的水平。所以，在软件项目实施过程中开发团队及其成员的业务能力、责任心、交流沟通能力和关键人员对项目的进度和质量有着显著的影响。

1)项目组成员的业务能力不足

在成立项目组时，往往忽视了成员业务能力的差异，事实上并不是每个成员有着同样的水平。如果在任务和进度安排上没有仔细考虑成员个体的生产率差异，造成项目拖期也许就是一种必然的结果。

为了避免这样的问题发生，在项目初期必须对项目成员的业务能力进行全面的评估，对于多数人都欠缺的能力应该安排统一的培训，后续还需要对培训的效果进行跟踪；对于少数能力欠缺的人员不应该让其承担主要任务，可以指定能力强的人员进行指导培养，借机参与主要任务，以期尽快提高业务能力，为后续项目储备人才；对于新员工承担的工作和任务应该加强监督和评审，保证过程和结果不出现大的偏差而导致后续大量的返工。

2)项目组成员的责任心不强

软件项目通常是分阶段、分任务进行的，责任到人，这种情况下项目成员的责任心就成为一个不可小觑的因素，一旦有人敷衍了事，就会导致阶段性成果质量较差，需要大量返工，后继任务迟迟不能开始，继而延误项目整体进度。为了有效防止类似情况发生，项目组就要制定项目规范和标准，能够切实监控实施过程、评价阶段成果。除此之外，项目经理需要加强同责任心不强的成员之间的单独沟通，从正面影响他们的分工协作意识，帮助他们树立正确的价值观和集体荣誉感，加强项目团队的凝聚力，鼓励大家为共同的利益和荣誉而努力工作。

3)项目组成员间的沟通不畅

在软件项目实施过程中，一周5个工作日，如果花了3天时间用于成员之间的沟通，2天时间用于完成具体承担的任务，项目的进度恐怕难以保证。所以如何建立快捷顺畅的沟通渠道，并采用最佳的沟通方式来解决面临的问题，以保证成员之间的高效沟通是项目经理乃至软件开发机构必须做的事情。高效沟通最重要的是花最短时间，采用有效的方法或工具使交流各方达成一致意见。如果出现沟通不畅，必须及时分析和总结原因，选择以下方式中的一种或几种解决此类问题：(a)建立一个项目组局域网，项目非涉密电子资源统一存放在指定的服务器上，方便团队成员共享；(b)建立一个项目组聊天群，按天通报项目进度，方便交流非涉密问题的解决办法；(c)建立项目邮件组，一旦变更达成一致后，发送邮件确认；(d)每周、每天召开交流座谈会，时间不需要太长，注重效果即可；(e)面向项目组成员每周发送项目周报……

4)项目实施期间关键人员流失

软件项目实施期间如果关键成员调离项目组或离开软件开发机构，则有可能导致项目短期停顿，严重时可能造成项目失败。不过这种情况一般很少发生，因为项目经理在项目初期进行风险评估时将这个问题作为高等级风险列入其中，制定了相应的风险跟踪策略和考虑具体的应对措施。

3.质量和时间的制约关系被忽视

时间和质量是项目中两个重要因素，在特别关注项目进度的情况下往往会牺牲项目的质量。由于软件项目中测试环节的引入，就需要保证最终产品满足一定的质量规范。但是项目中经常出现项目后期测试问题太多，BUG修改和回归测试等工作花费了大量的时间而导致项目的进度延迟。

一般情况下项目进度安排不会太宽松，容易促使项目管理者轻视或忽略项目各阶段性成果的质量评审环节。这样以来无形中隐藏了各阶段存在的错误或缺陷，直到项目后期测试时才可能全部暴露出来，如果是需求引起的缺陷，往往会耗费相当于前期评审的5～20倍的工作量来进行处理，反而导致项目拖期。在软件项目实施过程中，必须注重项目各阶段的评审工作，以便提早发现问题并将其解决，避免项目后期大量返工造成进度失控，才能更好地保证软件项目的质量。

4.项目的风险管理工作不够精细

软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。在项目进行过程中，如果项目管理者能够不断对软件风险进行识别、评估、制定策略和监控的话，那么决策将更科学，并从总体上减少项目风险，保证项目的实现。如果项目管理者的风险管理意识淡漠，或对项目可能发生的问题或潜在的不利因素不能精心预测，也不制定有针对性的应对策略，就不会提前采取有效的应急措施，那么当风险在项目实施过程中真正转化为问题后，处理起来将费时费力，项目干系人的工作也会非常被动。导致软件风险的原因很多，例如进度和经费紧张、产品性能要求很高、项目组成员水平差异较大等，所以作为项目管理者，对软件风险要精细化管理，形成一套突发事件的应对机制，能够通过各种方法、工具和冗余资源跟踪和处理软件风险。

5.项目进度管理未能及时响应软件需求的频繁变化

在软件开发过程中用户的需求永远是没有止境的，用户会不停地提出这样或者那样的改进建议，希望软件人员能够满足其要求。在修改这些需求和解决相关问题的时候，会导致另一些功能发生异常，而且这些发生异常的功能模块又可能影响更多的模块。需求频繁变更经常让软件开发方误入“需求陷阱”，在没有很好的应对办法时，加班赶进度就成了家常便饭，即便如此，能否按时保质保量完成项目都可能成为一个谁都不想回答的问题。因此在项目管理过程中应该对需求变更的管理形成一套完善的分析、控制和管理的机制，成立变更控制委员会专门对变更进行分析、调查和处理。

要避免“需求陷阱”，首先要弄清问题的种类。在开发后期，用户所提出的需求(或需要改进的地方)可以分为3类：第一类是影响业务流程的进行，用变通的方式无法解决的问题；第二类是不影响业务流程的进行，但是会降低客户工作效率的问题；第三类是为了让软件使用更加方便，也就是说锦上添花的问题。显然，第一类问题的修改是非常必要的，必须及时修改。第二类问题要看对客户工作效率的影响程度，然后再决定是否进行修改。第三类问题在进度紧张的情况下无需进行修改。考虑到时间和成本制约而未修改的第二类和第三类问题可以统计出来，在以后的升级版本中进行修改。

6.项目技术方案设计和实施时不重视进度约束

项目开发模式、生命周期、开发语言、开发环境、相关工具和技术的选择，在技术方案中都有明确的阐述，这些因素都会直接或间接的影响项目成员的个体生产率，一旦在方案设计之初没有充分考虑进度约束，轻率的给出了相关的描述，而且在后续实施过程中一味地按照方案中的要求去执行，那么项目各阶段的返工恐怕不再是一个偶然事件。在技术方案中系统的总体设计和架构设计是一个非常值得重视的问题。

所以项目管理者在估算和安排进度时，要为系统总体设计和架构设计预备充足的时间，另外设计人员应该重视进度约束，有能力并且通过架构设计屏蔽整个系统的复杂性，向模块设计和开发人员提供一套简单、高效的开发规程和模式，从而真正提高后续设计开发的效率和质量，既保证了项目按进度实施，又能为系统提供一个稳定健壮的架构。6.1.2软件项目进度管理的概念和意义

进度是对执行的活动和里程碑制定的工作计划日期表。进度决定着项目是否达到预期目的，它是跟踪和沟通项目进展状态的依据，也是跟踪变更对项目影响的依据。

进度管理是指运用一定的工具和方法制定项目实施计划，经评审形成基线计划后，在项目实施过程中对项目的实际进展情况进行控制，在与质量、成本目标协调的基础上，确保项目能够按时完成所需的一系列活动。

按时完成项目是项目经理最大的挑战之一，而时间是项目规划中灵活性最小的因素，进度问题是项目冲突的主要原因，尤其在项目的后期。可见，有效的进度管理是项目管理追求的主要目标之一，其意义主要表现在以下几个方面：

1.充分发挥资源效能、节省项目成本、保证软件质量

一般情况下项目范围越大，项目所要完成的任务越多，项目耗时就越长；项目范围越小，项目所要完成的任务越少，项目耗时就越短。如果用户特别要求较短的项目工期，那么项目组在确定其范围时，必须进行范围压缩或分割，要么简化项目的功能和性能，要么项目分期或外包进行，总之，要把项目的范围和进度统一起来与用户协商相关事宜。

例如成本估算既要考虑项目范围和进度，也要考虑用户对软件质量的要求。而在项目实施过程中将性能良好的软硬件资源、优秀的人力资源分配到关键任务和关键路径上，或者在资源充足的情况下安排一些工作并行进行，这能够大幅度缩短各项主要任务的时间开销，项目的整体进度就会加快，以人力成本为核心的软件项目成本也因此而降低。当项目进度紧张，必须压缩工期时，项目的成本将会急剧上升，并且由于加班赶工导致项目质量难以保障。开发方可以采取以下措施保证项目进度：

(1)在用户许可的情况下，缩减项目的部分任务，或者降低部分任务的质量，优先满足项目进度的要求；

(2)增加项目经费投入(无论来源于用户还是开发方)，调配更多的项目资源，使某些工作能够并行完成或者加班完成；

(3)把项目的部分任务外包出去，虽然以增加成本为代价，但能够保证项目的进度。这种情况下采购管理、质量管理和进度管理的协调又将成为开发方的重要工作。

2.有助于形成正确的工作方法，减少时间浪费

软件项目实施包括需求分析、可行性分析、总体设计、详细设计、编码和测试等多个阶段，每个阶段的工作方法正确与否决定着项目干系人花费的时间是超过还是少于计划时间，其结果必然影响项目整体的进度。

例如在需求分析阶段，开发方一开始就采用与用户进行面对面访谈的方法，获得的效果与所花费的时间可能都会让项目组感到十分沮丧。在访谈的过程中，由于开发方对用户的业务背景及其相关术语不甚了解，很容易忽略或听不懂用户讲到的一些术语，花了好长时间却没有完全弄清用户需要解决的问题，这次不行，下次还得再谈，这样的过程可能会重复两三遍。因为开发方和用户毕竟是处在两种或多种知识领域的人，在不太懂对方的专业术语时，谈话要么很谨慎，要么就是相互问得太多，一旦出现没完没了的问题，给面谈双方的感觉肯定不好。

这种效率和效果低下的调研方法将会导致调研时间延长而且调研成本增加，双方的信心和配合程度随着时间的拉扯而逐渐降低。正确的需求调研方法应该是首先进行书面交流，然后熟悉业务流程，再进行面对面访谈，必要时发放匿名需求调查表，甚至召开高层业务主管报告会。

采用上述正确的需求调研方法，看似步骤较多，实际上每个步骤花费的时间并不是太长，而且每个环节都能获得很好的效果，与不停的返工相比，能够有效节约需求调研时间，把富裕的时间留给项目其他阶段，也有助于加快项目进度。

3.有利于培养精诚团结和高效工作的软件项目团队

软件项目团队的成员往往存在着各方面的差异，例如个人性格、兴趣爱好、技术水平和成长经历等，这些差异使得他们在项目组成立初期，需要花时间熟悉组内其他成员、适应工作环境、接受新的工作任务，而且这段时间一般情况下都比较长，留给他们真正工作的时间相对就会减少，这是项目管理者必须应对的挑战之一。善于管理的项目经理通过组织讨论会，让项目组成员尽快知道项目组成立的背景、成员选择的理由、每个角色的重要性、项目的目标、工作范围、质量标准、预算及进度计划的标准和限制，以及项目成功之后开发机构和成员所能获得的效益，激励成员对管理制度和工作环境等方面发表各自的意见和建议，积极参与项目计划的制定工作，从而使成员之间尽快了解对方的优势和不足，以便更加合理的分配任务和安排进度，同时也能很快凝聚人心，形成团队意识，大大缩短项目组成员磨合阶段的时间。

这样，项目组成员真正工作的时间就会相对充裕一些，他们就能从容应对自己或小组承担的任务，精诚团结，高效工作，并很快成长为优秀的软件项目团队。6.1.3软件项目进度管理的过程

1.活动定义

确定为完成软件项目的各个交付成果所必须进行的诸项具体活动。软件活动定义是一个过程，它涉及确认和描述一些特定的活动，需要完成WBS中的细目和子细目。

定义活动的输出结果包括以下内容：

活动目录(也称活动清单)。活动目录必须包括项目中要执行的所有活动，活动目录可视为WBS的细化。活动目录必须是完备的，不包含任何不在项目范围内的活动。

细节说明。细节说明是定义活动的依据，是有关活动目录细节的说明，以方便项目管理过程的执行。细节说明应包括对所有假设和限制条件的说明，细节说明也应文档化。

WBS结构的更新。在利用WBS进行定义活动的过程中，随着对软件项目认识的不断加深，如果发现WBS中任务的遗漏或错误要及时加以更新。

2.活动排序

活动排序就是确定活动间的相关性，并根据这些相关性安排各项活动的先后顺序。某个活动的执行必须依赖于某些活动的完成，即某个活动必须在某些活动完成之后才能开始。活动必须被正确地加以排序，以便制订切实可行的进度计划。活动排序可由计算机或手工完成，对于小型项目手工排序很方便，对于大型项目早期用手工排序也很方便，但对于大型项目应该把手工编制和计算机排序结合起来效果更好。在确定活动之间的先后顺序时有以下三种依赖关系：

强制性依赖关系(MandatoryDependencies)。强制性依赖关系指工作性质所固有的依赖关系，也称为硬逻辑关系(HardLogic)，它们往往涉及一些实际的限制。项目管理团队在确定活动先后顺序的过程中要明确哪些依赖关系属于强制性的，例如在施工项目中只有在基础完成之后才能开始上部结构的施工；在软件项目中必须在完成原型系统之后才能进行测试。软逻辑依赖关系(DiscretionaryDependencies)。软逻辑依赖关系是指由项目团队确定的依赖关系。这种依赖关系要有完整的文字记载，因为它们会造成总时差不确定、失去控制并限制今后进度安排的选择。软逻辑依赖关系有时称为优先选用逻辑关系、优先逻辑关系或者软逻辑关系(SoftLogic)。项目管理团队在确定活动先后顺序的过程中要明确哪些依赖关系属于软逻辑的。可以根据具体应用领域内部的最好做法来安排活动的关系，也可以根据项目的某些非寻常方面对活动顺序做出安排，通常根据以前成功完成类似的项目经验，选定活动的关系。外部依赖关系(ExternalDependencies)。外部依赖关系是指受项目外部因素制约的那些依赖关系，涉及项目活动和非项目活动之间的依赖关系。项目管理团队在确定活动先后顺序的过程中要明确哪些依赖关系属于外部依赖的，例如学校图书馆建筑施工项目的场地平整，可能要在项目外部的校园环境听证会之后才能动工；软件系统的试运行可能取决于来自外部供应商提供的硬件是否安装。这种依赖关系的活动排序可能要依靠以前类似性质的项目历史信息或者合同和建议。

软件项目活动排序不仅要考虑它们之间的依赖关系，还要考虑它们之间的时间关系，如图6.1所示。图6.1软件项目活动(任务)之间时间依赖关系(活动之间的时间依赖关系表明了活动的开始和结束之间的逻辑，最常见的是结束—开始关系)图6.1(a)是一种结束—开始关系，表示A活动结束，B活动才能开始，A活动是B活动的前置任务，是最常用且风险最低的一种依赖关系。例如，软件原型系统完成，才能对其进行测试；硬件选型完成，才能进行硬件安装。

图6.1(b)是一种结束—结束关系，表示A活动结束，B活动必须结束。A和B往往是后续某一项活动的前置任务。例如，硬件安装结束时，软件编码和测试必须结束，只有这两个任务都完成，后续的系统安装和测试才能开始。图6.1(c)是一种开始—开始关系，表示A活动与B活动同时开始。这种情况下两项任务没有紧密的前后紧随关系，认为它们可以同时开始，只是通过并行安排工作，以便缩短项目的进度。例如需求获取和项目规划就可以同时开始。

图6.1(d)是一种开始—结束关系，表示B活动结束时，A活动必须开始。这是一种最容易出错的逻辑关系，实际工作中很少使用。

3.活动历时估计

在确定活动的顺序后需要估计活动清单中的每项活动任务从开始到完成所需的时间。活动的持续时间是一个随机变量，无法事前确切地知道活动实际需要的时间，只能进行

估计。

通过对活动目录、约束条件、各种假设、资源需求与供给以及历史资料的分析，再进行活动历时的估计将使估计的时间尽可能地接近现实，以便于项目的正常实施。活动目录/清单。由活动分解和定义过程产生的目录/清单，包括了项目中所要执行的所有活动。活动目录可视为WBS的一个细化。活动目录应是完备的，它不包含任何不在项目范围里的活动。活动目录应包括活动的具体描述，以确保项目团队成员理解工作该如何去做，这样才能确保估计的准确性。

约束条件。约束因素将限制项目团队对时间的选择余地。具体地讲，例如学生学籍管理系统项目在大学和在中学进行就会有一些不同，系统管理的内容和任务量会有很大差别，需求分析这项活动持续时间的估计就会不一样。又如给软件系统限定了运行环境的项目，都将对项目形成约束条件。因此在不同的时间和地点，进行的同一类型项目会具有不同的约束因素，需要具体情况具体分析。各种假设。项目实施过程中会有很多可能发生的事情，例如参加项目的人员可能在项目开发过程中请病假、事假、其他公务外出、甚至离职等情况。这时需要假设这些因素对活动持续时间的影响。当然假设是对风险确认的结果，也需要考虑这些因素的真实性和确定性。例如在很多情况下，给科研项目研究人员分配工作时间时，不是一年12个月，往往骨干成员是8～10个月，其他成员是4～6个月。这说明，事实上能够一年全天候为项目工作的项目成员基本上没有的。这与罗德尼·特纳(J·RedneyTurner)的建议是一致的，他认为平均对于每个项目的工作人员来说，假设每年工作260天，一些项目全职人员只有70%的可用性，实际上他们一年的工作时间是180(260×0.7)天。因此在估计活动历时的时候，应该在估算出来的持续时间基础上乘以1.4(1.0/0.7)，从而得到一个切合实际的历时估计。然而，因为项目的规模大小不一，整个持续时间长短也有很大差异，进行假设和选取影响系数，所以需要具体情况具体分析。

资源需求与供给。项目中多数活动所需时间由相关资源多少所决定。例如一项活动，如果由2个正常水平的技术人员承担，需要用5个月来完成，如果由同等水平的4个人承担，需要2.5个月完成，如果由2个高水平的技术人员承担，需要用4个月来完成。很显然软件项目中人力资源、个体生产率、软硬件性能和工作环境等资源的数量和质量对项目持续时间的影响必须给予重视。这也要求项目管理者能够科学地分配和管理项目资源。类似项目活动的历史资料。相关类似项目活动的档案和专业数据等历史资料，对于估计活动所需的时间是有参考价值的。当活动所需的时间不能由实际工作内容推算时，可通过分析这些历史资料，帮助估计新项目中部分活动的持续时间。

当活动所需的时间估计出来以后，活动目录中应该增加各项活动的持续时间，并在相关文档中提供估计依据和细节，以便确保在制定进度时所用的假设合理、可信。

经验表明，由活动的具体负责人进行活动历时估计是较好的做法，即可以赢得活动负责人的承诺，又可以避免一个人进行所有活动估计所产生的偏差。

4.制定进度计划

制定进度计划是分析活动顺序、持续时间、资源需求和进度约束，并编制项目进度计划书的过程。进度计划是监控项目实施的基础，也是项目管理的基准。制定进度计划时需要考虑时间、费用和资源三个方面的因素。

使用进度计划编制工具来处理各种活动、持续时间和资源信息，就可以制定出一份列明各项活动计划完成日期的进度计划。这一过程旨在确定项目活动的计划开始日期与计划完成日期，并确定相应的里程碑。在编制进度计划过程中可能需要审查和修正持续时间估算与资源估算，以便制定出有效的进度计划。在得到批准后该进度计划即成为基准，用来跟踪项目绩效。随着工作的推进、项目管理计划的变更以及风险性质的演变，应该在整个项目实施期间持续修订进度计划，以确保进度计划始终现实可行。

制定项目进度计划的一般步骤如下：

(1)进度编制；

(2)资源调整；

(3)成本预算；

(4)计划优化调整；

(5)形成基线计划。

5.进度控制

软件项目进度控制和监督的目的是增强项目进度的透明度，以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。软件开发项目实施中进度控制是项目管理的关键，若某个分项或阶段实施的进度没有把握好，则会影响整个项目的进度，因此应当尽可能地排除或减少上述干扰因素对进度的影响，确保项目实施的进度。

结合软件项目实施的阶段，其进度控制主要有：准备阶段进度控制、需求分析和设计阶段进度控制、实施阶段进度控制三个部分。准备阶段进度控制的任务是向用户提供有关项目信息，协助用户确定工期总目标、编制阶段计划和项目总进度计划、控制该计划的执行；

需求分析和设计阶段进度控制的任务是编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划及控制相关计划的执行等；

实施阶段进度控制的任务是编制实施计划和实施总进度计划并控制其执行等。

为了及时地发现和处理计划执行中发生的各种问题，就必须加强项目的协同工作。协同工作是组织项目计划实现的重要环节，它要为项目计划顺利执行创造各种必要的条件，以适应项目实施情况的变化。

6.2软件项目进度安排图示方法

6.2.1甘特图

甘特图(GanttChart，又称横道图、条形图)，是一个展示简单活动或事件随时间变化的方法。甘特图是亨利·甘特于1910年开发的一个完整地用条形图表示进度的标志系统。甘特图中一个活动代表从一个时间点到另一个时间点所需的工作量，事件表示一个或几个活动的起点或终点。甘特图通过展示项目进展或定义完成目标所需具体活动的方式，使管理者对项目进行情况有个大致的了解，从而实现对进度大体上的控制。其示例如图6.2所示。图6.2甘特图示例(这是一个典型的基于开发阶段组织的软件项目的甘特图)甘特图的优势是容易理解和改变。它是描述进展最简单的方式，而且可以很容易通过扩展来确定提前或滞后于进度的具体要素，这种方法最大的优点是：形象直观、简明易懂、绘图简单、便于检查和计算资源需要量。它可以容纳大量信息，是用于沟通项目状态的优秀工具。

但是甘特图法不能给出项目的详细状况，只是对整个项目或项目作为一个系统的粗略描述。其主要缺陷有：

不能全面地反映出各活动错综复杂的相互联系和相互制约的协作关系；

没有表明在执行活动中的不确定性，并没有反映项目的真实状态，不能从图中看出计划的潜力所在；

不能突出影响工期的关键活动。6.2.2网络图

为了克服甘特图在进度标识中的缺点，网络计划技术应运而生。网络计划技术提供了一种描述项目活动间逻辑关系的图解模型—网络图。利用这种图解模型和有关的计算方法分析出项目活动关系、关键路径，并用科学的方法调整计划安排，找出最好的计划方案。采用这种计划不仅在计划制定期间可求得工期、成本和资源的优化，而且在计划的执行过程中通过跟踪和对比，也可以对进度进行有效的控制和调整，从而保证了项目预定目标的实现。网络图是网络计划技术的基础，是由有向线段和节点组成的，用来表示活动流程的有向、有序的网状图形。网络图用于展示项目中的各个活动以及活动之间的逻辑关系，是活动排序的一个输出，它可以表达活动的历时。

常见的网络图有前导图法网络图、箭线图法网络图和条件箭线图法网络图。

1.前导图法(PDM)网络图

前导图法(PrecedenceDiagramMethod,PDM)网络图也称为节点图或单代号网络图，如图6.3所示。图6.3PDM网络图示例(PDM图用节点来描述活动，箭线表示活动之间的逻辑关系，可以方便地表示活动之间的逻辑关系)

PDM网络图具有以下特点：

(1)构成PDM网络图的基本元素是节点(Box)；

(2)节点表示活动(任务)；

(3)用箭线表示各活动(任务)之间的逻辑关系；

(4)可以方便地表示活动之间的各种逻辑关系；

(5)没有时标；

(6)在软件项目中PDM比ADM更通用。

2.箭线图法(ADM)网络图

箭线图法(ArrowDiagramMethod,ADM)网络图也称为双代号网络图，如图6.4所示。图6.4ADM网络图示例(ADM图用箭线表示活动，箭线上的标注表示活动名称和历时，节点表示活动的开始和结束，适合表示结束—开始的逻辑关系)

ADM网络图具有以下特点：

(1)箭线表示活动(任务)，箭线上方的文字表示活动(任务)名称，下方的数字表示其持续时间，图6.4中的时间单位为天；

(2)节点(circle)表示前一个活动的结束，同时也表示后一个活动的开始；

(3)只适合表示结束—开始的逻辑关系；

(4)可以有时标。

3.条件箭线图法(CDM)网络图

条件箭线图法(ConditionalDiagramMethod,CDM)网络图允许活动序列相互循环与反馈，从而在绘制网络图的过程中会形成许多条件分支，而在PDM、ADM中是绝对不允

许的。6.2.3里程碑图

里程碑图(MilestoneChart)是一种直观表达重大工作完成情况的图示方法，如图6.5所示，能够反映重大事件完成时间的延迟量或提前量(实际完成时间与计划完成时间的偏差)。里程碑不同于活动，活动是需要消耗资源的，里程碑仅仅表示重大事件的标记，里程碑图主要用于对项目总体进度的跟踪，尤其是对项目交付日期的持续跟踪。图6.5软件项目里程碑图示例(里程碑是项目中的重大事件，是一个时间点， 通常指一个可支付成果的完成，里程碑图给项目执行提供指导)该方法度量里程碑的进度，计算公式如下：

SVms表示里程碑进度偏差(ScheduleVariance)

对每个已经完成的里程碑，Tai表示第i个里程碑实际完成日期，Tpi表示第i个里程碑计划完成日期；

对每个已经开始但尚未完成的里程碑，Tai表示第i个里程碑实际开始日期，Tpi表示第i个里程碑计划开始日期；

当对软件项目整体进度进行考察时，里程碑一般指软件项目生存周期内的阶段节点，TD表示整个项目的工期；

当对软件项目阶段的内部进度进行考察时，里程碑一般指阶段内的活动(或任务)节点，TD表示该阶段的工期。(6-1)需要说明一点，当对软件项目阶段的内部进度进行考察，而且完成该阶段目标的活动排列在不同路径时，以关键路径作为依据计算阶段内重大事件的Tai－Tpi。

公式6-1反映了实际进度对项目交付期限和阶段节点计划进度的偏差程度，体现了项目的计划水平或实施能力，对于进度跟踪与控制具有参考价值。

里程碑图与其计划密切相关，所以里程碑计划的制定要与分配给项目的资源、经费和工作环境等实际情况结合起来，否则不切实际的里程碑计划容易让项目组成员遭受挫折，一旦非常努力仍然难以实现阶段目标的话，放弃也许是唯一的选择。

6.3软件项目进度估算方法

软件项目进度估算有很多种方法，例如，类推估算法、专家估算法、基于规模的进度估算法、PERT估算法、关键路径法、蒙特卡罗估算法、进度表估算法、基于承诺的进度估算法、Jones的一阶估算准则。

类推估算法、专家估算法和成本估算方法相似，不同之处在于估算的是各项活动的持续时间以及整个项目的工期。基于承诺的进度估算就是从需求出发安排进度，不进行中间的工作量估计，它是通过开发人员做出的进度承诺而进行的进度估计。其本质上来说不能算是一种进度估计，而且通常低估20%～30%。所以项目管理者必须充分认识开发人员估算的重要性，鼓励开发人员充分考虑各种前提，并及时掌握开发人员估算的前提，加强事后总结，判断原因，协助开发人员改善估算方法，尽可能提高估算的准确性。

6.3.1基于规模的进度估算法

在估算出项目规模和工作量、成立项目团队之后，项目进度估算可以用如下公式估算：(6-2)6.3.2PERT估算法

PERT(ProgramEvaluationanReviewTechnique，计划评审技术)是20世纪50年代末美国海军部开发北极星潜艇系统时为协调3000多个承包商和研究机构而开发的，其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。PERT通过考虑估算中的不确定性和风险,可以估计整个项目在某个时间内完成的概率，也可以提高活动持续时间估算的准确性。

假定各项活动的完成时间估算值服从正态分布，估算的标准差为σ，那么在区间(－3σ，+3σ)，正态随机变量的概率为99.72%，也就是说，在(－3σ，+3σ)间计算出的工期是最有把握完成的工期。

PERT对各个项目活动的完成时间按三种不同情况估计，就是常说的三点技术，如图6.6所示。

乐观时间(OptimisticTime，TO)：基于活动的最好情况,估计活动的持续时间；

最可能时间(MostLikelyTime，TM)：基于最可能获得的资源、最可能取得的资源生产率、对资源可用时间的现实预计、资源对其他参与者的可能依赖以及可能发生的各种干扰等估计活动的持续时间；

悲观时间(PessimisticTime，TP)：基于活动的最差情况,估计活动的持续时间。图6.6三点技术确定项目活动、资源需求(考虑估算中的不确定性和风险，根据TO、TM、TP三个值进行加权平均，计算出TE，用以提高估算的准确性，使估算更加准确)

PERT认为整个项目的完成时间是各个活动完成时间之和，且服从正态分布，对以上3种估算值进行加权平均，来计算预期活动持续时间。这3种估算结果能表明持续时间估算的变化范围。

假定各项活动的三个估计TOi、TMi、TPi服从β分布，由此可估算出第i项活动的期望时间Ti：

第i项活动的方差：(6-3)(6-4)所有活动的期望时间：

所有活动的方差：

所有活动的标准差：(6-7)(6-6)(6-5)用公式6-3估算出来的各项活动的持续时间可能更加准确。尽管没有理论证明使用β分布的正确性，但在PERT估算中表现出以下好处：

①根据特定活动的性质，这种分布可能向左右偏斜也可能对称(近似于正态分布)；

②分布的均值与差值能由上述三个时间估计值导出；

③该分布是一种单峰分布，最可能时间估计周围概率的集中趋势很强。

案例：PERT估算实例

X学校办公自动化系统的开发活动分解及其完成时间(单位：天)估计如表6-4所示。表6-4X学校办公自动化系统时间估计结合标准正态分布表，可得到整个项目在某一时间内完成的概率。根据正态分布规律，在±σ范围内即在47.304天与54.696天之间完成的概率为68%；在±2σ范围内完即在43.608天到58.393天完成的概率为95%；在±3σ范围内即39.912天到62.088天完成的概率为99%，如图6.7所示。如果客户要求在39天内完成，则可完成的概率几乎为0，也就是说，项目有不可压缩的最小周期，这是客观规律，千万不能不顾客观规律而对用户盲目承诺，否则必然会受到客观规律的惩罚。图6.7标准偏差与标准正态分布(白色区域是距平均值小于1σ之内的数值范围，所占比率为68%，根据正态分布，2σ之内的比率合起来为95%，3σ之内的比率合起来为99%。实际应用中，常考虑一组数据具有近似于正态分布的概率分布。如果假设正确，则约68.3%数值分布在距离平均值有1σ之内的范围，约95.4%数值分布在距离平均值有2σ之内的范围，以及约99.7%数值分布在距离平均值有3σ之内的范围，称为“68-95-99.7法则”或“经验法则”)6.3.3关键路径法

关键路径法(CriticalPathMethod，CPM)是根据指定的网络顺序逻辑关系和单一的历时估算计算每一个活动单一的、确定的最早和最迟开始时间以及完成时间。

关键路径法是一种网络图方法，由雷明顿-兰德公司(Remington-Rand)的J.E.Kelly和杜邦公司的M.R.Walker于1957年提出，用于对化工工厂的维护项目进行日程安排。关键路径法适用于有很多而且必须按时完成的项目，而且随着项目的进展不断更新。该方法采用单一历时估计，所包含的任务历时被视为是确定的。用关键路径法估算项目进度，首先要绘制项目的网络图，然后确定网络图中所有路径的历时，其中历时最长的路径就是关键路径，整个项目的工期等于最长的历时。

关键路径法有正推法和逆推法两种常用方法。按照时间顺序计算最早开始时间和最早完成时间的方法，称为正推法。按照逆时间顺序计算最晚开始时间和最晚结束时间的方法，称为逆推法。

1.进度时间参数

采用PDM图估算项目进度时，用图6.8所示的符号表达每个任务及其进度时间参数。图6.8PDM网络图中进度时间参数图示符号(PDM图的节点记录最早开始时间、最晚开始时间、最早完成时间、最晚完成时间、持续时间和浮动时间，直观地表达每个任务及时间参数)下面介绍相关符号代表的意义：

EST(EarlyStartTime，最早开始时间)：取该活动的所有前置活动的最早完成时间的最大值。

LFT(LateFinishTime，最晚完成时间)：取该活动的所有后置活动的最晚开始时间的最小值。

EFT(EarlyFinishTime，最早完成时间)：等于该活动的最早开始时间加上活动的持续时间。EFT=EST+TD。

LST(LateStartTime，最晚开始时间)：等于该活动的最晚完成时间减去活动的持续时间。LST=LFT－TD。

TD(Duration，持续时间)：某项任务的历时。浮动时间(FloatTime)：表示一个活动的机动时间，它是一个活动在不影响其它活动或者项目完成的情况下可以延迟的时间量。各个活动的浮动时间是相关的，如果某个活动用了浮动时间，则后续的活动可能没有浮动时间使用。

浮动时间包括总浮动时间、自由浮动时间和干扰浮动时间。它是进行活动时间调整的依据，可以在不影响项目总工期的情况下合理利用浮动时间来调度任务。

TF(TotalFloatTime，总浮动时间)：不影响项目最早完成时间，即本活动可以延迟的时间。它等于活动的最迟开始时间和最早开始时间之差，或者是活动的最迟结束时间和最早结束时间的差。自由浮动时间(FreeFloatTime，FFT)：在不影响后置任务最早开始时间，本活动可以延迟的时间。它等于紧后活动的最早开始时间和本活动的最早结束时间之差。

干扰浮动时间(InterferingFloatTime，IFT)：是活动的总浮动时间与自由浮动时间之差。它反映了自由浮动时间使用后，活动还能被延时多少而不影响整个项目的结束时间。

TF的大小反映了项目进度安排的合理程度，如下所示：

当TF>0时，表示时间安排比较合理；

当TF=0时，表示项目必须按期完成；

当TF<0时，表示项目进度会推迟。假定Aj代表当前活动，Ai代表Aj的前置活动，Ai有多个(包括Ab，…，Ac)；Ak代表Aj的后置活动，Ak有多个(包括Am，…，An)。其PDM网络图如图6.9所示。图6.9PDM网络图中进度时间参数计算图例(用正推法计算活动Aj的最早开始时间，用逆推法计算活动Aj的最晚完成时间，最早开始时间或最晚完成时间之差就是Aj的浮动时间)用正推法计算活动Aj的最早开始时间如下：

用逆推法计算活动Aj的最晚完成时间如下：

活动Aj的最早完成时间计算如下：

活动Aj的最晚开始时间计算如下：

活动Aj的浮动时间计算如下：

(6-8)(6-9)(6-10)(6-11)(6-12)采用ADM图估算项目进度时，用图6.10所示的符号表达每个任务及其进度时间参数。图6.10ADM网络图中进度时间参数图示符号(ADM图的节点记录最早完成时间的最大值和最晚开始时间的最小值，两者之差就是浮动时间)图6.10中符号代表的含义如下：

① No.表示事件的编号。

② ET(EarlyTime，最早时间)：是指在该节点结束的各项活动最早完成时间的最大值，反映了从该节点开始的各项活动最早可能开始的时间。一般从网络图的起点开始计算ET，起点的最早开始时间为0或规定时间。

③ LT(LateTime，最晚时间)：是指从该节点开始的各项活动最晚开始时间的最小值，反映了进入该节点的活动最迟必须完成的时间。它从网络图的终点开始、按节点编号从大到小反方向计算。表示终点的节点最迟结束时间等于其最早开始时间。④ TF：是指从该节点开始的各项活动的浮动时间，即TF=LT－ET。

假定j代表当前节点，i代表j的前向节点，i的取值有多个，即i={b，…，c}(b＜c＜j)，分别代表在节点j结束的各项活动的开始节点，Aij代表节点i和j之间的活动，tij是活动Aij的持续时间；k代表j的后继节点，k的取值有多个，即k={m，…，n}(j＜m＜n)，分别代表在节点j开始的各项活动的结束节点，Ajk代表节点j和k之间的活动，tjk是活动Ajk的持续时间，其ADM网络图例如图6.11所示。图6.11ADM网络图中进度时间参数计算图例(用正推法计算节点j的最早时间，用逆推法计算节点j的最晚时间，两者之差表示从节点j开始的所有活动的浮动时间)用正推法计算节点j的最早时间如下：

(6-13)

用逆推法计算节点j的最晚时间如下：

(6-14)

TFj表示从节点j开始的所有活动的浮动时间，其计算公式如下：

(6-15)

案例：进度时间参数计算

X项目中的两个任务A和B并行进行，它们之间的时间关系是结束—结束型，完成A的持续时间是5天，完成B的持续时间是1天，请用PDM网络图安排这两个任务的进度，并标明其中的时间参数。

由于TDB<TDA，所以先计算A的时间参数

对于任务A：EST=0，EFT=EST+TDA=0+5=5

LFT=5，LST=LFT－TDA=5－5= 0

TF=LST－EST=LFT－EFT=0如果A和B同时结束，那么

对于任务B：LFT=5，LST=LFT－TDB=5－1=4

如果A和B同时开始(当A结束时，B早已结束)，那么

对于任务B：EST=0，EFT=EST+TDB=0+1=1

TF=LST－EST=LFT－EFT=4

由此可知A和B的进度安排如图6.12所示。图6.12X项目中任务A和B的进度安排PDM图(任务A没有浮动时间，任务B有4天的浮动时间，因此，可以在任务A开始后的0～4天中的任一天开始任务B)

2.构造ADM网络图的注意事项

采用关键路径法估算项目的进度，首先要构造网络图。PDM网络图主要由节点和箭线组成，节点表示活动、箭线表示活动间的逻辑关系，它没有时标；而ADM网络图主要由节点、箭线和时标组成，箭线表示活动，节点表示活动的顺序，对节点编号后可代表时标，其中两个相邻节点之间只能表示一项活动，即相邻两个节点之间只能有一条箭线，这样估算时间时才不会产生歧义。所以在构造ADM网络图时必须注意以下事项：

1)所有活动的排序要有明确的方向

一般情况下按照项目过程从左向右对活动进行排序，用无持续时间的节点表示顺序，对其编号时注意箭头节点的编号要大于箭尾节点的编号，但不强调连续性。节点之间用有持续时间的箭线连接，而且要体现明确的前置和后置活动。网络图中的前置活动是指某活动的紧前活动，后置活动是指某活动的紧后活动。

2)项目网络图只能有一个起点和一个终点

整个项目的实施从开始到结束无论包含了多少活动，即便是部分活动并行作业，但网络图中只有一个起点代表项目开始，只有一个终点代表项目结束(完成)。当项目开始时有几个活动并行作业，或者在几个活动结束后完工，都用一个起点和一个终点表示项目的开始和结束，避免出现与客观现实不符的表达方式，例如网络图中显示项目有多个开始和/或多个结束，或者只有开始而永远不能结束等。

3)合理引入虚活动解决逻辑混乱或悬点问题

虚活动是一个实际上并不存在的活动，不需要人力、物力和时间等资源，只是为了表达相邻活动之间的衔接关系而虚设的活动，在网络图中用虚箭线表示。在以下几种情况下需要引入虚活动：

(1)相邻两节点之间有一条以上箭线时要引入虚活动。网络图中两个相邻节点之间的一条箭线表示一项活动。如果相邻两节点之间有多条箭线，就会造成逻辑上的混乱。图6.13(a)所示的网络图中，节点4和5之间有两条箭线，用来表达活动E和F，使得运用项目工具估算进度时，在选择节点4和5之间的箭线及其持续时间方面产生逻辑错误，这很难正确计算这两个节点的时间参数。图6.13相邻两节点之间有一条以上箭线时要引入虚活动(虚活动是为了表达相邻活动之间的衔接关系而虚设的活动，它可以改进网络图，使其逻辑更清晰)引入虚活动，改进网络图可以解决上述问题。图6.13(b)就是图6.13(a)改进后的正确的网络图。在节点4和5之间用1条箭线表示活动E，节点4和6之间的箭线表示活动F，节点5和6之间的虚箭线表示一个虚活动，这样以来，节点4、5、6的时间参数计算起来很方便，而且结果也就唯一。

(2)多条路径上的公共节点逻辑不清楚时最好引入虚活动。图6.14(a)中节点3是路径A-E-G-H和B-C-D-F-G-H的公共节点，从(a)图可以看出，A和C即是E的紧前活动，也是D的紧前活动。但项目的实施过程是：活动E的开始只取决于活动A，活动D的开始既取决于活动A，也取决于活动C，活动A和C是可以并行作业的，活动C对于活动E的开始不起决定性作用。显然，(a)图存在着逻辑错误，不能正确反映项目的活动关系。图6.14多条路径上的公共节点逻辑不清时最好引入虚活动(引入虚活动可以使网络图更准确地反映活动之间的逻辑关系)图6.14(b)是引入虚活动之后的ADM网络图。引入虚活动后中止了活动C和E之间的连接，很明确地反映了项目的正确活动过程，即活动A和C是D的紧前活动，E的紧前活动只有A。

(3)引入虚活动能够使网络图不存在悬点。图6.15(a)中的节点4就是一个悬点，它仅在一侧有箭线与节点3连接，另一侧失去了与其他任何节点的联系，反映不出它为其他活动或整个项目做出了什么贡献，显然是不符合实际的。图6.15(c)中的节点2也是一个悬点，它仅在一侧有箭线与节点3连接，另一侧失去了与其他任何节点的联系，该图显示项目有2个起点，也是不符合实际的。图6.15引入虚活动能够使网络图不存在悬点(可以根据活动之间的  顺序关系引入虚活动，避免网络图中出现悬点)在构造ADM网络图时，除了起点和终点外，其他各个节点的前后都应有箭线连接，使网络图从起点开始，经由任何路径都可以到达终点。否则将使某些活动失去与其前置或后置活动应有的联系。此外每项活动都应有节点表示其开始和结束，即箭线首尾都必须有一个节点，更不能从一条箭线中间引出另一箭线。

为了遵循这一规则，可以根据活动之间的顺序关系引入虚活动，避免网络图中出现悬点。图6.15(b)是引入虚活动排除悬点4之后的ADM图，图6.15(d)是引入虚活动排除悬点2之后的ADM图，都是正确的表示形式。

4)网络图中不能有回路(即循环现象)

软件项目在实施过程中每个阶段的成果都要经过评审论证，如果达到要求就可以进入下个阶段的工作，否则需要进行修正。这种情况在绘制流程图时容易体现。但是在构造网络图时很容易导致网络图中出现回路，如图6.16所示。图6.16带有回路的ADM网络图(网络图中不能有回路，这里F-G-H主要体现测试-错误诊断-修改错误的活动过程，形成了回路，一旦出现回路就需要进行修正)在图6.16中，F-G-H主要体现测试-错误诊断-修改错误这一系列活动过程，因为编码完成后，需要经过测试、调试，发现和排除存在的错误，以保证软件质量。如果项目实施过程像图6.16表示的那样简单，一次就能发现所有错误，并且将其改正，那么项目的工期估算也会变得比较容易。然而事实证明，测试-错误诊断-修改错误的活动往往要反复进行，难以掌握的是不知道这样的循环究竟实施多少次，而且每次所用的时间还不尽相同，这给项目工期的估算带来了巨大困难。如果能够估计测试-错误诊断-修改错误重复进行的次数，那么在构造网络图时，就可以将这个阶段的活动绘制成多个线性序列。假定测试-错误诊断-修改错误的活动重复了3次，每次的活动历时已经估计出来，则图6.16可以改进为图6.17。

如果不能估计出某些活动循环的次数，就要重新定义这些活动。图6.17排除回路后的ADM网络图(如果能够估计测试-错误诊断-修改错误重复进行的次数，那么在构造网络图时，就可以将这些活动绘制成多个线性序列)

5)尽可能安排并行作业以缩短项目工期

在活动的逻辑关系、时间关系以及项目实施环境允许的情况下，尽可能将某些活动安排成并行作业以缩短项目工期。在安排并行作业时，选择能够并行作业的几个活动中持续时间最长的一个活动，并直接与其紧后活动衔接，其中另外的几个活动通过虚活动与其紧后活动衔接，方便确定关键路径和计算其持续时间。

3.确定关键路径的几点说明

(1)关键路径是项目整个网络图中完成时间最长的路径，是浮动时间为0的路径；

(2)关键路径决定着项目完成的最短时间，关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟；

(3)关键路径上的任何活动都是关键活动，如果关键路径上的一个活动比计划的时间长，整个项目的进度将会拖延，除非采取纠正措施；

(4)需要注意的是项目中的关键活动不一定都在关键路径上；

(5)项目网络图中的关键路径可能不止一条；

(6)在项目的推进过程中关键路径可能会改变；

(7)确定关键路径后，就可以估算项目工期、合理安排进度。

4.用关键路径法估算项目进度

案例：借助PDM网络图估算项目进度

W公司为X企业开发一个人力资源管理系统(HRMS)，X-HRMS项目组对其中的活动(任务)进行了分解和定义，并对各项活动(任务)的历时做出了估计，得出了如表6-5所示的项目活动目录/清单。假如你是项目组成员，希望你能依据该表绘制项目的PDM网络图，从中确定关键路径，并估算出该项目的工期。表6-5X-HRMS项目活动目录/清单假定项目的开始日期为1，由表6-5提供的活动目录清单，首先运用公式6-8至公式6-12计算各活动的进度时间参数如下：

活动A：ESTA=1，EFTA=1+70=71

活动B：ESTB=1，EFTB=1+30=31

活动C：ESTC=EFTA=71，EFTC=71+60=131

活动D：ESTD=EFTB=31，EFTD=31+30=61

活动E：ESTE=EFTB=31，EFTE=31+20=51

活动F：ESTF=EFTC=131，EFTF=131+30=161

活动G：ESTG=max{EFTD，EFTE}=61，EFTG=61+30=91活动H：ESTH=max{EFTF，EFTG}=161，EFTH=161+20=181

活动H：LFTH=181，LSTH=181－20=161，TFH=161－161=0

活动G：LFTG=LSTH=161，LSTG=161－30=131，TFG=131－61=70

活动F：LFTF=LSTH=161，LSTF=161－30=131，TFF=131－131=0

活动E：LFTE=LSTG=131，LSTE=131－20=111，TFE=

111－31=80活动D：LFTD=LSTG=131，LSTD=131－30=101，TFD=

101－31=70

活动C：LFTC=LSTF=131，LSTD=131－60=71，TFC=

71－71=0

活动B：LFTB=min{LSTD，LSTE}=101，LSTB=101－30=71，TFB=71－1=70

活动A：LFTA=LSTC=71，LSTA=71－70=1，TFA=1－1=0

然后运用上述数据，绘制X-HRMS项目的PDM网络图如图6.18所示。图6.18X-HRMS项目的PDM网络图(根据表6-5描述的活动依赖关系绘制网络图)从图6.18可以看出，X-HRMS项目的工期为

TD=181－1=180(天)

以图6.18为基础，计算各条路径的持续时间(等于该路径上各项活动的持续时间的累加和)如下：

PA-C-F-H：TD1=70+60+30+20=180(天)

PB-D-G-H：TD2=30+30+30+20=110(天)

PB-E-G-H：TD3=30+20+30+20=100(天)

从上述计算结果可知，TD1>TD2>TD3

所以，X-HRMS项目的关键路径有1条，即A-C-F-H。

从图6.18可以看出，活动总浮动时间越大(例如图中的活动B、D、E、G)，该活动在整个网络中的机动时间就越大，所以应该在一定范围内将该活动的人力、物力资源利用到关键活动上去，以达到缩短项目结束时间的目的。

案例：借助ADM网络图估算项目进度

W公司为用户开发一个软件系统K，项目组提供了如表6-6所示的项目活动目录/清单。假如你是项目组成员，希望你能依据该表绘制项目的ADM网络图，从中确定关键路径，并估算出K项目的工期。表6-6K项目活动目录/清单假定项目的开始时间为0，由表6-6提供的活动目录清单，首先运用公式6-13、6-14、6-15计算各节点的进度时间参数如下：

节点1：ET1=0

节点2：ET2=0+3=3

节点3：ET3=0+2=2

节点4：ET4=0+3=3

节点5：ET5=max{3+4=7，2+5=7}=7

节点6：ET6=3+6=9

节点7：ET7=max{7+6=13，2+4=6，9+2=11}=13

节点8：ET8=13+3=16节点8：LT8=16，TF8=0

节点7：LT7=16－3=13，TF7=13－13=0

节点6：LT6=13－2=11，TF6=11－9=2

节点5：LT5=13－6=7，TF5=7－7=0

节点4：LT4=11－6=5，TF4=5－3=2

节点3：LT3=min{7－5=2，13－4=9}=2，TF3=2－2=0

节点2：LT2=7－4=3，TF2=3－3=0

节点1：LT1=0，TF1=0

然后充分考虑构造注意事项，绘制K项目的ADM网络图，如图6.19所示。以图6.19为基础，计算各条路径的持续时间如下：

PA-D-H-J：TD1=3+4+6+3=16

(周)

PB-E-H-J：TD2=2+5+6+3=16

(周)

PB-F-J：TD3=2+4+3=9

(周)

PC-G-I-J：TD4=3+6+2+3=14

(周)

从上述计算结果可知，TD1=TD2>TD4>TD3

所以，K项目的关键路径有2条，即A-D-H-J和B-E-H-J，工期为：

TD=max{TD1,…,TD2}

=

16(周)

从图6.19可以看出，关键路径上的关键活动A、D、B、E、H、J的总浮动时间都为0，一旦这几个活动中任何一个拖期，必然造成整个项目延期。图6.19K项目的ADM网络图(根据表6-6描述的活动依赖关系绘制网络图)正推法估算项目进度时应该注意以下几点：

(1)首先建立项目的开始时间；

(2)项目的开始时间是网络图中第一个活动的最早开始时间；

(3)从左到右，从上到下进行任务编排；

(4)当一个任务有多个前置时，选择其中最大的最早完成日期作为其后置任务的最早开始日期。逆推法估算项目进度时应该注意以下几点：

(1)首先建立项目的结束时间；

(2)项目的结