团队作业3--需求改进&系统设计
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/gdgy/Networkengineering1834 |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/gdgy/Networkengineering1834/homework/11151 |
| 这个作业的目标 | 对修改选题及需求进行修改，给出系统的架构设计 |
一、博文内容
- [Product Backlog](#Product Backlog)
- [Sprint Backlog](#Sprint Backlog)
二、需求&原型改进
需求改进
针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改
Q&A1
问题1：面向的用户范围还可以再扩大
修改1：我们将用户量进行更改，从初期面向对象为学校社团、学生组织，后期为广州大学城高校的各个社团、学生组织甚至可以用于商业领域。
Q&A2
问题2：需求规格说明书不够完善
修改2：对上周的需求规格说明书进行了进一步的补充和完善
修改说明书
补充完善上周提交的需求规格说明书
项目功能修改
| 功能 | 详细描述 |
|---|---|
| 登录功能 | 面试官用内置的账号密码（一开始是面向学习社团的，所以默认都是学生学号）进行登录，增加可退出登录的功能 |
| 面试官设置 | 面试官进入系统之后要填写自己的组别等相关信息，方便分类，无新增 |
| 学生列表 | 展示不同组别的所有面试者信息，新增可查看选中某一个学生的信息 |
| 面试队列 | 展示当前正在面试的面试者的信息以及可以对其进行详细评价，还有叫号功能，新增面试过程中如果通过面试有发短信的功能 |
预期的用户数量
面试招新系统第一版开发测试完成后，我们将与学校社团、学生组织合作，预计的用户量为学校内大一、大二级的学生，预计人数为2,000到2,200人。
伴随着合作着的增加，产品升级迭代，我们将与广州大学城各高校的社团、学生组织合作，用户量预计将达到10,000到50,000人。
应用场景设计
小红是某个社团的部长，今年她需要为自己的部门招聘一些大一新生，但是由于报名人数众多，她正为面试时如何记录和安排人员而苦恼。但是，有了这个系统，小红可以轻松在这个系统上面看到当前的面试队列和面试者的信息，同时，还能在这个系统上及时记录面试者的评价，提高了她面试的效率。
功能分析
参考《构建之法》5节功能的定位和优先级，给出功能分析的四个象限
| 外围功能 | 杀手功能 | |
|---|---|---|
| 必须要求 | 通过发短信来告知当前面试进度 | 四个功能，登录、面试官设置、学生列表和面试队列 |
| 辅助要求 | 界面跳转、美化 |
调整WBS及计划
根据修改后的需求，调整任务分解WBS及相应的项目进度计划
三、系统设计
总体设计
数据库设计
面试队列设计
queue表
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| student_id | int | 学生id |
| queue_base_id | int | 队伍id |
| order_count | int | 排队序号 |
| interviewed | int | 是否已面试 |
| group_id | int | 面试小组id |
| introduction | varchar | 面试通知内容 |
| submit_time | datetime | 提交时间 |
queue_base表
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| date | varchar | 时间（yyyy-MM-dd） |
| direction | int | 方向 |
| status | int | 对应状态 |
| total_count | int | 总开放限额 |
| queue_count | int | 队伍长度限额 |
面试点评设计
interview表
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| student_id | int | |
| administrator_id | int | |
| comment | varchar | |
| timestamp | datetime |
用户设计
administrator表
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| username | varchar | 用户名 |
| password | varchar | 密码 |
| name | varchar | 面试官人名 |
| group_id | int | 面试组 |
| direction | int | 方向 |
student表
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| name | varchar | 姓名 |
| school_id | varchar | 学号 |
| institute | varchar | 学院 |
| major | varchar | 专业年级 |
| sex | int | 性别（0-男、1-女） |
| phone | varchar | 手机号码 |
| varchar | 邮箱 | |
| introduction | varchar | 自我介绍 |
| direction | int | 方向 |
| skill | varchar | 技能经验 |
| know | varchar | 对该组织的认识 |
| ticket | varchar | 凭证 |
| timestamp | datetime | 报名时间 |
| status | int | 状态 |
| open_id | varchar | 微信id |
| scene | varchar | 报名成功后返回的二维码图片scene带参 |
| wechat_introduction | varchar | 小程序页面说明 |
student_list表
| 列名 | 类型 | 备注 |
|---|---|---|
| xh | varchar | 主键 |
| name | varchar |
ER图
四、Alpha任务分配计划
Product Backlog
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项。
| Product Backlog | Sprint Backlog |
|---|---|
| 用户模块 | 登录注册，个人信息填写、管理员权限管理 |
| 审批模块 | 浏览、报名社团，面试官审批 |
| 通知模块 | 发布通知（网页），接受通知（小程序） |
Sprint Backlog
对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。在PM的协助下，编码的同学对任务进行认领。
| 任务 | 负责人 | 开始日期 | 结束日期 | 预计工时 |
|---|---|---|---|---|
| Alpha版本 | ||||
| 拟定数据库结构 | 陈诒祺 | 2020年11月5日 | 2020年11月7日 | 8h |
| 建立数据库 | 曾肖宇 | 2020年11月7日 | 2020年11月8日 | 2h |
| 实现权限管理 | 曾肖宇 | 2020年11月7日 | 2020年11月8日 | 4h |
| 实现审批、通知功能 | 陈诒祺 | 2020年11月9日 | 2020年11月11日 | 6h |
| 前端页面（小程序） | 曾曼青 | 2020年11月5日 | 2020年11月7日 | 4h |
| 个人信息 | 曾曼青 | 2020年11月5日 | 2020年11月6日 | 2h |
| 接收、确认通知 | 曾曼青 | 2020年11月6日 | 2020年11月7日 | 2h |
| 前端页面（网页） | 曾曼青、邓婧汐 | 2020年11月5日 | 2020年11月11日 | 22h |
| 社团信息 | 邓婧汐 | 2020年11月5日 | 2020年11月7日 | 10h |
| 发布通知 | 曾曼青 | 2020年11月8日 | 2020年11月8日 | 2h |
| 报名人员信息浏览 | 曾曼青 | 2020年11月9日 | 2020年11月10日 | 5h |
| 面试人员审批 | 曾曼青 | 2020年11月10日 | 2020年11月11日 | 5h |
| UI设计（小程序） | 邓婧汐 | 2020年11月5日 | 2020年11月6日 | 4h |
| UI设计（网页） | 邓婧汐 | 2020年11月6日 | 2020年11月7日 | 4h |
| 测试总结 | 陈诒祺、曾肖宇、曾曼青、邓婧汐 | 2020年11月20日 | 2020年11月24日 | - |
| 测试 | 2020年11月21日 | 2020年11月22日 | - | |
| 总结 | 2020年11月23日 | 2020年11月24日 | - |
五、测试计划
测试术语
黑盒测试，功能测试，测试项，严重性
性能测试(Performance Testing)
在一定负载情况下，系统响应时间、搜索筛选结果等性能是否满足用户特定的性能需求。
负载测试(Load Testing)
在一定的软甲、硬件及网络环境下，在不同虚拟用户数量的情况下进行一种或者多种业务，测试服务器的性能指标是否在用户要求的范围内，用于确定系统所能承受的最大用户数、最大有效用户数以及不同用户数下的系统响应时间和服务器的资源利用率。
压力/强度测试(Stress Testing)
在一定软件、硬件及网络环境下，模拟大量的虚拟用户想服务器产生负载, 使服务器的资源处于极限状态下并长时间连续运行,目的是用来测试服务器高负载情况下是否能够稳定工作。
配置测试(Configuration Testing)
在一定的软件，硬件及网络环境下, 在数据库中构造不同数量级别的数据记录,运行一种或多种业务,在一定虚拟用户数量的情况下,获取不同配置的性能指标,由于选择最佳的设备及参数配置。通过配置测试可以将性能缺陷放大,方便定位瓶颈。
测试人员
曾曼青，曾肖宇，陈诒祺，邓婧汐
任务概述
测试范围
小程序、网页端的所有功能
| 测试类型 | 是否完成测试 | 测试优先级 | 说明 |
|---|---|---|---|
| 注册账号 | 最高级 | 学生、社团负责人注册账号时使用的信息是否能通过 | |
| token测试 | 中等 | 检查前端是否能正常接收并发送token认证，服务端能否接收并解析token | |
| 进入网站 | 高级 | 通过发布的链接是否能进入网站 | |
| 修改个人信息 | 中等 | 学生、社团负责人在修改个人信息时，是否检测敏感字符 | |
| 数据库测试 | 低 | 数据信息是否一致：用户提交的信息是否正确，数据输出错误：主要由网络或程序本身设计问题等引起 |
压力测试
测试系统的限制和故障恢复能力,即测试web应用
系统会不会崩溃，在什么情况下会崩溃。
测试的区域包括表单、登陆和信息传输页面等
测试目标
所有功能均能正常实现，能应对多用户需求
测试用例编写
测试策略
测试方法
手动测试、黑盒测试
工具引用及测试培训
手动，内训
测试停止及恢复条件
测试停止条件：开发人员需要更改代码
恢复条件：确认代码修改无误
测试文档及缺陷提交管理等
在每次做完测试后都要记录并且上传
测试环境
Windows系统、电信移动网
测试资源
硬件资源需求
计算机、安卓手机、苹果手机
软件资源需求
谷歌浏览器、微信、sql server/my sql
测试环境需求
移动网络或WIFI网络
测试风险评估
人力方面
人力充足
时间方面
时间充足，当一个功能开发完成后，就开始测试，以节约时间
环境方面
缺少对Linux浏览器环境的测试
资源方面
无
部门合作方面
测试人员随时报告测试结果给开发人员，开发人员根据报告进行代码修改
