做業連接html
組長博客連接前端
本次測試報告android
本次評審表ios
總體深藍配淺灰的色調,第一眼看起來並不會有違和感,主界面課表頁課程分塊的底色多樣,可經過刷新換色,直觀漂亮。數據庫
功能上基本知足學生羣體的必備需求,例如課表與成績的查詢,圖書館的便利服務,空教室的查找,實驗預定等等,同時結合融入易班工具與期末考啦等等其餘軟件,造成一個整合平臺,這一點足以吸引大多數本校學生羣體。後端
同時單獨提一下該軟件的蘋果客戶端,增設一鍵評議與二手市場工具等功能,功能雖小卻給人帶來至關便利的用戶體驗。緩存
按照描述的bug定義,找出至少兩個功能性的比較嚴重的bug安全
bug曝光:
服務器
bug曝光:
微信
bug曝光:
bug曝光:
假設大家團隊須要開發這套系統,須要注意哪些方面(架構、部署運維、微服務等)
可採起微服務的軟件架構方式,即將總體軟件應用構建成一系列按業務領域劃分模塊的、小的自治服務,這些自治模塊會處理他們本身的數據、執行不一樣的功能。這種服務分離的方式很大程度上使得總體能夠輕易的構建、修改並拓展整合。獨立開發、獨立部署、錯誤隔離等,這些都很是適合於整套系統一個健壯的開發過程。
介紹採訪對象的背景和需求(他們有沒有用過相似的APP,除了現有的功能還有別的需求麼)
一位福州大學大三的學生。他目前在使用福大教務通和易班。他除了現有的功能沒有其餘更多的需求。
描述用戶使用這個產品的過程, 用戶的問題解決了麼?軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗方面有問題麼?
使用過程當中他認爲該軟件的界面比福大教務通要好看一些,福大教務通的功能它基本都有,並且還集成了其餘的小功能,不用再去下載多餘的軟件。十分的方便。
用戶對產品有什麼改進意見?
主界面的懸浮按鈕太靠下了,不容易按到。沒法經過向右滑動的方式打開側邊欄,使用起來不太習慣。在使用一項側邊欄的其餘功能時沒法經過返回鍵回到主頁面。
結論:通過這麼多工做,你必定有充分的理由給這個軟件下一個評價,請選擇一個結論
很是推薦
介紹採訪對象的背景和需求(他們有沒有用過相似的APP,除了現有的功能還有別的需求麼)
一位福州大學大三的學生。他目前在使用福大教務通。他除了現有的功能沒有其餘更多的需求。
描述用戶使用這個產品的過程, 用戶的問題解決了麼?軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗方面有問題麼?
這個軟件的功能很豐富,基礎的功能與福大教務通使用的感受一致,界面會更好一些,在課表的顯示上能夠將未開始或以結束的課以灰色狀態顯示,這個功能很不錯。
用戶對產品有什麼改進意見?
對歷年卷這個功能但願裏面的內容能更新更豐富一些。
結論:通過這麼多工做,你必定有充分的理由給這個軟件下一個評價,請選擇一個結論
很是推薦
估計大概要3個月左右,有專業的UI支持能夠省去較多邏輯界面的問題,可是因爲系統功能較多,須要爬取的數據量比較大,和原應用涉及的關係也比較多,所以開發和溝通週期應該不會過短,可是應該也會有一些現成接口,因此估計3個月左右。
與福大教務通相比,福大助手的操做比較簡潔,可是可視化稍弱。
福大助手較期末考啦功能會比較少一些。
易班的界面和功能比較美觀和齊全,可是邏輯不如福大助手簡潔和清晰。
福大圖書檢索系統加載速度快,可是不如福大助手界面簡單。
類似APP或網頁端:福大教務通、課程盒子、期末考啦、福大易班、福大圖書檢索系統、福大大學物理實驗選課平臺、福大教務處官網等。
相比較下,福大助手的頁面簡潔,邏輯清晰,加載快,可是功能不齊全,美觀性較弱。
評份內容 | 滿分 | 團隊打 | 評分理由 |
---|---|---|---|
用戶體驗 | 10 | 8 | 一站式的服務十分便捷,但存在少許bug |
UI界面 | 10 | 7.3 | 界面簡潔,邏輯清晰,但圖標等美感較差 |
核心功能 | 10 | 8.5 | 功能較多,速度快,可是子模塊功能不夠齊全 |
若是你是項目經理,如何提升從而在競爭中勝出?
提升產品的穩定性。儘可能減小登陸錯誤的狀況發生,避免出現某個功能突然沒法使用的狀況發生。
目前市場上有什麼樣的產品了?
福大教務通和福大易班。功能基本上差很少,都是能夠查成績,考試安排和課表。
你要設計什麼樣的功能?
成績詳情。能夠查看每門課的平均分和和最高分,瞭解本身的學習狀況。
爲什麼要作這個功能,而不是其餘功能?
從學生的需求出發,成績是他們所關心的。而出於競爭心理,他們也會有了解你們整體考試狀況的須要。
爲何用戶會用你的產品/功能?
由於學生都是比較關心成績的,不只關心本身考得如何,也會想知道你們的狀況,知道本身處於什麼樣的水平。
Need 需求:
對於以上的創新,咱們不由能夠想到,會有同窗使用「福大助手」查當作績時,不只僅是想要看到一堆數據,更多的要查看到圖表的類型,從而可以更清晰的查看到自身成績所處的位置。
同時對於過於單一的界面形式,當功能過於多時,但願界面能夠形式多樣化一些。Competitors 競爭:
針對市面上的相似產品,咱們主打集成功能型的產品。一款產品就能夠知足用戶對於諸多功能的需求,咱們的產品雖然功能衆多,可是功能使用方面卻不遜色於單一功能的產品。Delivery 推廣:
首先,將咱們的方案給客戶審覈,若審覈經過,咱們將進行推廣,能夠配合客戶的方法進行推廣,線上和線下進行推廣。線上,如:微信、微博、推特等App以及電視廣告等進行推廣;線下,如:傳單宣傳、講座宣傳等措施進行。若是你來領導這個團隊,會有什麼不同?
若是讓我來領導這個團隊,我應該會比較注重團隊的規範化和制度化。好比時間表的成立,哪一個時間該完成什麼事情強制的列出來,而且比較詳細的對隊員要求工做,而不是等到截止日期以前纔來完成。並且技術文檔的創建也很重要,好比遇到的技術上的bug有同窗解決了,那麼就更新到文檔裏,遇到一樣問題的同窗能夠進行查閱,從而下降學習成本。
任務 | 人數 | 所佔時間比 |
---|---|---|
後端代碼研發 | 2 | 40 |
美工和界面 | 1 | 30 |
測試 | 1 | 20 |
靈活調整部分(統籌和監管等) | 1 | 10 |
一我的負責監管和統籌整個項目進程,合理把握產品的研發方向;兩我的完成主要的後端代碼的開發;一我的負責界面和美工;一個同窗完成測試。具體狀況還應當根據團隊的實現能力來進行,根據完成的質量和效率進行調整。總體時間比例:開發和測試總體佔60%;美工和界面的實現佔30%;剩餘的10%屬於靈活時間的調配,可根據具體狀況增長或減小。
週數 | 任務安排 |
---|---|
第一週 | 小組第一次會議,將接下去的工做列表化和明確化;討論總體的功能佈局;分配任務。 |
第二週 | 小組進行考察,考察市面上相似的產品,並對其進行產品評估,列出相似產品的優缺點,爲接下來的研發作好準備。 |
第三週 | 進行界面的設計和佈局的規劃。 |
第四周至第七週 | 進行產品後端的代碼研發,同時界面和美工組進行相應的調試以及跟後端組進行會談,改進原始方案。 |
第八週至第九周 | 測試人員進行產品測試,此時前端、後端、測試人員一齊進行協做。 |
第十週至第十五週 | 針對前期遇到的問題每一個小組進行改整,繼續完善產品。 |
第十六週 | 靈活時間,繼續完善產品,(養成在deadline前完成的好習慣。)等待最終的發佈。 |
應用服務器配置:2 核 2G * 12
後端服務器配置:16 核 64G * 4
關係型數據庫數量:12(備份 4)
緩存數據庫數量:6(備份 2)
網站安全性:WAF、DDOS
想必都有用過一鍵評議功能,期末查成績的時候或者選課的時候還要逼迫咱們評議,雖然福大助手的一鍵評議對學生很友好,可是評議的分數都是隨機的,對於那些你喜歡的老師就不是很友好,因此但願在一鍵評議功能上新加一個能夠選擇分數的功能。
線上打印資料功能:線上打印ppt或歷年卷,線下到店取或者出點小錢線下送貨。
選課功能:如今爲止好像任何一個軟件都沒法實現選課功能,選課還要登錄教務處網上很麻煩,但願能增長一個選課功能。
在評議界面加入分數選擇,能夠設置總體分數,也能夠爲每位老師設置分數。
這個功能實現起來須要成本,可是也是可以賺錢的主要功能。實現上分爲線上與線下兩部分。
線上:在資料的下載界面上新增打印資料功能,便可跳轉到設置界面,設置打印的格式,如單面雙面、份數、一面多頁、是否裝訂、是否送貨上門、以及收件地址等功能,還能夠新加選擇商家功能,設置完畢後跳轉支付頁面,支付成功後商家接單處理。
線下:能夠自立門店,與別的商家競爭,也能夠與校內商家合做,從中賺錢利潤。
這個功能須要自立門戶,在主菜單中加入選課功能,相關的選課操做和教務處一致。
此功能在一鍵評議功能上新增,系統自動評議時獲取分數的數據從用戶的輸入欄上獲取,而不是隨機獲取,對於用戶未輸入分數的欄目仍是使用隨機數。
此功能在歷年卷功能下接入,在用戶下載文檔界面選擇在線打印,隨後跳轉到在線打印設置界面。
此功能從主界面加入,選課信息要從教務處調入,主要設計好符合人性的選課界面,將學生選完的信息返回教務處。
姓名 | 得分(百分制比例%) |
---|---|
柯奇豪 | 24 |
蔣雄 | 21 |
黃志銘 | 12 |
黃毓明 | 7 |
林翔宇 | 8 |
丁水源 | 8 |
楊禮亮 | 12 |
林淇 | 8 |
小組 | 評分 |
---|---|
第一組 | 74 |
第二組 | 82 |
第三組 | 78 |
第四組 | 77 |
第五組 | 72 |
第六組 | 71 |
第七組 | 72 |
第八組 | 79 |
最低分 | 71(第六組) |
最高分 | 82(第二組) |
有效分數 | 74,78,77,72,72,79 |
最終平均得分 | 75.4 |
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: 這個咱們當時沒有想過這方面的,也沒有得到這些帳號的渠道。
PSP | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | ||
· Estimate | · 估計這個任務須要多少時間 | 0 | 0 |
Development | 開發 | ||
· Analysis | · 需求分析 (包括學習新技術) | 0 | 0 |
· Design Spec | · 生成設計文檔 | 0 | 0 |
· Design Review | · 設計複審 (和同事審覈設計文檔) | 0 | 0 |
· Coding Standard | · 代碼規範 (爲目前的開發制定合適的規範) | 0 | 0 |
· Design | · 具體設計 | 20 | 10 |
· Coding | · 具體編碼 | 180 | 240 |
· Code Review | · 代碼複審 | 0 | 0 |
· Test | · 測試(自我測試,修改代碼,提交修改) | 10 | 20 |
Reporting | 報告 | ||
· Test Report | · 測試報告 | 0 | 0 |
· Size Measurement | · 計算工做量 | 10 | 10 |
· Postmortem & Process Improvement Plan | · 過後總結, 並提出過程改進計劃 | 10 | 10 |
合計 | 200 | 260 |
第N周 | 新增代碼(行) | 累計代碼(行) | 本週學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
---|---|---|---|---|---|
10 | N | N | 12 | 200 | 學習微信相關接口使用 |