第05組 團隊項目-需求分析報告

組長本次做業博客連接

組隊後的團隊項目的總體計劃安排（1 2分）

序號	持續時間	主要任務	是否完成
一	9.28	組隊	√
二	10.1-10.21	製做團隊選題報告	√
三	10.22-10.27	製做團隊需求分析報告	√
四	10.28-11.2	團隊編程準備與製做	×
五	10.28-11.11	alpha衝刺準備	×
六	11.12-11.22	進行alpha衝刺，併發布alpha版本	×
七	11.23-12.3	beta衝刺準備	×
八	12.4-12.13	進行beta衝刺，併發布最終版本	×
九	12.14-課程結束	課程總結	×

團隊分工（2 5分）

• alpha版本需作事情明細

  • 1）.先完成實現小程序必須完成的界面以及接口，拓展功能暫不考慮
  • 2）.前端爲本組6位女生，各自負責本身的原型模塊
  • 3）.後端爲本組5位男生，其中3個負責函數，2個負責數據庫

• 成員分工明細及TODO list

  成員分工

  項目經理	鄭裕恆
  函數與接口設計	潘海東，餘廷龍，方瑞雄
  數據庫	鄭裕恆，翁世豪
  原型修改與實現	張萬聰，劉詩琳，嚴欣，陳蘇蘇，王玥，馬麗華

TODO list

• 燃盡圖

思惟導圖（3 2分）

總思惟導圖

功能模塊

市場定位與分析模塊

營銷策略模塊

風險管理模塊

團隊分工與貢獻比例（4 2分）

姓名	主要工做	貢獻比例
方瑞雄	評審表設計，博客撰寫，最終評審表整理	10%
嚴欣	報告中驗收驗證標準的編寫	5%
陳蘇蘇	報告中驗收驗證標準的編寫，報告細節更改	10%
翁世豪	報告中功能描述的編寫，思惟導圖設計	8%
潘海東	報告中功能描述的審覈	2%
劉詩琳	原型圖設計，記錄課堂提問問題	10%
鄭裕恆	PPT製做，文檔中交互原型設計，PPT演講人員，圖片修整與美化	15%
王玥	報告中驗收驗證標準的編寫，原型設計，logo設計與解讀	10%
張萬聰	原型圖設計，博客撰寫	10%
餘廷龍	對報告的排版與整理，UML圖設計，報告引言撰寫	15%
馬麗華	報告中驗收驗證標準的編寫	5%

評審表設計（5 1分）

UML（6 10分）

• 因爲咱們產品功能很少沒辦法拆分得那麼細，因此每一個圖整合後只作一份（很用心作的，此條已徵得助教的贊成）

用例圖

• 描述的部分：
  • 下單用戶與配送用戶之間經過訂單進行聯繫
• 面臨的問題：
  • 不一樣用戶雙方可能會對訂單產生爭議
  • 訂單沒法第一時間更新
• 解決了哪些問題：
  • 下單用戶與配送用戶對訂單的操做有主動權，而且實現對訂單的可視化

類圖

• 描述的部分
  • 用戶的我的信息和用戶對訂單的操做
  • 廣場訂單的表現形式
  • 訂單自己的狀態以及訂單衍生出的信息交互
• 面臨的問題
  • 用戶信息可能不夠全面，致使沒法準確獲得用戶信息
  • 訂單的處理問題
• 解決了哪些問題
  • 使用評論與點評功能解決了用戶之間的交互
  • 使用標籤讓訂單更具體，讓用戶更方便

活動圖

• 描述的部分
  • 訂單生成與實現功能
• 面臨的問題
  • 訂單管理功能
  • 用戶對訂單的要求操做
• 解決了哪些問題
  • 讓用戶對訂單有更多的主動權

狀態圖

• 描述的部分
  • 描述了用戶建立訂單與查找訂單的過程
• 面臨的問題
  • 用戶訂單無人受理
  • 用戶訂單沒法被搜索
• 解決了哪些問題
  • 解決了用戶之間對訂單的評論
  • 解決了用戶訂單發佈錯誤從新下單的功能

實體關係圖

• 描述的部分
  • 用戶，訂單，評論三者之間的屬有關係
• 面臨的問題
  • 用戶信息未能如實呈現
  • 訂單與用戶間的匹配不夠完善
  • 評論沒法徹底解決用戶與訂單間的矛盾
• 解決了哪些問題
  • 訂單與用戶關係之間的可視化
  • 評論與訂單之間的平衡
  • 用戶對評論的操做可執行

工具選擇（7 2分）

UML圖設計的工具

• 我選擇的是starUML，由於這學期選修了《面向對象分析與設計》，老師要求咱們自學UML，而且須要在課程設計裏使用UML作軟件建模，而後他就推薦給咱們這一款軟件，由於比較容易上手。
  實體聯繫圖是用億圖圖示作的，由於starUML無法作實體聯繫圖，因此就百度了一個軟件。（廷龍提供）

原型圖設計的工具

• 墨刀，Axure Rp 9（萬聰詩琳提供）

對工具的評價（8 2分）

• 對於starUML,老師誠不欺我，這款軟件確實很是容易上手，只須要用鼠標拖動工具欄的控件和線條即可以輕鬆繪製各類UML圖，導出圖片也很是方便，可是這款軟件也有明顯的缺點，就是畫出的圖比較不夠美觀，可是也還看得過去。對於億圖圖示，我以爲這款軟件也很是方便使用，能夠畫各類圖，並且能夠畫得很是漂亮，可是這款軟件是收費的，並且價格不低，它有15天試用期，可是在試用期導出的圖會有試用水印，因此我就只好經過調整畫圖的位置讓個人圖避開水印，而後再把我須要的部分截取下來。
• 墨刀界面不能批量導出爲圖片，可是不少圖標都是現成的，能夠生成連接分享、團隊多人協做以及各類對齊、參考線都挺好用的。
• Axure Rp 9 不知道爲何在加入交互效果的時候會出現閃退，功能比墨刀更全面，能夠生成HTML文件、能夠批量導出圖片。

答辯總結（9 9分）

本組現場答辯得分

得分詳情：第一組給分56.4分，第二組給分52.8分，第三組給分52分，第四組給分53.4分，第五組給分54分，第六組給分53.4分，第七組給分54分，第八組給分49.2分，第九組給分53.4分，第十組給分49.8分，第十一組給分47.4分，第十二組給分48分
去除一個最高分：56.4分 去除一個最低分：47.4分
取平均分：52分

針對其餘小組提問回答

第一組提問：對於紫荊一樓這種菜品不固定的檔口，有沒有考慮增長顯示菜品的功能，有沒有考慮過若是在食堂排隊的同窗會由於配送員點好幾份等待太久而發生糾紛?

因爲咱們平臺如今不是定位爲爲食堂進行銷售，而是經過點單方自行決定吃什麼東西，因此暫時沒有考慮過引進菜品。當這個小程序後期成熟後，會考慮加進去。配送員應該是避開高峯排隊時間的，咱們的小程序目的也是錯峯購買，因此這個問題產生的概率應該不大。

第二組提問：我以爲挺不錯的，就是好像跟咱們的項目有些撞車了，建議多增長些額外小功能來吸引用戶和凸顯本身的賣點。

謝謝建議！咱們如今主推的是食堂帶飯的這一功能，在把這一功能盡善盡美以後咱們也會加入代購超市奶茶店，代取快遞，文印店打印等功能

第三組提問：各大外賣平臺上的店家均可以顯示哪些套餐、菜品已售罄，可是對於學校的食堂來講，可能會出現配送員點菜的時候某些菜品已售罄，如何解決這一問題?

咱們鼓勵在食堂的人來當配送員，因此他們對食堂的菜品是否銷售通常可以及時掌握，若是沒法知足點單人的要求，能夠聯繫取消訂單或者更換菜品。

第四組提問：無

有問必答，無問不答。

第五組提問：咦咱們不就是第五組嗎?

對的咱們就是第五組。

第六組提問：發佈配送能否有時間範圍約束？

在發佈訂單的時候就能夠設置配送時間約束

第七組提問：食品產生問題時平臺如何界定責任？

首先在註冊的時候用戶須要簽定協議，在發生食品問題的時候告知平臺，平臺會出面聯繫配送員和商家，並積極協助調查，具體的責任認定要在瞭解責任源頭以後協商。

第八組提問：如何解決因一我的接單太多，而致使食品的新鮮度很差，從而致使用戶對使用軟件的意願下降的問題？

咱們會限制配送的同窗在一個時間段內的接單數量，好比在一個小時內最多隻能接5單。

第九組提問：食堂食物的標價是該應用後臺更新嗎？怎麼樣保證及時快速更新？若是食堂有打包費這樣的額外要求是用戶私下交易仍是平臺來監管？

因爲食堂飯菜的價格及物價的波動無常以及本產品的適用人羣是經過校園認證的學生，本平臺只提供點單方和配送方提供食堂菜品、配送價格等信息的公佈，所涉及的金錢只包括配送價格。具體飯菜的價格（包含打包費）以支付寶、微信、一卡通等的消費記錄憑證爲基礎進行支付。在信用機制和身份認證機制下，服務方與被服務方的交易是私下進行的。

第十組提問：是否考慮過以可視化地圖的形式向用戶展現配送員的配送狀況？

現階段暫時沒有考慮以可視化的形式展現配送員的送餐狀況，緣由以下：校內食堂離宿舍距離近，一旦接單成功配送時間會很短。但這會是咱們平臺能夠爭取的方向，若是條件容許，咱們可能會在beta版本加以實現。

第十一組提問：能不能預計送達時間呢?

能夠，在點單和配送的界面都有填寫預計送達時間和預計配送時長。

第十二組提問：建議加入商家端，商家能夠自定義菜單，價格也能夠更及時透明更新。另外關於封條那個建議我以爲很是不錯，這裏+1

小雞帶飯是一款主打校內同窗互相帶飯的小程序。暫時沒有考慮引入商家入駐的功能，由於與美團等產品相比，咱們在這方面不具有競爭性。封條有在考慮範圍，在有必定用戶羣體之後咱們會和食堂協商，而後推出咱們的定製封條。

提供《需求規格說明書》做爲隨筆的附件（通過修改的最終版本）（10 1分）

需求規格說明書

遇到的困難及解決方法（11 2分）

• 困難描述
  • 對驗收驗證標準沒有明確的定義致使工做推遲
  • 從無到有的原型設計，工具沒法肯定
• 作過哪些嘗試
  • 從多份文檔提取驗收驗證標準的寫法，並加以理解
  • 嘗試多種原型設計工具，最終決定使用墨刀
• 是否解決
  已所有解決
• 有何收穫
  不少東西不懂須要多嘗試，纔能有突破

PSP（12 1分）

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	· 計劃	60	60
· Estimate	· 估計這個任務須要多少時間	60	60
Development	· 開發	1770	2550
· Analysis	· 需求分析 (包括學習新技術)	240	300
· Design Spec	· 生成設計文檔	60	60
· Design Review	· 設計複審	60	60
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	30	30
· Design	· 具體設計	60	120
· Coding	· 具體編碼	1200	1800
· Code Review	· 代碼複審	30	90
· Test	· 測試（自我測試，修改代碼，提交修改）	90	90
Reporting	報告	140	140
· Test Repor	· 測試報告	60	60
· Size Measurement	· 計算工做量	20	20
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	60	60
	· 合計	1970	2750

學習進度條（13 1分）

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
1	0	0	0	0	0
2	0	0	0	0	0
3	0	0	0	0	0