ETロボコン2011 九州大会 コード品質評価プロジェクト (SCQR2011)

Presentation on theme: "ETロボコン2011 九州大会 コード品質評価プロジェクト (SCQR2011)"— Presentation transcript:

1 ETロボコン2011 九州大会 コード品質評価プロジェクト (SCQR2011)
九州大会特別企画！ 今年もやったのです！ ETロボコン2011 九州大会 コード品質評価プロジェクト (SCQR2011) 今年のテーマ ～“清く、正しく、美しく ”～ 企画：QUEST（九州組込みソフトウェアコンソーシアム) 2011/9/4　やっぱり今年も暑かった･･･

2 目次（あらすじ） 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察
網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

3 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

4 去年からのあらすじ ・・・というところから、 昨年は“ミンナにやさしいソースコード” というテーマでレビューをしました。 モデル審査
組込みソフトウェア の総合品質 設計品質 コード品質 性能品質 基本だし。 走行タイム ココ、ないね・・・ では、評価しますか。 命かけてるし。 ・・・というところから、 　　昨年は“ミンナにやさしいソースコード” 　　　　というテーマでレビューをしました。

5 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

6 今年の着目点 “ミンナにやさしいソースコード” と言ったはいいが、何をすると“ミンナにやさしく”なるのかを
　と言ったはいいが、何をすると“ミンナにやさしく”なるのかを 　今年は噛み砕いて、テーマにしてみました。 　それが、 　　・清く（元々のコンセプト＜モデル＞が反映している） 　　・正しく（複雑度を上げず、色々なことを考慮している） 　　・美しく（正しいコメント、分かりやすいコメント） 　です。

7 今年の着目点 (*≧∇≦)/ 参加いただいたチームの皆さん！ です。 今年は、皆さんの“清く・正しく・美しく”を評価させて頂きました。
参加いただいたチームの皆さん！　です。 今年は、皆さんの“清く・正しく・美しく”を評価させて頂きました。 TeamNo. Team Name 言語 133 スーパーHTSくん cpp 202 流し満貫 32 Ｎｏｂｕ３ＳＷ（Ｒ） c 273 Y研ロボ ひびきの 176 チキン南蛮 257 コアファイター 参加 ありがとうございました！ ぱちぱちっ！ (*≧∇≦)/ （複雑でないことが良いのです。） （UMLに基づいたアーキテクチャ違反がないこと） （重複したロジックはないですか？） 評価した人： 　片平性能審査団員、 　松下性能審査団員

8 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

9 評価基準 静的解析ツールによる評価 目視（網膜→脳）による評価 ★ｃ言語： QACによる解析結果の総合品質得点 ★c++言語：
使用ツール： 目視（網膜→脳）による評価 パッケージ分割の視点 （アーキテクチャ設計）、ファイル分割の視点（コンポーネント設計）、関数分割の視点（ファンクション設計）、コーディングの視点（コーディングスタイル）のスコープに分割し、各スコープを評価するメトリクスで品質を診断 ・構成（機能、戦略、データなどがキチンとまとめられているか？） ・見易さ（解読容易性）・・・コメントの適正さ、ソース構造の分かりやすさ ・戦略的対応（難所攻略・コース戦略） 　　　　　　　　　　　　　　　　　　　　　　　　　　　　使用ツール：評価委員の網膜と脳

10 評価基準(細目) 静的解析ツールによる評価 目視（網膜→脳）による評価 ・障害に繋がる指摘数（減点項目）
・複雑度（加点項目…複雑度が低いほうが良い） ・最大ネスティング数（加点項目・・・数が少ないほうが良い） 　ツールによる評価点＝減点項目＋加点項目 静的解析ツールによる評価 ・構成（基本評価項目１〜５） ・ソースコメント（基本評価項目１〜５） ・戦略的アルゴリズム（基本評価項目１〜５） ・難所攻略（加点項目０〜３） 　目視による評価点＝基本評価項目＋加点項目 目視（網膜→脳）による評価

11 評価基準(表彰内容) 評価基準 　　今年は、ｃ言語、ｃ＋＋言語部門、 　　と言語ごとに総合点の高いチームを 　　表彰します。

12 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

13 解析ツールで評価すると・・・ Ｃの場合（QAC） 指数化、発見数などがクラス毎などで 数値化されます。

14 警告の内容を、警告別にhtml(txt)表示できます。
解析ツールで評価すると・・・ Ｃ＋＋の場合（QAC++） 警告の内容を、警告別にhtml(txt)表示できます。

15 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

16 ツール解析結果から見える考察 今年は、昨年と違う非常に面白い傾向が見られました。
　　ツールにおいては、“正しく”=障害指摘数、“美しく”=複雑さ、煩雑さを主に見ましたが、ソースコードのボリュームと反比例し、記述内容が多いチームほど、“正しく、美しく”記述されているという傾向が見られました。よく考えているチームほどよく整理されている、という本来あるべき姿といえます。

17 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

18 網膜から見える背景（解読容易性） 今年は、見やすさだけでなく、いかに“考えぬいているか”も評価の対象にしました。
難所攻略やコース戦略性などソースコードから読み取れる“思慮”を読み取ることにしました。そうすると非常に面白い結果が出てきました。 結果からいうと“清く（思慮深い）” （戦略的・難易度が高い）ソースほど、キチンと整理されている、という傾向が現れています。

19 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

20 総合レビュー結果から見えてくること 今年の総合レビューでは、評価する側から見ると、とても嬉しい結果になっています。
　　それは、熟慮を重ね、新しいコト・難しいコトにチャレンジしたチームほど、 　　　　“清く・正しく・美しく” 　ソースを書いているという事実です。 ※ツール高評価のチームは目視も高評価

21 去年からのあらすじ 今年の着目点 評価基準 解析ツールで評価すると・・・ ツール解析結果から見える考察 網膜から見える背景（解読容易性） 総合レビュー結果から見えてくること 評価結果っ！！！

22 評価結果っ！！！ では、いよいよ、 ・金賞（ｃ＋＋言語部門） ・金賞（ｃ言語部門） の発表をします！

23 ですっ！ 評価結果っ！！！ ・金賞（ｃ＋＋言語部門）は、 “スーパーHTSくん“ さん 所感： 総合得点４８点
　　　　　　　　　　　　　　ですっ！ 所感：　総合得点４８点 　ツール評価・目視評価とも高得点でした。目視で確認した難易度の高いアルゴリズムも、ツールで確認した複雑度やネスティング回数などで、複雑すぎないようにキチンと整理されていることが伺えます。

24 ですっ！ 評価結果っ！！！ ・金賞（ｃ言語部門）は、 “Ｎｏｂｕ３ＳＷ（Ｒ）”さん 所感： 総合得点４４点
　“Ｎｏｂｕ３ＳＷ（Ｒ）”さん 　　　　　　　　　　　　　　ですっ！ 所感：　総合得点４４点 　ツール評価・目視評価とも高得点でした。目視での確認では全ての難所に対して攻略が記述され、なおかつ、考えぬいた戦略が伺えました。またファイル・フォルダ構成、ソースコメントなど、分かりやすさを優先していてお手本的なソースコードといえます。

25 評価結果っ！！！ ・総評 今年の評価では、ツール評価と目視評価において、相関関係がみられました。
　　今年の評価では、ツール評価と目視評価において、相関関係がみられました。 　　受賞したチームはともに評価が高く、難所攻略やコース戦略を考慮しソースの難易度・複雑度は本来、高くなるはずですが、キチンと整理されていることが分かります。 　　“見られる“ことを意識したのかはわかりませんが、コーディングという技術として考えた場合、難しい事を整理しながら解決していった事が見て取れます。評価の低いチームはにも逆の相関性が見られ、典型的な”書き散らし”が見て取れました。

26 最後に、ちょっと、オマケ・・・　　ーー；

27 SCQRの未来・・・ 今後、MBD,MDDが定着していくと、ソフトウェア開発体制には、“モデラー、モデル・クリエーター”という階層が出来ていくと思われます。今、我々がSE,PGと呼んでいる職業のちょうど中間なのかもしれません。　MBD,MDDが普及し浸透していくと、ソースを書く（修正）するという作業は開発作業全体からみれば少なくなっていくでしょう。　このレビュー自体の意味が重要視されなくなり、淘汰されいく未来が我々の望む未来なのかもしれません。　 UMLからカリカリ書いてたなぁ・・・、ソースコード・レビューなんてやってたよねぇ、ETロボコンで・・・、なんて時代に早くなるといいと思ってたりしてます。（そうならなきゃ、いけないんだけどさ・・・）

28 SCQR2011に参加いただいたチームの皆さん、ありがとうございました。
表彰されたチームの皆さん、おめでとうございました！ また、来年の猛暑の夏に、 　　　熱いソースコードお待ち申し上げます。　 おしまい。　Ｍ（＿＿）／