今回は、UMLのシーケンス図で表現したデータ移動モデルを用いて変更機能規模を測定する方法を紹介します。また、変更機能規模の測定結果の使い道について簡単に紹介します。
変更機能規模測定時に問題になること
本連載の第 3 回でソフトウェアの拡張や変更の際に開発範囲の規模を変更機能規模により測定できると説明しました。変更機能規模は、以下のような 3 種類のデータ移動を集計することで測定します。
- 追加されたデータ移動
- 変更されたデータ移
- 削除されたデータ移動
これらのデータ移動は、拡張や変更を行う前のソフトウェアのデータ移動モデルを基準にしてソフトウェアの拡張や変更によりどのようなデータ移動の追加、変更、削除が発生するかを考えて特定します。そのためには、以下の 3 つのことを行う必要があります。
- 拡張や変更を行う前のソフトウェアのデータ移動モデルを思い出す
- 拡張や変更を行った後のソフトウェアのデータ移動モデルを作成する
- データ移動の追加、変更、削除数を集計する
ここでまず問題になるのが、「拡張や変更を行う前のソフトウェアのデータ移動モデルを思い出す」ことです。データ移動の集計表ではデータ移動の順番が示されていないため各データ移動の意味を思い出すのに苦労します。そのため、データ移動の集計表の定義後数カ月が経過すると自分が定義した表であってもデータ移動の意味をなかなか思い出せなくなります。また、他人が作った変更前のデータ移動の集計表でそれを理解するだけでひと苦労でしょう。従って、変更機能規模を測定するためには変更前のデータ移動をなるべく自分や第 3 者が理解しやすい形で記録していくことが大事になります。
藤井流変更規模測定法
変更前のデータ移動を自分や第 3 者が思い出したり、理解しやすいという点では、UMLのシーケンス図の方がデータ移動の集計表よりも優れているのではないかと筆者は思っています。このようなUMLのシーケンス図の利点を活かして、筆者はUMLのシーケンス図と変更機能規模の集計表を組み合わせて変更機能規模を測定しています。これは、以下のような方法です。
- UMLのシーケンス図により変更の前後でのデータ移動モデルを表現する
- 変更の前後のデータ移動モデルの間で追加、変更、削除されたデータ移動を変更機能規模の集計表で集計する
ちょっとした工夫レベルのものですが、とりあえずこの方法を藤井流の変更機能規模測定法と呼びます。
以降、従業員検索を行う機能プロセスの例を用いて藤井流の変更機能規模測定法を説明します。まず、変更前の機能プロセスを以下のようなものだとします。機能プロセスに対する要求とデータ移動を「会話」形式ユースケースもどきで表現してみます。
| シーケンス番号 | 要求 | データ移動 |
|---|---|---|
| 1 | 検索画面から検索条件を入力する | データグループ「検索条件」をエントリー( E ) |
| 2 | 検索条件にマッチするデータグループ「従業員」をリード( R ) | |
| 3 | 検索条件にマッチした従業員一覧（氏名、社員コード）を検索結果画面に表示する | データグループ「検索結果」をエクジット( X ) |
ここで、シーケンス番号はデータ移動のシーケンスでの順番を表しています。また、注目オブジェクト「従業員」の属性は以下のようなものであるとします。
- 従業員コード
- 氏名
- 内線番号
- 組織コード
ここで、組織コードは各「従業員」が所属する「組織」を参照するための外部キーです。
変更前の従業員検索機能プロセスのデータ移動をシーケンス図で表現すると図1のようになります。
次のリリースあるいは次のリリースの開発途中で、このアプリケーションの要求が以下のように変更されたとします。
- 検索結果に従業員の氏名、社員コードだけではなく、内線番号と所属名も表示する
変更後の従業員検索機能プロセスのデータ移動モデルは表 2 のようになります。
| シーケンス番号 | 要求 | データ移動 |
|---|---|---|
| 1 | 検索画面から検索条件を入力する | データグループ「検索条件」をエントリー( E ) |
| 2 | 検索条件にマッチするデータグループ「従業員」をリード( R ) | |
| 3 | 「従業員」が所属するデータグループ「組織」をリード( R ) | |
| 4 | 検索条件にマッチした従業員一覧（氏名、社員コード、内線番号、所属名）を検索結果画面に表示する | データグループ「検索結果」をエクジット( X ) |
変更後の従業員検索機能プロセスのデータ移動モデルをシーケンス図で表現すると、図 2 のようになります。
この変更で、追加/削除/変更されたデータ移動は以下の3つです。
- データグループ「従業員」のリード( R ) → 変更されたデータ移動
- データグループ「組織」のリード( R ) → 追加されたデータ移動
- データグループ「検索結果」のエクジット( X ) → 変更されたデータ移動
これらの追加/削除/変更が発生した各データ移動の発生場所は、以下のように変更前、変更後のシーケンス図上の対応するデータ移動のシーケンス番号で記録することができます。
- 削除されたデータ移動 → 変更前のシーケンス図上のシーケンス番号
- 追加/変更されたデータ移動 → 変更後のシーケンス図上のシーケンス番号
これらのシーケンス番号と表 3 に示す変更機能規模の集計表を用いて変更機能規模の集計と記録を行うことができます。
| 新旧種別 | シーケンス番号 | 変更種別 | E | X | R | W | 備考 |
|---|---|---|---|---|---|---|---|
| 旧 | 1 | 削除 | 1 | 0 | 0 | 0 | |
| 新 | 1 | 変更 | 1 | 0 | 0 | 0 | 属性が追加された |
| 新 | 2 | 追加 | 0 | 0 | 1 | 0 | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 合計 | 3 | 2 | 2 | 0 |
この表の各列の意味は以下のとおりです。
- 新旧種別：変更前を「旧」、変更後を「新」と分類
- 変更種別：データ移動の追加/変更/削除種別
既にお気づきかもしれませんが、この表において削除されたデータ移動は変更前のシーケンス図上のシーケンス番号とともに記入されます。
従業員検索機能プロセスで変更されたデータ移動を集計表に記入すると以下のようになります。
| 新旧種別 | シーケンス番号 | 変更種別 | E | X | R | W | 備考 |
|---|---|---|---|---|---|---|---|
| 新 | 2 | 変更 | 0 | 0 | 1 | 0 | 属性が追加された |
| 新 | 3 | 追加 | 0 | 0 | 1 | 0 | |
| 新 | 4 | 変更 | 0 | 1 | 0 | 0 | 属性が追加された |
| 合計 | 0 | 1 | 2 | 0 |
この表から、従業員検索機能プロセスの機能規模は 3 CFPということが分かります。同様の方法で、測定対象のソフトウェアを構成するすべての機能プロセスの変更機能規模の総和を求めればソフトウェアの変更機能規模を測定できます。
ここまでの説明で、表1、2のような表と図1、2のシーケンス図とは内容が重複しているのではないかと思われる方もいらっしゃると思います。そのような疑問は非常にもっともです。表1、2は要求とデータ移動の両方を含むのに対して、図1、2はデータ移動だけを含んでいます。ただ、表1、2に記述されている要求は通常要求成果物や基本設計書に書かれている内容であるため、表1、2のような記述を行うと同じ要求を 2 ケ所に記述することになってしまいます。このような要求の記述の重複を避け、データ移動モデルを作る（変更する）手間を小さくするために、筆者はデータ移動を図1、2のようなシーケンス図だけで表現することにしています。
変更機能規模測定結果の使い道
ソフトウェアを開発するということは、基本的に機能を追加/変更/削除することです。変更機能規模は、そのような機能の追加/変更/削除の量、つまり開発規模を定量化するために使うことができます。ソフトウェア開発は新規開発と改修の 2 種類に大別されると思いますが、それらの両方の開発の規模は以下のように変更機能規模で定量化することができます。
- 新規開発：データ移動の追加だけからなる変更機能規模
- 改修：データ移動の追加/変更/削除からなる変更機能規模
つまり、新規開発の規模も改修の規模も変更機能規模で定量化することができるのです。変更機能規模が求まれば、変更機能規模と開発生産性から開発労力を見積もることができます。
ここで気をつけなくてはいけないのは、改修の場合のテスト労力（規模）です。テストを行う際に追加/変更した機能だけではなく、全機能をテストする場合には、そのテストの労力は変更機能規模ではなく、その時点でのソフトウェア全体の機能量を表す正味機能規模に比例する可能性があります。
変更機能規模は、開発途上で仕様変更を定量化するために使うこともできます。ソフトウェア開発の失敗原因としては、開発範囲のなし崩し的拡大、いわゆるスコープクリープが上位 3 位ぐらいに入るのではないかと筆者は推測しています。開発契約の締結段階や基本設計の時点で初期の変更機能規模をペースライン（基準）として設定し、開発途上で仕様変更をベースラインからの変更規模として測定することで、仕様変更の規模を定量化することができます。仕様変更の規模が定量化できれば、開発依頼者と仕様変更の影響をより合理的に議論し、判断するために役立つのではないかと期待できます。
さらに、仕様変更を受け入れながら開発する反復型開発やアジャイル開発においても、変更機能規模を測定することで仕様変更量や変更量を含む開発生産性を求めることができます。そのように仕様変更量や、仕様変更量を含む開発生産性を求めることで、反復型開発やアジャイル開発の良さを定量的にアピールできる可能性があります。
終わりに
今回の記事では、変更機能規模測定を行うための小技の説明が膨らんだため、COSMIC 法を用いた機能規模測定の結果を紹介できませんでした。前回の記事で予告した内容と異なり申し訳ありませんでした。次回の記事では、COSMIC 法を用いた機能規模測定結果を紹介し、余力があれば機能規模の概算法を紹介する予定です。年末年始に記事が執筆できるか少し不安ですが、...。
参考文献
- [1] COSMIC 法の公式サイト, https://cosmic-sizing.org/, (参照 2016-02-29)
- [2] JFPUG の COSMIC 法のページ, https://www.jfpug.gr.jp/cosmic/top.htm, (参照 2010-12-09)
参考文献[2]について：
本記事を掲載した時には日本語訳のドキュメントがリンク先で公開されていましたが、2016年2月現在はリンク先に存在しないようです。日本語訳としては、代わりにJIS規格「JISX0143 ソフトウェア－ＣＯＳＭＩＣ機能規模測定手法」をご覧ください。JIS規格は、日本工業標準調査会JISCの公式サイトhttps://www.jisc.go.jp/のJIS検索ページにてJIS番号「X0143」で検索すると閲覧できます。（2016年2月追記）