| 這個作業屬于哪個課程 | <2020春W班 (福州大學)> |
|---|---|
| 這個作業要求在哪裡 | <作業要求> |
| 這個作業的目标 | <評測分析騰訊即時通信IM，采訪潛在使用者，對于即時通信SDK的建議和規劃> |
| 作業正文 | <作業正文> |
| 其他參考文獻 | <騰訊IM即時通訊開發文檔> |
Part.01 調研，評測
評測：
軟體的bug，功能評測，黑箱測試
本次作業選用的完成方式：方式一
（PS：在一開始嘗試使用方式二進行開發，作為一個目标是成為專業後端工程師的人，我的第一思路是将這個sdk的開發文檔中的REST API整合到springboot裡的，然後用一個簡單的gui進行測試，無奈這個sdk确實是提供給前端的人員開發使用的，且并沒有為java提供接口，我隻能想辦法自己弄，最後截止2020-04-17晚上，在借鑒了github一個開源項目的前提下，把騰訊即時通訊IM SDK整合到springboot時出了一些問題，卡在那了，報空指針，估計還是計算usersig那裡出的問題，考慮到馬上截止了，隻好懸崖勒馬，換用方式一重新開始，目前本人已自閉，心情有點郁悶ing，拖大了，還是按照開發文檔按步驟來使用SDK可能可行性要大很多）
Demo測試(本次對web端、Android端、ios端與小程式端均進行了同類型測試)
下載下傳并使用demo，對使用的不同demo，每種demo至少提供兩張使用過程中的截圖
-
web端：裝置 個人PC（系統：Windows 10 專業版）
登入界面測試
測試結果：界面顯示正常、建立使用者功能正常
字元串類型輸入測試：文字型資訊一般文字、表情
測試結果：輸入、接收正常、資訊顯示正常
檔案流類型輸入測試：圖檔
測試結果：輸入、接收正常、圖檔顯示正常、圖檔可預覽
檔案流類型輸入測試：視訊
測試結果：輸入、接收正常、視訊顯示正常、視訊可點選線上播放
自定義消息輸入測試
測試結果：輸入、接收正常、自定義消息不可點選檢視詳情（那自定義消息的意義何在？)
-
Android端：裝置 MI9（系統：MIUI 11.0.5穩定版）
測試結果：界面顯示正常、注冊登入功能正常
添加好友測試
測試結果：添加好友功能正常，驗證資訊功能沒有顯示驗證資訊
測試結果：1、直接錄制的視訊輸入、接收正常、視訊顯示正常、視訊可點選線上播放
2、無法上傳本機的視訊，報錯（雲通訊：right)，初步判斷是沒有擷取應用的讀取檔案權限
3、本機的視訊可通過檔案上傳，但無法下載下傳僅顯示存儲路徑，這樣的設計很不友好
測試結果：輸入、接收不正常、安卓這邊直接不給自定義了，直接顯示歡迎加入雲通信IM大家庭，點選後跳轉開發文檔
-
ios端：裝置 ipad mini5（系統：13.3.1（17D50））
測試結果：界面顯示正常、注冊登入功能正常、讓人欣慰的是和安卓那邊資料是互通的，估計應該是一個後端提供的接口，但是字型在我的裝置顯示有問題，是白色的，在賬号框與密碼框，根本看不清自己輸入了什麼，很差的人機互動，在後續界面也有此問題
輸入測試
測試結果：因和安卓界面UI邏輯基本差不多，輸入與接收正常的地方和上部分安卓一樣，問題也和上部分安卓一樣，字型顔色仍有問題
-
小程式端：内嵌微信不展示裝置（微信版本：7.0.13）
測試結果：1、字元串類型輸入、接收正常、資訊顯示正常
2、檔案流類型輸入測試：圖檔輸入、接收正常、圖檔顯示正常、圖檔可預覽
3、檔案流類型輸入測試：視訊輸入、接收正常、視訊顯示正常、視訊可點選線上播放
4、自定義消息輸入測試輸入、接收正常、輸入、接收正常、自定義消息不可點選檢視詳情（那自定義消息的意義何在？)
PS:小程式端的問題表現與web相同，應該是直接把web作為一個frame嵌入微信的，是以在小程式端視訊上傳正常且自定義消息的問題表現相同
使用發現的BUG
1、找出至少兩個比較嚴重的功能性bug（說明：操作不夠人性化、沒考慮到使用者的xx需求等并不算嚴重的功能性bug）
2、請使用專業的語言描述（每個bug 不少于 40字），并配圖說明
3、你覺得為什麼這個産品組的人沒有發現這些bug??
PS:在上一部分在對各個端進行測試時，發現了一些小的bug，已在上部分測試結果指出，在此處就不一一列舉，在本部分主要列舉嚴重的bug
-
軟體Demo使用過程中的bug（黑箱測試發現的）
-
BUG1:ios端的ui字型與整體UI顯示問題
-
問題描述:
ios端的ui字型與整體UI顯示問題，在登入界面使用者名、密碼無法顯示，疑似是字型顔色的問題，然後在顯示詳細資料、我的個人消息、開發調試等界面均有按鈕的左側描述字樣無法顯示的問題（因長按按鈕會發現實際是有一個按鈕名字的，顯示為灰色，如我的個人消息界面中第一個按鈕左側顯示為好友申請，但正常狀态不顯示）
-
開發人員沒發現這個問題原因:
我猜測有兩個可能 1、開發人員沒有正确的對按鈕等UI的背景顔色和字型的顔色進行設定，故導緻字型和背景均為白色，導緻顯示不正常（但考慮到鵝廠這樣的大廠的程式員不會犯這樣的低級錯誤，故本人不是很傾向于這個猜測）；2、該app測試釋出的ios版本與目前版本（本人使用的是最新的13）相比應該較老，然後ios系統在更新過程中可能對作業系統的字型顔色庫進行了版本更新，可能修改了對應字型顔色調用時的方法或變量名，然後該app在調用字型顔色的時候找不到對應的映射，調用失敗，異常處理将字型的顔色調用了預設的白色故導緻了現在出現的問題（本人比較傾向于這個猜測，但是手上沒有其他版本的ios，且不可能順着ios的版本由新到舊逐一測試，該app在發行時，發行的人員手上應該有對應的ios版本，這個開發人員好找問題，該猜測暫時無法證明）
-
BUG2:黑名單操作時的消息顯示問題（測試時使用本人Android（登入使用者theTuring_221701412）和ios裝置（登入使用者test_221701412）進行測試，Android裝置将ios裝置的使用者拉入黑名單，ios裝置發送消息）
-
問題描述:對這個問題按照操作流程進行描述
-
Step1：使用者theTuring_221701412将使用者test_221701412拉入黑名單
-
Step2：使用者test_221701412向使用者theTuring_221701412發送消息：我現在已被拉入黑名單
-
Step3：使用者theTuring_221701412将使用者test_221701412移除黑名單
-
Step4：使用者test_221701412向使用者theTuring_221701412發送消息：我現在被移除了黑名單
-
Result：使用者theTuring_221701412界面：僅收到消息：我現在被移除了黑名單（狀态：已讀）；使用者test_221701412界面：顯示消息：；1、我現在已被拉入黑名單（狀态：已讀）2、我現在被移除了黑名單（狀态：已讀）
-
問題所在:
使用者theTuring_221701412并沒有收到消息：我現在已被拉入黑名單，但使用者test_221701412那邊回報卻是已讀（這樣的bug在某些場景很緻命，本人目前想到的最明顯的場景就是戀人之間吵架（A與B），A拉黑B，拉黑後B說了很多道歉的話理論上應該可以挽回A，A在第二天從黑名單又拉回B，B界面顯示A已收到長篇大論的道歉（已讀），A那邊卻并沒有收到，兩人漸行漸遠（PS：個人建議：1、重要事當面講，工作上的也好，愛情友情上的也罷，聊天工具的bug難說會導緻資訊不對稱與遺漏，就算做不到打個電話！！2、強扭的瓜不太甜，不要當舔狗！！！））
在研究了騰訊即時通訊IM的開發文檔後，由REST API 接口清單裡面研究了添加黑名單、删除黑名單、導入單聊消息的API的文檔中請求包與應答包的JSON資料包後得出了以下猜測（使用上述使用者舉例）：使用者theTuring_221701412調用添加黑名單接口将使用者test_221701412拉入黑名單；然後使用者test_221701412發送了消息：我現在已被拉入黑名單此時該消息被存到了處理隊列中；使用者theTuring_221701412調用删除黑名單接口将使用者test_221701412移除黑名單，根據文檔删除黑名單接口，請求包僅發送解除的使用者的json數組，使用者test_221701412向使用者theTuring_221701412發送消息：我現在被移除了黑名單，使用者theTuring_221701412調用導入單聊消息接口就接收到了第二條消息，應答包就傳回了一個ok給使用者test_221701412；使用者test_221701412接收到ok，則邏輯将最新以及以前的消息全部标記為已讀（問題就是出現在這裡的！！因為按照正常的邏輯你讀了最新消息那之前所有沒讀的都應該讀了，但此場景因為黑名單的操作實際上第一條消息還在使用者test_221701412的請求隊列中沒有發出去，但也被标記成了已讀），我認為這個bug隻需要給消息增加一個标記，且在導入單聊消息接口的應答包除了ok的屬性再增加一個标記的是哪條資訊即可解決。
涉及的接口清單
删除黑名單接口的請求包
導入單聊消息接口的請求包
實際操作出現bug截圖
采訪：
假如你需要用這個騰訊即時通信SDK開發屬于你的自己産品，那麼開發之前你除了需要了解該SDK的基本使用之外，更重要的就是為你将開發的産品進行市場調研
第8章 使用者調研，12 章 軟體的使用者體驗
我想要利用 IM SDK 開發的産品
構思你根據該SDK想要開發的産品，包括産品主要功能、産品面向的使用者、NABCD分析等
-
産品名：千尋
-
産品類型：
根據使用者注冊的興趣标簽，做一個即時比對的聊天軟體，讓你在茫茫人海中遇見那個與你意氣相投的ta，産品名取自詩句：衆裡尋他千百度，那人卻在燈火闌珊處。
-
産品功能：
- 提供一個即時聊天的交友平台；
- 根據算法比對，根據使用者在注冊時一個必填的幾個資訊：愛好、個人标簽、喜歡的圈子、性别，進行一個限定範圍的随機比對；
- 建立即時通訊連接配接，使用者可以發送普通資訊、圖檔、視訊等，也可以選擇進行視訊聊天；
- 對聊天的記錄進行一個持久化的記錄，可以對你中意的那個ta（前提是線上）選擇再次發起聊天；
- 對于有違規操作的使用者進行管理，初犯禁言，慣犯封ip；
-
面向使用者：
在社會上缺乏友情，缺乏社交的人，有社交恐懼症的人，可以先嘗試在這個平台邁向社交的第一步；在小衆圈子有特别愛好，在日常生活圈子無法遇到意氣相投的人的人，可以通過這個平台找到朋友一起合作；喜愛社交，熱愛廣交朋友的人，可以通過這個平台認識更多的人。
-
使用者場景舉例：
- ①自閉缺少朋友的陳同學，在日常的社交中一遇到人很多的大型聚會隻想逃跑，有一定的社交恐懼症，在現實有一肚子的話卻無人也不敢與人訴說，但是有所不同的是他在網絡上又是另外一個樣子，很愛表達自己的想法，有一天他突然發現了一個叫做千尋的即時社交app，登上以後随機比對到了一個人，一步步的從開始的語音交流，到後面的與那人再一次發起聊天，這樣愈加接近于現實社交，漸漸的讓他在現實中敢于表現自己，最後與現實和網絡中的朋友們都其樂融融的相處起來了。
- ②喜愛傳統國術的黃同學，熱愛傳統國術，但是自己卻是一所知名大學的軟體工程的學生，周邊的同學大多愛好都是遊戲和打代碼，自己空有一聲好武藝，卻沒有人可以交流，有一天他的朋友陳同學在逛論壇的時候看到了千尋給他進行了安利，果然試了幾次比對以後，見到了詠春的大佬-葉某，一問二人在一所城市，沒過幾天，就線下見面，在武館切磋了起來，場面極其快活，那叫一個刀光劍影！
- ③喜愛廣交朋友的劉同學，從小到大就憑借着自己不錯的社交能力交了很多朋友，但是随着年齡增長，身邊的人都開始忙起來了自己的事情了，有人考研、有人準備面試、有人在忙着練武，感覺自己有很多心裡話想與人訴說，但是好像朋友都在忙，也漸漸疏遠了不少，在好友陳某的安利下下載下傳了千尋，填完了自己的個人資訊，愛好旅遊，于是在一次比對中遇到了同樣熱愛旅行的牙某，随着聊天的不斷深入，二人也不斷的在聊天記錄中發起了再次聊天，最後二人約在了某知名旅遊景點見面，一起去爬山，此時的二人都心生愛慕，确定了男女朋友關系，一問二人居然在一所學校（因為在比對前其實有填了學校），從此，校園裡又多了對甜甜蜜蜜的情侶。
采訪潛在使用者
從你的身邊尋找你要開發的産品的潛在使用者，記載你對這位使用者的采訪。使用下面的采訪提要：
-
介紹采訪對象的背景和需求
采訪的對象是我的好友劉同學，劉同學有着和上述使用者場景3相似背景，愛廣交朋友，一方面享受于與人聊天的快樂，一方面也想多交朋友為自己以後的創業增加人脈基礎。劉同學渴望能有一個軟體工具能幫助自己找到意氣相投的夥伴，一起分享快樂，一起排憂解難，在未來一起在社會上闖出一片天地。
-
采訪對象使用Demo圖檔
-
采訪過程（語音形式）介紹了我想用SDK制作的産品
-
使用者使用騰訊即時通信Demo體驗
使用者使用這個demo的過程, 使用者的問題初步解決了，可以完成日常生活的最基本的聊天；軟體在資料量/界面/功能/準确度上，總體還是可以的，但是界面更加設計的不是很好看，可以更簡潔一點，功能上web端對于分類子產品設計的讓人一頭霧水，準确度的話大緻可以；使用者體驗方面，有些互動不是很友好，如界面的聊天界面顯示感覺與習慣性的左發送者右接收者相反，不是很習慣。
-
使用者對SDK的意見
SDK 的開發文檔做得不是很友好，存在很多困擾開發者的地方。對于實作小功能的場景，這個 SDK 足夠應付。如果要提供針對性服務，需要後端的支援，但是該SDK并沒有提供java的後端接入。
-
使用者對我開發的産品的意見
這個想法不錯，具有較高的可行性，是一種新型的社交軟體，應該挺有意思的，但是也有很多細節需要考慮和完善。對于并發的問題的考慮與比對算法的設計還需要多加考慮。
-
結論
- 非常不推薦
- 不推薦
- 一般
- 推薦 √
- 非常推薦
Part.02 分析
參考 8.6 節 對工作的估計， 和14.1 節 軟體工程的品質
使用騰訊即時通信的所有功能，聯系第二部分的分析，估計這個SDK做到這個程度大約需要多少時間？（團隊人數大約6人左右，計算機大學畢業生）。 分析這個軟體目前的優劣（和類似軟體相比，如網易雲信），并推理出團隊在軟體工程方面可以提高的一個重要部分（具體建議）
時間規劃
使用騰訊即時通信的所有功能，聯系第二部分的分析，估計這個SDK做到這個程度大約需要多少時間？（團隊人數大約6人左右，計算機大學畢業生）
規劃前的準備
其實作在的大多即時通訊SDK，本質應該都是基于TCP的Socket套接字編寫的一個多線程的系統，我在對騰訊即時IM SDK進行分析之前，大概花了一個下午使用java的Socket套接字完成了一個Sever - Client端可以實作僅發送文本的即時聊天程式，以此程式的完成工作量來推測騰訊即時IM SDK的開發時間，我的程式運作截圖如下：
下圖是我從github中擷取的一個大概的IM系統的系統架構，也為我分析的基礎參考：
開發這個SDK需要解決的問題
- 1、一個開源的公用SDK對于高并發的請求的處理問題
- 2、在給每一位申請了SDK使用者配置設定了密鑰以後，對于每位使用者調用接口後的資料存儲的持久化及安全性問題
- 3、對于提供接口不恰當調用，對提供伺服器造成的負載問題
- 4、接口完善後的測試階段，如何做到合理測試問題，保證能滿足基本功能使用
- 5、接口完成後的開發文檔攥寫問題，如何能讓第三方的開發者能快速上手
- 6、接口完成後的Demo（服務于多個平台）編寫及Demo編寫後的基礎測試
我的結論
前提條件：
團隊人數大約6人左右，計算機大學畢業生，且每人程式設計水準都較高前提，按照國家規定的每天 8 小時一星期工作 5 天工作制，按照有一人有相關經驗，能做系統的整體設計，六人人員能力得滿足如右（系統總體構架且有參與過即時通訊系統大型項目經驗：1人；java後端且熟悉伺服器端的代理以及Socket套接字與多線程程式設計的人員：2人；熟悉Android：1人；熟悉web前端：1人；ios：1人；熟悉c++程式設計：1人；熟悉單元測試、接口測試、并有很好的文檔攥寫能力：1-2人），在6人之中能滿足之前我列舉的能力中2-3項的前提下
我認為這個SDK可能可以在1year（約260個工作日）左右被初步的開發出來，我認為大緻的時間安排如下：
- 需求提取分析：15個工作日左右
- 系統設計：15個工作日左右
- 分布式資料庫設計：20個工作日左右
- SDK接口開發實作：60個工作日左右
- 伺服器代理配置及負載測試：20個工作日左右
- 測試修改bug及攥寫文檔：80個工作日左右
- demo編寫及測試：40個工作日左右
同類産品對比優劣
分析這個軟體目前的優劣（和類似軟體相比，如網易雲信）
在通過搜尋引擎擷取資訊後得到以下的競品分析圖：
軟體工程實踐2020_個人作業 —— 軟體評測 軟體工程實踐2020_個人作業 —— 軟體評測 軟體工程實踐2020_個人作業 —— 軟體評測
再通過比較核心服務價格，得出騰訊即時通訊IM SDK有以下優劣勢：
- 優勢
- 群組聊天支援量最大：鵝廠家大業大，騰訊雲伺服器規模是在國内數一數二的，自然對于稍大一點大開銷是不在意的
- 平台支援較為豐富
- 群組核心功能較為豐富
- 核心服務價格有免費版本：适合個人進行開發測試，也可付費更新服務較為親民
- 劣勢
- 對于實時視訊音頻的功能不支援拓展，限制了某些子產品的開發調用
- 檔案傳輸有限制，28mb偏小，不清楚在付費後有沒有更新一說
- 服務端消息記錄存儲時間較短
- 教學白闆子產品不支援，限制了在教學領域的使用
- 服務維護較差僅可提工單，但沒有論壇，缺少像其他競品的服務維護體系
團隊軟體工程方面建議
推理出團隊在軟體工程方面可以提高的一個重要部分（具體建議）
對于團隊在軟體工程提高方面，我現在的最大的感受還是一個團隊的整體合作的部分，如何去達到一個更好的團隊的合作效率，一般來說，在一個團隊裡面成員能力是參差不齊的，擅長的領域也是不同的，誠然，就正常的任何一件事的團隊合作來說來講，各司其職，發揮所長，揚長避短這樣可能是最好的安排。但說回團隊軟體工程方面，我認為情況又有一些的不同，首先，我認為在一個團隊軟體工程的情景下，一個leader是必要的，這個上司者可以是一個人、也可以是幾個人、一群人，畢竟軟工的項目是需要一個整體的架構的，一個好的整體設計能為後續的開發減少很多在跨子產品的互動之間減少很多不必要的磨合，leader們就需要做到這個，這背後也是經驗的展現。然後談到個人，術業有專攻，漸漸的在團隊内的軟工角色會劃分為前端、後端等再被按負責子產品細分，但是這不代表就隻需要會自己常負責的子產品，每個個人知識的全面性的提升對與團隊整體的合作會有很大幫助。
Part.03 建議和規劃
參考《建構之法》第8章 功能的定位和優先級；第9章 項目經理
假如你需要用這個騰訊即時通信SDK開發屬于你的自己産品：
-
如果你是項目經理，如何提高進而在競争中勝出？
- 1、在項目啟動階段，做好充分的市場調研，從統計資料中提取出最切合使用者實際的需求
- 2、做好成本分析，盡量對項目成本預算做到最佳的管控，在預算内讓成本發揮最大效益
- 3、使用合理的團隊管理模式，做好團隊分工，提高團隊的效率
- 4、運用項目管理知識體系（PMBOK），合理運用10大管理與自己的專業素養科學管理項目
-
目前市場上有什麼樣的産品了？
- 1、soul：即時比對通訊社交軟體，基于心靈的智能社交APP。功能是尋找最适合自己的靈魂伴侶。 微信微網誌上發不出的話，默默記錄在案，而恰巧有陌生人在意。
- 2、陌陌：MOMO是陌陌（NASDAQ：MOMO）于2011年8月推出的一款基于地理位置的開放式移動視訊社交應用，是中國的開放式社交平台。在MOMO，可以通過視訊、文字、語音、圖檔來展示自己，基于地理位置發現附近的人，建立真實、有效、健康的社交關系。陌陌的願景是希望人們通過移動網際網路，發現身邊的美好與新奇，讓人們連接配接原本該連接配接的人。
- 3、探探：探探是一個基于大資料智能推薦、全新互動模式的社交App。探探根據使用者的個人資料、位置、興趣愛好等資訊，計算并推送身邊與你比對的人，幫助使用者結識互有好感的新朋友。
-
你要設計什麼樣的功能？
- 1、提供一個即時聊天的交友平台；
- 2、根據算法比對，根據使用者在注冊時一個必填的幾個資訊：愛好、個人标簽、喜歡的圈子、性别，進行一個限定範圍的随機比對；
- 3、建立即時通訊連接配接，使用者可以發送普通資訊、圖檔、視訊等，也可以選擇進行視訊聊天；
- 4、對聊天的記錄進行一個持久化的記錄，可以對你中意的那個ta（前提是線上）選擇再次發起聊天；
- 5、對于有違規操作的使用者進行管理，初犯禁言，慣犯封ip；
-
為何要做這個功能，而不是其他功能？
- 這個功能是自己對于現今三種比較有代表性社交心理分析得出的需求而設想出的功能，在社會上缺乏友情，缺乏社交的人，有社交恐懼症的人，可以先嘗試在這個平台邁向社交的第一步；在小衆圈子有特别愛好，在日常生活圈子無法遇到意氣相投的人的人，可以通過這個平台找到朋友一起合作；喜愛社交，熱愛廣交朋友的人，可以通過這個平台認識更多的人。
-
為什麼使用者會用你的産品/功能？
- 我認為社交對于人類這種社會性動物來說是日常生活種非常重要的一環，人不能脫離這個賴以生存的社會，而在社會立足則離不開社交，這個産品設計了一種新型的社交模式，根據對于三種有一定代表性的使用者場景進行分析，我認為還是較為契合當今人們的社交心理的，是切合使用者需求而設計出的産品。
-
你的創新在哪裡？可以用 NABCD 分析。
- N:使用者需求分析
- 1、缺乏社交的人，需要一個邁向社交的第一步的機會；
- 2、小衆圈子有特别愛好的人，需要一個與志同道合朋友社交的機會；
- 3、熱愛社交的人，需要一個平台去認識更多的朋友；
- 4、所有人都需要社交，而一種新型的社交模式可以為人們提供一種new style的社交模式。
- A: 我們的獨特招數
- 在功能方面：我們
- 在需求方面：我們認為
- 社交對于人類這種社會性動物來說是日常生活種非常重要的一環，人不能脫離這個賴以生存的社會，而在社會立足則離不開社交，這個産品設計了一種新型的社交模式，根據對于三種有一定代表性的使用者場景進行分析，我認為還是較為契合當今人們的社交心理的，是切合使用者需求而設計出的産品。
- 在功能方面：我們
- B: 我們帶來的好處
- 1、更便捷，一種根據你的自我标簽随機比對的社交方式；
- 2、更專業，通過騰訊即時通訊IM保證了傳輸的穩定與安全；
- 3、更切合使用者需求，專注于即時社交子產品，可根據使用者需求做出更多的私人化定制。
- C: 我們的競争對手
- 參考前面SDK分析部分的競品分析以及建議和規劃部分對于産品競品的分析（Soul、陌陌、探探）。
- D: 我們如何推廣
- 1、推出産品，上線應用商店
- 2、通過短信随機發送邀請，邀請用于參與内測，參與有獎
- 3、通過一些自媒體與現在的新媒體平台通過現在的一些新的推廣方式推廣，包括但不限于廣告，vlog等方式。
- N:使用者需求分析
-
如果你來上司這個團隊，會有什麼不一樣？
- 1、我會加強與隊員的交流，做好這個系統的整體構架與設計
- 2、做好分工與溝通的設計，增加團隊效率
- 3、定期進行彙報會議，定期對整體項目計劃進行讨論與修正
- 4、做好必要的文檔攥寫工作，保證後續開發不會偏移初衷
- 5、在發行前做好測試工作，減少發行後的程式錯率
- 6、做好後續的版本更新疊代，不斷的減少bug，更加的貼近使用者需求
-
如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？
- 如果我的團隊有5個人, 4個月的時間，我作為項目經理，角色我配置為：測試1人、美工設計1人、後端邏輯部分編寫人員1人、資料庫設計及伺服器管理人員1人、前端界面設計人員1人。
-
描述你的團隊在周期為16周，每周都要做什麼，才能保證在第16周如期釋出軟體。
- 第 1 周：需求分析（團隊會議，所有成員參與）
- 第 2 周：原型設計（美工設計，開發人員參與建議）
- 第 3 周：工具評測（團隊參與進行）
- 第 4、5 周：系統設計（由項目經理主導，開發人員參與）
- 第 6 周：資料庫設計（資料庫設計及伺服器管理人員負責，後端邏輯部分編寫人員參與建議）
- 第 7 周：設計階段結束，用一周時間重新回顧之前的各部分重新思考，修改回顧不合理部分（團隊參與進行）
- 第 8 周：項目整體架構（項目經理主導進行）
- 第 9、10、11、12 周：編碼開發階段（項目經理+開發人員+測試人員可以開始對完成子產品進行單元測試)
- 第 13 周：前背景互動，伺服器部署（項目經理+開發人員）
- 第 14、15 周：測試階段（測試人員大規模測試、開發人員修改bug）
- 第 16 周：發行階段，傳遞項目，做好後續疊代的準備
-
項目釋出後，有沒有考慮過項目該怎麼部署才能滿足需求？依據下圖（某校教務處系統的部署）作為參考，分析16周後你所完成的項目上線需要哪些配套裝置(伺服器、帶寬、資料庫需求數量與配置)
- 該項目初步分析應該并發較高，考慮選用騰訊雲頂配的雲伺服器，後續具體升降還得考慮具體的項目架構
- 應用伺服器叢集：專業配置 四核8GB 2.4GHz *2 公網帶寬 200Mbps
- 關系型資料庫：MYSQL數量：3（讀寫分離2，備份1）
- 緩沖資料庫：Redis（主1、備1）
- 安全性：ARP(保證通訊資料安全)、DDOS(分布式拒絕服務攻擊)
Part.04 Q&A部分
本部分對本次答辯老師以及助教的提問進行回答
-
汪老師
- Q1:視訊線上播放流暢嗎？
- A1:視訊線上播放流暢，不過測試使用的視訊為10s左右的短視訊，對再大一點的視訊是否解析會出現卡頓等情況，還需進一步測試。
- Q2:在浏覽器端和手機端有差别嗎？
- A2:就目前的測試結果來看,浏覽器端與小程式端基本展現的界面邏輯與問題完全相同，考慮應該小程式端直接内嵌web端的，浏覽器端和手機端有一定差别，主要展現在視訊的上傳方面（調用本地視訊報錯）、自定義消息方面（web端可定義，手機直接跳轉開發文檔）等方面。
- Q3:黑名單那個問題是否是有意不發送移入黑名單資訊呢？
- A3:黑名單有意不發送移入黑名單資訊我認為這樣的設計是合理的，但是不應該在另一方标記為已讀，這樣的處理會造成雙方的消息不對稱，我認為是一個bug應該修改。
-
傅老師
- TIPS:微信和QQ的黑名單一般是靜默的。
-
林助教
- Q1:它是如何防止DDOS攻擊呢，如果發起大量TCP半連接配接，并且僞裝ip，那封禁ip是解決不了的。
- A1:：對于DDOS攻擊，可以通過CDN節點中轉加速服務隐藏伺服器真實IP，關閉不必要的服務或端口，增加伺服器的帶寬增加承壓能力，增加網站請求IP過濾，然後本身騰訊的雲伺服器就有安全服務可以考慮購買，如果發起大量TCP半連接配接，并且僞裝ip這個暫時沒有想到怎麼解決，以為之前考慮的封ip是針對一般的違規使用者，其也不具備網絡攻擊的能力。