第七章軟件系統開發與軟件工程方法

一、軟件危機二、軟件工程第七章軟件系統開發與軟件工程方法一、軟件危機

一、軟件危機1、軟件開發的發展歷程

19601970198019902000

早期

第二階段第三階段第四階段面向批處理

多用戶

分布式系統

強大的桌面系統有限的分布

實時

嵌入“智能”面向對象技術自定義軟件

數據庫

低成本硬件

專家系統開發者=使用者

軟件產品

人工神經網絡

并行計算

網絡計算機

一、軟件危機19601970198019902000

一、軟件危機2、軟件危機

1）案例思考1——FAA的失敗項目 20世紀80年代中期，更換空中交通控制系統已成為美國聯邦航空管理局（FAA）非常優先的任務。1989年IBM公司獲得更換該系統的合同，截止期為2001年，預計投入25億美元。由于面臨著極苛刻的需求，該軟件項目是已進行的最復雜的項目之一。例如，交通控制系統必須具備全局完整性并且每周7天，每天24小時不能停止工作，甚至在升級時或正常維護時，也不允許有停頓時間。任何錯誤的數據都會引起重大傷亡，任何停機均會導致世界范圍的出行延誤或潛在的危險。該系統的反應時間不能超過2-3秒。此外，該系統設計時必須考慮到允許私人飛機駕駛員繼續使用舊設備，并要求軟件能在未來移植到更新的硬件設備上。當IBM獲得該合同后，該系統的主要花費為軟件開發，用于硬件的投入僅為8萬美元。1993年，負責該項目的IBM子公司——IBM聯邦系統公司被IBM賣給了Loral公司。到1994年，該系統已花費了23億美元，但尚未提交系統的任何程序段，而此時估算整個系統的花費將增至50億美元。1994年底，FAA不得不承認該項目失敗并進行調查。作為調查的結果，FAA取消或修改了系統的四個主要部分。面臨當前空中控制系統存在的隱患，FAA不得不訂購了一套作為權宜之計的系統，由另一家公司開發。 你認為該項目的失敗反映了什么問題？失敗的主要原因可能是什么？FAA為什么選擇取消和修改的方式而不是增加資源和生產力的方式？

一、軟件危機1）案例思考1——FAA的失敗項目FAA對此項目調查總結出的原因為以下幾條：FAA并沒有明確掌握某些系統功能的需求。制定了過于急躁的開發和實現計劃（包括費用與進度的估計）在給定的軟件復雜度下，沒有考慮到開發商的生產力，尤其是早期階段需要投入的資源。在《人月神話》一書中，Brooks將過去30年大型軟件項目的開發比喻為史前陷入瀝青坑的巨獸。恐龍、猛犸、劍齒虎等動物在焦油中掙扎，然而掙扎得越激烈，就陷得越快，最終都沉到了坑底。過去的大型軟件項目中，大多數開發出了可運行的系統——不過只有極少數滿足了目標、進度和預算的要求。表面上看起來沒有任何一個單獨的問題會導致困難，每個問題都能獲得解決，但這些問題糾纏和積累在一起時，團隊的行動就越來越慢，并且很難再看清問題的本質。FAA對此項目調查總結出的原因為以下幾條：在《人月神話》一書1995年美國的商業軟件失敗統計：1995年美國的商業軟件失敗統計：

一、軟件危機2、軟件危機

案例思考2——遺傳信息庫建設 在正在建設的遺傳信息庫如，假設你要開發一個管理軟件。你并不是一個生物遺傳方面的專家，甚至對此方面的知識一竅不通，你該如何入手？要使該項目成功，你認為應該有哪些保障條件？你的問題是什么：對遺傳信息的管理需要什么條件：了解遺傳信息的表示和管理流程如何實現：與遺傳領域的專家交流。障礙是什么：難以溝通與交流。可能因誤解產生錯誤的需求描述。

一、軟件危機案例思考2——遺傳信息庫建設你的問題是什么：對

一、軟件危機2、軟件危機

軟件項目為什么會失敗？

軟件項目失敗的核心問題在哪里？答案只有一個：復雜性。軟件要解決的問題本身是復雜的開發人員一般不是該問題領域的專家軟件規模要求多人參與，而不同專業領域的人的交流是困難的軟件規模使得既要理解系統整體結構又要把握細節比較困難。

一、軟件危機軟件項目為什么會失敗？軟件項目失敗的核心問題在例:Windows95有1000萬行代碼

Windows2000有5000萬行代碼Exchange2000和Windows2000開發人員結構Exchange2000Windows2000項目經理25人約250人開發人員140人約1700人測試人員350人約3200人例:Windows95有1000萬行代碼Exchange20

一、軟件危機2、軟件危機

2）軟件神話

[1]管理神話神話：有關軟件開發的理論和方法已經很豐富，有很多可用的標準與規范，因而可以保證軟件開發的順利進行。現實：理論與方法在大多數實踐中并沒有得到真正的應用。使用者并沒有對這些理論與方法建立正確的認識。神話：已經有很多強大的開發工具和先進的計算機硬件，這些可以保證軟件開發的質量與效率。現實：這些工具并沒有得到合理的應用。神話：如果我們落后于進度，可以通過增加人手來趕上。現實：向一個已經延遲的項目增加人手，只會使延遲的項目更加落后——除非項目中不需要交流。生一個孩子10個月，無論有多少人。

一、軟件危機2）軟件神話[1]管理神話

一、軟件危機2、軟件危機

2）軟件神話

[1]管理神話神話：通過把軟件項目外包給實現強大的軟件開發公司可以保證軟件的成功。現實：再專業的軟件公司，不了解客戶的需求和業務流程，也不可能順利完成軟件開發項目。

一、軟件危機2）軟件神話[1]管理神話改正一個問題需付出的代價需求分析結構設計詳細設計編碼集成測試系統測試現場改正一個問題的估計費用改正一個問題估計的工作量20200200010005.02.50.050.5(美元)(人天)改正一個問題需付出的代價需結構設計詳細設計編碼集成測試系統測

一、軟件危機2、軟件危機

2）軟件神話

[2]客戶神話神話：有了目標系統的一般性描述就可以寫程序了，細節可以逐步完善。現實：糟糕的系統定義是項目失敗的主要原因。關于問題域、功能、行為、性能、接口、設計約束以及確認標準的形式化的、詳細的描述是必要的，這些內容只能通過客戶與開發者之間的交流才能確定。神話：軟件需求是經常變更的，而這些變更可以容易的被滿足，因為軟件是靈活的。現實：軟件需求確實是容易變更的，但變更的代價將隨軟件開發的進度不同而有很大的差異。如果重新項目早期的問題定義，需求變化則很容易被調節，而項目后期需求變更的代價可能是致命的。

一、軟件危機2）軟件神話[2]客戶神話

一、軟件危機2、軟件危機

2）軟件神話[3]實踐者的神話神話：軟件是藝術，軟件開發是個人的舞臺。現實：50年代可能是，現在不是。神話：一旦寫完了程序并能正常運行，我們的工作就結束了。現實：越早開始寫代碼，軟件開發花費的時間就越長。統計表明60%到80%的工作量是花在將軟件第一次交付給客戶以后發生的。神話：程序真正運行以前，沒有辦法評估其質量。現實：高質量的實現來自高質量的設計。從項目一開始就必須進行技術評審。神話：項目的成功來自于可運行程序的提交。軟件開發過程中的文檔是不必要的，延緩項目進度的東西。現實：軟件項目的成果包含很多內容，文檔是成功開發的基礎，也是軟件質量的保證。好的開發質量降低了重復勞動，從而提高了效率，導致更短的交付時間。

一、軟件危機2）軟件神話[3]實踐者的神話

一、軟件危機2、軟件危機

3）軟件危機及主要表現軟件危機指在計算機軟件開發和維護過程中所遇到的一系列嚴重問題——軟件開發不能滿足日益增長的需求；難以維護不斷增長的已有軟件。[1]成本與進度的估計[2]用戶需求與產品不一致[3]軟件可靠性差[4]可維護性差[5]文檔資料不完整[6]軟件成本比例不斷上升[7]開發生產率相對停滯

一、軟件危機3）軟件危機及主要表現軟件危機指在計算機軟件開一、軟件危機2、軟件危機

3）軟件項目成敗的因素分析1）失敗項目的主要原因[1]用戶需求不完整、被誤解或經常變化[2]有限的用戶參與[3]缺少行政支持[4]缺少技術支持[5]項目計劃不充分[6]目標不明確[7]沒有足夠的資源（客戶沒有提供/開發者不具備相應生產力）2）成功項目的主要原因[1]大量的用戶參與[2]上層管理人員的支持[3]完整、詳細的項目計劃[4]符合實際的工作進度與里程碑[5]開發人員的培訓、交流[6]良好的工作環境、團隊協作機制一、軟件危機3）軟件項目成敗的因素分析1）失敗項目的主要原因一、軟件危機2、軟件危機

3）消除軟件危機的思路——[1]正確的觀念a)軟件不是程序軟件是邏輯產品而不是實物產品軟件的功能依賴于硬件和軟件的運行環境以及人們對它的操作軟件特征：功能的多樣性實現的多樣性能見度低軟件結構合理性差智力密集及知識產權保護b)軟件開發不是個體勞動軟件設計的復雜性一、軟件危機3）消除軟件危機的思路——[1]正確的觀念a)軟一、軟件危機2、軟件危機

3）消除軟件危機的思路——[2]正確的過程管理與控制軟件開發技術:軟件開發方法軟件開發過程軟件工具和軟件工程環境軟件工程管理:軟件管理軟件經濟軟件心理一、軟件危機3）消除軟件危機的思路——[2]正確的過程管理與二、軟件工程1、軟件工程將工程管理思想引入軟件開發過程：

轉變對軟件的認識：上升程序系統轉變思維定式：上升程序員系統工程師(系統分析員)

工程化訓練二、軟件工程轉變對軟件的認識：二、軟件工程1、軟件工程將工程管理思想引入軟件開發過程：

二、軟件工程用戶分析員程序員用戶分析員程序員“一個好的工業，應有一套

良好的標準來配套”軟件的工業化生產過程應具備的特點：明確的工作步驟詳細具體的規范化文檔明確的質量評價標準“一個好的工業，應有一套

良好的標準來配套”軟件的工業化生產軟件產品的標準化軟件開發過程的標準化軟件產品的標準化軟件開發過程的標準化

強調規范化強調文檔化軟件工程技術的兩個明顯特點：強調規范化軟件工程技術的兩個明顯特點：二、軟件工程1、軟件工程FritzBauer在NATO會議上給出的定義：“軟件工程是為了經濟地獲得可靠的和能在實際機器上高效運行的軟件而確立和使用的健全的工程原理（方法）。”

二、軟件工程二、軟件工程1、軟件工程IEEE【IEE83】給出的軟件工程定義：“軟件工程是開發、運行、維護和修復軟件的系統方法。”

二、軟件工程二、軟件工程1、軟件工程

IEEE【IEE93】給出了一個更加綜合的定義：“將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件中。”二、軟件工程二、軟件工程1、軟件工程

軟件工程是應用計算機科學、數學及管理科學等原理開發軟件的工程。它借鑒傳統工程的原則、方法，以提高質量，降低成本為目的。軟件工程所包含的內容不是一成不變的，而是隨著人們對軟件系統的研制開發和生產的理解不斷發展變化，應該用發展的眼光看待。二、軟件工程軟件工程所包含的內容不是一成不變的，而是隨著人們二、軟件工程1、軟件工程軟件工程是一種層次化的活動，a)質量——軟件工程的根基與目標b)過程——建造一個高質量軟件所需完成任務的框架c)方法——提供了如何建造軟件的技術手段d)工具——為過程和方法提供自動或半自動化的支持（CASE）二、軟件工程軟件工程是一種層次化的活動，a)質量——軟件工程工具方法過程質量焦點工具方法過程質量焦點二、軟件工程2、軟件工程一般視圖

工程：對技術（或社會）實體的分析、設計、構造、驗證和管理。首先要問題的問題： 要解決什么問題？ 實體的什么特征能解決這個問題？ 如何設計該實體？ 如何構建該實體？ 如何控制和避免構建過程中的錯誤？ 如何在用戶要求修改、適應和增強時長期地支持這些實體？定義階段：做什么開發階段：如何做支持階段：應對變化項目跟蹤與控制技術評審質量保證軟件配置管理文檔管理復用管理測試管理風險管理支持活動二、軟件工程工程：對技術（或社會）實體的分析、設計、構造、驗軟件工程框架可用性性性確正合算選取適宜的開發模型采用合適的設計方法提供高質量的工程支持重視軟件工程的管理基本過程原則

目標過

程支持過程組織過程軟件工程框架可用性性性確正合算選取適宜的開發模型采用合適的設軟件過程評估軟件能力成熟度CMM1-初始級：沒有過程定義，個人能力。2-可重復級：基本項目管理過程，跟蹤費用與進度，有必要的規范以重復類似項目的成功。3-定義級：過程管理文檔化、標準化、集成化。使用統一的文檔化的組織過程認可的方法開發和維護軟件。4-管理級：對軟件過程與產品質量進行詳細地定量地收集與評估5-優化級：通過定量反饋不斷進行過程優化與改進。軟件過程評估軟件能力成熟度CMM二、軟件工程3、軟件開發過程——軟件生命周期軟件產品或軟件系統從設計、投入使用到被淘汰的全過程。二、軟件工程軟件生存期的階段劃分(1)可行性研究與計劃(2)需求分析(3)總體設計(4)詳細設計(5)實現(6)集成測試(7)確認測試(8)使用和維護軟件生存期的階段劃分(1)可行性研究與計劃二、軟件工程3、軟件開發過程——軟件開發模型軟件開發模型是軟件開發全部過程、活動和任務的結構框架。它能直觀表達軟件開發全過程，明確規定要完成的主要活動、任務和開發策略。軟件開發模型也常稱為：軟件過程模型軟件生存期模型軟件工程范型二、軟件工程二、軟件工程2、軟件開發過程——瀑布模型可行性研究與計劃需求分析設計編碼運行維護測試定義階段開發階段維護階段二、軟件工程可行性研究與計劃需求分析設計編碼運行維護測試定義按照傳統瀑布模型開發軟件的特點1.階段間具有順序性和依賴性。2.推遲實現的觀點。3.每個階段必須完成規定的文檔;每個階段結束前完成文檔審查,及早改正錯誤。按照傳統瀑布模型開發軟件的特點1.階段間具有順序性和依賴性。二、軟件工程2、軟件開發過程——原型模型建造/修改原型用戶測試運行原型

聽取用戶意見二、軟件工程建造/修改用戶測試聽取用采用原型模型的軟件生存周期分析定義系統需求生成原型系統設計程序設計編碼測試運行和維護原型化含原型化的軟件生存期采用原型模型的軟件生存周期分析定義生成系統程序編碼測試運行二、軟件工程2、軟件開發過程——增量模型先完成一個系統子集的開發，再按同樣的開發步驟增加功能(系統子集),如此遞增下去直至滿足全部系統需求。系統的總體設計在初始子集設計階段就應作出設想。

二、軟件工程分析增量模型設計編碼測試分析設計編碼測試分析設計編碼測試分析設計編碼測試增量1增量2增量3增量n

增量1交付客戶

增量2交付客戶

增量3交付客戶增量n交付客戶日歷時間…..分析增量模型設計編碼測試分析設計編碼測試分析風險分析工程實施用戶通信用戶評估產品維護項目產品增強項目新產品開發項目概念開發項目計劃建造及發布2、軟件開發過程——螺旋模型風險工程用戶通信用戶產品維護項目產品增強項目新產品開發項目概V1.0功能時間V2.0V1.1V1.0功時間V2.0V1.1二、軟件工程進一步開發實現和集成階段運行狀態實現階段計劃階段面向對象分析階段需求階段維護期2、軟件開發過程——噴泉模型二、軟件工程進一步開發實現和集成階段運行狀態實現階段計劃階段2、軟件開發過程——組件模型與軟件生產線應用構件提取車間應用構件庫構件生產車間構件庫組裝車間領域1領域2應用系統...12341基礎構件，2功能構件3接口構件，4用戶界面構件2、軟件開發過程——組件模型與軟件生產線應用構件應用構件生第七章軟件系統開發與軟件工程方法

一、軟件危機二、軟件工程第七章軟件系統開發與軟件工程方法一、軟件危機

一、軟件危機1、軟件開發的發展歷程

19601970198019902000

早期

第二階段第三階段第四階段面向批處理

多用戶

分布式系統

強大的桌面系統有限的分布

實時

嵌入“智能”面向對象技術自定義軟件

數據庫

低成本硬件

專家系統開發者=使用者

軟件產品

人工神經網絡

并行計算

網絡計算機

一、軟件危機19601970198019902000

一、軟件危機2、軟件危機

1）案例思考1——FAA的失敗項目 20世紀80年代中期，更換空中交通控制系統已成為美國聯邦航空管理局（FAA）非常優先的任務。1989年IBM公司獲得更換該系統的合同，截止期為2001年，預計投入25億美元。由于面臨著極苛刻的需求，該軟件項目是已進行的最復雜的項目之一。例如，交通控制系統必須具備全局完整性并且每周7天，每天24小時不能停止工作，甚至在升級時或正常維護時，也不允許有停頓時間。任何錯誤的數據都會引起重大傷亡，任何停機均會導致世界范圍的出行延誤或潛在的危險。該系統的反應時間不能超過2-3秒。此外，該系統設計時必須考慮到允許私人飛機駕駛員繼續使用舊設備，并要求軟件能在未來移植到更新的硬件設備上。當IBM獲得該合同后，該系統的主要花費為軟件開發，用于硬件的投入僅為8萬美元。1993年，負責該項目的IBM子公司——IBM聯邦系統公司被IBM賣給了Loral公司。到1994年，該系統已花費了23億美元，但尚未提交系統的任何程序段，而此時估算整個系統的花費將增至50億美元。1994年底，FAA不得不承認該項目失敗并進行調查。作為調查的結果，FAA取消或修改了系統的四個主要部分。面臨當前空中控制系統存在的隱患，FAA不得不訂購了一套作為權宜之計的系統，由另一家公司開發。 你認為該項目的失敗反映了什么問題？失敗的主要原因可能是什么？FAA為什么選擇取消和修改的方式而不是增加資源和生產力的方式？

一、軟件危機1）案例思考1——FAA的失敗項目FAA對此項目調查總結出的原因為以下幾條：FAA并沒有明確掌握某些系統功能的需求。制定了過于急躁的開發和實現計劃（包括費用與進度的估計）在給定的軟件復雜度下，沒有考慮到開發商的生產力，尤其是早期階段需要投入的資源。在《人月神話》一書中，Brooks將過去30年大型軟件項目的開發比喻為史前陷入瀝青坑的巨獸。恐龍、猛犸、劍齒虎等動物在焦油中掙扎，然而掙扎得越激烈，就陷得越快，最終都沉到了坑底。過去的大型軟件項目中，大多數開發出了可運行的系統——不過只有極少數滿足了目標、進度和預算的要求。表面上看起來沒有任何一個單獨的問題會導致困難，每個問題都能獲得解決，但這些問題糾纏和積累在一起時，團隊的行動就越來越慢，并且很難再看清問題的本質。FAA對此項目調查總結出的原因為以下幾條：在《人月神話》一書1995年美國的商業軟件失敗統計：1995年美國的商業軟件失敗統計：

一、軟件危機2、軟件危機

案例思考2——遺傳信息庫建設 在正在建設的遺傳信息庫如，假設你要開發一個管理軟件。你并不是一個生物遺傳方面的專家，甚至對此方面的知識一竅不通，你該如何入手？要使該項目成功，你認為應該有哪些保障條件？你的問題是什么：對遺傳信息的管理需要什么條件：了解遺傳信息的表示和管理流程如何實現：與遺傳領域的專家交流。障礙是什么：難以溝通與交流。可能因誤解產生錯誤的需求描述。

一、軟件危機案例思考2——遺傳信息庫建設你的問題是什么：對

一、軟件危機2、軟件危機

軟件項目為什么會失敗？

軟件項目失敗的核心問題在哪里？答案只有一個：復雜性。軟件要解決的問題本身是復雜的開發人員一般不是該問題領域的專家軟件規模要求多人參與，而不同專業領域的人的交流是困難的軟件規模使得既要理解系統整體結構又要把握細節比較困難。

一、軟件危機軟件項目為什么會失敗？軟件項目失敗的核心問題在例:Windows95有1000萬行代碼

Windows2000有5000萬行代碼Exchange2000和Windows2000開發人員結構Exchange2000Windows2000項目經理25人約250人開發人員140人約1700人測試人員350人約3200人例:Windows95有1000萬行代碼Exchange20

一、軟件危機2、軟件危機

2）軟件神話

[1]管理神話神話：有關軟件開發的理論和方法已經很豐富，有很多可用的標準與規范，因而可以保證軟件開發的順利進行。現實：理論與方法在大多數實踐中并沒有得到真正的應用。使用者并沒有對這些理論與方法建立正確的認識。神話：已經有很多強大的開發工具和先進的計算機硬件，這些可以保證軟件開發的質量與效率。現實：這些工具并沒有得到合理的應用。神話：如果我們落后于進度，可以通過增加人手來趕上。現實：向一個已經延遲的項目增加人手，只會使延遲的項目更加落后——除非項目中不需要交流。生一個孩子10個月，無論有多少人。

一、軟件危機2）軟件神話[1]管理神話

一、軟件危機2、軟件危機

2）軟件神話

[1]管理神話神話：通過把軟件項目外包給實現強大的軟件開發公司可以保證軟件的成功。現實：再專業的軟件公司，不了解客戶的需求和業務流程，也不可能順利完成軟件開發項目。

一、軟件危機2）軟件神話[1]管理神話改正一個問題需付出的代價需求分析結構設計詳細設計編碼集成測試系統測試現場改正一個問題的估計費用改正一個問題估計的工作量20200200010005.02.50.050.5(美元)(人天)改正一個問題需付出的代價需結構設計詳細設計編碼集成測試系統測

一、軟件危機2、軟件危機

2）軟件神話

[2]客戶神話神話：有了目標系統的一般性描述就可以寫程序了，細節可以逐步完善。現實：糟糕的系統定義是項目失敗的主要原因。關于問題域、功能、行為、性能、接口、設計約束以及確認標準的形式化的、詳細的描述是必要的，這些內容只能通過客戶與開發者之間的交流才能確定。神話：軟件需求是經常變更的，而這些變更可以容易的被滿足，因為軟件是靈活的。現實：軟件需求確實是容易變更的，但變更的代價將隨軟件開發的進度不同而有很大的差異。如果重新項目早期的問題定義，需求變化則很容易被調節，而項目后期需求變更的代價可能是致命的。

一、軟件危機2）軟件神話[2]客戶神話

一、軟件危機2、軟件危機

2）軟件神話[3]實踐者的神話神話：軟件是藝術，軟件開發是個人的舞臺。現實：50年代可能是，現在不是。神話：一旦寫完了程序并能正常運行，我們的工作就結束了。現實：越早開始寫代碼，軟件開發花費的時間就越長。統計表明60%到80%的工作量是花在將軟件第一次交付給客戶以后發生的。神話：程序真正運行以前，沒有辦法評估其質量。現實：高質量的實現來自高質量的設計。從項目一開始就必須進行技術評審。神話：項目的成功來自于可運行程序的提交。軟件開發過程中的文檔是不必要的，延緩項目進度的東西。現實：軟件項目的成果包含很多內容，文檔是成功開發的基礎，也是軟件質量的保證。好的開發質量降低了重復勞動，從而提高了效率，導致更短的交付時間。

一、軟件危機2）軟件神話[3]實踐者的神話

一、軟件危機2、軟件危機

3）軟件危機及主要表現軟件危機指在計算機軟件開發和維護過程中所遇到的一系列嚴重問題——軟件開發不能滿足日益增長的需求；難以維護不斷增長的已有軟件。[1]成本與進度的估計[2]用戶需求與產品不一致[3]軟件可靠性差[4]可維護性差[5]文檔資料不完整[6]軟件成本比例不斷上升[7]開發生產率相對停滯

一、軟件危機3）軟件危機及主要表現軟件危機指在計算機軟件開一、軟件危機2、軟件危機

3）軟件項目成敗的因素分析1）失敗項目的主要原因[1]用戶需求不完整、被誤解或經常變化[2]有限的用戶參與[3]缺少行政支持[4]缺少技術支持[5]項目計劃不充分[6]目標不明確[7]沒有足夠的資源（客戶沒有提供/開發者不具備相應生產力）2）成功項目的主要原因[1]大量的用戶參與[2]上層管理人員的支持[3]完整、詳細的項目計劃[4]符合實際的工作進度與里程碑[5]開發人員的培訓、交流[6]良好的工作環境、團隊協作機制一、軟件危機3）軟件項目成敗的因素分析1）失敗項目的主要原因一、軟件危機2、軟件危機

3）消除軟件危機的思路——[1]正確的觀念a)軟件不是程序軟件是邏輯產品而不是實物產品軟件的功能依賴于硬件和軟件的運行環境以及人們對它的操作軟件特征：功能的多樣性實現的多樣性能見度低軟件結構合理性差智力密集及知識產權保護b)軟件開發不是個體勞動軟件設計的復雜性一、軟件危機3）消除軟件危機的思路——[1]正確的觀念a)軟一、軟件危機2、軟件危機

3）消除軟件危機的思路——[2]正確的過程管理與控制軟件開發技術:軟件開發方法軟件開發過程軟件工具和軟件工程環境軟件工程管理:軟件管理軟件經濟軟件心理一、軟件危機3）消除軟件危機的思路——[2]正確的過程管理與二、軟件工程1、軟件工程將工程管理思想引入軟件開發過程：

轉變對軟件的認識：上升程序系統轉變思維定式：上升程序員系統工程師(系統分析員)

工程化訓練二、軟件工程轉變對軟件的認識：二、軟件工程1、軟件工程將工程管理思想引入軟件開發過程：

二、軟件工程用戶分析員程序員用戶分析員程序員“一個好的工業，應有一套

良好的標準來配套”軟件的工業化生產過程應具備的特點：明確的工作步驟詳細具體的規范化文檔明確的質量評價標準“一個好的工業，應有一套

良好的標準來配套”軟件的工業化生產軟件產品的標準化軟件開發過程的標準化軟件產品的標準化軟件開發過程的標準化

強調規范化強調文檔化軟件工程技術的兩個明顯特點：強調規范化軟件工程技術的兩個明顯特點：二、軟件工程1、軟件工程FritzBauer在NATO會議上給出的定義：“軟件工程是為了經濟地獲得可靠的和能在實際機器上高效運行的軟件而確立和使用的健全的工程原理（方法）。”

二、軟件工程二、軟件工程1、軟件工程IEEE【IEE83】給出的軟件工程定義：“軟件工程是開發、運行、維護和修復軟件的系統方法。”

二、軟件工程二、軟件工程1、軟件工程

IEEE【IEE93】給出了一個更加綜合的定義：“將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件中。”二、軟件工程二、軟件工程1、軟件工程

軟件工程是應用計算機科學、數學及管理科學等原理開發軟件的工程。它借鑒傳統工程的原則、方法，以提高質量，降低成本為目的。軟件工程所包含的內容不是一成不變的，而是隨著人們對軟件系統的研制開發和生產的理解不斷發展變化，應該用發展的眼光看待。二、軟件工程軟件工程所包含的內容不是一成不變的，而是隨著人們二、軟件工程1、軟件工程軟件工程是一種層次化的活動，a)質量——軟件工程的根基與目標b)過程——建造一個高質量軟件所需完成任務的框架c)方法——提供了如何建造軟件的技術手段d)工具——為過程和方法提供自動或半自動化的支持（CASE）二、軟件工程軟件工程是一種層次化的活動，a)質量——軟件工程工具方法過程質量焦點工具方法過程質量焦點二、軟件工程2、軟件工程一般視圖

工程：對技術（或社會）實體的分析、設計、構造、驗證和管理。首先要問題的問題： 要解決什么問題？ 實體的什么特征能解決這個問題？ 如何設計該實體？ 如何構建該實體？ 如何控制和避免構建過程中的錯誤？ 如何在用戶要求修改、適應和增強時長期地支持這些實體？定義階段：做什么開發階段：如何做支持階段：應對變化項目跟蹤與控制技術評審質量保證軟件配置管理文檔管理復用管理測試管理風險管理支持活動二、軟件工程工程：對技術（或社會）實體的分析、設計、構造、驗軟件工程框架可用性性性確正合算選取適宜的開發模型采用合適的設計方法提供高質量的工程支持重視軟件工程的管理基本過程原則

目標過

程支持過程組織過程軟件工程框架可用性性性確正合算選取適宜的開發模型采用合適的設軟件過程評估軟件能力成熟度CMM1-初始級：沒有過程定義，個人能力。2-可重復級：基本項目管理過程，跟蹤費用與進度，有必要的規范以重復類似項目的成功。3-