実証的ソフトウェア工学

ソフトウェアの高度化、大規模化とこれに伴う開発コストの増大に伴い、ソフトウェア開発において、生産性の向上と品質の確保が重要な課題となっています。

そのための有用なアプローチとして、ソフトウェア開発の分野において、他の科学、工学分野と同様に、計測、定量化と評価、そしてフィードバックによる改善という実証的手法(エンピリカルアプローチ)が注目されています。
エンピリカルアプローチでは、以下の5つのステップが実施されます。

以降、Step3~Step5を繰り返します。

この研究テーマでは、エンピリカルアプローチを用いて、以下のような研究を行っています。

StagE

StagE(Software Traceability and Accountability for Global software Engineering:エンピリカルデータに基づくソフトウェアタグ技術の開発と普及)

プロジェクトそのものは,2012年3月31日で終了しますが,引き続き関連研究を実施していきます.

背景:ソフトウェアに対する漠然とした不安

ソフトウェア技術は,情報家電製品,ハイブリッド自動車をはじめ,航空管制システム,金融管理システムなどの社会・産業の基幹システムまで広く用いられており、国民生活を支える社会インフラの基盤となっています.しかし,そこで用いられているソフトウェアがどのような過程で構築され,どれだけ信頼ができる品質を持っているのか,発注者にもユーザーにもわかりません.

StagE01

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

ソフトウェアが適正な手順で開発され,品質も信頼できることをデータで示し,発注者やユーザーが手軽に「見る」ことができれば,解決できるかもしれません.そのために,食品流通等におけるトレーサビリティの概念を,ソフトウェアの開発過程に応用することで,「いつ、どこで、誰が、どのように」開発したものであるかというトレーサビリティ情報を「ソフトウェアタグ」としてソフトウェア製品そのものに添付します.

StagE02

ソフトウェアタグの効果

発注者やユーザは,ソフトウェアタグを確認することで,以下のようなメリットを得ることが可能です.

自分が購入したソフトウェアは,きちんとした手順で作られているのかどうかを知ることができる.
万一,不具合が起こっても,すぐにその原因を調査し,解決できる仕組みが実現されている.
外部に発注したソフトウェアが,きちんとした手順で作られたかどうかを確認できる.
ユーザ・発注者・開発者間で訴訟となっても,自らを守る客観的な証拠を示すことができる.

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

楠本研では,StagEプロジェクトにおいて,ソフトウェアタグに登録する情報の収集に関する研究を行っています.具体的には,ソフトウェア開発過程からソフトウェアタグに登録されるメトリクス情報の自動収集システムの開発,ソフトウェアタグとして利用できる新しいメトリクスの提案を行っています.

システム概要図

StagE03

実プロジェクトから収集したタグデータ例

StagE04

プログラム依存グラフを用いた研究

プログラム依存グラフとは

プログラムの依存関係を表すグラフを,プログラム依存グラフ,あるいはPDG(Program Dependence Graph)と呼ぶ.

依存関係とは,2つの文などの関係を表し,主に以下の2つが用いられる.

制御依存
ある文の実行の有無が,他の文に影響される
データ依存
ある文で使用する変数の値が,他の文で設定される

PDGは,これらの依存関係を辺とし,依存関係の対象となる文などを頂点としたグラフである.

PDG1

上の図は,PDGの一例である. ここでは,制御依存を表す辺を点線で,データ依存を表す辺を実線で表している.
例えば,”y = x + 1;”という文の実行の有無は,”if (y == k)”の評価結果に依存するため, “if (y == k)”から”y = x + 1;”へ制御依存辺が引かれている. 同様に,”y = x + y;”という文で用いる変数xおよびyの値は,”x = 0;”および”y = 0;”という文で設定されているため,それぞれの頂点からデータ依存辺が引かれている.

PDGを用いることで,データの流れなど,プログラムの振る舞いを表現することができる. 以下では,このPDGを用いた研究を紹介する.

プログラム依存グラフを利用したメソッド内構造の改善手法

PDG を用いて,リファクタリングを行う手法について研究している.
リファクタリングとは,外部の振る舞いを変えずにソースコードの内部構造を整理することである.開発や保守で重要であるが,手動では困難なためツールでサポートすることが大切である.
本研究では,PDG からリファクタリングの候補を特定する手法を提案する. 結果をグラフィカルに示すツールも開発しており,リファクタリングの候補を視覚的に確認することが可能である.

PDG2_s

新規開発者のソフトウェア理解を目的としたプログラム依存グラフ可視化手法

他人が書いたソースコードを理解するのは容易ではない.PDG は依存関係や構造の理解を容易にするのに有効だと考えることができる.
本研究では, PDG の可視化手法を提案し, 統合開発環境の一つであるEclipse のプラグインとして実装した. 実装したプラグインは, Java プログラムのメソッドを選択し, そのメソッドに対するPDGを, 構造を理解しやすい配置にして出力することを可能にしている.

PDG3_s

見積り(工数予測)

ソフトウェア開発プロジェクトにおいては、開発費の超過や納期遅れといったプロジェクトの失敗を未然に防ぐため、コストの管理が重要です。
主にソフトウェア開発の世界では、コストとして工数という指標が用いられます。工数とは、開発期間×要員で算出される延べ作業時間を表す数値です。
単位としては、「人時」、「人月」などが用いられ、例えば、1人時では1人で1時間かかることを表し、2人月では2人で1カ月、もしくは1人で2カ月かかることを表します。

工数予測とは

プロジェクトのコストを管理するためには、まずそのプロジェクトに必要な工数を知る必要があります。
工数を予測し、必要な工数を知ることで、開発作業の前に適切なスケジュールが立てられたり、適切な人員配置が可能となったりします。これによりプロジェクトを円滑に進めることができます。
したがって、プロジェクトの成功のためには工数予測の精度が重要であり、これまでにも様々な手法が提案され、研究が行われてきました。

研究内容

ソフトウェア開発プロジェクトは個別性が高いため、あらゆるプロジェクトに対して高い予測精度が期待できる万能な工数予測手法は、現時点では存在しません。
また、単に工数予測といっても、どの手法を用いるかだけでなく、どのメトリクス(プロジェクトの特性を表わす項目。開発規模、使用言語など)を基に予測を行うのか、EbA(近年注目されている工数予測手法の一つ。EstimationMethodsで詳しく説明)の場合「類似」の基準は何なのか、など多くの課題が存在します。ある課題に焦点絞り、我々は研究に取り組んでいます。

EstimationMethods

高い予測精度を期待できない予測プロジェクトの判別

類似性に基づく工数予測手法

工数予測手法の中の一つに、類似性に基づく工数予測手法(Estimation by Analogy、通称EbA)があります。
このEbAでは、複数の過去プロジェクトのデータの中から予測したいプロジェクト(予測プロジェクト)に類似した過去に行われたプロジェクト(過去プロジェクト)を用いて工数予測を行います。

工数予測ツールの開発

工数予測の問題点

近年、予測精度の高さから、過去に実施したプロジェクト(過去プロジェクト)に基づく工数予測手法が注目されています。 EstimationMethodsで紹介したEbAもその一つです。
しかしながら、過去プロジェクトに基づく手法では、予測精度は過去プロジェクトに大きく依存するため、1つの手法だけでどのような過去プロジェクトに対しても高い予測精度を得ることは難しくなります。

ツールの開発方針

前述の問題点に対処するため、我々は予測対象のプロジェクトに対して複数の工数予測手法を同時に適用し、各手法ごとに工数の予測値と期待される精度を表示する工数予測ツールの開発を行っています。
ツールは汎用性を重視し、Ruby on Railsを用いてWebアプリケーションとして実装しています。
また、各ソフトウェア開発組織は独自にアレンジした工数予測手法を利用していることが多いため、その場合でもツールを利用できるよう、使用する工数予測手法はユーザが簡単に追加登録できるよう設計しています。

高い予測精度を期待できない予測プロジェクトの判別

類似性に基づく工数予測手法

工数予測手法の中の一つに、類似性に基づく工数予測手法(Estimation by Analogy、通称EbA)があります。
このEbAでは、複数の過去プロジェクトのデータの中から予測したいプロジェクト(予測プロジェクト)に類似した過去に行われたプロジェクト(過去プロジェクト)を用いて工数予測を行います。

コードクローンに関する研究

コードクローンとは

近年,ソフトウェア工学における研究対象の1つとして,コードクローンが注目を集めています.
コードクローンとは,プログラムのソースコード中に存在する,他のソースコードと同一,あるいは類似したコード片のことで,主にコピーアンドペーストなどによって生成されると考えられています.

CodeClone

コードクローンの影響

一般的にコードクローンはソフトウェアの保守作業量を増大させるおそれがあると考えられています.
これは,コードクローンにバグが見つかり,修正を加えた場合,修正したコード片とコードクローン関係にある他のすべてのコード片に対しても,同様の修正を検討しなけばならないという理由からです.そのため,コードクローンの情報を把握しておくことや,まとめることができるコードクローンを1つに集約することは,非常に有益なことであると考えられています.

この考えのもと,コードクローンの検出や集約に関する研究はこれまでに数多く行われています.
しかし,実際にコードクローンがどの程度ソフトウェアの保守作業量に影響を与えているのかを,定量的に調査した研究はあまり多くありません.また,既存の研究に関して,以下のような点が問題点として挙げられます.

  • メソッド単位やファイル単位で調査を行っており,コードクローンを含むメソッド内やファイル内の修正はすべてコードクローンに関する修正と判断しているため,実際にはコードクローンと関わりのない修正が,コードクローンに関する修正と判定されている可能性があります.
  • 既存研究では,ソースコードに加えられた修正の行数を測定し,調査を行っています.しかし,この調査手法では,1行の変更が10箇所に加えられた場合と,10行の変更が1箇所に加えられた場合の,修正に要する作業量が等しくなります.しかし,ソースコードに修正を加える際の作業量の大部分は,修正すべき箇所の特定など,実際にソースコードに 修正を加える前の段階に要すると考えられます.このため,上記の例の場合,1行の変更が10箇所にある場合の方が,より修正に要する作業量は多いと考えられます.
  • 特定のコードクローン検出ツールのみを用いて調査しているため,別の検出ツールを用いると違う結果が導かれる可能性があります.

修正頻度の計測

我々の研究グループでは,ソースコードに加えられる修正の頻度に注目して,コードクローンが保守作業量に与える影響を調査しています.もしコードクローンが本当に保守作業量を増大させているのであれば,より高い頻度で修正が加えられていると考えられます.
既存の研究の問題点を改善するため,ソースコードに加えられる修正を行単位で調べ,修正箇所数を用いて修正の頻度を計測しています.さらにコードクローン検出ツールによらない結果を得るために,4種類のコードクローン検出ツールを利用して調査を行っています.

いくつかのオープンソースソフトウェアを対象に計測を行ったところ,規模の小さなプロジェクトについてはコードクローンへの修正頻度と,コードクローン以外への修正頻度に有意な差は見られませんでしたが,規模の大きなプロジェクトについては,コードクローンの修正頻度の方が低いという結果が得られました.
これは,一般的にいわれていることと逆の結果が得られたことになります.また,いずれのコードクローン検出ツールを用いても同様の傾向となりました.

上の図は大規模なソフトウェアに対して計測を行った結果を,下の図は中,小規模のソフトウェアに対して複数のツールを用いて計測を行った結果をそれぞれ示しています.

LargeProject

Multiple

今後は,どのようなコードクローンが修正されにくく,どのようなコードクローンが修正されやすいのかなど,より細かい分析を行っていく予定です.