自考軟件工程選擇填空必考知識點（整理自歷年真題）

1.軟件系統模型分類：概念模型，軟件模型。
2.功能需求，非功能需求（性能需求，外部接口需求，設計約束和質量屬性（可靠性，存活性，可維護性，用戶友好性）需求）。
3.初始需求發現技術：自悟，交談，觀察，小組會，提煉。
4.需求規約基本性質：重要性和穩定性程度，可修改的，完整的，一致的。
5.需求規約三種風格：非形式化，半形式化，形式化。
6.軟件開發的本質：不同抽象層術語之間以及不同抽象層處理邏輯之間的映射。
7.結構化分析方法給出了一種能表達系統功能模型的圖形化工具是數據流圖。
8.數據流圖，DFD圖，用來描述數據變換，元素包括：數據流，數據存儲，數據源，數據潭，加工（數據變換單元）。
9.單個需求的屬性：必要的，可測的，無歧義的，可跟蹤的，可測量的。
10.描述加工的三種表達工具：結構化自然語言，判定表，判定樹。
11.耦合因素：一個模塊對另一個模塊的引用，一個模塊向另一個模塊傳遞數據，一個模塊對另一個模塊施加控制。
1）內容耦合：A直接修改或操作B中的數據。
2）公共耦合：兩個或以上模塊共同引用一個全局數據項。
3）控制耦合：一個模塊通過接口向另一個模塊傳遞一個控制信號。
4）標記耦合：A通過接口向B和C傳遞一個公共參數，則BC存在標記耦合。
5）數據耦合：模塊之間通過參數來傳遞數據，最低的耦合形式。
12.內聚：
1）偶然內聚：基本不存在任何關係。
2）邏輯內聚：邏輯相關的功能被放在同一模塊中。
3）時間內聚：同一時間內執行的功能僅僅因爲時間因素關聯在一起，放入一個模塊中，即爲時間內聚。
4）過程內聚：一個模塊內部的處理成分是相關的，必須以特定的次序執行，則稱爲過程內聚。
5）通信內聚：所有成分都操作同一數據集或生成同一數據集。
6）順序內聚：各個成分和同一個功能關係密切，且一個成分的輸出作爲另一個成分的輸入。
7）功能內聚：最理想的內聚，所有成分對於完成一個單一功能來說都是基本的。
13.高內聚，低耦合的啓發式規則：
改進軟件結構，提高模塊獨立性；
力求模塊規模適中；
力求深度（控制的層數），寬度，扇入（被多少個上層模塊調用）和扇出（直接控制的下級模塊數目）適中；
盡力使模塊的作用域（受該模塊內一個判定影響的所有模塊的集合）在其控制域（模塊本身和所有直接或間接從屬它的模塊）之內；
盡力降低模塊接口的複雜度；
力求模塊功能可以預測。
14.總體設計工具：模塊結構圖，層次圖， HIPO圖。
15.詳細設計工具： 程序流程圖 盒圖（N-S圖）問題分析圖（PAD圖）類程序設計語言PDL。
16. UML描述事物的八個術語：類與對象，接口，協作，用況，主動類，構件，製品，節點。
UML描述事物之間相互依賴和作用的4個術語：關聯，泛化，細化和依賴。
UML的兩類圖形化工具：結構圖——用於表達系統或系統成分的靜態結構模型，給出系統或系統成分的一些說明信息。
行爲圖——用於表達系統或系統成分的動態結構模型，給出系統或系統成分的一些行爲信息 。
17.軟件開發中的四種建模工具：
類圖：可視化的表示系統靜態結構模型的工具。
用況圖：表達系統功能模型的圖形化工具。
狀態圖：用來表示狀態機的圖，可以包含一個狀態機任意的 所有的特徵。
順序圖：是一種交互圖，由一組對象以及按照時序組織的對象之間的關係組成，其中還包含這些對象之間所發送的消息 。
18.RUP（統一軟件開發過程）以用況爲驅動的（通過用況分析獲取用戶需求），以體系結構爲中心的迭代、增量式開發。。
19.發現錯誤是保障軟件過程質量和軟件產品質量的基礎，軟件測試的首要目標是預防錯誤，次要目標是發現錯誤。
20.軟件評估可分爲靜態評估技術和動態評估技術（軟件測試——按照特定規程發現軟件錯誤的過程）。
21.軟件測試技術分爲兩類：
白盒測試技術，又稱結構測試技術，典型的是路徑測試技術，依據是程序的邏輯結構；
黑盒測試技術，又 稱爲功能測試技術，依據是軟件行爲的描 述，包括事務處理流程技術，狀態測試技術，定義域測試技術等。。
22.控制流程圖：
一種表示程序控制結構的圖形化工具，基本元素是過程塊，節點和判定。
控制流程圖與程序流程圖的區別：
控制流程圖中不現實過程塊的細節，程序流程圖中着重於過程屬性的描述。
23.路徑測試技術測試策略：
最強策略：路徑覆蓋，很難實現。最弱：語句覆蓋，檢測錯誤能力弱，其次分支覆蓋，再次條件覆蓋與條件組合覆蓋 。
24.軟件測試是一個有程序的過程，包括測試設計、測試執行以及測試結果比較。
25. 路徑測試技術路徑選取原則：
選擇最簡單的，具有有一定功能含義的入口/出口路徑 。
在已選取的基礎上，選取無循環的路徑；選取短路徑、簡單路徑。
選取沒有明顯功能含義的路徑，研究這樣的路徑爲什麼存在，爲什麼沒有通過功能上合理的路徑得到覆蓋。
26、基於事務流的測試技術（黑盒測試技術，功能測試技術，基於軟件規約的測試）：事務流程圖作爲表達被測軟件模型的工具。
事務流程圖要素：操作，分支，節點和 鏈。
事務流程圖 與控制流程圖之間的主要差異：
基本元素模型所表達的語義不同；一個事務不等同於路徑測試中的一條路徑；
事務流程圖中的分支和節點可能是一個複雜的過程，一方面不但可以包括支持系統的一些操作，也可以包括被測試軟件的一些操作。
27.事務流測試技術的步驟：
獲得事務流程圖；瀏覽、複審，對事物進行分類，關注“並生”，“絲分裂”“吸收”和“結合”事務；用例設計，設計足夠的測試用例，實現基本事務覆蓋；測試執行。
28.等價類劃分：劃分等價類（有效等價類和無效等價類）；設計測試用例（建立等價類表，然後設計測試用例）
29.邊界值分析：大量錯誤經常發生在輸入或輸出範圍的邊界上，設計測試用例時應選擇一些邊界值。
30.因果圖：着重檢查各種輸入條件的組合，通過生成判定表，針對判定表的每一列生成測試用例 。
31.軟件測試序列 ：單元測試，集成測試，有效性測試和系統測試。
32.軟件生存週期模型：瀑布模型，增量模型，演化模型、螺旋模型、噴泉模型。
33.瀑布模型規定了各開發階段的活動：系統需求、軟件需求、需求分析、設計、編碼、測試和運行。
34.CMMl模型基於過程途徑思想，通過過程把軟件質量3個支撐點：受訓的人員、規程和方法、工具和設備進行集成，以開發所期望的系統／產品。
35．CMMl模型提供了兩種過程改善路徑，一是稱爲能力等級的過程改善路徑（未完成級，已執行級，已管理級，已定義級，已定量管理級，持續優化級），二是稱爲成熟度等級的過程改善路徑（初始級，已管理級，已定義級，已定量管理級，持續優化級）。。
36.針對開發的CMMl是一個有關產品和服務的過程改善的成熟度模型，集成了3個源模型：軟件CMM，系統工程CMM，集成產品開發CMM。
37.由於軟件錯誤的複雜性，在軟件工程測試中，應綜合運用測試技術，並且應實施合理的測試序列：單元測試、集成測試、有效性測試和系統測試。
38.．對於一個項目而言，過程管理計劃是項目管理計劃的主體，一般還可能存在一些對支持生存週期過程具有重要作用的其他計劃，包括軟件工程管理計劃、軟件配置管理計劃、軟件質量保證計劃、軟件驗證和確認計劃和軟件度量計劃。
39.軟件基本過程指那些與軟件生產直接相關的活動集，可分爲供應過程、獲取過程、開發過程、運行過程、維護過程。
40.RUP利用UML提供的術語和工具定義了需求獲取層、系統分析層、設計層和實現層，並給出了實現各層模型之間映射的基本活動以及相關的指導。
41.軟件測試是一個有程序的過程，包括測試設計、測試執行以及測試結果比較等。由於軟件錯誤的複雜性，在軟件工程測試中，應綜合運用測試技術，並且應實施合理的測試序列：單元測試、集成測試、有效性測試和系統測試。
42.在單元測試期間，通常要考慮模塊的四個特徵：1.模塊接口。2.局部數據結構。3.重要的執行路徑。4.錯誤執行路徑。
43.軟件生存週期模型：
1.瀑布模型，70年代提出，系統需求，軟件需求，需求分析，設計，編碼，測試，運行
2.增量模型，第一個交付版本時間成本都較少，減小風險，前提是需求可結構化
3.演化模型，有彈性的過程模式，事先不能定義完整需求
4.螺旋模型，加入風險分析
5.噴泉模型，體現了軟件開發所固有的迭代和無間隙的特徵
43.《IS0／IEC軟件生存週期過程l2207—1995》標準按過程主體把軟件生存週期過程分爲基本過程、支持過程和組織過程。