做業博客連接前端
團隊會議紀要連接java
組長博客連接python
視頻連接mysql
組隊後的團隊項目的總體計劃安排
項目logo及思惟導圖
項目logo
logo含義:由一個裝滿備忘錄、便籤的罐頭和一隻貓組成,白綠色調映託咱們備忘錄的清新簡便,鈔票似的備忘錄便籤表明記憶像金錢同樣珍貴,罐頭上的Canmory是由記憶罐頭:memory can提取組合而成,象徵着記憶只有存在罐頭裏纔不會遺忘。可愛的貓爲咱們的備忘錄添了幾分生趣。linux
思惟導圖
產品思惟導圖
產品思惟導圖-引導
直觀充分的展現了記憶罐頭的幾大核心新穎的功能:語音輸入、生活助手、快遞訂單短信識別、生活助手天氣分析、APP使用行爲分析。android
產品思惟導圖-後端數據處理、存儲
後端數據處理、存儲主要分爲兩部分,存儲在雲端的數據和存儲在android手機的數據。用戶備忘數據默認保存在本地,註冊帳號以後可對數據進行雲備份。手機端數據庫使用sqlite,服務器端數據庫使用mysql。後端人員用java設計api接口以便前端調用數據。雲備份功能的實現基於雲服務器和網絡協議實現。正則表達式
產品思惟導圖-短信識別
短信識別大致有四個步驟:sql
- 獲取短信讀取權限
- 讀取新短信內容
- 分析短信內容
- 將短信中需識別的關鍵信息返回給後端使用。
- 獲取短信權限:能夠直接使用現有的安卓代碼。
- 讀取新短信內容:考慮經過監聽短信廣播或是經過觀察者對象監聽短信數據庫變化來實現。
- 分析短信內容:考慮經過發信人號碼和短信內容兩方面來分析短信。
- 發信人號碼方面,能夠考慮經過網絡上爬取快遞公司和售票網站的號碼來對短信分類;
- 短信內容方面,考慮經過自行撰寫正則表達式匹配短信內容,達到對短信分類和獲取所需信息的要求。其中發信人號碼不是必要的途徑。
- 返回短信關鍵信息給後端:對於快遞短信,返回快遞公司名稱,取件時間,取件地點和取件所需這四類信息;
- 對於車票短信,返回發車時間,上車地點,目的地和所需物件這四類信息。最終返回一個含有所需信息的完整字符串給後端。
產品思惟導圖-智能分析
分爲APP使用分析和天氣分析兩部分,用戶都可以自定義兩個功能。
其中APP使用分析主要以通知的形式提示用戶使用遊戲軟件時間過長等
事項,天氣分析主要以通知的形式提示用戶天氣情況及相應措施。數據庫
產品思惟導圖-壁紙生成
用戶可自定義該功能,自定義部分包括壁紙形式、顯示模式和備忘錄內容等,該功能主要是顯示5或10條備忘錄於鎖屏或桌面小控件。
產品思惟導圖-註冊界面
用戶在最開始能夠經過手機號註冊使用咱們的產品,用戶註冊的驗證方式是手機動態驗證碼,而且註冊設置的密碼應當符合要求。
產品思惟導圖-登陸界面
用戶在登陸界面能夠經過手機號登陸使用咱們的產品,登陸方式爲經過手機的動態驗證碼進行驗證,而且提供記住帳戶密碼提高用戶體驗,避免每次登錄都須要輸入密碼。
產品思惟導圖-使用1
產品思惟導圖-使用2
產品思惟導圖-語音輸入(語音識別)
App經過調用百度語音的api來實現語音轉文字的功能。
產品思惟導圖-語音輸入(浮窗按鈕)
使用浮窗按鈕來進行對備忘錄快捷的控制,包括了語音備忘,壁紙開關等功能。浮窗按鈕主要經過調用Android的WindowManager類來實現
評審表格設計
評審表格地址
分工與貢獻分評定
撰寫需求規格說明書的工做流程
將每一個部分分配到我的初步完成,而後將你們完成的各個模塊內容進行初步彙總和精細彙總最後團隊共同討論精修整理的流程。需求規格說明書中比較複雜繁瑣的部分分配兩我的共同完成,而且分配的任務都和組員所擔任的角色關係緊密,好比後端負責接口以及驗收驗證標準部分,前端負責原型。
答辯總結
求出本組的現場答辯得分:去除最高總分,最低總分,求平均分(保留2位小數)
收集其餘組對本組提出的問題,並回答(每少回答一點,該項得分扣除5%,扣完爲止)
第一組(爸爸餓了隊)
- 項目的原型設計中用戶新建備忘錄的頁面有很是多的選項可供用戶選擇,這是否會增長用戶的學習和使用成本?
- 答:你好,其實不會的,大多數可選項就如同不少軟件註冊時,能夠選擇不填寫的,咱們在後端有設置默認值,用戶須要填寫的只是標題等一些必填項。如果用戶須要對於某個備忘進行詳細設置,我相信只要進行了幾波操做以後,會很快駕輕就熟的。
- 對諸如快遞信息、訂單信息的備忘由應用獲取,如何保證其餘應用的訂單信息可以被應用讀取到?
- 答:你好,咱們主要作的是短信提醒,經過Android內部的短信接口,將獲取的通知短信內容存儲進數據庫,進行分析以後,生成備忘內容的。
- 產品添加了分析用戶平常行爲並向用戶提醒的功能,這一功能是否已經超出一款備忘錄軟件的功能範疇,應該從新考慮產品定位?
- 答:你好,這項功能是咱們的拓展功能,如今主要方向是對於用戶的軟件運行進行監控分析,好比打開app次數,時間等,用戶使用beiwangapp實際上是爲了更好的規範本身,咱們提供的這項功能,可以讓用戶看到本身使用手機的狀況,進而作出更好的規範,和產品的定位其實並不衝突。若是不須要這個服務的話,用戶也能夠考慮關閉這個功能的。
第二組(拖鞋旅遊隊)
- 競品較多,而且大部分的人使用手機自帶的備忘錄便知足了自身的需求了。
- 答:感謝提問!咱們的備忘錄主要提出的一個便捷和智能的概念。市面上可以便捷的產品可能不夠智能,智能的產品可能不夠便捷,又智能又便捷的產品更是少之又少。而咱們的目標就是作一個這樣子的App。根據咱們前期的市場調研和問卷調查,市面上確實沒有相似的產品,而且在向被調查者說明了咱們的特色後絕大多數被採訪者願意使用咱們的產品。
- 生成的壁紙可能會被App擋住,不便於查看。
- 答:感謝提問!咱們的App在鎖屏部分使用壁紙,在桌面部分使用小控件,我方的排版會將這兩方設計得不會影響用戶的體驗。
第三組(彳艮 彳亍隊)
- 能否針對懶癌用戶設計一套模板,對於一些簡單的日程直接一鍵生成?
- 答:感謝提問!你提問的關於模板設計的問題咱們小組沒有考慮過,可是這確實是一個不錯的創意,咱們小組在後續的開發將會考慮迭代這個功能。
- 能夠在不註冊的狀況下使用嗎?
- 答:感謝提問!咱們的記憶罐頭app支持無聯網操做,即用戶能夠在不註冊登陸的狀況下使用。
- 有沒有合理的插入廣告方式?可讓用戶欣然接受的
- 答:感謝提問!插入廣告若是想讓用戶可以接受確定要基於不影響用戶操做的狀況下,所以能夠考慮用通知的方式(簡單的文字介紹)來插入廣告,不過咱們的記憶罐頭app暫時沒有插入廣告的想法,由於咱們的app始終追求用戶的體驗至上,
廣告或多或少會影響用戶的體驗。
第四組(火箭少男100隊)
- 缺乏更加創新型的idea
- 答:你好!感謝你的提問。咱們的備忘錄實現語音輸入、自動生成備忘壁紙和鎖屏以及可以分析用戶行爲。在創新性來講,咱們以爲目前沒有一款備忘錄比得上咱們。
- 缺乏詳細的分工細則
- 答:你好!感謝你的提問。咱們的分工細則十分詳細,詳情請你看咱們的ppt最後一頁。同時咱們是惟一在ppt中放入這麼詳盡的分工的隊伍。
- 功能佈局合理性尚缺
- 答:咱們力求給用戶展現最簡潔的界面,或許有些許功能佈局不合理,會在後續更多考慮這一問題。
第五組(起牀一塊兒肝活隊)
- 有些備忘錄的優先級可能會隨時間改變,好比做業剛佈置時優先級低,截止前優先級高,這種狀況怎麼處理?
- 答:感謝提問!若是用戶對於備忘錄有設置完成時間,那咱們的優先級將會進行對應的調整,好比,根據deadline轉換成相應的優先級加入,使得能夠動態改變一些活動的優先級。
- 若是有足夠多優先級同樣高的備忘錄致使一個屏幕沒法根據優先級排列而不夠顯示怎麼辦?
- 答:感謝提問!咱們支持用戶進行自主選擇展現的備忘信息。可是若是有多個優先級相同而用戶沒有選擇的話,咱們優先展現deadline近的。
- 請舉一個沒有手動設置備忘錄而自動提醒的例子?
- 答:感謝提問!咱們向用戶申請權限以得到讀取短信的能力,在提取短信內容的狀況下,咱們進行分析,好比車票,快遞等的信息,將其加入用戶的備忘錄,以提醒用戶。
第七組(第三視角隊)
- 備忘錄中的待辦事項時間順序上衝突時,事務排布優先級設定有什麼邏輯設定嗎?
- 答:感謝提問!咱們備忘錄中每一個待辦事項優先級能夠設爲高,中,低三種;用戶未手動修改時默認爲中的優先級。
- 備忘錄壁紙覆蓋掉原壁紙時,在關閉備忘錄壁紙功能後,原壁紙能從新回來嗎?
- 答:感謝提問!咱們的軟件遵循迭代原則,而在咱們備忘錄的阿爾法版本中沒有設置這個功能;這一建議很好,但咱們認爲加上這一功能後的工做量會超出團隊的承受範圍,在後續的版本迭代中咱們團隊會再進行討論考慮是否加入這一功能。
- 備忘錄的鎖屏和壁紙顯示是否設置有安全保護措施?
- 答:咱們備忘錄容許用戶自行設置是否在鎖屏和壁紙顯示,有這方面顧慮的用戶能夠關閉這些功能。
第八組(小白吃隊)
- 雲備份保存在用戶賬號上,但若是須要轉移到不一樣賬號上,或者不使用雲備份轉移到其餘設備上如何實現?
- 答:咱們的 app會設置默認狀況,若是想要建議版本的備忘,能夠造成只有標題的形式。
- 有云服務這個功能麼?好比想找到好久以前的一條備忘可是換手機了怎麼辦?
- 如何盈利?
第九組(我頭髮呢隊)
- 雲備份保存在用戶賬號上,但若是須要轉移到不一樣賬號上,或者不使用雲備份轉移到其餘設備上如何實現?
- 答:感謝提問!首先,備忘錄自己即是週期短,內容簡的特色,所以用戶備忘錄的內容不會過多,因此若用戶想要轉移到不一樣的帳戶徹底能夠經過手動從新輸入備忘錄。其次若用戶不想要使用備忘錄的雲備份功能能夠選擇不登陸使用咱們的產品,依舊可使用咱們的基礎備忘錄的功能毫無大礙。第三,用戶經過手機註冊登陸咱們的產品,所以若用戶常常更換手機號碼、多個不一樣帳號都不嫌麻煩,那麼咱們相信手動輸入幾條備忘錄用戶必定也不會嫌棄麻煩。
- IOS權限嚴格,難以在IOS上實現。其需求對象以工做黨爲最多。然而工做黨且有不少事情須要備忘的羣體,通常會使用IOS來減小手機使用系統上的繁瑣。如何解決?
- 答: 感謝提問!首先但願您方能夠再仔細查看咱們的需求規格說明書以及PPT,咱們屢次明確的陳述過平臺是基於安卓平臺,至於IOS版本目前尚未考慮,所以您方這個問題暫時不給予回答。IOS平臺在後續迭代過程咱們會進一步完善解決。
- 有沒有考慮過雲備份生成鏈接,供不一樣帳號設備使用?
- 答:感謝提問!對於您重複提出的不一樣帳號的問題,和問題一同樣的回覆,備忘錄具備簡短便捷週期短且是平常事項的特色,所以多個帳戶之間使用只是添加累贅,暫時不給予考慮。而對於不一樣設備,若是用戶擁有一個帳號,那麼就可使用不一樣的設備登陸使用咱們的產品,而且能夠在不一樣的設備上看到本身的備忘錄內容,這也是咱們所謂的雲備份的含義。
需求分析報告
修改之處
- 修剪了圖片的尺寸,使之更齊整,內容更清晰(修改其一)。
- 在產品功能部分,完善了對雲備份的描述。
- 產品功能部分,完善了對壁紙展現的描述
《需求規格說明書》附件
記憶罐頭需求規格說明書
記憶罐頭需求ppt
遇到的困難及解決方法
緒佩
困難描述
在安裝AS的時候遇到.gradle文件夾的報錯。
在完成前端佈局文件的時候遇到水平線不會畫的問題以及排版效果老是作不到原型作的那樣好。
身爲pm,存在一些分工還不夠到位及時。
作過哪些嘗試
查閱衆多資料以後,終於在某一篇博客裏面找到緣由,因而從隊友的電腦中拷貝了gradle-4.6-all.zip文件進行了相應的配置。
仔細學習安卓前端開發資料文檔,還在努力學習中。將界面儘可能作的精美、到位、友好。
不斷努力改善中,儘可能成爲一個好的pm。
是否解決
已解決
正在解決
正在成長改善
有何收穫
身爲pm貌似感受本身的任務有點太多了,忙不過來,可能後面會稍微減小一點工做啊,主要仍是推動項目和督促工做。對於前端開發還要好好學習,真的是要熬夜苦肝...:)
鴻傑
困難描述
對於AppWidget不夠了解,不清楚如何實現簡單控件TextView
Android Studio加載gradle很是慢
AppWidget關於ListVie組件的實現不瞭解
作過哪些嘗試
百度搜索相關博客和文檔閱讀了解
嘗試修改博客的示例代碼
請教有項目經驗的學長、學姐
是否解決
基本瞭解如何實現簡單控件TextView
經過手動下載gradle文件而後配置本地路徑加快了速度
基本瞭解如何實現複雜控件ListView
有何收穫
經過博客和文檔的閱讀,訓練了我閱讀博客和文檔的能力
基本瞭解AppWidget的簡單實現
實現了簡單的ListView
丹丹
困難描述
- 如何製做APP介紹視頻,如何製做團隊logo
作過哪些嘗試
- 學習AE,PR,PS軟件使用技巧,學習AE模板套用,學習透明Logo製做
是否解決
- 已解決
有何收穫
- 掌握了AE,PR,PS軟件使用技巧
家偉
困難描述
- 不肯定對特定類別短信應該以何種形式和模板返回所需內容
- 沒有學習過Java中的正則表達式
作過哪些嘗試
- 在團隊內部進行討論並集體作出決定
- 在網絡上查找相應資料和博客
是否解決
- 已解決
- 已解決
有何收穫
- 掌握了Java中的Pattern類和Matcher類使用技巧,學習了Java中文字符的表示方法
青元
困難描述
- 沒有android開發經驗,得邊學邊寫。
- 由於沒有實際項目經驗,分工不是太明確
作過哪些嘗試
- 閱讀開發文檔和書籍
- 詢問有經驗的人
是否解決
- 是
有何收穫
- 有了必定的android開發能力
卉卉
困難描述
一個後端爲了瞭解項目作了原型,審美受到質疑
寫了一點點雲端接口被告知Alpha版本先實現本地,pm定的deadline日益接近,linux做業也面臨提交,緊急學習安卓和sqlite
作過哪些嘗試
感謝小夥伴們的建議和幫助!
感謝隊友家燦的幫助!還有就固然是熬夜學習了
是否解決
- 已解決
- 沒有解決,還在趕deadline
有何收穫
- 收穫了黑眼圈
家燦
困難描述
- 項目實現的是即便本功能,開始你們想作的是雲端,可是這樣存在一個問題就是用戶手機斷網以後,軟件沒法正常運行的問題
作過哪些嘗試
- 去圖書館借閱了幾本關於Android開發的書籍,而後也看了不少網上的博客
是否解決
- 是,而後發現了Android有嵌入的sqlite數據庫,很符合咱們的功能需求
有何收穫
- 對於Android下的sqlite進行了初步學習:建庫建表查詢等等還有就是sqlite的可視化軟件等等
政演
遇到的困難及解決方法
需求表報告工做量大,需求複雜繁多,難以完成
需求報告排版格式要求細緻繁複,修改複雜。
作過哪些嘗試
百度搜索相關博客和文檔閱讀了解
請教有項目經驗的學長、學姐
是否解決
基本瞭解如何實現初步的需求報告
基本瞭解如何製做精美的需求報告
有何收穫
經過博客和文檔的閱讀,訓練了我閱讀博客和文檔的能力
學會合理分配文檔工做
實現了最後版本的需求報告,而且是惟一沒有被老師diss的一份
一好
困難描述
思惟導圖沒作過。
有不少知識沒學過,好比安卓基礎開發,好比api如何調用
as針對我,下了不少次都不星(行)
作過哪些嘗試
查閱網上的實現案例
向同窗詢問as安裝方法,查閱安卓基礎書籍
是否解決
- 是
有何收穫
學到了新的知識
能更好的融入團隊中,爲團隊貢獻一份力量
愷琳
遇到困難
前端代碼不熟悉,須要瞭解
代碼須要貼近原型設計,須要在完成必定功能下貼近美觀
作過哪些嘗試
上網查百度
查看android stdio的教程視頻
有何收穫
初步瞭解android stdio頁面設計代碼
瞭解相關控件
可以利用一些控件使頁面貼近原型。
宇恆
遇到困難
- 對於AS的各類細節處理十分難操做,下拉列表、級聯列表、顏色處理、邊框處理等等
作過哪些嘗試
- 詢問同窗、網上查閱、書籍查閱,再創建測試文件真正手動操做幾回
有何收穫
- 稍微有了一種佈局觀,瞭解怎麼佈局纔算合理,一些細節化的處理能夠很快的解決
PSP
Planning |
計劃 |
150 |
240 |
· Estimate |
·估計這個任務須要多少時間 |
15 |
5 |
Development |
開發 |
180 |
150 |
· Analysis |
需求分析(包括學習新技術) |
120 |
120 |
· Design Spec |
· 生成設計文檔 |
240 |
300 |
· Design Review |
· 設計複審 |
30 |
60 |
· Coding Standard |
· 代碼規範 (爲目前的開發制定合適的規範) |
0 |
0 |
· Design |
· 具體設計 |
180 |
240 |
· Coding |
· 具體編碼 |
0 |
0 |
· Code Review |
· 代碼複審 |
0 |
0 |
· Test |
·測試(自我測試,修改代碼,提交修改) |
0 |
0 |
Reporting |
報告 |
245 |
300 |
· Test Repor |
· 測試報告 |
0 |
0 |
· Size Measurement |
· 計算工做量 |
0 |
0 |
· Postmortem & Process Improvement Plan |
· 過後總結, 並提出過程改進計劃 |
60 |
90 |
合計 |
|
1058 |
1355 |
學習進度條
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 |
需求報告撰寫 |