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

目錄

• 1.總體計劃安排
• 2.團隊分工
  • ①alpha版本須要作的事
  • ②各成員分工及TODO list
  • ③燃盡圖
• 3.思惟導圖
  • ①思惟導圖-首頁
  • ②思惟導圖-個人
  • ③思惟導圖-消息
  • ④思惟導圖-社區
• 4.每位成員的貢獻比，工做流程圖
• 5.評審表格
• 6.UML
• 7.工具選擇
• 8.對工具的評價
• 9.答辯總結
  • ①本組的現場答辯得分
  • ②回答其餘小組對本小組的提問
  • ③標明修改完善之處
• 10.《需求規格說明書》
• 11.遇到的困難和解決方法
• 12.PSP
• 13.學習進度條

組長博客

1.總體計劃安排

2.團隊分工

①alpha版本須要作的事

前端

後端

②各成員分工及TODO list

③燃盡圖

（由於整個團隊項目的ddl與完成時間未定，因此此處只是本次「需求分析報告」的燃盡圖）

3.思惟導圖

①思惟導圖-首頁

直觀充分地展現了借唄的兩個核心業務：
活動室的申請和管理、我的倉庫裏物品的租借和管理。

②思惟導圖-個人

「個人」頁面主要分爲：我租借的、我管理的、信用度三大部分。
我租借的：包含用戶所租借活動室或物品的詳細信息、到期時間，同時也包含歸還與評價
我管理的：相似於「我租借的」，包含所借物品的信息和被租用次數
信用度：此功能主要用於對用戶的誠信程度進行量化評估

③思惟導圖-消息

爲用戶提供租用申請的消息、學校或學院的重要通知。
而且爲每位用戶提供不一樣的數據分析，讓用戶能充分了解本身的物品使用狀況。

④思惟導圖-社區

「社區」功能是咱們爲用戶提供的一個社交平臺，
讓用戶在租借/使用物品的同時能參與到不一樣的社交活動，
同時也能讓不一樣用戶的各類閒置物品充分流通。

4.每位成員的貢獻比，工做流程圖

5.評審表格

6.UML

類圖
1.描述的是app的功能方面內容
2.仍需改進：項目模塊定義的不夠清晰 各個類之間的聯繫較爲繁瑣
3.統一了參數，整體設計，提升先後端開發的效率

用例圖
1.描述了借唄app的各部分功能以及對各部份內容的具體化。
2.若是按照用戶習慣來進行排版，提升使用的友好性
3.讓各個用戶使用的功能更加直觀，防止了用戶權限混雜的問題

狀態圖
1.描述的是物品的各個狀態
2.仍需改進：每一個部分的具體轉化還不夠徹底，須要細緻優化。
3.直觀的體現了物品的狀態，讓後面的設計思路更加清晰

活動圖
1.描述了用戶借入和租出的後續操做和結果。
2.仍需改進：更多的功能和操做難以在圖中表示出來
3.直觀的表示出物品租借的步驟

實體關係圖
1主要描述的是系統的概念結構設計的部分。
2實體的決定、實體屬性的決定、實體之間的關係（包括了一對一，一對多，多對一，多對多)
3各實體屬性的決定和實體間的關係和關聯

7.工具選擇

億圖軟件

8.對工具的評價

這個軟件的能夠做不少的圖，並且將各類圖分類，有不少東西能夠直接用，不過因爲沒有下載破解版因此導出的圖片不清晰且有水印，能夠去百度使用破解版。

9.答辯總結

①本組的現場答辯得分

51.72分

②回答其餘小組對本小組的提問

1.便利性仍是挺不錯的，但願重點考慮下安全性和互動性，能夠往社交方面走一走（第二組）
安全性的問題咱們考慮用設置押金來解決；借唄有設置「社區」這個功能，用以知足不一樣用戶的社交需求。

2.各個部門管理的不止有活動室，還有一些屬於他們的物資，好比體育部就有記分牌之類的，能夠考慮讓部門掛出空閒的物資來出借（第三組）
對於部門來講的閒置物資，可讓管理人員以部門的名義創建我的帳號來進行出借。

3.未提問（第四組）
...

4.是否能夠對不想要出借的部門進行獎勵或者合做來增長本身APP的可借數量，不止活動室，不少部門有他們獨有的物資。（第五組）
咱們對於活動室的管理首先要跟學院那邊商定好，對於願意出借活動室的部門會以獎勵部員信用度和可借數量增長的方式進行合做（信用度越高，可借物品數量越多）

5.大家如何作到獲取各個部門活動室以及其餘場地的租借權利？（第六組）
在借唄上線之前，會先與學院和相關老師進行溝通來進行活動室的協調

6.大家數據庫到底是mysql仍是sql server（第七組）
mysql

7.如何確保借用出去的物品或者是活動室的完整度，以及軟件是如何進行盈利的？（第八組）
用戶在出借和歸還的時候都須要對活動室或者物品上傳照片來確保完整度；至於盈利問題，平臺會在須要租金的物品的出借成功時，收取小部分佣金。

8.對於某些已經被主席團分配給學院各個部門的活動室，如何跟相關的部門負責人協調，以確保有多方同時使用同一個活動室而形成的不便？（第九組）
咱們會協調各個部門，經過獎勵的方式讓部門出借活動室；同時在發佈出借活動室消息的時候，租借者能夠選擇本身獨用或者在「社區」中發佈消息招攬你們共同使用。

9.與學院、老師的合做有具體可行的方案嗎？（第十組）
在借唄上線之前，會先與學院和相關老師進行協商來進行活動室的協調，具體方案還正在考慮中。

10.活動室的管理是否要和學院先作好溝通（第十一組）
在借唄上線之前，會先與學院和相關老師進行溝通來進行活動室的協調

11.如何避免具備活動室鑰匙的人出租活動室謀取私利？以及活動室原有物資的安全問題（第十二組）
對於出租活動室，平臺是不設置租金選項的，即租借活動室只須要申請不須要租金；對於安全問題，則經過在租借和歸還時上傳照片來解決。

③標明修改完善之處

①調整了表格框線的問題
②修改了環境要求和軟件接口
③刪除了一些沒必要要的內容

10.《需求規格說明書》

《需求規格說明書》
（提取碼：ny78）

11.遇到的困難和解決方法

困難描述： 沒有android開發經驗，得邊學邊寫。由於沒有實際項目經驗，分工不是太明確
作過哪些嘗試: 閱讀開發文檔和書籍；詢問有經驗的人
是否解決: 是
有何收穫: 有了必定的android開發能力

困難描述：需求報告工做量大，需求複雜繁多，難以完成；需求報告排版格式要求細緻繁複，修改複雜
作過哪些嘗試：百度搜索相關博客和文檔閱讀了解
是否解決：是
有何收穫：經過博客和文檔的閱讀，訓練了閱讀博客和文檔的能力；學會合理分配文檔工做，實現了最後版本的需求報告

12.PSP

PSP2.1	Personal Software Process Stages	預估耗時 (小時)	實際耗時 (小時)
Planning	計劃	12	15
· Estimate	· 估計這個任務須要多少時間	12	15
Development	開發	2	2
· Analysis	· 需求分析 (包括學習新技術)	5	5
· Design	· 生成設計文檔	5	5
· Design Review	· 設計複審	0.2	0.3
· Coding Standard	· 代碼規範 (爲目前的開發制定或選擇合適的規範)	0	0
· Design	· 具體設計	2	3
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	· 測試(自我測試，修改代碼，提交修改)	0	0
Reporting	報告	0	0
· Test Report	· 測試報告	0	0
· Size Measurement	· 計算工做量	0.1	0.1
· Postmortem & Process Improvement Plan	· 過後總結, 並提出改進計劃	0.5	0.5
	· 合計	14.8	15.9

13.學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
1	0	0	12	12	基本瞭解了原型圖的設計理念與實現方法，掌握了墨刀的基礎用法
2	412	412	20	32	構思算法，實現基本框架
3	660	1072	36	68	算法改進
4	148	1220	15	83	瞭解接口的使用，學習了github使用規範
5	0	1220	15	98	明確了團隊項目選題
6	0	1220	15	113	明確了團隊項目需求