寫在前面
- 本次作業
- 測試報告鏈接
- 林燊大哥
第一部分 調研，評測
一、評測
軟件的bug，功能評測，黑箱測試
1.下載并使用，描述最簡單直觀的個人第一次上手體驗
IOS端
- UI界面簡單明了，是我喜歡的極簡風格。課程模塊界面簡潔優雅，功能切換方式靈活便利。
- 登陸界面的驗證碼識別功能深得我心。（ps：強迫癥驅使著我在明知道不區分大小寫的前提下，還是不得不切換大小寫）
- 功能齊全到讓人無法用言語描述，所以只好引用作業原文中的一段話：
查的了成績、考場、空教室，左通圖書館，右達易班，能搶實驗，能下歷年卷。
Android端
- 在福大三年，聽過很多人推薦福大助手，但是用慣了福大教務通，而且它的功能基本能滿足我
需求，就遲遲沒有入手這個App。在華為應用市場找到了這個App，只有2.4MB，很快就下好了，這算是我對它的第一個好印象。 - 打開App，迎來的是簡潔好看的界面，有趣的是，還可以在設置中更改側邊欄顏色，算是給挑剔顏色的人一個無可反駁的理由去喜歡它。
- 課程表界面和福大教務通沒什么大不同，比較有趣的是可以把課程導到日歷里面，
好像有了日歷就能提醒你按時上課一樣。比較尷尬的是這步操作找不到撤銷的地方，對于我這種手殘點到，看著日歷滿滿當當心煩的人就不是一次很美好的體驗了 - 最令人稱道的是它豐富的附加功能，可以說把“助手”這兩個字發揮到了極點。不管是登易班，還是查空教室，這些功能都是比較有用的，而且在福大教務通中并沒有。還有一個有趣的地方是一鍵評議功能被放到了易班工具中（易班：我沒有），并且寫成了一鍵XX，還是比較耐人尋味的。
- 總的來說，體驗感還是很不錯的，如果有其它朋友需要相似功能的軟件，我會向他翹起大拇指推薦福大助手。
2.使用思維導圖，描述福大助手的結構體系
3. 按照描述的bug定義，找出至少兩個功能性的比較嚴重的bug
測試主體：
福大助手(IOS端)
福大助手(Android端)
IOS端
- 進入“設置->推送”界面后，APP卡死，無法返回，無法執行其他操作。
- 易班工具使用時一直卡在登陸界面，無法進行其他操作。
- 單科績點無法顯示。
- 雖然驗證碼識別功能深得我心，但是它偶爾還是會開小差的～
Android端
- 課程表在刷新的過程中點擊“+”，“+”功能會消失。
4. 用專業的語言描述bug（每個bug 不少于 40字），并適當配圖
BUG描述模版參考知乎：怎樣用簡潔又清楚的語言將 bug 描述清楚？
IOS端
Bug1
1.標題：“設置->推送”界面，APP卡死，無法返回，無法執行其他操作。
2.測試人員姓名：劉宏巖
3.缺陷報告提交的時間：2018.12.07
4.缺陷的等級：中級
5.缺陷的優先級（等級表明缺陷的嚴重程度，優先級表明修復缺陷的優先程度）：中級
6.測試環境（包括但是不僅限于使用的設備名稱，測試標的物的版本，操作系統的信息。等等一切相關信息）：IPhone8，操作系統及版本：IOS12.1
7.缺陷發生的位置（模塊）：“設置->推送”界面
8.預期結果：正常操作，并且可以正常退回主界面。
9.實際結果：APP卡死無反應。
10.重現步驟：打開app依次點擊：設置->推送。
11.附圖：
Bug2
1.標題：易班工具無法正常登陸，導致APP卡死，無法進行其他操作，且不會提示登陸超時。
2.測試人員姓名：蔡宇航
3.缺陷報告提交的時間：2018.12.07
4.缺陷的等級：中級
5.缺陷的優先級（等級表明缺陷的嚴重程度，優先級表明修復缺陷的優先程度）：中級
6.測試環境（包括但是不僅限于使用的設備名稱，測試標的物的版本，操作系統的信息。等等一切相關信息）：IPhone6s，操作系統及版本：IOS12.1
7.缺陷發生的位置（模塊）：“易班工具”界面
8.預期結果：正常登陸。
9.實際結果：APP卡死無反應。
10.重現步驟：打開app依次點擊：易班工具。
11.附圖：
Bug3
1.標題：成績查詢界面，學分可以顯示，但是單科績點無法顯示，單學期績點無法顯示。
2.測試人員姓名：劉宏巖
3.缺陷報告提交的時間：2018.12.07
4.缺陷的等級：初級
5.缺陷的優先級（等級表明缺陷的嚴重程度，優先級表明修復缺陷的優先程度）：初級
6.測試環境（包括但是不僅限于使用的設備名稱，測試標的物的版本，操作系統的信息。等等一切相關信息）：IPhone6s，操作系統及版本：IOS12.1
7.缺陷發生的位置（模塊）：“成績界面”
8.預期結果：正常顯示單科績點。
9.實際結果：績點一列顯示為“-”。
10.重現步驟：打開app依次點擊：成績。
11.附圖：
Bug4
1.標題：驗證碼識別功能識別錯誤.
2.測試人員姓名：劉宏巖
3.缺陷報告提交的時間：2018.12.07
4.缺陷的等級：初級
5.缺陷的優先級（等級表明缺陷的嚴重程度，優先級表明修復缺陷的優先程度）：初級
6.測試環境（包括但是不僅限于使用的設備名稱，測試標的物的版本，操作系統的信息。等等一切相關信息）：IPhone6s，操作系統及版本：IOS12.1
7.缺陷發生的位置（模塊）：“登陸界面”
8.預期結果：正常識別驗證碼并完成填寫。
9.實際結果：有些驗證碼識別錯誤。
10.重現步驟：打開app依次點擊：進入登陸界面。
11.附圖：
Android端
Bug1
1.標題：課程表在刷新的過程中點擊“+”，“+”功能消失
2.測試人員姓名：朱志豪
3.缺陷報告提交的時間：2018.12.07
4.缺陷的等級：初級
5.缺陷的優先級（等級表明缺陷的嚴重程度，優先級表明修復缺陷的優先程度）：初級
6.測試環境（包括但是不僅限于使用的設備名稱，測試標的物的版本，操作系統的信息。等等一切相關信息）：IPhone6s，操作系統及版本：Android 8.0.0
7.缺陷發生的位置（模塊）：“課程表界面”
8.預期結果：
9.實際結果：
10.重現步驟：打開app依次點擊：“+” -> “刷新” -> 在刷新過程中點擊“+”
11.附圖：
5. 你覺得為什么這個產品組的人沒有發現這些bug?
IOS端
- 開發人員在測試時沒有注意到這些細節。
- 開發人員忽略了訪問教務處可能出現的問題，也有可能是教務處自身的失誤造成了這些BUG的產生。
- 運用不同IOS版本進行測試，可能開發團隊的測試機沒有BUG，但是使用者的某款手機有BUG。
- 驗證碼識別程序自身存在的BUG。
Android端
- 可能是測試人員不像我會
手賤地在刷新的時候點“+”吧。
6. 假設我們團隊需要開發這套系統，需注意的方面
- 如果我們團隊要開發這套系統的話，首先要踩在巨人的肩膀上，找一找有沒有合適的可以借鑒的系統。同時要做好需求分析，明確我們的客戶，系統的用戶是誰，他們需要解決什么問題。很顯然，用戶群體是福大可愛的學生們。便捷的體驗和強大的功能是免不了的，當然，對學生來說最重要的免費版也是必不可少的。
- 架構方面要做到可靠性，安全性和可維護性，尤其是要考慮到用戶的體驗，必須保證容易上手。
- 運行維護方面只能辛苦我們的開發團隊每隔一段時間進行一次維護了，相信我們的用戶也會積極反饋問題，大大加快這個軟件進入能用好用的階段。
- 微服務方面我們會安排金牌客服宏巖，在線滿足各類需求。
二、采訪
第8章 用戶調研，12 章 軟件的用戶體驗，
被采訪人 ：林佳煒（數計學院2018級新生）
采訪過程：
請問您使用過福大助手嗎？
答：沒有使用過，我現在在用福大教務通。在使用福大教務通的過程中，有什么是你需要卻沒有的功能嗎？
答：有的，比如它無法查歷年卷，無法看空教室。正好現在就有這么一款app推薦給您，叫做福大助手，可以滿足您的這些需求，你可以現場試一下。
答：好啊。在使用這款軟件的過程中，你的問題解決了嗎？
答：解決了，這款軟件非常好用，不僅可以看教務通知，還可以查歷年卷。軟件在數據量/界面/功能/準確度上各有什么優缺點？
答：數據量的話我很滿意了，界面也是我比較喜歡的簡潔型，功能很齊全。準確度的話，我打開了歷年卷里的ppt，感覺還是不錯的。用戶體驗方面有問題么？
答：用戶體驗上感覺還不錯，功能比較完善，而且使用起來并不困難。您對產品有什么改進意見？
答：如果能夠兼容安卓9.0以上就好了。若要給這個軟件下一個評價,請選擇一個結論:
a 非常不推薦
b 不推薦
c 一般
d 推薦
e 非常推薦
答： d
第二部分 分析
參考 8.6 節 對工作的估計， 和14.1 節 軟件工程的質量
1. 估計這個項目做到這個程度大約需要多少時間（團隊人數6人左右，計算機大學畢業生，并有專業UI 支持）。
- 如果這個團隊具有熟悉安卓開發和iOS開發，以及能夠熟練掌握接口設置的同學的話，估計需要3至4個月時間。
- 如果團隊中沒有同學有過類似的開發經驗的話，算上學習時間和熟悉開發工具的時間，估計需要半年時間。
2. 分析這個軟件目前的優劣（和類似軟件相比），并推理出開發團隊在軟件工程方面可以提高的一個重要部分（具體建議）
我們將福大助手與三個類似軟件相比，分別是：超級課程表、課程盒子和針對武漢大學生的微信小程序“在武大”。
- 由于前兩者是面向全國大學生的，所以他們的功能更加偏向顯示課表、查詢成績以及各校學生的交流互動。與這兩者對比，福大助手更加本土化，除了顯示課表、查詢成績功能，它還可以使用福大易班的相關工具，更便于福大學生的使用。
- 微信小程序“在武大”，如果說把搭載在微信上算是他的一個劣勢的話，那似乎這個小程序涵蓋了福大助手的所有功能。包括圖書館借閱查詢、成績查詢、故障報修等等。甚至還有失誤招領、校園巴士以及一些娛樂項目。
- 如果說福大助手與之相比的優勢的話那估計就是他能夠直接查看學校教務處信息
和提供學科歷年卷以及一鍵XX的功能了。（敏感詞已屏蔽） - 在對比了三個軟件之后，我們覺的開發團隊要在軟件中添加一個動態功能，一個能夠讓用戶進行社交的平臺，有助于學生之間的交流和一些校園有趣事情的分享。這是前三個軟件都具有而福大助手沒有的功能。那么可以認為，當年開發團隊在開發福大助手的時候，當時的學生用戶是不需要這種平臺功能的，而現在的大學生對此的需求量還是很大的。所以我認為，開發團隊需要在軟件工程的用戶調研方面實時跟上進度，起碼半年進行一次，否則很有可能漏掉當代用戶的需求。
3. 根據理解和體驗，畫出整個軟件所有功能邏輯框圖，根據重要度標識出各模塊的重要度、完成度、出發點及效果。
原圖顯示：
4. 針對不同的維度評分，對用戶體驗方面、UI界面美觀度、核心功能，分別打分。
用戶體驗：★★★☆☆
- 可以很容易地上手，各個功能在頁面中的分布也很合理。
UI界面美觀度：★★★★☆
- 感覺已經是理工學生的UI巔峰水平。
核心功能：★★★★☆
- 能夠顯示課表、查詢成績、使用易班工具和進入教務處，都完成的很不錯。就是存在一些些的bug以及處理邊界問題的手段不夠高明。
第三部分 建議和規劃
參考《構建之法》第8章 功能的定位和優先級；第9章 項目經理
這個軟件有很多可以提高的部分。
1.如果你是項目經理，如何提高從而在競爭中勝出？
- 如我我是項目經理，我將會從以下幾方面提高我們產品的競爭力：
- 質量保障：高質量是一個有競爭力的產品必須具備的條件。作為一個產品經理，我將從以下兩方面提高軟件質量：
- “磨刀不誤砍柴工”，在軟件開發工作進行前，應先根據項目的大小和個人的能力進行合理的分工，并制定代碼規范等一系列標準。
- 正如柯老板所說的，“一個好的公司，測試和開發人員的地位是同等重要的”，所以我們會運用一定的流程和工具，量化工作的流程和結果，例如：測試用例、BUG、代碼覆蓋率、MTTF、軟件效能參數等等。將測試結果反饋開發人員進行進一步的調試優化。確保產品的高質量。
- 迭代模式：在每次軟件更新時，除了修復已知BUG和進行細節優化，還可以加入一些實驗性的功能，以吸引新的用戶群體和提高不同用戶分群的留存率。
- 自我分析：采用SWOT框架分析本產品進行創新過程中可能遇到的問題，并有針對性地采取方案。
- 宣傳推廣：制定合理的宣傳策略，提高產品的知名度，開展活動，吸引更多的用戶。
- 提高用戶體驗：定期投放問卷，進行用戶調研，根據用戶反饋有針對性地進行改進，以提高用戶體驗
- 質量保障：高質量是一個有競爭力的產品必須具備的條件。作為一個產品經理，我將從以下兩方面提高軟件質量：
2.目前市場上有什么樣的產品了？
- 目前市場上的同類產品主要有：
- 福大教務通
- 超級課程表
- 課程格子
- 課程表助手
- 輕課表
- MD課表
- 我的課程表
3.你要設計什么樣的功能？
- 殺手功能（Core）
- 課程表
- 日程管理
- 成績查詢
- 考場查詢
- 空教室查詢和申請
- 課程資源共享
- 師資信息
- 校招信息
- 外圍功能（Context）
- 宿舍報修
- 圖書借閱
- 實驗預約
- 校園地圖
- 教務通知
4.為何要做這個功能，而不是其他功能？
- 課程表、日程管理、成績查詢、考場查詢、課程資源共享這些功能是此類產品的基礎功能，如果產品缺少此類功能，可能會流失大量用戶。
- 空教室查詢、師資信息、校招信息這些功能能很好地滿足大部分用戶的需求，開發此類功能為了面向主要用戶群體。
- 宿舍報修、圖書借閱、實驗預約、校園地圖、教務通知這些功能相比于前面的那些，用戶使用頻率較低，開發此類功能主要為開拓潛在用戶群體的市場。
- 除了上述功能之外，其他功能暫時不做考慮，一方面，因為用戶群體對這些功能的需求并不是很大，投入極大人力物力資源來滿足極小部分用戶的需求；除了投入多產出少，另一方面，對于本產品面向的主要用戶群體來說，加入這些功能，將使軟件變得“臃腫”，造成不良的用戶體驗。
5.為什么用戶會用你的產品/功能？
- 橫向來看，正如《構建之法》中所述：“讓用戶驚喜的功能一旦出現，就能給用戶的滿意度帶來正面幫助。”用戶之所以會選擇我們的產品，就是因為我們的產品相較于別的產品有更有亮點，更能給用戶帶來驚喜。例如：使用本產品的師資信息功能在選課時候相較于通過網頁手動查詢教師信息的方式更能給用戶帶來便利，提升用戶滿意度。
- 縱向來看，用戶對課表查詢、成績查詢等基礎功能性存在強烈需求。本產品正是為了滿足用戶的基本需求而設計的，功能齊全，能較好地滿足用戶的基本需求。除了產品本身能滿足用戶的需求外，從產品本身來看，產品良好的設計給用戶良好的用戶體驗，使用戶在使用本產品時身心愉悅，具有一定的黏性。
- 綜合來說，本產品的核心價值或服務、交互體驗，運營宣傳等都是用戶持續使用本產品的原因。
6.你的創新在哪里？可以用 NABCD 分析
- 我們的產品的主要創新功能有：師資信息、校招信息。
- 采用NABCD模型按部就班分析：
- N （Need，需求）
- 用戶的需求有：
- 對于師資信息：學生需要詳細了解授課教師
- 對于校招方案：學生在報考該學校，需要詳細了解該學校。
- 用戶存在的痛點有：
- 對于師資信息：例如：1.學生在選課時只能看到教師姓名，想要詳細了解只能一個個去各學院官方網站查找，十分不便。2.在選擇導師時，無法詳細地了解每個導師擅長的方向和研究的領域，導致最后做出的選擇可能并不是最適合自己的。
- 對于校招信息：學生在報考學校時，只能通過百度百科、學校官網、或者親自咨詢目標院校的學生，了解信息不夠全面不夠及時。
- 用戶的需求有：
- A （Approach，做法）
- 解決方案：
- 對于師資信息：從各個學院官方網站整合師資信息。
- 對于校招信息：將學校發布的校招信息及時推送給用戶，并且給出往年校招信息，作為參考，讓用戶可以自行對比，及時了解招生政策的變化情況。
- 解決方案：
- B （Benefit，好處）
這些創新功能給用戶帶來了及時的信息，并簡化了信息收集的過程。 - C （Competitors，競爭）
- 優勢：軟件質量高，可靠性強，交互友好
- 劣勢：因缺少官方接口，數據獲取采用爬蟲實現，效率低。不利于商用化推廣。
- D （Delivery，推廣）
- 制定合理的宣傳策略，提高產品的知名度，開展活動，如：
- 可以與校方合作，以二維碼、鏈接形式分享推廣
- 通過邀請新用戶注冊給予一定獎勵形式推廣
- 制定合理的宣傳策略，提高產品的知名度，開展活動，如：
- N （Need，需求）
7.如果你來領導這個團隊，會有什么不一樣？
- 正如亞當·斯密所說：“分工的起源是由于人的才能具有自然差異”，如果我來領導這個團隊，我會更加重視分工，根據每個人的能力進行合理的任務分配和deadline制定。也像柯老板說的一樣，“deadline是第一生產力”，合理地制定deadline能推動整個工程項目的進度。適時對組內成員進行push，跟進項目進度，進行督促，定期召開站立會議。注重團隊成員之間的溝通，例如可以進行利用共享文檔編寫工作總結，實現組內成員之間進度的相互了解，以便在遇到瓶頸時集中力量克服困難。
8.如果你的團隊有5個人,4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？
| 角色 | 項目初始階段 | 詳細設計階段 | 編碼階段 | 測試階段 | |
|---|---|---|---|---|---|
| 項目經理 | 制定軟件規格需求說明書，評估風險 | 審批方案 | 跟進項目進度，組織召開會議 | 審核測試報告 | |
| IOS端開發 | 了解客戶需求，統一開發流程規范 | 框架搭建，接口設計 | 開發IOS端App | 根據測試人員返回的結果，改進優化 | |
| Android端開發 | 了解客戶需求，統一開發流程規范 | 框架搭建，接口設計 | 開發Android端App | 根據測試人員返回的結果，改進優化 | |
| 美工 | 了解客戶需求 | 應用專業知識，設計符合客戶要求的UI界面 | 根據程序編寫的實際需求提供額外的圖片 | 協助交互測試 | |
| 測試人員 | 制定測試計劃 | 設計測試用例 | 根據測試計劃，編寫測試數據、測試腳本 | 執行測試并提交測試報告 |
9.描述你的團隊在16 周期間每周都要做什么，才能在第16周如期發布軟件，大小里程碑績點設定
| 時間/周 | 工作 |
|---|---|
| 1-3 | 需求分析，文檔規范撰寫 |
| 4 | 界面設計 |
| 5 | 界面美化 |
| 6 | 客戶端框架搭建，模塊接口設計 |
| 7 | 服務器搭建 |
| 8-11 | Android、IOS編碼 |
| 12-15 | 程序測試，bug修改 |
| 16 | 正式上線，發布產品 |
10.項目發布后，有沒有考慮過項目該怎么部署才能滿足需求。依據附錄圖（某校教務處系統的部署）作為參考，分析16周后你所完成的項目上線需要哪些配套設備(服務器、帶寬、數據庫需求數量與配置)
- 應用服務器配置：8核8G*3（2臺日常使用,分IOS、安卓，1臺作為備用服務器）
- 后端服務器配置：8核8G*3（2臺日常使用，1臺作為備用服務器）
- 關系型數據庫：MySQL，數量2（一個日常使用，一個備份）
- 帶寬：20Gbps
第四部分 增量開發設計
1. 我的日程
- 新增功能點的原型界面
- 基本實現思路
- 對于每個用戶，每新建一個日程，就將其同步到數據庫中，以便記錄用戶日程。
- 日程如上圖所示，每個日程為一個簡單的小卡片，全部日程以時間軸的方式進行查看，使得整個界面更加簡潔有條理。
- 對于每個日程可單獨管理，通過右劃小卡片可以對卡片進行刪除和修改。
- 可以增加日歷事件，選擇性同步到手機自帶的日程、鬧鐘提醒以及在通知欄上提示，用戶可以通過每個日程小卡片上快捷開關，對每個日程單獨管理，選擇提醒或不提醒
- 時間軸上每個日程對應的小方塊，對于選擇提醒的日程會為藍色，選擇不提醒的日程為白色，更加方便查看。
- 新增功能點與原有產品如何接入
- 新增的日程功能是以福大助手的一個子功能接入，與其他現有功能交集小，接入十分簡單。
- 我的日程的進入點可以同福大助手的其他子功能一樣，放在福大助手本身的右側菜單欄上。
- 數據庫方面，可以以原來的用戶列表做一個索引，對于每個用戶的日程單獨做一個數據表，通過原來的用戶表索引找到這個日程數據表。
- 我的日程也可嘗試與課表接入，把相應時間段的日程放入課表顯示。這個功能需要與課表顯示接入。在日程數據庫中新增一個標志位，對于要加入課表的日程就設置這個標志位置“1”，在生成課表時，可以先遍歷日程數據表，將置“1”的日程加入課表。
第五部分 答辯總結
得分
| 第一組 | 第二組 | 第三組 | 第四組 | 第五組 | 第六組 | 第七組 | 第八組 | 第九組 | 平均分 |
|---|---|---|---|---|---|---|---|---|---|
| 67 | 77 | 78 | 81 | 82 | 69 | 68 | 81 | 75.8 |
- 說明：第八組的分數在經過溝通之后對方同意修改，改為81。
貢獻度
| 名 | 貢獻度 | 工作量比例 |
|---|---|---|
| 燊 | 10% | 10% |
| 鈞昊 | 10% | 10% |
| 俞辛 | 10% | 10% |
| 宏巖 | 14% | 14% |
| 喜源 | 11% | 11% |
| 柏濤 | 11% | 11% |
| 宇航 | 11% | 11% |
| 愷翔 | 10% | 10% |
| 志豪 | 13% | 13% |
Q&A
1.爸爸餓了隊
- 問：評測報告與PPT中展示的內容不一致，ppt制作先于報告，是否考慮以后避免這樣的問題出現？
- 答：以后會加強審核工作。
- 問：希望更多的內容通過演講者口述出來，ppt用來展示更多圖表
- 答：好的，感謝你的建議。
- 問：增量開發的實現難度如何，大概需要多長的工作時間？
- 答：增量開發實現難度不大，在熟悉產品的情況下半個月可以實現。
2.拖鞋旅游隊
- 問：為什么IOS端與Android端的BUG數量有所差異？
- 答：我們組員大部分都是IOS的手機，而且負責測試的組員也是IOS手機導致安卓端測試時間較少，所以BUG數量有差異。
- 問：第八第九頁的GIF已經糊了，是否應采取其他形式來展示BUG？
- 答：GIF是因為視頻轉格式問題導致模糊，現場采用了直接播放視頻的形式來展示，下次會做好提前審核。
- 問：增量開發的功能已與日歷功能相近，是否真的有必要實現？
- 答：我們認為這個功能還是有必要的。
3.彳艮彳亍隊
- 問：Android端的bug數量較少，是否是Android端測試交缺漏？會不會有其他bug沒檢測出來？
- 答：初期安卓端確實測試有缺漏，后期我們已經補上，詳見我們的測試報告。
- 問：PPT制作更加精美細致嗎？如文字的大小等。（僅是建議。）
- 答：感謝你的建議，下次我們會做的更好。
- 問：視頻和GIF圖片，一個沒有配音，一個圖像過于模糊，能否更好解決？
- 答：視頻問題在我們電腦上測試良好，現場可能由于音響原因倒是沒有聲音，圖像問題因為格式轉換問題導致模糊，主要還是我們審核工作沒做好，下次會注意。
5.起床一起肝活隊
- 問：BUG測試中IOS端和Android端的BUG數量差距明顯，IOS端4個，Android端才1個，Android端才開發1年，BUG明顯應該更多，為什么只找出了一個呢？
- 答：安卓端BUG已經補充，詳見測試報告。
- 問：功能邏輯框圖缺少了一鍵評議、大物實驗、嘉錫講壇和二手市場這四個功能模塊，為什么呢？
- 答：我們是根據IOS端來做的邏輯框圖，IOS端并沒有這幾個功能。
- 問：在報告中第六部分測試結果與建議，其中全是文字，為什么沒有圖片，而且這部分內容是否過少了呢？
- 答：去學習了一下貴組的第六部分是怎么敘述的，發現貴組無非是把測試結果的表格做成了一張圖片，然后寫了一個總體分析，一共四行建議。希望這個建議我們兩組共勉。
6.404 Note Found隊
- 問：安卓端bug為什么只有一個呢？
- 答：已經補充詳見測試報告。
- 問：PPT上的內容展示是否會字數過多，內容冗余？
- 答：是的，這次PPT制作策略上出了點問題，下次會改進。
- 問：PPT上的產品分析對比和文檔上的產品分析對比為什么不一致呢？
- 答：由于測試報告和PPT是不同同學負責制作，又沒有做好審核工作，所以出現了這個問題。
7.第三視角
- 問：為什么不對視頻進行后期錄音或者配置簡單的錄音設備？
- 答：視頻在我們的筆記本上查看是有聲音的，不知道為何現場演示的時候出現了這個問題。
- 問：關于過小的字體和部分高糊圖片是不是應該考慮下觀感？
- 答：感謝你的建議，下次會改進。
- 問：增量開發的部分會不會顯得有點略簡單了？
- 答：簡單實用也不失為一件好事。
8.小白吃
- 問：ppt中采訪的是對福大教務通的使用情況，為什么沒有呈現對福大助手的采訪？
- 答：PPT只截取了部分采訪情況，具體采訪情況可以看我們博客。
- 問：從bug評測那起ppt里的文字變得非常多，請問是否考慮過觀眾的觀看體驗。
- 答：感謝您的建議，下次我們會改進。
- 問：思維導圖內容之多，是否應該取其重點呈現，而不是一次性的放一整個部分？為什么部分圖片高糊？
- 答：高糊問題我們確實沒有做好審核工作，思維導圖希望可以換個方式展示也許會更好。
第六部分 個人部分
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 5 | 5 |
| · Estimate | · 估計這個任務需要多少時間 | 5 | 5 |
| Development | 開發 | 320 | 350 |
| · Analysis | · 需求分析 (包括學習新技術) | 120 | 150 |
| · Design Spec | · 生成設計文檔 | 5 | 5 |
| · Design Review | · 設計復審 | 5 | 5 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | 30 | 30 |
| · Design | · 具體設計 | 5 | 5 |
| · Coding | · 具體編碼 | 120 | 120 |
| · Code Review | · 代碼復審 | 5 | 5 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 30 | 30 |
| Reporting | 報告 | 30 | 30 |
| · Test Repor | · 測試報告 | 10 | 10 |
| · Size Measurement | · 計算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后總結, 并提出過程改進計劃 | 10 | 10 |
| 合計 | 355 | 385 |
學習進度條
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時（小時） | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 1 | 200 | 200 | 6 | 6 | 學習PyQt5的基本使用 |
| 2 | 500 | 700 | 12 | 18 | 學習Qt開發 |
| 3 | 300 | 1000 | 3 | 21 | 學習python爬蟲 |
| 4 | 200 | 1200 | 4 | 25 | 學習安卓常用控件 |
| 5 | 400 | 1600 | 7 | 32 | 學習安卓XML的使用 |
| 6 | 600 | 2200 | 7 | 39 | 學習安卓開發中數據庫的使用 |
| 7 | 300 | 2500 | 8 | 47 | 學習安卓QQ登錄SDK |
| 8 | 400 | 2900 | 24 | 71 | 安卓網絡傳輸 |
| 9 | 300 | 3200 | 12 | 83 | 安卓SQLite數據庫的使用 |
| 10 | 300 | 3500 | 6 | 89 | 學習騰訊地圖SDK |
