軟體過程

1. 軟體描述->軟體開發->軟體有效性驗證->軟體進化
2. 基本要素：方法、工具、過程

正式技術評審的目標：發現軟體中的錯誤

模組型別

1. 傳入：下屬模組資料傳給上級模組
2. 傳出：上級模組資料傳給下屬模組
3. 變換：上級模組的資料轉換形式後再傳回給上級模組
4. 協調：對所有下屬模組協調和管理

注意區分上級模組和下屬模組

成熟度

CMM 5個：

1. 初始：制度缺乏，無序
2. 可重複：基本管理制度，可跟蹤，可重複同類項目
3. 已定義：文件化、標準化、可按需改進
4. 已管理：詳細度量標準，有定量的理解和控制
5. 優化：持續改進

CMMI 6個：（0-5）

　　0.未完成：未執行

　　1.已執行：可標識的輸入輸出，關注於過程域的特定目標

　　2.已管理：過程制度化，監控，控制，評審

　　3.已定義：關注過程的組織和部署

　　4.量化：定量管理

　　5.優化：優化，持續得到改進

軟體過程模型

1. 瀑布：
   1. 優點：易理解，管理成本低　　
   2. 缺點：必須需求明確，不適合大型軟體，風控弱，已延期和超出預算
2. 增量：瀑布+原型，優先滿足核心需求及功能，再在基本需求上不斷優化、完善及補充，確定性比原型高
3. 演化：（迭代，需求缺乏準確認知）
   1. 原型：(規模不大，不太複雜）
      1. 快速構造部分需求
      2. 水平：導航，主要用在介面上
      3. 垂直：主要用在演算法上
      4. 拋棄式：解決需求不確定、不完整
      5. 演化式：增量式，易於升級和優化，適合Web
   螺旋
   ：（規模龐大，複雜，高風險）
   1. 瀑布+演化
   2. 制定計劃+風險分析+實施工程+客戶評估
   3. 強調風險分析
4. 噴泉：
   1. 迭代+無間隙
   2. 不利於專案管理和稽核
5. UP模型（統一過程）

1. 1. 用例和風險驅動，架構為中心
   2. 迭代+增量
   3. 4個階段：起始、精華、構建、移交
   4. 5個工作流：需求、分析、設計、實現、測試

敏捷方法

1. 極限程式設計：
   1. 輕量、高效、低風險、柔性、可預測、科學
   2. 4大價值觀+5個原則+12個最佳實踐+行為
      1. 4大價值觀：溝通、簡單、反饋、勇氣
      2. 5個原則：快速反饋、簡單假設、逐步修改、提倡更改、優質工作
      3. 12個最佳實踐：計劃遊戲、小型釋出、隱喻、簡單設計、重構、結隊程式設計、集體程式碼所有制、持續整合、每週40小時、現場客戶、編碼標準
2. 水晶法
   ：不同專案不同策略、約定和方法論
3. 並列爭球法：迭代+衝刺
4. 自適應軟體開發：猜測+合作+學習
5. 開放式：虛擬團隊，開發不在同一處
6. FDD驅動：開發人員分類。指揮者+類程式設計師

需求分析->系統設計->系統測試->執行和維護

需求分析

1. 獲取
2. 分析與協商：超綱、優先順序、衝突
3. 系統建模：結構化分析（SA）：資料流圖(DFD)、資料字典(DD)，面向物件分析（OOA）
4. 規約：分析任務的最終產物
   1. 引言
   2. 資訊描述
   3. 功能描述
   4. 行為描述
   5. 檢驗標準
   6. 參考書目
   7. 附錄
5. 驗證：
   1. 複查：正確性+完整性+清晰性
   2. 評審：目標一致、資料齊全、資料重組、主要功能在範圍內、符合約束條件、技術風險、檢驗標準
6. 管理：
   1. 建立跟蹤：正向+逆向
   2. 確保使用者需求

系統設計

1. 設計方法：結構化設計（SD）面向物件設計（OOD）
2. 概要設計：
   1. 總體結構
   2. 資料結構與資料庫：概念->邏輯->物理
   3. 編寫設計文件
   4. 評審
3. 詳細設計：
   1. 模組和演算法
   2. 模組內資料結構
   3. 程式碼+輸入輸出格式+介面
   4. 詳細設計說明書
   5. 評審　　　　　　

資料庫設計過程

1. 需求分析：資料+功能+效能
2. 概念結構設計：ER圖
3. 邏輯結構設計：ER圖轉換成表
4. 物理設計：儲存結構+存取路徑
5. 實施：程式設計+測試+試執行
6. 執行與維護：執行+日常維護

系統測試

原則：

1. 儘早開始
2. 避免開發或小組承擔（單元測試除外）
3. 不能窮舉
4. 重視群集
5. 嚴格按計劃，避免隨意

物件：程式+文件+資料，不包括開發人員

過程：計劃->大綱->用例+說明文件->實施->報告

策略：單元測試->整合測試->確認測試->系統測試

單元測試

1. 模組介面
2. 區域性資料結構
3. 模組內路勁
4. 邊界條件
5. 錯誤處理

整合測試

把所有模組組裝成一個系統測試

1. 非漸增式：先單元，再完整
2. 漸增式
   1. 自頂向下：先上層模組，再下層模組，需要樁模組，不需要驅動模組
   2. 自底向上：先下層模組，再上層模組，需要驅動模組，不需要樁模組
   3. 驅動模組：主程式，裝模組：模擬需要呼叫的模組
3. 迴歸測試：重新執行已測試過的子集，只包括主要程式功能
4. 冒煙測試：暴露影響構建的錯誤　　　　

確認測試

1. 進一步檢查軟體功能和效能
2. Alphea測試(開發者場所)和Beta測試（使用者場所）
3. 退化測試是用來防止改動產生的新錯誤

系統測試

1. 恢復
2. 安全
3. 壓力
4. 效能
5. 部署

白盒測試

1. 語句覆蓋：每個語句至少執行1次
2. 判定覆蓋：每種結果（分支）至少1次
3. 條件覆蓋：每個條件至少一次（不同的條件可能出相同的分支結果）
4. 判定/條件覆蓋：同時滿足判定覆蓋和條件覆蓋
5. 路徑覆蓋：每條執行到的路徑至少1次

使用判定表看出條件取值的組合

除錯

1. 測試之後，開發人員進行
2. 方法：試探、回溯、對分查詢、歸納、演繹

執行和維護(生命週期最長）

新舊轉換

1. 直接轉換
2. 並行準換
3. 分段轉換
4. 執行新系統過程：初始->推廣->控制->整合->管理

維護

1. 指標：可理解、可測試、可修改
2. 文件：使用者文件、系統文件
3. 型別：硬體、軟體
4. 內容：
   1. 軟體：正確性、適應性、完善性(在使用或執行中新增的需求)、預防性
   2. 資料：安全性、完整性、併發性
   3. 程式碼
5. 管理：提出修改->領導審查答覆->領導分配任務->驗收+登記
6. 工具：
   
   1. 版本控制
   2. 文件分析
   3. 開發資訊庫
   4. 逆向工程
   5. 再工程

評價

1. 立項：規劃階段
2. 中期：實施過程中，里程碑式
3. 結項：正式執行後
4. 內容：
   1. 需求：目標
   2. 規格說明：所有分析和測量，表示軟體部件
   3. 記錄：執行計劃時詳細記載
   4. 報告：執行測量和分析的結果，能重複及重新評價

專案管理

範圍（4P）

1. 人員：專案管理、高階管理、開發、客戶、使用者
2. 產品：環境、目標、功能+效能
3. 過程
4. 專案
5. 輸入：
   1. 專案章程
   2. 專案範圍管理計劃
   3. 組織過程資產
   4. 批准的變更申請

估算模型

COCOMO（靜態）

1. 基本：靜態單變數，只有LOC（原始碼行數）
2. 中級：基本+產品、硬體、人員專案等因素
3. 詳細：中級+分析、設計各步驟的影響
4. COCOMO II：物件點、功能點、程式碼行

Putnam（動態）

進度

1. 基本原則：劃分、相互依賴、實踐分配、工作量確認、確定責任、明確輸出、里程碑
2. 安排：Gantt圖、Pert圖
   1. Pert圖不能描述並行關係
   2. Gant圖不能描述依賴關係

組織

1. 基本原則：儘早落實、減少交流介面、責權均衡
2. 模式：專案劃分、職能劃分（專項組）、矩陣（專案+職能）

配置管理（SCM）

基線、配置項、版本控制、變更控制

配置項

1. 產品組成部分的工作成果：需求文件、設計文件、原始碼、測試用例
2. 專案管理和機構支撐過程產生的文件：工作計劃、專案質量報告、專案跟蹤報告

裝置清單不屬於配置項

風險管理

1. 識別：效能、成本、支援、進度
2. 預測：建立標準->描述後果->估算影響->標註精度
3. 評估：RE=P x C，P：發生概率，C：成本
4. 控制：避免、監控、RMMM計劃

軟體質量

1. 內部、外部、使用
2. 滿足規定或潛在使用者需求的能力

工具

特徵：

1. 覆蓋整個軟體週期
2. 為專案排程提供多種手段
3. 估算模型進行估算
4. 支援多專案和子專案管理
5. 確定關鍵路徑、鬆弛時間、超前實踐、滯後時間
6. 成語與任務間的通訊輔助
7. 資源平衡
8. 跟蹤資源使用
9. 生成固定格式的報表和報告

不具備指導性作用　

補充

冗餘附加技術：

1. 備份程式的儲存及呼叫（不是關鍵程式）
2. 糾錯檢測及恢復
3. 容錯固化　　

環路複雜性（McCabe）

　　V(G)=E-N+2，E:邊數，N:節點數

開發方法

1. 原型法：需求不清晰+多變
2. 結構化法：規模不大+不復雜+不多變
3. Jackson法：以資料結構驅動+規模小

------------------------------------------------------------------------------------------

模組劃分原則：

1. 大小適中
2. 扇入扇出合理
   1. 扇出大=複雜度高，扇入大=複用度高
   2. 頂層扇出大，中間刪除較少，底層扇入大
   3. 一般扇入扇出係數在3或4，不超過7
3. 深度寬度合理　　

完善模組不能改進設計質量

體系結構風格

1. 倉庫風格：
   1. 優點：多方法、可更改、可維護、可重用、支援容錯和健壯
   2. 缺點：測試困難、選擇太多、效率低、成本高、缺少並行支援
   3. 包括：資料庫系統、黑板系統、超文本系統

資料倉庫

1. OLAP：針對聯機資料訪問與分析，通過多維的方式對資料進行分析、查詢和報表

UML圖

1. 用例圖：描述參與者必須要完成的任務
2. 類圖：類名、介面、屬性、操作、關係：依賴，泛化，關聯
3. 物件圖：物件:型別
4. 狀態圖：狀態詞（動名詞）+動作
5. 包圖：資料夾
6. 活動圖：有開始有結束
7. 構件圖：介面+依賴
8. 製品圖：系統的物理結構，常與部署圖一起使用
9. 組合結構圖：描述類的內部結構
10. 部署圖：立方體+<<artifact>>
11. 互動圖：
    1. 序列圖：生命線+控制焦點（像川字）
    2. 通訊圖：路勁+順序號
    3. 互動概覽圖：活動圖+順序圖
    4. 計時圖：任務物件的生命線，強調訊息實際時間以及相對順序