Example of a function model of the process of "Maintain Reparable Spares" in IDEF0 notation. 機能モデル （きのうモデル、Function model）はモデル化されるシステム またはサブ領域内の機能 （アクティビティ 、タスク分析 （英語版 ） プロセス 、運用 ）の構造化された表現である[ 1] 機能的モデル とも。
またアクティビティモデルまたはプロセス・モデリング とも呼ばれる機能モデル は、定義されたスコープ内の事業体の機能の図式表現である。機能モデルの目的は、情報ニーズの発見を補助し、機会の識別を助け、そして製品またはサービスコスト決定するための基盤を確立する、機能とプロセスを記述することである[ 2]
機能モデルプロジェクトは20世紀前半に開発されていたマネージメントダイアグラム の他のタイプとして、1950年代に始まった。最初に知られるガントチャート は、それをharmonogram と呼んだKarol Adamiecki によって1896年に開発された。
Adamieckiは、彼のチャートを1931年まで発表しなかったこと、及び彼の作業がいずれの場合もポーランド語あるいはロシア語で発表され、言語が西側世界 でポピュラーでなかったことから、そのチャートは今、1910-1915年近辺で彼のチャートを設計し、西側でポピュラーになった、Henry Gantt (1861-1919) の名前を持つ[ 3] [ 4] [ 5] フロー・プロセス・チャート (Flow process chart )は、1921年に米国機械工学学会 (ASME ) のメンバーに『プロセス・チャート：一つの最適方法発見における最初のステップ』のプレゼントして、Frank Gilbreth によって紹介された[ 6] 産業工学 カリキュラムにそれらの方法を素早く見つけました。
最初に良く定義された機能モデルの一つは、1950年代の防衛関連のTRW 社によって開発された機能フロー・ブロック・ダイアグラム (FEBD )であった[ 7] NASA によって採用された[ 8] システム工学 でさらに幅広く使われた[ 9]
システム工学 及びソフトウェア工学 における機能モデルは、機能的観点のモデリング (modeling perspective )で創られる。機能的観点は、ビジネスプロセスモデリング で可能な、別の観点が、例えば、振舞い的、組織的、あるいは情報的である、観点の一つである。[ 10]
機能モデリングの観点は、動的システム を記述することに集中する。このモデリング観点における主な概念はプロセスであり、これは、機能、変換、アクティビティ、行為、タスク、などであり得る。この観点で採用されるモデリング言語の良く知られた例は、データフローダイアグラム (data flow diagram )である。
その観点は、プロセスを記述する、以下の4つのシンボルを使う。
プロセス：インプットからアウトプットへの変換を描く。
ストア：データの集まり、またはある種の物品。
フロー：プロセスにおけるデータまたは物品の移動。
外的エンティティ：モデル化されたシステムの外部であるが、それと作用する。 ここで、これらのシンボルと共にそのプロセスは、これらのシンボルのネットワークとして表され得る。この分割プロセスがDFD：データフロー・ダイアグラムである。
動的エンタープライズモデリング （英語版 ） コントロール・モデル (Control model)、機能モデル、プロセス・モデル (Process model )、及び組織的モデル (Organizational model)で創られる。
Example of functional decomposition in a systems analysis. 機能分割 (Functional decomposition )[訳語疑問点 は、オリジナル機能が、機能構成 (function composition )[訳語疑問点 によるそれらの部品から再構築され得る方法のような、構成要素部品に機能的 (functional )[訳語疑問点 関係性を解決するプロセスへ広く参照する。一般に、分割のプロセスは、構成要素の識別への洞察を高める目的、あるいは構成要素のプロセスがモジュール性 のレベルを所有する時のみ可能なタスクである、グローバル機能の圧縮された表現を得る目的のいずれかを引き受ける。
機能分割 (Functional decomposition ) は、主要な目標が可能な最も大きい広がりのプロセスをモジュール化 することである、コンピュータプログラミング における卓越した役割を持っています。例えば、ライブラリ管理システムが、在庫モジュール、顧客情報モジュール、及び料金査定モジュールに分解されるかもしれません。初期のコンピュータ・プログラミングの数十年に、それは、若干の卓越した実行者によって呼ばれたとき、これは『サブルーチン化の芸術』として明らかにされました。
工学システムの機能分割は、設計されたシステムを分析するための方法です。基本的な考えは、ブロック・ダイアグラムのそれぞれのブロックがその記述に『and』または『or』条件無しで記述できるような方法で、システムを分割しようとすることである。
この課題は、システムのそれぞれの部分に純粋な機能 (function )を持たせることを強います。システムが純粋な機能で構成されているとき、それらは再利用されるか、あるいは置換えられることができます。普通の副次効果は、ブロック間のインタフェースが単純そして汎用になるということです。インタフェースが通常単純になることから、それは、関連し、類似の機能で純粋な機能で置換えることがより容易です。
機能的アプローチは、複数の図式表現技法とモデリング表記法で拡張された。このセクションでは、年代順に重要な技法の全貌を提供する。
Functional Flow Block Diagram Format.[ 11] 機能フロー・ブロック・ダイアグラム (FFBD )は、システム の機能的フローの、多段で、時間順で、ステップ毎のフロー・ダイアグラム (Flow diagram )である。[ 12] システム工学 で幅広く使われた。機能フロー・ブロック・ダイアグラムは、機能フロー・ダイアグラム 、機能ブロック・ダイアグラム 、あるいは機能フロー としても参照される[ 13]
機能フロー・ブロック・ダイアグラム（FFBD）は、システム のためのステップ毎の操作やシーケンスを支援する、通常詳細を定義するが、しかしそれらは、システムの開発や制作におけるプロセス を定義するため効果的に使われる。ソフトウェア開発プロセス (Software development process )もまた、幅広くFFBDを使う。システムの文脈で、機能フローのステップは、ハードウェア 、ソフトウェア 、人材 、設備、及び手順の組合せを含むかもしれない。FFBD手法で機能は、実行の論理的順序で組織化され、描かれる。各機能は、それの他の機能の実行と完了との論理的関係で示される。機能名でラベル付けされたノードは、各機能を描く。左から右への矢印は実行の順序を示す。論理記号は、機能の順次または並列実行を表す。[ 14]
階層的入力処理出力 HIPO (HIPO )は、1970年代に普及した、システム のモジュールを階層的 に表現し各モジュールを文書化するための[ 15] システム分析 設計支援と文書化技法である。[ 16]
それは、要求を開発し、設計を構築し、そして自動化された待ち合わせを示すためのエキスパート・システムの実装を支援するため使われた。検証は、設計と実装の方法のため体系的に行われた。[ 17]
システムの全体設計は、HIPOチャート、または構造チャート (Structure chart )を使って文書化される。構造チャートは、組織チャートに現れるそれと類似であるが、付加的詳細を示すため変更された。構造チャートは、情報の幾つかのタイプを表示するため使うことができるが、データ構造 (Data structure )あるいはコードのいずれをも表示するのに最も共通的に使われる。
Figure 2. N2 chart definition.[ 18] N2チャート (N2 Chart )は、システム要素間の機能的又は物理的インタフェースを表現する、マトリックス 形式でのダイアグラムである。それは、機能的及び物理的インタフェースを体系的に識別し、定義し、表にし、そして分析するため使われる。それはシステム・インターフェース と、ハードウェア 及びソフトウェア ・インタフェースに適用する。[ 12]
N2ダイアグラムは、データ・インタフェースを開発するため、主にソフトウェア 領域で、広範囲に使われた。しかしながらそれはハードウェア・インタフェースを開発するためにも使える。基本的な N2 チャートは、図２に示されます。システム機能は対角線上に置かれる；Ｎ ｘ Ｎマトリックスでの正方形の残りは、インタフェースのインプットとアウトプットを表す。[ 18]
SADT basis element. 構造化分析及び設計技術 (SADT )は、ソフトウェア・アプリケーションのスケッチを構築するダイアグラム 的表記で、機能の階層としてシステム を記述するための、ソフトウェア・エンジニアリング手法 (Software engineering methodology )である。それは、エンティティとアクティビティを表すビルディング・ブロックとボックス間を関係づける矢印を提供する。これらのボックスと矢印は、関連する非公式な意味論 を持つ。[ 19] [ 20]
SADTは、一つの会社の機能とそれらの関係性を記述することによって、あらゆる事業体の特手化された機能的ビューを提供する。これらの機能は、販売、受注計画、製品設計、部品製造、及び人材資源管理のような、会社の目的を満たす。SADTは、シンプルな機能的関係描くことができ、そして異なった機能間でのデータとコントロールの流れの関係性
を反映できる。IDEF0 形式論は、ダグラス・テイラー・ロス によって1985年に開発されたSADTに基づいている。[ 21]
IDEF0
IDEF0 ダイアグラムの例IDEF0 は、情報システム と事業プロセスの分析、開発、リエンジニアリング、及び統合、あるいはソフトウェア工学分析のための機能的モデリング言語 を提供する、製造 機能を記述する一つの機能モデリング手法論である。[ 22] ソフトウェア工学 分野でのモデリング言語であるIDEF ファミリー手法の一員であり、機能モデリング言語SADT で構築される。
IDEF0機能モデリング手法は、組織またはシステムの意思決定、行動、及びアクティビティをモデル化するため設計された。[ 23] ダグラス・テイラー・ロス とSofTech社 によって開発された、確立された図式モデリング言語構造化分析及び設計技術 (SADT )から派生した。そのオリジナル形式では、IDEF0は、図式モデリング言語の定義（構文 と意味論 ）とモデル開発の包括的方法論の解説の両方を含んでいた。[ 1] [ 23]
Business Process Modeling Notation Example. 事業プロセス・モデリング表記法 (BPMN )は、ワークフロー における事業プロセス を規定するための一つの図式表現 法である。BPMNは、Business Process Management Initiative(BPMI),で開発され、2005年の組織合併により、現在はObject Management Group によって取り扱われている。BPMNの現在バージョンは1.1であるが、BPMN2.0に向けての大きな改訂のプロセスが進行している。[ 24] [ 25]
BPMN仕様は、事業プロセス・ダイアグラム （BPD）で事業プロセス を規定するための図式表記法を提供している。[ 26] BPEL4WS ）による実行構築の基礎との間のマッピングも提供する。[ 27]
中軸設計 (Axiomatic design は、分析、開発、リエンジニアリング、及び、製品、情報システム、事業プロセス、またはソフトウェア工学ソリューションの統合、等のソリューション合成のフレームワークとして使われる、トップダウンな階層機能的分割プロセスである。[ 28]
システムとソフトウェア工学分野で、多くの特定機能及び機能的モデルが定義されてきた。ここでは2～3の一般的タイプだけが説明される。
事業機能モデル （BFM）は、組織のミッションを実行するため日常的に実施されるオペレーションの一般的記述あるいは分類である。それは、事業領域機能の文脈での重要な事業プロセス (business process )を示すことができる。事業機能モデルにおけるプロセスは、価値連鎖（バリューチェーン）モデルにおけるプロセスから構成されねばならない。プロセスは、最終製品制作あるいはサービス提供のため実行される関連事業アクティビティのグループである。継続ベースで実行される事業機能と違って、プロセスは、それらが望まれたアウトプットを提供することでマークされる、特定化された開始と終了ポイントを持つという事実によって特徴づけられる。右側の図は、事業プロセス、事業機能、及び事業領域の事業参照モデル間の関係性を描いている。[ 29]
This FEA Business reference model depicts the relationship between the business processes, business functions, and the business area’s business reference model. 事業参照モデル (Business reference model )は、事業体 (Enterprise )、サービス組織 (service organization )、あるいは政府機関 (Government agency )の中核事業 (Core business )の機能的及び組織的側面に着目した、一つの参照モデルである。エンタープライズアーキテクチャ (EA)における事業参照モデルは、EAと関連した構造とビュー (views )をどのように組織化するか定義する、エンタープライズアーキテクチャフレームワーク (Enterprise Architecture Framework )あるいはアーキテクチャフレームワーク の一部である。
一般的な参照モデル (reference model )は、それらを実行する組織的構造 (organizational structure )とは独立に、基本的目標または何かのアイデアを具現化する何かのモデルであり、様々な目的のため参照するのに探すことができる。事業参照モデルは、組織の事業運営 (business operations )を記述する手段である。
事業参照モデルの他のタイプは、事業プロセス (Business process )、事業機能、及び事業領域 の参照モデルの間の関係性をも描く。これらの参照モデルは、階層的に構成され、サービス・コンポーネント、技術、データ、及び性能の分析のための基盤を提供する。
オペレータ機能モデル（Operator Function Model） は、人的要因 (Human factors )技術者によって使われる伝統的なタスク分析 (task analysis )技法に代わる提案である。オペレータ機能モデルは、どのようにオペレータが、許容可能な全体システムの性能を達成するため、複雑システムを単純な部分に分割し、コントロール行為とシステム構成を協調させるかを数学的フォームで表そうとする試みである。そのモデルは、複雑システムの知識表現 、情報フロー、及び意思決定における基本の課題を表現する。Miller (1985)は、どのようのそのモデルがオペレータ・コントロール機能から成る意思決定問題を解決するため使われるかを特定するシステム＋コントロール構造に関して、ネットワーク構造がオペレータの内的モデル (Internal model )を表現可能であると考えられることを提案した。[ 30]
ウィキメディア・コモンズには、
機能モデル に関連するカテゴリがあります。
パブリックドメイン である、アメリカ合衆国連邦政府 が作成した次の文書本文を含む。アメリカ国立標準技術研究所
^ a b FIPS Publication 183 released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).
^ Reader's Guide to IDEF0 Function Models . Accessed 27 Nov 2008.^ H.L. Gantt, Work, Wages and Profit , published by The Engineering Magazine , New York, 1910; republished as Work, Wages and Profits , Easton, Pennsylvania, Hive Publishing Company, 1974, ISBN 0879600489 .
^ Gerard Blokdijk, Project Management 100 Success Secrets , Lulu.com, 2007, ISBN 0980459907 , Google Print, p.76
^ Peter W. G. Morris, The Management of Projects , Thomas Telford, 1994, ISBN 0727725939 , Google Print, p.18
^ Ben B. Graham (2002). Detail Process Charting . p.2.
^ Tim Weilkiens (2008). Systems Engineering with SysML/UML: Modeling, Analysis, Design . Page 287.
^ Harold Chestnut (1967). Systems Engineering Methods . Page 254.^ Thomas Dufresne & James Martin (2003). "Process Modeling for E-Business" . INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003
^ Process perspectives . In: Metamodeling and method engineering , Minna Koskinen, 2000.^ Systems Engineering Fundamentals. ^ a b The first version of this article is completely based on the NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
^ Task Analysis Tools Used Throughout Development . FAA 2008. Retrieved 25 Sept 2008.^ FAA (2006). NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
^ Sandia National Laboratories (1992). Sandia Software Guidelines Volume 5 Tools, Techniques,and Methodologies SANDIA REPORTS 85–2348qUC–32
^ IBM Corporation (1974).HIPO—A Design Aid and Documentation Technique , Publication Number GC20-1851, IBM Corporation, White Plains, NY, 1974.
^ Mary Ann Goodwin and Charles C. Robertson (1986). EXPERT SYSTEM VERIFICATION CONCERNS IN AN OPERATIONS ENVIRONMENT . NASA paper N88-17234.
^ a b NASA (1995). "Techniques of Functional Analysis". In: NASA Systems Engineering Handbook
^ John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT) . Retrieved 21 Sep 2008.
^ SADT at Free-logisitcs.com. Retrieved 21 Sep 2008.^ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management. . p.508.
^ Systems Engineering Fundamentals. ^ a b Varun Grover, William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.168.
^ “BPMN Information ”. 2008年11月2日 閲覧。 ^ “BPMN FAQ ”. 2008年11月2日 閲覧。 ^ Richard C. Simpson (2004). An XML Representation for Crew Procedures
^ S.A. White, "Business Process Modeling Notation (BPMN)," In: Business Process Management Initiative (BPMI) 3 May 2004.
^ Suh (2001). Axiomatic Design: Advances and Applications, Oxford University Press, 2001, ISBN 0-19-513466-4
^ Analyze the Business and Define the Target Business Environment . Accessed 27 Nov 2008.^ Operator Function Model (OFM) . Accessed 27 Nov 2008.
