實驗十四 團隊項目評審&課程學習總結

一：1.結合本學期課程學習內容，對比《實驗一 軟件工程準備》的任務5你所提的問題（給出提問博客連接），嘗試對提出問題進行解答，並闡明是如何經過學習/實踐/討論弄清楚的；學習中是否產生了新的問題？若有，請提出。
一、提問博客連接地址：http://www.javashuo.com/article/p-tgqbsupd-ks.html
二、對問題的回答：
問題1：本書第四章講的是「兩人合做」，在該章節中講述了代碼規範，代碼複審，兩人合做的技巧等......但沒有涉及到一個問題，讓我很疑慮，在一個開發團隊中，每一個人編寫代碼的水平各不相同，那麼，如何在團隊中合理分配每人的任務？使每一個人都能在團隊中出色的表現，從中受益，提升水平。
回答：首先呢，在一個團隊中，成員之間必然有着技術性的差別，在團隊開發過程當中，能夠根據團隊對的規模，項目的大小來靈活的調整團隊的成員分配，但根據描述，比較適合的是功能團隊模式，該團隊是把一個大的項目分紅若干個功能，每個小團隊共同去完成一個功能，這個小團隊裏面有技術大牛和菜鳥共同組成，菜鳥向大牛去學習，大牛帶着菜鳥們共同完成該功能
問題2：在第11章231頁，有下面這樣一段話 「寫好代碼後，小飛對照設計文檔和代碼指南進行自我複審，重構代碼。」 對於「代碼重構」不是很清楚。
回答：我查了一些資料，重構就是經過調整程序代碼，但並不改變程序的功能特徵，達到改善軟件的質量、性能，使程序的設計模式和架構更趨合理，更容易被理解，提升軟件的擴展性和維護性。資料中都在強調重構的好處，而重構在「軟件系統的過程, 它不會改變代碼的外部行爲, 同時改善其內部結構。 這是一種嚴格的清理代碼的方法, 它能夠最大限度地減小引入錯誤的可能性。 本質上, 當重構代碼時, 是在編寫代碼以後改進它的設計」。
問題3：在通讀到本書的最後時，老師留了一個問題：「軟件工程師在企業中是勞動密集型的工人，仍是有首創性的專業人士？他們對軟件企業的成敗負有多大的責任？」
回答： 經過查閱資料，個人理解是這樣的：軟件工程師在企業中不該該是勞動密集型的工人，而應該是有首創性的專業人士。可是在中國的諸多企業中，包括外企，每每都是專業人士帶領着一羣勞動密集型的工人在工做，普通的程序員再聰明，也沒有能力在大方向上改變公司的決策。軟件工程師與軟件企業的成敗息息相關，但對軟件企業成敗負多大的責任，倒是要多方面考慮的問題。軟件企業的失敗是有多方面緣由的形成的，好比經營模式、領導層的緣由，員工的緣由。他們所要負責的只是其中一部分。所以軟件企業的成敗不該該由軟件工程師來負主要責任，若是要把這個責任強加到軟件工程師身上，那麼至少也要給軟件工程師同等的發聲權利。

2、總結本身在項目的 可行性分析/需求分析/軟件設計/實現/測試/項目驗收/中學到了哪些「知識點」。
需求階段：爲了更好的理解問題，人們經常採用創建模型的方法，除了建立分析模型以外，在需求分析階段還應該寫出軟件需求規格說明書，通過嚴格評審並獲得用戶確認以後，做爲這個階段的最終成果。一般主要從一致性、完整性、現實性和有效性4個方面複審軟件需求規格說明書。
設計階段：自頂向下逐步求精是進行軟件結構設計的經常使用途徑，可是，若是已經有了詳細的數據流圖，也可使用面向數據流的設計方法，用形式化的方法由數據流圖映射出軟件結構，這樣映射出來的只是軟件的初步結構，還必須根據設計原理而且參考啓發式規則，認真分析和改進軟件的初步結構，以獲得質量更高的模塊和更合理的軟件結構。
實現階段：實現階段包括編碼和測試，所謂編碼就是把軟件設計結果翻譯成用某種程序設計語言書寫的過程。目前軟件測試仍然是保證軟件質量的關鍵步驟，它是對軟件規格說明書、設計和編碼的最後複審。
測試階段：白盒測試和黑盒測試是軟件測試的兩類基本方法，這兩類方法各有所長，相互補充，一般，在測試過程當中早期階段主要使用白盒測試，而在測試過程的後期階段主要使用黑盒測試方法。
發佈階段：在這次團隊項目中，咱們小組開發的是旅遊管理系統，因此因爲各類緣由，此項目並未發佈。
維護階段：預防性維護實質上就是軟件再工程，典型的軟件再工程過程模型定義了庫存目錄分析、文檔重構、逆向過程、代碼重構、數據重構、正向過程6類活動。

3、結合我的項目/結對編程/團隊項目的我的經歷，談談心得。
經歷過，也算是給本身博得一次發言權， 你纔會知道那是什麼 ， 過程怎樣，該怎麼作，遇到問題如何解決， 歷數心得，受益不淺。
從整個項目的過程來看， 團隊合做中須要溝通、分工、協做和監督。只有作好這四項纔算是一個好的合做團隊。首先， 團隊合做 最基本的技能就是溝通。溝通的目的就是讓別人瞭解你的想法，由於每一個人考慮問題的時候總會有各類各樣的看法 ，也會出現各式各樣的誤差，咱們只有經過溝通來綜合全部人的好的想法， 以 減小走彎路， 從而讓事情進行的更順利。再其次，團隊合做中協做是必不可少的。在項目組中各成員都明確 分工 了本身的任務， 明確 了本身的任務分工， 就須要你們單獨工做的同時 又去配合其餘人。
瞭解需求、分析、設計、編程、壘代碼、別人看來，計算機的東西、 枯燥、乏味、無聊，還很容易讓人浮躁，在我看來，也很容易讓人絕望，由於不是簡單的一觸而就的東西，須要你花時間，花心思，你想，要讓人與機器溝通，要讓人以機器工做的角度來思考，還得考慮用戶須要什麼，各類問題雜合，確實是不太容易 。一路走，都是很枯燥乏味的，沒有一點甘霖，也沒有但願，代碼，代碼，代碼，頭暈眼花……只有當運行鍵後再也不有那麼多錯誤和警告，當功能一個一個都能按咱們的設計實現，當成果漂漂亮亮地展示在面前，那就是咱們的但願，咱們的動力，是咱們最須要的光明。
這樣的實踐，主題面向的是創新，若是你有想法，有能力，有自信，就很值得去嘗試一下， 不試一下，誰都不知道本身有多少，到底行不行，而能從中得到的東西寥寥數語豈能言說盡，只有當你身處其中，經歷過，體驗過，不管是枯燥，絕望， 仍是最後的光明幸福，你才知道其中的滋味。不要放棄嘗試，任什麼時候候都不。一路走 ，一路調解，一路堅持。

4、總結這門課程的實踐總結和給你帶來的提高
（1）統計在軟件工程實踐中，你完成了多少行的代碼；20000多行
（2）你在軟件工程實踐的各次做業分別花了多少時間？

時間（h） 做業
8 實驗一 軟件工程準備
8 實驗二 軟件工程我的項目
10 實驗三 做業互評與改進
12 實驗四 附加實驗 項目互評
15 實驗五 團隊做業1：軟件研發團隊組建
12 實驗六 團隊做業2：團隊項目選題
18 實驗七 團隊做業3：團隊項目原型設計與開發
16 實驗八 團隊做業4：基於原型的團隊項目需求調研與分析
16 實驗九 團隊做業5：團隊項目需求改進與系統設計
20 實驗十 團隊做業6：團隊項目系統設計改進與詳細設計
30 實驗十一 團隊做業7：團隊項目設計完善&編碼
26 實驗十二 團隊做業8：軟件測試與Alpha衝刺
25 實驗十三 團隊做業9：Beta衝刺與團隊項目驗收
（3）哪一次做業讓你印象最深入？爲何？

答：整個一學期下來，每次做業都在很認真的去完成，因此對於這門課程，我以爲不管是在學習上仍是作做業的耐心上收穫都不少。尤爲是在團隊項目設計完善過程當中，印象最深的應該是項目通過編碼和修改，出現了不少bug，在自習室整整呆了一天，盯了一天的電腦，修改了一天的代碼，眼睛真的是太累了，心情也很無奈崩潰，因此才體會到了軟件工程師的不容易，好在最後大問題已經解決，順利的完成了項目驗收的任務。
（4）累計花了多少個小時在軟件工程實踐上？平均每週花多少個小時？
答：累計共花了160個小時在軟件工程實踐上，平均每週大約花8個小時在軟件工程實踐上。
（5）你學習和掌握的新語言、新平臺；
答：項目所用到的java語言以前就有學習、這學期學習到了博客園、GitHub、雨課堂、慕課網。
（6）填寫下表，總結一學期的學習中，你學習或使用的軟件工程開發工具、開發方法和建模方法；

軟件開發工具、項目管理工具 軟件開發方法 軟件建模方法
墨刀、Visio、在線做圖工具ProcessOn、www.leangoo.con、navicate等 原型開發方法，面向對象的軟件開發方法等 面向對象建模（用例圖、類圖、包圖、流程圖、時序圖等）
（7）其餘方面的收穫或提高。
答：一個好的團隊，是成功的須要， 各成員的專業知識與技能儲備 ， 成員間的優點互補， 「 物之爲用 」 ，只有當你 「 有 」 ，須要的時候隨時均可以拿出來 「 用 」 。 此外， 一我的的力量畢竟有限，不管是智力，能力仍是精力，都有所不能及的地方，集一個團隊的力量，發揮整個團隊的做用，這樣就能解決更多的問題，打敗更多的困難。

5、你認爲目前的課程存在哪些問題，你有什麼更好的建議。
我認爲軟件工程這門課應該側重於實驗課的學習，一個好的項目須要團隊去花費時間去開發和設計，可是理論知識也當然重要，理論實踐相結合纔是學好一門課程的前提。