软件项目管理第6章 软件项目进度管理

第6章软件工程进度管理6.1软件工程进度管理概述6.2软件工程进度安排图示方法6.3软件工程进度估算方法6.4软件工程进度方案编制6.5软件工程进度跟踪和控制6.6小结案例：上大学需要做好时间管理

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

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

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

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

1)要做好可行的学习方案、管好时间

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

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

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

案例：软件工程延期，原因何在？

W是一家专门从事应用软件开发的公司，目前有员工45人，下设销售部、软件开发部和技术效劳部等业务部门，其中销售部主要负责将公司现有的产品推销给客户，同时也会根据客户的具体需要，承接应用软件的研发工程，然后将承接的工程移交给软件开发部，进行软件的研发工作。软件开发部共有开发人员16人，主要进行软件产品的研发，以及客户委托的应用软件开发。技术效劳部主要负责本公司售出软件系统的维护与技术支持工作。2021年1月4日，销售部与×制造公司签订了一个企业内部物流管理系统开发的软件工程，经双方洽谈，2021年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)的和杜邦公司的于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)工程的结束时间是网络图中最后一个活动的最晚结束时间；

(3)从右到左，从下到上进行计算；

(4)当一个前置任务有多个后置任务时，选择其中最小最晚开始日期作为其前置任务的最晚完成日期。

明确工程网络图中的关键路径，有利于将关键资源分配到关键路径上，以保证关键路径上的关键路径活动顺利执行并且能够按时完成，继而保证工程按期完成。如果要缩短整个工程周期，就必须缩短关键路径或者位于关键路径上关键活动的作业时间。采用关键路径法估算和安排进度时，要确保网络图的完整性，规划出关键路径，认真分析关键路径上存在的风险，根据总浮动时间的大小调整活动到合理的路径上，尽可能减少非关键路径上存在较多的关键活动，不能将关键路径上的任务交由太少的骨干人员来承担，不能轻易将关键资源集中在非关键活动上，不能静态对待非关键活动，不能无视非关键路径上的关键活动。总之要确保关键路径按时完成。6.3.4参数模型估算法

1. Walston-Felix(IBM)模型

工作量估算公式如表5-33所示。

进度和人员估算公式如下：(6-16)(6-17)2.根本COCOMO模型

采用根本COCOMO模型估算进度的内容在第5章里做了简要介绍，针对三种软件开发模式的具体估算公式如下：

组织型：

嵌入型：

半独立型：

如果要把工程进度控制在某个范围之内，需要控制软件规模，同时必须考虑影响工作量的一些关键因素。(6-20)(6-19)(6-18)3. COCOMOⅡ模型

COCOMOⅡ模型中用于早期开发和结构化后期的进度估算公式如下：

B是一个依赖于5个规模经济性比例因子的指数，其计算见公式5-20。

SCED反映工程组面临的进度压力，是所要求的完成时间与同类工程标准进度之间的比例，可从表5-45或表5-46中选取。(6-21)6.3.5蒙特卡罗估算法

模拟仿真方法是使用一个系统的替代物或模型来分析该系统的行为或绩效的方法。在软件工程进度估算中就是用不同的假设来计算相应的时间，最常见的是蒙特卡罗方法。

蒙特卡罗方法是一种以概率统计理论为根底，利用重复的统计实验来求解物理和数学问题的方法。这类问题可以直接或间接地利用一个随机过程来描述，蒙特卡罗方法就是通过模拟这个过程，找出希望求出的某些结果或观察感兴趣的某种现象。在用蒙特卡罗方法求解一个问题时，需要用随机数来描绘问题中某种概率的分布形式，只要有了描绘问题的概率分布，便可以从头到尾模拟问题的整个过程，并进行仿真。它能够比较逼真地描述事物的特点及演变过程，借助计算机较好地求解一些在数学上很难写出恰当解析式的复杂随机过程的问题，工程进度估算便是其中之一。

应用蒙特卡罗方法进行软件工程进度估算时，需要通过屡次试验，即反复虚拟“执行〞工程，从而获得工程工期的统计分布，如图6-20所示。图6.20运用蒙特卡罗对工程方案进度仿真的结果(对规模分别为10KLOC、20KLOC、 40KLOC的商业软件工程进行蒙特卡罗模拟仿真，得到三条曲线A、B、C，可以预测工程在给定时间完成的可能性)图6-20中的三条曲线A、B、C，是对规模分别为10KLOC、20KLOC、40KLOC的商业软件工程进行了蒙特卡罗模拟仿真的结果。

图6-20中曲线A说明，当10KLOC的软件工程方案工期为70天左右时，该工程完成的可能性在50%左右；当方案工期远小于70天时，工程完成的可能性趋于0；当方案工期为100天时，工程完成的可能性到达了90%；当方案工期为120天时，工程完成的可能性接近100%。

图6-20中曲线B说明，当20KLOC的软件工程方案工期为88天左右时，该工程完成的可能性在50%左右；当方案工期远小于88天时，工程完成的可能性趋于0；当方案工期为120天时，工程完成的可能性到达了90%；当方案工期为140天时，工程完成的可能性接近100%。图6-20中曲线C说明，当40KLOC的软件工程方案工期为120天左右时，该工程完成的可能性在50%左右；当方案工期远小于120天时，工程完成的可能性趋于0；当方案工期为160天时，工程完成的可能性到达了90%；当方案工期为180天时，工程完成的可能性接近100%。

应用蒙特卡罗方法进行工程进度估算和安排时，需要考虑活动持续时间的随机因素，导致每次仿真得到的工期与关键路径都会有所不同，此时需要采用合理的方法对屡次仿真结果进行分析，才能较好的描述工程进度方案的不