システムの評価と検証 第1講

☆V&V 検証と評価
○ほとんど成功しない大規模システムのプロジェクト

☆システムエンジニアリングを構成する4つの活動
○システム設計
○システムエンジニアリング管理
○評価解析←この授業
○インテグレーション

☆Verification &Validation
○Verification
・仕様に従っていることの証明
・正しくサービス/プロダクトを作っているか?
∟調査・検査・査察・・・目で見て専門家が確認する
∟解析・・・統計などから調べる
∟実証・・・ものを使って試してみる
∟試験・・・出来上がったシステム自体を調べる
○Validation
・ユーザが満足することの証明
・正しいサービス/プロダクトを作っているか?
∟アンケート
∟インタビュー
∟観察
○いつやるの
・EVERYDAY!

☆課題
○自分の研究について、その有効性を検証、評価するためにいつ、どのようにV&Vできるかについて考えて、説明する

広告

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

☆2次元Vモデル→URL参照w
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/ソフトウェア工学-第2講/

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は開発に入る前段階からこのような形で物理とその関係を物理アーキテクチャというのを作った
file
これをイメージとして持っていたから、できたものがこうなった

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

モデル駆動型システム開発の基礎 第7項(4日目)

☆要求管理という方法論
○要求図
・一部のSysMLの定義は、UMLに基づいている
○要求を管理ツールによって処理する
・要求管理ツールの環境では、要求を定義して1項目ごとに扱う
・複数のユーザは要求を1項目に独立して編集する
○管理ツールによる要求作成
・要求を作成するには、インターフェースで要求の項目を作って、Databaseで保存する
○要求につく属性
・要求管理ツールでは、要求項目ごとに属性を定義できる
・要求の属性
・重要さ
・種類
・所有者
・優先レベル
○要求のトレーサビリティ
・要求管理ツールの大事なポイントは、要求の間に関係を指定する仕組みが備えること。
・しかし、一般のツールは、シンプルなトレースにしか対応していない
○要求管理ツールとモデリングツールの統合
・要求とモデルを同時に処理する環境
・要求管理ツールから要求項目をモデル要素としてインポートする。
○SysMLで要求をモデル化する
・SysMLで要求をモデル化するには、基本的にダイアグラムの種類は2つ
・ユースケースダイアグラム
・要求ダイアグラム
・ユースケースという要素とSysML要求という要素を同じダイアグラムにおいて混合できる。
一般的に、ブロックというシステム構造の単位とも混合できる

モデル駆動型システム開発の基礎 第5~6講(3日目)

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

参照:教科書271ページ

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

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

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

☆ワークショップの体験
◯イノベーティブなコミュニケーションツールを作る
2013-09-25 19.24.40 2013-09-25 19.27.54 2013-09-25 19.34.50 2013-09-25 19.46.46 2013-09-25 19.53.17 2013-09-25 19.57.14 2013-09-25 19.57.21 2013-09-25 20.23.31 2013-09-25 20.24.06 2013-09-25 20.24.14 2013-09-25 20.35.00 2013-09-25 20.43.51 2013-09-25 20.43.56 2013-09-25 20.44.02 2013-09-25 20.45.55 2013-09-25 20.47.29 2013-09-25 20.48.59 2013-09-25 20.50.37 2013-09-25 20.52.08 2013-09-25 20.52.15

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

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

☆ブロック定義図
◯Internal Block Diagramという図式
・ブロックとパートの相違は「定義とインスタンス」という概念に等しい
・ブロックによってインスタンスを生成する
(イメージとしては、ブロックがカレーのレシピで、インスタンスはカレーそのもの)
◯パート間の通信
・ポートでパートは外部の要素につながる
◯モデル構築のアプリケーション
・製品のコンフィグレーションを評価して比較する
・コンフィグレーションを評価したり最適化出来て、初期開発段階で正確に計画する

☆動作モデリング
◯動作モデリングは3つの形式
・アクティビティ図
→非同期動作(ワークフロー)
・インタラクション図
→同期動作(時間的に揃える通信)
・ステート図
→システムの状態と状態遷移
※動作モデルは組み合わせられる
◯状態図
・状態図によってシステムの状態と状態遷移を記述する
・表現できること
→状態に入る条件・状態を出る条件・状態で行う活動・状態遷移を定義する
◯同期動作→インタラクション
・インタラクション図によって、システムの間に同期的メッセージを記述する
・表現できること
→パートの通信、同期メッセージ、非同期メッセージ(返答)

☆SysML Rhapsodyのインストール

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

☆システムエンジニアリングという分野
◯「システムモデル」って?
→異なった分野におけるシステムを、単純化して表現する。
◯システムエンジニアリングの進化傾向
・開発コスト削減
・開発期間の短縮
・品質改善
・製品の特徴を増やす、機能性向上
・分割されたチームや供給者などを管理する
◯製品の例
・飛行機
・衛生、地上局
・自動車(大型/小型)
◯複雑さの要因
・異なった分野の統合
→メカ、エレキ、ソフトなど、学際領域と呼ばれる製品の状況
・製品の機能を、メカ、エレキの部品より、段階的にソフトで制御する
・製品の部品と要求感のトレーサビリティーを守る

☆一般的なアプローチ
◯システムエンジニアリング分野を、より良く支援する
・形式的なモデルでシステムエンジニアリングを支援する
・形式的な製品モデルによって開発の活動を改善する
◯システムのモデルの役割
・製品に対する要求
→要求の最もカンタンな形式は、テキスト それをわかりやすくするためにモデルにする
→製品のそれぞれの部品に要求を割り当てる
・製品の特性を記述
→構成・動作・要求
・開発プロセス感の製薬を理解したり扱う

☆開発段階の紹介
【開発→概念設計→詳細設計→原始製造→製造→サービス】
◯製品開発プロセスは産業によって依存する
◯開発段階の一般的な流れ
1.開発計画・初期要求分析:シエ品に対する要求をまとめて開発計画を決める
2.コンセプト作成・概念設計:製品の主な要素を企画して製品の構造や動作を決定する
3.詳細設計:より専門的なレベルまで落としていく 定義仕様を満たす要素を開発
4.物理的な・擬似のプロトタイプ:製品に対するプロトタイプを作成
◯開発ライフサイクルのスタンダード
・標準化協会で定義
→IEEEなど
◯開発計画・基本要求分析・管理
・プロジェクト計画
・顧客と一緒に要望を発見
・市場価値を見積もる
・開発予算を決定
・保障のコストを目算する
→既存の製品の改良であれば、それまでの開発についての故障率などを試算し、
その分を予算に追加して置かなければならない
→新しいものを作る場合、難しい
・基本要求の管理
・明確に要求を整理
→DBに基づいてのツールがある
・要求はどのような製品の部品で満足できるかを調査する
・現場
→ツールが存在しているのに、度々ExcelやWordで要求が管理される
◯コンセプト作成・概念設計
・製品のコンセプトを作成する
◯詳細設計
・詳細設計の目的は、定義仕様に合わせて部品を開発する
・部品表というデータ構造で、部品の定義を保存する
・部品表で部品定義仕様を管理する。
◯製造・大量生産/量産
・供給者から購入した部品を、製品の構造をもとに組み合わせる
・供給者管理という作業を行う
◯サービス段階
・製品を保守したり修理したりする。
・保障情報を加工して設計変更を実施する
・故障原因を探して製品品質を向上させる「根本分析」

☆システムモデルに基づいてのシステムエンジニアリング
◯システムモデルは、製品の構造や動作を記述する役割
◯システムモデルの利点
・要求の明確さを上達させ、製品機能を検証したり、製品の性能を評価しておく
・チームの中に、プロジェクトの目標に対する理解を強化させる(連絡媒体)
・製品の実際の複雑さを把握する
・製品の規格を見積もる。
◯Rain Sensing Wiper
・雨をフロントガラスで検知し、雨ならワイパーを作動する
・雨量が増加したら、ワイパーの速度を増やし、雨が止んだら、ワイパーを止める

☆Dual VeeModel
◯Architecting-VeeとEntitiy-Vee

☆システムモデルに基づくシステムエンジニアリング
◯システムモデルの役割(第1)
→システムレベルの問題点や要求などを洗い出して分野モデルを統合する
◯システムモデルは分野モデルを取り替えるものではない(第2)
→SysMLがあるからといってUMLがいらないわけじゃないし、他の言語の代わりになるわけではない

☆SysMLというシステムモデル
◯ユースケース図<ユースケース表記>
・ユースケース
→製品の利用シナリオ
・システムの範囲
・外部と内部を区別する
・アクターとシステムの関係
・内部と外部でやりとりする情報
・ユースケースの関係
・include「埋め込んでいる情報」
・Extend「例外的な活動」
◯要求図 整理・関係
・複合関係、要求の記述やテキストなどを分割する
・<<trace>>(追跡):複数の要求の間に、関係が存在するのを表現する
・<<refine>>(洗練):要求の記述を、詳細に述べたりする
・<<deriveReqt>>(派生):複数の要求の間に、派生する作業が行われたのを表現する
◯要素間のトレーサビリティ構築
・モデルベースアプローチの利点→トレーサビリティ構築を強化する
・要素の間に、関係が存在すれば、情報を手軽に追跡する
・運用:システム変更に対する影響分析、要求カバー分析など