團隊資訊
| 學号： | 姓名： | 本次部落格連結： |
| 041602209 | 黃毓明（臨時隊長） | https://www.cnblogs.com/mingsonic/p/9820702.html |
| 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 | 柯奇豪（原隊長） | https://www.cnblogs.com/S031602219/p/9822576.html |
| 031602603 | 陳超星 | https://www.cnblogs.com/ccxccx/p/9822698.html |
| 041602204 | 丁水源 | https://www.cnblogs.com/littlenorthwest/p/9820713.html |
團隊分工：
确定 alpha 版本需要做哪些事情
| 子產品序号 | 子產品名 | 子產品具體内容 |
| 1 | 現場簽到 | 1）實作基本的簽到功能 2）改進簽到功能實作優化 |
| 2 | 釋出通知 | 1）實作基本的通知功能 2）實作通知欄提醒功能 |
| 3 | 投票 | 1）實作基本投票功能 2）結果資料的分析與傳回 |
| 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 | · 估計這個任務需要多少時間 | ||
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | ||
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 60 | 80 |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 20 | |
| Reporting | 報告 | ||
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 120 | 165 |
Individual Score
具體評分細則：
| 姓名 | 貢獻分+基礎分=總得分（%） |
| 黃毓明 | 15+2=17 |
| 14+2=16 | |
| 11+2=13 | |
| 6+2=8 | |
| 蘇路明 | 13+2=15 |
| 陳瀚霖 | 7+2=9 |
| 胡展瑞 | 12+2=14 |
- 本隊“原隊長”給出的“課後”貢獻分評估
| 學号 | 名 | “課後”貢獻分 | 評價 |
|---|---|---|---|
| 031602219 | 奇豪(隊長) | 12.5% | 配置設定到的任務不難，算是正常操作，作為标準拿個基礎分 |
| 毓明 | 14.5% | 作為臨時隊長配置設定管理很好，各項任務也能盡職盡責 | |
| 水源 | 13.5% | 任務完成基本符合預期，但是用詞上還需要改進，例如ER圖中實體、屬性應該是名詞，“核實”以及某些實體的叫法都偏動作了些 | |
| 禮亮 | 任務完成基本符合預期，但是菱形分支上缺乏條件說明，部分箭頭訓示缺失，還望及時修改 | ||
| 超星 | 6.5% | 參照交換組的評定，似乎貢獻度不夠，需注意 | |
| 翔宇 | 參照交換組的評定，任務完成基本符合預期 | ||
| 志銘 | 10.5% | 兩人做的話似乎分攤的工作量略小，同時類圖的規範标準似乎沒有明确，"+"(public)、"-"(private)和"#"(protected)的差別 | |
| 熊 |
給出本次換隊環節的感受
- 本次實踐課中，我作為被換出的隊員加入到了其他組的項目程序中去。感覺他們的工作氛圍挺好的，臨時組長也很快就配置設定好了任務，大家各司其職，還是很有條理的。本以為臨時被換到陌生的團隊，會手忙腳亂，但是實際上情況還不錯。由于是和該小組原來的成員一起負責用例圖的，不清楚的地方可以及時問，不會因為不熟悉項目耽擱太多時間。感覺這個環節還是很有趣的。