團隊資訊
隊員姓名與學号
| 學号 | 姓名 | 部落格連結 |
|---|---|---|
| 124 | 王彬（組長） | 點選這裡 |
| 206 | 趙暢 | |
| 215 | 胡展瑞 | |
| 320 | 李恒達 | |
| 131 | 佘嶽昕 | |
| 431 | 王源 | |
| 陳文垚 | ||
| 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】用例圖
這裡描述的是系統哪部分？
- 描述的是系統的項目需求部分。
這部分要面臨什麼樣的問題？
- 使用者需求的變化是多樣性的，未來仍需要盡善盡美。
以下設計解決了哪些問題？
- 直覺的表達了不同使用者的不同需求。
- 解決了項目的需求分析,為接下來更詳細的任務作鋪墊。
-
福大軟工 · 第八次作業（課堂實戰）- 項目UML設計（團隊） -
福大軟工 · 第八次作業（課堂實戰）- 項目UML設計（團隊）
【part2】類圖
- 描述了系統中的各個類、接口以及它們之間的靜态結構和關系
- 主要面臨系統中的功能邏輯接口混亂問題
- 以下設計解決了系統的靜态視圖設計，執行功能的描述，以及各個類之間的關系和協作
-
福大軟工 · 第八次作業（課堂實戰）- 項目UML設計（團隊）
【part3】活動圖
- 描述的是系統執行的活動部分，從活動到活動的流程
- 答：程式運作流程和子產品調用不清晰
- 答：實作了整個用戶端使用周期各個活動的确認
-
福大軟工 · 第八次作業（課堂實戰）- 項目UML設計（團隊）
【part4】狀态圖
- 描述的是用戶端App 的整個狀态過程。
- 以及商家Web用戶端的整個狀态過程。
- 對整個應用的狀态進行一個描述。
- 面臨狀态的缺漏，沒有描述到所有的狀态。
- 解決了整個用戶端使用周期各個狀态的确認。
-
福大軟工 · 第八次作業（課堂實戰）- 項目UML設計（團隊）
【part5】實體關系圖
- 描述了資料庫中各個實體及其屬性和各實體之間的關系
- 主要面臨資料庫中實體關系混亂、存在備援的問題
- 以下設計解決了資料庫系統中各實體的設計問題，描述了各實體的屬性以及實體之間的關系
-
福大軟工 · 第八次作業（課堂實戰）- 項目UML設計（團隊）
【part6】泳道圖 選做
- 泳道圖是特殊的活動圖，是以描述的是也系統執行的活動部分
- 面臨各個活動歸屬不清晰，職責不明确的問題
- 明确流程環節所屬的階段
- 能夠将模型中的活動按照職責組織起來，清晰展現出某個動作發生在哪個組織
-
福大軟工 · 第八次作業（課堂實戰）- 項目UML設計（團隊）
工具選擇
選擇的工具
- ProcessOn
選擇的理由
- 首先是免費。
- ProcessOn是一個線上的工具，隻要打開網頁就能用，這就非常的友善且高效。作為線上的工具有一個隐藏的好處就是跨平台，例如Visio是一個微軟的軟體，如果使用Linux和Mac就無法實作移動辦公。
- ProcessOn功能強大。流程圖、各種UML、類圖都可以用ProcessOn來繪制，這款繪圖工具包含了豐富的圖形和各種元素。并且操作十分簡便，基本上上手就可以用。
- 具有類似于石墨文檔的線上共同編輯功能。儲存到本地也十分友善。
使用後的評價
- 算上這次應該是第三次使用ProcessOn了，這款編輯工具不但功能豐富而且還是線上工具=。=,用的還是相當的順手的，用到現在也隻是今天在上色的時候稍感身心不舒暢（沒有格式刷，全靠RBG ctrl+v 上色..）。總的來說使用體驗還是不錯的，能滿足我們的使用需求！
評估成員的貢獻配置設定
本隊“臨時隊長”給出的“課上”貢獻分評估；
| 完成部分 | 貢獻分評估 | |
|---|---|---|
| 用例圖1 | 14% | |
| 趙暢(臨時隊長) | 部落格寫作，布置任務，類圖 | 12% |
| 類圖 | ||
| 朱志豪 | 分而治之alpha版本事項，用例圖2 | |
| 志炜 | 狀态圖兩份 | |
| 文垚 | 實體關系圖 | |
| 泳道圖，活動圖 | 10% | |
| 張傑 | ||
| 陳超星 | 2% |
本隊“原隊長”給出的“課後”貢獻分評估；
| 部落格編寫、alpha任務配置設定 | ||
| 用例圖 | ||
| 擷取其他組的完成情況 | 7% | |
| 13% | ||
給出本次換隊環節的感受
-優點:
-暢暢醬今兒順利接過彬少的衣缽，熟絡新老隊員，調節隊内工作氛圍，并詳細地配置設定、布置給新老隊員任務，為我們今兒成功完成任務墊底基調，也看到了在暫時離開PM等人後，我們剩餘人等仍能獨當一面的這一情況。
-缺點:
-新隊員不熟悉他們今天剛接觸項目的情況，在作圖初始階段花了一定時間進一步了解。
-部分新隊員不大擅于溝通，不太容易融入新隊伍。
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 20 | |
| · Estimate | · 估計這個任務需要多少時間 | 120 | 140 |
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | 30 | |
| · Design Spec | · 生成設計文檔 | 5 | |
| · Design Review | · 設計複審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 90 | 110 |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | ||
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 165 | 185 |