404 Note Found隊 福大助手項目測評


目錄

組長博客鏈接

作業鏈接

第一部分 調研,評測

評測:

福大助手的bug

IOS端

  • 如果沒有對“福大助手”進行日歷的授權設置,那么“考場”中的“加入日歷”功能無法實現,點擊“加入日歷”提示“授權失敗”的窗口,但是沒有引導用戶進行授權的窗口;

  • “設置”中的“推送”功能沒有實現,點擊“推送”顯示頁面后無法操作,所有Switch按鈕無效,也無法回退到“設置”界面;

  • 一鍵評議”功能如果輸入錯誤的字符串會多次提示“發送未知錯誤,評議失敗,嘗試繼續評議”,然后app崩潰

  • “易班工具”中的“輔導員考核”功能,輸入“得分”欄的數據為字母或特殊字符(如@、&等)點擊“保存”后沒有提示“只能輸入數字”的窗口,而是直接顯示“輔導員考核詳情”頁面

Android端

  • 進入設置頁面,編輯側邊欄的時候,要是選擇不顯示現在所在的功能頁面,退出設置之后,還會存在取消的頁面,這個是邏輯上不符的。

  • “一鍵xx”功能,如果反復切換評議用途,切換過后的頁面刷新初始化十分緩慢,有時出現初始化的情況,“驗證碼”無論輸入的是什么,都能夠開始評議。

福大助手結構體系的思維導圖

  • 按照描述的bug定義,找出至少兩個功能性的比較嚴重的bug。用專業的語言描述bug(每個bug 不少於 40字),並適當配圖.

為什么開發人員沒有發現這個bug

  • 可能開發人員主要專注於軟件主要功能的實現上,測試的話也是會盡量按比較單一的角度測試,所以對於軟件的這些個bug就比較難測試出來。

假設團隊開發這款app,應注意哪些方面(架構、部署運維、微服務等)?

應注意采用微服務構架以及提高運維要求兩方面。

眾所周知,福大助手是由福大本校學生組成的西二在線所開發,隨着學生不斷的畢業以及新技術的不斷嘗試,團隊本身的人員組成以及項目使用的技術會以相當高的頻率迭代。同樣,作為福大本地化軟件,福大助手無疑會在將來不斷地進行優化。

對於這類快速更新迭代的團隊,隨着時間及項目規模的擴大,傳統的單體架構有着“復雜性逐漸變高”、“技術債務逐漸上升”、“部署速度逐漸變慢”、“阻礙技術創新”及“無法按需伸縮”的問題。
在此我們先引入微服務這一理念。

微服務,以單一職責、服務自治、輕量級通信及接口明確為設計原則的一種架構風格;而針對福大助手這一app,我們認為最應該注意的是項目應該采用微服務構架
為什么這樣說呢?我們看看微服務和傳統單體構架的區別:

  1. 單體架構所有的模塊全都耦合在一塊,代碼量大,維護困難;微服務每個模塊就相當於一個單獨的項目,代碼量明顯減少,遇到問題也相對來說比較好解決。

  2. 單體架構所有的模塊都共用一個數據庫,存儲方式比較單一,微服務每個模塊都可以使用不同的存儲方式(比如有的用redis,有的用mysql等),數據庫也是單個模塊對應自己的數據庫。

  3. 單體架構所有的模塊開發所使用的技術一樣,微服務每個模塊都可以使用不同的開發技術,開發模式更靈活。

很明顯 ,微服務架構其本質便是在結構上實現各個服務模塊的松耦合
就福大助手來說,微服務能為團隊帶來主要好處如下:

  1. 易於開發和維護:微服務單個模塊就相當於一個項目,開發時僅需觀察其單獨的邏輯,易於團隊開發和維護app功能。
  2. 能夠局部修改且容易部署:同樣,當某個模塊出現bug時,團隊能夠僅關注於完善出現bug的模塊,在解決后只需要單獨重啟這一模塊的服務即可,部署相對簡單。
  3. 技術棧不受限:由於微服務“單一職責”和“服務自治”的設計原則,技術人員在實現微服務模塊時僅需考慮模塊本身的業務邏輯,其實現技術本身並沒有限制,有利於項目長遠的技術創新,同樣方便新加入的團隊成員接手項目。
  4. 按需伸縮:類似與3中所述,開發時僅需關注模塊自身邏輯,進行性能擴展時不必考慮其它模塊的情況,團隊能夠及時根據需求對功能模塊進行調整優化。

然而,在微服務帶來種種好處的同時,它也有一些需要注意的不足

  1. 對團隊的運維提出了很高的要求:
    對於單體架構來講,我們只需要維護好這一個項目就可以了,但是對於微服務架構來講,由於項目是由多個微服務構成的,每個模塊出現問題都會造成整個項目運行出現異常,想要知道是哪個模塊造成的問題往往是不容易的,因為我們無法一步一步通過debug的方式來跟蹤,這就對運維人員提出了很高的要求。在團隊的實際資源分配中,勢必要比以往投入更多的資源在運維上
  2. 微服務是一個分布式系統
    對於單體架構來講,我們可以不使用分布式,但是對於微服務架構來說,分布式幾乎是必會用的技術,由於分布式本身的復雜性,導致微服務架構也變得復雜起來。

采訪

福大助手采訪:

采訪一

  • 介紹采訪對象的背景和需求
    使用過易班、福大教務通、超級課程表等相關軟件。除了現有功能沒有什么其他需求。
  • 讓采訪對象使用福大助手(請上傳照片證明用戶的確正在使用,遠程采訪的同學請讓別人幫忙照相)
  • 描述用戶使用這個產品的過程, 用戶的問題解決了么?軟件在數據量/界面/功能/准確度上各有什么優缺點?用戶體驗方面有問題么?
    這個軟件功能很強大,可以解決想要解決的問題。在數據方面,數據量大,可以查很多東西。界面很友好。准確度沒有什么問題。用戶體驗上,它的功能很復雜,在只想看課表的時候更傾向於教務通,因為它功能單一,看起來比較清晰簡單。福大助手平時反而不會用。
  • 用戶對產品有什么改進意見?
    這款軟件很強大,沒有意見。
  • 結論
    非常推薦

采訪二

  • 介紹采訪對象的背景和需求
    使用過易班、福大教務通、超級課程表等相關軟件。希望通過軟件方便自己學習和生活。
  • 讓采訪對象使用福大助手(請上傳照片證明用戶的確正在使用,遠程采訪的同學請讓別人幫忙照相)
  • 描述用戶使用這個產品的過程, 用戶的問題解決了么?軟件在數據量/界面/功能/准確度上各有什么優缺點?用戶體驗方面有問題么?
    這個軟件功能很強大,可以解決想要解決的問題。里面東西很多,被安利了。界面有更換主題功能,非常適合自己。功能上,還希望能增加交水電費和校園卡充值功能。准確度上和其他類似軟件沒有區別。
  • 用戶對產品有什么改進意見?
    增加交水電費和校園卡充值功能。
  • 結論
    推薦

采訪三

  • 介紹采訪對象的背景和需求
    使用過易班、福大教務通、超級課程表等相關軟件。希望只用一款app包括所有內容的軟件,不想自己的qpp太多。
  • 讓采訪對象使用福大助手(請上傳照片證明用戶的確正在使用,遠程采訪的同學請讓別人幫忙照相)
  • 描述用戶使用這個產品的過程, 用戶的問題解決了么?軟件在數據量/界面/功能/准確度上各有什么優缺點?用戶體驗方面有問題么?
    這個軟件功能很強大,可以解決想要解決的問題。數據量方面,里面包括了教務通和易班的大部分內容,界面方面,非常不友好,感覺不好看,iOS手機界面和android手機不同,課程表界面和側邊欄界面不好看。准確度方面,和另外兩款沒差。用戶體驗上,第一感覺界面不友好。
  • 用戶對產品有什么改進意見?
    將ios的界面設計得更友好。
  • 結論
    一般

第二部分 分析

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

  • 三個半月。
    主要分為萌芽,磨合,規范,創造四個階段。
    人員分工為項目負責人一人,前端兩人,后端兩人,算法一人,並有專業UI支持。

  • 一、萌芽時期花費半個月。
    (1)根據調查客戶需求進行需求創作,需求再改進,由項目負責人和開發共同確認需求可行。
    (2)然后UI設計和前端進行具體討論,給出一套完整的需求文檔,確定項目開發周期。
    (3)根據以上討論結果對整個項目進行一個總體的規划,進而確定項目的詳細功能和人員的具體分工。
  • 二、磨合時期花費兩個月。
    (1)原型設計階段花費十天左右,前期畫出產品的基本草圖頁面,其中包括:產品原型頁面交互/產品功能說明文檔,前端根據需求分析設計出一套大致的原型設計模型,后期UI設計給出具體建議,對原型進行具體改進,得出一個理想實現界面,並給出產品結構圖、模塊功能梳理清單。
    (2)開發設計階段需要一個多月,這階段主要是前后端開發設計以及前后端交接,實現產品的具體功能,這個階段應該注意的一點是比如注冊域名、買服務器、備案、蘋果開發者賬號、安卓開發者賬號、短信服務等等。在確定開發后就可以准備這些東西了。不然中途會影響開發工期,影響上線時間。
    (3)磨合后期進行初步驗收測試,兼容性調試開發。並及時解決此產品不兼容問題,bug問題和閃退問題。
  • 三、規范時期花費半個月。
    在磨合期已經得出項目的胚型,規范時期就是對項目進行優化改進,對產品進行調整和增刪。
    (1)前端進行版塊細化,界面調整和功能增刪。
    (2)后端則及時給出接口,與前端進行對接。
    (3)UI設計則注重界面美化,使用戶得到一個簡潔美觀的觀賞頁面。
    (4)階段后期進行項目總測試,對項目完整的進行一個驗收測試,並給出US流程圖。
  • 四、創新階段花費半個月。
    (1)app可小范圍的進行發布使用,投入線下運營。
    (2)及時得到用戶反饋,進行項目改進優化,最終得出一個簡潔實用的app。

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

  • 優點:
    (1)側邊欄設置簡潔,易於觀看搜索。
    (2)課程表導出到日歷,提醒成績正在更新。
    (3)相比福大教務處和福大易班,閃退和卡頓更少,用戶體驗更佳。
    (4)一鍵評議。可對老師評價進行一鍵評議,節省時間精力,使用方便快捷。
    (5)功能齊全,相比教務處,福大助手在功能設置這方面絲毫不遜色,而且更勝一籌,包含功能都是學生經常使用的功能,以學生為出發點,更能理解學生需求。
  • 缺點:
    (1)成績查看功能部分無成績變化圖,不可觀察成績波動。
    (2)宣傳力度不夠,APP宣傳大多是通過同學間口口相傳,沒有最大程度的開發潛在用戶,宣傳渠道匱乏,進而使產品得不到最大化的使用,也因此得不到更多反饋建議,從而進行項目優化,拉低了app的整體使用效果。
    (3)界面簡潔美觀,但過於單一,缺少創意,主題設置方面無自定義壁紙選項,不具備在線圖庫選擇功能。

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

重要度為藍色框,完成度為橘色框

針對不同的維度評分,對用戶體驗方面、Ul界面美觀度、核心功能,分別打分。

第三部分 建議和規划

參考《構建之法》第8章 功能的定位和優先級;第9章 項目經理

這個軟件有很多可以提高的部分。

如果你是項目經理,如何提高從而在競爭中勝出?

  • 在擁有競爭對手殺手功能的同時,開發出競爭對手不具有的功能。只有不斷創新,才能立於不敗之地。
  • 優化外圍功能,盡可能提升用戶使用感受,擴大固定用戶群體。
  • 現有的軟件盡管有很多可以提高的部分,但是確實已經做得不錯了,不少同學沒有使用是因為不知道有這個軟件。福大助手功能眾多,甚至擁有福大教務處、福大易班、期末考啦這三個app所謂的殺手功能。所以應該加大宣傳力度,讓更多的同學嘗試使用。

目前市面上有什么樣的產品了?

  • 福大教務處
    福州大學教務處官方推出的一款集課表,成績查詢,學業分析,學期選課,空教室查詢等多個功能於一體的教務app。
  • 福大易班
    集福州大學學生工作、學習、生活方面為一體的校園服務辦理app。(基本上集齊了學校大部分個人日常需要申請辦理的事務,但部分功能能否使用/使用感受大家都懂)
  • 期末考啦
    面向福州大學的學生學習資料分享軟件。
  • 超級課程表
    以課程表為基礎展開的校園實用工具。部分福大學生會使用這個app查看課表。

你要設計什么樣的功能?

優化部分:

  • 課程查詢
    提供查詢其他專業開課情況的功能,用戶在查詢到感興趣的課程的情況下可以使用課程表內現有的添加課程功能將課程添加到課程表。
  • 課程導出到日歷提示
    點擊導出到日歷功能后出現彈窗顯示:在設置-清除數據里可撤銷導出操作。
  • 學業分析(ios版本有,Android版本沒有)
    提供可視化的績點排名變化、修習學分統計、修習情況的分析。
  • 校歷查看(ios版本有,Android版本沒有)
    查看活動安排、假期安排等情況。

創新部分:

  • 同學幫
    實名制的同學互動平台。分成學習、生活兩部分。學習部分主要用來發布一些面向用戶的個人學習信息。用戶可以在這個板塊發布找研友、有償考研信息分享交流、有償期末答疑解惑等消息。生活部分主要用來發布一些生活上的便利互助信息,如打車拼單、閑置物品轉讓出售等。
  • 在線簽到點名
    最小以班級為單位在該板塊上發布簽到活動,用戶在指定地點附近輸入特定信息可進行簽到簽退點名。
  • 教師信息查詢
    提供教師的個人資料,授課情況,掛科率高分率、學生評價。

為什么要做這個功能,而不是其他功能?

  • 同學幫
    我們為福大助手設計了一個板塊用於學生間的交流。目前學校資源的分享或出售往往是通過qq群聊,效率低且充滿了不確定性。但由於而福大助手實名制的平台提升了學生間交流的效率。該功能的實現需要投入一定成本的開發,但是我們認為這個功能是有用戶群體且有是回報的。用戶群體形成,社區化的平台可以用來投放考研信息、餐飲宣傳等廣告,廣告集成在這個板塊不會影響福大助手其他功能的使用。
  • 課程查詢
    大學課堂一個很重要的特點就是可以任意蹭到想上的課。提供校內課程查詢的功能可以使用戶方便地查獲想上的課的時間地點並添加到課程表。這個功能提升了用戶使用感受且實現成本不大。
  • 導出到日歷提示
    很多人點擊課程導出到日歷功能往往只是為了測試這個功能的實現效果如何,但是導出到日歷這個功能實際效果並不是很好(如圖,不僅不能使課程全部清晰地展示在日歷上而且會影響日歷的觀感,甚至可能導致一些重要事件被蓋住)。而且撤銷這個操作的行為按鍵過於隱,用戶不易找到。
    但不可否認確實有部分用戶會使用課程導出到日歷這個功能,因此我們做出的優化手段是在后出現彈窗顯示:在設置-清除數據里可撤銷導出操作。
  • 學業分析、教師信息查詢、在線點名簽到、校歷查看
    學業分析,福大助手不具備的福大教務處的功能兩個功能之一,比起可有可無的培養計划,學業分析有一定用戶需求。
    教師信息查詢,受西二在線公眾號這個功能的啟發,學生在選課時面對不熟悉的老師能從這里找到一點信息幫助選課,用戶需求較大。
    在線點名簽到,受到小小簽到啟發,大學生需要簽到簽退的場合很多,用戶需求大。比起手動簽名,電子簽到的形式更有效率且適合集成到福大助手這個平台。
    校歷查看,提供可視化的學校時間安排,實現成本低,需求大。

總結:福大助手側邊欄支持自定義,理論上只要是有用的功能都能加上去,且不影響用戶使用。考慮到實現成本與收益的問題我們為福大助手增加了以上優化和新增功能點。

為什么用戶會用你的產品/功能?

在為什么要做這個功能,而不是其他功能?這個問題里已經有體現。

你的創新在哪里?可用nabcd分析。

我們對福大助手app改進的主要創新點在同學幫這個模塊。

  • N(Need,需求)
    現階段大學校園內資料分享、物品交易等活動十分豐富,但是此類活動溝通的平台往往是在qq、微信群聊中,充滿了不確定性且交易的效率低下。
  • A(Approach,做法)
    我們為福大助手app設計了“同學幫”這個模塊用於同學間的交流。福州大學的學生可在此平台上分享或出售考研資料,尋找研友,交易閑置物品,發布拼單信息等。
  • B(Benefit,好處)
    福大助手實名制的特點使溝通變得透明安全且更有效率。因此這個功能預計可以帶來可觀用戶群體。
  • C(Competitors,競爭)
    目前基於福大其他校內的服務軟件均未提供這個功能。福大助手ios版本推出的“二手市場”模塊和超級課程表推出的溝通功能“下課聊”是匿名制,用戶群體小且與我們基於實名制的創新點沒有沖突。
  • D(Delivery,推廣)
    在物品交易、考研分享群里宣傳,讓更多潛在用戶體驗該功能。累積一定用戶群體后,我們可以在社區化的模塊里的廣告版面投入諸如考研信息等廣告進行盈利。

如果你來領導團隊,會有什么不一樣?

一個產品從想法的萌芽到最后的交付給用戶使用,甚至上架銷售,私以為包括了五個部分:需求分析,沖刺安排,沖刺,測試和迭代,上架宣傳。《構建之法》的第185頁談到:“PM做開發和測試之外的所有事情”,所以一個優秀的PM是不會參與或者盡可能少的參與軟件的開發的。所以來說,如果我來領導團隊,中間的三部分是不會發生變化的,所以我這里主要說明對於需求分析和上架宣傳的看法。對於需求分析部分,《構建之法》的第八章,功能的定位和優先級中進行了詳細的說明。我們可以通過《構建之法》提出的使用四個象限來描述“福大助手”的功能分析:

殺手功能這一列是穩定的加分項,這里我們按下不表。來看外圍功能這一列功能,該列描述了一些殺手功能以外的或關鍵或不關鍵的功能。在很久之前,我就聽到同學們說過“福大助手”的“一鍵評議”功能蘋果可以用,安卓不可以用,這導致我很晚才下載它,甚至在前兩天還有同學和我說“福大助手對蘋果十分友好,但在安卓端感覺可有可無”,我+1。
除了這個方法,《構建之法》上還提出的另一種方法,將軟件的功能分為驚喜核心功能基本功能或屬性。“福大助手”的驚喜包括了:一鍵評議,課程表導出到日歷,提醒成績正在更新,主題設置和自定義側邊欄等等的功能,核心功能是課程表和成績查詢,基本功能可以不談。這樣看來“福大助手”還是不錯的。
再來看“福大助手”的宣傳方面,這款APP我是在第一學期期末要看成績時從舍友口中聽到的,單單從這一點就能體現出很多問題:1.“福大助手”是通過同學之間好的評價來進行宣傳的,2.這個學期前面的時間我沒用過福大助手,之前一直使用教務通,3.當我聽到他很方便時,安卓端卻不能使用“一鍵評議”(大一時,現在可以用了)。這三點體現出了,宣傳渠道匱乏前期流失了大量的用戶,即使能100%地保留下ios端的用戶,安卓用戶少之又少也是個問題,畢竟你不能忽略安卓系統龐大的使用群體。
總結一下,“福大助手”優秀的地方很優秀,但是很多功能安卓端的不適用后期宣傳力度不大給了它致命一擊。如果我來做PM,我會注意這兩個方面,在研發的安排階段將核心功能的各個移動端適用這一重要的地方強調一下,並且在后期宣傳時加大力度,這一點抽屜就做得很好,可以向他學習一下。
最后偷偷說一句,我比較喜歡很多人一起吃飯,如果我做了PM,估計會經常和團隊一起出來吃飯,交流感情。

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

需求分析和軟件開發准備階段大家要一起參與進來,盡快完成自己的任務,提前研發開始的時間。
研發階段,1個人負責Android前端,1個人負責Android后端,1個人負責ios前端,1個人負責ios后端,1個人負責美工。
后期測試階段,Android端可以和ios端互換軟件進行測試工作。
宣傳階段大家也是要一起參與,我認為這部分工作大家都是一樣的所以大家要一起來做。

描述你的團隊在16個周期間每周都要做什么,才能在第16周如期發布軟件,大小里程碑績點設定。

假設我的團隊都具有一定的開發基礎開發經驗,那么我會這么安排我的團隊:

項目發布后,有沒有考慮過項目該怎么部署才能滿足需求。依據附錄圖(某校教務處系統的部署)作為參考,分析16周后你所完成的項目上線需要哪些配套設備(服務器、帶寬、數據庫需求數量與配置) 。

基本的服務器框架都是C/S結構的,請求和相應流程是這樣的:

現通過增設以下設備以達到優化功能:

  • 中間層DLA
    DLA采用緩沖隊列和連接池設計。 客戶端大並發請求到來時,DAL設計緩沖隊列,存儲等待的請求,並且DAL中設計數據庫連接池,當數據庫連接池中有空閑連接,那么從緩沖隊列中取出一個請求處理,以此類推。這種做法有效的降低了服務器的壓力,保證請求被緩存。
  • 緩存數據庫
    將常用的數據加載入緩存,
    有請求到來時,應用服務器先從緩存中獲取數據,如果緩存中有數據,那么不需要訪問數據庫,如果緩存中沒有,在訪問數據庫取出數據,並更新緩存。如此一來處理效率不受限於數據庫的並發數。增設的備份redis數據庫則能夠實現數據的備份和持久化。
  • 在單獨應用服務器上部署緩存服務器
    將緩存部署在單獨服務器上,通過訪問該緩存服務器,方便各個應用服務器訪問彼此緩存
  • 將關系型數據庫實現讀寫分離負載均衡
    當有大量復雜的寫操作數據庫時,讀寫分離可以保證讀數據庫操作不被阻塞;由於數據庫讀操作會比寫操作多,那么可以對數據庫執行負載均衡。主流數據庫都有replication機制,采用replication機制可以實現負載均衡。中間層的寫數據庫操作投遞到主數據庫中,讀操作從讀數據庫中讀取,當主數據庫中數據被修改后,數據庫采用replication機制將數據同步給備份服務器。
  • 任務服務器
    單獨設計一個任務服務器,讓應用服務器主動去請求任務服務器,主動獲取任務處理,如果應用服務器處於忙碌狀態就不需要請求新的任務,空閑的應用服務器會去請求任務服務器中的任務,這是最合理的負載均衡。如果所有應用服務器都處於忙碌狀態,
    那么任務服務器將任務緩存至自己的任務隊列,當應用服務器空閑時會來取任務。這樣便對應用服務器實現了負載均衡
  • 備用任務服務器
    設置多台任務服務器,並且實現failover機制,多台任務服務器之間實現心跳,如果檢測不到對方心跳,則使自己成為主任務服務器,防止任務服務器出現故障

優化后框架圖如下:

最終設備如下:

帶寬計算方法是這樣的:
每秒鍾下載文件的字節數×8/0.7 = 寬帶的速率
流量和帶寬的換算是,帶寬:流量=1:150
假設2400人同時在線,2400人並發同時操作,每個人的要恢復30KB的備忘錄數據,那么合算成帶寬就是:2400/(30KB*8)=10Mb

因為預計在線人數較多以及雲備份的使用頻率頻繁,所以選擇4核8G服務器。

第四部分 增量開發設計

既然你對產品有這么多的意見和建議,請就你認為產品的可提升功能、新增需求點做出增量開發設計,要求:

優化/新增功能點的原型界面

  • 在福州助手中,對課表功能進行修改;新增功能同學幫、在線簽到、教師信息查詢
  • 在課表功能中,在我的課表底下,有查詢其他專業課表的功能,以及直觀的將課表加入日歷提醒的功能塊;在其他專業課程下,用戶可以點擊課程查看課程詳細信息,並可以添加至自己的課表

  • 在同學幫中,有四個模塊,分別是考研交流、答疑解惑、打車拼單,以及物品轉讓。個模塊以論壇的形式相互獨立,用戶可以以實名制的形式自由發帖、留言,以達到交換信息的作用
  • 在教室查詢模塊中,可以查詢在籍老師的信息,包括:姓名、學位、郵箱、教學特色、教學歷程、以及掛科率、高分率、點名率。
    在教室信息的下方,可以實名制對老師進行評論、並可以查看其他人對該老師的評論。

基本實現思路

  • 課程查詢、導出到日歷提示、學業分析、教師信息查詢、校歷查看等功能在可在原有功能基礎上進行開發和優化。數據來自該軟件原有數據庫。
    教師信息查詢功能,由於西二在線公眾號之前有提供過這個功能,福大助手這個app也是由西二在線進行開發的,只需要把數據合並到福大助手上即可。
  • 在線點名簽到功能需要調用用戶的地點上傳服務器進行簽到簽退。
  • 同學幫功能開發難度較大,相較於福大助手之前的功能來說,服務器負載增加,可能需要調用已有的聊天api進行開發。

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

  • 課程查詢、導出到日歷提示、學業分析、教師信息查詢、教師信息查詢功能、在線點名簽到功能等功能在可在短時間內完成,則在新版本發布時就可進行更新。
  • 同學幫功能需要一定時間的開發,可單獨更新發布。

第五部分 答辯總結

貢獻度及分工

姓名 比例
家偉 11%
卉卉 10%
宇恆 10%
政演 9.5%
丹丹 9%
鴻傑 8%
一好 7%
愷琳 6.5%
青元 9%
家燦 9.5%
緒佩 10.5%

問題回答

第一組

Q1:演講缺乏對專業測評工具的介紹,可以介紹一下你們所使用的應用在線測評工具嗎?
答:感謝提問!我們使用的測評工具是Testin雲測試。Testin雲測試是一個真機自動化雲測試服務平台,可實現自定義終端進行批量自動化兼容適配測試以及功能、性能、穩定性測試。我們在平台上傳了福大助手的apk文件獲得了測試報告數據。

Q2:項目測評是否有發布問卷調查,對應用進行一個大基數的調查?

答:感謝提問!我們沒有采取發布問卷調查的形式。我們認為問卷調查的形式對我們的評測幫助並不大,一是沒想到什么有針對性的問題,二是對一個軟件的評測和分析是需要對軟件細致地測試得出的,大多數同學不會通過日常的操作找到什么我們測試人員沒有發現的bug,三是我們通過線下了解,同學們的需求比較單一,對福大助手現有的功能都比較滿意,提出的如校園卡充值等需求對非技術性的要求較高,不在我們考慮的增量開發范圍內。當然,以上僅代表我們組的觀點。貴組的問卷調查分析結果是一個亮點,說明貴組的問卷問題和結果分析做的很好,我們會多多學習。

Q3:項目的增量開發難度如何,以小組實力需要多久的開發時間?
答:感謝提問!增量開發的主要功能同學幫涉及到實時交互的功能,難度較高,以小組實力初步估計要兩個月左右的時間。

第二組
Q1:是否也有使用問卷調查的形式呢?
答:感謝提問!我們組這次的測試報告中沒有考慮到使用問卷調查的形式,因為感覺大家都是輕使用這款App只會使用一些基礎的功能,所以不必采用問卷調查的形式。當然,如果測試報告的形式更有利於我們進行測試的話,我們之后會考慮采用這種方式來進行測試工作。

Q2:假如由貴小組來開發該軟件,覺得需要多久呢?
答:感謝提問!由我們組來進行開發的話,由於大家都是在校大學生,且經驗不甚豐富,所以我認為助教學姐給出的四個月是個不錯的建議。

Q3:具體的評測方法是什么?
答:感謝提問!我們組的測試同學使用的是名為“testin”的網站,該網站只用上傳APK文件,就會給出關於該軟件的測試報告,若有興趣,歡迎討論!

第三組
Q1:在測試的過程中並未提及對應的軟件產品的版本號,這就使得bug沒有針對性,有些或許並不是所有用戶目前所使用的版本都潛在的問題,存在指向不明的情況
答:感謝提問!我們確實沒有填,下次注意。但bug是只要一個設備存在,就需要去修改。

Q2:雖然有着詳細的測試數據,但並沒有給出一定的解釋性說明,這造成雖然堆有大量數據但大眾很難去理解其所代表的含義,可以掛出你們對於數據的解讀嗎?
答:感謝提問!其實數據解讀我們在測試文檔里面有給出來,如果你們還是覺得不是很能理解,可以看我們的詳細excel文檔

3:指出的分析大都和數據的安全性相關,能否就你們所目前所指出的安全性給福大助手app提出具體的一攬子解決方案呢?
答:感謝提問!我們也很想提供一攬子解決方案,但確實做不到。

第四組
Q1:測試報告及ppt中均有錯別字,為什么沒有認真審核呢?
答:感謝提問!對於PPT數字“5”和“五”不統一的問題深感抱歉,由於疏忽影響觀看美感。我們下次會注意的。對於測試報告中存在錯別字我們團隊沒有發現,希望可以更明確的指出錯誤之處方便我們做出修改。

Q2:測試報告沒有上傳pdf文件,下次能否考慮上傳pdf文件呢?畢竟pdf文件不會因為打開軟件的不同呈現不同。
答:感謝提問!對於我們沒有上傳pdf文件給你們帶來的不便表示抱歉,我們下次會盡量考慮到大家閱讀的友好型做出改進。但是這次作業中也沒有明確要求為pdf文件,所以還請諒解。

3:用戶采訪僅放了三張圖,是否不夠有說服力呢?畢竟圖中部分同學神似團隊成員呢?
答:感謝提問!我們的采訪是線下面對面采訪,雖只放置三張圖片但並非代表只采訪了三個對象。這在PPT演示過程中已有陳述是抽取三個代表性對象進行展示。而相較於您方放置的一個線下采訪短視頻是否我們就可以等價的認為您方說服力也不夠強呢?對於“圖中神似團隊成員”的問題,我們團隊中就有一半的成員在之前為使用過福大助手。首先,對象已經是屬於我們的采訪對象范圍;其次,我們圖中確實存在一位團隊成員,但她便是我們挑選出來的代表性對象,我們認為這並沒有什么不妥。最后,如果您方認為說服力不夠,我們很樂意看到您方所謂比較有說服力的采訪數據和證據。

第五組
Q1:測評可以加入問卷調查的,了解下大家對這個軟件的認識,因為我發現其實還是很多人不知道的。
答:感謝提問!這是一個很棒的建議!之后我們會多考慮問卷的。

Q2:其實我覺得福大助手在響應時間方面並不是很好,很多東西都半天出不來,也不知道是不是手機問題。
答:感謝提問!其實我們團隊也有類似的感覺,不過似乎易班及福大教務通等一眾教務類軟件都具有這些毛病,或許和服務器也有一定關系。

Q3:PPT一共有四頁給福大助手來了一腳,雖然這APP確實很多地方有問題,但還是別踢了,都腫了。(滑稽)
答:感謝提問!柯大魔王要求如此,一人一腳也是無奈之舉。(莫非柯老板是西二在線幕后股東?)

第七組
1:你們的測試看起來非常有料,可以具體分享一下是怎么測試的嘛?
答:感謝提問!測試的過程雖然是我們組的核心機密,但是看在我們小組之間的關系非常不錯。我們做的測試主要是黑盒測試,除此之外我們還使用了testin,上傳apk文件,他們提供了很多款機型做測試,同時也給出測試的方式,性能測試、安全測試和兼容性測試等。不過一個賬戶只能免費使用一次軟件測試。

Q2:你們的增量開發中有“同學幫”,可以具體的介紹一下同學幫是干什么的嘛?可以實現什么?
答:感謝提問!同學幫的功能:實名制的同學互動平台。分成學習、生活兩部分。學習部分主要用來發布一些面向用戶的個人學習信息。用戶可以在這個板塊發布找研友、有償考研信息分享交流、有償期末答疑解惑等消息。生活部分主要用來發布一些生活上的便利互助信息,如打車拼單、閑置物品轉讓出售等。我們覺得這個功能能夠提供一個很好的校內交流氛圍。

Q3:你們認為增量開發難度如何?
答:感謝提問!增量開發的難度視內容而定吧,要是您們指的是“同學幫”功能的話,開發上我覺得是有一定的難度,畢竟功能比較繁雜,不過物品轉讓在ios上已經有做嘗試;對於學習部分,開發難度上類似於一個在線聊天系統,難度應該也不大。

第八組
Q1:對於增量設計中的在線點名功能認為是否有必要加這個?是不是加劇代簽之類的情況?
答:感謝提問!本組覺得在線點名功能是可以擴展的功能,至於是否會加劇代簽之類的情況,本組覺得教務處賬號涉及個人隱私太多,大部分同學可能都不願意為了簽到借給他人。

Q2:可以抽取一部分的思維導圖或者邏輯框圖展示在ppt中,ppt中好像沒有體現。
答:感謝提問!本組認為把思維導圖或者邏輯框圖放在ppt中沒有很大的意義,因為這些圖如果放在ppt中很難讓同學們看清。

Q3:產品分析感覺這部分內容有點少了。
答:感謝提問!下次會在這方面有所改進。

評分結果

組號 其他組對本組的評分 本組對其他組的評分
1 78 80
2 81 76
3 77 71
4 76 69
5 86 78
6 85 85
7 82 71
8 84 80
平均 81

評審表

第六部分 個人部分

個人PSP

PSP2.1 header 2 預估耗時(分鍾) 實際耗時(分鍾)
Planning 計划 50 30
· Estimate ·估計這個任務需要多少時間 20 30
Development 開發 150 120
· Analysis 需求分析(包括學習新技術) 60 60
· Design Spec · 生成設計文檔 0 0
· Design Review · 設計復審 0 0
· Coding Standard · 代碼規范 (為目前的開發制定合適的規范) 0 0
· Design · 具體設計 80 50
· Coding · 具體編碼 10 20
· Code Review · 代碼復審 0 0
· Test ·測試(自我測試,修改代碼,提交修改) 0 0
Reporting 報告 10 10
· Test Repor · 測試報告 0 0
· Size Measurement · 計算工作量 0 0
· Postmortem & Process Improvement Plan · 事后總結, 並提出過程改進計划 20 20
合計 300 350

個人學習進度條

第N周 新增代碼(行) 累計代碼(行) 本周學習耗時(小時) 累計學習耗時(小時) 重要成長
1 0 0 5 5 閱讀《構建之法》,重點了解了 NABCD 模型
2 0 0 10 15 找到了適合團隊的原型工具,以及如何並行操作
3 68 68 6 6 python字符處理復習、爬蟲學習
4 78 146 7 13 java爬蟲學習
5 194 340 6 19 單元測試設計
6 0 340 10 29 需求報告撰寫
7 0 340 5 34 Alpha博客撰寫
7 0 340 3 37 Alpha2博客審查
7 0 340 3 40 Alpha3博客審查
7 0 340 2 42 Alpha4博客撰寫
7 50 390 10 52 構思了隨機算法、附加功能算法和具體思路,完成撰寫敘述
7 0 340 2 54 Alpha5博客撰寫
8 0 340 2 56 Alpha6博客撰寫
8 0 340 2 58 Alpha7博客撰寫
8 0 340 2 60 Alpha8博客撰寫
8 0 340 2 62 Alpha9博客撰寫
8 0 340 2 64 Alpha10博客撰寫
9 0 700 4 68 測試文檔撰寫
9 0 700 2 70 Beta1博客撰寫

測試報告

測試文檔

測試ppt

評審表


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com