1. はじめに 当WEBマガジンの2010年9月号で、組み込みソフトウェア開発におけるソースコード品質評価方法を紹介しました。 今回の記事から数回に渡り、この品質評価方法を使ってETロボコンのソースコードを評価した結果やモデル品質との関係などを紹介していきます。 2. ETロボコンとは ETロボコンは、組み込みソフトウェアエンジニアの育成を目的として毎年開催されているコンテストです。 ETロボコンは、その前身となるUMLロボコンが2002年に始まって以降、順調に参加チームを増やし、2010年大会では全国350チームが参加する大規模なコンテストに成長しました。 2010年大会では、全国を10地区に分けて9月から10月にかけて地区大会を行ない、そこで良い成績を収めた40チームが12月1日のチャンピオンシップ大会で戦います。 コンテストでは、黒いラインが描かれたコース上をロボットに走行させ、そのタイム(走行性能)を競うだけではなく、ソフトウェアの設計内容を記述したモデルを審査し、その品質(設計品質)の良し悪しも競います。これにより、走行結果のような利用者視点の品質だけでなく、ソフトウェアの作り方や成果物の品質といった開発者視点の品質に対する教育の機会となっています。 さらに、ETロボコンのユニークな点として、走行体となるロボット(メカ、ハード両方)が全てのチームで共通であることが挙げられます。つまり、純粋にソフトウェアのみの良し悪しを競うコンテストというわけです。 ETロボコンの競技規約やモデル審査基準は公式サイトに掲載されていますので、興味のある方はご覧ください。 3. ETロボコンにおけるソースコード品質評価の実施 ETロボコンは、走行性能だけでなく、モデルによる設計品質も評価する点で非常にユニークなのですが、ロボットに組み込まれる唯一の成果物であるソースコードに関しては評価対象外となっています。 図 1 ETロボコンにおける評価対象
組み込みソフトウェアエンジニアの育成という観点からすると、ソースコード品質までを評価し、参加者が開発上流から下流まで全ての成果物品質を高める動機づけとなれば、コンテストの価値が一層高まると当社は考えました。 そこで、当社はETロボコンの東京地区実行委員会と関西地区実行委員会の協力を得て、これら地区の独自企画として、希望者を対象にソースコード品質評価を実施しました。それでは、ソースコード品質評価結果、そしてモデルとソースコードの品質トレーサビリティを考察した結果を見ていきましょう。 4. ETロボコンソースコードの品質評価結果 ソースコードは地区大会前と地区大会後に分けて募集しました。今回は、地区大会前に応募のあったチーム(全10チーム)の評価結果を紹介します。10件のプロジェクトそれぞれの地区とプログラム言語の内訳は以下の表のとおりです。 表1.地区とプログラム言語の内訳(地区大会前募集)
評価したソースコードの規模は以下の表のとおりです。 表2.ソースコードの規模(地区大会前募集分)
全体的にコンパクトな規模に収まっています。 次に、品質評価結果を紹介します。 品質評価は、C/C++向けソースコード品質評価ツールAdquaを使用して行ないました。 このツールは、以下の図のように、評価する品質特性(信頼性、効率性、保守性、移植性、再利用性)ごとに、品質特性を構成する概念を段階的に分解して評価するアプローチを採用しています。 図 2 ソースコード品質評価の仕組み
評価方法の詳細は本記事の冒頭で記した過去記事に掲載していますので、興味のある方はご覧ください。 品質評価結果は以下の図のとおりです。 図 3 品質評価結果(地区大会前募集分)
この図は、品質特性ごとの良し悪しを偏差値で表現しています。偏差値は、Adquaで過去に評価した100超の実開発プロジェクトの評価結果に基づいて算出したものです。 この結果を見ると、ほとんどのプロジェクトが平均点(つまり偏差値50)を上回る結果となっており、概ね良好な品質を確保できていると言えそうです。 読者の中には、エンジニア育成を目的としたコンテスト向けに開発されたソースコードの品質の方が、実製品向けに開発されたソースコードの品質よりも良いことに違和感を覚える方がいらっしゃるかもしれません。 ETロボコンのソースコードの品質が相対的に高い理由は、プロジェクトの性質の違いにあると考えられます。ETロボコンのプロジェクトと実開発プロジェクトの間で、明確な違いとして挙げられるのは、プロジェクトの規模です。 ETロボコンのソースコードは、その規模が全体を見通せる程度に収まっており、ソースコード修正に伴う品質劣化が起きにくいため、高い品質が保たれているものと考えられます。一方、多くの実開発プロジェクトではソフトウェアの大規模/複雑化が進み、全体を見通すことや理解することが困難になっています。 さらに、実開発プロジェクトは、このような状況で派生開発や不具合対応に伴う修正が繰り返されます。その結果、設計やソースコードの理解が不十分な状態での修正が蓄積され、品質が劣化するケースが多いものと考えられます。 このように、今回の評価結果では、ETロボコンのようなコンパクトなプロジェクトとの対比によって、実開発プロジェクトが抱える問題点を再認識できた、という見方もできそうです。 5. モデル品質とソースコード品質の関係 前述のとおり、ETロボコンでは、各チームからソフトウェアの設計内容を記述したモデルが提出されます。 このモデルの品質とソースコードの品質を比べることで、モデル品質とソースコード品質の関係を分析することができます。 分析の仕方は色々ありますが、今回は、ある1つのプロジェクト(以下、Xプロジェクトとします)について、モデルとソースコード品質評価結果を比較した例を紹介します。 まずXプロジェクトの品質についてですが、以下の図のように、モデル、ソース共に高い水準といえるものでした。 図 4 Xプロジェクトのモデル品質とソースコード品質
つまり、Xプロジェクトは、モデル品質の良さがソースコード品質の良さに繋がっているお手本のような例といえます。
しかし、以下の図のように、ソースコード品質の副特性のレベルまで見ていくと、安定性が低いという問題があることがわかりました。 図 5 Xプロジェクトの品質副特性(一部抜粋)
安定性は、ある要素が他要素の変更の影響を受けにくいようになっているかを表すもので、実装する前の設計で確保しておくべき品質特性と考えられます。従って、まずは設計モデル上で安定性を低下させる要因があるか否かが気になるところです。 Xプロジェクトの設計モデル(パッケージレベル)を以下の図に示します。 図 6 Xプロジェクトの設計モデル(パッケージレベル)
設計モデルでは、レイヤが意識されており、要素間の依存関係が最小限に抑えられています。少なくとも安定性に問題のある設計ではなさそうです。 そこで、安定性は実装時に低下したものと推測しました。そのことを確認するために、Xプロジェクトの設計モデルとソースコードからリバースしたモデル同士を比較してみます。 図 7 設計モデルとソースコードからリバースしたモデルとの比較
ソースコードからリバースしたモデルを見ると、設計で想定していない依存関係が存在しており、それらの中にはレイヤを飛び越えた依存関係も含まれていることがわかりました。 このように実装で独自に追加した依存関係が、安定性の低下に結びついたと考えられます。 では、設計通りに実装できていれば高い安定性を実現できたのでしょうか。 そのことを検証するために、以下の図のようなコンセプトでソースコードを修正しました。 図 8 ソースコード修正のコンセプト
修正したソースコードを再評価した結果は以下のとおりです。 図 9 ソースコード修正後の品質評価結果
設計通りに実装することで、高い安定性を実現できたことがわかります。 最後に、Xプロジェクトにおけるモデルとソースコードの比較例から得られた知見をまとめておきます。 - 設計で想定していない要素間の関係を実装すると、設計で確保した品質を低下させる
→ 設計で確保した品質を維持するためには、設計と実装を乖離させないことが大切 - ソースコードを評価することで、設計と実装の乖離を見つけることができる
→ 良い設計であれば、実装を設計通りに修正するだけで品質の向上が期待できる
次回は、大会後に募集したソースコードの品質評価結果について分析した内容を紹介する予定です。 *本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。 |