2.1.2.1.3 PDM 依赖关系
PDM 包括4种依赖关系或先后关系:
完成对开始(FS):后一活动的开始要等到前一活动的完成完成对完成(FF):后一活动的完成要等到前一活动的完成开始对开始(SS):后一活动的开始要等到前一活动的开始。开始对完成(SF):后一活动的完成要等到前一活动的开始。以上4种关系的表示如下图所示：
2.1.2.1.4 PDM规则
在PDM中，FS是最常用的逻辑关系，而SF关系很少用。在绘制PDM时，需要遵守下列规则：
箭线图法(ArrowDiagramming Method，ADM)也称为双代号网络图法(Active Onthe Arow，AOA)，它用节点表示事件，用箭线表示活动，并在节点处将其连接起来，以表示依赖关系。
2.1.2.2.2 方法图示ADM中，给每个事件而不是每项活动指定一个唯一的号码。活动的开始(箭尾)事件叫做该活动的紧前事件(PrecedeEvent)，活动的结束(箭头)事件叫做该活动的紧后事件(SuccessorEvent)。在复杂的 ADM 中，为避免多个起点或终点引起的混淆，也可以用虚活动来解决，如图所示：
2.1.2.2.3 ADM规则
在ADM中，有三个基本原则：
每一个事件必须有唯一的一个代号，即ADM中不会有相同的代号。任何两项活动紧前事件和紧后事件代号至少有一个不相同，节点序号沿箭线方向越来越大。流入(流出)同一事件的活动，均有共同的后继活动(或先行活动)。ADM 只使用FS 关系，因此可能要使用虚活动才能正确地定义所有的逻辑关系，用虚箭线表示。 2.1.3 确定依赖关系2.1.3.1 依赖关系划分在项目进度管理中，通常使用三种依赖关系来进行活动排序，分别是强制性依赖关系、可自由处理的依赖关系和外部依赖关系。
强制性依赖关系。也称为硬逻辑关系、工艺关系。这是活动固有的依赖关系这种关系是活动之间本身存在的、无法改变的逻辑关系。可自由处理的依赖关系。也称为软逻辑关系、组织关系、首选逻辑关系、优先逻辑关系，这是人为确定的一种先后关系。外部依赖关系。这种关系涉及项目与非项目活动之间的关系。2.1.3.2 逻辑关系划分逻辑关系的表达可以分为平行、顺序和搭接3种形式。
平行关系。也称为并行关系，两项活动同时开始即为平行关系。例如，在上图中，活动A和B是平行关系。顺序关系。相邻两项活动先后进行即为顺序关系。如前一活动完成后，后一活动马上开始则为紧连顺序关系。如后一活动在前一活动完成后隔一段时间才开始则为间隔顺序关系。在顺序关系中，当一项活动只有在另一项活动完成以后才能开始，并且中间不插入其他活动，则称另一项活动为该活动的紧前活动：反之，当一项活动只有在完成之后，另一项活动才能开始，并且中间不插入其他活动，则称另一活动为该活动的紧后活动。例如，在上图中，活动A和C为紧连顺序关系，A和E是间隔顺序关系，A是C的紧前活动，C是A的紧后活动。搭接关系。两项活动只有一段时间是平行进行的则称为搭接关系2.2 活动资源估算2.2.1 定义活动资源估算包括决定需要什么资源(例如，人员、工具、设备等)和资源的数量以及何时使用资源来有效地执行项目活动。它必须和成本估算结合。
2.2.2 注意事项进行资源估算时，必须要对资源的可用性进行评价，否则，将只能是纸上谈兵。包括考虑资源地理位置的改变，以及资源数量和级别在项目进行过程中可能会改变。例如，在软件开发的前期，需要一些系统分析师的参与，而在编码阶段，则需要很多程序员的参与。
2.2.3 估算方法进行活动资源估算的方法主要有专家判断法、替换方案的确定、公开的估算数据估算软件和自下而上的估算。
2.2.3.1 专家判断法专家判断法通常是由项目成本管理专家根据以往类似项目的经验和对本项目的判断，经过周密思考，进行合理预测，从而估算出项目资源。进行预测的专家可以是任何具有专门知识或经过特别培训的组织和个人。
2.2.3.2 替换方案的确定资源估算是为了给项目预算明确空间，为早期的资源筹备提供数据，如果某项活动存在替代方案，或提供的资源有替代支持可能，则需要明确声明。
2.2.3.3 公开的估算数据有些公司会定期地公开一些生产率或人工费率数据，其中包括很多国家和地区的劳动力交易、材料和设备信息。这些数据可以作为资源估算的参考。
2.2.3.4 估算软件依靠软件的强大功能，可以定义资源可用性、费率，以及不同的资源日历。
2.2.3.5 自下而上的估算把复杂的活动分解为更小的工作，以便于资源估算。将每项工作所需要的资源估算出来，然后汇总即是整个活动所需要的资源数量。
2.3 活动历时估算 2.3.1 注意事项活动历时估算直接关系到各项具体活动、各项工作网络时间和完成整个项目所需要总体时间的估算。
活动历时估算通常同时要考虑间隔时间。在估算时，要在综合考虑各种资源、人力、物力、财力的情况下，把项目中各工作分别进行时间估计。若活动时间估算太短，则在工作中会出现被动紧张的局面：反之，如果活动时间估算太长，则会使整个项目的完工期限延长，从而造成损失。
2.3.2 包含的工作内容2.3.2.1 软件项目的工作量软件项目的工作量和工期的估算比较复杂，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏，以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。因此，估算错误是软件项目失败的主要原因之一。
2.3.2.1.1 工作量衡量（代码量）软件项目通常用代码行(Lime OfCode，LOC)来衡量项目规模，LOC指所有的可执行的源代码行数，包括可交付的工作控制语言语句、数据定义、数据类型声明、等价声明、输入输出格式声明等。
项目经理可以根据对历史项目的审计来核算本企业的单行代码价值。
2.3.2.1.1.1 代码量衡量举例例如，假设某公司每一万行Java语言源代码形成的源文件约为250KB，视频点播系统项目的源文件大小为 3.75MB，则可估计该项目源代码大约为15万行，该项目累计投入工作量为 240人月，每人月费用为10000元(包括人均工资、福利、办公费用公摊等)，则该项目中1LOC的价值为：
(240x10000)/150000=16元/LOC
该项目的人月平均代码行数为：
150 000/240=625LOC/人月
2.3.2.2 软件生产率2.3.2.2.1 生产率与人员的关系对于一个小型软件开发项目，一个人就可以完成需求分析、设计、编码和测试工作。随着项目规模的增大，就需要更多的人共同参与同一项目的工作，因此，要求由多人组成软件开发组。但是，软件产品是逻辑产品而不是物理产品，当几个人共同承担项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。
如果两个人之间需要通信，则在这两人之间存在一条通信路径。如果一个软件开发组有N个人，每两人之间都需要通信，则总的通信路任有 nX(n-1)/2 条。
例如，4名软件工程师之间的通信路径如图所示：
也就是说，这4名软件工程师之间需要建立 4x(4-1)/2=6 条通信路径。假设每条通信路径的开销为200LOC/年。如果4名软件工程师单独工作，每个人的生产率是6000LOC年，那么，由这4名软件工程师组成的项目组的生产率为 4X6000-200x6=24000-1200=22800LOC/年。如果在这一年期限的最后两个月，又增加了2名工程师，新增成员的个人生产率为3000LOC年。这样，通信路径增加6x(6-1)/2-6=9 条，增加通信开销为(200/12)x2x9=300LOC。而这2个人的开发工作量为(3000/12)X2X2=1000LOC，因此，全年总计工作量为22800+1000-300=23500LOC
从理论上来说，一项软件开发任务由一个人单独开发，生产率最高。但是，在实际开发中，这是不现实的。稍大的软件开发，都必须组织一个开发小组。软件开发组的规模不能太大，人数不能太多，一般在2~8人左右为宜。
2.3.2.3 人员和时间的关系对于一个规模为100人月的项目来说，既可以安排10个人开发10个月，也可以安排100个人开发1个月。那么，究竟怎么处理人员和时间的关系呢？明确地说，没有特定的规则，在项目实施中，需要根据实际情况(例如，客户要求的交付日期等)来决定但就一般而言，可以参考 Putnam 模型。
2.3.2.3.1 Putnam 模型Putnam 模型假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目(总工作量达到或超过30个人年)中收集到的工作量分布情况而推导出来的,但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程式”把已交付的源代码行数与工作量和开发时间联系起来，用下面的公式表示:
其中，t是开发持续时间(以年计)，K是软件开发与维护在内的整个生存期所花费的工作量(以人年计)，L是源代码行数(以LOC计)，C是技术状态常数，它反映出“妨碍程序员开发的限制”，并因开发环境而异，通常取值在 2000~28000之间。
2.3.3 估算方法介绍2.3.3.1 德尔菲法2.3.3.1.1 定义德尔菲(Delphi)法是当前比较流行的专家评估技术，该方法结合了专家判断法和三点估算法，在没有历史数据的情况下，对项目进行估算。
2.3.3.1.2 步骤德尔菲法对减少数据中人为的偏见、防止任何人对结果不适当地产生过大的影响尤其有用，其具体实施步骤如下：
组织者发给每位专家一份软件系统的规格说明书(略去名称和单位)和一张记录估算值的表格，请他们进行估算。专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：ai：该软件可能的最小规模(最少源代码行数)。mi：该软件最可能的规模(最可能的源代码行数)。bi：该软件可能的最大规模(最多源代码行数)。无记名地填写表格，并说明做此估算的理由。在填表的过程中，专家互相不进行讨论，但可以向组织者提问。组织者对专家们填在表格中的数据进行整理，计算各位专家的估算期望值E并综合各位专家估算值的期望中值E(这种方法通常也称为三点估算法)。将各位专家第一次判断意见汇总，列成图表，进行对比，再分发给各位专家让专家比较自己与他人的不同意见，修改自己的估算和判断。然后比较两次估算的结果若差异很大，则要通过查询找出差异的原因。上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模(源代码行数)。在此过程中不得进行小组讨论。在向专家进行反馈的时候，只给出各种意见，但并不说明发表各种意见的专家的具体姓名。通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。2.3.3.1.3 缺点与改进方案德尔菲法的主要缺点是过程比较复杂，花费时间较长。另外，人们无法利用其他参加者的估算值来调整自己的估算值。
宽带德尔菲法克服了这个缺点。在专家正式将估算值填入表格之前，由组织者召集小组会议，专家们与组织者一起对估算问题进行讨论然后专家们再无记名填表。组织者对各位专家在表中填写的估算值进行综合和分类后再召集会议，请专家们对其估算值有很大变动之处进行讨论，请专家们重新无记名填表。这样适当重复几次，得到比较准确的估计值。由于增加了协商的机会，集思广益，使得估算值更趋于合理。
2.3.3.1.4 总结德尔菲法与常见的召集专家开会，通过集体讨论得出一致预测意见的专家会议法既有联系又有区别。
德尔菲法能发挥专家会议法的优点，即：能充分发挥各位专家的作用集思广益，准确性高;能把各位专家意见的分歧点表达出来，取各家之长；
避各家之短同时，德尔菲法又能避免专家会议法的缺点，即：权威人士的意见影响他人的意见:有些专家碍于情面，不愿意发表与其他人不同的意见;出于自尊心而不愿意修改自己原来不全面的意见。
2.3.3.2 类比估算法2.3.3.2.1 定义类比估算法适合评估一些与历史项目在应用领域、环境和复杂度等方面相似的项目，通过新项目与历史项目的比较得到规模估计。
2.3.3.2.2 步骤由于类比估算法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比估算法的前提条件之一是企业建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
类比估算法的基本步骤如下:
整理出项目功能列表和实现每个功能的代码行。 标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方。通过步骤(1)和(2)得出各个功能的估计值。产生规模估计。2.3.3.2.3 估算举例软件项目中用类比估算法，往往还要解决可复用代码的估算问题。估计可复用代码量的最好办法就是由程序员或系统分析师详细地考查已存在的代码，估算出新项目可复用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比，以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行：等价 LOC=[(重新设计%+重新编码% +重新测试%)/3]x已有 LOC
例如，有10000LOC，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的 LOC 可以计算为：
[(30%+50%+70%)/3]x10 000=5000LOC即复用这 10 000LOC 相当于编写 5000LOC 的工作量。
2.3.3.3 功能点估算法2.3.3.3.1 定义功能点(Function Point，FP)估算是在需求分析阶段基于系统功能的一种规模估计方法。FP估算并不是集中于功能上，而是通过研究初始应用需求，确定各种输入、输出、数据文件、查询和外部接口，以及一些复杂度调整值。
2.3.3.3.2 步骤通常的步骤如下：
计算输入、输出、查询、数据文件与接口的数目。将这些数据进行加权乘。根据对复杂度的判断，总数可以用复杂性调节因子进行调整。统计发现，对一个软件产品的开发，功能点对项目早期的规模估计很有帮助。功能点估算法与程序设计语言无关，但涉及到的主观因素比较多。例如，各种权值函数的取值等。而且，FP值没有直观的物理意义。
2.3.3.4 COCOMO 估算模型2.3.3.4.1 定义COCOMO 模型(COnstructive COst MOdel)是一种结构型估算模型，是一种精确、易于使用的估算方法。
2.3.3.4.2 模型划分在COCOMO模型中，考虑开发环境，软件开发项目的总体类型可分为三种:组织型、嵌入型和半独立型。COCOMO模型按其详细程度分成3级：基本 COCOMO 模型、中间 COCOMO 模型和详细 COCOMO 模型。
2.3.3.4.2.1 基本 COCOMO 模型基本 COCOMO 模型是一个静态单变量模型，它用一个以已估算出来的源代码行数为自变量的(经验)函数来计算软件开发工作量。具体计算公式如下表所示：
其中，KLOC=1000LOC:M表示开发工作量，单位为人月;7表示开发进度，单位为月。
2.3.3.4.2.2 中间 COCOMO 模型中间 COCOMO 模型则在用 LOC为自变量的函数计算软件开发工作量(此时称为名义工作量)的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。具体计算公式如下表所示：
其中EAF为调整因子，取值范围在 0.9~1.4之间。
2.3.3.4.2.3 详细 COCOMO 模型详细 COCOMO 模型包括中间 COCOMO 模型的所有特性，但用各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤(例如，分析、设计等)的影响。详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO 模型相同。但详细COCOMO模型分层、分阶段给出工作量因素分级表。针对每一个影响因素，按模块层、子系统层、系统层，有三张不同的工作量因素分级表，供不同层次的估算使用。
2.4 进度控制2.4.1 定义项目进度控制就是将实际进度与计划进度进行比较并分析结果，以保持项目工期不变，保证项目质量和所耗费用最少为目标，做出有效对策，进行项目进度更新。
2.4.2 内容说明
项目进度更新主要包括两方面工作，即分析进度偏差的影响和进行项目进度计划的调整。这两方面的工作都是以关键路径及相关参数为基础，可能要使用挣值分析的结果。
2.4.2.1 进度偏差的影响当出现进度偏差时，需要分析该偏差对后续活动及总工期的影响。主要从以下几方面进行分析：
分析产生进度偏差的活动是否为关键活动。若出现偏差的活动是关键活动，则无论其偏差大小，对后续活动及总工期都会产生影响，必须进行进度计划更新：若出现偏差的活动为非关键活动，则需根据偏差值与总时差和自由时差(本活动总时差-紧后活动总时差的最小值)的大小关系，确定其对后续活动和总工期的影响程度。分析进度偏差是否大于总时差。如果活动的进度偏差大于总时差，则必将影响后续活动和总工期，应采取相应的调整措施：若活动的进度偏差小于或等于该活动的总时差，表明对总工期无影响:但其对后续活动的影响，需要将其偏差与其自由时差相比较才能做出判断。分析进度偏差是否大于自由时差。如果活动的进度偏差大于该活动的自由时差,则会对后续活动产生影响，如何调整，应根据后续活动允许影响的程度而定；若活动的进度偏差小于或等于该活动的自由时差，则对后续活动无影响，进度计划可不进行调整更新。经过上述分析，项目管理人员可以确定应该调整产生进度偏差的活动和调整偏差值的大小，以便确定应采取的调整更新措施，形成新的符合实际进度情况和计划目标的进度计划。
2.4.2.2 项目进度计划的调整项目进度计划的调整往往是一个持续反复的过程，一般分几种情况：
2.4.2.2.1关键活动的调整对于关键路径，由于其中任一活动持续时间的缩短或延长都会对整个项目工期产生影响。
因此，关键活动的调整是项目进度更新的重点。有以下两种情况：
第一种情况：关键活动的实际进度较计划进度提前时的调整方法。若仅要求按计划工期执行，则可利用该机会降低资源强度及费用。实现的方法是，选择后续关键活动中资源消耗量大或直接费用高的予以适当延长，延长的时间不应超过已完成的关键活动提前的量;若要求缩短工期，则应将计划的未完成部分作为一个新的计划，重新计算与调整，按新的计划执行，并保证新的关键活动按新计算的时间完成。第二种情况：关键活动的实际进度较计划进度落后时的调整方法。调整的目标就是采取措施将耽误的时间补回来，保证项目按期完成。调整的方法主要是缩短后续关键活动的持续时间。这种方法是指在原计划的基础上，采取组织措施或技术措施缩短后续工作的持续时间以弥补时间损失，确保总工期不延长。实际上，不得不延长工期的情况非常普遍，在项目总计划的制订中要充分考虑到适当时间冗余。当预计到项目时间要拖延时应该分析原因，第一时间给项目干系人通报并征求项目业主(建设单位)的意见，这也是项目进度控制的重要工作内容。
2.4.2.2.2 非关键活动的调整当非关键路径上某些工作的持续时间延长，但不超过其时差范围时，则不会影响项目工期，进度计划不必调整。为了更充分地利用资源，降低成本，必要时可对非关键活动的时差做适当调整，但不得超出总时差，且每次调整均需进行时间参数计算，以观察每次调整对计划的影响。
非关键活动的调整方法有三种：在总时差范围内延长非关键活动的持续时间、缩短工作的持续时间、调整工作的开始或完成时间。
当非关键路径上某些工作的持续时间延长而超出总时差范围时，则必然影响整个项目工期，关键路径就会转移。这时，其调整方法与“关键活动的调整”方法相同。
2.4.2.2.3 增减工作项目由于编制计划时考虑不周，或因某些原因需要增加或取消某些工作，则需重新调整网络计划，计算网络参数。由于增减工作项目不应影响原计划总的逻辑关系，以便使原计划得以实施。
因此，增减工作项目，只能改变局部的逻辑关系。增加工作项目，只对原遗漏或不具体的逻辑关系进行补充；减少工作项目，只是对提前完成的工作项目或原不应设置的工作项目予以消除。增减工作项目后，应重新计算网络时间参数，以分析此项调整是否对原计划工期产生影响，若有影响，应采取措施使之保持不变。
2.4.2.2.4 资源调整若资源供应发生异常时，应进行资源调整。资源供应发生异常是指因供应满足不了需要，例如，资源强度降低或中断，影响到计划工期的实现。资源调整的前提是保证工期不变或使工期更加合理。资源调整的方法是进行资源优化，提高资源利用率。
在软件项目中，必须处理好进度与质量之间的关系。在软件开发实践中，常常会遇到这样的事情，当任务未能按计划完成时，只好设法加快进度赶上去。但事实告诉我们，在进度压力下赶任务，其成果往往是以牺牲产品的质量为代价的。因此，当某一开发项目的进度有可能拖期时，应该分析拖期原因，加以补救：不应该盲目地投入新的人员或推迟预定完成日期。Brooks 曾指出：为延期的软件项目增加人员将可能使其进度更慢。
今天关于项目进度管理的相关内容就分享到这里！
如果对您有帮助，欢迎点赞+关注，也可以发表您宝贵的评论，和我一起互动！
欢迎访问我的博客：夜夜流光相皎洁_小宁
