軟體工程實訓心得體會範文 篇1
這次軟體工程實訓是從XX年XX月XX日號開始的，截至XX年XX月XX日號。實訓內容是用java相關知識(主要是jsp)做一個物流配送系統。下面談談對這次實訓的看法。
因為自己平時對java知識儲備不足，特別是jsp這一塊基本不了解怎麼回事，所以一拿到這個項目，我心裡都是沒有底的，再加上我被分到的那個組，我知道就意味著是我一個人在戰鬥了。呵呵，26號，實訓開始了，我們的老師是來自中軟國際公司的程式設計師，一個是周褀，一個是朱映，都是一身樸素的著裝，讓我感覺做軟體的也沒什麼兩樣。老師介紹了自己之後，就直接切入正題了，分析了下我們各個組的系統，即將用到的知識，然後就總體把覺得需要補充的知識(jsp和資料庫連線等這幾塊)給我們實際操作了下，因為當時看到用jsp，還講的那麼認真，當時我就後悔了，平時要是多聽點，現在老師這麼認真的給我們講，這是一個多麼難得的機會啊。後悔也沒用啊，開始還勉強能理解一點，後來就直接暈了。然後再給大家介紹了一些即將用到的工具，比如rationalRose，SVN，MyEclipse等等。接下來的幾天就不再細講了。下面談談通過這次實訓的心得體會吧。
通過這次實訓，讓我了解到工程開發的過程，可行性分析——>需求分析——>概要設計——>詳細設計——>代碼編寫——>測試——>驗收。從技術方面上，我開始jsp基礎基本上就是零的，在老師和syz2(另外一個物流小組，我一個人基本上是跟她們做的，或者說是看著她們做的)的幫助下，對jsp有了一個大概的認識。其實實訓開始前，我還以為做個系統沒什麼大不了，可是當真正拿到一個項目，我卻真的無從下手了，而且就是在知道需求分析和詳細設計，在代碼編寫時，一樣寸步難行。通過這個實訓，也讓我了解到，團隊協作是多麼的重要。一個人的精力是多麼的有限。進一步理解到，企業為什麼如此重視團隊協作。同時借用老師的話就是團隊協作固然重要，但是是建立在個人素質的基礎上，假設你個人素質不行，將會影響到整個團隊，就別提對團隊作更多貢獻了。**老師說這幾句話的時候，朝向了我，估計是有特殊意義的吧，所以，我將謹記老師的教導。
還有一個收穫是從一個同學(小胖)那裡得到的，他的那組成員跟我的這組大體一樣，我倒是覺得沒什麼了，不過他倒是很重視這個問題吧。然後他說出來，我也覺得這個問題確實其實是個大的問題。就是不管你會不會這門技術，會不會做這個東西，態度要正確才好，就算你不會做，你也應該認真的對待，將來 出身到社會，就不是說像你現在，不會做就不做，跑去玩遊戲了。小胖說出了這段話，也在我身上有了一個印證，雖然我jsp技術知識為0，但我也還是在認真的跟著他們一起做，不會做，就多問，畢竟現在我們是學生，可以毫不顧忌的詢問各種問題，老師也會盡力為你回答。將來出身社會就不一樣了。雖然，我就算個打醬油的水平，但是這個醬油也要打得有涵量啊。不管怎麼樣，我能對自己有個交待，雖然我不會，但是這次實訓我確實是認真對待了，六天的實訓，除了晚上加班外，還花了2個通宵來完成不同階段的任務，完成與否也不重要了，我至少我做了，這點，是這次我應該對自己的一個肯定。
這次實訓的心得基本上就是這些了，最後特別感謝中軟國際帶我們的那兩個老師(周褀，朱映)，這兩個老師對待我們很平易近人，對我們提出的問題，總是不光解決了，還進行了擴展，晚上也跟我們一起加班加到很晚，印象尤其深刻就是朱映老師為了給小胖解決一個問題，臉都變紅了，還在繼續努力，這點我並不會覺得老師知識儲備不夠，我想應該是這個問題的突發吧，一時沒想到怎麼處理。相反讓我感覺更多的就是老師很認真，很負責。還要感謝就是syz2小組的傾力支持，輔導。
軟體工程實訓心得體會範文 篇2
我們是20xx年3月7號進入宏天實訓公司參加軟體開發實訓的，在此次實訓中，除了讓我明白工作中需要能力，素質，知識之外，更重要的是學會了如何去完成一個任務，懂得了享受工作。當遇到問題，冷靜，想辦法一點一點的排除障礙，到最後獲取成功，一種自信心就由然而生，這應該就是工作的樂趣。有時候不懂的就需要問別人了，虛心請教，從別人的身上真的能學到自己沒有的東西，每一次的挫折都會使我更接近成功。還有學會了在工作中與人的合作與交流，同樂同累，合作互助，這是團體的精神，也是必須學習的東西。
經過之前的在校學習，對程式設計有了一定的認識與理解。在校期間，一直都是學習理論知識，沒有機會去參與項目的開發。所以說實話，在實訓之前，軟體項目開發對我來說是比較抽象的，一個完整的項目要怎麼分工以及完成該項目所要的步驟也不是很明確。而經過這次實訓，讓我明白了一個完整項目的開發，必須由團隊來分工合作，並在每個階段中進行必要的總結與論證。
一個完整項目的開發它所要經歷的階段包括：遠景範圍規劃和用例說明、項目結構和風險評估、業務功能說明書、詳細設計說明書、代碼實現、測試和安裝包等等。一個項目的開發所需要的財力、人力都是很多的，如果沒有一個好的遠景規劃，對以後的開發進度會有很大的影響，甚至會出現在預定時間內不能完成項目或者完成的項目跟原來預想的不一樣。一份好的項目結構、業務功能和詳細設計說明書對一個項目的開發有明確的指引作用，它可以使開發人員對這個項目所要實現的功能在總體上有比較明確的認識，還能減少在開發過程中出現不必要的痲煩。代碼的實現是一個項目開發成功與否的關鍵，也就是說，前期作業都是為代碼的實現所做的準備。
我深刻的認識到要成為一名優秀的軟體開發人員不是一件容易的事情，不僅要有足夠的幹勁和熱情，還要有紮實的編寫代碼基礎，必須要有事先對文檔進行可靠性報告，功能說明書，詳細設計說明書等的編寫和一些風險評估的編寫的能力。
除了圖書館，最能讓我感覺到身在大學的就是實訓機房，在匆匆過去的兩個月內，我往返於實訓機房與宿舍之間，使我享受了一個充實的學習時期，讓我感受到了大學的魅力，對自己充滿信心，對大學充滿信心，以積極的心態迎接明天挑戰。
實訓中要求有紮實的理論基本知識，操作起來才順心應手，我這時才明白什麼是“書到用時方恨少”。這就激發了學習的欲望。
“學以致用”，就是要把學來的知識能運用到實際操作當中，用實踐來檢驗知識的正確性。我想，這是實訓的最根本目的。
“紙上得來終覺淺，絕知此事要躬行!”，在短暫的實訓過程中，讓我深深感受到自己在實際運用中專業知識的匱乏。以前總以為自己學的還不錯，一旦套用到實際就大不一樣了，這時才真正領悟“學無止境”的含義。
經過為期兩個月的電子政務服務平台系統開發的實訓，我對Visual 軟體開發平台有了更深一步的了解，對微軟基礎類庫的認識與使用也有了大大的提高。以及如何使用SQL Server資料庫進行連線操作方面有了本質的提高。
短短的實訓結束了，為我將來的就業打下了良好的基礎，也提高了我的軟體開發的水平，今後我將會更加努力的學習，不斷提高自身素質，開拓創新，與時俱進，做一個優秀的軟體開發工程師。
軟體工程實訓心得體會範文 篇3
經過這學期軟體工程實驗的學習，深深感到用戶需求對軟體的重要性。成功的軟體產品是建立在成功的需求基礎之上的，而高質量的需求來源於用戶與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，溝通就開始了。
需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什麼，我們所要做的就是和他們交談從他們那裡得到需求，只要問用戶系統的目標特徵，什麼是要完成的，什麼樣的系統能適合商業需要就可以了，但是實際上需求獲取並不是想像的這樣簡單，這條溝通之路布滿了荊棘。首先需求獲取要定義問題範圍，系統的邊界往往是很難明確的，用戶不了解技術實現的細節，這樣造成了系統目標的混淆。
其次是對問題的理解，用戶對計算機系統的能力和限制缺乏了解，任何一個系統都會有很多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎麼樣工作效率更好，也不太清楚那些工作可以交給軟體完成，他們不清楚需求是什麼，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認為是"很明顯"的信息。最後是需求的確認，因為需求的不穩定性往往隨著時間的推移產生變動，使之難以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。
需求獲取活動要完成的任務或者步驟的過程如下：
1、編寫項目視圖和範圍文檔
系統的需求包括四個不同的層次：業務需求、用戶需求和功能需求、非功能性需求。業務需求說明了提供給用戶新系統的最初利益,反映了組織機構或用戶對系統、產品高層次的目標要求，它們在項目視圖與範圍文檔中予以說明。用戶需求文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需求定義了開發人員必須實現的軟體功能，使得用戶能完成他們的任務，從而滿足了業務需求。
非功能性需求是用戶對系統良好運作提出的期望，包括了易用性、反應速度、容錯性、健壯性等等質量屬性。需求獲取就是根據系統業務需求去獲得系統用戶需求，然後通過需求分析得到系統的功能需求和非功能需求。項目視圖和範圍文檔就是從高層次上描述系統的業務需求，應該包括高層的產品業務目標，評估問題解決方案的商業和技術可行性,所有的使用實例和功能需求都必須遵從的標準。而範圍文檔定義了項目產品所包括的所有工作及產生產品所用的過程。項目相關人員對項目的目標和範圍能達成共識,整個項目組都應該把注意力集中在項目目標和範圍上。
2、用戶群分類
系統用戶在很多方面存在著差異，例如：使用系統的頻度和程度、套用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、訪問許可權、地理上的布局以及個人的素質和喜好等等。根據這些差異，你可以把這些不同的用戶分成不同的用戶類。與ULM中Usecase的Actor概念一樣，用戶類不一定都指人，也可以包括其他套用系統、接口或者硬體，這樣做使得與系統邊界外的接口也成為系統需求。將用戶群分類並歸納各自特點，並詳細描述出它們的個性特點及任務狀況，將有助於需求的獲取和系統設計。
3、建立核心隊
通常用戶和開發人員不自覺的都有一種"我們和他們"的想法，產生一種對立關係，把彼此放在對立面，每一方都定義自己的"邊界"，只想自己的利益而忽略對方的想法。他們通過文檔、記錄和對話來溝通，而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這樣的方法是不正確的，不會給雙方帶來一點益處,良好的溝通關係沒有建立導致了誤解和忽略重要的信息。只有當雙方參與者都明白要成功自己需要什麼，同時也知道要成功對方需要什麼時，才能建立起一種合作關係。
為了建立合作關係通常採取一種組隊的方式來獲取需求，建立一個由用戶代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以採用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意以下原則：小組會議應該由中立方來組織和主持，用戶和開發人員都要參加;交流預先要確定準備和參與的規則;議題要明確並覆蓋所有關鍵點，但信息來源應該自由;交流目標要明確，並告知所有的成員。
4、確定使用實例
從用戶代表處收集他們將使用系統完成所需任務的描述，討論用戶與系統間的互動方式和對話要求，這就是使用實例，一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和互動順序。使用實例方法給需求獲取帶來的好處來自於該方法是用以任務為中心和以用戶為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用實例方法可以使用戶更清楚地理解和認識到新系統允許他們做什麼和怎麼做。描寫使用實例的時候要注意使用簡潔直白的表述，儘量使用主動語態，用"系統"或者"用戶"作為主語，比如"用戶提交用戶密碼，系統驗證用戶密碼是否正確"，還有一點在描述中不要設計界面細節，比如"用戶從下拉框中選擇產品類型"。使用實例為以後寫用例場景描述中的基本路徑和擴展路徑提供了素材。
5、分析用戶工作流程
分析用戶工作流程觀察用戶執行業務任務的過程，通過分析使用實例得到系統的用例圖。編制用例圖文檔將有助於明確係統的使用實例和功能需求，統一建模語言的使用有助於與用戶進一步交流。每個用例的描述應包括：編號,為每個用例分配一個唯一的編號，為需求的追溯提供了方便;參與者，與這個用例互動的 actor;前置條件，開始用例前所必須具備的系統狀態;後置條件，用例完成後系統達到的狀態;基本路徑，用例完成的關鍵路徑，也是用戶期望的路徑;擴展點，基本路徑的分枝，表示意外情況;欄位說明，路徑中名稱的進一步分解說明，對以後類屬性的定義和資料庫欄位設計起作用;設計約束，實現用例的非功能約束。
6、檢查問題報告
通過檢查當前已經運行系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新系統或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。
7、需求重用
如果客戶要求的功能與已有的系統很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟體組件。業務建模和領域建模式需求重用的最好方法，像分析模式和設計模式一樣，需求也有自己的模式。
總結：經過一學期的軟工實驗，深刻感到其重要性的同時也學到了不少的東西 ，將對我在今後的軟體開發過程中起極大的作用。