軟件的定義 軟工 :: 概述 程序 ：為完成特定任務的指令 數據 ：由數據結構組織，是程序操作的對象 文檔 ：為便于維護，編寫的說明性文字
軟件危機是什么 軟工 :: 概述 軟件在整個生命周期中遇到的嚴重的麻煩問題
舉例軟件危機有哪些 軟工 :: 概述 項目超出預算 → 虧損 項目超時 → 不能交付 軟件質量差 → 不合要求 → 不能交付
軟件的特征 軟工 :: 概述 胡磊式抱怨： 1、（各個過程都）xxx特別困難 估計開發時間 特別困難 估計工作量 特別困難 軟件測試 特別困難 軟件維護 特別困難 2、xxx有新問題 軟件維護 產生新問題 3、軟件不會磨損，但會退化和廢棄
軟件危機產生的原因應該從哪些角度來談 軟工 1、軟件自身特點（與物相關） 2、軟件開發與維護方法（與人相關） 軟工 :: 概述 :: 軟件危機
產生軟件危機中與 軟件自身特點 相關的原因 軟工 1、軟件是邏輯部件 => 缺乏可見性 => 進度、質量難以衡量 2、軟件需要維護 => 維護需要修改 => 修改產生錯誤 3、規模龐大 => 需合作開發 => 需涉及很多方法 這三點是相互促進的，增加的難度都是指數級的。
軟件危機產生原因中與人相關的原因 軟工 1、需求分析階段：不充分或錯誤 2、開發階段：不規范 3、質量保證階段：缺少測評手段 3、維護階段：難以維護 <= 開發階段不重視文檔 軟工 :: 概述 :: 軟件危機 分階段出現問題。需求分析有問題，開發有問題，測試/質量保證有問題，維護有問題。
簡述整本書的框架邏輯 軟工
軟件工程的定義 軟工 （1）應用 系統化、規范化、可量化的方法（采用的方法）來 開發、維護 軟件（目的）， =即 把工程應用到軟件（總結） （過程） （2）對（1）方法的研究 （研究） （1）顧名思義，軟件工程=軟件+工程。那受作用的對象就是軟件，而方法就是工程化。 對其進一步解釋工程是什么，答案是：工程是系統的、規范的、可度量的 對其進一步解釋軟件要干什么，答案是：目的是開發、維護軟件 總結，這其實就是工程化的方法。 （1）有了方法論，還得上升一步，對整個方法過程進行研究提升優化，那就是對上述過程的研究。 軟件需求規格說明書和需求建模的要求也是系統化、規范化
軟件工程的三要素有哪些 軟工 質量焦點（基礎）→ 1、過程 → 2、方法 → 3、工具
軟件工程三要素中 過程的含義 軟工 連接軟工的各個階段，（含義）（理解，套話） 在各個環節之間建立里程碑，（關鍵詞） 以提升軟件質量、縮短開發時間。（目的） 最后一句是一句套話廢話，軟件工程干什么的目的最終都是提升質量和縮短時間。
軟件工程三要素中方法的含義 軟工 給軟件開發、維護提供解決方法。（含義） 方法依賴了一組原則，這是一組包含了所有技術領域的原則（關鍵詞） 最后可以加一句套話廢話：目的是為了縮短開發時間，提升軟件質量。
軟件工程三要素中工具的含義 軟工 為下層的過程和方法提供自動化或半自動化的支持（含義） 這樣的系統被稱為計算機輔助軟件系統。（關鍵詞） 軟工 :: 概述 :: 軟件工程
計算機輔助軟件工程 英文縮寫 CASE 中文名 軟工 :: 概述 :: 軟件工程三要素 Computer-Aided Software Engineering
軟件工程的根基是什么 軟工 質量關注點/質量焦點
軟件工程的發展過程可以分為哪幾代 第一代、傳統的軟件工程 第二代、對象工程 第三代、過程過程 第四代、構建工程 對象工程：c語言面向對象那種 過程工程：有了第二章軟件過程那些東西，瀑布、螺旋什么的 構建工程：組件化，工程化
七大類軟件的劃分 軟工 1、系統軟件：服務其他所有程序的基礎軟件，如windows 2、應用軟件：輔助完成特定領域 3、工程/科學軟件：如MATLAB 4、嵌入式軟件：如智能手表 5、產品線軟件：具有工業性質的 6、移動App：如安卓app 7、人工智能軟件：用特殊算法解決復雜問題 軟工 :: 概述
軟件工程的七個原則（西德專家） 瀑布質量保證的兩點：1、計劃 2、評審 項目管理方面： 3、質量保證的方法：規范化 4、明確權責 5、先進技術 6、少而精 7、不斷改進 西德一個軟件工程專家提出來的，很多資料都有 1、（初始）嚴格的計劃 <= 大量失敗源于計劃不周 2、定期評審 <= 盡早發現錯誤 <= 越晚發現錯誤，代價越高 3、嚴格的產品控制 ： 給予每部分不同的權限，不能想改就改，命名什么的都要規范 4、使用先進技術 ：這技術包括編程工具、開發技術、維護技術 5、規定權責和時限 <= 更好地進行管理 6、開發人員少而精 : 避免胡磊這種垃圾 7、不斷改進，不斷迭代，不斷提升
軟件生命周期的概念 軟工 軟件產品 或 軟件系統（主體） 從 定義，設計，投入使用到被淘汰的過程 軟工 :: 過程模型
軟件過程的概念 軟工 軟件過程是軟件生產一系列活動的總和，這些活動覆蓋了軟件開發的整個過程 軟件工程三要素中也有一個“過程”他們的答案是可以通用的。
能力成熟度模型是哪個學校提出來的 軟工 卡內基梅隆大學CMU 軟工 :: 軟件過程
能力成熟度模型 英文縮寫 CMM 中文名 軟工 軟工 :: 過程模型 Capability Maturity Model
能力成熟度模型的分級 軟工 1、初始級：一般學生出來創業的狀態 2、可重復級：希望學生們能夠有些管理，能達到這個水平 3、已定義級：公司里面差不多就這樣，有了標準，把標準貼到墻上 4、量化管理級：有些有歷史的公司可以量化管理，采集數據然后分析幫助maneger 5、優化級：可以不斷進步改進升級 軟工 :: 軟件過程 公司里最喜歡就是量化管理了，說什么KPI，績效什么的。
CMM是干什么的 軟工 能力成熟度模型是一個標準，這個標準對軟件過程中的各個階段的好壞進行了描述。 軟工 :: 過程模型 定量描述了軟件過程的好壞程度。
軟件開發模型 的同義詞 軟工 軟件過程模型 軟工 :: 軟件過程模型
軟件生存周期模型 的同義詞 軟件過程模型 軟工 :: 軟件過程模型
軟件過程模型的概念 是一種結構框架， 能直觀表達整個過程，（目的） 包含了軟件開發的過程、活動、任務、策略，（內容） 為了完成任務制定的一系列框架，規定了各個步驟
軟件工程三要素各個要點答題的思路 軟工 含義+關鍵詞+目的 軟工 :: 概述 :: 軟件工程 :: 軟件工程三要素 目的都是更好更快， 關鍵詞：過程：里程碑；方法：一組原則；工具：CASE
軟件生命周期各個階段的完整順序 軟工 1、問題定義 2、可行性研究 3、需求分析 4、概要設計 5、詳細設計 6、程序開發 7、測試/質量保證 8、軟件維護
問題定義 階段 此階段產生了什么 項目計劃報告 是在哪一階段產生的 軟工 軟件工程 :: 過程模型
可行性研究 階段 此階段產生了什么 可行性研究報告 是在哪一階段產生的 軟工 軟工 :: 過程模型
需求分析 階段 此階段產生了什么 需求分析規格說明書 是在哪一階段產生的 軟工 軟件工程 :: 過程模型 還有需求建模
概要設計 階段 此階段產生了什么 概要設計說明書 是在哪一階段產生的 軟工 軟工 :: 過程模型
詳細設計 階段 此階段產生了什么 詳細設計說明書 是在哪一階段產生的 軟工 軟工 :: 過程模型
程序編寫 階段 此階段產生了什么 源代碼 是在哪一階段產生的 軟工 軟工 :: 過程模型
軟件測試 階段 此階段產生了什么 測試報告 是在哪一階段產生的 軟工 軟工 :: 過程模型
軟件維護 階段 此階段產生了什么 維護說明書 是在哪一階段產生的 軟工 軟工 :: 過程模型
軟件過程模型中經典模型是哪一個 瀑布模型
軟件工程范型 的同義詞 軟件過程模型
瀑布模型是以什么為驅動的 以文檔為驅動 軟工 :: 過程模型
軟件生命周期和哪一種軟件開發模型是一致的 瀑布模型 軟工 :: 軟件過程模型
瀑布模型的順序性和依賴性的含義 兩重含義： 1、在時間上，只有前一階段完成后，后一階段才能開始。（順序性） 2、在內容上，前一階段的輸出是后一階段的輸入。（依賴性） 過程模型 :: 瀑布
瀑布模型中推遲實現的含義 編碼時間越早 → 最終開發時間反而越長 為解決這個問題， 瀑布模型中，編碼階段之前有需求分析、系統設計等階段，對軟件進行了深入分析， 通過推遲編碼的時間，讓軟件開發效率更高。 過程模型 :: 瀑布
瀑布模型每個階段都需要完成哪兩個重要做法 1、每個階段完成相應文檔 2、每個階段對文檔進行評審 過程模型
瀑布模型的特點/優點 1、順序性和依賴性 2、推遲實現 3、每個階段交付文檔 4、每個階段完成文檔審查 質量好、文檔驅動、穩定
瀑布模型的質量保證方法是什么 1、每階段交付文檔 2、每階段對文檔進行評審 過程模型
理想中的瀑布模型與實際的瀑布模型有什么區別 理想中的瀑布模型是筆直單向前進的， 而實際的瀑布模型是帶反饋的，若某一階段出現了問題會回到相應階段做修改。
大部分軟件預算花費在{{c1::}} 軟件維護 軟件開發 軟件測試 系統設計 需求分析
如何理解“瀑布模型是由文檔驅動的”這句話的含義 瀑布模型的核心就是文檔， 瀑布模型的主要優點和主要缺點都是跟文檔相關的。
瀑布模型的缺點 總：太過理想化 1、階段劃分固定 → 階段間有大量文檔 → 增加工作量 2、開發模型線性 → 末期才能看到產品 → 增加風險 3、開發模型線性 → 后期才能進行測試 → 增加工作量 4、難以勝任 需求變化和需求不明確 的情況 這些優缺點并不是每個過程獨有的，而是整個類型的，相關的模型都具有相同的優缺點。
瀑布模型適用于什么場合 需求明確（需求變動是瀑布模型弱點之一） 技術成熟（因錯誤后期才維護是瀑布模型弱點之一） 工程管理嚴格（瀑布模型需要每階段寫文檔并評審） 過程模型 :: 瀑布模型
漸增模型是什么 增量模型 過程模型 :: 增量模型
簡述增量模型的概念 軟工 把軟件分解成各個模塊， 第一個模塊完成最核心的功能， 然后逐漸添加更加次要功能的模塊到軟件上。 軟工 :: 過程模型
RAD 中文名 快速應用開發（模型） 英文縮寫 過程模型 過程模型 :: 增量過程模型 Rapid Application Development模型
增量過程模型的分類 軟工 增量模型 RAD模型
增量過程模型與RAD的關系 RAD是一種增量過程模型
增量模型中所謂的 增量是什么意思 軟件模塊構件 過程模型
增量模型的優點 1、只要有一個增量，就能進行開發 2、初期不用太多人力資源 3、增量可以有效管理技術風險。（一個增量有問題，不會使整個軟件重新調整） 4、更早進入市場 5、給予用戶充足學習時間。
開放的軟件體系結構的含義 軟工 1、新增加的構件不會破壞原有結構 2、擴充新構件的過程簡單、方便 軟工 :: 過程模型 :: 增量 一方面是對原有的：不會改變破壞 另一方面是對將來的：可擴充，并且擴充方便
增量模型的缺點 軟工 1、軟件體系結構必須是開放的，這非常困難。 2、每個增量必須提供部分系統功能 => 增量的劃分很困難 3、不斷修改 => 易失去整體性 軟工 :: 過程模型 :: 增量
增量模型適用于什么場合 軟工 1、變化多 2、要早日進入市場 軟工 :: 過程模型 :: 增量
簡述RAD模型 軟工 與瀑布模型類似，都是按照軟件生命周期順序來開發軟件。不過比起瀑布模型，更強調速度。 與增量模型的共同點是 都是按照構件開發軟件的。 RAD模型是在瀑布模型的基礎上，強調快速開發，按照構件的形式劃分軟件，然后對軟件進行整合。 軟工 :: 過程模型 :: 增量過程模型 :: RAD模型
快速應用開發模型 強調什么 軟工 短暫的開發周期/快速 軟工 :: 過程模型 :: 增量過程模型 ::RAD
RAD的缺點 軟工 1、需要大量人力（獨有缺點） 2、三種系統不適用： 無法合理模塊化的系統（模塊化的問題，也是增量模型的問題） 需要后期調整的（瀑布模型的缺點） 技術風險高的系統（瀑布模型的缺點） 軟工 :: 過程模型 :: 增量過程模型 :: RAD
原型模型 與 演化過程模型 的關系 原型模式是一種演化過程模型 過程模型
螺旋模型 與演化過程模型的關系 螺旋模型是一種演化過程模型 過程模型 :: 演化過程模型 演化過程模型：改來改去模型。
原型模型與螺旋模型的關系 兩者都屬于演化過程模型，是并列關系。 過程模型 :: 演化過程模型
在ppt中演化模型{{c1::}}演化過程模型 等同于 不同于
增量過程模型基本的思想是什么 通過以模塊化構建，逐漸完成一個功能完整的系統。 每一個增量的開發都是一個瀑布模型。
演化模型的基本思想是什么 先實現最核心的功能 過程模型 :: 演化 改來改去，改來改去模型都是現實性最核心的。 增量模型也是
原型開發范型 的同義詞 原型開發過程模型 過程模型 :: 演化 :: 原型
什么時候適用于原型開發模型 1、客戶定義了一些基本任務，但沒有明確具體任務 或 2、開發者對種種具體情況沒有把握。 軟件過程模型 :: 演化 ::原型 說白了就是其中一方沒搞明白，后面需要一直改改改的情況。 什么時候適合原型開發？–答沒搞懂的情況下
原型模型的優點 先開發出核心 => 減少不明確需求的風險 過程模型 :: 演化 :: 原型 可以一直改改改，改得快。 我還可以說，它有這些優點： 投入市場早，早點給用戶學習，反饋及時改需求方便，有bug可以很早發現，不用到了最后項目結束測試階段才發現問題，用戶可以很快看到軟件，并明確自己的需求。
簡述原型模型的過程 溝通（需求獲取） → 快速策劃、設計 → 開發（構造原型） → 交付使用 → 獲取反饋 → （重新開始） 過程模型 :: 演化 :: 原型
原型模型的缺點（獨有部分） 1、客戶意識不到一些質量問題 2、工程師為了快速運行程序 => 得進行折衷（關鍵詞） => 會產生一些質量問題 3、快速建立 + 多次修改 => 質量差 演化模型：多次修改，沒有用構件的方式。 增量模型：所謂增量就是構件，使用了構件的方式具有模塊化。 只要是交給用戶先看，用戶又不懂，很多問題他都意識不到。
螺旋模型有哪四個象限 計劃 風險 工程 反饋 軟工 :: 過程模型 :: 演化 :: 螺旋 風險是螺旋的特點，因此專門有個象限是風險評估。 1、計劃制定 2、風險評估 3、工程實施 4、客戶評估
軟件開發的風險有哪些，請粗略說明（非考綱） 1、用戶對產品不滿意 2、到了期限未能交付 3、程序員跳槽
原型的概念 原始的類型，為后期的完整開發提供基礎 軟件過程 :: 演化
螺旋模型強調什么 風險管理 過程模型 :: 演化過程模型 :: 螺旋模型
螺旋模型適合于{{c1::}}的開發 大型軟件 小型軟件 技術成熟的軟件 技術不成熟的軟件 過程系統
螺旋模型的優點 1、支持需求變化 2、開發了原型 => 便于用戶和開發者共同理解 => 便于決策 3、可及時調整決策 => 降低風險 4、可擴充、可修改 => 提高軟件適應能力 修修改改的模型：兩種演化模型（原型+螺旋）都很適合需求變化。 修修改改的模型都可以及時調整決策，也可修改，可擴充。 兩種增量模型也是可擴充的，但是經典的瀑布式就是難以修改和擴充的。
螺旋模型的缺點 1、對開發者要求高 2、需要風險評估（因為螺旋模型重視風險評估） 3、迭代次數多→增加時間、成本 過程模型 螺旋的特色就是風險。
螺旋模型適用場景 1、需求不明確（需求變動是螺旋模型的亮點） 2、大型軟件 3、支持多種開發方法，如面向過程、面向對象（不明白） 過程模型
簡述噴泉模型的過程 為保證統一性， 在整個過程中圍繞“對象”展開， 因而各階段的界限變得模糊。 過程模型 :: 噴泉 關鍵詞：對象驅動、邊界模糊、同時進行
噴泉模型中“噴泉”的含義 表明各個階段之間界限模糊、無縫銜接、同時進行 這不是糊弄人嘛，你是從火星來的嗎，噴泉長這個樣子嗎？
軟件開發過程中迭代的含義 過程模型 這個階段反復做，寫了改，改了寫
噴泉模型以什么為動力 用戶需求 軟件過程模型 這廢話，所有的模型都是以用戶需求為動力的。 瀑布模型是文檔驅動的
噴泉模型是以什么為驅動的 對象驅動 軟件過程模型 整個開發過程圍繞對象展開，確保統一性。
噴泉模型的優點 各階段無明顯界限 => 可同時開發 => 開發效率高 => 節省時間 軟件過程模型
噴泉模型的缺點 開發階段重疊 => 需要大量人員 => 不利于項目管理（RAD模型也是） 信息隨時會加入 => 文檔管理困難
敏捷聲明的內容 1、個體和交互 勝過 過程和工具 2、可工作的軟件 勝過 全面的文檔 3、客戶合作 勝過 合同談判 4、響應變化 勝過 遵循計劃
極限編程 英文縮寫 XP 中文名 軟件過程 軟件過程 :: 敏捷 eXtreme Programming
極限編程中“極限”二字的含義 把好的開發方法用到極值
舉例一些敏捷開發模型 極限編程/XP SCRUM 軟件過程 :: 敏捷
敏捷模型的優點 快， 不僅快，這樣的快還能持久。 軟件過程 :: 敏捷 對需求變更反應更快 plus.這種快速是可持續的 => 適合商業競爭下小項目
敏捷模型的缺點 1、不適用于大型軟件 2、軟件難以維護重構
Rational 統一過程 英文縮寫 RUP “中文”名 軟工 軟工 :: 軟件過程模型
RUP是干什么的 Rational軟件公司總結的軟件過程 軟件過程模型
RUP最佳實踐是什么 Rational公司總結的6條最有效的軟件開發經驗 軟件過程模型
需求分析的定義（原話） 以規范化、易理解、一致性的方式（對需求規格說明書的描述） 對待開發系統中有意義部分的描述（描述對象） 需求分析 需求分析的核心是需求規格說明書，而需求規格說明書的特點就是規范化、易理解… 而描述的對象是什么，是待開發系統中有意義的部分。
需求獲取的概念 1、一方面是一個動作，軟件需求的來源 2、一方面是一個方法，收集需求的方法 需求分析 需求獲取是需求分析過程中的第一步，所以說所有需求分析的信息都是來源于需求獲取的。 與IEEE軟件工程的定義一樣，給出了兩層含義，第一層是具體的，第二層是抽象的邏輯化的。于是這里第二層思想就是方法論。
需求抓取 的同義詞 需求獲取 需求分析
需求發現 的同義詞 需求獲取 需求分析
需求獲得 的同義詞 需求獲取 需求發現
需求分析的過程主線 需求獲取 → 需求提煉 → 需求描述 → 需求驗證
需求提煉的概念 對問題進行分析，對其建立模型， 要求精確化、完全化， 最后形成 需求規格說明書。 需求分析 :: 需求分析的過程 :: 需求提煉 因為整個需求分析過程中最重要的步驟就是需求規格說明書和建模，所以有時也把需求提煉這個單獨的步驟等同于整個需求分析，畢竟名字也可以叫得一樣。 說白了就是建模+需求規格說明書，精確化、完全化是需求規格說明書附加的內容。
需求描述完成的基本標志是什么 形成一份 完整的、規范的 需求規格說明書 需求分析 :: 需求分析的過程 :: 需求描述
需求規格說明書 的 作用 讓用戶和開發者對軟件的初始規定有共同理解， 使其成為開發的基礎 需求分析 :: 需求分析的過程 :: 需求描述 軟件過程模型 :: 需求分析 對雙方都是增強理解，對開發者起指導作用，對測試人員起參考作用。
需求管理的完整過程 分為 需求確認 和 需求變更 兩條線 1、需求確認部分（需求分析的步驟）： 需求獲取 → 需求提煉 → 需求描述 → 需求驗證 2、需求變更部分：需求變更
需求確認 與 需求驗證的關系 需求確認 是 軟件需求管理過程中的主要支線， 需求驗證 是 需求確認這條支線中最后一個步驟 因此，需求驗證 包含于 需求確認 需求分析 :: 需求分析的過程
需求分析的步驟 和 需求確認的關系 按照ppt的說法，兩者所包含的內容都是相同的 都是 需求獲取 → 需求提煉 → 需求描述 → 需求驗證 需求分析 :: 需求分析的過程
需求分析的作用 重要性（正面）： 1、對開發者： 增強對開發的指導 增強對用戶的理解 2、對用戶： 增強對開發者的理解 3、對測試人員： 提供參考 必要性（反面）： 錯誤的需求分析導致 開發失敗 需求分析 :: 需求分析的概念 搭建了橋梁，增加雙方的理解。 對于主要干事情的開發者而言，更是對他們工作的指導。 對于測試人員來說能提供參考，但相對開發者來說沒有這么重要。
需求分析的任務 1、建立分析模型（建模） 2、編寫需求說明書 這是最主要的兩點，本章這兩部分所包含內容也最多。
建模的作用 需求分析 確定目標，確定該做的事
功能性需求 和 非功能性需求 的含義 功能性需求：系統應該做什么 非功能性需求：標準、細節、質量等其他內容 需求分析
需求獲取技術有哪些 采訪 會議 觀察商業過程 注意，對應的還有質量驗證的技術。
需求獲取的挑戰 客戶說不清楚需求（老頭） 需求總是變（老頭） 問題復雜（問題本身） 理解問題：不全面，不一致（軟件公司這邊的問題） 需求分析 :: 需求分析的過程 :: 需求獲取
需求誘導十原則 交流方面： 1、傾聽 2、有準備的溝通 3、聚焦引導話題 4、當面溝通 5、繼續前進原則 6、記錄決定（存儲） 7、有人推動（動力） 8、圖形表示（轉碼） 好聽的話： 9、通力合作（廢話） 10、雙贏原則（好聽） 需求分析 :: 需求分析的過程 :: 需求獲取
需求分析 的一詞多義 （隨時增改） 需求分析： 章節名，軟件生命過程中的一部分 需求分析的過程：指的是軟件需求管理的主線，共有四個步驟 步驟名，與“需求提煉”同義，是需求分析過程的二個步驟 需求分析 因為需求分析作為一個大過程，最重要的內容就是建模和需求結構分析說明書，而這兩部分都是在小步驟需求提煉中完成的。所以大致上，需求提煉=需求分析。
需求提煉 的一個同義詞 需求分析 （需求分析有很多個含義，這只是其中一個奇葩含義。 需求分析通常是指軟件過程中的一個大的階段） 需求分析
需求提煉的定義 對問題和環境進行分析， 為此建立相應的模型， 使得用戶需求精確化、完整化， 最終的目的是 需求規格說明書 需求分析 :: 需求分析的過程 :: 需求提煉 需求提煉是需求分析最核心的部分，某種意義上可以等同于需求分析，而需求分析的核心是建模和說明書，因此需求提煉也就是建模和說明書。
需求分析的核心是什么 建立分析模型 其實還有需求分析說明書
分析建?？梢园凑漳男藴史诸?1、數據模型、功能模型、行為模型 的劃分 2、面向需求 和 面向過程 的劃分 需求分析 :: 分析建模
軟件需求規格說明書 的定義 是對待開發軟件行為的完整描述， 包含了功能性和非功能性需求 要求：清晰化、規范化、完整化 是開發人員與用戶溝通的橋梁，能夠促進相互之間的理解。
需求分析完成的標志是什么 完成了一份完整而規范的需求規格說明書 需求分析
軟件需求規格說明書有哪些原則（分性質和內容） 需具備的性質： 全面性 規范性 無二義性 可操作性 可擴充性 需描述的內容： 描述功能而非具體做法 描述運行環境 描述更大的整體 需求分析 需求規格說明書答題模板
需求驗證的必要性 如果錯誤，返工代價大 需求分析 :: 需求分析的過程 :: 需求驗證 原話：如果后期發現錯誤，會付出更大代價導致返工
對需求文檔應進行哪些檢查 1、有效性檢查： 各種功能是否有效 2、一致性檢查： 文檔內部不能有沖突 3、完備性檢查： 文檔應包含所有用戶的全部需求 4、現實性檢查： 現有技術能夠實現 需求分析 :: 需求分析的過程 :: 需求驗證 現實性檢查即檢查可操作性， 一致性檢查即檢查自洽性，有無內部沖突， 完備性即檢查完整性，是否寫完了
需求驗證技術有哪些 1、瀑布里有評審，這里也有評審 評審分正式和非正式兩種 2、需求分析要產生用戶手冊，這里也要產生用戶手冊 3、原型模型有原型，這里也有原型 4、軟件測試有用例，這里也有用例 5、軟工三要素有CASE，這里也有CASE，當然要保證“一致性” 需求分析 :: 需求分析的過程 :: 需求驗證 五種方法在書中都有對應的部分 1、需求評審：有正式和非正式兩種，類似于瀑布中各個階段的評審（項目管理的文科方法） 2、編寫用戶手冊。（傳統文本方法） 計算機科技方法： 3、利用原型檢驗系統。（先編程） 4、對每個需求編寫測試用例。（再寫用例） 5、檢驗模型的一致性。如CASE工具（完整成熟的工具）
ERD 中文名 實體-聯系圖 英文縮寫 需求分析 :: 建模 E-R圖 Entity - Relationship Diagram
數據字典 英文縮寫 DD 中文名 需求分析 :: 建模 Data Dictionary
數據流圖 英文縮寫 DFD 中文名 軟工 需求分析 :: 建模 Data Flow Diagram
狀態變遷圖 英文縮寫 STD 中文名 軟工 需求分析 :: 建模 State Transition Diagram
數據流圖長什么樣 需求分析 :: 建模 它表示的都是數據在各個主體之間的流動方向。
用例圖長什么樣 用例圖的特點就是有很多小人。
時序圖 同義詞 順序圖 同義詞 軟工 需求分析 :: 建模
順序圖長什么樣 需求分析 :: 建模
用例圖 中文縮寫 UCD 中文名 需求分析 :: 建模 Use Case Diagram
類圖 英文縮寫 CD 中文名 建模 需求分析 :: 建模 Class Diagram
軟件設計 的同義詞 系統設計 系統設計
軟件設計的定義(IEEE) (IEEE給出的） 軟件系統 或 其組件的架構、構件、接口 and so on 的 定義過程 及其結果 軟件設計 軟件設計=系統設計=架構設計+數據設計+構件設計+接口設計 按照IEEE的風格，一般有兩層含義：一是定義過程，二是其結果。 軟件設計/系統設計的分類是怎樣的：系統架構、構件、接口設計，設計了這些東西再加上設計的過程和結果。
在面向過程設計過程，需要具體設計哪些部分？ 請把這些部分歸納為概要設計或詳細設計。 概要設計部分： 接口設計 數據設計 體系結構設計 詳細設計部分： 過程設計 系統設計
在面向對象設計過程，需要具體設計哪些部分？ 請把這些部分歸納為概要設計或詳細設計。 概要設計： 接口設計 類/數據設計 體系結構設計 詳細設計： 構件級設計 系統設計
概要設計包括哪些內容 接口設計 數據設計 組件設計（沒有叫設計這個構件的內部） 體系結構設計 系統設計 :: 概要設計
概要設計中哪一個是主要內容 體系結構設計 系統設計 :: 概要設計
詳細設計的概念 對概要設計設計出的具體模塊或具體過程進行進一步設計， 使其能編碼實現。 系統設計 :: 詳細設計
頂層設計是什么（同義詞） 概要設計
軟件架構設計是什么（同義詞） 概要設計
總體設計是什么（同義詞） 概要設計
好的設計須具備的三個特點（ppt上說三個，實際上拆開不止三個） （軟件需求說明書的要點+隱藏需求） 1、滿足明確要求與隱藏要求 2、易讀易理解 3、完整性 4、可行性/現實性/可操作性 1、實現所有模型中的 明確要求 和 隱藏要求。（對客戶給出的需求方面） 2、設計對后階段的人員（編碼、測試、維護）易讀易理解。（對我們的工程師而言） 3、完整性：包含整個軟件 可行性：能解決數據、功能、行為各領域的問題（對軟件設計本身而言）
哪些過程模型是先完成最核心的板塊 增量模型、螺旋模型、原型模型
系統設計的指導原則 中 數據、體系結構、接口、組件設計的具體要求是什么 1、對于組件：功能獨立 2、對于接口：能組件間或與外部相連 3、對于數據結構：能為系統所用 系統設計 :: 系統設計指導原則 后兩點都是廢話，就像說鞋的要求是能穿一樣。 對于組件來講，功能獨立是其基本要求，ppt也花了不少篇幅來講這個。
系統設計的指導原則有什么（5點） 1、是架構（整體而言） 2、模塊化（具體往下） 3、具體到各方面 4、由需求分析中的信息驅動（信息來源） 5、正確、清楚（表示方式） 系統設計 包含了來源、表示方式、具體的，整體的 1、設計出的是架構 2、模塊化 3、包含各個方面：數據、體系結構、接口、組件（可展開） 4、由軟件需求分析中信息驅動 5、表示方式：正確、清楚
軟件設計中有哪些質量屬性 功能性：Dell可以跑MATLAB，而Surface不可以 易用性：Surface在哪兒都可以打開，很方便 可靠性：Dell電腦相對穩定，不會時不時宕機 性能：Dell電腦性能相對較強，可以滿足我的正常需求 可支持性：擴展性、適應性、可維護性 系統設計
可支持性的細分分類 擴展性：我的Dell電腦可以擴展出多顯示器 適應性：Dell電腦在強磁場也能工作 可維護性：電池壞了也可以換 系統設計 :: 設計質量的屬性 :: 可支持性 這里和其他部分有沖突，進行模糊化處理。
書上經典圖中設計模型有哪些層次 第一層：構件級設計 第二層：接口設計 第三層：體系結構設計 第四層：數據/類設計
抽象的概念 找到本質和共性，拋去細節和差異。 系統設計 :: 八大概念
體系結構的定義 1、軟件的整體結構。 2、它提供了一種概念，這種概念能夠完善系統中各個構件的組織方式、相互作用的方式。 系統設計 :: 八大概念 書上有完整的專業性表述
體系結構可以用那些模型表示 關于整體的： 結構模型 框架模型 有變化的： 動態模型 過程模型 做事情的： 功能模型 系統設計 :: 八大概念 對應于什么層次模型、數據流模型、對象模型、調用模型
設計模式的含義 設計模式處在一個特定的環境中，因此需要聯系上下文， 在這種環境中特定的問題有特定的解決方案，這些問題和解決方案具有共同性。 系統設計 :: 八大概念 :: 設計模式
數據抽象的含義 描述對象的數據集合 門：門的類型、門的重量… 系統設計 :: 八大概念 :: 抽象 如：門xxx
過程抽象的含義 有限、明確的功能指令集合。 開門：（包含各種過程）走到門前，拉門，轉把手… 系統設計 :: 八大概念 :: 抽象
模塊化的概念 將軟件劃分為若干個相對獨立的組件， 以這些組件的集成解決問題 系統設計 :: 八大概念
模塊{{c1::}}組件 等于 不等于
簡述模塊個數與工作成本的關系 模塊數量越大，集成成本越高。 模塊數量越小，單個模塊成本越高。 只有當模塊個數適中時，工作成本才最小。 系統設計 :: 八大概念 :: 模塊化
模塊有哪些設計標準 1、往下：可分解性 2、往上：可以組裝成新組件 3、可理解 4、遇到變化：連續性，小變化只影響本模塊 5、遇到異常：模塊化的保護：異常只影響本模塊 系統設計 :: 八大概念 :: 模塊化 1、可分解性：可分解為子問題（內部往細節看） 2、組合性：模塊可以組裝成新組件（外部往大了看） 3、可理解性（對程序員來講） 4、連續性：小變化只影響單個模塊 5、模塊化的保護：內部異常只影響本模塊 后面兩條都一個意思，不過一個是正面的，另一個是負面的。
信息隱藏這個概念是關于什么問題的 信息隱藏是模塊劃分的原則之一。 系統設計 :: 八大概念 :: 信息隱藏
信息隱藏的含義 如果另一個模塊不需要本模塊的相關信息，那么這個模塊不能訪問本模塊的信息 系統設計 :: 八大概念 :: 信息隱藏
功能獨立的概念 1、每個模塊只負責特定的獨立功能 2、對外接口簡單 系統設計 :: 八大概念 :: 功能獨立
功能獨立的優點 易于開發： 功能單一（對本身而言） 接口簡單（對外面信息交換而言） 易于測試和維護： 錯誤傳遞少 => 錯誤影響小（因為功能單一） 模塊重用（維護和測試量大大降低） 系統設計 :: 八大概念 :: 功能獨立
功能獨立有哪些標準 內聚性 耦合性 系統設計 :: 八大概念 :: 功能獨立
內聚性的含義 內聚性強，說明單個功能都被放入單一模塊中 內聚性若，說明單個功能被切分為多個模塊 它說明了單個模塊功能的強弱 系統設計 :: 八大概念 :: 功能獨立
耦合性的含義 耦合性越強，單個模塊對其他模塊依賴度越高 耦合性越弱，單個模塊對其他模塊依賴度越低 耦合性體現了模塊間的相互依賴程度 系統設計 :: 八大概念 :: 功能獨立
耦合性與內聚性的關系是怎樣的 負相關， 耦合性越高，內聚性越低。 耦合性越低，內聚性越高。 系統設計 :: 八大概念 :: 功能獨立
一個功能獨立的模塊應該是怎樣的，請用定性衡量標準說明 高內聚低耦合 系統設計 :: 八大概念 :: 功能獨立
細化 同義詞 精化 同義詞 系統設計 :: 八大概念
精化的概念 逐漸求精的過程 系統設計 :: 八大概念 不斷細化，細節分層。
精化與抽象的關系 兩者是互補的。 精化是不斷對細節進行分解，能揭示底層細節。 抽象是對細節進行隱藏，隱藏了底層細節。 系統設計 :: 八大概念
重構的概念 不改變組件功能的前提下，重新設計代碼，使其代碼簡化更為高效。 系統設計 :: 八大概念 重寫模塊，重寫代碼
重構的方法 檢查現有的冗余情況： 未使用的元素、無效元素、低效算法、不當的數據結構… 系統設計 :: 八大概念 :: 重構
數據設計中對什么內容進行了高層次的抽象 用戶/客戶的數據視圖 系統設計 :: 四個方面 數據設計 設計的是數據，數據是來自于客戶的，所以要抽象也是對客戶的數據進行抽象，而抽象后的展示方式就是使用數據視圖。
數據設計的含義 構建 高層抽象 數據模型/信息模型 的過程和方法。 系統設計 :: 四個方面
體系結構設計的含義（設計內容3點和設計方法） 設計內容： 1、各個模塊干什么 2、模塊間的連接 3、整體對模塊的約束 設計方法： 通過已知的需求分析的建模，對系統分析，以理解系統的特性。 系統設計 :: 四個方面 通過已知的來自于需求分析建模的數據進行分析。 設計內容： 1、設計各個組件，如數據模塊、計算模塊（設計各個具體的組件） 2、設計各個組件之間通信、協同的連接方式（設計組件之間的關系） 3、設計各個組件構成系統的約束條件（設計組件對整體系統的關系） 設計方法： 對系統進行分析，理解系統的特性
數據中心架構是什么樣的 以數據庫為中心，其他的軟件都以它為中心交換數據 系統設計 :: 四個方面 :: 體系結構設計 :: 體系結構設計的簡要分類
數據流體系架構是怎樣的 批處理系列，處理文字數據，就像電路通過各個組件一樣 系統設計 :: 四個方面 :: 體系結構設計 :: 體系結構設計的簡要分類 :: 數據流體系架構
調用和返回架構是怎樣的 就像編程里用的嵌套模式，從上層不斷地調用底層的數據或功能 系統設計 :: 四個方面 :: 體系結構設計 :: 體系結構設計的簡要分類 :: 調用和返回架構
面向對象架構是怎樣的 以對象為單位，說明每個對象內部的數據和功能，并描述對象之間的關系 系統設計 :: 四個方面 :: 體系結構設計 :: 體系結構設計的簡要分類
層次架構是怎樣的 系統設計 就像OS系統一樣，有一個個層級 系統設計 :: 四個方面 :: 體系結構設計 :: 體系結構設計的簡要分類
概念數據模型大概是怎樣的 描述的不是具體的數據組織方式，而是抽象的相互之間的數據的關系 系統設計 :: 四個方面 :: 數據設計 :: 概念數據模型
物理數據模型大概是怎樣的 用具體化的方式描述了具體定量的數量關系 系統設計 :: 四個方面 :: 數據設計 :: 物理數據模型
瀑布、螺旋、噴泉分別是什么驅動的 瀑布：文檔驅動 螺旋：風險驅動 噴泉：對象驅動
主流的幾種過程模型中哪些是模塊化模型，哪些是改來改去模型 模塊化：增量、RAD 改來改去：原型、螺旋、噴泉、敏捷
哪些模型要求的人力多，哪些模型要求的人力少 整體人力多：噴泉、RAD 初期人力少：RAD
哪個模型碼農要求高 螺旋、敏捷
各個主流模型對需求變化的應付情況 難以應付：瀑布、增量、RAD、噴泉 易于應付：原型、螺旋、敏捷
哪些模型進入市場早/見客戶早，哪些晚 早：增量、原型、螺旋 晚：瀑布、RAD、噴泉
哪種過程適合大型軟件 螺旋
模塊化過程（增量那種直接寫的）的缺點 需具備開放性 劃分困難
改來改去模型的優點 早點給用戶看 適應需求變化
改來改去模型的缺點 只去整體性 → 質量差 難以維護 改的太多 → 時間、成本高
改來改去模型都是先完成什么部分 最核心最主要的部分
軟件過程模型優缺點的答題思路是什么 1、先看是否是 模塊化 或 改來改去 的過程模型 如果是搬模板 2、答驅動方式：文檔、風險、對象… 3、需求變化、風險、技術成熟、管理程度…
質量保證需要做到哪幾個“一致” 表明軟件是否與下列一致： 1、與給定需求一致 2、與隱藏需求一致 3、與指定開發標準一致
質量保證/軟件質量測量的基礎是什么 軟件需求
軟件需求與軟件功能不一致{{c1::}}軟件質量問題 等同于 不等同于 缺乏一致性等同于缺乏軟件質量
軟件質量保證的概念 通過系統性的監測和評估工程， 以最大限度地提高實現質量的最低標準
質量保證的原則 1、達到預期 2、淘汰錯誤 質量保證 一次成功的意思應該是軟件交付之后按理來說就沒有錯誤了。 1、適合用途：產品應達到預期 2、一次成功：淘汰掉錯誤
SQA 中文 軟件質量保證 英文縮寫 質量保證 Software Quality Assurance
SQA的概念 通過監視、評估工程 以確保軟件的質量。 質量保證 軟件質量保證的概念：通過監視、評估等方法，系統性地提升軟件的最低質量。
系統設計 → {{c1::}} → 軟件維護 都不對 質量保證 可行性研究 需求分析 質量保證涵蓋了軟件生命周期中的整個過程，這里應該填“軟件測試”
軟件測試的定義 兩個過程，由具體到抽象 過程一：（具體） 在特定條件下，對系統或組件進行操作， 觀察其結果，并對其某方面進行評估。 過程二：（抽象深化） 分析現有結果與應有結果的差異，并進行評估特征。
軟件缺陷的含義 對系統或組件來說輸出的現有結果與應有結果有差異 質量保證 :: 軟件測試 多了功能 少了功能 少了隱藏功能 錯誤 覺得不好用，用戶會覺得不好
軟件缺陷有哪些 功能與產品說明書不一致： 1、多實現了產品說明書的功能 2、少實現了產品說明書的功能 3、未實現產品說明書的隱含功能 4、軟件出現了錯誤 5、軟件難以理解、不易使用、性能差 → 測試人員覺得不好 → 用戶會認為不好 跟女人一樣，要按照她的想法去做，多了一點不行，少了一點也不行，還要滿足她沒有說的需求。 錯誤當然是不能容忍的，而且覺得質量不好，不能理解的東西她也覺得不好。
驗證和確認的區別 驗證(Verification)：過程是否正確 確認(Validation)：結果是否正確 質量保證 結果只能確認，確認結果就很順口，而驗證結果就不常用。驗證的是過程。
軟件測試與質量保證的區別 1、軟件測試是質量保證的主要方法。 2、軟件測試在程序編寫完成后進行， 質量保證貫穿了產品生命周期的全過程。 3、軟件測試是為了找出軟件的缺陷并確保修復， 質量保證是有一套完整科學成體系的方法。 質量保證 軟件測試是質量保證的主要方法，質量保證是一套完整成體系的方法論。 軟件測試：找出軟件缺陷，并確保修復 質量保證：執行軟件開發過程，并防止軟件缺陷， 需遵循一套完整的標準和方法。
軟件測試的基本原則 測試不了的部分：1、無法窮盡測試（測試不完） 2、潛在缺陷無法測出 時間： 3、盡早測試 事物本身特點： 4、軟件缺陷有聚集性 5、避免“殺蟲劑”現象 對于人： 6、使用獨立的測試團隊，而不是讓開發團隊測試 質量保證
測試用例的概念 內容：一組數據的集合， 包含了 輸入、條件、預期輸出 目的：為了驗證程序正確性，找出軟件缺陷而開發的 質量保證
測試策略V模型的過程 左右兩邊一一對應，一一測試驗證。
軟件測試V模型把測試分為了哪些過程 單元測試 集成測試 系統測試 驗收測試 質量保證
軟件測試V模型的四個測試步驟分別的含義是什么 單元測試：測試模塊內部，驗證軟件模塊是否按詳細設計的規格說明運行 集成測試：測試模塊之間，驗證軟件模塊間是否按概要設計說明運行 系統測試：測試整個系統，驗證整個系統是否按照概要設計說明運行 驗收測試：檢測是否符合合同定義，滿足用戶功能和業務 軟件質量保證 :: 軟件測試
子系統測試的同義詞 集成測試 質量保證 :: 軟件測試
樁模塊的概念 替換了被測模塊原有的子模塊，因為不需要使用原子模塊的全部功能。 質量保證 :: 軟件測試
驅動模塊的概念 代替被測模塊的主程序，用來輸入和輸出數據 質量保證
簡要描述單元測試，待測模塊與周圍模塊關系是怎樣的 被測模塊的子模塊被替換成樁模塊，用于減少原子模塊中不必要的功能。 被測模塊的主模塊被替換成驅動模塊，用于傳遞輸入輸出數據 質量保證
集成測試有哪些方法 1、自頂向下集成 2、自底向上集成 3、SMOKE方法 質量保證 :: 軟件測試
自頂向下集成測試方法分為哪幾種 廣度優先方法、深度優先方法 質量保證 :: 軟件測試
簡述自頂向下和自底向上集成測試方法的過程 自頂向上：按照從上至下或從下至上的方法逐漸集成新模塊到系統中進行測試
自頂向下和自底向上集成測試方法分別的缺點是什么 自頂向下：需要開發大量樁模塊 自底向上：每個模塊都要開發驅動模塊 質量保證 :: 軟件測試 :: 集成測試
實際工作中常使用{{c1::}}的集成測試方式 兩種相結合 自頂向下 自底向上
簡述SMOKE方法 設計一系列測試以暴露待測試構造（build）的錯誤，將此構造與其他構造進行集成進行測試。 質量保證 :: 軟件測試 :: 集成測試
SMOCK方法的測試單位是什么 構造（Build） 質量保證 :: 軟件測試 :: 集成測試
系統測試的主要內容有哪些 1、功能測試 2、性能測試 3、強度/壓力測試 4、恢復測試 5、安全測試 質量保證 :: 軟件測試 :: 系統測試 自頂向下 自底向上 冒煙 這些是集成測試，畢竟是一塊塊把它們都拼到一起的測試。而系統測試則是把它們都看做一個整體來測試系統的功能性能。 功能測試是要看軟件在實際的工作環境中表現如何。這當然首先要符合需求說明書的功能，然后性能要好。還要要求在現實情況中遭遇各種問題：強度、掉電、是否安全。
軟件性能體現在什么地方 性能測試 響應時間、緩存區占用量、處理精度等 質量保證 :: 軟件測試 :: 系統測試 :: 性能測試
功能測試的含義 系統測試 檢查軟件是否符合軟件需求規格說明書的功能，以驗證其錯誤 質量保證 :: 軟件測試 :: 系統測試 :: 功能測試
壓力測試的概念 系統測試 測試運行環境有問題時系統的運行情況， 如調高輸入數據速率，設計占用大量內存資源的測試用例 質量保證 :: 軟件測試 :: 系統測試 :: 壓力測試
恢復測試的含義 系統測試 測試硬件產生故障系統能否正常工作 質量保證 :: 軟件測試 :: 系統測試 :: 恢復測試
如何進行恢復測試 系統測試 模擬硬件故障，如掉電測試。 質量保證 :: 軟件測試 :: 系統測試 :: 恢復測試
驗收測試是以什么人為主的 用戶 質量保證 :: 軟件測試
α測試和β測試分別是什么 α測試：用戶在開發環境下進行測試 β測試：用戶在實際環境下進行測試 質量保證 :: 軟件測試 :: 驗收測試
α測試和β測試分別在什么地方測試 α測試：在開發環境下測試，開發者場所 β測試：在用戶場所進行 質量保證 :: 軟件測試 :: 驗收測試
α測試和β測試開發者的在場情況如何 α測試：開發者在場 β測試：開發者不在場 質量保證 :: 軟件測試 :: 驗收測試
α測試和β測試是否可以同時進行 不可以，只有當α測試足夠可靠后才能進行β測試。 質量保證 :: 軟件測試 :: 驗收測試
回歸測試的概念 軟件部分修改后， 對整個系統或某個部分進行再測試， 這樣的再測試是有選擇的， 目的是驗證修改后的部分不會有錯誤影響。 質量保證 :: 軟件測試 :: 回歸測試
回歸測試在什么時候進行 在軟件測試的各個階段，軟件產生變化的部分需要進行再測試。
回歸測試的分類 缺陷再測試（因為有錯而更改） 功能改變測試（因為需求→功能變更而更改） 新功能測試 完全回歸測試（測試整個系統） 質量保證 :: 軟件測試 :: 回歸測試 錯誤而更改、需求→功能而更改、新增、整體
回歸測試應采用{{c1::自動化測試}}（一個詞）（什么方法） 質量保證 :: 軟件測試 :: 回歸測試
軟件質量保證的主要方法是什么 軟件測試 質量保證
軟件測試占總成本大概多少 40%以上 每個部分都自賣自夸，搞硬件的說自己吃香，搞軟件的說軟件需求越來越大，軟件維護的說自己占用成本最高，這里又來一個說軟件測試占總成本40%以上，那你的意思是軟件開發、需求分析、系統設計之類的只占總成本不到10%.吹牛吧你。
質量與可靠性有哪些衡量標準 質量保證 功能性：是否滿足響應功能 可靠性：平均無故障的時間 可維護性：平均修復時間 可用性：可靠性+可維護性 效率：軟件運行得快不快 可移植性：跨平臺、跨硬件移植 關于正常用：功能性、效率 關于故障：可靠性、可維護性、可用性 關于換平臺：可移植性
白盒測試的含義 考慮系統或組件的內部邏輯結構進行的測試
黑盒測試的含義 不考慮系統或組件內部邏輯結構進行的測試
灰盒測試的含義 介于黑盒測試與白盒測試之間的測試，既關注程序的輸入輸出，又關注程序的邏輯性
結構性測試的同義詞 白盒測試
功能性測試的同義詞 黑盒測試
灰盒測試常被用于哪個階段 集成測試階段
邏輯覆蓋屬于{{c1::}}盒測試 白 黑
邏輯覆蓋有哪幾種分類 語句覆蓋 分支覆蓋 條件覆蓋 條件組合覆蓋 質量保證 :: 軟件測試 :: 白盒測試 :: 邏輯覆蓋
語句覆蓋的含義 設計若干個測試用例，使得每條語句都能至少被測試一次 質量保證 :: 軟件測試 :: 白盒測試 :: 邏輯覆蓋
分支覆蓋的含義 設計用例，使每個判斷的每個分支至少測試一次。 質量保證 :: 軟件測試 :: 白盒測試 :: 邏輯覆蓋
判定覆蓋 的同義詞 分支覆蓋 質量保證 :: 軟件測試 :: 白盒測試 :: 邏輯覆蓋 :: 分支覆蓋
條件覆蓋的含義 設計測試用例，使得每個條件的取值至少被測試一次。 質量保證 :: 軟件測試 :: 白盒測試 :: 邏輯覆蓋
條件組合覆蓋的含義 設計足夠多的測試用例，使得每個判斷組合都至少執行一次 質量保證 :: 軟件測試 :: 白盒測試 :: 邏輯覆蓋
控制流圖 英文縮寫 CFD 中文名 Control Flow Diagram
程序圖 的同義詞 控制流圖
流圖的同義詞 控制流圖
控制流圖長什么樣
控制流圖覆蓋測試屬于{{c1::}}盒測試 白 黑 灰 質量保證 :: 軟件測試 :: 白盒測試
控制流圖覆蓋測試 與 邏輯覆蓋 的具體分類中的對應關系 語句覆蓋-節點覆蓋 分支覆蓋-邊覆蓋 條件覆蓋-路徑覆蓋 質量保證 :: 軟件測試 :: 白盒測試 :: 控制流圖覆蓋測試
黑盒測試的分類 等價類劃分、邊界值分析、狀態測試 質量保證 :: 軟件測試 :: 黑盒測試
簡述等價類劃分的大致方法 把所有可能的輸入數據劃分為若干部分，從每一部分中選取少數具有代表性的數據作為測試用例 質量保證 :: 軟件測試 :: 黑盒測試 :: 等價類劃分
等價類的劃分分哪些步驟 1、列出等價類表 2、選取測試用例 質量保證 :: 軟件測試 :: 黑盒測試 :: 等價類劃分
等價類是什么 是一個集合，在這個集合中各個輸入對于揭示程序的錯誤都是等效的。 質量保證 :: 軟件測試 :: 黑盒測試 :: 等價類劃分
等價類有哪兩種情況 有效等價類：對程序合理的輸入集合 無效等價類：對程序不合理的輸入集合 質量保證 :: 軟件測試 :: 黑盒測試 :: 等價類劃分
設計黑盒測試用例時，采用等價類劃分的方法，應使用{{c1::}} 其他 有效等價類 無效等價類 設計測試用例時要同時考慮有效等價類和無效等價類
等價類劃分的原則有哪些 1、給出范圍 可以劃分（連續型） 2、給出輸入集合 可以劃分（離散型） 3、輸入為bool量 可以劃分（布爾型） 4、每個輸入處理都不同，則對于每個輸入都可以劃分（case1,2,3） 5、給定規則，是否合規，可以劃分 質量保證 :: 軟件測試 :: 黑盒測試 :: 等價類劃分 1、若給出了輸入的取值范圍，則可以劃分有效和無效等價類。（連續型） 2、規定了輸入值的集合，可以劃分一個有效和無效等價類。（離散型） 3、輸入條件為布爾量，可以劃分一個有效等價類和無效等價類。（布爾型） 4、給出輸入的一組值，其中每個值都要分別處理， 則對于每個值，都可以劃分有效等價類和無效等價類。（case1,2,3） 5、規定了一個條件規則，則可以劃分…（是否符合規則）
靜態分析方法是什么 不運行程序，檢查和閱讀代碼、文檔、手冊來發現問題 軟件測試 空談誤國型
靜態分析的分類 1、同事審查，用于初次審查，要求最低 2、走查：開發組內部進行 3、審查：開發組、測試組合相關人員開會 軟件測試
伙伴審查 的同義詞 軟件測試 同事審查
靜態分析類型中要求最低的審查方式是哪一種 同事審查 軟件測試
靜態分析類型中初次審查是在什么人之間進行 同事審查，在同事之間進行 軟件測試
邊界值分析方法是什么 是一種黑盒測試方法，是對等價類劃分測試的補充。 因為軟件大量測試出現在邊界上 軟件測試 :: 黑盒測試
軟件維護的概念（原因+動作+目的） 原因：軟件出現問題需要改進 動作：對代碼及文檔進行修改 目的：修改軟件的同時保持軟件的完整性 軟件維護
軟件維護的基本類型有哪些 糾錯性維護：為了改錯 適應性維護：適應外部條件，如OS或硬件架構變化 完善性維護：增加新功能，如OneNote不斷完善 預防性維護：采用先進方法重新設計、編碼、測試 Adobe有PS只能在Windows上面跑，但是x86的復雜指令集架構太老舊了，時代浪潮滾滾向前，需要用ARM架構，于是我們進行適應性維護。（可以這么理解，但實際上并不是的）
軟件維護的基本類型中，占比最小和最大分別是什么 占比最大：完善性維護 占比最小：預防性維護
正確性維護 的同義詞 糾錯性維護 軟件維護
完善性維護占比大概占維護成本的多少 50% 軟件維護 :: 完善性維護
軟件維護的成本大概占總成本的多少 80% 這騙人
可維護性的因素主要分為哪些大的方面 主要因素（抽象） 環境因素（具體） 軟件維護
可維護性的主要因素（抽象）有哪些 1、可理解性 2、可移植性 3、可重用性 4、可測試性 5、可修改性 軟件維護 與軟件的質量相比很多都相同，但是增加了可測試性、可修改性，沒有了性能、功能性。
可維護性的環境因素（具體）有哪些 1、軟件維護的文檔 2、軟件的運行環境 3、軟件的維護組織 4、軟件維護的質量（這不廢話嗎） 軟件維護 對應了“軟件維護為什么困難”這個問題。
軟件維護的困難性有哪些 1、管理不到位（管理） 2、人員變動（人） 3、軟件可讀性差（文檔） 4、時間緊（時間） 軟件維護 軟件功能的的困難可以用各個階段進行論述，而軟件維護的困難可以從 管理+人+文檔+時間 四方面來論述。
軟件維護的過程模型大概長什么樣子 1、分類鑒別（尋找大方向） 2、分析（代替了需求分析） 3、設計（類似于系統設計） 4、編碼實現 5、測試 6、驗收 7、交付 是一個微縮版的軟件過程模型
軟件再工程是什么 對現有軟件進行重新改造， 使之形成新的軟件，新的形式 軟件維護
軟件逆向工程的概念 正向工程是從概念設計到代碼， 而逆向工程是從代碼模塊分析出模塊間的關系，獲知抽象概念。 然后通過某種形式來展現這個系統。 軟件維護
項目管理的四要素 4P： People人員 Product產品 Process過程 Project項目 項目管理
軟件項目管理的定義 （IEEE） 計劃、協調、度量、監控、控制等 一些列方法應用到軟件開發維護中， 以保證過程具有系統性、可量化、有原則。 項目管理
PCMM 中文名 人力資源管理成熟度模型 英文縮寫 項目管理 People Capability Maturity Model
軟件度量的定義 一種量化衡量的方法，使得人們可以把握軟件項目生產效率 項目管理
軟件獨立的目的是什么 描述（項目和過程） 評估（狀態和質量） 預測（為計劃） 改進（產品質量和產品性能） 項目管理
項目中的三駕馬車是什么 項目負責人Project Manager 只能部門負責人Manager in Department 項目成員Project Members 項目管理
軟件度量的分類 面向規模度量 面向功能度量 項目管理
軟件的特征有哪些 胡磊式抱怨： 1、軟件開發進度、時間、工作量、成本難以衡量（可延伸） 2、軟件維護非常困難，維護易產生新問題 客觀問題： 1、不會磨損和老化，但是會退化和廢棄 2、軟件是開發或者工程化的，不是制造的 概述
軟件的雙重作用是什么 1、一方面是一種產品 2、另一方面是開發軟件的工具 概述 就像人，一方面是個人，另外一方面可以造人。
按照軟件的功能來劃分，軟件可以分為哪幾類 1、系統軟件 2、支撐軟件（獨有，奇葩） 3、應用軟件 在這本書里軟件有很多種劃分方法，有七大類軟件，我也不知道為什么這么劃分。還有操作系統的劃分方法，各種計算機的書劃分方法都不一樣。這里就記它這種吧。
軟件工程的目標 在給定時間、預算內， 按照用戶的要求， 開發 易修改、高效、可靠、可維護、適應力強、可移動、可重用（常規套話） 的軟件 概述
稱贊軟件好的詞有哪些 可靠性、可維護、可用性好 功能性 可移植、移植性好 可讀性好、可理解 易修改、易維護、易測試 性能好、高效
基于構件的過程模型與常規過程模型有什么不同 1、分析步驟：新增組件分析，看哪些組件可以用，哪些組件需要改 2、系統設計步驟：需要考慮組件的重用 3、代碼實現：有組件的話一些代碼就不用直接寫了，要把組件集成進軟件中 軟件過程
基于構件的過程模型的缺點（4點） 1、模型復雜 2、需求的折衷，不一定完全符合要求 3、無法完全控制開發系統的演化過程 4、項目、模塊劃分困難 軟件過程
簡述基于構件的軟件過程是什么玩意兒 不同于RAD和增量模型，基于構件看起來是用的別人寫的模塊， 而增量模型、RAD的模塊是自己寫的 軟件過程 所以有些地方無法自己控制
用例圖在ppt的哪個位置 需求分析
數據流圖在PPT的哪個位置 需求分析
PPT中需求分析部分主要講了哪些圖 數據流圖、用例圖
分解設計是什么 把軟件分解為各個組件的設計 系統設計
頁面設計的重要原則 1、用戶為中心 2、減少用戶記憶負擔 3、保持界面一致 系統設計
體系結構組織和細化的兩個基本問題是什么 控制問題和數據問題 1、組織→控制結構問題 架構內如何實現控制管理 是否有多種控制架構 2、細化→數據傳遞問題 組件間如何進行數據傳遞 數據流是連續傳遞還是間斷傳遞的 系統設計
內聚強弱的排序 功能內聚 > 順序內聚 > 通信內聚 > 過程內聚 > 時間內聚 > 邏輯內聚 > 偶然內聚 系統設計 時間內聚與順序內聚含義相似
偶然內聚的含義 沒有什么關系，只為了節省內存就放進了一個模塊內 系統設計 :: 八大概念 :: 內聚
邏輯內聚的概念 把任務邏輯相同相似的放在一塊 系統設計 :: 八大概念 :: 內聚
時間內聚的概念 把同一個階段的任務放在同一個模塊里 系統設計 :: 八大概念 :: 內聚
低內聚的分類 時間內聚 > 邏輯內聚 > 偶然內聚 系統設計 :: 八大概念 :: 內聚
過程內聚的含義 模塊內的元素按照一定的執行順序， 使用程序流程圖一般能得到過程內聚的模塊 系統設計 :: 八大概念 :: 內聚
通信內聚的含義 模塊內各個元素有相同輸入或輸出 系統設計 :: 八大概念 :: 內聚
中內聚的分類 內聚 通信內聚 > 過程內聚 系統設計 :: 八大概念 :: 內聚
順序內聚的含義 1、模塊內運輸與一個功能緊密相關 2、元素處理順序執行 系統設計 :: 八大概念 :: 內聚 這很像時間內聚啊
功能內聚的概念 1、模塊處理元素屬于一個整體 2、完成單一功能 系統設計 :: 八大概念 :: 內聚
高內聚的分類 功能內聚 > 順序內聚 系統設計 :: 八大概念 :: 內聚
系統結構圖長什么樣 系統設計
系統結構圖中的模塊分為哪幾種 傳入模塊 傳出模塊 變換模塊 協調模塊 系統設計
系統結構圖中各個模塊傳遞的數據流分別叫什么名字 傳入模塊：邏輯輸入數據流 傳出模塊：邏輯輸出數據流 變換模塊：變換數據流 協調模塊：（沒說） 系統設計 :: 系統結構圖
結構化的總體設計的方法步驟 1、分析數據流圖，通過軟件需求規格說明書弄清楚數據加工過程。（來源：需求分析的說明書） 2、確定問題類型，將其分為變換型和事務性。（分類，確定大方向） 3、推導出初始系統結構圖（草圖） 4、不斷改進系統結構圖（不斷修改） 5、修改補充數據詞典 系統設計 事物型和變換型結構圖的畫法流程都是一樣的，總體而言都是這么做的。
系統結構圖的分類 變換型系統結構圖 事務型系統結構圖 系統設計
變換型系統結構圖中的過程分為哪些步驟 1、取得數據-數據輸入 2、變換數據-中心變換 3、給出數據-數據輸出 系統設計 :: 系統結構圖 :: 變換型系統結構圖
簡述事務型系統結構圖 根據輸入的特點，選擇一個處理單元進行處理， 每個事務處理單元可能會調用若干個操作模塊以及下層的細節模塊進行處理。 系統設計 :: 系統結構圖 :: 事務型系統結構圖
簡述 事務型系統結構圖 和 變換型系統結構圖 的區別 事務型系統結構圖是分類后選定某一個模塊進行變換， 而變換型系統結構圖是直接對輸入數據進行變換。 系統設計 :: 系統結構圖
對于兩種系統結構圖，實際操作中常使用{{c1::}} 兩種混合 變換型系統結構圖 變換型系統結構圖 系統設計 :: 系統結構圖
常使用以{{c1::變換分析}}為主，{{c1::事務分析}}為輔的方式進行軟件結構設計 系統設計 :: 系統結構圖
變換分析是什么 是一系列設計方法的總稱， 目的是把數據流圖轉化為軟件結構 系統設計 :: 面向數據流設計 軟件結構？或者說是轉化為系統結構圖？ 變換分析和事務分析都是軟件設計的方法，他們都是將數據流圖轉化為系統結構圖。
變換分析是將什么圖轉換為什么圖？ 將 數據流圖（需求分析階段） 轉換為 變換型系統結構圖（系統設計階段） 系統設計 :: 面向數據流分析
變換分析分為哪些步驟 1、重新畫數據流圖 2、將數據流圖分為輸入、輸出、中心變換三部分 3、進行一級分解，將數據流圖分解出的三部分轉換為系統結構圖 4、進一步分解，細化每個板塊。 系統設計 :: 面向數據流分析 :: 變換分析
變換分析的注意事項有哪些 1、完成本模塊所有的下屬模塊后才能轉向下個模塊的設計（設計順序） 2、需考慮模塊的耦合與內聚（模塊性質） 3、黑箱技術 4、模塊劃分時，模塊的下屬模塊不宜過多（模塊劃分） 5、遇到某些情況需要停止模塊分解（停止條件） 系統設計 :: 面向數據流分析 :: 變換分析 設計的順序，模塊的性質是怎樣的，黑箱，劃分的規則，停止條件
模塊劃分時，一個模塊的下屬模塊一般是幾個左右 變換分析 5個 系統設計 :: 面向數據流分析 :: 變換分析
什么是 “黑箱”技術 變換分析 設計當前模塊時，不需要考慮其下屬模塊的內部結構和實現方式， 只需要定義其為“黑箱”，而在下一步繼續設計加工。 系統設計 :: 面向數據流分析 :: 變換分析
什么情況下停止模塊分解 變換分析 1、不能細分為明顯的子任務 2、分解成了所提供的模塊或程序庫的子程序 3、模塊過小 4、模塊的輸入、輸出是系統輸入輸出的信息 系統設計 :: 面向數據流分析 :: 變換分析
正確寫法：{{c1::}} 事務型系統結構圖 事物型系統結構圖 系統設計 :: 面向數據流分析
事務的含義 面向數據流分析 是一種數據流，這種數據流可以引發一個或多種處理模塊 系統設計 :: 面向數據流分析 :: 事務分析
事務分析的大致過程 面向數據流設計 1、根據數據流圖進行分解 2、建立第一級事務性系統結構圖 3、不斷優化形成更加細分的結構圖 系統設計 :: 面向數據流分析 :: 事務分析 大致過程，模糊化處理
簡述這幾個數據流圖的主要圖形是干什么的 數據流圖
數據流圖有哪幾種基本成分 數據流圖
兩個加工之間只能有一條數據流{{c1::}} 數據流圖 錯 對 兩個加工之間可以有多個數據流
數據流命名的兩個原則 數據流圖 1、不用使用意義空洞的名詞 2、使用現實系統中已有的名字
數據流圖中需要畫控制流嗎{{c1::}} 不能畫 必須畫 可以畫 控制流不能畫在數據流圖中
激發條件需要畫在數據流圖中嗎{{c1::}} 不能畫 必須畫 可以畫 不要在數據流圖中標出激發條件
加工的概念 數據流圖 表示對數據的操作 模糊化
加工的編號是干嘛的 數據流圖 說明該加工在層次分解中的位置
加工的命名要怎么弄 數據流圖 1、不要用空洞的名字 2、要選用有意義，存在已有的名字
什么數據流不必命名 數據流圖 流向數據存儲或從數據存儲中流出的數據流不用命名
外部實體的概念 數據流圖 在系統之外的東西叫外部實體
對于加工來說輸入輸出是不是必須的{{c1::}} 數據流圖 輸入輸出都是必須的 輸入是必須的 輸出是必須的 輸入輸出都不是必須的 每個加工至少得有一個數據輸入流和一個數據輸出流
數據是否可以不經過加工而直接在數據源、數據終點、數據存儲之間流動{{c1::}} 數據流圖 不可以 可以，但必須經過數據存儲 可以，但是必須要有控制流
DFD與程序流程圖在數據和控制方面的區別 DFD不表示程序的控制結構，只描述數據的流動。
數據流圖，用例圖，類圖，程序流程圖中哪一個有父圖子圖，要分層來畫{{c1::}} 數據流圖 用例圖 類圖 程序流程圖 DFD分層多層。
描述畫DFD的過程 1、畫頂層 2、畫下面的層次 3、先考慮開始和結束，暫時忽略系統過程 4、抓住主干，暫時忽略細節 5、隨時準備重畫 DFD是先暫時忽略過程，而用例圖是暫時畫整體的，后期再逐步細化。
畫分層DFD的指導原則是什么（四條） 1、父圖-子圖平衡 2、局部數據存儲 3、編號 4、分解的程度
父圖-子圖平衡的概念 數據流圖 父圖輸入輸出數據流 = 子圖輸入輸出數據流
局部數據儲存的概念 數據流圖 加工不能從某個地方來，又回那個地方去。 只有等到某個層級加工可以從一個地方來，又到另一個地方去的時候才應該畫出來。
加工的編號依據什么原則 數據流圖 1、頂圖不編號 2、子圖的圖號為父圖加工號（加工是一個數據流圖中的專有名詞） 3、同等級的子圖以最后的數字序號為區別
分解一般分解為大約多少層 數據流圖 4±1層
各層各張數據流圖的加工數據大概是多少 數據流圖 7±2
DFD的改進手段有哪三點 1、檢查正確性 2、提高易理解性/可讀性 3、重新分解
可以從哪三個角度檢查DFD的正確性 1、數據是否守恒/一致 2、數據存儲使用正確 3、父圖、子圖是否平衡
數據不守恒情況的分類有哪兩種 數據流圖 1、有相應的數據輸入，但是輸出沒有用到 2、輸出用到了某個數據，但這個數據沒有輸入 數據流圖 :: 檢查正確性
關于數據存儲使用的判斷 數據流圖 :: 檢查正確性 檢查只有流入沒有流出的數據存儲 或只有流出沒有流入只有流出的數據存儲 數據流圖 :: 改進措施 :: 檢查正確性 :: 數據存儲的使用
可以通過哪三點提高DFD的易理解性 1、簡化加工之間的聯系 2、均勻分解 3、正確合理地命名 數據流圖 :: 改進
什么叫不均勻的分解 數據流圖 一張圖中某些加工已經不能再分解了， 而另一些加工還可以繼續分解出好幾層。 數據流圖 :: 改進 :: 提高易理解性
命名不當和分解不當有什么關聯{{c1::}} 數據流圖 分解不當 => 命名不當 命名不當 => 分解不當
重新分解的步驟 數據流圖 1、把某張圖的所有子圖框起來 2、把這部分的各個子圖分為幾個部分， 讓每個部分都聯系緊密，與外界聯系少。 3、把各個部分建立為新的子圖 4、為新的子圖命名和編號 數據流圖 :: 改進 :: 重新分解
UML 中文 統一建模語言 英文縮寫 需求分析 Unified Modeling Language
UML是面向{{c1::}}的 對象 過程
UML的概念 是一個統一的交流標準，包含了概念、術語和圖形符號
UML是用于需求分析的方法論{{c1::}} 錯 對 它只是一種建模語言
舉例系統邊界 用例圖 計算機軟硬件邊界 某個部門 某個組織
為什么要進行系統邊界識別 用例圖 通過識別系統邊界，以明確什么是系統，系統的職責是什么
參與者的概念 用例圖 1、在系統之外 2、需要使用系統或與系統交互 如人，設備，外部系統
參與者有哪三種表示形式 用例圖 1、icon形式：畫一個小人，并注明名字 2、Label形式：畫個框框，并注明名字 3、Decoration形式：框框里畫個小人，并標注名字
所有的數據流都需要命名{{c1::}} 數據流圖 錯 對 最初輸入和最后輸出的數據流不用命名
用例的符號是怎樣的 用例圖 橢圓
簡述系統、參與者、用例三者的關系 用例圖 用例屬于系統，在系統的范圍內。 參與者不屬于系統，在系統的范圍外。 參與者與用例通過“關聯”進行聯系。
用例的獲取方法（通過以下問題討論用例） 用例圖 對于參與者 1、想用系統干什么 2、想訪問什么信息 對于系統 1、需要什么外部信息 2、需要把什么信息告訴參與者 3、如何維護 通過以下問題討論用例： 1、參與者希望系統干什么 2、參與者在系統中訪問/增改什么信息 3、系統需要哪些外部信息 4、需要將系統的什么事情告訴參與者 5、如何維護系統
用例的定義 用例圖 系統與參與者的交互的說明 ，對其進行的文字描述（與上一句同義）， 提供了外部可見功能
用例的目的是{{c1::}} 用例圖 定義系統行為 解釋系統結構 用例的目的是定義系統行為，而不是解釋系統的內部結構。
通過用例做需求分析的特點 用例圖 1、從使用的角度，分析而不考慮內部結構實現方式 2、用例描述了一些用戶需求，用戶目標 3、是對系統行為的動態描述
{{c1::}}屬于UML動態建模部分 用例圖 數據流圖
用例是一個單獨的步驟{{c1::}} 錯 對 把用例當做一個單獨的步驟、操作或事務的處理是一個常見的錯誤
對于飲料販賣機來說，是把飲料販賣機這個硬件作為系統邊界還是把商店或企業組織作為邊界，該根據什么情況來選擇呢 用例圖 開發設備的話就用軟硬件作為系統邊界 從事企業過程就以企業組織為邊界
用例圖中有哪幾種關系 關聯association 泛化generalization 包含include 擴展extend
關聯的含義 用例圖中的關系 參與者與參與執行的用例的通信路徑
泛化的含義 用例圖中的關系 一般和特殊的關系，類似于類的繼承與派生
包含 英文 include 中文 用例圖
擴展 英文 extend 中文 用例圖
包含的含義 用例圖 其中一個用例的范圍包含另一個用例
基本用例是什么 用例圖中的關系 :: 包含 能包含另一個用例的，范圍更大的用例
被包含用例是什么 用例圖中的關系 :: 包含 被另一個用例包含，范圍更小的一個用例
箭頭方向是從{{c1::基本用例（范圍大的）}}指向{{c1::被包含用例（范圍小的）}} 用例圖中的關系 :: 包含
什么時候使用包含用例 用例圖 1、多個用例有相同功能，則將這些功能分解到另一個用例中 2、某個用例功能過多時，用包含關系創建兩個小用例 一個“合”，一個“分”
擴展關系是怎樣的 用例圖 以某個用例作為基礎，只有當這個用例可以執行時，擴展用例才能夠執行
基本用例和擴展用例分別是什么 用例圖中的關系 :: 擴展關系 基本用例：是獨立的，是擴展用例可以操作的基礎 擴展用例：不能獨立執行，只有滿足基本用例后才能執行
箭頭方向的指向是怎樣的 用例圖中的關系 :: 擴展 由擴展用例（非獨立）指向基本用例（獨立，基本點）
包含和擴展關系的區別 用例圖 依賴性不同。 包含關系中兩個用例是獨立的，都可以獨立執行。 擴展關系中如果執行了擴展用例，那一定得執行基本用例。
什么關系的表示 關聯 的圖像表示法是怎樣的 用例圖
表示什么關系 擴展 的圖像表示法 用例圖
表示什么關系 泛化 圖像表示法 用例圖
表示什么關系 包含 圖像表示法 用例圖
用例圖的概念 顯示用例、參與者，以及它們之間關系的圖
UML中，一個用例模型由{{c1::}}用例圖描述 若干個 一個
用例需要描述哪些內容 用例圖 1、用例的目標 2、用例啟動條件（觸發條件） 3、用例與參與者間信息傳遞（傳遞的信息） 4、用例中主路徑與其他路徑（傳遞的路徑） 5、用例結束后系統狀態（結束）
用例規約是什么 對用例的描述
前置條件 的含義 用例 :: 用例描述的主要組成 用例執行前應滿足的條件
后置條件 的概念 用例 :: 用例描述的主要組成 用例執行完畢后可能處于的一組狀態
主事件流的概念 用例 :: 用例描述的主要組成 正常情形，最常用的路徑
用例圖中，如果有被可擴展、包含、泛化的用例 應該怎么做 寫出它們的名稱，并說明使用的情況
用例描述中 用例優先級 的概念 用例 :: 用例描述的主要組成 說明用例的優先級，這代表了用戶對用例的期望值
用例的優先級可以用來干什么 用例 :: 用例描述的主要組成 為今后開發制定優先順序
用例描述的主要組成有哪些 用例圖 1、用例名稱 2、用例說明 3、參與者 4、前置條件 （擴展） 5、后置條件 （擴展） 6、擴展點 （擴展） 7、優先級 （擴展） 8、主事件流 （擴展） 9、其他事件流
用例分析的步驟 用例圖 1、確定 系統的邊界 和 參與者（確定范圍） 2、確定每個參與者的行為，將其命名為用例（確定行為與命名） 3、分解共用公共的系統行為（包含關系） 4、把可以分解為擴展用例的分解為擴展用例（擴展關系） 5、編制用例腳本（畫草圖） 6、畫用例圖 7、將特殊情況的用例畫成子用例圖 8、細化用例圖，解決重復和沖突
用例識別有哪兩種方法 1、基于參與者 2、基于事件 面向對象和面向過程
基于參與者的方法是怎樣的 用例識別 1、識別出于系統有關的參與者 2、對每個參與者 識別出他們參與的過程
基于事件的方法是怎樣的 用例識別 1、識別系統響應的外部事件 2、把事件參與者與用例聯系起來
識別用例有哪些要點 1、是有意義的目標 2、使用業務語言，用戶觀點 3、用例粒度
用例粒度問題是怎樣的 粒度大則用例數少，粒度小則用例數多。 用例粒度無絕對標準。
組件級設計 同義詞 過程設計 同義詞
組件級設計位于哪個時間段 位于數據設計、體系結構設計、接口設計之后 系統設計 :: 面向過程組件設計
結構化構成元素有哪幾種 1、順序 2、條件 3、重復、循環 系統設計 :: 面向過程組件設計
詳細設計工具可以分為哪幾類 圖形設計符號：流程圖、盒圖 表格設計符號：決策表 程序設計符號：PDL 系統設計 :: 面向過程組件設計
流程圖的概念 用各種方塊圖形、線條、箭頭表達解決問題的步驟及順序的圖 系統設計 :: 面向過程組件設計
{{c1::}}是算法的一種表示方式 流程圖 結構圖 數據流圖 用例圖
SOP 中文名 標準作業流程 英文縮寫 Standard operating procedure
SOP是什么 用于企業，讓任何人看到流程圖都一目了然
程序流程圖 與 流程圖的關系 程序流程圖屬于流程圖，但是好像這門課主要講的是程序流程圖 系統設計 :: 面向過程組件設計
制作流程圖的優點有哪些 1、所有流程都很清楚 2、換人時好上手 3、畫流程圖時容易發現錯誤而進行改正 系統設計 :: 面向過程組件設計
流程圖的各個符號表示什么意思 {{c1::}} {{c1::}} 系統設計 :: 面向過程組件設計 :: 流程圖
流程圖有哪幾種基本結構 順序 選擇 循環 系統設計 :: 面向過程組件設計 :: 流程圖 老生常談了
盒圖有哪幾種基本控制結構 順序型 選擇型 WHILE重復型 UNTIL重復型 CASE型 系統設計 :: 面向過程組件設計 :: 盒圖
盒圖的順序性長什么樣子
盒圖的選擇型長什么樣子 系統設計 :: 面向過程組件設計 :: 盒圖
盒圖的WHILE重復型長什么樣子 系統設計 :: 面向過程組件設計 :: 盒圖
盒圖的UNTIL重復型長什么樣子 系統設計 :: 面向過程組件設計 :: 盒圖
盒圖的CASE型長什么樣子 系統設計 :: 面向過程組件設計 :: 盒圖
判定表 同義詞 決策表 同義詞 系統設計 :: 面向過程組件設計
判定表 與 程序流程圖 在 控制結構 分支判斷 部分有什么重大的區別 判定表只能有兩分支的判斷的列表， 而程序流程圖可以有多分支判斷的列表
PDL長什么樣
盒圖長什么樣
面向對象設計活動可以有哪些 系統架構設計 用例設計 類設計 數據庫設計 用戶界面設計 系統設計 :: 面向對象設計
架構設計的輸入和輸出分別是什么 輸入：用例模型、分析模型 輸出：物理結構、子系統、設計類 系統設計 :: 面向對象設計
架構設計分為哪幾個步驟 系統設計 Step1:構造系統物理模型 Step2:設計子系統 Step3:非功能需求設計
構造系統的物理模型的過程 系統設計 1、用UML的xx圖描述其物理結構 2、把需求分析得到的功能分配到具體的物理節點上
系統的物理模型長什么樣子 系統設計 :: 面向對象設計
面向對象設計活動由什么人員進行 架構師 系統設計
設計子系統的步驟 架構設計 Step1:劃分各個子系統 Step2:定義子系統間的關系 Step3:定義子系統的接口 系統設計 :: 面向對象設計 :: 架構設計
通過哪些依據來劃分子系統 架構設計 1、按照功能 2、按照物理布局 3、按照軟件層次 系統設計 :: 面向對象設計 :: 架構設計
按照軟件層次劃分子系統大概是什么樣子的 架構設計 系統設計 :: 面向對象設計 :: 架構設計
子系統之間可以有些什么關系 架構設計 請求-服務關系：單向調用的關系 平等關系：雙向調用關系 系統設計 :: 面向對象設計 :: 架構設計
解決子系統之間關系過于密切的方法有哪些 架構設計 1、重新劃分子系統 2、重新定義子系統接口，將依賴關系定義在接口上 系統設計 :: 面向對象設計 :: 架構設計
非功能需求設計是什么 架構設計 可移植性、軟件通用性、安全性 這些不是用戶提出來的對用戶有直接用處的部分 系統設計 :: 面向對象設計 :: 架構設計
什么是類 包含信息（數據） 和信息行為（函數）
類間關系有哪些 關聯關系 聚合關系 組合關系 依賴關系 泛化關系 系統設計 :: 面向對象設計
分析類圖和設計類圖大概長什么樣 系統設計 :: 面向對象設計
類的設計講了哪幾種類，說出他們分別的含義 實體類：業務實體，用于存儲信息 邊界類：用例、參與者之間若有交互，應建立邊界類 控制類：控制協調對象 系統設計 :: 面向對象設計
細化用例的步驟 Step1:找出所有類 Step2:添加各種類的類型 Step3:添加類的關系 系統設計 :: 面向對象設計 :: 細化用例
詳細設計一個類由什么人完成 構架工程師
類設計有哪些步驟 Step1:定義類的屬性 Step2:定義類的操作 Step3:定義類間關系 系統設計 :: 面向對象設計 :: 類設計

總結

以上是生活随笔為你收集整理的【成电860考研】《软件工程》-anki卡片知识合集-504张卡片-28000字-上岸资料整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。