Team information
- 隊名: 彳艮彳亍團隊
- 各成員短學号、名:
學号: | 姓名: | 本次部落格連結: |
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 |
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 |
181600215 | 林翔宇 |
Division of labor
- 确定 alpha 版本需要做哪些事情
子產品序号 | 子產品名 | 子產品具體内容 |
1 | 現場簽到 | 1)實作基本的簽到功能 2)改進簽到功能實作優化 |
2 | 釋出通知 | 1)實作基本的通知功能 2)實作通知欄提醒功能 |
3 | 投票 | 1)實作基本投票功能 2)結果資料的分析與傳回 |
4 | 想法收集 | 實作基本的問答功能 |
5 | 文章共享 | 1)實作基礎的文本編輯功能 2)完成簡單的文本選擇注釋功能 |
- 各成員分工明細及 TODO list
-
- 燃盡圖
UML Design
Part1:(部署圖)
• 這裡描述的是系統哪部分?
這裡主要說明的是部署問題
• 這部分要面臨什麼樣的問題?
伺服器及資料庫的搭建,前後端互動等。
• 以下設計解決了哪些問題?
解決的問題:
前端客戶操作傳回給背景伺服器,後端伺服器依照前端操作給出相應傳回值,從資料庫中調用相應的資料。
Part2:(類圖)
使用WeEdit小程式的功能方面内容。
1)項目子產品定義不夠清晰;
2)代碼未有統一格式;
通過統一參數,友善後續前後端工作的配合。
Part 3:(狀态圖)
• 這裡描述的是系統哪部分?
這部分UML描述了釋出簽到、釋出共享文檔、釋出投票功能可能的狀态以及其中狀态的具體活動
每個具體狀态轉化細化得不夠完全、在實作中還需更近一步改進
展現了軟體需要的功能以及解決了軟體内部各功能實作的邏輯問題
Part 4:(用例圖)
這裡是使用者在**WeEdit**系統上能夠進行各項操作的部分,以及對操作内容的具體化。
需要面臨功能如何按照使用者習慣排布的問題
各個功能子產品之間直覺的邏輯聯系
Part 5:(活動圖)
描述了使用者具體選擇釋出通知,現場簽到,投票,想法收集和文章分享這幾大子產品。以及每個子產品相對應的後續操作和結果。如進入現場簽到子產品後,可以選擇簽到會議。
不能防止同學帶翹課的同學的手機來簽到。
解決了使用者權限的問題。不同權限的使用者進入不同的界面,進行不同的操作,不會發生權限混亂造成檔案出現錯誤。
Part 6:(時序圖)
展示對象之間互動的順序。它通過描述對象之間發送消息的時間順序顯示多個對象之間的動态協作。
需要理清項目各子產品内的邏輯,按時間順序顯示各子產品内的動态協作。
更加清晰地展示了各子產品内的互動邏輯、互動順序。
Part 7:(實體關系圖 )(本人完成的部分~~~(*^_^*)~~~)
主要描述的是系統的概念結構設計的部分。
• 這部分要面臨什麼樣的問題?
實體的決定、實體屬性的決定、實體之間的關系(包括了一對一,一對多,多對一,多對多)
1) 配置設定了七個實體:參與者、發起者、投票、現場簽到、文章分享、想法收集、釋出通知
2) 各實體屬性的決定。具體屬性可參照“實體關系圖”。
3) 各實體之間的關系。具體實體之間的關系可參照“實體關系圖”
(發起者)
(參與者)
Selected tool
- 選擇工具: ProcessOn
- 選擇的原因:
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 Table
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | 30 | |
· Estimate | · 估計這個任務需要多少時間 | ||
Development | 開發 | 140 | 180 |
· Analysis | · 需求分析 (包括學習新技術) | 20 | |
· Design Spec | · 生成設計文檔 | ||
· Design Review | · 設計複審 | 10 | |
· Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
· Design | · 具體設計 | 40 | 50 |
· Coding | · 具體編碼 | ||
· Code Review | · 代碼複審 | ||
· Test | · 測試(自我測試,修改代碼,送出修改) | 60 | |
Reporting | 報告 | ||
· Test Repor | · 測試報告 | ||
· Size Measurement | · 計算工作量 | 15 | |
· Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | 35 | |
合計 | 200 | 260 |
Individual Score
-
- 本隊“臨時隊長”給出的“課上”貢獻分評估;
姓名 | 貢獻分+基礎分=總得分(%) |
黃毓明 | 15+2=17 |
14+2=16 | |
11+2=13 | |
6+2=8 | |
蘇路明 | 13+2=15 |
陳瀚霖 | 7+2=9 |
胡展瑞 | 12+2=14 |
-
- 本隊“原隊長”給出的“課後”貢獻分評估;
給出本次換隊環節的感受
- 首先呢,我覺得這種換隊環節在對類似的UML設計上是很可以的,說說好處哈,其一就是新加入的隊員進行,作為本隊隊員,我們需要比原來更加認真地回答和思考問題,整理完思緒後再和交換的隊員描述,對于産品本身的定位以及可行性,能有交換隊員幫我們也做詳細地參考;另外,在換隊過程中,因為大家都不太熟悉,是以換隊過程中,可以提高大家的積極性,能夠更好地完成項目的進行,再者,因為交換成員進來,使用的語言他們也會順便帶進來哈哈哈,是以不失為更好地了解他們平時是怎麼配置設定工作以及進行的,anyway,真好!