1、編輯編輯ppt1/ /實戰訓練實戰訓練第一部分第一部分 軟件工程軟件工程編輯編輯ppt2本講內容本講內容 1 1 軟件工程概述軟件工程概述 2 2 軟件工程過程和活動軟件工程過程和活動 3 3 軟件過程模型軟件過程模型 4 4 軟件過程成熟度模型軟件過程成熟度模型CMMCMM編輯編輯ppt31 軟件工程概述軟件工程概述 1.1 1.1 軟件的概念軟件的概念 1.2 1.2 為什么要軟件工程為什么要軟件工程 1.3 1.3 什么是軟件工程什么是軟件工程 1.4 1.4 參考書目參考書目編輯編輯ppt41.1 軟件的概念軟件的概念 定義定義Program + Data Structure + Do

2、cuments 軟件的性質軟件的性質復雜性復雜性難以描述性難以描述性不可見性不可見性變化性變化性易于副本的大批量生產易于副本的大批量生產強合作性強合作性編輯編輯ppt51.2 為什么要軟件工程為什么要軟件工程 軟件危機軟件危機爆發時間爆發時間 1967年年NATO的研究組首次提出的研究組首次提出 1968年年NATO軟件工程會議首次提出軟件工程軟件工程會議首次提出軟件工程概念概念 1968-2013, 近近40多年多年 “危機危機”一詞一詞軟件危機依然存在軟件危機依然存在Crisis！編輯編輯ppt61.2 為什么要軟件工程為什么要軟件工程 軟件危機面對的問題軟件危機面對的問題 藝術藝術 vs

3、. 標準化標準化 錯誤的發現錯誤的發現 軟件需求獲取軟件需求獲取 軟件支持和維護軟件支持和維護 開發速度開發速度 vs. 市場需求市場需求 開發周期過長、開發成本過高開發周期過長、開發成本過高 研發風險研發風險 軟件開發中的復雜的協作軟件開發中的復雜的協作(人員人員,問題問題,過程過程) 不同角色的軟件神話不同角色的軟件神話(管理者管理者,用戶用戶,開發者開發者,大眾大眾)編輯編輯ppt71.2 為什么要軟件工程為什么要軟件工程 采用什么方法緩解危機采用什么方法緩解危機硬件硬件 ?建筑學建筑學?拍電影拍電影? 軟件工程！軟件工程！編輯編輯ppt81.3 什么是軟件工程什么是軟件工程 Fritz

4、 Bauer: “建立和應用完善的工程原理以便經濟地得建立和應用完善的工程原理以便經濟地得到在真實機器上可靠和有效運行的軟件。到在真實機器上可靠和有效運行的軟件。特點：重原理、輕技術、無度量特點：重原理、輕技術、無度量 IEEE：(1)應用系統的有規則的定量的方法開發、應用系統的有規則的定量的方法開發、使用和維護軟件；即應用工程于軟件。使用和維護軟件；即應用工程于軟件。(2)研究研究(1)中的方法中的方法特點：粗糙特點：粗糙編輯編輯ppt91.3 什么是軟件工程什么是軟件工程 Definition軟件工程是以軟件工程是以質量質量為核心，為了經濟地開為核心，為了經濟地開發滿足發滿足客戶需求客戶需

5、求的軟件而研究、建立和應的軟件而研究、建立和應用的用的系統化系統化的、的、有規則有規則的、的、可度量可度量的和的和可可控制控制的工程原則、方法，涉及到的工程原則、方法，涉及到軟件過程、軟件過程、項目管理、開發方法、軟件復用、軟件度項目管理、開發方法、軟件復用、軟件度量、開發工具量、開發工具，甚至，甚至企業文化企業文化等各個方面。等各個方面。 編輯編輯ppt10 A Quality FocusProcessMethodsCASE Tools1.3 什么是軟件工程什么是軟件工程編輯編輯ppt111.4 軟件工程參考書目軟件工程參考書目編輯編輯ppt122 過程和活動過程和活動 2.1 軟件過程的概

6、念軟件過程的概念 2.2 問題定義活動問題定義活動 2.3 可行性研究活動可行性研究活動 2.4 需求分析活動需求分析活動 2.5 設計活動設計活動 2.6 實施活動實施活動 2.7 測試活動測試活動 2.8 部署活動部署活動編輯編輯ppt132.1 軟件過程的概念軟件過程的概念 軟件過程的定義軟件過程的定義軟件過程由開發或維護軟件及其相關產品軟件過程由開發或維護軟件及其相關產品的一系列的一系列活動活動構成，這些活動從不同的方構成，這些活動從不同的方面定義了軟件開發中的步驟、交付物、涉面定義了軟件開發中的步驟、交付物、涉眾及其職責等流程要素眾及其職責等流程要素 編輯編輯ppt142.1 軟件過

7、程的概念軟件過程的概念Build theSystem控制 預算,計劃表,標準輸入需求資源人員,工具輸出代碼,文檔Process控制/約束輸入資源輸出編輯編輯ppt152.1 軟件過程的概念軟件過程的概念WhatHowChange編輯編輯ppt162.1 軟件過程的概念軟件過程的概念編輯編輯ppt172.1 軟件過程的概念軟件過程的概念 Basic Activities(Basic Activities(基礎活動基礎活動) )問題定義，需求，設計，實問題定義，需求，設計，實b現，現，軟件驗證，集成，軟件演進軟件驗證，集成，軟件演進/維護，退役維護，退役 Umbrella Activities (

8、Umbrella Activities (輔助性活動輔助性活動) )軟件項目跟蹤和控制，正式的技術復審，軟件項目跟蹤和控制，正式的技術復審，軟件質量保證，軟件配置管理，文檔編制，軟件質量保證，軟件配置管理，文檔編制，復用管理，度量，風險管理，復用管理，度量，風險管理，Something that covers or protects. 保護物覆蓋或保護的事物編輯編輯ppt182.2 問題定義活動問題定義活動 What問題定義是軟件開發過程當中的一個定義問題定義是軟件開發過程當中的一個定義要解決的問題并確定系統范圍的活動。要解決的問題并確定系統范圍的活動。 Why形成一個早期判斷，達成一個最初共

9、識形成一個早期判斷，達成一個最初共識 When項目日程表的最前端項目日程表的最前端占整個軟件開發時間中的比例很小占整個軟件開發時間中的比例很小 編輯編輯ppt192.2 問題定義活動問題定義活動 Who系統分析師、出資方領導、出資方技術人系統分析師、出資方領導、出資方技術人員、開發方領導和項目經理員、開發方領導和項目經理 Where客戶現場客戶現場 編輯編輯ppt202.2 問題定義活動問題定義活動 How編輯編輯ppt212.3 可行性研究活動可行性研究活動 What可行性研究是以相對短的時間和相對低的可行性研究是以相對短的時間和相對低的成本來確定給定的問題在其約束條件內是成本來確定給定的問

10、題在其約束條件內是否有解、有幾種解以及哪個是最佳解。否有解、有幾種解以及哪個是最佳解。 Why必須要先確立滿足約束條件的方案是否存必須要先確立滿足約束條件的方案是否存在、是否可行、是否最優，然后再在最優在、是否可行、是否最優，然后再在最優方案的基礎上進行開發方案的基礎上進行開發 編輯編輯ppt222.3 可行性研究活動可行性研究活動 When 項目的早期階段項目的早期階段 占整個軟件開發時間中的比例較小，但比問題定占整個軟件開發時間中的比例較小，但比問題定義活動所消耗的時間長義活動所消耗的時間長 Who 系統分析師、出資方領導、出資方技術人員、用系統分析師、出資方領導、出資方技術人員、用戶代表

11、、開發方領導、項目經理、架構設計師、戶代表、開發方領導、項目經理、架構設計師、領域專家、財務人員、市場人員、軟件質量保證領域專家、財務人員、市場人員、軟件質量保證（SQA，Software Quality Assure）人員等）人員等 Where 客戶現場?？蛻衄F場。編輯編輯ppt232.3 可行性研究活動可行性研究活動 How How編輯編輯ppt242.4 需求分析活動需求分析活動 What需求：主要是在產品構建之前確定的系統需求：主要是在產品構建之前確定的系統必須符合的條件或具備的功能，它們是關必須符合的條件或具備的功能，它們是關于系統將要完成什么工作的一段描述語句，于系統將要完成什么工

12、作的一段描述語句，它們必須經過所有相關人員的認可，其目它們必須經過所有相關人員的認可，其目的是徹底地解決客戶的問題。的是徹底地解決客戶的問題。 需求文檔需求文檔 一組需求的集合一組需求的集合 用戶需求文檔、系統需求文檔和軟件規約文檔用戶需求文檔、系統需求文檔和軟件規約文檔 編輯編輯ppt252.4 需求分析活動需求分析活動功能性需求和非功能性需求功能性需求和非功能性需求 功能性需求：描述了系統應該做什么，即具備功能性需求：描述了系統應該做什么，即具備的功能或服務。（輸入、輸出和計算等）的功能或服務。（輸入、輸出和計算等） 非功能性需求：描述了系統必須遵守的約束條非功能性需求：描述了系統必須遵守

13、的約束條件。（響應時間、吞吐量件。（響應時間、吞吐量 、可靠性、可移植性、可靠性、可移植性、可擴展性、易用性、安全性、資源要求、可復可擴展性、易用性、安全性、資源要求、可復用性、技術要求、文化和政策需求、法律需求、用性、技術要求、文化和政策需求、法律需求、道德要求、隱私要求，等等）道德要求、隱私要求，等等） 描述需求的標準描述需求的標準 是完整的、正確的、必要的、無歧義的、可行是完整的、正確的、必要的、無歧義的、可行的、可驗證的以及被設置了優先級別的。的、可驗證的以及被設置了優先級別的。 What編輯編輯ppt262.4 需求分析活動需求分析活動 Why需求不一致、模糊、矛盾需求不一致、模糊、

14、矛盾需求變更需求變更客戶忽略領域常識客戶忽略領域常識/知識知識/術語術語 客戶集中于現有系統的不足之處，而忽略客戶集中于現有系統的不足之處，而忽略了系統要實現的關鍵功能了系統要實現的關鍵功能零碎、無組織、不明確、表達不清零碎、無組織、不明確、表達不清不分輕重緩急不分輕重緩急 編輯編輯ppt272.4 需求分析活動需求分析活動 When項目的早期階段？項目的早期階段？貫穿于整個軟件開發過程的需求活動貫穿于整個軟件開發過程的需求活動編輯編輯ppt282.4 需求分析活動需求分析活動 Who 系統分析師、需求闡釋者、客戶代表、用戶代表、系統分析師、需求闡釋者、客戶代表、用戶代表、開發方領導、項目經理

15、、架構設計師、領域專家、開發方領導、項目經理、架構設計師、領域專家、財務人員、市場人員、軟件質量保證（財務人員、市場人員、軟件質量保證（SQA，Software Quality Assure）人員、程序員、測試）人員、程序員、測試人員、部署人員、技術文檔編寫人員、培訓人員人員、部署人員、技術文檔編寫人員、培訓人員等。等。 Where 調研時，在客戶現場調研時，在客戶現場 編寫軟件需求規約文檔時，可以在開發單位編寫軟件需求規約文檔時，可以在開發單位 復審相關的需求文檔時，根據需要來安排復審相關的需求文檔時，根據需要來安排編輯編輯ppt292.4 需求分析活動需求分析活動 How網羅需求entry

16、/ 工作上下文范圍entry/ 領域知識和可重用的需求do/ 獲取涉眾的原始需求exit/ 建立原始需求記錄定義系統do/ 分析系統需求exit/ 制定軟件需求文檔exit/ 改進業務詞匯表管理系統規模do/ 分析需求優先級、工作量和風險等屬性exit/ 修訂系統開發計劃需求變更請求do/ 問題分析和變更描述exit/ 提交需求變更申請啟動需求do/ 確定需求的涉眾、范圍、目標和限制條件do/ 估算項目費用exit/ 達成一致意見 更多迭代 未通過復審 需求變更實現do/ 修改需求文檔do/ 修改設計文檔do/ 修改測試用例do/ 修改程序exit/ 評估變更結果 通過復審 who/系統分析師

17、、項目經理、客戶代表、開發方領導、財務人員等who/系統分析師、需求闡釋者、客戶代表、用戶等who/系統分析師、需求闡釋者等復審do/ 審查需求文檔exit/ 發布審查結論who/系統分析師、項目經理、客戶代表、用戶代表、領域專家、SQA人員等who/系統分析師、項目經理、領域專家、SQA人員等who/用戶代表、客戶代表、系統分析員、需求闡釋者等需求變更處理do/ 評估變更影響do/ 預算變更成本do/ 制定變更計劃do/ 審查exit/ 發布審查結論who/用戶代表、客戶代表、項目經理、系統分析師、架構設計師、軟件設計員、開發方領導、財務人員等who/系統分析師、需求闡釋者、項目經理、架構設

18、計師、軟件設計員、測試人員、實施員、SQA人員、用戶代表、客戶代表、財務人員、部署人員等 需求定義完成 未通過復審 通過復審 編輯編輯ppt302.5 設計活動設計活動 What 設計：設計： 是在系統的約束條件下（如預算、時間、人力是在系統的約束條件下（如預算、時間、人力資源、用戶軟、硬件環境和用戶對系統的操作資源、用戶軟、硬件環境和用戶對系統的操作能力等），為了實現系統的功能性需求和非功能力等），為了實現系統的功能性需求和非功能性需求，而找到并描述的一種遵循高質量的能性需求，而找到并描述的一種遵循高質量的通用原則的方法，其交付文檔能夠指導開發人通用原則的方法，其交付文檔能夠指導開發人員實現

19、系統。員實現系統。編輯編輯ppt312.5 設計活動設計活動 總體設計總體設計 根據軟件需求規約文檔，確定一個合理的軟件根據軟件需求規約文檔，確定一個合理的軟件體系結構。這個體系結構包括合理地劃分組成體系結構。這個體系結構包括合理地劃分組成系統的模塊、模塊間的調用關系以及模塊間的系統的模塊、模塊間的調用關系以及模塊間的接口關系。軟件體系結構還從總體方面決定了接口關系。軟件體系結構還從總體方面決定了系統的可擴充性、可維護性，以及系統的性能系統的可擴充性、可維護性，以及系統的性能等。總體設計的設計粒度較大，有時也被稱為等。總體設計的設計粒度較大，有時也被稱為概要設計、架構設計。概要設計、架構設計。

20、編輯編輯ppt322.5 設計活動設計活動詳細設計詳細設計 詳細設計地任務是在總體設計的基礎上進一步詳細設計地任務是在總體設計的基礎上進一步確定如何實現目標系統，包括系統的數據對象確定如何實現目標系統，包括系統的數據對象的設計、人機接口的設計以及模塊邏輯的詳細的設計、人機接口的設計以及模塊邏輯的詳細設計。設計。設計部件的粒度設計部件的粒度 系統、子系統、框架、構件、組件、模塊、類、系統、子系統、框架、構件、組件、模塊、類、方法等方法等編輯編輯ppt332.5 設計活動設計活動 Why軟件架構是軟件系統的核心軟件架構是軟件系統的核心應對復雜多變的情況，同時保持完整性應對復雜多變的情況，同時保持完

21、整性應對系統在擴展功能當中出現的問題應對系統在擴展功能當中出現的問題大規模復用的有效基礎大規模復用的有效基礎 項目管理的基礎項目管理的基礎 編輯編輯ppt342.5 設計活動設計活動 When項目的中、早期階段？項目的中、早期階段？工作量早期 中期 后期項目時間大小貫穿于整個軟件開發過程的設計活動貫穿于整個軟件開發過程的設計活動編輯編輯ppt352.5 設計活動設計活動 Who主要包括架構設計師、軟件設計員、復用主要包括架構設計師、軟件設計員、復用工程師、設計復審員、項目經理、財務人工程師、設計復審員、項目經理、財務人員、軟件質量保證（員、軟件質量保證（SQA，Software Quality

22、 Assure）人員和需求變更者等）人員和需求變更者等 Where建議在軟件企業內部進行設計建議在軟件企業內部進行設計 編輯編輯ppt362.5 設計活動設計活動 How定義架構草案entry/ 軟件需求規約文檔do/ 定義多個備選架構草案do/ 選擇最優架構草案exit/ 審查架構草案who/架構設計師、軟件設計員、項目經理、SQA人員、財務人員等改進架構do/ 考慮設計原則和架構模式do/ 分析設計元素do/ 分析元素間的關系和接口exit/ 修改設計模型設計專用構件設計數據庫設計可復用的框架或構件選擇可復用的框架或構件entry/ 軟件可復用資產庫do/ 查找符合條件的的框架和構件do/

23、 選擇適合的框架或構件修訂設計說明書do/ 修訂設計說明書exit/ 復審設計說明書 新的迭代或需求變更 架構設計早期who/架構設計師、復用工程師who/架構設計師、復用工程師、軟件設計員who/復用工程師、軟件設計員who/構件設計員who/數據庫設計員who/架構設計師、復用工程師、軟件設計員、項目經理、SQA人員、財務人員等 需要設計新的可復用框架或構件 開發專用構件 需要設計數據庫 找到合適的框架或構件 未通過復審 通過復審 未通過審查通過審查編輯編輯ppt372.6 實施活動實施活動 What編碼：是將軟件設計結果轉換成用某種程編碼：是將軟件設計結果轉換成用某種程序設計語言書寫的程

24、序。序設計語言書寫的程序。單元測試：是把一個模塊作為獨立的程序單元測試：是把一個模塊作為獨立的程序單元進行測試，以保證它能夠正確執行規單元進行測試，以保證它能夠正確執行規定的功能。定的功能。 集成：是指將單獨的軟件構件合并成一個集成：是指將單獨的軟件構件合并成一個整體的軟件系統。集成分為集成子系統和整體的軟件系統。集成分為集成子系統和集成系統兩個級別：集成系統兩個級別：編輯編輯ppt382.6 實施活動實施活動 Why以實施為中心的軟件開發以實施為中心的軟件開發 弱化的需求弱化的需求 弱化的設計弱化的設計 對實施人員的過度依賴對實施人員的過度依賴 編輯編輯ppt392.6 實施活動實施活動 W

25、hy將單元測試作為實施的一部分將單元測試作為實施的一部分 When項目的中、后期階段項目的中、后期階段 工作量早期 中期 后期項目時間大小貫穿于整個軟件開發過程的實施活動貫穿于整個軟件開發過程的實施活動編輯編輯ppt402.6 實施活動實施活動 Who包括實施員、代碼復審員、集成員、測試包括實施員、代碼復審員、集成員、測試工程師、測試員、項目經理、架構設計師、工程師、測試員、項目經理、架構設計師、軟件設計員、復用工程師、軟件設計員、復用工程師、SQA人員和財人員和財務人員等務人員等 Where建議在軟件企業內部進行開發建議在軟件企業內部進行開發 編輯編輯ppt412.6 實施活動實施活動 Ho

26、w制定計劃do/ 修訂實施計劃/集成測試/測試計劃/預算實施成本exit/ 審核計劃和預算who/架構設計師、軟件設計員、復用工程師、項目經理、實施員、集成員、測試工程師、測試員、SQA人員、財務人員等實施構件do/ 開發或改進構件do/ 制作測試驅動程序和樁模塊do/ 執行單元測試do/ 修訂集成計劃/測試計劃(方案)exit/ 復審代碼who/實施員、集成員、測試工程師、代碼復審員 未通過代碼復審 集成每個子系統do/ 將新建或變更構件集成到相關子系統中do/ 對集成的子系統進行測試who/集成員、測試員、測試工程師集成系統do/ 集成出新的工作版本do/ 集成測試who/集成員、測試員、

27、測試工程師迭代總結(實施)entry/ 實施的工作版本do/ 審查計劃執行情況/實施質量/實施成本who/項目經理、實施員、集成員、測試工程師、測試人員、架構設計師、軟件設計員、復用工程師、SQA人員、財務人員等未通過子系統測試 通過代碼復審 通過子系統測試 此次迭代中還有其它子系統未集成 已完成此次迭代中的子系統集成 此次迭代中還有子系統未被集成到工作版本 完成 未通過審核 通過審核 未通過集成測試 通過集成測試 此次迭代中還有其它構件未實施 已完成此次迭代中構件的實施 編輯編輯ppt422.7 測試活動測試活動 What 測試：是選擇適當的測試用例執行被測程序的過程，其目測試：是選擇適當的

28、測試用例執行被測程序的過程，其目的在于發現程序錯誤。的在于發現程序錯誤。 缺陷缺陷：是系統任一方面（包括需求、設計或代碼）的：是系統任一方面（包括需求、設計或代碼）的缺點。該缺點會促成或潛在的促成一個或多個失敗發缺點。該缺點會促成或潛在的促成一個或多個失敗發生。生。 錯誤錯誤：是指程序中的缺陷所產生的不正確結果。：是指程序中的缺陷所產生的不正確結果。 失敗失敗：當一個程序不能運行或者其表現不可被接受時：當一個程序不能運行或者其表現不可被接受時稱為失敗。失敗是系統執行中出現的情況。失敗源于稱為失敗。失敗是系統執行中出現的情況。失敗源于代碼缺陷。代碼缺陷。 單元測試、集成測試、系統測試、單元測試、

29、集成測試、系統測試、(alpha)(alpha)、(Beta)(Beta) 驗收測試驗收測試 編輯編輯ppt432.7 測試活動測試活動質量維度：描述質量的概念或評測質量的質量維度：描述質量的概念或評測質量的方法的不同視角方法的不同視角 可靠性維度可靠性維度 可用性維度可用性維度 性能維度性能維度測試用例：為特定目標開發的測試輸入、測試用例：為特定目標開發的測試輸入、執行條件和預期結果的集合。執行條件和預期結果的集合。 編輯編輯ppt442.7 測試活動測試活動 When項目的后期階段？項目的后期階段？優點 縮短測試時間縮短測試時間 易于定位缺陷易于定位缺陷 避免錯上加錯避免錯上加錯 工作量早

30、期 中期 后期項目時間大小編輯編輯ppt452.7 測試活動測試活動 Who主要包括測試工程師、測試員、軟件設計主要包括測試工程師、測試員、軟件設計員、實施員、項目經理、部署工程師、部員、實施員、項目經理、部署工程師、部署員、署員、SQA人員和財務人員等人員和財務人員等 Where建議單元測試、集成測試和系統測試在實建議單元測試、集成測試和系統測試在實施員所在的開發現場及其附近進行施員所在的開發現場及其附近進行測試和驗收測試則完全在用戶現場測試測試和驗收測試則完全在用戶現場測試 編輯編輯ppt462.7 測試活動測試活動 (5/5) How制定測試計劃entry/ 需求規約文檔/設計說明書/集

31、成構建計劃do/ 制定測試計劃do/ 設計測試用例和測試過程do/ 分析測試工作量，預算測試成本who/測試工程師、項目經理、SQA人員和財務人員實施測試do/ 設計/實現測試用的驅動程序和樁模塊do/ 測試構件和子系統who/軟件設計員、實施員 單元測試失敗 或還有其它單元測試未實施 集成測試 完成單元測試 who/測試員 完成集成測試 集成測試失敗 或還有其它迭代內集成測試未測 系統測試who/測試員 系統測試未通過 測試 通過 需要測試who/客戶和用戶測試不需要測試需要測試who/客戶、用戶、部署工程師和部署員 不需要測試 驗收測試 需要驗收測試 who/客戶、用戶、項目經理、部署工程

32、師和部署員評估測試do/ 提出系統變更請求do/ 制定/修訂測試評估報告who測試工程師迭代總結(測試)do/ 審查測試計劃執行情況/測試成本/測試質量who/測試工程師、測試員、軟件設計員、實施員、項目經理、SQA人員和財務人員等 不需要驗收測試 編輯編輯ppt472.8 部署活動部署活動 What部署：是為確保最終用戶可以正常使用軟部署：是為確保最終用戶可以正常使用軟件產品而進行的活動。件產品而進行的活動。 根據產品類型，可以將部署分為三種模式根據產品類型，可以將部署分為三種模式: : 自定義安裝模式自定義安裝模式 現場支持模式現場支持模式 InternetInternet模式模式 編輯編

33、輯ppt482.8 部署活動部署活動部署單元：由一個工作版本（可執行構件部署單元：由一個工作版本（可執行構件集）、文檔（最終用戶支持材料和發布說集）、文檔（最終用戶支持材料和發布說明）和安裝工件組成明）和安裝工件組成 部署計劃：說明如何將產品從開發商轉移部署計劃：說明如何將產品從開發商轉移到用戶群到用戶群 兼容、轉換和遷移策略兼容、轉換和遷移策略 部署時間表部署時間表 部署順序部署順序 用戶培訓用戶培訓 編輯編輯ppt492.8 部署活動部署活動 When項目的后期階段？項目的后期階段？工作量早期 中期 后期項目時間大小編輯編輯ppt502.8 部署活動部署活動 Who主要包括部署工程師、部署

34、員、文檔編寫員、包裝員、實施員、項目經理、SQA人員和財務人員等 Where一部分工作可以在開發現場進行，如制定部署計劃、包裝產品、編寫相關文檔等；另一部分工作必須在用戶現場進行，如測試、驗收測試和用戶正式使用中的安裝、培訓工作等。編輯編輯ppt512.8 部署活動部署活動 How計劃部署do/ 制定部署計劃do/ 定義材料清單who/部署工程師編寫支持材料who/文檔編寫員參與內部測試do/ 熟悉系統do/ 部署測試環境who/部署工程師、部署員生成部署單元do/ 編寫發布說明do/ 開發安裝工件who/部署工程師、軟件設計員和實施員測試的部署who/部署工程師、部署員驗收測試的部署who/

35、部署工程師、部署員包裝產品who/包裝員用戶正式使用的部署who/部署工程師、部署員 測試未通過 通過 需要測試 不需要測試 需要驗收測試 不需要驗收測試 需要正式部署 不需要正式部署 迭代總結(部署)do/ 審查部署計劃執行情況/部署成本/部署質量who/項目經理、部署工程師、部署員、文檔編寫員、包裝員、實施員、SQA人員和財務人員等編輯編輯ppt523 3 軟件過程模型軟件過程模型 3.1 3.1 過程模型概念過程模型概念 3.2 3.2 線形順序模型系列線形順序模型系列 3.3 3.3 演進模型系列演進模型系列 3.4 3.4 其它模型系列其它模型系列 3.5 3.5 過程模型的選擇過程

36、模型的選擇編輯編輯ppt533.1 過程模型概念過程模型概念 為什么需要模型為什么需要模型? ?模型幫助我們解釋事物模型幫助我們解釋事物如何工作如何工作模型能夠拓寬我們的視野模型能夠拓寬我們的視野( (抽象抽象) ) 軟件過程模型軟件過程模型一個過程模型是一個過程的抽象表示一個過程模型是一個過程的抽象表示過程模型幫助我們更好地理解軟件開發過程模型幫助我們更好地理解軟件開發編輯編輯ppt543.1 過程模型概念過程模型概念(2/5)編輯編輯ppt553.1 過程模型概念過程模型概念編輯編輯ppt563.1 過程模型概念過程模型概念編輯編輯ppt573.1 過程模型概念過程模型概念 經典模型經典模

37、型 Linear Sequential Model Waterfall Model V Model Department of Defense Model RAD Model Prototyping Model Build-and-Fix Model Incremental Model Spiral Model Concurrent Development Model XP Model RUP Model編輯編輯ppt583.2 線形順序模型系列線形順序模型系列 線性順序模型線性順序模型analysisdesigncodetestSystem/informationengineering編輯編

38、輯ppt593.2 線形順序模型系列線形順序模型系列 瀑布模型瀑布模型編輯編輯ppt60 特征特征接受上一階段的結果作為本階段的輸入接受上一階段的結果作為本階段的輸入開發階段嚴格按線性方式進行開發階段嚴格按線性方式進行對本階段的工作進行評審對本階段的工作進行評審每一階段具有相關的里程碑和交付產品每一階段具有相關的里程碑和交付產品 缺點缺點缺乏靈活性，難以適應需求不明確或需求經常變化的缺乏靈活性，難以適應需求不明確或需求經常變化的軟件開發軟件開發開發早期存在的問題往往要到交付使用時才發現，維開發早期存在的問題往往要到交付使用時才發現，維護代價大護代價大 適用適用在開發的早期階段軟件需求被完整確定

39、在開發的早期階段軟件需求被完整確定3.2 3.2 線形順序模型系列線形順序模型系列編輯編輯ppt61實際使用的瀑布模型實際使用的瀑布模型3.2 3.2 線形順序模型系列線形順序模型系列編輯編輯ppt623.2 線形順序模型系列線形順序模型系列 V V 模型模型REQUIREMENTSANALYSISSYSTEMDESIGNPROGRAMDESIGNCODINGUNIT & INTE-GRATION TESTINGSYSTEMTESTINGACCEPTANCETESTINGOPERATION& MAINTENANCEVerify designValidate requiremen

40、ts編輯編輯ppt633.2 線形順序模型系列線形順序模型系列 RAD (Rapid Application Development)RAD (Rapid Application Development)模型模型60 90 days編輯編輯ppt643.3 演進模型系列演進模型系列 原型模型原型模型Listen to customerbuild/revisemock-upcustomer test-drives mock-up編輯編輯ppt653.3 演進模型系列演進模型系列 邊建邊改邊建邊改 ModelModelBuild first versionModify until client i

41、s satisfiedMaintenancephaseRetirementDevelopmentMaintenance編輯編輯ppt663.3 演進模型系列演進模型系列 邊建邊改邊建邊改 Model(Model(續續) )編輯編輯ppt673.3 演進模型系列演進模型系列 增量模型增量模型System/InformationengineeringanalysisdesignCodeTest增量一增量一交付交付1analysisdesignCodetest增量二增量二analysisdesignCodetest增量三增量三analysisdesignCodetest增量四增量四Calendar

42、Time交付交付2交付交付3交付交付5編輯編輯ppt683.3 演進模型系列演進模型系列CustomerCommunicationRisk AnalysisEngineeringConstruction & ReleasePlanningCustomerEvaluationProject entryPoint axis 螺旋模型螺旋模型編輯編輯ppt693.3 演進模型系列演進模型系列 XP XP 模型，一種敏捷開發方法模型，一種敏捷開發方法編輯編輯ppt703.4 其它模型系列其它模型系列 構件組裝模型構件組裝模型與瀑布模型對比與瀑布模型對比編輯編輯ppt713.4 其它模型系列其它

43、模型系列應用構件提取車間構件生產車間標準規范 與 質量保證1基礎構件，2功能構件 3接口構件，4用戶界面構件 應用構件庫 構件庫組裝車間領域 1領域 2應用系統 . .1 12 23 34 4編輯編輯ppt72各種模型的比較各種模型的比較模型模型優點優點缺點缺點瀑布模型瀑布模型規范，文檔驅動規范，文檔驅動系統可能不滿足客系統可能不滿足客戶真正的需求戶真正的需求快速原型快速原型克服了瀑布型的缺點克服了瀑布型的缺點增量模型增量模型開發早期回報明確，開發早期回報明確，易于維護易于維護要求開放的軟件體要求開放的軟件體系結構系結構螺旋模型螺旋模型風險驅動，適用于大風險驅動，適用于大型項目開發型項目開發風

44、險分析人員需要風險分析人員需要有經驗且經過充分有經驗且經過充分訓練訓練編輯編輯ppt733.5 過程模型的選擇過程模型的選擇 軟件工程過程模型的選擇是基于軟件工程過程模型的選擇是基于: :項目的應用特點項目的應用特點采用的方法和工具采用的方法和工具需要的控制需要的控制交付的產品交付的產品編輯編輯ppt743.5 過程模型總結過程模型總結u在前期需求明確，盡量采用在前期需求明確，盡量采用瀑布模型瀑布模型u用戶沒有信息系統使用經驗，需求分析人員技能不足，采用戶沒有信息系統使用經驗，需求分析人員技能不足，采用用原型原型u不確定因素很多，無法一下子計劃，采用增量或螺旋不確定因素很多，無法一下子計劃，采

45、用增量或螺旋u需求不穩定，采用需求不穩定，采用增量增量u資金和成本無法一次到位，采用資金和成本無法一次到位，采用增量增量u可以各種模型可以各種模型合并使用合并使用，但每一次必須要有明確的交付物，但每一次必須要有明確的交付物和出口準則和出口準則u編程人員經驗較少，不宜采用編程人員經驗較少，不宜采用快速快速的方法的方法編輯編輯ppt754 4 軟件過程能力成熟度軟件過程能力成熟度編輯編輯ppt764 4 能力成熟度模型能力成熟度模型CMMCMM CMMCMM（Capability Maturity ModelCapability Maturity Model）即能力成）即能力成熟度模型，是美國卡耐

46、基梅隆大學軟件工程研究所熟度模型，是美國卡耐基梅隆大學軟件工程研究所（SEISEI）建立的，）建立的，用于評價軟件機構的軟件過程能力用于評價軟件機構的軟件過程能力成熟度的模型成熟度的模型。 此模型建立之初的主要目的在于提供一種評此模型建立之初的主要目的在于提供一種評價軟件承接方能力的方法，為大型軟件項目的招投價軟件承接方能力的方法，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據。而發展到標活動提供一種全面而客觀的評審依據。而發展到后來，又同時后來，又同時被軟件組織用于改進其軟件過程被軟件組織用于改進其軟件過程。編輯編輯ppt77軟件組織的成熟與不成熟軟件組織的成熟與不成熟不成熟的軟件組

47、織不成熟的軟件組織 軟件過程一般并不預先計劃，而是在項目進行中由實際軟件過程一般并不預先計劃，而是在項目進行中由實際工作人員及管理員臨時計劃工作人員及管理員臨時計劃 有時，即使軟件過程已計劃好，仍不按計劃執行有時，即使軟件過程已計劃好，仍不按計劃執行 沒有一個客觀的基準來判斷產品質量，或解決產品和過沒有一個客觀的基準來判斷產品質量，或解決產品和過程中的問題程中的問題 對軟件過程步驟如何影響軟件質量，一無所知，產品質對軟件過程步驟如何影響軟件質量，一無所知，產品質量得不到保證。而且，一些提高質量的環節，如檢查、量得不到保證。而且，一些提高質量的環節，如檢查、測試等經常由于要趕進度而減少或取消測試

48、等經常由于要趕進度而減少或取消4 4 能力成熟度模型能力成熟度模型CMMCMM編輯編輯ppt78 產品在交付前，對客戶來說，一切都是不可見的產品在交付前，對客戶來說，一切都是不可見的 沒有長遠目標，管理員通常只關注解決任何當前的危機沒有長遠目標，管理員通常只關注解決任何當前的危機 由于沒有實事求是地估計進度、預算，因此他們經常超由于沒有實事求是地估計進度、預算，因此他們經常超支、超時。當最后期限臨近，他們往往在功能性和質量支、超時。當最后期限臨近，他們往往在功能性和質量上妥協，或以加班加點方式趕進度上妥協，或以加班加點方式趕進度4 4 能力成熟度模型能力成熟度模型CMMCMM編輯編輯ppt79

49、2.2.成熟的軟件組織成熟的軟件組織 具有全面而充分的組織和管理軟件開發和維護過程的能力具有全面而充分的組織和管理軟件開發和維護過程的能力 管理員監視軟件產品的質量以及生產這些產品的過程。管理員監視軟件產品的質量以及生產這些產品的過程。 制定了一系列客觀基準來判別產品質量，并分析產品和過制定了一系列客觀基準來判別產品質量，并分析產品和過程中的問題。程中的問題。 進度和預算可以按照以前積累的經驗來制定，結果可行。進度和預算可以按照以前積累的經驗來制定，結果可行。預期的成本、進度、功能與性能和質量都能實現，并達到預期的成本、進度、功能與性能和質量都能實現，并達到目的。目的。4 4 能力成熟度模型能

50、力成熟度模型CMMCMM編輯編輯ppt80 能準確及時地向工作人員通報實際軟件過程，并按照計劃能準確及時地向工作人員通報實際軟件過程，并按照計劃有規則地有規則地( (前后一致，不互相矛盾前后一致，不互相矛盾) )工作工作 凡規定的過程都編成文檔凡規定的過程都編成文檔 軟件過程和實際工作方法相吻合。必要時，過程定義會及軟件過程和實際工作方法相吻合。必要時，過程定義會及時更新，通過測試，或者通過成本時更新，通過測試，或者通過成本- -效益分析來改進過程。效益分析來改進過程。 全體人員普遍地、積極地參與改進軟件過程的活動。在組全體人員普遍地、積極地參與改進軟件過程的活動。在組織內部的各項目中，每人在

51、軟件過程中的職責都十分清晰織內部的各項目中，每人在軟件過程中的職責都十分清晰而明確，各守其責，協同工作，有條不紊，甚至能預見和而明確，各守其責，協同工作，有條不紊，甚至能預見和防范問題的發生。防范問題的發生。4 4 能力成熟度模型能力成熟度模型CMMCMM編輯編輯ppt81CMMCMM的組成的組成 成熟度級別成熟度級別 關鍵過程域關鍵過程域 共同特性共同特性 關鍵實踐關鍵實踐 過程能力過程能力 目目 標標 實施或制度化實施或制度化 活動或基礎設施活動或基礎設施 表明表明 實現實現 解決解決 描述描述 5 個個 包含包含 劃分為劃分為 包含包含 4 4 能力成熟度模型能力成熟度模型CMMCMM編

52、輯編輯ppt825.5.優化級優化級4.4.已管理級已管理級3.3.已定義級已定義級2.2.可重復級可重復級1.1.初始級初始級標 準 、 一標 準 、 一致的過程致的過程有紀律有紀律的過程的過程可預測的過程可預測的過程持續改進的過程持續改進的過程軟件過程成熟軟件過程成熟度的度的5 5個等級個等級4 4 能力成熟度模型能力成熟度模型CMMCMM編輯編輯ppt83 CMM CMM提供了一個成熟度等級框架：提供了一個成熟度等級框架：1 1級級- -初始級、初始級、2 2級級- -可重可重復級、復級、3 3級級- -已定義級、已定義級、4 4級級- -已管理級和已管理級和5 5級級- -優化級。優化

53、級。 1.1.初始（初始（initialinitial）級：）級： 軟件過程的特點是無秩序的，甚至是混亂的。幾乎沒軟件過程的特點是無秩序的，甚至是混亂的。幾乎沒有什么過程是經過妥善定義的，成功往往依賴于個人或小有什么過程是經過妥善定義的，成功往往依賴于個人或小組的努力。組的努力。 2.2.可重復（可重復（repeatablerepeatable）級：）級： 建立了基本的項目管理過程來跟蹤成本、進度和功能建立了基本的項目管理過程來跟蹤成本、進度和功能特性。制定了必要的過程紀律，能重復早先類似應用項目特性。制定了必要的過程紀律，能重復早先類似應用項目取得的成功。取得的成功。4 4 能力成熟度模型能

54、力成熟度模型CMMCMM編輯編輯ppt84 3. 3.已定義（已定義（defineddefined）級：）級： 己將管理和工程活動兩方面的軟件過程文檔化、標己將管理和工程活動兩方面的軟件過程文檔化、標準化，并綜合成該機構的標準軟件過程。所有項目均使準化，并綜合成該機構的標準軟件過程。所有項目均使用經批準、剪裁的標準軟件過程來開發和維護軟件。用經批準、剪裁的標準軟件過程來開發和維護軟件。 4.4.已管理（已管理（managedmanaged）級：）級： 收集對軟件過程和產品質量的詳細度量值，對軟件過收集對軟件過程和產品質量的詳細度量值，對軟件過程和產品都有定量的理解和控制。程和產品都有定量的理解

55、和控制。 5.5.優化（優化（optimizingoptimizing）級：）級： 整個組織關注軟件過程改進的持續性、預見及增強自整個組織關注軟件過程改進的持續性、預見及增強自身，防止缺陷及問題的發生。過程的量化反饋和先進的身，防止缺陷及問題的發生。過程的量化反饋和先進的新思想、新技術促使過程不斷改進。新思想、新技術促使過程不斷改進。4 4 能力成熟度模型能力成熟度模型CMMCMM編輯編輯ppt85 成熟度等級成熟度等級表明了一個軟件組織的過程能表明了一個軟件組織的過程能力的水平。除初始級外，每個成熟度等級力的水平。除初始級外，每個成熟度等級都包含若干個關鍵過程域（都包含若干個關鍵過程域（Ke

56、y Process Key Process AreaArea，簡稱，簡稱KPAKPA）達到某個成熟度級別，該級別（以及較低達到某個成熟度級別，該級別（以及較低級別）的所有關鍵過程域都必須得到滿足，級別）的所有關鍵過程域都必須得到滿足，并且過程必須實現制度化。并且過程必須實現制度化。4 4 能力成熟度模型能力成熟度模型CMMCMM編輯編輯ppt86缺陷預防、技術更新缺陷預防、技術更新管理、過程更改管理管理、過程更改管理定量過程管理定量過程管理軟件質量管理軟件質量管理機構過程焦點、機構過程機構過程焦點、機構過程定義、培訓大綱、綜合軟定義、培訓大綱、綜合軟件管理、軟件產品工程、件管理、軟件產品工程、

57、組間協調、同行評審組間協調、同行評審需求管理、軟件項目計劃需求管理、軟件項目計劃、軟件項目跟蹤和監督、軟件項目跟蹤和監督、軟件分包合同管理、軟件軟件分包合同管理、軟件質量保證、軟件配置管理質量保證、軟件配置管理能力成熟度級能力成熟度級別中的關鍵過別中的關鍵過程域程域18個個優化級優化級已管理級已管理級已定義級已定義級可重復級可重復級初始級初始級4 4 能力成熟度模型能力成熟度模型CMMCMM6個個7個個2個個3個個編輯編輯ppt87能力成熟度模型集成能力成熟度模型集成CMMICMMICapability Maturity Model IntegrationCapability Maturity

58、 Model IntegrationCMMCMM的成功導致了各種模型的衍生，每一種模的成功導致了各種模型的衍生，每一種模型都探討了某一特定領域中的過程改進問題型都探討了某一特定領域中的過程改進問題SW-CMMSW-CMM：適用于軟件開發：適用于軟件開發SE-CMMSE-CMM：系統工程能力成熟度模型：系統工程能力成熟度模型SA-CMMSA-CMM：適用于軟件獲?。哼m用于軟件獲取SECAMSECAM：系統工程能力評估模型：系統工程能力評估模型People CMMPeople CMM：討論軟件組織吸引、開發、激勵、組織：討論軟件組織吸引、開發、激勵、組織和留住人才的能力和留住人才的能力EIA/IS

59、 731EIA/IS 731：替代：替代SW-CMMSW-CMM和和SECAMSECAMIPD-CMMIPD-CMM：適用于集成化產品開發：適用于集成化產品開發FAA-CMMFAA-CMM：集成了：集成了SE-CMMSE-CMM、 SA-CMMSA-CMM、 SW-CMMSW-CMM編輯編輯ppt88 相應的國際標準：相應的國際標準： ISO/IEC 12207ISO/IEC 12207（軟件生存周期過程）（軟件生存周期過程） ISO/IEC 15288ISO/IEC 15288（系統生存周期過程）（系統生存周期過程） ISO/IEC 15504ISO/IEC 15504（軟件過程評估）（軟件

60、過程評估） 模型的繁衍導致模型框架、術語等方面的矛盾和不一致模型的繁衍導致模型框架、術語等方面的矛盾和不一致 包含在當代工程中各種各樣的學科和工程是密切交叉在一包含在當代工程中各種各樣的學科和工程是密切交叉在一起的，應用不同模型時效率低下且容易混淆，常常要付出起的，應用不同模型時效率低下且容易混淆，常常要付出極其昂貴的代價極其昂貴的代價 美國國防部、美國國防工業委員會和美國國防部、美國國防工業委員會和SEI/CMUSEI/CMU于于19981998年啟年啟動動CMMICMMI項目，希望項目，希望CMMICMMI是若干過程模型的綜合和改進，是是若干過程模型的綜合和改進，是支持多個工程學科和領域的系統的、一致的過程改進