☆V&V 検証と評価
○ほとんど成功しない大規模システムのプロジェクト
☆システムエンジニアリングを構成する4つの活動
○システム設計
○システムエンジニアリング管理
○評価解析←この授業
○インテグレーション
☆Verification ＆Validation
○Verification
・仕様に従っていることの証明
・正しくサービス/プロダクトを作っているか？
∟調査・検査・査察・・・目で見て専門家が確認する
∟解析・・・統計などから調べる
∟実証・・・ものを使って試してみる
∟試験・・・出来上がったシステム自体を調べる
○Validation
・ユーザが満足することの証明
・正しいサービス/プロダクトを作っているか？
∟アンケート
∟インタビュー
∟観察
○いつやるの
・EVERYDAY！
☆課題
○自分の研究について、その有効性を検証、評価するためにいつ、どのようにV&Vできるかについて考えて、説明する
https://t09468ns.wordpress.com/2013/04/16/ソフトウェア工学-第２講/
☆アーキテクチャの鉄則
○利害関係者の要求を定義し、システム要求を明確にした後にシステムアーキテクチャを開始する
○システムやプロジェクトの目的を定義し、明確にする必要がある
○アーキテクチャの完了
・システムが構成要素レベルにまでっ分解される
・構成要素間のインタフェースが定義される
・ここの構成要素に対して要求が定義される、これではじめて開発チームはそれらの設計を開始できる
→構成要素は通常、設計の最も下位のレベルで定義される
→構成要素を開発する場合：ハードウェアやソフトウェアのチームが設計を開始するレベル
→購入できるばあい：その要素を購入できるレベル
☆アーキテクチャの3つのView
○Operational View→Concept of Operations（CONOPS）
・ユーザーあるいはオペレーター視点からシステムを定義する。ユーザーがシステムとあるいはシステムが外部システムとどのように作用するのか
○Functional View
・それを機能に落としこむ
○Physical View
・さらに物理要素にまで落としこむ
☆インテグレーションを考慮したアーキテクチャ
○単なる統合することではない
○はやい段階最終形態をわかるようにしたい
○つまり、こういうこと？
SDM実習にて、チームDは開発に入る前段階からこのような形で物理とその関係を物理アーキテクチャというのを作った
これをイメージとして持っていたから、できたものがこうなった
だから出来たものは「こんなものができたのか！」ではなく「イメージ通りになったね！」ということになる。
これが大事だ・・・ということだと思われw
☆要求管理という方法論
○要求図
・一部のSysMLの定義は、UMLに基づいている
○要求を管理ツールによって処理する
・要求管理ツールの環境では、要求を定義して1項目ごとに扱う
・複数のユーザは要求を1項目に独立して編集する
○管理ツールによる要求作成
・要求を作成するには、インターフェースで要求の項目を作って、Databaseで保存する
○要求につく属性
・要求管理ツールでは、要求項目ごとに属性を定義できる
・要求の属性
・重要さ
・種類
・所有者
・優先レベル
○要求のトレーサビリティ
・要求管理ツールの大事なポイントは、要求の間に関係を指定する仕組みが備えること。
・しかし、一般のツールは、シンプルなトレースにしか対応していない
○要求管理ツールとモデリングツールの統合
・要求とモデルを同時に処理する環境
・要求管理ツールから要求項目をモデル要素としてインポートする。
○SysMLで要求をモデル化する
・SysMLで要求をモデル化するには、基本的にダイアグラムの種類は2つ
・ユースケースダイアグラム
・要求ダイアグラム
・ユースケースという要素とSysML要求という要素を同じダイアグラムにおいて混合できる。
一般的に、ブロックというシステム構造の単位とも混合できる
☆シーケンス図
◯ライフラインの定義
◯メッセージの表記
・システムのロールの間に、情報・データを交換するには、メッセージを使う
・各メッセージはシステムが備える機能で支援される
・メッセージの方向は、以下の通り定義される
・メッセージの矢印の先にあるライフラインが、メッセージの機能を備えている
・矢印を出しているライフラインのシステムが、その機能を呼び出している
・簡単に言うと、メッセージは、機能の呼び出しに相当している
◯メッセージに属する特徴
・呼び出された機能を実行する時間
・任意：返答メッセージ
・呼び出される機能には、変数が定義されるなら、変数に設けられる値が表示される
・ツールによっては、同期メッセージと非同期メッセージを利用する。表記の代わりに直線矢印（同期）もしくは破線矢印（非同期）、表示するメッセージ
◯特別なメッセージの表記
・自分の機能を呼び出すシステムのロールは矢印が出て戻るようなメッセージを用いる
・メッセージを受け取ったシステムの反応をモデリングするために役立つ
◯フラグメントを使用した、制御フローの記述
・シーケンス図の制御フローを定義するにはフラグメントという領域を利用する。
参照：教科書２７１ページ
☆概要
◯通年
・秋〜春で2単位
◯ワークショップをデザインする
・ファシリテーション能力は教える予定ない
☆ワークショップデザインの前提
◯新しい事業などを発送するためのアイディア創出の力をアップさせたいと考えている
◯中堅企業20名が参加予定
◯企画提案を行う部署
☆ワークショップの体験
◯イノベーティブなコミュニケーションツールを作る
☆課題
◯30分のワークショップを考える
◯テーマは「自動運転が普及した時代の”バックドアを開けたい意思”を読み取るには？」
☆ブロック定義図
◯Internal Block Diagramという図式
・ブロックとパートの相違は「定義とインスタンス」という概念に等しい
・ブロックによってインスタンスを生成する
（イメージとしては、ブロックがカレーのレシピで、インスタンスはカレーそのもの）
◯パート間の通信
・ポートでパートは外部の要素につながる
◯モデル構築のアプリケーション
・製品のコンフィグレーションを評価して比較する
・コンフィグレーションを評価したり最適化出来て、初期開発段階で正確に計画する
☆動作モデリング
◯動作モデリングは3つの形式
・アクティビティ図
→非同期動作（ワークフロー）
・インタラクション図
→同期動作（時間的に揃える通信）
・ステート図
→システムの状態と状態遷移
※動作モデルは組み合わせられる
◯状態図
・状態図によってシステムの状態と状態遷移を記述する
・表現できること
→状態に入る条件・状態を出る条件・状態で行う活動・状態遷移を定義する
◯同期動作→インタラクション
・インタラクション図によって、システムの間に同期的メッセージを記述する
・表現できること
→パートの通信、同期メッセージ、非同期メッセージ(返答)
☆SysML Rhapsodyのインストール
☆システムエンジニアリングという分野
◯「システムモデル」って？
→異なった分野におけるシステムを、単純化して表現する。
◯システムエンジニアリングの進化傾向
・開発コスト削減
・開発期間の短縮
・品質改善
・製品の特徴を増やす、機能性向上
・分割されたチームや供給者などを管理する
◯製品の例
・飛行機
・衛生、地上局
・自動車（大型／小型）
◯複雑さの要因
・異なった分野の統合
→メカ、エレキ、ソフトなど、学際領域と呼ばれる製品の状況
・製品の機能を、メカ、エレキの部品より、段階的にソフトで制御する
・製品の部品と要求感のトレーサビリティーを守る
☆一般的なアプローチ
◯システムエンジニアリング分野を、より良く支援する
・形式的なモデルでシステムエンジニアリングを支援する
・形式的な製品モデルによって開発の活動を改善する
◯システムのモデルの役割
・製品に対する要求
→要求の最もカンタンな形式は、テキスト それをわかりやすくするためにモデルにする
→製品のそれぞれの部品に要求を割り当てる
・製品の特性を記述
→構成・動作・要求
・開発プロセス感の製薬を理解したり扱う
☆開発段階の紹介
【開発→概念設計→詳細設計→原始製造→製造→サービス】
◯製品開発プロセスは産業によって依存する
◯開発段階の一般的な流れ
１．開発計画・初期要求分析：シエ品に対する要求をまとめて開発計画を決める
２．コンセプト作成・概念設計：製品の主な要素を企画して製品の構造や動作を決定する
３．詳細設計：より専門的なレベルまで落としていく 定義仕様を満たす要素を開発
４．物理的な・擬似のプロトタイプ：製品に対するプロトタイプを作成
◯開発ライフサイクルのスタンダード
・標準化協会で定義
→IEEEなど
◯開発計画・基本要求分析・管理
・プロジェクト計画
・顧客と一緒に要望を発見
・市場価値を見積もる
・開発予算を決定
・保障のコストを目算する
→既存の製品の改良であれば、それまでの開発についての故障率などを試算し、
その分を予算に追加して置かなければならない
→新しいものを作る場合、難しい
・基本要求の管理
・明確に要求を整理
→DBに基づいてのツールがある
・要求はどのような製品の部品で満足できるかを調査する
・現場
→ツールが存在しているのに、度々ExcelやWordで要求が管理される
◯コンセプト作成・概念設計
・製品のコンセプトを作成する
◯詳細設計
・詳細設計の目的は、定義仕様に合わせて部品を開発する
・部品表というデータ構造で、部品の定義を保存する
・部品表で部品定義仕様を管理する。
◯製造・大量生産／量産
・供給者から購入した部品を、製品の構造をもとに組み合わせる
・供給者管理という作業を行う
◯サービス段階
・製品を保守したり修理したりする。
・保障情報を加工して設計変更を実施する
・故障原因を探して製品品質を向上させる「根本分析」
☆システムモデルに基づいてのシステムエンジニアリング
◯システムモデルは、製品の構造や動作を記述する役割
◯システムモデルの利点
・要求の明確さを上達させ、製品機能を検証したり、製品の性能を評価しておく
・チームの中に、プロジェクトの目標に対する理解を強化させる（連絡媒体）
・製品の実際の複雑さを把握する
・製品の規格を見積もる。
◯Rain Sensing Wiper
・雨をフロントガラスで検知し、雨ならワイパーを作動する
・雨量が増加したら、ワイパーの速度を増やし、雨が止んだら、ワイパーを止める
☆Dual VeeModel
◯Architecting-VeeとEntitiy-Vee
☆システムモデルに基づくシステムエンジニアリング
◯システムモデルの役割（第1）
→システムレベルの問題点や要求などを洗い出して分野モデルを統合する
◯システムモデルは分野モデルを取り替えるものではない（第2）
→SysMLがあるからといってUMLがいらないわけじゃないし、他の言語の代わりになるわけではない
☆SysMLというシステムモデル
◯ユースケース図＜ユースケース表記＞
・ユースケース
→製品の利用シナリオ
・システムの範囲
・外部と内部を区別する
・アクターとシステムの関係
・内部と外部でやりとりする情報
・ユースケースの関係
・include「埋め込んでいる情報」
・Extend「例外的な活動」
◯要求図 整理・関係
・複合関係、要求の記述やテキストなどを分割する
・<<trace>>(追跡)：複数の要求の間に、関係が存在するのを表現する
・<<refine>>(洗練)：要求の記述を、詳細に述べたりする
・<<deriveReqt>>(派生)：複数の要求の間に、派生する作業が行われたのを表現する
◯要素間のトレーサビリティ構築
・モデルベースアプローチの利点→トレーサビリティ構築を強化する
・要素の間に、関係が存在すれば、情報を手軽に追跡する
・運用：システム変更に対する影響分析、要求カバー分析など
朝起きたら、首相官邸からLINEで「東京招致成功」を知った。
TVをつければ当然メディアは大騒ぎ。
SportsBookで1番人気だったとはいえ、汚染水問題が浮き彫りになりながらも、マドリードの猛追を差し置いて選ばれたのはやはり嬉しい。
ただ、これをFB経由で見ている人なら、大勢の知識人(笑)が「最悪の結果」とか「辞退しろ」とか騒いでいるのを見ているのではないか。。。そう思っている。
それに関して、俺は自分の意見を述べたいと思ってこれを書こうと思った。
まず、俺は「2020年のオリンピックを歓迎すべき」というスタンスである事を先にいいたいと思う。つまり、五輪招致は「最高の結果」になったとおもっている。
但し、何でもかんでも手放しに喜んでいいわけではない…という、冷静な思いもある。
まず、いくらか反五輪の意見を見てみたが、それらに共通することは以下のこと
・最終プレゼンが嘘つきまくり
∟汚染水はコントロールできている
∟東京に被害はない
∟水や食料の基準は世界の最も厳しいものの1/100以下
・そのプレゼンが被災地の人たちを失望させている。それでよく復興支援と言えたものか
・東京都は福島原発事故の加害者である
∟事実そこで生産された電気は全く現地で使われず、東京に来ていた
・TPPや増税のめくらまし／体のいい言い訳
といったところであろうか。
まず、個人的には本意ではない（その理由は後述）のだが、多少の批判を受けるつもりでこれだけは反論する
・東京都は福島原発事故の加害者である
これは、もし本当に現地の人がそう言っているのであれば、烏滸がましいにも程がある。俺は「東京も福島も、この事故に関して同罪である」と思ってる。もちろん、電気を使っていた東京近郊含め。あまりにもこの事故によって、福島の人たちが「悲劇のヒロイン」的になっているのは、少々違うと思う。この事故が起きたことにより、東京都では電気が不足し、計画停電などで事故が起きて亡くなった方だっている。こちらもまた被害者である。
そして、今回問題がおきる前までは、この原子力発電所による収入で街が潤っていたという、その事実をすべて棚上げにしている。それまで美味しい思いをしていながら、それなのに過疎化は止められないで、だからより原子力の恩恵を受ける事を求め、いざ事故になったら東京を叩く…つくづく日本人は人や政府を叩き潰すことが好きである。おそらく俺も例外ではないのだろうけど。とある私が尊敬する人はこれを「農村民族」と言っていたが。。。責任転嫁したがる日本人の悪いところが全面的に出ているなと感じている。
…いま、ここまで読んでくれた人はどう思っているのだろうか。
もし、これを読んで不愉快になったり、なんか退屈だな〜とか、ひねくれてんな〜と思ったとしたら、それは申し訳ない半面、私の狙い通りになったと思ってる。
俺がいいたいのはその感情…結局これを読んでも建設的な会話にならないよね？ということ。つまり、ネガティブな思いで、人や政府を批判したところで、この問題は解決しない。仮に東京招致をやめたら原発事故はかんぜんに収束するのか？放射線量はゼロになるのか？ならないよね？じゃあ、批判して何になるの？ということ。これが、先ほどの「本意ではない」と言った理由である。
すでに賽は投げられ、そしてその目は「東京」が出た。それは事実であり、それは今後五輪によって世界中からお金が入ってくる「権利」と、様々な問題を世界に見られ、それらを解決する方法にいくようにしていかなければいけない「義務」を表している。政府やオリンピック選手による「チーム東京」によって実現した「招致」これを実現するには開催地東京を中心とした「チーム日本」のちからが必要だ。だけど、それで得られるものは、かつての東京五輪が人々に感動を与えたように、直接的・間接的に日本中…いや世界中に感動を与えてくれると思うし、1億3000万の日本人が同じベクトルを向いて一丸となれる絶好の機会として、俺はこの開催決定を歓迎している。
とはいえ、
・最終プレゼンが嘘つきまくり
・TPPや増税のめくらまし／体のいい言い訳
に関しては、目を背けず向き合わなければいけない。でもそれを責めるのではなく、みんながそれらを他人事ではなく、自分事だと思って考えていくべきではないか。例えば
汚染水はコントロールできている／東京に被害はない／水や食料の基準は世界の最も厳しいものの1/100以下
確かに、コントロールできててれば汚染水問題は発生しないし、東京に被害はないという根拠はないし、基準はそれがサンプリング検査である限り絶対とはいえないだろうし、嘘と言われても仕方ないのかもしれない。
だけど、これを責めるのであれば、それはさっきの俺の反論と同様、その問題の解決にはならない。
考えよう。言ってしまった「嘘」をどうすれば「事実」にできるのかを。
たかが70人しかいない大学院1学年でも7企業のソリューションを複数生み出している。たった3ヶ月程度で
問題は山積みだけど、2020まで7年もある。頭だって、70じゃなくて1億3000万ある。
考えよう。答えは絶対出せる。そのためにはこんなくだらない批判・反論はいらない。
と、自分の思いを長文にわたって書いたわけだが、ここまで読んでくださった方もしいたらありがとうございましたm(__)m
今日、ブレイン・ストーミング 通称ブレストの怖さを感じた。
それは、この使い方を乱用すれば、簡単に人を傷つけてしまうということ。。。
今日とあるチームのブレストに混ぜさせてもらった。
そのテーマ内容は、正直に言えば、俺には不向きであった。
なぜ不向きだったのか。
意見はものすごく出た。
そりゃあそうだ。
そのテーマの背景には、俺の人生の経験で、一般的に「黒歴史」と呼ばれるものに通じるものがあったからだ。
はっきり言えば、俺は途中無我夢中に書いていた時があった。
黒い経験が、また別の黒い経験を連鎖させ、ただひたすらポスト・イットを書きまくっていた。
そして、出てきた俺の意見は、「いいね〜」というのでうめつくされるものとは程遠い、黒歴史の最中にいた自分自身の悲痛な叫びのようなものであった。
もちろん、これには無我夢中でやっていたとはいえ、気づいていた。しかし、そのチームにとって少しでも得られるものになればと思って、行けるところまでやってしまった
しかし、それが俺の一番の失敗だった。2×2で分類をし、俺の書いたものがひとつひとつ読まれながら処理されて行った時、新卒のメンバーの1人が「なんか見てて悲しくなる」と、それ以上は口には出していなかったが、その顔は明らかにショックを受けたような顔をしていた。
俺はそのチームのために出したつもりではあったが、結果的には、自らの過去を他人にぶちまけて人を傷つけただけ、言葉の暴力以外のなにものでもなかった。しかも研究とかではなく単なる授業のグループワークなのに。。。
これを言った俺も、実のことを言えばそれなりにダメージはある。やはり、思い出したくないのに忘れられない過去を引っ張り出してくるのだから、それ相応のダメージは覚悟していたし、それは自業自得だ。だけど、それを他人に押し付けるのはやってはいけないこと。おれはそれを今日ブレストという道具を乱用してやってしまった。
意見はなんでもいいとは言われるが、それはあくまで人を傷つけない程度の内容であるというのはきっと前提条件のはず。そしてそれは自分の経験と結ぶことによって満たせないこともあるんだということを、今日思い知った。。。
（プログラマーにとって）ひとつの覚悟
ソフトのオープンソース化
正直、チームのメンバーに相談しようか悩んだ。
だけど、やっぱりこれが俺の考えだし、例えそれで先生に何を言われようと構わない。
俺はこのプログラムを公開しよう。そう決めた
所詮実装は孤独だ
そんな孤独を毎年同じ時間掛けて誰かがやらなくたっていい。
あるパーツがあれば使えばいい
俺だってそう。これを作るのに色んなパーツを組み合わせていった。
そして、俺はそれを更に誰かに使ってもらうために、このソースコードを公開する
Twitterで掃除開始の命令を出したら、それを受けてRoombaが動く
掃除の清掃と開始は通知する。
こんなシンプル。。。これがウチラの考えたステークホルダー要求だったから。
でも、これが誰かの手に渡った時、ひょっとしたらまた別の誰かのステークホルダー要求に進化できるかもしれない。
そんな思いをちょっと持っている。
とっととURLを公開しろよと思うかもしれないけど
これを利用する人に一つお願い。
これを使うのに許可はいらないし、逆に質問があればできるだけ受け付けます。
無論、これを見て使おうと思った一般の方々（これを見ているのかわからないけど）も同様に（いたら、だが）質問は受け付けます。
メッセージ頂いたら、可能な限り対応します
その代わり、、、作ったプログラムはまた誰かのために（もちろん個人情報は消して）オープンにしてあげてください。
義務ではないが、お願い。
これを作った人間は、それを望んでアップしているので
そのソースコード
↓↓↓↓↓↓↓↓
https://github.com/NaokiShibazaki/OpenRCCRelaySubSystemProject
多分、Eclipse環境で動く。必要なJarファイルなどは下のクラス図見るかぐぐって分からなければきいてくださいｗ
誰かのために、使ってもらえたら いいなぁ〜ｗ
Naoki's SDM Diary 