インクリメンタルモデルで、どのようにサブシステムわけするかと、アジャイルにおけるプロトタイプはそうあるべきかについて、途中だったので、結論を書いておきます。
まず「ウォーターフォールとスパイラルモデルの問題点とインクリメンタルモデル」で書いた
どの時点で、そのサブサブシステムにわけ、その際、何を決め、その各プロジェクトをどのように運営していくことで、一番効果的にできるか。。。
という疑問が生じる
ということについて。
ここに書いたように、要求仕様をまとめた段階から、すぐに画面設計に行かれてしまうと問題があるので、要求仕様から、モジュール分割をしていくこととします（このやりかたは、「ＳＥのための仕様の基本」という本などで採用されてます。IEEE1016を基にしてるみたい。そいつは、ここ（ＰＤＦ）
で、このとき、できるだけ、データのやり取り、それもＤＢのデータのやり取りですむように分割しくと、Ｇｏｏｄなわけです。
そうすれば、ＤＢをプログラム独立性があるようにちゃんと正規化して設計していけば（それだけでプログラムから独立するとはいいきれないけど）プログラムにあまり依存せずに、プロセスを分割できることになります。
このＤＢ構造に関しては、たぶん、要求仕様でＥＲ図相当のエンティティを出していると思うので、それにもとづきやっていくということになります。
そして、１担当者が自分で見切れる範囲になるまで、機能（業務）を分割していくことになります。その際、業務の入出力は、ＤＢ入出力プラスアルファで規定しておくということになります。
で、問題は、このように分割された場合、なにをどう進めるかになるのですが、手順的にはマスタ操作系からいって、あまりＤＢ更新の多くないもの、最後にメインとなるようなものと進めていけば、手順の戻りや待ちがすくないので、きれいです。
でも、そうやってすすめると、たぶん、メイン部分の処理が、できるかどうか心配になるので、実際は、一番中心になる業務（受注から発注・在庫・物流など）の正常系で中心になる作業を、切り込み隊長みたいな感じで誰かがやっていって、それが巧くいったら、そこから派生させて、どんどんやっていくというほうが、安心して作業はできます。
とはいえ、インクリメンタルモデルの場合、どれをどうすすめるかは、センスの問題になっちゃいますね。
次の話題。
「ウォーターフォールにおけるテストとアジャイルにおけるテスト」で書いた
一方、アジャイルの場合、はじめにシステムテストを行うことはできない。
なぜなら、全体ができるというのは、一番下位の部分ができてからということになるので、それまで、テストできない。
そーすると、こまるので、それを担保するために、プロトタイプを作成する目的が変わってくるんだけど、それは、また別の機会に。。
のプロトタイプの目的について。
プロトタイプは従来、画面を出して、その操作性とかをユーザーに確認してもらうというのが中心でした。
しかし、最近の場合は、それもあるけど、まず先に、本当に実現できるのかを確認するためにプロトタイプを作るということも多くあります。また、フレームワーク決定のために作るということも多くあります。
この場合、
・実現しなければならない要求に対して、不明確な部分（ここの最後のほうで書いてある要素技術）をまず確認します。
・その上でフレームワークを作ります。
→ＧＵＩも、帳票出力も
・そして、そこから見本を作って、従来のプロトタイプを行う
っていう感じになります。
で、この場合、技術的にできることを担保する意味で、要素技術（技術的に問題となるところを解決する技術）部分を、先に開発し、プロトタイプを作成します。
この要素技術は、通信速度、トランザクション処理など、システムテストに関係することを模擬的環境を作って確かめるなんていうこともあるし、もっとプログラムよりの、ＰＤＦを出力するにはどうするか？などという話の場合もあります。
てなかんじで、回答終わり。
アクセス
トータル
ランキング
