軟件工程實驗心得

第一篇：軟件工程實驗心得

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

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

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

軟件工程實驗心得（2）：

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

一、軟件設計理論的層次

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

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

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

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

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

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

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

二、關於耦合

1、耦合的粒度

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

2、解耦的原理

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

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

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

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

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

三、關於接口

這一節更具體，談一談接口，因為使用接口是軟件設計的重要手段，但已經不屬於“道”了~

1、接口與繼承

接口描述的是對象某一個方面行為特徵。使用接口與使用繼承關係各有優缺點，使用子類繼承可以繼承父類的功能，體現了重用的精神。而接品更加靈活，因為它解除了子類與父類之間的高度耦合，它體現在靈活擴展的精神。

2、接口與純虛類

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

接口存在的理由就是它更加靈活，關係簡單，易於理解。比如一個類可以實現十幾個甚至幾十個接口，但一般開發工具只支持單繼承(由於多繼承太容易導致混亂和衝突)，如果要繼承十幾層，系統結構想必會無法理解了，我以為這是接口存在的最重要的原因。

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

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

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

軟件工程實驗的心得體會

---- 獲取用户需求的溝通技巧

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

需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用户知道需求是什麼，我們所要做的就是和他們交談從他們那裏得到需求，只要問用户系統的目標特徵，什麼是要完成的，什麼樣的系統能適合商業需要就可以了，但是實際上需求獲取並不是想象的這樣簡單，這條溝通之路佈滿了荊棘。首先需求獲取要定義問題範圍，系統的邊界往往是很難明確的，用户不瞭解技術實現的細節，這樣造成了系統目標的混淆。

其次是對問題的理解，用户對計算機系統的能力和限制缺乏瞭解，任何一個系統都會有很多的用户或者不同類型的用户，每個用户只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎麼樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什麼，或者説如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是用户與開發人員之間的交流很容易出現障礙，忽略了那些被認為是"很明顯"的信息。最後是需求的確認，因為需求的不穩定性往往隨着時間的推移產生變動，使之難以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。

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

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

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

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

2、用户羣分類

系統用户在很多方面存在着差異，例如：使用系統的頻度和程度、應用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、訪問權限、地理上的佈局以及個人的素質和喜好等等。根據這些差異，你可以把這些不同的用户分成不同的用户類。與ulm中usecase的actor概念一樣，用户類不一定都指人，也可以包括其他應用系統、接口或者硬件，這樣做使得與系統邊界外的接口也成為系統需求。將用户羣分類並歸納各自特點，並詳細描述出它們的個性特點及任務狀況，將有助於需求的獲取和系統設計。

3、建立核心隊

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

為了建立合作關係通常採取一種組隊的方式來獲取需求，建立一個由用户代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以採用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意以下原則：小組會議應該由中立方來組

織和主持，用户和開發人員都要參加；交流預先要確定準備和參與的規則；議題要明確並覆蓋所有關鍵點，但信息來源應該自由；交流目標要明確，並告知所有的成員。

4、確定使用實例

從用户代表處收集他們將使用系統完成所需任務的描述，討論用户與系統間的交互方式和對話要求，這就是使用實例，一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。使用實例方法給需求獲取帶來的好處來自於該方法是用以任務為中心和以用户為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用實例方法可以使用户更清楚地理解和認識到新系統允許他們做什麼和怎麼做。描寫使用實例的時候要注意使用簡潔直白的表述，儘量使用主動語態，用"系統"或者"用户"作為主語，比如"用户提交用户密碼，系統驗證用户密碼是否正確"，還有一點在描述中不要設計界面細節，比如"用户從下拉框中選擇產品類型"。使用實例為以後寫用例場景描述中的基本路徑和擴展路徑提供了素材。

7、分析用户工作流程

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

5、檢查問題報告

通過檢查當前已經運行系統的問題報告來進一步完善需求客户的問題報告及補充需求為新系統或新版本提供了大量豐富的改進及增加特性的想法，負責提供用户支持及幫助的人能為收集需求過程提供極有價值的信息。

6、需求重用

如果客户要求的功能與已有的系統很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。業務建模和領域建模式需求重用的最好方法，像分析模式和設計模式一樣，需求也有自己的模式。

小結 ：經過一學期的軟工實驗，深刻感到其重要性的同時也學到了不少的東西 ，將對我在今後的軟件開發過程中起極大的作用。

第三篇：軟件工程實驗報告

《軟件工程》課程實驗報告

實驗名稱：教務管理系統之子系統——學院課程安排

姓名：

院 （系）：軟 件 學 院

專業班級：

學號：

指導教師：

地點：

成績：

時間：2014 年 10月 日 至 2014 年 11月 8 日

1.實驗目的

確定項目的可實施性，獲取項目的需求，並在此基礎上完成系統的邏輯功能模型的建立，瞭解軟件工程中需求分析階段的主要活動和需求分析文檔描述的主要內容，掌握利用數據流圖描述系統功能需求的方法，正確應用數據字典。增進對軟件工程的理解，學會系統的分析軟件的構成，掌握並理解軟件從確立到測試等一系列過程。

2.實驗內容

1. 系統簡介

每個學期的期中，學校教務處向各個學院發出下各學期的教學計劃，包括課程名稱、課程代碼、課時、班級類別（本科、專科、成人教育、研究生）、班號等；學院教學主管人員根據教學任務和要求給出各個課程的相關限制（如：任課教師的職稱、上課的班數、最高和最低周學時數等）；任課教師自報本人授課計劃，經所在教研室協調任可，將教學計劃上交學院主管教學計劃的人員，批准後上報學校教務處，最終由教務處給出下個學期全學院教師的教學任務書。

假設上述排課過程全部由人工操作，現要求為上述過程實現計算機自動處理過程。

2. 限定條件

a) 每位教師的主講課程門數不超過2門/學期：講師以下職稱的教師不能承擔學院定主課的主講任務。

b) 學院中層幹部的主講課時不能超過4學時/周。

c) 本學期出現嚴重教學事故的教師不能承擔下各學期的主講任務。

d) 本系統的輸入項至少包括：教務處佈置的教學計劃，學院教師自報的授課計劃和學院定的有關授課限制條件。

e) 本系統的輸出項至少包括：教務處最終下達全院教師的教學任務書和學院各個班級下各學期的課程表（可以不含上課地點）。

項目數據流圖

系統的分析“教務管理系統之子系統——學院課程安排”的組成、結構和實現步驟，明白項目的業務流程圖，繪製數據流圖（dfd），數據模型（er），編寫數據字典（dd），數據加工處理的描述，撰寫需求規格説明書

3.實驗步驟

1.

2.

3.

4.

5. 對圖書管理系統進行分析，整合用户權限和操作 根據用户操作流程畫出系統流程圖 對系統做出概要分析，擬定開發流程 繪製出甘特圖 繪製線性時間圖

4總結與回顧

通過這次實驗，我學到了很多東西，教務管理系統是學校的管理核心，管理應涉及到學校的專業設置、學藉管理、成績管理、網上註冊、開課管理、選課管理、師資管理等，在數據庫一級建立強有力的安全系統，管理人員可以在互聯網的任何地方辦工，

真正實現學校網上管理。

學校中的教務管理是一項很重要的工作，包括學生管理，教師管理和課程管理等。開發“教務信息處理系統”的目的就是利用計算機的查詢和運算功能，代替手工處理，提高工作效力和質量，所以該系統是必要而且能夠實現的。

此次開發的軟件是教務管理系統的一個子系統，即學院課程安排。通過此次課程設計，我們更加了解了軟件的原理，軟件的開發方法和步驟，如繪製數據流圖和數據字典的編寫。進一步掌握了有關數據庫設計的知識和java程序設計，瞭解了有關網絡的相關知識，對軟件開發平台有了一定了解。我增長了不少軟件工程與編程，數據庫的知識。在作設計的過程中，軟件是不斷變化的，開始構造的是一方面，實際製作時又是另外一方面，所以得不斷變化。軟件必須有效的支持他的用户，我們做的軟件是學生選課系統，所以我們需要從學生和老師，管理員的實際情況出發，制定他們操作方便的系統，是軟件對用户友好。

在寫數據字典之前，我對數據字典的理解有一些偏差，通過這次作實驗，我知道了數據字典就是對數據流，數據流分量，數據存儲，處理的定義集合。我們做這種比較小的軟件時，數據字典還比較好維護，哪裏出了問題，可以很快的找到，然後改正。如果做比較大的軟件時，數據字典就不好維護了。開發大的軟件系統時，數據字典的規模和複雜程度迅速增加，貌似人工維護就不太可能了。

這次實驗的完成是我們小組共同努力的結果，我們每個人都付出了很大的汗水，也讓我明白了團隊合作是多麼的重要，那麼大的工作量僅靠一個人的力量是不可能完成的，在以後的工作和學習中一定要重視團隊合作的重要性，多與合作伙伴交流，瞭解每個人的想法，最後大家的想法和在一起就是個很了(本站向你推薦)不起的工作。也讓我認識到軟件在我們的生活中越來越重要，我們的生活處處離不開軟件，也讓我對自己以後的工作有了很深的瞭解，讓我可以向着自己的目標一點點前進。

第四篇：軟件工程實驗報告

《軟件工程》實驗報告

專業班級微軟it一班

學生姓名

指導教師趙春剛

實驗一需求分析

一、實驗目的

通過對軟件項目的需求分析，掌握需求分析的主要方法和技術，瞭解需求分析過程。 二、實驗要求

自選一個軟件項目，應用軟件工程中需求分析方法對系統需求進行分析。 三、實驗內容

1、項目完成主要功能概述 （1）項目名稱

（2）項目完成主要功能

2、項目需求描述（建立需求模型） （友情提示：完成主要的用例模型即可） 四、實驗總結

實驗二軟件設計

一、實驗目的

通過對軟件項目的軟件設計，掌握軟件設計的方法的技術，瞭解軟件設計過程。 二、實驗要求

針對需求分析所選的項目和功能模塊進行。完成軟件項目主要概要設計和詳細設計。 三、實驗內容

1、項目概要設計描述（建立概要設計模型）

（友情提示：完成項目的主要系統結構圖（功能模塊圖）即可）

2、項目詳細設計描述（建立詳細設計模型）

（友情提示：用流程圖或uml相關模型（活動圖、時序圖等），完成兩個模塊以上）

四、實驗總結

説明：（此實驗為可選做，若完成實驗成績加分）

實驗三軟件測試

一、實驗目的

通過對軟件項目的測試，掌握軟件測試的原理和方法，瞭解軟件測試過程。 二、實驗要求

針對需求分析所選的項目和功能模塊進行。完成軟件項目主要功能模塊的測試。 三、實驗內容

1、採用主要測試方法描述

2、主要功能模塊測試用例設計

四、實驗總結

第五篇：軟件工程實驗要求

軟件工程實驗要求

要求：

1查詢相關資料，要求以某一個項目的進展為實驗過程，整個實驗過程是講一個系統的設計過程，比如，學生管理系統，圖書館管理系統，掃雷程序等（舉例的不要採用）

2按照軟件工程過程，強調設計的過程，主要包括需求分析，總體設計與詳細設計，也可以放入測試與維護等環節，其中設計到一些知識點，比如數據庫，數據流圖，數據字典，程序技術等。

3確定設計的系統後，請各位同學把設計的題目交給學習委員，讓學習委員進行調整，要求雷同題目，即相同的系統最多隻能2個同學使用。

4實驗報告最後打印出來，a4紙，至少5頁，需要封面（這個可以下載有江蘇理工學院封面的那個東西改一下），封面主要包括題目、姓名、學號等。文字段落等無要求，但佈局統一合理，美觀舒服為好。

5實驗報告要有實驗目的，實驗步驟，實驗心得等基本步驟，自己可以參照成熟的實驗報告添加相關的內容。

6下載相關資料時，切忌全篇下載，可以整合，但參考的資料必須比較多，換句話説，你論文中的內容在網上一搜的話，我頂多只能搜到一段，不要一搜就是一大片一樣的。

7可以下載一些圖表格等元素，但不要全部都是。

8有心的同學可以設計一個網絡上找不到的系統，自我分析整個的大概設計過程，改換一種方式表達出來。比如，你們班級的一個管理系統，自我主頁的一個設計，一個獨一無二的文學欣賞網站等，此類同學請在題目後標註是原創。 9上交時間為下週四下午2點之後，60-210