需求&原型改進
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 |
Category表
| en_US | ||
| zh_CN |
Comment表
| Id | Int | Primary Key |
| Time | ||
| Name | ||
| Text | text | |
| Blog_id | Foreign key |
Pulish表
| Title | ||
| Tag | ||
| Class | ||
| Open | bool | 是否公開 |
Message表
| Read | Bool | |
| Url |
Verified_user表
| Num | ||
| School | ||
| Information | ||
| Verified | 是否認證 |
ToDoList表
| Date | ||
| Todo | 是否完成 |
Tag表
Class表
E-R圖
部落客ER圖
認證使用者ER圖
普通使用者ER圖
依據項目組能提供的總時間、功能子產品的優先級以及子產品之間的依賴關系，在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 | |