1、第6章 软件项目进度管理 第6章 软件项目进度管理 6.1 软件项目进度管理概述软件项目进度管理概述 6.2 软件项目进度安排图示方法软件项目进度安排图示方法 6.3 软件项目进度估算方法软件项目进度估算方法 6.4 软件项目进度计划编制软件项目进度计划编制 6.5 软件项目进度跟踪和控制软件项目进度跟踪和控制6.6 小结小结 第6章 软件项目进度管理 案例：案例：上大学需要做好时间管理小刚于2008年考入X大学，攻读计算机科学与技术专业学士学位。报到之后，和同学们一起参加了新生入学教育，知道了该专业的培养目标，而且从学校提供的资料中看到了该专业的培养计划，表6-1是该培养计划的一部分。表表6
2、-1 计算机科学与技术专业本科培养计划计算机科学与技术专业本科培养计划(部分内容部分内容)第6章 软件项目进度管理 第6章 软件项目进度管理 有了专业培养目标和培养计划，小刚觉得自己只要认真上课就行了。谁曾想大一第一学期，英语考试不及格。第二学期，他的情绪低落，不好好上课，不按照要求学习，结果期末考试，有三门主课不及格，他想主动退学。后来，在老师的开导和帮助下，小刚认真反思自己存在的问题、分析自己的兴趣和优缺点，以专业培养计划为蓝本，制定了自己的年度学习计划，再以此为基础制定了每学期的学习计划，在每学期开学之初，以本学期课表为参考，制定每月和每周的学习计划，最后将学习任务细分到每天，例如，20
3、09年3月6日的计划如表6-2所示。第6章 软件项目进度管理 表表6-2 2009年年3月月6日日(星期五星期五)学习生活计划学习生活计划第6章 软件项目进度管理 第6章 软件项目进度管理 显然，表6-2所示的计划具有极强的可操作性，关键的问题是能否严格按照计划执行，落实其中的每项任务，并努力实现相应的目标。为此，小刚给自己制定了奖励和惩罚措施，并将自己的计划告诉同班学习认真的几位同学，还有自己的班主任，获取他们无形的监督，断掉自己不好好学习的退路，很快他就能够严格按照计划开展自己每天的学习和生活，进步非常迅速，学期期末考试的总分及平均成绩在班上名列前茅。后面的大学三年，他一如既往，学会了更好
4、地制定计划、控制进度和追求质量，最终以优异的成绩获得了计算机科学与技术专业的本科毕业证书和工学学士学位证书。第6章 软件项目进度管理 小刚对自己的大学四年进行了认真总结，其中包括了以下内容：1)要做好可行的学习计划、管好时间为了提高效率，在制定计划时，要适当给自己“压力”，对每一科目的预习、听课和温习要考虑时间、速度、质量的限制，要学会三者之间的协调。这种目标明确、有压力的学习，可以使注意力高度集中，提高学习效率。同时每学习完一部分时，都有一种轻松感、愉悦感，便会更充满信心地学习下去。第6章 软件项目进度管理 2)要注重计划的落实、跟踪与反馈学习计划一旦制定，就要注重落实。若有完不成的，也应在
5、次日立即加倍补上。同时要反省自己，当天的计划为什么没有完成？明天先干什么？再干什么？怎么干？如果完成的好可自我奖励一下；如果完成的不好必须自我惩罚一次。这样做，既有约束力又有可操作性，每天都会感到进步。一段时间后，还应该根据自己的学习情况，对计划做出进一步调整和完善，以更好地促进学习。第6章 软件项目进度管理 每天的上课不算项目，只是日常活动，但是从案例中仍然可以清晰地看到，时间、质量和成本之间相互影响、相互制约的关系，做好时间管理即进度管理在项目实施过程中就显得尤为重要。进度估算及其管理也是软件项目管理的重要内容之一，也是在软件项目的早期开展的一项重要工作。第6章 软件项目进度管理 6.1
6、软件项目进度管理概述软件项目进度管理概述案例：案例：软件项目延期，原因何在？W是一家专门从事应用软件开发的公司，目前有员工45人，下设销售部、软件开发部和技术服务部等业务部门，其中销售部主要负责将公司现有的产品推销给客户，同时也会根据客户的具体需要，承接应用软件的研发项目，然后将承接的项目移交给软件开发部，进行软件的研发工作。软件开发部共有开发人员16人，主要进行软件产品的研发，以及客户委托的应用软件开发。技术服务部主要负责本公司售出软件系统的维护与技术支持工作。第6章 软件项目进度管理 2013年1月4日，销售部与制造公司签订了一个企业内部物流管理系统开发的软件项目，经双方洽谈，2013年6
7、月10日之前必须完成系统开发和测试，并投入试运行，这些都明确地写入了合同中。合同签订后，销售部将合同移交给软件开发部，公司决定由大李作为项目经理，负责该项目的实施。软件开发部为此项目配备了1名系统分析员、2名程序员(曾参与了2个软件系统的编程工作)和1名技术专家(不太熟悉制造企业内部物流管理的业务)，要求这些成员必须全程参加项目的实施工作。第6章 软件项目进度管理 大李是一名经过全国考试认证的系统分析师，作为软件研制的骨干先后参与了10多个应用软件的研发工作，曾担任过系统分析员、系统设计员和程序员，具有比较丰富的软件研制经验。在此之前从未作为项目负责人直接管理过任何软件项目，所以他暗下决心一定
8、要干好这个项目。于是，大李很快制定了项目的进度计划，如表6-3所示。第6章 软件项目进度管理 表表6-3 制造公司内部物流管理系统项目进度计划制造公司内部物流管理系统项目进度计划第6章 软件项目进度管理 但是，需求分析工作并未在1月7日开始，而是在1月9日正式开始。2月初，大李检查工作时发现需求分析进行的不尽人意，他再三强调需求分析的重要性，同时要求项目组成员努力做好各自的工作。3月初，他再次细致检查系统设计工作的进展，让他感到意外的是总体设计刚刚做完，详细设计还未开始。“这个项目要拖期了？很有可能按时完不成任务？现在该怎么办呢？”他的心里开始打鼓，感觉没有什么做的不太合适的地方，一时没了太好
9、的主意。第6章 软件项目进度管理 有人积极地帮助他分析了其中的问题。(1)项目进度计划过粗(2)人力资源配置欠合理(3)部分子任务工作量估算不合理(4)项目疏于进度控制(5)缺少风险控制措施下面来进一步了解软件项目进度延期频发的一些主要原因，以便今后可以避免这类问题的发生。第6章 软件项目进度管理 6.1.1 软件项目进度延期的主要原因软件项目进度延期的主要原因1.项目进度本身不合理项目进度本身不合理当项目进度延迟时，应该首先分析进度计划本身是否合理？影响项目进度计划和安排的因素较多，主要从进度估算、关键资源、人力资源等方面进行分析和考虑。1)进度估算不准确估算的准确性是项目进度计划安排中最关
10、键的影响因素之一。估算不准确的原因很多，主要有两个方面：即缺少有经验的估算专家和缺少项目历史数据的收集。对于这两点只有通过多个项目的积累才可能得以改善。另外，估算过程中还需要考虑一些特殊因素的影响，例如项目增加了几名新员工可能会降低项目的平均生产率，项目过程中因为需要采用某种新技术而需要投入额外的预研时间等。第6章 软件项目进度管理 2)关键资源安排不合理在进度计划安排中未能优先保证项目关键路径上所需的资源，没有通过人员技能矩阵对项目关键资源进行分析和安排。在任务安排过程中要对关键资源进行保护，以尽量减少为关键资源安排非关键任务。在进度计划安排时适当考虑10%15%的余量，有利于项目遇到突发事
11、件或项目风险转变为实际问题时有能力进行应急处理。第6章 软件项目进度管理 3)人力资源未充分利用由于存在关键路径和岗位角色矩阵，导致为项目配置的人力资源往往不能得到充分的利用。尤其在中小型项目实施过程中更应该采用敏捷和迭代的开发方法，以充分利用有限的人力资源，例如项目前期开发人员可以参与需求分析和公有组件的开发，而在后期他们也可以参与软件测试。对软件项目而言需要保证项目组成员的整体利用程度达到70%以上，否则就应该考虑采用新的开发模式和生命周期模型。第6章 软件项目进度管理 2.团队及其成员存在负面影响团队及其成员存在负面影响软件项目中的编程人员的角色类似于建筑工程项目中的泥瓦工和钢筋工等，经
12、常从事创造性的工作，因此软件项目人员的流失往往给项目或软件开发机构带来短时间难以弥补的损失，因为新成员的培训和学习需要较长的时间，个体生产率在短期内很难提高到较高的水平。所以，在软件项目实施过程中开发团队及其成员的业务能力、责任心、交流沟通能力和关键人员对项目的进度和质量有着显著的影响。第6章 软件项目进度管理 1)项目组成员的业务能力不足在成立项目组时，往往忽视了成员业务能力的差异，事实上并不是每个成员有着同样的水平。如果在任务和进度安排上没有仔细考虑成员个体的生产率差异，造成项目拖期也许就是一种必然的结果。为了避免这样的问题发生，在项目初期必须对项目成员的业务能力进行全面的评估，对于多数人
13、都欠缺的能力应该安排统一的培训，后续还需要对培训的效果进行跟踪；对于少数能力欠缺的人员不应该让其承担主要任务，可以指定能力强的人员进行指导培养，借机参与主要任务，以期尽快提高业务能力，为后续项目储备人才；对于新员工承担的工作和任务应该加强监督和评审，保证过程和结果不出现大的偏差而导致后续大量的返工。第6章 软件项目进度管理 2)项目组成员的责任心不强软件项目通常是分阶段、分任务进行的，责任到人，这种情况下项目成员的责任心就成为一个不可小觑的因素，一旦有人敷衍了事，就会导致阶段性成果质量较差，需要大量返工，后继任务迟迟不能开始，继而延误项目整体进度。为了有效防止类似情况发生，项目组就要制定项目规
14、范和标准，能够切实监控实施过程、评价阶段成果。除此之外，项目经理需要加强同责任心不强的成员之间的单独沟通，从正面影响他们的分工协作意识，帮助他们树立正确的价值观和集体荣誉感，加强项目团队的凝聚力，鼓励大家为共同的利益和荣誉而努力工作。第6章 软件项目进度管理 3)项目组成员间的沟通不畅在软件项目实施过程中，一周5个工作日，如果花了3天时间用于成员之间的沟通，2天时间用于完成具体承担的任务，项目的进度恐怕难以保证。所以如何建立快捷顺畅的沟通渠道，并采用最佳的沟通方式来解决面临的问题，以保证成员之间的高效沟通是项目经理乃至软件开发机构必须做的事情。高效沟通最重要的是花最短时间，采用有效的方法或工具
15、使交流各方达成一致意见。第6章 软件项目进度管理 如果出现沟通不畅，必须及时分析和总结原因，选择以下方式中的一种或几种解决此类问题：(a)建立一个项目组局域网，项目非涉密电子资源统一存放在指定的服务器上，方便团队成员共享；(b)建立一个项目组聊天群，按天通报项目进度，方便交流非涉密问题的解决办法；(c)建立项目邮件组，一旦变更达成一致后，发送邮件确认；(d)每周、每天召开交流座谈会，时间不需要太长，注重效果即可；(e)面向项目组成员每周发送项目周报第6章 软件项目进度管理 4)项目实施期间关键人员流失软件项目实施期间如果关键成员调离项目组或离开软件开发机构，则有可能导致项目短期停顿，严重时可能
16、造成项目失败。不过这种情况一般很少发生，因为项目经理在项目初期进行风险评估时将这个问题作为高等级风险列入其中，制定了相应的风险跟踪策略和考虑具体的应对措施。第6章 软件项目进度管理 3.质量和时间的制约关系被忽视质量和时间的制约关系被忽视时间和质量是项目中两个重要因素，在特别关注项目进度的情况下往往会牺牲项目的质量。由于软件项目中测试环节的引入，就需要保证最终产品满足一定的质量规范。但是项目中经常出现项目后期测试问题太多，BUG修改和回归测试等工作花费了大量的时间而导致项目的进度延迟。一般情况下项目进度安排不会太宽松，容易促使项目管理者轻视或忽略项目各阶段性成果的质量评审环节。这样以来无形中隐
17、藏了各阶段存在的错误或缺陷，直到项目后期测试时才可能全部暴露出来，如果是需求引起的缺陷，往往会耗费相当于前期评审的520倍的工作量来进行处理，反而导致项目拖期。第6章 软件项目进度管理 在软件项目实施过程中，必须注重项目各阶段的评审工作，以便提早发现问题并将其解决，避免项目后期大量返工造成进度失控，才能更好地保证软件项目的质量。4.项目的风险管理工作不够精细项目的风险管理工作不够精细软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。在项目进行过程中，如果项目管理者能够不断对软件风险进行识别、评估、制定策略和监控的话，那么决策将更科学，并从总体上减少项目风险，保证项目的实现。如果项目管
18、理者的风险管理意识淡漠，或对项目可能发生的问题或潜在的不利因素不能精心预测，也不制定有针对性的应对策略，就不会提前采取有效的应急措施，那么当风险在项目实施过程中真正转化为问题后，处理起来将费时费力，项目干系人的工作也会非常被动。第6章 软件项目进度管理 导致软件风险的原因很多，例如进度和经费紧张、产品性能要求很高、项目组成员水平差异较大等，所以作为项目管理者，对软件风险要精细化管理，形成一套突发事件的应对机制，能够通过各种方法、工具和冗余资源跟踪和处理软件风险。5.项目进度管理未能及时响应软件需求的频繁变化项目进度管理未能及时响应软件需求的频繁变化在软件开发过程中用户的需求永远是没有止境的，用
19、户会不停地提出这样或者那样的改进建议，希望软件人员能够满足其要求。在修改这些需求和解决相关问题的时候，会导致另一些功能发生异常，而且这些发生异常的功能模块又可能影响更多的模块。第6章 软件项目进度管理 需求频繁变更经常让软件开发方误入“需求陷阱”，在没有很好的应对办法时，加班赶进度就成了家常便饭，即便如此，能否按时保质保量完成项目都可能成为一个谁都不想回答的问题。因此在项目管理过程中应该对需求变更的管理形成一套完善的分析、控制和管理的机制，成立变更控制委员会专门对变更进行分析、调查和处理。要避免“需求陷阱”，首先要弄清问题的种类。在开发后期，用户所提出的需求(或需要改进的地方)可以分为3类：第
20、一类是影响业务流程的进行，用变通的方式无法解决的问题；第二类是不影响业务流程的进行，但是会降低客户工作效率的问题；第三类是为了让软件使用更加方便，也就是说锦上添花的问题。第6章 软件项目进度管理 显然，第一类问题的修改是非常必要的，必须及时修改。第二类问题要看对客户工作效率的影响程度，然后再决定是否进行修改。第三类问题在进度紧张的情况下无需进行修改。考虑到时间和成本制约而未修改的第二类和第三类问题可以统计出来，在以后的升级版本中进行修改。6.项目技术方案设计和实施时不重视进度约束项目技术方案设计和实施时不重视进度约束项目开发模式、生命周期、开发语言、开发环境、相关工具和技术的选择，在技术方案中
21、都有明确的阐述，这些因素都会直接或间接的影响项目成员的个体生产率，一旦在方案设计之初没有充分考虑进度约束，轻率的给出了相关的描述，而且在后续实施过程中一味地按照方案中的要求去执行，那么项目各阶段的返工恐怕不再是一个偶然事件。第6章 软件项目进度管理 在技术方案中系统的总体设计和架构设计是一个非常值得重视的问题。所以项目管理者在估算和安排进度时，要为系统总体设计和架构设计预备充足的时间，另外设计人员应该重视进度约束，有能力并且通过架构设计屏蔽整个系统的复杂性，向模块设计和开发人员提供一套简单、高效的开发规程和模式，从而真正提高后续设计开发的效率和质量，既保证了项目按进度实施，又能为系统提供一个稳
22、定健壮的架构。第6章 软件项目进度管理 6.1.2 软件项目进度管理的概念和意义软件项目进度管理的概念和意义进度是对执行的活动和里程碑制定的工作计划日期表。进度决定着项目是否达到预期目的，它是跟踪和沟通项目进展状态的依据，也是跟踪变更对项目影响的依据。进度管理是指运用一定的工具和方法制定项目实施计划，经评审形成基线计划后，在项目实施过程中对项目的实际进展情况进行控制，在与质量、成本目标协调的基础上，确保项目能够按时完成所需的一系列活动。按时完成项目是项目经理最大的挑战之一，而时间是项目规划中灵活性最小的因素，进度问题是项目冲突的主要原因，尤其在项目的后期。可见，有效的进度管理是项目管理追求的主
23、要目标之一，其意义主要表现在以下几个方面：第6章 软件项目进度管理 1.充分发挥资源效能、节省项目成本、保证软件质量充分发挥资源效能、节省项目成本、保证软件质量一般情况下项目范围越大，项目所要完成的任务越多，项目耗时就越长；项目范围越小，项目所要完成的任务越少，项目耗时就越短。如果用户特别要求较短的项目工期，那么项目组在确定其范围时，必须进行范围压缩或分割，要么简化项目的功能和性能，要么项目分期或外包进行，总之，要把项目的范围和进度统一起来与用户协商相关事宜。例如成本估算既要考虑项目范围和进度，也要考虑用户对软件质量的要求。而在项目实施过程中将性能良好的软硬件资源、优秀的人力资源分配到关键任务
24、和关键路径上，或者在资源充足的情况下安排一些工作并行进行，这能够大幅度缩短各项主要任务的时间开销，项目的整体进度就会加快，以人力成本为核心的软件项目成本也因此而降低。第6章 软件项目进度管理 当项目进度紧张，必须压缩工期时，项目的成本将会急剧上升，并且由于加班赶工导致项目质量难以保障。开发方可以采取以下措施保证项目进度：(1)在用户许可的情况下，缩减项目的部分任务，或者降低部分任务的质量，优先满足项目进度的要求；(2)增加项目经费投入(无论来源于用户还是开发方)，调配更多的项目资源，使某些工作能够并行完成或者加班完成；(3)把项目的部分任务外包出去，虽然以增加成本为代价，但能够保证项目的进度。
25、这种情况下采购管理、质量管理和进度管理的协调又将成为开发方的重要工作。第6章 软件项目进度管理 2.有助于形成正确的工作方法，减少时间浪费有助于形成正确的工作方法，减少时间浪费软件项目实施包括需求分析、可行性分析、总体设计、详细设计、编码和测试等多个阶段，每个阶段的工作方法正确与否决定着项目干系人花费的时间是超过还是少于计划时间，其结果必然影响项目整体的进度。例如在需求分析阶段，开发方一开始就采用与用户进行面对面访谈的方法，获得的效果与所花费的时间可能都会让项目组感到十分沮丧。第6章 软件项目进度管理 在访谈的过程中，由于开发方对用户的业务背景及其相关术语不甚了解，很容易忽略或听不懂用户讲到的
26、一些术语，花了好长时间却没有完全弄清用户需要解决的问题，这次不行，下次还得再谈，这样的过程可能会重复两三遍。因为开发方和用户毕竟是处在两种或多种知识领域的人，在不太懂对方的专业术语时，谈话要么很谨慎，要么就是相互问得太多，一旦出现没完没了的问题，给面谈双方的感觉肯定不好。这种效率和效果低下的调研方法将会导致调研时间延长而且调研成本增加，双方的信心和配合程度随着时间的拉扯而逐渐降低。第6章 软件项目进度管理 正确的需求调研方法应该是首先进行书面交流，然后熟悉业务流程，再进行面对面访谈，必要时发放匿名需求调查表，甚至召开高层业务主管报告会。采用上述正确的需求调研方法，看似步骤较多，实际上每个步骤花
27、费的时间并不是太长，而且每个环节都能获得很好的效果，与不停的返工相比，能够有效节约需求调研时间，把富裕的时间留给项目其他阶段，也有助于加快项目进度。第6章 软件项目进度管理 3.有利于培养精诚团结和高效工作的软件项目团队有利于培养精诚团结和高效工作的软件项目团队软件项目团队的成员往往存在着各方面的差异，例如个人性格、兴趣爱好、技术水平和成长经历等，这些差异使得他们在项目组成立初期，需要花时间熟悉组内其他成员、适应工作环境、接受新的工作任务，而且这段时间一般情况下都比较长，留给他们真正工作的时间相对就会减少，这是项目管理者必须应对的挑战之一。第6章 软件项目进度管理 善于管理的项目经理通过组织讨
28、论会，让项目组成员尽快知道项目组成立的背景、成员选择的理由、每个角色的重要性、项目的目标、工作范围、质量标准、预算及进度计划的标准和限制，以及项目成功之后开发机构和成员所能获得的效益，激励成员对管理制度和工作环境等方面发表各自的意见和建议，积极参与项目计划的制定工作，从而使成员之间尽快了解对方的优势和不足，以便更加合理的分配任务和安排进度，同时也能很快凝聚人心，形成团队意识，大大缩短项目组成员磨合阶段的时间。这样，项目组成员真正工作的时间就会相对充裕一些，他们就能从容应对自己或小组承担的任务，精诚团结，高效工作，并很快成长为优秀的软件项目团队。第6章 软件项目进度管理 6.1.3 软件项目进度
29、管理的过程软件项目进度管理的过程1.活动定义活动定义确定为完成软件项目的各个交付成果所必须进行的诸项具体活动。软件活动定义是一个过程，它涉及确认和描述一些特定的活动，需要完成WBS中的细目和子细目。定义活动的输出结果包括以下内容：活动目录(也称活动清单)。活动目录必须包括项目中要执行的所有活动，活动目录可视为WBS的细化。活动目录必须是完备的，不包含任何不在项目范围内的活动。细节说明。细节说明是定义活动的依据，是有关活动目录细节的说明，以方便项目管理过程的执行。细节说明应包括对所有假设和限制条件的说明，细节说明也应文档化。第6章 软件项目进度管理 WBS结构的更新。在利用WBS进行定义活动的过
30、程中，随着对软件项目认识的不断加深，如果发现WBS 中任务的遗漏或错误要及时加以更新。2.活动排序活动排序活动排序就是确定活动间的相关性，并根据这些相关性安排各项活动的先后顺序。某个活动的执行必须依赖于某些活动的完成，即某个活动必须在某些活动完成之后才能开始。活动必须被正确地加以排序，以便制订切实可行的进度计划。活动排序可由计算机或手工完成，对于小型项目手工排序很方便，对于大型项目早期用手工排序也很方便，但对于大型项目应该把手工编制和计算机排序结合起来效果更好。第6章 软件项目进度管理 在确定活动之间的先后顺序时有以下三种依赖关系：强制性依赖关系(Mandatory Dependencies)
31、。强制性依赖关系指工作性质所固有的依赖关系，也称为硬逻辑关系(Hard Logic)，它们往往涉及一些实际的限制。项目管理团队在确定活动先后顺序的过程中要明确哪些依赖关系属于强制性的，例如在施工项目中只有在基础完成之后才能开始上部结构的施工；在软件项目中必须在完成原型系统之后才能进行测试。第6章 软件项目进度管理 软逻辑依赖关系(Discretionary Dependencies)。软逻辑依赖关系是指由项目团队确定的依赖关系。这种依赖关系要有完整的文字记载，因为它们会造成总时差不确定、失去控制并限制今后进度安排的选择。软逻辑依赖关系有时称为优先选用逻辑关系、优先逻辑关系或者软逻辑关系(Sof
32、t Logic)。项目管理团队在确定活动先后顺序的过程中要明确哪些依赖关系属于软逻辑的。可以根据具体应用领域内部的最好做法来安排活动的关系，也可以根据项目的某些非寻常方面对活动顺序做出安排，通常根据以前成功完成类似的项目经验，选定活动的关系。第6章 软件项目进度管理 外部依赖关系(External Dependencies)。外部依赖关系是指受项目外部因素制约的那些依赖关系，涉及项目活动和非项目活动之间的依赖关系。项目管理团队在确定活动先后顺序的过程中要明确哪些依赖关系属于外部依赖的，例如学校图书馆建筑施工项目的场地平整，可能要在项目外部的校园环境听证会之后才能动工；软件系统的试运行可能取决于
33、来自外部供应商提供的硬件是否安装。这种依赖关系的活动排序可能要依靠以前类似性质的项目历史信息或者合同和建议。软件项目活动排序不仅要考虑它们之间的依赖关系，还要考虑它们之间的时间关系，如图6.1所示。第6章 软件项目进度管理 图6.1 软件项目活动(任务)之间时间依赖关系(活动之间的时间依赖关系表明了活动的开始和结束之间的逻辑，最常见的是结束开始关系)第6章 软件项目进度管理 图6.1(a)是一种结束开始关系，表示A活动结束，B活动才能开始，A活动是B活动的前置任务，是最常用且风险最低的一种依赖关系。例如，软件原型系统完成，才能对其进行测试；硬件选型完成，才能进行硬件安装。图6.1(b)是一种结
34、束结束关系，表示A活动结束，B活动必须结束。A和B往往是后续某一项活动的前置任务。例如，硬件安装结束时，软件编码和测试必须结束，只有这两个任务都完成，后续的系统安装和测试才能开始。第6章 软件项目进度管理 图6.1(c)是一种开始开始关系，表示A活动与B活动同时开始。这种情况下两项任务没有紧密的前后紧随关系，认为它们可以同时开始，只是通过并行安排工作，以便缩短项目的进度。例如需求获取和项目规划就可以同时开始。图6.1(d)是一种开始结束关系，表示B活动结束时，A活动必须开始。这是一种最容易出错的逻辑关系，实际工作中很少使用。第6章 软件项目进度管理 3.活动历时估计活动历时估计在确定活动的顺序
35、后需要估计活动清单中的每项活动任务从开始到完成所需的时间。活动的持续时间是一个随机变量，无法事前确切地知道活动实际需要的时间，只能进行估计。通过对活动目录、约束条件、各种假设、资源需求与供给以及历史资料的分析，再进行活动历时的估计将使估计的时间尽可能地接近现实，以便于项目的正常实施。第6章 软件项目进度管理 活动目录/清单。由活动分解和定义过程产生的目录/清单，包括了项目中所要执行的所有活动。活动目录可视为WBS的一个细化。活动目录应是完备的，它不包含任何不在项目范围里的活动。活动目录应包括活动的具体描述，以确保项目团队成员理解工作该如何去做，这样才能确保估计的准确性。约束条件。约束因素将限制
36、项目团队对时间的选择余地。具体地讲，例如学生学籍管理系统项目在大学和在中学进行就会有一些不同，系统管理的内容和任务量会有很大差别，需求分析这项活动持续时间的估计就会不一样。又如给软件系统限定了运行环境的项目，都将对项目形成约束条件。因此在不同的时间和地点，进行的同一类型项目会具有不同的约束因素，需要具体情况具体分析。第6章 软件项目进度管理 各种假设。项目实施过程中会有很多可能发生的事情，例如参加项目的人员可能在项目开发过程中请病假、事假、其他公务外出、甚至离职等情况。这时需要假设这些因素对活动持续时间的影响。当然假设是对风险确认的结果，也需要考虑这些因素的真实性和确定性。例如在很多情况下，给
37、科研项目研究人员分配工作时间时，不是一年12个月，往往骨干成员是810个月，其他成员是46个月。这说明，事实上能够一年全天候为项目工作的项目成员基本上没有的。这与罗德尼特纳(JRedney Turner)的建议是一致的，他认为平均对于每个项目的工作人员来说，假设每年工作260天，一些项目全职人员只有70%的可用性，实际上他们一年的工第6章 软件项目进度管理 作时间是180(2600.7)天。因此在估计活动历时的时候，应该在估算出来的持续时间基础上乘以1.4(1.0/0.7)，从而得到一个切合实际的历时估计。然而，因为项目的规模大小不一，整个持续时间长短也有很大差异，进行假设和选取影响系数，所以
38、需要具体情况具体分析。资源需求与供给。项目中多数活动所需时间由相关资源多少所决定。例如一项活动，如果由2个正常水平的技术人员承担，需要用5个月来完成，如果由同等水平的4个人承担，需要2.5个月完成，如果由2个高水平的技术人员承担，需要用4个月来完成。很显然软件项目中人力资源、个体生产率、软硬件性能和工作环境等资源的数量和质量对项目持续时间的影响必须给予重视。这也要求项目管理者能够科学地分配和管理项目资源。第6章 软件项目进度管理 类似项目活动的历史资料。相关类似项目活动的档案和专业数据等历史资料，对于估计活动所需的时间是有参考价值的。当活动所需的时间不能由实际工作内容推算时，可通过分析这些历史
39、资料，帮助估计新项目中部分活动的持续时间。当活动所需的时间估计出来以后，活动目录中应该增加各项活动的持续时间，并在相关文档中提供估计依据和细节，以便确保在制定进度时所用的假设合理、可信。经验表明，由活动的具体负责人进行活动历时估计是较好的做法，即可以赢得活动负责人的承诺，又可以避免一个人进行所有活动估计所产生的偏差。第6章 软件项目进度管理 4.制定进度计划制定进度计划制定进度计划是分析活动顺序、持续时间、资源需求和进度约束，并编制项目进度计划书的过程。进度计划是监控项目实施的基础，也是项目管理的基准。制定进度计划时需要考虑时间、费用和资源三个方面的因素。使用进度计划编制工具来处理各种活动、持
40、续时间和资源信息，就可以制定出一份列明各项活动计划完成日期的进度计划。这一过程旨在确定项目活动的计划开始日期与计划完成日期，并确定相应的里程碑。第6章 软件项目进度管理 在编制进度计划过程中可能需要审查和修正持续时间估算与资源估算，以便制定出有效的进度计划。在得到批准后该进度计划即成为基准，用来跟踪项目绩效。随着工作的推进、项目管理计划的变更以及风险性质的演变，应该在整个项目实施期间持续修订进度计划，以确保进度计划始终现实可行。制定项目进度计划的一般步骤如下：(1)进度编制；(2)资源调整；(3)成本预算；(4)计划优化调整；(5)形成基线计划。第6章 软件项目进度管理 5.进度控制进度控制软
41、件项目进度控制和监督的目的是增强项目进度的透明度，以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。软件开发项目实施中进度控制是项目管理的关键，若某个分项或阶段实施的进度没有把握好，则会影响整个项目的进度，因此应当尽可能地排除或减少上述干扰因素对进度的影响，确保项目实施的进度。结合软件项目实施的阶段，其进度控制主要有：准备阶段进度控制、需求分析和设计阶段进度控制、实施阶段进度控制三个部分。第6章 软件项目进度管理 准备阶段进度控制的任务是向用户提供有关项目信息，协助用户确定工期总目标、编制阶段计划
42、和项目总进度计划、控制该计划的执行；需求分析和设计阶段进度控制的任务是编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划及控制相关计划的执行等；实施阶段进度控制的任务是编制实施计划和实施总进度计划并控制其执行等。为了及时地发现和处理计划执行中发生的各种问题，就必须加强项目的协同工作。协同工作是组织项目计划实现的重要环节，它要为项目计划顺利执行创造各种必要的条件，以适应项目实施情况的变化。第6章 软件项目进度管理 6.2 软件项目进度安排图示方法软件项目进度安排图示方法6.2.1 甘特图甘特图甘特图(Gantt Chart，又称横道图、条形图)，是一个展示简单活动或事件随时间变化的方法
43、。甘特图是亨利甘特于1910年开发的一个完整地用条形图表示进度的标志系统。甘特图中一个活动代表从一个时间点到另一个时间点所需的工作量，事件表示一个或几个活动的起点或终点。甘特图通过展示项目进展或定义完成目标所需具体活动的方式，使管理者对项目进行情况有个大致的了解，从而实现对进度大体上的控制。其示例如图6.2所示。第6章 软件项目进度管理 图6.2 甘特图示例(这是一个典型的基于开发阶段组织的软件项目的甘特图)第6章 软件项目进度管理 甘特图的优势是容易理解和改变。它是描述进展最简单的方式，而且可以很容易通过扩展来确定提前或滞后于进度的具体要素，这种方法最大的优点是：形象直观、简明易懂、绘图简单
44、、便于检查和计算资源需要量。它可以容纳大量信息，是用于沟通项目状态的优秀工具。但是甘特图法不能给出项目的详细状况，只是对整个项目或项目作为一个系统的粗略描述。其主要缺陷有：不能全面地反映出各活动错综复杂的相互联系和相互制约的协作关系；没有表明在执行活动中的不确定性，并没有反映项目的真实状态，不能从图中看出计划的潜力所在；不能突出影响工期的关键活动。第6章 软件项目进度管理 6.2.2 网络图网络图为了克服甘特图在进度标识中的缺点，网络计划技术应运而生。网络计划技术提供了一种描述项目活动间逻辑关系的图解模型网络图。利用这种图解模型和有关的计算方法分析出项目活动关系、关键路径，并用科学的方法调整计
45、划安排，找出最好的计划方案。采用这种计划不仅在计划制定期间可求得工期、成本和资源的优化，而且在计划的执行过程中通过跟踪和对比，也可以对进度进行有效的控制和调整，从而保证了项目预定目标的实现。第6章 软件项目进度管理 网络图是网络计划技术的基础，是由有向线段和节点组成的，用来表示活动流程的有向、有序的网状图形。网络图用于展示项目中的各个活动以及活动之间的逻辑关系，是活动排序的一个输出，它可以表达活动的历时。常见的网络图有前导图法网络图、箭线图法网络图和条件箭线图法网络图。1.前导图法前导图法(PDM)网络图网络图前导图法(Precedence Diagram Method,PDM)网络图也称为节
46、点图或单代号网络图，如图6.3所示。第6章 软件项目进度管理 图6.3 PDM网络图示例(PDM图用节点来描述活动，箭线表示活动之间的逻辑关系，可以方便地表示活动之间的逻辑关系)第6章 软件项目进度管理 PDM网络图具有以下特点：(1)构成PDM网络图的基本元素是节点(Box)；(2)节点表示活动(任务)；(3)用箭线表示各活动(任务)之间的逻辑关系；(4)可以方便地表示活动之间的各种逻辑关系；(5)没有时标；(6)在软件项目中PDM比ADM更通用。2.箭线图法箭线图法(ADM)网络图网络图箭线图法(Arrow Diagram Method,ADM)网络图也称为双代号网络图，如图6.4所示。第
47、6章 软件项目进度管理 图6.4 ADM网络图示例(ADM图用箭线表示活动，箭线上的标注表示活动名称和历时，节点表示活动的开始和结束，适合表示结束开始的逻辑关系)第6章 软件项目进度管理 ADM网络图具有以下特点：(1)箭线表示活动(任务)，箭线上方的文字表示活动(任务)名称，下方的数字表示其持续时间，图6.4中的时间单位为天；(2)节点(circle)表示前一个活动的结束，同时也表示后一个活动的开始；(3)只适合表示结束开始的逻辑关系；(4)可以有时标。3.条件箭线图法条件箭线图法(CDM)网络图网络图条件箭线图法(Conditional Diagram Method,CDM)网络图允许活动
48、序列相互循环与反馈，从而在绘制网络图的过程中会形成许多条件分支，而在PDM、ADM中是绝对不允许的。第6章 软件项目进度管理 6.2.3 里程碑图里程碑图里程碑图(Milestone Chart)是一种直观表达重大工作完成情况的图示方法，如图6.5所示，能够反映重大事件完成时间的延迟量或提前量(实际完成时间与计划完成时间的偏差)。里程碑不同于活动，活动是需要消耗资源的，里程碑仅仅表示重大事件的标记，里程碑图主要用于对项目总体进度的跟踪，尤其是对项目交付日期的持续跟踪。第6章 软件项目进度管理 图6.5 软件项目里程碑图示例(里程碑是项目中的重大事件，是一个时间点，通常指一个可支付成果的完成，里
49、程碑图给项目执行提供指导)第6章 软件项目进度管理 该方法度量里程碑的进度，计算公式如下：SVms表示里程碑进度偏差(Schedule Variance)对每个已经完成的里程碑，Tai表示第i个里程碑实际完成日期，Tpi表示第i个里程碑计划完成日期；对每个已经开始但尚未完成的里程碑，Tai表示第i个里程碑实际开始日期，Tpi表示第i个里程碑计划开始日期；当对软件项目整体进度进行考察时，里程碑一般指软件项目生存周期内的阶段节点，TD表示整个项目的工期；当对软件项目阶段的内部进度进行考察时，里程碑一般指阶段内的活动(或任务)节点，TD表示该阶段的工期。D1ipiaimsT)TT(SV(6-1)第6
50、章 软件项目进度管理 需要说明一点，当对软件项目阶段的内部进度进行考察，而且完成该阶段目标的活动排列在不同路径时，以关键路径作为依据计算阶段内重大事件的TaiTpi。公式6-1反映了实际进度对项目交付期限和阶段节点计划进度的偏差程度，体现了项目的计划水平或实施能力，对于进度跟踪与控制具有参考价值。里程碑图与其计划密切相关，所以里程碑计划的制定要与分配给项目的资源、经费和工作环境等实际情况结合起来，否则不切实际的里程碑计划容易让项目组成员遭受挫折，一旦非常努力仍然难以实现阶段目标的话，放弃也许是唯一的选择。第6章 软件项目进度管理 6.3 软件项目进度估算方法软件项目进度估算方法软件项目进度估算
