軟件工程心得體會

第一篇：軟件工程心得體會

軟件工程心得體會

未接觸軟件工程之前一直都很想學這門課程，因為覺得這門課很

牛，是那些有工程師稱號的高手才擺弄的東西。學了一個學期的軟件

工程課，終于知道了個軟件工程的大概。學的時候總覺得很抽象，理

解起來好像不難，但總是摸不著頭腦一種很茫然的感覺。

曾經以為程序就是軟件，軟件就是程序。學習這門課程第一個收

獲是，知道了二者的不同之處。以前做過的一些小型的軟件比如加密

軟件，我也只是在程序旁邊附上一個軟件的說明，看來已經很接近作

坊了。不過大的項目沒有接觸過，用軟件工程的方法還是第一次。我

想也是程序的不斷復雜化導致了軟件危機的發生，使得人們不得不探

索新的解決方法。

經過倪老師的講解，理解了軟件工程，就是一套用于軟件的團隊

開發，以提高軟件質量和程序員工作效率為目的的規范。其核心就是,

對于軟件開發的5個重要組成部分：需求分析，設計，編碼，調試，

維護，如何組織這5個部分的工作，以及如何完成每一個工作。

吾生也有涯，而知也無涯，學習永無止境。起初，對軟件工程處

于一知半解的狀態，分工比較混亂。在劃分模塊后明確了各自分工，

漸漸形成良性循環。

在學習過程中,知道了團隊合作十分重要，爭議固然存在，但通

過討論、協商，群策群力，在不斷磨合中能夠達成一致與默契。團隊

成員中能力各有高下，互相尊重，各取所長，不宜妄自菲薄。組長多

加協調，組員積極配合，才能合作愉快。

學習能力體現在能盡快接受新的知識，順應變化，學為所用。上

《軟件工程導論》這門課，我的收獲大概如下：

我們為什么需要軟件工程呢？上面已經給出了一些原因。專業點

講，軟件工程最終是為了實現〃軟件制造業〃的社會化，工業化大生產，

提高其勞動生產效率。只有如此，軟件業才能實現社會化，工業化大生產，

才能〃做大做強〃。沒有管理的設計是失敗和混亂的設計，沒有設計

指導的編程是無序的忙碌的。根據開發的軟件的規模，應該適當程度

的運用軟件工程化的思想，需要靈活，畢竟我們開發的軟件大多數是

中小型的，大型的并不多見（我是這么認為的）。但只要涉及人員間

的交流和溝通，或多或少都要需要軟件工程才能更有效率，工作成果

更穩定。

其實開發軟件,就像是解決一個邏輯問題。想想自己平時是怎樣

寫程序的。首先是要有一個想法，即我寫的這個程序是要干什么的；

然后就是對要實現的核心功能大概構思一種或多種實現方法，并從中

選出一種自認為是較好的；接下來就是將涉及的各種主要或次要功能

分成各個模塊；最后就是分模塊來編碼和DEBUG。在我看來,除了第

一步外，其余的步驟應該是一個循環的過程。在編碼的過程中，你總

是需要不斷地回過頭來修改原先的模塊設計，甚至最初選定的實現算

法。

具體到每一步的工作要怎樣完成，是非常靈活的，只要把握住大

體的方向就行。在進行分析，設計，編碼，調試，維護這幾部分的工

作的時候，最核心的就是文檔的編寫。

1.可行性分析就是關于當前項目能不能干的分析結果。

2.項目描述這是在決定立項以后，對當前項目的一份扼要說明。3.

需求分析就是對客戶要求的功能的定義。

4軟件設計這就是對程序的每一個模塊的詳細設計的說明文檔。5.

開發日志我一直都認為這是文檔中最有趣的部分。開發日志相當于編

碼階段的文檔，它的形式可以很隨意，主要是記錄一些在寫程序時突

然萌發的靈感，或對代碼的一些微小的修改，或對程序結構的一些微

小變動等，還要對上述這些修改變動作些說明。

6.測試分析用于指出程序存在或潛在的缺陷和錯誤，以及程序性

能的數字描述。

第二篇：軟件工程心得體會（推薦）

軟件工程學習心得

這個學期我學習了軟件測試這門專業課程，在學期即將結束的時

候，我也對這門課程建立基本的了解。軟件測試這門課程作為軟件工

程專業中一門很重要的課程，已經在軟件領域占據了不可替代的角色，

當一個軟件從雛形到真正的在一臺計算機是哪個運行的時候，誰也不

能保證計算機軟件能一步到位的滿足人們的需求。所以就有了軟件測

試，其目的的：第一是確認軟件的質量，其一方面是確認軟件做了你

所期望的事情，另一方面是確認軟件以正確的方式來做了這個事情。

我認為，在整個龐大的軟件工程中，不管是需求分析、架構設計,

甚至是最后的debug,都會產生引入不管的機會，這就要去作為一個

軟件測試師要掌握豐富的軟件工程原理和知識。測試的工作將會存在

于整個項目周期，即在項目開始時需要各種分析調研時就開始了，尤

其是在形成需求規格說明書時就有對文檔的測試需求，甚至主導整個

項目的走向。

軟件測試對邏輯思維、學習能力、反應思維要求很高，是否有嚴

密的思維和逆向思維也非常重要。做測試還要考慮到所有出錯的可能

性，有時候還要用一些非常規的測試方法。軟件測試還很注重軟件性

能問題，也

就是要保證軟件運行得很好；在不同環境下，考慮軟件的兼容性

同樣重要。對于測試人員來講，會比開發人員更加重視軟件產品的質

量問題。在測試過程中，測試者可能會為可會的需求角度考慮更多，

由此我們可以認為測試人員有權利決定產品是否可以發布。然而，通

過一個學期的學習，我們又不得不懂得，軟件測試人員不是萬能的，

測試人員在面對一個設計爛編碼的軟件時，也是無法不低頭的，再怎

么測試它也變不成優秀的軟件。

通過課上的理論和課下的實踐，以及在網上和一些論壇里討論和

學習，使我對測試有了大致的接觸和深入的了解。以下就是我在軟件

測試方面的認識：

每項測試都包括三個部分，一組操作，一組預期結果和一組實際

結果。另外要盡量用最少的測試用例覆蓋軟件功能的絕大方面。考慮

到各個方面的原因，我們應考慮盡可能多的條件下的測試，這樣我們

的測試才能更具有全面性和普遍性。大體上我們的測試可以分一下幾

個方面：

(1)邊界測試，測試用戶輸入框中的數值的最大數和最小數，以

及為空時的情況。

(2)非法測試，例如在輸入數字的地方輸入字母。

(3)跟蹤測試，跟蹤一條數據的流程，保證數據的正確性。

(4)在開始測試之前應保證數據的正確性，然后再從系統中找出

各種BUG。

(5)接口測試，程序往往在接口的地方很容易發生錯誤，要在此

模塊測試勿掉以輕心。

(6)代碼重用測試，在開發過程中有些模塊功能幾乎相同，開發

人員在重用代碼時可能忘記在原有代碼上修改或修改不全面，而造成

的錯誤。

(7)突發事件測試，服務器上可能發生意外情況的測試，如網絡

中斷，電源斷電等極端的情況。

(8)外界環境測試，有些系統在開發時依賴于另外一個系統，當

另外一個系統發生錯誤時,這個系統所受到的影響的情況。

(9)系統兼容測試，例如有些程序在正6能運行正常，至IJ正5下

不能運行。有些程序在WIN2000下能運行，而到WIN98卻不能運行。

(10)用戶的易用性測試，往往用戶的需求是不斷的變化的，而

其中的一部份變化的原因，是由用戶操作上不方便引起的。

雖然課程已經接近尾聲，我卻開始對軟件測試產生濃厚興趣，也

增加了我對其的知識，在以后的大學課余時間中我一定會更加努力，

永不放棄，世上無難事，只怕有心人！通過刻苦鉆研，相信有付出就

一定有回報，總有一天,我定能在計算機和軟件測試方面有所成就。

第三篇：軟件工程心得體會

《軟件工程》的感悟

時間飛逝，不知不覺間《軟件工程》的學習已經過了大半了。在

這將近半學期的學習中，雖然我不能說我將《軟件工程》學習的有多

么的好，但是通過學習，我還是受益良多。

在以前，我一直對軟件存在一些偏見或則是誤解，認為軟件就是

程序，軟件的開發就是編寫程序，只要編完了程序，一切也就ok了，

而且我還片面的認為只要我掌握了時下最新的語言和工具，那么我就

能寫程序了。一個人，只要會編程，就能寫軟件，就是程序員；一個

公司，只要招聘一些程序員，就能開發好的軟件產品。只要有幾個有

經驗的程序員，再找些兼職的大學生，就能組成一個軟件公司。

但是通過了《軟件工程》這門課的學習，使我認識到了我以前的

錯誤。軟件其實不僅僅是程序，軟件開發其實也不僅僅是編寫程序，

軟件是思想在硬件上的載體和體現，處理的是邏輯和信息。唯有對軟

件和軟件的開發過程，有充分的認識，才能更好的開發出，過程受控、

質量受控的軟件產品。

而且在以前，我一直以為軟件的開發其實是一件很輕松快樂的事

情，只要一天坐在電腦旁敲敲鍵盤，那么一切就可以了，但是現在我

才發現，我以前的很多的思想是多么的膚淺可笑。編程其實是一種樂

趣和苦惱共存的一項創造性活動。因為編程不僅能夠滿足我們內心深

處進行創造的渴望，而且還能愉悅我們內在的情感。

而且通過學習《軟件工程》，我還學到了很多其他的東西。比如

通過學習《軟件工程》，特別是老師每次用實際的軟件現場的講解，

為我提供了一個盡早接觸世界工作和真實項目的機會。計我知道如何

在以最小的成本中，訓練自己的基本工程素質和能力，如何激發自己

的積極性等。而且通過學習《軟件工程》，還讓我認識和培養了我的

團隊協作能力，特別是對于我們這些在校的學生來說，這種學習更是

能讓我在以后工作中少走很多的彎路。

所以，通過《軟件工程》的學習，我是真的學習到了很多有用的

東西，讓我明白了很多的道理。在此我對老師的辛勤教育表示感謝，

因為是你讓我學習到了這些，是我獲益良多。

第四篇：軟件工程實驗心得體會

軟件工程實驗心得體會

軟件工程實驗心得體會一：軟件工程實驗心得體會

經過這學期軟件工程實驗的學習，深深感到用戶需求對軟件的重

要性。成功的軟件產品是建立在成功的需求基礎之上的，而高質量的

需求來源于用戶與開發人員之間有效的溝通與合作。當用戶有一個問

題可以用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，

溝通就開始了。

需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的

活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什么，我們

所要做的就是和他們交談從他們那里得到需求，只要問用戶系統的目

標特征，什么是要完成的，什么樣的系統能適合商業需要就可以了，

但是實際上需求獲取并不是想象的這樣簡單，這條溝通之路布滿了荊

棘。首先需求獲取要定義問題范圍，系統的邊界往往是很難明確的，

用戶不了解技術實現的細節，這樣造成了系統目標的混淆。

其次是對問題的理解，用戶對計算機系統的能力和限制缺乏了解，

任何一個系統都會有很多的用戶或者不同類型的用戶，每個用戶只知

道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為

一個整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完

成，他們不清楚需求是什么，或者說如何以一種精確的方式來描述需

求，他們需要開發人員的協助和指導，但是用戶與開發人員之間的交

流很容易出現障礙，忽略了那些被認為是彳艮明顯’的信息。最后是需求

的確認，因為需求的不穩定性往往隨著時間的推移產牛變動，使之難

以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。

需求獲取活動要完成的任務或者步驟的過程如下：

1、編寫項目視圖和范圍文檔

系統的需求包括四個不同的層次：業務需求、用戶需求和功能需

求、非功能性需求。業務需求說明了提供給用戶新系統的最初利益，反

映了組織機構或用戶對系統、產品高層次的目標要求，它們在項目視

圖與范圍文檔中予以說明。用戶需求文檔描述了用戶使用產品必須要

完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需

求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，

從而滿足了業務需求。

非功能性需求是用戶對系統良好運作提出的期望，包括了易用性、

反應速度、容錯性、健壯性等等質量屬性。需求獲取就是根據系統業

務需求去獲得系統用戶需求，然后通過需求分析得到系統的功能需求

和非功能需求。項目視圖和范圍文檔就是從高層次上描述系統的業務

需求，應該包括高層的產品業務目標，評估問題解決方案的商業和技

術可行性,所有的使用實例和功能需求都必須遵從的標準。而范圍文檔

定義了項目產品所包括的所有工作及產生產品所用的過程。項目相關

人員對項目的目標和范圍能達成共識，整個項目組都應該把注意力集中

在項目目標和范圍上。

2、用戶群分類

系統用戶在很多方面存在著差異，例如：使用系統的頻度和程度、

應用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、

訪問權限、地理上的布局以及個人的素質和喜好等等。根據這些差異,

你可以把這些不同的用戶分成不同的用戶類。與ULM中Usecase的

Actor概念一樣，用戶類不一定都指人，也可以包括其他應用系統、接

口或者硬件，這樣做使得與系統邊界外的接口也成為系統需求。將用

戶群分類并歸納各自特點，并詳細描述出它們的個性特點及任務狀況,

將有助于需求的獲取和系統設計。

3、建立核心隊

通常用戶和開發人員不自覺的都有一種‘我們和他們’的想法，產牛

一種對立關系，把彼此放在對立面，每一方都定義自己的‘邊界’，只想

自己的利益而忽略對方的想法。他們通過文檔、記錄和對話來溝通，

而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這

樣的方法是不正確的，不會給雙方帶來一點益處,良好的溝通關系沒有

建立導致了誤解和忽略重要的信息。只有當雙方參與者都明白要成功

自己需要什么，同時也知道要成功對方需要什么時，才能建立起一種

合作關系。

為了建立合作關系通常采取一種組隊的方式來獲取需求，建立一

個由用戶代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。

聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以

采用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注

意以下原則：小組會議應該由中立方來組織和主持，用戶和開發人員

都要參加;交流預先要確定準備和參與的規則;議題要明確并覆蓋所有關

鍵點，但信息來源應該自曲交流目標要明確，并告知所有的成員。

4、確定使用實例

從用戶代表處收集他們將使用系統完成所需任務的描述，討論用

戶與系統間的交互方式和對話要求，這就是使用實例，一個單一的使

用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。使用

實例方法給需求獲取帶來的好處來自于該方法是用以任務為中心和以

用戶為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，

使用實例方法可以使用戶更清楚地理解和認識到新系統允許他們做什

么和怎么做。描寫使用實例的時候要注意使用簡潔直白的表述，盡量

使用主動語態，用‘系統'或者'用戶彳乍為主語，比如‘用戶提交用戶密碼,

系統驗證用戶密碼是否正確‘，還有一點在描述中不要設計界面細節，

比如'用戶從下拉框中選擇產品類型使用實例為以后寫用例場景描述

中的基本路徑和擴展路徑提供了素材。

5、分析用戶工作流程

分析用戶工作流程觀察用戶執行業務任務的過程，通過分析使用

實例得到系統的用例圖。編制用例圖文檔將有助于明確系統的使用實

例和功能需求，統一建模語言的使用有助于與用戶進一步交流。每個

用例的描述應包括：編號，為每個用例分配一個唯一的編號，為需求的

追溯提供了方便;參與者，與這個用例交互的actor;前置條件,開始用

例前所必須具備的系統狀態;后置條件，用例完成后系統達到的狀態;基

本路徑，用例完成的關鍵路徑，也是用戶期望的路徑;擴展點，基本路

徑的分枝，表示意外情況;字段說明，路徑中名稱的進一步分解說明，

對以后類屬性的定義和數據庫字段設計起作用;設計約束，實現用例的

非功能約束。

6、檢查問題報告

通過檢查當前已經運行系統的問題報告來進一步完善需求客戶的

問題報告及補充需求為新系統或新版本提供了大量豐富的改進及增加

特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極

有價值的信息。

7、需求重用

如果客戶要求的功能與已有的系統很相似，則可查看需求是否有

足夠的靈活性以允許重用一些已有的軟件組件。業務建模和領域建模

式需求重用的最好方法，像分析模式和設計模式一樣，需求也有自己

的模式。

總結：經過一學期的軟工實驗，深刻感到其重要性的同時也學到

了不少的東西，將對我在今后的軟件開發過程中起極大的作用

＞軟件工程實驗心得體會二：軟件工程實驗心得＞＞（789字）

早在我選擇民政職業技術學院就讀軟件開發與項目管理這門專業

的時候，我一直認為軟件開發無非是努力的敲代碼，從敲代碼的過程

中去體會各行代碼的意思和用處，在沒學軟件工程時我一直都是努力

的敲代碼去學習軟件開發這門專業。在大一的時候我敲代碼的激情很

好，但是到大二的時候就出現問題了，我根本就不喜歡敲代碼了，看

見代碼就頭疼。所以感覺厭惡這門專業，對學習也不感興趣了。而且,

還有一件更頭疼的事是在寫一個簡單的程序時竟然老是出錯，難一點

的，復雜一點的程序竟然無從下手。但是去看程序的參考答案時都看

得懂，又感覺很容易。學了軟件工程以后，我就感覺我以前的學習方

法是錯誤的。以前我只注重于代碼，而不注重理論知識以及編程的思

路，程序的架構。以至于在些程序時沒有寫程序的思路，不能形成程

序的架構。只想到看腦袋里是否有與此類似的代碼。越想程序越亂，

最后腦袋里一片空白。不知道程序從哪個方面下手了。

軟件工程這門課程是做軟件開發的人必學的課程，通過學這門課

程，程序員就會注重軟件開發的理論知識，以及做項目開發的思路。

學了這門課程后你寫程序就不會去盲目的去套用代碼，而是理清此程

序的架構以及思路。程序該從什么時候開始，什么時候結束。在中間

需要添加什么樣的功能，以完善該軟件。其實學軟件工程并不難，而

且很容易。軟件工程與日常生活聯系起來的話，就是在一天中你該先

做什么，后做什么。理解了先做什么，后做什么了以后寫程序就不是

那么難了，再復雜的程序也可以分成幾大塊。你理清程序的思路后就

可以一步步的解決其中的難題，最終實現軟件的功能。如果沒學軟件

工程不知道理清程序的思路的話，做一個大的項目開發，那么多的代

碼，沒有一個很好的結構，最終只會導致程序混亂，錯誤百出，知道

代碼再多也會素手無策的。

總而言之，作為一個程序員學習軟件工程這門課程是至關必要的，

如果沒學習軟件工程，你就不會做項目開發，也不可能開發出一個完

善的軟件出來。

＞軟件工程實驗心得體會三：軟件工程實驗心得＞＞（1261字）

曾經看過一本書叫《道法自然》，內容略記得一二，但我最欣賞

的是它的書名。軟件設計沒什么太神秘有東西，只要用心體會，其實

一切都很自然。軟件的設計之〃道〃，也不在于設計有多么的華麗、

精巧，而在于其樸實、自然，最終達到〃以無招勝有招〃，進入一個

全新的境界。

一、軟件設計理論的層次

以我的拙見，軟件設計領域中的各種概念，可以分為以下幾個層

次來進行理解：

1、軟件設計的目的：重用性、擴展性。

這是最高的層次，是應對軟件危機的需要。

2、設計原則：低耦合、高聚合。

各種軟件設計的原則，如依賴倒置原則、單一職則原則、面向接

口等，以及各種設計模式，其根本的目的其實只是為了降低耦合這么

簡單。因為只有低藕合才能更好的適應變化，更好的重用和擴展。

3、實現方法：運用設計模式封裝變化、降低耦合。

設計模式只是用來〃封裝變化、降低耦合〃的工具而已。它是面

向對象設計時代的產物，其本質就是充分運用面向對象的三個特性，

即：封裝、繼承和多態，進行靈活的組合運用。

二、關于耦合1、耦合的粒度

耦合無論如何乜是不可避免的。當我們實現接口、繼承父類的時

候，就會不可避免的產生耦合。耦合是有不同粒度的，我們解耦到什

么粒度為止，我認為應以模塊的重用粒度為準。盡量解除重用模塊或

對象之間的耦合。而重用模塊之內的耦合，應屬于聚合的范疇，所以

不要盲目的去解耦，否則就陷入了誤區。

2、解耦的原理

怎樣才能解耦呢，或者說為什么各種設計模式能達到解耦的目的

呢?我覺得有以下幾個思路：

(1)將具體的東西抽象處理

(2)將分散的東西集中處理

而面向對象中的接口、繼承正為我們提供了這樣的一種機制。通

過訪問接口或基類或抽象類，而不是具體的實現類，從而與具體的實

現類達到了解耦的目的。我們還可以設計一些控制類，像潤滑劑一樣,

協調各實現類之間的訪問，也可以達到耦的目的。

事實上，各種設計模式的基本思想也就是這樣。創建型模式是為

了解除創建對象時產生的耦合，實際上是解除對類稱名的依賴，而結

構型和行為型是為了解除對象屬性或方法的直接調用。不管什么設計

模式，都是將對具體實現類的訪問提升為對接口、基類或用于協調的

控制類的訪問。

三、關于接口

這一節更具體，談一談接口，因為使用接口是軟件設計的重要手

段，但已經不屬于"道〃了~

1、接口與繼承

接口描述的是對象某一個方面行為特征。使用接口與使用繼承關

系各有優缺點，使用子類繼承可以繼承父類的功能，體現了重用的精

神。而接品更加靈活，因為它解除了子類與父類之間的高度耦合，它

體現在靈活擴展的精神。

2、接口與純虛類

理論上接口可以由純虛基類實現類似的功能，那為什么還我們不

去掉接口的概念，而直接使用虛類呢？

接口存在的理由就是它更加靈活，關系簡單，易于理解。比如一

個類可以實現十幾個甚至幾十個接口，但一般開發工具只支持單繼承

(由于多繼承太容易導致混亂和沖突)，如果要繼承十幾層，系統結構想

必會無法理解了，我以為這是接口存在的最重要的原因。

如果接口和虛美繼承結合使用，可以產生強大的威力，這也是許

多設計模式的〃殺手澗〃。

以上算是總結一下自己的心得。肯定有不少片面之處，請各位指

教。

第五篇：軟件工程實習心得體會

軟件工程實習心得體會

(-)在這次軟件工程課程