(57)【特許請求の範囲】
【請求項１】
システム開発を支援するシステム開発支援装置において、
システム開発における上流成果物に基づいて生成される下流成果物を生成する手段と、
前記上流成果物の属性情報および前記下流成果物の属性情報を生成し、格納する手段と、
前記下流成果物について次の生成に先立って、格納された前記上流成果物の属性情報および前記下流成果物の属性情報の少なくとも一方が変更されているかを検知する手段と、を有し、
前記検知する手段で、前記上流成果物の属性情報および前記下流成果物の属性情報の少なくとも一方が変更されていることを検出した場合、前記下流成果物を生成する手段による前記下流成果物の生成が必要であると判断することを特徴とするシステム開発支援装置。
【請求項２】
請求項１に記載のシステム開発支援装置において、
前記属性情報を生成し、格納する手段は、前記属性情報として、前記上流成果物および前記下流成果物の誤り符号を生成することを特徴とするシステム開発支援装置。
【請求項３】
請求項１乃至２のいずれかに記載のシステム開発支援装置において、
前記下流成果物を生成する手段は、
前記検知する手段が前記下流成果物の内容に変更がなく、前記上流成果物の内容に変更があると検知した場合、上流成果物から下流成果物を生成して、前記下流成果物を置き換えることを特徴とするシステム開発支援装置。
【請求項４】
請求項１乃至３のいずれかに記載のシステム開発支援装置において、
前記検知する手段は、下流成果物の内容に変更があると検知した場合、上流成果物から生成された下流成果物が既存の下流成果物と内容が一致するかを判定し、
一致する場合は上流成果物と下流成果物が整合している、
不一致の場合は上流成果物と下流成果物が整合していない、と判定することを特徴とするシステム開発支援装置。
【請求項５】
請求項４に記載のシステム開発支援装置において、
前記判定結果を出力する手段をさらに有することを特徴とするシステム開発支援装置。
【請求項６】
請求項３に記載のシステム開発支援装置において、
前記検知する手段は、置き換えられた前記下流成果物と、既存の前記下流成果物の内容を比較し、
当該比較の結果、不一致の場合に再作成した下流成果物をシステム構築基盤へインポートする手段をさらに有することを特徴とするシステム開発支援装置。
【請求項７】
請求項１乃至６のいずれかに記載のシステム開発支援装置において、
前記下流成果物を生成する手段は、
前記上流成果物の識別情報を抽出し、次回以降下流成果物を生成する際には、前記上流成果物の識別情報を用いて、対応する上流成果物を特定することで、下流成果物を生成することを特徴とするシステム開発支援装置。
【請求項８】
請求項１乃至７のいずれかに記載のシステム開発支援装置において、
前記下流成果物を生成する手段は、前記上流成果物の変更日時を抽出し、
前記検知する手段は、下流成果物について次の生成に先立って、前記上流成果物の変更日時に基づき上流成果物の内容が変更されたかを検知し、生成すべき下流成果物を絞り込むことを特徴とするシステム開発支援装置。
【請求項９】
請求項２乃至８のいずれかに記載のシステム開発支援装置において、
前記属性情報を生成し、格納する手段は、前記上流成果物および前記下流成果物を予め定められた書式に成型し、成形された前記上流成果物および前記下流成果物から、前記属性情報である誤り検出符号を生成することを特徴とするシステム開発支援装置。
【請求項１０】
請求項３に記載のシステム開発支援装置において、
前記検知する手段は、前記下流成果物を生成する手段に付与されたバージョンを参照することで、当該生成する手段が変更されたことを検出し、前記生成する手段が変更された場合には、前記上流成果物の内容の変更有無を除き、前記下流成果物の内容の変更有無を検知し、
前記生成する手段は、前記下流成果物の内容に変更があったときに、前記上流成果物から前記下流成果物を生成し、生成された下流成果物と既存の下流成果物を置き換えることを特徴とするシステム開発支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、いわゆるシステムの開発（特に、そこで用いられるソフトウェアの開発）を支援する技術に関し、特にいわゆる上流成果物から下流成果物の作成の効率化に関する。
【背景技術】
【０００２】
ソフトウェアの開発、特に、システム構築基盤を用いたシステム、ソフトウェア開発では、システムの仕様を記述した仕様書を作成し、その仕様書に基づき定義体を作成してシステム構築基盤へインポートすることでシステムを製造し、テストを行う。このように上流成果物（例えば、仕様書）から下流成果物（例えば、定義体）を作成する方式は、２つの観点で分類できる。１つ目の観点は、上流成果物から下流成果物の作成手段が、自動、手動のどちらであるかである。２つ目の観点は、上流成果物からの作成を行わずに、直接下流成果物を変更することが可能であるか否かである。
【０００３】
上記２つの観点に基づくと、一般的な上流成果物から下流成果物を作成する手段を４つに分類できる。
【０００４】
１つ目の手段は、下流成果物作成が自動で、下流成果物の直接変更が不可となる場合で、一例は上流成果物をソースコード、下流成果物をコンパイルされたプログラムとする場合である。プログラムはコンパイルにより自動的に作成され、かつプログラムを直接変更することは通常できない。
【０００５】
２つ目の手段は、下流成果物作成が手動で、下流成果物の直接変更が可能となる場合で、一例は上流成果物を上流設計書、下流成果物を下流設計書とする場合である。下流設計書は、有識者が上流設計書を参照しながら手動で作成するため、下流設計書を直接変更することが可能である。
【０００６】
３つ目の手段は、下流成果物作成が手動で、下流成果物の直接変更が不可となる場合である。下流成果物作成が手動である場合、下流成果物の直接変更は通常可能であるため、このようなケースは実際には存在しないと考えられる。
【０００７】
４つ目の手段が本発明の対象であり、下流成果物作成が自動で、下流成果物の直接変更が可能となる場合である。このようなケースの一例は、上流成果物を仕様書、下流成果物を定義体作成ツールに基づき仕様書から自動的に作成される定義体とする場合である。当該定義体は、システム構築基盤上で編集可能であるため、仕様書を変更せずに直接定義体を変更することも可能となる。
【０００８】
このようなシステム開発において、一度下流成果物の作成を行った後に、一部の成果物を変更した場合、その影響範囲を特定して、影響範囲内の成果物を再作成する必要がある。
【０００９】
影響範囲を特定せずに、全ての成果物を再作成する方式も考えられるが、その場合どの成果物に変更が発生したかを把握できないため、システム構築基盤へのインポートやテストを全ての成果物を対象に行う必要がある。
【００１０】
多数の仕様書及び定義体を対象とした場合、システム構築基盤へのインポート及びテストには、膨大な工数を要するため、開発の効率化のためには変更が発生した成果物を絞り込むことが必要となる。
【００１１】
成果物の変更に影響を受ける範囲は、上流成果物と下流成果物の関係が１：１で対応しない場合、上流成果物と下流成果物との依存関係から判定する必要がある。このため、影響範囲は一般に自明ではなく、何らかの手段を用いて絞込みを行う必要がある。
特許文献１では、下流成果物作成が手動で、下流成果物の直接変更が可能であることを前提とし、各工程の成果物とそれらの関連付け情報を保持し、任意の成果物を修正する際に修正に関連する成果物情報を提示する。これにより、変更した成果物に依存する成果物の範囲を特定することが可能となる。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開平９−１６３９２
【発明の概要】
【発明が解決しようとする課題】
【００１３】
特許文献１では、成果物とは別にそれらの関連付け情報を保持するため、成果物の作成、変更、削除などに伴い、関連付け情報も保守する必要がある。よって、関連付け情報を持たない場合に比べて、保守工数が増加する。
【００１４】
また、本発明は下流成果物作成が自動で、下流成果物の直接変更が可能である、という前提を置いており、このような前提で影響範囲分析を行う技術は現状存在しない。
【００１５】
本発明の目的は、ユーザの工数を増加させることなく、上流成果物と下流成果物の変更に伴う不整合を解決することである。
【課題を解決するための手段】
【００１６】
上記目的を達成するために、本発明では、仕様書および定義体の属性情報を用いて、変更の発生している箇所を特定することで達成するものである。より具体的には、属性情報として、仕様書や定義体のファイル名、更新日時、ハッシュ値を用いるものである。
【００１７】
さらに、本発明の一例は、システム開発に用いるデータを格納する記憶装置と、当該記憶装置からデータを読み出す入力装置と、当該入力装置に接続されるプロセッサと、生成したデータを書きだす出力装置と、を備えるシステムであって、当該システムは、記憶装置から入力装置を用いて仕様書、定義体、属性情報などの成果物を読み出し、読み出した成果物の内容からどの成果物に変更があったかを示す変更ステータスを判定し、当該変更ステータスの内容から仕様書と定義体の内容に不整合が発生しているかを判断する。ここで、不整合が発生していると判断した場合に定義体を再作成し、不整合を解消することも本発明の一態様である。
【発明の効果】
【００１８】
本発明によれば、より容易に不整合の発生個所を特定可能になる。
【図面の簡単な説明】
【００１９】
【図１】本発明の第一の実施形態の、開発支援システム、システム構築基盤の構成を示す図である。
【図２】本発明の第一の実施形態の、定義体新規作成の処理手順を示す図である。
【図３】本発明の第一の実施形態の、定義体再作成の処理手順を示す図である。
【図４】本発明の第一の実施形態の、更新ステータス判定の処理手順を示す図である。
【図５】本発明の第一の実施形態の、定義体更新の処理手順を示す図である。
【図６】本発明の第一の実施形態の、既存属性情報の構成を示す図である。
【図７】本発明の第二の実施形態の、更新ステータス判定の処理手順を示す図である。
【図８】本発明の第一の実施形態の、開発支援システム、システム構築基盤のハードウェア構成を示す図である。
【発明を実施するための形態】
【００２０】
＜第一の実施形態＞
第一の実施形態は、仕様書を入力として定義体が初期作成された場合、定義体の属性情報を受け取り、仕様書および定義体にどのような変更が加えたれたかを示すステータス（以降、更新ステータス）を判定し、当該更新ステータス毎に仕様書と定義体との不整合を解決する手順を実施するシステムである。
以降、図面を参照して詳細に説明する。
図１は、本発明の第一の実施形態の、開発支援システム、システム構築基盤の構成を示す図である。
この図において、符号１０００は開発支援システムであり、仕様書格納部１００１、定義体格納部１００２、属性情報格納部１００３、属性情報読込部１０１０、属性情報比較部１１０１、属性情報作成部１０１２、属性情報出力部１０１３、仕様書読込部１０２０、定義体読込部１０３０、定義体作成部１０３２、定義体出力部１０３３、定義体インポート部１０３４、更新ステータス読込部１０４０、更新ステータス出力部１０４３を含んで構成される。
【００２１】
属性情報読込部１０１０は、属性情報格納部１００３から属性情報を読み込む。
属性情報比較部は、属性情報読込部１０１０で読み込んだ属性情報を比較する。
属性情報作成部１０１２は属性情報の値を作成し、作成した属性情報は属性情報出力部１０１３で属性情報格納部１００３へ格納される。
仕様書読込部１０２０は、仕様書格納部１００１に格納されている仕様書を読み込む。
定義体読込部１０３０は、定義体格納部１００２に格納されている定義体を読み込む。
定義体作成部１０３２は定義体の内容を作成し、作成された定義体は定義体出力部１０３３で定義体格納部１００２へ格納される。
定義体インポート部１０３４は、定義体格納部１００２に格納された定義体をシステム構築基盤１１００の中へインポートする。
更新ステータス読込部１０４０は、ユーザが定義した更新ステータスを受け取る。
更新ステータス作成部１０４２は、属性情報比較部１１０１での比較結果に基づき、更新ステータスを判定する。
更新ステータス出力部１０４３は、更新ステータス作成部１０４２で作成した更新ステータスを、ユーザインタフェースへ出力する。以上の各部の処理については、いわゆるプログラムに従ってCPUの如き演算装置の処理で実現される。その詳細は、後述する。
【００２２】
また、符号１１００はシステム構築基盤である。本実施形態が前提とするシステム開発では、仕様書から自動的に定義体が作成され、当該定義体をシステム構築基盤１１００へインポートすることでシステムの製造を行う。
【００２３】
次に、本発明の第一の実施形態の処理手順を、図２〜６を参照しながら説明する。
図２は、本発明の第一の実施形態の、定義体を新規作成する際の処理手順を示した図である。
【００２４】
定義体新規作成Ｓ２０００では、まず既存仕様書識別情報２０１１を外部より取得する（Ｓ２０１０）。ここで、既存仕様書識別情報２０１１は、複数の仕様書それぞれを一意に識別可能な情報であり、例えば仕様書のＩＤや仕様書のファイル名などを含む。
【００２５】
次に、Ｓ２０１０で取得した既存仕様書識別情報２０１１に基づき、仕様書読込部１０２０にて仕様書格納部に格納されている既存仕様書２０２１を取得する（Ｓ２０２０）。既存仕様書２０２１は、本手順を実施する前に、設計者が手動で作成した仕様書であり、定義体を作成するために必要な情報を含んでいる。
【００２６】
次に、既存仕様書２０２１の内容を入力とし、定義体作成部１０３２にて定義体を作成する（Ｓ２０３０）。本発明では、仕様書から定義体を自動的に作成する手段が定義体作成部１０３２として用意されていることを想定しており、Ｓ２０３０では当該手段を利用して定義体を作成する。なお、１つの定義体の作成するために必要な仕様書は、１つまたは複数とする。
なお、定義体の形式はシステム構築基盤１１００の入力フォーマットに依存するが、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、特定の仕様に従ったバイナリデータなどを採用することができる。
【００２７】
次に、Ｓ２０１０で取得した仕様書及びＳ２０３０で作成した定義体から、属性情報作成部１０１２にてそれらの属性情報を作成し（Ｓ２０４０）、属性情報出力部１０１３にて作成した属性情報を属性情報格納部１００３内の既存属性情報２０５１として出力する（Ｓ２０５０）。既存属性情報２０５１の構成は、図６を参照して説明する。既存属性情報２０５１は、既存仕様書識別情報２０１１、既存仕様書変更日時４０１２、既存仕様書誤り検出符号４０１３、既存定義体識別情報４０１１、既存定義体誤り検出符号４０１２を含んで構成される。既存属性情報２０５１の各構成要素の詳細な説明は、図２〜図５の処理手順の中で説明する。
【００２８】
次に、定義体出力部１０３３にてＳ２０３０で作成した定義体を既存定義体２０６１として出力する（Ｓ２０６０）。
次に、定義体インポート部１０３４にて既存定義体２０６１をシステム構築基盤１１００へインポートする。インポート処理は、システム構築基盤１１００に用意されている機能を活用して行うため、本発明ではその詳細まで言及しない。このインポート処理により、システム構築基盤上で定義体が利用可能となり、定義体の内容に従ってシステム内のデータ構造、データ変換仕様、処理仕様などが定義される。このインポート処理の後、定義体をシステム構築基盤内で書き換えて定義体格納部１００２へエクスポートすることが可能となる。
【００２９】
以上により、既存仕様書識別情報２０１１、既存仕様書２０２１を入力として、既存属性情報２０５１、既存定義体２０６１を出力する定義体新規作成Ｓ２０００が完了する。
本実施形態では、まず定義体新規作成Ｓ２０００の各定義体(例えば、全ての定義体)について行っておき、その後ユーザが一部の仕様書や定義体に手動で変更を加えた上で、Ｓ３０００定義体再作成を実施し、仕様書と定義体との不整合を解決する。
【００３０】
図３は、本発明の第一の実施形態の、定義体を再作成する処理手順を示した図である。
定義体再作成Ｓ３０００では、まず既存属性情報２０５１、更新仕様書３０１１、更新定義体３０１２を入力とし、更新ステータスを判定する（Ｓ３０１０）。更新ステータスは、仕様書及び定義体へどのような変更が加えられたかを、属性情報の比較により求める処理であり、図４を参照して後ほど説明する。
【００３１】
次に、更新ステータス出力部１０４３にて、Ｓ３０１０で判定された更新ステータス３０２１を出力する（Ｓ３０２０）。ここで、更新ステータス３０２１は、ユーザが目視で確認可能な形式で表現され、かつユーザが任意のステータスを書き換え可能な形で出力される。例えば、ソフトウェアのＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）上で各定義体を１行とする表形式で出力する、ＣＳＶ（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）や表計算ソフトのファイル形式で書き出す、などの手段を採ることが可能である。
【００３２】
次に、更新ステータス読込部１０４０にて、Ｓ３０２０で出力した形式と同じ形式(ないし実質的に同等の形式)で、編集済更新ステータス３０３１を読み込む（Ｓ３０３０）。なお本実施形態では、ユーザが更新ステータスを書き換えることを考慮に入れて、更新ステータス出力Ｓ３０２０と更新ステータス読込Ｓ３０３０を行っているが、更新ステータスをユーザが書き換える必要がない場合は、Ｓ３０２０とＳ３０３０を省略し、Ｓ３０１０で更新ステータスを判定後、直接定義体更新Ｓ３０４０を行っても良い。
【００３３】
次に、既存属性情報２０５１、更新仕様書３０１１、編集済更新ステータス３０３１を入力とし、定義体の更新を行い、新規定義体３０４１、定義体更新結果３０４２、新規属性情報３０４３を出力する（Ｓ３０４０）。定義体更新Ｓ３０４０の詳細は、図５を参照して後ほど説明する。
【００３４】
次に、定義体インポート部１０３４にて、Ｓ３０４０で作成された新規定義体を必要に応じてシステム構築基盤１１００へインポートする（Ｓ３０５０）。インポートの要否は定義体更新結果３０４２に依存し、「定義体更新」のときのみインポートを実施し、それ以外の場合は行わない。詳細な条件については、図５を参照して後ほど説明する。
【００３５】
このようにインポートを行う定義体を更新が行われたもののみに絞り込むことで、インポートと、インポートした定義体を対象に行われるテストの工数を削減することができる。
【００３６】
次に、Ｓ３０４０で出力された定義体更新結果３０４２をユーザへ提示する（Ｓ３０６０）。これにより、ユーザは定義体再作成Ｓ３０００でどのような処理が行われ、不整合が解決した定義体や不整合が解決しなかった定義体を把握することが可能となる。
【００３７】
なお、図３では一つの既存属性情報２０５１を入力して再作成を実施する処理手順を示したが、複数の既存属性情報２０５１を入力してそれぞれの属性情報に対応する定義体に対して、再作成を逐次実行しても良い。この場合、Ｓ３０１０〜Ｓ３０５０の処理手順が、指定した既存属性情報２０５１毎に繰返し実行される。
【００３８】
以降では、図４、図５を参照しながら、更新ステータス判定Ｓ３０１０、定義体更新Ｓ３０４０の詳細な処理手順について説明する。
図４は、本発明の第一の実施形態の、更新定義体３０１２、既存属性情報２０５１、更新仕様書３０１１を入力とし、更新ステータス３０２１を判定して出力する処理手順を示した図である。
【００３９】
まず、属性情報比較部１１０１にて、既存属性情報２０５１の中に含まれる既存定義体誤り検出符号４０１２と、更新定義体３０１２の誤り検出符号とを比較する（Ｓ４０１０）。具体的には、既存属性情報２０５１内の既存定義体識別情報４０１１を参照し、更新定義体３０１２を特定し、当該更新定義体３０１２から属性情報作成部１１０１にて誤り検出符号を算出し、既存定義体誤り検出符号４０１２と値を比較する。
【００４０】
既存定義体識別情報４０１１は、定義体を一意に識別可能な情報であり、例えば定義体に付与されたＩＤや定義体のファイル名などを含む。更新定義体３０１２は、Ｓ２０７０でインポートされた既存定義体２０６１に対して、システム構築基盤１１００上で変更が加えられた可能性がある定義体であり、既存定義体２０６１と内容が一致する場合もあるが、内容が異なる場合もある。
【００４１】
また、既存定義体誤り検出符号４０１２は、既存定義体２０６１から算出される符号であり、当該符号の比較により定義体の内容が一致するかしないかを判定することができる。既存定義体誤り検出符号４０１２には、チェックサム、ＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）、ハッシュ関数などあらゆる誤り検出符号を適用可能である。なお、例えば誤り検出時に誤りが発生している箇所を正確に特定したいなどのニーズがある場合には、誤り検出符号に替わり、既存定義体２０６１の原文を保持し、原文を比較することで誤りの検出を行っても良い。
【００４２】
なお、更新定義体３０１２の形式としては、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、特定の仕様に従ったバイナリデータなどを採用することができる。ここで、ＸＭＬなどのマークアップ言語を採用した場合は、全く同じ意味を持つファイルであっても、改行、空白、コメントの有無などにより一部の内容が異なる可能性がある。このように一部の内容が異なる定義体から算出される誤り検出符号は異なるため、全く同じ意味を持つ定義体同士であっても、誤り検出符号が不一致と判定される可能性がある。このような誤判定を防止するため、本発明では更新定義体３０１２を一度読み込み、決められた書式で整形する処理をＳ４０１０の誤り検出符号算出の前に行っても良い。このような処理を実施することで、同じ意味(例えば、全く同じ意味)を持つ定義体を不一致と判定する可能性を低減することができる。
【００４３】
Ｓ４０１０の比較にて、不一致と判定された場合には、更新ステータスに「定義体変更あり」を代入して更新ステータス判定Ｓ３０１０を終了する（Ｓ４０２０）。このステータスは、Ｓ２０７０で既存定義体２０６１がシステム連携基盤１１００にインポートされた後、システム連携基盤１１００内で定義体が書き換えられて更新定義体３０１２へエクスポートされたことを示す。このステータスと判定された場合には、更新定義体３０１２をマスターとみなし、更新仕様書３０１１から作成される定義体が更新定義体３０１２と等しくなるかを判定することで、仕様書と定義体が整合していることを検証する。
【００４４】
Ｓ４０１０の比較にて、一致と判定された場合には、次に属性情報比較部１１０１にて、既存仕様書変更日時４０３１と、更新仕様書３０１１の変更日時とを比較する（Ｓ４０３０）。具体的には、既存仕様書識別情報２０１１を参照して更新仕様書３０１１を特定し、当該更新仕様書３０１１から更新日時を取得し、取得した更新日時と既存仕様書変更日時４０３１を比較する。
【００４５】
既存仕様書変更日時４０３１は、Ｓ２０４０で算出された既存仕様書２０２１に記録されているファイルのタイムスタンプであり、Ｓ２０６０が実行された日時を示している。
【００４６】
更新仕様書３０１１は、既存仕様書２０２１から変更された可能性がある仕様書であり、仕様書格納部１００１に格納されている。仕様書の内容はユーザが手動で変更することが可能であるため、Ｓ２０００の実施以降にユーザが編集していれば、変更日時や誤り検出符号が変化し、編集していなければ変更日時や誤り検出符号に変化はない。
【００４７】
Ｓ４０３０の変更日時比較の結果は３通り考えられる。1つ目は更新仕様書３０１１の変更日時が既存仕様書変更日時４０３１よりも古い場合、２つ目は更新仕様書３０１１の変更日時が既存仕様書変更日時４０３１と等しい場合、３つ目は更新仕様書３０１１の変更日時が既存仕様書変更日時４０３１よりも新しい場合である。
【００４８】
Ｓ４０３０において更新仕様書３０１１の変更日時が既存仕様書変更日時４０３１よりも古かった場合は、更新ステータスに「古い仕様書」を代入し、更新ステータス判定Ｓ３０１０を終了する（Ｓ４０４０）。この場合、更新仕様書３０１１の更新日時が前回の定義体作成時よりも古かったということなので、仕様書が古いバージョンに置き換わる事故が発生した可能性がある。よって、仕様書が古い旨をユーザへ提示し、仕様書の確認を促す。
【００４９】
Ｓ４０３０において、更新仕様書３０１１の変更日時が既存仕様書変更日時４０３１と等しかった場合は、更新ステータスに「仕様書日時変更なし」を代入し、更新ステータス判定Ｓ３０１０を終了する（Ｓ４０５０）。更新日時が一致したということは、前回の定義体作成時から仕様書に変更が加えられていないことを示しているため、仕様書と定義体は既に整合しており、不整合を解決する処理は不要となる。
【００５０】
Ｓ４０３０において、更新仕様書３０１１の変更日時が既存仕様書変更日時４０３１よりも新しかった場合は、更新仕様書３０１１が前回定義体作成時から変更された可能性があることを示している。よって、さらに属性情報作成部１０１２にて更新仕様書３０１１から誤り検出符号を算出し（Ｓ４０６０）、属性情報比較部１１０１にて既存仕様書誤り検出符号４０８１と比較を行う（Ｓ４０７０）。
【００５１】
更新仕様書３０１１から算出された更新仕様書誤り検出符号４０６１、及び既存仕様書誤り検出符号４０７１は、既存定義体誤り検出符号と同じ形式であり、チェックサム、ＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）、ハッシュ関数などあらゆる公知の誤り検出符号を適用可能である。なお、例えば誤り検出時に誤りが発生している箇所を正確に特定したいなどのニーズがある場合には、誤り検出符号に替わり、既存仕様書２０２１の原文を保持し、原文を比較することで誤りの検出を行っても良い。
【００５２】
Ｓ４０７０の比較の結果、誤り検出符合が一致した場合には、更新ステータスに「仕様書内容変更なし」を代入し、更新ステータス判定Ｓ３０１０の処理を終了する（Ｓ４０８０）。
Ｓ４０７０の比較の結果、誤り検出符合が不一致の場合には、更新ステータスに「仕様書内容変更あり」を代入し、更新ステータス判定Ｓ３０１０の処理を終了する（Ｓ４０９０）。
【００５３】
図５は、本発明の第一の実施形態の、定義体更新Ｓ３０４０の処理手順を示した図である。本発明では、更新ステータス判定Ｓ３０１０で得られた更新ステータスまたは更新ステータス読込Ｓ３０３０で得られた更新ステータスに基づき、仕様書及び定義体に対して適切な処理を行うことで仕様書と定義体との不整合を解決する。
【００５４】
まず、編集済更新ステータス３０３１に基づき、定義体再作成の要否判定を行う（Ｓ５０１０）。この要否判定では、編集済更新ステータス３０３１において、「定義体変更あり」（Ｓ４０２０）または「仕様書内容変更あり」（Ｓ４０９０）と判定された定義体に対しては「再作成要」と判定し、それ以外の「古い仕様書」（Ｓ４０４０）、「仕様書日時変更なし」（Ｓ４０５０）、「仕様書内容変更なし」（Ｓ４０８０）に対しては、「再作成不要」と判定する。
【００５５】
Ｓ５０１０で「再作成不要」と判定された場合は、Ｓ３０４０の処理を終了する。
Ｓ５０１０で「再作成要」と判定された場合は、既存仕様書識別情報２０１１に基づき更新仕様書３０１１を取得し（Ｓ５０２０）、更新仕様書３０１１から定義体を作成する（Ｓ２０３０）。
【００５６】
Ｓ２０３０は、図２を参照して説明した定義体作成Ｓ２０３０と同様に、別途用意されている作成手段を用いて定義体を作成する。
次に、Ｓ２０３０で作成した定義体から新規定義体誤り検出符号５０４１を算出し、更新定義体３０１２から更新定義体誤り検出符号５０４２を算出する（Ｓ５０４０）。新規定義体誤り検出符号５０４１及び更新定義体誤り検出符号５０４２は、既存定義体誤り検出符号４０１２と同じ形式であり、チェックサム、ＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）、ハッシュ関数などあらゆる公知の誤り検出符号を適用可能である。また、既存定義体誤り検出符号４０１２に替わり定義体の原文が用いられている場合には、新規定義体誤り検出符号５０４１及び更新定義体誤り検出符号５０４２にも定義体の原文を用いる。
【００５７】
次に、新規定義体誤り検出符号５０４１と更新定義体誤り検出符号５０４２とを比較する（Ｓ５０５０）。
以降の処理は、Ｓ５０５０の比較結果に基づき分岐する。Ｓ５０５０の比較結果が一致である場合は、Ｓ５０６０、Ｓ５０７０、Ｓ５０８０、Ｓ５１２０、Ｓ５１３０の処理を行い、定義体更新Ｓ３０４０を終了する。また、Ｓ５０５０の比較結果が不一致である場合には、Ｓ５０８０、Ｓ５０９０、Ｓ５１００、Ｓ５１１０、Ｓ５１２０、Ｓ５１３０、Ｓ５１４０の処理を行い、定義体更新Ｓ３０４０を終了する。以降で、各処理手順を説明する。
【００５８】
Ｓ５０５０の比較結果が一致である場合、編集済更新ステータス３０３１の内容に基づき分岐を行う（Ｓ５０６０）。編集済更新ステータス３０３１の内容が「仕様書内容変更あり」である場合には定義体更新結果に「定義体更新不要」を代入して（Ｓ５０７０）、更新仕様書３０１１に基づき、属性情報を作成し（Ｓ５１２０）、新規属性情報３０４３として出力した後（Ｓ５１３０）、定義体更新Ｓ３０４０を終了する。また、編集済更新ステータス３０３１の内容が「定義体変更あり」である場合には定義体更新結果に「仕様書&定義体整合」を代入し（Ｓ５０８０）、更新仕様書３０１１に基づき、属性情報を作成し（Ｓ５１２０）、新規属性情報３０４３として出力した後（Ｓ５１３０）、定義体更新Ｓ３０４０を終了する。
【００５９】
定義体更新結果が「定義体更新不要」である場合は、更新仕様書３０１１の内容が既存仕様書２０２１の内容と異なるものであったが、仕様書から作成される新規定義体の内容は同じであったことを意味する。このような場合は、定義体に影響が出ない範囲で仕様書が書き換えられているため、仕様書と定義体は整合しているとみなす。
【００６０】
定義体更新結果が「仕様書&定義体整合」である場合は、更新仕様書３０１１と更新定義体３０１２とが両方とも変更されたが、更新仕様書３０１１と更新定義体３０１２との整合性は保たれていることを意味している。このような場合は、システム構築基盤１１００内で変更されてエクスポートされた更新定義体３０１２の変更内容に合わせて、更新仕様書３０１１が正しく変更されているため、仕様書と定義体は整合しているとみなす。
一方、Ｓ５０５０の比較結果が不一致である場合、Ｓ５０６０と同様に編集済更新ステータス３０３１の内容に基づき分岐を行う（Ｓ５０９０）。
【００６１】
編集済更新ステータス３０３１の内容が「仕様書内容変更あり」である場合には、定義体更新結果に「定義体更新」を代入して（Ｓ５１００）、Ｓ２０３０で作成した定義体を新規定義体３０４１として出力する（Ｓ５１１０）。さらに、更新仕様書３０１１及び新規定義体３０４１に基づき、属性情報を作成する（Ｓ５１２０）。属性情報に含まれるデータは、図６の既存属性情報２０５１に示されている５つである。ただし、Ｓ５１２０では、既存仕様書識別情報２０１１、既存仕様書変更日時４０３１、既存仕様書誤り検出符号４０７１は、更新仕様書３０１１から作成し、既存定義体識別情報４０１１、既存定義体誤り検出符号４０１２は、新規定義体３０４１から作成する。
【００６２】
さらに、Ｓ５１２０で得られた属性情報を、新規属性情報３０４３として出力し（Ｓ５１３０）、定義体更新Ｓ３０４０を終了する。
一方、編集済更新ステータス３０３１の内容が「定義体変更あり」である場合には、定義体更新結果に「仕様書不整合あり」を代入して（Ｓ５１４０）、定義体更新Ｓ３０４０を終了する。
【００６３】
定義体更新結果が「仕様書不整合あり」となる場合は、システム構築基盤１１００上で定義体が変更されて更新定義体３０１２にエクスポートされたが、更新仕様書３０１１から作成した定義体と更新定義体３０１２の内容が一致しないことを示している。更新定義体３０１２が変更された場合は更新定義体３０１２をマスターとみなし、それに合わせて仕様書が修正されていると仮定するため、仕様書と定義体の間に不整合が発生した場合、更新仕様書３０１１の変更が不十分であると判定する。
【００６４】
Ｓ３０４０では、編集済更新ステータス３０３１の内容に基づき定義体再作成の要否を判定し、再作成要と判定されたときのみ定義体を作成する。さらに、新たに作成された定義体の属性情報に基づき定義体更新結果を判定する。このとき、定義体更新結果が「定義体更新」と判定された定義体に関しては、Ｓ３０５０にて、新規定義体５１１１をシステム構築基盤１１００へインポートする処理を行う。定義体更新結果が「定義体更新」以外の場合は、システム構築基盤１１００へのインポートは行わない。
【００６５】
以上により、第一の実施形態に基づく仕様書と定義体の更新ステータスの判定、及び仕様書と定義体の不整合の自動的な解決が実現される。
【００６６】
＜第二の実施形態＞
第二の実施形態では、第一の実施形態の更新ステータス判定Ｓ３０１０において、仕様書の属性情報の比較処理（Ｓ４０３０〜Ｓ４０８０）を省略する。例えば、システム開発中に定義体作成Ｓ２０３０で使用される定義体作成手段に変更が発生した場合、同一の仕様書を入力として定義体を作成した場合でも、定義体作成手段変更前と変更後で、作成される定義体の内容が一致しない可能性がある。このような場合は、仕様書の内容が同一であっても定義体の作成を行う必要があるため、仕様書の属性情報の比較処理が不要となる。
【００６７】
以下、本発明の第二の実施形態の処理手順を、図７を参照して説明する。
図７は、本発明の第二の実施形態の、更新ステータス判定Ｓ３０１０の処理手順を示した図である。本実施形態では、図３に示す定義体再作成Ｓ３０００、図５に示す定義体更新Ｓ３０４０の処理は第一の実施形態と同様であり、図４に示す更新ステータス判定Ｓ３０１０の処理手順を、図７に示す処理手順へ置き換える。これにより、仕様書の属性情報の比較を省略する。
【００６８】
なお、第一の実施形態と第二の実施形態どちらを用いるかは、例えば定義体作成Ｓ２０３０に用いられる定義体作成手段のバージョンを参照することで判定することができる。具体的には、属性情報作成Ｓ５１２０で新規属性情報３０４３を作成する際に、図６で示した５つの情報に加えて、定義体作成手段のバージョンを示す値を付与し、更新ステータス判定Ｓ３０１０の前に、現在使用している定義体作成手段のバージョンと比較する。
【００６９】
ここでバージョンが一致する場合には、本発明における第一の実施形態の更新ステータス判定Ｓ３０１０を用い、バージョンが不一致の場合には、本発明の第二の実施形態の更新ステータス判定Ｓ３０１０を用いる。このようにすることで、定義体作成手段の変更を検知し、自動的に適切な判定を選択することが可能となる。
【００７０】
まず、既存定義体誤り検出符号４０１２と更新定義体３０１２の誤り検出符号とを比較する（Ｓ７０１０）。この処理はＳ４０１０と同様である。
【００７１】
次に、Ｓ７０１０の比較結果が不一致の場合は、更新ステータスに「定義体変更あり」を代入し、Ｓ３０１０の処理を終了する（Ｓ７０２０）。この処理も、図４のＳ４０２０と同様である。
【００７２】
次に、Ｓ７０１０の比較結果が一致の場合は、更新ステータスに「仕様書内容変更あり」を代入し、Ｓ３０１０の処理を終了する（Ｓ７０３０）。この処理は、図４のＳ４０９０と同様であり、Ｓ４０３０〜Ｓ４０８０は省略されている。
以上の処理を更新ステータスＳ３０１０として実行することで、仕様書の属性情報を考慮しない更新ステータス判定が実現する。
【００７３】
図８は、第一の実施形態、及び第二の実施形態のシステムにおける開発支援システム１０００、システム構築基盤１１００のハードウェア構成を示すブロック図である。
この図において、符号８００１はＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、符号８００２はメモリ、符号８００３はＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、符号８００４は入力装置、符号８００５は出力装置、符号８００６は通信装置である。
【００７４】
ＣＰＵ８００１は、属性情報読込部１０１０、属性情報比較部１１０１、属性情報作成部１０１２、属性情報出力部１０１３、仕様書読込部１０２０、定義体読込部１０３０、定義体作成部１０３２、定義体出力部１０３３、定義体インポート部１０３４、更新ステータス読込部１０４０、更新ステータス出力部１０４３、に対応するプログラムを実行する。
【００７５】
メモリ８００２は、属性情報読込部１０１０、属性情報比較部１１０１、属性情報作成部１０１２、属性情報出力部１０１３、仕様書読込部１０２０、定義体読込部１０３０、定義体作成部１０３２、定義体出力部１０３３、定義体インポート部１０３４、更新ステータス読込部１０４０、更新ステータス出力部１０４３、に対応するプログラムを格納する。これらのプログラムをＣＰＵ８００１が実行することで、各々の処理が実現する。
【００７６】
ＨＤＤ８００３は、仕様書格納部１００１、定義体格納部１００２、属性情報格納部１００３、に相当する。各部が格納するデータは、ＨＤＤ８００３上のデータとして蓄積される。
【００７７】
入力装置８００４は、属性情報読込部１０１０、仕様書読込部１０２０、定義体読込部１０３０、更新ステータス読込部１０４０において情報を読み込むために使用される。
【００７８】
出力装置８００５は、属性情報出力部１０１３、定義体出力部１０３３、更新ステータス１０４３において、情報を書き出すために使用される。
【００７９】
以上、本発明の実施形態によれば、システム開発で仕様書から定義体を自動作成する開発手順において、一部の仕様書または定義体に変更があり仕様書と定義体の間に不整合が発生した場合に、仕様書および定義体の属性情報を前回定義体作成時のものと比較することにより、変更が発生した箇所を特定し、変更箇所に応じて定義体の再作成などの対応を行うことにより仕様書と定義体の不整合を自動的に解決することで、システムの開発効率を向上させることを可能となる。
【符号の説明】
【００８０】
１００１…仕様書格納部、定義体格納部…１００２、属性情報格納部…１００３
【図１】
0006482998.tif 000002
【図２】
0006482998.tif 000003
【図３】
0006482998.tif 000004
【図４】
0006482998.tif 000005
【図５】
0006482998.tif 000006
【図６】
0006482998.tif 000007
【図７】
0006482998.tif 000008
【図８】
0006482998.tif 000009