システムアーキテクティングとインテグレーション 第1講

☆2次元Vモデル→URL参照ｗ
https://t09468ns.wordpress.com/2013/04/16/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%A8%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%80%80%E7%AC%AC2%E8%AC%9B/

https://t09468ns.wordpress.com/2013/04/16/ソフトウェア工学-第２講/

https://t09468ns.wordpress.com/2013/04/16/%E3%83%A2%E3%83%87%E3%83%AB%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%8F%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E4%BA%88%E6%B8%AC%E3%81%A8%E5%88%B6%E5%BE%A1%E3%80%80%E7%AC%AC%EF%BC%92%E8%AC%9B/

☆アーキテクチャの鉄則
○利害関係者の要求を定義し、システム要求を明確にした後にシステムアーキテクチャを開始する
○システムやプロジェクトの目的を定義し、明確にする必要がある
○アーキテクチャの完了
・システムが構成要素レベルにまでっ分解される
・構成要素間のインタフェースが定義される
・ここの構成要素に対して要求が定義される、これではじめて開発チームはそれらの設計を開始できる
→構成要素は通常、設計の最も下位のレベルで定義される
→構成要素を開発する場合：ハードウェアやソフトウェアのチームが設計を開始するレベル
→購入できるばあい：その要素を購入できるレベル

☆アーキテクチャの3つのView
○Operational View→Concept of Operations（CONOPS）
・ユーザーあるいはオペレーター視点からシステムを定義する。ユーザーがシステムとあるいはシステムが外部システムとどのように作用するのか
○Functional View
・それを機能に落としこむ
○Physical View
・さらに物理要素にまで落としこむ

☆インテグレーションを考慮したアーキテクチャ
○単なる統合することではない
○はやい段階最終形態をわかるようにしたい
○つまり、こういうこと？
SDM実習にて、チームDは開発に入る前段階からこのような形で物理とその関係を物理アーキテクチャというのを作った

これをイメージとして持っていたから、できたものがこうなった

だから出来たものは「こんなものができたのか！」ではなく「イメージ通りになったね！」ということになる。
これが大事だ・・・ということだと思われw

モデル駆動型システム開発の基礎 第５~６講(３日目)

☆シーケンス図
◯ライフラインの定義
◯メッセージの表記
・システムのロールの間に、情報・データを交換するには、メッセージを使う
・各メッセージはシステムが備える機能で支援される
・メッセージの方向は、以下の通り定義される
・メッセージの矢印の先にあるライフラインが、メッセージの機能を備えている
・矢印を出しているライフラインのシステムが、その機能を呼び出している
・簡単に言うと、メッセージは、機能の呼び出しに相当している
◯メッセージに属する特徴
・呼び出された機能を実行する時間
・任意：返答メッセージ
・呼び出される機能には、変数が定義されるなら、変数に設けられる値が表示される
・ツールによっては、同期メッセージと非同期メッセージを利用する。表記の代わりに直線矢印（同期）もしくは破線矢印（非同期）、表示するメッセージ
◯特別なメッセージの表記
・自分の機能を呼び出すシステムのロールは矢印が出て戻るようなメッセージを用いる
・メッセージを受け取ったシステムの反応をモデリングするために役立つ
◯フラグメントを使用した、制御フローの記述
・シーケンス図の制御フローを定義するにはフラグメントという領域を利用する。

参照：教科書２７１ページ

イノベーティブワークショップデザイン論第1講

☆概要
◯通年
・秋〜春で2単位
◯ワークショップをデザインする
・ファシリテーション能力は教える予定ない

☆ワークショップデザインの前提
◯新しい事業などを発送するためのアイディア創出の力をアップさせたいと考えている
◯中堅企業20名が参加予定
◯企画提案を行う部署

☆ワークショップの体験
◯イノベーティブなコミュニケーションツールを作る

☆課題
◯30分のワークショップを考える
◯テーマは「自動運転が普及した時代の”バックドアを開けたい意思”を読み取るには？」

モデル駆動型システム開発の基礎 第3〜4講(2日目)

☆ブロック定義図
◯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>>(派生)：複数の要求の間に、派生する作業が行われたのを表現する
◯要素間のトレーサビリティ構築
・モデルベースアプローチの利点→トレーサビリティ構築を強化する
・要素の間に、関係が存在すれば、情報を手軽に追跡する
・運用：システム変更に対する影響分析、要求カバー分析など

コミュニケーション 第７講

〜論文の書き方〜
☆まず、論文とは何か？
◯論文
・学術会一般で単に「論文」という時には、査読付きジャーナル（論文誌）の論文を指す
◯国際（or国内）会議の講演論文
・「講演論文」は「論文」ではない。
◯学位論文
・所詮内部資料( ；∀；)

☆なぜ論文を書くのか
◯「論文」「講演論文」
・学術の進歩のため
・自分の成果を世に問うため
・博士号を取るため
◯「学位論文」
・研究成果を体系的にまとめる訓練
・研究成果を人に伝える訓練
・修士号・博士号を取るため

☆論文と本の違い
◯論文
・学術分野の発展
・一つの論文にオリジナリティーが明確に証明
・独特の書き方（ルール）がある。
◯本
・著者の自由
・ただし、ジャンルにもよる。。。

☆SDMの「修士論文」のカテゴリー
◯SDMの「修士論文」
・学会論文型
・（投稿論文にならないが）社会に役立つ
・自分のためになる（業務に役立つ）
◯専門家育成型研究科の「修士論文」
・学会論文型

☆タイトルの付け方
◯タイトルだけ見て、具体的な内容をイメージできるように。
◯ゴールステートメントに書いたことがオリジナルな特徴であるはずなので、そのうちの最も重要な部分を書く

モデルに基づくシステムの予測と制御 第７講

〜ドライバーによる車の安全運転〜
☆多発する交通事故の概要
◯死亡人数は１１年連続で減少
・２４時間以内に亡くなる方は減っている→医療技術の向上

☆事例研究 省略と先行
◯省略
・安全運転を怠る
・３割〜４割程度→大多数は、省略していない
◯先行
・確認と行動を同時並行でやってしまう
・全体の４割〜５割
◯省略＋先行→７〜８割が正しくやってない！

システムデザインのための統計とデータ処理 第６講

☆Excelでの統計の復習
◯主な関数
– SUM(数値1,…) 合計 -AVERAGE(数値1,…) 平均値
– MEDIAN(数値1,…) 中央値
– DEVSQ(数値1,…) 偏差平方和 – VAR(数値1,…) 分散
– STDEV(数値1,…) 標準偏差
– MAX(数値1,…) 最大値
– MIN(数値1,…) 最小値
– COUNT(数値1,…) データ数 

☆SPSSの使い方
◯特記事項無し

☆課題

◯データの入力方法

◯変数の定義

◯分析方法
「分析」→「一般線型モデル」→「1変数」

↓

↓

ビジネスシステムのシステムズアプローチ 第5講

〜システム ダイナミクス〜
☆環境容量
◯その環境が養うことのできる特定のタイプの生物の個体数
・一定の土地に無限の動物は暮らせないんだよ

☆S字曲線

◯最初のうちは順調に指数関数的に増えていったとしても、環境容量が近くになれば増加量はすくなくなる。そして最終的には環境容量に収束する

☆Growth with Overshoot

◯システムに遅れ(Delay)があると、S時になる前に環境容量を超えてしまい、そこで振動が発生する

☆Overshoot and Collapse

◯環境容量が一定とは限らない（例えば、市場に飽きられて減少するなど）
◯仮に環境容量が下がることによって、図のように崩壊が起こることもある。

システムデザインマネジメント実習 第5・6講

☆ドキュメントを作ることはコミュニケーションの重要な道具
◯論理的理解を助ける
◯あとでしっかりと読み直せる

☆目的別に別ドキュメントにする
◯「このドキュメントは◯◯に関する資料である」と目的を載せることが大事
◯判断に用いた資料は、別ドキュメントにする。

☆Stakeholder Concept
◯出来ないas is→出来るto beを作ることが重要！！！