JPH01116765A - 概念設計ツールとプロジェクト管理ツールを自動的にインタフエイスする方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 以下の順序で本発明を説明する。

Ａ、産業上の利用分野 Ｂ、従来技術 Ｃ０発明が解決しようとする問題点 り０問題点を解決するための手段 Ｅ、実施例 Ｅｌ、製品の構造（第１、第２、第３、第４、第５図） Ｅ２．概念設計ツールの論理の流れ図（第６図） Ｅ３．照会システム論理の流れ図（第７図）Ｅ４．字下
げ部品表の発生の流れ図（第８図） Ｅ５．スクリーン・ダンプの例（第９、第１０、第１１
図） Ｅ６．概念設計ツールからプロジェクト管理ツールへの
インターフェイス（第１２図）Ｅ７．プロジェクト管理
ツール中のフォーマット化（第１３図） Ｆ１発明の効果 Ａ、産業上の利用分野 本発明は一般的にコンピュータに基づくプロジェクト管
理システムに関し、具体的にはプロジェクト管理ツール
を概念的な設計ツールに自動的に°インターフェイスし
て、ハードウェア製品の設計に統一的な方法を与えるこ
とに関する。概念的な設計ツールは、設計過程中の初期
段階で製品構造の階層的ツリー表示を発生及び展開する
ことを含む、製品設計へのトップ・ダウン機能方法を使
用する。本発明はユーザから収集する明細情報のための
インターフェイス及び初期の製造段階のためのリレーシ
ョナル・データベース及び計算機化プロジェクト管理ツ
ールのための部品表及びフィーシイビリティ（問題解決
）のコストの見積りを与える。

Ｂ、従来技術 新製品を設計、開発及び製造する方法もしくは現存の製
品に主要な変更を与える方法は、製品の品質を保持しつ
つ、予定の期間内に最小のコストで製品を市場に出す際
に製造マネジャ及びエンジニアに多くの難問をなげかけ
ている。現在の競争のはげしい工業界では、製造マネジ
ャ及びエンジニアは、新製品の複雑さ、世界的規模の生
産の複雑さ及び競争が変化するという性質のために生ず
る多くの問題に対処するための情報を必要とする。

競争に打克つためには新製品は極めて短期間に市場に出
さなければならないので、以前製品開発に関連していた
伝統的な学習曲線法は役に立たず、設計の初期の段階に
製品の（技術から製造への）リリースをより良く管理し
、設計のコスト・インパクトを判断する必要が生じた。

これ等の要求を満すためには、通常の製品の設計方法は
満足すべきものでないことを多くの会社が認めている。

現在の方法は設計の努力に製造エンジニアニング、コス
ト・エンジニアニング、ロジステイックな計画、調達、
製造及びサービス／援助を早期に関与させることを必要
としている。

さらに現在の方法は、設計、リリース及び製造を通して
製造データの計画及び制御を必要とする。

現在の管理ツール（用具）としての計画管理の起源は今
世紀の初頭にあり、ヘンリーＬ・ガント（Ｈｅｎｒｙ　
Ｌ、　Ｇａｎｔｔ）が第１次世昇天戦中に政府のために
現在でも有名な作業管理のための視覚的援助方法を開発
したことに始まる。ガント・チャートは各タスクを、タ
スクの継続時間に比例する長さに比例する棒で示した計
画予定グラフである。

１９５０年代の後半に、ペンシルバニア（Ｐｅｎｎｓｙ
ｌｖａｎｉａ　）大学のＥＤＶＡＣの共同発明者である
ジョン・ブレスパー・モークレー博士（叶、Ｊｏｈｎ　
Ｐｒｅｓｐｅｒ　Ｍａｕｃｈｌｅｙ）はクリティカル・
パス法（ＣＰＭ）を開発し、この方法はポラリス（Ｐｏ
ｌａｒｉｓ）潜水艦計画のコンサルタントであるライラ
ード・フラザー（Ｗｉｌｌａｒｄ　Ｆｒａｚｅｒ）によ
ってさらに発展された。フラザーの方法はプログラム評
価再検討（パート）法（ＰＥＲＴ）と呼ばれる。

パート・チャートはあるプロジェクトの先行及び後継タ
スク並びにクリティカル・バスを示す流れ図と似ている
ものである。

パート／ＣＰＭモデルは長年知られていて、プロジェク
ト管理に、多くの大会社によって使用されている。この
ようなプロジェクト管理ツールは最初本体コンピュータ
上で、次にミニ・コンピュータ上で具体化されたが、大
きな会社では利用できるが、小さな会社及び工場では利
用できない装置であった。より最近になって、マイクロ
即ち所謂パーソナル・コンピュータのために、種々のプ
ロジェクト管理ソフトウェア製品が開発された。

元々本体プログラムとして書かれ、後にパーソナルコン
ピュータ・プログラムとして書かれたプロジェクト管理
ツールの例はコンピュータ・ライン社（Ｃｏｍｐｕｔｅ
ｒｌｉｎｅ　Ｉｎｃ、）によって刊行されているプラン
トラック（Ｐｌａｎｔｒａｃ）である。このプログラム
は最初英国で建設業界のために書かれ、後に米国に搬入
されたものである。特にパーソナル・コンピュータのた
めに書かれた最初のプロジェクト管理ツールは、現在ソ
フトウェア出版社（Ｓｏｆｔｗａｒｅ　Ｐｕｂｌｉｓｈ
ｉｎｇ　Ｃｏｒｐ、）によって出されているバーバード
・プロジェクト・マネジャ（Ｈａｒｖａｒｄ　Ｐｒｏｊ
ｅｃｔ　Ｍａｎａｇｅｒ）である。現在では１００以上
のプロダクト・マネジャ・アプリケーションがパーソナ
ル・コンピュータのために書かれている。これ等はコン
ピュータをベースとするプロジェクト管理ツールを小さ
な会社及び工場に経済的にアクセス可能にしたが、その
アプリケーションはユーザの側である程度の精密さを必
要とする。この結果、多くの小さな会社及び工場は依然
プロジェクト管理に手書きの方法を使用しており、しば
しば計画のサプライにおいて１ステツプ先に留まる進捗
担当者及びその場しのぎ的な仕事に依存している。

ルパートＡ、シュミットベルク（Ｒｕｐｅｒｔ　Ａ。

Ｓｃｈｍｉｄｔｂｅｒｇ）マークＡ、イエリー（Ｍａｒ
ｋ　Ａ。

Ｙｅｒｒｙ）はオートファクト１９８６年輪文集（Ａｕ
ｔｏｆａｃｔ　　１９８６　Ｐｒｏｃｅｅｄｉｎｇｓ）
の第９−３１乃至第９−４３頁の論文「トップ・ダウン
方式を使用した設計用複合アセンブリＪ　　（Ｄｅｓｉ
ｇｎｉｎｇＣｏｍｐｌｅｘ　Ａｓｓｅｍｂｌｉｅｓ）に
、エンジニャが先ずトップ・ダウン組立体を形成して、
下方に作業を進め、下位のサブアセンブリ及び部品の細
部を埋めて行く設計方法を説明している。この方法では
、設計対象の階層的表示を組立てて、細部を仕上げてい
る。設計の概念が精密になるにつれ、設計の制約は階層
の下へと伝えられる。精密化の各レベルでの設計概念の
評価によって、フィードバックが設計変更の勧告もしく
は一部の設計の制約の緩和の要求の形で階層の上方に伝
えられる。

このトップ・ダウン設計方法は新製品のための伝統的な
方法よりも著しい利点を有する。しかしながらシュミッ
トベルク及びイエリーの方法はユーザの側での高度のコ
ンピュータ設計の精密さを仮定したＣＡＤ／ＣＡＭシス
テム環境で具体化されるものである。望まれるものはト
ップ・ダウン設計方法の長所を取入れ、そして新ハード
ウェア製品の設計と生産を完全に統合したプロジェクト
管理ツールとのインターフェイスを与える、使用の簡単
なシステムである。

Ｃ０発明が解決しようとする問題点 本発明の目的は、ハードウェアの製品設計にトップ・ダ
ウン機能方法を適用し、ユーザから集めた情報をプロジ
ェクト管理ツールに自動的に入力する、使用が容易なシ
ステムを与えることにある。

本発明の他の目的は概念的設計ツールを使用して集めた
詳細な情報をプロジェクト管理ツールへの入力として入
力するインターフェイスを与えることにある。

Ｄ０問題点を解決するための手段 本発明に従えば、コンピュータ・デイスプレィ上のスケ
ッチ・シート方式が製品の機能設計を導入するのに使用
される。ユーザは部品の記述だけをキー人力する必要が
あり、システムが階層ツリー構造をコンピュータ・デイ
スプレィ上で自動的に描き出す。次にユーザは部品毎に
、製品のすべての部品について考慮するようにプロンプ
トされる（促される）。一連のメニューが、部品のため
製造計画に従って現われ、ユーザを案内する。

プロセスは製品設計の機能スケッチの発生によって始ま
る。このスケッチは階層ツリー構造の形をなし、トップ
・ダウン設計方法を援助する。システムはユーザに製品
の要素である部品を照会し、照会過程が進行するにつれ
、ツリー構造がコンピュータ・スクリーン上に形成され
、ユーザに見えるようになる。

製品の機能的階層中の各要素部ち項目の背後では、関連
製造情報が集められている。この製造情報の詳細は製品
のリリースの立案、計画及び製品計画だけでな（フィー
シイビリティ（問題解決の可能性）レベルでのコストの
推定にも使用される。

ユーザは設計過程の任意の時間に上位レベルもしくは極
めて詳細なレベルで提案されている製品もしくは製品の
部品を取扱うというオプションを有する。任意のレベル
でユーザの知らない製造上の細部はデータベースから既
知の項目の属性を使用して、省略時解釈によって選択す
ることができる。

製品の設計者には製造の初期段階もしくは設計過程と製
造及び他の生産関連事項との統合について援助が与えら
れる。設計者は製品構造中の各項目について製造用デー
タを入力するようにプロンプトされ、階層ツリー構造は
３次元構造になる。

この３次元構造はいくつかの目的に使用される。

この製造用データは処理されて設計者が必要な推定値も
しくは計画が作成される。製造用データは次の４つのカ
テゴリに分類できる：　（１）製品の製造計画を援助す
る情報、（２）製品のコスト推定値を発生するのを援助
する情報、（３）製品リリース計画の発生を援助する情
報及び（４）類似の項目を探す際にＣＡＤ／ＣＡＭ設計
者を援助する情報。第４の場合は、従って設計者は他に
設計する労を避けて類似の設計を使用する、もしくは修
正のためのテンプレートとして既存の設計を使用するこ
と、もしくは新らしい設計を準備するための案内に使用
するというオプションを有する。

早期のコスト見積りは極く上位レベルのアセンブリ、は
とんど細部を含まない部分だけを考えるので、本発明に
よって具体化される階層的方法は製品のコスト見積りに
便利なインターフェイスを与える。リリース計画が完成
すると、さらに多くの細部が利用可能になるので製品の
コスト見積りはより詳細なツリー構造をデイスプレィ上
に展開してより正確な見積りを与える。製品の極めて初
期の開発段階のコスト見積りは設計の最も重要な部分に
エンジニャリングの努力を向けるだけでなく製品のフィ
ーシビリテイの決定を援助する。

概念的な設計ツールを使用して集めた製造用の細部情報
はプロジェクト管理ツールに自動的に入力される。リリ
ース計画を発生するのに必要な情報のこのような自動的
転送は現在の牢乎作業的プロジェクト管理システムより
も使い良さ及び生産性の著しい向上を与える。この過程
は他に必要とされる製品リリース計画段階及びユーザと
の対話によって前もって集められた利用可能な情報、知
識及び相互関係を使用して製品リリース活動シーケンス
及び計画を形成する。すべてのタスク及び活動時間は製
品の構造を決定する際の概念的設計ツールによって集め
られているのでプロジェクト管理ツールへのユーザの直
接的インターフェイスは必要でない。ユーザが供給しな
ければならない唯一の追加の情報は各資源の利用可能な
容量である。

Ｅ、実施例 Ｅｌ、製品の構造 第１図を参照すると、機能的ブロック図で自動部品表シ
ステムが示されている。このシステムの主要部分はデー
タベース１０及び照会システム１２である。データベー
ス１０は現在利用可能ないくつかの製品のうちの任意の
ものでよいが、好ましい実施例の説明の目的のためには
ＩＢＭのデータベース（ＤＡＴＡＢＡＳＥ）２　（ＤＢ
２）を使用する。ＤＢ２はリレーショナル・データベー
ス管理システムであるが、階層データベースを含む他の
データベースも使用できる。照会システム１２はエキス
パート・システムでよいが好ましい実施例ではＩＢＭの
再構造化拡張実行プログラム言語（ＲＥ　Ｘ　Ｘ）を使
用する。ＩＢＭのＤＢ２についての一般的情報はＩＢＭ
社刊０ＧＣ２６−４０７３−２に説明されている。ＲＥ
ＸＸ言語の説明はＩＢＭ社刊０ＧＣ２４−５２３８−２
で参照される「仮想マシン／システム・プロダクト、シ
ステム・プロダクト・インタープリタ・ユーザズ・ガイ
ド、リリース４　　（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ
／ＳｙｓｔｅｍＰｒｏｄｕｃｔ、　Ｓｙｓｔｅｍ　Ｐｒ
ｏｄｕｃｔ　Ｉｎｔｅｒｐｒｅｔｅｒ　Ｕｓｅｒ’５Ｇ
ｕｉｄｅ、　Ｒｅ１ｅａｓｅ　４　）になされている。

ユーザ１４は先ず照会システム１２によって機能的な製
品構造について照会され、ユーザの入力に応答してデー
タベース１０はテーブル中にその構造をとらえる。照会
セツションはユーザに製品名を入力するようにプロンプ
トすることによって始まる。製品がたとえば新製品の芝
刈り機であるとすると、ユーザは単に「芝刈り機」をタ
イプで入力する。次に照会システムはその製品の主要部
品をリストするようにプロンプトする。芝刈り機の場合
は、部品は本体アセンブリ、エンジン、袋アセンブリ、
ハンドル及び制御アセンブリである。

これ等は次の部品を入力させるためのプロンプトによっ
て、ユーザから個々に入力され、もしくは「終り」を入
力することによってこれ以上主要部品がないことが示さ
れる。主要部品を入力すると、ユーザは「終り」を入力
し、次に照会セツションは入力した主要部品の下位部品
を調べる。たとえば、照会システム１２はユーザ１４に
本体アセンブリの部品の入力を促す。これ等の部品はエ
ンジン・デツキ及び車輪である。フレーム・アセンブリ
のすべての下位部品が入力されると、ユーザは「終り」
を入力し、これによって次に照会システムはユーザにエ
ンジンの部品を導入するよもにプロンプトする。今の場
合、完全なエンジン・アセンブリが外部から調達される
ものとすると、ユーザは部品をリストする必要がないの
で、ユーザは単に「終り」を入力する。この過程は新製
品のすぺての部品を必要な細部レベル迄入力する迄続け
られる。

照会セツションが進むにつれ、ユーザ１４によって導入
された部品はリレーショナル・データベース１０によっ
てテーブル中に取得され、機能的な階層ツリー構造１６
がコンピュータ・スクリーン上に発生される。このツリ
ー構造の一般化した例を第２図に示す。下位アセンブリ
が製品中に２度以上現われる時は、この下位アセンブリ
もツリー中に複数同視われる。第２図の例ではツリー構
造は３つのレベルを有する。ツリーは少なくとも２レベ
ルを有し、現実の限界はあるとしても、製品及びこの製
品を画定するのに要する細部のレベルに依存して無数の
レベルが存在する。本発明の特定の実施例では、３０レ
ベル迄のツリー構造が許容されている。経験上、最も複
雑な部品を除き、すべての場合に３０レベルで十分なこ
とがわかっている。新らしい芝刈り機の例の場合には、
第２図のブロック１は説明（ｌｅｇｅｎｄ）として「芝
刈り機」を含んでいることになる。このブロックはユー
ザ１４がワード「芝刈り機」を入力すると直ちに発生さ
れる。次にユーザが芝刈り機の主要部品の名前を入力す
ると、ブロック２が説明「本体フレーム」とともに、ブ
ロック３が説明「エンジン」とともに、ブロック４が説
明「袋アセンブリ」とともに、ブロック５が説明「ハン
ドル兼制御アセンブリ」とともに発生されることになる
。

これ等のブロックが発生される時、これ等をブロック１
に接続する線も発生される。続いて、次のレベルで、ブ
ロック６が説明「エンジン・デツキ」とともに、続いて
説明「車輪」とともにブロック７が、これ等のブロック
をブロック２に接続する線とともに発生される。エンジ
ンは完成アセンブリとして購入されているので、ユーザ
からは下位部品名は入力されず、従ってブロック３の下
にはブロックは存在しない。次に照会セツションに応答
して、ユーザが下位部品のデータを入力する時にブロッ
ク８．９及び１０が発生される。

データ・ベース１０はユーザ入力からの部品情報を第１
表に示した形式を有するテーブル中に取得する。

このテープ）５と第２図の階層ツリーを比較すると、見
出し「項目」の下には番号１が４回リストされ、その直
ぐ右には番号２．３．４及び５がリストされていること
がわかる。１に続いて２が２回現われ、右には番号６及
び７が存在する。従って第１表に示したテーブルは階層
ツリー構遜を直接的に記述していて、このテーブルから
第２図に。

示したグラフ表示がコンピュータ・デイスプレィ上に表
示されるように発生される。ユーザはこの表示の発生中
及び照会セツションの終りに製品の構造が確定した後に
、このツリー構造を見て正しいかどうかをチエツクする
ことができる。

第１図を再び参照すると、製品構造が確定された後の次
の動作は字下げ部品表１８を形成することである。第２
図に示した階層ツリー構造及び第１表に示したリレーシ
ョナル・データベース・テーブルによって一般的に示さ
れた製品の場合には、字下げ部品表は第２表に示した一
般的形式を有する。第１表は製品データ構造の論理メモ
リを示し、第２図及び第３表はデータの２つの代替表示
を示していることは明らかであろう。この部品表は製品
のためのデータベース・テーブルをアクセスすることに
よって形成される。最上位レベルで、項目１は字下げ（
右シフト）されていない。第２のレベルの項目２．３．
４及び５は１スペース分字下りしている。第３レベルの
項目６．７．８．９及び１０は各々２スペース字下りし
ている等々になっている。アプリケーション・コードは
次のように上記項目の階層構造に従っている。項目１が
最上部の打上に現われる。項目２が第２行の上に現われ
る０次にデータベースの先行項目（左項）としての項目
２を探索すると、項目６及び７が見出される。従って項
目６が第３行上に現われる。

次にデータベースの先行項目６を探索する。この例では
、何も見出されない。従って項目７が第４行に現われる
。再び、データベースの先行項目７を探索するが何も見
出されず、項目３が第５行上に現われる。残りの項目が
同様にして処理され、最後に完全な部品表が形成される
。

第３図は、照会過程中にコンピュータ・スクリーン上に
発生する階層ツリー構造の完全な具体例を示している。

２レベルだけしか示されていないが、現実の限界内で、
製品及び製品を画定するのに必要な明細のレベルに依存
して、複数のレベルを発生することができる。又使用す
るデイスプレィの能力に依存して、階層ツリー構造は明
細のレベルが進むにつれていくつかの相継ぐスクリーン
上に表示される。製品のコストの見積りを行うため、先
ず階層ツリー構造を使用して製品の構造を発生する。製
品の構造の各項目について、ユーザは既知の製造情報を
入力しなければならない。この情報によって、コスト推
定値をデータベース１０から引出すことができる。ユー
ザはユニット当りの時間を単位とする全製品アセンブリ
時間についての粗な推定値及び１５％といった臨時費因
子を入力する。システムは製造構造を字下げ部品表であ
る部品のリストに分解する。部品当りのコストだけでな
く各部品の数量が、各項目に関連するリレーショナル・
データベース中の製造情報テーブルから引出される。コ
スト見積り関数が次にリスト上の各部品についてその数
量にそのコストを掛ける。部品リストのためのこの結果
が加算される。

労働推定時間に標準の時間当り労働費及び難易率が乗算
される。部品リストの乗算と労働の乗算結果が加算され
て、結果がユーザに出力される。

第４図はユーザがたとえば対象として電池を選択し、活
動「明細」を選択した時に現われるコンピユータ・デイ
スプレィのスクリーンを示している。設計エンジニャは
このスクリーンを使用して既知の製造データをキー人力
する。この例では設計者はシアーズ（Ｓｅａｒｓ）社か
ら購入済みの電池を使用することを考えている。製品の
構造中には１個の電池があり、その機能は電カニニット
である。

ユーザは次に選択を行って、既知の項目の属性に基づい
てリレーショナル・データベースから省略時値を求める
。ユーザは活動「省略時」を選択し、第５図に示された
スクリーンが表示される。リレーショナル・データベー
スがこれ等の省略時値をアクセスする方法は、照会セク
ション中にユーザの入力データが取得されたテーブルを
アクセスすることによる。第５図に示されたスクリーン
は星印をマークした結果の省略時値を表示する。システ
ムは項目番号Ａ０００を発生している。ツリー内のこの
項目の位置からシステムはこれが本体アセンブリである
と判断する。販売会社のフル・ネーム「シアー−ズ・レ
ブツク社（ＳｏａｒｓＲｏｅｂｕｃｋ　Ｉｎｃ、）　Ｊ
が挿入される。電池を製品に組込む方法はアセンブリで
ある。この項目は完全な既成品として購入されたもので
あるものであるから、この作業の所要時間（調達時間）
は０である。

実際値に基づく、電池当りのコストは１５０００ドルで
ある。項目の分類即ちグループ技術分類は収集した属性
機能、資源戦略及び販売会社に依存して、システムが発
生される。この項目分類カードは計画及び調達を含む多
くの生産計画機能に使用することができる。

Ｅ２．概念的設計ツールの論理の流れ同第６図を参照す
ると、ソフトウェアで具体化された概念的設計ツールの
流れ図が示されている。

この分野の通常の知識を有するものは、ベーシッ４　（
ＢＡＳ　Ｉ　Ｃ’）　、パスカル（Ｐａｓｃａｌ）もし
くはＣのような任意の適切なコンピュータ言語で、これ
等のコンピュータ言語をサポートするＩＢＭパーソナル
・システム（Ｐ　Ｓ）　　・コンビニご夕のためのソー
ス・コードをこの流れ図から書くことができる。

このプロセスは機能ブロック１００に示したように、製
品の機能的構造を入力することによって開始する。この
入力は第７図に関して詳細に説明される照会セツション
中に行われる。−皮製品の機能的機能が入力され、階層
ツリー構造が所望の明細の現在のレベル迄発生されると
、ユーザはテロンプトされて機能ブロック１０２中の構
成中の項目を選択する。ユーザが項目を選択すると、シ
ステムは機能ブロック１０４中で製造明細のためのポツ
プ・アップ（出し）パネルを提示する。

このポツプ・アップ・パネルによってユーザは機能ブロ
ック１０６中で既知の製造情報をキー人力する。この情
報がユーザによって入力されると、システムは機能ブロ
ック１０８で項目番号を発生する。次にシステムは機能
ブロック１１０でユーザに省略時情報をアクセスするよ
うに選択させる。

判断ブロック１１２中でテストが行われ、ユーザが省略
時値をアクセスすることを選択したかどうかが判定され
る。選択していない時には、次に判断ブロック１１４中
でテストが行われ、製造明細を入力すべき項目がさらに
存在するかどうかが判定される。もし存在する時は、プ
ロセスは機能ブロック１０２にループ・バックする。判
断ブロック１１２中のテスト結果がＹＥＳ　（Ｙ）であ
ると、即ちユーザが省略時情報をアクセスすることを選
択すると、システムはデータベース１０中で省略時値を
アクセスし１．これ等の値を挿入する。次に機能ブロッ
ク１１８中で、システムは項目分類コードを発生する。

ユーザは機能ブロック１２０中の省略時データの任意の
ものをオーバーライドできるというオプションが与えら
れている。テストが判断ブロック１２２中でなされ、ユ
ーザが任意の省略時デー夕のオーバーライドを選択した
かどうかが判断される。もしオーバーライドした時は、
システムは機能ブロック１０６にループ・バックして、
ユーザは前に挿入した省略時データのタイプオーバー（
書直し）として既知の製造データのキー人力ができる。

そうでない時はシステムは機能ブロック１０２にループ
して製品の機能的構造中の次の項目を選択する。最後に
、判断ブロック１１４のテスト結果が否定（Ｎ）になる
時に、プロセスは終る。

Ｅ３．照会システムの論理の流れ同 第７図は本発明の照会システムの論理の流れ図である。

第７図に示したプログラム論理は第１表に示したデータ
ベースを構築するためのものである。この流れ図はＩＢ
Ｍ社のＲＥＸＸ言語のような対話システム及びＩＢＭ社
のＤＢ２のようなデータベース・システムと組合した時
に通常の技術を有するプログラマが必要とされるコード
を書いて照会システムを具体化するのに十分なものであ
る。第７図を参照すると、このプロセスはブロック２０
で２＝１にセットすることによって開始する。ここでｌ
は製品もしくは部品のレベルである。

次に、機能ブロック２２で、システムのユーザは製品名
を入力するようにプロンプトされる。この例では、名前
は「芝刈り機」である。システムは判断ブロック２４で
ユーザ入力を待ち、製品名が入力された時に、システム
は機能ブロック２６中で製品名を有するファイルをデー
タベース中に開き、コンピュータ・スクリーン上に製品
名を表示する。ブロック２８中でｌは部品の次のレベル
を示すｆ＋１にセットされ、システムは機能ブロック３
０中で製品のこのレベルの部品を入力するようにユーザ
にプロンプトする。判断ブロック３２によって判断され
るように、ユーザが部品を入力する度に、機能ブロック
３４で入力した部品はそのレベルのためのデータ・ベー
ス中に記憶され、システムは機能ブロック３６中でツリ
ー構造のノードで、コンピュータ・スクリーン上に入力
した部品を表示する。システムはユーザによる各部品の
入力の後に、このレベルの部品のリストに終りを示す終
り機能キーを押す迄ユーザに部品の入力をプロンプトす
る。従って、システムは判断ブロック３８中で終り機能
入力を求めてユーザ入力をテストする。もしこのキー人
力が検出されないと、システムは判断ブロック３２で次
のユーザ入力を待つ。入力が受取られると、この部品名
が機能ブロック３４中のデータベース・テーブル中に記
憶される等々に動作が進行する。

終り機能キーを押すことによって示されるように、所与
のレベルのためのすべての部品が入力されると、次にシ
ステムは判断ブロック４０で部品の現行レベル中の最後
の部品がユーザによって入力されたかどうかを判断する
。入力されていないと、現行レベルの次の部品が表示さ
れたツリー構　′造中で強調表示され、システムは機能
ブロック３０にループ・バックし、ユーザはここで再び
この部品の入力がプロンプトされる。他方、判断ブロッ
ク４０によって検出されるように、ユーザによって部品
の現行レベルの最後の部品が入力されていると、システ
ムは判断ブロック４４でユーザ入力をテストし、次のレ
ベルの部品を入力してよいかどうかを判断する。この入
力は次のレベルがプロンプトされた時に、Ｙキーもしく
はＮキーをユーザが押すことによって達成される。ユー
ザが現在次のレベルの部品を入力することを望んでいる
ことを示して、Ｙキーが押されると、システムはブロッ
ク２８にループ・バックして、次のレベルにインデック
スする。他方、ユーザがこの時、部品の次のレベルを入
力したくないこと、もしくは入力すべき次のレベルの部
品が存在しないことを示してＮキーが押された時は、照
会過程が終る。

Ｅ４．字下げ部品表の発生の流れ同 次に第８図の流れ図を参照すると、この図は照会セツシ
ョン中に形成されたデータベース中のテーブルから字下
げ部品表が自動的に発生される方法を示している。ＩＢ
Ｍ　　ＤＢ２データベースのような、データ・システム
を理解しているこの分野のプログラマはこの流れ図の論
理から本発明を具体化するコードを書くことができる。

このプロセスは第８図のブロック４６で１＝１、ｉ＝０
にセットすることによって開始する。ここで２は上述の
部品レベルであり、ｉは部品表の字下げ（右シフト）量
である。次にレベル１０項目１が機能ブロック４８中で
アクセスされる。現在の例では、この項目は製品名「芝
刈り機」である０次に項目１が機能ブロック５０中でプ
リント（書込み）され、次にブロック５２中で２及びｉ
が各々１を加えることによって、インデックスされる０
次に判断ブロック５４で、レベル２がツリー中に残され
ているかどうかが判断される。もし残っている時は、シ
ステムは機能ブロック５６で現行レベルのツリー中の次
の一番左の項目をアクセスする。アクセスした項目は機
能ブロック５８中で字下げ量ｉで書込まれる０次に機能
ブロック６ｏ中で、先行項目を求めてデータベース（Ｄ
Ｂ）が探索される。もし存在することが判断ブロック６
２で見出されると、システムはブロック５２にループ・
バックして、レベルと字下げ量を１だけインデックスす
る。そうでない時は、テストが判断ブロック６４でなさ
れ、現行レベルの最後の項目が接続されているかどうか
が判断される。もし接続されている場合にはレベル及び
字下げ量はブロック６６中で各々から１を減することに
よって逆方向にインデックスする０次にプロセスは判断
ブロック５４に戻り、順次項目のアクセス及び書込み過
程を続ける。判断ブロック５４中のテスト結果が否定（
Ｎ）の時、即ちツリー構造にどのレベルｌも残されてい
ない時は、レベル及び字下げ量はブロック６８中で１を
減することによって逆方向にインデックスされる０次に
判断ブロック７０中でテストがなされ、字下げ量ｉが０
以下であるかどうかが判断される。もし０以下でない時
は、プロセスは判断ブロック５４に戻る。そうでない時
は、字下げ部品表は完成し、処理が終る。

Ｅ５．スクリーン・ダンプの例 システムの論理について、さらに特定の例のユーザ・イ
ンターフェイスをスクリーン・ダンプによって示す。ス
クリーン・ダンプのうちの最初のものが第９図に示され
ている。第９図は製品「芝刈り機」並びに２つの下位部
品「上ハンドル」及び「下ハンドル」を有する最初の主
要部品「ハンドル」を単一のツリー構造で示す。このツ
リーは第７図及び第８図の流れ図によって示した論理に
よる３つのレベルを示している。第１０図では、ユーザ
は下位部品「上ハンドル」のための第４のレベルの部品
を入力している。これ等の２つの図から、各部品レベル
がシステムへのユーザ入力によって形成される方法が明
らかであろう。最後に、第１１図に、コンピュータ・ス
クリーン上に現われた時の芝刈り機のハンドル・アセン
ブリのための字下り部品表を示す。データベースから発
生される完全な部品表を表示するためには、部品表は図
示したようにカーソル・キーによって上方もしくは下方
に画面を移動することができることに注意されたい。

上述のことから、本発明に従うシステムを使用すること
によって、さほど精通していないコンピュータのユーザ
でも、新製品のための部品表を迅速に形成できることが
明らかであろう。この方法は設計の初期段階で資源もし
くは構造に関して、くわしい明細を必要とする製品の部
品及び下位部品を識別する際の助けとなる。

Ｂ６．概念設計ツールからプロジェクト管理ツールへの
インターフェイス プロセスの次の段階は概念設計ツールによって収集した
データをプロジェクト管理ツールに入力することである
０本発明の好ましい実施例は、概念設計ツールとミツチ
ェル管理システム社（Ｍｉｔｃｈｅｌｌ　Ｍａｎａｇｅ
ｍｅｎｔ　Ｓｙｓｔｅｍｓ　Ｉｎｃ、）によって販売さ
れている管理兼プロジェクト計画システム（Ｍａｎａｇ
ｅｍｅｎｔ　Ａｎｄ　Ｐｒｏｊｅｃｔ　Ｐｌａｎｎｉｎ
ｇ　Ｓｙｓｔｅｍ　−ＭＡＰＰＳ）なるプロジェクト管
理ツール間のインターフェイスを与える。このプログラ
ムはマツプアウト（ＭＡＰＰＯＵＴ）及びマツプイン（
ＭＡＰＰＩＮ）と呼ばれる２つのユーティリティ・プロ
グラムを含む。マツプアウトによって、ユーザはインタ
ーロッキング・マツブス・ネットワーク・データ・ファ
イルを取出し、この情報をＡＳＣＩＩフォーマット中に
書込むことによって、マツブス・ネットワーク中に含ま
れているネットワーク・データにアクセスできる。この
再構成によってファイルは実質的にアンロックされ、マ
ツブス・ネットワーク・データが分離され、アクセス可
能になり、新らしい報告フォーマットを形成して、これ
を他のプログラムからのデータと再結合することができ
る。マツプインは他のプログラムからのデータをマツプ
・ネットワーク・データファイルに直接挿入可能にする
インターフェイスである。

マツブス・プロジェクト管理ツールは本発明の好ましい
実施例において使用され、本発明を実施する最良モード
を表わしているが、同程度の容量及び機能を有する他の
プロジェクト管理ツールも本発明の実施に適しているこ
とは明らかであろう。

本発明に従えば、プロジェクト管理ツールへの直接ユー
ザインターフェイスは必要でない。それはすべてのタス
ク及び活動時間が製品構造中の各項目について、概念設
計ツールによって収集されているからである。ユーザが
供給しなければならない唯一の追加の情報は各資源の利
用可能な容量である。概念設計ツールから利用できる情
報は項目を形成するのに必要な技術、項目のタイプ、項
目の分類コード、調達源０、項目を設計するための所要
時間、この項目をシミュレートするための（必要ならば
）所要時間、項目の原型を得るための所要時間、項目を
エンジニアリング（技術）から製造ヘリリース（発行）
する時間、項目を販売会社から調達する（必要ならば）
のに要する調達時間、項目を販売会社から移動する（必
要ならば）時間、項目を検査する（必要ならば）時間、
項目を倉庫から取寄せる（必要ならば）時間を含む。

プロジェクト管理技術は製品のリリースを計画するのに
使用される。ユーザは製品リリース計画のための各項目
のための製造明細も含む製品構造を提示する。所要時間
の欠けている構造内の項目は強調表示される。しかしな
がら、ユーザがオーバーライドしないと、欠けた所要時
間は省略時解釈モードによって標準の省略時間にするこ
とができる。ユーザはアプリケーション・プロフィール
を再検討して、リリース計画の仮定を制限適に更新する
ことができる。ユーザはｒ項目の臨界性（クリティカリ
ティ）の定義」機能を使用して、項目が臨界的（クリテ
ィカル）であるかどうかを判断する規則を変更できる。

製品構造内の臨界項目だけがプロジェクト管理ツールに
送られる。臨界性因子には項目コスト、項目の調達及び
作業の所要時間及び新技術因子が含まれる。仮定には又
順方向もしくは逆方向プロジェクト計画が含まれ、逆方
向計画が選択された時には、プロジェクト完成時日付け
が含まれる。又次の各々について省略時の推定値も必要
である。

・測定の時間の単位（日か週） ・アセンブリの平均的部品の設計時間。通常でない設計
時間は製造明細中に特に指定される。プロジェクトの資
源としての設計者の数も必要である。

・部品当りのシミュレーション時間。製品のための資源
として利用可能なシミュレータの数も必要である。もし
同じ人間が設計とシミュレーションの両方を行う時は、
比例する量の資源を両方の活動に割当てられな（ではな
らない。

・部品当りのプロトタイピング時間。この製品のために
利用可能なプロトタイピング用資源の数が必要である。

もし同じ人間が、設計、プロトタイピング及びシミュレ
ーションを共に行う時には、比例した量のを３つの活動
の各々に割当てる必要がある。

・部品当りの省略時作業時間（ユーザが製造明細情報内
に時間を示さない時には、情報を全く使用しないのでは
なくて、省略時の値が使用される）。

作業資源の能力を示したい時は、作業資源の数を指定し
なければならない。

・項目をエンジニアリングから製造ヘリリースするため
の省略時の時間 ・部品当りの省略時の調達時間 ・部品当りの省略時の移動時間 ・部品当りの省略時の検査時間 ・部品当りの省略時の倉庫からの取寄せ時間・省略時の
アセンブリ時間（この省略時の時間は０でよい。それは
代表的なアセンブリ時間は任意の他の考慮すべき時間よ
りはるかに短かいからである） ・製品のためのエンジニアリングの事前分析をするため
に企業が割当てる時間の量 ・製品を正式にリリースするために企業が割当てる時間
の量 ・プランに組込まれたパーセントの臨時性さらに製品に
割当てられた従業員の休暇計画も検討しなければならな
い。

製品構造は上述のように、システムによって部品のリス
トに分解される０項目臨界性の定義機能が呼出され、ユ
ーザが選択した因子に基づいて部品リストが修正される
。リスト上の部品についてのすべての製造明細情報がこ
の機能に渡される。

臨界的でない項目は項目臨界性の定義・機能を使用して
リストから除去される。次にシステムはリリース・プラ
ン・プロジェクト管理機能を呼出す。

臨界部品リスト及び対応する所要時間情報はプロジェク
ト・マネジャに渡される。各部品は設計、シミュレーシ
ョン、プロトタイピング、作業、調達、輸送、検査、倉
庫からの取寄せ、製品事前分析及び正式リリースのため
に、あるＯもしくは非０の単位時間を必要とする。リリ
ース・プラン管理機能は順方向もしくは逆方向計画モー
ドで動作する。順方向計画モードで、各項目は一連の時
間、及びこれに関連する資源消費イベントを有する。

プロジェクト・マネジャがリリース計画を完了する迄は
、ユーザはその製品のための最初のカストマ出荷日付け
を判断しない。プロジェクト・マネジャは最長の所要時
間の項目を選択して、これを最初に計画しなければなら
ない、消費される任意の資源は利用可能な資源から差引
かれる。プロジェクト・マネジャはすべてが計画される
迄、長い所要時間の項目の選択を続ける。最初のカスト
マ出荷日付けは、時間及び資源の理由のために先に繰延
べされるので、資源は過剰に割当てられない。

逆方向計画は最初のカストマ出荷日付けを選択して、こ
の日付けの前にすべての必要な活動をあてはめるように
逆方向に作業することを含む。この過程中は、利用可能
な資源が過剰に割当てられることがある。プロジェクト
・マネジャはこの事実をユーザに強調表示するが、計画
過程を続ける。

それは必要が生じたならば、ユーザは追加の資源を得る
ことができるからである。

このようにして、すべての臨界項目について、項目毎に
詳細な製品計画が形成される。上述の手順は製品の構造
及びコスト見積りについて繰返される。

製品のリリースを具体化するためには、ユーザは次にエ
ンジニアリングの変更を形成しな（ではならない。この
プロセスは製品内の各臨界項目についてリリース日付け
を有する詳細な製品計画で開始する。ユーザはエンジニ
アリング変更をまとめることを要求し、エンジニアリン
グ変更のパッケージのリリースのための所望を頻度を入
力する。

頻度は代表的な場合、月に１度もしくは２週間に１度で
ある。次にシステムによって各エンジニアリング変更リ
リースについての変更回数が発生される。システムはリ
リース計画中に各項目のリリース日付けを決定する。こ
れ等の日付けはユーザによって定義されて、期間中にグ
ループ化される。

ＥＣ（エンジニアリング変更）番号機能が呼出され、シ
ステムは必要な各エンジニアリング変更リリースについ
てエンジニアリング変更参号を発生する。

以上簡単に概略を説明したので、次にプロジェクト管理
ツールに対する自動的なインターフェイスの流れ図を示
す第１２Ａ、第１２Ｂ及び第１２Ｃ図を参照されたい。

この流れ図に示した論理は、通常の技術を有するプログ
ラマが本発明を具体化する際にベーシック（ＢＡＳ　Ｉ
　Ｃ）　、パスカル（Ｐａｓｃａｌ）もしくはＣのよう
な高水準言語のソース・コードを書くのに十分である。

プロセスは第１２Ａ図の機能ブロック２００中で、概念
設計ツール（ＣＤＴ）を使用して製品構造が作成及び修
正される。この処理は第７図を参照して説明されたもの
である。次に機能ブロック２０２中で、概念設計ツール
を使用して、構造中の項目毎に製造明細を入力する。こ
の過程は第４、第５及び第６図を参照して説明された。

この時点で、ユーザは機能ブロック２０４中に示したよ
うにリリース計画の発生を要求できる。

ユーザがリリース計画の発生を要求する時、本発明に従
うプロジ円りト管理インターフェイス（ＰＭｒ）が機能
ブロック２０６中で呼出される。

概念設計ツールによって発生されるデータ・ファイルが
プロジェクト管理ツールのためにフォーマット化される
方法は、第１３Ａ図乃至第１３Ｅ図を参照して詳細に説
明される。ユーザは次に判断ブロック２０８中で順方向
もしくは逆方向計画のどちらが望まれているかを尋ねる
。ユーザによって順方向計画が選択されると、ユーザは
プロンプトされて、ブロック２１０中で開始日付けが充
填される。しかし逆方向計画が選択された時には、ユー
ザはプロンプトされて、ブロック２１２中で最初のカス
トマ出荷日付けが充填される。次に制御は第１２Ｂ図の
最上部に判断ブロック２１４に進み、ここでユーザには
アプリケーション・プロフィール省略時データを更新す
るためのオプションが与えられる。プロフィール化され
た省略時データはシステムによって自動的に挿入され、
ユーザはこの省略時データを使用するか、もしくはこれ
等を変更するかを選択できる。もしユーザが省略時デー
タの更新を選択した時は、ユーザは機能ブロック２１６
中で、ユーザが更新したいこれ等の省略時価をタイプす
ることによって新らしい値を入力する０次にプロセスは
判断ブロック２１８に進み、ここでユーザには再びシス
テムのデータ、この場合は臨界性の定義を更新するオプ
ションが与えられる。もしユーザが更新を選択した時に
は、機能ブロック２２０中で、ユーザはユーザが更新し
たい値をタイプすることによって新らしい定義が入力さ
れる。

この時、システムはブロック２２２．２２３及び２２４
中で臨界性の要求を満足する項目を選択して、ブロック
２２６中で選択した項目のリストを発生する。この分解
の専門家にとっては、この種の選択過程はデータベース
によって日常的に行われるものであり、上述のように好
ましいデータベースはＩＢＭ社のＤＢ２で゛あることは
明らかであろう。次にブロック２２８．２２９及び２３
０中で、ブロック２２６中で発生したリスト中の各項目
のための所要時間を加えて、第１２Ｃ図の最上部のブロ
ック２３２中ですべての項目及び関連する所要時間のリ
ストを発生する。

−度ブロック２３２中でリストが発生されると、システ
ムはブロック２３４中で、アプリケーション・プロフィ
ールから追加の所要時間を取出して、これ等の所要時間
をブロック２３６中で各項目について加える。次にシス
テムは機能ブロック２３８中でリスト中の最長所要時間
を発見する。関連する所要時間を有するすべてのイベン
トは、機能ブロック２４０中で活動として定義され、機
能ブロック２４２中で項目の活動がリストされる。次に
判断ブロック２２４によって、リスト中にさらに処理す
べき項目があるかどうかを判断する。もし存在する時は
、制御は機能ブロック２３８に戻り、ここで次の最長の
所要時間が見出される等々に進行する。−度量後の項目
が処理されると、機能ブロック２４６中でプロジェクト
管理ツールのためのファイルがフォーマット化される。

Ｅ７．プロジェクト管理ツール中のフォーマット化 プロジェクト管理ツール、ここではマツブス（ＭＡＰＰ
Ｓ）プロジェクト管理ツールのためのファイルをフォー
マット化する過程を第１３Ａ図乃至第１３Ｅ図に示す。

プロセスは第１３Ａ図の機能ブロック２５０中でマツブ
ス（ＭＡＰＰＳ）ネットワーク・データ・ファイルの骨
組みを呼出す。この骨組み（シェル）は活動もしくは資
源が書込まれていない空のデータ・ファイルである。

次に機能ブロック２５２中で、ファイルの骨組み中にプ
ロジェクトの名前が書込まれる。この名前は概念設計ツ
ールの製品名である。次に判断ブロック２５４中でチエ
ツクがなされ、この名前が有効がどうかが判断される。

もし有効でない時には、制御がブロック２５２に戻る前
に、ブロック２５６でエラー・メツセージが表示される
。有効な名前がファイル中に書込まれたものと仮定する
と、ファイルのためのヘッダ情報が機能ブロック２５Ｂ
中で書込まれる。活動、資源、コネクタ及び主要管理点
の数が機能ブロック２６０でチエツクされる。もし不備
があると、機能ブロック２６０に戻る前にエラー・メツ
セージが表示される。

ヘッダ情報がファイルに書込まれると、次の段階は第１
３Ｂ図の最上部のブロック２６４に示した活動ファイル
の書込みである。データ・フィールド・オプションがブ
ロック２６６でＡＰＰＥＮＤ（付属）に等しくセットさ
れ、活動数の書込み過程がブロック２６日中で開始され
る。−各活動数に続いて、ブロック２７０中でファイル
への活動明細の書込みが行われる。次にブロック２７１
で論理チエツクが行われ、続いて判断ブロック２７２で
、ファイルに書込まれるべき活動がさらに存在するかど
うかの判断がなされる。

次にブロック２７４中で資源ファイルがファイル中に書
込まれる。ブロック２７６中でデータ・フィールド・オ
プションがＡＰＰＥＮＤに等しくセットされ、資源シー
ケンス・ファイル番号の書込み過程がブロック２７８で
開始する。各資源ファイル番号の後に、ブロック２８０
中で資源の明細がファイル中に書込まれる。次にブロッ
ク２８１中で論理チエツクがなされ、続いて判断ブロッ
ク２８２中でファイルに書込むべき資源がさらに存在す
るかどうかの判断がなされる。。

次に第１３Ｃ図の最上部の機能ブロック２８４で時間及
びコスト情報が書込まれる。各活動について、活動数の
存在がブロック２８６中において検証され、ブロック２
８８中で時間及びコストの明細がファイルに書込まれる
。この処理は判断ブロック２８７中ですべての活動が処
理されたことがわかる迄続けられる。

次に活動資源の用途（ＡＲＵ）が機能ブロック２９０中
で書込まれる。各活動について、活動数が再びブロック
２９２中で検証され、ブロック２９４中で活動、資源数
及び用途の明細がファイル中に書込まれる。この処理は
判断ブロック２９５中ですべての活動が処理されたこと
が明らかになる迄続く。

次に機能ブロック２９６で活動の主要管理点（ＭＩＬ）
がファイルに書込まれる。第１３Ｄ図の最上部の機能ブ
ロック２９８で、主要管理点が書込まれ、次にブロック
３００中で主要管理黒目付けが書込まれる。次にブロッ
ク３０２中の活動数が検証される。このプロセスは判断
ブロック３０３によって明らかにされるようにすべての
主要管理点が書込まれる迄続けられる。

次にコネクタ情報がフォーマット化される。ブロック３
０４中で、いくつかの項目数のための活動が選択され、
ブロック３０６中で活動が日付けに従って順序付けられ
る。このコネクタ・ファイルはブロック３０８中でファ
イルに書込まれる。

各活動について、判断ブロック３１１によって明らかに
されるようにすべての活動が処理される迄活動がブロッ
ク３１０中で書込まれる。次にこの項目数について、す
べての項目が、判断ブロック３１４で明らかにされるよ
うに処理される迄、自／至（ｆｒｏｍ／ｌｏ）関係、即
ちコネクタ情報がブロック３１２で指定される。

次に第１３Ｅ図を参照すると、機能ブロック３１６に示
したように、上述のマツプスイン（ＭＡＰＰＳＩＮ）ユ
ーテイリテーを使用して、書込済の種々のファイルがマ
ツブス（ＭＡＰＰＳ）ネットワーク・データ・ファイル
の骨組みにコピーされる６次にブロック３１８で、プロ
ジェクト・データ・ファイルがマツブス（ＭＡＰＰＳ）
プロジェクト管理ツールに渡される。この時点で、ブロ
ック３２０中に示されたようにマツブス（ＭＡＰＰＳ）
管理゛ツールが実行できる。ブロック３２２で修正した
プロジェクト・データ・ファイルが戻される０次にブロ
ック３２４中でマツブスアウト（ＭＡＰＰＳＯＵＴ）ユ
テイリテイが呼出され、上述のフォーマットのマツプス
アウト（ＭＡＰＰＳＯＵＴ）ファイルが形成される。ブ
ロック３２５で、このフォーマットの修正プロジェクト
・データ・ファイルが概念設計ツールに搬入され、プロ
ジェクト・データが更新される。

リリース計画を発生するのに必要とされる情報の自動的
移動は現在の半分人間によるプロジェクト管理システム
に対して有用性と生産性の大きな増強を与える。この方
法は製品リリースを計画するのに必要な他のフェイズ及
びユーザの対話性によって前もって収集された利用可能
な情報、知識及び相互関係を使用して製品リリース活動
シーケンス及び計画を発生する。

Ｆ０発明の効果 本発明に従えば、ハードウェアの製品設計にトップ・ダ
ウン機能方法を適用して、ユーザから集めた情報をプロ
ジェクト管理ツールに自動的に入力する、使用が容易な
システムが与えられる。

【図面の簡単な説明】

第１図は本発明に従う、自動化部品表を具体化するため
の機能的要件を示すシステム・ブロック図である。 第２図は新製品の部品の機能的表示を示した階層的ツリ
ー構造の表示図である。 第３図は設計中の計画製品のための、システムによって
発生された階層ツリー構造のコンピュータ・デイスプレ
ーのスクリーンの図である。 第４図は第３図に示した構造の１つの部品のための初期
製造関与データのコンピュータ・デイスプレーのスクリ
ーンの図である。 第５図はシステムによって入力された省略時データを有
する１部品のための初期製造関与データのコンピュータ
・デイスプレーのスクリーンの図である。 第６図はソフトウェアで具体化した概念設計ツールの論
理を示す流れ図である。 第７図は夫々第２図及び第１表の階層ツリー及びテーブ
ルがデータベース中に作成される照会ツリーの論理を示
す流れ図である。 第８図はデータベース中のテーブルを使用し、第２表に
示した字下げ部品表を発生する論理を示した流れ図であ
る。 第９図は、本発明に従う、芝刈り機のハンドルのための
ツリー構造で、細部の２レベルの特定の　例を示したス
クリーンの図である。 第１０図は第９図のツリー構造を細部の３レベルに拡張
したスクリーンの図である。 第１１図は第９図及び第１０図に示した例から形成され
た字下げ部品表のページのスクリーンの図である。 第１２Ａ図、第１２Ｂ図及び第１２Ｃ図は本発明に従う
、プロジェクト管理ツールへの自動化インターフェイス
の流れ図である。 第１３Ａ図乃至第１３Ｅ図はプロジェクト管理ツールの
ために概念設計ツールによって収集され、第１２Ａ図に
示したインターフェイスによって呼出されたデータのフ
ァイルをフォーマット化するプロセスの流れ図である。 １０・・・・リレーショナル・データベース、１２・・
・・照会システム、１４・・・・ユーザ、１６・・・・
階層ツリー構造、１８・・・・字下げ部品表。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　山　　本　　仁　　朗（外１名） 笛　１　圀 ％２図 第１３ｃ図

Claims (2)

【特許請求の範囲】
1. （１）最終製品を製造するための全設計及び製造の努力
   を援助し及び改良するのに必要な、初期の製造関与情報
   のために与えられた概念設計ツールとプロジェクト管理
   ツールを自動的にインターフェイスする方法であつて、
   該方法は （ａ）上記概念設計ツールを使用して、ユーザに機能的
   製品構造を入力するようにプロンプトし、 （ｂ）ユーザによつて入力された製品構造のデータをデ
   ータベース中に格納し、 （ｃ）上記概念設計ツールを使用して、ユーザに上記機
   能的製品構造の製造明細を入力するようにプロンプトし
   、 （ｄ）ユーザによつて入力された製造明細のデータをデ
   ータベース中に格納し、 （ｅ）製品構造の項目のうちどれが臨界的であるかを判
   断する規制を適用するようにユーザにプロンプトし、 （ｆ）臨界性の条件を満足する項目をデータベースから
   選択し、 （ｇ）上記概念設計ツールによつて収集され、上記デー
   タベース中にとらえられた製造明細データからの所要時
   間に従つて、選択した臨界項目を順序付け、 （ｈ）順序付けられた選択項目を上記プロジェクト管理
   ツールのファイル中にフォーマット化し、 （ｉ）上記フォーマット化したファイルを上記プロジェ
   クト管理ツール中に搬入する段階を有する、概念設計ツ
   ールとプロジェクト管理ツールを自動的にインターフェ
   イスする方法。
2. （２）ユーザが入力する製造明細が各項目に対する所要
   時間を含み、上記選択された臨界項目を順序付ける段階
   が、 （ａ）各選択された臨界項目について、上記データベー
   スからの所要時間を加え、 （ｂ）すべての項目及び関連する所要時間をファイル中
   にリストし、各項目のすべてのイベント及び関連する所
   要時間をその項目の活動と定義し、 （ｃ）所要時間によつて順序付けられた各項目のすべて
   の活動をリストして、上記順序付けられた選択項目をリ
   ストする段階を有する、 上記特許請求の範囲第（１）項記載の方法。