图书馆占座系统的开发.docx

图书馆占座系统的开发.docx

《图书馆占座系统的开发.docx》由会员分享，可在线阅读，更多相关《图书馆占座系统的开发.docx（12页珍藏版）》请在冰豆网上搜索。

图书馆占座系统的开发

Companynumber：

【WTUT-WT88Y-W8BBGB-BWYTT-19998】

图书馆占座系统的开发

图书馆占座系统的开发

一.项目描述

1.项目背景

图书馆作为一个学校相对高级的场所，大量的藏书，能够为我们提供丰富的学习资源。

相对安静、舒适的学习环境，更是使它成为自习的最佳去处；然而，作为报答一个公共场所，每一天都有大量的学生进进出出，由于每个人的行为习惯或思维方式的不同，便引发了一系列的不良现象。

其中最严重的莫过于“占位”现象。

每当寒冷的冬季以及各种考试来临前图书馆当仁不让的成为了人群爆满的地方，然而图书馆座位有限，便开始有人占位，或帮同学占位，而且占位的方式很多，几本甚至一本书、一瓶水、一支笔就可以占一个座位什么样的东西都能拿来占位。

图书馆的位置资源开始紧缺，因为虽然每个桌子上都有书或其他的占位物品，但三分之一的位置是没人的，同学们对此一片怨声载道

试着想象下这样一个场景：

“过几天就要考试了，为了考出好一点的成绩，你昨晚便下定决心，明天一定要泡一天的图书馆，把遗漏的、没有理解清楚的知识补回来；可第二天，当你背着书包来到图书馆的时候，从一楼找到六楼，却发现不仅每个书库连自修室都没有空位置。

令人恼火的是偌大的自修室内，只是稀疏零散地坐着几个学生。

一张可以坐四人的桌子，上面往往只有一个人麻木地坐着。

而其他座位上则是随意地放着几本书，仿佛是在告诫你：

“不要打这座位的主意，这里有人了！

”

2.项目目的

（1）为学校处理和解决图书馆占位问题提供科学的依据和解决方案；

（2）为学生营造一个良好的图书馆学习环境；

（3）节省同学们找座位的时间；

（4）更合理的使用图书馆自习室；

3.项目目标

制作一个简单易操作的软件系统，同学们无论在何时何地都能通过手机或电脑根据自己的学号和教务系统的密码登陆本软件，进行占位，但座位只保留半个小时。

如果半个小时后，该同学不去该座位摁确认键的话，那么该座位将会变成无人座。

4．项目主要内容

（1）需求分析

（2）编写程序

（3）购买服务器

（4）应用于图书馆

二.工作分解结构

三．任务包的描述

1.计划

计划主要包括定义系统和可行方案，对项目的整体进行计划。

2.需求分析

主要包括功能性能分析、流程分析、逻辑模型分析以及修改计划。

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。

解释被开发软件与其他有关软件之间的关系。

3.系统设计

对软件系统进行概要设计，即系统设计。

概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

在概要设计的基础上，需要进行软件系统的详细设计。

在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序（每个模块或子程序）的设计考虑，以便进行编码和测试。

应当保证软件的需求完全分配给整个软件。

详细设计应当足够详细，能够根据详细设计报告进行编码。

4.编码

包括程序和调剂。

在软件编码阶段，根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。

5.系统测试

测试编写好的系统。

交给用户使用，用户使用后一个一个的确认每个功能。

6.试运行

包括改正适应以及改善。

四.责任矩阵

任务

项目经理

程序员甲

程序员乙

技术专家

100软件开发

F

C

110计划

F

C

111定义系统

F

C

112可行方案

F

C

120需求分析

F

C

121功能性能

F

C

C

C

122流程分析

F

C

C

123逻辑模型

F

C

C

C

124修改计划

F

C

C

C

130系统设计

F

C

C

C

1310概要设计

F

C

1311整体结构

F

C

C

C

1312模块划分

F

C

C

C

1313确定接口

F

C

C

C

1320详细计划

F

C

C

C

1321建立算法

F

C

C

C

1322数据结构

F

C

C

C

1323流程图

F

C

C

C

140编码

J,S

F

F

C

141编写程序

J,

F

F

C

142调试

J,S

F

F

C

150系统测试

J,S

F

F

C

151单元测试

J,S

F

F

C

152集成测试

J,S

F

F

C

153确认测试

J,S

F

F

C

154系统测试

J,S

F

F

C

160试运行

J,S

F

F

C

161改正性运行

J,S

F

F

C

162适应性运行

J,S

F

F

C

163完善性运行

J,S

F

F

C

170交付

F

C

C

C

注：

Ｆ负责；Ｃ参与；Ｓ审批；Ｊ监督

五．任务间相互关系的网络图

0

0

2

2

111定义系统

0

0

2

2

0

5

3

112可行方案

2

0

5

5

0

8

3

121功能性能

5

0

8

8

0

12

4

122流程分析

8

0

12

12

0

17

5

123逻辑模型

12

0

17

17

0

19

2

124修改计划

17

0

19

19

0

21

2

1311整体结构

19

0

21

21

0

24

3

1312模块划分

21

0

24

24

0

25

1

1313确定接口

24

0

25

25

0

31

6

1321建立算法

25

0

31

31

0

33

2

1322数据结构

31

0

33

33

0

36

3

1323流程图

33

0

36

36

0

56

20

141编写程序

36

0

56

56

0

61

5

142调试

56

0

61

61

0

71

10

151单元测试

61

0

71

76

0

79

3

153确认测试

76

0

79

71

0

76

5

152集成测试

71

0

76

79

0

81

2

154系统测试

79

0

81

81

0

82

1

160运行

81

0

82

79

0

81

2

154系统测试

79

0

81

六．进度计划

项目的里程碑计划

1）1月5日—1月9日计划阶段

2）1月10日—2月1日需求分析

　　3）2月1日—2月25日系统设计，包括概要设计和详细设计

　　4）2月26日—4月1日编码

　　5）4月2日—4月30日系统测试

6）5月1日试运行

序号

任务

天数/天

111

定义系统

2

112

可行方案

3

121

功能性能

3

122

流程分析

4

123

逻辑模型

5

124

修改计划

2

1311

整体结构

2

1312

模块划分

3

1313

确定接口

1

1321

建立算法

6

1322

数据结构

4

1323

流程图

3

141

编写程序

20

142

调试

5

151

单元测试

10

152

集成测试

5

153

确认测试

3

154

系统测试

2

161

改正性运行

1

162

适应性运行

1

163

完善性运行

1

170

交付

七．成本计划

任务

预算/元

计划

1000

需求分析

6000

系统设计

20000

编码

70000

系统测试

30000

试运行

30000

总计：

157000元

八．项目风险管理

1、需求不明确

需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。

在软件开发过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。

确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题：

（1）让用户参与开发

（2）开发用户界面原型

（3）需求讨论会议

（4）强化需求分析与评审

2、项目缺少可见性

软件开发项目，往往在项目进度和软件质量方面缺少可见性，项目越缺少可见性，项目就越难以控制，项目就越有可能失败。

我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。

应对方法：

（1）迭代开发

（2）技术评审

（3）持续集成。

每日构建、持续集成，让项目进度跟踪工作更加容易。

当项目小组每天重新编译系统时，已完成与未完成的功能清楚可见，小组成员能够简单地从软件的表现知道距离整体完成还有多远。

3、新技术引入

技术创新是一种具有探索性、创造性的技术经济活动。

在开发过程中引入新技术，不可避免地要遇到各种风险。

通过T形软件开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。

应对方法：

（1）T形软件开发在项目开发早期，开发小组应该建立系统的架构，解决关键技术难题、开发系统的基础构件，并对系统所需要应用的技术做深度探索。

（2）充分论证。

在可行性分析阶段，要广泛搜集相关信息，设计多种可行方案，进行充分论证。

（3）同行经验

针对新技术，由于没有经验可借鉴，因此在探索过程中要充分利用互联网，通过搜索同行经验，往往事半功倍

4、技术兼容性风险

硬件产品之间、系统软件（操作系统、中间件、数据库管理系统）与主机设备之间、系统软件之间、应用软件与系统软件之间以及应用软件之间，都可能存在兼容性问题。

往往系统集成的项目越复杂，兼容性问题就越有可能存在。

应对方法：

设计先行。

在做系统的总体设计方案时，务必把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。

5、性能问题

由于先期设计不足，性能问题往往在系统切换或新系统使用一段时间后暴露。

出现性能问题往往要进行大量的优化工作，甚至局部的或全面的重新设计。

无论是用户还是开发者，谁都不希望出现性能问题

（1）性能规划

在系统设计时，应做好前期做性能规划，对可能出现性能问题的环节做到充足的估计。

（2）性能测试。

在开发过程中，要重视性能测试和压力测试，尽可能模拟现实使用环境，搭建测试平台。

另外，由于开发环境的计算机往往比生产环境的计算机配置高，在做测试时应尽量找一些配置低的机器、较小的网络带宽进行测试。

（3）充足的调试时间。

在项目开发计划中，为后期性能优化留有余地。

在对系统进行性能优化后，要进行性能测试和压力测试，可能还要做几次回归测试。

6、仓促上线

在项目实施过程中，上线环节最容易出纰漏。

应充分考虑各种可能出现的问题，做好风险对策。

应对方法：

（1）应急预案

（2）分步切换

7、可用性问题

软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。

往往由于软件的可用性差，导致用户不满意，甚至被市场淘汰。

在项目开发中应注意可用性问题，避免软件出现可用性方面的风险。

应对方法：

（1）了解用户。

到用户工作现场，了解目标用户使用软件的真实目的，从用户的角度、从用户的立场出发，了解如何通过软件系统替代用户的业务处理流程中，最繁琐、最容易出问题、或者是大量重复劳动的环节，让软件提高用户的工作效能和效率。

（2）参与型设计。

与用户协作，让用户参与用户界面的设计、评审与测试，确保用户能够全面地、及早地发现可用性等方面的问题，并及时纠正。