第四章 Maturity Level 3: Managed Process Areas

1. 第四章Maturity Level 3:Managed Process Areas 南台科技大學 資管系陳炳文、吳敏南 編

2. Table of Contents • 需求發展(RD) • 技術解決方案(TS) • 產品整合(PI) • 驗證(VER) • 確認(VAL) • 組織流程專注(OPF) • 組織流程定義(OPD)

3. Table of Contents (2) • 組織訓練(OT) • 整合的專案管理(IPM) • 風險管理(RSKM) • 整合團隊合作(IT) • 整合的供應商管理(ISM) • 決策分析與解決方案(DAR) • 適於整合之組織環境(OEI) • Q&A

4. 需求發展Requirement Development

5. 需求發展(RD) 目的 • 需求發展的目的，在於產出並分析客戶、產品及產品組件的需求。

6. Where Does RD Stand?

7. Why is RD Important? • Produce and analyze customer, product, and product component requirements. • RD Includes customer requirements rather than only product-level requirements • Customer may also provide specific design requirements • Product/Product Component requirement • Refined from customer requirements • Derived from design solution

8. 需求發展(RD) • 特定目標(specific goal, SG) • SG 1 發展客戶需求 • SG 2發展產品需求 • SG 3分析並確認需求

9. SG 1 發展客戶需求 • 蒐集關鍵人員(例如：客戶、最終使用者、供應商、建置人員及測試人員)的需要、期望、限制及介面，並轉換成客戶需求。

10. SG 1 發展客戶需求 • 特定執行方法(specific practice, SP) • SP 1.1 誘導需要 • SP 1.2 發展客戶需求

11. RD Context of SG1

12. SP 1.1 誘導需要 • 誘導關鍵人員提出有關產品生命週期各階段的需要、期望、限制及介面。

13. SP 1.1 誘導需要 (2) • 細部執行方法 • 與相關的關鍵人員一起參與，並使用方法，以誘導出需求、期望、限制及外部介面。

14. SP 1.1 誘導需要 (3) • 誘導需要的技術，舉例如下： • 技術展示 • 介面管制工作組 • 技術管制工作組 • 中間時期的專案審查 • 由最終使用者取得的問卷、訪談及操作劇本等資料 • 操作性的逐步審查和最終使用者的工作分析 • 雛型和模型 • 腦力激盪 • 品質機能展開 • 市場調查 • 試用版本的試用 • 由文件、標準或規格等來源中抽取 • 觀察現行產品、環境及工作流程的樣式(patterns) • 使用案例(use cases) • 經營案例分析 • 採取反向工程(針對現有產品)

15. Working with Difficult Customers • Protect yourself! • Manage the risk of the customer-supplier interface. • Document commitments both ways: • Communicate. • Manage expectations so there are no surprises. • Be willing to teach… and ready to learn: • If your “partner” is not willing to listen, be prepared to fine a new “partner” (or be ready to live with the consequences).

16. SP 1.2 發展客戶需求 • 轉換關鍵人員的需要、期望、限制及介面為客戶需求。

17. SP 1.2 發展客戶需求 (2) • 典型的工作產品 • 1. 客戶需求 • 2. 執行驗證 (verification)時的客戶限制 • 3. 執行確認(validation)時的客戶限制 • 細部執行方法 • 1. 轉換關鍵人員的需要、預期、限制及介面，成為客戶需求紀錄。 • 2. 定義驗證及確認時的限制。

18. SG 2 發展產品需求 • 調修並詳細說明客戶需求，以發展產品及產品組件需求。

19. SG 2 發展產品需求 • 特定執行方法(specific practice, SP) • SP 2.1 建立產品與產品組件需求 • SP 2.2 配置產品組件需求 • SP 2.3 界定介面需求

20. RD Context of SG2

21. SP 2.1 建立產品與產品組件需求 • 以客戶需求為基礎，建立並維護產品與產品組件的需求

22. SP 2.1 建立產品與產品組件需求 (2) • 典型的工作產品 • 1. 衍生需求 • 2. 產品需求 • 3. 產品組件需求 • 細部執行方法 • 1. 以專業術語發展產品與產品組件設計的需求。 • 2. 由設計決策衍生需求。 • 3. 建立並維護需求間的關連性，以提供變更管理和需求配置時影響的考量依據。

23. SP 2.2 配置產品組件需求 • 配置產品組件需求。

24. SP 2.2 配置產品組件需求 (2) • 典型的工作產品 • 1. 需求配置表 • 2. 暫時性的需求配置 • 3. 設計限制 • 4. 衍生需求 • 5. 衍生需求間的關係 • 細部執行方法 • 1. 配置需求於功能。 • 2. 配置需求於產品組件。 • 3. 配置設計限制於產品組件。 • 4. 記錄已配置需求間的關係。

25. 衍生需求 (Derived Requirements) • Derived requirements (Not in the customer requirements) – consideration the following: • Requirements that are not explicitly stated in the customer requirements. • From contextual requirements – e.g. applicable standards, law, policies, common practices and management decision. • From requirements needed to specify a product component. Derived requirements can also arise during analysis and design of components of product or system.

26. SP 2.3 界定介面需求 • 界定介面需求。

27. SP 2.3 界定介面需求 (2) • 典型的工作產品 • 介面需求 • 細部執行方法 • 1. 界定產品外部及內部的介面，例如：功能分割或物件之間的介面。 • 2. 發展已界定介面的需求。

28. SG 3 分析並確認需求 • 分析並確認需求，並發展所要功能的定義。

29. SG 3 分析並確認需求 • 特定執行方法(specific practice, SP) • SP 3.1 建立操作概念及劇本 • SP 3.2 建立必要功能的定義 • SP 3.3 分析需求 • SP 3.4 分析需求以取得平衡 • SP 3.5 用廣泛的方法確認需求

30. RD Context of SG3

31. SP 3.1 建立操作概念及劇本 • 建立並維護操作概念及其相關的劇本。

32. SP 3.1 建立操作概念及劇本 (2) • 典型的工作產品 • 1. 操作概念 • 2. 產品安裝、操作、維護及支援概念 • 3. 銷毀概念 • 4. 使用個案 (use cases) • 5. 依時間演化的劇本 • 6. 新需求 • 細部執行方法 • 1. 發展操作概念和劇本，包括適當的功能、績效、維護、支援及銷毀。 • 2. 定義產品的操作環境，包括界限和限制。 • 3. 審查操作概念和劇本，以調修需求並發現新需求。 • 4. 產品與產品組件一經選定，就發展詳細的操作概念，以定義產品、最終使用者及環境之互動，並滿足操作、維護、支援及銷毀的需要。

33. SP 3.2 建立必要功能的定義 • 建立並維護必要的功能定義。

34. SP 3.2 建立必要功能的定義 (2) • 典型的工作產品 • 1. 功能架構 • 2. 活動圖和使用個案 • 3. 物件導向分析和已界定的服務 • 細部執行方法 • 1. 分析和量化最終使用者需要的功能。 • 2. 分析需求，以界定邏輯或功能分割(如子功能)。 • 3. 依已建立的準則(如類似的功能、績效或耦合)，將需求分割成群組，以促進和專注於需求分析。 • 4. 在產品發展的整個過程，考量具有時效性之功能的順序。 • 5. 配置客戶需求於功能分割、物件、人員或支援元件，以支援解決方案的整合。 • 6. 配置功能需求及績效需求於功能及子功能。

35. SP 3.3 分析需求 • 分析需求，以確保其必要性(necessary)和充分性(sufficient)。

36. SP 3.3 分析需求 (2) • 典型的工作產品 • 1. 需求缺失報告 • 2. 用來解決缺失的需求變更建議 • 3. 關鍵需求 • 4. 技術績效度量 • 細部執行方法 • 1. 分析關鍵人員的需要、期望、限制及外部介面，以移除矛盾，並彙整成相關主題。 • 2. 分析衍生需求，以決定是否滿足更高階需求的目標。 • 3. 分析需求，以確保是完整、可行、可實現及可驗證的。 • 4. 界定對成本、時程、功能、風險或績效有重大影響的關鍵需求。 • 5. 界定技術績效度量，以便於發展階段時進行追蹤。 • 6. 分析操作概念及劇本，以調修客戶需要、限制及介面，並發現新需求。

37. SP 3.4 分析需求以取得平衡 • 分析需求，並在關鍵人員的需要和限制間取得平衡。

38. SP 3.4 分析需求以取得平衡 (2) • 典型的工作產品 • 需求相關風險的評量 • 細部執行方法 • 1. 使用經驗證的模型、模擬及雛型等，以分析關鍵人員之需要和限制間的平衡。 • 2. 執行需求及功能架構的風險評量。 • 3. 檢查產品生命週期概念，以分析它對需求風險的影響或衝擊。

39. SP 3.5 用廣泛的方法確認需求 • 使用多種適用的技術來確認需求，以確保在使用者環境下，最終產品如預期的運作。

40. SP 3.5 用廣泛的方法確認需求 (2) • 典型的工作產品 • 分析方法和結果的紀錄 • 細部執行方法 • 1. 分析需求以界定最終產品不能於使用者環境下適當運作的風險。 • 2. 以產品展示(如，雛型、模擬、模型、劇本及場景)，以及取得相關關鍵人員的回饋，尋求需求的足夠性和完整性。 • 3. 於設計成熟時，在需求確認環境下進行設計的評量，以界定確認議題，並揭露未敘明的需要和客戶需求。

41. GG3 制度化已定義流程 • 將流程制度化為已定義流程。 • 需求發展屬於成熟度第三評等，因此GG3是必要的。

42. GG3 制度化已定義流程 (2) • 一般執行方法(generic practice, GP) • GP 2.1 (CO 1) 建立組織政策 • GP 3.1 (AB 1) 建立已定義流程 • GP 2.2 (AB 2) 規劃流程 • GP 2.3 (AB 3) 提供資源 • GP 2.4 (AB 4) 指派責任 • GP 2.5 (AB 5) 訓練人員 • GP 2.6 (DI 1) 管理建構 • GP 2.7 (DI 2) 界定並納入相關的關鍵人員 • GP 2.8 (DI 3) 監控流程 • GP 3.2 (DI 4) 蒐集改善資訊 • GP 2.9 (VE 1) 客觀評估遵循程度 • GP 2.10 (VE 2) 與上層管理人員審查各狀況 • 各GP的詳細內請參看CMMI手冊。

43. 其他相關流程領域 • RM (Requirement Management) • managing customers and product requirement, obtaining the agreement with the requirements providers, commitments with stakeholder, maintaining traceability • TS (Technical Solution) • outputs of requirements are used, development of alternatives solution and design used in refining and deriving requirements • PI (Product Integration) • interface requirements and interface management • VER (Verification) • verify resulting product meet the requirements • VAL (Validation) • validated against the customer needs • CM (Configuration Management) • ensure that key work products are controlled and managed • Risk M (Risk Management) • managed risk that are related requirements

44. Requirements TS PI REQM RD Product & product component requirements Alternativesolutions Productcomponents Ver Val Product Customer Require-ments Product components, work products, verification and validation reports Customer needs 與其他工程類流程領域之關係 RD: Requirements Development TS: Technical Solution PI: Product Integration Ver: Verification Val: Validation

45. 技術解決方案Technical Solution

46. 技術解決方案(TS) • 目的 • 技術解決方案的目的，在於設計、發展及實作需求的解決方案。解決方案、設計結果及實作成品包括產品、產品組件，以及與產品相關生命週期的單一流程或適當組合的流程。

47. 技術解決方案(TS) • SG 1 選擇產品組件解決方案 • 從備選解決方案中，選擇產品或產品組件解決方案。 • SG 2 發展設計 • 發展產品或產品組件的設計。 • SG 3 實作產品設計 • 依照設計實作產品組件及相關的支援文件。

48. SG 1 選擇產品組件解決方案 • SP 1.1 發展詳細的備選解決方案及評選準則 • 發展詳細的備選解決方案及評選準則 • SP 1.2 漸進發展操作概念及劇本 • 漸進發展操作概念、劇本及環境，以描述每一個產品組件之條件、操作方式及操作狀態 • SP 1.3 選擇產品組件解決方案 • 選擇最能滿足所建立準則之產品組件解決方案

49. SP 1.1 發展詳細的備選解決方案及評選準則 • 典型的工作產品 • 1. 備選解決方案篩選準則 • 2. 新技術的評估 • 3. 備選解決方案 • 4. 最終選擇的評選準則 • 細部執行方法 • 1. 界定篩選準則，以作為選擇備選解決方案的考量因素 • 2. 界定現有技術與具競爭優勢的新產品技術 • 3. 產生備選方案 • 4. 取得每一備選解決方案的完整需求配置。 • 5. 發展選擇最佳備選解決方案的準則。 • 6. 為每一備選解決方案發展產品操作及使用者互動之依時間演化的劇本。

50. SP 1.2 漸進發展操作概念及劇本 • 典型的工作產品 • 1. 產品組件操作概念、劇本，以及與所有產品相關的生命週期流程(例如：操作、支援、訓練、製造、部署、現場、交付及廢棄)的環境 • 2. 產品組件互動的時序分析 • 3. 使用案例 • 細部執行方法 • 1. 漸進發展操作概念及劇本至適合產品組件發展的詳細程度 • 2. 漸進發展產品組件的操作環境