7.軟件工程

軟件生命周期

什么是軟件工程？以工程化的原則和方法來開發軟件，其目的是提高軟件生產率、提高軟件質量、降低軟件成本。

軟件工程3大組成部分：方法、工具、過程。

什么是軟件生命周期：經過開發、使用和維護，直到最后退役的全過程。

軟件生命周期的過程：

基本過程：主要參與方是發起或完成軟件產品開發、運行或維護的組織。基本過程分為獲取過程、供應過程、開發過程、運作過程和維護過程。
開發過程包括：需求分析、設計、編碼、集成、測試以及軟件產品相關的安裝和驗收等活動；維護過程包括軟件產品的遷移和退役。（軟件生存周期的過程）
支持過程：是一個有機組成部分支持其他過程，目的是軟件項目成功和提高質量。
支持過程包括：文檔預編譯過程、配置管理過程、質量保證過程、驗收過程、確認過程、聯合評審過程、審核過程、問題解決過程和易用性過程。（用于支持其他過程）
組織過程：組織過程可被某個組織用來建立和實現由相關的生產周期過程和人員組成的基礎結構，并不斷優化這種結構和過程。組織過程包括：管理過程、基礎設施過程、改進過程、人力資源過程、資產管理過程、重用大綱管理過程、領域工程過程。（和人、公司有關）

軟件生命周期各個階段的任務

都屬于基本過程，需求分析屬于開發過程。

獲取、供應過程：可行性研究（能不能做）
開發過程：需求分析（做什么）、【概要設計(模塊結構的設計)、詳細設計(模塊內部的設計、算法、數據結構等)】（怎么做？）、實現（做，編碼）、組裝測試(集成測試，不同模塊組裝成整體后開始測試)、確認測試(與用戶需求確認)。
運作過程：使用
維護過程：維護、退役。

各階段的產物：

?系統規劃階段?：
- 系統設計任務書、系統設計規格說明
?系統分析階段?：
- 系統方案建議書、需求規格說明（SRS）、確認測試計劃、系統測試計劃、初步的用戶手冊?6
?系統設計階段?：
- 程序規格說明、架構文檔、概要設計文檔、詳細設計文檔、概要測試計劃、詳細測試計劃?
?系統實施階段?：
- 軟件編碼、單元測試報告、集成測試報告、系統測試報告、操作手冊(測試完成)

習題

1、系統方案建議書是系統分析（需求分析）階段結束的產物
2、操作手冊是系統測試階段完成的產物

軟件過程管理?

能力成熟度模型?

CMM

能力成熟度模型CMM。衡量組織做軟件的能力。有4個等級

初始級：軟件過程雜亂無章，完全依賴個人努力和核心人物
可重復級：建立基本的項目管理過程和實踐，有必要的過程準則來重復，（重點在重復）
已定義級：軟件過程已經文檔化、標準化、并綜合成整個軟件開發組織的標準軟件過程。（重點在文檔化、標準化）
已管理級：指定了軟件過程和產品質量的詳細度量標準。（重點是詳細的度量標準）
優化級：可以不斷的持續改進。

CMMI

能力成熟度模型集成CMMI

是若干過程模型的綜合和改進，不僅僅是軟件，而是支持多個工程學科和領域的、系統的、一直的過程改進框架。，能適應現代工程的特點和需要，能提高過程質量和工作效率。

CMMI 的兩種表示方式：

階段式模型：類似CMM，他關注組織的成熟度，5個成熟度模型如下：
初始級：
已管理級
已定義級
定量管理
優先級
連續式模型：關注每個過程域的能力，過程域分類：
過程管理
項目管理
工程
支持

軟件過程評估

?軟件過程評估是根據過程模型或其他模型對組織的軟件過程進行規范的評估。

評估模型有：

CMM模型：幫助軟件組織通過基于模型的過程改進
Trililum模型：主要用于嵌入式軟件開發
bootstrap
iso

習題?

B，第1級最差

軟件過程模型

?也叫：軟件生命周期的典型模型。使用需求明確的開發。

瀑布模型

瀑布模型的特點：需要上一項完成才開始下一項，不能回去，逐漸被淘汰了。

上一項活動的產物作為該項活動的輸入
對該項活動的實施工作成功進行評審

原型模型

也叫“快速原型方法”

原型化模型的第一步是創建一個快速模型，滿足原型交互，通過分析，最終確認系統的需求，在原型的基礎上開發用戶滿意的產品。

原型化方法很難一下全面確認需求，所以他具備以下特點：

實際可行
具有最終系統的基本特征
構造方便、快速、造價低。
對用戶的需求是動態響應的，逐步納入的。

螺旋模型

螺旋模型是一個演化軟件過程模型，將原型實現的迭代特征和線性順序（瀑布）模型中控制的和系統化的方面結合起來，在螺旋模型中，軟件開發是一系列的增量發布

他的開發過程具有周期性重復的螺旋線狀。四個象限分別標志每個開發周期所劃分的4階段：制定計劃、風險分析、實施過程和用戶評估。

螺旋模型強調風險分析，特別適合龐大而復雜、高風險的系統。

V模型

V模型左邊代表開發過程：編碼、詳細設計、概要設計、需求分析
右邊代表測試過程：單元測試、集成測試、系統測試、驗收測試

V 模型的特點：生命周期和測試的對應

單編：單元測試的測試是在詳細設計完成
集詳
系概
驗需

V模型適合：需求明確且需求變更不頻繁。重測試。

增量模型

增量模型：首先開發核心模塊，與用戶確認后再開發次要模塊。優先級最高的服務最先交付。

特點：由于不是從系統整體角度劃分各個模塊，因此不利于模塊劃分。難點在于如何將客戶需求劃分為多個增量。與原型不同的是，增量模型每一次增量版本都可以作為獨立可操作的產品。而原型的構造一般是為了演示。?

后面的模型不太重要了

其他模型

噴泉模型：面向對象，以用戶需求為動力，以對象為驅動的模型

基于構件的開發模型CBSD：基于構件、逐漸，特點是增強了復用性。

習題

1、視頻

1、瀑布模型適合需求明確，且時間有嚴格要求。
原型模型適合需求不明確的快速開發
V模型適合需求明確且變更不頻繁的
螺旋模型適合復雜大型項目?強調風險分析。

2、螺旋模型適合大型復雜的軟件項目。

信息系統開發與方法

結構化方法

結構是指系統內各個組成要素（指模塊）之間的相互聯系、相互作用的框架。

結構化方法（生命周期法），是一種傳統的信息系統開發方法，組成部分：

結構化分析：系統分析階段
結構化設計：系統設計階段
結構化程序設計：系統實施階段

精髓是自頂向下，逐步求精的模塊化設計，面相數據流、面向過程。

結構化方法的主要特點：

開發目標清晰化：遵循“用戶第一”的原則
開發工作階段化：根據階段工作目標和要求進行審查，使各個階段有條不紊的進行，便于項目管理與控制。
開發文檔規范化：每個階段完整都需要有相應的文檔。
設計方法結構化：在系統分析和設計時，全局考慮，自頂向下的分解；在系統實現時，自底向上的逐步實現整個系統。

結構化方法的不足：

開發周期長
難以使用需求變化
很少考慮數據結構

結構化方法常用工具：一般采用圖形表達用戶需求，比如數據流圖、數據字典、結構化語言、判定表以及判定樹。

面相對象方法

面向對象方法：認為客觀世界由對象組成，任何事物都可以是對象，每個對象都有自己的運動規律和內部狀態，都屬于某個對象類，

面向對象方法特點：

使用OO方法構造的系統具有更好的復用性，建立全面合理、統一的模型（用例模型和分析模型）
OO也劃分階段，系統分析、系統設計和系統實現3個階段沒有縫隙，也就是界限變得不明確。不是一定要一項一項完成。
普遍使用各類信息系統的開發。

面向對象方法的不足：

1、必須依靠一定的面相對象技術支持，對大型項目有局限性，不能涉足系統分析之前的開發環節

2、大型信息系統的開發，通常是將結構化方法和OO方法結合，自底向上的時候采用OO。因此結構化方法和OO是相互依存、不可替代的。

原型化方法

原型化方法也稱為：快速原型化、原型化。

根據用戶初步需求，快速建立一個系統模型展示給用戶，不斷改進。

原型化方法分類：

按是否實現功能分類：水平原型（行為原型，功能的導航）、垂直原型（結構化原型，實現了部分功能）
按最終結果分類：拋棄式原型、演示化原型。

原型化的特點：

使系統開發周期縮短、成本和風險降低、速度加快、獲得較高的綜合開發收益。

原型化是以用戶為中心來開發系統，對系統的功能和結構容易理解和接受，有利于系統移交。

原型化不足：

開發環境和管理水平要求較高。

原型化優點：

有效的確認用戶需求，適用需求不明確的系統開發；適用分析層面難度大，技術層面難度不大的系統。
目前原型化方法不是一種獨立的系統開發方法，而只是一種開發思想，不是完整意義上的方法論體系，必須與西塔的信息系統開發方法結合使用

面相服務的開發-SO

面向服務：基本單位是服務，

OO形成了構件的概念，跨構件的功能調用會采用接口的形式暴露，進一步將接口的定義和實現進行解耦，則出現了面向服務SO。面向對象、基于構件、面向服務是3個遞進的抽象層次。

SO3個主要抽象級別：操作、服務、業務流程。

SO介紹：

最底層的操作代表單個邏輯單元的事務。服務的操作類似于對象的方法
位于第二層的服務代表操作的邏輯分組
最高層的業務流程則是為了實現特定業務目標而執行的一組長期運行的動作或活動。

快速應用開發-RAD

采用基于構件的開發方法快速開發。復用性強。是瀑布模型的一個高速變種。

RAD的4個基本思想：

讓用戶更主動參與系統分析、設計和構造中來。
將項目開發組織成一系列重點突出的研討會。
通過一種迭代的構造方法，加速需求分析和設計階段。
讓用戶提前看到一個可工作的系統

RAD的開發階段：

業務建模
數據建模
過程建模
應用生成
測試和交付

RAD的局限性：

并非所有應用都適合RAD
開發者和客戶必須在很短時間完成一系列的需求分析。
RAD只能用于管理信息系統的開發，不適合技術風險很高的項目。

敏捷開發模型

介紹

開發宣言：個體和交互勝過過程和工具，可以工作的軟件勝過面面俱到的文檔、客戶合作勝過合同談判、響應變化勝過遵循計劃。?

特點：

適應性，而非預設性的
面向人的，而非面向過程的

核心思想：

適應性
以人為本
迭代增量式。

主要的敏捷方法

1、極限編程-XP

XP 的基礎和價值觀是交流、樸素、反饋和勇氣。即任何一個軟件項目都可以從4個方面入手：加強交流、從簡單做起、尋求反饋、實事求是。

XP是一個近螺旋的開發方法，將復雜開發分解為簡單的小周期，提倡測試先行。

XP最大的不同：

在更短的周期內，更早的提出具體且持續的反饋信息。
迭代的進行計劃編制
依賴自動測試程序來監控開發進度，盡早捕獲缺陷
依賴口頭交流、測試和源程序進行溝通
提倡持續的演化式的設計
依賴開發團隊內部的緊密協作。
盡可能程序員短期利益和項目長期利益的平衡。?

2、動態系統開發方法-DSDM

動態系統開發方法倡導以業務為核心，快速進行系統開發，DSDM認為事情不可能一次圓滿完成，應該用20%的時間完成80%的有用功能，以適合商業目的為準。

3、并列爭球法-Scrum

Scrum的整個開發過程有若干個短的迭代周期組成，一個短的迭代周期稱為Sprint，每個Sprint的建議長度為2-4周，按需求優先級實現產品，多個自組織和自治的小組并行的遞增實現產品。

統一過程模型

敏捷是輕量級，統一過程模型是重量級的。

RUP 描述了如何有效利用商業的，可靠的方法開發和部署軟件，是重量級的過程。

RUP 是一個二維的軟件開發模型，有9個核心工作流：

業務建模：理解待開發系統所在機構及其商業運作，確保所有參與人員對待開發系統所在機構有共同的認識，評估待開發系統對所在機構的影響。
需求：定義系統功能以及用戶界面，使客戶、開發人員理解系統需求功能，為項目預算和計劃提供基礎。
分析與設計：把需求分析的結果轉化為分析和設計模型。
實現：把設計模型轉為實現結果，對開發的代碼進行單元測試，將不同模塊集成為可執行的系統。
測試：測試驗證，對缺陷進行歸檔，對軟件質量提出改進意見。
部署：打包、分發、培訓用戶以及銷售人員、技術支持。
配置與變更管理：跟蹤并維護系統開發過程中產生的所有產品的完整性和一致性。
項目管理：為軟件開發提供計劃、人員分配、執行、監控等方面的知道，進行風險管理。
環境：提供軟件環境，即提供過程管理和工具的支持。

rup生命周期的4個階段：每個循環生成產品的一個新版本，每個循環一次由4個連續階段組成。

初始，與需求有關。任務是為系統建立業務模型并確定項目的邊界。關注的事整個項目的業務和需求方面的主要風險，實現過程為：明確項目規模、評估項目風險、制定項目計劃、階段技術評審。
細化，與設計有關。任務是分析問題領域、建立完善的架構、淘汰項目中最高風險的元素。實現過程是：確定架構、制定構建階段計劃、建立支持環境、選擇構建、階段技術評審。
構建，與實現有關。開發所有剩余的構建和應用程序功能，把這些構建集成為產品，并進行詳細測試。完成所需功能的分析、開發、測試等。
移交，與實施交付有關。進行β測試測試，制作產品發布版本；對最終用戶支持文檔定稿；按用戶的需求確認新系統；培訓用戶和維護人員。

β測試是在用戶在實際使用下進行的測試，是完全真實的測試，軟件要交付必須進行這個測試

RUP的特點：

用例驅動：用例指功能
體系結構為中心
4+1視圖模型：
分析人員和測試人員：關心系統行為。看用例視圖
最終用戶關系系統的功能。看邏輯視圖
程序員關心系統的配置、裝配。看實體視圖
系統集成人員（項目經理）關心系統的性能、可擴展性。看進程視圖
系統工程師（運維）關心系統的發布、安裝等問題。看部署視圖
迭代與增量