軟工實踐作業(十)
調研,評測
評測
上手體驗
- 身份驗證的操作邏輯有些詭異;
- 介面設計到處透露出半成品的氣息(更想說是隨便做的氣息
- 基本是直接引用網頁或其他應用,像是為完成而完成;
- 功能稀少,看似一大排,其實好些是無意義、不可用或可以整合的功能,諸如學生工作管理等功能卻沒有整合在一起;
- 介面乾淨。
BUG
此次測試的機型有兩款,以下的bug在兩款機器上基本都有出現。
- 索尼Xperia XZ Premium( Android8.0 )
- iPad Pro 10.5' ( IOS 12.1 )
使用的軟體平臺為 微信6.7.3 ( Android ) 和 微信6.7.4 ( IOS )。
以下截圖基本為iPad的微信上的截圖。
成績查詢的年份選擇有限
- 重現步驟:進入福大企業號,進入成績查詢頁面,點選學年;
- 內容:學年選擇只有2012到2016;
- 建議:增加其他年份的成績查詢功能。目前2016屆也已經大三了,所以需要查成績的學生基本無法使用這個企業號查到成績。
個人日程的本地日曆同步功能
- 重現步驟:進入福大企業號,進入個人日程頁面,點選設定(底欄最右),點選同步本地日曆;
- 內容:點選同步本地日曆後提示“請從APP操作!”
- 建議:可完善功能,做好與本地日曆日程同步的功能,或者直接去掉。實際上此處的問題讓人覺得這個個人日程功能是從其他地方直接拿來用的。
個人日程的新增日程中的重現選項消失
- 重現步驟:進入福大企業號,進入個人日程頁面,點選懸浮加號按鈕,點選新增日程,選擇全天;
- 內容:選擇全天后,重複週期選項消失;
- 建議:不要讓它消失。實際上經過嘗試,如果在選擇全天前先選擇重複週期,重複週期仍然有效,即使它消失了。
個人日程的日、周、月的日程顯示
- 重現步驟:進入福大企業號,進入個人日程頁面,點選日/周/月;
- 內容:當日程較多時,有部分日程無法顯示;
- 建議:讓顯示框完全按照日程數增長或使顯示框能夠滾動。
個人日程的日程編輯功能
- 重現步驟:進入福大企業號,進入個人日程頁面,點選任一日程,點選懸浮加號按鈕,點選編輯,任意修改,點選懸浮加號按鈕,點選儲存;
- 內容:點選儲存後頁面無反應,返回後日程資訊也並沒有被改變;
- 建議:完善功能。
個人日程的日程備註功能
- 重現步驟:進入福大企業號,進入個人日程頁面,點選懸浮加號按鈕,點選新增,填寫備註和其他資訊,點選懸浮加號按鈕,點選儲存;
- 內容:如果備註內容超過255個字元,點選儲存後頁面無反應,返回後日程資訊也並沒有被改變;
- 建議:完善功能或增加長度限制提示。
我的課表的檢視課表功能
- 重現步驟:進入福大企業號,進入我的課表頁面;
- 內容:在有課的情況下顯示沒有課;
- 建議:完善功能。
原因分析
許多問題已經超出了技術上的bug的範疇。
- 開發未完成;
- 開發人員對此專案並不上心。
需要注意的
- 遵循團隊的程式碼規範,提高專案的可維護性;
- 功能性框架依賴性不能太強,善用開源框架,需要經過充分的測試選擇成熟穩定的框架,例如網路請求框架;
- 注意封裝一些重複性功能,適度耦合,通過統一入口進行呼叫,方便維護修改,也方便擴充套件,例如常用的新增附件功能;
- 估計專案的規模大小及使用者群體的訪問量,選擇可靠的開發和執行環境;
- 開發者在程式設計之外還需要注意編寫單元測試,介面部分需要更新到團隊的彙總中;
- 需要注意前端和後端的之間的除錯方式,各層之間通訊設計按照微服務架構的設計原則,這些服務需要共享資料庫;
- 考慮使用者資料的安全性,以及操作的安全性(例如連續點選按鈕可能出現的情況);
- 始終堅持以使用者為本的原則,在設計時儘量減少使用者的使用負擔。
採訪
- 背景:一名普通的計算機系大三學生;
- 需求:需要能夠查詢成績、課表,如果能整合學生管理功能,如請假審批、節假日去向等就更好了。
- 使用者的問題並沒有得到解決。
模組 | 優點 | 缺點 |
---|---|---|
資料量 | 部分功能直接連結網頁,內容豐富 | 部分功能無法提供任何資訊 |
介面 | 軟體的整體介面整潔 | 部分操作邏輯較不合理,部分介面設計較不友好、美觀 |
功能 | 能夠檢視主頁、新聞等 | 1.部分功能不可用;2.部分功能存在bug,使用者體驗不夠友好;3.直接連結網頁影響響應速度 |
準確度 | 部分功能都能正確響應 | 部分操作存在問題 |
使用者體驗:使用者體驗很不友好,在介面佈局、功能、反應速度等方面都或多或少存在著問題。
改進意見:將現有功能完善至可用,如可能,可考慮整合入學生管理功能。
結論:非常不推薦
分析
時間預估
大約一個月。
理由:功能較少,實現難度不高,但對於剛畢業的大學生,還是需要一定時間的。
軟體優劣
- 優勢
具備主頁、新聞、公告檢視等基本功能,介面簡潔。
- 劣勢
部分功能不可用,部分功能存在較多bug,使用者體驗差。
對比同類軟體:
主要是兩類:一類是同為福大系的軟體,另一類是同為微校系的軟體。
相比於同為福大系的福大助手、福大教務通和福大一卡通等,本軟體由於響應速度較不友好,所以身為微信平臺企業號的輕便優勢基本沒有,更不用提許多功能不可用、bug眾多等。
相比於同為微校系的軟體們,我對比了暨南大學的微校號。暨南微校的介面友好,操作簡便流暢,具有完整的校內通訊錄,直通各位學生微訊號,且整合有如請假審批、抽籤、簽到、學生工作、問卷調研等功能,使用者體驗良好。
具體建議
- 完善功能,提高使用者體驗;
- 應注重介面的設計,追求美觀,避免介面邏輯混亂,不能讓使用者在還沒使用時就對軟體產生不好的印象;
- 同時注重軟體效能,響應速度過慢或者bug較多都會很大程度地降低使用者體驗;
- 要有有效且便捷的使用者反饋渠道,讓使用者參與到軟體的迭代過程中以便更好地提高使用者體驗。
功能邏輯框圖
模組分析
模組 | 重要度 | 完成度 | 出發點 | 效果 |
---|---|---|---|---|
通知檔案 | 非常重要 | 80 | 主要用於檢視通知檔案,公示以及校內公告 | 能夠檢視所需內容 |
福大主頁 | 非常重要 | 75 | 主要用於檢視關於福大的重要資訊 | 連結向福大主頁的網頁,能滿足要求 |
校園新聞 | 非常重要 | 80 | 主要用於檢視福大的校園新聞 | 分為三類進行新聞訂閱,可檢視相關新聞,可搜尋,可調節字型和設定夜間模式,較友好 |
福大郵箱 | 重要 | 75 | 主要用於登入使用者的福大郵箱 | 連結向福大郵箱的網頁版 |
福大黃頁 | 非常重要 | 80 | 主要用於檢視福大各部門電話號碼 | 能夠檢視所需內容,操作簡便 |
我的課表 | 重要 | 主要用於檢視使用者的課表 | 無法顯示課表資訊 | |
成績查詢 | 重要 | 主要用於檢視使用者的成績 | 由於年份選擇有限,無法檢視絕大多數使用者的成績 | |
個人日程 | 一般 | 70 | 主要用於檢視使用者的日程 | 能進行部分基本操作,但bug較多,且介面不友好 |
移動OA | 一般 | 無法使用 | ||
失物招領 | 非常重要 | 80 | 主要用於檢視、釋出失物招領和尋物啟事資訊 | 能夠檢視、釋出失物招領和尋物啟事資訊,操作簡便 |
校園巴士 | 一般 | 70 | 主要用於檢視校園巴士的執行資訊 | 能檢視到基本資訊,但所提供的資訊量較小,無法為使用者提供有效幫助 |
講座報告 | 重要 | 80 | 主要用於檢視講座報告的相關資訊 | 能檢視到所需資訊,但介面設計和內容排版較不友好 |
學生證附卡 | 重要 | 主要用於檢視、更新學生證附卡資訊 | 能檢視到部分資訊,其他功能不可用 |
評分
模組 | 打分 | 理由 |
---|---|---|
使用者體驗 | 60分 | 反應速度慢,且存在較多bug,使用者體驗不好 |
UI介面 | 70分 | 介面簡潔,部分操作邏輯較不合理 |
核心功能 | 60分 | 功能略顯單薄,一些簡單的需求能夠滿足,許多功能無法使用 |
建議和規劃
- 如果你是專案經理,如何提高從而在競爭中勝出?
我認為需要提高的地方大致有量點:
首先是軟體的質量問題,目前的使用者體驗還不夠好。在試用和測試的過程中可以很明確地感受到這個軟體在設計製作上的嚴重不足。若將其與功能齊全,製作也較為完善的福大助手或其他微校相比較,那根本就是雲泥之別。從介面設計不合理到功能設定不完善,這款軟體的app需要改進的地方有非常多,更不要說與對手競爭、吸引使用者了。它連滿足使用者的基本要求都非常困難。沒有誰會願意浪費時間在一款並不便捷,使用體驗也不盡如人意的軟體上的。
其次是宣傳。我們學校關於自己公眾號和企業號的宣傳基本沒有。如果不是這次作業,我甚至不知道我們學校有這樣的軟體存在。這對於一款需要學生支援的軟體來說是致命的,所以應加強宣傳,提高在本校生,甚至在外校生中的知名度,這也有利於提高學校在學生中的聲譽。
- 目前市場上有什麼樣的產品了?
主要是兩類:一類是同為福大系的軟體,另一類是同為微校系的軟體。
相比於同為福大系的福大助手、福大教務通和福大一卡通等,本軟體由於響應速度較不友好,所以身為微信平臺企業號的輕便優勢基本沒有,更不用提許多功能不可用、bug眾多等。
相比於同為微校系的軟體們,我對比了暨南大學的微校號。暨南微校的介面友好,操作簡便流暢,具有完整的校內通訊錄,直通各位學生微訊號,且整合有如請假審批、抽籤、簽到、學生工作、問卷調研等功能,使用者體驗良好。
- 你要設計什麼樣的功能?
一個學生管理的功能。該功能可以協助學生工作,幫助學生和輔導員進行請假、節假日的審批。
- 為何要做這個功能,而不是其他功能?
目前我們學校的軟體中還缺乏類似的功能。所有相關的審批和表格填寫都需要人工在紙質假條、表格上進行填寫,每次請假都需要填寫紙質假條再交給輔導員簽字,非常不便。
- 你的創新在哪裡?可以用 NABCD 分析。
Need
現在我們學校的軟體中還缺乏類似的功能。所有相關的審批和表格填寫都需要使用紙質檔案,耗時耗力,電子化是大勢所趨。
Approad
新增一個審批模組,提供假條填寫和記錄、節假日去向填寫等功能,並且不斷完善。甚至可以新增電子化簽名、存檔等功能
Benefit
能夠便利學生和輔導員的學習和工作,也讓檔案管理更加簡便。
Competitors
目前校內還沒有相關產品。
Delivery
對於這類校園應用,特別是這種嵌入學生、輔導員工作中的應用,首先必須得到學校的支援,之後的推廣就比較簡單。先通過老師或輔導員瞭解學校在這方面的意向,然後爭取與相關工作的老師進行溝通。在獲得支援後也要注重使用者反饋,及時修復、增添功能,讓軟體能真正便利大家的生活。
- 如果你來領導這個團隊,會有什麼不一樣?
經過這次的測試可以看出,該軟體還比較簡陋:功能少、部分設計不合理,還有存在很多bug。如果由我來領導團隊,會更注重介面的美觀和基本功能的可用性。
- 如果你的團隊有5個人,4個月的時間,你作為專案經理,應該如何配置角色(開發,測試,美工等等)?
美工一人(包括UI和原型設計)
開發三人(前端兩人,後端一人)
測試一人(開發階段輔助後端)
- 描述你的團隊在16週期間每週都要做什麼,才能在第16周如期釋出軟體,大小里程碑績點設定。
週數 | 任務 | 里程碑 |
---|---|---|
1 | 確定專案內容與專案核心,進行需求分析,初步完成需求說明書 | |
2 | 完善需求規格說明書,明確分工,計劃好接下來的時間安排 | 完成需求分析 |
3-4 | 搭建開發環境,制定編碼規範,構建架構,進行原型設計 | 完成原型設計 |
5-7 | 開始主體功能的編碼,美工完成UI設計,前端與後端並行,根據具體情況調整進度 | |
8 | 功能完善,測試,並改進 | 釋出Alpha版本 |
9-11 | 開始其它功能的編碼,完成介面設計,實現對接,完成剩餘模組的任務 | |
12 | 繼續完善各功能模組,初步完成正式版本 | 釋出Beta版本 |
13-14 | 大規模測試,修復bug,根據反饋不斷調整完善最終版產品 | |
15 | 編寫使用者手冊 | 使用者手冊完成 |
16 | 專案部署,釋出最終版本的產品 | 專案部署,釋出最終版本的產品。 |
- 專案釋出後,有沒有考慮過專案該怎麼部署才能滿足需求。依據下圖(某校教務處系統的部署)作為參考,分析16周後你所完成的專案上線需要哪些配套裝置(伺服器、頻寬、資料庫需求數量與配置) 。
負載均衡:2臺(主備)
應用伺服器:16核32G 2臺
後端伺服器:32核64G 3臺
關係型資料庫:MySql 3個(讀寫分離2個,備份1個)
快取資料庫:Redis 2個(主備)
頻寬:採用千兆乙太網連線