[{PageViewPlugin}]
[SEにおけるプロセス改善], [SE Standard]
!!!Abstract
CMMI(Capability Maturity Model Integration)です。これは、プロセスに対する要求です。[1]の論文とEMSE284の授業での内容について、記録します。

!!!Topic
*CMMIとは
|まあ、有名ですので、詳しくは書きません。[2]を読んでください。プロジェクトを実行するための組織のとして良いプロセスを持っているかの成熟度を5段階で表すためのフレームワークなんですかね。

|CMMIは、ソフトウェアエンジニアリングのCMMから拡張されてできたプロセスへの要求となりますが、マネージメントのプロセスに対する要求がおもにCMMから、開発系に関するプロセス要求はSystems Engineeringからきているそうです。

*プロセス領域（Process Area）
|CMMIでは22個のプロセス領域があります（[SEI 2006|3], 17）。
**原因分析と解決 (Causal Analysis and Resolution：CAR)
**構成管理 (Configuration Management：CM)
**決定分析と解決 (Decision Analysis and Resolution：DAR)
**統合プロジェクト管理#IPPD (Integrated Project Management#IPPD：IPM#IPPD6)
**測定と分析 (Measurement and Analysis：MA)
**組織改革と展開 (Organizational Innovation and Deployment：OID)
**組織プロセス定義#IPPD (Organizational Process Definition #IPPD：
OPD#IPPD6 )
**組織プロセス重視 (Organizational Process Focus：OPF)
**組織プロセス実績 (Organizational Process Performance：OPP)
**組織トレーニング (Organizational Training：OT)
**成果物統合 (Product Integration：PI)
**プロジェクトの監視と制御 (Project Monitoring and Control：PMC)
**プロジェクト計画策定 (Project Planning：PP)
**プロセスと成果物の品質保証 (Process and Product Quality
Assurance：PPQA)
**定量的プロジェクト管理 (Quantitative Project Management：QPM)
**要件開発 (Requirements Development：RD)
**要件管理 (Requirements Management：REQM)
**リスク管理 (Risk Management：RSKM)
**供給者合意管理 (Supplier Agreement Management：SAM)
**技術解 (Technical Solution：TS)
**妥当性確認 (Validation：VAL)
**検証 (Verification：VER)

|それぞれのプロセス領域に対し、かなり詳細なプロセスの説明があります。たとえば、リスク管理は、ガイドラインの420-438ページまで説明が続きます（[SEI 2006|3], 420*438）。

*PMBOKとの比較
|PMBOKとCMMIの比較の図が授業で出てきました。CMMI＞PMBOKとしては定量的なプロジェクトマネージメントという話と意思決定の分析という話。上記の話と合わせると、この2つはCMMから来て、SEからは来ていないものになる。うーん、あまりピンとこないけど。PMBOK＞CMMIとしては、Human Resource Management。CMMIでは、人事の話はあまり扱っていないようです。この話は、[下の方|#a1]にも出てきますが。

*Scope
[{Image src='9420609766749793.jpg'}]
Fig. 1 Scope of Capability Model[1]

|ここからわかることは、CMMIは、プロジェクトチーム・プロジェクトマネージャによる、プロジェクト開発フェーズに適用するのが最も効果的であるということ。CMMIは、経営者が行うような戦略的なマネージメントや末端の技術者が実施するような専門的なタスクをターゲットとしていません。またプロジェクトのフェーズとしても、プロジェクトの早期の研究、運用フェーズの話は、スコープに入っていません。

*CMMIをやる目的は？
|CMMIは、プロセスを改善するために実施すべき。自分の会社の成熟度をアピールするために、CMMIの認定を受ける会社がある。実際にその会社のソフトウェアの品質が上がったかどうかは疑問だ。たとえばレベル3はプロセスが定義されていることを求めているが、定義だけなら、自分のやったことあるプロセスであれば誰でもできる。問題は、定義したものをプロセス改善に使えるかである。大抵の場合、そのプロセスは他の部隊では使えない。と先生が言ってました。

*CMMIの限界
|ここの話は、ちゃんとCMMIのスコープを理解しなさいという話なんだと思う。

|いいプロセスの特徴とどんなプロセスが必要かについての情報を提供するが、いいプロセスそのもやいつ使うべきかなどの情報は提供しない。([Sheard and Schoening 2002|1], 3)

|どんな製品がいい製品なのかの情報は提供しない。([Sheard and Schoening 2002|1], 3)

|プロジェクトの組織がどんなものがいいか、どんな人材を入れればいいのかについての情報は提供しない。([Sheard and Schoening 2002|#cite1], 4)

|どうリスクを減らすかの情報は提供するが、どうイノベーション（革新）を起こすか、もしくは起こしやすい環境を作るかの情報は提供しない。([Sheard and Schoening 2002|#cite1], 5)

!!!興味
*CMMIは、プロセスにおける理想を語る。理想的なKMのArchitectureの一部に組み込めるかも。

!!!Reference
#[#1]Sheard, Sarah A., William W. Schoening. 2002. Engineering Beyond Capability Models. Proceedings of the International Council on Systems Engineering
#[#2]Wikipedia contributors. 能力成熟度モデル統合 Internet. Wikipedia, ; 2008 11月 24, 20:57 UTC cited 2009 3月 10. Available from: http://ja.wikipedia.org/w/index.php?title=%E8%83%BD%E5%8A%9B%E6%88%90%E7%86%9F%E5%BA%A6%E3%83%A2%E3%83%87%E3%83%AB%E7%B5%B1%E5%90%88&oldid=23067660
#[#3]SEI. 2006. 開発のためのCMMI 1.2版. Carnegie Mellon Software Engineering Institute. Pittsburgh. http://www.sei.cmu.edu/cmmi/translations/japanese/models/cmmi-dev-v12-j.pdf