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

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

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

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

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

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

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

8、軟件工程學的是由于“軟件危機”的出現和加重而產生的，研究用工程的方法來管理軟件的開發。開發一個具有一定規模和復雜性的軟件系統與編寫一個簡單的程序不一樣。大型、復雜軟件系統的開發是一項工程，必須按照工程化的方法組織軟件的生產和管理，必須經過分析、設計、實現、測試、維護等一系列軟件過程和活動軟件工程學的產生提出有效的方法和工具支持軟件開發1968年提出軟件工程概念和思想20世紀70年代的結構化軟件開發方法20世紀80年代的面向對象的軟件開發方法新的技術: 軟件重用、快速原型、需求工程典型技術: COM, Java, C+, J2EE, .Net, .支撐工具和環境：Jbuilder, Visual

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

10、驗而證明正確的管理方法和最好的技術手段結合起來，經濟有效地開發和維護軟件。軟件工程是一門不斷發展的學科。軟件工程定義(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) 軟件工程就是建立和使用一套合理的工程原理，從而經濟地獲得可靠的、可以在實際機器上高效運行的軟件。軟

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）把系統的、規范的、 可度量的途徑應用于軟件開發、運行和維護過程，也就是把工程應用于軟件；（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、程是應用計算機科學、數學及管理科學等原理開發軟件的工程。它采用經過實踐驗證的工程的原則、方法，以提高質量，降低成本為目的。軟件工程的本質特性關注于大型程序的構造控制軟件復雜性適應軟件的經常變化性提高軟件開發的效率和諧合作開發軟件使軟件有效地支持它的用戶需求軟件是有一種文化背景的人為另一種文化背景的人開發的產品。軟件工程的基本原理用分階段的生命周期計劃嚴格管理堅持進行階段評審實行嚴格的產品控制采用現代程序設計技術結果應能清楚地審查開發小組的人員應該少而精承認不斷改進軟件工程實踐的必要性軟件工程包括技術和管理兩方面的內容，是技術與管理緊密結合所形成的工程學科。通常把在軟件生命周期全過程中使用的一整

15、套技術方法的集合稱為軟件工程方法學(methodology)，也稱為范型(paradigm)。軟件工程方法學軟件工程方法學三要素軟件工程方法學包含3個要素：方法、工具和過程。方法完成軟件開發各項任務的技術方法。工具為運用方法而提供的軟件工程支撐環境（支撐分析、設計、開發等）。過程規定了完成軟件開發各項任務的工作步驟。傳統軟件工程方法學傳統軟件工程方法學是生命周期方法學軟件生命周期一個軟件定義、開發、使用和維護，直到最終被廢棄，要經歷的漫長的時期，稱為軟件的生命周期。生命周期方法學這種方法學把軟件生命周期的全過程依次劃分為若干個階段，然后順序地完成每個階段的任務。2 面向對象方法學面向對象主要概

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

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

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

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

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

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

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

23、策略，應遵守什么樣的規定和制約，將這些活動框架（忽略不必要的細節）用一種模型表示出來，稱為軟件過程模型（或軟件開發模型或軟件生命周期模型）。軟件過程模型是軟件開發全部過程、活動和任務的結構框架。常用軟件過程模型（1）瀑布模型(Waterfall Model ）（2）快速原型模型(Rapid Prototype Model)（3）增量模型 (Incremental Model)（4）螺旋模型 (Spiral Model)（5）面向對象模型（噴泉模型、可重用組件模型）（6）統一軟件開發過程（IBM RUP）（7）敏捷(靈活)過程與極限編程（8）微軟過程（Microsoft Solution Fra

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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