第一篇：软件开发项目计划书格式
正文
一、项目计划书格式
根据《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 标准、条约和约定
列出在本项目开发过程中必须遵守的标准、条约和约定。例如：相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。
“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得；“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。
<项目名称>
软件开发计划
版本
<1.0>
[注：以下提供的模板用于
Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=正文）。]
修订历史记录
日期
版本
说明
作者
<日/月/年>
<详细信息>
<姓名>
目录
1.简介
1.1 目的 1.2 范围
1.3 定义、首字母缩写词和缩略语
1.4 引用
1.5 概述
2.项目概述
2.1 项目的目的、规模和目标
2.2 假设与约束
2.3 项目的可交付工件
2.4 软件开发计划的演进
3.项目组织
3.1 组织结构
3.2 外部接口
3.3 角色与职责
4.管理流程
4.1 项目估计
4.2 项目计划
4.2.1 阶段计划
4.2.2 迭代目标
4.2.3 发布版
4.2.4 项目时间表
4.2.5 项目资源分配
4.2.5.1 人员配备计划
4.2.5.2 资源获取计划
4.2.5.3 培训计划
4.2.6 预算
4.3 迭代计划
4.4 项目监测与控制
4.4.1 需求管理计划
4.4.2 进度控制计划
4.4.3 预算控制计划
4.4.4 质量控制计划
4.4.5 报告计划
4.4.6 评测计划
4.5 风险管理计划
4.6 收尾计划
5.技术流程计划
5.1 开发案例
5.2 方法、工具和技术
5.3 基础设施计划
5.4 产品验收计划
6.支持流程计划
6.1 配置管理计划
6.2 评估计划
6.3 文档计划
6.4 质量保证计划
6.5 问题解决计划
6.6 分包商管理计划
6.7 流程改进计划
7.其他计划
8.附录
9.索引
软件开发计划
1.简介
[软件开发计划的简介应提供整个文档的概述。它应包括此软件开发计划的目的、范围、定义、首字母缩写词、缩略语、引用和概述。]
1.1
目的[阐明此软件开发计划的目的。]
1.2
范围
[简要说明此软件开发计划的范围：它的相关项目，以及受到此文档影响的任何其他事物。]
1.3
定义、首字母缩写词和缩略语
[本小节应提供正确理解此软件开发计划所需的全部术语、首字母缩写词和缩略语的定义。
这些信息可以通过引用项目词汇表来提供。]
1.4
引用
[本小节应完整地列出此软件开发计划中其他部分所引用的所有文档。
每个文档应标有标题、报告号（如果适用）、日期和发布组织。列出可从中获取这些引用的来源。这些信息可以通过引用附录或其他文档来提供。
对于软件开发计划，所引用工件的列表中应包括：
_
迭代计划
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
需求管理计划
评测计划
风险管理计划
开发案例
业务建模指南
用户界面指南
用例建模指南
设计指南
编程指南
测试指南
手册风格指南
基础设施计划
产品验收计划
配置管理计划
评估计划（仅当该计划是单独的计划时，但它通常是文档计划
质量保证计划
问题解决计划
SDP 的6.2 节）
_
分包商管理计划
_
流程改进计划]
1.5
概述
[本小节应说明此软件开发计划中其他部分所包含的内容，并解释文档的组织方式。]
2.项目概述
2.1
项目的目的、规模和目标
[简要说明此项目的目的与目标，以及此项目将要交付的可交付工件。]
2.2
假设与约束
[列出此计划所依据的假设和对项目的所有约束（如预算、人员、设备、时间表等）。]
2.3
项目的可交付工件
[以表格的形式列出将在项目中创建的工件，包括目标交付日期。]
2.4
软件开发计划的演进
[以表格的形式列出软件开发计划的提议版本，以及在计划外修订与重新发行此计划需符合的标准。]
3.项目组织
3.1
组织结构
[说明项目团队（包括管理人员和其他复审委员会）的组织结构。]
3.2
外部接口
[说明项目与外部组织联系的方式。
对于每个外部组织，应确定其内部和外部联系人的姓名。]
3.3
角色与职责
[确定将负责各个核心工作流程、工作流程明细和支持流程的项目组织单位。]
4.管理流程
4.1
项目估计
[提供所估计的项目成本与进度、这些估计所依据的基础，以及项目中将重新进行估计的时间点和情况。]
4.2
项目计划
4.2.1
阶段计划
[包括以下内容：
_
工作细分结构
(WBS)
_
显示项目各阶段或迭代的时间分配情况的时间线或甘特图
_
确定主要里程碑及其成就标准
确定所有重要的发布点和演示版]
4.2.2
迭代目标
[列出每次迭代将要实现的目标。]
4.2.3
发布版
[简要说明每个软件发布版，并指出它是否是演示版、Beta 版等。]
4.2.4
项目时间表
[用图表显示完成迭代与阶段、发布点、演示版及其他里程碑的目标日期。]
4.2.5
项目资源分配
4.2.5.1
人员配备计划
[在此处确定所需人员的数目和类型，以及项目阶段或迭代需要的任何特殊技能或经验。]
4.2.5.2
资源获取计划
[说明您将如何发现并得到项目所需的人员。]
4.2.5.3
培训计划
[列出项目团队成员需要的所有特殊培训，以及完成这些培训的目标日期。]
4.2.6
预算
[按照
WBS 和阶段计划分配成本。]
4.3
迭代计划
[通过引用的方式将各项迭代计划附加在本节中。]
4.4
项目监测与控制
4.4.1
需求管理计划
[通过引用附加。]
4.4.2
进度控制计划
[说明以何种方法按照所计划的时间表监控项目进展，以及如何在需要时执行纠正操作。]
4.4.3
预算控制计划
[说明以何种方法按照项目预算监控项目开支，以及如何在需要时执行纠正操作。]
4.4.4
质量控制计划
[说明将在何时、以何种方法来控制项目可交付工件的质量，以及如何在需要时执行纠正操作。]
4.4.5
报告计划
[说明将生成的内部和外部报告，以及报告发布的频率和范围。]
4.4.6
评测计划
[通过引用附加。]
4.5
风险管理计划
[通过引用附加。]
4.6
收尾计划
[说明有序地完成项目所要执行的活动，其中包括人员重新分配、项目材料存档、事后检查汇报及报告等。]
5.技术流程计划
5.1
开发案例
[通过引用附加。]
5.2
方法、工具和技术
[以引用的方式列出所记录的项目技术标准：
_
业务建模指南
_
用户界面指南
_
用例建模指南
_
设计指南
_
编程指南
_
测试指南
_
手册风格指南]
5.3
基础设施计划
[通过引用附加。]
5.4
产品验收计划
[通过引用附加。]
6.支持流程计划
6.1
配置管理计划
[通过引用附加。]
6.2
评估计划
[作为软件开发计划的一部分，本小节说明项目的产品评估计划，并介绍评估所使用的技术、标准、指标和过程；评估将包括走查、检查和复审。请注意，评估计划是对测试计划的补充，但软件开发计划中并不包括测试计划。]
6.3
文档计划
[通过引用附加。]
6.4
质量保证计划
[通过引用附加。]
6.5
问题解决计划
[通过引用附加。]
6.6
分包商管理计划
[通过引用附加。]
6.7
流程改进计划
[通过引用附加。]
7.其他计划
[列出合同或法规所要求的其他计划。]
8.附录
[供
SDP 读者使用的其他材料。]
9.索引
第二篇：软件开发项目商业计划书
软件开发项目商业计划书
目前，中国软件产业的快速增长已成为拉动我国经济增长的关键点之一。工信部部长李毅中表示，IT行业为我国经济增长做出了十分重要的贡献，软件在 IT行业发展中举足轻重，成为推动经济增长和创造经济机会的催化剂。因此发展和扶持软件产业，是一个国家提高国家竞争力的重要途径，也是参与全球化竞争所必须占领的战略制高点。而《中国软件产业发展战略研究报告》也指出全球软件产业在发展过程中的网络化已成为第一发展趋势。
从2000年到2010年这十年间，中国软件产业发展较快，产业规模增速迅猛。2009年软件服务业销售收入同比增长20%，是所有行业里面唯一增长20%以上的产业。2007年软件收入5834.3亿。2007年的前五年，平均的增速接近40%，07年的速度与五年前相比增加了五倍多。企业数14373家，平均增速是25%，07年较02年增长了3倍。从业人员达到152.9万。到了2009年，我国软件产业完成软件业务收入9513亿元，同比增长25.6%，增速比上年低4.2个百分点，是2000年的16倍；软件出口196亿美元，是2000年的49倍。面对金融危机，虽然软件产业的增长速度有所放缓，但总体增长水平依然强劲。
第一部分 摘要
一、项目背景
二、项目简介
三、项目竞争优势
四、融资与财务说明
第二部分软件开发行业市场分析
一、软件开发行业发展现状
二、目标市场分析
三、竞争对手分析
四、小结
第三部分 公司介绍
一、公司基本情况
二、组织架构
三、管理团队介绍
第四部分 产品介绍
一、产品介绍
二、产品的新颖性/先进性/独特性
三、产品的竞争优势
第五部分 研究与开发
一、已有的技术成果及技术水平
二、研发能力
三、研发规划
第六部分 产品制造
一、生产方式
二、生产设备
三、成本控制
第七部分 市场营销
一、企业发展规划
二、营销战略
三、市场推广方式
第八部分 融资说明
一、资金需求及使用规划
（一）项目总投资
（二）固定资产投资（土地费用、土建工程、淀粉糖装饰、设备、预备费、工程建设其他费用、建设期利息）
（三）流动资金
二、资金筹集方式
三、投资者权利
四、资金退出方式
第九部分 财务分析与预测
一、基本财务数据假设
二、销售收入预测与成本费用估算
三、盈利能力分析
1、损益和利润分配表
2、现金流量表
3、计算相关财务指标（投资利润率、投资利税率、财务内部收益率、财务净现值、投资回收期）
四、敏感性分析
五、盈亏平衡分析
六、财务评价结论
第十部分 风险分析
一、风险因素
二、风险控制措施
第三篇：软件开发计划书
软件开发计划书模板
默认分类2009-06-30 14:21阅读258评论0
字号： 大中小
项目名称：图书管理系统
小组编号: 15
版本号: v1.0
评审日期：2006-11-19
目录
1.概述 3
1.1 目的 3
1.2 项目范围 3
1.3 术语定义 3
2.人员分工 3
2.1 基本信息 3
2.2 假设和约束 3
2.3 关键里程碑及其提交产品 3
3.项目计划 4
3.1 项目开发过程选择 4
3.2 项目估算 4
3.2.1 工作量估算 4
3.2.2 进度估算 4
3.3 开发环境 4
3.4 小组评审 4
4.项目跟踪 5
4.1 任务跟踪 5
4.2 问题跟踪 5
4.3 项目进展报告 5
5.参考资料 5
软件开发计划书
1.概述
图书管理系统是指应用电子计算机和网络通信设备，为图书馆管理人员能使日常办公实现自支化，同时也为本校师生提供方便的图书借阅环境,并能满足所有授权用户对信息的各种功能需求的计算机应用
软件系统。
1.1 目的通过书写开发计划文档，开发小组可以有条不紊地进行开发活动。这样，小组在开发的过程中有章
可循，否则会造成混乱而且低的工作效率。
1.2 项目范围
本项目负责项目生命周期模型的需求分析，系统设计、原型编码阶段。
2.角色与人员分工
2.1 基本信息
个人详细的任务分工在后面进度计划中描述，这里仅仅说明成员在本项目中担任的角色
人员 角色 职责
李晓虎 项目经理 管理负责整个项目，协同开发
林君宇 系统分析员 进行系统分析与设计
兰皓 程序员 编程实现原型
连九研 程序员 编程实现原型
蒋海倩 测试,配置 测试，配置管理
2.2 假设和约束
假设：（1）需求比较稳定；
（2）项目人员按时到位；
（3）项目中遇到的所有新技术能顺利得到解决；
约束：软件需求文档中描述的需求都能实现，保证项目工期
2.3 关键里程碑及其提交产品
里程碑名称 产品名称 提交日期 责任人
项目计划 《小组项目开发计划》 2006.11.20 李晓虎
业务需求描述 《 业务需求描述基线》 2006.11.21 李晓虎
对象系统需求规格基线 《系统需求规格说明书》 2006.11.29 李晓虎
对象系统设计规格基线 《系统设计规格说明书》 2006.12.5 李晓虎
结构化系统需求基线 《结构化需求规格说明书》 2006.12.17 李晓虎
结构化系统设计基线 《结构化设计规格说明书》 2006.12.22 李晓虎
小组项目总结 《小组项目总结报告》 2006.12.29 李晓虎
程序包及程序框架文档 程序包以及程序框架文档 2006.12.29 李晓虎
3.项目计划
3.1 项目开发过程选择
小组开发所用的开发过程
1）面向对象开发方法中的迭代开发。
2）结构化开发方法中的瀑布模型。
3.2 项目估算
3.1.1 工作量估算
Stage Percentage of Effort Effort(Person-Hours)
需求获取 4 8
需求分析 20 20
设计 40 30
实现（含编程，测试）20 20
项目管理 8 10
其它 4 8
总计 100 96
3.1.2 进度估算
Microsoft Project Gantt Chart：
3.2 开发环境
硬件环境 软件环境
PC 等 JBuilder2006, Oracle, Weblogic 等
3.3 小组评审
小组自行定义的内部评审点
评审关键点 评审内容 评审安排
开发计划 项目开发计划 2006.11.20 上午 九教北304
业务需求描述 《 业务需求描述基线》 2006.11.21 上午 九教北304
对象系统需求规格基线 《系统需求规格说明书》 2006.11.29 上午 九教北304
对象系统设计规格基线 《系统设计规格说明书》 2006.12.5 上午 九教北304
结构化系统需求基线 《结构化需求规格说明书》 2006.12.17 上午 九教北304
结构化系统设计基线 《结构化设计规格说明书》 2006.12.22 上午 九教北304
小组项目总结 《小组项目总结报告》 2006.12.28 上午 九教北304
4.项目跟踪
4.1 任务跟踪
小组每周开一次例会来总结工作，时间是每周六上午；
每个成员每周要交一个《个人工作进展报告》。
4.2 问题跟踪
小组成员将问题申报给组长，组长汇总并组织开会来讨论解决，同时形成会议记录。组长跟踪问题
使其最终得到解决。
.4.3 项目进展报告
小组长填写关键里程碑处小组工作汇报的安排，关键里程碑是指课程计划中定义的关键评审点，需
要评审时做小组工作汇报
汇报人 内容 文档负责人
兰皓 业务需求描述 林君宇
兰皓 系统需求说明 李晓虎
兰皓 系统设计说明 李晓虎
兰皓 结构化需求规格说明 李晓虎
兰皓 结构化设计规格说明 李晓虎
5.参考资料
1.《系统分析与设计》.John W.Satzinger 等著.机械工业出版社
第四篇：软件开发项目合同
软件开发合同书
甲方：
乙方： 深圳市凯路网络技术有限公司
鉴于甲方委托乙方软件开发，帮助甲方树立企业形象，扩大宣传，拓宽销售渠道，为明确双方责任，根据中国相关法律经双方协商，签订此合同，以期双方共同遵守。
甲方在此委托乙方进行_软件的开发，为明确双方责任，经友好协商，双方达成以下协议：
第一条：项目的内容、价款、开发进度、交付方式由“合同附录”载明。
第二条：甲方的权利和义务
１、提供专人与乙方联络。
２、提供所有需要开发需求的资料给乙方。
３、按照“合同附录”的要求，及时支付费用。
４、甲方将在著作版权法的范围内使用本合同标的及相关作品、程序、文件源码，不得将其复
制、传播、出售或许可给其它第三方。
５、甲方对合同中的系统软件、页面设计，程序开发享有排它的使用权。
第三条：乙方的权利和义务
１、提供专人与甲方联络。
２、按照“合同附录”的要求，使用甲方资料，进行软件的开发。
３、在“合同附录”要求的期限内，完成软件的开发，并通知甲方进行验收。
４、在验收期内甲方要求下，对不合格地方进行修改。
５、本合同标的及相关作品、程序、文件源码的版权属于乙方。(版权归属应该为嘉源公司)
第四条：验收
１、验收标准有以下几条：
（a）、甲方可以通过任何上网的计算机访问这个软件
（b）、软件系统中不存在任何错误或系统运行错误，图片链接错误（以甲方提供的开发需求为准）。（功能符合开发需求，开发需求需要清晰界定功能）
（c）、网络程序运行正常。
２、验收期为一周。
第五条：违约责任
1、任何一方有证据表明对方已经、正在或将要违约，可以中止履行本合同，但应及时通知对方。若对方继续不履行、履行不当或者违反本合同，该方可以解除本合同并要求对方赔偿损失。
2、因不可抗力而无法承担责任的一方，应在不可抗力发生的3天内，及时通知另一方。
3、一方因不可抗力确实无法承担责任，而造成损失的，不付赔偿责任。本合同所称不可抗力是指不能预见、不能克服并不能避免且对一方当事人造成重大影响的客观事件，包括但不限于自然灾害如洪水、地震、火灾和风暴等以及社会事件如战争、**、政府行为等。
第六条：保密条款
双方应严格保守在合作过程中所了解的对方的商业及技术机密，否则应对因此造成的损失进行赔偿。
第七条：其它
1、如果本合同任何条款根据现行法律被确定为无效或无法实施，本合同的其它所有条款将继续
有效。此种情况下，双方将以有效的约定替换该约定，且该有效约定应尽可能接近原约定和本合同相应的精神和宗旨。
2、“合同附录”规定的有效期满，本合同自动失效。届时双方若愿意继续合作，应重新订立合同。
3、本合同经双方授权代表签字并盖章，自签订日起生效。
4、本合同一式两份，双方当事人各执一份，具有同等法律效力。
第八条：以上条款如有未尽事宜，经甲、乙双方协商后加以补充。
5、付款方式：项目总费用为八千元(人民币),在签定合同当日内预付总项目费用的百分之三十，在软件完成后交付总项目费用的百分之四十，测试用两个月没问题后再付剩下的总项目费用的百分之三十。
甲方：乙方：
甲方代表：乙方代表：
电话：电话：
电子信箱：电子信箱：
日期：日期：
合同附录
<
关于购买OA系统信息:
1在线邮局（增加部门群和全公司两个功能）
新邮件发邮件发件箱收邮件废邮件
2个人文件夹
私人文件夹公共文件夹管理员管理
3办公用品管理
办公用品种类领取办公用品审核领用表发放办公用品资料管理
4人事管理
企业员工资料企业员工统计 企业部门员工 员工调职管理员工培训管理员工考勤管理 5权限设置
部门管理权限职位权限管理用户帐号设置用户权限设置系统维护设置 6系统帮助
系统帮助信息管理帮助类别输入帮助信息
7常用资料
公共信息查询常用公共网址手机与IP地址查用邮编查询万年日历查询世界时间查询常用信息查询常用网址查询酒店饭店查询常用邮编查询列车资料查询航班资料查询单位换算查询媒体资料查询
8个人办公(能否增加部门工作计划)
个人工作计划部门工作计划员工工作任务
9通讯助理
个人通讯录内部通讯录外部通讯录手机短消息
10通知管理
通知管理发送通知已发通知已收通知我的通知（做到按部门发送）11通告管理(发布通告)
发布通告管理通告浏览通告
12考勤管理+值班管理(能否放在一起,算一个模块)
设置考勤时间开始考勤今日考勤统计日考勤统计月考勤统计值班管理值班记录
第五篇：软件开发项目管理（范文）
管理目标
1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。
2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。
3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。
执行概述
1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。
2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。
3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。
4、解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨部门协调等几个方面。
5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。
6、风险识别、风险控制以及风险的预案。
项目管理
1、需求阶段
对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求讨论，明确项目的目标、价值。确定项目范围、功能及优先级。
组建项目团队，特别要搞清楚项目的关键人。项目启动会议，相关的关系人都必须参加。
2、设计阶段
根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。
设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。
该阶段交付成果需要进行评审。
3、执行阶段(开发和测试)准备开发环境、测试环境。跟踪，推动项目按计划进行。
项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。按里程碑对阶段成果进行评估，以确保该阶段完成的质量。代码审核，包括CS审核、SQL审核、WEB审核等。对需求变更进行控制管理。
测试阶段BUG响应及改进、收集反馈意见。对项目风险进行管理。
4、发布阶段
包括制定项目发布计划，用户培训，发布上线。
5、试运行阶段
数据监控(日志、服务器状态)，根据监控出现的问题，及时进行处理，改进性能问题，特定情况执行补丁升级。
6、收尾阶段
产品交付，项目总结会。
常见问题
1、开发时间的估算
制定项目计划时，需要估算每个任务所需的时间，其中主要是开发任务中模块的分配和时间估算，在公司现有的技术框架下，开发人员主要的工作是投入在具体的业务逻辑实现上。通常单个模块开发时间取决于以下因素：
1、负责模块的业务逻辑的复杂程度。
2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度)。
3、模块技术实现上是否存在难点，所谓的技术难点定义是：在现有系统中还未实现的、开发人员自身未没接触过的技术。对于这样的难点，开发者没有相关的代码可以参考，自己也没有经验，所以需要投入学习时间用于研究解决。
模块分配和开发时间估算的步骤：
1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。
2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下：
A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。
B、技术难度较大的模块由技术水平比较高的人负责。C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。
3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。在此过程中应
4、对开发人员估算的时间进行确认。在确认过程中作为，项目管理者将预估时间和开与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。发人员估算时间进行比较。那些差异较大的，与人员探讨其中的缘由。对于时间周期比较长的任务，将任务拆分为更小的子任务，每个任务的完成时间为8-24工时，消除时间周期较长的任务，避免不确定性影响项目的进度。
2、CodeReview CodeReview是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工；关于CodeReview执行，首先应有编码规范和代码审查规范。通过这两个文档来规范开发人员的代码实现，代码编写者必须要严格按照规范来进行；代码审核者根据这些标准来CodeReview代码，同时在CodeReview过程中需要不断完善该文档。
CodeReview一般可按以下步骤实施：
1、检查开发者的代码实现是否遵循了编码规范。
2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。
3、代码编写者和代码审核者坐在一起，由代码编写者按照UseCase依次讲解自己负责的代码和相关逻辑，代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug，对这些bug记录在案。
4、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要检查Bug。同时全面兼顾，确保代码整体上结构优良；审核完毕后，代码审核者编写“代码审核报告”记录发现的问题及修改建议，提交给相关人员。
5、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。
6、代码编写者bugfixed完毕之后给出反馈。
7、代码审核者把CodeReview中发现的有价值的问题更新到“代码审核规范”的文档中，对于特别值得提醒的问题可群发email给所有技术人员。
3、需求变更管理
需求变更管理也是项目管理中最重要的一个环节，对需求变更管理的有效性将直接影响对待需求变更的正确态度：
1、需求变更是不可避免的。
2、需求变更要必须被管理。
3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。需求变更管理的目标：
1、相关的干系人必须清楚地了解发生的变更。
2、变更处于有效的管理中。
3、尽量降低变更带来的风险。
通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。需求变更流程：
1、确定需求的基准线。将以UserCase作为需求基准线，在UserCase确认之后的任项目的成功与否。何需求改变，都需要走需求变更流程。
2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。
3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。项目管理者对项目的成功与否负有主要的责任。需求变更的决策应由项目管理者做出。
4、需求变更确认后，由专人将生成需求变更单记录下来，通知给项目中所有关系人。
5、确定变更的负责人。承担需求变更的具体工作，比如基线控制，对需求变更的记录，并通知相关人员。
6、相关人员接收到确认的需求变更后，需求分析人员修改需求说明书和UserCase的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。
7、按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现的问题及时沟通和处理。
8、需求冻结。项目越到后期，需求变更对项目的影响就越大，所以在一定时候要进入需求冻结阶段，不再接收新需求或需求的变更。
4、风险管理
影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，常见风险如下：
1、目标以及需求不明确
为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有正式的业务需求文档，在没有明确的需求范围的情况下，有时为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。
在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。
2、项目目标扩大以及需求变更
在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。
前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户)，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。
3、代码质量风险
质量风险主要指开发代码的质量。在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响很大。开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重要。
往往有这样一种情况，每个团队成员按照项目计划报告进度都是100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题。这需要在项目实施过程中采取有效的措施来规避风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题；管理评审，通过组织级的质量审计看产品以及实施过程是否满足质量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要求的代码，走查通常能够发现50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。
4、人员技能和资源的不足
项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见，一个熟练的技术人员完成同样一个任务需要3天，但一个新手可能就需要7-10天。项目管理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训，以保证项目的顺利实施。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。
5、缺乏良好的团队协作
软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。
6、项目会议
组织会议是项目执行过程中一项非常重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，不成功的会议会对项目本身造成了不好的影响。
不成功的会议通常表现为如下形式：
1、会议氛围不好，参与者发言不踊跃；
2、会议讨论常常偏离主题；
3、会议没有取得预期的结果；
4、会议时间常常一拖再拖。
这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：
1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能取得成功，这是会议成功的充分条件。
2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只是一个发表想法的人，他不用对会议的成功承担责任。
3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。组织会议的十一条最佳实践：
1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。
2、提前发出会议议程，以便会议参与者知道他们来做什么。
3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确保必要人物都在的情况下一次会议参与者越少效果越好。
4、提前预约参与者的时间，以确保他们能按时到场。
5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说： A、再一次强调会议的目标，我们来做什么。
B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。
C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人的讲话，等别人说完你再说等等。
6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。
7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。
8、会议要有结论。我们常在会议上听到有人说：“大家讨论了这么半天，结论呢？”。没有结论的会议是没有意义的。
9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。
10、会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这一点。
11、按时结束的会议会受到所有人的欢迎。
点击咨询 