アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要
オージスさんのアジャイル開発の事例を見ていたら、アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要という指摘があって面白かった。
考えたことをラフなメモ書き。
【元ネタ】
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で計測できれば、過去の計測データを用いて、かなりの精度で見積りができるはず。
アジャイルに開発するには、要求が変化するにも関わらず、優れたモデリング能力と見積り能力が必要になるという指摘が面白い。
| 固定リンク
「モデリング」カテゴリの記事
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないか(2024.02.12)
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント