ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

データ移行も、けっこうあぶないよね。

2005-04-28 21:51:47 | 開発ネタ
 そうそう、おばかなプロジェクト問題(って、囲っちゃっていいのかあ?)の話のついでに。。。
 旧システムから新システムのデータ移行っていうのも、甘くみられちゃいません?

 けっこーたいへんなのよね。
 もちろん、データがおかしくなっていれば、データクレンジングとかしないといけないから、それは大変なのは、わかってもらえると思うんですが、そうじゃなくっても




 あるプロジェクトで、データ移行「半日」、SQLを流すだけというのがあった。

 で、その日になった。

 (その時点で、ウィリアムのいたずらは、ぜんぜんデータ移行にタッチしていない。移行後、確認用のテストをするはずだった)

 SQLをながした。

 30分たっても、返事がない。まあ、そんなもんだろう。

 1時間たっても、返事がない

 1時間半たっても、返事がない。なんか、へん??

 どんなSQL投げた??

 しまった、数十万件ものテーブルを、Joinしたり、副問い合わせしたり、いろいろと。。。。。

 これは、おわんないかも。。。

 つくりなおしだ。でも、データ移行に半日しかとってないんだ。

 データ移行は、CSVなり、insert文にするなり、データをあらかじめ作ってウィリアムのいたずらが確認しておくべきだった。




 教訓:他人を信じるな

(そー来るかい (^^;)v )

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

UMLを採用しても(したから?)おかしくなるケース

2005-04-28 07:55:35 | 開発ネタ
 なんか、最近、アクセス数が多いので、今日もこりずに、おかしなプロジェクトの話。
 昨日のブログの書いた、「商品台帳に在庫数を記入して、更新する方法を採用したら、ディスクがたりなくなっちゃって出来ない!」っていう話。

 この会社、基本的にUMLを採用してるので、たぶん、このプロジェクトもUMLを採用してると思うんです。




 実は、そこが問題!

・まず、システム分析に入るため、ユーザーからヒアリングして、UMLのユースケースを作った。
・ユーザーは、在庫を知るのに、商品台帳に在庫数を記入して、(在庫が入ったら在庫数を書き換え)更新していた。
・なので、単純にそのままやった。
・UML上、そのように書いても、矛盾は出ない。
・逆にユースケース図から、別の方法を考えようと思っても。。。考えが浮かばない。




 UMLを採用し、業務分析を行う場合、ユーザーからヒアリングしてその内容を書きます(まあ、ユースケース図とか、アクティビティ図とか)。

 この場合、本来業務は、いろんなやり方がありえる(場合が多い)。

 しかし、いろんなやり方のうち、どのやり方かを決めてやらないと、現場が混乱するので、偉い人(じゃない場合もあるけど、結局自分を含め、誰かが)がえいや!ときめてやる。

 その場合、

 コンピューターを導入しない前に現場が決めたことは、
    コンピューターを「入れない」状態での最適解である。

 コンピューターを「入れた後」も、そのやり方がいいとは限らない。



 たとえば、上の例でいうと、コンピューターを「入れる前」であれば、在庫を知るのに、商品台帳に在庫数を記入して、更新するやり方は、最適解となる。
 入庫伝票、出庫伝票を書いても、それを集計する人がいなければ、在庫数がわからないから。

 でも、コンピューターを「入れた(後の)」場合、その集計処理はコンピューターが行うから、入庫処理、出庫処理をしたほうが、システム上よいというケースが多い(今回もそのケース)。




 ところが、UMLの図をみてしまうと、そのやり方をもとに考えてしまうので(とくに若手でいろんなやり方を知らない人は)、業務のやり方が悪いとわかっても、それをどう変えたらいいか、気がつかない。

 ユーザーに聞いても、コンピューターを使っていなければ、コンピューターを入れた後で、どんなシステムがよいのかは、本当のところ想像つかない。だから、やっぱり、業務のやり方が悪いとわかっても、それをどう変えたらいいか、気がつかない。

 入出力だけを押さえて、そのプロセスについて、いろいろ発想を広げるか、通論を調べることになる。

 しかし、前者は、データ中心指向的な発想だし、後者も最近言われない(業務のパターン化について、クラス化して公開するなんていう話をあまり聞かない。そのため、このブログで、「業務のモデル化」っていうカテゴリで、それをやろうとしたんだけど)。
 つーことで、UMLのやりかただけを聞いた若手の人なんかが、システムを切ると、こーいう、困ったことが起こることがある。




 っていうことが、以前のブログ「テストの失敗や品質不良の問題は、フレームワークのまずさと、仕様変更のためが多いと思う 」で書いた、「ユーザーがいう業務内容が、はたして、コンピューターを載せたとき、最適な方法かどうかわからない。」の具体例です。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする