1 需求分析
1.1 系统需求
该系统需要解决本学校学生在图书馆盲目寻找自习室教室及座位的问题。学生通过该系统可以实时查看图书馆自习室与座位的使用情况，使学生方便、快捷地在图书馆查找空余的座位。图书馆领导及管理人员也可以通过本系统查询自习室的使用人次和座位的预定情况进行统计，及时制定行营的对策，科学合理的配置相关资源。
1.2 功能需求
本系统设计的最终目的是实现对座位的有序高效管理。为此，在系统设计时，应做好用户需求调查，充分了解学生的实际需求，保证系统具有良好的易用性、稳定性和扩展性。系统设计要点如下：
（1）系统管理：对用户信息、角色信息、菜单信息和日志信息进行管理。
（2）师生信息（学习者）管理：可对班级、教师、学生等信息进行管理。
（3）自习教室管理：管理图书馆的自习教室。
（4）选座管理：可预约和取消自习教室座位。
（5）通知公告：发布图书馆相关自习教室使用以及开放的相关通知等。
（6）数据统计：利用图形直观显示自习教室某时间段（每天、每周、每月等或某个时间段如8:00-9:00等）各自习教室的座位使用情况以及的违规（违反自习教室使用规定）人数。
（7）修改密码：所有用户可在系统中重置或修改个人密码。
（8）信用积分管理：对学生自习教室的使用采用信用积分制。若信用积分累计到一定程度，某段时间内可采取相应的处罚措施等。如：若预约座位多长时间未使用且未取消的，扣1分等等。并对违规使用者，发出相关信息。
（9）安全退出：用户完成所有操作后安全退出本系统。
1.3 用例分析
1.3.1 按照角色建立用例模型
1) 非系统用户用例
对“用户注册”用例的描述如下。
| 用例编号 | 1 |
|---|---|
| 用例名称 | 用户注册 |
| 用例描述 | 非系统用户，需要进行用户注册才能使用系统功能。 |
| 前置条件 | 用户有申请注册账户的条件。 |
| 后置条件 | 用户完成申请。 |
| 活动步骤 | 1.提交申请资料 2.等待审核通过 |
| 扩展点 | 无 |
| 异常处理 | 该用户在信用黑名单上，无法注册 |
2)学习者用例
对“预约座位”用例的描述如下。
| 用例编号 | stu1 |
|---|---|
| 用例名称 | 预约座位 |
| 用例描述 | 学习者可以进行座位预约，进行学习 |
| 前置条件 | 学习者当前没有座位且登录系统，并通过了身份验证 |
| 后置条件 | 座位被成功预约 |
| 活动步骤 | 1.学习者根据条件找到想要预约的座位。2.进行预约 |
| 扩展点 | 1.学习者身份验证失败，则用例结束2.没有找到座位，则预约失败。 |
| 异常处理 | 查询条件错误，查询失败 |
对“修改个人信息”用例的描述如下。
| 用例编号 | stu2 |
|---|---|
| 用例名称 | 修改个人信息 |
| 用例描述 | 学习者可以登录系统，进行修改自己的个人信息 |
| 前置条件 | 学习者对自己的信息进行设置 |
| 后置条件 | 信息修改完成 |
| 活动步骤 | 1.进入修改信息页面。2.修改自己的信息。 |
| 扩展点 | 无 |
| 异常处理 | 信息重复或是信息格式错误，信息修改失败 |
对“查询个人信息”用例的描述如下。
| 用例编号 | stu3 |
|---|---|
| 用例名称 | 查询个人信息 |
| 用例描述 | 学习者可以登录系统 进行查看自己的个人信息 |
| 前置条件 | 学习者对自己的信息进行设置 |
| 后置条件 | 显示个人信息 |
| 活动步骤 | 进入个人信息管理页面 |
| 扩展点 | 无 |
| 异常处理 | 无 |
对“学习记录”用例的描述如下。
| 用例编号 | stu4 |
|---|---|
| 用例名称 | 学习记录 |
| 用例描述 | 学习者登录系统，通过次功能查询自己的在图书馆预约以及自己的学习记录 |
| 前置条件 | 系统中存在自己的信息 |
| 后置条件 | 学习者完成查询 |
| 活动步骤 | 1.进入学习查询管理页面。2.点击查询。 |
| 扩展点 | 无 |
| 异常处理 | 无 |
对“查询自习室信息”用例的描述如下。
| 用例编号 | stu5 |
|---|---|
| 用例名称 | 查询自习室信息 |
| 用例描述 | 学习者通过条件进行筛选，查看自习室实时的状态 |
| 前置条件 | 学习者登录系统 |
| 后置条件 | 返回自习室的状态 |
| 活动步骤 | 1.通过条件找到自习室。2.查看自习室状态。 |
| 扩展点 | 1.没有找到自习室，查询失败。2.查找条件错误，查询失败。 |
| 异常处理 | 自习室没有空座位，用例结束 |
3)图书馆工作人员用例
以“公告发布”这个用例为例，描述如下。
| 用例编号 | user1 |
|---|---|
| 用例名称 | 公告发布 |
| 用例描述 | 图书馆工作人员可以在系统后台发布图书馆相关自习教室使用以及开放的相关通知 |
| 前置条件 | 图书馆工作人员登录系统 |
| 后置条件 | 公告通知成功发布 |
| 活动步骤 | 1.进入后台管理系统。2.发布公告 |
| 扩展点 | 无 |
| 异常处理 | 公告内容涉及到敏感词汇，则发布失败 |
4)系统管理员用例
以“权限分配”这个用例为例，描述如下。
| 用例编号 | admin |
|---|---|
| 用例名称 | 权限分配 |
| 用例描述 | 系统中存在不同的用户，不同用户的权限不同，通过此对用户的权限进行分配 |
| 前置条件 | 系统中存在不同类型的用户 |
| 后置条件 | 每个用户都赋予相应的权限 |
| 活动步骤 | 1.管理员进入系统管理页面2.找到想要给予权限的的用户，为其分配权限。 |
| 扩展点 | 1.给予的权限与超过系统最大值，用例结束。2.未找到用户。 |
| 异常处理 | 未找到用户，则用例结束 |
1.3.2 优化用例模型
经过修改，“图书馆自习教室管理系统”的用例图如图2.3-5所示。
用例之间的关系有extend(继承)，include(包含)和generalization(泛化)三种，当某些步骤在多个用例中重复出现从，且单独形成价值时，可以将这些步骤提取出来，单独形成一个可供其他用例使用的用例，从而形成模型的简化。当学习者离开自习室的途中，首先需要查询到自习室对相应的状态，这时可以把自习室信息查询作为离开自习室用例，预约自习室用例的包含的用例。在本系统中，可能会遇到学习者的信用不足的情况，因为导致这种情况的原因是，预约了不去自习室，所以可以把它从预约自习室中提取出来，作为预约自习室用例的扩展用例。
2 系统设计
2.1 总体设计
2.1.1 架构模式
该系统平台的整体架构模式采用的是B/S与C/S模式相结合的多层架构模式。系统前端采用浏览器形式发布与访问，在学生用户座位预订、操作上采用WEB方式进行数据访问与操作;而在系统后台管理配置功能的操作上，系统采用传统的CIS模式来实现。采用这种结构模式的优点:一方面与当前的校园网络、图书馆信息管理系统保持一致，更好的与之兼容;另一方面因为这种混合模式可扩展性更强,为系统后续提供基于便携设备的移动式访问功能打下了良好的基础，降低开发的复杂性。
2.1.2 绘制子系统图
系统主要可以分为3个子系统：学生用户预约子系统、自习室座位管理子系统、添加黑名单子系统。
1.学生用户预约子系统：主要功能为学生对自习室座位的预约，按照题目的描述，学生用户通过登录验证后，通过系统对图书馆内自习室的座位情况进行查询，如自己没有违纪记录且自习室有空闲的座位，可以进行座位的预约或者取消座位的预约。
2.自习室管理子系统：主要功能是为管理员提供一个管理图书馆自习室的系统，管理员用户在登录后台管理系统后，可以对自习室的情况进行查看，按需来对自习室进行增加或删除，同时也可以通过对自习室内作为情况查看来进行相应的调整；同时可以根据目前自习室情况来发布相应的公告以及删除公告。
3.添加黑名单子系统：主要功能为对违规用户的处理，按照题目要求，在学生出现违规情况如预约座位后长时间未使用且未取消预约的，进行相应信誉分扣除处理，当信誉分扣除到一定分值时判定为违规用户，并对违规用户进行加入黑名单操作并进行一系列处理。
2.2 详细设计
2.2.1 建立对象模型
分析可知，系统可划分出进行操作的实体类学生和管理员，此外还有进行各种数据处理的系统控制类，以及与系统的数据库进行交互的系统边界类。下面对分离出的三个子系统分别绘制类图
系统类图
学生预约子系统类图
自习室管理系统类图
增加黑名单子系统类图
2.2.2 建立实体关系图
以学生预约座位为例，与此相关的实体类有Student、Studyroom、Manager和Seat,一个Student可以预约一个Seat，且一个Seat在同一时间段内只能被一个Student使用，一个Studyroom里可以有多个Seat，所以Seat和Studyroom之间的多重表达式是1…n，Seat和Studydent之间的多重表达式是1…1，实体关系图如图表示：
2.2.3 建立动态模型
当用户向ReserveBoundary发送预约座位的请求后，系统把该请求发送给ReserveControl进行处理，预约成功后，ReserveControl要改变座位的状态以及学生的信息。“个人预约座位”的顺序图如图所示：
2.2.4 设计用户界面
面向对象的分析阶段还需要设计出目标系统的用户界面。
此处展示登陆页面、主窗口、管理员界面
1、登陆界面
2、主窗口
3、管理员界面
2.2.5 建立功能模型
1、顶层数据流图
管理员将座位信息录入到“占座”系统，学生可以提交预定表单，将不合格信息返回给学生，提示预定失败。若系统通过预定表单申请，则将汇总信息返回给学生。
2、一层数据流图
管理员把座位信息录入到“占座”系统中。学生可以提交预定表单，同时系统会检查学生提交过来的表单信息，将不合格信息返回给学生，提示预定失败。将合格预定信息传入系统，并把学生自选座位给学生。等待发出座位状态信息，将汇总信息发送给学生。
3、二层数据流图
管理员把座位信息录入到“占座”系统中。学生可以提交预定表单，同时系统会检查学生提交过来的表单信息，将不合格信息返回给学生，提示预定失败。将合格预定信息传入系统，并把分配座位给学生。之后更新座位状态，更新座位占有信息，显示该座位被占有，此时其他同学不可再预约此座位。等待发出座位信息状态，将汇总信息发送给学生。
3 质量计划
3.1概述
3.1.1目的
为了健全和完善图书馆自习教室管理系统设计开发的质量管理体系，促进质量管理活动系统化、规范化，以确保所交付的图书馆自习教室管理系统能够满足规定的各项具体需求。
3.1.2介绍
本质量管理计划涵盖所有与图书馆自习教室系统设计开发有关的质量目标和具体措施。
涉及需求分析阶段、设计阶段、编码阶段、测试阶段、工程实施阶段。
项目生命周期各阶段的质量检查点：列出各阶段的质量检查计划表，包括责任人、检查时间、检查任务。
质量检查和确认技术：描述针对不同的对象而采用的特定的质量控制方法和技术及质量问题的级别和处理流程等。
3.2.质量管理
3.2.1.质量管理的角色和职责
质量控制是图书馆自习教室系统组每个成员的职责；
质量保证经理对整个项目的质量全权负责, 并签字确认；
项目经理负责任务的分配和监督项目进度，制定相关的工作计划和联系客户；
质量保证队伍负责制订、检查和督促本计划的实施，及时发现项目工作中的问题，并通过评审总结报告、项目周报等形式向各项目组成员汇报质量活动的结果；
项目功能小组各组长在每个软件开发生命周期阶段结束后，总结本模块的软件质量状况和质量目标的实现情况,以确保整个项目目标的实现。对质量目标应定期进行考核，以追求质量管理体系的持续改进；
流程检查人员负责通过检查文档审核开发各阶段是否可以通过；
测试人员负责对软件的质量和对需求实现的程度进行把关，并定期整理测试情况分析报告交项目经理、系统分析人员；
配置管理员负责有关软件配置项及项目各生命周期交付文档管理和变更控制工作；
图书馆自习教室系统管理人员负责反映质量要求，参与软件开发过程的质量控制，并监督本计划的执行情况。
3.2.2质量管理流程
3.2.2.1.交付文档质量监控流程
项目经理和质量保证团队在项目初期对项目交付文档的模板进行检查和审核，确保项目交付品的架构和内容大纲的完整性和正确性。
在项目进行过程中，质量保证团队、项目经理及各项目功能小组组长会分别对交付品进度和质量进行监控，确保在最后的项目完成阶段，图书馆对提交的交付文档能有满意的反馈。
3.2.2.2. 上线系统质量监控流程
对于上线系统的质量监控主要体现在软件配置管理和系统测试工作两方面。为了保证本项目的整体实施同业务和技术明细相一致，这方面的工作包含如下几个任务：
明确现状和期望之间的差异，以及测试软件可能存在的缺陷。通过测试，寻找系统功能性的不足。在测试结束之后判断软件死机带来的风险。
在测试汇报中对发现的缺陷进行分类和总结。测试应该针对容易出错的流程和应用组件进行。测试结果应该进行文档记录，描述软件运作的各种情况。
具体工作如下：
制定软件配置管理（SCM）策略和流程–根据最佳实践来制定SCM 策略和流程，包括源代码管理流程，开发管理流程和生产周转流程。
制定测试策略和方法–根据需求制定测试方法：明确测试阶段和环境需求、确定各个测试阶段的开始和结束准则、制定故障跟踪流程的测试标准、确定测试工具和配置管理程序、确定需要其他工作的支持。
准备测试计划和测试案例–对测试进行计划和准备：分析业务需求和技术明细、确定典型的逻辑场景、明确系统容量和压力点、编制测试脚本和环境、编制测试数据集。
进行系统测试–进行下列工作以保证满足功能和技术需求：测试环境就绪确认、执行测试脚本、分析测试结果，制定错误跟踪报告。
3.2.2.3.项目质量评审
图书馆自习教室系统质量监控将采用日常质量监控流程与定期质量评审制度。日常质量监控程序通过制定图书馆自习教室系统开发的统一的规范、流程、指南、模板等指导项目的开发过程，并监控这些流程和规范的执行情况，以确保所有交付品的质量。定期质量评审由质量保证经理发起，项目组相关负责人配合，对项目前一阶段的工作质量进行总结与评审，并将生成项目质量评审报告。
项目质量评审报告将根据各阶段质量检查点所应检查的内容作出质量上的评审。对在质量评审工作中发现的问题，将根据其性质、范围划分级别。相关人员以此为依据来确定缺陷修复的优先级，缺陷严重程度高的修复优先级也高。
项目质量评审报告将交由项目管理办公室讨论，质量保证经理与项目管理办公室将对项目质量评审报告中需要明显改善的质量问题作出具体地改进方案，以及时间上和人员上的安排。
3.3质量检查和确认技术
3.3.1工具和技术
项目初期必须根据项目实际情况明确质量管理的工具：配置管理工具、测试工具、其他质量管理工具
3.3.2管理配置
图书馆自习教室系统配备专人作为配置管理工程师，建立开发库、配置管理库；
产品库对设计开发各阶段的配置项进行配置管理；
每个配置项都有修改记录表，注明该配置项自创建以来每次修改的内容、时间和修改人；
每个配置项都有自己的版本号以及相应的命名规范，只要配置项的内容经批准发生改变，该文档的版本号数值就会做相应的升级；
所有的配置项都将保存在指定的服务器上，由配置管理工程师统一保管、定期备份；
3.3.3介质控制
为了保护计算机程序的物理媒体，以避免非法存取，意外损坏或自然老化，图书馆自习教室系统配备专人配置管理工程师，负责妥善管理、跟踪、存放和备份存放配置项的各类媒体。
3.3.4问题报告和纠正
在图书馆自习教室系统质量检查中出现问题时，遵循逐级上报的原则：
项目组成员级不能解决的上报到组长，由其协调解决；组长不能解决的上报到项目经理。各子系统开发组组长在每个软件开发生命周期阶段结束后，总结本子系统的软件质量状况和质量目标的实现情况，并填写《质量总结报告》。
项目经理每周整理一份项目状态报告，记录一周来项目的进展情况和出现的问题，如果这些问题还能被解决，将被移交到更高一层的领导者协调处理。必要时，对出现的问题将予以记录（如评审缺陷清单、遗留问题清单等），交配置管理工程师备案。质量管理组将对问题追踪进行监督，确保问题关闭。
对在质量检查工作中发现的问题，将根据其性质、范围和对软件的影响程度划分级别。相关人员以此为依据来确定缺陷修复的优先级：缺陷严重程度高的修复优先级也高；同理，回归
测试的优先级也依此确定。
4816
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
