前言
- 本次作業連結
- 組長部落格連結
- 宣傳視訊連結
項目logo及思維導圖
項目logo
- 項目Logo設計思路：我們的項目基于福州大學的各個食堂展開服務，是以我們的圖示是一個抽象的碗，碗由字母“J”和“S”（即食的拼音縮寫）組成，色調使用了相近的兩種橙色，整個logo意在使得使用者一看到我們的圖示就聯想到熱鬧的食堂并與我們的app名産生聯系。
- 思維導圖
組隊後的團隊項目的整體計劃安排
| 階段 | 主要任務 | 計劃時間 | 内容 |
|---|---|---|---|
| 1 | 項目選題 | 2018.09.27-2018.10.12 | 确定選題，完成項目的市場調研和競品分析，指定推廣戰略 |
| 2 | 需求分析 | 2018.10.20-2018.11.04 | 編寫需求說明書 |
| 3 | 編碼規範 | 2018.11.05-11.11 | 完成接口規定、編碼規範、編碼環境搭建 |
| 4 | Alpha沖刺 | 2018.11.11-2018.11.23 | 完成項目的核心功能開發、前後端對接 |
| 5 | 改進總結調整 | 2018.11.24-12.07 | 項目完善、使用者試用回報、測試計劃改進 |
| 6 | Beta沖刺 | 2018.12.13-2018.12.21 | 完成附加功能的開發以及根據使用者回報改進 |
隊員本次作業貢獻比例
| 姓名 | 比例（%） | 完成工作 |
|---|---|---|
| 王彬 | 14 | 視訊拍攝、界面原型設計、logo設計 |
| 趙暢 | 10 | 類圖設計、Word彙總、思維導圖彙總 |
| 李恒達 | 12 | 思維導圖、視訊拍攝、驗收标準撰寫 |
| 胡展瑞 | 驗收标準撰寫、PPT制作、視訊制作 | |
| 王源 | 類圖設計、思維導圖、食堂平面圖設計 | |
| 佘嶽昕 | 驗收标準撰寫、思維導圖 | |
| 陳志炜 | 功能描述撰寫、思維導圖 | |
| 陳文垚 | 引言編寫、思維導圖 | |
| 林煌偉 | 類圖設計、思維導圖 |
撰寫需求規格說明書的分工
答辯總結
小組得分
- 去掉一個最高分，去掉一個最低分，小組最終得分為77分
| 組号 | 組名 | 打分 |
|---|---|---|
| 爸爸餓了隊 | 81 | |
| 拖鞋旅遊隊 | 78 | |
| 彳艮彳亍隊 | 79 | |
| 火箭少男100 | 76 | |
| 起床一起肝活隊 | 60 | |
| 404 Note Found隊 | 71 | |
| 7 | 第三視角 | |
| 8 | 小白吃 | |
| 9 | 我頭發呢隊 |
問題彙總
第二組的提問：
- 問題1：使用者一開始使用怎麼能最快得知其口味喜好并進行正确的推薦，推薦的正确性如何保證？
- 答：我們的推薦是建立在使用者使用軟體的當時口味偏好進行推薦的，此外在軟體開發初期，我們會積極嘗試可能的算法來達到我們對推薦精确度的要求，初步調查後，随機森林、kNN等線性回歸算法在我們的考慮範圍内， 我們在項目計劃書中，以及現場PPT展示中都明确闡述了我們的軟體是基于使用者使用時對3-4道布爾選擇題的選擇來衡量使用者的口味。
- 問題2：關于推薦到菜品如果是自選類，能否進行正确的推薦且保證大部分自選都符合使用者的口味？
- 答：在團隊選題報告答辯中我們就回答過，自選視窗存在每日菜單變動的問題，這一客觀局限使得我們并不打算向使用者推薦自選檔口的菜品，不過現在在考慮面對自選檔口時隻推薦檔口的招牌菜的做法的可行性。
- 問題3：如何更大程度吸引使用者選擇你們的産品？
- 答：這個問題我們在團隊選題報告的項目推廣中已經有了全面且清晰的闡述。
第三組的提問：
- 問題1：每家店鋪都有不同的菜品,如果需要細化菜品的話是否需要大量的調查
- 答：是的，将各家不同的菜品進行口味量化是我們的項目無法避免的一部分，也是推薦的可信度的保障，是以我們在項目初期已經對各個食堂的菜品進行錄入與分析。
- 問題2：對于學生街以及食堂來說很多店鋪都在不停的更換,如何及時的更新店鋪數量,需要維護人員定期的調查嗎
- 答：我們目前隻針對福大的各個食堂展開我們的服務，按照經驗來看，食堂大部分的店鋪并不會進行頻繁的菜品輪換，但對店鋪及其菜品的維護也是需要定時進行
- 問題3：如何保證評價的可信程度,如果是别的商家惡意評論或者是水軍好評該如何解決？
- 答：我們的使用者評價更多的是使用者對店鋪的意見和建議，且我們也不打算提前開發産品的社交屬性，在産品上線後得試運作期間我們會注意惡意差評得情況是否出現，并對此采取相應措施
第四組的提問：
- 問題1：請問推薦的準确性如何保證呢？僅采用簡單的線性回歸雖然效率高但是很難評估準确性。
- 答：我們在項目需求答辯中已經闡述了我們對推薦算法的驗收标準，我們會在訓練模型時努力達成我們的目标
- 問題2：産品的适用推薦範圍是多大呢？
- 答：我們的推薦範圍框定在福州大學各個食堂的非自選檔口的菜品中，針對自選檔口也可能會采取推薦檔口特色菜品的方式。
- 問題3：産品是否存在定期的疊代規程？
- 答：感謝您的建議與提醒，我們已在項目需求計劃書中補上這部分内容
第五組的提問：
- 問題1：有沒有可能出現重複推薦了相同的店但是使用者并不喜歡卻無法屏蔽的現象？
- 答：我們在原型設計中就已經考慮到這個問題，當使用者對目前的推薦不滿意時使用者可以要求程式給出其他推薦，二被否決的推薦在往後的推薦結果中的權重會相應減小
- 問題2：遇到多人出行不知道吃什麼的時候這款軟體還能适用嘛？
- 答：如何使用本款軟體是使用者的自由，我們會盡力保證應用本身功能的易用性
- 問題3：關于你們組的logo，與嘀嘀打車的有些相似（塗上色就差不多了），後期有考慮進行修改避嫌麼
- 答：在我們看來兩者差異十分明顯
第六組的提問：
- 問題1：請問使用者的口味細化你們打算怎麼做到？
- 答：我們通過使用者擷取推薦菜品前做的4道與非選擇題來獲知使用者當下的口味偏好，并作為我們推薦的依據
- 問題2：請問軟體推廣過程打算做出什麼努力？
- 答：這部分我們在項目選題報告中的推廣方式部分已經做出充分詳細的闡述。
- 問題3：如何突顯産品競争優勢吸引使用者
- 答：我們的産品在一開始的定位就将目标人群設定為FZU在校大學生，将使用場景設定在大學食堂的範圍，目标清晰，需求明确。市面上存在一些類似菜品推薦的小程式或APP，但它們的核心都是随機推薦菜名而沒有綜合考慮使用者需求，也沒有結合所在地區的商鋪進行本地化。此外現階段的類大衆點評軟體的應用理念和操作邏輯基本大同小異，都是根據使用者的地理位置給出附近區域的餐廳推薦，但卻沒有進一步深入達到某一菜品級别的推薦。以上就是我們的軟體的競争優勢。
第七組的提問：
- 問題1：請問”使用者分析報告“中“總營業額”、“周客源數”、“支付筆數”你們要怎麼擷取？并不是使用你們的産品推薦菜品并且點選了”帶我去“，或者評論了，就能确定他為這道菜品消費了啊
- 答：這是我們的産品原型對後期産品可能的産品形态的一種展望，為了達成這個目标，我們需要打通支付方式、食堂商家的中間道路，是以在産品開發初期，問題中提到的統計資訊暫時無法上線，在先期的開發中我們會将精力主要集中在普通使用者端的開發與推薦算法的完善，如果産品運作穩定再向我們的遠期産品願景努力。
- 問題2：請問你們怎們確定推薦的菜肴就是使用者适合的？怎們确定及判定使用者的口味及喜愛？
- 答：使用者對推薦菜品是否滿意是一個主觀問題，我們所能做的就是盡量保證推薦算法的客觀合理性。對使用者口味的判定是通過使用者每次擷取推薦前的4道布爾選擇題來擷取的，之後我們的推薦算法會根據使用者的選擇推薦出最可能獲得使用者青睐的菜肴
- 問題3：請問你們怎們保證菜品推薦的真是可靠？菜品推薦應該是要基于大量的使用者，請問你們前期推廣打算怎麼吸引使用者？
- 答：我們推薦的菜品都是通過到食堂實地采集相應的資料并錄入到我們的資料庫中，是以推薦的菜品都是真實可靠的。關于産品推廣，我們已經在之前的項目選題報告中的推廣方式部分做出明确詳細的闡述。
第八組的提問：
- 問題1：商家端管理是否需要配備硬體，還是說隻要用手機就行？
- 答：商家端的應用會基于Web端提供服務，因為分析報告内容多樣，采用Web端展示更友善使用者浏覽。
- 問題2：關于ppt的講解，老師是建議說讓上次沒有參與的非pm的優先，為什麼還是pm講解的？
- 答：因為這次答辯是關于整個軟體的整體方向的報告，PM參與了項目需求報告的撰寫、PPT的制作、宣傳視訊的制作，對這次項目有更全面的認識，是以這次PPT演講依然由PM承擔，在之後深入到技術層面的演講中會優先讓其他組員承擔演講任務。
- 問題3：對于推薦算法的那一部分，要做到花費時間少和比對相對準确，真的能有相對較好的平衡嘛？
- 答：算法的時間複雜度與其準确性之間并沒有直接的關系，我們指定了相應的驗收标準對我們的推薦算法的性能表現進行衡量，確定推薦算法的準确性和運作速度達到應用的要求。
第九組的提問（暫無）：
- 問題1：
- 答：
- 問題2：
- 問題3：
修改完善本組需求分析報告
- 新增推薦算法驗收标準
- 新增對項目的可維護性要求
- 格式審查:去除首頁的頁碼
《需求規格說明書》附件
需求規格說明書
評審表格設計
評審表格下載下傳
遇到的困難及解決辦法
困難描述：
- 在一開始什麼都沒有的情況下，老師丢給我們一個軟體需求規格說明書的國标，感覺非常複雜又難以上手，不知道怎麼下手。
- 對于項目，要從腦海中模糊的idea轉換成各種骨感的UML圖，一開始時覺得難以下手。
做過那些嘗試：
- 參考其他人寫過的需求規格說明書的格式。
- 在當堂的UML制作課上與同組同學一起制作各種UML圖。
是否解決：
- 需求規格說明書順利編寫完成，基本符合規範。
- 在大家的共同努力下，多個UML圖都做了出來/
有何收獲：
- 通過當堂答辯，從同學和老師那裡得到了很多有用的建議。
- 通過做UML圖，對軟體從idea變換成更加具體的表現有了更多的體會。
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 30 | 20 |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 690 | 880 |
| · Analysis | · 需求分析 (包括學習新技術) | 120 | 180 |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 540 | 660 |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | 15 | |
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 735 | 915 |
學習進度表
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 500 | 單元測試的寫法 | ||||
| 17 | Axure RP 8 原型設計工具 | ||||
| 300 | 800 | 16 | 33 | C++爬蟲、regex正規表達式比對 | |
| 48 | UML類圖的制作 | ||||
| 68 | 軟體需求規格說明書的書寫 |