JP2021128431A - リスク評価システム及びリスク評価方法 - Google Patents

Abstract

【課題】ソフトウェア開発における要件に関する問題を早期に検出し、要件の再検討及び開発人員の確保を可能とするため、要件に基づいてリスクを評価したい。【解決手段】プロセッサ部と、記憶部と、を有するリスク評価システムであって、記憶部は、リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求を示す要求情報と、過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求を示す過去要求情報と、過去のソフトウェア開発プロジェクトにおけるソースコードの変更履歴と、を記憶し、プロセッサ部は、要求情報と過去要求情報との類似度を算出し、過去要求情報と変更履歴とに基づいて、過去要求情報に対応するソースコードの変更履歴を抽出し、類似度と、過去要求情報に対応するソースコードの変更履歴とに基づいて、要求情報を実現するソフトウェア開発におけるリスクを評価する。【選択図】図２

Description

本発明はソフトウェア開発における要件リスクを評価する技術に関する。

ソフトウェア開発における要件は、開発対象のソフトウェアが満たすべき性質であり、ソフトウェアの開発者が定義する。ウォーターフォール型のソフトウェア開発プロセスでは、開発開始時に要件を定義するが、その時点では開発者であってもソフトウェアが何を満たすべきか十分に理解できない場合がある。そのため、要件があいまいになることや不正確になることなどの問題があり、その問題を設計、プログラミング又はテストが進んだ時点で初めて発見することがある。このとき、設計、プログラミング又はテストのやり直しが必要となるが、納期が近づく中で開発人員を追加することは難しく、開発が納期に間に合わない原因となる。このような事態に対し、要件に関する問題を早期に検出できれば、要件の再検討や開発人員の確保が可能になるため、要件に基づいてソフトウェア開発プロジェクトのリスクを評価したい。

ソフトウェア開発プロジェクトのリスクを評価する手法として、特許文献１では、プロジェクトの計画段階において、その計画に潜在するリスクを客観的に評価するリスク評価システムが提案されている。

特開平１１−６６１５０号公報

特許文献１では、計画したプロジェクトに類似する過去のプロジェクトの情報を参照し、その実績から計画プロジェクトのリスクを評価するシステムが提案されている。ただし、このシステムはプロジェクト単位でリスクを評価するため、個々の要件に関する問題を検出することはできない。要件の再検討、及び、当該要件に関する専門知識を有するソフトウェア開発人員の確保のため、個々の要件に関するリスクを評価することが課題となる。

上記課題の少なくとも一つを解決するため、本発明は、プロセッサ部と、記憶部と、を有するリスク評価システムであって、前記記憶部は、リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求を示す要求情報と、過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求を示す過去要求情報と、前記過去のソフトウェア開発プロジェクトにおけるソースコードの変更履歴と、を記憶し、前記プロセッサ部は、前記要求情報と前記過去要求情報との類似性を示す類似度を算出し、前記過去要求情報と前記変更履歴とに基づいて、前記過去要求情報に対応するソースコードの変更履歴を抽出し、前記類似度と、前記過去要求情報に対応するソースコードの変更履歴とに基づいて、前記要求情報を実現するソフトウェア開発におけるリスクを評価することを特徴とする。

本発明の一態様によれば、ソフトウェア開発プロジェクトにおいて要件を満たす上でのリスクを評価する要件リスク評価システムを提供することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明の実施例１の要件リスク評価システムのハードウェア構成を示すブロック図である。 本発明の実施例１の要件リスク評価システムの機能を示すブロック図である。 本発明の実施例１の要件リスク評価システムが保持する要件情報の一例を示す説明図である。 本発明の実施例１の要件リスク評価システムが保持する過去要件情報の一例を示す説明図である。 本発明の実施例１の要件リスク評価システムが保持する要件−ソースコード対応関係情報の一例を示す説明図である。 本発明の実施例１の要件リスク評価システムが保持するソースコード変更情報の一例を示す説明図である。 本発明の実施例１の要件リスク評価システムの利用方法を示すフローチャートである。 本発明の実施例１の要件リスク評価システムによって表示される要件情報入力画面の一例を示す説明図である。 本発明の実施例１の要件リスク評価システムがリスクを評価する処理を示すフローチャートである。 本発明の実施例２の要件リスク評価システムの機能を示すブロック図である。 本発明の実施例２の要件リスク評価システムが保持するプロジェクト情報の一例を示す説明図である。 本発明の実施例２の要件リスク評価システムが保持するソースコード変更情報の一例を示す説明図である。 本発明の実施例２の要件リスク評価システムがリスクを評価する処理を示すフローチャートである。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また、実施形態の中で説明されている諸要素およびその組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、本発明の実施例１の要件リスク評価システムのハードウェア構成を示すブロック図である。

図１に示すように、要件リスク評価システム１０は、プロセッサ１０１、主記憶装置１０２、補助記憶装置１０３、入力装置１０４、出力装置１０５、及び通信装置１０６を備える。

プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）又はＭＰＵ（Micro Processing Unit）を用いて構成される。主記憶装置１０２は、プログラム及びデータを記憶する装置であり、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＮＶＲＡＭ（Non Volatile RAM）等である。プロセッサ１０１及び主記憶装置１０２は情報処理装置を構成する。プロセッサ１０１が、主記憶装置１０２に格納されているプログラムを読み出して実行することによって、要件リスク評価システム１０の様々な機能が実現される。補助記憶装置１０３は、例えば、ＳＳＤ（Solid State Drive）、ハードディスクドライブ、光学式記憶装置、記録媒体の読取／書込装置等である。補助記憶装置１０３に格納されているプログラム及びデータは主記憶装置１０２に随時ロードされる。

入力装置１０４は、ユーザから情報を取得する装置であり、例えば、キーボード、マウス及びタッチパネル等である。出力装置１０５は、ユーザに情報を提供する装置であり、例えば、液晶モニタ、ＬＣＤ（Liquid Crystal Display）、グラフィックカード及びスピーカ等である。通信装置１０６は、ＬＡＮ又はインターネット等の通信手段を介した他の装置との間の通信を実現する有線方式又は無線方式の通信インタフェースであり、例示すれば、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢ（Universal Serial Interface）モジュール、シリアル通信モジュール等である。

図２は、本発明の実施例１の要件リスク評価システムの機能を示すブロック図である。

ユーザインタフェース２０２は、ユーザ２０１からの要件情報の入力を受け付け、入力された要件に関して要件リスク評価部２０４が算出したリスクを表示する。

類似要件検索部２０３は、ユーザ２０１がユーザインタフェース２０２に入力した要件情報と、要件情報管理部２０５から取得した過去要件情報とから、要件に類似する過去要件情報を検索する。

要件リスク評価部２０４は、ユーザ２０１がユーザインタフェース２０２に入力した要件情報と、類似要件検索部２０３が検索した過去要件情報と、ソースコード変更情報管理部２０７が管理するソースコード変更情報とから、要件情報に関するソフトウェア開発上のリスクを評価する。

要件情報管理部２０５は、要件管理システム２１１から過去要件情報を収集し、要件情報データベース２０８に保存する。要件管理システム２１１は、ソフトウェア開発プロジェクトにおける要件を記録するシステムである。

要件−ソースコード対応関係管理部２０６は、トレーサビリティ管理システム２１２から要件−ソースコード対応関係情報を収集し、要件−ソースコード対応関係データベース２０９に保存する。また、要件−ソースコード対応関係管理部２０６は、過去要件情報の入力を受け付け、それを満たすために開発されたソフトウェアのソースコード情報を提供する。トレーサビリティ管理システム２１２は、過去のソフトウェア開発プロジェクトの開発者によって記録された要件、ソフトウェア仕様およびソースコードの対応関係を管理するシステムである。

ソースコード変更情報管理部２０７は、ソースコード構成管理システム２１３からソースコード変更情報を収集し、ソースコード変更情報データベース２１０に保存し、要件リスク評価部２０４からの要求に応じてソースコード変更情報を出力する。ソースコード構成管理システム２１３は、ソフトウェア開発者が、ソースコードに対する変更を行うたびに、変更ファイル、変更日時、コメントおよび変更者名を登録し、ソースコードに対する変更の履歴を参照できるシステムである。

ユーザインタフェース２０２、類似要件検索部２０３、要件リスク評価部２０４、要件情報管理部２０５、要件−ソースコード対応関係管理部２０６及びソースコード変更情報管理部２０７の機能は、プロセッサ１０１が主記憶装置１０２に格納されたプログラムに従って、必要に応じて要件リスク評価システム１０の各部を制御することによって実現される。すなわち、以下の説明において上記の各部が実行する処理は、実際にはプロセッサ１０１が実行する。また、要件情報データベース２０８、要件−ソースコード対応関係データベース２０９及びソースコード変更情報データベース２１０は、主記憶装置１０２又は補助記憶装置１０３に格納される。

要件管理システム２１１と、要件−ソースコード対応関係管理システム２１２と、ソースコード構成管理システム２１３とはそれぞれ、要件リスク評価システム１０と接続されている。図２の例では、要件リスク評価システム１０、要件管理システム２１１、要件−ソースコード対応関係管理システム２１２及びソースコード構成管理システム２１３をそれぞれ独立したシステムとして記載しているが、このような構成は一例であり、これらの任意の二つ以上の機能が一つの計算機システムによって実現されてもよい。

図３は、本発明の実施例１の要件リスク評価システムが保持する要件情報の一例を示す説明図である。

要件情報３０は、分類３０１及び要件３０２を備える。分類３０１は、要件の特徴に基づく分類である。図３において分類３０１は構成要素として大分類と小分類を備えるが、これ以外の構成要素を持っていてもよい。要件３０２は、開発対象のソフトウェアの要件の内容を示す文章である。

図４は、本発明の実施例１の要件リスク評価システムが保持する過去要件情報の一例を示す説明図である。

過去要件情報４０は、要件ＩＤ４０１、プロジェクト名４０２、分類４０３及び要件４０４を備える。要件ＩＤ４０１は、過去要件情報を一意に特定する情報である。プロジェクト名４０２は、プロジェクトを一意に特定する名称である。分類４０３および要件４０４は、それぞれ分類３０１および要件３０２と同様の情報である。

図３に示した要件情報３０は、今回の開発対象のソフトウェアの要件に関する情報である。これに対して、過去要件情報４０は、過去に実行されたプロジェクトにおいて開発されたソフトウェアに関する情報である。これらは、いずれも、要件情報データベース２０８に格納される。

図５は、本発明の実施例１の要件リスク評価システムが保持する要件−ソースコード対応関係情報の一例を示す説明図である。

要件−ソースコード対応関係情報５０は、要件ＩＤ５０１及びソースコードファイル名５０２を備える。要件ＩＤ５０１は、要件を一意に特定するＩＤであり、過去要件情報４０の要件ＩＤ４０１と同一である。ソースコードファイル名５０２は、ソースコードのファイルを一意に特定する名称である。要件−ソースコード対応関係情報５０は、要件ＩＤ５０１で特定される過去要件情報の要件を、ソースコードファイル名５０２で特定されるソースコードによって実現していることを表す。

要件−ソースコード対応関係情報５０は、トレーサビリティ管理システム２１２が保持するトレーサビリティ情報から導出される。トレーサビリティ情報は、要件とソフトウェア仕様との対応関係、及び、ソフトウェア仕様とソースコードとの対応関係を示す情報であり、ソフトウェア開発において要件がソフトウェア仕様およびソースコードに反映されているかを確認するために開発時に記録される。この情報を利用し、過去プロジェクトにおける要件−ソースコード対応関係情報５０が導出される。

ここで、一つの要件が複数のソースコードで実現される場合があり、このとき一つの要件ＩＤ５０１の値に対して複数のソースコードファイル名５０２の値が対応する。

図６は、本発明の実施例１の要件リスク評価システムが保持するソースコード変更情報の一例を示す説明図である。

ソースコード変更情報６０は、プロジェクト名６０１、変更日時６０２及び変更ファイル６０３を備える。プロジェクト名６０１は、プロジェクトを一意に特定する名称である。変更日時６０２は、ソースコードが変更された日時である。変更ファイル６０３は、変更したソースコードのファイル名である。

ソースコード変更情報６０は、ソースコード構成管理システム２１３が管理する情報を根拠に間接的に導出された情報であってもよい。例えば、ソースコード構成管理システム２１３における管理単位がリポジトリであるとき、リポジトリ名とプロジェクト名称との対応関係に基づき、ソースコード変更情報管理部２０７がプロジェクト名称を特定してもよい。

図７は、本発明の実施例１の要件リスク評価システムの利用方法を示すフローチャートである。図７のフローチャートに基づく動作は以下の通りである。

ステップ７０１：ユーザ２０１は、ユーザインタフェース２０２に、ソフトウェア開発プロジェクトにおいて満たすべき要件の要件情報を入力する。このときに入力される条件の例については後述する（図８参照）。

ステップ７０２：類似要件検索部２０３は、ステップ７０１で入力された要件情報に類似する過去要件情報を、要件情報管理部２０５から検索し取得する。過去要件情報の取得は、例えば、要件情報３０の分類３０１と同一の項目を過去要件情報４０の分類４０３が含んでいる場合に、その過去要件情報４０を取得することで行う。

ステップ７０３：類似要件検索部２０３は、ステップ７０２で取得した過去要件情報４０の各々に対し、ステップ７０１で入力された要件情報との類似度を評価する。類似度の評価は、例えば、要件情報の分類３０１と過去要件情報４０の分類４０３とが同一である組の数を類似度とすることで行う。

ステップ７０４：要件リスク評価部２０４は、ステップ７０２で取得した過去要件情報４０の各々を満たすためのソースコードのファイル名を、要件−ソースコード対応関係管理部２０６から取得する。

ステップ７０５：要件リスク評価部２０４は、ステップ７０４で取得したソースコードファイル名をソースコード変更情報管理部２０７へ入力し、ソースコードファイル名で特定されるソースコードの変更履歴を取得する。

ステップ７０６：要件リスク評価部２０４は、ステップ７０３で評価した類似度と、ステップ７０５で取得したソースコードの変更履歴から、ステップ７０１でユーザ２０１が要件情報を入力した要件の各々に対し、ソフトウェア開発上のリスクを算出して、その結果を出力する。このときのリスク算出の詳細については後述する（図９参照）。

図８は、本発明の実施例１の要件リスク評価システムによって表示される要件情報入力画面の一例を示す説明図である。これは、図７のステップ７０１でユーザインタフェース２０２に表示されるものである。

要件情報入力画面８０は、分類入力部８０１、要件入力部８０２、リスク表示部８０３及び確定ボタン８０４を備える。

分類入力部８０１は、要件に関する分類に関し、予めシステムに与えられたリストの中からの選択による入力を受け付ける。リストの構成要素は、例えば、大分類として機能要件、非機能要件の各分類、小分類として機能に関する分類、信頼性、保守性のような非機能要件分類などがある。

要件入力部８０２は、文章による要件の入力を受け付ける。

ユーザが確定ボタン８０４を押すと、ステップ７０２の処理が開始する。

リスク表示部８０３は、ステップ７０６の処理によって出力されたリスクを表示する。

図９は、本発明の実施例１の要件リスク評価システムがリスクを評価する処理を示すフローチャートである。具体的には、これは、ステップ７０６で要件リスク評価部２０４がリスクを評価するときの、データの流れを示す。

処理９０３は、要件リスク評価部２０４が、ソースコード変更履歴９０２に基づき、ソースコード変更量の時系列分布を算出する処理である。ソースコード変更量の時系列分布は、例えば、日付とそれまでに変更されたソースコードの行数との組で表される。

処理９０４は、要件リスク評価部２０４が、処理９０３で算出したソースコード変更量の時系列分布から、開発後半のソースコード変更量を評価する処理である。評価の方法は、例えば、最初のソースコード変更の実行日と最後のソースコード変更の実行日との間を開発期間とし、開発期間の所定の割合が経過して以降の期間を開発後半と定義してその期間内のソースコード変更量を算出するといったものである。ここで、所定の割合とは、５０％に限らず、例えば７０％など、任意に設定することができる。このため、「後半」を「後期」と読み替えてもよい。

処理９０５は、要件リスク評価部２０４が、要件情報と過去要件情報の類似度と、処理９０４で算出した開発後半のソースコード変更量とから、ソフトウェア開発上のリスクを算出する処理である。算出は、例えば、（類似度）×（開発後半のソースコード変更量）の値が所定の値以上であればリスク高と算出する、といった方法による。

この場合、類似度が高く、かつ、開発後半のソースコード変更量が大きいほどリスクが高いと評価される。ソースコードの変更は、それが発生する時期が開発期間の終わりに近いほど、開発の遅延、開発人員の追加及び開発費用の増大といった望ましくない結果を引き起こしやすいと推定され、また、そのようなことが発生した要件と評価対象の要件との類似度が高いほど、評価対象の要件でも同様のことが発生しやすいと推定されるためである。

上記の実施例１に示した要件に基づくリスク評価によって、要件定義時点での要件の再検討、及び、当該要件に関する専門知識を有するソフトウェア開発人員の確保といった対策を取ることが可能となる。

次に、本発明の実施例２を説明する。本実施例は、実施例１において機能構成を変更し、過去のプロジェクト情報を利用したリスク評価を可能にするものである。以下に説明する相違点を除き、実施例２のシステムの各部は、図１から図９に示した実施例１の同一の符号を付された各部と同一の機能を有するため、それらの説明は省略する。

図１０は、本発明の実施例２の要件リスク評価システムの機能を示すブロック図である。

要件−ソースコード対応関係管理部２０６は、ソースコード変更情報管理部２０７からソースコード変更情報を、プロジェクト情報管理部１００１からプロジェクト情報１１０（図１１参照）をそれぞれ収集し、要件−ソースコード対応関係情報５０を導出する。導出は、例えば下記のように行われる。すなわち、プロジェクト情報１１０のチケットＩＤ１１０１及び対応要件ＩＤ１１０４、並びに、ソースコード変更情報６０の対応チケットＩＤ１２０１（図１２参照）及び変更ファイル６０３を使用し、プロジェクト情報１１０のチケットＩＤ１１０１の値とソースコード変更情報６０の対応チケットＩＤ１２０１の値とが一致する場合に、そのプロジェクト情報１１０の対応要件ＩＤ１１０４の値によって特定される要件と、そのソースコード変更情報６０の変更ファイル６０３の値によって特定されるソースコードとが対応関係にあるものとして導出される。

プロジェクト情報管理部１００１は、プロジェクト管理システム１００３からプロジェクト情報を収集し、プロジェクト情報データベース１００２に保存し、他の機能へプロジェクト情報を提供する。プロジェクト管理システム１００３は、プロジェクトにおける工程及び作業の内容と実施時期とを管理するシステムである。

プロジェクト管理システム１００３は、要件リスク評価システム１０と接続されている。

なお、実施例１と共通する各部と同様に、プロジェクト情報管理部１００１の機能は、プロセッサ１０１が主記憶装置１０２に格納されたプログラムに従って、必要に応じて要件リスク評価システム１０の各部を制御することによって実現される。すなわち、以下の説明においてプロジェクト情報管理部１００１が実行する処理は、実際にはプロセッサ１０１が実行する。また、プロジェクト情報データベース１００２は、主記憶装置１０２又は補助記憶装置１０３に格納される。

図１１は、本発明の実施例２の要件リスク評価システムが保持するプロジェクト情報の一例を示す説明図である。

プロジェクト情報１１０は、チケットＩＤ１１０１、チケット区分１１０２、チケット名１１０３、対応要件ＩＤ１１０４、開始日１１０５及び終了日１１０６を備える。チケットＩＤ１１０１は、プロジェクト情報を一意に特定するＩＤである。チケット区分１１０２は、プロジェクト情報の分類を示すものであり、例えば、要件定義の情報であれば要件、テストの情報であればテストとする。チケット名１１０３はプロジェクト情報の名称である。対応要件ＩＤ１１０４は、そのプロジェクト情報がどの要件に関するものかを示すＩＤであり、図４の要件ＩＤ４０１と対応する。開始日１１０５、終了日１１０６は、チケット名１１０３で表される作業の開始日および終了日を表す。

図１２は、本発明の実施例２の要件リスク評価システムが保持するソースコード変更情報の一例を示す説明図である。なお、実施例１の図６と同様の項目については、図６と同じ符号を記載し、その説明を省略する。

対応チケットＩＤ１２０１は、そのソースコード変更がどのプロジェクト情報に関して実施されたかを示すＩＤであり、図１１のチケットＩＤ１１０１と対応する。

図１３は、本発明の実施例２の要件リスク評価システムがリスクを評価する処理を示すフローチャートである。具体的には、これは、図７のステップ７０６で要件リスク評価部２０４がリスクを評価するときの、データの流れを示す。なお、図１３に示す項目のうち、実施例１の図９と同様の項目については、図９と同じ符号を記載し、その説明を省略する。

処理９０４は、要件リスク評価部２０４が、処理９０３で算出したソースコード変更量の時系列分布から、開発後半のソースコード変更量を評価する処理である。評価の方法は、例えば、プロジェクト１３０１におけるテスト工程の開始日から終了日までの期間を開発後半と定義してその期間内のソースコード変更量を算出するといったものである。これは、テスト工程が開始してからのソースコードの変更が、開発の遅延等につながりやすいであろうという推定に基づく。

上記の実施例２によれば、プロジェクト情報を利用することで、工程単位で変更時期を特定し、プロジェクトごとの工程の実施時期を考慮したリスクの評価が可能となる。

上記の本発明の実施形態は、次のような例を含んでもよい。

（１）プロセッサ部（例えばプロセッサ１０１）と、記憶部（例えば主記憶装置１０２及び補助記憶装置１０３の少なくともいずれか）と、を有するリスク評価システム（例えば要件リスク評価システム１０）であって、記憶部は、リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求を示す要求情報（例えば要件情報３０）と、過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求を示す過去要求情報（例えば過去要件情報４０）と、過去のソフトウェア開発プロジェクトにおけるソースコードの変更履歴（例えばソースコード変更履歴６０）と、を記憶し、プロセッサ部は、要求情報と過去要求情報との類似性を示す類似度を算出し（例えばステップ７０３）、過去要求情報と変更履歴とに基づいて、過去要求情報に対応するソースコードの変更履歴を抽出し（例えばステップ７０４から７０５）、類似度と、過去要求情報に対応するソースコードの変更履歴とに基づいて、要求情報を実現するソフトウェア開発におけるリスクを評価する（例えばステップ７０６）。

これによって、ソフトウェア開発プロジェクトにおいて要求を満たす上でのリスクを評価するリスク評価システムを提供することができる。

（２）上記（１）において、プロセッサ部は、過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求と、要求を満たす仕様と、仕様に対応するソースコードと、を対応付けるトレーサビリティ情報（例えばトレーサビリティ管理システム２１２からの情報）を取得し、トレーサビリティ情報とソースコードの変更履歴とに基づいて、過去要求情報に対応するソースコードの変更履歴を抽出する。

これによって、トレーサビリティが管理されているソフトウェア開発プロジェクトにおいて本発明のリスク評価を行うことができる。

（３）上記（１）において、記憶部は、過去のソフトウェア開発プロジェクトにおける作業とソースコードとを対応付けるプロジェクト情報（例えばプロジェクト情報１１０）を記憶し、プロセッサ部は、プロジェクト情報とソースコードの変更履歴とに基づいて、過去要求情報に対応するソースコードの変更履歴を抽出する。

これによって、プロジェクト情報が管理されているソフトウェア開発プロジェクトにおいて本発明のリスク評価を行うことができる。

（４）上記（１）において、プロセッサ部は、ソースコードの変更履歴に基づいて、リスク評価の対象であるソフトウェア開発プロジェクトの開発期間の後期に実行されたソースコード変更量を算出し（例えばステップ９０４）、算出した開発期間の後期のソースコード変更量に基づいてリスクを評価する。

これによって、的確にリスクを評価することができる。

（５）上記（４）において、プロセッサ部は、開発期間のうち、所定の割合の期間が経過した後の期間を開発期間の後期と定義する。

これによって、的確にリスクを評価することができる。

（６）上記（４）において、記憶部は、過去のソフトウェア開発プロジェクトにおける作業とソースコードとを対応付けるプロジェクト情報を記憶し、プロセッサ部は、プロジェクト情報に基づいて、過去のソフトウェア開発プロジェクトにおけるソフトウェアのテストが行われた期間を特定し、テストが行われた期間を開発期間の後期と定義する。

これによって、的確にリスクを評価することができる。

（７）上記（４）において、プロセッサ部は、リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求と過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求との類似度が高く、かつ、当該過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求に対応するソースコードの開発期間の後期における変更量が多いほど高くなるように、リスクを評価する。

これによって、的確にリスクを評価することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１０…要件リスク評価システム、２０１…ユーザ、２０２…ユーザインタフェース、２０３…類似要件検索部、２０４…要件リスク評価部、２０５…要件情報管理部、２０６…要件−ソースコード対応関係管理部、２０７…ソースコード変更情報管理部、２０８…要件情報データベース、２０９…要件−ソースコード対応関係データベース、２１０…ソースコード変更情報データベース、２１１…要件管理システム、２１２…要件−ソースコード対応関係管理システム、２１３…ソースコード構成管理システム

Claims (14)

1. プロセッサ部と、記憶部と、を有するリスク評価システムであって、
   前記記憶部は、
   リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求を示す要求情報と、
   過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求を示す過去要求情報と、
   前記過去のソフトウェア開発プロジェクトにおけるソースコードの変更履歴と、を記憶し、
   前記プロセッサ部は、
   前記要求情報と前記過去要求情報との類似性を示す類似度を算出し、
   前記過去要求情報と前記変更履歴とに基づいて、前記過去要求情報に対応するソースコードの変更履歴を抽出し、
   前記類似度と、前記過去要求情報に対応するソースコードの変更履歴とに基づいて、前記要求情報を実現するソフトウェア開発におけるリスクを評価することを特徴とするリスク評価システム。
2. 請求項１に記載のリスク評価システムであって、
   前記プロセッサ部は、
   前記過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求と、前記要求を満たす仕様と、前記仕様に対応するソースコードと、を対応付けるトレーサビリティ情報を取得し、
   前記トレーサビリティ情報と前記ソースコードの変更履歴とに基づいて、前記過去要求情報に対応するソースコードの変更履歴を抽出することを特徴とするリスク評価システム。
3. 請求項１に記載のリスク評価システムであって、
   前記記憶部は、前記過去のソフトウェア開発プロジェクトにおける作業とソースコードとを対応付けるプロジェクト情報を記憶し、
   前記プロセッサ部は、前記プロジェクト情報と前記ソースコードの変更履歴とに基づいて、前記過去要求情報に対応するソースコードの変更履歴を抽出することを特徴とするリスク評価システム。
4. 請求項１に記載のリスク評価システムであって、
   前記プロセッサ部は、前記ソースコードの変更履歴に基づいて、前記リスク評価の対象であるソフトウェア開発プロジェクトの開発期間の後期に実行されたソースコード変更量を算出し、算出した開発期間の後期のソースコード変更量に基づいてリスクを評価することを特徴とするリスク評価システム。
5. 請求項４に記載のリスク評価システムであって、
   前記プロセッサ部は、前記開発期間のうち、所定の割合の期間が経過した後の期間を前記開発期間の後期と定義することを特徴とするリスク評価システム。
6. 請求項４に記載のリスク評価システムであって、
   前記記憶部は、前記過去のソフトウェア開発プロジェクトにおける作業とソースコードとを対応付けるプロジェクト情報を記憶し、
   前記プロセッサ部は、前記プロジェクト情報に基づいて、前記過去のソフトウェア開発プロジェクトにおけるソフトウェアのテストが行われた期間を特定し、前記テストが行われた期間を前記開発期間の後期と定義することを特徴とするリスク評価システム。
7. 請求項４に記載のリスク評価システムであって、
   前記プロセッサ部は、前記リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求と前記過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求との類似度が高く、かつ、当該過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求に対応するソースコードの前記開発期間の後期における変更量が多いほど高くなるように、リスクを評価することを特徴とするリスク評価システム。
8. プロセッサ部と、記憶部と、を有するリスク評価システムが実行するリスク評価方法であって、
   前記記憶部は、
   リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求を示す要求情報と、
   過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求を示す過去要求情報と、
   前記過去のソフトウェア開発プロジェクトにおけるソースコードの変更履歴と、を記憶し、
   前記リスク評価方法は、
   前記プロセッサ部が、前記要求情報と前記過去要求情報との類似性を示す類似度を算出する第１手順と、
   前記プロセッサ部が、前記過去要求情報と前記変更履歴とに基づいて、前記過去要求情報に対応するソースコードの変更履歴を抽出する第２手順と、
   前記プロセッサ部が、前記類似度と、前記過去要求情報に対応するソースコードの変更履歴とに基づいて、前記要求情報を実現するソフトウェア開発におけるリスクを評価する第３手順と、を含むことを特徴とするリスク評価方法。
9. 請求項８に記載のリスク評価方法であって、
   前記第２手順において、前記プロセッサ部は、前記過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求と、前記要求を満たす仕様と、前記仕様に対応するソースコードと、を対応付けるトレーサビリティ情報を取得し、前記トレーサビリティ情報と前記ソースコードの変更履歴とに基づいて、前記過去要求情報に対応するソースコードの変更履歴を抽出することを特徴とするリスク評価方法。
10. 請求項８に記載のリスク評価方法であって、
    前記記憶部は、前記過去のソフトウェア開発プロジェクトにおける作業とソースコードとを対応付けるプロジェクト情報を記憶し、
    前記第２手順において、前記プロセッサ部は、前記プロジェクト情報と前記ソースコードの変更履歴とに基づいて、前記過去要求情報に対応するソースコードの変更履歴を抽出することを特徴とするリスク評価方法。
11. 請求項８に記載のリスク評価方法であって、
    前記第３手順において、前記プロセッサ部は、前記ソースコードの変更履歴に基づいて、前記リスク評価の対象であるソフトウェア開発プロジェクトの開発期間の後期に実行されたソースコード変更量を算出し、算出した開発期間の後期のソースコード変更量に基づいてリスクを評価することを特徴とするリスク評価方法。
12. 請求項１１に記載のリスク評価方法であって、
    前記第３手順において、前記プロセッサ部は、前記開発期間のうち、所定の割合の期間が経過した後の期間を前記開発期間の後期と定義することを特徴とするリスク評価方法。
13. 請求項１１に記載のリスク評価方法であって、
    前記記憶部は、前記過去のソフトウェア開発プロジェクトにおける作業とソースコードとを対応付けるプロジェクト情報を記憶し、
    前記第３手順において、前記プロセッサ部は、前記プロジェクト情報に基づいて、前記過去のソフトウェア開発プロジェクトにおけるソフトウェアのテストが行われた期間を特定し、前記テストが行われた期間を前記開発期間の後期と定義することを特徴とするリスク評価方法。
14. 請求項１１に記載のリスク評価方法であって、
    前記第３手順において、前記プロセッサ部は、前記リスク評価の対象であるソフトウェア開発プロジェクトにおいて開発するソフトウェアに対する要求と前記過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求との類似度が高く、かつ、当該過去のソフトウェア開発プロジェクトにおいて開発したソフトウェアに対する要求に対応するソースコードの前記開発期間の後期における変更量が多いほど高くなるように、リスクを評価することを特徴とするリスク評価方法。

Images