軟件開發模型
- 瀑布模型（SDLC）：適用於需求明確或二次開發的項目
理想化的開發模型，要求有明確的需求分析，而要達到這一點在現實開發中幾乎不開能
結構化模型的代表，線性開發：軟件計劃→需求分析→軟件設計→程序編程→軟件測試→運行維護 - 原型模型：適用於需求不明確的項目
項目開發初期，構造一個軟件原型，通過調整原型使其滿足客戶要求，一旦確定真正需求，原型將被丟棄 - 演化模型：適用於對需求缺乏準確認識的項目
從初始的原型逐步演化成最終軟件產品 - 增量模型：適用於可以分批次地進行軟件產品交付的項目
將待開發的軟件系統模塊化，先做實現基本需求的核心模塊，交付用戶使用後，根據用戶需求不斷增量，調整，直到完善 - 螺旋模型：適用於大型複雜的項目
結合了瀑布和演化的優點，加入了風險分析
沿着螺線進行若干次迭代（制定計劃→風險分析→實施工程→客戶評估），從概念項目開始第一個螺旋 - 噴泉模型：適用於面向對象的軟件項目
面向對象的模型，以用戶需求爲動力，以對象爲驅動的模型，使開發具有迭代性和無間隙性 - V模型：適用於傳統信息系統應用的項目
強調了軟件開發過程中若干個測試級別
在需求分析的時候，寫驗收測試和系統測試，可以提早發現問題；
在概要設計的時候，寫集成測試的測試計劃；
在詳細設計的時候，寫單元測試的測試計劃 - 快速應用開發（RAD）：適用於系統模塊化程度較高的項目，不適合技術風險很高的情況
業務建模→數據建模→過程建模→應用生成→測試與交付 - 迭代模型：適用於需求難以確定，不斷變更的項目，採用迭代開發方法
- 構件組裝模型（CBSD）：
基於構件的開發方法，提高了軟件開發的複用性，可靠性強
需求分析和定義→軟件架構設計→構件庫的建立→應用軟件構建→測試和發佈 - 統一過程（UP）：適用於大型項目
用例驅動，以架構爲中心，迭代和增量
初始→細化→構建→交付 - 敏捷開發方法：適用於小型項目，是一種以人爲核心、迭代、循序漸進的開發方法
- 極限編程（XP）：一種輕量級的開發方法，激發開發人員創造性、使得管理負擔最小的一組技術
- 4大價值觀：溝通、簡單、反饋、勇氣
- 5大原則：快速反饋、簡單性假設、逐步修改、提倡更改、優質工作
- 12個最佳實踐：
- 計劃遊戲（快速制定計劃、隨着細節的不斷變化而完善）
- 小型發佈（系統的設計要能夠儘可能早地交付）
- 隱喻（找到合適的比喻傳達信息）
- 簡單設計（只處理當前的需求，使設計保持簡單）
- 測試現行（先寫測試代碼，然後再編寫程序）
- 重構（重新審視需求和設計，重新明確地描述它們以符合新的和現有的需求）
- 結隊編程
- 集體代碼所有制
- 持續集成（可以按日甚至按小時爲客戶提供可運行的版本）
- 每週工作40個小時
- 現場客戶
- 編碼標準
- 水晶法：強調經常交付，認爲每—個不同的項目都需要一套不同的策略、約定和方法論
- 並列爭球法：核心是迭代、增量交付，按照30天進行迭代開發交付可實際運行的軟件
- 使用迭代的方法，其中，把每30天一次的迭代稱爲一個“衝刺”， 並按需求的優先級來實現產品，多個自組織和自治的小組並行地遞增實現產品
- 自適應軟件開發：核心是三個非線性的，重迭的開發階段：猜測、合作、學習
- 6個基本原則：
- 有一個使命作爲指導；
- 特徵被視爲客戶價值的關鍵點；
- 過程中的等待是很重要的，因爲“重做”與“做”同樣關鍵；
- 變化不被視爲更改，而是被視爲對軟件開發實際情況的調整；
- 確定的交付時間迫使開發人員認真考慮每一個生產的版本的關鍵需求；
- 風險也包含其中
- 6個基本原則：
- 極限編程（XP）：一種輕量級的開發方法，激發開發人員創造性、使得管理負擔最小的一組技術
軟件開發方法
| 方法 | 特點 |
| 結構化開發方法 | 面向數據流的開發方法 總的指導思想是：自頂向下，逐層分解 基本原則是功能的分解與抽象 特別適合於數據處理領域的問題，但是不適合解決大規模的，特別複雜的項目，且難以適應需求的變化 |
| Jackson | 面向數據結構的開發方法 JSP以數據結構爲驅動，適合於小規模的項目。但輸入數據結構與輸出數據結構沒有對應關係時，這種方法難以勝任。 JSD以事實爲驅動，是一種基於進程的開發方法，所以適應於時序特點較強的系統，包括數據處理系統和一些實時控制系統 |
| 原型方法 |
適用於需求不明確的開發 包括拋棄式原型和演示化原型 當系統規模不是很大也不是很複雜時，採用此方法比較合適 |
| 面向對象方法 | 更好的複用性 關鍵在與建立一個全面、合理、統一的模型 分析、設計、實現三個階段，界限不明確 |
| 面向服務方法 |
SO方法有三個主要的抽象級別：操作、服務、業務流程 SOAD分爲三個層次：基礎設計層(底層服務構件)、應用結構層(服務之間的接口和服務級協定)和業務組織層(業務流程建模和服務流程編排) 服務建模：分爲服務發現、服務規約和服務實現三個階段 |
軟件測試
基礎知識
測試目標：以儘可能少的時間和人力發現軟件產品中儘可能多的錯誤
測試用例：由測試數據和預期結果構成
測試過程：制定測試計劃→編制測試大綱→生成測試用例→實施測試→生成測試報告
黑盒測試
黑盒測試又稱功能測試。它把軟件看做一個不透明的黑盒子，完全不考慮（或不瞭解）軟件的內部結構和處理算法，它只檢查軟件功能是否能按照軟件需求說明書的要求正常使用，軟件是否能適當地接收輸入數據併產生正確的輸出信息，軟件運行過程中能否保持外部信息（例如文件和數據庫）的完整性等。
常用的黑盒測試技術
- 等價類劃分：將所有可能的輸入數據，劃分爲若干子集，然後從每一個子集中選取少數具有代表性的數據作爲測試用例
- 邊界值分析：對等價類劃分的一個補充，即選取正好等於、剛剛大於或剛剛小於邊界的值作爲測試數據
- 錯誤猜測：列舉出軟件中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例
- 因果圖：根據輸入條件與輸出結果之間的因果關係來設計測試用例
白盒測試
已知產品的內部工作過程，通過測試證明每種內部操作是否符合設計規格要求（將軟件比做一個透明盒子，裏面的一切我們都看的清楚，可以通過測內部結構來判斷）
測試方法
基本路徑測試
循環覆蓋測試
邏輯覆蓋測試（由低到高）
語句覆蓋：冒泡排序只要一個用例就可以達到語句覆蓋
判定覆蓋
條件覆蓋
判定-條件覆蓋
條件組合覆蓋
路徑覆蓋：設計足夠的測試用例，覆蓋軟件中所有可能的路徑
使用 McCabe 度量法計算路徑複雜度：V(G)=m-n+2
其中V(G)是有向圖G中的環路個數，m是邊數，n是頂點數，一般用環路數V(G)來表示程序複雜性。
測試階段
- 單元測試（模塊測試）【白盒爲主，黑盒爲輔】
一般是在編程階段完成，由程序員自行測試編寫的模塊，檢查模塊是否實現了詳細設計說明書中規定的功能和算法
測試內容：模塊接口、局部數據結構、重要的執行通路、錯誤處理、邊界條件
驅動模塊：相當於所測模塊的主程序，它接收測試數據，把這些數據傳送給所測模塊，最後再輸出實際結果
樁模塊：用以代替所測模塊調用的子模塊 - 集成測試（組裝測試）【黑盒測試】
在單元測試的基礎上，將所有模塊按照概要設計說明書的要求進行組裝
測試目的：發現模塊間的接口和通信問題，發現設計階段產生的錯誤
一次性組裝方式：一次性組裝所有模塊進行測試
增量式組裝方式：將模塊逐步組裝成系統，有自頂向下（需要樁模塊）、自底向上、混合式 - 確認測試【黑盒測試】
檢查軟件的功能、性能和其他特徵是否與用戶的需求一致
測試步驟：有效性測試→軟件配置審查→驗收測試
Alpha測試：公司內部人員模擬各類用戶對即將面市的軟件產品進行測試，試圖發現錯誤並修正
Beta測試：由軟件的多個用戶在實際使用環境下進行的測試，這些用戶返回有關錯誤信息給開發者 - 系統測試【黑盒測試】
把軟件放在實際的硬件和網絡環境中進行測試，檢查軟件的非功能需求和質量屬性是否得到滿足
測試內容：恢復測試、安全性測試、強度測試、性能測試、可靠性測試、安裝測試
迴歸測試：修改了舊代碼後，重新測試，確認修改沒有引入其他錯誤或導致原有代碼錯誤
軟件維護
可維護性
易分析性：爲判定軟件修改所需的努力
易改變性：進行修改，適應環境變化所需的努力
穩定性 ：與修改造成的風險後果相關
易測試性：與確認修改所需的努力
提高可維護性
軟件開發各個階段都充分考慮維護問題
使用面向對象方法
結構化設計中注意模塊化、信息隱蔽、高內聚、低耦合等問題
編寫軟件開發文檔以及形成良好的編程風格
維護類型
改正性維護：修復錯誤（25%）
適應性維護：適應環境（20%)
完善性維護：增加功能，提高性能（50%)
預防性維護：爲以後增加功能準備(5%)
軟件過程改進
CMM
描述和分析了軟件過程能力的發展程度，確立了一個軟件過程成熟程度的分級標準
初始級→可重複級→已定義級→已管理級→優化級
| 等級 | 管理方面 | 組織方面 | 工程方面 |
| 優化級 | 技術改進管理 過程改進管理 |
缺陷預防 | |
| 已管理級 | 定量管理過程 | 軟件質量管理 | |
| 已定義級 | 集成軟件管理 組間協調 |
組織過程焦點 組織過程定義 培訓程序 |
軟件產品工程 同級評審 |
| 可重複級 | 需求管理 軟件項目計劃 軟件項目跟蹤與監控 軟件子合同管理 軟件質量保證 軟件配置管理 |
CMMI
繼承併發揚了CMM的優良特性，借鑑了其他模型的優點，融入了新的理論和實際研究成果
階段式→組織能力成熟度
| 成熟度等級 | 過程域 | |
| 已管理級 |
需求管理、項目計劃、配置管理、項目監督與控制、供應商合同管理、度量和分析、過程和產品質量保證 |
未完成的：過程域未執行或未得到CL1中定義的所有目標 已執行的：其共性目標是過程將可標識的輸入工作產品轉換成可標識的輸出工作產品，以實現支持過程域的特定目標 已管理的：其共性目標集中於已管理的過程的制度化 |
| 已定義級 |
需求開發、技術解決方案、產品集成、驗證、確認、組織級過程焦點、組織級過程定義、組織級培訓、集成項目管理、風險管理、集成化的團隊、決策分析和解決方案、組織級集成環境 |
其共性目標集中於已定義的過程制度化 |
| 定量管理級 | 組織級過程性能、定量項目管理 | 其共性目標集中於可定量管理的過程的制度化 |
| 優化級 | 組織級改革與實施、因果分析和解決方案 | 使用量化(統計學)手段改變和優化過程域，以滿足客戶要求的改變和持續改進計劃中的過程域的功效 |
連續式→軟件過程能力
| 連續式分組 | 過程域 |
| 過程管理 | 組織級過程焦點、組織級過程定義、組織級培訓、組織級過程性能、組織級改革與實施 |
| 項目管理 |
項目計劃、項目監督與控制、供應商合同管理、集成項目管理、風險管理、集成化的團隊、定量項目管理 |
| 工程 | 需求管理、需求開發、技術解決方案、產品集成、驗證、確認 |
| 支持 |
配置管理、度量和分析、過程和產品質量保證、決策分析和解決方案、組織級集成環境、因果分析和解決方案 |
項目管理
- 時間管理
- 風險管理
- 特性：不確定性、損失
- 風險的優先級通常是根據風險暴露設定（風險曝光度=發生的概率×造成的損失）
- 風險識別：通過建立風險條目檢查表，試圖系統化地確定對項目計劃的威脅
- 風險預測（風險估算）：從兩個方面評估一個風險：風險發生的可能性或概率；以及如果風險發生了所產生的後果
- 風險評估：定義風險參考水平值，預測影響參考水平值的風險組合
- 風險控制：輔助項目組建立處理風險的策略，有效的策略應考慮風險避免、風險監控、風險管理及意外事件計劃
- 風險避免即放棄或不進行可能帶來損失的活動或工作（主動）
- 風險監控是指在決策主體的運行過程中，對風險的發展與變化情況進行全程監督，並根據需要進行應對策略的調整
- 風險管理是指在一個肯定有風險的環境裏把風險減至最低的管理過程
- Gant圖（進度管理）
- 不能清晰地反映出各任務之間的依賴關係，難以確定整個項目的關鍵所在，也不能反映計劃中有潛力的部分
- 能清晰地描述每個任務從何時開始，到何時結束，任務的進展情況以及任務之間的並行關係
- Pert圖（活動）
- 不能清楚描述各任務之間的並行情況
- 能清晰的描述每個任務從何時開始，到何時結束，以及各任務之間的依賴關係
- 關鍵路徑＝圖中最長的路徑
- 鬆弛時間＝最遲開始時間－最早開始時間
- A-B-C-D-E：CD鬆弛時間=最遲時間（AE(max)-ED-DC）－最早時間（AB+BC）
軟件工具
開發工具
需求分析工具
設計工具
編碼與排錯工具
測試工具
維護工具
版本控制工具
文檔分析工具
開發信息庫工具
逆向工程工具
再工程工具：主要集中在代碼重構，程序結構重構和數據結構重構等
軟件調試
歸納法：是指從測試所暴露的問題出發，收集所有正確或不正確的數據，分析他們之間的關係，提出假想的錯誤原因，用這些數據來證明或反駁，從而查出錯誤所在。
試探法：調試人員分析錯誤的症狀，猜測問題所在的位置，利用在程序中設置輸出語句，分析寄存器，存儲器的內容等手段獲得錯誤的線索，一步步地試探和分析錯誤的所在。這種方法效率低，適合結構比較簡單的程序。
回溯法：調試人員從發現錯誤的位置開始，人工沿着程序的控制流程往回跟蹤代碼，直到找出錯誤根源爲止。這種方法適合於小型程序，對於大規模程序，由於其需要回溯的路徑太多而不可操作。
對分查找法：這種方法主要用於縮小錯誤範圍，如果已經知道程序中的變量在若干位置的正確取值，可以在這些位置上給這些變量以正確值，觀察程序運行的輸出結果，如果沒有發現問題，則說明賦予變量一個正確值開始到輸出結果之間程序沒有錯誤，問題可能在除此之外的程序中，否則錯誤就在所觀察的這部分程序中，對含有錯誤的程序段再使用這種方法，直接把故障範圍縮小到比較容易診斷爲止。
演繹法：根據測試結果，列出所有可能的錯誤；分析已有的數據，排除不可能和彼此矛盾的原因；對其餘的原因，選擇可能性最大的，利用已有的數據完善該假設，使假設更具體；用假設來解釋所有的原始測試結果，如果能解釋這一切，則假設得以證實，也就找出錯誤，否則，要麼是假設不完備或不成立，要麼有多個錯誤同時存在，需要重新分析，提出新的假設知道發現錯誤爲止
內聚類型（由高到底）
功能內聚：完成一個單一功能，各個部分協同工作，缺一不可
順序內聚：處理元素相關，而且必須順序執行
通信內聚：所有處理元素集中在一個數據結構的區域上
過程內聚：與處理元素相關，而且必須按特定的次序執行
瞬時內聚（時間內聚）：所包含的任務必須在同一時間間隔內執行（如初始化模塊）
邏輯內聚：完成邏輯上相關的一組任務
偶然內聚（巧合內聚）：完成一組沒有關係或鬆散關係的任務
耦合類型（由高到底）
內容耦合：當一個模塊直接修改或操作另一個模塊的數據或者直接轉入另一個模塊
公共耦合：兩個或多個模塊，通過引用一個公共區的數據（數據結構和變量）而發生作用
控制耦合：通過傳送開關、標誌、名字等控制信息，明顯地控制選擇另一模塊的功能
標記耦合：兩個模塊都只和一個數據結構有關，通過參數表傳遞記錄信息
數據耦合：通過參數傳遞簡單數據
外部耦合：通過全局變量，不是通過參數表
非直接耦合：模塊之間沒有直接關係，完全是通過主模塊的控制和調用來實現的，獨立性最強，耦合度最低
模塊劃分原則
模塊的大小要適中。
模塊的扇入和扇出要合理。
深度和寬度適當。