20年以上にわたりシステム構築の現場で仕事をしてきた筆者の経験では、プロジェクトの失敗を探ると要件定義までの上流工程の問題に行き着くことが多い。定義した要求に過不足がある、要求の内容が誤解を生む表現になっている、整理が不十分なまま要求が個条書きされており整合が取れていない──。こうした事態が、みなさんの現場でも起こっていないだろうか。 利用部門などから要求を引き出して分析し、それを基にソリューションを立案してその妥当性を検証する。さらに、要求の変更を管理していく。ソリューション企画から要件定義までの上流工程を中心に、こうした要求にかかわる一連の作業をいかに行うかが、プロジェクト成功の大きなカギを握る。 しかし多くの現場には、要件定義までの上流工程について標準的な方法が存在せず、ITエンジニアの属人的スキルに頼っているのが実情だろう。スキルの高いITエンジニアが要件定義までの工程を担当するか
システム開発では、よく例外処理をどうするのかという問題が“例外なく”指摘される。現にぼくも開発のジレンマのひとつとして「実業務のさまざまな例外をコンピュータ上に乗せるか否か」ということを言ってきた。 しかしながら、よく考えてみると例外とはいったいどういうことを指しているのだろうか。めったにないこと、予想外のこと、決まったことから外れたこと、そう言ったところでそれが大事（必須）なことであれば例外ではないはずだ。 ということは、まずは重要なことであれば、それがめったに起きることであっても例外とは言わないのだろう。そして、それはシステムに組み込まれる。しかし、１０年に１回しかないことを定例というのだろうか。 では逆に重要でなければ無視すればいいと考えられるのなら、システムには例外というものがないである。もっと正確にいうと最初に設計したときには例外というものはないということになる。 だから、例外と
前回の主旨で述べたように今の業務システムを変えたいと言っています。ということは、現状に様々は問題があって、その問題を解決していこうということでもあります。その問題あるいは課題とはいったい何なのだろうか。そこをきちっと分析して本質的な課題を抽出しないと方向がずれてしまいます。 個々の領域については細かく見ていくことにしますが、現状の業務システムおよびそれを取り巻く環境を俯瞰してみると、どうも「ビジネスとIT」、「ユーザとベンダー」といった両岸の間に流れる“誤解”の川があるような気がします。そこにかなりの部分の問題が潜んでいるように思えるのです。 何年もの間、「経営とITの融合」、「ビジネスに貢献するIT」、「ビジネスマインドをもったSE」だとか両者をうまくつなぐことの必要性は謳われていながら、現実には乖離があるのは否めないのではないでしょうか。 その誤解について少し見ていくことにします。そし
後藤卓司 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 業務プロセス設計では，システムの動き（振る舞い）を明確にする。ここでは「(1)業務フロー設計」と「(2)ユースケース分析」というステップを踏み，5種類の設計書を作成する（図4）。要件定義で作成した「業務流れ図」「業務機能階層図」「業務用語集」「アプリケーション機能一覧」を用意しておこう。図5と照らし合わせて読んでほしい。 (1)業務フロー設計では，業務機能がどのような組織，手段，手順で処理されるのかを記述した「業務流れ図」と，業務全体を大機能，中機能，小機能に構造化した「業務機能階層図」を作成する。 要件定義でも業務流れ図や業務機能階層図を作成しているが，これらはユーザー側の視点で記述されているものだ。業務フロー設計ではこれを，開発者側の視点で書き直すことになる。その際，次の3点に注意する。 一つ目は，それぞれ
http://www.tibco.com/devnet/business_studio/default.jsp ここからダウンロード可能です。フリーです。Eclipseプラグインです。でも今までのEclipseのモデラーでNo.1です。BPMN/XPDLなので学習コストは一般の人にはきついかもしれない。最近ずうーっとXPDLとにらめっこしている私には抵抗なかったけど。サンプル画像をいくつか。 こんなのとか、 こんなのとか。で、操作性も結構よいです。トランジションの付け替えとか、連続してトランジションひいたり（CTRLキー押しながらやる)、ノード変更もいちいちパレットにいって選択しなおさなくてOKで、該当ノードを選択して、右クリックで変えたいノード一覧が表示されるので選べばＯＫ！すばらしいです。ちょこまかいじってもフリーズしなかったり異常終了しません。 他にも細かい演出がある。例えばノードを
前回は，データモデル全体が俯瞰できること，データモデルが適切にグルーピングされていること，各グループ間の関連が把握できることの重要性について説明しました。今回は，業務の流れに沿って，システム全体を俯瞰することの重要性について説明しましょう。 業務間連携や外部システム連携を発注者と合意する 複数の業務にまたがるシステムを設計・開発する場合，個々の業務ごとに画面→機能→データ設計を進めてしまいがちです。 業務間の連携について全く考慮する必要がないシステムならこれでも問題ないのですが，受発注システムのように，データベースやファイルに登録された伝票データが複数業務にわたって参照・更新されていくシステムでは，業務間連携について十分に考慮する必要があります。 さらに，外部システムとの連携についても考慮する必要があります。例えば，得意先別に仕訳された請求データを外部システムとして既に存在する財務管理シス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く