これも・・・・

これは授業の履修生向けに送信したメールですが，
結構，システムエンジニアリングの大事なことをしゃべっているので，
ここにも残しておきましょう．．．．．



1.      Specifying stakeholder in MECE at employing scenario graph.
Read your text book, named Visualizing Project Management, section “IDENTIFYING THE PROJECT STAKEHOLDERS”  starting at ”page 12.
Page 14 has big hint.  There is main stakeholder’s classification: Customer & users，Project Participant，Marketplace and Professional societies，regulatory, bodies and standards organization.
If you prepare these 4 viewpoints and classify stakeholders according to each of them, in general, serious oversight can be avoided.

１．      コンテキストをシナリオグラフで作成するときのMECE
特にWHOに関し，Stakeholder　の見落としが無いようにと，授業でお伝えしました．
利用者としてのＷＨＯをMECEに並べる，提供者としてのＷＨＯをMECEに並べる，，，，キリがないようにも思えます．どこまでおさえればよいか．
このヒントは，教科書VPMの12ページの下の方から始まる節「IDENTIFYING THE PROJECT STAKEHOLDERS」に書かれています．14ページにあるCustomer & users，Project Participant，MarketplaceそれにProfessional societies，regulatory, bodies and standards organization ，この4種類のwhoの視点でそれぞれMECEに整理され，どれを外すかSCOPEを決めてあれば，Stakeholderの見逃しによる大きな失敗は避けられます．



２．      Systems Architecture (1)
It is the top layer which is how to realize the system technically.
It’s functional structure which you select from your choices.
You had better read page 10 in Incose SE Handbook, if you have no confidence about the number of components in your architecture.
There is useful explanation about magic number 7 +/- 2.

2.      システムアーキテクチャ　その１
実現する方法であるシステムをどういう構成にするかの最上位の決定になります．Functionのdecomposition結果の最下段が，componentになるわけですが，30個のcomponentでは細かすぎるような感じであり，かといって3個では少なすぎるような感じがする．こんな混乱は，初心者のエンジニアがよくおこします．この解決のヒントは，Incose SE Handbookの10ページの最後の段落に書かれています．マジックナンバー（？）として紹介されている7±2です．従って，5個くらいから9個くらいのcomponent数であれば，（なんとなく）よさげであると見定めることができます．



3.      Systems Architecture (2)
Also you can get useful information on page 427 in VPM.
There is clear explanation about systems architecture.
Components, interfaces among them and their interrelationships are needed.
You can use any presentation methodology for your architecture illustration.
SysML or OPM, lectured in ALPS, can be utilized as well as UML.

３．システムアーキテクチャ　その２
上記のような目安に加え，やはり必要になるのは論理的な正規化です．この点に関してはVPMの用語集（427ページ）を参照してください．Architectureの説明にあるように各componentとそれらを何でつなぐか（つまりinterface）と，繋がれたcomponent間の関係が記述されたものがarchitectureです．日本の多くのＩＴ業界のエンジニアは，機能ブロック図を描きアーキテクチャとしていますが，これはシステムデザインの際に問題を発生しやすくします．アーキテクチャは，システム構成を決定する際のグランドルールです．Componentとinterfaceとそれでつながれたcomponent同士の関係を明示してください．図だけでも，図と説明分を用いてもかまいません，表現方法としてUMLが一般的ですがSysMLやALPSで習うOPMでもかまいません．

Enjoy your assignment!

SEにおける日本のガラパゴス化状況

情報システム学会の研究会で、
ずーーーーーーーーーーーーーーーーーっと
気になっていた話題を話しました。

日本の(特にＩＴ業界のいう)Systems Engineeringが世界標準とかけはなれたところにあるという点。

思いっきりぶちまけました。
上から目線で、
高飛車に・・・・・(^^;;


失礼いたしました。
でもね、
本当に、日本の世界に対するＳＥ力を底上げしたいと願っているのです。

最終ページの「提言」。
ぜひ、ご検討ください。

利用した資料はここです。