あるデータについて、表示範囲を設定し、
「グラフ」ボタンがクリックされるとグラフが、
「表」ボタンがクリックされると表の一覧が
「ＣＳＶ」ボタンがクリックされるとＣＳＶ形式でデータが
表示される状況を表した。
お客さんと合意をとるだけならこれでいいが、実際に実装まで考えるんなら、
ここで止めるとまずい。というのも、これには、３つの実装方法が考えられるが、
それにより開発コストとリスクが大幅に異なり、従って、プロジェクトの進め方も
変えたほうがよいからだ。
【その１】
サーバーで、
１．サーバー側でデータをまず取得する。
２．その後、おされたボタンにより、サーバー側で
２－１．グラフ用に加工
２－２．表用に加工
２－３．ＣＳＶ用に加工
のいずれかを行い、クライアント側は、サーバーで加工されたデータを表示する
これは、プログラム数は増えるが、他メディアの仕様が影響しないため
（グラフ用データは２項目全データ、
表用は全項目だが一部データ、
ＣＳＶ用は全項目全データが必要など）
比較的、簡単に作れる。
プロジェクトはそのまま詳細化、分担割して問題はない。
【その２】
１．サーバー側でデータを取得し、クライアントに全データを送る。
２．おされたボタンにより、クライアント側で
２－１．グラフ用にJavascriptで頑張る
２－２．表用にJavascriptで整形する
２－３．データはＣＳＶで送られることにしておけば、そのまま出す
のように、javascriptで加工する
これは、Javascriptの生産性に影響してくる
他メディアの仕様が影響することも気がかり
プロジェクトはそのまま詳細化しつつ、Javascriptでの実現性を確認、
詳細化が煮詰まったところで、サーバー側の処理に問題ないか確認し
すすめる。
【その３】
１．サーバー側でデータを取得し、クライアントに全データを送る。
２．おされたボタンにより、クライアント側でグラフ／表／ＣＳＶ部品を切り替えて表示
これは、要望どおりの思った部品を作るのが結構難しい。
→単にグラフを出す、表を出すことは簡単に出来る。
グラフの操作や表の切り替えなどを、要求に合わせるのが難しい。
仮に作れても、他メディアの仕様の影響をもろに受ける。
グラフ操作のバグが、表に影響することも・・・
プロジェクトは、まず、部品が出来るかどうかを確認する必要がある。
その１とその３では、開発リスクが異なり、その３の場合は、そういう
部品が作れるかどうかで決まってしまう。
なので、画面遷移図を考えるとき、
遷移図から実装を考えるのが、ウォーターフォールでは、決まりなんだけど、
先に、実装を考えて（つまり、その１、その２、その３の図を作って）、その上で、
（その図からサーバー部分を除くことにより）画面遷移図を考えてったほうが、
のちのち、安全・・・
