1. 程式人生 > 其它 >實踐課:i至誠app案例分析---江潔蘭

實踐課:i至誠app案例分析---江潔蘭

這個作業屬於哪個課程 至誠軟工實踐F班
這個作業要求在哪裡 [作業要求] (https://edu.cnblogs.com/campus/fzzcxy/ZhichengSoftengineeringPracticeFclass/homework/12580)
這個作業的目標 分析產品軟體,找出其中的問題並進行分析,提高對產品軟體bug方面的認識
學號 212106715

第一部分 找Bug

Bug發生時的測試環境

  作業系統:HarmonyOs2.0.0,手機:榮耀9X
bug程度劃分

星星數 嚴重程度
⭐⭐⭐⭐⭐ 致命
⭐⭐⭐⭐ 嚴重
⭐⭐⭐ 一般
輕微

Bug具體情況描述

1. 健康日報填報時間和提交時間有延遲

可復現性:必然發生,bug程度:⭐⭐⭐

2.進校申請提交後找不到更改申請資訊的地方,如果提交的申請資訊有錯,或者沒有得到輔導員同意,只能撤回或者終止後重新提交,不能修改,很不方便。

可復現性:必然發生,bug程度:⭐⭐⭐⭐

3.校園一卡通-離線碼,點進去並沒有離線碼

可復現性:必然發生,bug程度:⭐⭐

4.辦公管理-考核系統-頁面跳轉失敗

可復現性:必然發生,bug程度:⭐⭐

5.安全設定-手機號繫結和郵箱繫結,只能輸入四位字元,無法完成繫結

可復現性:必然發生,bug程度:⭐⭐⭐⭐

6.重置密碼的時候點右邊的眼睛,密碼還是看得到,重置密碼後不需要重新登入,自己退出登入後再登入才需要輸入新密碼

可復現性:必然發生,bug程度:⭐⭐⭐⭐

Bug分析

可能成因

  開發人員疏忽大意,測試工作做得不完善,沒有反饋功能,使用者在使用過程中發現bug後無法反饋給維護人員,維護人員不能及時意識到需要完善。

嚴重性

  app展示的功能沒有完全實現,存在功能缺陷,存在使用者體驗很不好的方面。

改進建議沒有實現的功能都實現,增加反饋功能,以便能及時獲取使用者反饋,進一步改善app。

第二部分 功能分析

根據軟體已有的功能,評估其做到這個程度大約需要多少時間?(例如:團隊人數6人左右,計算機大學畢業生,並有專業UI支援)。

階段 所花時間
需求分析 2周
程式設計 1周
編碼 14周
測試 3周

分析這個軟體目前的優劣(和微信端的“至誠教務助手”相比),哪個更實用?(必答)

  我覺得該軟體的功能沒有完全實現,使用者體驗感不高,至誠教務助手只需關注公眾號,無需再下一個app,查課表、查成績等都比較便捷,所以我認為至誠教務助手更實用。

從各方面的問題,推理出這個軟體團隊在軟體工程方面可以提高的一個重要方面(具體建議)。

  軟體測試方面,測試是對軟體功能實現的檢測,也是對軟體整體部分的檢測,建議儘可能在系統安全、功能實現、使用者體驗等其他對軟體進行全面的測試,將測試出來的問題及時解決。

你在第一部分發現的bug,為何軟體團隊不能在釋出前修復?他們是不知道,還是有意不修復?你覺得是什麼原因?

  開發人員粗心大意,可能是有意不修復,以及測試把關不嚴,敷衍了事,沒有注意在特殊的配置或環境下測試。

第三部分 建議和規劃!

市場現狀

目前市場上是否有其他類似功能的產品、競品?

功能相似的產品:校園專屬app,競品:樂雲一卡通

上述產品的定位、優勢與劣勢在哪裡?

定位:為在校生服務
優勢:有app和微信公眾號兩個平臺,滿足在校生在校使用需求
劣勢:

上述產品之間呈現什麼樣的關係,哪些為競品關係?以及競爭中的各方態勢如何?

市場與產品生態

產品的使用者群體之間是否存在一定的關係?是否有利用其相互作用二次構成特定使用者生態的可能性?

產品的子產品,以及其他相關產品之間是否存在一定的關係?是否有利用各個產品特性之間的相互關係二次構成產品生態的可能性?

產品規劃

你要在當前軟體的基礎上設計什麼樣的新功能?為何要做這個功能,而不是其他功能?為什麼使用者會用你的產品/功能?你的創新在哪裡?可以用NABCD分析。

  新功能:校園導航,幫助新生了解所在位置,指引新生去到目的地。
  原因:對不熟悉校園的新生來說,具有實用性。新生剛入學,對校園環境不瞭解,雖然說會有校園地圖提供給新生,有時候地圖表達的可能不夠清楚,更有可能有新生看不懂校園地圖又羞於問路。
  創新點:地圖導航和校園app結合

如果你是專案經理,可以招聘6個人,並且有4個月的時間,你認為應該如何配置角色(開發,測試,美工等等) 才能在第16周如期釋出軟體的改進版本,並取得預想中的成績。

角色配置:兩名名開發,兩名測試,一名美工,一名架構師
請為你的團隊設計16個週期每週的詳細規劃。
  詳細規劃

時間 工作內容
第一週——第二週 做調研,瞭解使用者使用該產品過程中存在的不足之處,以及使用者希望改進的方面
第三週——第四周 兩名測試對現有版本進行測試,生成測試文件
第五週——第七週 架構師確定改進方案
第八週——第十二週 編碼實現改進
第十三週——第十四周 測試,且提交測試後的修改
第十五週 邀請部分使用者體驗
第十六週 最後完善