團隊項目-需求分析報告

組長博客連接

一、總體計劃安排

階段序列	階段時間	主要階段任務	完成狀況
第一階段	9.18	團隊成立	已完成
第二階段	9.18-9.25	肯定選題及協商分工	已完成
第三階段	9.25-10.14	前期學習及準備	已完成
第四階段	10.14-10.20	選題報告	已完成
第五階段	10.20-10.27	需求分析報告	已完成
第六階段	10.27-11.9	完成用戶登陸模塊	待完成
第七階段	11.9-11.23	完成用戶車輛登記板塊	待完成
第八階段	11.23-11.30	完成用戶留言板塊	待完成
第九階段	12.1-12.10	完成動態板塊	待完成
第十階段	12.10-12.18	完成灰度測試	待完成
第十一階段	12.19-12.27	團隊工做量整理，公測	待完成
第十二階段	12.28	團建	待完成

二、團隊分工

肯定 alpha 版本須要作哪些事情

狀態	分工內容	截止時間	負責人
進行中	註冊界面	11月09日	石曉楠
進行中	登陸界面	11月09日	陳啓昌
未開始	車輛登記模塊	11月23日	劉曉翔
未開始	用戶留言模塊	11月30日	王焱
未開始	動態板塊	12月10日	楊晉南
未開始	其餘界面設計	12月10日	宋奕

各成員分工明細及 TODO list

成員姓名	分工	to do list
宋奕	項目經理、後端工程師	1.負責成員分工及組織會議，推進項目進程 。2.負責後端接口及邏輯功能的實現，服務器的部署及數據庫的構造
林少惠	UI設計師、團隊資源管理師	1.負責項目原型的邏輯功能設計，app的UI設計。2.負責設計及撰寫文檔，拍攝記錄團隊進程，溝通先後端
楊藍婷	UI設計師、團隊資源管理師	1.負責項目原型的邏輯功能設計，app的UI設計,2.負責設計及撰寫文檔，拍攝記錄團隊進程，溝通先後端
張雨	UI設計師、團隊資源管理師	1.負責項目原型的邏輯功能設計，app的UI設計,2.負責設計及撰寫文檔，拍攝記錄團隊進程，溝通先後端
陳啓昌	前端工程師	負責web端界面的功能實現，及先後端交互
石曉楠	前端工程師	負責web端界面的功能實現，及先後端交互
陳靖雯	前端工程師	負責web端界面的功能實現，及先後端交互
楊晉南	移動端工程師	負責安卓端及iOS端的接口交互，和頁面的實現
劉曉翔	移動端工程師	負責安卓端及iOS端的接口交互，和頁面的實現
王焱	移動端工程師	負責安卓端及iOS端的接口交互，和頁面的實現
劉華一	算法工程師	負責算法學習、設計及開發

燃盡圖

三、思惟導圖

四、評估貢獻比例

撰寫需求規格說明書的工做流程

• 項目經理肯定需求規格說明書的內容
  
• 小組開會肯定app界面的各個模塊和功能。
• 一部分人先完成說明書的文字部分和原型、UML圖等。

• 另外一部分人最後完成PPT製做、PPT演講準備、整合需求說明書內容。

  組員分工

  任務內容	分工狀況及分數
  需求報告文字描述部分	曉楠六、張雨2
  思惟導圖	曉楠2
  類圖	宋奕2
  ER圖	晉南2
  數據字典	晉南4
  外部需求	宋奕4
  狀態圖、活動圖	張雨4
  驗收驗證標準	張雨2
  整合報告內容、排版	曉楠二、靖雯4
  原型設計	少惠1五、靖雯五、曉楠3
  PPT製做	藍婷15
  PPT演講	啓昌6
  評審表設計	靖雯1
  評審表彙總、錄入	張雨2
  填寫評審表和提問	宋奕二、啓昌二、晉南二、曉翔二、王焱二、華一二、藍婷二、少惠二、張雨二、曉楠二、靖雯2
  博客撰寫	張雨4
  開會	宋奕二、啓昌二、晉南二、曉翔二、王焱二、藍婷二、少惠二、張雨二、曉楠二、靖雯2
  分工、計算貢獻率、提交材料	靖雯3

  組員工做量比例

  姓名	貢獻率
  宋奕	10/130=8%
  啓昌	10/130=8%
  晉南	10/130=8%
  曉翔	4/130=3%
  王焱	4/130=3%
  華一	2/130=2%
  藍婷	19/130=15%
  少惠	19/130=15%
  張雨	18/130=14%
  曉楠	16/130=12%
  靖雯	16/130=12%

  五、評審表格設計

  六、UML

  必作圖

  用例圖

  描述的部分：
  （1）描述了咱們軟件必須完成的任務，定義了必須完成的軟件功能；
  （2）基本呈現用戶與用例之間的具體關係；
  （3）基本表達系統的基本功能；
  （4）基本表達系統的具體行爲。
  面臨的問題：
  （1）如何具體對用例進行分類，使得用例更加具體；
  （2）如何對用戶與不一樣用例之間的關係詳細分析。
  解決的問題：
  （1）初步獲取用戶的需求；
  （2）指導測試；
  （3）在整個過程當中對其餘工做流起到指導做用。
  

  類圖

  活動圖

  描述的部分：
  (1)動態生成過程。
  (2)聯繫車主過程。
  面臨的問題：
  （1）面臨帳戶管理問題。
  （2）面臨聯繫車主問題。如何使用戶較爲快速的聯繫到對應的車主。
  解決的問題：
  使用戶能夠查詢到車主，方便快捷的解決難題。
  

  狀態圖

  【part1】

  描述的部分：描述了用戶登陸及未登陸使用的狀態。
  面臨的問題：面臨用戶帳號管理的問題。
  解決的問題：
  （1）解決了用戶註冊登陸流程的問題。
  （2）解決了用戶找回密碼的問題。
  

  【part2】

  描述的部分：描述了用戶尋找車主的狀態。
  面臨的問題：面臨掃描識別及車牌識別的問題。
  解決的問題：
  （1）解決了用戶經過掃描車身進行識別的問題。
  （2）解決了用戶經過輸入車牌號進行識別的問題。
  （3）解決了用戶經過本平臺尋找車主的問題。
  

  【part3】

  描述的部分：描述了用戶動態編輯、展現及評論的狀態。
  面臨的問題：面臨用戶添加自定義動態及其顯示、評論的問題。
  解決的問題：
  （1）解決了用戶自定義建立動態、顯示動態的問題。
  （2）解決了用戶評論他人動態的問題。
  

  實體關係圖

  其餘圖

  成員成果聚集

• part1

  （1）這裏描述的是系統的登陸部分
  （2）這裏面臨的是實名認證的問題
  （3）咱們經過添加數據庫的學生表來解決了這個問題
  
  這個表記錄了從1998-2019的學生身份數據。

• part2

  （1）這裏描述的是系統的車牌綁定部分
  （2）這裏面臨的是套牌車的問題
  （3）咱們經過多拍幾張照片或者選取特色來解決了這個問題這邊增長了兩個表
  

  七、工具選擇

  ProcessOn在線做圖工具

  八、對工具的評價

  ProcessOn是一個在線做圖工具的聚合平臺，它能夠在線畫流程圖、思惟導圖、UI原型圖、UML、網絡拓撲圖、組織結構圖等等，高效易用，並且支持團隊協做，可多人同時製做。

  九、答辯總結

  本組的現場答辯得分 去除最高總分，最低總分，求平均分（保留2位小數）

  團隊組別	第01組	第02組	第03組	第04組	第05組	第06組	第07組	第08組	第09組	第10組	第11組	第12組	本組最終得分
  他組隊本組的評分	89	87	79.9	88	86	90	86	85	84	85	81	77	85.09

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

團隊組別	提出的問題	回答
第01組	車牌識別提取號碼的功能打算怎麼實現？本身寫算法仍是直接用別人的輪子？	用別人的輪子
第02組	Q1：如何說服用戶將本身的車牌信息錄入？Q2：以及別人隨意查看車主信息彷佛有些不合理？Q3：且替人挪車的收益感受不是那麼大，時效性也不高，受衆和使用頻率也不會很高	A1：這就靠咱們的前期宣傳，若是可能的話，咱們會嘗試與學校合做，加大用戶量；A2：車主的信息是能夠自行選擇是否進行徹底公開的，相似電話號碼，若是車主不想透露，能夠經過平臺進行聯繫；A3:咱們會設立獎勵機制，若是你正好在求助的用戶附近，經過幫他挪車是樂於助人的同時又能夠賺的積分，和樂而不爲呢
第03組	產品如何盈利，如何鼓勵不是車主的其餘用戶幫忙挪車？	經過發放優惠券和別的商家或者小組合做
第04組	如何可以很及時的通知車主挪車？由於不是每一個人都隨時看手機。	因爲是推送因此咱們也沒辦法強制完成
第05組	初期用戶量不足的狀況下，大家的項目等於沒有挪車功能，一個沒有功能的應用就算客戶使用了，怎麼保證它在大家功能成熟前不刪了它呢？	咱們的app主要功能是挪車，可是不止這一個功能哦，還能夠在平臺上發佈你的買賣車信息以及若是您不當心將別人車的某些部分弄壞掉能夠進行留言之類的哦
第07組	屢次發出挪車消息無人應答，致使用戶體驗感不好，如何避免？	這個在項目初期是不可能避免的，可是中後期用戶總量增長，應該能夠緩解
第08組	建議是若是挪的不是本身的車而使用這個軟件來幫別人挪車或者經過其它方式，能夠收取適當的費用，來增長產品的盈利性	這個建議咱們會歸入考慮的，謝謝
第09組	能查看他人那麼多信息，信息安全如何保障？	咱們嚴格控制每條信息得保密，只要設置是保密，他人就看不見的
第10組	未提問...
第11組	獲取用戶手機號和車牌如何實現，真的會願意本身填上這些私密信息嗎，若是從其餘渠道獲取，是否是有侵犯我的隱私的問題？	手機號是能夠有隱藏的選項的，若是您不肯意將本身的手機號公佈出來，能夠隱藏起來
第12組	Q1:電話加密如何實現？Q2:基於網絡電話仍是傳統電路域電話？Q3:電路域電話存在一段傳輸沒法加密，網絡電話如何保證用戶能接到	A1: 電話加密是基於阿里雲的功能；A2:基於網絡電話；A3:阿里雲對用戶功能應該是有所保障

根據答辯中其餘組提出的意見和建議修改完善本組需求分析報告，並標明修改之處

針對永福所說的縮進問題，有作修改


對於token類型的改進

十、需求說明書

十一、遇到的困難及解決方法

困難描述

對《軟件需求規格說明書》較爲陌生，不知從何入手

作過哪些嘗試

咱們認真閱讀了做業中給出的 checklist，而後請教了以前的學長學姐。並閱讀了一些前輩的報告，最終肯定出框架，而後開始分工撰寫。

是否解決

是

有何收穫

瞭解了《軟件需求規格說明書》的框架和內容，明白了團隊協做的重要性，並體會到其中的樂趣。

十二、psp

---

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

1三、學習進度條

---

第N周	新增代碼（行）	累積代碼（行）	本週學習耗時（小時）	累積學習耗時（小時）	重要成長
1	0	0	10	10	作前期準備工做
2	0	0	12	22	撰寫選題報告
3	0	0	13	35	撰寫需求報告