JP6722528B2

JP6722528B2 - ソフトウェア開発支援方法及びシステム

Info

Publication number: JP6722528B2
Application number: JP2016131093A
Authority: JP
Inventors: 真澄川上; 誠市井; 文雄小田
Original assignee: Clarion Co Ltd
Current assignee: Faurecia Clarion Electronics Co Ltd
Priority date: 2016-06-30
Filing date: 2016-06-30
Publication date: 2020-07-15
Anticipated expiration: 2036-06-30
Also published as: CN107562419B; CN107562419A; JP2018005535A

Description

本発明は、ソフトウェアを開発する際の作業を支援するためのソフトウェア開発支援方法及びシステムに関する。

大規模なソフトウェアを開発するとき、母体となるソースコードを分析し、新しい機能を追加する場合が多い。このとき母体ソースコードの理解が不十分なままソースコードの追加および変更を行うと、修正すべき箇所の見逃しや、並行して実施されている他開発者との変更と衝突し、不具合を発生させることがある。この課題を解決するため、母体ソースコードの分析を行う手法が提案されている（特許文献１参照）。特許文献１では、母体ソースコード内の関数および変数間の依存関係を検索することで、母体ソースコードの分析を支援する方法が提案されている。

特開平５−２８９８６２号公報

特許文献１の方法は、ソースコードを変更する際に、変更影響のチェック漏れを無くすには十分ではなく、しかも、単一の開発者を想定しており、複数開発者による作業の衝突は考慮されていない。

本発明の目的は、ソースコードを変更する際に、変更影響のチェック漏れを無くすことを支援することにある。

上記課題を解決するため、本発明は、関数又は変数のうち少なくとも一方で構成される複数の要素を含むソースコードを格納する記憶装置と、情報の入出力を行う入出力装置と、前記記憶装置及び前記入出力装置を管理するコントローラを含むシステムにおけるソフトウェア開発支援方法であって、前記コントローラが、前記ソースコードに含まれる要素の変更を指示する第一の変更要求を前記入出力装置から受付けたとき、当該受付けた第一の変更要求の影響を受ける他の要素が変更されているかどうかを示す第一の変更管理情報と前記第一の変更要求の影響を受ける他の要素の変更予定の有無を示す第一の変更予定情報を前記記憶装置に格納する第１のステップと、前記入出力装置が、前記第一の変更要求で変更を指示された要素、前記第一の変更要求の影響を受ける他の要素、前記第一の変更管理情報及び、前記第一の変更予定情報を出力する第２のステップと、を有することを特徴とする。

本発明によれば、ソースコードを変更する際に、変更影響のチェック漏れを無くすことができる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明の実施例１を示すシステムの全体構成図である。テーブルとデータベースの構成図であって、（ａ）は、要素依存関係の例を示すテーブルの構成図、（ｂ）は、ソースコードデータベースに保存されるテーブルの構成図、（ｃ）は、構成管理データベースの構成図、（ｄ）は、チェックフラグデータベースに保存されるテーブルの構成図である。ソース構成管理部の処理を説明するためのフローチャートである。ソース依存関係解析部の処理を説明するためのフローチャートである。ソースメトリクス解析部の処理を説明するためのフローチャートである。母体ソースコードに機能を追加する典型的な開発フローを示すフローチャートである。ユーザインタフェース表示部で管理されるシンボルの凡例を示す構成図である。関数に対して変更必要のフラグを立てたときの状態を説明するための図であって、（ａ）は、ディスプレイの表示例を示す構成図、（ｂ）は、変更フラグテーブルの構成図である。フラグ管理部の処理を説明するためのフローチャートである。設計が終了した時点のフラグの状態を説明するための図であって、（ａ）は、ディスプレイの表示例を示す構成図、（ｂ）は、変更フラグテーブルの構成図である。設計を行った後、ソースコードの変更を実施した状態を説明するための図であって、（ａ）は、実施例２におけるディスプレイの表示例を示す構成図、（ｂ）は、実施例２における変更フラグテーブルの構成図である。実施例３における処理であって、チェックフラグデータベースを参照しない場合の処理を説明するためのフローチャートである。実施例３における処理であって、チェックフラグデータベースのデータを活用した場合の処理を説明するためのフローチャートである。実施例３におけるシステムであって、複数の開発者を対象としたシステムの構成図である。複数の開発者の変更によって衝突が起こった状態を説明するための図であって、（ａ）は、実施例３におけるディスプレイの表示例を示す構成図、（ｂ）は、実施例３における変更フラグテーブルの構成図である。

以下、実施例について図面を用いて説明する。なお、図面において、同一符号は、同一または相当部分を示す。また、本発明は、図示例に限定されるものではない。

本実施例は、母体ソースコードに機能を追加する典型的な開発フローのうち、設計工程の作業について説明する。

図１は、本発明の実施例１を示すシステムの全体構成図である。図１において、システム（ソフトウェア開発支援システム）は、開発マシン１０と、管理サーバ１２を備え、開発マシン１０が管理サーバ１２に接続される。開発マシン１０は、ディスプレイ１０２と、周辺機器１０３と、中央処理演算装置１０４と、記憶装置１０５から構成される。ディスプレイ１０２は、情報を表示する表示装置あるいは情報を出力する出力装置として構成され、周辺機器１０３は、キーボード等を有し、情報を入力する入力装置として構成される。この際、ディスプレイ１０２と周辺機器１０３を、情報を入出力する入出力装置として構成することができる。中央処理演算装置１０４は、例えば、ＣＰＵ（Central Processing Unit）、メモリ、入出力インタフェース等の情報処理資源を備えたコンピュータ装置として構成され、ＣＰＵによって実行されるソフトウェア１４を備え、記憶装置１０５は、情報記憶部１６を備えている。ソフトウェア１４は、ユーザインタフェース表示部１０８と、ソース構成管理部１０９と、ソース依存関係解析部１１０と、ソースメトリクス解析部１１１と、フラグ管理部１１２から構成される。情報記憶部１６は、変更中ソースコード１１３と、ソースコードデータベース１１４から構成される。この際、中央処理演算装置１０４は、記憶装置１０５を管理すると共に、入出力装置と情報の送受信を行うコントローラとして機能する。

１又は複数の開発マシン１０から利用される管理サーバ１２は、中央処理演算装置１０６と、記憶装置１０７から構成され、開発マシン１０と情報の送受信を行って記憶装置１０７を管理する。記憶装置１０７は、情報記憶部１８を備えている。中央処理演算装置１０６は、例えば、ＣＰＵ、メモリ、入出力インタフェース等の情報処理資源を備えたコンピュータ装置として構成される。情報記憶部１８は、構成管理データベース１１５と、チェックフラグデータベース１１６から構成される。この際、開発者１０１は、ディスプレイ１０２と周辺機器１０３を通じて開発マシン１０を利用する。

ユーザインタフェース表示部１０８は、ソース構成管理部１０９と、ソース依存関係解析部１１０と、ソースメトリクス解析部１１１と、フラグ管理部１１２のうちいずれかの処理内容や処理結果などをディスプレイ１０２に表示するためのソフトウェア（プログラム）である。ソース構成管理部１０９は、ソースコードのバージョン管理をするためのソフトウェアであって、変更中ソースコード１１３と構成管理データベース１１５に接続され、複数のユーザ（開発者）がいつどのソースコードを変更したかを管理している。ソース依存関係解析部１１０は、ソースコードに含まれる関数および変数間の参照関係を解析するためのソフトウェアであり、変更中ソースコード１１３とソースコードデータベース１１４に接続される。基本的にソースコードの静的解析技術に基づいて処理されるが、ロジカルカップリングなどのアルゴリズムに基づいて処理される実現形態もある。ソースメトリクス解析部１１１は、ソースコードに属する各関数および変数に関係するメトリクス（数値情報）を計測するソフトウェアであり、変更中ソースコード１１３とソースコードデータベース１１４に接続される。なお、後に説明する実施例では他依存数のみを表示しているが、複雑度や変更頻度等のメトリクスを扱う実現形態もある。フラグ管理部１１２は、チェックフラグデータベース１１６に接続され、チェックフラグデータベース１１６に記録されたチェックフラグデータを管理するためのソフトウェアである。構成管理データベース１１５は、ソース構成管理部１０９と連携してソースコードの構成管理を行う。チェックフラグデータベース１１６は、フラグ管理部１１２と連携してチェックフラグデータを保存する。

図２は、テーブルとデータベースの構成図であって、（ａ）は、要素依存関係の例を示すテーブルの構成図、（ｂ）は、ソースコードデータベースに保存されるテーブルの構成図、（ｃ）は、構成管理データベースの構成図、（ｄ）は、チェックフラグデータベースに保存されるテーブルの構成図である。

図２（ａ）において、要素依存関係の例を示すテーブル２０１は、記憶装置１０５に保存されるテーブルであって、本ツールが対象とするソースコード中の関数および変数の依存関係を表わしたグラフに関する情報として、「関数：func1」、「関数：func2」、「変数：value1」、「関数：func3」から構成される。ここで、本実施例では、ソースコード中に存在する関数および変数を要素と呼ぶ。テーブル２０１では、「関数：func2」が「変数：value1」と「関数：func3」を参照し、「関数：func2」は「関数：func1」から参照されている依存関係であることを示している。依存関係は、矢印２０２で示している。

図２（ｂ）において、ソースコードデータベース１１４には、要素テーブル２０３と、変更影響テーブル２０４が保存される。要素テーブル２０３は、要素ＩＤ２０５と、ファイル２０６と、関数/変数２０７と、他依存数２０８から構成される。要素ＩＤ２０５には、要素を一意に識別するための識別子が格納される。ファイル２０６には、ファイルを特定するファイル名などの情報が格納される。関数/変数２０７には、関数又は変数を特定する情報（関数名、変数名）が格納される。他依存数２０８には、関数/変数２０７に記録された関数又は変数の他に、要素と依存関係を有するものが存在する数を示す情報（数値情報）が格納される。

変更影響テーブル２０４は、変更元要素ＩＤ２０９と、変更影響要素ＩＤ２１０と、変更影響タイプ２１１から構成される。変更元要素ＩＤ２０９と変更影響要素ＩＤ２１０は、要素ＩＤ２０５で定義されたＩＤに対応するＩＤであって、変更元要素ＩＤ２０９には、要素の変更元を示す変更元要素を識別するための識別子が格納される。例えば、要素ＩＤ２０５のうち「要素２」が変更される場合（変更予定の場合）、変更元要素ＩＤ２０９には、「２」が格納される。変更影響要素ＩＤ２１０には、変更元要素の変更に伴って影響を受ける要素を識別するための識別子が格納される。例えば、要素ＩＤ２０５のうち「要素２」の変更の影響を受ける要素が「１」、「３」、「４」である場合、変更影響要素ＩＤ２１０には、「１」、「３」、「４」が格納される。変更影響要素ＩＤ２１０には、変更影響要素ＩＤ２１０に格納された要素が変更元要素によって呼び出されるタイプである場合、「呼出」の情報が格納され、変更影響要素ＩＤ２１０に格納された要素が変更元要素を呼び出すタイプである場合、「被呼出」の情報が格納される。

図２（ｃ）において、構成管理データベース１１５には、ソースコード２１２が保存される。ソースコード２１２は、複数のバージョン２１３によって管理されている。各バージョン２１３には、更新日時が保存されており、最新バージョン２１３のソースコード２１２を取出すことができる。

図２（ｄ）において、チェックフラグデータベース１１６には、変更フラグテーブル２１４が保存される。変更フラグテーブル２１４は、ファイル２１５と、関数/変数２１６と、ソース構成管理状態２１７と、変更予定状態２１８と、変更衝突状態２１９と、更新者２２０と、更新日時２２１から構成される。ファイル２１５には、ファイル２０６と同様の情報であって、ファイルを特定するファイル名などの情報が格納される。関数/変数２１６には、関数/変数２０７と同様の情報であって、関数又は変数を特定する情報（関数名、変数名）が格納される。ソース構成管理状態２１７には、ソース構成管理が未変更の場合、「未変更」の情報が格納され、ソース構成管理が変更済である場合、「変更済」の情報が格納される。変更予定状態２１８には、変更予定（要素の変更予定）が未確認の場合には、「未確認」の情報が格納され、変更予定が変更不要である場合、「変更不要」の情報が格納され、変更予定が必要である場合、「変更必要」の情報が格納される。変更衝突状態２１９には、衝突の有無を示す情報（要素間で衝突（重複）が生じたか否かを示す情報）が格納される。更新者２２０には、ソースコードを変更した更新者の名称を示す情報が格納される。更新日時２２１には、ソースコードが変更された更新日時を示す情報が格納される。なお、図２（ｄ）では、変更フラグテーブル２１４には、テーブル２０１の初期状態の情報が格納されている。

図３は、ソース構成管理部の処理を説明するためのフローチャートである。図３において、開発者１０１がソースコードの変更を行う場合には、構成管理データベース１１５上のソースコードではなく、記憶装置１０５上のローカルソースコードを変更する。この変更が完了した段階で、開発者１０１がソースコードの登録を指示すると、ソース構成管理部１０９による処理が開始される（ステップ３０１）。まず、ソース構成管理部１０９は、変更中ソースコード（変更中のソースコード）１１３と、構成管理データベース１１５中の最新のバージョン２１３のソースコード２１２とを比較し（ステップ３０２）、差分があるか否かを判定し（ステップ３０３）、差分がない場合、このルーチンでの処理を終了し、差分がある場合、構成管理データベース１１５に、変更中ソースコードを最新バージョンとして登録し（ステップ３０４）、このルーチンでの処理を終了する。この処理は一般的なソースコード構成管理ツールが持つ処理である。

図４は、ソース依存関係解析部の処理を説明するためのフローチャートである。図４において、ソース依存関係解析部１１０は、後に説明する一覧画面（変更影響チェック画面）８０１を呼出したタイミング、もしくは、変更中ソースコード１１３が変更されたタイミング、もしくは、定期的なスケジュールで、ソース（ソースコード）の依存関係解析を開始する（ステップ４０１）。ソース依存関係解析部１１０は、ステップ４０１で処理が開始されると、変更中ソースコード１１３の持つすべての要素でループを行い（ステップ４０２）、変更中ソースコード１１３の各要素の依存関係を計測し（ステップ４０３）、計測結果を、ソースコードデータベース１１４の変更影響テーブル２０４に依存関係を示す情報として保存する（ステップ４０４）。ソース依存関係解析部１１０は、この処理をすべての要素に対して行い、このルーチンでの処理を終了する（ステップ４０５）。この処理は一般的なソース依存関係解析ツールが持つ処理である。

図５は、ソースメトリクス解析部の処理を説明するためのフローチャートである。図５において、ソースメトリクス解析部１１１は、後に説明する一覧画面（変更影響チェック画面）８０１を呼出したタイミング、もしくは、変更中ソースコード１１３が変更されたタイミング、もしくは、定期的なスケジュールで、ソース（ソースコード）のメトリクス解析を開始する（ステップ５０１）。ソースメトリクス解析部１１１は、ステップ５０１で処理が開始されると、変更中ソースコード１１３の持つすべての要素でループを行い（ステップ５０２）、変更中ソースコード１１３の各要素のメトリクスを計測し（ステップ５０３）、計測結果を、ソースコードデータベース１１４の要素テーブル２０３に、各要素のメトリクスを示す情報として保存する（ステップ５０４）。ソースメトリクス解析部１１１は、この処理をすべての要素に対して行い、このルーチンでの処理を終了する（ステップ５０５）。この処理は一般的なソースメトリクス解析ツールが持つ処理である。

図６は、母体ソースコードに機能を追加する典型的な開発フローを示すフローチャートである。図６において、開発プロセスの始点６０１から、開発者１０１が処理を開始し、母体コード（ソースコード）を読込むための操作を実行すると、ユーザインタフェース表示部１０８が、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込み、読込んだ母体コード（ソースコード）をディスプレイ１０２上に表示する。この際、開発者１０１は、ディスプレイ１０２上に表示された母体コード（ソースコード）に対して、周辺機器１０３のキーボード等を操作して、機能の追加を設計する（ステップ６０２）。例えば、「func2」を変更するための設計を行う。この際、フラグ管理部１１２は、ステップ６０２にて、例えば、「func2」を変更する際の変更影響チェックを行い、チェック結果（「func2」の変更の影響を受ける関数又は変数等の情報）をチェックフラグデータベース１１６に登録する。

次に、開発者１０１は、周辺機器１０３のキーボード等を操作して、ステップ６０３にて追加された機能をソースコード上に実装する（ステップ６０３）。この後、開発者１０１が、母体コード（ソースコード）とチェックフラグを読込むための操作を実行すると、ユーザインタフェース表示部１０８が、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込み、フラグ管理部１１２を介してチェックフラグデータベース１１６からチェックフラグを読込み、読込んだ母体コード（ソースコード）とチェックフラグをディスプレイ１０２上に表示する。この際、開発者１０１は、ディスプレイ１０２上に表示された母体コード（ソースコード）とチェックフラグを参照して、機能の実装完了チェックを行う（ステップ６０４）。例えば、開発者１０１は、表示された母体ソースコードとチェックフラグとを比較し、変更影響チェックを行う。この際、開発者１０１は、チェック結果に問題が発生していれば、さらにソースコードの修正を行う。チェック結果が良好であれば、変更後コード（ソースコード）を構成管理データベース１１５に登録するための操作を実行する。これにより、開発プロセスは終点６０５で終了する。

図７は、ユーザインタフェース表示部で管理されるシンボルの凡例を示す構成図である。図７において、ユーザインタフェース表示部１０８は、フラグ管理部１１２を介して、チェックフラグデータベース１１６の変更フラグテーブル２１４のうちソース構成管理状態２１７の情報をソース構成管理状態７０１の情報として、変更予定状態２１８の情報を変更予定状態７０２の情報として、変更衝突状態２１９の情報を変更衝突状態７０３の情報として管理すると共に、各情報をシンボルに対応づけて管理し、管理された情報とシンボルをディスプレイ１０２の画面上に表示する。ソース構成管理状態７０１の情報とシンボルは、未変更（レ点）と変更済（！）から構成される。変更予定状態７０２の情報とシンボルは、未確認（？）、変更不要（Ｎ）、変更必要（Ｃ）から構成される。変更衝突状態７０３の情報とシンボルは、変更衝突状態（×）から構成される。各々のカテゴリ内では同時に表示されるものは一つのシンボルに限られるが、ソース構成管理状態７０１、変更予定状態７０２、変更衝突状態７０３に関する情報やシンボルは、一つの要素に対して同時に表示される可能性がある。

図８は、関数に対して変更必要のフラグを立てたときの状態を説明するための図であって、（ａ）は、ディスプレイの表示例を示す構成図、（ｂ）は、変更フラグテーブルの構成図である。図８において、開発者１０１が、周辺機器１０３を操作して、ディスプレイ１０２の画面上に一覧画面８０１を表示させ、ユーザインタフェース表示部１０８を通じて「func2」に対して変更必要（変更予定）のフラグ（Ｃ）を立てることを指示すると、ソース依存関係解析部１１０は、指示された情報を基にソースコードデータベース１１４を参照して、「func2」と呼出または被呼出の関係にある関数又は変数として、例えば、「value1」、「func3」、「func1」に未確認フラグ（？）を立てるための処理を実行する。この処理結果がユーザインタフェース表示部１０８を介してディスプレイ１０２に転送されると、ディスプレイ１０２の一覧画面８０１には、ソース依存関係解析部１１０の参照結果が表示される。この際、開発者１０１は、表示された一覧画面８０１の内容を参照することができる。

一覧画面８０１には、変更元（要素の変更元）８０２に関する情報として、「func2」のファイル（FileA.c）および関数/変数「func2」が表示され、変更影響８０３として、「func2」の変更の影響を受けるファイルおよび関数/変数であって、要素テーブル２０３と変更影響テーブル２０４に登録されたファイル名（FileA.h、FileB.c、FileC.c）および関数/変数の名称（value1、func3、func1）が表示され、変更影響タイプ８０４として、変更影響テーブル２０４に登録された「呼出」または「被呼出」が表示され、メトリクス８０５として、要素テーブル２０３の他依存数２０８に登録された情報（他依存数：１５など）が表示される。この際、変更元８０２の関数/変数「func2」には、未変更を示すシンボルレ点と、変更必要（変更予定）を示すシンボル（Ｃ）がフラグ（チェックフラグ）として表示される。また、変更影響８０３の関数/変数（value1、func3、func1）には、未変更を示すシンボルレ点と、未確認を示すシンボル（？）がフラグ（チェックフラグ）として表示される。

開発者１０１は、この一覧画面８０１を参照し、自分が設計したい機能に必要な母体コード（ソースコード）の変更範囲を検討する。変更範囲の検討にあたっては、変更影響タイプ８０４とメトリクス８０５を参照して、変更影響のインパクトを参考にすることができる。ここで示した変更影響タイプ８０４とメトリクス８０５は一部の例であり、変更影響の分析に役立つ様々な項目を追加した実現形態がある。

また、変更フラグテーブル２１４のファイル２１５には、ファイル名（FileA.h、FileA.c、FileB.c、FileC.c）が登録され、関数/変数２１６には、関数又は変数の名称（value1、func2、func3、func1）が登録され、ソース構成管理状態２１７には、各ファイルが未変更であることを示すために、「未変更」の情報が登録され、変更予定状態２１８には、「func2」の欄のみ、変更必要（変更予定）であることを示すために、「変更必要」の情報が登録され、他の欄には、変更必要であるか否かは未確認であることを示すために、「未確認」の情報が登録され、更新者２２０には、開発者１０１の名称が登録され、更新日時２２１には、開発者１０１による更新日時の情報が登録される。なお、変更フラグテーブル２１４には、ファイル２１５に対応して、要素ＩＤの情報を登録することもできる。

図９は、フラグ管理部の処理を説明するためのフローチャートである。この処理は、開発者１０１が未確認フラグ（？）を立てるための操作を実行することによって開始される（ステップ９０１）。フラグ管理部１１２は、処理が開始されると、未確認フラグ（？）を立てるための操作による情報を基に要素テーブル２０３を参照して、要素テーブル２０３のすべての要素ＩＤでループを開始し（ステップ９０２）、要素テーブル２０３の要素ＩＤを基に変更フラグテーブル２１４から、ループ処理中の要素ＩＤに該当する行（要素ＩＤで特定されるファイルに該当する行）を取得する（ステップ９０３）。

次に、フラグ管理部１１２は、変更フラグテーブル２１４を参照して、要素が変更必要（変更予定）であるか否か、即ち、要素ＩＤで特定されるファイルが変更必要（変更予定）である否かを判定し（ステップ９０４）、このステップで否定の判定結果を得た場合、このルーチンでの処理を終了し、このステップで肯定の判定結果を得た場合、要素テーブル２０３の要素ＩＤを基に変更影響テーブル２０４から変更元要素ＩＤが一致する複数行を取得し（ステップ９０５）、取得した複数行でループを開始する（ステップ９０６）。

次に、フラグ管理部１１２は、ループ中の処理として、取得した複数行のうち該当行の変更影響要素ＩＤを変更影響テーブル２０４から取得し（ステップ９０７）、取得した変更影響要素ＩＤを基に変更フラグテーブル２１４のうち要素ＩＤが一致する行（要素ＩＤで特定されるファイルが一致する行）を取得し（ステップ９０８）、変更予定状態が「変更必要（Ｃ）」でないか否かを判定し（ステップ９０９）、このステップで肯定の判定結果を得た場合、変更予定状態を未確認（？）に変更し（ステップ９１０）、その後、このルーチンでの処理を終了し、ステップ９０９で否定の判定結果を得た場合、即ち、変更必要（変更予定）（Ｃ）である場合、何もせずループを継続し、その後、このルーチンでの処理を終了する。最終的にすべての要素テーブル２０３に含まれる要素ＩＤで処理を行い、ステップ９１１で処理を終了する。ここで示したアルゴリズムは基本的な流れを示したため、実際には未確認（？）範囲を最小化する応用アルゴリズム等を持つ実現形態がある。

図１０は、設計が終了した時点のフラグの状態を説明するための図であって、（ａ）は、ディスプレイの表示例を示す構成図、（ｂ）は、変更フラグテーブルの構成図である。図１０において、開発者１０１が、周辺機器１０３を操作して、ディスプレイ１０２の画面上に一覧画面８０１を表示させ、ユーザインタフェース表示部１０８を通じて「func2」等を変更するための設計が完了したことを指示すると、ソース依存関係解析部１１０は、指示された情報を基にソースコードデータベース１１４を参照して、「func2」と呼出または被呼出の関係にある関数又は変数（value1、func3、func1）にシンボルを表示するための処理を実行する。この処理結果がユーザインタフェース表示部１０８を介してディスプレイ１０２に転送されると、ディスプレイ１０２の一覧画面８０１には、ソース依存関係解析部１１０の参照結果が表示される。この際、開発者１０１は、表示された一覧画面８０１の内容を参照することができる。

一覧画面８０１には、変更元８０２に関する情報として、「func2」のファイルの名称（FileA.c）および関数/変数の名称（func2）が表示され、変更影響８０３として、「func2」の変更の影響を受けるファイルおよび関数/変数であって、要素テーブル２０３と変更影響テーブル２０４に登録されたファイルの名称（FileA.h、FileB.c、FileC.c）および関数/変数の名称（value1、func3、func1）が表示され、変更影響タイプ８０４として、変更影響テーブル２０４に登録された「呼出」または「被呼出」が表示され、メトリクス８０５として、要素テーブル２０３の他依存数２０８に登録された情報（他依存数：１５など）が表示される。この際、変更元８０２の関数/変数「func2」には、未変更を示すシンボルレ点と、変更必要（変更予定）を示すシンボル（Ｃ）がフラグ（チェックフラグ）として表示される。また、変更影響８０３の関数/変数（value1、func3、func1）には、未変更を示すシンボルレ点と、変更不要を示すシンボル（Ｎ）または変更必要を示すシンボル（Ｃ）がフラグ（チェックフラグ）として表示される。

この際、開発者１０１は、一覧画面８０１を見ることで、すべての未確認フラグ（？）が、変更予定フラグ（Ｃ）または変更不要フラグ（Ｎ）に付け替えられているかどうかを確認できる。そのため、未確認フラグが残っていた場合には、すべての未確認フラグ（？）は、ユーザインタフェース表示部１０８により強調表示（図中では白黒反転表示）される。これにより、開発者１０１の設計時点における変更影響の考慮漏れが抑止される。

また、変更フラグテーブル２１４のファイル２１５には、ファイルの名称（FileA.h、FileA.c、FileB.c、FileC.c）が登録され、関数/変数２１６には、関数/変数の名称（value1、func2、func3、func1）が登録され、ソース構成管理状態２１７には、各ファイルが未変更であることを示すために、「未変更」の情報が登録され、変更予定状態２１８には、「func2」と「func3」の欄のみ、変更必要（変更予定）であることを示すために、「変更必要」の情報が登録され、他の欄には、変更不要であることを示すために、「変更不要」の情報が登録され、更新者２２０には、開発者１０１の名称が登録され、更新日時２２１には、開発者１０１による更新日時の情報が登録される。変更フラグテーブル２１４には、一覧画面８０１に表示されたフラグ（チェックフラグ）に関連した情報が格納される。この際、更新者と更新日時の情報が保存されるため、誰が何時どのような判断を行ったかという設計エビデンスが保存される。

本実施例によれば、新しい機能を追加する開発者１０１が、実装前の設計工程に本システムを利用することで、抜け漏れなく（変更影響のチェック漏れなく）ソースコードを変更することを支援することができる。具体的には、設計が終了した時点で、一覧画面８０１には、変更元８０２に関する情報と変更影響８０３の情報が表示されるので、開発者１０１は、一覧画面８０１を参照することで、ソードコードに属する要素のうち変更元要素と変更元要素の影響を受ける要素との関連を確認することができる。また、一覧画面８０１には、未確認フラグ、変更予定フラグまたは変更不要フラグがシンボルとして表示されるので、開発者１０１は、ソードコードに属する要素を変更したか否か等を容易に確認することができる。さらに、一覧画面８０１には、未確認フラグが残っていた場合には、未確認フラグが強調して表示されるので、開発者１０１の設計時点における変更影響の考慮漏れが抑止される。また、一覧画面８０１のメトリクス８０５には、他依存数が数値情報で表示されるので、開発者１０１は、他依存数が設定値よりも多い要素（他依存数：１５）については、変更すると影響が大きいので、変更しない方が良いと判断できる。

本実施例は、母体ソースコードに機能を追加する典型的な開発フローのうち、ソースコードの変更を行う実装工程の作業の例である。

図１１は、設計を行った後、ソースコードの変更を実施した状態を説明するための図であって、（ａ）は、実施例２におけるディスプレイの表示例を示す構成図、（ｂ）は、実施例２における変更フラグテーブルの構成図である。図１１において、開発者１０１が、周辺機器１０３を操作して、ディスプレイ１０２の画面上に一覧画面８０１を表示させ、ユーザインタフェース表示部１０８を通じて「func2」等を変更するための設計が完了した後、ソースコードの変更を指示すると、ソース依存関係解析部１１０は、指示された情報を基にソースコードデータベース１１４を参照して、「func2」と呼出または被呼出の関係にある関数又は変数（value1、func3、func1）にシンボルを表示するための処理を実行する。この処理結果が、ユーザインタフェース表示部１０８を介してディスプレイ１０２に転送されると、ディスプレイ１０２の一覧画面８０１には、ソース依存関係解析部１１０の参照結果が表示される。この際、開発者１０１は、表示された一覧画面８０１の内容を参照することができる。

一覧画面８０１には、変更元８０２に関する情報として、「func2」のファイル（FileA.c）および関数/変数「func2」が表示され、変更影響８０３として、「func2」の変更の影響を受けるファイルおよび関数/変数であって、要素テーブル２０３と変更影響テーブル２０４に登録されたファイルの名称（FileA.h、FileB.c、FileC.c）および関数/変数の名称（value1、func3、func1）が表示され、変更影響タイプ８０４として、変更影響テーブル２０４に登録された「呼出」または「被呼出」が表示され、メトリクス８０５として、要素テーブル２０３の他依存数２０８に登録された情報（他依存数：１５など）が表示される。この際、変更元８０２の関数/変数「func2」には、変更済を示すシンボル（！）と、変更必要（変更予定）を示すシンボル（Ｃ）がフラグ（チェックフラグ）として表示される。また、変更影響８０３の関数/変数（value1、func3、func1）には、未変更を示すシンボルレ点または変更済を示すシンボル（！）、変更不要を示すシンボル（Ｎ）または変更必要を示すシンボル（Ｃ）がフラグ（チェックフラグ）として表示される。

この際、開発者１０１は、一覧画面８０１を見ることで、設計通り変更されているか否かを確認することができる。例えば、要素（func2）が変更予定（Ｃ）で且つ変更済（！）の場合であって、要素（value１）が変更不要（Ｎ）で且つ未変更（レ点）の場合は、設計通り実装されている望ましい例である。一方、要素（func2）が変更予定（Ｃ）で且つ変更済（！）の場合であって、要素（func3）が、変更予定（Ｃ）にもかかわらず未変更（レ点）の場合と、要素（func2）が変更予定（Ｃ）で且つ変更済（！）の場合であって、要素（func1）が、変更不要（Ｎ）にもかかわらず変更済（！）の場合は、設計通り変更されておらず望ましくない例である。望ましくないフラグの組合せの場合、シンボルは、ユーザインタフェース表示部１０８により、強調表示される。ただし、望ましくない例であっても、実装の都合上変更が起きることはよくあるため、操作の制約は設けない。新たに追加された変更要素を変更予定（Ｃ）に変更し、再チェックをかけることで、変更影響の考慮漏れを抑止した上で、誤った設計を行った事実は開発者のＩＤとともにチェックフラグデータベース１１６の変更フラグテーブル２１４に登録される。

また、変更フラグテーブル２１４のファイル２１５には、ファイルの名称（FileA.h、FileA.c、FileB.c、FileC.c）が登録され、関数/変数２１６には、関数又は変数の名称（value1、func2、func3、func1）が登録され、ソース構成管理状態２１７には、「func1」のみ「変更済」の情報が登録され、それ以外は、「未変更」の情報が登録され、各ファイルが未変更であることを示すために、「未変更」の情報が登録され、変更予定状態２１８には、「func2」と「func3」の欄のみ、「変更必要」の情報が登録され、他の欄には、「変更不要」の情報が登録され、更新者２２０には、開発者１０１の名称が登録され、更新日時２２１には、開発者１０１による更新日時の情報が登録される。

本実施例によれば、新しい機能を追加する開発者１０１が、実装後に本システムを利用することで、抜け漏れなくソースコードを変更することを支援することができる。具体的には、設計を行った後、ソースコードの変更を実施した場合、一覧画面８０１には、変更元８０２に関する情報及び変更影響８０３の情報と共に、未確認フラグ、変更予定フラグまたは変更不要フラグがシンボルとして表示され、且つ、これらのシンボルのうち設計通り変更されていないフラグの組合せの場合には、シンボルが強調して表示されるので、開発者１０１は、ソードコードに属する要素が、設計通り変更されていないことを容易に確認することができる。

本実施例は、複数の開発者が並行して機能の追加を行う場合の例である。以下、複数の開発者が並行して機能の追加を行う場合の問題と解決策について説明する。

図１２は、実施例３における処理であって、チェックフラグデータベースを参照しない場合の処理を説明するためのフローチャートである。図１２において、開発プロセスの始点１２０１から、開発者Ａが処理を開始し、開発者Ａが、母体コード（ソースコード）を読込むための操作を実行すると、ユーザインタフェース表示部１０８が、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込み、読込んだ母体コードをディスプレイ１０２上に表示する。この際、開発者Ａは、ディスプレイ１０２上に表示された母体コード（ソースコード）に対して、周辺機器１０３のキーボード等を操作して、機能Ａの追加を設計する（ステップ１２０２）。例えば、「func2」を変更するための設計を行う。次に、開発者Ａは、周辺機器１０３のキーボード等を操作して、ステップ１２０２にて追加された機能Ａ（機能Ａの追加）をソースコード上に実装する（ステップ１２０３）。この後、開発者Ａは、構成管理データベース１１５から母体コード（ソースコード）を読込むための操作を実行し、ディスプレイ１０２上に表示された母体コードを参照して、機能Ａの実装完了チェックを行い（ステップ１２０４）、チェック後、変更後コード（ソースコード）を構成管理データベース１１５に登録するための操作を実行する。これにより、開発プロセスは終点１２０５で終了する。

一方、開発者Ｂは、開発プロセスの始点１２１１から処理を開始する。開発者Ｂが母体コード（ソースコード）を読込むための操作を実行すると、ユーザインタフェース表示部１０８は、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込み、読込んだ母体コードをディスプレイ１０２上に表示する。この際、開発者Ｂは、ディスプレイ１０２上に表示された母体コードに対して、周辺機器１０３のキーボード等を操作して、機能Ｂの追加を設計する（ステップ１２１２）。例えば、「func2」を変更するための設計を行う。次に、開発者Ｂは、周辺機器１０３のキーボード等を操作して、ステップ１２１２にて追加された機能Ｂ（機能Ｂの追加）をソースコード上に実装する（ステップ１２１３）。この後、開発者Ｂは、構成管理データベース１１５から母体コード（ソースコード）を読込むための操作を実行し、ディスプレイ１０２上に表示された母体コードを参照して、機能Ｂの実装完了チェックを行う（ステップ１２１４）。この際、開発プロセスを終点１２１５で終了する前に、修正手戻りの発生や衝突発生検知遅れが生じることがある。

例えば、開発者Ａの操作による処理が開発者Ｂの操作による処理よりも早く完了し、ステップ１２０４にて、機能Ａの変更後コード登録が、ステップ１２１４における機能Ｂの実装完了チェックよりも先に実施された場合、ステップ１２１４における機能Ｂの母体コード読込みは、機能Ｂの追加を設計する際に実施したステップ１２１２における母体コード読込みとは異なるコード（ソースコード）を読込むため、機能Ａが変更されたコード（ソースコード）の影響を受ける。具体的には、開発者Ｂに対して変更予定でないファイルが変更された場合、変更影響チェックをやり直す必要が発生する。この際、場合によっては、ソースコードの修正もやり直す必要がある。この変更影響による衝突を、ステップ１２１４における母体コード読込みを実施するまで検知することができず、衝突発生検知遅れとなり、機能Ｂの実装完了チェックの作業において、修正手戻りの発生により、開発工数が長くなってしまう。また、機能Ａと機能Ｂが同じ内容の変更であった場合については、ステップ１２１３では、二重作業の実施となり、開発者Ｂが行った、機能Ｂの追加を実装する作業は無駄になってしまう。

図１３は、実施例３における処理であって、チェックフラグデータベースのデータを活用した場合の処理を説明するためのフローチャートである。図１３において、開発プロセスの始点１３０１から、開発者Ａが処理を開始し、開発者Ａが母体コード（ソースコード）を読込むための操作を実行すると、操作に伴う情報を入力したユーザインタフェース表示部１０８は、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込み、読込んだ母体コードをディスプレイ１０２上に表示する。この際、開発者Ａは、ディスプレイ１０２上に表示された母体コードに対して、周辺機器１０３のキーボード等を操作して、機能Ａの追加を設計（例えば、「func2」を変更するための設計）し（ステップ１３０２）、設計後のチェックフラグをチェックフラグデータベース１１６に登録するための操作を実行する。

次に、開発者Ａは、周辺機器１０３のキーボード等を操作して、ステップ１３０２にて追加された機能Ａ（機能Ａの追加）をソースコード上に実装する（ステップ１３０３）。この後、開発者Ａが、母体コード（ソースコード）を読込むと共に、チェックフラグを読込むための操作を実行すると、操作に伴う情報を入力したユーザインタフェース表示部１０８は、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込むと共に、フラグ管理部１１２を介してチェックフラグデータベース１１６からチェックフラグを読込み、読込んだ母体コードとチェックフラグをディスプレイ１０２上に表示する。この際、開発者Ａは、ディスプレイ１０２上に表示された母体コードとチェックフラグを参照して、機能Ａの実装完了チェックを行い（ステップ１３０４）、チェック後、変更後コード（ソースコード）を構成管理データベース１１５に登録するための操作を実行する。これにより、開発プロセスは終点１３０５で終了する。

この際、フラグ管理部１１２は、ソースコードに含まれるシンボルの変更を指示する第一の変更要求を周辺機器１０３から受付けたとき、当該受付けた第一の変更要求の影響を受ける他のシンボルが変更されているかどうかを示す情報（第一の変更管理情報）をソース構成管理状態２１７の情報としてチェックフラグデータベース１１６に格納すると共に、第一の変更要求の影響を受ける他のシンボルの変更予定の有無を示す情報（第一の変更予定情報）を変更予定状態２１８の情報としてチェックフラグデータベース１１６に格納する。ユーザインタフェース表示部１０８は、第一の変更要求で変更を指示されたシンボル、第一の変更要求の影響を受ける他のシンボル、第一の変更要求の影響を受ける他のシンボルが変更されているかどうかを示す情報（第一の変更管理情報）及び、第一の変更要求の影響を受ける他のシンボルの変更予定の有無を示す情報（第一の変更予定情報）をディスプレイ１０２の画面上に表示させる。

一方、開発者Ｂは、開発プロセスの始点１３１１から処理を開始する。開発者Ｂが母体コード（ソースコード）を読込むと共に、チェックフラグを読込むための操作を実行すると、操作に伴う情報を入力したユーザインタフェース表示部１０８は、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込むと共に、フラグ管理部１１２を介してチェックフラグデータベース１１６からチェックフラグを読込み、読込んだ母体コードとチェックフラグをディスプレイ１０２上に表示する。この際、開発者Ｂは、ディスプレイ１０２上に表示された母体コードに対して、周辺機器１０３のキーボード等を操作して、機能Ｂの追加を設計する（ステップ１３１２）。例えば、「func2」を変更するための設計を行う。この際、フラグ管理部１１２が衝突（要素間の衝突）を検知した場合、ディスプレイ１０２上には、何れかの要素に変更衝突が生じたことが表示される。この場合、開発者Ｂは、開発者Ａと実装内容と時期を調整するための話し合いを行う（ステップ１３１３）。

この際、フラグ管理部１１２は、ソースコードに含まれるシンボルの変更を指示する第二の変更要求を周辺機器１０３から受付けたとき、当該受付けた第二の変更要求の影響を受ける他のシンボルが変更されているかどうかを示す情報（第二の変更管理情報）をソース構成管理状態２１７の情報として保持すると共に、第二の変更要求の影響を受ける他のシンボルの変更予定の有無を示す情報（第二の変更予定情報）を変更予定状態２１８の情報として保持し、チェックフラグデータベース１１６に格納された第一の変更管理情報及び第一の変更予定情報と、保持した第二の変更管理情報及び第二の変更予定情報とを比較し、この比較結果から、いずれかの情報間で変更衝突があるか否かを判定し、この判定結果をユーザインタフェース表示部１０８を介してディスプレイ１０２に転送する。ユーザインタフェース表示部１０８は、第二の変更要求で変更を指示されたシンボル、第二の変更要求の影響を受ける他のシンボル、第二の変更管理情報及び、第二の変更予定情報をディスプレイ１０２の画面上に表示させる。

次に、開発者Ｂは、周辺機器１０３のキーボード等を操作して、ステップ１３１２にて追加された機能（調整後に追加された機能を含む）Ｂ（機能Ｂの追加）をソースコード上に実装する（ステップ１３１４）。この後、開発者Ｂが、母体コード（ソースコード）を読込むと共に、チェックフラグを読込むための操作を実行すると、操作に伴う情報を入力したユーザインタフェース表示部１０８は、ソース構成管理部１０９を介して構成管理データベース１１５から母体コード（ソースコード）を読込むと共に、フラグ管理部１１２を介してチェックフラグデータベース１１６からチェックフラグを読込み、読込んだ母体コードとチェックフラグをディスプレイ１０２上に表示する。この際、開発者Ｂは、ディスプレイ１０２上に表示された母体コードとチェックフラグを参照して、機能Ｂの実装完了チェックを行い（ステップ１３１５）、チェック後、変更後コード（ソースコード）を構成管理データベース１１５に登録するための操作を実行する。これにより、開発プロセスは終点１３１６で終了する。この際、フラグ管理部１１２は、いずれかの情報間で変更衝突がないと判定したことを条件に、保持した第二の変更管理情報及び第二の変更予定情報をチェックフラグデータベース１１６に格納する。

ステップ１３１２で、フラグ管理部１１２が衝突を検知した場合、早期に衝突を検知することができ、フラグを点滅表示（強調表示）することで、開発者Ｂに警告することができる。この際、開発者Ｂは、この警告を見て、開発者Ａと話合いを行い、実装内容と時期を調整することができる。この話合いにより、ステップ１３１４で機能Ｂの追加を実装するときに、同じ作業を二重に行わなくて済み（二重作業の抑止）、工数が削減できる。また、ステップ１３１５で機能Ｂの実装完了チェックを行うときには、機能Ａが既に登録されていることを設計で考慮済みのため、予想外の作業手戻りは発生せず（修正手戻りの抑止）、工数が削減できる。

図１４は、実施例３におけるシステムであって、複数の開発者を対象としたシステムの構成図である。図１４において、開発者１０１として、複数の開発者Ａ、Ｂを対象として場合、各開発者Ａ、Ｂに対して開発マシン１０が用意される。各開発マシン１０はそれぞれ管理サーバ１２に接続される。なお、各開発マシン１０と管理サーバ１２は、図１のものと同様に構成されているので、それらの説明は省略する。なお、図１４のシステムでは、記憶装置１０７が、各開発マシン１０で共有されているので、各開発マシン１０が、記憶装置１０７に格納されるチェックフラグデータベース１１６をアクセスすることで、各開発者Ａ、Ｂの変更（変更必要）に伴う要素の衝突の有無を検知できる。

図１５は、複数の開発者の変更によって衝突が起こった状態を説明するための図であって、（ａ）は、実施例３におけるディスプレイの表示例を示す構成図、（ｂ）は、実施例３における変更フラグテーブルの構成図である。図１５において、複数の開発者１０１が、それぞれ周辺機器１０３を操作して、ディスプレイ１０２の画面上に一覧画面８０１を表示させ、ユーザインタフェース表示部１０８を通じて「func2」等を変更すると、ソース依存関係解析部１１０は、指示された情報を基にソースコードデータベース１１４を参照して、「func2」と呼出または被呼出の関係にある関数又は変数（value1、func3、func1）にシンボルを表示するための処理を実行する。この処理結果がインタフェース表示部１０８を介してディスプレイ１０２に転送されると、ディスプレイ１０２の一覧画面８０１には、ソース依存関係解析部１１０の参照結果が表示される。この際、各開発者１０１は、表示された一覧画面８０１の内容を参照することができる。

一覧画面８０１には、変更元８０２に関する情報として、「func2」のファイル（FileA.c）および関数/変数「func2」が表示され、変更影響８０３として、「func2」の変更の影響を受けるファイルおよび関数/変数であって、要素テーブル２０３と変更影響テーブル２０４に登録されたファイルの名称（FileA.h、FileB.c、FileC.c）および関数/変数の名称（value1、func3、func1）が表示され、変更影響タイプ８０４として、変更影響テーブル２０４に登録された「呼出」または「被呼出」が表示され、メトリクス８０５として、要素テーブル２０３の他依存数２０８に登録された情報（他依存数：１５など）が表示される。この際、変更元８０２の関数/変数「func2」には、未変更のシンボルレ点、変更必要のシンボル（Ｃ）がフラグ（チェックフラグ）として表示される。また、変更影響８０３の関数/変数（value1、func3、func1）には、未変更のシンボルレ点、変更不要のシンボル（Ｎ）または変更必要のシンボル（Ｃ）、さらに変更衝突（衝突あり）を示すシンボル（×）がフラグ（チェックフラグ）として表示される。

また、変更フラグテーブル２１４のファイル２１５には、ファイルの名称（FileA.h、FileA.c、FileB.c、FileC.c、FileB.c、FileC.c）が登録され、関数/変数２１６には、関数又は変数の名称（value1、func2、func3、func1、func3、func1）が登録され、ソース構成管理状態２１７には、それぞれ、「未変更」の情報が登録され、変更予定状態２１８には、「FileA.h」の欄に「変更不要」が登録され、「FileA.c」と「FileB.c」の欄に「変更必要」が登録され、「FileC.c」の欄に「変更不要」が登録され、「FileB.c」と「FileC.c」に「変更必要」が登録され、変更衝突状態２１９には、「FileB.c」、「FileC.c」、「FileB.c」、「FileC.c」の欄に「変更衝突」が登録され、更新者２２０には、開発者１０１の名称（開発者Ａまたは開発者Ｂ）が登録され、更新日時２２１には、各開発者（開発者Ａまたは開発者Ｂ）１０１による更新日時の情報が登録される。

ここで、フラグ管理部１１２は、変更フラグテーブル２１４を参照し、要素ＩＤ３の「FileB.c」に関して、ソース構成管理状態２１７に登録された情報と変更予定状態２１８に登録された情報とを比較し、いずれかの情報間に変更衝突があるか否かを判定する。この際、開発者Ａの操作による情報として、ソース構成管理状態２１７に「未変更」が登録され、変更予定状態２１８に「変更必要」が登録され、開発者Ｂの操作による情報として、ソース構成管理状態２１７に「未変更」が登録され、変更予定状態２１８に「変更必要」が登録された場合、「変更必要」が重複しているので、フラグ管理部１１２は、「変更衝突」と判定し、変更衝突状態２１９に「変更衝突」の情報を登録する。

また、フラグ管理部１１２は、変更フラグテーブル２１４を参照し、要素ＩＤ４の「FileC.c」に関して、ソース構成管理状態２１７に登録された情報と変更予定状態２１８に登録された情報とを比較し、いずれかの情報間に変更衝突があるか否かを判定する。この際、開発者Ａの操作による情報として、ソース構成管理状態２１７に「未変更」が登録され、変更予定状態２１８に「変更不要」が登録され、開発者Ｂの操作による情報として、ソース構成管理状態２１７に「未変更」が登録され、変更予定状態２１８に「変更必要」が登録された場合、開発者Ａが「変更必要」で、開発者Ｂが「変更不要」であって、両者の内容が矛盾しているので、フラグ管理部１１２は、「変更衝突」と判定し、変更衝突状態２１９に「変更衝突」の情報を登録する。

変更衝突状態２１９に、「変更衝突」の情報が記録された場合、フラグ管理部１１２とユーザインタフェース表示部１０８の処理により、一覧画面８０１の変更影響８０３には、変更衝突の生じた要素、例えば、要素ＩＤ３、４のファイル（FileB.c、FileC.c）に関して、変更衝突状態７０３のシンボル（×）が強調して表示される。これは、変更予定（Ｃ）が付いている要素に変更衝突（×）が付いているものが直接的に影響するが、変更不要（Ｎ）と判断しているが間接的に影響する可能性があるため、変更衝突の生じた要素については、警告を行うためである。この場合、各開発者Ａ、Ｂは、一覧画面８０１を見ることで、要素の変更に伴って衝突が生じたことを容易に確認することができる。また、この場合、変更の具体的な内容について開発者Ａ、Ｂ間で話合う必要がある。この話合いによって重複した内容の変更や、変更同士の衝突に起因する不具合を避けることができる。

本実施例によれば、複数の開発者が並行して新しい機能を追加した場合の衝突を早期に検出し、二重作業を減らすことができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、管理サーバ１２の中央処理演算装置１０６が記憶装置１０７を管理する代わりに、開発マシン１０の中央処理演算装置１０４が、コントローラとして、記憶装置１０７を管理することもできる。上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能等は、それらの一部又は全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に記録して置くことができる。

１０開発マシン、１２管理サーバ、１０１開発者、１０２ディスプレイ、１０３周辺機器、１０４中央処理演算装置、１０５記憶装置、１０６中央処理演算装置、１０７記憶装置、１０８ユーザインタフェース表示部、１０９ソース構成管理部、１１０ソース依存関係解析部、１１１ソースメトリクス解析部、１１２フラグ管理部、１１３変更中ソースコード、１１４ソースコードデータベース、１１５構成管理データベース、１１６チェックフラグデータベース、２０３要素テーブル、２０４変更影響テーブル、２１２ソースコード、２１４変更フラグテーブル、７０１ソース構成管理状態、７０２変更予定状態、７０３変更衝突状態、８０１一覧画面

Claims

関数又は変数のうち少なくとも一方で構成される複数の要素を含むソースコードを格納する記憶装置と、
情報の入出力を行う入出力装置と、
前記記憶装置及び前記入出力装置を管理するコントローラを含むシステムにおけるソフトウェア開発支援方法であって、
前記コントローラが、前記ソースコードに含まれる要素の変更を指示する第一の変更要求を前記入出力装置から受付けたとき、当該受付けた第一の変更要求の影響を受ける他の要素が変更されているかどうかを示す第一の変更管理情報と前記第一の変更要求の影響を受ける他の要素の変更予定の有無を示す第一の変更予定情報を前記記憶装置に格納する第一のステップと、
前記入出力装置が、前記第一の変更要求で変更を指示された要素、前記第一の変更要求の影響を受ける他の要素、前記第一の変更管理情報及び、前記第一の変更予定情報を出力する第二のステップと、を有することを特徴とするソフトウェア開発支援方法。
請求項１に記載のソフトウェア開発支援方法であって、
前記コントローラが、前記ソースコードに含まれる要素の変更を指示する第二の変更要求を前記入出力装置から受付けたとき、当該受付けた第二の変更要求の影響を受ける他の要素が変更されているかどうかを示す第二の変更管理情報と前記第二の変更要求の影響を受ける他の要素の変更予定の有無を示す第二の変更予定情報を保持する第三のステップと、
前記入出力装置が、前記第二の変更要求で変更を指示された要素、前記第二の変更要求の影響を受ける他の要素、前記第二の変更管理情報及び、前記第二の変更予定情報を出力する第四のステップと、を有することを特徴とするソフトウェア開発支援方法。
請求項２に記載のソフトウェア開発支援方法であって、
前記コントローラは、
前記第三のステップでは、前記記憶装置に格納された前記第一の変更管理情報及び前記第一の変更予定情報と、前記保持した前記第二の変更管理情報及び前記第二の変更予定情報とを比較し、当該比較結果から、前記いずれかの情報間で変更衝突があるか否かを判定し、当該判定結果を前記入出力装置に転送することを特徴とするソフトウェア開発支援方法。
請求項３に記載のソフトウェア開発支援方法であって、
前記コントローラは、
前記第三のステップでは、前記いずれかの情報間で変更衝突がないと判定したことを条件に、前記保持した前記第二の変更管理情報及び前記第二の変更予定情報を前記記憶装置に格納することを特徴とするソフトウェア開発支援方法。
請求項３に記載のソフトウェア開発支援方法であって、
前記入出力装置は、
前記コントローラから、前記いずれかの情報間で変更衝突ありの判定結果を受信した場合、前記変更衝突ありの判定結果で特定される要素を強調して出力することを特徴とするソフトウェア開発支援方法。
請求項１に記載のソフトウェア開発支援方法であって、
前記入出力装置は、
前記第二のステップでは、前記第一の変更要求の影響を受ける他の要素の数を示す第一の数値情報を出力することを特徴とするソフトウェア開発支援方法。
請求項２に記載のソフトウェア開発支援方法であって、
前記入出力装置は、
前記第二のステップ又は前記第三のステップでは、前記第一の変更要求の影響を受ける他の要素の数を示す第一の数値情報又は前記第二の変更要求の影響を受ける他の要素の数を示す第二の数値情報を出力することを特徴とするソフトウェア開発支援方法。
関数又は変数のうち少なくとも一方で構成される複数の要素を含むソースコードを格納する記憶装置と、
情報の入出力を行う入出力装置と、
前記記憶装置及び前記入出力装置を管理するコントローラと、を有するソフトウェア開発支援システムであって、
前記コントローラは、
前記ソースコードに含まれる要素の変更を指示する第一の変更要求を前記入出力装置から受付けたとき、当該受付けた第一の変更要求の影響を受ける他の要素が変更されているかどうかを示す第一の変更管理情報と前記第一の変更要求の影響を受ける他の要素の変更予定の有無を示す第一の変更予定情報を前記記憶装置に格納し、
前記入出力装置は、
前記第一の変更要求で変更を指示された要素、前記第一の変更要求の影響を受ける他の要素、前記第一の変更管理情報及び、前記第一の変更予定情報を出力することを特徴とするソフトウェア開発支援システム。
請求項８に記載のソフトウェア開発支援システムであって、
前記コントローラは、
前記ソースコードに含まれる要素の変更を指示する第二の変更要求を前記入出力装置から受付けたとき、当該受付けた第二の変更要求の影響を受ける他の要素が変更されているかどうかを示す第二の変更管理情報と前記第二の変更要求の影響を受ける他の要素の変更予定の有無を示す第二の変更予定情報を保持し、
前記入出力装置は、
前記第二の変更要求で変更を指示された要素、前記第二の変更要求の影響を受ける他の要素、前記第二の変更管理情報及び、前記第二の変更予定情報を出力することを特徴とするソフトウェア開発支援システム。
請求項９に記載のソフトウェア開発支援システムであって、
前記コントローラは、
前記記憶装置に格納された前記第一の変更管理情報及び前記第一の変更予定情報と、前記保持した前記第二の変更管理情報及び前記第二の変更予定情報とを比較し、当該比較結果から、前記いずれかの情報間で変更衝突があるか否かを判定し、当該判定結果を前記入出力装置に転送することを特徴とするソフトウェア開発支援システム。