2018軟工實踐第八次作業-團隊專案UML設計
阿新 • • 發佈:2018-11-08
團隊資訊
隊員姓名與學號
學號 | 姓名 | 部落格連結 |
---|---|---|
124 | 王彬(組長) | 點選這裡 |
206 | 趙暢 | |
215 | 胡展瑞 | 點選這裡 |
320 | 李恆達 | |
131 | 佘嶽昕 | 點選這裡 |
431 | 王源 | |
206 | 陳文垚 | 點選這裡 |
209 | 陳志煒 | |
225 | 林煌偉 |
本次作業連結
團隊分工
alpha 分而治之:(作者:志豪)
alpha版本需要做的事情
模組序號 | 模組名 | 模組具體內容 |
---|---|---|
1 | 學生使用者模組 | 1.學生使用者登入 2.選擇口味介面 3.推薦展示介面 4.推薦評價頁面 5.檢視美食地圖 6.推薦店鋪位置指引 |
2 | 商家使用者模組 | 1.商鋪使用者登入 2.檢視食客評論與回覆介面 3.提交菜品和選單資料介面 4.會員充值介面 |
3 | 後臺管理模組 | 1.食堂店鋪與店鋪菜品增刪改查操作 2.推薦演算法 3.對會員和充值系統的管理 |
成員具體分工及TODO list
負責人 | 分工明細 | TODO List |
---|---|---|
王彬 | 負責專案任務分配、進度跟蹤推進、原型製作 | 1.完成原型的開發 2.文件撰寫與彙總 |
趙暢 | 資料庫搭建、資料庫介面編寫 | 1.配合後端小組完成程式後端的開發 2.完成菜品量化,搭建資料庫 |
胡展瑞 | 負責專案各個部分的測試編寫 | 1.編寫測試用例幫助前後端把控質量 |
李恆達 | 前端模組(普通使用者端)實現 | 1.完成前埠味選擇功能 2.完成推薦結果評價功能 |
陳志煒 | 前端模組(普通使用者端)實現、推薦演算法設計 | 1.完成美食地圖功能 2.完成店鋪位置指引功能 |
陳文垚 | 前端模組(普通使用者端)實現 | 1.學生端登入入口 2.完成推薦結果展示功能 |
林煌偉 | 前端模組(商鋪使用者端)實現 | 1.商鋪使用者登入功能 2.商鋪使用者檢視食客評論與回覆功能 3.商鋪提交選單和菜品資料功能 |
佘嶽昕 | 後端模組實現 | 1.前後端互動介面(學生使用者端)設計與實現 2.前後端互動介面(商鋪使用者端)設計與實現 |
王源 | 後端模組實現 | 1.菜品推薦演算法設計與實現 2.後端與資料庫介面定義與實現 |
燃盡圖
UML
【part1】用例圖
這裡描述的是系統哪部分?
- 描述的是系統的專案需求部分。
這部分要面臨什麼樣的問題?
- 使用者需求的變化是多樣性的,未來仍需要盡善盡美。
以下設計解決了哪些問題?
直觀的表達了不同使用者的不同需求。
解決了專案的需求分析,為接下來更詳細的任務作鋪墊。
【part2】類圖
這裡描述的是系統哪部分?
- 描述了系統中的各個類、介面以及它們之間的靜態結構和關係
這部分要面臨什麼樣的問題?
- 主要面臨系統中的功能邏輯介面混亂問題
以下設計解決了哪些問題?
- 以下設計解決了系統的靜態檢視設計,執行功能的描述,以及各個類之間的關係和協作
【part3】活動圖
這裡描述的是系統哪部分?
- 描述的是系統執行的活動部分,從活動到活動的流程
這部分要面臨什麼樣的問題?
- 答:程式執行流程和模組呼叫不清晰
以下設計解決了哪些問題?
- 答:實現了整個客戶端使用週期各個活動的確認
【part4】狀態圖
這裡描述的是系統哪部分?
描述的是客戶端App 的整個狀態過程。
以及商家Web客戶端的整個狀態過程。
對整個應用的狀態進行一個描述。
這部分要面臨什麼樣的問題?
- 面臨狀態的缺漏,沒有描述到所有的狀態。
以下設計解決了哪些問題?
- 解決了整個客戶端使用週期各個狀態的確認。
【part5】實體關係圖
這裡描述的是系統哪部分?
- 描述了資料庫中各個實體及其屬性和各實體之間的關係
這部分要面臨什麼樣的問題?
- 主要面臨資料庫中實體關係混亂、存在冗餘的問題
以下設計解決了哪些問題?
- 以下設計解決了資料庫系統中各實體的設計問題,描述了各實體的屬性以及實體之間的關係
【part6】泳道圖 選做
這裡描述的是系統哪部分?
- 泳道圖是特殊的活動圖,所以描述的是也系統執行的活動部分
這部分要面臨什麼樣的問題?
- 面臨各個活動歸屬不清晰,職責不明確的問題
以下設計解決了哪些問題?
明確流程環節所屬的階段
能夠將模型中的活動按照職責組織起來,清晰體現出某個動作發生在哪個組織
工具選擇
選擇的工具
ProcessOn
選擇的理由
上學期學資料庫畫ER圖的時候就用過ProcessOn,無需下載在web端即可使用,介面簡潔大方,用起來方便快捷,非常容易上手,而且功能也很豐富。
使用後的評價
使用者體驗極好,對實體或者屬性進行位置的編排和佈局時,ProcessOn可以很方便地直接選中拖動。今天還意外發現了ProcessOn會在推薦頁面顯示一些人氣較高的設計。在自己的設計遇到困難時,或許可以去看看別人的設計找一下靈感。
評估成員的貢獻分配
本隊“臨時隊長”給出的“課上”貢獻分評估;
姓名 | 完成部分 | 貢獻分評估 |
---|---|---|
李恆達 | 用例圖1 | 14% |
趙暢(臨時隊長) | 部落格寫作,佈置任務,類圖 | 12% |
林煌偉 | 類圖 | 12% |
朱志豪 | 分而治之alpha版本事項,用例圖2 | 14% |
陳志煒 | 狀態圖兩份 | 12% |
陳文垚 | 實體關係圖 | 12% |
佘嶽昕 | 泳道圖,活動圖 | 10% |
張傑 | 泳道圖,活動圖 | 12% |
陳超星 | 泳道圖,活動圖 | 2% |
本隊“原隊長”給出的“課後”貢獻分評估;
姓名 | 完成部分 | 貢獻分評估 |
---|---|---|
王彬 | 部落格編寫、alpha任務分配 | 10% |
李恆達 | 用例圖 | 12% |
趙暢(臨時隊長) | 部落格寫作,佈置任務,類圖 | 14% |
林煌偉 | 類圖 | 12% |
胡展瑞 | 獲取其他組的完成情況 | 7% |
王源 | 獲取其他組的完成情況 | 7% |
陳志煒 | 狀態圖兩份 | 13% |
陳文垚 | 實體關係圖 | 12% |
佘嶽昕 | 泳道圖,活動圖 | 13% |
PSP
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | 10 | 10 |
· Estimate | · 估計這個任務需要多少時間 | 10 | 10 |
Development | 開發 | 90 | 140 |
· Analysis | · 需求分析 (包括學習新技術) | 30 | 45 |
· Design Spec | · 生成設計文件 | 0 | 0 |
· Design Review | · 設計複審 | 0 | 0 |
· Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
· Design | · 具體設計 | 60 | 95 |
· Coding | · 具體編碼 | 0 | 0 |
· Code Review | · 程式碼複審 | 0 | 0 |
· Test | · 測試(自我測試,修改程式碼,提交修改) | 0 | 0 |
Reporting | 報告 | 45 | 45 |
· Test Repor | · 測試報告 | 30 | 30 |
· Size Measurement | · 計算工作量 | 5 | 5 |
· Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 10 | 10 |
合計 | 145 | 195 |
本次換隊環節的感受
- 作為留在原組的隊員,感覺換人後隊內的氛圍沒多大變化,還是一如既往地棒。
- 臨時隊長暢暢同學把每個人的工作安排地清清楚楚明明白白,積極和每個隊員進行溝通,檢查大家的完成情況並能夠給出相應的建議,完美的PM。
- 自己在畫關係圖的時候容易忽略一些實體的屬性,多虧和其他隊員的討論溝通才順利完成。
- 在最後的配色上糾纏了很久, 在臨時隊長的推薦下,借鑑了Color Hunt上面的一些配色方案,拯救了我的直男審美。