1 需求&原型改进:
团队组成：
PM：齐爽爽（258）
小组成员：马帅（248），何健（267），蔡凯峰（285）
Git链接：https://github.com/WHUSE2017/C-team
改进博客：http://www.cnblogs.com/shuangshuangblog/p/7693711.html
2 需求规格说明书改进
上周规格说明书，缺少页面设计，系统设计书里面添加页面。
本周又进行小组会，又有所修改，考虑到后期用户很多，某活动可能很多人，于是，我们就按照某个时间和地点的活动，给参加的用户进行分组，相当于建立了一个临时群组，当申请加入时，群主同意后，发送站内同意消息，即加入活动成功。和群主联系，同时，也可以查看群成员信息，和任意一个成员联系。上周场景修改：
| 名字 | 西瓜 |
| 性别、年龄 | 女、20岁 |
|
职业 |
计算机院学生 |
| 收入 | 学生 |
| 知识层次和能力 | 大学 |
| 生活、工作情况 | 喜欢电子产品，喜欢旅游，喜欢交朋友 |
| 动机，目的，困难 | 游玩、交友、熟悉大武汉。困难：有时候自己有时间，朋友没有时间，自己一个人又不想出去。 |
| 用户偏好 | 想找到一起同行的大学生，男女不限。 |
| 用户比例 | 基本都是这样的人。 |
| 典型场景 | 在网上找小伙伴，然后一起出去玩。 |
| 典型描述 | 本网站提供相同计划行程的同学联系方式。 |
用户痛点是，有时间，自己时间和朋友时间不一致，但是又想出去玩，又觉得一个人出去玩没意思。不排斥和陌生同学一起溜达，有交新朋友的欲望。
1.背景：
（1）典型用户：西瓜、耗子等相同需求的用户
（2）用户的需求/迫切需要解决的问题
a.这周有闲暇时间，想去看电影，但是约身边同学和朋友都没有时间，在QQ微信和贴吧问了好长时间，却没有实质性回复；
b.快速找到在周六下午去看电影的人，地点可以随意，学校附近最好，武汉市内的其他电影院也可接受；
c.简单的输入，就能反馈给我信息，查看周末看电影的群组，然后选择我喜欢的群组，申请加入，同时可以选择同一群组的其他小伙伴，提前联系。
（3）假设：用户主页面发布和查询功能已经完成；
2.场景
西瓜这周想出去看电影，但是没有找到身边小伙伴，想找到一起去的同学。她先登录一起玩耍PC端，如果他设置了“记住密码”，会自动登录。
进去之后，页面上方，输入出发点（前期只在本校），活动类型，活动地址，活动时间（也可是其中的某个或者某几个）点击搜索，后在下面反馈出匹配的群组，点击详情，课显示同行者昵称、已经使用网站游玩次数、院系、自我介绍。当看到有意愿活动后，假设看中耗子发起的活动，即耗子是群主，点击申请加入按钮，申请加入，等待耗子同意；也可点击详情按钮，显示耗子及其他同行者联系方式：QQ、微信、手机号。自己选择一个方式联系。
当耗子同意并确认同行后，在APP里面点击确认。此次约伴成功。
在点击搜索后，如果没有满意活动，未点击确认同行，则在每天晚上7点，向用户邮箱发送推荐信息。用户也可以直接发布活动消息，发起活动。
如果搜索结果为空，则弹出提示框，“是否发布行程信息，方便找到同行伙伴！”
耗子要么每晚7点接收提示更新的信息，登录PC端查看，要么等待西瓜联系，要么自己主动登录查看目前群组的新情况。
3 系统设计
4 Alpha任务分配计划
4.1 Product Backlog
|
ID |
name |
important |
How to do? |
notes |
|
1 |
注册本系统 |
30 |
打开软件，进行注册，将有效信息保存在数据库 |
有消息提示 |
|
2 |
登录本系统 |
30 |
验证输入信息，跳转主页，保存用户信息 |
验证码等 |
|
3 |
查找活动 |
40 |
根据某几项输入，进行查询，反馈群组信息，以及成员信息 |
如果没有反馈，则说明没有类似活动，询问是否发起此活动 |
|
4 |
发起活动 |
30 |
输入详细时间地点，发起活动 |
|
|
5 |
查看群组成员信息 |
30 |
点击详情按钮，查看成员信息，基本信息及联系方式 |
|
|
6 |
查看自己活动记录 |
10 |
查看之前活动记录 |
|
|
7 |
修改个人信息 |
10 |
修改该用户在数据库中的表 |
|
|
8 |
活动评价 |
10 |
对此路线活动进行评价 |
|
|
9 |
小组成员评价 |
10 |
可选择的对小组其他成员进行评价 |
|
|
10 |
查看个人评价 |
10 |
查看其他用户对自己的评价 |
4.2 Sprint Backlog
、
4.3 甘特图
5 测试计划
因为本项目很小，所以测试，我们只做功能性测试，和一些简单错误处理，以及效能方面的测试。
（1）功能实现方面：
登录页面：
|
按钮 |
功能 |
|
登录 |
后台验证用户名和密码，跳转到用户主页 |
|
注册 |
跳转到注册页面 |
|
记住密码 |
记住密码，下次用户打开软件，课自动登录 |
注册页面：
|
按钮 |
功能 |
|
返回 |
返回到登录页面 |
|
确认 |
提交注册信息，写入user表，并返回注册信息，如果注册成功，则返回提示，并跳转到主页；如果没有注册成功，则返回提示信息。 |
主页面：
|
按钮 |
功能 |
|
注销 |
点击后进入登录界面，用户由登录状态转换为非登录状态 |
|
资料 |
点击后显示当前用户的个人资料，并可以对资料进行修改 |
|
消息 |
点击后可以查看站内消息 |
|
帮助 |
包含软件的使用文档和相关信息 |
|
搜索 |
填写用户需求后点击会显示相应的组团搜索结果 |
|
发布 |
点击后会将当前用户的需求发布出去 |
|
加入 |
点击后当前用户将加入相应的团体，成为里面的组员 |
|
详情 |
点击后会看到组团的详细信息 |
（2）输入错误提示
|
错误名称 |
解决办法 |
|
1.用户名和密码错误 |
提示输入错误，检查信息是否正确并返回 |
|
2.验证码输入错误 |
登录失败，请重新输入 |
|
3.账号注册为空或者已存在 |
若空提示错误，返回 若存在提示存在，返回 |
|
4.注册密码低于6位 |
提示低于6位信息并重新输入 |
|
5.邮箱输入格式不正确 |
提示输入格式不正确 |
|
6.手机号输入有误 |
提示输入有效手机号 |
|
7.新密码与确认新密码不同 |
提示新密码与确认新密码不同 |
|
8.提交信息失败 |
提示失败信息，并建议检查错误信息类型 |
（3）性能方面测试
根据老师博客推荐，我们决定使用VSTS对系统性能方面进行测试。（目前参数数值借鉴博客数据）
效能测试：在100个用户的情况下，产品搜索必须在3秒钟内返回结果。
负载测试：在2 000个用户的情况下，产品搜索必须在5秒钟内返回结果。
压力测试：在高峰压力（4 000个用户）持续48小时的情况下，产品搜索的返回时间必须保持稳定。系统不至于崩溃。
6 团队成员绩效评估方法
在进行简单讨论后，由于我们组分工相对简单：
前台界面：何健，占25%；
逻辑层：蔡凯峰，比较重要，所以占项目32%；
数据库设计与连接以及Alpha版展示与讲解：马帅，占28%；
文档编辑与组员协作：齐爽爽，15%。
算出基础得分，最后，再个人对自己评分，自己觉得自己任务完成度进行百分比评价，再基础得分*自评百分比。