JP2006178511A - ソフトウェア変更トレーサビリティ管理装置 - Google Patents

Abstract

【課題】 ソフトウェア構成品の変更時に、修正すべきソフトウェア構成品の抽出を容易とし、トレーサビリティを確保する。
【解決手段】 管理装置１は、ソフトウェア変更を生じた問題毎に、問題に対処するために修正されたソフトウェア構成品を記憶する手段２と、新たな問題の発生時に、その問題発生の原因として特定されたソフトウェア構成品が修正された過去の問題への対処にあたって、手段２に記憶されている各構成品が同時に修正された問題の数を、各構成品の影響度として評価する手段３と、その影響度に対応して、修正の必要性のチェックを行うべき構成品の名称を表示する手段４とを備える。
【選択図】図１

Description

本発明は、ソフトウェア構成品の間のトレーサビリティ管理方式に係り、さらに詳しくはソフトウェアの開発、保守過程におけるソフトウェア構成品の修正もれなどを防止するための、ソフトウェア変更時におけるトレーサビリティ管理装置に関する。

従来において、ソフトウェア開発や保守過程においてソフトウェアの変更を行う場合には、例えば設計書などの上流工程の構成品から実行プログラムなどの下流工程の構成品までの関係を対応一覧表として自動生成することによって、設計書から実行プログラムまでの一連のソフトウェア構成品に対するトレーサビリティを確保する方式が用いられていた。
このような従来技術の文献として次の特許文献がある。
特開２００２−１８２９０８号公報 「Ｓ／Ｗ開発プロセス間のトレーサビリティ装置」

この文献には、上流ドキュメントから下流ドキュメントへの対応関係を示すトレース情報によって要求仕様書や外部設計書の修正箇所を判定し、修正が必要な上流ドキュメントを修正させる技術が開示されている。

しかしながらこのように上流工程の構成品から下流工程までの構成品の間の関係づけだけの仕組みを利用してトレーサビリティを確保しようとすると、例えば設計書より先に実行プログラムを変更するような場合に、上流工程のプログラムの変更もれのように、プログラムと設計書の間に変更要因の関係づけが行われず、トレーサビリティが確保されない場合があるという問題点があった。

このような場合に実際には、例えば下流工程の実行プログラムに変更が発生した場合に、ソフトウェア構成品の間の影響範囲を水平展開によって洗い出して対応するという方法がとられていた。水平展開とは、障害原因となったプログラムの変更に伴って、その影響を受けるプログラム、もしくはソフトウェア構成品を全て洗い出し、適切な変更を行うシステム維持作業である。この作業はほとんど人手に頼らざるを得ず、設計書とソースプログラムやロードモジュールとしての実行プログラムとの間の対応関係における影響範囲の明確化に多くの工数がかかるという問題点があった。

また実際のソフトウェア開発では、上流工程からの順序だったソフトウェア構成品の修正の仕組みがなく、ソフトウェアの変更を必要とする問題が発生すると、例えばソースファイルやロードモジュールとしての実行ファイルのみが修正され、上流工程の設計書の修正は後回しにされることも多かった。これによってソフトウェア変更のトレーサビリティが確保されなくなるという問題点もあった。

本発明の課題は、上述の問題点に鑑み、過去のソフトウェア構成品の修正状況を変更影響関係情報として記憶しておき、その情報を利用することによって水平展開に要する工数を削減し、変更プログラム抽出作業を容易にすることと、上流工程のソフトウェア構成品が修正されない限り、下流工程の構成品の修正を許可しないようにソフトウェア構成品の修正を制御することによって、ソフトウェア変更のトレーサビリティを確保することである。

図１は、本発明のソフトウェア変更トレーサビリティ管理装置の原理構成ブロック図である。同図は、ソフトウェア変更時のソフトウェア構成品間の整合性を確保するソフトウェア変更トレーサビリティ管理装置の原理構成ブロック図であり、同図（ａ）は後述する第１の実施例に対応し、同図（ｂ）は第２の実施例に対応する原理構成を示す。

図１（ａ）において、本発明のソフトウェア変更トレーサビリティ管理装置１は、少なくとも影響関係情報記憶手段２、影響度評価手段３、および表示手段４を備える。
影響関係情報記憶手段２は、ソフトウェア変更を生じた問題毎に、その問題に対応するために修正されたソフトウェア構成品をソフトウェア変更影響関係情報として記憶するものであり、影響度評価手段３は、新たにソフトウェアの変更を行うべき問題が発生した時、その問題発生の原因として特定されたソフトウェア構成品が修正された過去の問題への対処にあたって、影響関係情報記憶手段２に記憶されている各ソフトウェア構成品が同時に修正された問題の数を、各ソフトウェア構成品の影響度として評価するものであり、表示手段４は、評価された影響度に対応して、修正の必要性のチェックを行うべきソフトウェア構成品の名称を表示するものである。

発明の実施の形態においては、表示手段４によって表示されたソフトウェア構成品以外のソフトウェア構成品であって、新たに発生した問題点に対応して修正を行うべきソフトウェア構成品の名称を外部から受け取るインタフェース手段５をソフトウェア変更トレーサビリティ管理装置１がさらに備え、また影響関係情報記憶手段２が、外部から受け取ったソフトウェア構成品を含め、新たに発生した問題に対応して修正の行われたソフトウェア構成品をさらに記憶することもできる。

図１（ｂ）は、後述する第２の実施例に対応するソフトウェア変更トレーサビリティ管理装置の原理構成を示し、装置７は、チェック実施フラグ格納手段８と、修正許可手段９とを備える。

チェック実施フラグ格納手段８は、ソフトウェア変更を行うべき問題に対応して、修正の必要性をチェックすべきソフトウェア構成品であって、上流側から下流までの各段階の関連のある一連のソフトウェア構成品に対応して、各ソフトウェア構成品のチェックが行われたことを示すチェック実施フラグを格納するものであり、修正制御手段９は、外部からのソフトウェア構成品の修正要求に対応して、チェック実施フラグ格納手段８の格納内容を用いて、修正が要求されたソフトウェア構成品の上流側にある全てのソフトウェア構成品がチェック済みである時にのみ、要求されたソフトウェア構成品の修正を許可するものである。

発明の実施の形態においては、チェック実施フラグ格納手段８が、上流側から下流側までの段階の数が既知である時、その各段階におけるソフトウェア構成品が存在し、チェックの対象となることを示す対象フラグをさらに格納するとともに、修正制御手段９がその対象フラグの値に応じて、外部から修正が要求されたソフトウェア構成品の上流側のソフトウェア構成品がチェックの対象とならないと判定した時、要求されたソフトウェア構成品の修正を許可することもできる。

本発明によれば、ソフトウェア変更を行うべき問題が発生した時、その原因として特定されたソフトウェア構成品が修正された過去の問題への対処にあたって、各ソフトウェア構成品が同時に修正された問題の数を影響度として評価し、その影響度に対応して修正の必要性のチェックを行うべきソフトウェア構成品を表示することによって、ユーザの水平展開における労力を軽減させることができ、また水平展開によってさらに明らかとなったソフトウェア構成品を、将来の問題発生に備えて、ソフトウェア変更影響関係情報として反映させることによって、将来の問題発生時点におけるトレーサビリティの確保に有効となる。

また上流側から下流側までの各段階の関連のある一連のソフトウェア構成品に対応して、各構成品のチェックが行われたことを示すチェック実施フラグを用いて、修正要求がなされたソフトウェア構成品の上流側にあるすべてのソフトウェア構成品がチェック済みである時にのみ、要求されたソフトウェア構成品の修正を許可することによって、上流工程からの順序だったソフトウェア構成品の修正の仕組みが確保され、ソフトウェア変更トレーサビリティの実現に寄与するところが大きい。

図２は、本発明のソフトウェア変更トレーサビリティ管理装置の第１の実施例の構成ブロック図である。同図において管理装置は、プログラムを管理する構成管理部１０、設計書を管理する構成管理部１１、設計書を生成する設計書生成部１２、構成管理部１０によって管理されるプログラムと、構成管理部１１によって管理される設計書との対応情報を抽出する対応情報抽出部１３、対応情報抽出部１３の抽出結果に基づいて構成品間の関係を関係一覧表として格納する構成品間関係データベース１４、入出力部１５、変更制御ユーザインターフェース部１６、ソフトウェアを変更すべき問題が生じた時の問題処理表を格納する問題管理部１７、前述のシステム維持作業としての水平展開の結果を格納する水平展開データベース１８、水平展開データベース１８に格納され、後述する変更影響関係情報（変更影響表）を用いて後述する影響の評価カウントを行う影響度評価部１９、および表示部２０を備えている。なお水平展開データベース１８内のチェックリストについては後述する。

図２において、水平展開データベース１８は本発明の特許請求の範囲の請求項１における影響関係情報記憶手段に相当し、影響度評価部１９は影響度評価手段に、表示部２０は表示手段に相当する。

図３は、第１の実施例におけるソフトウェア変更トレーサビリティ管理処理のフローチャートである。同図において処理が開始されると、まずステップＳ１で構成管理部１０との連動によって不具合の問題に対応するプログラムファイルのチェックアウト／チェックインが行われ、ステップＳ２で不具合問題の原因となったプログラムのファイル名と変更影響表から、その問題に対応した各プログラムの影響度のカウント評価が行われる。この変更影響関係情報、および影響度の評価については図４と図６を用いて後述する。

つづいてステップＳ３で、不具合問題に関連して修正する必要があるか否かのチェックを行うべきプログラムファイル名を示すチェックリストが生成され、そのチェックリストが図２の表示部２０に表示され、ステップＳ４で、例えばユーザによってチェックリストと独立して行われた水平展開作業によって修正が必要と判定され、チェックリストに含まれていないプログラムとしての新規検出ファイル名と、プログラムのチェック結果を入出力部１５を介して受け取り、ステップＳ５で水平展開によって新規検出された修正の必要のあるプログラムファイルの名称が水平展開データベース１８内の変更影響表に反映され、ステップＳ６で全てのプログラムファイルに対する処理が終了したか否かが判定され、まだ終了していない場合にはステップＳ１以降の処理が繰り返される。

すなわちステップＳ１からステップＳ５までの処理では、プログラムファイルの１つについて図７で説明するチェックリストの各プログラムに対応する１行分に相当する処理が行われ、全てのプログラムファイルに対応する各行の処理が終了したか否かがステップＳ６で判定され、終了した場合には、ステップＳ７で構成管理部１０と連動して修正後のファイルが構成ファイルとして確定されて処理を終了する。

図４は、水平展開データベースに格納される変更影響関係情報、すなわち変更影響表の例の説明図である。この変更影響表には、不具合の問題の各番号に対応して、各プログラムの修正が行われた場合には“１”、行われなかった場合には“０”が、変更影響関係情報として格納されている。

図５は、上流工程設計書に対応する変更影響表の例である。図４におけると同様に、各問題の番号に対応してＢＤ書（基本設計書）０００１から、０００６までの修正が行われたか否かが格納されている。

図６は、図４で変更影響関係情報が格納されていた問題ＩＴ−０００５の次に発生したＩＴ−０００６の問題に対応して行われた影響度カウント評価の結果の説明図である。ここで、例えばユーザによって、問題番号ＩＴ−０００６の不具合の原因がプログラム０００３であることが特定されたものとして、この影響度カウント評価について説明する。

図４において、問題番号ＩＴ−０００１からＩＴ−０００５までの過去の５つの問題のうちで、今回新たに発生した問題ＩＴ−０００６の不具合の原因となったプログラム０００３の修正が行われた問題は、問題番号ＩＴ−０００１、ＩＴ−０００２、およびＩＴ−０００５であることがわかる。そこでこれら３つの問題に対応する変更影響関係情報を取り出し、それを各行、すなわち各プログラムファイルに対応して合計することによって、影響度カウント値が最も右側の列として求められる。この影響度カウント値は、今回新たに発生したＩＴ−０００６の不具合問題の原因として特定されたプログラム０００３と関連して、各プログラムファイルが過去の問題解決時に同時に修正された程度を反映するものと推定され、従って今回のＩＴ−０００６の問題に対応してチェックを行うべき程度を各プログラムに対して示すものと考えられる。従って、本実施例においては、この値が“０”でないプログラムを、プログラムの修正対象としてチェックすべきものとして処理を行う。

図７は、このチェック対象プログラムを示す水平展開チェックリスト画面の例であり、この画面は図２の表示部２０に表示されるものである。この例は図６で説明した問題番号ＩＴ−０００６に対応する水平展開チェックリストを示し、各プログラムファイル名のプログラムに対する影響度カウント値とチェック対象の欄は、図６で説明した影響度カウント評価の結果に対応して、本発明のソフトウェア変更トレーサビリティ管理装置のシステムによって自動出力される。この自動出力のうちでチェック対象の欄の●は、この問題の不具合原因として特定されたプログラムファイルを示し、○は図６で説明した影響度カウントのカウント値が“０”でないプログラムを示す。

図７のチェックリスト画面のうち、左側の３つの欄は、例えばユーザによってマニュアル入力されるものである。水平展開新規検出の欄の○は、システム自動出力結果とは独立にユーザによって行われた水平展開の結果、修正が行われるべきファイルとして新規に検出されたプログラムを示す。この新規検出されたプログラムは、図４で説明した過去の問題に対応するプログラムの修正結果を示す変更影響関係情報によっては検出されなかったチェック対象であり、このチェック対象に対しては当然プログラムの修正が行われるとともに、図８で説明するように、次の不具合問題が発生した時に、この新規検出結果を反映して図６で説明した影響度カウント評価が実施される。

すなわち、図７においてチェック対象としてシステムによって自動出力されたプログラム０００１、０００３、０００４、０００５のチェックと、その結果として必要となった修正の後にも不具合が解消されない場合に水平展開として他のプログラムのチェックが行われ、修正が必要なプログラムの検出が行われる。

マニュアル入力される右の２つの欄のうち、チェック結果はチェックの結果として修正が実施されたか否かを示すものであり、ここではプログラム０００１、０００３、０００４、および０００６について変更が行われたことが、０００５についてはチェックの結果修正が行われなかったことが示されている。チェック日の欄には、ユーザによって各プログラムのチェックが行われた日が入力されている。

図８は、次の不具合問題、すなわち問題番号ＩＴ−０００７に対応する水平展開チェックリスト画面のうちのシステム自動出力結果を示す。ここではこの問題の原因として特定されたプログラムがプログラム０００１であるものとする。ここで図４の変更影響関係情報を用いて影響度カウント評価が行われるが、図４の変更影響関係情報にはＩＴ−０００６に対応するデータが、プログラム０００１からプログラム０００６の各行に対して上から“１、０、１、１、０、１”の値がすでに格納されているものとする。

図８においてプログラム０００１が不具合原因として特定されていることから、図４においてプログラム０００１の修正が行われた問題としてＩＴ−０００１、ＩＴ−０００２、ＩＴ−０００５、およびＩＴ−０００６の列が取り出され、各行の値を横に合計することによってプログラム０００１から０００６に対する影響度カウント値として上から“４、０、４、４、１、１”が得られる。

ここでこの影響度カウント値は、図６におけるＩＴ−０００６に対する影響度カウント値に、図４にこの問題の発生時に新たに格納されたＩＴ−０００６に対応するデータを各行に対して加算したものと同じとなっているが、これは偶然である。この偶然は、ＩＴ−０００６の問題の不具合原因としてのプログラム０００３と、ＩＴ−０００７の不具合原因としてのプログラム０００１が修正された過去の問題が同一であることによって生じている。仮にＩＴ−０００７の不具合原因が、例えばプログラム０００２にあるとすれば、ＩＴ−０００７の問題に対応して実施される影響度カウント評価の結果は上から“０，２，０，０，０，２”となる。

以上のように第１の実施例によれば、過去の問題に対応して修正されたプログラムのデータを変更影響関係情報として蓄積することによって、新たに生じた問題に対応して修正対象としてチェックすべきプログラムが自動的に明らかになり、水平展開作業の労力を軽減できるとともに、この変更影響関係情報の内容が不完全であったとしても、独立に実施される水平展開作業の中で新たに検出されたプログラムの修正の結果が次の問題発生時点においてチェック対象プログラムの検出に利用されることとなる。

続いて本発明の第２の実施例について説明する。図９は、ソフトウェア変更トレーサビリティ管理装置の第２の実施例の構成と、第２の実施例におけるソフトウェア構成品修正制御処理の流れの説明図である。

図９において、図２におけると同じ構成ブロックについては同じ符号を付してある。図２と異なる構成ブロックとしては、構成品間関係データベース１４を管理する関係データベース管理部２２、問題管理部１７によって管理される問題処理表２３、ソフトウェア構成品の修正を制御する変更制御部２５、修正制御のためのフラグを格納する変更制御テーブル２６、ソフトウェア構成品としてのＢＤ書（基本設計書）３０、ＦＤ書（機能設計書）３１、ＤＤ書（詳細設計書）３２、ソースプログラム３３、およびロードモジュールとしての実行プログラム３４が示されている。

図９においてソフトウェア構成品の修正制御は、次の（１）から（８）の順序で実行される。
（１） 発生した不具合問題が、ユーザ、例えば不具合発見者によって問題処理表２３に記録され、不具合の原因が判明、すなわちバクプログラムファイルが特定された時点で、その問題処理票２３が問題管理部１７に渡される。
（２） 問題管理部１７によって、その不具合原因として特定されたプログラムの影響範囲、すなわち構成品間関係データベース１４内の該当箇所の問合せが関係データベース２２になされる。
（３） 関係データベース管理部２２が影響範囲としての該当箇所を問題管理部１７に返答する。
（４） 開発者（ユーザ）が後述するトレーサビリティｉｄを指定して、変更制御ユーザインターフェース部２６に該当箇所のソフトウェア構成品の修正許可を依頼し、変更制御部２５は変更制御テーブル２６内にその問題に対応するレコードを生成し、そのトレーサビリティｉｄに対応して、上流から下流までの一連のソフトウェア構成品に対する対象フラグを設定する。ここで対象フラグは、後述するように上流から下流までの各段階のソフトウェア構成品がそれぞれ存在し、修正を行うべきか否かのチェック対象となることを示すフラグである。
（５） ユーザから修正の依頼があったソフトウェア構成品に対する修正許可の問合せが変更制御ユーザインターフェース部１６から構成管理部１０、１１に行われる。
（６） 構成管理部から変更制御部２５に対して、ソフトウェア構成品の修正許可の問合せが行われる。変更制御部２５は、変更制御テーブル２６に格納されている実施フラグ、すなわちそのソフトウェア構成品の修正を行うべきか否かのチェックが行われたことを示すフラグの内容によって、修正依頼があったソフトウェア構成品の修正（変更）の可否を決定する。この判定においては、修正依頼のあったソフトウェア構成品の上流の構成品のチェックが行われていない場合、すなわち実施フラグの値が“０”である場合には修正を許可せず、上流のすべての構成品に対するチェックが終了、すなわち実施フラグが“１”となっている場合には修正が許可される。
（７） 修正可否の判定結果が、変更制御部２５から変更制御ユーザインターフェース部１６を介してユーザに通知され、修正が許可される場合には修正が要求された設計書、ソースプログラム、ロードモジュールなどの修正が行われ、その結果が変更制御テーブル２６の実施フラグの値に反映され、修正が許可されない場合には、ユーザに修正が依頼されたソフトウェア構成品の上流にあり、まだチェックが行われていないソフトウェア構成品の通知が行われる。
（８） 上流から下流までの一連のソフトウェア構成品の修正チェックが行われるまで、（４）から（７）が繰り返される。なお（４）において、対象フラグの変更制御テーブル２６への格納は、最初の修正許可依頼時のみに行われる。

なお図９において、変更制御テーブル２６は本発明の特許請求の範囲の請求項４におけるチェック実施フラグ格納手段に相当し、変更制御部２５は修正制御手段に相当する。
図１０は、第２の実施例における構成品間関係データベース１４の構築方式の説明図である。構成管理部１１は、上流工程から作成されるソフトウェア構成品を機能ブレイクダウンするにあたって、ＢＤ書３０、ＦＤ書３１、ＤＤ書３２、ソースプログラム、および実行プログラム毎に、対応する構成品の間の関係を次の図１１に示すように構成品間関係データベース１４に格納する。

図１１は、構成品間関係データベースの格納例である。構成品間関係データベース１４は、不具合問題が発生した場合にたどるべき一連のソフトウェア構成品が、上流から下流までの各段階に対応して、トレーサビリティｉｄに対応する各行に格納される形式となっている。このトレーサビリティｉｄは、不具合問題の発生に対して上流から下流までのチェックすべきソフトウェア構成品（関連箇所）をどのようにたどるべきかを示すものであり、どのトレーサビリティｉｄを用いるかは不具合問題が発生した時点でユーザによって決定されるものとする。

例えばソースプログラムとしてのプログラム０００１が不具合原因として特定された問題が発生すると、このプログラムが含まれるトレーサビリティｉｄ、図１１では３つのうちで、ユーザによって例えばα機能−００００１が選択されると、図１１の１番上の行に対応するレコードが変更制御テーブル２６に作成されることになる。

図１２は、変更制御テーブル２６の格納内容の例である。不具合問題の問題番号のそれぞれに対応して、選択されたトレーサビリティｉｄによって決定される上流から下流までのソフトウェア構成品、すなわち図１１で説明した各行のソフトウェア構成品に対応する対象フラグと実施フラグの値が格納されている。

この状態で変更制御部２５が、問題番号ＩＴ−０００６に対応してソースプログラムの修正可否の問合せを受けた場合には、ソースプログラムのすぐ上流のＤＤ書の実施フラグの値が“０”であるために、ＤＤ書の修正の必要性のチェックが行われていないことになり、変更制御ユーザインターフェース部１６を介してユーザに対して修正の不許可が通知され、ＤＤ書の修正チェックを先に実施するように要請が行われる。

また対象フラグの値は、前述のようにそのソフトウェア構成品が存在し、修正の必要性のチェックを行う必要があるかを示すものであり、例えばＩＴ−０００７の問題に対応して選択されたα機能−００００５においては最も上流のＢＤ書の対象フラグは“０”となっている。すなわち関連のあるＢＤ書が、図１１に示すように存在しないため、そのすぐ下流側のＦＤ書の修正はＢＤ書の実施フラグの値に関係なく実施できることになる。

このように第２の実施例においては、トレーサビリティｉｄに対応してソフトウェア構成品間の関係をたどりながらソフトウェア変更処理が行われるが、上流の構成品からの修正チェックしか受付けない仕組みが実現され、ソフトウェア変更トレーサビリティの確保が可能となる。

本発明のソフトウェア変更トレーサビリティ管理装置の原理構成ブロック図である。 第１の実施例におけるソフトウェア変更トレーサビリティ管理装置の構成ブロック図である。 第１の実施例におけるソフトウェア変更トレーサビリティ管理処理のフローチャートである。 水平展開データベースにおける変更影響表の例である。 上流工程における変更影響表の例である。 図４の変更影響表を利用した影響度カウント評価の説明図である。 水平展開チェックリスト画面の例である。 新たな問題が発生した時の水平展開チェックリスト画面のシステム自動出力結果の例である。 第２の実施例におけるソフトウェア変更トレーサビリティ管理装置の構成と、ソフトウェア変更制御の流れを示す図である。 構成品間関係データベースの構築方式の説明図である。 構成品間関係データベースの格納内容の例を示す図である。 変更制御テーブルの格納内容の例を示す図である。

符号の説明

１、７ ソフトウェア変更トレーサビリティ管理装置
２ 影響関係情報記憶手段
３ 影響度評価手段
４ 表示手段
５ インターフェース手段
８ チェック実施フラグ格納手段
９ 修正制御手段
１０、１１ 構成管理部
１２ 設計書生成部
１３ 対応情報抽出部
１４ 構成品間関係データベース
１５ 入出力部
１６ 変更制御ユーザインターフェース部
１７ 問題管理部
１８ 水平展開データベース
１９ 影響度評価部
２０ 表示部
２２ 関係データベース管理部
２３ 問題処理表
２５ 変更制御部
２６ 変更制御テーブル
３０ ＢＤ書（基本設計書）
３１ ＦＤ書（機能設計書）
３２ ＤＤ書（詳細設計書）
３３ ソースプログラム
３４ ロードモジュール（実行プログラム）

Claims (5)

1. ソフトウェア変更時のソフトウェア構成品間の整合性を確保するソフトウェア変更トレーサビリティ管理装置であって、
   ソフトウェア変更を生じた問題毎に、該問題に対処するために修正されたソフトウェア構成品をソフトウェア変更影響関係情報として記憶する影響関係情報記憶手段と、
   新たにソフトウェア変更を行うべき問題が発生した時、該問題発生の原因として特定されたソフトウェア構成品が修正された過去の問題への対処にあたって、前記影響関係情報記憶手段に記憶されている各ソフトウェア構成品が同時に修正された問題の数を、該特定されたソフトウェア構成品を含む各ソフトウェア構成品の影響度として評価する影響度評価手段と、
   該評価された影響度に対応して、修正の必要性のチェックを行うべきソフトウェア構成品の名称を表示する表示手段とを備えることを特徴とするソフトウェア変更トレーサビリティ管理装置。
2. 前記表示手段によって表示されたソフトウェア構成品以外のソフトウェア構成品であって、前記新たに発生した問題に対応して修正を行うべきソフトウェア構成品の名称を外部から受け取るインタフェース手段をさらに備えることを特徴とする請求項１記載のソフトウェア変更トレーサビリティ管理装置。
3. 前記影響関係情報記憶手段が、前記外部から受け取ったソフトウェア構成品を含め、前記新たに発生した問題に対処するために修正が行われたソフトウェア構成品を記憶することを特徴とする請求項２記載のソフトウェア変更トレーサビリティ管理装置。
4. ソフトウェア変更時のソフトウェア構成品間の整合性を確保するソフトウェア変更トレーサビリティ管理装置であって、
   ソフトウェア変更を行うべき問題に対応して修正の必要性をチェックすべきソフトウェア構成品であって、上流側から下流までの各段階の関連のある一連のソフトウェア構成品に対応して、各ソフトウェア構成品のチェックが行われたか否かを示すチェック実施フラグを格納するチェック実施フラグ格納手段と、
   外部からのソフトウェア構成品の修正要求に対応して、該チェック実施フラグ格納手段の格納内容を用いて、該修正が要求されたソフトウェア構成品の上流側にある全てのソフトウェア構成品がチェック済みであると判定した時にのみ、該要求されたソフトウェア構成品の修正を許可する修正制御手段とを備えることを特徴とするソフトウェア変更トレーサビリティ管理装置。
5. 前記実施フラグ格納手段が、前記上流側から下流側までの段階の数が既知である時、各段階におけるソフトウェア構成品が存在し、前記チェックの対象となることを示す対象フラグをさらに格納するとともに、
   前記修正制御手段が、該対象フラグの値に応じて、前記要求されたソフトウェア構成品の上流側のソフトウェア構成品が前記チェックの対象とならないと判定した時、該要求されたソフトウェア構成品の修正を許可することを特徴とする請求項４記載のソフトウェア変更トレーサビリティ管理装置。

Images