图书管理系统项目计划.docx

资源描述

图书管理系统项目计划.docx

《图书管理系统项目计划.docx》由会员分享，可在线阅读，更多相关《图书管理系统项目计划.docx（40页珍藏版）》请在冰点文库上搜索。

图书管理系统项目计划.docx

图书管理系统项目计划

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/T13702-1992计算机软件分类与代码

GB/T20918-2007信息技术

GB/T19003-2008软件工程

GB/T5538-1995软件工程标准分类法

GB/T9386-2008计算机富安居测试文档编制

GB/T9385-2008计算机软件需求规格说明

GB/T5532-2008计算机软件测试规范

GB/T18221-2000信息技术程序设计语言

GB/T11457-2006信息技术软件工程

GB/T8567-2006计算机软件文档编制规范

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#+SQLServer2005

软件对象：

源程序、可执行程序、支撑系统的数据库数据、安装软件。

2.5.2需提交用户的文档

安装维护手册：

主要内容是介绍安装和维护的主要步骤和注意事项。

使用手册：

主要内容是向用户介绍如何使用该系统。

需求规格说明书：

向用户介绍该系统的需求规格说明。

2.5.3须提交内部的文档

1．软件项目管理计划

该文档由组长完成，介绍项目的整个管理过程。

该文档在软件设计需求分析初级阶段完成，后续阶段由文档维护员进行相应的更新。

2.需求规格说明初稿

在需求分析阶段，由全体小组成员采集分析用户的需求，并在例会上作出决策，有文档维护员撰写整理需求规格说明初稿，并在后续各个阶段进行需求变更的更新。

3.设计报告初稿

在总体设计阶段，小组根据需求规格说明文档，完成软件体系结构的设计，由组长编写软件体系结构设计文档初稿，并在后续开发阶段补充和更新。

该文档由文档维护员负责维护更新。

4.测试文档

在软件开发阶段，测试人员需要编写测试规格说明文档，并在后续测试阶段更新。

开发人员将根据测试规格说明文档建立测试环境、准备测试数据。

5．用户手册

在更新用需求分析阶段，测试人员需要开始着手编写用户手册，并在需求分析结束后需要形成初稿；在后续阶段不断由文档维护员户文档；并在系统交付阶段随着系统一起被交付。

6.个人项目总结

由组内成员各自独立完成，对开发过程中获得的工作经验进行总结。

在提交系统时一并提交。

7.其他文档

软件开发过程中的其他文档，如开发日志（按组员意见选择公开与否），风险报告及其处理意见等，由秘书进行整理与汇聚。

作为以后软件开发以及交流的经验。

2.5.4应当提供的服务

将向用户演示安装、维护以及运行使用。

2.6项目开发环境

1、软件：

Eclipse\visualstudio\Dreamweaver\Firework

2、硬件：

PC机

3、技术：

ASP＼HTML＼CSS＼VBscript\javascript\SQL

4、项目设计及运行平台WindowsXPwebIIS

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模块

风险事件

风险概率

风险影响描述

风险影响值

风险期望值

排序

级别

缓解策略策略

应急计划和巢湖发事件

风险处理措施

风险负责人

需求风险

需求分析不到位，导致数据模型建立好后无法使用

10%≤成本增长<20%

0.2

0.12

四级

1、重新进行到位的需求分析

1当数据模型建立后无法使用时，即使重新做需求分析

一周

工作包负责人

需求风险

缺少有效的需求变化管理过程

10%

5%≤进度实施<10%

0.2

0.020

四级

1、及时和项目经理进行有效的沟通，确保需求的有效管理

1、当缺少有效的需求变化管理过程时，要及时，与相应的管理人员惊醒沟通，制定有效的变化管理

三天

工作包负责任

需求风险

客户不断变化需求

工作质量受到较小的影响

0.1

0.009

四级

1、要做好与客户之间的沟通工作2、工作人员要做好应对必要变化的准备，满足客户的需求

当客户不断变化需求时，1、要做好与客户之间的沟通工作2、工作人员要做好应对必要变化的准备，满足客户的需求

一周

工作包负责人

需求风险

院图书馆调研经常推后

20%

10≤进度拖延<

0.4

0.080

三级

与客户相关人员惊醒有效沟通

当需求调研不能及时进行时，根据合理时间调研并与相关工作人员进行有效沟通并确定调研时间

两天

项目经理

需求风险

某些需求超出项目范围

25%

范围主要部分受到影响

0.2

0.050

三级

查看范围进度计划，并与客户，进行合理的沟通

1、某些需求超出项目范围时，1、明确列出超出项目范围需求，2查看范围进度计划，并与客户，进行合理的沟通

一天

项目经理

需求风险

漏掉某些模块或多了某些模块

范围的次要不分受到影响

0.1

0.006

四级

查看范围进度计划，及时修改

当漏掉某些模块或多了某些模块时，1、查看范围进度计划，及时与项目经理进行沟通，如果漏掉某些模块，及时把漏掉的任务分配给相应的工作人员进行补充，如果多了一些设计模块，查看进度，并决定是否删除多出的模块

一周

工作包负责人