我的做業——軟件工程實踐總結做業

這個做業屬於哪一個課程	軟件工程1916|W（福州大學）
這個做業要求在哪裏	我的做業——軟件工程實踐總結做業
學號	221600307
這個做業的目標	總結本學期軟件工程實踐課程內容。

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

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

我在這個課程的目標是：經過實際項目將理論與現實相結合，在實踐中掌握更多知識，培養更多能力。 期待這門課可以讓我對軟件工程有更清晰的認知，但願能交出一份不錯的答卷。

這是學期初我對這門課的期待，期末回顧，我以爲已經基本實現了個人期待，一個項目從策劃、分析到實現、測試，如何在一個小組中最大化地發揮本身的做用，如何和別人合做共同儘量完美地達成一個目標等等，都是在實踐中學到的內容。固然這也多虧個人隊友們都是很好的人，互相幫助才能學到更多。

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

1. 統計一下，你在這門軟件工程實踐中，完成了多少行的代碼；

   • 在各次做業完成過程當中其實個人代碼量並不算多，由於小組做業時我主要在作UI設計、測試以及各類文檔撰寫。結對編程300行左右，GitHub實訓約500行，校招平臺1000多行。

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

   做業名稱	花費時間(h)
   第一次做業——準備篇	3
   結對第一次——原型設計（文獻摘要熱詞統計）	12
   結對第二次—文獻摘要熱詞統計及進階需求	10
   團隊做業第一次—團隊展現	2
   團隊做業第二次—項目選題報告	10
   團隊第三次-項目原型設計	16
   團隊做業第四次-項目需求分析	20
   團隊做業第五次—項目系統設計與數據庫設計	5
   團隊做業第六次—團隊Github實戰訓練	20
   項目Alpha衝刺（團隊）	50
   過後諸葛亮（團隊）	3
   項目Beta衝刺（團隊）	40
   Beta階段團隊項目互評	6
   我的做業——軟件工程實踐總結做業	3
   總計	200

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

   • 印象最深入的是α衝刺，由於時間緊，任務重，因此每一天你們都在爭分奪秒地趕工，並且因爲前期任務完成的欠缺，致使大範圍返工。經此一役你們都獲得了教訓，每一階段都須要全力以赴，千萬不能抱有此次沒作好下次彌補的僥倖心理。

4. 累計花了多少個小時在軟工實踐上？平均每週花多少個小時？

   • 由上表可看出，各次做業累計完成的時間已經有約200h，還有一些課外學習的時間，零零總總算下來大概有240h左右，平均每週花費20h，已經大大超出我當初對這門課的預期。

5. 學習和使用的新軟件&新工具

   • 原型：墨刀
   • 測試：Emmagee、iTest
   • 代碼管理：GitHub
   • markdown：Typora

6. 學習和掌握的新語言、新平臺

   • 不算新語言吧，是舊語言但新技術，安卓開發。開發平臺是AndroidStudio和IDEA。

7. 學習和掌握的新方法

   • 各類測試方法。

8. 其餘方面的提高

   • 在與人合做方面有很大提高，還有如何同時進行多種任務，各類文檔的撰寫以及對一個項目流程的把控。

2、寫下屬於本身的人月神話

團隊開發最重要的就是協做和配合，在完成項目的過程當中文檔是很是重要的，小組成員在開發時不能只一根筋地埋頭苦幹本身被分配到的任務，須要時時跟進其餘人的進度，檢查本身的完成部分和其餘成員是否契合。咱們小組前期就是由於成員之間沒有協調好，在代碼完成過程當中沒有檢查先前階段的文檔，致使最終的客戶端界面和原型有很大出入，先後端接口之間也老是有出入，經常要改。後期咱們對這個問題進行了改進就大大減小了問題出現的次數。

3、對下一屆實踐的建議，或者對於開學初的你，對於大一的你，對於開學初的我，你有什麼想建議和告知的呢？對於後來人的期許。 特別地，特別地，下一屆要不要中途換隊員？

• 對於大一的我：課外學習是很是重要的，不要侷限於課堂和課堂做業，儘可能多積累項目經驗，多看多學多寫。
• 對剛開學的我：在此爲你點播一首歌——建議是看開點。把握時間，創造奇蹟。
• 對下一屆的建議：學期初就要對本身整個學期進行大概的規劃，結對編程和小組項目選擇組員都是很是重要的。和組員的熟悉程度、你們的技術掌握程度都是須要考量的點。不要由於怕錯就不作，邁出一步以後的９９步就會更容易走。並且但願下一屆學生在選課前可以清楚課程的上課形式，否則容易在後期產生抵觸心理。
• 對於中期換人：做爲被選中替換的人，在緊張的β階段難以快速上手一個已經趨於完整的項目，小組其餘成員已經一塊兒完成過８次做業，我做爲空降人員初期總以爲格格不入。不幸中的幸運是交換後的小組我須要作的工做此前已經有必定的知識積累，不然只能做爲團隊邊緣人物完成一些可有可無的任務，新組舊組項目成功的喜悅全都與你無關。對於小組來講，若是一開始就抱着早晚會有一我的被換走因此不能讓任何一我的成爲組裏的絕對核心的想法，那麼開始就註定了項目的失敗。固然不排除有一些組前期組隊時因爲成員之間相互的不瞭解因此後期磨合出現問題產生換人的想法，個人建議是誰想換誰換，不想換就不換，畢竟在實際的工做場景中硬逼一個後端開發去作界面設計的狀況也是毫不可能發生的。這門課並不教授技術，只是依靠學生此前的技術積累，舊組在選題時已經考慮過全部人的技術側重，然後期貿然作出隨機替換的決定不只草率並且絲毫沒有顧及到實際狀況。大三下學期課程很是多，光是各科的做業已經讓人感到疲憊，我想學生是否有本身選擇的權力呢？

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

• 萌芽階段

  組內成員提出選題建議，討論、擊碎、重構並採納的過程。

• 磨合階段

  初期文檔不規範或者文檔沒有考慮概括到的狀況，代碼、接口等等在α階段經常出現差錯，因此須要改正、磨合。

• 規範階段

  後期從新制定了各類規範，代碼與接口規範在以後階段大有幫助。

• 創造階段

  暫未達到。

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

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

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

在內測及小組互評階段咱們的應用都獲得了較好的評價，用戶滿意度較高，對於現有功能較爲滿意，咱們在開發時也很是全力以赴，並不僅是爲了完成這門課的做業敷衍了事。因爲現階段ａｐｐ功能已較爲完善，咱們後續還會再進行完善維護，若是有機會但願能投入使用。
用戶使用手冊
2）經過一系列工具，流程，團隊合做，可以在預計的時間內發佈 「足夠好」 的軟件

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

在持續兩個月的小組做業裏能夠經過一系列博客的發佈看出咱們項目的流程規劃和實現過程，每一個階段的任務都按時甚至提早交付，基本在計劃以內。

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

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

全部的代碼都有GitHub存檔，迭代過程可在ｔｅａｍｂｉｔｉｏｎ查看，編寫過程就已經考慮到後續的拓展、維護過程，代碼具備良好的可擴展性，而且有完整的相關文檔可供查閱。

6、個性發揮

此時無聲勝有聲。