项目计划书.docx
《项目计划书.docx》由会员分享，可在线阅读，更多相关《项目计划书.docx（13页珍藏版）》请在冰豆网上搜索。
项目计划书
科成集团
项目计划书
科成集团
科成集团
2010/12/13
项目背景
1.1项目名称
学生管理信息系统开发设计
1.2项目情况简介
采用C/S和B/S相结合的方式，开发学生管理系统，辅助一个学院办公室的辅导员日常管理学生的工作，能满足辅导员的工作需求，提高他们的工作效率，更好的为学生服务。
1.3技术支持
SQLSever数据库，VisualStudio2008开发工具，ASP.NET动态网页技术
项目总体目标
2.1项目成果
成功开发出适用于中国石油大学的学生管理系统
2.2项目工期要求
2011年5月1日前完成系统开发并投入使用
2.3成本要求
总成本共计12000元
2.4质量要求
满足用户需求的功能，包括：
1）WYSIWYG（What-you-see-is-what-you-get所见即所得）功能：
人性化界面，自动安装，多级撤消（UNDO）和纠错，菜单操作等。
2）支持多用户同时访问：
采用并发机制。
3）标准的数据库功能，能对数据库进行方便管理：
具有安全性，完整性，并发控制，数据恢复等。
4）生成报表，提供报表摸板；提供打印功能：
可用摸板（综合测评，贫困困难补助名单，学生名单，宿舍名单，……），标准打印功能
5）文件传输功能：
在系统涉及范围内能方便的传输文件
6）学生管理：
每一客户（辅导员）都管理一定数量（100~500人）的学生，客户能通过该系统管理每个学生的基本信息，如学号，姓名，……；管理学生学籍，如退学，休学，复学，转班，……；管理学生住宿情况，如寝室号，地址，电话……；管理班级情况，如班长，团支书开会，……
7）教师管理:
提供在校教师的基本信息，如职称，联系方式
8）教学管理:
提供课程表查询，如可知道在某天某时那些班没课……；方便学生查询成绩，包括网上查询。
9）年度学生综合测评管理
叙述：
年度综合测评是学校一年一次的对学生的综合评价。
它分德育（30分），智育（60分），体育（10），奖惩分（正负10分），加起来为100+正负10。
德育由自评——自己给自己评分（30%）+互评——班上同学给自己评分（30%）+辅导员评分——辅导员给自己评分（40%）；智育由学生一学年的学习课程成绩来算，算法为……；体育……；奖惩分由一学年内获奖的情况来确定。
学校根据综合分可对学生进行排名和奖学金的发放，奖学金的评定有成绩的硬性规定，如三等奖要平均分70以上，最底分62以上。
10）辅导员个人管理:
针对辅导员的工作辅助管理他日常的事务。
他能根据个人管理更好管理每个学生，更好的为学生服务。
11）系统自我管理：
系统有自我管理功能，如有错误自动记录，提示，修复；数据库的自动整理，备份；……
项目团队组织
3.1项目组织结构
项目经理：
项目计划的制订和跟踪，包括进度、资源和成本的管理，还要负责团队的建立和管理
系统分析员：
需求分析、系统分析（OOA）、业务建模
架构设计师：
系统设计（OOD）
测试设计师：
测试用例的开发、测试计划
程序员：
编码实现、单元测试、集成测试
测试员：
执行功能测试和压力测试
文档工程师：
用户手册、开发指南、产品发布说明
3.2生命周期
初始阶段：
大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计）
?
?
?
?
设计阶段：
大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）
?
?
?
?
实施阶段：
大部分编码和测试，少部分设计（大部分实施及测试，部分部署）
?
?
?
?
收尾阶段：
安装及维护（大部分部署）
项目工作分解
4.1工作分解及编码
4.2项目里程碑计划
1）了解用户需求,确定开发系统要达到的目标
2）完成系统的总体设计
3）通过单元和功能测试
4）通过系统测试,打包投入使用
项目进度计划
5.1项目工序时间
序号
工作名称
工作时间（天）
紧后项目
搭接项目
搭界时间
1
产品需求
5
2
2
产品目标
5
3，4
3
规格说明书
10
6
4
初步进度计划
5
5
5
高层设计
10
6
6
最终进度计划
5
7
7
低层设计
10
8，9
8
编码
15
10
9
测试计划
5
10
10
单元测试
5
11
11
系统测试
10
—
5.2项目工序网络图
5.3关键路径
序号
工作名称
工作时间（天）
最早开始时间
最晚开始时间
最早结束时间
最晚结束时间
1
产品需求
5
0
0
5
5
2
产品目标
5
5
5
10
10
3
规格说明书
10
10
12
20
22
4
初步进度计划
5
10
10
15
15
5
高层设计
10
15
15
25
25
6
最终进度计划
5
25
25
30
30
7
低层设计
10
30
30
40
40
8
编码
15
40
40
55
55
9
测试计划
5
40
45
50
55
10
单元测试
5
55
55
60
60
11
系统测试
10
60
60
70
70
项目总工期为:
71天
5.4甘特图
项目资源计划
6.1人力资源计划
序号
工作名称
工作天数
人力资源
工作量估计（工时）
平均每天工作量
每天安排人数
1
产品需求
5
管理人员
120
24
3
2
产品目标
5
管理人员
120
24
3
3
规格说明书
10
工程师
200
40
5
4
初步进度计划
5
管理人员
80
16
2
5
高层设计
10
工程师
200
40
5
6
最终进度计划
5
管理人员
80
16
2
7
低层设计
10
工程师
800
80
10
8
编码
15
程序员
1200
80
10
9
测试计划
5
程序员
80
16
2
10
单元测试
5
程序员
200
40
5
11
系统测试
10
程序员
800
80
10
6.2设备计划
序号
工作名称
设备使用情况
原材料使用情况
1
产品需求
电脑、打印机、电话
电、纸张
2
产品目标
电脑、打印机
电、纸张
3
规格说明书
电脑、打印机
电、纸张
4
初步进度计划
电脑、打印机
电、纸张
5
高层设计
电脑
电
6
最终进度计划
电脑、打印机
电、纸张
7
低层设计
电脑
电
8
编码
电脑
电
9
测试计划
电脑、打印机
电、纸张
10
单元测试
电脑
电
11
系统测试
电脑
电
项目采购计划
设备/原材料名称
数量
采购
方式
采购（租赁）地点
采购（租赁）成本（元）
电脑
10台
购买
中关村
30000
打印机
2台
购买
中关村
500
纸张
若干
购买
超市
600
项目成本预算
每项工作的费用都包括人力费用和固定费用（材料、设备）
8.1单位人力费用
管理人员：
40元/小时
工程师：
60元/小时
程序员：
30元/小时
8.2费用预算安排
序号
工作名称
固定费用（元）
总费用（元）
每周平均费用（元/周）
1
产品需求
800
5600
5600
2
产品目标
800
5600
5600
3
规格说明书
1000
13000
6500
4
初步进度计划
800
4000
4000
5
高层设计
1600
13600
6800
6
最终进度计划
800
4000
4000
7
低层设计
2000
14000
7000
8
编码
600
48600
16200
9
测试计划
600
3000
3000
10
单元测试
800
6800
6800
11
系统测试
1000
25000
12500
8.3项目累计成本预算表
周数
本周费用（元）
已累积费用（元）
至本周累计费用（元）
1
5600
0
5600
2
5600
5600
11200
3
10500
11200
21700
4
13300
21700
35000
5
10800
35000
45800
6
7000
45800
52800
7
7000
52800
59800
8
19200
59800
79000
9
16200
79000
95200
10
16200
95200
111400
11
6800
111400
118200
12
12500
118200
130700
13
12500
130700
143200
项目风险计划
软件项目管理的四个阶段中，在初始阶段项目成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的，比如：
在这个阶段如果某种原因突然资金来源断了（这在需求阶段是很有可能的），以至于不能继续进行项目，不得不终止项目，那么这时候的损失只是需求分析阶段的投入。
随着项目的进展项目成功的可能性变大，风险发生的概率逐渐变小，风险对项目的损失逐渐变大，快到收尾阶段的时候风险对项目的损失最大，随着收尾阶段的进行风险又逐渐变小。
9.1风险识别?
风险源与风险事件:
1）初始阶段可能的风险事件：
?
?
?
?
1、项目目标不清
?
?
?
?
2、项目范围不明确（范围太大太小都不可以）
?
?
?
?
3、用户参与少或和用户沟通少
?
?
?
?
4、对业务了解不够
?
?
?
?
5、对需求了解不够
?
?
?
?
6、没有进行可行性研究
2）?
设计阶段可能的风险事件
?
?
?
?
1、项目队伍缺乏经验，如缺乏有经验的系统分析员
?
?
?
?
2、没有变更控制计划，以至于变更没有依据，该变更的不变，不该变的也变，这样得来的设计势必会失败或者偏离用户需求
?
?
?
?
3、仓促计划，可能带来进度方面的风险
?
?
?
?
4、漏项，由于设计人员的疏忽某个功能没有考虑进去
3）实施阶段可能的风险事件
?
?
?
?
1、开发环境没有具备好
?
?
?
?
2、设计错误带来的实施困难
?
?
?
?
3、程序员开发能力差，或程序员对开发工具不熟
?
?
?
?
4、项目范围改变（突然要增加或修改一些功能，需要重新考虑设计）
?
?
?
?
5、项目进度改变（要求提前完成任务等）
?
?
?
?
6、人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大
?
?
?
?
7、开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差
?
?
?
?
8、没有有效的备份方案
?
?
?
?
9、没有切实可行的测试计划
?
?
?
?
10、测试人员经验不足
?
4）收尾阶段可能的风险事件
?
?
?
?
1、质量差
?
?
?
?
2、客户不满意
?
?
?
?
3、设备没有按时到货
?
?
?
?
4、资金不能回收
风险识别的有效方法:
建立风险项目检查表、因果分析图、采访各种项目干系人等。
?
软件项目的风险可以从以下几方面检查：
?
?
?
?
?
产品规模风险
?
?
?
?
业务影响风险检
?
?
?
?
与客户相关的风险
?
?
?
?
过程风险
?
?
?
?
技术风险
?
?
?
?
开发环境风险
?
?
?
?
与人员的模式和经验有关的风险
9.2风险综合评价
风险因素
权重W
风险发生的可能性
W*c
很大（1.0）
比较大（0.8）
中等（0.6）
不大（0.4）
较小（0.2）
计划不完善
0.2
0.08
工期紧张
0.2
0.04
人员变动
0.1
0.04
目标不明确
0.1
0.02
开发环境不可靠
0.15
0.06
编程能力
0.15
0.09
测试能力
0.1
0.06
W*C=0.39
9.3风险应对措施
PMBOK提到三种应对方法
?
1）避免
?
?
?
?
通过分析找出来发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。
比如：
如何避免客户不满意？
?
?
?
?
客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户需求。
不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节完全可以避免：
?
?
?
?
1、业务建模阶段要让客户参与
?
?
?
?
2、需求阶段要多和客户沟通，了解客户真正的需求
?
?
?
?
3、目标系统的模型或DEMO系统要向客户演示，并得到反馈意见，如果反馈的意见和DEMO系统出入比较大时，一定要将修改后的DEMO系统在次向客户演示，直到双方都达成共识为止
?
?
?
?
4、要有双方认可的验收方案和验收标准
?
?
?
?
5、做好变更控制和配置管理
?
?
2）减轻
?
?
?
?
通过降低风险事件发生的概率或得失量来减轻对项目的影响。
也可以采用风险转移的方法来减轻风险对项目带来的影响。
项目预算中考虑应急储备金是另一种降低风险影响的方法。
比如：
经过风险识别发现，项目组的程序员对所需开发技术不熟。
可以采用熟悉的技术来减轻项目在成本或进度方面的影响。
也可以事先进行培训来减轻对项目的影响。
?
?
?
3）接受
?
?
?
?
接收风险造成的后果。
比如：
为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。
开发应对计划:
针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。
比如:
在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程可以参照如下：
?
?
?
?
?
1、进行调研，确定流动原因
?
?
?
?
2、在项目开始前，把缓解这些流动原因的工作列入风险管理计划
?
?
?
?
3、项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行
?
?
?
?
4、制定文档标准，并建立一种机制，保证文档及时产生
?
?
?
?
5、对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作
?
?
?
?
6、对每个关键性技术人员培养后备人员
?
?
?
?
在考虑风险成本之后，决定是否采用上述策略。
项目质量管理
10.1文档管理
1）内部文档包括：
项目开发计划;需求分析;体系结构设计说明;详细设计说明;构件索引;构件成分说明;构件接口及调用说明;组件索引;组件接口及调用说明;类索引;类属性及方法说明;测试报告;测试统计报告;质量监督报告;源代码;文档分类版本索引;软件安装打包文件。
2）外部文档主要包括：
软件安装手册;软件操作手册;在线帮助;系统性能指标报告;系统操作索引。
根据文档的不同，文档的来源也不同，文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。
特别是在系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。
10.2系统维护质量保证
系统交付后还需要后续的维护，一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。
所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。
他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。
对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。
如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。
升级会员 