軟工實踐總結

目錄

• 請回望暑假時的第一次作業，你對于軟體工程課程的想象
  • 對比開篇部落格你對課程目标和期待，“希望通過實踐鍛煉，增強計算機專業的能力和就業競争力”，對比目前的所學所練所得，在哪些方面達到了你的期待和目标，哪些方面還存在哪些不足，為什麼？
    • 已達到期待和目标
    • 未達到期待和目标
    • 意想不到的收獲
  • 總結這門課程的實踐總結和給你帶來的提升。
    • 統計一下，你在這門軟體工程實踐中，完成了多少行的代碼；
    • 軟工實踐的各次作業分别花了多少時間？（做一個清單）
    • 哪一次作業讓你印象最深刻？為什麼？
    • 累計花了多少個小時在軟工實踐上？平均每周花多少個小時？同時貼出開篇部落格“你打算平均每周拿出多少個小時用在這門課上”的回答
    • 學習和使用的新軟體；
    • 學習和使用的新工具；
    • 學習和掌握的新語言、新平台；
    • 學習和掌握的新方法；
    • 其他方面的提升。
• 寫下屬于自己的人月神話——個人或結對或團隊項目實踐中的經驗總結+執行個體/例證結合的分析
• 對下一屆實踐的建議，或者對于開學初的你，對于大一的你，對于開學初的我，對于同期的TA們，對于後來的學弟學妹：
  • 你有什麼想建議、告知和期許想要告訴他們呢？
  • 特别地，特别地，下一屆要不要中途換隊員（強制的、徹底的從一隊換到另一隊）？假設依舊是一個90+人數的大班
  • 身在一個格外大的班級，競争強勁，你認為一個組的人數應當在多少比較合适？
  • 個人/結對/團隊作業應該控制在怎樣的規模？
  • 這學期下來，你最感謝的人是誰？有什麼話想要對TA說呢？
• 分析一下自己所處的團隊。軟體工程實踐是大學裡少有的認真的團隊協作經驗。《建構之法》上說團隊的發展有幾個階段，你的團隊都經曆過麼，最後到達了“創造”階段了麼？（參考《建構執法》第17章 人、績效和職業道德）
• 怎樣證明你學會了軟體工程？
  • 研發出符合使用者需求的軟體
  • 通過一系列工具，流程，團隊合作，能夠在預計的時間内釋出 “足夠好” 的軟體
  • 并且通過資料展現軟體是可以維護和繼續發展的。
  • 對着這個檢查表：http://xinz.cnblogs.com/p/3852177.html 檢查一下，自己如果去企業面試，這些常見的問題是否都能回答，并在此總結。
• 閱讀軟體工程中關于代碼品質的的經典論文，從下列文獻中選擇一篇或若幹篇，結合自己的實際做一個閱讀筆記（例如，自己寫的代碼品質如何，是不是一個大泥球，如何衡量自己代碼的品質）？從以下參考論文中選擇一篇或若幹篇：
• 個性發揮，包括圖文、照片和創意等

開篇部落格的課程目标和期待（包含當時内心想法但是沒寫出來的）：

開篇部落格連結

1. 熬夜我應該能挺過去；
2. 能夠學習到軟體工程的流程，做出自己的産品；
3. 學習新技術和使用新工具；
4. 和團隊成員變成朋友；

1. 熬夜我應該能挺過去 =

   熬夜是真的，整個課程實踐過程中，大概有三四次見到福大淩晨夜景，現在回憶起來還是十分痛苦的，雖然在身心上承受很大考驗，但是還是挺過來了。年輕吃點苦也挺合适。

2. 能夠學習到軟體工程的流程，做出自己的産品 = 團隊作業完成了我們的産品記憶罐頭，目前可以提供使用者正常的使用，手機上還安裝着呢，雖然效果沒有期望的那麼好，但是也基本符合開始的期望。學習實踐了軟體的需求、開發、測試、推廣等等的知識。
3. 學到更多學習新技術和使用新工具 = 我們的項目是基于Android移動開發的，我幾乎都是一張白紙，甚至之前都沒有怎麼使用過java，面對配置設定下來的任務，智能去圖書館借書，請教同學，或者自己百度，期間真的學會了特别多。
4. 和團隊成員變成朋友 = 團隊組隊的時候，也是大家自己不知道怎麼的就湊在了一起，經過後來的接觸---一次次的團隊協作，交流經驗，互相提建議；發現大家的很多優點，也都很容易相處，認識了大家優秀的一面。

基本上達到開始的期待和目标。

1. 認識了團隊裡面很多優秀的小夥伴。
2. 重新複習了一下去年學的區域網路知識（ftp搭建之類）；
3. 其實很多階段，都讓人收獲挺大的，答辯課上不少提問和回答挺指的學習的，還有柯老闆的道理集今後可能會挺受用的。

根據自己不完全正确的統計，參照自己的學習進度條，大概完成了4000+行代碼。感覺有點多，可能是期間自己寫了太多垃圾代碼；對于java一開始不是很熟練，寫一個小功能都要很久。

作業	花費時間（分鐘）	部落格連結
第一次作業-開篇準備	60	部落格連結；
個人項目	1236
結對項目1	1523	部落格連結 ；
團隊風采展	120
結對作業2	1539
團隊選題報告	800
團隊課堂UML設計	920
團隊需求分析報告	1203
Alpha版本沖刺	7890	部落格連結1；部落格連結2；部落格連結3；部落格連結4；部落格連結5；部落格連結6；部落格連結7；部落格連結8；部落格連結9；部落格連結10；部落格連結11；
團隊現場程式設計	935
團隊項目測評（福大助手）	400
Beta版本沖刺	2340	部落格連結1；部落格連結2；部落格連結3；部落格連結4；部落格連結5；部落格連結6；部落格連結7；總結；
最終版本展示	240

要說最讓我印象深刻的其實是結對作業一，這次作業是原型作業，和舍友一起做的作業，剛剛開始對于軟工實踐還抱着一股熱情的時候，覺得要認真做好，從界面布局，配色，布局的人性化等等，還參考了國内外的優秀網頁，最後設計的原型，最後看來還是蠻漂亮的，還被助教翻牌了，挺開心的。

累計花了----19206分鐘=320小時=14天)

貼出開篇部落格回答：打算平均每周十個小時左右用在這門課程上。

現在看來，很明顯不止，主要還是在自己不懂的技術上面卡住太久時間了。

• 重新學習：Eclipce For JavaEE的使用
• 開發使用了：Android Studio工具
• UML設計使用了：StarUML工具和ProcessOn
• 結對作業使用了：Axure（用得很艱難）
• 資料庫檔案可視化軟體：SQLite Expert
• 寫伺服器代碼的時候用的：IntelliJ IDEA
• 當然還有我們的産品：記憶罐頭！

• 現場程式設計重新學習了Eclipce For JavaEE的使用
• 開發使用了Android Studio工具
• UML設計使用了StarUML工具和ProcessOn
• 輕量級伺服器（阿裡雲）
• FTP伺服器搭建（忘記叫什麼了）
• 後裔采集器（爬蟲）
• vs裡面的代碼覆寫率和單元測試工具
• winscp （檢視連接配接伺服器的）

• 學習使用java語言開發
• 在web平台上完成項目的雲端功能，對web端有更深的認識
• Android平台開發有一個新的認識

• 在個人項目中知道了單元測試的意義和方法
• 在個人項目中學習了代碼覆寫率的概念
• 在個人項目中對代碼進行性能分析對開發中優化代碼有一個比較新的認識
• 結對作業學習了原型的設計技巧和爬蟲技術
• 在團隊開發中學習了Android開發知識
• 學習了Javaweb的開發
• 伺服器的搭建
• Git代碼管理

• 在項目存在壓力的情況下，能夠評估項目，合理安排時間，通過各種途徑學習和開發；也鍛煉了團隊開發的能力；

經驗總結： 經過這次實踐，我覺得團隊協作非常重要，要是一個人很大的壓力很難獨立完成的項目，有團隊的話，就有着交流和互相鼓勵，我覺得會輕松很多。而且學習能力非常重要，開發中遇到的問題很多會是我們用已有的知識解決不了的東西，隻能在進入下一個階段前趕緊學習，做好知識儲備，要不讓會拖慢團隊進度。

執行個體分析：

這次的實踐課程，自己起初是一張白紙，隻有不斷學習，才能做好，從安裝Android開發環境，從http協定開始web開發等等，每次在安排任務之後都會對照自己的燃盡圖和項目計劃，考慮自己要學什麼。

建議：

• 第一個就是軟體工程很有意義啊！！
• 第二個就是不要怕接觸自己沒有碰過的技術知識，現在階段，拓展自己的知識面，會學到更多有趣的東西
• 第三個就是注意身體。注意身體。注意身體。

暫時的換人，可以體驗一下，隊員之間可以互相取取經，但是永久性的交換隊員，我覺得是風險很大的，有的隊員可能是團隊的核心成員，換到其他項目團隊，舒展不開手腳，原團隊也會失去主心骨；而且，團隊本來就是志同道合的人們一起組建的，不是嗎？抱着好玩心态，三天體驗卡，還行，永久性的不贊成。

看項目情況吧

5-12個人比較實際，一般要八九個吧，文檔+美工+前端組+後端組+PM

現在的配置設定就很不錯了，特别是團隊作業的分階段回報，做的很好，讓大家能夠目标明确的配置設定時間。

最感謝的是鄭西坤，在我學習web程式設計焦頭爛額的時候，提供給我很多建議和指導，對我的問題也是不厭其煩的指導，

對西坤同學說的話：

謝謝！（鞠躬）

《建構之法》團隊發展階段

• 萌芽階段：就像小苗破圖而出，柔弱但充滿希望。團隊成員剛剛接觸到團隊的宗旨，同時很有可能剛剛互相認識。團隊的目标沒有真正達成一緻，而成員則非常依賴于團隊上司的指導。
• 磨合階段：就像一個人的青少年時期，充滿了對個人、同伴和團隊的疑惑和沖突。團隊無論大小都要客服困難，傳遞結果，大家不得不認真的面對問題，開展讨論了。這些沖突不一定都是技術問題也許是關于角色、職責、互相關系。甚至是各自性格、文化的沖突。不少人都想成為某個領域的“擁有者”（在軟體項目中，誰負責哪個方面，每個方面要怎麼做，等等）。同時也有一些人會以不同的方式進行挑戰。
• 規範階段：從磨合階段畢業進入到規範階段的團隊成員們就角色、職責定義和流程都取得了比較一緻的意見。這一時期團隊具有以下特點。
  1. 團隊的工作流程和工作的方式得到大家的認可。成員之間互相更加了解，欣賞各自能力和經驗，工作中互相支援。
  2. 上司主要扮演促成者和鼓勵者的角色，有能力的成員也分擔了一定的上司職責，并自然的獲得大家的尊重。
  3. 随着項目的開展，一些成文的或不成文的規則逐漸建立起來了。
  4. 作為一個整體，團隊要做什麼、不做什麼，都更加明确。團隊的信心更足，和其他團隊打交道更有底氣。
• 創造階段：經曆以上三階段後團隊可以創造一些有意義的東西，并不是所喲偶團隊都能到達這一階段。擁有以下特點：
  1. 團隊知道為何而戰，并将注意力幾種到如何創造、實作目标上。
  2. 高度自治，不再需要上司的時時教誨與介入。不同意見仍會出現，但成員都以一種積極的心态和方式解決。互相支援，互相依賴，并保持各自的靈活性。

• 萌芽階段： 這個階段顯然是經曆過的，在最初始定下項目選題的時候我們便是在萌芽階段，大家對于我們的産品的目标完成的主要功能主要是通過我描述和讨論好多次之後才陸續确定下來的。應該算是在alpha沖刺開發前團隊一直處于這一階段向下一階段邁進。
• 磨合階段： 這個階段的對個人和團隊中的疑惑感覺我們團隊倒比較少出現，因為團隊一直以來的答辯得分和成績都在前列，是以主要是出現成員之間的角色、職責、互相關系、各自性格、文化沖突。團隊其實在Alpha完成後Beta階段也出現了這種苗頭，因為配合不夠到位、存在一些誤會等等一些原因，但是最終還是算比較正常的解決和度過了這種現情況。（我感覺團隊不管在任何階段都在不斷的磨合配合的更好，是以不代表我們在後面階段就不再需要磨合）

團隊自信

UML現場設計

團隊展示

項目評測

需求分析報告

項目選題報告

• 規範階段：
  • 團隊已經有一些成文規則（開會做會議紀要、每隔2-3天進行回報...）和不成文規則（開會地點：34#3 or 青蔔 or 35#3）
  • 在Beta版本和最終版本階段我便是主要扮演一個促成者和鼓勵者的角色，把任務配置設定下去看結果的流程，apk經過13次疊代，其中有一些是我要求疊代修複bug，還有一些是隊員主動更新疊代，修複bug并釋出打包新的apk
  • 團隊的資訊更足，和其他團隊打交道更有底氣這是一定的！從團隊每次作業團隊總分、答辯分數、文檔分數都高居榜首便能知曉。
  團隊還沒有達到創造階段，但是給我們跟多的磨合實踐，相信大家會更加優秀的，每個人都會發生很大的蛻變！！！

1. 我們的産品在開發前做過一次市場調研問卷調查（樣本容量：線上93+線下110=203份），并完成了我們的記憶罐頭商業企劃書。其中包括使用者對我們産品功能的回報餅狀圖，我們産品功能十分符合使用者需求。

需求展示

1. 在完成産品後我們邀請了86位使用者進行内測試用我們的記憶罐頭,并且收集了使用者回報問卷。

體驗指數展示

期待指數展示

我們團隊在軟體工程實踐課程的機會之下，通過團隊合作完成了産品記憶罐頭！分别在Alpha版本階段完成産品的初始版本，Beta版本完善産品進行一定的bug修複，最終版本已經疊代13次完成産品的1.1.3版本，産品下載下傳連結。

現軟體的可維護性和是否可繼續發展通過上面的使用者回報問卷截圖便能看出。

使用者需求期待指數超過4分的比例在70%以上，證明我們的産品是可維護和可持續發展的。并且産品具有十分可觀的盈利方式和前景，對不同手機（三星、華為、Oppo）應用市場的線上付費桌面做了一個簡單的調研：

三星付費桌面

華為付費桌面

Oppo付費桌面

盈利點

可以看出，我們的核心創新點鎖屏桌面展示如果能夠達到美觀、友好的前提下，還能展示出使用者的備忘内容，那麼便完全可以借助于付費桌面已經廣為人知的免推廣的天然優勢！！！在每種桌面單價較為廉價的模式下，提高使用者購買欲，相信可以很快的搶占付費桌面的一塊市場，這樣也為後續的開發提供了條件和盈利希望。當然，這一切都需要在能夠解決生成美觀桌面展示備忘的這一難點的前提下。也正所謂難點即賣點！

emmmm，我可以說這些問題打開了我新世界的大門嗎？很多問題沒有聽過，更不要說回答了。其實一直覺得自己的學習很奇怪，沒有什麼目标可言，是以碰到這些系統的問題，就會感覺沒見過，概念模糊。。。

總結：現在的能力去就業，在第一輪就被刷掉（很明顯），很多知識需要實踐和積累，自己都沒有聽過，看來自己在專業學習上很懈怠，也不得其法，這麼多問題給了我很多思路。

參考論文文獻：

[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

2019年，1月18日。

2019年的第一個福大淩晨夜景。