社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

Empirical Project Monitor: プロセス改善支援を目的とした定量的開発データ自動収集・分析システムの試作
大平雅雄†

横森 励士††

阪井誠†††

鳥居宏次†

松本 健一†

井上 克郎††† 奈良先端科学技術大学院大学 〒 630–0192 奈良県生駒市高山町 8916–5†† 大阪大学 〒 560–8531 大阪府豊中市待兼山町 1–3††† 株式会社 SRA 先端技術研究所 〒 164–0004 東京都渋谷区四谷 3–12
E-mail: †ohira@empirical.jp,｛matumoto, torii｝@is.aist-nara.ac.jp, ††{yokomori,inoue}@ist.osaka-u.ac.jp,†††sakai@sra.co.jp
あらましソフトウェアの生産性や信頼性向上を目的とするプロセス改善は急務の課題となっているが，実際のソフトウェア開発現場におけるプロセス改善の実施は困難を伴う場合が多い．その原因の一つとして，一貫性のある定量的なデータを継続的に測定することが難しいという問題が挙げられる．本稿では，ソフトウェア開発におけるプロセスデータを自動的に収集・分析する Empirical Project Monitor (EPM) を紹介する．EPM は，開発者に特別な負担をかけることなく開発プロセスに関する定量的データを自動的に収集し，プロセス改善のために有益な分析結果を提示するシステムである．
キーワード

ソフトウェアプロセス改善，エンピリカルソフトウェア工学，データ自動収集，定量的データ分析

Empirical Project Monitor: A System that Automatically Collects andAnalyzes Quantitative Development Data toward Process Improvement
Masao OHIRA† , Reishi YOKOMORI†† , Makoto SAKAI††† , Ken-ichi MATSUMOTO† , Katsuro
INOUE†† , and Koji TORII†† Nara Institute of Science and Technology, 8916–5, Takayama, Ikoma, Nara 630–0192, Japan†† Osaka University, 1–3, Machikaneyama, Toyonaka, Osaka 560–8531, Japan††† SRA Key Technology Laboratory, Inc. 3–12, Yotsuya, Shinjuku, Tokyo, 164–0004, Japan
E-mail: †ohira@empirical.jp,｛matumoto, torii｝@is.aist-nara.ac.jp, ††{yokomori,inoue}@ist.osaka-u.ac.jp,†††sakai@sra.co.jp
Abstract In recent years, improvement of software process is increasingly gaining attention. However, its practice
is not easy because of difficulties of data collection and utilization of collected data. In this paper, we introduce
Empirical Project Monitor (EPM), which is an automatic data collection and analysis system to support software
process improvement. Collecting data from common tools used in software development, EPM analyzes the data
automatically and provides graphical results. EPM assists and facilitates coherent data collection which is a difficult
task in practice.
Key words Software Process Improvement, Empirical Software Engineering, Automatic Data Collection, Quantitative Data Analysis

1. は じ め に

その重要性が増す中で，ソフトウェアの生産性および信頼性の近年，ソフトウェアシステムの社会的役割が多様化し，かつなっている．一般的にソフトウェアプロセスの改善は，ソフト向上を目的としたソフトウェアプロセスの改善は急務の課題とウェアプロセスの現状分析，新しいソフトウェアプロセスの設て開発中の Empirical Project Monitor (EPM) を紹介する．

計，新しいソフトウェアプロセスの評価と展開の 3 つの段階を

EPM は，開発者に特別な負担をかけることなく開発プロセス順次，継続的に行うことで達成されるものである [1]．

に関する定量的データを収集し，プロセス改善のために有益なプロセスの現状分析では，現状のプロセスを理解し問題点の分析結果を提示するシステムである．

洗い出し等を行い，次に，プロセスの設計では，現状プロセス

以下，本稿の構成は次の通りである．2 章では，ソフトウェアの分析結果に基づいて改善策の立案等を行う．そしてプロセス

プロセス改善に関する諸問題に対処するための我々のアプローの評価では，新しく設計されたプロセスが以前のプロセスに比チと ESEE の概要を述べる．続く 3 章では，EPM を紹介し，べてどの部分が，どのように，どれくらい改善されたか等につ4 章では EPM をプロセス改善のために利用する利点についていて評価を行う．これらのステップをより適切かつ効果的に行説明する．最後に，5 章においてまとめと今後の課題を述べ本う，すなわち，より良いプロセス改善を進めるためには，客観稿を結ぶ．

的で一貫性のある定量的データに基づいてプロセスの分析・設計・評価がなされることが望ましい．
ソフトウェア開発に関する諸計測技術は，ソフトウェアプロセスおよびソフトウェアプロダクトの理解，管理，制御，予測等を行う際の有効な手段としてこれまで数多く提案されてき

2. エンピリカルソフトウェア工学環境
本章では，前章で述べた諸問題に対処するための我々のアプローチについて述べる．

2. 1 改善のためのサイクリックプロセス

た [2]．一般に，ソフトウェア計測のためのデータ収集に要する

これまで， ソフトウェアプロセス改善を支援するために，数多コストは決して低いものではないが，多くの企業では多大な労くのモデルが提案されてきた（CMMI [7], IDEAL MODEL [8]

力を払いデータの収集を行っている．

等）．これらのモデルは共通して，段階的かつ継続的なプロセ

しかしながら，ソフトウェア計測に関する十分な経験がなければ，プロセス改善のための目標を明確に設定できない，分析

ス改善を通じてソフトウェアの生産性や信頼性を向上させるための一連のガイドラインを提供している．に必要なソフトウェアやメトリクスが何かわからない，分析結果を次の改善活動に結びつける道筋が定かではない等，提案さData
Collection

れているメトリクスや収集データを活用し効果的にプロセス改善を進めることができない [3]．また，関係者の配置転換等，人DataAnalysis

員の流動によって組織内にデータ収集に関する十分な経験が蓄積されにくいという場合も少なくないため，一貫性のないデー

Feedback forImprovement

タ収集方法（方針）が継続的なプロセス改善を困難にする原因ともなっている．

図1

プロセス改善のための基本モデル

このような問題に対処するためのアプローチとして，GQM(Goal-Question-Metric) 法がある [4], [5]．GQM 法は洗練され

図 1 は，プロセス改善に対する我々の基本モデルである．本た計測技法の一つである．GQM 法では，計測のための目標モデルは，ソフトウェア開発データの大規模収集，集約的デー(Goal) を設定し，それらの目標を達成するために必要な要件をタ分析, プロセス改善のためのフィードバック，というサイク明確にするための質問 (Question) を挙げる．そして，その質リックなプロセス改善活動を想定している． 特に， 他の既存モ問に基づき計測モデルと計測手順を決定する．GQM 法を利用

デルのように厳格な手順を規定するものではなく，ソフトウェしたソフトウェアプロセスの改善は，論理的かつ合理的な手法

ア開発プロジェクトおよび組織の問題に沿って柔軟な改善活動である．一方，その実践においては，関係者が計測プロセスのを行うためのモデルである．このような柔軟な改善モデルに基詳細について関与する必要があるため，たゆまぬ努力と高いコづく支援環境は，ストが要求される．
上述の問題を要約すると，計測のための努力がソフトウェエ
アプロセスの効果的な改善に結びつかない大きな要因は，•個人の経験に依存しない定量的な計測•

特別な作業負荷やコストを必要としない計測を行えるように設計・構築することが重要であると考える．こ

•計測に関する経験の欠如

れらの 2 点は，前章で挙げた問題を解決するための我々の計測•

計測にかかるコストの負荷活動支援のための基本方針でもある．の 2 点に集約されると捉えることができる．

2. 2 ESEE の設計方針

これらを克服するためのアプローチとして，我々はエンピリ

現在我々は，柔軟な改善モデルを実現するために，以下に述

カルソフトウェア工学 [6] に取り組んでいる．定量的なデータにべる 3 つの設計方針に沿って支援環境 ESEE を構築中である．

基づいて様々な手法，技術，ツール等を評価する一方で，産業界データ収集のための方針：との協力による実データの収集を図ることで，より実践的なプ•

改善目標の設定優先ではなく，大規模データ収集を優先

ロセス改善のための支援環境（エンピリカルソフトウェア工学（理想的には改善のための目標設定が重要であるが，あらかじ

環境 (Empirical Software Engineering Environment: ESEE)

め明確な改善目標を設定すること自体が困難な場合が少なくなと呼ぶ．
）の構築を目指す．本稿では，ESEE 構築の一環としいため）•

プロダクトデータを中心に収集（データ収集のための管発プロジェクトデータを自動的に収集する．ソフトウェア開発

理者・開発者の余分な負担を最小限に抑えるため，プロセスに一般的に利用されているシステムからデータを収集すること

データはプロダクトデータから可能な限り抽出する）

で，データ収集専用の新たなシステムの導入や，不慣れなシス•

人為的操作のない加工されていないデータを収集（ドキュメント等，主観的なデータが混入しやすいものを排除する

テムの利用にかかる負担を避ける狙いがある．
フォーマット変換： 収集データをプロダクトデータと（プロため）ダクトデータから抽出した）プロセスデータに分類する．プロ•

セスデータは XML 形式のデータに変換する．プロダクトデー

リアルタイムでのデータ収集（現状を即座に把握し開発プロセスの管理・改善に連動させるため）•広く利用されている開発支援システムからデータを収集（開発形態に依存しない多様なプロジェクトも支援の対象とするため）タを直接利用するのではなく，一度中間形式に変換するので，分析目的に応じた様々なデータにも対応が可能である．
データ蓄積：プロダクトデータとプロセスデータをそれぞれデータベースに格納する．プロダクトデータはコードクローン

データ分析のための方針：本研究では，以下に挙げる順序で検出 [9] のようにソースコード等の生データを必要とする分析段階的に実データを分析しつつ，その有効性を探る予定である．に利用する．プロセスデータは作業進捗，作業効率，生産性等，（ 1 ） 単一のプロジェクトを対象とするプロセス・プロダク

開発作業全体の特性を分析するために利用する．

トメトリクス（簡易，容易）

データ分析・可視化：コードクローン検出，ソフトウェアコン（ 2 ） 複数のプロジェクト間のメトリクス

ポーネント検索 [10]，協調フィルタリングによる類似プロジェ（ 3 ） プロジェクトの分類・進化予測

クト同定 [11], プロジェクト分類 [12] 等，様々な分析・可視化（ 4 ） コンポーネント・専門知識の再利用ツールを提供予定である．

（ 5 ） さらなる複雑・高度な分析

このように，ESEE は膨大なデータを数千規模のソフトウェ

本研究では，定量的かつ大規模なデータを分析処理する手ア開発プロジェクトから自動的に収集し，分析結果を提供する法および技術を開発し，組織の利益に直結するようなフィードシステムである． プラグイン形式でシステムへ機能を追加するバックを提供する仕組みを構築する．個々の開発者・管理者あことができる仕組みによって ESEE を拡張性の高い柔軟なシス

るいは単一のプロジェクトを支援の対象にした研究やツールはテムにする．プロジェクトや組織によってプロセス改善のため数多く提案されてきたが，数千規模のプロジェクトおよび組織のデータ分析の目的は異なる場合が多いため，様々なプロジェを支援の対象にする研究はほとんど見当たらない．大規模デー

クトおよび組織を支援する上で，この仕組みは非常に重要であ

タから有用な知識を抽出する方法を探るために，上記のようにると思われる． このことが，柔軟性のない（追加的な分析要求簡易なメトリクスから順次，複雑・高度な分析手法を開発し，に対応しにくい） 完全なシステムを構築するよりも，定量的実データに適用する方針である．

データ収集基盤というべき基本的な枠組みを提供することを重フィードバック提供のための方針：我々は，プロジェクトおよび組織のそれぞれの目的に応じたフィードバックを提供する
柔軟なシステム構築を目指しており，現在様々なツールや手法の評価を行いながら，ESEE を構築中である．3 章で紹介する

Empirical Project Monitor (EPM) は，ESEE 構築の一環として開発したシステムである．EPM は，開発者に特別な負担をかけることなく定量的な開発データを収集し，プロセス改善のために有益な分析結果を提示するシステムである．

視する理由である．

3. Empirical Project Monitor (EPM)
本 章 で は ，ESEE 構 築 の 一 環 と し て 実 装 中 の Empirical

Project Monitor (EPM) を紹介する．
3. 1 EPM の概要
EPM はプロセス改善の支援を目的とした，開発データの自動収集・分析システムである．EPM は，ソフトウェア開発に

2. 3 アーキテクチャ

おいて一般的に利用されているシステムから開発活動に関するESEE は図 1 のすべてのステップを支援する単一の巨大な支データを収集し，プロセス改善のために有益な分析結果をユー援環境ではなく，分析の目的や方法に応じて交換可能なプラグザに提供する．EPM は，実際の開発現場では困難がつきまとイン形式の様々なツール群から構成される柔軟なシステムであう一貫性のある定量的データ収集とデータ利用を容易にする．

る．ESEE の本質的な機能は，(1) 数千規模のプロジェクトの開EPM は ESEE の基本コンポーネントから構成されている

発データを収集し，(2) その膨大な収集データをプロセス改善（図 2 中の灰色部）．ESEE の枠組みに沿って，EPM は構成管および組織の利益に直結させるために分析結果（フィードバッ

理システム，メーリングリストマネージャ，障害管理システム

ク）を提供するという 2 点にある．という， ソフトウェア開発支援として広く普及し利用されてい図 2 は ESEE の概略図である．ESEE は，データ収集，フォーるシステムからデータを収集する．

マット変換，データ蓄積，データ分析・可視化の 4 つのコンポー

EPM は Ruby で記述されたスクリプトによって分析対象のネントから構成されている．以下では，それぞれの機能についデータを XML 形式に変換する．XML 形式のデータは各コンて簡単に説明する．

ポーネントとのインターフェースとして公開されている．現在

データ収集：構成管理システムやメーリングリストマネー

EPM は，構成管理システムとして CVS ，メーリングリスト

ジャ等， 広く普及している開発支援システムから数千規模の開マネージャとして mailman, Majordomo, fml，障害管理シス

図 2 ESEE のアーキテクチャと EPMテムとして GNATS, Bugzilla のデータを XML に変換可能でを収集することによって，一貫性のある分析結果を提供するこある．これらは（特にオープンソース）ソフトウェア開発プロとができる． また，オープンソースで利用され，かつ一般的なジェクトで一般的に利用されているシステムであるため，デーシステムを利用するため，作業負荷・導入コストを最小限に抑タ収集のために開発者・管理者に特別な作業や導入コストをかえる事ができる．

けない．これらのシステムは改造せず，コマンドの実行結果を

3. 2 EPM の可視化結果出力したログの解析や，明確に定義された保存ファイル・DB

EPM は収集データから主に，ソースコードの規模 (Linesからの抽出によってデータを得ており，最新バージョンへの対of Code)，チェックイン/チェックアウトの数，メール/障害報応が比較的容易な構造になっている．これら以外のシステムの告の数等を計測する．それらのメトリクスを使用したデータ

データについては，現在のフォーマットとのデータ項目の対応分析を行い，現在，EPM は 5 種類の分析結果を提示すること付けを行い XML 形式に変換することで利用可能である．

ができる．以下では，我々のプロジェクト（EASE プロジェク

XML 形式のデータは EPM の内部では PostgreSQL データベースに格納される．格納されたプロセスデータはユーザ（管ト [13]）を例として利用し，EPM が可視化する分析結果について述べる．

理者・開発者）の要求に応じて分析結果を提示する．データはソースコードの規模推移：図 3 は，は，我々のプロジェクト随時収集され，リアルタイムで分析されるため，ユーザは容易におけるソースコード規模の推移（図中，黒の折線）を示したに現在のプロジェクトの状況を理解することができる．

ものである．図中，灰色の垂線は開発者が CVS リポジトリを例えば，構成管理システムからは，ソースコードの修正，更新した（チェックインの）時期を示しており，リポジトリ中チェックイン，チェックアウト等のイベントについての情報をのあるソースコードに対して追加/修正/削除等の操作を行った

抽出し，プロセスデータとして XML 形式のデータに変換されことを示している．このグラフはプロジェクトの現在の進捗をる．同時に，CVS リポジトリ中のコンポーネントのサイズ，更把握するために役立つ．また， 過去の同様なプロジェクトと比新時期，バージョン等の変遷を抽出する．メーリングリストマ

較することによりある程度の予測が可能となる．

ネージャあるいは障害管理システムからは，メール，障害報告

チェックインとチェックアウトの関連：図 4 は，チェックインや障害修正報告等を元に，投稿時間，件名，差出人等の情報をの時期（図中，灰色の垂線）とチェックアウト回数（図中，黒抽出し，XML 形式に変換する．同時に，話題ごとに集計したの垂線）との関係を示している．CVS リポジトリに対して開一覧表も作成する．

発者が更新（チェックイン）操作を行った場合，通常他の開発分析は Java サーブレットにより行われ，結果をウェブブラ者はローカルにある自らのファイルを更新するためにチェックウザから閲覧することができるので，EPM は分析結果の共有アウトの操作を行う．チェックイン後にチェックアウト数が少を促進する．分析結果共有の簡便化は，収集データを理解する

ない場合は， ファイルが更新されているにもかかわらず他の開ために行う議論の場に有効である．

発者がそれを参照していない，あるいは，その更新が他の開発

このように，EPM は定量的な開発データを低いコストで収者には重要ではないことを意味する．したがってこのグラフか集し，開発プロジェクトのリアルタイムでの管理を支援する．

ら，開発者がチェックイン後に CVS リポジトリを参照したか，基本的な 3 種類のシステムから人為的操作のされにくいデータ参照が少ない場合に他の開発者に知らせるべき更新が存在する図3

図4

図6

ソースコードの規模推移

図7

チェックインとチェックアウトとの関連

チェックインと障害件数との関連

累積・未解決障害件数と平均障害滞留時間との関連推移（図中，黒の折線グラフ）とチェックインの時期（図中，灰色の垂線）との関係を示している．障害報告がなされた後，開発者が障害修正の結果を反映するためにチェックインが行われる場合が多い．したがって，このグラフは各バージョンごとの障害対応の状況を確認するのに役立てることができる．
累積・未解決障害件数と平均障害滞留時間との関係：図 7 は，障害報告の累積（図中，上の折線），未解決障害件数の推移（図中，下の折線），平均障害滞留時間（図中，真中の折線）との関係を示したものである．このグラフは，プロジェクト管理者が
図5

メール投稿数の推移とチェックイン/障害発生/解決時期との関連

現在プロジェクトが抱えている障害件数や障害が解決されるまでにかかる平均時間を把握するのに役にたつ．また，プロジェか等の確認が行える．
メールの投稿数の推移とチェックイン/障害発生/障害解決時

クトが抱えている障害状況が一目できるため，開発者がバグを減らすための動機付けとしても利用することができる．

期との関連：図 5 は，開発者用のメーリングリストを使用してこのように，EPM はプロジェクト管理のために有益な分析投稿されたメールの累積の推移（図中，太い黒の折線），障害結果を提供し，プロジェクトのプロセス改善に利用することが発生時期（図中，細かい点線），障害解決時期（図中，粗い点できる．現在の実装では，上記の 5 種類のグラフおよびスケー線），チェックインの時期（図中，灰色の垂線）との関係を表し

ル（週/月/年）を変更したものを提供するのみであるが，デーたものである．このグラフから，障害発生/解決時期とコミュ

タ分析のための方針 (2) の複数のプロジェクト間の関係を分析・ニケーションの関係を知ることができる．障害管理システムへ可視化する機能を実装予定である．また，ユーザ自身がデータ障害報告がなされた場合，一般的に，開発者はその障害についベースを直接操作し，希望に応じた分析結果を提供できるようてメーリングリストを利用して活発に議論をはじめる場合が多なカスタマイズ機能も実装中である．

い．障害が数多く報告されているにもかかわらず，開発者が議4. EPM の利用シナリオ論を行っていないならば，開発者間のコミュニケーションに問題がある可能性が高い．また，このグラフの障害発生時期，（バ

本章では，プロジェクト管理に EPM を利用する利点を，ソグフィックスを行った）チェックイン時期，障害解決時期の対応

フトウェア開発の現場でしばしば言及される以下のような問題から，プロジェクトの障害対応の状況も確認することができる．

をシナリオとして用いながら説明する．

チェックインと障害件数との関係：図 6 は障害報告の累積の•データを収集する際の開発者・管理者の負荷の増加

•

プロジェクトの進捗状況に関連した情報交換の遅れ

本研究ではソフトウェア産業からの協力を得てこの壁を打破し，•データの人手による操作産業界の実データと実践的な手法によって問題解決のための研

一点目は，開発者・管理者がデータ収集のために付加的な作業を求められるときに問題となる．例えば，データ収集が目的究を進めたいと考えている．
謝辞

本研究の一部は，文部科学省「e-Society 基盤ソフトの進捗報告やプロダクト報告は，作業量の増加を敬遠する管理ウェアの総合開発」の委託に基づいて行われた．ESEE および者・開発者にとっては負担となることは少なくない．

EPM の実装では，岩村聡氏，小野英治氏，新海平氏にご協力

EPM は，一般的なソフトウェア開発において広く普及している開発支援システムからデータを収集するため，EPM を導入するにあたって付加的な作業やコストはほとんど生じない．
また，たとえ CVS 等のシステムを利用していないプロジェク
トであっても，フリソフトウェアを基本データ収集用システムとして使用しているため，導入コストは極めて低い．
二点目の問題は，コミュニケーションに関連したものである．
多くの場合，開発者間のコミュニケーション不足は，生産性を引き落とす原因である [14]．特に，近年盛んに行われている分散開発では，対面でのコミュニケーションを行う機会が非常に少ない．遠隔地の他者とコミュニケーションをとる手段としては電子メールが日常的に利用されているが，電子メールを介したコミュニケーションでは適切なタイミングで適切な人物から正しい情報を得ることは極めて難しい [15]．

EPM の特徴の一つは，データをリアルタイムに収集し，結果を一般的なブラウザを利用して閲覧可能な点である．このことは開発者が現在のプロジェクトの状況を把握し，他の開発者と現状理解を共有するのに役立つ．特に，前章図 5 で紹介したグラフのような，リアルタイムで確認できるコミュニケーションの履歴は，コミュニケーション不足等を示す一種のアラートとして利用することができる．
最後の問題は，ドキュメント中心のプロジェクト管理においてしばしば言及される問題である．人手によるドキュメントの質は，個々人の経験の違いや人事評価を意識したデータの加工等によって客観性および一貫性が失われる場合がある．

EPM を利用したプロジェクト管理では，人手による恣意的なデータ操作は基本的に不可能なため，上述の問題は生じにく
い．この特徴が，客観的なデータに基づいた一貫性のある継続的なプロセス改善活動を支援することにつながるものと考える．

5. まとめと今後の課題
本稿では，プロセス改善へ向けたの我々のアプローチとエンピリカルソフトウェア工学環境 (ESEE) の概要について述べた．
また，ESEE の部分的実装として構築した Empirical Project

Monitor (EPM) を紹介した．EPM は，開発者に特別な負担をかけることなく，開発プロセスに関する定量的データを自動的に収集し，プロセス改善のために有益な分析結果を提示することができる．現在我々は，様々な分析要求に対応可能なカスタマイズ機能，複数のプロジェクトデータの比較分析機能を実装中である．また，EPM の評価を目的として企業の開発現場にEPM を導入することも計画中である．
これまでわが国では，多くの課題を抱えている産業界のソフトウェア開発に関するデータが，大学等の研究者に届くことは少なく，この領域の技術進歩の大きな阻害要因となってきた．

頂いた．深く感謝いたします．
文献[1] 大場充, 堀田勝美, 松浦建司, ソフトウェアプロセス改善と組織学習–CMM を毒にするか？薬にするか？–, ソフト・リサーチ・センター, 2003.
[2] 井上克郎, 松本健一, 飯田元, ソフトウェアプロセス, ソフトウェ
アテクノロジーシリーズ, プロセスと環境トラック, 第 8 巻, 共立出版, 2000.
[3] L. Briand, C. Differding, and D. Rombach, Practical guidelines for measurement-based process improvement, Technical Report ISERN–96–05, Department of Computer Science, University of Kaiserslautern, Germany, 1996.
[4] V. Basili and D. Weiss, A methodology for collecting valid
Software Engineering Data, IEEE Transactions on Software
Engineering, Vol.10, No.6, pp.728–738, 1984.
[5] V. Basili, Applying the Goal/Question/Metric Paradigm inthe Experience Factory, Presented at the 10th Annual CSR
Workshop in Amsterdam, 1993.
[6] V. Basili, The Experimental Software Engineering Group:
A Perspective, ICSE’00 award presentation, Limerick, Ireland, June 5–10, 2000.
[7] CMMI Product Team, Capability Maturity Model Integration (CMMI) Version 1.1 CMMISM for Systems Engineeringand Software Engineering (CMMI–SE/SW, v1.1), Continuous Representation, CMU/SEI–2002–TR–001, ESC–TR–2002–001, 2001.
[8] J. Gremba and C. Myers, The IDEAL Model: A PracticalGuide for Improvement, appeared in the Software Engineering Institute (SEI) publication, Bridge, issue 3, 1997.
[9] T. Kamiya, S. Kusumoto, and K. Inoue, CCFinder: A
Multi-Linguistic Token-based Code Clone Detection System for Large Scale Source Code, IEEE Transactions on
Software Engineering, Vol.28, No.7, pp. 654–670, 2002.
[10] R. Yokomori, T. Ishio, T. Yamamoto, M. Matsushita, S.
Kusumoto, and K. Inoue, Java Program Analysis Projectsin Osaka University: Aspect-Based Slicing System ADAS
and Ranked-Component Search System SPARS-J, Proceedings of the 25th International Conference on Software Engineering (ICSE’03), pp.828–829, Portland, Oregon, 2003.
[11] N. Ohsugi, A. Monden, and S. Morisaki, Collaborative Filtering Approach for Software Function Discovery, Proceedings of 2002 International Symposium on Empirical Software Engineering (ISESE 2002), Vol.2, pp.45–46, Nara,Japan, 2002.
[12] S. Kawaguchi, P. K. Garg, M. Matsushita and K. Inoue,
Automatic Categorization for Evolvable Software Archive,
International Workshop on Principles of Software Evolution(IWPSE’03), pp.195–200, Helsinki, Finland, 2003.
[13] EASE (Empirical Approach to Software Engineering)project, http://www.empirical.jp/index-e.html[14] A. H. Dutoit and B. Bruegge, Communication Metrics for
Software Development, IEEE Transactions on Software Engineering, Vol.24, No.8, pp.615–628, 1998.
[15] J. D. Herbsleb, A. Mockus, T. A. Finholt and R. E. Grinter, An Empirical Study of Global Software Development:
Distance and Speed, Proceedings of the 23rd international
conference on Software engineering (ICSE’01), pp.81–90,
Toronto, Canada, 2001.