软件工程导论习题
軟件工程導論習題
- 第一章 軟件工程學概述
- 第二章 可行性研究
- 分層DFD圖
- 畫DFD圖的步驟
- 第三章 需求分析
- 第五章 總體設計
- 測試題目
第一章 軟件工程學概述
1.軟件生命周期 一般包括:軟件開發期和軟件運行期，下述____不是軟件開發期所應包含的內容（ D）
A、需求分析
B、結構設計
C、程序編制
D、軟件維護
解析：軟件生命周期由軟件定義、軟件開發和運行維護(也稱為軟件維護)3個時期組成，每個時期又進一步劃分成若干個階段。軟件定義時期的任務是： 確定軟件開發工程必須完成的總目標；確定工程的可行性；導出實現工程目標應該采用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，并且制定工程進度表。這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟件定義時期通常進一步劃分成3個階段，即問題定義、可行性研究和需求分析。開發時期具體設計和實現在前一個時期定義的軟件，它通常由下述4個階段組成：總體設計（需求分析），詳細設計（結構設計），編碼和單元測試，綜合測試（程序編制）。其中前兩個階段又稱為系統設計，后兩個階段又稱為系統實現。維護時期的主要任務是使軟件持久地滿足用戶的需要。
2.軟件生命周期是指一個軟件從_______開始直到該軟件最終退役為止的整個時期。C
A、開發
B、需求
C、定義
D、構想
解析：軟件生存周期是指從軟件定義、開發、使用、維護到淘汰的全過程。
3.軟件危機是指在計算機軟件的（ ）過程中所遇到的一系列嚴重問題。B
A、設計
B、開發和維護
C、應用
D、需求分析
解析：軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。
4.以下（ ）不屬于軟件危機的表現。D
A、對軟件開發成本和進度估計不準確。
B、軟件的文檔不全。
C、軟件成本在計算機系統總成本中所占比例逐年上升。
D、軟件開發生產率提高很快。
解析：軟件危機的典型表現：
對軟件開發成本和進度的估計常常很不準確
用戶對“已完成的”軟件系統不滿意的現象經常發生
軟件產品的質量往往靠不住。
軟件常常是不可維護的
軟件通常沒有適當的文檔資料。
軟件成本在計算機系統總成本中所占的比例逐年上升。
軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。
D沒說全
5.以下（ ）不是產生軟件危機的原因。A
A、軟件也是商品
B、軟件不同與其他的普通實物商品
C、沒有弄清楚需求就著手編寫程序
D、程序人員錯誤的認知
解析：產生軟件危機的原因：
與軟件本身特點有關：
1.軟件不同于硬件.管理和控制軟件開發過程相當困難
2.軟件在運行過程中不會因為使用時間過長而被用壞如果運行中發現了錯誤,很可能是遇到了一個在開發時期引入的在測試階段沒能檢測出來的錯誤。
3.軟件不同于一般程序，它的一個顯著特點是規模龐大，而且程序復雜性將隨著程序規模的增加而呈指數上升。
4.事實上，對用戶要求沒有完整準確的認識就匆忙著手編寫程序是許多軟件開發工程失敗的主要原因之一。
5.目前相當多的軟件專業人員對軟件開發和維護還有不少糊涂觀念。在實踐過程中或多或少地采用了錯誤的方法和技術，這可能是使軟件問題發展成軟件危機的主要原因。
6.錯誤的認識和做法主要表現為忽視軟件需求分析的重要性，認為軟件開發就是寫程序并設法使之運行，輕視軟件維護等
軟件開發與維護的方法不正確有關：
1.只重視程序而忽視軟件配置其余成分的糊涂觀念。
2.軟件開發人員在定義時期沒有正確全面地理解用戶需求，直到測試階段或軟件交付使用后才發現“已完成的”軟件不完全符合用戶的需要。
3.嚴重的問題是在軟件開發的不同階段進行修改需要付出的代價是很不相同的，如下圖所示。
本題軟件危機與軟件是不是商品并沒有關系，B是有關于軟件本身的特點，C、D分別對應4、6點
6.以下描述錯誤的是：D
A、隨著時間的推移，越往后發現錯誤，修復錯誤成本越大。
B、軟件是程序、數據及相關文檔的完整集合。
C、軟件開發項目是團隊協同配合、共同體完成。
D、軟件開發比軟件測試更重要。
解析：軟件開發與軟件測試同等重要
7.軟件工程的基本原理包括：D
A、用分階段的生命周期計劃嚴格管理；堅持進行階段評審
B、實行嚴格的產品控制；采用現代程序設計技術
C、結果應能清楚地審查；開發小組的人員應該少而精；承認不斷改進軟件工程實踐的必要性
D、以上都對
解析：軟件工程的基本原理：
1、用分階段的生命周期計劃嚴格管理
2、堅持進行階段評審
3、實行嚴格的產品控制
4、采用現代程序設計技術
5、結果應能清楚地審查
6、開發小組的人員應該少而精
7、承認不斷改進軟件工程實踐的必要性
8.軟件工程方法學包含3個要素，這3個要素不包括（ ）A
A、測試
B、方法
C、工具
D、過程
解析：軟件工程方法學：
方法：完成軟件開發的各項任務的技術方法，回答“怎樣做”的問題
工具：為運用方法而提供的自動的或半自動的軟件工程支撐環境
過程：為了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟
9.目前使用最廣泛的軟件工程方法學是傳統方法學和（ B ）
A、面向過程方法學
B、面向對象方法學
C、面向結果方法學
D、面向測試方法學
解析：軟件工程方法學：
1、傳統方法學：傳統方法學也稱為生命周期方法學或結構化范型。它采用結構化技術(結構化分析、結構化設計和結構化實現)來完成軟件開發的各項任務，并使用適當的軟件工具或軟件工程環境來支持結構化技術的運用。
2、面向對象方法學：與傳統方法相反，面向對象方法把數據和行為看成是同等重要的，它是一種以數據為主線，把數據和對數據的操作緊密地結合起來的方法。
10.軟件工程中應用最廣泛的模型是（A ）
A、瀑布模型
B、增量模型
C、螺旋模型
D、噴泉模型
解析：1.瀑布模型一直是唯一被廣泛采用的生命周期模型，現在它仍然是軟件工程中應用得最廣泛的過程模型。如下圖所示為傳統的瀑布模型
傳統的瀑布模型
按照傳統的瀑布模型開發軟件，有下述的幾個特點。
a)階段間具有順序性和依賴性：
兩重含義： ①必須等前一階段的工作完成之后，才能開始后一階段的工作； ②前一階段的輸出文檔就是后一階段的輸入文檔，因此，只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結果。
b) 推遲實現的觀點
瀑布模型在編碼之前設置了系統分析與系統設計的各個階段，分析與設計階段的基本任務規定，在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現。
c) 質量保證的觀點：
軟件工程的基本目標是優質、高產。為了保證所開發的軟件的質量，在瀑布模型的每個階段都應堅持兩個重要做法。
每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。
每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤。
瀑布模型有許多優點：
可強迫開發人員采用規范的方法（例如，結構化技術）；
嚴格地規定了每個階段必須提交的文檔；
要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。
2.增量模型：增量模型也稱為漸增模型。使用增量模型開發軟件時，把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。使用增量模型時，第一個增量構件往往實現軟件的基本需求，提供最核心的功能。
優點：能在較短時間內向用戶提交可完成部分工作的產品。
逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。
使用增量模型的困難：在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。
必須把軟件的體系結構設計得便于按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。
風險更大的增量模型：
3.螺旋模型螺旋模型的基本思想是，使用原型及其他方法來盡量降低風險。理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風險分析過程的快速原型模型。
完整的螺旋模型
4.噴泉模型：“噴泉”這個詞體現了面向對象軟件開發過程迭代和無縫的特性。迭代是軟件開發過程中普遍存在的一種內在屬性。用面向對象方法學開發軟件時，工作重點應該放在生命周期中的分析階段。
圖中代表不同階段的圓圈相互重疊，這明確表示兩個活動之間存在交迭；
圖中在一個階段內的向下箭頭代表該階段內的迭代（或求精）。
圖中較小的圓圈代表維護，圓圈較小象征著采用了面向對象范型之后維護時間縮短了。
第二章 可行性研究
1.DFD中的每個加工至少有______。 （B ）
A、一個輸入流或一個輸出流
B、一個輸入流和一個輸出流
C、一個輸入流
D、一個輸出流
解析：DFD圖：數據流圖(DFD)是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程中所經受的變換。
分層DFD圖
如果系統的規模較大，僅用一個DFD圖難以描述，會使得系統變得復雜、龐大而又難以理解。為了降低系統的復雜性，一般采取“逐層分解”的方法，繪制分層的DFD圖。
- 繪制分層DFD圖的原則一般是：先全局后局部，先整體后細節，先抽象后具體。
- 繪制分層DFD圖的步驟一般是
- 先確定整個系統的范圍和功能，繪制頂層的DFD圖。
- 繪制出頂層的DFD圖之后，然后逐層分解頂層DFD圖，獲得若干中間層DFD圖。
- 根據獲得的中間層DFD圖繪制各個底層的DFD圖。
畫DFD圖的步驟
注意事項
- 命名。不論數據流、數據存儲還是加工，合適的命名使人們易于理解其含義。
- 畫數據流而不是控制流。數據流反映系統“做什么”，不反映“如何做”，因此箭頭上的數據流名稱只能是名詞或名詞短語，整個圖中不反映加工的執行順序。
- 一般不畫物質流。數據流反映能用計算機處理的數據，并不是實物，因此對目標系統的數據流圖一般不要畫物質流。
- 每個加工至少有一個輸入數據流和一個輸出數據流，反映出此加工數據的來源與加工的結果。
- 編號。如果一張數據流圖中的某個加工分解成另一張數據流圖時，則上層圖為父圖，直接下層圖為子圖。子圖及其所有的加工都應編號。
- 父圖與子圖的平衡。子圖的輸入輸出數據流同父圖相應加工的輸入輸出數據流必須一致，此即父圖與子圖的平衡。
- 局部數據存儲。當某層數據流圖中的數據存儲不是父圖中相應加工的外部接口，而只是本圖中某些加工之間的數據接口，則稱這些數據存儲為局部數據存儲。
- 提高數據流圖的易懂性。注意合理分解，要把一個加工分解成幾個功能相對獨立的子加工，這樣可以減少加工之間輸入、輸出數據流的數目，增加數據流圖的可理解性。
2.數據字典(DD)是定義（ A )系統描述工具中的數據的工具。
A、數據流程圖
B、系統流程圖
C、程序流程圖
D、軟件結構圖
解析：數據字典是關于數據的信息的集合，也就是對數據流程圖中包含的所有元素的定義的集合。
3.在數據流圖中，橢圓O代表__________。 （ C）
A、源點
B、終點
C、處理
D、模塊
解析：數據流四中基本符號：
正方形表示數據的源點或終點
圓角矩形代表變換數據的處理
開口矩形代表數據存儲
箭頭表示數據流，即特定數據的流動方向
4.數據字典中，一般不包括下列哪個選項( D )。
A、數據流
B、數據存儲
C、加工
D、源點與終點
解析：一般說來，數據字典應該由對下列4類元素的定義組成。處理=加工，沒有源點與終點
數據元素的別名就是該元素的其他等價的名字，出現別名主要有下述3個原因：
對于同樣的數據，不同的用戶使用了不同的名字。
一個分析員在不同時期對同一個數據使用了不同的名字。
兩個分析員分別分析同一個數據流時，使用了不同的名字。
由數據元素組成數據的方式只有下述3種基本類型：
順序即以確定次序連接兩個或多個分量。
選擇即從兩個或多個可能的元素中選取一個。
重復即把指定的分量重復零次或多次。
數據字典的用途：
數據字典最重要的用途是作為分析階段的工具
數據字典中包含的每個數據元素的控制信息是很有價值的
數據字典是開發數據庫的第一步，而且是很有價值的一步。
5.在數據流圖中，有名字及方向的成分是________. （ C）
A、控制流
B、信息流
C、數據流
D、信號流
解析：箭頭表示數據流，即特定數據的流動方向
6.數據字典最基本的功能是( C )。
A、數據庫設計
B、數據通訊
C、數據定義
D、數據維護
解析：數據字典是關于數據的信息的集合，也就是對數據流程圖中包含的所有元素的定義的集合。
從定義可以看出來是對定義的集合那么他最基本的功能其實也就是數據定義。數據字典是指對數據的數據項、數據結構、數據流、數據存儲、處理邏輯、外部實體等進行定義和描述，其目的是對數據流程圖中的各個元素做出詳細的說明
7.數據字典是對數據定義信息的集合，它所定義的對象都包含于___.（ A）
A、數據流圖
B、程序框圖
C、軟件結構
D、方框圖
解析：見上題定義
8.可行性研究要進行一次______需求分析。（ C）
A、詳細的
B、全面的
C、簡化的、壓縮的
D、徹底的
解析：可行性研究是在項目建議書被批準后，對項目在技術上和經濟上是否可行所進行的科學分析和論證，它需要進行一次簡化的、壓縮的需求分析。軟件工程導論第六版第二章導論也說了：必須時刻記住，可行性研究的目的不是解決問題，而是確定問題是否值得去解決。怎樣達到這個目的呢？當然不能靠主觀猜想而只能靠客觀分析。必須分析幾種主要的可能解法的利弊，從而判斷原定的系統規模和
目標是否現實，系統完成后所能帶來的效益是否大到值得投資開發這個系統的程度。因此，可行性研究實質上是要進行一次大大壓縮簡化了的系統分析和設計的過程，也就是在較高層次上以較抽象的方式進行的系統分析和設計的過程。
第三章 需求分析
1.軟件需求說明書的作用不應包括_______。（D ）
A、軟件設計的依據
B、用戶與開發人員對軟件要做什么的共同理解
C、軟件驗收的依據
D、軟件可行性研究的依據
解析：軟件需求說明書（軟件規格說明書）：對所開發軟件的功能、性能、用戶界面及運行環境等作出詳細的說明。它是在用戶與開發人員雙方對軟件需求取得共同理解并達成協議的條件下編寫的，也是實施開發工作的基礎。該說明書應給出數據邏輯和數據采集的各項要求，為生成和維護系統數據文件做好準備。它的作用是作為用戶和軟件開發人員達成的技術協議書，作為著手進行設計工作的基礎和依據，系統開發完成以后，為產品的驗收提供了依據。
需求說明書是由開發人員經需求分析后形成的軟件文檔，是對需求分析工作的全面總結。其作用有以下幾點。
（1）便于用戶、分析人員和軟件設計人員進行理解和交流，用戶通過需求規格說明書在分析階段即可初步判定目標軟件能否滿足其原來的期望，設計人員則將需求規格說明書作為軟件設計的基本出發點。
（2）支持目標軟件系統的確認
在軟件的測試階段，根據需求說明書中確定的可測試標準設計測試用例，確認軟件是否滿足需求說明書中規定的功能和性能等。
（3）控制系統進化過程
在需求分析完成之后，如果用戶追加需求，那么需求說明書將用于確定是否為新需求。
2.軟件需求分析一般應確定的是用戶對軟件的__________.（D ）
A、功能需求
B、非功能需求
C、性能需求
D、功能需求和非功能需求
解析：軟件需求中需構造一個完全的系統邏輯模型，理用戶出的每一功能性能求，使用戶明確自己的任務。因此，需求應確定用戶對軟件的功能需求 和非功能需求。
3.需求分析是_______.（A ）
A、軟件開發工作的基礎
B、軟件編碼的開始
C、由系統分析員單獨完成的
D、由用戶自己單獨完成的
解析：需求分析也稱為軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什么的過程。軟件需求分析是一個項目的開端，也是項目實施最重要的關鍵點。
4.需求分析中，開發人員要從用戶那里解決的最重要的問題是_____。（A ）
A、讓軟件做什么
B、要給軟件提供哪些信息
C、要求軟件工作效率怎樣
D、讓軟件具有何種結構
5.軟件需求規格說明書的內容不應包括對_______的描述。（ B）
A、主要功能
B、算法的詳細過程
C、用戶界面及運行環境
D、軟件的性能
解析：軟件需求說明書是指在研究用戶要求的基礎上，完成可行性分析和投資效益分析以后，由軟件工程師或分析員編寫的說明書。它詳細定義了信息流和界面，功能需求，設計要求和限制，測試準則和質量保證要求。它的作用是作為用戶和軟件開發人員達成的技術協議書，作為著手進行設計工作的基礎和依據，系統開發完成以后，為產品的驗收提供了依據。
軟件需求說明書的內容應包含如下幾部分內容：
1.概述
·說明開發軟件系統的目的、意義和背景
·說明用戶的特點、約束
2.需求說明
·功能說明，逐項列出各功能需求的序號、名稱和簡要說明
·性能說明，說明處理速度、響應時間、精度等
·輸入輸出要求·數據管理要求·故障處理要求
3.數據描述
·數據流圖·數據字典·接口說明
4.運行環境規定
·說明軟件運行所需的硬件設備
·說明軟件運行所需的系統軟件和軟件工具
5.限制
·說明軟件開發在成本、進度、設計和實現方面的限制。
6.需求分析最終結果是產生_______。（ C）
A、項目開發計劃
B、可行性分析報告
C、需求規格說明書
D、設計說明書
7.軟件需求分析是保證軟件質量的重要步驟，它的實施應該是在__C__。
A、編碼階段
B、軟件開發全過程
C、軟件定義階段
D、軟件設計階段
解析：在軟件技術人員著手設計軟件之前，需要由既精通計算機技術又 熟悉用戶應用領域的軟件系統分析人員，對軟件問題進行細致的需求分析。 需求分析是軟件工程過程中一個重要的里程碑。在需求分析過程中，軟件系統分析人員通 過研究用戶在軟件問題上的需求意愿，分析出軟件系統在功能、性能、數據等諸多方面應該達 到的目標，從而獲得有關軟件的需求規格定義
8.在結構化的分析方法中，用實體關系圖表達系統中的對象及其關系，在實體關系圖中，表達對象的實例關系之間的關聯有三種類型是（ABD ）。
A、一對一聯系
B、多對多聯系
C、不確定
D、一對多聯系
解析：為了開發復雜的系統，應從不同角度（模型）抽象出目標系統的特性（數據模型、功能模型、行為模型）。
模型種類數據模型：E-R圖功能模型：數據流圖行為模型：狀態轉換圖數據字典：描述出現在上面三種模型中的數據對象及控制信息的特性，給出準確定義。
實體－聯系圖
數據對象可以是外部實體、事物、行為、事件、角色、單位、地點、結構等。
屬性定義了數據對象的性質。
聯系（1）一對一聯系（1：1）（2）一對多聯系（1：N）（3）多對多聯系（M：N）
9.結構化設計是一種應用最廣泛的系統設計方法，是以__B__為基礎，自頂向下，求精和模塊化的過程。
A、數據庫
B、數據流圖
C、數據結構
D、系統模塊
解析：面向數據流自頂向下求精 。借助數據流圖、數據字典、IPO圖等，細化、完善詳細的數據流圖，等到各處理環節對應的功能。
需求分析大佬博客地址：https://www.cnblogs.com/youcong/p/9500873.html
第五章 總體設計
1.最高程度也是最差的耦合是________.（B ）
A、公共耦合
B、內容耦合
C、控制耦合
D、數據耦合
解析：
2.模塊內聚度越高，說明模塊內各成分彼此結合的程度越_______.（B ）
A、松散
B、緊密
C、無法判斷
D、相等
解析：軟件設計應追求盡可能松散耦合，避免強耦合，這樣模塊間的聯系就越小，模塊的獨立性就越強，對模塊的測試、維護就越容易。
內聚：衡量一個模塊內部各個元素彼此結合的緊密程度
3.在下列耦合中，最低程度的偶合是（C ）
A、內容偶合
B、公共偶合
C、數據偶合
D、控制耦合
解析：數據耦合 ：兩個模塊之間只是通過參數交換信息，而且交換的信息僅僅是數據。 數據耦合是最低程度的耦合。
控制耦合 ：兩個模塊之間所交換的信息包含控制信息。 控制耦合是中等程度的耦合。
公共耦合 ：兩個或多個模塊通過一個公共區相互作用時的耦合。 公共區可以是：全程數據區、共享通信區、內存公共覆蓋區、任何介質上的文件、物理設備等。 軟件結構中存在大量的公共耦合時會給診斷錯誤帶來困難。
內容耦合 ： 一個模塊與另一個模塊的內容直接發生聯系。 內容耦合對維護會帶來嚴重的困難。
4.一個模塊把數值作為參數傳送給另一個模塊，這種耦合方式稱為（ A）
A、數據耦合
B、公共耦合
C、控制耦合
D、標記耦合
解析：標記耦合（特征耦合）：當把整個數據結構作為參數傳遞而被調用模塊只需要使用其中一部分數據元素時，這種情況稱為標記耦合。
數據耦合指兩個模塊之間有調用關系,傳遞的是簡單的數據值,相當于高級語言的值傳遞.數據耦合聯系簡單,耦合度低,模塊獨立性好,模塊間的影響最小，是最理想的一種耦合形式。
5.原型化方法是用戶和設計者之間執行的一種交互構成，適用于（ A ）系統。
A、需求不確定性高的
B、需求確定的
C、管理信息
D、實時
解析：原型不同于最終系統，它只實現所選擇的部分功能，僅是為了試驗或是演示而用，部分功能需求可以忽略或者模擬實現，因此適用于需求不確定性高的系統
6.銀行計算機儲蓄管理信息系統中，根據客戶提出的要求（如存款、取款、查詢、掛失、咨詢等）進行相應的業務處理的該層數據流圖是______。B
A、變換型
B、事務性
C、既不是變換型也不是事務型
D、不確定
解析：變換流 ：具有較明確的輸入、變換（或稱主加工）和輸出界面的數據流圖稱為變換型數據流圖。 如圖所示，該變換中心可以理解為數據的加工和處理程序。
事務流：事務型數據流圖中存在一個事務中心（也就是數據處理、加工中心），它將輸入分離成若干個發散的數據流，形成許多活動路徑，并根據輸入值選擇其中一條路徑。
題干中根據客戶提出的要求（如存款、取款、查詢、掛失、咨詢等）進行相應的業務處理很明顯是存在一個事務中心的，所以為事務性
7.以下不屬于需求分析所解決的問題是（ D）
A、撰寫需求規格說明書
B、建立概念模型
C、畫出狀態轉換圖
D、畫出功能模塊圖
解析：需求分析的任務：確定對系統的綜合要求包括： 1．功能需求 2．性能需求3. 可靠性和可用性需求4. 出錯處理需求 系統發現錯誤時采取的行動，主要在系統關鍵部分設置。5. 接口需求 用戶接口、硬件接口、軟件接口、通信接口、等。6. 約束 精度、工具和語言、設計約束、硬件約束、標準，等。7. 逆向需求 8. 將來可能提出的要求 ；
分析系統的數據要求 通過建立數據模型來分析，如數據字典、層次方框圖、Warnier圖，并將數據結構規范化。
導出系統的邏輯模型 包括完善的數據流圖、實體－聯系圖、狀態轉換圖、數據字典、主要的處理算法（IPO圖）等。
修正系統開發計劃 修訂前期制定的開發進度計劃、等。
畫出功能模塊圖是在總體設計階段而不是需求分析階段
8.總體設計啟發式規則包括（ABCD ）。多項選擇題
A、改進軟件結構提高模塊獨立性
B、力爭降低模塊接口的復雜度
C、設計單入口、單出口的模塊
D、模塊功能應該可以預測
解析：啟發規則
爭取低耦合、高內聚
增加內聚、減少耦合
模塊規模適中
過大，分解不充分，不易理解；
太小，則開銷過大、接口復雜。
適當控制模塊結構參數
深度 = 分層的層數。過大表示分工過細。
寬度 = 同一層上模塊的最大值。過大，表示系統復雜度大。
扇出 = 一個模塊直接調用\控制的模塊數。
扇入 = 直接調用該模塊的模塊數。
盡可能減少高扇出結構，隨著深度增大扇入。
扇出太大一般是因為缺乏中間層次，應當適當增加中間層次的控制模塊；
扇出太小時可以把下級模塊進一步分解為若干個子功能模塊，或合并到它的上級模塊中去。
頂層扇出高，中間扇出少，底層高扇入。
模塊的作用范圍保持在該模塊的控制范圍內
控制域 = 該模塊本身以及所有直接或間接從屬于它的模塊。
作用域 = 該模塊中一個判斷所影響的所有其他模塊。
令作用域是控制域的子集：
把作判定的點往上移；
把那些在作用域但不在控制域內的模塊移到控制域內。
降低接口的復雜程度
模塊接口的復雜性是引起軟件錯誤的一個主要原因。接口設計應該使得信息傳遞簡單并且與模塊的功能一致。
單出口單入口，避免內容耦合
易于理解和維護。
模塊功能可預測
相同輸入必產生相同輸出。
測試題目
1.在軟件生存周期中，( B )階段要回答的問題是“要解決的問題是做什么?”
A、詳細設計
B、需求分析
C、概要設計
D、軟件測試
解析：軟件生命周期各階段的任務：
1、問題定義
確定好要解決的問題是什么（what），通過對客戶的訪問調查，系統分析員扼要的寫出關于問題性質、工程目標和工程規模的書面報告，經過討論和必要的修改之后這份報告應該得到客戶的確認。
2、可行性研究
確定該問題是否存在一個可以解決的方案。可行性研究的結果是客戶做出是否繼續進行這項工程的決定的重要依據，一般來說，只有投資可能取得較大的效益的那些工程項目才值得繼續進行下去。
3、需求分析
深入具體的了解用戶的需求，在所開發的系統要做什么這個問題上和用戶想法完全一致。明確目標系統必須做什么，確定目標系統必須具備哪些功能。通常用數據流圖、數據字典和簡要的算法表示系統的邏輯模型。用《規格說明書》記錄對目標系統的需求。
4、概要設計（總體設計）
概括的說，應該怎樣實現目標系統，設計出實現目標系統的幾種可能方案，設計程序的體系結構，也就是確定程序由哪些模塊組成以及模塊之間的關系。
5、詳細設計
實現系統的具體工作，編寫詳細規格說明，程序員可以根據它們寫出實際的程序代碼。詳細設計也稱模塊設計，在這個階段將詳細的設計每個模塊，確定實現模塊功能所需的算法和數據結構。
6、編碼和單元測試（編碼占全部開發工作量的10%-20%）
7、綜合測試（測試占全部開發工作量的40%-50%）
8、軟件維護
通過各種必要的維護活動使系統持久的滿足用戶的需求。主要分為 改正性維護、適應性維護、完善性維護、預防性維護。
2.軟件特性中，一個軟件能再次用于其他相關應用的程度稱為(B )。
A、可重用性
B、容錯性
C、可適應性
D、可移植性
解析：可重用性：系統的某部分可被應用到其他系統中的程度，以及應用的難易程度。比如組件化，就是從代碼的可重用性考量的，比如使用Android Jetpack的組件更好更快的構建App，復用了很多的邏輯代碼。
容錯性：在軟件失效或者違反規定的接口的情況下，軟件產品維持規定的性能級別的能力
可移植性（portability）：軟件產品從一種環境遷移到另外一種環境的能力
可適應性：軟件產品無需采用手段就可能適應不同的指定環境的能力
3.下列選項中，屬于實現階段的任務的是( C )。
A、組裝測試計劃
B、繪制程序流程圖
C、單元測試
D、驗收測試計劃
解析：編碼和測試統稱為實現。
4.在軟件質量要素中，學習使用軟件（即操作軟件、準備輸入數據、解釋輸出結果等）的難易程度指的是( B)。
A、完整性
B、可用性
C、正確性
D、靈活性
5.在軟件工程中，不屬于軟件定義部分的任務是（ D )。
A、軟件驗收測試計劃
B、軟件項目計劃
C、需求分析
D、集成測試計劃
解析：軟件定義時期的任務是確定軟件開發工程必須完成的總目標，這個時期通常進一步劃分成三個階段，即問題定義、可行性研究和需求分析。在這個階段需要完成制定軟件項目計劃、進行需求分析和制定驗收測試計劃等任務。該階段的任務不包括制定集成測試計劃，它是軟件開發階段的任務之一。
6.在軟件工程中，( C )不屬于軟件開發部分的任務。
A、軟件總體設計
B、單元測試
C、軟件經銷
D、集成測試
7.需求分析最終結果是產生（ C )。
A、項目開發計劃
B、可行性分析報告
C、需求規格說明書
D、設計說明書
解析：需求分析也彌為軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什么的過程，最終產生需求規格說明書，把用戶對待開發軟件提出的“要求”或“需要”進行分析與整理，確認后形成描述完整、清晰與規范的文檔，確定軟件需要實現哪些功能，完成哪些工作，故選 B
項目開發計劃是用于指導項目實施和管理的整合性、綜合性、全局性、協調統一的整合計劃文件。進行需求分析不能得到項目開發計劃，故排除 A 設計說明書是對各方面的設計進行要求，要進行產品分析，設計分析，故排除 C
可行性分析報告在前一階段的項目建議書獲得審批通過的基礎上，主要對項目市場、技術、財務、工程、經濟和環境等方面進行精確系統、完備無遺的分析，為投資決策提供科學依據，并作為進一步開展工作的基礎。要進行可行性分析，不是需求
8.數據流圖中的每個加工至少有(A )。
A、一個輸入流和一個輸出流
B、一個輸入流或一個輸出流
C、一個輸入流
D、一個輸出流
解析：2-1
9.SA方法的基本思想是（ C)。
A、自底向上逐步抽象
B、自底向上逐步分解
C、自頂向下逐步分解
D、自頂向上抽象
解析：SA 法也是一種建模的活動，主要是根據軟件內部的數據傳遞、變換關系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。
SA 法的基本思想
結構化分析(Structured Analysis，簡稱SA 法)是面向數據流的需求分析方法，是70年代由Yourdon,Constaintine 及DeMarco 等人提出和發展，并得到廣泛的應用。
結構化分析方法的基本思想是“分解”和“抽象”。
分解：是指對于一個復雜的系統，為了將復雜性降低到可以掌握的程度，可以把大問題分解成若干小問題，然后分別解決。
抽象：分解可以分層進行，即先考慮問題最本質的屬性，暫把細節略去，以后再逐層添加細節，直至涉及到最詳細的內容，這種用最本質的屬性表示一個自系統的方法就是“抽象”。
2.SA 法的步驟
⑴建立當前系統的“具體模型”;
系統的“具體模型”就是現實環境的忠實寫照，即將當前系統用DFD 圖描述出來。這樣的表達與當前系統完全對應，因此用戶容易理解。
⑵抽象出當前系統的邏輯模型;
分析系統的“具體模型”，抽象出其本質的因素，排除次要因素，獲得用DFD 圖描述的當前系統的“邏輯模型”。
⑶建立目標系統的邏輯模型;
分析目標系統與當前系統邏輯上的差別，從而進一步明確目標系統“做什么”，建立目標系統的“邏輯模型”(修改后的DFD 圖)。
⑷為了對目標系統作完整的描述，還需要考慮人機界面和其它一些問題。
3.SA 法的描述工具
⑴ 分層的數據流圖
⑵ 數據詞典
⑶ 描述加工邏輯的結構化語言、判定表或判定樹。
2 數據流圖
數據流圖(Data Flow Diagram，簡稱DFD)是描述系統中數據流程的圖形工具，它標識了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換邏輯輸出所需的加工處理。
1.數據流圖的圖符數據流圖有以下4 種基本圖形符號：
箭頭，表示數據流； 〇：圓或橢圓，表示加工； =：雙杠(帶一邊開口,一邊閉合)，表示數據存儲； □：方框，表示數據的源點或終點。
箭頭表示數據流，圓或橢圓表示加工。雙杠或者單杠表示數據存儲，矩形框表示數據的源點或終點，即外部實體。
⑴ 數據流 是數據在系統內傳播的路徑，由一組成固定的數據項組成。除了與數據存儲(文件)之間的數據流不用命名外，其余數據流都應該用名詞或名詞短語命名。數據流可以從加工流向加工，也可以從加工流向文件或從文件流向加工，也可以從源點流向加工或從加工流向終點。
⑵ 加工 也稱為數據處理，它對數據流進行某些操作或變換。每個加工也要有名字，通常是動詞短語，簡明地描述完成什么加工。在分層的數據流圖中，加工還應有編號。
⑶ 數據存儲 指暫時保存的數據，它可以是數據庫文件或任何形式的數據組織。流向數據存儲的數據流可理解為寫入文件，或查詢文件，從數據存儲流出的數據可理解為從文件讀數據或得到查詢結果。
⑷ 數據源點和終點 是軟件系統外部環境中的實體(包括人員、組織或其他軟件系統)，統稱為外部實體。一般只出現在數據流圖的頂層圖中。
10.面向對象技術中,對象是類的實例。對象有三種成份:(D )、屬性和方法(或操作)。
A、消息
B、規則
C、封裝
D、標識
解析：對象三大屬性 狀態，行為，標識符 標識符是一個對象的屬性，它用于區分這個對象與所有其他對象
11.系統流程圖是描述( D )的工具。
A、邏輯系統
B、程序系統
C、體系結構
D、物理系統
解析：系統流程圖是進行系統分析時常用的一種描述方法，它用物理符號以黑盒子的形式描繪系統里面的毎個部件。它表達的僅是信息在系統各部件之間流動的情況，而不是對信息進行加工處理的控制過程。
系統流程圖是概括地描述物理系統的傳統工具，它一般用在可行性分析階段。它的基本思想是用圖形符號以黑盒子的形式描繪組成系統的每個部件(程序、文檔、數據庫等)。系統流程圖表達的是數據在系統各個部件之間的流動情況，而不是對數據進行加工處理的控制過程，因此盡管系統流程圖的某些符號和程序流程圖的符號相同，但它卻是物理數據流圖而不是程序流程圖。
12.一個模塊把數值作為參數傳送給另一個模塊，這種耦合方式稱為( A )。
A、數據耦合
B、公共耦合
C、控制耦合
D、標記耦合
解析：2-3，2-4
13.模塊本身的內聚是模塊獨立性的重要度量因素之一，在七類內聚中，具有最強內聚的一類是( )。
A、功能性內聚
B、過程性內聚
C、邏輯性內聚
D、順序性內聚
解析：內聚強度從低到高如下所示： 偶然內聚，邏輯內聚，時間內聚，過程內聚，通訊內聚，順序內聚，功能內聚
14.為了提高軟件測試的效率，應該( D )。
A、隨機地選取測試數據
B、取一切可能的輸入數據作為測試數據
C、在完成編碼以后制定軟件的測試計劃
D、選擇發現錯誤可能性最大的數據作為測試用例
解析：對于一個軟件，其可能的輸入數據數量一般是非常驚人的，所以要想全部將其作為測試用例是不現實的，應當選擇發現錯誤可能性大的數據作為測試用例，不能隨機選取測試用例
15.產生軟件維護的副作用是指( D )。
A、開發軟件時的錯誤
B、運行時的錯誤
C、隱含的錯誤
D、因修改軟件而造成的錯誤
解析：維護成本中 無形的代價包括: 1. 維護活動占用了其他軟件開發可用的資源，使資源的利用率降低；2. 一些修復或修改請求得不到及時安排，使客戶滿意度下降；3. 維護的結果把一些新的潛在的錯誤引入軟件，降低了軟件質量；4. 將軟件人員抽調到維護工作中，使得其他軟件開發過程收到干擾。
所謂副作用是指因修改軟件而造成的錯誤或其它不希望發生的情況，有三種副作用：修改代碼的副作用，修改數據的副作用和文檔的副作用。
修改代碼的副作用
在使用程序設計語言修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子程序、刪除或修改一個標號、 刪除或修改一個標識符、改變程序代碼的時序關系、改變占用存儲的大小、改變邏輯運算符、修改文件的打開或關閉、改進程序的執行效率，以及把設計上的改變翻譯成代碼的改變、為邊界條件的邏輯測試做出改變時，都容易引入錯誤。
修改數據的副作用
在修改數據結構時，有可能造成軟件設計與數據結構不匹配，因而導致軟件出錯。數據副作用就是修改軟件信息結構導致的結果。例如，在重新定義局部或全局常量、 重新定義記錄或文件格式、增大或減小一個數組或高層數據結構的大小、修改全局或公共數據、重新初始化控制標志或指針、重新排列輸入/輸出或子程序的參數時，容易導致設計與數據不相容的錯誤。數據副作用可以通過詳細的設計文檔加以控制。在此文檔中描述了一種交叉引用，把數據元素、記錄、文件和其它結構聯系起來。
文檔的副作用
對數據流、軟件結構、 模塊邏輯或任何其它有關特性進行修改時，必須對相關技術文檔進行相應修改。否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤。使得軟件文檔不能反映軟件的當前狀態。對于用戶來說，軟件事實上就是文檔。如果對可執行軟件的修改不反映在文檔里，就會產生文檔的副作用。例如，對交互輸入的順序或格式進行修改，如果沒有正確地記錄在文檔中，就可能引起重大的問題。過時的文檔內容、索引和文本可能造成沖突，引起用戶的失敗和不滿。因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。
總結
- 上一篇： java宿舍信息管理系统_Java宿舍管
- 下一篇： 华为基本法 读书笔记