团队作业3--需求改进&系统设计
| 这个作业属于哪个课程 | 信安1912-软件工程 |
|---|---|
| 这个作业要求在哪里 | 团队作业3 |
| 这个作业的目标 | 需求&原型改进+系统设计+Alpha任务分配计划 |
一、需求&原型改进
1.1 问题及修改
| 问题 | 修改 | |
|---|---|---|
| 1 | 对功能的描述不够清晰具体 | 对需求说明书和设计进行重置 |
| 2 | 团队任务计划不够清晰 | 重新审视项目规划，组织成员讨论后，明确了项目各阶段的需求 |
| 3 | 界面较复杂，应考虑用户需求 | 将UI简洁化，方便用户使用 |
| 4 | 在功能方面进一步考虑用户需求 | 新增产品逻辑分析 |
1.2 展现原型
手段：选取不同样本询问
| 身份 | 用户描述 | |
|---|---|---|
| 用户A | 学生 | 有时候老师布置的作业比较难，我需要在网上寻找资料，现在相关的途径一般是通过搜题软件搜索，需要每道都拍照。如果有你们这个软件，就不需要每题拍照了，而且也可以使用文字搜索，效率确实有所提高，我个人比较期待。 |
| 用户B | 教师 | 我讲习题课时，需要同学们把注意力聚焦在某题，此时可能需要这个软件帮助我分解试卷。平时我在网上下载的资料，也可以在这个软件的帮助下较快形成题库，否则我总是要把pdf的题目通过敲键盘得到，才能形成统一格式的卷子。 |
| 用户C | 学生 | 要学的科目很多，卷子也很多。如果有这个软件，我做错题归纳整理的时候应该会容易很多。我可以给试卷拍照，通过软件分解后把题目保存，老师讲完后再把试卷扔掉。这样下来，我的桌面就能整洁不少，不再试卷堆积成山了。 |
1.3 修改规格说明书
- 功能描述细化（修改）
- 产品逻辑分析（新增）
本产品应用场景较为广泛。以目前的团队技术支持以及时间而言，可以实现学习工具的版本。团队内部认为本产品仍有发展空间。在当今应试学习如此重要，且电子化、信息化不断普及的情况下，必然产生通过软件管理学习的需求。本产品即是大型学习软件的雏形，最终可以实现对用户个性化题库的构建，帮助用户应对考试。 - User Story（新增）
小江是一位考研人，他每天起早贪黑地学习，书与笔记堆满大半个桌面。
小江每天都会有许多错题，而他需要把其中有价值的题目记录下来。以前，小江总是把题目抄在本子上，再写上答案。等下次复习的时候，就把答案遮住，重新做一遍题目。然而，有些题目的题干很长，还需要画图，十分浪费时间。除此以外，错题的科目不同，所属的知识框架也不同。由于时间的原因，后面的错题无法与前面的错题更新在一起，导致错题的管理十分混乱，延长了小江遍历错题本的时间。
小江对此状况感到非常不满，直到某天，他看到了一个团队开发的产品：试卷分割助手。
此产品一定程度上解决了小江的困境。小江通过微信登录产品后，把试卷照片上传到产品，通过产品得到了各道题目的独立图片。他选取需要的题目，加上答案注释，然后放在对应科目的仓库里。凭借时间戳和命名的管理，小江在复习的时候可以很快的遍历某知识框架的错题，节省了很多时间。此产品好用且免费，小江给开发团队捐助了20元，通过行动表达了对Ta们的支持。 - 需求规格说明书（修改后）
1.4 功能分析的四个象限
| 外围功能 | 杀手功能 | |
|---|---|---|
| 必要需求 | 登录、注册 | 试题分割、文字提取 |
| 辅助需求 | 资料分享、转发 | 试卷分割 |
1.5 调整任务分解WBS及相应的项目进度计划
1.5.1 WBS图
1.5.2 项目进度计划
| 时间 | 任务 | 进度 |
|---|---|---|
| 第9周 | 1.团队组队、团队博客 | ✔ |
| 2.团队介绍、成员展示、角色分配、选题确定 | ✔ | |
| 第10周 | 1.需求规格说明书 | ✔ |
| 2.原型设计，队员估计任务难度并学习必要的技术 | ✔ | |
| 3.编码规范完成、平台环境搭建完成、初步架构搭建 | ✔ | |
| 第11周 | 1.原型改进（给目标用户展现原型，并进一步理解需求） | ✔ |
| 2.架构设计，WBS, 团队成员估计各自任务所需时间 | ✔ | |
| 3.测试计划 | ✔ | |
| 4.确定小程序界面设计 | ✔ | |
| 4.成员继续学习技术 | ✔ | |
| 第12、13周 | 1. 团队项目Alpha任务分配计划 | |
| 2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交**（预计时间为11.18-11.25 | ||
| ）** | ||
| 3.改进测试计划（预计时间11.19） | ||
| 第14周 | 1.用户反馈+测试计划改进 | |
| 2. 团队Alpha阶段个人总结 | ||
| 3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 | ||
| 第15周 | 1. 团队项目Alpha博客：事后分析 |
二、系统设计
2.1 设计摘要
2.1.1 设计摘要说明
| 前端页面 | 直接与用户打交道，与用户进行交互 |
|---|---|
| 后端系统 | 负责处理用户的请求，为用户提供其想要的数据 |
2.1.2 系统的架构设计说明
本系统主要采用的是MVC的设计模式
视图（View） 视图层能够实现数据有目的的显示，在视图中一般没有程序上的逻辑，为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。
控制器（Controller） 控制器起到不同层面间的组织作用，用于控制应用程序的流程，它处理事件并作出响应，“事件”包括用户的行为和数据模型上的改变。
模型层（Model）：“数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法，“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。
2.2 前端设计
与用户直接交互，将用户请求反馈到后端。（以微信小程序导航栏中每一项分解）
- 首页/启动页 index
- 功能页（包含试卷分割、试题分割页、ocr文字提取）spilt
- 个人界面 user
- 使用帮助 help
- 相关接口设计
2.3 后台设计
响应用户的请求，进行相关操作。（以各功能进行分解）
其中本系统共分为4部分：Faster-RCNN，试卷分割（将一张A3试卷分割成两张A4试卷作为Faster-RCNN的输入），试题分割，试题识别。
- 试卷分割 实现该功能的文件为split_into_two.py。
- 试题分割 该功能由Test_question_split.py文件实现。
- ocr文字提取
三、Alpha任务分配计划
3.1 人员分工
| 姓名 | 学号 | 团队分工 |
|---|---|---|
| 姜珺杨 | 3219005446 | 前端、UI、美工、文档编写 |
| 刘梓祥 | 3119005426 | 后台 |
| 周心怡 | 3219005452 | 前端、测试、文档编写 |
| 邱秀文 | 3219005450 | 前端、测试、文档编写 |
| 程雨秋 | 3219005444 | PM、测试、文档编写 |
3.2 待实现的功能项及任务认领
3.2.1 功能项
| 模块名称 | 优先级 |
|---|---|
| 试卷相关处理 | 高 |
| 用户模块 | 中 |
| 小程序界面 | 高 |
| 接口 | 高 |
| 云服务器/本地服务器 | 低 |
| 相关文档/博客 | 中 |
| 测试计划 | 中 |
3.2.2 任务认领及时间分解
| 功能名称 | 负责人 | 预计工时 | 优先级 |
|---|---|---|---|
| 试卷分割 | 刘梓祥 | 5h | 中 |
| 题目分割 | 刘梓祥 | 10h | 高 |
| ocr文本读取 | 刘梓祥 | 10h | 高 |
| 前后端接口 | 刘梓祥、姜珺杨 | 10h | 高 |
| 小程序总体界面设计 | 姜珺杨、程雨秋 | 2h | 中 |
| 用户界面 | 周心怡 | 3h | 中 |
| 功能界面 | 姜珺杨 | 10h | 高 |
| 首页 | 邱秀文 | 5h | 低 |
| 帮助界面 | 周心怡 | 5h | 低 |
| 相关文档编写 | 刘梓祥、姜珺杨、程雨秋、邱秀文、周心怡 | 10h | 中 |
| 博客编写 | 姜珺杨、周心怡、邱秀文 | 7h | 中 |
| 测试计划 | 程雨秋、周心怡 | 5h | 中 |
| 测试 | 姜珺杨、邱秀文 | 10h | 中 |
| 功能界面 |
3.3 甘特图
ps.由于对第四次作业上交时间估计错误 因此本图日期从day1开始延后两天）
四、测试计划
4.1 测试目的
此计划编写的目的是为系统能够达到与系统规格说明书所描述的功能一致，并且检验系统是否运行稳定。
4.2 测试范围
- 项目的可用性
- 系统的安全性
- 功能的完整性
- 数据的准确性
- 系统的稳定性
4.3 测试人员
姜珺杨、周心怡、程雨秋
4.4测试安排与进度
于冲刺Day4、Day6、Day7三天进行。(详见甘特图)
4.5测试环境
微信开发者工具自带模拟器及以上几位同学手机。
（覆盖安卓、ios手机及pad）