制定项目计划

制订 第 1 页 共 4 页 制订项目计划 第四部分：遗漏任务或不正确的分配资源很容易发生，甚至有了计划和时间的正确评估。 作者：William H.Roetzheim 译者：Mirnshi 译者评注：制定项目计划是项目经理的职责，本系列文章为项目经理提供了很好的参考， 值得一看和细细体会。译文与原文有冲突之处，以原文为主。原文参见www.sdmagazine.com. 对于一位项目经理来说，最困难的任务之一是制订一个用于管理项目开发计划的基线。 遗漏任务、不正确的任务分配计划或为维护而分配足够资源的失败很容易发生， 甚至有了 计划和时间的正确评估。软件评估是一门可以被学习的科学；对于广泛的项目来说，经过 可以实现的正确和持续的评估开发费用和时间进度后，就可以快速的制订一个项目计划。 这些文章提供了一些工具，帮助你理解一步步完成项目的费用和时间进度的评估。 在第一篇文章中，《评估软件费用》(项目和过程管理，2000年十月)，我给出了评估 一个程序大小(称作程序量)的不同方法。我论述了代码行数和点的传统计量方法，并 且介绍了其他的方法，最后，我指出了如何使用那些资料准备一个初步的不调整的评估。 在《项目费用调整》(项目和过程管理，2000年 11月)，我针对不同的项目环境回顾了项 目费用调整的原则，并且举例说明了如何制订一个精确的时间和费用的评估，用于开发一 个新的应用。《重用的计算》(项目和过程管理，2000年12月)，说明了如何量化软件重用、 商业组件和函数库在你的评估中的效果。最后，也就是这篇文章描述了你如何通过你对项 目费用和时间进度的洞察，制订一个完整的项目计划。 工作细目分类结构 一个项目计划最基本的构建块是工作细目分类结构(work breakdown structure -- WBS)。WBS包含了需要完成的任务列，你可以用一个电子表格制订 WBS的，电子表 格中包括任务名称列表，计划中的任务百分比和任务说明。一个是用于多数电子商务的简 单的WBS模板见表1。 一旦你确定了项目工作任务的全部正确的计划，你就可以使用计划的百分比，快速轻 松的分配 WBS中的所有任务的计划。确定计划所用到的方法和资料在系列文章的前三部分 作了说明。 可交付的计划 在大多数项目中，你需要制订技术文档。 一般来说，这促进了开发之间的交流，帮助维护和为付款提供里程碑界点 第一步是制订另外一个模板，文档标题的时间和说明。文档模板经常被当作标准参考； 然而，我们能在这个最初的一步上走得更远。在你的项目计划中，将每份文档的页数评估 制订项目计划 第 2 页 共 4 页 包含进来是有意义的。这些资料可以帮助建立客户的期望值，为编写文档的开发人员和审 核时的评估人员定义文档的适用范围 我发现文档正确的页数能够预测出。将开发计划的所有月数作为输入，就可以用下面 的计算出页数。 页数 = A + B (人月^C) 对人月取 C 的幂，然后乘以 B，然后加上 A，得出结果。 表2 提供了一个适用于许多电子商务开发项目的可交付计划的例子 使用表2列举的标准，来计算一下一个50个人月项目的软件设计描述的页数评估。A、B、 C的取值分别为0.00、8.00、和0.91。计算如下: 页数 = A + B (人月^C) = 0 + 8 (50 ^ 0.91) = 8 * 35 = 280页 评估维护计划 作为你的计划过程的一部分，经常需要评估维护的效果。你也许需要计划一个适当的 维护，或者提供软件的保障。这些都要求你要为提供这些服务的计划作评估。 第一，首先，你必须要和参与维护工作的客户达成共识。在 CostXpert Group里，我 们将维护工作划分为三种类别：纠错，适应和优化。标准的 bug修订作为纠错维护，而适 应修订包括修改程序使之适应于操作环境的改变，诸如数据库、操作系统、编译器版本的 改变等等。优化维护是最复杂的，包括修改代码，使之在同样的需求下，能适应更多的可 接受的方式。优化维护的最大的例子是通过修改代码，在一个糟糕的地方提高性能。注意 并不是所有为增加新的功能作的代码修改被认为维护，任何修改也不见得都要严格基于用 户的喜好。 我发现了维护的年计划稳定期相对于开发计划成比例(这个结论最初由Barry Boehm提 出，接着被众多的研究人员所确认)。这个值范围介于开发计划的 3-20%。多数项目集中在 原始计划的12-17%的窄范围内。 例如，假设你有一个需要 50个人月开发计划的项目。你评估维护计划需要 15%。维护 图 1 基于 Capers Jones 的一项研究结果的维护 计划的大致分布(参见 软件费用评估，McGraw Hill 1998)。表 3也列 举了基于系列文章步骤 的每个维护工作的适当 分类。 制订项目计划 第 3 页 共 4 页 的年预算需要 50*0.15，也就是7.5个人月计划。 我限定说明的是：维护的稳定期。在 CostXpert Group，我们发现对于一般系统过渡 到稳定期需要 4年的维护。在这期间，维护计划将超出稳定期计划。最好的维护计划通常 是指数下降，从四年初过渡到稳定期的下降值大概为 2倍。在这期间，附加的计划花费在 纠错和优化维护上。 这是本系列文章的总结。系列文章覆盖了开发一个软件项目基线的所有方面。尽管每 个人对于软件项目失败的产生有着自己的看法，我在Mitre公司，Cost Xpert Group， Booz， Allen & Hamilton的经验和工作告诉我，更多的项目是失败于糟糕的费用和时间评估，而 不是技术，政治或团队的问题。Capers Jones的广泛研究，给出了类似的声明(可以在他 的书《软件费用评估》中找到)。因此，不用吃惊，几乎没有公司和个人理解到，软件的评 估不仅仅是一门艺术， 而且是一门可以学习的科学。 表1 一个简单的工作分类条目结构模板 任务 百分比 说明 项目计划和管理 10 项目评估，计划和风险管理 定义商务策略 4 定义商务策略和用创造性的方式编写文档 定义市场策略 4 定义市场策略和用创造性的方式编写文档 定义需求 4 用文档和原型方式定义系统需求，定义生产和风格指南 设计 30 定义功能性说明书，技术说明书，体系结构和测试计划 开发 19 开发，包括前端，中间层，代理和接口 测试 19 测试，包括单元和集成测试 配置 10 配置，包括接受测试和要求时的用户文档 表2 可交付计划标准的例子 可交付的 A B C 说明 软件文档开发 计划(SDP) 5.000.080.91描述管理软件开发计划， 采用项目甘特图来 表示，由一个或更多的项目工作补充，次序 涵盖了工作的多个方面 策略纲要 2.000.900.91项目目标策略的文档化，商业成功的评测， 投资人和投资人的目标 创造性的纲要 2.000.900.91定义对象、目标、市场、产品定位、Web策 略和全部市场策略之间的相互管理和纽带 软件需求说明 书(SRS) 3.001.210.91计算机程序的详细需求说明，确保每个需求 能够实现的方法 原型 1.000.001.00系统原型 功能说明书 0.004.000.91从商业的角度定义后台和中间层的功能需 求。 技术概要 0.004.000.91定义系统实现的技术细节，包括对象设计 体系结构 0.002.140.91充分详细的描述站点的体系结构，便于站点 配置使用 软件测试计划 (STP) 5.000.120.91描述计算机程序的可接受测试计划。说明软 件测试环境，标明测试和测试工作的时间进 度 软件设计说明 (SDD) 0.008.000.91描述程序范围内的设计结果。软件体系结构 设计和实现软件的详细设计。包括中间层对 制订项目计划 第 4 页 共 4 页 象和应用服务器设计。所有关键运算和商业 规则的伪代码，映射了所有屏幕、排序、选 择、报表的显示要求的伪代码和所有接口的 详细的数据格式说明 软件测试说明 (STD) 5.002.270.91描述测试准备，测试用例和用于完成计算机 程序接受的测试过程 软件用户手册 (SUM) 15.02.100.91指导具有计算机使用经验的用户如何安装使 用计算机程序，包括如何完成用户工作的指 南， 在软件需求，说明书中确定的操作场景。 而且也提供了完整的屏幕、报表、菜单选择 的全面参考 表3 维护的适当分类 分类说明 维护分类 紧急程序修订 纠错 例行调试 纠错 输入数据文件的适应调整 适应 硬件操作系统的适应调整 适应 为用户作的增强提高 不包括在维护中 改善文档 不包括在维护中 提高代码效率 优化 其他 其他