軟件開發(fā)過程概述報告課件

1、軟件開發(fā)過程概述 Beyond Technology南海東軟信息技術(shù)學院2012.03第1頁，共82頁。本節(jié)教學目標本節(jié)的目標是介紹軟件過程的思想。學習本節(jié)，需要了解以下內(nèi)容：軟件過程和軟件過程模型的概念幾個一般的軟件過程模型及它們的使用范圍軟件需求、軟件開發(fā)、測試和進化中所涉及到的活動概貌第2頁，共82頁。本節(jié)主要內(nèi)容什么是軟件過程軟件過程與軟件工程的關(guān)系什么是軟件過程模型過程反復(fù)過程活動第3頁，共82頁。幾個概念什么軟件：計算機程序和相關(guān)文檔。軟件產(chǎn)品可為特定客戶或通用市場開發(fā)什么是軟件工程：軟件工程是關(guān)于軟件生產(chǎn)的各個方面的工程學科什么是軟件過程：以軟件開發(fā)和進化為目的的一系列活動什么是

2、軟件過程模型：以特定角度提出的軟件過程的簡化表示形式第4頁，共82頁。軟件過程軟件過程是復(fù)雜的，像所有智力過程一樣，它依賴于人的判斷軟件過程具有極大的差異型。沒有一個理想的過程，并且不同的機構(gòu)采用的是完全不同的軟件開發(fā)方法。對于一些系統(tǒng)，需要使用一種非常結(jié)構(gòu)化的開發(fā)過程；而對于業(yè)務(wù)系統(tǒng)，由于需求的變更頻繁，采用一個靈活、敏捷的過程可能更有效第5頁，共82頁。軟件過程雖然不同軟件過程有很大的差異，但是有些基本活動還是所有軟件過程都具有的。它們是：軟件描述：軟件的功能以及軟件操作上的約束必須定義軟件設(shè)計和實現(xiàn)：軟件一定要按照描述來生產(chǎn)軟件有效性驗證：軟件要被確定是有效的，即軟件能做客戶想要的事情軟

3、件進化：軟件一定按客戶需要的變更來進化第6頁，共82頁。軟件過程模型軟件過程模型是軟件過程的抽象表示法。每個過程模型從一個特定的角度表現(xiàn)一個過程，只提供過程的某一側(cè)面的信息。從體系結(jié)構(gòu)的角度來分析一些非常一般的過程模型，來解釋不同的軟件開發(fā)方法。在實際的開發(fā)過程中，往往將這些模型看做過程框架，對其進行擴展并匹配它們來創(chuàng)建符合實際環(huán)境的專用的軟件開發(fā)過程。討論以下過程模型：瀑布模型進化式開發(fā)基于組件的軟件工程這三個一般模型廣泛的用于當前的軟件工程實踐。它們相互不排斥，而且經(jīng)常一起使用，尤其是在大型系統(tǒng)開發(fā)當中。第7頁，共82頁。瀑布模型這個模型采用一些基本的過程活動，即描述、開發(fā)、有效性驗證和進

4、化，并且使用單獨的過程階段（如需求描述、軟件設(shè)計、實現(xiàn)和測試等階段）表現(xiàn)這些活動。該模型圖從一個階段到另一個階段逐次下降，因此命名為“瀑布模型”或軟件生命周期模型：第8頁，共82頁。瀑布模型需求分析與定義：通過咨詢系統(tǒng)用戶建立系統(tǒng)的服務(wù)、約束和目標。并對其詳細定義從而為系統(tǒng)描述服務(wù)系統(tǒng)和軟件設(shè)計：系統(tǒng)設(shè)計過程區(qū)分硬件和軟件系統(tǒng)的需求。它建立一個總體的系統(tǒng)體系結(jié)構(gòu)。軟件設(shè)計包括識別和描述一些基本的軟件系統(tǒng)的抽象及其之間的關(guān)系第9頁，共82頁。實現(xiàn)和單元測試：在這個階段，軟件設(shè)計是作為一組程序或者程序單元實現(xiàn)的，單元測試就是檢驗每個單元是否符合描述集成和系統(tǒng)測試：集成單個的程序單元或者程序，并對他

5、能夠整體進行測試以確保其滿足需求。在測試之后，軟件系統(tǒng)交付給客戶使用運行和維護：正常情況下（雖然不是必須的），這是一個具有最長生命周期的階段。系統(tǒng)被安裝并且進入實際的使用中。維護包括改正在早期各階段末發(fā)現(xiàn)的錯誤，改善系統(tǒng)單元的實現(xiàn)，當新的需求出現(xiàn)時提供系統(tǒng)的服務(wù)能力第10頁，共82頁。瀑布模型主要優(yōu)勢：它的每個階段都生成文檔，而且它與其他工程過程模型相一致主要缺點：他將項目生硬得分解成這些確切的階段。委托事項一定要在過程的早期階段清晰給出，而這意味著他難以響應(yīng)用戶需求的變更實用范圍：只有在全面理解需求，而且在系統(tǒng)開發(fā)過程中不太可能發(fā)生重大改變的時候，應(yīng)該采用瀑布模型。第11頁，共82頁。進化式

6、開發(fā)模型這個方法在描述活動、開發(fā)活動和有效性驗證活動中不斷修改內(nèi)容，即用抽象描述快速開發(fā)出一個初始的系統(tǒng)，然后由客戶提供的信息來精煉系統(tǒng)，直到客戶滿意為止該方法主張描述、開發(fā)和有效性驗證等活動并行執(zhí)行，同時讓這些活動都能得到快速的反饋信息第12頁，共82頁。進化式開發(fā)模型進化式開發(fā)有兩個基本類型：探索式開發(fā)：其目標是與用戶一起工作，共同探討系統(tǒng)需求，直至最后交付系統(tǒng)。這類開發(fā)是從需求較清楚的部分開始，根據(jù)用戶的建議逐漸向系統(tǒng)中添加功能拋棄式原型：這種開發(fā)方法的目標是理解用戶需求，然后再給出系統(tǒng)的一個較好的需求定義。原型著重對客戶需求理解差的那一部分的實驗第13頁，共82頁。進化式開發(fā)模型主要優(yōu)

7、勢：進化式方法在應(yīng)付客戶緊急需要的情況下較瀑布模型更為有效?；谶M化式方法的軟件過程的好處是不斷的補充完善。當用戶對系統(tǒng)需求有更深刻理解時，能夠很快在軟件系統(tǒng)中得到反映。從工程學和管理學角度來看，此方法存在兩個問題：過程不可見：如果系統(tǒng)開發(fā)很快，要產(chǎn)生每個版本的文檔來反映變更就很不劃算系統(tǒng)結(jié)構(gòu)通常較差：這是因為連續(xù)的變革損壞了系統(tǒng)的結(jié)構(gòu)。越往后變更系統(tǒng)就越困難，而且成本逐漸上升第14頁，共82頁。進化式開發(fā)模型實用范圍：對于很小規(guī)?；蛘咧行拖到y(tǒng)（達到500000行代碼），采用進化式開發(fā)方法不失為一種最佳選擇。對于大型的，生命周期很長的系統(tǒng)，由不同的團隊負責開發(fā)系統(tǒng)的不同部分，進化式開發(fā)的問題就

8、變得很突出。采用這種方法很難建立一個穩(wěn)定的系統(tǒng)框架，保證來自不同團隊的貢獻可以很好的集成。因此對于大型系統(tǒng)，可以采用混合型開發(fā)方法。結(jié)合瀑布模型和進化式開發(fā)方法的優(yōu)點。第15頁，共82頁?；诮M件的軟件工程模型這種方法是基于已存在的很多可復(fù)用的組件。系統(tǒng)的開發(fā)過程主要是把這些組件集成到新系統(tǒng)中，而非從頭開發(fā)。復(fù)用時常對快速系統(tǒng)開發(fā)來說是必不可少的。面向復(fù)用的方法依賴可以存取的可復(fù)用軟件組件以及能集成這些組件的框架。第16頁，共82頁?；诮M件的軟件工程模型初始需求和有效性驗證方面和其他開發(fā)過程一樣，但是中間過程就有很大的不同：組件分析：按照需求描述，搜尋能滿足需求的組件需求修改：根據(jù)得到的組件

9、信息修改需求，如不允許修改需求，則要重新尋求組件使用復(fù)用的系統(tǒng)設(shè)計：在這個階段設(shè)計系統(tǒng)的框架，或者重復(fù)使用一個已存在的框架。如果沒有合適的框架，則需要重新設(shè)計一個新的軟件開發(fā)和集成：當沒有合適的組件時，就要自己開發(fā)，然后再集成這些自己開發(fā)的和現(xiàn)成的組件，使之成為一個整體。第17頁，共82頁?；诮M件的軟件工程模型主要優(yōu)點：減少了需要開發(fā)的軟件數(shù)量，從而降低了軟件開發(fā)成本，同時也降低了風險。通常也可以使軟件快速交付主要缺點：有時為了適應(yīng)某個組件，存在對客戶需求的修改，而且這可能導致一個不符合用戶真正需要的系統(tǒng)。此外，對系統(tǒng)進化的控制也不起作用，因為可復(fù)用的組件新的版本是不受機構(gòu)控制的第18頁，共

10、82頁。過程反復(fù)對于所有的大型軟件項目來說，變更是不可避免的。這意味著軟件過程不是一個一次性的過程，在有變更請求，系統(tǒng)需要重新去做的時候，過程活動就會有規(guī)律的重復(fù)進行重復(fù)式開發(fā)對于軟件來說是一個十分基礎(chǔ)的內(nèi)容，在這里我們通過兩個過程模型的描述來介紹這個主題，這兩個過程模型是專門設(shè)計用于支持過程重復(fù)的：增量式開發(fā)螺旋式開發(fā)第19頁，共82頁。增量式開發(fā)模型在增量開發(fā)的過程中，客戶大概地提出系統(tǒng)需要提供的服務(wù)，指明哪些服務(wù)是最重要的，哪些是最不重要的。此時，一系列的交付增量被確定，每個增量提供系統(tǒng)功能的子集。對增量中服務(wù)的分配取決于服務(wù)的優(yōu)先次序。最高優(yōu)先級的服務(wù)首先被交付。第20頁，共82頁。增

11、量式開發(fā)模型第21頁，共82頁。增量式開發(fā)模型每個增量開發(fā)沒有必要使用相同的過程方法，當一個增量中的服務(wù)有了完善的描述時，開發(fā)可以使用瀑布模型。在描述不清楚的地方，就可能用一個進化式開發(fā)模型第22頁，共82頁。增量式開發(fā)模型主要優(yōu)點：客戶無需等到整個系統(tǒng)實現(xiàn)。第一個增量會滿足他們大多數(shù)關(guān)鍵需求，因此，軟件馬上就能使用客戶可以將早期的增量作為原型，從中獲得對后面系統(tǒng)增量的需求經(jīng)驗項目總體性失敗的風險比較低。雖然可能在一些增量中遇到問題，但是其他一些增量將會成功的交付客戶因為最重要的增量最先提交，而后面的增量也不斷的被集成進來，這就使得最重要的系統(tǒng)服務(wù)得到了最多的測試。主要缺點：很難把客戶的需求映

12、射到適當規(guī)模的增量上。大多數(shù)系統(tǒng)功能都用到的公共服務(wù)很難在初期定義出來第23頁，共82頁。增量式方法模型增量式方法的一個最近的進化方法稱作“極限編程”（extreme programming）。它是建立在開發(fā)和交付非常小的功能增量方式上的，客戶參與在開發(fā)的過程中，經(jīng)常性的參與代碼改進和結(jié)對編程。第24頁，共82頁。螺旋式開發(fā)模型它不是將軟件過程用一系列的活動和活動間的回溯來表示，而是將過程用螺旋線表示。在螺旋線中，每個回路表示軟件過程的一個階段。因此，最里面的回路可能與系統(tǒng)可行性分析有關(guān)，下一個回路與系統(tǒng)需求定義有關(guān)，再下一個回路與系統(tǒng)設(shè)計有關(guān)，等等。第25頁，共82頁。螺旋式開發(fā)模型螺旋式開

13、發(fā)中每個回路分成四個部分：目標設(shè)置：為項目的每個階段定義專門目標風險評估和規(guī)避：每個項目風險確定以后要進行詳細的分析，并采取措施規(guī)避風險開發(fā)和有效性驗證：在風險預(yù)估之后，就可以為系統(tǒng)選擇開發(fā)模型規(guī)劃：對項目進行評審之后確定是否需要進入螺旋線的下一個回路特點：對風險考慮是明確的，對每個環(huán)節(jié)都有風險評估適用于：風險比較大的項目第26頁，共82頁。過程活動在軟件開發(fā)過程中，如何來組織描述、開發(fā)、驗證和進化這四個基本過程，取決于軟件類型、人員以及機構(gòu)的組織結(jié)構(gòu)第27頁，共82頁。過程活動軟件描述軟件描述或者需求工程主要是理解定義系統(tǒng)需要哪些服務(wù)以及找出開發(fā)和運行期間受到哪些約束需求工程對于軟件過程是一

14、個特別關(guān)鍵的階段，這個階段的錯誤將不可避免的帶到后續(xù)的系統(tǒng)設(shè)計和實現(xiàn)階段中第28頁，共82頁。第29頁，共82頁。過程活動軟件描述需求工程過程有四個主要階段：可行性研究：從軟硬件技術(shù)上能否實現(xiàn)，從業(yè)務(wù)角度成本是否劃算來判斷。研究的結(jié)果就是要得出結(jié)論，該系統(tǒng)是否值得進行更細致的分析需求導出和分析：這是一個通過對現(xiàn)有系統(tǒng)分析、與潛在用戶和購買者討論、進行任務(wù)分析等導出系統(tǒng)需求的過程。也許需要開發(fā)一個或多個不同的系統(tǒng)模型和原型。這樣有助于分析員了解所描述的系統(tǒng)需求描述：就是把在分析活動中收集的信息以文檔的形式確定下來。在這個文檔中有兩類需求：用戶需求：從客戶和最終用戶角度對系統(tǒng)需求的抽象描述系統(tǒng)需求

15、：對系統(tǒng)要提供的功能的詳盡描述需求有效性驗證：檢查文檔的描述的準確性、完備性等第30頁，共82頁。過程活動軟件描述需求工程過程的產(chǎn)出：產(chǎn)出用以描述系統(tǒng)的文檔。在這個文檔中包含兩個層次的需求描述：最終用戶和客戶需求高層次的需求描述；系統(tǒng)開發(fā)人員需要比較詳細的系統(tǒng)描述。第31頁，共82頁。過程活動軟件設(shè)計與實現(xiàn)該階段是把系統(tǒng)描述轉(zhuǎn)換成一個可運行的系統(tǒng)的過程包含設(shè)計和編碼兩個部分。如果是進化式開發(fā)方法，可能還包含軟件的精煉過程軟件設(shè)計是對實現(xiàn)軟件的結(jié)構(gòu)、系統(tǒng)的數(shù)據(jù)、系統(tǒng)組件間的接口以及所用的算法的描述。設(shè)計者不可能一次就完成一個完整的設(shè)計，這是一個多次反復(fù)的過程。第32頁，共82頁。過程活動軟件設(shè)計

16、與實現(xiàn)設(shè)計過程中一些專門的活動：體系結(jié)構(gòu)設(shè)計：確定系統(tǒng)是由哪些子系統(tǒng)構(gòu)成的，以及這些子系統(tǒng)之間的關(guān)系是怎樣的，并對這些內(nèi)容編寫文檔抽象描述：對每個子系統(tǒng)提供的服務(wù)以及子系統(tǒng)在什么范圍內(nèi)運行給出抽象描述接口設(shè)計：對每個子系統(tǒng)，都要給出與其他子系統(tǒng)間的接口設(shè)計并編寫文檔。這個接口描述一定是無二義的組件設(shè)計：把服務(wù)分配到不同的組建，并設(shè)計這些組件的接口數(shù)據(jù)結(jié)構(gòu)設(shè)計：詳細設(shè)計系統(tǒng)實現(xiàn)階段要試用的數(shù)據(jù)結(jié)構(gòu)，并給出描述算法設(shè)計：詳細設(shè)計服務(wù)將要采用的算法并對此給出描述以上是設(shè)計過程中非常一般的模型，實際的過程中有不同程度的調(diào)整第33頁，共82頁。過程活動軟件設(shè)計與實現(xiàn)對設(shè)計過程可能的調(diào)整：設(shè)計的最后兩個階

17、段數(shù)據(jù)結(jié)構(gòu)和算法設(shè)計可能推遲到實現(xiàn)過程完成如果試用探索式開發(fā)方法，系統(tǒng)界面的設(shè)計可能要在數(shù)據(jù)結(jié)構(gòu)得到定義之后進行抽象描述階段可能要忽略掉隨著敏捷開發(fā)方法的越來越多的使用，設(shè)計過程的輸出不再是單獨的文檔了，可能是用程序代碼來表示。在系統(tǒng)體系結(jié)構(gòu)完成之后，后面的設(shè)計階段都是漸增式的。每個增量可以表示為一段程序代碼而不是設(shè)計模型結(jié)構(gòu)化的設(shè)計方法（面向功能的設(shè)計）與面向?qū)ο蟮脑O(shè)計方法第34頁，共82頁。過程活動軟件設(shè)計與實現(xiàn)系統(tǒng)設(shè)計完成后，就是實現(xiàn)系統(tǒng)的程序開發(fā)過程程序設(shè)計因人而異，通常沒有統(tǒng)一的模式程序設(shè)計人員要對自己開發(fā)的程序進行調(diào)試錯誤檢測和調(diào)試不是一回事，檢測是要發(fā)現(xiàn)存在的錯誤，而調(diào)試是要定位

18、錯誤并改正這些錯誤進行程序調(diào)試時，首先要對程序的行為有一個最初的預(yù)計，然后執(zhí)行程序看輸出結(jié)果是否同預(yù)期的一樣。調(diào)試過程需要程序員一步步地手動跟蹤代碼，同時會需要一些測試用例來定位問題。第35頁，共82頁。過程活動軟件有效性驗證軟件有效性驗證，或更一般的稱為檢驗和有效性檢驗，是要看系統(tǒng)是否符合他的描述以及系統(tǒng)是否符合客戶的預(yù)期目標。他包括檢查過程和從用戶需求定義到程序開發(fā)的每個軟件過程階段。通常的測試過程：先是組件測試，其次是集成系統(tǒng)測試，最后是用客戶數(shù)據(jù)對系統(tǒng)的測試。這是一個多次反復(fù)的過程。第36頁，共82頁。過程活動軟件有效性驗證測試過程的階段：組件（或單元）測試：測試單個組件，以確保其操作

19、的正確性，獨立的測試每個組件，而不受其他系統(tǒng)組件的影響。組件可能是簡單的實體，如函數(shù)或?qū)ο箢悾蚴沁@些實體的組合集成系統(tǒng)測試：組件得以集成形成系統(tǒng)。這個過程側(cè)重于找出組件間非預(yù)期的交互行為和組件接口問題。也關(guān)注系統(tǒng)是否滿足功能上和非功能上的需求，并測試系統(tǒng)的總體特性。對于大型系統(tǒng)可能有：子系統(tǒng)集成測試、最終系統(tǒng)集成測試等多階段測試過程系統(tǒng)接收測試：系統(tǒng)在運行之前進行的最后階段測試。是用客戶提供的真實數(shù)據(jù)進行測試。能暴露系統(tǒng)需求中的錯誤和遺漏以及系統(tǒng)是否達到性能要求等其他的問題第37頁，共82頁。過程活動軟件有效性驗證組件的開發(fā)和測試是交叉進行的。程序員自己構(gòu)造用來測試的數(shù)據(jù)，在代碼開發(fā)過程中增

20、量的進行測試對于增量式開發(fā)方法，每一個增量在開發(fā)的時候就應(yīng)該測試，這種測試根據(jù)對增量的需求來設(shè)計對于極限編程，測試和需求都是先于開發(fā)過程。這幫助測試者和開發(fā)者理解需求并保證不會由于設(shè)計測試案例而拖延時間一個獨立的測試團隊需要有一個擬定的測試計劃并按照這個測試計劃來工作，制定測試計劃的依據(jù)是系統(tǒng)描述和設(shè)計第38頁，共82頁。過程活動軟件有效性驗證測試計劃是如何把測試和開發(fā)活動聯(lián)系起來的？接收測試也叫做測試，需要持續(xù)到客戶與開發(fā)者都滿意為止系統(tǒng)需要上市銷售時，要進行的測試叫做測試第39頁，共82頁。過程活動軟件進化軟件的變更可以發(fā)生在系統(tǒng)開發(fā)之中或之后的任何時間里現(xiàn)在已經(jīng)不再將軟件工程看作是開發(fā)和

21、維護兩個完全獨立的過程，而是將其看作一個進化的過程，即在軟件的生命期內(nèi)不斷的隨著需求的變化而變更的進化式過程第40頁，共82頁。Rational統(tǒng)一過程Rational統(tǒng)一過程（RUP）是現(xiàn)代過程模型的一個實例。他是混合過程模型的一個很好的實例。他集合了所有一般過程模型的要素，支持反復(fù)，并給出了描述和設(shè)計上的一個好的實踐。RUP過程認識到傳統(tǒng)過程模型展現(xiàn)的是過程的一個視角，RUP一般從三個視角來描述：動態(tài)視角，給出模型隨時間所經(jīng)歷的各個階段靜態(tài)視角，給出所有規(guī)定的過程活動實踐視角，建議在過程中采用好的實踐實例第41頁，共82頁。Rational統(tǒng)一過程RUP動態(tài)視角（組織成幾個可以重復(fù)的階段）

22、開端：建立系統(tǒng)的一個業(yè)務(wù)案例。評估系統(tǒng)對業(yè)務(wù)的貢獻，決定項目是否有必要繼續(xù)進行細化：增進對問題的理解，建立系統(tǒng)的體系框架，給出項目計劃并識別關(guān)鍵項目風險，本階段完成時，就得到系統(tǒng)的需求模型，是軟件的一個體系描述和開發(fā)計劃構(gòu)造：主要關(guān)心的是系統(tǒng)設(shè)計、編碼和測試。系統(tǒng)的各個部分在并行開發(fā)，再集成在一起。在這個階段完成時，就得到了一個能工作的軟件系統(tǒng)了，還有能交付給用戶的相關(guān)文檔轉(zhuǎn)換：RUP的最后階段，關(guān)注如何將系統(tǒng)從開發(fā)單位轉(zhuǎn)移到用戶單位，并使之在真是環(huán)境中工作。此階段完成時，就有了一個在操作環(huán)境下能正常工作的軟件系統(tǒng)及其文檔了第42頁，共82頁。Rational統(tǒng)一過程RUP的靜態(tài)視角（靜態(tài)工作

23、流）工作流描述業(yè)務(wù)建模使用業(yè)務(wù)對業(yè)務(wù)過程進行建模需求找出與系統(tǒng)進行交互的參與者并開發(fā)用例完成對系統(tǒng)需求的建模分析和設(shè)計使用體系結(jié)構(gòu)模型、組件模型、對象模型和序列模型來創(chuàng)建并記錄設(shè)計模型實現(xiàn)實現(xiàn)系統(tǒng)中的組件并將他們合理安排在子系統(tǒng)中，從設(shè)計模型自動代碼生成有助于加快此過程測試測試是一個反復(fù)過程，他的執(zhí)行是與實現(xiàn)緊密相關(guān)聯(lián)的。系統(tǒng)測試緊隨實現(xiàn)環(huán)節(jié)的完成部署創(chuàng)建和奮發(fā)產(chǎn)品版本并安裝到他們的工作場所配置和變更管理此支持工作流管理對系統(tǒng)的變更項目管理此支持工作流管理系統(tǒng)開發(fā)環(huán)境此工作流用于提供軟件開發(fā)團隊可用的合適的軟件工具第43頁，共82頁。Rational統(tǒng)一過程RUP的實踐視角：反復(fù)的開發(fā)軟件：根

24、據(jù)客戶的輕重緩急來規(guī)劃系統(tǒng)的增量，在開發(fā)過程中先開發(fā)和交付最高優(yōu)先權(quán)的系統(tǒng)特征管理需求：明確的記錄客戶的需求并跟蹤這些需求的變更。在接受之前分析系統(tǒng)的變更所帶來的影響使用基于組件的體系結(jié)構(gòu)：將系統(tǒng)體系結(jié)構(gòu)設(shè)計成組件式可視化模型軟件：使用圖形化UML模型來表現(xiàn)軟件的靜態(tài)和動態(tài)視圖驗證軟件質(zhì)量：確保軟件滿足了機構(gòu)質(zhì)量標準控制對軟件的變更：使用變更管理軟件及配置管理過程和工具來管理軟件的變更第44頁，共82頁。Rational統(tǒng)一過程RUP并不適合于所有的開發(fā)類型，但是他卻是代表了新的一代的一般過程。最重要的創(chuàng)新在于對階段的分解和工作流，以及將軟件部署到用戶環(huán)境視為過程的一部分。階段是動態(tài)的而且是有

25、目標的。工作流是靜態(tài)的，且是不與單個階段相關(guān)的技術(shù)活動，但是可以在整個開發(fā)過程中使用，以便達到每個階段的目標第45頁，共82頁。通常描述的過程活動及產(chǎn)出文檔需求分析概要設(shè)計詳細設(shè)計編碼集成測試確認測試撰寫用戶文檔用戶培訓打包和交付第46頁，共82頁。需求分析(1/3)任務(wù)進行需求調(diào)查，定義軟件的用戶需求，撰寫軟件需求規(guī)格說明書(SRS)根據(jù)SRS，撰寫軟件確認測試計劃評審SRS和軟件確認測試計劃輸入用戶的初步需求描述輸出軟件需求規(guī)格說明書軟件確認測試計劃第47頁，共82頁。需求分析和軟件定義(2/3)實施根據(jù)用戶需求描述，分析和定義軟件系統(tǒng)的需求，按照軟件需求規(guī)格說明書編寫指南編寫軟件需求規(guī)格

26、說明書(SRS)根據(jù)SRS，制定軟件確認測試計劃，按照軟件確認測試計劃編寫指南編寫軟件確認測試計劃文檔對需求分析的結(jié)果(軟件需求規(guī)格說明書和軟件確認測試計劃)進行評審第48頁，共82頁。需求分析和軟件定義(3/3)說明用戶需求描述了用戶對目標軟件系統(tǒng)的期望和要求(包括功能、性能和設(shè)計約束等)，因此，需求分析只需關(guān)心要解決的問題，而無需關(guān)心這些問題的解決方案軟件確認測試計劃應(yīng)該包含軟件需求規(guī)格說明書中所定義的所有需求的測試內(nèi)容第49頁，共82頁。概要設(shè)計(1/3)任務(wù)根據(jù)SRS，進行軟件的總體結(jié)構(gòu)設(shè)計、接口設(shè)計和數(shù)據(jù)設(shè)計，撰寫軟件總體結(jié)構(gòu)設(shè)計、接口設(shè)計和數(shù)據(jù)設(shè)計規(guī)格說明書根據(jù)軟件的概要設(shè)計，制定

27、軟件集成測試計劃輸入軟件需求規(guī)格說明書SRS輸出軟件總體結(jié)構(gòu)設(shè)計規(guī)格說明書軟件數(shù)據(jù)設(shè)計規(guī)格說明書軟件接口設(shè)計規(guī)格說明書軟件集成測試計劃第50頁，共82頁。概要設(shè)計(2/3)實施根據(jù)SRS來進行軟件設(shè)計按照軟件總體結(jié)構(gòu)設(shè)計規(guī)格說明書編寫指南編寫軟件總體結(jié)構(gòu)設(shè)計文檔按照軟件數(shù)據(jù)設(shè)計規(guī)格說明書編寫指南編寫軟件數(shù)據(jù)設(shè)計文檔按照軟件接口設(shè)計規(guī)格說明書編寫指南編寫軟件接口設(shè)計文檔按照軟件集成測試計劃編寫指南編寫軟件集成測試計劃文檔第51頁，共82頁。概要設(shè)計(3/3)說明概要設(shè)計要給出滿足用戶需求的軟件解決方案，主要是指軟件的總體結(jié)構(gòu)、接口設(shè)計和數(shù)據(jù)設(shè)計，不涉及具體模塊的內(nèi)部細節(jié)第52頁，共82頁。詳細設(shè)

28、計(1/3)任務(wù)進行軟件的詳細設(shè)計，撰寫軟件詳細設(shè)計規(guī)格說明書根據(jù)軟件的詳細設(shè)計，制定軟件單元測試計劃輸入軟件需求規(guī)格說明書SRS軟件總體設(shè)計規(guī)格說明書軟件接口設(shè)計規(guī)格說明書軟件數(shù)據(jù)設(shè)計規(guī)格說明書第53頁，共82頁。詳細設(shè)計(2/3)實施根據(jù)SRS和軟件總體結(jié)構(gòu)、接口和數(shù)據(jù)設(shè)計規(guī)格說明書，進行軟件的詳細設(shè)計，根據(jù)軟件詳細設(shè)計規(guī)格說明書編寫指南撰寫軟件詳細設(shè)計文檔根據(jù)每個模塊的內(nèi)部實現(xiàn)細節(jié)的設(shè)計，以及軟件單元測試計劃編寫指南編寫軟件單元測試計劃文檔輸出軟件詳細設(shè)計規(guī)格說明書軟件單元測試計劃第54頁，共82頁。詳細設(shè)計(3/3)說明詳細設(shè)計主要根據(jù)軟件需求規(guī)格說明書，在軟件總體結(jié)構(gòu)設(shè)計、接口設(shè)計和

29、數(shù)據(jù)設(shè)計的基礎(chǔ)上，涉及軟件解決方案的詳細細節(jié)，尤其是模塊的實現(xiàn)算法和思想第55頁，共82頁。編碼(1/2)任務(wù)編寫程序進行單元測試，撰寫單元測試報告輸入軟件總體結(jié)構(gòu)設(shè)計規(guī)格說明書軟件數(shù)據(jù)設(shè)計規(guī)格說明書軟件接口設(shè)計規(guī)格說明書軟件詳細設(shè)計規(guī)格說明書單元測試計劃第56頁，共82頁。編碼(2/2)實施根據(jù)軟件總體結(jié)構(gòu)設(shè)計規(guī)格說明書、軟件數(shù)據(jù)設(shè)計規(guī)格說明書、軟件接口設(shè)計規(guī)格說明書、軟件詳細設(shè)計規(guī)格說明書進行編碼根據(jù)單元測試計劃對各個模塊進行單元測試輸出經(jīng)過單元測試的軟件模塊源程序單元測試報告第57頁，共82頁。集成測試(1/2)任務(wù)集成各個軟件模塊進行測試輸入軟件模塊的程序代碼軟件總體結(jié)構(gòu)設(shè)計規(guī)格說明書

30、軟件數(shù)據(jù)設(shè)計規(guī)格說明書軟件接口設(shè)計規(guī)格說明書軟件集成測試計劃第58頁，共82頁。集成測試(2/2)實施根據(jù)軟件總體結(jié)構(gòu)設(shè)計規(guī)格說明書、軟件接口設(shè)計規(guī)格說明書、軟件數(shù)據(jù)設(shè)計規(guī)格說明書和軟件集成測試計劃，逐步組裝模塊進行軟件的集成測試，撰寫集成測試報告輸出可運行的、經(jīng)過集成測試的目標軟件系統(tǒng)集成測試報告第59頁，共82頁。確認測試(1/2)任務(wù)根據(jù)軟件需求規(guī)格說明書和軟件確認測試計劃進行確認測試，撰寫確認測試報告輸入軟件需求規(guī)格說明書確認測試計劃第60頁，共82頁。確認測試(2/2)實施根據(jù)軟件需求規(guī)格說明書和確認測試計劃，對軟件進行確認測試，撰寫確認測試報告輸出可運行的、經(jīng)過確認測試的目標軟件系

31、統(tǒng)確認測試報告說明確認測試由用戶進行測試第61頁，共82頁。撰寫用戶文檔(1/2)任務(wù)撰寫用戶文檔輸入軟件需求規(guī)格說明書軟件總體結(jié)構(gòu)、接口設(shè)計和數(shù)據(jù)設(shè)計規(guī)格說明書可運行的目標軟件系統(tǒng)第62頁，共82頁。撰寫用戶文檔(2/2)實施根據(jù)用戶軟件需求規(guī)格說明書，軟件總體結(jié)構(gòu)、接口設(shè)計和數(shù)據(jù)設(shè)計規(guī)格說明書撰寫用戶文檔用戶文檔一般包括：用戶使用手冊，安裝手冊，軟件開發(fā)手冊等等輸出用戶手冊安裝手冊開發(fā)指南第63頁，共82頁。用戶培訓(1/2)任務(wù)對用戶進行培訓輸入軟件需求規(guī)格說明書用戶使用手冊、安裝手冊、開發(fā)手冊可運行的目標軟件系統(tǒng)第64頁，共82頁。用戶培訓(2/2)實施根據(jù)可運行的目標軟件系統(tǒng)、用戶使

32、用手冊，安裝手冊，開發(fā)手冊對用戶進行培訓輸出無第65頁，共82頁。打包交付(1/2)任務(wù)對軟件進行打包，并交付用戶使用輸入可執(zhí)行的目標軟件系統(tǒng)各種要交付的文檔和資料，包括電子版和打印版第66頁，共82頁。打包交付(2/2)實施制作安裝軟件安裝并配置目標軟件系統(tǒng)交付安裝軟件、文檔和資料輸出安裝軟件交付給用戶的文檔和資料第67頁，共82頁。RUP補充介紹RUP（Rational Unified Process）是軟件工程化過程RUP是一個流程工具平臺，一個流程框架RUP猶如一個菜譜，通過菜譜做成各種菜系RUP是一個定制流程的工具平臺第68頁，共82頁。RUP核心第69頁，共82頁。RUP的組織方式

33、時間軸階段和迭代內(nèi)容軸工作流程第70頁，共82頁。RUP通過時間軸的組織先啟(Inception):定義項目目標和范圍精化(Elaboration)：計劃項目、指定特性、構(gòu)架基線化構(gòu)建(Construction):構(gòu)建產(chǎn)品產(chǎn)品化(Transition):將產(chǎn)品發(fā)布到用戶社區(qū)第71頁，共82頁。RUP的工作流程業(yè)務(wù)建模需求分析設(shè)計實施測試部署配置與變更管理項目管理環(huán)境第72頁，共82頁。相關(guān)活動組迭代過程第73頁，共82頁。RUP核心概念第74頁，共82頁。參考資料RUP 學堂 /developerworks/cn/rational/theme/rational-rup/rup.html揭開RUP的神秘面紗/developerworks/cn/onlinecourse/ratio