共通フレーム２００７見て、気づいた！
共通フレーム２００７では、以下のように開発が進む
1. システム要件定義
2. システム方式設計
3. ソフトウェア要件定義
4. ソフトウェア方式設計・ソフトウェア詳細設計
5. ソフトウェアコード作成及びテスト
6. ソフトウェア結合・ソフトウェア適格性確認テスト
7. システム結合・システム適格性確認テスト
8. ソフトウェア導入
9. ソフトウェア受入れ
10. ソフトウェア保守
つまり、要求分析を行う（＝ソフトウエア要件定義）前に、
ＲＦＰかなにかで、大体システムの大まかな像は決まっていると考えられる。
（ハードとか大体のネットワーク、ＯＳくらいまで、ＤＢも？）
もちろん、アジャイルなんかもあるから、この順番どおり
やるとは限らないけれど、でも、この順番って、でたらめでも
ないだろうから（ウォーターフォールなら、この順でＯＫだし）
まあ、そう想定しているのだろう。
というか、かりにアジャイルでも、普通、仕事の上ではそうだ。
もう、要求仕様の前に、ＲＦＰでかなりの部分決まっている。
開発言語、フレームワークまで決まっていることも多いと思う。
というのも、ＲＦＰに答える形で出す提案書で、開発費用をださないと
いけないけど、開発費用をだすには、開発言語とフレームワークまで
決まっていないと、お金が出ない（ＣＯＢＯＬの人とＪａｖａの人では、
単価や見つけやすさなどがいろいろ違う）
だから、要求仕様の前に、ＲＦＰがあって、（かりにＲＦＰがなかったとしても）
要求仕様前にシステムが大体決まっているというのは、一般的な話。
ところが、大学は、要求仕様から始まる。
超上流っていうのもあるけど、大学等で行う超上流は、目的から要求を出す手法で
あって、システムのハードなどを考えることではない。
それは、ソフトウエア方式の決定のところできまる。
要求仕様では、Ｈｏｗを決定せず、ＯＳなどについては、もし決まっていれば、
制約として書くことになる。そうやって、ＩＥＥＥ８３０が決まっているという
ことになっている・・・
・・・が、実際にはこれって、
要件プロセス完全修得法
http://www.amazon.co.jp/dp/488303111X
あたりで、ハードなどの決定は、要求段階でするなって書いてあるからじゃなくって？
このズレって、結構大きい気がする・・・
システムのハードが確定しないと、非機能要求を満たせるかどうかが検証できない
（分散メモリかＲＤＢか決まらないと、レスポンスは決まらない）
非機能要求が満たせないと、機能要求を変えるかもしれない
（レスポンスが遅いのであれば、リアルタイムで確認はしないとか）
実務と大学が乖離すると、あんまり意味ない学問になっちゃうよね、
ソフトウエア工学って・・
アクセス
トータル
ランキング
