解釈を変更可能なプログラムソースコード保守性評価ツールの実現と適用
ダウンロード数： 166回
年度 : 2013年
発表場所 : SQiPシンポジウム
紹介文 :
ソースコード品質評価にドメインの特性や開発者の意図を反映させ、より適切な評価結果を得る方法を提案しています。
測定されたメトリクスに対する開発者へのヒアリングの流れや結果、得られた評価結果の分析、ツールの改善点などが示されています。ソースコード品質評価における課題や改善の進め方に興味がある人にとって有意義な内容となっています。
本研究に登場する既存のソースコード品質評価ツール「Adqua」を使っている方にはもちろん、他のソースコード品質評価ツールを使っている方にとっても、参考になる研究です。
ソースコード品質評価にドメインの特性や開発者の意図を反映させ、より適切な評価結果を得る方法を提案しています。
測定されたメトリクスに対する開発者へのヒアリングの流れや結果、得られた評価結果の分析、ツールの改善点などが示されています。ソースコード品質評価における課題や改善の進め方に興味がある人にとって有意義な内容となっています。
本研究に登場する既存のソースコード品質評価ツール「Adqua」を使っている方にはもちろん、他のソースコード品質評価ツールを使っている方にとっても、参考になる研究です。
概要 :
As a technique for measuring the quality characteristic of software, there is a method of evaluating quality which conducted static code analysis using the metrics drawn in the form connected to the goal which
should be made clear on quality based on the Goal-Question-Metric (GQM) method. However, if the characteristic that a developer minds for every domain or project may differ from each other and the quality
evaluation of two or more projects (especially domains differ) is carried out by the same GQM model, the evaluation which is different from a developer's viewpoint or the characteristic of a domain may be obtained.
Then, after including a developer's intention in a GQM model, it is desirable to carry out quality evaluation,but in the quality evaluation tool for many source codes, the GQM model given a definition is easily
unchangeable. Moreover, the influence on the evaluation result in the real project at the time of changing the evaluation result based on the measurement result of metrics according to a domain, the characteristic for every project, or a developer's consideration is not clear. Then, in evaluating the quality of a source code from the measurement result of the metrics in a GQM model, we realize the program source code conservativeness evaluation tool which made variable the interpretation of the measurement result according to the characteristic of a domain, or a developer's viewpoint. Furthermore, we checked that some evaluation results changed by comparing the case where the standard quality evaluation for Adqua and the case where the conservativeness
evaluation tool is applied, after setting up interpretive procedure through the hearing of a development pursuer.
As a technique for measuring the quality characteristic of software, there is a method of evaluating quality which conducted static code analysis using the metrics drawn in the form connected to the goal which
should be made clear on quality based on the Goal-Question-Metric (GQM) method. However, if the characteristic that a developer minds for every domain or project may differ from each other and the quality
evaluation of two or more projects (especially domains differ) is carried out by the same GQM model, the evaluation which is different from a developer's viewpoint or the characteristic of a domain may be obtained.
Then, after including a developer's intention in a GQM model, it is desirable to carry out quality evaluation,but in the quality evaluation tool for many source codes, the GQM model given a definition is easily
unchangeable. Moreover, the influence on the evaluation result in the real project at the time of changing the evaluation result based on the measurement result of metrics according to a domain, the characteristic for every project, or a developer's consideration is not clear. Then, in evaluating the quality of a source code from the measurement result of the metrics in a GQM model, we realize the program source code conservativeness evaluation tool which made variable the interpretation of the measurement result according to the characteristic of a domain, or a developer's viewpoint. Furthermore, we checked that some evaluation results changed by comparing the case where the standard quality evaluation for Adqua and the case where the conservativeness
evaluation tool is applied, after setting up interpretive procedure through the hearing of a development pursuer.
