JP2011175446A - 要件・バグレポート処理システム及びその方法 - Google Patents

要件・バグレポート処理システム及びその方法 Download PDF

Info

Publication number
JP2011175446A
JP2011175446A JP2010038866A JP2010038866A JP2011175446A JP 2011175446 A JP2011175446 A JP 2011175446A JP 2010038866 A JP2010038866 A JP 2010038866A JP 2010038866 A JP2010038866 A JP 2010038866A JP 2011175446 A JP2011175446 A JP 2011175446A
Authority
JP
Japan
Prior art keywords
requirement
value
bug report
bug
line
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2010038866A
Other languages
English (en)
Inventor
Fumio Tanaka
史生 田中
Tsuneo Kikuchi
恒男 菊池
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2010038866A priority Critical patent/JP2011175446A/ja
Publication of JP2011175446A publication Critical patent/JP2011175446A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Stored Programmes (AREA)

Abstract

【課題】
ソースコードの指定行の全変更履歴を検索し、関連する要件・バグレポートを出力することにより、複数回修正された行に対して、その変更以前の修正および関連する要件・バグレポートを追跡する。
【解決手段】
要件・バグレポート処理システムは、ソースコードの特定の行を指定する入力装置と、処理装置でプログラムを実行することで、入力装置から指定されたソースコードの過去のリビジョンから、行を変更した全てのリビジョンを行の変更前後の編集距離を基に検出する第1処理手段と、リビジョンに関連する要件・バグレポートを検出する第2処理手段と、第2処理手段によって処理された要件・バグレポートを出力表示する出力装置を有する。
【選択図】図1

Description

本発明は、要件・バグレポート処理システム及びその方法に係り、特にソフトウェアのソースコードの指定行における変更に関連する要件・バグレポートを検索して表示するシステムに関するものである。
従来、ソフトウェア開発において、要件・バグレポートの管理情報とソースコードの構成管理情報を関連付けることで、トレーサビリティの確保を実現している。例えば、要件・バグレポートの管理情報内に、関連するソースコード修正時の構成管理の履歴番号を登録する。また、作成・修正を行ったソースコードを構成管理システムへ登録する際に、関連する要件・バグレポートを示す管理番号情報をコミットメッセージに付記などすることで関連付けを行う。
これにより、要件・バグレポートから構成管理システム情報の履歴番号が追跡でき、そこから更にソースコード修正箇所の追跡ができる。また構成管理情報内のコミットメッセージからその関連する要件・バグレポートの管理番号を探すことができ、そこから修正理由となる要件・バグレポートの追跡が可能となる。
一般的に、要件・バグレポートからのソースコード修正箇所の追跡が行われている。例えば、特許文献1には、プログラム修正情報をプログラムソースとは別に登録・管理しておき、このプログラム修正情報の一覧を表示し、一覧からプログラム修正情報を指定することにより、該当のプログラムソース行に表示することを可能とするプログラム修正情報管理方法が開示されている。
ソースコードから要件・バグレポートを追跡可能なシステムとして、例えば、非特許文献1に開示されたような、TFS (Team Foundation Server)が知られている。TFSはソースコードの各行について、その行が作成・修正された最後の変更セットと更新者、更新日時を提示する。変更セットとは、構成管理の特定の履歴番号の情報であるので、その履歴番号のコミットメッセージを探し、その内容から要件・バグレポートの管理番号を探し、ソースコードのある行が変更された理由となる要件・バグレポートを追跡することを可能としている。
しかし、その行が作成・修正された最後の変更セットを提示するだけであるので、複数回修正された行に対して、その変更セット以前の修正および関連する要件・バグレポートを追跡できないという問題がある。
特開2000−112743号公報
Visual Studio 2008 Team Foundation Server http://www.microsoft.com/japan/msdn/vstudio/2008/product/vsts/tfs.aspx V.I. Levenshtein、「Binary codes capable of correcting deletions, insertions, and reversals」、1966年、Soviet Physics Doklady 10、pp.707−710
本発明は、ソースコードの指定行の全変更履歴を検索し、関連する要件・バグレポートを出力することにより、複数回修正された行に対して、その変更以前の修正および関連する要件・バグレポートを追跡できるようにするものである。
本発明に係る要件・バグレポート処理システムは、好ましくは、ソフトウェアのソースコードの指定行における変更に関連する要件・バグレポートを検索して出力装置に出力する要件・バグレポート処理システムであって、
ソースコードの特定の行を指定する入力装置と、処理装置でプログラムを実行することで実現される、該入力装置から指定されたソースコードの過去のリビジョンから、行を変更した全てのリビジョンを行の変更前後の編集距離を基に検出する第1処理手段と、処理装置でプログラムを実行することで実現される、該リビジョンに関連する要件・バグレポートを検出する第2処理手段と、該第2処理手段によって処理された要件・バグレポートを可視的に出力する出力装置とを有することを特徴とする要件・バグレポート処理システムとして構成される。
好ましい例によれば、前記第1処理手段は、リビジョンの検出基準として行の変更前後の長さと編集距離を用いてリビジョンを検出する。
また、好ましくは、前記第2処理手段で検出された要件・バグレポートの一覧を表示器に表示するものであって、該第2処理手段は、該表示の際にコード変更の種類により、表示を変更する。
また、好ましくは、前記第2処理手段は、要件・バグレポートの一覧を表示器に表示する際に、仕様変更かバグ修正かにより表示を変更する。
また、好ましくは、上記要件・バグレポート処理システムは、該入力装置から指定される、ソースコード名と2つのリビジョン番号に応じて、リビジョン間の差分情報を出力するソースコード構成管理システムと、要件・バグレポートの管理番号、タイトル、機能追加のレポートか又はバグ修正のレポートかのいずれかを指定する種別に関する情報を少なくとも格納する要件・バグレポートDBを更に有し、
前記第2処理手段は、該入力装置から指定されたレビジョン番号と等しいビジョン番号におけるコミットメッセージを該ソースコード構成管理システムから取得し、
該コミットメッセージが有する要件・バグレポートの管理番号を基に、該要件・バグレポートDBから、該当する要件・バグレポートのタイトル、種別を取得し、
該出力装置は、該第2処理手段によって取得された、ある要件・バグレポートの、該リビジョン番号、管理番号、タイトルの一覧を出力して表示する。
また、本発明に係る要件・バグレポート処理方法は、好ましくは、処理装置でプログラムを実行することにより、ソフトウェアのソースコードの指定行における変更に関連する要件・バグレポートを検索して出力装置に出力する処理方法であって、
該処理装置は、入力装置から指定されたソースコード名、リビジョン番号、2つの行の行番号を受け取るステップと、
該処理装置は、要件・バグレポートの管理番号を含むコミットメッセージを格納するDBから、該ソースコード名と2つのリビジョン番号に応じた、リビジョン間の差分情報を取得するステップと、
該処理装置は、該差分情報を解析して、要件・バグレポートの管理番号、タイトル、機能追加のレポートか又はバグ修正のレポートかのいずれかを指定する種別に関する情報を少なくとも格納する要件・バグレポートDBから、該当する要件・バグレポートのタイトル、種別を取得するステップと、
該出力装置は、取得された、ある要件・バグレポートの、該リビジョン番号、管理番号、タイトルの一覧を出力して表示するステップと
を有することを特徴とする要件・バグレポート処理方法として構成される。
本発明によれば、ソースコードの指定行について全変更履歴を検索して、該当するリビジョンのコミットメッセージ内に記述された関連する要件・バグレポートの管理番号情報から、指定行の作成・修正に関連する要件・バグレポートを出力することができる。これにより、複数回修正された行に対して、その変更以前の修正および関連する要件・バグレポートを追跡することができる。
一実施例による要件・バグレポート表示システムの構成図。 差分情報の例を示す図。 コミットメッセージの例を示す図。 要件・バグレポートDBの構成例を示す図。 テーブルDの例を示す図。 テーブルXの例を示す図。 テーブルYの例を示す図。 テーブルAの例を示す図。 テーブルBの例を示す図。 テーブルCの例を示す図。 テーブルRの例を示す図。 テーブルSの例を示す図。 テーブルTの例を示す図。 テーブルPの例を示す図。 テーブルQの例を示す図。 テーブルGの例を示す図。 要件・バグレポート検出機能102による処理フローを示す図。 差分情報を解析してテーブルA、B、Cに格納する処理(1708)のフローを示す図。 指定行を含む差分ブロックのIDを取得する処理(1711)のフローを示す図。 指定行のコードを取得する処理(1713)のフローを示す図。 指定行のコードに対応する変更前リビジョンにおけるコードの行番号を取得する処理(1715)のフローを示す図。 指定行の行番号に対応する変更後リビジョンの行番号を取得する処理(1719)のフローを示す図。 リビジョンに関連する要件・バグレポートを検出して表示する処理(1724)のフローを示す図。 リビジョンのコミットメッセージに付記された要件・バグレポートの管理番号を取得する処理のフローを示す図。 指定行のコードに対応する変更前リビジョンにおけるコードの行番号を変更前後のコードの長さの平均値と編集距離を用いて取得する処理のフローを示す図。 要件・バグレポートを検出しソースコードの変更種別によって分類して表示する処理のフローを示す図。 指定行のコードに対応する変更前リビジョンにおけるコードの行番号と変更種別を取得する処理(2614)のフローを示す図。 コード行を分割して変更種別を解析する処理(2706)のフローを示す図。 各変更種別をもとに変更種別を決定する処理(2716)のフローを示す図。 リビジョンに関連する要件・バグレポートを検出しソースコードの変更種別によって分類して表示する処理(2623)のフローを示す図。 変更種別によって要件・バグレポートを分類して表示する処理(3016)のフローを示す図。 リビジョンに関連する要件・バグレポートを検出しその種別によって分類して表示する処理のフローを示す図。 要件・バグレポートの種別によって要件・バグレポートを分類して表示する処理(3216)のフローを示す図。 テーブルKの例を示す図。 テーブルEの例を示す図。 テーブルFの例を示す図。 テーブルHの例を示す図。 テーブルIの例を示す図。 テーブルJの例を示す図。 テーブルLの例を示す図。 テーブルMの例を示す図。 テーブルUの例を示す図。 テーブルVの例を示す図。 検出した要件・バグレポート一覧の表示例を示す図。 検出した要件・バグレポートをソースコードの変更種別ごとに分類した一覧の表示例を示す図。 検出した要件・バグレポートをその種別ごとに分類した一覧の表示例を示す図。 テーブルWの例を示す図。
以下、図面を参照して、本発明の実施形態について説明する。
図1は、一実施例による要件・バグレポート表示システムの構成を示す。このシステムは、ハードウェアとして、サーバ装置101と、入力器を持つ入力装置106と、表示器を持つ出力装置107を有して構成される。
サーバ装置101は、ユーザが指定したソースコード名・リビジョン番号・行番号セットから関連する要件・バグレポート検出機能102と、ソースコード構成管理システム104と、要件・バグレポートの管理情報が格納された要件・バグレポートDB105を有する。入力装置106は、ユーザによりソースコード名、リビジョン番号、行番号セットが指定される。出力装置107は、要件・バグレポート検出機能102が検出した要件・バグレポートを表示する。なお、図示していないが、サーバ装置101は処理装置(プロセッサ)及びメモリ、HDD(ハードディスク装置)等の外部記憶装置を備え、処理装置で所定のプログラムを実行することにより、上記要件・バグレポートの検出機能102や構成管理システム104を実現し、かつ後述するフローチャートに示す処理動作を行う。
ソースコード構成管理システム104と、要件・バグレポート検出機能102はそれぞれ別のプログラムで実現される機能であり、従来から使用されているソースコード構成管理システム104で収集された構成管理情報を、本発明に特徴的な要件・バグレポート検出機能102が利用して、特徴的な処理を実行することで効果を発揮するものである。
ソースコード構成管理システム104は、構成管理情報を格納する構成管理情報DB(リポジトリということがある)103を持ち、要件・バグレポート検出機能102からの問い合わせに対して構成管理情報を返す。例えば、構成管理システム104としては、SubverionというOSS(Open Source Software)がある。ソースコード構成管理システム104はソースコード名と2つのリビジョン番号を指定することにより、リビジョン間の差分情報を出力する機能を持つ。差分情報の構成例を図2に示す。また、ソースコード名とリビジョン番号を指定することにより、コミットメッセージを出力する機能を持つ。コミットメッセージの構成例を図3に示す。
図2を参照するに、差分情報201は、ファイルについて2つのリビジョン間で何行目に変更があるかを示す行番号の行、変更前のリビジョンにおけるコードの内容を示す行、変更後のリビジョンにおけるコードの内容を示す行、その他の行からなる。より詳しく言えば、行番号の行は数字(図示では、1,10c1)から始まる。変更前のリビジョンにおけるコードの内容を示す行は、<記号から始まる。変更後のリビジョンにおけるコードの内容を示す行は、>記号から始まる。その他の行は、数字、<記号、>記号以外の文字から始まる。行番号を示す行、変更前コードの内容を示す行、変更後コードの内容を示す行を1つのブロックとして、1つの差分情報を示す。行番号の行から次の行番号の行までか、次の行番号の行がない場合は最終行までを差分ブロック202とする。
図示の例で、< function startTest() { から< })(); までの10行は変更前のリビジョンにおける1ブロックを示し、> function startTest (filename, rev, linenums) {
は、変更後のリビジョンにおける1ブロックを示す。また、行番号13c4の、< while (rev > 1) { は変更前のリビジョンにおける1ブロックを示し、> for (; rev > 1; rev--) { は変更後のリビジョンにおける1ブロックを示す。
図3のコミットメッセージの例を参照する。コミットメッセージ301は、ソースコードを構成管理情報DB103に格納する度に作成されるメモであり、それぞれ1行で表される。コミットメッセージ301は、先頭にあるコミットについての説明、その後ろにある区切り記号#、続いて関連する要件・バグレポートの管理番号、をコンマ区切りで列挙する。区切り記号#が存在しない場合、そのコミットメッセージには関連する要件・バグレポートの管理番号は存在しない。ここで、要件・バグレポートは、ソースコード構成管理システム104のプログラムの実行により、ソースコードを修正した後のテスト実行時にバグが検出される度に、作成される。その時に、図4に示すような、管理番号やタイトル等を含む要件・バグレポートのエントリが作成される。
図4は、要件・バグレポートDBの構成例を示す。
要件・バグレポートの各エントリは、管理番号401、タイトル402、機能追加のレポートか又はバグ修正のレポートかのいずれかを指定する種別403、及びその他の情報として、登録者、担当者等の情報から構成される。
次に、図5〜図16を参照して、要件・バグレポートの作成、表示の処理中に使用されるテーブルの構成について説明する。これらのテーブルは、処理の途中に一時的に作成されるものもあり、各テーブルはサーバ装置101のメモリに保持される。
図5は、差分情報201を格納するテーブルDを示す。テーブルDは、差分情報列501を持ち、差分情報列の各行には差分情報201が1行ずつ格納される。
図6は、行番号を格納するテーブルXを示す。テーブルXは行番号列601を持ち、行番号列の各行には、入力装置106から指定された行番号が1つずつ格納される。
図7は、行番号を一時的に格納するテーブルYを示す。テーブルYは処理中に使用されるものであり、行番号列701の各行には行番号が1つずつ格納される。
図8はテーブルAを示す。テーブルAは、テーブルDに格納された情報を基に差分ブロック202の開始と終了の行番号を格納する。各エントリは、ID列801、変更前開始行番号列802、変更前終了行番号列803、変更後開始行番号列804、変更後終了行番号列805、等の情報から構成される。ID列の各行には差分ブロック202を識別するために重複のない数値が格納される。変更前開始行番号列、変更前終了行番号列、変更後開始行番号列、変更後終了行番号列の各行には数値が格納される。
図9はテーブルBを示す。テーブルBは、テーブルDに格納された情報を基に差分ブロック202ごとに変更前(即ちテーブルDの<記号)のソースコードのみを選択して格納する。テーブルBはID列901、変更前コード列902を持つ。ID列の各行にはテーブルAのID列801に格納された数値と対応する数値が格納され、変更前のソースコードが含まれる差分ブロック202を識別可能とする。変更前コード列の各行には差分ブロック202の<記号で始まる行の3文字目以降が格納される。
図10に示す、テーブルCは、テーブルDに格納された情報を基に差分ブロック202ごとに変更後(即ちテーブルDの>記号)のソースコードのみを選択して格納する。テーブルCはID列1001、変更後コード列1002を持つ。ID列の各行にはテーブルAのID列801に格納された数値と対応する数値が格納され、変更後のソースコードが含まれる差分ブロック202を識別可能とする。変更後コード列の各行には差分ブロック202の>記号で始まる行の3文字目以降が格納される。
図11は、リビジョン番号を格納するテーブルRを示す。テーブルRは、差分のあるレビジョンのみを集めたテーブルであり、リビジョン番号列1101の各行には、レビジョン番号の新しい順から遡ってリビジョン番号が1つずつ格納される。
図12は、差分ブロック202における変更前の各行のソースコードと変更後の指定行番号のソースコードとの編集距離を格納するテーブルSを示す。テーブルSはIndex列1201、編集距離列1202を持つ。Index列の各行には変更前のソースコードの何行目についての編集距離であるかを示す数値が格納される。なお、編集距離列の各行に格納される編集距離の概念は、非特許文献2(V.I. Levenshtein、「Binary codes capable of correcting deletions, insertions, and reversals」、1966年、Soviet Physics Doklady 10、pp.707−710)に記載されており、2つの文字列がどの程度異なっているかを表す数値である。一方の文字列からもう一方の文字列に変換するために必要な、文字の挿入・削除・置換の最小回数により表される。
図13は、テーブルSの編集距離列1202の値が最小の行を格納するテーブルTを示す。テーブルTはIndex列1301を持つ。
図14は、要件・バグレポートの管理番号を格納するテーブルPを示す。テーブルPは管理番号列1401を持ち、管理番号列の各行には要件・バグレポートの管理番号が1つずつ格納される。
図15は、要件・バグレポートの管理番号を一時的に格納するテーブルQを示す。テーブルPは管理番号列1501を持ち、管理番号列の各行には要件・バグレポートの管理番号が1つずつ格納される。
図16は、リビジョン番号と関連する要件・バグレポートの情報を格納するテーブルGを示す。テーブルGはリビジョン番号列1601、管理番号列1602、タイトル列1603を持つ。リビジョン番号列の各行にはリビジョン番号が1つずつ格納される。管理番号列の各行には要件・バグレポートの管理番号が1つずつ格納される。タイトル列の各行には要件・バグレポートのタイトルが格納される。
次に、図17を参照して、要件・バグレポート検出機能102による、指定されたソースコード名、リビジョン番号、行番号セットから、関連する要件・バグレポートを表示する処理フローについて説明する。
まず、ユーザにより入力装置106から指定されたソースコード名を受け取り、変数Srcに格納する(1701)。同様に、ユーザにより指定されたリビジョン番号を受け取り、変数Revに格納する(1702)。また、ユーザにより指定された行番号セットを受け取り、テーブルXに格納する(1704)。次に、Revの値が1より大きいかを確認する(1705)。確認の結果、1よりも大きい場合(1706)、リポジトリ103から、Srcを対象に、RevとRev−1との間の差分情報を取得し、テーブルDに格納する(1707)。差分情報を解析し、解析結果をブロックに分割して、テーブルA、テーブルB、テーブルCに格納する(1708)。テーブルXから行番号を1つ取り出し、変数Nに格納する(1709)。Nに値が格納されている場合(1710)、Nが含まれる差分ブロックのIDをテーブルAから取得し変数IDに格納する(1711)。IDに値が格納されている場合(1712)、IDとNをもとに、テーブルCからN行目のコードを取得し、変数Codeに格納する(1713)。Codeに値が格納されている場合(1714)、テーブルBからRev−1においてCodeに対応するコードの全ての行の行番号を取得し、テーブルYに格納する(1715)。
続いて、テーブルRにRev−1を格納し、テーブルXの次の1行に進む(1716)。テーブルCからN行目のコードを取得し、変数Codeに格納した後に、Codeに値が格納されていない場合(1717)、テーブルXの次の1行に進む。Nが含まれる差分ブロックのIDをテーブルAから取得し変数IDに格納した後に、IDに値が格納されていない場合(1718)、テーブルBからRev−1においてRevのN行目に対応する行の行番号を取得し、テーブルYに格納し(1719)、テーブルXの次の1行に進む。Nの値が存在しない場合(1720)、テーブルYから全ての行番号を取り出し、テーブルXに格納する(1721)。その後、Revの値をRev−1に変更し(1722)、次の差分情報の解析に進む。
上記Revの値の確認の結果、Revの値が1以下であった場合(1723)、テーブルRに格納されたリビジョン番号をもとに、要件・バグレポートを出力装置107に出力して表示器に表示する(1724)。
次に、図18を参照して、差分情報を解析してブロックに分割しテーブルA、B、Cに格納する処理(1708)について詳細に説明する。
まず、ブロックを識別するためのIDを初期化する(1801)。差分情報をテーブルDに格納する(1802)。次にテーブルDから1行読み込み、変数Lineに格納する(1803)。Lineに値が格納されているかを確認し、Lineに値が格納されている場合には(1804)、Lineの1文字目の種類を確認する(1829)。その結果、数字であった場合(1805)、IDを更新する(1806)。次に、Line内に含まれるaかcかdのいずれか1文字より前の部分を取り出し、変数Strに格納する(1807)。
次に、Strにコンマが含まれるかを確認し(1808)、含まれる場合には(1809)コンマの前後をそれぞれ変数PreSと変数PreEに格納する(1810)。一方、含まれない場合には(1811)Strの値を変数PreSと変数PreEに格納する(1812)。次に、Line内に含まれるaかcかdのいずれか1文字より後の部分を取り出し、変数Strに格納する(1813)。Strにコンマが含まれるかを確認し(1814)、含まれる場合には(1815)コンマの前後をそれぞれ変数CurSと変数CurEに格納する(1816)。一方、含まれない場合には(1817)Strの値を変数CurSと変数CurEに格納する(1819)。IDおよび、PreSを変更前開始行として、PreEを変更前終了行として、CurSを変更後開始行として、CurEを変更後終了行として、テーブルAに格納し(1820)、テーブルDの次の1行に進む。
テーブルDから1行読み込み、変数Lineに格納した後に、Lineの1文字目を確認して、>記号であった場合には(1824)、Lineの3文字目以降を変数Lに格納する(1825)。IDおよび、変更後コードとしてLをテーブルCに格納し(1826)、テーブルDの次の1行に進む。テーブルDから1行読み込み、変数Lineに格納した後に、Lineの1文字目を確認して、<記号であった場合には(1821)、Lineの3文字目以降を変数Lに格納する(1822)。そして、IDおよび、変更前コードとしてLをテーブルBに格納し(1823)、テーブルDの次の1行に進む。
テーブルDから1行読み込み、変数Lineに格納した後に、Lineの1文字目を確認してその他の文字であった場合(1827)、テーブルDの次の1行に進む。テーブルDから1行読み込み、変数Lineに格納した後に、Lineに値が格納されていない場合(1828)、処理を終了する。
図19は、RevのN行目が含まれる差分ブロックのIDを取得して変数IDへ格納する処理1711の詳細を示す。まず、テーブルAから1行読み込む(1901)。読み込める場合(1902)、Nの値が変更後開始行番号列の値以上かつ変更後終了行番号列の値以下の範囲に含まれるかを確認する(1903)。含まれる場合(1904)、ID列の値をID変数とし(1905)、処理を終了する。含まない場合(1906)、テーブルAの次の1行に進む。テーブルAから行を読み込めない場合(1907)、処理を終了する。
図20は、RevのN行目のコードを取得してCodeへ格納する処理(1713)の詳細を示す。
まず、テーブルAからID列の値がIDの値と等しい行を読み込み(2001)、この行の変更後開始行番号列の値をNの値から引いた結果を変数Mに格納する(2002)。次に、テーブルCから1行読み込む(2003)。読み込める場合(2004)、ID列の値がIDの値と等しいかを確認する(2005)。等しい場合(2006)、Mの値が0であるかを確認する(2007)。その結果、0である場合(2008)、コード列の値を変数Codeに格納し(2009)、処理を終了する。
一方、0でない場合(2010)、Mの値をM−1に変更し(2011)、テーブルCの次の1行に進む。ID列の値がIDの値と等しくない場合(2012)、テーブルCの次の1行に進む。テーブルCから行を読み込めない場合(2013)、処理を終了する。
図21は、Rev−1においてRevのN行目のCodeに対応する全てのコードの行番号を取得してテーブルYに格納する処理(1715)の詳細を示す。
まず、変数Indexの値を0に初期化する(2101)。テーブルBから1行読み込む処理において(2102)、1行を読み込める場合(2103)、ID列の値がIDの値と等しいかを確認する(2104)。その結果、等しい場合(2105)、変更前コードとCodeの値との編集距離を計算し(2106)、Indexと編集距離をテーブルSに格納する(2107)。次に、Indexの値をIndex+1に変更し(2108)、テーブルBの次の1行に進む。一方、ID列の値がIDの値と等しくない場合(2109)、テーブルBの次の1行に進む。
テーブルBから1行を読み込めない場合(2110)、テーブルSに格納されている行の中から編集距離が最小の行を全て取得し(2111)、編集距離が一定以下であるかを確認する(2112)。その結果一定以下である場合(2113)、取得した行のIndex列をテーブルTに格納する(2114)。その後、テーブルTから1行読み込む処理において(2115)、1行を読み込める場合(2116)、変数Countの値を0に初期化する(2117)。次に、テーブルAから1行読み込み(2118)、ID列の値がIDの値と等しいかを確認する(2119)。その結果等しい場合(2120)、テーブルTから読み込んだ行のIndex列の値とCountの値が等しいことを確認する(2128)。
その結果、読み込んだ行のIndex列の値とCountの値が等しい場合(2121)、Index列の値にテーブルAの変更前開始番号列の値を加えた結果をテーブルYに格納し(2122)、テーブルTの次の1行に進む。Index列の値とCountの値が等しくない場合(2123)、Countの値をCount+1に変更し(2124)、テーブルAの次の1行に進む。ID列の値がIDの値と等しくない場合(2125)、テーブルAの次の1行に進む。テーブルTから行を読み込めない場合(2126)、処理を終了する。テーブルSに格納されている行の中から編集距離が最小の行を全て取得し、編集距離が一定より大きい場合(2127)、処理を終了する。
図22は、Rev−1においてRevのN行目に対応する行番号を取得してテーブルYに格納する処理(1719)の詳細を示す。
まず、テーブルAから1行読み込む(2201)。読み込めた場合(2202)、Nの値が変更後開始行番号列の値より小さいかを確認する(2203)。確認の結果、小さい場合(2204)、変更後開始行番号列の値からNの値を引き、さらにその結果を変更後開始行番号列の値から引いた結果をテーブルYに格納し、処理を終了する(2205)。Nの値が変更後開始行番号列の値以上の場合(2206)、ID列の値を変数IDに格納し(2207)、テーブルAの次の1行に進む。
一方、テーブルAから行を読み込めない場合(2208)、テーブルAからID列の値がIDの値と等しい行を読み込む(2209)。読み込めた場合(2210)、Nの値から変更後終了行番号列の値を引き、さらにその結果を変更前終了行番号列の値に加えた結果をテーブルYに格納し(2211)、処理を終了する。テーブルAからID列の値がIDの値と等しい行を読み込めない場合(2212)、処理を終了する。
図23は、要件・バグレポートDBから関連する要件・バグレポートを取得して表示する処理(1724)の詳細を示す。
まず、テーブルYから1行読み込む(2301)。読み込めた場合(2302)、リビジョン番号列の値を変数Revに格納する(2303)。次に、リポジトリからRevの値と等しいリビジョン番号におけるコミットメッセージを取得し、変数Msgに格納する(2304)。Msgから要件・バグレポートの管理番号を取得し、テーブルPに格納する(2305)。テーブルPから1行読み込み、管理番号列の値を変数Nに格納する(2306)。Nに値が格納されている場合(2307)、要件・バグレポートDBからNの値と等しい管理番号の要件・バグレポートのタイトルを取得し、変数Titleに格納する(2308)。Titleに値が格納されている場合(2309)、リビジョン番号としてRev、管理番号としてN、タイトルとしてTitleをテーブルGに格納し(2310)、テーブルPの次の1行に進む。一方、Titleに値が格納されていない場合(2311)、テーブルPの次の1行に進む。テーブルPから行を読み込めない場合(2312)、テーブルYの次の1行に進む。
テーブルYから行を読み込めない場合(2320)、テーブルGにデータが格納されているかを確認する(2313)。確認の結果、データが格納されている場合(2314)、テーブルGに格納されているリビジョン番号、管理番号、タイトルの一覧を出力装置の表示器に表示する(2315)。リビジョン番号、管理番号、タイトルの一覧の表示例を図44に示す。管理番号を入力装置から取得し、変数Nに格納する(2316)。続いて、要件・バグレポートDBからNの値に等しい管理番号の要件・バグレポートを表示する(2317)。テーブルGにデータが格納されていない場合(2318)、指定行の変更に関連する要件・バグレポートはないことを表示する(2319)。
図24は、コミットメッセージに記載された要件・バグレポートの管理番号を取得する処理(2305)を示す。
まず、Msgの値に#記号が含まれるかを確認する(2401)。その結果、含まれる場合(2402)、Msgの値から#記号より後の部分を取得し、変数Strに格納する(2403)。次に、Strの値にコンマが含まれるかを確認し(2404)、その結果、コンマが含まれる場合(2405)、Strの値をコンマで分割し、テーブルQに格納する(2406)。コンマが含まれない場合(2411)、Strの値をテーブルQに格納する(2412)。その後、テーブルQに格納されているデータが全て数字であるかを確認し(2407)、その結果、全て数字である場合(2408)、テーブルQから全データを取り出してテーブルPに格納する(2409)。一方、数字でないデータがあった場合(2410)、処理を終了する。上記Msgに#記号が含まれない場合(2413)、処理を終了する。
図25は、図21の処理の代案例を示す。
Rev−1においてCodeに対応する全行番号を取得しテーブルYに格納する処理(1715)の処理内容として、図21の処理は編集距離のみを用いる例であるが、図25の例は、変更前後のコードの長さと編集距離を用いる例である。
まず、変数Indexの値を0に初期化する(2501)。テーブルBから1行読み込む(2502)。読み込める場合(2503)、ID列の値がIDの値と等しいかを確認する(2504)。その結果等しい場合(2505)、変更前コードとCodeの値との編集距離を計算し、変更前コードの長さとCodeの値の長さとの平均値で編集距離を割った値を変数Rateに格納する(2506)。IndexとRateをテーブルEに格納する(2507)。次に、Indexの値をIndex+1に変更し(2508)、テーブルBの次の1行に進む。ID列の値がIDの値と等しくない場合(2509)、テーブルBの次の1行に進む。
テーブルBから行を読み込めない場合(2510)、テーブルEに格納されている行の中からRateが最小の行を全て取得し(2511)、Rateが一定以下であるかを確認する(2512)。一定以下である場合(2513)、取得した行のIndex列をテーブルTに格納する(2514)。テーブルTから1行読み込む(2515)。テーブルTから1行を読み込める場合(2516)、変数Countの値を0に初期化する(2517)。次に、テーブルAから1行読み込み(2518)、ID列の値がIDの値と等しいかを確認する(2519)。確認の結果、両者が等しい場合(2520)、テーブルTから読み込んだ行のIndex列の値とCountの値が等しいことを確認する(2521)。確認の結果、両者が等しい場合(2522)、Index列の値にテーブルAの変更前開始番号列の値を加えた結果をテーブルYに格納し(2523)、テーブルTの次の1行に進む。
Index列の値とCountの値が等しくない場合(2524)、Countの値をCount+1に変更し(2525)、テーブルAの次の1行に進む。ID列の値がIDの値と等しくない場合(2526)、テーブルAの次の1行に進む。テーブルTから行を読み込めない場合(2527)、処理を終了する。テーブルEに格納されている行の中からRateが最小の行を全て取得し、編集距離が一定より大きい場合(2528)、処理を終了する。
図26は、図23の処理の代案例(代案例1)を示す。
指定されたソースコード名、リビジョン番号、行番号セットから、関連する要件・バグレポートを表示する処理フローにおいて、検出した要件・バグレポートの一覧を表示する際に、コード変更の種類により表示を変更する一実施例である。
まず、ユーザにより入力装置106から指定されたソースコード名を受け取り、変数Srcに格納する(2601)。同様に、ユーザにより指定されたリビジョン番号を受け取り、変数Revに格納する(2602)。また、ユーザにより指定された行番号セットを受け取り、テーブルXに格納する(2603)。次に、Revの値が1より大きいかを確認する(2604)。確認の結果、1よりも大きい場合(2605)、リポジトリ103から、Srcを対象に、RevとRev−1との間の差分情報を取得し、テーブルDに格納する(2606)。そして差分情報を解析し、解析結果をテーブルA、B、Cに格納する(2607)。
その後、テーブルXから行番号を1つ取り出し、変数Nに格納する(2608)。Nに値が格納されている場合(2609)、Nが含まれる差分ブロックのIDをテーブルAから取得し変数IDに格納する(2610)。IDに値が格納されている場合(2611)、IDとNを基に、テーブルCからN行目のコードを取得し、変数Codeに格納する(2612)。Codeに値が格納されている場合(2613)、テーブルBからRev−1においてCodeに対応するコードの全ての行の行番号と変更種別を取得し、行番号をテーブルYに、変更種別を変数Modifiedに格納する(2614)。続いて、テーブルFにRev−1とModifiedの値を格納し(2615)、テーブルXの次の1行に進む。テーブルCからN行目のコードを取得し、変数Codeに格納した後に、Codeに値が格納されていない場合(2616)、テーブルXの次の1行に進む。テーブルFを図36に示す。
Nが含まれる差分ブロックのIDをテーブルAから取得し変数IDに格納した後に、IDに値が格納されていない場合(2617)、テーブルBからRev−1においてRevのN行目に対応する行の行番号を取得し、テーブルYに格納し(2618)、テーブルXの次の1行に進む。Nの値が存在しない場合(2619)、テーブルYから全ての行番号を取り出し、テーブルXに格納する(2620)。その後、Revの値をRev−1に変更し(2621)、次の差分情報の解析に進む。Revの値が1以下であった場合(2622)、テーブルRに格納されたリビジョン番号をもとに、要件・バグレポートを表示器に表示する(2623)。
図27は、図26の処理例における、Rev−1においてCodeに対応する全行番号を取得しテーブルYに格納、および変更種別を変数Modifiedに格納する処理(2614)の詳細を示す。
まず、変数Indexの値を0に初期化する(2701)。テーブルBから1行読み込む(2702)。1行を読み込める場合(2703)、ID列の値がIDの値と等しいかを確認する(2704)。確認の結果、等しい場合(2705)、コード列の値からCodeの値への変更種別を解析し、変数MTypeに格納する(2706)。続いて、コード列の値とCodeの値との編集距離を計算し(2707)、Index、編集距離、MTypeをテーブルHに格納する(2708)。テーブルHを図37に示す。
次に、Indexの値をIndex+1に変更し(2709)、テーブルBの次の1行に進む。ID列の値がIDの値と等しくない場合(2710)、テーブルBの次の1行に進む。テーブルBから行を読み込めない場合(2711)、テーブルHに格納されている行の中から編集距離が最小の行を全て取得し(2712)、編集距離が一定以下であるかを確認する(2713)。確認の結果、一定以下である場合(2714)、取得した行のIndex列と変更種別列をテーブルIに格納する(2715)。テーブルIを図38に示す。
次に、テーブルIの各行の変更種別列をもとに変更種別を決定し、変数Modifiedに格納する(2716)。テーブルIから1行読み込む(2717)。1行を読み込める場合(2718)、変数Countの値を0に初期化する(2719)。次に、テーブルAから1行読み込み(2720)、ID列の値がIDの値と等しいかを確認する(2721)。確認の結果、両者が等しい場合(2722)、テーブルIから読み込んだ行のIndex列の値とCountの値が等しいことを確認する(2723)。その結果、両者が等しい場合(2724)、Index列の値にテーブルAの変更前開始番号列の値を加えた結果をテーブルYに格納し(2725)、テーブルIの次の1行に進む。一方、Index列の値とCountの値が等しくない場合(2726)、Countの値をCount+1に変更し(2727)、テーブルAの次の1行に進む。
ID列の値がIDの値と等しくない場合(2728)、テーブルAの次の1行に進む。テーブルIから行を読み込めない場合(2729)、処理を終了する。テーブルHに格納されている行の中から編集距離が最小の行を全て取得し、編集距離が一定より大きい場合(2730)、処理を終了する。
図28は、図27の処理における、コードからCodeへの変更種別を解析しその結果を変数MTypeに格納する処理(2706)の詳細を示す。
まず、Codeの値をテーブルWの区切り文字で分割し、テーブルJに格納する(2801)。テーブルWを図47に示す。テーブルJを図39に示す。テーブルJから1行取り出し、変数Tokenに格納する(2802)。Tokenに値が格納されている場合(2803)、Tokenの値がテーブルKに含まれるかを確認する(2804)。確認の結果、Tokenの値が含まれる場合(2805)、Tokenの値をテーブルLに格納し(2806)、テーブルJの次の1行に進む。テーブルLを図40に示す。一方、Tokenの値が含まれない場合(2807)、テーブルJの次の1行に進む。
テーブルJにTokenに値が格納されていない場合(2808)、コード列の値をテーブルWの区切り文字で分割し、テーブルJに格納する(2809)。テーブルJから1行取り出し、変数Tokenに格納する(2810)。Tokenに値が格納されている場合(2811)、Tokenの値がテーブルKに含まれるかを確認する(2812)。テーブルKを図34に示す。確認の結果、Tokenの値が含まれる場合(2813)、Tokenの値をテーブルMに格納し(2814)、テーブルJの次の1行に進む。一方、Tokenの値が含まれない場合(2815)、テーブルJの次の1行に進む。テーブルMを図41に示す。
上記の、Tokenに値が格納されていない場合(2816)、テーブルLとテーブルMの内容が一致するかを確認する(2817)。その結果、両者が一致する場合(2818)、変数MTypeに“その他”という値を格納する(2819)。一方、両者が不一致の場合(2820)、変数MTypeに“構造”という値を格納する(2821)。
図29は、図27の処理における、テーブルIの各行の変更種別列をもとに変更種別を決定しその結果を変数Modifiedに格納する処理(2716)の詳細を示す。
まず、変数MStructとMOtherに“False”を格納する(2901)。テーブルIから1行取り出し、変数MTypeに格納する(2902)。Mtypeに値が格納されている場合(2916)、MTypeの値を確認する(2903)。値が“構造”の場合(2904)、MStructの値を“True”に変更する(2905)。値が“その他”の場合(2906)、MOtherの値を“True”に変更する(2907)。
一方、MTypeに値が格納されていない場合(2908)、MStructとMOtherの値を確認する(2909)。確認の結果、MStructのみ“True”の場合(2910)、変数Modifiedに“構造”という値を格納する(2911)。MOtherのみ“True”の場合(2912)、変数Modifiedに“その他”という値を格納する(2913)。MStructとMOtherがともに“True”の場合(2914)、変数Modifiedに“両方”という値を格納する(2915)。
図30は、図26の処理における、要件・バグレポートを表示する処理(2623)の詳細を示す。
まず、テーブルFから1行読み込む(3001)。読み込めた場合(3002)、リビジョン番号列の値を変数Revに、変更種別列の値を変数Modifiedに格納する(3003)。次に、リポジトリからRevの値と等しいリビジョン番号におけるコミットメッセージを取得し、変数Msgに格納する(3004)。Msgから要件・バグレポートの管理番号を取得し、テーブルPに格納する(3005)。テーブルPから1行読み込み、管理番号列の値を変数Nに格納する(3006)。Nに値が格納されている場合(3007)、要件・バグレポートDBからNの値と等しい管理番号の要件・バグレポートのタイトルを取得し、変数Titleに格納する(3008)。Titleに値が格納されている場合(3009)、リビジョン番号としてRev、管理番号としてN、タイトルとしてTitle、変更種別としてModifiedをテーブルUに格納し(3010)、テーブルPの次の1行に進む。テーブルUを図42に示す。
一方、Titleに値が格納されていない場合(3011)、テーブルPの次の1行に進む。テーブルPから行を読み込めない場合(3012)、テーブルFの次の1行に進む。テーブルFから行を読み込めない場合(3013)、テーブルUにデータが格納されているかを確認する(3014)。確認の結果、テーブルUにデータが格納されている場合(3015)、テーブルUに格納されているリビジョン番号、管理番号、タイトル、変更種別の一覧を、変更種別で分類して表示器に表示する(3016)。そして、管理番号を入力装置から取得し、変数Nに格納する(3017)。続いて、要件・バグレポートDBからNの値に等しい管理番号の要件・バグレポートを表示器に表示する(3018)。
上記の、テーブルUにデータが格納されていない場合(3019)、指定行の変更に関連する要件・バグレポートはないことを表示する(3020)。
図31は、図30の処理における、テーブルUから変更種別列の値で分類してリビジョン番号、管理番号、タイトル、変更種別の一覧を表示する処理(3016)の詳細を示す。
まず、テーブルUから1行読み込む(3101)。読み込めた場合(3102)、変更種別列の値を確認する(3103)。値が“構造”の場合(3104)、リビジョン番号、管理番号、タイトル、変更種別を表示に追加し(3105)、テーブルUの次の1行に進む。値が“構造”以外の場合(3106)、テーブルUの次の1行に進む。テーブルUから行を読み込めない場合(3107)、テーブルUの1行目に戻る(3108)。テーブルUから1行読み込む(3109)。読み込めた場合(3110)、変更種別列の値を確認する(3111)。値が“両方”の場合(3112)、リビジョン番号、管理番号、タイトル、変更種別を表示に追加し(3113)、テーブルUの次の1行に進む。値が“両方”以外の場合(3114)、テーブルUの次の1行に進む。
上記の、テーブルUから行を読み込めない場合(3115)、テーブルUの1行目に戻る(3116)。テーブルUから1行読み込む(3117)。1行を読み込めた場合(3118)、変更種別列の値を確認する(3123)。値が“その他”の場合(3119)、リビジョン番号、管理番号、タイトル、変更種別を表示に追加し(3120)、テーブルUの次の1行に進む。値が“その他”以外の場合(3121)、テーブルUの次の1行に進む。テーブルUから行を読み込めない場合(3122)、処理を終了する。リビジョン番号、管理番号、タイトル、変更種別の一覧の表示例を図45に示す。
図32は、図23の処理の更なる代案例(代案例2)を示す。検出した要件・バグレポートの一覧を表示する際に、コード変更の種類により、表示を変更する一実施例である。
まず、テーブルRから1行読み込む(3201)。1行を読み込めた場合(3202)、リビジョン番号列の値を変数Revに格納する(3203)。次に、リポジトリからRevの値と等しいリビジョン番号におけるコミットメッセージを取得し、変数Msgに格納する(3204)。Msgから要件・バグレポートの管理番号を取得し、テーブルPに格納する(3205)。テーブルPから1行読み込み、管理番号列の値を変数Nに格納する(3206)。
Nに値が格納されている場合(3207)、要件・バグレポートDBからNの値と等しい管理番号の要件・バグレポートのタイトルと種別を取得し、タイトルを変数Titleに、種別を変数Typeに格納する(3208)。Titleに値が格納されている場合(3209)、リビジョン番号としてRev、管理番号としてN、タイトルとしてTitle、種別としてTypeをテーブルVに格納し(3210)、テーブルPの次の1行に進む。テーブルVを図43に示す。一方、Titleに値が格納されていない場合(3211)、テーブルPの次の1行に進む。
上記のテーブルPから行を読み込めない場合(3212)、テーブルRの次の1行に進む。また、テーブルRから行を読み込めない場合(3213)、テーブルVにデータが格納されているかを確認する(3214)。確認の結果、データが格納されている場合(3215)、テーブルVに格納されているリビジョン番号、管理番号、タイトル、種別の一覧を、種別で分類して表示器に表示する(3216)。管理番号を入力装置から取得し、変数Nに格納する(3217)。続いて、要件・バグレポートDBからNの値に等しい管理番号の要件・バグレポートを表示する(3218)。テーブルVにデータが格納されていない場合(3219)、指定行の変更に関連する要件・バグレポートはないことを表示する(3220)。
図33は、図32の処理における、テーブルVから種別列の値で分類してリビジョン番号、管理番号、タイトル、種別を一覧表示する処理(3216)の詳細を示す。
まず、テーブルVから1行読み込む(3301)。1行を読み込めた場合(3302)、種別列の値を確認する(3303)。確認の結果、値が“機能追加”の場合(3304)、リビジョン番号、管理番号、タイトル、種別を表示に追加し(3305)、テーブルVの次の1行に進む。値が“バグ修正”の場合(3306)、テーブルVの次の1行に進む。テーブルVから行を読み込めない場合(3307)、テーブルVの1行目に戻る(3308)。テーブルVから1行読み込む(3309)。1行を読み込めた場合(3310)、種別列の値を確認する(3311)。値が“バグ修正”の場合(3312)、リビジョン番号、管理番号、タイトル、種別を表示に追加し(3313)、テーブルVの次の1行に進む。値が“機能追加”の場合(3314)、テーブルVの次の1行に進む。
上記のテーブルVから行を読み込めない場合(3315)、処理を終了する。リビジョン番号、管理番号、タイトル、種別の一覧の表示例を図46に示す。
101:サーバ装置 102:要件・バグレポート検出機能部
103:構成管理情報DB 104:ソースコード構成管理システム
105:要件・バグレポートDB 106:入力装置 107:出力装置
201:差分情報 202:差分ブロック 301:コミットメッセージ
401:要件・バグレポートの管理番号 402:要件・バグレポートのタイトル
403:要件・バグレポートの種別。

Claims (6)

  1. ソフトウェアのソースコードの指定行における変更に関連する要件・バグレポートを検索して出力装置に出力する要件・バグレポート処理システムであって、
    ソースコードの特定の行を指定する入力装置と、
    処理装置でプログラムを実行することで実現される、該入力装置から指定されたソースコードの過去のリビジョンから、行を変更した全てのリビジョンを行の変更前後の編集距離を基に検出する第1処理手段と、
    処理装置でプログラムを実行することで実現される、該リビジョンに関連する要件・バグレポートを検出する第2処理手段と、
    該第2処理手段によって処理された要件・バグレポートを可視的に出力する出力装置と
    を有することを特徴とする要件・バグレポート処理システム。
  2. 前記第1処理手段は、リビジョンの検出基準として行の変更前後の長さと編集距離を用いてリビジョンを検出することを特徴とする請求項1の要件・バグレポート処理システム。
  3. 前記第2処理手段で検出された要件・バグレポートの一覧を表示器に表示するものであって、該第2処理手段は、該表示の際にコード変更の種類により、表示を変更することを特徴とする請求項1又は2の要件・バグレポート処理システム。
  4. 前記第2処理手段は、要件・バグレポートの一覧を表示器に表示する際に、仕様変更かバグ修正かにより表示を変更することを特徴とする請求項3の要件・バグレポート処理システム。
  5. 請求項1乃至3のいずれかの請求項に記載の要件・バグレポート処理システムであって、該入力装置から指定される、ソースコード名と2つのリビジョン番号に応じて、リビジョン間の差分情報を出力するソースコード構成管理システムと、
    要件・バグレポートの管理番号、タイトル、機能追加のレポートか又はバグ修正のレポートかのいずれかを指定する種別に関する情報を少なくとも格納する要件・バグレポートDBを有し、
    前記第2処理手段は、該入力装置から指定されたレビジョン番号と等しいビジョン番号におけるコミットメッセージを該ソースコード構成管理システムから取得し、
    該コミットメッセージが有する要件・バグレポートの管理番号を基に、該要件・バグレポートDBから、該当する要件・バグレポートのタイトル、種別を取得し、
    該出力装置は、該第2処理手段によって取得された、ある要件・バグレポートの、該リビジョン番号、管理番号、タイトルの一覧を出力して表示する
    ことを特徴とする要件・バグレポート処理システム。
  6. 処理装置でプログラムを実行することにより、ソフトウェアのソースコードの指定行における変更に関連する要件・バグレポートを検索して出力装置に出力して表示する処理方法であって、
    該処理装置は、入力装置から指定されたソースコード名、リビジョン番号、2つの行の行番号を受け取るステップと、
    該処理装置は、要件・バグレポートの管理番号を含むコミットメッセージを格納するDBから、該ソースコード名と2つのリビジョン番号に応じた、リビジョン間の差分情報を取得するステップと、
    該処理装置は、該差分情報を解析して、要件・バグレポートの管理番号、タイトル、機能追加のレポートか又はバグ修正のレポートかのいずれかを指定する種別に関する情報を少なくとも格納する要件・バグレポートDBから、該当する要件・バグレポートのタイトル、種別を取得するステップと、
    該出力装置は、取得された、ある要件・バグレポートの、該リビジョン番号、管理番号、タイトルの一覧を出力して表示するステップと
    を有することを特徴とする要件・バグレポート処理方法。
JP2010038866A 2010-02-24 2010-02-24 要件・バグレポート処理システム及びその方法 Pending JP2011175446A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010038866A JP2011175446A (ja) 2010-02-24 2010-02-24 要件・バグレポート処理システム及びその方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010038866A JP2011175446A (ja) 2010-02-24 2010-02-24 要件・バグレポート処理システム及びその方法

Publications (1)

Publication Number Publication Date
JP2011175446A true JP2011175446A (ja) 2011-09-08

Family

ID=44688248

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010038866A Pending JP2011175446A (ja) 2010-02-24 2010-02-24 要件・バグレポート処理システム及びその方法

Country Status (1)

Country Link
JP (1) JP2011175446A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130167120A1 (en) * 2011-12-21 2013-06-27 International Business Machines Corporation Retrieving revisions in source code from a plurality of revision history data sets
CN109783106A (zh) * 2018-12-28 2019-05-21 西安交通大学 一种基于编辑距离的自适应反馈程序评测方法及装置
CN114416524A (zh) * 2021-12-15 2022-04-29 北京邮电大学 文件错误的定位方法及装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130167120A1 (en) * 2011-12-21 2013-06-27 International Business Machines Corporation Retrieving revisions in source code from a plurality of revision history data sets
US8990773B2 (en) 2011-12-21 2015-03-24 International Business Machines Corporation Retrieving revisions in source code from a plurality of revision history data sets
CN109783106A (zh) * 2018-12-28 2019-05-21 西安交通大学 一种基于编辑距离的自适应反馈程序评测方法及装置
CN109783106B (zh) * 2018-12-28 2021-05-28 西安交通大学 一种基于编辑距离的自适应反馈程序评测方法及装置
CN114416524A (zh) * 2021-12-15 2022-04-29 北京邮电大学 文件错误的定位方法及装置
CN114416524B (zh) * 2021-12-15 2023-03-24 北京邮电大学 文件错误的定位方法及装置

Similar Documents

Publication Publication Date Title
US11106626B2 (en) Managing changes to one or more files via linked mapping records
TWI454941B (zh) 自動測量網頁文件集
US9852217B2 (en) Searching and ranking of code in videos
JP6542612B2 (ja) テストシナリオ生成支援装置およびテストシナリオ生成支援方法
US20160063062A1 (en) Code searching and ranking
US20200327177A1 (en) System and method for monitoring internet activity
US20200225943A1 (en) Visualizations of software project and contributor activity
US20140075299A1 (en) Systems and methods for generating extraction models
JP2005301859A (ja) コード検索プログラム及びコード検索装置
JP2011175446A (ja) 要件・バグレポート処理システム及びその方法
US20050010597A1 (en) System and method of determining impact of model changes
JP6120607B2 (ja) 要件検出装置及び要件検出プログラム
JP2008112363A (ja) 文書処理装置および文書処理プログラム
US20150178075A1 (en) Enhancing understandability of code using code clones
JP6497199B2 (ja) プログラム試験優先順位決定システム
KR101798139B1 (ko) 웹 기반 데이터 시각화 시스템에서의 데이터 변수타입에 따른 필터 시스템 및 방법
JP2008117280A (ja) ソフトウェアソースコードの検索方法及びシステム
JP2010287143A (ja) 記事整理システム
JP2021114120A (ja) 曖昧箇所訂正支援装置及び方法
JPWO2020085374A1 (ja) 熟練指数提供装置、熟練指数提供方法、及びプログラム
JP5417359B2 (ja) 文書評価支援システム、及び文書評価支援方法
JP6978997B2 (ja) 類似データの検索方法、情報検索装置及びプログラム
US20240126631A1 (en) Systems and methods for generating an enhanced error message
JP5380130B2 (ja) ファイル検索装置及びファイル検索方法、並びにプログラム
JP6884172B2 (ja) 計算機システム及び文書の評価方法