第一章1軟體危機的主要表現：對軟體開發成本和進度的估計不準確；產品不符合使用者的要求；軟體質量不高、可靠性差；軟體常常不可維護、錯誤難以改正；缺乏適當的文件資料；軟體成本佔系統總成本的比例逐年上公升；軟體開發速度跟不上計算機發展速度
3軟體工程的三要素：方法，工具，過程
4軟體生存週期包括軟體定義、軟體開發、執行維護3個部分。
其又分為6個步驟。(書上為8個步驟)
1）軟體定義； a.問題定義 b.可行性研究 c.需求分析
2）軟體開發；d.總體設計e.詳細設計 f.編碼和單元測試 g.綜合測試 3）軟體維護
第二章大家好好看看書上的圖例
第三章1便利的應用規約技術(facilitated application specification techniques , fast)是一種面向團隊的需求收集方法，即由開發人員和共同利益者的團隊共同完成如下任務：確認問題，為解決方案的要素提供建議， 協商不同的方法，說明初步的解決方案需求集合
2驗證軟體需求的正確性，一般應從4個方面進行：
(1) 一致性所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。
(2) 完整性需求必須是完整的，規格說明書應該包括使用者需要的每乙個功能或效能。
(3) 現實性指定的需求應該是用現有的硬體技術和軟體技術基本上可以實現的。
(4) 有效性必須證明需求是正確有效的，確實能解決使用者面對的問題。
3軟體需求權威的定義（ieee軟體工程標準詞彙表中的定義）
使用者解決問題或達到目標所需要的條件或能力；系統或系統部件要滿足合同、標準、規範或其他正式規定文件所要具有的條件或能力；一種反映上面兩條的文件說明
對定義的理解 ：軟體需求的概念涵蓋了使用者角度（系統的外部行為）和開發人員角度（系統的內部特性）兩個方面，關鍵在於需求一定要文件化
第五章1抽象：是在軟體設計的規模逐漸增大的情況下，控制複雜性的基本策略。 過程抽象，資料抽象
2逐步求精：把問題的求解過程分解成若干步驟或階段，每步都比上步更精化，更接近問題的解法。
3模組化；即把軟體按照規定原則，劃分為乙個個較小的、相互獨立的但又相互關聯的部件；實際上是系統分解和抽象的過程。
4資訊隱藏：指模組中包含的資訊（演算法和資料）不被不需要這些資訊的其他模組訪問，模組間只交流實現軟體功能所必需的資訊。
5區域性化：指把一些關係密切的軟體元素物理的放得彼此接近。
6模組獨立： 模組完成獨立的功能並且與其他模組的介面簡單；符合資訊隱蔽和資訊區域性化原則，模組間關聯和依賴程度盡可能小
7耦合(coupling) 模組之間的相對獨立性的度量
內聚（cohesion） 乙個模組內部各個元素彼此結合的緊密程度的度量
獨立性強的模組應該是高內聚低耦合的模組。
1）耦合----模組之間的依賴程度
內容耦合：乙個模組直接修改另乙個模組的內容
公共耦合：兩個以上的模組共同引用乙個全域性資料
外部耦合：若允許一組模組訪問同乙個全域性變數
控制耦合：接收模組的動作依賴於控制訊號
標記耦合：兩個模組介面的引數包含相同的內部結構
資料耦合：僅是模組之間的資料傳遞
非直接耦合：模組之間沒有訊息傳遞
2）內聚----模組內部各成分之間的關聯程度
巧合內聚：各成分之間並沒有關係，只是把分散在多處的功能合在一起
邏輯內聚：僅僅是邏輯功能相關成分合在一起，由判定引數確定
時間內聚：必須在同一時間執行，並無功能邏輯的成分合在一起
過程內聚：過程順序相關的功能成分合在一起
通訊內聚：需要對相同的外部資料進行操作的成分合在一起
資訊內聚：完成多個功能，各個功能都在同一資料結構上操作
功能內聚：只完成單一的功能
8輸入控制模組的分解
從變換中心的邊界開始，沿著輸入路徑向外移動，把輸入路徑上的每個加工對映成結構圖中受輸入控制模組控制的乙個低層模組
輸出控制模組的分解
從變換中心的邊界開始，沿著輸出路徑向外移動，把輸出路徑上的每個加工對映成結構圖中受輸出控制模組控制的乙個低層模組
變換控制模組的分解
把變換中心每個加工對映成結構圖中受變換控制模組控制的乙個低層模組
第六章1pdl（program design language）是一種用於描述功能部件的演算法設計和處理細節的語言。
它是一種偽碼。偽碼的語法規則分為「外語法」和「內語法」：
外語法應當符合一般程式語言常用語句的語法規則；
內語法可以用英語中一些簡單的句子、短語和通用的數學符號，來描述程式應執行的功能
2計算環路複雜性的方法：
根據圖論，在乙個強連通的有向圖g中，環的個數由以下公式給出：
v(g)＝m－n＋p
其中，v(g)是有向圖g中環路個數，m是圖g中弧數，n是圖g中結點數，p是圖g中的強連通分量個數
為使圖成為強連通圖，從圖的入口點到出口點加一條用虛線表示的有向邊，使圖成為強連通圖
注意：等於程式圖中弧所封閉的區域數
第七章1軟體測試的目的是：設計測試用例，以最小的代價、在最短的時間內系統地發現各種不同型別的錯誤。
軟體測試是以發現錯誤為目的執行乙個程式的過程。它的目的非常明確，就是要盡可能地發現至今為止尚未發現的錯誤或缺陷。
2軟體測試的步驟
(1)單元測試單元測試通常採用白盒測試，並且多個構件或模組可以並行進行測試
(2)整合測試整合測試也稱組裝測試、聯合測試
(3)確認測試確認測試一般使用黑盒測試法。
α測試使用者在開發者的場所進行測試；並且在開發者的指導下進行；測試在受控環境中進行；開發者記錄發現的錯誤和問題。
β測試使用者在乙個或多個客戶場所進行測試；不受開發者控制；
測試者記錄發現的問題和錯誤，定期將問題報告傳送給開發者。
(4)系統測試系統測試是對整個基於計算機的系統進行的一系列測試。
3軟體測試方法
(1)靜態測試
(2)動態測試：白盒測試，黑盒測試
白盒測試（又稱為結構測試）
把測試物件看作乙個透明的盒子，測試人員根據程式內部的邏輯結構及有關資訊設計測試用例，檢查程式中所有邏輯路徑是否都按預定的要求正確地工作。
黑盒測試（又稱功能測試）
把測試物件看做乙個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能需求。
等價類分為無效等價類和有效等價類
4軟體可靠性：是程式在給定的時間間隔內，按照規格說明書的規定成功地執行的概率。
軟體可用性：程式在給定的時間點，按照規格說明書的規定，成功地執行的概率。
可靠性和可用性的區別：可靠性是在0到t時間間隔內，系統沒有失效的概率；而可用性是在t時刻，系統是正常執行的概率。
5公式平均維修時間mttr是修復乙個故障平均需要用的時間，取決於維護人員的技術水平和對系統熟悉程度。
平均無故障時間mttf是系統按照規格說明書規定成功地執行的平均時間，取決於系統中潛伏的錯誤數量。
第八章1軟體維護：指軟體系統交付使用以後，為了改正錯誤或滿足新的需要而修改軟體的過程。
型別：改正性維護，適應性維護，完善性維護，預防性維護
2維護工作量的模型
m=p+k * exp(c-d)
m—維護的總工作量； p—生產性工作量；
k—經驗常數；c—複雜程度；
d—維護人員對軟體的熟悉程度
3軟體維護的*** ：因軟體修改而造成的錯誤或其它不希望出現的情況。
***的型別： 編碼*** ：修改原始碼引入錯誤
資料***：修改資料結構時，可能造成軟體設計與資料結構不匹配
文件***軟體修改了，文件不能反映軟體當前的狀態
4可維護性（maintainability）：指理解、改正、調整和改進軟體的難易程度。
對軟體可維護性影響的主要因素：： 可理解性（understandability）可測試性（testability）可修改性（modifiability）可移植性（portability）
可重用性（reuseability）
提高可維護性的方法：建立明確的軟體質量目標和優先順序；使用提高軟體質量的技術和工具；進行明確的質量保證審查；選擇可維護的程式語言；改進程式的文件
5軟體再工程：遺留系統通常對組織的核心業務邏輯提供關鍵性的支援，因此需要採用先進的軟體工程方法對整個軟體或軟體中的一部分重新進行設計、編寫和測試，以提高軟體的可維護性和可靠性，保證系統的正常執行，這就是軟體再工程。
反(逆)向工程：是分析程式以便在比源**更高的抽象層次上建立出程式的某種表示的過程。
正向工程：利用從現有程式中恢復的設計資訊而修改或重構現有系統，以提高系統的整體質量。
正向工程並不是簡單的構造乙個與原有系統功能等價的系統，而是結合新的使用者需求和軟體技術擴充套件原有系統的功能和效能。
軟體工程複習重點
第一章軟體工程概論 1.軟體危機是指在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題，幾乎所有軟體都不同程度地存在這些問題。2.軟體危機的典型表現 1 對軟體開發成本和進度的估計常常很不準確 2 使用者對 已完成的 軟體系統不滿意的現象經常發生 3 軟體產品質量往往靠不住 4 軟體常常是不可維護...
軟體工程導論重點內容
第一章軟體工程概述 一 什麼是軟體？1.滿足功能要求和效能的指令或電腦程式集合 2.處理資訊的資料結構 3.描述程式功能以及程式如何操作和使用所要求的文件 軟體的特點 軟體是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性。軟體是通過人們的智力活動，把知識與技術轉換成資訊的一種產品，是在研製 開...
軟體工程 完整規範版
軟體 程文件模板 附錄 軟體需求分析報吿文件模板 9 本指南用於指導軟體開發者為南京市交通局開發軟體專案的過程，通過規範軟體專案承擔單位地開發過程達到提高軟體質量，降低維護成本的目的。開發者應根據本指南進行軟體開發合編制軟體開發文件。本指南是對軟體專案承擔單位的基本要求。在本指南的附錄 至 中提供了...