項目評測

時間 2019-11-17

標籤項目評測简体版

原文原文鏈接

目錄html

組長博客連接前端

做業連接mysql

第一部分調研，評測

評測：android

福大助手的bug

IOS端

若是沒有對「福大助手」進行日曆的受權設置，那麼「考場」中的「加入日曆」功能沒法實現，點擊「加入日曆」提示「受權失敗」的窗口，可是沒有引導用戶進行受權的窗口；

「設置」中的「推送」功能沒有實現，點擊「推送」顯示頁面後沒法操做，全部Switch按鈕無效，也沒法回退到「設置」界面；

「一鍵評議」功能若是輸入錯誤的字符串會屢次提示「發送未知錯誤，評議失敗，嘗試繼續評議」，而後app崩潰；

「易班工具」中的「輔導員考覈」功能，輸入「得分」欄的數據爲字母或特殊字符（如@、&等）點擊「保存」後沒有提示「只能輸入數字」的窗口，而是直接顯示「輔導員考覈詳情」頁面

Android端

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

「一鍵xx」功能，若是反覆切換評議用途，切換事後的頁面刷新初始化十分緩慢，有時出現初始化的狀況，「驗證碼」不管輸入的是什麼，都可以開始評議。

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

按照描述的bug定義，找出至少兩個功能性的比較嚴重的bug。用專業的語言描述bug（每一個bug 很多於 40字），並適當配圖.

爲何開發人員沒有發現這個bug

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

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

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

衆所周知，福大助手是由福大本校學生組成的西二在線所開發，隨着學生不斷的畢業以及新技術的不斷嘗試，團隊自己的人員組成以及項目使用的技術會以至關高的頻率迭代。一樣，做爲福大本地化軟件，福大助手無疑會在未來不斷地進行優化。redis

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

微服務，以單一職責、服務自治、輕量級通訊及接口明確爲設計原則的一種架構風格；而針對福大助手這一app，咱們認爲最應該注意的是項目應該採用微服務構架。
爲何這樣說呢？咱們看看微服務和傳統單體構架的區別：sql

單體架構全部的模塊全都耦合在一塊，代碼量大，維護困難；微服務每一個模塊就至關於一個單獨的項目，代碼量明顯減小，遇到問題也相對來講比較好解決。數據庫
單體架構全部的模塊都共用一個數據庫，存儲方式比較單一，微服務每一個模塊均可以使用不一樣的存儲方式（好比有的用redis，有的用mysql等），數據庫也是單個模塊對應本身的數據庫。後端
單體架構全部的模塊開發所使用的技術同樣，微服務每一個模塊均可以使用不一樣的開發技術，開發模式更靈活。

很明顯，微服務架構其本質即是在結構上實現各個服務模塊的鬆耦合。
就福大助手來講，微服務能爲團隊帶來主要好處以下：

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

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

對團隊的運維提出了很高的要求：
對於單體架構來說，咱們只須要維護好這一個項目就能夠了，可是對於微服務架構來說，因爲項目是由多個微服務構成的，每一個模塊出現問題都會形成整個項目運行出現異常，想要知道是哪一個模塊形成的問題每每是不容易的，由於咱們沒法一步一步經過debug的方式來跟蹤，這就對運維人員提出了很高的要求。在團隊的實際資源分配中，勢必要比以往投入更多的資源在運維上。
微服務是一個分佈式系統
對於單體架構來說，咱們能夠不使用分佈式，可是對於微服務架構來講，分佈式幾乎是必會用的技術，因爲分佈式自己的複雜性，致使微服務架構也變得複雜起來。

採訪

福大助手採訪：

採訪一

介紹採訪對象的背景和需求
使用過易班、福大教務通、超級課程表等相關軟件。除了現有功能沒有什麼其餘需求。
讓採訪對象使用福大助手（請上傳照片證實用戶的確正在使用，遠程採訪的同窗請讓別人幫忙照相）
描述用戶使用這個產品的過程, 用戶的問題解決了麼？軟件在數據量/界面/功能/準確度上各有什麼優缺點？用戶體驗方面有問題麼？
這個軟件功能很強大，能夠解決想要解決的問題。在數據方面，數據量大，能夠查不少東西。界面很友好。準確度沒有什麼問題。用戶體驗上，它的功能很複雜，在只想看課表的時候更傾向於教務通，由於它功能單一，看起來比較清晰簡單。福大助手平時反而不會用。
用戶對產品有什麼改進意見？
這款軟件很強大，沒有意見。
結論
很是推薦

採訪二：

介紹採訪對象的背景和需求
使用過易班、福大教務通、超級課程表等相關軟件。但願經過軟件方便本身學習和生活。
讓採訪對象使用福大助手（請上傳照片證實用戶的確正在使用，遠程採訪的同窗請讓別人幫忙照相）
描述用戶使用這個產品的過程, 用戶的問題解決了麼？軟件在數據量/界面/功能/準確度上各有什麼優缺點？用戶體驗方面有問題麼？
這個軟件功能很強大，能夠解決想要解決的問題。裏面東西不少，被安利了。界面有更換主題功能，很是適合本身。功能上，還但願能增長交水電費和校園卡充值功能。準確度上和其餘相似軟件沒有區別。
用戶對產品有什麼改進意見？
增長交水電費和校園卡充值功能。
結論
推薦

採訪三：

介紹採訪對象的背景和需求
使用過易班、福大教務通、超級課程表等相關軟件。但願只用一款app包括全部內容的軟件，不想本身的qpp太多。
讓採訪對象使用福大助手（請上傳照片證實用戶的確正在使用，遠程採訪的同窗請讓別人幫忙照相）
描述用戶使用這個產品的過程, 用戶的問題解決了麼？軟件在數據量/界面/功能/準確度上各有什麼優缺點？用戶體驗方面有問題麼？
這個軟件功能很強大，能夠解決想要解決的問題。數據量方面，裏面包括了教務通和易班的大部份內容，界面方面，很是不友好，感受很差看，iOS手機界面和android手機不一樣，課程表界面和側邊欄界面很差看。準確度方面，和另外兩款沒差。用戶體驗上，第一感受界面不友好。
用戶對產品有什麼改進意見？
將ios的界面設計得更友好。
結論
通常

第二部分分析

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

三個半月。
主要分爲萌芽，磨合，規範，創造四個階段。
人員分工爲項目負責人一人，前端兩人，後端兩人，算法一人，並有專業UI支持。
1、萌芽時期花費半個月。
（1）根據調查客戶需求進行需求創做，需求再改進，由項目負責人和開發共同確認需求可行。
（2）而後UI設計和前端進行具體討論，給出一套完整的需求文檔，肯定項目開發週期。
（3）根據以上討論結果對整個項目進行一個整體的規劃，進而肯定項目的詳細功能和人員的具體分工。
2、磨合時期花費兩個月。
（1）原型設計階段花費十天左右，前期畫出產品的基本草圖頁面，其中包括:產品原型頁面交互/產品功能說明文檔，前端根據需求分析設計出一套大體的原型設計模型，後期UI設計給出具體建議，對原型進行具體改進，得出一個理想實現界面，並給出產品結構圖、模塊功能梳理清單。
（2）開發設計階段須要一個多月，這階段主要是先後端開發設計以及先後端交接，實現產品的具體功能，這個階段應該注意的一點是好比註冊域名、買服務器、備案、蘋果開發者帳號、安卓開發者帳號、短信服務等等。在肯定開發後就能夠準備這些東西了。否則中途會影響開發工期，影響上線時間。
（3）磨合後期進行初步驗收測試，兼容性調試開發。並及時解決此產品不兼容問題，bug問題和閃退問題。
3、規範時期花費半個月。
在磨合期已經得出項目的胚型，規範時期就是對項目進行優化改進，對產品進行調整和增刪。
（1）前端進行版塊細化，界面調整和功能增刪。
（2）後端則及時給出接口，與前端進行對接。
（3）UI設計則注重界面美化，使用戶獲得一個簡潔美觀的觀賞頁面。
（4）階段後期進行項目總測試，對項目完整的進行一個驗收測試，並給出US流程圖。
4、創新階段花費半個月。
（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	計劃	20	10
· Estimate	·估計這個任務須要多少時間	60	70
Development	開發	20	10
· Analysis	需求分析（包括學習新技術）	60	60
· Design Spec	· 生成設計文檔	0	0
· Design Review	· 設計複審	0	0
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	80	50
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	·測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	10	10
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工做量	0	0
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	20	20
合計		270	230