This page (revision-1) was last changed on 23-Aug-2026 01:51 by Hiroaki Tateshita

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
23-Aug-2026 01:51 3 KB Hiroaki Tateshita 複雑システムのシステムアーキテクチャー ==> System_Architecture_of_Complex_System

Page References

Incoming links Outgoing links
Systems Architecture
Systems Architecture

Version management

Difference between version and

At line 1 added 64 lines
[{PageViewPlugin}]
[Systems Engineering]
!!!Abstract
SEの世界では、よくこのSystems Architectureという言葉が出てきます。正確な把握のため、学んだことを書いていきます。
!!!What's new?
*2009年3月27日に内容として間違えている箇所（受注者、発注者が逆！？）があり、修正すると同時に、[Thinking Outside the Box]と[DoDAF]へのリンクを追加し、Referenceを一つ追加しました。
*2009年5月6日に[System_Architecture_of_Complex_System|3]という項目を追加しました。
!!!Topic
!!Systems Architectureって何？
|グルーピングされた機能とその相互関係を決めたもの（[Eisner 2008, 259|Systems Engineering#Reference]）。構造化されたコンポーネントとその関係。設計の原則・ガイドラインとなるもの（[Eisner 2008, 266|1]）。
!!どうやって作るの？
|ここでは、Eisner先生の提案する費用対効果アプローチの手順について紹介します。（[Eisner 2008, 270|1]）。
*システム要求（System Requirements）
|（システムのミッションは既に定義されている状態と考えると、）ミッションを実現するために何をシステムに要求すべきかを分析するのがここ。システムを外部発注する場合は、ユーザは、基本的にここまで実施する。自分の経験からすると、これが仕様書になる。この情報をもとにいわゆるRequest For Proposal（RFP）が行われる。
*機能分析・分解（Function Analysis/Decomposition)
|要求分析の結果を受け、その要求を満たすために、このシステムにどんな機能が必要かを分析・分解する。システムが発注される場合は、これは、受注側が発注者に提案するための検討作業の一部となる。システムエンジニアの知識と経験の見せどころであります。うまくDecomposeしないと、とくに内部インタフェースで困ることになります。暗黙知が必要な部分ですね。
*アーキテクチャの案の作成（Synthesis）
|機能分析の結果を受け、それを具体的に何をどう組み合わせて実現するかを考えます。システムが発注される場合は、ここは受注者側の技術と経験の見せどころです。発注者側にシステム構成案を提示します。おそらくコストと一緒に。ここからは、Eisnerアプローチの特徴となるのですが、ここで受注者は、[費用対効果|CostEffective]を意識した提案をする必要があります。Eisner先生によるとここで３つの選択肢（Alternative）を考えるそうです。その３つとは（１）ケチだけどぎりぎり要求を満たすものlow cost、（２）豪勢だけどとてもコストが高いものhigh performance or effective、そして（３）コストエフェクティブ[CostEffective]なものです。詳しくは、[費用対効果|CostEffective]のページ参照。
|Eisner先生によると、この3つの選択肢を考えることが、Inside the Box Thinkingから[Outside The Box Thinking|Thinking Outside the Box]にレベルアップすることにつながるとのこと([Eisner 2005|2], 47)。
*アーキテクチャの選択
|アーキテクチャの案の選択肢から、ひとつを経営判断として選択します。システムが発注される場合は、受注者側の提案を受け、選択します。
*他
|Eisner先生曰く、アーキテクチャに対し、いろいろと解析・分析するようです。
##評価計画
##ライフサイクルコストの見積もり
##リスク分析
##Concurrent Engineering
*フレームワーク
|DoD（アメリカの国防省）がシステムアーキテクチャーに関するフレームワークを作っています（[Eisner 2008, 265|#cite1]）。いわゆる[DoDAF]（Department of Defense Architecture Framework）のこと。詳細は[こちら|DoDAF]へ。
|Eisnerアプローチと[DoDAF]のアプローチは、両立できると考えます。それは、対象が異なるからです。Eisnerアプローチは、どのように[CostEffective]なアーキテクチャーを選択するかという方法論であり、DoDAFは、どのようなアーキテクチャーが素晴らしいかを示すものであるからです。
[#3]
*[System_Architecture_of_Complex_System]
|近年[SEにおける複雑さ]で登場するような複雑システムを扱う機会が増えています。そうです。世の中はどんどん複雑化しているのです。それは進化ともいえます。[ここ|System_Architecture_of_Complex_System]では、そんな複雑システムをどうArchitectしていくかを考えたいと思います。
!!具体的には？
*情報システム
|ある情報システムについて、ハードウェアは何にするか、どこの会社のどの製品のどういう構成とするか。要求されるレスポンスを十分に実現できるスペックはどれくらいか。ミドルウェアは何にするか、データベースソフトをどれにするか。どの機能に対し、COTS（既製品のソフトウェア）をどう活用するか、それともスクラッチ（作りこみ）とするか。 このあたりを決めたものがSystem Architectureになると思います。
|ただ、Eisner先生は、Architecture designの次にもうSubsystem designが来ると説明しているので、もしかしたら、自分の考える基本設計とこのSystem Architectureは、結構かぶっているのではとも思います。
*[Future_Emergency_Medical_Support_System]
|SEの授業で、実際にシステムアーキテクチャーを作ってみようというプロジェクトをやることになりました。その記録を[こちら|Future_Emergency_Medical_Support_System]に書きます。
*[Damage Mitigation System for Communication during Disaster]
|問題解決の授業で、津波やハリケーンのような災害時に発生する通信障害を改善することができないかということを考えることになりました。その記録を[こちら|Damage Mitigation System for Communication during Disaster]に書きます。
*[Food_Delivery_Service_Support_System]
|データベース設計の授業で、料理出前代行サービスを行っている小さな会社のビジネスプロセスを支援するシステムの設計を行うことになりました。その記録を[こちら|Food_Delivery_Service_Support_System]に書きます。
!!!Reference
#[#1]Eisner, Howard. Essentials of Project and Systems Engineering Management. 3rd ed. Hoboken, N.J.: John Wiley & Sons, 2008
#[#2]Eisner, Howard. 2005. Managing complex systems : Thinking outside the box. Wiley series in systems engineering and management. Hoboken, N.J.: John Wiley.
This page (revision-) was last changed on 23-Aug-2026 01:51 by Hiroaki TateshitaTop