組隊后的團(tuán)隊項目的整體計劃安排(1 2分)

序號

持續(xù)時間

主要任務(wù)

是否完成

一

9.28

組隊

√

二

10.1-10.21

制作團(tuán)隊選題報告

√

三

10.22-10.27

制作團(tuán)隊需求分析報告

√

四

10.28-11.2

團(tuán)隊編程準(zhǔn)備與制作

×

五

10.28-11.11

alpha沖刺準(zhǔn)備

×

六

11.12-11.22

進(jìn)行alpha沖刺，并發(fā)布alpha版本

×

七

11.23-12.3

beta沖刺準(zhǔn)備

×

八

12.4-12.13

進(jìn)行beta沖刺，并發(fā)布最終版本

×

九

12.14-課程結(jié)束

課程總結(jié)

×

團(tuán)隊分工(2 5分)

alpha版本需做事情明細(xì)

1).先完成實現(xiàn)小程序必須完成的界面以及接口，拓展功能暫不考慮

2).前端為本組6位女生，各自負(fù)責(zé)自己的原型模塊

3).后端為本組5位男生，其中3個負(fù)責(zé)函數(shù)，2個負(fù)責(zé)數(shù)據(jù)庫

成員分工明細(xì)及TODO list

成員分工

項目經(jīng)理

鄭裕恒

函數(shù)與接口設(shè)計

潘海東，余廷龍，方瑞雄

數(shù)據(jù)庫

鄭裕恒，翁世豪

原型修改與實現(xiàn)

張萬聰，劉詩琳，嚴(yán)欣，陳蘇蘇，王玥，馬麗華

TODO list

燃盡圖

思維導(dǎo)圖(3 2分)

總思維導(dǎo)圖

功能模塊

市場定位與分析模塊

營銷策略模塊

風(fēng)險管理模塊

團(tuán)隊分工與貢獻(xiàn)比例(4 2分)

姓名

主要工作

貢獻(xiàn)比例

方瑞雄

評審表設(shè)計，博客撰寫，最終評審表整理

10%

嚴(yán)欣

報告中驗收驗證標(biāo)準(zhǔn)的編寫

5%

陳蘇蘇

報告中驗收驗證標(biāo)準(zhǔn)的編寫，報告細(xì)節(jié)更改

10%

翁世豪

報告中功能描述的編寫，思維導(dǎo)圖設(shè)計

8%

潘海東

報告中功能描述的審核

2%

劉詩琳

原型圖設(shè)計，記錄課堂提問問題

10%

鄭裕恒

PPT制作，文檔中交互原型設(shè)計，PPT演講人員，圖片修整與美化

15%

王玥

報告中驗收驗證標(biāo)準(zhǔn)的編寫，原型設(shè)計，logo設(shè)計與解讀

10%

張萬聰

原型圖設(shè)計，博客撰寫

10%

余廷龍

對報告的排版與整理，UML圖設(shè)計，報告引言撰寫

15%

馬麗華

報告中驗收驗證標(biāo)準(zhǔn)的編寫

5%

評審表設(shè)計(5 1分)

UML(6 10分)

由于我們產(chǎn)品功能不多沒辦法拆分得那么細(xì)，所以每個圖整合后只做一份(很用心做的，此條已征得助教的同意)

用例圖

描述的部分：

下單用戶與配送用戶之間通過訂單進(jìn)行聯(lián)系

面臨的問題：

不同用戶雙方可能會對訂單產(chǎn)生爭議

訂單無法第一時間更新

解決了哪些問題：

下單用戶與配送用戶對訂單的操作有主動權(quán)，并且實現(xiàn)對訂單的可視化

類圖

描述的部分

用戶的個人信息和用戶對訂單的操作

廣場訂單的表現(xiàn)形式

訂單本身的狀態(tài)以及訂單衍生出的信息交互

面臨的問題

用戶信息可能不夠全面，導(dǎo)致無法準(zhǔn)確得到用戶信息

訂單的處理問題

解決了哪些問題

使用評論與點評功能解決了用戶之間的交互

使用標(biāo)簽讓訂單更具體，讓用戶更方便

活動圖

描述的部分

訂單生成與實現(xiàn)功能

面臨的問題

訂單管理功能

用戶對訂單的要求操作

解決了哪些問題

讓用戶對訂單有更多的主動權(quán)

狀態(tài)圖

描述的部分

描述了用戶創(chuàng)建訂單與查找訂單的過程

面臨的問題

用戶訂單無人受理

用戶訂單無法被搜索

解決了哪些問題

解決了用戶之間對訂單的評論

解決了用戶訂單發(fā)布錯誤重新下單的功能

實體關(guān)系圖

描述的部分

用戶，訂單，評論三者之間的屬有關(guān)系

面臨的問題

用戶信息未能如實呈現(xiàn)

訂單與用戶間的匹配不夠完善

評論無法完全解決用戶與訂單間的矛盾

解決了哪些問題

訂單與用戶關(guān)系之間的可視化

評論與訂單之間的平衡

用戶對評論的操作可執(zhí)行

工具選擇(7 2分)

UML圖設(shè)計的工具

我選擇的是starUML，因為這學(xué)期選修了《面向?qū)ο蠓治雠c設(shè)計》，老師要求我們自學(xué)UML，并且需要在課程設(shè)計里使用UML做軟件建模，然后他就推薦給我們這一款軟件，因為比較容易上手。

實體聯(lián)系圖是用億圖圖示做的，因為starUML沒法做實體聯(lián)系圖，所以就百度了一個軟件。(廷龍?zhí)峁?

原型圖設(shè)計的工具

墨刀，Axure Rp 9(萬聰詩琳提供)

對工具的評價(8 2分)

對于starUML,老師誠不欺我，這款軟件確實非常容易上手，只需要用鼠標(biāo)拖動工具欄的控件和線條便可以輕松繪制各種UML圖，導(dǎo)出圖片也非常方便，但是這款軟件也有明顯的缺點，就是畫出的圖比較不夠美觀，但是也還看得過去。對于億圖圖示，我覺得這款軟件也非常方便使用，可以畫各種圖，而且可以畫得非常漂亮，但是這款軟件是收費的，而且價格不低，它有15天試用期，但是在試用期導(dǎo)出的圖會有試用水印，所以我就只好通過調(diào)整畫圖的位置讓我的圖避開水印，然后再把我需要的部分截取下來。

墨刀界面不能批量導(dǎo)出為圖片，但是很多圖標(biāo)都是現(xiàn)成的，可以生成鏈接分享、團(tuán)隊多人協(xié)作以及各種對齊、參考線都挺好用的。

Axure Rp 9 不知道為什么在加入交互效果的時候會出現(xiàn)閃退，功能比墨刀更全面，可以生成HTML文件、可以批量導(dǎo)出圖片。

答辯總結(jié)(9 9分)

本組現(xiàn)場答辯得分

針對其他小組提問回答

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

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

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

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

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

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

第四組提問：無

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

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

在發(fā)布訂單的時候就可以設(shè)置配送時間約束

第七組提問：食品產(chǎn)生問題時平臺如何界定責(zé)任？

首先在注冊的時候用戶需要簽訂協(xié)議，在發(fā)生食品問題的時候告知平臺，平臺會出面聯(lián)系配送員和商家，并積極協(xié)助調(diào)查，具體的責(zé)任認(rèn)定要在了解責(zé)任源頭之后協(xié)商。

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

我們會限制配送的同學(xué)在一個時間段內(nèi)的接單數(shù)量，比如在一個小時內(nèi)最多只能接5單。

第九組提問：食堂食物的標(biāo)價是該應(yīng)用后臺更新嗎？怎么樣保證及時快速更新？如果食堂有打包費這樣的額外要求是用戶私下交易還是平臺來監(jiān)管？

由于食堂飯菜的價格及物價的波動無常以及本產(chǎn)品的適用人群是通過校園認(rèn)證的學(xué)生，本平臺只提供點單方和配送方提供食堂菜品、配送價格等信息的公布，所涉及的金錢只包括配送價格。具體飯菜的價格(包含打包費)以支付寶、微信、一卡通等的消費記錄憑證為基礎(chǔ)進(jìn)行支付。在信用機(jī)制和身份認(rèn)證機(jī)制下，服務(wù)方與被服務(wù)方的交易是私下進(jìn)行的。

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

現(xiàn)階段暫時沒有考慮以可視化的形式展示配送員的送餐情況，原因如下：校內(nèi)食堂離宿舍距離近，一旦接單成功配送時間會很短。但這會是我們平臺可以爭取的方向，如果條件允許，我們可能會在beta版本加以實現(xiàn)。

第十一組提問：能不能預(yù)計送達(dá)時間呢

可以，在點單和配送的界面都有填寫預(yù)計送達(dá)時間和預(yù)計配送時長。

第十二組提問：建議加入商家端，商家可以自定義菜單，價格也可以更及時透明更新。另外關(guān)于封條那個建議我覺得非常不錯，這里+1

提供《需求規(guī)格說明書》作為隨筆的附件(經(jīng)過修改的最終版本)(10 1分)

遇到的困難及解決方法(11 2分)

困難描述

對驗收驗證標(biāo)準(zhǔn)沒有明確的定義導(dǎo)致工作推遲

從無到有的原型設(shè)計，工具無法確定

做過哪些嘗試

從多份文檔提取驗收驗證標(biāo)準(zhǔn)的寫法，并加以理解

嘗試多種原型設(shè)計工具，最終決定使用墨刀

是否解決

已全部解決

有何收獲

很多東西不懂需要多嘗試，才能有突破

PSP(12 1分)

PSP2.1

Personal Software Process Stages

預(yù)估耗時(分鐘)

實際耗時(分鐘)

Planning

· 計劃

60

60

· Estimate

· 估計這個任務(wù)需要多少時間

60

60

Development

· 開發(fā)

1770

2550

· Analysis

· 需求分析 (包括學(xué)習(xí)新技術(shù))

240

300

· Design Spec

· 生成設(shè)計文檔

60

60

· Design Review

· 設(shè)計復(fù)審

60

60

· Coding Standard

· 代碼規(guī)范 (為目前的開發(fā)制定合適的規(guī)范)

30

30

· Design

· 具體設(shè)計

60

120

· Coding

· 具體編碼

1200

1800

· Code Review

· 代碼復(fù)審

30

90

· Test

· 測試(自我測試，修改代碼，提交修改)

90

90

Reporting

報告

140

140

· Test Repor

· 測試報告

60

60

· Size Measurement

· 計算工作量

20

20

· Postmortem & Process Improvement Plan

· 事后總結(jié), 并提出過程改進(jìn)計劃

60

60

· 合計

1970

2750

學(xué)習(xí)進(jìn)度條(13 1分)

周數(shù)

本周學(xué)習(xí)耗時(小時)

實際完成任務(wù)

1

46

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。