第一章：
軟件工程定義：
1968年10月，Fritz Bauer 首次提出了“軟件工程”的概念，并將“軟件工程”定義為：為了經濟地獲得能夠在實際機器上有效運行的可靠軟件，而建立并使用的一系列工程化原則。
1993年IEEE對軟件工程的定義：軟件工程是將系統化的、規范化的、可度量的途徑應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件的方法的研究。
軟件工程原則：
抽象與自頂向下，逐層細化 ?信息隱蔽和數據封裝 模塊化 局部化 確定性 一致性和標準化 完備性和可驗證性
瀑布模型：
開發活動的特征：（1）以上一項活動方產生的工作對象為輸入(2)利用這一輸入,實施本項活動應完成的內容(3)給出該項活動的工作結果,作為輸出傳給下一項活動(4)對實施該項活動的工作結果進行評審,若其工作得到確認,則繼續進行下一項活動,否則返回前項,甚至更前項的活動進行返工
瀑布模型的優點:
(1)可強迫開發人員采用規范化的方法
(2)嚴格地規定了每個階段必須提交的文檔
瀑布模型的缺點
(1)由于瀑布模型幾乎完全依賴于書面的規格說明,很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。如果需求規格說明與用戶需求之間有差異,就會發生這種情況(2)瀑布模型只適用于項目開始時需求已確定的情況。總地來說,瀑布模型是一種應付需求變化能力較弱的開發模型,因此,很多在該模型基礎上開發出來的軟件產品不能夠真正滿足用戶需求
第二章：
可行性研究的過程：
- 復查系統規模和目標
復查系統定義，改正含糊或不確切的敘述，清晰地描述對目標系統的一切限制和約束
- 研究目前正在使用的系統
現有的系統是信息的重要來源。若一個軟件是對舊系統的改造，那開發新系統時，要充分了解老系統存在的問題，需要增加的功能，新系統實際上是老系統的部分功能加上一些新增功能形成的系統
- 導出新系統的高層邏輯模型
- 重新定義問題
新系統的邏輯模型實質上表達了分析員對系統必須做什么的看法，得到新系統的高層邏輯模型之后，可能會發現前面問題定義的范疇過大，分析員還要和用戶一起再復查問題定義，對問題進行重新定義和修正。
- 導出和評價供選擇的解法
分析員應該從系統邏輯模型出發，研究問題的幾個組成部分，細化各功能點，導出若干個較高層次的物理解法供比較和選擇
- 推薦行動方針
- 草擬開發計劃
任務分解 進度規劃 財務預算 風險分析及對策
- 書寫文檔提交復查
第三章：
一.軟件需求的定義：
以清晰、簡單、一致且無二義性的方式，描述用戶對目標軟件系統在功能、行為、性能、設計約束等方面的期望，是在開發過程中對軟件系統的約束。
二.需求分析的任務：
- 業務需求：是客戶對于軟件系統的高層次目標要求，定義了項目的遠景和范圍
- 用戶需求：從用戶角度描述軟件系統的功能需求與非功能需求，通常只涉及系統的外部行為。
- 功能需求：功能需求描述軟件系統應該提供的功能或務,通常涉及用戶或其他外部系統與目標系統之間的交互,不考慮目標系統內部的實現細節
- 非功能需求：非功能需求即性能需求，反映了客戶對軟件系統質量和性能的額外要求
- 約束條件： 約束條件是軟件系統設計和實現時必須滿足的限制條件
- 業務規則： 業務規則是對某些功能的可執行性成內部執行速制的一些限定條件
- 外部接口需求:??? 外部接口需求是描述目標系統與外部環境之間的交互接口
- 數據定義:當用戶描達一個數據項或一個復雜的業務數據結構的格式或缺省值時,正在進行數據定義
第四章：
啟發規則：
啟發規則是軟件結構設計優化準則，軟件概要設計的任務就是軟件結構的設計，為了提高設計的質量，必須根據軟件設計原理設計軟件，利用啟發規則優化軟件結構。
1.改進軟件結構提高模塊獨立性2.模塊規模適中3.適當控制深度、寬度、扇出、扇入
4.模塊的作用域應該在控制域之內5.力爭降低模塊接口的復雜程度
6.設計單入口單出口的模塊7.模塊功能可預測
第五章：
詳細設計的過程
軟作詳細設計是軟件工程的重要階段,在詳細設計過程中,細化了高層的體系結構設計，將軟件結構中的主要部件劃分為能獨立編碼、編譯和測試的軟件單元,并進行軟件單元的設計,同時確定了軟件單元和單元之間的外部接口。
一.詳細設計的基本任務：
- 算法設計:用某種圖形、表格、語言等工具將每個模塊處理過程的詳細算法描述出來
- 數據結構設計:對于需求分析,概要設計確定的概念性的數據類型進行確切的定義
- 物理設計： 對數據庫進行物理設計,即確定數據庫的物理結構
- 其他設計
a.代碼設計：為了提高數據的輸入、分類、存儲及檢索等操作的效率,對數據庫中的某些數據項的值要進行代碼設計b.輸入/輸出格式設計c.人機對話設計
- 編寫詳細設計說明書 ?6 . 評審：對處理過程的算法和數據庫的物理結構要進行評審
二.詳細設計方法：
- 自頂向下，逐步求精 ?2.具有單入、單出的控制結構 3. 五種控制結構：順序結構，選擇，先判斷型循環結構，后斷型循環結構，多選擇分支結構
第七章：
一．測試用例設計：
白盒測試是對軟件的過程細節做細致的檢查。這一方法把測試對象看作 個打開的盒子，允許測試人員利用程序內部的邏輯結構及有關信息設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態,確定實際的狀態是否與期望的狀態一致。
覆蓋標準：
- 語句覆蓋
含義：就是選擇足夠多的測試用例，運行被測程序，使得程序中每條語句至少執行一次。
- 判定覆蓋
含義：又稱為分支覆蓋，在設計測試用例，針對程序中具有分支結構的部分，為了測試所有的可能結果，需要將每個分支都至少執行一次，查看相應的語句執行情況和結果
(1)a=2,b=0,x=4,覆蓋RACBDE
(2)a=3,b=1,x=1覆蓋 RABE
- 條件覆蓋
條件覆蓋是指設計測試用例時,除了保證每條語句執行一次,還要使判定表達式的每個條件的各種可能取值都至少執行一次,為了實現條件覆蓋,保證各種可能的條件都取值,即保證
第一個判斷有以下取值: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)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)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)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
二．測試的步驟：
- 單元測試
a.單元測試的主要任務
單元測試針對每個模塊,主要解決五個方面的問題：(1)模塊接口(2)局部數據結構（3）路徑測試 (4)過界條件 (5)出錯處理
b.單元測試的執行過程
- 集成測試
a.非增式集成測試方法 b. 增式集成測試方法
- 確認測試
確認測試的標準 ?配置審查的內容 ?Alpha Beta 測試 ?
- 系統測試
方法：恢復測試方法 ??安全測試方法 ?強度 ?性能
第八章：
一．軟件維護的概念
軟件維護是指在軟件運行或維護階段對軟件產品所進行的修改,這些修改可能是改
正軟件中的錯誤,也可能是增加新的功能以適應新的需求,但是一般不包括軟件系統結
構上的重大改變。根據軟件維護的不同原因,軟件維護可以分成四種類型
(1)改正性維護
在軟件交付使用后,由于開發時測試得不徹底或不完全,在運行階段會暴露一些開
發時未能測試出來的錯誤,為了識別和糾正軟件錯誤,改正軟件性能上的缺陷,避免實
施中的錯誤使用,應當進行的診斷和改正錯誤的過程,這就是改正性維護
(2)適應性維護
隨著計算機技術的飛速發展和更新換代,軟件系統所需的外部環境或數據環境可能
會更新和升級,如操作系統或數據庫系統的更換等。為了使軟件系統適應這種變化,需
要對軟件進行相應的修改,這種維護活動稱為適應性維護
(3)完善性維護
在軟件的使用過程中,用戶往往會對軟件提出新的功能與性能要求,為了滿足這些
要求,需要修改或再開發軟件,以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件
的可維護性,這種情況下進行的維護活動叫作完善性維護,完善性維護不一定是救火
式的緊急維修,而可以是有計劃的一種再開發活動
4)預防性地護
這類維護是為了提高軟件的可維護性,可靠性等,為以后進一步改進軟件打下良好
的基礎的維護活動,具體來講,就是采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分重新設計、編碼和測試的活動。
二．軟件維護的特點
1.軟件維護受開發過程影響大
2.軟件維護困難多
3.軟件維護成本高
三．軟件維護的步驟
軟件維護工作包括建立維護組織、報告與評估維護申請、實施維護流程等步驟。
在影響分析和版本規劃的過程中,不同的維護類型需要采用不同的維護策略
（1）改正性維護:首先應該評價軟件錯誤的嚴重程度,對于十分嚴重的錯誤,維護
員應該立即實施維護對于一般性的錯誤,維護人員可以將有關的維護工作與其他開發
任務一起進行現劃。在有些情況下,有的錯誤非常嚴重,以致不得不臨時放棄正常的維
護控制工作程序,既不對修改可能帶來的副作用作出評價,也不對文檔作相應的更新,而
是立即進行代碼的修改。這是一種救火式的改正性維護,只有在非常緊急的情況下才使
用,這種維護在全部維護中只占很小的比例。應當說明的是,救火式不是取消,只是推遲
了維護所需要的控制和評價。一旦危機取消,這些控制和評價活動必須進行,以確保當
前的修改不會增加更為重要的問題
(2)適應性維護:首先確定軟件維護的優先順序,再與其他開發任務一起進行規劃
(3)定善性維護,根據商業的需求和軟件的發展，有些完善性維護可能不會被接受。對于被接受的維護中請,應該確定其優先次序井現劃其開發工作
第九章
質量保證
產品的生命，不論生產何種產品，質量都是極端重要的。軟件產品開發周期長，耗費巨大的人力和物力，更必須特別注意保證質量。
軟件質量：概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特征相一致的程度。
軟件質量因素的定義：
正確性：系統滿足規格說明和用戶目標的程度,即,在預定環境下能正確地完成預期功能的程度
建壯性：在硬件發生故障、輸人的數據無效或操作錯誤等意外環境下,系統能做出適當響應的程度
完整性(安全性)：對未經授權的人使用軟件或數據的企圖,系統能夠控制(禁止)的程度
效率：為了完成預定的功能,系統需要的計算資源的多少
可用性：系統在完成預定應該完成的功能時令人滿意的程度
風險：按預定的成本和進度把系統開發出來,并且為用戶所滿意的概率
可理解性：理解和使用該系統的容易程度
可維修性：診斷和改正在運行現場發現的錯誤所需要的工作量的大小
靈活性(適應性)：修改或改進正在運行的系統需要的工作量的多少
可測試性：軟件容易測試的程度
可移植性：把程序從一種硬件配置和(或)軟件系統環境轉移到另一種配置和環境時,需要的工作量多少,有一種定量度量的方法是:用原來程序設計和調試的成本除移植時需用的費用
可再用性：在其他應用中該程序可以被再次使用的程度(或范圍)
互運行性：把該系統和另一個系統結合起來需要的工作量的多少
軟件質量保證的措施主要有：基于非執行的測試（也稱為復審或評審），基于執行的測試（即以前講過的軟件測試）和程序正確性證明。
復審主要用來保證在編碼之前各階段產生的文檔的質量；基于執行的測試需要在程序編寫出來之后進行，它是保證軟件質量的最后一道防線；程序正確性證明使用數學方法嚴格驗證程序是否與對它的說明完全一致
技術復審的必要性：
正式技術復審的顯著優點是，能夠較早發現軟件錯誤，從而可防止錯誤被傳播到軟件過程的后續階段。
正式技術復審是軟件質量保證措施的一種，包括走查和審查等具體方法。走查的步驟比審查少，而且沒有審查正規。
走查主要有下述兩種方式。
（1） 參與者驅動法。參與者按照事先準備好的列表，提出他們不理解的術語和認為不正確的術語。文檔編寫組的代表必須回答每個質疑，要么承認確實有錯誤，要么對質疑做出解釋。
（2） 文檔驅動法。文檔編寫者向走查組成員仔細解釋文檔。走查組成員在此過程中不時針對事先準備好的問題或解釋過程中發現的問題提出質疑。這種方法可能比第一種方法更有效，往往能檢測出更多錯誤。經驗表明，使用文檔驅動法時許多錯誤是由文檔講解者自己發現的。
審查步驟：
（1） 綜述。由負責編寫文檔的一名成員向審查組綜述該文檔。在綜述會結束時把文檔分發給每位與會者。
（2） 準備。評審員仔細閱讀文檔。最好列出在審查中發現的錯誤的類型，并按發生頻率把錯誤類型分級，以輔助審查工作。這些列表有助于評審員們把注意力集中到最常發生錯誤的區域。
（3） 審查。評審組仔細走查整個文檔。和走查一樣，這一步的目的也是發現文檔中的錯誤，而不是改正它們。通常每次審查會不超過90分鐘。審查組組長應該在一天之內寫出一份關于審查的報告。
（4） 返工。文檔的作者負責解決在審查報告中列出的所有錯誤及問題。
（5） 跟蹤。組長必須確保所提出的每個問題都得到了圓滿的解決（要么修正了文檔，要么澄清了被誤認為是錯誤的條目）。必須仔細檢查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審查過程中返工量超過5%，則應該由審查組再對文檔全面地審查一遍。
程序正確性證明：
測試可以暴露程序中的錯誤，因此是保證軟件可靠性的重要手段；但是，測試只能證明程序中有錯誤，并不能證明程序中沒有錯誤。因此，對于保證軟件可靠性來說，測試是一種不完善的技術，人們自然希望研究出完善的正確性證明技術。
?
?
