南関東大会特別賞評価

(1)

ミス・ユースケースの利活用

非機能要件から得られたリスク対応のモデル化

2010年12月 2日

南関東地区大会審査委員長

アンリツエンジニアリング株式会社

林啓弘

(2)

概要



ETロボコンのモデルにみる要求分析で

非機能要件や外乱等について列挙されて

いますが、列挙された当該課題の対策を

行うにあたって、どこでどのように対応して

いるかを文字列で表明されています。



ユースケースを拡張したミス・ユース

ケースを利活用して、モデル図上に「課題

対策」を表明してみませんか。

分かりづらいものも

お誘い

(3)

*日本工業標準調査会移植性標準適合性置換性共存性設置性 portability ある環境から他の環境に移すためのソフトウェア製品の能力。備考：環境には組織、ハードウェア又はソフトウェアの環境を含めてもよい。環境適応性移植性保守性標準適合性試験性安定性変更性 maintainability 修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、又は環境の変化、要求仕様の変更及び機能仕様の変更にソフトウェアを適応させることを含めてもよい。解析性保守性効率性標準適合性資源効率性 efficiency 明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力時間効率性効率性使用性標準適合性魅力性運用性習得性 usability 指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力理解性使用性信頼性標準適合性回復性障害許容性 reliability 指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力成熟性信頼性機能性標準適合性セキュリティ相互運用性正確性 functionality ソフトウェアが、指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力合目的性機能性説明副特性特性ソフトウェアの品質特性 (JIS X 0129-1)

ソフトウェアの品質特性 (JIS X 0129-1)

非機能要求から実装可能

なアーキテクチャを設計し、

技術的な機能仕様書に具

体化する。

非機能要求が、あいまい

になっている場合は、不足

している基礎情報を調査し、

事例や専門家の経験も活

用して明示的に洗練する。

非機能要求が、前提の多

い仮説になっている場合は、

技術的なリスクとして管理し、

エンジニアリング活動を行う。

引用引用要求工学・設計開発技術研究部会要求工学・設計開発技術研究部会非機能要求とアーキテクチャ非機能要求とアーキテクチャWGWG 2007 2007年年88月月

要素技術などに記載されています

(4)

ソフトウェアの品質特性 (JIS X 0129-1)

非機能要求から実装可能な

アーキテクチャを設計し、技

術的な機能仕様書に具体化

する。

非機能要求が、あいまいに

なっている場合は、不足して

いる基礎情報を調査し、事例

や専門家の経験も活用して

明示的に洗練する。

非機能要求が、前提の多い

仮説になっている場合は、技

術的なリスクとして管理し、エ

ンジニアリング活動を行う。

引用引用要求工学・設計開発技術研究部会要求工学・設計開発技術研究部会非機能要求とアーキテクチャ非機能要求とアーキテクチャWGWG 2007 2007年年88月月

ここは？

粒度が適切ならば

ユースケースで表明。

ユースケースでの表明が不適切ならば、

ユースケース記述で表明

(5)

ソフトウェアの品質特性 (JIS X 0129-1)

非機能要求から

リスク因子を導出されているチームも・・・

リスク対応する？対応するならば、その影響は、どのユース

ケースに・・・

？新たなリスクを生んでいないか？

どうやって判断する？

フェールセーフ設計

自家保険

キャプティブ

保険・共済・基金

危険の

転嫁

_{危険の相殺}

危険の結合

危険の制限

危険の分散

危険の準備

危険の

保有

リスク・

ファイナンス

危険の防止

危険の

除去

危険回避は危険を伴う

活動をしないこと

危険の

回避

リスク・

コントロール

ミスユース

ケース

ネガティブ・

アクター

(6)

ミスユースケース

ユースケースA

ミスユースケースA

ユースケースAの

脆弱な処理を緩和する

脅威

<<

threaten

>>

緩和

<<

mitigate

>>

アクター

ネガティブ

アクター

Include や extend

ユースケースAの

脆弱な処理を緩和する

ミスユースケース

：人またはエンティティによって、システムに損害を与える実行

可能なアクションの集まり。

ネガティブアクター

：ミスユースケースを開始するアクター。

これは意図的または

不注意によるもの。

（

ミスユーザ

）

(7)

ミスユースケース

ユースケースA

ミスユースケースA

ユースケースAの

脆弱な処理を緩和する

拡張点：ｘｘｘｘｘ

脅威

<<

threaten

>>

緩和

<<

mitigate

>>

アクター

ネガティブ

アクター

ユースケースBの

脆弱な処理を緩和する

<<include>>

緩和

<<

mitigate

>>

ミスユースケースB

<<include>>

脅威

<<

threaten

>>

<<extend>>

新たなリスクを生んでいないか・・・

(8)

ミスユースケース記述



ミスユースケース名称



概要



基本パス



代替パス



緩和（軽減）ポイント



拡張ポイント



トリガー



前提条件



仮定



軽減の保証



潜在的なミスユーザのプロファイル



ステークホルダーと脅威

ミスユースケース記述の方法は

₂

通り

軽量化記法

通常のユースケース記述に

「

脅威

」の項目を付加します。

ミスユース

ケース主体で

記載する

(9)



３Ｄ難所が脅威の対象になる

ＥＴロボコンの３Ｄ難所

シーソー

階段

シーソーから降りたときに

シーソーに後ろから跳ね飛ばされる

板上のラインを見失う

衝突して転倒する

降りた後、ラインを見失う

試走会を

見ていて

(10)



光センサに影響を与えるものが脅威対象になる

その他の脅威

太陽光

照明

走行に影響をあたえる

コース（ライン）を見失う

光センサ値の変動が大きく

会場では制限

されている

カメラのフラッシュ

電池

緩和策

まいまい式

ローパスフィルタ

(11)

様々な分析手法

９ その他／昨年振返り

０ アナロジー／メタファー

４ （対象）その他戦略

５ （対象）コース戦略

５ リスク分析

２ システム分析

３ 要求分析

３ ドメイン分析

１ ロバストネス分析

１ 構造化分析

１１ ソフトウェア品質特性／非機能要件

２ ミスユースケース分析

４ ユースケース分析

４ ゴール指向分析

６ フィーチャ分析

０ フィッシュボーン

２０ マインドマップ

チーム数

分析方法等

ＨＡＳＨＵＦＯ

79 ＮｉＡＳＥＴ

264 逆襲のＲ−ＧＲＡＹ

253 ＳｔｒａｙＣａｂ０５

174 ＳＯＲＯＴ

152 チームＨＵＬＡパンダ

74 ひものエンベダーズ

56 クラっちＷＩＮ

33 ＨＥＬＩＯＳ

28 ビバリーＳＩＬＳ

21 青大ロボコン研ＭＡＸ

2 チーム名

チームID

チーム名

チームID

ＡＥＫＲＵＮＮＥＲ１０

72 誠レーシングチーム

18 ミスユースケース分析

ソフトウェア品質特性／非機能要件

マインドマップマインドマップ _{マインドマップ}_{マインドマップ} マインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップ：一般社団法人ブザン教育協会マインドマップ：一般社団法人ブザン教育協会

(12)

様々な分析手法

９ その他／昨年振返り

０ アナロジー／メタファー

４ （対象）その他戦略

５ （対象）コース戦略

５ リスク分析

２ システム分析

３ 要求分析

３ ドメイン分析

１ ロバストネス分析

１ 構造化分析

１１ ソフトウェア品質特性／非機能要件

２ ミスユースケース分析

４ ユースケース分析

４ ゴール指向分析

６ フィーチャ分析

０ フィッシュボーン

２０ マインドマップ

チーム数

分析方法等

芝浦雑伎団

294 ＨＡＳＨＵＦＯ

79 のんびびりＱ

48 ｉ−Ｋ∀Ｓ

24 Ｓｕｐｅｒくろしお

19 チーム名

チームID

リスク分析

マインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップマインドマップ：一般社団法人ブザン教育協会マインドマップ：一般社団法人ブザン教育協会

(13)

(14)

(15)

<<緩和>> <<緩和>> 衝立に衝突し転倒する段差後にコースアウトする

誠レーシングチーム

シーソー階段衝立

(16)

(17)

AEK RUNNER10

【ネガティブアクター】

マシンのゆがみ、遊び

難所の段差

消耗した電池

会場の照明

ミスユースケースの補足説明

脅威と緩和策

(18)

(19)

(20)

(21)

(22)

ＨＥＬＩＯＳ

「非機能要件からの機能追加」

をユースケース図に組み込ま

れています。（水色）

UC-12 ライン形状の切り替わ

りを特定する

UC-14 段差を検出する

UC-13 曲線の繋ぎ目を補完

する軌跡を走行する

シナリオに異常

ケースを記述し、

対策を織り込まれ

ている。

(23)

(24)

(25)

(26)

(27)

ＳＯＲＯＴ

品質やパフォーマ

ンスに関する要求

を明らかにする。

エリア分割し、各エ

リアに対応する走

行方法を実装

⇒詳細は３ージへ

UC021

電池電

圧を取得する

UC025

段差を

検知する

UC026

ロストを

検知する。

(28)

(29)

(30)

ＳｔｒａｙＣａｂ０５

＜非機能要件より＞

PID制御、スピード制御、

三重多数決、色判定、

時間判定、位置判定、

位置補正、復帰走法、

フェイルセーフ

(31)

(32)

(33)

(34)

ＮｉＡＳＥＴ

非機能要件非機能要件マインドマップから、マインドマップから、走行体を構成する走行体を構成する部品の相性や個体部品の相性や個体差などを研究する部差などを研究する部分を抽出分を抽出プログラムにフィープログラムにフィードバックできる情報ドバックできる情報の収集なども開発の収集なども開発のサポートという形のサポートという形でここで行うでここで行う主な内容主な内容・相性・不良品を・相性・不良品を念頭に入れたハー念頭に入れたハードウェアの選定ドウェアの選定・さまざまな情報を・さまざまな情報を効率よく得るための効率よく得るためのソフトウェアの作成ソフトウェアの作成 →これにより開発の →これにより開発の円滑化・ハードウェ円滑化・ハードウェアの問題対処が高アの問題対処が高速に可能速に可能

詳細は

5 ₅

枚目に

(35)

(36)

(37)

(38)

(39)

ＨＡＳＨＵＦＯ

リスク分析

・・・

完走することを「安全」ととらえ，FTA（Fault Tree

Analysis）によるリスク分析を実施。完走を阻害

する障害を抽出

⇒ ユースケースに表明

(40)

芝浦雑伎団

リスク保有

・・・

衝突の可能性が

あるが

．．．

リスク回避

・・・

当日の状況しだ

いでは３Ｄ難所を

回避

(41)

お誘い

ミスユースケース、ネガティブアクター

を利活用して、ユースケース図を見直

してみませんか。

ユースケースに影響する対策が

構造や振る舞いの

どの部分に影響があるかが

見出せるようになります。

非機能要件から導出された実装可能な要件をユースケース（図、記述）に

南関東大会特別賞評価

ミス・ユースケースの利活用

非機能要件から得られたリスク対応のモデル化

2010年12月 2日

南関東地区大会審査委員長

アンリツエンジニアリング株式会社

林 啓弘

概要



ETロボコンのモデルにみる要求分析で

非機能要件や外乱等について列挙されて

いますが、列挙された当該課題の対策を

行うにあたって、どこでどのように対応して

いるかを文字列で表明されています。



ユースケースを拡張した ミス・ユース

ケースを利活用して、モデル図上に「課題

対策」を表明してみませんか。

分かりづらいものも

お誘い

ソフトウェアの品質特性 (JIS X 0129-1)

非機能要求から実装可能

非機能要求から実装可能

なアーキテクチャを設計し、

なアーキテクチャを設計し、

技術的な機能仕様書に具

技術的な機能仕様書に具

体化する。

体化する。

非機能要求が、あいまい

非機能要求が、あいまい

になっている場合は、不足

になっている場合は、不足

している基礎情報を調査し、

している基礎情報を調査し、

事例や専門家の経験も活

事例や専門家の経験も活

用して明示的に洗練する。

用して明示的に洗練する。

非機能要求が、前提の多

非機能要求が、前提の多

い仮説になっている場合は、

い仮説になっている場合は、

技術的なリスクとして管理し、

技術的なリスクとして管理し、

エンジニアリング活動を行う。

エンジニアリング活動を行う。

要素技術などに記載されています

要素技術などに記載されています

ソフトウェアの品質特性 (JIS X 0129-1)

非機能要求から実装可能な

非機能要求から実装可能な

アーキテクチャを設計し、技

アーキテクチャを設計し、技

術的な機能仕様書に具体化

術的な機能仕様書に具体化

する。

する。

非機能要求が、あいまいに

非機能要求が、あいまいに

なっている場合は、不足して

なっている場合は、不足して

いる基礎情報を調査し、事例

いる基礎情報を調査し、事例

や専門家の経験も活用して

や専門家の経験も活用して

明示的に洗練する。

明示的に洗練する。

非機能要求が、前提の多い

非機能要求が、前提の多い

仮説になっている場合は、技

仮説になっている場合は、技

術的なリスクとして管理し、エ

術的なリスクとして管理し、エ

ンジニアリング活動を行う。

ンジニアリング活動を行う。

ここは？

ここは？

粒度が適切ならば

粒度が適切ならば

林啓弘

ユースケースを拡張したミス・ユース

_{危険の相殺}