福大軟工 · 第十次做業 - 項目測評之拖鞋旅遊隊

拖鞋旅遊隊項目測評

前言

• 隊名：拖鞋旅遊隊
• 組長博客：http://www.javashuo.com/article/p-fctqbfnm-kq.html
• 本次做業：https://edu.cnblogs.com/campus/fzu/Grade2016SE/homework/2436

第一部分 調研，評測

評測

Android端評測

• 上手體驗：功能全面，易於上手，佔用內存小，頁面設計人性化。
• 思惟導圖：
  
• Bug1：
  
• Bug2：
  
• 爲何這個產品組的人沒有發現這些bug：測試小組測試不仔細，不全面；這些功能先後端開發可能不一樣步。

IOS端評測

• 上手體驗：運行流暢，圖標簡潔，配色清爽，部分圖片失真，功能種類多可是不完善，夜間模式，導入日曆功能方便，實用性高
• 思惟導圖：
  點我查看原圖
  
• Bug1：
  
• Bug2：
  
• 爲何這個產品組的人沒有發現這些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	小白吃	79

• 問題&回答

第一小組的問題：

• 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	計劃	5	5
· Estimate	· 估計這個任務須要多少時間	120	150
· Development	開發	10	10
· Analysis	· 需求分析 (包括學習新技術)	10	10
· Design Spec	· 生成設計文檔	20	30
· Design Review	· 設計複審 (和同事審覈設計文檔)	20	20
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	50	80
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	0	0
· Reporting	報告	0	0
· Test Report	· 測試報告	0	0
· Size Measurement	· 計算工做量	0	0
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	5	5
	合計		150

• 我的學習進度條

第N周	新增代碼(行)	累計代碼(行)	本週學習耗時(小時)	累計學習耗時(小時)	重要成長
1	300	300	8	8	入門Visual studio的使用(包括單元測試)
2	0	300	6	14	瞭解正則表達式的使用
3	0	300	10	24	加深掌握了Axure的使用，學會了使用NABCD模型進行需求分析
4	500	800	36	60	增強了python/java爬蟲基礎,在java代碼方面有很大的提高，解除了數據分析和可視化設計
5	0	800	10	70	競品分析
6	0	800	12	82	UML設計，需求收集
7	0	800	10	92	需求分析，思惟導圖設計
8	150	950	22	114	團隊現場編程，收驗團隊成果，思考與改善總體架構
9	100	1050	8	122	尋找產品配色，協助先後端對接，對界面UI提出改善
10	500	1550	10	132	產品配色，先後端對接
11	0	1550	7	139	這階段主要總結反思Alpha衝刺和項目評測的實施