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