1.需求&原型改进
1.1 给目标用户展示原型，并进一步沟通理解需求
①我们的目标用户是评分者用户
②思考用户痛点，描述使用场景。
场景一：对于唱歌，跳舞，表演，演讲，朗诵等文艺、文化类的比赛，需综合观众和评委的评分评选出冠军和给出相应的排名的比赛，观众用户投票给自己喜欢的选手，从主观程度投票，并不具有较强的客观性，从而直接影响比赛的排名，导致比赛结果存在争议的后果。
这个情景存在的痛点：观众用户主观性较强行为直接影响比赛结果、比赛结果存在争议。
场景二：对于一个唱歌比赛，从系统用户内筛选出此比赛相似度最高的权威性的评委用户，和对比赛具有较强专业性的观众用户。由他们根据选手比赛时的表现，给出专业性较强的评分结果，最后比赛结果争议几乎没有。
从这个场景中我们可以知道大家都接受了比赛的最后结果。
1.2 修改完善上周完成的《需求规格说明书》
①《需求规格说明书》coding地址：https://git.coding.net/Ssl_dhlg18/SIMsystem.git
②场景描述：用户甲认为2号选手表现较好，参照系统评分细则，音色音质方面音色清晰有质感，演唱完整。台风方面能很好得用肢体语言和表情诠释歌曲的感情。整体方面有较强的音乐表现力，有个人的情感感染力和个人风格魅力体现；但缺乏和观众互动表现。于是系统给出9分的高分，用户提交打分，完成打分任务。
1.3 功能的四个象限
1.4 任务分解WBS(Work Breakdown Structure)
Leangoo地址为：https://www.leangoo.com/kanban/board/go/2556649#
2.系统设计
2.1 系统的架构设计
系统采用Struts+Spring+Hibernate整合的框架实现的，但是模式依旧采取的是传统的MVC设计模式进行项目实现，详细分为：模型，视图，控制器其中模型的主要任务是进行业务数据和业务处理，视图是用户可以看到的界面，并与之交互，即JSP界面；而控制器主要的任务是负责接收从界面传过来的用户请求，并调用相应的模型类去处理这些请求,主要利用HTTP协议和后台进行交互。
系统架构图 1-1
用户系统总体E-R图 1-2
由上面的概念结构设计可得到数据库的关系模式，具体如下。(userForm)：用户表用户名：user_name数据类型：String；
账号：account数据类型：int；密码：password数据类型：String；用户类型：user_type数据类型：int；工作单位：work_unit数据类型：String；职务：duty数据类型：String。
测试计划
1.引言
1.1 项目背景
用于比赛中评委打分，便捷评分。
2.任务概要
2.1 测试范围：
活动管理，项目管理，用户管理，时间管理，启动比赛管理，评分管理，吐槽管理，排名管理。
2.2 测试目标：
先将小组成员以前写过的代码收集，进行测试。
2.3 广义上海包含测试需求分析：
测试的话，不仅仅需要精准度，还要尽量减少错误率。对代码的要求也要做到求精，并且测试必须伴随着项目的进行而进行。这样才能确保最大的成功和最少的错误。
3.测试策略
3.1 测试人员需求、分工
小组共同承担测试任务。
3.2 测试方法
手动测试。
3.3 工具引用及测试培训
内训
3.3 测试阶段计划
| 工作内容 | 人员安排 | 起止时间 |
| 活动管理、项目管理 | 罗建彪、宋非、罗远云 | 具体看进度 |
| 用户管理、时间管理 | 罗建彪、宋非、罗远云 | 具体看进度 |
| 启动比赛管理、评分管理 | 罗建彪、宋非、罗远云 | 具体看进度 |
| 吐槽管理、排名管理 | 罗建彪、宋非、罗远云 | 具体看进度 |
4.测试资源
4.1 测试人员要求：
有一定测试基础，对系统很熟悉。
5.风险评估
5.1 人力方面
三个臭皮匠顶个诸葛亮，组员三人共同担任测试人员。
5.2 时间方面
根据程序进度进行不同的测试以及综合测试。