吉富 にそのファイルは見つかりません

吉富

Memo†

論文†

Title	Author	Conference	Presentation	Star
A systematic mapping study on technical debt and its management			JSS15.pdf	☆☆☆
Identification and management of technical debt: A systematic mapping study			20190808_004.pdf	☆☆☆
Supporting Analysis of Technical Debt Causes and Effects with Cross-Company Probabilistic Cause-Effect Diagrams		MSR’19	Supporting Analysis of Technical Debt Causes and Effects with Cross-Company Probabilistic Cause-Effect Diagrams.pdf
The most common causes and effects of technical debt: first results from a global family of industrial surveys		ESEM '18	The Most Common Causes and Effects of Technical Debt.pdf
Technical Debt Triage in Backlog Management		MSR’19	Technical Debt Triage in Backlog Management.pdf
How Do Developers Fix Issues and Pay Back Technical Debt in the Apache Ecosystem?		SANER'18	How Do Developers Fix Issues and Pay Back Technical Debt in the Apache Ecosystem?.pdf
The Pricey Bill of Technical Debt		ICSME'17	The Pricey Bill of Technical Debt.pdf
On the Diffuseness of Code Technical Debt in Java Projects of the Apache Ecosystem		MSR'19	On the Diffuseness of Code Technical Debt in Java Projects of the Apache Ecosystem.pdf
The Delta Maintainability Model: Measuring Maintainability of Fine-Grained Code Changes		TD'19	[添付]	☆☆
			[添付]
A Practical Model for Measuring Maintainability		QUATIC 2007	A Practical Model for Measuring Maintainability.pdf
The quamoco product quality modelling and assessment approach		ICSE '12	The Quamoco Product Quality Modelling and Assessment Approach_0.pdf
			[添付]
Establishing a Framework for Managing Interest in Technical Debt			[添付]
A framework for managing interest in technical debt: an industrial validation		ICTD'18	[添付]
Estimating the Breaking Point for Technical Debt			[添付]
			[添付]
			[添付]
The Technical Debt Dataset		PROMISE'19	Technical debt dataset.pdf
			[添付]
Maintenance Effort Estimation for Open Source Software: A Systematic Literature Review		ICSME'17	[添付]
Estimating development effort in Free/Open source software projects by mining software repositories: a case study of OpenStack		MSR'14	[添付]
Empirical validation of human factors in predicting issue lead time in open source projects		PROMISE '11	[添付]

Schedule†

Goal†

研究のイメージ†

• まず，多重債務のようなTDは存在するのか
  • データセットを時系列に並べることによって，変化を分析する
  • プロジェクトが進むと，LOCも増加していくため，検定を用いて(例えば1000行統一など)TDが増加しているのかを分析する
• FindBugsを用いて動的に解析，WARNINGの増加数からTDの増え方を分析していく
• 現地点での研究のイメージ
  • まず，OSSでの工数見積もりモデルを作成する．
  • COCOMOやFP法は企業プロジェクトのように技術者の入れ替わりが激しくないことが前提にあるため，頻繁に入れ替わりが起こるOSSプロジェクトではそのまま適用することができない
  • TDコストを見積もるモデルを作成する．

本研究によって解決される問題†

• 多重債務システムの優先順位付けに向けた工数見積もり

興味あり用件・議論案件†

• 時間的順序関係を考慮したTDの分析(遅延相関分析を絡めて)
• 人による多重債務とTDによる多重債務のメタファの区別
  • (経済学)
    • 債務：ある当事者(債務者または借り手)が別の当事者(債権者または貸し手)に負う金額
    • 元金：借りた元の金額
    • 利息：返済された追加金額．
    • 金利：借りたお金に対する利息の割合．(%で表される)
  • (ソフトウェア工学)
    • 債務：納期に間に合わせるなどの理由によりコーディング中に行われる技術的な妥協
    • 元金：ソフトウェアシステムで現在の品質と設計時の最適な品質の差に対処するために必要な工数
    • 利息：設計時の品質が減衰してしまうため，ソフトウェアの保守に費やす必要のある追加分の工数
    • 金利：保守に費やす必要のある追加分の工数の比率
    • 利息確率：特定の種類の技術的負債が実際に目に見える結果をもたらす確率(EX.リファクタリングを必要とするコードを修正する必要がある可能性)
    • 利息額：技術的負債を含むシステムの一部のメンテナンスを実行するための追加コスト(EX.リファクタリングを必要とするコンポーネントを変更するために必要な追加コスト)

• 利息について
  • 通常は年率，すなわち金利で，元金の割合として計算される．利息には，元金の金額に対して全ての期間で計算される場合，単純利息と呼ばれる．利息の合計量は直線的に増加する．一方，元金に累計利息を加えた場合，複合利息と呼ばれる．したがって，利息の総量は指数関数的に増加する．契約を達成するために，借り手はローンのタイプを指定し，債権者に満期日で返済することを義務付ける債務証券を発行する．

• TDではお金を貸している人と借りている人が誰なのか？また，貸す・借りるとは何なのか？
• 経済学をマスターする
• SRGMマスターする
• 借金の返済はどんなモデルでどんなふうに計算されているのか

TDミーティング†

• 毎週水曜16:30〜

研究会参加†

• テンプレ
• 研究会名：
  • 開催日程：???年??月??日(?)〜??月??日(?)
  • 開催場所：
  • 内容
    • 〆切: ??年??月??日
    • 提出原稿(PDF) : [添付]

研究会参加目標†

• 研究会名：
  • 開催日程：???年??月??日(?)〜??月??日(?)
  • 開催場所：

過去録†

• 吉富/B4

メモ†

HYOHYOの備忘録†

JDKのお掃除方法†

• 古いJDK が存在しているのか調べるコマンド
  • /usr/libexec/java_home -V
• アンインストールするコマンド
  • sudo rm -rf /Library/Java/JavaVirtualMachines/jdkホゲホゲ.jdk
  • 必要な分だけこのコマンドを繰り返す

特定のプロジェクトの特定の期間のハッシュ値を拾ってくる†

• プロジェクトのリポジトリまで移動
• gitコマンド
  • git --no-pager log --since=2017-03-30 --until=2019-11-14 --pretty=format:\%H\ --date=short --no-merges --all --date-order > commits.txt
• コミット日(正確にはauthor日)も一緒に拾ってきたい場合は以下の通り．
  • git --no-pager log --since=2017-03-30 --until=2019-11-19 --pretty=format:'%H [%cd]' --date=format:'%Y/%m/%d %H:%M:%S' --no-merges --all --date-order > commits20170330-_date.txt

セルの文字列を分割する方法†

• 半角のスペースで区切られている場合
  • =LEFT(A1,FIND(" ",A1)-1) : 半角スペースが登場するまで文字列を取り出す
  • =MID(A1,FIND(" ",A1)+1,LEN(A1)) : 半角スペースの次の位置から取り出している
• 全角のスペースで区切られている場合
  • =LEFT(A1,FIND("　",A1)-1)
  • =MID(A1,FIND("　",A1)+1,LEN(A1))
• 半角スペースと全角スペースが混在して区切られている場合
  • =LEFT(A1,FIND(" ",SUBSTITUTE(A1,"　"," "))-1)
  • =MID(A1,FIND(" ",SUBSTITUTE(A1,"　"," "))+1,LEN(A1))

2つのcommit間の差分をファイルを指定して出力†

• ファイル名一覧取得
  • git diff --name-only <コミットID1> <コミットID2>
• ファイル名を指定して差分出力
  • git diff <コミットID1> <コミットID2> <ファイル名>
• git diff --stat v1 v2
  • v1 と v2 のスナップショット間で差分を取って変更行数を集計したいとき
• git log --numstat v1..v2
  • v1 から v2 までの各コミットの修正行数を集計したいとき

gitstatsを用いてLOCの推移を可視化(グラフ化)する†

• (お膳立て)
  • gnuplotをインストール
  • GitStatsをGitHubから入手
  • GitStatsをインストール
  • GitStatsを使ってみる

• gnuplotのインストール
  • http://ricardo.ecn.wfu.edu/pub/gnuplot/からdmgファイルをダウンロード，アプリケーションに放り込んでおく
  • ターミナル起動，右のコマンドを打ち込む：ln -s /Applications/Gnuplot.app/Contents/Resources/bin/gnuplot /usr/local/bin/
  • ターミナルにgnuplotと打ち込んで起動することを確認する

• GitStatsのインストール
  • まずはクローン：git clone git://github.com/hoxu/gitstats.git
  • gitstatsディレクトリに移動，右のコマンドを入力：make install

• gitstatsの起動
  • gitstats 【リポジトリ(.git)の場所】 【生成場所】
  • 生成場所のindex.htmlでグラフが表示される

活動報告†

02/03†

• ソースファイルが取れなかった理由が判明
  • あるコミットを境に，srcディレクトリ以下ではなく，junitディレクトリ以下に配置されていることがわかった

2月の予定†

• 上記のソースファイルについて早急に取得＆Understandでメトリクス結果のcsv取得
• 各解析結果について，依存関係のcsvを吐き出す(できれば2週間以内に終わらせたい)
• 月末に，塩谷くんのSpotBugs解析結果を組み合わせてdbを作成する

01/30†

• 一旦解析完了
  • ソースコードが適切に取得できていなかった問題は順次解決する(TODO)
• 塩谷君との話の中で，SpotBugsで依存関係を持つTDを取得することが可能なのかを議論，１ファイル内で解決されるエラーしかない...

01/28†

• Understand解析中
  • 途中のコミットからソースコードを適切に取得できていなかったことが判明，そのコミットから再度ソースコードを取り直し解析を再開する

01/21†

• 対象プロジェクトをJUnit4で調整
  • 全コミット毎のソースコードを収集中
  • 22日からUnderstand実行
  • 塩谷君のSpotBugs解析が終わったらデータ照らし合わせ．ハッシュ値で紐付けられるようにする
    • ハッシュ値を介してSpotBugsで検出されたエラーをUnderstandで検出した依存関係グラフを用いて辿り，どこにTDが波及していったのかを見る(とりあえず証拠集め)-->遅くとも月末までには確実に完了させる
    • さらにTDが解決されないことにより各メトリクスの数値が変動した場合，利子が増えたものと判断する．(ただしまだモデルにどうやって当てはめるのかまではイメージできていない)

TODO†

• 研究計画書を書く

01/20†

• 全コミットで実行するのはいまだに苦戦中であるが，とりあえず1コミットでUnderstandを実行することに成功
  • 結果の読み方を確認する
• 塩谷君がSpotbugsを実行してくれているので，結果を待ちつつこちらもUnderstandの実行環境を整える

TODO†

• Understandから得られたメトリクス解析結果をどのようにモデルに当てはめるのかを考える

01/17†

• 福元くんの提案では，依存関係を取るだけならJdepsを使うのもありかもしれないとのこと．
  • understandは関数の関係しか見れないかもしれないので，求めているものは発見できないかもしれない．
  • jdepsを使用することも検討する．

• understandの実行について
  • 柏さんのrepo-tools上にUnderstandを実行できる環境があることを確認
  • 自身の環境でも実行できるように環境構築を行う

• メトリクス分析の結果を機械学習でモデル化している研究を発見
  • 使用ツール：weka
  • まだよくわからないのであくまでメモ書き

01/14†

• 現地点での進捗とTODO
  • 01月14日_0.pdf

11/25†

• 工数見積もりの論文いくつか読んでみたけどよくわからない
• Bugzillaで検出されたバグが修正するまでの時間が増加しているかどうかで工数を見積もるのが良いのか？？
  • とりあえず，バグ修正時間予測の既存研究を調査してみる

11/19†

• RxJavaの2012年3月〜2017年3月での集計が完了
  • LOCの増加に伴ってWARNINGが急激に上昇している箇所がある
• TODO
  • priorityのレベルやWARNINGの種類で分けてみる
  • LOCとWARNING数から近似関数を作成する
    • LOCについては1ヶ月区切りでしか今のところわかってないので，とりあえずそれで関数作ってみる

11/18†

• jabrefの2014年3月〜2016年9月での集計が完了
  • 随分と歪な変化が見られた(特に面白みはない...?)
• FindBugsのWARNINGの種類ごとに集計を出してみると何か出てくるか？

• TODO
  • RxJavaについても同様に集計を行う

11/14†

• 片桐さんのツールfbapplierで複数のリビジョンでFindBugsが実行できることを確認
  • beamで実行しようとしたが，ソースファイルの位置の関係で実行できてない
    • 恐らくfbapplierで実行するのは困難？
  • RxJavaが実行できたので，まずはRxJavaを対象にしようかな
    • 使用できそうなプロジェクト：RxJava, jabref
  • 研究室のマシンで実行する
    • と思ったら片桐さんが大半のコミットを分析していらっしゃったので、ありがたく拝借
• TODO
  • RxJavaにgitstatsを実行
  • xmlファイルからWARNINGの数をカウント、コミットハッシュ順にソート
  • ローンの返済方法などをちょっくらお勉強、なんか使えそうな気がする

11/08†

• 発見された課題
• プロジェクト内で発生したWARNINGの数を，リビジョンごとに数える．
  • 各リビジョンのLOCと比較して，指数関数的に増加しているのかを見る
  • もし増えている場合・・・前のリビジョンとの差分が多重債務であると判断できる

11/06†

• beamの検索結果：
  • COMMITのHashCommitとSonarのHashCommitの数を比較した結果
  • COMMIT数(22332) - Sonar_ISSUES数 (19749) = 2583
  • では，この2583件はどこへ行ったのか？
    • (予想)MargeなどでそもそもTDが入るようなコミットではなかった？

• TDの工数が既存のモデルに一致しているのかをチェックする必要がある．
  • グラフ化する(縦軸：Effort(min)，横軸：Commit(time))
• 1コミットごとにSonarを回しているのかと思ったら，ファイルの行数ごとに分析しているっぽい(SONAR_ISSUESのStartlineとEndlineが一致しているところを見るとどうやらそうらしい)
• beamのCommitHashを時系列に並べ，2番目と3番目のCommitHashを比較したところ，TDの件数が26->28(件)に，
  • Effortが279->1607(min)に増加
  • ただ，2つのTDを比較すると，一致しているファイル・行数がない．つまり単純にCommi間を比較してもわからない？でも工数は確実に増えているように見える．
  • 件数や工数で比較する場合，差分はT Dによるものだと思われるが，既存のTD(A)によるものなのか，TD(B)が新たに発生したのかどちらになるのかを目視する必要がある． 見える．
  • commitHashに対応するSONAR_ISSUESのcreationcommitHashがない場合がある -> コメントアウトの変更，pomファイルの変更, READMEファイルの変更など?

11/01†

• DONE
  • 研究動機研究動機【11月01日】.pdf
    • MSRに出せたらいいなー
• TODO
  • データセットの収集・分析
    • "The Technical Debt Dataset"のASFデータを利用
    • https://github.com/clowee/The-Technical-Debt-Dataset

10/25†

• TODO
  • Tracy: A Business-Driven Technical Debt Prioritization Framework
  • The Delta Maintainability Model: Measuring Maintainability of Fine-Grained Code Changes
  • Estimating Development Effort in Free/Open Source Software Projects by Mining Software Repositories: A Case Study of OpenStack
  • TD工数見積もり研究での問題点の洗い出し

10/18†

• TODO
  • TDのデータセットの収集
    • https://docs.google.com/document/d/1bU8UGLD--M-XG5rpdhEunt4cUNgsAu6NABbBmPW_TkI/edit

08/28†

• 技術的負債の元本と利子を定量化した研究
  • Establishing a Framework for Managing Interest in Technical Debt
  • A framework for managing interest in technical debt: an industrial validation

08/21†

• この論文はTDのモデル化をしようとしている論文かもしれない
  • The Delta Maintainability Model: Measuring Maintainability of Fine-Grained Code Changes

08/08†

• システムの変更率が双曲割引率によって求められるという内容の論文を発見
• サーベイ論文2つ目を取得

08/05†

Done†

• ソフトウェア信頼度成長モデルの動的分析手法について一通りかじってみた
  • ハザードモデル，NHPP，統計的分析方法など
    • もう少し深めにかじっても面白いが一旦保留
• TD論文を読み込み中
  • 設計段階でのTD,TDの原因とその影響の定性的分析を読んだ

07/11†

Done†

• 研究で使用するツールの選定
  • 工数見積もり，ソフトウェア複雑度分析，TD検出をそれぞれ行うためのツール

Todo†

論文メモ†

テンプレ†

Done†

Todo†

論文メモ†

ショートカット

• 新入生へ
• 卒業生へ
• Projects
• 研究グループ
• 研究発表会
• 引き継ぎ
• 輪講資料
• マシン管理
• アカウント管理
• UPKI申請手順
• 研究協力
• 精算関連
• 購入希望物品
• 論文！学会発表！
• Tools
• 学会参加報告
• 院試＠和歌山大学
• 過去のイベント
• 論文英語単語帳
• サイトマップ
• MenuBar

メンバのページ

• 旧メンバ@NAIST
• 旧メンバ@和大
• 大平＠2012〜
• 野口@2018~
• 作島@2019~
• 堀口@2019~
• 木村@2019~

最新の30件