軟件工程學概述

(Introduction)前言Programmingisfun,butdevelopingqualitysoftwareishard.---PhilippeKruchten2outline軟件軟件危機軟件工程軟件生命周期軟件過程及模型3outline軟件軟件危機軟件工程軟件生命周期軟件過程及模型4軟件的概念軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序，數據及其相關文檔的完整集合。程序是按事先設計和的功能性能要求執行的指令序列(instructions)數據是使程序能正常操縱信息的數據結構(datastructures)文檔是與程序開發，維護和使用有關的圖文材料(documents)

軟件=程序+數據+文檔程序=算法+數據結構軟件是人類心靈和智慧在虛擬空間中的投射。5問題1有哪些類型的程序設計語言？面向機器匯編語言、機器語言等面向過程

Fortran,Pascal,C等面向對象

C++,Java等面向問題結構化查詢語言SQL等6問題2在軟件開發過程中會產生哪些文檔？可行性研究報告需求規格說明書概要設計說明書詳細設計說明書測試報告用戶手冊……….7問題3軟件開發過程中為什么要編寫文檔？便于對軟件開發的管理和維護便于各種人員的交流有哪些文檔標準國際標準ISO行業標準IEEE、CMMI國家標準GB企業標準8CaseAnalysis19案例黃河水量調度綜合監視系統系統開發流程：瀑布模型開發工具：VisualBASIC.NET地理信息系統：ARCIMS數據庫管理系統：MicrosoftSQLServer7.0運行環境：局域網絡（LAN）操作系統（WindowsNTServer2000）系統結構：三層Browser/Server結構10系統介紹黃河水量調度綜合監視系統主要功能水量調度實時水情監視監視與預警流域信息查詢氣象信息查詢水調資料查詢水情信息查詢引退水信息查詢降雨信息查詢水質信息查詢水調方案查詢重要文檔查詢功能設置以及地圖標繪11實時水情監視12河道概況13生成報表14水庫概況選擇水庫名稱后，電子地圖會定位到相應位置，并彈出水庫概況信息窗口15水庫概況16水庫概況-庫容曲線17云圖應用查詢18水庫水情19日雨量信息該站雨量信息20時段雨量信息21雨量信息圖22墑情信息圖23軟件的特點表現形式軟件是一種邏輯實體，具有抽象性。生產方式軟件的開發過程中沒有明顯的制造過程，大多數軟件仍是定制的。要求

軟件產品不允許誤差維護在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題24軟件的特點軟件的開發和運行常受到計算機系統的限制，對計算機系統有著不同程度的依賴性軟件的開發至今尚未完全擺脫手工的開發方式軟件本身是復雜的實際問題的復雜性程序邏輯結構的復雜性軟件成本相當昂貴25軟件的分類按軟件的功能進行劃分：系統軟件應用軟件按軟件規模進行劃分：類別參加人員數研制期限源程序行數

微型1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M26軟件的發展軟件發展的四個階段軟件發展存在的問題27軟件發展的四個階段1950---1965

沒有系統的軟件開發方法和管理機制、自定義軟件、批處理、有限分布。1965---1975

產生人機交互的新概念、新技術軟件產品、多用戶、實時、數據庫。281973---1988

微處理器的出現并廣泛應用 分布式系統、嵌入智能、低成本硬件、消費者的影響。1988---至今

廣域和局域網絡迅速普及 強大的桌面系統、面向對象技術、專家系統、人工智能、神經網絡、并行計算、網絡計算機。軟件發展的四個階段29軟件發展存在的問題軟件開發能力不能滿足人們的需要。社會對軟件的依賴程度加大，人們普遍關注軟件的安全和可靠性。建造高可靠性、高質量軟件的任務任重路遠。若干年前開發的應用軟件經過幾十次修改已無人認識它的內部結構，己經不可維護。30outline軟件軟件危機軟件工程軟件生命周期軟件過程及模型31案例分析1：IBM360美國IBM公司在1963年至1966年開發的IBM360的操作系統。這一項目花了5000人一年的工作量，最多時有1000人投入開發工作，寫出了近100萬行源序。......據統計，這個操作系統每次發行的新版本都是從前一版本中找出1000個程序錯誤而修正的結果。......這個項目的負責人F.D.Brooks事后總結了他在組織開發過程中的沉痛教訓時說：“......正像一只逃亡的野獸落到泥潭中做垂死的掙扎，越是掙扎，陷得越深，最后無法逃脫滅頂的災難。......程序設計工作正像這樣一個泥潭，......一批批程序員被迫在泥潭中拼命掙扎，......誰也沒有料到問題竟會陷入這樣的困境......”。IBM360操作系統的歷史教訓成為軟件開發項目的典型事例為人們所記取。SoftwareCrisis!32人月神話：“沒有一種單純的技術或管理上的進步，能夠獨立地承諾在10年內大幅度地提高軟件的生產率、可靠性和簡潔性”。1、大前提：軟件活動包含根本任務和次要任務根本任務——打造構成抽象軟件實體的復雜概念結構，次要任務——使用編程語言表達這些抽象實體，并在時間和空間內將它們映射成機器語言。2、小前提：現有解決方案致力于解決次要任務考察和評估幾乎現有所有的軟件工程解決方案，布魯克斯指出：現有所有方案全都在致力于解決軟件工程中的次要問題。3、結論：沒有銀彈無論這些方案多么完善，都不可能在根本上解決問題，即使將全部次要任務的時間縮減到零，也不會帶來生產率數量級上的提高。33案例分析2：Ariane5June4,1996EuropeanSpaceAgencylostnewestrocket,theAriane5,successortotheAriane4Morethan$370Millionlostonfirstflight34案例分析2：Ariane5TheAriane5softwarereusedthespecificationsfromtheAriane4,buttheAriane5'sflightpathwasconsiderablydifferentandbeyondtherangeforwhichthereusedcomputerprogramhadbeendesigned.Adataconversionfroma64-bitfloatingpointto16-bitsignedintegervaluecausedanarithmeticoverflow,asthefloatingpointnumberhadavaluetoolargetoberepresentedbya16-bitsignedinteger.Itisoneofthemostinfamouscomputerbugsinhistory35軟件危機的概念軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。這些問題絕不僅僅是不能正常運行的軟件才具有的，實際上，幾乎所有軟件都不同程度地存在這些問題。Keypoints:howtodevelopnewsoftwarehowtosupportoldsoftware36軟件危機的典型表現典型表現：對軟件開發成本和進度的估計常常很不準確。用戶對“已完成的”軟件系統不滿意的現象經常發生。軟件產品的質量往往靠不住。軟件常常是不可維護的。軟件通常沒有適當的文檔資料。軟件成本在計算機系統總成本所占的比例逐年上升。軟件開發生產率提高的速度，遠遠跟不上計算機應用普及的速度。37開發成本高舉例38產生軟件危機的原因客觀：軟件本身的特點軟件的規模加大、復雜性提高、性能增強軟件是邏輯產品，尚未完全認識其本質和特點主觀：不正確的開發、管理方法缺乏有效的、系統的開發、維護大型軟件項目的技術手段和管理方法用戶對軟件需求的描述和軟件開發人員對需求的理解往往存在差異計劃不周，最終導致進度拖延沒有充分的文檔資料軟件可靠性缺少度量的標準，質量無法保證忽視軟件維護，使其維護，不易升級39outline軟件軟件危機軟件工程軟件生命周期軟件過程及模型40軟件工程的概念必須意識到：“軟件”編程，它有自己的生命周期

(lifecycle)。大型軟件系統的開發與其它工程項目如建造橋梁、制造飛機、輪船等的開發是同理的。

“軟件工程”(SoftwareEngineering)NATOConference,Garmisch,Germany,1968.解決問題的想法：軟件危機根源解決途徑軟件工程41軟件工程定義Boehm：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。IEEE：將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件中。FritzBauer：建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法。42軟件工程定義概括地說，軟件工程是指導計算機軟件開發和維護的工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它，這就是軟件工程。43軟件工程定義軟件工程是一門交叉學科軟件開發技術:

軟件開發方法軟件開發過程軟件工具和軟件工程環境軟件工程管理:

軟件管理學軟件經濟學

軟件工程所包含的內容不是一成不變的，隨著人們對軟件系統的研制開發和生產的理解。應該用發展的眼光看待它。44

轉變對軟件開發的認識：

上升

程序系統

轉變思維定式：

上升

程序員系統工程師(系統分析員)

工程化訓練45a“quality”focusprocessmodelmethodstools方法使用的順序；要求交付的文檔資料；為保證質量和適應變化所需要的管理；軟件開發各個階段完成的里程碑。軟件開發提供了“如何做”的技術。為軟件工程方法提供了自動的或半自動的軟件支撐環境，CASE軟件工程三要素46軟件工程的歷史起源于20世紀50年代但是從學術的角度看，軟件工程還是一個年輕的學科第一次會議在20世紀60年代后期在80年代才從計算機科學分離開47軟件工程的歷史1、60年代末～80年代初狀況：軟件系統的規模、復雜性以及在關鍵領域的廣泛應用促進了軟件開發過程采納工程化的方法進行管理。研究：開發模型、支持工具、開發方法。成果：瀑布模型、結構化語言（Pascal等）、結構化方法、各種管理方法（如費用估算、文檔復審）。事件：前期主要研究系統實現技術；后期則開始強調管理和軟件質量。焦點：軟件項目482、80年代初～現在

狀況：“軟件工廠”的概念已經提出。研究：軟件生產技術，特別是軟件復用技術和軟件生產管理的研究和實踐。成果：提出了具有廣泛應用前景的面向對象方法和相關的編程語言。事件：軟件過程改進。在工業實踐中建立起一種量化的評估程序，判定軟件組織成熟的程度。焦點：軟件過程軟件工程的歷史493、近幾年

研究從過程管理轉向產品開發，更加注重新的程序開發范型和軟件生產。范圍：面向agent語言、復用技術、需求分析規格說明的形式化研究、高智能高自動化的CASE成為熱點。軟件工程的歷史50軟件工程原理Boehm于1983年提出7條基本原理：(1)用分階段的生命周期計劃嚴格管理(2)堅持進行階段評審(3)實行嚴格的產品控制——基線配置管理

(Baselineconfigurationmanagement)(4)采用現代程序設計技術(5)結果應能清楚地審查—setstandards(6)開發小組的成員應該少而精(7)承認不斷改進軟件工程實踐的必要性51outline軟件軟件危機軟件工程軟件生命周期軟件過程及模型52軟件生命周期軟件的生命周期是軟件產品或系統一系列相關活動的全周期。從形成概念開始，經過研制，交付使用，在使用中不斷增補修訂，直到最后退役，讓位于新的軟件產品的全過程。生命周期的構成：軟件定義問題定義可行性研究需求分析軟件開發總體設計詳細設計編碼和單元測試綜合測試軟件維護維護退役53軟件生命周期問題定義“要解決的問題是什么？”確定要開發軟件系統的總目標給出功能、性能、可靠性以及接口等方面的要求可行性研究“對于問題定義所確定的問題有可行的解決方法嗎？”了解用戶要求和現實環境從技術、經濟、市場等方面研究并論證開發該軟件系統的可行性54軟件生命周期可行性研究(cont.)技術可行性：當前的軟件開發方法和工具能否支持需求的實現；操作可行性：用戶能否在特定的環境下使用這個軟件；經濟可行性：開發和使用、維護這個軟件的成本能否被用戶所接受。階段性產品可行性論證報告制定初步項目開發計劃(人員,進度)55軟件生命周期需求分析“為了解決問題，目標系統必須做什么？”任務：確定用戶對軟件系統的需求：功能需求：軟件必須要完成的功能；性能需求：軟件的安全性、可靠性、可維護性、精度、錯誤處理、適應性、用戶培訓等；運行環境約束：待開發的軟件產品必須滿足的環境要求重要性：軟件開發的依據，軟件驗收的標準56軟件生命周期需求分析(cont.)困難：難以說清、動態變化、歧義、復雜。應用軟件的需求分析涉及應用領域的知識和經驗。需求分析過程需求分析人員必須與用戶不斷、反復地交流和商討，使用戶需求逐步準確、一致、完全。方法：抽象、問題分解、快速原型、多視點等面向數據流的分析方法、面向數據的分析方法、面向對象的分析方法工具：RationalRose,WitClass,VisualModel57

需求分析階段性產品軟件需求規格說明書SRS用軟件需求規格說明語言描述軟件系統的功能需求、性能需求、接口需求、設計需求、軟件產品的基本結構、采用的開發標準和驗收原則等。用戶手冊概要58軟件生命周期總體設計工具

面向數據流的設計方法結構圖面向數據的設計方法面向對象的設計方法RationalRose階段性產品概要設計規格說明書數據庫或數據結構設計說明書集成測試計劃59軟件生命周期詳細設計“應該怎樣具體地實現這個系統呢？”任務細化概要設計所生成的各個模塊,并詳細描述程序模塊的內部細節(算法，數據結構等)，形成可編程的程序模塊，制訂單元測試計劃階段新產品詳細設計規格說明書,單元測試計劃60軟件生命周期編碼和單元測試任務把軟件設計轉換成程序代碼，即寫成以某一種特定程序設計語言表示的“源程序清單”寫出的程序應當是結構良好、清晰易讀的，且與設計相一致的仔細測試每個單元模塊61軟件生命周期編碼和單元測試方法以詳細設計規格說明書為依據、基于某種程序設計語言進行編碼。

結構化程序設計、面向對象程序設計工具Eclipse,VisualStudio.NET,etcIDE階段產品源程序代碼62軟件生命周期綜合測試任務將已測試過的模塊按一定順序組裝起來，按規定的各項需求，逐項進行有效性測試。

方法用戶參與，以軟件需求規格說明書為依據進行測試工具專用測試工具階段性產品可供用戶使用的軟件產品(文檔，源程序)63軟件生命周期軟件運行確認測試后的軟件安裝在用戶環境中；測試通過后移交用戶使用；盡量擴大軟件發行量發揮更大的社會和經濟效益；軟件使用過程中用戶要認真收集軟件錯誤，并撰寫軟件問題報告和軟件維護報告64軟件生命周期軟件維護軟件工作環境不斷變化，軟件也必然跟著變化，軟件必須不斷進化以滿足客戶的需求變化，這是軟件產品最根本的特性。軟件維護占用軟件開發60%以上的工作量。正確性維護擴充性維護適應性維護階段性產品：軟件產品的新版本

65outline軟件軟件危機軟件工程軟件生命周期軟件過程及模型66軟件過程軟件過程是近十年來人們關注的焦點。軟件過程規定了獲取、供應、開發、操作、和維護軟件時，要實施的過程、活動和任務。其目的是為各種人員提供一個公共的框架，以便用相同的語言進行交流。軟件過程模型是軟件過程的抽象表示。軟件過程模型也常稱為：

軟件工程模式軟件生存周期模型67軟件過程模型建造-修正模型瀑布模型快速原型模型增量模型螺旋模型噴泉模型形式化方法模型基于構件的開發模型RUP敏捷過程與極限編程微軟過程模型注：軟件過程模型是不斷發展的，每種模型都有各自的優缺點，使用時可組合多種模型。68建造－修正模型BuildandFixORCodelikeHell(魯莽編碼)從一個大致的想法開始工作，然后經過非正規的設計、編碼、調試和測試方法，最后完成工作?？赡苡谢蚩赡軟]有規范發布（可能）69建造－修正模型好處：成本可能很低。只需要很少的專業知識，任何寫過程序的人都可以。對于一些非常小的、開發完后就會很快丟棄的軟件可以采用。缺點：對于規模稍大的項目，采用這種模型是很危險的。70傳統的瀑布模型實際的瀑布模型瀑布模型711.階段間具有順序性和依賴性前一階段的工作完成之后，才能開始后一階段的工作；前一階段的輸出文檔就是后一階段的輸入文檔。2.推遲實現的觀點對于規模較大的軟件項目來說，往往編碼開始得越早最終完成開發工作所需要的時間反而越長。3.質量保證的觀點每個階段都必須完成規定的文檔，是“文檔驅動”的模型；每個階段結束前都要對所完成的文檔進行評審，盡早發現問題，改正錯誤。瀑布模型的特點721.瀑布模型的優點：可強迫開發人員采用規范的方法；嚴格地規定了每個階段必須提交的文檔；要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。2.瀑布模型的缺點：只能通過文檔了解產品，不經過實踐的需求是不切實際的。3.瀑布模型適用于：需求是預知的；軟件實現方法是成熟的；項目周期較短。瀑布模型的優缺點73導致問題的主要原因用戶與開發者之間存在著差異，由于沒有有效的溝通渠道或媒介，這種差異常常無法協調。2.用戶由于不熟悉信息技術，可能提出非常含糊甚至不可行的需求，這種需求經常被開發人員所誤解。3.經驗表明，一旦用戶開始使用一個計算機系統他們對目標系統的理解可能又會發生很多變化這導致原始需求失效。更嚴重的是一個大型系統往往需要很多人，花幾年的時間才能完成。在這期間，用戶的需求和環境可能發生了大變化，從而使最終的系統不能使用。74

實際上，軟件開發，特別是開發的早期階段，應該是學習和實踐的過程，這個活動（action）應該包括開發人員和用戶兩個方面。盡管用戶在開始時說不清楚所要求的未來軟件系統(目標系統）會是什么樣子（需求），但他們卻可以對IT人員開發的系統非常熟練地進行挑剔！這就啟發我們能否一開始就給用戶展示一個目標系統的的雛形，讓用戶評頭論足，然后逐步進行修改，直至成功。這就是所謂的快速原型模型。

解決辦法75快速原型模型快速原型模型快速原型：是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集。

76適用于用戶驅動的系統（即需求模糊或隨時間變化的系統）軟件產品的開發基本上是線性、順序的改善的用戶參與提高系統的實用性、可維護性節省開發的投入、縮短整個軟件的開發周期本質就是“快速”優點77原型模型存在的問題用戶有時誤解了原型的角色：例如他們可能誤解原型應該和真實系統一樣可靠缺少控制：由于用戶可能不斷提出新要求，因而原型迭代的周期很難控制額外的花費：研究結果表明構造一個原型可能需要10%額外花費為了盡快實現原型，采用了不合適的技術，運行效率可能會受影響原型法要求開發者與用戶密切接觸，有時這是不可能的，例如外包軟件。78注意雖然有問題存在，但是快速原型模型仍是軟件開發的一個有效的過程模型。關鍵是定義了開始的游戲規則，即用戶與開發者兩方面必須達成一致：原型被建造僅是為了定義需求，之后被拋棄（或至少部分被拋棄），實際的軟件在充分考慮了質量和可維護行之后才被開發。79構建原型的方法1.手工繪制一個書面原型，或采用簡單的開發平臺，如微機，構造一個功能型界面。2.使用開發工具，快速開發一個初步的、符合用戶基本（主要）需求的、可運行的原型。3.借用一個商品化的，或第三方開發的類似系統，或對成功軟件的功能復用（部分的或全部的）請用戶評價是否符合需求，在明確了基本需求之后，再著手開發自己的原型。80CaseAnalysis281案例：構建原型《全省雨水情監視預警系統》

項目初期需求不是很清晰，難以獲得完整的需求，瀑布模型不適用，考慮使用快速原型模型，先構建一個原型系統給用戶用，在用戶使用的過程中獲取更多的需求。

構建好的原型系統就是用戶和開發人員之間進行溝通的紐帶。82系統介紹 《全省雨水情監視預警系統》根據今年省水利廳的防汛要求可以隨時隨地地讓防汛有關工作人員看到報警信息，當出現緊急情況時，能主動把報警信息推送到這些工作人員的電腦桌面，也可以以短消息或者圖片的形式發到工作人員的移動設備上，使相關人員隨時了解實時信息，為監視、分析、決策、指揮提供靈活方便的信息獲取手段。83“客戶端登錄”功能原型在本界面用戶輸入服務器地址、用戶名及密碼，可以進行登錄，也可以勾選自動登錄以便下次運行時自動使用已保存的用戶名與密碼進行登錄。84“自動預警”功能原型

當有預警消息傳送至桌面，會進行判斷客戶端是否開啟，若客戶端開啟，則自動打開預警消息的彈窗并顯示預警消息，否則會等待下次開啟客戶端時進行離線傳送。85“用戶管理”功能原型

用戶管理用于管理接受預警信息的用戶。用戶權限分為3種，超級管理員，管理員，普通用戶。超級管理員默認只有一位，可以查看編輯所有用戶信息，管理員可以查看編輯自己的用戶信息以及普通用戶的信息，普通用戶僅僅可以查看自己的用戶信息。86“用戶管理”功能原型87“測站管理”功能原型

測站管理功能實現對所有測站的基礎信息的管理，包括測站基礎數據瀏覽與查看、測站的預警標識的設置。測站信息是系統數據的關鍵基礎部分，通過測站的添加與刪除，為系統提供了測站的預警范圍，同時可以根據預警需要進行設置測站是否預警。88“測站管理”功能原型89“預警管理”功能原型

預警管理頁面是對預警信息進行管理，預警信息是預警系統當中重要預警功能重要的組成部分，包括降雨量門檻，流量門檻，水位門檻，水庫站門檻。

預警管理頁面將對這些門檻進行設置，設置后的門檻值為系統提供預警條件，當預警條件改變時也可以通過預警管理頁面編輯對門檻值進行修改。90“預警管理”功能原型91“日志管理”功能原型

日志管理頁面用于查詢歷史記錄，可以查詢特定用戶的預警信息，可以查看歷史記錄狀態是已經發送，未發送，還是通過離線發送，可以對歷史記錄進行刪除。日志管理頁面是預警系統結果反饋的重要組成部分。92“日志管理”功能原型93“消息管理”功能原型

消息管理用于用戶自定義自己習慣的消息格式，每個用戶對于消息格式有不同的要求，消息管理界面用于對所有的消息格式總共9類進行編輯，對于消息格式不正確的格式，系統會自動判斷，并且自動替換成正確的消息格式。消息管理功能為用戶提供了多樣性選擇，便于系統擴展。94“消息管理”功能原型95增量模型

增量模型把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。96增量模型需求分析驗證規格說明驗證概要設計驗證針對每個構件，完成詳細設計、編碼和集成、經測試后交付給用戶維護97增量模型適用于：適用于需求經常改變的軟件開發過程。如果在項目既定的商業要求期限之前不可能找到足夠的開發人員，在這種情況下，增量模型顯得特別有用。98螺旋模型螺旋模型的基本思想：使用原型及其他方法來盡量降低風險。把它看作在每個階段之前都增加了風險分析過程的快速原型模型。

簡化的螺旋模型99完整的螺旋模型100螺旋模型適用于：特別適用于龐大、復雜并具有高風險的系統。適用于內部開發的大規模軟件項目。101支持軟件復用。利用預先包裝好的軟件構件來構造應用系統。領域分析構件可變性分析構建可復用構件領域模型領域基準體系結構圖可復用構件庫分析體系結構設計獲取構件構件特化和修改評價構件組裝和測試開發未找到構件的部分應用系統工程應用系統領域工程基于構件的開發模型102形式化方法是建立在嚴格數學基礎上的一種軟件開發方法。軟件開發的全過程中，從需求