項目測評

組長部落格連結

作業連結

目錄

• 第一部分 調研，評測
  • 福大助手的bug
    • IOS端
    • Android端
  • 福大助手結構體系的思維導圖
  • 為什麼開發人員沒有發現這個bug
  • 假設團隊開發這款app,應注意哪些方面（架構、部署運維、微服務等）？
  • 采訪
  • 福大助手采訪：
• 第二部分 分析
  • 估計這個項目做到這個程度大約需要多少時間(團隊人數6人左右，計算機大學畢業生，并有專業UI支援)
  • 分析這個軟體目前的優劣(和類似軟體相比)，并推理出開發團隊在軟體工程方面可以提高的一個重要部分(具體建議)
  • 根據了解和體驗，畫出整個軟體所有功能邏輯框圖，根據重要度辨別出各子產品的重要度、完成度、出發點及效果;
  • 針對不同的次元評分，對使用者體驗方面、Ul界面美觀度、核心功能，分别打分。
• 第三部分 建議和規劃
  • 如果你是項目經理，如何提高進而在競争中勝出？
  • 目前市面上有什麼樣的産品了？
  • 你要設計什麼樣的功能？
  • 為什麼要做這個功能，而不是其他功能？
  • 為什麼使用者會用你的産品/功能？
  • 你的創新在哪裡？可用nabcd分析。
  • 如果你來上司團隊，會有什麼不一樣？
  • 如果你的團隊隻有5個人，4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？
  • 描述你的團隊在16個周期間每周都要做什麼，才能在第16周如期釋出軟體，大小裡程碑績點設定。
  • 項目釋出後，有沒有考慮過項目該怎麼部署才能滿足需求。依據附錄圖（某校教務處系統的部署）作為參考，分析16周後你所完成的項目上線需要哪些配套裝置(伺服器、帶寬、資料庫需求數量與配置) 。
• 第四部分 增量開發設計
  • 優化/新增功能點的原型界面
  • 基本實作思路
  • 優化/新增功能點與原有産品如何接入
• 第五部分 答辯總結
  • 貢獻度及分工
  • 問題回答
  • 評分結果
• 第六部分 個人部分
  • 個人PSP
  • 個人學習進度條
• 測試報告

評測：

• 如果沒有對“福大助手”進行月曆的授權設定，那麼“考場”中的“加入月曆”功能無法實作，點選“加入月曆”提示“授權失敗”的視窗，但是沒有引導使用者進行授權的視窗；

• “設定”中的“推送”功能沒有實作，點選“推送”顯示頁面後無法操作，所有Switch按鈕無效，也無法回退到“設定”界面；

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

• “易班工具”中的“輔導員考核”功能，輸入“得分”欄的資料為字母或特殊字元（如@、&等）點選“儲存”後沒有提示“隻能輸入數字”的視窗，而是直接顯示“輔導員考核詳情”頁面

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

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

• 按照描述的bug定義，找出至少兩個功能性的比較嚴重的bug。用專業的語言描述bug（每個bug 不少于 40字），并适當配圖.

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

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

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

對于這類快速更新疊代的團隊，随着時間及項目規模的擴大，傳統的單體架構有着“複雜性逐漸變高”、“技術債務逐漸上升”、“部署速度逐漸變慢”、“阻礙技術創新”及“無法按需伸縮”的問題。

在此我們先引入微服務這一理念。

微服務，以單一職責、服務自治、輕量級通信及接口明确為設計原則的一種架構風格；而針對福大助手這一app，我們認為最應該注意的是項目應該采用微服務構架。

為什麼這樣說呢？我們看看微服務和傳統單體構架的差別：

1. 單體架構所有的子產品全都耦合在一塊，代碼量大，維護困難；微服務每個子產品就相當于一個單獨的項目，代碼量明顯減少，遇到問題也相對來說比較好解決。
2. 單體架構所有的子產品都共用一個資料庫，存儲方式比較單一，微服務每個子產品都可以使用不同的存儲方式（比如有的用redis，有的用mysql等），資料庫也是單個子產品對應自己的資料庫。
3. 單體架構所有的子產品開發所使用的技術一樣，微服務每個子產品都可以使用不同的開發技術，開發模式更靈活。

很明顯 ，微服務架構其本質便是在結構上實作各個服務子產品的松耦合。

就福大助手來說，微服務能為團隊帶來主要好處如下：

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

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

1. 對團隊的運維提出了很高的要求：

   對于單體架構來講，我們隻需要維護好這一個項目就可以了，但是對于微服務架構來講，由于項目是由多個微服務構成的，每個子產品出現問題都會造成整個項目運作出現異常，想要知道是哪個子產品造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。在團隊的實際資源配置設定中，勢必要比以往投入更多的資源在運維上。

2. 微服務是一個分布式系統

   對于單體架構來講，我們可以不使用分布式，但是對于微服務架構來說，分布式幾乎是必會用的技術，由于分布式本身的複雜性，導緻微服務架構也變得複雜起來。

采訪一

• 介紹采訪對象的背景和需求

  使用過易班、福大教務通、超級課程表等相關軟體。除了現有功能沒有什麼其他需求。

• 讓采訪對象使用福大助手（請上傳照片證明使用者的确正在使用，遠端采訪的同學請讓别人幫忙照相）

  

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

  這個軟體功能很強大，可以解決想要解決的問題。在資料方面，資料量大，可以查很多東西。界面很友好。準确度沒有什麼問題。使用者體驗上，它的功能很複雜，在隻想看課表的時候更傾向于教務通，因為它功能單一，看起來比較清晰簡單。福大助手平時反而不會用。

• 使用者對産品有什麼改進意見？

  這款軟體很強大，沒有意見。

• 結論

  非常推薦

采訪二：

• 使用過易班、福大教務通、超級課程表等相關軟體。希望通過軟體友善自己學習和生活。

• 

• 這個軟體功能很強大，可以解決想要解決的問題。裡面東西很多，被安利了。界面有更換主題功能，非常适合自己。功能上，還希望能增加交水電費和校園卡充值功能。準确度上和其他類似軟體沒有差別。
• 增加交水電費和校園卡充值功能。
• 推薦

采訪三：

• 使用過易班、福大教務通、超級課程表等相關軟體。希望隻用一款app包括所有内容的軟體，不想自己的qpp太多。

• 

• 這個軟體功能很強大，可以解決想要解決的問題。資料量方面，裡面包括了教務通和易班的大部分内容，界面方面，非常不友好，感覺不好看，iOS手機界面和android手機不同，課程表界面和側邊欄界面不好看。準确度方面，和另外兩款沒差。使用者體驗上，第一感覺界面不友好。
• 将ios的界面設計得更友好。
• 一般

• 三個半月。

  主要分為萌芽，磨合，規範，創造四個階段。

  人員分工為項目負責人一人，前端兩人，後端兩人，算法一人，并有專業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）界面簡潔美觀，但過于單一，缺少創意，主題設定方面無自定義桌面選項，不具備線上圖庫選擇功能。

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

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

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

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

• 福大教務處

  福州大學教務處官方推出的一款集課表，成績查詢，學業分析，學期選課，空教室查詢等多個功能于一體的教務app。

• 福大易班

  集福州大學學生工作、學習、生活方面為一體的校園服務辦理app。（基本上集齊了學校大部分個人日常需要申請辦理的事務，但部分功能能否使用/使用感受大家都懂）

• 期末考啦

  面向福州大學的學生學習資料分享軟體。

• 超級課程表

  以課程表為基礎展開的校園實用工具。部分福大學生會使用這個app檢視課表。

優化部分：

• 課程查詢

  提供查詢其他專業開課情況的功能，使用者在查詢到感興趣的課程的情況下可以使用課程表内現有的添加課程功能将課程添加到課程表。

• 課程導出到月曆提示

  點選導出到月曆功能後出現彈窗顯示：在設定-清除資料裡可撤銷導出操作。

• 學業分析（ios版本有，Android版本沒有）

  提供可視化的績點排名變化、修習學分統計、修習情況的分析。

• 校曆檢視（ios版本有，Android版本沒有）

  檢視活動安排、假期安排等情況。

創新部分：

• 同學幫

  實名制的同學互動平台。分成學習、生活兩部分。學習部分主要用來釋出一些面向使用者的個人學習資訊。使用者可以在這個闆塊釋出找研友、有償考研資訊分享交流、有償期末答疑解惑等消息。生活部分主要用來釋出一些生活上的便利互助資訊，如打車拼單、閑置物品轉讓出售等。

• 線上簽到點名

  最小以班級為機關在該闆塊上釋出簽到活動，使用者在指定地點附近輸入特定資訊可進行簽到簽退點名。

• 教師資訊查詢

  提供教師的個人資料，授課情況，挂科率高分率、學生評價。

• 我們為福大助手設計了一個闆塊用于學生間的交流。目前學校資源的分享或出售往往是通過qq群聊，效率低且充滿了不确定性。但由于而福大助手實名制的平台提升了學生間交流的效率。該功能的實作需要投入一定成本的開發，但是我們認為這個功能是有使用者群體且有是回報的。使用者群體形成，社群化的平台可以用來投放考研資訊、餐飲宣傳等廣告，廣告內建在這個闆塊不會影響福大助手其他功能的使用。
• 大學課堂一個很重要的特點就是可以任意蹭到想上的課。提供校内課程查詢的功能可以使使用者友善地查獲想上的課的時間地點并添加到課程表。這個功能提升了使用者使用感受且實作成本不大。

• 導出到月曆提示

  很多人點選課程導出到月曆功能往往隻是為了測試這個功能的實作效果如何，但是導出到月曆這個功能實際效果并不是很好（如圖，不僅不能使課程全部清晰地展示在月曆上而且會影響月曆的觀感，甚至可能導緻一些重要事件被蓋住）。而且撤銷這個操作的行為按鍵過于隐，使用者不易找到。

  但不可否認确實有部分使用者會使用課程導出到月曆這個功能，是以我們做出的優化手段是在後出現彈窗顯示：在設定-清除資料裡可撤銷導出操作。

  

• 學業分析、教師資訊查詢、線上點名簽到、校曆檢視

  學業分析，福大助手不具備的福大教務處的功能兩個功能之一，比起可有可無的培養計劃，學業分析有一定使用者需求。

  教師資訊查詢，受西二線上公衆号這個功能的啟發，學生在選課時面對不熟悉的老師能從這裡找到一點資訊幫助選課，使用者需求較大。

  線上點名簽到，受到小小簽到啟發，大學生需要簽到簽退的場合很多，使用者需求大。比起手動簽名，電子簽到的形式更有效率且适合內建到福大助手這個平台。

  校曆檢視，提供可視化的學校時間安排，實作成本低，需求大。

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

在為什麼要做這個功能，而不是其他功能？這個問題裡已經有展現。

我們對福大助手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，估計會經常和團隊一起出來吃飯，交流感情。

在需求分析和軟體開發準備階段大家要一起參與進來，盡快完成自己的任務，提前研發開始的時間。

研發階段，1個人負責Android前端，1個人負責Android後端，1個人負責ios前端，1個人負責ios後端，1個人負責美工。

後期測試階段，Android端可以和ios端互換軟體進行測試工作。

宣傳階段大家也是要一起參與，我認為這部分工作大家都是一樣的是以大家要一起來做。

假設我的團隊都具有一定的開發基礎和開發經驗，那麼我會這麼安排我的團隊：

基本的伺服器架構都是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%
宇恒
政演	9.5%
丹丹	9%
鴻傑	8%
一好	7%
恺琳	6.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		69
5	86
6	85
7	82
8	84
平均		—

評審表

PSP2.1	header 2	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃
· Estimate	·估計這個任務需要多少時間
Development	開發	50
· Analysis	需求分析（包括學習新技術）	60
· Design Spec	· 生成設計文檔
· Design Review	· 設計複審
· Coding Standard	· 代碼規範 (為目前的開發制定合适的規範)
· Design	· 具體設計
· Coding	· 具體編碼
· Code Review	· 代碼複審
· Test	·測試（自我測試，修改代碼，送出修改）
Reporting	報告	20
· Test Repor	· 測試報告
· Size Measurement	· 計算工作量
· Postmortem & Process Improvement Plan	· 事後總結, 并提出過程改進計劃

|合計||160|180
           

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時（小時）	累計學習耗時（小時）	重要成長
	391		25		複習c++，學習單元測試和代碼覆寫率，更熟悉Visual Studio的使用
	100	491		30	在優化代碼和改bug
	15	45	閱讀《建構之法》第三章和第八章，學習使用Axure RP8，對UI設計有進一步了解和認識，對項目開發架構進一步的了解
	441	932		70	對爬蟲初步認識，還有待學習（隊友負責子產品），Debug能力++；
				詳細了解需求規格說明書以及接口文檔書寫
	232	1164		105	學習基礎前端界面布局及學習思維導圖制作
	597	1761		125	學習前端互動，查資料能力++，對前端認識越來越深，恐懼越來越大，懂得做一個項目的艱難！
	323	2084	40	165	前端細節控件監聽，checkbox等等的熟悉、頁面跳轉的學習
9	106	2190		171	優化前端界面，演講答辯經驗++，頭發--

測試文檔

測試ppt