| 審査対象 |
審査内容 |
モデルの
書き方 |
正確性 |
採用した表記法にしたがっているかを審査します。
※UML以外の表記法も可能。
|
| 理解性 |
図の
見やすさ |
図を見ただけで理解しやすいかを審査します。
具体的には、以下のような内容を審査します。
| レイアウトは適切か |
| 要素数は適切か |
| 色分け等による可読性の向上 |
| 図が、印刷された段階で内容を読み取れる適切な大きさになっているか |
| 図が過度に書き込まれていないか |
|
図の
補足 |
モデルをわかり易く伝えるように工夫しているかを審査します。
具体的には、以下の内容について、モデルの内容理解を助ける補足であるか、補足が過剰になっていないかを審査します。
| コンセプトシート |
|
・モデル全体の説明 |
|
・訴求ポイント |
| 補足記述 |
|
※補足記述とは、表記法以外で記述された（自然言語、図等）モデル内容の説明を指します。 |
|
・モデリング方針 |
|
・モデルの構成、各図についての説明 |
|
・アルゴリズムや戦略の解説 |
|
| モデルの内容 |
設計モデル |
ソフトウェアとして、高品質な設計がなされているかどうかを審査します。
|
| 機能 |
ソフトウェアが製品の利用者に対し、どのような機能を提供するかを記述して
ください。
具体的には、以下の内容を審査します。
| ・すべての機能が網羅されている。 |
| ・機能が妥当であること。 |
|
利用者から見て意味・価値のある内容かどうかを審査します。
以下は「妥当でない」場合の例です。
|
|
|
抽象的すぎて利用者視点になっていない。 |
|
|
詳細すぎて利用者視点になっていない。 |
| ・機能が多くなる場合は、グルーピングや階層化が実施されていること。 |
（注）本大会では、モデルの提出枚数に制限があるため、機能の詳細内容や想定されるシナリオすべての網羅などは必要ありません。
|
| 構造 |
機能を実現するために必要な要素群を記述してください。
|
※UMLではクラス図やオブジェクト図などが該当します。 |
具体的には、以下の内容を審査します。
| ・すべての要素および要素間の関係が網羅されている。 |
| ・要素および要素間の関係が妥当であること。 |
|
要素は、「概念」、「責務」、「情報」、「関数」など使用される設計手法によって異なります。
いずれの手法においても、要素の「凝集度の高さ」、要素間の「結合度の低さ」が重視されます。 |
| ・要素が多くなる場合には、グルーピングや階層化が実施されていること。 |
|
※UMLではパッケージ図が該当します。 |
（注）本大会では、モデルの提出枚数に制限があるため、要素の詳細内容の記述は必要ありません。 |
| 振る舞い |
機能を実現するために必要な要素群の振る舞い、要素間の相互作用、要素内部の振る舞いを記述してください。
具体的には、以下の内容を審査します。
| 要素群の振る舞い |
|
※UMLでは状態マシン図、アクティビティ図などが該当します。 |
|
・システム全体の振る舞いが記述されている。 |
|
・振る舞いが動作要件を満足していること。 |
| 要素間の相互作用 |
|
※UMLではシーケンス図、コミュニケーション図、タイミング図などが該当します。 |
|
・特定の機能に対する要素間の相互作用が記述されている。 |
|
・対象となる機能の実現可能性が判断出来ること。 |
| 要素内部の振る舞い |
|
※UMLでは状態マシン図、アクティビティ図などが該当します。 |
|
・特定の要素に対し、要素内部の振る舞いが記述されている。 |
|
・振る舞いが妥当であること。 |
（注）本大会では、モデルの提出枚数に制限があるため、すべての機能に対する記述は必要ありません。 |
| 性能モデル |
モデルから読みとれる予測性能について、その有効性を審査します。 |
| 要素技術 |
走行体制御に必要な要素技術を記述してください。
具体的には、以下の内容を審査します。
・デバイス要素技術(センサ、モータ)
・基本走行技術(走る/曲がる/止まる)
・自律性(ライントレース、自己位置推定) |
| 走行戦略 |
難所を含む走行戦略に対する性能を記述してください。
具体的には、以下の内容を審査します。
・走行戦略性能
・戦略技術の多様性/冗長性/リカバリー性 |
| トレーサビリティ |
"記述されたモデルの内容"が相互に参照・確認（追跡）が可能か、内容が一貫しており矛盾がないか、を審査します。具体的には、以下の項目間でのトレーサビリティを審査します。
・機能、構造、振る舞いのモデル図
・要素技術と走行戦略
・要素技術、走行戦略と構造、振る舞いのモデル図
・[要求モデルを記述した場合]要求モデルと他のモデル図
基本的には、記述されたモデル図がトレーサビリティの評価対象となりますが、機能、構造、振る舞いのいずれかの観点がモデル図として示されていない場合は、トレーサビリティがとれていないと見なします。
たとえば、以下のようなケースについては、トレーサビリティを満たせていない箇所があると判断します。
・設計モデルの機能、構造、振る舞いのいずれかの観点について、モデル図が示されていない。
・構造で記載されていない要素が、振る舞いの図に登場している。
・振る舞いで記述されている機能が、機能に表現されていない。
・走行戦略に記載されている走行方法と要素技術に関連性が見られない。
・要素技術で記述されている内容が、設計モデルの構造内のどの要素で反映されているかが分からない。
要求モデルを記述した場合は、要求モデルも含めてトレーサビリティの評価を行います。要求モデルを記述した場合は、例えば下記のようなケースについては、トレーサビリティを満たせていない箇所があると判断します。
・要求モデルで記載されている要求と、設計モデルで記載される機能の間に関連性が見られない。
・要求モデルで記載されている要求と、要素技術や走行戦略との間に関連性が見られない。
|
| 追加課題 |
要求モデル |
製品やソフトウェアに対する要求が、把握されているかどうかを審査します。
具体的には、以下の内容を審査します。
・設計モデルで記述された機能を導出するに至った経緯(どのような要求が存在し、
どの要求をシステムで実現するかを決定したのか)が記述されていること
・機能的な要求や、品質、性能といった非機能的な要求が検討の過程およびその結果が、記述されていること |
| 並行性設計 |
並行性設計に対する検討がなされていると判断された場合、その設計指針と設計内容の妥当性を審査します。
※並行性設計の検討を行った場合は、その旨をモデルの冒頭で記載するとともに、具体的な設計指針、設計内容についても分かりやすいように示してください（丸で囲う、アイコンを付ける等）。"
|
| 設計指針 |
どのような指針で並行性設計を実施したかを記述してください。
具体的には、以下の内容を審査します。
| 並行性に対する要求と、その理由 |
|
・要求として、並行動作が必要ないと判断されるケースもあり得ます。その際には、必要でないと判断した理由も記述してください。 |
| 要求を実現するために、採用したアプローチ方法 |
|
・後述する設計内容の元になった考え方・設計上のポイントを示してください。 |
|
| 設計内容 |
意図した並行性を実現するために必要な要素群（構造面）と、それらの振る舞い（振る舞い面）を記述してください。
具体的には、以下の内容を審査します。
| 構造面 |
|
・実行単位間の相互作用 |
|
|
実行単位とは並行動作する単位のこと。
※一般的には、スレッド、プロセス、もしくはタスクと呼ばれる。 |
|
・実行単位および実行単位間の関係が、妥当であること。 |
| 振る舞い面 |
|
・実行単位間の相互作用 |
|
|
並行動作の実行単位間の相互作用が記述されていること。 |
|
・実行単位内部の振る舞い |
|
|
実行単位の内部の振る舞いが記述されていること。 |
|
| 開発支援 |
分析/設計/実装/計測/検証等の開発支援において、ソフトウェアの品質及び開発効率を向上させるための手段や方法について審査します。
各チームにおける開発に関する課題が明確に示されており、その課題に対して効果的な開発支援がなされているかを評価します。 |
| オリジナリティ |
モデルの記述内容から、新しい試みや日常の開発で出来ないことにチャレンジし、
それが有効であったと判断された場合には、オリジナリティとして加点を行います。 |
