第一篇：軟件工程導論知識點總結(整理)

《軟件工程導論》課后習題答案

第一章 軟件工程概論

1．什么是軟件危機？

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

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

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

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

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

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

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

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

2．為什么會產生軟件危機？

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

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

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

3．怎樣克服軟件危機？

(1)充分吸收和借鑒人類長期以來從事各種工程項目中積累的行之有效的有效原理、概念、技術與方法，特別是吸取幾十年來人類從事計算機硬件研究和開發的經驗教訓。在開發軟件的過程中努力作到良好的組織，嚴格的管理，相互友好的協作。

(2)推廣在實踐中總結出來的開發軟件的成功的技術和方法，并研究更好、更有效的技術和方法，盡快克服在計算機系統早期發展階段形成的一些錯誤概念和作法。

(3)根據不同的應用領域，開發更好的軟件工具并使用這些工具。將軟件開發各個階段使用的軟件工具集合成一個整體，形成一個很好的軟件開發支環環境。

總之為了解決軟件危機，既要有技術措施(方法和工具)，又要有必要的組織管理措施。

4.構成軟件項目的最終產品：

應用程序、系統程序、面向用戶的文檔資料和面向開發者的文檔資料。

5．什么是軟件生存周期？

軟件生存周期是指從軟件定義、開發、使用、維護到淘汰的全過程。

6．軟件生存周期為什么劃分成階段？

(1)任何一個階段的具體任務不僅獨立，而且簡單，便于不同人員分工協作，從而降低整個軟件開發工作的困難程度。

(2)可以降低每個階段任務的復雜程度，簡化不同階段的聯系，有利于工程的組織管理，也便于采用良好的技術方法。

(3)使軟件開發的全過程以一種有條不紊的方式進行，保證軟件的質量，特別是提高了軟件的可維護性。

7．應該怎樣來劃分階段？

(1)每一個階段的任務盡可能獨立；

(2)同一階段內的任務性質盡可能相同；

(3)每一個階段任務的開始和結束有嚴格的標準。

8．軟件開發模型有幾種？它們的開發方法有可特點？

軟件開發模型有瀑布型、漸增型和變換型。

瀑布型開發方法是按照軟件生存周期的劃分依次實施，每一個階段有明確規定的任務。它的特點：

(1)各個階段的順序性和依賴性；

(2)劃分邏輯設計與物理設計，盡可能推遲程序的物理實現；

(3)每個階段必須完成規定的文檔，對其中問題通過復審及早發現，及早解決。

漸增型開發方法及特點:

(1)從部分需求出發，先建立一個不完全的系統，通過測試運行該系統取得經驗和信息反饋，加深對軟件需求的理解，進一步使系統擴充和完善。如此反復，直至軟件人員和用戶對所設計完成的軟件系統滿意為止。

(2)在漸增型開發下的軟件是隨軟件開發的過程而逐漸形成的。

(3)漸增型開發方法適合于知識型軟件的開發，設計系統時對用戶需求的認識開始不是很清楚的，需要在開發過程中不斷認識、不斷獲得新的知識去豐富和完善系統。多數研究性質的試驗軟件，一般采用此方法。

變換型開發方法及特點:

(1)從軟件需求的形式化說明出發，經過一系列的程序變換，得到最終的程序系統。

(2)該方法必須有嚴格的數學理論和形式化技術的支持。

9.什么是軟件工程?

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

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

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

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

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

10．什么是軟件工程環境: 方法與工具的結合，加上配套的軟、硬件支持稱為軟件工程環境。它能支持開發者按照軟件工程的方法,全面完成生存周期中的各項任務。

第二章 可行性研究

1.問題定義的任務和主要工作?

問題定義的任務：將用戶提出的要求具體化、定量化；確定研制系統的范圍，明確研制的邊界。

問題定義階段的工作：

(1)通過調查研究，了解系統需求；

(2)確定系統的功能需求、性能需求、可靠性需求、安全及保密性、資源、開發費用及開發進度等的需求；

(3)問題定義階段的產品--系統目標與范圍說明書。

2.可行性研究目的?

確定在問題定義中所提出的問題是否值得去解，在限制條件下，問題能否解決。

3．可行性研究的任務？

(1)進一步分析和澄清問題的定義，在澄清問題的基礎上，導出系統的邏輯模型；

(2)從系統邏輯模型中，選擇問題的若干種主要解法，研究每一種解法的可行性，為以后的行動提出建議；

(3)如果問題沒有可行的解，建議停止系統開發；如果問題有可行的解，應該推薦一個較好的解決方案，并為工程制定一個初步的計劃。

4．可行性研究包括哪幾方面的內容？

(1)技術可行性：現有技術能否實現本系統，現有技術人員能否勝任，開發系統的資源能否滿足；

(2)經濟可行性：經濟效益是否超出開發成本；

(3)操作可行性：系統操作在用戶內部行得通嗎？

(4)法律可行性：新系統開發是否會侵犯他人、集體或國家利益，是否違反國家法律。

5．可行性研究的步驟?

(1)復查系統的規模和目標；

(2)研究目前正在使用的系統，總結現有系統的優劣，提出新系統的雛形；(3)導出新系統的高層邏輯模型；(4)推薦建議方案；

(5)推薦行動方針；

(6)書寫計劃任務書(可行性報告)；

(7)提交審查。

6.可行性研究報告的主要內容？

可行性分析的結果是可行性研究報告,內容包括：

(1)系統概述：說明開發的系統名稱,提出單位和開發單位。

(2)可行性研究的前提:系統目標；要求；約束和限制；可行性研究的基本準則等。

(3)對現有系統的分析:處理流程，圖示說明現有系統的處理流程和數據流程；現有系統存在的問題。

(4)系統需求:主要功能；主要性能及其要求；操作要求；信息要求；限制性要求。

(5)建議系統:系統目標；處理流程；系統結構,功能,性能；系統技術可行性；投資和效益分析；操作可行性；法律可行性。

(6)其它可選方案:與國內外同類型方案的比較；提出一兩個可行性方案供論證和探討。

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

(8)結論性意見：由用戶方、設計方和投資方共同簽署意見。

第三章 需求分析

1.需求分析的描述工具有哪些?

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

2.需求分析的基本任務是什么?

準確定義未來系統的目標，確定為了滿足用戶的需要系統必須做什么。

3.怎樣建立目標系統的邏輯模型?要經過哪些步驟? 建立目標系統的邏輯模型的過程也就是數據流圖的分解過程。

4.什么是結構化分析?它的結構化體現在哪里?

結構化分析:使用數據流程圖、數據字典、結構化英語、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標文檔-需求規格說明書。

結構化體現在將軟件系統抽象為一系列的邏輯加工單元,各單元之間以數據流發生關聯。

5.軟件需求規格說明書由哪些部分組成?

組成包括：

(1)引言：編寫目的、背景說明、術語定義及參考資料等。(2)概述主要功能、約束條件或特殊需求。(3)數據流圖與數據字典。

(4)用戶接口、硬件接口及軟件接口。(5)性能需求、屬性等。

(6)其它需求，如數據庫、操作及故障處理等。

6.為什么數據流圖要分層?畫分層的DFD要遵循哪些原則?

分層的目的：便于逐步細化、結構清晰。畫分層的DFD要遵循哪些原則：(1)父圖與子圖之間數據要平衡。

(2)分解的深度和層次達到使加工足夠簡單、易于理解的基本加工為止。

(3)區分局部文件和局部外部項(局限于數據流中某一層或某幾層的文件和外部項)。(4)不要把控制流作為數據流。(5)忽略瑣碎的枝節。

(6)每個數據流要有一個合適的名字，盡量使用現實系統中有具體意義的名字。

7.系統流程圖與數據流程圖有什么區別?

系統流程圖描述系統物理模型的工具，數據流程圖描述系統邏輯模型的工具。

系統流程圖從系統功能的角度抽象的描述系統的各個部分及其相互之間信息流動的情況。

數據流程圖從數據傳送和加工的角度抽象的描述信息在系統中的流動和數據處理的工作狀況。

8.數據字典包括哪些內容?它的作用是什么？

數據字典是描述數據流圖中數據的信息的集合。它對數據流圖上每一個成分：數據項、文件(數據結構)、數據流、數據存儲、加工和外部項等給以定義和說明；它主要由數據流描述、加工描述和文件描述三部分組成。對用戶來講,數據字典為他們提供了數據的明確定義；對系統分析員來講,數據字典幫助他們比較容易修改已建立的系統邏輯模型。

9.描述加工邏輯的工具有哪些?

判定樹、判斷表和結構化語言等。

第四章 總體設計

1.系統設計包括哪兩個階段?

系統設計包括總體設計與詳細設計兩個階段。

2.總體設計的主要任務是什么？

總體設計的主要任務是完成軟件結構的設計,確定系統的模塊及其模塊之間的關系。

3.什么是模塊？模塊具有哪幾個特征？總體設計主要考慮什么特征？

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

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

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

4.什么是模塊化？模塊設計的準則？

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

模塊設計的準則：

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

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

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

(4)盡量降低模塊接口的復雜程度；

(5)設計單入口、單出口的模塊。

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

5.變換型數據流由哪幾部分組成？

變換型結構由三部分組成:傳入路徑、變換(加工)中心和傳出路徑。6.變換分析設計的步驟？

(1)區分傳入、傳出和變換中心三部分，劃分DFD圖的分界線；(2)完成第一級分解:建立初始SC圖的框架；(3)完成第二級分解:分解SC圖的各個分支；

(4)對初始結構圖按照設計準則進行精化與改進。

7.事務型數據流由哪幾部分組成？

事務型結構由至少一條接受路徑、一個事務中心與若干條動作路徑組成。

8.事務分析設計的步驟？

(1)在DFD圖中確定事務中心、接收部分(包含全部接收路徑)和發送部分(包含全部動作路徑);

(2)畫出SC圖框架,把DFD圖的三部分分?quot;映射“為事務控制模塊,接收模塊和動作發送模塊.一般得到SC圖的頂層和第一層(如果第一層簡單可以并入頂層);

(3)分解和細化接收分支和動作分支,完成初始的SC圖;

(4)對初始結構圖按照設計準則進行精化與改進。

9.比較層次方框圖與結構圖是的異同？

(1)層次方框圖描繪數據的層次結構, 結構圖描繪的是軟件結構。

(2)二者都采用多層次矩形框樹形結構。層次方框圖的頂層矩形框代表完整的數據結構, 下面各層矩形框依次代表上個框數據的子集；結構圖

是在層次圖的每一個方框內注明模塊的名字或主要功能，方框之間的直線表示模塊的調用關系，用帶注解的箭頭表示模塊調用過程中傳遞的信息。

第五章 詳細設計

1.詳細設計的目的? 為軟件結構圖(SC圖或HC圖)中的每一個模塊確定采用的算法和塊內數據結構,用某種選定的表達工具給出清晰的描述.2.詳細設計的主要任務? 編寫軟件的“詳細設計說明書”.軟件人員要完成的工作：

(1)為每一個模塊確定采用的算法, 選擇某種適當的工具表達算法的過程,寫出模塊的詳細過程描述.(2)確定每一模塊使用的數據結構.(3)確定模塊結構的細節,包括對系統外部的接口和用戶界面,對系統內部其它模塊的接口,以及關于模塊輸入數據、輸出數據及局部數據的全部細節.(4)為每一個模塊設計出一組測試用例,以便在編碼階段對模塊代碼(即程序)進行預定的測試.3.結構化程序設計的基本原則? 在詳細設計中所有模塊都使用單入口、單出口的順序、選擇、循環三種基本控制結構.4.比較面向數據流和面向數據結構兩類設計方法的異同? 相同點：

(1)遵守結構程序設計“由頂向下”逐步細化的原則,并以其為共同的基礎；

(2)均服從“程序結構必須適應問題結構”的基本原則,各自擁有從問題結構(包括數據結構)導出程序結構的一組映射規則。

不同點：

(1)面向數據流的設計以數據流圖為基礎，在分析階段用DFD表示軟件的邏輯模型，在設計階段按數據流類型，將數據流圖轉換為軟件結構。面向數據結構的設計以數據結構為基礎，從問題的數據結構出發導出它的程序結構。

(2)面向數據流的設計的最終目標是軟件的最終SC圖，面向數據結構的設計的最終目標是程序的過程性描述。

5.比較Jackson方法和LCP方法的異同?

Jackson與LCP設計方法都是以數據結構為出發點，以程序的過程描述為最終目標，設計步驟基本相似。它們的主要差別是：

(1)使用不同的表達工具，其中LCP方法中的表達工具Warnier圖

比Jackson設計方法中的表達工具Jackson圖有更大的通用性；(2)Jackson方法的步驟和指導原則有一定的靈活性，而LCP設計

方法則更加嚴密。

6.詳細設計的描述工具應具備什么功能？

無論哪類描述工具不僅要具有描述設計過程，如控制流程、處理功能、數據組織及其它方面的細節的能力,而且在編碼階段能夠直接將它翻譯為用程序設計語言書寫的源程序。

第六章

編碼

1.編碼的任務？

使用選定的程序設計語言，把模塊的過程性描述翻譯為用語言書寫的源程序(源代碼)。

2.對源程序基本要求？

源程序要求：正確可靠、簡明清晰、效率高。(1)源程序的正確性是對程序質量的最基本要求；

(2)源程序的簡明清晰，便于驗證源代碼和模塊規格說明的一致性，容易進行測試和維護；

(3)對于大多數模塊，編碼時應該把簡明清晰放在第一位；

(4)除了編碼階段產生源代碼外，在測試階段也需要編寫一些測試程序，用于對軟件的測試。

3.程序設計語言的特點?(1)名字說明：程序中使用對象的名字，能為編譯程序所檢查和識別；(2)類型說明：定義對象的類型，確定該對象的使用方式；

(3)初始化：為變量提供適當的初始值或由系統給變量賦一特殊的表明未初始化的值；(4)對象的局部性：程序中真正需要的那部分才能訪問的對象；(5)程序模塊：控制程序對象的名字；

(6)循環控制結構：如FOR語句、WHILE-DO語句、REPEAT-UNTIL語句等；(7)分支控制結構：如IF語句、CASE語句等；

(8)異常處理：為程序運行過程中發生的錯誤和意外事件提供檢測和處理上的幫助；(9)獨立編譯：能分別編譯各個程序單元。

4.選擇程序設計語言需要考慮的因素？

(1)選擇用戶熟悉、便于用戶維護的語言。

(2)選擇目標系統的環境中可以提供的編譯程序所能選用的語言。(3)選擇可以得到的軟件工具,能支持程序開發中可以利用的語言。

(4)根據工程規模的大小、目標系統應用范圍，如實時應用選擇Ada語言或匯編語言，系統軟件開發選擇C語言或匯編語言，軟件開發中若含有大量數據操作則選擇SQL、dBASE等數據庫語言等。

(5)選擇程序員熟悉的語言。

(6)選擇標準化程度高、程序可移植性好的語言。

(7)根據算法與計算的復雜性、數據結構的復雜性選擇。如對于系統程序和結構復雜的應用程序，選擇支持數組、記錄(或結構)與指針動態數據結構的Pascal語言或C語言。

(8)根據實時要求系統需要的響應速度和效率選擇相應的語言。

5.編碼風格的指導原則。

(1)源程序：包括適當的標識符、適當的注解、程序清單的合理布局與清晰；

(2)數據說明：數據結構或數據類型的說明次序標準化；變量名稱盡量有意義；對復雜的數據結構在注解中要說明在程序設計中實現這個數據結構的方法。

(3)語句的構造簡單明了：不要為節省空間將多個語句寫在同一行；盡量避免復雜的條件及“非”條件的測試；避免大量使用循環嵌套和條件嵌套；括號的使用是為了使邏輯表達式和算術表達式的運算順序清晰直觀。

(4)效率：考慮程序運行的時間存儲器效率、輸入/輸出的效率；在處理程序正確性、清晰與效率之間的關系時先求程序正確后求快；先求清楚后求快；保持程序簡單以求快；書寫清楚,不為“效率”犧牲清晰。

6.第四代語言(4GL)應具備哪些的特征？

(1)具有很強的數據管理能力，能對數據庫進行有效的存取、查詢和其它有關操作；(2)能提供一組高效的、非過程化的命令，組成語言的基本語句，編程時用戶只需用這些命令說明“做什么”，不必描述實現的細節；

(3)能滿足多功能、一體化的要求。為此，語言中除必須含有控制程序邏輯與實現數據庫操作的語句外，還應包括生成與處理報表、表格、圖形，以及實現數據運算和分析統計功能的各種語句，共同構成一個一體化的語言，以適應多種應用開發的需要。

第七章

軟件測試

1.軟件測試的基本任務？

軟件測試是按照特定的規則，發現軟件錯誤的過程；好的測試方案是盡可能發現迄今尚未發現錯誤的測試；成功的測試方案是發現迄今尚未發現錯誤的測試；

2.測試與調試的主要區別？

(1)測試從一個側面證明程序員的失?。徽{試證明程序員的正確；

(2)測試從已知條件開始，使用預先定義的程序，且有預知的結果，不可預見的僅是程序是否通過測試；調試從不可知內部條件開始，除統計性調試外，結果是不可預見的；

(3)測試有計劃并且要進行測試設計；調試不受時間約束；

(4)測試是發現錯誤、改正錯誤、重新測試的過程；調試是一個推理的過程；

(5)測試執行是有規程的；調試執行要求程序員進行必要的推理；

(6)測試由獨立的測試組在不了解軟件設計的件下完成；調試由了解詳細設計的程序員完成；

(7)大多數測試的執行和設計可由工具支持；調試用的工具主要是調試器。

3.人工復審的方式和作用? 人工復審的方式：代碼會審、走查和排練和辦公桌檢查； 人工復審的作用：檢查程序的靜態錯誤。

4.什么是黑盒測試?黑盒測試主要采用的技術有哪些? 黑盒測試：也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內部邏輯結構。測試者把被測程序看成一個黑盒,不用關心程序的內部結構。黑盒測試是在程序接口處進行測試，它只檢查程序功能是否能按照規格說明書的規定正常使用，程序是否能適當地接收輸入數據產生正確的輸出信息，并且保持外部信息(如數據庫或文件)的完整性。

黑盒測試主要采用的技術有:等價分類法、邊沿值分析法、錯誤推測法和因果圖等技術。

5.什么是白盒測試?白盒測試主要采用的技術有哪些? 測試者了解被測程序的內部結構和處理過程,對程序的所有邏輯路徑進行測試,在不同點檢查程序狀態,確定實際狀態與預期狀態是否一致。

白盒測試主要采用的技術有：路徑測試技術和事務處理流程技術，對包含有大量邏輯判斷或條件組合的程序采用基于邏輯的測試技術。

6.路徑測試技術中幾種主要覆蓋的含義?舉例說明? 語句覆蓋:至少執行程序中所有語句一次。

判定覆蓋:使被測程序中的每一個分支至少執行一次。故也稱為分支覆蓋。條件覆蓋:執行所有可能的穿過程序的控制路流程。

條件組合測試:設計足夠的測試用例，使每個判定中的所有可能條件取值組合至少執行一次。

7.等價分類法的測試技術采用的一般方法?舉例說明?(1)為每個等價類編號；

(2)設計一個新的測試方案,以盡可能多的覆蓋尚未被覆蓋的有效等價類,重復這一步驟,直到所有有效等價類被覆蓋為止。

(3)設計一個新的測試方案,使它覆蓋一個尚未被覆蓋的無效等價類, 重復這一步驟,直到所有無效等價類被覆蓋為止。

8.軟件測試的一般步驟? 單元測試、子系統測試、系統測試、驗收測試、平行測試。

9.比較集成試的兩種方式的優劣? 非漸增式測試方式：分別測試模塊,再把所有模塊按設計要求放在一起組成所要的程序。該方法編寫測試軟件工作量大，模塊間的接口錯誤發現得晚，錯誤定位較難診斷，總體測試有的錯誤容易漏掉，測試時間相對較少，可以并行測試所有模塊，能充分利用人力，加快工程進度。

漸增式測試方式：把下一個要測試的模塊,同已經測試好的那些模塊結合起來進行測試。該方法利用已測試過的模塊作測試軟件,開銷小，較早發現模塊間的接口錯誤，錯誤定位往往和最近入的模塊相關，對已測試好的模塊可在新加入模塊的條件下受到新的檢驗，測試更徹底，需要較多的測試時間，不能并行測試。總的來說，漸增式測試方法比較好。

10.軟件測試的策略?

(1)在任何情況下都應使用邊界值分析的方法。(2)必要時用等價類劃分法補充測試方案。(3)必要時再用錯誤推測法補充測試方案。(4)對照程序邏輯，檢查已設計出的測試方案。

(5)根據對程序可靠性的要求采用不同的邏輯覆蓋標準，再補充一些測試方案。

第八章 軟件維護

1.為什么說軟件的維護是不可避免的？

因為軟件的開發過程中，一般很難檢測到所有的錯誤，其次軟件在應用過程中需要隨用戶新的要求或運行環境的變化而進行軟件的修改或完成功能的增刪等，為了提高軟件的應用水平和使用壽命，軟件的維護是不可避免的。

2.軟件的維護一般分為哪幾類？

改正性維護：滿足用戶對已開發產品的性能與運行環境不斷提高的要求，進而達到延長軟件壽命的目的。

適應性維護：對程序使用期間發現的程序錯誤進行診斷和改正的過程，配合變化了的環境進行修改軟件的活動；

完善性維護：滿足用戶在使用過程中提出增加新的功能或修改已有功能的建議而進行的工作；

預防性維護：為了改善未來的可維護性或可靠性而修改軟件的工作。

3.影響軟件維護的因素有哪些？

開發方法：采用模塊化詳細設計文檔有助于理解軟件的結構、界面功能和內部流程；開發過程中嚴格而科學的管理規劃及清晰可靠的文檔資料對發生錯誤后的理解與糾錯是至關重要的；開發過程中模塊的獨立程度越高，對軟件修改越容易，對軟件的改進和移植越方便。

開發條件：軟件開發及維護人員的水平決定了軟件開發的質量和維護的效率；開發過程中使用標準的程序設計語言和標準的操作系統接口，可以大大提高軟件的可維護性；在測試過程中用例的有效性，可極大地減少軟件存在的錯誤；其次使用規范化的文檔資料可為維護提供更好的依據。

4.軟件維護困難主要表現在什么方面？

(1)一般來講，維護人員對開發人員寫的程序及文檔，理解都比較困難，對維護工作不會喜歡；

(2)維護持續時間都很長，在開發人員不在現場的輕快下，維護軟件通常是很困難的；

(3)絕大多數軟件在設計時對將來的軟件修改都沒有考慮或考慮不多，尤其未能在設計中強調并認真解決好模塊的獨立性，使軟件的修改既困難又易發生差錯。

5.決定軟件可維護性的因素？

(1)軟件的可理解性、可測試性、可修改性；

(2)文檔描述符合要求、用戶文檔簡潔明確、系統文檔完整并且標準。

6.軟件價格應該計入維護成本嗎？為什么？

在軟件的生命周期中，軟件維護的工作量非常大，不同應用領域的維護成本差別也很大。一般大型軟件的維護成本遠遠高于開發成本若干倍。因此軟件價格中應該計入維護成本。

第九章 軟件工程管理

1.軟件工程管理的內容？

(1)費用管理: 對軟件開發進行成本核算,使軟件生產按照商品生產的規律辦事。包括:以簡單、科學方法估算軟件開發費用,作為簽定開發合同的根據；管理開發費用的有效使用,即用經濟手段來保證產品如期按質完成。

(2)質量管理: 按項目的質量保證計劃,確保各個開發階段的開發和維護工作全部按軟件工程的規范進行,保證軟件產品的質量。

(3)配置管理:通過對于程序、文檔和數據的各種版本所進行的管理，保證資料的完整性與一致性。

(4)項目管理：制定《項目實施計劃》，按照計劃的內容組織和實施軟件的工程化生產。最終目標是以合理的費用和進度，圓滿完成計劃所規定的軟件項目。

2.軟件項目有哪些特點？

(1)軟件項目與其他任何產業項目不同，它是算法、思想、概念、組織、流程、效率、優化等的融合體；

(2)開發軟件項目產品,在多數情況下,用戶給不出明確的想法和要求。

(3)在開發過程中，程序及其相關的文檔資料常常需要修改，在修改過程中又可能帶來新的問題，且這些問題要在很久以后才會發現。

(4)在研制開發過程中，文檔資料是不可缺少的，但工作量又是巨大的,往往也是人們不愿去作的。

(5)參加軟件項目的工作人員，要求具有一定的業務水平和實際工作經驗，而很難完全避免的人員流動，對工作的影響是很大的。離開的人員不僅帶走了重要的信息，而且帶走了工作經驗。

3.軟件成本估算的一般方法？

自頂向下估計：首先估算出項目總的開發成本，然后在項目內部進行成本分配。由少數專家參與，依靠他們過去的經驗，將要開發的軟件與過去開發過的軟件進行”類比“，以估計新的軟件開發所需要的工作量和成本。

自底向上估計：將開發任務分成若干子任務,子任務又分成子子任務,直到每一個單元內容足夠明確為止；把各個任務單元的成本估計出來,匯合成項目的總成本。該方法得到的結果比較接近實際。

4.為什么在軟件開發中，不能用簡單增加人員的方法來縮短開發時間？

大量軟件開發實踐說明：向一個已經延遲的項目追加開發人員,可能使它完成得更晚。因為當開發人員以算術級數增長時，而人員之間的通信將以幾何級數增長，往往”得不償失"。

5.影響軟件質量的主要因素有哪些？

(1)產品運行:正確性、風險性、效率、完整性、健壯性和可用性；

(2)產品修改:可理解性、可維護性、靈活性、可測試性；

(3)產品轉移：可移植性、可重用性和互運行性。

第二篇：軟件工程導論填空題總結

1.軟件生存周期一般可分為問題定義、可行性研究、需求分析、設計編碼、測試、運行與維護階段。

2.按軟件的功能進行劃分，軟件可以劃分為系統軟件、支撐軟件 和應用軟件。

3.可行性研究主要集中在以下四個方面 經濟可行性、技術可行性、法律可行性 和抉擇。4.用戶界面的可使用性是用戶界面設計最重要的也是最基本的目標。

5.常見的軟件概要設計方法有3大類：以數據流圖為基礎構造模塊結構的結構化設計方法，以數據結構為基礎構造模塊的jackson方法_，以對象、類、繼承和通信為基礎的面向對象設計方法。

6.數據流圖和數據字典共同構成系統的邏輯模型。

7.軟件測試的方法有分析方法和非分析方法（即黑盒法）。8.單元測試一般以白盒測試為主，黑盒測試為輔。

9.成本估計方法主要有自底向上估計、自頂向下估計和算法模型估計三種類型。10.通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學，也稱為范型,軟件工程方法學包含三個要素：方法、工具和過程。目前使用得最廣泛的軟件工程方法學，分別是傳統方法學和面向對象方法學

11.最基本的測試是集成測試和驗收測試。

12.所謂情景分析就是對用戶將來使用目標系統解決某個具體問題的方法和結果進行分析 13.需求分析過程應該建立3種模型，它們分別是數據模型，功能模型，行為模型.數據對象彼此之間相互連接的方式稱為聯系，也稱為關系。聯系可分為3種類型：一對一聯系，一對多聯系，多對多聯系。

14.軟件的驗證：一致性，完整性，現實性，有效性

15.四種維護的定義：1.改正性維護2.適應性維護3.完善性維護4.預防性維護。2.數據流圖中信息流的類型有（變換流）和(事務流)。3.軟件的定義是：軟件=程序+數據+（文檔），軟件是（程序及其文檔）。4.經典結構程序設計包括順序、選擇和（重復）三種結構。5.集成測試時對軟件結構中上層使用(自頂向下)的集成測試方法，對軟件結構中下層使用(自底向上)的集成測試方法。

6.軟件維護包括(改正性維護)、適應性維護、完善性維護、預防性維護。

7.面向對象方法學建模得到的三個基本子模型是(對象建模)、動態模型、功能模型。8.復雜大型問題的對象模型通常由主題層、類與對象層、結構層、(屬性層)、及服務層5個層次組成。

9.面向對象方法學是基于 軟件的重用。

10.軟件層次結構圖中方框間的連線表示

調用 關系。

21．在軟件開發過程中要產生大量的信息，要進行大量的修改，軟件配置管理能協調軟件開發，并使混亂減到最低程度。

22．規定功能的軟件，在一定程度上對自身錯誤的作用（軟件錯誤）具有屏蔽能力，則稱此軟件具有容錯功能的軟件。

23．McCall提出的軟件質量模型包括11 個軟件質量特性。

24．軟件可維護性度量的七個質量特性是可理解性、可測試性、可修改性、可靠性、可移植性、可使用性和效率。

25．為了便于對照檢查，測試用例應由輸入數據和預期的輸出結果兩部分組成。

26．程序設計語言的心理特性主要表現在 歧義性、簡潔性、傳統性、局部性和順序性。27．軟件結構是以 模塊 為基礎而組成的一種控制層次結構。

28．在結構化分析中，用于描述加工邏輯的主要工具有三種，即：結構化語言、判定表、判定樹。

29．結構化語言是介于自然語言和形式語言之間的一種半形式語言。

30．若年利率為i，不計復利，n年后可得21．系統流程圖是描述物理模型的傳統工具，用圖形符號表示系統中各個元素表達了系統中各種元素之間的(信息流動)情況。22．成本效益分析的目的是從(經濟)角度評價開發一個項目是否可行。

23．自頂向下結合的漸增式測試法，在組合模塊時有兩種組合策略：深度優先策略和(寬度優先策略)。

24．獨立路徑是指包括一組以前沒有處理的語句或條件的一條路徑。從程序圖來看，一條獨立路徑是至少包含有一條(在其他獨立路徑中未有過)的邊的路徑。

25．匯編語言是面向(機器)的，可以完成高級語言無法完成的特殊功能，如與外部設備之間的一些接口工作。

26．在JSP方法中解決結構沖突的具體辦法是(中間數據結構或中間文件)。

27．詳細設計的任務是確定每個模塊的內部特性，即模塊的算法、(使用的數據)。28．所有軟件維護申請報告要按規定方式提出，該報告也稱(軟件問題)報告。

29．有兩類維護技術：在開發階段使用來減少錯誤、提高軟件可維護性的面向維護的技術；在維護階段用來提高維護的效率和質量的(維護支援)技術。

30．科學工程計算需要大量的標準庫函數，以便處理復雜的數值計算，可供選擇的語言有：(FORTRAN語言)、PASCAL語言、C語言和PL/1語言。1.軟件的開發與運行經常受到硬件的限制和制約。(√)2.模塊內的高內聚往往意味著模塊間的松耦合。(√)3．Jackson圖只能表達程序結構，不能表達數據結構。(X)上述數據流圖表示數據A和B同時輸入變換成C。(X)5．軟件的質量好壞主要由驗收人員負責，其他開發人員不必關心。(X)6．判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋。(√)7.應該盡量使用機器語言編寫代碼，提高程序運行效率，而減少高級語言的使用。(X)8．UML只能應用于軟件系統模型的建立。(X)9．容錯就是每個程序采用兩種不同的算法編寫。(X)軟件測試的目的是為了無一遺漏的找出所有的錯誤。(X)1.在進行總體設計時應加強模塊間的聯系。（N）2.系統結構圖是精確表達程序結構的圖形表示法。因此，有時也可以將系統結構圖當作系統流程圖使用。（N）

3.用黑盒法測試時，測試用例是根據程序內部邏輯設計的。（N）4.在程序調試時，找出錯誤的位置和性質比改正該錯誤更難。（Y）

5.以對象、類、繼承和通信為基礎的面向對象設計方法（OOD）也是常見的軟件概要設計方法之一。（Y）

6.如果通過軟件測試沒有發現錯誤，則說明軟件是正確的。（N）7.快速原型模型可以有效地適應用戶需求的動態變化。（Y）

8.模塊化，信息隱藏，抽象和逐步求精的軟件設計原則有助于得到高內聚，低耦合度的軟件產品。（Y）

9.集成測試主要由用戶來完成。（N）10.軟件危機完全是由于硬件問題引起的。（N）

第三篇：軟件工程導論知識總結范文

軟件工程導論 第一章:軟件工程學概論

1.軟件危機：是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。

2.概括的說，軟件危機包括兩方面問題：如何開發軟件已滿足日益增長的需求；如何維護數量不斷膨脹的已有軟件。3.軟件危機的典型表現：對軟件開發成本和進度的估計常常很不準確；用戶對“已完成的”軟件系統不滿意的現象經常發生；軟件的質量往往靠不住；軟件常常是不可維護的；軟件通常沒有適當的文檔資料；軟件成本在計算機系統總成本中所占的比例逐年上升；軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速不及深入的趨勢。

4.產生軟件危機的原因：在軟件開發和維護的過程中存在這么多嚴重的問題，一方面與軟件本身的特點有關，另一方面也和軟件開發與維護的方法不正確有關。

5.在實踐過稱中或多或少的采用了錯誤的方法和技術，這可能是使軟件問題發展成軟件危機的主要原因。

6.軟件不同與硬件，他是計算機系統中的邏輯部件而不是物理部件。

7.軟件不同于一般程序，他的一個顯著特點是估摸龐大，而且程序復雜性將隨著程序規模的增加而呈指數上升。

8.軟件本身獨有的特點確實給開發和維護帶來一些客觀困難。9.對用戶要求沒有完整的認識就匆忙著手編寫程序是軟件開發功臣失敗的主要原因之一。

10.一個軟件從定義、開發、使用和維護，直到最終被遺棄，要經歷一個漫長的時期，通常把軟件經歷的這個漫長的時期稱為生命周期。

11.軟件是程序、數據及相關文檔的完整集合。其中，程序是能夠完成預定功能和性能的可執的指令序列；數據是使程序能夠適當的處理信息的數據結構；文檔是開發、使用和維護程序所需要的圖文資料。

12.軟件工程是指導計算機軟件開發和維護的一門工程學科。13.軟件工程是：把系統的、規范的、可度量的途徑應用與軟件開發、運行和維護過程，也就是吧工程應用與軟件；研究前面所提到的途徑。

14.軟件工程的本質特性：軟件工程關注與大型程序的構造；軟件工程的中心課題是控制復雜性；軟件經常變化；開發軟件的效率非常重要；和諧的合作是開發軟件的關鍵；軟件必須有效地支持他的用戶；在軟件工程領域中通常由具有一種文化背景的人體另一種具有文化背景的人創造產品。

15.軟件工程的基本原理：用分階段的生命周期計劃嚴格管理；堅持進行階段評審；實行嚴格的產品控制；采用現代程序設計技術；結果應能清楚的審查；開發小組的人員應該少而精；承認不斷該井軟件工程的必要性。16.軟件工程包括技術和管理兩方面得內容，是技術與管理緊密結合所形成的工程學科。

17.通常把在軟件生命周期全過程中使用的一套技術方法的集合稱為方法學，也稱之為范型。18.方法學三要素：方法、工具和過程。

19.傳統方法學也稱為生命周期方法學或結構化范型。它采用結構化技術來完成軟件開發的各項任務，并使用適當的軟件工具或軟件工程環境來支持結構化技術的運用。

20.面向對象方法學與傳統方法學相反，它吧數據和行為看成是同等重要的，他是一種一數據為主線，把數據和對數據的操作緊密的結合起來的方法。

21.棉線對象方法學的要點:把對象作為融合了數據及在數據上的操作行為的統一的軟件構件；把所有的對象都劃分成類；按照父類與子類的關系，把若干相關類組成一個層次結構的系統；對象彼此間僅能通過發送消息互相聯系。

22.傳統方法學強調自頂而下順序的完成軟件開發的各項任務。23.面向方法學開發軟件的過程，是一個主動地多次反復迭代的演化過程。

24.面向對象范型的優點：降低了軟件產品的復雜性，提高了軟件的可理解性，簡化了軟件的開發和維護工作；促進了軟件重用。25.面向對象方法特有的繼承性和多態性，進一步提高了可重用性。26.軟件生命周期由軟件定義、軟件開發和運行維護3個時期組成，每個時期又進一步劃分成若干個階段。

27.軟件定義時期的任務：確定軟件開發工程必須完成的總目標；確定工程的可行性；導出實現工程目標應該采用的策略及系統必須完成的功能；估計完成該工程需要的資源和成本，并且制定工程進度表。

28.軟件定義時期分為三個階段：問題定義、可行性研究、需求分析。

29.開發時期階段組成：總體設計、詳細設計、編碼和單元測試、綜合測試。

30.維護時期的樹妖任務是使軟件持久的滿足用戶的需求。31.最基本的測試是集成測試和驗收測試。

32.通常的維護活動：改正性維護；適應性維護；完善性維護；預防性維護。

33.軟件過程是為了獲得高質量軟件所需要完成的一系列框架，它規定了完成各項的任務工作步驟。

34.把過程定義為：使用資源將輸入轉化為輸出的活動所構成的系統。

35.系統是相互關聯或相互作用的一組要素。

36.過程定義了運用方法的順序、應該交付的文檔資料、為保證軟件件質量和協調變化所需要的管理措施，以及標志軟件開發各個階段任務完成的里程碑。37.瀑布模型一直被廣泛采用的生命周期模型，仍然是軟件工程中應用的最廣泛的過程模型。

38.瀑布模型的特點：階段間具有順序性和依賴性；推遲延遲的觀點；質量保證的觀點。

39.瀑布模型的優點：可強迫開發人員采用規范的方法；嚴格的規定了每個階段必須提交的文檔；要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。

40.所謂快速原型是快建立起來的可以在計算機上運行的程序，他所能完成的功能往往是最終端產品能完成的功能的一個子集。41.快速原型模型的主要優點：不帶反饋環，軟件產品的開發基本上是線性順序進行的。42.增量模型也稱漸進模型。

43.增量模型的優點：能在短時間內向用戶提交可完成部分工作產品；逐步增加產品功能可以使用戶有充裕的時間學習和適應新產品從而減少一個全新的軟件可能給客戶組織帶來的沖擊。44.螺旋模型的基本思想是，使用原型及其他方法來盡量降低風險?？梢园阉醋魇窃诿總€階段都增加了風險分析過程的快速模型。

45.螺旋模型的優點：對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件來發的一個重要目標；減少了過多測試或測試不足所帶來的風險；更重要的是，在螺旋模型中維護只是模型的另一個周期，在維護和開發之間并沒有本質區別。

46.噴泉模型是典型的面向對象的軟件過程模型之一。47.“噴泉”這個詞體現了面向對象開發過程迭代和無縫的特性。

48.Ratioanal統一過程是一種完整而且完美的軟件過程。49.RUP軟件開發生命周期是一個二維的生命周期模型。50.RUP九個核心工作流：業務建模；需求；分析與設計；實現；測試；部署；配置與變更管理；項目管理；環境。

51.RUP工作階段：初始階段、精化階段、構建階段、移交階段。52.極限編程：是敏捷過程中最富盛名的一個，“極限”含義是指把好的開發實踐運用到極致。

53.微軟過程生命周期：規劃階段、設計階段、開發階段、穩定階段、發布階段。

54.面向對象方法=對象+類+繼承+用消息通信

可行性研究

1.典型的可行性研究過程步驟：復查系統規模和目標；研究目前正在使用的系統；導出新系統的高岑邏輯模型；進一步定義問題；導出和評論供選擇的解法；推薦行動方針；草擬開發計劃；書寫文檔提交審查。

2.系統流程圖是概括的描繪物理系統的傳統工具。他的基本思想是用圖形符號以黑盒子形式描繪組成系統的每個部件（程序、文檔、數據庫、人工過程等）。

3.系統流程圖基本符號：處理（矩形）、輸入輸出（平行四邊形）、連接（圓形）、換頁連接（向下的五邊形箭頭）、數據流（箭頭）。

4.面對復雜的系統時，一個比較好的方法是分層次的描繪這個系統。

5.數據流圖（DFD）是一種圖形化技術，他面會信息流和數據從輸入移動到輸出的過程中所經受的變換。6.數據流圖是系統邏輯功能的圖形表示。

7.數據流圖符號：正方形（或立體型）表示數據的源點或終點；圓角矩形（或圓形）代表數據變換的處理；開口矩形（或兩條平行線）代表數據存儲；箭頭代表數據流，即特定數據流動的方向。8.數據存儲和數據流都是數據，僅僅所處的狀態不同，數據存儲是處于靜止狀態的數據，數據流是處于運動中的數據。9.畫數據流圖的基本目的是利用它作為交流信息的工具。另一個主要的用途是作為分析和設計的工具。

10.數據字典是關于數據信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。、11.數據流圖和數據字典共同構成系統的邏輯模型，沒有數據字典，數據流圖就不嚴格，然而沒有數據流圖，數據字典也難以發揮作用。12.數據字典4類元素的定義組成：數據流；數據流分量（即數據元素）；數據存儲；處理。

13.數據字典中記錄數據元素的下列信息：一般信息；定義；使用特點；控制信息和分組信息。

14.數據元素組陳的方式：順序、選擇、重復，可選。15.“=”:等價于或定義為；“+”；和（即連接兩個分量）；“【】”：或（即，從方括弧內列出的若干分量中選擇一個），通常用“|”號隔開供選擇的分量；“{}”：重復；“（）”：可選。

16.數據字典最重要的用途是作為分析階段的工具。

17.卡片形式書寫數據字典：開片：名字、別名、描述、定義、位置。

18.軟軟開發成本主要表現為人力消耗。

19.估算技術：代碼行技術；任務分解技術；自動估算成本技術。20.成本/效益分析地第一步是估計開發成本、運行費用和新系統將帶來的經濟效益。

21.通常用利率的形式表示貨幣的時間價值。

22.通常用投資回收期衡量一項開發工程的價值。所謂投資回收期就是使累計的經濟效益等于最初投資所需要的時間。23.衡量工程價值的另一項經濟指是工程的純收入，也就是在整個生命周期之內系統的累計經濟效益與投資之差。需求分析 1.軟件系統的綜合要求：功能需求；性能要求；可靠性和可用性需求；出錯處理需求；接口需求；約束；你想需求；將來可能提出的要求。

2.分析系統的數據要求，這是軟件需求分析的一個重要任務，它通常采用建立數據模型的方法。

3.復雜的數據由許多基本的數據元素組成，數據結構表示數據元素之間的邏輯關系。

4.訪談是最早開始使用的獲取用戶需求的技術，也是迄今為止仍然廣泛使用的需求分析技術。他有兩種基本形式，分別是正式的和非正式的訪談。

5.軟件系統本質上是信息處理系統，而任何信息處理系統的基本功能都是把輸入數據轉變成需要的輸出信息。

6.結構分析方法就是面向數據流自頂而下逐步求精進行需求分析的方法。

7.面向團隊的需求收集法，稱為簡易的應用規格說明技術。這種方法提倡用戶與開發者密切合作，共同表示問題，提出解決方案要素，商討不同方案并指定基本要求。

8.面向團隊的需求方法的優點：開發者與用用戶不分彼此，齊心協力，密切合作；即時討論并求精；有能導出規格說明的具體步驟。

9.快速建立軟件原型是最準確、最有效、最強大的需求分析技術。他是快速建立起來的旨在演示目標系統主要功能的可運行的程序。

10.構建原型的要點是，他應該實現用戶看得見的功能，省略系統“隱含”功能。

11.快速模型的特性：快速；容易修改。

12.快隨構建和修改原型的方法和工具：第四代技術；可重構的軟件構件；形式化規格說明和原型環境。

13.通常，模型是由一組圖形符號和組織這些符號的規則組成。14.結構化分析實質上是一種創建模型的活動。

15.通過需求分析除了創建分析模型之外，還應該寫出軟件需求規格說明書，他是需求分析階段得出的最主要的文檔。16.通常用自然語言完整、準確、具體的描述系統的數據要求、功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求

17.概念性數據模型是一種面向問題的數據模型，是按照用戶的觀點對數據建立的模型。

18.數據模型包含三種續相互關聯的信息：數據對象、數據對象的屬性、數據對象彼此間相互連接的關系。19.聯系：一對一；一對多；多對多。

20.ER圖（實體-聯系圖）包含了實體、關系、屬性，通常用矩形代表實體，用連接相關實體的菱形表示關系，用橢圓形或圓角矩形表示實體的屬性，并用直線把實體與其屬性連接起來。21.通常用“范式”定義消除數據冗余的程度。第一范式（1NF）數據冗余程度最大，第五范式（5NF）數據冗余程度最小。22.狀態轉換圖（簡稱狀態圖）通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統地行為。

23.狀態是任何可以被觀察到得系統行為模式，一個狀態代表系統的一種行為模式。

24.在狀態圖中定義的狀態主要有：初態、終態和中間狀態。在一張狀態圖中只能有一個初態，而終態則可以有0至多個。25.事件就是引起系統動作或轉換狀態的控制信息。

26.狀態圖中，初態用實心圓表示，終態用一對同心圓表示，中間狀態用圓角矩形表示。

27.活動表語法格式：事件名(參數表)/動作表達式；三種事件：entry（進入該狀態的動作）, exit（退出該狀態的動作）, do（該狀態下的動作）。

28.事件表達式的語法格式：事件說明【守衛條件】/動作表達式；守衛條件為真時，狀態轉換發生。

29.層次方框圖用樹形結構的一系列多層次的矩形框描繪的數據的層次結構。

30.Warnier圖和層次方框圖相似，W圖也用樹形層次結構描繪信息，但是這種圖形工具比層次方框圖提供了更豐富的秒胡手段。

31.IPO圖是輸入、處理、輸出圖的簡稱。一種圖形工具，能夠方便的描繪輸入數據、對數據的處理和輸出數據之間的關系。32.驗證軟件需求的4個方面：一致性、完整性、現實性、有效性。

33.PSL/PSA（問題陳述語言/問題陳述分析程序）系統：功能：描述任何應用領域的信息系統；創建一個數據庫保存對該信息系統的描述符；對描述符施加增加、刪除和更改等操作；產生格式化的文檔和關于規格說明書的各種分析報告。

34.PSL/PSA系統用描述符從系統信息流、系統結構、數據結構、數據導出、系統規模、系統動態、系統性質和羨慕管理共8個方面描述信息系統。第五章:總體設計

總體設計過程分為兩個階段: 1>.系統設計,確定系統的具體實現方案 2>.結構設計階段,確定軟件結構

總體設計的9個步驟: 1>.設想供選擇的方案 2>.選取合理的方案 3>.推薦最佳方案 4>.功能分解 5>.設計軟件結 6>.設計數據庫 7>.制定測試計劃 8>.書寫文檔 9>.審查和復查

書寫文檔(形成概要設計規格說明書): 1>.系統說明 2>.用戶手冊 3>.測試計劃 4>.詳細的實現計劃 5>.數據庫設計結果

模塊是由邊界元素限定相鄰程序元素的序列,而且有一個總體標識符代表它.(模塊式構成程序的基本構件)根據模塊數目和接口成本(模塊間的聯系成本)兩個因素來決定模塊的最適當數目.抽象:就是抽出事物的本質特征而暫時不考慮他們的細節.(抽象層次的過程實際上也是逐步求精的過程).抽象和求精是一對互補的概念,也是人類解決復雜問題時最常用,最有效的方法.抽象使得設計者能夠說明過程和數據，同時卻忽略了低層細節，求精則幫助設計者在設計過程中逐步揭示出低層細節。

信息隱藏原理指出:應該這樣設計和確定模塊,使得一個模塊內包含的信息(過程和數據)對于不需要這些信息的模塊來說是不能訪問的.局部化,是指把一些關系密切的軟件元素物理地放得彼此靠近,在模塊中使用局部數據元素是局部化的一個例子.模塊獨立性:使得每個模塊完成一個相對獨立的特定子功能,并且和其他模塊之間的關系很簡單.模塊的獨立程序由兩個標準度量：

1>.耦合:數據耦合，控制耦合，特征耦合，公共環境耦合，內容耦合

（盡量使用數據耦合，少用控制耦合和特征耦合，限制公共環境耦合的范圍，完全不用內容耦合）

2>.內聚:功能內聚,信息內聚,通信內聚,過程內聚,時間內聚,邏輯內聚,偶然內聚.啟發式規則: 1>.改進軟件結構提高模塊獨立性 2>.模塊規模應該適中

3>.深度,寬度,扇出和扇入都應適當 4>.模塊的作用或應該在控制域之內 5>.力爭降低模塊接口的復雜程度 6>.設計單入口單出的模塊 7>.模塊功能應該可以預測

層次圖和HIPO圖,結構圖(描繪軟件結構的圖形工具).結構圖:用尾部是空心圓表示傳遞的是數據,實心圓表示傳遞的是控制信息.面向數據流的設計方法:把信息流映射成軟件結構,信息流的類型決定了映射方法信息流類型:1>.交換流,2>.事務流 第六章:詳細設計

在設計人機界面過程中,遇到的4個問題: 1>.系統影響時間(長度,易變性)2>.用戶幫助設施(集成的/附加的幫助設施)3>.出錯信息處理

4>.命令交互(一個命令對應單一的功能)人機界面設計指南: 1>.一般交互指南涉及信息顯示,數據輸入和系統整體控制,因此這類指南是全局性的,忽略它們將承擔較大的風險.2>.信息顯示指南:用文字,圖形和聲音按位置移動和大小,使用顏色,分辨率和省略

3>.數據輸入指南:選擇命令,輸入數據和向系統提供輸入

過程設計的 工具: 1.程序流程圖

程序流程圖的缺點: 1>.程序流程圖本質上不是逐步求精的好工具,它誘使程序員過早的考慮程序的控制流程,而不去考慮程序的全局結構 2>.程序流程圖中用箭頭代表控制流,因此程序員不受任何約束,可以完全不顧結構程序設計的精神,隨意轉移控制 3>.程序流程圖不容易表示數據結構 2.盒圖 盒圖的特點:克服了程序流程圖的缺點,但自身缺點是不易擴展

1>.功能域(即一個特定控制結構的作用域)明確,可以從盒圖上一眼就看出來 2>.不能任意轉移控制

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

4>.很容易表現嵌套關系,也可以表示模塊的層次結構

3.PAD圖(問題分析圖):是用二維樹形結構的圖來表示程序的控制流.將這種圖翻譯成程序代碼比較容易

4.判斷表:能夠清晰的表示復雜的條件組合與應做的動作之間的對應關系.(在多重嵌套的條件選擇時)5.判定樹:容易繪制,易于理解,但不能判斷哪些組合不可能,葉子多

6.過程設計語言(偽碼):是用正文形式表示的數據和處理過程的設計工具.過程設計語言(PDL)的優點: 1>.可以作為注釋直接插在源程序中間

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

3>.已經有自動處理PDL的程序存在,而且可以自動由PDL生成程序代碼

程序復雜程序的定量度量 1.流圖:只要順序執行俄流向都能合并,忽略箭頭,每個節點都是連通的(用圓表示節點代表一條或多條語句,箭頭線成為邊,代表控制流)由邊和結點圍成的面積為區域,當計算區域數時應該包括圖形外部為被圍起來的那個區域.計算環形復雜度的方法: 1>.流圖的區域數等于環形復雜度

2>.流圖G的環形復雜度V(G)=E-N+2,其中E是流圖中邊的條數,N是節點數

3>.流圖G的環形復雜度V(G)=P+1,其中P是流圖中判定節點的數目 第七章: 1.通常把編碼和測試統稱實現

2.所謂編碼就是把軟件設計結果翻譯成某種程序設計語言書寫的程序

3.為了使程序容易測試和維護以減少軟件的總成本，所選用的高級語言有理想的模塊化機制，以及可讀性好的控制結構和數據結構。為了便于調試和提高軟件可靠性，語言特點應該是編譯程序能夠多地發下程序中錯的錯誤，為了降低軟件開發和維護的成本，選用的高級語言應該有良好的獨立編譯機制。4.選擇程序設計語言的使用標準： 1).系統用戶的要求 2).可以使用的編譯程序 3).可以得到的軟件工具 4).工程規模 5).程序員的知識

6).軟件可移植性要求 7).軟件的應用領域 5.編碼的風格: 1).程序內部的文檔 2).數據說明 3).語句說明 4).輸入輸出

5).效率（通算法提高和決定的）提高效率 ：

1).效率是性能的要求，因此應該在需求分析階段效率方面的要求

2).效率是靠設計來以高的

3).程序的效率和程序的簡單程序是一致的 6.討論效率問題： 1).程序運行時間 2).存儲器效率 3).輸入輸出效率 軟件測試基礎： 1.測試方法：

1).黑盒：如果已經知道了產品應該具有的功能，可以通過測試來檢驗是否每個功能都能正常使用。

2).白盒: 如果知道產品的內部工作過程，可以通過測試來檢驗產品內部動作是佛感召規格說明的規定正常進行

2.黑盒測試是在程序接口進行的 黑盒測試（功能測試）3.測試步驟： 模塊測試-》子系統測試-》系統測試-》驗收測試-》平行運行

4.測試階段的信息流： 1》軟件配置 2》測試配置 5.單元測試主要使用白盒測試技術，而且對多個模塊的測試可以并行的進行 6.測試重點： 1).模塊接口 2).局部數據接口 3).重要的執行通路 4).出錯處理器 5).邊界條件

7.軟件測試：為了發現錯誤而執行代碼過程 8.程序調試：為了診斷和改正程序中錯誤的錯誤代碼 9.集成測試是測試盒組裝軟件的系統化技術

10.驗證指的是保證軟件正確地實現了某個特定要求的一系列活動，而確認指的是為了保證軟件確實滿足了用戶需求而進行的一系列活動

11.需求分析階段產生的軟件需求規格說明書。第八章: 軟件維護：在軟件交付使用之后，為了改正錯誤或者滿足新的需要而修改的過程

改正性維護：把診斷和改正錯誤的過程稱為改正性維護

適應性維護：為了和變化了的環境適當的配合而進行的修改軟件的活動是既必要而又經常性的活動

完善性維護：在軟件使用的過程中，用戶往往提出增加新功能或修改已有功能的建議，還可能提出一般性的改進意見

預防性維護：為了改進未來的標準性或可靠性或為了給未來奠定更好的基礎而修改軟件

軟件維護的過程： 1.維護組織 2.維護報告：

⑴滿足維護要求表中提出的要求所需要的工作量 ⑵維護要求的性質 ⑶這項要求的優先次序 ⑷與修改有關的事后數據 3.維護的事件流 4.保存維護記錄 5.評價維護活動: ⑴每次程序運行平均失敗的次數 ⑵用于每一類維護活動的總人時數

⑶平均每個程序每種語言每種維護類型，所做的程序變動數 ⑷維護過程中增加或刪除一個原語句平均花費的人時數 ⑸維護每種語言所花費的人時數 ⑹一張維護要求表的平均周轉時間 ⑺不同維護類型所占的百分比

軟件的可維護性的定義：維護人員理解改動改正或改進這個軟件的難易程度

決定軟件可維護的因素主要有： 1).可理解性 2).可測試性 3).可修改性 4).可移植性 5).可重用性

重用指同一事物不做修改或稍加改動就在不同環境中多次重復使用

以下一個方面可以提高軟件的可維護性: 1).軟件中可使用的可重用的構件越多，軟件的可靠性越高，改正性維護需求需求就越少

2).軟件中可使用的可重用的構件越多，適應性和完整性就越容易，文檔影響軟件可維護性的決定因素

軟件系統的文檔可分為用戶文檔和系統文檔

軟件文檔應滿足下數要求: 1).必須描述如何使用這個系統 2).必須描述怎樣安裝和管理這個系統 3).必須描述系統需求和設計 4).必須描述系統的實現和測試

用戶文檔至少包含下數: 1).功能描述 2).安裝文檔 3).使用手冊 4).參考手冊 5).操作員指南

所謂系統文檔只從問題定義需求說明到驗收測試計劃，這樣一系列和實現有關的文檔

可維護性是所有軟件都應該具備的基本特點

代碼復審應該強調編碼風格和內部說明文檔這兩個影響可維護性的因素

配置復審在測試結束是進行正式的可維護性復審

配置復審的目的是保證軟件配置的所有成分都是完整的，一致的和可理解的

為了便于修改和管理已經編目歸檔了, 軟件在工程過程模型的六類活動： 1).庫存目錄分析 2).文檔重檔 3).逆向工程 4).代碼重構 5).數據重構 6).正向工程 第九章: 面向對象方法學的出發點和基本原則是盡可能模擬人類習慣的思維方式,使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法于過程，也就是使描述問題的問題空間與實現解決的解決空間在結構上盡可能一致

面向對象方法學具有以下4個要點: 1).認為客觀世界是又各種對象組成，任何事物都是對象 2).把所有對象都劃分成各種對象類，每個對象都定義了一組數據和一組方法

3).按照子類與父類的關系把若干個對象類組成一個層次結構的系統

4).對象彼此之間僅能通傳遞消息互相聯系

面向對象方法學的優點有: 1).與人類習慣的思維方法一致 2).穩定性好 3).可重用性好

4).較易開發大型軟件產品 5).可維護性好

由于以下因素使得面向對象方法所開發的軟件可維護性好: 1).穩定性比較好 2).較容易修改 3).容易理解 4).易于測試和調試

面向對象方法學中的對象是由描述該對象性的數據以及可以對這些數據施加的所有操作封裝在一起所構成的同意體

對象是封裝了數據結構以及施加在這些數據結構上的操作的封裝體

對象有如下基本特點: 1).以數據為中心 2).對象是主動的 3).實現了數據封裝 4).本質上具有并行性 5).模塊獨立性好

類就是對具有相同數據和相同操作的一組相似對象的定義

類是支持繼承的抽象數據類型而對象就是類的實例

實例就是由某個特定的類所描述的一個具體的對象

消息是要求某個對象執行在定義它的那個類中所定義的某個操作的規格說明

消息由三部分組成 1).接受消息對象 2).消息選擇符 3).零個或多個變元

方法就是對象所執行的操作，也就是類中所定義的服務

屬性就是類中所定義的數據，它是對客觀世界實體所具有的性質的抽象

對象具有封裝性的條件如下: 1).有一個清晰的邊界 2).有確定的接口 3).受保護的內部實現

繼承是指直接獲得已有的性質和特征而不必重復定義它們

多態性是指子類對象可以像父類對象那樣使用同樣的消息既可以發送給父類對象也可以發送給子類對象

函數重載是指同一個作用域內的若干個參數特征不同的函數可以使用相同的函數名字

運算符重載是指同一個運算符也可以施加于不同類型的操作數上面

所謂模型就是為了理解事物而對事物做出的一種抽象，是對事物一種無歧義的書面描述

用面向對象方法開發軟件通常需要建立3中模式: 1).描述系統數據結構的對象模型 2).描述系統控制結構的動態模型 3).描述系統的功能的功能模型

關聯是雙向的，可在一個方向上為關聯起一個名字，在另一個方向上起另一個名字

聚集也稱聚合，是關聯的特例聚集表示類與類之間的關系，是整體與部分的關系

共享聚集在聚集關系中處于部分個對象可同時參與多個屬于整體對象的構成

泛化關系就是通常所說的繼承關系，是通用元素和具體元素之間的一種分類關系

沒有具體對象的類稱為抽象類

預定義的類約束有四種: 1).多重 2).不相交 3).完全 4).不完全

多重繼承指的是一個子類可以同時多次繼承同一個上層基類

依賴關系描述兩個模型元素之間的語意連接關系，其中一個模型元素是獨立的，另一個模型元素不獨立，它依賴于獨立的獨立的模型元素

當對同一個事物在不同抽象層次上描述時這些描述之間具有細化關系

細化用來協調不同模型之間的關系，表示各個開發階段不同抽象層次之間的相關性 第十三章：

管理:通過計劃組織和控制等一系列活動,合理地配置和使用各種資源,以達到既定目標的過程.軟件項目管理貫穿于軟件的整個生命周期之中.軟件管理項目過程從一組項目計劃活動開始,而制定計劃的基礎是工作量估算和完成期限估算.為了使估算項目的工作量和完成期限,首先需要估算軟件的規模.度量軟件規模的技術: 1>.代碼行技術:比較簡單的定量估算軟件規模的方法.2>.功能點技術:依據對軟件信息域特性和軟件復雜性的評估結果估算軟件規模,用功能點(FP)為單位.信息域的五個特性:輸入項數,數出項數,查詢數,主文件數,我外部接口數.估算功能點的步驟: 1>.計算未調整的功能點數UFP 2>.計算技術復雜性因子TCF 3>.計算功能點數FP 工作量：軟件規模（KLOC或FP）的函數。單位：人月.工作量估算常用模型：靜態單變量模型，動態多變量模型，COCOMO2模型.COCOMO2構造性成本模型，給出了三個層次的軟件開發工作量估算模型：

1>.應用系統組織模型：主要用于估算構建原型的工作量。2>.早期設計模型：適用于體系結構設計階段。

3>.后體系結構模型：適用于完成體系結構設計之后的軟件開發階段。

成本因素分為：產品因素、平臺因素、人員因素、項目因素。COCOMO2使用的5個分級因素：項目先例性、開發靈活性、風險排除度、項目組凝聚力、過程成熟度。

工程網絡是系統分析和系統設計的強有力的工具，用箭頭表示作業(即消耗資源又需要持續一定時間),用圓圈表示事件(并不消耗時間和資源).制定進度計劃的工具有Gantt圖和工程網絡。

機動時間=它結束事件的最遲時刻-它開始事件的最早時刻-持續時間.人員組織： 1>.民主制程序員組

2>.主程序員組（特性：專業化、層次化）3>.現代程序員組

軟件質量：軟件與明確的和隱含的定義的需求相一致的程序.具體地說是：軟件與明確的敘述的功能和性能需求，文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特征相一致的程度.軟件質量保證措施：（軟件復審是最重要的之一）1>.基于非執行的測試 2>.基于執行的測試 3>.程序正確性證明

正式技術復審包括走查和審查.走查有兩種方式：參與者驅動法，文檔驅動法。審查的基本步驟：綜述，準備，審查，返工，跟蹤。

軟件配置管理員是應用于整個軟件過程中的保護性活動，是在軟件整個生命期內管理變化的一組活動。目標是使變化能夠更正確且更容易被適應，在需要修改軟件時減少為此而花費的工作量。

能力成熟度模型是改進軟件過程的有效策略，以增量方式逐步引入變量，明確定義了5個成熟度級。一個軟件開發組織可用一系列小的改良性步驟買入更高的成熟度等級。

第四篇：軟件工程知識點總結

軟件工程知識點總結

軟件工程知識點總結

1.軟件危機：指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。

2.軟件危機產生的原因：1.軟件本身的復雜性、難衡量的特點；2.軟件開發與維護的方法不正確。

3.軟件的定義：計算機程序、方法、規則、相關文檔資料以及在計算機上運行程序時所必需的數據

4.軟件不是程序，軟件是程序、數據以及相關文檔的完整集合。

5.程序是能夠完成預定功能和性能的可執行的指令序列；數據是使程序能夠適當地處理信息的數據結構；文檔是開發、使用和維護程序所需要的圖文資料。

6.軟件生命周期：一個軟件從定義、開發、使用和維護，直到最終被廢棄所經歷的一個漫長時期。

7.軟件開發的過程：

①問題定義：確定要求解決的問題是什么

②可行性研究：決定該問題是否存在一個可行的解決辦法

③需求分析：深入了解用戶的要求，在要開發的目標系統必須做什么問題和用戶取得完全一致的看法。④概要設計：概括回答怎樣實現目標系統。概要設計又叫邏輯設計、總體設計、高層設計。

⑤詳細設計：把解法具體化，設計出程序的詳細規格說明。詳細設計也叫模塊設計、底層設計。⑥編碼和單元測試：編寫程序的工作量只占軟件開發全部工作量的10%－20％。

⑦綜合測試：軟件測試的工作量通常占軟件開發全部工作量的40%－50％。

⑧軟件維護：軟件維護的費用通常占軟件總費用的55％－70%。

①②③為軟件定義時期，④⑤⑥⑦為軟件開發階段。④⑤為系統設計，⑥⑦為系統實現。

中國國家標準《計算機軟件開發規范》將軟件生命周期分為：可行性研究與計劃，需求分析，概要設計，詳細設計，實現，組裝測試，確認測試，使用和維護8個階段。

8.軟件工程：是指導計算機軟件開發和維護的工程學科。軟件工程采用工程的概念、原理、技術和方法來開發和維護軟件，結合正確的管理技術和先進可靠的技術方法，經濟地開發出高質量的軟件，并有效地維護它。

9.軟件工程方法學：方法、工具和過程。普遍使用的是傳統方法學和面向對象方法學。

10.瀑布模型：唯一被廣泛采用的模型，各階段間具有順序性和依賴性：前階段完成才能進行下一階段。文檔驅動。

原型模型：快速建立一個能反映用戶主要需求的原型系統讓用戶試用，并根據用戶意見修改原型。原型的用途是獲知用戶真正需求，一旦需求確定，原型將被拋棄。當用戶對系統的目標不是很清楚，難以定義需求，可用此法。

增量模型：也叫漸增模型。整個軟件被分解成許多各增量構件，設計人員分批地逐步向用戶提交產品，每次用戶都得到一個滿足部分需求的可運行產品。優點：能在短時間內向用戶提交可完成部分工作的有用產品，易于維護。

螺旋模型：使用原型及其他方法來盡量降低風險。它類似于原型法，不過在每個階段之前都增加了風險分析過程。

螺旋模型適用于內部開發的大規模軟件項目。螺旋模型的優勢在于它是風險驅動的。

V型模型：從需求分析就開始編寫測試計劃一直到系統交付。需求分析對應于驗收測試，概要設計對應于系統測試，詳細設計對應于集成測試，編碼對應于單元測試，這樣先產生計劃再執行測試,在測試的每個階段都進行審查.噴泉模型：是一種典型的適合于面向對象范型的過程模型，支持開發過程中的迭代。

瀑布模型注重凍結需求的理念、Up模型注重增量迭代/用例驅動、V型模型講究質量保證理念、Xp模型講究溝通。

11.實體－關系圖（E－R圖），用于建立數據模型，其中包含了實體、關系、屬性。

12.數據流圖（DFD）：描繪信息流和數據輸入輸出的移動過程。是結構化分析過程中使用的主要建模工具。功能建模。

13.狀態轉換圖：通過描述系統的狀態及引起系統狀態轉換的事件，表示系統的行為，提供了行為建模的機制。

3/29/2013 1

軟件工程知識點總結

14.數據字典：描述在數據模型、功能模型和行為模型中出現的數據對象和控制信息的特征，給出這些對象的精確定義。數據字典是分析模型的核心，通常使用CASE工具來創建和維護數據字典。

15.結構化設計的幾個階段：數據設計、體系結構設計、接口設計、過程設計（是詳細設計階段的主要任務）。

結構設計屬于概要設計階段。接口設計（包括I/O設計）和過程設計屬于詳細設計階段。人機界面設計屬接口設計。

16.基本設計原理：模塊化、抽象、逐步求精、信息隱藏、模塊獨立（功能獨立，和其它模塊沒有過多相互作用）。

模塊獨立的好處：易開發、易測試、易維護。模塊獨立程度的衡量標準：內聚和耦合。

17.內聚衡量模塊內各元素之間結合的緊密程度。耦合衡量不同模塊之間連接的緊密程度。

數據耦合→控制耦合→公共環境耦合→內容耦合（高）

（低內聚）偶然內聚→邏輯內聚→時間內聚→（中內聚）過程內聚→通信內聚→（高內聚）順序內聚→功能內聚

模塊獨立性設計原則：提高內聚，降低耦合18.表示軟件結構：層次圖、HIPO圖、結構圖。過程設計：程序流程圖、盒圖（N－S圖）、PAD圖、判定表、判定樹。

19.軟件測試分：單元測試和綜合測試。軟件項目管理從項目計劃開始，第一項計劃活動是估算。

白盒測試：也稱結構測試，邏輯驅動測試，基于代碼的測試，測試程序內部的邏輯結構和過程性細節，前期使用。

黑盒測試：即功能測試，在程序接口進行測試，測試后期使用。具體辦法：等價劃分、邊界值分析、錯誤推測。

20.IEEE 1058.1給出軟件項目管理計劃的框架；ISO9000－3標準適用于軟件的開發、供應、維護；

ISO/IEC12207是指導軟件過程實施的標準；ISO/IEC TR 15504是軟件過程評估標準。軟件質量保證－SQA。

21.軟件重用是降低軟件整體成本、提高軟件質量和開發生產率的合理有效途徑。

可重用的軟件成分：軟件的技術表示（結構模型、設計和代碼）、文檔、測試數據、與過程相關的任務（如審查）。

22.軟件可移植性：指軟件從某一環境移植到另一環境下的難易程度。為方便移植，要盡量采用通用的程序設計語言。

3/29/2013 2

第五篇：軟件工程知識點總結

軟件工程是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護上的過程。是一門指導軟件系統開發的工程學科，它以計算機理論及其他學科為指導，采用工程化的概念、原理、技術和方法進行軟件的開發和維護，把經實踐證明的學科的管理措施與最先進的技術方法結合起來，目標是以較少的投資獲取高質量的軟件。內容：方法與技術、工具與環境、管理技術、標準與規范。領域：軟件需求分析、軟件設計、軟件構造、測試和維護。難題 1.復雜性 2.不可見性 3.易變性 4.服從性 5.非連續性

計算機科學中與實踐相關的部分，都和數據以及其他學科發生關系。軟件工程和人的行為、現實社會的需求息息相關。

發展史：1.生產作坊方式2.面向對象的方法3.軟件過程工程4.軟件復用和基于構件的開發 學生做到：1.研發出符合客戶需求的軟件 2.通過一定的軟件流程，在預計的時間內發布足夠好的軟件 3.通過數據和其他方式展現所開發的軟件是可以維護和繼續發展。

單元測試（好標準）：1.在最基本的功能/參數上驗證程序正確性；2.由最熟悉代碼的人寫；3.測試后，機器狀態保持不變；4.要快；5.產生可重復、一致的結果；6.獨立性；7.覆蓋所有代碼路徑；8.集成到自動測試的框架中；9.和產品代碼一起保存和維護。

回歸測試：模塊出現退步，從正常退化到不正常狀態，為了驗證新改進的代碼的正確性。個人開發：計劃：估計時間（開發）：.需求分析.生成設計文檔.設計復審.代碼規范.具體設計.具體編碼.代碼復審.測試；記錄用時；測試報告；計算工作量；事后總結；提出改進計劃 個人在團隊中：1.通過交流實驗等方法理解問題、需求或任務2.提出多種解決辦法3.與相關角色交流解決問題的提案，決定一個可行方案4.執行5.和其他角色合作，測試實現方案，修復缺陷6.對結果負責

代碼規范：代碼風格規范：1.縮進2.行寬3.括號4.斷行與空白行5.分行6.命名7.下劃線8.大小寫9.注釋

代碼設計規范：1.函數2.goto3.錯誤處理4.處理C++中的類 代碼復審目的：1.找出錯誤代碼2.發現邏輯錯誤3.發現算法錯誤4.發現潛在錯誤5.發現可能需要改進的地方6.傳授經驗

代碼復審步驟：1.代碼成功編譯2.程序員必須測試過代碼3.程序與提出新的代碼，差異分析4.可選擇面對面復審，獨立復審5.面對面復審中，開發者控制流程，講述修改的前因后果，復審者有權打斷敘述提出自己意見7.開發者負責所有問題得到滿意解答8.達成一致意見 復審后：1.改正明顯的錯誤2.對無法解決的錯誤，記錄下來3.把所有錯誤記在“我常犯的錯誤”表中，作為以后自我復審的第一步

結對編程好處：1.在開發層次，提供更好的設計質量和代碼質量，解決問題能力強2.對開發人員，結對更有信心3.在企業管理層上，更有效的交流相互學習傳遞經驗，高投入產出比 如何結對編程：1.駕駛員：寫設計文檔，進行編碼和單元測試2.領航員：審閱文檔、編碼；考慮單元測試的覆蓋率；思考是否需要重構；幫解決技術問題3.不斷輪換角色，不連續一小時，領航員控制時間4.主動參與5.只有水平差距，沒有級別差距6.設置好結對編程環境 團隊模式：1.主治醫師2.明星3.社區4.業余劇團5.秘密團隊6.特工7.交響樂團8.爵士樂 開發方法： 統一流程（RUP）業務建模.需求.分析和設計.實現.測試.部署.配置和變更管理.項目管理.環境.敏捷開發原則：1.盡早并持續交付有價值的軟件滿足需求2.歡迎需求的變化3.經常發布可用軟件，間隔較短4.業務員與開發人員共同工作5.以有進取心的人為核心6.面對面交流7.可用軟件是衡量項目進展的主要指標8.可持續發展9.不斷關注技術和設計10.保持簡明 敏捷流程：1.找出完成產品所需要做的事2.決定當前沖刺需要解決的事3.沖刺 軟件需求：1.獲取和引導需求2.分析和定義需求3.驗證需求4.在軟件產品的生命周期中管理需求（功能性需求.開發過程需求.非功能性需求.綜合需求）需求獲取方法：用戶調查1.焦點小組2.深入面談3.卡片分類4.調查問卷5.用戶日志研究6.人類學調查7.眼動跟蹤研究8.快速原型調研9.a/b測試

利益相關者：用戶：直接使用軟件的人；客戶：購買軟件的人；市場分析師：代表典型用戶的需求；監管機構：符合行業和政策規定；軟件工程師：需求階段重要角色

項目經理PM：對項目流程負責，正確的協調團隊內部外部，調配各部門資源和時間，有效進行風險管理，保證一個項目按計劃結項。管事也管人，不一定做具體工作。應對風險：1.進一步研究2.接受3.規避4.轉移5.降低6.制定應急計劃

PM能力：1.觀察、理解和快速學習2.分析管理能力3.專業能力4.自省能力

典型用戶：名字.年齡.收入.代表的用戶在市場上的比例和重要性.典型場景.環境.生活情況.知識層次/能力.偏好

功能說明書 1.定義好相關概念2.規范好一些假設3.避免誤解，界定邊界條件4.描述主流用戶5.一些好的功能會有副作用6.服務質量說明 功能驅動設計：1.構造總體模型2.構造功能列表3.制定開發計劃4.功能設計階段5.實現具體功能

用戶體驗：1.用戶第一印象2.從用戶角度考慮問題3.軟件服務始終要記住用戶的選擇4.短期刺激和長期影響5.不讓用戶犯簡單錯誤6.用戶體驗和質量7.情感設計 評價標準：1.盡快提供可感觸的反饋2.系統界面符合用戶的現實慣例3.用戶有控制權4.一致性和標準化5.適合各種類型的用戶6.幫助用戶識別、診斷并修復錯誤7.有提示和幫助文檔 測試方法：1.單元測試2.代碼覆蓋率測試3.構建驗證測試4.驗收測試5.探索式測試6.回歸測試7.場景/集成/系統測試8.伙伴測試9.效能測試10.壓力測試11.內/外部公開測試

黑箱：把軟件系統當作一個黑箱，無法了解或使用系統的內部結構及知識。從軟件的行為而不是從內部結構出發來設計測試。白箱：設計者可以看到軟件系統的內部結構，并使用軟件的內部結構和知識來選擇測試數據及具體的測試方法。

軟件質量：1.程序的質量2.軟件工程的質量（開發過程可見性、風險控制、軟件內部模塊、開發成本控制、內部質量指標完成情況）

如何衡量：CMMI理論：一級初始級（企業項目目標實現），二級管理級（對項目流程審查，保證成功），三明確級（對管理體系制度化保障完成），四量化管理級（數字化管理，流程的穩定性），五級優化級（充分利用信息資料，主動改善流程）

如何衡量：1.軟件CC后DCR的數量2.用戶的好評3.在CC后發現bug的數量4.文檔完整性和準確性5.修復bug平均時間6.單位開發量出現最大bug數量7.測試用例的覆蓋率8.模塊的復雜程度9.代碼的行數10.文檔的數量和復雜程度11.有多少代碼重復12.平均每天構建失敗的次數13.實現了多少功能點14.軟件能運行多久，平均初次錯誤時間，無故障時間 會診：1.開發者提交參加會診的bug和修改方案2.會議決定是否同意修改方案3.執行

IT創新：1.靈光一閃，創新及隨其后2.大家都喜歡創新3.好的想法會贏4.創新者都是一馬當先5.要成為領域的專家6.技術是創新的關鍵7.成功的團隊更能創新

團隊合作階段：1.萌芽階段2.磨合階段3.規范階段4.創造階段5.團隊的效能曲線和假團隊 職業道德：1.行為與公眾利益一致2.以客戶和雇主利益最大化的方式做事3.確保自己的產品以及修改滿足專業標準4.具備完整獨立的專業判斷5.軟件項目的經理和領導人應提倡并親自采用復合道德規范的方法來管理軟件的開發和維護6.保證職業的誠信和榮譽7.公平對待同儕，并予以支持和幫助。

需求分析：四方面：對問題的識別、分析與綜合、制定規格說明書、評審；三原則：必須能夠表達和理解問題的數據域和功能域；必須按自頂向下、逐步分解的方式對問題進行分解和不斷細化；要給出系統的邏輯視圖和物理視圖。