ソフトウェアからシステムに視野を広げる / Zoom out from Software

Slide 1

Slide 1 text

ソフトウェアからシステムに視野を広げるシステムズエンジニアリング、SysML、システムアーキテクチャ設計 2020/3/14 井芹洋輝 1

Slide 2

Slide 2 text

この資料について ⚫目的 • 知識・視野をソフトウェア→システムに拡げる • システムズエンジニアリングとSysMLについて概要を知る • ソフトウェアと非ソフトウェアの責務割り当てを体験する ⚫対象者 • 組み込み開発 • ソフトウェア開発入門者 2

Slide 3

Slide 3 text

なぜソフトウェアからシステムに視野を広げるのか ⚫メカ・エレキ・ソフト等複数の領域が複雑に連携するシステムでは、高度（より高性能、より複雑な機能等）な製品の実現に、システムレベルのエンジニアリングの工夫が不可欠なため ⚫今回のアウトライン • システムレベルのアプローチを知る： • システムズエンジニアリング/SysML • システムレベルのアーキテクチャを知る： • システムアーキテクチャ設計 • ソフトとソフト以外の連携の仕組みを考える： • ワークショップ 3 知識を得る考え方を学ぶ

Slide 4

Slide 4 text

システムズエンジニアリング概要 4

Slide 5

Slide 5 text

システムとは ⚫「情報を処理することによって、事前に定義された何らかの目標を達成するように系統立てられている要素の集合あるいは要素の配置」 • （実践ソフトウェアエンジニアリング第二版ロジャー S.プレスマン） ⚫様々な粒度で使われる言葉 5 プロダクトシステム筐体/機械ソフトハードエンタープライズシステムクラウドクライアントクライアントハードソフト

Slide 6

Slide 6 text

システムズエンジニアリングとは ⚫「システムズエンジニアリングとは、成功したシステムズを実現するための、様々な領域を横断するアプローチ・手法である」 • （INCOSEより翻訳） ⚫プロダクトシステムのシステムズエンジニアリングは、ビジネス目標の達成のため、ステークホルダのニーズ・シーズから、メカ・ソフト・ハードなど様々な領域を横断して、現実のプロダクトを実現するアプローチ・手法 6

Slide 7

Slide 7 text

システムズエンジニアリングの体系や標準 ⚫ISO/IEC 15288:2015 • システムライフサイクルプロセスの標準。システムズエンジニアリングのプロセス標準として参照されることが多い。旧版はJIS化されている ⚫INCOSE, OOSEM • 前者はシステムズエンジニアリングについての体系の解説書 • 後者は前者で解説されるMBSEのプロセス ⚫Harmony for Systems Engineering • システムズエンジニアリングについてのIBMのプロセス体系 ⚫SEBOK • システムズエンジニアリングのBOK。ウェブで公開されている • https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowled ge_(SEBoK) 7

Slide 8

Slide 8 text

システムズエンジニアリングにおける開発プロセス (V字モデルへのマッピング) 8 ステークホルダ要求定義システム要求定義システムアーキテクチャ設計サブシステム分析・設計サブシステム実装サブシステム単体検証サブシステム結合および検証システム結合および検証システム妥当性確認サブシステムごとにプロセスを運用する。複数階層化する場合も

Slide 9

Slide 9 text

システムズエンジニアリングでのアクティビティ 9 フェーズ目的アクティビティステークホルダ要求定義ステークホルダにとって必要なサービスを実現するために、ステークホルダからシステムに対する要求を定義する・ステークホルダの識別・ステークホルダのニーズ・シーズの収集・ステークホルダの要求の定義システム要求定義ステークホルダの要求を、実現可能なシステムの要求に仕様化する・ステークホルダとの折衝・システムの要求と制約の定義スコープの定義機能、制約、品質の定義システムアーキテクチャ設計システム要求の実現手段を、サブシステム開発が可能になるまで分析・設計する・外部仕様の具体化・構成要素やその関係についての仕様化・設計方針の策定

Slide 10

Slide 10 text

システムズエンジニアリングで心がけること ⚫Interdisciplinary(複数の領域を横断) ⚫Broad Scope（システム全体、ライフサイクル全体を扱う） ⚫Iterative（反復的に洗練させる） 10

Slide 11

Slide 11 text

複数の領域を横断・システム全体プロダクトシステムズでのサブシステム（例：カメラ） 11 システム分析・設計光学系システムレフ制御システムセンサ制御・画像処理システムネットワーク・メディア制御システムモニタシステムメカ開発エレキ開発ソフト開発それぞれでサブシステムの開発プロセスを運用する筐体・外装デジタル回路開発アナログ回路開発 FPGA開発全体でエンジニアリングを進める

Slide 12

Slide 12 text

ライフサイクル全体プロダクトシステムズのライフサイクル（複数のタイプがある） 12 プロジェクトプロセステクニカルプロセス合意プロセスイネーブリングプロセスニーズの概念化～システムの実現～利用～進化～廃棄システムライフサイクルシステムオブシステムズライフサイクル関連システムのライフサイクル派生システムのライフサイクルシステムプロダクトラインライフサイクル対象に応じたスコープでエンジニアリングを行う

Slide 13

Slide 13 text

反復的な洗練 13 基礎研究基礎開発開発発展要求分析設計実装テスト発展反復的なエンジニアリングで複雑・大規模・困難な問題に対応する

Slide 14

Slide 14 text

システムズエンジニアリングでのモデリングの活用 14

Slide 15

Slide 15 text

モデル、モデリング（モデル化）とは ⚫「モデル化とは、認知したいと考えている構造、振る舞い、現象などについて、別の効率的な形式や方法による表現を用いることである」 • (「The Nature of Modeling」。訳はSQuBOK V2) ⚫「モデルとは『ある人によっての、ある状況、あるいはある状況についての概念の明示的な解釈』です」 • (「UMLモデリングの本質」にて、システム仕様の分析学の引用を用いた解説) 15

Slide 16

Slide 16 text

モデル、モデリング（モデル化）とは ⚫「目的を達成するために、対象の特定の特質を、特定の形式で表現する」のがモデリング ⚫目的達成にフォーカスするため、以下を活用する • 抽象化する • 削る • 構造化する • 形式化する • 分割する 16

Slide 17

Slide 17 text

モデリングの恩恵 1. 理解を助ける • 例）大規模な実装をクラス図で抽象化し俯瞰 2. 思考を深める • 例）マインドマップでアイデアを掘り下げ 3. 共有を助ける • 例）ロジックツリーで第三者に問題を明示化 4. 協力を支える • 例）構造モデルを使って分担決め 5. モデル対応ツール・手法の恩恵を得る • 例）モデル駆動テストで仕様を検証 17 モデリングでより効率的に物事をこなすより難しい物事をこなす仲間とシナジーを発揮するモデリング＝表現の工夫で人間の能力を拡張する

Slide 18

Slide 18 text

システムズエンジニアリングではモデリングの活躍所が多数 ⚫システムズエンジニアリングで求められること： ⚫システムズエンジニアリングで活用できるモデル記法やモデリング手法 • SysML/UML/RDRA/構造化設計手法など多数 18 ステークホルダとの連携・合意形成仲間との協業システムとして実現複雑・大規模様々な領域を横断多様なシステムと連携 × 【モデリングの恩恵】 1.理解を助ける 2.思考を深める 3.共有を助ける 4.協力を支える 5.モデル対応ツール・手法の恩恵を得る要求にジャストフィットする

Slide 19

Slide 19 text

MBSE（モデルベースドシステムズエンジニアリング） ⚫モデルに基づいてシステムズエンジニアリングのアクティビティを進めるアプローチ ⚫著名な手法 • Harmony for Systems Engineering • OOSEM • いずれもSysMLを活用したシステムズエンジニアリング手法 19

Slide 20

Slide 20 text

SysMLとは ⚫OMG Systems Modeling Languageの略システムズエンジニアリングを支援するためのモデリング言語 ⚫UMLからの拡張： • UMLと同一 • シーケンス図、ステートマシン図、ユースケース図、パッケージ図 • UMLを改変 • アクティビティ図、ブロック定義図（元：クラス図）、内部ブロック図（元：複合構造図） • UMLから削除 • 上記で触れていないUMLダイアグラム • 新規 • 要求図、パラメトリック図 20

Slide 21

Slide 21 text

システムズエンジニアリングにおけるSysMLの活用 1. ステークホルダ要求定義/2. システム要求定義 21 ●ブロック定義図コンテキストを分析・定義する ●要求図要求を分析・定義する ●アクティビティ図（外部）ユースケースの詳細を分析する ●ユースケース図アクターとシステムの関係を分析する反復的に洗練させる

Slide 22

Slide 22 text

システムズエンジニアリングにおけるSysMLの活用 3. システムアーキテクチャ設計 22 ●システム要求 ●ブロック定義図システムの構成要素を設計する ●アクティビティ図（内部）内部要素に責務を配置する ●シーケンス図基本機能のシーケンスを分析する ●ステートマシン図内部状態を分析する反復的に洗練させる ●内部ブロック図内部構造を設計する

Slide 23

Slide 23 text

【補足】SysMLを現場で活用するためには 23 モデル記法の知識モデルの活用手法の知識モデルで課題解決する能力 23 【勉強する】 SysML/UML 【勉強・実践する】 MBSE(OOSEM、Harmony for Systems Engineering）【実践して磨く】優れたモデリングから学ぶ優れたエンジニアリングから学ぶ日頃の業務で、モデル活用経験を重ね、継続的に磨く必要スキル

Slide 24

Slide 24 text

システムアーキテクチャ設計 24

Slide 25

Slide 25 text

システムアーキテクチャとその役割 25

Slide 26

Slide 26 text

システムアーキテクチャとは ⚫システムアーキテクチャとは、システム要求を実現するためにシステムをどう構成するかという設計判断の集合 • 外部IF、内部構成、内部構成の関わり合い、内部の設計方針 26 ビジネス開発ステークホルダ・システムアーキテクチャは橋渡し・ビジネス目標を達成するために、ステークホルダ要求の実現方針を開発に示す

Slide 27

Slide 27 text

橋渡しをする人：システムアーキテクトの役割 ⚫システムズエンジニアリングとして、優れた技能・経験に基づいて、内外のステークホルダと折衝し、各領域のスペシャリストとすり合わせしながら、ビジネス目標を達成するアーキテクチャを育て上げる • 広い視野（ドメイン、コンテキスト、時系列）に基づいた問題と解決策の分析 • 要求・制約の折衝 • 要求と実現手段のすり合わせ • 優れた技能・経験に基づいた実現手段の設計 • 組織のアーキテクチャスキルの育成 • 学習サイクルによる継続的改善 27

Slide 28

Slide 28 text

アンチパターン：象牙の塔のアーキテクト ⚫開発の現実・現場から距離をとって、トップダウンでシステムアーキテクチャを指示するアーキテクト • 背景： • 手法や方法論など教条への狂信 • 上流工程と下流工程の断絶 • コンサルなど外部リソースへのアーキテクティングの丸投げ • WFで手戻りを悪として学習フィードバックを否定した成れの果て • 属人的要因 →ステークホルダ・開発・ビジネスが断絶しプロジェクト失敗へ 28

Slide 29

Slide 29 text

システムアーキテクチャによる橋渡し：様々なステークホルダへの考慮 ⚫例：ユーザ要求だけでなく、内部のステークホルダの要求・制約を取り込み、プロジェクトリスクを軽減する • 設計、製造、設置、保守、法規など内部のステークホルダの要求の補完 • 例）製造時検査の自動化の要求を補強 • 実現性などの開発制約に基づいた機能の見直し • 例）早期にフィージビリティスタディを実施し、実現困難と判断した要求を早期に外す 29

Slide 30

Slide 30 text

システムアーキテクチャによる橋渡し：様々な視座や領域を横断 ⚫ビジネスの観点で要求の実現手段を折衝する • 例）必要最低限までハードウェア性能を最適化して部品コストを下げ、利益を上げる（ハードウェアは変動費に直結） • 例）システムズで稼ぐ。レンズで利益を上げる方針をとることで、カメラ本体の原価目標を緩和 ⚫それぞれの領域の強み・弱みを補完しあい、シナジーを発揮する • 例） 30 ソフトウェア FPGA 低速な逐次処理高速な並行処理複雑な処理（フロー、状態、高精度）が得意主に論理演算が中心 FPGAによる映像処理＆ソフトによる複雑なアルゴリズム処理補佐で、高画素の複雑な映像処理を実現

Slide 31

Slide 31 text

システムアーキテクチャ設計のアプローチ 31

Slide 32

Slide 32 text

システムアーキテクチャ設計のアプローチ：重要なメカニズムに注力する ⚫重要なシステム要求、アーキテクチャにとって重要な要求・制約に対するメカニズムに注力する • 例）ビジネスを左右する重大な機能・性能、実現の困難な基本機能 ⚫最大責任時点（プロジェクトにとって、最も効果的な設計判断のタイミング）の早いメカニズムから注力する • 例） 32 要素のタイプ最大責任時点メカ早エレキ（基板設計）早エレキ（FPGA）遅ソフトウェア遅課題最大責任時点未経験の技術早世の中に存在しない機能極早前機種からの流用技術遅

Slide 33

Slide 33 text

システムアーキテクチャ設計のアプローチ：責務を分離して問題を扱いやすくする ⚫大きな問題をより小さく、より管理しやすい問題へと変える ⚫人々の協働の仕方を示す 33 システム要求重要なアーキテクチャメカニズムメカエレキソフトサブシステムメカエレキソフトサブシステムメカエレキソフト過去の蓄積、反復による学習フィードバック、一般的な知見重要なアーキテクチャ設計方針

Slide 34

Slide 34 text

ワークショップサブシステムへの責務割り当て体験 34

Slide 35

Slide 35 text

ワークショップ1：AEシステムの責務割り当て ⚫課題： • 動画カメラのAE（映像明るさを適正値に調整する）の責務割り当てを行う ⚫作成するもの： • アクティビティ図 ⚫対象システム 35 内部ブロック図

Slide 36

Slide 36 text

ワークショップ1：AEシステムの責務割り当て ⚫AEのアルゴリズム 1. 映像の明るさ値を計算する 2. 映像明るさ値と理想明るさ値から、明るさ補正値を計算する 3. 明るさ補正値から、センサ制御ユニットを制御し、映像明るさを調整する ⚫各パートの処理ごとの得意・不得意 36 処理センサ制御ユニット画像処理ユニット (FPGA) 中央制御ユニット（ソフトウェア）映像の出力〇 × × 映像の明るさ値の計算 × 〇 × 明るさ補正値の計算 × △ 〇センサ制御ユニットの制御 × × 〇映像明るさの調整〇 △ × 〇：得意、△：やや得意、×：実現不能

Slide 37

Slide 37 text

ワークショップ1：AEシステムの責務割り当て ⚫コンポーネントに処理の責務を割り当て、アクティビティ図で表現しよう 37 ここを埋める

Slide 38

Slide 38 text

アクティビティ図のサンプル 38

Slide 39

Slide 39 text

ワークショップ2：AEシステムの責務見直し ⚫課題 • 前の課題において「明るさ補正値の計算」が、処理速度不足でソフトウェアにて実装不能なことが分かった。 • 責務割り当てを見直してアクティビティ図を修正してほしい ⚫作成するもの • アクティビティ図 39

Slide 40

Slide 40 text

まとめ ⚫システムズエンジニアリング ⚫SysML ⚫システムアーキテクチャ設計 40