本文內容來自於對《軟件工程導論》（第6版，張海潘 牟永敏 編著），僅爲個人學習記錄。如涉及版權問題請版權方聯繫我。
1.1軟件危機
軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。軟件危機包含兩方面的問題：
如何開發軟件，以滿足對軟件日益增長的需求；如何維護數量不斷膨脹的已有軟件。
軟件危機有一下的典型表現：
（1）對軟件成本和進度的估計常常很不準確。
（2）用戶對“已完成的”軟件系統不滿意的現象經常發生。
（3）軟件產品的質量往往靠不住。
（4）軟件常常是不可維護的。
（5）軟件通常沒有適當的文檔資料。
（6）軟件成本在計算機系統總成本中所佔的比例逐年上升。
（7）軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。
軟件生命週期：
軟件開發最初的工作應是問題的定義；然後要進行可行性研究；接下來應該進行需求分析。進過上述軟件定義時期的準備工作才能進入開發時期，而在開發時期，首先要對軟件進行設計（通常又分爲概要設計和詳細設計兩個階段），然後才能進入編寫程序的階段，程序編寫玩之後還必須經過大量的測試工作（需要的工作量通常佔軟件開發全部工作量的40%~50%）才能最終交付使用。所以，編寫程序只是軟件開發過程中的一個階段，而且在典型的軟件開發工程中，編寫程序所需的工作量只佔軟件開發全部工作量的10%~20%。
軟件工程學的一個重要目標就是提高軟件的可維護性，減少軟件維護的代價。
消除軟件危機的途徑：
首先應該對計算機軟件有一個正確的認識。應該徹底消除在計算機系統早期發展階段形成的“軟件就是程序”的錯誤觀念。一個軟件必須由一個完整的配置組成，事實上，軟件是程序、數據及相關文檔的完整集合。其中，程序是能夠完成預定功能和性能的可執行的指令序列；數據是是程序能夠適當地處理信息的數據結構；文檔是開發、使用和維護程序所需要的圖文資料。1983年IEEE爲軟件下的定義是：計算機程序、方法、規則、相關的文檔資料以及在計算機上運行程序時所必需的數據。
1.2軟件工程
概括地說，軟件工程是指導計算機軟件開發和維護的一門工程學科。
採用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件並有效地維護它，這就是軟件工程。
1968年在第一界NATO會議上曾經給出了軟件工程的一個早期定義：“軟件工程就是爲了經濟地獲得可靠的且能在實際機器上有效地運行的軟件，而建立和使用完善的工程原理。”
1993年IEEE進一步給出了一個更全面更具體的定義：“軟件工程是：①把系統的、規範的、可度量的途徑應用於軟件開發、運行和維護過程，也就是把工程應用於軟件；②研究①中提到的途徑。”
軟件工程具有下述的本質特性：
1.軟件工程關注於大型程序的構造
2.軟件工程的中心課題是控制複雜性
3.軟件經常變化
4.開發軟件的效率非常重要
5.和諧地合作是開發軟件的關鍵
6.軟件必須有效地支持它的用戶
7.在軟件工程領域中通常由具有一種文化背景的人替具有另一種文化背景的人創造產品
軟件工程的7條基本原理：
1.用分階段的生命週期計劃嚴格管理
2.堅持進行階段評審
3.實行嚴格的產品控制
4.採用現代程序設計技術
5.結果應能清楚地審查
6.開發小組的人員應該少而精
7.承認不斷改進軟件工程實踐的必要性
軟件工程方法學：
通常把在軟件生命週期全過程中使用的一整套技術方法的集合稱爲方法學（methodology），也成爲範型（paradigm）。在軟件工程領域中，這兩個術語的含義基本相同。
軟件工程方法學包含3個要素：方法、工具和過程。其中，方法是完成軟件開發的各項任務的技術方法，回答“怎樣做”的問題；工具是爲了運用方法二提供的自動的或半自動的軟件工程支撐環境；過程是爲了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。
目前使用得最廣泛的軟件工程方法學，分別是傳統方法學和麪向對象方法學：
傳統方法學也稱爲生命週期方法學或結構化範型。
面向對象方法學具有下述4個要點：
（1）把對象（object）作爲融合了數據及在數據上的操作行爲的統一的軟件構件。
（2）把所有對象都劃分成類（class）。
（3）按照父類（或稱爲基類）與子類（或稱爲派生類）的關係，把若干個相關類組成一個層次結構的系統（也稱爲類等級）。
（4）對象彼此間僅能通過發送消息互相聯繫。
1.3軟件生命週期
軟件生命週期由軟件定義、軟件開發和運行維護（也成爲軟件維護）3個時期組成，每個時期又進一步劃分成若干個階段。
軟件定義時期的任務是：確定軟件開發工程必須完成的總目標；確定工程的可行性；導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，並且制定工程進度表。這個時期通常又稱爲系統分析，由系統分析員負責完成。軟件定義時期通常進一步劃分成3個階段，即問題的定義、可行性研究和需求的分析。
開發時期具體設計和實現前一時期定義的軟件，它通常由下述5個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。其中前兩個階段又稱爲系統設計，後兩個階段又稱爲系統實現。
維護時期的主要任務是使軟件持久地滿足用戶的需求。
下面簡要介紹軟件生命週期每個階段的基本任務：
1.問題定義
問題定義階段必須回答的關鍵問題是：“要解決的問題是什麼？”如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得到的結果很可能是毫無意義的。儘管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。
通過對客戶的訪問調查，系統分析員扼要地寫出關於問題性質、工程目標和工程規範的書面報告，經過討論和必要的修改之後這份報告應該得到客戶的確認。
2.可行性研究
這個階段要回答的關鍵問題是：“對於上一個階段所確定的問題有行得通的解決方法嗎？”爲了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計過程，也就是在較抽象的高層次上進行的分析和設計過程。可行性研究應該是比較簡短的，這個階段的任務不是具體解決問題，而是研究問題的範圍，探索這個問題是否值得去解，是否有可行的解決方法。
可行性研究的結果是客戶做的是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段需要投入更多的人力物力。及時終止不值得投資的工程項目，可以避免更大的浪費。
3.需求分析
這個階段的任務仍然不是具體地解決問題，而是準確地確定“爲了解決這個問題，目標系統必須做什麼”，主要是確定目標系統必須具備哪些功能。
用戶瞭解他們面對的問題，知道必須做什麼，但是通常不能完整準確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟件開發人員知道怎樣用軟件實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此，系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法表示系統的邏輯模型。
在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須準確完整地體現用戶的需求。這個階段的一項重要任務，使用正式文檔準確地記錄對目標系統的需求，這份文檔通常稱爲規格說明書（specification）。
4.總體設計
這個階段必須回答的關鍵問題是：“概括地說，應該怎樣實現目標系統？”總體設計又稱爲概要設計。
首先，應該設計出實現目標系統的集中可能的方案。通常至少應該設計出低成本、中等成本和高成本3中方案。軟件工程師應該用適當的表達工具描述每種方案，分析每種方案的優缺點，並在充分權衡各種方案的利弊的基礎上，推薦一個最佳方案。此外，還應該制定出實現最佳方案的詳細計劃。如果客戶接受所推薦的方案，擇應該進一步完成下述的另一項主要任務。
上述設計工作確定瞭解決問題的策略及目標系統中應包含的程序，但是，怎樣設計這些程序呢？軟件設計的一條基本原理就是，程序應該模塊化，也就是說，一個程序應該由若干個模塊適中的模塊按合理的層次結構組織而成。因此，總體設計的另一個主要任務就是設計程序的體系結構，也就是確定程序由哪些模塊組成一級模塊間的關係。
5.詳細設計
總體設計階段以比較抽象概括的方式提出瞭解決問題的方法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：“應該怎樣具體地實現這個系統呢？”
這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。
詳細設計也成爲模塊設計，在這個階段將詳細地設計每個模塊，確定實現模塊功能所需要的算法和數據結構。
6.編碼和單元測試
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。
程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時使用彙編語言），把詳細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫的每一個模塊。
7.綜合測試
這個階段的關鍵人物是通過各種類型的測試（及相應的調試）使軟件打到預定的要求。
最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配的過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。
必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。
爲了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。
通過對軟件測試結果的分析可以預測軟件的可靠性；反之，根據對軟件可靠性的要求，也可以決定測試和調試過程什麼時候可以結束。
應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，作爲軟件配置的一個組成部分。
8.軟件維護
維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需求。
通常有4類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟件錯誤；適應性維護，即修改軟件以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟件使它更完善；預防性維護，即修改軟件爲將來的維護活動預先做準備。
雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟件設計，修改程序，測試程序，複查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟件定義和開發的全過程。
每一項維護活動都應該準確地記錄下來，作爲正式的文檔資料加以保存。
以上根據應該完成的任務的性質，把軟件生命週期劃分成8個階段。在實際從事軟件開發工作時，軟件規模、種類、開發環境以及開發時使用的技術方法等因素，都影響階段的劃分。事實上，承擔的軟件項目不同，應該完成的任務也有差異，沒有一個使用於所有軟件項目的任務集合。適用於大型複雜項目的任務集合，對於小型簡單項目而言往往就過於複雜了。
1.4軟件過程
軟件過程是爲了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。
大約有：瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型、Rational統一過程（RUP）、敏捷過程與極限編程、微軟過程等過程框架。
作爲一名.NET程序猿。着重記錄微軟過程。
微軟過程
作爲世界上最大的同時也是最成功的的軟件公司之一，Microsoft公司擁有自己獨特的軟件開發過程，幾十年的實踐證明微軟過程是非常成功和行之有效的。下面簡要地介紹微軟過程。
1.微軟過程準則
微軟過程遵循下述的基本準則：
項目計劃應該兼顧未來的不確定因素。
用有效的風險管理來減少不確定因素的影響。
經常生成並快速地測試軟件的過度版本，從而提高產品的穩定性和可預測性。
採用快速循環、遞進的開發過程。
用創造性的工作來平衡產品特性和產品成本。
項目進度表應該具有較高穩定性和 權威性。
使用小型項目組併發地完成開發工作。
在項目早起把軟件配置項基線化，項目後期則凍結產品。
使用原型驗證概念，對項目進行早起論證。
把零缺陷作爲追求的目標。
里程碑評審會的目的是改進工作，切忌互相指責。
2.微軟軟件生命週期
微軟過程把軟件生命週期劃分成5個階段，下面簡述各個階段的工作內容。
（1）規劃階段
這個階段的主要任務是，根據從市場上獲得的用戶情況和用戶需求等信息，在調查、統計和分析的基礎上，完成下述工作。
確定產品目標。
獲取競爭對手的信息。
完成對客戶和市場的調研分析。
確定新版本產品應該具備的主要特性。
確定相對於前一版本而言，新版本應該解決的問題和需要增加的功能。
（2）設計階段
當項目團隊已經確定了70%以上的產品需求時，開發工作就可以進入設計階段了，這個階段的主要工作內容如下：
根據產品目標便攜系統的特性規格說明書，這份規格說明書主要描述軟件特性、系統結構、各構件間的相關性以及接口標準。
從系統高層開始着手盡心系統設計，主要完成下述工作：簡明扼要地描述整個系統的設計方案，繪製系統結構圖，確定系統中存在的風險因素，分析系統的可重用性。
劃分出系統中的子系統，給出各個子系統和各個構建的規格說明。
根據產品特性規格說明書制訂產品開發計劃。
（3）開發階段
這個階段的主要任務是，完成產品中所有構件的開發工作，包括編寫程序代碼和書寫文檔。一些開發工作可能會持續到穩定階段，以便在那時對測試中發現的問題作出修改。
（4）穩定階段
這個階段的主要任務是對產品進行測試和調試，以確保已經正確地實現了整個解決方案，產品可以發佈了。這個階段測試的重點是，產品在真實環境下的使用和操作。
（5）發佈階段
在這個階段項目組發佈產品或解決方案，穩定發佈過程，並把項目移交到運營和支持人員手中，以獲得最終用戶對項目的認可。
綜上所述，作爲另外一種適用於商業環境下具有有限資源和有限開發時間約束的項目的軟件過程模式，微軟過程綜合了Rational統一過程和敏捷過程的許多優點，是對衆多成功項目的開發經驗的正確總結；另一方面，微軟過程也有某些不足之處，例如，對方法、工具和產品等方面的論述不如RUP和敏捷過程全面，人們對它的某些準則本身也有不同意見。在開發軟件的實踐中，應該把微軟過程與RUP和敏捷過程結合起來，取長補短，針對不同項目的具體情況進行定製。
本文內容來自於對《軟件工程導論》（第6版，張海潘 牟永敏 編著），僅爲個人學習記錄。如涉及版權問題請版權方聯繫我。