Cost-Effective
最終更新：
hirotate1103 2008年10月31日(金) 05:09:59履歴
Systems Approach, Systems Architecture
Abstract
How to
Reference
Abstract 
SEでは、この費用対効果の高い選択を行っていくことが重要とのことで、授業でものすごい回数繰り返して教授が強調していました。ただし、顧客ごとに要求がことなるため、顧客ごとに答えが違うことに注意。
How to
- Systhesis
以下の表を埋めることをSysthesisというらしい。＊の部分に必要な機能および一段階分解した機能を書き、その実現方法を3つのパターンで考えていくことらしい
| Functions | subfuncuion | Alternative1 (low cost low effectiveness) | Alternative2 (knee) | Alternative3 (High cost high effectiveness) |
| * | * | # | # | # |
| * | # | # | # | |
| * | # | # | # | |
| * | # | # | # | |
| * | * | # | # | # |
| * | # | # | # | |
| * | # | # | # | |
| * | # | # | # |
- Analysis
Systhesisで行ったことを元に、定量化するのがAnalysisとのこと。Weightは、顧客と相談しながら決める。
| Functions | subfuncuion | Weight | Alternative1 (low cost low effectiveness) | Alternative2 (knee of curve) | Alternative3 (High cost high effectiveness) |
| * | * | w | score | score | score |
| * | w | score | score | score | |
| * | w | score | score | score | |
| * | w | score | score | score | |
| * | * | w | score | score | score |
| * | w | score | score | score | |
| * | w | score | score | score | |
| * | w | score | score | score | |
| total score | Sum(score*weight) | Sum(score*weight) | Sum(score*weight) |
そして下記のグラフを書き、基本的には、Knee of curveを選ぶのがよいとされているらしい。ちなみに点線のようになったら、何か間違えていることが多いので計算方法などをやり直した方がいいとか。そうなのかな。。
- comments
ただ、NASAも含めて、政府関連機関などは、予算の制限という絶対的なものがあり、また、できるだけ安くを求められるところもあるので、必ずしもこの考え方がそのまま当てはまるわけではない。まあ、総合評価方式の参考にもなるかな。
Reference
- Eisner, Howard. Essentials of Project and Systems Engineering Management. 3rd ed. Hoboken, N.J.: John Wiley & Sons, 2008
このページへのコメント
申し訳ない。。返信遅れました。初期の初期？自分の知っている情報システムで例えてみます。まず、発注側でシステムの要求仕様（SubFunctionの機能要求含む）を出して、RFPを行うと思います。次は、受注側で実現方法を考えて、コストの見積もりなどを行って、検討結果を提案することになると思います。この時点で出てくるのが、ここで説明している全体アーキテクチャだと思ってます。そこには、SubFunctionの実現方法も記載されている想定です。（実際は、要求仕様の裏返しの場合が多いですが。）
フェーズとしては、初期の初期で、とりあえずアーキテクチャベースラインを設定するということなのかな。Subfunctionについては、次のフェーズで検討し、再設定するという流れの理解でよいのかな？
ここは、システム全体アーキテクチャーの話で、システム全体の単位として、3つの選択肢があるということです。もちろんFunctionレベルだといろいろと選択肢はあるはずだけど、それらを総合した結果を3つに分けてます。
アーキテクチャーを提案する側からみると、ゴージャスな提案をするか、ケチケチだけどぎりぎり要求は満たすものを提案するか、その中間を狙うか、ということになります。
どうでしょう。。。
ちょっとわからないんだけど、Altanativeを一つ選択すると（たとえばKnee of curve）、その他の選択肢の実現方法は捨ててしまうのかな？Functionによっては、Low costでもよかったり、High cost、High performanceの方がよかったりと、バリエーションもっとある気がしますが。。。