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

項目	內容
該做業所屬課程	任課教師博主主頁連接
做業要求	實驗十四 團隊項目評審&課程學習總結
課程學習目標	反思總結課程學習內容

任務一:各項目組在團隊項目Github倉庫中提交甲方填寫驗收意見的驗收意見表

團隊Github連接地址： https://github.com/struggle17/projecttable

任務二：我的學習總結

1.結合本學期課程學習內容，對比《實驗一 軟件工程準備》的任務5你所提的問題（給出提問博客連接），嘗試對提出問題進行解答，並闡明是如何經過學習/實踐/討論弄清楚的；學習中是否產生了新的問題？若有，請提出。

博客連接：通讀《構建之法》以後的問題

• 問題一：所謂軟件危機是指在計算機軟件的開發和維護的過程當中所遇到的一系列嚴重問題；軟件工程是指導計算機軟件開發和維護的一門工程科學。但在實際中咱們應該怎樣用軟件工程消除軟件危機？軟件工程的誕生是否從根本上消除了軟件危機，爲何？
  • 解答:軟件危機的產生緣由一方面與軟件自己的特色有關，另外一方面是與已有的軟件開發、維護的方法不正確有密切關係。解決軟件危機既要有技術措施（方法和工具），又要有必要的組織管理措施，即採用工程化的原則和方法組織軟件開發是擺脫軟件危機的一個主要出路。軟件工程是從技術和管理兩個方面來研究如何更好地開發和維護計算機軟件，從源頭上消除軟件危機。
    軟件工程的誕生只能大大減小軟件開發成本並提升軟件質量，不能從根本上消除軟件危機。
• 問題二：在構建之法的第五章第二小節中有講到了軟件的團隊模式，有主治醫師模式 ，明星模式，社區模式，業餘劇團模式等等，怎樣理解這些模式？
  • 解答：
    （1）主治醫師模式：一人爲主，其餘人爲此人服務。
    （2）明星模式：主治醫師模式到達極致，一人的光芒掩蓋全部人。
    （3）社區模式：每一個人參與本身感興趣的項目，貢獻力量，大部分人不拿報酬。
    （4）業餘劇團模式：在不一樣項目中每一個人扮演着不一樣的角色，可能隨着項目的改變，本身的角色也會發生變化。
    （5）祕密團隊模式：一些軟件項目在祕密狀態下進行，別人不知道他們具體在作什麼。
    （6）特工團隊模式：有一些有特殊技能的專業人士組成的團隊。
    （7）交響樂團模式：人員工具齊全，準備充足的團隊。
    （8）爵士樂模式：相對自由，有風險，人少且不靠譜。
    （9）功能團隊模式：具有不一樣能力的同事們平等協做，共同完成一個功能。
    （10）官僚模式：層層領導的團隊模式
• 問題三：在構建的過程當中會遇到各類各樣的問題，在咱們遇到這些問題時咱們應該從哪些方面分析構建失敗的緣由？爲何要進行重構？
  • 構建失敗的可能緣由：
    1.在沒有實質的數據和分析的狀況下，就接受一個強制的日程安排或完成日期/里程碑日期；
    2.添加過多的人員以實現不切實際的日程壓縮；
    3.未能考慮和調整需求的增加或變化並據此對計劃和預算預期進行必要的調整；
    4.忽略事實和統計數據的情緒化或」全憑直覺的「利益干係人談判；
  • 1.重構改進軟件設計，若是沒有重構，程序的設計會逐漸腐敗變質，重構很像是在整理代碼，你所作的就是讓全部東西回到應該的位置上；2.重構使軟件更容易理解；3.重構提升編程速度，良好的設計是快速開發的根本，事實上，擁有良好設計纔可能作到快速開發。

2.總結本身在項目的可行性分析/需求分析/軟件設計/實現/測試/項目驗收/中學到了哪些「知識點」

• 可行性分析:其目的是可否用最小的代價在儘量短的時間內肯定問題是否可以解決，可行性研究最根本的任務是對之後的行動方針提出建議。從技術可行性、經濟可行性和操做可行性三個方面分析項目的可行性；採用NABCD方法進行項目初步分析。
• 需求分析：需求分析是軟件定義時期的最後一個階段，它的基本任務是準確的回答「系統作什麼」這個問題；獲取需求分析的方法例如利用問卷調查法獲取項目的需求；利用原型開發工具mockplus進行原型設計；設計項目的數據流圖——創建功能模型的基礎；E-R圖等，需求分析過程創建的三種模型：數據模型、功能模型和行爲模型。
• 實現：一般把編碼和測試統稱爲實現，編碼就是把軟件設計結果翻譯成某種程序設計語言書寫的程序，編碼是對設計的進一步具體化，所以，程序的質量主要取決於軟件設計的質量；進行項目編碼前進行項目需求分析、概要設計、詳細設計、編寫編碼規範說明書等是很是重要的。
• 測試：軟件測試是保證軟件質量的關鍵步驟，它是對軟件規格說明、設計和編碼的最後複審，本項目在最後進行了黑盒測試，採其方法有等價類劃分法、邊界值分析法等。
• 驗收：項目驗收主要是咱們對本身項目成果的一個交付，在驗收時開發方也要有好的溝通能力，儘可能向客戶展現本身的成果，讓驗收方滿意。

3.結合我的項目/結對編程/團隊項目的我的經歷，談談心得。

• 轉眼間一學期就結束了，經過這學期的學習，我受益不淺。記得剛上這門課的時候，老師佈置了第一個任務就是申請本身的我的博客，提出本身經過通讀構建之法遇到的問題，當時咱們花費了不少時間在編輯博客上面，再到後來每次的博客撰寫的流暢，其實這也是一種收穫。再到後來的項目需求分析的編寫，利用mockplus製做項目原型設計、項目的編碼及測試，每一次的做業我都參與了其中，因此多多少少都有一些收穫。經過一學期的學習，我最大的收穫是親身經歷了一個完整的項目的誕生的過程，經過一系列的說明書的設計，我大概瞭解了編寫需求分析說明書、系統詳細設計說明書、編碼規範說明書的規範等等說明書的規範。學習了一些工具的使用，好比利用mockplus進行項目的原型設計，採用輕量級的Visio建模工具進行項目的建模。
• 在咱們進行結對編程和團隊項目的過程當中，我最大的收穫是明白了拿到一個項目時須要先對它進行分解，再對每一個小模塊進行詳細劃分和設計，這樣作的好處就是目標明確、思路清晰、一個小模塊出錯不會影響其餘模塊，方便修改。再者，團隊合理分工也很重要，這會使得效率提高不少，但在作的過程當中也須要小組成員的共同協做，共同探討與研究。若是每次的任務你們都去參與，每一個人去承擔一點任務，這樣做業作起來也容易不少，還有一個問題就是在項目設計的過程當中小組成員要團結協做，遇到意見不統一時你們要及時溝通，努力去聽取別人中肯的意見，不能獨斷獨行。

4.總結這門課程的實踐總結和給你帶來的提高

• 統計在軟件工程實踐中，你完成了多少行的代碼；
  在整個項目中我主要進行項目的前端設計，因此大概3500多行代碼吧
• 你在軟件工程實踐的各次做業分別花了多少時間?

任務	花費時間（h）
實驗 一 軟件工程準備	4h
實驗 二 軟件工程我的項目	8h
實驗 三 做業互評與改進	3h
實驗 四 軟件工程結對項目	8h
實驗 五 軟件工程準備	5h
實驗 六 團隊項目選題	3h
實驗 七 團隊項目原型設計與開發	6h
實驗 八 基於原型的團隊項目需求調研與分析	5h
實驗 九 團隊項目需求改進與系統設計	4h
實驗 十 團隊項目系統設計與詳細設計	4h
實驗 十一 團隊項目設計完善&編碼	30h
實驗 十二 軟件測試與Alpha衝刺	8h
實驗 十三 Beta衝刺與團隊項目驗收	6h
實驗 十四 團隊項目評審&課程學習總結	5h

• 哪一次做業讓你印象最深入？爲何?
  我記得給我印象最深入的就是利用vivio工具進行UML建模的那次做業，由於是第一次接觸該建模工具，因此我在建模初期，先學習了該建模工具的畫法，後來根據咱們的項目須要設計出咱們的E-R圖、活動圖、類圖、用例圖等等，再到最後在該軟件中將圖形畫出來。我還記得咱們小組在第一次建模中缺乏了最基本的類圖，後來根據老師的提示，修正並添加了相應的圖。經過那次的做業，我不但學習了一個建模工具，還經過該工具親自畫出了咱們的項目建模圖，這也是將理論和實踐相結合的一次比較印象深入的體驗吧。

• 累計花了多少個小時在軟件工程實踐上？平均每週花多少個小時?
  大概前先後後花費了130個小時在軟件工程實踐上。平均每週花10個小時

• 你學習和掌握的新語言、新平臺?
  學習了利用Java語言進行軟件開發，利用mockplus進行項目的原型設計，用Visio建模、在Github中託管代碼、學會了博客中完成每次的任務

• 填寫下表，總結一學期的學習中，你學習或使用的軟件工程開發工具、開發方法和建模方法?

軟件開發工具、管理工具	軟件開發方法	軟件建模方法
Myeclipse	原型開發、面向對象方法、結構化方法	面向對象建模

• 其餘方面的收穫或提高?
  對於軟件工程，我最爲深入的認識就是項目的編碼工做在整個項目中並非最爲重要的。在軟件開發尤爲是團隊開發時，非編程的工做常起到十分重要的做用。在團隊開發時，咱們團隊花費了不少的時間在調研、討論、溝通、設計等等工做上，而這些工做則是爲開發工做打下基礎。在本學期的學習中我還有一個很大的收穫就是團隊意識加強了，由於在項目開發中團隊合做是很重要的，甚至項目的成功與否和團隊每一位成員都有很大的關係。

  5.你認爲目前的課程存在哪些問題，你有什麼更好的建議。

• 在這一學期中，雖然會由於每次的博客做業而煩惱，可是我也獲得了相應的收穫，學習到了不少新知識。我也深切感覺到老師爲了照顧咱們的基礎，特意爲咱們設計了本學期的課程，老師對咱們也很負責。我有一個本身的小建議是第十章面向對象分析中課本是以ATM系統爲例子講的，我以爲老師能夠換成咱們更爲熟悉的學生信息管理系統等簡單的系統就更好了。