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

前言

• 組長博客：hjj
• 做業博客：第十次做業 - 項目測評（團隊）

第一部分 調研，評測

評測

• 小組我的第一次上手體驗

  • 後敬甲

    福大助手定位是，爲Fzuer量身定作的校園學習生活助手。
    在初次上手以後，能夠發現其功能基本覆蓋了福大學習生活的各個方面，也符合軟件自己的定位。
    發現一點不足在於，軟件沒有固定的首頁，各個功能模塊同一級並行，在各模塊都可獨立退出app，頁面層次分佈不符合多數用戶已有的使用習慣

  • 劉浩

    上手體驗：初次運行後第一感受是app響應很快且功能不少 目前使用到的就其中下載歷年卷和查看課程表這兩個功能 這兩個功能都很齊全 ui設計總體感受比較和諧 在左邊放置功能切換界面讓人眼前一亮 整體來講仍是一個不錯的大學應用工具

  • 盧澤明

    上手體驗：Android端的福大助手界面好看，首頁爲課程表也是知足了廣大學生的需求。運行流暢，功能這幾年一直在增長，能夠說已經集齊了大部分必備功能。
    不足之處：功能部件所有在右側展開部分，確實有點不夠明顯。我相對喜歡把各個頁面放在底部欄的按鈕。其次沒有我的中心，可讓用戶設置本身的我的信息，好比修改頭像，設置基本信息等。
    還有就是但願加上一些校園小知識，好比小白的發車時間地點等

  • 黃靖茹

    上手體驗：界面整體來講比較簡潔，歷年卷和一鍵評分功能是使用福大助手的主要緣由。功能相教福大教務處更齊全。交互方面作的也還能夠，可是針對安卓系統，每次按返回鍵沒有返回上一層對於安卓用戶來講不是很習慣。小建議：歷年卷能按本身專業分就更好了，有的時候不想打字也沒必要翻好久的目錄。

  • 葛亮

    上手體驗：運行速度快功能多，一個app集合了易班和教務處的功能，更有方便同窗選課和搶實驗的功能。
    課程表導入到日曆也很方便。
    但查考場的界面感受有美中不足，若是有多門考試連在一塊兒，極有可能把日期和科目看混。
    另外沒有找到能夠修改登陸信息和找回密碼的界面和功能，在訪問登陸失敗的時候讓用戶很絕望。

  • 蔡文斌

    上手體驗：Android端的福大助手界面簡潔大方，用戶容易上手，運行流暢，功能齊全，幾乎集齊了其餘校園app的功能，是一款不錯的校園軟件。
    不足之處：沒有我的中心，可讓用戶設置本身的我的信息，好比修改頭像，設置基本信息等。能夠在抽屜內加上校歷的這個功能，方便用戶查詢節假日等信息。若是能夠的話，對於界面的設計能夠進一步的改善，有些界面太過於簡單，雖然突出了功能，可是對於部分用戶，使用體檢就不是那麼好

  • 黃澤

    上手體驗：總體佈局簡潔明瞭，無廣告騷擾，交互動做天然柔和，功能相較於福大教務處更加完善齊全，課程導入日曆功能比較新穎，美中不足的是單期績點沒法查看，部分交互沒有給出明確提示，好比點擊左側欄本身的名字會彈出我的信息一覽表，可是不容易被用戶發現。總的來講是一個優秀的校園app

  • 朱躍安

    上手體驗：進入界面的首頁是課表界面很是方便平常查課表。抽屜界面包含功能豐富，可以爲福大學生提供很好的服務，並且還能在設置界面隱藏本身平時用不到的功能。
    不足之處:校招功能處沒有給出近期校招活動的列表，只能本身一個一個的去查找。若是在不知道校招活動具體狀況下，就很難經過搜索框查找，只能本身手動滑動日期條，一個一個的查看每一個日期下的校招活動，應該添加一個日曆表。有些界面過於簡陋不美觀，如嘉錫講堂界面，這頗有可能影響到用戶使用該功能。

  • 張傑

    上手體驗：Android端總體佈局遵循Material Design，以藍色爲默認色彩並能夠更改喜歡的顏色，簡潔大方。抽屜內功能豐富，整合福大教務通、福大易班、福大曆年卷，基本知足用戶需求，同時可將課程同步到日曆中，方便使用。

    不足之處：
    內的用戶信息佔位較大但無功能，建議將我的信息以及帳號註銷等功能放置其中。
    右上角的更多功能用於切換學期較爲奇怪。
    fab彷佛是爲了fab而fab，功能能夠整合至右上角更多按鈕。

• 思惟導圖
  

• Bug及緣由猜測
  點擊此查看在線文檔

• 假設團隊須要開發這套系統，須要注意的方面

  • 普遍聽取用戶的意見，作出適當的改進和調整。
  • 界面交互更加良好
  • 主題功能模塊要有突出特點，不能只是大雜燴。
  • 我會增強宣傳力度，尋求合做。正如如今的易班同樣，不斷地在高校內合做推廣，知名度就高了起來。不少人是沒聽過福大助手，那我相信在大力宣傳之下，只要用戶接觸了福大助手，就會發現是值得使用的

採訪：

Android手機：
1.背景：數計學院2016級計算機專業某不肯透露名字的蔡同窗，據他描述爲第一次使用福大助手
2.需求：
須要時常查看課程表，且期末考將近，急需歷年卷的幫助，通過短暫使用，蔡同窗表示福大助手基本知足他的需求
除了現有的功能外，蔡同窗以爲要是App能整合一個及時通信功能，或者是線上交流功能，讓你們能夠交流學業或者其餘信息的話就更好了

IOS手機：
1.背景：福建師範大學2016級軟件工程某不肯透露名字的陳同窗，據他描述師大尚未這種學業助手類型的應用
2.使用體驗：
初次上手，陳同窗表示該程序能在Apple store上線足以說明該程序仍是至關厲害的，由於審覈要求比較嚴格，（相對於安卓應用）還表示他很喜歡這種不顯示主頁，將全部功能簡化的設計
並且功能也齊全，採訪者問其有什麼想法，他表示驚訝於學校願意將學校數據接口給學生使用，且感嘆福大助手團隊完成了一個完成度比較高的做品

第二部分 分析

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

  計算機專業畢業具備良好的專業素養，在專業UI的額外支持下，三個月比較足夠。

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

  優點：

  • 做爲課程表軟件，它比「超級課程表」來的清新，沒有煩人的廣告，用戶體驗較好
  • 做爲學習資料軟件，比百度文庫，豆丁文檔等針對性，福大學習能夠精確找到符合條件的資料，與期末考啦至關。
  • 做爲校園交流軟件，比福大易班來的流暢，比福大教務通功能來的多，界面更加整潔，服務器較少癱瘓。

  劣勢：

  • 尚有不少功能有待完善，好比添加課程方面，常常出現bug，致使用戶卸載重裝。
  • 福大助手做爲校園助手，限制了它的上限只能是在福大。相比易班，其推廣度大大不如。

• 根據理解和體驗，畫出整個軟件全部功能邏輯框圖，根據重要度標識出各模塊的重要度、完成度、出發點及效果；

  • 成績查詢
    
  • 嘉錫講壇
    
    -教務通知
    
  • 考場查詢
    
  • 課程表
    
  • 空教室查詢
    
  • 歷年卷
    
  • 圖書館
    
    -校招日曆
    

• 針對不一樣的維度評分，對用戶體驗方面、UI界面美觀度、核心功能，分別打分。

  • 用戶體驗 9/10
  • UI 8.5/10
  • 核心功能 9.5/10

第三部分 建議和規劃

• 若是你是項目經理，如何提升從而在競爭中勝出？
  • 普遍聽取用戶的意見，作出適當的改進和調整。
  • 界面交互更加良好
  • 主題功能模塊要有突出特點，不能只是大雜燴。
  • 我會增強宣傳力度，尋求合做。正如如今的易班同樣，不斷地在高校內合做推廣，知名度就高了起來。不少人是沒聽過福大助手，那我相信在大力宣傳之下，只要用戶接觸了福大助手，就會發現是值得使用的
• 目前市場上有什麼樣的產品了？
  • 福大易班的校本化功能，期末考啦爲學生提供學習資料的查詢，超級課程表提供課表查詢。
• 你要設計什麼樣的功能？
  • 能夠設計一個校內百事通的功能。彙總各類常見問題，如：福大哪裏有乾洗店，哪裏能夠充電等。
  • 能夠將學生卡充值整合進來。真正作到上大學只須要一個軟件
• 爲什麼要作這個功能，而不是其餘功能？
  • 福大助手是專門爲福大學生服務而設計的，綜合了學生對平常生活和學習方面所需的服務，評測出學生須要哪些不須要哪些功能，例如福大易班提供的精品課程功能，對於大部分學生來講使用的頻率低，對於福大助手這種輕便的軟件是不要這種功能的。又如課表查詢，福大助手提供的僅僅是對於課表的查詢、更新等平常學生常常用到且必須的功能，而超級課程表添加除課表查詢外，還有小紙條功能提供簡單的聊天功能，這對學生來講是極少使用的。總之，福大助手提供的功能是學生常用到且有幫助的的，刪除一切沒必要要的功能。
• 爲何用戶會用你的產品/功能？
  • 首先由於功能齊全，整合大學生各類必備的如課程表，空教室查詢等。很是的簡潔方便。
  • 其次界面清晰，運行流暢，沒有廣告等擾人內容。
• 你的創新在哪裏？能夠用 NABCD 分析。

NEED：福大助手僅提供對學生平常生活和學習有需求的功能，其餘沒必要要的功能都沒有添加，極大的方便學生用戶的使用。
APPROCH：福大助手將一個個較大的需求，封裝成一個個功能模塊，並且用戶還能夠經過設置隱藏一些較少用到的功能模塊，這樣更簡化操做。
BENEFIT：各個功能模塊提供不一樣的服務，且所有的功能模塊涵蓋了幾乎全部的用戶所需的功能，用戶只需下載一個軟件就能享受到好幾個軟件提供的服務，並且操做更加輕便。因爲刪除了沒必要要的功能，軟件所佔用的空間也更加的小。
COMPETITORS：一個集成其餘幾個軟件重要功能的軟件，操做又簡便，是很是吸引用戶。
DELIVERY：採用抽屜界面，將全部的功能模塊放置在抽屜界面中，因爲功能數只有十來個，用戶能夠很容易的找到本身所需的功能，而且還能經過設置將近期用不到的功能隱藏起來，就能更大方便找到所需的功能。各個功能的界面也是儘可能作到簡潔明瞭，提供最佳視覺效果。

• 若是你來領導這個團隊，會有什麼不同？
  • 首先增強團隊凝聚力，使團隊工做更高效，和諧
  • 其次對代碼的規範和質量嚴格把關。
  • 保密，信息安全，用戶信息的保密纔是重中之重。
• 若是你的團隊有5我的, 4個月的時間，你做爲項目經理，應該如何配置角色（開發，測試，美工等等）？
  • 大體分爲美工一人，前端開發一人，後端開發一人，測試一人，項目經理一人。
  • 項目經理在四個月期間中一直負責統籌團隊開發，調研市場需求，制定合理的開發計劃，負責協調團隊隊員合做 。
  • 前15天，負責美工的人員須要在儘可能短的時間內設計出初稿方便其餘人員今早開始設計。先後端人員能夠簡略設計所須要接口，測試人員準備好測試環境和測試數據等。
  • 中期的兩個半月，先後端人員負責好開發出初版，並在美工和測試人員的要求下不斷修改跟進版本。
  • 後期一個月，測試人員不斷的測試查找bug，先後端人員負責修改bug。美工人員能夠修改美化界面，先後端人員負責跟進。項目經理準備好產品上線的工做。
• 描述你的團隊在16 週期間每週都要作什麼，才能在第16周如期發佈軟件，大小里程碑績點設定。

週數	任務	里程碑
1-2	需求分析，初步肯定產品功能，市場調研，完成需求分析報告書.明確分工	需求分析完成
3-4	深化需求分析，制定代碼規範，構建架構，進行原型設計，統一開發環境	原型設計完成
5-8	代碼實現，前端和後端並行。
9-11	先後端接口對接，對各個功能模塊進行測試	Alpha版本發佈
12-13	接受意見反饋，修復bug，完善功能。	Beta版本發佈
14	進行嚴格的性能測試、壓力測試、集成測試等
15	編寫用戶手冊。	用戶手冊完成
16	項目部署，發佈最終版本的產品。	發佈正式版本

• 項目發佈後，有沒有考慮過項目該怎麼部署才能知足需求。依據附錄圖（某校教務處系統的部署）做爲參考，分析16周後你所完成的項目上線須要哪些配套設備(服務器、帶寬、數據庫需求數量與配置) 。
  • 後端服務器：2核4G
  • 帶寬：人均1M
  • 關係型數據庫：SQL Server 數量：3（讀寫分離二、備份1）
  • 緩存數據庫：Redis 數量：1（主備）

第四部分 增量開發設計

• 主界面設置功能
  • 在設置界面加入主界面設置功能，在全局作修改
  • 做爲設置界面下的子功能接入
    
• 校園卡充值功能
  • 設計相應界面，並接入校園卡充值接口
  • 做爲平行於各一級功能的功能模塊接入
  • 原型
    
• 校園精確導航
  • 調用高德地圖或者百度地圖，並在其基礎上細化地圖
  • 做爲平行於各一級功能的功能模塊接入
  • 原型
    
• 校歷瀏覽
  • 設計相應按鈕，接入校歷網頁
  • 做爲平行於各一級功能的功能模塊接入
  • 原型
    

第五部分 答辯總結

• 評估團隊中每一個人對本次做業的貢獻比例

成員	分工	貢獻比
葛亮	測評報告整理	11%
文斌	邏輯框圖製做	12%
黃澤	思惟導圖製做	12%
靜茹	Bug測評	12%
敬甲	ppt製做+演講+博客整理	13%
澤明	軟件規劃	10%
劉浩	採訪	9%
張傑	增量原型設計	11%
朱躍安	軟件建議	10%

• 答辯總結

  • 求出本組的現場答辯得分：去除最高總分，最低總分，求平均分（保留2位小數）

  組號	得分
  1	80
  2	72
  3	76
  4	81
  5	92
  6	80
  7	77
  8	82

  • 去掉一個最高分（92），去掉一個最低分（72），最終得分：79.33

• 答辯質詢

• 第一組

  Q1:增量設計的4個功能中，團隊最看重哪一個功能？

  A1:校歷功能吧~最簡單且最實用

  Q2:增量設計的實現難度如何，須要團隊多少工做量？

  A2:實現難度較高，工做量沒顧及

  Q3:ppt中的bug展現可使用gif進行更生動的展現

  A3:謝謝建議，下次會考慮這種方式

• 第二組

  Q1:是否能夠多增添點PPT的 內容

  A1:能夠，但沒有必要

  Q2:有沒有發現到更多的BUG

  A2:已經所有展現

  Q3:增量開發的難度如何

  A3:實現難度較高

• 第三組

  Q1:大家是否有對用戶進行調研來獲取一些用戶的需求？

  A1:未採起調研

  Q2:大家的具體的人員分工體如今哪？

  A2:在博客和答辯中都有體現

  Q3:校園卡充值功能又沒

  A3:問題沒有描述完整哦

• 第四組

  Q1:展現的資料能夠有些不充分，但願能夠改進

  A1:謝謝建議

  Q2:增量開發的難度有考慮過嗎？

  A2:更可能是從功能去考慮，難度方面考慮較少

  Q3:無

  A3:無

• 第五組

  Q1:增量設計裏校園卡充值功能是否能確保安全性，怎麼肯定學校相關部門願意合做與否？

  A1:增長功能的前提就得保證安全性，不能肯定

  Q2:增量設計裏設計主頁面會不會多餘，把除了課程表之外的模塊作主頁面是否是並不利於自身使用？

  A2:僅表明本身組的意見，很少餘

  Q3:無

  A3:無

• 第六組

  Q1:您好，請問大家有沒有考慮過作採訪環節或者問卷調查？

  A1:採訪環節有作，問卷調查沒有作

  Q2:您好，請問大家有沒有考慮過從不一樣方面進行測試，如利用網上的軟件進行測試？

  A2:沒有，都是本身來測，從效果來看，這個方法接地氣且是個不錯的方法

  Q3:您好，因爲大家ppt內容沒那麼豐富，是否可以考慮從測評報告中再摘取一些內容？

  A3:無

• 第七組

  Q1:是否有考慮採起採訪或調研的方式來聽聽用戶們的想法和建議？

  A1:有采訪，但沒有調研。

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

  A2:有考慮，體如今博客裏，歡迎交流。

  Q3:展現的資料能夠再充分一點，加強說服性。

  A3:謝謝建議

第六部分 我的部分

• PSP

  PSP	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
  Planning	計劃	30	45
  ?Estimate	?估計這個任務須要多少時間	30	45
  Development	開發	0	0
  ?Analysis	?需求分析 (包括學習新技術)	20	30
  ?Design Spec	?生成設計文檔	0	0
  ?Design Review	?設計複審	0	0
  ?Coding Standard	?代碼規範(爲目前的開發制定合適的規範)	0	0
  ?Design	?具體設計	30	30
  ?Coding	?具體編碼	0	0
  ?Code Review	?代碼複審	0	0
  ?Test	?測試（自我測試，修改代碼，提交修改）	0	0
  Reporting	報告	0	0
  ?Test Repor	?測試報告	0	0
  ?Size Measurement	?計算工做量	20	30
  ?Postmortem & Process Improvement Plan	?過後總結, 並提出過程改進計劃	30	45
  	合計	160	225

• 學習進度條

  第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
  4	0	340	5	25	Leangoo工具學習
  5	300	640	15	40	哈希算法、優先隊列、結構體等c++內容複習
  8	0	640	10	50	d代碼方面暫無
  10	0	640	5	55	Github代碼管理學習、leangoo工具完善
  12	100	740	5	60	瞭解了些python，寫博客能力++
  13	200	940	10	70	寫博客繼續++、ppt製做++、錄屏++、頭髮--、睡眠------
  14	100	1040	5	75	寫博客繼續++、ppt製做++、頭髮繼續--