Word第第頁軟件工程實驗心得體會軟件工程試驗心得體會1

曾經看過一本書叫《道法自然》，內容略記得一二，但我最觀賞的是它的書名。軟件設計沒什么太神奇有東西，只要專心體會，其實一切都很自然。軟件的設計之“道”，也不在于設計有多么的華麗、精致，而在于其樸實、自然，最終到達“以無招勝有招”，進入一個全新的境界。

一、軟件設計理論的層次

以我的拙見，軟件設計領域中的各種概念，可以分為以下幾個層次來進行理解：

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

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

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

各種軟件設計的原則，如依靠倒置原則、單一職則原則、面對接口等，以及各種設計模式，其根本的目的其實只是為了降低耦合這么簡潔。由于只有低耦合才能更好的適應改變，更好的重用和擴展。

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

設計模式只是用來“封裝改變、降低耦合”的工具而已。它是面對對象設計時代的產物，其本質就是充分運用面對對象的三個特性，即：封裝、繼承和多態，進行敏捷的組合運用。

二、關于耦合

1、耦合的粒度

耦合無論如何也是不行避開的。當我們實現接口、繼承父類的時候，就會不行避開的產生耦合。耦合是有不同粒度的，我們解耦到什么粒度為止，我認為應以模塊的重用粒度為準。盡量解除重用模塊或對象之間的耦合。而重用模塊之內的耦合，應屬于聚合的范疇，所以不要盲目的去解耦，否則就陷入了誤區。

2、解耦的原理

怎樣才能解耦呢，或者說為什么各種設計模式能到達解耦的目的呢？我覺得有以下幾個思路：

〔1〕將詳細的東西抽象處理

〔2〕將分散的東西集中處理

而面對對象中的接口、繼承正為我們供應了這樣的一種機制。通過訪問接口或基類或抽象類，而不是詳細的實現類，從而與詳細的實現類到達了解耦的目的。我們還可以設計一些掌握類，像潤滑劑一樣，協調各實現類之間的訪問，也可以到達耦的目的。

事實上，各種設計模式的基本思想也就是這樣。創建型模式是為了解除創建對象時產生的耦合，事實上是解除對類稱名的依靠，而結構型和行為型是為了解除對象屬性或方法的直接調用。不管什么設計模式，都是將對詳細實現類的訪問提升為對接口、基類或用于協調的掌握類的訪問。

三、關于接口

這一節更詳細，談一談接口，由于使用接口是軟件設計的重要手段，但已經不屬于“道”了~

1、接口與繼承

接口描述的是對象某一個方面行為特征。使用接口與使用繼承關系各有優缺點，使用子類繼承可以繼承父類的功能，表達了重用的精神。而接品更加敏捷，由于它解除了子類與父類之間的高度耦合，它表達在敏捷擴展的精神。

2、接口與純虛類

理論上接口可以由純虛基類實現類似的功能，那為什么還我們不去掉接口的概念，而直接使用虛類呢？

接口存在的理由就是它更加敏捷，關系簡潔，易于理解。比方一個類可以實現十幾個甚至幾十個接口，但一般開發工具只支持單繼承〔由于多繼承太簡單導致混亂和沖突〕，假如要繼承十幾層，系統結設想必會無法理解了，我以為這是接口存在的最重要的緣由。

假如接口和虛類繼承結合使用，可以產生強大的威力，這也是很多設計模式的“殺手锏”。

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

軟件工程試驗心得體會2

早在我選擇民政職業技術學院就讀軟件開發與項目管理這門專業的時候，我始終認為軟件開發無非是努力的敲代碼，從敲代碼的過程中去體會各行代碼的意思和用途，在沒學軟件工程時我始終都是努力的敲代碼去學習軟件開發這門專業。在大一的時候我敲代碼的激情很好，但是到大二的時候就消失問題了，我根本就不喜愛敲代碼了，觀察代碼就頭疼。所以感覺厭惡這門專業，對學習也不感愛好了。而且，還有一件更頭疼的事是在寫一個簡潔的程序時竟然老是出錯，難一點的，冗雜一點的程序竟然無從下手。但是去看程序的參考答案時都看得懂，又感覺很簡單。學了軟件工程以后，我就感覺我以前的學習方法是錯誤的。以前我只注意于代碼，而不注意理論學問以及編程的思路，程序的架構。以至于在些程序時沒有寫程序的思路，不能形成程序的架構。只想到看腦袋里是否有與此類似的代碼。越想程序越亂，最終腦袋里一片空白。不知道程序從哪個方面下手了。

軟件工程這門課程是做軟件開發的人必學的課程，通過學這門課程，程序員就會注意軟件開發的理論學問，以及做項目開發的思路。學了這門課程后你寫程序就不會去盲目的去套用代碼，而是理清此程序的架構以及思路。程序該從什么時候開頭，什么時候結束。在中間需要添加什么樣的功能，以完善該軟件。其實學軟件工程并不難，而且很簡單。軟件工程與日常生活聯系起來的話，就是在一天中你該先做什么，后做什么。理解了先做什么，后做什么了以后寫程序就不是那么難了，再冗雜的程序也可以分成幾大塊。你理清程序的思路后就可以一步步的解決其中的難題，最終實現軟件的功能。假如沒學軟件工程不知道理清程序的思路的話，做一個大的項目開發，那么多的代碼，沒有一個很好的結構，最終只會導致程序混亂，錯誤百出，知道代碼再多也會素手無策的。

總而言之，作為一個程序員學習軟件工程這門課程是至關必要的，假如沒學習軟件工程，你就不會做項目開發，也不行能開發出一個完善的軟件出來。

軟件工程試驗心得體會3

經過這學期軟件工程試驗的學習，深深感到用戶需求對軟件的重要性。勝利的軟件產品是建立在勝利的需求基礎之上的，而高質量的需求來源于用戶與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開頭關心用戶解決這個問題，溝通就開頭了。

需求獵取可能是最困難、最關鍵、最易出錯及最需要溝通溝通的活動。對需求的獵取往往有錯誤的熟悉：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問用戶系統的目標特征，什么是要完成的`，什么樣的系統能適合商業需要就可以了，但是事實上需求獵取并不是想象的這樣簡潔，這條溝通之路布滿了荊棘。首先需求獵取要定義問題范圍，系統的邊界往往是很難明確的，用戶不了解技術實現的詳情，這樣造成了系統目標的混淆。

其次是對問題的理解，用戶對計算機系統的力量和限制缺乏了解，任何一個系統都會有許多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統，而不知道系統的整體狀況，他們不知道系統作為一個整體怎么樣工作效率更好，也不太清晰那些工作可以交給軟件完成，他們不清晰需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發人員的幫助和指導，但是用戶與開發人員之間的溝通很簡單消失障礙，忽視了那些被認為是很明顯的信息。最終是需求確實認，由于需求的不穩定性往往隨著時間的推移產生變動，使之難以確認。為了克服以上的問題，必需有組織的執行需求的獵取活動。

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

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

系統的需求包括四個不同的層次：業務需求、用戶需求和功能需求、非功能性需求。業務需求說明白供應給用戶新系統的最初利益,反映了組織機構或用戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求文檔描述了用戶使用產品必需要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需求定義了開發人員必需實現的軟件功能，使得用戶能完成他們的任務，從而滿意了業務需求。

非功能性需求是用戶對系統良好運作提出的期望，包括了易用性、反應速度、容錯性、健壯性等等質量屬性。需求獵取就是依據系統業務需求去獲得系統用戶需求，然后通過需求分析得到系統的功能需求和非功能需求。項目視圖和范圍文檔就是從高層次上描述系統的業務需求，應當包括高層的產品業務目標，評估問題解決方案的商業和技術可行性,全部的使用實例和功能需求都必需遵從的標準。而范圍文檔定義了項目產品所包括的全部工作及產生產品所用的過程。項目相關人員對項目的目標和范圍能達成共識,整個項目組都應當把留意力集中在項目目標和范圍上。

2、用戶群分類

系統用戶在許多方面存在著差異，例如：使用系統的頻度和程度、應用領域和計算機系統學問、所使用的系統特性、所進行的業務過程、訪問權限、地理上的布局以及個人的素養和愛好等等。依據這些差異，你可以把這些不同的用戶分成不同的用戶類。與ULM中Usecase的Actor概念一樣，用戶類不肯定都指人，也可以包括其他應用系統、接口或者硬件，這樣做使得與系統邊界外的接口也成為系統需求。將用戶群分類并歸納各自特點，并具體描述出它們的獨特特點及任務狀況，將有助于需求的獵取和系統設計。

3、建立核心隊

通常用戶和開發人員不自覺的都有一種我們和他們的想法，產生一種對立關系，把彼此放在對立面，每一方都定義自己的邊界，只想自己的利益而忽視對方的想法。他們通過文檔、記錄和對話來溝通，而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這樣的方法是不正確的，不會給雙方帶來一點好處,良好的溝通關系沒有建立導致了誤會和忽視重要的信息。只有當雙方參加者都明白要勝利自己需要什么，同時也知道要勝利對方需要什么時，才能建立起一種合作關系。

為了建立合作關系通常實行一種組隊的方式來獵取需求，建立一個由用戶代表和開發人員組成的聯合小組作為需求獵取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以采納會議、電子郵件、綜合辦公系統等方式進行溝通，但溝通時應留意以下原則：小組會議應當由中立方來組織和主持，用戶和開發人員都要參與;溝通預先要確定預備和參加的規章;議題要明確并掩蓋全部關鍵點，但信息來源應當自由;溝通目標要明確，并告知全部的成員。

4、確定使用實例

從用戶代表處收集他們將使用系統完成所需任務的描述，商量用戶與系統間的交互方式和對話要求，這就是使用實例，一個單一的使用實例可能包括完成某項任務的很多規律相關任務和交互挨次。使用實例方法給需求獵取帶來的好處來自于該方法是用以任務為中心和以用戶為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用實例方法可以使用戶更清晰地理解和熟悉到新系統允許他們做什么和怎么做。描寫使用實例的時候要留意使用簡潔直白的表述，盡量使用主動語態，用系統或者用戶作為主語，比方用戶提交用戶密碼，系統驗證用戶密碼是否正確，還有一點在描述中不要設計界面詳情，比方用戶從下拉框中選擇產品類型。使用實例為以后寫用例場景描述中的基本路徑和擴展路徑供應了素材。

5、分析用戶工作流程

分析用戶工作流程觀看用戶執行業務任務的過程，通過分析使用實例得到系統的用例圖。編制用例圖文檔將有助于明確系統的使用實例和功能需求，統一建模語言的使用有助于與用戶進一步溝通。每個用例的描述應包括：編號,為每個用例安排一個唯一的編號，為需求的追溯供應了便利;參加者，與這個用例交互的actor;前置條件，開頭用例前所必需具備的系統狀態;后置條件，用例完成后系統到達的狀態;基本路徑，用例完成的關鍵路徑，也是用戶期望的路徑;擴展點，基本路徑的分枝，表示意外狀況;字段說明，路徑中名稱的進一步分解說明，對以后類屬性的定義和數據庫字段設計起作用;設計約束，實現用例的非功能約束。

6、檢查問題報告

通過檢查當前已經運行系統的問題報告來