福大軟工 · 第十次作業 - 項目測評（團隊）

Part 0.開篇

作業連結

組長部落格連結

本次測試報告

本次評審表

Part 1.調研，評測

· 評測

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

整體深藍配淺灰的色調，第一眼看起來并不會有違和感，主界面課表頁課程分塊的底色多樣，可通過重新整理換色，直覺漂亮。

功能上基本滿足學生群體的必備需求，例如課表與成績的查詢，圖書館的便利服務，空教室的查找，實驗預約等等，同時結合融入易班工具與期末考啦等等其他軟體，形成一個整合平台，這一點足以吸引大多數本校學生群體。

同時單獨提一下該軟體的蘋果用戶端，增設一鍵評議與二手市場工具等功能，功能雖小卻給人帶來相當便利的使用者體驗。

• 按照描述的bug定義，找出至少兩個功能性的比較嚴重的bug
  • 斷網環境下，二手市場功能因無法擷取資料而進入無休止的加載狀态(ios)
    • bug曝光:

      

    • 具體描述: 斷開wifi後，啟用福大助手的二手市場功能，因無法從伺服器端擷取資料，程式在加載狀态中執行循環等待，但未設定跳出條件判斷而陷入無休止的加載等待狀态中。
    • 可能發生的原因: 網絡不穩定出現斷開網絡或使用者無接入網絡
    • 沒有發現此類bug的原因: 沒有充分考慮斷網未能擷取資料的異常處理
  • 設定下的推送設定點選後導緻軟體未響應(ios)

    • 

    • 具體描述: 進入設定子產品，點選推送功能，程式出現快閃跳回設定界面後卡死未響應，軟體整體奔潰。
    • 可能發生的原因: 軟體自身内部存在代碼錯誤
    • 沒有發現此類bug的原因: 沒有在軟體測試階段及時修複以至于該子產品應用無法正常使用甚至導緻軟體自身奔潰。
  • 圖書館無使用者資訊登出功能(ios)

    • 

    • 具體描述: 使用圖書館賬号登陸後，使用者無法進行登出操作，使用者登陸後點選賬号持續如圖界面。
    • 可能發生的原因: 設計存在缺漏，欠考慮
    • 沒有發現此類bug的原因: 不算重點功能，是以開發過程容易忽略
  • 圖書館無具體的書籍詳情(ios)

    • 

    • 具體描述:使用者通過圖書館檢索搜尋到需要的對象，點選了解詳情時發生無資訊顯示(此功能Android端正常)
    • 可能發生的原因: 内部代碼存在問題
    • 沒有發現此類bug的原因: 開發過程中的疏漏
  • 二手市場設計缺陷(ios)

    • 

    

    

    

    • 具體描述:當使用者使用二手市場功能進行登入操作時，無法傳回上一界面，僅可通過注冊賬戶連結做一個中間跳闆，同時跳轉後整體樣式改變，宛如兩個全然不同的設計
    • 沒有發現此類bug的原因: 不算重點功能，是以開發過程容易忽略
  • 缺少201702的資料(ios&android)
    • bug曝光: 圖略
    • 具體描述:使用者進行績點查詢，但并未傳回真實資料，僅為預設值0
    • 可能發生的原因: 可能是資料源自身的問題，導緻沒有辦法擷取真實資料
    • 沒有發現此類bug的原因: 未及時回報資訊
• 假設你們團隊需要開發這套系統，需要注意哪些方面(架構、部署運維、微服務等)

可采取微服務的軟體架構方式，即将整體軟體應用建構成一系列按業務領域劃分子產品的、小的自治服務，這些自治子產品會處理他們自己的資料、執行不同的功能。這種服務分離的方式很大程度上使得整體可以輕易的建構、修改并拓展整合。獨立開發、獨立部署、錯誤隔離等，這些都非常适合于整套系統一個健壯的開發過程。

· 采訪

某同學甲

• 介紹采訪對象的背景和需求（他們有沒有用過類似的APP，除了現有的功能還有别的需求麼）

一位福州大學大三的學生。他目前在使用福大教務通和易班。他除了現有的功能沒有其他更多的需求。

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

使用過程中他認為該軟體的界面比福大教務通要好看一些，福大教務通的功能它基本都有，而且還內建了其他的小功能，不用再去下載下傳多餘的軟體。十分的友善。

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

主界面的懸浮按鈕太靠下了，不容易按到。無法通過向右滑動的方式打開側邊欄，使用起來不太習慣。在使用一項側邊欄的其他功能時無法通過傳回鍵回到首頁面。

• 結論：經過這麼多工作，你一定有充分的理由給這個軟體下一個評價,請選擇一個結論

非常推薦

某同學乙

一位福州大學大三的學生。他目前在使用福大教務通。他除了現有的功能沒有其他更多的需求。

這個軟體的功能很豐富，基礎的功能與福大教務通使用的感覺一緻，界面會更好一些，在課表的顯示上可以将未開始或以結束的課以灰色狀态顯示，這個功能很不錯。

對曆年卷這個功能希望裡面的内容能更新更豐富一些。

Part 2.分析

• 估計這個項目做到這個程度大約需要多少時間（團隊人數6人左右，計算機大學畢業生，并有專業UI 支援）

估計大概要3個月左右，有專業的UI支援可以省去較多邏輯界面的問題，但是由于系統功能較多，需要爬取的資料量比較大，和原應用涉及的關系也比較多，是以開發和溝通周期應該不會太短，但是應該也會有一些現成接口，是以估計3個月左右。

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

與福大教務通相比，福大助手的操作比較簡潔，但是可視化稍弱。

福大助手較期末考啦功能會比較少一些。

易班的界面和功能比較美觀和齊全，但是邏輯不如福大助手簡潔和清晰。

福大圖書檢索系統加載速度快，但是不如福大助手界面簡單。

相似APP或網頁端：福大教務通、課程盒子、期末考啦、福大易班、福大圖書檢索系統、福大大學實體實驗選課平台、福大教務處官網等。

相比較下，福大助手的頁面簡潔，邏輯清晰，加載快，但是功能不齊全，美觀性較弱。

• 根據了解和體驗，畫出整個軟體所有功能邏輯框圖，根據重要度辨別出各子產品的重要度、完成度、出發點及效果

• 針對不同的次元評分，對使用者體驗方面、UI界面美觀度、核心功能，分别打分

評分内容	滿分	團隊打	評分理由
使用者體驗	10	8	一站式的服務十分便捷，但存在少量bug
UI界面		7.3	界面簡潔，邏輯清晰，但圖示等美感較差
核心功能		8.5	功能較多，速度快，但是子子產品功能不夠齊全

Part 3.建議和規劃

• 如果你是項目經理，如何提高進而在競争中勝出？

提高産品的穩定性。盡量減少登入錯誤的情況發生，避免出現某個功能忽然無法使用的情況發生。

• 目前市場上有什麼樣的産品了？

福大教務通和福大易班。功能基本上差不多，都是可以查成績，考試安排和課表。

• 你要設計什麼樣的功能？

成績詳情。可以檢視每門課的平均分和和最高分，了解自己的學習情況。

• 為何要做這個功能，而不是其他功能？

從學生的需求出發，成績是他們所關心的。而出于競争心理，他們也會有了解大家總體考試情況的需要。

• 為什麼使用者會用你的産品/功能？

因為學生都是比較關心成績的，不僅關心自己考得如何，也會想知道大家的情況，知道自己處于什麼樣的水準。

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

  • Need 需求：

    對于以上的創新，我們不禁可以想到，會有同學使用“福大助手”檢視成績時，不僅僅是想要看到一堆資料，更多的要檢視到圖表的類型，進而能夠更清晰的檢視到自身成績所處的位置。

    同時對于過于單一的界面形式，當功能過于多時，希望界面可以形式多樣化一些。

  • Approach 方法：
  1. 增加适當的圖表資訊，借助統計學的方法進行對資料的分析。
  2. 對于各個不同功能的子產品采用相對不同但又獨具功能風格的界面。
  • Benefit 好處：
  1. 使用圖表可以便于使用者直覺地檢視到相關資訊。
  2. 多樣且個性化的界面不僅可以很直覺的讓使用者區分開各個功能的界面子產品，而且還可以豐富産品的内涵，這不僅是審美上的提升，還是功能上的改善。

  • Competitors 競争：

    針對市面上的類似産品，我們主打內建功能型的産品。一款産品就可以滿足使用者對于諸多功能的需求，我們的産品雖然功能衆多，但是功能使用方面卻不遜色于單一功能的産品。

  • Delivery 推廣：

    首先，将我們的方案給客戶稽核，若稽核通過，我們将進行推廣，可以配合客戶的方法進行推廣，線上和線下進行推廣。線上，如：微信、微網誌、推特等App以及電視廣告等進行推廣；線下，如：傳單宣傳、講座宣傳等措施進行。

• 如果你來上司這個團隊，會有什麼不一樣？

如果讓我來上司這個團隊，我應該會比較注重團隊的規範化和制度化。比如時間表的成立，哪個時間該完成什麼事情強制的列出來，并且比較詳細的對隊員要求工作，而不是等到截止日期之前才來完成。而且技術文檔的建立也很重要，比如遇到的技術上的bug有同學解決了，那麼就更新到文檔裡，遇到同樣問題的同學可以進行查閱，進而降低學習成本。

• 如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？

任務	人數	所占時間比
後端代碼研發	2	40
美工和界面	1	30
測試		20
靈活調整部分（統籌和監管等）

• 文字說明：

一個人負責監管和統籌整個項目程序，合理把握産品的研發方向；兩個人完成主要的後端代碼的開發；一個人負責界面和美工；一個同學完成測試。具體情況還應當根據團隊的實作能力來進行，根據完成的品質和效率進行調整。整體時間比例：開發和測試整體占60%；美工和界面的實作占30%；剩餘的10%屬于靈活時間的調配，可根據具體情況增加或減少。

• 描述你的團隊在16 周期間每周都要做什麼，才能在第16周如期釋出軟體，大小裡程碑績點設定。

周數	任務安排
第一周	小組第一次會議，将接下去的工作清單化和明确化；讨論整體的功能布局；配置設定任務。
第二周	小組進行考察，考察市面上類似的産品，并對其進行産品評估，列出類似産品的優缺點，為接下來的研發做好準備。
第三周	進行界面的設計和布局的規劃。
第四周至第七周	進行産品後端的代碼研發，同時界面和美工組進行相應的調試以及跟後端組進行會談，改進原始方案。
第八周至第九周	測試人員進行産品測試，此時前端、後端、測試人員一齊進行協作。
第十周至第十五周	針對前期遇到的問題每個小組進行改整，繼續完善産品。
第十六周	靈活時間，繼續完善産品，（養成在deadline前完成的好習慣。）等待最終的釋出。

• 項目釋出後，有沒有考慮過項目該怎麼部署才能滿足需求。依據附錄圖（某校教務處系統的部署）作為參考，分析16周後你所完成的項目上線需要哪些配套裝置(伺服器、帶寬、資料庫需求數量與配置)

應用伺服器配置：2 核 2G * 12

後端伺服器配置：16 核 64G * 4

關系型資料庫數量：12（備份 4）

緩存資料庫數量：6（備份 2）

網站安全性：WAF、DDOS

Part 4.增量開發設計

優化/新增的功能點

優化功能:

想必都有用過一鍵評議功能，期末查成績的時候或者選課的時候還要逼迫我們評議，雖然福大助手的一鍵評議對學生很友好，但是評議的分數都是随機的，對于那些你喜歡的老師就不是很友好，是以希望在一鍵評議功能上新加一個可以選擇分數的功能。

新增功能：

線上列印資料功能：線上列印ppt或曆年卷，線下到店取或者出點小錢線下送貨。

選課功能：現在為止好像任何一個軟體都無法實作選課功能，選課還要登陸教務處網上很麻煩，希望能增加一個選課功能。

基本實作思路:

評議功能優化：

在評議界面加入分數選擇，可以設定整體分數，也可以為每位老師設定分數。

新增線上列印資料功能：

這個功能實作起來需要成本，但是也是能夠賺錢的主要功能。實作上分為線上與線下兩部分。

線上：在資料的下載下傳界面上新增列印資料功能，即可跳轉到設定界面，設定列印的格式，如單面雙面、份數、一面多頁、是否裝訂、是否送貨上門、以及收件位址等功能，還可以新加選擇商家功能，設定完畢後跳轉支付頁面，支付成功後商家接單處理。

線下：可以自立門店，與别的商家競争，也可以與校内商家合作，從中賺錢利潤。

新增選課功能：

這個功能需要自立門戶，在主菜單中加入選課功能，相關的選課操作和教務處一緻。

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

一鍵評議新增設定分數功能接入：

此功能在一鍵評議功能上新增，系統自動評議時擷取分數的資料從使用者的輸入欄上擷取，而不是随機擷取，對于使用者未輸入分數的欄目還是使用随機數。

線上列印資料功能接入：

此功能在曆年卷功能下接入，在使用者下載下傳文檔界面選擇線上列印，随後跳轉到線上列印設定界面。

選課功能接入：

此功能從主界面加入，選課資訊要從教務處調入，主要設計好符合人性的選課界面，将學生選完的資訊傳回教務處。

Part 5.答辯總結

組員得分細則

姓名	得分（百分制比例%）
柯奇豪	24
蔣雄	21
黃志銘	12
黃毓明	7
林翔宇
丁水源
楊禮亮
林淇

評審表格設計

Final Score

小組	評分
第一組	74
第二組	82
第三組	78
第四組	77
第五組	72
第六組	71
第七組
第八組	79
最低分	71（第六組）
最高分	82（第二組）
有效分數	74，78，77，72，72，79
最終平均得分	75.4

Q&A

Q1. 增量開發的列印功能有更詳細的實施前調查嗎？

A1. 暫時沒有，但是個人認為列印功能很有用處，但是期末考啦上面的做的就不夠完善，宣傳力度也不夠，是以很少人用過。

Q2. ppt中有些頁面的字太小了

A2. 好的以後會注意。

Q3. 演講時的bgm有點出戲（迫于需要提三個問題）

A3.下次會注意。

Q1. 能否多尋找幾處BUG？

A1. 可以看我們的測評文檔哦，其實我們找了挺多bug的，隻是處于初始PPT時間問題，沒有放在PPT上。

Q2. 增量功能的列印功能需不需要配送，如果需要要怎麼解決？

A2. 可以自由選擇是否配送，我們覺得可以效仿美團和餓了麼的訂單功能。

Q3. 為什麼Android和IOS的BUG沒有分開設定一個區塊來講述？

A3. 這個是我們的問題，測評人員通宵做的，後來新增很多bug，來不及改PPT，下次我們會注意的，謝謝。

Q1: 現場播放音樂讓人有些分心，下次希望可以換一種音樂或者不放。

A1: 好的，我們會吸取經驗，争取下次能夠讓你們滿意。

Q2: PPT中第五頁左上角的餅狀圖讓人難以分辨，希望可以改進。

A2: 謝謝你們的提意，我們會對這一部分進行适當地改進的。

Q3: 有的bug有标注是ios系統，那麼沒有描述的bug是否是安卓端的呢？

A3: 由于裝置原因，其餘的大多數是安卓端的，我們也認識到了我們的測試不足，會争取進行改進的。

Q1:BUG測試記錄的第五點圖檔太多引起接下來的表格很多空白，能夠

否适當排版一下，還有第二張圖檔反了

A1:好的，我們會對此問題進行修改，并引起注意

Q2:報告中IOS的BUG測試是否太少了？

A2:你好，你應該是說反了，應該是安卓較少，可能我們測試的時候疏忽，我們下次會注意。

Q3:能否再測試報告中加上具體的人員分工？

A3:好的，我們會對此問題進行修改，并引起注意

Q1: 在測試的過程中并未提及對應的軟體産品的版本号，這就使得bug沒有針對性，有些或許并不是所有使用者目前所使用的版本都潛在的問題，存在指向不明的情況

A1: 謝謝指正，我們後續會補充說明的。

Q2: 雖然有着詳細的測試資料，但并沒有給出一定的解釋性說明，這造成雖然堆有大量資料但大衆很難去了解其所代表的含義，可以挂出你們對于資料的解讀嗎？

A2: 具體的解讀在文檔裡有

Q3: 指出的分析大都和資料的安全性相關，能否就你們所目前所指出的安全性給福大助手app提出具體的一攬子解決方案呢？

A3: 資料安全無論在哪，一直是個難題。我們目前也沒有很好的解決辦法。

Q1：PPT的bgm是忘記從模闆中删去還是故意設計？

A1：這個當然是故意的呀，我們前一天晚上示範過2-3遍，最後才想到才配樂的哈

Q2：PPT演講部分指代不明，有誤導。

A2：具體是哪方面呢？我們下次會再仔細檢查的，謝謝！

Q3：對提出的增量設計是否考慮過具體的實作方法或衡量過它們的實作難度？

A3：有設想過的，實施起來其實不會太難呀，問題主要是需要再和學校以及商家一同合作協商。

Q1: ppt的右側的黃色欄感覺看的很不舒服很多餘，字很小，希望能考慮到聽衆的視覺感受

A1: ppt的問題我們會根據大家的意見去改進，同時也學習一些ppt做的好的組的ppt。

Q2: 考卷列印的具體實施方案能否分享一下？

A2: 考卷列印我們想做一個外賣的入口，列印店作為商家，商品為列印的份數，将資料的編号作為外賣的備注添加。這是我們覺得目前比較可行也比較容易實作的方式。

Q3: 雖然有一定難度，但是還是一提研究所學生和導師賬号登入後的界面是否有過測評？

A3: 這個我們當時沒有想過這方面的，也沒有獲得這些賬号的管道。

Part 6.個人部分

• 個人PSP

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

• 個人學習進度條（每周追加）

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時(小時)	累計學習耗時（小時）	重要成長
	N			42	進行微信小程式自定義控件部分的學習，學習傳遞控件内資料的方式