研究グループ
コードクローン研究グループ†
Missions†
- コードクローンの作成と利用がソフトウェア品質に与える影響の解明
- コードクローンの作成と利用における属人性の影響の解明
Projects†
- Projects/CodeClone：ECTECの使い方等の資料
- [[Projects/]]：研究テーマ1（To be updated）
- [[Projects/]]：研究テーマ2（To be updated）
CC班コアタイム†
Members†
- 2016/01/27: 久木田大ゼミ資料
- 日付：資料名
ミーティング議事録†
2016年12月15日†
久木田†
- DONE
- Issue作成者，割り当て者，クローン変更者を紐づけて目視調査を行う
Derby目視確認.pdf- Derbyの修正漏れの例のように修正漏れが起きないように事前に発見する必要がある
- 全く変更がないコードがバグ修正の過程で削除されるのであれば，事前に見つけることができるはず
- strutsでは良い例が見つからなかった（対象としているコンポーネントが悪い？DERBYよりクローンとBugIssueの紐づいている数が少ないからか？）
- TODO
- FindBugsで見つけることができるバグパターンが今見ているBugを見つけることができるのか
- DONE
- TODO
- とりあえず動くものを実装中（DONE : データの保存形式をSQLiteに変更した）
- 同じアプリに含まれるクラス間の類似度を計算しないように実装を変更
- 少数のアプリなどでLSI部分テスト
- 検索部分の仕組み(LSIの結果を見る部分)実装
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- トピック数、評価方法についての考察
2016年12月08日†
久木田†
- DONE
- struts(Component)の目視調査
- struts目視確認.pdf
- メソッド単位のクローンが存在していた
- マージによるクローンの変更が多い
- Derbyと同じくメソッドの呼び出し方法の変更も見ることができた
- クローンが別のところに再利用されているものが見ることができた
- CCTの追跡機能のバグ修正（間違った追跡を行っていた）
- TODO
- Issue作成者，割り当て者，クローン変更者を紐づけて目視調査を行う
- MEMO
- なぜIssueとクローンが紐づいているのか
- クローンとIssueが紐づいたのであれば，どのように修正すれば良いのか，はじめからクローンを作らなければよいのかなどを考えながら目視しないと解決方法を見つけることができない
- DONE
- アプリをビルドしてみた → 確かにソースにない.classが生成された
- 今回の手法は「似ているアプリを検索する段階」と「差分の機能を示す段階」の2段階に分けて考える必要があるのでは？
- 「似ているアプリを検索する段階」
- 「差分の機能を示す段階」
- 特定の2アプリ間（もしくは前の段階で挙げられた各アプリ間）における差分を探す
- クラス間類似度（今までやってきたやつ）がより小さいものを提示すればいい？（メソッド数の少ないクラスの扱いが重要になりそう）
- 実験ではそれぞれの段階を評価する？
- 1段階目について、目視でアプリを確認しておいて、出力を見て考察する？
- 1段階目について、F-Droidにおけるアプリのカテゴリは正解集合として使える？（使うべきではなさそう）
- 2段階目について、目視でアプリの機能を確認しておいて、出力を見て考察する？
- TODO
- とりあえず前回の手法を進める
- 同じアプリに含まれるクラス間の類似度を計算しないように実装を変更
- 少数のアプリなどでLSI部分テスト
- 検索部分の仕組み(LSIの結果を見る部分)実装
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- トピック数、評価方法についての考察
2016年11月29日†
久木田†
- DONE
- どのクローンを見るのか観点を決める（変更ありとなし，一人の開発者と複数の開発者，Issueありとなし）
- クローンの作成・変更がなぜ起きたのかを理解するために
- コメント，コード，Issue Reportを見る
- 特定のモジュールでどんなソースコードがクローンとして作成されているのかを見る
- クローンに紐づいているIssueはどんなIssueなのかIssue Reportを見る
- コードクローン内の処理自体の変更は確認できず，メソッドの呼び出し方法や型キャストの方法の変更が多く，他のコード（メソッド）などの変更に伴うものが多い
- TODO
- DONE
- enum型は内部では特殊なクラスとして表現されているらしい（別の.classファイルとして生成される）
- 単語数が極端に少ない文書の扱いについて（除去していいのか？）
- 内部クラスが含む標準API呼び出しの数を調べてみた
- 内部クラス（$マーク付きクラス）
(161個, 平均値=3.987578)
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 6, 6, 6, 6, 7, 7, 7, 8, 8, 8, 8, 9, 10, 14, 16, 16, 22, 28, 30, 37, 37, 41, 104]
- 普通のクラス
(55個, 平均値=28.527273)
[0, 0, 1, 1, 1, 1, 1, 2, 3, 4, 4, 4, 5, 5, 5, 6, 6, 8, 8, 9, 10, 11, 12, 14, 16, 16, 19, 22, 23, 25, 27, 27, 27, 28, 29, 31, 32, 37, 38, 38, 40, 42, 42, 57, 57, 58, 61, 70, 74, 79, 79, 79, 82, 90, 103]
- Android Studioでビルドできずに困っている
- TODO
- 引き続き2つのアプリに含まれるクラスをソースなどと比較して確認する
- アプリをビルドしたときに生成されるファイル（APK化前のファイル群）を確認する
- 少数のアプリなどでLSI部分テスト
- 検索部分の仕組み(LSIの結果を見る部分)実装
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- トピック数、評価方法についての考察
- MEMO
2016年11月24日†
久木田†
- DONE
- １つのクローンの追跡調査
- 作成されてから削除されるまで一度も変更がないものがいくつかある
- 削除されたクローンは長い間変更されていないものが多い
- 一人の開発者のみが変更に関わっているクローンは比較的短い期間での変更が多い
- クローンの作成・変更によってIssueが埋め込まれ，クローンの変更・削除によってIssueがFixされているものがあまり見られなかった
- TODO
- どのクローンを見るのか観点を決める（変更ありとなし，一人の開発者と複数の開発者，Issueありとなし）
- クローンの作成・変更がなぜ起きたのかを理解するために
- コメント，コード，Issue Reportを見る
- 特定のモジュールでどんなソースコードがクローンとして作成されているのかを見る
- クローンに紐づいているIssueはどんなIssueなのかIssue Reportを見る
- DONE
- 2つのアプリに含まれる全クラス同士の組み合わせのうち類似度の大きいものを順に出力。上位をソースなどと比較して確認した
- クラスがネストされていることがある（$マーク）
- たった1つ（ごく少数）の標準APIしか呼んでいないクラスが含まれている？
- TODO
- 引き続き2つのアプリに含まれるクラスをソースなどと比較して確認する
- アプリをビルドしたときに生成されるファイル（APK化前のファイル群）を確認する
- 少数のアプリなどでLSI部分テスト
- 検索部分の仕組み(LSIの結果を見る部分)実装
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- トピック数、評価方法についての考察
2016年11月16日†
久木田†
- DONE
- モジュール（クローンを含む）毎に分けて追跡，バグがあるものとないものの比較(derbyのjava/engine/org/apache/derby/impl/storeを調査)
- issueがどこで，だれによって埋め込まれたか
- TODO
- １つのクローンの追跡調査
- pajekでクローンと開発者のグラフで，クローンの変更回数とクローンノードの大きさを比例させる
- MEMO
- １つのクローンにおいて，だれが作成・変更し，いつだれがBugを埋め込み，修正していったのかを見ることによって，
- 複数人が1か月に変更が行われていれば，共同のownerであるかもしれない
- DONE
- TODO
- 2つのアプリに含まれる全クラス同士の組み合わせのうち類似度の大きいものを順に出力。上位をソースなどと比較して確認する
- 少数のアプリなどでLSI部分テスト
- 検索部分の仕組み(LSIの結果を見る部分)実装
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- トピック数、評価方法についての考察
2016年11月10日†
久木田†
- DONE
- プロジェクトのissue混入率ランキング
- クローンの増減に関わった開発者の調査
- TODO
- issueがどこで，だれによって埋め込まれたか
- モジュール（クローンを含む）毎に分けて追跡，バグがあるものとないものの比較(derbyのjava/engineを調査)
- MEMO
- クローンに関係のあるIssue数／全Issue数
- Issueの分類
- IssueでBugだったものと紐づいたクローンはあるのか
derbyとstrutsをまず見る
- DONE
- 研究発表会
- コードがカオスだったので少しだけリファクタリング？
- TODO
- 少数のアプリなどでLSI部分テスト
- 検索部分の仕組み(LSIの結果を見る部分)実装
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- トピック数、評価方法についての考察
2016年11月04日†
久木田†
- DONE
- LOCとクローンLOCの時系列データのスムージング
- バグ有・無クローンの比較（検定）
- TODO
- クローンの増減に関わった開発者の調査
- issueがどこで，だれによって埋め込まれたか
- モジュール（クローンを含む）毎に分けて追跡，バグがあるものとないものの比較
- プロジェクトのissue混入率ランキング
- MEMO
- 古くから存在するクローンにissueが埋め込まれた場合，作成者と埋め込んだ人が違う開発者であれば，管理者が変わったことで発生した事象かも
- バグが埋め込まれたクローンは誰が作成者・利用者・管理者か
- DONE
- 前回実装完了部分を改良
- 検索部分の仕組みを思いついた
- TODO
- 検索部分の仕組み(LSIの結果を見る部分)実装中
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- トピック数、評価方法についての考察
2016年10月27日†
久木田†
- DONE
- 修論目次案
- LOCとクローンLOCの時系列データ作成
- TODO
- 修論目次修正
- バグ有・無クローンの比較（検定）
- プロジェクトごとの運用の違いは？
- DONE
- StigmataCSV→コーパス変換部分実装完了
- tfidf、LSI部分実装完了
- アプリ収集用スクレイパー実装完了
- TODO
- LSIの結果を見る部分実装
- 読み込ませるアプリやクラス、メソッドの種類、数についての考察
- なぜLSIなのか
2016年10月20日†
久木田†
- DONE
- TODO
- 修論目次
- バグ有・無クローンの比較（検定）
- 共同作業を多くしている開発者グループの抽出
- 分析・ケーススタディ・RQの設定
- MEMO
- コードクローンを安全に管理するはGoalにならない
- プロセスを見るとは
- バグでなくIssueで
- ユニーククローン数（累積クローン数）とは
- クローン含有率＝クローン行数/全体コード行数（今日中）
- プロジェクトごとにリビジョン系列でクローン含有率計算してグラフを書く
- DONE
- ガントチャートらしきものを作成
- 目次らしきものを作成
- StigmataCSV取得部分実装
- TODO
2016年10月13日†
久木田†
- DONE
- TODO
- 大ゼミ質疑回答（今日中）
- 分析・ケーススタディ・RQの設定
- DONE
- 簡易版ガントチャート作成
- 2016/10/
- Python、Gensim理解（13,14,15）
- コーパス作成部分実装（13,14,15）
- LSI部分実装（15,16,17）
- アプリ収集（17,18）
- PythonやGensimの理解を進めている
- TODO
2016年10月6日†
久木田†
2016年9月29日†
久木田†
- DONE
- 関西支部大会発表
- コードクローンの作成・利用過程の分析が必要な理由についてのスライド
- Research Questions のスライド
- Apache Strutsのクローン変更回数と変更間隔の集計（バグありとバグなしの比較）
- TODO
- DONE
- やはりStigmataを使う方針に決めた
- 実際のアプリにStigmataを適用して、出力をソースコードと比較した
- smcモードは、各「クラス」の中に書かれているAPI呼び出しの順列を取るだけだった（メソッド単位ではなかった）
- クラス単位ではAPI呼び出しの「順列」に意味はないと考えられる
- オープンラボ用ポスターの作成にあたってざっくりと手順を書いた
- TODO
2016年9月9日†
久木田†
- DONE
- データリストで未完了の解析を行う（28プロジェクト完了）
- Birdのmissing linksの論文を読む
- 分析方法・結果のスライド作成
- TODO
- 共同ファイル変更数の調査
- 共同変更を多く行っている開発者が関わっているクローンの中身を見る
- MEMO
- クローンサイズの分布をみることで大きなクローン，小さなクローンを定義する
- インデントなどのバグに直接影響を与えることがないものは省きたい
- Pajekのデータを使ってクローンまたはバグを介してつながりが太い開発者を見つけ出す
- Birdの論文からサブグループとは何かを読む
- DONE
- 玉田先生にStigmataについてメールで質問した
- 今回はStigmataを使わない方針に決めた（ソースコードを解析する）
- 既存の手法を意識して考えることにした
- 機能抽出過程
- 標準API呼び出しの順列は機能を表すはず
- メソッドごとに標準API呼び出し順列を取得
- tf-idf的フィルタリング？
- BoW化？
- いい感じにゆるめな手法を探している...
- ラベル付け過程
- エンドユーザーにもわかる抽象度の機能名は、クラス名やメソッド名にも表れているはず
- 識別子名に対する自然言語処理（tf-idf的フィルタリング？）
- TODO
- 実際の簡単なアプリの標準API呼び出し順列を確認、比較する
2016年8月31日†
久木田†
- DONE
- データリストで未完了の解析を行う
- スライドの分析の内容の枠組みを考える
- TODO
- データリストで未完了の解析を行う（残り19プロジェクト）
- Birdのmissing linksの論文を読む
- 分析方法・結果のスライド作成
2016年8月26日†
久木田†
- DONE
- 現状集まっているデータと集めているデータ（リポジトリとバグと解析完了か否か）
- ファイルとクローンで違いがあるかどうか（ファイルバージョンのPajekデータ作成）
- TODO
- データリストで未完了の解析を行う
- Birdのmissing linksの論文を読む
- スライドの分析の内容の枠組みを考える
- DONE
- 全体MTGのスライド→研究発表_0.pdf
- Chen et al.の手法はCVSの各リビジョンのdiff結果とコミットメッセージを紐付ける。アプリ検索には重い？
- Marcus et al.の手法はソースコード内の識別子名やコメントを基にLSI（潜在意味解析）を行う。
- TODO
2016年8月10日†
久木田†
- DONE
- 複数プロジェクトのPajekデータ作成
- Pajekのデータからクローン同士，バグ同士の2モードネットワーク構築
- 媒介中心性の高いバグ票の目視(Ant,Struts)
- TODO
- 現状集まっているデータと集めているデータ（リポジトリとバグと解析完了か否か）
- ファイルとクローンで違いがあるかどうか
- Birdのmissing linksの論文を読む
- MEMO
- 3年寝太郎：クローンの平均変更期間を出して
- クローンのミッシングリンクをネットワーク分析で繋げれそう
- DONE
- 研究の背景、動機の、自分なりに納得のいく説明ができた
- TODO
2016年8月4日†
久木田†
- DONE
- SZZデータの利用方法変更
- Pajekデータ作成：（人(fixした人) - バグID - クローンID）
- 関西支部大会原稿作成
- TODO
- 複数プロジェクトのPajekデータ作成
- Pajekのデータからクローン同士，バグ同士の2モードネットワーク構築
- ファイルとクローンで違いがあるか
- MEMO
- Birdの研究との違いをどうするか
- CCの管理においてよくないこととは？
- CCの問題？
- バグの内容の問題？（媒介中心性が高いやつ？）
- 人の問題？
- DONE
- word2vecをインストールした
- webで見つけたサンプル的なものを動かしてみた
- TODO
- word2vecの詳しい使い方を調べて実践
- サーベイ論文を途中までしか読んでないので続きを読む
- 今後の方針？
- stigmataで取得できるクラス名、メソッド名をword2vecしてみて、どんな類似語が出るか確かめる？
- ひとまずの機能の定義
- 機能はメソッドの集合で構成される
- それを一定のルールでまとめたものがクラスであり、機能と関連する
2016年7月28日†
久木田†
- DONE
- FOSEに向けたデータ作成
- SZZ出力確認
- Pajekデータ作成：5プロジェクト分
- クローンサイズ：行数＋ブロック（トークン数）
- TODO
- SZZデータの利用方法変更
- Pajekデータ作成：（人(fixした人) - バグID - クローンID）
- 関西支部大会原稿作成
- DONE
- word2vecの論文を読んだ
- 実験の方法をいろいろ考えてメモしていた
- さらに読むべき論文を昨日教えてもらった
- TODO
2016年7月21日†
久木田†
- DONE
- TODO
- FOSEに向けたデータ作成
- SZZ出力確認
- Pajekデータ作成：5プロジェクト分
- クローンサイズ：行数＋ブロック（トークン数）
- DONE
- 論文を読んだ
- Stigmataの出力の意味など詳しい使い方を調べたが、わからなかった
- Stigmata以外の指標も考えてみたが、するならまずはStigmataからしてみよう
- birthmarkそのままだと量が多いので、無駄なものを減らす工夫が必要
- TODO
- 玉田先生に聞く？
- Stigmataの機能、出力、各birthmarkの意味
- word2vecも見てみる
2016年6月30日†
久木田†
- DONE
- プロジェクトのデータ取得(残りはeclipseとant)
- コードクローン集計プログラム作成
- TODO
- DONE
- TODO
- 具体的な実験方法を考える
- 論文読む
- 簡単なAndroidアプリを作ってみる
2016年6月23日†
久木田†
- DONE
- クローンの類似性を用いて追跡できていないクローンを減らす
- プロジェクトのデータ取得（Spring Framework）
- GitHub API を使ったIssue取得プログラム
- TODO
- DONE
- Stigmataで実際のアプリを解析してみた
- Stigmataの出力を整形してソートしてみた（が、現時点では意味不明）
- TODO
2016年6月16日†
久木田†
- DONE
- Ant分析のテーブルを埋める
- SIGSE投稿
- 削除されたコードクローンの確認
- TODO
- プロジェクトのデータ取得
- クローンの類似性を用いて追跡できていないクローンを減らす
- DONE
- Stigmataの使い方を理解した
- 前田さんから読むべき論文をもらった
- TODO
- Stigmataで実際のアプリを解析してみる
- 論文を読む
2016年6月9日†
久木田†
- DONE
- 論文を1つ読んだ
- データベース演習をがんばった
- 輪講資料を作った
- 考えた
- 検索するには、各アプリが使用しているクラスを見て機能を取得し、その機能ごとに重みを付けておく必要がある
- ---- 機能の取り出し方はどうする？
- ---- 機能を自動で取得するには？
- -------- 機械学習する？
- ------------ 何を正解にする？
- -------- ラベルを参考にする？
- ---- 最適な重みは機械学習する？
- TODO
- さらに論文を読む
- 研究の進め方を確定させて、それに伴う何かをする
2016年5月30日†
久木田†
2016年5月26日†
久木田†
- DONE
- クローンセットがどのように追跡できなくなったかの目視確認
- jEditに対してECTECとCCTをかける
- TODO
- jEditのECTECバージョンとCCTバージョンの比較
- 追跡ツール試作の章を書く
2016年5月19日†
久木田†
- DONE
- SZZ(verGitHub)の実装
- 取得したプロジェクトに対してSZZの適用
- TODO
- クローン追跡がどの程度できているかの調査
- 対象外にすべきディレクトリの特定
- TODO
- いただいた本を読み進めライセンスがどういうものなのか理解していく
2016年5月12日†
久木田†
- DONE
- いろんなプロジェクトに対してCCTをかける(JUnit,struts,jabref,Ant)
- 取得したデータの確認
- TODO
- SZZ(verGitHub)の実装
- 取得したプロジェクトに対してSZZの適用
2016年4月28日†
久木田†
- DONE
- TODO
- いろんなプロジェクトに対してCCTをかける（現状あるのはstruts）
- 取得したデータの確認
- DONE
- リファクタリングに関することも考えることにしてみた
- TODO
- 一貫性のある変更とは？を考える
- 最低限読むべき論文がたくさんあるので読む
2016年4月21日†
- TODO
- ソフトウェアエンジニアリング基礎知識体系を読んで勉強する
久木田†
- DONE
- nokogiri動作確認(特にマージコミット部分)
- nokogiriバグ修正
- スライド（ツール説明）
2016年4月14日†
久木田†
- TODO
- nokogiri動作確認(特にマージコミット部分)
- 大ゼミ資料作りはじめ
2016年4月8日†
- DONE
- ついさっきDB.getParentsCommitInfo()を実装
- 全体MTGの輪講とデータベース演習を頑張ってました
- TODO
久木田†
2016年4月1日†
上西・松浦†
- DONE
- Nokogiri担当分（CommitInfoExtractor）完成
- TODO
松尾大典†
- DONE
- CodeFragmentDetector, CloneDetectorの移行
久木田†
- DONE
- コード片特定，クローン特定
- コードクローンの追跡（まだバグあり）
- TODO
- 実装：マージ発生時のコード片，コードクローンの処理
2016年3月24日†
松尾大典†
- DONE
- コード片変更箇所の特定フロー（進捗５割？）
- DiffやDB接続は他から拝借するので独自部分は後はほぼ無い
- DIffのとり方の変更に対応
- TODO
- DB接続、確認クエリ、格納クエリ
- 動作確認
- コーディング規約を周りに合わせる
久木田†
- DONE
- TODO
- 実装：マージ発生時のコード片，コードクローンの処理
- Diffに含まれるファイルからコード片抽出
- DBに格納されている前のリビジョンでのコード片と比較
- 一致するコード片があればコードクローンとして追跡する
- クローンのマージ
- クローン情報のデータベースへの格納
- 動作確認
- DONE
- フローの1, 2番目まで
- コミットIDの取得
- 任意のコミットIDのスナップショット中に存在するファイルリストの取得
- コード片特定に必要なライブラリの移動
- TODO
- MEMO
上西・松浦†
2016年3月17日†
久木田†
- DONE
- 実装：マージ発生時のコード片，コードクローンの処理
- Diff取得（ファイル，行数，属性）
- Diff比較
- クローンのデータベース設計
- TODO
- 実装：マージ発生時のコード片，コードクローンの処理
- Diffに含まれるクローンの比較
- クローンのマージ
- データベース設計・実装
上西・松浦†
- DONE
- 既存コードを読んだ
- 火曜に久木田さんと簡易MTGでDBを決定
- TODO
- 担当フロー部分の実装（久木田さん作のDiffを流用）
- MEMO
2016年3月11日†
久木田†
- DONE
- 動作手順フローチャート作成
- マージ発生時のコード片，コードクローンの処理（久木田）
- TODO
- DONE
- TODO
- MEMO
- フローチャート
- あるリビジョンのすべてのファイルをスキャンし，コード片とコードクローンを特定し，データベースに挿入
- できたら，確認してもらった後，実装開始．
上西・松浦†
2016年3月3日†
CC班コアタイム†
13:30〜16:30
久木田†
- DONE
- TODO
- 動作手順フローチャート作成
- リビジョン情報・関係を取り出す（松浦・上西）
- コードクローンの特定（最初のリビジョンのスキャン）（片桐）
- コードクローン変更箇所（コミット）の特定（大典）
- マージ発生時のコード片，コードクローンの処理（久木田）
- データベースの再設計（一人ではできないので手伝ってほしいです）
2016年2月26日†
久木田†
- DONE
- この設計のままでは，計算量が膨大になり，クローンを追跡できないことが判明
- TODO
- TODO
- FileDetector作成中です
- JGitの実装でモタついてます･･･。
- DONE
- 久木田さんにCommitDetector作成を依頼→完成
- TODO
2016年2月17日†
久木田†
2016年2月10日†
- TODO
- ひとつのバグに対して同時修正を必要としたクローンを含むファイルの割合はどうか
久木田†
2016年2月5日†
久木田†
- DONE
- ECTEC(ver.kukita)作成
- 大ゼミ回答提出
2016年1月29日†
- DONE
- コードクローン班用wikiページ作成
- 研究テーマ２件のラフ設定
- コードクローン作成パターンの時系列分析（プロジェクト開始から現在までのクローン作成の特徴を開発者別に時系列分析しパターン化する）
- コードクローンの作成／利用における人間関係の分析（第三者のコードクローンを利用する際の人間関係とコード品質との関係を分析する）
- TODO
- 疑問を解消する（サーベイ？）：研究する意味あるのかを再度確認するため．
- 不具合修正に占めるコードクローンの修正割合は？ (modified clones/modified bugs)
- 不具合修正とは無関係な変更に占めるクローンの変更割合は？(modified clones/changes)
久木田†
- DONE
- ECTEC(ver.kukita)のデータベース設計
- 大ゼミ発表
- TODO
- ECTEC(ver.kukita)作成
- 大ゼミ回答提出
- コードクローンの作成理由の調査
- DONE
- TODO
- 来週のMTGに参加
- エントリーシート作成
- 大家さんに会いに行く
- ResearchQuestions
- 開発者によってコードの再利用を行いやすい・されやすい傾向があるか
- プロジェクトに長く携わることで再利用傾向に変化があるか
- 他者の書いたコードを再利用することは不具合の混入に起因するか
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
