軟件工程(復旦大學)-概論課件

軟件工程第1章概論軟件工程第1章概論2/154教師介紹趙文耘教授、博士生導師復旦大學軟件工程實驗室主任中國計算機學會軟件工程專業(yè)委員會副主任中國軟件行業(yè)協(xié)會軟件工程分會副理事長上海復旦天翼計算機有限公司總經理2/154教師介紹趙文耘教授、博士生導師3/154序言計算機專業(yè)應該學到什么，有什么用?在大學里能夠學到什么?學習能力?3/154序言計算機專業(yè)應該學到什么，有什么用?序言（2）什么是一個好專業(yè)?中國Vs美國中國Vs印度中國Vs日本?軟件工程課程的目標4/154序言（2）什么是一個好專業(yè)?4/1545/154課程成績計算項目和作業(yè)40％一個項目文檔和練習課堂練習20％大考40％總分排序后按30％(A/A-)類推5/154課程成績計算項目和作業(yè)6/154參考書實用軟件工程（第二版）鄭人杰、殷人昆、陶永雷，清華大學出版社，1997年軟件工程（第二版）齊治昌、譚慶平、寧洪，高等教育出版社，2004年軟件系統(tǒng)開發(fā)技術（修訂版）潘錦平、施小英、姚天昉，西安電子科技大學出版社，1997年計算機科學技術百科全書（第二版）張效強主編，清華大學出版社，2005年SoftwareEngineeringAPractitionersApproach(SixthEdition),RogerSPressman，2005年（中文版）鄭人杰等譯，機械工業(yè)出版社，2007年6/154參考書實用軟件工程（第二版）7/154內容摘要計算機軟件軟件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境7/154內容摘要計算機軟件8/154內容摘要計算機軟件軟件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境8/154內容摘要計算機軟件9/154計算機軟件計算機軟件指計算機系統(tǒng)中的程序及其文檔程序是計算任務的處理對象和處理規(guī)則的描述計算任務：任何以計算機為處理工具的任務處理對象：數據（如數據、文字、圖形、圖像、聲音等，它們只是表示，而無含義）或信息（數據及有關的含義）處理規(guī)則一般指處理的動作和步驟。程序必須裝入計算機內才能工作文檔是為了便于了解程序所需的闡明性資料，文檔一般是給人看的，不一定裝入計算機9/154計算機軟件計算機軟件指計算機系統(tǒng)中的程序及其文檔10/154軟件的發(fā)展

1946-1956年從計算機問世到實用的高級程序語言出現前存儲容量比較小，運算速度比較慢采用個體工作方式,用低級語言編寫程序應用領域主要是以數值數據處理為主的科學計算，其特點是輸入、輸出量較小衡量程序質量的標準主要是功效，即運行時間省、占用內存小主要研究內容是科學計算程序、服務性程序和程序庫，研究對象是順序程序10/154軟件的發(fā)展1946-1956年11/1541956-1968年

從實用的高級程序語言出現到軟件工程出現前存儲器容量大，外圍設備得到迅速發(fā)展，出現了高級程序設計語言應用領域包括數據處理（非數值數據），其特點是計算量不大，但輸入、輸出量卻較大高速主機與低速外圍設備的矛盾突出，出現了操作系統(tǒng)、并發(fā)程序、數據庫及其管理系統(tǒng)20世紀60年代初提出了軟件一詞，開始認識到文檔的重要性研究高級程序設計語言、編譯程序、操作系統(tǒng)、支持編程的工具及各種應用軟件工作方式逐步從個體方式轉向合作方式出現軟件危機11/1541956-1968年12/1541968年-至今從軟件工程出現到現在硬件向巨型機和微型機二個方向發(fā)展，出現了計算機網絡，軟件方面提出了軟件工程，出現了“計算機輔助軟件工程”（CASE）計算機的應用領域滲透到各個業(yè)務領域，出現了嵌入式應用，其特點是受制于它所嵌入的宿主系統(tǒng)開發(fā)方式逐步由個體合作方式轉向工程方式軟件工程方面的研究主要包括軟件開發(fā)模型、軟件開發(fā)方法及技術、軟件工具與環(huán)境、軟件過程、軟件自動化系統(tǒng)等軟件方面研究以智能化、自動化、集成化、并行化、以及自然化為標志的軟件開發(fā)新技術12/1541968年-至今13/154軟件危機

許多軟件項目不能滿足客戶的要求許多軟件項目超出預算和時間安排13/154軟件危機14/154軟件危機的表現對軟件開發(fā)成本和進度的估計常常很不正確用戶對“已完成的”軟件系統(tǒng)不滿意的現象經常發(fā)生軟件產品的質量往往靠不住軟件常常是不可維護的軟件通常沒有適當的文檔資料軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升軟件開發(fā)生產率提高的速度遠遠跟不上計算機應用迅速普及深入的趨勢14/154軟件危機的表現對軟件開發(fā)成本和進度的估計常常很不15/154軟件危機的原因軟件是邏輯產品，開發(fā)進度、成本難以估計缺乏或不完整、不一致的文檔給維護帶來困難用戶對軟件需求的描述往往不夠精確，有遺漏，有二義軟件開發(fā)人員對需求的理解與用戶的本來愿望有差異大型軟件項目需多人協(xié)同完成，缺乏管理經驗開發(fā)人員不能有效地、獨立自主地處理大型軟件的全部關系缺乏有力的方法學和工具的支持軟件項目的特殊性和人類智力的局限性15/154軟件危機的原因軟件是邏輯產品，開發(fā)進度、成本難以16/154克服軟件危機的途徑消除錯誤的概念和做法推廣使用成功的開發(fā)技術和方法使用軟件工具和軟件工程支持環(huán)境加強軟件管理16/154克服軟件危機的途徑消除錯誤的概念和做法17/154軟件的特點軟件是一種邏輯實體，而不是有形的系統(tǒng)元件，其開發(fā)成本和進度難以準確地估算軟件是被開發(fā)的或被設計的，它沒有明顯的制造過程，一旦開發(fā)成功，只需復制即可，但其維護的工作量大軟件的使用沒有硬件那樣的機械磨損和老化問題17/154軟件的特點軟件是一種邏輯實體，而不是有形的系統(tǒng)元18/15418/15419/154其它特點：軟件的開發(fā)和運行常受到計算機硬件的限制，對計算機硬件有著不同程度的依賴性軟件的開發(fā)至今尚未完全實現自動化軟件成本相當昂貴相當多的軟件工作涉及到社會因素19/154其它特點：20/15420/15421/154軟件的分類系統(tǒng)軟件：屬于計算機系統(tǒng)中最靠近硬件的一層，其它軟件一般都通過系統(tǒng)軟件發(fā)揮作用，它與具體的應用領域無關。如操作系統(tǒng)、編譯程序等。支持軟件：支持軟件的開發(fā)和維護的軟件。如數據庫管理系統(tǒng)、網絡軟件、軟件開發(fā)環(huán)境等。應用軟件：特定應用領域專用的軟件。如實時軟件、嵌入式軟件、科學和工程計算軟件、事務處理軟件、人工智能軟件等。21/154軟件的分類系統(tǒng)軟件：屬于計算機系統(tǒng)中最靠近硬件的22/154

按軟件工作方式劃分：實時處理軟件分時軟件交互式軟件批處理軟件按軟件服務對象的范圍劃分：項目軟件產品軟件

22/154按軟件工作方式劃分：23/154

按使用的頻度進行劃分：

一次使用頻繁使用按軟件失效的影響進行劃分：

高可靠性軟件一般可靠性軟件23/154按使用的頻度進行劃分：軟件工程(復旦大學)-概論課件25/154軟件語言

softwarelanguage

軟件語言是用于書寫計算機軟件的語言。它主要包括：

需求定義語言功能性語言設計性語言實現性語言（即程序設計語言）文檔語言25/154軟件語言

softwarelanguage26/154需求定義語言

requirementsdefinitionlanguage需求定義語言用來書寫軟件需求定義。軟件需求定義是軟件功能需求和非功能需求的定義性描述。軟件功能需求刻畫軟件“做什么”，軟件非功能需求刻畫諸如功能性限制、設計限制、環(huán)境描述、數據與通信規(guī)程及項目管理等典型的需求定義語言有PSL語言（ProblemStatementLanguage問題陳述語言）26/154需求定義語言

requirementsdefi27/154功能性語言

functionallanguage功能性語言用來書寫軟件功能規(guī)約（functionalspecification）軟件功能規(guī)約是軟件功能的嚴格而完整的陳述。通常它只刻畫軟件系統(tǒng)“做什么”的外部功能，而不涉及系統(tǒng)“如何做”的內部算法。典型的功能性語言有廣譜語言、Z語言。27/154功能性語言

functionallanguag28/154設計性語言

designlanguage設計性語言用來書寫軟件設計規(guī)約（designspecification）軟件設計規(guī)約是軟件設計的嚴格而完整的陳述。一方面，它是軟件功能規(guī)約的算法性細化，刻畫軟件“如何做”的內部算法，另一方面，它是軟件實現的依據。典型的設計性語言有PDL語言（ProgramDesignLanguage）28/154設計性語言

designlanguage設計性29/154實現性語言

實現性語言用來書寫計算機程序實現性語言也稱編程語言或程序設計語言（programminglanguage）程序設計語言可按語言的級別、對使用者的要求、應用范圍、使用方式、成分性質等多種角度進行分類

29/154實現性語言實現性語言用來書寫計算機程序30/154

按語言級別分：低級語言和高級語言

低級語言是與特定計算機體系結構密切相關的程序設計語言，如機器語言、匯編語言。其特點是與機器有關，功效高，但使用復雜，開發(fā)費時，難維護。

高級語言是不反映特定計算機體系結構的程序設計語言，它的表示方法比低級語言更接近于待解問題的表示方法。其特點是在一定程度上與具體機器無關，易學、易用、易維護。但高級語言程序經編譯后產生的目標程序的功效往往較低。30/154按語言級別分：低級語言和高級語言31/154

按用戶要求分：過程式語言和非過程式語言

過程式語言（procedurallanguage）是通過指明一列可執(zhí)行的運算及運算次序來描述計算過程的程序設計語言。如FORTRAN、COBOL、C等。

非過程式語言（nonprocedurallanguage）是不顯式指明處理過程細節(jié)的程序設計語言。在這種語言中盡量引進各種抽象度較高的非過程性描述手段，以期做到在程序中增加“做什么”的描述成分，減少“如何做”的細節(jié)描述。如第四代語言（4GL）、函數式語言、邏輯式語言。31/154按用戶要求分：過程式語言和非過程式語言32/154也可稱：命令式語言和申述式語言

命令式語言（imperativelanguage）即過程式語言。

申述式語言（declarativelanguage）是著重描述要處理什么，而非描述如何處理的語言。申述式語言程序是關于問題解的約束陳述，這些約束迫使含于實現中的算法處理機制生成一個解或一組解。如函數式語言、邏輯式語言。32/154也可稱：命令式語言和申述式語言33/154

函數式語言(functionalprogramminglanguage)中函數是構造程序的基本成分，它提供一些設施用于構造更為復雜的函數。程序人員根據提出的問題去定義求解函數（即主程序），其中可能包含一些輔助函數。如Lisp語言。

邏輯式語言(logicprogramminglanguage)的基本運算單位是謂詞。謂詞定義了變元間的邏輯關系。例如，Prolog語言的基本形式是Horn子句，其程序圍繞著某一主題的事實、規(guī)則和詢問三類語句組成。這三類語句分別用來陳述事實、定義規(guī)則和提出問題。33/154函數式語言(functionalpro34/154

按應用范圍分：通用語言和專用語言

通用語言指目標非單一的語言，如FORTRAN、COBOL、C等。

專用語言指目標單一的語言，如自動數控程序APT。34/154按應用范圍分：通用語言和專用語言35/154

按使用方式分：交互式語言和非交互式語言

交互式語言指具有反映人機交互作用的語言，如BASIC。

非交互式語言指不反映人機交互作用的語言，如FORTRAN、COBOL。35/154按使用方式分：交互式語言和非交互式語言36/154

按成分性質分：順序語言、并發(fā)語言、分布語言

順序語言指只含順序成分的語言，如FORTRAN、C。

并發(fā)語言指含有并發(fā)成分的語言，如Modula、Ada、并發(fā)Pascal。

分布語言指考慮到分布計算要求的語言，如Modula。36/154按成分性質分：順序語言、并發(fā)語言、分布語言37/154文檔語言

documentationlanguage

文檔語言用來書寫軟件文檔。計算機軟件文檔是計算機開發(fā)、維護和使用過程的檔案資料和對軟件本身的闡述性資料。通常用自然語言或半形式化語言書寫。37/154文檔語言

documentationlangu38/154內容摘要計算機軟件軟件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境38/154內容摘要計算機軟件39/154軟件工程定義1968年NATO(北大西洋公約組織)會議上首次提出FritzBauer：軟件工程是為了經濟地獲得可靠的和能在實際機器上高效運行的軟件而建立和使用的好的工程原則IEEE：軟件工程是（1）將系統(tǒng)化的、規(guī)范的、可度量的方法應用于軟件的開發(fā)、運行和維護的過程，即將工程化應用于軟件中；（2）（1）中所述方法的研究計算機科學技術百科全書：軟件工程是應用計算機科學、數學及管理科學等原理，以工程化的原則和方法制作軟件的工程39/154軟件工程定義1968年NATO(北大西洋公約組織40/154軟件工程的框架

目標：生產具有正確性、可用性以及價格合宜的產品

正確性反映軟件產品實現相應功能規(guī)約的程度；

可用性反映軟件的基本結構、實現及其文檔為用戶可用的程度；

價格合宜反映軟件開發(fā)與運行的總代價滿足用戶要求的程度。40/154軟件工程的框架目標：41/154

過程（Process）：生產一個最終滿足需求且達到工程目標的軟件產品所需要的步驟軟件工程過程包括：開發(fā)過程、運作過程、維護過程、管理過程、支持過程、獲取過程、供應過程、剪裁過程等41/154過程（Process）：42/154

原則：選取適宜的開發(fā)模型采用合適的設計方法提供高質量的工程支持重視軟件工程的管理42/154原則：43/154軟件生存周期

（softwarelifecycle）軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計算機軟件的生存周期軟件生存周期大體可分為如下幾個活動：計算機系統(tǒng)工程、需求分析、設計、編碼、測試、運行和維護43/154軟件生存周期

（softwarelife44/154計算機系統(tǒng)工程計算機系統(tǒng)包括計算機硬件、軟件、使用計算機系統(tǒng)的人、數據庫、文檔、規(guī)程等系統(tǒng)元素。計算機系統(tǒng)工程的任務：確定待開發(fā)軟件的總體要求和范圍，以及它與其它計算機系統(tǒng)元素之間的關系進行成本估算，做出進度安排進行可行性分析，即從經濟、技術、法律等方面分析待開發(fā)的軟件是否有可行的解決方案，并在若干個可行的解決方案中作出選擇。44/154計算機系統(tǒng)工程45/154軟件需求分析主要解決待開發(fā)軟件要“做什么”的問題確定軟件的功能、性能、數據、界面等要求，生成軟件需求規(guī)約。45/154軟件需求分析46/154軟件設計主要解決待開發(fā)軟件“怎么做”的問題。軟件設計通常可分為系統(tǒng)設計（也稱概要設計或總體設計）和詳細設計。系統(tǒng)設計的任務是設計軟件系統(tǒng)的體系結構，包括軟件系統(tǒng)的組成成分、各成分的功能和接口、成分間的連接和通信，同時設計全局數據結構；詳細設計的任務是設計各個組成成分的實現細節(jié)，包括局部數據結構和算法等。46/154軟件設計47/154編碼

用某種程序設計語言，將設計的結果轉換為可執(zhí)行的程序代碼。測試發(fā)現并糾正軟件中的錯誤和缺陷。測試主要包括單元測試、集成測試、確認測試和系統(tǒng)測試。運行和維護在軟件運行期間，當發(fā)現了軟件中潛藏的錯誤或需要增加新的功能或使軟件適應外界環(huán)境的變化等情況出現時對軟件進行修改。47/154編碼48/154內容摘要計算機軟件軟件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境48/154內容摘要計算機軟件49/154軟件過程軟件過程是軟件生存周期中的一系列相關的過程。過程是活動的集合，活動是任務的集合。軟件過程有三層含義：個體含義，即指軟件產品或系統(tǒng)在生存周期中的某一類活動的集合，如軟件開發(fā)過程，軟件管理過程等；整體含義，即指軟件產品或系統(tǒng)在所有上述含義下的軟件過程的總體；工程含義，即指解決軟件過程的工程，它應用軟件工程的原則、方法來構造軟件過程模型，并結合軟件產品的具體要求進行實例化，以及在用戶環(huán)境下的運作，以此進一步提高軟件生產率，降低成本。49/154軟件過程軟件過程是軟件生存周期中的一系列相關的過50/154ISO12207軟件生存周期過程ISO/IEC12207標準把軟件生存周期中可以開展的活動分為5個基本過程，8個支持過程和4個組織過程。每一個過程劃分為一組活動，每項活動進一步劃分為一組任務。50/154ISO12207軟件生存周期過程ISO/IEC51/154

基本（primary）過程供各當事方在軟件生存周期期間使用。包括：獲?。╝cquisition）過程：確定需方和組織向供方獲取系統(tǒng)、軟件或軟件服務的活動。供應（supply）過程：確定供方和組織向需方提供系統(tǒng)、軟件或軟件服務的活動。開發(fā)（development）過程：確定開發(fā)者和組織定義并開發(fā)軟件的活動。運作（operation）過程：確定操作者和組織在規(guī)定的環(huán)境中為其用戶提供運行計算機系統(tǒng)服務的活動。維護（maintenance）過程：確定維護者和組織提供維護軟件服務的活動。51/154基本（primary）過程供各當事方在軟52/154

支持（supporting）過程用于支持其他過程，它有助于軟件項目的成功和質量提高。包括：文檔編制（documentation）過程：確定記錄生存周期過程產生的信息所需的活動。配置管理（configurationmanagement）過程：確定配置管理活動。質量保證（qualityassurance）過程：確定客觀地保證軟件和過程符合規(guī)定的要求以及已建立的計劃所需的活動。52/154支持（supporting）過程用于支持53/154驗證（verification）過程：根據軟件項目要求，按不同深度確定驗證軟件所需的活動。確認（validation）過程：確定確認軟件所需的活動。聯(lián)合評審（jointreview）過程：確定評價一項活動的狀態(tài)和產品所需的活動。審計（audit）過程：確定為判斷符合要求、計劃和合同所需的活動。問題解決（problemresolution）過程：確定一個用于分析和解決問題的過程。53/154驗證（verification）過程：根據軟件項54/154

組織（organizational）過程用于軟件組織建立和實現構成相關生存周期的基礎結構和人事制度，并不斷改進這種結構和過程。包括：管理（management）過程：確定生存周期過程中的基本管理活動?；A設施（infrastructure）過程：確定建立生存周期過程基礎結構的基本活動。改進（improvement）過程:確定一個組織為建立、測量、控制和改進其生存周期過程所需開展的基本活動。培訓（training）過程:確定提供經適當培訓的人員所需的活動。54/154組織（organizational）過55/154ISO/IEC12207為軟件生存周期過程建立了一個公共框架，它提供了一組標準的過程、活動和任務。對于一個軟件項目，可根據其具體情況對標準的過程、活動和任務進行剪裁，即刪除不適用的過程、活動和任務。ISO/IEC12207標準的附錄A中的剪裁（tailoring）過程規(guī)定了在針對該標準進行剪裁時所需要的基本活動（包括：明確項目環(huán)境；請求輸入；選擇過程、活動和任務；把剪裁決定和理由寫成文檔），剪裁過程的輸出是：剪裁決定和理由記錄。附錄B就剪裁要點提供簡要說明，并列出一些關鍵要素，可以根據這些要素作出剪裁決定。55/154ISO/IEC12207為軟件生存周期過程建立56/154能力成熟度模型CMMCMM（CapabilityMaturityModel）即能力成熟度模型，是美國卡耐基梅隆大學軟件工程研究所（SEI）在美國國防部資助下于二十世紀八十年代末建立的，用于評價軟件機構的軟件過程能力成熟度的模型。此模型在建立和發(fā)展之初，主要目的在于提供一種評價軟件承接方能力的方法，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據。而發(fā)展到后來，又同時被軟件組織用于改進其軟件過程。56/154能力成熟度模型CMMCMM（Capability57/154軟件組織的成熟與不成熟1.不成熟的軟件組織軟件過程一般并不預先計劃，而是在項目進行中由實際工作人員及管理員臨時計劃有時，即使軟件過程已計劃好，仍不按計劃執(zhí)行沒有一個客觀的基準來判斷產品質量，或解決產品和過程中的問題對軟件過程步驟如何影響軟件質量，一無所知，產品質量得不到保證。而且，一些提高質量的環(huán)節(jié)，如檢查、測試等經常由于要趕進度而減少或取消57/154軟件組織的成熟與不成熟1.不成熟的軟件組織58/154產品在交付前，對客戶來說，一切都是不可見的沒有長遠目標，管理員通常只關注解決任何當前的危機由于沒有實事求是地估計進度、預算，因此他們經常超支、超時。當最后期限臨近，他們往往在功能性和質量上妥協(xié)，或以加班加點方式趕進度58/154產品在交付前，對客戶來說，一切都是不可見的59/1542.成熟的軟件組織具有全面而充分的組織和管理軟件開發(fā)和維護過程的能力管理員監(jiān)視軟件產品的質量以及生產這些產品的過程制定了一系列客觀基準來判別產品質量，并分析產品和過程中的問題進度和預算可以按照以前積累的經驗來制定，結果可行。預期的成本、進度、功能與性能和質量都能實現，并達到目的能準確及時地向工作人員通報實際軟件過程，并按照計劃有規(guī)則地(前后一致，不互相矛盾)工作59/1542.成熟的軟件組織60/154凡規(guī)定的過程都編成文檔軟件過程和實際工作方法相吻合。必要時，過程定義會及時更新，通過測試，或者通過成本-效益分析來改進過程。全體人員普遍地、積極地參與改進軟件過程的活動。在組織內部的各項目中，每人在軟件過程中的職責都十分清晰而明確，每人各守其責，協(xié)同工作，有條不紊，甚至能預見和防范問題的發(fā)生。60/154凡規(guī)定的過程都編成文檔61/154軟件過程成熟度等級CMM提供了一個成熟度等級框架：1級-初始級、2級-可重復級、3級-已定義級、4級-已管理級和5級-優(yōu)化級。1.初始（initial）級：軟件過程的特點是無秩序的，甚至是混亂的。幾乎沒有什么過程是經過妥善定義的，成功往往依賴于個人或小組的努力。2.可重復（repeatable）級：建立了基本的項目管理過程來跟蹤成本、進度和功能特性。制定了必要的過程紀律，能重復早先類似應用項目取得的成功。61/154軟件過程成熟度等級CMM提供了一個成熟度62/1543.已定義（defined）級：己將管理和工程活動兩方面的軟件過程文檔化、標準化，并綜合成該機構的標準軟件過程。所有項目均使用經批準、剪裁的標準軟件過程來開發(fā)和維護軟件。4.已管理（managed）級：收集對軟件過程和產品質量的詳細度量值，對軟件過程和產品都有定量的理解和控制。5.優(yōu)化（optimizing）級：整個組織關注軟件過程改進的持續(xù)性、預見及增強自身，防止缺陷及問題的發(fā)生。過程的量化反饋和先進的新思想、新技術促使過程不斷改進。62/1543.已定義（defined）級：63/1545.優(yōu)化級4.已管理級3.已定義級2.可重復級1.初始級標準、一致的過程有紀律的過程可預測的過程持續(xù)改進的過程軟件過程成熟度的5個等級63/1545.優(yōu)化級4.已管理級3.已定義級2.可重復級164/154成熟度等級關鍵過程域共同特性關鍵實踐包含劃分為包含過程能力表明目標實現實施或制度化解決活動或基礎設施描述CMM結構能力成熟度模型的結構64/154成熟度等級關鍵過程域共同特性關鍵實踐包含劃分為包65/154能力成熟度模型的結構

成熟度等級表明了一個軟件組織的過程能力的水平。除初始級外，每個成熟度等級都包含若干個關鍵過程域（KeyProcessArea，簡稱KPA）（見表1.2）達到某個成熟度級別，該級別（以及較低級別）的所有關鍵過程域都必須得到滿足，并且過程必須實現制度化。65/154能力成熟度模型的結構成熟度等級表明了一個軟件組66/154CMM提供了18個關鍵過程域，每個關鍵過程域都有一組對改進過程能力非常重要的目標，并確定了一組相應的關鍵實踐

目標說明了每一個關鍵過程域的范圍、界限和意義。

關鍵實踐描述了建立一個過程能力必須完成的活動和必須具備的基礎設施，完成了這些關鍵實踐就達到了相應關鍵過程域的目標，該關鍵過程域也就得到了滿足。每個關鍵過程域的關鍵實踐都是按照五個共同特性（執(zhí)行約定，執(zhí)行能力，執(zhí)行活動，測量和分析，驗證實現）進行組織的，主要解決關鍵實踐的實施或制度化問題。66/154CMM提供了18個關鍵過程域，每個關鍵過程域都67/154

共同特性將描述關鍵過程域的關鍵實踐組織起來。共同特性是一些屬性，指明一個關鍵過程域的執(zhí)行和規(guī)范化是否有效、可重復和可持續(xù)。共有5個共同特性:執(zhí)行約定，執(zhí)行能力，執(zhí)行活動，測量和分析，驗證實現。1)執(zhí)行約定：執(zhí)行約定描述機構為確保過程的建立和持續(xù)而必須采取的一些措施。典型內容包括建立機構策略和領導關系。67/154共同特性將描述關鍵過程域的關鍵實踐組織起來。共68/1542)執(zhí)行能力：執(zhí)行能力描述了項目或機構完整地實現軟件過程所必須有的先決條件。典型內容包括資源、機構結構和培訓。3)執(zhí)行活動：執(zhí)行活動描述了執(zhí)行一個關鍵過程域所必需的活動、任務和規(guī)程。典型內容包括制定計劃和規(guī)程、執(zhí)行和跟蹤以及必要時采取糾正措施。68/1542)執(zhí)行能力：69/1544)測量和分析：測量和分析描述了為確定與過程有關的狀態(tài)所需的基本測量實踐。這些測量可用來控制和改進過程。典型內容包括可能采用的測量實例。5)驗證實現：驗證實現描述了為確保執(zhí)行的活動與已建立的過程一致所采取的步驟。典型內容包括管理部門和軟件質量保證組實施的評審和審核。69/15470/154在執(zhí)行活動這個共同特性中的實踐描述了建立一個過程能力所必須完成的活動。所有其他實踐共同形成了一個使機構能將執(zhí)行活動中描述的實踐進行規(guī)范化的基礎。各關鍵過程域的詳細描述，參見《能力成熟度模型（CMM）：軟件過程改進指南》，卡耐基梅隆大學軟件工程研究所編著，劉孟仁等譯，電子工業(yè)出版社出版。70/15471/154缺陷預防技術更新管理過程更改管理優(yōu)化級定量過程管理軟件質量管理已管理級機構過程焦點機構過程定義培訓大綱綜合軟件管理軟件產品工程組間協(xié)調同行評審已定義級需求管理軟件項目計劃軟件項目跟蹤和監(jiān)督軟件分包合同管理軟件質量保證軟件配置管理可重復級初始級能力成熟度級別中的關鍵過程域71/154缺陷預防優(yōu)化級定量過程管理已管理級機構過程焦點已72/154關鍵過程域實例機構過程焦點第3級的關鍵過程域：已定義級

機構過程焦點的目的是，為能改進機構整體軟件過程能力的軟件過程活動建立機構的職責。

機構過程焦點包括，建立和維護機構的軟件過程和項目軟件過程（之間）的默契關系，并協(xié)調有關評估、開發(fā)、維護和改進這些過程的活動。機構提供長期的約定和資源，以協(xié)調現在和將來的軟件項目的軟件過程的開發(fā)和維護。該項工作由某個小組實施，例如軟件工程過程組。它負責機構的軟件過程活動，特別是負責開發(fā)和維護機構標準軟件過程和相關過程資源（如在機構過程定義關鍵過程域中說明的），并協(xié)調軟件項目的過程活動。72/154關鍵過程域實例機構過程焦點73/154目標目標1：機構內部軟件過程的制定和改進活動協(xié)調一致。目標2：相對于過程標準，所使用的軟件過程的優(yōu)勢和薄弱環(huán)節(jié)標識清楚。目標3：機構級的過程開發(fā)和改進活動有計劃。73/154目標74/154執(zhí)行約定約定1：機構遵循書面的管理策略，協(xié)調整個機構范圍內的軟件過程開發(fā)和改進活動。

該策略一般規(guī)定:1.建立一個小組，負責機構級的軟件過程活動，使這些活動與各項目協(xié)調一致。

2.定期評估項目所使用的軟件過程，以確定其優(yōu)勢和薄弱環(huán)節(jié)。

74/154執(zhí)行約定75/1543.對機構標準軟件過程進行合理地剪裁，以得到項目使用的軟件過程。

關于機構標準軟件過程，參見綜合軟件管理關鍵過程域的活動1。4.每個項目的軟件過程、工具和方法的改進和其他有用信息，可用于其他項目。75/1543.對機構標準軟件過程進行合理地剪裁，以得到項76/154約定2：上級管理部門倡導和支持機構的軟件過程開發(fā)和改進活動。

上級管理部門：

1.向機構成員和負責人說明有關軟件過程活動的約定。

2.制定資金、人員配備和其他資源的長期計劃和約定。

3.制定管理和執(zhí)行有關軟件過程開發(fā)和改進活動的策略。76/154約定2：上級管理部門倡導和支持機構的軟件過程開發(fā)77/154約定3：上級管理部門監(jiān)督機構的軟件過程開發(fā)和改進活動。

l.確保機構標準軟件過程滿足企業(yè)目標和策略。

2.提出關于軟件過程開發(fā)和改進活動優(yōu)先次序的建議。

3.參與制定軟件過程開發(fā)和改進計劃。

a.上級管理部門與更高層人員和負責人共同協(xié)調軟件過程需求及問題

b.上級管理部門與該機構負責人進行協(xié)調，以獲得負責人和機構成員的支持和參與77/154約定3：上級管理部門監(jiān)督機構的軟件過程開發(fā)和改進78/154執(zhí)行能力能力1：有一個負責機構的軟件過程活動的小組。

一個小組是一些部門、負責人和人員的組合，負責一組任務和活動。小組的規(guī)?？梢圆煌?，既可以是單個兼職的人，也可以是多個來自不同部門的兼職人員，也可以由幾個專職人員組成。組成小組時考慮的因素包括：分派的任務和活動、項目規(guī)模、機構結構和機構文化。某些小組，如軟件質量保證組，集中關注項目活動;而其他一些小組，例如軟件工程過程組，集中關注機構范圍內的活動。

78/154執(zhí)行能力79/154

1.條件可能時，小組成員以專職工作的軟件專業(yè)人員為核心，并盡可能有其他的兼職人員支持。

該小組最一般的例子是軟件工程過程（SEPG）。

2.小組成員中有軟件工程及軟件相關科目的代表。軟件工程及軟件相關科目的實例有：軟件需求分析軟件設計程序編碼軟件測試軟件配置管理軟件質量保證79/1541.條件可能時，小組成員以專職工作的軟件專80/154能力2：為實施機構的軟件過程活動提供了充足的資源和資金。

1.委派在特定領域具有特長的人員支持該小組。特定領域的實例有：軟件重用計算機輔助軟件工程技術(CASE)測量培訓課程開設

2.有支持該機構軟件過程活動的工具。支持工具的實例有：統(tǒng)計分析工具桌面出版工具數據庫管理系統(tǒng)過程建模工具80/154能力2：為實施機構的軟件過程活動提供了充足的資源81/154能力3：負責機構軟件過程活動的小組成員接受過實施這些活動所需的培訓。培訓的實例有：軟件工程實踐過程控制技術機構過程變動管理軟件過程計劃、管理和監(jiān)督技術轉變參見培訓大綱關鍵過程域81/154能力3：負責機構軟件過程活動的小組成員接受過實施82/154能力4：軟件工程組和其他軟件相關小組的成員接受過機構軟件過程活動及其在這些活動中的任務方面的定向培訓。

參見培訓大綱關鍵過程域82/154能力4：軟件工程組和其他軟件相關小組的成員接受過83/154執(zhí)行活動活動1：定期評估軟件過程，并根據評估結果制定行動計劃。

評估一般每隔一年、一年半至三年進行一次。評估可針對機構中所使用的所有軟件過程，也可通過對過程和項目進行抽樣評估。評估機構軟件過程能力的方法實例之一是SEI軟件過程評估方法。行動計劃標識：涉及哪些評估結果針對評估結果實施更改軟件過程的準則負責實施更改的小組或個人83/154執(zhí)行活動84/154活動2：機構制定和維護它的軟件過程開發(fā)和改進活動的計劃。該計劃：以軟件過程評估后的行動計劃和其他的機構過程改進倡議為基礎。確定要實施的活動及實施這些活動的進度。確定負責這些活動的小組和個人。確定所需的資源，包括人員配備和工具。初始發(fā)布和有大改動時通過同行評審。

參見同行評審關鍵過程域。

6.機構的軟件負責人和上級負責人評審認可。84/154活動2：機構制定和維護它的軟件過程開發(fā)和改進活動85/154活動3：在機構級協(xié)調關于機構和項目的軟件過程的開發(fā)和改進活動。涉及的軟件過程有：

1.機構標準軟件過程。關于機構標準過程，參見機構過程定義關鍵過程域的活動1和活動2。

2.項目定義的軟件過程。關于項目定義的軟件過程。參見綜合軟件管理關鍵過程域的活動1和活動2。85/154活動3：在機構級協(xié)調關于機構和項目的軟件過程的開86/154活動4：在機構級協(xié)調有關軟件過程數據庫的使用。機構的軟件過程數據庫用來收集機構和項目的軟件過程以及生成的軟件產品的信息。關于機構的軟件過程數據庫，參見機構過程定義關鍵過程域的活動5。86/154活動4：在機構級協(xié)調有關軟件過程數據庫的使用。87/154活動5：監(jiān)控和評價機構中限制使用的新過程、方法和工具。合適時，推廣到機構的其他部分。活動6：在機構內協(xié)調機構和項目的軟件過程的培訓。

1.制定有關機構和項目軟件過程的專題培訓計劃。

2.合適時，培訓由負責機構軟件過程活動的小組（如軟件工程過程組）或培訓小組準備和實施。參見培訓大綱關鍵過程域。87/154活動5：監(jiān)控和評價機構中限制使用的新過程、方法和88/154活動7：向與實施軟件過程有關的小組通報機構和項目中軟件過程開發(fā)和改進活動的情況。通報方式的實例有：過程電子公告板過程咨詢委員會工作小組信息交流會調查過程改進組日常討論88/154活動7：向與實施軟件過程有關的小組通報機構和項目89/154測量和分析測量1：測量機構的軟件過程開發(fā)和改進活動的狀態(tài)測量的實例有：機構在過程評估、開發(fā)和改進活動中已完成的工作、工作量和耗費的資金，與計劃相比較每次軟件過程的評估結果，與以前的評估結果和建議相比較89/154測量和分析90/154驗證實現驗證1：上級管理部門定期評審軟件過程開發(fā)和改進活動。上級管理部門實施定期評審的主要目的是適當地、及時地掌握軟件過程活動。在滿足機構需求的前提下，只要有適當的機制來報告異常情況，評審的時間間隔就盡可能長些。

1.對照計劃，評審有關開發(fā)和改進軟件過程活動的進展和狀態(tài)。

2.討論低層不能解決的沖突和問題。

3.指定和評審行動措施，并跟蹤到關閉。

4.編寫評審的總結報告，并分發(fā)給相關的小組和個人。90/154驗證實現91/154能力成熟度模型集成CMMI

CapabilityMaturityModelIntegrationCMM的成功導致了各種模型的衍生，每一種模型都探討了某一特定領域中的過程改進問題SW-CMM：適用于軟件開發(fā)SE-CMM：系統(tǒng)工程能力成熟度模型SA-CMM：適用于軟件獲取SECAM：系統(tǒng)工程能力評估模型PeopleCMM：討論軟件組織吸引、開發(fā)、激勵、組織和留住人才的能力EIA/IS731：替代SW-CMM和SECAMIPD-CMM：適用于集成化產品開發(fā)FAA-iCMM：集成了SE-CMM、SA-CMM、SW-CMM91/154能力成熟度模型集成CMMI

Capability92/154相應的國際標準：ISO/IEC12207（軟件生存周期過程）、ISO/IEC15288（系統(tǒng)生存周期過程）、ISO/IEC15504（軟件過程評估）模型的繁衍導致模型框架、術語等方面的矛盾和不一致包含在當代工程中各種各樣的學科和工程是密切交叉在一起的，應用不同模型時效率低下且容易混淆，常常要付出極其昂貴的代價92/154相應的國際標準：ISO/IEC12207（軟93/154美國國防部、美國國防工業(yè)委員會和SEI/CMU于1998年啟動CMMI項目，希望CMMI是若干過程模型的綜合和改進，是支持多個工程學科和領域的系統(tǒng)的、一致的過程改進框架，能適應現代工程的特點和需要，能提高過程的質量和工作效率2000年發(fā)布第一個CMMI模型CMMI-SE/SW/IPPDV1.0：集成了SW-CMM、EIA/IS731、IPDCMMV0.9893/154美國國防部、美國國防工業(yè)委員會和SEI/CMU于94/1542002年1月發(fā)布CMMI-SE/SW/IPPDV1.1，美國國防工業(yè)委員會在第一屆CMMI國際研討會上宣布，CMMIV1.1將至少穩(wěn)定五年不變CMMI模型為每個學科的組合都提供兩種表示法：階段式模型和連續(xù)式模型94/15495/154階段式模型階段式模型的結構類同于軟件CMM，它關注組織的成熟度，其成熟度等級如下圖所示5．優(yōu)化的4．定量管理的3．已定義的2．已管理的1．初始的過程不可預測且缺乏控制過程為項目服務過程為組織服務過程已度量和控制集中于過程改進階段式成熟度等級95/154階段式模型階段式模型的結構類同于軟件CMM，它關96/154階段式模型的成熟度等級結構過程域2過程域n成熟度等級過程域1執(zhí)行的能力執(zhí)行的承諾定向實現驗證實現特定目標共性目標特定實踐共性實踐公共特征96/154階段式模型的成熟度等級結構過程域2過程域n成熟度97/154CMMIV1.1的24個過程域的分組如下：97/154CMMIV1.1的24個過程域的分組如下：98/154連續(xù)式模型連續(xù)式模型關注每個過程域的能力，一個組織對不同的過程域可以達到不同的過程域能力等級（Capabilitylevel，CL）。CMMI中包括六個過程域能力等級，等級號為0～5。能力等級表明了單個過程域中組織執(zhí)行的好壞程度。允許組織對連續(xù)式模型的過程域進行剪裁，也允許對不同的過程域采用不同的能力等級下圖給出了某組織的過程域能力等級98/154連續(xù)式模型連續(xù)式模型關注每個過程域的能力，一個組99/154能力等級特征示意圖CL0未完成的CL1已執(zhí)行的CL2已管理的CL3已定義的CL4定量管理的CL5優(yōu)化的過程域RSKMIPMSAMPMCPPITQPM99/154能力等級特征示意圖CL0未完成的CL1已執(zhí)行的C100/154能力等級包括共性目標及相關的共性實踐，這些實踐在過程域內被添加到特定目標和實踐中。當組織滿足過程域的特定目標和共性目標時，就說該組織達到了那個過程域的能力等級。能力等級2～5的名字與成熟度等級2～5同名，但含義不同。能力等級可以獨立地應用于任何單獨的過程域，任何一個能力等級都必須滿足比它等級低的能力等級的所有準則，各能力等級的含義簡述如下：100/154能力等級包括共性目標及相關的共性實踐，這些實踐101/154CL0未完成的：過程域未執(zhí)行或未達到CL1中定義的所有目標。CL1已執(zhí)行的：其共性目標是過程將可標識的輸入工作產品轉換成可標識的輸出工作產品，以實現支持過程域的特定目標。CL2已管理的：其共性目標集中于已管理的過程的制度化。根據組織級政策規(guī)定過程的運作將使用哪個過程，項目遵循已文檔化的計劃和過程描述，所有正在工作的人都有權使用足夠的資源，所有工作任務和工作產品都被監(jiān)控、控制和評審。101/154CL0未完成的：過程域未執(zhí)行或未達到CL1中102/154CL3已定義的：其共性目標集中于已定義的過程的制度化。過程是按照組織的剪裁指南從組織的標準過程集中剪裁得到的，還必須收集過程資產和過程的度量，并用于將來對該過程的改進上。CL4定量管理的：其共性目標集中于可定量管理的過程的制度化。使用測量和質量保證來控制和改進過程域，建立和使用關于質量和過程執(zhí)行的定量目標作為管理準則。CL5優(yōu)化的：使用量化（統(tǒng)計學）手段改編和優(yōu)化過程域，以對付客戶要求的改變和持續(xù)改進計劃中的過程域的功效。102/154CL3已定義的：其共性目標集中于已定義的過103/154連續(xù)式模型將24個過程域劃分為過程管理、項目管理、工程和支持四個過程組：103/154連續(xù)式模型將24個過程域劃分為過程管理、項目管104/154內容摘要計算機軟件軟件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境104/154內容摘要計算機軟件105/154軟件過程模型軟件過程模型是軟件開發(fā)全部過程、活動和任務的結構框架也稱軟件開發(fā)模型或軟件生存周期模型105/154軟件過程模型軟件過程模型是軟件開發(fā)全部過程、活106/154軟件過程模型典型的軟件過程模型有：瀑布模型（waterfallmodel）演化模型（evolutionarymodel）增量模型（incrementalmodel）原型模型（prototypingmodel)螺旋模型（spiralmodel）噴泉模型（waterfountainmodel）基于構件的開發(fā)模型（component-baseddevelopmentmodel）形式方法模型（formalmethodsmodel）106/154軟件過程模型典型的軟件過程模型有：107/154瀑布模型系統(tǒng)工程需求分析與規(guī)約設計與規(guī)約編碼與單元測試集成測試系統(tǒng)測試運行與維護107/154瀑布模型系統(tǒng)工程需求分析設計與編碼與集成測試運108/1541970年W.Royce提出瀑布模型

特征接受上一階段的結果作為本階段的輸入利用這一輸入實施本階段應完成的活動對本階段的工作進行評審將本階段的結果作為輸出，傳遞給下一階段

缺點缺乏靈活性，難以適應需求不明確或需求經常變化的軟件開發(fā)開發(fā)早期存在的問題往往要到交付使用時才發(fā)現，維護代價大108/1541970年W.Royce提出瀑布模型109/154許多軟件項目在開發(fā)早期對軟件需求的認識是模糊的、不確定的，因此軟件很難一次開發(fā)成功?？梢栽讷@取了一組基本的需求后，通過快速分析構造出該軟件的一個初始可運行版本，稱之謂原型（prototype），然后根據用戶在試用原型的過程中提出的意見和建議、或者增加新的需求，對原型進行改造，獲得原型的新版本，重復這一過程，最終得到令客戶滿意的軟件產品。演化模型的開發(fā)過程就是從構造初始的原型出發(fā)，逐步將其演化成最終軟件產品的過程。演化模型適用于對軟件需求缺乏準確認識的情況。典型的演化模型有：增量模型、原型模型、螺旋模型。演化模型109/154許多軟件項目在開發(fā)早期對軟件需求的認識是模糊的110/154增量模型項目日歷時間軟件功能性和特征12345第2次增量發(fā)布增量212345第n次增量發(fā)布增量n12345第1次增量發(fā)布增量1┇5部署（發(fā)布，反饋）4構造（編碼，測試）3建模（分析，設計）2計劃1交流110/154增量模型項目日歷時間軟件功能性和特征12345111/154增量模型將軟件的開發(fā)過程分成若干個日程時間交錯的線性序列，每個線性序列產生軟件的一個可發(fā)布的“增量”版本，后一個版本是對前一版本的修改和補充，重復增量發(fā)布的過程，直至產生最終的完善產品。增量模型融合了瀑布模型的基本成分（重復地應用）和演化模型的迭代特征增量模型強調每一個增量都發(fā)布一個可運行的產品111/154增量模型將軟件的開發(fā)過程分成若干個日程時間交錯112/154增量模型特別適用于：需求經常變化的軟件開發(fā)市場急需而開發(fā)人員和資金不能在設定的市場期限之前實現一個完善的產品的軟件開發(fā)增量模型能有計劃地管理技術風險，如早期增量版本中避免采用尚未成熟的技術112/154增量模型特別適用于：113/154原型（prototype）是預期系統(tǒng)的一個可執(zhí)行版本，它反映了系統(tǒng)性質（如功能、計算結果等）的一個選定的子集。一個原型不必滿足目標軟件的所有約束，其目的是能快速、低成本地構建原型。原型方法從軟件工程師與客戶的交流開始，其目的是定義軟件的總體目標，標識需求。然后快速制訂原型開發(fā)的計劃，確定原型的目標和范圍，采用快速設計的方式對其建模，并構建原型。被開發(fā)的原型應交付給客戶試用，并收集客戶的反饋意見，這些反饋意見可在下一輪迭代中對原型進行改進。在前一個原型需要改進，或者需要擴展其范圍的時候，進入下一輪原型的迭代開發(fā)。原型模型113/154原型（prototype）是預期系統(tǒng)的一個可執(zhí)114/154部署交付和反饋構建原型交流快速設計方式建?？焖儆媱澰湍Ｐ?14/154部署交付和反饋構建原型交流快速設計方式建?？焖?15/154原型的類型：探索型（exploratoryprototyping）其目的是要弄清目標系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性實驗型（experimentalprototyping）其目的是驗證方案或算法的合理性，它是在大規(guī)模開發(fā)和實現前，用于考核方案是否合適，規(guī)格說明是否可靠。演化型（evolutionaryprototyping）其目的是將原型作為目標系統(tǒng)的一部分，通過對原型的多次改進，逐步將原型演化成最終的目標系統(tǒng)。115/154原型的類型：116/154原型的使用策略：廢棄（throwaway）策略主要用于探索型和實驗型原型的開發(fā)。這些原型關注于目標系統(tǒng)的某些特性，而不是全部特性，開發(fā)這些原型時通常不考慮與探索或實驗目的無關的功能、質量、結構等因素，這種原型通常被廢丟，然后根據探索或實驗的結果用良好的結構和設計思想重新設計目標系統(tǒng)。追加（addon）策略主要用于演化型原型的開發(fā)。這種原型通常是實現了目標系統(tǒng)中已明確定義的特性的一個子集，通過對它的不斷修改和擴充，逐步追加新的要求，最后使其演化成最終的目標系統(tǒng)。原型可作為單獨的過程模型使用，它也常被作為一種方法或實現技術應用于其它的過程模型中。116/154原型的使用策略：117/154B.Boehm于1988年提出是瀑布模型和演化模型的結合，并增加了風險分析螺旋模型沿著螺線旋轉，在四個象限上分別表達四個方面的活動，即：制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件風險分析：評價所選的方案，識別風險，消除風險工程實施：實施軟件開發(fā)，驗證工作產品客戶評估：評價開發(fā)工作，提出修正建議螺旋模型117/154B.Boehm于1988年提出螺旋模型118/154

118/154119/154螺旋模型出現了一些變種，它可以有3到6個任務區(qū)域。螺旋模型指引的軟件項目開發(fā)沿著螺線自內向外旋轉，每旋轉一圈，表示開發(fā)出一個更為完善的新軟件版本。如果發(fā)現風險太大，開發(fā)者和客戶無法承受，則項目就可能因此而終止。多數情況下沿著螺線的活動會繼續(xù)下去，自內向外，逐步延伸，最終得到所期望的系統(tǒng)。119/154螺旋模型出現了一些變種，它可以有3到6個任務區(qū)120/154噴泉模型120/154噴泉模型121/154噴泉模型是一種支持面向對象開發(fā)的模型體現迭代和無間隙特征迭代：各開發(fā)活動常常重復工作多次，相關的功能在每次迭代中隨之加入演進的系統(tǒng)無間隙：開發(fā)活動之間不存在明顯的邊界121/154噴泉模型是一種支持面向對象開發(fā)的模型122/154支持軟件復用（reuse）利用預先包裝好的軟件構件（包括組織內部開發(fā)的構件和現存商品化構件COTS）來構造應用系統(tǒng)基于構件的開發(fā)模型122/154支持軟件復用（reuse）基于構件的開發(fā)模型123/154領域分析構件可變性分析構建可復用構件領域模型領域基準體系結構圖可復用構件庫分析體系結構設計獲取構件構件特化和修改評價構件組裝和測試開發(fā)未找到構件的部分應用系統(tǒng)工程應用系統(tǒng)領域工程123/154領域分析構件可變性構建領域模型領域基準可復用分124/154領域工程的目的是構建領域模型、領域基準體系結構和可復用構件庫。領域分析分析該領域中各種應用系統(tǒng)的公共部分或相似部分，構建領域模型和領域基準體系結構（referencearchitecture），標識領域的候選構件。對候選構件進行可變性分析，以適應多個應用系統(tǒng)的需要。構建可復用構件，經嚴格測試和包裝后存入可復用構件庫（稱為構件工程）。124/154領域工程的目的是構建領域模型、領域基準體系結構125/154應用系統(tǒng)工程的目的是使用可復用構件組裝應用系統(tǒng)。分析待開發(fā)的應用系統(tǒng)，設計應用系統(tǒng)的體系結構，標識應用系統(tǒng)所需的構件。在可復用構件庫中查找合適的構件（也可購買第三方的構件）。特化選中的構件，必要時作適當的修改，以適應該應用系統(tǒng)的需要。開發(fā)那些未找到合適構件的應用部分。組裝應用系統(tǒng)。評價構件的復用情況，以改進可復用構件，同時對新開發(fā)的部分進行評價，并向構件工程推薦候選構件。125/154應用系統(tǒng)工程的目的是使用可復用構件組裝應用系統(tǒng)126/154根據AT&T、Ericsson、HP公司的經驗，有的軟件復用率高達90%以上，產品上市時間可縮短2～5倍，錯誤率減少5～10倍，開發(fā)成本減少15%～75%。僅管這些結論出自一些較好使用基于構件開發(fā)的實例，但毫無疑問，基于構件的開發(fā)模型對提高軟件生產率、提高軟件質量、降低成本、提早上市時間起到很大的作用。126/154根據AT&T、Ericsson、HP公司的經驗127/154形式方法模型形式化方法（formalmethods）是建立在嚴格數學基礎上的一種軟件開發(fā)方法。軟件開發(fā)的全過程中，從需求分析、規(guī)約、設計、編程、系統(tǒng)集成、測試、文檔生成、直至維護各個階段，凡是采用嚴格的數學語言，具有精確的數學語義的方法，都稱為形式化方法。形式化方法用嚴格的數學語言和語義描述功能規(guī)約和設計規(guī)約，通過數學的分析和推導，易于發(fā)現需求的岐義性、不完整性和不一致性，易于對分析模型、設計模型和程序進行驗證。通過數學的演算，使得從形式化功能規(guī)約到形式化設計規(guī)約，以及從形式化設計規(guī)約到程序代碼的轉換成為可能。127/154形式方法模型形式化方法（formalmeth128/154凈室過程模型系統(tǒng)工程需求收集代碼審查盒結構規(guī)約形式化設計正確性驗證代碼生成統(tǒng)計使用測試認證測試計劃增量1需求收集代碼審查盒結構規(guī)約形式化設計正確性驗證代碼生成統(tǒng)計使用測試認證測試計劃需求收集代碼審查盒結構規(guī)約形式化設計正確性驗證代碼生成統(tǒng)計使用測試認證測試計劃增量2增量3128/154凈室過程模型需求代碼盒結構規(guī)約形式化設計正確性129/154內容摘要計算機軟件軟件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境129/154內容摘要計算機軟件130/154敏捷軟件開發(fā)軟件開發(fā)的新挑戰(zhàn)快速的市場進入時間，要求高生產率快速變化的需求快速發(fā)展的技術傳統(tǒng)的軟件開發(fā)方法強調過程強調文檔開發(fā)人員負擔過重稱為重載(Heavyweight)方法130/154敏捷軟件開發(fā)軟件開發(fā)的新挑戰(zhàn)131/154針對上述問題，產生了一系列輕載(Lightweight)方法，如XP、SCRUM等。2001年2月，新方法的一些創(chuàng)始人在美國猶他州成立了敏捷軟件開發(fā)聯(lián)盟，簡稱Agile聯(lián)盟。Agile聯(lián)盟起草了一個敏捷軟件開發(fā)宣言，該宣言由四個價值觀聲明組成，并提煉出敏捷軟件開發(fā)方法必須遵循的12條原則。Agile方法是在保證軟件開發(fā)有成功產出的前提下，盡量減少開發(fā)過程中的活動和制品的方法?；\統(tǒng)的講就是，“剛剛好”（Justenough），即開發(fā)中的活動及制品既不要太多也不要太少。131/154針對上述問題，產生了一系列輕載(Lightwe132/154Agile方法的價值觀個人和交互高于過程和工具不是否定過程和工具的重要性，而是更強調軟件開發(fā)中人的作用和交流的作用。軟件是由人組成的團隊來開發(fā)的，與軟件項目相關的各類人員通過充分的交流和有效的合作，才能成功地開發(fā)出得到用戶滿意的軟件。如果光有定義良好的過程和先進的工具，而人員的技能很差，又不能很好地交流和協(xié)作，軟件是很難成功地開發(fā)的。132/154Agile方法的價值觀個人和交互高于過程和工具133/154可運行軟件高于詳盡的文檔通過執(zhí)行一個可運行的軟件來了解軟件做了什么，遠比閱讀厚厚的文檔要容易得多。敏捷軟件開發(fā)強調不斷地快速地向用戶提交可運行的軟件（不一定是完整的軟件），以得到用戶的認可。好的必要的文檔仍是需要的，它能幫助我們理解軟件做什么，怎么做以及如何使用，但軟件開發(fā)的主要目標是創(chuàng)建可運行的軟件。133/154可運行軟件高于詳盡的文檔134/154與客戶協(xié)作高于合同（契約）談判只有客戶才能明確說明需要什么樣的軟件，然而，大量的實踐表明，在開發(fā)的早期客戶常常不能完整地表達他們的全部需求，有些早期確定的需求，以后也可能會改變。要想通過合同談判的方式，將需求固定下來常常是困難的。敏捷軟件開發(fā)強調與客戶的協(xié)作，通過與客戶的交流和緊密合作來發(fā)現用戶的需求。134/154與客戶協(xié)作高于合同（契約）談判135/154對變更及時做出反應高于遵循計劃任何軟件項目的開發(fā)都應該制訂一個項目計劃，以確定各開發(fā)任務的優(yōu)先順序和起止日期。然而，隨著項目的進展，需求、業(yè)務環(huán)境、技術等都可能變化，任務的優(yōu)先順序和起止日期也可能因種種原因會改變。因此，項目計劃應具有可塑性，有變動的余地。當出現變化時及時做出反應，修訂計劃以適應變化。135/154對變更及時做出反應高于遵循計劃136/154Agile方法的指導原則（1）最優(yōu)先的是通過盡早地和不斷地提交有價值的軟件使客戶滿意（2）歡迎變化的需求，即使該變化出現在開發(fā)的后期，為了提升對客戶的競爭優(yōu)勢，Agile過程利用變化作為動力（3）以幾周到幾個月為周期，盡快、不斷地發(fā)布可運行軟件（4）在整個項目過程中，業(yè)務人員和開發(fā)人員必須天天一起工作136/154Agile方法的指導原則（1）最優(yōu)先的是通過盡137/154（5）以積極向上的員工為中心建立項目組，給予他們所需的環(huán)境和支持，對他們的工作予以充分的信任（6）項目組內效率最高、最有效的信息傳遞方式是面對面的交流（7）測量項目進展的首要依據是可運行的軟件（8）敏捷過程提倡可持續(xù)的開發(fā)，項目發(fā)起者、開發(fā)者和用戶應能長期保持恒定的速度137/154（5）以積極向上的員工為中心建立項目組，給予他138/154（9）應時刻關注技術上的精益求精和好的設計，以增強敏捷性（10）簡單化是必不可少的，這是盡可能減少不必要工作的藝術（11）最好的構架、需求和設計出自于自我組織的團隊（12）團隊要定期反思怎樣才能更有效，并據此調整自己的行為138/154（9）應時刻關注技術上的精益求精和好的設計，139/154Agile方法的適用范圍MartinFowler認為：新方法不是到處可適用的適合采用Agile方法的情況：需求不確定、易揮發(fā)（Volatile,意指今天的要求明天就不需要了）有責任感和積極向上的開發(fā)人員用戶容易溝通并能參與139/154Agile方法的適用范圍MartinFowl140/154Agile的典型方法ExtremeProgramming(簡稱XP)SCRUMCrystalMethodologies(簡稱Crystal)FeatureDrivenDevelopment(簡稱FDD)DynamicSystemsDevelopmentMethodology(簡稱DSDM)AdaptiveSoftwareDevelopment(簡稱ASD)PragmaticProgramming等140/154Agile的典型方法ExtremeProgr141/154XP方法由KentBeck提出，是Agile方法中最引人注目的一個XP最初實踐于1997年Crysler公司的C3項目(Smalltalk開發(fā)）適用于10人以下項目組、開發(fā)地點集中的場合廣泛用于需求模糊和揮發(fā)性強的場合IONA公司的Obix技術支持小組在采用了XP方法后，軟件生產率提高了67%141/154XP方法由KentBeck提出，是Agile142/154XP方法的4個價值觀交流（Communication）實踐表明，項目失敗的重要原因之一是交流不暢，使得客戶的需求不能準確地傳遞給開發(fā)人員，造成開發(fā)人員不能充分理解需求；模型或設計的變動未能及時告知相關人員，造成系統(tǒng)的不一致和集成的困難所有項目相關人員之間充分的有效的交流是軟件開發(fā)成功所必不可少的XP方法提倡面對面的交流，這是一種有效的也是效率最高的交流方式142/154XP方法的4個價值觀交流（Communicat143/154簡單（Simplicity）指在確保得到客戶滿意的軟件的前提下，做最簡潔的工作（簡單的過程、模型、文檔、設計和實現）在開發(fā)中不斷優(yōu)化設計，時刻保持代碼簡潔、無冗余體現了敏捷開發(fā)的“剛剛好(Justenough)”思想，即開發(fā)中的活動及制品既不要太多也不要太少，剛好即可143/154簡單（Simplicity）144/154反饋（Feedback）及時有效的反饋能確定開發(fā)工作是否正確，及時發(fā)現開發(fā)工作的偏差并加以糾正。強調各種形式的反饋，如非正式的評審（走查，Walkthrough）、小發(fā)布等144/154反饋（Feedback）145/154勇氣（Courage）采用敏捷軟件開發(fā)需要勇氣：信任合作的同事，也相信自己做能做到的最簡單的事只有在絕對需要的時候才創(chuàng)建文檔讓業(yè)務人員制定業(yè)務決策，技術人員制定技術決策用可能的最簡單的工具，例如白板和紙，只有在復雜建模工具能提供可能的最好價值時才去使用它們相信程序員能制定設計決策，不需要給他們提供過多的細節(jié)需要勇氣來承認自己是會犯錯誤的，需要勇氣來相信自己明天能克服明天出現的問題。145/154勇氣（Courage）146/154XP方法的12個核心實踐1.完整的團隊（WholeTeam）所有的小組成員應在同一個工作地點工作成員中必須有一個現場用戶（On-siteUser）由他提出需求，確定開發(fā)優(yōu)先級通常還設一個“教練”（Coach）角色

教練指導XP方法的實施，以及與外部的溝通和協(xié)調2.計劃對策（PlanningGame）

包括兩類：發(fā)布計劃和迭代（Iteration）計劃146/154XP方法的12個核心實踐1.完整的團隊（Who147/1543.系統(tǒng)比喻（Metaphor）

系統(tǒng)比喻是待開發(fā)軟件的一個每個成員都熟悉的形象化比喻，相當于一個粗略的軟件體系結構4.小發(fā)布（Smallrelease）

經常、不斷地發(fā)布可運行的、具有商業(yè)價值的小軟件版本，供現場用戶評估或最終使用