JP6546569B2

JP6546569B2 - データ処理プログラム及びデータ処理方法

Info

Publication number: JP6546569B2
Application number: JP2016168393A
Authority: JP
Inventors: 忍斎藤
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2016-08-30
Filing date: 2016-08-30
Publication date: 2019-07-17
Anticipated expiration: 2036-08-30
Also published as: JP2018036792A

Description

本発明は、データ処理プログラム及びデータ処理方法に関する。

インターネット上でのビジネスの普及やモバイル網の普及により、さまざまなものがソフトウェアにより実現されるようになっており、商用で利用されるソフトウェアの開発品質の重要性が増している。また、ソフトウェアでは短期間での投資効果も求められるため、システム開発の開発期間も短くなっている。

アジャイル開発やリーン開発に代表される短期のソフトウェア開発では、新たなタスク（機能実装又はバグ改修等）が発生すると、開発者の１つ１つのタスクに対応したチケットが起票される（起票は、ソフトウェア開発の管理者（例：スクラムマスター）、又は開発者自身が実施）。

チケットが起票されると、当該チケットに対応するタスクを担う開発者がアサインされる。アサインされた開発者は、タスクの内容に基づき、ソースコードの更新（新規作成・変更・削除）を行う。

このようなソフトウェア開発のプロジェクトでは、一般的に、チケットの状態を管理する課題管理システム（ＩＴＳ（Issue Tracking System））と、ソースコードの版管理をするバージョン管理システム（ＶＭＳ（Version Management System））の２つが利用されている。

開発者は、ＩＴＳで起票されたチケット（に対応するタスク）の内容に基づき、ソースコードの更新（新規作成・変更・削除）を行い、ＶＭＳに更新途中のソースコードのコミットを行う。チケットに対応するタスクが完了（ソースコードの更新が完了）すると、プロジェクトで予め定められた確認作業（例：回帰試験の実施、管理者の挙動確認）が実施される。その上で、開発者は、更新が完了したソースコードをＶＭＳにコミットする。併せて、ＩＴＳでも当該タスクに対応するチケットの状態を完了として記録される。

「大競争時代のソフト生産技術革命」、［online］、インターネット＜・http://itpro.nikkeibp.co.jp/article/COLUMN/20130601/481262/?rt=nocnt＞

しかしながら、実際のソフトウェア開発では、開発者の実装作業（ソースコードの更新と、ＶＭＳへのコミット）だけが先に進んでしまい、それらのタスクに対応するチケットが起票されていなかったり、起票されていたとしてもチケットが最新のソースコードの内容を反映していなかったりするケースが多くみられる。これにより、開発（例：イテレーション）終了後に、チケットやそれに関連する開発文書（例：要件定義書）の内容が、最新のソースコードの内容を反映せずに開発が終わってしまうこともある。

このように、チケット（および、それに関連する開発文書）の更新漏れが発生し、残存したままであると、その後何らかの問題がソフトウェアで発生して、開発時のバグ修正のソースコードへの反映状況等を確認しようとした際に、当該ソースコードに対する各更新が、バグ修正によるものであったの否かさえも確認することができなくなってしまう。また、次の開発（イテレーション）において新しいメンバが参画した際にも、ソフトウェアの実装機能の全容が把握できない、あるいは、なぜその機能を実装したのかという根拠情報（Ｒａｔｉｏｎａｌｅ）も把握できない事態となる。

本発明は、上記の点に鑑みてなされたものであって、ソースコードが更新された理由が不明となるのを回避可能とすることを目的とする。

そこで上記課題を解決するため、データ処理プログラムは、ソフトウェアのソースコードの更新理由ごとに起票され、当該更新理由の識別情報と、当該更新理由の発生時期と、当該更新理由に応じた作業の完了時期とを含む第１のデータの集合と、前記ソースコードの更新ごとに記録され、当該更新の時期を含む第２のデータの集合であって、一部の前記第２のデータについては、更に、当該第２のデータに係る更新に対応する更新理由の識別情報がユーザによって入力されている集合と、を参照して、前記一部の第２のデータについて入力された前記識別情報を含む前記第１のデータに含まれる発生時期及び完了時期と、前記識別情報が入力されていない前記第２のデータに含まれる更新の時期との関係に基づいて、当該第２のデータに対して前記識別情報が入力されていない原因を複数のパターンのうちのいずれかに分類する分類部としてコンピュータを機能させる。

ソースコードが更新された理由が不明となるのを回避可能とすることができる。

本発明の実施の形態におけるデータ処理装置のハードウェア構成例を示す図である。本発明の実施の形態におけるデータ処理装置の機能構成例を示す図である。データ処理装置が実行する処理手順の一例を説明するためのフローチャートである。チケットデータの一例を示す図である。コミットログの一例を示す図である。ＴＣＮＣの一例を示す図である。分類結果に応じた通知情報の出力例を示す図である。分類結果に応じた修正候補のレコメンド情報の出力例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるデータ処理装置のハードウェア構成例を示す図である。図１のデータ処理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

データ処理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってデータ処理装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

図２は、本発明の実施の形態におけるデータ処理装置の機能構成例を示す図である。図２において、データ処理装置１０は、ＶＭＳ１１、ＩＴＳ１２、ＴＣＮＣ生成部１３、原因分類部１４、及び修正候補出力部１５等を有する。これらは、データ処理装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

ＶＭＳ１１は、ソフトウェア（主にプログラム）のソースコードの版管理を行うバージョン管理システム（Version Management System）である。一般的な（市販されている）バージョン管理システムがＶＭＳ１１として利用されてもよい。

図２において、ＶＭＳ１１は、コミットログ生成部１１１及びコミットログ記憶部１１２等を含む。コミットログ生成部１１１は、新規に作成されたソースコード、又は既存のソースコード等のコミット指示がＶＭＳ１１に入力されると、当該ソースコードに関するコミットログを生成し、当該コミットログをコミットログ記憶部１１２に記録する。コミットとは、ソースコードの版（バージョン）を一つ上げてＶＭＳ１１に登録することをいう。すなわち、コミットは、ソースコードの更新ごとに実行される。したがって、コミットログは、ソースコードの更新ごとに記録される。

ＩＴＳ１２は、ソフトウェアの開発者のタスク（作業）を割り当てたチケットデータを管理する課題管理システム（Issue Tracking System）である。一般的な（市販されている）課題管理システムが、ＩＴＳ１２として利用されてもよい。チケットデータとは、ソフトウェアのソースコードの更新理由の発生に応じて（すなわち、当該更新理由に応じたタスク（機能実装又はバグ改修等のソースコードの更新作業）の発生に応じて）起票されるデータをいう。

図２において、ＩＴＳ１２は、チケット状態更新部１２１及びチケットデータ記憶部１２２等を含む。チケット状態更新部１２１は、チケットデータ記憶部１２２に記憶されるチケットデータの状態を更新する。具体的には、チケット状態更新部１２１は、ユーザによって入力されるチケットデータの起票指示に応じ、チケットデータを生成し、当該チケットデータをチケットデータ記憶部１２２に記録する。この際、チケットデータには、起票時刻（すなわち、更新理由及びタスクの発生時刻）が記録される。したがって、チケットデータは、ソースコードの更新理由ごと（更新理由に応じたタスクごと）に記録される。また、チケット状態更新部１２１は、更新理由に応じたタスクの完了通知がユーザによって入力されると、当該タスクに対応するチケットデータに対して完了時刻を記録する。

例えば、ソースコードの更新理由が発生すると、当該更新理由に応じたタスクを開始させるために、チケットデータが起票される。開発者は、チケットデータの内容に基づき、ソースコードの更新を行い、更新後のソースコードをＶＭＳ１１にコミットする。その結果、当該更新に対応するコミットログがコミットログ記憶部１１２に記録される。

なお、コミットログ記憶部１１２及びチケットデータ記憶部１２２は、例えば、補助記憶装置１０２、又はデータ処理装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

ＴＣＮＣ生成部１３、原因分類部１４、及び修正候補出力部１５の機能については、処理手順の説明において明らかにされる。

なお、ＶＭＳ１１及びＩＴＳ１２は、それぞれデータ処理装置１０とは異なるコンピュータを用いて実現されてもよい。

図３は、データ処理装置が実行する処理手順の一例を説明するためのフローチャートである。図３の処理手順は、例えば、ユーザによって処理の実行指示が入力されると開始される。

ステップＳ１０１において、ＴＣＮＣ生成部１３は、チケットデータ記憶部１２２からチケットデータの集合を取得する。

図４は、チケットデータの一例を示す図である。図４において、１つの行が１つのチケットデータに相当する。各チケットデータは、チケットＩＤ、起票時刻、及び完了時刻等を含む。チケットＩＤは、チケットデータごと（すなわち、更新理由又はタスクごと）の識別情報である。起票時刻は、チケットデータの起票時刻である。完了時刻は、チケットデータに対応するタスクの完了時刻である。なお、チケットＩＤ及び起票時刻は、起票時にチケットデータに記録される。完了時刻は、チケットデータに対応するタスクの完了時にチケットデータに記録される。

なお、一般的なチケットデータには、タスクの内容（例えば、実装されるべき機能の内容、又は修正されるべきバグの内容等）やその他の情報も含まれるが、本実施の形態では、便宜上、他の情報については省略する。

続いて、ＴＣＮＣ生成部１３は、コミットログ記憶部１１２からコミットログの集合を取得する（Ｓ１０２）。

図５は、コミットログの一例を示す図である。図５において、１つの行が１つのコミットログに相当する。各コミットログは、ソースコード名及びコミット時刻等を含む。また、一部のコミットログは、更に、チケットＩＤを含む。

ソースコード名は、コミットされたソースコードの名前（例えば、ソースコードのファイル名）である。コミット時刻は、コミットが行われた時刻（すなわち、更新がＶＭＳ１１に反映された時刻）である。チケットＩＤは、コミットログに係るソースコードの更新に対応するタスクのチケットデータのチケットＩＤである。

チケットＩＤは、例えば、ソースコードがＶＭＳ１１にコミットされる際に、ユーザ（開発者等）によってダイアログボックス等を介して入力される。すなわち、コミットログ生成部１１１は、コミット時にチケットＩＤが入力された場合、当該チケットＩＤをも含むコミットログを生成する。但し、チケットＩＤが入力されない場合も有る。チケットデータの起票や、チケットＩＤの入力等は、ユーザの運用に任されているためである。したがって、チケットＩＤを含まないコミットログが生成されうる。

なお、一般的なコミットログには、他にも様々な情報が記録されるが、本実施の形態では便宜上省略される。

続いて、ＴＣＮＣ生成部１３は、取得されたチケットデータ及びコミットログに基づいて、チケットデータの起票時刻及び完了時刻と、コミットログのコミット時刻との関係をソースコードごとに可視化するチャート（チケット−コミットネットワーク図（Ticket-Commit Network Chart））を生成する（Ｓ１０３）。以下、チケット−コミットネットワーク図を、「ＴＣＮＣ」という。

続いて、ＴＣＮＣ生成部１３は、生成したＴＣＮＣを、表示装置１０６に表示する（Ｓ１０４）。

図６は、ＴＣＮＣの一例を示す図である。図６に示されるように、ＴＣＮＣは、ソースコードごと（Ｓｏｒｕｃｅ１〜３）に、時系列に、チケットデータの起票時刻、完了時刻、及びコミットログのコミット時刻のそれぞれのタイミングを示す。なお、図６の例では、タイミングの粒度が１日単位であるが、可視化したい時間幅に応じて、１時間単位や半日単位でタイミングが示されてもよい。

コミットには、コミット時におけるチケットＩＤの入力の有無に対応して、チケットＩＤ有コミットとチケットＩＤ無コミット（図では赤マル）の２種類が存在する。図６において、チケットＩＤ有コミットは黒塗りの円で表現され、チケットＩＤ無コミットは白抜きの円で表現されている。

図６によれば、Ｓｏｕｒｃｅ１について、チケットＩＤ有コミットが２つ（６／２と６／３）、チケットＩＤ無コミットが２つ（６／２９、６／３０）が存在することが分かる。これらは、コミットログの内容に基づいて抽出及び可視化される。

ＴＣＮＣは、また、コミットログに含まれているチケットＩＤに基づき、当該チケットＩＤに対応するチケットデータの生存期間（起票時刻から完了時刻までの期間）をも示す。例えば、Ｓｏｕｒｃｅ１については、チケットＩＤとして「ＴＩＤ−１」を含むコミットログが有る。そこで、ＴＣＮＣ生成部１３は、「ＴＩＤ−１」のチケットＩＤを含むチケットデータの起票時刻（６／１）と完了時刻（６／４）を取得し、６／１から６／４までを生存期間として表示する。なお、図６において、生存期間の両端は、三角形によって示されている。

すなわち、ＴＣＮＣでは、ソースコードごとに、当該ソースコードに関するコミットログに含まれている各チケットＩＤについて、当該チケットＩＤに係るチケットＩＤの生存期間を示すためにライン（実線の水平線）が描画され、当該ラインに、当該チケットデータの起票時刻及び完了時刻と、当該チケットＩＤを含むコミットログのコミット時刻とが配置される。

一方、チケットＩＤ無コミットのコミット時刻は、チケットＩＤ有コミットのコミット時刻並びにチケットデータの起票時刻及び完了時刻とは別のラインに配置される。チケットＩＤ無コミットは、いずれのチケットデータに対応するのかが不明であるからである。例えば、Ｓｏｕｒｃｅ１では、ＴＩＤ−１に対応するコミット時刻が配置されるライン（実線）と、チケットＩＤ無コミットが配置されるライン（破線）とが分けられている。

続いて、原因分類部１４は、各チケットＩＤ無コミットについて、チケットＩＤが入力されていない原因（又は理由）を、複数のパターンのうちのいずれかのパターンに分類する（Ｓ１０５）。

本実施の形態において、チケットＩＤが入力されていない原因のパターンは、以下の二つである。
パターン１：コミットに対応するチケットデータの更新（起票・修正）が漏れている。
パターン２：コミットに対応するチケットデータは存在しているが、単に開発者がコミット時にチケットＩＤを入力し忘れてしまった。

例えば、Ｓｏｕｒｃｅ１やＳｏｕｒｃｅ３では、チケットＩＤ有コミットに対応するチケット（ＴＩＤ−１やＴＩＤ−３）の生存期間外で、チケットＩＤ無コミットが発生している。このようなチケットＩＤ無コミットについては、チケットの新規起票や、既存チケットの内容の更新が漏れている可能性が高い。そこで、原因分類部１４は、コミット時刻が当該生存期間に含まれないチケットＩＤ無コミットを、パターン１に分類する。

一方、Ｓｏｕｒｃｅ２では、チケットＩＤ有コミットに対応するチケット（ＴＩＤ−２）の生存期間内でチケットＩＤ無コミットが発生している。このようなチケットＩＤ無コミットについては、単に開発者がコミット時にＴＩＤ−２の入力をし忘れている可能性が高い。そこで、原因分類部１４は、コミット時刻が当該生存期間に含まれるチケットＩＤ無コミットを、パターン２に分類する。

続いて、原因分類部１４は、各チケットＩＤ無コミットについて、分類結果に応じた通知情報を、表示装置１０６に表示されているＴＣＮＣに出力する（Ｓ１０６）。

図７は、分類結果に応じた通知情報の出力例を示す図である。図７に示されるように、パターン１に分類された、Ｓｏｕｒｃｅ１又はＳｏｕｒｃｅ３のチケットＩＤ無コミットについては、通知情報ｎ１及びｎ３のように、チケットの更新漏れの可能性が有ることを示すメッセージが表示される。

一方、パターン２に分類された、Ｓｏｕｒｃｅ２のチケットＩＤ無コミットについては、通知情報ｎ２のように、コミット時にチケットＩＤの付与漏れの可能性が有ることを示すメッセージが表示される。

ユーザは、通知情報を参照して、チケットＩＤ無コミットに対応するコミットログにチケットＩＤを入力したり、チケットＩＤ無コミットに対応するチケットデータの起票若しくは修正を行ったりすることができる。

続いて、修正候補出力部１５は、各チケットＩＤ無コミットについて、分類結果に応じた修正候補のレコメンド情報を、表示装置１０６に表示されているＴＣＮＣに出力する（Ｓ１０７）。

図８は、分類結果に応じた修正候補のレコメンド情報の出力例を示す図である。図８に示されるように、パターン１に分類されたチケットＩＤ無コミットに対しては、レコメンド情報ｒ１又はレコメンド情報ｒ３のように、当該チケットＩＤ無コミットに係るソースコードに対するチケットデータが修正候補として提示される。

例えば、Ｓｏｒｕｃｅ１であれば、チケットＩＤ無コミットの前に起票及び完了しているＴＩＤ−１のチケットデータが修正候補として提示される。また、当該チケットデータとは別のチケットデータが起票されなければならない可能性もあるため、その旨も提示される。同様に、Ｓｏｕｒｃｅ３であれば、チケットＩＤ無コミットの後に起票されたＴＩＤ−３のチケットデータが修正候補として提示される。なお、チケットデータの修正とは、例えば、起票時刻又は完了時刻の修正である。

一方、パターン２に分類されたチケットＩＤ無コミットに対しては、レコメンド情報ｒ２のように、同一期間でコミットされたチケットＩＤ有コミットに対応するチケットＩＤが修正候補として提示される。例えば、Ｓｏｒｕｃｅ２について、チケットＩＤ無コミットに対応するコミットログに対して、「ＴＩＤ−２」が入力候補として提示される。

なお、ステップＳ１０６及びＳ１０７のいずれか一方のみが実行されてもよい。また、図７に示されるＴＣＮＣにおいて、ユーザによって選択されたチケットＩＤ無コミットについて、ステップＳ１０７が実行されてもよい。

上述したように、本実施の形態によれば、チケットＩＤ無コミットに係るコミットログの存在をユーザに通知することができ、コミットログの修正又はチケットデータの起票・修正をユーザに促すことができる。したがって、チケットＩＤ無コミットの解消を促進することができ、ソースコードが更新された理由が不明となるのを回避可能とすることができる。

すなわち、本実施の形態によれば、開発終了後に、ソフトウェアの開発過程におけるチケットデータの起票が充実化されることにより、開発時のバグ修正のソースコードへの反映状況等を確認しようとした際に、当該ソースコードに対する各更新が、バグ修正によるものであったか否かが確認出来なくなるような状況を回避することができる。また、次の開発者（又は更新の要求者）が実装機能の全容が把握できなくなることや、実装機能の根拠が把握できないようなことを回避できる。その結果、ソフトウェア開発における保守作業の品質を向上させることができる。

なお、本実施の形態において、チケットデータは、第１のデータの一例である。コミットログは、第２のデータの一例である。チケットデータの起票時刻、完了時刻は、それぞれ、更新理由の発生時期、当該更新理由に応じた作業の完了時期の一例である。コミットログのコミット時刻は、更新の時期の一例である。原因分類部１４は、分類部の一例である。修正候補出力部１５は、出力部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０データ処理装置
１１ＶＭＳ
１２ＩＴＳ
１３ＴＣＮＣ生成部
１４原因分類部
１５修正候補出力部
１００ドライブ装置
１０１記録媒体
１０２補助記憶装置
１０３メモリ装置
１０４ＣＰＵ
１０５インタフェース装置
１０６表示装置
１０７入力装置
１１１コミットログ生成部
１１２コミットログ記憶部
１２１チケット状態更新部
１２２チケットデータ記憶部
Ｂバス

Claims

ソフトウェアのソースコードの更新理由ごとに起票され、当該更新理由の識別情報と、当該更新理由の発生時期と、当該更新理由に応じた作業の完了時期とを含む第１のデータの集合と、前記ソースコードの更新ごとに記録され、当該更新の時期を含む第２のデータの集合であって、一部の前記第２のデータについては、更に、当該第２のデータに係る更新に対応する更新理由の識別情報がユーザによって入力されている集合と、を参照して、
前記一部の第２のデータについて入力された前記識別情報を含む前記第１のデータに含まれる発生時期及び完了時期と、前記識別情報が入力されていない前記第２のデータに含まれる更新の時期との関係に基づいて、当該第２のデータに対して前記識別情報が入力されていない原因を複数のパターンのうちのいずれかに分類する分類部としてコンピュータを機能させることを特徴とするデータ処理プログラム。
前記分類部は、更新の時期が、前記一部の第２のデータについて入力された前記識別情報を含む前記第１のデータに含まれる発生時期及び完了時期の間に含まれる前記第２のデータと、更新の時期が、当該発生時期及び当該完了時期の間に含まれない前記第２のデータとに関する前記原因を、異なるパターンに分類する、
ことを特徴とする請求項１記載のデータ処理プログラム。
前記分類部は、更新の時期が、前記一部の第２のデータについて入力された前記識別情報を含む前記第１のデータに含まれる発生時期及び完了時期の間に含まれる前記第２のデータについては、当該更新に対応する更新理由に係る前記第１のデータが有るにも関わらず、前記識別情報の入力がされていないことが原因とするパターンに分類する、
ことを特徴とする請求項１又は２記載のデータ処理プログラム。
前記一部の第２のデータについて入力された前記識別情報を、前記識別情報が入力されていない前記第２のデータに対する入力候補として出力する出力部、
としてコンピュータを機能させることを特徴とする請求項１乃至３いずれか一項記載のデータ処理プログラム。
ソフトウェアのソースコードの更新理由ごとに起票され、当該更新理由の識別情報と、当該更新理由の発生時期と、当該更新理由に応じた作業の完了時期とを含む第１のデータの集合と、前記ソースコードの更新ごとに記録され、当該更新の時期を含む第２のデータの集合であって、一部の前記第２のデータについては、更に、当該第２のデータに係る更新に対応する更新理由の識別情報がユーザによって入力されている集合と、を参照して、
前記一部の第２のデータについて入力された前記識別情報を含む前記第１のデータに含まれる発生時期及び完了時期と、前記識別情報が入力されていない前記第２のデータに含まれる更新の時期との関係に基づいて、当該第２のデータに対して前記識別情報が入力されていない原因を複数のパターンのうちのいずれかに分類する分類手順をコンピュータが実行することを特徴とするデータ処理方法。