- 班級：軟件工程1916|W
- 作業：項目原型設計
- 團隊名稱：SkyReach
- 目標：展示團隊風采，磨合團隊
- 原型工具：墨刀
- 博客PDF：點擊下載
| 隊員學號 | 隊員姓名 | 個人博客地址 | 備注 |
|---|---|---|---|
| 221600107 | 陳某某 | https://www.cnblogs.com/canceregg/ | 隊長 |
| 221600106 | 陳某 | https://www.cnblogs.com/chenhong1998/ | |
| 221600110 | 公孫某某 | https://www.cnblogs.com/gonggongsun/ | |
| 221600117 | 黃某某 | https://www.cnblogs.com/hsyuan0910/ | |
| 221600118 | 李某某1 | https://home.cnblogs.com/u/Anizwel/ | |
| 221600120 | 李某某2 | https://www.cnblogs.com/Azuration/ | |
| 221600122 | 史某某 | https://www.cnblogs.com/tentacion/ |
貢獻比例表：
| 隊員學號 | 隊員姓名 | 此次活動任務 | 貢獻比例 |
|---|---|---|---|
| 221600106 | 陳鴻 | 需求調查 | 5% |
| 221600107 | 陳家豪 | 安排任務，原型設計 | 25% |
| 221600110 | 公孫駿傑 | 原型設計，需求分析 | 30% |
| 221600117 | 黃盛遠 | 博客撰寫，需求分析 | 25% |
| 221600118 | 李鴻斌 | 需求調查 | 5% |
| 221600120 | 李子琪 | 需求調查 | 5% |
| 221600122 | 史雲天 | 需求調查 | 5% |
一、NABCD模型
Need
- 提供一個匿名交流平台
- 提供一個興趣分流社區
- 讓用戶暢所欲言（法律與道德允許范圍內）
- 提供群聊與私信功能
- 提供對於關鍵字的統計功能
Approach
- 設計一個基於安卓的APP社區
- 發表了問卷調查征集用戶意見
- 前端采用網絡請求OKhttp，圖片加載glide，輕量數據庫greenDAO,異步鏈式RxJava等框架，后端用PHP,APACHE服務器,MYSQL數據庫部署。采用前后端分離的模式進行開發
Benefit
- 用戶可以暢所欲言，在一個不記錄自己名稱的地方合理發表自己的看法。（法律與道德允許范圍內）
- 用戶如果有需求，可以主動聯系與自己有相同興趣的“隱友”
- 教育專區中，用戶可以提出對老師適當的建議，管理員可以根據重復出現的字眼進行統計，找出比較迫切的問題。
Competitors
- 優點
- 移動端，方便用戶隨時隨地使用
- 操作簡單方便
- 集合了市場上某些軟件的優點，並且界面簡潔
- 缺點
- 語言的管理困難，需要多數管理員來處理社區舉報
- 運營成功過於高
Delivery
- 線上推廣
- QQ、微信等社交軟件
- 推文推廣
- 線下推廣
- 貼宣傳海報
- 人脈朋友間的推廣
二、 問題回答
- 功能不夠完善，過於簡單
因為團隊中沒有一人有完全的開發經驗，所以都是新手需要重新學期，因此開始定下的目標比較小，首先保證能夠最后提交一個完成的項目。如果中間進度夠快的話，我們的拓展功能還是有考慮很多，例如不僅僅是發帖子，也允許進行投票、提供一些數據和詞匯的統計分析等等。如果項目能夠順利，會大大擴展功能的。
- 如何屏蔽惡意言論
這個也是匿名社區必須要面對的問題，言論自由並非真正的自由。過於自由的言論，總會有惡意的不良事件產生。最初的想法，是依靠簡單的非法字眼排除，以及人工審核。即，如果有敏感字眼的帖子，禁止上傳。管理員可以偶爾看一眼社區，對於熱門的帖子查看是否不合法。之后，如果項目順利，則可以研究引入人工智能的方式，減少人工的成本。
- 如何解決人工審核發帖工作量大的問題
如同，上述。首先，進行簡單的敏感字眼審查，包含敏感字眼的自動屏蔽。前期，無法引入人工智能算法時，為了減輕管理員的工作量，只要對於熱門的帖子進行審核，可以比較大減輕壓力。之后，如果有足夠的能力，可以加入人工智能算法，實現輔助審核。同時，對於用戶加入一個信譽機制，如果經常性發非法字眼，則會被禁言。
- 匿名聊天不切實際，安全無法保證
安全性無法保證這個確實存在，但是任何產品肯定都有一定的風險。這個產品的定位，知識針對一個本校的學生，對於大學生，素質相對也會比較高。風險的保證會比較低。僅僅是一個的匿名聊天，作為一個放松，以及吐槽的地方，因此也不需要過於在意其中的言論。對於，發表看法的專區，會特別添加其中的安全機制，盡量在敏感的地方減小其中的分險。
- 如何做到學校認證
首先，第一個的想法是與校方合作，在用戶注冊時，提供關鍵信息，與預留校方信息吻合才允許注冊。但是，如果無法做到這點，那就運用比較極端方式，由於大部分學生都是住宿，因此利用定位系統，只有在學校的地區，才允許發帖和留言。
三、 原型設計
項目考慮過APP和Web兩種方式，最后權衡之下，由於APP對於手機的權限調用更多，需要用到手機的其他傳感器，如定位系統等，所以考慮了安卓APP。
部分截圖：
四、PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） |
|---|---|---|
| Planning | 計划 | |
| • Estimate | • 估計這個任務需要多少時間 | 10 |
| Development | 開發 | |
| • Analysis | • 需求分析 (包括學習新技術) | 60 |
| • Design Spec | • 生成設計文檔 | 50 |
| • Design Review | • 設計復審 | 30 |
| • Coding Standard | • 代碼規范 (為目前的開發制定合適的規范) | 0 |
| • Design | • 具體設計 | 450 |
| • Coding | • 具體編碼 | 0 |
| • Code Review | • 代碼復審 | 0 |
| • Test | • 測試（自我測試，修改代碼，提交修改） | 30 |
| Reporting | 報告 | |
| • Test Report | • 測試報告 | 20 |
| • Size Measurement | • 計算工作量 | 10 |
| • Postmortem & Process Improvement Plan | • 事后總結, 並提出過程改進計划 | 20 |
| 合計 | 680 |
五、團隊合作截圖
由於人數過多，分工比較稀疏，並沒有每次都所有成員一起，同時多數也是QQ群交流，拍圖場景比較多：
六、研究計划進度
- 第4周：查找資料，確定研究課題。本階段通過網上搜集資料，小組討論，身邊人調查來確定具有開發意義的課題，確定一個項目。
- 第5周：完成詳細的需求分析，建立合適的UML圖與建立初步的原型。
- 第6-8周：查閱資料，學習相關知識，准備編碼。
- 第9-14周：編碼時間
- 第15周：測試與完善
- 第16周：總結，編寫相關文檔。