软件开发项目计划编制过程

本文转自:http://pm.csai.cn/contract/No209.htm及相关

来源：希赛网 作者： 卢琳生 [2005/04/27]

摘要 本文简要说明了软件开发项目的计划的要素、计划编制过程、以及项目计划内容确定的一般过程。 关键词 项目管理、计划、编制过程 正文 一、项目计划的要素 根据PMBOK2000，项目计划可以包含如下要素： 1、 项目范围说明 项目范围说明阐述进行这个项目的原因或意义，形成项目的基本框架，使项目所有者或项目管理者能够系统地、逻辑地分析项目关键问题及项目形成中的相互作用要素，使项目干系人在项目开始实施前或项目相关文档编写以前，能够就项目的基本内容和结构达成一致；项目范围说明应当形成项目成果核对清单，作为项目评估的依据，在项目终止以后或项目最终报告完成以前进行评估，以此作为评价项目成败的依据；范围说明还可以作为项目整个生命周期监控和考核项目实施情况的基础，和项目其他相关计划的基础。 2、 项目进度计划 进度计划是说明项目中各项工作的开展顺序、开始时间、完成时间及相互依赖衔接关系的计划。通过进度计划的编制，使项目实施形成一个有机的整体。进度计划是进度控制和管理的依据，可以分为项目进度控制计划和项目状态报告计划。 在进度控制计划中，要确定应该监督哪些工作、何时进行监督、监督负责人是谁，用什么样的方法收集和处理项目进度信息，怎样按时检查工作进展和采取什么调整措施，并把这些控制工作所需的时间和人员、技术、物资资源等列入项目总计划中。 3、 项目质量计划 质量计划针对具体待定的项目，安排质量监控人员及相关资源、规定使用那些制度、规范、程序、标准。项目质量计划应当包括与保证与控制项目质量有关的所有活动。质量计划的目的是确保项目的质量目标都能达到。根据ISO9001要求和PMBOK2000，为实现质量目标，组织应遵循以顾客为中心、领导作用、全员参与、过程方法、管理的系统方法、持续改进、基于事实的决策方法、互利的供方关系等8项质量管理原则。 4、 项目资源计划 有了项目范围计划和进度计划后，资源计划就是决定在项目中的每一项工作中用什么样的资源（人、材料、设备、信息、资金等等），在各个阶段使用多少资源。项目费用计划包括资源计划、费用估算、费用预算。 5、 项目沟通计划 沟通计划就是制定项目过程中项目干系人之间信息交流的内容、人员范围、沟通方式、沟通时间或频率等沟通要求的约定 6、 风险对策计划 风险对策计划是为了降低项目风险的损害而分析风险、制定风险应对策略方案的过程，包括识别风险、量化风险、编制风险应对策略方案等过程 7、 项目采购计划 项目采购计划过程就是识别哪些项目需求可应通过从本企业外部采购产品或设备来得到满足。如果是软件开发工作的采购，也就是外包，应当同时制定对外包的进度监控和质量控制的计划。 8、 变更控制、配置管理计划 由于项目计划无法保证一开始就预测得非常准确，在项目进行过程中也不能保证准确有力的控制，导致项目计划与项目实际情况不符的情况经常发生，所以必须有效处理项目的变更。变更控制计划主要是规定变更的步骤、程序，配置管理计划就是确定项目的配置项和基线，控制配置项的变更，维护基线的完整性，向项目干系人提供配置项的准确状态和当前配置数据。 二、项目计划编制过程 由于软件开发的手工性、个体性特征，软件开发项目计划不可能是一个静态的计划，一次在项目启动时，可以先制定一个颗粒度相对比较粗的项目计划，先确定项目高层活动和预期里程碑。粗颗粒度的项目计划需要不断地更新迭代，根据项目的大小和性质以及项目的进展情况进行迭代和调整。迭代和调整的周期也是根据项目的情况进行制订的，一般短到一周，长到2个月左右。经过不断的计划制订、调整、修订等工作，项目计划从最初的粗粒度，变得非常详细。这样的计划将一直延续到项目结束，延续到项目的成果出现。 制定计划的过程就是一个对项目逐渐了解掌握的过程，通过认真地制定计划，项目经理可以知道哪些要素是明确的，哪些要素是要逐渐明确的，通过渐近明细不断完善项目计划。阶段计划中包含的工作汇报和下一阶段工作安排是掌握项目进度的依据，从阶段计划对照总体计划，才能一目了然地看出工作的进展情况。制定计划的过程，也是在进度、资源、范围之间寻求一种平衡的过程。制定计划的精髓不在于写出一份好看的文档，而在于运用您的智慧去应对各种问题和面临风险并尽可能做出前瞻性的思考。一旦计划被负责任地完成，他就可以给自己一个和管理层或客户交流与协商的基础，帮助你在项目过程中防范各种问题的出现，帮助你保证项目按时完成。 企业确定要开始某个项目时一般会下达一个立项的文件，暂且叫“项目立项文件”，主要内容是遵照的合同或相关协议，项目的大致范围、项目结束的截止时间和一些关键时间，指定项目经理和部分项目成员等等。 接下来的项目计划编写一般要按照以下过程： 1 成立项目团队：相关部门收到经过审批后的“项目立项文件”和相关资料，则正式在“项目立项文件”中指定的项目经理组织项目团队，成员可以随着项目的进展可以在不同时间加入项目团队，也可以随着分配的工作完成而退出项目团队。但最好都能在项目启动时参加项目启动会议，了解总体目标、计划，特别是自己的目标职责，加入时间等等。 2 项目开发准备：项目经理组织前期加入的项目团队成员准备项目工作所需要的规范、工具、环境。如开发工具、源代码管理工具、配置环境、数据库环境等。前期加入的项目团队成员主要由计划经理，系统分析员等组成，但快要制定好的项目计划一定要尽可能经过在所有项目团队成员和项目干系人中间的充分沟通。如果项目中存在一些关键的（指将影响项目成败）技术风险，则在这一阶段项目经理应组织人员进行预研。预研的结果应留下下书面结论以备评审。 说明：项目计划书必须在相应阶段对项目目标、阶段目标和各项任务进行精确的定义，就是要在相应阶段进一步进行项目目标的细化工作；特别是在概要设计完成，详细设计或编码实现开始之前应该对下一阶段的目标任务进行细化。应当充分调查并掌握影响项目计划的一切内部和外部影响因素；应当尽可能充分地分析项目工作分解结构，通过分析项目工作分解结构不仅获得项目的静态结构，而且通过逻辑分析，获得项目各工作任务之间动态的工作流程；应当将项目目标、任务进行分解，制定详细的实施方案。 3 项目信息收集：项目经理组织项目团队成员通过分析接收的项目相关文档、进一步与用户沟通等途径，在规定的时间内尽可能全面收集项目信息。项目信息收集要讲究充分的、有效率的沟通，并要达成共识。有些成员认为，电子邮件发来的文档（计划、需求、周计划等）是在沟通不够充分的情况下完成的，成员看过后有不了解或与自己的能力或意愿不符的情况，但通过电子邮件等方式沟通的效率不高，这也许是个习惯的问题，也许和某个具体问题本身是否容易通过电子邮件沟通清楚有关。因此重要的内容需要开会进行Q&A讨论，确保所有重要问题都得到理解，最终达成共识。讨论会上达成共识的应当记录成文字落实在具体的文档中。 4 编写《软件项目计划书》 项目经理负责组织编写《软件项目计划书》。《软件项目计划书》 是项目策划活动核心输出文档，它包括计划书主体和以附件形式存在的其他相关计划，如配置管理计划等。《软件项目计划书》的编制参考《GB8567－88计算机软件产品开发文件编制指南》中项目开发计划的要求。各企业在建立ISO9001质量管理体系或CMM过程中也会建立相应的《软件开发项目计划书规范》。 编制项目计划的过程应当分为以下几个步骤： a、确定项目的应交付成果。这里的项目的应交付成果不仅是指项目的最终产品，也包括项目的中间产品。例如通常情况下软件开发项目的项目产品可以是：需求规格说明书、概要设计说明书、详细设计说明书、数据库设计说明书、项目阶段计划、项目阶段报告、程序维护说明书、测试计划、测试报告、程序代码与程序文件、程序安装文件、用户手册、验收报告、项目总结报告等等； b、任务分解：从项目目标开始，从上到下，层层分解，确定实现项目目标必须要做的各项工作，并画出完整的工作分解结构图。软件开发项目刚开始可能只能从阶段的角度划分，如需求分析工作、架构设计工作、编码工作、测试工作等等，当然规模较大时也可把需求、设计拆分成不同的任务。不过特别是在概要设计完成时可以对下一阶段的目标任务进行横向的细化。 c、在资源独立的假设前提下确定各个任务之间的相互依赖关系，以确定各个任务开始和结束时间的先后顺序；获得项目各工作任务之间动态的工作流程。 d、确定每个任务所需的时间，即根据经验或应用相关方法给任务需要耗费的时间；确定每个任务所需的人力资源要求，如需要什么技术、技能、知识、经验、熟练程度等等。 e、确定项目团队成员可以支配的时间，即每个项目成员具体花在项目中的确切时间；确定每个项目团队成员的角色构成、职责、相互关系、沟通方式。 f、确定管理工作，管理工作是贯穿项目生命周期的，如项目管理、项目会议等、编写阶段报告。项目团队成员之间的沟通时间、项目团队成员和其他项目干系人之间的沟通时间也比较容易被忽视，而沟通时间也是比较不容易固定地量化和日程化。但这些工作在计划中都应当充分地被考虑进去，再回师项目计划更加合理，更有效地减少因为计划的不合理而导致的项目进度延期。 g、根据以上结果编制项目总体进度计划，总体进度计划应当体现任务名称、责任人、开始时间、结束时间、应提交的可检查的工作成果。 h、考虑项目的费用预算、可能的风险分析及其对策、需要公司内部或客户或其他方面协调或支持的事宜。 5 软件项目计划书评审、批准 项目计划书评审、批准是为了使相关人员达成共识、减少不必要的错误，使项目计划更合理更有效。 项目经理完成《软件项目计划书》后，首先组织项目团队内部的项目团队负责人、测试负责人、系统分析负责人、设计负责人、质量监督员等对项目计划书进行评审，评审可采取电子或会议方式，并进行阶段成果项目团队内评阅记录。应当要求所有相关人员在收到软件项目计划书后的一个约定时间内反馈对计划书的意见。项目经理确保与所有人员就项目计划书中所列内容达成一致。这种一致性是要求所有项目团队成员对项目计划的内容进行承诺，无法承诺或者说是无法达成一致的，要么修改项目计划去适应某些项目团队成员，要么是由某些项目团队成员采取妥协措施，去适应项目计划的要求。 项目经理将已经达成一致的软件项目计划书提交项目高层分管领导或其授权人员进行审批，审批完成时间不能超过预先约定的时间。对于意义重大的项目，由过程控制部门如质量管理部和项目分管领导同时对《软件项目计划书》进行审批。 批准后的软件项目计划书作为项目活动开展的依据和本企业进行项目控制和检查的依据，并在必要时根据项目进展情况实施计划变更。 项目质量监督员根据《软件项目计划书》和《软件开发项目质量计划书规范》编制软件开发项目质量计划。大型的项目应当编制单独的《软件开发项目质量计划书》；规模较小的可以在《软件项目计划书》的某个章节说明“软件开发项目质量计划”，也可单独编制类似“软件开发项目质量控制表”的文档。 配置管理员根据计划书编制《项目配置管理计划》。以项目工作计划书中的阶段成果为依据，根据配置管理计划规范编制配置管理计划，项目经理审批配置管理计划，并对配置管理计划的有效性负责。 项目策划工作完毕，软件项目计划书通过评审，一般情况下，对软件开发项目来说，工作转入需求分析阶段。 三、项目计划内容确定 项目计划内容的确定一般要按照以下过程： 1 确定项目概貌 合同项目以合同和招投标文件为依据，非合同项目以可行性研究报告或项目前期调研成果为依据，明确项目范围和约束条件，并以同样的依据，明确项目的交付成果。进一步明确项目的工作范围和项目参与各方责任。 2 确定项目团队 确定项目团队的组织结构和与项目开发相关的职能机构，包括管理、开发、测试、QA、评审、验收等。确定项目团队人员及分工。与相关人员协商，确定项目团队人员构成。如内部不能满足人员需求，则提出人员支援申请。 3 明确项目团队内、外的协作沟通 明确与用户单位的沟通方法。明确最终用户、直接用户及其所在本企业／部门名称和联系电话。客户更多的参与是项目成功的重要推动力量，加强在开发过程中与用户方项目经理或配合人员的主动沟通，将有助加强客户等项目的参与程度。建议采用周报或月报的方式通告项目的进展情况和下一阶段计划，出现的需要客户协调或了解的问题。 当项目团队需要与外部单位协作开发时，应明确与协作单位的沟通方式。确定协作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。 明确本企业内部协作开发的部门名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。 明确项目团队沟通活动。项目团队成员规模在3人以上的项目应该组织项目团队周例会，项目团队采用统一的交流系统建立项目团队的交流空间。 4 规划开发环境和规范 说明系统开发的所采用的各种工具，开发环境，测试环境等。列出项目开发要遵守的开发技术规范和行业标准规范。对于本企业还没有规范的开发技术，项目经理应组织人员制订出在本项目中将遵守的规则。 5 编制工作进度计划 根据本企业规定和项目实际情况，确定项目的工作流程。编制项目的工作计划，此计划为高层计划，各阶段的工作时间安排要包括完成阶段文档成果、文档成果提交评审及进行修改的时间，各阶段结束的标志是阶段成果发布。在计划中要求明确以下内容： a、工作任务划分； b、显示项目各阶段或迭代的时间分配情况的时间线或甘特图； c、确定主要里程碑、阶段成果； d、要求用文字对项目工作计划做出解释。最终用一张时间表格来完整说明整个工作计划； 对于迭代开发的项目，应编制出第一阶段的阶段计划。阶段内的任务分割以2-5天为合适，特殊任务的时间跨度在两个星期内； 在项目的进行过程中，项目经理编制双周工作计划，指导成员的具体工作。 6 编制项目的监控计划。其中说明进度控制、质量控制、版本控制、预算控制等。 7 编制项目的风险计划，分析项目过程中可能出现的风险以及相应的风险对策。对于大型项目，建议以附件方式编制，便于不断更新。 8 制定辅助工作计划。根据项目需要，编制如培训计划、招聘计划等。 9 规划开发支持工作，如供方管理计划。 10 规划项目验收：制定项目的验收计划。此项工作可以视需要进行裁减。 11 规划项目收尾与交接活动。制定项目的验收、培训和项目进入维护阶段与技术支持部的交接工作。 参考文献 《管理软件开发项目》（第二版）Neal Whitten（软件项目管理系列丛书，孙艳春等译）； 《IT项目管理》Kathy Schwalbe（项目管理译丛 王金玉等译）； 《项目管理—计划、进度和控制的系统方法》（第7版）Harold Kerzner（电子工业出版社，杨爱华等译）； 《实用软件工程》（第二版）郑人杰、殷人昆、陶永雷（清华大学出版社） 《软件工程：实践者的研究方法》（第5版）Roger S.Pressman著； 《ISO9001：2000质量管理体系的要求》； 《高级项目管理基础》（信息产业部计算机信息系统集成高级项目经理培训讲义）； 《成功的项目管理》Trevol L Young（泰晤士报商业版，严鸿娟译）； 《成功的项目管理》Jack Gido ＆ James P. Clements（21世纪管理经典教材系列，张金城等译）； 《如何做好项目管理》Stanley E. Portny（IDG新经济工商实务傻瓜丛书，宁俊等译）； 《PMBOK-2000》PMI； 本文完成日期：2005年3月23日 本文作者邮箱：[email protected]或[email protected] 欢迎指正。 软件开发项目计划书编写说明 摘要 本文主要对软件开发项目计划书的格式及主要内容的编写要点进行说明，对一些内容进行了举例说明。 关键词 项目、计划书、格式、编写说明 正文 一、项目计划书格式 根据《GB8567－88计算机软件产品开发文件编制指南》中项目开发计划的要求，结合实际情况调整后的《项目计划书》内容索引如下： 1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料 1.5 标准、条约和约定 2 项目概述 2.1项目目标 2.2产品目标与范围 2.3假设与约束 2.4 项目工作范围 2.5 应交付成果 2.5.1 需完成的软件 2.5.2 需提交用户的文档 2.5.3 须提交内部的文档 2.5.4 应当提供的服务 2.6 项目开发环境 2.7 项目验收方式与依据 3 项目团队组织 3.1 组织结构 3.2 人员分工 3.3 协作与沟通 3.3.1 内部协作 3.3.2 外部沟通 4 实施计划 4.1 风险评估及对策 4.2 工作流程 4.3 总体进度计划 4.4 项目监控 4.4.1 质量控制计划 4.4.2 进度监控计划 4.4.3 预算监控计划 4.4.4 配置管理计划 5 支持条件 5.1 内部支持（可选） 5.2 客户支持（对项目而言） 5.3 外包（可选） 6 预算（可选） 6.1 人员成本 6.2 设备成本 6.3 其它经费预算 6.4 项目合计经费预算 7 关键问题 8专题计划要点 二、项目计划书的编写说明 1 引言 1.1 编写目的 说明编写这份项目计划的目的，并指出预期的读者。 作用：本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。注意这里的“目的”不是“项目目标”，而是为了说明本文档的目的与作用。“项目目标”在2.1中说明。 意义：使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定，项目生命周期所有活动的行动基础，以便项目团队根据本计划书开展和检查项目工作。” 例如可以这么写：为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。 常见的问题：把项目本身的“项目目标”误作编制项目开发计划的目的。 1.2 背景 主要说明项目的来历，一些需要项目团队成员知道的相关情况。主要有以下内容： 项目的名称：经过与客户商定或经过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“XX系统”开发的项目名称是“XX系统开发”。 项目的委托单位：如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方；如果是自行研发的软件产品，项目的委托单位就是本企业。 项目的用户（单位）：软件或网络的使用单位，可以泛指某个用户群。注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。如海关的报关软件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。 项目的任务提出者：本企业内部提出需要完成此项目的人员，一般是领导或商务人员；注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。如果是内部开发项目，则两者的区别在于前者指人，后者指单位。 项目的主要承担部门：有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门（也有的分为不同事业部）。项目的特点就是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要根据项目所涉及的范围确定本项目的主要承担部门。 项目建设背景：从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。 例句：根据《某部关于某建设工作的实施意见》精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。 目前对于某建设工作的工作主要采用计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划，某建设工作单位手工上报建设工作进度情况的方式，而全市的建设工作有数百个，加上前期建设工作的数量和今后某市建设发展的趋势，建设工作的数量将越来越多，原来的工作模式已经越来越无法适应市委市政府的要求。因此，充分利用现代信息化、因特网的优势，建立“某市某建设工作信息报送反馈系统”，提高某建设工作信息报送反馈工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。 软件系统与其他系统的关系：说明与本系统有关的其他系统，说明它们之间的相互依赖关系。这些系统可以是这个系统的基础性系统（一些数据、环境等必须依靠这个系统才能运行），也可以是以这个系统为基础的系统，或者是两者兼而有之的关系、互相依赖的系统。例句：本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在市政府网站。 软件系统与机构的关系：说明软件系统除了委托单位和使用单位，还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。 1.3 定义 列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义，使它的含义和通用术语的惯用含义不一致。 1.4 参考资料 列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位，必要时说明得到这些文件资料和标准的途径。本节与下一节的“标准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”，因为“参考”的不一定是“必须遵守”的。常用资料如： 本项目的合同、标书、上级机关有关通知、经过审批的项目任务书； 属于本项目的其他已经发表的文件； 本文档中各处引用的文件、资料，包括所要用到的软件开发标准。 1.5 标准、条约和约定 列出在本项目开发过程中必须遵守的标准、条约和约定。例如：相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。 “参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得；“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。 2 项目概述 2.1 项目目标 设定项目目标就是把项目要完成的工作用清晰的语言描述出来，让项目团队每一个成员都有明确的概念。注意，不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个模糊的目标，它还不够具体和明确。明确的项目目标应该指出了服务对象，所开发软件系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。 项目目标应当符合SMART原则： l S Specific 明确的陈述 l M Measurable 可以衡量的结果 l A Attainable 可以达成的目标 l R Realistic 合理的，现实的或者说是能和实际工作相结合 l T Trackable 可以跟踪的 项目目标可以进行横向的分解也可以进行纵向的分解。横向分解一般按照系统的功能或按照建设单位的不同业务要求，如分解为第一目标、第二目标等等；纵向的分解一般是指按照阶段，如分解为第一阶段目标、第二阶段目标等等，或近期目标、中期目标、远期目标等等。阶段目标一般应当说明目标实现的较为明确的时间。一般要在说明了总目标的基础上再说明分解目标，可加上“为实现项目的总目标，必须实现以下三个阶段目标······” 2.2 产品目标与范围 根据项目输入（如合同、立项建议书、项目技术方案、标书等）说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。对项目成果（软件系统）范围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。产品目标如“提高工作信息报送反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强度。” 2.3 假设与约束 对于项目必须遵守的各种约束（时间、人员、预算、设备等）进行说明。这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。 假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成。如：“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认” 约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。 假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性（概率）、造成的影响、应当采取的相应措施。 2.4 项目工作范围 说明为实现项目的目标需要进行那些工作。在必要时，可描述与合作单位和用户的工作分工。 注意产品范围与项目工作范围的不同含义。 产品范围界定：软件系统产品本身范围的特征和功能范围。 工作范围界定：为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。 产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。 2.5 应交付成果 2.5.1 需完成的软件 列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。其中软件对象可能包括：源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。 2.5.2 需提交用户的文档 列出需要移交给用户的每种文档的名称、内容要点及存储形式，如需求规格说明书、帮助手册等。此处需要移交用户的文档可参考合同中的规定。 2.5.3 须提交内部的文档 可根据《GB8567-88计算机软件产品开发文件编制指南》附录O：“文件编制实施规定的实例（参考件）”结合各企业实际情况调整制定《软件开发文档编制裁减衡量因素表》。根据《因素表》确定项目对应的项目衡量因素取值，以确定本项目应完成的阶段成果。将不适用于本项目的内容裁减，以减少不必要的项目任务和资源。 根据因素取值列出本项目应完成的阶段成果，说明本项目取值所在的区间，将其他因素值区间删除。 2.5.4 应当提供的服务 根据合同或某重点建设工作需要，列出将向用户或委托单位提供的各种服务，例如培训、安装、维护和运行支持等。具体的工作计划如需要编制现场安装作业指导书、培训计划等，应当在本计划“4.3总体进度计划”中条列出。 2.6 项目开发环境 说明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。环境可能不止一种，如开发工具可能需要针对Java的，也需要针对C++的。有些环境可能无法确定，需要在需求分析完成或设计完成后才能确定所需要的环境。 2.7 项目验收方式与依据 说明项目内部验收和用户验收的方式，如验收包括交付前验收、交付后验收、试运行（初步）验收、最终验收、第三方验收、专家参与验收等等。项目验收依据主要有标书、合同、相关标准、项目文档（最主要是需求规格说明书）。 3 项目团队组织 3.1 组织结构 说明项目团队的组织结构。项目的组织结构可以从所需角色和项目成员两个方面描述。所需角色主要说明为了完成本项目任务，项目团队需要哪些角色构成，如项目经理、计划经理、系统分析员（或小组）、构架设计师、设计组、程序组、测试组等等。组织结构可以用图形来表示，可以采用树形图，也可以采用矩阵式图形，同时说明团队成员来自于哪个部门。除了图形外，可以用文字简要说明各个角色应有的技术水平。 注意虽然有一些通用的结构可以套用，但各种不同规模、不同形式的项目组织结构是不一样的。如产品研发项目可能就不需要实施人员（小组），但需要知识转移方面的人员（小组）。而软件编码外包的项目则不需要程序员，测试人员也可以适当地减少。 3.2 人员分工 确定项目团队的的每个成员属于组织结构中的什么角色，他们的技术水平、项目中的分工与配置，可以用列表方式说明，具体编制时按照项目实际组织结构编写。以下是一个示例。 3.3 协作与沟通 项目的沟通与协作首先应当确定协作与沟通的对象，就是与谁协作、沟通。沟通对象应该包括所有项目干系人，而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。 其次应当确定协作模式与沟通方式。沟通方式如会议、使用电话、QQ、内部邮件、外部邮件、QuickPlace、聊天室等等。其中邮件沟通应当说明主送人、抄送人，聊天室沟通方式应当约定时间周期。而协作模式主要说明在出现什么状况的时候各个角色应当（主动）采取什么措施，包括沟通，如何互相配合来共同完成某项任务。定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等 3.3.1 项目团队内部协作 本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。 3.3.2 项目接口人员 应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括： a、负责本项目同用户的接口人员； b、负责本项目同本企业各管理机构，如计划管理部门、合同管理部门、采购部门、质量管理部门、财务部门等的接口人员； c、负责本项目同分包方的接口人员。 3.3.3 项目团队外部沟通与协作模式 项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录办法等内容。明确最终用户、直接用户及其所在本企业／部门名称和联系电话。明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。 4 实施计划 4.1 风险评估及对策 识别或预估项目进行过程中可能出现的风险。应该分析风险出现的可能性（概率）、造成的影响、根据影响应该采取的对策，采取的措施。风险识别包括识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响的风险，如人事任免和成本估计等。外在风险指超出项目工作组等控制力和影响力之外的风险，如市场转向或政府行为等 风险的对策包括：避免：排除特定危胁往往靠排除危险起源；减缓：减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数；吸纳：接受一切后果，可以是积极的（如制定预防性计划来防备风险事件的发生），也可以是消极的（如某些费用超支则接受低于预期的利润）。 对于软件开发项目而言，在分析、识别和管理风险上投入足够的时间和人力可以使项目进展过程更加平稳，提高项目跟踪和控制的能力，由于在问题发生之前已经做了周密计划，因而对项目的成功产生更加充分的信心。 软件开发项目常见预估的风险： 1) 工程／规模／进度上的风险 规模大，规模估算不精确甚至误差很大；就规模而言，用户要求交付期、费用很紧；预料外的工作(测试未完时的现场对应等)； 2) 技术上的风险 使用新的开发技术、新设备等，或是新的应用组合，没有经验；是新的行业或业务，没有经验；性能上的要求很严； 3) 用户体制上的问题 用户管理不严，恐怕功能决定、验收不能顺利地完成（或者出现了延迟）；或者恐怕功能会多次变更；与用户分担开发，恐怕工程会拖延（或者出现了延迟）；用户或其他相关单位承担的工作有可能延误； 4) 其它：应该包含此处没有、但据推测有风险的项目。 4.2 工作流程 说明项目采用什么样的工作流程进行。如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己创建的工作流程。不同的流程将影响后面的工作计划的制定。必要时画出本项目采用的工作流程图及适当的文字说明。 4.3 总体进度计划 这里所说的总体进度计划为高层计划。作为补充，应当分阶段制定项目的阶段计划，这些阶段计划不在这份文档中，当要以这份总体计划为依据。 总体进度计划要依据确定的项目规模，列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果，在阶段时间安排中要考虑项目阶段成果完成、提交评审、修改的时间。 对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作，给出每项工作任务的预定开始日期、完成日期及所需的资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（里程碑）。 例如 ` 需求评审 设计评审 表格中检查点／里程碑等阶段划分为举例，实际作业阶段划分、阶段成果等请根据项目需要确定。 制定软件项目进度计划可以使用一些专门的工具，最常用的是Microsoft的Project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但无法完全代替项目计划书，特别是一些主要由文字来说明的部分。小规模的项目可简便地使用EXCEL作为辅助工具。关于如何使用这些工具不在此作详细说明。 制定软件项目进度计划应当考虑以下一些因素: 1）对于系统需求和项目目标的掌握程度。如开始时对于系统需求和项目目标只有比较数的了解，就只能制定出比较粗的进度计划，等到需求阶段或设计阶段结束，就应该进一步细化进度计划。 2）软件系统规模和项目规模，这两个不是一个概念。软件系统规模往往是从功能点的估算或其他估算方式得来的，而项目规模还要考虑对文档数量与质量的要求，使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。例如，完成一个大型的系统，在一定的时间内一个人或几个人的智力和体力是承受不了的。由于软件是逻辑、智力产品，盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理方面的问题将更为严重。 3）软件系统复杂程度和项目复杂程度：和软件系统规模和项目规模一样，软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度，而项目的复杂程度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度，多项目情况下资源保障的情况，等等等等。软件系统的规模与软件系统的复杂程度未必是成比例的关系；同样项目的规模与项目的复杂程度未必是成比例的关系。 4）项目的工期要求，就是项目的紧急程度。有些项目规模大，却因为与顾客签订了合同，或者为了抢先占领市场，工期压缩得很紧，这时就要考虑如何更好地合理安排进度，多增加人选多采用加班的方式是一种万不得已的选择。增加人选除了增加人的成本外必定会增加沟通的成本（熟悉项目任务所需要的时间）；加班如果处理不好会造成情绪上的问题，也可能会因为过于忙碌而无法顾及质量，造成质量的下滑。 5）项目成员的能力。这些能力包括项目经理的管理能力，系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力，以及企业或项目团队激发出这些能力的能力。从另外一个角度看还有总体上对客户行业业务的熟悉程度；对于建模工具、开发工具、测试工具等技术的掌握程度；企业内部对行业业务知识和主要技术的知识积累。 4.4 项目控制计划 4.4.1 质量保证计划 执行质量评审活动，对过程质量进行控制。规模较大的项目应当单独编写《软件开发项目质量计划》。根据GB/T 12504 计算机软件质量保证计划规范，内容包括： l 引言（本章节包括质量计划的目的、定义、参考资料） l 管理（描述负责软件质量管理的机构、任务及其相关的职责） l 文档（列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则） l 标准、条例和约定（列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施） l 评审和检查（规定所要进行的技术和管理两个方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查） l 软件配置管理（编制有关配置管理条款，或在“4.4.4 配置管理计划”中说明，或引用按照《GB/T 12505 计算机软件配置管理计划规范》单独制定的文档） l 工具、技术和方法（指明用于支持特定软件项目质量管理工作的工具、技术和方法，指出它们的目的和用途） l 媒体控制（说明保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化） l 对供货单位的控制（供货单位包括项目承办单位、软件销售单位、软件开发单位。规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。） l 记录的收集、维护和保存（指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限） 4.4.2 进度控制计划 （可直接引用以下描述或根据项目情况制定本节内容） 本项目的进度监控执行本企业《项目管理规范》，由本企业过程控制部门如质量管理部统一进行监控，并保留在监控过程中产生的日常检查记录。 4.4.3 预算监控计划 说明如何检查项目预算的使用情况。根据项目情况需要制定。 4.4.4 配置管理计划 编制有关软件配置管理的条款，或引用按照GB/T 12505单独制订《配置管理计划》文档。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。 根据《GB/T 12505 计算机软件配置管理计划规范》，软件配置管理计划内容如下： l 引言（本章节包括质量计划的目的、定义、参考资料） l 管理（描述负责软件配置管理的机构、任务、职责及其有关的接口控制。） l 软件配置管理活动（描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等到四方面的软件配置管理活动的需求。） l 工具、技术和方法（指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法） l 对供货单位的控制（供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求） l 记录的收集、维护和保存（指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施，并指明要保存的期限） 5 支持条件 说明为了支持本项目的完成所需要的各种条件和设施。 5.1 内部支持 逐项列出项目每阶段的支持需求（含人员、设备、软件、培训等）及其时间要求和用途。 例如，设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境，逐项列出有关到货日期、使用时间的要求。 5.2 客户支持 列出对项目而言需由客户承担的工作、完成期限和验收标准，包括需由客户提供的条件及提供时间。 5.3 外包（可选） 列出需由外单位分合同承包者承担的工作、完成时间，包括需要由外单位提供的条件和提供的时间。 6 预算 6.1 人员成本 列出产品/项目团队每一个人的预计工作月数。 列出完成本项目所需要的劳务（包括人员的数量和时间） 劳务费一般包括工资、奖金、补贴、住房基金、退休养老金、医疗保险金 6.2 设备成本 设备成本包括：原材料费，设备购置及使用费 列出拟购置的设备及其配置和所需的经费 列出拟购置的软件及其版本和所需的经费 使用的现有设备及其使用时间 6.3 其它经费预算 列出完成本项目所需要的各项经费，包括差旅费、资料费、通行费、会议费、交通费、办公费、培训费、外包费等，包括： （1） 差旅费（旅费、出租）（含补贴） （2） 资料费（图书费、资料费、复印费、出版费） （3） 通信费（市话长话费、移动通信费、上网费、邮资） （4） 会议费（鉴定费、评审会、研讨费、外事费等） （5） 办公费（购买办公用品） （6） 协作费（业务协作招待费、项目团队加班伙食费） （7） 培训费（培训资料编写费、资料印刷费、产地费、设备费） 其他（检测、外加工费、维修费、消耗品、低易品、茶话会等） 6.4 项目合计经费预算 列出完成本项目需要的所有经费预算（上述各项费用之和）。 7 关键问题 逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目成败的影响。 8专题计划要点 专题计划也就是因为项目的需要在本文档之外独立建立的计划，本节说明本项目开发中需要制定的各个专题计划的要点。专题计划可能包括分合同计划、分项目计划、项目团队成员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装部署计划。 参考文献 《项目管理—计划、进度和控制的系统方法》（第7版）Harold Kerzner（电子工业出版社，杨爱华等译）； 《计算机软件工程规范国家标准汇编2003》中国标准出版社； 《PMBOK-2000》PMI； 《PMBOK-2004》PMI； 《成功的项目管理》Trevol L Young（泰晤士报商业版，严鸿娟译）； 《成功的项目管理》Jack Gido ＆ James P. Clements（21世纪管理经典教材系列，张金城等译）； 《如何做好项目管理》Stanley E. Portny（IDG新经济工商实务傻瓜丛书，宁俊等译）； 《管理软件开发项目》（第二版）Neal Whitten（软件项目管理系列丛书，孙艳春等译）； 《IT项目管理》Kathy Schwalbe（项目管理译丛 王金玉等译）； 《高级项目管理基础》（信息产业部计算机信息系统集成高级项目经理培训讲义） 本文完成日期：2005年4月28日 本文作者邮箱：[email protected]或[email protected] 欢迎指正。