第一章 軟體工程概論

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.什麼是軟體工程環境 :

方法與工具的結合, 加上配套的軟、 硬體支援稱為軟體工程環境。 它能支援開發者按照軟體 工程的方法 , 全面完成生存週期中的各項任務。

第二章 可行性研究

(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. 結構化程式設計的基本原則 ?

在詳細設計中所有模組都使用單入口、單出口的順序、選擇、迴圈三種基本控制結構 .

相同點:

(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. 軟體測試的基本任務?

軟體測試是按照特定的規則, 發現軟體錯誤的過程; 好的測試方案是儘可能發現迄今尚 未發現錯誤的測試;成功的測試方案是發現迄今尚未發現錯誤的測試;