需求&原型改进
0. 团队介绍
团队名称：121ComeOn
项目名称：个人博客项目
团队组成：
PM：黄金筱（107）
成员：王枫（031），刘烨（255），周明浩（277）
github地址：https://github.com/WHUSE2017/SW_HW4/
改进后需求规格说明文档地址：https://github.com/WHUSE2017/SW_HW4/blob/master/README.md
1. 课堂QA及对项目功能的修改
本次讨论主要在目标用户人群的选择上与各位老师和同学展开了讨论，课堂上的QA经筛选整理记录如下。
Q: 个人博客是为了跟什么产品区分。
A: 最大的区别是为了体现个性化，与博客园、CSDN等不同，我们去掉了大量的为了满足绝大多数用户而构造的冗余功能，取而代之的是个性化的界面以及更适合我们自生使用的功能。
Q: 是否是不对外发布的。
A: 目前是不对外发布，暂时是针对个人，普通用户同样作为用户群体作为游客访问我们的博客。
Q: 目标用户是哪些。
A: 个人博客目标用户是个人，也就是有需求的用户或者小组内成员，作为普通用户可以随时查看我们的博客。
Q: 如何向别人展示，跟博客园有什么区别。
A: 我们做的是一个针对自己的web应用程序，而博客园是一个以博客为基准的平台，博主可以在这个基础之上与其他博主沟通交流，主要是以学习交流为主。但是正因为有了这个平台，大家的框架界面都是一致的，而我们恰恰是瞄准了这一点，认为一个个性化的博客比起这个更实用我们自己。
Q: 个性化的功能提醒是通过什么方式，是否需要做成邮件等提醒。
A: 目前打算登陆后有提示，后期会根据需求修改。
Q: 有没有打算推广，或者想过在博客园的基础上推广，定位目标不一样导致了考虑一下。
A: 我们认为我们的项目并不需要让大众使用。
修改：对于上述问题我们在上一次作业的博客底部也和各位老师展开了讨论，最后我们决定在原有的基础上增加一类用户，他们经过博主的身份验证能够取得获取实时资讯的功能，并且我们重新定义了本项目服务的用户群体。
与目标用户沟通进一步理解需求：
我们对新构建的用户小志进行了沟通，小志同学作为我们博主熟知的人群最大的痛点在于无法方便地获取校内资讯。对此我们计划在经过认证之后，提高该类用户的权限，让其获得更多功能的使用权限。
原版本用户划分：
| 权限 | 用户名称 | 功能 |
|---|---|---|
| 低 | 游客 | 浏览、评论、分享等 |
| 高 | 个人博主 | 除游客功能外还具备管理博客、获取资讯等 |
改进后用户划分：
| 权限 | 用户名称 | 功能 |
|---|---|---|
| 低 | 游客 | 浏览、评论、分享等 |
| 中 | 合作者 | 除游客功能外还具有获取资讯功能 |
| 高 | 个人博主 | 除合作者功能外还具备管理博客、获取消息等功能 |
2. 完善需求规格说明书
初稿不足之处
初稿基本完成了包括原型设计、项目进度计划等功能。
具体改进
增加了一个新的用户等级，并修改了与之相对应的其他功能。
添加认证用户典型场景
添加认证页面
添加用户管理界面
场景举例
今天小周在知乎上逛了一下午，他发现知乎真是个好地方，有各种各样的大v分享知识和经验，还有很多段子手大v在认真的搞笑，晚上他还在线学习了机器学习的课程，这么东西要记下来真不是一件容易的事情，所以他登录了他的个人博客，把这些内容分门别类都记录了下来，还随手加上了标签，以便日后查阅。都整理好了以后他又写了一篇日记，他一直都有写日记的习惯，今天也不例外，但是日记这种事肯定不好意思让陌生人看到，所以小周把它的权限设置为私密。
然后他看到有网友小王评论了他前几天写的一篇技术博客，小王说他没有看的特别明白，但是有另外一种方法可以解决他这个问题，试之，效果很棒，于是他向留言网友表示感谢，并表示希望可以互相关注，以便日后可以互相帮助。
接着他查看了一下自己的ToDoList列表，发现忘记写数理统计的作业了，不过还好，截止日期是3天后，他想了想决定不写了，因为他的目光被实时资讯上面的小红点吸引了，打开看到武大计算机官网最新的公示通知和今日头条的新闻推送，点开看了看好像没什么有兴趣的内容，就关了。
最后他发现他的首页照片好久没有换了，就找了一个最近看的电影的截图画面传上去，看起来效果还真不错。
这边小王晚上无聊也打开了小周的博客，看看他今天有没有发什么新鲜事和有意思的技术，发现小周回复了他的留言，很开心，又浏览了一下今天的新博文，里面的段子很好笑，于是他输入了一下“搞笑”关键词，网页显示了搞笑分类下的博文。
3. 功能分析的四个象限
杀手功能：博主用户可以看到待办事项和实时资讯，已经身份认证的用户也可以看到实时资讯
外围功能：界面简洁、美观，符合用户习惯，在各个浏览器上运行良好
必要需求：普通博客所有基本功能如发布博客、评论博客、搜索博客、用户登录等等
辅助需求：可以按个人喜好修改主页巨幕图，添加标签和分类
4. 调整任务分解WBS及相应的项目进度计划
任务调整情况（插旗部分为修改地方）
项目进度调整
10.22 更新
添加部分
系统设计
Alpha任务分配
测试计划部分
系统设计
一、系统架构设计
1. 设计摘要说明
| 设计部分 | 功能需求 |
|---|---|
| 前端页面 | 与用户直接交互 |
| 后端系统 | 负责处理用户的请求，提供请求结果并将其返回 |
| 数据库 | 存储信息，完成数据相关操作 |
概念架构图：
前端页面运用ajax技术和后端进行交互，减少服务器刷新压力，在一定程度上使前后端分离。
2. 前端页面设计
本项目的其中一个需求是界面体现用户审美，以“美观”、“简洁”为原则实现一个优质的前端交互效果。通过 HTML + CSS + JavaScript结合，调用后端提供的 API，将页面展示给用户。
我们采用Axure作为原型设计工具，将原型的文件夹下载下来可以使用原型直接交互。原型链接：
3. 后端系统设计
博主后台活动
其他用户后台
二、数据库设计（+ER图）
Congif表
| 字段 | 类型 | 备注 |
|---|---|---|
| Key | String | |
| Value | String |
Category表
| 字段 | 类型 | 备注 |
|---|---|---|
| en_US | String | |
| zh_CN | String |
Comment表
| 字段 | 类型 | 备注 |
|---|---|---|
| Id | Int | Primary Key |
| Time | Int | |
| Name | String | |
| String | ||
| Text | text | |
| Blog_id | Int | Foreign key |
Pulish表
| 字段 | 类型 | 备注 |
|---|---|---|
| Id | Int | Primary Key |
| Time | Int | |
| Title | String | |
| Tag | String | |
| Text | text | |
| Class | String | |
| Open | bool | 是否公开 |
Message表
| 字段 | 类型 | 备注 |
|---|---|---|
| Id | Int | Primary Key |
| Title | String | |
| Read | Bool | |
| Url | String |
Verified_user表
| 字段 | 类型 | 备注 |
|---|---|---|
| Id | Int | Primary Key |
| Name | String | |
| Num | String | |
| School | String | |
| Information | Text | |
| Verified | Bool | 是否认证 |
ToDoList表
| 字段 | 类型 | 备注 |
|---|---|---|
| Id | Int | Primary Key |
| Title | String | |
| Date | Int | |
| Class | String | |
| Todo | Bool | 是否完成 |
Tag表
| 字段 | 类型 | 备注 |
|---|---|---|
| Id | Int | Primary Key |
| Name | String |
Class表
| 字段 | 类型 | 备注 |
|---|---|---|
| Id | Int | Primary Key |
| Name | String |
E-R图
博主ER图
认证用户ER图
普通用户ER图
Alpha任务分配
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项。
根据前期的需求分析和项目计划，对博客的功能进行优先级排序。
第一优先级：个人博客页面搭建，基本功能实现（登录、发布博文、搜索博文、评论博文、设置功能等）
第二优先级：个性化功能实现（待办事项、最新资讯、认证用户管理）
我们选择第一优先级的功能作为Alpha版本的待实现功能
对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。在PM的协助下，编码的同学对任务进行认领。
任务分解及认领
周明浩：确定代码规范，搭建前后台框架。确定前台页面框架，编写后台功能接口
刘烨：完成前台界面和Js
王枫：实现后台接口功能，完成数据库操作
黄金筱：根据实际情况对开发过程中发生的问题进行解决。
以甘特图的方式拟定迭代冲刺计划。
测试计划
测试计划和测试总纲主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责什么方面，各种资源在哪里。
1.引言
1.1 项目背景
本测试计划旨在说明系统测试的基本需求，界定测试范围，指导测试设计及边界，使测试人员能够更好地进行测试。
1.2 参考资料
本测试计划根据本项目的《需求规格说明文档》编写，参考需求文档示例中的“测试计划主要内容”相关内容。
1.3 有关项目人员组成
PM: 黄金筱（107）
开发人员：王枫（031），刘烨（255），周明浩（277）
测试人员：王枫（031），黄金筱（107），刘烨（255）,周明浩（277）
2.任务概述
2.1 测试范围
主要针对本项目的功能性需求和非功能性需求进行测试。
功能性需求：包括本项目的《需求规格说明文档》中的所有功能描述
非功能性需求：性能、可靠性、可维护性
3.测试策略
3.1 测试人员分工
| 测试人员 | 测试分工 |
|---|---|
| 刘烨 | 系统功能需求 |
| 王枫 | 系统可靠性 |
| 周明浩 | 系统性能 |
| 黄金筱 | 系统可维护性 |
3.2 测试方法
系统功能需求：黑盒测试+手动测试
系统非功能需求：白盒测试+临界测试+压力测试
3.3 测试阶段计划
由于本项目有两个迭代周期，所以准备在每个迭代周期结束前两天集中安排测试。
人员分工见上3.1，Alpha版本测试起止时间为2017.10.29-2017.10.30
4.测试资源
4.1 硬件资源需求
一台可联网的Windows电脑
一台可联网的Mac电脑
一部可联网的手机
4.2软件资源需求
具有可正常上网的浏览器
4.3测试人员需求
充分了解本项目的功能需求和非功能需求，有一定的软件测试知识基础，了解软件测试流程
5.风险评估
人力方面：充足
时间方面：一般，如不能按计划完成项目开发则可能会压缩测试时间
环境方面：暂无风险
资源方面：充足
6.团队成员绩效评估方法
6.1 团队贡献分分配规则
虽然这是本组成员的第一次合作，但是每位成员都各司其职，在提前沟通的情况下按照规定时间积极完成任务。经过讨论，我们一致同意平均分配团队贡献分。
6.2 贡献比
| 姓名 | 任务占比 | 完成度 | 评分 |
|---|---|---|---|
| 王枫 | 25% | 100% | 25 |
| 黄金筱 | 25% | 100% | 25 |
| 刘烨 | 25% | 100% | 25 |
| 周明浩 | 25% | 100% | 25 |
