軟件工程概述2

第一章軟件工程概論

軟件發(fā)展史軟件概念、特點和分類（補充）軟件危機軟件工程概念和基本研究內(nèi)容軟件生存周期和模型其他軟件開發(fā)過程模型五、軟件生存周期和模型（一）瀑布模型及其特點(1)階段間具有順序性和依賴性第一，必須等前—階段的工作完成之后，才能開始后一階段的工作；第二，前一階段的輸出文檔就是后一階段的輸入文檔，因此，只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結(jié)果。（一）瀑布模型及其特點(2)推遲實現(xiàn)的觀點

瀑布模型在編碼之前設(shè)置了系統(tǒng)分析與系統(tǒng)設(shè)計的各個階段，分析與設(shè)計階段的基本任務(wù)規(guī)定，在這兩個階段主要考慮目標系統(tǒng)的邏輯模型，不涉及軟件的物理實現(xiàn)。清楚地區(qū)分邏輯設(shè)計與物理設(shè)計，盡可能推遲程序的物理實現(xiàn)，是按照瀑布模型開發(fā)軟件的一條重要的指導(dǎo)思想。(3)質(zhì)量保證的觀點第一，每個階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務(wù)。完整、準確的合格文檔不僅是軟件開發(fā)時期各類人員之間相互通信的媒介，也是運行時期對軟件進行維護的重要依據(jù)。第二，每個階段結(jié)束前都要對所完成的文檔進行評審，以便盡早發(fā)現(xiàn)問題，改正錯誤。事實上，越是早期階段犯下的錯誤，暴露出來的時間就越晚，排除故障改正錯誤所需付出的代價也越高。因此，及時審查，是保證軟件質(zhì)量，降低軟件成本的重要措施。瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動的模型。瀑布模型各階段主要任務(wù)劃分（補充）1問題定義問題定義階段必須回答的關(guān)鍵問題是：“要解決的問題是什么?”主要文檔：《系統(tǒng)目標與范圍的說明》2可行性研究對于上一個階段所確定的問題有行得通的解決辦法嗎?主要文檔：《可行性論證報告》、《項目實施計劃》、《系統(tǒng)流程圖》3需求分析這個階段的任務(wù)仍然不是具體地解決問題，而是準確地確定“為了解決這個問題目標系統(tǒng)必須做什么”，主要是確定目標系統(tǒng)必須具備哪些功能。這個階段的一項重要任務(wù)是用正式文檔準確地記錄對目標系統(tǒng)的需求，產(chǎn)生規(guī)格說明書。主要文檔：《需求說明書》、《數(shù)據(jù)流圖》、《數(shù)據(jù)字典》、《加工說明》等。4總體設(shè)計這個階段必須回答的關(guān)鍵問題是：“概括地說，應(yīng)該怎樣實現(xiàn)目標系統(tǒng)”。應(yīng)設(shè)計出低成本、中等成本、高成本3種方案，推薦最佳方案。主要文檔：《軟件結(jié)構(gòu)圖》、《層次圖》5詳細設(shè)計這個階段的關(guān)鍵問題是“應(yīng)該怎樣具體實現(xiàn)這個目標系統(tǒng)?！痹O(shè)計每個模塊，確定實現(xiàn)模塊功能所需要的算法和數(shù)據(jù)結(jié)構(gòu)。主要文檔：《模塊過程性描述》、《偽代碼》、《程序流程圖》等6編碼和單元測試這個階段的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護的程序模塊。主要文檔：《程序清單》7綜合測試這個階段的關(guān)鍵任務(wù)是通過各種類型的測試使軟件達到預(yù)定的要求。包括：集成測試，據(jù)設(shè)計的軟件結(jié)構(gòu)，把經(jīng)過單元檢驗的模塊按某中選定的策略結(jié)合起來，在裝配過程中對程序進行必要的測試。驗收測試，按照規(guī)格說明書的規(guī)定，由用戶對目標系統(tǒng)進行驗收。主要文檔：《測試報告》8軟件維護改正性維護：診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯誤適應(yīng)性維護：修改軟件以適應(yīng)環(huán)境的變化完善性維護：根據(jù)用戶的要求改進或擴充軟件使它更完善預(yù)防性維護：修改軟件為將來的維護活動預(yù)先做準備主要文檔：填寫更改相關(guān)文檔五、軟件生存周期和模型（二）快速原型模型特點：1。快速建立起來的可以在計算機上運行的程序，能完成的功能往往是最終產(chǎn)品的一個子集。2。快速原型模型的特點是不帶反饋環(huán)，基本上按線性順序開發(fā)。原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗證，據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求，不會因為規(guī)格說明文檔的錯誤而進行較大的返工。開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西，在設(shè)計編碼階段發(fā)生錯誤的可能性比較小，自然減少了反饋。五、軟件生存周期和模型（三）增量模型特點：又稱漸增模型。使用增量模型開發(fā)軟件時，把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計、編碼和測試。每個構(gòu)件由多個相互作用的模塊構(gòu)成，能完成特定的功能。第一個增量構(gòu)件往往實現(xiàn)軟件的基本需求，提供最核心的功能。分解時唯一必須準守的約束條件是，當把新構(gòu)件集成到現(xiàn)有軟件中去時，所形成的產(chǎn)品必須是可測試的。優(yōu)點：1、能在較短的時間內(nèi)向用戶提交可完成部分功能的產(chǎn)品。2、逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學(xué)習(xí)和適應(yīng)新產(chǎn)品，減少一個全新的軟件可能給客戶帶來的沖擊。困難：1、在把每個新的增量構(gòu)件集成到現(xiàn)有的軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)的產(chǎn)品2、軟件體系結(jié)構(gòu)必須是開放的3、本身具有矛盾性，一方面要求開發(fā)人員把軟件看作一個整體，另一方面要求開發(fā)人員把軟件看作構(gòu)件序列，且構(gòu)件間彼此獨立五、軟件生存周期和模型（四）螺旋模型螺旋模型的基本思想是：使用原型及其他方法來盡量降低風(fēng)險。1、確定階段目標，為完成階段目標選擇方案，設(shè)定這些方案的約束條件。2、用建造原型的方法來排除上述方案中潛在的風(fēng)險。3、用瀑布模型開發(fā)。4、評價該階段工作，計劃下階段工作。優(yōu)點：1、軟件重用2、測試量減少3、維護是模型的另一個周期4、螺旋模型主要是用于內(nèi)部開發(fā)的大規(guī)模軟件項目，它是風(fēng)險驅(qū)動的。圖1.8完整的螺旋模型五、軟件生存周期和模型（五）噴泉模型

“噴泉”體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。圖中代表不同階段的圓圈相互重疊，表明兩個活動之間存在交迭，而且保證了各項開發(fā)活動之間的無縫過段。

六、其他軟件開發(fā)過程模型（一）Rational統(tǒng)一過程

RationalUnifiedProcess是軟件工程的過程。它提供了在開發(fā)組織中分派任務(wù)和責任的紀律化方法。它的目標是在可預(yù)見的日程和預(yù)算前提下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品。RationalUnifiedProcess是Rational公司開發(fā)和維護的過程產(chǎn)品。UML是良好溝通需求、體系結(jié)構(gòu)和設(shè)計的工業(yè)標準語言。UML由Rational軟件公司創(chuàng)建，現(xiàn)在由標準化對象管理機構(gòu)（OMG）維護。能對大部分開發(fā)過程提供自動化的工具支持。它們被用來創(chuàng)建和維護軟件開發(fā)過程（可視化建模、編程、測試等）的各種各樣的產(chǎn)物--特別是模型。6個最佳實踐的有效部署

迭代的開發(fā)軟件需求管理使用基于構(gòu)件的體系結(jié)構(gòu)可視化軟件建模驗證軟件質(zhì)量控制軟件變更

迭代的開發(fā)產(chǎn)品--面對當今的復(fù)雜的軟件系統(tǒng)，使用連續(xù)的開發(fā)方法：如首先定義整個問題，設(shè)計完整的解決方案，編制軟件并最終測試產(chǎn)品，是不可能的。需要一種能夠通過一系列細化，若干個漸進的反復(fù)過程而生成有效解決方案的迭代方法。RationalUnifiedProcess支持專注于處理生命周期中每個階段中最高風(fēng)險的迭代開發(fā)方法，極大地減少了項目的風(fēng)險性。迭代方法通過可驗證的方法來幫助減少風(fēng)險--經(jīng)常性的、可執(zhí)行版本使最終用戶不斷的介入和反饋。因為每個迭代過程以可執(zhí)行版本告終，開發(fā)團隊停留在產(chǎn)生結(jié)果上，頻繁的狀態(tài)檢查幫助確保項目能按時進行。迭代化方法同樣使得需求、特色、日程上戰(zhàn)略性的變化更為容易。需求管理--RationalUnifiedProcess描述了如何提取、組織和文檔化需要的功能和限制；跟蹤和文檔化折衷方案和決策；捕獲和進行商業(yè)需求交流。過程中用例和場景的使用被證明是捕獲功能性需求的卓越方法，并確保由它們來驅(qū)動設(shè)計、實現(xiàn)和軟件的測試，使最終系統(tǒng)更能滿足最終用戶的需要。它們給開發(fā)和發(fā)布系統(tǒng)提供了連續(xù)的和可跟蹤的線索。__基于構(gòu)件的體系結(jié)構(gòu)--該過程在全力以赴開發(fā)之前，關(guān)注于早期的開發(fā)和健壯可執(zhí)行體系結(jié)構(gòu)的基線。它描述了如何設(shè)計靈活的，可容納修改的，直觀便于理解的，并且促進有效軟件重用的彈性結(jié)構(gòu)。RationalUnifiedProcess支持基于構(gòu)件的軟件開發(fā)。構(gòu)件是實現(xiàn)清晰功能的模塊、子系統(tǒng)。RationalUnifiedProcess提供了使用新的及現(xiàn)有構(gòu)件定義體系結(jié)構(gòu)的系統(tǒng)化方法。它們被組裝為良好定義的結(jié)構(gòu)，或是特殊的、底層結(jié)構(gòu)如Internet、CORBA和COM等的工業(yè)級重用構(gòu)件?？梢暬浖?-開發(fā)過程顯示了對軟件如何可視化建模，捕獲體系結(jié)構(gòu)和構(gòu)件的構(gòu)架和行為。這允許你隱藏細節(jié)和使用"圖形構(gòu)件塊"來書寫代碼。可視化抽象幫助你溝通軟件的不同方面，觀察各元素如何配合在一起，確保構(gòu)件模塊一致于代碼，保持設(shè)計和實現(xiàn)的一致性，促進明確的溝通。Rational軟件公司創(chuàng)建的工業(yè)級標準UnifiedModelingLanguage(UML)是成功可視化軟件建模的基礎(chǔ)。驗證軟件質(zhì)量--拙劣的應(yīng)用程序性能和可靠性是戲劇性展示當今軟件可接受性的特點。從而，質(zhì)量應(yīng)該基于可靠性、功能性、應(yīng)用和系統(tǒng)性能根據(jù)需求來進行驗證。RationalUnifiedProcess幫助計劃、設(shè)計、實現(xiàn)、執(zhí)行和評估這些測試類型。質(zhì)量評估被內(nèi)建于過程、所有的活動，包括全體成員，使用客觀的度量和標準，并且不是事后型的或單獨小組進行的分離活動。控制軟件的變更--管理變更的能力--確定每個修改是可接受的，能被跟蹤的--在變更不可避免環(huán)境中是必須的。開發(fā)過程描述了如何控制、跟蹤和監(jiān)控修改以確保成功的迭代開發(fā)。它同時指導(dǎo)如何通過隔離修改和控制整個軟件產(chǎn)物（例如，模型、代碼、文檔等）的修改來為每個開發(fā)者建立安全的工作區(qū)。另外，它通過描述如何進行自動化集成和建立管理使小隊如同單個單元來工作。Rational統(tǒng)一過程過程簡介二維結(jié)構(gòu)

開發(fā)過程可以用二維結(jié)構(gòu)或沿著兩個坐標軸來表達：橫軸代表了制訂開發(fā)過程時的時間，體現(xiàn)了過程的動態(tài)結(jié)構(gòu)。它以術(shù)語周期（cycle）、階段(phase)、迭代（iteration）和里程碑(milestone)來表達。

縱軸表現(xiàn)了過程的靜態(tài)結(jié)構(gòu)：如何用術(shù)語活動（activity）、產(chǎn)物(artifact)、角色(worker)和工作流(workflow)來描述。9個核心的過程工作流核心工作流分為6個核心"工程"工作流商業(yè)建模工作流需求工作流分析和設(shè)計工作流實現(xiàn)工作流測試工作流分發(fā)工作流3個核心"支持"工作流項目管理工作流配置和變更控制工作流環(huán)境工作流（二）敏捷過程敏捷過程（agileprecess）是一種以人為核心、迭代、循序漸進的開發(fā)方法。它是由17個工程師為了解決日益龐大的開發(fā)團隊和繁瑣的開發(fā)過程、大量的文檔中解脫開發(fā)人員的工作量達成的一項共識。在敏捷過程中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。簡言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。

敏捷過程是全一個全新的新理論。他不同于原來的6Sigma，ISO9000和CMM。細心的人們可以發(fā)現(xiàn)，敏捷過程也借鑒了大量軟件工程中的方法。迭代與增量開發(fā)，這兩種在任何一本軟件工程教材中都會被提到的方法，在敏捷開發(fā)模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。

改善，而非創(chuàng)新。敏捷過程可理解為在原有軟件開發(fā)方法基礎(chǔ)上的整合——取其精華，去其糟粕。因此敏捷過程繼承了不少原有方法的優(yōu)勢?！霸诿艚蒈浖_發(fā)的過程中，我們每兩周都會得到一個可以工作的軟件，”Fowler介紹，“這種非常短的循環(huán)，使終端客戶可以及時、快速地看到他們花錢構(gòu)建的軟件是一個什么樣的結(jié)果。”

也許是因為時間關(guān)系，F(xiàn)owler只說出了這些優(yōu)勢中的一部分。允許開發(fā)過程中的需求變化、通過早期迭代可以較早發(fā)現(xiàn)風(fēng)險、使代碼重用變得可行、減少項目返工……借鑒了眾多先進方法和豐富經(jīng)驗，擁有的眾多優(yōu)勢使得敏捷開發(fā)看來已經(jīng)成為解決軟件危機的標準答案。敏捷過程的價值觀個體和交互

勝過

過程和工具可以工作的軟件

勝過

面面俱到的文檔客戶合作

勝過

合同談判響應(yīng)變化

勝過

循環(huán)計劃

鼓勵和側(cè)重左側(cè)的內(nèi)容，不是完全的支持。她強調(diào)人的作用，希望在開發(fā)團隊中有優(yōu)秀的開發(fā)人員。

遵循的原則

我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。在團隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。工作的軟件是首要的進度度量標準。敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。簡單是最根本的。最好的構(gòu)架、需求和設(shè)計出于自組織團隊。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。（三）極限編程ExtremeProgramming（極限編程，簡稱XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期與WardCunningham共事時，就一直共同探索著新的軟件開發(fā)方法，希望能使軟件開發(fā)更加簡單而有效。Kent仔細地觀察和分析了各種簡化軟件開發(fā)的前提條件、可能行以及面臨的困難。1996年三月，Kent終于在為DaimlerChrysler所做的一個項目中引入了新的軟件開發(fā)觀念——XP。XP是一個輕量級的、靈巧的軟件開發(fā)方法；同時它也是一個非常嚴謹和周密的方法。它的基礎(chǔ)和價值觀是交流、樸素、反饋和勇氣；即任何一個軟件項目都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇于實事求是。XP是一種近螺旋式的開發(fā)方法，它將復(fù)雜的開發(fā)過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發(fā)人員和客戶可以非常清楚開發(fā)進度、變化、待解決的問題和潛在的困難等，并根據(jù)實際情況及時地調(diào)整開發(fā)過程。為什么稱為“Extreme”（極限）

“Extreme”（極限）是指，對比傳統(tǒng)的項目開發(fā)方式，XP強調(diào)把它列出的每個方法和思想做到極限、做到最好；其它XP所不提倡的，則一概忽略（如開發(fā)前期的整體設(shè)計等）。一個嚴格實施XP的項目，其開發(fā)過程應(yīng)該是平穩(wěn)的、高效的和快速的，能夠做到一周40小時工作制而不拖延項目進度。

XP的軟件開發(fā)是什么樣

1極限的工作環(huán)境

為了在軟件開發(fā)過程中最大程度地實現(xiàn)和滿足客戶和開發(fā)人員的基本權(quán)利和義務(wù)，XP要求把工作環(huán)境也做得最好。每個參加項目開發(fā)的人都將擔任一個角色（項目經(jīng)理、項目監(jiān)督人等等）并履行相應(yīng)的權(quán)利和義務(wù)。所有的人都在同一個開放的開發(fā)環(huán)境中工作，最好是所有人在同一個大房子中工作，還有茶點供應(yīng)；每周40小時，不提倡加班；每天早晨，所有人一起站著開個短會；墻上有一些大白板，所有的Story卡、CRC卡等都貼在上面，討論問題的時候可以在上面寫寫畫畫；下班后大家可以一起玩電腦游戲……。2極限的需求

客戶應(yīng)該是項目開發(fā)隊伍中的一員，而不是和開發(fā)人員分開的；因為從項目的計劃到最后驗收，客戶一直起著很重要的作用。開發(fā)人員和客戶一起，把各種需求變成一個個小的需求模塊（UserStory），例如“計算年級的總?cè)藬?shù)，就是把該年級所有班的人數(shù)累加。”；這些模塊又會根據(jù)實際情況被組合在一起或者被分解成更小的模塊；它們都被記錄在一些小卡片（StoryCard）上，之后分別被程序員們在各個小的周期開發(fā)中（Iteration，通常不超過3個星期）實現(xiàn)；客戶根據(jù)每個模塊的商業(yè)價值來指定它們的優(yōu)先級；開發(fā)人員要做的是確定每個需求模塊的開發(fā)風(fēng)險，風(fēng)險高的（通常是因為缺乏類似的經(jīng)驗）需求模塊將被優(yōu)先研究、探索和開發(fā)；經(jīng)過開發(fā)人員和客戶分別從不同的角度評估每個模塊后，它們被安排在不同的開發(fā)周期里，客戶將得到一個盡可能準確的開發(fā)計劃；客戶為每個需求模塊指定驗收測試（功能測試）。每發(fā)布一次開發(fā)的軟件（經(jīng)過一個開發(fā)周期），用戶都能得到一個可以開始使用的系統(tǒng)，這個系統(tǒng)全面實現(xiàn)了相應(yīng)的計劃中的所有需求。而在一些傳統(tǒng)的開發(fā)模式中，無論什么功能，用戶都要等到所有開發(fā)完成后才能開始使用。3極限的設(shè)計

從具體開