ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

宇宙ロボットエレベーター ロボット競技会とか(教育ITソリューションEXPOの感想)

2014-05-30 16:07:14 | Weblog
そうそう、書き忘れていた。先週(5月23日)、教育ITソリューションEXPOに行って来た。

全体的な感想は、いつもやっているような内容が、小規模のなってやっている感じ。つまり、コンテンツのお話。LMS、電子黒板・・・いろいろあるんだけど、いままでみたいに、「どっか~んと何」というのではなく、小規模にいろいろあるかんじ・・・

新しいところでは、富士ゼロックスの反転学習、AmazonAWSを使ってLMSとかもあったり、Tincan(SCORMの次といわれる)の展示もあったり、 小型ヒューマノイドロボットのNAOによる学習もあったけど、全部小さい展示。

そうそう、ロボットというと、LEGO.ちゃんと出てて、いまそのパンフレットを見てる。
LEGO Mindstorms Education EV3はもちろん、
Story Starterっていうのがあるらしい
それと、

第二回 宇宙ロボットエレベーターロボット競技会
http://space-elevator.narika.jp/

のチラシもあった。11月23日開催らしいが、
宇宙エレベーターワークショップが6月15日レゴジャパン本社であるらしい
宇宙エレベーター実験キットというのが、レゴであるらしいよ(そのチラシの裏に書いてある)

それと、GAKUENというのが、大きく出てた。

こんなかんじかな・・・

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アシュアランスケースとその表記法のGSNのチュートリアルを聞いてきた

2014-05-30 13:19:34 | Weblog
KBSEのチュートリアル、
アシュアランスケース演習   ~ ツールを使って書いてみよう!! ~
http://www.ieice.org/~kbse/tutorial/tutorial-20140530a.html
を聞いてきた。その内容をメモメモ




アシュアランスケースの必要性
リスク:障害、怪我→どのくらいの確率で起こるか

1.はじめに
・マクドナルドコーヒー訴訟
 コーヒーをこぼしてやけど→訴訟→勝訴

1.アシュアランスケースの必要性
 リスクの構造と
 それに対する安全性の主張の必要性
 主張する際のポイント

アシュアランスケース

(安全性の)主張
  ↑
  説明←アシュアランスケース(主張するための手段)
  ↑
 エビデンス

欧米では、アシュアランスケースは安全分野で

1.0事例から得られる示唆
・マグドナルドコーヒー訴訟の事例を考えると
事前準備
  ・発生割合
  ・温度などに対するリスク
プロセス
  ・提供する仕組みに不備
  ・クレームの発生しないシステム
  ・クレームの対応
その後
  ・どのように対応(発生防止)

・トヨタ 大規模リコール(プリウス)
 何も問題はないか?
  ・電子スロットに欠陥がないことを証明する
    →難癖をつける人に証明できるか?

訴訟だけでなく、お客さんの不安に証明できるか?

1.1 リスク発生条件と対処法
リスク
  前提条件が成立:システムが正常運用
   ↓(そうでない)
  想定している例外条件:想定された事項を実行
   ↓(そうでない)
  想定していない:運用プロセスでシステム機能回復

リスクの対処方法
1.リスクの識別
   網羅的、
2.リスクの対処策の考案・選択
   適切な対処
3.リスク対策の実施確認
   証拠が必要
それでも、想定外のトラブルがおこる。そのとき運用で対応

1.2 システムリスク管理のための開発活動
・V字開発
  要件定義         システム試験
   外部設計      結合試験
    内部設計   単体試験
      プログラミング

想定できることはV字で開発できる
想定外:運用保守工程

1.3 システムリスクの対応・主張方法
・イプシロンロケット 打ち上げ中止
  地上装置
  搭載検査機
   →0.07秒はやかった

確認問題 ワークシート
  問題
  理由
  対処

1.3 システムリスクの対応・主張方法
 主張
 |-前提
 |-説明
 証拠

Toulminの論証構造
  →クリティカルシンキング

2.2 アシュアランスケースの表記法
  GSN
  CAE
  ARM

・astah GSNで作図

・木構造になっている
 説明をいれて主張

・主張は最終的にundevelopか証拠で終わる

・→に2つ(astahは自動的に色を変える)

主張:S+Vの命題(命令や挨拶でない)
説明:分割するときの議論の仕方
証拠:ドキュメント

前提:システムの運用環境、定義など
・ディペンダビリティ→たよりがいがある
・語彙の定義

ゴールの分割
  システムの構成要素ごとに分解
  機能による分解
  属性構造による分類

間違いやすいポイント
・説明戦略とゴールと取り違い
・主張が実行文になっている

Q;構成要素に分割する→独立を保障しないといけないのでは?
A;→独立でない場合、相互作用のゴールを入れる

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする