網絡15軟工我的做業5——軟件工程總結

1、請回望開學時的第一次做業，你對於軟件工程課程的想象

1. 對比開篇博客你對課程目標和期待，「但願經過實踐鍛鍊，加強計算機專業的能力和就業競爭力」，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，爲何？

答：
達到的目標：瞭解了一門新的技術（小程序的開發）；培養本身的領導力；時間管理能力有所提高……
存在的不足：學習新知識的效率較慢；處理團隊分工問題不當；
緣由：經過這幾回做業所得所感，完成了些許期待，也明顯的感覺到本身的不足。

2. 總結這門課程的實踐總結和給你帶來的提高，包括如下內容：

• 1）統計一下，你在這門課程中，完成了多少行的代碼；

  大概1500行

• 2）軟工的各次做業分別花了多少時間？（作一個列表）

  做業（以博客做爲統計）	時間（h）
  軟件工程網絡15我的閱讀做業1	7
  軟件工程網絡15我的閱讀做業2-提出問題	7
  軟件工程網絡15結對編程做業	35
  軟件工程網絡15團隊做業1——團隊組隊&展現	2
  軟件工程網絡15我的做業3——案例分析	7
  軟工網絡15團隊做業2——團隊計劃	6
  軟工網絡15團隊做業3——需求分析與設計	6
  軟工網絡15團隊做業4——Alpha階段敏捷衝刺	64
  團隊做業5——測試與發佈（alpha階段）	3
  團隊做業6——展現博客（alpha階段）	3
  項目複審——Alpha階段	1.5
  軟工網絡15團隊做業7——Alpha衝刺之過後諸葛亮	2
  軟工網絡15我的做業4——alpha階段我的總結	3
  軟工網絡15團隊做業8——Beta階段敏捷衝刺	48
  軟工網絡15團隊做業9——項目驗收與總結	3
  beta版驗收互評	1.5
  網絡15軟工我的做業5——軟件工程總結	2

• 3）哪一次做業讓你印象最深入？爲何？

  「軟件工程網絡15我的閱讀做業2-提出問題」，看書提問題什麼的真的從沒有作過這樣的做業，通常都是先了解課程，再提出相應的問題，那次做業是讓咱們看書，本身提出相關問題，一時有點迷茫，還找了老師推薦的一些提問題的書之類的參考如何提問題。

• 4）累計花了多少個小時在軟工上？平均每週花多少個小時？

  以博客做業來衡量的話總共201h；以15周的課程計算，平均每週13.4h

• 5）學習和使用的新軟件；

  墨刀、leangoo

• 6）學習和使用的新工具；

  微信小程序開發工具、碼雲、知曉雲

• 7）學習和掌握的新語言、新平臺；

  新語言：js/wxml/wxss
  新平臺：微信小程序開發工具、知曉雲

• 8）學習和掌握的新方法；

  自行提問、單元測試……

• 9）其餘方面的提高。

  瞭解一個項目的流程並進行實踐

2、寫下屬於本身的人月神話——我的或結對或團隊項目實踐中的經驗總結+實例/例證結合的分析

1. 關於我的項目：
   首先明確本身的能力；而後根據實際規劃時間，肯定這些時間就是作你的項目的，沒有其餘事情干擾，除非緊急狀況；在實踐時多參考材料並多詢問能力出衆的同窗，提升本身的能力。
2. 關於結對項目：
   找到與本身志同道合的夥伴，儘管實踐過程當中有問題也能夠比較好的解決，畢竟都是爲了項目；一樣，提高本身的能力很重要。
3. 關於團隊項目：
   團隊選題時要全面瞭解這個團隊的能力以及所選擇項目的難易程度（相對來講），以便以後更好的實施；團隊任務分配要儘量細緻並讓每一個隊員都有事可作；團隊之間的溝通重中之重，不管是項目的問題仍是人際關係的問題，相信沒有交流解決不了的問題。

3、對下一屆實踐的建議，或者對於開學初的你，對於大一的你，對於開學初的我，你有什麼想建議和告知的呢？對於後來人的期許。對於換人機制，有什麼樣的建議？

1. 對於後來人的期許：好好學習編程，多看相關類型的書或教材，提升本身的學習能力。
2. 對於換人機制的建議：現階段的要求就挺好的，不論是團隊之間商量好的仍是主動想要加入其餘組都由本身或者團隊之間商量。

4、分析一下本身所處的團隊。軟件工程實踐是大學裏少有的認真的團隊協做經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過麼，最後到達了「創造」階段了麼？（參考《構建之法》第17章 人、績效和職業道德）

團隊的發展有四個階段：萌芽階段、磨合階段、規範階段和創造階段。咱們的團隊經歷着前三個階段，正在向創造階段努力着……

5、怎樣證實你學會了軟件工程？

1. 研發出符合用戶需求的軟件

• 必須公開發布，有實際的用戶，必定的用戶量和持續使用量 （3 天后能保持10 - 100個用戶）；而不是：作沒有用戶使用的軟件

  發佈較晚，也沒有進行推廣，用戶少的可憐
  

  2. 經過一系列工具，流程，團隊合做，可以在預計的時間內發佈 「足夠好」 的軟件

• 有項目規劃/需求/設計/實現/發佈/維護，有定時的進度發佈 ； 而不是：經過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲交付等方式糊弄

  leangoo管理項目：
  Alpha階段：https://www.leangoo.com/kanban/board/go/2376778
  Beta階段：https://www.leangoo.com/kanban/board/go/2404218
  以前的博客都有項目相關規劃/需求/設計/實現/發佈/維護。

  3. 而且經過數據展示軟件是能夠維護和繼續發展的。

• 而不是找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料

  源代碼等資料或文檔經過碼雲保存：https://gitee.com/whting/word_wechat_applet/tree/beta/
  

請在隨筆中用數據證實上述內容或側重選擇之一。

六*（附加題）、閱讀軟件工程中關於代碼質量的的經典論文，從下列文獻中選擇一篇或若干篇，結合本身的實際作一個閱讀筆記（例如，本身寫的代碼質量如何，是否是一個大泥球，如何衡量本身代碼的質量）？從如下參考論文中選擇一篇或若干篇：

參考論文文獻：

• [1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
• [2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
• [3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87