鄭悅強-實踐課:案例分析
阿新 • • 發佈:2022-04-10
這個作業屬於哪個課程 | 至誠軟工實踐F班 |
---|---|
這個作業要求在哪裡 | 作業連結 |
這個作業的目標 | i至誠功能測試 |
學號 | 212106749 |
第一部分 找Bug
1.日常i至誠使用體驗
常用功能固定至首頁,日常使用方便。介面相對簡潔,也可點選更多查詢更多服務。
2.測試環境
手機系統版本ios15.1
i至誠版本2.0.8
3.bug的可復現性及具體復現步驟
- 測試次數:10次
- 可復現性:10次
- bug必然發生
4.bug具體情況描述
Bug1、健康日報定位可自定義修改,不能實時獲取使用者定位。
Bug2、健康日報時間設定與北京時間不一致,不能準時打卡。
Bug3、賬號手機號換綁可隨意輸入號碼,不能識別輸入是否有誤。
Bug4、部分服務並沒有功能。
5.Bug分析
Bug的可能成因:健康日報設計的時候可能只是提供校內使用,就沒有增加定位功能。i至誠沒有提取裝置系統時間,導致i至誠內時間和裝置系統時間不一致。
Bug的嚴重性:軟體內時間不準,導致使用者體驗不佳,需要等時間到了之後才可填報。
對於Bug的預期及改進建議:可以把多餘的部分功能刪除,使軟體更加簡潔。
第二部分 功能分析
1.根據軟體已有的功能,評估其做到這個程度大約需要多少時間?(例如:團隊人數6人左右,計算機大學畢業生,並有專業UI支援)。
任務需求 | 週數 |
---|---|
問題的定義及規劃 | 2周 |
需求分析 | 1周 |
軟體設計 | 3周 |
軟體編碼 | 5周 |
軟體測試及bug修復 | 4周 |
軟體完成釋出 | 1周 |
2.分析這個軟體目前的優劣(和微信端的“至誠教務助手”相比),哪個更實用?
i至誠有ui介面相比公眾號的教務助手介面好看,不單隻有文字。i至誠主要用於健康日報填寫,學生外出申請,宿舍報修等,實際使用到的功能比較少。教務助手實現的功能更常用,學生課程學習通知、成績查詢,大多數使用的教務助手。
3.從各方面的問題,推理出這個軟體團隊在軟體工程方面可以提高的一個重要方面(具體建議)。
做好需要分析,減少開發沒有必要的功能,完善日常使用出現的Bug。
4.你在第一部分發現的bug,為何軟體團隊不能在釋出前修復?他們是不知道,還是有意不修復?你覺得是什麼原因?
可能感覺有些bug關係不大,不影響主要資訊收集所以就沒有去修復。
第三部分 建議和規劃
1、市場現狀
- 目前市場上是否有其他類似功能的產品、競品?
市場上也有類似校園軟體,提供校內日常生活服務。如完美校園,今日校園,智享校園
- 上述產品的定位、優勢與劣勢在哪裡?
使用群體都是在校學生,其實根據每個學校的群體日常使用進行開發就好,各個軟體不太好分辨優劣勢。
- 上述產品之間呈現什麼樣的關係,哪些為競品關係?以及競爭中的各方態勢如何?
產品定位都是一樣的,僅適用於校內服務。
2、市場與產品生態
-
產品的使用者群體之間是否存在一定的關係?是否有利用其相互作用二次構成特定使用者生態的可能性?
產品使用群體主要是校內師生,用於個人功能服務資訊提交申請之類。沒有構成特定使用者生態的可能性。
3、產品規劃
- 你要在當前軟體的基礎上設計什麼樣的新功能?為何要做這個功能,而不是其他功能?為什麼使用者會用你的產品/功能?你的創新在哪裡?
可以把教務助手的功能整合到軟體中,讓使用者使用都集中到一個地方。
- 如果你是專案經理,可以招聘6個人,並且有4個月的時間,你認為應該如何配置角色(開發,測試,美工等等) 才能在第16周如期釋出軟體的改進版本,並取得預想中的成績。
新增前端開發2人,後端開發2人,美工1人,測試1人。
- 請為你的團隊設計16個週期每週的詳細規劃。
開發週期 | 任務 | 開發週期 | 任務 |
---|---|---|---|
第一週 | 問題的定義及規劃 | 第九周 | 軟體編碼 |
第二週 | 問題的定義及規劃 | 第十週 | 軟體編碼 |
第三週 | 需求分析 | 第十一週 | 軟體編碼 |
第四周 | 軟體設計 | 第十二週 | 軟體測試及bug修復 |
第五週 | 軟體設計 | 第十三週 | 軟體測試及bug修復 |
第六週 | 軟體設計 | 第十四周 | 軟體測試及bug修復 |
第七週 | 軟體編碼 | 第十五週 | 軟體測試及bug修復 |
第八週 | 軟體編碼 | 第十六週 | 軟體完成釋出 |