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》標準按過程主體把軟體生存週期過程分為基本過程、支援過程和組織過程。