第2章軟件工程

第2章軟件工程2.1軟件工程的基本概念2.2軟件開發過程2.3系統定義2.4軟件實現2.5軟件維護2.6軟件開發管理2.1軟件工程的基本概念2.1.1軟件危機及其形成原因2.1.2軟件工程的定義2.1.3軟件工程的基本原則2.1.4軟件工程的基本內容一、軟件的概念

軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序、數據及其相關文檔的完整集合。 其中，程序是按事先設計的功能和性能要求編寫的指令序列；數據是使程序能正常操縱信息的數據結構；文檔是與程序開發、維護和使用有關的圖文材料。 注：程序并不是軟件，程序只是軟件的組成部分。2.1.1軟件危機及其形成原因二、軟件的特點（1）軟件是一種邏輯實體。（2）軟件的開發，是人的智力的高度發揮，而不是傳統意義上的硬件制造。（3）軟件維護與硬件的維修有著本質的差別。（4）軟件的開發和運行常常受到計算機系統的限制，對計算機系統有著不同程度的依賴性。（5）軟件的開發至今尚未完全擺脫手工藝的開發方式，使軟件的開發效率受到很大限制。（6）軟件的開發是一個復雜的過程。（7）軟件的成本非常高昂。三、軟件危機及其形成原因什么是軟件危機軟件不符合用戶的實際需要軟件價格昂貴軟件開發項目超支和延期軟件質量低，可靠性差軟件缺少適當的文檔資料難于修改和維護軟件軟件危機的形成原因軟件本身是邏輯部件，質量難以評價，潛在的錯誤在所難免軟件規模越來越大，軟件結構越來越復雜忽視需求分析的重要性，急于開始編程輕視軟件測試和輕視軟件維護軟件開發技術落后，生產方式落后，開發工具落后軟件危機的解決方法

必須消除存在的錯誤認識、樹立軟件工程觀念用工程化方法和途徑來開發和維護軟件

開發和使用更好的軟件工具

應該采取必要的管理措施

總之:技術措施+組織管理措施按工程化的原則和方法來組織和規范軟件開發過程，解決軟件研制中面臨的困難和混亂，從而根本上解決軟件危機。所謂軟件工程，就是研究大規模程序設計中的方法、工具和管理的一門工程科學。1968年北約組織在前聯邦德國格密斯舉行的國際學術會議上正式提出并使用了“軟件工程”的概念，運用工程學的基本原理和方法來組織和管理軟件生產。后來還發展了相關的心理學、生理學和經濟學等方面的學科。軟件工程誕生了，它是解決軟件危機唯一有效的方法。定義一：軟件工程是科學知識在設計和構造計算機程序以及開發、運作和維護這些程序所要求的有關文檔編制中的實際應用。定義二：為了經濟地獲得可靠的能在實際的計算機上運行的軟件所確立和使用的健全的工程原理。定義三：對軟件開發、運行、維護、退役的系統研究方法。

定義四：對軟件開發、運行、維護的系統化的、有紀律的、可定量的方法的應用，即對軟件的工程化的應用。定義五：軟件工程是指導計算機軟件開發和維護的一門學科，它采用工程的概念、原理、技術和方法，把經過時間考驗而證明是正確的管理技術和與技術方法結合起來用于開發軟件。2.1.2軟件工程的定義用分階段的生命周期計劃嚴格管理

堅持進行階段評審

實行嚴格的產品控制采用現代程序設計技術

工作成果應當能夠清楚地評審開發小組的成員應少而精

承認不斷改進軟件工程實踐的必要性2.1.3七條基本原則軟件生存周期模型指導整個軟件開發過程軟件分析系統分析、可行性分析、軟件開發計劃、需求分析軟件設計總體設計、詳細設計

軟件實現編程序軟件測試

軟件維護

軟件管理

成本估算、風險分析、進度安排、人員組織、軟件質量保證2.1.4軟件工程的基本內容2.2軟件開發過程2.2.1軟件開發的主要階段2.2.2軟件生命周期模型2.2.3模塊化軟件開發原則2.2.4軟件開發方法軟件從產生、發展到淘汰要經歷定義、開發和維護三大階段定義階段細分成可行性論證、需求分析開發階段細分成總體設計、詳細設計、實現、集成測試和確認測試維護階段細分成軟件使用、修改維護、退役2.2.1軟件開發的主要階段軟件產品從形成概念開始，經過開發、使用和維護，直到退役的全過程九個階段：2.2.2軟件生命周期模型軟件生命周期瀑布模型將軟件生存周期的各項活動規定為依照固定順序連接的若干階段工作，形如瀑布流水，最終得到軟件產品。瀑布模型的特點線性開發序列：每一階段任務必須通過評審才能進入下一階段，直線前進避免大的返工，允許局部的返工瀑布模型的局限性明確全部需求困難甚至不現實開發周期過長、用戶不能及時提出修改意見軟件生存周期漸增模型又稱演化模型又稱原型模型用主動的正常的迭代避免被迫的不正常的反復程序員與用戶反復交互原型模型的特點采用軟件重用技術和強有力的快速開發工具采用主動的、正常的迭代避免了瀑布模型被迫的、不正常的返工有助于用戶和軟件開發人員對需求的定義和確認原型模型的局限性不收斂于開發者預定目標資源規劃和管理較為困難更新文檔麻煩抽象自頂向下逐步求精模塊化信息隱蔽與局部化模塊獨立啟發式規則2.2.3模塊化軟件開發原則把大型軟件按照規定的原則劃分為一個個較小的、相對獨立但又相關的模塊的設計方法，叫做模塊化設計（modulardesign）。模塊（module）是數據說明和可執行語句等程序對象的集合，每個模塊單獨命名并且可以通過名字對模塊進行訪問實現模塊化設計的重要指導思想是分解、信息隱藏和模塊獨立性。分解 設函數C(x)定義問題x的復雜程度，函數E(x)確定解決問題x所需要的工作量（時間）。對于兩個問題Pl和P2，如果C(P1)＞C(P2)，

顯然 E(P1)＞E(P2)

根據人類解決一般問題的經驗，如果一個問題由Pl和P2兩個問題組合而成，那么它的復雜程序大于分別考慮每個問題時的復雜程度之和，即

C(Pl＋P2)＞C(P1)＋C(P2)

綜上所述，可得到下面的不等式

E(Pl＋P2)＞E(Pl)＋E(P2)模塊化模塊完成特定的子功能可以組合、分解、更換的單元，如過程、函數、子程序、宏等模塊化解決一個復雜問題時，自頂向下逐層將軟件分解成若干模塊的過程目的：降低軟件的復雜性模塊化軟件開發原則模塊劃分的指導原則模塊可分解性：能把問題分解為子問題的系統化機制模塊可組裝性：能把現有的模塊組裝成新系統模塊可理解性：一個模塊作為獨立單元無需參考其它模塊來理解模塊連續性：系統需求的微小修改只導致對個別模塊，而不是對整個系統的修改模塊保護性：一個模塊內出現異常情況時，它的影響局限在該模塊內部模塊化軟件開發原則模塊與成本的關系模塊化軟件開發原則信息隱蔽與局部化信息隱蔽：一個模塊內包含的信息(過程或數據)對于不需要這些信息的其它模塊來說不可見（不能訪問）局部化：將關系密切的軟件元素的位置盡量靠近信息隱蔽與局部化有利于軟件的可維護性，可以防止誤操作和誤修改模塊化軟件開發原則模塊獨立模塊獨立性：模塊化、抽象、信息隱蔽和局部化直接結果模塊獨立的好處：使軟件開發更容易、適合分工合作使軟件測試和維護更容易模塊獨立的度量內聚：一個模塊內部各元素之間彼此結合的緊密程度的度量耦合：不同模塊之間互連程度的度量模塊化軟件開發原則啟發式規則改進軟件結構提高模塊獨立性模塊規模應該適中模塊之間的調用關系應當按照層次化組織模塊的深度、寬度、扇出和扇入都應適當設計單入口單出口的模塊模塊功能應該可以預測模塊化軟件開發原則對軟件分析方法、軟件設計方法軟件實現（編碼）方法的總稱。結構化方法（StructuredMethod）面向對象方法（Object-OrientedMethod）2.2.4軟件開發方法2.3系統定義2.3.1可行性分析2.3.2需求分析可行性分析目的用最小的代價在盡可能短的時間內確定問題是否能夠解決任務在澄清了問題定義之后，分析員首先應該導出系統的邏輯模型，然后從系統邏輯模型出發，探索出若干種可供選擇的主要解法（即系統實現方案）。最后仔細研究每種解法的可行性。2.3.1可行性分析一般說來，可行性研究應該從下述幾方面進行：（1）技術可行性：指使用現有的技術能否完成這個項目。（2）經濟可行性：指通過對軟件開發項目進行成本/效益估計，以確定軟件系統可能帶來的經濟效益能否超過研制和維護此系統所需的費用。（3）社會因素的考慮：軟件開發是否會侵犯他人、集體或國家的利益，是否違反國家的法律并可能由此而承擔法律責任。步驟確定項目規模和目標研究正在運行的系統建立新系統的高層邏輯模型導出和評價各種方案推薦可行方案編寫可行性分析報告軟件開發計劃通過可行性分析，如果開發軟件系統可行的話，接著要制定軟件的開發計劃。內容資源計劃：人力資源、硬件資源、軟件資源成本預算：估計總的開發成本進度安排：確定最終的軟件交付日期、在交付日期內安排和分配工作量需求分析需求分析目標解決“做什么(Whattodo)”，而不是“怎么做(Howtodo)”既是軟件開發依據，也是軟件驗收標準與用戶充分溝通，去偽存真，去粗存精通信瓶頸：用戶vs

開發人員階段性標志：軟件需求規格說明(SRS：SoftwareRequirementsSpecification)

2.3.2需求分析一、需求分析任務確定軟件系統的綜合要求功能要求性能要求系統數據接口要求安全性保密性和可靠性要求系統運行要求異常處理要求等分析軟件系統的數據要求建立系統的邏輯模型評估項目開發計劃（成本、進度）二、需求分析工具層次方框圖Warnier圖IPO圖（輸入/處理/輸出）三、需求分析方法結構化分析方法結構化分析方法（StructuredAnalysis，簡稱SA方法）是70年代中期提出的一種面向數據流、自頂向下、逐步求精進行需求分析的方法。結構化分析方法中使用的工具主要包括：數據流圖、數據字典、結構化語言、判定表和判定樹。 其中數據流圖用以表達系統內數據的運動情況；數據字典用以定義系統中的數據；結構化語言、判定表和判定樹都是用以描述數據流的加工的工具。面向對象分析方法2.4軟件實現2.4.1總體設計2.4.2詳細設計2.4.3編碼2.4.4測試一、總體設計內容總體設計又稱概要設計解決“如何做(Howtodo)”設計供選擇的方案推薦最佳方案設計軟件結構,劃分功能模塊，定義各功能模塊的接口設計數據結構和數據庫用戶界面設計制定測試計劃編寫總體設計階段的文檔評審總體設計方案2.4.1總體設計軟件實現二、總體設計的圖形工具層次圖HIPO圖（層次圖加輸入/處理/輸出圖）結構圖軟件實現三、總體設計的設計方法結構化設計自頂向下基于數據流的設計方法面向對象設計軟件實現

詳細設計以總體設計階段的工作為基礎的，但又不同于總體設計，主要表現為以下兩個方面：（1）在總體設計階段，數據項和數據結構以比較抽象的方式描述，而詳細設計階段則應在此基礎上給出足夠詳細描述。（2）詳細設計要提供關于算法的更多的細節，例如：總體設計可以聲明一個模塊的作用是對一個表進行排序，詳細設計則要確定使用哪種排序算法。在詳細設計階段為每個模塊增加了足夠的細節后，程序員才能夠以相當直接的方式進行下一階段的編碼工作。2.4.2詳細設計軟件實現 詳細設計的任務和原則一、詳細設計的任務1）確定每個模塊的算法。

2）確定每一個模塊的數據組織。

3）為每個模塊設計一組測試用例。

4）編寫詳細設計說明書。軟件實現

二、詳細設計的原則（1）模塊的邏輯描述正確可靠、清晰易讀。（2）采用結構化程序設計方法，改善控制結構，降低程序復雜度，提高程序的可讀性、可測試性和可維護性。

軟件實現三、詳細設計的工具過程設計語言(PDL：ProcedureDesignLanguage)又稱偽碼，半形式化、易編輯、易自動生成程序流程圖易上手、非結構化盒圖（N-S圖）結構化、功能域明確PAD圖結構化、可用于數據結構、易自動生成軟件實現四、詳細設計的方法面向數據結構的設計方法：以數據結構為中心結構化設計方法以數據流為中心面向對象設計方法以對象為中心軟件實現2.4.3編碼編碼（實現）：俗稱編程序(Programming)編碼任務選擇一種程序設計語言將詳細設計文檔“翻譯”為程序（源程序代碼）單元測試（調試）編碼原則高效+技巧安全+可靠時間、空間效率可用性、可維護性、可移植性良好的編程風格可以減少軟件錯誤階段性標志：源程序代碼編碼風格

編碼風格實際上是一種編碼原則。從20世紀70年代以來，編碼的目標從強調效率轉變到強調清晰。與此相應，編碼風格也從追求“聰明”和“技巧”，變為提倡“簡明”和“直接”。人們逐漸認識到，良好的編碼風格能在一定程度上彌補程序設計語言存在的缺點。反之，如果不注意編碼風格，即使使用了結構化的現代語言，也很難寫出高質量的程序。一、代碼文檔化：指編碼時適當選擇標識符的名字、適當安排注釋和注重程序的整個組織形式。二、數據說明：程序或模塊在其可執行部分的前面都集中了一些說明語句，出于閱讀理解和維護的要求，最好使其規范化，使說明的先后次序固定。三、語句構造：每條語句都應當簡單而直接，同時也不應為了追求運行效率而使代碼復雜化，這樣會減低程序的可讀性。四、輸入/輸出：源程序的輸入輸出風格必須滿足運行工程學的需要。程序效率 盡管效率是值得追求的目標，但不應為了非必需的效率提高而犧牲代碼的清晰性、可讀性和正確性。應記住下面三條準則。（1）效率是一種性能需求，目標值應當在需求分析階段給出。軟件效率應以需求為準，不應以人力所及為準。（2）好的設計可以提高效率。（3）代碼效率與代碼的簡單性相關。一、代碼效率

（1）應先簡化算術和邏輯的表達式。

（2）仔細研究嵌套的循環，以確定是否有語句可以從內層往外移。

（3）盡量避免使用多維數組。

（4）盡量避免使用指針。

（5）使用執行時間短的算術運算。

（6）即使語言允許，一般也不要采用混合數據類型。

（7）盡量使用整數表達式和布爾表達式。二、輸入/輸出的效率（1）所有輸入/輸出都應該有緩沖，以減少過多的通信次數。

（2）對輔存（如磁盤），應選用最簡單的訪問方法。

（3）輔存的輸入/輸出，應該以塊為單位進行。

（4）終端和打印機的輸入/輸出，應當考慮設備的特性，以提高輸入/輸出的質量和速度。

（5）不應當采用不能被人們所理解的超高效的輸入/輸出。結構化程序設計采用自頂向下、逐步求精的設計方法；采用單入口單出口的控制結構；只包含順序、選擇和循環三種控制結構；軟件實現一、軟件測試的目標測試是為了發現程序中的錯誤而執行程序的過程；好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；成功的測試是發現了至今為止尚未發現的錯誤的測試。二、測試原則測試不能證明軟件沒有錯誤應避免程序員測試自己的程序對合法的和非法的輸入都要測試測試用例（包括輸入及預期輸出）必須高效2.4.4軟件測試軟件實現測試原則盡早地和不斷地進行軟件測試程序員應避免檢查自己的程序要預先確定測試用例設計的測試用例應當包括合理的輸入條件和不合理的輸入條件充分注意測試中的群集現象嚴格執行測試計劃，排除測試的隨意性應當對每個測試結果做全面檢查妥善保存測試計劃、測試用例、出錯統計和最終分析報告軟件實現三、測試分類單元測試（又稱模塊測試）時期：編碼階段定義：對軟件設計的最小單位（程序模塊）進行的測試方法：采用白盒測試法輔之以黑盒測試法內容：模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試組裝測試（又稱集成測試）時期：編碼完成階段定義：在單元測試的基礎上將所有模塊按照設計要求組裝為完整的系統方法：漸增式測試和非漸增式測試內容：各模塊的接口軟件實現確認測試定義：驗證軟件的功能、性能及其他特性是否與用戶的要求一致方法：測試、β測試內容：有效性測試和驗收測試階段：即將交付使用系統測試定義：把通過確認測試的軟件作為整個計算機系統的一個元素與其他元素結合在一起在實際運行（使用）環境下，對計算機系統進行一系列的組裝測試和確認測試軟件實現四、白盒測試前提：完全了解程序的結構和處理過程方法：窮盡測試、邏輯覆蓋

邏輯覆蓋的不同標準語句覆蓋選擇足夠多的測試數據,使被測程序中每個語句至少執行一次判定覆蓋條件覆蓋判定／條件覆蓋條件組合覆蓋路徑覆蓋軟件實現五、黑盒測試定義：只檢查程序功能是否能按照需求規格說明書的規定正常運行，程序是否能接收輸入數據并產生正確的輸出信息，并且保持外部信息的完整性。方法：等價類劃分僅選取少量最有代表性的輸入數據邊界值分析使程序運行在邊界情況(下標,循環次數)下錯誤推測軟件實現六、軟件調試

任務：測試之后進一步診斷和改正程序中的錯誤步驟：確定錯誤的位置確定問題的原因方法：輸出存儲器內容適當插入打印語句使用專門的調試工具調試策略

試探法、回溯法、歸納法、演繹法軟件實現2.5軟件維護2.5.1什么是軟件維護2.5.2軟件維護分類2.5.3軟件維護的過程軟件維護是軟件生命周期的最后一個階段，它是指已完成開發工作，交付使用后，對軟件產品所進行的一些軟件工程活動。軟件維護的必要性運行中發現錯誤適應軟硬件環境變化適應功能需求變化維護成本通常高大開發成本的4倍2.5.1什么是軟件維護軟件維護決定可維護性的因素可理解性：理解軟件的難易程度可測試性：測試和診斷軟件中錯誤的難易程度可修改性：修改軟件的難易程度各類文檔軟件維護的分類改正性維護：在軟件運行中發生異常或故障時進行。適應性維護：為使該軟件能適應外部環境的變動。完善性維護：為擴充軟件的功能，提高原有軟件性能而開展的軟件工程活動。軟件維護在軟件維護時，必然會對源程序進行修改，為了正確、有效地修改源程序，需要經歷下列步驟：分析和理解程序修改程序重新驗證程序軟件維護的組織維護文檔的編寫軟件維護2.5.3軟件維護的過程2.6軟件開發管理2.6.1質量管理2.6.2進度安排2.6.3人員管理2.6.4風險分析2.6.5成本/效益分析軟件質量：定量比較困難ISO軟件質量模型的質量特性和質量子特性組成：功能性適應性、準確性、互用性、依從性、安全性可靠性成熟、容錯、易恢復易使用性易理解、易學、易操作效率時間特性、資源特性可維護性易分析、易修改、穩定、易測試可移植性適應性、易安裝、一致性、易替換軟件開發管理2.6.1質量管理