浅谈项目进度管理之计划编制

《浅谈项目进度管理之计划编制》由会员分享，可在线阅读，更多相关《浅谈项目进度管理之计划编制（6页珍藏版）》请在金锄头文库上搜索。

1、浅谈项目进度管理之计划编制浅谈项目进度管理之计划编制软件项目计划（SPP：Software Project Plan）是 CMM 二级中列出的第二个 关键过程域。这是因为 CMM2 软件项目计划需要根据纳入配置管理后的软件需 求进行项目估算，并依据文档化的流程，形成项目计划文档。软件项目计划的 目的在于建立合理的计划，执行软件工程和管理软件项目。软件项目计划管理 在软件开发过程中处于十分重要的地位，它体现了对客户需求的理解，是开展 项目活动的基础，是软件项目跟踪与监控（SPTO）的基础。 一、软件项目计划这一关键过程域在实施的过程中应该贯彻如下方针： 1.以分配的软件需求作为计划软件项目的基础

2、。 在项目定义阶段，针对用户提出的原始需求（又称 statements of work ,SOW）,通过用户方和承接方的相互协商，确定双方一致同意的、项目组承诺 实现的需求，这个需求即是“分配给软件的系统需求”或者更简洁地说， “分配 需求” ，然后根据它来提出项目意见，制定初始的项目计划。由此可见项目计划 是以分配给软件需求作为软件项目的基础。 2.由项目经理、项目软件经理和其他软件经理共同协商软件项目的各项约 定，并与系统工程组、硬件工程组和系统测试组协商，这些组介入该活 动的有关事宜，同时记入文档。 所谓约定有对外约定和对内约定。对外约定如与客户、分包商有关部门约 定。对内约定包含两方面

3、：一是项目组与组织内部其他组，如测试组、硬件组、 系统组的约定。二是项目组内部的约定。对软件而言，对外约定像用户需求的 更改是不可避免的，一旦有变动会影响整个项目。因此 CMM 提出由高级管理 者控制对外约定。约定是计划的基础，CMM SPP 中将其列为一个目标，即约 定必须是有关各方一致同意 、认可的。 另外，软件计划要包括所有项目活动和所有参加方面的责任，这些活动和 责任都要文档化，以保证有效地将计划传达给项目各个参加方。在项目计划执 行前，各个项目参加方要认同所承担的项目责任，这种认同是项目计划有效性 的一个基本保证。 3.软件项目的规模、工作量和成本估计、进度和其他约定必须通过相关组

4、的审查，以获得相关组及个人的支持。 CMM 中的一个组织或一个机构里，通常有许多小组，比如软件质量保证 组，负责计划和实施项目的质量保证活动的团队；软件配置管理组，负责策划、 协调和实施软件项目正式配置管理活动的团队等等。在执行每个活动时候，这 些组并不是独自行事的，而是相互影响的。在 SPP 这个关键过程域中受影响的 组包括软件工程组、软件估计组、系统工程组、系统测试组、软件质量保证组、 软件配置管理组、合同组和文档组。但是在对所有与组织外部的个人和组所作 的软件项目约定，则由高级管理人评审。所以 CMM 中提出“高级管理者参加 按照文档化规程对组织外部个人和组所作的软件项目约定的评审”以此

5、作为一 项活动。 4.项目软件开发计划需要进行管理和控制 项目计划是 CMM 实施一开始就涉及且最后才能相对完善的关键过程域， 它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资 源计划。在其他关键过程域的实践相对稳定之前，项目计划的实践总是处于需 要改动的状态。 所以需要对项目软件开发计划进行管理和控制以保证项目顺利实施。二、软件项目计划的关键问题及解决方案 1.关于软件项目的估计建立合理的软件计划的基础是对软件项目规模、资源要求和风险等要有一 个合理的估算。这个估算过程应是规范的，而不是任意的。例如，如果提出一 个项目计划需十个软件工程师工作六个月的计划，那么就要问这些数

6、据是如何 得到的。用户提出的时间和费用的要求仅能作为项目计划约束的条件，而不能 作为项目计划的基础。 根据 CMM SPP 的活动 9、10、11，估计对象应该包括软件规模、工作产 品的工作量和成本、软件进度、风险、关键计算机资源等。项目计划的基础要 求是估计项目中的各种工作所需的工作量和进度，软件成本通常由工作量换算 而得到。 估计模型有很多种，常用的如下： 算法模型：包括一个或多个算法，生成的软件估计是一些变量的函数，如 COCO-MO 专家判断：利用一个或多个专家的经验作估计。 类比：和已完成的与新项目的规模和功能十分类似的项目做比较，作估计 自顶向下的估计：从项目的全局特性导出项目的整

7、体估计，然后将其分配 到各个分量上 自底向上的估计：分别估计软件作业的各个分量，再综合出整体估计 在具体进行估计的时候应该注意以下几个问题： 1)选择科学的估计方法。CMM 的核心思想是不断学习、不断改进。在项 目过程中，计划是被不断修订的，所以每做一次修订，就必须作估计。 因此在某个项目中只对项目选定一种（几种）能改进的估计方法，多次 估计的结果进行比较，才能积累经验和数据，估计也才能越来越精确。 2)必须积累本组织自己的数据 随着生命周期阶段的进展，估计会越来越精确。一方面是不确定性随 着阶段的进展而减少，另一方面基于对估计值与实际值的分析比较，可合 理选择估计模型的参数。组织在每一个项目

8、结束时，需要将项目数据综合 归纳，保留。如果在刚开始没有估计值的情况下，我们只要选定方法，做 就是了。需要数据的地方如项目有数据用自己的数据，否则用本组织数据。 对于无组织的数据，则一次选定本地区的数据、本国行业数据，国际上的 行业数据。CMM 2 级 SPP 的活动场 15 要求建立一个数据库，记录项目估 计数据，包括计划时的数据、再次调整计划后的数据。为使数据可用，必 须记录下估计的假定，如采用的估计模型、模型参数、估计时作业的描述 等。另外，CMM2 的本关键过程域还提到要按照文档化规程进行估计。由前 面，在整个生存期内，随着项目的发展，需要不断进行估计。为确保估计的有 效性，结果的可比

9、性，必须描述项目进行估计的具体步骤，即所谓规程。这样 一来就能保证估计过程的可重复性，无论什么人去估计，或是在不同时间估计、 估计的步骤都是一致的，估计的假设也是一致的。CMM SPP 中要求有 4 个文 档化的估计规程，具体的规程形式由项目自己确定，CMM 仅提出了对规程的 一般要求。这些规程指出：估计假定要记入文档； 如有历史数据，使用历史数据； 估计要经过评审； 规模估计是多种估计的基础； 在用 CMM 进行过程改进的实践中，许多项目常常忘记进行规模估计，认 为项目计划内容未明显包含规模。然而正是规模大小会影响技术解决方案。对 于同一计划，人和月是不能交换的，比如说 5 个人干 3 个月

10、的活就不等于 4 个 人干 4 个月的工作。规模越大。通信与管理的开销越大。规模直接影响进度的 安排、人力资源的安排、计算机资源的安排以及风险的分析。所以最初的模型 估计也应该在项目定义阶段给出。其中代码行技术和功能点技术两个技术用来 对软件规模进行估计。代码行技术是比较简单的定量估计软件规模的方法。这 种方法根据以往开发类似产品的经验和历史数据，估计实现一个功能需要的源 程序行数。功能点估计依据对软件信息域特性和软件复杂性的评估结果，估计 软件规模。在进行估计的时候我们可以参考如下几点建议：首先下功夫精简软件需求规格说明书。从根本上来讲，估计的输入是需求 规格说明书。要做合理的估计首先要力争

11、使需求规格说明清晰。尽可能将工作分解得详细。分解得越详细，对开发软件的技术方面理解越 透，估计越精确。 采用几种独立的技术，没有一种估计技术是万能的，所以要避免其弱点利 用其强处，最好采用技术组合。可以按情况对不同软件成分采用不同的估计技 术。 比较与印证。对同一对象采用不同的估计技术，然后比较其结果，研究为 何它们得到不同估计，从中能做出较精确的估计。 注意采集数据，将实际数据与估计值进行比较，不断修订估计值和估计模 型的参数。总之，根据 CMM，当我们需要制定项目计划，首先确定了项目的需求后， 估计出所有的可交付产品，以及这些产品的规模。比如，规模可能包括哪些？ 如果是生产类项目，可能估计

12、的是交付的东西的数量，比如凳子多少条，牛奶 多少箱等，如果软件开发类项目，可能是特性多少个，代码行多少行等，这些 根据你所估计的对象来确定。另外，规模估计出来后，需要根据生产率估计项 目可能的工作量，比如生产一条凳子要多长时间，一箱牛奶要多长时间，软件 开发的话，可能就是一天生产多少行代码。在设计阶段，可能就是一天设计几 个特性或者几页设计文档等。根据生产率再估计出总工作量。 最后，根据你所 拥有的人力，来确定出项目的进度计划。 根据这个再对应到软件开发上来。一个软件开发项目可能的生命周期有可 能包括以下几个阶段： 需求分析、软件设计、编码、单元测试、系统测试、交 付。不同的项目有不同的生命周

13、期，但项目计划阶段一定要把项目的生命周期 确定下来，这也是计划的一部分。那么，在制定计划时，怎么估计这几个阶段 的里程碑时间呢？在处于二级的组织，由于之前没有什么量化的能力基线（也 就是一般的每个阶段的生产率） ，那么也只能去参考历史项目的信息。假使以前 的项目刚好做了这些度量的话，比如度量过每个阶段花费的时间，投入的人力， 统计过交付件的规模（文档页数、代码行数等） 。那么，项目刚好可以参考这些 历史的数据，大致估计一下这个项目各个阶段可能需要的时间，来确定这个项目的阶段里程碑时间。假使没有类似的项目数据的话，可能估计的可信度就不 高了。业界有估计方法，都是用来帮助我们得到比较可信的估计结果

14、的，比如 Delphe、Pert sizing。 在项目的生命周期不同阶段，因为所作的工作不同，生产率也就不同，每 个阶段甚至都有不同的生产率度量单位，比如需求分析阶段，可能就是需求分 析文档页数/人天。在编码阶段，可能就是代码行/人天等。一个组织需要积累和 建立这些能力数据，才能保证后面的项目有可信赖的数据参考，支撑后面的项 目进行估计和计划的制定。 2.鉴别和评估软件风险 风险管理是项目管理的重要内容之内，从某种意义上讲，项目管理就是风 险管理。风险就是不利事件发生的不确定性。所有。首先必须清楚风险是可能 事件，它可能发生，也可能不发生。所以决定了风险的动态性。 风险评估是项目计划时必不可

15、少的一项工作。正如前面提到的项目成本估 算和进度估计一样都是项目管理的重要活动。忽略了风险，轻者给项目工作带 来被动，重者可能对项目造成严重的灾难性后果。 CMM 实际上在本关键过程域的活动 13 是如此表述这个问题的： “对与项目的成本、资源、进度和技术方面相联系的软件风险进行鉴别、评 估和建立文档” 。风险评估包括风险识别、风险分析和对风险进行优先级排序。 风险识别是风险评估的第一步。就某个特定的软件工程项目来说，从项目 具体情况出发，列举出可能出现的风险。真正弄清每一个可能风险的情况是风 险识别的主要任务。检查单是风险识别的一个有力的工具。采用检查单中所列 举的各种风险，对照即将开发的软

16、件项目，逐一加以甄别，判定检查单中哪些 风险在该项目中可能发生。在进行风险识别时采用访谈、调查还是会议方式应 根据软件项目的具体情况决定。 风险识别以后需要弄清楚已识别的风险可能何时何地发生，发生了会怎么 样。风险分析的任务是分析每个风险可能造成的影响，给出比较风险大小的量 值。进行分析可以借助一些已有的模型，但不是所有列出的风险都可以借助模 型进行分析的，因此常常采用主观分析。 识别出风险，对其进行分析后就要对其进行排序了。排序步骤包括对已识 别和分析的风险估计概率类型，如高概率风险、低概率风险；评估每个风险对 项目的影响级，如低级、中级、高级。风险排序应该根据该项目各有关风险的 概率和影响级。显然高概率和高影响级的风险应该排在中概率和高影响级风险 的前面。最后针对排序列在前几位的风险采取缓解措施和跟踪措施。3.确定软件生存周期 确定软件的生命周期，这在 CMM 本关键过程域活动 5 也有体现“识别和 确定具有可管理的预先规定阶段的软件生命周期” 。典型的几种生命周期模型包 括瀑布模型、快速原型模型、渐进模型、喷泉模型等。 瀑布模型严格规定各阶段的任务，上一阶段任务输 出作为下一阶