アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要
オージスさんのアジャイル開発の事例を見ていたら、アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要という指摘があって面白かった。
考えたことをラフなメモ書き。
【元ネタ】
OGIS Scalable Agile Method の真髄(前編)
OGIS Scalable Agile Method の真髄(後編)
ざっくり読んだ感じでは、RUPをベースにオブジェクト指向設計に基づいたモデリングを行い、反復型開発でシステムを構築していくような開発スタイルを提唱している。
オージスさんはオブジェクト指向設計の老舗であり、モデリング力があるからこそ、アジャイル開発にオブジェクト指向設計を組み合わせた開発スタイルを提唱できるのだろうと思う。
興味深い点は、アジャイル開発のように、契約時の要件が固まっていない場合、「発生する変更の規模を測定する」考え方から見積りを行う点だ。
(引用開始)
機能規模測定手法を用いて、スコープの変化を許容するソフトウェアの調達方法としては southernSCOPE [12] というものが提案されています。この方法は、オーストラリアのヴィクトリア州における情報システムの調達において開発されたものです。
southernSCOPE の実行手順は以下のとおりです。
(1)ソフトウェアを調達する際に、顧客はスコープマネジャーを雇う
(2)スコープマネジャーは、FP (Function Point) 法により初期の費用とスケジュールを見積もる
(3)顧客は、機能概要や制約を記述したRFPを作成し、入札にかける
(4)顧客は、調達先と機能規模あたりの単価に合意する
(5)分析フェーズを実行することで、要求仕様書を作成する
(6)要求仕様書に基づいてスコープマネジャーが機能規模を算出し、顧客は予算とスケジュールを考慮してどの機能が必要かを決める
(7)開発途上での変更について、 スコープマネジャーが費用に対する影響を算出し、顧客と開発者が合意する
(8)開発が完了した時点で、顧客は納品されたソフトウェアと変更に対する費用を支払う
(引用終了)
上記の方法では、設計フェーズを反復しながらモデルを洗練化していき、出来上がったモデルに対し、FP法(ファンクションポイント法)で機能規模を計測する所が重要。
FP法は、InputとOutputのデータの内容が決まれば、そのシステムの規模を測定できるという見積りの仕組み。
FP法は従来から長い歴史があり、計測方法や機能規模に関するデータもたくさん蓄積されているので、持続的に計測できれば、規模見積りに役立つだろう。
更に重要な点は、機能規模をファンクションポイントで客観的に計測できるようなモデルを作る能力があるのが前提だ。
オージスさんのように、長年モデリングに携わって、モデリングの経験が深いからこそ、FP法は生きる。
児玉公信さんの「システム開発の見積りのための実践ファンクションポイント法」では、ER図とDFDからFP法を計測する事例が載っていて、とても勉強になる。
そもそもFP法は、データモデリングと相性が良い。
ER図からテーブルのCRUD表が作れれば、ILF・EIFのようなデータをすぐに洗い出せるし、ILF・EIFを参照・出力するようなプロセスを考えれば、FP法ですぐに計算可能だからだ。
オブジェクト指向設計はおろか、DFDやER図をまともに書けないようでは、FP法で計測することすらできないだろう。
個人的には、DOAを標榜する人達は何故、自分たちが作ったモデルに対してFP法で機能規模を見積もる手法を展開させなかったのか、不思議だ。
そもそも、モデルをシステム提案という早い段階から設計する理由の一つは、ざっくりでもいいから、早めにシステムの規模を見積り、開発コストを見積りたいからだ。
だからこそ、優れたモデリング能力があれば、曖昧な要求からある程度のモデルを導くことができるので、FP法で即座に見積りできるはず。
機能規模をFPで計測できれば、過去の計測データを用いて、かなりの精度で見積りができるはず。
アジャイルに開発するには、要求が変化するにも関わらず、優れたモデリング能力と見積り能力が必要になるという指摘が面白い。
| 固定リンク
「モデリング」カテゴリの記事
- SQLは画面や帳票のインターフェイス層に相当する(2021.04.10)
- 統計学と機械学習の違いは、データの説明かデータの予測か(2021.04.01)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 「データモデル大全」は良い本だ(2021.03.21)
- 関西IT勉強宴会の感想~コロナワクチン接種管理システムのデータモデリング(2021.02.25)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Agile」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
コメント