一、需求&原型改进
1. 需求改进
针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改
问题1：你们的用户量还可以进行修改，如果真正做出来的话，你们的用户量还可以再提高很多。
修改1：我们将用户量进行更改，从初期合作对象为院内社团、学生组织，后期为广州大学城高校的各个社团、学生组织。
问题2：上周的需求规格说明书不够完善
修改2：对上周的需求规格说明书进行了进一步的补充和完善
2. 修改说明书
修改完善上周提交的需求规格说明书
（1）项目功能修改
网页端（管理端）：
- 账号注册，需填写社团信息；
- 编辑所属社团简介、部门信息；
- 上传照片至社团相册；
- 发布招新信息；
- 编辑、发布通知；
- 查看、修改、删除报名人员的状态。
小程序端（学生端）：
- 账号注册，需填写个人信息；
- 查看社团的信息；
- 报名社团，填写报名表；
- 查看招新情况进度；
- 接受通知。
（2）预期的用户数量
招新通第一版开发测试完成后，我们将与学院内各个社团、学生组织合作，预计的用户量为学院内大一级的学生，预计人数为1,000到1,200人。
伴随着合作社团的增加，产品升级迭代，我们将于广州大学城各高校的社团、学生组织合作，用户量预计将达到10,000到50,000人。
（3）应用场景设计
家明是一名刚进大学的大学生，想要在大学中创出自己的一片天地。家明在师兄师姐的接待下对学校有了一个大体的了解，但当他面对“百团大战”时，还是不敢进到人群中向师兄师姐咨询。他看到最外面的社团有贴小程序的二维码，于是他打开微信扫一扫，发现在小程序上可以看到众多社团的介绍，还可以对师兄师姐进行提问，甚至于还可以报名。家明最后在小程序上对自己感兴趣的社团都查阅、询问了一番，最后选择报名了羽毛球协会、创业俱乐部这两个社团。
3.功能分析
参考《构建之法》5节功能的定位和优先级，给出功能分析的四个象限
| 外围功能 | 杀手功能 | |
|---|---|---|
| 必须要求 | 通过小程序浏览社团 | 通过小程序进行招新报名、查看面试进度 通过网页对招新人员信息进行增删查改 |
| 辅助要求 | 界面跳转、美化 | - |
4. 调整WBS及计划
根据修改后的需求，调整任务分解WBS及相应的项目进度计划
二、系统设计
1. 总体设计
2. 数据库设计
（1）管理端用户
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| user_name | varchar | |
| pass_word | varchar | |
| stu_id | varchar | 学号 |
| pho_num | varchar |
（2）学生端用户
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| user_name | varchar | |
| pass_word | varchar | |
| stu_id | varchar | 学号 |
| pho_num | varchar | |
| college | varchar | |
| stu_class | varchar | |
| mailbox | varchar | |
| school | varchar |
3.社团设计
| 列名 | 类型 | 备注 |
|---|---|---|
| id | int | 主键 |
| club_name | varchar | |
| club_desc | longtext | |
| Amin_id | int | 外键，级联管理端用户id |
| school | varchar |
三、Alpha任务分配计划
1. Product Backlog
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项。
| Product Backlog | Sprint Backlog |
|---|---|
| 用户模块 | 登录注册，个人信息、社团信息填写 |
| 首页模块 | 浏览、报名社团 |
| 通知模块 | 发布通知（网页），接受通知（小程序） |
2. Sprint Backlog
对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。在PM的协助下，编码的同学对任务进行认领。
| 任务 | 负责人 | 开始日期 | 结束日期 | 预计工时 |
|---|---|---|---|---|
| Alpha版本 | ||||
| 数据库 | 辜仰淦 | 2020年5月15日 | 2020年5月23日 | 8h |
| 建立数据库 | 辜仰淦 | 2020年5月15日 | 2020年5月17日 | 2h |
| 实现基本操作 | 辜仰淦 | 2020年5月18日 | 2020年5月23日 | 6h |
| 前端页面（小程序） | 陈余、姜达成 | 2020年5月15日 | 2020年5月25日 | 10h |
| 首页 | 陈余 | 2020年5月15日 | 2020年5月23日 | 3h |
| 发现 | 陈余 | 2020年5月15日 | 2020年5月23日 | 3h |
| 个人信息 | 陈余 | 2020年5月15日 | 2020年5月23日 | 2h |
| 通知 | 姜达成 | 2020年5月24日 | 2020年5月25日 | 2h |
| 反馈与建议 | 陈余 | 2020年5月24日 | 2020年5月25日 | 2h |
| 设置 | 陈余 | 2020年5月24日 | 2020年5月25日 | 2h |
| 前端页面（网页） | 郭奕材、王煜墉 | 2020年5月15日 | 2020年5月25日 | 18h |
| 社团信息 | 郭奕材 | 2020年5月15日 | 2020年5月25日 | 10h |
| 发布通知 | 2020年5月15日 | 2020年5月25日 | 2h | |
| 报名人员信息浏览 | 王煜墉 | 2020年5月15日 | 2020年5月25日 | 10h |
| UI设计（小程序） | 刘婉儿 | 2020年5月15日 | 2020年5月20日 | - |
| UI设计（网页） | 刘婉儿 | 2020年5月15日 | 2020年5月20日 | - |
| 测试总结 | 郭奕材、陈余、辜仰淦、王煜墉 | 2020年5月26日 | 2020年5月28日 | - |
| 测试 | 2020年5月26日 | 2020年5月28日 | - | |
| 总结 | 2020年5月26日 | 2020年5月28日 | - |
3. 以甘特图的方式拟定迭代冲刺计划。
四、测试计划
1.测试术语
黑盒测试，功能测试，测试项，严重性
性能测试（Performance Testing）：
在一定负载情况下，系统响应时间、搜索筛选结果等性能是否满足用户特定的性能需求。
负载测试（Load Testing）：
在一定的软甲、硬件及网络环境下，在不同虚拟用户数量的情况下进行一种或者多种业务，测试服务器的性能指标是否在用户要求的范围内，用于确定系统所能承受的最大用户数、最大有效用户数以及不同用户数下的系统响应时间和服务器的资源利用率
压力/强度测试（Stress Testing）：
在一定软件、硬件及网络环境下，模拟大量的虚拟用户想服务器产生负载, 使服务器的资源处于极限状态下并长时间连续运行,目的是用来测试服务器高负载情况下是否能够稳定工作。
配置测试（Configuration Testing）：
在一定的软件，硬件及网络环境下, 在数据库中构造不同数量级别的数据记录,运行一种或多种业务,在一定虚拟用户数量的情况下,获取不同配置的性能指标,由于选择最佳的设备及参数配置。通过配置测试可以将性能缺陷放大,方便定位瓶颈。
2.测试人员
郭奕材、辜仰淦、王煜墉、陈余
3.任务概述
测试范围
小程序、网页端的所有功能
| 测试类型 | 是否完成测试 | 测试优先级 | 说明 |
|---|---|---|---|
| 注册账号 | * | 学生、社团负责人注册账号时使用的信息是否能通过 | |
| token测试 | 中等 | 检查前端是否能正常接收并发送token认证，服务端能否接收并解析token | |
| 进入网站 | 高级 | 通过发布的链接是否能进入网站 | |
| 修改个人信息 | 中等 | 学生、社团负责人在修改个人信息时，是否检测敏感字符 | |
| 数据库测试 | 低 | 数据信息是否一致：用户提交的信息是否正确，数据输出错误：主要由网络或程序本身设计问题等引起 |
压力测试： 测试系统的限制和故障恢复能力,即测试web应用
系统会不会崩溃，在什么情况下会崩溃。
测试的区域包括表单、登陆和信息传输页面等
测试目标
所有功能均能正常实现，能应对多用户需求
测试用例编写
4.测试策略
测试人员需求、分工
郭奕材、陈余：用户测试
辜仰淦：性能测试
王煜墉：压力测试
测试方法
手动测试、黑盒测试
工具引用及测试培训
手动，内训
测试阶段计划
（工作内容、人员安排、起止时间等）
测试停止及恢复条件
测试停止条件：开发人员需要更改代码
恢复条件：确认代码修改无误
测试文档及缺陷提交管理等
在每次做完测试后都要记录并且上传
测试环境
Windows系统、电信移动网
5.测试资源
硬件资源需求
计算机、安卓手机、苹果手机
软件资源需求
谷歌浏览器、微信、sql server/my sql
测试环境需求
移动网络或WIFI网络
测试人员需求
用户测试：郭奕材、陈余
性能测试：辜仰淦
压力测试：王煜墉
6.风险评估
人力方面；
人力充足
时间方面；
时间充足，当一个功能开发完成后，就开始测试，以节约时间
环境方面；
缺少对Linux浏览器环境的测试
资源方面
无
部门合作方面
测试人员随时报告测试结果给开发人员，开发人员根据报告进行代码修改