软件项目计划书格式

　软件项目计划书格式

　一、项目计划书格式

　根据《GB8567-88计算机软件产品开发文件编制指南》

　中项目开发计划的要求，结合实际情况调整后的《项目计

　划书》内容索引如下：

　1引言

　编写目的 背景

　定义

　参考资料

　标准、条约和约定 2项目概述

　项目目标

　产品目标与范围 假设与约束 项目工作范围 应交付成果 需完成的软件 需提交用户的文档 须提交内部的文档 应当提供的服务 项目开发环境

　项目验收方式与依据

　3项目团队组织

　组织结构

　人员分工

　协作与沟通

　内部协作

　外部沟通

　4实施计划

　风险评估及对策

　工作流程

　总体进度计划

　项目监控

　质量控制计划

　进度监控计划

　预算监控计划

　配置管理计划

　5支持条件

　内部支持

　客户支持

　外包

　6预算

　人员成本

　设备成本

　其它经费预算

　项目合计经费预算

　7关键问题

　8专题计划要点

　二、项目计划书的编写说明

　1引言

　编写目的说明编写这份项目计划的目的，并指出预期的读者。

　作用：本节是为了说明编制“项目计划书”亦即本文

　档的意图和希望达到的效果。注意这里的“目的”不是

　“项目目标”，而是为了说明本文档的目的与作用。“项目 目标”在中说明。意义：使项目成员和项目干系人了解项 目开发计划书的作用、希望达到的效果。开发计划书的作 用一般都是“项目成员以及项目干系人之间的共识与约定, 项目生命周期所有活动的行动基础，以便项目团队根据本 计划书开展和检查项目工作。"

　例如可以这么写：为了保证项目团队按时保质地完成

　项目目标，便于项目团队成员更好地了解项目情况，使项 目工作开展的各个过程合理有序，因此以文件化的形式， 把对于在项目生命周期内的工作任务范围、各项工作的任 务分解、项目团队组织结构、各团队成员的工作责任、团 队内外沟通协作方式、开发进度、经费预算、项目内外环 境条件、风险对策等内容做出的安排以书面的方式，作为 项目团队成员以及项目干系人之间的共识与约定，项目生 命周期内的所有项目活动的行动基础，项目团队开展和检

　常见的问题：把项目本身的“项目目标”误作编制项 目开发计划的目的。

　背景

　主要说明项目的来历，一些需要项目团队成员知道的 相关情况。主要有以下内容：

　项目的名称：经过与客户商定或经过立项手续统一确 定的项目名称，一般与所待开发的软件系统名称有较大的 关系，如针对“XX系统”开发的项目名称是“XX系统开 友0

　项目的委托单位：如果是根据合同进行的软件开发项 目，项目的委托单位就是合同中的甲方；如果是自行研发 的软件产品，项目的委托单位就是本企业。

　项目的用户：软件或网络的使用单位，可以泛指某个 用户群。注意项目的用户或单位有时与项目的委托单位是 同一个，有时是不一样的。如海关的报关软件、税务的报 税软件，委托单位是海关或税务机关，但使用的用户或单 位不仅有海关或税务机关，还包括需要报关、报税的企业 单位。

　项目的任务提出者：本企业内部提出需要完成此项目 的人员，一般是领导或商务人员；注意项目的任务提出者 一般不同于项目的委托单位，前者一般是企业内部的人员。

　如果是内部开发项目，则两者的区别在于前者指人，后者 指单位。

　项目的主要承担部门：有些企业根据行业方向或工作 性质的不同把软件开发分成不同的部门。项目的特点就是 其矩阵式组织，一般一个项目的项目成员可能由不同的部 门组成，甚至可能由研发部门、开发部门、测试部门、集 成部门、服务部门等等其中几个组成。需要根据项目所涉 及的范围确定本项目的主要承担部门。

　项目建设背景：从政治环境上、业务环境上说明项目 建设背景，说明项目的大环境、来龙去脉。这有利于项目 成员更好地理解项目目标和各项任务。

　例句：根据《某部关于某建设工作的实施意见》精神, 为了保障某建设工作的正常实施，必须加强监督考核，建 立督查通报制度，某市某建设工作小组办公室把此项建设 工作实施列入督查的重要内容，及时掌握进度，相关部门 建立市某建设工作简报制度，及时反映全市某建设工作动

　o

　目前对于某建设工作的工作主要采用计划部门手工编 制年度计划、建设工作主管部门和建设工作实施单位联合 手动编制进度计划，某建设工作单位手工上报建设工作进 度情况的方式，而全市的建设工作有数百个，加上前期建 设工作的数量和今后某市建设发展的趋势，建设工作的数 量将越来越多，原来的工作模式已经越来越无法适应市委 市政府的要求。因此，充分利用现代信息化、因特网的优 势，建立“某市某建设工作信息报送反馈系统”，提高某建 设工作信息报送反馈工作效率，提高信息的及时性、减轻 各级相关工作人员的劳动强度是非常有必要和紧迫的任务。

　软件系统与其他系统的关系：说明与本系统有关的其 他系统，说明它们之间的相互依赖关系。这些系统可以是 这个系统的基础性系统，也可以是以这个系统为基础的系 统，或者是两者兼而有之的关系、互相依赖的系统。例 句：本系统中对外部办公部分如需要各个建设单位报送材 料的子系统应当挂在市政府网站。软件系统与机构的关系: 说明软件系统除了委托单位和使用单位，还与哪些机构组 织有关系。例如一些系统需要遵守那些组织的标准、需要 通过那些组织机构的测试才能使用等等、是否需要外包或 与那些组织机构合作。

　定义

　列出为正确理解本计划书所用到的专门术语的定义、 外文缩写词的原词及中文解释。注意尽量不要对一些业界 使用的通用术语进行另外的定义，使它的含义和通用术语 的惯用含义不一致。

　参考资料

　列出本计划书中所引用的及相关的文件资料和标准的 作者、标题、编号、发表日期和出版单位，必要时说明得 到这些文件资料和标准的途径。本节与下一节的“标准、 条约和约定”互为补充，注意“参考资料”未必作为“标 准、条约和约定”，因为“参考”的不一定是"必须遵守” 的。常用资料如：

　本项目的合同、标书、上级机关有关通知、经过审批 的项目任务书；

　属于本项目的其他已经发表的文件；

　本文档中各处引用的文件、资料，包括所要用到的软 件开发标准。

　标准、条约和约定

　列出在本项目开发过程中必须遵守的标准、条约和约 定。例如：相应的《立项建议书》、《项目任务书》、合同、 国家标准、行业标准、上级机关有关通知和实施方案、相 应的技术规范等。

　“参考资料” 一般具有“物质”特性，一般要说明参 照了什么，要说明在哪里可以获得；“标准、条约和约定” 一般具有“精神”特性，一般是必须遵守的，不说明在哪 里可以获得。参考资料的内容应该涵盖“标准、条约和约 c±=t ”

　7E o

　2项目概述 项目目标

　设定项目目标就是把项目要完成的工作用清晰的语言 描述出来，让项目团队每一

　个成员都有明确的概念。注意，不要简单地说成在什 么什么时间完成开发什么什么软件系统或完成什么什么软 件安装集成任务。注意“要完成一个系统”只是一个模糊 的目标，它还不够具体和明确。明确的项目目标应该指出 了服务对象，所开发软件系统最主要的功能和系统本身的 比较深层次的社会目的或系统使用后所起到的社会效果。

　项目目标应当符合SMART原则：

　ISSp ecific明确的陈述

　IMMeasura ble可以衡量的结果 lAAttainab le可以达成的目标

　IRRealist ic合理的，现实的或者说是能和实际工作 相结合

　ITTracka ble可以跟踪的项目目标可以进行横向的分解也可以进行纵向的分解。

　横向分解一般按照系统的功能或按照建设单位的不同业务 要求，如分解为第一目标、第二目标等等；纵向的分解一

　般是指按照阶段，如分解为第一阶段目标、第二阶段目标 等等，或近期目标、中期目标、远期目标等等。阶段目标 一般应当说明目标实现的较为明确的时间。一般要在说明 了总目标的基础上再说明分解目标，可加上“为实现项目 的总目标，必须实现以下三个阶段目标 ”

　产品目标与范围

　根据项目输入说明此项目要实现的软件系统产品的目 的与目标及简要的软件功能需求。对项目成果范围进行准 确清晰的界定与说明是软件开发项目活动开展的基础和依 据。软件系统产品目标应当从用户的角度说明开发这一软 件系统是为了解决用户的那些问题。产品目标如“提高工 作信息报送反馈工作效率，更好地进行工作信息报送的检 查监督，提高信息的及时性、汇总统计信息的准确性，减 轻各级相关工作人员的劳动强度。”

　假设与约束

　对于项目必须遵守的各种约束进行说明。这些内容将 限制你实现什么、怎样实现、什么时候实现、成本范围等 种种制约条件。假设是通过努力可以直接解决的问题，而 这些问题是一定要解决才能保证项目按计划完成。女口：

　“系统分析员必须在3天内到位”或“用户必须在8月8 日前确定对需求文档进行确认”

　约束一般是难以解决的问题，但可以通过其他途径回 避或弥补、取舍，如人力资源的约束限制，就必须牺牲进 度或质量等等。

　假设与约束是针对比较明确会出现的情况，如果问题 的出现具有不确定性，则应该在风险分析中列出，分析其 出现的可能性、造成的影响、应当采取的相应措施。

　项目工作范围

　说明为实现项目的目标需要进行那些工作。在必要时, 可描述与合作单位和用户的工作分工。

　注意产品范围与项目工作范围的不同含义。

　产品范围界定：软件系统产品本身范围的特征和功能 范围。

　工作范围界定：为了能够按时保质交付一个有特殊的 特征和功能的软件系统产品所要完成的那些工作任务。

　产品范围的完成情况是参照客户的需求来衡量的，而 项目范围的完成情况则是参照计划来检验的。这两个范围 管理模型间必须要有较好的统一性，以确保项目的具体工 作成果，能按特定的产品要求准时交付。

　应交付成果

　需完成的软件

　列出需要完成的程序的名称、所用的编程语言及存储 程序的媒体形式。其中软件对象可能包括：源程序、数据 库对象创建语句、可执行程序、支撑系统的数据库数据、 配置文件、第三方模块、界面文件、界面原稿文件、声音 文件、安装软件、安装软件源程序文件等等。

　需提交用户的文档

　列出需要移交给用户的每种文档的名称、内容要点及 存储形式，如需求规格说明书、帮助手册等。此处需要移 交用户的文档可参考合同中的规定。

　须提交内部的文档

　可根据《GB85 67-88计算机软件产品开发文件编制指 南》附录0： “文件编制实施规定的实例”结合各企业实际 情况调整制定《软件开发文档编制裁减衡量因素表》。根据 《因素表》确定项目对应的项目衡量因素取值，以确定本 项目应完成的阶段成果。将不适用于本项目的内容裁减， 以减少不必要的项目任务和资源。

　根据因素取值列出本项目应完成的阶段成果，说明本 项目取值所在的区间，将其他因素值区间删除。

　应当提供的服务

　根据合同或某重点建设工作需要，列出将向用户或委 托单位提供的各种服务，例如培训、安装、维护和运行支 持等。具体的工作计划如需要编制现场安装作业指导书、 培训计划等，应当在本计划“总体进度计划”中条列出。

　项目开发环境

　说明开发本软件项目所需要的软硬件环境和版本、如 操作系统、开发工具、数据库系统、配置管理工具、网络 环境。环境可能不止一种，如开发工具可能需要针对Ja va 的，也需要针对C ++的。有些环境可能无法确定，需要在 需求分析完成或设计完成后才能确定所需要的环境。

　项目验收方式与依据

　说明项目内部验收和用户验收的方式，如验收包括交 付前验收、交付后验收、试运行验收、最终验收、第三方 验收、专家参与验收等等。项目验收依据主要有标书、合 同、相关标准、项目文档。3项目团队组织 组织结构

　说明项目团队的组织结构。项目的组织结构可以从所 需角色和项目成员两个方面描述。所需角色主要说明为了 完成本项目任务，项目团队需要哪些角色构成，如项目经 理、计划经理、系统分析员、构架设计师、设计组、程序 组、

　测试组等等。组织结构可以用图形来表示，可以采用 树形图，也可以采用矩阵式图形，同时说明团队成员来自 于哪个部门。除了图形外，可以用文字简要说明各个角色 应有的技术水平。

　注意虽然有一些通用的结构可以套用，但各种不同规 模、不同形式的项目组织结构是不一样的。如产品研发项 目可能就不需要实施人员，但需要知识转移方面的人员。

　而软件编码外包的项目则不需要程序员，测试人员也可以 适当地减少。

　人员分工

　确定项目团队的的每个成员属于组织结构中的什么角 色，他们的技术水平、项目中的分工与配置，可以用列表 方式说明，具体编制时按照项目实际组织结构编写。以下 是一个示例。

　项目团队外部沟通与协作模式

　项目团队外部包括企业内部管理协助部门、项目委托 单位、客户等等。本节说明在项目开发过程中项目团队内 部与接口人员、客户沟通的方式、频次、沟通成果记录办 法等内容。明确最终用户、直接用户及其所在本企业/部 门名称和联系电话。明确协作开发的有关部门的名称、经 理姓名、承担的工作内容以及工作实施责任人的姓名、联 系电话。确定有关的合作单位的名称、负责人姓名、承担 的工作内容以及实施人的姓名、联系电话

　4实施计划

　风险评估及对策

　识别或预估项目进行过程中可能出现的风险。应该分 析风险出现的可能性、造成的影响、根据影响应该釆取的 对策，采取的措施。风险识别包括识别内在风险及外在风 险。内在风险是指项目工作组能加以控制和影响的风险， 如人事任免和成本估计等。外在风险指超岀项目工作组等 控制力和影响力之外的风险，如市场转向或政府行为等

　风险的对策包括：避免：排除特定危胁往往靠排除危 险起源；减缓：减少风险事件的预期资金投入来减低风险 发生的概率，以及减少风险事件的风险系数；吸纳：接受 一切后果，可以是积极的，也可以是消极的。

　对于软件开发项目而言，在分析、识别和管理风险上 投入足够的时间和人力可以使项目进展过程更加平稳，提 高项目跟踪和控制的能力，由于在问题发生之前已经做了 周密计划，因而对项目的成功产生更加充分的信心。

　软件开发项目常见预估的风险：

　1） 工程/规模/进度上的风险

　规模大，规模估算不精确甚至误差很大；就规模而言, 用户要求交付期、费用很紧；预料外的工作；

　2） 技术上的风险

　使用新的开发技术、新设备等，或是新的应用组合， 没有经验；是新的行业或业务，没有经验；性能上的要求 很严；

　3） 用户体制上的问题

　用户管理不严，恐怕功能决定、验收不能顺利地完成; 或者恐怕功能会多次变更；与用户分担开发，恐怕工程会 拖延；用户或其他相关单位承担的工作有可能延误；

　4）其它：应该包含此处没有、但据推测有风险的项 目。

　工作流程

　说明项目采用什么样的工作流程进行。如瀑布法工作 流程，原型法工作流程、螺旋型工作流程、迭代法工作流 程，也可以是自己创建的工作流程。不同的流程将影响后 面的工作计划的制定。必要时画出本项目采用的工作流程 图及适当的文字说明。

　总体进度计划

　这里所说的总体进度计划为高层计划。作为补充，应 当分阶段制定项目的阶段计划，这些阶段计划不在这份文 档中，当要以这份总体计划为依据。

　总体进度计划要依据确定的项目规模，列表项目阶段 划分、阶段进度安排及每阶段应提交的阶段成果，在阶段 时间安排中要考虑项目阶段成果完成、提交评审、修改的 时间。

　对于项目计划、项目准备、需求调研、需求分析、构 架设计或概要设计、编码实现、测试、移交、内部培训、 用户培训、安装部署、试运行、验收等工作，给出每项工 作任务的预定开始日期、完成日期及所需的资源，规定各

　项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件。例如

　需求评审 设计评审

　表格中检查点/里程碑等阶段划分为举例，实际作业

　阶段划分、阶段成果等请根据项目需要确定。

　制定软件项目进度计划可以使用一些专门的工具，最 常用的是M icrosoft的P roject作为辅助工具，功能比较 强大，比较适合于规模较大的项目，但无法

　完全代替项目计划书，特别是一些主要由文字来说明 的部分。小规模的项目可简便地使用EXC EL作为辅助工具。

　关于如何使用这些工具不在此作详细说明。

　制定软件项目进度计划应当考虑以下一些因素：

　1）对于系统需求和项目目标的掌握程度。如开始时对 于系统需求和项目目标只有比较数的了解，就只能制定出

　比较粗的进度计划，等到需求阶段或设计阶段结束，就应 该进一步细化进度计划。

　2）软件系统规模和项目规模，这两个不是一个概念。

　软件系统规模往往是从功能点的估算或其他估算方式得来 的，而项目规模还要考虑对文档数量与质量的要求，使用 的开发工具、新技术、多少复用、沟通的方便程度、客户 方的情况、需要遵守的标准规范等等等等。例如，完成一 个大型的系统，在一定的时间内一个人或几个人的智力和 体力是承受不了的。由于软件是逻辑、智力产品，盲目增 加软件开发人员并不能成比例地提高软件开发能力。相 反，随着人员数量的增加，人员的组织、协调、通信、培 训和管理方面的问题将更为严重。

　3） 软件系统复杂程度和项目复杂程度：和软件系统规 模和项目规模一样，软件系统的复杂程度主要是考虑软件 系统本身的功能、架构的复杂程度，而项目的复杂程度主 要是指项目团队成员的构成、项目任务的复杂程度、项目 干系人的复杂程度、需求调研的难易程度，多项目情况下 资源保障的情况，等等等等。软件系统的规模与软件系统 的复杂程度未必是成比例的关系；同样项目的规模与项目 的复杂程度未必是成比例的关系。

　4） 项目的工期要求，就是项目的紧急程度。有些项目 规模大，却因为与顾客签订了合同，或者为了抢先占领市 场，工期压缩得很紧，这时就要考虑如何更好地合理安排 进度，多增加人选多采用加班的方式是一种万不得已的选 择。增加人选除了增加人的成本外必定会增加沟通的成本; 加班如果处理不好会造成情绪上的问题，也可能会因为过 于忙碌而无法顾及质量，造成质量的下滑。

　5） 项目成员的能力。这些能力包括项目经理的管理能 力，系统分析员的分析能力、系统设计人员的设计能力、 程序员的编码能力、测试人员的测试能力，以及企业或项 目团队激发出这些能力的能力。从另外一个角度看还有总 体上对客户行业业务的熟悉程度；对于建模工具、开发工 具、测试工具等技术的掌握程度；企业内部对行业业务知 识和主要技术的知识积累。

　项目控制计划

　质量保证计划

　执行质量评审活动，对过程质量进行控制。规模较大 的项目应当单独编写《软件开发项目质量计划》。根据 GB/T12 504计算机软件质量保证计划规范，内容包括： 1引言

　1管理

　1文档

　1标准、条例和约定

　1软件配置管理1工具、技术和方法

　1媒体控制

　1对供货单位的控制

　1记录的收集、维护和保存

　进度控制计划

　本项目的进度监控执行本企业《项目管理规范》，由本

　企业过程控制部门如质量管理部统一进行监控，并保留在 监控过程中产生的日常检查记录。

　预算监控计划

　说明如何检查项目预算的使用情况。根据项目情况需 要制定。

　配置管理计划

　编制有关软件配置管理的条款，或引用按照GB/T1250

　5单独制订《配置管理计划》文档。在这些条款或文档中， 必须规定用于标识软件产品、控制和实现软件的修改、记 录和报告修改实现的状态以及评审和检查配置管理工作等 四方面的活动。还必须规定用以维护和存储软件受控版本 的方法和设施；必须规定对所发现的软件问题进行报告、 追踪和解决的步骤，并指出实现报告、追踪和解决软件问 题的机构及其职责。

　根据《GB/T1 2505计算机软件配置管理计划规范》，软 件配置管理计划内容如下：

　1引言

　1管理1软件配置管理活动

　1工具、技术和方法

　1对供货单位的控制

　1记录的收集、维护和保存

　5支持条件

　说明为了支持本项目的完成所需要的各种条件和设施。

　内部支持

　逐项列出项目每阶段的支持需求及其时间要求和用途。

　例如，设备、软件支持包括客户机、服务器、网络环 境、外设、通讯设备、开发工具、操作系统、数据库管理 系统、测试环境，逐项列出有关到货日期、使用时间的要 求。

　客户支持

　列岀对项目而言需由客户承担的工作、完成期限和验 收标准，包括需由客户提供的条件及提供时间。

　外包

　列出需由外单位分合同承包者承担的工作、完成时间, 包括需要由外单位提供的条件和提供的时间。

　6预算

　人员成本

　列出产品/项目团队每一个人的预计工作月数。

　列出完成本项目所需要的劳务

　劳务费一般包括工资、奖金、补贴、住房基金、退休 养老金、医疗保险金

　设备成本

　设备成本包括：原材料费，设备购置及使用费

　列出拟购置的设备及其配置和所需的经费

　列出拟购置的软件及其版本和所需的经费

　使用的现有设备及其使用时间 其它经费预算

　列出完成本项目所需要的各项经费，包括差旅费、资 料费、通行费、会议费、交通费、办公费、培训费、外包 费等，包括：

　差旅费

　资料费

　通信费

　会议费

　办公费

　协作费

　培训费

　其他

　项目合计经费预算

　列出完成本项目需要的所有经费预算。

　7关键问题

　逐项列出能够影响整个项目成败的关键问题、技术难 点和风险，指出这些问题对项目成败的影响。

　8专题计划要点

　专题计划也就是因为项目的需要在本文档之外独立建 立的计划，本节说明本项目开发中需要制定的各个专题计 划的要点。专题计划可能包括分合同计划、分项目计划、 项目团队成员培训计划、测试计划、安全保密计划、质量 保证计划、配置管理计划、用户培训计划、系统安装部署 计划。