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

Transcript

1. ソフトウェアからシステムに 視野を広げる システムズエンジニアリング、SysML、システムアーキテクチャ設計 2020/3/14 井芹 洋輝 1
2. この資料について ⚫目的 • 知識・視野をソフトウェア→システムに拡げる • システムズエンジニアリングとSysMLについて概要を知る • ソフトウェアと非ソフトウェアの責務割り当てを体験する ⚫対象者 • 組み込み開発 • ソフトウェア開発入門者 2
3. なぜソフトウェアからシステムに視野を広げるのか ⚫メカ・エレキ・ソフト等複数の領域が複雑に連携するシステムでは、 高度（より高性能、より複雑な機能等）な製品の実現に、システムレ ベルのエンジニアリングの工夫が不可欠なため ⚫今回のアウトライン • システムレベルのアプローチを知る： • システムズエンジニアリング/SysML • システムレベルのアーキテクチャを知る： • システムアーキテクチャ設計 • ソフトとソフト以外の連携の仕組みを考える： • ワークショップ 3 知識 を得る 考え方 を学ぶ
4. システムズエンジニアリング概要 4
5. システムとは ⚫「情報を処理することによって、事前に定義された何らかの目標を 達成するように系統立てられている要素の集合あるいは要素の配 置」 • （実践ソフトウェアエンジニアリング第二版 ロジャー S.プレスマン） ⚫様々な粒度で使われる言葉 5 プロダクトシステム 筐体/機械 ソフト ハード エンタープライズシステム クラウド クライアント クライアント ハード ソフト
6. システムズエンジニアリングとは ⚫「システムズエンジニアリングとは、成功したシステムズを実現するた めの、様々な領域を横断するアプローチ・手法である」 • （INCOSEより翻訳） ⚫プロダクトシステムのシステムズエンジニアリングは、 ビジネス目標の達成のため、 ステークホルダのニーズ・シーズから、 メカ・ソフト・ハードなど様々な領域を横断して、 現実のプロダクトを実現するアプローチ・手法 6
7. システムズエンジニアリングの体系や標準 ⚫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
8. システムズエンジニアリングにおける開発プロセス (V字モデルへのマッピング) 8 ステークホルダ 要求定義 システム 要求定義 システムアーキ テクチャ設計 サブシステム 分析・設計 サブシステム 実装 サブシステム 単体検証 サブシステム 結合および検証 システム 結合および検証 システム 妥当性確認 サブシステムごとに プロセスを運用する。 複数階層化する場合も
9. システムズエンジニアリングでのアクティビティ 9 フェーズ 目的 アクティビティ ステークホルダ要求定義 ステークホルダにとって必要なサービ スを実現するために、ステークホルダ からシステムに対する要求を定義す る ・ステークホルダの識別 ・ステークホルダのニーズ・シーズの収集 ・ステークホルダの要求の定義 システム要求定義 ステークホルダの要求を、実現可能 なシステムの要求に仕様化する ・ステークホルダとの折衝 ・システムの要求と制約の定義 スコープの定義 機能、制約、品質の定義 システムアーキテクチャ設計 システム要求の実現手段を、サブシ ステム開発が可能になるまで分析・ 設計する ・外部仕様の具体化 ・構成要素やその関係についての仕様化 ・設計方針の策定
10. システムズエンジニアリングで心がけること ⚫Interdisciplinary(複数の領域を横断) ⚫Broad Scope（システム全体、ライフサイクル全体を扱う） ⚫Iterative（反復的に洗練させる） 10
11. 複数の領域を横断・システム全体 プロダクトシステムズでのサブシステム（例：カメラ） 11 システム分析・ 設計 光学系システム レフ制御システム センサ制御・ 画像処理システム ネットワーク・ メディア制御 システム モニタシステム メカ開発 エレキ開発 ソフト開発 それぞれでサブシステムの開発プロセスを運用する 筐体・外装 デジタル回路開発 アナログ回路開発 FPGA開発 全体でエンジニアリングを 進める
12. ライフサイクル全体 プロダクトシステムズのライフサイクル（複数のタイプがある） 12 プロジェクトプロセス テクニカルプロセス 合意プロセス イネーブリングプロセス ニーズの概念化～システムの実現～利用～進化～廃棄 システムライフサイクル システムオブシステムズライフサイクル 関連システムのライフサイクル 派生システムの ライフサイクル システムプロダクトラインライフサイクル 対象に応じたスコープで エンジニアリングを行う
13. 反復的な洗練 13 基礎研究 基礎開発 開発 発展 要求分析 設計 実装 テスト 発展 反復的なエンジニアリングで複雑・大規模・困難な問題に対応する
14. システムズエンジニアリングでの モデリングの活用 14
15. モデル、モデリング（モデル化）とは ⚫「モデル化とは、認知したいと考えている構造、振る舞い、現象など について、別の効率的な形式や方法による表現を用いることであ る」 • (「The Nature of Modeling」。訳はSQuBOK V2) ⚫「モデルとは『ある人によっての、ある状況、あるいはある状況につい ての概念の明示的な解釈』です」 • (「UMLモデリングの本質」にて、システム仕様の分析学の引用を用いた解 説) 15
16. モデル、モデリング（モデル化）とは ⚫「目的を達成するために、対象の特定の特質を、特定の形式で表現 する」のがモデリング ⚫目的達成にフォーカスするため、以下を活用する • 抽象化する • 削る • 構造化する • 形式化する • 分割する 16
17. モデリングの恩恵 1. 理解を助ける • 例）大規模な実装をクラス図で抽象化し俯瞰 2. 思考を深める • 例）マインドマップでアイデアを掘り下げ 3. 共有を助ける • 例）ロジックツリーで第三者に問題を明示化 4. 協力を支える • 例）構造モデルを使って分担決め 5. モデル対応ツール・手法の恩恵を得る • 例）モデル駆動テストで仕様を検証 17 モデリングで より効率的に物事をこなす より難しい物事をこなす 仲間とシナジーを発揮する モデリング＝ 表現の工夫で人間の 能力を拡張する
18. システムズエンジニアリングではモデリングの活躍所が多数 ⚫システムズエンジニアリングで求められること： ⚫システムズエンジニアリングで活用できるモデル記法やモデリング手法 • SysML/UML/RDRA/構造化設計手法など多数 18 ステークホルダとの連携・合意形成 仲間との協業 システムとして実現 複雑・大規模 様々な領域を横断 多様なシステムと連携 × 【モデリングの恩恵】 1.理解を助ける 2.思考を深める 3.共有を助ける 4.協力を支える 5.モデル対応ツール・手法の恩恵を得る 要求にジャストフィットする
19. MBSE（モデルベースドシステムズエンジニアリング） ⚫モデルに基づいてシステムズエンジニアリングのアクティビティを進め るアプローチ ⚫著名な手法 • Harmony for Systems Engineering • OOSEM • いずれもSysMLを活用したシステムズエンジニアリング手法 19
20. SysMLとは ⚫OMG Systems Modeling Languageの略 システムズエンジニアリングを支援するためのモデリング言語 ⚫UMLからの拡張： • UMLと同一 • シーケンス図、ステートマシン図、ユースケース図、パッケージ図 • UMLを改変 • アクティビティ図、ブロック定義図（元：クラス図）、内部ブロック図（元：複合構造図） • UMLから削除 • 上記で触れていないUMLダイアグラム • 新規 • 要求図、パラメトリック図 20
21. システムズエンジニアリングにおけるSysMLの活用 1. ステークホルダ要求定義/2. システム要求定義 21 •ブロック定義図 コンテキストを分析・定義する •要求図 要求を分析・定義する •アクティビティ図（外部） ユースケースの詳細を分析する •ユースケース図 アクターとシステムの関係を分析する 反復的に洗練させる
22. システムズエンジニアリングにおけるSysMLの活用 3. システムアーキテクチャ設計 22 •システム要求 •ブロック定義図 システムの構成要素を設計する •アクティビティ図（内部） 内部要素に責務を配置する •シーケンス図 基本機能のシーケンスを分析する •ステートマシン図 内部状態を分析する 反復的に洗練させる •内部ブロック図 内部構造を設計する
23. 【補足】SysMLを現場で活用するためには 23 モデル記法の知識 モデルの活用手法 の知識 モデルで課題 解決する能力 23 【勉強する】 SysML/UML 【勉強・実践する】 MBSE(OOSEM、Harmony for Systems Engineering） 【実践して磨く】 優れたモデリングから学ぶ 優れたエンジニアリングから学ぶ 日頃の業務で、モデル活用経験を重ね、継続 的に磨く 必要スキル
24. システムアーキテクチャ設計 24
25. システムアーキテクチャとその役割 25
26. システムアーキテクチャとは ⚫システムアーキテクチャとは、システム要求を実現するためにシステ ムをどう構成するかという設計判断の集合 • 外部IF、内部構成、内部構成の関わり合い、内部の設計方針 26 ビジネス 開発 ステー クホルダ ・システムアーキテクチャは橋渡し ・ビジネス目標を達成するために、ステークホルダ要求 の実現方針を開発に示す
27. 橋渡しをする人：システムアーキテクトの役割 ⚫システムズエンジニアリングとして、優れた技能・経験に基づいて、 内外のステークホルダと折衝し、各領域のスペシャリストとすり合わ せしながら、ビジネス目標を達成するアーキテクチャを育て上げる • 広い視野（ドメイン、コンテキスト、時系列）に基づいた問題と解決策の分析 • 要求・制約の折衝 • 要求と実現手段のすり合わせ • 優れた技能・経験に基づいた実現手段の設計 • 組織のアーキテクチャスキルの育成 • 学習サイクルによる継続的改善 27
28. アンチパターン：象牙の塔のアーキテクト ⚫開発の現実・現場から距離をとって、トップダウンでシステムアーキテ クチャを指示するアーキテクト • 背景： • 手法や方法論など教条への狂信 • 上流工程と下流工程の断絶 • コンサルなど外部リソースへのアーキテクティングの丸投げ • WFで手戻りを悪として学習フィードバックを否定した成れの果て • 属人的要因 →ステークホルダ・開発・ビジネスが断絶しプロジェクト失敗へ 28
29. システムアーキテクチャによる橋渡し： 様々なステークホルダへの考慮 ⚫例：ユーザ要求だけでなく、内部のステークホルダの要求・制約を取 り込み、プロジェクトリスクを軽減する • 設計、製造、設置、保守、法規など内部のステークホルダの要求の補完 • 例）製造時検査の自動化の要求を補強 • 実現性などの開発制約に基づいた機能の見直し • 例）早期にフィージビリティスタディを実施し、実現困難と判断した要求を早期に外す 29
30. システムアーキテクチャによる橋渡し： 様々な視座や領域を横断 ⚫ビジネスの観点で要求の実現手段を折衝する • 例）必要最低限までハードウェア性能を最適化して部品コストを下げ、利益 を上げる（ハードウェアは変動費に直結） • 例）システムズで稼ぐ。レンズで利益を上げる方針をとることで、カメラ本体 の原価目標を緩和 ⚫それぞれの領域の強み・弱みを補完しあい、シナジーを発揮する • 例） 30 ソフトウェア FPGA 低速な逐次処理 高速な並行処理 複雑な処理（フロー、状態、高精 度）が得意 主に論理演算が中心 FPGAによる映像処理＆ ソフトによる複雑なアルゴリズム処理補佐 で、高画素の複雑な映像処理を実現
31. システムアーキテクチャ設計のアプローチ 31
32. システムアーキテクチャ設計のアプローチ： 重要なメカニズムに注力する ⚫重要なシステム要求、アーキテクチャにとって重要な要求・制約に 対するメカニズムに注力する • 例）ビジネスを左右する重大な機能・性能、実現の困難な基本機能 ⚫最大責任時点（プロジェクトにとって、最も効果的な設計判断のタイ ミング）の早いメカニズムから注力する • 例） 32 要素のタイプ 最大責任時点 メカ 早 エレキ（基板設計） 早 エレキ（FPGA） 遅 ソフトウェア 遅 課題 最大責任時点 未経験の技術 早 世の中に存在しない機能 極早 前機種からの流用技術 遅
33. システムアーキテクチャ設計のアプローチ： 責務を分離して問題を扱いやすくする ⚫大きな問題をより小さく、より管理しやすい問題へと変える ⚫人々の協働の仕方を示す 33 システム要求 重要な アーキテクチャメカニズム メカ エレキ ソフト サブシステム メカ エレキ ソフト サブシステム メカ エレキ ソフト 過去の蓄積、反復による学習フィードバック、一般的な知見 重要な アーキテクチャ設計方針
34. ワークショップ サブシステムへの責務割り当て体験 34
35. ワークショップ1：AEシステムの責務割り当て ⚫課題： • 動画カメラのAE（映像明るさを適正値に調整する）の責務割り当てを行う ⚫作成するもの： • アクティビティ図 ⚫対象システム 35 内部ブロック図
36. ワークショップ1：AEシステムの責務割り当て ⚫AEのアルゴリズム 1. 映像の明るさ値を計算する 2. 映像明るさ値と理想明るさ値から、明るさ補正値を計算する 3. 明るさ補正値から、センサ制御ユニットを制御し、映像明るさを調整する ⚫各パートの処理ごとの得意・不得意 36 処理 センサ制御ユニット 画像処理ユニット (FPGA) 中央制御ユニット （ソフトウェア） 映像の出力 〇 × × 映像の明るさ値の計算 × 〇 × 明るさ補正値の計算 × △ 〇 センサ制御ユニットの制御 × × 〇 映像明るさの調整 〇 △ × 〇：得意、△：やや得意、×：実現不能
37. ワークショップ1：AEシステムの責務割り当て ⚫コンポーネントに処理の責務を割り当て、アクティビティ図で表現しよう 37 ここを埋める
38. アクティビティ図のサンプル 38
39. ワークショップ2：AEシステムの責務見直し ⚫課題 • 前の課題において「明るさ補正値の計算」が、処理速度不足でソフトウェア にて実装不能なことが分かった。 • 責務割り当てを見直してアクティビティ図を修正してほしい ⚫作成するもの • アクティビティ図 39
40. まとめ ⚫システムズエンジニアリング ⚫SysML ⚫システムアーキテクチャ設計 40