第三章 Maturity Level 2: Managed Process Areas

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

2. Table of Contents • 需求管理(REQM) • 專案規劃(PP) • 專案監控(PMC) • 供應商協議管理(SAM) • 度量與分析(MA) • 流程與產品品質保證(PPQA) • 建構管理(CM) • Q&A

3. Supplier SupplierAgreementManagement RequirementsManagement ProjectPlanning Project Monitoring andControl Configuration Management Process and Product Quality Assurance Measurement and Analysis Maturity Level 2 PAs Development Project Customer

4. 需求管理Requirement Management

5. 需求管理(REQM) • 目的 • 需求管理的目的，在於管理專案產品及產品元件的需求，並界定(identify)這些需求與專案計畫及工作產品間的差異(inconsistencies)。

6. Requirements Must be Documented • Simple as a memo • Elaborate as multi-volume specifications • All changes must be documented, tracked, and verified throughout the life cycle of the system.

7. Barriers to REQM • Requirements constantly change. • Requirements are changed without appropriate coordination approval. • Customers do not always recognize the need to document the requirements. • Responsibility for Requirements Management is not clearly established.

8. Where Does REQM Stand?

9. Why Is REQM Important? • Requirements management processes manage the requirements of a project to ensure that • The correct requirements are identified and the inconsistencies between the requirements and the project plans and work product are resolved. • Bidirectional traceability between the requirements and the product/product component are maintained. • Any changes to the requirements are documented and the impact to the project are assessed.

10. What Are the Benefits of REQM? • Agreement reached from requirements provider and receiver to ensure that the correct requirements are incorporated into the project plan. • Requirement changes are effectively managed thru defined process. Traceability maintained between the requirements and the product facilitate the impact evaluation of changes as well as the verification of work-product. • Requirements baseline are established as the basis for further product component requirements development.

11. SG 1 管理需求 • 管理需求，並界定需求與專案計畫及工作產品間之差異 • 藉由進行下列活動，使專案能全程維護一組最新及已核定的需求： • 管理所有的需求變更。 • 維護需求、專案計畫及工作產品間的關係。 • 界定需求、專案計畫及工作產品間的差異。 • 採取矯正措施。

12. SG 1 管理需求 (2) • 特定執行方法(specific practice, SP) • SP 1.1 瞭解需求 • SP 1.2 取得需求承諾 • SP 1.3 管理需求變更 • SP 1.4 維護需求的雙向追溯性 • SP 1.5 界定專案工作與需求間的差異

13. REQM Context

14. SP 1.1 瞭解需求 • 瞭解需求 • 與需求提供者一起瞭解需求之意義

15. SP 1.1 瞭解需求 (2) • 典型的工作產品 • 1. 區別適當需求提供者的準則清單 • 2. 需求評估和接受準則 • 3. 依準則進行分析的結果 • 4. 經議定的需求 • 細部執行方法 • 1. 建立區別適當需求提供者的準則清單。 • 2. 建立客觀的需求接受準則。 • 3. 分析需求，以確保其符合已建立之準則的要求。 • 4. 與需求提供者達成需求共識，使專案成員可對需求承諾。

16. SP 1.1 瞭解需求 (3) • 需求接受準則，舉例如下： • 􀁹清晰而適當地表達 • 􀁹完整 • 􀁹相互的一致性 • 􀁹可個別界定 • 􀁹可適當地實作 • 􀁹可驗證(可測試) • 􀁹可追溯

17. SP 1.1 瞭解需求 (4) • 需求提供準則: • 專案成員應與需求提供者充分溝通，正確瞭解需求之意義，並與需求提供者達成共識。對需求的瞭解應足以進行系統發展，以滿足客戶需求。

18. SP 1.2 取得需求承諾 • 取得需求承諾 • 取得專案成員對需求的承諾

19. SP 1.2 取得需求承諾 (2) • 典型的工作產品 • 1. 需求影響評量 • 2. 需求和需求變更承諾的紀錄 • 細部執行方法 • 1. 評量需求對現有承諾的影響。需求變更或新需求發生時，評估其對專案成員的影響。 • 2. 協商並記錄承諾。在專案成員對需求或需求改變承諾之前，對現有承諾的改變，應先協商。

20. SP 1.3 管理需求變更 • 管理需求變更 • 當需求於專案執行期間漸進發展時，管理需求的變更

21. SP 1.3 管理需求變更 (2) • 典型的工作產品 • 1. 需求狀況表 • 2. 需求資料庫 • 3. 需求決策資料庫 • 細部執行方法 • 1. 記錄所有的需求和需求變更，不論是專案本身產生的或外界的要求。 • 2. 維護需求變更紀錄，以及每次變更的理由。維護變更的歷史紀錄，有助於追蹤需求變更的狀況。 • 3. 從相關關鍵人員的觀點，評估需求變更的影響。 • 4. 使專案能取得需求和變更的資料。

22. SP 1.4 維護需求的雙向追溯性 • 維護需求的雙向追溯性 • 維護需求與專案計畫及工作產品間的雙向追溯性

23. SP 1.4 維護需求的雙向追溯性 (2) • 典型的工作產品 • 1. 需求追溯表 • 2. 需求追蹤系統 • 細部執行方法 • 1. 維護需求追溯性，以確保已記錄低階(或衍生)需求的來源。 • 2. 維護需求追溯性，從需求到衍生需求，以及需求所配置的功能、物件、人員、流程及工作產品。 • 3. 維護水平追溯性，包括從功能到功能，以及跨介面的追溯。 • 4. 製作需求追溯表 (Traceability Matrix)。

24. 追溯性 • Horizontal traceability • functions to functions and across interfaces. • Vertical (bidirectional) traceability • life cycle phases – design, software modules, testing,…

25. 需求追溯表Requirements vs. Requirements

26. 需求追溯表 (2)Requirements vs. Components

27. SP 1.5 界定專案工作與需求間的差異 • 界定專案工作與需求間的差異 • 界定需求與專案計畫及工作產品間的差異(inconsistencies)

28. SP 1.5 界定專案工作與需求間的差異 (2) • 典型的工作產品 • 1. 差異紀錄，包括差異來源、條件及理由 • 2. 矯正措施(corrective actions) • 細部執行方法 • 1. 審查專案計畫、活動及工作產品，是否與需求及需求變更相符。 • 2. 界定差異來源及其理由。 • 3. 當需求基準有變動時，界定有關計畫及工作產品所需的變更。 • 4. 啟動矯正措施。

29. 其他相關流程領域 • RD (Requirements Development) • transforming stakeholder needs into product requirements • TS (Technical Solution) • the requirements processes are used, development of alternative solutions . Transforming requirements into technical solutions • PP (Project Planning) • How project planning reflect requirements and revise change as requirements change • PMC (Project Monitoring and Control) • Tracking and controlling project activities related to requirements and taking appropriate corrective actions • RM (Risk Management) • identifying and handling risks associated with requirements. • CM (Configuration Management) • baselines and controlling changes to configuration documention for requirements.

30. 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

31. Importance • There is a stable environment for managing the project. • Inconsistencies between those requirements and the project’s plans and work products are identified and resolved. • Building to the correct requirements. • You can assess which requirements and product components are affected by a proposed change. • Unnecessary rework are eliminated. • Traceability – evaluating impact of change, in work product verification, , keep requirements and project work in synchronization.

32. Process Compliance Customer Satisfaction Time ….. Project begins Project closed • Establish • Customer/Product Req., • Acceptance Criteria, • Horizontal Traceability, • Vertical Traceability • Commitment , Baselines of SRS • Project REQM Person : • Customer Requirements Validation • Project REQM Person : • Requirement Change Procedures • Vertical Traceability • Requirements and Work Product Consistency REQM in Project

33. GG 2 制度化已管理流程 • 將流程制度化為已管理流程。 • 對於成熟度第二級評等而言，GG2是必要的，且其執行方法也是預期的。

34. GG 2 制度化已管理流程 (2) • 一般執行方法(generic practice, GP) • GP 2.1 (CO 1) 建立組織政策 • GP 2.2 (AB 1) 規劃流程 • GP 2.3 (AB 2) 提供資源 • GP 2.4 (AB 3) 指派責任 • GP 2.5 (AB 4) 訓練人員 • GP 2.6 (DI 1) 管理建構 • GP 2.7 (DI 2) 界定並納入相關的關鍵人員 • GP 2.8 (DI 3) 監控流程 • GP 2.9 (VE 1) 客觀評估遵循程度 • GP 2.10 (VE 2) 與上層管理人員審查各狀況

35. GP 2.1 建立組織政策 • 建立並維護組織政策，以規劃和執行需求管理流程。 • 本政策建立組織對下列活動的期望：管理需求，以及界定需求與專案計畫及工作產品間的差異。

36. GP 2.2 規劃流程 • 建立並維護執行需求管理流程的計畫。 • 執行需求管理的計畫通常是專案計畫的一部分，專案計畫在專案規劃流程領域中說明。

37. GP 2.3 提供資源 • 提供充足的資源，以執行需求管理流程、發展工作產品及提供流程服務。 • 可用於本流程領域的資源(工具)，舉例如下： • 需求追蹤工具 • 追溯工具

38. GP 2.4 指派責任 • 指派需求管理流程的責任與授權，以執行流程、發展工作產品及提供流程服務。

39. GP 2.5 訓練人員 • 依需要訓練人員，以執行或支援需求管理流程。 • 訓練的主題，舉例如下： • 應用領域的專業知識 • 需求定義、分析、審查及管理 • 需求管理工具 • 建構管理 • 談判及衝突解決

40. GP 2.6 管理建構 • 將指定的需求管理流程工作產品，納入適當層級的建構管理。 • 納入建構管理的工作產品，舉例如下： • 需求 • 需求追溯表

41. GP 2.7 界定並納入相關的關鍵人員 • 依計畫界定並納入需求管理流程相關的關鍵人員。 • 從下列人員中選擇相關的關鍵人員：客戶、最終使用者、發展人員、製作人員、測試人員、供應商、市場行銷人員、維護人員、報廢處理人員，以及其他會影響產品及流程或受產品及流程所影響的人。

42. GP 2.7 界定並納入相關的關鍵人員(2) • 關鍵人員參與的活動，舉例如下： • 解決需求瞭解的議題 • 評量需求變更的影響 • 溝通雙向追溯性 • 界定專案計畫、工作產品及需求間的差異

43. GP 2.8 監控流程 • 依本流程的執行計畫，監控需求管理流程，並採取適當的矯正措施。 • 用於監控的度量，舉例如下： • 需求變動率(即需求變更的百分比)

44. GP 2.9 客觀評估遵循程度 • 依本流程的說明、標準及程序，客觀評估需求管理流程的遵循程度，並解決不符合議題。 • 審查的活動，舉例如下： • 管理需求 • 界定專案計畫、工作產品及需求間的差異

45. GP 2.9客觀評估遵循程度 (2) • 審查的工作產品，舉例如下： • 需求 • 需求追溯表

46. GP 2.10 與上層管理人員審查各狀況 • 與上層管理人員審查需求管理流程的活動、狀況及結果，並解決議題。 • 針對組織外部承諾的變更建議，必須與上層管理人員審查，以確保所有的承諾可以完成。

47. GG 3 制度化已定義流程 • 將流程制度化為已定義流程。 • 對於成熟度第二級評等而言，GG3不是必要的，且其執行方法也不是預期的，但對於成熟度第三和更高級評等而言，GG3是必要的。

48. GG 3 制度化已定義流程 (2) • 一般執行方法(generic practice, GP) • GP 3.1 建立已定義流程 • GP 3.2 蒐集改善資訊

49. GP 3.1 建立已定義流程 • 建立並維護已定義的需求管理流程的說明。

50. GP 3.2 蒐集改善資訊 • 蒐集由規劃及執行需求管理流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。