图书馆占座原因分析 图书馆有人占座怎么办

图书馆占座原因分析 图书馆有人占座怎么办

会计述职报告-小免子

图书馆占座系统的开发

一。项目描述

1.项目背景

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

学习资源。相对安静、舒适的学习环境，更是使它成为自习的最佳去处；然而，

作为报答一个公共场所，每一天都有大量的学生进进出出，由于每个人的行为习

惯或思维方式的不同，便引发了一系列的不良现象。其中最严重的莫过于“占位”

现象。每当寒冷的冬季以及各种考试来临前图书馆当仁不让的成为了人群爆满的

地方，然而图书馆座位有限，便开始有人占位，或帮同学占位，而且占位的方式

很多，几本甚至一本书、一瓶水、一支笔就可以占一个座位„„什么样的东西都能

拿来占位。图书馆的位置资源开始紧缺，因为虽然每个桌子上都有书或其他的占

位物品，但三分之一的位置是没人的，同学们对此一片怨声载道

试着想象下这样一个场景:“过几天就要考试了，为了考出好一点的成绩，

你昨晚便下定决心，明天一定要泡一天的图书馆，把遗漏的、没有理解清楚的知

识补回来；可第二天，当你背着书包来到图书馆的时候，从一楼找到六楼，却发

现不仅每个书库连自修室都没有空位置。令人恼火的是偌大的自修室内，只是稀

疏零散地坐着几个学生。一张可以坐四人的桌子，上面往往只有一个人麻木地坐

着。而其他座位上则是随意地放着几本书，仿佛是在告诫你：“不要打这座位的

主意,这里有人了！”

2.项目目的

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

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

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

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

3。项目目标

制作一个简单易操作的软件系统，同学们无论在何时何地都能通过手机或电

脑根据自己的学号和教务系统的密码登陆本软件,进行占位，但座位只保留半个

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

无人座。

4．项目主要内容

（1）需求分析

（2）编写程序

(3)购买服务器

（4）应用于图书馆

二。工作分解结构

三．任务包的描述

1.计划

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

2。需求分析

主要包括功能性能分析、流程分析、逻辑模型分析以及修改计划。叙述该项软件

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

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

图书馆占座系统

计划需求分析系统设计编码系统测试试运行

定义

系统

可行

方案

逻辑模型

流程分析

功能

性能

调试

程序

详细计划

概要设计

确认测试

集成测试

单元测试

改正性

系统测试

适应性

修改计划

完善性模块

划分

确定

接口

建立

算法

数据

结构

流程

图

整体

结构

3。系统设计

对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括

系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数

据结构设计和出错处理设计等，为软件的详细设计提供基础。在概要设计的基础上，需要进

行软件系统的详细设计。在详细设计中,描述实现具体模块所涉及到的主要算法、数据结构、

类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序（每个模块或子程序)

的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应

当足够详细,能够根据详细设计报告进行编码.

4。编码

包括程序和调剂。在软件编码阶段，根据《软件系统详细设计报告》中对数据结构、算法分

析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能,从而

实现对目标系统的功能、性能、接口、界面等方面的要求。

5。系统测试

测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。

6。试运行

包括改正适应以及改善。

四。责任矩阵

任务项目经理程序员甲程序员乙技术专家

100软件开发FC

110计划FC

111定义系统FC

112可行方案FC

120需求分析FC

121功能性能FCCC

122流程分析FCC

123逻辑模型FCCC

124修改计划FCCC

130系统设计FCCC

1310概要设计FC

1311整体结构FCCC

1312模块划分FCCC

1313确定接口FCCC

1320详细计划FCCC

1321建立算法FCCC

1322数据结构FCCC

1323流程图FCCC

140编码J,SFFC

141编写程序J，FFC

142调试J，SFFC

150系统测试J，SFFC

151单元测试J，SFFC

152集成测试J，SFFC

153确认测试J，SFFC

154系统测试J，SFFC

160试运行J，SFFC

161改正性运行J,SFFC

162适应性运行J，SFFC

163完善性运行J，SFFC

170交付FCCC

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

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

002

2111定义系

统

002

205

3112可行方

案

205

508

3

121功能

性能

508

8012

4122流程

分析

8012

12017

5123逻辑

模型

12017

17019

2124修改

计划

17019

19021

21311整

体结构

19021

21024

31312模

块划分

21024

24025

11313确

定接口

24025

25031

61321建

立算法

25031

31033

21322数

据结构

31033

33036

31323流

程图

33036

36056

20141编写

程序

36056

56061

5142调试

56061

六．进度计划

项目的里程碑计划

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

61071

10151单元

测试

61071

76079

3153确认

测试

76079

71076

5152集成

测试

71076

79081

2154系统

测试

79081

81082

1160运行

81082

141

编写程序

20

142

调试

5

151

单元测试

10

152

集成测试

5

153

确认测试

3

154

系统测试

2

161

改正性运行

1

162

适应性运行

1

163

完善性运行

1

170

交付

七．成本计划

八．项目风险管理

1、需求不明确

需求不明确是软件开发过程中经常可能遇到的问题,这类问题往往表现在需求范围未

界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过

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

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

(1)让用户参与开发

(2)开发用户界面原型

(3)需求讨论会议

(4)强化需求分析与评审

2、项目缺少可见性

软件开发项目，往往在项目进度和软件质量方面缺少可见性，项目越缺少可见性，项目

就越难以控制，项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强

项目的可见性。应对方法：

（1)迭代开发

(2)技术评审

任务预算/元

计划1000

需求分析6000

系统设计20000

编码70000

系统测试30000

试运行30000

总计：157000元

（3)持续集成.每日构建、持续集成，让项目进度跟踪工作更加容易。当项目小组每天

重新编译系统时，已完成与未完成的功能清楚可见，小组成员能够简单地从软件的表现知道

距离整体完成还有多远。

3、新技术引入

技术创新是一种具有探索性、创造性的技术经济活动。在开发过程中引入新技术，不

可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施

可降低新技术风险。应对方法：

（1)T形软件开发在项目开发早期,开发小组应该建立系统的架构,解决关键技术难题、

开发系统的基础构件，并对系统所需要应用的技术做深度探索。

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

证。

(3)同行经验

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

行经验,往往事半功倍

4、技术兼容性风险

硬件产品之间、系统软件(操作系统、中间件、数据库管理系统）与主机设备之间、系

统软件之间、应用软件与系统软件之间以及应用软件之间，都可能存在兼容性问题。往往系

统集成的项目越复杂,兼容性问题就越有可能存在.应对方法：设计先行。在做系统的总体设

计方案时，务必把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存

在较大的技术兼容性问题。

5、性能问题

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

能问题往往要进行大量的优化工作,甚至局部的或全面的重新设计。无论是用户还是开发者，

谁都不希望出现性能问题

(1）性能规划

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

(2)性能测试.在开发过程中,要重视性能测试和压力测试,尽可能模拟现实使用环境，搭

建测试平台.另外,由于开发环境的计算机往往比生产环境的计算机配置高,在做测试时应尽

量找一些配置低的机器、较小的网络带宽进行测试。

（3)充足的调试时间。在项目开发计划中，为后期性能优化留有余地。在对系统进行

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

6、仓促上线

在项目实施过程中，上线环节最容易出纰漏.应充分考虑各种可能出现的问题，做好风

险对策。应对方法：

(1)应急预案

(2)分步切换

7、可用性问题

软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人

愉快、是否不易出错等诸多因素。往往由于软件的可用性差,导致用户不满意，甚至被市场

淘汰。在项目开发中应注意可用性问题,避免软件出现可用性方面的风险。应对方法:

(1)了解用户.到用户工作现场，了解目标用户使用软件的真实目的，从用户的角

度、从用户的立场出发，了解如何通过软件系统替代用户的业务处理流程中，最繁琐、

最容易出问题、或者是大量重复劳动的环节，让软件提高用户的工作效能和效率。

(2)参与型设计.与用户协作，让用户参与用户界面的设计、评审与测试,确保用户

能够全面地、及早地发现可用性等方面的问题,并及时纠正。