軟體工程模型

軟體工程模型也稱軟體開發模型。它是指軟體開發全部過程、活動和任務的結構框架，通過該模型能清晰、直觀地表達軟體開發全過程，明確地規定要完成的主要活動和任務，它奠定了軟體項目工作的基礎。

基本介紹

• 中文名：軟體工程模型
• 外文名：Software engineering model
• 軟體：分析、設計、開發與實施
• 基於：軟體生命周期的軟體分析
• 如：RUP、敏捷

簡介

模型是用於表現更大、更複雜的物體、或體制、或概念的經過精確刻畫的一種“直觀反映”。模型通常是一個計畫的初步產品或結構，依據此模型或從模型中可產生出最終的產品。各傳統領域均用模型來表示實際產品、實際產品的生產加工過程及工藝標準等。例如，房產銷售領域通常採用按實際比例縮小的房屋結構模型來展示他們的商品，這種模型主要從實際使用角度進行模擬，讓用戶能夠直觀地感受“使用”效果；而施工圖紙也是模型，是從建造角度反映製造房屋建築的結構、質量標準、技術和工藝標準的模型。
在軟體工程領域中，我們也將採用模型來表示軟體產品在各生產階段中的進展情況和結果。例如，在軟體分析階段，可用模型來表示分析結果，在軟體設計階段用模型來反映設計方案，測試階段有測試模型；軟體實現人員根據分析、設計模型進行生產，測試人員根據測試模型進行軟體測試。

軟體工程的基本目標

軟體工程的基本目標就是在給定的資源約束條件下開發生產更多更好的軟體產品，具體表現如下：
1、開發儘可能多的軟體產品，滿足社會對軟體全方位、不同套用領域的套用需求，是軟體工程的首要目標。
2、提高軟體的生產效率。由於軟體產品的特殊性使得如何提高軟體產品的生產效率成了迫切需要解決的難題。為此，人們從各個方面研究、探討軟體產品生產的內在規律，包括生產過程的管理、組織形式、開發工具、程式設計方法等，試圖找出比較滿意的求解方案。
3、滿足套用的功能需要。這裡包括幾層意思：產品功能強、性能好、按期交付使用、易於用戶操作和維護。
4、降低軟體開發成本，包括降低軟體設計成本和軟體維護成本，而軟體維護成本比開發成本要大得多。因此，提高軟體可維護性是降低軟體開發成本的有效途徑。
在具體工程項目的實際開發過程中，試圖讓以上幾個目標都達到理想的程度往往是非常困難的。例如，如果過於追求提高軟體的性能，可能造成開發出的軟體對硬體有較大的依賴性，從而直接影響到軟體的通用性和可移植性。實際上軟體工程就是要解決如何在用戶要求的功能、質量、成本、進度之間取得平衡，滿足套用的實際需要。

常見的軟體工程模型及特點

線性順序模型

軟體工程的“線性順序模型”也稱“傳統生命周期模型”，或稱“瀑布模型”，是一種最早的、套用最廣的、支持直線型開發的過程模型。圖1是關於軟體開發階段的線性順序模型。

圖1

線性順序模型從系統分析開始，逐步經過各個開發階段到軟體開發完畢、交付使用止。每個階段的變換結果是下一個階段的變換的輸入，相鄰的兩個階段具有極其密切的因果關係。該模型以軟體的需求能夠完全被確定為前提，這種模型的特點是“一瀉千里”、易“下”而幾乎不可能“上”，因此又得名“瀑布模型”。
這種模型在分析和設計階段需要建立整個系統的視圖，即在初期就建立所有系統組成部分的需求，因為軟體必須與系統的其他組成部分——硬體、資料庫、人或其他系統進行互動，然後把這些需求的相關部分分配給軟體。
這種模型具有以下幾個缺點：
1、在開發過程中的每個變化會引起不小的混亂。
2、不能接收在項目開始階段中存在的不確定性，即在需求分析階段必須明確軟體系統的全部需
求，實際上這是較難做到的。
3、需求確定後，進行一連串的設計、實現、測試過程，才能制定出軟體的初始版本，軟體的運行
版本只能到項目開發晚期得到。如果在這時才發現錯誤，則錯誤的後果極有可能是災難性的，糾正錯誤
的代價將是非常昂貴的。
4、有些開發者往往要等待其他人員完成任務後才能進行開發工作。
5、用戶如果提出修改，則代價往往很大。

原型模型

原型是一種原始模型，是原始的類型、形式、形狀或例證的描述，是作為後期階段的基礎模型。軟體工程的“原型模型”的基本思想是從用戶處收集到的需求出發，初步定義軟體的總體目標，然後根據總體目標進行快速設計，建造一個能夠反映用戶主要需求並且能夠運行的軟體系統原型。通過運行原型，使得用戶快速了解未來軟體系統的概貌，便於快速判斷需求的正確性、操作的實用性，以及功能是否遺漏、是否需要改進或增強等意見，然後再設計、修改原型，再運行原型、徵求用戶意見，如此重複直至雙方認可。原型模型的整個構造過程是一個疊代的過程，圖2描述了原型模型。

圖2

原型模型可以幫助用戶和開發者較快速地獲取雙方理解一致的需求，但不是最終交付的軟體產品。原型作為參考，實際的軟體開發必須在充分考慮質量和可維護性等因素以後才進行。
這種模型的優點是：
1、用戶能夠很早就感覺到實際系統的“模式”，開發者可以很快地建造出一些供以後實際開發的“模型”；
2、如果理想的話，原型可以作為標識軟體需求的一種機制。
這種模型的缺點是：
1、用戶往往把看到的原型作為軟體的最初“版本”，不理解或難以理解，原型實際上是沒有考慮軟體的總體質量、性能、可維護性等一系列保證軟體質量的因素而快速“拼湊”起來的“演示軟體”，以致誤解軟體開發的艱難性；
2、由於很早就得到用戶“認可”，開發人員往往就放鬆對軟體開發的管理，開發者也常常進行“折中”，把“演示”功能中的不合理部分處理成軟體的實際功能。

增量模型

在增量模型中，軟體被作為一系列的增量構件來設計、實現、集成和測試。與構建大廈類似，先設計一個總體規劃圖，然後一層層地構造搭建整個建築。增量模型是把整個軟體系統分解為若干個軟體構件，開發過程中，逐個實現每個構件，實現一個構件，展示一個構件。如果發現問題可以及早進行修正，逐步進行完善，最終獲得滿意的軟體產品。
在使用增量模型時，第一個增量往往是實現基本需求的核心構件。該核心構件交付用戶使用後，經過評價形成下一個增量的開發計畫，它包括對核心構件的修改和一些新功能的發布。這個過程在每個增量發布後不斷重複，直到產生最終的完善產品。

螺旋模型

1988年，Barry Boehm發表了“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調其他模型所忽視的風險分析，特別適合於大型複雜的系統。該模型將開發分為4個環節（見圖3）：制訂計畫、風險分析、開發實施和用戶評估。開發活動圍繞這4個環節螺旋式地重複執行，直到最終得到用戶認可的產品。

圖3

形式化方法模型

形式化方法模型包含了一組導致計算機軟體的數學規約的活動，使得軟體工程師能夠通過使用嚴格的、數學的符號體系來規約、開發和驗證基於計算機的軟體系統。用形式化方法開發軟體時，提供一種通過數學分析來消除二義性、不完整性、不一致性問題的機制。這種方法能夠作為程式驗證的基礎，能夠發現和糾正在其他情況下發現不了的問題，可以生產高正確性的軟體。因此，這種方法往往用於開發航空、醫療等安全性能要求很高的軟體系統，但是在商業環境中不可能成為主流開發方法。
這種模型的軟體開發的特點是開發費時且費用昂貴，對開發人員的要求很高，需要具有形式化方法所必要的知識背景。