| 學號： | 姓名： | 本次博客連接： |
| 041602209 | 黃毓明（臨時隊長） | |
| 061600236 | 楊禮亮 | http://www.cnblogs.com/YangLiLiang/p/9821082.html |
| 031601124 | 蔣熊 | https://www.cnblogs.com/jxdbky/p/9822930.html |
| 031601123 | 黃志銘 | http://www.cnblogs.com/zhimingfzu/p/9823028.html |
| 181600215 | 林翔宇 | https://www.cnblogs.com/Stella12/p/9823123.html |
| 031602219 | 柯奇豪（原隊長） | http://www.javashuo.com/article/p-mezkqnqe-dv.html |
| 031602603 | 陳超星 | https://www.cnblogs.com/ccxccx/p/9822698.html |
| 041602204 | 丁水源 | http://www.javashuo.com/article/p-wbsgrcgy-me.html |
團隊分工：html
肯定 alpha 版本須要作哪些事情前端
| 模塊序號 | 模塊名 | 模塊具體內容 |
| 1 | 現場簽到 | 1）實現基本的簽到功能數據庫 2）改進簽到功能實現優化小程序 |
| 2 | 發佈通知 | 1）實現基本的通知功能後端 2）實現通知欄提醒功能服務器 |
| 3 | 投票 | 1）實現基本投票功能工具 2）結果數據的分析與返回post |
| 4 | 想法收集 | 實現基本的問答功能 |
| 5 | 文章共享 | 1）實現基礎的文本編輯功能學習 2）完成簡單的文本選擇註釋功能測試 |
分工圖及todolist：
燃盡圖：
UML Design：
Part1：（部署圖）
• 這裏描述的是系統哪部分？
這裏主要說明的是部署問題
• 這部分要面臨什麼樣的問題？
服務器及數據庫的搭建，先後端交互等。
• 如下設計解決了哪些問題？
解決的問題：
前端客戶操做返回給後臺服務器，後端服務器依照前端操做給出相應返回值，從數據庫中調用相應的數據。
Part2：（類圖）
• 這裏描述的是系統哪部分？
使用WeEdit小程序的功能方面內容。
• 這部分要面臨什麼樣的問題？
1）項目模塊定義不夠清晰；
2）代碼未有統一格式；
• 如下設計解決了哪些問題？
解決的問題：
經過統一參數，方便後續先後端工做的配合。
Part 3：（狀態圖）
• 這裏描述的是系統哪部分？
這部分UML描述了發佈簽到、發佈共享文檔、發佈投票功能可能的狀態以及其中狀態的具體活動
• 這部分要面臨什麼樣的問題？
每一個具體狀態轉化細化得不夠徹底、在實現中還需更近一步改進
• 如下設計解決了哪些問題？
解決的問題：
體現了軟件須要的功能以及解決了軟件內部各功能實現的邏輯問題
Part 4：（用例圖）
• 這裏描述的是系統哪部分？
這裏是用戶在**WeEdit**系統上可以進行各項操做的部分，以及對操做內容的具體化。
• 這部分要面臨什麼樣的問題？
須要面臨功能如何按照用戶習慣排布的問題
• 如下設計解決了哪些問題？
解決的問題：
各個功能模塊之間直觀的邏輯聯繫
Part 5：（活動圖）
• 這裏描述的是系統哪部分？
描述了用戶具體選擇發佈通知，現場簽到，投票，想法收集和文章分享這幾大模塊。以及每一個模塊相對應的後續操做和結果。如進入現場簽到模塊後，能夠選擇簽到會議。
• 這部分要面臨什麼樣的問題？
不能防止同窗帶翹課的同窗的手機來簽到。
• 如下設計解決了哪些問題？
解決的問題：
解決了用戶權限的問題。不一樣權限的用戶進入不一樣的界面，進行不一樣的操做，不會發生權限混亂形成文件出現錯誤。
Part 6：（時序圖）
• 這裏描述的是系統哪部分？
展現對象之間交互的順序。它經過描述對象之間發送消息的時間順序顯示多個對象之間的動態協做。
• 這部分要面臨什麼樣的問題？
須要理清項目各模塊內的邏輯，按時間順序顯示各模塊內的動態協做。
• 如下設計解決了哪些問題？
解決的問題：
更加清晰地展現了各模塊內的交互邏輯、交互順序。
Part 7：（實體關係圖 ）
• 這裏描述的是系統哪部分？
主要描述的是系統的概念結構設計的部分。
• 這部分要面臨什麼樣的問題？
實體的決定、實體屬性的決定、實體之間的關係（包括了一對一，一對多，多對一，多對多）
• 如下設計解決了哪些問題？
解決的問題：
1） 分配了七個實體：參與者、發起者、投票、現場簽到、文章分享、想法收集、發佈通知
2） 各實體屬性的決定。具體屬性可參照「實體關係圖」。
3） 各實體之間的關係。具體實體之間的關係可參照「實體關係圖」
參與者
（E-R圖——參與者）
（E-R圖——發起者）
工具選擇：
Process ON
主要是基於方面才選擇這個工具的，之前的老師也有推薦過。
使用感覺:
簡單便攜，支持的UML也比較多，主要是網頁版，隨時隨地均可以使用，也比較容易上手，適合小團隊使用。
PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 10 | 15 |
| · Estimate | · 估計這個任務須要多少時間 | 10 | 10 |
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | 10 | 15 |
| · Design Spec | · 生成設計文檔 | 5 | 5 |
| · Design Review | · 設計複審 (和同事審覈設計文檔) | 5 | 5 |
| · Coding Standard | · 代碼規範 (爲目前的開發制定合適的規範) | 0 | 0 |
| · Design | · 具體設計 | 60 | 80 |
| · Coding | · 具體編碼 | 0 | 0 |
| · Code Review | · 代碼複審 | 0 | 0 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 10 | 20 |
| Reporting | 報告 | ||
| · Test Report | · 測試報告 | 0 | 0 |
| · Size Measurement | · 計算工做量 | 5 | 5 |
| · Postmortem & Process Improvement Plan | · 過後總結, 並提出過程改進計劃 | 5 | 10 |
| 合計 | 120 | 165 |
Individual Score
具體評分細則：
| 姓名 | 貢獻分+基礎分=總得分（%） |
| 黃毓明 | 15+2=17 |
| 丁水源 | 14+2=16 |
| 楊禮亮 | 11+2=13 |
| 蔣熊 | 6+2=8 |
| 黃志銘 | 6+2=8 |
| 蘇路明 | 13+2=15 |
| 陳瀚霖 | 7+2=9 |
| 胡展瑞 | 12+2=14 |
- 本隊「原隊長」給出的「課後」貢獻分評估
| 學號 | 名 | 「課後」貢獻分 | 評價 |
|---|---|---|---|
| 031602219 | 奇豪(隊長) | 12.5% | 分配到的任務不難，算是正常操做，做爲標準拿個基礎分 |
| 041602209 | 毓明 | 14.5% | 做爲臨時隊長分配管理很好，各項任務也能盡職盡責 |
| 041602204 | 水源 | 13.5% | 任務完成基本符合預期，可是用詞上還須要改進，例如ER圖中實體、屬性應該是名詞，「覈實」以及某些實體的叫法都偏動做了些 |
| 061600236 | 禮亮 | 13.5% | 任務完成基本符合預期，可是菱形分支上缺少條件說明，部分箭頭指示缺失，還望及時修改 |
| 031602603 | 超星 | 6.5% | 參照交換組的評定，彷佛貢獻度不夠，需注意 |
| 181600215 | 翔宇 | 12.5% | 參照交換組的評定，任務完成基本符合預期 |
| 031601123 | 志銘 | 10.5% | 兩人作的話彷佛分攤的工做量略小，同時類圖的規範標準彷佛沒有明確，"+"(public)、"-"(private)和"#"(protected)的區別 |
| 031601124 | 熊 | 10.5% | 兩人作的話彷佛分攤的工做量略小，同時類圖的規範標準彷佛沒有明確，"+"(public)、"-"(private)和"#"(protected)的區別 |