物流信息服务平台开发计划方案样本.doc

n 目前文档修改密码：8362839

物流信息服务平台
开发计划书
编号：ISS- IM-VOLVO-001 -SDP
版本:1.0

作者：
张桐
日期：
-11-6
审批：
刘平
日期：
-11-8

变更统计
日期
版本
变更说明
作者
-11-6
1.0
创建
张桐

填表说明
在需求分析阶段开始着手准备开发计划，当需求分析结束后，依据项目估算和需求分析结果，完成软件开发计划书，评审后纳入到基线库。制订开发计划过程是不停正确细化，逐步完善丰富过程。开发计划是项目经理管理和跟踪依据， 又起到指导项目组日常工作作用。当实际情况和计划偏离到一定程度时，应修正开发计划。
软件开发应根据开发计划制订内容进行。开发计划是项目跟踪依据，经过和实际开发进展情况作比较分析，项目经理能够立即了解项目开发状态。项目组中每个组员全部应该明确地知道项目计划内容，而且对所分配任务承诺签字，确保计划落实实施。
1 项目总览
1.1 基础信息

项目名称
沃尔沃物流信息服务平台
项目编号
IM-VOLVO-001
用户名称
沃尔沃（中国）投资
用户代表
周伟
项目经理
张桐
质量确保员
杨海舰
配置管理员
刘扬
工作量估算
16个人月
项目开始日期
-11-02
项目结束日期
-02-08

1.2 项目关键联络人

姓名
电话号码
传真号码
E-Mail
用户
蒋宇

项目经理
张桐

84480686

1.3 假设和约束
本项目计划能够顺利实施条件是基于以下假设成立：
n 企业能够满足计划中对多种项目资源需求；
n 项目实施过程中能得到用户有效支持和配合；
n 对于项目组员培训能够根据培训计划进行；
n 项目开发、实施过程中人员变动不超出80%。
1.4 里程碑提交产品

里程碑
提交产品
时间
责任人
需求
项目定义软件过程.xls
.11.6
张桐

软件开发计划
.11.7
张桐

软件测试计划
.11.7
刘杨

配置管理计划
.11.7
刘杨

质量确保计划
.11.7
杨海舰

量化过程管理计划
.11.7
张桐

质量管理计划
.11.7
张桐

需求规格说明书
.11.5
张桐

需求跟踪据矩阵
.11.5
张桐
设计
架构设计（部门级）
.11.15
张桐

数据库设计
.11.15
李兵

概要设计
.11.15
张桐
开发/单元、集成测试
代码
.12.29
张桐

测试用例
.11.21
刘扬

集成测试汇报
.12.29
刘扬

Build说明
.12.29
张桐
系统测试
测试总结汇报
.1.4
刘扬

用户手册
.1.10
刘扬
实施
实施计划
.1.11
张桐

培训计划
.1.11
张桐

软硬件安装布署计划书
.1.11
徐光

应用程序包
.2.7
张桐

应用系统布署说明
.2.7
张桐

系统验收
.2.7
张桐
1.5 公布提交产品
提交产品
时间
是否提交用户
责任人
需求规格说明书
.02.07
是
张桐
架构设计
.02.07
否
张桐
概要设计
.02.07
否
张桐
数据库设计
.02.07
是
李兵
测试用例
.02.07
是
刘扬
应用程序包
.02.07
是
张桐
应用程序源码
.02.07
是
张桐
软硬件安装布署计划书
.02.07
是
徐光
应用系统布署说明
.02.07
是
张桐
公布清单
.02.07
否
张桐
用户手册
.02.07
是
刘扬
验收汇报
.02.07
否
张桐

2 项目计划
2.1 项目生命周期
n 项目阶段定义及各阶段关键产品
项目阶段
关键产品
需求
项目章程，项目级过程裁剪，软件开发计划，质量管理计划，量化过程管理计划，软件测试计划，配置管理计划，质量确保计划，需求规格说明书，系统原型
设计
架构设计（部门级），数据库设计，概要设计，
开发/单元/集成测试
源代码，测试用例，单元测试汇报
系统测试
测试总结汇报，用户手册
实施
验收汇报，实施计划，培训计划，软硬件安装布署计划书，应用系统布署说明，系统验收，应用程序包

n 开发模型
为确保项目进度根据计划进行本项目采取瀑布式开发模型。经过设置里程碑明确每阶段任务和目标，经过阶段评审，将开发过程纳入正确轨道，严格计划性确保软件产品按时交付。
示例图以下：
需求分析
需求调研
设计
编码
测试
运行维护

2.2 WBS 表
参见《开发计划》（Microsoft Project文档）。

2.3 规模估算
具体估算方法可参见《软件项目估算过程》，估算过程应该统计在《项目估算表》中，此处只描述估算结果。
工作产品
估算因子
分类
个数
累计规模
（换算比重后个数）
需求规格说明书
功效点
复杂：交互操作大于等于 6
13
26
概要设计
业务逻辑类
复杂
中等
简单
8
10
20
51
DB
Table
View
Procedure
Trigger
Constraint
35
2
0
0
0
35
2
编码

操作 (Action)
反应（Response）
报表（Report）
接口（Interface）
69
164
2
3
558
测试
测试用例
复杂：交互操作大于等于 6
15
30

2.4 工作量估算
具体估算方法可参见《软件项目估算过程》，估算过程应该统计在《项目估算表》中，此处只描述估算结果。
项目阶段
项目工作量百分比分布(%)
工作量
（人日）
需求
8.5%
30.7
设计
10.2%
37.0
编码/单元/集成
50.9%
184.8
系统测试
8.1%
29.5
实施
22.3%
81.0
项目开发总工作量
100.0%
363.0

2.5 成本估算
依据企业情况，项目成本关键是人员工资，所以工作量估算基础上反应了项目标成本。
阶段
计划人力成本
人员数量
人员百分比
需求
21195.00
8
80.0%
设计
30220.50
9
90.0%
开发/单元、集成
110499.50
9
90.0%
系统测试
20353.13
10
100.0%
实施
57428.88
10
100.0%
累计（元）
239697.00
10

2.6 进度安排
参见《开发计划》（Microsoft Project文档）。
2.7 关键计算机资源估算

1） 用户运行环境所需关键计算机资源
本项目标测试环境和系统上线环境相同。
用途
服务器型号
必需硬件配置
必需软件配置
数量
申报理由说明
Application server
DELL2850/至强
2.8G*2颗/4G内存/146G*2硬盘
Windows
1
此配置是所开发软件系统要求最基础配置，而且满足用户对系统性能要求。
DB Server

2）项目开发环境所需关键计算机资源：
用途
服务器型号
必需硬件配置
必需软件配置
数量
申报理由说明
Application server
DELL2850/至强
2.8G*2颗/4G内存/146G*2硬盘
Windows
1
满足最基础开发要求。
DB Server
2.8 项目评审
描述按计划需要评审工作产品，和采取评审方法和参与评审人员。评审方法是同行评审，评审过程参见《软件项目评审过程》。

工作产品
评审方法
评审参与人员
评审材料发放时间(提前X天)
需求规格说明书
同行评审
杨立东，张桐，李兵，伍箭，刘扬，杨海舰，王松涛，彭俊林，李进
1
开发计划
同行评审
刘平，张桐，李兵，伍箭，刘扬，杨海舰
1
量化过程管理计划
同行评审
刘平，张桐，李兵，伍箭，刘扬，杨海舰
1
质量管理计划
同行评审
刘平，张桐，李兵，伍箭，刘扬，杨海舰
1
配置管理计划
同行评审
刘平，张桐，李兵，伍箭，刘扬，杨海舰
1
质量确保计划
同行评审
刘平，张桐，李兵，伍箭，刘扬，杨海舰
1
系统测试计划
同行评审
刘平，张桐，李兵，伍箭，刘扬，杨海舰
1
概要设计
同行评审
杨立东，张桐，李兵，伍箭，刘扬，杨海舰，王松涛，彭俊林，李进
1
数据库设计
同行评审
项目经理，设计人员，开发人员，测试人员，QA人员
1
代码
走查
项目经理，设计人员，开发人员，测试人员，QA人员
1
测试用例
同行评审
项目经理，设计人员，开发人员，测试人员，QA人员
1
2.9 开发环境
本系统将在B/S结构下，采取基于JAVA技术而且符合J2EE开发规范进行开发，具体以下：
硬件
软件
DELL2850/至强
2.8G*2颗/4G内存/146G*2硬盘
数据库：oracle 9i
应用服务器：Websphere 5.1
开发工具：Ecplise
项目管理工具：Microsoft Project
绘图工具：Microsoft Visio
配置工具：Microsoft Visual SourceSafe
分析工具：Rational Rose
数据库设计工具：PowerDesigner 9.5
2.10 风险评定和控制
描述估计项目中可能发生风险，风险系数=严重等级X风险概率。风险等级是指该风险对项目进度、质量和成本影响严重程度，可分为四个等级，等级越高影响越严重。
1. 用户风险，指因为用户成熟度不够而产生风险
2. 过程风险，指因为项目组组员对开发过程不熟悉而产生风险
3. 能力风险，指因为项目组组员不含有项目需要能力而产生风险
4. 成本风险，指因为项目成本过高而产生风险
5. 人力资源风险，指因为人员不足而产生风险
6. 设备资源风险，指因为开发设备不足而产生风险
7. 技术风险，指因为采取项目组组员不熟悉技术而产生风险
8. 质量风险，指因为用户要求质量过高而产生风险
9. 时间风险，指因为开发时间过紧而产生风险
10. 需求风险，指因为需求调研不充足而产生风险
风险概率可用百分比表示，百分比越高发生可能性越大。风险应该根据风险系数大小排序。风险对策是为了减轻风险影响，项目组可能采取方法。全部风险按风险等级排序。
注：风险系数 = 严重等级 x 发生概率
严重等级范围 1-4

序号
风险系数
严重等级
发生概率
风险种类
风险说明
估计风险发生阶段
应对方法
降低风险策略
1
1.6
2
80%
1
和原有系统需求范围界定不清楚
开发实施阶段
一旦产生需求变更，根据企业变更步骤进行处理。
整个项目周期内和用户充足沟通，主动协调用户确定需求。
2
0.5
1
50%
9
系统设计开发时间短，有可能延期3-5个工作日
开发阶段
提前投入开发人员对已经经过评审设计开始编码。
系统设计一定要尽可能完善，加强项目组组员之间沟通。立即把握项目进度。
3
0.5
1
50%
1
用户对BS结构系统使用
实施阶段
进行针对性培训。
加强培训，尽可能完善用户手册。
2.11 组间协调计划
协调小组/人
协调方法
协调内容
如发生问题时怎样处理
频率/时间
蒋宇、杨晓南
会议
系统需求、项目进度
向上级汇报
每七天五
蒋宇、杨晓南
电话、邮件
开发时碰到细节问题
向上级汇报
每七天3-10次
蒋宇、杨晓南
会议
确定需求
向上级汇报
-11-07
蒋宇、杨晓南
会议
代码开发结束，讨论实施细节。
向上级汇报
-12-30
蒋宇、杨晓南
会议
系统测试结束，商讨数据移植方案
向上级汇报
-01-05
蒋宇、杨晓南
会议
讨论验收细节
向上级汇报
-02-05

2.12 培训计划
无

3 项目组成
依据本项目标情况列出项目中全部参与人员及所担当角色

角色
责任负担人
项目总监
刘平
咨询顾问
杨树轶
项目经理
张桐
质量确保员
杨海舰
SCCB
刘平、杨海舰、张桐、伍箭和刘扬
架构设计师
张桐
系统分析员责任人
伍箭
系统分析员
伍箭
测试责任人
刘扬
测试工程师
刘扬
软件工程师
李兵
软件工程师
王松涛
软件工程师
李海波
SCM管理员
刘扬
实施责任人
张桐

4 项目跟踪计划
对项目标跟踪活动也要有计划，跟踪计划描述参与人员、跟踪活动名称和跟踪频率。
角色
活动
频率
项目经理
召开定时例会
每七天（每两周提交项目进展汇报）
项目经理
组织项目数据分析汇报填报
每里程碑
项目总监
用户经理
项目经理
质量确保员
项目组组员
参与里程碑评审
每里程碑
项目组组员
填写PSA上任务跟踪信息
天天
SCCB
项目经理
质量确保员
计划变更及评审
当项目进度、工作量、成本、规模等偏差率超出计划阈值时。（参见度量计划）
项目组组员
项目总结
项目结束

5 问题跟踪
项目经理对项目中发觉人力资源变动、技术难点、计算机资源和外部环境影响等问题进行跟踪。跟踪统计反应在《项目问题跟踪表》中。
用户反馈问题在《用户反馈问题统计及跟踪表》中进行统计和跟踪。
需求变更另有需求变更步骤，不列入问题跟踪。
6 相关文档
《软件需求规格说明书》
《软件质量管理计划》
《量化过程管理计划》
《软件验收汇报》
《项目问题追踪表》
《软件项目进展汇报》
《软件项目里程碑汇报》
《软件项目总结汇报》
《软件配置管理计划》
《软件质量确保计划书》
《软件评审过程》
《软件项目估算指南》
《软件生命周期选择指南》