XXX系统

软件项目计划书

20##-10-12 10:10

目录

1 引言... 1

1.1 背景... 1

1.3 定义... 2

1.4 参考资料... 2

1.5 标准、条约和约定... 2

2 项目概述... 2

2.1 项目目标... 2

2.2 产品目标与范围... 3

2.3 假设与约束... 3

2.4 项目工作范围... 3

2.5 应交付成果... 3

2.5.1 需完成的软件... 3

2.5.2 需提交用户的文档... 3

2.5.3 须提交内部的文档... 3

2.5.4 应当提供的服务... 4

2.6 项目开发环境... 4

2.7 项目验收方式与依据... 4

3 项目团队组织... 4

3.1 组织结构... 4

3.2 人员分工... 4

3.3 协作与沟通... 5

3.3.1 项目团队内部协作... 5

3.3.2 项目接口人员... 5

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

4 实施计划... 5

4.1 风险评估及对策... 5

4.2 工作流程... 6

4.3 总体进度计划... 6

4.4 项目控制计划... 7

4.4.1 质量保证计划... 7

4.4.2 进度控制计划... 8

4.4.3 预算监控计划... 8

4.4.4 配置管理计划... 8

5 支持条件... 8

5.1 内部支持... 8

5.2 客户支持... 8

5.3 外包（可选）... 9

6 预算... 9

6.1 人员成本... 9

6.2 设备成本... 9

6.3 其它经费预算... 9

7 关键问题... 9

8专题计划要点... 9

XXX软件项目计划书

根据《GB8567－88计算机软件产品开发文件编制指南》中项目开发计划的要求，结合实际情况调整后的《项目计划书》内容如下：

1 引言

1.1 背景

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

(1)    项目的名称

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

(2)    项目的委托单位

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

(3)    项目的用户（单位）：

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

(4)    项目的任务提出者

本企业内部提出需要完成此项目的人员，一般是领导或商务人员；注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。如果是内部开发项目，则两者的区别在于前者指人，后者指单位。

(5)    项目的主要承担部门

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

(6)    项目建设背景

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

(7)    软件系统与其他系统的关系

说明与本系统有关的其他系统，说明它们之间的相互依赖关系。这些系统可以是这个系统的基础性系统（一些数据、环境等必须依靠这 个系统才能运行），也可以是以这个系统为基础的系统，或者是两者兼而有之的关系、互相依赖的系统。例句：本系统中对外部办公部分如需要各个建设单位报送材 料的子系统应当挂在市政府网站。

(8)    软件系统与机构的关系

说明软件系统除了委托单位和使用单位，还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。

1.3 定义

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

1.4 参考资料

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

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

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

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

1.5 标准、条约和约定

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

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

2 项目概述

2.1 项目目标

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

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

u  明确的陈述(Specific)

u  可以衡量的结果(Measurable)

u  可以达成的目标(Attainable)

u  现实的或者说是能和实际工作相结合(Realistic)

u  可以跟踪的(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、内部邮件、外部邮件、聊天室等等。其中邮件沟通应当说明主送人、抄送人，聊天室沟通方式应当约定时间周期。而协作模式主要说明在出现什么状况的时候各个角色应当（主动）采取什么措施，包括沟通，如何互相配合来共同 完成某项任务。定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等。

3.3.1 项目团队内部协作

本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。

3.3.2 项目接口人员

应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括：

(1)    负责本项目同用户的接口人员；

(2)    负责本项目同本企业各管理机构，如计划管理部门、合同管理部门、采购部门、质量管理部门、财务部门等的接口人员；

(3)    负责本项目同分包方的接口人员。

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

项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。

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

第二篇：软件项目计划书模板

 

目   录

1.      引言... 2

1.1             编写目的... 2

1.2             项目简介... 2

1.2.1       项目名称... 2

1.2.2         产品标识... 2

1.2.3         项目背景... 2

1.3             定义... 2

1.4             参考资料... 2

2.      项目概述... 2

2.1             工作内容... 2

2.2             交付项... 2

2.3             非交付项... 3

3.      项目组织和资源... 3

3.1             项目组织... 3

3.2             项目资源... 3

3.2.1         人力资源... 3

3.2.2         已有开发设施... 4

3.2.3         须获取的设施... 4

3.2.4         可复用软件资源... 4

4.      实施计划... 4

4.1             项目选用的生命周期... 4

4.2             项目开发过程阶段划分... 4

4.3             进度... 5

4.3.1         进度安排... 5

4.3.2         进度控制计划... 5

4.4             接口人员... 5

4.5             关键问题... 5

5.      专题计划要点... 6

5.1             基础技术积累计划... 6

5.2             测试计划... 6

5.3             培训计划... 7

5.4            系统安装计划... 7

1.    引言

1.1  编写目的

编写此计划的目的是为了合理安排组织成员，有效利用时间，以确保项目进度，预见项目风险等活动。使项目严格按照网站开发流程进行，遵循正规的顺序开展。同时，项目开发成员通过此计划书明确项目目标和各自职责。它说明网站的开发方法，是一种计划，以指导工作之用。

1.2  项目简介

1.2.1    项目名称

         项目编号：0728—2005

项目名称：手机“末”班车网站

1.2.2        产品标识

产品名称：手机“末”班车
英文名称：
版本号：1.0

1.2.3        项目背景

1.3  定义

DW：Dreamweaver

FW：Fireworks

PH：Photoshop

1.4  参考资料

《Photoshop CS经典详解100例》        李小军  编著          人民邮电出版社

《ASP动态网页设计》                   汪晓平  钟军 编著     人民邮电出版社

《Flash 基础教程》                      刘小灵  编著          人民邮电出版社

《数据库设计》                          王建    编著          清华大学出版社

2.    项目概述

手机”末”班车是一个关于手机的网站，主要介绍各种品牌的手机，并向广大用户提供交流的平台。

2.1  工作内容

项目名称定为：手机”末”班车

本项目分为：前台管理和后台管理

2.2  交付项

2.3  非交付项

《项目开发计划书》

《创意设计概要说明书》

3.    项目组织和资源

3.1  项目组织

3.2  项目资源

3.2.1        人力资源

说明参与项目的总人数和人员结构，人员结构可用下表从职责和技术水平等方面进行说明。

3.2.2        已有开发设施

开发地点：陕西国防学院第五机房

使用设备：电脑   台

3.2.3        须获取的设施

无

3.2.4        可复用软件资源

无

4.    实施计划

4.1  项目选用的生命周期

本项目采用的是瀑布式模型。此模型的本质是每个阶段的活动只做一次。从上一阶段向下一阶段逐级过度，最终得到所要开发的产品

4.2  项目开发过程阶段划分

4.3  进度

4.3.1       进度安排

                

4.3.2        进度控制计划

        第一阶段完成项目计划，ASP运行环境的配置等相关主要文档的编写。每天由各组组长汇报工作情况和进度，为了项目成功完成，由各组组员在组长的带领下进行充分的交流沟通。第二阶段为项目实施测试阶段，项目实施前，所有的项目成员开会，讨论编成中的具体问题，规定统一的

编程标准，如命名规范等。方便集成之后各小组分组讨论本小组需要解决的问题。（不懂之处及时提出，便于请教老师）第三阶段，各成员保证自己功能模块的实现，集成之后，分配测试人员进行测试。

4.4  接口人员

主要接口人员：吴瑶（项目经理）

对项目成员的接口人员：各组组长

4.5  关键问题

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

并根据项目情况，对项目风险进行排序，在下表中列出项目的前5个风险，并给出解决方案。

5.    专题计划要点

5.1  基础技术积累计划

1.    BBS 论坛

2.  用户登录系统

3.  网站架构设计

5.2  测试计划

单元测试和部分集成测试

项目组的测试人员结合详细的计划,对单元模块开始进行测试.。通过对设计文档的深入理解，从模块界面开始，到模块内部对数据库内书库的操作，以及代码阿德规范进行详细的单元测试。

集成测试

系统完成了模拟数据环境的试运行后，测试人员将认真细致的集成测试。

系统测试

在项目小组完成了全部的开发工作后，测试小组将对软件进行全面的系统测试，使系统逐步完善和成熟。

测试阶段分解：

详细测试活动写入《测试计划》

5.3  培训计划

当项目组成员因为技能不足或别业务不熟时，需要安排对项目组成员的培训；

5.4  系统安装计划