1. 程式人生 > >軟工1816 · 作業(十)專案測評(團隊)

軟工1816 · 作業(十)專案測評(團隊)

第一部分 調研,評測

評測

安卓端評測

  • 測試人:文垚

  • 描述最簡單直觀的個人第一次上手體驗。

  • 第一次上手體驗,操作簡單,介面簡潔。課程表與超級課程表差不多,不同課程不同顏色顯示,簡潔明瞭。但是整體介面在簡潔中透露出些許簡陋,整體UI設計缺少靈性,只有最基本的框架沒有進行優化,不夠美觀。特別是教務通知這一版塊,顯示過於簡陋,教務通知顯示經常出現排版混亂的問題。

  • 使用思維導圖,描述福大助手的結構體系

  • 按照描述的bug定義,找出至少兩個功能性的比較嚴重的bug。

  • 用專業的語言描述bug(每個bug 不少於 40字),並適當配圖.

  - 評議完成,但獲取成績資料失敗。具體表現為使用易班版塊中的“一鍵XX”功能對老師進行評議,評議完成後仍然無法檢視成績,顯示獲取成績資料失敗。經過一段時間後再次查詢成績,成功。
      

  • 評議完成

  • 獲取成績資料失敗

  - 使用圖書館功能查詢圖書,某些情況下直接閃退。具體表現為使用圖書館版塊中的查詢圖書功能,當本次查詢結果只有一個時,繼續查詢其他書籍將直接閃退。例如查詢《應用統計方法辭典》,查詢結果只有一個。再次查詢其他書籍,如《計算機組成原理》,直接閃退。

  • 你覺得為什麼這個產品組的人沒有發現這些bug?

  - 我認為產品組的人沒有發現這個bug的原因可能是產品研發完成後,測試組的成員對軟體進行的測試不夠全面,忽略了這些bug。

  • 假設你們團隊需要開發這套系統,需要注意哪些方面(架構、部署運維、微服務等)

  - 我認為團隊需要注意到接入其他學校資源的介面時要兼顧手機端和介面的相容性

IOS端評測

  • 測試人:恆達

  • 描述最簡單直觀的個人第一次上手體驗。

  • 軟體開啟後直接顯示課程表,這對經常需要檢視課表的我來說是非常方便的,開啟側邊欄後突然注意到福大助手中還有這麼多功能我沒有使用過,我平常的使用中最經常使用的功能是檢視課程表和檢視成績,至於其他功能卻很少用到過,感覺應用可以設立一個引導頁面來指導新使用者快速掌握應用的各個功能的位置

  • 使用思維導圖,描述福大助手的結構體系

  • 按照描述的bug定義,找出至少兩個功能性的比較嚴重的bug。

  • 用專業的語言描述bug(每個bug 不少於 40字),並適當配圖.

  - 點選設定內的推送後程序就能順利崩潰(未開推送狀態:進頁面後直接閃退;推送許可權開啟:進頁面不閃退但是應用無響應)

  - 成績功能模組中的各個學年的各科成績對應的績點無法統計出來,之後點選重新整理問題已經存在,完全退出軟體重新開啟軟體問題已經存在。

  • 你覺得為什麼這個產品組的人沒有發現這些bug?

  - 我認為這個問題產生的可能原因在於:1、產品組沒有對該功能進行詳細的測試,導致前端與後端資料對接的時候績點這個欄位的值讀取失敗 2、或者該介面本身就沒有傳遞這個資料產品組雖然知道問題存在不過也無能為力

  • 假設你們團隊需要開發這套系統,需要注意哪些方面(架構、部署運維、微服務等)

  - 我認為團隊需要注意根據專案的後期維護,不斷保持產品各個功能的可用性

採訪

採訪一

  • 介紹採訪物件的背景和需求(他們有沒有用過類似的APP,除了現有的功能還有別的需求麼)

  - 福大在讀大三學生,只用過教務通,需求:希望檢視並下載課程的課件和歷年卷

  • 讓採訪物件使用福大助手(請上傳照片證明使用者的確正在使用,遠端採訪的同學請讓別人幫忙照相)

  • 描述使用者使用這個產品的過程,使用者的問題解決了麼?軟體在資料量/介面/功能/準確度上各有什麼優缺點?使用者體驗方面有問題麼?

  - 問題解決了,除了使用基本功能外使用者還下載了很多的課程學習資料。軟體的介面簡約,主題還可根據個人喜好設定,功能完善,課程資訊準確度極高。體驗方面沒有問題。

  • 使用者對產品有什麼改進意見?

  - 使用者提出的改進意見是歷年卷資料很多過時,希望能及時更新。

  • 結論:

  - 非常推薦

  採訪二

  • 介紹採訪物件的背景和需求(他們有沒有用過類似的APP,除了現有的功能還有別的需求麼)

  - 福大在讀大三學生,用過教務通,超級課程表,除了現有功能外無其他需求。

  • 讓採訪物件使用福大助手(請上傳照片證明使用者的確正在使用,遠端採訪的同學請讓別人幫忙照相)

  • 描述使用者使用這個產品的過程,使用者的問題解決了麼?軟體在資料量/介面/功能/準確度上各有什麼優缺點?使用者體驗方面有問題麼?

  - 優點:軟體介面精美,功能齊全,執行流暢,課程資訊的準確度高,體驗方面沒有問題。

  • 使用者對產品有什麼改進意見?

  - 成績查詢功能裡缺少檢視課程平均分和最高分的功能,以及缺少績點排名的變化走勢圖,希望能新增該功能。

  • 結論:

   - 推薦

  採訪三、

  • 介紹採訪物件的背景和需求(他們有沒有用過類似的APP,除了現有的功能還有別的需求麼)

  - 福大在讀大三學生,用過教務通,易班,需求:除了現有功能還經常使用易班進行相關學習工作,希望二者能整合到一起

  • 讓採訪物件使用福大助手(請上傳照片證明使用者的確正在使用,遠端採訪的同學請讓別人幫忙照相)

  • 描述使用者使用這個產品的過程,使用者的問題解決了麼?軟體在資料量/介面/功能/準確度上各有什麼優缺點?使用者體驗方面有問題麼?

  - 問題解決了,在福大助手中就可直接點開易班,省去了多個軟體來回切換的麻煩。軟體功能齊全,包括我們經常使用到的空教室查詢,圖書館查詢,考場查詢等都有具備

  • 使用者對產品有什麼改進意見?

  - 使用者提出希望能增加選課教師資訊檢視的功能,可以在選課時瞭解到各個選課老師的資訊,方便選擇。

  • 結論:

  - 推薦

分析

  • 估計這個專案做到這個程度大約需要多少時間(團隊人數6人左右,計算機大學畢業生,並有專業UI 支援)。

 - 大概一個半月

  • 分析這個軟體目前的優劣(和類似軟體相比),並推理出開發團隊在軟體工程方面可以提高的一個重要部分(具體建議)。

  - 優勢:相比同類軟體(福大教務通), 介面UI更美觀, 功能更加齊全,覆蓋了日常學習中會使用的大部分功能。

  - 劣勢:功能繁雜,功能入口不清晰,程式穩定性有提升空間

  - 建議:主要要提高的地方就在UI的一些細節上,部分地方風格不是很統一。以及介面的穩定性上,加以改進,部分功能無法使用。

  • 根據理解和體驗,畫出整個軟體所有功能邏輯框圖,根據重要度標識出各模組的重要度、完成度、出發點及效果

 - 重要: 登入, 課程表, 查成績, 考場查詢

 - 一般: 歷年卷, 大物實驗, 易班, 圖書館, 教務通知

 - 不重要: 空教室, 嘉錫講壇, 校招日曆, 設定, 登出

  • 完成度:大部分功能都有完成,處理查成績判斷應該是介面問題,暫時無法使用。嘉熙講壇為對介面進行美化直接套web。

  • 功能邏輯框圖

image

  • 針對不同的維度評分,對使用者體驗方面、UI介面美觀度、核心功能,分別打分。

  - 使用者體驗方面:  8

  - UI介面美觀度:  8.5

  - 核心功能:  8

建議和規劃

  • 如果你是專案經理,如何提高從而在競爭中勝出?

  - 據前期的問卷調查以及小組內的個人生活經歷,我們認為福大助手的軟體質量是值得讚揚的,而在app store中它的評分是滿分五顆星,這也從側面體現了福大助手的軟體質量.不過我認為福大助手在一些方面仍然有提高的空間.首先是推廣方面,在日常生活中我們很少看到福大助手的廣告或者其他推廣手段,同學們知道有這麼一款軟體的存在也是因為口耳相傳雖然福大助手可以說是校內唯一的校園服務類app,即使不進行推廣有需求的同學也會在需要時自發下載,但是缺乏推廣就使得很多同學不知道這麼一款好軟體的存在,如果我是專案經理,我會花費一些精力在產品的推廣上,比如在新生入學時向學生們推廣這款軟體

  • 目前市場上有什麼樣的產品了?

  - 目前市面上與這款軟體定位類似的軟體有福大易班,福大教務通

  • 我們計劃設計的功能:

  - 新增福大地圖導航功能:對目前市面上的導航軟體沒有的一些福大地標進行導航(比如福大資訊辦,福大教學樓監控室)

  • 為何要做這個功能,而不是其他功能?

  - 市面上的導航軟體對大學內的導航存在一些盲區,普通使用者在通過這些地圖無法快速找到目的地,而通過瀏覽福大網站來找到相應地標的方式又比較繁雜而成功率不高,舉個例子:福州大學的教學區監控室在中樓3樓多媒體監控廳,這在市面上流行的導航地圖中都是查不到。

  • 為什麼使用者會用你的產品/功能?

  - 市面上的導航軟體還沒有將精力投入到校園內的導航,對一些只流傳於同學口中的地點導航地圖更是無法顧及,因此我們的校園導航功能瞄準的就是這個痛點。

  • 你的創新在哪裡?可以用 NABCD 分析。

  -  NEED:市面上的導航軟體對大學內的導航存在一些盲區,普通使用者在通過這些地圖無法快速找到目的地,而通過瀏覽福大網站來找到相應地標的方式又比較繁雜而成功率不高,舉個例子:福州大學的教學區監控室在中樓3樓多媒體監控廳,這在市面上流行的導航地圖中都是查不到。

  -  APPROACH:在福大助手中新增校園地圖功能,通過問卷調查並在福大相關網站上收集福大的詳細地標,並將資料整合到我們的福大地圖中,形成福大地圖導航

  -  BENIFIT:節約同學們校內尋路的時間,節約同學們因不知道校內某個地點而向其他人詢問的時間

  -  COMPETITOR:目前市面上的導航軟體在校內導航做得並不好,而且針對校內一些只流傳於同學口中的地點導航地圖更是無法顧及,所以我們目前的競爭對手在資訊來源這方面無法與我們的優勢比擬

  -  DELIVERY:我們會積極尋求與校方合作,借用校方的宣傳渠道為我們的產品進行推廣(畢竟是根正苗紅的福大app)

  • 如果你來領導這個團隊,會有什麼不一樣?

  -  如果我來領導這個團隊,我會更注重專案的推廣,因為根據我們釋出的100人問卷的結果顯示,仍然有12%的人沒有聽說過“福大助手” 這款軟體,此外我們也會積極尋求和校方合作,藉助學校的渠道來幫助宣傳我們的軟體

  • 如果你的團隊有5個人, 4個月的時間,你作為專案經理,應該如何配置角色(開發,測試,美工等等)?

  -  我們的分配:前端-2人 後端-2人 測試-1人

  • 描述你的團隊在16 週期間每週都要做什麼,才能在第16周如期釋出軟體,大小里程碑績點設定。
週數 計劃 里程碑 績點
1 問題定義,可行性研究,需求分析 完成專案需求說明書 10%
2 軟體總體設計,詳細設計 用層次圖完成軟體結構設計,編寫程式規格說明書 30%
3-10 具體編碼及單元測試 將詳細設計的結果翻譯成專案所用的語言,並編寫相應的單元測試,釋出alpha版本 30%
11 綜合測試 針對小部分目標使用者展開Alpha版本的使用評測,收集產品缺陷與改進之處 5%
12-15 beta版本開發 針對Alpha版本中存在的軟體缺陷進行改進,按照規格說明書中的驗收標準對產品進行驗收 15%
16 正式版本釋出 軟體按照規格說明書中的定義良好的執行 10%
  • 專案釋出後,有沒有考慮過專案該怎麼部署才能滿足需求。依據附錄圖(某校教務處系統的部署)作為參考,分析16周後你所完成的專案上線需要哪些配套裝置(伺服器、頻寬、資料庫需求數量與配置) 。

  -  我們認為為了滿足目前的使用者規模我們需要:
    -  負載均衡:2臺
    -  應用伺服器:16核32G 2臺
    -  後端伺服器:32核64G 3臺
    -  關係型資料庫:Oracle 3個 主從資料庫+備份
    -  快取資料庫:Redis 2個 主備

增量開發設計

  • 優化/新增功能點的原型介面:福大校園地圖導航

  - 假設需要查詢福大資訊化辦公室

  2018-12-07_17-19-29.gif

  • 基本實現思路

  - 接入百度地圖SDK,並根據我們對福大學生的問卷調查以及訪問福大各個機構官網查詢機構地址形成地理資料匯入到地圖中。

  • 優化/新增功能點與原有產品如何接入

  - 新增功能與原有介面並不會產生衝突,可以考慮在側邊欄新增一個按鈕指向本功能,並在應用引導頁設定提醒,向用戶介紹本新增功能的入口

答辯總結

小組現場答辯得分:

  • 去掉一個最高分,去掉一個最低分,小組最終得分為78.5分
組號 組名 打分
1 爸爸餓了隊 77
2 拖鞋旅遊隊 77
3 彳艮彳亍隊 81
4 火箭少男100 74
5 起床一起肝活隊 80
6 404 Note Found隊 85
7 第三視角 74
8 小白吃 82

問題回答:

第二組的提問

  • 問題1:能否說明一下尋找以及測試BUG的所使用的時間?感覺你們找的BUG蠻不容易找的

  • 答:我們小組的測試人員使用了一個晚上——將近4個小時的時間完成找bug的任務

  • 問題2:能否提供使用頻率中餅圖的具體百分比?

  • 答: FN5FYEF$IBRL.png

  • 問題3:增量開發中是否真的能做到直接找到一間辦公室的地址然後進行導航?

  • 答:具體的地理資料需要根據我們對福大學生的問卷調查以及訪問福大各個機構官網查詢機構地址形成地理資料匯入到地圖中。

第三組的提問

  • 問題1:個人覺得地圖導航需求不高,我覺得比如說你要去哪個辦公室,他告訴你哪棟樓幾零幾來的實在。

  • 答:感謝建議,我們的原型設想是將地標顯示到地圖上,之後如果使用者點選該地標會有更詳細的地理位置資訊展現。

  • 問題2:請問你們調查專案需求的時候是調查了多少人呢?是以什麼樣的形式?

  • 答:我們主要針對大一新生髮布了一份問卷調查,共有100人回答了本問卷

  • 問題3:感覺增量開發設計這塊所給出的新功能只有一個,是否有更多的想發沒有分享?

  • 答:我們一開始的設想有3個新功能,分別是:課程表備忘功能、圖書館自習室預定功能整合以及福大地圖導航,最後我們小組認為福大地圖導航的剛需最強,且實現可能性大所以最後選擇了這個功能

第四組的提問

  • 問題1:為什麼ppt中只展示了兩個系統的各一個bug呢?

  • 答: 我們在專案評測報告中展示了小組成員測試到的其他bug,ppt中只展示了在我們看來最嚴重、最隱蔽的bug,一方面是為了壓縮演講內容,另一方面是其他bug相比起展示的bug節目效果較差

  • 問題2:能否在ppt中體現隊員分工呢?

  • 答: 我們會在之後的ppt中注意的

  • 問題3:測試報告中幾乎沒有一張圖片,會不會沒有信服力呢?

  • 答: 感謝您的建議,我們會在之後的報告中關注沒有圖片這個問題。

第五組的提問

  • 問題1:ppt中增量開發設計模組只有一個功能,是否沒有展示完全?

  • 答:我們一開始的設想有3個新功能,分別是:課程表備忘功能、圖書館自習室預定功能整合以及福大地圖導航,最後我們小組認為福大地圖導航的剛需最強,且實現可能性大所以最後選擇了這個功能

  • 問題2:ppt中的bug測試展示是否有點少了?bug測試大概花了多長時間?

  • 答:我們在專案評測報告中展示了小組成員測試到的其他bug,ppt中只展示了在我們看來最嚴重、最隱蔽的bug。我們安卓端與ios端的測試人員分別用了4個小時的時間進行bug測試,雖然bug數量少,但是我認為我們安卓端的bug是最隱蔽的

  • 問題3:請問接受調查的使用者的年級分佈是怎樣的?

  • 答:
    4B@A(Q6)Y8FHCK57WAAL5IM.png

第六組的提問

  • 問題1:1、增量功能的想法很好,但是具體怎麼實施?

  • 答:實現思路:接入百度地圖SDK,並根據我們對福大學生的問卷調查以及訪問福大各個機構官網查詢機構地址形成地理資料匯入到地圖中。

  • 問題2:2、你們的問卷調檢視起來效果不錯,能不能簡要敘述一下你們都有什麼問題?

  • 答:歡迎檢視我們的問卷調查

  • 問題3:3、有沒有考慮過從別的途徑進行測試,而不是人工測試?

  • 答: 感謝您的建議,我們也是聽了您組的報告才知道還有自動化測試應用的網站存在(孤陋寡聞了),如果有下次我們一定考慮自動化測試應用的方式與手工測試方式相結合。

第七組的提問

  • 問題1:針對調查問卷具有侷限性這個問題,你們打算怎麼改進?

  • 答:之後我們會考慮通過與其他方式相結合來進行調查,感謝您的建議

  • 問題2:建議你們注意一下《測試報告》中目錄的格式問題?

  • 答:謝謝您的提醒,我們在之後的報告中會更加註意格式問題

  • 問題3:ppt中新功能的需求,有一部分是希望可以新增其他功能,可以說明具體是新增哪些功能嗎?

  • 答:希望新增其他功能是某位受訪者在回答希望新增什麼功能時提出的回覆,我們只是真實的把他的回答展現在詞雲中。

第八組的提問

  • 問題1:ppt中的功能使用頻率的具體資料是怎麼得到的?

  • 答:我們通過向福大學生髮布問卷調查來獲得的資料

  • 問題2:ppt中的福大助手結構圖是否過於簡單?嘉錫講壇等功能就無法被易班、生活工具、教務工具的其中之一涵蓋

  • 答:為了ppt的顯示清晰我們在演講時的圖片是進行過簡化的,詳圖在上方作業要求部分已經體現

  • 問題3:增量開發設計中的福大地圖導航想法很妙,能否簡述一下技術實現步驟?

  • 答:實現思路:接入百度地圖SDK,並根據我們對福大學生的問卷調查以及訪問福大各個機構官網查詢機構地址形成地理資料匯入到地圖中。

小組本次作業貢獻分

組員 貢獻比例 完成任務
王彬 20 完成部落格撰寫、專案評測撰寫、完成作業建議與規劃部分
趙暢 10 演講PPT
王源 10 功能原型圖製作
志煒 10 完成專案分析部分
文垚 10 應用測試安卓端、報告表格編輯
恆達 10 應用測試IOS端
煌偉 10 使用者採訪
展瑞 10 問卷設計、釋出並回收
嶽昕 10 問卷設計、釋出並回收

個人部分

PSP

PSP2.1    Personal Software Process Stages   預估耗時(分鐘) 實際耗時(分鐘)
Planning  計劃 5 7
· Estimate    · 估計這個任務需要多少時間 5 7
Development 開發 20 27
· Analysis    · 需求分析 (包括學習新技術) 10 10
· Design Spec     · 生成設計文件 0 0
· Design Review   · 設計複審 0 0
· Coding Standard     · 程式碼規範 (為目前的開發制定合適的規範) 0 0
· Design     · 具體設計 10 17
· Coding   · 具體編碼 0 0
· Code Review     · 程式碼複審 0 0
· Test    · 測試(自我測試,修改程式碼,提交修改) 0 0
Reporting  報告 10 10
· Test Repor  · 測試報告 0 0
· Size Measurement    · 計算工作量 5 5
· Postmortem & Process Improvement Plan   · 事後總結, 並提出過程改進計劃 5 5
    合計 35 44

學習進度條

第N周 新增程式碼(行) 累計程式碼(行) 本週學習耗時(小時) 累計學習耗時(小時) 重要成長
1 278 278 6 6 複習了C++,學習了檔案讀入讀寫,字元操作
2 0 278 5 11 學習了Axure RP的使用,以及NABCD模型
3 113 391 15 26 複習了python爬蟲和java的爬蟲
4 200 591 13 39 學習了linux下的檔案操作和網路程式設計
5 213 804 10 49 學習了使用GTK編寫圖形介面
6 0 804 7 56 學習了processon的使用,UML圖的建立
7 140 944 16 72 學習了linux下多執行緒的程式設計,學習撰寫需求分析報告
8 60 1004 8 80 學習了laravel的開發環境搭建,編寫第一個php文件
9 300 1304 20 100 學習了laravel框架的基本開發流程,掌握了路由和HTTP協議等技能
9 220 1524 16 116 編寫了laravel的route介面,學會了postman測試
10 200 1724 8 124 學習了Webgl的3D漫遊技術
11 250 1974 12 136 學習了webgl的光照渲染和紋理對映,學習了java的詞法分析器