【1414軟工助教】助教總結

一、開學初對自己的期望

最初自我介紹時，沒有列出對自己的期望。我想做的是減少同學們完成作業的阻力，以及做一些方向性的引導。

為此我做了兩件事：

• 變更了幾次作業的表述和刪除不必要的內容，使得同學們能夠更容易理解作業的要求。

• 寫了三篇博客，分別是：

  • 【1414軟工助教】在博客中插入代碼
  • 【1414軟工助教】作業博客高分指南 （可惜寫得太晚，在個人和結對作業結束后才發布）
  • 【1414軟工助教】沖刺博客指南 （在 Beta 沖刺前發布）。

  寫這些博客的目的是使同學們更清楚作業應該做什么，哪些是重點，哪些是推薦做的和不應該做的。這三篇都有強調的一點就是“詳細描述你都做了什么，或者思路是怎么樣的”。

二、班級

教師： 張敏老師（博客）

班級： 網絡四班（博客）

三、發布的助教博客

本學期共發布了 25 篇與助教相關的博客。

其中評分博客 15 篇：

個人作業1：四則運算控制台	結對項目1：GUI	個人作業2：案例分析
結對項目2：單元測試	團隊作業1：團隊展示	團隊作業2：需求分析&原型設計
團隊作業3：需求改進&系統設計	團隊作業4：Alpha版本項目沖刺	團隊作業5：Alpha測試與發布
團隊作業6：展示博客	個人作業3：Alpha總結	團隊作業7：Alpha復審與事后分析
團隊作業8：Beta版本項目沖刺	團隊作業9：Beta測試與發布	團隊作業10：Beta復審與事后分析

其余 10 篇博客為：

自我介紹	助教鏈接匯總	學生博客和Coding匯總
團隊博客匯總	【福大軟工】軟件案例分析優秀鏈接匯總
在博客中插入代碼	作業博客高分指南	沖刺博客指南
模塊化（零）：綜述	模塊化一：提取模塊

怎么一大堆匯總...
后面的模塊化沒有堅持寫下去，后面的是跟面向對象相關的。但老實說我寫的這份代碼是否足夠面向對象我都沒有很大把握。

累計 評論博客 380 次左右，每頁 20 個評論，共19頁，但其中有一些跟助教無關的評論。

四、助教表現自我評價

整體來看，我對自己的表現相當不滿意。初期沒有明確主要任務，整個學期缺乏和老師以及同學的交流，經常評成績拖到很晚。

但也不是一無是處。無論是給同學們的博客寫評論或者評分，我都非常認真，雖然也因此花了很多時間。此外我還修改了幾次作業的描述，力求作業要求更加清晰。我也制定了4次評分標准以及參與修改了幾次評分標准。

1. 在初期沒有明確主線任務

   及時評論同學們的博客和盡快給出成績是最基本的兩項工作，而我卻幾次把它們的優先度調低。例如有一次在還沒有給出成績的情況下，就去寫模塊化教程；還有一次是為了寫出單元測試 C++版 的空殼（相較於其他語言，C++版的真是麻煩），延遲評成績……

   這暴露了我的兩個缺點：

   • 雖然分清了任務的主次，但仍然忍不住要去做次要任務；
   • 容易對別人給出的新的期望做過度的回應（這可能就是棟哥覺得我做決定的時候“卡卡的”的原因）。

   這奇怪的【滿足自己】的方式……這兩點如果不改，在工作上還會吃到很多苦。

2. 缺乏和老師以及同學的交流

   這學期主動跟老師和同學交流的次數實在是少，基本上是同學們有問題來問我。這個學期有和張老師討論黃杉的分配問題，有和對給出的分數不解的同學的解釋和交流，有去找 PM 詢問關於團隊的問題……

   不過對於如何主動跟他們聊天，我也蠻苦惱的。現在我才想起來，可以多向身邊的人請教呀！

   我在 Beta 階段開始的時候，和同學交流這個方面做了一定的改進，創建了一個微信群，把各個團隊的 PM 都拉進去以討論一些關於項目管理的問題。

3. 評成績拖到很晚

   前期 29 份作業都要評，而且評分項比較多，感覺還是蠻耗時間的。雖然耗時最大的部分在於評論博客，但評成績的時候也花了很多時間。雖然用了 Excel 表格來處理一些數據，但操作起來還是挺麻煩。但是這都不是最大的問題。

   團隊項目開始后，每次只要給五份博客評分就行了，但是還是一拖再拖。我想可能是我對看這些博客產生了一種恐懼感。每次評分都要看一大堆文字，評分完還要寫一堆文字，實在是難受。這跟看代碼不一樣，看代碼是一種享受（寫代碼就更是了）。

   通常評分博客要指出同學們的一些問題，以及優秀的博客。有些問題反復強調都沒有任何改進，不得不說，我的積極性的確因此受到了打擊。給的建議同學不聽，給了好多評論，卻少有人回復。雖然老師說這是正常的，但我仍然感到傷心。我不是隨便給出評論的，有時候會反復看同一篇博客，爭取找出至少三個可以改進的地方，或者詢問問題。后來我發覺我這樣做是不對的，這樣是 自己間接地打擊自己的信心 。於是減少到找出一個可以改進的地方，只有收到回復之后才繼續尋找其他可以改進的地方，或者問其他問題。

4. 評分嚴格

   我給的分數通常都很低，特別是那些說得很模糊的博客。做了什么，應該詳細地說明，越詳細越清晰就越好。我有時候在想，是不是我的要求太高了？

   到后期，我減少了倒扣分的次數。因為如果像前期那樣倒扣分，團隊的分數可能經常拿到負分……

   像這樣自己做決定的地方還有幾個，我太想在助教的工作中加入自己的想法。后來我發現這樣做不合適，畢竟是第一次做軟工助教，對很多問題的了解都不夠深入，應該先照着老師的要求做。“嚴格執行已有的規則，以后再改進規則。”

   我發現在這次助教工作中，我犯的很多錯誤都是不應該的。很多道理我都懂，但是不知為何總是會做出與已經懂的道理相反的事情來。

5. 評分標准

   在制定評分標准的時候，我想要減少主觀因素帶來的影響。因此這些評分標准的特點是詳細，詳細到每個評分項在碰到某個情況時應該扣多少分。我不太分得清這樣做到底增加了工作量還是減少了工作量……

   這一點需要改進的地方是：在評分項內划分檔次，針對某個情況只給出對應的檔次，而不是某個分數。這樣給了助教一定的決定權但又不會受到太多主觀因素的影響。

五、作業的問題

表述的問題

在我自己查看作業描述的時候，發現讀起來比較費勁。有的是表達不夠簡潔，有的是作業要求提出是不夠直接。

拿兩個例子來說明：

1. 結對編程2——單元測試

   原文片段1：

   一旦我們分離出核心模塊，就可以針對該核心模塊一步一步開發並做好單元測試，什么是單元測試？請閱讀並學習《構建之法》第二章關於單元測試，回歸測試的內容。
   
   好了，你一定針對單元測試做了一番學習：
   
   * 閱讀並學習了課本上單元測試例子，以及代碼覆蓋率的知識；
   
   * 或者你還去bing.com，google.com了一把單元測試，JUnit；例如
       * http://www.cnblogs.com/greyzeng/p/4439080.html
       * http://www.cnblogs.com/zhengrui0452/p/6507630.html
   
   * 如果你是C/C++寫的，你還去挖了一遍CUnit；
       * http://cunit.sourceforge.net/example.html
   
   * 或者你直接用了C的 #include
   
   * 或者你用了C#，學習了課本上提到的Visual Studio的單元測試框架；
       * 請參考《構建之法》
   
   總之，你找到了適合自己語言的一種可以進行單元測試的工具。
   

   問題在於好多“或者”以及多余的描述。

   修改后：

   一旦我們分離出核心模塊，就可以針對該核心模塊一步一步開發並做好單元測試，什么是單元測試？

   請閱讀《構建之法（第二版）》第二章 2.1單元測試和2.2回歸測試。

   語言	推薦測試框架或工具	參考鏈接
   JAVA	JUnit	參考鏈接1 ， 參考鏈接2
   C 或者 C++	CUnit	參考鏈接
   C#	VSTS	《構建之法》

   原文片段2：

   那么，勤快的你已經迫不及待的想要自己上手來測一把：
   
       1. 通過單元測試代碼，測試加法是否能正確工作；
       2. 通過單元測試代碼，測試加減乘除功能。
       3. 通過單元測試代碼，測試計算類對於各種參數的支持：
   
           a. 輸入是有錯誤的，例如 “1 ++ 2”，
   
           b. 在數值范圍是 -1000 .. 1000 的時候，傳進去 “10000 + 32768”,
   
           c. 或者是 “ 248 / 0” 怎么辦?
   
           d. 怎么告訴函數的調用者 “你錯了”? 把返回的字符串定義為 “-1” 來表示？
   
           e. 那么如果真的計算結果是 “-1” 又怎么處理呢?
   

   問題在於 1 和 2 有包含關系；d 和 e 不屬於參數；問號太多，作業要求應盡量用陳述句表達。

   在查看同學們博客的時候，發現某些同學沒有完成以上的某些要求。可能是他們能力不足，也可能是他們認為以上 a b c d e 不屬於強制要求的部分。

   修改后：

   了解單元測試后，編寫代碼來完成以下單元測試：

   1. 驗證加、減、乘、除四個功能的正確性

   2. 負責計算的類對各種參數的支持情況，保證以下幾種情況不會使程序出錯：

      • 錯誤的輸入。如 “1 ++ 2” ；
      • 輸入的數字大於程序規定的數值范圍。如在數值范圍規定為 [-1000, 1000] 的情況下，傳入 “10000 + 32768” 這樣的表達式；
      • 除零錯誤。如 “ 248 / 0” ；

      如果出現了以上幾種輸入，需要在負責計算或者驗證的方法內給調用者返回錯誤信息。

      注：我們經常使用 “-1” 來表示出錯了，但在這里如果使用 “-1” ，計算結果真的是 “-1” 的情況下該如何處理？

2. 個人作業3——個人總結（Alpha階段）

   原文片段：

   我們在alpha 結束之后， 每位寫一個博客， 總結自己的alpha 過程， 同時，大家一定會在過程中產生了很多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 提出關於軟件工程的 5 個問題。
   

   在查看同學們博客的時候，發現幾個同學漏掉了 “總結自己的alpha 過程” 這個要求。

   修改后：

   寫一篇博客，內容包括兩個部分：

   1. 總結自己在 Alpha 沖刺過程中的貢獻、不足和體會；
   2. 結合你的讀書（教材，博客，參考書）或實踐，提出關於軟件工程的 5 個問題；

檢查點過多的問題

例如在 個人作業2——英語學習APP案例分析 中，我最初統計的檢查點個數達到了 22 個。

是否能夠針對不同學校的學生定制不同版本的作業呢？除了必須保留的核心部分，其余部分做適當增刪。

其他細節問題

例如最初的准備作業中，強制規定一種格式。這樣用程序自動獲取同學們的信息時，就能准確地獲取所有數據。

六、幾點建議

張敏老師首次嘗試這樣的教學方式實在是不容易，但也做得挺好的。有些問題一開始很難意識到，因此不好防范。為了今后課程越來越好，我提幾點建議：

1. 強制要求同學們使用 Markdown 。這學期只是推薦使用Markdown （軟件工程第一周預備作業），同學們的博客排版看起來不太舒服。
   當然也要考慮到同學們學習 Markdown 的難度。雖然在我們看來，Markdown 的語法超級簡單，但是對於第一次接觸 Markdown 的他們，可能需要有好的資料來幫他們適應。

2. 強調 Git 和 Coding 的使用。源代碼管理是軟件工程的一項內容，而只有極少數人學到這一項。直到 Beta 沖刺結束后，4班的所有團隊都沒有用好 Git 和 Coding，我在他們博客下面反復說和扣除分數都沒用。希望老師能當面強調。

   這一項是很重要的評分依據。可以看到同學們每天實際上都做了什么，做的東西是否跟博客上描述的【已完成任務】一致。但是幾個團隊都是好幾天提交一次，那么【已完成任務】就可以造假。

   Coding 的使用主要包括：

   • Fork
   • Pull Request
   • issues （討論）

3. 用 Coding 上的 issues （也就是【討論】）來代替 Leangoo 。Leangoo 的好處在於生成燃盡圖，壞處在於不公開。在兩個團隊將我加入 Leangoo 后，我看到他們的燃盡圖是假的，用於應付而生成。

   雖然可以讓各個團隊將助教加入他們的Leangoo，但是除此之外的其他人仍然看不到。

   不過如果不使用 Leangoo，那么如何生成燃盡圖呢？這是一個問題。如果解決不了，只能忽略該建議。

   有人做出將 GitHub issues 轉化為燃盡圖的工具，但針對 Coding 的工具卻找不到。

4. 在作業布置前就讓助教先做好評分標准，並放到作業博客上。這學期做的改進是在【評分基准】里給出了大致內容。之后最好能給出詳細的評分標准，也就是這學期助教在評分博客中展示的評分標准。

   這樣做的好處是讓同學們能夠隨時知道自己哪一點沒有做，哪一點沒有做好，他們能得多少分自己能夠大概知道。

七、同學們對課程的建議及其他

共有八個同學做了這次的附加作業，以下用 1. 2. 3. ... 8. 來標識不同同學的回答。

（1）你認為每次項目的評分標准存在哪些問題，你認為的合理評分准則是怎么樣的

1. 個人：發布的題目里沒有具體的評分細則，個人作業環節的分數懸殊很大。個人認為可以在發布題目的時候就將各項分數寫在題目要求中。

   結對：這部分很難斷定兩個同學分分數，容易出現只有一個人做了全部，另一個沾了光。應該設置相應分差值。

   團隊：這部分分數主要是助教根據博客情況來評分，但其實在博客上容易摻假，有點團隊可能一點代碼都沒怎么寫，在最后展示環節根本展示不出來，但是博客的分數卻十分高。建議展示環節的分值可以設得高一點。

2. 從貢獻度、完成度、完成質量、是否進步（比如因為專業知識掌握不多，第一次沒有做出來，但是通過學習，第二次能自己順利完成作業）等角度進行評分

   在個人作業方面，增加個人進步這一注重點，

   在結對編程中，要考慮角色分配的比重與個人貢獻度

   在團隊作業中，我希望能把alpha beta階段的團隊博客拆分出來，每個人自己當天的任務和都做到了什么，學到了什么都寫在自己博客上，每個人都要寫，不然很容易出現某些學生其實什么都沒有做，博客也沒有參與寫，全程划水。然后在alpha beta階段結束時，上交一份匯總博客（內容包括小組成員分工，項目完成度，燃盡圖，各成員博客鏈接等）

3. 個人：在得知項目分的時候才看到具體的得分點，容易丟失細節分。

   合理評分標准：在發布作業時應該明細各個得分點，方便同學根據要求寫博客。

   結對：在coding部分結對兩人分數不應該默認相同，應該有相對的貢獻分，雖然大家比較主張貢獻相同，但對一些隊員完全沒做事，自己完成所有工作的人來說至少有選擇是否需要說明這種情況的機會。

   合理評分標准：設有結對貢獻分，但不需要強制要求成員貢獻分必須不同，給成員自己選擇的權利。

   團隊：評分以博客展示為主，未免有些不合理。這樣的評分標准對一些表達的相對簡單，但項目完成度較高的團隊來說有很多的影響，團隊分所占的比例較大，很影響團隊中成員最終的成績。

   合理評分標准：設有團隊貢獻分，但不需要強制要求成員貢獻分必須不同，給成員自己選擇的權利。以博客展現和項目完成度兩方面來評分。

4. 個人：感覺博客所占評分標准過重，有的時候花很長時間完善代碼，但博客寫的沒別人好，或者沒有寫全得分點，導致最后分數偏低。導致大家更加關注如何寫好博客，而不是代碼，感覺有點輕重倒置。我認為可以把博客和代碼的按一定的比重區分開，比如：博客占40%，代碼占60%。

   結對：我認為可以要求小組公開任務分配情況，或者加入隊員互評作為助教評分的參考。

   團隊：對“每個人貢獻分必須不一致”這一點不是很認同。作為一個學生團體，很多時候大家在團隊中所做的貢獻都是差不多的。即使可能有一兩個作為主力在編代碼，可是其他人也可能在其他方面也付出了很多（比如“寫博客”）。我認為可以考慮附加分的形式，由團隊自己決定是否給團隊的某一或兩位成員加分。且團隊沖刺階段所占的分數比重過大，因為一個點沒有寫被扣了分，7天累加扣了近10分，后面感覺再怎么努力也很難追回。我認為一個沖刺階段可以按照1次作業分數計算，而不是7次。

5. 在評分標准這一塊，真的很詳細，從個人到結對再到團隊，真的越來越詳細，我覺得老師和助教在這個方面真的很辛苦，做的很棒了。

6. 個人作業：不知道具體的得分點在哪，結果博客沒寫出重點，分數就比較低了。可以在發布作業的時候公布得分點，這樣能讓我們充分展示自己的代碼成果。

   結對編程：大家的任務分配不同，可以設置一定的貢獻值。

   團隊作業：沖刺階段的博客評分可以最后統一評，不用依照每天的博客給分。

7. 感覺不僅是個人項目，對於結對/團隊項目而言也同樣存在這樣的問題，即過分重視博客的展現，實際做的努力往往在展示中不好體現出來，有的同學/團隊態度很認真、做事很努力，但是由於基礎比較差而沒能寫出漂亮的程序，但是在他（們）做的過程中獲得的進步卻並不比那些基礎好的同學小。但是由於博客評分占比非常大，所以在博客上展示出來的成果由於並不突出而得到較低的評分，這樣還是挺受打擊的。我覺得做任何事情態度永遠是第一位，三流的點子一流的執行遠比一流的點子三流的執行要有效的多。所以我希望將展示博客的評分占比稍微降一下，多關注一下那些基礎差但是很努力的同學（團隊）。

8. 1）在個人編程上有些編程能力比較強的人可能投入的時間並不是很多，但是對於編程較差的人需要花很多的時間來完成，這樣的話基礎差的人時間掃對於博客的編寫質量就不會很 高，花很多的時間的的分還不高。這個真的是一個很難解決的問題。

   2）在結對上面不僅有編學程能力較好的和編程差的同學的結合會導致大部分編程好的同學在寫可以說是付出較多的人，但是博客編寫不怎樣就會導致反而分不高的問題會讓人失衡，編程水平相當的人也會有一定的問題存在。我覺得結對編程也可以出現貢獻分的

   3）在團隊評分上應該不僅是看表面很更應該關注背后的東西。

   總結：不論是個人還是組隊和團隊我覺得博客的比重真的占太多是的有的人實際做的很多的人或這是小組卻因為博客的問題而沒有得到對應的分數，這樣的結果會很打擊人。

（2）你的團隊項目是否成功，如果重來一次你是否還會選擇這個團隊，為什么成功/失敗

1. 我個人認為是成功的，雖然我們團隊在過程中遇到過一些困難和問題，但我們團隊最終還是完成了，所以是成功的。

   重來一次我還會選擇這個團隊，因為我們相互磨合，配合還算默契。

2. 算是成功。我都可以，我個人覺得我這個人適應能力強，而且沒那么多挑剔，在哪里都可以，我都可以努力的去完成項目，真正的學到東西。
   這門課上，我確實花費了很多很多時間和精力。雖然最后分數不高（因為博客沒有即時交），對於我個人的提升是非常大的

3. 我的團隊項目總體來說是成功的，雖然與最初的需求分析有些許偏差，但基本的功能都已經實現，可以使用。如果重來一次當然還會選擇這個團隊，雖然中間有懈怠，但成員們也都盡可能完成分內的工作，不存在有人什么都沒做，有人包攬所有工作的現象，所以最終項目才能成功。

4. 我認為團隊總體還算成功的。如果再來一次我也還會選擇這個團隊。雖然在這整個團隊合作的過程中，我們遇到了很多的困難，也經歷了所有人心態都很低迷的期間。但大家也都沒有放棄過，堅持到了最后。而且在這個期間，大家互相也變得更加了解，有了一定的默契。

5. 我覺得我們團隊是成功的，因為雖然在這個過程中我們可能會出現一點小問題，比如有時候博客沒能及時上交，或者誰誰誰的任務太難沒能及時完成，但是通過我們的共同努力，我們還是把一個app做出來了。雖然這個app沒有完成全部的功能，像光榮榜這些功能沒有能實現，但是我們基本的功能都有實現了，像隨機發牌啊，計算啊，背景音樂啊等等，作為一個app，是能讓人玩的起來的，所以我覺得也算是成功了吧，畢竟大家斗沒經驗。

6. 我認為算是比較成功了，因為最后成品也做出來了，雖然部分功能沒有實現。如果重來一次，我還會選擇這個團隊，因為我覺得我們配合很默契，分工也比較合適。

7. 我認為我們團隊起碼在態度上是成功的，我們小組真的沒有大神一般的人物，全是基礎很差的同學，對於項目的實現基本上就是現學現賣，時間非常趕，雖說沒有做出華麗的界面和強大的功能，但是我們確實花了大量時間做了很多事情。可能在成果上我們是失敗的，但是我們態度上是認真對待的，也學到了很多東西，在這一點上我覺得我們還是成功的。如果重來一次，我還會選擇這個團隊。

8. 為什么不要呢？團隊合作會有推脫會有不愉快但這就是團隊，團隊的團結和認真態度做到了我覺得我們就是成功的。

（3）總結一下你們團隊在做項目時大家的時間安排情況

1. 我們代碼部分是根據每次小組會議中商討的去分配，也都有寫在博客中，大家根據自己博客中所制定的計划自行進行安排。而撰寫博客部分，每日博客是團隊成員輪流根據團隊實際情況輪流完成。

2. 別人我不知道，這個學期所有空余時間都在圖書館寫實驗報告，做軟工項目

3. 團隊在做項目的時候有估量每個任務需要花費的時間，對項目中每一個任務都安排相應的成員完成，但團隊成員在完成過程中可能因為自身效率問題導致所花費的時間也不同。總之，大家都會在自己課余時間完成自己分配到的任務。

4. 大家基本上是各寫各的部分，然后利用課間期間和周末晚上開會討論。即使有成員因為身體原因經常不在學校，也依然能夠按照要求完成自己所分配的任務。

5. 我覺得我的時間安排就不大合理，上次的個人總結就是個人原因沒能及時上交，是我的問題，后面也沒有問同學如何處理，做事情台拖拉，不夠主動，也因此吃了虧被扣了分。也因此得到了教訓，吃一塹長一智，以后再也Q不敢了。隊友們基本都能按時完成任務，畢竟是團隊，不能拖大家的后腿，所以大家完成的還算及時，不過大家也是在最后的時間里趕工，這個好像是大家的通病（QAQ），要改。

6. 我們的代碼分配是根據小組會議的商討，然后大家各自完成自己的部分，每天晚上會有固定的交流。而撰寫博客部分，博客是團隊成員輪流根據團隊實際情況完成，基本大家都有寫。

7. 我們團隊中，隊長分配的任務大部分都是很明確的，大家做好分內的事情就可以了，有些事情有交集大家也都會互相交流探討解決方案，由於分配到的任務不一樣，個人的基礎也不一樣，所以也很難量化每個人的工作，但是能肯定的是大家都認認真真做好了自己分內的工作。

8. 嘿嘿！主要還是隊長的安排，按時按量完成自己應該做的事情。

（4）軟件工程這門學問有很多 “知識點”， 這門課強調 “做中學” - 在實踐中學習知識點。請問你們在項目的 需求/設計/實現/測試/發布/維護 階段（一共6 個階段）中都學到了什么 “知識點”， 每個階段只要說明一個知識點就可以。

1. 需求：學會了如何撰寫需求說明書，需要描述用戶場景，從用戶的角度去分析需求，怎么樣將用戶所提需求具體化成實際需要開發的功能。

   設計：主要是學會了整個設計的流程，具體需要做些什么，如何設計，如何實現。

   實現：主要是對整個項目的各個方面進行總結和分析，學會如何在總結中學習和進步。

   測試：之前對測試這塊很不清楚，涉及不深。通過學習，知道了許多測試工具以及測試工具的使用，尤其是如何測試這部分。

   發布：知道了發布流程，如何展示項目，如何向用戶說明我們的應用。

   維護：知道了維護階段的具體做法，需要如何維護，如何使得用戶得到最好的用戶體驗。

2. 需求階段：學會了在項目開發之前一定要了解用戶需求，以及如何用圖表等將收集到的有用信息清晰的展示給自己的組員

   設計階段：學會了利用任務分解WBS等來清晰的構架項目輪廓，不僅能夠清晰的划分出任務模塊，還可以便於任務划分

   測試階段：學會了如何設計測試計划，如何多方面去測試項目（如性能測試，壓力測試，測試矩陣等）

   發布階段：學會了如何去發布軟件，並給出軟件介紹和運行環境

   維護階段：學會了運用騰訊的bugly來收集軟件反饋的日志信息，再通過不斷的完善優化對其進行維護

3. 需求：學到通過用戶調研來獲取用戶需求。

   設計：學習利用架構設計最大限度的滿足獲取的需求。

   實現：需要有明確的時間任務安排，按照設計文檔完成代碼實現項目需求。

   測試：通過撰寫測試報告可以明確項目所需做的測試、時間安排等。

   發布：從代碼完成到最后發布，經過了Alpha、Beta、ZBB等階段，不斷完善發布。

   維護：多次測試，發布后及時發現問題提供維護。

4. 需求階段：學會使用NABCD模型進行需求分析；

   設計階段：學會了把功能進行細分，從而提高編程效率；

   測試階段：學會使用Junit進行代碼測試；

   實現階段：學會使用燃盡圖掌握項目進度；

   發布階段：學會了發布的流程，以及展示博客的編寫，如何對項目進行展示；

   維護階段：對bug有了更深的理解，並學會根據用戶反饋進行維護、改進。

5. 在需求分析階段我學會了NABCD模型分析，設計階段學會使用墨刀來設計app的界面，在實現中學會搭建安卓壞境，用java語言編寫並打包成app，在測試環節學會了如何弄代碼覆蓋率，發布之后開了諸葛亮會議，維護就是不斷的升級和優化。

6. 需求階段：學會使用NABCD模型進行需求分析，還有如何撰寫需求說明書；

   設計階段：學會了使用功能優先級，選擇最核心的殺手功能；

   實現階段：學會使用燃盡圖掌握項目進度；

   測試階段：學會使用測試工具對代碼進行測試；

   發布階段：學會了展示博客的編寫，如何對項目進行展示；

   維護階段：學會了維護階段的具體做法，需要如何維護，如何使得用戶得到最好的用戶體驗。

7. 在需求中，我們學會了一種獲取用戶需求的方式——調查問卷；

   在設計中，我們學會了用一些在線工具完成項目的原型設計；

   在實現中，我們學會了前端與后端的聯系以及數據庫在程序設計中的重要性；

   在測試中，我們學會了對項目bug進行自查；

   在發布中，我們學會了對項目進行相關的宣傳；

   在維護中，我們學會了根據使用者的反饋進行相應調整。

8. 需求：需求分析對於一個項目是一個里程碑的存在，需求分析好對接下來項目的進展少走彎路起到質的作用。需求分析工具的使用、需求報告的編寫。

   設計：軟件是怎么解決需求的？通過圖形建模和思維導圖。

   實現：代碼模塊化的編寫。

   發布：要考慮用戶體驗是使用場景。

   測試：學會了使用測試工具和測試類。

   維護：保證服務器的正常運行。

八、致謝

感謝各位老師對我的包容與鼓勵，我這個助教做的實在是不合格。

感謝鄒欣老師和周筠老師提供給我一次做軟工助教的機會。鄒欣老師工作之余大量評論同學們的博客，實在令人佩服。我現在只能想着工作幾年之后想辦法為教育做一些貢獻，而鄒欣老師已經在教育方面做了很多貢獻，是一個好的榜樣。

感謝周筠老師和范飛龍老師與我分享經歷和指出我的問題。當時頭腦不冷靜，想着反駁而不是冷靜下來好好分析自己，做出了幼稚的表現。

感謝張敏老師對我的支持，同時也很抱歉，首次使用這種教學方式就碰到了我這樣的助教。

感謝同學們，你們讓我看到了我自己的很多不足之處，讓我得以不斷進步。這學期對你們太過於嚴格了，很少對你們的優秀之處進行表揚。

最后感謝張棟老師（棟哥），正因為您有改革的精神和實際的行動，我才有機會接觸構建之法，進而才有這段寶貴的經歷。