改善の３軸　とCMMI
Three axises of SPI and the CMMI

改善には次の３軸がある　There are three(3) axises to expand SPI
Extend PA
Refinement (efficiency,etc) 測定が必要
using Causal Analysis, L.L. ,assets, tools ,automated,
Involvement (coverage)

CMMI RD before getting order

派生開発型、仕様提示受理型のPJでは、要件開発は
受注前に行われることが多い
要件開発及びTSのSG1は、受注前にもある。

見積必要情報収集　　RD-SG1
機能概要決定　　　　RD,TS-SG1,SG2
品質レベル決定　　　RD-SG2
前提、制約条件　　　RD
実現性評価　　　　　RD,TS-SG1
予算見積もり　　　　PP-SG1　　簡略版
契約条件交渉　　　　RD-SG3、SAM
受注審査　　　　　　PP-SG3,RSKM　簡略版

コントローラーとしてのプロセス

Whyの階層
ビジネス目標、ビジネスニーズ
プロセス取り組み方針

コントローラー　　何を（プラクティス）をやるのか、その順番でやるのか

Whatの階層
プラクティス

Howの階層
実現方法

－－－－－－－－－－－－－－－－－－－－－－
ソフトウェアライフサイクルを決める

プロセス記述は標準そのままではない

１．ソフトウェアライフサイクルモデル群　からソフトウェアライフサイクルモデルを選択

２．共通フレームなどのアクティビティ・タスクをマッピングし、プロセス資産を使ってソフトウェアライフサイクルを作る

CMMIを改善に薦める理由

CMMIなら各プロセスをバランスよく段階を追って仕組みを改善できる

グローバルなベストプラクティスを知る事ができる。ソフトの世界でどの位置に
あるかを確認できる

但し、CMMIの先にある個別の専門領域も調べるべき

WFとagileの違い

WFはセットで開発、agileはstory毎に開発

WFは間に合うか、遅れるか、品質が悪いものをリリースするかのいずれか。
agileは、期限内に一定の品質のものを出荷できるが、一部機能が落ちるかもしれない

リリース後の変更は、WFでは例外扱いであり、Agileはある事を前提としている
従い、組み込み製品でかつ、更新が困難な場合はagileは向いていない

サービスを提供する形態の場合はagileが向いている。監視系などもagileが向いている

Sprint reviewでOKかどうか判断が必要。Web系ならあまり問題にならないがそうでない場合、
よく考えられたテストシナリオが必要。あるいは、要求を提示時に、最初にどう確認するかの設計が必要

Agileに移行するには、Function Pointなどで、簡易的な見積もりができる事が望ましい。
　で、ないと妥当なのかどうかが開発チームのいうがままになる