it项目计划书模板Word格式.docx

1、 需提交用户的文档 . 3 须提交内部的文档 . 3 应当提供的服务 . 4 项目开发环境 . 4 项目验收方式与依据 . 43 项目团队组织 . 4 组织结构 . 4 人员分工 . 4 协作与沟通 . 5 项目团队内部协作 . 5 项目接口人员 . 5 项目团队外部沟通与协作模式 . 54 实施计划 . 5 风险评估及对策 . 5 工作流程 . 6 总体进度计划 . 6 项目控制计划 . 7 质量保证计划 . 7 进度控制计划 . 7 预算监控计划 . 8 配置管理计划 . 85 支持条件 . 8 内部支持 . 8 客户支持 . 8 外包（可选） . 86 预算 . 9 人员成本 . 9 设

2、备成本 . 9 其它经费预算 . 97 关键问题 . 98专题计划要点 . 9XXX软件项目计划书根据GB856788计算机软件产品开发文件编制指南中项目开发计划的要求，结合实际情况调整后的项目计划书内容如下：1 引言 背景主要说明项目的来历，一些需要项目团队成员知道的相关情况。主要有以下内容： 项目的名称经过与客户商定或经过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“XX系统”开发的项目名称是“XX系统开发”。 项目的委托单位如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方；如果是自行研发的软件产品，项目的委托单位就是本企业。 项目的用户（单

3、位）：软件或网络的使用单位，可以泛指某个用户群。注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。如海关的报关软 件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。 项目的任务提出者本企业内部提出需要完成此项目的人员，一般是领导或商务人员；注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。如果是内部开发项目，则两者的区别在于前者指人，后者指单位。 项目的主要承担部门有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门（也有的分为不同事业部）。项目的特点就是其矩阵式组织，一般一个项

4、目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要根据项目所涉及的范围确定本项目 的主要承担部门。 项目建设背景从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。 软件系统与其他系统的关系说明与本系统有关的其他系统，说明它们之间的相互依赖关系。这些系统可以是这个系统的基础性系统（一些数据、环境等必须依靠这 个系统才能运行），也可以是以这个系统为基础的系统，或者是两者兼而有之的关系、互相依赖的系统。例句：本系统中对外部办公部分如需要各个建设单位报送材 料的子系统应当挂

5、在市政府网站。 软件系统与机构的关系说明软件系统除了委托单位和使用单位，还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。 定义列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义，使它的含义和通用术语的惯用含义不一致。 参考资料列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位，必要时说明得到这些文件资料和标准的途径。本节与下一节的“标 准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”

6、，因为“参考”的不一定是“必须遵守”的。常用资料如：本项目的合同、标书、上级机关有关通知、经过审批的项目任务书；属于本项目的其他已经发表的文件；本文档中各处引用的文件、资料，包括所要用到的软件开发标准。 标准、条约和约定列出在本项目开发过程中必须遵守的标准、条约和约定。例如：相应的立项建议书、项目任务书、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得；“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。2 项目概述 项目

7、目标设定项目目标就是把项目要完成的工作用清晰的语言描述出来，让项目团队每一个成员都有明确的概念。注意，不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个模糊的目标，它还不够具体和明确。明确的项目目标应该指出了服务对象，所开发软件 系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。项目目标应当符合SMART原则：明确的陈述可以衡量的结果可以达成的目标现实的或者说是能和实际工作相结合可以跟踪的项目目标可以进行横向的分解也可以进行纵向的分解。横向分解一般按照系统的功能或按照建设单位的不同业务要求，如分解为第一

8、目标、第二目标等等；纵向的分解一般是指按照阶段，如分解为第一阶段目标、第二阶段目标等等，或近期目标、中期目标、远期目标等等。阶段目标一般应当说明目标实现的较为明确的时间。一 般要在说明了总目标的基础上再说明分解目标，可加上“为实现项目的总目标，必须实现以下三个阶段目标” 产品目标与范围根据项目输入（如合同、立项建议书、项目技术方案、标书等）说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。对项目成果（软件系统）范 围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。产品目标如“提高工作信息报送

9、反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强 度。 假设与约束对于项目必须遵守的各种约束（时间、人员、预算、设备等）进行说明。这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成。如：“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。假设与约束是针对比较明确会出现的情况，如果问题的出现具有

10、不确定性，则应该在风险分析中列出，分析其出现的可能性（概率）、造成的影响、应当采取的相应措施。 项目工作范围说明为实现项目的目标需要进行那些工作。在必要时，可描述与合作单位和用户的工作分工。注意产品范围与项目工作范围的不同含义。产品范围界定：软件系统产品本身范围的特征和功能范围。工作范围界定：为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。 应交付成果 需完成的软件列出需要完成的程序

11、的名称、所用的编程语言及存储程序的媒体形式。其中软件对象可能包括：源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。 需提交用户的文档列出需要移交给用户的每种文档的名称、内容要点及存储形式，如需求规格说明书、帮助手册等。此处需要移交用户的文档可参考合同中的规定。 须提交内部的文档可根据GB8567-88计算机软件产品开发文件编制指南附录O：“文件编制实施规定的实例（参考件）”结合各企业实际情况调整制定软件开发文档编 制裁减衡量因素表。根据因素表确定项目对应的项目衡量因素取值，以确定本项目应完成

12、的阶段成果。将不适用于本项目的内容裁减，以减少不必要的项目任务和资源。根据因素取值列出本项目应完成的阶段成果，说明本项目取值所在的区间，将其他因素值区间删除。篇二：软件项目计划书 模版XX20XX年9月8日 项目计划书 编写目的 定义（略） 标准、条约和约定（略） 2 项目概述项目目标产品目标与范围假设与约束 应当提供的服务 项目开发环境 项目验收方式与依据 3 项目团队组织 组织结构 人员分工 协作与沟通 内部协作 外部沟通4 实施计划 风险评估及对策 工作流程（略） 总体进度计划 项目监控（略） 质量控制计划（略） 进度监控计划（略） 预算监控计划（略） 配置管理计划（略） 5 支持条件（略） 内部支持（可选）（略） 客户支持（对项目而言）（略） 外包（可选）（略） 6 预算（可选） 人员成本 设备成本 其它经费预算（略） 项目合计经费预算（略）7 关键问题8专题计划要点（略）篇三：项目计划书模板文档编号：ICSSHS-QMS-PP-QT-03 密 级：公开 版 本 号： 文件类别：质量管理体系文件 发布状态：已发布项目计划书20XX年10月文档更改历史记录1