Team informationhtml
Division of labor前端
| 模塊序號 |
模塊名 |
模塊具體內容 |
| 1 |
現場簽到 |
1）實現基本的簽到功能數據庫 2）改進簽到功能實現優化小程序 |
| 2 |
發佈通知 |
1）實現基本的通知功能後端 2）實現通知欄提醒功能服務器 |
| 3 |
投票 |
1）實現基本投票功能markdown 2）結果數據的分析與返回工具 |
| 4 |
想法收集 |
實現基本的問答功能 |
| 5 |
文章共享 |
1）實現基礎的文本編輯功能post 2）完成簡單的文本選擇註釋功能學習 |
-
- 燃盡圖
UML Design
Part1：（部署圖）
• 這裏描述的是系統哪部分？
這裏主要說明的是部署問題
• 這部分要面臨什麼樣的問題？
服務器及數據庫的搭建，先後端交互等。
• 如下設計解決了哪些問題？
解決的問題：
前端客戶操做返回給後臺服務器，後端服務器依照前端操做給出相應返回值，從數據庫中調用相應的數據。
Part2：（類圖）
• 這裏描述的是系統哪部分？
使用WeEdit小程序的功能方面內容。
• 這部分要面臨什麼樣的問題？
1）項目模塊定義不夠清晰；
2）代碼未有統一格式；
• 如下設計解決了哪些問題？
解決的問題：
經過統一參數，方便後續先後端工做的配合。
Part 3：（狀態圖）
• 這裏描述的是系統哪部分？
這部分UML描述了發佈簽到、發佈共享文檔、發佈投票功能可能的狀態以及其中狀態的具體活動
• 這部分要面臨什麼樣的問題？
每一個具體狀態轉化細化得不夠徹底、在實現中還需更近一步改進
• 如下設計解決了哪些問題？
解決的問題：
體現了軟件須要的功能以及解決了軟件內部各功能實現的邏輯問題
Part 4：（用例圖）
• 這裏描述的是系統哪部分？
這裏是用戶在**WeEdit**系統上可以進行各項操做的部分，以及對操做內容的具體化。
• 這部分要面臨什麼樣的問題？
須要面臨功能如何按照用戶習慣排布的問題
• 如下設計解決了哪些問題？
解決的問題：
各個功能模塊之間直觀的邏輯聯繫
Part 5：（活動圖）
• 這裏描述的是系統哪部分？
描述了用戶具體選擇發佈通知，現場簽到，投票，想法收集和文章分享這幾大模塊。以及每一個模塊相對應的後續操做和結果。如進入現場簽到模塊後，能夠選擇簽到會議。
• 這部分要面臨什麼樣的問題？
不能防止同窗帶翹課的同窗的手機來簽到。
• 如下設計解決了哪些問題？
解決的問題：
解決了用戶權限的問題。不一樣權限的用戶進入不一樣的界面，進行不一樣的操做，不會發生權限混亂形成文件出現錯誤。
Part 6：（時序圖）
• 這裏描述的是系統哪部分？
展現對象之間交互的順序。它經過描述對象之間發送消息的時間順序顯示多個對象之間的動態協做。
• 這部分要面臨什麼樣的問題？
須要理清項目各模塊內的邏輯，按時間順序顯示各模塊內的動態協做。
• 如下設計解決了哪些問題？
解決的問題：
更加清晰地展現了各模塊內的交互邏輯、交互順序。
Part 7：（實體關係圖 ）（本人完成的部分~~~(*^_^*)~~~）
• 這裏描述的是系統哪部分？
主要描述的是系統的概念結構設計的部分。
• 這部分要面臨什麼樣的問題？
實體的決定、實體屬性的決定、實體之間的關係（包括了一對一，一對多，多對一，多對多）
• 如下設計解決了哪些問題？
解決的問題：
1） 分配了七個實體：參與者、發起者、投票、現場簽到、文章分享、想法收集、發佈通知
2） 各實體屬性的決定。具體屬性可參照「實體關係圖」。
3） 各實體之間的關係。具體實體之間的關係可參照「實體關係圖」
（發起者）
（參與者）
Selected tool
1）ProcessOn屬於線上的編輯軟件，無需額外下載，隨需隨用！
2）ProcessOn操做界面整潔明瞭，極易上手，對新用戶的操做而言十分友好！
3）ProcessOn功能豐富，可以解決許多圖形的繪製問題，額外功能十分豐富！
4）ProcessOn集成了許多圖形的繪製，集成性強！
5）同窗的推薦啦~~
Evaluation of the tool
1）無需下載， very convenient！
2）功能豐富，very convenient plus one！
3）極易上手，very convenient plus two！
PSP表格
| Planning |
計劃 |
15 |
10 |
| · Estimate |
· 估計這個任務須要多少時間 |
5 |
8 |
| Development |
開發 |
|
|
| · Analysis |
· 需求分析 (包括學習新技術) |
50 |
20 |
| · Design Spec |
· 生成設計文檔 |
20 |
10 |
| · Design Review |
· 設計複審 (和同事審覈設計文檔) |
10 |
15 |
| · Coding Standard |
· 代碼規範 (爲目前的開發制定合適的規範) |
0 |
0 |
| · Design |
· 具體設計 |
30 |
90 |
| · Coding |
· 具體編碼 |
0 |
0 |
| · Code Review |
· 代碼複審 |
0 |
0 |
| · Test |
· 測試（自我測試，修改代碼，提交修改） |
5 |
15 |
| Reporting |
報告 |
|
|
| · Test Report |
· 測試報告 |
0 |
0 |
| · Size Measurement |
· 計算工做量 |
10 |
5 |
| · Postmortem & Process Improvement Plan |
· 過後總結, 並提出過程改進計劃 |
20 |
10 |
| 合計 |
|
160 |
183 |
評估成員的貢獻分配
| 黃毓明(臨時隊長) |
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)的區別 |
給出本次換隊環節的感覺
- 這種換隊環節我以爲頗有趣啊，原來團隊成員對於分工之類的都是比較明確的，若是此次沒有換隊這個環節，那你們就是按照本身的作，可是正由於此次換隊環節，原來的計劃一會兒被打亂了，也不能說亂，就是發生了一些變化。甚至換隊的一些人咱們還不認識，以及換隊成員可能對本組項目不熟悉，所以此次換隊咱們面臨着從新規劃、認識新隊員以及熟悉工做方式、和造成新的配合關係和模式等等。這樣的「忽然」的事件讓人頗有新鮮感和興趣。並且因爲隊長換走，原本可能會引發一點點亂，但實際也沒有，小組的人仍是很積極的，很快站出來臨時隊長，這就使事情順利多了。所以我以爲仍是很不錯的。哈哈哈！