團隊項目測評博客

第一部分 調研,評測

評測

安卓端評測

  • 測試人:文垚php

  • 描述最簡單直觀的我的第一次上手體驗。前端

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

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

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

  • 用專業的語言描述bug(每一個bug 很多於 40字),並適當配圖.數據庫

  - 評議完成,但獲取成績數據失敗。具體表現爲使用易班版塊中的「一鍵XX」功能對老師進行評議,評議完成後仍然沒法查當作績,顯示獲取成績數據失敗。通過一段時間後再次查詢成績,成功。
      json

  • 評議完成

  • 獲取成績數據失敗

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

  • 你以爲爲何這個產品組的人沒有發現這些bug?

  - 我認爲產品組的人沒有發現這個bug的緣由多是產品研發完成後,測試組的成員對軟件進行的測試不夠全面,忽略了這些bug。緩存

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

  - 我認爲團隊須要注意到接入其餘學校資源的接口時要兼顧手機端和接口的兼容性服務器

IOS端評測

  • 測試人:恆達

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

  • 軟件打開後直接顯示課程表,這對常常須要查看課表的我來講是很是方便的,打開側邊欄後忽然注意到福大助手中還有這麼多功能我沒有使用過,我日常的使用中最常用的功能是查看課程表和查當作績,至於其餘功能卻不多用到過,感受應用能夠設立一個引導頁面來指導新用戶快速掌握應用的各個功能的位置

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

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

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

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

  - 成績功能模塊中的各個學年的各科成績對應的績點沒法統計出來,以後點擊刷新問題已經存在,徹底退出軟件從新打開軟件問題已經存在。

  • 你以爲爲何這個產品組的人沒有發現這些bug?

  - 我認爲這個問題產生的可能緣由在於:一、產品組沒有對該功能進行詳細的測試,致使前端與後端數據對接的時候績點這個字段的值讀取失敗 二、或者該接口自己就沒有傳遞這個數據產品組雖然知道問題存在不過也無能爲力

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

  - 我認爲團隊須要注意根據項目的後期維護,不斷保持產品各個功能的可用性

採訪

採訪一

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

  - 福大在讀大三學生,只用過教務通,需求:但願查看並下載課程的課件和歷年卷

  • 讓採訪對象使用福大助手(請上傳照片證實用戶的確正在使用,遠程採訪的同窗請讓別人幫忙照相)

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

  - 問題解決了,除了使用基本功能外用戶還下載了不少的課程學習資料。軟件的界面簡約,主題還可根據我的喜愛設置,功能完善,課程信息準確度極高。體驗方面沒有問題。

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

  - 用戶提出的改進意見是歷年卷資料不少過期,但願能及時更新。

  • 結論:

  - 很是推薦

  採訪二

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

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

  • 讓採訪對象使用福大助手(請上傳照片證實用戶的確正在使用,遠程採訪的同窗請讓別人幫忙照相)

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

  - 優勢:軟件界面精美,功能齊全,運行流暢,課程信息的準確度高,體驗方面沒有問題。

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

  - 成績查詢功能裏缺乏查看課程平均分和最高分的功能,以及缺乏績點排名的變化走勢圖,但願能添加該功能。

  • 結論:

   - 推薦

  採訪3、

  • 介紹採訪對象的背景和需求(他們有沒有用過相似的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:一、增量功能的想法很好,可是具體怎麼實施?

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

  • 問題2:二、大家的問卷調查看起來效果不錯,能不能簡要敘述一下大家都有什麼問題?

  • 答:歡迎查看咱們的問卷調查

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

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

第七組的提問

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

  • 答:以後咱們會考慮經過與其餘方式相結合來進行調查,感謝您的建議

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

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

  • 問題3:ppt中新功能的需求,有一部分是但願能夠添加其餘功能,能夠說明具體是添加哪些功能嗎?

  • 答:但願添加其餘功能是某位受訪者在回答但願添加什麼功能時提出的回覆,咱們只是真實的把他的回答展示在詞雲中。

第八組的提問

  • 問題1:ppt中的功能使用頻率的具體數據是怎麼獲得的?

  • 答:咱們經過向福大學生髮布問卷調查來得到的數據

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

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

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

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

小組本次做業貢獻分

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

我的部分

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

學習進度條

第N周 新增代碼(行) 累計代碼(行) 本週學習耗時(小時) 累計學習耗時(小時) 重要成長
1 312 312 6 6 學習vs中單元測試、性能分析的用法,複習文件使用
2 0 312 6 12 學習了NABCD模型,學習c多線程
3 0 312 5 17 學習使用UML圖
4 200 612 6 12 學習ECharts
5 0 612 12 28 學習類圖和ai的使用
6 120 732 10 38 學習laravel和php的使用
7 170 902 14 52 學習laravel
8 800 1702 35 87 學習postman 學習laravel數據庫及json相關
9 100 1802 38 90 學習註釋和數據聚類
10 30 1832 3 93 學習數據清洗
相關文章
相關標籤/搜索