團隊信息

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

• 原組成員

團隊分工

分而治之

• 在劃分具體工作模塊上，我們也更願意從最終的產品開始，一層一層往下，把大型交付件分割為小型、具體的交付件。
• 交付件即可獨立實現且與其他模塊的耦合度較低的功能模塊。
• 對於我們的主功能——AR識別商鋪名返回商鋪信息
  及我們的副功能——基於GPS定位的智能推薦，我們可依次分割這兩個功能為以下幾個模塊。
  
• AR識別商鋪名返回商鋪信息

• 關於AR模塊的三個功能，這裏我簡單闡述一下：
  
• 運動追蹤
  • 在物體運動或者設備運動的過程中，追蹤目標物體，具體取決於虛擬物體和在場人員的數量。還要考慮移動手機使用 AR 時，可能會引起不安全或者阻礙了與現實世界的互動。
• 虛擬交互
  • 主要為體現在與虛擬資源交互，如選擇允許用戶辨別、操縱虛擬物體，以及與虛擬物體交互，同時要避免在平移過程中物體的突然變換或縮放比例。
• 環境增強
  • 當 AR 內容對現實世界環境做出反應時，通過陰影、光照、遮擋、反射和碰撞來模擬物體的真實存在，但是用戶可能因此難以在增強現實體驗中感知深度和距離。利用陰影、遮擋、透視、紋理、常見物體的比例，以及放置參考物體來可視化表達深度。例如：商鋪招牌的流水單引起的光線變化，通過這樣可視化方式表明空間深度。
• 基於GPS定位的智能推薦

• 在獲取位置輸入的前提下，我們將推薦算法模塊分為兩個部分，基於位置的協同過濾以及基於用戶的協同過濾，首先介紹一下協同過濾
• 協同過濾
  • 它的原理很簡單，就是根據用戶對物品或者信息的偏好及興趣采樣；
  • 發現物品或者內容本身的相關性，或者是發現用戶的相關性，
  • 然後再基於這些關聯性進行推薦。
• 接下來在介紹一下基於位置的協同過濾以及基於用戶的協同過濾
• 基於位置的協同過濾
  • 在給用戶做推薦的時候，根據用戶過往興趣偏好、地理位置及其時間衰減因子的比重來得到推薦信息。
• 基於用戶的協同過濾
  • 在給用戶做推薦的時候，根據多用戶的共同興趣偏好、地理位置及其時間衰減因子的比重來得到推薦信息。

alpha版本實現內容

• ①我們實現安卓前端設計(UI設計) 以及 後端開發
• ②我們實現目標檢測模塊以及文字識別模塊的算法實現以及優化
• ③通過AR接口實現後端與自然場景下文字識別模型的連接。

分工

分工明細

• 具體模塊如下圖所示

• 我們的alpha模塊主要針對於我們的核心功能AR識別商鋪名返回商鋪信息來實現，我們也為各組覆蓋到每名成員劃分了工作細則——TODO list。

TODO list

燃盡圖

• 以下是我們設計的任務卡片，其中文字識別和目標檢測模塊以及完成初步實現，只是仍需對現有模塊進行針對應用的改進

• 燃盡圖如下所示

• 由於部分任務的實現環節甚至在團隊作業開始之前我們已經完成，所以我們後續的規劃包括任務分割也會對此做一定調整。

UML

PART 1 —— 用例圖

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

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

1. 社區管理系統

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

PART 2 —— 類圖

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

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

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

PART 3 —— 活動圖

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

PART 4 —— 狀態圖

1. 登入界面

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

1. 主要功能

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

PART 5 —— 實體關系圖

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

PART 6 —— 時序圖

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

PART 7 —— 泳道圖

• 這裏描述的是系統哪部分？
  • 描述系統中各工作組工作規劃流程，顯示整個系統和用戶之間的動態協作。
• 這部分面臨什麽樣的問題？
  • 系統各個部分及使用者之間的同步、異步等等時序邏輯的問題。
  • 各個模塊之間傳遞細節的差異問題。
• 以下設計解決了哪些問題？
  • 描述了各部分內部連接關系以及各部分與部分之間的連接關系
• 附：

PART 8 —— 功能流程圖

• 這裏描述的是系統哪部分？
  • 該部分描述了系統的核心功能實現的流程圖
• 這部分面臨什麽樣的問題？
  • 處理圖片切片、數據獲取接口問題
  • 算法實現穩定性問題
• 以下設計解決了哪些問題？
  • 描述目標檢測模塊和文字識別模塊間具體流程圖
• 附：

PART 9 —— 功能實現圖

• 這裏描述的是系統哪部分？
  • 這裏描述了我們主要功能的實現步驟。
• 這部分面臨什麽樣的問題？
  • 系統各個部分間聯系，並行部分的實現的問題。
  • 模塊間傳遞參數的不穩定性問題。
• 以下設計解決了哪些問題？
  • 描述目標檢測模塊和文字識別模塊間的關聯以及內部實現的具體流程
• 附：

工具選擇

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

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

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

使用後對工具的評價

PSP表格

評估成員的貢獻分配

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

課堂貢獻度

說明：13%是最基礎的貢獻度，其中奇豪和凱欣都按時完成了任務，但是都進行了返工。而柏濤和源提前完成任務並且高質量完成任務。剩下的同學都是按時完成任務並且沒有返工。0%貢獻度的同學本次課請假沒能參與，在線編程由於比賽會場的網絡原因，只能給出適當修改意見。

課後貢獻度

說明：由於燊、愷翔、鈞昊三人因比賽會場網絡原因，沒能及時將繪制的UML類圖發給軟工時間的各位導致了軟工實踐課程的其他同學工作量大。所以在課後的安排中將絕大部分工作都安排給了燊、愷翔、鈞昊三人身上，所以這一次課後作業的大部分貢獻度都分給了這三位同學。

個人心得

燊

• 首先作為團隊的隊長，沒有參加這次軟工現場實戰，我感到十分遺憾。由於比賽時間沖突的緣故，再加上賽場網絡限制的影響，我們很難參與到現場實戰環節中。我們設計的UML類圖也沒有辦法及時交付給現場的隊友們。
• 我們只能通過後續采取的補救措施——承擔課後作業的大部分工作量來盡量彌補我們“肝”到心累的隊友們。我們後續做的燃盡圖也盡量貼合實際完成了各模塊及子模塊工作的劃分，希望能夠在之後的alpha環節，跟大家一起取得更好的表現。

宏巖

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

喜源

• 本次課堂UML設計迎來了一個特殊環節——團隊換人環節。身為一個沒有被換走的隊員來說，在換隊之前，一想到別隊的成員來我們隊幫忙做UML還是挺害怕的，因為UML設計需要對整個軟件有深入的了解，而一個不是本組的人做起來會不會很吃力？
• 但是事實發現，新隊友還是很強的，簡單的溝通後就明白了自己負責的圖形應該是個什麽樣。整體來看，我們在臨時隊長的帶領下，整個過程井然有序，完全不輸原隊長。新團隊的氛圍很平靜，討論比較少，各做各的，分工得當。原團隊討論會比較多，這是新團體所欠缺的。

柏濤

• 本次團隊任務為增加趣味性，采取互換團隊成員的形式。我很幸運沒有被換到其他組去。

• 對臨時隊長的感受：

  • 1.在三位成員請假，隊長不在的情況下，我們的副隊長勇於承當重任，主動肩負起帶領全隊的責任，對團隊各成員的任務進行合理分配，調度協調，確保了各成員工作的順利開展。

• 對被換來的新隊友的感受：

  • 1.與被換來的新隊友一起工作，由於大家彼此都不認識，在工作時少了嬉鬧，大家都認認真真的幹活，更加高效；
  • 2.由於大家都不熟悉，沒什麽顧忌，可以直接指出對對方方案的不足。利於方案的改進。
  • 3.常說“物以類聚，人以群分。”能組成一個團隊，很大可能是同一類人，有著相似的思想。換來的新隊友來自另一個完全不同的團隊，有著與原來團隊截然不同的思想，站在一個全新的角度思考問題，更容易想出新的創意，為團隊註入新鮮血液。
• 新舊團隊氛圍對比
  • 1.新團隊比舊團隊多了幾分嚴肅，少了幾分歡樂。優點是可以更加高效地工作，缺點是工作變得無趣枯燥。

宇航

• 本次作為幸運的被選中的交換隊員，體驗了一次別的組的工作氛圍，僅僅是這一次uml團隊作業來看（兩隊風格差異明顯，但從最後成果差異不大，另外對於“拖鞋旅遊隊”的工作氛圍可能只體驗了一次，感受是片面的）。
• 相比於原隊伍，其他隊伍優點：行動力很高，缺點：工作氛圍交流溝通有所欠缺。“拖鞋旅遊隊”臨時隊長分工明確，制作uml圖時每個圖都有對應的隊員分工，臨時隊長和原隊長風格不同，但是對於分工都是很明確的。
• 從行動力上看，“拖鞋旅遊隊”的執行力很高，各個成員很快就完成了自己的工作。但是對於制作不同uml圖的隊員之間缺乏溝通。對於我個人來說，更喜歡原隊伍的工作氛圍，隊員之間溝通交流多，在明確分工的前提下互幫互助，原隊伍的執行力也是很高的。
• 同時也感謝這次交換機會，能感受別的隊伍的工作氛圍，有幸能在“拖鞋旅遊隊”中參與他們項目的一部分（uml圖設計制作），感受了這一隊伍的行動力（很贊的）。最後除了上面幾點的差別，在我看來兩支隊伍都是很優秀的。

誌豪

• 作為被換走的臨時隊員，我內心是有些拒絕的。從一個熟悉的環境到陌生的地方合作，總會有種強烈不適應的感覺。剛開始的確有些尷尬，看著旁邊兩三個同學談笑風生，玩著我不是很懂的梗，硬接兩句，更尷尬了。還好我臉皮夠厚，還好尷尬總會被工作沖淡，也要感謝趙暢同學以及他們小組成員的熱情款待。我在這一組並不會被孤立，相反，在我的積極爭取下，還能多做一個圖，得到了不錯的貢獻分。
• 雖然我覺得我做的圖比較簡單，給的貢獻偏高了，但至少這次換組我仍然能夠實現自己的價值。即食組的工作氛圍還是很活潑的，但行動力和執行力也很強，談笑風生中把任務做完，這是能力強的表現。
• 在一上午的接觸看來，在工作中，臨時隊長趙暢同學比我們的林燊大哥更隨和一些，也可能是因為我是新來的組員。林燊組長在工作中更為嚴肅，把工作和生活分的很開，氣場很強，工作效率也很高。兩組各有優劣，今後要更加努力，在林燊和宏巖的帶領下實現一個又一個“穩”。

俞辛

• 其實做為臨時隊長，我的感受沒有太多的不同。我認為這是因為從一開始我就對團隊很上心，每次團隊作業參與度都很高。所以很自然而然的就接過了臨時隊長的任務。
• 至於新換來的同學，執行力都很強，而且會主動承擔任務。印象最深的就是源，在作業發布之後就聯系了我們，和我們一起對作業的一些細節進行了討論，所以在貢獻度的分配上他也得到了最高分。
• 因為這次有了新的隊員，隊內的幾個開心果這次也都沒能到場，所以一開始團隊氛圍顯得很沈悶。後來經過我和宏巖的一些鬥嘴，氣氛慢慢活躍了起來，大家之間得溝通交流也多了起來，效率一下就上去了。所以說不論從個人體驗還是從對團隊的貢獻而言，維護一個好的團隊氛圍還是很有必要的，這也算是隊長的一個責任吧。
• 滿分10分，給自己這次的臨時隊長打個9分，小小自戀一下:-）唯一不足的就是沒能讓遠在青島的三個小朋友一起參與進來。

愷翔

• 由於本次外出時，雖然我們在線上制作了很多類圖，但是由於所在會場的網絡環境不好，導致我無法及時上傳類圖，與軟工小夥伴們同“肝”共苦，心裏十分內疚，於是我和鈞昊決定完成剩余文檔的全部制作，來彌補小夥伴們的損失和他們的精神損失。而且聽說今天來了一個換組遊戲，我覺得這次沒有參與進去感到十分可惜，如果有下次的話，希望能夠體驗一下。
• 我在課後也盡力承擔下課後的任務，並且添加上我們繪制的UML圖，以及框架圖。下次作業我們也會盡力承擔更多的任務的。

鈞昊

• 本次由於早上同燊、愷翔兩人比賽答辯，且由於會場的網絡條件限制，做好的UML類圖無法發給團隊的其他同學，只能通過提出一下修改意見的方式來完成UML設計的實現。其實我是很期待能夠體驗一下在陌生的團隊中共同完成設計開發。可是礙於時間沖突，沒有辦法很好完成。
• 期待下一次能夠再有這樣有趣的的點子來活躍軟工團隊的氣氛，這裏我也想提供一個可能比較有趣的點子： 在答辯環節交換成員，懟自己組的場景簡直不要要有趣。

福大軟工 · 第八次作業 課堂實戰+後續部分