JP7214173B1 - ソフトウェア開発を評価するためのシステム及び方法 - Google Patents

Abstract

【課題】より効率的で、アジャイル開発を評価するのにより適したソフトウェア開発を評価するための方法、フトウェア開発を評価するためのシステム及びコンピュータプログラムを提供する。【解決手段】製品達成システム１における評価方法は、パラメータ選択ユニット１１２によって複数のパラメータを選択するステップと、重み付けユニット１１４によって各パラメータの重みを確定するステップと、計算ユニット１１６によって前記パラメータに基づいて製品の達成率を計算するステップとを含む。この方法において、前記パラメータは、バグ修正スコアと、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアの少なくとも１つと、を含む。【効果】プロジェクトの成果をより正確に評価することができ、ソフトウェアエンジニアは、ソフトウェアをより良くするように動機付けられることで、ソフトウェア開発の効率を向上させることができる。【選択図】図１

Description

本発明は、情報と通信技術に関し、特に、ソフトウェア開発を評価するためのシステム及び方法に関する。

製品の達成率を確認するため、以下に示すように、特許文献１と２などのソフトウェア開発を評価する多くの方法がある。ただし従来の方法は、実際の状況を完全に反映しているわけではない。これらの方法の結果は、主に参照用であり、ソフトウェアエンジニアがソフトウェアをより良くするように動機付けられていない。

また、特許文献１と２に開示されている先行技術の評価方法は、ウォーターフォール型ソフトウェア開発を対象とし、アジャイル開発（ａｇｉｌｅ ｄｅｖｅｌｏｐｍｅｎｔ）には適していない。アジャイル開発では、スプリント（ｓｐｒｉｎｔ）間の相関関係が強いが、先行技術の手法ではこの相関関係を考慮に入れていない。このため、上手く運用できない。

したがって、より効率的で、アジャイル開発を評価するのにより適した新しい評価方法が必要である。

特開平０６－０２８０４０号公報 中国特許出願公開第１０９８１５２２０号

本出願の一具体的実施形態において、複数のパラメータを選択するステップと、前記パラメータに基づいて製品の達成率を計算するステップとを含むソフトウェア開発を評価するための方法であって、前記パラメータは、バグ修正スコアと、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアの少なくとも１つとを含む。

本出願の別の具体的実施形態において、複数のパラメータを選択するよう構成されるパラメータ選択ユニットと、前記パラメータに基づいて製品の達成度を計算するように構成される計算ユニットとを含むソフトウェア開発を評価するためのシステムであって、前記パラメータは、バグ修正スコアと、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアの少なくとも１つとを含む。

本出願の別の具体的実施形態において、複数のパラメータが選択される機能、製品の達成率が前記パラメータに基づいて計算される機能をユーザ端末に実現させるためのコンピュータプログラムであって、前記パラメータは、バグ修正スコアと、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアの少なくとも１つとを含む。

本発明によれば、プロジェクトの成果をより正確に評価することができ、ソフトウェアエンジニアは、ソフトウェアをより良くするように動機付けられることで、ソフトウェア開発の効率を向上させることができる。

本発明のいくつかの具体的実施形態に係る製品達成評価システム１のブロック図である。 本発明のいくつかの具体的実施形態に係る製品達成評価システム１を解析するための概念図である。 図１のＳＬＯ ＤＢ１０６の例示的なデータ構造を示す図である。 図１のバグ情報ＤＢ１０８の例示的なデータ構造を示す図である。 図１のリリース情報ＤＢ１１０の例示的なデータ構造を示す図である。 本発明のいくつかの具体的実施形態に係る製品達成評価システム１の構成動作を示す例示的なシーケンス図である。 本発明のいくつかの具体的実施形態に係る製品達成評価システム１の構成動作を示す例示的なシーケンス図である。 本発明のいくつかの具体的実施形態に係る製品達成評価システム１の例示的なＧＵＩ５００を示す図である。 本発明のいくつかの具体的実施形態に係るシステム構成と処理を実行するためのコンピュータハードウェアのブロック図である。

以下、各図面に示されている同一又は類似の部品、構成要素、プログラム、或いは信号は、全ての図面において同じ符号を付けているため、重複する説明は適切に省略されている。また、各図面の説明で重要でない構成要素を省略している。

本発明は、アジャイルソフトウェア開発を評価するための方法及びシステムである。ソフトウェア開発において、アジャイルプロジェクト管理は人気のあるプロジェクト管理方法である。Ｓｃｒｕｍは、複雑な環境で製品を開発、提供、及び保守するための有名かつ人気のあるフレームワークである。Ｓｃｒｕｍにおいて、各チームの作業は目標に分割され、時間的制約のあるイテレーションで完了し、これはスプリント（ｓｐｒｉｎｔ）と呼ばれる。

スプリントは、開発の基本単位であり、通常１週間から１ヶ月の間であり、２週間が最も一般的である。機能が難しいほど、作業を完了するために必要なスプリントが多くなる。通常、新しい機能は、いつも１つのスプリントが完了した後、別のスプリントが開始する前にリリースされる。また、本発明は、各スプリントが自体のリリースを有することができるという事実を利用する。

機能がリリースされる前、リリース日を満たすために時間通りにタスクを完了するための各チームの努力に依存している。機能がリリースされた後、ソフトウェア、サービス、又はＡＰＰの全体的な性能に依存して、サービスの品質を保証する。したがって、機能リリースの前後のパラメータを考慮する必要がある。特に、本発明は、アジャイル開発に適したパラメータを考慮し、前のスプリントの結果／パラメータを現在のスプリントの評価に組み込むことができる。

したがって、本発明のいくつかの実施例に係る製品達成評価システム１は、プロジェクト成果評価のエンハンスを提供する。

図１は、本発明のいくつかの実施例に係る製品達成評価システム１のブロック図である。本明細書のブロック図に示されているブロックは、コンピュータのＣＰＵや機械コンポーネントなどのデバイスのハードウェア内で実現され、コンピュータプログラムなどのソフトウェアにこれらの要素の協働によって実現される機能ブロックを描写する。したがって、当業者は、これらの機能ブロックが、ハードウェアとソフトウェアの組み合わせによって様々な方法で実現され得ることを理解するだろう。

図１に示すように、製品達成評価システム１は、入力ユニット１０２と、記憶ユニット１０４と、ＳＬＯ ＤＢ１０６と、バグ情報ＤＢ１０８と、リリース情報ＤＢ１１０と、パラメータ選択ユニット１１２と、重み付けユニット１１４と、計算ユニット１１６と、分析ユニット１１８と、ディスプレイ１２０とを含み得る。

入力ユニット１０２は、入力を受け取るように構成されている。いくつかの具体的実施形態において、手動で入力を受け取ることができ、例えばデータ及び値をキーインすることである。いくつかの具体的実施形態において、入力ユニット１０２は、マウス、キーボード、タッチパネルなどであり得る。例えばキーボード及びマウスを使用してデータ及び値を手動で入力できる。

いくつかの具体的実施形態において、監視ユニットからパラメータ値をキャプチャーして入力を自動的に受け取ることができる。例えばサーバの品質を保証するためにＳＬＯの値を監視するように構成された監視ユニットがある場合がある。入力ユニット１０２は、該監視ユニットからＳＬＯ値を自動的にキャプチャーすることができる。

記憶ユニット１０４は、入力ユニット１０２に接続され、対応するデータベースに入力を格納するように構成される。入力ユニット１０２は、様々なパラメータを入力として受け取り、次にこれらのパラメータを分類して、それぞれ適切なデータベースに格納するように構成され得る。いくつかの具体的実施形態において、記憶ユニット１０４は、これらのパラメータの検索を高速化するために、後述するパラメータ選択ユニット１１２に直接接続され得る。

ＳＬＯ ＤＢ１０６は、サービスレベルインジケータ（Ｓｅｒｖｉｃｅ ｌｅｖｅｌ ｉｎｄｉｃａｔｏｒ、ＳＬＩ）値を格納するように構成される。SLIは、サービス品質（Ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ、ＱｏＳ）の尺度を表すことができる。SLOは、特定の期間に期待されるサービスレベルを表すことができる。

例えば、ＳＬＯは、１ヶ月のＡＰＩ要求の９９％が３００ミリ秒以内にレスポンスを返さなければならないとして定義され得る。このＳＬＯに対し、ＳＬＩは、目標応答時間を達成する時間割合として報告し、次に所望のサービスレベル（９９％）と比較される。

いくつかの具体的実施形態において、ＳＬＩは、可用性、サービスデスク応答、インシデント応答時間、ＡＰＩ応答時間、遅延、ＡＮＲフリーレートなどを含み得る。いくつかの具体的実施形態において、ＳＬＩとＳＬＯは、実際の必要性に従って決定又は定義することができる。

図３は、図１のＳＬＯ ＤＢ１０６の例示的なデータ構造を示している。ＳＬＯ ＤＢ１０６は、ソフトウェア、サービス又はＡＰＰなどの性能を識別するＳＬＩ値を関連付けて格納する。図３に示すように、ＳＬＩの値をスプリントごとに計算して保存できる。

バグ情報ＤＢ１０８は、ソフトウェアにバグ情報を格納するように構成される。図４は、図１のバグ情報ＤＢ１０８の例示的なデータ構造を示している。バグ情報ＤＢ１０８は、バグ総数及びＰ０、Ｐ１、Ｐ２、Ｐ３などの各優先順位でのバグ数を識別するバグ情報を関連付けて格納する。図４に示すように、バグ情報をスプリントごとに計算して保存することもできる。

リリース情報ＤＢ１１０は、ソフトウェアリリース情報を格納するように構成される。図５は、図１のリリース情報ＤＢ１１０の例示的なデータ構造を示している。リリース情報ＤＢ１１０は、目標リリース日、実際のリリース日などを識別するリリース情報を関連付けて格納する。いくつかの具体的実施形態において、リリース情報ＤＢ１１０は、目標リリース日と実際のリリース日の減算により、機能リリースの遅延を計算することができる。いくつかの具体的実施形態において、リリース情報ＤＢ１１０は、図５に示されるように、機能リリースの遅延を保存することができる。

いくつかの具体的実施形態において、パラメータの値をスプリントごとに計算して保存できる。いくつかの具体的実施形態において、各スプリントの開始時、各スプリントの途中、又は各スプリントの終了時に該値を計算することもできる。いくつかの具体的実施形態において、スプリント期間に該値を平均することによって計算され得る。いくつかの具体的実施形態において、該値はまた、日、週、月、四半期、年などによって計算され得る。いくつかの具体的実施形態において、該値はまた、スプリントの長さに基づいて計算され得る。

パラメータ選択ユニット１１２は、パラメータを選択し、対応するデータベースなどからこれらのパラメータの値を検索するように構成される。パラメータ選択ユニット１１２は、製品達成率を評価するための１つ又は複数のパラメータを選択することができる。いくつかの具体的実施形態において、パラメータ選択ユニット１１２は、手動又は自動でパラメータを選択することができる。いくつかの具体的実施形態において、パラメータ選択ユニット１１２は、機械学習モデル又は任意の他の技術的手段に基づいてパラメータを選択することができる。いくつかの具体的実施形態において、パラメータ選択ユニット１１２は、履歴データ又はリアルタイムデータに従ってパラメータを動的に選択することができる。

重み付けユニット１１４は、パラメータ選択ユニット１１２に接続され、各パラメータの重みを確定するように構成される。いくつかの具体的実施形態において、重みユニット１１４は、重みを確定するために選択され得る。いくつかの具体的実施形態において、重み付けユニット１１４は、均等に、又は各パラメータの重要性に従って重みを確定することができる。いくつかの具体的実施形態において、重み付けユニット１１４は、手動又は自動で重みを確定することができる。いくつかの具体的実施形態において、重み付けユニット１１４は、機械学習モデル又は任意の他の技術的手段に基づいて重みを確定することができる。いくつかの具体的実施形態において、重み付けユニット１１４は、履歴データ又はリアルタイムデータに従って重みを動的に確定することができる。

計算ユニット１１６は、パラメータ選択ユニット１１２及び加重ユニット１１４からのパラメータ及び重み付けに基づいて製品の達成度を計算するように構成される。いくつかの具体的実施形態において、計算ユニット１１６は、各パラメータ又はスコアのために最大値及び／又は最小値の範囲を設定して、極端な値を有するパラメータが製品の達成率の精度を損なうのを防ぐことができる。

分析ユニット１１８は、計算ユニット１１６に接続され、計算ユニット１１６からの結果を受信及び??分析するように構成される。分析ユニット１１８は、計算ユニット１１６からの結果に従って、製品の達成度が良好、正常、又は不良であるかどうかを判断できる。いくつかの具体的実施形態において、分析ユニット１１８は、図１に示されるように、結果及び分析をディスプレイ１２０にさらに表示することができる。

図２は、本発明のいくつかの具体的実施形態に係る製品達成評価システム１を解析するための概念図である。いくつかの具体的実施形態において、パラメータは、ローカルインデックス２００及びグローバルインデックス２２０に分類することができる。ローカルインデックス２００は、それぞれ各チームに関連するパラメータを表すことができる。グローバルインデックス２２０は、プロジェクト全体又はソフトウェア開発に関連するパラメータを表すことができる。

いくつかの具体的実施形態において、ローカルインデックス２００は、オンタイムスコアＯＴなどを含み得る。いくつかの具体的実施形態において、グローバルインデックス２２０は、安定性スコアＳＴＡ、バグ修正スコアＢＦ、ＳＬＯエンハンススコアＳＥなどを含み得る。

オンタイムスコアＯＴは、機能リリース時間厳守を評価するスコア、又はより具体的には機能リリース遅延を評価するスコアであり得る。安定性スコアＳＴＡは、サービス又はソフトウェアの安定性を評価するためのスコアであり得る。バグ修正スコアＢＦは、サービス又はソフトウェア内の修正待ちバグ数を評価するスコアであり得る。ＳＬＯエンハンススコアは、サービス又はソフトウェア内のＳＬＯエンハンススコアを評価するスコアであり得る。いくつかの具体的実施形態において、上記パラメータは、特定の変数から計算されたパーセンテージとして表すことができ、これは以下に説明する。いくつかの具体的実施形態において、上記パラメータは、実際の必要性に応じて表現することができる。

いくつかの具体的実施形態において、リリースバージョン２１０は、ローカルインデックス２００とグローバルインデックス２２０との間に位置付けられることができる。リリースバージョン２１０は、ソフトウェア又はＡＰＰ上で新しい機能をリリースする時点であり得、ソフトウェア又はＡＰＰの新しいバージョンと呼ばれることもある。いくつかの具体的実施形態において、各スプリントには独自のリリースがあると予測される。

いくつかの具体的実施形態において、リリースバージョン２１０の前に考慮されるべきパラメータは、ローカルインデックス２００と呼ばれ得、一方、リリースバージョン２１０の後に考慮されるべきパラメータは、グローバルインデックス２２０と呼ばれ得る。具体的にはリリースバージョン２１０の前にソフトウェアへの評価は各チームの努力に依存し、リリースバージョン２１０の後のソフトウェアへの評価はソフトウェア又はサービスの性能に依存するため、考慮すべきパラメータはリリースバージョン２１０を通じてローカルインデックス２００とグローバルインデックス２２０に分けられる。

いくつかの具体的実施形態において、ローカルインデックス２００は、納期厳守２０２などのパラメータを含み得る。納期厳守２０２は、機能リリースが時間通りであるかどうかを確認するパラメータであり得る。いくつかの具体的実施形態において、機能リリースが時間通りに行われるかどうかの理由は、各チームのスプリント達成率、又は各チームが時間通りにタスクを完了するかどうかであり得る。

いくつかの具体的実施形態において、機能リリースは、所定の日付よりも早く、時間通りに、又は遅くてもよい。いくつかの具体的実施形態において、オンタイムスコアＯＴは、納期厳守２０２の程度の評価に用いられることができる。いくつかの具体的実施形態において、オンタイムスコアＯＴの式は、次のように表され得る。

ＯＴ＝１－（Ｄ_{ｒｅｌｅａｓｅ}－Ｄ_{ｔａｒｇｅｔ}）＊０．１ ………………………（１）

変数Ｄ_{ｒｅｌｅａｓｅ}は実際のリリース日であり得、Ｄ_{ｔａｒｇｅｔ}は目標リリース日であり得る。式（１）によれば、機能リリースが時間厳守の場合、オンタイムスコアＯＴは１になることができ、これは実際のリリース日が目標リリース日と同じであることを意味する。いくつかの具体的実施形態において、機能リリースが遅れる場合、オンタイムスコアＯＴは１未満であり得、逆も同様である。例えば機能リリースが１日遅れた場合、オンタイムスコアＯＴを０．１減らすことができる。

いくつかの具体的実施形態において、グローバルインデックス２２０は、インシデントレベル目標２２２、システムレベル目標２２４及びバグレベル目標２２６等のパラメータを含み得る。インシデントレベル目標２２２は、リリースバージョンのインシデントレベルを確定するパラメータであり得る。

ソフトウェア開発において、ソフトウェアバグは、コンピュータソフトウェア中のエラー、欠陥又は故障により生じた誤った結果や予想外の結果、或いは予期しない方式で動作することである。解決する優先度に応じて、バグはＰ０、Ｐ１、Ｐ２、Ｐ３又はＰ４に分類できる。特に、Ｐ０、Ｐ１などの優先度の高いバグは、操作処理に支障を生じさせてソフトウェアの中断又はパニックを引き起こし、ソフトウェア中のインシデントと見なされる場合がある。したがって、インシデントレベルは、製品の達成度を評価する重要パラメータである。

いくつかの具体的実施形態において、安定性スコアＳＴＡは、インシデントレベル目標２２２の程度を評価するために用いられることができる。いくつかの具体的実施形態において、安定性スコアＳＴＡの式は、次のように表され得る。

ＳＴＡ＝１－（（１＊Ｂ_Ｐ０）＋（０．７＊Ｂ_Ｐ１）） ……………………（２）

変数Ｂ_Ｐ０は、Ｐ０バグの数であり得、Ｂ_Ｐ１はＰ１バグの数であり得る。式（２）によれば、バージョンリリース中にＰ０又はＰ１バグがない場合、安定性スコアＳＴＡは、１であり得る。いくつかの具体的実施形態において、Ｐ０又はＰ１バグがある場合、安定性スコアＳＴＡは１未満であり得、逆もまた同様である。例えばＰ０バグが発生した場合、安定性スコアＳＴＡを１減らすことができ、Ｐ１バグが発生した場合、安定性スコアＳＴＡを０．３減らすことができる。いくつかの具体的実施形態において、実際の必要性に応じて１及び０．７等の係数を調整することができる。

この具体的実施形態の技術的利点の１つは、インシデントが７日以内に発生し、７日以内に解決される場合、該インシデントは、安定性スコアＳＴＡ及び全体的な製品達成率に寄与せず、これにより、エンジニアはインシデントをできる限り早く解決するようになる。

システムレベル目標２２４は、リリースバージョンのサービスレベルを確定するパラメータであり得る。サービスレベルは、サービスプロバイダーのパフォーマンスを測定するための重要な指標である。いくつかの具体的実施形態において、ＳＬＯエンハンススコアＳＥは、システムレベル目標２２４の程度を評価するために用いられることができる。いくつかの具体的実施形態において、ＳＬＯエンハンススコアＳEの式は、次のように表され得る。

ＳＥ＝１－（ＳＬＯ_{ｏｒｉｇｉｎａｌ}－ＳＬＯ_７ｔｈ） …………………………（３）

変数ＳＬＯ_{ｏｒｉｇｉｎａｌ}は、リリース時点でのＳＬＩ値であり得、ＳＬＯ_７ｔｈはリリース時点から７日目のＳＬＩ値であり得る。式（３）によれば、ＳＬＩが７日間変化しない場合、ＳＬＯエンハンススコアＳＥは、１であり得る。いくつかの具体的実施形態において、ＳＬＩが７日以内に減少する場合、ＳＬＯエンハンススコアは１未満であり得、逆もまた同様である。例えばＳＬＩが７日間で０．１％下がった場合、安定性スコアＳＴＡは０．１％下がる可能性がある。

バグレベル目標２２６は、リリースバージョンのバグレベルを確定するパラメータであり得る。いくつかの具体的実施形態において、該バグレベルは、ソフトウェア又はＡＰＰ内のバグ総数を表すことができる。上記のように、優先度に従ってバグを分類できる。優先度の低いバグを緊急に解決する必要はないが、バグが存在すると、ソフトウェアに異常動作が生じる可能性がある。したがって、バグレベル目標２２６は、製品の達成度を評価する重要なパラメータである。

いくつかの具体的実施形態において、バグ修正スコアＢＦは、バグレベル目標２２６の程度を評価するために用いられることができる。いくつかの具体的実施形態において、バグ修正スコアＢＦの式は、次のように表され得る。

ＢＦ＝１－（（Ｂ_７ｔｈ－Ｂ_{ｅｘｐｅｃｔｅｄ}）／（Ｂ_{ｅｘｐｅｃｔｅｄ}－Ｂ_{ｒｅｌｅａｓｅ}）） …（４－１）
Ｂ_{ｅｘｐｅｃｔｅｄ}＝Ｂ_{ｒｅｌｅａｓｅ}＋ＢＩ_{ｐｒｅｄｉｃｔｅｄ} …………………………（４－２）

変数Ｂ_{ｒｅｌｅａｓｅ}は、リリース時点のバグ総数、Ｂ_７ｔｈはリリース時点から７日目のバグ総数、Ｂ_{ｅｘｐｅｃｔｅｄ}はリリース時点から７日目の予測されるバグ総数であり得る。

Ｂ_{ｅｘｐｅｃｔｅｄ}は、Ｂ_{ｒｅｌｅａｓｅ}と予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}の和であり得る。予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}は、１つの機能リリースで増加を予測するバグ数を表することができる。各機能リリースについて、追加のバグは避けられない。したがって、予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}は、各機能リリース中のバグの許容誤差数を表すことができる。

いくつかの具体的実施形態において、予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}は、手動、自動又は他の任意の可能な方法によって決定され得る。いくつかの具体的実施形態において、予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}は、各リリースの定数、例えば３、５、７などであり得る。いくつかの具体的実施形態において、予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}は、変数であり、かつ各機能リリースに基づいて変化し得る。いくつかの具体的実施形態において、リリースしたい機能の複雑さに基づいて予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}を確定し得る。いくつかの具体的実施形態において、予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}は、実際の必要性に応じて確定することができる。

式（４－１）及び式（４－２）によれば、バグ総数が、リリース時点から７日目の予測されるバグ総数と同じ場合、バグ修正スコアＢＦは１の場合があり、これは、Ｂ_７ｔｈがＢ_{ｅｘｐｅｃｔｅｄ}に等しいことを意味する。いくつかの具体的実施形態において、７日以内に発生したバグが予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}よりも多い場合、バグ修正スコアＢＦは１未満であり得、逆もまた同様である。例えば発生したバグが予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}より多い場合、バグ修正スコアＢＦは特定の割合で減少する可能性がある。

図２を参照すると、インシデントレベル目標２２２、システムレベル目標２２４及びバグレベル目標２２６は、それぞれ重みｗ_ｓｔａ、ｗ_ｓｅ及びｗ_ｂｆを有することができる。いくつかの具体的実施形態において、品質スコア２３０は、ローカルインデックス２００及びグローバルインデックス２２０に基づいて計算され得る。いくつかの具体的実施形態において、品質スコア２３０は、全体的な製品達成率ＰＡ_{ｏｖｅｒａｌｌ}と呼ばれることがある。いくつかの具体的実施形態において、オンタイムスコアＯＴ、安定性スコアＳＴＡ、ＳＬＯエンハンススコアＳＥ及びバグ修正スコアＢＦに基づいて全体的な製品達成率ＰＡ_{ｏｖｅｒａｌｌ}を評価することができる。いくつかの具体的実施形態において、全体的な製品達成率ＰＡ_{ｏｖｅｒａｌｌ}の計算式は、次のように表され得る。

ＰＡ_{ｏｖｅｒａｌｌ}＝ｗ_ｓｅ＊ＳＥ＋ｗ_ｏｔ＊ＯＴ＋ｗ_ｓｔａ＊ＳＴＡ＋ｗ_ｂｆ＊ＢＦ

ｗ_ｓｅ、ｗ_ｏｔ、ｗ_ｓｔａ及びｗ_ｂｆは、それぞれ、各スコアの重みであり得る。いくつかの具体的実施形態において、各パラメータの重みは選択可能である。いくつかの具体的実施形態において、各パラメータの重要性が同じるか、異なることによってこれらの重みを確定できる。

いくつかの具体的実施形態において、上記の４つのパラメータの中で、ＳＬＯエンハンススコアＳＥの重みｗ_ｓｅは最大の重みを有し得、オンタイムスコアＯＴの重みｗ_ｏｔが最小の重みを有し得る。例えばｗ_ｓｅ、ｗ_ｏｔ、ｗ_ｓｔａ及びｗ_ｂｆは、それぞれ０．４、０．１、０．３、０．２である得る。いくつかの具体的実施形態において、重みの合計は、１であり得る。ただし、重み及び重みの和は、実際の必要性に応じて柔軟に調整することができる。

上記のように、リリース時点から７日目にバグを直ちに解決し、バグ総数が予測されるバグ総数より少なくなる場合、バグ修正スコアＢＦは１より高くなる可能性があり、これはＢ_７ｔｈがＢ_{ｅｘｐｅｃｔｅｄ}よりも低くなることを意味する。

例えばバグが解決された場合、バグ修正スコアＢＦは、特定のパーセンテージ増加される可能性がある。この具体的実施形態の技術的利点の１つは、より高い製品お達成率に達するため、エンジニアがソフトウェア又はＡＰＰの既存或いは新たに発見されたバグを解決するように動機付けられることができることである。例えばリリースバージョンでＰ１バグが発生し、安定性スコアＳＴＡが０．３下がった場合、全体的な製品達成率ＰＡ_{ｏｖｅｒａｌｌ}を上げる方法はバグを解決することである。

また、バグ総数がますます少なくなると、インシデントの確率はますます低くなり、ソフトウェア又はサービスの安定性はますます高くなる可能性があり、これは、インシデントレベル目標２２２、システムレベル目標２２４及びバグレベル目標２２６が大幅に改善される可能性があることを意味する。

いくつかの具体的実施形態において、Ｂ_{ｅｘｐｅｃｔｅｄ}は、以前スプリントから寄与されたボーナスポイントＢ_{ｂｏｎｕｓ}をさらに含み得、より具体的にはＢ_{ｅｘｐｅｃｔｅｄ}及びＢ_{ｂｏｎｕｓ}の両方を次のように計算できる。

スプリントｎ＋１の場合：Ｂ_{ｅｘｐｅｃｔｅｄ}＝Ｂ_{ｒｅｌｅａｓｅ}＋ＢＩ_{ｐｒｅｄｉｃｔｅｄ}＋Ｂ_{ｂｏｎｕｓ} ……………（５－１）
スプリントｎの場合：Ｂ_{ｂｏｎｕｓ}＝ＢＩ_{ｐｒｅｄｉｃｔｅｄ}－ＢＩ_{ａｃｔｕａｌ} ……………………（５－２）
ｎは、正の整数である。

式（５－１）及び（５－２）によれば、次のスプリントにボーナスポイントＢ_{ｂｏｎｕｓ}をＢ_{ｅｘｐｅｃｔｅｄ}内に追加でき、かつ前のスプリントのパラメータに従ってボーナスポイントＢ_{ｂｏｎｕｓ}を計算することができる。式（５－２）によれば、予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}が７日以内の実際のバグ増加ＢＩ_{ａｃｔｕａｌ}と等しい場合、Ｂ_{ｂｏｎｕｓ}は０になる可能性があり、これは実際のバグ増加ＢＩ_{ａｃｔｕａｌ}が予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}と同じである場合、次のスプリントにボーナスポイントＢ_{ｂｏｎｕｓ}を追加しないことを意味する。いくつかの具体的実施形態において、Ｂ_{ｂｏｎｕｓ}も現在のスプリントに追加され得る。

いくつかの具体的実施形態において、実際のバグ増加ＢＩ_{ａｃｔｕａｌ}が予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}よりも低い場合、Ｂ_{ｂｏｎｕｓ}は０を上回る可能性があり、これは発生したバグが予測よりも少ないことを意味する。例えば実際のバグ増加が予測より２少ない場合、２のボーナスポイントＢ_{ｂｏｎｕｓ}は次のスプリントでＢ_{ｅｘｐｅｃｔｅｄ}に追加される可能性がある。この具体的実施形態の技術的利点の１つは、エンジニアがより少ないバグでより良い機能リリースを提供するように動機付けることである。

いくつかの具体的実施形態において、手動で、自動的に、又は任意の機械学習方法に従って上の式を調整することができる。いくつかの具体的実施形態において、７日間の期間を使用してバージョンリリース後のいくつかのパラメータの傾向を評価する。ただし、周期は柔軟に決定することもできる。いくつかの具体的実施形態において、スプリントの長さに基づいて周期を決定し得る。該周期は、例えば３日、５日、１０日などと決定され得る。いくつかの具体的実施形態において、式中のパラメータ、変数、又は係数は、実際の必要性に応じて柔軟に決定することができる。いくつかの具体的実施形態において、上の式は、実際の必要性に応じて調整することができる。

いくつかの具体的実施形態において、全体的な製品達成率ＰＡ_{ｏｖｅｒａｌｌ}に従って各チームの製品の達成率を計算することができる。図２に示すように、ローカルインデックス２００は、各チームのチームスプリント完了２０４ａ、２０４ｂ、２０４ｃ及びチームスコア２０６ａ、２０６ｂ、２０６ｃそれぞれさらに含むことができる。チームスプリント完了２０４ａ、２０４ｂ、２０４ｃは、１つのスプリントにおける各チームの完了率を表すことができる。いくつかの具体的実施形態において、完了率は、総タスクに対する完了済みタスクのパーセンテージを表すことができる。チームスコア２０６ａ、２０６ｂ、２０６ｃは、各チームの製品達成率ＰＡ_ｔｅａｍを表すことができる。いくつかの具体的実施形態において、ＰＡ_ｔｅａｍの式は、次のように表され得る。

ＰＡ_ｔｅａｍ＝Ｃ_ｔｅａｍ＊ＰＡ_{ｏｖｅｒａｌｌ}－（（１－ＯＴ_ｔｅａｍ）＊ｗ_{ｏｔ－ｔｅａｍ}） …（６－１）
ＯＴ_ｔｅａｍ＝１－Ｄ_{ｄｅｌａｙ}＊０．１ ………………（６－２）
Ｄ_{ｄｅｌａｙ}＝Ｄ_{ａｃｔｕａｌ}－Ｄ_{ｔａｒｇｅｔ} ………………（６－３）

変数Ｃ_ｔｅａｍは、各チームの完了率、ＯＴ_ｔｅａｍは各チームのオンタイムスコア、Ｄ_{ｄｅｌａｙ}は各チームの遅延日数であり得る。式（６－２）によれば、各チームのタスクが時間どおりに完了した場合、各チームのオンタイムスコアＯＴ_ｔｅａｍは、１であり得る。いくつかの具体的実施形態において、各チームのタスクが遅れている場合、ＯＴ_ｔｅａｍは１未満であり得、逆もまた同様である。例えば機能リリースが１日遅れた場合、オンタイムスコアＯＴ_ｔｅａｍが０．１減りうる。

式（６－３）によれば、チームの遅延日数Ｄ_{ｄｅｌａｙ}は、実際の完了日Ｄ_{ａｃｔｕａｌ}と目標完了日Ｄ_{ｔａｒｇｅｔ}との間の差によって確定することができる。

また、各チームのオンタイムスコアＯＴ_ｔｅａｍは、時間通りにタスクを完了することの重要性を強調するため、重みｗ_{ｏｔ－ｔｅａｍ}を有し得る。重みｗ_{ｏｔ－ｔｅａｍ}は、柔軟に決定でき、例えば０、１、２又はこれ以上である。重みｗ_{ｏｔ－ｔｅａｍ}がゼロの場合、各チームの製品達成率ＰＡ_ｔｅａｍは、Ｃ_ｔｅａｍにＰＡ_{ｏｖｅｒａｌｌ}を掛けることで決定できる。いくつかの具体的実施形態において、重みｗ_{ｏｔ－ｔｅａｍ}は、実際の必要性に応じて決定することができる。

いくつかの具体的実施形態において、各チームの製品達成率ＰＡ_ｔｅａｍは、ＰＡ_{ｏｖｅｒａｌｌ}、Ｃ_ｔｅａｍ、ＯＴ_ｔｅａｍなどのパラメータに従って計算し得る。いくつかの具体的実施形態において、各チームの製品達成率ＰＡ_ｔｅａｍに従って全体的に分割された製品達成度を計算し得る。例えば各チームの製品達成率ＰＡ_ｔｅａｍの平均を計算することにより、全体的に分割された製品達成度を計算する。いくつかの具体的実施形態において、全てのチームが機能リリースに含まれるわけではないので、参加していないチームのスコアはゼロを表示し、全体的に分割された製品達成度の計算に寄与しない。

いくつかの具体的実施形態において、製品達成評価システム１は、各パラメータ、変数、又はボーナスポイントのために範囲を設定することができる。より具体的には、各パラメータ、変数、又はボーナスポイントのために最大値及び／又は最小値を事前に決定し得る。例えばＳＬＯエンハンススコアは３０％、５０％、８０％程度などの最小スコアを有し得る。ＳＬＯエンハンススコアが最小スコアよりも低い場合、ＳＬＯエンハンススコアを最小スコアに置き換えることができる。別の例として、バグ修正スコアＢＦは、２００％、３００％、５００％、８００％、１０００％程度などの最大スコアを有し得る。したがって、全体的な製品達成率は、某パラメータの影響を強く受けず、全体的な製品達成率の精度はより良くなる。

いくつかの具体的実施形態において、実際の必要性に従ってパラメータを選択すると共に組み合わせて、製品達成率を計算することができる。例えばバグ修正スコアＢＦをＳＬＯエンハンススコアＳＥと組み合わせて、製品の達成率を計算できる。いくつかの具体的実施形態において、バグ修正スコアＢＦをオンタイムスコアＯＴと組み合わせて、製品の達成率を計算できる。いくつかの具体的実施形態において、バグ修正スコアＢＦを安定性スコアＳＴＡと組み合わせて、製品の達成率を計算できる。バグ修正スコアＢＦが考慮すべき唯一のパラメータである場合、エンジニアは最も単純なバグを修正し、製品の達成率をすばやく上げることができるが、ソフトウェア又はサービスのパフォーマンスをますます低下させる可能性がある。

図６は、本発明のいくつかの具体的実施形態に係る製品達成評価システム１の構成動作を示す例示的なシーケンス図である。ステップＳ３０２において、パラメータ選択ユニット１１２は、パラメータを選択し、対応するデータベースからデータ又は値を検索することができる。ステップＳ３０４において、重み付けユニット１１４は、各パラメータの重みを確定することができる。ステップＳ３０６において、計算ユニット１１６は、パラメータ及び重みに従って製品の達成率を計算することができる。

図７は、本発明のいくつかの具体的実施形態に係る製品達成評価システム１の構成動作を示す例示的なシーケンス図である。ステップＳ３２２において、パラメータ選択ユニット１１２は、パラメータを選択し、対応するデータベースからデータ又は値を検索することができる。ステップＳ３２４において、重み付けユニット１１４は、各パラメータの重みを確定することができる。ステップＳ３２６において、計算ユニット１１６は、各パラメータ、スコア、又はボーナスポイントの範囲を設定することができる。ステップＳ３２８において、計算ユニット１１６は、パラメータ、スコア、又はボーナスポイントが範囲を超えているかどうかをチェックすることができる。いずれかのスコアが範囲を超えている場合（ステップＳ３２８でのチェック結果が範囲を超えている）、計算ユニット１１６は、範囲に合うようにスコアを自動的に調整することができる。スコアは範囲を超えていない場合（ステップＳ３２８でのチェック結果が範囲を超えていない）、計算ユニット１１６は、パラメータ及び重みに従って製品の達成率を計算することができる。

図８は、本発明のいくつかの具体的実施形態に係る製品達成評価システム１の例示的なＧＵＩ５００を示す図である。図８に示すように、製品達成評価システム１のＧＵＩ５００は、パラメータ領域５０２と、変数領域５０４と、重み付け領域５０６と、製品の達成率領域５０８と、ボーナスポイント領域５１０とを含み得る。

パラメータ領域５０２において、パラメータのインデックス及びこれに対応するスコアを表示することができる。変数領域５０４では、パラメータの変数及びこれに対応する値を表示できます。重み付け領域５０６では、対応する各パラメータの重みを表示することができる。製品の達成率領域５０８では、上記のパラメータ、変数、及び重みから計算された製品の達成率を表示することができる。ボーナスポイント領域５１０では、上記のパラメータ及び変数に従ってボーナスポイントを表示することができる。例えば、ボーナスポイント領域５１０は、予測されるバグ増加ＢＩ_{ｐｒｅｄｉｃｔｅｄ}に用いられる基本基準、実際のバグ増加ＢＩ_{ａｃｔｕａｌ}に用いられるグラウンドトゥルース及びＢＩ_{ｐｒｅｄｉｃｔｅｄ}とＢＩ_{ａｃｔｕａｌ}との間の差から計算され得るボーナスポイントを含み得る。いくつかの具体的実施形態において、追加のボーナスポイントは、後続のスプリントなどに役に立つ。

図９は、本発明のいくつかの具体的実施形態に係るシステム構成と処理を実行するためのコンピュータハードウェアのブロック図である。図９において、ＣＰＵ６０４、メインメモリ６０６、ＨＤＤ（ハードディスク）６０８、キーボード６１０、マウス６１２及びディスプレイ６１４がシステムバス６０２に接続されている。ＣＰＵ６０４は、好ましくは、３２ビットまたは６４ビットアーキテクチャに基づく。メインメモリ６０６は、好ましくは２ＧＢ以上の容量を有する。

ハードディスク６０８は、好ましくは、２００ＧＢ以上の容量を有する。いくつかの具体的実施形態において、ハードディスク６０８は、オペレーティングシステム、過去のプロジェクト情報、分析対象となる現在のプロジェクト情報、及び本発明による処理プログラムを格納する。オペレーティングシステムは、Ｌｉｎｕｘ、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷｉｎｄｏｗｓシリーズ及びＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ的Ｍａｃ ＯＳなど、ＣＰＵ６０４と互換性のある任意のオペレーティングシステムにすることができる。

また、ハードディスク６０８は、Ｃ、Ｃ＋＋、Ｃ＃及びＪａｖａ（商標）などのなどの任意のプログラミング言語プロセッサを格納することもできる。該プログラミング言語プロセッサは、本発明に従ってプロセッシングプログラムを作成及び維持するために使用される。いくつかの具体的実施形態において、ハードディスク６０８は、プログラミング言語プロセッサ及び開発環境によってコンパイルされるソースコードを書き込むためのテキストエディタをさらに含むことができる。

キーボード６１０及びマウス６１２は、ハードディスク６０８からメインメモリ６０６にロードされ、ディスプレイ６１４に表示されるオペレーティングシステム又はプログラム（図示せず）を起動するため、及び文字をキーインするために用いられる。ディスプレイ６１４は、好ましくは液晶ディスプレイであり、任意の解像度のディスプレイを使用することができる。ディスプレイ６１４は、本発明による処理結果を表示するために用いられる。

また、上記の具体的実施形態に記載のシステム及方法は、ソリッドステートメモリデバイス、光ディスクストレージデバイス、又は磁気ディスクストレージデバイスなどの非一過性コンピュータ可読ストレージデバイスで構成することができる。或いは、インターネット経由でサーバからプログラムをダウンロードすることもできる。

以上、本発明の技術的内容及び特徴につき説明したが、本発明の技術の分野における通常の知識を有する者は、本発明の教示および開示から逸脱することなく、多種多様な変化及び修正を行なうことができる。したがって、本発明の範囲は、開示された具体的実施形態に限定されず、本発明から逸脱しないその他の変化及び修正を含み、かつ以下の特許請求の範囲に網羅される。

１ 製品達成システム
１０２ 入力ユニット
１０４ 記憶ユニット
１０６ ＳＬＯ ＤＢ
１０８ バグ情報ＤＢ
１１０ リリース情報ＤＢ
１１２ パラメータ選択ユニット
１１４ 重み付けユニット
１１６ 計算ユニット
１１８ 分析ユニット
１２０ ディスプレイ
２００ ローカルインデックス
２０２ 納期厳守
２０４ａ，２０４ｂ，２０４ｃ チームスプリント完了
２０６ａ，２０６ｂ，２０６ｃ チームスコア
２１０ リリースバージョン
２２０ グローバルインデックス
２２２ インシデントレベル目標
２２４ システムレベル目標
２２６ バグレベル目標
２３０ 品質スコア
５０２ パラメータ領域
５０４ 変数領域
５０６ 重み付け領域
５０８ 製品の達成率領域
５１０ ボーナスポイント領域
６０２ システムバス
６０４ ＣＰＵ
６０６ メインメモリ
６０８ ハードディスク（ＨＤＤ）
６１０ キーボード
６１２ マウス
６１４ ディスプレイ
Ｓ３０２，Ｓ３０４，Ｓ３０６，Ｓ３２２，Ｓ３２４，Ｓ３２６，Ｓ３２８，Ｓ３３０，Ｓ３３２ ステップ

Claims (10)

1. パラメータ選択ユニットと計算ユニットとを含むシステムで実行される、ソフトウェア開発を評価するための方法であって、
   前記パラメータ選択ユニットが、複数のパラメータを選択するステップと、
   前記計算ユニットが、前記パラメータに基づいて製品の達成率を計算するステップと
   を含み、
   前記パラメータは、バグ修正スコアと、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアの少なくとも１つとを含むソフトウェア開発を評価するための方法。
2. 前記バグ修正スコアは、修正されたバグ数を評価するスコアで、前記ＳＬＯエンハンススコアはＳＬＯエンハンスを評価するスコアで、前記オンタイムスコアは機能リリースの時間厳守を評価するスコアで、前記安定性スコアはサービス又はソフトウェアの安定性を評価するスコアである請求項１に記載のソフトウェア開発を評価するための方法。
3. 前記システムに含まれる重み付けユニットが、各パラメータの重みを確定するステップと、
   前記計算ユニットが、各パラメータの範囲を設定するステップと、
   前記計算ユニットが、前記パラメータ、重み及び範囲に基づいて製品の達成率を計算するステップと
   をさらに含む請求項１に記載のソフトウェア開発を評価するための方法。
4. 前記計算ユニットが、予測されるバグ増加を設定するステップと、
   前記計算ユニットが、前記予測されるバグ増加に基づいて前記バグ修正スコアを計算するステップと
   をさらに含む請求項１に記載のソフトウェア開発を評価するための方法。
5. 前記計算ユニットが、前記予測されるバグ増加及び実際のバグ増加に基づいて第一スプリントでのボーナスポイントを計算するステップと、
   前記計算ユニットが、前記ボーナスポイントを第二スプリントに追加するステップと
   をさらに含む請求項４に記載のソフトウェア開発を評価するための方法。
6. 前記範囲は、最大値及び／又は最小値を含み、
   前記バグ修正スコアの前記最大値は、その他のパラメータより大きい、
   請求項３に記載のソフトウェア開発を評価するための方法。
7. 前記パラメータは、バグ修正スコア、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアを含む請求項１に記載のソフトウェア開発を評価するための方法。
8. 前記パラメータ選択ユニットが、各チームの完了率及び各チームのオンタイムスコアを取得するステップと、
   前記計算ユニットが、各チームの完了率、各チームのオンタイムスコア及び前記製品の達成率に基づいて各チームの製品達成率を計算するステップと、
   をさらに含む請求項１に記載のソフトウェア開発を評価するための方法。
9. 複数のパラメータを選択するよう構成されるパラメータ選択ユニットと、
   前記パラメータに基づいて製品の達成度を計算するように構成される計算ユニットと
   を含むソフトウェア開発を評価するためのシステムであって、
   前記パラメータは、バグ修正スコアと、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアの少なくとも１つとを含むソフトウェア開発を評価するためのシステム。
10. 複数のパラメータが選択される機能、及び
    製品の達成率が前記パラメータに基づいて計算される機能、
    をユーザ端末に実現させるためのコンピュータプログラムであって
    前記パラメータは、バグ修正スコアと、ＳＬＯエンハンススコア、オンタイムスコア及び安定性スコアの少なくとも１つとを含むコンピュータプログラム。

Images