軽微な不具合、重大な不具合
大規模化、複雑化している近年のソフトウェア開発では非常に多くの不具合が報告されています。そのためタイプミスなどの「軽微な不具合」からセキュリティに関する「優先度の高い不具合」までが同等に扱われてしまうことが問題になっています。
これに対して、個々の不具合が与える影響を考慮した分類・分析の研究が行われており、ユーザーや開発者に大きな影響を与える6種類の不具合はHigh Impact Bugと呼ばれています。
続きを読む
「研究内容」カテゴリーアーカイブ
ユースケースの多面的評価に基づいたソフトウェア部品開発の費用対効果の計測支援
ソフトウェア開発と見積もり
ソフトウェア開発において、ソフトウェアを発注する顧客側は要望が叶えられることを期待し、開発者側は予算の範囲内で顧客が満足するソフトウェアを実現することを望みます。
そのためソフトウェアの開発過程では、開発者側が顧客側の要望を分析し、要望の実現に必要なコストの割り当てを行います。これは見積もりと呼ばれ、正しくコストを分析し、予算から実現可能な実装の範囲を決定することが求められます。
続きを読む
OSSライセンス特定ツールにおけるライセンスルール自動生成手法の構築
OSSの再利用とライセンス
近年の大規模なソフトウェア開発では，開発コスト削減のために，OSSを再利用することが一般的になりつつあります． OSSは，ソースファイルに記述されているOSSライセンスを遵守することで，ソフトウェアの一部として再利用することができます．
現在，69種類のOSSライセンスがOpen Source Initiative (OSI)に承認されています．OSSライセンスを遵守するには，まず，各ソースファイルのライセンス記述を読み，どのOSSライセンスに該当するかを特定する必要があります．
OSS開発におけるHigh Impact Bugを考慮した不具合修正時間予測
OSSプロジェクトと不具合報告
近年のソフトウェア開発ではオープンソースソフトウェア（OSS）が幅広く利用されています。ユーザが増えて大規模化したOSSプロジェクトには、日々多くの不具合が報告されています。
報告される不具合の数は日々増え続けている（OSSプロジェクトのApache Ambariの例）
しかし、報告される不具合の数は非常に膨大なため、すべての不具合を次のバージョンリリースまでに修正することは困難です。プロジェクト管理者は次のバージョンリリースまでにどの不具合を優先的に修正すべきかという意思決定を行う必要が出てきました。
その意思決定の指標として、個々の不具合の修正にかかる時間を見積もることが重要です。このような背景から、近年OSS開発における不具合修正時間を予測する研究が盛んに行われています。
モジュールの適性を考慮したコミッター予測
大規模OSS開発において，日々大量の不具合が報告されています．多くの不具合は，投稿された修正パッチファイルをコミッターが検証することによって修正されます．コミッターとは，コードを直接変更する権限を持つ特別な開発者のことで，コミット権限を持たない開発者に比べ，コミッターは少人数で構成されています． 続きを読む
リポジトリマイニング手法の習得支援
ソフトウェアリポジトリマイニング(MSR)技術は，ソフトウェア開発の生産性や品質を改善するための有力な手段の1つです．しかしながら，MSR技術の知識やスキルがない学生にとっては，様々なリポジトリや手法を扱うまでに多くの学習コストが必要となるため，実際のプロジェクトを対象としてMSR技術を適用する事は容易ではありません．そこで，ソフトウェア工学分野における教育的観点から，学生のMSR技術の習得支援を目的としたシミュレーション環境の構築を目指しています．
OSSコミュニティとシステムの共進化を分析するためのデータマイニング手法の構築
近年，システム開発の低価格化・短納期化に対応するために，Linuxをはじめとするオープンソースソフトウェアを活用したシステム開発が一般的になりつつあります．しかし一方で，OSSはボランティアの開発者によって開発が進められているため，「利用しているOSS がいつまで存続するか分からない」という理由からOSSを活用したシステム開発を躊躇するベンダー企業も少なくありません． 続きを読む
バグトリアージ手法の構築
近年の大規模システム開発では，試験工程のみならず運用工程においても多数の不具合が検出されるため，不具合管理システムを用いて，検出された不具合の再現方法や修正方法を詳細に記録し，漏れのないように不具合を管理することが求められる．不具合管理システムに報告された不具合一つ一つに対して，重要度や優先度を設定し，適任の担当者に修正タスクを割当てることをバグトリアージと呼ぶ． 続きを読む
保守対応効率化のためのアウェアネス支援システム
研究背景：
ミッションクリティカルなシステムで利用されているオープンソースソフトウェア(OSS) の不具合は，開発者によって迅速に修正されることが望まれる．しかし，多くの開発者を抱えるOSS プロジェクトでは，言語や文化，習慣などが異なる世界中の不特定多数のボランティア集団によって開発を進められているため，管理者が保守作業の適任者を特定することが容易ではなく，不具合が修正されるまでの時間が長くなってしまう問題がある．
ACTION：
本研究で作成したACTION(Awareness Communication Tool for Interactive Open Negotiation)は，(a)保守対象のソースコードの開発に関与した経験のある開発者，(b)開発者の活動地域と開発者の活動時間，を直観的に把握できるよう支援することができる．システムの有用性を検証するために比較実験をおこなった結果，ACTION を利用することで，開発者の活動時間に沿ったコミュニケーションが可能になることを確認した．また，従来システムと比較してACTION はOSS 開発者のコミュニケーションを効率化できることを確かめた．
アクションの全体図
- Folder/File View
ツリー構造化されたフォルダ・ファイルの一覧を示す．ファイルをクリックすることで，イベントが起こり，ファイルを検索キーとしたクエリがデータベースに送られる．
- Module History View
ファイルの変更を行った開発者，変更時刻をグラフに示す．横軸はタイムゾーン，縦軸は日付で，1プロットは開発者1名に該当する．
- Active Time View
開発者のメール送信数を用いて，活動頻度を表すヒストグラムを表す．横軸は時刻，縦軸はメールの送信数である．
- Commit History View
開発者の開発履歴をリスト化して示す。
コミュニティ媒介性
研究の背景：
一般に，LinuxやApacheをはじめとするOpen Source Software（OSS）開発コミュニティには，情報共有や作業の効率化を図るために，参加者の役割（開発者，バグ報告者，ユーザなど）に応じたいくつかのサブコミュニティが存在しています．参加者が地理的に分散している環境下において高機能かつ高品質なOSSを持続的に開発するためには，それぞれのサブコミュニティで行われる活動の結果として得られる成果物（ソースコード，バグ報告，ユーザフィードバックなど）を有機的に機能させOSSに反映していくことが重要になります．そのため， OSSコミュニティ参加者の内，コアメンバはいくつかのサブコミュニティに参加しコミュニティ全体の秩序の形成や組織化に貢献し，サブコミュニティ間の協調作業を円滑化する役割を担っています．
我々が行った分析から，複数のサブコミュニティを媒介するコアメンバのコミュニケーション構造（図1）は，成功コミュニティと衰退コミュニティとでは大きく異なることが分かりました（図2）． また，異なるサブコミュニティの参加者をコアメンバが媒介する度合いを評価する指標として，従来の媒介中心性は適切ではないことも明らかにしました．
|
|
従来指標の問題点：
複数のサブコミュニティが存在するOSSコミュニティにおいて，コアメンバの媒介度合いを評価するための従来指標である媒介中心性は以下のような問題があることがわかりました．
（1）コミュニティ内／間の媒介を区別しない．
（2）情報伝達の向きを区別しない．
特に本研究では，サブコミュニティ間にまたがる情報伝達におけるコアメンバの媒介度合いの評価を対象としているため，従来の媒介中心性では，コミュニティ内の媒介への偏りが顕著なノード（たとえば図2の Netscape のコアメンバ）であっても，サブコミュニティ間を媒介するコアメンバとして高く評価される場合があり，媒介中心性は本研究の目的とは合致しない指標でした．
コミュニティの媒介性：
従来指標の問題点を解決することを目的として，本研究ではサブコミュニティ間の協調作業を円滑化するコアメンバの媒介度合いを定量的に評価するための指標，コミュニティ媒介性を提案しています．
コミュニティ媒介性は，サブコミュニティXからサブコミュニティYを媒介する度合いとサブコミュニティYからサブコミュニティXを媒介する度合いの調和平均に基づいて，コアメンバがサブコミュニティ間を相互に媒介する度合いを評価する指標です．また，コミュニティ媒介性は，OSSコミュニティにおけるコアメンバの媒介のパターンを想定した3つの指標からなります(図3)．
|
|
