昨日の話のつづき
システムを作り上げるときは、２つの方法があるんだけど
の２つの方法とは？について
この２つというのは、要求仕様を出すときの問題なんだけど、
１つは、UMLなどで、前提となっている、ユーザーからヒアリングをして、業務を分析する方法。
いわゆるシステム分析手法というものが使える場合。
この場合は、ヒト・モノ・カネを分析対象にできる。
そこで、UMLが使える。担当するヒトやシステムをアクターとして、業務内容をユースケースないしは、アクティビティ図におとす。
さらに、要求がまとまったら、クラスにおとしていくことができる。
もうひとつは、ベンチャーのような新規事業開発で多いんだけど、業務の手順すら、まったくわかんない場合。たとえば、ホリエモンが、「放送とITの融合」っていったけど、なにをやるか、どうやるか、さっぱりわかんない。
この状態で仕事が来た場合。
この状態の場合、ユーザーは、いろいろケチ、注文をつけるんだけど、まったくやり方は、出てこない。で、このやり方を待っていると、たいてい、いつまでたっても出てこない。なので、SE側で、業務からシステムから、一切合財をまとめないといけないケース。
たぶん、みかままさんの書いている、テスト設計の方針は千差万別の”JaSST'05版「クイズ100人に聞きました」”システムが、はっきりしないけど、これっぽい例かも。。。つまり、なにを、どうしたらいいの？というのは、さっぱり決まっていない。ここで、仕様を待つと、地獄がくる。
だって、だれも、見たこともないもん、どーやって、仕様をきったらいいか、本当のところ、だれもわかんないもん。
ということで、こういう開発の場合は、SEが業務フローをつくり（上記の場合は、業務ではないので、業務フローはないけど）、仕様をつくり、プロトタイプを見せて（業務の場合は、業務フローをまずみせて）ユーザに、いいたいことを言わせないといけない。
あ、ちなみに、この場合、＠ITのコメント、
要求や仕様のあいまいさをなくすための、レビューやウォークスルーのような静的なテストも大切です。
を、真に受けてやると、たいへんな事態におちいり、開発は失敗します。
だって、みんなみたことないもの、要求なんて、わかるわけないし、仕様もわかるわけないじゃん！だれかが作って見なけりゃ・・
なんで、創造が創造をよび、空想的仕様で、ありえないような仕様に発散する危険性大です。
作る「前」にレビューやウォークスルーをするのは、前者のようなシステム開発（業務分析可能な場合）で、後者の場合は、プロトタイプを作った「後」にします（＝つまり、みかままさんの態度はただしい。だれか、はやく、いってあげればいいのに。。こーいう場合は、仕様は、出る出るっていってるけど、口だけだよ！って）
で、こういう後者のような場合、どうやってプロトをつくるか？
というか、それ以前に
業務のフローをつくっていくか？っていうことなんだけど、
これが、昔のブログで書いたはなしで、こんなかんじっすね。
（１）モノの流れをおさえる
（モノをあげて、それのCRUDをおっていくいと、流れがでてくる。
（２）次にカネの流れをおさえる（カネが関係ない場合は、省略）
（３）で、モノとカネだけで、情報の流れ（必要データ）を確定してしまう
→ここで、その情報を流すためのプロセスを考えて、DFDにもっていって、さらにERを作ってしまう
っていう、データ中心指向に持っていってしまう方法なわけ。
DFDまでもってくれば、あとは、そのまま開発してもいいし、DFDからユースケースにもっていって、オブジェクト指向にしてもいいし。。。
つまりね、ヒトを登場させないわけよ。
ホリエモンみればわかるでしょ！従業員のことなんて、出てこないでしょ。買収するときに。。。
基本的に、ビジネスを組み立ててる、えらーーい、かたがたは、従業員なんて、どーでもいい話なのよ。っていうことで、まず、サービスの流れと、それで、どうカネを回収するかという部分から押していくことになる。
なんで、アクターがでてきたり、スイムレーンに分けてかくような、UMLくんは、使いにくいのよ。お偉いさんたちのビジネス構築にはね。ヒト、従業員の分担は、でてこないから（そういうのは、下々管理職のしごとと思っているんだろーな）
で、プロトにもっていくか、業務フローと、システム概要をだして、ユーザーとのウォークスルーやレビューにもっていくわけ。
う、まだ昨日の答えに行き着いてないけど、ここで、お仕事しないとまずそうなんで、いったんここで、きって、続きは覚えていたら、またいつか書くぞ！
アクセス
トータル
ランキング
