盡管程序員領著一份不錯的薪水，可是他們也同樣付出了巨大的精力與時間。隨著軟件規模的日益龐大，用戶需求的不確定以及快速變更，使得軟件開發已經不能停留在小作坊式的個人英雄時代，它已經發展為如今的依賴團隊合作的行為，常規的管理方法已經無法滿足軟件開發的實際需求。而軟件工程正是研究如何以系統性的、規范化的 、可定量的過程化方法高效開發與管理、維護軟件的交叉性學科。

• 軟件工程過程有哪些
• 常見的軟件開發過程模型有哪些
• UML中一般有哪些圖

軟件工程過程有哪些

軟件工程是一門系統科學，是研究與應用如何以系統性的、規范性的、可定量的過程化方法來開發與維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的方法。
標準的軟件開發過程具備一定的流程，一般包括以下幾個方面的內容：可行性分析、需求分析、設計、編碼與實現、測試以及運行與維護。
（1）可行性分析
可行性分析是系統在正式立項之前必須進行的一項工作，它的目的不是為了分析軟件開發過程中的問題，也不是為了解決軟件開發過程中可能存在的問題，而是確定軟件系統是否有價值做、是否能夠以盡可能小的代價在盡可能短的時間內解決問題。

具體而言，在可行性分析階段，要確定軟件的開發目標與總的要求，所以在做可行性分析的時候，一般需要考慮技術是否可行、經濟效益是否可行、用戶操作是否可行、法律與社會是否可行等。例如，對于一個超市商品價格查詢系統而言，就需要調查顧客是否希望使用這樣的軟件，超市商品價格來源是哪里？技術上是否能夠實現等？

可行性分析一般都由戰略專家執行，該階段的文檔成果為《可行性分析報告》

（2）需求分析
需求分析是軟件項目成敗的關鍵，它是回答客戶做什么的問題，是一個對用戶的需求進行正確加工、正確理解，然后把它用軟件工程開發語言表達出來的過程。需求分析不僅僅是用戶需求，也應該死開發中遇到的所有的需求。例如，在做需求分析時，首先需要弄清楚該項目的目的是為了解決什么問題；其次弄清楚測試案例中應該輸入什么數據，最后就是弄清楚哪些人需要使用本系統等。

本階段的基本任務是和用戶一起確定要解決的問題，建立軟件的邏輯結構，編寫需求規格說明書文檔并最終得到用戶的認可。需求分析的主要方法有結構化分析方法、數據流程圖和數據字典等方法。本階段一般能形成軟件需求說明書、數據要求說明書以及初步的用戶手冊。

需求分析需要領域專家與系統架構師都參與進來，階段性文檔成果為《需求分析說明書》等。

（3）設計
軟件設計的主要任務是將軟件分解成模塊，即實現某個功能的數據和程序說明、可執行程序的程序單元。這個模塊可以是一個函數、過程、子程序、一段帶有程序說明的獨立的程序和數據，也可以是可組合、可分解以及可更換的功能單元。

軟件設計可以分為概要設計和詳細設計兩個階段。
概要設計就是結構設計，其主要目標就是給出軟件的模塊結構。在詳細設計中，首先就是要設計出模塊的程序流程、算法和數據結構，其次是設計數據庫，常用方法還是結構化程序設計方法。

該階段的文檔成果有《概要設計說明書》、《業務用例文檔》、《詳細設計說明書》、《技術用例文檔》等

（4）編碼與實現
編碼是指把軟件設計轉換成計算機可以接受的程序，即寫成以某一程序設計語言表示的“源程序清單”。程序設計語言可以是C、C++、C#或Java等。 當前軟件開發中除在專用場合，已經很少使用20世紀80年代的高級語言了，取而代之的是面向對象程序設計語言，而且面向對象的開發語言和開發環境大都合為一體，大大提高了開發的速度。由面向對象的開發語言開發的項目，系統的可擴展性與可維護性都大大增強。

該階段的文檔成果有《接口文檔》、《關鍵算法文檔》等。

（5）測試
軟件測試貫穿于軟件開發的整個過程，它的目的是以較小的代價發現盡可能多的錯誤。要實現這個目標關鍵在于根據軟件開發各階段的規格說明和程序的內部結構精心設計一套出色的測試用例（測試數據和預期的輸出結果組成了測試用例），利用這些測試用例進行測試，從而發現程序中存在的錯誤和bug。不同的測試方法有不同的測試用例設計方法，常用的測試方法有白盒測試和黑盒測試。

白盒測試是一種測試單元內部如何工作的方法，目的是通過檢查軟件內部的邏輯結構，對軟件中邏輯路徑進行覆蓋的測試，而黑盒測試不考慮程序的內部結構與特性，只根據程序功能或程序的外部特性設計測試用例，這兩種測試方法都是依據軟件的功能或對軟件的行為描述，發現軟件的接口、功能和結構錯誤。
該階段的文檔成果有《單元測試報告》、《集成測試報告》、《系統測試報告》等。

（6）運行與維護
雖然系統交付給用戶，安裝運行了，但是任何一個系統都不是一開始就能完全滿足實際的應用需求，一般在交付使用后，還需要不斷地進行再開發。而維護是指在已完成對軟件的研制（分析、設計、編碼和測試）工作并交付使用以后，對軟件產品所進行的一些軟件工程的活動。即根據軟件運行的情況，對軟件進行適當修改與維護，如完善性維護、適應性維護，以適應新的要求，以及糾正運行中發現的錯誤，編寫軟件問題報告、軟件修改報告。一個系統的質量的高低和系統的分析、設計有很大的關系，和系統的維護也有很大的關系。
需要注意的是，軟件工程比較強調文檔的重要性，所以每個階段最好能夠有文檔保存，因為每個階段建立在上一個階段的基礎之上，如果基礎出了問題，后續階段都可能會出現相應的問題，文檔正好可以備查。

常見的軟件開發過程模型有哪些

軟件開發過程描述的是軟件構造、部署以及維護的一種方法，它規定了完成各項任務所需的步驟。建立軟件開發過程模型的理論基礎是軟件生命周期理論和相關的軟件工程原則。

軟件開發過程的核心思想是將軟件開發過程分為若干個階段，每個階段都遵循“高內聚、低耦合”（耦合性：也稱塊間聯系。指軟件系統結構中各模塊間相互聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間耦合高低取決于模塊間接口的復雜性、調用的方式及傳遞的信息。。內聚性：又稱塊內聯系。指模塊的功能強度的度量，即一個模塊內部各個元素彼此結合的緊密程度的度量。若一個模塊內各元素（語名之間、程序段之間）聯系的越緊密，則它的內聚性就越高。）的特性，這樣可以有助于簡化問題、有助于驗證分階段的工作成功，并且加強對軟件開發的管理。

常見的軟件開發過程模型有瀑布模型、螺旋模型、增量模型、原型模型和RUP模型。

（1）瀑布模型
瀑布模型將軟件生命周期劃分為可行性分析、需求分析、設計、代碼實現、測試、安裝于維護等6個基本活動，并且規定了它們自上而下的固定次序，形如瀑布流水，逐層下落。圖11-1所示為瀑布模型結構圖。

在瀑布模型中，軟件開發的各項活動都嚴格按照現行方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如果驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。

作為一種最早出現的軟件開發模型，瀑布模型為項目提供了按階段劃分的檢查點，當前一階段完成后，開發人員只需要去關注后續階段的工作，所以采用瀑布模型可以嚴格地保證軟件產品最終能夠按時交付使用。但是由于瀑布模型的這種線性關系，使得各個階段的劃分太過固定，階段之間產生了大量的文檔，從而會增加工作量；在瀑布模型中，用戶只有等到整個開發過程的末期才能見到開發成果，從而會增加開發的風險；而且會產生一個嚴重的后果，就是早期的錯誤可能等到了測試才被發現，問題會被放大最終導致嚴重的后果。

（2）原型模型

原型是指模擬某種產品的原始模型，軟件系統的原型是軟件系統的一個早期可以運行的版本。原型模型是增量模型的一種形式，在開發真實系統前，首先需要構建一個簡單的系統原型，實現客戶或未來的用戶與系統的交互，客戶或用戶在對原型進行使用使用的過程中，不斷發現問題，從而達到進一步細化系統需求的目的。開發人員在已有原型的基礎上，通過逐步調整原型來滿足客戶或用戶的需求，確定客戶的真正需求，進而開發出客戶或用戶滿意的系統。圖11-3所示為原型模型結構圖。

原型模型可以克服瀑布模型的缺點，減少因為軟件需求不明造成的開發風險。它的關鍵之處在于盡可能快速地建造出軟件原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，使用原型模型進行軟件開發，最重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求，而不是系統的內部結構。

（3）螺旋模型
螺旋模型是一種采用周期性的方法來進行軟件系統開發的模型，它結合了瀑布模型與原型模型的特點，強調了其他模型所忽視的風險分析，常用于大型復雜系統的開到。圖11-2所示的為螺旋模型結構圖。

螺旋模型的優點主要表現在它設計上的靈活性，它可以在項目的各個階段進行變更，以小的分段來構建大型系統可以使成本計算簡單明了，而且風險分析可以使一些極端困難的問題和可能導致費用過高的問題被更改或取消，同時用戶評價為需求的變更帶來柔性，客戶始終能夠掌握項目的進展，從而提高需求的準確性與開發的高效性。而螺旋模型的缺點是由于它強調風險分析，要求客戶接受并相信這種分析，而做出相關反應是不容易的，需要開發人員具有相當豐富的風險憑據經驗和專門知識，而且要求用戶參與階段評價，對用戶來說比較困難，過多的迭代次數也會增加開發成本，推遲軟件交付的時間。

（4）增量模型
增量模型也稱為漸增模型，是在項目的開發過程中以一系列的增量方式開發系統。在增量模型中，軟件被作為一系列的構件來設計、實現、集成與測試。每一個構件都由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。在增量模型開發中，將整個產品分解成若干個構件，每次并不是交付一個可運行的完整產品，而是交付系統的部分可運行子系統。此種方法的優點四可以較好地適應客戶或用戶需求的變化，客戶或用戶可以分批不間斷地看到運行良好的子系統，從而降低開發風險。圖11-4所示為增量模型結構圖

缺陷：

• 系統是進行增量開發的，所以每次加法的構件在添加入系統的時候都有可能破壞已構建好的系統部分。

• 需求的變化時不可避免的，增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也容易使軟件過程的控制失去整體性。

  在增量模型中，第一個增量往往是實現基本需求的核心產品。核心產品交付使用后，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布后不斷重復，直到產生最終的完善產品。例如，使用增量模型開發字處理軟件?？梢钥紤]，第一個增量發布基本的文件管理、編輯和文檔生成功能，第二個增量發布更加完善的編輯和文檔生成功能，第三個增量實現拼寫和文法檢查功能，第四個增量完成高級的頁面布局功能。

（5）統一軟件過程RUP模型

RUP（Rational Unified Process 統一過程）是Rational公司提出的一套軟件開發過程模型。它將用戶需求轉化為軟件系統所需活動的集合，描述了一系列相關的軟件工程流程，他們具有相同的結構，即相同的流程框架。

RUP 吸收了多種開發模型的優點，具有良好的操作性與實用性。統一過程不僅是一個簡單的過程，而且是一個通用的過程框架。它可以用于各種不同類型的軟件系統、各種不同的應用領域、各種不同的項目規模等。

RUP可以用二維坐標來描述。橫軸通過時間組織，是過程展開的生命周期特征，體現開發過程的動態結構，用來描述它的術語主要包括周期（Cycle）、階段（Phase）、迭代（Iteration）和里程碑（Milestone）；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動（Activity）、產物（Artifact）、工作者（Worker）和工作流（Workflow）。

RUP中的軟件生命周期在時間上被分解為4個階段，即初始階段（Inception）、細化階段（Elaboration）、構建階段（Construction）以及交付階段（Transition）。每個階段結束于一個主要的里程碑，而每個階段本質上是兩個里程碑之間的時間跨度。圖11-5RUP所示為RUP工作流程示意圖。具體而言，四個階段的功能如下所示。

• 初始階段：初始階段的目標是為系統建立商業案例并確定項目的邊界，在這個階段定義了最終產品視圖、商業模型并確定系統范圍。它以需求分析為主，建立系統整體結構。初始階段結束時的第一個重要的里程碑是生命周期目標里程碑，它用于評價項目基本的生存能力。
• 細化階段：設計及確定系統的體系結構，制定工作計劃及資源要求。針對第一階段需求分析結果，進行設計、代碼實現、測試、然后再反饋到需求分析。該階段結束時第二個重要的里程碑是生命周期結構里程碑，它為系統的結構建立了管理基準并使項目能夠在構建階段進行衡量
• 構建階段：構建產品并繼續演進需求、體系結構、計劃直至產品提交。對初始階段的需求進行設計、代碼實現、測試、反饋。重復需求、設計、編程、測試的過程。構建階段的里程碑是初始功能里程碑，它決定了產品是否可以在測試環境中進行部署。
• 交付階段：把產品提交給用戶使用，綜合測試，交付可運行產品。該階段結束時的里程碑是產品發布里程碑。

UML中一般有哪些圖

總結

以上是生活随笔為你收集整理的软件工程：软件工程过程与方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。