hjj的座標
階段主要任務
計畫時間內容1
專案選題
18.09.27—18.10.12
專案選擇，經市場調研並與老師溝通後確定選題
2需求分析
18.10.13—18.11.04
完成需求規格說明書
3設計分工
18.11.04—18.11.11
專案詳細分工，**規範，平台環境基本架構，介面初步美化設計，視覺識別演算法完善
4模組程式設計及對接
18.11.11—18.11.23
後端伺服器搭建完成，介面互動完全實現，各模組編碼基本完成後，進行對接5測試
18.11.24—18.12.07
d對alpha版本進行應用測試，根據測試結果確定beta版本優化內容
6優化完善
18.12.07—18.12.21
根據上一階段測試反饋內容，對專案進行進一步優化改善，形成正式版本
7專案實施
18.12.21—19.01.08
爭取在實際場景中能夠試點實施，投入運營
演技max系列
成員分工
貢獻比葛亮
原型優化
14%文斌
14%黃澤
15%靜茹
14%敬甲
logo+思維導圖+功能描述+部落格整理
14%澤明
功能驗收標準
14%劉浩
ppt製作演講
15%想看戳我吧
組號得分179
273376
472566
678775
880977
最後得分：75.71分
第1組1、在早上的答辯中，為了解決誠信問題所提出的解決方法需要付出額外的人力成本進行誠信核查，這是否會影響到專案初衷提高支付效率？
答：出現誠信問題，需要誠信核查的情況屬於少數情況，不會影響整體的結算效率。
2、如果演算法識別不出菜品，之後軟體的處理邏輯是什麼？
答：在伺服器正常運**況下，不會出現識別不出菜品的情況，如果出現極少數識別錯誤的情況，會在專案落地實施後，若出現極少數識別錯誤的情況，我們會與商家協定相應處理措施。
3、識別演算法所需要的資料集有乙個收集的標準嗎？
答：我們的資料集的標準：要求可以拍攝餐盤內的所有菜品，並且同乙個餐盤從菜品不同分布拍攝，每種分布100張。
第2組2、產品的推出主要是為了方便學生群體，但是商家可能存在直營、外賣以及使用小二結賬等多平台導致應接不暇的情況，如何去處理使得商家更願意使用你們的產品？1、會不會出現使用產品時識別不出菜品的情況，到時候該如何解決呢？
答：在伺服器正常運**況下，不會出現識別不出菜品的情況，如果出現極少數識別錯誤的情況，會在專案落地實施後，若出現極少數識別錯誤的情況，我們會與商家協定相應處理措施。
2、消費者的信用問題該如何得到更好的解決？
答：以專案投入使用前的宣傳手段和信用支付監管手段共同完善對信用問題的解決。
3、會不會出現識別菜品出錯，從而導致算錯了**，導致使用者（包括學生和商家）的體驗變差
答：演算法的置信度現已達到95.4%以上，在投入使用前會達到99%以上，識別錯誤概率極低。在專案落地實施後，若出現極少數識別錯誤的情況，我們會與商家協定相應處理措施。
答：我們的產品主要針對食堂的使用場景，滿足商家的直營需求，而在學校的監管下經營外賣的食堂商家會越來越少直至沒有，所以不會存在經營應接不暇的情況。
3、你們在資料分析中提到可以分析出卡路里、熱量等等關乎健康的資料，但就我個人而言，這樣的資料不太能得到我的認同，因為可信度不高，有什麼更精準更有說服力的資料分析方式嗎？
第4組1、識別錯誤的後續處理是否能保證到使用者體驗呢？
2、識別錯誤率控制在1%以下是十分困難的一件事，如果是基於速度快的yolo演算法的目標檢測來完成，是否在準確性方面達到的效果不會特別好呢？
3、產品的市場前景非常巨集大，是否存在乙個詳細的規程來協助產品的迭代維護呢？
答：暫時沒有，精力有限，能力有限，放眼當下。
第5組1、你們是否有考慮到使用者使用你們的產品會出現的逃費行為，就是買了產品不付錢，或者只拍部分的食品，這種行為你們有考慮到如何檢測到或避免嗎？
答：逃單行為我們會採用攝像頭人臉識別，匹配賬戶的選餐記錄和支付記錄來做監管。對於只拍部分食品的行為，也在我們的考慮範圍內，但沒有很好的解決方案，但這種情況屬於極少數，損失可彌補。
2、你們ppt給出的自選視窗菜品識別錯誤率控制在1%一下，是否有些偏高呢，畢竟涉及到商家的利益，能否再降低錯誤率，否者商家如何會選擇你們的產品呢
答：不會偏高，技術雖好也有瓶頸和天花板。識別錯誤率控制得極低，也有相應的反饋機制，在這兩個前提下，即便有錯誤和損失，成本也極低，在給商家帶來足夠的利益的前提下，商家能夠接受這樣的額外成本。
3、你們的產品主要賣點就是不用排隊，但你們是否有考慮到排隊實際上是能幫助食堂消化**，如果每個人都不排隊的話，那麼是會出現很多人找不到座位的，而且取餐**和取完餐回座位的**是否會產生衝突混亂呢
答： 排隊消化**是因為食堂本身硬體限制，才會有這樣的畸形的好處。而排隊結算點單是食堂用餐體驗的硬核需求，我們不會為了一粒芝麻丟掉乙個西瓜。
第6組1、你好，請問原型登陸頁面老師、學生登入按鈕不夠清晰，原型不夠美觀，有考慮改進嗎？
答：現有原型主要為了展現專案邏輯，美觀度會在專案實施時改進。
答：會在上傳到b站時使用強降噪改進。
3、你好，請問是否考慮分析使用者喜好?
第7組1、請問當大量使用者沒能及時取餐，而導致有大量的餐盤堆積在商家工作區，這樣給工作人員帶來了極大的不便，你們打算怎麼解決？是否只能到商家附件才可以點餐，還是可以預約點餐？
2、你們軟體拍照識別支付的操作複雜度是否會大於直接掃視窗的支付寶***？如果這樣對於效率的提公升似乎並不是很大。
3、請問你們調查過商家願意使用你們產品的比例嗎？當商家使用的比率不高的時候，你們打算怎麼說服商家？
答：沒有調查過。宣傳和合作方式有很多種，不是技術層面簡單明瞭，涉及到人的意願的問題，總是複雜的，也總是有解決辦法的。
第9組根據其他組的意見和建議，沒有需要修改的地方。沒有問題
這次戳我吧
psp
personal software process stages
預估耗時（分鐘）
實際耗時（分鐘）
planning
計畫30
45•estimate
•估計這個任務需要多少時間
390545
development開發0
0•analysis
•需求分析 (包括學習新技術)
6060
•design spec
•生成設計文件
6060
•design review
•設計複審
3045
•coding standard
•**規範(為目前的開發制定合適的規範)
3060
•design
•具體設計
6090
•coding
•具體編碼00
•code review
•**複審00
•test
•測試（自我測試，修改**，提交修改）00
reporting
報告60
120•test repor
•測試報告00
•size measurement
•計算工作量
3020
•postmortem & process improvement plan
•事後總結, 並提出過程改進計畫
3045
合計780
1090
第n周新增**（行）
累計**（行）
本週學習耗時（小時）
累計學習耗時（小時）
重要成長40
3405
25leangoo工具的學習
5300
64015
40雜湊演算法、優先佇列、結構體等c++演算法複習80
64010
50**方面暫無
軟工實踐作業（七）
作業鏈結 團隊部落格彙總 團隊需求報告 pdf 需求報告ppt pdf 報告 ppt 粗略的計畫 這裡的分工其實主要是文件各部分的詳細的分工，整個作業的分工在工作量比例的 中。學號姓名 此次作業任務 貢獻比例 031602240 許郁楊1.整理 安排任務 2.報告引言 使用者介面 硬體介面部分 2....
2018軟工實踐作業二
github位址 wordcount psp psp2.1 personal software process stages 預估耗時 分鐘 實際耗時 分鐘 planning 計畫 estimate 估計這個任務需要多少時間55 development 開發 analysis 需求分析 包括學習新技...
軟工實踐作業之個人總結
作業原文 對比開篇部落格你對課程目標和期待，希望通過實踐鍛鍊，增強計算機專業的能力和就業競爭力 對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，為什麼？在和他人合作編碼的方面得到了鍛鍊，不僅是在剛開始一對一的結對程式設計，後面的團隊作業也是。寫 不單單是考慮實現相應的...