한국   대만   중국   일본 
能力 成熟도 統合 모델 - 위키百科, 우리 모두의 百科事典 本文으로 移動

能力 成熟도 統合 모델

위키百科, 우리 모두의 百科事典.
( CMMI 에서 넘어옴)

能力 成熟도 統合 모델 (Capability Maturity Model Integration, CMMI )은 소프트웨어 開發 및 電算裝備 運營 業體들의 業務 能力 및 組織의 成熟度를 評價하기 위한 모델을 말한다. CMMI는 旣存 能力 成熟도 모델 (CMM)을 발전시킨 것으로서, 旣存에 소프트웨어 品質保證 基準으로 使用되던 SW-CMM과 시스템 엔지니어링 分野의 品質保證 基準으로 使用되던 SE-CMM을 統合하여 開發한 後續 評價 모델이다. CMMI는 1~5段階까지 있으며, 5段階가 가장 높은 水準이다. CMMI는 소프트웨어 開發 및 電算裝備 運營 分野의 品質 關聯 國際 公認 基準으로 使用되고 있다.

소프트웨어 工學 [ 編輯 ]

CMMI 는 소프트웨어와 시스템 工學의 力量 成熟度를 評價하는 모델이다. (Software Engineering, Sommerville)

CMMI는 모델 SW-CMM(Software Capability Maturity Model, 소프트웨어 力量 成熟도 모델)v2.0과 SECM(System Engineering Capability Model) 그리고 IPD-CMM(統合製品開發-CMM)李 합쳐진 統合모델이다.

  • CMM Integration 프로젝트의 基盤이 되는 모델
    • SW-CMM: CMM v 2.0 draft C
    • SECM: EIA/IS-731(Systems Engineering)
    • IPD-CMM v 0.98

다양한 定義와 標準 모델들 間의 差異로, 敎育/評價/改善에 追加 費用 誘發 等의 問題로 인하여 統合된 모델을 必要로 하게 되었으며, 이와 함께 ISO/IEC에서는 標準 番號 15504로 CMMI가 아닌 유럽의 SPICE (Software Process Improvement and Capability dEtermination== ISO 15504 )모델을 國際 標準으로 選定함에 따라 이에 對抗하기 위해 SEI는 CMMI를 配布하게 되었다.

2006年 8月에 發表된 CMMI 버전1.2부터는 "開發을 위한 CMMI(CMMI for Development)-2006年 8月 配布", "發注를 위한 CMMI(CMMI for Acquisition)-2007年 10月 配布", "서비스를 위한 CMMI(CMMI for Services)"로 나뉘어 配布되기 始作하였다. 現在

CMMI의 프로세스 領域 [ 編輯 ]

CMMI는 組織의 開發 프로세스를 5 段階의 成熟도 레벨과 6段階의 力量 레벨로 나누어 評價한다. 이에 關聯하여 20餘個의 프로세스 領域을 支援하고 있으며, 이에 對한 4가지 知識體系와 4가지 分類를 提供하고 있다.

CMMI가 支援하는 知識體系의 範圍 [ 編輯 ]

CMMI는 “擴張된 프레임워크”를 提供한다. 現在 아래와 같은 4가지 知識體系를 構成하고 있는데 이 各各의 領域을 Discipline이라고 한다.

시스템 工學 (Systems engineering) [ 編輯 ]

  • 시스템 工學은 모든 시스템 開發에 該當된다. 소프트웨어를 包含시켜도 되고 안해도 된다.
  • 시스템 工學은 顧客의 要求/期待/制限事項들을 製品에 反映하고, 製品 全體 生命週期 동안의 支援 活動에 重點을 둔다.
  • 아래는 시스템 工學의 프로세스 領域(Process Area)이다.
    • 組織 프로세스 正義(Organizational Process Definition)
    • 組織 프로세스 重點(Organizational Process Focus)
    • 組織 訓鍊(Organizational Training)
    • 組織 프로세스 成果(Organizational Process Performance)
    • 組織 革新 및 履行(Organizational Innovation and Deployment)
    • 原因分析 및 解決(Causal Analysis and Resolution)
    • 形象管理(Configuration Management)
    • 意思決定 分析 및 解決(Decision Analysis and Resolution)
    • 測定 및 分析(Measurement and Analysis)
    • 製品 統合(Product Integration)
    • 프로젝트 進行 管理(Project Monitoring and Control)
    • 프로젝트 計劃(Project Planning)
    • 프로세스 및 製品 品質保證(Process and Product Quality Assurance)
    • 定量的 프로젝트 管理(Quantitative Project Management)
    • 要求事項 開發(Requirement Development)
    • 要求事項 管理(Requirement Management)
    • 危險管理(Risk Management)
    • 供給者 契約 管理(Supplier Agreement Management)
    • 技術 솔루션(Technical Solution)
    • 確認(Validation)
    • 檢證 (Verification)

소프트웨어 工學 (Software engineering) [ 編輯 ]

  • 소프트웨어 工學은 소프트웨어 시스템의 開發에 該當된다.
  • 소프트웨어 工學은 소프트웨어의 開發/運營/維持補修에 對해 體系的이고 訓鍊되었으며 定量化 可能한 接近 方法에 重點을 둔다.
  • 소프트웨어 工學의 프로세스 領域(PA)은 시스템 工學(System Engineering)과 同一하다.

統合製品 및 프로세스 開發(Integrated product and process development) [ 編輯 ]

統合製品 및 프로세스 開發은 顧客의 要求/期待値/要求事項을 滿足하기 위해 製品 全體 生命週期 동안 關聯 利害 當事者와의 適切한 協業을 遂行할 수 있는 體系的인 接近方法이다.

  • 統合製品 및 프로세스 開發의 프로세스 領域(Process Area)

供給者 蘇싱(Supplier sourcing) [ 編輯 ]

作業이 漸漸 複雜해지면서, 프로젝트 管理者는 프로젝트에 必要한 特定 製品에 對해 機能 遂行을 供給者에게 要請하거나, 修正을 要請할 수 있다. 이러한 活動들이 致命的일 때, 製品 引渡 前에 더 나은 소스 分析과 供給者 活動 모니터링을 通한 利得을 얻을 수 있다. 이러한 環境에서 供給者 소싱은 發注者의 製品 獲得 方式을 다룬다.

  • 供給者 蘇싱의 프로세스 領域(Process Area)이다.
    • 統合 供給者 管理(Integrated Supplier Management)

CMMI가 支援하는 프로세스 領域의 分類 [ 編輯 ]

CMMI의 프로세스 領域은 크게 4가지로 分類된다.

  • 프로세스 管理(Process Management)
  • 프로젝트 管理(Project Management)
  • 工學(Engineering)
  • 支援(Support)

프로세스 管理 [ 編輯 ]

프로세스 管理 領域은 프로세스를 定義하고 計劃하고 展開하고,적용하고,감시하고,조정하고, 評價하고 測定하고 改善하기 위한 프로젝트 間의 活動을 包含한다.

CMMI의 프로세스 管理 프로세스 領域은 아래와 같이 5個의 프로세스 領域으로 區分된다.

프로젝트 管理 [ 編輯 ]

프로젝트 管理 프로세스 領域은 프로젝트를 計劃하고 監視하고 統制하는 것과 關聯된 프로젝트 管理活動들을 다룬다.

CMMI의 프로젝트 管理 프로세스 領域은 다음과 같다.

  • 프로젝트 計劃(Project Planning)
  • 프로젝트 監視 및 統制 (Project Monitoring and Control)
  • 供給者 契約 管理(Supplier Agreement Management)
  • 統合 프로젝트 管理(Integrated Project Management)
  • 危險管理(Risk Management)
  • 統合팀(Integrated Teaming)
  • 定量的 프로젝트 管理(Quantitative Project Management)

엔지니어링 [ 編輯 ]

엔지니어링 프로세스 領域은 開發과 엔지니어링 Disciplines 間의 共有되는 維持補修 活動을 다룬다. 엔지니어링 프로세스 領域은 또한 소프트웨어 工學과 시스템 工學을 하나의 製品 開發 프로세스로 統合하고, 製品 基盤 프로세스 改善 戰略을 支援한다. CMMI의 엔지니어링 프로세스 領域은 아래와 같다.

  • 要求事項 開發(Requirements Development)
  • 要求事項 管理(Requirements Management)
  • 技術 솔루션(Technical Solution)
  • 製品統合(Product Integration)
  • 檢證(Verification)
  • 確認(Validation)

支援 [ 編輯 ]

製品 開發 및 維持補修를 支援하는 活動을 다룬다. 다른 프로세스들이 제대로 遂行될 수 있도록 하는 프로세스들이다. 一般的으로 支援 프로세스 領域은 프로젝트를 目標로 하며,조직에 對해 좀 더 一般的인 프로세스들이다. 例를 들어 PPQA는 프로세스의 客觀的 評價와 모든 프로세스 領域에서 定義되는 作業 産出物을 提供하기 위한 모든 프로세스 領域에 使用될 수 있다. 모든 PA들에서 使用할 수 있는 機能들을 提供하며, 몇몇 一般 實行(generic practice) 들을 具現하는 것을 도와준다. CMMI의 支援 프로세스 領域은 다음과 같다.

  • 形象管理(Configuration Management)
  • 프로세스 및 製品 品質保證(Process and Product Quality Assurance)
  • 測定 및 分析(Measurement and Analysis)
  • 統合을 위한 組織 環境(Organizational Environment for Integration)
  • 決定分析 및 解決(Decision Analysis and Resolution)
  • 原因分析 및 解決(Causal Analysis and Resolution)

CMMI의 力量 成熟도 [ 編輯 ]

CMMI의 組織 開發 프로세스 成熟度는 레벨1~레벨5로 나뉘어 있다. 레벨1은 매우 未熟하고 혼돈된 프로세스(Ad-hoc Process)이며, 레벨5는 最適化된 가장 成熟한 最高水準의 프로세스(Optimizing)이다.

CMMI의 組織 成熟도 [ 編輯 ]

CMMI는 組織의 프로세스 改善을 통한 소프트웨어 開發 過程에서의 費用, 品質, 日程 等 모든 것을 충족시키며 特定 成熟도 레벨로 進入하기 위한 最小限의 基準 提示와 반드시 遂行해야할 活動들의 集合으로, 프로세스 프레임워크의 成熟도 向上을 위한 모델이다.

CMMI 모델의 各 프로세스 領域(Process Areas)의 特定 目標(specific goals, SP)과 共通 目標(generic goals, GG)의 達成程度를 測定함으로써 프로세스 改善 水準을 나타낼 수 있다.

CMMI는 組織의 SW 開發뿐만 아니라 시스템設計, 하드웨어, 運營 等 시스템統合(System Integration, SI) 事業 全般에 對한 프로세스를 評價하고 定義하는 方法인 SCAMPI(Standard CMMI Appraisal Method for Process Improvement)를 提供한다.

特히 製品 또는 서비스의 開發, 獲得, 維持補修하기 爲한 組織의 公正 및 管理 能力을 向上시키기 위한 가이드를 提供과 이를 통해 프로세스 改善 詩 必要한 目標와 體系의 提供이 可能하다. 5段階로 構成되는 CMMI의 成熟도 레벨은 評價 組織의 프로세스를 改善 및 評價하기 위해 實行해야할 實行指針을 包含하며, 成熟한 組織의 各 레벨別 特徵은 아래와 같다.

소프트웨어 프로세스 成熟도 레벨 5段階 [ 編輯 ]

  • 레벨 1(Initial) -個人의 力量에 따라 프로젝트의 成功과 失敗가 左右된다. 소프트웨어 開發 프로세스는 거의 없는 狀態를 의미한다.
    • 標準化된 프로세스 없이 프로젝트 遂行結果 豫測이 困難한 組織
    • 適用 프로세스 없음.
  • 레벨 2(Managed) - 프로세스 下에서 프로젝트가 統制되는 水準으로 組織은 프로세스에 對한 어느 程度의 訓鍊이 되었다고 볼 수는 있지만, 日程이나 費用과 같은 管理 프로세스 中心이다. 旣存 類似 成功事例를 應用하여 反復的으로 使用한다.
    • 基本的인 프로세스 構築에 依해 프로젝트가 管理되고 있는 組織
    • 適用 프로세스
      • 要求事項 管理(Requirement Management)
      • 프로젝트 計劃(Project Planning)
      • 프로젝트 監視 및 制御 (Project Monitoring & Control)
      • 供給者 契約 管理(Supplier Agreement Management)
      • 測定과 分析(Measurement & Analysis)
      • 프로세스와 製品 品質 保證(Process & Product Quality Assurance)
      • 形象管理(Configuration Management)
  • 레벨 3(Defined) - 레벨 2에서는 프로젝트를 위한 프로세스가 存在한다면 레벨 3에서는 組織을 위한 標準 프로세스가 存在한다. 모든 프로젝트는 組織의 프로세스를 가져다 狀況에 맞게 調整하여 承認받아 使用한다.
    • 細部 標準 프로세스가 있어 프로젝트가 統制되는 組織
    • 適用 프로세스
      • 要求事項 開發 (Requirement Development)
      • 技術的 解決 (Technical Solution)
      • 製品 統合 (Product Integration)
      • 檢證 (Verification)
      • 組織 프로세스 重點 (Organization Process Focus)
      • 組織 프로세스 正義 (Organization Process Definition)
      • 組織 訓鍊 (Organization Training)
      • 統合된 프로젝트 管理(Integrated Project Management)
      • 統合된 供給者 管理(Integrated Supplier Management)
      • 危險(Risk Management)
      • 決定分析 및 解決(Decision Analysis & Revolution)
      • 統合 組織 環境 (Organizational Environment for Integration)
      • 統合된 팀 構成(Integrated Teaming)
  • 레벨 4(Quantitatively Managed) - 소프트웨어 프로세스와 소프트웨어 品質에 對한 定量的인 測定이 可能해진다. 組織은 프로세스 데이터베이스를 構築하여 各 프로젝트에서 測定된 結果를 一括的으로 蒐集하고 分析하여 品質評價를 위한 基準으로 삼는다.
    • 프로젝트 活動이 政略的으로 管理?統制되고 成果 豫測이 可能한 組織
    • 適用 프로세스
  • 레벨 5(Optimizing) - 이 레벨에서는 持續的인 改善에 置重한다. 組織的으로 最適化된 프로세스를 適用하여 다시 피드백을 받아 改善하는 上位 段階이다.
    • 持續的인 改善活動이 定着化 되고 最適의 管理로 프로젝트가 遂行되는 組織
    • 適用 프로세스

CMMI의 프로세스 改善 效果 [ 編輯 ]

全 世界 많은 企業들은 組織의 프로젝트 遂行能力 向上을 爲해 CMMI를 適用하고 있으며, 國內ㆍ外에서 最近 프로젝트 參與나 製品 供給을 위한 前提條件으로 提示되는 境遇가 늘어나면서 IT서비스 企業은 勿論 많은 製造, 金融圈 企業 等이 CMMI 認證 獲得을 推進하고 있는 趨勢이다. 흔히, CMMI 導入의 妥當性을 얘기하면서 投資對比 效果를 言及한다. 프로젝트 日程遵守率 이나 生産性, 品質, 費用, 顧客滿足度 側面에서 많은 效果를 본 것으로 나타나고 있다. 勿論 이런 肯定的인 效果를 본 組織이 全體的으로 많지는 않지만 充實하게 CMMI를 適用한 組織에서는 이러한 肯定的인 效果를 얻을 수 있을 것이다. 그러나 國內 企業들의 CMMI 適用의 效果는 調査 結果만큼 좋지 못한 것이 事實이다. 이러한 原因은 國內 SW開發 文化의 差異나 CMMI 適用方式의 差異 等에서 찾을 수 있을 것이다.

기타 追加 情報 [ 編輯 ]

CMMI의 全身에 該當하는 CMM(Capability Maturity Model)은 美國 카네기 멜론 大學 ( CMU )의 소프트웨어 工學 硏究所 (SEI; Software Engineering Institute가 IT 開發의 프로세스 管理能力 向上을 위해 미국방성(Department of Defense)의 資金 支援을 받은 프로젝트로 1986年부터 硏究하기 始作하여 1991年度에 發表한 標準 모델이다. CMM은 가장 먼저 開發된 SW-CMM을 일컫는 말이기도 하지만 現在는 소프트웨어 以外에도 適用할 수 있는 많은 分野가 있어 이런 部類의 成熟도 모델을 總稱하는 意味로 使用된다. SEI는 2005年부터 CMM에 對한 支援과 업데이트를 中斷하고 CMMI 擴散에 注力하겠다는 方針을 밝힌바 있다.

CMMI는 航空電子 소프트웨어 開發이나 北美 , 유럽 , 아시아 , 오스트레일리아 , 南아메리카 , 아프리카 等의 나라들의 政府 主體로 實施하는 프로젝트 等에서 넓게 使用되어 오고 있어 이러한 나라들에서 CMMI에 對한 關心은 높다. 現在, 몇 個의 나라들의 政府機關에서는 소프트웨어 開發 契約에 있어서 支援 業體에게 레벨3 基準을 基本으로 要求하고 있는 實情이다.


技術 솔루션 [ 編輯 ]

技術 솔루션은 成熟 段階 3에 包含된 14個의 프로세스 領域들 中 하나이며 시스템 엔지니어링 活動과 關聯하여 CMMI에 새롭게 追加된 프로세스 領域으로써 複雜한 製品을 開發하는 境遇에 有用하게 使用될 수 있다.

Purpose(目的) [ 編輯 ]

‘技術 솔루션’ 프로세스 領域의 目的은 要求事項에 對한 솔루션을 設計, 開發, 具現하기 위한 것이다. 여기서 솔루션이란 製品, 製品 컴포넌트, 그리고 製品의 生命週期 프로세스까지 包含하고 있다.

Introductory Notes [ 編輯 ]

  • 要求事項들을 만족시키는 솔루션을 評價, 選擇
  • 選擇한 솔루션을 위한 細部 設計를 開發
  • 製品이나 製品 컴포넌트 設計를 具現

Related Process Areas(關聯 프로세스 領域) [ 編輯 ]

  • 要求事項 開發(Requirements Development) 프로세스 領域
  • 確認(Verification) 프로세스 領域
  • 意思決定 分析 및 解決(Decision Analysis and Resolution) 프로세스 領域
  • 要求事項 管理(Requirements Management) 프로세스 領域
  • 組織 革新 및 適用 管理(Organizational Innovation and Deployment) 프로세스 領域

Specific Practices by Goal [ 編輯 ]

技術 솔루션 프로세스 領域에서의 特定 目的과 特定 프랙티스는 다음과 같다.

SG1: 製品 컴포넌트에 對한 솔루션을 選定해야 한다. [ 編輯 ]

  • SP1.1-1: 具體的인 候補 솔루션 및 솔루션 選定 基準을 開發해야 한다.
    • 候補 솔루션과 選定基準을 開發한다.
  • SP1.2-1: 運營 槪念 및 運營 시나리오를 具體化해야 한다.
    • 各 製品 컴포넌트를 위한 特定 運營狀態, 條件들, 運營方式을 說明하기 위한 運營 槪念, 시나리오, 環境들을 具體化한다.
  • SP1.3-1: 製品 컴포넌트에 對한 솔루션을 選定해야 한다.
    • 選定 基準을 가장 滿足하는 製品 컴포넌트 솔루션을 選定한다.

SG2: 設計 作業을 遂行해야 한다. [ 編輯 ]

  • SP2.1-1: 製品 或은 製品 컴포넌트에 對한 設計 作業을 遂行해야 한다.
    • 製品이나 製品 컴포넌트에 對한 設計 作業을 遂行한다.
  • SP2.2-1: 技術 데이터 패키지를 定義해야 한다.
    • 技術 데이터 패키지란 製品 아키텍처, 要求事項, 컴포넌트, 開發 프로세스, 主要 製品 特徵, 物理的인 製品 特性 및 製藥事項, 인터페이스 要求事項, 컴포넌트에 對한 要求事項, 製造 過程에서의 要求事項, 檢證基準, 使用條件 및 使用法, 意思決定 根據 等을 包含하는 槪念으로 開發해야 하는 製品이나 製品 컴포넌트에 對해 開發者들이 明確하게 理解할 수 있도록 說明해 놓은 것이라고 할 수 있다.
  • SP2.3-1: 基準에 根據하여 인터페이스를 設計해야 한다.
    • 製品 컴포넌트 인터페이스를 위한 솔루션을 樹立하고 維持한다.
  • SP2.4-1: 自體 開發, 購買, 或은 再使用에 對한 分析 作業을 遂行해야 한다.
    • 選定基準에 따라 製品 컴포넌트를 自體 開發, 購買, 再使用할지에 對한 評價를 遂行한다.

SG3: 製品 設計를 具現해야 한다. [ 編輯 ]

  • SP3.1-1: 設計를 具現해야 한다.
    • 製品 컴포넌트의 設計를 具現한다.
  • SP3.2-1: 製品 支援 文書를 開發해야 한다.
    • 엔드유저를 위한 文書를 開發하고 維持한다.

Generic Practices by Goal [ 編輯 ]

모든 프로세스 領域에서 共通的으로 適用될 수 있는 目的으로 技術 솔루션 프로세스가 組織에 內在化되어 있는지 判斷하는데 도움을 준다.

  • GG 1 特定 目標들을 達成한다.
    • GP 1.1 基本 프랙티스들을 遂行
  • GG 2 管理 프로세스를 內在化한다.
    • GP 2.1 組織의 政策 樹立
    • GP 2.2 프로세스 計劃
    • GP 2.3 資源 提供
    • GP 2.4 責任 割當
    • GP 2.5 訓鍊
    • GP 2.6 構成要素 管理
    • GP 2.7 關聯 利害關係者들 識別 및 包含
    • GP 2.8 프로세스 觀察 및 統制
    • GP 2.9 客觀的인 評價
    • GP 2.10 높은 水準의 管理와 狀態 檢討
  • GG 3 定義된 프로세스 內在化한다.
    • GP 3.1 定義된 프로세스 樹立
    • GP 3.2 改善 事項 蒐集
  • GG 4 定量的으로 管理하는 프로세스를 內在化한다.
    • GP 4.1 프로세스를 爲한 定量的 目標들을 樹立
    • GP 4.2 下位 프로세스 性能의 安定化
  • GG 5 最適의 프로세스를 內在化한다.
    • GP 5.1 繼續的인 프로세스 改善을 保證
    • GP 5.2 問題의 根本的인 原因

要約 [ 編輯 ]

技術 솔루션 프로세스 領域에는 여러 個의 對案들에 對한 分析 活動을 통해 要求事項을 충족시킬 수 있는 솔루션을 選定하고, 運營 시나리오를 開發하고, 設計 作業을 遂行하고, 技術 데이터 패키지를 作成하고, 具體的인 인터페이스를 設計하고, 自體 開發, 購買 또는 再使用에 對한 分析 作業을 遂行하고, 製品 支援 文書를 開發하는 活動 等이 包含된다.

같이 보기 [ 編輯 ]

參考 文獻 [ 編輯 ]

  • Mary Beth Chrissis, Mike Konrad, Sandy Shrum CMMI®: Guidelines for Process Integration and Product Improvement, 2003

外部 링크 [ 編輯 ]

위키미디어 共用 에 關聯된
미디어 分類가 있습니다.
元本 住所 " https://ko.wikipedia.org/w/index.php?title=能力_成熟도_통합_모델&oldid=37291705 "