| 審査対象 |
審査内容 |
審査の観点 |
モデルの
書き方 |
正確性 |
採用した表記法にしたがっているかを審査します。
※UML以外の表記法も可能。
|
表記法を正しく使って記述されているかを評価します。採用している表記法が一般的でない（例：ネット検索しても表記法の説明が見当たらない）場合は、表記法の説明資料を提示してください。提示がないと減点になります。
表記法に反した記述の有無を確認し、反した記述によって設計内容の理解を損なう個所が多いほど低い評価になります。
尚、表記法の説明資料を提示して頂いても、必要に応じて提示チームに対して確認を行うことがあります。
|
| 理解性 |
図の
見やすさ |
図を見ただけで理解しやすいかを審査します。
具体的には、以下のような内容を審査します。
| レイアウトは適切か |
| 要素数は適切か |
| 色分け等による可読性の向上 |
| 図が、印刷された段階で内容を読み取れる適切な大きさになっているか |
| 図が過度に書き込まれていないか |
|
印刷した段階で、図が読み取れる大きさになっているか、1ページに詰め込み過ぎていないか（例：ページあたり約10%以上の空白スペースがあるか）、見やすくするためにレイアウトを工夫しているかを評価します。
印刷しても読めないぐらい小さかったり（例：8ポイント未満の文字サイズ）、ド派手な色彩（例：サイケデリックな色合い）で読みにくくなっている場合などは、減点になります。
|
図の
補足 |
モデルをわかり易く伝えるように工夫しているかを審査します。
具体的には、以下の内容について、モデルの内容理解を助ける補足であるか、補足が過剰になっていないかを審査します。
| 【コンセプトシート】 |
| ・モデル全体の説明 |
| ・訴求ポイント |
| 【補足記述】 |
|
※補足記述とは、表記法以外で記述された（自然言語、図等）モデル内容の説明を指します。 |
| ・モデリング方針 |
| ・モデルの構成、各図についての説明 |
| ・アルゴリズムや戦略の解説 |
|
モデリング方針やモデルの構成説明など、モデルを理解するために役立つ内容が、的確に記述されているかを評価します。
モデルから読み取れる内容を文書で説明したり、モデルと補足で表現していることがずれていたりした場合は、減点になります。
|
| モデルの内容 |
設計モデル |
ソフトウェアとして、高品質な設計がなされているかどうかを審査します。
| |
| 機能 |
ソフトウェアが製品の利用者に対し、どのような機能を提供するかを記述してください。
※UMLでは、ユースケース図などが該当します。
具体的には、以下の内容を審査します。
具体的には、以下の内容を審査します。
| ・すべての機能が網羅されている。 |
| ・機能が妥当であること。 |
|
利用者から見て意味・価値のある内容かどうかを審査します。
以下は「妥当でない」場合の例です。
|
|
|
抽象的すぎて利用者視点になっていない。 |
|
|
詳細すぎて利用者視点になっていない。 |
| ・機能が多くなる場合は、グルーピングや階層化が実施されていること。 |
（注）本大会では、モデルの提出枚数に制限があるため、機能の詳細内容や想定されるシナリオすべての網羅などは必要ありません。
|
提供される機能が漏れなく記述されており、その表現にグルーピングや階層化などの工夫がなされているかを評価します。
提供される機能が不足していたり、不要な機能が書かれている場合は、減点になります。
|
| 構造 |
機能を実現するために必要な要素群を記述してください。
|
※UMLではクラス図やオブジェクト図などが該当します。 |
具体的には、以下の内容を審査します。
| ・すべての要素および要素間の関係が網羅されている。 |
| ・要素および要素間の関係が妥当であること。 |
|
要素は、「概念」、「責務」、「情報」、「関数」など使用される設計手法によって異なります。
いずれの手法においても、要素の「凝集度の高さ」、要素間の「結合度の低さ」が重視されます。 |
| ・要素が多くなる場合には、グルーピングや階層化が実施されていること。 |
|
※UMLではパッケージ図が該当します。 |
（注）本大会では、モデルの提出枚数に制限があるため、要素の詳細内容の記述は必要ありません。 |
機能を実現するために必要な構成要素が存在し、それらの構成要素間の関係（構造）が正当であるかを評価します。加えて構造が複雑にならない工夫がなされていると高く評価します。
構成要素が不足していたり、複雑な構成になっているのに対処されていなかったり場合は、減点になります。
|
| 振る舞い |
機能を実現するために必要な要素群の振る舞い、要素間の相互作用、要素内部の振る舞いを記述してください。
具体的には、以下の内容を審査します。
| 【要素群の振る舞い】 |
|
※UMLでは状態マシン図、アクティビティ図などが該当します。 |
|
・システム全体の振る舞いが記述されている。 |
|
・振る舞いが動作要件を満足していること。 |
| 【要素間の相互作用】 |
|
※UMLではシーケンス図、コミュニケーション図、タイミング図などが該当します。 |
|
・特定の機能に対する要素間の相互作用が記述されている。 |
|
・対象となる機能の実現可能性が判断出来ること。 |
| 【要素内部の振る舞い】 |
|
※UMLでは状態マシン図、アクティビティ図などが該当します。 |
|
・特定の要素に対し、要素内部の振る舞いが記述されている。 |
|
・振る舞いが妥当であること。 |
（注）本大会では、モデルの提出枚数に制限があるため、すべての機能に対する記述は必要ありません。 |
機能を実現するために、構造で取り上げた構成要素間がどのようなやり取りを行うのか、イベントに対してどのような振舞いを行うのかを評価します。加えて振舞いが複雑にならない工夫がなされていると高く評価します。
記述されている振舞いが実現不可能だったり、複雑すぎる場合は、減点になります。
|
| 性能モデル(※1) |
モデルから読みとれる予測性能について、その有効性を審査します。 |
|
| 要素技術 |
走行体制御に必要な要素技術を記述してください。
具体的には、以下の内容を審査します。
・デバイス要素技術(センサ、モータ)
・基本走行技術(走る/曲がる/止まる)
・自律性(ライントレース、自己位置推定)
倒立振子制御の拡張、通信制御、通信品質(非同期通信における冗長化対策など)確保、定番の光センサデータのノイズ処理、なども含まれます。
ライントレース制御や自己位置推定走行についても走行体の自律性を高める要素技術として審査します。 |
目標となる性能が書かれており、その目標を達成するために必要な要素技術が具体的に明示されているかを評価します。書かれている内容が根拠に基づいていると高い評価になります。
要素技術だけを示していたり、目標達成に必要な記述が揃っていなければ減点になります。
|
| 走行戦略 |
難所を含む走行戦略に対する性能を記述してください。
具体的には、以下の内容を審査します。
・走行戦略性能
・戦略技術の多様性/冗長性/リカバリー性
ベーシック・ステージや難所ボーナス・ステージに対する戦略について審査します。また、難所攻略時の冗長性や多様性、失敗時のリカバリ処理についても審査します。特に各難所攻略に対する戦略の共通化を意識した記述は高評価とします( = モデル/コードの共通化に繋がる)。
コースや難所の攻略方法だけでなく、競技中のBluetooth通信の活用方法など、走行方法を含めた走行戦略全般について審査します。
（開発中のBluetooth通信の活用方法は開発環境で審査します。） |
安定し素早く走行するための方法、難所の攻略方法、コース復帰に代表されるような不測の事態に対する対処方法が記載され、その内容が実現可能であり効果があるかを評価します。
実現方法が明示されていない、もしくは実現性に疑問が残る、本当に効果があるか分からない場合は、減点になります。
|
| トレーサビリティ |
"記述されたモデルの内容"が相互に参照・確認（追跡）が可能か、内容が一貫しており矛盾がないか、を審査します。具体的には、以下の項目間でのトレーサビリティを審査します。
・機能、構造、振る舞いのモデル図
・要素技術と走行戦略
・要素技術、走行戦略と構造、振る舞いのモデル図
・[要求モデルを記述した場合]要求モデルと他のモデル図
基本的には、記述されたモデル図がトレーサビリティの評価対象となりますが、機能、構造、振る舞いのいずれかの観点がモデル図として示されていない場合は、トレーサビリティがとれていないと見なします．
たとえば、以下のようなケースについては、トレーサビリティを満たせていない箇所があると判断します。
・設計モデルの機能、構造、振る舞いのいずれかの観点について、モデル図が示されていない。
・構造で記載されていない要素が、振る舞いの図に登場している。
・振る舞いで記述されている機能が、機能に表現されていない。
・走行戦略に記載されている走行方法と要素技術に関連性が見られない。
・要素技術で記述されている内容が、設計モデルの構造内のどの要素で反映されているかが分からない。
要求モデルを記述した場合は、要求モデルも含めてトレーサビリティの評価を行います。要求モデルを記述した場合は、例えば下記のようなケースについては、トレーサビリティを満たせていない箇所があると判断します。
・要求モデルで記載されている要求と、設計モデルで記載される機能の間に関連性が見られない。
・要求モデルで記載されている要求と、要素技術や走行戦略との間に関連性が見られない。
|
モデル間のつながりが分かり、そのつながりが一貫しているかどうか、つながりが双方向にたどれるか、つながりが妥当であるかを評価します。
モデル間につながりがなかったり、間違ったつなぎになっている場合は、減点になります。
|
| 追加課題 |
要求モデル |
製品やソフトウェアに対する要求が、把握されているかどうかを審査します。
具体的には、以下の内容を審査します。
・設計モデルで記述された機能を導出するに至った経緯(どのような要求が存在し、どの要求をシステムで実現するかを決定したのか)が記述されていること
・機能的な要求や、品質、性能といった非機能的な要求が検討の過程およびその結果が、記述されていること |
なぜこの機能が必要なのか（機能要求）、なぜこの性能を達成する必要があるのか（非機能要求）といった根拠とが記述されていると加点します。
記述されている内容が妥当であり、機能と非機能の要求を両方とも記述している場合は、高く評価します。
|
| 並行性設計 |
並行性設計に対する検討がなされていると判断された場合、その設計指針と設計内容の妥当性を審査します。
※並行性設計の検討を行った場合は、その旨をモデルの冒頭で記載するとともに、具体的な設計指針、設計内容についても分かりやすいように示してください（丸で囲う、アイコンを付ける等）。"
|
|
| 設計指針 |
どのような指針で並行性設計を実施したかを記述してください。
具体的には、以下の内容を審査します。
| 【並行性に対する要求と、その理由】 |
|
・要求として、並行動作が必要ないと判断されるケースもあり得ます。その際には、必要でないと判断した理由も記述してください。 |
| 【要求を実現するために、採用したアプローチ方法】 |
|
・後述する設計内容の元になった考え方・設計上のポイントを示してください。 |
|
並行性設計の必要の有無を、理由も含めて記述されている場合は、加点になります。
設計のアプローチ方法（設計指針）が検討され、その内容が理にかなっていれば高く評価します。 |
| 設計内容 |
意図した並行性を実現するために必要な要素群（構造面）と、それらの振る舞い（振る舞い面）を記述してください。
具体的には、以下の内容を審査します。
| 【構造面】 |
|
・実行単位を定義していること。 |
|
|
実行単位とは並行動作する単位のこと。
※一般的には、スレッド、プロセス、もしくはタスクと呼ばれる。 |
|
・実行単位および実行単位間の関係が、妥当であること。 |
| 【振る舞い面】 |
|
・実行単位間の相互作用 |
|
|
並行動作の実行単位間の相互作用が記述されていること。 |
|
・実行単位内部の振る舞い |
|
|
実行単位の内部の振る舞いが記述されていること。 |
|
並行性設計の内容が、構造と振舞いのモデルで表現されていると加点されます。
構造は、タスク（もしくはスレッド）構成が記述されており、その内容がモデルに反映されていると高く評価します。
振舞いは、タスク間の協調動作が表現されている、その内容がモデルに反映されていると高く評価します。 |
| 開発支援(※1) |
分析/設計/実装/計測/検証等の開発支援において、ソフトウェアの品質及び開発効率を向上させるための手段や方法について審査します。
各チームにおける開発に関する課題が明確に示されており、その課題に対して効果的な開発支援がなされているかを評価します。 |
開発効率、品質向上に対する開発環境を適用している場合は加点になります。
開発環境を利用したことで効果が出ていることが分かるエビデンス（証拠）がある場合は、高く評価します。
複数の開発工程で効果を生む開発環境を構築（例：設計ツールと計測ツールを組合わせてテスト駆動開発を実現）した場合は、更に高く評価します。
|
| オリジナリティ(※1) |
モデルの記述内容から、新しい試みや日常の開発で出来ないことにチャレンジし、それが有効であったと判断された場合には、オリジナリティとして加点を行います。 |
過去に使われたことのない独創てなアイディアや今まで行っていなかったようなチャレンジを盛り込んでいる場合は、加点されます。
その内容が効果を生んでいるのであれば、高く評価します。
尚、過去に使われたかどうかは、審査員が過去の大会の公開情報に基づいて判断します。
|
| ※１ETロボコンは、組み込みソフトウェア開発全般におけるスキル向上を目的としています。
ソフトウェアのモデリング技術に加え、性能、開発支援、オリジナリティなどの内容も客観的に評価するために、審査対象として扱っています。 |
