SchoolofComputerEngineering，HuaihaiInstituteofTechnology軟件工程SoftwareEngineering淮海工學院計算機工程學院軟件工程系

樊寧計算機樓409TEL:85892393E-MAIL:angelafn66@163.com教材、參考書教材《軟件工程導論》，張海藩編著，清華大學出版社，2008.2《軟件工程導論學習輔導》，張海藩編著，清華大學出版社，2008.9參考書《軟件工程》，齊治昌譚慶平寧洪編著，高等教育出版社。《軟件工程自考應試指導》，劉海巖等編著，南京大學出版社。《軟件工程學實驗》，周蘇等編著，科學出版社，2005.4《軟件工程（英文版·第7版）》，IanSommerville,機械工業出版社，2004.11軟件工程課程說明軟件工程涉及：軟件生命周期(定義、設計、編碼、測試、發布、維護、淘汰)各階段的任務與內容軟件開發生產中有關工藝、模式、方法和工具的管理與技術問題軟件工程不涉及：程序語言的內容軟件編程軟件工程著力于解決軟件危機，即軟件經常不能按時按質地交付使用與其它軟件專業課的區別(1)立足于系統的整體。(2)講授系統分析、系統設計、測試及維護的理論和方法。(3)構筑一個軟件系統，實踐軟件開發全過程。

“軟件工程”課程教學與實踐的目標

轉變對軟件開發的認識：上升程序系統轉變思維定式：上升程序員系統工程師(系統分析員)

工程化訓練軟件工程與一般工程的差異軟件是邏輯產品而不是實物產品軟件的功能依賴于硬件和軟件的運行環境以及人們對它的操作軟件設計的復雜性軟件特征：功能的多樣性實現的多樣性能見度低軟件結構合理性差智力密集及知識產權保護內容安排第一章軟件工程學概述第二章可行性研究第三章需求分析第四章總體設計第五章詳細設計第六章實現第七章測試第八章維護第九章面向對象方法學引論第十章面向對象分析第十一章面向對象設計第十二章面向對象實現第十三章軟件項目管理第一章軟件工程學概述學習目標了解軟件產生軟件危機的原因和消除軟件危機的途徑；掌握軟件生命周期的概念與生命周期中各階段劃分；熟練掌握軟件過程模型或生命周期模型中典型的幾個模型——瀑布模型、原型模型、增量模型和螺旋模型、噴泉模型。了解目前比較流行的Rational統一過程、以極限編程為杰出代表的敏捷過程以及微軟過程。軟件工程發展的大事記1968.10NATO在德國南部的Gamisch會議上首次提出“軟件工程”1976IEEE成立標準委員會，“軟件工程”成為計算機科學專業的一門課程1987ISO/IEC成立標準委員會，“軟件工程”成為一個專業1993IEEECS/ACM成立聯合委員會1998美國德州首次發布“軟件工程師”執照;開始執行軟件工程知識體項目軟件是程序及其有關的文件與數據的集合。軟件的開發周期大大長于生產周期。軟件不像硬件一樣會磨損，但會過時。軟件很容易復制，因此具有復雜的知識產權問題。軟件是計算機系統產品的靈魂。隨著計算機系統的普及，軟件的復雜性與重要性與日俱增。軟件的特點軟件與硬件產品的故障率時間時間故障率使用初期磨損期理想曲線實際曲線修改硬件故障率分布曲線軟件故障率分布曲線軟件應用領域系統軟件操作系統編譯器編輯器應用軟件企業管理教育應用

實時軟件系統控制嵌入軟件

個人計算機軟件所有用于個人計算機的軟件科學與工程計算仿真計算機輔助設計人工智能專家系統人工神經網絡軟件應用于所有需要人類智能的領域類別參加人員數研制期限源程序行數微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～51～2年5k～50k大型5～202～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M 按軟件規模進行劃分：軟件的發展19501960197019801990第一代第二代第三代第四代批處理分發量小專用軟件多用戶實時性數據庫商品軟件C/S結構開發工具分布式系統嵌入式數據倉庫面向對象網絡環境合作開發分布計算并行計算軟件發展趨勢并行計算提高計算速度面向對象的軟件開發方法軟件框架（frameworks）用于處理大型軟件系統圖形接口越來越強人工智能和神經網絡技術高級程序設計語言專用工具軟件開放資源軟件(OpenSourceSoftware)第1章軟件工程學概述1.1

軟件危機軟件危機的出現：60年代中期到70年代中期，許多軟件最終成為不可維護的，這就是軟件危機.軟件工程就是為解決軟件危機問題而出現的。1968年，正式提出并使用“軟件工程”的概念。1.1.1什么是軟件危機？對軟件開發成本和進度的估計常常很不準確。用戶對為他們開發的軟件往往不滿意。軟件產品的質量往往靠不住。軟件常常是不可維護的。軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。包括：軟件通常沒有適當的文檔資料。軟件成本在計算機系統總成本中所占的比例逐年上升。軟件開發生產率提高的速度太慢。以上的這些問題能夠解決嗎?1.1.1什么是軟件危機？1.1.2產生軟件危機的原因不能用象硬件替換部件的方式修復軟件的故障軟件質量是一個牽涉到人的因素的問題軟件項目管理者往往沒有軟件開發的經驗軟件開發者往往沒有經過正規的工程訓練編程人員不愿意將軟件開發的藝術過程轉化為工程過程?Windows95有1000萬行代碼?

Windows2000有5000萬行代碼，3000多個工程師，幾百個小團隊。?Exchange2000和Windows2000開發人員結構Exchange2000Windows2000項目經理25人約250人開發人員140人約1700人測試人員350人約3200人例對軟件的常見誤解用戶的誤解開發人員的誤解管理者的誤解誤解先對軟件需求做一般的說明，以后再逐步明確就可以了.需求本身就是不斷變化的，軟件容易改變可以很快調整適應這種變化.現實軟件需求不明確是造成軟件開發費用增加和延時交貨的主要原因.軟件開發費用隨著開發階段的后移而大大增加.1x1.5-6x60-100x軟件開發費用設計階段開發階段維護階段用戶的誤解開發人員的誤解誤解一旦程序開發完畢工作正常，我的任務就完成了在程序工作之前，無法顧及軟件的質量問題.對于一個成功的項目來說，唯一能夠提供的就是可以工作的程序.現實一個軟件的50%-70%的工作量耗在軟件交付使用以后.對于某些錯誤,軟件審查比軟件測試更加有效.一個完整的軟件要包括程序、各種文件和各種數據.管理者的誤解誤解書上已經有各種軟件開發的標準，拿來用就是了.已經有足夠的軟件開發工具可供使用.一旦項目的程序員不夠可以隨時增加.現實書上是有各種軟件開發的標準，但不是過時就是不適用.軟件工具不是一拿來就能用的.“項目后期增加程序員會使項目的完成更加推后."--Brooks1.1.3解決軟件危機的途徑推廣使用在實踐中總結出來的開發軟件的成功的技術和方法。開發和使用更好的軟件工具。總之，為了解決軟件危機，既要有技術措施，又要有必要的組織管理措施。軟件工程正是從管理和技術兩方面研究更好地開發和維護計算機軟件地一門新興學科。1.2軟件工程IEEEstd610.12定義為:應用一種系統的、科學嚴格的、定量的方法來開發、運行和維護軟件;也就是說將工程的方法用于開發軟件.Boehm：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料.FritzBauer：建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法.1.2.1軟件工程的本質特性關注大型程序的構造中心問題是控制復雜性軟件經常變化開發效率非常重要和諧地合作是開發軟件的關鍵有效地支持它的用戶具有一種文化背景的人替另一種文化背景的人創造產品1.2.2軟件工程的基本原理用分階段的生命周期計劃嚴格管理堅持進行階段評審實行嚴格的產品控制采用現代程序設計技術結果應能清楚地審查開發小組成員應少而精承認不斷改進軟件工程實踐的必要性軟件工程包括技術和管理兩方面的內容，是技術與管理緊密結合所形成的工程學科。所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學(methodology)，也稱為范型(paradigm)。在軟件工程領域中，這兩個術語的含義基本相同。1.2.3軟件工程方法學1.2.3軟件工程方法學傳統方法學面向對象方法學1.3軟件生命周期生命周期方法學從時間角度對軟件開發和維護的復雜問題進行分解，把軟件生命的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然后逐步完成每個階段的任務。軟件定義問題定義：要解決的問題是什么？可行性研究：有可行的解決辦法嗎？需求分析：為解決問題，目標系統必須做什么？軟件設計總體設計：概括地說，應如何解決該問題？詳細設計：應怎樣具體實現這個系統？編碼和單元測試：編寫代碼，測試模塊綜合測試：通過測試，使軟件達到要求軟件維護軟件維護：通過各種維護活動使系統持久地滿足用戶地需要1.3軟件生命周期軟件開發的過程制定開發計劃軟件項目劃分軟件需求定義編寫軟件需求說明制定軟件測試計劃與方法數據結構與數據字典用戶文件軟件設計編寫軟件設計說明制定軟件測試計劃與方法數據結構與數據字典編碼與測試編碼軟件測試計劃與方法生產，銷售與維護用戶手冊維護服務軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。通常使用生命周期模型簡潔地描述軟件過程。1.4軟件過程1.4軟件開發模型軟件開發模型（又稱為軟件生命周期模型）—軟件項目開發和維護的總體過程思路的框架。它指出了軟件開發過程各階段之間的關系和順序，是軟件開發過程的概括。它為軟件開發過程提供原則和方法，并為軟件工程管理提供里程碑和進度表。因此，軟件開發模型也是軟件工程的重要內容。1.4軟件開發模型軟件開發模型的幾種類型：以軟件需求完全確定為基礎的瀑布模型；在開發初期僅給出基本需求的漸進式模型，如原型模型、螺旋模型、噴泉模型等；以形式化開發方法為基礎的變換模型、基于四代技術的模型；基于知識的智能模型等等。在實際開發時，應根據項目的特點和現有的條件選取合適的模型，也可以把幾種模型組合起來使用以便充分利用各模型的優點。1.4.1瀑布模型瀑布模型（waterfallmodel）是由W.Royce于1970年提出來的。又稱為軟件生存周期模型。瀑布模型嚴格按照軟件生存周期各個階段來進行開發，上一階段的輸出即是下一階段的輸入，并強調每一階段的嚴格性。它規定了各階段的任務和應提交的成果及文檔，每一階段的任務完成后，都必須對其階段性產品（主要是文檔）進行評審，通過后才能開始下一階段的工作。因此，它是一種以文檔作為驅動的模型。1.4.1瀑布模型問題定義可行性研究需求分析總體設計詳細設計編碼與單元測試綜合測試軟件維護特點：1.階段間具有順序性和依賴性2.推遲實現的觀點3.質量保證的觀點瀑布模型優點提供了軟件開發的基本框架，有利于大型軟件開發過程中人員的組織、管理，有利于軟件開發方法和工具的研究與使用，因此，在軟件工程中占有重要的地位。瀑布模型缺點1）在軟件開發的初期階段就要求做出正確、全面、完整的需求分析對許多應用軟件來說是極其困難的。2）在需求分析階段，當需求確定后，無法及時驗證需求是否正確、完整。3）作為整體開發的瀑布模型，由于不支持產品的演化，缺乏靈活性，對開發過程中很難發現的錯誤，只有在最終產品運行時才能暴露出來，從而使軟件產品難以維護。瀑布模型適應場合瀑布模型一般適用于功能、性能明確、完整、無重大變化的軟件系統的開發。例如操作系統、編譯系統、數據庫管理系統等系統軟件的開發。應用有一定的局限性。1.4.2原型模型原型模型（prototypingmodel）的基本框架是軟件開發人員根據用戶提出的軟件基本需求快速開發一個原型，以便向用戶展示軟件系統應有的部分或全部功能和性能，在征求用戶對原型的評價意見后，進一步使需求精確化、完全化，并據此改進、完善原型，如此迭代，直到軟件開發人員和用戶都確認軟件系統的需求并達成一致的理解為止。軟件需求確定后，便可進行設計，編碼、測試等以后的各個開發步驟。需求的采集和細化快速設計建造原型用戶評價原型對原型加工(需求精確化)產品樣品(需求確認)開始停止圖1-4-2使用原型確定需求的過程快速原型的開發途徑有三種：1）僅模擬軟件系統的人機界面和人機交互方式。2）開發一個工作模型，實現軟件系統中重要的或容易產生誤解的功能。3）利用一個或幾個類似的正在運行的軟件向用戶展示軟件需求中的部分或全部功能。總之，建造原型應盡量采用相應的軟件工具和環境，并盡量采用軟件重用技術，在運行效率方面可做出讓步，以便盡快提供。同時，原型應充分展示軟件系統的可見部分，如人機界面、數據的輸入方式和輸出格式等。原型模型的適應場合原型模型比瀑布模型更符合人們認識事物的過程和規律，是一種較實用的開發框架。它適合于那些不能預先確切定義需求的軟件系統的開發，更適合于那些項目組成員（包括分析員、設計員、程序員和用戶）不能很好交流或通信有困難的情況。1.4.3螺旋模型螺旋模型（spiralmodel）是B.Boehm于1988年提出的。它綜合了瀑布模型和原型模型的優點，即將兩者結合，并加入了風險分析機制。螺旋模型的基本框架如圖1-4-3所示。生命周期計劃需求計劃風險分析原型1原型2原型3可操作的原型建模模擬評價操作概念軟件需求需求確認開發計劃組裝測試計劃風險分析風險分析風險分析軟件產品設計設計驗證與確認詳細設計編碼單元測試組裝測試驗收測試實現成本順時針為進展方向計劃：明確目標、約束條件選擇方案風險分析構造原型工程實現用戶評價；階段評審圖1-4-3螺旋模型驗收測試計劃需求精化計劃需求評價評審決策實現計劃1.4.3螺旋模型螺旋模型的每一個周期都包括計劃（需求定義）、風險分析、工程實現和評審4個階段。1．計劃（需求定義）第一周期開始利用需求分析技術理解應用領域，獲取初步用戶需求，制定項目開發計劃（即整個軟件生命周期計劃）和需求分析計劃。經過一個周期后，根據用戶和開發人員對上一周期工作成果評價和評審，修改、完善需求，明確下一周期軟件開發的目標、約束條件，并據此制定新一輪的軟件開發計劃。1.4.3螺旋模型2．風險分析根據本輪制定的開發計劃，進行風險分析，評估可選方案，并構造原型進一步分析風險，給出消除或減少風險的途徑。此時根據風險分析的結果決策項目是否繼續。所以，螺旋模型是一個風險驅動的模型。3．工程實現利用構造的原型進行需求建模或進行系統模擬，…，直至實現軟件系統。1.4.3螺旋模型4．用戶評價與階段評審將原型提交用戶使用并征求改進意見。開發人員應在用戶的密切配合下進一步完善用戶需求，直到用戶認為原型可滿足需求，或對軟件產品設計進行評價或確認等。螺旋模型從第一個周期的計劃開始，一個周期、一個周期地不斷迭代，直到整個軟件系統開發完成。螺旋模型的優點支持用戶需求的動態變化。這就要求構造的原型的總體結構、算法、程序、測試方案應具有良好的可擴充性和可修改性。也支持軟件系統的可維護性，每次維護過程只是沿螺旋模型繼續多走一兩個周期。原型可看作形式的可執行的需求規格說明，易于為用戶和開發人員共同理解，還可作為繼續開發的基礎，并為用戶參與所有關鍵決策提供了方便。螺旋模型的優點螺旋模型特別強調原型的可擴充性和可修改性，原型的進化貫穿整個軟件生存周期，這將有助于目標軟件的適應能力。螺旋模型為項目管理人員及時調整管理決策提供了方便，進而可降低開發風險。螺旋模型的缺點和適應場合缺點：①如果每次迭代的效率不高，致使迭代次數過多，將會增加成本并推遲提交時間；②使用該模型需要有相當豐富的風險評估經驗和專門知識，要求開發隊伍水平較高。適應場合：支持需求不明確、特別是大型軟件系統的開發，并支持面向規格說明、面向過程、面向對象等多種軟件開發方法，是一種具有廣闊前景的模型。增量模型也稱為漸增模型。使用增量模型開發軟件時，把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。開發字處理軟件使用增量模型：第一個增量構件往往實現軟件的基本需求。第二個增量構件提供更完善的編輯和文檔生成功能；第三個增量構件實現拼寫和語法檢查功能；第四個增量構件完成高級的頁面排版功能。1.4.4增量模型圖1.5增量模型采用瀑布模型或快速原型模型開發軟件時，目標都是一次就把一個滿足所有需求的產品提交給用戶。增量模型則與之相反，它分批地逐步向用戶提交產品，整個軟件產品被分解成許多個增量構件，開發人員一個構件接一個構件地向用戶提交產品。從第一個構件交付之日起，用戶就能做一些有用的工作。顯然，能在較短時間內向用戶提交可完成部分工作的產品，是增量模型的一個優點。增量模型的另一個優點是，逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。使用增量模型的困難是，在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。此外，必須把軟件的體系結構設計得便于按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。從某種意義上說，增量模型本身是自相矛盾的。它一方面要求開發人員把軟件看作一個整體，另一方面又要求開發人員把軟件看作構件序列，每個構件本質上都獨立于另一個構件。除非開發人員有足夠的技術能力協調好這一明顯的矛盾，否則用增量模型開發出的產品可能并不令人滿意。圖1.6風險更大的增量模型1.4.5噴泉模型噴泉模型是近幾年提出來的軟件生存周期模型。它是以面向對象的軟件開發方法為基礎，以用戶需求為動力，以對象來驅動的模型。維護測試實現設計分析演化圖1-4-4噴泉模型噴泉模型的特點1．軟件系統可維護性較好；2．各階段相互重疊，表明了面向對象開發