組隊后的團隊項目的整體計劃安排(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分)

本組現場答辯得分

針對其他小組提問回答

第一組提問：對于紫荊一樓這種菜品不固定的檔口，有沒有考慮增加顯示菜品的功能，有沒有考慮過如果在食堂排隊的同學會因為配送員點好幾份等待過久而發生糾紛

由于我們平臺現在不是定位為為食堂進行銷售，而是通過點單方自行決定吃什么東西，所以暫時沒有考慮過引進菜品。當這個小程序后期成熟后，會考慮加進去。配送員應該是避開高峰排隊時間的，我們的小程序目的也是錯峰購買，所以這個問題產生的幾率應該不大。

第二組提問：我覺得挺不錯的，就是好像跟我們的項目有些撞車了，建議多增加些額外小功能來吸引用戶和凸顯自己的賣點

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

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

我們鼓勵在食堂的人來當配送員，所以他們對食堂的菜品是否銷售一般能夠及時掌握，如果無法滿足點單人的要求，可以聯系取消訂單或者更換菜品。

第四組提問：無

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

第六組提問：發布配送可否有時間范圍約束？

在發布訂單的時候就可以設置配送時間約束

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

首先在注冊的時候用戶需要簽訂協議，在發生食品問題的時候告知平臺，平臺會出面聯系配送員和商家，并積極協助調查，具體的責任認定要在了解責任源頭之后協商。

第八組提問：如何解決因一個人接單太多，而導致食品的新鮮度不好，從而導致用戶對使用軟件的意愿降低的問題？

我們會限制配送的同學在一個時間段內的接單數量，比如在一個小時內最多只能接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分)

周數

本周學習耗時(小時)

實際完成任務

1

46

完成了原型的設計 ,報告，PPT，評審表制作。最終評分，博客撰寫 。

總結

以上是生活随笔為你收集整理的staruml透明_第05组 团队项目-需求分析报告的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。