軟體工程複習總結

 

1、 軟體危機是指在電腦開發過程中的開發和維護過程中所遇到的一系列的嚴重問題。
2、 軟體是程式、資料及相關文檔的完整集合，程式是能夠完成預定功能和效能的可執行
的程式序列；資料是是使程式能夠適當的處理資訊的資料結構；文檔是開發、使用和
維護程式所需要的圖文資料。
3、 軟體工程學包含3個要素：方法、工具、過程。
4、 目前使用最廣泛的軟體工程方法學是傳統方法學和物件導向方法學。
5、 軟體工程方法學的軟體過程基本上可以用瀑布模型來描述。
6、 瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型。
7、 Rup把軟體生命週期劃為：初始、精化、構建、移交階段。
8、 可行性研究的三方面：技術可行性、經濟可行性、操作可行性。
9、 資料流圖（DFD）是一種圖形化技術，他描繪資訊流和資料從輸入移動到輸出的過程
中所經受的變化。
10、 資料字典是關於資料資訊的集合，也就是對資料流程圖中所包含的所有元素的定
義的集合。
11、 資料流圖和資料字典共同構成系統的邏輯模型，沒有資料字典，資料如就不嚴格，
沒有流程圖，資料字典也難以發揮作用。
12、 需求分析階段結束之前，系統分析員應該寫出軟體需求規格說明書，以書面形式
準確的描述軟體需求。
13、 9、結構化分析方法就是面向資料流自頂向下逐步求精進行需求分析的方法。
14、 ER圖中包含了實體、關係和屬性，矩形代表實體，菱形表示關係，橢圓或圓角
矩形表示屬性，用直線把實體和其屬性串連。
15、 驗證軟體需求的正確性：一致性、完整性、現實性、有效性。
16、 總體設計的基本目的是回答"概括地說，系統應該如何?？"，總體設計又稱
為概要設或初步設計。
17、 模組的獨立程度可以有兩個定性標量度量：內聚和耦合。
18、 軟體測試的目標：（1）測試是為了發現程式中的錯誤而執行程式的過程；（2）好
的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；（3）成功的測試是發
現可至今為止尚未發現的錯誤的測試。
19、 軟體測試步驟：模組測試、子系統測試、系統測試、驗收測試、平行運行。
20、 軟體可靠性是程式在給定的時間點，按照規格說明書的規定，成功的啟動並執行機率。
21、 用物件導向方法開發軟體，通常需要建立3種形式的模型：描述系統資料結構的
物件模型，描述系統控制結構的動態模型和描述系統功能的功能模型。
22、 用物件導向方法開發軟體，在任何情況下，物件模型始終都是最重要、最基本的、
最核心的。
23、 通常，使用UML提供的類圖來建立物件模型。
24、 類與類之間通常有關聯、泛化（繼承）、依賴和細化等4種關係。
25、 在UML中，在一段為空白心的三角形的連線表示泛化關係。
26、 複雜問題的物件模型通常由：主題層、類與對象層、結構層、屬性層和服務層。
27、 廣義的說，軟體重用可分為知識重用、方法和標準的重用、軟體成分的重用。
28、 工程網路和Gantt圖同樣是安排進度和管理工程進度情況的強有力的工具。        
29、 3種典型人員組織方式：民主製程序員組、住程式員組、現代程式員組。
30、 軟體過程的輸出資訊可以分為3類電腦程式、描述電腦程式的文檔、資料，
這些項組成了軟體過程中產生的全部資訊，人們把他們統稱為軟體配置，而這些項就
是軟體配置項。
31、 Cmm把軟體過程從無序到有序的進化過程分成5個階段，並把這些階段排序，
形成五個逐層提高的等級。能力的成熟度等級的5個等級從低到高依次是：初始級（1級）、
可重複級（2級）、已定義級（3級）已管理級（4級）和最佳化級（5級）。

15、編碼風格：持續內部文檔、資料說明、語句構造、輸入輸出、效率、
32、 軟體危機的典型表現：對軟體開發成本和進度的估計常常很不準確；使用者對"已
完成"的軟體系統不滿意的現象經常發生；軟體產品品質往往靠不住；軟體常常是不
可維護的；軟體通常沒有適當的文檔資料；軟體成本在電腦總成本中所佔的比例逐
年上升；軟體開發生產效率提高的速度，遠遠跟不上電腦應用迅速普及深入的趨勢。
33、 軟體不同於硬體，他是電腦系統的邏輯組件而不是物理組件。
34、 軟體不同於一般程式，它的一個顯著特點就是規模龐大。
簡單題
1、軟體工程基本原理（1）用分階段的生存周期嚴格管理。（2）堅持進行階段評審。（3）
實行嚴格的產品控制。（4）採用現代程式設計技術。（5）結果應能清楚地審查。（6）開
發小組人員應該少而精。（7）承認不斷改進軟體工程實踐的必要性。
2、軟體生命週期各階段的基本任務  軟體生命週期由軟體定義程式、軟體開發和運行維護3
個時期組成，每個時期又進一步劃分成若干個階段。（1）問題定義 （2）可行性研究 （3）
需求分析 （4）總體設計 （5）詳細設計 （6）編碼和單元測試 （7）綜合測試（8）軟
件維護
3、需求分析的任務一、確定對系統的綜合要求（1）功能需求（2）效能需求（3）可靠
性和可用性需求（4）出錯處理需求（5）介面需求（6）約束（7）逆向需求（8）將來可
能提出的需求二、分析系統的資料要求
三、匯出系統的邏輯模型四、修正系統開發計劃
4、改進軟體設計的啟發學習法規則（1）改進軟體結構提高模組獨立性（2）模組規模應該適
中（3）深度、寬度、扇出和扇入都應適當（4）模組的範圍應該在控制域之（5）力爭
降低模組介面的複雜程度（6）設計單入口單出口的模組（7）模組功能應該可以預測
5、物件導向設計準則和啟發學習法原則
（1）模組化（2）抽象（3）資訊隱藏（4）弱耦合（5）強內聚（6）可重用
（1）設計結果應該清晰易懂（2）一般-特殊結構的深度應適當（3）設計簡單的類（4）
使用簡單的協議（5）使用簡單的服務（6）把設計變動減至最小
6、軟體維護的幾種類型
（1）改正性維護（2）適應性維護（3）完善性維護（4）預防性維護
7、決定軟體可維護性因素
（1）可理解性（2）可測試性（3）可修改性（4）可移植性（5）可重用性
8、軟體配置項
軟體配置的主要任務就是控制變化，同時也負責各個軟體配置項和軟體各種版本的標誌、
軟體配置審計以及軟體配置發生的任何變化的報告。（1）標識軟體配置中的對象（2）版
本控制（3）變化控制（4）配置審計（5）狀態報表
設計題
1、等價類別 有效/無效資料 邊界值測試
2、UML類圖的描述  3、N-S圖、PAD圖
論述題
（1） 軟體工程（2）可行性研究 問題定義階段必須回答的關鍵問題是："要解決的問題
是什麼"。如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會自白
浪費時間和金錢，最終得出的結果很可能是毫無意義的。儘管確切地定義問題的
必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。（3）
需求分析這個階段的任務仍然不是具體地解決客戶的問題，而是準確地回答"目標
系統必須做什麼"這個問題。（4）總體設計這個階段的基本任務是，概括地回答"怎
樣實現目標系統?"這個問題。概要設計又稱為初步設計、邏輯設計、高層設計或
總體設計。（5）詳細設計這個階段的任務還不是編寫程式，而是設計出程式的詳
細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工
程藍圖，它們應該包含必要的細節，程式員可以根據它們寫出實際的程式碼。
（6）編碼實現（語言，測試）這個階段的關鍵任務是寫出正確的容易理解、容易
維護的程式模組。（7）維護維護階段的關鍵任務是，通過各種必要的維護活動使
系統持久地滿足使用者的需要。（8）物件導向技術（9）專案管理

1.軟體工程學：為了更有效地開發與維護軟體，軟體工作者早20世紀60年代後期開始認
真研究消除軟體危機的途徑，從而逐漸形成了一門新興的工程學科。
2.軟體危機典型變現：
  (1).對軟體發開成本和進度的估計常常不準確.
  (2).使用者對"已完成的"軟體系統不滿意的現象經常發生.
  (3).軟體產品的品質往往靠不住.
  (4).軟體常常是不可維護的.
  (5).軟體通常沒有適當的文檔資料.
  (6).軟體成本在電腦系統總成本中所佔的比例逐年上升.
  (7).軟體開發產生率提高的速度,遠遠跟不上電腦應用迅速普及深入的趨勢.
3.產生軟體危機的原因:
  (1).軟體不同於硬體,它是電腦系統中的邏輯組件而不是物理組件.
  (2).軟體不同於一般程式,它的一個顯著特點是規模龐大,而且程式複雜性將隨著程式規
模的增加而呈指數上升.
  (3).軟體本身專屬的特點確實給開發和維護帶來一些客觀困難.
  (4)與軟體開發和維護有關的許多錯誤認識和做法形成,可以歸因於在電腦系統發展的
早期階段軟體開發的個體特點.
4.消除軟體危機的途徑:
  (1).應該對電腦軟體有一個正確的認識.
  (2).充分認識到軟體開發不是某種個體勞動的神秘技巧,而應該是組織良好、管理嚴密、
各類人員協同配合、共同完成的工程項目.
  (3).在使用要總結出成功的技術和方法,儘快消除錯誤概念和做法.
  (4).開發和使用更好的軟體工具
5.軟體工程的本質特性:
  (1).軟體工程關注於大型程式的構造.
  (2).軟體工程的中心課題是控制複雜性.
  (3).軟體經常變化.
  (4).開發軟體的效率非常重要.
  (5).和諧地合作是開發軟體的關鍵.
  (6).軟體必須有效地支援它的使用者.
  (7).在軟體工程領域中通常由具有一種文化背景的人替具有另一種文化背景的人創造產
品.
6.軟體工程的原理:
  (1).用分段的生命週期計劃嚴格管理.
  (2).堅持進行階段評審.
  (3).實行嚴格的產品控制.
  (4).採用現代程式設計技術.
  (5).結果應能清楚地審查.
  (6).開發小組的人員應該少而精.
  (7).承認不斷改進軟體工程實踐的必要性.
7.軟體生命週期：由軟體定義程式、軟體開發和運行維護3個時期組成,每個時期又進一步劃
分成若干個階段.
8.軟體開發時期4個階段:總體設計,詳細設計,編碼和單元測試,綜合測試.
9.軟體維護,維護階段的關鍵任務是,通過各種必要的維護活動使系統持久地滿足使用者的
需要.
10.瀑布模型的特點:
  (1).階段間具有順序性和依賴性.
  (2).延遲實現的觀點.
  (3).品質保證的觀點.
11.快速原型模型:是快速建立起來的可以在電腦啟動並執行程式,它所能完成的功能往往是
最終產品能完成的功能的一個子集.
12.快速模型的主要優點是不帶饋環的,軟體產品基本上是線性順序進行的.
13.可行性研究的目的:用最小的代價在儘可能短的時間內確定問題是否能夠解決.
14.可行性的解法:
  (1)技術可行性.(2)經濟可行性.(3)操作可行性.
15.可行性研究過程步驟:
  (1).複查系統規模和目標.
  (2).研究目前正在使用的系統.
  (3).匯出新系統的高層邏輯模型.
  (4).進一步定義問題.
  (5).匯出和評價供選擇的解法.
  (6).推薦行動方針.
  (7).草擬開發計劃.
  (8).書寫文檔提交審查.
16.系統流程圖:是概括地描繪物理系統的傳統工具.它的基本思想是用圖形符號以黑盒子
形式描繪組成系統的每個組件.
17.資料流圖(DFD):是一種圖形化技術,它描繪資訊流和資料從輸入移動到輸出的過程中所
經受的變換.
18.資料字典:是關於資料的資訊的集合,就是對資料流圖中包括的所有元素的定義的集合.
19.資料字典組成元素:(1)資料流.(2)資料流分量.(3)資料存放區.(4)處理.
20.定義資料的方法:定義絕大多數複雜事物的方法,都是用被定義的事物的成分的某種組
合表示這個事物,這些組成成分又由更底層的成分的組合來定義.
21.資料字典最重要用途:作為分析階段的工具。
22.為什麼要進行需求分析：因為它的基本任務是準確地回答"系統必須做什嗎？"這個
問題。可行性研究階段只是粗略瞭解使用者的需求，許多細節被忽略，然而最終的系統
中卻不能遺漏任何細節。所以可行性研究並不能代替需求分析。
23.軟體系統綜合要求：(1)功能需求.(2)效能需求.(3)可靠性和可行性需求.(4)出錯處理需
求.(5) 介面需求.(6)約束.(7)逆向需求.(8)將來可能提出的要求.
24.訪談:是最早開始使用的擷取使用者需求的技術,是迄今為止仍然廣泛使用的需求分析技
術.
25.需求分析過程3種模型:資料模型、功能模型和行為模型.
26.資料模型包含3種相互關聯資訊:資料對象、資料對象的屬性及資料對象彼此間相互
串連的關係.
27.總體設計的目的:就是回答"概括地說,系統應該如何??"這個問題.
28.總體設計兩個過程:系統設計階段,確定系統的具體實現方案;結構設計階段,確定軟體
結構.
29.總體設計過程步驟: (1)設想供選擇的方案.(2)選取合理的方案.(3)推薦最佳方案.(4)功能
分解.(5)設計軟體結構.(6)設計資料庫.(7)制定測試計劃.(8)書寫文檔.(9)審查和複查.
30.模組化:就是把程式劃分成獨立命名且可獨立訪問的模組,每個模組完成一個子功能,把
這些模組整合起來構成一個整體,可以完成指定的功能滿足使用者的需求.
31.怎做到模組獨立:開發具有獨立功能而且和其他模組之間沒有過多的相互作用的模組.
32模組獨立兩個定性標準度量:內聚和耦合.
33.耦合:對一個軟體結構內不同模組之間互連程度的度量.
34.內聚:標誌著一個模組各個元素彼此結合的緊密程度,它是資訊隱藏和局部化概念的自
然擴充.
35.功能內聚10分 順序內聚9分 通訊內聚7分 過程內聚5分 時間內聚3分 邏輯內聚
1分 偶然內聚0分
36.設計時要力爭做到高內聚,低耦合.
37.啟發學習法規則介紹:
  (1).改進軟體結構提高模組獨立性.
  (2).模組規模應該適中.
  (3).深度、寬度、扇出和扇入都應適當.
  (4).模組的範圍應該在控制域之內.
  (5).力爭降低模組介面的複雜程度.
  (6).設計單入口單出口的模組.
  (7).模組功能應該可以預測
38.交換流:資訊沿輸入通訊路進入系統,同時由外部形式變換成內部形式,進入系統的資訊
通過變換中心,經加工處理以後再沿輸出路變成外部形式離開軟體系統.
39.事務流:資料沿輸入通路到達一個處理T,這個處理根據輸入資料的類型在若干個動作
序列中選出一個來執行.
40.詳細設計目標:確定應該怎樣具體地實現所要求的系統.
41.結構程式設計:如果一個程式的代碼塊僅僅通過順序、選擇和迴圈這3種基本控制結構
進行串連,並且每個代碼只有一個入口和一個出口.
42.實現:通常把編碼和測試統稱.
43.編碼:就是那軟體設計結果翻譯成用某種程式設計語言書寫的程式.
44.測試方法:黑箱測試(知產品的功能可測試)和白盒測試(知產品內部工作過程可測試)
45.測試步驟:(1)模組測試.(2)子系統測試.(3)系統測試.(4)驗收測試.(5)平行運行.
46.測試重點:(1)模組介面(2)局部資料結構(3)重要的執行通路(4)出錯處理通路(5)邊界條件.
47.確認測試:也稱驗收測試,它的目標是驗收軟體的有效性.
48.Alpha測試:由使用者在開發人員的場所進行,並且在開發人員對使用者的"指導"下進行測試.開
發者負責記錄發現的錯誤和使用中遇到的問題.
49.Beta測試:由軟體的終端使用者在一個或多個客戶場所進行.與Alpha測試不同,開發人員通
常不在Beta測試的現場,因此,Bate測試時軟體在開發人員不能控制的環境中的"真實"應
用.
50.調試:是在測試發現錯誤之後排除錯誤的過程.
51.軟體維護:就是在軟體已經交付使用之後,為了改正錯誤或滿足新的需要而修改的過程.
52.改正性維護:診斷和改正錯誤的過程.
53.決定軟體維護性的因素:(1)可理解性.(2)可測試性.(3)可修改性.(4)可移植性.(5)可重用
性.
54.使用者文檔:是使用者瞭解系統的第一步,它應該能使使用者獲得對系統的準確的初步印象.
55.使用者文檔包括的內容:(1)功能描述(2)安裝文檔(3)使用手冊(4)參考手冊(5)操作員指南.
56.系統文檔:指從問題定義、需求說明到驗收測試計劃這樣一系列和系統實現有關的文
檔.