404 Note Found隊 Beta答辯總結

組長博客連接前端

404 Note Foundjava

全部成員

學號 姓名
031602114 胡緒佩(組長)
031602543 周政演
031602444 莊卉
081600410 胡青元
031602627 劉愷琳
031602525 劉一好
031602511 何家偉
031602513 黃鴻傑
031602510 葛家燦
031602539 翟丹丹
031602113 何宇恆

項目宣傳視頻連接

項目宣傳視頻連接:https://www.bilibili.com/video/av38829275python

貢獻比例

工做流程

  • 本次做業因爲在alpha版本階段咱們已經將大部分功能基本實現,因此Beta版本咱們只是對於各個隊員
    負責的部分進行獨立模塊的優化和改進。
  • 而且對團隊協做進行了必定程度的規範化,採用github平臺的方式進行團隊協做。
  • 在Beta衝刺階段不斷對bug進行修復而且在deadline以前好幾天完成apk打包
  • 並作了產品的專業機型測試,以及內測產品的推廣及用戶調查,針對調查結果對咱們的產品進行bug修復和用戶友好性改進,在幾天時間內從1.0.0
    版本更新至1.1.1版本。

組員分工

緒佩: 對備忘錄的狀態之間改變跳轉進行修復改進、對刪除備忘錄的功能bug修復、現場展現PPT答辯、項目的推動、任務的分工android

卉卉: 雲服務器雲端數據的部署,接口的測試和改進,產品的界面優化建議師,產品界面圖標圖片製做git

家燦: 雲服務器雲備份,雲同步部署,接口測試和改進github

青元: 登陸註冊界面的完善,和雲端數據庫的對接,協做完成雲同步和雲備份,引導頁的製做算法

鴻傑: 完成智能提醒天氣分析和用戶行爲分析的功能合併,協做完成備忘錄即將到期的通知顯示,答辯環節提問回答算分彙總處理。數據庫

家偉: 改進和優化短信提醒的時間,內容,對後臺運行程序的嘗試後端

一好: 完成語音輸入的浮標嘗試,PPT製做

宇恆: 完成備忘錄詳情處添加圖片路徑處理,添加能夠拍照的功能

政演: 針對兩個智能進行深度優化,設計實現了基於 LD-Sketch 的雲端數據處理框架,並製做ppt上臺答辯,博客分工以及撰寫

丹丹: 新穎視頻的製做

愷琳: 優化生成壁紙的功能,美化壁紙展現的界面,修復生成壁紙的小bug

團隊貢獻比例:
姓名|貢獻度
---|---
緒佩|11%
卉卉|9.5%
家燦|11%
青元|13%
鴻傑|11%
家偉|6.5%
一好|6%
宇恆|6%
政演|11%
丹丹|9%
愷琳|6%

# GitHub 項目連接

https://github.com/heihuifei/Canmory-of-404-Note-Found

本組 Beta 衝刺站立會議博客連接彙總

Beta 衝刺 (1/7)

Beta 衝刺 (2/7)

Beta 衝刺 (3/7)

Beta 衝刺 (4/7)

Beta 衝刺 (5/7)

Beta 衝刺 (6/7)

Beta 衝刺 (7/7)

燃盡圖

燃盡圖:

原計劃、達成狀況及緣由分析

組員:胡緒佩

原計劃將什麼功能作到什麼程度

  • 原計劃將功能作到能夠正常的添加和刪除備忘錄而且能夠
    友好的堆備忘錄的完成狀態進行跳轉

實際作得怎樣了

  • 實際達到原計劃的完成度,產品能夠正常的進行備忘錄
    的添加和刪除,而且能夠友好的對備忘錄的完成狀態實現
    勾中跳轉。

若是沒有達成,反思是哪些因素影響的

  • 已經達成,後續還會對於其中一些操做性的細節作出優
    化,提升用戶友好性。

組員:周政演

原計劃將什麼功能作到什麼程度

  • 原計劃的智能分析,僅僅是獲取用戶的數據。

實際作得怎樣了

  • 最後的智能分析是一個基於 LD-Sketch 的雲端數據處理框架,用於在雲服務器後臺上處理從用戶傳來的數據。將用戶的數據項看作流的形式,傳到雲服務器的sketch上,而不是將數據項存儲在數據庫中。後端人員只須要設計好用戶端的數據採集,存於字符串中,經過thrift將數據從用戶端傳輸到雲端,並控制多用戶向雲端的併發數據傳遞。在後端將字符串解析成所需的數據,設置到LD-sketch的閾值大小,經過管道存入LD-sketch中,LD-sketch將自動報出超過閾值的數據項。

若是沒有達成,反思是哪些因素影響的

  • 已達成

組員:莊卉

原計劃將什麼功能作到什麼程度

  • 實現本地和雲端數據的傳送

實際作得怎樣了

  • 完成

若是沒有達成,反思是哪些因素影響的

組員:何家偉

原計劃將什麼功能作到什麼程度

  • 原計劃實現短信的分析功能,在收到快遞或出行短信時自動提取關鍵字使前端能顯示相應備忘錄

實際作得怎樣了

  • 達到預計要求,但短信模板還可以進一步優化

若是沒有達成,反思是哪些因素影響的

  • 已達成

組員:黃鴻傑

原計劃將什麼功能作到什麼程度

  • 原計劃實現桌面控件、天氣提醒功能、鎖屏壁紙設置、智能提醒功能

實際作得怎樣了

  • 達到預計要求,可是在打包apk過程當中智能提醒功能出現了些許bug,在後續將完善這些bug

若是沒有達成,反思是哪些因素影響的

  • 已達成

組員:葛家燦

原計劃將什麼功能作到什麼程度

  • 用戶登入註冊:用戶可使用手機號(11位)和密碼(6-16位)註冊本身的帳戶,登入軟件,用戶數據保存在服務器中。
  • 雲備份和雲同步:用戶登入成功以後,打開側邊欄,點擊雲備份,能夠將用戶本地的我的數據,備份至服務器中,;點擊雲同步,能夠將用戶先前備份在雲端的數據,還原至本地。避免因爲手機丟失或者操做不當帶來的不便。

實際作得怎樣了

  • 實際上知足先前構想

若是沒有達成,反思是哪些因素影響的

  • 已達成

組員:胡青元

原計劃將什麼功能作到什麼程度

  • 功能實用,界面美觀。

實際作得怎樣了

  • 功能使用,但界面不夠美觀,以及功能還存在bug。

若是沒有達成,反思是哪些因素影響的

  • 已完成。

組員:劉愷琳

原計劃將什麼功能作到什麼程度

-將備忘錄顯示在頁面上,並能夠選擇本身想要的壁紙。

實際作得怎樣了

  • 能夠作到從圖片庫中選取壁紙並顯示,顯示前五條壁紙

若是沒有達成,反思是哪些因素影響的

  • 任務完成

組員:翟丹丹

原計劃將什麼功能作到什麼程度

  • 知足組員要求,進行情景式視頻剪輯

實際作得怎樣了

  • 已完成

若是沒有達成,反思是哪些因素影響的

  • 任務已完成

組員:劉一好

原計劃將什麼功能作到什麼程度

  • 原計劃實現語音轉文字功能和語音轉文字懸浮窗

實際作得怎樣了

  • 語音轉文字功能實現成功,懸浮窗口實現成功可是沒法進行語音轉文字

若是沒有達成,反思是哪些因素影響的

  • Android 的Service 功能中不能調用有關UI部分的內容。因此即便我實現了懸浮窗,可是不能進行語音輸入的它對於咱們整個團隊來講就略顯雞肋了。

組員:何宇恆

原計劃將什麼功能作到什麼程度

-原計劃將備忘錄編輯界面增長拍照和上傳視頻功能

實際作得怎樣了

-實際上只作了拍照功能,並無實現上傳視頻功能

若是沒有達成,反思是哪些因素影響的

  • android的edittext不支持多媒體插入,我在事先沒有作好調查

Beta 版本展現

直接發佈可用 Beta 版本,並提供使用說明。

記憶罐頭APK網盤地址:https://pan.baidu.com/s/1AsbRgRbkdrx6Qz_dnpv_Sw

功能:登錄註冊

使用說明

  • 輸入11位手機號做爲帳號,輸入4到10個字母或者數字做爲密碼
  • 輸入註冊過的手機號和密碼便可登錄

功能:語音輸入

使用說明

  • 點擊語音輸入

  • 說出要造成備忘的內容

  • 語音輸入生成備忘

功能:新建或修改備忘錄

使用說明

  • 根據提示輸入標題,更改到期時間,調整優先級,添加詳細內容,以及在更多設置中按照提示選擇便可。

功能:智能分析

使用說明

  • 咱們的智能分析是一個基於 LD-Sketch 的雲端數據處理框架,用於在雲服務器後臺上處理從用戶傳來的數據。將用戶的數據項看作流的形式,傳到雲服務器的sketch上,而不是將數據項存儲在數據庫中。後端人員只須要設計好用戶端的數據採集,存於字符串中,經過thrift將數據從用戶端傳輸到雲端,並控制多用戶向雲端的併發數據傳遞。並在後端將字符串解析成所需的數據,設置到LD-sketch的閾值大小,經過管道存入LD-sketch中,LD-sketch將自動報出超過閾值的數據項。

  • 智能分析主要用於後臺的數據處理,不向用戶開放。

智能分析的部分特色

線速處理數據
可以高速處理從邊緣到雲端的數據,LD-sketch原是用於數據中心的高速流量測量,本產品用戶端到雲端的數據量遠遠小於數據中心,能夠輕鬆完成線速數據處理。

佔用極少空間

儘可能減小空間的開銷,不使智能分析成爲負擔。sketch的基本思想是將數據壓縮到較小的空間內,在可接受的偏差估計下完成數據採集,利用LD-sketch能夠大大減小數據存儲佔用的空間。

通用處理框架

使邊緣到雲端的數據處理框架具有良好的通用性。咱們設計的框架無需針對每一種數據都設計專門的處理方法。每一條數據都以字符串的形式傳輸,只要在後端設計好字符串的格式處理便可。

簡化對接操做

省去數據庫處理過程,簡化處理流程。咱們的數據處理框架中,繞過了數據庫,避免數據在數據庫中大量的 IO 操做,下降計算開銷,同時不須要數據庫管理員對數據處理,簡化了對接操做。

功能:智能提醒

使用說明

  • 打開智能提醒功能開關,根據引導設置權限,回到主界面再次打開智能提醒開關

功能:天氣提醒

使用說明

  • 打開天氣預報功能開關

功能: 雲備份 雲同步

使用說明

  • 未聯網狀況下只要不退出登陸可正常使用該帳號的本地備忘功能。
  • 雲備份:在聯網狀況下,點擊雲備份,能夠將用戶本地的我的數據,備份至服務器中,避免因爲手機丟失或者操做失誤帶來的不便。
  • 雲同步:在聯網狀況下,點擊雲同步,能夠將用戶先前備份在雲端的數據,還原至本地。

功能:桌面控件

使用說明

  • 添加桌面控件

功能:壁紙預覽





使用說明:選擇圖片庫的一張圖片,用戶能夠自由選擇字體顏色和字體大小,點擊預覽能夠預覽鎖屏效果,點擊生成壁紙
即可以生成鎖屏壁紙進行展現

得分

收集其餘組對本組提出的問題,並回答

第一組回答:(爸爸餓了隊)

1. 在早上的答辯中沒有聽懂基於LD-Sketch的用戶行爲統計算法能否詳細解釋一下?

答:感謝提問!咱們的智能分析是一個基於 LD-Sketch 的雲端數據處理框架,用於在雲服務器後臺上處理從用戶傳來的數據。將用戶的數據項看作流的形式,傳到雲服務器的sketch上,而不是將數據項存儲在數據庫中。後端人員只須要設計好用戶端的數據採集,存於字符串中,經過thrift將數據從用戶端傳輸到雲端,並控制多用戶向雲端的併發數據傳遞。並在後端將字符串解析成所需的數據,設置到LD-sketch的閾值大小,經過管道存入LD-sketch中,LD-sketch將自動報出超過閾值的數據項。

若有興趣,歡迎討論 :)

附:
對於sketch的有關算法,能夠查看這篇介紹:https://www.sdnlab.com/22685.html

關於LD-sketch的算法細節,能夠查看這篇論文:https://ieeexplore.ieee.org/document/6848076/

2. 是否考慮精簡界面的元素數量,給用戶更簡潔的觀感?

答:感謝提問!咱們在備忘展現的主界面的未完成、到期未完成、已完成三個列表都可點擊使其隱藏。咱們認爲已經儘量的精簡了界面的元素數量,使其在知足用戶需求的狀況下儘可能簡潔。若是有什麼好的建議歡迎與咱們交流。

3. 應用的功能較可能是否考慮作一個用戶引導方便新用戶瞭解功能?

答:感謝提問!咱們的app在用戶第一次安裝時會提供一個引導頁來介紹特點功能。

第二組回答:(拖鞋旅遊隊)

1. 對於本項目,在後續的bug修改以及推廣方面有哪些想法

答:感謝提問!咱們項目組負責開發部分的成員會繼續修改bug,bug修改完善後,會投入市場運營,線上線下會同時宣傳,爭取吸引更多用戶的使用。

2. 在之前的課上有提過大家不用語音輸入的,如今怎麼也支持語音輸入了

答:感謝提問!由於咱們有多餘的時間和足夠的能力,多多益善嘛,後續就添加了這個功能。

3. 有沒有考慮本項目的某些地方其實產生了重疊從而對項目進行部分的增長或刪除

答:感謝提問!目前尚未發現功能嚴重重疊的現象,但後續在推廣過程當中會根據用戶反饋現象,對功能進行增刪改。

第三組回答:(彳艮彳亍隊)

1. 大家有沒有作過關於界面美觀或是邏輯設計的調查或測試?

答:感謝提問!在問卷中咱們有這樣的選項。

2. 語音輸入的結果精度高嗎?語音輸入功能是調用什麼實現的嗎?

答:感謝提問!語音輸入是調用百度的接口,精度在咱們的能力範圍確保語音輸入的準確度。

3. 若是每一項提示須要填寫這麼多項的話,會不會太麻煩?讓用戶體驗下降,是否考慮簡化(目前我的用來以爲挺好,須要提醒事項多的時候沒有測試過,因此不太清楚)

答:感謝提問!咱們的備忘錄並非對每一個選項都要設置,最簡便的方法是語音輸入,直接轉成備忘錄的標題。

第四組回答:(火箭少男100隊)

1. 爲何沒有展現智能分析?僅從口頭描述來講,是否僅是上傳各app的使用時長給服務器而已呢?

答:感謝提問!

  • 第一,智能分析是一個運行在後臺的功能,不對用戶開放。
  • 第二,app未推廣,缺乏實際的用戶數據。
  • 第三,智能分析的演示過程時間較長,十五分鐘的展現時間沒法完成。
  • 第四,但願提問小組能夠更認真一點聆聽演示報告,有疑問,至少提問前看一下ppt上的內容。如果僅上傳app使用時長給服務器,又何足道哉?咱們的智能分析是一個基於 LD-Sketch 的雲端數據處理框架,用於在雲服務器後臺上處理從用戶傳來的數據。將用戶的數據項看作流的形式,傳到雲服務器的sketch上,而不是將數據項存儲在數據庫中。後端人員只須要設計好用戶端的數據採集,存於字符串中,經過thrift將數據從用戶端傳輸到雲端,並控制多用戶向雲端的併發數據傳遞。在後端將字符串解析成所需的數據,設置到LD-sketch的閾值大小,經過管道存入LD-sketch中,LD-sketch將自動報出超過閾值的數據項。
  • 第五,咱們已在羣裏上傳程序源碼,框架的可行性也早已驗證過,歡迎測試。
  • 第六,如下是測試效果。咱們從服務器端收到input,每條字符是一個數據項,設置閾值爲100,在修改接口以後,同時將數據流用管道傳入LD-Sketch,下圖是後臺中sketch的數據存儲使用狀況(爲了方便顯示,將行設爲20,實際中並不是如此),而且能夠看到,LD-sketch迅速並正確地報出超過閾值的key。

2. 在以前的展現中,大家反覆提到軟工課不必作過高大上的技術,爲何此次展現又加了兩個「智能」模塊呢?

答:感謝提問!這個問題分兩點回答。

  1. 咱們從始至終都是有四個核心其中包括兩個智能,但願提問小組能夠更認真一點聽每一次的演示,至少在提問以前也應該看一看被提問組提交的材料,這是對被提問方最基本的尊重。
  2. 咱們所說的沒有必要作過於高大上的功能是在沒完成基礎軟件工程的前提下,固然若是完成了加上是徹底OK的,相比於那個咱們是針對於alpha版本某些組甚至沒有完成他們的軟件就一直吶喊着那些聽起來高大上的算法卻只有PPT產品提出來的觀點,在beta版本已經完成基礎軟件添加高大上的功能有何不可呢?

3. 大家認爲最核心的功能是什麼呢?爲何?

答:感謝提問!咱們認爲最核心的功能是鎖屏壁紙展現;壁紙展現可以最直觀的讓用戶看到本身定下的備忘錄,改變傳統的備忘錄形式,作到真正的「備忘」。

第五組回答:(精雕細課夢之隊)

1. 語音輸入的功能很好,請問語音識別的準確率如何?

答:感謝提問!其實以前就有回答過相似的問題,咱們使用的是百度語音接口,準確率和使用者的口音和使用環境也有關係,正常使用的時候準確率是很可靠的。

2. 請問有沒有打算beta版本以後從哪些方面來進一步完善?

答:感謝提問!優化各個頁面的邏輯,使得頁面更加人性化。還有就是對用戶的APP使用狀況進行分析,以提供更好的服務。

3. 請問大家會用什麼來吸引用戶、留住用戶?

答:感謝提問!咱們會提供個性化的設置,優美的界面,各類方便實用的功能其實就已經很吸引人了。

第七組回答:(第三視角隊)

1. 仍存在一些bug未解決,演示時,智能讀取短信加入待辦事項的功能彷佛出了問題,找到緣由了嗎?

答:感謝提問!找到緣由了,智能讀取短信時數據庫讀寫出了問題。咱們已經進行了解決。

2. 待辦事項,進行中事項與已完成事項的ui交互邏輯不夠友好,事項的相互轉移操做不是很明晰,能夠再進行優化嗎?

答:感謝提問!咱們會在後續更新中進行優秀,感謝您的建議。

3. 智能分析功能能夠作一些展現嗎?

答:感謝提問!咱們會再對這方面進行優化,按照計劃會在最終演示的時候進行展現。

第八組回答:(小白吃隊)

1. 大家組的人數相對其餘組比較多,可否簡述一下大家的分工和工做時間?

答:感謝提問!分工已經在ppt很明確的指出了,但願該組組員再看一下;工做時間爲每週二、五、6晚上9點至11點,值得一提的是,在本週三前,本組已經大體完成了全部核心功能,併發布了app1.0.0版本,並作了許多改進,現在已經到了1.0.9版本!

2. 爲何會出現現場演示中的錯誤,以後有無尋找緣由並進行修改?

答:感謝提問!會在現場演示中出現錯誤,一方面是由於前期確實是沒有準備好,另外一方面是由於沒有真正彩排過,沒有到實地演練一遍!

3. 大家項目的功能已經十分完善了,可否簡述一下後續的製做計劃呢

答:感謝提問!咱們項目功能雖然比較完善了,可是還有一些細節處理的不夠友好,還有待改進,另外會針對於咱們的智能性方面作出更進一步的優化。再者咱們將會對咱們的產品作一個市場推廣並根據用戶反饋迭代產品,推廣迭代過程還很漫長。後續計劃將由pm制定!

我的PSP

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

我的學習進度條

第N周 新增代碼(行) 累計代碼(行) 本週學習耗時(小時) 累計學習耗時(小時) 重要成長
1 0 0 5 5 閱讀《構建之法》,重點了解了 NABCD 模型
2 0 0 10 15 找到了適合團隊的原型工具,以及如何並行操做
3 68 68 6 6 python字符處理複習、爬蟲學習
4 78 146 7 13 java爬蟲學習
5 194 340 6 19 單元測試設計
6 0 340 10 29 需求報告撰寫
7 0 340 5 34 Alpha博客撰寫
7 0 340 3 37 Alpha2博客審查
7 0 340 3 40 Alpha3博客審查
7 0 340 2 42 Alpha4博客撰寫
7 50 390 10 52 構思了隨機算法、附加功能算法和具體思路,完成撰寫敘述
7 0 340 2 54 Alpha5博客撰寫
8 0 340 2 56 Alpha6博客撰寫
8 0 340 2 58 Alpha7博客撰寫
8 0 340 2 60 Alpha8博客撰寫
8 0 340 2 62 Alpha9博客撰寫
8 0 340 2 64 Alpha10博客撰寫
9 0 700 4 68 測試文檔撰寫
9 0 700 2 70 Beta1博客撰寫
10 300 1000 2 72 Beta2博客撰寫
10 200 1200 2 74 Beta3博客撰寫
10 300 1500 2 76 Beta4博客撰寫
11 300 1500 2 78 Beta5博客撰寫
12 0 1500 2 80 Beta6博客撰寫
13 200 1700 5 85 設計實現new idea
14 0 1700 2 87 Beta7博客撰寫
14 0 1700 2 89 Beta總結博客撰寫
14 400 2100 6 95 完成智能分析

後續討論

組長博客連接:http://www.javashuo.com/article/p-oyfpfhvn-hk.html

相關文章
相關標籤/搜索