修士学位論文

題目

トレーサビリティ実現のためのソフトウェアタグ生成基盤システムの開発

指導教員
楠本 真二 教授

報告者
鵜久森 将隆

平成 22 年 2 月 8 日

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

平成 21 年度 修士学位論文

トレーサビリティ実現のためのソフトウェアタグ生成基盤システムの開発
鵜久森 将隆内容梗概
ソフトウェアの開発における定量的データの収集・分析は，ソフトウェア受注者側のプロセス改善やプロジェクトの進捗・品質管理を目的としている．しかし近年，ソフトウェア発
注者側の視点に立った開発プロジェクトデータのより幅広い活用が求められ，ソフトウェア
へのトレーサビリティの適用が提案されている．ソフトウェアに対するトレーサビリティとは製品品質や開発状況の把握が発注者にも可能なことを意味する．このソフトウェアトレー
サビリティを実現する技術としてソフトウェアタグに関する研究・開発が行われている．ソフトウェアタグとはソフトウェア開発中に収集された種々のメトリクスをパッケージ化したものである．ソフトウェアタグを実現するにはソフトウェアタグの規格化，データ収集・可視化・評価手法の開発，実証実験の実施，法的諸問題の検討といった様々な課題がある．
本研究ではソフトウェア開発プロジェクトの実証データからデータを収集し，ソフトウェ
アタグを生成するシステムを提案する．ソフトウェアタグの生成方法は，どのようなプロジェクトにも適応できること，低コストであること，生成されたソフトウェアタグが利便性の高いものであることが要求されている．
提案するシステムは，収集する対象データをユーザが定義できる機能をもち，この定義に従った GUI の入力フォーマットを提供する．収集対象データをユーザが定義できることによ
り，どのようなプロジェクトにも利用が可能なシステムを実現した．また一部のデータ項目
では自動データ収集機能を提供する．自動データ収集機能により，低コストでのソフトウェ
アタグ生成を実現した．自動データ収集機能の実装においては，ソフトウェア開発時に利用される開発支援ツールの機能や特徴を調査し，開発支援ツールから生成される実証データか
らデータを収集する方法を検討した．さらに，収集，生成されたデータを XML 形式のソフ
トウェアタグとして出力することによりソフトウェアタグの利便性向上の要求に対応した．
実験ではあるソフトウェア開発プロジェクトのデータを用いて，開発したシステムでのデータ入力コストを評価した．その結果，1 回の入力において利用者の作業時間は平均 2 分程度であり，入力における負荷はそれほど高くないことを確認した．

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

目次
1

まえがき

1

2

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

3

3

4

2.1

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

3

2.2

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

3

2.3

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

4

2.4

ソフトウェアトレーサビリティ実現に向けての研究開発活動 . . . . . . . . .

4

ソフトウェアタグ

3.1

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

5

3.2

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

5

3.3

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

5

3.4

タグ利用のシナリオ

7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ソフトウェアタグ生成システム

10

4.1

ソフトウェアタグ生成に対する要求 . . . . . . . . . . . . . . . . . . . . . . . 10

4.2

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

4.3

システム利用モデル

4.4

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

4.5

4.6
5

5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.4.1

タグデータの構成要素 . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4.2

タグデータ定義の構成要素 . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4.3

タグデータ定義編集部 . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4.4

タグデータ入力部 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.5

タグデータ出力部 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

自動データ収集手法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5.1

分類 [要件定義，設計] のメトリクス計測 . . . . . . . . . . . . . . . . 19

4.5.2

分類 [プログラミング] のメトリクス計測 . . . . . . . . . . . . . . . . 20

4.5.3

分類 [品質] のメトリクス計測 . . . . . . . . . . . . . . . . . . . . . . 22

実行例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

実験

24

5.1

実験目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2

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

5.3

収集タグデータ項目. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
i

5.4

実験手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.5

評価方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.6

結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6

考察

28

7

Threats to Validity

31

8

関連研究

32

9

あとがき

34

謝辞

35

参考文献

36

ii

1

まえがき
近年，ソフトウェアの大規模化と社会的影響の拡大によりソフトウェアの重要性が高まる

と共に，さまざまな問題が発生している [1]．例えば，ソフトウェアに障害が発生することで，金融システムや交通システムなどの重大な社会インフラが停止したり，航空管制システ
ムや自動車安全システムなどが人命に関わる危険を引き起こす．また，それに伴いユーザ・ベンダに莫大な経済的損失を与える．さらに開発期間の短縮のためにコストの低減や生産性の向上が要求されたり，情報システム開発に関わる訴訟が頻繁に発生している [2]．
これらの問題を解決するアプローチの一つとして，ソフトウェアトレーサビリティの概念が提案されている．トレーサビリティとは本来，野菜や食肉等の物品の生産・流通履歴を確
認可能であることを意味するが，これをソフトウェアに対し適用することでソフトウェア
ユーザによるソフトウェアの製品品質・開発状況の把握や，発注者・受注者間の法的係争発生時の処理の短期化を可能とすることが期待されている．
このソフトウェアトレーサビリティを実現するためにソフトウェアタグの研究開発が行われている [3]．ソフトウェアタグは，ソフトウェアの開発中に収集された管理データや品質情報など複数のデータから構成され，各データ種類をタグ項目と呼ぶ．タグ項目に従って，開発成果物や副次的に発生するデータ（実証データ/エンピリカルデータ）からタグデータが開発中，もしくは開発完了時に収集され，ソフトウェアタグが作成される．作成されたソフトウェアタグはソフトウェアに付随し，ユーザはタグの内容を見ることによって，対象ソ
フトウェアの開発過程や品質保証のプロセス，成果物の品質情報を入手できる．
ソフトウェアタグによるソフトウェアトレーサビリティの実現にはいくつかの課題があり，その一つにソフトウェアタグを生成する技術の開発がある．そこで本研究ではソフトウェア
トレーサビリティ実現の一環として，ソフトウェアタグ生成システムの提案を行う．
ソフトウェアタグの生成については，収集データが異なるプロジェクトに対して適用でき
ること，低コストで生成できること，生成されたソフトウェアタグが利便性の高いものであることが求められる．本研究ではこれらの要求を解決するため，収集するタグデータ項目をシステムユーザが定義可能なソフトウェアタグ生成システムを提案する．システムユーザは標準で用意されているデータ項目以外に，必要なデータ項目を追加可能である．システムは追加されたデータ項目定義を読み込み，それに従った入力フォーマットを提供する．
また，一部の項目については自動データ収集機能を提供し，低コストでソフトウェアタグを生成する．収集されたタグデータは，統一的な記法をもつ XML[4] で出力することにより，ソフトウェアタグ分析ツール [5][6] などで利用することが可能である．
以降，2 章ではソフトウェアトレーサビリティ実現にむけた概況を述べ，3 章ではソフト
ウェアタグの定義について説明する．4 章ではソフトウェアタグ生成システムに対する要求

1

や利用モデル，システム構成について述べる．5 章では実プロジェクトからシステムを利用してソフトウェアタグを生成し，ソフトウェアタグ生成のコストを計測する．6 章，7 章では，システムを利用したソフトウェアタグ生成の利点や問題点を考察する．8 章では本研究で参考にした文献や関連研究を挙げる．最後に 9 章でまとめと今後の課題を述べる．

2

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

2
2.1

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

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

2.2

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

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

トレーサビリティ情報
生産者情報

物流情報

生産者

輸送業者

製造情報

原材料
情報

物流情報

加工業者

輸送業者

小売
情報

問い合わせ
原材料情報
製品情報

小売・卸業者

消費者

図 1: 食品のトレーサビリティ[3]なお，過去にソフトウェア開発分野においてトレーサビリティという言葉は，能力成熟度
モデル [8] で使用されてきた．能力成熟度モデル（CMMI）とは，ソフトウェア開発組織のソフトウェア開発能力向上のために利用されるプロセス改善モデルである．CMMI ではプ

3

添付

ソフトウェアタグ
データ収集

データ収集

データ収集

データ収集

開発組織
プロフィール

要求分析

設計

実装

データ収集

テスト

ソフトウェア製品

図 2: ソフトウェアトレーサビリティ[3]ロセス改善方法の一つとして要求仕様と計画・開発・成果物間のトレーサビリティの必要性
を定義している．しかし，ここで述べられているトレーサビリティは開発組織のプロセス改
善のためであり，ユーザ側にトレーサビリティを与えるものではない．

2.3

StagE プロジェクト

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

2.4

ソフトウェアトレーサビリティ実現に向けての研究開発活動

ソフトウェアタグによるソフトウェアトレーサビリティの実現に向けて，５つの研究開発活動を行っている（図 3）．
ソフトウェアタグ
規格化

ソフトウェアタグの実相と適用

ソフトウェアタグの収集技術

ソフトウェア
構築可視化に伴う法的諸問題

ソフトウェアタグに基づく可視化と評価技術

図 3: ソフトウェアトレーサビリティに向けての研究開発活動

本研究はソフトウェアタグ生成技術の開発を目標としている．

4

ソフトウェアタグ

3
3.1

概要

ソフトウェアタグとは開発に関する実証的データ（エンピリカルデータ）[1] を収集しそのデータを一定の形式でパッケージ化したものである．StagE プロジェクトはソフトウェア
タグ規格 第 1.0 版を策定している [9]．この規格においてソフトウェアタグは管理データや品質情報など複数のデータから構成され，各データ種類をタグ項目と呼ぶ．タグ項目は発注者・受注者間で共有する候補として定義してあり，発注者・受注者は用途に応じてタグ項目を選択しソフトウェアタグを構成する．
タグ項目は全 41 項目あり，プロジェクト情報と進捗情報に大別される．

3.2

プロジェクト情報

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

• 基本情報• システム情報• 開発情報• プロジェクトの階層構造情報• その他
表 1 にプロジェクト情報の一覧を示す．表 1 の予定・実績の要否は予定と実績による管理が必要かを示している．成果物やプロセス，目標についてベースラインを作成することはソフトウェア開発の改善において重要であるため [10]，いくつかのタグ項目に対し予定と実績
による管理を要求している．

3.3

進捗情報

ソフトウェアタグの内，進捗情報とはソフトウェア開発によって得られた作業の進捗状況
や，成果物やプロセスの品質を表す情報を指す．進捗情報はプロジェクト情報とは異なりプ
ロジェクト途中で値が変化する．

5㸬ᶆ‽ࢱࢢ㡯┠୍ぴ⾲

表 1: ソフトウェアタグ:プロジェクト情報

cu

"v




±01



!"#

wx

pqyz

{|78

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

ñòóªôõLC8DBÀZö ïðBÉÊïðRúR6A÷Åøùk6/°±L01P

óªôõ_`

ÄÅóªôõ_`L:;iñò !78 L¶·k./óªôõL¹u9°.01P!78 LabicdB,
gh678 P




óªôõ0
1

hM¾
&'()*+HIÖÛ¿£F+[8ªÚ8Û
ôª+
6ÝïðkLûü
ý&'()*+
6

±Ö
Ø§Ze+,óªôõL-®ÈØ§.8Û])^/01,02/3/4­Z &'()*+
e+,óªôõL-®¿¨567/4 
<QfW®
-38
+,óªôõL?|@H<=ÈØ§9 ¬ {­78
?AZe+,óªôõL?|@Hk<6=Ø§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
´2^(b1´2&'+ 1&îB`§^L'©ªi^L,_¨WL0
1P !78 Labicd çcBcBccî6
B,gh678 P&'()*+&'()*+d
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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

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

&'()*+> L&'() p&'()*+L&'()*+
*+L+,çî&'()*+I
O/Ô¿B<&'()*+

T½Ö
_ÌÖ
6

+,çî&'()*+01

&'()*+>+,çî&' +,58&'()*+L=B&'()*+()*+9_Ô¿B\L=i 6
+,58&'()*+,-./
01&'()*+

T½Ö
_ÌÖ
6

:@ü"

\LjB !78 Labi
cdB,ghBÀZöAK§
678 P





<QfW®
6

&'()*+@
H


&'()*
+Lst_
Ì01

\Lj

<Q
¯2{
­Lhú hú&'()*+ÄÅ&'()*+åæçè§éêë8(BìíÄÅîBØ§éêë8(6

ÄÅ01

z

6
13

Ý
Ý

Ý

Ý

Ý

Ý

Ý

Ý

Ý

Ý

L

進捗情報内ではタグ項目は 29 項目存在し，そのタグ項目がどの開発プロセスに関するか
でさらに以下の 8 つに分類される．

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

3.4

タグ利用のシナリオ

ソフトウェアタグ定義を発注者・受注者がどのように利用するのか一例を述べる．ソフト
ウェアタグの内，19 番プログラミングの規模としてソースコードからコード行数を，20 番
プログラミングの変更としてソースコード行数の差分量を選択したとする．これにより，発注者は実装時にコード行数がどのように推移して作成されたか，また，日々のコード行数の推移がどれくらいの変更・削除・追加によって行われたかを把握可能になる．また，30 番の欠陥対応件数として不具合消化数を選択すれば，不具合を修正するためにどの程度ソース
コードの修正を行ったか分かる．タグの利用方法としては，製品品質の把握，開発状況の把握，紛争処理がある．実際に開発者・発注者間でソフトウェアタグを作成する際に，これらの目的に応じてどのソフトウェアタグ項目を使用するかを選択する必要がある．各利用方法
に対し，各タグ項目がどのように用いられるかを述べる．
製品品質を把握するには，進捗情報の分類”品質”に含まれるタグ項目が用いられる．例えばバグ数やレビュー状況からソフトウェアが程度作りこまれたかを調べる．また，製品品質を把握することで，ソフトウェアを部品として再利用することも可能である．その際にはシステム構成や，テスト項目数，リスト項目数などが使用される．

7

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

8

開発状況を把握するには，開発がどのような環境で行われたかを表すために開発体制や開発手法が使用される．また，どういったプロセスを追って開発されたかを調べるためにプロ
セス管理情報などが使用される．
紛争処理の際には，ソフトウェアが十分テストされたものかを見るためにバグ数，レビュー
状況，テスト項目数などが使用される．また，発注者・開発者間でソフトウェアに対しどのよな合意があったかを確かめるために発注者ヒアリング情報，要件変更，会議実施状況が使
用される．

9

ソフトウェアタグ生成システム

4
4.1

ソフトウェアタグ生成に対する要求

ソフトウェアタグの生成に対する要求について述べる．
プロジェクトに依存しないソフトウェアタグの生成方法

3.1 節で述べたとおり，ソフトウェアタグとなるデータ項目は各発注者，受注者間で協議した上で選択される．協議の上でのデータ項目は様々な形が考えられる．例として，プロジェ
クト A の協議ではタグ項目 26 番 [レビュー状況] のデータとしてレビュー回数を選択したとする．しかし，プロジェクト B の協議ではレビュー合計時間を選択する可能性があり，またプロジェクト C ではその両方，もしくはまったく別のデータを収集対象とするかもしれな
い．このようにプロジェクトにより収集データの項目は異なる．システムはこれに対応でき
るように，プロジェクトに依存しないソフトウェアタグの生成方法を提供する必要がある．
低コストでのソフトウェアタグの生成
ソフトウェア開発プロジェクトにおいてコストを抑えることは重要な課題の１つである．
コストオーバーとなるプロジェクトは後を絶たず，特にソフトウェア開発においては，２次
受け，３次受けのプロジェクトはコストに余裕のないことも多い．このようなプロジェクト
は，ソフトウェアタグを生成するためのリソースを十分に割り当てることができないと考えられる．このため，低コストでソフトウェアタグを生成できることが要求される．
利便性の高いソフトウェアタグの出力
これまでも何度か述べたが，ソフトウェアタグの目的は「ソフトウェア開発データの発注者との共有を行い，ソフトウェアの品質や由来を発注者に示す」ことである．ソフトウェア
タグがこの目的を達成するためには，生成されたソフトウェアタグのデータの確認が容易であること，分析ツールなどで利用できる形式であることが要求される．

4.2

設計方針

4.1 節で述べた要求に対応する本システムの設計方針について述べる．
拡張性の高い収集対象タグデータの定義
前節で述べたとおり，開発ベンダやプロジェクトにより収集されるデータは異なるため，それらに依存しないソフトウェアタグの生成方法を考える必要がある．そこで収集対象とな

10

るデータをシステムユーザが定義可能なシステムを実現する．
収集するデータをタグデータ，タグデータに関する定義をタグデータ定義とよぶ．タグ
データ定義を用いたタグデータ収集方法のイメージを図 4 に示す．

①データ対象の読み込み
タグデータ定義

データ入力
システム④データ蓄積②入力フォーマットの提供③データ入力タグデータ
リポジトリ
図 4: タグデータ定義と入力システムのイメージデータ入力システムは，タグデータ定義を読み込み，それに従った入力フォーマットをユーザに提供する．ユーザは提供された入力フォーマットに従い，プロジェクトのデータを入力していく．入力が完了すると，そのデータはタグデータリポジトリに格納される．
この手法は柔軟で拡張性が高いタグデータの収集を可能にする．標準のタグデータ定義を
システム側で提供しておくと，データ入力システムは定義を読みこみ，システムユーザに標
準データ項目の入力フォーマットを提供する．
タグデータ定義はシステムユーザにより追加が可能であるので，標準タグデータ定義で足りなければ，独自のタグ定義を追加する．これによりシステムはプロジェクトに依存しない
ソフトウェアタグ生成方法をシステムユーザに提供可能である．
このようにユーザにより追加が可能なタグデータ定義を利用することにより，プロジェク
トに依存しないシステムを構成する．
プロジェクトデータ自動収集機能の提供
低コストでのソフトウェアタグ生成を目指すため，データ自動収集機能の実装を検討する．
一般的に，ソフトウェア開発プロジェクトは Subversion[11] や CVS[12] などのバージョン
管理システムを利用している．バージョン管理システムはソースコードの管理に使われることが多く，そのリポジトリにはソースコードの更新履歴が蓄積されている．本システムはリ
ポジトリから得られるデータの自動収集を考える．さらに開発プロジェクトでは Gnats[13]や影舞 [14] などのバグトラッキングシステムが利用されている．バグトラッキングシステ
ムにはソフトウェアのバグに関する情報が蓄積されており，このログから品質に関するデー

11

タの自動収集を検討する．またソフトウェア開発では JUDE1 [15]，IBM Rational Rose[16]，Microsoft oﬃceVisio[17] などの UML モデリングツールが利用されている．本システムではフリーで利用できる JUDE のファイルから要件定義，設計のデータを自動収集する方法について検討する．
データ自動収集機能の詳細については，4.5 節で述べる．

XML 形式でのソフトウェアタグ出力
XML とは文書やデータの意味や構造を記述するためのマークアップ言語の１つである．
XML により統一的な記法を用いながら独自の意味や構造をもった言語を作成することができるため，ソフトウェア間の通信・情報交換に用いるデータ形式や，様々な種類のデータを保存するためのファイルフォーマットの定義によく用いられている．本システムは入力，収集されたデータを XML 形式のソフトウェアタグとして出力することを検討する．これによりソフトウェアタグの利便性が高くなり，グラフ表示ツールによるプロジェクトデータの確認や，ソフトウェアタグを入力とした分析ツールによるプロジェクトの分析が容易となる．

4.3

システム利用モデル

この節では本システムを利用したソフトウェアタグ生成のモデルについて述べる．
システムを利用したプロジェクトの開始から終了までのソフトウェアタグ生成の手順は次のようになる．
手順１ ソフトウェアタグプロジェクトの新規作成
手順 2 収集対象データ定義（タグデータ定義）の作成
手順 3 プロジェクトデータを収集
手順 4 手順 3 をプロジェクト終了まで一定の期間で繰り返す
手順 5 ソフトウェアタグの出力
手順 3，手順 4 の概要図を図 5 に示す．図 5 はプロジェクトの流れが時系列で表現されている．プロジェクトの開始後，システムを利用してデータを収集する．その後，一定期間ごとに同様の操作を繰り返して，タグデータを蓄積していく．図 5 では 3/27 に１度目のデー
タ収集を行い，3 日後の 3/30，その後３日置きにデータの収集を行っている様子が示されている．期間はさまざま考えられるが，データ収集のコスト，受注者へのタグデータ提示の手
1

現在は astah*という名称に変更

12

間を考えると，発注者，受注者間で協議の上，決定すると良いと思われる．データ収集のコストに関しては第 5 章で実験を行う．
収集されたタグデータはタグデータリポジトリに蓄積される．その後，プロジェクトが終了，あるいは必要に応じて途中で，XML フォーマットのソフトウェアタグを出力する．

プロジェクト
開始
3/27

3/30

5/28

… システムを利用してタグデータの収集

ソフトウェアタグ

5/31

終了
図 5: システムを利用したプロジェクトデータ収集モデル

4.4

システム構成システムの全体構成を図 6 に示す．システムは主にタグデータ定義編集部，タグデータ入力部，タグデータ出力部から構成される．

4.4.1

タグデータの構成要素

タグデータの構成要素を図 7 に示す．
タグデータは具体値を示す value の他，その値についてのメタデータを持つ．tagIdentiﬁer
はデータ項目をユニークにする識別子，id はハッシュ値，name はデータ項目名，user はメト
リクスの計測者，unit は値の単位，object は値の根拠となった議事録やソースコード，date
は値を入力，もしくは計測した日時，remarks はその他の備考記録をもつ．
具体例を図 8 に示す．図 8 のタグデータから，実測値が 10，この値はレビュー回数の値であること，2007 年 4 月 18 日 15 時の時点でレビューを 10 回行ったこと，計測の根拠となっ

13

メイン
モジュール
収集対象となる
タグデータの定義を行う

作成

データ定義
編集部

タグデータ定義

入力フォーマットの提供
データ入力
システム
出力要求
ユーザ
タグデータの表，グラフ表示

タグデータ
入力部

タグデータ

タグデータ
出力部
XML

制御フロー
データフロー

タグデータ
リポジトリ

出力
ソフトウェアタグ

図 6: システムの全体構成たものはレビュー議事録であることなどがわかる．このようにメタデータを記録しておくことで，さらに詳細なデータが必要な場合は議事録を参照するなどの行動が可能である．

4.4.2

タグデータ定義の構成要素

前項に続き，タグデータ定義の構成要素について説明する．タグデータ定義は，タグデー
タが表す内容についての定義を保持するものである．
構成要素を図 9 に示す．タグデータ定義は，タグデータをユニークにする識別子 tagIden-

tiﬁer，タグデータの項目名 name，詳細を記す description，単位を示す unit，そして収集頻度を示す frequency からなる．
具体例として図 8 に示されたタグデータのタグデータ定義を図 10 に示す．このタグデー
タ定義から，レビュー回数のタグデータを計測する頻度や，レビュー回数についての詳細を得ることが可能である．

4.4.3

タグデータ定義編集部

タグデータ定義編集部は，4.4.2 項で説明したタグデータ定義を追加，除去する機能をもつ．図 11 にタグデータ定義編集部の構成を示す．システムのユーザはタグデータ定義編集機能を利用して収集対象となるタグデータ定義を作成する．ユーザにより作成されたタグ

14

TagData {value : 10
tagIdentifier :progressInformation.quality.
reviewStatus.reviewNum
id : 1365874845…
name :
user :
unit :
object :date : 2007/04/18 15:00:00
remarks :3/27, 3/30, …
}

TagData {value :
tagIdentifier :id :name :
user :
unit :
object :date :
remarks :
}

具体値
識別子
ハッシュ値
データ項目名
計測者
単位
計測対象
日時
その他備考

レビュー回数鵜久森
件
レビュー議事録
レビュー実施日

図 7: タグデータの構成要素
図 8: タグデータ具体例

TagDataDefinition {tagIdentifier :progressInformation.quality.
reviewStatus.reviewNum

TagDataDefinition {tagIdentifier :name :
description :unit :
frequency :}識別子
データ項目名
タグデータ項目の詳細
単位
収集頻度

レビュー回数
レビューを行った回数．
レビューは毎週水曜と金曜に実施．
unit : 件
frequency : タグデータ計測日に準拠
name :
description :}図 9: タグデータ定義の構成要素

図 10: タグデータ定義の具体例

15

データ定義は XML ファイルとして，ソフトウェアタグプロジェクトのタグデータ定義ディレクトリに保存される．タグデータ定義の XML ファイルを図 12 に示す．
GUIの提供システム
ユーザ

収集対象データの追加，除去

タグデータ定義
編集部
生成

タグデータ定義
ディレクトリ

progressInformation.testSizeTransition.singleTestNum_def.xml
progressInformation.design.designSizeTransition.windowNum_def.xml
progressInformation.quality.reviewStatus.reviewNum_def.xml…

図 11: タグデータ定義編集部の構成

progressInformation.quality.reviewStatus.reviewNum_def.xml<?xml version="1.0" encoding="utf-8" ?><tagDataDefinition ><tagIdentifier>progressInformation.quality.reviewStatus.reviewNum</tagIdentifier><name></name><description></description><unit> </unit><frequency></frequency></tagDataDefinition>

レビュー回数
レビューを行った回数．レビューは毎週水曜と金曜に実施．
件
タグデータ計測日に準拠

図 12: タグデータ定義の XML ファイル

また，プロジェクト A で作成されたタグデータ定義ファイルは，プロジェクト B のタグ
データ定義ディレクトリにコピーすることで，プロジェクト B でも利用可能である（図 13）．
ベンダやプロジェクトにより，よく使うタグデータ定義をまとめておくとタグデータ定義を作成する時間を削減できる．

4.4.4

タグデータ入力部

タグデータ入力部の構成を図 14 に示す．
タグデータ入力部は入力ウィザード，入力フォーマット生成部，自動データ収集部から構成される．入力フォーマット生成部はユーザによって定義されたタグデータ定義を読み込み，

16プロジェクトA
タグデータ定義DIR

プロジェクトB
タグデータ定義DIR

progressInformation. …
.reviewNum_def.xml

コピーprogressInformation. …
.reviewNum_def.xml

図 13: タグデータ定義の流用

タグデータ定義

入力フォーマットの提供
データ入力
自動収集設定システム
ユーザ

タグデータ入力部
入力フォーマット
生成
GUI入力
入力フォーマットウィザード
生成部
ユーザによる 自動収集設定
入力データ
自動データ
収集部
収集データ
タグデータ
リポジトリ

処理フロー
データフロー

図 14: タグデータ入力部の構成

17タグデータの入力フォーマットを生成する．入力ウィザードは入力フォーマットをシステムユーザに提示し，ユーザはフォーマットに従ってデータを入力する．また，同時に自動収集する項目についても設定を行う．入力が完了すると，ユーザによる入力データはタグデータ
リポジトリに格納され，自動収集項目についてはその設定が自動データ収集部に渡される．
自動データ収集部は受け取った設定に従ってデータの計測，収集を行い，同じくタグデータ
リポジトリに格納する．
また，データ入力のサポートとして，前回の入力データを保持しておく機能をもつ．入力
フォーマットには前回入力データがすでに入力されているため，変更がない項目については入力する必要がない．これは計測者情報である user や計測単位である unit，計測根拠のobject などあまり変更がない項目に対して，入力コストの面で効果的である．
4.4.5

タグデータ出力部

タグデータ出力部の構成を図 15 に示す．

出力操作
GUIの提供システム 表，グラフ表示
ユーザ
制御フロー
データフロー

タグデータ出力部
データ出力
モジュール

タグデータ

タグデータ
リポジトリ

タグデータ
タグデータ
トランスレータＸＭＬ
トランスレート

ソフトウェアタグ

図 15: タグデータ出力部の構成

タグデータ出力部はデータ出力モジュールとタグデータトランスレータから構成される．
システムユーザは GUI を通して出力操作を行い，データ出力モジュールは操作に応じてタ
グデータの表，グラフ表示やトランスレータ命令を行う．タグデータトランスレータはタグ
データを XML にトランスレートし，ソフトウェアタグを出力する．ソフトウェアタグの出力のタイミングは任意であり，必要に応じてプロジェクトの途中で出力も可能である．出力のタイミングとして，プロジェクト完了時の他，発注者への開発経過報告時などが考えれる．

18

表 3: システムが提供する自動収集データ
分類

項番

タグ項目

要件定義

14

規模 [推移]15

変更 [推移]16規模 [推移]設計

プログラミング

品質

4.5

17

変更 [推移]1920規模 [推移]変更 [推移]

21
29
30
31
32

複雑度
欠陥件数 [推移]
欠陥対応件数 [推移]
欠陥密度
欠陥指摘率

収集データ
ユースケース図数
ユースケース数
アクター数
ユースケース図追加数
ユースケース図削除数
ユースケース追加数
ユースケース削除数
アクター追加数
アクター削除数
クラス図数
シーケンス図数
ステートマシン図数
アクティビティ図数
クラス図追加数
クラス図削除数
シーケンス図追加数
シーケンス図削除数
ステートマシン図追加数
ステートマシン図削除数
アクティビティ図追加数
アクティビティ図削除数
ソースコード行数
追加行数
削除行数
更新回数
ＣＫメトリクス
バグ報告数
バグクローズ数
バグ報告数 / ソースコード行数
バグ報告数 / 消化テスト項目数

入力

JUDE で作成したモデリングファイル

Subversion, CVS の
リポジトリ

Gnats, 影舞のログファイル

自動データ収集手法

システムが提供する自動収集のデータ項目を表 3 に示す．データの収集手法については以降の項で説明する．

4.5.1

分類 [要件定義，設計] のメトリクス計測

分類 [要件定義]，[設計] の自動データ収集手法について説明する．システムは UML モデ
リングツール JUDE[15] で作成されたＵＭＬモデルからのデータ収集に対応している．デー
タ収集手法の概要図を図 16 に示す．

JUDE では，JUDE のモデルデータを活用するアプリケーションソフトウェアを開発するための Java インターフェース群である JUDE API を公開している．この JUDE API は

19

自動データ
収集部

解析
命令
JUDE API結果

ユースケース数，
クラス図数，.. .

解析

ＪＵＤＥファイル
処理フロー
データフロー

図 16: 要件定義，設計のデータ収集手法概要

JUDE のインストールディレクトリに存在し，JUDE Professional のインストールディレク
トリには jude-api.jar と jude-pro.jar が，JUDE Community のインストールディレクトリ
には jude-api.jar と jude-community.jar が含まれている2 ．自動データ収集部はこの JUDE

API を利用し，JUDE で作成された UML モデルからデータ計測を行う．必要となるのは
jude-api.jar と，jude-pro.jar か jude-community.jar のどちらかである．
4.5.2

分類 [プログラミング] のメトリクス計測

分類 [プログラミング] のデータ収集手法について述べる．ソフトウェア開発プロジェクト
ではソースコードの管理にバージョン管理システムが用いられている．そこで本システムは比較的高いシェアと認知度をもつフリーのバージョン管理ツールである Subversion，CVSのリポジトリからデータを収集する．
概要図を図 17 に示す．バージョン管理ツールのリポジトリから，指定した日付の最終コ
ミットリビジョンのソースコードをエクスポートし，メトリクスを計測する．計測はメトリ
クス計測プラグインプラットフォーム MASU[18] を利用する．MASU の出力結果から，タグ
項目規模に該当するソースコード行数，複雑度に該当する CK メトリクス [19] を収集する．
また，タグ項目変更に関しては svn diﬀ や cvs diﬀ のコマンドを利用する．概要図を図 18に示す．

22009 年 9 月 15 日，JUDE は astah*に改名された．それに伴い，JUDE Professional は astah* professional，
JUDE Community は astah* community に改名された．API は jude-api.jar は astah-api.jar に，jude-pro.jar
は ashta-pro.jar に，jude-community.jar は astah-community にファイル名が変更されている．自動データ収集手法は astah-api.jar，astah-pro.jar，astah-community.jar を用いても有効であることを確認している．

20

データ収集日指定

リポジトリ
指定された日付のソースコードをエクスポート

ソースコード

自動データ
収集部

解析
結果

入力

MASU

行数，
ＣＫメトリクス

処理フロー
データフロー
図 17: 規模，複雑度のデータ収集手法概要

自動データ収集部①コミットログの取得

リポジトリ②計測する２つの日付間の全リビジョンでDiff命令
Diffデータ

計測器

Diff結果追加，削除行数
更新回数

処理フロー
データフロー

図 18: 変更のデータ収集手法概要

21

まずリポジトリからコミットログを取得する．コミットログから，計測する２つの日付間でコミットされたリビジョン番号を調べ，その全リビジョン間で Diﬀ 命令を行う．例えば，

2 月 1 日から 2 月 4 日の間でコミットされたリビジョン番号が 700，701，702，703 ならば，
700-701 間，701-702 間，702-703 間で Diﬀ を出力する．この Diﬀ の出力結果を入力とした
Diﬀ データ計測器から，ファイルごとの追加行数，削除行数，コミット数を取得する．Diﬀ
データ計測器は本研究で実装した．

4.5.3

分類 [品質] のメトリクス計測

分類 [品質] のデータ収集手法について説明する．たいていのソフトウェア開発プロジェク
トではプロジェクトのバグ登録，及び修正状況の追跡をするシステムとしてバグトラッキン
グシステムが用いられている．バグトラッキングシステムのデータベースには，報告されたバグの種類や報告日，修正されたか否かなどの情報が蓄積されている．バグトラッキングシ
ステムはこの情報をログとして出力することができ，本システムはこのログ情報からタグ項
目 29 番の欠陥件数，30 番の欠陥対応件数の情報を収集する．31 番の欠陥密度については
ソースコード行数の入力が必要であり，32 番についてはテストの消化数が必要である．それらの入力があれば，自動計測が可能である．

4.6

実行例

本節ではシステムの実行例を挙げる．
図 19 がタグデータ定義の編集画面である．発注者，受注者間の協議のうえで決定した収集対象タグデータのタグデータ定義を編集する．タグデータ定義はプロジェクトの新規作成から終了までいつでも編集可能なので，プロジェクトの途中で収集するタグデータ項目が変更となったときは任意のタイミングで項目の追加，除去ができる．
タグデータ定義に従いデータ入力部が入力フォーマットを生成する．図 20 に示す入力画
面はウィザード形式になっており，分類ごとにプロジェクトのデータを入力する．4.3 節で述べたように，プロジェクトの終了まで一定の期間でタグデータ入力ウィザードを起動し，タグデータの入力，自動収集を行う．
入力，収集されたデータはタグデータリポジトリに蓄積される．図 21 は蓄積されたデータをテーブルで表示したものである．

22

定義の追加，除去

タグデータ定義ファイルが作成される
図 19: タグデータ定義編集画面

計測者や備考など
メタデータの入力を行う

タグデータ定義に従い生成された入力フォームにデータ入力
自動収集する
データにチェック

計測対象ファイルを設定

図 20: データ入力ウィザード

23

年 月 日のタグデータ

2008 2 28

図 21: 蓄積されたデータの出力

実験

5
5.1

実験目的

本研究で開発したソフトウェアタグ生成システムを用いて，実際のプロジェクトからソフ
トウェアタグを生成する．ソフトウェア生成にかかるコストを計測し，本システムの有用性を検証する．

5.2

対象プロジェクト

ITSpiral[20] で作成された実プロジェクト教材に対して，本システムを利用してソフトウェ
アタグを生成した．これは大学の履修登録プログラムを開発した際に得られた開発データであり，要件定義，設計，実装，テスト等の開発プロセスでさまざまな実証データが存在す
る．プロジェクトはウォーターフォールモデルで開発され，設計プロセス終了に２ヶ月，実装からプロダクトの提出までに３ヶ月の時間を要している．総開発期間は 5ヶ月で，総デー
タ量は 450MB である．このプロジェクトのエンピリカルデータを表 4 に示す．
なお，表 5 が示すように開発支援ツールを各開発プロセスで使用しており，収集データの一部としてツールの実行結果やプロジェクトデータが存在する．

24

表 4: 適用対象プロジェクトのエンピリカルデータ
プロセス名

エンピリカルデータ

要件定義

要求仕様書，業務フロー図，画面一覧
ユースケース図，アクター定義書，品質要求書

分析・設計

クラス図，コラボレーション図，シーケンス図アーキテクチャ仕様書，エンティティクラス設計書
コントロールクラス設計書，バウンダリクラス設計書

実装

ソースコード，API ドキュメント，リポジトリ
静的チェック記録

テスト

テスト計画書・仕様書

プロジェクト管理

内部・外部レビュー記録，プロジェクト管理記録
変更経緯説明書

表 5: プロジェクトで使用された開発支援ツール
ツール名

説明

使用開発プロセス

JUDE

UML モデリングツール

要求・分析・設計

Eclipse

統合開発環境実装

影舞

バグ管理ツール

テスト

Subversion

構成管理ツール

実装

25

5.3

収集タグデータ項目

表 6 に実験で収集したタグデータ項目を示す．収集タグデータ項目は 53 項目，そのうち自動収集したものは 40 項目，手動入力したものは 13 項目である．

5.4

実験手順

実験手順を以下に示す．

1. タグデータ定義編集部を使って収集するタグデータのタグデータ定義を追加する．
2. 表 4 のエンピリカルデータからデータを集める．
3. システムの入力ウィザードを使ってタグデータを入力，計測する．
4. ソフトウェアタグの出力．
タグデータ定義編集部で追加したタグデータ定義を表 7 に示す．表 7 で示しているデータ
項目は，タグデータ入力部により提供された入力フィールドに入力した項目になる．それ以外の項目については自動収集を行っている．

5.5

評価方法

システムを利用したソフトウェアタグ生成のコストを検証する．評価基準は以下の項目である．

• タグデータ定義の追加に要した時間• データ入力に要した時間• 自動データ収集に要した時間
5.6

結果

表 7 に示す 13 項目のタグデータ定義を追加するのにかかった時間は 9 分 50 秒だった．表8 に入力時間と自動収集時間の結果を示す．

26

表 6: 収集タグデータ項目
分類

項番

タグ項目

要件定義

14

規模 [推移]15

変更 [推移]規模 [推移]設計

プログラミング

テスト

品質

16

17

変更 [推移]1920規模 [推移]変更 [推移]

21

複雑度

22

規模 [推移]

24

密度

25

消化

26

レビュー状況

27
28
29
30
31
32
33

レビュー作業密度
レビュー指摘率 [推移]
欠陥件数 [推移]
欠陥対応件数 [推移]
欠陥密度
欠陥指摘率
静的チェックの結果

収集タグデータ項目

収集方法

ユースケース図数
ユースケース数
アクター数
要件定義数
ユースケース図の追加数
ユースケースの追加数
アクターの追加数
ユースケース図の削除数
ユースケースの削除数
アクターの削除数

自動
自動
自動
手動
自動
自動
自動
自動
自動
自動

画面数
クラス図数
シーケンス図数
ステートマシン図数
アクティビティ図数
クラス図の追加数
シーケンス図の追加数
ステートマシン図の追加数
アクティビティ図の追加数
クラス図の削除数
シーケンス図の削除数
ステートマシン図の削除数
アクティビティ図の削除数

手動
自動
自動
自動
自動
自動
自動
自動
自動
自動
自動
自動
自動

ソースコード行数
行数の変更量
追加行数
削除行数
更新回数
CK メトリクス.WMC
CK メトリクス.NOC
CK メトリクス.CBO
CK メトリクス.RFC
CK メトリクス.LCOMCK メトリクス.DIT

自動
自動
自動
自動
自動
自動
自動
自動
自動
自動
自動

単体テスト項目数
結合テスト項目数
総合テスト項目数
単体テスト項目数 / ソースコード
総合テスト項目数 / ユースケース数
消化総合テスト項目数 / 総合テスト項目数
消化総合テスト項目数

手動
手動
手動
自動
自動
自動
手動

レビュー回数
レビュー時間レビュー回数 / レビュー時間
レビュー指摘件数
バグ報告数
バグクローズ数
バグ報告数 / ソースコード行数
バグ報告数 / 消化総合テスト項目数
checkstyle の検出数
findbugs の検出数
pmd の検出数
pmd-cpd の検出数

手動
手動
自動
手動
自動
自動
自動
自動
手動
手動
手動
手動

27

表 7: 追加したタグデータ定義

6

name

description

画面数

システムの画面の数．画面一覧.doc に記載．

レビュー指摘件数

レビューで指摘された件数. 議事録に記載．

レビュー回数

レビューを実施した回数．議事数でカウント．

レビュー時間レビューを実施した合計時間．議事録に記載．

Findbugs

Findbugs の結果

CPD

CPD の結果

PMD

PMD の結果．Priority1 から Priority5 まで．

Checkstyle

Checkstyle の結果．トータル出力数．

要件定義数

品質要求.doc に記載されている件数．

単体テスト項目数

Junit で実行したテスト項目数

結合テスト項目数

システムテスト仕様書に記載．

総合テスト項目数

統合テスト仕様書に記載．

消化総合テスト項目数

総合テスト仕様書に記載．

考察
タグ定義を 13 項目追加するためにかかった時間は 9 分 50 秒だった．１件の追加におよそ

46 秒ほどかかる計算になるが，プロジェクトの初めに１度追加するだけなので，入力時間の合計１時間 10 分に比べればそれほど大きなコストとはならなかった．

2007 年 3 月 27 日から 5 月 31 日までの期間は要求，分析，設計のフェーズであったため，
ソースコードが存在しない．また，欠陥件数に関する影舞のログもまだ存在していなかった
ため，この間の自動計測は JUDE ファイルからタグ項目要件定義，設計のデータを収集しているのみである．そのため，自動収集は１秒前後程度の非常に短い時間で終わっている．

2007 年 12 月 12 日から自動収集時間がそれまでに比べて大きくなっている．これはこの日からプログラミングが開始されたためである．リポジトリからのソースコードのエクス
ポート，MASU の実行，Diﬀ の実行に時間がかかった結果と言える．同時に入力時間も増えているが，リポジトリの登録を含む自動収集の設定に時間がかかり，それまでと比べて 5分以上余分に時間がかかった．リポジトリの登録などは一度行えば以降は行う必要がないた
め，後の計測は 2 分 30 秒ほどの入力時間ですんでいる．自動収集時間についてはそれ以降若干増加傾向にあるが，これはソースコードの規模が大きくなっているためと思われる．

31 日分のデータ入力時間の平均値は 2 分 17 秒である．ここで１ヶ月にかかる人的コスト28表 8: 実験結果

計測日

入力時間

自動収集時間計測日

入力時間

自動収集時間2007/03/27

0:01:54

0:00:01

2007/12/17

0:03:07

0:00:55

2007/03/30

0:02:54

0:00:00

2007/12/20

0:02:26

0:00:55

2007/04/04

0:02:27

0:00:00

2007/12/26

0:02:20

0:01:02

2007/04/06

0:01:45

0:00:01

2008/1/7

0:03:13

0:00:52

2007/04/10

0:01:43

0:00:02

2008/1/15

0:02:55

0:01:18

2007/04/18

0:01:19

0:00:01

2008/1/21

0:02:23

0:00:52

2007/04/23

0:01:42

0:00:01

2008/1/24

0:03:12

0:00:49

2007/04/26

0:02:05

0:00:01

2008/1/29

0:03:18

0:00:52

2007/05/07

0:01:13

0:00:01

2008/2/1

0:02:25

0:00:51

2007/05/10

0:01:13

0:00:01

2008/2/6

0:02:24

0:00:51

2007/05/15

0:01:16

0:00:01

2008/2/12

0:02:46

0:00:48

2007/05/21

0:01:140:00:01

2008/2/15

0:02:32

0:00:53

2007/05/24

0:01:29

0:00:01

2008/2/20

0:02:34

0:00:52

2007/05/29

0:01:29

0:00:02

2008/2/25

0:02:15

0:00:52

2007/05/31

0:01:09

0:00:02

2008/2/28

0:02:01

0:00:49

2007/12/12

0:06:04

0:00:41

入力時間

自動収集時間合計

1:10:47

0:14:28

最高値

0:06:04

0:01:1829

を考える．
開発プロジェクトでは，プロジェクトメンバーに作業進捗を週報，日報といった形で提出させる．そこでタグデータの収集日を週報に合わせ，1 週間に 4 回と仮定すると，1ヶ月に 4
回データの収集を行うことになる．1 日分の入力時間を結果の平均値からとって 2 分 17 秒とすると 1ヶ月の入力時間は式 (1) の通り 10 分程度となる．

2 : 17 ∗ 4(日) ≈ 10(分/月) ≈ 0.16667(時間/月)(1)

1 人月を 8 時間，20 日で換算すると，１人月の時間は式 (2) となる．
1 人月 = 8(時間) ∗ 20(日) = 160(時間/月)(2)

式 (1) を式 (2) で割れば，１ヶ月あたりのタグ収集にかかるコストが導き出せる．

0.16667= 0.00104125 ≈ 0.001(人月)
160

(3)

これは 1 人月を 100 万円とすると１ヶ月あたりにかかる費用は 1000 円程度となる．
ソフトウェア開発データ白書 2008[21]p.92 によると，ソフトウェアベンダー 21 社 1440 プ
ロジェクトの工数の統計平均は 27485 人時である．これを式 (2) に従い，人月に直すと約 172
人月になる．172 人月に対してソフトウェアタグ生成に必要な人的コスト 0.001 人月は非常に小さい値である．したがって，本システムを用いたソフトウェアタグ生成はコストが低いと言える．
入力時間が短くなった要因として，4.4.4 項で述べた前回の入力データを入力フィールドに保持しておくサポートが挙げられる．user,unit,obj は，初めの入力から最終日の入力まで変更することがなかったため，入力には時間がかからなかった．また，remarks についても追加数や削除数などの項目については「2008 年 1 月 29 日からの追加数」などの入力を行った
ものの，remarks に変更がない項目も存在したため，この場合は入力サポートの効果があったと言える．

30

7Threats to Validity
今回追加したタグデータ定義は 13 項目であったため，追加にそれほど時間はかからなかった．しかし実際のソフトウェア開発では入力する項目はこれよりもっと多い．例えば 100 項
目の追加を考えた場合，これをすべて人手でタグデータ定義を追加するのは手間がかかる．
したがって，基本的なデータについてはあらかじめタグデータ定義をシステム側から提供する必要があるだろう．
同時に，手動での入力項目は 13 項目と少なかったため，項目が増えるとそれに比例してデータ入力の時間も必要となる．
また，実験では 4.4.1 節で述べたタグデータの remarks などの入力も行ったが，これらのデータ量が多い場合，入力にさらに手間がかかる．user に関しても今回はすべて被験者の名前を入力したが，これの変更が多ければ入力時間が延びるだろう．
結果には示していないが，自動計測時間はリポジトリからのエクスポート，MASU の実
行時間が主に占めている．実験対象のプロジェクトはソースコード行数がおよそ 26000 行だったが，さらに巨大な規模のソフトウェアになると自動計測時間はさらに延びるだろう．
参考までにソースコード 2 １万行のオープンソースプロジェクトに対して行数とＣＫメトリ
クスの計測を行ったところ，計測時間は 6 分 52 秒となった．ただし，ネットワーク上のリ
ポジトリに対して計測を行ったので通信によるオーバーヘッドは生じている可能性がある．

UML 図やバグトラッキングシステムからの計測は１秒前後であったため，規模が大きくなってもオーバーヘッドは少ないと思われる．
今回の実験では被験者が開発者自身なので，システムに対する慣れが結果に影響を与えていると思われる．システムはソフトウェアタグやソフトウェア開発の定量的管理にそれなりに理解がある者を対象としているものの，初めてシステムを利用するものに対しては利用マ
ニュアルなどを作成する必要がある．
システムの利用者がソフトウェアタグを生成するプロジェクトについて全く理解がない場
合，つまり入力すべきデータの根拠となるファイルなどがどこにあるのか分からないような場合は結果よりさらに時間がかかる．今回，被験者はプロジェクトの要件定義書や議事録，
静的チェックの結果ファイルなどがどこに存在するか理解していたので，データの入力にとまどうことはなかった．システムの利用者はプロジェクトについてある程度の理解をしているか，もしくは入力するプロジェクトデータを各担当者がまとめて提出するような体制が必
要である．

31

8

関連研究
文献 [22] ではソフトウェアタグデータ収集システムのプロトタイプの開発を行っている．

こちらの研究は自動データ収集についてのみを取り扱っており，本研究が提案した収集タグ
データ項目をユーザが選択するといったことはできない．文献 [23] では本研究でも実験対象
プロジェクトとして用いた ITSpiral 実プロジェクト教材のソフトウェアタグを作成し，ソフトウェアタグからのプロジェクトの分析を行っている．

StagE プロジェクトの参考文献を挙げる．文献 [24] では本論文の 2 章，3 章でも紹介した
StagE プロジェクトとソフトウェアタグについて詳しく解説されている．文献 [25] ではソフ
トウェアタグ普及に向けた法的議論と利用技術基盤について，文献 [26] ではソフトウェアタ
グ支援ツールの開発について解説されている．文献 [27] はユーザ・ベンダ各々の作業の責任分担を調査し，各々の作業が十分に行われているかを定量的に判断する要求品質管理手法を提案している．文献 [5] では，発注者がプロジェクトの進捗状況を把握する際にソフトウェ
アタグを利用するという状況を想定した可視化ツールを提案している．従来の可視化ツール
では下流工程の可視化に重点を置いていたが，この研究では開発工程全体を網羅しているソ
フトウェアタグを用いるため，上流工程を含めた可視化を行うことが可能である．文献 [6]ではソフトウェアタグに含まれる設計文書メトリクスを用いて，低品質モジュールの予測を試みている．設計文書メトリクスを利用することで設計工程完了時に予測を行い，実装工程
における品質改善活動に寄与することができると述べられている．
文献 [28] では，定量的管理を取り入れたソフトウェア開発プロセスのためのオーサリン
グ・テーラリングフレームワークを提案している．オーサリングとはプロセスの構築作業，
テーらリングとは作業内容の修整作業を指す．文献では提案フレームワークをもとに定量的管理計画の立案を支援するシステム「AQUAMarine」を開発し，その評価を行っている．
リポジトリの履歴データを利用した参考文献を挙げる．文献 [29] ではリポジトリの履歴
データをもとにしてソースコード修正箇所のグルーピングを行ったデータベースを作成し，それをもとに開発者に修正箇所を提示するシステム ROSE を提案している．文献 [30] は CVSを用いた分析に必要な事前処理の収集，形式化を試みている．文献 [31] では Bugzilla のバグ
情報とソースコードの import 情報マッピングし，バグ予測を行う手法を提案している．文献 [32] では 5 つのオープンソースソフトウェアと１つのクローズドソースソフトウェアのバ
グトラッキングシステムやバージョン管理システムからデータを収集し，プロジェクトごとにデータの比較を行っている．
ソースコードのメトリクス計測に関する参考文献を挙げる．文献 [33] では計測するメトリ
クスや入力が同じ場合，結果は異なるのかをテーマにソフトウェアメトリクス計測ツールの比較を行っている．実験では 9 つの計測ツールに対し，100 プロジェクトのソースコードを32

入力として結果の比較を行っている．ソフトウェアタグ規格 [9] のタグ項目 3 番「静的チェッ
クの結果」に関連して，静的バグ解析ツールに関する研究である文献 [34] を挙げる．この論文では IntelliJ IDEA, FindBugs, Jlint の 3 つの静的バグ解析ツールのパフォーマンスの比較を行っている．

33

9

あとがき
本論文では，ソフトウェアトレーサビリティの実現を目的としたソフトウェアタグ生成シ

ステムの提案を行った．2 章ではソフトウェアトレーサビリティの必要性について述べ，3
章ではトレーサビリティを実現するソフトウェアタグについて述べた．4 章ではソフトウェ
アタグの生成方法に対する要求について整理し，それらを解決するためのシステムの設計を行い，システムの構成について述べた．5 章では実プロジェクトに対して本システムを用いてソフトウェアタグの生成を行い，そのコストについて評価を行った．その結果，本システ
ムによるソフトウェアタグの生成は非常に低コストで行えることを証明した．
今後の課題について述べる．
まず，標準タグデータ定義を作成する必要がある．7 章で述べたように入力するタグデー
タ項目が増加すると，それだけタグデータ定義を作成する必要があるため，高コストにつながる．そのためシステム側で基本的なデータについてはタグデータ定義を提供する予定である．
生成コストを下げるため，また自動収集の適応可能対象となるプロジェクトを増やすために，自動収集機能を拡張することも考えられる．UML モデリングツールからの計測は現状

JUDE[15] だけであるため，Microsoft Visio[17] や IBM Rational Software Modeler[16] などへの対応を検討する必要がある．バグトラッキングシステムにおいても，Bugzilla[35] など認知度の高いものについては対応していく必要がある．
また，発注者にわかりやすく開発状況や品質を示せるようなタグデータの表示形式を考える必要がある．プロジェクトの途中で，一般的なプロジェクトデータの統計値 [21] と比較できるような形式でタグデータを出力し，提示することで発注者は進捗を確認することができる．また，一般的なプロジェクトと比較することにより発注したソフトウェアのプロジェク
トに対して安心感をもつことができる．また，データに疑問があった場合には受注者に確認をとることができるため，プロジェクトの問題早期発見につながる．
最後に，システムの現場評価が必要である．これについては協力企業にシステムの利用を依頼し，評価をお願いする．またネットワーク上での公開も予定している．現場での利用，
公開に向けてアプリケーションとしての利便性，信頼性を上げ，マニュアルの整備を行う．
さらに利用者からの評価を反映し，システムの改善を行っていく予定である．

34

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

35

参考文献
[1] 井上克郎, 松本健一, 鶴保征城, 鳥居宏次: “実証的ソフトウェア工学研究への取り組み”,
情報処理学会, Vol. 45, No. 7, pp. 722–728, 2004.

[2] 「動かないコンピュータ」の解決に裁判は役立つか: “
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040609/145573/,”.
[3] StagE プロジェクト: “http://www.stage-project.jp/,”.
[4] E. R. Harold: “XML バイブル”, 日経 BP 社, 2001.
[5] 奥村哲也, 大蔵君治, 伏田享平, 川口真司, 名倉正剛, 飯田元. “ソフトウェアタグの運用を支援する開発履歴可視化ツール”,. 情報処理学会第 166 回ソフトウェア工学研究会,
情報処理学会研究報告, 第 2009-SE-166 巻, pp. 1–8, October 2009.

[6] 片山真一, 大蔵君治, 伏田享平, 川口真司, 名倉正剛, 門田暁人, 飯田元. “ソフトウェア
タグを用いた設計文書メトリクスからの 低品質モジュールの予測”,. 電子情報通信学会
技術研究報告, 第 109 巻, pp. 067–072, December 2009.

[7] 日経コンピュータ 特集 1：ユーザーの言い分ベンダーの言い分, pp. 40–55, 2008 年 10
月 1 日号.

[8] 開発のための CMMI.(CMMI-DEV) 1.2 版: “
http://www.sei.cmu.edu/cmmi/translations/japanese/models/dev-v12-abstractj.html,” 技術報告書, Vol. CMU/SEI-2006-TR-008, .
[9] ソフトウェアタグ規格第 1.0 版: “
http://www.stage-project.jp/kanri/data/dl/20081029151602.pdf,”.
[10] 松本健一: “エンピリカルソフトウェア工学の現状と展望：SEL が残した 13 の教訓”,
SEC journal, No. 2, pp. 6–13, 2005.
[11] subversion.tigris.org: “http://subversion.tigris.org/,”.
[12] C. C. V. System: “http://www.nongnu.org/cvs/,”.
[13] Gnats: “http://www.gnu.org/software/gnats/,”.
[14] バグトラッキングシステム影舞: “http://www.daifukuya.com/kagemai/,”.
[15] astah*(旧 JUDE)): “http://astah-users.change-vision.com/ja/,”.
36

[16] IBM Rational ソフトウェア http://www-06.ibm.com/jp/software/rational/.
[17] M. O. Visio: “http://oﬃce.microsoft.com/ja-jp/visio/default.aspx,”.
[18] 三宅達也, 肥後芳樹, 楠本真二, 井上克郎: “多言語対応メトリクス計測プラグイン開発
基盤 MASU の開発”, 電子情報通信学会論文誌 D, Vol. J92-D, No. 9, pp. 1518–1531,

2009.
[19] S. R. Chidamber and C. F. Kemerer: “A Metrics Suite for Object-Oriented Design,”
IEEE Trans. Software Eng., Vol. 20, pp. 476–493, 1994.
[20] IT スパイラル: “http://it-spiral.ist.osaka-u.ac.jp/index.html,”.
[21] 独立行政法人情報処理推進機構（IPA）, ソフトウェア・エンジニアリング・センター（SEC）. ソフトウェア開発データ白書 2008. 日経 BP 社, 2008.

[22] 西川倫道, 鵜久森将隆, 山田慎也, 楠本真二: “ソフトウェアタグデータ収集システムの試作”, ソフトウェア信頼性研究会第 5 回ワークショップ論文集, pp. 57–65, 2009.

[23] 山田慎也, 西川倫道, 鵜久森将隆, 楠本真二: “実プロジェクトデータからのソフトウェ
アタグ作成とその分析”, 情報処理学会, 2009.

[24] 松本健一: “事故前提社会に向けたユーザ・ベンダ間での開発データ共有− StagE プロ
ジェクトとソフトウェアタグ−”, SEC journal, Vol. 5, No. 3, pp. 198–203, 2009.

[25] 久保浩三, 小柴昌也, 角田雅照, 松村知子: “事故前提社会に向けたユーザ・ベンダ間での開発データ共有−ソフトウェアタグ普及に向けた法的議論と利用技術基盤−”, SEC

journal, Vol. 5, No. 6, pp. 368–376, 2009.
[26] 井上克郎, 楠本真二, 飯田元: “事故前提社会に向けたユーザ・ベンダ間での開発データ
共有−ソフトウェアタグ規格とソフトウェアタグ支援ツール−”, SEC journal, Vol. 5,

No. 5, pp. 234–243, 2009.
[27] 松村知子, 松本健一: “ユーザとベンダ間の協調による要求品質確保のための定量化事
例−”, 奈良先端科学技術大学院大学テクニカルレポート, NAIST-IS-TR2009006, 2009.

[28] 伏田享平, 高田純, 米光哲哉, 福地豊, 川口真司, 飯田元: “AQUAMarine: 定量的管理計
画立案システム”, SEC journal, Vol. 5, No. 4, pp. 244–251, 2009.

37

[29] T. Zimmermann, P. Weisgerber, S. Dieh, and A. Zeller: “Mining Version Histories
to Guide Software Changes,” International Conference on Software Engineering Proceedings of the 26th International Conference on Software Engineering, pp. 563–572,
2004.
[30] T. Zimmermann and P. Weisgerbe: “Preprocessiong CVS Data for Fine-grained analysis,” 1st International Workshop on Mining Software Repositories, pp. 2–6, 2004.
[31] A. Schroter, T. Zimmermann, and A. Zeller: “Predicting Component Failures at
Design Time,” Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering, pp. 18–27, 2006.
[32] A. Bachmann and A. Bernstein: “Software process data quality and characteristics:
a historical view on open and closed source projects,” Proceedings of the joint international and annual ERCIM workshops on Principles of software evolution (IWPSE)
and software evolution (Evol) workshops, pp. 119–128, 2009.
[33] R. Lincke, J. Lundberg, and W. Löwe. “Comparing software metrics tools,”. In
ISSTA ’08: Proceedings of the 2008 international symposium on Software testing andanalysis, pp. 131–142, New York, NY, USA, 2008. ACM.
[34] F. Wedyan, D. Alrmuny, and J. M. Bieman: “The Eﬀectiveness of Automated Static
Analysis Tools for Fault Detection and Refactoring Prediction,” ICST Proceedings ofthe 2009 International Conference on Software Testing Verification and Validation,
pp. 141–150, 2009.
[35] Bugzilla.org: “http://www.bugzilla.org/,”.

38