誰能告訴我這科的理論在哪可以實用呀？搞不懂，只能收藏一下包不掛科

知識點總結

第一章：

軟體工程定義：

1968年10月，Fritz Bauer 首次提出了“軟體工程”的概念，并將“軟體工程”定義為：為了經濟地獲得能夠在實際機器上有效運行的可靠軟體，而建立并使用的一系列工程化原則，

1993年IEEE對軟體工程的定義：軟體工程是將系統化的、規范化的、可度量的途徑應用于軟體的開發、運行和維護的程序，即將工程化應用于軟體的方法的研究，

軟體工程原則：

抽象與自頂向下，逐層細化 資訊隱蔽和資料封裝 模塊化 區域化 確定性 一致性和標準化 完備性和可驗證性

瀑布模型：

開發活動的特征：（1）以上一項活動方產生的作業物件為輸入(2)利用這一輸入,實施本項活動應完成的內容(3)給出該項活動的作業結果,作為輸出傳給下一項活動(4)對實施該項活動的作業結果進行評審,若其作業得到確認,則繼續進行下一項活動,否則回傳前項,甚至更前項的活動進行返工

瀑布模型的優點:

(1)可強迫開發人員采用規范化的方法

(2)嚴格地規定了每個階段必須提交的檔案

瀑布模型的缺點

(1)由于瀑布模型幾乎完全依賴于書面的規格說明,很可能導致最終開發出的軟體產品不能真正滿足用戶的需要，如果需求規格說明與用戶需求之間有差異,就會發生這種情況(2)瀑布模型只適用于專案開始時需求已確定的情況，總地來說,瀑布模型是一種應付需求變化能力較弱的開發模型,因此,很多在該模型基礎上開發出來的軟體產品不能夠真正滿足用戶需求

第二章：

可行性研究的程序：

1. 復查系統規模和目標

復查系統定義，改正含糊或不確切的敘述，清晰地描述對目標系統的一切限制和約束

1. 研究目前正在使用的系統

現有的系統是資訊的重要來源，若一個軟體是對舊系統的改造，那開發新系統時，要充分了解老系統存在的問題，需要增加的功能，新系統實際上是老系統的部分功能加上一些新增功能形成的系統

1. 匯出新系統的高層邏輯模型
2. 重新定義問題

新系統的邏輯模型實質上表達了分析員對系統必須做什么的看法，得到新系統的高層邏輯模型之后，可能會發現前面問題定義的范疇過大，分析員還要和用戶一起再復查問題定義，對問題進行重新定義和修正，

1. 匯出和評價供選擇的解法

分析員應該從系統邏輯模型出發，研究問題的幾個組成部分，細化各功能點，匯出若干個較高層次的物理解法供比較和選擇

1. 推薦行動方針
2. 草擬開發計劃

任務分解 進度規劃 財務預算 風險分析及對策

1. 書寫檔案提交復查

第三章：

一.軟體需求的定義：

以清晰、簡單、一致且無二義性的方式，描述用戶對目標軟體系統在功能、行為、性能、設計約束等方面的期望，是在開發程序中對軟體系統的約束，

二.需求分析的任務：

1. 業務需求：是客戶對于軟體系統的高層次目標要求，定義了專案的遠景和范圍
2. 用戶需求：從用戶角度描述軟體系統的功能需求與非功能需求，通常只涉及系統的外部行為，
3. 功能需求：功能需求描述軟體系統應該提供的功能或務,通常涉及用戶或其他外部系統與目標系統之間的互動,不考慮目標系統內部的實作細節
4. 非功能需求：非功能需求即性能需求，反映了客戶對軟體系統質量和性能的額外要求
5. 約束條件： 約束條件是軟體系統設計和實作時必須滿足的限制條件
6. 業務規則： 業務規則是對某些功能的可執行性成內部執行速制的一些限定條件
7. 外部介面需求: 外部介面需求是描述目標系統與外部環境之間的互動介面
8. 資料定義:當用戶描達一個資料項或一個復雜的業務資料結構的格式或預設值時,正在進行資料定義

第四章：

啟發規則：

啟發規則是軟體結構設計優化準則，軟體概要設計的任務就是軟體結構的設計，為了提高設計的質量，必須根據軟體設計原理設計軟體，利用啟發規則優化軟體結構，

1.改進軟體結構提高模塊獨立性2.模塊規模適中3.適當控制深度、寬度、扇出、扇入

4.模塊的作用域應該在控制域之內5.力爭降低模塊介面的復雜程度

6.設計單入口單出口的模塊7.模塊功能可預測

第五章：

詳細設計的程序

軟作詳細設計是軟體工程的重要階段,在詳細設計程序中,細化了高層的體系結構設計，將軟體結構中的主要部件劃分為能獨立編碼、編譯和測驗的軟體單元,并進行軟體單元的設計,同時確定了軟體單元和單元之間的外部介面，

一.詳細設計的基本任務：

1. 演算法設計:用某種圖形、表格、語言等工具將每個模塊處理程序的詳細演算法描述出來
2. 資料結構設計:對于需求分析,概要設計確定的概念性的資料型別進行確切的定義
3. 物理設計： 對資料庫進行物理設計,即確定資料庫的物理結構
4. 其他設計

a.代碼設計：為了提高資料的輸入、分類、存盤及檢索等操作的效率,對資料庫中的某些資料項的值要進行代碼設計b.輸入/輸出格式設計c.人機對話設計

1. 撰寫詳細設計說明書 6 . 評審：對處理程序的演算法和資料庫的物理結構要進行評審

二.詳細設計方法：

1. 自頂向下，逐步求精 2.具有單入、單出的控制結構 3. 五種控制結構：順序結構，選擇，先判斷型回圈結構，后斷型回圈結構，多選擇分支結構

第七章：

一．測驗用例設計：

白盒測驗是對軟體的程序細節做細致的檢查，這一方法把測驗物件看作 個打開的盒子，允許測驗人員利用程式內部的邏輯結構及有關資訊設計或選擇測驗用例，對程式所有邏輯路徑進行測驗，通過在不同點檢查程式的狀態,確定實際的狀態是否與期望的狀態一致，

覆寫標準：

1. 陳述句覆寫

含義：就是選擇足夠多的測驗用例，運行被測程式，使得程式中每條陳述句至少執行一次，

1. 判定覆寫

含義：又稱為分支覆寫，在設計測驗用例，針對程式中具有分支結構的部分，為了測驗所有的可能結果，需要將每個分支都至少執行一次，查看相應的陳述句執行情況和結果

(1)a=2,b=0,x=4,覆寫RACBDE

(2)a=3,b=1,x=1覆寫 RABE

1. 條件覆寫

條件覆寫是指設計測驗用例時,除了保證每條陳述句執行一次,還要使判定運算式的每個條件的各種可能取值都至少執行一次,為了實作條件覆寫,保證各種可能的條件都取值,即保證

第一個判斷有以下取值:a>1,a<=1,b=0,b≠0

第二個判斷有以下取值:a=2,a≠2,x>1,x<=1

選擇兩組測驗用例:

(1)a=2,b=2,x=2(滿足a>1,b≠0,a=2,x>1的條件),執行路徑為 RABDE

(2)a=1,b=0,x=0(滿足a<=1,b=0,a≠2,x<=1的條件),執行路徑為RABE

1. 判定/條件覆寫

單獨使用判定覆寫和條件覆寫測驗結果都不夠全面, 若將兩種覆寫結合，就會相互補充,判定/條件覆寫就是設計足夠多的測驗用例，使得每個判定運算式中的每個條件都取到各種可能的值,并且使每個判斷陳述句的所有判斷結果至少出現一次，

(1)a=2,b=0,x=2(滿足a>1,b=0,a=2,x>1的條件)，執行路徑RACBDE

(2)a=1,b=1,x=1(滿足a<=1,b≠0,a≠2,x<=1的條件)，執行路徑RABE

1. 條件組合覆寫

條件組合覆寫就是設計足夠多的測驗用例,使得每個判定運算式中條件取值的各種組合都至少出現一次，根據每個判定運算式情況,列出如下條件組合

(1)a>1,b=0,A運算式為真;(2)a>1,b≠0,A運算式為假;(3)a<=1,b=0,A運算式為假

(4)a<=1,b≠0,A運算式為假;(5)a=2,x>1,B運算式為真(6)a=2,x<=1,B運算式為真;

(7)a≠2,x>1,B運算式為真;(8)a≠2,x<=1,B運算式為假，

選擇以下四組測驗用例

選擇條件a=2,b=0,x=2,(1)、(5)組合,執行路徑 RACBDE

選擇條件a=2,b=1,x=1,(2)、(6)組合,執行路徑 RABDE

選擇條件a=1,b=0,x=2,(3)、(7)組合,執行路徑 RABDE

選擇條件a=1,b=1,x=1,(4)、(8)組合,執行路徑 RABE

1. 路徑覆寫

就是選取足夠多的用例，保證程式的所有路徑都至少執行一次，如果存在環形結構，也要保證此環的所有路徑都至少執行一次，

(1)a=1,b=1,x=1(滿足a<=1,b≠0,a≠2,x<=1的條件),執行路徑為RABE

(2)a=2,b=0,x=2(滿足a>1,b=0,a=2,x>1的條件),執行路徑為 RACBDE

(3)a=2,b=1,x=2(滿足a>1,b≠0,a=2,x>1的條件),執行路徑為 RABDE;

(4)a=3,b=0,x=1(滿足a>1,b=0,a≠2,x<=1的條件),執行路徑為 RACBE

二．測驗的步驟：

1. 單元測驗

a.單元測驗的主要任務

單元測驗針對每個模塊,主要解決五個方面的問題：(1)模塊介面(2)區域資料結構（3）路徑測驗 (4)過界條件 (5)出錯處理

b.單元測驗的執行程序

1. 集成測驗

a.非增式集成測驗方法 b. 增式集成測驗方法

1. 確認測驗

確認測驗的標準 配置審查的內容 Alpha Beta 測驗

1. 系統測驗

方法：恢復測驗方法 安全測驗方法 強度 性能

第八章：

一．軟體維護的概念

軟體維護是指在軟體運行或維護階段對軟體產品所進行的修改,這些修改可能是改

正軟體中的錯誤,也可能是增加新的功能以適應新的需求,但是一般不包括軟體系統結

構上的重大改變，根據軟體維護的不同原因,軟體維護可以分成四種型別

(1)改正性維護

在軟體交付使用后,由于開發時測驗得不徹底或不完全,在運行階段會暴露一些開

發時未能測驗出來的錯誤,為了識別和糾正軟體錯誤,改正軟體性能上的缺陷,避免實

施中的錯誤使用,應當進行的診斷和改正錯誤的程序,這就是改正性維護

(2)適應性維護

隨著計算機技術的飛速發展和更新換代,軟體系統所需的外部環境或資料環境可能

會更新和升級,如作業系統或資料庫系統的更換等，為了使軟體系統適應這種變化,需

要對軟體進行相應的修改,這種維護活動稱為適應性維護

(3)完善性維護

在軟體的使用程序中,用戶往往會對軟體提出新的功能與性能要求,為了滿足這些

要求,需要修改或再開發軟體,以擴充軟體功能、增強軟體性能、改進加工效率、提高軟體

的可維護性,這種情況下進行的維護活動叫作完善性維護,完善性維護不一定是救火

式的緊急維修,而可以是有計劃的一種再開發活動

4)預防性地護

這類維護是為了提高軟體的可維護性,可靠性等,為以后進一步改進軟體打下良好

的基礎的維護活動,具體來講,就是采用先進的軟體工程方法對需要維護的軟體或軟體中的某一部分重新設計、編碼和測驗的活動，

二．軟體維護的特點

1.軟體維護受開發程序影響大

2.軟體維護困難多

3.軟體維護成本高

三．軟體維護的步驟

軟體維護作業包括建立維護組織、報告與評估維護申請、實施維護流程等步驟，

在影響分析和版本規劃的程序中,不同的維護型別需要采用不同的維護策略

（1）改正性維護:首先應該評價軟體錯誤的嚴重程度,對于十分嚴重的錯誤,維護

員應該立即實施維護對于一般性的錯誤,維護人員可以將有關的維護作業與其他開發

任務一起進行現劃，在有些情況下,有的錯誤非常嚴重,以致不得不臨時放棄正常的維

護控制作業程式,既不對修改可能帶來的副作用作出評價,也不對檔案作相應的更新,而

是立即進行代碼的修改，這是一種救火式的改正性維護,只有在非常緊急的情況下才使

用,這種維護在全部維護中只占很小的比例，應當說明的是,救火式不是取消,只是推遲

了維護所需要的控制和評價，一旦危機取消,這些控制和評價活動必須進行,以確保當

前的修改不會增加更為重要的問題

(2)適應性維護:首先確定軟體維護的優先順序,再與其他開發任務一起進行規劃

(3)定善性維護,根據商業的需求和軟體的發展，有些完善性維護可能不會被接受，對于被接受的維護中請,應該確定其優先次序井現劃其開發作業

第九章

質量保證

產品的生命，不論生產何種產品，質量都是極端重要的，軟體產品開發周期長，耗費巨大的人力和物力，更必須特別注意保證質量，

軟體質量：概括地說，軟體質量就是“軟體與明確地和隱含地定義的需求相一致的程度”，更具體地說，軟體質量是軟體與明確地敘述的功能和性能需求、檔案中明確描述的開發標準以及任何專業開發的軟體產品都應該具有的隱含特征相一致的程度，

軟體質量因素的定義：

正確性：系統滿足規格說明和用戶目標的程度,即,在預定環境下能正確地完成預期功能的程度

建壯性：在硬體發生故障、輸人的資料無效或操作錯誤等意外環境下,系統能做出適當回應的程度

完整性(安全性)：對未經授權的人使用軟體或資料的企圖,系統能夠控制(禁止)的程度

效率：為了完成預定的功能,系統需要的計算資源的多少

可用性：系統在完成預定應該完成的功能時令人滿意的程度

風險：按預定的成本和進度把系統開發出來,并且為用戶所滿意的概率

可理解性：理解和使用該系統的容易程度

可維修性：診斷和改正在運行現場發現的錯誤所需要的作業量的大小

靈活性(適應性)：修改或改進正在運行的系統需要的作業量的多少

可測驗性：軟體容易測驗的程度

可移植性：把程式從一種硬體配置和(或)軟體系統環境轉移到另一種配置和環境時,需要的作業量多少,有一種定量度量的方法是:用原來程式設計和除錯的成本除移植時需用的費用

可再用性：在其他應用中該程式可以被再次使用的程度(或范圍)

互運行性：把該系統和另一個系統結合起來需要的作業量的多少

軟體質量保證的措施主要有：基于非執行的測驗（也稱為復審或評審），基于執行的測驗（即以前講過的軟體測驗）和程式正確性證明，

復審主要用來保證在編碼之前各階段產生的檔案的質量；基于執行的測驗需要在程式撰寫出來之后進行，它是保證軟體質量的最后一道防線；程式正確性證明使用數學方法嚴格驗證程式是否與對它的說明完全一致

技術復審的必要性：

正式技術復審的顯著優點是，能夠較早發現軟體錯誤，從而可防止錯誤被傳播到軟體程序的后續階段，

正式技術復審是軟體質量保證措施的一種，包括走查和審查等具體方法，走查的步驟比審查少，而且沒有審查正規，

走查主要有下述兩種方式，

（1） 參與者驅動法，參與者按照事先準備好的串列，提出他們不理解的術語和認為不正確的術語，檔案撰寫組的代表必須回答每個質疑，要么承認確實有錯誤，要么對質疑做出解釋，

（2） 檔案驅動法，檔案撰寫者向走查組成員仔細解釋檔案，走查組成員在此程序中不時針對事先準備好的問題或解釋程序中發現的問題提出質疑，這種方法可能比第一種方法更有效，往往能檢測出更多錯誤，經驗表明，使用檔案驅動法時許多錯誤是由檔案講解者自己發現的，

審查步驟：

（1） 綜述，由負責撰寫檔案的一名成員向審查組綜述該檔案，在綜述會結束時把檔案分發給每位與會者，

（2） 準備，評審員仔細閱讀檔案，最好列出在審查中發現的錯誤的型別，并按發生頻率把錯誤型別分級，以輔助審查作業，這些串列有助于評審員們把注意力集中到最常發生錯誤的區域，

（3） 審查，評審組仔細走查整個檔案，和走查一樣，這一步的目的也是發現檔案中的錯誤，而不是改正它們，通常每次審查會不超過90分鐘，審查組組長應該在一天之內寫出一份關于審查的報告，

（4） 返工，檔案的作者負責解決在審查報告中列出的所有錯誤及問題，

（5） 跟蹤，組長必須確保所提出的每個問題都得到了圓滿的解決（要么修正了檔案，要么澄清了被誤認為是錯誤的條目），必須仔細檢查對檔案所做的每個修正，以確保沒有引入新的錯誤，如果在審查程序中返工量超過5%，則應該由審查組再對檔案全面地審查一遍，

程式正確性證明：

測驗可以暴露程式中的錯誤，因此是保證軟體可靠性的重要手段；但是，測驗只能證明程式中有錯誤，并不能證明程式中沒有錯誤，因此，對于保證軟體可靠性來說，測驗是一種不完善的技術，人們自然希望研究出完善的正確性證明技術，

軟體工程一測

1. 軟體工程三要素：______________、_________________、_________________
2. 獲取愿景的三部曲：
3. 愿景_______（是/否）功能，
4. 愿景必須指出__________
5. 迭代與增量的定義
6. UML靜態圖包括（4個）
7. UML動態圖包括（5個）
8. 為什么使用UML語言
9. ______________是軟體成功的基礎，

答案：

1. 工具（系統）、方法（技能）、開發程序（框架）
2. 第一步：找到軟體專案的“老大”；第二步：得到“老大”對專案的期望（愿景）；第三步：描述出愿景的度量指標，
3. 否
4. 度量指標
5. 迭代是反復求精，增量是逐塊建造
6. 類圖、物件圖、組件圖、部署圖
7. 時序圖、協作圖、狀態圖、活動圖、用例圖
8. 主要用于交流，有利于清晰，有利于精確
9. 需求

軟體工程二測

1. 在專案失敗的因素中，與 相關的比例最高，
2. 是解決需求噩夢的手段，
3. 簡要分析專案開發程序中，公司老板、中層經理、一線員工的需求分別有什么特點，
4. ICONIX程序從把需求檔案變成可運作的代碼程序只需四步，需要使用哪四張UML圖？
5. 若某公司設有公司老總、市場總監與財務總監，實作強化客戶管理功能、提升財務效率功能、優化公司資源功能的三種軟體，“老大”分別是誰？

答案：

1.需求

2.需求工程

3.公司老板：企業戰略、開源節流（定于愿景）

中層經理：簡化管理、優化流程（業務建模）

一線員工：作業簡單（用例分析）

4.用例圖、序列圖、類圖、健壯性圖

5.強化客戶管理：市場總監

提升財務效率：財務總監

優化公司資源：公司老總

軟體程序三測

1. 業務建模序列圖階段要注意什么？
2. 業務序列圖中，alt表示（ ），loop表示（ ），opt表示（ ）；
3. Alt和opt在使用的時候有什么區別？
4. 業務序列圖中，訊息的名字表示什么？
5. 業務序列圖中，訊息的方向表示什么？
6. 把（ ）看作特殊的業務物體，
7. 業務建模結果復核目的有兩點，分別是什么？

答案：

1. 本階段不要考慮要實作什么系統
2. 分支，回圈，可選分支
3. Alt表示分支，是需要條件的；opt表示可選分支，沒有條件，有選擇性，
4. 代表責任和目的
5. 責任委托，不是資料流動
6. 時間
7. 一是完善業務建模成果，尋找是否有遺漏或錯誤的地方進行修正，如果問題明顯，就需要迭代回去繼續做業務建模作業；

二是關鍵干系人在資訊和意見上達成一致，并共同簽字確認，作為下一階段啟動的標志，

軟體工程四測

1. 業務建模要求我們把視角從_______，以達到清晰準確地“診斷”，對癥“開方”

答案：軟體系統轉向客戶組織，站在客戶角度看問題

2、業務建模三步驟：

1、___________2、____________3、____________

答案：

1. 明確我們為誰服務（選定愿景要改進的組織），
2. 要改進的組織是什么現狀（業務用例圖、現狀業務序列圖），
3. 我們如何改進（改進業務序列圖），

3、了解組織現狀：

（1）從外部看：組織是____的集合，用業務用例圖來建模

（2）從內部看：組織是____的集合

答案：價值、系統

4、業務用例圖幫助我們從______了解組織的______，

答案：高層次 、業務構成

5、業務執行者是在業務組織之外，與其互動，享受其價值的_______

答案：人或組織

6、業務用例是業務組織為業務執行者提供的______.

答案：價值

7、業務序列圖幫助我們從______了解組織的______，

答案：細節上、 業務流程

8、業務序列圖詳細描述________、_______、________之間如何互動，以完成某個業務用例的實作流程

答案：業務執行者、業務工人、業務物體

9、舉個簡單的例子并識別其中的業務物件：業務執行者、業務工人、業務物體

答案：自由發揮

10、我們如何改進（改進業務序列圖）

答案：了解業務組織現狀的目的——發現流程中的改進點：

• 資訊自動流轉
• 封裝復雜業務邏輯
• 職責轉移
• 訪問和操作業務物件

其他……

軟體程序五測

1. 域建模_____不等于_____（等于或不等于）資料模型
2. ___用例分析________前做域建模
3. 需求分析的主流分析方法有___原型法____、______用例法_______
4. 繪制系統用例圖的步驟

1. 確定系統邊界

2. 識別系統執行者

3. 識別系統用例

4. 確定用例間的關系

1. 怎樣區別主執行者和輔執行者

主執行者：

1.用例發起者；

2.用例為其實作有價值的目標；

輔執行者：

1.用例支持者；

2.用例的完成需要與其互動，得到其支持

1. 如何找到執行者

誰使用該系統？

? 誰改變系統的資料？

? 誰從系統獲取資訊？

? 誰負責維護、管理并保持系統正常運行？

? 系統需要應付哪些硬體設備？

? 系統需要和那些外部系統互動？

? 誰對系統運行產生的結果感興趣？

? 有沒有自動發生的事件？

1. 系統用例是執行者通過系統____達到某個目標______
2. 用例的關系____泛化____、_____包含_______、______擴展__________
3. 先發現執行者還是先發現用例？為什么？

執行者比用例明顯，

? 執行者的個數遠比用例的個數少，

? 找到一個執行者，就可以找到一堆用例，

? 執行者是系統外部人物的代表，所以當然是要先找到執行者，才能夠從執行者的角度去尋找用例，

1. 用例命名的三個條件是什么？

用例名稱必須是動賓短語，

? 采用域建模中的名詞術語，

? 慎用弱動詞弱名詞——會掩蓋真正的業務

1. 用例_____不等于______功能，用例____不等于______步驟

軟體程序六測

1. 每個用例必須對應有___愿景目標______
2. 用例描述的基本組成__干系人利益_____________、_____基本路徑____________、________擴展路徑_______、_______業務規則_______________
3. _________用例_______是干系人利益的平衡點，
4. 基本路徑的書寫要求，

以主動語態、“名詞-動詞-名詞”格式來書寫，

主語只能是執行者或系統，

1. 基本路徑與擴展路徑是否要分開，

要