軟件工程課件：第01章 軟件工程概述

1、第1章軟件工程概述1內(nèi)容1.0 軟件概念1.1 軟件危機1.2 軟件工程1.3 軟件生命周期1.4 軟件過程1.0 軟件概念軟件軟件的特點軟件發(fā)展歷程軟件概念-軟件 軟件（ Software）是計算機系統(tǒng)中與硬件相互依存的另一部分，它是包括程序（Program） ，數(shù)據(jù)（Data）及其相關(guān)文檔（ Document）的完整集合。 Software = Program + Data + Document程序是按事先設(shè)計的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu)文檔是與程序開發(fā)，維護和使用有關(guān)的圖文材料軟件概念-軟件的特點抽象性軟件是邏輯實體，沒有明顯的制造過程，運行和使用沒

2、有磨損與老化問題。依存性軟件開發(fā)和運行依賴于計算機系統(tǒng)。工藝性軟件開發(fā)至今尚未完全擺脫手工工藝的開發(fā)方式。復雜性軟件邏輯結(jié)構(gòu)、開發(fā)技術(shù)、項目管理復雜。成本高開發(fā)成本、維護成本高。風險大軟件項目的成功率低。維護難維護不能依靠原開發(fā)者，理解軟件代碼難，維護也是開發(fā)，維護成本高軟件工作涉及各種社會因素政策規(guī)章、管理思想、文化背景、信息素養(yǎng)、技術(shù)水平、系統(tǒng)接口等。軟件的復雜性邏輯復雜軟件的邏輯結(jié)構(gòu)非常復雜開發(fā)復雜成本難以估算、進度難以控制、人員素質(zhì)要求、質(zhì)量得不到保證成本高例：軟件成本風險大1995年美國Standish咨詢集團的統(tǒng)計分析(至90年代初的軟件項目執(zhí)行情況)成功：16.2%失敗：31受到

3、挑戰(zhàn)：53.8%近幾年來的統(tǒng)計數(shù)據(jù)成功：26失?。?8受到挑戰(zhàn)：46%維護難維護形式多樣化改正性：修改故障完善性：增加功能適應(yīng)性：移植維護成本越來越高55%到70維護帶來的問題可能引發(fā)新的錯誤，經(jīng)維護后邏輯結(jié)構(gòu)更復雜1.1 軟件危機軟件危機軟件發(fā)展歷程，軟件危機，軟件危機的表現(xiàn)。產(chǎn)生軟件危機的原因軟件特點有關(guān)，開發(fā)中的問題，維護中的問題。消除軟件危機的途徑正確認識“軟件”，重視軟件過程，采用有效的軟件開發(fā)技術(shù)和方法，引進工程管理方法。軟件發(fā)展歷程早期面向批處理有限的分布自定義軟件第二階段多用戶實時數(shù)據(jù)庫軟件產(chǎn)品第三階段分布式系統(tǒng)嵌入“智能”低成本硬件消費者的影響第四階段強大的桌面系統(tǒng)面向?qū)ο蠹?/p>

4、術(shù)專家系統(tǒng)人工神經(jīng)網(wǎng)絡(luò)并行計算網(wǎng)路計算機195019601970198019902000 1968年10月，北大西洋公約組織（NATO）的科學家在德國召開的學術(shù)會議上正式提出了軟件危機問題。軟件危機軟件危機是計算機軟件開發(fā)和維護過程中所遇到的一系列嚴重問題。主要包括下列兩個方面的問題：如何開發(fā)軟件，以滿足對軟件的日益增長的需求；如何維護不斷增多的已有軟件。軟件危機的典型表現(xiàn)對軟件開發(fā)成本和進度的估計常常很不準確；用戶對交付的軟件經(jīng)常不滿意；軟件產(chǎn)品的質(zhì)量往往達不到要求；開發(fā)出來的軟件通常難以維護；軟件產(chǎn)品文檔資料不適用和不完善；軟件成本在整個系統(tǒng)總成本中所占比例逐年上升；軟件開發(fā)生產(chǎn)率的提高不

5、能滿足對軟件需求的增長；成本問題計算機軟件和硬件費用比越來越大IBM 360 OS, 5000多人年，耗時4年(19631966)，花費2億多美元美國空軍：1955年軟件占總費用(計算機系統(tǒng))的18%，70年60%，85年達到85美國全球軍事指揮控制系統(tǒng)，硬件1億美元，軟件高達7.2億美元軟件質(zhì)量問題軟件應(yīng)用面的擴大：科學計算、軍事、航空航天、工業(yè)控制、企業(yè)管理、辦公、家庭軟件越來越多的應(yīng)用于安全攸關(guān)的系統(tǒng)，對軟件質(zhì)量提出更高的要求80年代歐洲亞麗安娜火箭的發(fā)射失敗，原因是軟件錯誤美國阿托拉斯火箭的發(fā)射失敗，原因是軟件故障軟件的復雜性越來越高英國1986年開發(fā)的辦公室信息系統(tǒng)Folios經(jīng)4年

6、，因性能達不到要求，1989年取消日本第5代機因為軟件問題在投入50億美元后于1993年下馬由于軟件質(zhì)量問題導致失敗的軟件項目非常多項目進度問題項目進度難以控制項目延期比比皆是由于進度問題而取消的軟件項目較常見只有一小部分的項目能夠按期完成軟件維護問題軟件維護非常困難軟件維護的多樣性軟件維護的復雜性軟件維護的副作用產(chǎn)生軟件危機的原因與軟件本身的特點有關(guān)成本高、風險大、難于維護、邏輯復雜。軟件是計算機系統(tǒng)中的邏輯實體而不是物理實體，軟件生產(chǎn)與硬件不同，在它的開發(fā)過程中沒有明顯的制造過程。軟件是通過人們的智力活動，把知識與技術(shù)轉(zhuǎn)化成信息的一種產(chǎn)品。在軟件的運行過程中，沒有“用壞”的問題。軟件維護意

7、味著修正原來的設(shè)計，較為困難。與軟件開發(fā)與維護的方法不正確有關(guān)軟件專業(yè)人員對軟件開發(fā)和維護存在糊涂觀念，在實踐過程中采用了錯誤的方法和技術(shù)。如忽視軟件需求分析的重要性；輕視軟件維護。消除軟件危機的途徑正確認識“軟件”軟件程序，軟件是相關(guān)程序、數(shù)據(jù)及文檔的集合。正確認識“軟件開發(fā)”軟件開發(fā)不是個體勞動，而主要是一種有組織的團隊活動。研究軟件開發(fā)的技術(shù)手段在軟件開發(fā)中使用已證明行之有效的技術(shù)，研究和探索新的技術(shù)。更好地使用軟件工具，建立一個良好的軟件工程支撐環(huán)境。研究軟件開發(fā)的管理方法在軟件開發(fā)中使用已證明行之有效的工程管理方法。組織良好、管理嚴密，使各類人員協(xié)同配合，共同完成軟件開發(fā)的工程項目。

8、軟件工程學的是由于“軟件危機”的出現(xiàn)和加重而產(chǎn)生的，研究用工程的方法來管理軟件的開發(fā)。開發(fā)一個具有一定規(guī)模和復雜性的軟件系統(tǒng)與編寫一個簡單的程序不一樣。大型、復雜軟件系統(tǒng)的開發(fā)是一項工程，必須按照工程化的方法組織軟件的生產(chǎn)和管理，必須經(jīng)過分析、設(shè)計、實現(xiàn)、測試、維護等一系列軟件過程和活動軟件工程學的產(chǎn)生提出有效的方法和工具支持軟件開發(fā)1968年提出軟件工程概念和思想20世紀70年代的結(jié)構(gòu)化軟件開發(fā)方法20世紀80年代的面向?qū)ο蟮能浖_發(fā)方法新的技術(shù): 軟件重用、快速原型、需求工程典型技術(shù): COM, Java, C+, J2EE, .Net, .支撐工具和環(huán)境：Jbuilder, Visual

9、 Studio, WebLogic, 解決危機的技術(shù)途徑20世紀80年代末，美國DoD和業(yè)界開始認識到管理的重要性美國DoD的一項研究表明，70%的項目由于管理不善導致難以控制進步、成本和質(zhì)量；進一步的研究發(fā)現(xiàn)：管理是影響軟件項目成功開發(fā)的全局性因素，而技術(shù)只影響局部如果軟件開發(fā)組織不能對軟件項目進行有效管理，就不能充分發(fā)揮軟件開發(fā)方法和工具的潛力，也就不能高效率地開發(fā)出高質(zhì)量的軟件產(chǎn)品解決危機的管理途徑1.2 軟件工程軟件工程的概念軟件工程的基本原理軟件工程方法學軟件工程概念軟件工程是指導計算機軟件開發(fā)與維護的一門工程學科。采用工程的概念、原理、方法和技術(shù)來開發(fā)和維護軟件。將經(jīng)過時間和實踐考

10、驗而證明正確的管理方法和最好的技術(shù)手段結(jié)合起來，經(jīng)濟有效地開發(fā)和維護軟件。軟件工程是一門不斷發(fā)展的學科。軟件工程定義(Fritz Bauer,1968) The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines. (1968- Fritz Bauer) 軟件工程就是建立和使用一套合理的工程原理，從而經(jīng)濟地獲得可靠的、可以在實際機器上高效運行的軟件。軟

11、件工程定義(IEEE,1990) Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE(The Institute for Electrical an

12、d Electronic engineers) Std 610-1990.） 軟件工程是：（1）把系統(tǒng)的、規(guī)范的、 可度量的途徑應(yīng)用于軟件開發(fā)、運行和維護過程，也就是把工程應(yīng)用于軟件；（2）研究（1）中提到的途徑。軟件工程定義(CMU/SEI,1990) Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. Softwar

13、e engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.SEI software engineering definition from 1990 SEI Report on Undergraduate Software Engineering Education (CMU/SEI-90-TR-003):軟件工程定義 軟件工

14、程是應(yīng)用計算機科學、數(shù)學及管理科學等原理開發(fā)軟件的工程。它采用經(jīng)過實踐驗證的工程的原則、方法，以提高質(zhì)量，降低成本為目的。軟件工程的本質(zhì)特性關(guān)注于大型程序的構(gòu)造控制軟件復雜性適應(yīng)軟件的經(jīng)常變化性提高軟件開發(fā)的效率和諧合作開發(fā)軟件使軟件有效地支持它的用戶需求軟件是有一種文化背景的人為另一種文化背景的人開發(fā)的產(chǎn)品。軟件工程的基本原理用分階段的生命周期計劃嚴格管理堅持進行階段評審實行嚴格的產(chǎn)品控制采用現(xiàn)代程序設(shè)計技術(shù)結(jié)果應(yīng)能清楚地審查開發(fā)小組的人員應(yīng)該少而精承認不斷改進軟件工程實踐的必要性軟件工程包括技術(shù)和管理兩方面的內(nèi)容，是技術(shù)與管理緊密結(jié)合所形成的工程學科。通常把在軟件生命周期全過程中使用的一整

15、套技術(shù)方法的集合稱為軟件工程方法學(methodology)，也稱為范型(paradigm)。軟件工程方法學軟件工程方法學三要素軟件工程方法學包含3個要素：方法、工具和過程。方法完成軟件開發(fā)各項任務(wù)的技術(shù)方法。工具為運用方法而提供的軟件工程支撐環(huán)境（支撐分析、設(shè)計、開發(fā)等）。過程規(guī)定了完成軟件開發(fā)各項任務(wù)的工作步驟。傳統(tǒng)軟件工程方法學傳統(tǒng)軟件工程方法學是生命周期方法學軟件生命周期一個軟件定義、開發(fā)、使用和維護，直到最終被廢棄，要經(jīng)歷的漫長的時期，稱為軟件的生命周期。生命周期方法學這種方法學把軟件生命周期的全過程依次劃分為若干個階段，然后順序地完成每個階段的任務(wù)。2 面向?qū)ο蠓椒▽W面向?qū)ο笾饕?/p>

16、念對象、類、繼承、消息等。面向?qū)ο蠓椒▽W這種方法學把數(shù)據(jù)和行為看成同等重要，它是一種以數(shù)據(jù)為主線，把數(shù)據(jù)和對數(shù)據(jù)的操作緊密結(jié)合起來的方法1.3 軟件生命周期軟件生命周期概念軟件生命周期模型軟件生命周期各階段任務(wù)常見的軟件工程方法學（幾大公司）軟件生命周期概念軟件生命周期基本階段軟件生命周期由軟件定義、軟件開發(fā)和軟件維護三個時期組成，每個時期又可劃分若干個階段。生命周期方法學軟件工程采用的生命周期方法學就是從時間角度對軟件開發(fā)和維護的復雜性進行分解，把軟件生存的漫長周期依次劃分為若干個階段，每個階段都有獨立的任務(wù)，然后逐步完成每個階段的任務(wù)。 劃分軟件生存周期階段的基本原則使各階段的任務(wù)之間盡可

17、能相互獨立，同一個階段各項任務(wù)的性質(zhì)盡可能相同，從而降低每個階段任務(wù)的復雜程序，簡化不同階段之間的聯(lián)系，有利于軟件開發(fā)工程的組織管理。1.4 軟件生命周期模型 問題定義 軟件定義 可行性研究 需求分析 總體設(shè)計軟件生命周期 軟件開發(fā) 詳細設(shè)計 編碼和單元測試（實現(xiàn)） 綜合測試 運行維護 軟件維護軟件生命周期基本階段的任務(wù)（1）軟件定義時期總目標的確定，可行性，采用策略，系統(tǒng)功能，所需資源與成本，工程進度表，也稱為系統(tǒng)分析時期，分為所定義，可行性研究和需求分析。（2）開發(fā)時期具體設(shè)計和實現(xiàn)前面所定義的軟件。分為：總體設(shè)計，詳細設(shè)計，編碼和單元測試，綜合測試。（3）維護時期使軟件盡量地滿足用戶需要

18、，糾錯，適應(yīng)新環(huán)境，滿足新需求 軟件生命周期的階段1. 問題定義要解決的問題是什么？2. 可行性研究問題能夠解決嗎？3. 需求分析為了解決問題需要做什么？4. 總體設(shè)計為了解決問題，大概怎樣做？5. 詳細設(shè)計為了解決問題，具體怎樣做？6. 編碼和單元測試編程實現(xiàn)，并測試每一個程序模塊，驗證程序達到設(shè)計要求。7. 綜合測試集成測試、壓力測試、驗收測試，驗證系統(tǒng)滿足需求。8. 軟件維護改正性維護、適應(yīng)性維護、完善性維護、預(yù)防性維護，保障系統(tǒng)持久性滿足用戶的要求。問題定義可行性研究需求分析總體設(shè)計詳細設(shè)計編碼與單元測試綜合測試軟件維護要解決的問題是什么？問題性質(zhì)、工程目標和規(guī)模的報告分析員：實際用戶

19、+負責人是否有解決辦法？分析員 高層邏輯模型，準確和具體的工程規(guī)模和目標，成本/效益分析等可行性報告為了解決的問題，目標系統(tǒng)必須做什么？準確確定系統(tǒng)的功能系統(tǒng)的邏輯模型（數(shù)據(jù)流圖+數(shù)據(jù)字典+簡要算法）如何解決這些問題模塊劃分軟件結(jié)構(gòu)如何具體地實現(xiàn)系統(tǒng)：每個模塊的流程圖（程序的詳細規(guī)格說明）通過各種類型的測試，使軟件達到預(yù)定的要求寫出正確的容易理解和容易維護的程序模塊 通過各種必要的維護活動使系統(tǒng)持久地滿足用戶的需要軟件生命周期的各階段任務(wù)軟件工程層次模型軟件工程： 一種層次化模型質(zhì)量關(guān)注點過程方法工具 軟件工程層次圖軟件工程三個要素：工具、方法、過程基礎(chǔ)層，綜合方法及工具，定義方法使用的順序，

20、所需要的管理為軟件開發(fā)提供“如何做”的技術(shù)為軟件開發(fā)提供自動或半自動的軟件支撐環(huán)境，建立計算機輔助軟件工程(CASE)的軟件開發(fā)支撐系統(tǒng)軟件工程擴展模型軟件工程方法學例ALM（Application Lifecycle Management，應(yīng)用生命周期管理）MSF（Microsoft Solution Framework，微軟方案框架 )RUP（Rational Unified Process，統(tǒng)一軟件過程 ）OOA/OOD/OOPOOA (Object-Oriented Analysis面向?qū)ο蠓治? 分析師拿到所有來自客戶的需求了；了解需求，分析需求、技術(shù)實現(xiàn)等，分析出來一個方案，即項目

21、需求。分析師們分析結(jié)果出來后，形成了最早的需求模型，包括可行性報告、需求分析報告、系統(tǒng)模型、草圖等。OOD (Object Oriented Design面向?qū)ο笤O(shè)計) 設(shè)計師們拿到需求模型進行細化，模塊化，定義所有的細節(jié)，設(shè)計軟件的詳圖，這里就是詳細的需求分析規(guī)格書和具體的設(shè)計文檔。OOP (Object Oriented Programming面象對象程序設(shè)計) 程序員按照設(shè)計圖的要求完成項目的實際操作部分，在項目里就是coding的工作和testing的工作。1.4 軟件過程軟件過程是為了獲得高質(zhì)量的軟件需要完成的一系列任務(wù)的框架，規(guī)定了完成各項任務(wù)的工作步驟。A process def

22、ines Who is doing What, When, and How, in order to reach a certain goal.軟件過程定義了軟件工程的階段、應(yīng)用方法的順序、應(yīng)交付的文檔、保證軟件質(zhì)量的措施、標志軟件開發(fā)各階段的里程碑。 軟件過程框架模型 軟件過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項任務(wù)的工作步驟。工作任務(wù)里程碑、交付物SQA(軟件質(zhì)量保障)點 公共過程框架輔助活動框架活動任務(wù)集合軟件過程模型軟件生命周期的每一階段都有明確的任務(wù)，把規(guī)模大、結(jié)構(gòu)復雜、管理復雜的軟件開發(fā)變得容易控制和管理。各個階段的活動如何銜接，開發(fā)過程中采用什么樣的

23、策略，應(yīng)遵守什么樣的規(guī)定和制約，將這些活動框架（忽略不必要的細節(jié)）用一種模型表示出來，稱為軟件過程模型（或軟件開發(fā)模型或軟件生命周期模型）。軟件過程模型是軟件開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架。常用軟件過程模型（1）瀑布模型(Waterfall Model ）（2）快速原型模型(Rapid Prototype Model)（3）增量模型 (Incremental Model)（4）螺旋模型 (Spiral Model)（5）面向?qū)ο竽Ｐ停▏娙Ｐ?、可重用組件模型）（6）統(tǒng)一軟件開發(fā)過程（IBM RUP）（7）敏捷(靈活)過程與極限編程（8）微軟過程（Microsoft Solution Fra

24、mework）（1）瀑布模型(Waterfall Model)傳統(tǒng)瀑布模型評審評審評審評審評審瀑布模型問題定義可行性研究需求分析總體設(shè)計詳細設(shè)計編碼與單元測試綜合測試軟件維護軟件定義時期軟件開發(fā)時期軟件維護時期瀑布模型的特點階段間具有順序性和依賴性提供了軟件過程模型的基本框架,強調(diào)了每一階段活動的嚴格順序。前一階段產(chǎn)品（文檔）驅(qū)動下一階段的工作。推遲實現(xiàn)的觀點程序的物理實現(xiàn)集中在開發(fā)階段的后期，用戶在最后才能看到自己的產(chǎn)品。質(zhì)量保證的觀點每一個階段必須完成規(guī)定的文檔；以評審確認階段工作，即上一階段的結(jié)束，下一階段的開始。傳統(tǒng)瀑布模型存在什么問題？改進的瀑布模型及時反饋：開發(fā)時盡早知道上一階段的

25、錯誤。維護分類：根據(jù)軟件維護的內(nèi)容和程度，確定維護的階段。評審評審評審評審評審反饋反饋反饋反饋軟件維護瀑布模型的優(yōu)缺點瀑布模型適合于用戶需求明確、完整、無重大變化的軟件項目開發(fā)。瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動的模型?！捌俨寄Ｐ褪怯晌臋n驅(qū)動的”，這個事實是它的一個主要缺點。實際項目很少按照該模型給出的順序進行；用戶常常難以清楚地給出所有需求；用戶必須有耐心，等到系統(tǒng)開發(fā)完成。 （2）快速原型模型 (Rapid Prototype Model) 在用戶不能給出完整、準確的需求說明，或者開發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性或人機交互的形式等許多情況下，可以根據(jù)用戶的一

26、組基本需求，快速建造一個原型（可運行的軟件），然后進行評估，進一步精化、調(diào)整原型，使其滿足用戶的要求，也使開發(fā)者對將要做的事情有更好的理解。建造/修改原型 聽取用 戶意見用戶測試運行原型原型實現(xiàn)范型快速原型模型快速原型法是一種新型的軟件開發(fā)方法，它使用交互的，快速建立起來的原型取代了形式的、僵硬的大量的規(guī)格說明，用戶通過在計算機上實際運行和試用原型系統(tǒng)而向開發(fā)者提供真實的反饋意見。建立原型系統(tǒng)修改原型符合用戶需要的應(yīng)用系統(tǒng)用戶試用反饋意見快速原型模型快速原型驗證規(guī)格說明驗證設(shè)計驗證編碼測試綜合測試維護變化的需求驗證維護過程開發(fā)過程采用不帶反饋的瀑布模型，進行快速開發(fā)和修改。原型系統(tǒng)提交用戶評測

27、，反復修改，直到用戶滿意。原型模型存在的問題 為了使原型盡快的工作，沒有考慮軟件的總體質(zhì)量和長期的可維護性。 為了演示，可能采用不合適的操作系統(tǒng)、編程語言、效率低的算法，這些不理想的選擇成了系統(tǒng)的組成部分。 開發(fā)過程不便于管理。有效的使用原型模式 建造原型僅是為了定義需求，之后就被拋棄（或被部分拋棄），實際的軟件在充分考慮了質(zhì)量和可維護性之后才被開發(fā)。3）增量模型 (Incremental Model)是一種漸進地開發(fā)逐步完善的軟件版本的模型。需求分析驗證規(guī)格說明驗證設(shè)計驗證維護針對每個構(gòu)件完成詳細設(shè)計、編碼和集成，經(jīng)測試后交付給用戶需求分析一步到位；功能模塊作為增量逐步交付。增量模型分析分析

28、分析分析設(shè)計設(shè)計設(shè)計設(shè)計編碼編碼編碼編碼測試測試測試測試增量1增量2 增量3增量4 交付交付交付交付反復地應(yīng)用瀑布模型的基本成分和原型模型的迭代特征，每一個線型過程產(chǎn)生一個“增量”的發(fā)布或提交，該增量均是一個可運行的產(chǎn)品。早期的版本實現(xiàn)用戶的基本需求，并提供給用戶評估的平臺。需求作為增量逐步交付。增量模型的優(yōu)點在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，并分批、逐步地向用戶提交產(chǎn)品。從第一個構(gòu)件交付之日起，用戶就能做一些有用的工作。整個軟件產(chǎn)品被分解成許多個增量構(gòu)件，開發(fā)人員可以一個構(gòu)件一個構(gòu)件地逐步開發(fā)。逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學習和適應(yīng)新產(chǎn)品，從而減少一個全新的軟件可能給客

29、戶組織帶來的沖擊。采用增量模型比采用瀑布模型和快速原型模型需要更精心的設(shè)計，但在設(shè)計階段多付出的勞動將在維護階段獲得回報。增量模型的困難在把每個新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟件的體系結(jié)構(gòu)設(shè)計得便于按這種方式進行擴充，向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便，也就是說，軟件體系結(jié)構(gòu)必須是開放的。開發(fā)人員既要把軟件系統(tǒng)看作整體。又要看成可獨立的構(gòu)件，產(chǎn)生觀念上的矛盾。多個構(gòu)件并行開發(fā)，具有集成的風險。4）螺旋模型 (Spiral Model) 軟件風險是任何軟件開發(fā)項目中都普遍存在的實際問題，項目越大，軟件越復雜，承擔該項目所冒的風險也越大

30、。 對于復雜的大型軟件，開發(fā)一個原型往往達不到要求。螺旋模型將瀑布模型和增量模型結(jié)合起來，加入了風險分析。在該模型中，軟件開發(fā)是一系列的增量發(fā)布，早期的迭代中，發(fā)布的增量可能是一個紙上的模型或原型，在以后的迭代中，逐步產(chǎn)生系統(tǒng)更加完善的版本。 螺旋模型的基本思想是降低風險。簡單的螺旋模型快速原型驗證規(guī)格說明驗證設(shè)計驗證編碼測試綜合測試維護變化的需求驗證風險分析風險分析風險分析風險分析風險分析風險分析可看作在每個階段之前都增加了風險分析過程的快速原型模型。每一個階段都可能存在不同的風險！完整的螺旋模型原型版本當前進度 螺旋模型風險分析工程實施用戶交流用戶評估產(chǎn)品維護項目產(chǎn)品增強項目新產(chǎn)品開發(fā)項目

31、概念開發(fā)項目計劃建造及發(fā)布螺旋模型的優(yōu)點和特點螺旋模型的優(yōu)點對可選方案和約束條件的強調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個重要目標減少了過多測試或測試不足維護和開發(fā)之間并沒有本質(zhì)區(qū)別螺旋模型的特點風險驅(qū)動，需要相當豐富的風險評估經(jīng)驗和專門知識，否則風險更大主要適用于內(nèi)部開發(fā)的大規(guī)模軟件項目，隨著過程的進展演化，開發(fā)者和用戶能夠更好的識別和對待每一個演化級別上的風險隨著迭代次數(shù)的增加，工作量加大，軟件開發(fā)成本增加（5-1）面向?qū)ο?噴泉模型噴泉模型(Fountain Model)是面向?qū)ο竽Ｐ?。主要用于支持面向?qū)ο箝_發(fā)過程，體現(xiàn)了軟件創(chuàng)建所固有的迭代和無間隙的特征分析設(shè)計實

32、現(xiàn)測試集成演化（5-2）面向?qū)ο?構(gòu)件集成模型(Component Integration Model) 構(gòu)件（components)也稱為組件，是一段實現(xiàn)一系列有確定接口的程序體，具有自己的功能和邏輯，能同其他構(gòu)件集成起來協(xié)調(diào)工作。該模型（又稱為可重用部件組裝模型）支持軟件重用（Reusability） ，對縮短軟件開發(fā)周期、降低項目成本有重要的現(xiàn)實意義。同時，建造符合某應(yīng)用領(lǐng)域體系結(jié)構(gòu)標準的構(gòu)件，可以用來搭建分布式的、跨越不同操作平臺(集成化軟件開發(fā)環(huán)境（ISEE）)的軟件，擴展了軟件的應(yīng)用前景，促進了軟件標準化、商品化的發(fā)展。在此基礎(chǔ)上專家們又提出了“基于構(gòu)件的軟件工程”(CBSE)。構(gòu)

33、件集成模型 構(gòu)件集成模型 軟件體系結(jié)構(gòu)被建立后，必須用構(gòu)件去充實，這些構(gòu)件可從復用庫中獲得，或者根據(jù)專門需要而開發(fā)。整個過程可以演化地進行，面向?qū)ο蠓椒ńo予技術(shù)上的支持。構(gòu)件集成模型Sommerville提出基于組件開發(fā)有兩種思路：完成高層設(shè)計，對設(shè)計中的組件給出描述，以便找出可復用的組件，這些組件可在體系結(jié)構(gòu)層次上加入或更詳細的設(shè)計層次上加入。先根據(jù)需求搜尋可復用組件，再將設(shè)計建立在獲得的組件基礎(chǔ)上。這兩種思路可結(jié)合起來。設(shè)計系統(tǒng)體系結(jié)構(gòu)描述組件搜尋可復用組件集成系統(tǒng)先完成架構(gòu)設(shè)計的復用系統(tǒng)需求描述搜尋可復用組件對需求作某些修改體系結(jié)構(gòu)設(shè)計集成系統(tǒng)復用驅(qū)動設(shè)計構(gòu)件技術(shù)主要有三種流行標準對象管

34、理組織OMG的CORBA微軟的COM / DCOMSUN的 EJB ( Enterprise JavaBean )OMG的CORBA對象管理組織OMG發(fā)布的公用對象請求代理體系結(jié)構(gòu)(Common Object Request Broker Architecture)。通過一個對象請求代理（ORB)提供一系列服務(wù)，使得一個構(gòu)件和其他構(gòu)件通信，而不管它們在系統(tǒng)中的位置，實現(xiàn)了遠程對象通過接口進行通信的機制。為了解決CORBA對象引用不透明、缺少多重接口、系統(tǒng)過于復雜等問題，專家們又開發(fā)了新一代面向?qū)ο笾虚g件平臺 ICE （ Internet Communications Engine互聯(lián)網(wǎng)通信引擎

35、）。使構(gòu)建分布式應(yīng)用系統(tǒng)更容易、性能和伸縮性更好。微軟的COM / DCOMCOM微軟提出、開發(fā)的構(gòu)件對象模型（Component Object Model)，它提供了運行于windows之上的單個應(yīng)用系統(tǒng)使用不同廠商生產(chǎn)的構(gòu)件的規(guī)約。DOM基于分布式環(huán)境下的COM稱為DCOM (Distribute COM)。SUN的 EJB ( Enterprise JavaBean )隨著Java在企業(yè)級應(yīng)用的地位日趨重要，Sun提出了一個統(tǒng)一的企業(yè)級Java平臺J2EE（Java 2 Enterprise Edition）。在J2EE中，EJB負責最核心的業(yè)務(wù)處理。它為服務(wù)器端的應(yīng)用程序提供了一種與廠

36、商無關(guān)的Java接口，讓任何符合EJB規(guī)范的構(gòu)件都可以運行在每一臺這樣的服務(wù)器上。（6）統(tǒng)一軟件開發(fā)過程統(tǒng)一軟件開發(fā)過程（Rational Unified Process， RUP)是由Rational公司的Booch、Jacobson、Rumbaugh提出的軟件過程模型。RUP重復一系列周期，每個周期由一個交付給用戶的產(chǎn)品結(jié)束。每個周期劃分為初始、細化、構(gòu)造和移交四個階段，每個階段圍繞著五個核心工作流（需求、分析、設(shè)計、實現(xiàn)、測試）分別迭代。RUP的“最佳實踐”軟件開發(fā)經(jīng)驗迭代式開發(fā)按照原型模型，迭代開發(fā)產(chǎn)品，獲取用戶的反饋意見，加深對需求的理解，逐步趨向最終產(chǎn)品。管理需求人為需求分析是一個

37、連續(xù)過程，使用有效的方法（如用例和腳本）捕獲用戶變化的需求，以驅(qū)動設(shè)計與實現(xiàn)。使用基于構(gòu)建的體系結(jié)構(gòu)提供使用現(xiàn)有構(gòu)建和新開發(fā)構(gòu)件定義體系結(jié)構(gòu)的方法，采用構(gòu)建來建造系統(tǒng)，從而減低軟件復雜性，提供軟件重用率。可視化建模采用可視化建模語言（UML）描述系統(tǒng)模型。驗證軟件質(zhì)量建立貫穿整個開發(fā)過程的、全員參與的軟件質(zhì)量評估方法?？刂栖浖兏刂啤⒏櫤捅O(jiān)控軟件的修改，確保迭代開發(fā)的成功。RUP軟件開發(fā)生命周期RUP初始階段：進行問題定義，確定目標，評估其可行性，降低關(guān)鍵風險。細化階段：制定項目計劃、配置各類資源、建立系統(tǒng)架構(gòu)（包括各類視圖）。構(gòu)造階段：開發(fā)整個產(chǎn)品，并確保產(chǎn)品可移交給用戶。移交階段：產(chǎn)品

38、發(fā)布、安裝、用戶培訓。 在每個階段的每次迭代的最后，用例模型、分析模型、設(shè)計模型、實現(xiàn)模型都會增量，每個階段結(jié)束的里程碑處，管理層做出是否繼續(xù)、進度、預(yù)算、是否給下一階段提供資助等決定。 不同階段工作流的側(cè)重點不同，前兩階段大部分工作集中在需求、分析和架構(gòu)設(shè)計上；在構(gòu)造階段，重點轉(zhuǎn)移到詳細設(shè)計、實現(xiàn)和測試上。（7）敏捷過程與極限編程2001年，為了解決許多公司的軟件團隊陷入不斷增長的過程泥潭，一批業(yè)界著名專家一起概括出了一些可以讓軟件開發(fā)團隊具有快速工作、響應(yīng)變化能力的價值觀和原則，他們稱自己為敏捷聯(lián)盟。敏捷開發(fā)過程的方法很多，主要有：SCRUM，Crystal,特征驅(qū)動軟件開發(fā)（Featur

39、e Driven Development，簡稱FDD），自適應(yīng)軟件開發(fā)(Adaptive Software Development，簡稱ASD)，以及最重要的極限編程(eXtreme Programming,簡稱XP)。極限編程(XP)是于1998年由Smalltalk社群中的大師級人物Kent Beck首先倡導的。觀點在按照我的理解方式審查了軟件開發(fā)的生命周期后，我得出一個結(jié)論：實際上滿足工程設(shè)計標準的惟一軟件文檔，就是源代碼清單。 - Jack Reeves 設(shè)計和編程都是人的活動。忘記這一點，將會失去一切。 - Bjarne Stroustrup 敏捷過程敏捷軟件開發(fā)宣言個體和交互 勝過

40、 過程和工具可以工作的軟件 勝過 面面俱到的文檔客戶合作 勝過 合同談判響應(yīng)變化 勝過 遵循計劃敏捷宣言遵循的原則我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。 在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。 圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。 在團隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。 工作的軟件是首要的進度度量標準。 敏

41、捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。 簡單是最根本的。 最好的構(gòu)架、需求和設(shè)計出于自組織團隊。 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。敏捷過程認為的軟件設(shè)計“壞味道”僵化性很難對系統(tǒng)進行改動，因為每個改動都會迫使許多對系統(tǒng)其他部分的其它改動。 脆弱性對系統(tǒng)的改動會導致系統(tǒng)中和改動的地方在概念上無關(guān)的許多地方出現(xiàn)問題。 牢固性很難解開系統(tǒng)的糾結(jié)，使之成為一些可在其他系統(tǒng)中重用的組件。 粘滯性做正確的事情比做錯誤的事情要困難。 不必要的復雜性設(shè)計中包

42、含有不具任何直接好處的基礎(chǔ)結(jié)構(gòu)。 不必要的重復性設(shè)計中包含有重復的結(jié)構(gòu)，而該重復的結(jié)構(gòu)本可以使用單一的抽象進行統(tǒng)一。 晦澀性很難閱讀、理解。沒有很好地表現(xiàn)出意圖。敏捷開發(fā)避免“軟件腐化味” 的面向?qū)ο蟮脑O(shè)計原則單一職責原則(SRP) ：一個類應(yīng)該僅有一個引起它變化的原因。 開放-封閉原則(OCP) ：軟件實體應(yīng)該是可以擴展的，但是不可修改。 Liskov替換原則(LSP) ：子類型必須能夠替換掉它們的基類型。 依賴倒置原則(DIP) ：抽象不應(yīng)該依賴于細節(jié)。細節(jié)應(yīng)該依賴于抽象。 接口隔離原則(ISP) ：不應(yīng)該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結(jié)構(gòu)。 重用發(fā)布等價原則(REP) ：重用的粒度就是發(fā)布的粒度。 共同封閉原則(CCP) ：包中的所有類對于同一類性質(zhì)的變化應(yīng)該是共同封閉的。一個變化若對一個包產(chǎn)生影響，則將對該包中的所有類產(chǎn)生影響，而對于其他的包不造成任何影響。 共同重用原則(CRP) ：一個包中的所有類應(yīng)該是共同重用的。如果重用了包中的一個類，那么就要重用包中的所有類。 無環(huán)依賴原則(ADP) ：在包的依賴關(guān)系圖中不允許存在環(huán)。 穩(wěn)定依賴原則(SDP) ：朝著穩(wěn)定的方向進行依賴。 穩(wěn)定抽象原則(SAP)