图书综合管理系统优质项目专项计划.doc

图书管理系统项目计划

目录
1 引言 1
1.1 背景 1
1.2 定义 2
1.3 参考资料 2
1.4 标准、条约和约定 2
2 项目概述 3
2.1 项目目标 3
2.2 产品目标和范围 3
2.3 假设和约束 3
2.4 项目工作范围 3
2.5 应交付结果 4
2.5.1 需完成软件 4
2.5.2 需提交用户文档 4
2.5.3 须提交内部文档 4
2.5.4 应该提供服务 5
2.6 项目开发环境 5
3 项目团体组织 5
3.1 组织结构 5
3.2 人员分工 6
3.3 协作和沟通 8
3.3.1 项目团体内部协作 8
3.3.2 项目接口人员 8
3.3.3 项目团体外部沟通和协作模式 8
4 实施计划 8
4.1 风险评定及对策 8
4.2 工作步骤 12
4.3 总体进度计划 13
4.4 项目控制计划 14
4.4.1 质量确保计划 14
4.4.2 进度控制计划 15
4.4.3 预算监控计划 15
4.4.4 配置管理计划 16
5 支持条件 17
5.1 内部支持 17
5.2 用户支持 17
5.3 外包（可选） 17
6 预算 17
6.1 人员成本 17
6.2 设备成本 18
6.3 其它经费预算 18
7 关键问题 18
8专题计划关键点 19

图书管理系统项目计划

1 引言
1.1 背景
(1) 项目标名称
图书管理系统
(2) 项目建设背景
伴随大家知识水平层次提升，图书馆成为日常生活中不可缺乏一部分。而图书馆存书量和业务量庞大，仅仅靠传统记帐式管理是不可行。图书馆系统应运而生，逐步成为信息化建设关键组成部分。图书馆管理系统为学校或社会型图书馆管理员提供全部借阅者具体信息，和馆内库存具体情况，对借书和还书两大功效进行合理操纵并登记。
(3) 软件系统和其它系统关系
本系统属于整个企业发展系统建设基础性系统，关键是尝试性为用户提供服务同时，逐步建立并完善一个独立数据库，大范围集结优异项目管理工程案例。未来在这个基础骨干系统基础上逐步完善各个子系统，并发展成为功效完善、功效强大独立系统。优异项目管理案例能够挂在工程管理职能部门相关网页下供社会学习参考。
(4) 软件系统和机构关系
该系统出了为本企业用户提供相关服务之外，还应该在工程管理职能部门下设置相关优异项目管理案例供社会学习参考。
1.2 定义
Sql语言：是指基础通用数据库操作语言。
GUI编程：是指图形界面编程。
1.3 参考资料
文档格式要求根据中国GB/T8567-1988国家标准和IEEE/ANSI830-1993标准规范要求进行。包含以下文件：
a.图书借阅关系系统需求说明书
b.软件工程项目开发文档范例
c.软件工程国家标准文档
d.图书借阅管理需求说明书
e.软件需求说明书编写规范
书籍包含：
《软件项目管理》夏辉，周传生，清华大学出版社。
1.4 标准、条约和约定
本项目遵从以下标准：
GB/T 13702-1992 计算机软件分类和代码
GB/T 20918- 信息技术
GB/T 19003- 软件工程
GB/T 5538-1995 软件工程标准分类法
GB/T 9386- 计算机富安居测试文档编制
GB/T 9385- 计算机软件需求规格说明
GB/T 5532- 计算机软件测试规范
GB/T 18221- 信息技术程序设计语言
GB/T 11457- 信息技术 软件工程
GB/T 8567- 计算机软件文档编制规范
2 项目概述
2.1 项目目标
本项目标总目标是完成图书馆管理系统，为实现此目标，必需实现一下三个阶段目标：
第一阶段目标：总体设计出图书馆管理系统总框架，并分析所需功效。
第二阶段目标：大致完成图书馆管理系统。
第三阶段目标：对完成管理系统测试并验收。
2.2 产品目标和范围
本项目产品目标是实现图书馆对图书智能化、信息化、简单化，经过该系统来替换以往复杂软件操作存在弊端。系统关键功效是实现图书信息增加、删除、修改、查找、借阅、还书显示操作，及实时数据库提交更改。提升图书管理职员作信息报送反馈工作效率，愈加好统计信息，提升信息立即性、汇总统计信息正确性，减轻管理员劳动强度。
2.3 假设和约束
本项目标开发时间为:
工作人员：6人
开发经费预算：90万
设备：7台PC
假设：
1、 本企业资金充足，全部硬件设施如若需要就能在三天内投入使用，而且已经办完了全部 系统开发相关手续。
2、 人员充足且协作能力强，工作效率高，能够快速经过努力完成所交付任务。
3、 严格跟进，不能超出计划时间。
约束：
1、 系统开发，标准上严格控制成本，不能超出预算10%。
2、 必需在项目经理有效指挥下严格完成任务，投入人员不能超出5人。
3、人力资源约束限制，就必需牺牲进度或质量。
2.4 项目工作范围
为了使本系统成功达成用户要求，需完成以下任务：
系统需求分析、系统概要设计、编码设计、和系统测试和维护。
2.5 应交付结果
2.5.1 需完成软件
程序名称：图书馆管理系统
编程语言：C#+SQL Server
软件对象：源程序、可实施程序、支撑系统数据库数据、安装软件。

2.5.2 需提交用户文档
安装维护手册：关键内容是介绍安装和维护关键步骤和注意事项。
使用手册：关键内容是向用户介绍怎样使用该系统。
需求规格说明书：向用户介绍该系统需求规格说明。
2.5.3 须提交内部文档
1．软件项目管理计划
该文档由组长完成，介绍项目标整个管理过程。该文档在软件设计需求分析初级阶段完成，后续阶段由文档维护员进行对应更新。
2.需求规格说明初稿
在需求分析阶段，由全体小组组员采集分析用户需求，并在例会上作出决议，有文档维护员撰写整理需求规格说明初稿，并在后续各个阶段进行需求变更更新。
3.设计汇报初稿
在总体设计阶段，小组依据需求规格说明文档，完成软件体系结构设计，由组长编写软件体系结构设计文档初稿，并在后续开发阶段补充和更新。该文档由文档维护员负责维护更新。 4. 测试文档
在软件开发阶段，测试人员需要编写测试规格说明文档，并在后续测试阶段更新。开发人员将依据测试规格说明文档建立测试环境、准备测试数据。
5．用户手册
在更新用需求分析阶段，测试人员需要开始着手编写用户手册，并在需求分析结束后需要形成初稿；在后续阶段不停由文档维护员户文档；并在系统交付阶段伴随系统一起被交付。
6. 个人项目总结
由组内组员各自独立完成，对开发过程中取得工作经验进行总结。在提交系统时一并提交。 7. 其它文档
软件开发过程中其它文档，如开发日志（按组员意见选择公开是否），风险汇报及其处理意见等，由秘书进行整理和汇聚。作为以后软件开发和交流经验。
2.5.4 应该提供服务
将向用户演示安装、维护和运行使用。
2.6 项目开发环境
1、软件： Eclipse \ visual studio \ Dreamweaver \ Firework
2、硬件： PC机
3、技术： ASP＼HTML＼CSS＼VBscript \ javascript\ SQL
4、项目设计及运行平台 Windows XP web IIS
2.7 项目验收方法和依据
代码验收：在交付用户之前进行小组内评审，代码编写符合HB6465标准，和文档说明保持一致，代码书写风格统一，采取标准规范，没有下列错误：因为软件缺点造成丢失数据，不符合设计要求，响应时间太长无法接收等问题。
文档验收：在交付用户之前进行小组内评审，文档格式符合HB6465标准， 功效符合和用户协议要求，清楚易读，没有语病和歧义。
服务验收：服务硬件达成文档说明要求，人员技术考评合格，定时上门维护。
3 项目团体组织
3.1 组织结构

设计经理
测试经理
开发经理
项目经理
需求分析组
界面设计组
文档编写组
概要设计组
框架设计组
具体设计组
测试组
测试用例设计组
测试脚本开发组

3.2 人员分工

姓名
角色
工作描述
×××
项目经理
01.项目沟通交流
02.项目进度掌控
03.关键技术框架制订
04.工作任务划分分配、审核、验收
05.开发平台建设
06.样例程序制作
07.日常管理工作
08.关键文档结果物整理
09.测试验收各个模块
10.架构设计整个系统关键权限部分
11.处理疑难技术问题
12.模块设计指导
×××
开发经理
01. 开发项目进度掌控
02. 工作任务划分分配、审核、验收测试验收各个模块
03. 日常管理工作
×××
×××
×××
开发人员
01. 分析系统需求分析
02. 界面设计
03. 文档编写
×××
设计经理
01. 分析新功效
02. 软件框架扩展
03. 代码模块分配
04. 数据库设计说明书
×××
设计人员
01.数据交换
02.安装程序
03.安装手册
×××
设计人员
01.数据加载分析
×××
设计人员
01. 项目后期总体负责
02. 加载程序编写
×××
设计人员
01.数码相机照片读取剪切模块设计
×××
测试人员
01. 对软件进行测试
02. 编写软件测试文档
×××
测试人员
01.用户操作手册
3.3 协作和沟通
3.3.1 项目团体内部协作
本项目由项目经理领头协调各个项目组组员协调工作。下设小组长×××、×××。 关键经过企业内部邮箱联络，项目团体每一个组员全部有一份项目组员联络方法单。 在每一项目阶段开始和结束时全部由项目经理组织召开工作大会。并由×××做好会议记要，并归档统一管理。
3.3.2 项目接口人员
(1) 负责本项目同用户接口人员 本项目有企业自主开发，供企业发展使用。关键是由项目经理同开发设计部街头。
(2) 负责本项目同本企业开发设计部接口人员 依旧由项目经理担任接口人员。 项目经理和开发设计部和企业职能部门交接内容由专员负责统计，并交由×××统一归档。
3.3.3 项目团体外部沟通和协作模式
项目团体外部由项目经理负责沟通协作。 在每一项目阶段开始和结束时，项目经理结束团体内部工作安排总结以后，需要向企业相关职能部门提交汇报，汇报交由×××统一归档保管。
联络方法：
开发设计部： 电话：151****0326（部长助理）
邮箱：××××××@
紧急联络方法（仅供特殊情况下使用）：
电话：158****9469（李经理）
邮箱：××××××@
4 实施计划
4.1 风险评定及对策
风险识别
风险定性和定量分析
风险应对
编号
WBS模块
风险事件
风险概率
风险影响描述
风险影响值
风险期望值
排序
等级
缓解策略策略
应急计划和巢湖发事件
风险处理方法
风险责任人
1
需求风险
需求分析不到位，造成数据模型建立好后无法使用
6%
10%≤成本增加<20%
0.2
0.12
8
四级
1、重新进行到位需求分析
1当数据模型建立后无法使用时，即使重新做需求分析
一周
工作包责任人
2
需求风险
缺乏有效需求改变管理过程
10%
5%≤进度实施<10%
0.2
0.020
6
四级
1、立即和项目经理进行有效沟通，确保需求有效管理
1、当缺乏有效需求改变管理过程时，要立即，和对应管理人员惊醒沟通，制订有效改变管理
三天
工作包负责任
3
需求风险
用户不停改变需求
9%
工作质量受到较小影响
0.1
0.009
9
四级
1、要做好和用户之间沟通工作2、工作人员要做好应对必需改变准备，满足用户需求
当用户不停改变需求时，1、要做好和用户之间沟通工作2、工作人员要做好应对必需改变准备，满足用户需求
一周
工作包责任人
4
需求风险
院图书馆调研常常推后
20%
10≤进度拖延<
0.4
0.080
1
三级
和用户相关人员惊醒有效沟通
当需求调研不能立即进行时，依据合理时间调研并和相关工作人员进行有效沟通并确定调研时间
两天
项目经理
5
需求风险
一些需求超出项目范围
25%
范围关键部分受到影响
0.2
0.050
3
三级
查看范围进度计划，并和用户，进行合理沟通
1、一些需求超出项目范围时，1、明确列出超出项目范围需求，2查看范围进度计划，并和用户，进行合理沟通
一天
项目经理
6
需求风险
遗漏一些模块或多了一些模块
6%
范围次要不分受到影响
0.1
0.006
11
四级
查看范围进度计划，立即修改
当遗漏一些模块或多了一些模块时，1、查看范围进度计划，立即和项目经理进行沟通，假如遗漏一些模块，立即把遗漏任务分配给对应工作人员进行补充，假如多了部分设计模块，查看进度，并决定是否删除多出模块
一周
工作包责任人
7
相关性风险
签署协议不科学不严谨，存在边界界定不清楚问题
15%
10%≤进度实施<20%
0.4
0.060
10
四级
立即和用户进行有效沟通并重新修订协议
当协议有问题时，1、立即和用户进行有效沟通，并进行重新修订协议，2、重新依据需求制订愈加完美协议
桑拿天
项目经理
9
相关性风险
软硬件不兼容
1%
项目标最终产品实际上不能使用
0.8
0.040
12
四级
立即和供给商联络，并进行有效沟通，更换硬件设备
当软硬件不兼容时1、立即和供给商联络，并进行有效沟通，更换硬件设备2、假如无法更换，查看该硬件是否能够用在该系统其它位置
三天
工作包责任人
10
相关性风险
病毒、黑客入侵造成系统无法正常工作
5%
项目标最终产品实际上不能使用
0.6
0.050
16
三级
做好系统安全防护
当病毒、黑客入侵造成系统无法正常工作时，1、立即进行系统体检，用相关工具杀毒，2、经过相关设备对系统进行有效保护预防系统再次收到攻击

11
技术风险
预算有误，造成开发过程无法进行
9%
10%≤进度实施<20%
0.2
0.018
7
四级
向投资者申请新资金
当预算有误，造成开发过程无法进行时，向投资者申请新资金，2、向投资者展示新预算和以前错误预算
一周
工作包责任人
12
技术风险
开发工具不可靠造成项目过程中bug
5%
10%≤进度实施<20%
0.40.
0.032
5
四级
确定开发工具可靠
当开发工具不可靠时，1、立即做测试，发觉bug。2、更换开发工具
一周
工作包责任人
13
技术风险
使用框架存在漏洞bug，造成项目失败
1%
质量降低需要得到相关领导同意
0.2
0.002
13
四级
测试人员立即发觉问题，开发人员立即处理问题
当使用框架存在漏洞bug，造成项目失败时，1、立即对框架进行修复2、更换更可靠框架
一周
工作包责任人
14
管理风险
技术人员离职，模块任务无人完成
5%
10%≤进度实施<20%
0.3
0.050
2
三级
1、加强人员考评；确定人员可靠性2、立即需找人员替换气工作
当技术人员离职，模块任务无人完成时1、加强人员考评；确定人员可靠性2、立即需找人员替换气工作3、和当事人做立即沟通，
2天
项目经理
15
管理风险
不能按进度计划完成对应任务
2%
10%≤进度实施<20%
0.3
0.060
14
四级
做好跟踪统计
当不能按进度计划完成对应任务时，1、做好对每个人立即跟踪统计，2、若不能按进度完成，应该进行加班完成对应任务
一周
工作包责任人
15
管理风险
进度进化不够完善造成整体任务滞后
5%
质量降低需要得到相关领导同意
0.6
0.086
15
三级
立即调整计划
当进度进化不够完善造成整体任务滞后时1、立即调整计划2、将所差进度加班完成
2天
工作包责任人
16
自然风险
火灾、涝灾、地震等自然灾难

1%
质量降低需要得到相关领导同意
0.3
0.020
16
三级
做好转移工作，降低损失程度
当火灾、涝灾、地震等自然灾难时1、做好系统备份转移工作，把损失降低到最小2立即做出应急处理，是相关责任人做出快速反应。
三天
工作包责任人
4.2 工作步骤

项目计划
需求分析
概要设计
数据库设计
编码实施
系统测试
结项
SQA
配置管理

4.3 总体进度计划
起止时间
责任人及所需资源
完成工作
应提交结果
检验点/里程碑

项目经理和各部门责任人
项目立项
立项汇报
高层经理审批

项目团体建立

SM和PM决定，SQA人员由中心确定

项目生命周期模型选择
项目计划中生命周期

需求开发过程定义
需求开发计划
简单制订需求开发计划

软件评定和风险评定
软件评定开发书、软件开发计划、风险管理计划和日志
简单实施

培训计划制订
培训计划

软件开发计划文档化
软件开发计划

测试计划
测试计划

项目结项
项目总结汇报、验收汇报
概要编写

需求分析人员
用户需求调研、需求分析、软件需求走查、需求组内正式评审
软件需求规格说明书、评审准备表、汇报

设计人员
界面设计、总框架设计
界面设计汇报、框架设计汇报表

编程人员
系统编程
编程源代码
系统可运行

测试人员
测试软件
测试阶段汇报、系统测试评定、操作手册、用户手册、测试阶段度量数据

项目经理和各项目责任人
验收、维护
验收汇报、项目总结汇报

项目经理
用户验收

4.4 项目控制计划
4.4.1 质量确保计划
实施时间
阶段任务
人员
分工
×月×日
×月×日
×月×日
×月×日
×月×日
需求分析

需求评审

开发经理

系统和测试设计

系统概要设计评审

系统具体设计评审

制订测试策略评审

制订测试计划评审

编码和测试实施

制订编码规范评审
设计经理

测试需求评审

测试经理

代码审查

单元测试汇报评审

测试用例评审

缺点汇报评审

测试评定和系统布署

测试评定汇报评审

布署方案评审
项目经理

4.4.2 进度控制计划
时间
阶段任务
人员
分工
201×年×月
201×年×月
201×年×月
项目开启和计划
项目经理 技术教授

需求分析
开发经理

系统和测试设计

系统概要设计
设计经理

系统具体设计

制订测试策略
测试组长

制订测试计划

编码和测试实施

制订编码规范
设计经理

确定测试需求
测试经理

编码
设计经理

单元测试

编写测试用例
测试经理

实施测试

测试评定和系统布署

测试评定

制订布署方案
开发组长

4.4.3 预算监控计划
活动
小活动
预算小活动分摊
预算大活动分摊
预算累计
项目计划
1、模板确定
1320

3960
1320
2、撰写项目计划汇报
2640
3960

需求分析
3、需求调研
2640

11880
6600
4、需求分析
5280
11880
5、需求确定
2640
14520
6、撰写需求分析说明书
1320
15840

软件设计
7、系统分析
3960

25080
19800
8、模块设计
9240
29040
9、数据库设计
6600
35640
10、美工设计
3960
39600
11、撰写具体设计说明书
1320
40920

软件开发
12、硬件安装
25900

45700
66820
13、环境配置
1320
68140
14、代码实现
18480
86620

软件测试
15、集成测试
5280

11880
91900
16、系统测试
5280
97180
17、撰写系统测试汇报
1320
98500
验收总结
18、撰写用户手册
1320

5280
99820
19、人员培训
1320
101140
20、产品转移
1320
102460
21、经验总结
1320
103780
4.4.4 配置管理计划
采取专用版本管理工具进行软件版本控制，如SVN或是Git之类管理工具。
（1）人员和职责
版本控制管理者：项目经理 职责：制订版本控制步骤
（2）确定版本库用户权限
管理者：负责版本管理、对版本库拥有全部权限
开发人员：写入 读出
测试人员：读
（3）定义配置项（版本控制项）及其标识
系统项目计划
系统需求说明
系统概要设计
系统具体设计
测试策略
测试计划
测试用例
编码规范
源代码
缺点汇报
测试最终止果汇报
（4）定义项目基线（略）
（5）定义配置项版本管理策略
根据4类不一样功效分支进行：
l 主干分支
l 私有分支
l 小组分支
l 集成份支
5 支持条件
5.1 内部支持
无
5.2 用户支持
需求分析阶段：用户201×年×月×日参与到此阶段，需求分析人员统计需求。
用户验收阶段：用户于×月×日对本系统验收。
5.3 外包（可选）
无
6 预算
6.1 人员成本
姓名
标准费率
加班费
×××
￥330/工作日
￥50/小时
×××
￥250/工作日
￥40/小时
××××××
×××
￥200/工作日
￥35/小时
×××
￥250/工作日
￥40/小时
×××
￥200/工作日
￥35/小时
×××
￥200/工作日
￥35/小时
×××
￥200/工作日
￥35/小时
×××
￥200/工作日
￥35/小时
×××
￥200/工作日
￥35/小时
×××
￥200/工作日
￥35/小时
6.2 设备成本
全部设备全部有，成本为0。
6.3 其它经费预算

1
差旅费
3500
交通费用、伙食费、住宿费和差旅补助等等
2
资料费
1500
图书费、资料费、复印费
3
通信费

市话长话费、移动通信费、上网费、邮资
4
办公费

购置办公用具
5
协作费
11000
业务协作招待费、项目团体加班伙食费
6
奖金及福利费
15000
奖金、节假日福利等
7
加班费
15000
依据加班费率计算
8
房租
9000
包含地税
9
水电费
1000

10
项目监理费
5000
项目开发过程监理费
11
后期维护费
0
上线后期六个月维护
12
其它
5000
检测、维修费、消耗品、低易品、茶话会等
其它经费预算总计
90000

7 关键问题
软件开发项目风险是指在软件生命周期中所碰到全部预算、进度和控制等各方面问题，和由这些问题而产生对软件项目标影响。软件项目风险常常会包含很多方面，如：缺乏用户参与，缺乏高级管理层支持，含糊要求，没有计划和管理等，总体概括下来应该由楼六大方面。
1） 需求风险
很多项目在确定需求时全部面临着部分不确定性。当在项目早期容忍了这些不确定性，而且在项目进展过程当中得不四处理，这些问题就会对项目标成功造成很大威胁。假如不控制和需求相关风险原因，那么就很有可能产生错误产品或拙劣地建造预期产品。每一个情况对产品来讲全部可能致命。
2） 相关性风险
很多风险全部是因为项目标外部环境或原因相关性产生。常常我们在控制外部相关性上做不够，所以缓解策略应该包含可能性计划，方便从第二资源或协同工作资源中取得必需组成部分，而且觉察潜在问题。
3） 技术风险
软件技术飞速发展和经验丰富职员缺乏，意味着项目团体可能会因为技巧原因影响项目标成功。在早期，识别风险从而采取适宜预防方法是处理风险领域问题关键，
4） 管理风险
尽管管理问题制约了很多项目标成功，不过不要因为风险管理计划中没有包含全部管理活动而感到惊奇。在大部分项目里，项目经理常常是写项目风险管理计划人，她们有先天性不足——自己检验自己错误，这是最难。然而，像这些问题可能会使项目标成功变得愈加困难。假如不正视这些棘手问题，它们就很有可能在项目进行某个阶段影响项目本身。
5）自然风险
软件产品本身也属于一个应用型产品，一样会受到自然灾难影响。
8专题计划关键点
无