第十次作業 - 項目測評

拖鞋旅遊隊項目測評

前言

• 隊名：拖鞋旅遊隊
• 組長部落格：https://www.cnblogs.com/Sulumer/p/10087665.html
• 本次作業：https://edu.cnblogs.com/campus/fzu/Grade2016SE/homework/2436

第一部分 調研，評測

評測

Android端評測

• 上手體驗：功能全面，易于上手，占用記憶體小，頁面設計人性化。
• 思維導圖：

  

• Bug1：

  

• Bug2：

  

• 為什麼這個産品組的人沒有發現這些bug：測試小組測試不仔細，不全面；這些功能前後端開發可能不同步。

IOS端評測

• 上手體驗：運作流暢，圖示簡潔，配色清爽，部分圖檔失真，功能種類多但是不完善，夜間模式，導入月曆功能友善，實用性高
• 點我檢視原圖

  

• 

• 

• 為什麼這個産品組的人沒有發現這些bug：第一個bug可能是因為開發者對于考試安排的了解錯誤。第二個bug是前後端對分享功能的開發不同步。

假設你們團隊需要開發這套系統，需要注意哪些方面(架構、部署運維、微服務等)。

• 我們會加強宣傳。
• 根據回報修複bug。
• 跟進更新如曆年卷、易班等功能。

采訪

• 采訪對象背景：附件某高校大三學生，沒有使用過類似app。
• 采訪對象需求：需要一款可以檢視課表、考場、成績及一些在校日常查詢的功能。
• 采訪照片：

  

• 采訪對象的使用體驗：
  • 采訪對象對日常一些所需要的查詢資訊的問題都可以完美地解決。
  • 資料量很齊全且豐富，所需要查詢的資訊都可以查到。
  • 界面較為簡潔明了且醒目，但不同界面間的字型風格不夠統一。
  • 功能比較齊全和豐富，但部分易班上的功能使用度過低。
  • 準确度上做的較好，使用到目前未發現不準确現象。
• 采訪對象的改進意見：這位使用者強烈建議增加一個課表分享和成績分享的功能，他想分享到微信上給别人看他的課表，以及家長對于成績的查詢，能夠簡單明了直覺的看到所需的資料。
• 結論：非常推薦！

第二部分 分析

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

  我們估計這個項目做到這個程度隻需要一個月，因為既然是本校大學畢業生，應該會有比較好的基礎，而且做這個項目應該會受到學校極大的支援，對接口的擷取難度應該較低，而且有專業的UI支援，我們認為一個月時間足夠了。

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

  這款軟體優勢在于擁有較為廣闊的群衆而且功能也算齊全，劣勢就在于有些功能可以有時候無法使用（空教室功能），在軟體工程方面可以提高的一個重要部分就是對曆年卷這一子產品的管理，許多科目都上傳了不相關的資訊進而幹擾大家擷取正确的資訊，希望能夠加強這一塊的管理。

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

  

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

  使用者體驗方面打7分：因為有些功能經常無法使用而且曆年卷功能沒有維護。

  UI界面美觀打9分：界面簡潔明了，矢量圖也很精美。

  核心功能8分：查詢課程表、查詢成績、查詢考場、曆年卷應該都是核心功能，大多數都好用。

第三部分 建議和規劃

• 如果你是項目經理，如何提高進而在競争中勝出？
  • 加強宣傳。這款産品宣傳力度在同類中非常低，大部分同學沒有使用過甚至沒有用過。
  • 解決bug，增強使用者體驗。
  • 增強功能，如檢視課表，查詢成績，查找曆年卷。
• 目前市場上有什麼樣的産品了：超級課程表、福大教務通、課程格子。
• 你要設計什麼樣的功能？
  • 曆年卷代列印及送貨上門服務。
  • 學分查詢。
  • 教師基本資訊查詢。

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

  據我們作為學生的角度以及綜合前期的調研等，這幾個功能現有方式較為不友善，而這些功能又都是剛需。

• 為什麼使用者會用你的産品/功能？
  • 到期末的時候大家都會有列印曆年卷的需求，這樣比較友善同學。
  • 目前福大助手易班中的學分查詢已經不能用了。學分查詢對于同學來了解自己還差多少學分還是很有必要的。
  • 教師基本資訊查詢可以幫助同學們在學期選課的時候看到教師的基本資訊幫助同學們選擇任課老師。

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

  我們的創意解決了使用者列印曆年卷，查詢學分，已經在選課時可以比較老師的挂科率和高分率。相對于其他競争者而言，不太可能做到這麼本土化的功能，他們的課表app固然很優秀，但也伴随着廣告多，社交性太強等諸多問題。而我們的app更能滿足使用者的需求。

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

  如果我來上司這個團隊，說實話，我覺得不一定會比現在的團隊做得好。但是站在另一個角度，使用者回報、營運方面并沒有得在這個産品的現有團隊得到很好的展現。如果是我來上司，在産品上線後，我會加強營運這個産品，至少做到讓全校學生都知道又這款app。使用者回報也是極其重要的，它可以幫助我們不斷的修複和完善産品，我會重視使用者回報，有時間甚至會與使用者深入溝通，以此來不斷提升産品。

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

  這是一款工具類的産品，同時具有非常強的競争力，是以我認為這款産品的美工任務還是比較小的，同時開發周期也是比較緊張的，不足以配置設定一人。我會配置兩名人員作為前端開發（其中一名為前端組長），兩名後端開發（其中一名後端組長），一人項目經理兼産品經理兼美工兼營運，全員開發（兩名組長與項目經理主要測試，其他人員輔助測試）。

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

  

  

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

  

第四部分 增量開發設計

• 優化/新增功能點的原型界面
  • 新增曆年卷上傳入口。
  • app消息推送功能。
• 基本實作思路
  • 曆年卷上傳入口

  • 後端新增一個檔案上傳接口，為了安全要加入token以及AES加密，同時不能直接釋出，需要有一個辨別标記稽核情況。
  • 前端在曆年卷頁面加一個上傳按鈕，上傳參數：學院、科目、檔案、學号、時間....同時上傳隻是上傳，管理者在後端頁面通過稽核之後，才允許出現在曆年卷裡。
  • 獎勵還是無獎勵機制，後續再看積極性。

  • app消息推送功能

  • 出成績或者考試日期公布臨近，就會推送。
  • 校招，每天的招聘資訊推送。 由于考慮到出成績、考試、校招這些都會提前出來，而且也不是緊急時間，是以可以采用輪詢的方式，頻率每12小時或每6小時跟伺服器請求一次，如果有新通知則在安卓端彈出。

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

  曆年卷入口簡要原型：

  

第五部分 答辯總結

• 團隊貢獻比例

  | 學号 | 成員 | 分工 | 貢獻分 |

  | --------- | ------ | ------------------ | ------ |

  | 031602428 | 蘇路明 | 撰寫部落格，回答問題 | 9|

  | 031602401 | 陳瀚霖 | 評測，評審表，提出問題| 11|

  | 031602406 | 程曉宏 | PPT制作與示範| 12|

  | 031602438 | 葉一帆 | 增量開發 | 9.5|

  | 031602407 | 何家健 | 評測，評審表，提出問題| 10|

  | 031602410 | 黃海潮 | 采訪| 9|

  | 031602429 | 王錦揚 | 建議與規劃 | 9.5|

  | 031602442 | 鄭孔宇 | 分析|9.5|

  | 031602439 | 俞凱欣 | 建議與規劃| 9.5|

  | 031602421 | 林世傑 | 項目評測報告| 11|

• 評分：去除最高分（81）最低分（71）後的平均分：75.84

  組号	團隊名	評分
  1	爸爸餓了	71
  2	拖鞋旅遊隊	81
  3	彳艮彳亍	79
  4	火箭少男100	72
  5	起床一起肝活隊	75
  6	404 Note Found	76
  7	第三視角	74
  8	小白吃

• 問題&回答

第一小組的問題：

• Q1:增量開發中的列印送上門服務可行性強嗎，畢竟列印成本很低，但是人力送貨上門的成本很高？
• A1:我們覺得可行性還是挺強的，至少列印利潤高，使用者在這方面需求也比較強。可通過使用者自行選擇上門或者自取，上門收取額外費用（1-2元），其實在校内送貨上門地點還是比較集中的，可以考慮一天送一次等，數量上去了，成本就降低了，同時校内列印服務市場劃分還是比較明确的，這一服務能有效提升合作列印店的市場擴張。
• Q2:是否考慮過對增量功能采用其他的送貨方式，比如使用者到店自提或者使用類似豐巢快遞櫃的設變來支援這個功能？（隻是假設）
• A2:有考慮過多種方式結合，如果隻是純粹到店自提，資料的管理也是一件很棘手的事情，我覺得在這一場景不适用類似豐巢快遞櫃的設變，成本過高，沒有必要。
• Q3:測評除了采訪對象外是否有釋出問卷調查？
• A3:這一方面我們相對其他組确實比較欠缺，我們沒有釋出具體的問卷調查，隻有通過一些資料收集，以及采訪交流。

第三組的問題

• Q1:請問你們的緻命級bug2是什麼系統的bug？
• A1:我們在測試報告以及PPT都有以系統來分割bug，我們展示了不止一個緻命級bug，好像沒有厘清這裡說的是哪個bug。
• Q2:請問再找其他學校同學測試的過程中兩者學校易班或是大物實驗等一些福大助手核心功能子產品在現實中的作用是否相似？
• A2:易班類有相似，大物實驗沒有具體了解。
• Q3:請問那位被采訪同學說希望增加課表分享,課表分享不是已經有了麼？
• A3:但是目前福大助手這方面做得好像并不夠完善，也不能成功分享吧。IOS系統沒發現課表分享功能。

第四組的問題

• Q1:ppt中部分圖檔建議考慮使用透明的底，而不是白底。
• A1:作為白底主要是考慮到圖檔的界限問題，以後會注意。
• Q2:bug展示的不夠多，是沒有發現更多的呢還是選了兩個有代表性的呢
• A2:選取了兩個有代表性的，其他的相對感覺不是很重要或者頻率不是很高。
• Q3:采訪使用者數量是否有些不足呢
• A3:這一方面我們相對其他組确實比較欠缺。

第五組的問題

• Q1:采訪對象是否太少，結果會不會出現特殊性
• A1:這一方面我們相對其他組确實比較欠缺。但是我們也有收集其他的資料，從反映情況還是沒有出現特殊性的。
• Q2:ios端的bug沒有展現系統環境，查詢不到是否足以夠作為理由
• A2:福大助手軟體内沒有注明版本，在app store中查詢應是3.9.12.版本。
• Q3:測評報告第八頁，BUG2中的b小點，“幾點”是否為錯别字，這能否展現後期對報告成品的稽核不夠充分
• A3:确實是錯别字，這是我們的失誤，我們考慮将撰寫報告的人員“祭天”。

第六組的問題

• Q1:ppt24頁的改進意見中，課表分享福大助手已經實作了
• A1:但是目前福大助手這方面做得好像并不夠完善，也不能成功分享吧。IOS系統沒發現課表分享功能。
• Q2:邏輯框圖和思維導圖顯示不清楚
• A2:本次截圖确實都顯示比較模糊，我們也有盡力在處理。
• Q3:能否關閉APP消息推送功能
• A3:确實應加入app消息推送的選擇。

第七組的問題

• Q1:ppt功能設計中第一點是：曆年卷代列印及送貨上門服務。此功能實作起來有點難度，想知道怎麼來具體實作這個功能？
• A1:使用者選擇列印，背景資料發送給列印店并産生單号，提取方式選擇送貨上門（考慮收取1-2元服務費）或者自取，現在跑腿這麼發達，送貨上門應該不會問題。
• Q2:在增量功能中，對于那個曆年卷的功能，假設會去實作，那請問你們怎麼判斷曆年卷的真實性，以及可靠性？
• A2:曆年卷上傳肯定是需要背景人工稽核的，也可以考慮在前台注明不明真實性，使用者發現曆年卷的不真實可K它，被K多了的曆年卷将考慮暫時下架重新稽核。
• Q3:ppt功能邏輯圖中你們認為“大物實驗”的完成度是0，你們是怎麼判斷出是0的？
• A3:目前好像登入不上？

第八組的問題

• Q1:測試報告中的中功能點的重要程度與完成程度的數值是否具有準确性和科學性？
• A1:隻能說是預估吧。
• Q2:ppt中表示福大教務通作為一款福大助手工具是不合格的，但是為什麼福大教務通的使用率依舊如此之高？
• A2:首先其在産品推出前期做了良好的推廣效應，同時其實官方産品，有官方光環保護。最重要其實感覺其是針對教務通方面，不具備其他的助手功能，其使用率高我覺得是因為使用者習慣（本人也是教務通忠實粉絲，對此方面思考認為是如此）。
• Q3:曆年卷列印功能在期末考啦上面已經失敗過了，你們是否有更好的實施方法？
• A3:其的使用者需求度不言而喻，失敗不代表不可行，失敗也有很多種原因。良好的服務和使用者的便利是這方面最重要的條件，至于實施方案不清楚之前的期末考啦是怎麼操作的，覺得這方面在列印源與配送上有非常大的優化空間。

第六部分 個人部分

• 個人PSP

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

【學習進度條】

第N周	新增代碼(行)	累計代碼(行)	本周學習耗時(小時)	累計學習耗時(小時)	重要成長
	18.5		熟悉Axure的使用方法、對軟體的原型設計有了更深刻的了解
	113		28.5	47	對算法的構思有更多的了解
	106	219		62	加深掌握了Axure的使用，學會了使用NABCD模型進行需求分析
	211	430	18	80	認識了原型設計的重要性，學會部分原型設計的技能
	252	692	12	92	進行logo，原型的設計與修改
		742		102	logo，原型初步設計完成
	190	932		132	logo，原型完善
			157	海報設計，logo，原型完善
9		1132		162	logo，原型繼續完善
	100	1232		165	短故事模闆設計