軟件工程名詞解釋和簡答題總結

1、軟件工程名詞解釋和簡答題總結名詞解釋總結：-9 軟件開發(fā)環(huán)境-8 錯誤推測法-7 .黑盒測試法-6 軟件質(zhì)量保證-5 .瀑布模型-4.軟件危機-3.軟件工程-2.軟件生存周期-1.軟件生存周期模型0.軟件開發(fā)方法1、需求分析2、白盒法3、黑盒法4、漸增式測試5、非漸增式測試6、可執(zhí)行的規(guī)格說明7、經(jīng)濟可行性8、系統(tǒng)設計說明書9、面向對象設計10、結構化設計11、結構化分析12、基于腳本的設計13、IDEF 方法14、JSP方法15、軟件概要設計16、信息隱蔽17、系統(tǒng)流程圖18、集成測試19、附加策略20、拋棄策略21、抽象22、參數(shù)化抽象23、靜態(tài)測試24、原型25、事件26、動態(tài)冗余27、

2、模塊化28、JSP方法29、模型30、瀑布模型31、增量模型32、噴泉模型33、功能模型34、動態(tài)模型35、對象模型36、貨幣的時間價值37、類38對象39、多態(tài)性40、風險分析41、模塊42、JSD方法43、路徑覆蓋44、判定/條件覆蓋45、條件組合覆蓋46、條件覆蓋47、原型模型48、軟件工程環(huán)境49、程序圖50、結構化分析方法51、數(shù)據(jù)流圖52、字據(jù)字典53.IDEF 方法54. 概要設計55. 耦合性56. 內(nèi)聚性57. 無直接耦合58. 數(shù)據(jù)耦合59. 標記耦合60. 控制耦合61. 公共耦合62. 內(nèi)容耦合63. 偶然內(nèi)聚64. 邏輯內(nèi)聚65. 時間內(nèi)聚66. 通信內(nèi)聚67. 順序

3、內(nèi)聚68. 功能內(nèi)聚69. 軟件結構70. 控制范圍71. 作用范圍72. 變換流73. 事物流74. 程序設計風格75. 集成測試76. 非漸增式77. 漸增式78. 確認測試79. 軟件的可維護性80. 對象81. 類82. 類結構83. 消息84. 軟件質(zhì)量85. 質(zhì)量保證86. 軟件可靠性87. 軟件評審88. 容錯定義89. 軟件配置管理90. 基線-9 指在計算機的基本軟件的基礎上，為了支持軟件的開發(fā)而提供的一組工具軟件系統(tǒng)-8 .在測試程序時，人們可能根據(jù)經(jīng)驗或直覺推薦程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。-7 把被測試對象看成一個黑盒子，測試

4、人員完全不考慮程序的內(nèi)部結構和處理過程。-6 .是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品確保軟件產(chǎn)品從誕生到消亡為止的所有階段的 質(zhì)量的活動，即確定、達到和維護需要的軟件質(zhì)量而進行的所有有計劃、有系統(tǒng)的管理活動。-5 將軟件生存周期各個活動規(guī)定為依線性順序連接的若干階段的一種軟件開發(fā)模型。它包括可行性分析、項目開發(fā)計劃、需求分析、概要設計、詳細設計、編碼、測試和維護。-4.軟件危機：軟件發(fā)展第二階段的末期，由于計算機硬件技術的進步。一些復雜的、大型的軟件開發(fā)項目提出來了， 但，軟件開發(fā)技術的進步一直未能滿足發(fā)展的要求。在軟件開發(fā)中遇到的問題找不到解決的辦法， 使問題積累起來，形成了尖銳的矛盾， 因

5、而導致了軟件危 機。-3.軟件工程：用科學的原理和理論定義，開發(fā)、維護軟件的學科。-2.軟件生存周期：一個軟件從提出開發(fā)要求開始直到該軟件報廢為止的整個時期。包括： 可行性分析和項目開發(fā)計劃、需求分析、概要設計、詳細設計、編碼、測試、維護等.-1.軟件生存周期模型：是描述軟件開發(fā)過程中各種活動如何執(zhí)行的模型。（模型：是為了理解事物而對事物做出一種抽象， 它忽略不必要的細節(jié)，它也是事物的一種抽象形式、 一個規(guī) 劃、一個程式。）0.軟件開發(fā)方法：用早就定義好的技術集合和符號表示習慣來組織軟件生產(chǎn)的過程。主要有：結構方法、Jackson方法、維也納開發(fā)方法（VDM）、面向對象的開發(fā)方 法1、需求分析

6、：需求分析是指開發(fā)人員要準確理解用戶的需求，進行細致的調(diào)查分析，將用戶非形式的需求陳述轉化成完整的需求定義，再由需求定義轉換到相應的形式功能規(guī)約（需求規(guī)格說明）的過程。2、白盒法：該方法把測試對象看作一個打開的盒子，測試人員須了解程序的內(nèi)部結構和處理過程，以檢查處理過程的細節(jié)為基礎， 對程序中盡可能多的邏輯路徑進行測試，檢查內(nèi)部控制結構和數(shù)據(jù)結構是否有錯，實際的運行狀態(tài)與預期的狀態(tài)是否一致。白盒法也不可能進 行窮舉測試。3、黑盒法：該方法把被測試對象看成一個黑盒子，測試人員完全不考慮程序的內(nèi)部結構和 處理過程，只在軟件接口處進行測試，依照需求規(guī)格說明書，檢查程序是否滿足功能要求。 因此，黑盒測

7、試又稱為功能測試或數(shù)據(jù)驅動測試。4、漸增式測試：逐個把未經(jīng)過測試的模塊組裝到已經(jīng)過測試的模塊上去，進行集成測試。 每加入一個新模塊進行一次集成測試，重復此過程直至程序組裝完畢。5、非漸增式測試：首先對每個模塊分別進行單元測試，然后再把所有的模塊按設計要求組 裝在一起進行測試。6、可執(zhí)行的規(guī)格說明：這是一種使要求說明過程自動化的技術，通過可執(zhí)行的規(guī)格說明語 言來描述預期的行為“做什么”，人們可以從直接觀察中用規(guī)格說明語言來規(guī)定任何系統(tǒng)行 為。7、經(jīng)濟可行性：對組織的經(jīng)濟狀況和投資能力進行分析，對系統(tǒng)建設，運行和維護費用進 行估算，對系統(tǒng)建成后可能取得的社會及經(jīng)濟效益進行估計。8、系統(tǒng)設計說明書：

8、是從系統(tǒng)總體的角度出發(fā)對系統(tǒng)建設中各主要技術方面的設計進行說明，是系統(tǒng)設計階段的產(chǎn)物，其著重點在于闡述系統(tǒng)設計的指導思想以及所采用的技術路線和方法，編寫系統(tǒng)設計說明書將為后續(xù)的系統(tǒng)開發(fā)工作從技術和指導思想上提供必要的保證。9、面向對象設計：是把分析階段得到的需求轉變成符合成本和質(zhì)量要求的、抽象的系統(tǒng)實 現(xiàn)方案的過程?；蛘哒f，面向對象設計就是用面向對象觀點建立求解域模型的過程。10、 結構化設計：面向數(shù)據(jù)流的設計是以需求分析階段產(chǎn)生的數(shù)據(jù)流圖為基礎，按一定的步驟映射成軟件結構，因此又稱結構化設計（SD）。11、 結構化分析：是根據(jù)分解與抽象的原則，按照系統(tǒng)中數(shù)據(jù)處理的流程，用數(shù)據(jù)圖來建立系統(tǒng)的功

9、能模型，從而完成需求分析工作。12、 基于腳本的設計：此方法主要用于解決要求的驗證問題。一個腳本將模擬在系統(tǒng)運行期 間用戶經(jīng)歷的事件，它提供了輸入、處理、輸出的屏蔽，以及有關對話的一個模型，開發(fā)者能夠給用戶顯示一個系統(tǒng)的逼真視圖。13、 IDEF方法：是美國空軍在1981年針對集成化計算機輔助制造（簡稱ICAM）工程項目中 用于進行復雜系統(tǒng)分析和設計的方法，是在結構化分析與設計技術的基礎上提出來的。14、JSP方法：定義了一組以數(shù)據(jù)結構為指導的映射過程，他根據(jù)輸入、輸出的數(shù)據(jù)結構，按一定的規(guī)則映射成軟件的過程描述，即程序結構，而不是軟件的體系結構，因此該方法適于詳細設計階段。15、軟件概要設計

10、：進入了設計階段，要把軟件“做什么”的邏輯模型變換為“怎么做”的物理模型，即著手實現(xiàn)軟件的需求，并將設計的結果反應在“設計規(guī)格說明書”文檔中，所 以軟件設計是一個把軟件需求轉換為軟件表示的過程，最初這種表示只是描述了軟件的總的體系結構，稱為軟件的概要設計或結構設計。16、 信息隱蔽：指在設計和確定模塊時，使得一個模塊內(nèi)包含的信息（過程或數(shù)據(jù)），對于 不需要這些信息的其它模塊來說，是不能訪問的。17、系統(tǒng)流程圖：是描述物理系統(tǒng)的傳統(tǒng)工具，它用圖形符號來表示系統(tǒng)中的各個元素，例 如人工處理、數(shù)據(jù)處理、數(shù)據(jù)庫、文件、設備等。它表達了系統(tǒng)中各個元素之間的信息流動 的情況。18、 集成測試：是指在單元測

11、試的基礎上，將所有模塊按照設計要求組裝成一個完整的系統(tǒng) 進行的測試，故也稱組裝測試或聯(lián)合測試。19、 附加策略：是將原型用于開發(fā)的全過程，原型由最基本的核心開始，逐步增加新的功能 和新的需求，反復修改反復擴充，最后發(fā)展為用戶滿意的最終系統(tǒng)。20、 拋棄策略：是將原型用于開發(fā)過程的某一階段，促使該階段的開發(fā)結果更加完整、準確、一致、可靠，該階段結束后，原型隨之作廢。21、 抽象：是認識復雜現(xiàn)象過程中使用的思維工具，即抽出事物本質(zhì)的共同的特征而暫不考 慮它的細節(jié)，不考慮其它因素。22、參數(shù)化抽象：所謂參數(shù)化抽象，它是指當描述類的規(guī)格說明時并不具體指定所要操作的 數(shù)據(jù)類型，而是把數(shù)據(jù)類型作為參數(shù)。2

12、3、 靜態(tài)測試：指被測試程序不在機器上運行，而是采用人工檢測和計算機輔助靜態(tài)分析的 手段對程序進行檢測。24、 原型：是指模擬某種產(chǎn)品的原型模型。軟件開發(fā)中的原型是軟件的一個早期可運行的版本，它反映了最終系統(tǒng)的重要特征。25、事件：是指定時刻發(fā)生的某件事情。它是某事情發(fā)生的信號，它沒有持續(xù)時間，它是一種相對性的快速事件。26、 動態(tài)冗余：動態(tài)冗余的主要方式是多種模塊待機儲備，當系統(tǒng)檢測到某工作模塊出現(xiàn)錯 誤時，就用一個備用的模塊來頂替它并重新運行。 這里須有檢測、切換和恢復過程，故稱其 為動態(tài)冗余。27、 模塊化：是指解決一個復雜問題是自頂向下逐層把軟件系統(tǒng)劃分成若干模塊的過程，每 個模塊完成

13、一個特定的子功能， 所有的模塊按某種方法組裝起來， 成為一個整體，完成整個 系統(tǒng)所要求的功能。28、JSP方法：定義了一組以數(shù)據(jù)結構為指導的映射過程，它根據(jù)輸入、輸出的數(shù)據(jù)結構，按一定的規(guī)則映射成軟件的過程描述，即程序結構，而不是軟件的體系結構，因此該方法適于詳細設計階段。29、 模型：是為了理解事務而對事物做出一種抽象，它忽略不必要的細節(jié)，它也是事物的一 種抽象形式，一個規(guī)劃，一個程式。30、 瀑布模型：是將軟件生存各個活動規(guī)定為依線性順序聯(lián)接的若干階段的模型。它包括可 行性分析、項目開發(fā)計劃、需求分析、概要設計、詳細設計、編碼、測試和維護。它規(guī)定了由前至后，相互銜接的固定次序，如同瀑布流水

14、，逐級下落。31、 增量模型：是在項目的開發(fā)工程中以一系列的增量方式開發(fā)系統(tǒng)。增量方式包括增量開發(fā)和增量提交。增量開發(fā)是指在項目開發(fā)過程中以一定的時間間隔開發(fā)部分工作軟件；增量提交是指在開發(fā)周期內(nèi)，以一定的時間間隔增量方式向用戶提交工作軟件及相應穩(wěn)當。增量開發(fā)和增量提交可以同時使用，也可單獨使用。32、 噴泉模型：是一種以用戶需求為動力，以對對象作為驅動的模型，適合于面向對象的開發(fā)方法。他克服了瀑布模型不支持軟件重用和多項開發(fā)活動集成的局限性。噴泉模型使開發(fā)過程具有迭代性和無間隙性。系統(tǒng)某些部分常常重復工作多次，相關功能在每次迭代中隨之加入演化的系統(tǒng)。無間隙是指在分析、設計、實現(xiàn)等開發(fā)活動之間

15、不存在明顯的邊界。33、 功能模型：描述了系統(tǒng)的所有計算， 它表明一個計算如何從輸入值得到輸出值，他不考 慮所計算的次序。功能模型說明對象模型中操作的涵義、動態(tài)模型中動作的意義以及對象模 型中約束的意義。34、 動態(tài)模型：是與時間和變化有關的系統(tǒng)性質(zhì)。該模型描述了系統(tǒng)的控制結構，他表示了瞬時的、行為化的系統(tǒng)控制性質(zhì)。它關心的是系統(tǒng)的控制，操作的執(zhí)行順序。它從對象的事 件和狀態(tài)的角度出發(fā)，表現(xiàn)了對象的相互行為。35、對象模型：表示了靜態(tài)的、結構化的系統(tǒng)數(shù)據(jù)性質(zhì)，描述了系統(tǒng)的靜態(tài)結構，它是從客 觀世界實體的對象關系角度來描述，表現(xiàn)了對象的相互關系。36、 貨幣的時間價值：通常利用銀行的存款利息來表

16、示貨幣的時間價值。設年利率為I，現(xiàn) 存入p元，n年后得到本金和利息為 F。若不計復利，則P元在n年后的價值為：F=P*(1+ n*i)。反過來，若n年后能收入的本金和利息為F,則將來F元的現(xiàn)在價值（本金）P為：P=F/（1+ n*i）。可用這個公式來計算將來收入的現(xiàn)在價值。這是效益分析的最基本公式。37、類：具有相同或相似性質(zhì)的對象的抽象就是類。38、對象：是人們要進行研究的任何事物，從最簡單的整數(shù)到復雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規(guī)則、計劃或事件。類的具體化就是對象，也可以說類的實例是對象。39、 多態(tài)性：指相同的操作或函數(shù)、過程可作用于多種類型的對象上并獲得

17、不同結果。不同的對象，收到同一消息可以產(chǎn)生不同的結果，這種現(xiàn)象稱為多態(tài)性。40、風險分析：實際上就是貫穿在軟件工程上的一系列風險管理步驟，其中包括風險識別、 風險估計、風險管理策略、風險解決和風險監(jiān)督，它能讓人們主動“攻擊”風險。41、 模塊：模塊在程序重視數(shù)據(jù)說明、可執(zhí)行語句等程序對象的集合，或者是單獨命名和編 址的元素，如高級語言中的過程、函數(shù)、子程序等等。42、JSD方法：主要以活動事件為中心，通過有一串活動順序組合構成的進程，建立系統(tǒng)模 型，最后實現(xiàn)該模型。43、路徑覆蓋：指設計足夠的測試用例，覆蓋被測程序中所有可能的路徑。44、判定/條件覆蓋：指設計足夠的測試用例，使得判定表達式中的

18、每個條件的所有可能取 值至少出現(xiàn)一次，并使每個判定表達式所有可能的結果也至少出現(xiàn)一次。45、 條件組合覆蓋：是指設計足夠的測試用例，使的每個判定表達式中條件的各種可能的值 的組合都至少出現(xiàn)一次，條件組合覆蓋是比較強的覆蓋標準。46、 條件覆蓋：是指設計足夠的測試用例，使得判定表達式中每個條件的各種可能的值至少 出現(xiàn)一次。滿足條件覆蓋并不一定滿足判定覆蓋。47、原型模型：又稱快速原型模型，它是在開發(fā)真實系統(tǒng)之前，構造一個原型，在該原型的 基礎上，逐漸完成整個系統(tǒng)的開發(fā)工作。48、 軟件工程環(huán)境：美國國防部在STARS十劃中定義如下：“軟件工程環(huán)境是一組方法、過 程及計算機程序（計算機化的工具）

19、的整體化構件，他支持從需求定義、程序生成知道維護 的整個軟件生存期”。49、 程序圖：是退化的程序流程圖。也就是說，把程序流程圖中每個處理符號都退化成一個結點，原來連接不同處理符號的流線變成連接不同結點的有向弧，這樣得到的有向圖就叫程序圖。50、結構化分析方法：是采用自頂向下逐層分解的分析策略把一個復雜的系統(tǒng)分解成若干小 問題然后分別解決。51、數(shù)據(jù)流圖：簡稱 DFD,是SA（結構化分析）方法中用于表示系統(tǒng)邏輯模型的一種工具是一種功能模型作用：它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動和處理的過程，反映系統(tǒng)必須完成的邏輯功能52、字據(jù)字典：簡稱DD,就是用來定義數(shù)據(jù)流圖中的各個成分具體含義的，它以一種

20、準確的無二義性的說明方式為系統(tǒng)的分析設計及維護提供了有關元素的一致的定義和詳細的描述.53.IDEF方法：是美國空軍在 1981年針對集成化計算機輔助制造（Integrated ComputerAided Manufacturing,簡稱ICAM） 工程項目中用于進行復雜系統(tǒng)分析和設計的方法，是在結構化分析與設計技術的基礎上提出來的。54. 概要設計：是在需求分析的基礎上通過抽象和分解將系統(tǒng)分解成模塊，確定系統(tǒng)功能是 實現(xiàn)。55. 耦合性：也稱塊間聯(lián)系。指軟件系統(tǒng)結構中各模塊間相互聯(lián)系緊密程度的一種度量。模塊之間聯(lián)系越緊密，其耦合性就越強，模塊的獨立性則越差。56. 內(nèi)聚性：也稱塊內(nèi)聯(lián)系。指模

21、塊的功能強度的度量，即一個模塊內(nèi)部各個元素彼此結合的緊密程度的度量。模塊內(nèi)元素聯(lián)系越緊密，內(nèi)聚性越高。57. 無直接耦合：兩個模塊之間沒有直接的關系，它們分別從屬于不同模塊的控制與調(diào)用，它們之間不傳遞任何信息。58. 數(shù)據(jù)耦合：指兩個模塊之間有調(diào)用關系，傳遞的是簡單的數(shù)據(jù)值，相當于高級語言中的 值傳遞。59. 標記耦合：指兩個模塊之間傳遞的是數(shù)據(jù)結構。60. 控制耦合：指控制模塊調(diào)用另一個模塊時，傳遞的是控制變量，被調(diào)用塊通過該控制變量的值有選擇地執(zhí)行塊內(nèi)某一功能（控制變量）61. 公共耦合：通過一個公共數(shù)據(jù)環(huán)境相互作用的那些模塊間的耦合。（一個公式數(shù)據(jù)環(huán)境）62. 內(nèi)容耦合：一個模塊直接使用

22、另一個模塊的內(nèi)部數(shù)據(jù)，或通過非正常入口而轉入另一個 模塊內(nèi)部63偶然內(nèi)聚：一個模塊內(nèi)的各處理元素之間沒有任何聯(lián)系。64. 邏輯內(nèi)聚：模塊內(nèi)執(zhí)行幾個邏輯上相似的功能，通過參數(shù)確定該模塊完成哪一個功能。65. 時間內(nèi)聚：把需要同時執(zhí)行的動作組合在一起。66. 通信內(nèi)聚：指模塊內(nèi)所有處理元素都在同一個數(shù)據(jù)結構上操作，或者指各處理使用相同 的輸入數(shù)據(jù)或產(chǎn)生相同的輸出數(shù)據(jù)。67. 順序內(nèi)聚：一個模塊中各處理元素都密切相關于同一功能且必須順序執(zhí)行，前一功能元 素的輸出是下一功能元素的輸入。68. 功能內(nèi)聚：最強的內(nèi)聚，指模塊內(nèi)所有元素共同完成一個功能，缺一不可。69. 軟件結構：軟件系統(tǒng)的模塊層次結構，反

23、映了整個系統(tǒng)的功能實現(xiàn)，即將來程序的控制 體系70. 控制范圍：是模塊本身和它的下屬模塊的集合。71. 作用范圍：模塊中的一個判定影響的所有模塊的集合。作用范圍應該在控制范圍內(nèi)。72. 變換流由輸入、變換（或處理）、輸出三部分組成。73. 事物流：某個加工將它的輸入流分離成許多發(fā)散的數(shù)據(jù)流，形成許多加工路徑，并根據(jù)輸入選擇其中一個路徑來執(zhí)行這種特征的DFD稱為事物流。74. 程序設計風格：指一個人編制程序時所表現(xiàn)出來的特點、習慣、邏輯思路等。75. 集成測試：將模塊組合起來成為一個完整的系統(tǒng)對其進行測試。76. 非漸增式：將模塊先進行單元測試然后組裝在一起進行測試。77. 漸增式：逐個將未測試

24、的模塊組裝到已經(jīng)測試過的模塊上去進行集成測試，每加入一個就測試一次。78. 確認測試：按照需求規(guī)格說明書中的確定指標對系統(tǒng)進行功能與性能的測試。79. 軟件的可維護性：軟件能夠被理解、校正、適應及增強功能的容易程度。80. 對象：是客觀實體在問題域中的抽象。81. 類：具有相似或相同性質(zhì)的對象的抽象就是類。82. 類結構：類的結構通常有一般-具體（分類結構）整體-抽象（組裝結構）83. 消息：對象之間通信的構造。84. 軟件質(zhì)量：與確定的功能和性能需求一致、與成文的開發(fā)標準相一致、與所有專業(yè)開發(fā) 的軟件所期望的隱含特性相一致。85. 質(zhì)量保證：向社會和用戶提供滿意高質(zhì)量的產(chǎn)品確保軟件從誕生到消

25、亡為止的所有階段 的質(zhì)量的活動。86. 軟件可靠性：在規(guī)定的環(huán)境下和時間里軟件按要求的功能執(zhí)行的概率。87. 軟件評審：是一個過濾器，它使用在軟件開發(fā)的各個階段，通過軟件評審可以及時的發(fā)現(xiàn) 軟件中存在的問題然后加以改正。88. 容錯定義：規(guī)定功能的軟件在出現(xiàn)錯誤是仍然可以在一定程度上完成要求的功能、規(guī)定功能的軟件可以屏蔽錯誤、規(guī)定功能的軟件可以在出錯的時候自動恢復到正常的狀態(tài)、規(guī)定功能的軟件在一定的程度上有容錯的能力。89. 軟件配置管理：軟件配置管理（SCM用于整個軟件工程過程，目標是表示變更，控制變 更，確保變更的正確實施，報告變更。 SCM是用在整個軟件生存周期個階段中的變更活動。90.

26、 基線：是軟件生存周期中各開發(fā)階段的一個特定點，它的作用是把開發(fā)各階段的工作劃 分的更加明確化，使本來連續(xù)的工作在這些點上斷開，便于檢查于肯定階段成果。91. 數(shù)據(jù)字典：一個定義應用程序中使用的所有數(shù)據(jù)元素和結構的含義、類型、數(shù)據(jù)大小、格式、度量單位、精度以及允許取值范圍的共享倉庫。數(shù)據(jù)字典的維護獨立于軟件需求規(guī)格說明，并且在產(chǎn)品的開發(fā)和維護的任何階段，各個風險承擔者都可以訪問數(shù)據(jù)字典。它定義了原數(shù)據(jù)元素、組成結構體的復雜數(shù)據(jù)元素、重復的數(shù)據(jù)項、一個數(shù)據(jù)項的枚舉值以及可選的數(shù)據(jù)項。92. 數(shù)據(jù)流圖：是結構化系統(tǒng)分析的基本工具。一個數(shù)據(jù)流圖確定了系統(tǒng)的轉化過程、系統(tǒng)所操縱的數(shù)據(jù)或物質(zhì)的收集（存儲

27、），還有過程、存儲、外部世界之間的數(shù)據(jù)流或物質(zhì)流。 數(shù)據(jù)流模型把層次分解方法運用到系統(tǒng)分析上，這種方法很適用于事務處理系統(tǒng)和其它功能密集型應用程序。93. 數(shù)據(jù)流圖：描繪了系統(tǒng)的數(shù)據(jù)關系。分析實體聯(lián)系圖有助于對業(yè)務或系統(tǒng)數(shù)據(jù)組成的理解和交互，并暗示產(chǎn)品將有必要包含一個數(shù)據(jù)庫。相反，當你在系統(tǒng)設計階段建立實體聯(lián)系圖時，通常要定義系統(tǒng)數(shù)據(jù)庫的物理結構。94. 狀態(tài)轉換圖：實時系統(tǒng)和過程控制應用程序可以在任何給定的時間內(nèi)以有限的狀態(tài)存在。當滿足所定義的標準時，狀態(tài)就會發(fā)生改變，例如在特定條件下， 接收到一個特定的輸入激勵。這樣的系統(tǒng)是有限狀態(tài)機的例子。大多數(shù)軟件系統(tǒng)需要一些狀態(tài)建?；蚍治觯拖翊蠖鄶?shù)

28、系統(tǒng)涉及到轉換過程、數(shù)據(jù)實體和業(yè)務對象。95. 對話圖：在許多應用程序中，用戶界面可以看作是一個有限狀態(tài)機。在任何情況下僅有一個對話元素（例如一個菜單，工作區(qū)，行提示符或對話框）對用戶輸入是可用的。在激活 的輸入?yún)^(qū)中，用戶根據(jù)他所采取的活動，可以導航到有限個其它對話元素。因此，許多用戶界面可以用狀態(tài)轉換圖中的一種稱為對話圖來建模。對話圖描繪了系統(tǒng)中的對話元素和它們之間的導航連接，但它沒有揭示具體的屏幕設計。96. 類圖：面向對象的軟件開發(fā)優(yōu)于結構化分析和設計，并且它運用于許多項目的設計中，從而產(chǎn)生了面向對象分析、設計和編程的域。類圖是用圖形方式敘述面向對象分析所確定的類以及它們之間的關系。簡答

29、題總結：1、可行性研究的任務是什么？首先需要進行概要的分析研究，初步確定項目的規(guī)模和目標，確定項目的約束和限 制，把他們清楚地列舉出來。然后，分析員進行簡要的需求分析，抽象出該項目的邏輯 結構，建立邏輯模型。從邏輯模型出發(fā)，經(jīng)過壓縮的設計，探索出若干種可供選擇的主 要解決方法，對每種解決方法都要研究它的可行性，可從以下三個方面分析研究每種解 決方法的可行性。技術可行性：對要開發(fā)項目的功能、性能、限制條件進行分析，確 定在現(xiàn)有的資源條件下，技術風險有多大，項目是否能實現(xiàn)。經(jīng)濟可行性：進行開發(fā)成本的估算以及了解取得效益的評估，確定要開發(fā)的項目是否值得投資開發(fā)。社會可行性：要開發(fā)的項目是否存在任何侵

30、犯、妨礙等責任問題，要開發(fā)項目的運行方式在用 戶組織內(nèi)是否行得通，現(xiàn)有管理制度、人員素質(zhì)、操作方式是否可行。2、什么是模塊的影響范圍？什么是模塊的控制范圍？他們之間應該建立什么關系？一個模塊的作用范圍（或稱影響范圍）指受該模塊內(nèi)一個判定影響的所有模塊的集 合。一個模塊的控制范圍指模塊本身以及其所有下屬模塊（直接或間接從屬于它的模塊）的集合。一個模塊的作用范圍應在其控制范圍之內(nèi)，且判定所在的模塊應在其影響的模 塊在層次上盡量靠近。如果再設計過程中，發(fā)現(xiàn)模塊作用范圍不在其控制范圍之內(nèi)，可 以用上移判點”或下移受判斷影響的模塊，將它下移到判斷所在模塊的控制范圍內(nèi)”的方法加以改進。3、非漸增式測試與漸

31、增式測試有什么區(qū)別？漸增式測試如何組裝模塊？非漸增式測試方法把單元測試和集成測試分成兩個不同的階段，前一階段完成模塊的單元測試，后一階段完成集成測試。而漸增式測試往往把單元測試與集成測試和在 一起，同時完成。非漸增式需要更多的工作量，因為每個模塊都需要驅動模塊和樁模 塊，而漸增式利用已測試過的模塊作為驅動模塊或樁模塊，因此工作量較少。漸增式 可以較早的發(fā)現(xiàn)接口之間的錯誤，非漸增式最后組裝是才發(fā)現(xiàn)。漸增式有利于排錯， 發(fā)生錯誤往往和最近加進來的模塊有關，而非漸增式發(fā)現(xiàn)接口錯誤推遲到最后，很難判 斷是哪一部分接口出錯。漸增式比較徹底，已測試的模塊和新的模塊再測試。漸增 式占用的時間較多，但非漸增式

32、須更多的驅動模塊、樁模塊也占用一些時間。非漸增 式開始可并行測試所有模塊，能充分利用人力，對測試大型軟件很有意義。漸增式測試 有以下兩種不同的組裝模塊的方法：自頂向下組合。該方法只需編寫樁模塊，其步驟 是從頂層模塊開始，沿被測程序的軟件結構圖的控制路徑逐步向下測試，從而把各個模 塊都結合起來，它又有兩種組合策略：深度有先策略：先從軟件結構中選擇一條主控 制路徑，把該路徑上的模塊一個個結合進來進行測試，以便完成一個特定的子功能，接 著再結合其它需要優(yōu)先考慮的路徑。寬度有先策略：逐層結合直接下屬的所有模塊。 自低向上結合。該方法僅需編寫驅動模塊。其步驟為：把底層模塊組合成實現(xiàn)一個 個特定子功能的族

33、。為每一個族編寫一個驅動模塊，以協(xié)調(diào)測試用例的輸入和測試結 果的輸出。對模塊族進行測試。按軟件結構圖依次向上擴展，用實際模塊替換驅動 模塊，形成一個個更大的族。重復至步，直至軟件系統(tǒng)全部測試完畢。4、軟件質(zhì)量與軟件質(zhì)量保證的含義是什么？從實際應用來說，軟件質(zhì)量定義為：與所確定的功能和性能需求的一致性。與所成文的開發(fā)標準一致性。 與所有專業(yè)開發(fā)的軟件所期望的隱含特性的一致性。軟件質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品，確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動，即確定、達到和維護需要的軟件質(zhì)量而進行的所有有計劃、 有系統(tǒng)的管理活動。5、軟件工程標準化的意義是什么？都有哪些軟件工程

34、標準？積極推進軟件工程標準化，其道理是顯而易見的。僅就一個軟件開發(fā)項目來說， 有許多層次，不同分工的人員相互配合，在開發(fā)項目的各個部分以及各開發(fā)階段之間也 都存在許多聯(lián)系和銜接問題。如何把這些錯綜復雜的關系協(xié)調(diào)好，需要有一系列統(tǒng)一的 約束和規(guī)定。在軟件開發(fā)項目取得階段成果或最后完成是時，需要進行階段評價和驗收 測試。投入運行的軟件，其維護工作中遇到問題又與開發(fā)工作者有著密切的關系。軟件 的管理工作則滲透到軟件生存期的每一個環(huán)節(jié)。所有這些都要要求提供統(tǒng)一的行動規(guī)范和衡量準則，使得各種工作都有章可循。軟件工程的標準主要有以下三個：FIPS135是美國國家標準局發(fā)布的軟件文檔管理指南NSAC 39是

35、美國核子安全分析中心發(fā)布的安全參數(shù)顯示系統(tǒng)的驗證與確認。ISO5807是國際標準化組織公布（現(xiàn)已 成為中國的國家標準）的信息處理 一數(shù)據(jù)流程圖、程序流程圖、程序網(wǎng)絡圖和系統(tǒng)資 源圖的文件編制符號及約定。1、需求分析階段的基本任務是什么？需求分析階段的基本任務是要準確的定義新系統(tǒng)的目標，為了滿足用戶需要，回答系統(tǒng)必須做什么”的問題。本階段要進行以下幾方面的工作：問題識別。雙方確定對 問題的綜合需求，這些需求包括：功能需求、性能需求、環(huán)境需求、用戶界面需求，另 外還有可靠性、安全性、保密性、可移植性、可維護性等方面的需求。分析與綜合，導出軟件的邏輯模型。分析人員對獲取的需求，進行一致性的分析檢查，

36、在分析、綜合 中逐步細化軟件功能，劃分成各個子功能。這里也包括對數(shù)據(jù)域進行分解，并分配到各 個子功能上，以確定系統(tǒng)的構成及主要成份，并用圖文結合的形式，建立起新系統(tǒng)的邏 輯模型。編寫文檔。編寫 需求規(guī)格說明書”、編寫初步用戶使用手冊、編寫確認測試 計劃、修改完善軟件開發(fā)計劃。2、采用黑盒技術設計測試用例有哪幾種方法？這些方法各有什么特點？等價類劃分。等價類劃分是將輸入數(shù)據(jù)域按有效的或無效的（也稱合理的或不合 理的)劃分成若干個等價類，測試每個等價類的代表值就等于對該類其它值的測試。 邊界值分析。該方法是將測試邊界情況作為重點目標，選取正好等于，剛剛大于或剛剛 小于邊界值的情況，根據(jù)這些情況選擇

37、測試用例。錯誤推測。錯誤推測法沒有確定的 步驟，憑檢驗進行。它的基本思想是列出程序中可能發(fā)生錯誤的情況，根據(jù)這些情況選 擇測試用例。因果圖。因果圖能有效的檢測輸入條件的各種組合可能會引起的錯誤。因果圖的基本原理是通過畫因果圖，把用自然語言描述的功能說明轉換為判定表，最后為判定表的每一列設計一個測試用例。3、說明動態(tài)建模的過程。準備腳本。動態(tài)分析從尋找事件開始，然后確定各對象的可能事件的順序。在分析階段不考慮算法的執(zhí)行，算法是實現(xiàn)模型的一部分。 確定事件。確定所有外部事件。 事件包括所有來自或發(fā)往用戶的信息、外部設備的信號、輸入、轉換和動作。準備事 件跟蹤表。把腳本表示成一個事件跟蹤表，對象為表

38、中的列，給每一個對象分配一個獨 立的列。構造狀態(tài)圖。對各對象類建立狀態(tài)圖，反映對象接收和發(fā)送的事件，每個事 件跟蹤都對應于狀態(tài)圖中一條路徑。4、軟件生產(chǎn)經(jīng)歷了幾個階段？各有何特征？軟件生產(chǎn)至今已經(jīng)歷了三個階段：程序設計時代(1946-1956):這個階段的生產(chǎn)方式是個體手工勞動，使用的工具實際其語言、匯編語言。開發(fā)方法是追求編程技巧， 追求程序運行效率。硬件特征是價格貴、存儲容量小，運行可靠性差。軟件特征是只有 程序、程序設計概念，不重視程序設計方法。程序系統(tǒng)時代(1956-1968):這個階段的生產(chǎn)方式是作坊式的小集團合作生產(chǎn)，生產(chǎn)工具是高級語言，開發(fā)方法仍就靠個人技巧，但開始提出結構化方法

39、。硬件特征是速度、容量、工作可靠性有明顯提高。軟件特 征是程序員數(shù)量猛增， 但開發(fā)技術沒有新的突破， 開發(fā)人員的素質(zhì)和落后的開發(fā)技術不 適應規(guī)模大、結構復雜的軟件開發(fā)，導致軟件危機的產(chǎn)生。軟件工程時代(1968至今): 這個階段的生產(chǎn)方式是工程化的生產(chǎn)，使用數(shù)據(jù)庫、開發(fā)工具、開發(fā)環(huán)境、網(wǎng)絡、分布 式、面向對象技術來開發(fā)軟件。硬件特征是向超高速、大容量、微型化以及網(wǎng)絡化方向 發(fā)展。軟件特征是開發(fā)技術有很大進步，但是未能獲得突破性進展，軟件價格不斷上升，沒有完全擺脫軟件危機。5、簡述Gantt圖的功能及不足。Gantt圖常用水平線段來描述把任務分解成子任務，以及每個子任務的進度安排， 動態(tài)反映軟件

40、開發(fā)進度情況，該圖可以：表示任務分解成子任務情況；表示每個任務的開始時間和完成時間，線段的長度表示子任務完成所需要的時間；表示子任務之間的并 行和串行關系。Gantt圖只能表示任務之間的并行與串行的關系，難以反映多個任務之 間存在的復雜關系，不能直觀表示任務之間相互依賴制約關系，以及哪些任務是關鍵字任務等信息，因此僅僅用 Gantt圖作為進度的安排是不夠的。6、什么是數(shù)據(jù)字典？其作用是什么？它有哪些條目？數(shù)據(jù)字典（簡稱DD）是用來定義數(shù)據(jù)流圖中的各個成分的具體含義的，它以一種 準確的、無二義性的說明方式為系統(tǒng)的分析、設計及維護提供了有關元素的一致的定義和詳細的描述。他和數(shù)據(jù)流圖共同構成了系統(tǒng)的

41、邏輯模型，是需求規(guī)格說明書的主要組 成部分。數(shù)據(jù)字典是為分析人員查找數(shù)據(jù)流圖中有關名字的詳細定義而服務的，因此也 像普通字典一樣，要把所有條目按一定的次序排列起來，以便查閱。數(shù)據(jù)字典有以下四 類條目：數(shù)據(jù)流、數(shù)據(jù)項、數(shù)據(jù)存儲、基本加工。數(shù)據(jù)項是組成數(shù)據(jù)流和數(shù)據(jù)存儲的最 小元素。源點、終點不在系統(tǒng)之內(nèi)，故一般不在字典中說明。7、調(diào)試的目的是什么？調(diào)試有哪些技術手段？調(diào)試的目的是確定錯誤的原因和位置，并改正錯誤，因此調(diào)試也成為糾錯。調(diào)試技 術主要有：簡單的調(diào)試方法，主要有在程序中插入打印語句、運行部分程序等；歸納法 調(diào)試，他從測試結果發(fā)現(xiàn)的線索（錯誤跡象、征兆）入手、分析他們之間的聯(lián)系，導處 錯誤

42、原因的假設，然后再證明或否定這個假設；演繹法調(diào)試，該方法列出所有可能的錯 誤原因的假設，然后利用測試數(shù)據(jù)排除不適當?shù)募僭O，最后再測試數(shù)據(jù)驗證余下的假設 確實是出錯的原因；回溯法調(diào)試，該方法從程序產(chǎn)生錯誤的地方出發(fā)，人工沿程序的邏 輯路徑反向搜索，直到找到錯誤的原因為止。1、如何做好軟件質(zhì)量保證工作？軟件質(zhì)量保證工作是軟件工程管理的重要內(nèi)容，軟件質(zhì)量保證應做好以下幾個方面的工作：1采用技術手段和工具。質(zhì)量保證活動要貫徹開發(fā)過程始終，必須從采用技 術手段和工具，尤其是使用軟件開發(fā)環(huán)境來進行軟件開發(fā)。2組織正式技術評審，在軟件開發(fā)的第一個階段結束時，都要組織正式的技術評審。國家標準要求單位必須采用

43、審查、文檔評審、設計評審、審計和測試等具體手段來保證質(zhì)量。3加強軟件測試。軟件測試是質(zhì)量保證的重要手段，因為測試可發(fā)現(xiàn)軟件可發(fā)現(xiàn)軟件中大多數(shù)潛在錯誤。4推選軟件工程規(guī)范（標準）。用戶可以自己指定軟件工程規(guī)范（標準），但標準一旦確認就應貫徹執(zhí)行。5對軟件的變更進行控制。軟件的修改和變更常常會引起潛伏的 錯誤，因此必須嚴格控制軟件的修改和變更。6對軟件質(zhì)量進行度量。即對軟件質(zhì)量 進行跟蹤，及時記錄和報告軟件質(zhì)量情況。2、什么是數(shù)據(jù)流圖？其作用是什么？其中的基本符號各表示什么含義？數(shù)據(jù)流圖簡稱DFD，是SA方法中用于表示系統(tǒng)邏輯模型的一種工具。它以圖形的方式描述數(shù)據(jù)在系統(tǒng)中流動和處理的過程，由于它只

44、反映系統(tǒng)必須完成的邏輯功能，所 以它是一種功能模型。數(shù)據(jù)流圖有四種基本圖形符號：箭頭表示數(shù)據(jù)流；“C圓或橢圓表述加工；“=雙杠表示數(shù)據(jù)存儲；“方框表示數(shù)據(jù)的源點或終點。3、什么是確認測試？該階段有哪些工作？確認測試又稱有效性測試。它的任務是檢查軟件的功能與性能是否與需求規(guī)格說明 書中確定的指標相符合。確認測試階段有兩項工作，進行確認測試與軟件配置審查。1 確認測試一般是在模擬環(huán)境中運用黑盒測試方法，由專門測試人員和用戶參加的測試。2軟件配置審查的任務是檢查軟件的所有文檔資料的完整性、正確性。如果發(fā)現(xiàn)遺漏和錯誤，應補充和改正，同時要編排好目錄，為以后的軟件維護工作奠定基礎。4、詳細設計的基本任務

45、是什么？有哪幾種描述方法？詳細設計是軟件設計的第二階段， 其基本任務有：為每個模塊進行詳細的算法設計； 為模塊內(nèi)的數(shù)據(jù)結構進行設計；對數(shù)據(jù)庫進行物理設計，即確定數(shù)據(jù)庫的物理結構；其 它設計，根據(jù)軟件系統(tǒng)類型，還可能要進行代碼設計、輸入/輸出格式設計、人機對話設計；編寫詳細設計說明書；評審。詳細描述處理過程常用三種工具：圖形、表格和語 言。如結構化程序流程圖、盒圖和問題分析圖。IPO圖也是詳細設計的主要工具之一。表格工具如判定表可作為詳細設計中描述邏輯條件復雜的算法。過程設計語言（PDL ）是一種用于描述模塊算法設計和處理細節(jié)的語言工具。5、什么是軟件危機？其產(chǎn)生的原因是什么？當軟件開發(fā)技術的進

46、步不能跟上硬件技術的進步，未能滿足發(fā)展的要求，致軟件開發(fā)中遇到的問題找不到解決的辦法，使問題積累起來，形成了尖銳的矛盾，因而導致了 軟件危機。主要表現(xiàn)為：1經(jīng)費預算經(jīng)常突破，完成時間一再拖延；2開發(fā)的軟件不能滿足用戶要求；3開發(fā)的軟件可維護性差；4開發(fā)的軟件可靠性差。造成軟件危機的原因是由于軟件產(chǎn)品本身的特點以及開發(fā)軟件的方式、方法、技術和人員引起的。共產(chǎn)生原因主要有以下幾方面：1軟件的規(guī)模越來越大，結構越來越復雜；2軟件開發(fā)管理困難而復雜；3軟件開發(fā)費用不斷增加；4軟件開發(fā)技術落后；5生產(chǎn)方 式落后；6開發(fā)工具落后，生產(chǎn)率提高緩慢。6、CASE工作臺有哪些分類?一個CASE工作臺是一組工具集

47、，支持像設計、實現(xiàn)或測試等特定的軟件開發(fā)階段。 工作臺工具能通過共享文件、共享倉庫或共享數(shù)據(jù)結構來集成。它能支持大多數(shù)的軟件 過程活動。工作臺有：1程序設計工作臺；2分析和設計工作臺；3測試工作臺； 4交叉開發(fā)工作臺；5配置管理（CM ）工作臺；6文檔工作臺7項目管理工作臺。7、IDEFO方法有什么特點？1采用方框和箭頭等簡單的圖形符號描述系統(tǒng)的活動和數(shù)據(jù)流，描述活動所受到的約束條件及實現(xiàn)機制。從側面清楚的反映了系統(tǒng)的功能。故IDEF0圖宜全為正式文檔。2采用嚴格的自頂向下、逐層分解的方式建立系統(tǒng)功能模型。頂層確定系統(tǒng)范圍，采 用抽象原則，然后有控制的逐步展開有關活動的細節(jié)，符合SA方法的分析

48、策略。同時,IDEF0規(guī)定每張圖至少有3個、最多有6個方框，上界6保證采用層次性描述復雜問題的可 理解性，下界3保證分解有意義。1、軟件維護的特點是什么？主要體現(xiàn)在三個方面：1非結構化維護和結構化維護。軟件的開發(fā)過程對軟件的 維護有很大的影響。若不采用軟件工程的方法開發(fā)軟件，則軟件只有程序而無文檔，維 護工作非常困難，這是一種非結構化的維護。若采用軟件工程的方法開發(fā)軟件，則各階 段都有相應的文檔，容易進行維護工作，這是一種結構化的維護。2維護的困難性。軟件維護的困難性是由于軟件需求分析和開發(fā)方法的缺陷。軟件生存周期中的開發(fā)階段沒有嚴格而有科學的管理和規(guī)劃，就會引起軟件運行時的維護困難。3軟件維

49、護的費用。軟件維護的費用在總費用中的比重是在不斷增加的，這是軟件維護有形的代價。另 外還有無形的代價，即要占用更多的資源。軟件維護費用增加的主要原因是軟件維護的 生產(chǎn)率非常低。2、什么是CASE ？ CASE工具有哪些分類？CASE是一組工具和方法的集合，可以輔助軟件開發(fā)生命周期各階段進行軟件開發(fā)。 從學術研究角度講，CASE是多年來在軟件開發(fā)管理、軟件開發(fā)方法、軟件開發(fā)環(huán)境和 軟件工具等方面研究和發(fā)展的產(chǎn)物。CASE把軟件開發(fā)技術、軟件工具和軟件開發(fā)方法集成到一個統(tǒng)一而一致的框架中，并且吸引了CAD （計算機輔助設計）、軟件工程、操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡和許多其它計算機領域的原理和技術。因而，

50、CASE領域是一個應用集成和綜合的領域。從產(chǎn)業(yè)角度講，CASE是種類繁多的軟件開發(fā)和系統(tǒng)集成的產(chǎn)品及軟件工具的集合。CASE分類：1CASE技術種類CASE系統(tǒng)所涉及到的技術有 兩類：一類是支持軟件開發(fā)過程本身的技術；另一類是支持軟件開發(fā)過程管理的技術。從CASE系統(tǒng)產(chǎn)生方式來看，還有一種特殊的CASE技術，即元一一CASE技術。他是生成CASE系統(tǒng)的生成器所采用的技術。該生成器可用來創(chuàng)建支持軟件開發(fā)過程活動及 過程管理的CASE系統(tǒng)。<2>CASE工具的分類對 CASE工具分類的標準可分為：功 能。功能是對軟件進行分類的最常用的標準。支持的過程。根據(jù)支持的過程，工具可 分為設計工

51、具、編程工具、維護工具等。支持的范圍。根據(jù)支持的范圍，可分為窄支 持、較寬支持和一般支持工具。窄支持指支持過程中特定的任務，較寬支持是指支持特 定過程階段；一般支持是指支持覆蓋軟件過程的全部階段或大多數(shù)階段。1993年，F(xiàn)uggetta根據(jù)CASE系統(tǒng)對軟件過程的支持范圍，提出 CASE系統(tǒng)可分為三類：支持 單個過程任務的工具。工具可能是通用的，或者也可能歸組到工作臺。工作臺支持某 一過程所有活動或某些活動。他們一般以或多或少的集成度組成工具集。環(huán)境支持軟件過程所有活動或至少大部分。他們一般包括幾個不同的工作臺，將這些工作臺以某種方式集成起來。3、說明容錯軟件的定義與容錯的一般方法。歸納容錯軟

52、件的定義，有以下四種：規(guī)定功能的軟件，在一定程序上對自身錯誤 的作用（軟件錯誤）具有屏蔽能力，貝帰此軟件為具有容錯功能的軟件。規(guī)定功能的 軟件，在一定程序上能從錯誤狀態(tài)自動恢復到正常狀態(tài)，則稱之為容錯軟件。規(guī)定功 能的軟件，在因錯誤而發(fā)生錯誤時，仍然能在一定程度上完成預期的功能，貝V把該軟件 稱為容錯軟件。規(guī)定功能的軟件，在一定程度上具有容錯能力，貝V稱之為容錯軟件。 實現(xiàn)容錯技術的主要手段是冗余，通常冗余技術分為四類。結構冗余。結構冗余是通 常用的冗余技術。按其工作方式，它分為靜態(tài)、動態(tài)和混合冗余三種。信息冗余。為 檢查或糾正信息在運算或傳輸中的錯誤須外加一部分信息，這種現(xiàn)象稱為信息冗余。

53、時間冗余。是指以重復執(zhí)行指令（指令復執(zhí)）或程序（程序復算）來消除瞬時錯誤帶來 的影響。冗余附加技術。是指為實現(xiàn)上述冗余技術所需的資源和技術。包括程序、指 令、數(shù)據(jù)、存放和調(diào)動他們的空間和通道等。4、軟件概要設計階段的基本任務是什么？設計軟件系統(tǒng)結構（簡稱軟件結構），具體為：采用某種設計方法，將一個復 雜的系統(tǒng)按功能劃分成模塊。確定每個模塊的功能。確定模塊之間的調(diào)用關系。 確定模塊之間的接口，即模塊之間傳遞的信息。評價模塊結構的質(zhì)量。數(shù)據(jù)結構及 數(shù)據(jù)庫設計，漢數(shù)據(jù)結構的設計及數(shù)據(jù)庫的設計。編寫概要設計文檔。主要有：概要 設計說明書；數(shù)據(jù)庫設計說明書；用戶手冊；修訂測試計劃。評審。5、快速原型模型

54、有幾種？各有何特點？根據(jù)原型的不同作用，有三類原型模型：探索型原型。這種類型的原型模型是把 原型用于開發(fā)的需求分析階段，目的是要弄清用戶的需求，確定所期望的特性，并探索 各種方案的可行性。它主要針對開發(fā)目標模糊，用戶與開發(fā)著對項目都缺乏經(jīng)驗的情況， 通過對原型的開發(fā)來明確用戶的需求。實驗型原型。這種原型主要用于設計階段，考 核實現(xiàn)方案是否合適，能否實現(xiàn)，對于一個大型系統(tǒng)，若對設計方案心中沒有把握時， 可通過這種原型來證實設計方案的正確性。演化型原型。這種原型主要用于及早向用 戶提交一個原型系統(tǒng)，該原型系統(tǒng)或者包含系統(tǒng)的框或者包含系統(tǒng)的主要功能。在得到 用戶的認可后，將原型系統(tǒng)不斷擴充演變?yōu)樽罱K

55、的軟件系統(tǒng)，它將原型的思路擴展到軟 件開發(fā)的全過程。1、在劃分軟件生存周期階段時，應遵循的基本原則是什么？軟件生存周期的各個階段有不同的劃分。軟件規(guī)模、種類、開發(fā)方式、開發(fā)環(huán)境以及開發(fā)使用方法都影響軟件生存周期的劃分。在劃分軟件生存周期階段時，應遵循的一條基本原則是各階段的任務應盡可能相對獨立，同一階段各項目任務的性質(zhì)盡可能相 同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯(lián)系，有利于軟件項目開 發(fā)的組織管理。2、請說明軟件文檔的作用？軟件開發(fā)項目生存期各階段都包含哪些文檔？軟件文檔的作用是：提高軟件開發(fā)過程的能見度；提高開發(fā)效率；作為開發(fā)人員階段工作成果和結束標志；記錄開發(fā)過程的 有

56、關信息便于使用與維護；提供軟件運行、維護和培訓有關資料；便于用戶了解軟件功 能、性能。軟件開發(fā)項目生存期各階段應包括得文檔以及與各類人員的關系如下：可行 性研究報告、項目開發(fā)計劃、軟件需求說明書、數(shù)據(jù)要求說明書、測試計劃、概要設計 說明書、詳細設計說明書、用戶手冊、操作手冊、測試分析報告、開發(fā)進度月報、項目 開發(fā)總結、程序維護手冊（維護修改建議） 。3、軟件開發(fā)成本估算方法有哪幾種？<1>自頂向下估算方法。估算人員參照以前完成的項目所耗費的總成本（或總工作 量），來推算將要開發(fā)的軟件的總成本（或總工作量），然后把它們按階段、步驟和工作單元進行分配，這樣方法稱為自頂向下的估算方法。<2>自底向上估算方法。自底向上估算方法是將待開發(fā)的軟件細分，分別估算每一個子任務所需要的開發(fā)工作量，然后將 它們加起來，得到軟件的總