第一篇：軟件工程總結 具體

第一章

1．什么是軟件危機？它有哪些典型表現？為什么會產生軟件危機？

軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。這些問題表現在以下幾個方面：

(1)用戶對開發出的軟件很難滿意。

(2)軟件產品的質量往往靠不住。

(3)一般軟件很難維護。

(4)軟件生產效率很低。

(5)軟件開發成本越來越大。

(6)軟件成本與開發進度難以估計。

(7)軟件技術的發展遠遠滿足不了計算機應用的普及與深入的需要。產生軟件危機的原因

(1)開發人員方面，對軟件產品缺乏正確認識，沒有真正理解軟件產品是一個完整的配置組成。造成開發中制定計劃盲目、編程草率，不考慮維護工作的必要性。

(2)軟件本身方面，對于計算機系統來說，軟件是邏輯部件，軟件開發過程沒有統一的、公認的方法論和規范指導，造成軟件維護困難。

(3)尤其是隨著軟件規模越來越大,復雜程度越來越高,原有軟件開發方式效率不高、質量不能保證、成本過高、研制周期不易估計、維護困難等一系列問題更為突出，技術的發展已經遠遠不能適應社會需求。

2．假設自己是一家軟件公司的總工程師，當把圖1.1給手下的軟件工程師們觀看，告訴他們及早發現并改正錯誤的重要性時，有人不同意這個觀點，認為要求在錯誤進入軟件之前就清除它們是不現實的，并舉例說：“如果一個故障是編碼錯誤造成的，那么，一個人怎么能在設計階段清楚他呢？”應該怎樣反駁他？

反駁：發生在編碼時期的故障極有可能是需求分析階段由于操作不當產生的，所以必須及時消除錯誤，否則，到了后期軟件運行和維護階段再回過頭來修改，將會付出更大的代價。

3．什么是軟件工程?它有哪些本質特性？怎樣用軟件工程消除軟件危機？

軟件工程是指導計算機軟件開發和維護的工程學科。

(1)它采用工程的概念、原理、技術和方法來開發和維護軟件；

(2)它將管理技術與當前經過時間考驗的而證明是正確的技術方法結合起來；

(3)它強調使用生存周期方法學和結構分析和結構技術；

(4)經過人們長期的努力和探索，圍繞著實現軟件優質高產這個目標,從技術到管理兩個方面做了大量的努力,逐漸形成了“軟件工程學”這一新的學科。

消除軟件危機的措施：

（1）對計算機軟件有一個正確的認識（軟件≠程序）

（2）必須充分認識到軟件開發不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目。

（3）推廣使用在實踐中總結出來的開發軟件的成功技術和方法。（4）開發和使用更好的軟件工具 ? 1.技術措施 推廣和使用在實踐中總結出的好的軟件開發技術和方法，并不斷探索和研究更有效的技術。開發和使用更好的軟件工具，包括采用好的開發工具，系統分析和輔助設計工具等，以提高工作效率。? 2.管理措施

吸收和借鑒人類長期以來從事各類工程項目所積累的行之有效的原理、概念、技術和方法

4.軟件生命周期的定義：

一個軟件從定義、開發、使用和維護，直到最終被廢棄為止的整個過程

軟件生命周期的構成：

5.軟件生命周期的各個階段和任務：

定義時期：問題定義 可行性研究 需求分析

開發時期：總體設計 詳細設計 編碼和單元測試 綜合測試 維護時期：綜合測試

(1)問題定義：通過對系統實際用戶和使用部門負責人的訪問調查，明確要解決問題性質、工程目標和規模。(2)可行性研究：導出系統的高層邏輯模型（數據流圖），并在此基礎上更準確、更具體的確定工程的規模和目標；更準確的估計系統的成本和效益。

(3)需求分析：和用戶密切配合，充分交流信息，以得到用戶確認的系統邏輯模型（數據流圖、數據字典及簡要的算法表示的系統邏輯模型）。(4)總體設計：

1）提出幾種可能的解決方案，權衡各種方案的利弊，并推薦出最佳方案；

2）設計軟件的結構，確定軟件的模塊構成及模塊之間的關系。

(5)詳細設計：把解決問題的方案具體化，設計出程序的詳細規格說明，并包含必要的細節信息。(6)編碼和單元測試：將詳細設計的結果翻譯成高級程序設計語言的源程序，并仔細測試編寫的每一個模塊。

(7)綜合測試：通過各類型的嚴格測試與調試，使軟件達到預定的要求。

1）集成測試：各模塊裝配后測試；

2）驗收測試：按規格說明書。

(8)軟件維護：通過必要的維護工作使得系統持久的滿足用戶的需要： 1）改正性維護；2）適應性維護； 3）完善性維護；4）預防性維護 6.軟件工程的定義：

采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的技術方法結合起來，來指導軟件的開發與維護 7.軟件工程的基本原理：

（1）用分階段的生命周期計劃嚴格管理

項目概要計劃，里程碑計劃，項目控制計劃，產品控制計劃，驗證計劃，運行維護計劃。

（2）堅持進行階段評審（評審過程）

每個階段都進行嚴格的評審，以便盡早發現錯誤。（3）實行嚴格的產品控制

實行基準配置（經過階段評審后的軟件配置成份，包括文檔和程序代碼）對軟件的修改進行嚴格管理。（4）采用現代的程序設計技術 結構化分析(SA)與設計(SD);面向對象的分析(OOA)與設計(OOD)。

（5）結果能清楚的審查

規定開發組織的責任和產品標準。

（6）開發小組的人員應該少而精

成員素質要好，人數不宜過多。

（7）承認不斷改進軟件工程實踐必要性 8.軟件工程方法學定義：

通常把在軟件生命周期全過程中使用的一整套技術方法的集合成為?（亦為范型）9．軟件工程方法學的三要素：方法、工具、過程 10.軟件工程方法學的包括：

簡述結構化范型和面向對象范型的要點，并分析它們的優缺點

傳統方法學（生命周期方法學/結構化范型）（1）仍然是使用十分廣泛的軟件工程方法學。

（2）采用結構化技術來完成軟件開發的各項任務，并使用適當的軟件工具或軟件工程環境來支持結構化技術的運用。

（3）從上而下，順序地完成軟件開發的各階段任務 面向對象的方法學

（1）出發點和基本原則是盡量模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識實踐解決問題的方法與過程，從而使描述問題的問題空間與實現解法的解空間在結構上盡可能一致

（2）把對象作為融合了數據及在數據上的操作行為的統一軟件構件；（3）把所有對象都劃分成類；

（4）按照父類與子類的關系，把若干個相關類組成一個層次結構的系統；（5）對象彼此間僅能通過發送消息互相聯系 11． 什么是軟件生命周期模型？ 模型分類？

軟件開發過程模型是軟件開發全部過程、活動和任務的結構框架。它能直觀表達軟件開發全過程，明確規定要完成的主要活動、任務和開發策略。亦稱為： 軟件開發模型 軟件生存期模型

分類(1)瀑布模型(2)快速原型模型(3)增量模型（4）螺旋模型（5）噴泉模型 12．試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優缺點，說明每種模型的適用范圍？ 瀑布模型：

【適用領域】：用戶需求清楚的表達

優點：1.可強迫開發員采用規范的方法 2.嚴格地規定了每個階段必須提交的文件 3.要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。缺點：傳統的瀑布模型過于理想化，是由文檔驅動的。

快速原型模型：

（1）一般用于最終系統的早期用戶評價,開發工期短，質量有保證

（2）軟件產品的開發基本是線性順序進行的，加速軟件開發，節省軟件開發成本 【適用領域】：事先不能完整定義需求的領域 增量模型：

【適用領域】：用戶逐步需求提交產品

（1）先完成一個系統子集的開發，再按同樣的開發步驟增加功能(系統子集),如此遞增下去直至滿足全部系統需求。（2）系統的總體設計在初始子集設計階段就應作出設想 13．軟件開發方法：軟件開發過程所遵循的方法和步驟

開發過程一般包括：需求、設計、實現、確認等活動 主要針對需求和設計的典型方法： 結構化方法(SASD)面向數據結構方法(OSD)面向對象方法(OO)第二章

1．在軟件開發的早期階段為什么要進行可行性研究？

z 可行性研究的目的：就是用最小的代價在盡可能短的時間內確定問題是否能夠解決。

2.可行性研究的任務？應該從哪方面研究目標系統的可行性？

可行性研究的任務： 1.進一步分析和澄清問題； 2.導出系統的邏輯模型；

3.從邏輯模型出發，提出若干種系統實現方案

4.研究每種實現方案的可行性：

z 技術上的可行性 ——使用現有的技術能實現這個系統嗎？

z 經濟上的可行性 —這個系統的經濟效益能超過它的開發成本嗎（投資與效益）z 操作可行性 ——系統的操作方式在這個用戶組織內行得通嗎？ z 社會、政策允許的可行性

5.為每個可行的解決方案制定一個粗略的實現進度 6.對以后的行動方針提出建議

3．數據詞典（DD）的定義、組成、用途、例子：

（1）定義：描述數據流圖中數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。它對數據流圖上每一個成分：數據項、文件(數據結構)、數據流、數據存儲、加工和外部項等給以定義和說明；（2）組成：由數據流、數據流分量（即數據元素）、數據儲存、處理四部分組成。對用戶來講,數據字典為他們提供了數據的明確定義；對系統分析員來講,數據字典幫助他們比較容易修改已建立的系統邏輯模型

（3）用途：

a.作為分析階段的工具，與數據流圖共同來完整的描述一個系統。數據流圖只描述了系統的邏輯模型，但是沒有給出數據及各個加工處理過程的具體含義；而數據字典則是其有益的補充。

b.數據字典中包含的每個數據元素的控制信息是很有價值的。c.開發數據庫的基礎。（4）例子：

4．可行性研究報告的主要內容/步驟？ 可行性分析的結果是可行性研究報告,內容包括：

(1)系統概述：說明開發的系統名稱,提出單位和開發單位。(2)可行性研究的前提:系統目標；要求；約束和限制；可行性研究的基本準則等。(3)對現有系統的分析:處理流程，圖示說明現有系統的處理流程和數據流程；現有系統存在的問題。(4)系統需求:主要功能；主要性能及其要求；操作要求；信息要求；限制性要求。(5)建議系統:系統目標；處理流程；系統結構,功能,性能；系統技術可行性；投資和效益分析；操作可行性；法律可行性。(6)其它可選方案:與國內外同類型方案的比較；提出一兩個可行性方案供論證和探討。

(7)制定下一階段的預算。

(8)結論性意見：由用戶方、設計方和投資方共同簽署意見。5．可行性研究過程的步驟/怎樣進行可行性研究?(1)復查系統規模和目標

（2）研究目前正在使用的系統

（3）導出新系統的高層邏輯模型（4）進一步定義問題

（5）導出和評價供選擇的解法（6）推薦行動方針（7）草擬開發計劃（8）書寫文檔提交審查 6．系統流程圖：

基本符號

系統符號

7.數據流圖（DFD）：是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程中所經受的變換

8.數據流圖的用途：(1)作為交流信息的工具(2)作為分析和設計的工具 9.計算機儲蓄系統。儲戶填寫的存款單或者取款單由業務員輸入系統，如果是存款，系統記錄存款人姓名、住址、存款類型、存款日期、利率等信息，并印出存款單給儲戶；如果是取款，系統計算利息并印出利息清單給儲戶。寫出問題定義并分析此系統的可行性。

10.機票預訂系統。旅行社把預訂機票的旅客信息（姓名、性別、工作單位、身份證號碼、旅行時間、旅行目的地等）輸入進該系統，系統為旅客安排航班，印出取票通知和賬單，旅客在飛機起飛的前一天憑取票通知和賬單交款取票，系統校對無誤即印出機票給旅客。

寫出問題定義并分析此系統的可行性。

11．成本/效益分析：

第三章

1．需求分析的基本任務是什么? 準確定義未來系統的目標，確定為了滿足用戶的需要系統必須做什么 需求分析的8大任務：

（1）功能需求（2）性能需求（3）可靠性和可用性需求（4）出錯處理需求（5）接口需求（6）約束（7）逆向需求（8）將來可能提出的要求 2．導出系統的邏輯模型，通常用：數據流圖、實體聯系圖、狀態轉換圖、數據字典、和主要的算法描述這個邏輯模型。3.與用戶溝通獲取需求的方法：

（1）訪談、分發調查表、情景分析技術（2）面向數據流自頂下下求精（3）簡易的應用規格說明書（4）快速建立軟件原型

4．訪談分類：正式的訪談、非正式的訪談

5．情景分析技術的用處主要體現在以下兩個方面：

（1）它能在某種程度上演示目標系統的行為，從而便于用戶解釋，而且還可以進一步揭示出一些分析員目前還不知道的需求。

（2）由于情景分析較易為用戶所理解，使用這種技術能保證用戶在需求分析的過程中始終扮演一個積極主動的角色。6．（1）結構化分析方法：就是面向數據流自頂向下逐步求精進行需求分析的方法。（2）結構化分析實質上是一種創建模型的活動。

（3）根據結構化分析準則，需求分析過程應該建立3種模型: 數據模型、功能模型、行為模型

（4）實體-聯系圖（ERD）描繪數據對象及數據對象之間的關系，用于建立數據模型的圖形。

（5）數據流圖描繪數據在軟件中移動時被變換的邏輯過程，指明系統具有的變換數據的功能，數據流圖是建立功能模型的基礎。

（6）狀態轉換圖（狀態圖STD）指明作為外部事件結果的系統行為。狀態轉換圖描繪系統的各種行為模式和在不同狀態間轉換的方式。狀態轉換圖是行為建模的基礎。

7．從哪些方面驗證軟件需求的正確性？

一致性、完整性、現實性、有效性 8.驗證軟件需求的的方法：

（1）驗證需求的一致性：軟件工具

（2）驗證需求的現實性：仿真或性能模擬技術

（3）驗證需求的完整性和有效性：只有在用戶的密切合作下才能完成 9.需求分析的描述工具有哪些?

有數據流圖、數據字典、判定表、判定樹、結構化自然語言、層次方框圖、Warnier圖、IPO圖和需求描述語言等

第五章、總體設計(系統設計+概念設計)1．總體設計的組成：系統設計階段——確定系統的具體實現方案

具體實現方案：結構設計階段——確定軟件結構

設計的目的/標：在于形成軟件的一種層次的可對底層結點交叉引用的模塊化結構 2．總體設計過程9個步驟：

（1）設想供選擇的方案（2）選取合理的方案（3）推薦最佳方案（4）功能分解（5）設計軟件結構（6）設計數據庫（7）知道測試計劃（8）書寫文檔（9）審查和復審

3．書寫文檔時通常有以下幾種？

（1）系統說明：主要內容包括系統流程圖描繪的系統構成方案，組成系統物理元素清單，成本/效益分析；對最佳方案的概括描述，精化的數據流圖，用層次圖或結構圖描繪的軟件結構，用IPO圖或其他工具簡要描述的各個模塊的算法，模塊間的接口關系，以及需求、功能、模塊三者之間的交叉參照關系等（2）用戶手冊

根據總體設計階段的結果，修改更正正在需求分析階段產生的初步的用戶手冊

（3）測試計劃 包括測試策略，測試方案，預期的測試結果，測試進度計劃（4）詳細的實現計劃（5）數據庫設計結果

4．（1）設計原理：

模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨立（2）抽象(Abstraction)：解決問題時只考慮與問題有關的方面，不考慮與問題無關的方面。即抽出事物的本質特性而不考慮細節

（3）逐步求精定義：

為了能集中精力解決主要問題而盡量推遲對問題細節的考慮。人類解決復雜問題時采用的基本方法，也是許多軟件工程技術(例如，規格說明技術，設計和實現技術)的基礎 作用：

幫助軟件工程師把精力集中在與當前開發階段最相關的那些方面上忽略那些對整體解決方案來說雖然是必要的，然而目前還不需要考慮的細節，這些細節將留到以后再考慮（4）信息隱蔽的含義：

有效的模塊化可以通過定義一組獨立模塊來實現，這些模塊相互之間只交流軟件功能必需的信息。

目的： 提高模塊的獨立性，減少修改或維護時的影響面。（5）信息局部化：把關系密切的軟件元素物理地放得彼此靠近。

優點：可維護性好、可靠性好、可理解性好 5．模塊化(Modularity)？模塊設計的準則？

是按規定的原則將一個大型軟件劃分為一個個較小的、相對獨立但又相關的模塊。準則：

(1)改進軟件結構, 提高模塊獨立性:在對初步模塊進行合并、分解和移動的分析、精化過程中力求提高模塊的內聚，降低藕合。

(2)模塊大小要適中:大約50行語句的代碼，過大的模塊應分解以提高理解性和可維護性;過小的模塊,合并到上級模塊中。

(3)軟件結構圖的深度、寬度、扇入和扇出要適當。一般模塊的調用個數不要超過5個。

(4)盡量降低模塊接口的復雜程度；(5)設計單入口、單出口的模塊。

(6)模塊的作用域應在控制域之內：

6．模塊？特征？總體設計主要考慮什么特征？

（1）模塊是數據說明、可執行語句等程序對象的集合，可以單獨命名且可通過名字來訪問。

（2）模塊具有輸入和輸出(參數傳遞)、功能、內部數據結構(局部變量)和程序代碼四個特性。

（3）概要設計主要考慮輸入、輸出(參數傳遞)和功能兩個特性

7.模塊獨立：的概念是模塊化、抽象、信息隱藏、局部化概念的直接結果 特點：具有特定子功能、接口簡單

衡量標準： 1.耦合：亦稱塊間聯系，衡量不同模塊間相互依賴的緊密程度，為獨立性的直接衡量。2.內聚：亦稱塊內聯系，模塊內各部分(語句或段落)之間結合的緊密程度。

耦合性是模塊間相互依賴程度的度量，耦合的強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。（耦合性越高，模塊獨立性越弱）耦合強度依賴的因素：

一模塊對另一模塊的引用

一模塊向另一模塊傳遞的數據量 一模塊施加到另一模塊的控制的數量 模塊間接口的復雜程度

去除模塊間控制耦合的方法：

(1)將被調用模塊內的判定上移到調用模塊中進行(2)被調用模塊分解成若干單一功能模塊 如何降低模塊間耦合度：

(1)如模塊必須存在耦合，選擇適當的耦合類型原則：

盡量使用數據耦合 少用控制耦合

限制公共耦合的范圍

堅決避免使用內容耦合(2)降低模塊間接口的復雜性

內聚性：

一個模塊內部各成分之間相互關聯的強度

耦合、內聚與模塊獨立性關系

耦合與內聚都是模塊獨立性的定性標準，都反映模塊獨立性的良好程度。但耦合是直接的主導因素，內聚則輔助耦合共同對模塊獨立性進行衡量。8.啟發規則：

（1）改進軟件結構提高模塊獨立性（2）模塊規模應該適中

（3）寬度、深度、扇出、扇入都應適當（4）模塊的作用域應該在控制域之內（5）力爭降低模塊接口的復雜程度（6）設計單入口單出口的模塊（7）模塊功能應該可以預測 名稱解釋：

（1）深度：表示軟件結構中控制的層數，粗略的標志了一個系統的大小和復雜程度（2）寬度：軟件結構內同一個層次上的模塊總數的最大值。一般來說，寬度越大系統越復雜。對寬度影響最大的因素是模塊的扇出。

（3）扇出：是一個模塊直接控制（調用）的模塊數模，扇出過大意味著模塊過分復雜，需要控制盒協調過多的下級模塊。

9.描繪軟件結構的圖形工具：

（1）層次圖(Hierarchy圖)和HIPO圖（帶編號）（2）結構圖（SC）

10.（1）IPO圖——是輸入、處理、輸出圖的簡稱，它是美國IBM公司發展完善起來的一種圖形工具，能夠方便地描繪輸入數據、對數據的處理和輸出數據之間的關系。（2）IPO圖的基本形式是：

A.在左邊的框中列出有關的輸入數據，B.在中間的框內列出主要的處理，C.在右邊的框內列出產生的輸出數據。11.層次圖和結構圖小結

1、層次圖和結構圖并不嚴格表示模塊的調用次序。多數人習慣于按調用次序從左到右畫模塊，但并沒有這種規定，出于其他方面的考慮，例如為了減少交叉線，也完全可以不按這種次序畫。

2、層次圖和結構圖并不指明什么時候調用下層模塊。

3、層次圖和結構圖只表明一個模塊調用那些模塊，至于模塊內還有沒有其他成分則完全沒有表示。12.面向數據流的設計方法

（1）面向數據流的設計方法是把信息流映射成軟體結構，信息流的類型決定了映射的方法。（2）信息流的兩種類型：變換流

事務流

（3）事務流/事務中心完成的任務：接收輸入數據

分析每個事務以確定它的類型

根據事務類型選取一條活動通路（4）面向數據流方法的設計過程：

（5）設計步驟：

1復查基本系統模型

○2復查并精華數據流圖

○3確定數據流圖具有變換特性還是事務特性

○4確定輸入流和輸出流的邊界，從而孤立出變換中心

○5完成“第一級分解”

○6完成“第二級分解”

○7使用設計度量和啟發式規則對第一次分割得到的軟件結構進一步精化

○（6）設計步驟的目的：開發出軟件的整體表示。即一旦確定了軟件結構就可以把它作

為一個整體來復查，從而能夠評價和精化軟件結構

（7）概要設計與詳細設計的區別

——概要設計就是設計軟件的結構，包括組成模塊，模塊的層次結構，模塊的調用關系，每個模塊的功能等等。同時，還要設計該項目的應用系統的總體數據結構和數據庫結構，即應用系統要存儲什么數據，這些數據是什么樣的結構，它們之間有什么關系。——詳細設計階段就是為每個模塊完成的功能進行具體的描述，要把功能描述轉變為精確的、結構化的過程描述。

第六章、詳細設計

1．程序（過程）設計工具

1.程序流程圖

2.盒圖(N-S圖)

3.問題分析圖(PAD)4.過程設計語言(PDL)(偽碼)

5.判定表

2．詳細設計工具：(1)圖形工具(2)表格工具

(3)語言工具 3．結構程序設計？

（1）完成軟件模塊過程設計的一種重要技術

（2）所有程序都可以建立在一組已有的邏輯構成元素上，這一組邏輯構成元素強調了“對功能域的維護”。

（3）這些邏輯構成元素是結構化程序設計的基礎。4．程序流程圖/程序框圖

缺點：（1）誘使程序員過早的考慮程序的控制流程，而不去考慮程序的全局結構

（2）在程序流程圖中用箭頭表示控制流，因此控制員不受任何約束，可以完全不顧結構程序設計的精神，隨意轉移控制（3）程序流程圖不易表示數據結構

5．盒圖(N-S圖)

特點：（1）功能域明確，可以從盒圖上一眼就能看出來

（2）不可能任意轉移控制

（3）很容易確定局部和全程數據的作用域

（4）很容易表現嵌套關系，也可表示模塊的層次結構

6．問題分析圖(PAD圖)

優點：（1）使用表示結構化控制結構的PAD符號所設計出來的必然是結構化程序

（2）PAD圖所描繪的程序十分清晰

（3）用PAD圖變現程序邏輯，易讀，易懂，易記

（4）PAD圖的符號支持自頂向下、逐步求精方法的使用

（5）容易將PAD圖轉換成高級語言源程序

（6）即可用于表示程序邏輯，也可用于描述數據結構

7.過程設計語言(PDL)(偽碼)特點：

（1）關鍵字的固定語法，它提供了結構化控制結構、數據說明和模塊化的特點

（2）自然語言的自由語法，它描述出來特點

（3）數據說明的手段

（4）模塊定義和調用的技術，應該提供各種接口描述模式 作為設計工具的優點：

（1）可以作為注釋直接插在源程序中間

（2）可以使用普通的正文編輯程序或文字處理系統，很方便的完成PDL的書寫和編輯工作

（3）已經有自動處理PDL的程序存在，而且可以自動有PDL生產程序代碼

缺點：不如圖形工具形象直觀，描述復雜的條件組合與動作之間的對應關系時，不如判斷表清晰簡單

8.判定表

組成：左上部列出所有條件、左下部是所有可能做的動作、右上部是表示各種條件組合的一個矩陣、右下部是和每種條件組合相對應的動作

9.判斷樹

優點：形式簡單到不需任何說明，一眼就可以看出其含義，易于掌握和利用。10.結構程序設計方法

Jackson圖

程序復雜程度的定量度量:McCabe方法

第七章

1． 2．

3． 4．

第八章

1．軟件維護定義：就是在軟件已經交付使用后，為了改正錯誤或滿足新的需求而修改軟件的過程

2．軟件維護的類型：改正性維護、適應性維護、完善性維護、預防性維護

第九章

1． 2．

3．4．

第十章

1． 2．

3．4．

第二篇：軟件工程總結

軟件工程課程總結

摘要：

計算機是20世紀最重大的科學技巧成就之一，使當代社會的經濟、軍事、科研、教育、服務等方面在概念和技巧上發生了性的變化，對人類社會的進步已經并還將產生極為深刻的影響。目前，計算機是世界各發達國度劇烈競爭的科學技巧領域之一。

電子計算機早期功效主要是計算，后來已遠遠超越單純計算的功效，還可模擬、思維、進行自適應反饋處理等等，把它叫做“電腦”更為合實際。由于電子計算機功效的飛躍性發展，應用于生產和生活的各個方面，直接和顯著地提高了生產、工作和生活的效率、節奏和水平，在軟科學研究和應用中它也起著關鍵作用，因此它已被公認是現代技巧的神經中樞，是未來信息社會的心臟和錄魂。計算機學科分為四個領域，分別是計算機科學，計算機工程，軟件工程和信息系統。

正文：

軟件工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。包括項目管理，分析，設計，程序的編寫，測試和質量控制。它涉及到程序設計語言、數據庫、軟件開發工具、系統開發平臺、標準、設計模式等方面。

學了《軟件工程》這門課程和一些有關資料后，感覺一些東西都曾經接觸過，但在實際工作中有些理論要完全遵循可能還有些障礙，軟件工程只是提供了理論上的一些結論，但對項目的具體可操作性的規范的制定方面卻做的很少，《軟件工程》發展了幾十年，光是開發模型就達到了10多種，對不同的項目采用合適的開發模式，有些項目在不同的開發階段可能還要轉換開發模式，把它們靈活的應用到實際中還是很困難的。

軟件技術是信息技術產業的核心之一，軟件技術的發展是與信息技術產業的發展互相促進的。當今世界，信息技術正處于新一輪重大技術突破的前夜。預計今后 20~30 年是信息科學技術的變革突破期，可能導致 21 世紀下半葉一場新的信息技術革命。近年來，從 IT 界到一些國家首腦，都高度關注以物聯網為標志的新一輪信息技術的發展態勢，認為這是繼 20 世紀 80 年代 PC 機、90 年代互聯網、移動通信網之后，將引發 IT 業突破性發展的第三次 IT 產業化浪潮。每一次重大的技術變革都會引起企業間、產業間甚至國家間競爭格局的重大變化，也促進了軟件技術與軟件產業的重大變革與發展。

近年來，信息技術、軟件技術、軟件系統與軟件產業的發展備受關注，已有不少論述、分析與判斷。近10 年內網絡技術經歷寬帶化、移動化和三網融合將走向基于 Ipv6 的下一代互聯網，2010 年 1 月，國家 863 計劃信息技術領域辦公室和國家 863 計劃信息技術領域專家組，在上海舉辦“信息-物理融合系統 CPS發展戰略論壇”，提出“信息-物理融合系統 CPS 是一個綜合計算、網絡和物理環境的多維復雜系統，是信息和物理世界的深度的融合交互，可實現大型工程系統的實時感知、動態控制和信息服務，使系統更加可靠、高效與實時協同，使得人類物理現實和虛擬邏輯逐步融合，具有重要而廣泛的應用前景。業界關于軟件工程的代表性觀點創立與使用健全的工程原則，以便經濟地獲得可靠且高效率的軟件。應用系統化，遵從原則，可被計量的方法來發展、操作及維護軟件；也就是把工程應用到軟件上。與開發、管理及更新軟件產品有關的理論、方法及工具。一種知識或學科，目標是生產品質良好、準時交貨、符合預算，滿足用戶所需的軟件。實際應用科學知識在設計、建構電腦程序，與相伴而來所產生的文件，以及后續的操作和維護上。

6使用與系統化生產和維護軟件產品有關之技術與管理的知識，使軟件開發與修改可在有限的時間與費用下進行。

7建造由工程師團隊所開發之大型軟件系統有關的知識學科。對軟件分析、設計、實施及維護的一種系統化方法。系統化地應用工具和技術于開發以計算機為主的應用。

10軟件工程是關于設計和開發優質軟件。

《軟件工程》是一門綜合性和實踐性很強的核心課程，它屬于是一門交叉學科，包含有：軟件開發技術（軟件開發方法學、軟件開發過程、軟件工具和軟件工程環境）、軟件工程管理（軟件管理學、軟件經濟學、軟件心理學）。主要內容包括軟件工程概述、可行性分析、需求分析、概要設計、詳細設計、面向對象分析與設計、編碼、軟件測試、項目計劃與管理。

本課程是面向準備從事軟件開發的畢業生而開設的一門專業課程。針對計算機教學中軟件工程這一薄弱環結，結合目前軟件開發商對人才的要求，對計算機專業的畢業生進行軟件工程強化培訓，目的是使畢業生能夠了解和掌握軟件工程的基本理論和方法，并在實際軟件開發中運用這些方法。

我理解，軟件工程是按照工程學的管理方式，有組織、有計劃的，在一定的質量基礎、時間限度和成本范圍內，實現功能明確的軟件系統。而且，軟件工程在企業范圍內運行，一定需要企業資源的支持，要與企業的經營、決策、管理體系聯系在一起，才能夠被踏踏實實的落實下來。

軟件工程項目是一個需要一步一步的計算，分析思考而來的，需要不斷思考，研究不斷進步，軟件業作為一個服務業，要想得到發展，首先必須形成一個對軟件服務有迫切需要的市場。其次，這個市場中的消費者必須具備足夠的購買力。軟件的消費群體簡單一點，可以分為個體消費和企業消費。中國的企業群體，數量龐大，但是質量不高。上規模的企業極少。國內目前能夠形成比較大規模的獨立市場的，肯定是小規模的軟件系統。

隨著信息化時代的到來其地位越來越受到人們的重視，軟件工程從一個學科，或是某一個研究方向來說，人員僅僅是過程，方法的執行者，所以人員素質往往被忽略，軟件工程是一門實踐性很強的學科，所以在實際的軟件研究過程中，人員的素質占有很重要的地位。要有出色的軟件問世，研發人員的素質至關重要！

作為軟件工程的學習者應該不斷創新，不斷嘗試、實踐，不斷研究和學習，中國的軟件工程技術依舊滯后于國外一些軟件工程技術，作為新一代的學習者應該擔當起振興起中國軟件事業，使中國科技得到高速發展！

現在已經是信息化時代，信息化潮流不斷涌現，想要掌握主動權就是掌握信息化的發展方向，這就需要我們不斷學習，時間，研究，學習國外的先進技術，轉變自己的技術，然后融合，創新。

軟件技術不是一成不變的，是隨著社會的進步的不斷進步，不需要不斷的創新，不斷的改善的，需要我們不斷的學習，不斷的研究，不斷進步。

第三篇：軟件工程總結

1.Software is a product and can be manufactured using the same technologies used for other engineering artifacts Answer: b 2.WebApps are a mixture of print publishing and software development, making their development outside the realm of software engineering practice.Answer: b 3.Software engineering umbrella activities are only applied during the initial phases of software development projects.Answer: b 4.Planning ahead for software reuse reduces the cost and increases the value of the systems into which they are incorporated.Answer: a 5.The essence of software engineering practice might be described as understand the problem, plan a solution, carry out the plan, and examine the result for accuracy.Answer: a 6.In agile process models the only deliverable work product is the working program.Answer: b 7.A most software development projects are initiated to try to meet some business need.Answer: a 8.In general software only succeeds if its behavior is consistent with the objectives of its designers.Answer: b 9.Software processes can be constructed out of pre-existing software patterns to best meet the needs of a software project.Answer: a 10.Process technology tools allow software organizations to compress schedules by skipping unimportant activities.Answer: b 11.It is generally accepted that one cannot have weak software processes and create high quality end products.Answer: a 1.Requirements engineering is a generic process that does not vary from one software project to another.Answer: a 2.A stakeholder is anyone who will purchase the completed software system under development.Answer: b 3.It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one.Answer: a 4.Developers and customers create use-cases to help the software team understand how different classes of end-users will use functions.Answer: a 5.Use-case actors are always people, never system devices.Answer: b 6.Analysis patterns facilitate the transformation of the analysis model into a design model by suggesting reliable solutions to common problems.Answer: a 7.In win-win negotiation, the customer’s needs are met even though the developer’s need may not be.Answer: b 8.In requirements validation the requirements model is reviewed to ensure its technical feasibility.Answer: b

1.Object-oriented domain analysis is concerned with the identification and specification of reusable capabilities within an application domain.Answer: a 2.In structured analysis models focus on the structure of the classes defined for a system along with their interactions.Answer: b 3.Creation and refinement of use cases if an important part of scenario-based modeling.Answer: a 4.It is important to consider alternative actor interactions when creating a preliminary use case.Answer: b 5.Brainstorming is one technique that may be used to derive a complete set of use case exceptions.Answer: a 6.In many cases there is no need to create a graphical representation of a usage scenario.Answer: a 7.One or more attributes of a data object must be defined as a key to allow the location of an instance of the data object.Answer: a 8.Attributes are chosen for an object by examining the problem statement and identifying the entities that appear to be related.Answer: b 9.An analysis package involves the categorization of analysis model elements into useful groupings.Answer: a 10.The data flow diagram must be augmented by min-spec that can serve as a guide the design of the software component that will implement the process.Answer: a 11.The UML sequence diagram show the order in which system events are processed.Answer: b 12.Analysis patterns are discovered, they are not explicitly created.Answer: a 13.It is not possible to justify the time required for WebApp requirements analysis.Answer: b 14.UML activity diagrams can be used to represent the user observable functionality delivered by the WebApp as well as the operations contained in each analysis class.Answer: a 15.Configuration analysis focuses on the architecture of the user’s web browsing environment.Answer: b 16.Content objects are extracted from use cases by examining the scenario description for direct or indirect content references.Answer: a 1.With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.Answer: b 2.Program flow graphs are identical to program flowcharts.Answer: b 3.The cyclomatic complexity of a program can be computed directly from a PDL representation of an algorithm without drawing a program flow graph.Answer: a 4.Graph-based testing methods can only be used for object-oriented systems Answer: b 5.Equivalence testing divides the input domain into classes of data from which test cases can be derived to reduce the total number of test cases that must be developed.Answer: a 6.Boundary value analysis can only be used to do white-box testing.Answer: b 7.Orthogonal array testing enables the test designer to maximize the coverage of the test cases devised for relatively small input domains.Answer: a 8.Client/server architectures cannot be properly tested because network load is highly variable.Answer: b 1.The best representation of system architecture is an operational software prototype.Answer: b 2.The architectural representations can be an enabler for communication among project stakeholders.Answer: a 3.An architectural description is often documented using an architecture template.Answer: b 4.An architectural genre will often dictate the architectural approach that may used for the structure to be built.Answer: a 5.Before an architectural pattern can be chosen for use in a specific system it must have a code implementation to facilitate its reuse.Answer: b 6.Once selected, archetypes always need to be refined further as architectural design proceeds.Answer: a 7.Quantitative methods for assessing the quality of proposed architectural designs are readily available.Answer: b

Chapter 10 Self-Check Quiz

1.In the most general sense a component is a modular building block for computer software.a.True b.False

Answer: a(Section 10.1)

2.In the context of object-oriented software engineering a component contains

a.attributes and operations b.instances of each class c.roles for each actor(device or user)d.set of collaborating classes

Answer: d(Section 10.1.1)

3.In traditional software engineering modules must serve in which of the following roles?

a.Control component b.Infrastructure component c.Problem domain component d.All of the above

Answer: d(Section 10.1.2)

4.Software engineers always need to cerate components from scratch in order to meet customer expectations fully.a.True b.False

Answer: b(Section 10.1.3)

5.Which of the following is not one of the four principles used to guide component-level design?

a.Dependency Inversion Principle b.Interface Segregation Principle c.Open-Closed Principle d.Parsimonious Complexity Principle

Answer: d(Section 10.2.1)

6.The use of stereotypes can help identify the nature of components at the detailed design level.a.True b.False

Answer: a(Section 10.2.2)

7.Classes and components that exhibit functional, layer, or communicational cohesion are relatively easy to implement, test, and maintain.a.True b.False

Answer: a(Section 10.2.3)

8.Software coupling is a sign of poor architectural design and can always be avoided in every system.a.True b.False

Answer: b(Section 10.2.4)

9.WebApp content design at the component level focuses on content objects and the manner in which they interact.a.True b.False

Answer: b(Section 10.4.1)

10.A WebApp functional architecture describes the key functional components and how they interact with each other.a.True b.False

Answer: a(Section 10.4.2)

11.Which of these is a graphical notation for depicting procedural detail?

a.box diagram b.decision table c.ER diagram d.flowchart

Answer: d(Section 10.5.1)

12.A decision table should be used

a.to document all conditional statements b.to guide the development of the project management plan c.only when building an expert system d.when a complex set of conditions and actions appears in a component

Answer: d(Section 10.5.2)

13.A program design language(PDL)is often a

a.combination of programming constructs and narrative text b.legitimate programming language in its own right c.machine readable software development language d.useful way to represent software architecture

Answer: a(Section 10.5.3)

14.In component-based software engineering, the development team examines the requirements to see which are amenable to composition, rather than construction, before beginning detailed design tasks.a.True b.False

Answer: a(Section 10.6)

15.Which of the following is not one of the major activities of domain engineering?

a.analysis b.construction c.dissemination d.validation

Answer: d(Section 10.6.1)

16.Which of the following factors would not be considered during component qualification?

a.application programming interface(API)b.development and integration tools required c.exception handling d.testing equipment required

Answer: d(Section 10.6.2)

17.Which is the following is a technique used for component wrapping?

a.black-box wrapping b.clear-box wrapping c.gray-box wrapping d.white-box wrapping

Answer: b(Section 10.6.2)

18.Which of the following is not one of the issues that form a basis for design for reuse?

a.object-oriented programming b.program templates c.standard data d.standard interface protocols

Answer: a(Section 10.6.3)

19.In a reuse environment, library queries are often characterized using the ________ element of the 3C Model.a.concept b.content c.context d.all of the above

Answer: c(Section 10.6.4)

1.The importance of software design can be summarized in a single word a.b.c.d.Answer: d(Section 8.1)

2.Which of the following is not a characteristic common to all design methods?

a.configuration management b.functional component representation c.quality assessment guidelines d.refinement heuristics

Answer: a(Section 8.2.2)

3.Which of the following can be used to represent the architectural design of a piece of software?

a.Dynamic models b.Functional models c.Structural models d.All of the above

Answer: d(Section 8.3.2)

4.Design patterns are not applicable to the design of object-oriented software?

a.True b.False

Answer: b(Section 8.3.3)

5.Since modularity is an important design goal it is not possible to have too many modules in a proposed design.a.True b.False

Answer: b(Section 8.3.5)

6.Information hiding makes program maintenance easier by hiding data and procedure from unaffected parts of the program.accuracy complexity efficiency quality

a.True b.False

Answer: a(Section 8.3.6)

7.Cohesion is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: b(Section 8.3.7)

8.Coupling is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: d(Section 8.3.7)

9.When using structured design methodologies the process of stepwise refinement is unnecessary.a.True b.False

Answer: b(Section 8.3.8)

10.Software designs are refactored to allow the creation of software that is easier to integrate, easier to test, and easier to maintain.a.True b.False

Answer: a(Section 8.3.10)

11.Which of the following is not one of the five design class types

a.Business domain classes b.Entity classes c.Process classes d.User interface classes

Answer: b(Section 8.3.13)

12.Which design model elements are used to depict a model of information represented from the user’s view?

a.Architectural design elements b.Component-level design elements c.Data design elements d.Interface design elements

Answer: c(Section 8.4.1)

13.Which design is equivalent to the floor plan of a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: a(Section 8.4.2)

14.Which design model is equivalent to the detailed drawings of the access points and external utilities for a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: d(Section 8.4.3)

15.Which design model is equivalent to a set of detailed drawings for each room in a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: b(Section 8.4.4)

16.The deployment design elements specify the build order for the software components.a.True b.False

Answer: b(Section 8.4.5)

第四篇：軟件工程總結

第一章軟件與軟件工程的概念

軟件的概念：軟件是計算機系統中與硬件相互依存的另一部分，軟件包括程序，數據，及其相關文檔的完整集合。程序是按事先設計的功能和性能要求執行的指令序列。數據是使程序能夠正確地處理信息的數據結構。文檔是與程序開發，維護和使用有關的圖文資料。

程序的最小單位是函數及子程序，程序與數據是分離的，在面向對象程序設計時代，程序的最小單位是類，在類中封裝了相關的數據及指令代碼。

軟件的特性，判斷正誤：1.軟件是無形的、不可見的邏輯實體，因此，軟件是無法描述的。（錯）

2、軟件的開發特性是指軟件需要大量手工勞動，難以自動化生產。（對）

3、有缺陷的軟件就是廢品。（錯）

4、軟件的生產指的是軟件的復制。（錯）

5、由于軟件的開發充滿人的個性特點，因此管理并不決定軟件開發的成敗（錯）。

6、軟件的開發環境往往就是軟件的運行環境，或者與其兼容。（對）

7、合格的軟件產品不需要維護，軟件需要維護說明其質量不合格。（錯）

8、軟件可以不斷改進，因此軟件不需要廢棄。（錯）

軟件的分類：1，系統軟件：能與計算機硬件緊密配合在一起，使計算機系統各個部件，相關的軟件和數據協調，高效的工作的軟件。2，應用軟件，是在系統軟件的支持下，在特定區域內開發，為特定目的服務的一類軟件。3，支撐軟件，也叫工具軟件，是協助用戶開發軟件的工具性軟件。4，可復用軟件，最初實現的典型的可復用軟件是各種標準函數庫，通常是由計算機廠商提供的系統軟件的一部分。

IEEE給出的定義：軟件工程是開發，運行，維護和修復軟件的系統方法。軟件的定義：計算機程序，方法，規則，相關的文檔資料一集在計算機上運行時所必需的數據。

軟件危機的典型表現

1、成本太高，預算不準

2、超過預計時間

3、軟件質量標準不明確

4、生產率低

5、缺乏文檔資料，難以維護。原因：1，缺乏軟件開發的經驗和有關軟件開發數據的積累，使得開發工作的計劃很難制定。2.軟件人員與用戶的交流存在障礙，除了知識背景的差異，缺少合適的交流方法及需求描述工具。3，軟件開發過程不規范，缺少方法和規范的指導。4，隨著軟件規模的增大，其復雜性往往會呈指數級升高。5，缺少有效的軟件評測手段，提交用戶的軟件質量差。

軟件危機發生的主要原因有：

1、遇到了無法解決的高難度技術問題（不是）

2、無法招聘到足夠的編程高手（不是）

3、軟件人員與用戶互相不理解（是）

4、計劃和管理不科學、落實不力（是）

5、軟件質量標準不明確（是）

軟件的質量特性包括（選擇）問題1：

1、功能性

2、可靠性

3、使用性

4、經濟性（不包括）

軟件的質量特性包括（選擇）問題2：

1、效率

2、可維護性

3、可移植性

4、經濟性（不包括）

軟件工程的目標是運用先進的軟件開發技術和管理方法來提高軟件的質量和生產率，也就是要以較短的周期，較低的成本生產出高質量的軟件產品，并最終實現軟件的工業化生產。軟件生存期：軟件的孕育，誕生，成長，成熟，衰亡的生存過程。軟件生存期由軟件定義，軟件開發和運行維護三個時期組成，每個時期又可劃分為若干個階段。

2、軟件定義時期的任務主要任務是解決“做什么”的問題，確定工程的總目標和可行性；實現工程目標的策略及系統功能；估計需要的資源和成本；制訂工程進度表。通常又分為3個階段：問題定義，可行性研究，需求分析。

3、軟件開發時期的任務和包含階段主要任務是解決“如何做”的問題，設計和實現定義的軟件。由概要設計、詳細設計、編碼和測試4個階段組成。

4、軟件運行維護時期的主要任務是使軟件持久地滿足用戶的需要，通常有4類維護活動：改正性維護；適應性維護；完善性維護；預防性維護。開發過程中的典型文檔：軟件需求規格說明書。項目計劃。軟件測試計劃。軟件設計說明書。用戶手冊。軟件工程各個階段的基本任務

1、問題定義與可行性研究：解決什么問題？能否解決問題？是否值得做？”

2、需求分析：做什么

3、軟件設計：如何實現

4、程序編碼和單元測試：實現設計

5、集成和系統測試：組裝連接測試、功能驗證測試

6、軟件運行和維護：修改 第二章軟件工程方法與工具

軟件工具：是指能支持軟件生存周期中某一階段（如系統定義，需求分析，設計，編碼，測試，維護等）的需要而使用的軟件工具。

需求分析工具

1、結構化圖形工具箱。通過數據流程圖DFD進行功能分析。包括DFD圖形工具，實體-關系圖(E-R)圖形工具，Jackson圖形工具，Warnier圖形工具，Visio綜合工具，2、面向對象工具，Rational Rose，PowerDesigner，Visio 設計工具（1)概要設計工具：設計目標軟件的體系結構、控制結構和數據結構。軟件的體系結構通常用模塊結構圖來描述。模塊的數據結構通常用實體-關系圖來描述。Visio。Rational Rose 詳細設計工具。設計模塊的算法和內部實現細節。詳細設計描述方法有輸入-處理-輸出(IPO)圖。問題分析圖(PAD)。盒圖(NS圖)。流程圖(FC)。程序設計語言(PDL)。結構化語言。判定表。判定樹

第三章軟件需求獲取與結構化分析方法 需求獲取的主要任務是與用戶溝通，了解系統或產品的目標是什么，客戶或用戶想要實現什么，系統和產品如何滿足業務的要求，最終系統或產品如何用于日常工作。獲取并理解用戶的需求是軟件工程師所面對的最困難的任務之一。

需求分析的困難體現：系統的目標或范圍問題；需求不準確性問題；需求的易變問題

需求獲取的任務：發現和分析問題，并分析問題的原因，結果關系。與用戶進行各種方式的交流，并使用調查研究方法收集信息。按照三個成分即數據，過程和接口觀察問題的不同側面。將獲取的需求文檔化，形式有用例，決策表，決策樹等。需求獲取的原則：深入淺出，以流程為主線。

獲取具體的需求的途徑1，與用戶交流。2，現有產品或競爭產品的描述文檔。3，系統需求規格說明。4，當前系統的問題報告和改進要求。5，市場調查和用戶問卷調查。6，觀察用戶如何工作。

關于需求獲取問題的認識辨析：

1、沒有與用戶交流就不可能獲取系統需求。（不能獲取準確、全面的系統需求）

2、沒有經過與用戶交流而獲取的需求都是不真實的需求。（一些需求從用戶以外的途徑獲取）

3、系統開發必須獨立完成，參考類似系統及技術文檔屬于抄襲行為，應予避免。（系統開發包含研究行為，應了解對手產品，取長補短）

4、系統開發包含改進當前系統的缺陷和不足。（對）

5、需求調查時，用戶所說的需求未必是真實、準確的需求，因此需求分析需要依賴用戶，但是不能過分迷信用戶。（對，需求描述是困難的）

6、觀察用戶如何工作也是一種需求調查行為。（對）

軟件需求分析階段的任務：需求獲取，需求分析，需求定義，需求驗證。完整性，正確性，合理性，可行性，充分性。

結構化分析方法：是一種建模技術。核心是數據字典。

功能模型用數據流圖（DFD)來描述使用實體—關系圖（ER圖）建立數據模型。使用狀態轉換圖（簡稱狀態圖）建立系統行為模型。數據字典。加工規格說明。需求建模的依據是需求描述

數據建模，ER圖，需要認真看。

第四章結構化設計方法

結構化設計方法是在模塊化，自頂向下逐步細化及結構化程序設計技術基礎上發展起來的，結構化設計方法可分為兩類：一類是根據系統的數據流進行設計，稱為面向數據流的設計，或稱過程驅動設計，另一類是根據系統的數據結構進行設計，稱為面向數據結構的設計，或稱數據驅動的設計。

軟件的體系結構設計，模塊化設計都是分而治之策略的具體表現。模塊化是將整體軟件劃分為獨立命名且可獨立訪問的模塊，不同的模塊通常具有不用的功能或指責，每個模塊可獨立開發，測試，最后組裝成完整的軟件。模塊是構成軟件的基本構件。模塊并不是越小越好，當模塊數目增加時，每個模塊的規模將減小，開發單個模塊的成本確實減少了，但是隨著模塊數目增加，模塊之間關系的復雜程度也會增加，設計模塊間接口所需要的工作量也將增加。

模塊的獨立性是指軟件系統中每個模塊只涉及軟件要求的具體的子功能，而與軟件系統中其他模塊的接口是簡單的，若一個模塊只具有單一的功能且與其他模塊沒有太多的聯系，那么稱此模塊有獨立性。

自頂向下，逐步細化：抽象是指忽視一個主題中與當前目標無關的方面，以便更充分地注意與當前目標有關的方面，當我們進行軟件設計時，設計開始時應盡量提高軟件的抽象層次，按抽象級別從高到低進行軟件設計，將軟件的體系結構按自頂向下方式，對各個層次的過程細節和數據細節逐層細化，直到用程序設計語言的語句能夠實現為止，從而最后確定整個系統的體系結構，這就是自頂向下逐步細化過程。

復用是指同一事物不做修改或稍加修改就可以多次重復使用，將服用的思想用于軟件開發，稱為軟件復用。1是盡量使用已有的構件。2是如果確實需要創建新的構件，則在設計時應該考慮將來的可重復使用性。軟件設計的階段與任務：從工程管理的角度，可以將軟件設計分為概要設計階段和詳細設計階段。從技術的角度，傳統的結構化方法將軟件設計劃分為體系結構設計、數據設計、接口設計和過程設計4部分；概要設計包括體系結構設計、數據設計、接口設計。詳細設計即過程設計，對結構表示進行細化，得到軟件詳細的數據結構和算法。

軟件設計各項設計工作的依據：體系結構設計，定義軟件模塊及其之間的關系，依賴于數據流圖。數據設計，依賴于ER圖。接口設計，依賴于頂層數據流圖。過程設計：依賴于加工規格說明、狀態圖

基于數據流方法的設計過程：1.復查并精化數據流圖。2.確定數據流圖中數據流的類型，典型的數據流類型有變換型數據流和事務型數據流。3.導出初始的軟件結構圖。4.逐級分解。5.精化軟件結構。6.導出接口描述和全局數據結構。

軟件模塊結構的改進方法：1，模塊功能的完善化。2，消除重復功能，改善軟件結構。3，模塊的作用范圍應在控制范圍之內。4，盡可能減少高扇出結構，隨著深度增大扇入。5，避免或減少使用病態連接。6，模塊的大小要適中。接口設計的依據是數據流圖中的自動化系統邊界。

自頂向下，逐步細化的設計過程主要包括兩個方面：一是將復雜問題的解法分析和細化成由若干個模塊組成的層次結構，二是將每個模塊的功能逐步分解細化為一系列的處理。第五章編碼

編碼容易出現的風格不足

1、變量或函數名字缺乏具體含義

2、變量或函數名字與其用途不符

3、變量或函數未加上必要的注釋

4、函數未說明其功能、參數的意義

5、引用的符號未加以解釋和說明

6、對循環等重要的程序語句未注釋

7、對用到的重要庫函數沒有解釋說明

8、對結構體等復雜數據結構的組成成分沒有解釋說明

9、缺乏必要的提示語句 第六章軟件測試方法

軟件測試是在軟件投入生產性運行之前，對軟件需求分析，設計規格說明和編碼的最終復審，是軟件質量控制的關鍵步驟。軟件測試是為了發現錯誤而執行程序的過程。

第五篇：軟件工程總結

一、軟件工程概述

1．軟件特點

軟件：計算機程序（人們為了實現特定的功能而編制的一組指令集），軟件文檔，以及計算機程序運行時所需要的數據。

軟件是計算機系統中的邏輯成分，具有無形性，可復用性。

2．軟件分類（1）按功能劃分：系統軟件、支撐軟件、應用軟件。（2）按工作方式劃分：實時處理軟件、分時處理軟件、交互式軟件、批處理軟件。（3）按規模劃分：微型軟件、小型軟件、中型軟件、大型軟件。（4）按服務對象劃分：通用軟件、定制軟件。3．軟件發展階段（1）程序設計時代（20世紀50年代）。（2）程序系統時代（20世紀60年代）。（3）軟件工程時代（20世紀70年代起）。4．軟件危機

（1）危機現象：軟件開發成本與進度估計不準確，軟件產品與用戶要求不一致，軟件產品質量可靠性差，軟件文檔不完整不一致，軟件產品可維護性差，軟件生產率低。

（2）危機原因：科學的工程化思想組織和指導，完善的質量保證體系，軟件文檔的不重視，軟件的不可見性，系統規模龐大，生產工程化程度低，對用戶需求關心不 夠，對維護不夠重視，開發工具自動化程度低。5．軟件工程

軟件工程：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必須的相關文件資料。軟件工程是一門關于軟件開發與維護的工程學科，它涉及軟件生產的各個方面，能夠為經濟、高效地開發高質量的軟件產品提供最有效的支持。

軟件工程的目標：控制成本，滿足需求，提高質量，提高可靠性，是產品易于維護，移植，升級和使用，控制開發周期。

（1）工程方法：結構化方法、JSD方法、面向對象方法。（2）軟件工具：具有自動化特征的軟件開發集成支撐環境。（3）工程過程：在軟件工具支持下的一系列工程活動，基本活動是軟件定義、軟件開發、軟件驗證、軟件維護。（4）工程管理：項目規劃，項目資源調配，軟件產品控制。（5）工程原則：分階段生命周期計劃，階段評審制度，嚴格的產品控制，采用先進的技術，成果能清楚地審查，開發隊伍精練，不斷改進工程實踐。（6）工程目標：開發成本較低，軟件功能能滿足用戶需求，軟件性能較好，軟件可靠性高，軟件易于使用、維護與移植，能按時完成開發任務并及時交付使用。（7）工程文化：包括工程價值、工程思想和工程行為三個方面的內容。

二、軟件工程過程模型 1．軟件生命周期 如同任何事物都有一個發生、發展、成熟直至衰亡的全過程一樣，軟件系統或軟件產品也有一個定義、開發、運行維護直至被淘汰這樣的全過程，我們把軟件將要經歷的這個全過程稱為軟件的生命周期。它包含：軟件定義、軟件開發、軟件運行維護三個時期，并可以細分為可行性研究、項目計劃、需求分析、概要設計、詳細設計、編碼實現與單元測試、系統 2 集成測試、系統確認驗證、系統運行與維護等幾個階段。

軟件定義期 軟件定義是軟件項目的早期階段，主要由軟件系統分析人員和用戶合作，針對有待開發的軟件系統進行分析、規劃和規格描述，確定軟件是什么，為今后的軟件開發做準備。這個時期往往需要分階段地進行以下幾項工作。1．軟件任務立項 軟件項目往往開始于任務立項，并需要以“軟件任務立項報告”的形式針對項目的名稱、性質、目標、意義和規模等作出回答，以此獲得對準備著手開發的軟件系統的最高層描述。2．項目可行性分析 在軟件任務立項報告被批準以后，接著需要進行項目可行性分析。可行性分析是針對準備進行的軟件項目進行的可行性風險評估。因此，需要對準備開發的軟件系統提出高層模型，并根據高層模型的特征，從技術可行性、經濟可行性和操作可行性這三個方面，以“可行性研究報告”的形式，對項目作出是否值得往下進行的回答，由此決定項 目是否繼續進行下去。3．制定項目計劃 在確定項目可以進行以后，接著需要針對項目的開展，從人員、組織、進度、資金、設備等多個方面進行合理的規劃，并以“項目開發計劃書”的形式提交書面報告。4．軟件需求分析 軟件需求分析是軟件規格描述的具體化與細節化，是軟件定義時期需要達到的目標。需求分析要求以用戶需求為基本依據，從功能、性能、數據、操作等多個方面，對軟件系統給出完整、準確、具體的描述，用于確定軟件規格。其結果將以“軟件需求規格說明書”的形式提交。在軟件項目進行過程中，需求分析是從軟件定義到軟件開發的最關鍵步驟，其結論不僅是今后軟件開發的基本依據，同時也是今后用戶對軟件產品進行驗收的基本依據。軟件開發期 在對軟件規格完成定義以后，接著可以按照“軟件需求規格說明書”的要求對軟件實施開發，并由此制作出軟件產品。這個時期需要分階段地完成以下幾項工作。1．軟件概要設計 概要設計是針對軟件系統的結構設計，用于從總體上對軟件的構造、接口、全局數據結構和數據環境等給出設計說明，并以“概要設計說明書”的形式提交書面報告，其結果將成為詳細設計與系統集成的基本依據。模塊是概要設計時構造軟件的基本元素，因此，概要設計中軟件也就主要體現在模塊的構成與模塊接口這兩個方面上。結構化設計中的函數、過程，面向對象設計中的類、對象，它們都是模塊。概要設計時并不需要說明模塊的內部細節，但是需要進行全部的有關它們構造的定義，包括功能特征、數據特征和接口等。在進行概要設計時，模塊的獨立性是一個有關質量的重要技術性指標，可以使用模塊的內聚、耦合這兩個定性參數對模塊獨立性進行度量。2．軟件詳細設計 設計工作的第二步是詳細設計，它以概要設計為依據，用于確定軟件結構中每個模塊的內部細節，為編寫程序提供最直接的依據。詳細設計需要從實現每個模塊功能的程序算法和模塊內部的局部數據結構等細節內容 3 上給出設計說明，并以“詳細設計說明書”的形式提交書面報告。3．編碼和單元測試 編碼是對軟件的實現，一般由程序員完成，并以獲得源程序基本模塊為目標。編碼必須按照“詳細設計說明書”的要求逐個模塊地實現。在基于軟件工程的軟件開發過程中，編碼往往只是一項語言轉譯工作，即把詳細設計中的算法描述語言轉譯成某種適當的高級程序設計語言或匯編語言。為了方便程序調試，針對基本模塊的單元測試也往往和編碼結合在一起進行。單元測試也以“詳細設計說明書”為依據，用于檢驗每個基本模塊在功能、算法與數據結構上是否符合設計要求。4．系統集成測試 所謂系統集成也就是根據概要設計中的軟件結構，把經過測試的模塊，按照某種選定的集成策略，例如漸增集成策略，將系統組裝起來。在組裝過程中，需要對整個系統進行集成測試，以確保系統在技術上符合設計要求，在應用上滿足需求規格要求。5．系統確認驗證 在完成對系統的集成之后，接著還要對系統進行確認驗證。系統確認驗證需要以用戶為主體，以需求規格說明書中對軟件的定義為依據，由此對軟件的各項規格進行逐項地確認，以確保已經完成的軟件系統與需求規格的一致性。為了方便用戶在系統確認期間能夠積極參入，也為了系統在以后的運行過程中能夠被用戶正確使用，這個時期往往還需要以一定的方式對用戶進行必要的培訓。在完成對軟件的驗收之后，軟件系統可以交付用戶使用，并需要以“項目開發總結報告”的書面形式對項目進行總結。

軟件運行與維護期 軟件系統的運行是一個比較長久的過程，跟軟件開發機構有關的主要任務是對系統進行經常性的有效維護。軟件的維護過程，也就是修正軟件錯誤，完善軟件功能，由此使軟件不斷進化升級的過程，以使系統更加持久地滿足用戶的需要。因此，對軟件的維護也可以看成為對軟件的再一次開發。在這個時期，對軟件的維護主要涉及三個方面的任務，即改正性維護、適應性維護和完善性維護。2．瀑布模型 瀑布模型誕生于20世紀70年代，是最經典的并獲得最廣泛應用的軟件過程模型。瀑布模型中的“瀑布”是對這個模型的形象表達，即山頂傾瀉下來的水，自頂向下、逐層細化。（1）特點：線性化模型、階段具有里程碑特征、基于文檔的驅動、階段評審機制。（2）作用：為軟件項目按規程管理提供了便利，為其他過程模型的推出提供了一個良好的 拓展平臺。（3）局限性：主要適合于需求明確且無大的需求變更的軟件開發，但不適合分析初期需求 模糊的項目。3．原型模型（1）快速原型方法：是原型模型在軟件分析、設計階段的應用，用來解決用戶對軟件系統在需求上的模糊認識，或用來試探某種設計是否能夠獲得預期結果。（2）原型進化模型：針對有待開發的軟件系統，先開發一個原型給用戶使用，然后根據用 戶的使用意見，對原型不斷修改，使它逐步接近，并最終到達開發目標。