1、軟件工程概述軟件軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序、數據及其相關文檔的完整集合。軟件的特點1Logical rather than physical（軟件是一種邏輯實體，而非具體的物理實體）2Developed or Engineered, not manufactured in the classical sense（在研制、開發活動中被創造出來，但不能按傳統的生產含義加以理解）3Doesn't wear out（在軟件的運行和使用期間，沒有磨損、老化問題）軟件的發展軟件的發展可以分為這樣三個階段：1程序設計階段，約為50至60年代2程序系統階段，約為60至70

2、年代3軟件工程階段，約為70年代以后時期特點程序設計程序系統軟件工程軟件所指程序程序及說明書程序、文檔及數據主要程序設計語言匯編及機器語言高級語言軟件語言*軟件工作范圍程序編寫包括設計和測試軟件生存期需求者程序設計者本人少數用戶市場用戶開發軟件的組織個人開發小組開發小組及大、中型軟件開發機構軟件規模小型中、小型大、中、小型決定質量的因素個人程序設計技術小組技術水平管理水平開發技術和手段子程序、程序庫結構化程序設計數據庫，開發工具，開發環境，工程化開發方法，標準和規范，網絡和分布式開發，面向對象技術，軟件過程與過程改進維護責任者程序設計者開發小組專職維護人員硬件特征價格高，存儲容量小，工作可靠性

3、差降價，速度、存儲容量及工作可靠性有明顯提高向超高速、大容量、微型化及網絡化方向發展軟件特征完全不受重視軟件技術的發展不能滿足需求，出現軟件危機開發技術有進步，但未獲突破性進展，價格高，未完全擺脫軟件危機軟件危機*軟件需求增長得不到滿足；*軟件生產成本高，價格昂貴；*軟件生產進度無法控制；*軟件需求定義不準確，易偏離用戶需求；*軟件質量不易保證；*軟件可維護性差等等軟件工程采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，這就是軟件工程。Boehm曾為軟件工程下了定義：運用現代科學技術知識來設計并構造計算機程序及為開發、

4、運行和維護這些程序所必需的相關文件資料。Fritz Bauer: The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.軟件工程是建立和使用一系列完善的工程化原則以便經濟地獲得能夠在實際機器上有效運行的可靠軟件。1983年，IEEE（Institute of Electrical & Electronic Engineers，電氣和電

5、子工程師學會）做出的定義是“軟件工程是開發、運行、維護和修復軟件的系統方法。”它的核心內容是“以工程化的方式組織軟件的開發”，其中涉及軟件計劃、開發和維護各個階段。軟件工程三個要素：方法、工具和過程。1） 軟件工程方法為軟件開發提供了“如何做”的技術。2） 軟件工具為軟件工程方法提供自動的或半自動的軟件支撐環境。3） 軟件工程過程指將軟件工程的方法和工具綜合起來，以達到合理、及時地進行計算機軟件開發的目的。軟件工程過程（Software Engineering Process）軟件工程過程是指為了獲得軟件產品，在軟件工具支持下由軟件工程師采用軟件工程方法完成的一系列軟件工程活動。軟件工程的七條

6、原理著名的軟件工程專家于1983年在一篇論文中提出了軟件工程的七條基本原理。他認為這七條原理是確保軟件產品質量和開發效率的原理的最小集合。1 分階段的生命周期計劃嚴格管理2 堅持進行階段評審3 實行嚴格的產品控制4 采用現代程序設計技術5 結果應能清楚地審查6 開發小組的人員應少而精7 承認不斷改進軟件工程實踐的必要性軟件工程的目標組織實施軟件工程項目是為了獲得項目的成功，即達到以下幾個主要的目標：1 出較低的開發成本2 到預期的軟件功能3 取得較好的軟件性能4 使開發的軟件易于移植5 需要較低的維護費用6 能按時完成開發工作，及時交付使用概括地說，基本目標，四個字：優質、高效。即質量高、效率

7、高。軟件工程的原則軟件工程基本目標適用于所有軟件工程項目。為達到這些目標，在軟件開發過程中必須遵循下列軟件工程原則。1抽象2信息隱蔽3模塊化4局部化5確定性6一致性7完備性8驗證性使用一致性、完備性和可驗證性的原則可以幫助開發者設計一個正確的系統。軟件生命周期（life cycle）同其它事物一樣，軟件也有孕育、誕生、成長、成熟、衰亡的生存過程，稱為軟件的生命周期。包括六階段內容：1 制定計劃2 需求分析3 系統設計4 程序編寫5 軟件測試6 運行和維護軟件生命周期經典模型瀑布模型軟件生命周期模型是從軟件項目需求定義直至軟件經使用后廢棄為止，跨越整個生存期的系統開發、運作和維護所實施的全部過程

8、、活動和任務的結構框架。軟件開發模型瀑布模型：按照軟件生命周期經典模型-瀑布模型的各個階段實施開發工作優點：1提供了軟件開發的基本框架，優于“手工作坊”式的開發方法2有利于大型軟件開發過程中人員的組織、管理3有利于軟件開發方法和工具的研究與使用，從而提高了大型軟件項目開發的質量和效率缺點：1在軟件開發的初始階段指明軟件系統的全部需求是困難的，有時甚至是不現實的2需求確定后，用戶和軟件項目負責人要等相當長的時間（經過設計、編碼、測試、運行）才能得到一份軟件的最初版本。如果用戶對這個軟件提出比較大的修改意見，那么整個軟件項目將會蒙受巨大的人力、財力、時間方面的損失。漸進模型（演化模型、原型模型）原

9、型模型在克服瀑布模型缺點、減少由于軟件需求不明確而給開發工作帶來風險方面，確實有著顯著的效果原型化方法是用戶和軟件開發人員之間進行的一種交互過程，適用于需求不確定性高的系統螺旋模型它是生命周期模型與原型模型的結合，不僅體現了兩個模型的優點，還增加了新的成分風險分析螺旋模型是支持大型軟件開發并具有廣泛應用前景的模型例題1開發軟件時，對于提高軟件開發人員工作效率至關重要的是（A）。軟件工程中描述軟件生存周期的瀑布模型一般包括計劃、（B）、設計、編碼、測試、維護等幾個階段。其中，設計階段在管理上又可以依次分成（C）和（D）兩個步驟。供選答案：A： 程序開發環境 操作系統的資源管理功能開發程序人員數量

10、 計算機的并行處理能力B： 需求分析 需求調查可行性分析 問題定義C、D：方案設計代碼設計概要設計 數據設計運行設計詳細設計故障處理設計 軟件體系結構設計答案：A. B. C. D. 2有人將軟件的發展過程劃分為4個階段：第一階段（20世紀50年代）稱為“程序設計的原始時期”。這時既沒有（A），也沒有（B），程序員只能用機器指令編寫程序。第二階段（20世紀60年代）稱為“基本軟件期”。出現了（A），并逐漸普及。隨著（B）的發展，編譯技術也有較大的發展。第三階段（20世紀60年代末-70年代中）稱為“程序設計方法時代”。這一時期，與硬件價格下降相反，軟件開發費用急劇上升。人們提出了（C）和（D）

11、等程序設計方法，設法降低軟件的開發費用。第四階段（20世紀70年代中期至今）稱為“軟件工程時期”，軟件開發技術不再僅僅是程序設計技術，而是包括了與軟件開發的各個階段，如（E）、（F）、編碼、單元測試、綜合測試、（G）及其整體有關的各種管理技術。供選擇的答案：AD：匯編語言 操作系統 虛擬存儲器概念 高級語言結構化程序設計 數據庫概念 固件 模塊化程序設計EG：使用和維護 兼容性的確認 完整性的確認 設計需求定義 圖象處理答案：A. B. C. D. E. F. G.問題定義關于問題性質、工程目標和規模的書面報告可行性研究（也稱可行性分析，Feasibility Analysis）目的就是要用最

12、小的代價在盡可能短的時間內確定問題是否能夠解決。具體任務：1進一步分析和澄清問題定義。2導出系統的高層邏輯模型。從系統邏輯模型出發，探索若干種可供選擇的主要解法（即系統實現方案）。對每種解法都應該至少從下述幾方面研究其可行性：Economic feasibility，經濟可行性。這個系統的經濟效益能超過它的開發成本嗎？ Technical feasibility，技術可行性。使用現有的技術能實現這個系統嗎？Legal feasibility，法律可行性。確定系統開發可能導致的任何侵權行為、妨礙性后果和責任。Operational feasibility，操作可行性。系統的操作方式在這個用戶組織

13、內行得通嗎？3、對以后的行動方針提出建議。基于計算機系統的成本效益分析是可行性研究的重要內容，它用于評估計算機系統的經濟合理性。給出系統開發的成本論證，并將估算的成本與預期的利潤進行對比。成本軟件開發成本主要表現為人力消耗（乘以平均工資則得到開發費用）。一般來說，基于計算機系統的成本由四個部分組成：1購置并安裝軟硬件及有關設備的費用2系統開發費用3系統安裝、運行和維護費用4人員培訓費用1、代碼行技術代碼行技術是比較簡單的定量估算方法，也是一種自底向上的估算方法。它把開發每個軟件功能的成本和實現這個功能需要用的源代碼行數聯系起來。通常根據經驗和歷史數據估計實現一個功能需要的源程序行數。一旦估計出

14、源代碼行數以后，用每行代碼的平均成本乘以行數即可確定軟件的成本。每行代碼的平均成本主要取決于軟件的復雜程度和開發小組的工資水平。大致分如下兩步： 對要求設計的系統進行功能分解，直到可以對為實現該功能所要求的源代碼行數做出可靠的估算為止。根據經驗和歷史數據，對每個功能塊估計一個最有利的、最可能的和最不利的LOC值。設最有利的LOC值為a，最可能的LOC值為m，最不利的LOC值為b，則代碼行的期望（平均）值L 再根據歷史數據和經驗，選擇每個軟件功能塊的LOC價格計算每個功能塊的價格及工作量，并確定該軟件項目總的估算價格和工作量。可行性論證的提綱大致包括如下內容：1、 背景情況。問題描述，市場需求等

15、2、 系統描述。簡略的范圍描述，計劃目標和階段目標等3、 候選方案。候選方案的配置，選擇最終方案的準則等4、 價格利益分析。經費概算和預期經濟效益5、 技術冒險評價。包括技術實力、設備條件和已有工作基礎6、 操作可行性。用戶組織對操作方式的希望7、 法律可行性。系統開發可能導致的侵權、違法等8、 其它與項目有關的問題。可能的未來變化9、 結論。需求分析所謂軟件需求是指用戶對目標軟件系統在功能、行為、性能、設計約束等方面的期望。需求分析具體任務：1、 確定對系統的綜合要求1） 系統功能要求2） 系統性能要求3） 運行要求4） 將來可能提出的要求2、 分析系統的數據要求（需求分析的本質就是對數據和

16、加工進行分析）3、 導出系統的邏輯模型4、 修正系統開發計劃5、 開發原型系統（可選）需求獲取技術1、 訪談與會議2、 書面調查法3、 觀察用戶工作流程4、 用戶和開發人員共同組成聯合小組需求調查主要包括四部分內容：1、 組織概況2、 組織的業務活動：1） 組織的業務狀態2） 業務的詳細內容3） 輸入輸出信息從六個方面著手：*信息流向*信息種類*利用的目的*信息的使用者和制造者*輸入和輸出地點*輸入和輸出信息量3、 存在問題、約束條件4、 未來要求結構化分析方法（SA方法）就是面向數據流自頂向下逐步求精進行需求分析的方法。分析的過程：面向數據流，采用自頂向下、分支分層、逐步分解、逐步細化、逐步

17、求精，最后落實到具體加工、基本加工、簡單加工。用逐步求解的方法控制系統的復雜度，使得復雜系統簡單化、抽象系統具體化。數據流圖（DFD）數據流圖描繪系統的邏輯模型，或者說描繪信息在系統中流動和處理的情況。基本系統模型數據流分析將系統模型視作一種數據變換，它接受各種形式的輸入，通過變換產生各種形式的輸出。例，下圖是一個飛機機票預定系統的基本系統模型 數據流圖的成分下圖是機票預定系統的DFD。可以看出，數據流圖是由以下四個基本成分組成的：1、 數據流（用箭頭表示）2、 加工（用圓圈表示）3、 文件（用單線或雙線表示）4、 數據源點和終點（用方框表示）幾點說明：1、 一個加工并不一定是一個程序。2、

18、一個數據存儲也不等同于一個文件。3、 數據存儲和數據流都是數據，但所處狀態不同。自頂向下逐層畫DFD的步驟如下：1） 把基本系統模型加上源點和終點作為頂層DFD。2） 畫出各層DFD，逐層畫DFD的過程也就是逐層分解的過程。為便于管理，要對分層DFD和圖中的加工進行編號。A、 子圖的圖號就是分解的父圖中相應加工的編號。B、 子圖中的加工編號是由子圖號、小數點、局部順序號組成。3） 畫出總的DFD。（可選）畫DFD時要注意的幾個問題：1、 畫DFD不是畫流程圖。DFD只描述“做什么”，不描述“怎么做”和做的順序。而流程圖表示對數據進行加工的次序和細節。2、 父圖和子圖的平衡。父圖某加工的輸入輸出

19、和分解這個加工的子圖的輸入輸出必須完全一致。3、 局部文件。文件總是局部于分層DFD的某一層或某幾層。4、 分解的深度與層次。逐層分解要求分解到加工成為足夠簡單、易于理解的基本加工為止。所謂基本加工就是加工的意義明確、操作單一。但是究竟分解的層次多少合適，應當根據問題的復雜程度來確定。一般來說，可參考以下準則：1） 一個加工的分解，最多不要超過7個子加工。若超過7個時，可以用增加層次的辦法來減少子加工數。2） 分解在邏輯上應合理、自然，不能硬性分割。3） 在保證數據流的易理解性的前提下，盡量少分解層次。這樣可以減少層次的界面。4） 分解要均勻。即在一張DFD中，不要有些加工已是基本加工，另一些

20、加工還要分解好幾層。絕對均勻不可能，但不要相差太大。數據字典（DD）數據字典是關于數據的信息的集合，也就是對數據流圖中包含的系統元素（所有數據流、加工、文件）的定義的集合。數據流圖和數據字典是需求規格說明書的主要組成部分。1、 數據流條目數據流條目是定義數據流的。定義的方式一般是列出該數據流的各組成數據項。在定義數據流時，通常借助于一些簡單的符號。如=等價于（定義為）+ “與” x=a+b，x由a和b組成|，,“或”x= , ，x=a|b x由a或b組成重復 x=a x由0個或多個a組成mn重復 如x=3a8 表示x中至少出現3次a，至多出現8次a（）可選（選擇）如x=a+（b）+c b可以在

21、x中出現，也可以不出現“”基本數據元素 x=“a” x為取值為a的數據元素.連接符 x=1.9 x可取1至9中的任一值如數據流“存折”可以定義：存折=戶名+所號+帳號+開戶日+性質+（印密）+1存取行500000000099999999戶名=2字母24所號=“001”“999”帳號=“00000001”“99999999”開戶日=年+月+日性質=“1”.“6”印密=“0”存取行=日期+（摘要）+支出+存入+余額+操作+復核日期=年+月+日年=“0001”.“9999”月=“01”.“12”日=“01”.“31”摘要=1字母4支出=金額金額=“0000000.01”.“9999999.99”操作

22、=“00001”.“99999”2、 數據文件條目文件條目是定義文件的，一般只需列出文件的組成數據項，以及文件的組織方式如數據文件（數據存儲）“存折”可定義為存折=戶名+所號+帳號+開戶日+性質+（印密）+1存取行500000000099999999組織：按帳號次序從小至大排列3、 加工條目（小說明）小說明集中描述一個加工“做什么”，即加工邏輯。所謂加工邏輯是指用戶對這個加工的邏輯要求，即這個加工的輸出數據流和輸入數據流的邏輯關系。目前用于寫小說明（加工邏輯說明）的工具有結構化英語、判定表和判定樹。結構化英語下面是商店業務處理系統中“檢查發貨單”的例子IF the invoice exceed

23、s $500 THEN(發貨單金額超過$500)IF the account has any invoice more than 60 days overdue THEN（欠款超過60天）the confirmation pending resolution of the debt(在償還欠款前不予批準)ELSE (account is in good standing)(欠款未超期)issue confirmation and invoice(發批準書及發貨單)ENDIFELSE (invoice $500 or less)(發貨單金額未超過$500)IF the account has a

24、ny invoice more than 60 days overdue THEN(欠款超過60天)issue confirmation, invoice and write message on credit action report(發批準書，發貨單及賒欠報告)ELSE (account is in good standing)（欠款未超期）Issue confirmation and invoice(發批準書及發貨單)ENDIF判定表在某些數據處理問題中，某數據流圖的加工需要依賴于多個邏輯條件的取值，就是說完成這一加工的一組動作是由于某一組條件取值的組合引發的。這時使用判定表來描述比較

25、合適。下面以“檢查發貨單”為例，說明判定表的構成。1234條件發貨單金額>$500>$500$500$500賒欠情況>60天60天>60天60天操作不發出批準書發出批準書發出發貨單發出賒欠報告判定表由四個部分組成，虛線分割開的四部分是：條件茬（Condition Stub）左上部分條件項（Condition Entry）右上部分動作茬（Action Stub）左下部分動作項（Action Entry）右下部分例題 請用判定表表示下面描述的耗電計費系統中電費的計算方法耗電計費系統可以采用固定價格收費和浮動價格收費兩種方式。若采用固定價格方式收費，對每月耗電100KWh以下

26、的用戶只征收最低標準費，超過100KWh的用戶按價格表A收費；若采用浮動價格方式收費，則每月耗電100KWh以下的用戶按價格表A收費，超過100KWh的用戶按價格表B收費。答案：條件收費方式固定固定浮動浮動耗電規模>100100>100100操作征收最低標準費按價格表A收費按價格表B收費條件固定固定浮動浮動>100100>100100操作按價格表A收費征收最低標準費按價格表B收費按價格表A收費判定樹判定樹也是用來表達加工邏輯的一種工具，有時它比判定表更直觀。下面把前面的“檢查發貨單”的例子用判定樹表示。我們用DFD描述了系統中數據流動和加工的狀況，用DD描述了其中的一些

27、數據流、文件和加工，但是還不能滿足需求分析階段的要求。任何一個軟件系統都可能有成千上萬個數據項，僅僅描述它們是不夠的，更重要的是如何把它們以最優的方式組織起來，以滿足系統對數據的要求。E-R圖（Entity-Relationship，實體-關系圖）1、實體是現實世界中實體的數據側面；或者說，數據對象是現實世界中省略了功能和行為的實體。2、聯系客觀世界中的事物彼此間往往是有聯系的。同樣，應用問題中的任何數據對象都不是孤立的，它們與其它數據對象一定存在各種形式的聯系。聯系可分為三類：1） 一對一聯系（1：1）2） 一對多聯系（1：N）3） 多對多聯系（M：N）3、屬性屬性是實體或聯系所具有的性質軟

28、件需求規格說明1. 引言。編寫目的，項目背景等2. 任務概述。目標，運行環境等3. 數據描述。4. 功能需求。5. 性能需求。6. 運行需求。7. 其他需求。例題1軟件需求分析的任務不應包括（A）。進行需求分析可使用多種工具，但（B）是不適用的。在需求分析中，分析員要從用戶那里解決的最重要的問題是（C）。需求規格說明書的內容不應當包括（D）。該文檔在軟件開發中具有重要的作用，但其作用不應當包括（E）。供選答案：A：問題分析信息域分析結構化程序設計確定邏輯模型B：數據流圖判定表PAD圖數據詞典C：要讓軟件做那么要給軟件提供哪些信息要求軟件工作效率如何要讓軟件具有什么樣的結構D：對重要功能的描述對

29、算法的詳細過程性描述軟件確認準則軟件的性能E：軟件設計的依據用戶和開發人員對軟件要“做什么”的共同理解軟件驗收的依據軟件可行性分析的依據答案：A. B. C. D. E.2在結構化分析方法中，用以表達系統內數據的運動情況的工具有（）。供選答案：A.數據流圖 B.數據詞典 C.結構化英語 D.判定表與判定樹答案：A一旦軟件需求確認之后，就進入開發階段。開發階段由3個互相關聯的步驟組成，即設計、實現（編碼）和測試。從工程管理的角度看，軟件設計可分為概要設計/總體設計和詳細設計兩大步驟。從技術角度來看，軟件設計可分為數據設計、系統結構設計和過程設計。現在越來越多的人把界面設計也單獨取出作為一個方面。

30、概要設計基本目的是用比較抽象概括的方式確定系統如何完成預定的任務，即確定軟件系統的總體結構，給出系統中各個組成模塊的功能和模塊間的接口。涉及的概念主要有：模塊化，抽象與逐步求精，信息隱藏，模塊獨立在進行軟件結構設計時應該遵循的最重要的原理是模塊獨立原理。采用模塊化原理的優點：1） 可以使軟件結構清晰，容易設計、容易閱讀和理解、容易測試和調試。2） 提高軟件的可靠性。3） 易于軟件開發工程的組織管理。所謂模塊的獨立性，是指軟件系統中每個模塊只涉及軟件要求的具體的子功能，而和軟件系統中其他模塊的接口是簡單的。模塊獨立性可用兩個定量準則來度量耦合（coupling）：各個模塊之間相互關聯的度量內聚（

31、cohesion）：模塊內部各元素之間相互關聯的度量耦合共分七級非直接耦合、數據耦合、特征耦合/標記耦合、控制耦合、外部耦合、公共耦合、內容耦合按上述順序，耦合性逐漸升高，模塊獨立性逐漸降低。內聚共分七級偶然內聚、邏輯內聚、時間內聚、過程內聚、通信內聚、順序內聚、功能內聚按上述順序，內聚性逐漸加強，功能趨于單一，模塊獨立性也逐漸加強。軟件概要設計的目標是力求增加模塊的內聚，盡量減少模塊間的耦合。但增加內聚比減少耦合更重要，應當把更多的注意力集中到提高模塊的內聚程度上來。系統結構設計的七條啟發式原則：1） 改進軟件結構提高模塊獨立性2） 模塊規模應該適中3） 深度、寬度、扇出和扇入都應適當4）

32、模塊的作用范圍應在控制范圍之內5） 力爭降低模塊接口的復雜程度6） 設計單入口單出口的模塊7） 模塊功能應該可以預測概要設計常用圖形工具有：層次圖、HIPO圖、結構圖（SC圖）。常見的軟件概要設計方法有3大類：1） 以數據流圖為基礎構造模塊結構的結構化設計方法（SD，Structured Design）2） 以數據結構為基礎構造模塊結構的Jackson方法和LCP（Logical Construction of Programs）（Wanier）邏輯構造方法3） 以對象、類、繼承和通信為基礎的面向對象的設計方法（OOD）此外，以信息隱藏為原則的Parnas方法雖然沒有給出系統化的設計方法，但提

33、出了一組原則。結構化設計方法（Structured Design，SD）是基于模塊化、自頂向下細化、結構化程序設計等程序設計技術基礎而發展起來的。概要設計的步驟：1、 分析/重畫DFD2、 確定DFD的特點及邊界3、 映射為軟件結構4、 細化后，得到初始結構圖5、 獲得最終的軟件結構圖概要設計說明書1. 引言。編寫目的，項目背景等2. 任務概述。目標，運行環境，需求概述，條件與限制等3. 總體設計。處理流程，系統總體結構等4. 接口設計。外部接口，內部接口等5. 數據結構設計6. 運行設計7. 出錯處理設計8. 其它問題例題1在眾多的設計方法中，SD方法是最受人注意的，也是最廣泛應用的一種，這