當我們受到啟發，對生活有了新的感悟時，不妨將其寫成一篇心得體會，讓自己銘記於心，這樣有利於培養我們思考的習慣。是不是無從下筆、沒有頭緒？下面是小編精心整理的軟體工程實習心得體會，歡迎閱讀與收藏。
軟體工程實習心得體會1
學習了這門課程, 還有老師們的多元化教課,不但讓我從理論上掌握軟體工程,還有從不同的例項,讓理論和實踐得到了很好的結合。整一個學期下來，總的來說還是學到了很多東西的，有很多地方是值得肯定的，其實在我看來，軟體工程與其說是一門課程，不如說是一門思想。是一個如何去分析和處理問題的過程，應該說其範疇已經遠遠不止侷限於該門課程，成為了一個綜合的一個能夠解決問題的思想集合。
要學習軟體工程，學會如何系統的思考，以及養成良好的編碼習慣，想學好軟體工程，就必須知道軟體工程的目標、過程和原則： 軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。
可用性指軟體基本結構、實現及文件為使用者可用的程度。開銷合宜是指軟體開發、執行的整個開銷滿足使用者要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模組以及相關層次的說明、每一模組的介面定義。詳細設計產生程式設計師可用的模組說明，包括每一模組中資料結構說明及加工描述。實現活動把設計結果轉換為可執行的程式程式碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足使用者的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支援過程、培訓過程等。 軟體工程的原則是指圍繞工程設計、工程支援以及工程管理在軟體開發過程中必須遵循的原則。
pad圖：它是用結構化程式設計思想表現程式邏輯結構的圖形工具。pad也設定了五種基本控制結構的圖示，並允許遞迴使用。hipo圖：hipo圖是由一組ipo圖加一張hc圖組成。它是美國ibm公司在軟體設計中使用的主要表達工具。hc圖既是層次圖，用於表示軟體的分層結構。hc圖中的每一個模組，均可用一張ipo圖來描述。ipo 圖由輸入、處理和輸出三個框組成，需要時還可以增加一個數據檔案框，這種圖形的優點，是能夠直觀地顯示輸入處理輸出三者之間的聯絡。還有測試方法:按照測試過程是否在實際應用環境中來分，有靜態分析與動態測試。測試方法有分析方法(包括靜態分析法與白盒法)與非分析方法(稱黑盒法)。靜態分析技術：不執行被測軟體，可對需求分析說明書、軟體設計說明書、源程式做結構檢查、流程分析、符號執行來找出軟體錯誤。動態測試技術：當把程式作為一個函式，輸入的全體稱為函式的定義域，輸出的全體稱為函式的值域，函式則描述了輸入的定義域與輸出值域的關係。還學習了其他很多工具、語言、方法等，雖然不是都學得很透徹，但我相信在今後的學習中一定會慢慢的完善的。
軟體工程對於初學者來說，知識基礎較薄弱，對一些應用操作、概念、工具方法等理解起來較為困難，要能從整體概念上較好地理解和把握、學好軟體工程，不是僅僅把幾本專業書籍細緻地看幾遍，然後上機練習幾次就可以成功，學習過程中要注意多看多練要注意結合實際，更要多思考，面對錯誤不要一範就問，要嘗試自己去解決。但是還要注意什麼都學，肯定是什麼都學不透的，要集中精力打攻堅戰，學習軟體工程首先要明白自己的學習目標究竟是什麼，根據自己的實際工作出發，有針對性的在相應的學習方向上進行提高，制定出詳細的學習規劃。還要注意與其他科目的相輔相成，就像我們在學習物件導向分析的時候要結合大一學習的物件導向及其方法學這一專業科目進行研究拓展;在學習語言時，要看看與c語言的聯絡，多思多想，把從各個科目學到的知識通匯貫通。
在軟體工程的學習中，我瞭解到了軟體並非是一些程式碼這麼簡單，在開發軟體的過程中，編寫程式碼的工作量其實只佔不到所有工程量的30%，而後期的管理和維護更是佔了60%到80%之多。一個完整的專案規劃須包括，軟體的定義，可行性分析報告，專案開發計劃，軟體需求說明書，概要設計說明書，詳細設計說明書，使用者操作手冊，測試計劃，測試分析報告，開發進度報告，專案開發總結報告，軟體維護手冊，軟體問題報告，軟體修改報告，等多個文件，每個文件都要上級驗收審查，而文件數量眾多，要做好這點真的不是很容易，而恰恰寫好文件正能保證完成軟體工程其中一個目的的關鍵，既研究如何用最小的開銷做出生存期較長的軟體，再加上各個階段都要進行周密的策劃、詳細的分工部署和人員安排，且各階段要據具體情況不斷的反覆才能達成，所以程式碼只是開發軟體這個浩大的工程的一個小小的過程。
而編碼的'學習中，我更瞭解到形成自己獨特的規範的編碼風格是非常重要的事。因為這影響到了軟體後期繁重的維護，大家都要閱讀你的程式，如果你寫的程式毫無規範可言，那麼別人怎麼能讀懂你的程式讀不懂程式，維護又從何談起呢所以，我們在今後的學習中，一定要注意這方面的培養，在寫程式的過程中，要逐步的在規範的基礎上形成屬於自己的風格，即方便自己的修改，也方便日後他人的閱讀。
在學習中，我們還要注意比較三種方法的優缺點，例如：傳統方法雖然使軟體擺脫了混亂和無序，但其在適應需求變化的方面不夠靈活，而且傳統方法要麼面向行為，要麼面向資料，缺乏兩者的有機結合。而物件導向方法的程式設計和問題求解更符合人們日常自然的思維習慣，適合大型、複雜及互動性比較強的系統。形式化方法則是一中基於形式化數學變換的軟體開發方法，它可將系統的規格說明轉換為可執行的程式。在今後的學習中要注意多讀書、多思考、多練習、多討論，不斷熟悉書本的基礎，並以此為基礎將其擴散開來，應用於今後的實踐。不斷鍛鍊自己，向一名合格的程式設計師邁進。
軟體工程實習心得體會2
在這次軟體工程課程中，我學到了很多東西，第一次深刻的體會到了什麼叫做用工程化的思想來編寫軟體，以前自己也寫過一些小型軟體，沒有做過大型的專案，直到這次課堂我擔任組長並組織組員共同完成“個人圖書管理系統”這個專案，第一次和別人合作，才發現運用工程化的思想來做是如此的有必要。
從這裡，我才真正的意識到實施一個軟體工程並不是說簡單的會編碼就能夠解決問題的，我們更多的精力不是放在編碼上，編碼只是一個很小的模組，只佔到那麼小的一個部分。這個事實在很大程度上顛覆了我以前的思想，在我以前的認識中，似乎整個軟體就是編碼，除此無它，還好有老師的指導，不然真的會出現老師所說的，撞得頭破血流之後才想起來用軟體工程的思想來完成這個工作。
剛真正開始工作之前，我們費了很多的時間來完成一些前端工作，如需求分析和可行性分析，這塊工作在別人看來可能是相對無關緊要，甚至是多於的，其實，換做在以前，我也會這麼認為。可是，我現在算是深深地明白了磨刀不誤砍柴工的道理，這些工作的完成太有必要了，太重要了，要想你的軟體有用有市場，能被別人接受和認可，在進行過程中不會出現崩潰性的問題，這些工作缺一不可。
還有就是接下來的一些設計模組，此模組與軟體編碼涉及比較緊密，主要是解決一些引數傳遞和介面通訊的問題，此模組對我的觸動遠沒有上兩個模組對我的影響大，因此再次也不做過多的介紹。
在整個活動的`完成過程中，作為組長，我收穫很多，我發現，要是組裡有個人不怎麼想做事情時，他對於整個組織的影響是毀滅性的，正所謂“一顆老鼠屎，能壞一倉谷”，以後我的組織裡要是出現這樣的人，我絕不會給他繼續留下來的機會，我會在第一時間將他清除出去。還有就是，作為組長，你要做的最重要的事情，不是發揮自己的聰明才智，而是創造出一個平臺，讓別人去發揮，你所要做得，出了保證這個平臺的完整性和公平性外，還有就是協調好各組員之間的關係。
這就是我的實習感想。
軟體工程實習心得體會3
時間過的很快，轉眼間已經實習將近5個月。
最先在內部系統組參與內部管理系統開發(struts+mysql+spring+hibernate)，之後是去做網路交換機軟體的指令碼測試。現在又迴歸內部系統，雖然在指令碼組期間，編碼能力被別人甩在後頭，但至少具有了一些測試經驗。
至少自己做的東西，是真正交付到了客戶手上，到也稍微有些成就感。
1淺談測試
一直以來，我都認為測試是脫離了軟體工程範圍的工作，不以為屑。但在實際情況中，測試是既重要且難以精湛的.其真正的壓力，在於找不到bug，責任在你，而不在於編碼人員。一般的測試人員不懂編碼，他們靠的是日以累計的經驗總結和想象力。而要做到高階測試工程師，則一定要懂編碼，因為這是你完全掌握整個系統的方方面面具體運作的前提。但占主導地位的，還是大型系統的整合測試經驗。實際專案中，編碼時間一般只佔30%左右，真正耗費時間的是IT階段的找bug與對應bug，此階段基本評定了coder的編碼質量。
2程式設計師的困惑
有些人，以為教學視訊和程式碼看多，自己就懂的多，實際做起來，卻不知從何下手，問題在那?如何定位?如何解決?通通跟一樣能力有關，debug追蹤能力，也稱除錯。在專案組工作不愁原始碼資源，但問題是蛋糕擺在面前，你如何去消化?
有位同事告訴我：程式碼看幾遍都沒用，要去抄，例如一個查詢模組，在此基礎上去做具體記錄的歷史記錄查詢模組，你可能會覺得很簡單，但實際情況卻往往報一堆異常，配置問題涉及到方方面面，以及資料庫欄位，傳值問題等等，一大堆對於新人來說很鬱悶的問題。但不用怕，只要學會除錯，一個個問題去追蹤，一個個去解決，自然而然，那段“原始碼”才真正屬於你。
3如何除錯追蹤?
如果你能在短短的時間內就看到問題點在那，放下斷點去追蹤，出去找工作，絕對沒問題。出現問題的時候，不要光看程式碼，要用實際行動去追蹤執行期間的具體值，那是最好途徑。eclipse是個很爽的ide，這點做的很好。例如頁面內容顯示不是自己想要的資料，我們要先從資料庫查詢語句去下手，設定斷點，一步一步step over，讓sql欄位(存取最終sql語句的字串)執行到有值，inspect進去看，如果還看不出來，就點選它，copy後在sql客戶端去實際執行，看看實際查詢出來的表是什麼，如果是對的，有可能就是頁面呼叫的錯誤或者action邏輯的傳值問題。
頁面錯誤的除錯，基本方法是用右鍵點選實際網頁檢視原始碼，copy到editplus，就能看到具體錯誤發生在那幾行。通常有幾種常見的錯誤，例如：缺少物件這種很多時候是有些被你呼叫的欄位有可能為空的情況出現的，可以加if語句加保護。追蹤的方法基本就是用alert語句，放在有可能出錯的地方。
4一些習慣
遇到問題先自己思考，無從下手再找高手幫忙看看，注意他幫你看的思路，別在一旁閒著，看多了自己也會了，不然你一輩子都停留在那種水平，從人身上學到的東西遠遠比書多的多。
解決了一個問題後，要去究根問底去找到問題產生的起因，以防你下次遇到類似的問題再浪費同樣的時間。
把程式碼寫的漂亮，註釋、空行、規範一樣不能少，可讀性是放在第一位。曾經看過一個高手寫的程式碼，真的一看就是不同水平的人寫的，幾乎很完美，讀起來很流暢，方便自己也方便別人。
任務完後不要呆著，去要求經理給你更有挑戰性的任務，只要你肯去嘗試，他們就會對你另言相看，把三天的任務一天加班搞定，效率和忠誠都有了，路也比較好走了。
5題尾話
如果你有一份思想，我有一份思想，拿出來交換，我們大家擁有就是2分份思想，可惜這種觀念，並不能深入每一個團隊的每一個人，少一點自私，未必不是好事。職場到處都存在被排擠的隱患，要為自己找片草地實在不容易。但有一點要相信，只要自己不放棄自己，這世上就沒有絕望的路，你可以被打趴下，可以被身邊的人暗算，可以被深愛的人流放，只要你用自己決心站起來，受過的傷痊癒後就能增強你的抵抗力，一路前進!