軟件評測
這個作業屬於哪個課程 | 2021春軟件工程實踐 W班 (福州大學) |
---|---|
這個作業要求在哪里 | 軟件評測 |
這個作業的目標 | 評測三個軟件,並給出分析、建議、規划等 |
其他參考文獻 | 《構建之法》、CSDN、各評測網站官網 |
第零部分 BUG量化標准
星級 | 描述 |
---|---|
☆☆☆☆☆ | 致命性系統故障、致命性安全性漏洞、用戶體驗嚴重影響 |
☆☆☆☆ | 嚴重系統故障、服務器鑒權漏洞或重要數據泄露、用戶體驗較差 |
☆☆☆ | 功能沒有完全實現但是不影響使用 |
☆☆ | 界面、性能缺陷、不影響操作功能的執行,是屬於優化方案。 |
☆ | 無關痛癢,不去在意也沒關系 |
第一部分 調研,評測
CODE CHINA
介紹
- CODE CHINA是CSDN推出的開源平台。面向國際化市場,具備使用GitLab最新高可靠部署方案、獨立第三方平台等特點,擁有海量用戶基礎和品牌加持。
體驗
- 主要對代碼倉庫進行測試
測試環境:銳捷校園網
首頁和登陸
- 體驗描述:登錄是和CSDN賬號是綁定的,有種強買強賣的感覺。個人認為有點減分
- 改進建議:如果整個平台能獨立(獨立賬號)並且把CSDN登錄作為類似QQ登錄的功能會比較好。
創建項目倉庫
- 體驗描述:很常規的創建項目功能
- BUG:
- 沒有提示項目標識串是必填並且只能是字母、數字、下划線組成的,灰色的my-awesome-project讓人誤以為是已經自動填寫,直到按下新建項目才有提示,影響用戶體驗。
- 錯誤提示是英語的,沒有做好漢化,體驗有點差
- 改進建議:希望能在必填字段加上紅色的星號和輸入提示。
初始化倉庫
- 體驗描述:指引界面比較完善,比較驚艷的是選擇新建文件的時候還有自帶IDE。其實Github也有,但是比較簡單。
- 改進建議:IDE可以考慮提交commit后回到倉庫界面
代碼上傳
- 體驗描述:7.5MiB/s ~ 11 MiB/s,基本上能把100M寬帶跑滿,加分。
邀請協作者
- 體驗描述:很好,還能選擇協作者的權限
- 改進建議:希望被邀請者能夠先確認再加入,不然不認識的人就可以隨隨便便拉你進奇奇怪怪的倉庫。
附加功能
BUG
漢化問題
- Bug發生時的測試環境:90.0.4430.212 (正式版本) (64 位) (cohort: Stable)
- Bug的可復現性及具體復現步驟:
- 可復現
- 在創建項目的時候在項目標識串填入中文
- Bug具體情況描述:很多提示信息和界面都沒有漢化,作為一個中國本地化這個缺陷個人認為是不能允許的。
- Bug分析:
- 成因:好像CODE CHINA是基於Git Lab二次開發的,那么有一些地方沒有漢化很正常,但是也體現了開發人員不夠細節。
- 嚴重性:☆☆
結論
-
廣告篇幅有點大,用起來有點難受,稍微有點流氓軟件那味
類別 描述 評分 (滿分 20分, 良好 12 分, 及格 8分,聊勝於無 1 分, 很差 -5分) 核心功能 分析三個核心功能,功能設計和質量。 17 細節 有什么為用戶考慮的細節? 10 用戶體驗 當用戶完成功能時,不干擾用戶 (例如: 是否不斷彈出不相關廣告)。 15 差異化功能 這個軟件獨特的功能. 它對用戶的吸引力有多大? 17 用戶有控制權 系統狀態有反饋,等待時間要合適。關鍵操作有確認提示,有明確的錯誤信息。 讓用戶方便地從錯誤中恢復工作, 快捷操作鍵可調整。 15 總分 74
GitHub
介紹
GitHub 是一個面向開源及私有軟件項目的托管平台,因為只支持 Git 作為唯一的版本庫格式進行托管,故名 GitHub。
GitHub 於 2008 年 4 月 10 日正式上線,除了 Git 代碼倉庫托管及基本的 Web 管理界面以外,還提供了訂閱、討論組、文本渲染、在線文件編輯器、協作圖譜(報表)、代碼片段分享(Gist)等功能。目前,其托管版本數量非常之多,而且其中不乏知名開源項目,例如 Ruby on Rails、jQuery、python 等。
介紹出處
體驗
- 主要對代碼倉庫進行測試
- 前提:網站連不連得上完全看網絡心情,很不穩定
測試環境:院樓校園網(上傳大概在40M左右)
創建倉庫
- 體驗描述:界面比較簡潔(褒義),選項也比較少,但提示比較全。
Clone倉庫
- 體驗描述:網絡不穩定Clone不下來是常有的事情
代碼上傳
- 體驗描述:網絡不穩定Push失敗也是常有的事情
邀請協作者
- 體驗描述:搜索用戶之后需要,被邀請的用戶要郵件確認
- 改進建議:希望可以不用郵件就能確定協作,例如站內通信(雖然github沒有站內通信功能,但可以考慮加一個通知站)
BUG
- Github作為一個老牌代碼托管平台,健壯性和穩定性都不錯,很難找到功能性BUG。
結論
- 老牌代碼托管平台風評無需多言,但是中國大陸使用Github網絡不穩定問題真的很要命
類別 | 描述 | 評分 (滿分 20分, 良好 12 分, 及格 8分,聊勝於無 1 分, 很差 -5分) |
---|---|---|
核心功能 | 分析三個核心功能,功能設計和質量。 | 20 |
細節 | 有什么為用戶考慮的細節? | 15 |
用戶體驗 | 當用戶完成功能時,不干擾用戶 (例如: 是否不斷彈出不相關廣告)。 | 20 |
差異化功能 | 這個軟件獨特的功能. 它對用戶的吸引力有多大? | 8 |
用戶有控制權 | 系統狀態有反饋,等待時間要合適。關鍵操作有確認提示,有明確的錯誤信息。 讓用戶方便地從錯誤中恢復工作, 快捷操作鍵可調整。 | 15 |
總分 | 78 |
Gitee
介紹
Gitee是代碼托管·協作開發平台,開發者超過 600 萬,托管項目超過 1500 萬,匯聚幾乎所有本土原創開源項目,並於 2016 年推出企業版,提供企業級代碼托管服務,成為開發領域領先的 SaaS 服務提供商。
體驗
- 主要對代碼倉庫進行測試
測試環境:院樓校園網(上傳大概在40M左右)
主界面
創建倉庫
- 體驗描述:
- 附加選項十分豐富,能設置程序語言、模板、還有分支模型
- 中文倉庫名稱會自動翻譯成英文路徑,很驚艷
- 提示很全面
代碼上傳
- 體驗描述:基本能跑滿40M,不錯。
邀請協作者
- 體驗描述:邀請方式很豐富,而且權限管理也比Github和CODE CHINA更勝一籌。
BUG
Commit統計
- Bug發生時的測試環境:
- git bash版本:2.21.0.windows.1
- Bug具體情況描述:把不同電腦上的Commit當作了不同的人,這樣在統計貢獻量的時候是很致命的錯誤
- Bug的可復現性及具體復現步驟:
- 可復現
- 只要在不同電腦上commit並push即可復現
- Bug分析:
- 成因:可能push的時候並未匹配用戶名,直接使用了push來源的電腦名
- 嚴重性:☆☆☆
- 改進建議:參考github(但是我不知道Github這邊是怎么實現的)
- 提交反饋(issue):
結論
-
沒什么廣告,用起來很清爽
-
要與Github這種老牌平台競爭,本地化肯定得做得好,而且也要加很多實用的功能
- 它確實做到了
類別 描述 評分 (滿分 20分, 良好 12 分, 及格 8分,聊勝於無 1 分, 很差 -5分) 核心功能 分析三個核心功能,功能設計和質量。 19 細節 有什么為用戶考慮的細節? 12 用戶體驗 當用戶完成功能時,不干擾用戶 (例如: 是否不斷彈出不相關廣告)。 20 差異化功能 這個軟件獨特的功能. 它對用戶的吸引力有多大? 17 用戶有控制權 系統狀態有反饋,等待時間要合適。關鍵操作有確認提示,有明確的錯誤信息。 讓用戶方便地從錯誤中恢復工作, 快捷操作鍵可調整。 15 總分 83
第二部分 分析
開發時間估計
CODE CHINA
- 基於Git Lab二次開發的話我認為開發時間會比GIthub和Gitee快。
- 預計總的時間要一個月
Github
- CODE CHINA和Gitee其實都是GIthub仿品,所以他的開發時間應該會比GIthub,畢竟創業難。
- 預計總的時間要三個月
Gitee
- 官網並沒有說明有基於什么二次開發,那我當他是從0開始仿GIthub,並且花費了一定時間做了一些差異化功能突出與Github的不同。
- 預計總的時間要兩個半月
同類產品對比排名
- 中國內地網絡穩定性
- Gitee = CODE CHINA > Github
- 內地市場競爭力
- Gitee > CODE CHINA > Github
- 資源豐富程度
- GIthub > Gitee > CODE CHINA
- 產品差異化
- Gitee > CODE CHINA > GIthub
- 綜合
- Gitee > Github > CODE CHINA
軟件工程方面的建議
針對CODE CHINA:
需要在質量管理上進行嚴格的把關,針對現在一些信息是處於中不中英不英的狀態,很尷尬。
BUG存在的原因分析
針對CODE CHINA的BUG:
- 應該就是偷懶了,急着把半成品放出來(敷衍了事)
- 要不就是Git Lab那邊硬編碼了,改不了
針對Gitee的BUG:
- 估計很少人會換着電腦開發,而Gitee用戶量比較少,沒GIthub多,所以比較難發現這個BUG
第三部分 建議和規划
市場概況
市場有多大?
根據BOSS直聘《2021應屆生秋招早鳥報告》:
根據上述數據,目前是高薪崗位最多的是IT行業從業人員(程序員),這充分說明了IT互聯網行業對於人才的需求。
大量的程序員意味着項目管理,需要用到一些工具去做工程化,其中代碼托管平台必不可少。
直接的用戶有多少?潛在的用戶又有多少?
直接用戶:所有程序員、需要學習開源代碼的學生
潛在用戶:對編程有興趣的人
市場現狀
目前市場上有什么樣的產品了?
- Github
- CODE CHINA
- Gitee
上述產品的定位、優勢與劣勢在哪里?
- Github
- Github是面向全球的,其優勢就在於可以接觸到全球優秀的開源項目,享受海量資源
- 缺點很明顯的就是沒有做好本地語言化,而且在國內使用網絡穩定性很差
- CODE CHINA
- CODE CHINA是面向中國人群,優勢在於本地化並且依托於CSDN社區。
- 缺點就是不像Github那樣能享受海量的國外優質資源
- Gitee
- Gitee也是面向中國人群,優勢在於本地化做得比CODE CHINA更好,並且擁有比上述兩者更多的功能
- 缺點也是和CODE CHINA一樣不像Github那樣能享受海量的國外優質資源
上述產品之間呈現什么樣的關系,哪些為競品關系?以及競爭中的各方態勢如何?
- CODE CHINA和Gitee明顯是模仿Github的,但這兩者都是后期之秀
- Gitee在中國市場下了很大功夫,本地化做的很好,功能也拓展得不錯,勝CODE CHINA一籌
- Github網站基本上沒有什么更新,功能更加也沒有Gitee和CODE CHINA多,但是他開發出了Github Desktop這種好用的可視化工具提高競爭力
- 但是用戶粘性很大,因為是老牌網站了。
- CODE CHINA感覺是趕時間做出來的半成本。。
- 綜上所述,在中國網絡環境下我認為競爭力可以這樣排序:
- Gitee > Github > CODE CHINA
- 如果不限國內環境的話我我認為Github和Gitee的位置就要對調了。
市場與產品生態
這個產品的核心用戶群是什么樣的人?典型用戶是什么樣的?學歷,年齡,專業,愛好,收入,表面需求,潛在需求都是什么?
- 這個產品的核心用戶群在於企業中工作的程序員
典型用戶:
學歷 | 本科 |
---|---|
年齡 | 25 |
專業 | 計算機 |
愛好 | 編程 |
收入 | 年薪10W |
表面需求 | 代碼項目管理 |
潛在需求 | 參考開源項目學習、模仿 |
產品的用戶群體之間是否存在一定的關系?是否有利用其相互作用二次構成特定用戶生態的可能性?
- 用戶群體會有關系,因為代碼托管平台本身也支持多人協作、組織等功能。
產品的子產品,以及其他相關產品之間是否存在一定的關系?是否有利用各個產品特性之間的相互關系二次構成產品生態的可能性?
- 像CODE CHINA的話,他是依托於CSDN的,所以說代碼托管平台本身是可以依靠IT社區應用,從而產生關系的。
- 這樣的話,IT社區就可以和代碼托管平台一起二次構成產品生態(都是IT類)
產品規划
你要在當前軟件的基礎上設計什么樣的新功能?
- 我希望能在Github上添加一個站內通信的功能,就像我上面提到邀請協作者的時候需要郵件確認是很麻煩的,而且添加了站內通信還可以方便開發者之間交流(不限於提issue和pr的時候)
功能以及NABCD分析
• Need,需求
- 用戶之間的通信
- 必須先進行雙方認證,防止垃圾信息
- 組織內部通信
- 系統消息推送(協作、邀請加入組織、Features發布等)
• Approach,做法
- 技術
- 使用websocket
• Benfit,好處
- 用戶如果只是需要簡單的聯系對方,無需發郵件、提issue等操作
- 一些系統推送消息可以直接在github網站內完成,不用切換到郵箱(例如邀請協作)
- 界面簡潔,用戶可以在短時間內學會使用該產品
• Competitors,競爭
- 因為目前Github沒有站內通信功能,所以誕生了Gitter(開源社區),是潛在的競爭者
- 上線了站內通信功能的話可以拉走一部分只需要簡單發消息的用戶
- 在中國地區,CODE CHINA也是競爭者,因為他們依托於CSDN
- 但是CODE CHINA本身並沒有站內通信功能。
• Delivery,推廣
- 發布這個版本的之后,首次進入網站,可以考慮添加用戶引導。
- 依托於Github已有用戶的情況下,推廣不是什么難事。
角色配置
- 如果你是項目經理,可以招聘6個人,並且有4個月的時間,你認為應該如何配置角色(開發,測試,美工等等) 才能在第16周如期發布軟件的改進版本,並取得預想中的成績。
- 一位熟知目前Github網站架構的高級工程師
- 用來整合系統消息、用戶系統的接口
- 兩位前端開發人員
- 一位后端開發人員
- 一位原型設計
- 一位測試人員
- 一位熟知目前Github網站架構的高級工程師
16周的詳細計划
周數 | 詳細工作 |
---|---|
第一周 | 需求分析 |
第二周 | 原型設計 |
第三周 | 數據庫與系統設計 |
第四周 | 整合系統消息、用戶信息系統 |
第五到第七周 | 編碼階段,alpha沖刺 |
第八周 | 測試界面、接口(運用白盒、黑盒等方法) |
第九周到第十周 | 修改測試出現的問題 |
第十一周到第十二周 | 優化UI和代碼,beta沖刺 |
第十三周 | 發布試用版、收集用戶意見 |
第十四周到第十五周 | 根據用戶反饋修改功能 |
第十六周 | 發布正式版本 |