項目測評（團隊）

寫在前面

• 本次做業
  
• 測試報告連接
• 林燊大哥

第一部分 調研，評測

1、評測

軟件的bug，功能評測，黑箱測試

1.下載並使用，描述最簡單直觀的我的第一次上手體驗

IOS端

• UI界面簡單明瞭，是我喜歡的極簡風格。課程模塊界面簡潔優雅，功能切換方式靈活便利。
• 登錄界面的驗證碼識別功能深得我心。（ps：強迫症驅使着我在明知道不區分大小寫的前提下，仍是不得不切換大小寫）
• 功能齊全到讓人沒法用言語描述，因此只好引用做業原文中的一段話：

查的了成績、考場、空教室，左通圖書館，右達易班，能搶實驗，能下歷年卷。

Android端

• 在福大三年，聽過不少人推薦福大助手，可是用慣了福大教務通，並且它的功能基本能知足我
  需求，就遲遲沒有入手這個App。在華爲應用市場找到了這個App，只有2.4MB，很快就下好了，這算是我對它的第一個好印象。
• 打開App，迎來的是簡潔好看的界面，有趣的是，還能夠在設置中更改側邊欄顏色，算是給挑剔顏色的人一個無可反駁的理由去喜歡它。
• 課程表界面和福大教務通沒什麼大不一樣，比較有趣的是能夠把課程導到日曆裏面，好像有了日曆就能提醒你按時上課同樣。比較尷尬的是這步操做找不到撤銷的地方，對於我這種手殘點到，看着日曆滿滿當小心煩的人就不是一次很美好的體驗了
• 最使人稱道的是它豐富的附加功能，能夠說把「助手」這兩個字發揮到了極點。無論是登易班，仍是查空教室，這些功能都是比較有用的，並且在福大教務通中並無。還有一個有趣的地方是一鍵評議功能被放到了易班工具中（易班：我沒有），而且寫成了一鍵XX，仍是比較回味無窮的。
• 總的來講，體驗感仍是很不錯的，若是有其它朋友須要類似功能的軟件，我會向他翹起大拇指推薦福大助手。

2.使用思惟導圖，描述福大助手的結構體系

3. 按照描述的bug定義，找出至少兩個功能性的比較嚴重的bug

測試主體：

福大助手(IOS端)

福大助手(Android端)

IOS端

1. 進入「設置->推送」界面後，APP卡死，沒法返回，沒法執行其餘操做。
2. 易班工具使用時一直卡在登錄界面，沒法進行其餘操做。
3. 單科績點沒法顯示。
4. 雖然驗證碼識別功能深得我心，可是它偶爾仍是會開小差的～

Android端

1. 課程表在刷新的過程當中點擊「+」，「+」功能會消失。

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. 假設咱們團隊須要開發這套系統，需注意的方面

• 若是咱們團隊要開發這套系統的話，首先要踩在巨人的肩膀上，找一找有沒有合適的能夠借鑑的系統。同時要作好需求分析，明確咱們的客戶，系統的用戶是誰，他們須要解決什麼問題。很顯然，用戶羣體是福大可愛的學生們。便捷的體驗和強大的功能是免不了的，固然，對學生來講最重要的免費版也是必不可少的。
• 架構方面要作到可靠性，安全性和可維護性，尤爲是要考慮到用戶的體驗，必須保證容易上手。
• 運行維護方面只能辛苦咱們的開發團隊每隔一段時間進行一次維護了，相信咱們的用戶也會積極反饋問題，大大加快這個軟件進入能用好用的階段。
• 微服務方面咱們會安排金牌客服宏巖，在線知足各種需求。

2、採訪

第8章 用戶調研，12 章 軟件的用戶體驗，

被採訪人 ：林佳煒（數計學院2018級新生）

採訪過程：

1. 請問您使用過福大助手嗎？
   答：沒有使用過，我如今在用福大教務通。
2. 在使用福大教務通的過程當中，有什麼是你須要卻沒有的功能嗎？
   答：有的，好比它沒法查歷年卷，沒法看空教室。
3. 正好如今就有這麼一款app推薦給您，叫作福大助手，能夠知足您的這些需求，你能夠現場試一下。
   答：好啊。
4. 在使用這款軟件的過程當中，你的問題解決了嗎？
   答：解決了，這款軟件很是好用，不只能夠看教務通知，還能夠查歷年卷。
5. 軟件在數據量/界面/功能/準確度上各有什麼優缺點？
   答：數據量的話我很滿意了，界面也是我比較喜歡的簡潔型，功能很齊全。準確度的話，我打開了歷年卷裏的ppt，感受仍是不錯的。
6. 用戶體驗方面有問題麼？
   答：用戶體驗上感受還不錯，功能比較完善，並且使用起來並不困難。
7. 您對產品有什麼改進意見？
   答：若是可以兼容安卓9.0以上就行了。
8. 若要給這個軟件下一個評價,請選擇一個結論:
   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.若是你是項目經理，如何提升從而在競爭中勝出？

• 如我我是項目經理，我將會從如下幾方面提升咱們產品的競爭力：
  • 質量保障：高質量是一個有競爭力的產品必須具有的條件。做爲一個產品經理，我將從如下兩方面提升軟件質量：
    1. 「磨刀不誤砍柴工」，在軟件開發工做進行前，應先根據項目的大小和我的的能力進行合理的分工，並制定代碼規範等一系列標準。
    2. 正如柯老闆所說的，「一個好的公司，測試和開發人員的地位是同等重要的」，因此咱們會運用必定的流程和工具，量化工做的流程和結果，例如：測試用例、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，推廣）
    • 制定合理的宣傳策略，提升產品的知名度，開展活動，如：
      • 能夠與校方合做，以二維碼、連接形式分享推廣
      • 經過邀請新用戶註冊給予必定獎勵形式推廣

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裏的文字變得很是多，請問是否考慮過觀衆的觀看體驗。
  • 答：感謝您的建議，下次咱們會改進。
• 問：思惟導圖內容之多，是否應該取其重點呈現，而不是一次性的放一整個部分？爲何部分圖片高糊？
  • 答：高糊問題咱們確實沒有作好審覈工做，思惟導圖但願能夠換個方式展現也許會更好。

我的部分

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

• 我的學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
1	300	300	15	15	熟悉了C++語言，瞭解了單元測試，代碼覆蓋率和性能分析
2	0	300	8	23
3	300	600	14	37	爬蟲，代碼能力更上一步
4	0	600	4	41	簡單的uml設計
5	0	600	11	52	使用墨刀進行app原型設計
6	150	750	12	64	使用android studio寫前端
7	900	1650	21	85	使用android studio設計前端和短信登陸初學服務器
8	800	2450	18	103	服務器接收和客戶端發送，okhttp框架學習
9	100	2550	8	111	熟練使用墨刀，用墨刀導入騰訊地圖