修士学位論文

題目

ソフトウェアタグデータ収集システムの設計とその試作

指導教員
楠本 真二 教授

報告者
西川 倫道

平成 21 年 2 月 9 日

大阪大学 大学院情報科学研究科
コンピュータサイエンス専攻

平成 20 年度 修士学位論文

ソフトウェアタグデータ収集システムの設計とその試作
西川 倫道

内容梗概
ソフトウェアの開発における定量的データの収集・分析は，ソフトウェア受注者側のプロセス改善やプロジェクトの進捗・品質管理を目的としている．しかし近年，ソフトウェア発注者側の視点に立った開発プロジェクトデータのより幅広い活用が求められ，ソフトウェアへのトレーサビリティの適用が提案されている．ソフトウェアに対するトレーサビリティとは製品品質や開発状況の把握が発注者にも可能なことを意味する．このソフトウェアトレーサビリティを実現する技術としてソフト
ウェアタグに関する研究・開発が行われている．ソフトウェアタグとはソフトウェア開発中に収集された種々のメトリクスをパッケージ化したものであり，実現するにはソフトウェアタグの規格化，ソフトウェアタグの収集・可視化・評価手法の開発，実証実験の実施，法的諸問題の検討といった様々な課題がある．本研究ではソフトウェアタグ実現の一環として，ソフトウェア開発時に作成される実証データからソフトウェアタグデータを収集するシステムを提案する．提案するシステムでは，どのような実証データからどのようなソフトウェアタグを収集したいかを指定することで収集を行う．
また，ソフトウェアタグデータ収集システムの設計を基にプロトタイプを実装した．この際，ソフトウェア開発時に利用される開発支援ツールの機能や特徴を調査し，開発支援ツールから作成される実証データから汎用的にタグデータを収集する方法を検討した．そして，実際の開発プロジェクトに適用してソフトウェアタグを作成し，ソフトウェアタグを用いた開発プロジェクトの分析を行った．
また，プロトタイプの実装から適用を通じて得られた知見から，ソフトウェアタグ収集システムの実
用上の課題を考察した．

主な用語
ソフトウェアメトリクス
データ収集
ソフトウェアトレーサビリティ
ソフトウェアタグ

i

目次
1

まえがき

1

2

ソフトウェアトレーサビリティの実現

2

3

4

2.1

ソフトウェア受発注における問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2

ソフトウェアトレーサビリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.3

StagE プロジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.4

ソフトウェアトレーサビリティ実現上の課題 . . . . . . . . . . . . . . . . . . . . . .

3

ソフトウェアタグ

3.1

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.2

プロジェクト情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.3

進捗情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.4

タグ利用のシナリオ

6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ソフトウェアタグデータ収集システム

84.1

設計方針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

4.2

システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

4.2.1

収集方法特定サブシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

4.2.2

対象データ特定サブシステム. . . . . . . . . . . . . . . . . . . . . . . . . .

10

4.2.3

タグ項目算出サブシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

4.2.4

タグ集計サブシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

プロトタイプシステムの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

4.3.1

対象とするタグ項目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

4.3.2

タグデータ収集の実現方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

4.3.3

プロトタイプにおける収集方法特定 . . . . . . . . . . . . . . . . . . . . . . .

12

4.3.4

プロトタイプにおける対象データ特定. . . . . . . . . . . . . . . . . . . . .

12

4.3.5

プロトタイプにおけるタグ項目算出 . . . . . . . . . . . . . . . . . . . . . . .

13

4.3.6

プロトタイプにおけるタグ集計 . . . . . . . . . . . . . . . . . . . . . . . . .

14

プロトタイプシステム利用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

4.3

4.4
5

4

適用事例

16

5.1

適用の目的

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

5.2

対象プロジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

5.3

実プロジェクトデータのタグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

5.4

タグデータによる開発状況の把握 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

ii

6

考察

23

7

あとがき

24

謝辞

25

参考文献

26

付録

28

iii

1

まえがき
近年，ソフトウェアの大規模化と社会的影響の拡大によりソフトウェアの重要性が高まると共に，様々な問題が発生している [2]．例えば，ソフトウェアに障害が発生することで，金融システムや交通システムなどの重大な社会インフラが停止したり，航空管制システムや自動車安全システムなどが人命に関わる危険を引き起こす．また，それに伴いユーザ・ベンダに莫大な経済的損失を与える．
他にも，開発期間の短縮のためにコストの低減や生産性の向上が要求されたり，情報システム開発に関わる訴訟が頻繁に発生している [22]．
これらの問題を解決するアプローチの一つとして，ソフトウェアトレーサビリティの概念が提案されている．トレーサビリティとは本来，野菜や食肉等の物品の生産・流通履歴を確認可能であることを意味するが，これをソフトウェアに対し適用することでソフトウェアユーザによるソフトウェアの製品品質・開発状況の把握や，ユーザ・ベンダ間の法的係争発生時の処理の短期化を可能とすることが期待されている．
ソフトウェアトレーサビリティを実現するためにソフトウェアタグの研究開発が行われている [20]．
ソフトウェアタグとはソフトウェア開発中に収集された管理データや品質情報をパッケージ化したものであり，ユーザはソフトウェアタグを見ることでソフトウェアがいつ，どこで，誰に，どのように開発されたか把握可能になる．
ソフトウェアタグによるソフトウェアトレーサビリティの実現には様々な課題があり，その一つにソフトウェアタグとなるデータを収集するツールの開発がある．そこで本研究ではソフトウェアト
レーサビリティ実現の一環として，タグデータ収集システムの提案を行う．具体的には，システムへの要求に応える設計方針を検討し，システム構成を設計した．また，プロトタイプを開発し実際のソ
フトウェア開発プロジェクトに適用してソフトウェアタグを作成した．そして作成したソフトウェア
タグからユーザがどのようにソフトウェアの品質や開発状況を把握するのか検討した．
以降，2 章ではソフトウェアトレーサビリティ実現にむけた概況を述べ，3 章ではソフトウェアタ
グの定義について説明する．4 章ではソフトウェアタグ収集システムの設計とプロトタイプの実装について述べ，5 章では，プロトタイプの適用事例について，適用の結果得られたソフトウェアタグ
データの分析を含めて述べる．6 章では，プロトタイプの実装から適用事例を通じて得られた知見か
ら，ソフトウェアタグ収集システムの課題を考察する．最後に 7 節でまとめと今後の課題を述べる．

1

2

ソフトウェアトレーサビリティの実現

2.1

ソフトウェア受発注における問題

ソフトウェア開発においてユーザは要件定義などの上流工程からベンダ任せにするケースが従来多かった [8]．しかし，そういった開発では，要件のあいまいさから設計ミスや頻繁な仕様変更が発生
し，品質低下，重大な不具合によるシステムダウン，コスト増大，納期遅れなどをもたらす．また，障害発生時には，ユーザによる原因や責任所在の追究が困難で，対応が遅れ，甚大な損害が発生するケースも多い．さらに，法的な係争に発展すると，裁判が長期化し，解決まで発注者・開発者双方の被害が増大する．
以上から近年，ソフトウェア開発プロジェクトにおいてユーザの参画が重要視されてきている．しかし，これまでソフトウェア開発におけるデータ収集・分析はベンダ側でのプロセス改善やプロジェ
クト内部の進捗・品質管理を目的とし，ユーザの視点に立って行われてこなかった．そこで，開発プ
ロジェクトデータのより幅広い活用が求められている．

2.2

ソフトウェアトレーサビリティ

2.1 節の問題の解決策としてソフトウェアトレーサビリティの概念が提案されている．トレーサビ
リティとは，物品の生産・流通履歴を確認可能であることを意味し，「追跡可能性」とも言われている．近年，食の安全上の問題から食品に対するトレーサビリティへの取り組みが活発に行われており，生産・処理・加工・流通・販売等の各段階で，情報の追跡・遡及が可能になるよう推し進められている (図 1)．
トレーサビリティの概念をソフトウェア開発に適用したソフトウェアトレーサビリティでは，ソフ
トウェア開発過程で作成される実証データからソフトウェアタグを作成し，ソフトウェア製品に添付して流通させる (図 2)．製品に添付されたソフトウェアタグからユーザはソフトウェアの製品品質や開発状況を把握する．

%&'()!#"$*+() ,-()/(.)01 2* +()      = >@?BA#CBD E9F ()(3)4

6 798;:<,.2052(1 () )  

図 1: 食品のトレーサビリティ[20]なお，過去にソフトウェア開発分野においてトレーサビリティという言葉は，能力成熟度モデル[10] で使用されてきた．能力成熟度モデル（CMMI）とは，ソフトウェア開発組織のソフトウェア開発能力向上のために利用されるプロセス改善モデルである．CMMI ではプロセス改善方法の一つとして要求仕様と計画・開発・成果物間のトレーサビリティの必要性を定義している．しかし，ここで2   
!#"#$%#& ('*),+

*8**-/.0#1

2#
3

45

*
67 

図 2: ソフトウェアトレーサビリティ[20]述べられているトレーサビリティは開発組織のプロセス改善のためであり，ユーザ側にトレーサビリ
ティを与えるものではない．

2.3

StagE プロジェクト

StagE(Software Traceability and Accountability of Global Software Engineering) プロジェクト[20] とは，文部科学省のプロジェクト「次世代 IT 基盤構築のための研究開発：ソフトウェア構築状
況の可視化技術の開発と普及」の略称として，平成 19 年度から奈良先端科学技術大学院大学と大阪大学が産学官連携で進めているプロジェクトである．ソフトウェアトレーサビリティの実現を目的とし，ソフトウェアタグの研究開発を行っている．

2.4

ソフトウェアトレーサビリティ実現上の課題

ソフトウェアタグによるソフトウェアトレーサビリティの実現には以下の課題がある．

• ソフトウェアタグの規格化• タグデータ収集ツールの開発• タグデータの可視化・評価手法の開発• 実証実験の実施• 法的諸問題の検討
このうち，本研究ではタグデータ収集ツールの開発を目標としている．

3

3

ソフトウェアタグ

3.1

概要

現在，StagE プロジェクトではソフトウェアタグ規格 第 1.0 版が策定されている [19]．この規格においてソフトウェアタグは管理データや品質情報など複数のデータから構成され，各データ種類をタ
グ項目と呼ぶ．タグ項目はユーザ・ベンダ間で共有する候補として定義してあり，ユーザ・ベンダは用途に応じてタグ項目を選択しソフトウェアタグを構成する．
タグ項目は全 41 項目あり，プロジェクト情報と進捗情報に大別される．また，各タグ項目は分類，
項番，タグ項目，説明，具体化例，実証データ例，予定・実績の要否，工程別の要否，備考を要素としてもつ．各要素の説明を表 1 に示す．なお，予定・実績の要否とあるが，成果物やプロセス，目標についてベースラインを作成することはソフトウェア開発の改善において重要であるため [3]，いくつかのタグ項目に対し予定と実績による管理を要求している．
表 1: タグ項目構成要素

3.2

要素名

説明

項番
タグ項目
説明
具体化例
実証データ例
予定・実績の要否
工程別の要否備考

タグ項目に割り当てられる通し番号
ソフトウェアタグを構成する個々のデータ種類・タグデータのインデックス
各タグ項目の意味や活用方法など
タグデータの例
タグデータを抽出する元となるプロジェクト情報やドキュメント・生データ
予定・実績値の差分による管理を行うデータ
工程別に管理を行うデータ
備考欄

プロジェクト情報

ソフトウェアタグの内，プロジェクト情報とは開発プロジェクトおよびシステムの基本的な情報を指す．プロジェクト情報はプロジェクトの途中で変更がなくプロジェクト全体を通して不変である．
プロジェクト情報内でタグ項目は 12 個あり，情報の種類ごとに以下の 5 つに分類される．

• 基本情報• システム情報• 開発情報• プロジェクトの階層構造情報• その他
表 2 においてプロジェクト情報の一覧を示す．

4

6㸬ᶆ‽ࢱࢢ㡯┠୍ぴ⾲!"#$%&'()*+01&'()*+,-./012&'()*+3,45678 2&'()*+9:;<=/ !
>?@$%ABC8D2EFGHIJK./ !"#LMNIO/PQL6RRS#T,UVW !"#9XYZB[\+])^ !9_`./P
表
ソフトウェアタグ
プロジェクト情報> !L78 9ab2cd./ef,gh678
ijL&'()*+klm./efL019noP>gh,UVWBpqT678 LrstL019noP

2:

cu

"v




±01



!"#

wx

:

pqyz

{|78 zg"#ÄÅ&'()* ÄÅ&'()*+L:;iñ ÄÅ&'()*+¹ ÈÉÊ2ËÌ2Í
ò !78 L¶·k./& Î2Ï§2Ð§6
+01'()*+L¹u9°.01P!78 LabicdB, Ö×Ø§Ù2[8ªÚ8Û×Ø§Ù2ÚFÜ8¡F+×Ø§Ù6
gh678 PÄÅÑ¸9ÒÓ6¨Ô¿ÀÕ¾hM¾&'()*+HIÖÛ¿£F+[8ªÚ8Û
ôª+6uµ¶·¸¹L&'()*+,-./&'©ªº»¼kL½¾³E´L­`®6B¿LÀk,ÁÂ9JK./QkÀÃ½

Þß01Là`¬áLÊâR
SãäÃ½6Ô¿ÀO/

Ý

ïð01

ñòóªôõLC8DBÀZö ïðBÉÊïðRúR6A÷Åøùk6/°±L01PïðkLûü
ý&'()*+
6þÿABÅøù !6LI4
hPe"ZBìøùRSL#$%í9&'Ô¿B()ïðç*FÛC8Dî019@Õóªôõ_`

ÄÅóªôõ_`L:;i Ø§Ze+,óªôõL-®ÈØ§ ±Öñò !78 L¶·k./ .8Û])^/01,02/3/4­Z &'()*+óªôõL¹u9°.01P e+,óªôõL-®¿¨567/4 !78 LabicdB, -38
<QfW®
gh678 P+,óªôõL?|@H<=ÈØ§9 ¬ {­78
?AZe+,óªôõL?|@Hk<
6
=AVfW9'+,óªôõ,A:;<=>gh6ef




óªôõ0
1

?|B,C½DEiÖ01
LÂ$9Ff/Qk>IG/e
f/?|@H<=RSÖ/ôª+HI9JK./efØ§Ze+,óªôõ,-./LThM6óªôõÊâ
¡ÄÅóªôõLÊâP¸ ìøùNLO./ïðhML=B{ ±Ök(){­¸k./PÞß0 PZehM=6[8ªÚ8Û
1,¹V01>n¯©/Ô¿ <Q)RBL[8ªÚ8Û&=SThM¾
ABº»ÃP½SUSVW78 XSVW78 =6 6ÄÅ^LÄÅóªôõÄÅ,§¨e& `§&'©ª 1&
ç]a8 8\a8 &'()*+
'©ªi^L,_¨WL0 ´2^(b1´2&'+ 1&îB`§^L 6
1P !78 Labicd çcBcBccî&'()*+dB,gh678 P
efW
6ÄÅqlÄÅNLhi,-./01P °±g2hijkg!78 LabicdB, Ñ¸qlLmno2pqoç«¿®2c
gh678 Pr®îÈ°±g2hijkgRSK>Ä°¶·²³ABÅøù2 &'()*+qlLst=u6
ìøùNIL´û,µs
./#øÙBv8*BLÄÅhiBwxÄ
ÅhiBy8õ LÄÅhiu6

]

·

«


&'()*
+Lst_
Ì01

&'()*+@ ñò&'()*+LÄÅ@H
H,-./01+,çî&'()*+01

:@ü"


<QfW®
6

&'()*+

T½Ö
_ÌÖ
6

&'()*+>+,çî&' +,58&'()*+L=B&'()*+ &'()*+
()*+9_Ô¿B\L=i 6
T½Ö+,58&'()*+,-./
_ÌÖ
01
6
\LjB !78 Labi
cdB,ghBÀZöAK§
678 P

5

13

Ý
YA&'!0õZ[B\L
jA&'()*+Z[

Ý

ql®
Åø
b2^ó8+¬ {­78

ÆÇz=B³E´ {¿ç|}23}26}îBÉhlÙB
uµ&'()*+LÆÇçÄÅ/C8Dk
À,uµ&'()*+~LÆÇ>O/RÈÆÇ6Z/7/7|8B
hiª´5¥S¸ Bcd2ÖB28´BÄÅ&0ê+\a8õÈ6,8u6
¬ {­78
B@/Ä/)R9no5BH/
/î
6
<QfW®
<@
6
6

p&'()*+ &'()*+> L&'() p&'()*+L&'()*+
01*+L+,çî&'()*+I
O/Ô¿B<



\Lj

L }~

&'()*+ &'()*+9$,./&'()*+
6
efL 
& ( *+









B Åø¼½
ÄÅ°±L0 ñò&'()*+LÄÅ9 ¦69§¨ ^©ª£F+«
1ñ./°±L01P$¶,  8¡¢£'F¤¥¥ABìøùk6/°±01k e^©ª£F+«¬L&'©ª­`®$ ¬,-./0%¯eA°±`²®³E´
6/P
1
ql®
b2^ó8+ÄÅ°±B¶·¸¹LÆÇ
6
6

ÄÅ&'()*+åæçè§éêë8(BìíÄÅîBØ§éêë8(
6

ÄÅ01

¯2{ <Q­Lhú húÝÝÝñT½Bñ £FL:;<=9JK./
ef
Ý

Ý

Ý

Ý

Ý

ÅøRSH¯IL28Û 1
õçq<@î¢£¤u&'()*+¥k$¦./&'()*+L !>§¨
Z6=©ª6S6¨!78 fW01ç`§fW
/78
î6

3.3

進捗情報

ソフトウェアタグの内，進捗情報とはソフトウェア開発によって得られた作業の進捗状況や，成果
物やプロセスの品質を表す情報を指す．進捗情報はプロジェクト情報とは異なりプロジェクト途中で変化する．
進捗情報内でタグ項目は 29 項目あり，そのタグ項目がどの開発プロセスに関するかでさらに以下の 8 つに分類される．

• 要件定義• 設計• プログラミング
• テスト
• 品質
• 工数
• 計画・管理• その他成果物
表 3 において進捗情報の一覧を示す．なお，タグ項目名の後ろに [推移] という語句が付けられているものは，時系列で連続するデータが想定されるタグ項目である．

3.4

タグ利用のシナリオ

ソフトウェアタグ定義をユーザ・ベンダがどのように利用するのか一例を述べる．ソフトウェアタ
グの内，19 番プログラミングの規模としてソースコードからコード行数を，20 番プログラミングの変更としてソースコード行数の差分量を選択したとする．これにより，ユーザは実装時にコード行数
がどのように推移して作成されたか，また，日々のコード行数の推移がどれくらいの変更・削除・追加によって行われたかを把握可能になる．他に，30 番の欠陥対応件数として不具合消化数を選択す
れば，不具合を修正するためにどの程度ソースコードの修正を行ったかも分かる．

6

!"#$%&./'()*+,-./012'()*3456-789:; !
<=>%&?2@ABCDEFGHIJ;K !"#-LMHNKOP-QRRS#TUVWX !"#9YZ[2\]^_`a !9b';KO<cdef?2ghij[k?%lGmHnopqrstuA jvlpqKO
wwnoGm?2xyzC{|C}|C~-




CC

w
w

$

$$
QSqK<./UX;Köno"#?2UVWXxyxyzy 6¾zUol;KO<UVWX2TQuA --9O

表 3: ソフトウェアタグ:進捗情報

¡

"¢

!"#
@ABªa«E!

­lÃ


´

µ¶cdefÏÐcdef£¤¥¦§¨uA ¦­UX[X@ABU'zrªa @ABªa«E!§¬­®¯
@ABªa«E!"#®­2«E!UX;K@ABªa«E!¯±²$@ABªa«E!¯±®³@ABªa«E!"#®Q
~·H+'[r­®
¸¹º»¼"#º@A6½A6ºa¾ A2¿
À­2»¼2ÁÂQÏÐpqr­®
µ¶-noÈÉUÑÒ

@ABªa«E!]Í^@ABªa«E
!8{à
Q
­lÃÄ
Q
­lÃÄ
­lÃÄÏÐÓÔ
Q

Î
Õn

µ¶cdefÕn'()-µ¶»¼Õn$ÝAÞ®Cßà®C¸¹®C]áâã ÆÇÕnÄ
<ÖµC×ØCÙÚÛÜÛzU ®C"#®Cäåæç-®º¾è6®ºéêë34 »¼ÕnÄ
bØÕnÄ
no;K
!èì®2íQ»¼®QbØÕn$uA "#®2îÁîuA ®2îÁî òóÕnÄ
Q
3456®2îïðAñã®$Q
Q

ÏÐcdefÏÐpqrÕn'()-®2j[ µ¶-noÈÉUÑÒ
k?ÏÐõ

­-øù²­lÃH+'pqr­-§ ÕnUûqSqr­®³­®
ú²µ¶cdef34!èýE!'()-µ¶æþÿQ<ÖµC×ØCÙÚÛÜÛzU
no;KÏÐpqr34!èì-®2j[k ÏÐ¯®2%&'®2()'®Q
?ÏÐõ

ô

÷

34!èýE!

üÏÐcdef+,µ¶cdefð6^ÏÐcdefÏÐpqrð6^"#®*ÏÐõ ()ð6^"#®2ÏÐð6^"#®Q_-ð6^-78ð6^"#®³@6ðìµ¶.\A6 A!'
®Q2

´

P¥
Î

78

LU$A01
LU$A+,_ô\A6 A!
Q

ð6^½A6
ð6^M(\A6 A!
­lÃÄ
Q

'()VWÄ2ÕnÄ234! LU$A¯®2JYµ¶2§Z¯®2@AB[ LU$A]Í^Q
èì A!2ð6^VWÄQ2- ¸-J\2LU$AgGQLU$AUX;K
LU$A3456-782j[k? LU$Ax®²2LU$A_-Q
LU$A]Í^LU$AJYLU$AJY-78
\A6 A!2öÕnÄQ
LU$A3456-782j[k? LU$A`a®2`a_-2bË`a®d LU$A]Í^LU$AJY-78
eQ
LU$AJY
\A6 A!2öÕnÄQ

cd­®cdefð6^Õn-78Ê A!78

cdJV­®

cd-JV./2JVlmbËP¥®2efnogG2pEcdq§¬¯®2¡rcdst§¬¯®Q

cd_-

ð6^Õn-78Ê A!78

pEcd®9@6ðìµ¶HuKv
bwaE­®³6ðê3®Q





14

7

°

]áâã"C#Þ$Aã"]áâã"C#Þ$Aã"]áâã"C#Þ$Aã"°ð6^½A6ÏÐÓÔQ

ÿ GHøù2ÿ Iøù2­UJ;KKéLêÞ².MËNOûqð6^2$Q
ð6^-./234!èì-78 ð6^½A6./2P¥ð6^"#de2ð6^ ð6^½A6
34!èìP¥²2¾«ðQKãR6./Q ð6^n¸Ä
ð6^M(
xyST:
Q

ü

Å9­-ÆÇÈÉÊ;KR?ºËÌÍ"°\A6 A!
«*Þ^«ÐÖÓÔ
Q

LU$A`a²cdef
÷

°

ÆÇÕnÄ
»¼ÕnÄ
bØÕnÄ
òóÕnÄ
öÕnÄ-Ï
ÐÓÔ
Q
­lÃÄ
ÆÇÕnÄ
»¼ÕnÄ
bØÕnÄ
òóÕnÄ
Q

34!èì-78./012
34
5
6
7
8
4
9
2å:ÿ4
;
8
2ÿ<2¾4AEJ²2 = \A6 A!
E^>?ÚÛ²Q
Q
ð6^-µ¶
ð6^"#®Q
ð6^½A6ð6^n¸Ä
<ÖµC×ØCÙÚÛÜÛzU
Q
no;K



|lC§ ©
Z-}
°

ð6^M(
efSTà
78ST:
Q
ð6^M(
efSTà
78ST:
Q
ð6^M(
efSTà
78ST:
\A6 A!
Q

°

A
B

w@6ðìµ¶CÊAB$µ¶CRSDEF

°

°

°

°

°

cdg[rxy"2hijÊUjknAB
w@6ðìµ¶CÊABüwcd­®CRSDE
F

"#$%&'()*+,-.

/0%1234'()56(783!

q3

RSTUVW,;<XYZ[\,-.]^_`aopq3

opcrseq3htuvwo
pq3

n
`

q3cse<,&*+:
yz{|}6~k6(l6m'();<BC

XY(?@XY(,?@cseXY( 
1XY( ¡,¢ XY»UW)+£c¤¥¦§¨©ª,~(W3BCah
9:«¬XY(cse­®hXY(¯_ XY»UW)

XY( ¡L{°,op±,²³, ?@+9:³´c¤¥¦hyz{|}6
XY(?@('VXµLc* ~¶·¸,3¹º?@$«,3c¤ qx?@A
¥¦
·¼½
BC
BC

¶·{¿ÀÁ

Â6ÃÄÅÆ±hÄÅÆ±Ç,ÈÉÀÁÊËÌ

¶·,Í±ÎÏÐÑ3ÎÒÓÔÎ·¼3Î ·¼½·¼½ÔÎÈÉÕ3BC
BC

ßàá(Wâã3

á(WäåæçèÇéêNÊË ØÙ¶·ÇëìOá(Wâã3,ßàÎ ·¼½
íîÎïðÎñ,ò,âãÇóôe
á(W?@AÌBCÞá(Wâã,õöÍ±
M
ñ,ò<


qx?@A
yz{|}6~BC
]933a4q3
4q3*+qx
('VX34q3]qxa/0%1234q3'()qxJBC



¾

ÿ

!"

nþ
vwÿ

!"

n0

EFGH
!IJ78KLEFGH
!MJ"#
23K
NOP1Q
D

TUVbcdefg[63hTUVbcdefi k6(l6m
j3BC
BC

I

+9?@

'()+9:'()56(
'();<
=>?@A
-.?@A
BC

á(W÷æ²øcBù´ á(W?@âã,úûÎüýõöÍ±
NÊËÌ

·¼½
á(W?@ABC

#<, $% &'()*)+c+,sem-./Å)+9:BCvw#<,3h12 vw53hvw66»3BC¦3vwÔ4m-./Å)v
w78
BC

4

ソフトウェアタグデータ収集システム

4.1

設計方針

D
EFGHnJopq3KL<, BCNOP1Q
D¶·§r2Ö×¶hØÙ¶·hÚÛÜÖÝBC
DD
#<§9:.;<h+9:h(5».6<ABC

ソフトウェアタグ収集システムに対する要求をどのように実現するか述べる．
まず，多くのソフトウェアタグデータに対応し収集可能であることが要求される．そこで，基本的なメトリクスの収集機能は収集システムが提供するとし，もし提供するメトリクスで対応出来ない
場合は，システム利用者側でメトリクス収集機能を用意すれば，ツールに組み込み可能にする．
また，低コストでタグデータが収集可能であることも要求される．これには，極力タグデータはシステムが自動収集することで対応する．収集システムを用いるだけでソフトウェアタグが作成でき，余計な作業を必要とさせない．
タグデータ収集後に得られたソフトウェアタグが分析しやすいものであることも要求される．これは，タグデータ収集後に，ユーザが収集結果を理解しやすいよう視覚化等の分析が行われるためである．そこで，タグデータ分析ツールが利用しやすい形式でタグデータを出力することで対応する．

4.2

システム構成4.1 節の方針に基づき設計したソフトウェアタグデータ収集システムの構成について述べる．

8
15

収集システムへの入力は，ソフトウェア開発時に発生する日々の開発履歴データと収集設定とする．日々の開発履歴データとは例えば，日々一定間隔でバックアップをとったプロジェクト開発フォ
ルダや，構成管理ツールで管理されたデータなどである．また，入力として開発履歴データを得ただけでは，どのタグ項目を何から収集するのか判別できないため，収集対象と収集方法の特定を行う必要がある．そこで，これらの情報を特定するためにシステム利用者に収集設定の入力を求める．
具体的には以下の項目を選択してもらう．

• 収集したいタグ項目は何か• どの実証データから収集を行うか• 収集対象はどのような開発支援ツールを介して得られたデータか• 収集対象のデータ形式は何か
システムの出力はソフトウェアタグデータである．出力形式はタグデータ分析ツールの利用に適したものとする．
収集ツールではシステム利用者が使用したいメトリクスを提供していない場合が 2 通り考えられる．一つは，プログラムを作成すればメトリクス計測可能だが，収集システムでは提供していない場合である．もう一つは，メトリクスの計測が手作業でしか出来ない場合である．例えば，定型フォー
マットの存在しない文章ファイルからメトリクスを計測する場合が挙げられる．前者に対してはメト
リクス計測プログラムをシステム利用者側で作成してもらうことで対応する．プログラム作成には収集システムが API を提供し，収集方法の設定時に作成したメトリクス計測プログラムを指定することでプラグインとして導入可能にする．後者に対しては，利用者側でメトリクス計測後に特定のファイル形式で計測データを作成してもらう．そして，収集方法の設定時に入力データとして指定することで対応する．例えば，csv 形式や xml 形式で作成された計測データを指定し，収集したいタグ
データとどのように対応をとるか設定する．
図 3 に設計したソフトウェアタグデータ収集システムの概要図を示す．開発データ履歴を入力とし，また，システム利用者から収集方法を設定してもらうことでソフトウェアタグデータを出力する．データ収集システム内部は収集方法特定，対象データ特定，タグ項目算出，タグ集計の 4 つのサブシステムで構成する．各サブシステムについて説明する．

4.2.1

収集方法特定サブシステム

収集設定をシステムユーザに入力してもらい収集方法を特定する．特定した情報のうち，タグ項目
に関する情報はタグ項目算出サブシステムへ，収集対象となる実証データの情報は対象データ特定
サブシステムへと送る．

9

< 1C
3=?>A@3B
IJ

MONQPSRUT !S"V$W%
KL

/0:
4;
65 798

D?EAFH:G /@3B 

!#"$&%('/ 0132 )

*&+&,.-

図 3: データ収集システム概要

4.2.2

対象データ特定サブシステム

収集方法特定サブシステムから送られた収集対象の情報を用いて，開発データ履歴から収集対象を特定する．例えば，収集対象となる実証データがどのような構成で履歴内に存在するのか，構成管理ツールで管理されているのかなどを判別し，各状況に即した特定を行う．特定した実証データはタグ項目算出サブシステムへと送る．

4.2.3

タグ項目算出サブシステム

タグ項目ごとに実証データからメトリクスを計測する．収集方法特定サブシステムから送られた
タグ項目情報をもとに使用するメトリクスを決定し，対象データ特定サブシステムで得られた実証
データから計測を行う．計測結果はタグ項目ごとにタグ集計サブシステムへと送る．

4.2.4

タグ集計サブシステム

タグ項目算出サブシステムから得られた各メトリクス値を集計し，ソフトウェアタグデータとして出力する．この際，タグデータ分析ツールが利用しやすい形式にデータ変換を行う．

4.3
4.3.1

プロトタイプシステムの開発対象とするタグ項目

ソフトウェアタグ定義ではタグ項目の各メトリクス値として実際に何をとるかはユーザ・ベンダ間の協議で決めるものとし，具体化例を挙げるに留まっている．そこで，まずどのタグ項目に対し何をタグデータとして収集するのかを決定し，そのタグデータをどのような実証データから収集するか

10

表 4: プロトタイプが収集するタグデータ
分類

項番

タグ項目

タグデータ

要件定義

14
15
16
17
19
20
21
29
30
31

規模 [推移]変更 [推移]規模 [推移]変更 [推移]規模 [推移]変更 [推移]複雑度
欠陥件数 [推移]
欠陥対応件数欠陥対応密度

ユースケース・アクターの数
追加，変更されたユースケース・アクターの数
UML 図の数
追加，変更された UML 図の数
コード行数
追加，変更されたコード行数
CK メトリクス
不具合数
不具合消化数
不具合数 ÷ コード行数

設計
プログラミング

品質を決定する．今回開発したプロトタイプでは進捗情報の 10 項目を対象とし，各項目で何をタグデー
タとするかは表 4 のように選択した．

4.3.2

タグデータ収集の実現方法

特定のプロジェクトに特化せず，多くのプロジェクトに対応可能なデータ収集を行うことを目指した．そこで，まず開発現場でよく使用される開発支援ツールを調査し [7]，どうすればそれらツールから包括的にタグデータを収集できるか検討した．ソフトウェアタグの分類ごとにタグデータ収集方法を述べる．
要件定義ではユースケース図の構成要素であるユースケース・アクターの数を収集する．一般的にユースケース図の作成時には UML モデリングツールが使用される．実際の開発現場では UML モデ
リングツールとして，JUDE[14]，Rational Rose[12]，Microsoft oﬃce Visio[16] などが主に利用されている．これら UML モデリングツールは作成したモデルを XMI 形式 [23] で出力するという共通した機能をもつ．XMI(XML Metadata Interchange) は，抽象的なモデルをツール間で交換可能にするために OMG[17] が策定した標準規格である．そこで，この機能に着目し，XMI 出力されたファイル
からユースケース図の情報を抽出する．
設計では，要件定義同様に UML 図作成のために UML モデリングツールが使用されるので，UML
モデリングツールから XMI 出力されたファイルから UML 図の数を抽出する．
プログラミングでは，一般的に構成管理ツールが使用される．構成管理ツールとはソースコード
やドキュメントの日々の進捗を管理するツールであり，Subversion[21] や CVS[6],[15] が知られている．これら構成管理ツールはプロジェクトデータを作業リポジトリに登録して用いられる．そこで，
この作業リポジトリから日々登録されたソースコードを取得し，解析を行う．
品質では，バグ管理ツールが使用される．EPM[5] はソフトウェア開発で発生するデータからプロジェ
クトの情報可視化を行うツールであるが，データ収集対象となるバグ管理ツールとして bugzilla[11]や影舞 [9] を挙げている．これらバグ管理ツールは登録されたバグを様々な条件で検索し，結果をCSV 形式で出力する機能がある．そこで，この機能に着目し csv 出力されたバグ検索結果から不具合数，不具合消化数といった品質情報を求める．

11

4.3.3

プロトタイプにおける収集方法特定

収集方法の特定には収集したいタグ項目，収集対象の情報をシステムユーザが指定する必要がある．そこでユーザインターフェースを提供し，各情報を入力してもらう．例えばタグ項目としてプログラミングの規模を収集する場合に，開発支援ツールとして構成管理ツール subversion を，タグデータとしてコード行数をシステムユーザが指定する．

4.3.4

プロトタイプにおける対象データ特定

収集対象となる実証データについて使用した開発支援ツールやファイル形式が分かっていても，開発履歴フォルダの指定のみでは対象データの特定が正確に行えない．そこでソフトウェアタグ構造にならった図 4 のフォルダを用意し，各タグ項目に該当するフォルダに収集対象となる実証データを格納するという入力制限を加える．そしてこのフォルダ構造に基づいて実証データの特定を行う．

図 4: ソフトウェアタグ定義にならったフォルダ構造12

4.3.5

プロトタイプにおけるタグ項目算出

各タグ項目でタグデータの導出が異なるため，分類ごとに分けて説明する
要件定義と設計ではユースケース図・UML 図に関する情報を UML モデリングツールの XMI 出
力から収集する．そこで XMI ファイルの解析に SDMetrics[18] を利用した．SDMetrics は XMI ファ
イルから UML 図のデザイン計測を行うツールである．UML 図に含まれる種々の要素数を計測することが可能であり，また，2 つの XMI ファイル間で要素数に基づいた差分も計測できる．要素数の計測を用いてユースケースや UML 図の数を算出し、差分を用いて変更を算出する。
プログラミングではソースコードを構成管理ツールのリポジトリから得る．ソースコードからコー
ド行数や CK メトリクスといったソフトウェアメトリクスを計測するために MASU[4] を使用する．

MASU はソフトウェアメトリクスをプラグインとして自由に追加可能なメトリクス計測プラットフォームである．MASU の計測結果からソースコード行数と CK メトリクスを得る．なお変更については連続するリビジョン間の差分を求める．使用したソフトウェアメトリクスについて詳細をタグ
項目ごとに示す．

• 項番 19，規模– LOC(Line of Code)
ソースコードの行数．空行やコメント行は除く．

• 項番 20，変更– ADD
追加されたソースコードの行数．

– DELETE
削除されたソースコードの行数．

• 項番 21，複雑度
CK メトリクス [1] を使用．
– WMC (Weighted Methods per Class)
クラスのメソッドの重さ (複雑さの総和) を 計測する．WMC が高いほど複雑であり，メンテナンスのコストがかかることを意味する．

– DIT (Depth of Inheritance Tree)
クラスのスーパクラスの数を計測する．DIT が高いほど，継承されている変数やメソッドが多いことを表す．

– NOC (Number Of Children)
クラスのサブクラスの数を計測する．NOC が高いほどサブクラスへの影響力が強い．

13

– CBO (Coupling Between Objects)
クラスに関係しているクラスの数を計測する．CBO が高いほど他のクラスに依存していることを示す．

– RFC (Response For a Class)クラスに関係しているメッセージの数を計測する．RFC が大きいほど受信したメッセージを遂行するために，発信しなければならないメッセージの数が多いことを示す．

– LCOM (Lack of Cohesion Of Methods)
クラスの凝集性の欠如を計測する．LCOM が小さいほど凝集性が高く，メソッドの強度が高いことを表す．
品質ではバグ管理ツールのバグ検索結果からバグに関する情報を収集する．バグ検索結果として表示される csv 出力の内容は自由に設定可能であり定型がない．そこで，タグデータとして何が欲しいのかによってシステムユーザが検索結果の出力項目を決める必要がある．プロトタイプではバグ検索結果として「バグが報告された日時」，「最終更新日時」，「バグが修正されたか」の情報をもつと仮定し，不具合数・不具合消化数を求めた．

4.3.6

プロトタイプにおけるタグ集計

対象データ特定において図 4 で示されるフォルダ構造を用いて開発履歴データの入力を行ったが，タグデータ収集結果も同様のフォルダ構造で出力する．例えばディレクトリ”C:\SoftWareTag”を出力先フォルダとしたとき，要件定義における規模の計測結果はディレクトリ”C:\SoftWareTag\要件
定義\規模”下に格納する．

4.4

プロトタイプシステム利用例開発したプロトタイプの利用例を示す．まず，起動すると図 5 の画面が表示される．＊１で収集し













図 5: プロトタイプ:開始時画面

たいタグ項目の分類を選択し，＊２でタグ項目を選択する．＊３では収集対象となる実証データがど14のような開発支援ツールから得られたものかを選択する．そしてタグデータとして何をとるかを＊ 4で選択する．選択後に＊ 5 の決定ボタンを押すと”！”マークが収集方法を選択した項目の前につく．
要件定義の規模に当たるものとして UML モデリングツール JUDE[14] の XMI 出力からアクターの数を計測するとしたときの収集設定画面を図 6 に示す．すべてのタグ分類，タグ項目に対して選択が

図 6: プロトタイプ:収集設定段階

終われば後は入力となるディレクトリ＊ 6 と収集結果出力先＊ 7 を指定し，実行ボタン＊ 8 を押せ
ばタグデータを収集する．

15

5

適用事例

5.1

適用の目的

ユーザがソフトウェアタグからソフトウェアの品質やプロジェクトの開発状況が把握可能であるかを調べることが適用の目的である．そこで，プロトタイプでは収集しない他のタグ項目についても手作業でメトリクスを収集し，ソフトウェアタグの効用をはかる．

5.2

対象プロジェクト

ITSpiral[13] で作成された実プロジェクト教材に対してプロトタイプを適用する．これは大学の履
修登録プログラムを開発した際に得られた開発データであり，要件定義，設計，実装，テスト等の開発プロセスでさまざまな実証データが存在する．開発期間は 5ヶ月で，総データ量は 450MB になる．
実プロジェクト教材で収集されているデータを表 5 に示す．
表 5: 適用対象プロジェクトで収集されているデータ
プロセス名

収集データ

要件定義
要求
分析・設計

要求仕様書，業務フロー図
ユースケース図，アクター定義書，品質要求書
クラス図，コラボレーション図，シーケンス図アーキテクチャ仕様書，エンティティクラス設計書
コントロールクラス設計書，バウンダリクラス設計書
ソースコード，API ドキュメント，静的チェック記録（checkstyle,FindBugs,PMD,CPD,Jdepend）
テスト計画書・仕様書
内部・外部レビュー記録，プロジェクト管理記録
変更経緯説明書

実装
テスト
プロジェクト管理

なお，表 6 が示すように開発支援ツールを各開発プロセスで使用しており，収集データの一部としてツールの実行結果やプロジェクトデータが存在する．
表 6: 実プロジェクト教材で使用された開発支援ツール
ツール名

説明

使用開発プロセス

JUDE

UML モデリングツール

要求・分析・設計

Eclipse

統合開発環境実装

影舞

バグ管理ツール

テスト

Subversion

構成管理ツール

実装

Jmeter

負荷テスト計測ツール

テスト

16

5.3

実プロジェクトデータのタグ

プロトタイプでは進捗情報 29 項目の内，10 項目に対応している．実プロジェクトデータから手作業で他のタグ項目についてメトリクスを収集した結果，進捗情報のうち表 7 の 12 項目のタグデータを新たに得た．
表 7: 手作業により得られたソフトウェアタグデータ
分類

項番

タグ項目

タグデータ

要件定義
テスト

13
22
23
24
25
26
27
28
32
33
34
35

ユーザヒアリング情報
規模 [推移]変更 [推移]密度
消化レビュー状況
レビュー作業密度
レビュー指摘率 [推移]
欠陥指摘率
静的チェックの結果
作業工数
生産性

ユーザヒアリング実施件数
テストケース数変更されたテストケース数
テストケース数/全体行数
消化テスト数
レビュー回数
レビュー時間/全体時間
レビュー指摘数
欠陥件数/消化テスト数
FindBugs 指摘件数
作業時間
行数/作業時間

品質

工数

計測したソフトウェアタグを示すがその際，どの程度細分化して情報を示すか決定する必要がある．タグ項目 19 番プログラミングの規模を例に挙げると，ソースコード行数の総和を示すのか，それともサブシステム毎に分けるのか，またはファイル毎やクラス毎に分けるのかを決定しないといけない．そこで，タグデータの粒度を表 8 のように設定する．レベル 1 は粒度をもっとも荒くした場合のタグデータであり，レベル 2 は一段階粒度を細かくしたタグデータである．
なお，タグ項番 13,29〜32 においてレベル 2 を設定していないが，これは今回の適用対象から得られた欠陥件数情報がサブシステムやクラス単位，またはバグの種類等の詳細データを持たず細かく分類できなかったためである．

17

表 8: タグデータの粒度
分類

項番

タグ項目

レベル 1

要件定義

13
14
15

ユーザヒア
リング情報
規模 [推移]変更 [推移]16規模 [推移]ユーザヒアリング実施件数
ユースケース図数
変更された
ユースケース図数
UML 図数17

変更 [推移]変更された UML 図数

19規模 [推移]全体のソースコード行数20

変更 [推移]

21
22
23

複雑度
規模 [推移]変更 [推移]

24

密度

25

消化

全体の変更されたソースコード行数
全体の CK メトリクス
テストケース数
変更された
テストケース数
テストケース数/
全体行数
消化テスト数26

レビュー状況

レビュー回数27

レビュー時間/全体時間

29
30
31

レビュー
作業密度
レビュー
指摘率 [推移]
欠陥件数 [推移]
欠陥対応件数欠陥対応密度

32

欠陥指摘率

33

静的チェック
の結果

設計

プログラ
ミング

テスト

品質

28

品質

レベル 2

レビュー指摘数
全体欠陥件数
全体欠陥対応件数
全体欠陥件数/
ソースコード行数
全体欠陥件数/消化テスト数全体 FindBugs 指摘件数

ユースケース・アクター数変更されたユースケース・
アクター数
クラス図数，シーケンス図数
コラボレーション図数
ステートチャート図数
アクティビティ図数，配置図数変更されたクラス図数
シーケンス図数
コラボレーション図数
ステートチャート図数
アクティビティ図数，配置図数
サブシステムのソースコード行数変更されたサブシステムのソースコード行数
サブシステムの CK メトリクス
システムテスト・総合テスト数変更されたシステムテスト・
総合テスト数システムテスト数/全体行数
統合テスト数/全体行数
システムテスト消化数
総合テスト消化数
内部レビュー回数
外部レビュー回数
内部レビュー時間/全体時間
外部レビュー時間/全体時間
内部レビュー指摘数
外部レビュー指摘数

サブシステムの FindBugs 指摘件数

プロジェクト情報の適用結果を表 9 に示す。次に進捗情報を粒度別に示す．表 10 と表 11 は，最終成果物についてそれぞれレベル 1 とレベル２で表したものである．表 7 はレベル１の日々の履歴を省略して表したものである。省略した部分は付録として添付する。

18

表 9: プロジェクト情報

表 10: 進捗情報レベル 1

19

表 11: 進捗情報レベル 220

表 12: 進捗情報レベル 1 履歴 (一部省略)

21

5.4

タグデータによる開発状況の把握

計測結果から，いくつかのタグデータをグラフ化したものを示す．図 7 はソースコード全体のコー
ド行数と変更量の推移を表し，図 8 は CK メトリクス [1] の推移を表したものである．

*A の期間において，コード行数はほとんど変化していないが，変更量が大きい．そこで，同期間において CK メトリクスの推移を見ると，減少していることが分かる．CK メトリクスはプログラムの複雑度を表すメトリクスである．そこで，この期間では新たに追加や削除が行われたのではなく，リファクタリングが行われたのではないかと推測できる．実際に構成管理ツールからソースコードの変更内容を調べたところ，リファクタリングの実施を確認した．このように，ソフトウェアタグを用いることでユーザは適用対象プロジェクトの特徴を把握，分析可能である．

図 7: ソースコード行数と変更量の推移

図 8: CK メトリクスの推移

22

6

考察
プロトタイプの適用結果を示す際に各タグデータを粒度でレベル分けして表示した．これは適用結果を分かりやすく示すために行ったが，本来はタグデータの粒度はユーザ・ベンダ間の協議で設定するものとソフトウェアタグ規格で設定している．しかし，ユーザ・ベンダがタグデータの粒度を自由に決定するとなると，ソフトウェアタグデータの収集やソフトウェアタグの視覚化といったツール
開発の際に一概に対象データを決定することが出来ない．そこで，タグデータの粒度定義をソフト
ウェアタグ定義において行う必要があるのではないかと考える．ソフトウェアタグ定義において各具体化項目の粒度としてある程度の定義をおけば，その定義に基づいて各ツールの開発が容易になる．
以上から，粒度についてソフトウェアタグ定義において記述し，その定義をもとにユーザ・ベンダ
間でタグデータと粒度の選択を行ったほうがよいと考える．

23

7

あとがき
本論文では，ソフトウェアトレーサビリティの実現を目的としてソフトウェアタグ収集システムを設計した．ソフトウェアタグ収集システムへの要求について実現方針を検討し，ソフトウェア開発履
歴データとタグデータ収集設定情報からソフトウェアタグデータを得るシステムを提案した．さらに，設計したシステムに基づいて開発したプロトタイプを実際の開発プロジェクトデータへ適用し，ソフトウェアタグの有用性を確認した．
今後の課題としては，以下があげられる．

• 対応外メトリクスへの対応
ソフトウェアタグ収集システムでは対応しないメトリクスを，ユーザが組み込める機能を実装する．

• 他開発プロジェクトへの適用
他のプロジェクトデータに適用実験を行い，新たな知見や問題点を得ることで，ソフトウェア
タグ収集システムを改良する．

24

謝辞
本研究の全過程を通して，常に適切な御指導および丁寧な御助言を賜りました大阪大学大学院情報科学研究科コンピュータサイエンス専攻 楠本真二教授に心から深く感謝申し上げます．
本研究に適切な御指導および御助言を頂きました大阪大学大学院情報科学研究科コンピュータサ
イエンス専攻 岡野浩三准教授に心から感謝いたします．
本研究に対して，適切な御指導および御助言を頂きました大阪大学大学院情報科学研究科コンピュー
タサイエンス専攻 肥後芳樹助教に深く感謝いたします．
本研究に対して，適切な御指導および御助言を頂きました大阪大学大学院情報科学研究科コンピュー
タサイエンス専攻 柿元健特任助教に感謝いたします．
プロトタイプの実装を御手伝い頂いた大阪大学大学院情報科学研究科博士前期課程 1 年 鵜久森将隆氏に感謝いたします．
ソフトウェアタグデータの分析を御手伝い頂いた大阪大学基礎工学部情報科学科 4 年 山田慎也氏に感謝いたします．
その他の大阪大学 大学院情報科学研究科コンピュータサイエンス専攻 楠本研究室の皆様のご協力に深く感謝致します．

25

参考文献
[1] S. R. Chidamber, C. F. Kemerer, “A Metrics Suite for Object-Oriented Design”, IEEE Trans.
Software Eng., vol.20, pp.476-493, 1994.
[2] 井上 克郎, 松本 健一, 鶴保 征城, 鳥居 宏次, “実証的ソフトウェア工学研究への取り組み”, 情報処理, Vol.45, No.7, pp.722-728, 2004

[3] 松本 健一, “エンピリカルソフトウェア工学の現状と展望：SEL が残した 13 の教訓 , SEC
journal, No2, pp.6-13, 2005
[4] 三宅 達也, 肥後 芳樹, 井上 克郎: “メトリクス計測プラグインプラットフォーム MASU の開発 ,ソフトウェアエンジニアリング最前線 2008, pp63-70, Sep 2008[5] 大平 雅雄, 横森 励士, 阪井 誠, 岩村 聡, 小野 英治, 新海 平, 横川 智教, “ソフトウェア開発プロ
ジェクトのリアルタイム管理を目的とした支援システム , 電子情報通信学会論文誌, Vol.J88-D-I,

No.2, pp.228-239, 2005
[6] Thomas Zimmermann, Peter Weisgerber, “Preprocessiong CVS Data for Fine-grained analysis, 1st International Workshop on Mining Software Repositories, pp.2-6, 2004
[7] “特集 1：開発支援ツールの利用実態”, 日経 SYSTEMS, 2008 年 6 月号, pp.11-39, 2008
[8] “特集 1：ユーザーの言い分ベンダーの言い分”, 日経コンピュータ, 2008 年 10 月 1 日号, pp.40-55,
2008[9] バグトラッキングシステム影舞
http://www.daifukuya.com/kagemai/[10] CMMI V1.2 モデル-公式日本語翻訳版
http://www.sei.cmu.edu/cmmi/translations/japanese/models/index.html[11] Home::Bugzilla::bugzilla.org ホームページ
http://www.bugzilla.org/[12] IBM Rational ソフトウェア
http://www-06.ibm.com/jp/software/rational/[13] IT スパイラル
http://it-spiral.ist.osaka-u.ac.jp/index.html

26

[14] JUDE:UML, ED, CRUC, DFD, Flowchart and Mind Map:Design & Modeling Tool
http://jude.change-vision.com/jude-web/index.html[15] Main Page - Ximbiot - CVS Wiki
http://ximbiot.com/cvs/wiki/[16] Microsoft Oﬃce Visio ホームページ
http://oﬃce.microsoft.com/ja-jp/visio/default.aspx[17] Object Managemant Group
http://www.omg.org/[18] SDMetrics - the design quality metrics tool for UML models
http://www.sdmetrics.com/[19] ソフトウェアタグ規格 第 1.0 版
http://www.stage-project.jp/kanri/data/dl/20081029151602.pdf[20] StagE プロジェクト
http://www.stage-project.jp/[21] subversion.tigris.org
http://subversion.tigris.org/[22] 「動かないコンピュータ」の解決に裁判は役立つか
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040609/145573/[23] XML Metadeta Interchange
http://www.omg.org/technology/documents/formal/xmi.htm

27

付録
本文 5.3 節において述べた実プロジェクトデータのソフトウェアタグ収集結果のうち、レベル１の日々の履歴について示す。

28

29

30

31

32

33

34