SQiP シンポジウム 2011 ＣＫメトリクスの分布に基づくソフトウェア設計の質の定量的評価 Quantitative Evaluation of Software Design Quality by using CK Metrics Distributions ○倉下 亮1) ○Ryo Kurashita1) 日本電気株式会社 IT ソフトウェア事業本部 NEC IT Software Operations Unit 吉村 博昭 1) 野中 誠2) 誉田 直美 3) Hiroaki Yoshimura1) Makoto Nonaka2) Naomi Honda3) Abstract Software design quality affects to software maintainability such as analyzability, which reduces the risk of quality problem and therefore increases reliability. To evaluate and improve the quality of software design, qualitative techniques such as checklists and design guidelines are typically used in practice. In addition, quantitative techniques such as design metrics are helpful to audit large number of projects efficiently from a quality assurance perspective. However, static thresholds for the employed metrics are sometimes useless and impractical to evaluate software design quality because of the variability of software products. Therefore, we need to use rich information about software design. In this paper, the authors introduce a quantitative evaluation technique of software design quality by focusing distributions of design metrics. The technique itself is still debatable but distributions of coupling and cohesion measures were helpful to understand the quality of software design. 1. はじめに ソフトウェア設計の質の向上は、ソフトウェアの保守性を高められるだけでなく、構造的な複 雑さを抑えることによりバグ混入のリスクを低減でき、ひいてはソフトウェア製品の信頼性向上 に結びつけることが期待できる。設計の質を向上させるには、設計レビューなどにより設計の改 善を検討することが一般的である。しかし、改善にあたっては定性的な指針が用いられることが 多く、定量的な評価方法が定着しているとはいいがたい。とくに、品質保証の立場で多数のプロ ジェクトを横断的に監査する場合には、設計の質を定量的に把握する評価指標が求められる。 筆者の所属する組織では、設計の十分性に関する評価指標として、設計仕様書のドラフト版作 成工数、レビュー工数、仕様書ページ数といった指標をこれまで用いてきた[1]。これらの指標は、 プロジェクト単位のように大きな視点で評価する場合には一定の目安となるが、プロセスデータ だけで、設計の質の評価をするには限界がある。また、品質保証部門による設計仕様書の第三者 レビューも実施しているが、これは目次レベルでの記載すべき項目のチェックであり、設計仕様 書そのものの定量的評価ではない。そもそも、定量的評価には画一的な設計仕様書の記載方法が 必要となるが、筆者等は様々な汎用ソフトウェアの開発を対象としており、全開発製品に共通の 1) 日本電気株式会社 ＩＴソフトウェア事業本部 NEC IT Software Operations Unit 〒211-8666 神奈川県川崎市中原区下沼部 1753 Tel: 044-431-7692 1753, Shimonumabe, Nakahara-Ku, Kawasaki City, Kanagawa Japan Tel: +81-44-431-7692 2) 東洋大学 Toyo University 〒112-8606 東京都文京区白山 5-28-20 5-28-20, Hakusan, Bunkyo-ku, Tokyo Japan 3) 日本電気株式会社 ＩＴソフトウェア事業本部 NEC IT Software Operations Unit 〒183-8501 東京都府中市日新町 1-10 1-10, Nisshincho, Fuchu City, Tokyo Japan Tel: 03-3945-4900 Tel: +81-3-3945-7461 Tel: 042-333-5427 Tel: +81-42-333-5427 SQiP シンポジウム 2011 メトリクスを設定することも難しい状況である。 ここで考えられる１つの方法は、コーディングがある程度進んだ段階でソースコードメトリク スを計測し、このメトリクスを活用して設計の十分性を確認する方法である[2]。設計要素を定量 的に示すメトリクスには、サイクロマチック数や分岐条件数、オブジェクト指向設計に関する CK メトリクス3)などさまざまな技法がこれまでに提案されている。また、これらのうち複数のメトリ クスの組に対して画一的な基準値を設けた Rosenberg らの提案[3,4]などが提示されている。しか し、たとえばソフトウェア規模が大きくなるとモジュール間結合度を低く抑えるのが次第に難し くなるように、画一的な基準値で設計の質を評価することが適切であるのかは議論の余地がある。 本稿では、CK メトリクスの測定値の分布に着目することで上述の弱点を補い、これを従来手法 との併用によりソフトウェア設計の質を評価する手法について報告する。この手法を自社内外の ソフトウェア 10 製品に適用し、その有用性を評価した。筆者らの組織ではこれまでにソフトウェ ア品質会計を軸とした品質管理に取り組んできたが、この手法を適用することで、これまで手薄 だった設計の質の評価と改善に対するプロジェクト横断的な活動の展開が期待できる。 2. 筆者所属組織の 筆者所属組織の事業環境 ここでは、本研究で対象とするソフトウェア製品の特徴、開発プロセスとその管理について概 観する。 2.1 ソフトウェア製品 ソフトウェア製品の 製品の特徴 筆者らの組織では、特定の顧客向けのシステムではなく、汎用的なソフトウェアの開発・保守 を行っている。そのため、出荷後に品質問題が発生した場合の影響範囲が大きく、高いレベルで の品質確保が特に求められる。 2.2 開発プロセス 開発プロセスと プロセスと管理 開発プロセスは、図 1 のＶ字モデルを基本としている。これは、基本設計からコーディングま での上流工程と、単体テストからシステムテストまでのテスト工程で構成される。 図 1 開発プロセス 開発プロセス 上流工程では、プロセス管理による仕様書等のレビューの十分性、設計仕様書の第三者確認に 3) CK メトリクスとは、Chidamber と Kemerer によって 1994 年に提案された、オブジェクト指向設 計の特性を測定する代表的なプロダクトメトリクスである。 SQiP シンポジウム 2011 よる記載内容の妥当性、両者を組合せて品質管理を行っている。 プロセス管理 設計仕様書のドラフト版作成工数、レビュー工数、仕様書ページ数、レビューによる摘出 バグ数、開発規模(BD から DD は予測、CD は実績)を計測し、これらの値を組み合わせたプ ロセス指標を活用 設計仕様書の第三者確認 品質保証担当が、開発部門作成の設計仕様書を、所属部門の標準である設計/レビューガイ ドに照らし、目次レベルでの記載すべき項目を確認 汎用的なソフトウェアでは、多岐に亘る動作プラットフォームや多様化したお客様ニーズ、短 納期などを考慮した開発が必須であり、ソフトウェア製品の分野により開発スタイルが異なる。 そのため、製品特性や開発する機能によって、適切な表現方法を工夫せざるを得ず、すべての特 性を網羅するような標準化は困難である。 設計の定量的評価には、設計仕様書そのものの定量的計測が考えられるが、現段階では、上述 の事情が妨げとなっている。 3. 過去の 過去の知見と 知見と今回の 今回の取り組み 上述のとおり、筆者所属組織では設計仕様書の定量的計測には解決すべき課題も多い。まずは、 設計仕様書を測定するのではなく、その代替方式としてソースコードメトリクスに着目し、この 計測結果を設計にフィードバックする手法を検討する。特に、CK メトリクスには、オブジェクト 指向設計でのクラス間インタフェースやメソッドの呼び出し関係に関するものなど設計に関わる メトリクスがあることから、これを活用することとする。ここでは、筆者所属組織の開発製品等 に対して CK メトリクスに関する従前の知見を適用し、その適合性と問題点を明確にすると共に、 それに対する改善提案について述べる。 3.1 過去の 過去の知見の 知見の検証 設計に対する定量的メトリクスの導入に際しては、ソフトウェア開発者の納得性を重視したい。 このため、出荷後の品質状況や設計の良し悪しなどの定性的評価と CK メトリクスが符合するかを 検証する。まずは、CK メトリクスに関する過去の知見として、Rosenberg, Stapko, Gallo の提案 [3,4]、および、Lorenz の経験則[5]について検証した。 3.1 3.1.1 Rosenberg, Stapko, Gallo の提案 この提案は、クラスの応答数(RFC)、クラスのメソッド数 (WMC)、オブジェクトクラス間結合度 (CBO)について４種の基準を設け、あるクラスが複数の基準に抵触した場合に要注意と判断するも のである。 Rosenberg, Stapko, Gallo が提案する基準 以下の基準に２つ以上該当するクラスは要注意である． クラスの応答数 RFC > 100 RFC > クラスのメソッド数×5 オブジェクトクラス間結合度 CBO > 5 メソッド数> 40 図 2 に、自社ソフトウェア 10 製品 （SW1～SW10）それぞれの全クラスに対して、Rosenberg, Stapko, Gallo が提案する基準に抵触したクラス数の割合を示す。SW1～3 はオブジェクト指向設計のエキ スパートが内部設計したソフトウェア、SW4～7 は出荷後品質に問題のあった自社ソフトウェア、 SQiP シンポジウム 2011 SW8～10 はオブジェクト指向設計上改善の余地があると定性的に判断された自社ソフトウェアで ある。本結果に示すとおり、エキスパートが内 部設計したソフトウェアでは抵触率が低い。し かし、抵触率が低いにもかかわらず出荷後品質 の悪いソフトウェア（SW5, SW6）もあれば、オ ブジェクト指向設計上の改善を要すると判断 されたにもかかわらず抵触率の低いソフトウ ェ ア （ SW8,SW9,SW10 ） も 存 在 し て お り 、 Rosenberg らの抵触率と出荷後品質ならびに 設計改善の必要性は必ずしも相関関係にある とは言えない。 図 2 Rosenberg 等の提案の 提案の抵触率 抵触率 3.1 3.1.2 Lorenz の経験則 Lorenz は経験から下記を提唱している。この経験則についても、上述の Rosenberg 等の提案と 同様に自社ソフトウェア等を用いて計測した(図 3)。SW4～7 は全般に高い値であるが、オブジェ クト指向設計のエキスパートが内部設計したソフトウェアである SW3 も同等に高い値であった。 一方で、オブジェクト指向設計上改善の余地がある自社ソフトウェアである SW9 は SW1、SW2 と大 きな差は無い。この様に、Lorenz の経験則についても、Rosenberg らの提案と同様に、内部設計 の良し悪しと必ずしも相関関係にあるとは言えない。 Lorenz の経験則 クラスあたりの平均メソッド数 < 20 クラスあたりの平均インスタンス変数 < 6 継承ツリーの深さ DIT < 6 Rosenberg 等の提案、Lorenz の経験則、いず れもクラス規模などの要因を加味しない画一 的な基準が示されたものであるが、上述の通り、 図 3 Lorenz の経験則の 経験則の抵触率 いくつかの自社製品に適用したところ、出荷後 品質との相関は必ずしも高くなく、自社で設計時の基準として導入するには、ソフトウェア開発 者に対する根拠に乏しい。 3.2 着眼点と 着眼点と提案 筆者らは、後述の表 1 のとおり、CK メトリ クスによってはクラス規模と一定の相関があ る点を知見として得た。そこで、画一的な基準 値を用いた上述の提案に対し、クラス規模によ る CK メトリクスの累積相対度数分布グラフの 形状に着目した手法を提案する。 3.2.1 累積相対度数分布グラフ 累積相対度数分布グラフ メトリクスの累積相対度数分布グラフは、対 象製品を構成するすべてのモジュールの測定 値を昇順に並べ、その累積相対度数を折れ線グ 図 4 累積相対度数分布グラフ 累積相対度数分布グラフの グラフの例 SQiP シンポジウム 2011 ラフで表したものである(図 4 の折れ線)。さらに、このグラフが一定の基準値(図 4 の垂直線) を超えた部分について、グラフと累積相対度数 100%の線のあいだにできる面積(図 4 の①部分) により設計の質を定量的に評価することを試みる。 この方法により、基準値を超過するモジュールの相対的な情報を表現できるようになり、画一 的な基準値による評価に加えて扱う情報量が増加すると考えられる。 3.2.2 メトリクスと メトリクスと基準値 上述の方法を、CK メトリクスのうち、CBO とメソッドの凝集度の欠如の度合い(LCOM4))に対して 適用し、設計の質の評価を行う。 CK メトリクスには、CBO、LCOM の他、RFC、WMC など複数存在するが、メトリクス相互の相関関 係を計測し、独立性の高いものを選択する。表 1 は、前出の SW1～SW10 について、各種メトリク スの相関を計測し、相関係数の高かったソフトウェア数を示したものである。この表にあるとお り、クラス規模を中心に WMC と CBO は相関が高いソフトウェアが多い傾向にあり、WMC は RFC と の相関が高いソフトウェアが多い傾向にある。これらのメトリクスは累積相対度数分布で見ても 同じ傾向を示してしまう可能性が高いので、全体として他のメトリクスと最も相関の少ない傾向 にある CBO を代表させることとする。なお、クラス規模は、累積相対度数分布グラフの作成上無 関係ではないが、本論文の目的である設計検証には適さないため相関の計測のみに用いる。また、 LCOM は相関を計測したメトリクスの中で、他のメトリクスと最も相関の高いソフトウェアが少な く、CBO の計測結果を補間できると考え、これも選択することとする。 一般に、多数のメトリクスを複合的に用いればより精度の高い結果が期待できるが、実運用時 の煩雑さを回避するため、シンプルさを追求しメトリクスは CBO、LCOM の２つのみとする。 表 1 メトリクス間 メトリクス間の相関ありの 相関ありの SW 数 クラス規模 RFC WMC LCOM CBO 合計 クラス規模 － 3 9 1 1 8 22 RFC 3 － 7 1 3 1 15 WMC 9 7 － 1 1 3 21 LCOM 1 1 1 － 0 1 4 DIT 1 3 1 0 － 1 6 CBO 8 1 3 1 1 － 14 次に、自社ソフトウェアの計測結果を用い て CBO と LCOM の基準値を設定する。 図 5 は、 SW5 の全クラスと出荷後に修正のあったクラ スについて、CBO 値、LCOM 値を横軸とし全体 の割合を表したものである。この図で、CBO、 LCOM とも出荷後修正のあったクラスの割合 の半数(50%)となる値を基準に設定する。今 回、CBO の基準値は 14 とし、LCOM の基準値 は 80 に設定する。これらの基準を超える部 分に、出荷後に修正のあった全クラス中の 69%が含まれており、基準値として適切であ る。なお、それらの修正の多くは設計上の見 通しの悪さにも一因があることから、CBO、LCOM 4) DIT 図 5 CBO/LCOM と出荷後修正クラス 出荷後修正クラスの クラスの割合 メソッドの凝集度の欠如の度合いを 0～100%の値で示したもので、Chidamber と Kemerer によっ て 1994 年に提案された。LCOM2 と表現される論文もあるが、本稿では LCOM と記載する。 SQiP シンポジウム 2011 で設計の質の一端を見ることができると考える。 4. 計測結果 図 6 は CBO の、図 7 は LCOM の累積相対度数分布グラフである。Rosenberg らの提案、Lorenz の経験則の計測時と同様に、オブジェクト指向設計のエキスパートが内部設計したソフトウェア （自社製品、オープンソースソフトウェア）3 製品(SW1～3)、出荷後品質に問題のある自社ソフ トウェア 4 製品(SW4～7)、オブジェクト指向設計上改善余地のある自社ソフトウェア 3 製品(SW8 ～10)、計 10 製品を計測対象とした。 基準値を超過する面積について論ずる 前に、基準の達成状況を整理しておく。 CBO を基準値(14)で見ると、エキスパー ト設計のソフトウェア(SW1、SW2、SW3) は、基準値遵守の比率が 95%以上と高い が、出荷後品質に問題のある自社ソフト ウェア(SW6)や設計改善余地のあるソフ トウェア(SW8)も同様に 95%以上である。 また、その他のソフトウェアについても 80%以上であり、 全体として密集している (SW4、SW5、SW7、SW9、SW10)。同様に、 LCOM を基準値(80)でみると、設計改善余地 のあるソフトウェア(SW10)はエキスパー ト設計のソフトウェア(SW1、SW2、SW3) の何れよりも高い基準値遵守の比率とな っている。また、80%前後では、両者およ び品質問題のあるソフトウェアも密集し た状態である。 以上のとおり、画一的な基準値を用い た上で、単純に基準値遵守の比率を見る だけでは、良し悪しの区別が出来ず、品 質の判断には使えないことがここでも検 証できる。 5. 考察と 考察と検証 図 6 CBO 累積相対度数グラフ 累積相対度数グラフ 図 7 LCOM 累積相対度数グラフ 累積相対度数グラフ 5.1 考察 上述の計測結果を基に基準値を超過した 部分の面積を算出し、一覧化したものを図 8 に示す。 CBO に着目すると、図 6 ではどのソフトウ ェアも基準値遵守の比率は 80%を超えている が、基準値を超えた部分の面積を比較すると、 SW4、SW10 は他のソフトウェアと大きく乖離 している。95%以上の SW6 も、SW1、SW2 と比 べると面積は大きい。一方、LCOM では、SW4、 SW6、SW8 がエキスパート設計のソフトウェア 図 8 CBO/LCOM 基準値超の 基準値超の面積 SQiP シンポジウム 2011 (SW1、SW2、SW3)より大きな値となった。 ここで注目したいのは、CBO、LCOM の基準値を超えた部分の面積の合計値である。オブジェク ト指向設計のエキスパートが内部設計したソフトウェア(SW1～3)は、CBO、LCOM の面積の合計値 が最大で 2.28(SW3)であるのに対し、出荷後品質に問題のある自社ソフトウェア 4 製品(SW4～7) と、オブジェクト指向設計上の改善余地のある自社ソフトウェア 3 製品(SW8～10)は、最小でも 2.64(SW5)である。つまり、内部設計が良い製品ほど、面積の合計値が低い傾向となっており、CBO、 LCOM の分布に着目した計測により、内部設計の質の定量的評価の一助となり得ると考える。 5.2 検証 図 9 は、本手法を他のソフトウェアに対して適用した結果である。 SW11 は、オブジェクト指向設計の浸透している開発拠点で開発されたソフトウェア、SW12 は、 SW8、SW9、SW10 と同じくオブジェクト指向設計上の改善余地のある自社ソフトウェアである。図 8 での 2.28(SW3)、2.64(SW5)の中間を仮に基準(2.46)とすると、SW11 は基準値以下、SW12 は基準 値を超えており、図 8 での結果と同様の傾向を示している。SW15、SW16 は、新技術の実装時に研 究開発されたソフトウェアであり、開発初期段 階からスクラッチアンドビルドで作成されたも のである。このような成り立ちのソフトウェア についても、本手法により設計の不十分さを指 摘することができる。 SW13 は、製造後サイクロマチック数や分岐条 件数などを計測、管理し、出荷までに改善して きたソフトウェアである。また、SW14 は、派生 開発の際、リファクタリングにより構造を見直 したソフトウェアである。いずれのソフトウェ アも、メソッド内部の構造改善は推進したが、 図 9 CBO/LCOM 基準値超の 基準値超の面積の 面積の検証 クラス間の関係やクラス設計そのものにまで 踏み込んだ修正は行っておらず、今後、本手法の適用により、より一層の改善推進が図れるもの と期待する。 なお、上述のとおり SW3 と SW5 の間を境に設計の質の良し悪しを見ることが出来たが、それぞ れの面積を絶対値でみれば大きな差は無い。そこで、CBO、LCOM 以外のメトリクスに目を向けた ところ、後者は最大 6KLOC 超の巨大クラスが存在し、規模の標準偏差も前者の 3 倍を超えている など、クラス規模の分布に差異があることがわかった。ソースコードを解析したところ、この巨 大クラスは、プログラムの主処理を担っている部分であることもわかった。しかしながら、現在 使用しているメトリクスの計測ツールでは、クラスの上下関係まで踏み込んだ計測はできず今後 の検討課題としたい。 6. おわりに 本手法は、クラス一つ一つの単純な計測値ではなく、全クラスの中での計測結果の重みを見て いる。このため、実際の運用では、CBO および LCOM の面積が基準値を超過しているかどうかを監 視し、超過している場合には、該当するクラスの設計改善を促進し、基準値内に収まったかどう かを再度確認することとなる。また、当部門では、製品の開発の際、既存製品の機能強化をバー ジョンアップという形で繰り返し実施する派生開発が多いので、都度の開発で改造のある部分に ついてクラスの設計改善を促進するなど、運用上の工夫が必要となる。 一方、手法そのものについても、5 章で述べたとおり検討すべき課題がまだ存在しており、本 論文で用いた CBO、LCOM とその他のメトリクスとの組合せの考慮も含め、より精度を高めていく 必要がある。本件については、クラス規模と出荷後品質の関係や、クラスの上下関係がメトリク SQiP シンポジウム 2011 スにもたらす影響などに目を向け検討を進めたい。この検討により、品質やプロダクトメトリク スとの関係を明らかにしていくことで、適正な規模でのクラス設計、メソッド設計の一助となる ことを期待している。 CK メトリクスの測定値の分布に着目した手法により、内部設計後の早い段階でのオブジェクト 指向設計の質の定量的評価に道が開けた。このことは、設計に対しプロセスメトリクスによる管 理手法しかなかった従来と比較し一歩前進である。既に、サイクロマチック数等のプロダクトメ トリクスの計測は自動的に行っており、CK メトリクスについても自動計測の準備中である。 今後、 コーディング着手後、CK メトリクスが機械的に計測できる段階で本論文の提案内容を実運用で推 し進め、オブジェクト指向設計による内部設計に定量的観点で一定の指針を設けることで、プロ セスメトリクスによる従来の管理手法を補完し、出荷後の品質リスクの低減に繋げたい。 参考文献 [1] 誉田直美, ソフトウェア品質会計：NEC の高品質ソフトウェア開発を支える品質保証技術, 日科技連, 2010. [2] 纐纈伸子，川村真弥，野村准一，野中誠，プロセスメトリクス利用よる Fault-Prone クラ ス予測精度の向上，Aug. 2010，ソフトウェア品質シンポジウム 2010 [3] Rosenberg, L., Stapko, R., and Gallo, A., Applying Object-Oriented Metrics, 6th Int’ l Symposium on Software Metrics, Nov. 1999. [4] Rosenberg, L., Applying and Interpreting Object Oriented Metrics, Software Technology Conference, Apr. 1998. [5] Lorenz, M. and Kidd, J., Object-Oriented Software Metrics: A Practical Guide, PTR Prentice Hall, 1994.
© Copyright 2024 Paperzz
