軟件工程壹直缺乏統壹的定義，很多學者和組織都給出了自己的定義:
Boehm:利用現代科技知識設計和構建計算機程序以及開發、運行和維護這些程序所必需的相關文檔和資料。
IEEE:軟件工程是壹種開發、運行、維護和修復軟件的系統方法。
弗裏茨·鮑爾(Fritz Bauer):建立和使用完美工程原理的壹系列方法，以更經濟的方式獲得可以在實際機器上有效運行的可靠軟件。
軟件工程的框架可以概括為:目標、過程和原則。
(1)軟件工程目標:生產出正確、可用、費用適當的產品。正確性是指軟件產品實現預期功能的程度。可用性是指軟件的基本結構、實現和文檔對用戶可用的程度。適度成本是指軟件開發和運行的整體成本滿足用戶要求的程度。這些目標的實現在理論和實踐上都有許多問題需要解決，對工藝、工藝模型和工程方法的選擇形成制約。
(2)軟件工程過程:生產壹個最終能滿足需求、達到工程目標的軟件產品所需的步驟。軟件工程過程主要包括開發過程、運行過程和維護過程。它們涵蓋需求、設計、實現、驗證和維護等活動。需求活動包括問題分析和需求分析。問題分析獲得需求的定義，也稱為軟件需求規範。需求分析產生功能規格。設計活動通常包括總體設計和詳細設計。概要設計確立了整個軟件體系結構，包括子系統、模塊和相關層次的描述，以及各個模塊的接口定義。詳細設計生成程序員可用的模塊描述，包括每個模塊中的數據結構描述和處理描述。實施活動將設計結果轉化為可執行的程序代碼。確認活動貫穿整個開發過程，實現完成後的確認，確保最終產品滿足用戶的要求。維護活動包括使用過程中的擴展、修改和改進。與上述流程相伴隨的，還有管理流程、支持流程、培訓流程等等。
(3)軟件工程原則是指圍繞工程設計、工程支持和工程管理，在軟件開發過程中必須遵循的原則。
軟件工程必須遵循哪些原則？
圍繞工程設計、工程支持和工程管理提出了以下四個基本原則:
(1)選擇合適的開發模式。
這個原理和系統設計有關。在系統設計中，軟件需求、硬件需求等因素相互制約、相互影響，往往需要權衡。因此，有必要了解需求定義的可變性，並采用合適的開發模型來確保軟件產品滿足用戶的需求。
(2)采用適當的設計方法。
在軟件設計中，我們通常需要考慮軟件的模塊化、抽象性、信息隱蔽性、本地化、壹致性和適應性等特點。合適的設計方法有助於實現這些功能，從而實現軟件工程的目標。
(3)提供高質量的工程支持
鋒利的工具能做好工作。在軟件工程中，支持軟件過程的軟件工具和環境是非常重要的。軟件工程項目的質量和成本直接取決於提供給軟件工程的支持的質量和有效性。
(4)重視軟件工程的管理。
軟件工程的管理直接影響到可用資源的有效利用，滿足目標的軟件產品的生產和軟件組織生產能力的提高。因此，只有有效地管理軟件過程，才能實現有效的軟件工程。
軟件工程是指導計算機軟件開發和維護的工程學科。
采用工程學的概念、原理、技術和方法來開發和維護軟件，將經過時間考驗的正確的管理技術與目前所能獲得的最佳技術方法相結合。這是軟件工程。
軟件工程強調使用生命周期方法和各種結構分析和設計技術。他們是
20世紀70年代，為了應對應用軟件越來越復雜，開發周期長，以及用戶對它的興趣。
軟件產品常常不滿足於現狀。人類通常用來解決復雜問題的策略
只是“分而治之”，即把問題分解，然後分別解決每個子問題的策略。
。從時間的角度來看，軟件工程中使用的生命周期方法是壹個復雜的軟件開發和維護問題。
分解，把軟件的長生命周期依次分成幾個階段，每個階段相對獨立。
任務，然後逐步完成每個階段的任務。當用軟件工程方法開發軟件時，
從任務的抽象邏輯分析開始，逐步進行開發。前壹階段任務
的完成是開始下壹階段工作的前提和基礎，下壹階段任務的完成通常是
它使前壹階段提出的解決方案更加具體，並增加了更多的物理細節。每個階段的開始
開頭和結尾都有嚴格的標準。對於任意兩個相鄰階段，前壹階段的結束標準為
是後期的起步標準。在每個階段結束之前，必須進行正式而嚴格的技術審查。
和管理評審，從技術和管理方面來檢查這個階段的開發成果，通過這個之後
壹個階段結束了；檢驗不合格，必須進行必要的返工，返工後再做。
經過審查。審查的主要標準之壹是“最新的”(即和。
所開發的軟件完全符合高質量的文檔，從而確保在軟件開發項目結束時有。
完整準確的軟件配置已交付使用。文件是溝通工具，清晰準確的解釋。
到這個時候，關於這個項目已經知道了什麽，並且已經建立了下壹步工作的基礎。
。此外，該文檔還充當備忘錄。如果文檔不完整，那麽壹定是忘記了壹些工作。
現在，在進入生命周期的下壹個階段之前，我們必須彌補這些缺失的細節。在完成生存周之後
在準備每個階段的任務時，要采用壹種系統的技術方法——結，適合這個階段任務的特點。
結構分析或結構設計技術。
軟件生命周期分為幾個階段，每個階段的任務相對獨立且簡單。
簡單，方便不同人員協同工作，從而降低整個軟件開發項目的難度；在軟件中
生命周期的每個階段都采用科學的管理技術和良好的技術方法，在每個階段，
結束前會從技術和管理兩個角度對他們進行嚴格考核，合格後才開始下壹階段的工作。
工作，從而使軟件開發工程的整個過程有條不紊地進行，以保證軟件
質量，尤其是軟件的可維護性。總之，軟件工程方法論可以得到很大的提高。
軟件開發的成功率和生產力也能得到顯著提高。
目前，劃分軟件生命周期階段的方法有很多，如軟件規模、類型、開發方法、
開發環境和開發中使用的方法論都會影響軟件生命周期階段的劃分。分區軟件
在生命周期的各個階段中，應該遵循的壹個基本原則是使每個階段的任務盡可能相互接近。
為了獨立性，同壹階段中每個任務的性質盡可能相同，從而降低每個階段的復雜性。
度，簡化不同階段之間的聯系，有利於軟件開發項目的組織和管理。壹般來說，軟
軟件生命周期由軟件定義、軟件開發和軟件維護三個時期組成，每個時期又進壹步。
分為幾個階段。下面的討論主要針對應用軟件，對系統軟件也基本適用。
軟件定義期的任務是確定軟件開發項目必須完成的總目標；確定項目的可行性
導出了實現工程目標應采取的策略和系統必須完成的功能；項目預計完成時間。
所需資源和費用，並制定項目進度計劃。這壹時期的工作通常被稱為系統分析。
，由系統分析員填寫。軟件定義期通常進壹步分為三個階段，即問題確定。
意義、可行性研究和需求分析。
在開發期間，對前期定義的軟件進行具體的設計和實現，通常分為以下四個階段。
成功:總體設計、詳細設計、編碼和單元測試、全面測試。
維護期的主要任務是使軟件永久滿足用戶的需求。具體來說，當軟件在
使用過程中發現錯誤時，應予以糾正；當環境發生變化時，軟件應該進行修改以適應新的環境。
；當用戶有新的需求時，要及時改進軟件，滿足用戶的新需求。通常，維護期不再
進壹步分為階段，但每個維護活動本質上都是壹個壓縮和簡化的定義和開放。
頭發處理。
下面簡要介紹軟件生命周期各階段的基本任務和結束標準。
1問題定義
問題定義階段必須回答的關鍵問題:“要解決的問題是什麽？”如果妳不知道
有什麽問題？試圖解決這個問題顯然是盲目的，只會浪費時間和金錢。最
最後的結果很可能是沒有意義的。盡管明確定義這個問題的必要性是顯而易見的。
但在實際操作中，這可能是最容易被忽視的壹步。
透過問題定義階段的工作，系統分析員應就問題的性質、工程目標及
關於規模的書面報告。通過對系統實際用戶和使用部門負責人的訪談和調查，分析者
簡單寫出他對問題的理解，在用戶和使用部門負責人的會議上認真討論。
書面報告，澄清歧義，糾正誤解，最後雙方各拿壹份。
滿意的文檔。
問題定義階段是軟件生命周期中最短的階段，通常只需要壹天或更短的時間。
時間。
2可行性研究
這壹階段需要回答的關鍵問題是:“對前壹階段確定的問題有可行的解決方案。
壹個解決方案？“為了回答這個問題，系統分析員需要壹個大大壓縮和簡化的。
系統分析和設計的過程，即在更抽象的高層次上進行分析和設計的過程。
可行性研究應該比較短，現階段的任務不是具體解決問題，而是研究問題的模型。
探討這個問題是否值得解決，是否有可行的解決方案。
在問題定義階段提出的項目目標和規模的報告通常是模糊的。可行性研究
階段要導出系統的高層邏輯模型(通常用數據流圖表示)，在此基礎上，要更多
準確、更具體地確定項目規模和目標。然後，分析師更準確地估計系統的成本和效率。
對建議系統進行有益、仔細的成本/收益分析是本階段的主要任務之壹。
可行性研究的結果是由使用部門的負責人決定是否繼續該項目。
重要的依據是，壹般來說，只有那些可能從投資中獲得更大收益的項目才值得繼續。
繼續吧。可行性研究的後期階段將需要更多的人力和物力。不值得及時停下來
不得不投資的項目可以避免更大的浪費。
3需求分析
現階段的任務仍然不是具體解決問題，而是準確確定“為了解決這個問題，
目標系統必須做什麽”主要是確定目標系統必須具備什麽功能。
用戶知道他們面臨的問題和他們要做的事情，但通常他們不能完全準確地表達出來。
滿足他們的要求，但也不知道如何使用計算機來解決他們的問題；軟件開發人員知道
如何用軟件實現人的要求，但是對具體用戶的具體要求並不完全清楚。所以這個系統
在需求分析階段，分析師必須與用戶密切合作，充分交流信息，才能獲得已被用戶確認的信息。
認知的系統邏輯模型。系統的邏輯通常用數據流圖、數據字典和簡要算法來描述。
系列型號。
在需求分析階段確定的系統邏輯模型是將來設計和實現目標系統的基礎，因為
這必須準確完整地反映用戶的需求。系統分析師通常是計算機軟件、技術
專家壹般喜歡很快開始詳細設計。然而，壹旦分析師開始談論程序設計，
細節會脫離用戶，讓他們無法繼續提出自己的訴求和建議。項目中使用的結。
結構分析和設計的方法為每個階段提供了具體的結束標準，並且必須完成需求分析階段。
整個精確的系統邏輯模型只有在用戶確認後才能進入下壹階段，這樣才能有
有效防止和克服急於進行具體設計的傾向。
4總體設計
現階段必須回答的關鍵問題是:“壹言以蔽之，這個問題應該如何解決？”
首先，應該考慮幾種可能的解決方案。例如，目標系統的壹些主要功能是使用
是計算機自動完成還是人工完成；如果妳使用計算機，妳使用批處理還是
人機交互模式；您使用傳統的文件系統還是數據庫來存儲信息？通常妳至少應該考慮
以下類型的可能方案:
低成本解決方案。系統只能完成最必要的工作，不能做壹點額外的工作。
工作。
中等成本的解決方案。這樣的系統不僅能很好地完成預定的任務，而且使用
聽起來很方便，也可能有壹些用戶沒有具體指定的功能和特性。雖然用戶沒有
這些特定的需求已經被提出，但是系統分析員根據他自己的知識和經驗得出結論，這些額外的
能力將在實踐中證明是非常有價值的。
高成本的“完美”系統。這樣的系統具有用戶可能想要的所有工作。
能力和特點。
系統分析師應該使用系統流程圖或其他工具來描述每個可能的系統，並對每個系統進行評估。
該方案的成本和收益也應與各種方案的利弊進行充分權衡？∩ Xi？平、桓、夏？nbsp
系統(最佳方案)，並制定實施推薦系統的詳細計劃。如果用戶接受該分數
分析師推薦的系統可以在這個階段開始完成另壹項主要工作。
以上工作確定了解決問題的策略，目標系統需要什麽程序，但是如何設置呢？
這些程序呢？結構設計的壹個基本原則就是程序要模塊化，也就是長流程。
前言應按照合理的層次結構，由多個規模適中的模塊組織而成。總體設計階段的第二階段
項目的主要任務是設計軟件的結構，即確定程序由哪些模塊組成以及模塊之間的關系。
關系。通常，用層次圖或結構圖來描述軟件的結構。
5詳細設計
在總體設計階段，以更抽象的方式提出問題的解決方案。細部設計階段
任務是將解決方案具體化，即回答以下關鍵問題:“這應該如何具體實現？”
系統呢？"
這個階段的任務不是寫程序，而是設計程序的詳細規格。這種規定
網格描述的作用與其他工程領域的工程師經常使用的工程藍圖非常相似。他們應該
包含必要的細節，程序員可以據此編寫實際的程序代碼。
通常使用HIPO圖(層次圖加上輸入/處理/輸出圖)或PDL語言(過程設計語言)
)描述詳細設計的結果。
6編碼和單元測試
這壹階段的關鍵任務是編寫易於理解和維護的正確程序模塊。
程序員應該根據目標系統的性質和實際環境選擇合適的高級編程。
語言(必要時匯編語言)，並將詳細設計的結果翻譯成用所選語言編寫的程序。
並仔細測試每個寫好的模塊。
7綜合測試
這個階段的關鍵任務是通過各種類型的測試(以及相應的調試)使軟件達到預設。
要求。
最基本的測試是集成測試和驗收測試。所謂集成測試，就是基於設計好的軟件結構。
根據選定的策略組裝通過單元測試的模塊，並在組裝過程中對齊它們。
以便進行必要的測試。所謂的驗收測試是按照規範的規定(通常在需求分析中
階段確定)，用戶(或者在用戶的積極參與下)將檢查和接受目標系統。
如有必要，可通過現場測試或並行操作對目標系統進行進壹步測試和檢驗。
為了使用戶在系統投產運行後能積極參與驗收測試並正確無誤。
為了有效地使用這個系統，用戶通常需要接受正式或非正式的培訓。
通過對軟件測試結果的分析，可以預測軟件的可靠性；相反，根據軟件可靠性
性需求也可以決定測試和調試過程何時結束。
測試計劃、詳細測試計劃和實際測試結果應與正式文件壹起保存。
作為軟件配置的壹個組成部分。
8軟件維護
維護階段的關鍵任務是通過各種必要的維護活動，使系統長期滿足用戶的需求。
需要。
通常有四種類型的維護活動:糾正性維護，即在使用過程中發現的診斷和糾正。
軟件錯誤；適應性維護，即修改軟件以適應環境的變化；完美的保養，
即根據用戶的要求對軟件進行改進或擴展，使其更加完善；預防性維護，也就是為將來修改軟件。
提前為維護活動做好準備。
雖然維護階段沒有進壹步劃分為更小的階段，但事實上，每項維護活動
應通過維修要求(或報告問題)，分析維修要求，提出維修要求。
維護計劃，維護計劃的審批，維護計劃的確定，軟件設計的修改，程序和測試程序的修改，
審查和驗收的壹系列步驟，所以它本質上是壹個壓縮和簡化的軟件定義和開放。
頭發的全過程。
應通過維修要求(或報告問題)，分析維修要求，提出維修要求。
維護計劃，維護計劃的審批，維護計劃的確定，軟件設計的修改，程序和測試程序的修改，
審查和驗收的壹系列步驟，所以它本質上是壹個壓縮和簡化的軟件定義和開放。
頭發的全過程。
參考資料:
"
不錯，希望妳采納。