【教學課件】軟件工程概述

1、軟件工程概述第1頁，共83頁。課程內(nèi)容軟件工程概述 SE面向?qū)ο筌浖こ?OOSE面向?qū)ο蠓治雠c設計 UML面向?qū)ο蟪绦蛟O計 C（選擇）設計模式初步：Design Patterns （選擇）SOA： Service Oriented Architecture （選擇） AOP： Aspect-Oriented Software Development 項目設計實踐： Web Application Development using UML Web2.0 PM第2頁，共83頁。Contents軟件危機 (1)軟件危機 (1.2)軟件工程 (2)軟件生命周期(3)軟件過程(4)軟件工程的目標第3

2、頁，共83頁。Contents1 軟件危機 第4頁，共83頁。第5頁，共83頁。軟件危機表現(xiàn)成本進度估計不準確變動頻繁的軟件需求軟件質(zhì)量不可靠軟件維護困難沒有適當?shù)奈臋n資料軟件在系統(tǒng)總成本比例上升軟件發(fā)展速度趕不上硬件第6頁，共83頁。軟件危機原因軟件本身特點：邏輯不可預見軟件開發(fā)和維護的方法不正確第7頁，共83頁。消除軟件危機途徑技術上：方法、工具管理上：組織、經(jīng)驗第8頁，共83頁。Contents軟件危機 (1.2)軟件工程 (1.2)第9頁，共83頁。軟件工程的定義Boehm：運用現(xiàn)代科學技術知識來設計并構造計算機程序及為開發(fā)、運行和維護這些程序所必需的相關文件資料IEEE： 軟件工程是

3、開發(fā)、運行、維護和修復軟件的系統(tǒng)方法Fritz Bauer：建立并使用完善的工程化原則，以較經(jīng)濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法第10頁，共83頁。軟件工程三要素：方法、工具和過程軟件工程方法為軟件開發(fā)提供了 “如何做” 的技術軟件工具為軟件工程方法提供了自動的或半自動的軟件支撐環(huán)境第11頁，共83頁。軟件工程過程定義了: 方法使用的順序 要求交付的文檔資料 為保證質(zhì)量和適應變化所需要的管理 軟件開發(fā)各個階段完成的里程碑第12頁，共83頁。軟件工程七條基本原理1 用分階段的生命周期計劃嚴格管理 這一條是吸取前人的教訓而提出來的。統(tǒng)計表明，50%以上的失敗項目是由于計劃不周

4、而造成的。在軟件開發(fā)與維護的漫長生命周期中，需要完成許多性質(zhì)各異的工作。 這條原理意味著，應該把軟件生命周期分成若干階段，并相應制定出切實可行的計劃，然后嚴格按照計劃對軟件的開發(fā)和維護進行管理。 Boehm 認為，在整個軟件生命周期中應指定并嚴格執(zhí)行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產(chǎn)品控制計劃、驗證計劃、運行維護計劃。第13頁，共83頁。軟件工程七條基本原理2 堅持進行階段評審 統(tǒng)計結果顯示： 大部分錯誤是在編碼之前造成的，大約占63%; 錯誤發(fā)現(xiàn)的越晚，改正它要付出的代價就越大，要差2到3個數(shù)量級。 因此，軟件的質(zhì)量保證工作不能等到編碼結束之后再進行，應堅持進行嚴格的階段評

5、審，以便盡早發(fā)現(xiàn)錯誤。第14頁，共83頁。軟件工程七條基本原理3 實行嚴格的產(chǎn)品控制 開發(fā)人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要采用科學的產(chǎn)品控制技術來順應這種要求。也就是要采用變動控制，又叫基準配置管理。 當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟件的一致性。第15頁，共83頁。軟件工程七條基本原理4 采納現(xiàn)代程序設計技術 從六、七時年代的結構化軟件開發(fā)技術，到最近的面向?qū)ο蠹夹g，從第一、第二代語言，到第四代語言，人們已經(jīng)充分認識到：采用先進的技術即可以提高軟件開發(fā)的效率，又可以減少軟件維護的成本。第16頁，共83頁。

6、軟件工程七條基本原理5 結果應能清楚地審查 軟件是一種看不見、摸不著的邏輯產(chǎn)品。軟件開發(fā)小組的工作進展情況可見性差，難于評價和管理。為更好地進行管理，應根據(jù)軟件開發(fā)的總目標及完成期限， 盡量明確地規(guī)定開發(fā)小組的責任和產(chǎn)品標準，從而使所得到的標準能清楚地審查。 第17頁，共83頁。軟件工程七條基本原理6 開發(fā)小組的人員應少而精 開發(fā)人員的素質(zhì)和數(shù)量是影響軟件質(zhì)量和開發(fā)效率的重要因素，應該少而精。 這一條基于兩點原因：高素質(zhì)開發(fā)人員的效率比低素質(zhì)開發(fā)人員的效率要高幾倍到幾十倍，開發(fā)工作中犯的錯誤也要少的多； 當開發(fā)小組為N人時，可能的通訊信道為N(N-1)/2, 可見隨著人數(shù)N的增大，通訊開銷將急

7、劇增大。第18頁，共83頁。軟件工程七條基本原理7 承認不斷改進軟件工程實踐的必要性 遵從上述六條基本原理，就能夠較好地實現(xiàn)軟件的工程化生產(chǎn)。但是，它們只是對現(xiàn)有的經(jīng)驗的總結和歸納，并不能保證趕上技術不斷前進發(fā)展的步伐。 因此，Boehm提出應把承認不斷改進軟件工程實踐的必要性作為軟件工程的第七條原理。根據(jù)這條原理，不僅要積極采納新的軟件開發(fā)技術，還要注意不斷總結經(jīng)驗，收集進度和消耗等數(shù)據(jù)，進行出錯類型和問題報告統(tǒng)計。這些數(shù)據(jù)既可以用來評估新的 軟件技術的效果，也可以用來指明必須著重注意的問題和應該優(yōu)先進行研究的工具和技術。 第19頁，共83頁。軟件工程方法學傳統(tǒng)方法學（結構化軟件開發(fā)）可行性

8、分析，需求分析，總體設計，詳細設計，編碼，測試，維護軟件項目管理面向?qū)ο蠓椒▽W（面向?qū)ο筌浖_發(fā)） 面向?qū)ο蠓治鯫OA，面向?qū)ο笤O計OOD，面向?qū)ο髮崿F(xiàn)OOP，面向?qū)ο鬁y試OOT，面向?qū)ο缶S護OOM面向?qū)ο蟮能浖椖抗芾淼?0頁，共83頁。Contents軟件 (1.1)軟件危機 (1.2)軟件工程 (1.2)軟件生命周期(1.3)軟件開發(fā)模型(1.4)軟件工程的目標第21頁，共83頁。軟件生命周期 life cycle軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計算機軟件的生命周期三個時期：定義、開發(fā)、維護軟件生存期的七個步驟，即可行性研究、需求分析、總體設計、詳細設計、程

9、序編碼、單元測試和集成測試、維護第22頁，共83頁。Contents軟件 (1.1)軟件危機 (1.2)軟件工程 (1.2)軟件生命周期(1.3)軟件過程(1.4)軟件工程的目標第23頁，共83頁。軟件生存期模型軟件生存期模型是跨越整個生存期的系統(tǒng)開發(fā)、運作和維護所實施的全部過程、活動和任務的結構框架 瀑布模型 原型模型 螺旋模型 第24頁，共83頁?！癢hatHowChange”概括了軟件開發(fā)活動（定義、開發(fā)、維護）中的主要特征。傳統(tǒng)的軟件開發(fā)模型主要有瀑布模型與快速原型模型。第25頁，共83頁。瀑布模型需求定義系統(tǒng)與軟件設計集成與系統(tǒng)測試實現(xiàn)與單元測試運行與維護各項活動按自上而下，相互銜接

10、的固定次序，如同瀑布逐級下落。每項活動均處于一個質(zhì)量環(huán)（輸入-處理-輸出-評審）中。第26頁，共83頁。瀑布模型 第27頁，共83頁。第28頁，共83頁。制定計劃確定要開發(fā)軟件系統(tǒng)的總目標；給出功能、性能、可靠性以及接口等方面的要求；完成該軟件任務的可行性研究；估計可利用的資源 (硬件，軟件，人力等)、成本、效益、開發(fā)進度；制定出完成開發(fā)任務的實施計劃，連同可行性研究報告，提交管理部門審查。第29頁，共83頁。需求分析和定義對用戶提出的要求進行分析并給出詳細的定義；編寫軟件需求說明書或系統(tǒng)功能說明書及初步的系統(tǒng)用戶手冊；提交管理機構評審。第30頁，共83頁。軟件設計概要設計 把各項需求轉(zhuǎn)換成軟

11、件的體系結構。結構中每一組成部分都是意義明確的模塊，每個模塊都和某些需求相對應；詳細設計 對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎；編寫設計說明書，提交評審。第31頁，共83頁。程序編寫把軟件設計轉(zhuǎn)換成計算機可以接受的程序代碼，即寫成以某一種特定程序設計語言表示的“源程序清單”；寫出的程序應當是結構良好、清晰易讀的，且與設計相一致的。第32頁，共83頁。軟件測試單元測試，查找各模塊在功能和結構上存在的問題并加以糾正；組裝測試，將已測試過的模塊按一定順序組裝起來；按規(guī)定的各項需求，逐項進行有效性測試，決定已開發(fā)的軟件是否合格，能否交付用戶使用。第33頁，共83頁。運行維護糾正性

12、維護 運行中發(fā)現(xiàn)了軟件中的錯誤需要 修正；適應性維護 為了適應變化了的軟件工作環(huán)境，需做適當變更；完善性維護 為了增強軟件的功能需做變更。第34頁，共83頁。 按照傳統(tǒng)瀑布模型開發(fā)軟件的特點 1.階段間具有順序性和依賴性。 2.推遲實現(xiàn)的觀點。 3.每個階段必須完成規(guī)定的文檔;每個階段結束 前完成文檔審查,及早改正錯誤。第35頁，共83頁。傳統(tǒng)瀑布模型開發(fā)軟件帶來的問題： 過程基本不可迭代 需求在開始的不確定性 錯誤到最后才能發(fā)現(xiàn) 開發(fā)進程呈現(xiàn)塞阻狀態(tài)第36頁，共83頁。軟件生存期循環(huán)第37頁，共83頁。快速原型模型快速原型模型（Rapid Prototype Model）的主要做法是：首先建

13、立一個能夠反映用戶主要需求的原型，讓用戶實際看一看未來系統(tǒng)的概貌，以便判斷哪些功能是符合需要的，哪些方面還需要改進。快速原型系統(tǒng)的優(yōu)越性主要體現(xiàn)在：軟件開發(fā)人員向用戶提供一個“樣品”，用戶向開發(fā)人員迅速作出“反饋”。第38頁，共83頁?？焖僭湍Ｐ蛨D示用戶測試，運行原型建造修改/原型聽取用戶意見第39頁，共83頁。原型模型 原型產(chǎn)生步驟第40頁，共83頁。如何產(chǎn)生快速原型系統(tǒng)？原型系統(tǒng)僅包括未來系統(tǒng)的主要功能，以及系統(tǒng)的重要接口。為了盡快向用戶提供原型，開發(fā)原型系統(tǒng)時應盡量使用能縮短開發(fā)周期的語言和工具。把原型系統(tǒng)作為基礎，通過補充與修改獲得最終的實際系統(tǒng)。第41頁，共83頁?？焖僭湍Ｐ蛶?/p>

14、的問題：需要足夠的人力資源 用戶和設計都成為關鍵適用于MIS形式的系統(tǒng)第42頁，共83頁。 增量模型(遞增模型) 先完成一個系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加功能 (系統(tǒng)子集),如此遞增下去直至滿足全部系統(tǒng)需求。 系統(tǒng)的總體設計在初始子集設計階段就應作出設想。第43頁，共83頁。增量模型分析設計編碼測試分析設計編碼測試分析設計編碼測試分析設計編碼測試增量2增量3增量4增量1第1個增量的發(fā)布第2個增量的發(fā)布第3個增量的發(fā)布第4增量的發(fā)布要點：順序過程和原型過程相結合強調(diào)版本升級每個版本的開發(fā)遵循順序過程 第44頁，共83頁。增量模型把軟件產(chǎn)品分解成一系列的增量構件，在增量開發(fā)迭代中逐步加入。

15、 每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。增量開發(fā)方法的新演進版本叫做 “極限程序設計（eXtreme Programming）”。 定義基本需求將需求賦予增量構件設計系統(tǒng)體系結構開發(fā)增量構件確認增量構件集成增量構件確認系統(tǒng)第45頁，共83頁。螺旋模型結合瀑布模型與快速原型的基礎上增加了風險分析第46頁，共83頁。螺旋模型 螺旋模型沿著螺線旋轉(zhuǎn)，在四個象限上分別表達四個方面的活動，即：制定計劃 確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件；風險分析 分析所選方案，考慮如何識別和消除風險；實施工程 實施軟件開發(fā)客戶評估 評價開發(fā)，提出修正建議。第47頁，共83頁。螺旋模型

16、決定目標、方案和限制評價方案、識別風險、弱化風險開發(fā)、驗證、下一級產(chǎn)品計劃下一階段集成測試第48頁，共83頁。風險分析工程構造及發(fā)布用戶評估客戶交流計劃項目入口螺旋模型軸線與增量模型的區(qū)別：活動劃分不同更強調(diào)“計劃”、“風險分析”和“用戶評估”版本有更明確的目標 要點：相似于增量模型，是順序過程與原型過程的統(tǒng)一，強調(diào)版本和版本升級。 版本的明確目標：概念項目增量項目維護項目第49頁，共83頁。當前的軟件的價值動力源泉，世界不可或缺的一部分規(guī)模、復雜性、分布和重要性不斷擴張生產(chǎn)和維護越來越難熟悉的軟件開發(fā)方法收到限制第50頁，共83頁。軟件開發(fā)問題的癥狀對于最終用戶的需要理解得不夠精確對需求的改

17、變束手無策程序塊不兼容軟件不易維護或不易擴展對項目嚴重缺陷的發(fā)現(xiàn)較晚軟件質(zhì)量低劣軟件性能令人無法接受開發(fā)組的人員按各自的方式進行開發(fā)，如果有人改變可部分軟件，將很難進行重組一個不可靠的構造和發(fā)布過程第51頁，共83頁。失敗原因特別的需求管理模糊和不精確的交流脆弱的構架過度復雜未檢測出需求、設計和實現(xiàn)之間的不一致測試的不足對于項目狀況的評估過于主觀未解決存在的風險無法控制變化的產(chǎn)生和傳播自動控制不足第52頁，共83頁。最佳軟件開發(fā)實踐 Best Practices迭代地開發(fā)軟件 Develop Iteratively管理需求 Manage Requirements應用基于構件的構架 Use Co

18、mponent Architectures為軟件建立可視化的模型 Model Visually (UML) 不斷地驗證軟件質(zhì)量 Continuously Verify Quality控制軟件的變更 Manage Change第53頁，共83頁。Best Practices Reinforce Each Other: An ExampleValidates architectural decisions early onAddresses plexity of design/implementation incrementallyMeasures quality early and oftenE

19、volves baselines incrementallyEnsures users involved as requirements evolveBest PracticesDevelop IterativelyManage RequirementsUse Component ArchitecturesModel Visually (UML)Continuously Verify QualityManage Change 第54頁，共83頁。現(xiàn)在軟件產(chǎn)業(yè)界普遍認為，開發(fā)復雜軟件項目必須采用基于UML的、以構架為中心、用例驅(qū)動與風險驅(qū)動相結合的迭代式增量開發(fā)過程，他是世界公認的開發(fā)復雜軟件項

20、目的最好過程，已經(jīng)成為軟件界的“圣經(jīng)”。這一開發(fā)過程目前已經(jīng)穩(wěn)定、成熟。這就是： RUPRational Unified Process第55頁，共83頁。Rational Unified ProcessRUP Rational 統(tǒng)一過程是由Rational 軟件公司開發(fā)和營銷的一種軟件工程過程，是開發(fā)組織用以分配與管理任務和職責的一種規(guī)范化方法。這個過程的目的是在預定的進度和預算范圍內(nèi)，開發(fā)出滿足最終用戶需要的高質(zhì)量軟件。第56頁，共83頁。RUP Implements Best PracticesBest PracticesProcess Made Practical Develop It

21、erativelyManage RequirementsUse Component ArchitecturesModel Visually (UML)Continuously Verify QualityManage Change 第57頁，共83頁。軟件開發(fā)過程為開發(fā)小組的活動順序提供向?qū)г敿氄f明那些制品將被開發(fā)，以及什么時候開發(fā)指導每一個開發(fā)人員和整個開發(fā)組的工作為監(jiān)控和度量項目的產(chǎn)品和活動提供準則第58頁，共83頁。RUP將這些最佳實踐活動以一種適當?shù)男问浇Y合起來，從而適應了廣泛的項目和開發(fā)組織。第59頁，共83頁。RUP 是一個過程產(chǎn)品(process product)。Rationa

22、l (IBM) 軟件公司開發(fā)并維護著這個產(chǎn)品，并將其與Rational 軟件公司自己的一系列軟件開發(fā)工具集成。第60頁，共83頁。RUP 有自己的過程框架 (process framework), 這個框架可以被改造和擴展以適應采納此方法的組織。第61頁，共83頁。RUP 簡要歷史RUP 2000RUP 5.5RUP 5.0ROP 4.1ROP 4.0Rational 方法Objective 過程3.8200019991998199719961995實時ROOM業(yè)務工程配置和變更管理需求學院Booch 方法OMT UML 0.8SQA 過程UML 1.1數(shù)據(jù)工程UI 設計UML 1.2基于WE

23、B的開發(fā)UML1.3第62頁，共83頁。Rational Process WorkbenchMajor addition of contentMajor addition of tool mentorsImproved Process for independent testingRational Objectory Process 4.1 1997Rational Objectory Process 4.0 1996Rational Unified Process 5.0 1998Rational Unified Process 2000Rational Unified Process 20

24、01Rational Unified Process 5.5 1999Rational Unified Process 2002Rational Unified Process 2003Rational ApproachProject ManagementUML 1.3RealTimePerformance TestingBusiness ModelingConfiguration & Change MgtObjectory UI DesignData EngineeringUML 1.1OMTBoochUML 1.0Requirements Test ProcessTree browser upgraded for enhanced capabilities of creating customized My RUP treeIntroduction