DFD（でぃーえふでぃー）
データの入出力・流れ・処理の視点から対象世界（システム）の機能や振る舞いを分析・記述するための図のこと。データを処理するプロセスを丸（バブル）で表すため、バブルチャートともいう。 DFDは構造化分析で中心的に使われる分析技法で1970年代後半に提案され、C・ゲイン（Christopher P. Gane）とT・サーソン（Trish Sarson）の共著『Structured Systems Analysis: Tools and Techniques』（1977年）やトム・デマルコ（Tom DeMarco）の『Structured Analysis and System Specification』（1979年）などによって普及した。 機能（データの処理）同士の関係をグラフィカルに表現することにより、システムの構造を明確にする。この機能とはコンピュータによる処理だけではなく、きちんと定めら
DFD
ＤＦＤの内容と書き方 ＤＦＤは、次のような記号で構成します。 データの源泉・行き先は、システムの利用者や外部システムです データストアは、台帳やデータベースです データフローは、伝票やデータ伝送の内容です 処理は、手続きや計算およびデータの変換内容です 記号の記入要領をまとめると次のようになります。 ＤＯＡの開発は、 ４つのモデルを順次作成する 現行物理ＤＦＤ（現状をそのままＤＦＤにすること）の作成要領は、次の通りです。 ①問題記述書を作成して「現状」を記述します。事務フローでもＯＫです。 ②問題記述書から「データのＩＮＰＵＴ元（発生源）」と「データのＯＵＴＰＵＴ先（行き先）を抜き出す。 ③問題記述書から「動詞」を抜き出す。 ④問題記述書から「名詞」を抜き出す。 ⑤問題記述書から「帳票名」を抜き出す。 ⑥「ＩＮＰＵＴ」を発生源、｛ＯＵＴＰＵＴ」を行き先、「動詞」を処理（プロセス）、「名詞」
ＥＡの詳細（図表類の説明）＜法規・基準＜Ｗｅｂ教材＜木暮
図をクリックすると拡大図が別ウインドウに表示されます。 政策･業務体系（ＢＡ） 経営戦略の明確化とかビジネスモデルの策定のプロセスです。対象となる業務・システムの範囲と最適化の方向性を優先順位をつけて明確に示す体系です。この体系で作成されるドキュメントには，業務説明書，機能構成図，機能情報関連図，業務流れ図があります。 業務説明書 業務・システムの管理・運用体制や最適化に向けた責任体制を明確化したものです。一般に簡潔な文章で記述されます。以下の文書は，それを具体的に詳細化したものであると位置づけられます。 機能構成図（ＤＭＭ：Diamond Mandala Matrix） 業務機能を階層的に３×３のマトリックスで表現します。中央のマスに業務名を書き，その周囲のマスに中央の業務を構成するサブ業務を，左上から時計周りに業務の順序に合わせて記述します。中央のマスを目的だとすれば，周囲のマスはそれ
モデリング：XEAD
現在進行中のプロジェクトで、設計の品質や生産性を高めたい．．． 業務知識や上流工程のスキルを身につけてキャリアアップしたい．．． ――そのためのお役立ち情報を揃えています。実務家から高い評価を得ている設計手法、専用の支援ツール、洗練されたモデルライブラリー。これらを駆使して、効率的にシステム設計のレベルアップをはかりましょう。 ニュース 「ＣＯＮＣＥＰＷＡＲＥ／自治体」の開発が始まりました(080420) 「ＣＯＮＣＥＰＷＡＲＥ／販売管理」をバージョンアップしました(080404) 「ＣＯＮＣＥＰＷＡＲＥ／生産管理」をバージョンアップしました(080404) ＸＥＡＤで入出力パネルの画像ファイルを扱えるようになりました(071004) 管理人のブログ「設計者の発言」
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
実践編・第５回 機能情報関連図（DFD）の使い方と論理化
文・清水惠子（みすず監査法人 シニアマネージャ） 実践編・第4回で機能分析についての説明をした。次のステップでは、分析した機能と情報の関連を分析し、その機能と情報の流れから業務改善を進めることになる。 ■DFDによる機能の流れの見直し-組織の垣根を越えて 実践編・第3回では、「アクションプラン＝行動計画」ついて説明したが、行動の目標を実行に移すにあたっては、まず、具体的に行動の対象とした業務についての現状分析が必要となる。機能情報関連図（DFD）を作成する第一の“ご利益”は、業務を実施する際の機能と情報の流れが組織の垣根を超えて一覧できることにある。 現状のDFDを作成する最後の作業である論理化の作業（業務のくくりなおし）を経てから、理想モデルを策定することになる（DFDについては、併せてコラム第4回を参照）。 論理化の作業によって、業務をくくりなおすことにより、情報の流れが整理される。つ
mtrip
「mtrip」は、SysML･UML・DFD（データフローダイアグラム図）等の汎用モデリング言語で記述されたアーキテクチャ設計モデルと、詳細設計モデルのMATLAB／Simulink を相互に変換するツールです。 詳細設計モデルの変更をアーキテクチャ設計モデルへ同期しないと、次第に構造面でモデルを検討する事が困難になります。『mtrip』はアーキテクチャ設計モデルと詳細設計モデルを同期させ、異なる視点からモデルを見ることができ、高い保守性を維持します。 Simulinkモデルベース開発の効果と限界 MATLAB / Simulink はシミュレーション機能や充実した関連製品により、制御モデルを迅速に作成・検証できる大変便利なツールです。 しかしながら、この簡便さゆえ、開発者は「システムの構造的側面」に注意を払うことなく、試行錯誤を繰り返し「とにかく動くモデル」を作ってしまいがちです。 構造
第4回 データの「見える化」ならDFDを使おう
「ずいぶん前に使っていたと，先輩から聞いたことがある」「今はUMLがあるからそんな手法はいらないのでは」――。開発現場で最近，DOA（Data Oriented Approach）についてこんな声を耳にする。確かに，システムの部品化が進んでSOA（Service Oriented Architecture）に注目が集まり，UMLやBPMN（Business Process Modeling Notation）を用いたモデリング手法が広がりを見せている。 しかし，従来から変わっていないことがある。それはすべてのシステムは必ず「データ」を扱うことだ。システムが大きくなればなるほど，扱うデータも多くなる。ここで機能を中心に考えていると，データの漏れや不整合の発生を招き，システム全体を見渡すのが難しくなる。だから筆者は，データの流れの把握と分析に着目したDOAにこだわる。以下では，筆者が実践するD
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DFDMODEL
ページが見つかりませんでした | 個人情報保護法・プライバシーマーク マニュアル