« XEAD、今後の展開 | トップページ | 「特別給付」のデータモデル »

2008.07.30

8/26に東京で講演します

 6月の名古屋と大阪でのヨタ話が好評だったので、東京でも開催することになりました。これも定員が50名と少なめなので、早めにお申し込みください。

システム開発の最終兵器「オープンパッケージ」
「オープンパッケージ」とは、設計情報(モデル)とソースコードが公開されている基幹業務向けパッケージのことです。これがもたらすインパクトを想像すると、これまでのシステム業界の混乱や矛盾はオープンパッケージが欠落していたためではないかと思えてきます。これが普及している未来において、現在のSIビジネスが依拠する多重下請構造は存在しません。そのときに生き残っている技術者であるためにはどうしたらいいのでしょう。

申し込み先:住友電工情報システム「システム開発現場の最前線を往く!!」

|

« XEAD、今後の展開 | トップページ | 「特別給付」のデータモデル »

コメント

業務でXEADを使わせていただいております。
そこで、質問なのですが、
例えば、Webサイトのシステムで、エンドユーザ(ブラウザでサイトを閲覧したりクリックする人)
の一連の操作を加えた業務フローを作成する
というこは邪道でしょうか?

通常は、XEADでは、渡辺さんもリファレンスモデルで
提示しているように、販売管理システムなどの
業務システムを取り扱っておりますが、
Webサイトのシステムで基本設計を作成する場合、
どうしてもエンドユーザの操作を業務フローに
加える必要が生じてくると存じます。
業務フローで具体的に説明させて頂きます。
業務フローの流れは、エンドユーザが
システム内(サイト内)のある項目をクリック
して情報を表示させる操作となります。
まず、エンドユーザがシステム(白枠)外に
主体として存在します。
システム内には、以下のような業務単位が
存在します。まず、吹き出しが「随時」、
担当者が「システム」、業務が「○○表示処理」です。

Webシステムをデザインするときは、以上のように
システム外に「エンドユーザ」、システム内の
業務単位の担当者が「システム」となると存じます。

渡辺さん的には、どのように考えられるか
お伺いいたしたいと存じます。
以上、よろしくご返答いただけたらと思います。

投稿: divcity | 2008.09.30 19:45

divcityさん

正しい認識です。雑誌か何かに書いたのですが、私はそのような場合、業務の担当者を「Webサーバ」とし(言われるように「システム」でもかまいません)、イベントには「随時」ではなく「○○表示を要求された!」と記述するようにしています。

業務フロー上の「○○表示処理」と外部主体の「ユーザ」との間には「○○表示要求」と「○○データ」がやりとりされる形で描かれることになりますね。

投稿: わたなべ | 2008.10.01 07:15

オープンパッケージのプロジェクトはもう存在するのでしょうか。
オープンパッケージとはたとえばオープンソースの販売管理ソフトとCONCEPWAREの販売管理がセットになったようなものと考えていいのでしょうか。
それなら本当に最終兵器だと思います!

投稿: iwajun | 2008.10.02 17:37

iwajunさん

想像されている通りのものです。私自身でコツコツ進めている他に、趣意に賛同されているある大手のSIerが「CONCEPTWARE/販売管理」にもとづいて開発を進めています(フレームワーク部分は有償ですが)。オープンパッケージが充実している未来を想像するとワクワクしますよね。

投稿: わたなべ | 2008.10.02 19:57

渡辺さん

ご返答ありがとうございました。
なるほどです。よくわかりました。

投稿: divcity | 2008.10.02 20:29

画面のオペレーションの単位にERを表示する機能は考えられないでしょうか?
たとえば、一つの画面で、、「検索条件入力,検索ボタンクリック検索結果を一覧で表示、1行選択すると、一覧で選ばれたレコードのカラムをすべて編集テキストフィールドのようなところに表示する。テキストフィールドを修正し反映ボタンをクリックする」という様なオペレーションをする画面の場合、オペレーションごとに何をするか記述し、確認したいのですがこういう要求ってないですかね?

投稿: mizo | 2008.10.23 22:40

mizoさん

XEADでは、機能毎に与えられるテーブル入出力一覧を、サブシステム単位で与えられるERDと対比させつつ、機能の役割を眺める、という仕様理解のスタイルをとっています。

言われるように、画面毎のERDを確認できるのであれば、それはそれで効果的だとは思います。しかしそのような見方を実現するためには、(機能定義毎ではなく)画面定義毎でのテーブル入出力の登録が必要になります。それはおそらく、ふつうの基幹システムのような機能数や画面数では、登録作業が煩雑すぎるかもしれません。

現在のXEADの仕様を前提にして考えると、機能定義に複数の画面が定義される可能性があるにせよ、それらをひっくるめて機能定義毎でのERDを、その機能固有のCRUD付きで表示する、なんてことができてもいいかもしれませんね。面白い提案をありがとうございました。

投稿: わたなべ | 2008.10.27 12:18

ボトムアップでERDを分析するかトップダウンでするかによっても、この機能毎のERDの有無は意味が違ってきてしまうと思うんですよ。

サブシステム毎にホワイトボードに書いたERDを確定して、XEADに登録するか、画面毎や、業務毎にERDを作成して、全体のERDに仕上げていくか。

今、やっているシステム全体で、500以上のテーブルを使い、サブシステムが10個程度、サブシステムの中に平均50個のテーブルが入ります。そうすると、テーブルが多すぎて、見直しがつらいです。仕様の把握もつらいです。そんな時、機能単位にもERDがあると、確認が楽かなというのが私にとってお願いした理由です。これだけ、画面が多いとトップダウンでERDを終わらせられなくて、ボトムアップでERDを作成しています。

提案経緯でした。

別件の提案ですが、システム全体のデータ項目辞書を作り同名項目のデータ型や項目名を統一するための方法がないと思うので、システム内にあるテーブルで使用している項目を一括出力する機能を提案します。直すのは手で一つ一つやっていけばいいと思うのです。

以上です。

投稿: mizo | 2008.10.30 07:04

1個のサブシステムの内部テーブルが50個ですか。そうとう多い感じがしますが、そのようなDB設計手法をとられているということでしょうかね。

思うに、テーブル数が多めになる手法には、仕様管理が煩雑になるという欠点があるかもしれません。私自身は、ひとつのサブシステムに10個以上の内部テーブルを置くことはめったにしません。XEADはそういう手法を前提にしているツール、ということでもありますね。

全テーブルを対象とするデータ項目の一覧表、いいアイデアですね。次のバージョンに盛り込もうと思います。ありがとうございました。

投稿: わたなべ | 2008.10.31 14:11

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 8/26に東京で講演します:

« XEAD、今後の展開 | トップページ | 「特別給付」のデータモデル »