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

做業格式

• 課程名稱：軟件工程1916|W（福州大學）
• 做業要求：我的做業——軟件工程實踐總結做業
• 我的學號：021600823
• 做業目標：軟工實踐總結

做業正文

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

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

「我不太喜歡說些不切實際的話，對於當前這個課，我但願能體驗一個還算完備的開發過程，寫出一個能夠跑的東西，我不太奢望它有什麼實際的做用，可是我但願它能被我好好的優化過幾回，而不是悶頭寫完就丟在那等着交就完事了。」

• 這是我寫在學期開始時，對於軟件工程實踐這門課的期待，如今回想起來，當時對於這門課的理解仍是有些淺薄。

• 在軟工實踐的過程當中，我瞭解到瞭如何規範地開展一個項目，如何撰寫規範的需求說明書、數據庫說明書等等。也學習瞭如何寫測試用例、使用robot workframe，loadround等各類測試工具來進行測試。

• 意外的是經過此次實踐我積攢了很多寫python的經驗，這也是我以前接觸不多的東西。

• 不足的話，就是因爲本次開發先後端分別使用的.vue和dotnet是我以前沒有接觸過的領域，因此我花費了不少時間在學習相關的知識上。

"針對你的選擇，你給本身的大三設定的規劃安排是什麼？"

大三下，就是這學期，把全部的選修修完，儘可能大四的時間要騰出來衝刺，另，平時要投入時間（晚上和週末的下午）開始複習高數和英語，不該該有在週末放縱本身的資格。

• 我當初真的不知道軟工大三的課能夠麻煩到這樣，除了軟工實踐還有別的課設，再加上我這學期把選修修滿——還要再加上大一的補修，時間真的是所剩無幾。本着課內學習爲重的原則，考研的進度目前看起來只有英語達標了叭，真的是有些頭疼。

2）總結這門課程的實踐總結和給你帶來的提高：

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

• 其實個人代碼量並非不少，個人任務量主要在報告，測試腳本編寫和測試用例撰寫上。

語言	代碼行
C#	320
Python	550
Java	660

2. 軟工實踐的各次做業分別花了多少時間？

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

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

• 結對第二次—文獻摘要熱詞統計及進階需求
• 此次的做業令我印象深入，這是我第一次進行結對寫代碼，由於溝通的緣故，我和隊友對項目的理解，對接口的需求，已經對進度的估計都有誤差，當時還有一點點的不愉快，主要是我這邊的代碼寫的較爲混亂，隊友當時看不太懂，並且底層的邏輯有些不嚴謹，我當時花了一個通宵重構，可是因爲時間不夠，邏輯的部分並未獲得太大改善，測試也不夠充分，雖然本身這邊的樣例過了可是並無拿到理想的分數。
• 這是一次屬於吃虧的經歷，不過也是此次經歷讓我對於本身編程的習慣有了深入的反思，我認爲它對個人影響是深遠的。

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

• 根據問題2給出的表格， 加上到現場答辯以及其餘交流的時間，大概有近160個小時了，不算一下，本身也沒發現竟然有這麼多的時間。平均下來，幾乎每週都有12個小時左右。

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

• 原型設計：墨刀、Photoshop
• 用例圖、類圖等：ProcessOn、StarUML
• 測試：LoadRound，Ride，Python
• 代碼管理：GitHub、GitLab
• Markdown: Tyopra、HackMD

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

• Python, .NET, VUE

7. 學習和掌握的新方法；

• 單元測試
• 自動化調試
• 壓力測試

8. 其餘方面的提高。

• 需求分析能力
• 抗壓能力
• UI設計的能力
• 邏輯分析能力
• 自學能力和查資料能力

---

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

需求必定是要在開始就作好的，而且由此來構造功能模塊，這樣才能夠在功能驗收的時候有個勉強可以做爲參照的驗收標準，寫代碼的時候就不會像沒頭蒼蠅同樣。在結對的時候，咱們當時就粗略的分析了須要，並無規劃好功能結構，間接致使後面的成績不理想，同時，在後面互測的時候也發現其餘組有的同窗對於本身軟件各塊的功能不明確，甚至出現了空按鈕和「同一功能兩個標準」的狀況出現。

---

3、對下一屆實踐的建議等等。

下一屆實踐的建議：建議在組隊的時候先把隊員大三下的目標摸清，由於這實在是一個敏感的時間點，對於我的目標的不同可能就決定着你們對於這門課程投入的不同。另外，但願你們各有所長，有所偏重點才能更好的配合，也能在本身擅長的領域統一意見，在開發的時候團隊裏有我的來統一意見是很重要的一件事，因此你們選組長的時候必定要慎重選擇，大局觀要強。
對開學初的本身：不要想那麼多有的沒的了。。。
對大一的本身：準確來講應該是大二，打好基礎，當時不該該擔憂留級的。
對後來人的期許：都比我強，確定輪不到我來操心。
對於中途換隊員：能夠換，可是我但願老師可以容許小組互相商討交換的人員，就比如球隊交易，原本好好的兩對（前端+後端）硬生生被配成（前前）+（後後）這誰頂得住。。。

---

4、分析一下本身所處的團隊。四個階段。

萌芽階段

• 在組隊開始的時候，雖然項目都已經肯定，可是你們都在討論要實現哪些功能，須要用到哪些技術。

磨合階段

• 我認爲是在需求分析和文檔階段，以及以前的GitHub實訓，在這個漫長的過程當中，你們在團隊裏找準了本身的定位，也逐漸明確了本身的目標和方向

規範階段

• 在alpha和以後的beta階段，你們明顯都有了本身所負責的領域，對於各項工做的分配和處理也顯得更熟練，甚至不用調配就自覺完成。

創造階段

• 好像。。。還沒到？

---

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

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

• 因爲是針對需求開發，因此實驗室的同窗就是實際的目標用戶，固然目前開發尚未徹底結束，因此目前的用戶量並無普遍上升。

經過一系列工具，流程，團隊合做，可以在預計的時間內發佈 「足夠好」 的軟件有項目規劃/需求/設計/實現/發佈/維護，有定時的進度發佈 ； 而不是: 經過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲交付等方式糊弄

• 咱們經過GitLab進行代碼管理和協做，每一個人都有分支，只有在分支中的代碼ok，纔會進行合併。這次的項目進度也一直在計劃以內。

而且經過數據展示軟件是能夠維護和繼續發展的。而不是 找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料

---

六*（選作）、閱讀軟件工程中關於代碼質量的的經典論文，作一個閱讀筆記？

---

7、個性發揮

大三剛開始

大三過一半

課程結束