軟件：
定義
經過嚴格測試和試用的具有相對穩定的文本和完整的文檔的程序
Wirth： 程序=算法+數據結構 軟件=程序+文檔
分類
- 根據軟件服務對象的范圍不同： 通用軟件（操作系統、數據庫等） 定制軟件（企業ERP、衛星控制系統等）
- 根據軟件完成功能所處的層次不同： 系統軟件 中間件軟件 應用軟件
- 按軟件工作方式不同（結合操作系統發展記憶）： 實時處理軟件 分時軟件 交互式軟件 批處理軟件
- 按照支撐應用開發的工具類型可以將其劃分為 ： 支持軟件開發過程的工具 支持軟件維護過程的工具 支持軟件管理過程和支持過程的工具
發展階段
軟件危機
大量錯誤、可靠性和可用性差
無法新增功能、難以維護
無法按時完成，嚴重的徹底失敗
體現
所謂軟件危機（Software Crisis）就是計算機軟件在開發和維護過程中所遇到的一系列嚴重問題，具體表現在：
軟件開發成本難以估算，無法制定合理的開發計劃；
用戶的需求無法確切表達； 軟件質量存在問題；
軟件的可維護性差；
缺乏文檔資料；
軟件成本難以控制；
原因
軟件系統本身的復雜性；
軟件開發的方法和技術不合理；
軟件開發過程
要做什麼：需求分析人員
怎麼做：系統設計人員
具體做：系統開發開發人員
做的對不對：測試人員
讓用戶用：工程實施人員
維護系統：系統維護人員
軟件工程
定義
Fritz Bauer首次提出瞭“軟件工程”的概念：軟件工程是為瞭經濟地獲得能夠在實際機器上高效運行的可靠軟件而建立和使用的一系列好的工程化原則。
Boehm為軟件工程下的定義：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序提供所必需的相關文件資料。
Fairley認為：軟件工程學是為在成本限額以內按時完成開發和修改軟件產品所需的系統生產和維護的技術和管理的學科。
IEEE計算機學會將“軟件工程”定義為：應用系統化的、規范化的、定量的方法來開發、運行和維護軟件，即：將工程應用到軟件。
總結：
1）工程概念在軟件領域裡的一個特定應用
2）軟件工程涉及軟件產品的所有環節
軟件工程三要素
方法、工具和過程
軟件工程目標和原則
目標： 生產具有正確性、可用性以及開銷適宜的軟件產品。
堅持四項基本原則：
選取適宜的開發模型；
采用合適的設計方法 ；
提供高質量的工程支持 ；
重視開發過程的管理 ；
軟件工程基本原理
八條一般原理： （1）抽象 （2）信息隱藏 （3）模塊化 （4）局部化 （5）確定性 （6）一致性 （7）完備性 （8）可驗證性
七條基本原理： （1）用分階段的生命周期計劃嚴格管理 （2）堅持進行階段評審 （3）實行嚴格的產品控制 （4）采用現代程序設計技術 （5）結果應能清楚地審查 （6）開發小組的人員應少而精 （7）承認不斷改進軟件工程實踐的必要性
軟件工程過程和生命周期
過程：
軟件規格說明、軟件開發、軟件確認、軟件演進
生命周期：
制定計劃、需求分析 、設計 、程序編碼 、測試 、運行維護
傳統軟件生命周期模型
瀑佈模型
特征： 本活動的工作對象來自於上一項活動的輸出，這些輸出一般是代表本階段活動結束的裡程碑式的文檔。 根據本階段的活動規程執行相應的任務。 產生本階段活動相關產出——軟件工件，作為下一活動的輸入。 對本階段活動執行情況進行評審。
優缺點：
V模型和W模型
V模型
瀑佈模型將測試作為軟件實現之後的一個獨立階段，使得在分析和設計階段潛伏下來的錯誤得到糾正的時機大為推遲，造成較大的返工成本；而且體系結構級別的缺陷也隻能在測試階段才能被發現，使得瀑佈模型駕馭風險的能力較低。 瀑佈模型將測試階段獨立於編碼之後，給人們造成瞭一種不良的影響，即：相對於編碼而言，分析與設計工作更重要，而並沒有強調測試的重要性，盡管測試有時會占據項目周期的一半時間。 V模型的價值在於糾正瞭人們這種錯誤的認識，將測試分等級，並和前面的開發階段對應起來。
W模型
W模型由兩個V型模型組成，分別代表測試與開發過程。 V模型雖然強調瞭測試階段的重要性（對測試進行分級，並和開發階段相對應），但它卻繼承瞭瀑佈模型的缺點，即將測試作為一個獨立的階段，所以並沒有提高模型抵抗風險的能力。 為瞭盡早發現分析與設計的缺陷，必須將測試廣義化，即擴充確認（validation）和驗證（verification）內容，並將廣義的測試作為一個過程貫穿整個軟件生命周期。基於這個出發點，Evolutif公司在V模型的基礎上提出瞭W模型。 W模型也存在局限性，它並沒有改變瀑佈模型中需求、設計和編碼等活動的串行關系，同時測試和開發活動也保持著一種線性的前後關系，上一階段完全結束，才可正式開始下一個階段的工作，因此，W模型仍然隻適合於需求比較穩定的軟件項目。
原型方法
產生原因：瀑佈，v，w都將軟件生命周期劃分為串行階段，前一個階段完成才能開始後一個階段。但是完整而準確的需求規格說明很難得到。
原型指模擬某種最終產品的原始模型；
原型方法指在獲得一組基本需求後，通過快速分析構造出一個小型的軟件系統原型，滿足用戶的基本要求。
特點：
1. 從認知論的角度看，原型方法遵循瞭人們認識事物的規律，因而更容易為人們所普遍接受。
2. 原型方法將模擬的手段引入分析的初期階段，溝通瞭人們的思想，縮短瞭用戶和開發人員之間的距離。
適用范圍和局限性：
1. 對於一個大型系統，如果不經過系統分析得到系統的整體劃分，而直接用原型來模擬是很困難的。
2. 對於大量運算的、邏輯性較強的程序模塊，原型方法很難構造出該模塊的原型來供人評價。
3. 對於原有應用的業務流程、信息流程混亂的情況，原型構造與使用有一定的困難。
4. 對於一個批處理系統，由於大部分活動是內部處理的，因此應用原型方法會有一定的困難。
選擇因素：
演化模型
由於需求很難調研充分，所以很難一次就開發成功。 演化模型提倡兩次開發。 第一次是試驗開發，得到試驗性的原型產品，其目標隻是在於探索可行性，弄清軟件需求； 第二次在此基礎上獲得較為滿意的軟件產品。
適用范圍： 需求不清楚； 小型或中小型系統； 開發周期短
增量模型
Mills等人於1980年提出 ，指首先對系統最核心或最清晰的需求進行分析、設計、實現、測試並集成到系統中。再按優先級逐步對後續的需求進行上述工作，逐步建設成一個完整系統的開發方法。
增量模型結合瞭瀑佈模型和演化模型的優點。它可以讓客戶得到一些機會延遲對詳細需求的決策，即客戶的需求可以逐步提出來；另外每一次“增量”需求的劃分與“增量”實現的集成是以不影響系統體系結構為前提的。
舉例： 使用增量模型開發文字處理軟件時，可以按照以下優先級進行增量開發：
1. 第一個增量實現基本的文件管理、編輯和文檔生成功能；
2. 第二個增量實現更加完善的編輯和文檔生成功能；
3. 第三個增量實現拼寫和文法檢查功能；
4. 第四個增量完成高級的頁面佈局功能。
增量模型的優點：
有利於增加客戶對系統的信心
降低系統失敗風險 提高系統可靠性
提高瞭系統的穩定性和可維護性
增量模型的缺點：
增量粒度難以選擇
確定所有的基本業務服務比較困難
螺旋模型
主要針對大型項目的開發： （1）需求功能復雜，無法一開始就明確；開發周期長，中途需求經常變化； （2）往往存在諸多風險因素，在不同程度上損害軟件開發過程和軟件產品的質量，所以必須對風險進行管理。
螺旋模型最大特點就是引入瞭明確的風險管理
- 制定計劃：確定軟件項目目標；明確對軟件開發過程和軟件產品的約束；制定詳細的項目管理計劃；根據當前的需求和風險因素，制定實施方案，並進行可行性分析，選定一個實施方案，並對其進行規劃。
- 風險分析：明確每一個項目風險，估計風險發生的可能性、頻率、損害程度，並制定風險管理措施規避這些風險。
- 實施工程：針對每一個開發階段的任務要求執行本開發階段的活動。
- 客戶評估：客戶使用原型，反饋修改意見；根據客戶的反饋，對產品及其開發過程進行評審，決定是否進入螺旋線的下一個回路。
噴泉模型
噴泉模型也稱迭代模型，認為軟件開發過程的各個階段是相互重疊和多次反復的，就象噴泉一樣，水噴上去又可以落下來，既可以落在中間，又可以落到底部。
各個開發階段沒有特定的次序要求，完全可以並行進行，可以在某個開發階段中隨時補充其他任何開發階段中遺漏的需求。
優點： 提高開發效率 縮短開發周期
缺點：難於管理
特點： 迭代性、無間隙性 噴泉模型是以對象驅動的模型，主要用於描述面向對象的軟件開發過程。
開發人員可以針對不同的對象集合並行進行開發，即存在多個子開發流程，這些子開發流程在對象集成時同步。其優點是可以提高軟件項目開發效率，節省開發時間。但是，由於各個開發階段的重疊性，開發人員的管理和階段生成的工件管理存在困難，因此，在應用噴泉模型時需要結合其他模型，比如結合增量模型在增量管理方面的優點，合理地劃分並發任務，控制開發人員的調度；結合瀑佈模型在文檔控制方面的優點，嚴格控制每一個迭代周期應該產生的文檔，並進行評審，對於在本周期沒有完成的任務，不應該象瀑佈模型那樣不允許進入下一階段，而是納入下一次迭代周期。
構件組裝模型
構件組裝模型利用==模塊化思想==將整個系統模塊化，並在一定構件模型的支持下復用構件庫中的一個或多個軟件構件，通過組裝高效率、高質量地構造軟件系統。構件組裝模型本質上是演化的，開發過程是迭代的 。
構件組裝模型的開發過程就是構件組裝的過程，維護的過程就是構件升級、替換和擴充的過程。
優點：
充分利用軟件復用，提高瞭軟件開發的效率。
允許多個項目同時開發，降低瞭費用，提高瞭可維護性，
可實現分步提交軟件產品。
缺點：
缺乏通用的構件組裝結構標準，風險較大；
構件可重用性和系統高效性之間不易協調；
由於過分依賴於構件，構件質量影響著最終產品的質量。
快速應用開發模型
快速應用開發（Rapid Application Development，RAD）是一個增量型的軟件開發過程模型，強調極短的開發周期。
RAD模型使用構件組裝方法進行快速開發。如果需求理解得很好且約束瞭項目范圍，RAD過程使得一個開發隊伍能夠在很短時間內（如60到90天）創建出系統。 RAD采用第四代語言技術快速生成應用
⑴ 業務建模：通過捕獲業務過程中信息流的流動及處理情況描述業務處理系統應該完成的功能，主要回答下列問題：什麼信息驅動業務流程？生成什麼信息？誰生成該信息？該信息流往何處？誰處理它？
⑵ 數據建模：對業務建模階段中部分定義的信息流進行細化，形成一組支持該業務處理功能所需的數據對象。標識出每個數據對象的特征，並定義這些數據對象之間的關系。
⑶ 過程建模：數據建模階段定義的數據對象被變換以實現完成一個業務功能所需的信息流，過程建模則對業務建模中的業務處理功能進行詳細定義，這些業務處理功能的操作對象就是數據建模階段形成的數據對象。
⑷ 應用生成：RAD利用第四代語言技術（4GL），復用已有的程序構件或是創建新的可復用構件，在自動化工具輔助下，完成軟件的構件組裝或者軟件的自動生成，從而快速構造軟件系統。
⑸ 測試及迭代：RAD模型強調復用，許多程序構件已經是測試過的，這減少瞭軟件系統測試的時間，但新構件必須測試，所有構件間的接口也必須完全測試到。當一輪需求完成快速開發後，可以迭代進入下一輪需求的開發。
缺點： 並非所有應用都適合采用RAD，如果一個應用不能被模塊化，那麼構造應用的構件就無法快速獲取。 由於時間約束，開發人員和客戶必須在較短的時間內完成一系列的需求分析，溝通配合不當都會導致應用RAD模型的失敗。 RAD適合於管理信息系統的開發，對於其他類型的應用系統，如技術風險較高、與外圍系統的互操作性較高等，不太合適。
新型軟件生命周期模型
RUP
RUP統一過程模型是一個面向對象的基於web的程序開發方法論 。 RUP既是一種軟件生命周期模型，又是一種支持面向對象軟件開發的工具，它將軟件開發過程要素和軟件工件要素整合在統一的框架中。
生命周期在時間上被分解為四個順序的階段：
初始階段（Inception）
細化階段（Elaboration）
構造階段（Construction）
移交階段（Transition）
每個階段結束於一個主要的裡程碑(Major Milestones)，並在階段結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。
RUP的迭代增量開發思想是融合瞭噴泉模型和增量模型的一種綜合生命周期模型。
使用UML（Unified Modeling Language，統一建模語言）進行軟件建模。
敏捷模型
敏捷建模原則： (1)優先考慮的是通過盡早地和不斷地提交有價值的軟件使客戶滿意； (2)即使到瞭開發的後期，也歡迎改變需求； (3)敏捷過程利用變化來為客戶創造競爭優勢； (4)經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好； (5)圍繞被激勵起來的個體來構建項目； (6)給他們提供所需的環境和支持，並且信任他們能夠完成工作； (7)在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是面對面的交談；工作的軟件是首要的進度度量標準；敏捷過程提倡可持續的開發速度； (8)責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度； (9)優秀的技能和好的設計會增強敏捷能力； (10)簡單是最根本的； (11)最好的構架、需求和設計出於自組織團隊； (12)每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，對自己的行為進行調整。
參考教材：
軟件工程模型與方法 肖丁等編著 北京郵電大學出版社
實用軟件工程（第二版），鄭人傑、殷人昆、陶永雷，清華大學出版社 2004
軟件工程導論（第四版），張海藩編著，清華大學出版社 2005
