第01-軟件工程概述

軟件工程第一章軟件工程概述學(xué)習(xí)目標(biāo)軟件危機(jī)和軟件工程的起源軟件生命周期和軟件過程模型傳統(tǒng)軟件生命周期敏捷過程begin

sensor_get(vertical_veloc_sensor);

sensor_get(horizontal_veloc_sensor);

vertical_veloc_bias:=integer(vertical_veloc_sensor);

horizontal_veloc_bias:=integer(horizontal_veloc_sensor);

...

exception

whennumeric_error=>calculate_vertical_veloc();

whenothers=>use_irs1();

end;航空：控制慣性導(dǎo)航系統(tǒng)的計(jì)算機(jī)向控制引擎噴嘴的計(jì)算機(jī)發(fā)送了一個無效數(shù)據(jù)，僅僅將一個64位浮點(diǎn)數(shù)轉(zhuǎn)換成16位有符號整數(shù)時，產(chǎn)生的溢出，表明在將一個64位浮點(diǎn)數(shù)轉(zhuǎn)換成16位有符號整數(shù)時，產(chǎn)生了溢出。溢出值測量的是火箭的水平速率，這比早先的Ariane4火箭所能達(dá)到的高出了5倍。在設(shè)計(jì)Ariane4火箭的軟件時，他們小心地分析了數(shù)字值，并且確定水平速率絕不會超出一個16位的數(shù)。不幸的是，他們在Ariane5火箭的系統(tǒng)中簡單地重新使用了這一部分，而沒有檢查它所基于的假設(shè)。這個錯誤導(dǎo)致1996年6月4日，Ariane5火箭初次發(fā)射后僅僅37秒，火箭偏離它的飛行路徑，解體并爆炸了?；鸺陷d有價值5億美元的通信衛(wèi)星。6億美元付之一炬。

發(fā)生在我們身邊的事件醫(yī)療：最廣為人知的是加拿大原子能公司制造的Therac－25線性加速放射器致人死亡事件。該機(jī)器由計(jì)算機(jī)控制，耗資百萬元以上，由于5次連續(xù)性的錯誤造成放射過量，5位病人死亡，2人重傷。死亡病人接受了超過正常劑量100倍以上的放射。

證券：因市場數(shù)據(jù)分配系統(tǒng)出現(xiàn)故障，日本東京證券交易所2012年2月2日中斷241支股票的早盤交易。東京證交所２０１０年１月耗資１３０億日元（約合１.７億美元）引進(jìn)名為“箭頭”的高速交易系統(tǒng)。這套系統(tǒng)處理每單交易耗時大約千分之二秒。由于2005年東京交易所的系統(tǒng)故障致使瑞穗證券公司蒙受了巨額損失，東京地方法院2011年12月判處東京交易所賠償瑞穗證券公司107億日元。。

2007-10-30日由于官方票務(wù)網(wǎng)站流量曾瞬時達(dá)到每小時800萬次，超過了系統(tǒng)設(shè)計(jì)的每小時100萬次的承受量。啟動后第一小時從各售價渠道瞬時提交到票務(wù)系統(tǒng)的門票達(dá)到20萬張(每秒56張)，也超過了系統(tǒng)設(shè)計(jì)的每小時銷售15萬張(每秒42張)的票務(wù)處理能力。北京奧組委不得不作出停止售票的決定。從初步的情況分析，并不是帶寬的問題，主要還是系統(tǒng)后臺的數(shù)據(jù)庫的處理能力，在設(shè)計(jì)、規(guī)劃方面，還有待改進(jìn)。123061.1軟件危機(jī)軟件危機(jī)的表現(xiàn)軟件開發(fā)費(fèi)用和進(jìn)度失控。軟件的可靠性差。生產(chǎn)出來的軟件難以維護(hù)。軟件危機(jī)的背后軟件的類型變得更多，從簡單的嵌入式系統(tǒng)到復(fù)雜的全球信息系統(tǒng)技術(shù)、業(yè)務(wù)和社會的快速變革導(dǎo)致不斷增長的需求大規(guī)模應(yīng)用帶來影響?yīng)毩⒌膽?yīng)用、交易為特征的交互式應(yīng)用、嵌入式控制系統(tǒng)、批處理系統(tǒng)、娛樂系統(tǒng)建模和仿真系統(tǒng)、數(shù)據(jù)采集系統(tǒng)、集成系統(tǒng)1.2軟件工程的概念今天，計(jì)算機(jī)系統(tǒng)開發(fā)成本的分配發(fā)生了戲劇性的變化。軟件，而不是硬件，是最大的成本項(xiàng)。管理者和很多開發(fā)人員面臨著同樣的問題為什么需要那么長時間才能結(jié)束開發(fā)？什么樣的開發(fā)過程才能保證軟件的質(zhì)量？這些問題以及其它許多問題都表明了對軟件及其開發(fā)的方式是必須關(guān)注了——這種關(guān)注最終導(dǎo)致了軟件工程實(shí)踐的出現(xiàn)。軟件工程的定義起源1968年北約組織在德國幕尼黑召開的一次關(guān)于軟件的學(xué)術(shù)會議上提出了“軟件危機(jī)”問題,并提出了軟件工程的概念.什么是軟件工程軟件工程是為了經(jīng)濟(jì)地獲得可靠的和能在實(shí)際機(jī)器上高效運(yùn)行的軟件而確立和使用的健全的工程原理（方法）。”--FeitzBauer軟件工程的定義軟件工程的幾種定義B.W.Boehm(1981):運(yùn)用現(xiàn)代科學(xué)技術(shù)來設(shè)計(jì)并構(gòu)造計(jì)算機(jī)程序,以及開發(fā)、運(yùn)行和維護(hù)這些程序所必需的相關(guān)資料.IEEE(1993)：軟件工程將系統(tǒng)化的、規(guī)范的、可度量的方法應(yīng)用于軟件的開發(fā)、運(yùn)行和維護(hù)的過程,即將工程化應(yīng)用于軟件中.軟件工程的定義將各種定義的共性歸納有下幾點(diǎn)：針對軟件而言；研究對象涉及到軟件的開發(fā)和維護(hù)過程；重視規(guī)范化的文檔和資料.傳統(tǒng)軟件工程的特點(diǎn):規(guī)范化:多人共同開發(fā)和維護(hù)軟件時,人人都必須遵循相同的約束規(guī)范.文檔化:在軟件開發(fā)的各階段都要有相關(guān)的文檔,用于描述設(shè)計(jì)思想、設(shè)計(jì)過程和具體實(shí)現(xiàn)技術(shù)等信息,以便開發(fā)和維護(hù)時參考.工程化:按照工程化的思想開發(fā)和維護(hù)軟件產(chǎn)品.軟件工程的定義(Cont.)軟件工程的本質(zhì)關(guān)注于大型軟件產(chǎn)品的構(gòu)造控制軟件的復(fù)雜性提高開發(fā)軟件的效率在開發(fā)軟件過程中合作滿足用戶的需求軟件工程的多樣性軟件類型的多樣性獨(dú)立的應(yīng)用、交易為特征的交互式應(yīng)用、嵌入式控制系統(tǒng)、批處理系統(tǒng)、娛樂系統(tǒng)、建模和仿真系統(tǒng)、數(shù)據(jù)采集系統(tǒng)、集成系統(tǒng)不同類型的系統(tǒng)可能需要不同的軟件工程技術(shù)涉及到人身安全的系統(tǒng)，其安全性和可靠性要求極高；某些嵌入式控制系統(tǒng)，其測試成本昂貴。軟件工程的基本原理著名軟件工程專家B.W.Boehm綜合軟件專家、學(xué)者們提出的關(guān)于軟件開發(fā)的意見,并結(jié)合其在TRW公司多年開發(fā)軟件的經(jīng)驗(yàn),于是1983年在一篇論文中提出了軟件工程的7條基本原理.(1)用分階段的生命周期計(jì)劃嚴(yán)格管理把軟件生命周期劃分成若干個階段;制定切實(shí)可行的計(jì)劃;嚴(yán)格按照計(jì)劃對軟件開發(fā)和維護(hù)進(jìn)行管理.(2)堅(jiān)持進(jìn)行階段評審在每個階段完成時都要進(jìn)行嚴(yán)格的評審;盡早發(fā)現(xiàn)并改正錯誤.(3)實(shí)行嚴(yán)格的產(chǎn)品版本控制在開發(fā)和維護(hù)過程中,不允許隨意修改軟件成份;必須對軟件進(jìn)行修改時,實(shí)施嚴(yán)格的配置管理,以保證軟件各成份的一致性.(4)采用現(xiàn)代程序設(shè)計(jì)技術(shù)結(jié)構(gòu)化程序設(shè)計(jì)技術(shù)結(jié)構(gòu)分析(SA)與結(jié)構(gòu)設(shè)計(jì)(SD)技術(shù)面向?qū)ο蟪绦蛟O(shè)計(jì)技術(shù)構(gòu)件程序設(shè)計(jì)技術(shù)(5)結(jié)果便于審查(文檔支持)軟件產(chǎn)品是一種邏輯產(chǎn)品,其可見性差,難以度量;為了更好地進(jìn)行管理和評價,應(yīng)明確規(guī)定開發(fā)組織的責(zé)任和產(chǎn)品標(biāo)準(zhǔn),使所得到地結(jié)果能夠清楚地審查.(6)人員少而精開發(fā)組人員素質(zhì)高;人數(shù)越少越好.(7)承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性積極主動地采納新的軟件技術(shù);軟件積極主動地采納新的軟件技術(shù);不斷總結(jié)經(jīng)驗(yàn).1.3軟件生命周期生命周期(lifecycle)：當(dāng)過程涉及到建造某種產(chǎn)品時,常將過程稱之為“生命周期”.軟件生命周期SLC(SoftwareLifeCycle):

軟件開發(fā)和維護(hù)的過程稱之為軟件生命周期,它描述了軟件產(chǎn)品從設(shè)想到實(shí)現(xiàn)、提交、使用和維護(hù)的過程.軟件開發(fā)通常包括的幾個階段：

軟件定義階段問題定義可行性分析項(xiàng)目估算項(xiàng)目計(jì)劃建模需求分析軟件設(shè)計(jì)構(gòu)建編碼測試部署維護(hù)安裝交付支持維護(hù)軟件生命周期與開發(fā)模型有關(guān).在開發(fā)一個較大規(guī)模的軟件項(xiàng)目時,必須首先確定生命周期的過程模型(開發(fā)模型)。在開發(fā)過程中,嚴(yán)格按照過程模型進(jìn)行。一個成熟的軟件公司,對于每類軟件項(xiàng)目都應(yīng)有固定的過程模型,以及過程模型的標(biāo)準(zhǔn)和范本.1.3.1軟件過程模型軟件過程是指軟件整個生命周期，從需求獲取，需求分析，設(shè)計(jì)，實(shí)現(xiàn)，測試，發(fā)布和維護(hù)一個過程模型。一個軟件過程定義了軟件開發(fā)中采用的方法，但軟件工程還包含該過程中應(yīng)用的技術(shù)——技術(shù)方法和自動化工具。區(qū)別一個過程是為達(dá)到目標(biāo)的部分按序排列步驟的集合；在軟件工程中，目標(biāo)是構(gòu)造一個軟件產(chǎn)品，或增強(qiáng)一個現(xiàn)存產(chǎn)品；過程工程的目標(biāo)是開發(fā)一個和增強(qiáng)一個過程。軟件工程的層次(Cont.)SoftwareEngineeringSoftwareEngineeringaqualityfocusprocessmethodstools方法:開發(fā)軟件的技術(shù).工具:在方法中使用的自動化或半自動化支撐環(huán)境.過程:獲得高質(zhì)量軟件所需要的一系列活動、約束和資源.軟件工程方法學(xué)的三要素軟件過程模型軟件開發(fā)過程模型是軟件開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架。它能直觀表達(dá)軟件開發(fā)全過程，明確規(guī)定要完成的主要活動、任務(wù)和開發(fā)策略。軟件開發(fā)過程模型也常稱為：軟件過程模型軟件生命周期模型軟件工程范型1.3.2瀑布模型問題定義需求分析可行性研究軟件項(xiàng)目計(jì)劃總體設(shè)計(jì)詳細(xì)設(shè)計(jì)測試發(fā)布與實(shí)施瀑布模型維護(hù)傳統(tǒng)生命周期線性順序模型瀑布模型“瀑布”模型(WaterfallModel)是最早使用的模型,是由WinstonRoyce于1970年提出的,該模型的出現(xiàn)成為軟件開發(fā)史上的一個重要轉(zhuǎn)折點(diǎn).瀑布模型就象瀑布一樣,一級一級地實(shí)現(xiàn).下一個階段開始之前,前一個階段必須完成。瀑布模型從一種較高的觀點(diǎn)看待軟件開發(fā),必須事先將每一個階段都安排好,開發(fā)時只需按模型的順序進(jìn)行即可。每個階段都是一個里程碑(Milestone)或基線(Baseline),在每個里程碑處都有明確的評價標(biāo)準(zhǔn),并進(jìn)行嚴(yán)格的評審與審計(jì),通過后才能進(jìn)入下一個階段,這樣項(xiàng)目經(jīng)理就能控制好項(xiàng)目的開發(fā)進(jìn)度、成本和質(zhì)量.瀑布模型(Cont.)瀑布模型的優(yōu)點(diǎn):結(jié)構(gòu)簡單,強(qiáng)調(diào)軟件開發(fā)過程的階段性和順序性;對軟件開發(fā)管理嚴(yán)格,文檔齊全(里程碑驅(qū)動或稱文檔驅(qū)動),注重復(fù)審,保證了軟件的質(zhì)量;軟件開發(fā)的支持工具比較齊全;支持推遲實(shí)現(xiàn)的觀點(diǎn),盡可能將編碼向后推遲.瀑布模型的缺點(diǎn):實(shí)際項(xiàng)目很少按照該模型給出的順序進(jìn)行重視需求規(guī)格說明,然而獲得一個完整的規(guī)格說明是非常困難的,導(dǎo)致了開發(fā)出來的系統(tǒng)最終需求與最初需求不一致,大大地降低了實(shí)用性.由于強(qiáng)調(diào)軟件開發(fā)的階段性,反饋信息慢,拖延了開發(fā)進(jìn)度;由于是文檔驅(qū)動的,因此耗費(fèi)了太多的時間和精力;錯誤具有放大效應(yīng)推遲實(shí)現(xiàn)加大了失敗的風(fēng)險瀑布模型選擇瀑布模型的條件：在開發(fā)時間內(nèi)需求不變化或變化較少的項(xiàng)目;分析設(shè)計(jì)人員對應(yīng)用領(lǐng)域較熟悉的項(xiàng)目;低風(fēng)險的項(xiàng)目;用戶使用環(huán)境相對穩(wěn)定的項(xiàng)目;盡管有許多不足,盡管有許多新的過程模型出現(xiàn),瀑布模型仍是使用最廣泛的過程模型。有效應(yīng)用瀑布模型的策略：微軟公司：嚴(yán)格的里程碑制度CMM：嚴(yán)格的過程管理加入原型特征：允許反復(fù)原型模型原型模型(PrototypeModel)由客戶和開發(fā)者進(jìn)行初步需求分析后,產(chǎn)生初步的系統(tǒng)規(guī)格說明書,根據(jù)該規(guī)格說明書快速產(chǎn)生一個可運(yùn)行的原型產(chǎn)品.向客戶展示該原型產(chǎn)品,對客戶進(jìn)行培訓(xùn),讓客戶試用,與客戶一起評價規(guī)格說明書的完整性、準(zhǔn)確性和一致性;根據(jù)評價結(jié)果,進(jìn)一步修改規(guī)格說明書;根據(jù)修改過的規(guī)格說明書,對原型進(jìn)行修改,產(chǎn)生一個新的原型,讓客戶試用,再與客戶一起評價該原型,……這一過程可重復(fù)多次,直到最終的規(guī)格說明演化成與用戶和客戶一致的、可執(zhí)行的系統(tǒng)為止.原型需求、設(shè)計(jì)或試用的次數(shù)：取決于原型的目標(biāo)原型模型的總體目標(biāo)：降低開發(fā)的風(fēng)險和不確定因素原型法的分類：拋棄式模型、進(jìn)化式模型1.拋棄式模型(ThrowawayModel)由H.Gomaa于1981年提出的,該模型用于確認(rèn)需求和設(shè)計(jì),而不是設(shè)計(jì)實(shí)際可用的系統(tǒng)。首先制定一個開發(fā)計(jì)劃,然后進(jìn)行需求分析、設(shè)計(jì)、編碼、測試,由用戶或客戶評價,如果不滿意再返回需求分析部分或設(shè)計(jì)部分或編碼部分,直到滿意為止.該模型開發(fā)的結(jié)果不是為最后使用,而是為了理解需求和開發(fā)方法,驗(yàn)證那些模糊的、沒有把握的需求.任務(wù)完成后該模型被拋棄,真正的系統(tǒng)開發(fā)將依據(jù)該模型的結(jié)果從頭開始.2.進(jìn)化式模型(EvolutionaryModel)首先設(shè)計(jì)一個全局性框架,然后建立一個初始的穩(wěn)定模型,運(yùn)行該原型,并反復(fù)添加、修改和完善,逐步向目標(biāo)系統(tǒng)進(jìn)化.每一次進(jìn)化,都產(chǎn)生一個逼近目標(biāo)的新版本.該模型在進(jìn)化過程中,始終強(qiáng)調(diào)可靠性、可維護(hù)性、適應(yīng)性和效率等軟件質(zhì)量問題.該模型的最終成果就是投入使用的系統(tǒng).這種方法的優(yōu)點(diǎn)是客戶可跟蹤開發(fā)過程,及時了解并建議修改開發(fā)的過程,最終系統(tǒng)能令用戶滿意,但開發(fā)進(jìn)度和成本難以控制.修改表修改表修改表原型需求測試原型實(shí)現(xiàn)原型設(shè)計(jì)修訂原型用戶/客戶審查系統(tǒng)需求(有時是非正式的,或未完成的）提交的系統(tǒng)丟棄型原型進(jìn)化型原型原型模型(Cont.)原型模型(Cont.)原型模型的優(yōu)點(diǎn)：使客戶了解最終產(chǎn)品的大致狀況;使客戶和開發(fā)人員深入理解項(xiàng)目的實(shí)質(zhì);共同討論一些雙方難以達(dá)成一致的部分;降低軟件開發(fā)的風(fēng)險.原型模型的缺點(diǎn)：由于有了一個原型產(chǎn)品,不利于開發(fā)人員的創(chuàng)新;開發(fā)進(jìn)度可能難以控制.原型模型(Cont.)選擇原型模型的條件:用戶定義了軟件的一組一般性目標(biāo)，但不能標(biāo)識出詳細(xì)的輸入、處理及輸出需求；開發(fā)者可能不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性或人機(jī)交互的形式。投標(biāo)時向客戶展示產(chǎn)品的框架;為對于不熟悉的領(lǐng)域或行業(yè)開發(fā)項(xiàng)目;快速原型法用進(jìn)化式原型法快速開發(fā)規(guī)模不大的軟件產(chǎn)品.1.3.2演化軟件過程模型背景：業(yè)務(wù)和產(chǎn)品需求隨著開發(fā)的發(fā)展常常發(fā)生改變，想找到最終產(chǎn)品的一條直線路徑是不可能的；緊迫的市場期限使得難于完成一個完善的軟件產(chǎn)品，但可以先提交一個有限的版本以對付競爭的或商業(yè)的壓力；只要核心產(chǎn)品或系統(tǒng)需求能夠被很好地理解，而產(chǎn)品或系統(tǒng)的細(xì)節(jié)部分可以進(jìn)一步定義。要求：在這些情況及其他類似情況下，軟件工程師需要一個過程模型，以便能明確設(shè)計(jì)，同時又能適應(yīng)隨時間演化的產(chǎn)品的開發(fā)。

模型：演化模型是利用一種迭代和增量的思想方法。它的特征是使軟件工程師漸進(jìn)地開發(fā)，逐步完善的軟件版本。增量模型增量模型(IncrementalModel)根據(jù)需求規(guī)模說明書將系統(tǒng)按功能分解成若干個子系統(tǒng).開始開發(fā)一個子系統(tǒng)的功能,經(jīng)過設(shè)計(jì)、實(shí)現(xiàn)、集成、測試后交付使用,然后再開發(fā)其他子系統(tǒng),再加入已有的系統(tǒng)中,逐漸構(gòu)成能完成全部功能的完整系統(tǒng).規(guī)格說明設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶規(guī)格說明設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶規(guī)格說明設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶增量1增量2增量3增量n增量模型(Cont.)增量模型的優(yōu)點(diǎn):項(xiàng)目可以分解為多個子系統(tǒng),子系統(tǒng)之間邊界清楚;任務(wù)或功能模塊驅(qū)動,可分階段提交產(chǎn)品;系統(tǒng)本身具有良好的模塊化特征,模塊內(nèi)部高內(nèi)聚,模塊之間低耦合,模塊本身信息隱蔽;增量模型的缺點(diǎn):不適合各部分聯(lián)系緊密的項(xiàng)目;系統(tǒng)整體結(jié)構(gòu)的一致性可能較差;各子系統(tǒng)風(fēng)格可能不一致.選擇增量模型的條件：在整個開發(fā)過程中,需求都可能發(fā)生變化,客戶接受分階段交付產(chǎn)品的項(xiàng)目;分析設(shè)計(jì)人員對應(yīng)用領(lǐng)域不熟悉的項(xiàng)目;中高等風(fēng)險項(xiàng)目;用戶可參與到整個開發(fā)過程中的項(xiàng)目;使用面向?qū)ο笳Z言或第四代語言開發(fā)的項(xiàng)目;軟件公司自己有較好的類庫,構(gòu)件庫;大型軟件系統(tǒng)。開發(fā)周期較長(超過1年).分批投資的項(xiàng)目.螺旋模型螺旋模型(SpiralModel)是Boehm提出來的,他從風(fēng)險角度看待軟件開發(fā)過程,建議螺旋模型將風(fēng)險管理結(jié)合到開發(fā)活動中,以最小化風(fēng)險并可控制風(fēng)險.先進(jìn)行需求分析和生命周期計(jì)劃,包括預(yù)算、方案、約束,進(jìn)行評審,然后進(jìn)行風(fēng)險分析,建立原型1,明確操作方法.修正預(yù)算、方案和約束,再評審,進(jìn)行風(fēng)險分析,建立原型2,明確軟件需求,確認(rèn)需求,制定開發(fā)計(jì)劃.修正預(yù)算、方案和約束,再評審,進(jìn)行風(fēng)險分析,建立原型3,進(jìn)行軟件設(shè)計(jì),確認(rèn)并驗(yàn)證設(shè)計(jì),做集成和測試計(jì)劃.修正預(yù)算、方案和約束,再評審,進(jìn)行風(fēng)險分析,建立原型4,進(jìn)行詳細(xì)設(shè)計(jì),編碼,單元測試,系統(tǒng)測試,驗(yàn)收測試,實(shí)現(xiàn)計(jì)劃.螺旋模型(Cont.)螺旋模型的優(yōu)點(diǎn)：強(qiáng)調(diào)風(fēng)險管理,開發(fā)大型軟件時可降低風(fēng)險.實(shí)際上是一個過程管理模型，而非開發(fā)模型每一次循環(huán)可以采用不同的模型，適應(yīng)風(fēng)險變化模型的缺點(diǎn)：開發(fā)進(jìn)度可能難以控制.RUPRUPRUP（RationalUnifiedProcess）統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程)是一個面向?qū)ο笄一诰W(wǎng)絡(luò)的程序開發(fā)方法論。RUP中的每個階段可以進(jìn)一步分解為迭代。一個迭代是一個完整的開發(fā)循環(huán)，產(chǎn)生一個可執(zhí)行的產(chǎn)品版本，是最終產(chǎn)品的一個子集，它增量式地發(fā)展，從一個迭代過程到另一個迭代過程到成為最終的系統(tǒng)。RUP現(xiàn)在軟件產(chǎn)業(yè)界普遍認(rèn)為，開發(fā)復(fù)雜軟件項(xiàng)目必須采用:基于UML的以構(gòu)架為中心用例驅(qū)動和風(fēng)險驅(qū)動相結(jié)合的迭代式增量開發(fā)過程RUP具有很多長處提高了團(tuán)隊(duì)生產(chǎn)力，在迭代的開發(fā)過程、需求管理、基于組件的體系結(jié)構(gòu)、可視化軟件建模、驗(yàn)證軟件質(zhì)量及控制軟件變更等方面，針對所有關(guān)鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準(zhǔn)則、模板和工具指導(dǎo)，并確保全體成員共享相同的知識基礎(chǔ)。它建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。但同時它也存在一些不足：RUP只是一個開發(fā)過程，并沒有涵蓋軟件過程的全部內(nèi)容，例如它缺少關(guān)于軟件運(yùn)行和支持等方面的內(nèi)容；此外，它沒有支持多項(xiàng)目的開發(fā)結(jié)構(gòu)敏捷開發(fā)是一種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力。人和交互

重于

過程和工具?？梢怨ぷ鞯能浖赜?/p>

求全責(zé)備的文檔?？蛻魠f(xié)作

重于

合同談判。隨時應(yīng)對變化

重于

遵循計(jì)劃。敏捷方法有時候被誤認(rèn)為是無計(jì)劃性和紀(jì)律性的方法，實(shí)際上更確切的說法是敏捷方法強(qiáng)調(diào)適應(yīng)性而非預(yù)見性。適應(yīng)性的方法集中在快速適應(yīng)現(xiàn)實(shí)的變化。當(dāng)項(xiàng)目的需求起了變化，團(tuán)隊(duì)?wèi)?yīng)該迅