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 時間方面

根據程式進度進行不同的測試以及綜合測試。