第十次作業 - 項目測評（團隊）

寫在前面

本次作業
測試報告連結
林燊大哥

第一部分調研，評測

一、評測

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

1.下載下傳并使用，描述最簡單直覺的個人第一次上手體驗

IOS端

UI界面簡單明了，是我喜歡的極簡風格。課程子產品界面簡潔優雅，功能切換方式靈活便利。
登陸界面的驗證碼識别功能深得我心。（ps：強迫症驅使着我在明知道不區分大小寫的前提下，還是不得不切換大小寫）
功能齊全到讓人無法用言語描述，是以隻好引用作業原文中的一段話：

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

Android端

在福大三年，聽過很多人推薦福大助手，但是用慣了福大教務通，而且它的功能基本能滿足我

需求，就遲遲沒有入手這個App。在華為應用市場找到了這個App，隻有2.4MB，很快就下好了，這算是我對它的第一個好印象。
打開App，迎來的是簡潔好看的界面，有趣的是，還可以在設定中更改側邊欄顔色，算是給挑剔顔色的人一個無可反駁的理由去喜歡它。
課程表界面和福大教務通沒什麼大不同，比較有趣的是可以把課程導到月曆裡面，好像有了月曆就能提醒你按時上課一樣。比較尴尬的是這步操作找不到撤銷的地方，對于我這種手殘點到，看着月曆滿滿當當心煩的人就不是一次很美好的體驗了
最令人稱道的是它豐富的附加功能，可以說把“助手”這兩個字發揮到了極點。不管是登易班，還是查空教室，這些功能都是比較有用的，而且在福大教務通中并沒有。還有一個有趣的地方是一鍵評議功能被放到了易班工具中（易班：我沒有），并且寫成了一鍵XX，還是比較耐人尋味的。
總的來說，體驗感還是很不錯的，如果有其它朋友需要相似功能的軟體，我會向他翹起大拇指推薦福大助手。

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

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

測試主體：

福大助手(IOS端)

福大助手(Android端)

進入“設定->推送”界面後，APP卡死，無法傳回，無法執行其他操作。
易班工具使用時一直卡在登陸界面，無法進行其他操作。
單科績點無法顯示。
雖然驗證碼識别功能深得我心，但是它偶爾還是會開小差的～

課程表在重新整理的過程中點選“+”，“+”功能會消失。

4. 用專業的語言描述bug（每個bug 不少于 40字），并适當配圖

BUG描述模版參考知乎：怎樣用簡潔又清楚的語言将 bug 描述清楚？

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.測試人員姓名：蔡宇航

6.測試環境（包括但是不僅限于使用的裝置名稱，測試标的物的版本，作業系統的資訊。等等一切相關資訊）：IPhone6s，作業系統及版本：IOS12.1

7.缺陷發生的位置（子產品）：“易班工具”界面

8.預期結果：正常登陸。

10.重制步驟：打開app依次點選：易班工具。

Bug3

1.标題：成績查詢界面，學分可以顯示，但是單科績點無法顯示，單學期績點無法顯示。

4.缺陷的等級：初級

5.缺陷的優先級（等級表明缺陷的嚴重程度，優先級表明修複缺陷的優先程度）：初級

7.缺陷發生的位置（子產品）：“成績界面”

8.預期結果：正常顯示單科績點。

9.實際結果：績點一列顯示為“-”。

10.重制步驟：打開app依次點選：成績。

第十次作業 - 項目測評（團隊）

Bug4

1.标題：驗證碼識别功能識别錯誤.

7.缺陷發生的位置（子產品）：“登陸界面”

8.預期結果：正常識别驗證碼并完成填寫。

9.實際結果：有些驗證碼識别錯誤。

10.重制步驟：打開app依次點選：進入登陸界面。

第十次作業 - 項目測評（團隊）

1.标題：課程表在重新整理的過程中點選“+”，“+”功能消失

2.測試人員姓名：朱志豪

6.測試環境（包括但是不僅限于使用的裝置名稱，測試标的物的版本，作業系統的資訊。等等一切相關資訊）：IPhone6s，作業系統及版本：Android 8.0.0

7.缺陷發生的位置（子產品）：“課程表界面”

8.預期結果：

9.實際結果：

10.重制步驟：打開app依次點選：“+” -> “重新整理” -> 在重新整理過程中點選“+”

第十次作業 - 項目測評（團隊）

5. 你覺得為什麼這個産品組的人沒有發現這些bug?

開發人員在測試時沒有注意到這些細節。
開發人員忽略了通路教務處可能出現的問題，也有可能是教務處自身的失誤造成了這些BUG的産生。
運用不同IOS版本進行測試，可能開發團隊的測試機沒有BUG，但是使用者的某款手機有BUG。
驗證碼識别程式自身存在的BUG。

可能是測試人員不像我會手賤地在重新整理的時候點“+”吧。

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.如果你是項目經理，如何提高進而在競争中勝出？

如我我是項目經理，我将會從以下幾方面提高我們産品的競争力：
- 品質保障：高品質是一個有競争力的産品必須具備的條件。作為一個産品經理，我将從以下兩方面提高軟體品質：
  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		75.8

說明：第八組的分數在經過溝通之後對方同意修改，改為81。

貢獻度

名		工作量比例
燊	10%
鈞昊
俞辛
宏岩	14%
喜源	11%
柏濤
宇航
恺翔
志豪	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	計劃	60
· Estimate	· 估計這個任務需要多少時間	30
Development	開發	720	780
· Analysis	· 需求分析 (包括學習新技術)	360
· Design Spec	· 生成設計文檔
· Design Review	· 設計複審
· Coding Standard	· 代碼規範 (為目前的開發制定合适的規範)	10
· Design	· 具體設計	90	120
· Coding	· 具體編碼
· Code Review	· 代碼複審
· Test	· 測試（自我測試，修改代碼，送出修改）	20
Reporting	報告	130
· Test Repor	· 測試報告
· Size Measurement	· 計算工作量
· Postmortem & Process Improvement Plan	· 事後總結, 并提出過程改進計劃
合計	800	770

個人學習進度條

N周	新增代碼（行）	累計代碼（行）	本周學習耗時(小時)	累計學習耗時（小時）	重要成長
2		22	Balsamiq Mockup 原型設計工具
3	200			32	學習并行程式設計
			37	學會需求分析報告的撰寫
			44	學會了簡單的視訊剪輯
	100	300	15	59
	50	350	11	70	熟悉python程式編寫
8		450			學習OPENMP
9		550		105	學習MPI