這門課非常重要，很多人說這門課是計算機課程裏面的馬克思課，其實不然，這麼課真的非常重要，學好了，受益終身！我終於深刻的體會了這一點！

第一章軟件工程學概述

迄今爲止，計算機系統已經經歷了4個不同的發展階段(主要元器件分別是：電子管；晶體管；中、小規模集成電路；大規模、超大規模集成電路)，但是，人們仍然沒有徹底擺脫“軟件危機”的困擾，軟件已經成爲限制計算機系統發展的瓶頸。

爲了更有效地開發與維護軟件，軟件工作者在20世紀60年代後期開始認真研究消除軟件危機的途徑，從而逐漸形成了一門新興的工程學科——計算機軟件工程學（簡稱爲軟件工程）。

1.1 軟件危機

1.1.1 軟件危機的介紹

軟件危機是指：在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。

軟件危機包含下述兩方面問題：
（1）如何開發軟件，以滿足對軟件日益增長的需求；
（2）如何維護數量不斷膨脹的已有軟件。

軟件危機的典型表現：
1、對軟件開發成本和進度的估計常常很不準確
2、用戶對“已完成的”軟件系統不滿意的現象經常發生
3、軟件產品的質量往往靠不住。
4、軟件常常是不可維護的。
5、軟件通常沒有適當的文檔資料。
6、軟件成本在計算機系統總成本中所佔的比例逐年上升。美國1985年，軟件成本約佔90%。
7、軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。

1.1.2 產生軟件危機的原因

與軟件本身的特點有關係：

軟件不同於硬件，軟件缺乏可見性，管理和控制軟件開發過程相當困難。
軟件在運行過程中不會因爲使用時間過長而被 “用壞 “如果運行中發現了錯誤,很可能是遇到了一個在開發時期引入的在測試階段沒能檢測出來的錯誤。
軟件不同於一般程序，它的一個顯著特點是規模龐大，而且程序複雜性將隨着程序規模的增加而呈指數上升。
目前相當多的軟件專業人員對軟件開發和維護還有不少糊塗觀念。在實踐過程中或多或少地採用了錯誤的方法和技術，這可能是使軟件問題發展成軟件危機的主要原因。
錯誤的認識和做法主要表現爲忽視軟件需求分析的重要性，認爲軟件開發就是寫程序並設法使之運行,輕視軟件維護等
事實上，對用戶要求沒有完整準確的認識就匆忙着手編寫程序是許多軟件開發工程失敗的主要原因之一。

軟件開發與維護的方法不正確有關：

只重視程序而忽視軟件配置其餘成分的糊塗觀念。
軟件開發人員在定義時期沒有正確全面地理解用戶需求，直到測試階段或軟件交付使用後才發現 “已完成的 ”軟件不完全符合用戶的需要。
嚴重的問題是在軟件開發的不同階段進行修改需要付出的代價是很不相同的。

在軟件開發的不同階段進行修改需要付出的代價：

1.1.3 消除軟件危機的途徑

首先應該對計算機軟件有一個正確的認識。事實上，軟件是程序、數據及相關文檔的完整集合。
充分認識到軟件開發不是某種個體勞動的神祕技巧，而應該是各類人員協同配合，共同完成的工程項目。
推廣使用在實踐中總結出來的開發軟件的成功的技術和方法，並且研究探索更好更有效的技術和方法。
應該開發和使用更好的軟件工具。

總之，從管理和技術兩方面研究解決軟件危機。

1.2 軟件工程

1.2.1 軟件工程的介紹

軟件工程概述
軟件工程是指導計算機軟件開發和維護的一門工程學科。採用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件並有效地維護它，這就是軟件工程。

軟件工程的兩個典型定義：

1968年在第一屆NATO會議上曾經給出了軟件工程的一個早期定義：
“軟件工程就是爲了經濟地獲得可靠的且能在實際機器上有效地運行的軟件，而建立和使用完善的工程原理。”
1993年IEEE進一步給出了一個更全面更具體的定義：“軟件工程是：
①把系統的、規範的、可度量的途徑應用於軟件開發、運行和維護過程，也就是把工程應用於軟件；
②研究①中提到的途徑。

軟件工程具有的本質特徵：

軟件工程關注於大型程序的構造
通常把一個人在較短時間內寫出的程序稱爲小型程序。
把多人合作用時半年以上才寫的程序稱爲大型程序。
軟件工程的中心課題是控制複雜性
不能把問題作爲整體通盤考慮，人們不得不把問題分解，使得分解出的每個部分是可理解的，而且各部分之間保持簡單的通信關係。
軟件經常變化
現實世界不斷變化，軟件爲了不被淘汰，必須隨着所模擬的現實世界一起變化。
開發軟件的效率非常重要
和諧地合作是開發軟件的關鍵
軟件必須有效地支持它的用戶
必須仔細的研究用戶，適當地培訓用戶。
在軟件工程領域中通常有具有一種文化背景的人替具有另一種文化背景的人創造產品
軟件工程師+領域專家

1.2.2 軟件工程的基本原理

1、用分階段的生命週期計劃嚴格管理
2、堅持進行階段評審
3、實行嚴格的產品控制
一切有關修改軟件的建議，特別是涉及對基準配置的修改建議，都必須按照嚴格的規程進行評審，獲得批准以後才能實施修改。絕對不能隨意修改。
4、採用現代程序設計技術
5、結果應能清楚地審查
6、開發小組的人員應該少而精
7、承認不斷改進軟件工程實踐的必要性

1.2.3 軟件工程方法學

軟件工程方法學包含3個要素：方法、工具和過程。

方法：完成軟件開發的各項任務的技術方法，回答“怎樣做”的問題
工具：爲運用方法而提供的自動的或半自動的軟件工程支撐環境
過程：爲了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟

目前，軟件工程方法學主要分爲以下兩類：

傳統方法學

概念：傳統方法學也稱爲生命週期方法學或結構化範型。
它採用結構化技術(結構化分析、結構化設計和結構化實現)來完成軟件開發的各項任務，並使用適當的軟件工具或軟件工程環境來支持結構化技術的運用。

傳統方法學的特點：
(1)傳統方法學把軟件生命週期的全過程依次劃分爲若干個階段，然後順序地完成每個階段的任務。
(2)每個階段的開始和結束都有嚴格標準，對於任何兩個相鄰的階段而言，前一階段的結束標準就是後一階段的開始標準。
(3)在每一個階段結束之前都必須進行正式嚴格的技術審查和管理複審。
審查的一條主要標準就是每個階段都應該交出“最新式的”(即和所開發的軟件完全一致的)高質量的文檔資料，從而保證在軟件開發工程結束時有一個完整準確的軟件配置交付使用。
面向對象方法學：

概念：
面向對象方法把數據和行爲看成是同等重要的，它是一種以數據爲主線，把數據和對數據的操作緊密地結合起來的方法。

面向對象方法學具有下述四個要點：
① 把對象(object)作爲融合了數據及在數據上的操作行爲的統一的軟件構件。
② 把所有對象都劃分成類(class)。
③ 按照父類與子類的關係，把若干個相關類組成一個層次結構的系統。（繼承性）
④ 對象彼此間僅能通過發送消息互相聯繫。(封裝性)

面向對象方法學基本原則：
儘量模擬人類習慣的思維方式，使開發軟件的方法與過程儘可能接近人類認識世界、解決問題的方法與過程，從而使描述問題的問題空間(也稱爲問題域)與實現解法的解空間(也稱爲求解域)在結構上儘可能一致。

面向對象方法學優點：
降低了軟件產品的複雜性，提高了軟件的可理解性，簡化了軟件的開發和維護工作。
面向對象方法特有的繼承性和多態性，進一步提高了面向對象軟件的可重用性。

1.3 軟件生命週期

軟件生命週期每個階段的基本任務：

問題定義
① 回答“要解決的問題是什麼？”
② 通過對客戶訪問調查，系統分析員扼要地寫出關於問題性質、工程目標和工程規模的書面報告。
可行性研究
① 回答“對於上一階段所確定的問題有行得通的解決辦法嗎？”；
② 探索這個問題是否值得去解，是否有可行的解決辦法；
③ 及時終止不值得投資的工程項目，可以避免更大的浪費。
需求分析
① 回答“爲了解決這個問題，目標系統必須做什麼？”；
② 主要是確定目標系統必須具備哪些功能；
③ 必須準確完整地體現用戶的要求。
概要設計
① 回答“概括地說，應該怎樣實現目標系統？”，又稱概要設計；
② 設計出實現目標系統的幾種可能的方案；
③ 推薦一個最佳方案，制定出實現最佳方案的詳細計劃；
④ 確定程序由哪些模塊組成以及模塊間的關係。
詳細設計
① 回答“應該怎樣具體地實現這個系統呢？”；
② 又稱模塊設計，詳細地設計每個模塊，確定實現模塊功能所需要的算法和數據結構。
編碼與單元測試
① 關鍵任務：寫出正確的容易理解、容易維護的程序模塊；
② 選取一種適當的高級程序設計語言，把詳細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。
綜合測試
① 關鍵任務：通過各種類型的測試使軟件達到預定的要求；
② 集成測試、驗收測試、現場測試、平行運行等測試方法
運行維護
① 關鍵任務：通過各種必要的維護活動，使系統持久地滿足用戶的需要；
② 改正性維護、適應性維護、完善性維護、預防性維護

在實際從事軟件開發工作時，軟件規模、種類、開發環境及開發時使用的技術方法等因素，都影響階段的劃分。

1.4 軟件過程

軟件過程是爲了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

軟件過程描述爲了開發出客戶需要的軟件，什麼人（who）、在什麼時候（when）、做什麼事（what）以及怎樣（how）做這些事以實現某一個特定的具體目標。

軟件過程是爲了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

1.4.1 瀑布模型

瀑布模型一直是唯一被廣泛採用的生命週期模型，現在它仍然是軟件工程中應用得最廣泛的過程模型。

按照傳統的瀑布模型開發軟件，有下述的幾個特點。

階段間具有順序性和依賴性
兩重含義：
①必須等前一階段的工作完成之後，才能開始後一階段的工作；
②前一階段的輸出文檔就是後一階段的輸入文檔，因此，只有前一階段的輸出文檔正確，後一階段的工作才能獲得正確的結果。
推遲實現的觀點
瀑布模型在編碼之前設置了系統分析與系統設計的各個階段，分析與設計階段的基本任務規定，在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現。
質量保證的觀點
軟件工程的基本目標是優質、高產。
爲了保證所開發的軟件的質量，在瀑布模型的每個階段都應堅持兩個重要做法。
① 每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。
② 每個階段結束前都要對所完成的文檔進行評審，以便儘早發現問題，改正錯誤。

傳統的瀑布模型過於理想化了，事實上，人在工作過程中不可能不犯錯誤。
實際的瀑布模型是帶“反饋環”的：

瀑布模型有許多優點：
① 可強迫開發人員採用規範的方法（例如，結構化技術）；
② 嚴格地規定了每個階段必須提交的文檔；
③ 要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。
缺點： 由文檔驅動的

1.4.2 快速原型模型

概念：
快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集。

快速原型模型是不帶反饋環的，這正是這種過程模型的主要優點：軟件產品的開發基本上是線性順序進行的。
快速原型的本質是“快速”。開發人員應該儘可能快地建造出原型系統，以加速軟件開發過程，節約軟件開發成本。

能基本上做到線性順序開發的主要原因如下：
（1）原型系統已經通過與用戶交互而得到驗證
據此產生的規格說明文檔正確地描述了用戶需求，因此，在開發過程的後續階段不會因爲發現了規格說明文檔的錯誤而進行較大的返工。
（2）開發人員通過建立原型系統已經學到了許多東西，因此，在設計和編碼階段發生錯誤的可能性也比較小，這自然減少了在後續階段需要改正前面階段所犯錯誤的可能性。

1.4.3 增量模型

概念：
增量模型也稱爲漸增模型。
使用增量模型開發軟件時，把軟件產品作爲一系列的增量構件來設計、編碼、集成和測試。
每個構件由多個相互作用的模塊構成，並且能夠完成特定的功能。使用增量模型時，第一個增量構件往往實現軟件的基本需求，提供最核心的功能。

使用增量模型的優點：
能在較短時間內向用戶提交可完成部分工作的產品。
逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的衝擊。
使用增量模型的困難：
在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。
必須把軟件的體系結構設計得便於按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。

還有一種風險更大的增量模型：構件可能無法集成到一起。

1.4.4 螺旋模型

概念：
螺旋模型的基本思想：使用原型及其他方法來儘量降低風險。
理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風險分析過程的快速原型模型。

1.4.5 噴泉模型

概念：
“噴泉”這個詞體現了面向對象軟件開發過程迭代和無縫的特性。
迭代是軟件開發過程中普遍存在的一種內在屬性。用面向對象方法學開發軟件時，工作重點應該放在生命週期中的分析階段。

1.4.6 Rational統一過程

概念：

Rational統一過程（Rational Unified Process,RUP）是由Rational軟件公司推出的一種完整而且完美的軟件過程。
RUP總結了經過多年商業化驗證的6條最有效的軟件開發經驗，這些經驗被稱爲“最佳實踐”。

最佳實踐

① 迭代式開發
迭代式開發允許在每次迭代過程中需求都可以有變化，這種開發方法通過一系列細化來加深對問題的理解，因此能更容易地容納需求的變更。
② 管理需求
RUP描述瞭如何提取、組織系統的功能性需求和約束條件並把它們文檔化。
③ 使用基於構件的體系結構
RUP提供了使用現有的或新開發的構件定義體系結構的系統化方法，從而有助於降低軟件開發的複雜性，提高軟件重用率。
④ 可視化建模
可視化建模語言UML緊密地聯繫在一起，在開發過程中建立起軟件系統的可視化模型，可以幫助人們提高管理軟件複雜性的能力。
⑤ 驗證軟件質量
軟件質量評估不再是事後型的或由單獨小組進行的孤立活動，而是內建在貫穿於整個開發過程的、由全體成員參與的所有活動中。
⑥ 控制軟件變更
RUP描述瞭如何控制、跟蹤和監控修改，以確保迭代開發的成功。

RUP軟件開發生命週期

RUP軟件開發生命週期是一個二維的生命週期模型。

(1)核心工作流

RUP中有9個核心工作流，其中前6個爲核心過程工作流程，後3個爲核心支持工作流程。

6個核心過程工作流

業務建模：深入瞭解使用目標系統的機構及其商業動作
需求：捕獲客戶需求，使開發人員與用戶達成需求共識
分析與設計：把需求分析的結果轉化成分析模型與設計模型
實現：把設計模型轉換成實現結果
測試：識別、確認缺陷並確保在軟件部署前消除缺陷
部署：生成可運行版本，把軟件移交給最終用戶

3個核心支持工作流

配置與變更管理：跟蹤並維護在軟件開發過程中產生的所有制品的完整性和一致性
項目管理：提供項目管理框架，爲軟件開發項目制定計劃、人員配備、執行和監控等方面的實用準則
環境：向軟件開發機構提供軟件開發環境，包括過程管理和工具支持

(2)工作階段

RUP把軟件生命週期劃分成4個連續的階段。
每個階段都有明確的目標，並且定義了用來評估是否達到這些目標的里程碑。
每個階段的目標通過一次或多次迭代來完成。

初始階段：建立業務模型，定義最終產品視圖，並且確定項目的範圍。
精化階段：設計並確定系統的體系結構，制定項目計劃，確定資源需求。
構建階段：開發出所有構件和應用程序，把它們集成爲客戶需要的產品，並且詳盡地測試所有功能。
移交階段：把開發出的產品提交給用戶使用。

(3)RUP迭代式開發

RUP強調採用迭代和漸增的方式來開發軟件。
RUP重複一系列組成軟件生命週期的循環。
每次循環都經歷一個完整的生命週期，每次循環結束都向用戶交付產品的一個可運行的版本。
每個階段又進一步細分爲一次或多次迭代過程。

1.4.7 敏捷過程與極限編程

敏捷過程

概念：
敏捷過程：爲了使軟件開發團隊具有高效工作和快速響應變化的能力，17位著名的軟件專家於2001年2月聯合起草了敏捷軟件開發宣言。

敏捷軟件開發宣言由下述4個簡單的價值觀聲明組成。

個體和交互勝過過程和工具
可以工作的軟件勝過面面俱到的文檔
客戶合作勝過合同談判
響應變化勝過遵循計劃

極限編程

極限編程：
極限編程（eXtreme Programming,XP）是敏捷過程中最富盛名的一個，其名稱中“極限”二字的含義是指把好的開發實踐運用到極致。
目前，極限編程已經成爲一種典型的開發方法，廣泛應用於需求模糊且經常改變的場合。

極限項目的整體開發過程：

極限編程的迭代過程：
首先，項目組針對客戶代表提出的“用戶故事” 進行討論，提出隱喻，在此項活動中可能需要對體系結構進行“試探”
然後，項目組在隱喻和用戶故事的基礎上，根據客戶設定的優先級制訂交付計劃。
接下來開始多個迭代過程，在迭代期內產生的新用戶故事不在本次迭代內解決，以保證本次開發過程不受干擾。開發出的新版本軟件通過驗收測試之後交付用戶使用。

1.4.8 微軟過程

微軟過程準則：

項目計劃應該兼顧未來的不確定因素。
用有效的風險管理來減少不確定因素的影響。
經常生成並快速地測試軟件的過渡版本，從而提高產品的穩定性和可預測性。
採用快速循環、遞進的開發過程。
用創造性的工作來平衡產品特性和產品成本。
項目進度表應該具有較高穩定性和權威性。
使用小型項目組併發地完成開發工作。
在項目早期把軟件配置項基線化，項目後期則凍結產品。
使用原型驗證概念，對項目進行早期論證。
把零缺陷作爲追求的目標。
里程碑評審會的目的是改進工作，切忌相互指責。

微軟軟件生命週期：

規劃階段 - 設計階段 - 開發階段 - 穩定階段 - 發佈階段

微軟軟件生命週期階段劃分和主要里程碑

微軟過程模型：

微軟過程的每一個生命週期發佈一個遞進的軟件版本，各個生命週期持續、快速地迭代循環。

微軟過程的生命週期模型：

1.5 本章小結

本章對計算機軟件工程學作一個簡短的概述，回顧計算機系統發展簡史。
本章介紹軟件工程的基本原理和方法有概括的本質的認識，詳細講解生命週期相關知識。
詳細講解8種典型的軟件過程模型。

作業

軟件危機的定義？
產生軟件危機的原因。
什麼是軟件工程。
軟件工程基本原理
軟件工程方法學的三要素
軟件生命週期：三個時期八個任務
軟件過程的定義及模型（至少前5個）

《軟件工程導論》第一章-軟件工程學概述-重點總結

第一章 軟件工程學概述