1. 程式人生 > >福大軟工 · 第十次作業 - 項目測評之拖鞋旅遊隊

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

系統 table 同事 stage 校招 www. 表達式 推理 odin

拖鞋旅遊隊項目測評

前言

  • 隊名:拖鞋旅遊隊
  • 組長博客:https://www.cnblogs.com/Sulumer/p/10087665.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小時跟服務器請求一次,如果有新通知則在安卓端彈出。
  • 優化/新增功能點與原有產品如何接入
    歷年卷入口簡要原型:
    技術分享圖片

第五部分 答辯總結

  • 評分:去除最高分(83)最低分(73)後的平均分:76.71

    組號 團隊名 評分
    1 爸爸餓了 73
    2 拖鞋旅遊隊 81
    3 彳艮彳亍 78
    4 火箭少男100 75
    5 起床一起肝活隊 83
    6 404 Note Found 79
    7 第三視角 77
    8 小白吃 74
    9 我頭發呢 73

第六部分 個人部分

  • 個人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 產品配色,前後端對接

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