SQiPシンポジウム2009 ソフトウェアの複雑性が改造時のバグの発生に与える影響について A qualitative impact of structural software complexity in maintenance projects 富士通株式会社 Fujitsu Limited 田中忠昭* ○中村光宏* ○Mitsuhiro Nakamura Tadaaki Tanaka Abstract This paper illustrates a bug number prediction model in building maintenance projects implementing small functional enhancements in existing software. More specifically, it reports on estimation models on structural complexity of embedded software based on the density and regularity model. It is shown that structural complexity has greater homogeneity in their relationship of predicted bug number with real bug number. 1. はじめに筆者の所属する組み込みソフトウェア開発の現場では、新規に開発を行うケースより既存のソフトウェアを母体にして改造を行うケースが多い。我々は、こうした改良開発でのフィールド流出問題の多くが母体の複雑性による理解不足が原因で発生していると予想した。本稿では、まず、フィールド流出問題における母体の理解不足の影響を調査し、バグ数がどのようなソフトウェア構造の複雑性に起因しているかを分析した。このようにバグ数とソフトウェアの複雑性の関係を明らかにすることで、改良開発における望ましいソフトウェア構造を提案することが可能になる。 2 章では既存のソフトウェアを母体にして改造を行う時にソフトウェア構造の複雑性が与える影響について概観する。3 章ではソフトウェアの複雑性を評価する統一的なモデルに基づいて複雑性とバグの発生状況の相関を分析することで、バグの発生に影響の大きな複雑性メトリックスを抽出する。4 章ではそのメトリックスを使ったバグ数予測モデルを提案し、単純な改造規模と母体規模に基づくモデルと実際のバグ数との相関を比較する。 2. 改造時に改造時にソフトウェア構造ソフトウェア構造の構造の複雑性が複雑性が与える影響える影響 2.1 母体の母体の理解不足が理解不足が影響する影響するバグするバグのバグの比率ネットワーク機器をはじめとする一部の組み込みソフトウェアはライフサイクルが長く、定期的な機能追加を長期間にわたって繰り返す開発形態が多いため、追加機能に閉じた比率よりも母体の構造と関連したバグの比率が大きい。図 2.1 に過去のフィールドに流出したバグ 55 件について、原因が母体の理解不足と思われる割合を調査した結果を示す。このうち、直接原因としたのは改造によって既存機能に不具合を生じたケースであり、何らかの影響としたのは追加機能の不具合の原因に既存機能の構造が関係しているケースである。図 2.1 母体の理解不足によるバグの比率 * 〒222-0033 神奈川県横浜市中区尾上町 6-81 ニッセイ横浜尾上町ビル Tel: 045-222-9915 6-81 Onoe-cho, Naka-ku, Yokohama, Kanagawa, Japan Tel: +81-45-222-9915 SQiPシンポジウム2009 これらのバグの発生理由は母体構造の調査不足とされがちだが、むしろ母体が複雑で十分な調査が難しいことが、根本原因ではないかと考えられる。 2.2 ソフトウェア開発ソフトウェア開発効率開発効率への効率への複雑性への複雑性の複雑性の影響新規開発に比べて改造開発を対象としたエンジニアリング上の検討事例は少ない。改造の場合、改造規模に加えて、母体となるソフトウェアの規模や複雑性といった変動要因が多く、さらにそのソフトウェアの複雑性には多様な側面があり、定式化が難しいことが理由と考えられる。ドキュメントの整備状況のような項目は決められても、モジュール性のようなソフトウェアの構造的複雑さを評価するのは容易でない。文献[1]では、改良開発に特有の変動要因（生産性に影響）の例として、以下の 6 点をあげている。・変更箇所の分散度・機能実現やテストへの波及度合い・既存システムに対する習熟度・既存システムの正確性・既存システムの理解容易性・既存テスト環境の再利用性上記のうち、ソフトウェア構造の複雑性と直接関連するのは、既存システムの理解容易性であるが、変更箇所の分散度や機能実現やテストへの波及度合いにも影響を及ぼす可能性がある。母体の理解不足によって発生するバグの対処だけでなく、改造が難しくなることによる開発効率の低下が予想される。 3. ソフトウェアのソフトウェアの複雑性と複雑性とバグのバグの発生との発生との相関分析との相関分析 3.1 複雑性評価モデル複雑性評価モデルソフトウェアの構造は図 3.1 に示すように、全体が機能ブロック(以下 FB と呼ぶ)の集合で構成され、FB は関数やグローバルデータの集合で構成され、関数は文の集合で構成されるというように階層構造をしている。（FB 以上の階層は開発組織で名称が異なるケースがあり、また、ソフトウェア規模によっては階層の数も異なるが、本稿では図 3.1 の構成を前提とする。）各階層は図 3.2 に示すような要素と要素間の関係で表現できる。筆者らは、こうしたソフトウェア構造の複雑性を、関係の密度とその規則性で評価するモデル (Density and Regularity Model) を提案している[2]。図 3.1 ソフトウェア構造表 3.1 に階層毎の関係の種類と規則性を示す。このモデルの特徴は、ソフトウェア全体を統一的な観点で表現している点である。これによって、従来、想定していなかった新たな関係の種類図 3.2 要素と関係による階層のモデル化が現れたとき、どの階層に属するかモデル内にマッピングする表 3.1 階層別関係要素と種類、規則性ことができる。例えば、コードクローン[3] がソフトウェアの保守性に影響することが報告されているが、クローンは類似コードという意味で関係の一種であり、同一関 SQiPシンポジウム2009 数内のクローンなら関数の階層に、関数にまたがる場合はアーキテクチャの階層の関係となる。従来のように、ソフトウェアの複雑性に関するメトリックスを個別に扱うのでなく、共通モデル上で位置づけを明らかにすることで、総合的な評価が容易になる。以下の各項で階層毎の関係の種類を対象にバグの発生との相関について分析した結果について述べる。 3.2 文の複雑性文を構成するのはスペースで区切られた単語である。文は、例えば C 言語では、ラベル付き文、式文、選択文、繰返し文、分岐文に分類されるが、今回は、このうち式文の中の代入文を対象に複雑性と可読性との関係を分析する。代入文は演算子と変数や定数といったオペランドで構成されるため、演算子とその対象となるオペランド間の関係の数を文の階層の複雑度として評価する。図 3.3 に文(1)の構造を表現した例を示す。文(1)は 14 個の要素と 13 個の関係で構成されている。 x = ++a1 << a2 - a3 >> a4 - a5 / a6; -----------(1) 文の複雑度が可読性に与える影響を分析する目的で、図 3.4 に示すような実験を行い、11 名の被験者を 2 グループに分け、複雑な文と複雑でない文の解釈の正解率と所要時間を測定した。各グループに A タイプの複雑な文と B タイプの単純な文を混在して 5 問づつ割り当てることで、被験者の技術レベルの差が分析に影響しないように配慮した。なお、5 個以上の関係を包含する文を複雑な文としている。図 3.5 に複雑な文の例を、図 3.6 にそれを単純化した例を示す。図 3.3 文の要素と関係の表現例 An は複雑な文、Bn は An を単純化した文 [n=1～5] (協力：東京情報大学) 図 3.4 グループ構成と割り当てた問題図 3.5 複雑な文の例図 3.6 図 3.5 を単純化した文 SQiPシンポジウム2009 表 3.3 に測定結果を示す。予想表 3.3 文の複雑度と可読性の評価結果に反して、複雑な文の方が正解率が高く、平均所要時間が短かった。サンプルサイズが小さく、有意差まではいえないが、今回の試行では文の複雑度は可読性に影響しないという結論である。ただし、今回の実験では、可読性、すなわち正確に読むことができるか、という観点で複雑性の影響を調査したが、可読性と改造時の容易さは必ずしも一致しない可能性がある。図 3.5 に示した文を読むことはできても、これらの文に対して何らかの変更を行う場合、適度な大きさに分割されていた方が容易であることが考えられるが、そうした観点での分析は今後の課題である。 3.3 関数の関数の複雑性関数を構成するのは文である。文と文の論理的依存関係を測定して関数の複雑度とする。図 3.7 にネスト数が 2 の if 文の例を示す。文 a,b,c,y,d は if 文 x に論理的に依存し、文 d は if 文 y にも依存する。この 6 個の文で構成される関数は 6 個の関係を持っている。これは、分岐数にネスト数を考慮したメトリックスである。関数の複雑度がバグの発生に与える影響について、表 3.5 に示すような 1300Kstep 程度の比較的大規模な通信ソフトウェアの 2 つの機能追加プロジェクトを対象に分析した。該当プロジェクトの結合試験以降に発生したバグ数と関数に属する文の論理的関係の数の相関係数を表 3.6 に示す。この結果からは、関数の複雑度とバグ数との間には、さほどの相関はないことがわかる。表 3.5 評価対象の機能追加プロジェクトの属性表 3.6 関数の複雑度とバグ数の相関図 3.7 文の論理的関係の例 3.4 アーキテクチャのアーキテクチャの複雑性アーキテクチャの複雑性がバグの発生に与える影響について FB の複雑性と改造時のバグ数との相関関係を分析する。FB の複雑度を図 3.8 および以下に示す五種類の静的メトリックスで評価する。 ①FB 内の関数間インタフェース ②他 FB の関数へのインタフェース ③他 FB の関数からのインタフェース ④他 FB のデータへのアクセス ⑤他 FB から自 FB のデータへのアクセス図 3.8 アーキテクチャの複雑性メトリック SQiPシンポジウム2009 FB 毎の上記メトリック表 3.7 FB の複雑度とバグ数との相関スと表 3.5 の機能追加時のバグ密度との相関係数を表 3.7 に示す。この中では③の他 FB からのインタフェースとかなり高い相関が、また⑤の他 FB からのデータアクセスと弱い相関があることがわかる。 4. ソフトウェア改造時ソフトウェア改造時の改造時のバグ数予測バグ数予測モデル数予測モデル機能追加時に発生するバグは、図 4.1 の①の純粋に追加機能に閉じて発生するバグと、②の母体との関連で発生するバグに分類することができる。そのうち①は改造規模に比例して発生すると考えられる。一方、②は以下に示す(a)(b)(c)の要因に影響される。 (a)母体の複雑度母体の理解不足を招きバグの要因となる。 (b)母体と追加機能の関係密度母体が複雑でも、うまく母体をラッピングして追加機能部との関係を疎にできれば複雑さの影響をあまり受けない。 (c)母体規模と追加規模の比率追加規模の比率が一定以上なら、複雑さの影響をあまり受けない。図 4.1 機能追加時のバグ要因全体のバグ数は改造規模と(a)で述べた母体の複雑度の両方に比例すると考え、(2)式で予想できる。(脚注参照)† 予想バグ予想バグ数バグ数 = 係数 a＊改造規模 + 係数 b＊改造規模＊改造規模＊母体の母体の複雑度 -----------(2) -----------(2) 係数 a は同じ組織による新規開発時のバグ密度から、係数 b は改造時の母体の理解不足が原因のバグの比率から決定した。 (2)式の母体の複雑度として、3 章の分析結果から、アーキテクチャの複雑性メトリックスのうち、他 FB の関数からのインタフェースと他 FB から自 FB のデータへの書き込みアクセスを使用し、 (3)で示す式で評価する。(3)式の下線部では 2 種類のメトリックスの重みを同等に評価するため正規化している。母体の母体の複雑度= 複雑度=被 call+(被 call+(被 write*全被 write*全被 call/全被 call/全被 write) write) -----------------------(3) -----------------------(3) † 改造規模と母体の複雑度の両方に比例することについてはさらに検討が必要だが、一つの根拠として文献[4]で、プロジェクトを難易度(difficulty)で 2 分類し、COSMIC FFP の機能単位である Cfsu と工数の相関を取ると 0.67 であるのに対し、Cfsu と難易度の積を評価モデルに組み込むことで相関が 0.86 まで高まった、との報告がある。 SQiPシンポジウム2009 FB 単位で、(2)式で求められる母体の複表 4.1 予想バグ数との相関雑度を考慮した予想バグ数（以下、予想バグ数と呼ぶ）と表 3.5 で示すプロジェクトで実際に発生したバグ数との相関値を表 4.1 に示す。また、機能追加 B を対象に予想バグ数と実バグ数の関係を表 4.2 に、改造規模と実バグ数の関係を表 4.3 にそれぞれ散布図で示す。実バグ数と改造規模との相関よりも予想バグ数との相関の方が大きいことがわかる。表 4.3 改造規模と実バグ数の散布図 16 14 12 10 改造規模予想バグ数表 4.2 予想バグ数と実バグ数の散布図 8 6 4 2 0 (2) 0 5 10 15 実バグ数 20 25 1800 1600 1400 1200 1000 800 600 400 200 0 0 5 10 15 20 25 実バグ数 5. まとめ本稿ではソフトウェア構造の複雑度モデルに基づいて文、関数、アーキテクチャの階層ごとに複雑度がバグの発生に与える影響について分析した。文については、複雑な文と複雑でない文を被験者に解釈してもらうことで理解性を比較し、関数とアーキテクチャについては、2 つの機能追加プロジェクトで発生したバグ数と複雑度の相関を取った。この結果、文と関数については有意な差は認められなかったが、アーキテクチャ階層の 2 種類のメトリックスについて、一定の相関があることがわかった。さらに改造時のバグ数予測モデルに基づく実際のバグ数との相関が、改造規模と実際のバグ数との相関より大きいことを示した。ソフトウェア改造時、母体のどういった複雑性がバグの原因となりやすいかを分析し、改造が想定されるソフトウェア開発時に設計上の考慮すべき内容を明らかにすることで、開発効率や品質が改善できると期待している。今後はサンプルサイズを大きくすることで統計上の信頼性を上げるとともに、母体の複雑度に、母体と追加機能の関係密度や母体規模と追加規模の比率を考慮して相関値が高まるようにバグ数予測モデルを改善したい。 6. 参考文献 [1] SEC, “ソフトウェア改良開発見積もりガイドブック～既存開発がある場合の開発～”, オーム社,2007 [2] 中村, “依存関係の密度と規則性でモデル化したソフトウェアの複雑性評価”, 日科技連ソフトウェア品質シンポジウム 2008, PP.237～232 [3] 神谷, “CCFinderNexGen の開発”, http://www.ccfinder.net/doc/umemurapm-seikahoukokukai-presen-suusei.pdf [4] Alain Abran, “Estimation Models for Software Maintenance Based on Functional Size” The DoD Software TECH, September 2006 Vol.9 Number 3, http://www.informit.com/articles/printerfriendly.aspx?p=24371