| 資訊類別 | 內容 |
|---|---|
| 作業所屬課程 | 軟體工程實踐 - 秋季班 |
| 作業要求 | 第一次團隊作業 - 原型設計與概要設計 |
| 作業目標 | 根據需求分析和設計，完成專案的原型設計和概要設計，培養團隊協作能力，為後續的開發奠定基礎。 |
| 團隊名稱 | iman 🌟 |
| 團隊成員 | - 102202146 - 藍敏龍 - 102201225 - 陳碧煌 - 102202105 - 王梓銘 - 102202124 - 阿依娜孜 - 102202135 - 施宇翔 - 102202134 - 承宇豪 - 102202117 - 楊邑豪 - 102202122 - 張誠坤 - 102201506 - 劉宇傑 - 102201137 - 郭劍敏 |
一、原型設計 🛠️
1.1 前臺應用原型
請點選以下連結檢視我們的原型設計：Man遊原型設計
1.1.1 登入方式 🔑
使用者可選擇微信或手機驗證碼登入，提升安全性與便利性。
為了方便使用者登入，我們提供了多種登入方式，使用者可以根據自己的偏好進行選擇：
- 微信登入：接入微信一鍵登入功能，使用者可透過微信快捷登入，無需繁瑣的註冊過程。
- 手機驗證碼登入：使用者可以輸入手機號，獲取驗證碼後完成登入，保障賬戶安全。
1.1.2 主頁 🏠
主頁以簡潔的列表形式呈現行程資訊，方便使用者管理。
主頁以簡潔的列表形式呈現，讓使用者快速瞭解行程的基本資訊，方便檢視和管理即將出發和已結束的旅遊行程。
- 行程列表：以卡片形式展示使用者的所有行程，包括即將出發和已結束的旅行，清晰明瞭。
- 新建行程按鈕：提供新增新行程的入口，使用者可以根據喜好選擇不同的方式建立行程。
- 個人中心入口：使用者可以透過主頁進入個人中心，管理個人資訊和檢視旅行資料。
1.1.3 行程總覽 🗺️
行程總覽幫助使用者清晰瞭解整個旅遊安排。
行程總覽為使用者提供了整個旅遊行程的規劃，讓使用者對行程安排一目瞭然。
- 行程規劃和路線概覽：顯示行程安排，包括每日的主要活動和地點，並簡要展示每日的行程詳情。
- 地圖與導航：提供行程的路線導航，方便使用者瞭解整體路線。
- 天氣預報：提供旅行期間的天氣預報，包括溫度和天氣狀況，幫助使用者做好出行準備。
1.1.4 每日行程 📅
每日行程頁面展示具體安排與預約提醒。
每日行程頁面提供了當天的具體行程安排，並針對需要預約的景點提供貼心提醒。
- 行程地點距離：顯示每個行程地點之間的距離，幫助使用者合理安排時間。
- 預約提醒：對需要預約的景點提供提醒，避免使用者錯過重要預約。
- 行程編輯：使用者可在行程上繼續編輯，新增或刪除地點，個性化定製行程。
1.1.5 旅行賬單 💰
旅行賬單幫助使用者管理開支，控制預算。
旅行賬單功能為使用者提供旅行期間的賬單記錄和預算管理。
- 預算設定：使用者可以在旅行前設定初步預算，幫助控制旅行開支。
- 開支記錄：根據不同類別記錄每日的具體開支，清晰瞭解消費情況，便於後續分析。
1.1.6 行李清單 🎒
行李清單功能幫助使用者整理行李，避免遺漏。
行李清單功能幫助使用者在出行前做好行李準備，避免遺漏重要物品。
- 分類整理：根據不同類別（如服飾、電子產品、證件等）分類行李，使用者可對照我們的基礎清單進行勾選。
- 自定義編輯：使用者可以自行新增或刪除物品，生成符合自身需求的行李清單。
1.1.7 建立行程 📝
使用者可以選擇多種方式建立新行程，靈活方便。
使用者可以根據自己的喜好選擇不同的方式建立新行程，我們提供了三種建立方式：
1.1.7.1 連結複用 🔗
透過連結建立行程，系統自動分析地點。
利用種草文章或攻略的連結建立行程，系統透過 Kimi API 識別連結並分析地點，自動生成行程。
- 根據推薦行程建立：使用者可以直接根據系統推薦的行程建立自己的行程，省時省力。
- 新增地點到已有行程：使用者可選擇喜歡的地點，新增到已有的行程規劃中，豐富行程內容。
1.1.7.2 自行建立行程 ✏️
使用者可以完全自定義行程安排，隨心所欲。
使用者可以手動規劃行程，完全按照自己的意願安排旅行計劃。
- 行程初始化：使用者輸入目的地和旅行日期，初始化行程框架。
- 新增行程和地點：在初始化的基礎上，使用者可進一步新增每日行程和想去的地點。
1.1.7.3 AI 智慧推薦行程 🤖
智慧推薦系統為使用者提供個性化行程建議。
在自行建立行程的基礎上，利用 AI 智慧推薦，為使用者提供個性化的行程建議。
- 關鍵詞引導：系統根據目的地和使用者偏好推薦相應行程，使用者只需輕鬆選擇喜歡的活動。
- 智慧調整：根據使用者實時反饋，智慧調整推薦，確保行程安排符合使用者的期望。
1.2 後臺管理原型
後臺管理原型連結：https://modao.cc/proto/5lPgyRD1smboy6kqDH8yJX/sharing?view_mode=read_only
1.2.1 實時使用者行為資料展示
展示了應用的實時使用者行為資料，包括關鍵指標如瀏覽量（PV）、獨立使用者數量（UV）、訪問次數和獨立IP等。頂部顯示實時資料重新整理時間，中部提供小時級別的趨勢圖，清晰反映使用者訪問量在一天中的變化。詳細資料表進一步分解每個小時的訪問資料，方便分析各時間段的使用者行為。
1.2.2 使用者訪問軌跡分析
詳細展示了使用者的訪問軌跡，包括訪問時間、使用者地域、使用者型別（新使用者或老使用者）、訪問來源等資訊。可以根據不同條件（如頁面URL、訪問時長、訪問渠道）對使用者進行篩選，幫助識別使用者的具體行為路徑，非常適合分析使用者的來源及行為模式，便於最佳化使用者體驗和推廣策略。
1.2.3 新老使用者趨勢分析
上方的折線圖顯示新使用者和老使用者數量在特定時間範圍內的變化趨勢，展示每日的新老使用者比例。下方的詳細資料表列出每天的新使用者數量、老使用者數量及其在總使用者中的佔比，有助於團隊分析使用者增長情況和留存率。
1.2.4 區域分佈圖
顯示使用者在不同省份的訪問量，使用不同顏色深淺來標示各地區的訪問情況，顏色越深代表訪問量越高。下面的資料表進一步提供各省份的瀏覽量（PV）、獨立使用者（UV）、訪問次數等指標，幫助理解不同區域的使用者分佈情況，為市場投放和區域推廣提供依據。
1.2.5 實時效能監控資料
展示應用的實時效能監控資料，包括CPU使用率、記憶體使用率、最大分割槽使用率和交換分割槽使用率等關鍵效能指標。趨勢圖記錄各項指標在一天中不同時間段的變化情況，幫助識別可能存在的效能瓶頸，適用於監控系統效能，確保應用在高訪問量下仍能穩定執行。
二、概要設計 😊
2.1 整體架構概覽 🌍
-
使用者層：
- 提供使用者統一登入介面. 🔑
- 實現賬戶許可權統一管理，確保安全性和便捷性. 🔒
-
技術層：
- 開發類：使用Python、Django、Uni-app等技術工具，構建應用的核心功能. 💻
- 管理類：負責專案管理相關工作，確保開發過程的高效性和系統性. 📊
-
功能層：
- 登入註冊：為使用者提供訪問應用的基本入口. 🚪
- 旅遊行程生成AI：根據使用者需求自動生成旅遊行程. 🤖
- 行程單展示及天氣交通訊息：展示詳細行程，同時提供天氣與交通資料，便於使用者規劃. 🌦️🚥
- 備忘錄：方便使用者記錄和管理旅途中的事項. 📒
-
資料層：
- 使用MySQL資料庫進行資料儲存和管理. 🗄️
- 為功能層提供高效、可靠的資料支援，保障使用者行程和相關資訊的有效管理和呼叫. 📈
2.2 UML 設計 ✨📊
2.2.1 用例圖 🌐
此用例圖描述了Man遊的主要功能模組及其使用者角色的互動關係，包括使用者的註冊登入、行程推薦、天氣查詢等操作，以及管理員的資料管理許可權和第三方API的呼叫，展示了系統的功能範圍和各參與者的職責。😊✨
2.2.2 活動圖 🚀
描述了Man遊的使用者流程，展示了客戶端和伺服器端的互動。使用者可以登入、檢視和修改旅遊計劃、記錄賬單、設定預算、建立行程（手動或使用AI輔助）、管理個人資訊等，同時系統會處理並儲存相關資料。🌟🗺️
2.2.3 類圖 📚
展示了一個旅遊規劃系統的主要類及其關聯，包括使用者類、行程推薦、天氣查詢、路線規劃、賬單管理和簡訊驗證等介面，實現了從登入、行程推薦到詳細行程生成的核心功能。📊🚀
2.2.4 時序圖 ⏳
詳細刻畫了使用者在旅遊規劃系統中的互動流程，涵蓋使用者登入、個性化旅行攻略生成、路線規劃設定及反饋與評分提交等核心功能模組。透過引入條件分支處理異常場景（如資料獲取失敗、服務不可用等），該設計有效提升了系統的魯棒性和使用者互動體驗。💻🛤️
2.2.5 協作圖 🤝
展示了旅遊規劃應用的主要功能模組和使用者互動流程。使用者可以透過手動或智慧方式建立行程，系統整合了 Kimi API 和高德地圖 API 來提供智慧推薦和路線規劃等功能。🌍🗺️
2.3 資料庫設計 📖
2.3.1 ER 圖 📊
此ER圖展示了旅遊規劃系統中各實體（如使用者、目的地、旅行路線、旅行攻略）及其相互關係，描述了使用者可以制定旅行攻略並查詢目的地和天氣資訊，同時管理旅行路線等相關資料。📚🌐
2.3.2 關係資料模型 📈
該實體關係圖展示了旅遊規劃系統的核心實體及其關係，包括使用者（User）、目的地（Destination）、旅行攻略（TravelGuide）、旅行路線（TravelRoute）和天氣資訊（Weather），使用者可以建立旅行攻略和路線，查詢目的地和天氣資訊，從而實現行程推薦與管理。🌈🌏
以下是我們資料庫展示：
資料庫表結構
| 庫名 | 表名 | 功能說明 |
|---|---|---|
| travel | tbl_users | 儲存使用者資訊 |
| travel | tbl_travel_guides | 儲存旅行攻略資訊 |
| travel | tbl_destinations | 儲存旅遊目的地資訊 |
| travel | tbl_routes | 儲存旅行路線資訊，包括經過的目的地列表（使用關聯表） |
| travel | tbl_route_stops | 儲存旅行路線的詳細站點資訊（可選） |
| travel | tbl_weather | 注意：此表在此設計中未直接使用，因為天氣資訊通常實時獲取，但如需儲存歷史天氣，可新增此表 |
表tbl_users
| 欄位名 | 資料型別 | 約束/索引 | 說明 |
|---|---|---|---|
| user_id | INT AUTO_INCREMENT | PK_tbl_users | 使用者ID（主鍵） |
| username | VARCHAR(50) | UNIQUE | 使用者名稱 |
| phone_number | VARCHAR(20) | UNIQUE, chk_tbl_users_phone | 使用者手機號，需唯一，且格式正確 |
| password | VARCHAR(255) | 使用者密碼（加密儲存） | |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP | 建立時間 |
| updated_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | 更新時間 |
檢查約束：chk_tbl_users_phone 用於確保手機號格式正確（具體實現依賴於資料庫系統）。
表tbl_travel_guides
| 欄位名 | 資料型別 | 約束/索引 | 說明 |
|---|---|---|---|
| guide_id | INT AUTO_INCREMENT | PK_tbl_travel_guides | 攻略ID（主鍵） |
| user_id | INT | fk_tbl_travel_guides_user | 使用者ID（外來鍵） |
| guide_url | VARCHAR(255) | 攻略連結 | |
| guide_name | VARCHAR(100) | UNIQUE | 攻略名稱 |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP | 建立時間 |
| updated_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | 更新時間 |
外來鍵：fk_tbl_travel_guides_user 引用 tbl_users 表的 user_id。
表tbl_destinations
| 欄位名 | 資料型別 | 約束/索引 | 說明 |
|---|---|---|---|
| destination_id | INT AUTO_INCREMENT | PK_tbl_destinations | 目的地ID（主鍵） |
| destination_name | VARCHAR(100) | UNIQUE, idx_tbl_destinations_name | 目的地名稱，需唯一 |
| description | TEXT | 目的地描述 | |
| location | VARCHAR(255) | 目的地位置 | |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP | 建立時間 |
| updated_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | 更新時間 |
非主鍵索引：idx_tbl_destinations_name 用於加速目的地名稱的查詢。
表tbl_routes
| 欄位名 | 資料型別 | 約束/索引 | 說明 |
|---|---|---|---|
| route_id | INT AUTO_INCREMENT | PK_tbl_routes | 路線ID（主鍵） |
| user_id | INT | fk_tbl_routes_user | 使用者ID（外來鍵） |
| route_name | VARCHAR(100) | UNIQUE, idx_tbl_routes_name | 路線名稱，需唯一 |
| description | TEXT | 路線描述 | |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP | 建立時間 |
| updated_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | 更新時間 |
外來鍵：fk_tbl_routes_user 引用 tbl_users 表的 user_id。
非主鍵索引：idx_tbl_routes_name 用於加速路線名稱的查詢。
注意：此表不包含 destination_ids 欄位，因為我們將使用關聯表來儲存路線和目的地的關係。
表tbl_route_stops
| 欄位名 | 資料型別 | 約束/索引 | 說明 |
|---|---|---|---|
| stop_id | INT AUTO_INCREMENT | PK_tbl_route_stops | 站點ID（主鍵） |
| route_id | INT | fk_tbl_route_stops_route | 路線ID（外來鍵） |
| destination_id | INT | fk_tbl_route_stops_destination | 目的地ID（外來鍵） |
| sequence | INT | UNIQUE(route_id, sequence), idx_tbl_route_stops_sequence | 站點順序，在路線內唯一 |
| arrival_time | TIME | 到達時間 | |
| departure_time | TIME | 出發時間 |
外來鍵：
- fk_tbl_route_stops_route 引用 tbl_routes 表的 route_id。
- fk_tbl_route_stops_destination 引用 tbl_destinations 表的 destination_id。
複合唯一約束：(route_id, sequence) 確保同一路線內站點順序的唯一性。
非主鍵索引：idx_tbl_route_stops_sequence 用於加速按站點順序的查詢。
2.3.3 物件關係對映 🗄️
{
"_id": "ObjectId", // 唯一識別符號
"username": "String", // 使用者名稱，新增唯一索引
"phone_number": "String", // 使用者手機號，新增唯一索引
"password_hash": "String", // 密碼雜湊值（加密儲存）
"created_at": "Date", // 註冊時間
"updated_at": "Date", // 最後更新時間
"travel_guides": [ // 使用者釋出的旅行攻略，巢狀陣列
{
"guide_id": "ObjectId", // 唯一識別符號
"guide_url": "String", // 攻略連結
"guide_name": "String", // 攻略名稱，唯一
"created_at": "Date", // 攻略建立時間
"updated_at": "Date" // 攻略更新時間
}
],
"travel_routes": [ // 使用者建立的旅行路線，巢狀陣列
{
"route_id": "ObjectId", // 唯一識別符號
"route_name": "String", // 路線名稱，唯一
"description": "String", // 路線描述
"created_at": "Date", // 路線建立時間
"updated_at": "Date", // 路線更新時間
"destinations": [ // 路線經過的目的地列表
{
"destination_id": "ObjectId", // 唯一識別符號
"sequence": "Integer", // 目的地在路線中的順序
"arrival_time": "Date", // 到達時間
"departure_time": "Date" // 離開時間
}
]
}
]
}
欄位說明
- userid：使用者ID，唯一標識使用者，原
username - phone：使用者手機號，唯一標識，原
phone_number - passwordHash：加密儲存的使用者密碼，原
password_hash - createdAt：使用者建立時間，原
created_at - updatedAt：使用者最後更新時間，原
updated_at
使用者的旅行攻略
- guides：使用者建立的旅行攻略列表，原
travel_guides- guideId：攻略ID，唯一標識每條攻略，原
guide_id - url：攻略連結，原
guide_url - name：攻略名稱，唯一標識，原
guide_name - createdAt：攻略建立時間，原
created_at - updatedAt：攻略更新時間，原
updated_at
- guideId：攻略ID，唯一標識每條攻略，原
使用者的旅行路線
- routes：使用者建立的旅行路線列表，原
travel_routes- routeId：路線ID，唯一標識每條路線，原
route_id - name：路線名稱，唯一標識，原
route_name - desc：路線描述，原
description - createdAt：路線建立時間，原
created_at - updatedAt：路線更新時間，原
updated_at - destinations：路線包含的目的地列表
- destId：目的地ID，引用目的地表中的ID，原
destination_id - seq：目的地在路線中的順序，原
sequence - arrival：到達時間，原
arrival_time - departure：出發時間，原
departure_time
- destId：目的地ID，引用目的地表中的ID，原
- routeId：路線ID，唯一標識每條路線，原
目的地（Destination）
- destName：目的地名稱，唯一標識每個目的地，原
destination_name - desc：目的地描述，原
description - loc：目的地位置，原
location - createdAt：目的地建立時間，原
created_at - updatedAt：目的地更新時間，原
updated_at
關係對映
- 使用者 (User) 與 攻略 (Guide) 是一對多關係，使用者可以有多個攻略。
- 使用者 (User) 與 路線 (Route) 是一對多關係，使用者可以建立多個路線。
- 路線 (Route) 與 目的地 (Destination) 是多對多關係，路線中包含多個目的地，目的地可以出現在多個路線中。
2.4 設計思考與考量 💭
2.4.1 總體原則 📋
(1) 統一總體設計：遵循“統一設計、統一規劃、統一實施，統一建設”的原則，加強規範化、標準化，確保各建設專案的實施過程符合總體架構設計。🌟
(2) 符合標準要求：符合各項資訊化建設要求，確保建設過程標準規範。👍
2.4.2 實用性和先進性 ⚙️
採用先進成熟的技術滿足使用者使用需求，兼顧其他相關的管理需求，使整個系統在相當一段時期內保持技術的先進性，而不至於落後，以適應現代科技和資訊化技術快速發展的大趨勢和大方向。🎉✨在保證系統先進性的前提下，也要充分考慮系統的實用性，畢竟只先進不實用的系統不是使用者真正需要的，最大程度的滿足使用者建設需要、貼合使用者使用需求，才能滿足使用者的實用性要求。
2.4.3 標準化、開放性、相容性 🔌
選擇標準、開放的技術和應用標準，軟體協議上真正實現開放，同時基於開放式標準，堅持統一規範的原則，實現標準化、模組化，從而為未來系統的開放、相容、發展奠定基礎。🔧🌍
2.4.4 高可靠性、穩定性 🔒
業務系統的執行，高可靠性是第一位的。要對系統架構進行高可靠性的設計和建設。採用冗餘、分散式、叢集、熱備等相關的技術手段，為整個系統的穩定執行保駕護航。🔒⚙️
2.4.5 易用性 👩💻
系統建成後是否能讓使用者使用人員很快上手，這直接關係到系統的使用效率。因此，在系統建設中，必須堅持系統的易用性原則。在系統的操作和控制方式上，儘可能透過技術手段，使得操作人員可以快速掌握系統的使用。🖥️👌
2.4.6 靈活性和可擴充套件性 🔄
考慮到未來業務的調整及快速發展，系統結構要層次化、模組化，易於未來應用的擴充套件。現代化的系統應該是一個不斷髮展、與時俱進的系統，所以它必須具有良好的靈活性和可擴充套件性，能夠根據使用者不斷髮展的業務需要，方便地進行調整和升級。🚀📈
三、團隊協作記錄 🤝
3.1 開發計劃時間安排 📅
Man遊的開發離不開詳細的工作安排，我們將工作安排精細到周，主要透過前後端來分配任務，並說明了每個階段的預計產出。
專案進度表 📊
| 週數 | 日期範圍 | 前端任務（uniapp） | 後端任務（Django） | 里程碑 | 產出 |
|---|---|---|---|---|---|
| 第1周 | 11月2日 - 11月8日 | - 搭建前端開發框架（uniapp） - 完成登入、註冊頁面的開發 - 實現頁面間的基本導航和路由 - 開發主頁和底部導航欄 |
- 搭建後端開發框架（Django） - 完成使用者認證模組的 API 開發 - 實現使用者註冊、登入、退出功能 - 設計並建立資料庫表（使用 MySQL） - 確保使用者資料安全和密碼加密處理 |
專案基礎框架搭建完成 | - 前後端基礎框架 - 登入、註冊功能介面 - 使用者認證 API - 資料庫表結構 |
| 第2周 | 11月9日 - 11月15日 | - 開發“預約提醒與門票價格查詢”介面 - 開發“連結種草文章”介面 - 最佳化 UI 細節和互動效果 - 實現與後端的資料對接 |
- 實現門票價格查詢 API，接入第三方資料來源 - 實現預約提醒功能的後端邏輯 - 開發文章連結解析和內容提取的 API - 完善資料庫結構和資料儲存邏輯 |
核心功能模組開發啟動 | - 門票查詢和預約提醒功能介面 - 文章連結解析功能 - 對應的後端 API |
| 第3周 | 11月16日 - 11月22日 | - 開發“個性化行程推薦”和“最優路線規劃”介面 - 整合地圖功能（如高德地圖 SDK） - 開發“完整行程單”和“備忘錄”介面 - 最佳化介面設計和使用者體驗 |
- 實現個性化行程推薦演算法，利用 LLM 介面和使用者偏好資料 - 開發路線規劃 API，整合交通工具選擇功能 - 實現行程單生成和備忘錄相關 API - 最佳化資料庫查詢和系統效能 |
核心功能模組開發完成 | - 所有核心功能介面開發完成 - 對應的後端功能實現 - 最佳化後的資料庫結構 |
| 第4周 | 11月23日 - 11月29日 | - 前端功能整合與最佳化 - 進行全面的功能測試和使用者體驗改進 - 修復測試中發現的 Bug 和問題 - 準備專案演示材料 |
- 後端 API 整合與最佳化 - 完成安全性測試，防範常見漏洞 - 修復測試中發現的 Bug 和問題 - 準備專案部署文件 |
專案測試和最佳化完成 | - 可供演示的 APP 版本 - 測試報告 - 專案演示 PPT 和演示影片 |
| 第5周 | 11月30日 | - 應用釋出準備 - 收集使用者反饋 - 專案總結與彙報 |
- 部署後端服務 - 確保後端服務穩定執行 - 資料備份與日誌監控 - 專案總結與彙報 |
專案上線與總結完成 | - 上線的應用 - 使用者反饋報告 - 專案總結文件 |
3.2 分工安排 😊
我們根據大家擅長的技術以及個人特點，做了相應的分工，並且詳細的說明了各自負責的內容：
專案經理 👔
| 成員姓名 | 角色 | 負責內容 |
|---|---|---|
| 藍敏龍 | 專案經理 | - 專案整體統籌與協調 - 制定專案計劃與進度把控 - 組織團隊會議與溝通 - 風險管理與問題解決 - 協助前後端聯調 |
前端組 💻
| 成員姓名 | 角色 | 負責內容 |
|---|---|---|
| 陳碧煌 | 前端開發工程師 | - 負責“預約提醒與門票價格查詢”介面開發 - 實現頁面的互動效果與資料展示 - 與後端對接門票查詢和預約提醒功能的 API - 最佳化介面設計和使用者體驗 |
| 王梓銘 | 前端開發工程師 | - 負責“個性化行程推薦”和“最優路線規劃”介面開發 - 整合地圖功能（如高德地圖 SDK） - 實現路線規劃的互動與展示 - 與後端對接行程推薦和路線規劃 API |
| 阿依娜孜 | 前端開發工程師 | - 負責“連結種草文章”介面開發 - 實現文章連結的輸入與內容展示 - 開發“完整行程單”和“備忘錄”介面 - 與後端對接文章解析和行程單生成的 API |
| 郭劍敏 | 前端開發工程師 | - 負責“使用者反饋與評價”介面開發 - 實現使用者評價的輸入與展示 - 最佳化使用者反饋的互動體驗 - 與後端對接反饋提交和查詢功能的 API |
| 張誠坤 | 前端開發工程師 | - 負責“資料統計與分析”介面開發 - 實現統計資料的視覺化展示 - 與後端對接資料統計功能的 API - 最佳化資料展示的使用者體驗 |
後端組 🔧
主要開發人員
| 成員姓名 | 角色 | 負責內容 |
|---|---|---|
| 施宇翔 | 後端架構師 | - 負責後端系統的架構設計 - 制定後端技術方案與規範 - 搭建後端開發框架（Django） - 設計資料庫結構和 ER 圖 - 指導後端組成員的開發工作 |
| 承宇豪 | 後端開發工程師 | - 實現使用者認證模組的 API，包括註冊、登入、退出功能 - 確保使用者資料安全和密碼加密處理 - 開發使用者資訊管理相關功能 - 設計並建立使用者相關的資料庫表 |
| 楊邑豪 | 後端開發工程師 | - 開發門票價格查詢 API，接入第三方資料來源 - 實現預約提醒功能的後端邏輯，設定定時任務 - 開發訊息通知模組 - 最佳化 API 的效能和安全性 |
協助開發與測試人員
| 成員姓名 | 角色 | 負責內容 |
|---|---|---|
| 劉宇傑 | 後端開發工程師 | - 協助資料庫的管理與維護 - 完成部分資料處理任務 - 參與後端系統的測試工作 - 編寫資料庫相關的文件 |
說明：
-
專案經理：
- 藍敏龍 負責專案的整體統籌與協調，確保專案順利進行。
-
前端組：
- 陳碧煌、王梓銘、阿依娜孜、郭劍敏、張誠坤 共同負責不同功能模組的前端開發，與後端對接相應的 API，最佳化使用者體驗。
-
後端組：
- 主要開發人員：
- 施宇翔 作為後端架構師，負責後端系統的架構設計和團隊指導。
- 承宇豪 和 楊邑豪 負責核心後端功能的開發，包括使用者認證、門票查詢、預約提醒等。
- 協助開發與測試人員：
- 劉宇傑 協助後端開發，完成簡單的功能模組，參與測試和文件編寫。
- 主要開發人員：
3.3 團隊協作過程記錄 📅
會議與討論 🗣️
在本次作業過程中，團隊採用了線上與線下相結合的協作方式。我們於近期召開了一次線下會議和兩次線上會議：
-
線下會議：團隊全體成員在學校內進行了一次面對面的交流，主要討論了專案的總體規劃、功能設計以及任務分工。
-
線上會議：利用騰訊會議，團隊進行了兩次線上會議，主要就專案進展、遇到的問題和解決方案進行了討論。
為確保本次任務高效、有序地進行，我們根據每位成員的特長和興趣，明確了具體的任務分工，詳情如下：
| 任務 | 負責人 |
|---|---|
| 登入及擴充套件模組的原型繪製 | 王梓銘 |
| 行程及擴充套件模組原型繪製 | 阿依娜孜 |
| 主頁及擴充套件模組原型繪製 | 陳碧煌 |
| 資料庫設計說明書撰寫 | 楊邑豪、郭劍敏 |
| 系統設計說明書撰寫 | 施宇翔、劉宇傑 |
| 用例圖、活動圖、類圖、時序圖繪製 | 承宇豪、施宇翔 |
| PPT 製作 | 陳碧煌、承宇豪、藍敏龍 |
| 部落格撰寫 | 藍敏龍 |
3.4 專案管理平臺的使用 🖥️
在本次專案中，團隊主要使用了 PingCode 作為專案管理平臺。PingCode 是一款專業的研發專案管理工具，集需求管理、任務跟蹤、缺陷管理和程式碼管理於一體，旨在提升團隊協作效率和專案管理水平。
本次任務我們就嘗試使用了PingCode對專案進行任務釋出以及提交：
我們在下一次任務也使用了PingCode平臺對任務進行釋出：
3.5 GitHub 貢獻記錄 📈
以下是我們團隊在GitHub上的簽入記錄：
四、附錄 📚
1 GitHub 團隊倉庫連結
- 倉庫連結：https://github.com/acedia7/MAN-travel
2 相關文件下載連結
- iman_系統設計說明書.pdf：https://pan.baidu.com/s/10Bw1iS9qIHL76Nye5jNakw?pwd=zk98
- iman__資料庫設計說明書.pdf：https://pan.baidu.com/s/13v02TklBQU1yf3TrFXw_NA?pwd=56cg
- iman__原型設計+概要設計答辯PPT.pdf：https://pan.baidu.com/s/1dWxXEr_XsKz5xr-j555jGg?pwd=c8es