团队作业3--需求改进&系统设计
| 这个作业属于哪个课程 | 软件工程 |
|---|---|
| 作业要求 | 团队作业3--需求改进&系统设计 |
| 作业目标 | 需求&原型改进、系统设计、Alpha任务分配计划、测试计划 |
1. 需求&原型改进
1.1 针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改
问题1：是否适应所提出的应用场景？
修改1：上次课堂讨论中意识到仅仅依靠个人的自觉是完全不能保证预定的有效性的，对于所举的食堂占座的例子并不能很好的规划方案并适应现实场景，所以本项目将针对图书馆这个具体使用场景进行设计。
问题2：如何防止已预定的座位被其他人占座？
修改2：理想情况下应该是去往图书馆学习的学生都需要下载这款app，然后在上面在线查看并预定座位等。如果产生座位纠纷，可参考下图中第一段话解决。
问题3：预定了座位后长时间不在怎么办？
修改3：增加了一个信用机制，出现以上情况可由热心同学向管理员检举或者管理员不定时巡查清理，发现以上情况就参考上图处理。
题外话
其实笔者本人现任图书馆助管，进馆以来目睹了太多因为占座产生的读者与读者、读者与管理员、读者与老师之间的矛盾纠纷，直到现在也是由于种种原因没能彻底解决这个占座问题。当初团队选题的时候笔者确有私心，希望能给图书馆解决此问题的一个新的方向。在开始这个项目以来，笔者在服务总台会积极收集读者反馈的关于占座的意见与建议（下面的场景刻画中的C用户也是以一部分读者为原型，还有一种暂离座位的情况等之后有余力再对系统进行改进，问题2、3也是基于读者反馈），同时与一众管理员进行讨论，为开发改良本项目做准备。
本文档仅供本次开发项目的开发人员进行参考。
1.2 场景刻画
用户A：新生；
用户B：偶尔到图书馆学习的老生；
用户C：经常泡图书馆的考研/考公人；
场景一： A：初踏入校园，想要快速融入校园生活，为了卷死舍友，想提前到图书馆挑个好位置，但是图书馆好大好多层好多位置，走着走着就迷路了……。
解决方案：设有图书馆每层的座位预览图，可以清晰地看到每一层的作为分布及占用情况。
场景二：B：只是平时有空偶尔心血来潮到图书馆学习……
解决方案：提供座位在线预定功能的同时可以查看座位的预定情况；
场景三：C: 常年在图书馆，座位就是家，书本高高摞一沓……
解决方案：提供长期订位功能，不是单纯的订几节课的时间，但还是根据信用机制处理作为资源。
1.3 《构建之法》5节功能的定位和优先级
| 外围功能 | 杀手功能 | |
|---|---|---|
| 必要需求 | (第二象限)拥有良好的的用户交互界面和用户安全功能 | (第一象限)在线座位预定 |
| 辅助需求 | (第三象限)查看自己的到馆次数及在馆时长 | (第四象限)预定凭证 |
1.4 根据修改后的需求，调整任务分解WBS及相应的项目进度计划
* 调节后的任务分解WBS
| 分解功能名称 | 负责人 |
|---|---|
| 登录注册功能设计 | 刘栋濠 |
| 用户管理模块 | 刘栋濠 |
| 座位设定模块 | 刘栋濠 |
| 预定模块 | 杨伊辙 |
| 查询模块 | 杨伊辙 |
| 信用机制 | 肖丽萍 |
| 统计模块 | 杨伊辙 |
* 项目进度计划
| 时间 | 完成模块 | 完成情况 |
|---|---|---|
| 第9周 | 项目搭建，分好模块，利用easymock和eolinker完成好模拟数据 | 已完成 |
| 第10、11、12周 | 1.团队项目 Alpha 任务分配计划 | 已完成 |
| 2.连续7天的 Alpha 敏捷冲刺，7篇每日 Scrum Meeting 博客+代码提交 | 待办 | |
| 3.开始各模块并行开发 | 待办 | |
| 第13周 | 对接接口 | 待办 |
| 第114周 | 1.打包测试 | 待办 |
| 2.用户反馈+测试计划改进 | 待办 | |
| 3.团队 Alpha 阶段个人总结 | 待办 | |
| 4.团队项目 Alpha 博客：发布说明、测试报告、展示博客、项目管理、事后分析 | 待办 |
2. 系统设计
2.1 系统架构图
2.2 数据库设计
2.2.1 ER图
2.2.2 数据库架构图
3. Alpha任务分配计划
3.1 待实现的功能项
| 功能描述 | 优先级 |
|---|---|
| 座位模块 | 中 |
| 用户模块 | 高 |
| 信用模块 | 中 |
3.2 待实现功能项分解
| 分解功能名称 | 负责人 |
|---|---|
| 登录注册功能设计 | 刘栋濠 |
| 用户管理模块 | 刘栋濠 |
| 座位设定模块 | 刘栋濠 |
| 预定模块 | 杨伊辙 |
| 查询模块 | 杨伊辙 |
| 信用机制 | 肖丽萍 |
| 统计模块 | 杨伊辙 |
3.3 甘特图
4. 测试计划
4.1 测试总纲
由于本项目为一个图书馆在线预定座位app，需要测试点大概如下：
-
单元测试：确保各个模块抽象且可用。由于编程这个任务由多位成员共同完成，在 commit 前各成员需要做好单元测试，确保自己代码功能正常；封装好自己函数功能接口，确保其他成员能够轻易调用。
-
功能测试：确保系统正常运行，满足正常业务。一个聊天系统是否受欢迎挺大程度上取决于系统是否方便，能否满足人们的需求，因此我们需要通过对系统实现的功能进行测试，主要通过进行正常的使用以及模拟可能出现的特殊情况测试系统功能的完备性以及健壮性。
-
兼容测试：主要测试前端页面能否适配不同的安卓系统、可视化界面是否美观。
-
压力测试：app正式上线前需要进行压力测试，确保正式上线时不会有崩溃、卡顿等现象。
4.2 测试日程
| 测试内容 | 测试时间 | 测试人员 |
|---|---|---|
| 单元测试 | 开发全过程 | 杨伊辙、刘栋濠 |
| 功能测试 | 上线前两周 | all |
| 兼容测试 | 上线前两周 | all |
| 压力测试 | 上线前一周 | all |
4.3 质量目标
-
通过单元测试，开发人员能实现每个功能并封装好代码，确保项目按计划进行
-
通过功能测试，确保系统能够正常运行，满足正常业务，解决一些已知 bug
-
通过兼容测试，能够在 安卓系统使用
-
通过压力测试，在测试版本能够支持100人同时在线
4.4 测试资源
-
测试人员：项目成员
-
测试环境：安卓
