需求分析報告

寫在前面

組長博客

另外圖看不清可以點開看大圖

組隊后的團隊項目的整體計划安排

時間	計划
9.26-10.19	選題報告及答辯
10.20-10.26	需求分析報告及答辯
10.28-10.29	接口設計
10.30-11.3	總體框架搭建
11.4-11.22	Alpha
11.23-12.13	Beta
12.14-？	完善

詳見下節的Todo List

團隊分工

Alpha Goal

后端

1. 用戶認證模塊完整
2. 點記錄和分享模塊實現
3. 軌跡記錄和分享模塊實現
4. 社交模塊完整實現
5. 平台集成和社會化分享能做多少算多少

App端

1. 用戶認證模塊完整
2. 點記錄和分享模塊實現
3. 軌跡記錄和分享模塊實現
4. 社交模塊基本實現
5. 平台集成和社會化分享能做多少算多少

成員分工明細

成員	分工
王永福	派任務、催進度、后端、App
孫承愷	算法設計和實現、App實現
邱暢傑	社會化分享模塊
丁樞桐	社會化分享模塊、算法設計和實現
張凌昕	App、公共事務
余琳玲	App、文案
林青霞	App
林星培	App
徐祖豪	App

其中App部分的細分見Todo，采用動態分配的認領制度

Todo

燃盡圖

思維導圖

本次團隊分工

流程

工作量評估

成員	工作量
張凌昕	5%
孫承愷	12%
邱暢傑	8%
林星培	10%
余琳玲	14%
林青霞	10%
王永福	23%
徐祖豪	5%
丁樞桐	13%

具體理由可見前節的流程圖

評審表

別看了

UML

成員成果匯集

Part 1 類圖

• 這里描述的是系統哪部分？

  • 描述了系統各部分數據的關系

• 這部分要面臨什么樣的問題 ？

  • 各部分關聯和划分

• 以下設計解決了哪些問題

  • 解決了開發者對於各個類體之間關系的宏觀認識

Part 2 用例圖

• 這里描述的是系統哪部分？

  • 用戶與系統的交互用例

• 這部分要面臨什么樣的問題 ？

  • 哪些用戶能干什么

• 以下設計解決了哪些問題

  • 明晰了用戶類型及操作

Part 3 認證狀態圖

• 這里描述的是系統哪部分？

  • 用戶與系統認證的狀態

• 這部分要面臨什么樣的問題 ？

  • 面臨賬號的登入注冊的設計邏輯的問題

• 以下設計解決了哪些問題

  • 解決了在設計登入注冊找回密碼這幾個方面的邏輯順序

Part 4 點分享狀態圖

• 這里描述的是系統哪部分？

  • 點分享的狀態

• 這部分要面臨什么樣的問題 ？

  • 面臨發布和瀏覽點分享的設計邏輯的問題

• 以下設計解決了哪些問題

  • 解決了發布和瀏覽點分享的狀態轉換問題

Part 5 軌跡狀態圖

• 這里描述的是系統哪部分？

  • 軌跡的狀態

• 這部分要面臨什么樣的問題 ？

  • 面臨記錄編輯軌跡的設計邏輯的問題

• 以下設計解決了哪些問題

  • 解決了記錄編輯軌跡的狀態轉換問題

Part 6 活動圖

• 這里描述的是系統哪部分？

  • 用戶使用系統的流程

• 這部分要面臨什么樣的問題 ？

  • 用戶可能不清楚系統的操作邏輯

• 以下設計解決了哪些問題

  • 明晰了用戶的操作順序和操作預期結果

Part 7 實體關系圖

• 這里描述的是系統哪部分？

  • 系統間各實體的關系

• 這部分要面臨什么樣的問題 ？

  • 各實體間如何組織

• 以下設計解決了哪些問題

  • 明確了各個實體的屬性及其間的關系

Part 8 部署圖

• 這里描述的是系統哪部分？

  • 系統部署架構

• 這部分要面臨什么樣的問題 ？

  • 系統如何部署

• 以下設計解決了哪些問題

  • 明確了系統部署是各個組件的節點分配

關於工具

主要使用了幾個工具：Visio、Process On、Visual Paradigm、StarUML

• Visio: 強大，不管對於初學者還是有高級要求的人員都適用
• Process On: 簡單易上手，對初學者友好，但高級功能欠缺，且不能導出到能在其他軟件編輯的通用格式，偶有小Bug
• Visual Paradigm: 非常高級的工具，學習曲線陡峭，難以掌握
• StarUML: 專門畫UML的，易用，強大，但比較卡，且難以破解

答辯總結

得分

組號	分數
1
2	54.6
3	51.3
4
5
6
7
8	47.4
9	50.4
10
11
12	49.2
平均分	50.3

截至本博客撰寫時(2019-10-27T17:30)，空白為未評分的小組

Q&A

1

• Q: 請問你們對帖子的內容有限制或審核嗎？如何規避大家都不分享軌跡而發布一些與軟件無關的內容？
• A: 后期上線時我們可以引入簡單的關鍵詞審查機制或引入第三方內容過濾服務提供商緩解這個問題

2

• Q: 創意還是很不錯的，希望將重點放在吸引用戶量上，或者將分享內容與其他社交平台聯動獲取更大的關注度
• A: 謝謝您的建議，我們會認證考慮的

3

• Q: 對那些積極分享或是分享內容優秀的用戶會不會有適當的獎勵機制？
• A: 我們在上線后可以考慮贈送增值服務等方式來獎勵，或推出原創激勵計划

4

截至本博客撰寫時(2019-10-27T17:30)，尚未提問

5

截至本博客撰寫時(2019-10-27T17:30)，尚未提問

6

• Q: 記錄軌跡的時候是否可以停止一段時間后，再繼續上一次的記錄？
• A: 我們會考慮加入此功能，如果時間允許

7

• Q: 為什么在這次作業中把使用cordova改成了Android
• A: 我們在前期調研趟坑中發現了Cordova的地圖存在較為嚴重的性能問題

8

• Q: 對用戶的需求場景還可以進行多一些的調查，請問如何去審核一些不文明的分享動態？
• A: 謝謝您的建議。后期上線時我們可以引入簡單的關鍵詞審查機制或引入第三方內容過濾服務提供商緩解這個問題

9

• Q: 創意挺好的，想請問該軟件的可移植性考慮是？
• A: 目前計划使用原生Android開發，暫無其他平台計划

10

• Q: 請問你們靠什么吸引用戶在一眾同類app中選擇使用你們的app呢？
• A: 我們的App目前來說更輕量，不過於商業化，且有在軌跡上進行標記的功能和基於位置的社交功能，相信可以吸引用戶

11

• Q: 沒有安卓基礎或許用小程序上手快一點？
• A: 確實如此。但是小程序對設備能力的調用限制較多，且網頁應用有性能問題

需求分析報告

其中有修訂記錄
另外根據柯老板的建議修改了字體大小
別看了

最終版本，散了吧

遇到的困難及解決方法

困難描述

本次作業要求完成一份需求分析報告，組內同學都沒有相關經驗

做過哪些嘗試

根據作業要求和Checklist, 網上找了幾份模板，嫖了一下往屆學長學姐的報告，最后形成了一份框架，然后根據框架分配任務，完成報告。

是否解決

是

有何收獲

了解了一份完整的需求分析報告應該包括哪些內容。以及需求分析報告的目標人群是誰，文字應該如何組織才能夠達到寫這份報告的目的。對於規范文本的格式也有了更多了解。

PSP

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	60	60
· Estimate	· 估計這個任務需要多少時間	60	60
Development	開發	980	1560
· Analysis	· 需求分析 (包括學習新技術)	1200	1200
· Design Spec	· 生成設計文檔	120	240
· Design Review	· 設計復審 (和同事審核設計文檔)	60	120
· Coding Standard	· 代碼規范 (為目前的開發制定合適的規范)	0	0
· Design	· 具體設計	0	0
· Coding	· 具體編碼	0	0
· Code Review	· 代碼復審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	110	170
· Test Report	· 測試報告	20	0
· Size Measurement	· 計算工作量	30	30
· Postmortem & Process Improvement Plan	· 事后總結, 並提出過程改進計划	60	120
合計		1150	1790

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時(小時)	累計學習耗時（小時）	重要成長
8	780	5460	8	70	學習了Android開發基礎；需求分析報告編寫