軟件項(xiàng)目開發(fā)的課件

1、1項(xiàng)目模擬/實(shí)戰(zhàn)訓(xùn)練第一部分 軟件工程2本講內(nèi)容1軟件工程概述2軟件工程過程和活動(dòng)3軟件過程模型4 軟件過程成熟度模型CMM31 軟件工程概述1.1 軟件的概念1.2 為什么要軟件工程1.3 什么是軟件工程1.4 參考書目41.1 軟件的概念定義Program + Data Structure + Documents 軟件的性質(zhì)復(fù)雜性難以描述性不可見性變化性易于副本的大批量生產(chǎn)強(qiáng)合作性51.2 為什么要軟件工程軟件危機(jī)爆發(fā)時(shí)間1967年NATO的研究組首次提出1968年NATO軟件工程會(huì)議首次提出軟件工程概念1968-2013, 近40多年“危機(jī)”一詞軟件危機(jī)依然存在Crisis！61.2 為

2、什么要軟件工程軟件危機(jī)面對(duì)的問題藝術(shù) vs. 標(biāo)準(zhǔn)化錯(cuò)誤的發(fā)現(xiàn)軟件需求獲取軟件支持和維護(hù)開發(fā)速度 vs. 市場(chǎng)需求開發(fā)周期過長(zhǎng)、開發(fā)成本過高研發(fā)風(fēng)險(xiǎn)軟件開發(fā)中的復(fù)雜的協(xié)作(人員,問題,過程)不同角色的軟件神話(管理者,用戶,開發(fā)者,大眾)71.2 為什么要軟件工程采用什么方法緩解危機(jī)硬件 ?建筑學(xué)?拍電影?軟件工程！81.3 什么是軟件工程Fritz Bauer:“建立和應(yīng)用完善的工程原理以便經(jīng)濟(jì)地得到在真實(shí)機(jī)器上可靠和有效運(yùn)行的軟件。特點(diǎn)：重原理、輕技術(shù)、無(wú)度量IEEE：(1)應(yīng)用系統(tǒng)的有規(guī)則的定量的方法開發(fā)、使用和維護(hù)軟件；即應(yīng)用工程于軟件。(2)研究(1)中的方法特點(diǎn)：粗糙91.3 什么

3、是軟件工程Definition軟件工程是以質(zhì)量為核心，為了經(jīng)濟(jì)地開發(fā)滿足客戶需求的軟件而研究、建立和應(yīng)用的系統(tǒng)化的、有規(guī)則的、可度量的和可控制的工程原則、方法，涉及到軟件過程、項(xiàng)目管理、開發(fā)方法、軟件復(fù)用、軟件度量、開發(fā)工具，甚至企業(yè)文化等各個(gè)方面。 10 A Quality FocusProcessMethodsCASE Tools1.3 什么是軟件工程111.4 軟件工程參考書目122 過程和活動(dòng)2.1 軟件過程的概念2.2 問題定義活動(dòng)2.3 可行性研究活動(dòng)2.4 需求分析活動(dòng)2.5 設(shè)計(jì)活動(dòng)2.6 實(shí)施活動(dòng)2.7 測(cè)試活動(dòng)2.8 部署活動(dòng)132.1 軟件過程的概念軟件過程的定義軟件過程

4、由開發(fā)或維護(hù)軟件及其相關(guān)產(chǎn)品的一系列活動(dòng)構(gòu)成，這些活動(dòng)從不同的方面定義了軟件開發(fā)中的步驟、交付物、涉眾及其職責(zé)等流程要素 142.1 軟件過程的概念Build theSystem控制 預(yù)算,計(jì)劃表,標(biāo)準(zhǔn)輸入需求資源人員,工具輸出代碼,文檔Process控制/約束輸入資源輸出152.1 軟件過程的概念WhatHowChange162.1 軟件過程的概念172.1 軟件過程的概念Basic Activities(基礎(chǔ)活動(dòng))問題定義，需求，設(shè)計(jì)，實(shí)b現(xiàn)，軟件驗(yàn)證，集成，軟件演進(jìn)/維護(hù)，退役Umbrella Activities (輔助性活動(dòng))軟件項(xiàng)目跟蹤和控制，正式的技術(shù)復(fù)審，軟件質(zhì)量保證，軟件配置

5、管理，文檔編制，復(fù)用管理，度量，風(fēng)險(xiǎn)管理，Something that covers or protects. 保護(hù)物覆蓋或保護(hù)的事物182.2 問題定義活動(dòng)What問題定義是軟件開發(fā)過程當(dāng)中的一個(gè)定義要解決的問題并確定系統(tǒng)范圍的活動(dòng)。Why形成一個(gè)早期判斷，達(dá)成一個(gè)最初共識(shí) When項(xiàng)目日程表的最前端占整個(gè)軟件開發(fā)時(shí)間中的比例很小 192.2 問題定義活動(dòng)Who系統(tǒng)分析師、出資方領(lǐng)導(dǎo)、出資方技術(shù)人員、開發(fā)方領(lǐng)導(dǎo)和項(xiàng)目經(jīng)理 Where客戶現(xiàn)場(chǎng) 202.2 問題定義活動(dòng)How212.3 可行性研究活動(dòng)What可行性研究是以相對(duì)短的時(shí)間和相對(duì)低的成本來確定給定的問題在其約束條件內(nèi)是否有解、有幾種解

6、以及哪個(gè)是最佳解。 Why必須要先確立滿足約束條件的方案是否存在、是否可行、是否最優(yōu)，然后再在最優(yōu)方案的基礎(chǔ)上進(jìn)行開發(fā) 222.3 可行性研究活動(dòng)When項(xiàng)目的早期階段占整個(gè)軟件開發(fā)時(shí)間中的比例較小，但比問題定義活動(dòng)所消耗的時(shí)間長(zhǎng)Who系統(tǒng)分析師、出資方領(lǐng)導(dǎo)、出資方技術(shù)人員、用戶代表、開發(fā)方領(lǐng)導(dǎo)、項(xiàng)目經(jīng)理、架構(gòu)設(shè)計(jì)師、領(lǐng)域?qū)＜?、?cái)務(wù)人員、市場(chǎng)人員、軟件質(zhì)量保證（SQA，Software Quality Assure）人員等Where客戶現(xiàn)場(chǎng)。232.3 可行性研究活動(dòng)HowHow242.4 需求分析活動(dòng)What需求：主要是在產(chǎn)品構(gòu)建之前確定的系統(tǒng)必須符合的條件或具備的功能，它們是關(guān)于系統(tǒng)將要完

7、成什么工作的一段描述語(yǔ)句，它們必須經(jīng)過所有相關(guān)人員的認(rèn)可，其目的是徹底地解決客戶的問題。 需求文檔一組需求的集合 用戶需求文檔、系統(tǒng)需求文檔和軟件規(guī)約文檔 252.4 需求分析活動(dòng)功能性需求和非功能性需求 功能性需求：描述了系統(tǒng)應(yīng)該做什么，即具備的功能或服務(wù)。（輸入、輸出和計(jì)算等）非功能性需求：描述了系統(tǒng)必須遵守的約束條件。（響應(yīng)時(shí)間、吞吐量 、可靠性、可移植性、可擴(kuò)展性、易用性、安全性、資源要求、可復(fù)用性、技術(shù)要求、文化和政策需求、法律需求、道德要求、隱私要求，等等） 描述需求的標(biāo)準(zhǔn)是完整的、正確的、必要的、無(wú)歧義的、可行的、可驗(yàn)證的以及被設(shè)置了優(yōu)先級(jí)別的。 What262.4 需求分析活動(dòng)

8、Why需求不一致、模糊、矛盾需求變更客戶忽略領(lǐng)域常識(shí)/知識(shí)/術(shù)語(yǔ) 客戶集中于現(xiàn)有系統(tǒng)的不足之處，而忽略了系統(tǒng)要實(shí)現(xiàn)的關(guān)鍵功能零碎、無(wú)組織、不明確、表達(dá)不清不分輕重緩急 272.4 需求分析活動(dòng)When項(xiàng)目的早期階段？貫穿于整個(gè)軟件開發(fā)過程的需求活動(dòng)282.4 需求分析活動(dòng)Who系統(tǒng)分析師、需求闡釋者、客戶代表、用戶代表、開發(fā)方領(lǐng)導(dǎo)、項(xiàng)目經(jīng)理、架構(gòu)設(shè)計(jì)師、領(lǐng)域?qū)＜摇⒇?cái)務(wù)人員、市場(chǎng)人員、軟件質(zhì)量保證（SQA，Software Quality Assure）人員、程序員、測(cè)試人員、部署人員、技術(shù)文檔編寫人員、培訓(xùn)人員等。Where調(diào)研時(shí)，在客戶現(xiàn)場(chǎng)編寫軟件需求規(guī)約文檔時(shí)，可以在開發(fā)單位復(fù)審相關(guān)的需求

9、文檔時(shí)，根據(jù)需要來安排292.4 需求分析活動(dòng)How302.5 設(shè)計(jì)活動(dòng) What 設(shè)計(jì)：是在系統(tǒng)的約束條件下（如預(yù)算、時(shí)間、人力資源、用戶軟、硬件環(huán)境和用戶對(duì)系統(tǒng)的操作能力等），為了實(shí)現(xiàn)系統(tǒng)的功能性需求和非功能性需求，而找到并描述的一種遵循高質(zhì)量的通用原則的方法，其交付文檔能夠指導(dǎo)開發(fā)人員實(shí)現(xiàn)系統(tǒng)。312.5 設(shè)計(jì)活動(dòng) 總體設(shè)計(jì)根據(jù)軟件需求規(guī)約文檔，確定一個(gè)合理的軟件體系結(jié)構(gòu)。這個(gè)體系結(jié)構(gòu)包括合理地劃分組成系統(tǒng)的模塊、模塊間的調(diào)用關(guān)系以及模塊間的接口關(guān)系。軟件體系結(jié)構(gòu)還從總體方面決定了系統(tǒng)的可擴(kuò)充性、可維護(hù)性，以及系統(tǒng)的性能等?？傮w設(shè)計(jì)的設(shè)計(jì)粒度較大，有時(shí)也被稱為概要設(shè)計(jì)、架構(gòu)設(shè)計(jì)。322.

10、5 設(shè)計(jì)活動(dòng)詳細(xì)設(shè)計(jì) 詳細(xì)設(shè)計(jì)地任務(wù)是在總體設(shè)計(jì)的基礎(chǔ)上進(jìn)一步確定如何實(shí)現(xiàn)目標(biāo)系統(tǒng)，包括系統(tǒng)的數(shù)據(jù)對(duì)象的設(shè)計(jì)、人機(jī)接口的設(shè)計(jì)以及模塊邏輯的詳細(xì)設(shè)計(jì)。設(shè)計(jì)部件的粒度系統(tǒng)、子系統(tǒng)、框架、構(gòu)件、組件、模塊、類、方法等332.5 設(shè)計(jì)活動(dòng)Why軟件架構(gòu)是軟件系統(tǒng)的核心應(yīng)對(duì)復(fù)雜多變的情況，同時(shí)保持完整性應(yīng)對(duì)系統(tǒng)在擴(kuò)展功能當(dāng)中出現(xiàn)的問題大規(guī)模復(fù)用的有效基礎(chǔ) 項(xiàng)目管理的基礎(chǔ) 342.5 設(shè)計(jì)活動(dòng)When項(xiàng)目的中、早期階段？工作量早期 中期 后期項(xiàng)目時(shí)間大小貫穿于整個(gè)軟件開發(fā)過程的設(shè)計(jì)活動(dòng)352.5 設(shè)計(jì)活動(dòng)Who主要包括架構(gòu)設(shè)計(jì)師、軟件設(shè)計(jì)員、復(fù)用工程師、設(shè)計(jì)復(fù)審員、項(xiàng)目經(jīng)理、財(cái)務(wù)人員、軟件質(zhì)量保證（SQA

11、，Software Quality Assure）人員和需求變更者等Where建議在軟件企業(yè)內(nèi)部進(jìn)行設(shè)計(jì) 362.5 設(shè)計(jì)活動(dòng)How372.6 實(shí)施活動(dòng)What編碼：是將軟件設(shè)計(jì)結(jié)果轉(zhuǎn)換成用某種程序設(shè)計(jì)語(yǔ)言書寫的程序。單元測(cè)試：是把一個(gè)模塊作為獨(dú)立的程序單元進(jìn)行測(cè)試，以保證它能夠正確執(zhí)行規(guī)定的功能。 集成：是指將單獨(dú)的軟件構(gòu)件合并成一個(gè)整體的軟件系統(tǒng)。集成分為集成子系統(tǒng)和集成系統(tǒng)兩個(gè)級(jí)別：382.6 實(shí)施活動(dòng)Why以實(shí)施為中心的軟件開發(fā)弱化的需求 弱化的設(shè)計(jì) 對(duì)實(shí)施人員的過度依賴 392.6 實(shí)施活動(dòng)Why將單元測(cè)試作為實(shí)施的一部分When項(xiàng)目的中、后期階段 工作量早期 中期 后期項(xiàng)目時(shí)間大小

12、貫穿于整個(gè)軟件開發(fā)過程的實(shí)施活動(dòng)402.6 實(shí)施活動(dòng)Who包括實(shí)施員、代碼復(fù)審員、集成員、測(cè)試工程師、測(cè)試員、項(xiàng)目經(jīng)理、架構(gòu)設(shè)計(jì)師、軟件設(shè)計(jì)員、復(fù)用工程師、SQA人員和財(cái)務(wù)人員等Where建議在軟件企業(yè)內(nèi)部進(jìn)行開發(fā) 412.6 實(shí)施活動(dòng)How422.7 測(cè)試活動(dòng)What測(cè)試：是選擇適當(dāng)?shù)臏y(cè)試用例執(zhí)行被測(cè)程序的過程，其目的在于發(fā)現(xiàn)程序錯(cuò)誤。 缺陷：是系統(tǒng)任一方面（包括需求、設(shè)計(jì)或代碼）的缺點(diǎn)。該缺點(diǎn)會(huì)促成或潛在的促成一個(gè)或多個(gè)失敗發(fā)生。錯(cuò)誤：是指程序中的缺陷所產(chǎn)生的不正確結(jié)果。失敗：當(dāng)一個(gè)程序不能運(yùn)行或者其表現(xiàn)不可被接受時(shí)稱為失敗。失敗是系統(tǒng)執(zhí)行中出現(xiàn)的情況。失敗源于代碼缺陷。單元測(cè)試、集成測(cè)試

13、、系統(tǒng)測(cè)試、(alpha)、(Beta) 驗(yàn)收測(cè)試 432.7 測(cè)試活動(dòng)質(zhì)量維度：描述質(zhì)量的概念或評(píng)測(cè)質(zhì)量的方法的不同視角 可靠性維度可用性維度性能維度測(cè)試用例：為特定目標(biāo)開發(fā)的測(cè)試輸入、執(zhí)行條件和預(yù)期結(jié)果的集合。 442.7 測(cè)試活動(dòng)When項(xiàng)目的后期階段？?jī)?yōu)點(diǎn)縮短測(cè)試時(shí)間易于定位缺陷 避免錯(cuò)上加錯(cuò) 工作量早期 中期 后期項(xiàng)目時(shí)間大小452.7 測(cè)試活動(dòng)Who主要包括測(cè)試工程師、測(cè)試員、軟件設(shè)計(jì)員、實(shí)施員、項(xiàng)目經(jīng)理、部署工程師、部署員、SQA人員和財(cái)務(wù)人員等 Where建議單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試在實(shí)施員所在的開發(fā)現(xiàn)場(chǎng)及其附近進(jìn)行測(cè)試和驗(yàn)收測(cè)試則完全在用戶現(xiàn)場(chǎng)測(cè)試 462.7 測(cè)試活動(dòng)

14、(5/5)How472.8 部署活動(dòng)What部署：是為確保最終用戶可以正常使用軟件產(chǎn)品而進(jìn)行的活動(dòng)。 根據(jù)產(chǎn)品類型，可以將部署分為三種模式:自定義安裝模式現(xiàn)場(chǎng)支持模式Internet模式 482.8 部署活動(dòng)部署單元：由一個(gè)工作版本（可執(zhí)行構(gòu)件集）、文檔（最終用戶支持材料和發(fā)布說明）和安裝工件組成 部署計(jì)劃：說明如何將產(chǎn)品從開發(fā)商轉(zhuǎn)移到用戶群兼容、轉(zhuǎn)換和遷移策略 部署時(shí)間表 部署順序用戶培訓(xùn) 492.8 部署活動(dòng)When項(xiàng)目的后期階段？工作量早期 中期 后期項(xiàng)目時(shí)間大小502.8 部署活動(dòng)Who主要包括部署工程師、部署員、文檔編寫員、包裝員、實(shí)施員、項(xiàng)目經(jīng)理、SQA人員和財(cái)務(wù)人員等Where一

15、部分工作可以在開發(fā)現(xiàn)場(chǎng)進(jìn)行，如制定部署計(jì)劃、包裝產(chǎn)品、編寫相關(guān)文檔等；另一部分工作必須在用戶現(xiàn)場(chǎng)進(jìn)行，如測(cè)試、驗(yàn)收測(cè)試和用戶正式使用中的安裝、培訓(xùn)工作等。512.8 部署活動(dòng)How523 軟件過程模型3.1 過程模型概念3.2 線形順序模型系列3.3 演進(jìn)模型系列3.4 其它模型系列3.5 過程模型的選擇533.1 過程模型概念為什么需要模型?模型幫助我們解釋事物如何工作模型能夠拓寬我們的視野(抽象)軟件過程模型一個(gè)過程模型是一個(gè)過程的抽象表示過程模型幫助我們更好地理解軟件開發(fā)543.1 過程模型概念(2/5)553.1 過程模型概念563.1 過程模型概念573.1 過程模型概念經(jīng)典模型Li

16、near Sequential ModelWaterfall ModelV ModelDepartment of Defense ModelRAD ModelPrototyping ModelBuild-and-Fix Model Incremental ModelSpiral ModelConcurrent Development ModelXP ModelRUP Model583.2 線形順序模型系列線性順序模型analysisdesigncodetestSystem/informationengineering593.2 線形順序模型系列瀑布模型60特征接受上一階段的結(jié)果作為本階段的輸入

17、開發(fā)階段嚴(yán)格按線性方式進(jìn)行對(duì)本階段的工作進(jìn)行評(píng)審每一階段具有相關(guān)的里程碑和交付產(chǎn)品缺點(diǎn)缺乏靈活性，難以適應(yīng)需求不明確或需求經(jīng)常變化的軟件開發(fā)開發(fā)早期存在的問題往往要到交付使用時(shí)才發(fā)現(xiàn)，維護(hù)代價(jià)大適用在開發(fā)的早期階段軟件需求被完整確定3.2 線形順序模型系列61實(shí)際使用的瀑布模型3.2 線形順序模型系列623.2 線形順序模型系列V 模型633.2 線形順序模型系列RAD (Rapid Application Development)模型60 90 days643.3 演進(jìn)模型系列原型模型Listen to customerbuild/revisemock-upcustomer test-dri

18、ves mock-up653.3 演進(jìn)模型系列邊建邊改 ModelBuild first versionModify until client is satisfiedMaintenancephaseRetirementDevelopmentMaintenance663.3 演進(jìn)模型系列邊建邊改 Model(續(xù))673.3 演進(jìn)模型系列增量模型System/InformationengineeringanalysisdesignCodeTest增量一交付1analysisdesignCodetest增量二analysisdesignCodetest增量三analysisdesignCodete

19、st增量四Calendar Time交付2交付3交付5683.3 演進(jìn)模型系列CustomerCommunicationRisk AnalysisEngineeringConstruction & ReleasePlanningCustomerEvaluationProject entryPoint axis螺旋模型693.3 演進(jìn)模型系列XP 模型，一種敏捷開發(fā)方法703.4 其它模型系列構(gòu)件組裝模型與瀑布模型對(duì)比713.4 其它模型系列應(yīng)用構(gòu)件提取車間構(gòu)件生產(chǎn)車間標(biāo)準(zhǔn)規(guī)范 與 質(zhì)量保證1基礎(chǔ)構(gòu)件，2功能構(gòu)件 3接口構(gòu)件，4用戶界面構(gòu)件 應(yīng)用構(gòu)件庫(kù) 構(gòu)件庫(kù)組裝車間領(lǐng)域 1領(lǐng)域 2應(yīng)用系統(tǒng) .

20、123472各種模型的比較模型優(yōu)點(diǎn)缺點(diǎn)瀑布模型規(guī)范，文檔驅(qū)動(dòng)系統(tǒng)可能不滿足客戶真正的需求快速原型克服了瀑布型的缺點(diǎn)增量模型開發(fā)早期回報(bào)明確，易于維護(hù)要求開放的軟件體系結(jié)構(gòu)螺旋模型風(fēng)險(xiǎn)驅(qū)動(dòng)，適用于大型項(xiàng)目開發(fā)風(fēng)險(xiǎn)分析人員需要有經(jīng)驗(yàn)且經(jīng)過充分訓(xùn)練733.5 過程模型的選擇軟件工程過程模型的選擇是基于:項(xiàng)目的應(yīng)用特點(diǎn)采用的方法和工具需要的控制交付的產(chǎn)品743.5 過程模型總結(jié)在前期需求明確，盡量采用瀑布模型用戶沒有信息系統(tǒng)使用經(jīng)驗(yàn)，需求分析人員技能不足，采用原型不確定因素很多，無(wú)法一下子計(jì)劃，采用增量或螺旋需求不穩(wěn)定，采用增量資金和成本無(wú)法一次到位，采用增量可以各種模型合并使用，但每一次必須要有明確

21、的交付物和出口準(zhǔn)則編程人員經(jīng)驗(yàn)較少，不宜采用快速的方法754 軟件過程能力成熟度764 能力成熟度模型CMM CMM（Capability Maturity Model）即能力成熟度模型，是美國(guó)卡耐基梅隆大學(xué)軟件工程研究所（SEI）建立的，用于評(píng)價(jià)軟件機(jī)構(gòu)的軟件過程能力成熟度的模型。 此模型建立之初的主要目的在于提供一種評(píng)價(jià)軟件承接方能力的方法，為大型軟件項(xiàng)目的招投標(biāo)活動(dòng)提供一種全面而客觀的評(píng)審依據(jù)。而發(fā)展到后來，又同時(shí)被軟件組織用于改進(jìn)其軟件過程。77軟件組織的成熟與不成熟不成熟的軟件組織軟件過程一般并不預(yù)先計(jì)劃，而是在項(xiàng)目進(jìn)行中由實(shí)際工作人員及管理員臨時(shí)計(jì)劃有時(shí)，即使軟件過程已計(jì)劃好，仍不

22、按計(jì)劃執(zhí)行沒有一個(gè)客觀的基準(zhǔn)來判斷產(chǎn)品質(zhì)量，或解決產(chǎn)品和過程中的問題對(duì)軟件過程步驟如何影響軟件質(zhì)量，一無(wú)所知，產(chǎn)品質(zhì)量得不到保證。而且，一些提高質(zhì)量的環(huán)節(jié)，如檢查、測(cè)試等經(jīng)常由于要趕進(jìn)度而減少或取消4 能力成熟度模型CMM78產(chǎn)品在交付前，對(duì)客戶來說，一切都是不可見的沒有長(zhǎng)遠(yuǎn)目標(biāo)，管理員通常只關(guān)注解決任何當(dāng)前的危機(jī)由于沒有實(shí)事求是地估計(jì)進(jìn)度、預(yù)算，因此他們經(jīng)常超支、超時(shí)。當(dāng)最后期限臨近，他們往往在功能性和質(zhì)量上妥協(xié)，或以加班加點(diǎn)方式趕進(jìn)度4 能力成熟度模型CMM792.成熟的軟件組織具有全面而充分的組織和管理軟件開發(fā)和維護(hù)過程的能力管理員監(jiān)視軟件產(chǎn)品的質(zhì)量以及生產(chǎn)這些產(chǎn)品的過程。制定了一系列客

23、觀基準(zhǔn)來判別產(chǎn)品質(zhì)量，并分析產(chǎn)品和過程中的問題。進(jìn)度和預(yù)算可以按照以前積累的經(jīng)驗(yàn)來制定，結(jié)果可行。預(yù)期的成本、進(jìn)度、功能與性能和質(zhì)量都能實(shí)現(xiàn)，并達(dá)到目的。4 能力成熟度模型CMM80能準(zhǔn)確及時(shí)地向工作人員通報(bào)實(shí)際軟件過程，并按照計(jì)劃有規(guī)則地(前后一致，不互相矛盾)工作凡規(guī)定的過程都編成文檔軟件過程和實(shí)際工作方法相吻合。必要時(shí)，過程定義會(huì)及時(shí)更新，通過測(cè)試，或者通過成本-效益分析來改進(jìn)過程。全體人員普遍地、積極地參與改進(jìn)軟件過程的活動(dòng)。在組織內(nèi)部的各項(xiàng)目中，每人在軟件過程中的職責(zé)都十分清晰而明確，各守其責(zé)，協(xié)同工作，有條不紊，甚至能預(yù)見和防范問題的發(fā)生。4 能力成熟度模型CMM81CMM的組成4

24、 能力成熟度模型CMM825.優(yōu)化級(jí)4.已管理級(jí)3.已定義級(jí)2.可重復(fù)級(jí)1.初始級(jí)標(biāo)準(zhǔn)、一致的過程有紀(jì)律的過程可預(yù)測(cè)的過程持續(xù)改進(jìn)的過程軟件過程成熟度的5個(gè)等級(jí)4 能力成熟度模型CMM83 CMM提供了一個(gè)成熟度等級(jí)框架：1級(jí)-初始級(jí)、2級(jí)-可重復(fù)級(jí)、3級(jí)-已定義級(jí)、4級(jí)-已管理級(jí)和5級(jí)-優(yōu)化級(jí)。 1.初始（initial）級(jí)： 軟件過程的特點(diǎn)是無(wú)秩序的，甚至是混亂的。幾乎沒有什么過程是經(jīng)過妥善定義的，成功往往依賴于個(gè)人或小組的努力。 2.可重復(fù)（repeatable）級(jí)： 建立了基本的項(xiàng)目管理過程來跟蹤成本、進(jìn)度和功能特性。制定了必要的過程紀(jì)律，能重復(fù)早先類似應(yīng)用項(xiàng)目取得的成功。4 能力成熟

25、度模型CMM84 3.已定義（defined）級(jí)： 己將管理和工程活動(dòng)兩方面的軟件過程文檔化、標(biāo)準(zhǔn)化，并綜合成該機(jī)構(gòu)的標(biāo)準(zhǔn)軟件過程。所有項(xiàng)目均使用經(jīng)批準(zhǔn)、剪裁的標(biāo)準(zhǔn)軟件過程來開發(fā)和維護(hù)軟件。 4.已管理（managed）級(jí)： 收集對(duì)軟件過程和產(chǎn)品質(zhì)量的詳細(xì)度量值，對(duì)軟件過程和產(chǎn)品都有定量的理解和控制。 5.優(yōu)化（optimizing）級(jí)： 整個(gè)組織關(guān)注軟件過程改進(jìn)的持續(xù)性、預(yù)見及增強(qiáng)自身，防止缺陷及問題的發(fā)生。過程的量化反饋和先進(jìn)的新思想、新技術(shù)促使過程不斷改進(jìn)。4 能力成熟度模型CMM85 成熟度等級(jí)表明了一個(gè)軟件組織的過程能力的水平。除初始級(jí)外，每個(gè)成熟度等級(jí)都包含若干個(gè)關(guān)鍵過程域（Key

26、 Process Area，簡(jiǎn)稱KPA）達(dá)到某個(gè)成熟度級(jí)別，該級(jí)別（以及較低級(jí)別）的所有關(guān)鍵過程域都必須得到滿足，并且過程必須實(shí)現(xiàn)制度化。4 能力成熟度模型CMM86缺陷預(yù)防、技術(shù)更新管理、過程更改管理定量過程管理軟件質(zhì)量管理機(jī)構(gòu)過程焦點(diǎn)、機(jī)構(gòu)過程定義、培訓(xùn)大綱、綜合軟件管理、軟件產(chǎn)品工程、組間協(xié)調(diào)、同行評(píng)審需求管理、軟件項(xiàng)目計(jì)劃、軟件項(xiàng)目跟蹤和監(jiān)督、軟件分包合同管理、軟件質(zhì)量保證、軟件配置管理能力成熟度級(jí)別中的關(guān)鍵過程域18個(gè)優(yōu)化級(jí)已管理級(jí)已定義級(jí)可重復(fù)級(jí)初始級(jí)4 能力成熟度模型CMM6個(gè)7個(gè)2個(gè)3個(gè)87能力成熟度模型集成CMMICapability Maturity Model Integ

27、rationCMM的成功導(dǎo)致了各種模型的衍生，每一種模型都探討了某一特定領(lǐng)域中的過程改進(jìn)問題SW-CMM：適用于軟件開發(fā)SE-CMM：系統(tǒng)工程能力成熟度模型SA-CMM：適用于軟件獲取SECAM：系統(tǒng)工程能力評(píng)估模型People CMM：討論軟件組織吸引、開發(fā)、激勵(lì)、組織和留住人才的能力EIA/IS 731：替代SW-CMM和SECAMIPD-CMM：適用于集成化產(chǎn)品開發(fā)FAA-CMM：集成了SE-CMM、 SA-CMM、 SW-CMM88相應(yīng)的國(guó)際標(biāo)準(zhǔn)： ISO/IEC 12207（軟件生存周期過程） ISO/IEC 15288（系統(tǒng)生存周期過程） ISO/IEC 15504（軟件過程評(píng)估）

28、模型的繁衍導(dǎo)致模型框架、術(shù)語(yǔ)等方面的矛盾和不一致包含在當(dāng)代工程中各種各樣的學(xué)科和工程是密切交叉在一起的，應(yīng)用不同模型時(shí)效率低下且容易混淆，常常要付出極其昂貴的代價(jià)美國(guó)國(guó)防部、美國(guó)國(guó)防工業(yè)委員會(huì)和SEI/CMU于1998年啟動(dòng)CMMI項(xiàng)目，希望CMMI是若干過程模型的綜合和改進(jìn)，是支持多個(gè)工程學(xué)科和領(lǐng)域的系統(tǒng)的、一致的過程改進(jìn)框架。4 能力成熟度模型CMM892000年發(fā)布第一個(gè)CMMI模型CMMI-SE/SW/IPPD V1.0：集成了SW-CMM、EIA/IS 731、IPD CMM V0.982002年1月發(fā)布CMMI-SE/SW/IPPD V1.1，美國(guó)國(guó)防工業(yè)委員會(huì)在第一屆CMMI國(guó)際研討會(huì)上宣布， CMMI V1.1將至少穩(wěn)定五年不變CMMI模型提供兩種表示法： 階段式模型和連續(xù)式模型4 能力成熟度模型CMM90階段式模型階段式模型的結(jié)構(gòu)類同于軟件CMM，它關(guān)