| 這個作業屬于哪個課程 | 2019學年02學期單紅老師軟體工程實踐 |
|---|---|
| 這個作業要求在哪裡 | 個人作業——軟體評測 |
| 這個作業的目标 | 對騰訊即時通信IM的demo進行調研、評測後閱讀《建構之法》相關内容完成随筆寫作 |
| 作業正文 | https://www.cnblogs.com/ginphy/p/12731787.html |
| 其他參考文獻 | 建構之法 |
第一部分：調研，測評
評測：
1.體驗Web端Demo
Web發起聊天
Web查找好友
Web語音通話：Web端語音通話無法傳達到移動端，發現一個疑似Bug，在Safari浏覽器中即使停止語音通話之後仍會識别為還在通話中影響其它頁面的聲音播放
Web建立群聊：在移動端中建立群聊不需要填寫這麼多資訊，群名稱在web端中必填但在移動端不必須，使用者體驗不統一
2.體驗iOS端Demo
iOS添加好友
iOS接受語音通話：發現BUG，iOS端接受Web端發來的語音通話時會現實為無法識别的消息
iOS換頭像
iOS群組聊天
iOS個人聊天：發現疑似Bug，iOS端拉黑對方後仍然可以向對方發送消息，但是無法撤回，取消拉黑後撤回成功
iOS查找使用者：會出現UI與系統重疊的問題
3.體驗小程式端Demo
小程式語言通話
小程式修改資料
小程式群組聊天：點選彈起的輸入選擇面闆會遮擋下層的幾條消息
小程式好友清單：拉黑後仍然存在于好友清單中不會消失！
小程式私人消息：消息UI中文字沒有與氣泡對齊！
4.其它BUG總結
1.在微信小程式中查找使用者發起聊天的過程中，即使輸入了正确的、存在的使用者名也會現實【未找到該使用者】，直接導緻發起群聊功能無法使用。
分析：開發者的資料庫出現問題，查找的使用者為使用者名還是使用者昵稱并未指明，設計上有缺陷。
2.在iOS用戶端中即使對方已經讀取了你發送的消息并且對你進行了回複，界面中仍然顯示該消息未讀。
分析：開發者未對該功能進行詳細測試，或者在測試過程中疏忽了。
3.語音通訊存在多個BUG，在iOS端接受語音通話請求時無法正常顯示，隻會提示為【不支援的自定義消息】，在Android中更是沒有語音消息入口。而在小程式接受語音消息時偶爾會出現對方接通但本地沒有顯示接通仍然停留在撥号狀态的問題。
分析：開發者在不同平台的語音通訊Demo沒有統一。
構思産品：
産品描述
一款面向校園的校内通訊系統，針對教學科研過程進行開發，同學和老師可以在該産品中交流教學資訊。
主要功能
支援教學相關檔案傳輸，對敏感檔案做好隐私保護，支援複雜公式顯示，支援.pdf、.caj等格式文檔的顯示，友善查閱文獻，支援圖表等資料展示。
面向使用者
大學師生
使用者分析
該類群體是需求明确，學習能力強，生活中常使用各類軟體産品，需要經常需要接觸各類文獻資料，資訊交流頻繁。
采訪：
采訪對象背景&需求
采訪對象為一名學習經濟管理類專業的大學生
平日裡有通過QQ、微信等常用軟體收發Office文檔并編輯檢視的習慣。在學習過程中經常需要使用手機内的Office軟體打開通過通訊軟體下載下傳的文檔進行學習。
采訪對象使用demo
對SDK的建議
“注冊有點太簡單了，找回密碼會不友善，還是要換個界面，現在這個太醜了，如果有了安卓和蘋果版應該就不會用小程式版了，打開很麻煩，還不如直接用微信。”
對我想開發産品的意見
“聽起來還不錯，但是老師可能不會用這個，已經習慣用QQ了，如果可以直接編輯一些資料就更好了，希望可以對報表的一些資料自動格式轉換。”
對騰訊即時通信的評價
推薦：“和QQ差不多，一看就會用，蘋果和安卓都可以下載下傳，占記憶體也不大，如果有其他人一起使用的話自己也會跟着一起用。但是有點卡卡的，如果不卡就更好了。”
第二部分：分析
估計時間
一個由福州大學軟體工程系畢業生組成的六人小組預計開發項目所需時間為2-3個月。
優劣分析
與類似軟體相比優勢在于平台分布廣，大學師生使用的數位硬體産品種類繁多，跨多個平台的特性有利于向師生群體推廣；并且背靠騰訊在技術支援和推廣上有利；軟體輕量化，專注性強，相比較于一些臃腫的即時通訊軟體更易獲得目标群體青睐。劣勢是進入市場較晚，面對即時通訊軟體的紅海市場難以打開局面，讓師生使用者放棄原本的交流方式有一定難度。跨多個平台也會導緻開發成本上升，對于一個小團隊而言負擔過重。
具體建議
在各類即時通訊軟體競争激烈的今日，這類專注性強針對特定群體的産品需要在需求階段就找到準确的産品定位，切入細分市場吸引特定使用者，在開發過程中要注意進度控制，不同平台的開發過程需要團隊的及時交流來保證産品的體驗是統一的、一貫的，降低使用者學習成本，注意提升産品效率，保證忙碌的師生使用者群體能夠在該産品上“用完即走”。
第三部分：建議和規劃
目前市場上的同類産品
CAJView（論文閱讀軟體）
Tim（商務輕量通訊軟體）
叮叮（商務辦公軟體）
......
NABCD分析
Need：本産品主要是針對大學師生，在師生的網路交流過程中，經常需要發送一些學科相關的内容，其中就包括了複雜的數學公式、代碼片段、資料圖表、論文文獻等内容，這些内容種類複雜，現在存在的一些工具并不難做到這類資料的保真傳輸，往往需要借助截圖等手段才能發送，這就導緻了在交流過程之中嚴謹的教學資料無法原原本本的發送給對方檢視，也照成了很多不便。目前許多論文平台如CNKI等下載下傳的文檔有多種格式，有些格式不被常用軟體支援，如果下載下傳專用閱讀器一來效率較低，二來部分資料在不同閱讀器上顯示效果也會有差異。是以需要一個平台能夠完善資訊的顯示并且将資訊的“傳輸”與“顯示”兩部分統一結合起來，友善師生使用者的使用。
Approach：
【技術方法】基于SDK進行開發，先以Web的形式完成該項目，因為Web平台的應用可以被大部分不同平台的硬體産品打開。在即時騰訊通訊的基礎上添加類似CAJView的文檔顯示功能闆塊用于閱讀資訊，使用md格式來進行文本傳輸，支援多種格式的資料顯示，包括代碼格式。
【營運模式】首先在校内進行推廣，聯系到校内相關人員将其先作為校内交流工具進行早期疊代，前期免費使用接受贊助，等到産品反響良好産品形态成熟後向社會推廣，後期作為專業軟體向使用機關收取少量費用作為平台營運成本。
Benefit：
對于在校師生來說具有了專業平台進行資料分享，有利于避免因文檔圖表資訊傳輸失真照成的資源浪費。校内平台有利于資訊保護，有在一定程度上保護了教師原創内容的知識産權。學生在與教師交流時與傳統的郵件途徑相比也提升了效率，減少了不同平台的學習成本。
Competitors：
【優勢】與類似軟體相比優勢在于平台分布廣，大學師生使用的數位硬體産品種類繁多，跨多個平台的特性有利于向師生群體推廣；并且背靠騰訊在技術支援和推廣上有利；軟體輕量化，專注性強，相比較于一些臃腫的即時通訊軟體更易獲得目标群體青睐。打通了資訊的“傳輸”與“顯示”兩部分，大大的提升了交流效率。
【劣勢】部分師生已經習慣了使用競品軟體進行交流，轉變平台需要一定的學習成本，作為小團隊的産品在博取社會信任上有一定難度，前期推廣有壓力。
Delivery：前期依靠校内人員使用進行産品疊代并積累口碑，後期依靠院校積累的口碑進行下一步推廣，當使用人數規模達到一定程度以後主打專業性進行面向全國院校的大規模推廣。
團隊上司方案
如果是我來上司這個團隊，我會注重需求的分析與進度的把控，作為一個小團隊，在開發過程中需要進行合理的任務配置設定，在前期疊代中采取靈活開發模式，對于師生的需求建議快速響應疊代産品。
配置人員
1人前端設計 1人文檔撰寫與測試 2人後端開發 2人前端開發；項目的需求分析與後期的疊代建議由所有成員一起完成。
16周安排
| 時間安排 | 目标任務 |
|---|---|
| 第1周 | 需求分析、确定開發環境 |
| 第2-3周 | 軟體設計、制作産品原型、撰寫需求規格說明書 |
| 第4周 | 進行資料庫設計、完善系統結構設計、撰寫系統設計說明書 |
| 第5-6周 | 進行基礎資訊傳輸部分開發 |
| 第7周 | 接口對接 |
| 第8周 | 測試修改與美化 |
| 第9-13周 | 進行各類資料傳輸部分開發 |
| 第14周 | |
| 第15周 | 釋出Demo版本，擷取使用者回報 |
| 第16周 | 針對使用者回報優化後上線正式版本 |
項目部署
| 裝置 | 數量 |
|---|---|
| 後端伺服器8核32G | 4台 |
| 應用伺服器4核8G | 2台 |
| 關系型資料庫 | MySQL數量6（讀寫分離4、備份2） |
| 分布式緩存資料庫 | Redis數量4 |
| 安全性 | WAF、DDOS |
| 注意大量資料檔案對于儲存設備的壓力 |