團隊資訊

• 隊名：火箭少男100
• 本次作業課上成員

• 原組成員

團隊分工

write something

UML

PART 1 —— 用例圖

1. 個人管理系統和登入系統

• 這裡描述的是系統哪部分？
  • 這裡是使用者個人管理系統和登入系統的用例圖。
• 這部分面臨什麼樣的問題？
  • 這部分要面臨使用者登入、註冊驗證、忘記密碼的基本問題，使用者的管理系統涉及個人資訊維護、系統快取和恢復載入等問題。
• 以下設計解決了哪些問題？
  • 展現了客戶與我們軟體之間的互動聯絡，便於我們對使用者個人管理系統和登入系統的視覺化和軟體原型設計，使使用者能夠理解使用登入和個人資訊的聯絡，更方便操作，並使開發者能夠有條理的實現這些元素。
• 附：

1. 社群管理系統

• 這裡描述的是系統哪部分？
  • 這裡是社群管理系統的用例圖。
• 這部分面臨什麼樣的問題？
  • 這部分要面臨搜尋店鋪，推薦店鋪等演算法問題，以及檢視附近動態的及時性。
• 以下設計解決了哪些問題？
  • 展現了社群管理的基本框架，便於我們對社群系統的視覺化和軟體原型設計，使用者可以通過這個圖更加理解社群的基本功能，便於操作。
• 附：
  

PART 2 —— 類圖

• 這裡描述的是系統哪部分？
  • 描述了系統每個部分之間的關係、連線情況。
• 這部分要面臨什麼樣的問題？

  • 對於Yolo和CRNN類的使用，需要使用預先訓練的引數。引數的訓練，需要包含大量資料的資料集，然而，現在還沒有有針對性的已經標註好的資料集，這就需要我們手動收集資料，進行標註，需要大量的人力物力。

  • 卷積運算需要強大的運算能力支援，較低端的單核CPU伺服器計算能力較弱，可能無法滿足實時性的需求。將會採用更高效能的CPU伺服器甚至GPU伺服器。但是這樣成本較高。
• 以下設計解決了哪些問題？
  • 解決了開發者對於各個類體之間關係的巨集觀認識。
• 附：
  

PART 3 —— 活動圖

• 這裡描述的是系統哪部分？
  • 描述軟體的大致使用流程，以及店鋪掃描、評論分享功能的使用流程。
• 這部分面臨什麼樣的問題？
  • 使用者在使用軟體的時候流程較為複雜，活動圖可以幫助使用者梳理整個軟體的使用流程。
• 以下設計解決了哪些問題？
  • 幫助使用者理清軟體的使用流程，明確各個功能的使用細節。
• 附：
  

PART 4 —— 狀態圖

1. 登入介面

• 這裡描述的是系統哪部分？
  • 使用者登入註冊的部分。
• 這部分面臨什麼樣的問題？
  • 面臨賬號的登入註冊以及遊客登入的設計邏輯的問題。
• 以下設計解決了哪些問題？
  • 解決了在設計登入註冊找回密碼以及遊客登入這幾個方面的邏輯順序。
• 附：
  

1. 主要功能

• 這裡描述的是系統哪部分？
  • 使用者社交，店鋪搜尋以及進行店鋪收藏評論的部分。
• 這部分面臨什麼樣的問題？
  • 面臨在使用者使用軟體的幾個主要功能時候的互動操作的邏輯。
• 以下設計解決了哪些問題？
  • 解決了在設計介面主要功能時候。面臨搜尋店鋪卡片，檢視店鋪介紹，收藏店鋪，點評店鋪。此外，從收藏的店鋪中進行評論店鋪。還有對社交部分的互動邏輯，設計點贊和評論的功能。
• 附：
  

PART 5 —— 實體關係圖

• 這裡描述的是系統哪部分？
  • 這是系統內部各個部分之間的實體關係圖。
• 這部分面臨什麼樣的問題？
  • 這部分將面對如何構建整體資料庫與內部細分以及各資料庫之間的聯絡問題。
• 以下設計解決了哪些問題？
  • 使得各個環節與內部關係之間的聯絡更加的明確，更方便地在後續的編碼過程裡明確定義各實體物件。
• 附：
  

PART 6 —— 時序圖

• 這裡描述的是系統哪部分？
  • 描述系統中各個物件之間傳送訊息的時間順序，顯示整個系統和使用者之間的動態協作。
• 這部分面臨什麼樣的問題？
  • 系統各個部分及使用者之間的同步、非同步等等時序邏輯的問題。
  • 各個模組之間傳遞細節的差異問題。
• 以下設計解決了哪些問題？
  • 描述了各個部分之間的訊息通訊，確認了模組間的請求、等待等等關係。
• 附：
  

工具選擇

本次作業團隊的最終選擇為 Process On

作業釋出之後，團隊就召集了一次小規模會議（因為比較突然，有部分人沒能出席）。主要是在 Process On 和 Visio 兩者之間進行選擇。最終考慮到以下幾點選擇了Process On：

• Process On 可以很方便的在網頁上開啟使用，而 Visio 需要在機房電腦上重新安裝
• Process On 的基本功能完全免費，而 Visio 則是需要收費的
• 團隊中大部分成員都有使用 Process On 的經歷，個別同學還是資深使用者

使用後對工具的評價

PSP表格

評估成員的貢獻分配

• 本隊“臨時隊長”給出的“課上”貢獻分評估
  

說明：13%是最基礎的貢獻度，其中奇豪和凱欣都按時完成了任務，但是都進行了返工。而柏濤和源提前完成任務並且高質量完成任務。剩下的同學都是按時完成任務並且沒有返工。0%貢獻度的同學本次課請假沒能參與。

給出本次換隊環節的感受

對於這次團隊作業，我本來應該是交換到別的隊伍去完成任務的。但是由於我們組的三位成員外出參加比賽，團隊內成員不足。經過和樂忠豪同學的溝通之後，他允許了我留在原組的請求，首先要在這裡感謝他的理解！
本次作為團隊成員，由於團隊的人員較以前減少一些，加上臨時隊長比較溫順，所以團隊的氛圍相較以前會顯得沉寂一些。但是大家都可以專注於自己的任務，並及時的溝通，但是溝通只限於兩三個人之間，沒有整組成員沒有進行過共同的交流。評價被換進來的三位同學，他們在和我們明確了軟體的功能之後，迅速的的完成了各類UML圖的製作，但是卻存在著質量不高的問題，有幾張UML也被隊長退回修改多次（可見臨時隊長真的很嚴格）。接下來評價一下新的隊長，和老隊長相比，新隊長顯得溫順一些，不能調動起大家的積極性，團隊缺少共同的交流機會，這應該是新隊長要加強的地方。但是新隊長會比新隊長有更嚴格的要求。對我們的貢獻度評分也很公平公正，並在最後下課的時候也給我們解釋了評分原因，這也是老隊長應該向新隊長學習的。
總而言之，對於這次集體作業，感謝大家可以積極配合認真的完成各自的任務，隊長有條不紊的進行彙總並按時提交，學習了大家身上的優點，帶給我很多的思考。