軟件工程概述相關(guān)附件.ppt課件

1、1/154內(nèi)容摘要軟件的概念與特點(diǎn)軟件危機(jī)軟件工程軟件生命周期軟件過程敏捷軟件開發(fā)CASE工具與環(huán)境第一章 軟件工程概述水利工程建筑工程機(jī)械工程 軟件工程 本章將介紹軟件的地位和作用、軟件的特點(diǎn)、軟件 的發(fā)展、軟件危機(jī)、軟件工程、軟件生命周期以及軟件過程等方面的問題和基本概念傳統(tǒng)工程新興工程氣象工程生物工程1.1 軟件的概念與特點(diǎn)1、軟件softwaresoft+ware軟制品(軟體) 軟件是計算機(jī)系統(tǒng)中與硬件相互依存的另一部分。 它包括程序、數(shù)據(jù)及其相關(guān)文檔的完整集合。2、軟件特點(diǎn). 軟件是一種邏輯實體，而不是具體的物理實體. 軟件的生產(chǎn)與硬件不同 . 在軟件的運(yùn)行和使用期間，沒有硬件那樣的

2、機(jī)械 磨損，老化問題磨合調(diào)整磨損用壞修改點(diǎn)實際曲線理想曲線硬件失效率曲線時間失效率時間失效率軟件失效率曲線. 軟件的成本相當(dāng)昂貴軟件技術(shù)的發(fā)展落后于需求時間軟件復(fù)雜性軟件需求差距軟件技術(shù)硬、軟件成本比例的變化年份成本%軟件1950197019851995硬件3、軟件的分類1、按軟件的功能進(jìn)行劃分系統(tǒng)軟件支撐軟件應(yīng)用軟件支撐軟件一般類型： 文本編輯程序 文本格式化程序支持需求分析： PSL/PSA問題描述語言 關(guān)系數(shù)據(jù)庫管理系統(tǒng)支持設(shè)計： 圖形軟件包 結(jié)構(gòu)化流程圖繪圖程序支持測試： 靜態(tài)分析器 測試覆蓋檢驗程序支持實現(xiàn)： 編輯程序 連接編輯程序支持管理： 標(biāo)準(zhǔn)檢驗程序 庫管理程序2、按軟件的規(guī)模

3、進(jìn)行劃分 按開發(fā)軟件所需的 人力、時間以及完成的 源代碼行數(shù)。類別參加人數(shù)研制期限產(chǎn)品規(guī)模(源代碼行數(shù))微型小型中型大型甚大型極大型112-55-20100-10002000-50001-4周1-6周1-2年2-3年4-5年5-10年約500行 約2000行 5000-50000行5萬-10萬行100萬行1000萬行 3、按軟件開發(fā)劃分軟件項目開發(fā)軟件產(chǎn)品開發(fā)上個世紀(jì)60年代開始顯現(xiàn)出來的“軟件危機(jī)”催生了“軟件工程”這門指導(dǎo)計算機(jī)軟件開發(fā)和維護(hù)的工程學(xué)科。1、什么是軟件危機(jī)軟件危機(jī)是指在計算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。1.2 軟件危機(jī)2、 產(chǎn)生軟件危機(jī)的原因 軟件缺乏“可

4、見性”。 對用戶需求沒有完整準(zhǔn)確的認(rèn)識、不能適應(yīng)用戶需求的變化。 缺乏對軟件產(chǎn)品和開發(fā)過程的質(zhì)量控制。 軟件本身的可維護(hù)性差、開發(fā)商缺乏對維護(hù)的重視和準(zhǔn)備、缺乏正確的維護(hù)方法。導(dǎo)致“對軟件開發(fā)成本、工作量、進(jìn)度的估計不準(zhǔn)確”；導(dǎo)致“用戶對已完成的軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生”；導(dǎo)致“軟件產(chǎn)品的質(zhì)量往往靠不住”；導(dǎo)致“軟件常常不可維護(hù)”； 開發(fā)、維護(hù)過程中文檔化工作做得不好、缺乏配置管理。 硬件成本逐年下降，但軟件成本居高不下。 近10來年，軟件開發(fā)生產(chǎn)率有較大的提高，但計算機(jī)應(yīng)用普及深入的速度更快。導(dǎo)致“軟件通常不具有良好一致性的文檔資料”；導(dǎo)致“軟件成本在計算機(jī)系統(tǒng)總成本中所占的比例逐年上升

5、”；導(dǎo)致“軟件開發(fā)生產(chǎn)率提高的速度，跟不上計算機(jī)應(yīng)用普及深入的速度”。3、 解決軟件危機(jī)的途徑首先，應(yīng)該對軟件產(chǎn)品、系統(tǒng)有一個正確的認(rèn)識。軟件不僅僅是程序。IEEE對軟件的定義：Computer programs, procedures, associated documentation and data pertaining to the operation of a computer system.應(yīng)該充分認(rèn)識軟件開發(fā)是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同完成的工程項目。應(yīng)該總結(jié)軟件開發(fā)的成功經(jīng)驗，應(yīng)用軟件工程領(lǐng)域的先進(jìn)思想、原理、方法、技術(shù)（針對具體公司、項目進(jìn)行定制）。最后，

6、應(yīng)該（開發(fā)）、采用適當(dāng)?shù)能浖ぞ?，尤其是CASE工具，來幫助完成軟件開發(fā)工作。1.3 軟件工程1、 軟件工程介紹軟件工程是指導(dǎo)計算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科。采用工程的概念、原理、技術(shù)和方法來開發(fā)和維護(hù)軟件，并融合其他學(xué)科、行業(yè)（如：管理、建筑、客戶服務(wù)）的原理、技術(shù)和經(jīng)驗，以規(guī)范、高效、可度量、可管理地開發(fā)出高質(zhì)量的軟件并維護(hù)它?！敖?jīng)濟(jì)”？軟件工程特性：更多關(guān)注大型程序的構(gòu)造；關(guān)注對復(fù)雜性、風(fēng)險的控制，關(guān)注可度量、可管理性；重視軟件系統(tǒng)的變化，要求軟件系統(tǒng)對變化的適應(yīng)性，要求變動控制；強(qiáng)調(diào)軟件開發(fā)的效率（涉及方法、工具）；強(qiáng)調(diào)合作開發(fā)、團(tuán)隊協(xié)作、溝通重視用戶（需求、反饋、技術(shù)支持等），重

7、視和用戶的交流；強(qiáng)調(diào)軟件系統(tǒng)應(yīng)能為用戶提供價值、可用性；強(qiáng)調(diào)開發(fā)團(tuán)隊?wèi)?yīng)具備相關(guān)行業(yè)的業(yè)務(wù)知識、建立系統(tǒng)語境、通過有效溝通準(zhǔn)確捕獲用戶需求。2、 軟件工程的基本原理Barry W. Boehm總結(jié)既有的軟件工程準(zhǔn)則，提出了7條軟件工程基本原理：1 用分階段的生命周期計劃嚴(yán)格管理;2 堅持進(jìn)行階段評審;3 實行嚴(yán)格的產(chǎn)品控制（配置管理）;4 采用現(xiàn)代（先進(jìn)的）程序設(shè)計技術(shù);5 結(jié)果應(yīng)能清楚地審查;6 開發(fā)小組的成員應(yīng)該少而精;7 承認(rèn)不斷改進(jìn)軟件工程實踐的必要性;3、 軟件工程的方法學(xué)通常把在軟件生命周期全過程中使用的一整套技術(shù)方法的集合稱為方法學(xué)methodology。軟件工程方法學(xué)包含3個要素

8、：方法、工具和過程。* 軟件工程傳統(tǒng)途徑（傳統(tǒng)方法學(xué)）把軟件生命周期的全過程依次劃分為若干個階段，順序地完成每個階段的任務(wù)。每一個階段的開始和結(jié)束都有準(zhǔn)則或標(biāo)準(zhǔn)。采用結(jié)構(gòu)化技術(shù)（結(jié)構(gòu)化分析、設(shè)計和實現(xiàn)）來完成軟件開發(fā)各階段的各項任務(wù)。每個階段結(jié)束前都進(jìn)行正式的技術(shù)審查和管理復(fù)審。技術(shù)審查幫助即時、盡早發(fā)現(xiàn)、糾正工程技術(shù)方面的錯誤；保證軟件質(zhì)量。軟件錯誤的積累和放大效應(yīng)圖目標(biāo)主要是各個階段的工程制品。如：系統(tǒng)范圍是否恰當(dāng)？技術(shù)方案是否可行？架構(gòu)是否穩(wěn)定？模型是否正確？管理復(fù)審主要任務(wù)是對項目的開銷、工作量、資源（人力）、進(jìn)度、風(fēng)險等進(jìn)行審查。幫助決定開發(fā)是否繼續(xù)，幫助對下一階段的工作進(jìn)行計劃、對

9、軟件開發(fā)過程進(jìn)行改進(jìn)。* 面向?qū)ο蠓椒▽W(xué)客觀世界的問題都是由客觀世界中的實體及實體間的關(guān)系構(gòu)成的。用計算機(jī)系統(tǒng)解決客觀世界的問題，希望實現(xiàn)解法的解空間與問題空間的結(jié)構(gòu)盡可能一致。傳統(tǒng)語言提供的解空間對象不能滿足要求。面向?qū)ο蠓椒▽W(xué)提供的解空間與客觀世界問題空間的結(jié)構(gòu)更一致。面向?qū)ο蠓椒ㄊ前褦?shù)據(jù)和處理相結(jié)合的方法。對象是由數(shù)據(jù)及可以施加于這些數(shù)據(jù)的操作所構(gòu)成的統(tǒng)一體。面向?qū)ο蠓椒ò殉绦蚩醋魇窍嗷f(xié)作而又彼此獨(dú)立的對象的集合；而不是工作在數(shù)據(jù)上的過程或函數(shù)的集合。要點(diǎn)：1 面向?qū)ο蠓椒▽W(xué)認(rèn)識問題空間，分析、解決問題是用對象的觀點(diǎn)。2 把對象抽象為類，類中定義數(shù)據(jù)和方法；類實例化即為對象。3 類層次

10、結(jié)構(gòu)4 對象之間通過傳遞消息相互聯(lián)系。1.4 軟件生命周期不同時期，不同的目標(biāo)、任務(wù)。* 生命周期各階段的基本任務(wù)：1 問題定義 要解決的問題是什么？性質(zhì)、范圍？ 客戶的目標(biāo)？軟件系統(tǒng)的價值？最后系統(tǒng)分析員應(yīng)提交開發(fā)方和客戶都認(rèn)可的書面報告。2 可行性研究對上一階段提出的問題有可行的解決方案嗎？3 需求分析用戶有哪些具體需求？為了滿足客戶的需求，系統(tǒng)必須具備哪些功能？ 準(zhǔn)確、完整地捕獲用戶需求。 系統(tǒng)分析員要提出經(jīng)用戶確認(rèn)的系統(tǒng)邏輯模型。 技術(shù)可行性 經(jīng)濟(jì)可行性（時間、人員等） 操作可行性4 總體設(shè)計 / 架構(gòu)設(shè)計要解決問題、滿足用戶需求，軟件系統(tǒng)的總體架構(gòu)是怎樣的？ 首先，架構(gòu)設(shè)計師應(yīng)該考慮

11、幾種可能的解決方案（Windows/Linux、.Net/J2EE、C/S or B/S、滿足不同需求功能集的不同方案）。 選擇、推薦最佳方案。 對確定的方案進(jìn)行更具體的設(shè)計、描述（建立模型圖、說明），包括對軟件系統(tǒng)進(jìn)行模塊化，劃分子系統(tǒng)、確定接口。5 詳細(xì)設(shè)計軟件系統(tǒng)、子系統(tǒng)/模塊 具體應(yīng)該是怎樣的？ 算法（PDL語言、流程圖等）。 數(shù)據(jù)結(jié)構(gòu)、函數(shù)/過程、類的定義。 建立模型圖。6 編碼和單元測試 用選定的編程語言書寫程序（子系統(tǒng)/模塊、類/組件、函數(shù)等），然后編譯/翻譯/匯編為機(jī)器代碼。 對這些子系統(tǒng)/模塊進(jìn)行單元測試。7 綜合測試軟件是否實現(xiàn)了功能需求和非功能需求？ 集成測試 系統(tǒng)測試

12、用戶驗收測試寫：測試計劃（測試策略、進(jìn)度）、測試結(jié)果記錄、測試結(jié)果分析、評估、報告。維護(hù)要求、審查、計劃（維護(hù)方案）、維護(hù)、回歸測試、維護(hù)記錄、復(fù)查驗收。8 維護(hù) 改正性維護(hù) 適應(yīng)性維護(hù) 完善性維護(hù) 預(yù)防性維護(hù)1.5 軟件過程軟件過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項任務(wù)的工作步驟。 通常使用生命周期模型簡潔、直觀地描述軟件開發(fā)、運(yùn)行、維護(hù)的過程。能力成熟度模型CMMCMM（Capability Maturity Model）即能力成熟度模型，是美國卡耐基梅隆大學(xué)軟件工程研究所（SEI）在美國國防部資助下于二十世紀(jì)八十年代末建立的，用于評價軟件機(jī)構(gòu)的軟件過程能力

13、成熟度的模型。此模型在建立和發(fā)展之初，主要目的在于提供一種評價軟件承接方能力的方法，為大型軟件項目的招投標(biāo)活動提供一種全面而客觀的評審依據(jù)。而發(fā)展到后來，又同時被軟件組織用于改進(jìn)其軟件過程。軟件組織的成熟與不成熟 1. 不成熟的軟件組織軟件過程一般并不預(yù)先計劃，而是在項目進(jìn)行中由實際工作人員及管理員臨時計劃有時，即使軟件過程已計劃好，仍不按計劃執(zhí)行沒有一個客觀的基準(zhǔn)來判斷產(chǎn)品質(zhì)量，或解決產(chǎn)品和過程中的問題對軟件過程步驟如何影響軟件質(zhì)量，一無所知，產(chǎn)品質(zhì)量得不到保證。而且，一些提高質(zhì)量的環(huán)節(jié)，如檢查、測試等經(jīng)常由于要趕進(jìn)度而減少或取消產(chǎn)品在交付前，對客戶來說，一切都是不可見的沒有長遠(yuǎn)目標(biāo)，管理員

14、通常只關(guān)注解決任何當(dāng)前的危機(jī)由于沒有實事求是地估計進(jìn)度、預(yù)算，因此他們經(jīng)常超支、超時。當(dāng)最后期限臨近，他們往往在功能性和質(zhì)量上妥協(xié)，或以加班加點(diǎn)方式趕進(jìn)度2. 成熟的軟件組織具有全面而充分的組織和管理軟件開發(fā)和維護(hù)過程的能力管理員監(jiān)視軟件產(chǎn)品的質(zhì)量以及生產(chǎn)這些產(chǎn)品的過程制定了一系列客觀基準(zhǔn)來判別產(chǎn)品質(zhì)量，并分析產(chǎn)品和過程中的問題進(jìn)度和預(yù)算可以按照以前積累的經(jīng)驗來制定，結(jié)果可行。預(yù)期的成本、進(jìn)度、功能與性能和質(zhì)量都能實現(xiàn)，并達(dá)到目的能準(zhǔn)確及時地向工作人員通報實際軟件過程，并按照計劃有規(guī)則地(前后一致，不互相矛盾)工作凡規(guī)定的過程都編成文檔軟件過程和實際工作方法相吻合。必要時，過程定義會及時更新，

15、通過測試，或者通過成本-效益分析來改進(jìn)過程。全體人員普遍地、積極地參與改進(jìn)軟件過程的活動。在組織內(nèi)部的各項目中，每人在軟件過程中的職責(zé)都十分清晰而明確，每人各守其責(zé)，協(xié)同工作，有條不紊，甚至能預(yù)見和防范問題的發(fā)生。軟件過程成熟度等級 CMM提供了一個成熟度等級框架： 1級-初始級、 2級-可重復(fù)級、 3級-已定義級、 4級-已管理級和5級-優(yōu)化級。 1.初始（initial）級： 軟件過程的特點(diǎn)是無秩序的，甚至是混亂的。幾乎沒有什么過程是經(jīng)過妥善定義的，成功往往依賴于個人或小組的努力。2.可重復(fù)（repeatable）級： 建立了基本的項目管理過程來跟蹤成本、進(jìn)度和功能特性。制定了必要的過程紀(jì)

16、律，能重復(fù)早先類似應(yīng)用項目取得的成功。3.已定義（defined）級： 己將管理和工程活動兩方面的軟件過程文檔化、標(biāo)準(zhǔn)化，并綜合成該機(jī)構(gòu)的標(biāo)準(zhǔn)軟件過程。所有項目均使用經(jīng)批準(zhǔn)、剪裁的標(biāo)準(zhǔn)軟件過程來開發(fā)和維護(hù)軟件。4.已管理（managed）級： 收集對軟件過程和產(chǎn)品質(zhì)量的詳細(xì)度量值，對軟件過程和產(chǎn)品都有定量的理解和控制。 5.優(yōu)化（optimizing）級： 整個組織關(guān)注軟件過程改進(jìn)的持續(xù)性、預(yù)見及增強(qiáng)自身，防止缺陷及問題的發(fā)生。過程的量化反饋和先進(jìn)的新思想、新技術(shù)促使過程不斷改進(jìn)。5.優(yōu)化級4.已管理級3.已定義級2.可重復(fù)級1.初始級標(biāo)準(zhǔn)、一致的過程有紀(jì)律的過程可預(yù)測的過程持續(xù)改進(jìn)的過程軟件

17、過程成熟度的5個等級成熟度等級關(guān)鍵過程域共同特性關(guān)鍵實踐包含劃分為包含過程能力表明目標(biāo)實現(xiàn)實施或制度化解決活動或基礎(chǔ)設(shè)施描述CMM結(jié)構(gòu)能力成熟度模型的結(jié)構(gòu)能力成熟度模型的結(jié)構(gòu) 成熟度等級表明了一個軟件組織的過程能力的水平。除初始級外，每個成熟度等級都包含若干個關(guān)鍵過程域（Key Process Area，簡稱KPA）（見表1.2）達(dá)到某個成熟度級別，該級別（以及較低級別）的所有關(guān)鍵過程域都必須得到滿足，并且過程必須實現(xiàn)制度化。 CMM提供了18個關(guān)鍵過程域，每個關(guān)鍵過程域都有一組對改進(jìn)過程能力非常重要的目標(biāo)，并確定了一組相應(yīng)的關(guān)鍵實踐 目標(biāo)說明了每一個關(guān)鍵過程域的范圍、界限和意義。 關(guān)鍵實踐描

18、述了建立一個過程能力必須完成的活動和必須具備的基礎(chǔ)設(shè)施，完成了這些關(guān)鍵實踐就達(dá)到了相應(yīng)關(guān)鍵過程域的目標(biāo)，該關(guān)鍵過程域也就得到了滿足。每個關(guān)鍵過程域的關(guān)鍵實踐都是按照五個共同特性（執(zhí)行約定，執(zhí)行能力，執(zhí)行活動，測量和分析，驗證實現(xiàn)）進(jìn)行組織的，主要解決關(guān)鍵實踐的實施或制度化問題。 共同特性將描述關(guān)鍵過程域的關(guān)鍵實踐組織起來。共同特性是一些屬性，指明一個關(guān)鍵過程域的執(zhí)行和規(guī)范化是否有效、可重復(fù)和可持續(xù)。共有5個共同特性: 執(zhí)行約定，執(zhí)行能力，執(zhí)行活動，測量和分析，驗證實現(xiàn)。1)執(zhí)行約定： 執(zhí)行約定描述機(jī)構(gòu)為確保過程的建立和持續(xù)而必須采取的一些措施。典型內(nèi)容包括建立機(jī)構(gòu)策略和領(lǐng)導(dǎo)關(guān)系。2)執(zhí)行能力：

19、 執(zhí)行能力描述了項目或機(jī)構(gòu)完整地實現(xiàn)軟件過程所必須有的先決條件。典型內(nèi)容包括資源、機(jī)構(gòu)結(jié)構(gòu)和培訓(xùn)。3)執(zhí)行活動： 執(zhí)行活動描述了執(zhí)行一個關(guān)鍵過程域所必需的活動、任務(wù)和規(guī)程。典型內(nèi)容包括制定計劃和規(guī)程、執(zhí)行和跟蹤以及必要時采取糾正措施。4)測量和分析： 測量和分析描述了為確定與過程有關(guān)的狀態(tài)所需的基本測量實踐。這些測量可用來控制和改進(jìn)過程。典型內(nèi)容包括可能采用的測量實例。5)驗證實現(xiàn)： 驗證實現(xiàn)描述了為確保執(zhí)行的活動與已建立的過程一致所采取的步驟。典型內(nèi)容包括管理部門和軟件質(zhì)量保證組實施的評審和審核。在執(zhí)行活動這個共同特性中的實踐描述了建立一個過程能力所必須完成的活動。所有其他實踐共同形成了一個

20、使機(jī)構(gòu)能將執(zhí)行活動中描述的實踐進(jìn)行規(guī)范化的基礎(chǔ)。各關(guān)鍵過程域的詳細(xì)描述，參見能力成熟度模型（CMM）：軟件過程改進(jìn)指南，卡耐基梅隆大學(xué)軟件工程研究所編著，劉孟仁等譯，電子工業(yè)出版社出版。缺陷預(yù)防技術(shù)更新管理過程更改管理優(yōu)化級定量過程管理軟件質(zhì)量管理已管理級機(jī)構(gòu)過程焦點(diǎn)機(jī)構(gòu)過程定義培訓(xùn)大綱綜合軟件管理軟件產(chǎn)品工程組間協(xié)調(diào)同行評審已定義級需求管理軟件項目計劃軟件項目跟蹤和監(jiān)督軟件分包合同管理軟件質(zhì)量保證軟件配置管理可重復(fù)級初始級能力成熟度級別中的關(guān)鍵過程域關(guān)鍵過程域?qū)嵗龣C(jī)構(gòu)過程焦點(diǎn)第3級的關(guān)鍵過程域：已定義級 機(jī)構(gòu)過程焦點(diǎn)的目的是，為能改進(jìn)機(jī)構(gòu)整體軟件過程能力的軟件過程活動 建立機(jī)構(gòu)的職責(zé)。 機(jī)構(gòu)

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

22、圍內(nèi)的軟件過程開發(fā)和改進(jìn)活動。 該策略一般規(guī)定: 1. 建立一個小組，負(fù)責(zé)機(jī)構(gòu)級的軟件過程活動，使這些活動與各項目協(xié)調(diào)一致。 2. 定期評估項目所使用的軟件過程，以確定其優(yōu)勢和薄弱環(huán)節(jié)。 3. 對機(jī)構(gòu)標(biāo)準(zhǔn)軟件過程進(jìn)行合理地剪裁，以得到項目使用的軟件過程。 關(guān)于機(jī)構(gòu)標(biāo)準(zhǔn)軟件過程，參見綜合軟件管理關(guān)鍵過程域的活動1。4. 每個項目的軟件過程、工具和方法的改進(jìn)和其他有用信息，可用于其他項目。約定2：上級管理部門倡導(dǎo)和支持機(jī)構(gòu)的軟件過程開發(fā)和改進(jìn)活動。 上級管理部門： 1. 向機(jī)構(gòu)成員和負(fù)責(zé)人說明有關(guān)軟件過程活動的約定。 2. 制定資金、人員配備和其他資源的長期計劃和約定。 3. 制定管理和執(zhí)行有關(guān)軟

23、件過程開發(fā)和改進(jìn)活動的策略。約定3：上級管理部門監(jiān)督機(jī)構(gòu)的軟件過程開發(fā)和改進(jìn)活動。 l. 確保機(jī)構(gòu)標(biāo)準(zhǔn)軟件過程滿足企業(yè)目標(biāo)和策略。 2. 提出關(guān)于軟件過程開發(fā)和改進(jìn)活動優(yōu)先次序的建議。 3. 參與制定軟件過程開發(fā)和改進(jìn)計劃。 a. 上級管理部門與更高層人員和負(fù)責(zé)人共同協(xié)調(diào)軟件過程需求及問題 b. 上級管理部門與該機(jī)構(gòu)負(fù)責(zé)人進(jìn)行協(xié)調(diào)，以獲得負(fù)責(zé)人和機(jī)構(gòu)成員的支持和參與執(zhí)行能力能力1：有一個負(fù)責(zé)機(jī)構(gòu)的軟件過程活動的小組。 一個小組是一些部門、負(fù)責(zé)人和人員的組合，負(fù)責(zé)一組任務(wù)和活動。小組的規(guī)?？梢圆煌?，既可以是單個兼職的人，也可以是多個來自不同部門的兼職人員，也可以由幾個專職人員組成。組成小組時考慮

24、的因素包括：分派的任務(wù)和活動、項目規(guī)模、機(jī)構(gòu)結(jié)構(gòu)和機(jī)構(gòu)文化。某些小組，如軟件質(zhì)量保證組，集中關(guān)注項目活動;而其他一些小組，例如軟件工程過程組，集中關(guān)注機(jī)構(gòu)范圍內(nèi)的活動。 1. 條件可能時，小組成員以專職工作的軟件專業(yè)人員為核心，并盡可能有其他的兼職人員支持。 該小組最一般的例子是軟件工程過程（SEPG）。 2. 小組成員中有軟件工程及軟件相關(guān)科目的代表。 軟件工程及軟件相關(guān)科目的實例有：軟件需求分析軟件設(shè)計程序編碼軟件測試軟件配置管理軟件質(zhì)量保證能力2：為實施機(jī)構(gòu)的軟件過程活動提供了充足的資源和資金。 1. 委派在特定領(lǐng)域具有特長的人員支持該小組。 特定領(lǐng)域的實例有：軟件重用計算機(jī)輔助軟件工程

25、技術(shù)(CASE) 測量培訓(xùn)課程開設(shè) 2. 有支持該機(jī)構(gòu)軟件過程活動的工具。 支持工具的實例有：統(tǒng)計分析工具桌面出版工具數(shù)據(jù)庫管理系統(tǒng)過程建模工具能力3：負(fù)責(zé)機(jī)構(gòu)軟件過程活動的小組成員接受過實施這些活動所需的培訓(xùn)。 培訓(xùn)的實例有：軟件工程實踐過程控制技術(shù)機(jī)構(gòu)過程變動管理軟件過程計劃、管理和監(jiān)督技術(shù)轉(zhuǎn)變參見培訓(xùn)大綱關(guān)鍵過程域能力4：軟件工程組和其他軟件相關(guān)小組的成員接受過機(jī)構(gòu)軟件過程活動及其在這些活動中的任務(wù)方面的定向培訓(xùn)。 參見培訓(xùn)大綱關(guān)鍵過程域執(zhí)行活動活動1：定期評估軟件過程，并根據(jù)評估結(jié)果制定行動計劃。 評估一般每隔一年、一年半至三年進(jìn)行一次。評估可針對機(jī)構(gòu)中所使用的所有軟件過程，也可通過對

26、過程和項目進(jìn)行抽樣評估。評估機(jī)構(gòu)軟件過程能力的方法實例之一是SEI軟件過程評估方法。 行動計劃標(biāo)識：涉及哪些評估結(jié)果針對評估結(jié)果實施更改軟件過程的準(zhǔn)則負(fù)責(zé)實施更改的小組或個人活動2：機(jī)構(gòu)制定和維護(hù)它的軟件過程開發(fā)和改進(jìn)活動的計劃。 該計劃：以軟件過程評估后的行動計劃和其他的機(jī)構(gòu)過程改進(jìn)倡議為基礎(chǔ)。確定要實施的活動及實施這些活動的進(jìn)度。確定負(fù)責(zé)這些活動的小組和個人。確定所需的資源，包括人員配備和工具。初始發(fā)布和有大改動時通過同行評審。 參見同行評審關(guān)鍵過程域。 6. 機(jī)構(gòu)的軟件負(fù)責(zé)人和上級負(fù)責(zé)人評審認(rèn)可?；顒?：在機(jī)構(gòu)級協(xié)調(diào)關(guān)于機(jī)構(gòu)和項目的軟件過程的開發(fā)和改進(jìn)活動。 涉及的軟件過程有： 1. 機(jī)

27、構(gòu)標(biāo)準(zhǔn)軟件過程。 關(guān)于機(jī)構(gòu)標(biāo)準(zhǔn)過程，參見機(jī)構(gòu)過程定義關(guān)鍵過程域的活動1和活動2。 2. 項目定義的軟件過程。 關(guān)于項目定義的軟件過程。參見綜合軟件管理關(guān)鍵過程域的活動1和活動2。活動4：在機(jī)構(gòu)級協(xié)調(diào)有關(guān)軟件過程數(shù)據(jù)庫的使用。 機(jī)構(gòu)的軟件過程數(shù)據(jù)庫用來收集機(jī)構(gòu)和項目的軟件過程以及生成的軟件產(chǎn)品的信息。 關(guān)于機(jī)構(gòu)的軟件過程數(shù)據(jù)庫，參見機(jī)構(gòu)過程定義關(guān)鍵過程域的活動5?；顒?：監(jiān)控和評價機(jī)構(gòu)中限制使用的新過程、方法和工具。合適時，推廣到機(jī)構(gòu)的其他部分?；顒?：在機(jī)構(gòu)內(nèi)協(xié)調(diào)機(jī)構(gòu)和項目的軟件過程的培訓(xùn)。 1. 制定有關(guān)機(jī)構(gòu)和項目軟件過程的專題培訓(xùn)計劃。 2. 合適時，培訓(xùn)由負(fù)責(zé)機(jī)構(gòu)軟件過程活動的小組（如軟

28、件工程過程組）或培訓(xùn)小組準(zhǔn)備和實施。 參見培訓(xùn)大綱關(guān)鍵過程域。活動7：向與實施軟件過程有關(guān)的小組通報機(jī)構(gòu)和項目中軟件過程開發(fā)和改進(jìn)活動的情況。 通報方式的實例有：過程電子公告板過程咨詢委員會工作小組信息交流會調(diào)查過程改進(jìn)組日常討論測量和分析測量1：測量機(jī)構(gòu)的軟件過程開發(fā)和改進(jìn)活動的狀態(tài) 測量的實例有：機(jī)構(gòu)在過程評估、開發(fā)和改進(jìn)活動中已完成的工作、工作量和耗費(fèi)的資金，與計劃相比較每次軟件過程的評估結(jié)果，與以前的評估結(jié)果和建議相比較驗證實現(xiàn)驗證1：上級管理部門定期評審軟件過程開發(fā)和改進(jìn)活動。 上級管理部門實施定期評審的主要目的是適當(dāng)?shù)?、及時地掌握軟件過程活動。在滿足機(jī)構(gòu)需求的前提下，只要有適當(dāng)?shù)臋C(jī)

29、制來報告異常情況，評審的時間間隔就盡可能長些。 1. 對照計劃，評審有關(guān)開發(fā)和改進(jìn)軟件過程活動的進(jìn)展和狀態(tài)。 2. 討論低層不能解決的沖突和問題。 3. 指定和評審行動措施，并跟蹤到關(guān)閉。 4. 編寫評審的總結(jié)報告，并分發(fā)給相關(guān)的小組和個人。能力成熟度模型集成CMMICapability Maturity Model IntegrationCMM的成功導(dǎo)致了各種模型的衍生，每一種模型都探討了某一特定領(lǐng)域中的過程改進(jìn)問題SW-CMM：適用于軟件開發(fā)SE-CMM：系統(tǒng)工程能力成熟度模型SA-CMM：適用于軟件獲取SECAM：系統(tǒng)工程能力評估模型People CMM：討論軟件組織吸引、開發(fā)、激勵、組

30、織和留住人才的能力EIA/IS 731：替代SW-CMM和SECAMIPD-CMM：適用于集成化產(chǎn)品開發(fā)FAA-iCMM：集成了SE-CMM、 SA-CMM、 SW-CMM相應(yīng)的國際標(biāo)準(zhǔn)： ISO/IEC 12207（軟件生存周期過程）、ISO/IEC 15288（系統(tǒng)生存周期過程）、ISO/IEC 15504（軟件過程評估）模型的繁衍導(dǎo)致模型框架、術(shù)語等方面的矛盾和不一致包含在當(dāng)代工程中各種各樣的學(xué)科和工程是密切交叉在一起的，應(yīng)用不同模型時效率低下且容易混淆，常常要付出極其昂貴的代價美國國防部、美國國防工業(yè)委員會和SEI/CMU于1998年啟動CMMI項目，希望CMMI是若干過程模型的綜合和

31、改進(jìn)，是支持多個工程學(xué)科和領(lǐng)域的系統(tǒng)的、一致的過程改進(jìn)框架，能適應(yīng)現(xiàn)代工程的特點(diǎn)和需要，能提高過程的質(zhì)量和工作效率2000年發(fā)布第一個CMMI模型CMMI-SE/SW/IPPD V1.0：集成了SW-CMM、EIA/IS 731、IPD CMM V0.982002年1月發(fā)布CMMI-SE/SW/IPPD V1.1，美國國防工業(yè)委員會在第一屆CMMI國際研討會上宣布， CMMI V1.1將至少穩(wěn)定五年不變CMMI模型為每個學(xué)科的組合都提供兩種表示法：階段式模型和連續(xù)式模型階段式模型階段式模型的結(jié)構(gòu)類同于軟件CMM，它關(guān)注組織的成熟度，其成熟度等級如下圖所示 5優(yōu)化的4定量管理的3已定義的2已管理

32、的1初始的過程不可預(yù)測且缺乏控制過程為項目服務(wù)過程為組織服務(wù)過程已度量和控制集中于過程改進(jìn)階段式成熟度等級過程域2過程域n成熟度等級過程域1執(zhí)行的能力執(zhí)行的承諾定向?qū)崿F(xiàn)驗證實現(xiàn)特定目標(biāo)共性目標(biāo)特定實踐共性實踐公共特征CMMI V1.1的24個過程域的分組如下：成熟度等級過程域已管理的需求管理REQM，項目計劃PP，項目監(jiān)督和控制PMC，供應(yīng)商合同管理SAM，度量和分析MA，過程和產(chǎn)品質(zhì)量保證PPQA，配置管理CM已定義的需求開發(fā)RD，技術(shù)解決方案TS，產(chǎn)品集成PI，驗證VER，確認(rèn)VAL，組織級過程焦點(diǎn)OPF，組織級過程定義OPD，組織級培訓(xùn)OT，集成化項目管理IPM，風(fēng)險管理RSKM，集成化

33、建組IT，決策分析和解決方案DAR，組織級集成環(huán)境OEI定量管理的組織級過程性能OPP，項目定量管理QPM優(yōu)化的組織級改革和實施OID，因果分析和解決方案CAR連續(xù)式模型連續(xù)式模型關(guān)注每個過程域的能力，一個組織對不同的過程域可以達(dá)到不同的過程域能力等級（Capability level，CL）。CMMI中包括六個過程域能力等級，等級號為05。能力等級表明了單個過程域中組織執(zhí)行的好壞程度。允許組織對連續(xù)式模型的過程域進(jìn)行剪裁，也允許對不同的過程域采用不同的能力等級下圖給出了某組織的過程域能力等級能力等級特征示意圖CL0未完成的CL1已執(zhí)行的CL2已管理的CL3已定義的CL4定量管理的CL5優(yōu)化的

34、過程域RSKMIPMSAMPMCPPITQPM能力等級包括共性目標(biāo)及相關(guān)的共性實踐，這些實踐在過程域內(nèi)被添加到特定目標(biāo)和實踐中。當(dāng)組織滿足過程域的特定目標(biāo)和共性目標(biāo)時，就說該組織達(dá)到了那個過程域的能力等級。能力等級25的名字與成熟度等級25同名，但含義不同。能力等級可以獨(dú)立地應(yīng)用于任何單獨(dú)的過程域，任何一個能力等級都必須滿足比它等級低的能力等級的所有準(zhǔn)則，各能力等級的含義簡述如下： CL0 未完成的：過程域未執(zhí)行或未達(dá)到CL1中定義的所有目標(biāo)。CL1 已執(zhí)行的：其共性目標(biāo)是過程將可標(biāo)識的輸入工作產(chǎn)品轉(zhuǎn)換成可標(biāo)識的輸出工作產(chǎn)品，以實現(xiàn)支持過程域的特定目標(biāo)。CL2 已管理的：其共性目標(biāo)集中于已管理

35、的過程的制度化。 根據(jù)組織級政策規(guī)定過程的運(yùn)作將使用哪個過程，項目遵循已文檔化的計劃和過程描述，所有正在工作的人都有權(quán)使用足夠的資源，所有工作任務(wù)和工作產(chǎn)品都被監(jiān)控、控制和評審。CL3 已定義的：其共性目標(biāo)集中于已定義的過程的制度化。 過程是按照組織的剪裁指南從組織的標(biāo)準(zhǔn)過程集中剪裁得到的，還必須收集過程資產(chǎn)和過程的度量，并用于將來對該過程的改進(jìn)上。CL4 定量管理的：其共性目標(biāo)集中于可定量管理的過程的制度化。使用測量和質(zhì)量保證來控制和改進(jìn)過程域，建立和使用關(guān)于質(zhì)量和過程執(zhí)行的定量目標(biāo)作為管理準(zhǔn)則。CL5 優(yōu)化的：使用量化（統(tǒng)計學(xué)）手段改編和優(yōu)化過程域，以對付客戶要求的改變和持續(xù)改進(jìn)計劃中的過

36、程域的功效。連續(xù)式模型將24個過程域劃分為過程管理、項目管理、工程和支持四個過程組：連續(xù)式分組過程域過程管理組織級過程焦點(diǎn)OPF，組織級過程定義OPD，組織級培訓(xùn)OT，組織級過程性能OPP，組織級改革和實施OID項目管理項目計劃PP，項目監(jiān)督和控制PMC，供應(yīng)商合同管理SAM，集成化項目管理IPM，風(fēng)險管理RSKM，集成化建組IT，項目定量管理QPM工 程需求管理REQM，需求開發(fā)RD，技術(shù)解決方案TS，產(chǎn)品集成PI，驗證VER，確認(rèn)VAL支 持配置管理CM，過程和產(chǎn)品質(zhì)量保證PPQA，度量和分析MA，決策分析和解決方案DAR，組織級集成環(huán)境OEI，因果分析和解決方案CAR內(nèi)容摘要計算機(jī)軟件軟

37、件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境軟件過程模型軟件過程模型是軟件開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架也稱軟件開發(fā)模型或軟件生存周期模型軟件過程模型典型的軟件過程模型有：瀑布模型（waterfall model）演化模型（evolutionary model）增量模型（incremental model）原型模型（prototyping model)螺旋模型（spiral model）噴泉模型（water fountain model）基于構(gòu)件的開發(fā)模型（component-based development model）形式方法模型（formal methods model

38、）瀑布模型系統(tǒng)工程需求分析與規(guī)約設(shè)計與規(guī)約編碼與單元測試集成測試系統(tǒng)測試運(yùn)行與維護(hù) 1970年W.Royce提出瀑布模型 特征接受上一階段的結(jié)果作為本階段的輸入利用這一輸入實施本階段應(yīng)完成的活動對本階段的工作進(jìn)行評審將本階段的結(jié)果作為輸出，傳遞給下一階段 缺點(diǎn)缺乏靈活性，難以適應(yīng)需求不明確或需求經(jīng)常變化的軟件開發(fā)開發(fā)早期存在的問題往往要到交付使用時才發(fā)現(xiàn)，維護(hù)代價大許多軟件項目在開發(fā)早期對軟件需求的認(rèn)識是模糊的、不確定的，因此軟件很難一次開發(fā)成功?？梢栽讷@取了一組基本的需求后，通過快速分析構(gòu)造出該軟件的一個初始可運(yùn)行版本，稱之謂原型（prototype），然后根據(jù)用戶在試用原型的過程中提出的意

39、見和建議、或者增加新的需求，對原型進(jìn)行改造，獲得原型的新版本，重復(fù)這一過程，最終得到令客戶滿意的軟件產(chǎn)品。演化模型的開發(fā)過程就是從構(gòu)造初始的原型出發(fā)，逐步將其演化成最終軟件產(chǎn)品的過程。演化模型適用于對軟件需求缺乏準(zhǔn)確認(rèn)識的情況。典型的演化模型有：增量模型、原型模型、螺旋模型。演化模型增量模型項目日歷時間軟件功能性和特征12345第2次增量發(fā)布增量212345第n次增量發(fā)布增量n12345第1次增量發(fā)布增量15部署（發(fā)布，反饋）4構(gòu)造（編碼，測試）3建模（分析，設(shè)計）2計劃1交流增量模型將軟件的開發(fā)過程分成若干個日程時間交錯的線性序列，每個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量”版本，后一個版本是

40、對前一版本的修改和補(bǔ)充，重復(fù)增量發(fā)布的過程，直至產(chǎn)生最終的完善產(chǎn)品。增量模型融合了瀑布模型的基本成分（重復(fù)地應(yīng)用）和演化模型的迭代特征增量模型強(qiáng)調(diào)每一個增量都發(fā)布一個可運(yùn)行的產(chǎn)品增量模型特別適用于：需求經(jīng)常變化的軟件開發(fā)市場急需而開發(fā)人員和資金不能在設(shè)定的市場期限之前實現(xiàn)一個完善的產(chǎn)品的軟件開發(fā)增量模型能有計劃地管理技術(shù)風(fēng)險，如早期增量版本中避免采用尚未成熟的技術(shù)原型（prototype）是預(yù)期系統(tǒng)的一個可執(zhí)行版本，它反映了系統(tǒng)性質(zhì)（如功能、計算結(jié)果等）的一個選定的子集。一個原型不必滿足目標(biāo)軟件的所有約束，其目的是能快速、低成本地構(gòu)建原型。原型方法從軟件工程師與客戶的交流開始，其目的是定義軟件

41、的總體目標(biāo)，標(biāo)識需求。然后快速制訂原型開發(fā)的計劃，確定原型的目標(biāo)和范圍，采用快速設(shè)計的方式對其建模，并構(gòu)建原型。被開發(fā)的原型應(yīng)交付給客戶試用，并收集客戶的反饋意見，這些反饋意見可在下一輪迭代中對原型進(jìn)行改進(jìn)。在前一個原型需要改進(jìn)，或者需要擴(kuò)展其范圍的時候，進(jìn)入下一輪原型的迭代開發(fā)。原型模型部署交付和反饋構(gòu)建原型交流快速設(shè)計方式建?？焖儆媱澰湍Ｐ驮偷念愋停禾剿餍停╡xploratory prototyping） 其目的是要弄清目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性實驗型（experimental prototyping） 其目的是驗證方案或算法的合理性，它是在大規(guī)模開發(fā)和實

42、現(xiàn)前，用于考核方案是否合適，規(guī)格說明是否可靠。演化型（evolutionary prototyping） 其目的是將原型作為目標(biāo)系統(tǒng)的一部分，通過對原型的多次改進(jìn)，逐步將原型演化成最終的目標(biāo)系統(tǒng)。 原型的使用策略：廢棄（throw away）策略 主要用于探索型和實驗型原型的開發(fā)。這些原型關(guān)注于目標(biāo)系統(tǒng)的某些特性，而不是全部特性，開發(fā)這些原型時通常不考慮與探索或?qū)嶒災(zāi)康臒o關(guān)的功能、質(zhì)量、結(jié)構(gòu)等因素，這種原型通常被廢丟，然后根據(jù)探索或?qū)嶒灥慕Y(jié)果用良好的結(jié)構(gòu)和設(shè)計思想重新設(shè)計目標(biāo)系統(tǒng)。追加（add on）策略 主要用于演化型原型的開發(fā)。這種原型通常是實現(xiàn)了目標(biāo)系統(tǒng)中已明確定義的特性的一個子集，通過

43、對它的不斷修改和擴(kuò)充，逐步追加新的要求，最后使其演化成最終的目標(biāo)系統(tǒng)。原型可作為單獨(dú)的過程模型使用，它也常被作為一種方法或?qū)崿F(xiàn)技術(shù)應(yīng)用于其它的過程模型中。B.Boehm于1988年提出是瀑布模型和演化模型的結(jié)合，并增加了風(fēng)險分析螺旋模型沿著螺線旋轉(zhuǎn)，在四個象限上分別表達(dá)四個方面的活動，即：制定計劃：確定軟件目標(biāo)，選定實施方案，弄清項目開發(fā)的限制條件風(fēng)險分析：評價所選的方案，識別風(fēng)險，消除風(fēng)險工程實施：實施軟件開發(fā)，驗證工作產(chǎn)品客戶評估：評價開發(fā)工作，提出修正建議螺旋模型 螺旋模型出現(xiàn)了一些變種，它可以有3到6個任務(wù)區(qū)域。螺旋模型指引的軟件項目開發(fā)沿著螺線自內(nèi)向外旋轉(zhuǎn)，每旋轉(zhuǎn)一圈，表示開發(fā)出一個

44、更為完善的新軟件版本。如果發(fā)現(xiàn)風(fēng)險太大，開發(fā)者和客戶無法承受，則項目就可能因此而終止。多數(shù)情況下沿著螺線的活動會繼續(xù)下去，自內(nèi)向外，逐步延伸，最終得到所期望的系統(tǒng)。噴泉模型噴泉模型是一種支持面向?qū)ο箝_發(fā)的模型體現(xiàn)迭代和無間隙特征迭代：各開發(fā)活動常常重復(fù)工作多次，相關(guān)的功能在每次迭代中隨之加入演進(jìn)的系統(tǒng)無間隙：開發(fā)活動之間不存在明顯的邊界支持軟件復(fù)用（reuse）利用預(yù)先包裝好的軟件構(gòu)件（包括組織內(nèi)部開發(fā)的構(gòu)件和現(xiàn)存商品化構(gòu)件COTS）來構(gòu)造應(yīng)用系統(tǒng)基于構(gòu)件的開發(fā)模型領(lǐng)域分析構(gòu)件可變性分析構(gòu)建可復(fù)用構(gòu)件領(lǐng)域模型領(lǐng)域基準(zhǔn)體系結(jié)構(gòu)圖可復(fù)用構(gòu)件庫分析體系結(jié)構(gòu)設(shè)計獲取構(gòu)件構(gòu)件特化和修改評價構(gòu)件組裝和測試

45、開發(fā)未找到構(gòu)件的部分應(yīng)用系統(tǒng)工程應(yīng)用系統(tǒng)領(lǐng)域工程領(lǐng)域工程的目的是構(gòu)建領(lǐng)域模型、領(lǐng)域基準(zhǔn)體系結(jié)構(gòu)和可復(fù)用構(gòu)件庫。領(lǐng)域分析分析該領(lǐng)域中各種應(yīng)用系統(tǒng)的公共部分或相似部分，構(gòu)建領(lǐng)域模型和領(lǐng)域基準(zhǔn)體系結(jié)構(gòu)（reference architecture），標(biāo)識領(lǐng)域的候選構(gòu)件。對候選構(gòu)件進(jìn)行可變性分析，以適應(yīng)多個應(yīng)用系統(tǒng)的需要。構(gòu)建可復(fù)用構(gòu)件，經(jīng)嚴(yán)格測試和包裝后存入可復(fù)用構(gòu)件庫（稱為構(gòu)件工程）。應(yīng)用系統(tǒng)工程的目的是使用可復(fù)用構(gòu)件組裝應(yīng)用系統(tǒng)。分析待開發(fā)的應(yīng)用系統(tǒng)，設(shè)計應(yīng)用系統(tǒng)的體系結(jié)構(gòu)，標(biāo)識應(yīng)用系統(tǒng)所需的構(gòu)件。在可復(fù)用構(gòu)件庫中查找合適的構(gòu)件（也可購買第三方的構(gòu)件）。特化選中的構(gòu)件，必要時作適當(dāng)?shù)男薷模赃m應(yīng)

46、該應(yīng)用系統(tǒng)的需要。開發(fā)那些未找到合適構(gòu)件的應(yīng)用部分。組裝應(yīng)用系統(tǒng)。評價構(gòu)件的復(fù)用情況，以改進(jìn)可復(fù)用構(gòu)件，同時對新開發(fā)的部分進(jìn)行評價，并向構(gòu)件工程推薦候選構(gòu)件。根據(jù)AT&T、Ericsson、HP公司的經(jīng)驗，有的軟件復(fù)用率高達(dá)90%以上，產(chǎn)品上市時間可縮短25倍，錯誤率減少510倍，開發(fā)成本減少15%75%。僅管這些結(jié)論出自一些較好使用基于構(gòu)件開發(fā)的實例，但毫無疑問，基于構(gòu)件的開發(fā)模型對提高軟件生產(chǎn)率、提高軟件質(zhì)量、降低成本、提早上市時間起到很大的作用。形式方法模型形式化方法（formal methods）是建立在嚴(yán)格數(shù)學(xué)基礎(chǔ)上的一種軟件開發(fā)方法。軟件開發(fā)的全過程中，從需求分析、規(guī)約、設(shè)計、編程

47、、系統(tǒng)集成、測試、文檔生成、直至維護(hù)各個階段，凡是采用嚴(yán)格的數(shù)學(xué)語言，具有精確的數(shù)學(xué)語義的方法，都稱為形式化方法。形式化方法用嚴(yán)格的數(shù)學(xué)語言和語義描述功能規(guī)約和設(shè)計規(guī)約，通過數(shù)學(xué)的分析和推導(dǎo)，易于發(fā)現(xiàn)需求的岐義性、不完整性和不一致性，易于對分析模型、設(shè)計模型和程序進(jìn)行驗證。通過數(shù)學(xué)的演算，使得從形式化功能規(guī)約到形式化設(shè)計規(guī)約，以及從形式化設(shè)計規(guī)約到程序代碼的轉(zhuǎn)換成為可能。凈室過程模型系統(tǒng)工程需求收集代碼審查盒結(jié)構(gòu)規(guī)約形式化設(shè)計正確性驗證代碼生成統(tǒng)計使用測試認(rèn)證測 試 計 劃增量1需求收集代碼審查盒結(jié)構(gòu)規(guī)約形式化設(shè)計正確性驗證代碼生成統(tǒng)計使用測試認(rèn)證測 試 計 劃需求收集代碼審查盒結(jié)構(gòu)規(guī)約形式化

48、設(shè)計正確性驗證代碼生成統(tǒng)計使用測試認(rèn)證測 試 計 劃增量2增量3內(nèi)容摘要計算機(jī)軟件軟件工程軟件過程軟件過程模型敏捷軟件開發(fā)CASE工具與環(huán)境敏捷軟件開發(fā)軟件開發(fā)的新挑戰(zhàn)快速的市場進(jìn)入時間，要求高生產(chǎn)率快速變化的需求快速發(fā)展的技術(shù)傳統(tǒng)的軟件開發(fā)方法強(qiáng)調(diào)過程強(qiáng)調(diào)文檔開發(fā)人員負(fù)擔(dān)過重稱為重載(Heavyweight)方法針對上述問題，產(chǎn)生了一系列輕載(Lightweight)方法，如XP、SCRUM等。2001年2月，新方法的一些創(chuàng)始人在美國猶他州成立了敏捷軟件開發(fā)聯(lián)盟 ，簡稱Agile 聯(lián)盟。Agile 聯(lián)盟起草了一個敏捷軟件開發(fā)宣言，該宣言由四個價值觀聲明組成，并提煉出敏捷軟件開發(fā)方法必須遵循的

49、12條原則。Agile方法是在保證軟件開發(fā)有成功產(chǎn)出的前提下，盡量減少開發(fā)過程中的活動和制品的方法?；\統(tǒng)的講就是，“剛剛好”（Just enough），即開發(fā)中的活動及制品既不要太多也不要太少。Agile方法的價值觀個人和交互高于過程和工具 不是否定過程和工具的重要性，而是更強(qiáng)調(diào)軟件開發(fā)中人的作用和交流的作用。 軟件是由人組成的團(tuán)隊來開發(fā)的，與軟件項目相關(guān)的各類人員通過充分的交流和有效的合作，才能成功地開發(fā)出得到用戶滿意的軟件。 如果光有定義良好的過程和先進(jìn)的工具，而人員的技能很差，又不能很好地交流和協(xié)作，軟件是很難成功地開發(fā)的?？蛇\(yùn)行軟件高于詳盡的文檔 通過執(zhí)行一個可運(yùn)行的軟件來了解軟件做了

50、什么，遠(yuǎn)比閱讀厚厚的文檔要容易得多。 敏捷軟件開發(fā)強(qiáng)調(diào)不斷地快速地向用戶提交可運(yùn)行的軟件（不一定是完整的軟件），以得到用戶的認(rèn)可。 好的必要的文檔仍是需要的，它能幫助我們理解軟件做什么，怎么做以及如何使用，但軟件開發(fā)的主要目標(biāo)是創(chuàng)建可運(yùn)行的軟件。與客戶協(xié)作高于合同（契約）談判 只有客戶才能明確說明需要什么樣的軟件，然而，大量的實踐表明，在開發(fā)的早期客戶常常不能完整地表達(dá)他們的全部需求，有些早期確定的需求，以后也可能會改變。 要想通過合同談判的方式，將需求固定下來常常是困難的。 敏捷軟件開發(fā)強(qiáng)調(diào)與客戶的協(xié)作，通過與客戶的交流和緊密合作來發(fā)現(xiàn)用戶的需求。對變更及時做出反應(yīng)高于遵循計劃 任何軟件項目

51、的開發(fā)都應(yīng)該制訂一個項目計劃，以確定各開發(fā)任務(wù)的優(yōu)先順序和起止日期。然而，隨著項目的進(jìn)展，需求、業(yè)務(wù)環(huán)境、技術(shù)等都可能變化，任務(wù)的優(yōu)先順序和起止日期也可能因種種原因會改變。 因此，項目計劃應(yīng)具有可塑性，有變動的余地。當(dāng)出現(xiàn)變化時及時做出反應(yīng)，修訂計劃以適應(yīng)變化。Agile方法的指導(dǎo)原則（1）最優(yōu)先的是通過盡早地和不斷地提交有價值的軟件使客戶滿意（2）歡迎變化的需求，即使該變化出現(xiàn)在開發(fā)的后期，為了提升對客戶的競爭優(yōu)勢，Agile過程利用變化作為動力（3）以幾周到幾個月為周期，盡快、不斷地發(fā)布可運(yùn)行軟件（4）在整個項目過程中，業(yè)務(wù)人員和開發(fā)人員必須天天一起工作（5）以積極向上的員工為中心建立項目

52、組，給予他們所需的環(huán)境和支持，對他們的工作予以充分的信任（6）項目組內(nèi)效率最高、最有效的信息傳遞方式是面對面的交流（7）測量項目進(jìn)展的首要依據(jù)是可運(yùn)行的軟件（8）敏捷過程提倡可持續(xù)的開發(fā)，項目發(fā)起者、開發(fā)者和用戶應(yīng)能長期保持恒定的速度（9） 應(yīng)時刻關(guān)注技術(shù)上的精益求精和好的設(shè)計，以增強(qiáng)敏捷性（10）簡單化是必不可少的，這是盡可能減少不必要工作的藝術(shù)（11）最好的構(gòu)架、需求和設(shè)計出自于自我組織的團(tuán)隊（12）團(tuán)隊要定期反思怎樣才能更有效，并據(jù)此調(diào)整自己的行為Agile方法的適用范圍Martin Fowler認(rèn)為：新方法不是到處可適用的適合采用Agile方法的情況：需求不確定、易揮發(fā)（Volatil

53、e,意指今天的要求明天就不需要了）有責(zé)任感和積極向上的開發(fā)人員用戶容易溝通并能參與Agile的典型方法Extreme Programming (簡稱XP) SCRUMCrystal Methodologies (簡稱Crystal)Feature Driven Development(簡稱FDD)Dynamic Systems Development Methodology(簡稱DSDM) Adaptive Software Development(簡稱ASD)Pragmatic Programming等XP方法由Kent Beck提出，是Agile方法中最引人注目的一個XP最初實踐于1997

54、年Crysler公司的C3項目 (Smalltalk開發(fā)）適用于10人以下項目組、開發(fā)地點(diǎn)集中的場合 廣泛用于需求模糊和揮發(fā)性強(qiáng)的場合IONA公司的Obix技術(shù)支持小組在采用了XP方法后，軟件生產(chǎn)率提高了67%XP方法的4個價值觀交流（Communication）實踐表明，項目失敗的重要原因之一是交流不暢，使得客戶的需求不能準(zhǔn)確地傳遞給開發(fā)人員，造成開發(fā)人員不能充分理解需求；模型或設(shè)計的變動未能及時告知相關(guān)人員，造成系統(tǒng)的不一致和集成的困難所有項目相關(guān)人員之間充分的有效的交流是軟件開發(fā)成功所必不可少的XP方法提倡面對面的交流，這是一種有效的也是效率最高的交流方式簡單（Simplicity）指在

55、確保得到客戶滿意的軟件的前提下，做最簡潔的工作（簡單的過程、模型、文檔、設(shè)計和實現(xiàn)）在開發(fā)中不斷優(yōu)化設(shè)計，時刻保持代碼簡潔、無冗余體現(xiàn)了敏捷開發(fā)的“剛剛好(Just enough)”思想，即開發(fā)中的活動及制品既不要太多也不要太少，剛好即可反饋（Feedback） 及時有效的反饋能確定開發(fā)工作是否正確，及時發(fā)現(xiàn)開發(fā)工作的偏差并加以糾正。 強(qiáng)調(diào)各種形式的反饋，如非正式的評審（走查，Walkthrough）、小發(fā)布等勇氣（Courage） 采用敏捷軟件開發(fā)需要勇氣：信任合作的同事，也相信自己做能做到的最簡單的事只有在絕對需要的時候才創(chuàng)建文檔讓業(yè)務(wù)人員制定業(yè)務(wù)決策，技術(shù)人員制定技術(shù)決策用可能的最簡單的

56、工具，例如白板和紙，只有在復(fù)雜建模工具能提供可能的最好價值時才去使用它們相信程序員能制定設(shè)計決策，不需要給他們提供過多的細(xì)節(jié)需要勇氣來承認(rèn)自己是會犯錯誤的，需要勇氣來相信自己明天能克服明天出現(xiàn)的問題。XP方法的12個核心實踐1.完整的團(tuán)隊（Whole Team）所有的小組成員應(yīng)在同一個工作地點(diǎn)工作成員中必須有一個現(xiàn)場用戶（On-site User）由他提出需求，確定開發(fā)優(yōu)先級通常還設(shè)一個“教練”（Coach）角色 教練指導(dǎo)XP方法的實施，以及與外部的溝通和協(xié)調(diào)2.計劃對策（Planning Game） 包括兩類：發(fā)布計劃和迭代（Iteration）計劃3. 系統(tǒng)比喻 （Metaphor） 系統(tǒng)

57、比喻是待開發(fā)軟件的一個每個成員都熟悉的形象化比喻，相當(dāng)于一個粗略的軟件體系結(jié)構(gòu)4. 小發(fā)布（Small release） 經(jīng)常、不斷地發(fā)布可運(yùn)行的、具有商業(yè)價值的小軟件版本，供現(xiàn)場用戶評估或最終使用 5. 測試（testing） XP方法提倡測試優(yōu)先，即先寫測試后編代碼（testing then coding）6. 簡單設(shè)計（Simple Design）設(shè)計只考慮當(dāng)前定義的功能而不考慮以后需求的變化該設(shè)計是完成目前功能所需的最簡潔的設(shè)計7. 結(jié)對編程（Pair Programming） 一個程序員編程的同時，另一個程序員負(fù)責(zé)檢查程序的正確性和可讀性 結(jié)對的伙伴可以動態(tài)調(diào)整8. 設(shè)計改進(jìn)（Design Improvement） 在不影響程序的外部可見行為的情況下，按高內(nèi)聚低耦合的原則對程序結(jié)構(gòu)進(jìn)行改進(jìn)，保持代碼簡潔、無冗余持續(xù)集成（Continuous Integration） 每完成一個模塊的開發(fā)（包括該模塊的單元測試）后，立即將其組裝到系統(tǒng)中，并進(jìn)行集成測試，完成該集成測試后才能進(jìn)行下一次集成10.代碼全體共有（Collective code Ownership） 團(tuán)隊中的任何人可以在任何時候修改系統(tǒng)任何位置上的任何代碼 團(tuán)隊的成員都可以參加模型的開發(fā)