2017年06月10日

サイバーセキュリティ研究開発戦略

内閣府サイバーセキュリティセンター(NISC)の作成したサイバーセキュリティ研究開発戦略(案)において、「想定できない変化に対応するための全体設計(デザイン)」の対応例として、階層化FDIRを紹介いただきました。
セキィリティの技術もどんどん発展しており、少し先になると、どのような技術が出てくるかわからないため、このようなリスク対応のデザインが必要となると考えられるようです。
内閣府サイバーセキュリティセンター(NISC)の作成したサイバーセキュリティ研究開発戦略(案)はこちらです。

posted by しらぴー at 02:47| Comment(0) | システムズエンジニアリング

2016年09月15日

アーキテクチャとアーキテクティング

アーキテクチャとは何か、アーキテクティングとは何か。よく聞かれるので簡単に説明をしておきたいと思う。
もちろん、アーキテクチャとは、もとともは建築物のことを指すものである。しかしながら、現在では、CPUのアーキテクチャや製品のアーキテクチャなどの言葉があるとおり、より広く使われるものである。
アーキテクチャとは、“システムと外界(コンテクスト)との関係”及び“システムを構成する要素とその要素間の関係”のことを指す。
慶應SDMでも価値交換のアーキテクチャを表すために価値連鎖分析(CVCA:Customer Value Chain Analysis)や、欲求のアーキテクチャを表す欲求連鎖分析(WCA : Wants Chain Analysis)なども使ったりする。

アーキテクティングとは、アーキテクチャを設計する行為をさして呼ばれるものである。一般的にアーキテクティングを説明すると、大きく以下の2つのポイントが重要となる。
•複数の視点(viewpoint)からシステムを見て、それぞれの視点における要素と要素間の関係をデザインする
•デザイン結果として見えるもの(view)の重ねあわせ(Allocation)を実施する
これをISO/IEC/IEEE 42010 Systems and software engineering – Architecture descriptionでは、以下のように示している。
つまり、対象となるシステム(System of Interest)にはアーキテクチャが存在する。また、対象となるシステムにはステークホルダ(Stakeholder)が存在する。そのステークホルダには関心事(Concern)があり、その関心事に対応した視点(Viewpoint)を設定することができる。その視点から見えるもの(View)が複数存在し、視点と視点から見えるものを集めたものがシステムのアーキテクチャの表現(Architecture Description)である。
具体的には、以下のように考えることができる。一般的な技術システムでは、ステークホルダとして、利用者と開発者が考えられる。利用者としてはどのように使うのか、どのような機能を持っているのかといったことが気になる。一方で、開発者としてはどのように機能を実現するかがきになると考えられる。このため、どのように使われるかの視点(運用視点:Operational Viewpoint)での設計(Operational View)と、どのような機能をどのようなサブ機能で実現するかの視点(機能視点:Functional Viewpoint)での設計(Functional View)と、どのようにサブ機能をハードウェアやソフトウェアで実現するかの視点(物理視点:Physical Viewpoint)での設計(Physical View)で考える。運用をどのような機能要素で実現し、機能要素をどのような物理要素で実現するかを重ねあわせによって決定する。これが一般的な技術システムにおけるアーキテクチャ設計である。同様なことを、組織の設計では、役割(役割視点)と組織(組織視点)で設計するなどによって実現できる。
System Architectureに関する名著としては、"the art of systems architecting"がある。この本では、ArchitectingはEngineeringよりもよりArt側の側面が強く、Science側の側面が弱いといっている。
実際、Architectingでは、解空間が広く、自由度が高いために、いわゆるセンスのようなものによるところが大きい。(もちろん、このセンスはある程度、後天的に身につけることが可能である)
System of SystemのArchitectureとなると、これまたいろいろな難しさがでてくるのであるが・・・・・
posted by しらぴー at 21:07| Comment(0) | システムズエンジニアリング

2015年09月14日

モデルベース・システムズエンジニアリング (MBSE)の進め方

最近、いろいろなところで、いろいろな会社の人から、モデルベース・システムズエンジニアリングの相談を受けます。そして、すごく多いのが、「Sysmlを使って書いてみたんですけど・・・・」という相談です。
いつも、「ん?」と思うのですが、あまりにも多くこのような話の持ってこられ方をするので、「なんでこんなことになっているんだろう」と不思議に思ってしまいます。
もちろん、「モデルベース・システムズエンジニアリング」というからには、「モデル」を活用した「システムズエンジニアリング」であることには違いないのですが、システムは多様ですし、その設計のアプローチも多様なので、そんなに単純にはすすみません。
自分としても、エアバス社(当時のダイムラークライスラーエアロスペース、後のEADS Astrium社)に駐在していたいときに、モデルベースシステムズエンジニアリング(MBSE)を立ち上げたメンバーの一人だったので、その立ち上げのときの苦労とアプローチをはっきりと覚えています。(ちなみに、そのエアバス社は、SysMLを作ったメンバー会社の一つです)
では、当時はどんな議論からはじめていたかというと、まずは、何のためにモデルベースシステムズエンジニアリングをおこなうのか、という点です。コスト削減のためなのか、スケジュール短縮のためなのか、あるいは品質向上のためなのか、目的によって、そのあとの検討が全くかわってきますので、まずはそこを明確にしました。もちろん、自社の戦略ははっきりしていますので、ここではそれほど時間がかかりませんでした。
次におこなったのが、では、開発プロセスの中で、どこをどのような(抽象度の)モデルにすれば、その目的を実現できるかの検討でした。これは、開発プロセスを明確にし、どこでどのようなモデルがあれば、よいか、そのためにはどのような情報が必要なのか、といったことを一つ一つ検討し、ライフサイクルを通じてシステムモデルを活用することで上記の目的が実現できるモデルベース開発をデザインすることでした。つまり、現在モデル化をしていない何を、どのようなモデルにするか。あるいは、現在すでにモデル化をしている何を、どのようなモデルに変更するかを考えることです。目的を考え、このモデルベース開発のアプローチをデザインすることだけで、ほぼ1年を有しました。
その後、どのようなモデルを活用するか、とうことを考え始めたのですが、適切にシステムモデルを標記するための記述法がなかったために、SysMLを作る方向に進みました。
ちなみに、結果として、当該部署ではSysMLは使わないこととなりました。あまりにも汎用的すぎて、目的のためには”Too much"だったようです。
もしモデルベースシステムズエンジニアリングをはじめたい方は、もちろん、SysMLの勉強として、いろいろなものをSysMLの標記法で書いてみるのはいいですが、本格的に進めるためには、やっぱり上記のようなことをしないと単に書いてみただけで、目的に適合しない活動になってしまうようです。
でも、そのためには、まずはシステムズエンジニアリングを理解しないと検討すらできないという問題点にぶつかってしまう場合も多いのですが。。。。




posted by しらぴー at 20:56| Comment(0) | システムズエンジニアリング