演講人：黃曉雯. 2 CMMI 介紹 CMMI 模式 CMMI 通過評鑑組織單位 CMMI 架構 CMMI 導入益處 CMMI 應用 3.

Presentation on theme: "演講人：黃曉雯. 2 CMMI 介紹 CMMI 模式 CMMI 通過評鑑組織單位 CMMI 架構 CMMI 導入益處 CMMI 應用 3."— Presentation transcript:

1 演講人：黃曉雯

2 2

3 CMMI 介紹 CMMI 模式 CMMI 通過評鑑組織單位 CMMI 架構 CMMI 導入益處 CMMI 應用 3

4 CMMI (Capability Maturity Model - Integrated) 能力成熟度模 型整合 是美國卡內基美隆大學 (Carnegie Mellon University) 的軟體工程學院 (Software Engineering Institute, SEI) 自 CMM 之後提出的修訂版本 CMM 的核心是將軟體開發視為一個「過程」，將這過程標準化，可 使得組織單位更好的實現目標 CMMI 的目的為發展出一個共通性的整合架構，以支援整 合不同專業領域的特定能力成熟度模式及相關產品 提供指導原則 促進流程改善 提升品質與生產力 4

5 美國卡內基美隆大學的軟體工程學院 SEI 提出三套流程模 式： CMMI-DEV ：針對系統研發提出研發管理流程 CMMI-ACQ ：針對採購商與供應商提出採購管理流程 CMMI-SVC ：針對服務維運提出管理流程 5

6 CMMI-DEV Maturity Level ( 成熟度等級 ) ： Level 1 ：初始級 (Initial) 没有固定的工作流程，仰賴組織成員的能力，缺點常會超過專案 的預算與時程 Level 2 ：管理級 (Managed) ，具備基礎專案與規劃管理能力 可確保專案流程是經過規劃、被記錄、已執行與控管的 6 －經濟部工業局 軟體價值產業推動計畫

7 CMMI-DEV Maturity Level ( 成熟度等級 ) ： Level 3 ：定義級 (Defined) ，標準化 整個組織所執行的流程說明和程序都是一致的 Level 4 ：量化管理級 (Quantitatively Managed) 針對專案品質與流程績效建立量化目標，並使用為管理專案的準 則 Level 5 ：最佳化級 (Optimizing) 持續流程改善，朝向學習型組織邁進 7

8 Level 2 曜發科技、立錡科技、富士康奇美、中國鋼鐵、廣達電腦、台灣富 士通、曜發科技、財政部、逢甲大學地理資訊系統研究中心 Level 3 國眾電腦、友達光電、三商電腦、叡揚資訊、慧智達科技、核心知 識、精誠資訊、經貿聯網科技、誠功科技、資拓宏宇、仁寶電腦工 業、大同、宏碁、富邦金控、惠普科技、新光人壽 Level 4 中冠資訊、程曦資訊整合、財團法人工業技術研究院、鼎升資訊科 技、鼎新電腦 Level 5 IBM 國際商業機器、中山科學研究院、凌群電腦 8

9 9 －寶發科技股份有限公司

10 美國有 10-15% 的軟體客戶都是國際大公司，一般都要求軟 體供應商通過較高級別的 CMM/CMMI 評鑑 透過確實的度量分析與專案監控，使得專案管理能力提升， 可以更有信心的掌握成本、時程與品質 奠定良好的專案流程標準化，可即時瞭解專案的活動狀況 及發生問題的應對方式 透過不斷的改善流程，除了使流程務實有效外，也將促進 生產力之提昇與營運成本之下降。 10

11 需求瞭解系統分析系統設計系統開發系統測試上線維護 11

12 瞭解客戶真正的需求與期望達成的目的 期望解決怎樣的問題 功能介面操作的要求 有無特殊規定、規範 當地使用者的習慣 限制條件內容 可透過訪談、 Email 、電話、問卷 … 等方式，進一步地取得 隱藏式的需求 專案需有啟動會議，告知並取得同意 書面文件有專案授權單、工作申請支援單、專案計畫書專案計畫書 專案計劃書中的 WBS( 內容時程規劃 ) 須依據專案在進行時同步更新 12

13 依據客戶的需求以及相關的資料內容，對系統做整體性的 分析及描述，取得較為準確或合理的結論 使用書面的方式清楚地呈現出客戶的需求，此成品為需求規格書 1 2 12 需求規格書內容分下列幾大項目： 範圍：作業環境、系統流程 功能性：操作方式、畫面處理或操作介面細部描述、程式流程 非功能性：如上線時間、效能要求 操作步驟：資料流程、 Use Case 13

14 一般而言，需求瞭解與系統分析會由同一人來負責 書面文件有需求規格書、需求追溯表、審查表、專案進度報告專案進度報告 專案的里程碑 14 需求規格書 PM 審查人員客戶 PMCM

15 依需求規格書的內容，轉成工程文件，此為軟體設計文件 (Software Design Document, SDD) 軟體設計文件分為兩種： 整體：有功能架構、系統架構、模組設計、資料設計 ( 檔案、資料 庫 ) 、部署設計 整體 系統架構：硬體、環境、網路、介面設計 模組設計：再使用 ( 評估原功能做調整 ) 、再開發 ( 自製 ) 、購買元 件 個別：依據功能、模組做更細部的描述 個別 若有重大技術問題，則在多方討論之後產生決策分析表 (Decision Analysis and Resolution, DAR) ，採用評分方式決 定決策分析表 15

16 此階段文件： 軟體設計文件 軟體設計文件 -{ 功能名稱 } 決策分析表 產品整合文件 Compiler 的方式、順序、位置與主要元件說明 使用者操作手冊 系統功能操作說明書 16

17 參考需求規格書 (SRS) 、依據軟體設計文件 (SDD) 開始撰寫 或修改程式內容 書面文件 依據軟體設計文件撰寫單元測試個案 開發人員會依據單元測試個案做單元測試 (UT) 依據需求規格書撰寫軟體測試個案 此為提供給客戶做測試的個案內容 17

18 系統測試一般分為三階段 公司 SIT ：公司的測試人員，依據軟體測試個案開始對系統做測試 測試正確產生的報告，稱作軟體測試報告 若有 Bug 則另有 IR 紀錄表紀錄，再將紀錄表提供給開發人員做修 改 客戶 SIT ：客戶的 IT/ 資訊人員，依據公司提供的軟體測試報告開始 測試 此階段一般為客戶的 IT 或資訊室人員做測試，此階段人員會具有 程式邏輯概念，且熟悉客戶作業流程 18

19 客戶 UAT ：客戶的使用者，依據所提供的軟體測試報告開始測試 一般會請真正的操作人員來做測試 僅熟悉作業流程 此階段也是三階段中時間最長的一個階段 當此階段完成後，客戶會針對使用的更新資料、執行檔等版本最 訂版 此階段之書面報告為軟體測試個案、軟體測試報告軟體測試個案 19

20 提供上線相關文件 使用者操作手冊 教育訓練文件 分為 IT 人員與使用者 AIG 上線操作步驟 Release Note 寫明此次交付軟體的異動內容、上線 Bug 的修復、版本的新舊版 號等資訊 上線計劃書 此為上線日期、上線流程 ( 動作 ) 、每階段所耗費的時間、負責的 人 ( 或單位 ) 及遭遇問題無法即時解決的處理方式 20

21 上線動作，會依據上線計畫書中所標示的時程進行 時間基本上會有兩天 第一天，客戶更換軟件與設備，公司現場支援以避免突發狀況 第二天，客戶所有人員正式啟用，公司現場支援與解決問題 之後，開結案會議收集意見與建議 到此，整個專案完整結束 21

22 22

23 如何寫簡報用的文件 一步一步慢慢來，先把自己要講的全寫上去，之後再逐次刪減 面對不同的場所，要調整簡報內容的重點與模式 自我練習的重要性 確實掌握簡報的時間 千萬別在客戶面前拿著麥克風做發聲練習 緊張是一定會有的，但是得看你可以在多短的時間內恢復 正常 23

24 職場上應有的基本禮節？ 遇到主管、同事或客戶需主動問好 不論是否請假或離職，都需要禮貌的告知權責主管 主管交付的文件一定要問清楚交付時間，若無法在交付時間內完成， 也一定要清楚地跟主管報備 工作上遭遇問題或困難，解決方式？ 自己來 詢問同事或主管 24

25 25

26 第一件事：搶別人的功勞 工作出現成果時，謹慎分析自己在當中扮演的角色，究竟有哪些功 勞真的算自己的 第二件事：掩飾過錯 掩飾過錯有如埋下一顆定時炸彈，等別人發現的時候，就是炸毀個 人聲譽的時候，事情將難以挽回 第三件事：工作常常沒有達到要求 萬一自己沒做好工作，下一個工作一定要加倍努力，趕快補償回來， 不要成為大家眼中的慣犯 －公司雜誌（ Inc. ）報導 26

27 首先，行事風格是民主或獨裁？ 民主，會有較自由的空間，但風險須自行負責 獨裁，最好凡事問，風險較小，但總覺得礙手礙腳的 其次，決策形式是掌握原則或注重細節？ 掌握原則，只要提綱挈領去報告就可 注重細節，只有比他更細了 最後，溝通方式是喜歡看書面報告或聽口頭報告？ 喜歡書面報告，必須準備一份鉅細靡遺厚厚的研究報告，讓他逐頁 批示 喜歡口頭報告，必須要言不煩地凡事當面請示，他會馬上給意見 － 2014-11-28 經濟日報 顏長川 27

28 要對程式有熱誠！ 寫程式是一件很快樂的事情！ 當工程師之前，請記得先交女友，不然當了工程師就交不 到女友了！ 工程師的痛就只有工程師能懂 ( 影片 ) ( 影片 ) 28

29 29