Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

COSMIC-FFP法 改メ COSMIC法のこと

見積り 本や資料

COSMIC法のことを会社で発表することにしていたので
プレゼンというかスライドの下書きを。


■見積手法の導入について
　～COSMIC法のご紹介～

■今日のお話し
－組込み向けファンクションポイント
　COSMIC法の紹介
－（うちの部署名）への見積手法の導入を考えてみる

■参考文献
　http://www.jfpug.gr.jp/cosmic/CFFP-index.html
－ファンクションポイント COSMIC-FFP法 実践ガイド
　（表紙の写真）
－COSMIC法Ver3.0マニュアル

■COSMIC 法の前に
ファンクションポイントとは

ソフトウェアの規模を表す尺度

開発者の論理でなく、エンドユーザー視点で測定
×ステップ数
○機能数

→エンドユーザーにとってのソフトウェアの価値を測る
→ソフトウェアの実装形態に依存しない

計測とは

何かを数えること
数え方の決めごとです

要するに
ステップ数じゃなくて別のものを数えてソフトウェア規模を測定します

■COSMIC機能規模測定法

適用領域
－業務アプリケーション
－リアルタイム系ソフトウェア
－上記の複合物

非適用領域
－数学的処理主体のソフトウェア
－連続的に信号処理を行うソフトウェア（オーディオ、ビデオ）

制限
－極小ソフトウェア
－小規模な変更

■COSMIC法の数えるもの
　（図2.1だけ）

■COSMIC測定プロセス
1.測定戦略段階
2.マッピング段階
3.測定段階

■測定戦略段階
1-1.測定目的の決定
1-2.測定範囲の決定
1-3.機能利用者の決定
1-4.測定詳細化レベルの決定

■測定目的の決定、測定範囲の決定

なぜ測定をするのか、及びその結果が何に使用されるかを定義する

例）
・工数見積りの入力として
・開発中のプロジェクト規模の変化の測定
・開発者の能力測定のための入力として
・生産性の測定のため

→目的によって「何を」「どこまで」測定すればよいかが違ってくる
　必要な情報の粒度・正確さが違ってくる
→ソフトウェアの分解レベルも違ってくる

（レイヤ、コンポーネント、分解レベルの話はここ）

■機能利用者の決定
機能利用者はデータのソフトウェアへの送信者およびソフトウェアからの受信者である
　（図4.1.2、または4.2.3）

（境界の話はここ）

■測定詳細化レベルの決定
　（図はv3.0の 2-4）

■ソフトウェア背景モデル
（ややこしくなるので割愛？）

■測定戦略段階のまとめ
（いるかな？）

1-1.測定の目的を確立する
1-2.被測定ソフトウェアの全体の範囲と個別に測定するソフトウェアの範囲を、
　　ソフトウェアアーキテクチャのレイヤと対等コンポーネントを考慮しながら定義する
1-3.被測定ソフトウェアの機能利用者を確立する
1-4.被測定ソフトウェア成果物の詳細化レベルと、
　もし必要なら標準的な機能プロセスの詳細化レベルで規模を定量化する手段を確立する

必要あれば繰り返し
COSMIC法だけでなく、全ての機能規模測定法に共通のプロセス

（規模を定量化するという話はどこかでする）

■COSMIC測定プロセス
　（各章の間に挟む？）
　（終わった章はまとめ的にひとこと説明）
1.測定戦略段階
　被測定ソフトウェアにソフトウェア背景モデルを適用する　←説明してないし
2.マッピング段階
　被測定ソフトウェアに汎用ソフトウェアモデルを適用する
3.測定段階
　実際に測定されたソフトウェア規模を得る

■マッピング段階
2-1.機能プロセスの識別
2-2.データグループの識別
2-3.データ属性の識別（任意）

　（図4.4.5と4.4.6）

オブジェクト指向設計と類似（でいいでしょ）

■汎用ソフトウェアモデル
　（これも割愛？）

■測定段階
3-1.データ移動の識別
3-2.測定関数の適用
3-3.測定結果の集計

■データ移動の識別
　（図5.1.1）
　（図5.1.7と5.1.8）

■測定関数の適用、測定結果の集計

COSMIC測定基本単位
１CFP（Cosmic Function Point)＝一つのデータ移動

規模（機能プロセスi）＝ ∑規模（エントリi）
　　+∑規模（エグジットi）
　　+∑規模（リードi）
　　+∑規模（ライトi）
■
COSMIC法はここまでです。

え!?、ここまで？

はい。ここまでです。

数え方の決めごと「だけ」です。
（私も誤解してました）

■FP 法の見積への利用

（図6.1）

生産性値＝実績FP／実績工数

見積工数＝見積FP／生産性値

プロジェクトの生産性は個々に異なるもの
→生産性を画一的に論ずることはできない

■COCOMOⅡスケールファクタとコストドライバ
（以下、例）
（自分たちに必要な要素に絞り込んで使え）

スケールファクタ
開発工数に対して指数的に増加減
・先例性
・開発の柔軟性
・アーキテクチャ、リスクの早期解決の必要性
・チーム結束性
・プロセス成熟度

コストドライバ
開発工数に対して乗数的に増加減
・プロダクト要因
・プラットフォーム要因
・要員の要員
・プロジェクト要因

（評価基準を設け、点数をつける、とか）

■見積手法導入の手順

1．社内へのFP計測法の標準化・普及、FP計測者の育成
2．パイロットプロジェクトによるFP計測および工数の収集
3．生産性値の分析と算出
4．見積モデルの 作成・標準化
5．見積モデルの普及

積算資料 2007/11月号より

■（部署名）でやってみよう
　（イマジン、です）

1. COSMIC 法のやり方を学ぶ
2. 実際に使ってデータ収集する
　　　見積時
　　　開発中×Ｎ（詳細かレベルが進むごとに計測する、かな？）
　　　完了時（実績）
3. 求めた CFP と実績工数の相関を分析する
　プロジェクト個別要因の影響を分析する
4. プロジェクト個別要因を CFP の係数として使えるように数値化する
　プロジェクト特性をモデル化し、モデルごとの CFP の測定法を見つけ出す
5. （部署名）の CFP 測定法と見積法をみんなで使えるようにする

（繰り返す、チューニング）

■課題、懸念

・十分なデータがサンプルできるか？
　社内受託案件はせいぜい○件／年？
・自社案件に合わせた測定法の確立が必要
　　既存製品の移植や改造
　　カーネル、BSP、ドライバ、ミドルウェア、、、
・案件のモデル化は可能か？

→傾向を見出だせるまで、どのくらいサンプルが必要？
→結局使えるまで、どこくらいかかる？

■
目的とゴールを明確に

何をいつまでに獲得したいのか

例）
開発前段階で一定以上の精度で見積できること
大型案件だけでも見積誤差をなくしたい
全案件での正確な見積の獲得
見積手法を使用していることを社外にアピール（営業的アドバンテージとして）


最初は『実践ガイド』のほうをメインに使って読んでみたが、
説明用に例として挙げられているシステムにひっぱられるせいか、
自社案件に合わせて具体的にイメージしようとすると、よくわからないことがいくつかあった
（機能プロセスの見出し方はいまだに謎だ...）。
使い方として一度学習していることを前提の書籍ということなので、例に照準を当てた割り切った書き方の部分もあるだろう。
最終的には、日本語版マニュアルの原典を当たることになった。

日本語版マニュアルは80ページ強で、ややボリューミーに感ずるが、その気になればわりとささっと読めてしまう。
ご興味ある方は、ぜひこちらを当たられたし。

COSMICV3.0には新たに「測定戦略段階」が追加されたとのこと。
ここがあったことが私にとっては理解の助けになった。