張泓---實踐課:案例分析
這個作業屬於哪個課程 | 至誠軟工實踐F班 |
---|---|
這個作業要求在哪裡 | https://edu.cnblogs.com/campus/fzzcxy/ZhichengSoftengineeringPracticeFclass/homework/12580 |
這個作業的目標 | 完成對i至誠的分析 |
張泓 | 212106745 |
第一部分 找Bug(黑白盒測試)
1.列出你認為的嚴重影響使用者體驗的Bug,並用專業的語言描述,參考要點如下:(必答)
(1) 功能未實現已經存在服務中 例如:宿舍點名系統,課堂點名系統等等
建議先刪除未實現的專案,待實現是在公告區域體現並增加該服務
(2) i至誠->服務->考核系統
在考核系統中提示:”考核未開始或你不是學院年終考核評委“並倒計時跳轉,倒計時結束並未進行跳轉
(3) i至誠->服務->日常服務->線上保修->報修記錄
在保修記錄中所有的記錄不論是進行中、已派工、待確定等等都不會結束,也不會因為時間而自動結束都是待完成狀態
第二部分 功能分析(參考8.6節對工作的估計,和14.1節軟體工程的質量)
1、根據軟體已有的功能,評估其做到這個程度大約需要多少時間?(例如:團隊人數6人左右,計算機大學畢業生,並有專業UI支援)。(必答)
大致需要15周左右的時間
時間 | 階段 |
---|---|
2周 | 專案的市場調研需求分析 |
1周 | 人員分工以及初步模型 |
6周 | 完整模型以及程式設計部分 |
1周 | 進行第一次測試並寫測試報告 |
2周 | 修復bug,並進行二次測試寫測試報告 |
1周 | 對於二次測試結果進行優化修改完善 |
1周 | 進行最後一次測試並進行優化 |
1周 | 專案總結 |
2、分析這個軟體目前的優劣(和微信端的“至誠教務助手”相比),哪個更實用?(必答)
優勢:相比於“至誠教務助手”更加的穩定,實現的功能也比較多,在頁面上來說i至誠的排版更加簡潔,比較下“至誠教務助手”就顯的擁擠。
劣勢:i至誠服務與本校學生和老師,但也僅限於本校師生同時需要下載不如 “至誠教務助手”便捷,相對於“至誠教務助手”有較高的侷限性
3、從各方面的問題,推理出這個軟體團隊在軟體工程方面可以提高的一個重要方面(具體建議)
有許多的功能並未完成,定期維護優化功能
4、你在第一部分發現的bug,為何軟體團隊不能在釋出前修復?他們是不知道,還是有意不修復?你覺得是什麼原因?可以從下面的可能性中選取幾個。
1.對使用者需求掌握不好 2.具體的設計質量不高
第三部分 建議和規劃(參考《構建之法》第8章功能的定位和優先順序;第9章專案經理)
這個軟體有很多可以提高的部分,如果你是新上任的專案經理,你將如何提高從而使其更富競爭力?請針對以下問題進行思考:
一、市場現狀
1、目前市場上是否有其他類似功能的產品、競品?
自然是有相類似的功能產品,每個學校都有其屬於自身的功能類似的App亦或是小程式或者是公眾號,感覺上是各自學校用各種的類似產品應該不會成為競品
2、上述產品的定位、優勢與劣勢在哪裡?
上述的類似產品都是提供給自身學校的師生使用,優勢自然是更輕鬆將學校和學生聯絡起來,更貼近該學校師生的使用需求,更容易對使用時產生的反饋進行修改和完善。劣勢上是產品還存在bug,一些功能需要完善。
3、上述產品之間呈現什麼樣的關係,哪些為競品關係?以及競爭中的各方態勢如何?
上述的產品,產品和產品更傾向於相互的完善一起進步一起發展、拓展,各自學校用各種的類似產品應該不會成為競品
二、市場與產品生態
1、產品的使用者群體之間是否存在一定的關係?是否有利用其相互作用二次構成特定使用者生態的可能性?
以本校為例學生、老師使用i至誠,疫情期間或多或少因為一些原因需要出校或是其他事情,都需要向i至誠遞交申請,是可以利用其相互作用二次構成特定使用者生態的可能性
2、產品的子產品,以及其他相關產品之間是否存在一定的關係?是否有利用各個產品特性之間的相互關係二次構成產品生態的可能性?
作為上述產品的子產品,自然是有增加或者是補充功能,同時應該也可以利用各個產品特性之間的相互關係二次構成產品生態的可能性
三、產品規劃
1、如果你是專案經理,可以招聘6個人,並且有4個月的時間,你認為應該如何配置角色(開發,測試,美工等等) 才能在第16周如期釋出軟體的改進版本,並取得預想中的成績。
3名開發人員(前後端),2名測試人員,1名美工
2、請為你的團隊設計16個週期每週的詳細規劃。
時間(周) | 階段 |
---|---|
1-2 | 需求分析以及專案的市場調研 |
3 | 人員工作分配,完成初步模型 |
4-10 | 建立完整模型,完成程式設計部分 |
11-12 | 測試人員進行測試,修復bug完善功能 |
13-14 | 優化程式碼,進行二次測試 |
15 | 對於二次測試結果進行優化修改完善 |
16 | 釋出專案 |