軟體系統
支撐軟體（Support Software）：軟體系統的中間層，支撐各種軟體的開發、執行與維護的軟體。
系統軟體（System Software System Software）：最靠近計算機硬體的 最靠近計算機硬體的一層軟體 —— 控制和協調計算機及外部裝置、支援應用軟體開發與執行的軟體。
支撐軟體（Support Software）：軟體系統的中間層，支撐各種軟體的開發、執行與維護的軟體。
軟體工程（Software Engineering Software Engineering）：研究或應用工程化方法來設計、創造、構建和維護有效、實用和高質量軟體的一門學科。
軟體危機:對軟體開發工作量和成本估計不準；軟體開發進度難以控制；軟體產品質量與可靠性差強人意
軟體工程技術主要發展趨勢
軟體需求工程 （Requirement Engineering）—— 基於知識的軟體需求分析、需求分析自動化
中介軟體（Middleware Middleware）技術—— 中介軟體平臺、企業服務匯流排ESB、網路構件、基於中介軟體的軟體整合技術
軟體質量保障 —— 軟體質量評測與度量、軟體可靠性技術、軟體 程過 改進模
軟體領域化 —— 領域軟體工程（ Domain Engineering）、行業應用軟體、企業應用軟體
程式的本質是組合、抽象與構造
構造的基本手段是迭代和遞迴。遞迴是一種表達相似性物件及動作的重複性無限性構造的重要思想
程式:由基本動作指令構造的，若干指令的一個組合或一個執行序列，用以實現複雜動作
指令：控制基本動作執行的命令
計算系統 = 基本動作 + 指令 + 程式執行機構
遞迴是表達相似性物件及動作的無限性重複性構造的方法
定義：遞迴是一種關於抽象的表達方法---用遞迴定義無限的相似事物
構造：遞迴是一種演算法或程式的構造技術---自身呼叫自身，高階呼叫低階，構造無限的計算步驟
遞迴執行：遞迴是一種典型的計算/執行過程---由後向前代入，直至代入到遞迴基礎，再由遞迴基礎向後計算直至計算出最終結果，即由前向後計算
程式應該正確、有效、易理解、簡單、自然、可擴充、可伸縮
程式設計語言是：人與計算機通訊的最基本工具。語法+語義+語用
結構化程式設計原則
簡單結構，儘量使用語言提供的基本控制結構，即順序結構、選擇結構和重複（迴圈）結構
組合巢狀，複雜結構應該用基本控制結構組合或巢狀實現
一致性，語言中沒有的控制結構，可用一段等價的程式段模擬，但要求該程式段在整個系統中應前後一致
塊機制，將程式組織成容易識別的塊，每塊只有一個入口和一個出口
嚴格控制GOTO語句
自頂向下，先考慮總體，後考慮細節；先考慮全域性目標，後考慮區域性目標
逐步細化，對於複雜問題，進行分解為子目標。
模組化，再將子目標分解為小目標，予以結構化實現
程式設計風格—重用性要求
可重複使用的、功能相對獨立的演算法或介面。應該考慮封裝成公共的控制元件或類
相對固定和獨立的程式實現方式和過程，應考慮做成程式模板，增強對程式實現方式的複用
程式的效率：程式的執行速度及程式所需佔用的儲存空間
效率的影響因素
演算法，源程式的效率與詳細設計階段確定的演算法的效率直接有關
儲存器，大中型計算機系統,儲存限制不是主要問題。在微型計算機系統，儲存容量對軟體設計和編碼的制約很大
輸入/輸出
物件導向程式設計
含義，物件導向程式設計是以建立模型體現出來的抽象思維過程和麵向物件的方法。
方法，選擇程式設計語言、類的實現、方法的實現、使用者介面的實現等
主要概念，物件、類、資料抽象、繼承、動態繫結、資料封裝、多型性、訊息傳遞。
編碼策略
自頂向下，從模組的最高層次逐步向下編碼
複合模式，自頂向下與自底向上相結合，可以先總體介面、互動，到基礎模組
自底向上，從類繼承的底層開始向上編碼
執行緒模式，執行緒：執行關鍵功能的最小模組集合先執行緒，級關鍵構建，後其他模組
演算法是軟體的靈魂
演算法是一個有窮規則的集合，它用規則規定了解決某一特定型別問題的運算序列，或者規定了任務執行或問題求解的一系列步驟。
計算學科演算法的基本特徵
有窮性：一個演算法在執行有窮步規則之後必須結束
確定性：演算法的每一個步驟必須要確切地定義，不得有歧義性。
輸入：演算法有零個或多個的輸入
輸出：演算法有一個或多個的輸出/結果，即與輸入有某個特定關係的量。
能行性：演算法中有待執行的運算和操作必須是相當基本的(可以由機器自動完成)，並能在有限時間內完成
問題求解第一步--數學建模
TSP問題(Traveling Salesman Problem，旅行商問題)
有若干城市，任何兩個城市之間的距離都是確定的，現要求一旅行商從某城市出發必須經過每一城市且只能在每個城市逗留一次，最後回到原出發城市，問如何事先確定好一條最短的路線使其旅行的費用最少。
TSP是最有代表性的組合最佳化問題之一，在半導體制造(線路規劃)、物流運輸(路徑規劃)等行業有著廣泛的應用
第二步，演算法策略設計
遍歷演算法
貪心演算法，每次在選擇下一個城市的時候，只考慮當前情況，保證迄今為止經過的路徑總距離最短
第三步，演算法思想的精確表達
演算法的資料結構設計---問題或演算法相關的資料之間的邏輯關係及儲存關係的設計
資料結構是資料的邏輯結構、儲存結構及其操作的總稱，它提供了問題求解/演算法的資料操縱機制
演算法的控制結構設計---演算法的計算規則或計算步驟設計
順序結構，分支結構，迴圈結構
軟體過程
軟體生命週期，軟體產品或軟體系統從設計、投入使用到被淘汰的全過程
軟體過程是在工作產品構建過程中，所需完成的工作活動、動作和任務的集合
活動主要實現寬泛的目標，與應用領域、專案大小、結果複雜性或者實施軟體工程的重要程度沒有直接關係
動作包含了主要工作產品生產過程中的一系列任務
任務關注小而明確的目標，能夠產生實際產品。
軟體過程模型：是軟體開發全部過程、活動和任務的結構框架。它能直觀表達軟體開發全過程，明確規定要完成的主要活動、任務和開發策略。
軟體過程評估：能力成熟度模型CMM
傳統軟體過程模型
瀑布模型
實際（帶反饋）的瀑布模型
瀑布模型的缺點
增加工作量：各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量
早期錯誤發現晚：早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果
開發風險大：由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險
不適應需求變化：不能反映實際的開發方式，軟體開發需要迭代；無法適應需求不明確和需求的變化
瀑布模型適用於系統需求明確且穩定、技術成熟、工程管理較嚴格的場合，如軍工、航天、醫療
V模型（V-model）：瀑布模型的變種
原型模型（Prototype model）
原型（prototype）一個部分開發的產品，使客戶和開發人員能夠對計劃開發的系統的相關方面進行檢查。
優點：減少需求不明確帶來的風險
適用場合：客戶定義一個總體目標集，但他們並不清楚系統的具體輸入輸出。
增量模型（Incremental model）
增量：滿足使用者需求的一個子集，能夠完成一定功能、小而可用的軟體
增量模型是一種非整體開發的模型，是一種進化式的開發過程
增量模型從部分需求出發，先建立一個不完整的系統，透過測試執行這個系統取得經驗和反饋，進一步使系統擴充和完善
如此反覆進行，直至軟體人員和使用者對所設計的軟體系統滿意為止
增量模型結合了原型模型的基本要素和迭代的特徵，採用了基於時間的線性序
列，每個線性序列都會輸出該軟體的一個“增量“
每個增量的開發可用瀑布或快速原型模型
適用於軟體開發中需求可能發生變化、具有較大風險、或者希望儘早進入市場的專案
螺旋模型：開發過程分成若干次迭代，每次迭代代表開發的一個階段，對應模型中一條環線
優點
螺旋模型強調原型的可擴充性和可修改性，原型的進化貫穿整個軟體生存週期，這將有助於目標軟體的適應能力，支援使用者需求的動態變化
原型可看作可執行的需求規格說明，易於為使用者和開發人員共同理解，還可作為繼續開發的基礎，併為使用者參與所有關鍵決策提供了方便
螺旋模型為專案管理人員及時調整管理決策提供了方便，進而可降低開發風險
適用於需求不明確或者需求可能發生變化的大型複雜的軟體系統。
噴泉模型（Fountain model）
噴泉模型是一種以使用者需求為動力，以物件為驅動的模型，主要用於描述物件導向的軟體開發過程
軟體開發早期定義物件，整個開發過程充實和擴充物件
現代軟體過程模型
基於構件的開發模型，Component-based development
軟體複用思想。
適用於系統之間有共性的情況
統一過程模型Rational Unified Process
基於物件導向方法學，使用統一建模語言UML（Unified Modeling Language）
敏捷開發過程
快速響應變化和不確定性
測試驅動開發可能導致透過測試但非使用者期望；重構而不降低質量困難
適用於需求模糊且經常改變的場合，適合商業競爭環境下的專案。
如何選擇軟體過程模型
1.前期需求明確的情況下，儘量採用瀑布模型
2.使用者無系統使用經驗，需求分析人員技能不足的情況下，儘量藉助原型模型
3.不確定因素很多，很多東西無法提前計劃的情況下，儘量採用增量模型或螺旋模型
4.需求不穩定的情況下，儘量採用增量模型
5.資金和成本無法一次到位的情況下，可採用增量模型
6.對於完成多個獨立功能開發的情況，可在需求分析階段就進行功能並行，每個功能內部都儘量遵循瀑布模型
7.全新系統的開發必須在總體設計完成後再開始增量或並行
8.編碼人員經驗較少的情況下，儘量不要採用敏捷或迭代模型
9.增量、迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付和出口原則
需求分析的概念
確定系統必須具有的功能和效能。
需求獲取
需求分析：對應用問題及環境的理解和分析，為問題涉及的資訊、功能及系統行為建立模型。將使用者需求精確化、完全化，最終形成下一步的需求規格說明書。
軟體需求規格說明書（SRS）------軟體系統的需求規格說明，是對待開發系統的行為的完整描述。它包含了功能性需求和非功能性需求。
需求驗證的工作
對需求文件需執行以下型別的檢查：
（1）有效性檢查
檢查不同使用者使用不同功能的有效性。
（2）一致性檢查
在文件中，需求之間不應該衝突。
（3）完備性檢查
需求文件應該包括所有使用者想要的功能和約束。
（4）現實性檢查
檢查保證能利用現有技術實現需求
需求驗證技術
（1）需求評審
（2）利用原型檢驗系統是否符合使用者的真正需要
（3）對每個需求編寫概念性的測試用例。
（4）編寫使用者手冊。用淺顯易懂的語言描述使用者可見的功能。
（5）自動的一致性分析。可用CASE工具檢驗需求模型的一致性
需求分析的任務
建立分析模型：準確地定義未來系統的目標，確定為了滿足使用者的需求系統必須做什麼
編寫需求說明:用《需求規格說明書》規範的形式準確地表達使用者的需求。
需求分析模型
程序導向分析模型:其基本思想是用系統工程的思想和工程化的方法，根據使用者至上的原則，自始自終按照結構化、模組化，自頂向下地對系統進行分析與設計
物件導向分析模型由5個層次（主題層、物件類層、結構層、屬性層和服務層）和5個活動（標識物件類、標識結構、定義主題、定義屬性和定義服務）組成。
程序導向分析模型——結構化分析方法
面向資料流進行需求分析的方法
結構化分析方法適合於資料處理型別軟體的需求分析
具體來說，結構化分析方法就是用抽象模型的概念，按照軟體內部資料傳遞、變換的關係，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟體為止
資料流圖的層次結構
在多層資料流圖中，頂層流圖僅包含一個加工，它代表被開發系統。它的輸入流是該系統的輸入資料，輸出流是系統所輸出資料
中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續細化，形成子圖
底層流圖是指其加工不需再做分解的資料流圖，它處在最底層
加工表示對資料進行的操作, 如“處理選課單” 、“產生髮票”等
外部實體（資料來源點/終點）位於系統之外的資訊提供者或使用者,稱為外部實體。即存在於系統之外的人員或組織。如“學務科”等
資料流表示資料和資料流向, 由一組固定成分的資料組成 如“選課單”由“學號、姓名、課程編號、課程名”等成分組成,資料流可從加工流向加工，也可在加工與資料儲存或外部項之間流動；兩個加工之間可有多股資料流
資料儲存表示需要儲存的資料流向, 如“ 學生檔案”、“課程設定”等
檢查資料流圖的原則
1）資料流圖上所有圖形符號只限於前述四種基本圖形元素
2）資料流圖的主圖必須包括前述四種基本元素，缺一不可
3）資料流圖的主圖上的資料流必須封閉在外部實體之間
4）每個加工至少有一個輸入資料流和一個輸出資料流
5）在資料流圖中，需按層給加工框編號。編號表明該加工所處層次及上下層的親子關係
6）規定任何一個資料流子圖必須與它上一層的一個加工對應，兩者的輸入資料流和輸出資料流必須一致。此即父圖與子圖的平衡
7）圖上每個元素都必須有名字
8）資料流圖中不可夾帶控制流
9）初畫時可以忽略瑣碎的細節，以集中精力於主要資料流
功能建模——編寫資料字典，寫出系統需求規格說明書，提交審查，並編寫測試驗收計劃、編寫初步的使用者手冊概要。
物件導向的軟體開發模型
資料模型（物件模型）:描述系統資料結構的物件模型;
行為模型（動態模型）描述系統控制結構
功能模型:描述系統功能
一個典型的軟體系統使用資料結構（物件模型），執行操作（動態模型），並且完成資料值的變化（功能模型）
軟體評估
組織分析：掌握目標單位的組成構成
業務分析：以客戶為中心，進行業務描述，遵循由粗到細的建模步驟，以崗位為最基本的構成單位，以崗位職責為最基本活動元素，建模業務流程，無須考慮流程中可能出現的異常情況和錯誤，可以在業務流程中反映相關的資料處理和變換
可行性分析：可行性的目的不是要解決問題，而是確定問題是否值得去解決，用最小的代價在儘可能短的時間內確定問題是否能夠解決
總體設計——又稱為概要設計或初步設計。
總體設計的任務是進行系統設計和結構設計。
系統設計劃分出組成系統的物理元素——程式、檔案、資料庫、人工過程和文件等等，但是每個物理元素仍然處於黑盒子級，這些黑盒子裡的具體內容將在詳細設計階段完成。
結構設計就是要確定系統中每個程式是由哪些模組組成的，以及這些模組相互間的關係
人類在認識複雜現象的過程中使用的最強有力的思維工具是抽象。
1）抽象：就是抽出事物的本質特性而暫時丌考慮它們的細節。
處理複雜系統的惟一有效的方法是用層次的方式構造和分析它。
一個複雜的動態系統首先可以用一些高階的抽象概念構造和理解，這些高階概念又可以用一些較低階的概念構造和理解，如此下去，直至最低層次的具體元素以某種方式對應於程式的一組成分
2）可行性分析：把需要解決問題抽象為一個解，探索是否有可行的解決方法。
需求分析：把需要解決的解抽象成功能；
總體設計：把系統抽象為結構；
詳細設計：把結構抽象為每個模組的處理過程；
編碼階段：把處理過程抽象為機器能夠執行的程式，
當源程式寫出來以後，也就達到了抽象的最低層
資訊隱藏原理
設計和確定模組，使得一個模組內包含的資訊(過程和資料)對於不需要這些資訊的模組來說，是不能訪問的。
區域性化
把一些關係密切的軟體元素物理地放得彼此靠近。區域性化有助於實現資訊隱藏。
模組獨立性：每個模組完成一個相對獨立的特定子功能，並且和其它模組之間的關係(或介面)很簡單。
模組獨立的概念是：模組化、抽象、資訊隱藏和區域性化概念的直接結果。
資料耦合當一個模組呼叫另一模組時，被呼叫模組的輸入、輸出都是簡單的資料
特徵耦合：當一個模組呼叫另一個模組時傳遞了整個資料結構,而被呼叫的模組只需要其中的一部分資料元素。
控制耦合：一模組向下屬模組傳遞的資訊，控制了被呼叫模組的內部邏輯。
外部耦合：一組模組均不同一外部環境關聯，並受到約束時，它們之間便存在外部耦合。
公共耦合：一組模組引用同一個公共資料區。
內容耦合：如果兩個模組中的一個模組直接引用了另一個模組的內容,則它們之間是內容耦合
內聚：衡量一個模組內部各個元素彼此結合的緊密程度。
偶然內聚：如果一個模組完成一組任務，這些任務彼此間即使有關係，關係也是很鬆散的，就叫做偶然內聚。
邏輯內聚：如果一個模組完成的任務在邏輯上屬於相同或相似的一類，則稱為邏輯內聚。
時間內聚：如果一個模組包含的任務必須在同一段時間內執行，就叫時間內聚
過程內聚：如果一個模組內的處理元素是相關的，而且必須以特定次序執行，則稱為過程內聚。
通訊內聚：如果模組中所有元素都使用同一個輸入資料和(或)產生同一個輸出資料，則稱為通訊內聚
順序內聚：如果一個模組內的處理元素和同一個功能密切相關，而且這些處理必須順序執行(通常一個處理元素的輸出資料作為下一個處理元素的輸入資料)，則稱為順序內聚。
功能內聚：如果模組內所有處理元素屬於一個整體，完成一個單一的功能，則稱為功能內聚。功能內聚是最高程度的內聚
好的設計應該具有如下三個特點
設計必須實現在分析模型中包含的所有明確要求，必須滿足客戶所期望的所有隱含要求；
設計必須對編碼人員、測試人員及後續的維護人員是可讀可理解的；
設計應提供該軟體的完整檢視，從實現的角度解決資料、功能及行為等各領域方面的問題
設計相關概念：
抽象
體系結構，軟體的整體結構和這種結構為系統提供概念上完整性的方式
設計模式，在給定上下文環境中一類共同問題的共同解決方案
模組化，軟體被劃分為命名和功能相對獨立的多個元件（通常稱為模組），透過這些元件的整合來滿足問題的需求
資訊隱藏，模組應該具有彼此相互隱藏的特性，即：模組定義和設計時應當保證模組內的資訊（過程和資料）不可以被不需要這些資訊的其他模組訪問
功能獨立，每個模組只負責需求中特定的子功能，並且從程式結構的其他部分看，該模組具有簡單的介面
精化，逐步求精的過程
重構，不改變元件功能和行為條件下，簡化元件設計（或程式碼）的一種重組技術
四類設計技術
資料設計（有時也被稱為資料架構）構建高層抽象（客戶/使用者的資料檢視）的資料模型、資訊模型體系結構設計
部署設計，部署環境包含整個解決方案的邏輯架構和服務質量（QoS）需求
介面設計（含介面設計）：允許使用者操作控制（使用者為中心），減少使用者記憶負擔，保持介面一致
元件設計：程序導向的元件設計-函式與模組的設計，物件導向的元件設計-類與操作的設計
變換分析
事務分析
混合結構分析：我們通常利用以變換分析為主、事務分析為輔的方式進行軟體結構設計
物件導向設計活動之一：架構設計
第1步：構造系統的物理模型
第2步：設計子系統
第3步：非功能需求設計
軟體測試策略
單元測試、系統測試、驗收測試
黑盒（等價類、邊界值）、白盒、條件覆蓋、語句覆蓋、
軟體專案管理的定義
是為了使軟體專案能夠按照預定的成本、進度、質量順利完成，而對人員（People）、產品（Product）、過程（Process）和專案(Project)進行分析和管理的活動。
4P要素：人員、產品、過程、專案
軟體逆向工程Software Reverse Engineering
是分析目標系統，識別系統的構件及其互動關係，並且透過高層抽象或其他形式來展現目標系統的過程
對逆向工程而言，抽象的層次、完備性、工具與分析人員協同工作的程度、過程的方向性等因素是需要考慮的