軟件危機
早期時代（1960中期以前）
個體化的軟件環境：編寫者和使用者往往是同一個（或同一組）人
這種個體化的軟件環境，使得軟件設計通常是在人們頭腦中進行的一個隱含的過程，除了程序清單之外，沒有其他文檔資料保存下來
第二個時期（1960-1970）
軟件作坊：廣泛使用產品軟件
基本上仍然沿用早期形成的個體化軟件開發方法，許多程序的個體化特性使得他們最終成為不可維護的
軟件危機的介紹
軟件危機包含下述兩方面的問題：
- 如何開發軟件，以滿足對軟件日益增長的需求
- 如何維護數量不斷膨脹的已有軟件
軟件危機主要有以下一些典型表現：
- 對軟件開發成本和進度的估計常常很不准確
- 用戶對“已完成的”軟件系統不滿意的現象經常發生
- 軟件產品的質量往往靠不住
- 軟件常常是不可維護的
- 軟件通常沒有適當的文檔資料
- 軟件成本在計算機系統中成本中所占的比例逐年上升
- 軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢
產生軟件危機的原因
- 一方面與軟件本身的特點有關
- 一方面也和軟件開發與維護的方法不正確有關
軟件是邏輯部件而不是物理部件
軟件維護通常意味着更正或修改原來的設計，這就在客觀上使得軟件較難維護
軟件不同於一般程序，它的一個顯著特點是規模龐大，而且程序復雜性將隨着程序的規模的增加而呈指數上升
錯誤的認識和做法主要表現為忽視軟件需求分析的重要性，認為軟件開發就是寫程序並設法使之運行，輕視軟件維護
軟件生命周期
- 問題定義
- 可行性研究
- 需求分析
- 開發時期
- 編寫程序
- 測試工作
消除軟件危機的途徑
軟件是程序、數據及相關文檔的完整集合
程序：能夠完成預定功能和性能的可執行的指令序列
數據：是使程序能夠適當地處理信息的數據結構
文檔：開發、使用和維護程序所需要的圖文資料
1983年IEEE為軟件下的定義是：計算機程序、方法、規則、相關的文檔資料以及在計算機上運行程序時所必須的數據，方法和規則通常是在文檔中說明並在程序中實現的
軟件工程
軟件工程的介紹
軟件工程是指導計算機軟件開發和維護的一門工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件並有效地維護它
1968年第一屆NATO會議上給出了軟件工程的一個早期定義：軟件工程就是為了經濟地獲得可靠的且能在實際機器上有效地運行的軟件，而建立和使用完善的工程原理
1993年IEEE給出了更全面更具體的定義：軟件工程是（1）把系統的、規范的、可度量的途徑應用於軟件開發、運行和維護過程，也就是把工程應用於軟件；（2）研究（1）中提到的途徑
軟件工程的本質特性
- 軟件工程關注於大型程序的構造
- 軟件工程的中心課題是控制復雜性
- 軟件經常變化
- 開發軟件的效率非常重要
- 和諧地合作是開發軟件的關鍵
- 軟件必須有效地支持它的用戶
- 在軟件工程領域中通常由具有一種文化背景的人替具有另一種文化背景的人創造產品
軟件工程的基本原理
-
用分階段的聲明周期計划嚴格管理
以為着，應該把軟件生命周期分成若干個階段，並相應制定出切實可行的計划，然后嚴格按照計划對軟件的開發與維護工作進行管理
-
堅持進行階段評審
- 大部分錯誤時在編碼之前造成的
- 錯誤發現與改正得越晚，所需要付出的代價也越高，因此在每個階段進行嚴格的評審，以便盡早發現在軟件開發過程中所犯的錯誤，是一條必須遵守的重要原則
-
實行嚴格的產品控制
當改變需求時，為了保持軟件各個配置成分的一致性，必須實行嚴格的產品控制，其中主要是實行基准配置管理
- 基准配置（基線配置）：經過階段評審后的軟件配置成分（文檔或程序代碼）
- 基准配置管理也稱為變動控制：一切有關修改協議的建議，特別是涉及對基准配置的修改建議，都必須嚴格按照的規程進行評審，獲得批准后才能實施修改
-
采用現代程序設計技術
采用先進的技術不僅可以提高軟件開發和維護的效率，而且可以提高軟件產品的質量
-
結果應能清楚的審查
為了提高軟件開發過程的可見性，更好地進行管理，應該根據軟件開發項目的總目標及完成期限，規定開發組織的責任和產品標准，從而使得到的結果能夠清楚的審查
-
開發小組的人員應該少而精
軟件開發小組的組成人員的素質應該好，而人數則不宜過多
-
承認不斷改進軟件工程實踐的必要性
不僅要積極主動地采納新的軟件技術，而且要注意不斷的總結經驗
軟件工程方法學
方法學（methodology）：軟件生命周期全過程中使用的一整套技術方法的集合，也稱為范型（paradigm）
軟件工程方法學的三要素：
-
方法
-
工具
-
過程
目前使用的最廣泛的軟件工程方法學為
-
傳統方法學
-
面向對象方法學
-
傳統方法學
也稱為生命周期方法學或結構化范型。把軟件生命周期的全過程依次划分為若干個階段，然后順序地完成每個階段的任務
-
面向對象方法學
當軟件規模龐大，或者對軟件的需求是模糊的或會隨着時間變化而變化的時候，使用傳統方法學開發軟件往往不成功，此外，使用傳統方法學開發出的軟件，維護起來仍然很困難
與傳統方法相反，面向對象方法把數據和行為看成是同等重要，它是一種以數據為主線，把數據和對數據的操作緊密地結合起來的方法
具有4個要點
- 把對象作為融合了數據及在數據上的操作行為的統一的軟件構建
- 把所有對象都划分成類
- 按照父類（基類）與子類（派生類）的關系，把若干個相關類組成一個層次結構的系統（類等級）
- 對象彼此間僅能通過發送消息互相聯系
傳統方法學強調自頂向下順序的完成軟件開發的各階段的任務
用面向對象方法學開發軟件的過程，是一個主動地多次反復迭代的演化過程。正確地運用面向對象方法學開發軟件，則最終的軟件產品由許多較小的、基本上獨立的對象組成，每個對象相當於一個微型程序，而且大多數對象都與現實世界中的實體相對應，因此，降低了軟件產品的復雜性，提高了軟件的可理解性，簡化了軟件的開發和維護工作。面向對象方法特有的繼承性和多態性，進一步提高了面向對象軟件的可重性
軟件生命周期
-
軟件定義
-
問題定義
必須回答：要解決的問題是什么？
-
可行性研究
關鍵問題：對於上一個階段所確定的問題有行得通的解決辦法嗎？
-
需求分析
為了解決這個問題，目標系統必須做什么？主要是確定目標系統必須具備哪些功能？用正式文檔准確地記錄目標系統的需求，這份文檔通常稱為規格說明書（specification）
-
-
軟件開發
-
總體設計（概要設計）
關鍵問題：概括地說，應該怎樣實現目標系統？
首先，應該設計出實現目標系統的幾種可能的方案。通常至少應該設計出低成本、中成本和高成本三種方案
軟件設計的一條基本原理就是，程序應該模塊化，也就是說，一個程序應該由若干個規模適中的模塊按合理的層次結構組織而成。因此，總體設計的另一項主要任務就是設計程序的體系結構，也就是確定程序由哪些模塊組成以及模塊間的關系
-
詳細設計（模塊設計）
把解法具體化，關鍵問題：應該怎樣具體地實現這個系統呢？
這個階段還不是編寫程序，而是設計出程序的詳細規格說明
詳細地設計每個模塊，確定實現模塊功能所需要的算法和數據結構
-
編碼和單元測試
關鍵任務：寫出正確的容易理解、容易維護的程序模塊
-
綜合測試
關鍵任務：通過各種類型的測試（以及調試）使軟件達到預定的要求
最基本的測試
-
集成測試
根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試
-
驗收測試
按照規格說明書的規定，由用戶（或用戶積極參加下）對目標系統進行驗收
必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗
-
-
-
運行維護（軟件維護）
關鍵任務：通過各種必要的維護活動使系統持久地滿足用戶的需要
通常有4類維護活動：
- 改正性維護
- 適應性維護
- 完善性維護
- 預防性維護