軟考—軟體設計師（軟體工程基礎知識）

1. 軟體生存周期

同任何事物一樣，一個軟體産品或軟體系統也要經曆孕育、誕生、成長、衰亡的許多階段，一般稱為軟體生存周期。把整個軟體生存周期劃分為若幹階段，使得每個階段有明确的任務，使規模大、結構複雜和管理複雜的軟體的開發變得容易控制和管理。通常，軟體生存周期包括可行性分析與項目開發計劃、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等活動，可以将這些活動以适當的方式配置設定到不同的階段去完成。 1.可行性分析與項目開發計劃 這個階段主要确定軟體的開發目标及其可行性。必須要回答的問題是：要解決的問題是什麼？該問題有可行的解決辦法嗎？若有解決的辦法，則需要多少費用？需要多少資源？需要多少時間？要回答這些問題，就要進行問題定義、可行性分析，制定項目開發計劃。 可行性分析與項目計劃階段的參加人員有使用者、項目負責人和系統分析師。該階段産生的主要文檔有可行性分析報告和項目開發計劃。 2.需求分析 需求分析階段的任務不是具體地解決問題，而是準确地确定軟體系統必須做什麼，确定軟體系統的功能、性能、資料和界面等要求，進而确定系統的邏輯模型。該階段的參加人員有使用者、項目負責人和系統分析師。該階段産生的主要文檔有軟體需求說明書。 3.概要設計 在概要設計階段，開發人員要把确定的各項功能需求轉換成需要的體系結構。在該體系結構中，每個成分都是意義明确的子產品，即每個子產品都和某些功能需求相對應，是以，概要設計就是設計軟體的結構，明确軟體由哪些子產品組成，這些子產品的層次結構式怎樣的，這些子產品的調用關系是怎樣的，每個子產品的功能是什麼。同時，還要設計該項目的應用系統的總體資料結構和資料庫結構，即應用系統要存儲什麼資料，這些資料是什麼樣的結構，它們之間有什麼關系。 概要設計階段的參加人員有系統分析師和軟體設計師。該階段産生的主要文檔有概要設計說明書。 4.詳細設計 詳細設計階段的主要任務是對每個子產品完成的功能進行具體描述，要把功能描述轉變為精确地、結構化的過程描述。即該子產品的控制結構是怎樣的，先做什麼，後做什麼，有什麼樣的條件判定，有什麼重複處理等，并用相應的表示工具把這些控制結構表示出來。 詳細設計階段的參加人員有軟體設計師和程式員。該階段産生的主要文檔有詳細設計文檔。 5.編碼 編碼階段就是把每個子產品的控制結構轉換成計算機可接受的程式代碼，即寫成某種特定程式設計語言表示的源程式清單。 6.測試 測試是保證軟體品質的重要手段，其主要方式是在設計測試用例的基礎上建廠軟體的各個組成部分。測試階段的參加人員通常是另一部門（或機關）的軟體設計師或系統分析師。該階段産生的主要文檔有軟體測試計劃、測試用例和軟體測試報告。 7.維護 軟體維護是軟體生存周期中時間最長的階段。已傳遞的軟體投入正式使用後，便進入軟體維護階段，它可以持續幾年甚至幾十年。在軟體運作過程中可能由于各方面的願意需要對它進行修改，其原因可能是運作中發現了軟體隐含的錯誤而需要修改；也可能是為了适應變化了的軟體工作環境而需要做适當變更；也可能是因為使用者業務發生變化而需要擴充和增強軟體的功能；還可能是為将來的軟體維護活動做預先準備等。 總結上文為表格：

名稱	階段工作	參與的人員	産生的文檔
可行性分析與項目開發計劃	主要确定軟體的開發目标及其可行性	使用者、項目負責人和系統分析師	可行性分析報告和項目開發計劃
需求分析	此階段的任務不是具體地解決問題，而是準确地确定軟體系統必須做什麼，确定軟體系統的功能、性能、資料和界面等要求，進而确定系統的邏輯模型。	使用者、項目負責人和系統分析師	軟體需求說明書
概要設計	開發人員要把明确的各項功能需求轉換成需要的體系結構。	系統分析師和軟體設計師	概要設計說明書
詳細設計	對每個子產品完成的功能進行具體描述，要把功能描述轉變為精确地、結構化的過程描述。	軟體設計師和程式員	詳細設計文檔
編碼	把每個子產品的控制結構轉化成計算機可接受的程式代碼，即寫成某種特定程式設計語言表示的源程式清單。	程式員	源程式清單
測試	保證軟體品質的重要手段，其主要方式是在設計測試用例的基礎上檢查軟體的各個組成部分。	通常是另一部門（或機關）的軟體設計師或系統分析師	軟體測試計劃、測試用例和軟體測試報告
維護	軟體生存周期中時間最長的階段。在軟體運作過程中可能由于各方面的原因需要對它進行修改。	維護人員

2.軟體過程模型

軟體過程模型習慣上也稱為軟體開發模型，它是軟體開發全部過程、活動和任務的結構架構。典型的軟體過程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、噴泉模型、基于構件的開發模型和形式化方法模型等。 1.瀑布模型（Waterfall Model） 瀑布模型是将軟體生存周期中的各個活動規定為依線性順序連結的若幹階段的模型，包括需求分析、設計、編碼、測試、運作與維護。它規定了由前至後、互相銜接的固定次序，如同瀑布流水逐級下落，如下圖所示。

瀑布模型為軟體的開發和維護提供了一種有效的管理模式，根據這一模型指定開發計劃，進行成本預算，組織開發力量，以項目的階段評審和文檔控制為手段有效地對整個開發過程進行指導，是以它是以文檔作為驅動、适合于軟體需求很明确的軟體項目的模型。

瀑布模型假設，一個待開發的系統需求是完整的、簡明的、一緻的，而且可以先于設計和實作完成之前産生。

瀑布模型的一個變體是V模型，如下圖所示。V模型描述了品質保證活動和溝通、模組化相關活動以及早起建構相關的活動之間的關系。随着軟體團隊工作沿着V模型左側步驟向下推進，基本問題需求逐漸細化，形成問題及解決方案的技術描述。一旦編碼結束，團隊沿着V模型右側的步驟向上推進工作，其實際上是執行了一系列測試（品質保證活動），這些測試驗證了團隊沿着V模型左側步驟向下推進過程中所生成的每個模型。V模型提供了一種将驗證确認活動應用于早起軟體工程工作中的方法。

瀑布模型的優點是，容易了解，管理成本低；強調開發的階段性早起計劃及需求調查和産品測試。不足之處是，客戶必須能夠完整、正确和清晰地表達他們的需要；在開始的兩個或3個階段中，很難評估真正的進度狀态；當接近項目結束時，出現了大量的內建和測試工作；直到項目結束之前，都不能示範系統的能力。在瀑布模型中，需求或設計中的錯誤往往隻有到了項目後期才能夠被發現，對于項目風險的控制能力較弱，進而導緻項目常常延期完成，開發費用超出預算。

2.增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型實作的疊代特征，它假設可以将需求分段為一系列增量産品，每一增量可以分别開發。該模型采用随着日城市間的進展而交錯的線性序列，每一個線性序列産生軟體的一個可釋出的“增量”，如下圖所示。當使用增量模型時，第一個增量往往是核心的産品。客戶對每個增量的使用和評估都作為下一個增量釋出的新特征和功能，這個過程在每一個增量釋出後不斷重複，直到産生了最終的完善産品。增量模型強調每一個增量均釋出一個可操作的産品。

增量模型作為瀑布模型的一個變體，具有瀑布模型的所有優點。此外，它還有以下優點：第一個可傳遞版本所需要的成本和時間很少；開發由增量表示的小系統所承擔的風險不大；由于很快釋出了第一個版本，是以可以減少使用者需求的變更；運作增量投資，即在項目開始時，可以僅對一個或兩個增量投資。

增量模型有以下不足之處：如果沒有對使用者的變更要求進行規劃，那麼差生的初始增量可能會造成後來增量的不穩定；如果需求不像早起思考的那樣穩定和完整，那麼一些增量就可能需求重新開發，重新釋出；管理發生的成本、進度和配置的複雜性可能會超出組織的能力。

3.演化模型（Evolutionary Model）

軟體類似于其他複雜的系統，會随着時間的推移而演化。在開發過程中，常常會面臨以下情形：商業和産品需求經常發生變化，直接導緻最終産品難以實作；嚴格的傳遞時間使得開發團隊不可能圓滿地完成軟體産品，但是必須傳遞功能有線的版本以應對競争或上頁壓力；很好地了解了核心産品和系統需求，但是産品或系統擴充的細節問題卻沒有定義。在上述情況和類似情況下，軟體開發人員需要一種專門應對不斷演變的軟體産品的過程模型。

演化模型是疊代的過程模型，使得軟體開發人員能夠逐漸開發出更完整的軟體版本。演化模型特别适用于對軟體需求缺乏準确認識的情況。典型的演化模型有原型模型和螺旋模型等。

3.1原型模型（Prototype Model）

大量的實踐表明，在開發初期很難得到一個完整的、準确地需求規格說明。這主要是由于客戶往往不能準确地表達對未來系統的全面要求，開發者對要解決的應用問題模糊不清，以至于形成的需求規格說明常常 是不完整的、不準确的，有時甚至是有歧義的。此外，在整個開發過程中，使用者可能會産生新的要求，導緻需求的變更。而瀑布模型難以适應這種需求的不确定性和變化，于是出現了快速原型（rapid portotype）這種新的開發方法。

原型是預期系統的一個可執行版本，反映了系統性質的一個標明的子集。一個原型不必滿足目标軟體的所有限制，其母的是能快速、低成本地建構原型。原型模型如下圖所示。

原型模型開始于溝通，其目的是定義軟體的總體目标，辨別需求，然後快速指定原型開發的計劃，确定原型的目标和範圍，采用快速設計的方式對其進行模組化，并建構原型。被開發的原型應傳遞給客戶使用，并收集客戶的回報意見，這些回報意見可在下一輪中對原型進行改進。在前一個原型需要改進，或者需要擴充其範圍的時候，進入下一輪原型的疊代開發。

根據使用原型的目的不同，原型可分為探索型原型、實驗型原型和演化型原型3中。探索型原型的目的是要弄清楚目标的要求，确定所希望的特性，所探讨多種方案的可行性。實驗型原型的摸得是驗證方案或算法的合理性，是在大規模開發和實作前，用于考察方案是否合适、規格說明是否可靠等。演化型原型的目的是将原型作為目标系統的一部分，通過對原型的多次改進，逐漸将原型演化成最終的目标系統。

3.2螺旋原型（Spiral Model）

對于複雜的大型軟體，開發一個原型往往達不到要求。螺旋模型将瀑布模型和演化模型結合起來，加入了兩種模型均忽略的風險分析，彌補了着兩種模型的不足。

螺旋模型将開發過程分為幾個螺旋周期，每個螺旋周期大緻和瀑布模型相符合，如下圖所示。每個螺旋周期分為如下4個工作步驟。

（1）制定計劃。确定軟體的目标，標明實施方案，明确項目開發的限制條件。

（2）風險分析。分析所選的方案，識别風險，消除風險。

（3）實施工程。實施軟體開發，驗證階段性産品。

（4）使用者評估。評估開發工作，提出修正建議，建立下一個周期的開發計劃。

螺旋模型強調風險分析，使得開發人員和使用者對每個演化層出現的風險有所了解，進而做出應有的反應。是以，該模型特别适用于龐大、複雜并且具有高風險的系統。

與瀑布模型相比，螺旋模型支援使用者需求的動态變化，為使用者參與軟體開發的所有關鍵決策提供了友善，有助于提高軟體的适應能力，并且為項目管理人員及時調整管理決策提供了便利，進而降低了軟體開發的風險。在使用螺旋模型進行軟體開發時，需要開發人員具有相當豐富的風險評估經驗和專業知識。另外，過多的疊代次數會增加開發成本，延遲送出時間。

4.噴泉模型（Water Fountain Model）

噴泉模型是一種以使用者需求為動力，以對象作為驅動的模型，适合于面向對象的開發方法。它克服了瀑布模型不支援軟體重用和多項開發活動內建的局限性。噴泉模型使開發過程具有疊代型和無間隙性，如下圖所示。疊代以為着模型中的開發活動常常需要重複多次，在疊代過程中不斷地完善軟體系統。無間隙是指在開發活動（如分析、設計、編碼）之間不存在明顯的邊界，也就是說，它不像瀑布模型那樣，在需求分析活動結束後才開始設計活動，在設計活動結束後才開始編碼活動，而是允許各開發活動交叉、疊代地進行。

噴泉模型的各個階段沒有明顯的界限，開發人員可以同步進行。其優點是可以提高軟體項目的開發相率，節省開發時間。由于噴泉模型在各個開發階段是重疊的，在開發過程中需要大量的開發人員，不利于項目的管理。此外，這種模型要求嚴格管理文檔，使得稽核的難度加大。

5.基于構件的開發模型（Component-based Development Model）

基于構件的開發是指利用預先包裝的構件來構造應用系統。構件可以試組織内部開發的構件，也可以使商品化成品（Commercial Off-The_shelf,COTS）軟體構件。基于構件的開發模型具有很多螺旋模型的特點，它本質上是演化模型，需要以疊代方式建構構件。其不同之處在于，基于構件的開發模型采用預先打包的軟體構件開發應用系統。

一種基于構件的開發模型如下圖所示，包括領域工程和應用系統工程兩部分。

領域工程的目的是建構領域模型、領域基準體系結構和可複用構件庫。為達到此目的，首先要進行領域分析，分析該領域中各種應用系統的公共部分或相似部分，建構領域模型和領域基準體系結構，表示領域的候選構件，對候選構件進行可變性分析，以适應多個應用系統的需要，最後建構可複用構件，經嚴格測試和包裝後存入可複用構件庫。

應用系統工程的目的是使用可複用構件組裝應用系統。首先進行應用系統分析，設計應用系統的體系結構，表示應用系統所需的構件，然後在可複用構件庫中查找合适的構件（也可以購買第三方構件），這些選取的構件需進行特化，必要時做适當的修改，以适應該應用系統的需要。對于那些未找到合适構件的應用部分，仍需單獨開發，并将其與特化修改後的構件組裝成應用系統。在此過程中，還需要對可複用構件的複用情況進行評價，以改進可複用構件，同時對新開發的部分進行評價，并向領域工程推薦候選構件。

綜上總結表格如下：

模型名稱	模型工作過程	優點	缺點	适用模型
瀑布模型	将軟體生存周期中的各個活動規定為依線性順訊連接配接的若幹階段的模型，包括需求分析、設計、編碼、測試、運作與維護。它規定了由前至後、互相銜接的固定次序，如瀑布流水逐級下落。	容易了解，管理成本低；強調開發階段性早期計劃及需求調查和産品測試。	客戶必須能夠完整、正确和清晰地表達他們的需要，在開始的2個或3個階段中，很難評估真正的進度狀态；當接近項目接受時，出現了大量的內建和測試工作；直到項目結束之前，都不能示範系統的能力。需求或設計中的錯誤往往隻有到了項目後期才能夠被發現，對于項目風險的控制能力較弱，進而導緻項目常常 延期完成，開發費用超出預算。	它是以文檔作為驅動、适合于軟體需求很明确的軟體項目的模型。
增量模型	融合了瀑布模型的基本成分和原型實作的疊代特征，它假設可以将需求分段為一系列增量産品，每一增量可以分别開發。	具有瀑布模型的所有優點，還具有第一個可傳遞版本所需要的成本和時間很少；開發由增量表示的小系統所承擔的風險不大；由于很快釋出第一個版本，是以可以減少使用者需求的變更；運作增量投資，即在項目開始時，可以僅對一個或兩個增量投資。	如果沒有對使用者的變更要求進行規劃，那麼産生的初始增量可能會造成後來增量的不穩定；如果需求不像早期思考的那樣穩定和完整 ，那麼一些增量就可能需要重新開發，重新釋出；管理發生的成本、進度和配置的複雜性可能會超出組織的能力。
原型模型	目的是快速、低成本地建構原型。	适用于需求不明确的開發
螺旋模型	螺旋模型将瀑布模型和演化模型結合起來，加入了兩種模型均忽略的風險分析，彌補了這兩種模型的不足。	支援使用者需求的動态變化，為使用者參與軟體開發的所有關鍵決策提供了友善，有助于提高軟體的适應能力，并且為項目管理人員及時調整管理決策提供了便利，進而降低了軟體開發的風險。	過多的疊代次數會增加開發成本，延遲送出時間。	适用于龐大、複雜并且具有高風險系統。
噴泉模型	是一種以使用者需求為動力，以對象作為驅動的模型。	可以提高軟體項目的開發效率，節省開發時間。	需要大量的開發人員，不利用項目的管理，此外，要求嚴格管理文檔，是的稽核的難度加大。	适合于面向對象的開發方法。

3.ISO/IEC9126的軟體品質模型

其中包括6個品質特性和21個品質子特性。

功能性	可靠性	可用性	效率	可維護性	可移植性
功能性是指與軟體所具有的各項功能及其規定性質有關的一組屬性	可靠性是指在規定條件下和規定時間周期内，與軟體維護其性能級别的能力有關的一組屬性。反映的是軟體中存在的需求錯誤、設計錯誤和實作錯誤而造成的失效情況	可用性是指根據規定使用者或隐含使用者的評估所作出的與使用軟體所需要的努力程度有關的一組屬性	效率是指在規定條件下，與軟體性能級别和所用資源總量之間的關系有關的一組屬性	可維護性是指與對軟體進行修改的難易程度有關的一組屬性	可移植性是指與把一個軟體從一個環境轉移到另一個環境運作的能力有關的一組屬性
适合性 準确性 互操作性（互用性） 依從性 安全性	成熟性 容錯性 可恢複性	可了解性 易學性 可操作性	時間特性 資源特性	可分析性 可改變性 穩定性 可測試性	适應性 可安裝性 遵循性（一緻性） 可替換性

4.内聚與耦合

高内聚、低耦合是軟體設計的一個原則，其中内聚是指子產品内部各元素之間聯系的緊密程度，也就是代碼功能的集中程度。耦合是指子產品之間互相聯系的緊密程度。 子產品的内聚類型通常可以分為7中，根據内聚度從高到低排序如下表：

内聚類型	描述
功能内聚	完成一個單一功能，各個部分協同工作，缺一不可
順序内聚	處理元素相關，而且必須順序執行
通信内聚	所有處理元素集中在一個資料結構的區域上
過程内聚	處理元素相關，而且必須按特定的次序執行
瞬時内聚	所包含的任務必須在同一時間間隔内執行（如初始化子產品）
邏輯内聚	完成邏輯上相關的一組任務
偶然内聚	完成一組沒有關系或松散關系的任務

子產品的耦合性類型通常分為7種，根據耦合度從低到高排序如下表：

耦合類型	描述
非直接耦合	沒有直接聯系，互相不依賴對方
資料耦合	借助參數表傳遞簡單資料
标記耦合	一個資料結構的一部分借助于子產品接口被傳遞
控制耦合	子產品間傳遞的資訊中包含用于控制子產品内部邏輯的資訊
外部耦合	與軟體以外的環境有關
公共耦合	多和子產品引用同一個全局資料區
内容耦合	一個子產品通路另一個子產品的内部資料 一個子產品不通過正常入口轉到另一子產品内部 兩個子產品有一部分程式代碼重疊 一個子產品有多個入口

注：軟體文檔

轉件文檔可以分開發文檔、管理文檔和使用者文檔三大類。

名稱	具體内容
開發文檔	《功能要求》、《投标方案》、《需求分析》、《技術分析》、《系統分析》、《資料庫文檔》、《功能函數文檔》、《界面文檔》、《編譯手冊》、《QA文檔》、《項目總結》等
管理文檔	《産品簡介》、《産品示範》、《疑問解答》、《功能介紹》、《技術白皮書》、《評測報告》等
使用者文檔	《安裝手冊》、《使用手冊》、《維護手冊》、《使用者報告》、《銷售教育訓練》等