ソフトウェア開発プロセスの進捗予測システムの開発
水野修，平山裕司 0 ，楠本真二，菊野 亨
大阪大学 基礎工学部 情報工学科〒 560 大阪府豊中市待兼山町 1-3
Tel: 06-850-6568 Fax: 06-850-6569
E-mail:fo-mizuno,hirayama,kusumoto,kikunog@ics.es.osaka-u.ac.jp

あらましなもの，実際の開発プロセスに適用して有効性の評価を行ったものはほとんどない．
本稿では，先ず，客観的かつ定量的なプロジェクト管
理手法を確立するために，一般化確率ペトリネットを用
いてソフトウェア開発プロセスを形式的にモデル化し，評価する方法を提案する．提案するモデルでは作業量という新しい概念を導入することによって，開発の進行に応じて変動する開発期間の大きさやプロダクトの成長を表現することが可能になっている．
次に，提案した一般化確率ペトリネットの拡張モデルに基づくソフトウェア開発プロセスの進捗予測システム
を設計，試作した．その概要と基本機能，さらに，提案システムの評価実験として，ある企業における開発実績
データに基づいた例題プロセスの定量的評価を行なった
結果についても報告する．

大規模化，複雑化が進むソフトウェアの開発においてプロジェクト管理の重要性が高まっている．効果的なプ
ロジェクト管理を行うためには，開発プロセスの定量的かつ客観的な評価結果に基づいた管理手法を確立する必要がある．本稿では，まず，客観的かつ定量的なプロジェ
クト管理手法を確立するために一般化確率ペトリネット
を用いてソフトウェア開発プロセスを形式的にモデル化し，評価する手法を提案する．次に，提案した一般化確
率ペトリネットの拡張モデルに基づき，試作したソフト
ウェア開発プロセスの進捗予測システムの概要と基本機能，評価例について述べる．

1 まえがき大規模化, 複雑化が進むソフトウェアの開発において
品質不良, 納期遅延, 予算超過といった問題の解決が求められている. これまでにドキュメントやソースコードなどのプロダクトやその生成過程である開発プロセスを評
価し , その結果に基づいてプロダクトや開発プロセスの改善を行う研究が活発に行われている [13][17][18]. しかし , 個々のプロダクトあるいは開発プロセスだけを独立に分析するだけでは , 様々な要因の相互作用の結果として生じるこれらの問題を十分に解決することは困難である [1].
こうした背景の下でソフトウェア開発の全過程を通して品質, コスト , 開発期間の各項目を統合的に管理する, いわゆるソフトウェアプロジェクト管理の考え方が注目されている. しかし , プロダクトの特性 (開発対象となるソ
フトウェアのアプリケーション分野, 規模等) やプロセスの特性 (開発方法, 作業者, 期間, コスト等) はプロジェク
ト毎に大きく異なるため, プロジェクト管理者の経験や勘に基づいて試行錯誤的にプロジェクト管理が行われているのが現状である [8][15]. これまでにもソフトウェア
開発プロセスのモデル化とその評価を行う手法が数多く提案されてきている [9][10][13][18][19]．PERT/CPM も代表的なものの一つである．しかし，品質，コスト，開発期間の 3 つ観点からプロセスを定量的に評価するよう

2 ペト リネット モデル
2.1

一般化確率ペト リネット (GSPN)

ペトリネットはソフトウェア開発プロセスのような並行システムの解析やシミュレーションでのモデル化に適した記述能力の高い数学的モデルである．ペトリネットの構成要素にはトークン，プレース，トランジション，
そしてプレースとトランジションを結ぶアークがある．
これまでにペトリネットに対する種々の拡張が報告されている．まず，確率ペトリネットは，トランジションの発火が可能になってから実際に発火するまでに遅延を許し，その遅延を表す指数分布確率変数を各トランジションに関連づけたペトリネットである．次に，一般化確率ペト
リネット (Generalized Stochastic Petri-net:以降 GSPNと呼ぶ) は通常のペトリネットと確率ペトリネットの概念を融合して一般化したペトリネットであり，発火に時間がかからない瞬間 (即時) トランジションと発火に時間がかかる時間トランジションの 2 種類のトランジションがある [11]．時間トランジションの発火時間は指数分布に従うが，各時間トランジションにそれぞれ固有の発火
レートを割り当てることで発火に要する平均時間を変化させることができる．
この GSPN をソフトウェア開発プロセスのモデル化に

0 現在オムロン株式会社

1例えば，作業量 20 時間の作業の実行について次の 2 つの場合を考える．
場合 1 : 2 人の標準的な能力の作業者が、次の作業条件
でこの作業を行なうとする．2 人の間のコミュニケーショ
ン・オーバーヘッドとして作業に携わる時間の 10%は作業の進行に寄与しない．このとき，2 人が 10 時間作業に携わったとしても，達成された作業量は 18(= 10 時間 2
2 2 0.9) 時間となる．
場合 2 : 標準的能力の作業者 4 人が次の条件のもとで5 時間作業に従事するとする．4 人の間のコミュニケー
ションにより作業に携わる時間の 20%がオーバーヘッド
としてかかる．このときに達成される作業量は 16(= 52 4 2 0.8) 時間となる．
作業量はある作業の大きさを作業条件に依らず一意に定めることができ，同一作業に対する様々な条件のもとでの作業時間を計算することができる．
提案するモデルでは，作業への入力となるプロダ ク
トに依存して作業量が決定されるものとする．例えば，コーディング作業であれば入力となる設計仕様書のサイズが大きいほど作業量は大きくなる．デバッグ作業であれば入力プロダクトに含まれるフォールト数が多いほど作業量は大きくなる．また，作業の進行は達成した作業量の増加という形で表される．達成した作業量の増加にしたがって出力プロダクトのサイズやフォールト数を変化させることでプロダクトの成長をモデル化できる．

用いることにより，開発に要する時間やコストを評価することができる．しかし，ソフトウェア開発におけるもう 1 つの重要な管理項目である品質を評価することはで
きない．

2.2

拡張 GSPN [5][7]

拡張 GSPN では，開発の進行にともなって変化するプ
ロダクト中のフォールト数を評価するために GSPN に対して次の 2 点の拡張を行なっている．

(1) トークンに対する属性の導入．
トークンは，開発作業の実行中に変化するプロダク
トサイズやフォールト数，作業の進捗度の値を属性として保持する．

(2) トランジションに対する発火実行関数の導入．
各トランジションには，その発火毎に評価される発火実行関数を与えることができる．この関数により，プロダクトサイズやフォールト数といったトークンの属性値の変化を記述することができる．

3 階層的モデル
提案する拡張 GSPN に基づく開発プロセスモデルでは作業量という新しい概念を導入することにより，開発期
間とプロダクトサイズの変動を考慮したソフトウェア開発の進捗予測を実現する．

3.1

3.2

作業量

モデルの概略

提案するモデルは，プロジェクトモデルとプロセスモ
デルの 2 つからなる階層的モデルである．図 1にその概略を示す．

従来，作業の大きさを表すために工数が用いられている．工数は，作業に従事した作業者の数と要した時間の積で表される．しかし，この値は作業が終わった時点で分かる値では容易に求まるが，これから行なおうとする
作業の場合には状況予測がつきにくいので，その値をあらかじめ予測して求めるのは難しい．例えば，工数で表した場合に 1 人の作業者が 10 日間で終えた作業も，10人の作業者が 1 日で終えた作業も同じ 10 人日となるが，一般に人数が多くなれば作業者間のコミュニケーションに要する時間が増えるため，それぞれの作業の大きさは必ずしも等しくない．工数には本来，作業の遂行に必要な作業の大きさだけでなく，コミュニケーションに必要な手間の大きさも含めている．従って，10 人の作業者が1 日で終えた作業 (10 人日の工数の作業) を 1 人の作業者が行なった場合，10 日より少ない日数で終える可能性がある．
そこで，標準的な作業者が 1 人で作業を行なったときに必要な総時間数をその作業の作業量と定義し ，この状況における作業効率を 1 と定める．作業効率は作業を行なう人数や各作業者の能力，使用するツールの性能，といった作業が行なわれる条件により変化するものとす
る．このように定めると，作業時間は作業量を作業効率で割った値として求めることができる．

AAAAAAAAAAAAAAA プロジェクトモデル
AAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA
作業の集合
AAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA
プロダクトの作業者の集合AAAAAAAAAAAAAAA
集合
AAAAAAAAAAAAAAA
作業効率の設定

属性値の変更AAAAAAAAAAAAAAAA
設計
AAAAAAAAAAAAAAAA
テスト
プロセスモデルコーディングAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
レビュー
デバッグ
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
図 1: モデルの概略

上位のプロジェクトモデルでは，ソフトウェア開発の諸要素を作業，作業者，プロダクトの 3 つの概念に集約し，それぞれに対して様々な属性を付加している．
下位のプロセスモデルは，設計，コーディング，レビ
ュー，テスト (単体テスト，結合テスト，受け入れテスト

2等)，デバッグ，等個々の作業モデルの集合であり，それぞれの作業モデルは拡張 GSPN を用いて記述される．
提案する階層的モデルでは，プロジェクトモデルと作業モデルが相互に情報を交換していくことでプロジェク
トの進行をモデル化することができる．具体的には，ある一定の時間間隔で次の 3 つの手順を実行することによりプロジェクトモデルの属性値の更新が行なわれる．

表 1: プロジェクトテンプレート
作業 Ai の属性
種類
開始条件
終了条件
入力プロダクト
出力プロダクト
作業者
予定終了期日作業量

1. プロジェクトモデルの作業，プロダクト，作業者の各属性値に基づいて，実行する作業の作業効率を求める．

プロダクト Pi の属性
サイズ
フォールト数
完成度

2. 求まった作業効率の情報を対応する作業モデルに渡作業者 Mi の属性
経験レベル

した後，作業モデルに従って一連の作業を実行する．

3. 作業の実行結果をプロジェクトモデルに返す．プロ

entry c:exit c:input
outputworkf orce
deadline
workloadsize
f aultc: ratelevel

表 2: プロジェクトの記述例

ジェクトモデルはその情報に基づいて作業とプロダ
クトの属性値を更新する．

A1
type

3.3

type

entry c:プロジェクト モデル

exit c:input

プロジェクトモデルは作業，プロダクト，作業者の 3つに着目し，プロジェクトをこれらの要素の集合としてモデル化したものである (表 1)．各要素にはそれぞれの概念を特徴づける属性を付加する．
作業には 6 種類の属性 (種類，開始/終了条件，入力/
出力プロダクト，作業者，予定終了期日，作業量) を与える．(1) 種類 (type) はその作業が設計，コーディング，レビュー，テスト，デバッグのうちのどれかを示す．(2) 開始条件 (entry c:) と終了条件 (exit c:) はその作業の開始と終了のための条件をそれぞれ表す．(3) 入力プロダクト(input) はその作業の入力となるプロダクト名とそのプロダクトが作業量の値の決定にどの程度影響を与えるのかを示す重みの 2 項組で表される．同一作業に対して 2 項
組は複数指定してもよいものとする．一方，出力プロダ
クト (output) は生成，更新されるプロダクトとそのプロダクトに対する重みを 2 項組として与える．なお 2 項組が複数個存在する場合は，作業で得られるプロダクトのサイズやフォールト数の変化量を，この重みに従ってそれぞれのプロダクトに割り振る．従って，各プロダクトに対する重みの和は 1 である．(4) 作業者 (workforce) の項では，どの作業者がどの程度の割合でその作業に携わるかを表す．すなわち，作業に携わる作業者とその作業者の稼働率 (その作業に携わることができる時間の割合)の 2 項組の集合として表す．(5) 予定終了期日 (deadline)
は開発計画で定められた作業の終了期日を表す．(6) 作
業量 (workload) では，その作業に割り当てられた作業
量とそれまでに達成された作業量 (達成作業量) の 2 項組で表す．
プロダ クトには 3 種類の属性: (1) プロダクトのサイ
ズ (size)，具体的にはドキュメントのページ数やソース
コード の行数を表す，(2) プロダクトに含まれている残存フォールト数 (fault)，(3) そのプロダクトに必要な記述事項の完全さを割合で表した完成度 (c: rate)，を与えoutputworkf orce
deadline
A2
type
entry c:exit c:input
outputworkf orce
deadlineA3
type
entry c:exit c:input
outputworkf orce
deadlineA4
type
entry c:exit c:input
outputworkf orce
deadlineA5
type
entry c:exit c:input
outputworkf orce
deadline
P0
size
f aultc: rate
M1
level
M2
level
M3
level

3

FD
(A1 ,non-executed)(A1 ,consumed)(P0 ; 7:0)
(P1 ; 0:3)，(P2 ; 0:5); (P3 ; 0:2)
(M1 ; 1:0)
20
PG
(A1 ,done)(A2 ,consumed)(P1 ; 1:2)
(P4 ; 1:0)
(M2 ; 1:0); (M3 ; 1:0)35
PG
(A1 ,done)(A3 ,consumed)(P2 ; 1:1)
(P5 ; 1:0)
(M1 ; 1:0)35
FT(A2 ,done), (A3 ,done)(A4 ,consumed)(P3 ; 2:0); (P4 ; 0:2); (P5 ; 0:25)(P6 ; 1:0)
(M2 ; 1:0)60
FTD
(A4 ,running)(A4 ,done),(A5 ,consumed)(P6 ; 2:4)
(P4 ; 0:45); (P5 ; 0:55)(M1 ; 1:0); (M3 ; 1:0)
65
8
0
1.0
3
2
1

思考，記述，会話といった作業者の振る舞い，あるいは，テスト中での故障の発生といった作業中の事象を対応させる．一方，プレースは振る舞いや事象が起きるまでの待ち状態を表している．

る．ここでプロダクトの完成度は記述事項の正しさには関係なく，必要とされる記述事項の漏れのなさを表すものとする．
作業者には経験レベル (level) を属性値として与える．
経験レベルはソフトウェア開発の経験年数に応じて作業者を初級，標準，上級の 3 つに分類し，それぞれを 1,2,3に数値化したものである．
このプロジェクトモデルを利用した記述例を表 2に示す． 表 2の A1 ; 1 1 1 ; A5 は作業の記述部分である．ここでは作業 A1 の記述を例に説明する．type より A1 は設計(FD) 作業であることがわかる．entry c: には作業 A1 が未実行であれば実行を開始することが記されている．一方 exit c: には A1 はその作業量が全て達成されれば終了することが書かれている．次に input にはプロダクト P0
が A1 の入力として与えられることと，A1 の作業量が P0のサイズの 7 倍の値に設定されることが記されている．
output には A1 の出力プロダクトが P1 ，P2 ，P3 の 3 つであり，作業の進行に伴って定まるプロダ クトのサイズやフォールト数の変化量がプロダクト P1 ，P2 ，P3 に対して 3:5:2 の比率で割り振られることが記されている．
workforce は作業 A1 を作業者 M1 が担当することを表している．最後に deadline より A1 の予定終了期日はプ
ロジェクト開始から 20 日目に設定されていることが分かる．
P0 はプロダクトの記述である．プロダクト P0 のサイ
ズが 8，フォールト数が 0，完成度が 100% であることが示されている．更に，作業者 M1 ; M2 ; M3 の属性より，経験レベルがそれぞれ 3，2，1 であることが分かる．
なお，各作業 (A1 ; 1 1 1 ; A5 ) の作業量，および ，初期
入力プ ロダ クト (この 例では P0 ) 以外のプ ロダ クト(P1 ,1 1 1,P6 ) の属性値はモデルの実行時に設定される．

3.4

トークンの属性s プロダクトサイズ
f フォールト数
w 達成作業量t 1 rcmrt 2 thP2

P1
トランジション
発火実行関数t 3 rwr

t1
-

t2

t3

s=s+1
w=w+1
f=f+1 (pin )図 2: 設計作業
図 2に示した設計作業の場合，トランジション t1 ; t2 ; t3はそれぞれ作業者間のコミュニケーション，問題の解決に必要な思考，ドキュメントとして記録するための記述に対応しており，発火レートとしてそれぞれ rcm ; rth ; rwrを与えている．これらの発火レートは一般的には次のような関数として表す．
コミュニケーションレート
rcm = fcm (作業者数，各作業者の経験レベル，
入力プロダクトの完成度)
思考レート

rth = fth (作業者数，各作業者の経験レベル)

作業モデル

記述レート

rwr = fwr (作業者数，各作業者の経験レベル)

ここではプロセスモデルの構成要素である作業モデルについて説明する．
作業モデルは作業の種類毎に定義し，その記述には拡張 GSPN を用いる．作業の種類として設計，コーディン
グ，レビュー，テスト，デバッグの 5 つを考える．図 2は拡張 GSPN で記述した設計作業である．この記述ではトークンの属性としてプロダクトサイズ s，フォールト
数 f ，達成作業量 w の 3 つを持たせている．各属性の意
味は次の通りである．(1) プロダクトサイズ s は作業により生成されたプロダクトのサイズを，(2) フォールト数f は作業中に作り込まれたり，取り除かれたフォールトの個数を，(3) 達成作業量 w はその時点までに達成された作業量を，それぞれ表す．
図 2中のトランジションはすべて発火に時間を要する
時間トランジション (図中の太線) である．例えば，トランジション t1 の発火レートは rcm で与えられており，これはトランジション t1 の発火時間が平均 1=rcm の指数分
布に従うことを意味する．これらのトランジションには

これらの関数の利用により作業者数や経験レベル，あるいは，入力プロダクトの完成度に応じて，コミュニケー
ションの発生頻度，思考や記述の難易度を動的に設定することができる1 ．
また，思考や記述のトランジションが発火する毎に達成作業量 w やプロダクトサイズ s が増加するといったトークンの属性値の変化は図 2の記述にもある様に，各トランジションの発火実行関数として記述される．なお，
設計作業におけるフォールトの混入 (すなわち，フォー
ルト数 f の変化) はフォールト混入率 pin による確率的な事象として取り扱う．このフォールト混入率 pin は一般的には次のような関数として表す．

pin = fin (作業者数，各作業者の経験レベル，
予定終了期日; 入力プロダクトの完成度)
1fcm ; fth ; fwr ; fin の具体的な式は適用するプロジェクトに応じて決めるものとする．

4

る．具体的には，作業，プロダクト，作業者の関係の定義や各作業，プロダクト，作業者についての属
性値を設定する．最後に，設定した作業モデル，パラメータを作業シミュレート部へ受け渡す．

この関数の利用により，デッドラインや作業者の経験がフォールトの混入率に与える影響も考慮することができる 1 ．例えば，図 2の設計作業ではトークンが P1 にあるとき，２つのトランジション t1 (コミュニケーションを表す) と t2 (思考を表す) が発火可能である．t1 の発火によって時間は経過するがプロダクトや作業量の達成には何の影響もなく，トークンは P1 に戻る．次に，t2 が発火すると 発火実行関数によって達成作業量 w が 1 増加
するとともにトークンは P2 に移る．トークンが P2 にあるときは t3 だけが発火可能である．この t3 (記述を表す)が発火するとプロダクトサイズ s が増加し，フォールト
混入率 pin の値によってフォールト数 f の増加が確率的に起こる．このときトークンは P1 に移る．

(2) 作業シミュレート部: 作業シミュレート部では，プロジェクト制御部から与えられた情報 (作業モデル
名とパラメータ) に基づいて，シミュレーションを行う．具体的には，先ず，与えられた作業モデル名に対応する拡張 GSPN 作業モデル記述をペトリネット
データベースより読み出す．次に，与えられたパラメータを用いてモデルを動作する．シミュレーショ
ン結果は一定時間間隔でプロジェクト制御部へ渡され，同時に，シミュレーションデータベースにも保存される．

4 進捗予測システム(3) ユーザインタフェース部: ユーザインタフェース部
はユーザとシステム (エディタ，プロジェクト制御
部，表示部) との間のデータとコマンド のやりとり

本章では，提案したモデルに基づく進捗予測システムとそれを用いたシミュレーションについて述べる．
プロジェクト記述

エディタを管理する．

(4) 表示部: シミュレート部において得られたデータを画
プロジェクト
データベース

面に表示する．また，シミュレーションデータベースに保存されている過去のプロジェクトのシミュレー
ション結果を表示することも可能である．データの評価を支援するためのグラフ表示機能や統計処理機
能を持つ．

プロジェクト記述
ユーザ
プロジェクト制御部

ユーザ
インタフェース(プロジェクトモデル)(5) エディタ: エディタはプロジェクト制御部の入力であるプロジェクト記述の作成を支援する．GUI によ・作業モデル名・パラメータるプロジェクトの記述が可能である．提案モデルにおける全てのパラメータの設定が行なえる．エディ
タの出力はプロジェクト記述ファイルとなり，プロ
ジェクトデータベースに保存される．

シミュレーション
結果

表示部
・プロセス図・グラフ

作業シミュレート部(作業モデル)

シミュレーション結果システムの実現に際して，高速な計算を求められる作
業シミュレート部とプロジェクト進行制御部は C 言語を用いて記述した．一方，高速性よりも操作性が重要である表示部とエディタは Tcl/Tk で記述した．プログラムの
サイズは，C 言語で記述した部分が約 1000 行，Tcl/Tk
で記述した部分が約 2500 行 であった．

作業モデル記述シミュレーション
データベースペトリネット
データベース

図 3: システム構成

4.2
4.1

システム構成システムの動作

シミュレーションの実行は 1 日を単位として次のように進められる．作業の進行を 1 日進める時には，先ずプロジェクト進行制御部が前日までの進行状況，各作業の開始条件，終了条件に基づいて，その日に実行すべき作業を決定する．次に，作業シミュレート部に 1 日分の作業を行うように指示を出す．作業シミュレート部では，指示された拡張 GSPN に従って作業を実行する．各作業では，その実行開始時に割り当てられた作業量を消費していき，これが 0 になった時に実行終了とみなす．
シミュレーションは任意に停止したり，再生することができる．また任意の時点の状態を保存可能であり，保システムの全体構成を図 3に示す．システムはプロジェ
クト制御部，作業シミュレート部，ユーザインタフェー
ス部，表示部，エディタから構成される．実線が制御の流れを，点線がデータの流れを表す．次に各部について説明する．

(1) プ ロジェクト制御部: プロジェクト制御部は，プ
ロジェクトデータベースに保存されているプロジェ
クト記述に基づいて，作業シミュレート部でシミュ
レートすべき作業モデルとそのパラメータを設定す

5

図 4: 実行画面
存した状態は前述のプロジェクト記述の形式をとっているので，これを用いてプロジェクトの状態を変更する (例えば，ある時点から作業者の数を増やす) ことも可能である．また，シミュレーション途中の各種パラメータの変更も行える．
シミュレーションの実行中の一例を，図 4に示す．同
図では画面に各作業に割り当てられた作業量と消費した作業量，各プロダクトのサイズと残存フォールト数が表示されている．これらの情報を見ることで，プロジェク
トの進行状況を視覚的にとらえることができる．また，工数と残存フォールト数の移り変わりを示すグラフを表示することも可能である．

4.3

機能設計



A2

A7

A8

A9

A 10

コーディング A11

A 12

A 13

A 14

A15

A 16

A 17

A 18

単体デバッグ A 19

A 20

A 21

A 22

統合テスト

A 23

A 24

A25

統合デバッグ A 26

A 27

A 28

単体テスト

機能テスト

機能デバッグ

事例 1: 各作業 Ai (2  i  34) は前の作業が完全に終了してから開始する理想的な場合．
事例 2: コーディング作業 A11 ; A12 ; A13 ; A14 の開始
条件を \直前の詳細設計が 70 %終了した時点" とする例外的な場合 (他の作業の開始条件については事
例 1 と同じ )．

A3

A5

詳細設計

ケーススタディ

A1

A4

構造設計

図 5に示す作業の流れで実行される開発プロセス [16]を考える．ここでは次の 2 つの事例についてのシミュレー
ションを行なう．


AA
AAA
AAAA
AAA
AA
AAAAA AAAAAAAAAAAA
AAA
AA
AA
AAA
AAAAAAAAAA
AAA
AA
AA
AAA
AAA
AA
AA
AAA
AAA
AA
AA
AA
AAA
AAA
AA
AA
AAAAA AA
AAA
AA
AAA
AA
AAAAA
AA
AA
AA

システム設計

A6

A 29

A 30

A 31

A 32

システムテスト

A 33

システムデバッグ

A 34

図 5: 開発プロセスの流れ6

事例 2 では，設計仕様書が不完全な状態で次のコーディ
ング 作業の実行を開始する．つまり，詳細設計の終盤
30%の作業とコーディング作業が並行して行なわれることになる．納期やコストに厳しい制限が課せられる開発
現場ではこのような状況が起こる可能性がある．
ここではこの 2 つの事例をそれぞれ提案モデルを用いて記述し，シミュレーションを行ない，開発期間，フォー
ルト数の変化，開発工数を評価してみる．なお，コミュニケーションレート rcm ，思考レート rth ，記述レート rwr ，フォールト混入率 pin に対して次の (H1)〜(H3) の仮定をおく．以下で，M は作業者数，L は作業者の経験レベ
ルの和，R は入力プロダクトの完成度，D は予定終了期
日までの日数である．また，Kcm ; Kth ; Kwr ; Kin は作業毎に与えられるパラメータ群であり，それぞれコミュニ
ケーション，思考，記述，フォールト混入率に対応する．
(H1) コミュニケーションレートは作業者数の 2 乗に比例し，作業者の経験レベルと入力プロダクトの完成度に反比例する．つまり，

表 4における事例 1 と事例 2 の差 (事例 2 の方が事例 1に比べて開発期間が短くなっているが，工数が多くかかっていること ) の原因について考える．事例 2 では詳
細設計と並行してコーディングが行われていた期間中，そのコーディング作業の入力プロダクトは不完全なままであった．従って，(1) 混入されたフォールト数が増え，その後のテストとデバッグの作業量が増加した，(2) コ
ミュニケーションのオーバーヘッドが増加した，ということが事例 1 と事例 2 の差の原因と考えられる．
実際の開発データを全てのパラメータに対して用いた適用例ではないため必ずしも正確な評価ではないが，提案モデルを用いれば開発現場の実状を反映したシミュ
レーションが可能であることが示せたものと考えている．
表 3: 並行実行開始前までのシミュレーション結果 (100回平均)
並行実行開始直前時点
開発期間の平均
開発期間の標準偏差
開発工数の平均
開発工数の標準偏差
残存フォールト数の平均
残存フォールト数の標準偏差M2
rcm = Kcm 2
LRとおく．
(H2) 思考レートと記述レートは作業者 1 人当たりの経験
レベルと作業者数に比例する．したがって

L
2 M = Kth L
ML
2 M = Kwr L
rwr = Kwr 2
M
rth = Kth 2

事例 2

84

84

3.41

2.85

202

201

7.69

7.53

89

91

8.65

10.01

表 4: 開発プロセス終了時でのシミュレーション結果 (100回平均)
開発プロセス終了時点
開発期間の平均
開発期間の標準偏差
開発工数の平均
開発工数の標準偏差
残存フォールト数の平均
残存フォールト数の標準偏差とする．
(H3) フォールト混入率は作業者数に比例し，作業者 1 人
当たりの経験レベルと入力プロダクトの完成度，予定終了期日までの日数に反比例する．したがって

pin = Kin 2

事例 1

M
2M
LRD

とする．
ただし，現時点ではモデルの記述に必要な開発データが完全には得られていないため，パラメータの一部に架空の値を設定してシミュレーションを行なっている (紙面の都合上，プロジェクトモデルの記述や設計作業以外で用いられるレートを表す関数の詳細は省略する)．
モデルを用いてシミュレーションを行なった結果を表3と表 4に示す．まず，表 3は設計作業とコーディングの並行実行を開始する直前の時点でのシミュレーション結果である．この時点では，事例 1 と事例 2 の間に差異は見られない．次に，表 4は開発プロセス終了時点でのシミュレーション結果である．事例 2 においては，平均開発期間は短かったものの平均開発工数は事例 1 に比べて20 人日増加していることがわかる．事例 1 と事例 2 の開発プロセスにおける相違点は，設計作業からコーディン
グに移る時に並行実行をしたか否かだけであるので，この開発工数の差が並行実行にあることがわかる．

事例 1

事例 2

212

201

9.4

6.5

751

771

22.00

24.75

49

48

7.38

5.67

5 まとめ
本稿では，ソフトウェア開発プロセスのペトリネット
モデルに基づく進捗予測システムを提案した．また，提案したシステムを用いてソフトウェア開発のシミュレー
ションを行ない，その結果に基づいて品質，コスト，開発期間を定量的に評価した．なお，システムの適用に当
たっては開発プロジェクトの実測データを用いて開発現場の実状を反映した事例のシミュレーションを行なうとともに，その結果に基づいて事例の分析を行なった．
今回の適用実験ではモデルのパラメータの設定に当たって一部に架空のデータを用いたため，十分に正当な評価は行なうことはできなかった．したがって，実測デー
タに基づいたシミュレーションを行ない，提案システムの有効性を検証することが今後の課題である．

7

[11] Marsan A. et al.:\A class of generalized stochastic
Petri nets for the performance evaluation of multiprocessor systems", ACM Trans. on Computer System Vol.2, pp.93-122 (1984).

謝辞
本研究に進めるに当たって数多くの貴重なデータを提供して頂き，多大なご協力を賜った オムロン (株) の坂本啓司氏，高木徳生氏に感謝致します．

[12] 大場 充: \ソフトウェア・プロジェクトの実績データ
収集・分析技法", ソフト・リサーチ・センター (1993).

参考文献[13] Ra o D. M.: \Evaluating the impact of process
improvements quantitatively using process modeling", Proc. of CASCON93, Vol.1, pp.290-313(1993).

[1] Abdel-Hamid T. K.: \The dynamics of software
project stang: A system dynamics based simulation approach", IEEE Trans. of Software Eng.,
Vol.15, No.2, pp.109-119 (1989).
[2] Basili V. R. and Rombach H. D.: \The TAME
project: Towards improvement-oriented softwareenvironment", IEEE Trans. Software Engineering,
Vol.14, No.6, pp.758-773 (1988).

[14] Sackman H., Erickson W. J. and Grant E. E.:\Exploratory experimental studies comparing online and oine programming performance", Communications of the ACM, Vol.11, No.1, pp.3-11(1968).

[3] Brooks F. P., Jr.: \The Mythical Man-Month",
Addison-Wesley (1975).

[15] 菅野文友, 吉澤 正 監修:\21 世紀へのソフトウェア
品質保証技術", 日科技連出版社 (1994).

[4] Curtis B., Krasner H. and Iscoe N.: \A eld study of the software design process for large systems", Communications of the ACM, Vol.31, No.11,
pp.1268-1287 (1988).

[16] Takagi Y., Tanaka T., Niihara N., Sakamoto K.,
Kusumoto S. and Kikuno T.: \Analysis of review's
e ectiveness based on software metrics", Proc. of
the 6th International Symposium on Software Reliability Engineering , pp.34-39 (1995).

[5] 古澤, 平山, 楠本, 菊野, 田中: \一般化確率ペトリネッ[17] Tanaka T., Sakamoto K., Kusumoto S., Matsumoto K. and Kikuno T.: \Improvement of software
process by process description and bene t estimation", Proc. of the 17th International Conference on
Software Engineering, pp.123-132 (1995).

トに基づくソフトウェア開発プロセスのモデル化と定量的評価", 第 15 回ソフトウェア信頼性シンポジウ
ム論文集，pp.99-104 (1994).

[6] Furuyama T., Arai Y. and Iio K.: \Fault generataion model and mental stress e ect analysis", The
Journal of Systems and Software, Vol.26, pp.31-42(1994).

[18] Tvedt J. D. and Collofello J. S.: \Evaluating thee ectiveness of process improvements on softwaredevelopment cycle time via system dynamics modeling", Proc. of COMPSAC95, pp.318-325 (1995).

[7] 平山, 水野, 楠本, 菊野: \ソフトウェアプロジェクトの定量的管理のための階層的モデルの提案", 電子情報通信学会技術研究報告 FTS95-74，pp.89-96 (1995).

[19] 山田 茂, 高橋宗雄:\ソフトウェアマネジメントモデ
ル入門", 共立出版社 (1993).

[8] Humphrey W. S.: \Managing the Software
Process", Software Engineering Institute, AddisonWesley (1989). \ソフトウェアプロセス成熟度の改
善"，藤野喜一監訳，日科技連 (1991).
[9] Kellner M. I.: \Software process modeling support
for management planning and control", Proc. of the
1st International Conference on Software Process ,pp.8-28 (1993).
[10] Lee G. and Murata T.: \A -distributed stochastic Petri net model for software project time/cost
management", The Journal of Systems and Software, Vol.26, No.2, pp.149-165 (1994).
8