見えるビジネスモデリング
2007年2月に開催されたデブサミ2007の中から、アーキテクトセッション「ビジネスモデルを極める！ （4＋1）×1ビューで見える化する」の内容を紹介する。 2007年2月14～15日の2日間、東京・目黒雅叙園で「Developers Summit 2007（デブサミ2007）」が開催された。このイベントは、技術者コミュニティとの連携から生まれた総合ITカンファレンス。今回は「デベロッパーがビジネスを刺激する――時代はWeb 2.0＋Enterpriseに」をテーマに、さまざまなセッションが行われた。この中からアーキテクトセッション「ビジネスモデルを極める！ （4＋1）×1ビューで見える化する」の内容を紹介する。 「デブサミ」は、技術者コミュニティを中心軸に据えたイベントとして2003年2月にスタート。さまざまなジャンルの「コミュニティ」リーダーが企画した、実際的・現場的学びの場を提供する
モノ・コト分析をパターン言語で表現 ― ＠IT
前回の「モノ・コト分析の段階的モデリング」は、クラスにステレオタイプ《mono》と《koto》を導入し、例題として注文から納品・請求までの簡単な業務フローを取り上げてモノ・コト分析でモデリングを行いました。ステレオタイプによりモデルの作成と理解が一層容易になったと思います。今回はモノ・コト分析の実践方法をパターン言語の形式で表現してみたいと思います。 パターンとパターン言語 「パターンとパターン言語」について第7回で簡単な解説を試みました。解説というよりも筆者なりの認識を語ったという方が正しいですが。今回はその1つの具体例としてモノ・コト分析実践方法のパターン言語化を試行してみましょう。ここに6つのパターンを抽出しました。パターンの名前にちょっと工夫をしてみました。この例のようにパターンには簡単で分かりやすく、かつインパクトのある名前を付けます。 （1）物事をわきまえよ モノとコトを分離す
変更に耐えるシステム構造とモデルの関係（下）
前編「変更に耐えるシステム構造とモデルの関係（上）」では、システムの分析を行ううえで知っておくべき知識の整理をしました。分析（あるいは設計）作業には、システムのモデルを構築する作業が伴います。今回は、システムの概念モデリングを行う際に注意すべき点を明らかにしながら、洗練されたモデルが変更に強いシステム構造を得る最短距離であることを解説していきます。 （1）概念モデル（概要レベル） 目的やビジネスの要求や業務フローが明らかになった後で、概念モデルを作成します。概念モデルはシステムの全体のエンティティの構造を主に洗い出します。E-R図に似ている部分がありますが、データを分析するのではなく概念の構造を分析します。属性や振る舞い、概念間の関係などを複数の視点で分析し構造を洗い出していきます。 概念モデルは、業務シナリオから導き出されます。業務シナリオを書いてみるか、もしくはビジネス要求や業務フロー
変更に耐えるシステム構造とモデルの関係（上） ― ＠IT
今回は2回に分けて、要求を忠実に反映したシステム分析の方法と、変更に耐えるシステム構造を作る方法を解説します。前編である今回は、実際の分析作業を行う前に知っておくべき知識の整理をしておきます。 保守性の考え方 保守性とは、「予想できなかった機能変更・追加を最低限のコストで実施できること」です。では、予想できない機能変更はどんなときに起きると思いますか。わたしは大きく2つあると思います。すなわち、「使いにくい」「使えない」など、要求が正しく実現されていないとき、あるいは、使ってみると新たな要求が出てくるときです。これは、システムの機能とビジネス要求の乖離（かいり）が原因だと考えられます。このような場合、結局は、仕様変更を余儀なくされます。（広い意味での）バグと考えてもいいでしょう。 ビジネス環境が変化することで、構築したシステムに機能の追加が要求されたり、短時間で機能変更が要求される場合もあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
