WO2022038666A1 - 分析装置、分析方法、およびプログラム - Google Patents

分析装置、分析方法、およびプログラム Download PDF

Info

Publication number
WO2022038666A1
WO2022038666A1 PCT/JP2020/031080 JP2020031080W WO2022038666A1 WO 2022038666 A1 WO2022038666 A1 WO 2022038666A1 JP 2020031080 W JP2020031080 W JP 2020031080W WO 2022038666 A1 WO2022038666 A1 WO 2022038666A1
Authority
WO
WIPO (PCT)
Prior art keywords
commit
development
sprint
history
statistical information
Prior art date
Application number
PCT/JP2020/031080
Other languages
English (en)
French (fr)
Inventor
謙輔 高橋
翔 金丸
友基 池谷
剛司 豊嶋
Original Assignee
日本電信電話株式会社
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 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2020/031080 priority Critical patent/WO2022038666A1/ja
Priority to JP2022543833A priority patent/JPWO2022038666A1/ja
Priority to US18/019,964 priority patent/US20230273773A1/en
Publication of WO2022038666A1 publication Critical patent/WO2022038666A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management

Definitions

  • the present invention relates to an analyzer, an analysis method, and a program.
  • the development team is improving the process by looking back (retrospective) at the end of each cycle, but many of them are based on the subjectivity of the developer, and there is no objective index. was there.
  • Non-Patent Document 1 focuses on "value” and proposes productivity evaluation metrics based on the concept of value stream map (VMS) in lean software development.
  • VMS value stream map
  • Non-Patent Document 1 is a productivity evaluation using man-hours as an index, and does not mention analysis of the history of the repository used by the development team.
  • Non-Patent Document 2 the activity of team activities in a large-scale open source software (OSS) project is quantified by calculating the Gini coefficient based on the number of people involved in the development of OSS and the period.
  • OSS open source software
  • the present invention has been made in view of the above, and an object thereof is to enable efficient management of agile development.
  • the analyzer of one aspect of the present invention is an analyzer that analyzes the results of a software development team that repeats the development cycle, and acquires the commit history from the development repository that stores the deliverables of the software development team.
  • a unit, an analysis unit that aggregates the commit history and calculates statistical information in units of the development cycle, and a display unit that displays the statistical information are provided.
  • the analysis method of one aspect of the present invention is an analysis method for analyzing the results of a software development team that repeats a development cycle, in which a computer obtains a commit history from a development repository that stores the products of the software development team. It is acquired, the commit history is aggregated in the unit of the development cycle, statistical information is calculated, and the statistical information is displayed.
  • FIG. 1 is a diagram showing an example of the configuration of the analyzer of the present embodiment.
  • FIG. 2 is a diagram showing an example of the commit history.
  • FIG. 3 is a diagram showing an example of a sprint period.
  • FIG. 4A is a display example of the Gini coefficient for each sprint.
  • FIG. 4B is a display example of the number of committed lines for each sprint.
  • FIG. 4C is a display example of a logarithmic histogram of the number of commit lines.
  • FIG. 4D is a display example of the Lorenz curve.
  • FIG. 5 is a flowchart showing an example of the processing flow of the analyzer.
  • FIG. 6 is a flowchart showing an example of the processing flow of the analyzer that calculates the Gini coefficient as statistical information.
  • FIG. 7 is a display example of the Gini coefficient for each sprint.
  • FIG. 8 is a display example of a logarithmic histogram of the number of commit lines.
  • FIG. 9 is a diagram
  • FIG. 1 is a diagram showing an example of the configuration of the analyzer 1.
  • the analysis device 1 shown in the figure includes an acquisition unit 11, an analysis unit 12, and a display unit 13, and analyzes the results of a development team that repeatedly carries out a development cycle (also referred to as a sprint period).
  • the acquisition unit 11 acquires the commit history from the development repository 2.
  • the development repository 2 is a place where a version control system used for software development stores files such as source code and documents and various data such as change history.
  • a version control system for example, a system such as Git or SVN in which a commit history remains is used. Commit is to store the file created or modified by the developer in the development repository 2.
  • the commit history is the history of the development team's commits.
  • FIG. 2 shows an example of the commit history acquired by the acquisition unit 11.
  • the commit history is recorded in commit units.
  • FIG. 2 shows an example of the commit history recorded in one commit.
  • the commit history shown in FIG. 2 includes the commit date, the commit author, the number of modified files, the number of modified lines, the number of added lines, the number of deleted lines, and the commit message.
  • the commit date is the date when the file was committed.
  • the commit author is the name of the person who committed, and the name of the person who actually modified the file.
  • the number of modified files is the number of files modified by this commit.
  • the number of modified lines is the total number of lines modified by this commit, and is the sum of the number of added lines and the number of deleted lines.
  • the number of additional lines is the number of lines added in this commit.
  • the number of deleted lines is the number of lines deleted by this commit.
  • the commit message is the message given to this commit.
  • the commit history may include other information.
  • the analysis unit 12 aggregates the commit history in units of repeated sprint periods and calculates statistical information.
  • the sprint period is given a start date and an end date, for example, as shown in FIG.
  • the analysis unit 12 aggregates the commit history for each sprint period indicated by the start date and the end date.
  • the statistical information obtained by the analysis unit 12 includes, for example, a Gini coefficient for each sprint, a number of committed lines for each sprint, a histogram for the number of committed lines, and a Lorenz curve.
  • the statistical information required by the analysis unit 12 is not limited to these.
  • FIGS. 4A to 4D show an example of statistical information visualized and displayed.
  • FIG. 4A is a display example of the Gini coefficient for each sprint.
  • FIG. 4B is a display example of the number of committed lines for each sprint.
  • FIG. 4C is a display example of a logarithmic histogram of the number of commit lines.
  • FIG. 4D is a display example of the Lorenz curve.
  • FIG. 5 is a flowchart showing an example of the processing flow of the analyzer 1 of the present embodiment. The process of FIG. 5 is performed at a predetermined timing, for example, every time the sprint is completed.
  • step S1 the acquisition unit 11 acquires the commit history from the development repository 2.
  • the acquisition unit 11 may exclude a specific commit history, or may correct the notational fluctuation of the name of the commit author in the commit history. Details of the preprocessing by the acquisition unit 11 will be described later.
  • step S2 the analysis unit 12 aggregates the commit history in units of the sprint period and calculates statistical information.
  • An example of calculating the Gini coefficient as statistical information will be described later.
  • step S3 the display unit 13 visualizes and displays the statistical information.
  • the user for example, the development team
  • the user can quantitatively compare the sprints, and can objectively measure the productivity and stability of the development team in agile software development.
  • the Gini coefficient is an index that measures income, uneven distribution of wealth, and inequality in energy consumption.
  • the history showing the results in software development such as the number of commit lines, the number of commits, or the number of files is aggregated as a key, and the genie coefficient is calculated by looking at the uneven distribution of the results in software development up to a certain sprint. We will quantitatively visualize the uneven distribution of results in software development.
  • the Gini coefficient is defined as the ratio of the area surrounded by the Lorenz curve and the evenly divided wiring to the area below the evenly divided wiring.
  • the evenly divided wiring is a Lorenz curve when the distribution of results is uniform.
  • the Gini coefficient can be expressed by the following equation using the integral of the Lorenz curve L (F).
  • the range of values taken by the Gini coefficient is 0 to 1, and the larger the value, the larger the disparity in the group.
  • step S1 the acquisition unit 11 acquires the commit history from the development repository 2.
  • step S21 the analysis unit 12 specifies the sprint including the commit history based on the commit date of the commit history.
  • step S22 the analysis unit 12 aggregates the values of the keys for which the Gini coefficient is to be calculated for each sprint. For example, if the number of commit lines is used as a key, the number of lines in sprint 1, the number of lines in sprint 2, ..., The number of lines in sprint X can be obtained.
  • the number of commit lines is an example and is not limited to this. Data that can be obtained from the commit history such as the number of files and the number of commits can be used as a key.
  • step S23 the analysis unit 12 calculates the Gini coefficient based on the aggregated values.
  • the Gini coefficient of sprint n can be calculated by the following formula.
  • the analysis unit 12 repeats steps S22 and S23 as many times as necessary. For example, when software development has been performed up to sprint X, steps S22 and S23 are repeated to calculate the Gini coefficient from sprint 1 to sprint X.
  • step S24 the analysis unit 12 calculates the difference between the Gini coefficients between the sprints. If the difference is within a certain range, it can be judged that the equivalent deliverables can be stably produced. If the difference increases above a certain level, the development team may be overloaded. If the difference is reduced above a certain level, the development team may have a problem in producing results.
  • step S3 the display unit 13 visualizes and displays the statistical information.
  • FIG. 7 shows an example of displaying the Gini coefficient for each sprint.
  • the sprint 1 represented by the reference numeral 110 only the data of the sprint 1 is used for the calculation of the Gini coefficient, so that the Gini coefficient is 0 (no uneven distribution). Since the Gini coefficient has increased in the section up to sprint 7 indicated by reference numeral 120, it is probable that a large amount of deliverables were created. It can be seen that the Gini coefficient is stable in the section from sprint 8 to 14 indicated by reference numeral 130, and a certain result is produced. From the sprint 15 indicated by reference numeral 140, the Gini coefficient is increased again.
  • the acquisition unit 11 may exclude the commit history that matches the exclusion condition.
  • the commit history acquired by the acquisition unit 11 includes commit histories other than the commit history indicating the results of the development team, which affects the measurement of stability as the development team. Therefore, the acquisition unit 11 excludes, for example, the commit history in which the character "auto" is included in the commit message. As a result, the commit history of automatic commit by CI can be excluded from the processing target.
  • the part of the logarithmic histogram shown by reference numeral 150 in FIG. 8 carries out a large number of lines with one commit, which is considered to hinder the analysis.
  • the horizontal axis is log 10 of the number of correction lines. Therefore, for example, in the class where the horizontal axis in reference numeral 150 is 5, 10 5 (100,000) rows are corrected by one commit. Therefore, the acquisition unit 11 excludes the commit history in which the number of correction lines in one commit is too large. As a result, the commit history that seems to be an abnormal commit can be excluded from the processing target.
  • the acquisition unit 11 may correct the notation fluctuation of the name of the commit author in the commit history.
  • the name of the committer can be set arbitrarily.
  • the person in charge of development develops using multiple development environments (for example, desktop and server), there is a possibility that the name notation may fluctuate in each development environment.
  • the analysis unit 12 aggregates the statistical information for each person in charge of development, if the notation of the name fluctuates, the analysis of the commit history will be affected.
  • the acquisition unit 11 converts the commit author in the commit history to correct the notation fluctuation.
  • the commit author is extracted from the commit history, and the errata before / after the conversion of the commit author is created for the same person including a plurality of commit authors.
  • the acquisition unit 11 mechanically converts the name of the commit author using the errata.
  • the acquisition unit 11 calculates the standardized Levenshtein distance between the name listed and the name of the committed author, and converts the calculated standardized Levenshtein distance into a name smaller than the threshold value and the minimum.
  • the acquisition unit 11 may calculate the Jaro-Winkler distance between the name listed and the name of the committed author, and convert the calculated Jaro-Winkler distance into a name larger than the threshold value and maximum. ..
  • the method for correcting the notational fluctuation is not limited to the above.
  • the analyzer 1 of the present embodiment is an analyzer that analyzes the results of the software development team that repeatedly executes sprints, and is a commit history from the development repository 2 that stores the deliverables of the software development team.
  • the acquisition unit 11 for acquiring the software, the analysis unit 12 for totaling the commit history in units of sprints and calculating the statistical information, and the display unit 13 for displaying the statistical information are provided.
  • the analysis unit 12 calculates the Gini coefficient in which the uneven distribution of the results of the software development team is viewed in sprint units. This makes it possible to quantitatively visualize the uneven distribution of continuous result production, and enables the development team to objectively evaluate productivity and stability. As a result, efficient management of agile development can be enabled.
  • the analyzer 1 described above includes, for example, a central processing unit (CPU) 901, a memory 902, a storage 903, a communication device 904, an input device 905, and an output device 906, as shown in FIG.
  • CPU central processing unit
  • a general-purpose computer system can be used.
  • the analyzer 1 is realized by the CPU 901 executing a predetermined program loaded on the memory 902.
  • This program can be recorded on a computer-readable recording medium such as a magnetic disk, an optical disk, or a semiconductor memory, or can be distributed via a network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Software Systems (AREA)
  • Educational Administration (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Stored Programmes (AREA)

Abstract

スプリントを繰り返して実施するソフトウェア開発チームの成果を分析する分析装置１であって、ソフトウェア開発チームの成果物を格納する開発リポジトリ２からコミット履歴を取得する取得部１１と、スプリントの単位でコミット履歴を集計して統計情報を算出する解析部１２と、統計情報を表示する表示部１３を備える。解析部１２は、ソフトウェア開発チームの成果の偏在性をスプリントの単位でみたジニ係数を算出する。

Description

分析装置、分析方法、およびプログラム
　本発明は、分析装置、分析方法、およびプログラムに関する。
　アジャイルソフトウェア開発においては、動作するソフトウェアの創出に価値を置き、短期間のサイクルでの開発を繰り返し実施することで、変化する要件に柔軟に対応している。
秦泉寺，他、"ＶＳＭを用いたアジャイル開発の生産性指標の提案とウォータフォール開発との比較"，情報処理学会，研究報告ソフトウェア工学，2019-SE-208，pp. 1-7 Ayako Masuda, et.al, "Team Activities Measurement Method for Open Source Software Development Using the Gini Coefficient"，2019 IEEE ICSTW.
　しかしながら、アジャイル開発を行う開発チームの生産性および安定性については、開発チーム自身では内部の体感として理解できるものの、外部から見た時に客観的に測定することが難しいという課題があった。
　また、開発チームは、各サイクルの終了時に振り返り（レトロスペクティブ）を行うことでプロセスの改善を実施しているが、開発者の主観に基づくものが多く、客観的な指標が存在していないという課題があった。
　アジャイル開発の生産性の客観的な指標を算出するために、質問紙を用いたアンケートや人月工数やテスト密度といったプロジェクト管理の強化が存在しているが、計測による開発メンバーへの負担が増大するといった課題が存在している。
　非特許文献１では、「価値」に着目し、リーンソフトウェア開発におけるバリュー・ストリーム・マップ（ＶＭＳ）の考え方を基本とした生産性評価のメトリクスが提案されている。非特許文献１は工数を指標とした生産性評価であり、開発チームで用いられるリポジトリの履歴の分析については言及されていない。
　非特許文献２では、大規模オープンソースソフトウェア（ＯＳＳ）プロジェクトにおけるチーム活動の活発度をＯＳＳの開発に携わった人数と期間をもとにジニ係数を算出して定量化している。しかしながら、アジャイル開発におけるスプリントごとの継続的な生産性および安定性の測定については言及されていない。
　本発明は、上記に鑑みてなされたものであり、アジャイル開発の効率的なマネジメントを可能にすることを目的とする。
　本発明の一態様の分析装置は、開発サイクルを繰り返して実施するソフトウェア開発チームの成果を分析する分析装置であって、前記ソフトウェア開発チームの成果物を格納する開発リポジトリからコミット履歴を取得する取得部と、前記開発サイクルの単位で前記コミット履歴を集計して統計情報を算出する解析部と、前記統計情報を表示する表示部を備える。
　本発明の一態様の分析方法は、開発サイクルを繰り返して実施するソフトウェア開発チームの成果を分析する分析方法であって、コンピュータが、前記ソフトウェア開発チームの成果物を格納する開発リポジトリからコミット履歴を取得し、前記開発サイクルの単位で前記コミット履歴を集計して統計情報を算出し、前記統計情報を表示する。
　本発明によれば、アジャイル開発の効率的なマネジメントを可能にすることができる。
図１は、本実施形態の分析装置の構成の一例を示す図である。 図２は、コミット履歴の一例を示す図である。 図３は、スプリント期間の一例を示す図である。 図４Ａは、スプリント毎のジニ係数の表示例である。 図４Ｂは、スプリント毎のコミットライン数の表示例である。 図４Ｃは、コミットライン数の対数ヒストグラムの表示例である。 図４Ｄは、ローレンツ曲線の表示例である。 図５は、分析装置の処理の流れの一例を示すフローチャートである。 図６は、統計情報としてジニ係数を算出する分析装置の処理の流れの一例を示すフローチャートである。 図７は、スプリント毎のジニ係数の表示例である。 図８は、コミットライン数の対数ヒストグラムの表示例である。 図９は、分析装置のハードウェア構成の一例を示す図である。
　以下、図面を参照しながら、一実施の形態の分析装置を説明する。
　図１は、分析装置１の構成の一例を示す図である。同図に示す分析装置１は、取得部１１、解析部１２、および表示部１３を備えて、開発サイクル（スプリント期間ともいう）を繰り返して実施する開発チームの成果を分析する。
　取得部１１は、開発リポジトリ２からコミット履歴を取得する。開発リポジトリ２は、ソフトウェア開発に用いるバージョン管理システムがソースコードやドキュメントなどのファイルおよび変更履歴などの各種データを保管する場所である。バージョン管理システムとしては、例えば、ＧｉｔまたはＳＶＮなどのコミット履歴が残るものを利用する。コミットとは、開発者が作成または修正したファイルを開発リポジトリ２に格納することである。コミット履歴とは、開発チームのコミットの履歴である。
　図２に、取得部１１が取得するコミット履歴の一例を示す。コミット履歴は、コミット単位で記録される。図２は、１回のコミットで記録されるコミット履歴の一例を示している。図２に示すコミット履歴は、コミット日、コミット著者、修正ファイル数、修正ライン数、追加ライン数、削除ライン数、およびコミットメッセージを含む。コミット日は、ファイルをコミットした日付である。コミット著者は、コミットした人の名前であり、実際にファイルを修正した人の名前である。修正ファイル数は、このコミットで修正したファイル数である。修正ライン数は、このコミットで修正した総ライン数であり、追加ライン数と削除ライン数を合計した値である。追加ライン数は、このコミットで追加したライン数である。削除ライン数は、このコミットで削除したライン数である。コミットメッセージは、このコミットに付与されたメッセージである。コミット履歴は、これ以外の情報を含んでもよい。
　解析部１２は、繰り返されるスプリント期間の単位でコミット履歴を集計して統計情報を算出する。スプリント期間は、例えば図３に示すように、開始日と終了日が与えられている。解析部１２は、開始日と終了日で示されるスプリント期間毎にコミット履歴を集計する。解析部１２が求める統計情報としては、例えば、スプリント毎のジニ係数、スプリント毎のコミットライン数、コミットライン数のヒストグラム、およびローレンツ曲線などがある。なお、解析部１２が求める統計情報をこれらに限定するものではない。
　表示部１３は、解析部１２が算出した統計情報を可視化する。図４Ａ～４Ｄに、可視化して表示した統計情報の一例を示す。図４Ａは、スプリント毎のジニ係数の表示例である。図４Ｂは、スプリント毎のコミットライン数の表示例である。図４Ｃは、コミットライン数の対数ヒストグラムの表示例である。図４Ｄは、ローレンツ曲線の表示例である。
　次に、本実施形態の分析装置１の動作について説明する。
　図５は、本実施形態の分析装置１の処理の流れの一例を示すフローチャートである。図５の処理は、所定のタイミング、例えばスプリントが終了する度に実施される。
　ステップＳ１にて、取得部１１は、開発リポジトリ２からコミット履歴を取得する。取得部１１は、特定のコミット履歴を除外してもよいし、コミット履歴のコミット著者の名前の表記揺れを是正してもよい。取得部１１による前処理の詳細は後述する。
　ステップＳ２にて、解析部１２は、スプリント期間の単位でコミット履歴を集計して、統計情報を算出する。統計情報としてジニ係数を算出する例については後述する。
　ステップＳ３にて、表示部１３は、統計情報を可視化して表示する。利用者（例えば開発チーム）は、分析装置１を操作し、表示する統計情報を選択したり、表示態様を選択したりできる。
　以上の処理により、利用者は、スプリント間を定量的に比較することができ、アジャイルソフトウェア開発における開発チームの生産性および安定性を客観的に測定することが可能となる。
　次に、統計情報としてジニ係数を利用する実施例について説明する。
　ジニ係数とは、所得、富の偏在性、エネルギー消費における不平等さなどを測る指標である。本実施形態では、コミットライン数、コミット数、あるいはファイル数などのソフトウェア開発における成果を示す履歴をキーとして集計し、あるスプリントまでのソフトウェア開発における成果の偏在性をスプリント単位でみたジニ係数を算出し、ソフトウェア開発における成果の偏在性を定量的に可視化する。
　ジニ係数は、ローレンツ曲線と均等分配線によって囲まれる領域と均等分配線より下の領域の面積の比として定義される。均等分配線とは、成果の分布が一様である場合のローレンツ曲線である。ジニ係数は、ローレンツ曲線Ｌ（Ｆ）の積分を用いて次式で表現できる。
Figure JPOXMLDOC01-appb-M000001
　ジニ係数がとる値の範囲は０から１で、値が大きいほどその集団における格差が大きい状態であるという評価になる。
　図６のフローチャートを参照し、統計情報としてジニ係数を算出する処理の流れを説明する。
　ステップＳ１にて、取得部１１は、開発リポジトリ２からコミット履歴を取得する。
　ステップＳ２１にて、解析部１２は、コミット履歴のコミット日をもとに、コミット履歴を含むスプリントを特定する。
　ステップＳ２２にて、解析部１２は、ジニ係数を算出したいキーの値をスプリント毎に集計する。例えば、キーとしてコミットライン数を用いると、スプリント１のライン数、スプリント２のライン数、・・・、スプリントＸのライン数が得られる。コミットライン数は一例でありこれに限定するものではない。ファイル数、コミット数などのコミット履歴から取得可能なデータをキーとして用いることができる。
　ステップＳ２３にて、解析部１２は、集計された値をもとにジニ係数を算出する。解析対象となる集団の数値をｘ＝｛ｘ１，ｘ２，・・・，ｘｎ｝と表すと、以下の式でスプリントｎのジニ係数を算出可能である。
Figure JPOXMLDOC01-appb-M000002
　解析部１２は、ステップＳ２２，Ｓ２３を必要なだけ繰り返す。例えば、ソフトウェア開発がスプリントＸまで行われていた場合、ステップＳ２２，Ｓ２３を繰り返してスプリント１からスプリントＸまでのジニ係数を算出する。
　ステップＳ２４にて、解析部１２は、スプリント間のジニ係数の差分を算出する。差分が一定範囲内の場合は、安定して同等の成果物が創出できていると判断できる。差分が一定以上に増加している場合は、開発チームに負荷が掛かっている可能性がある。差分が一定以上に減少している場合は、開発チームに成果創出の課題が発生している可能性がある。
　ステップＳ３にて、表示部１３は、統計情報を可視化して表示する。
　図７に、スプリント毎のジニ係数の表示例を示す。符号１１０で示すスプリント１では、ジニ係数の算出にスプリント１のデータのみを用いるので、ジニ係数は０（偏在性無し）となる。符号１２０で示すスプリント７までの区間では、ジニ係数が上昇しているので、成果物の大量創出があったと考えられる。符号１３０で示すスプリント８から１４までの区間は、ジニ係数が安定しており、一定の成果を創出していることが分かる。符号１４０で示すスプリント１５から、再度、ジニ係数が上昇している。
　次に、コミット履歴を解析する前に行う前処理について説明する。
　コミット履歴の前処理として、取得部１１は、除外条件に合致するコミット履歴を除外してもよい。
　スプリントの途中で継続的インテグレーション（ＣＩ）ツールによる自動コミットが追加されることがある。この場合、取得部１１の取得したコミット履歴には、開発チームによる成果を示すコミット履歴以外のコミット履歴が混在し、開発チームとしての安定性の測定に影響が出てしまう。そこで、取得部１１は、例えば、コミットメッセージに「ａｕｔｏ」という文字が入っているコミット履歴を除外する。これにより、ＣＩによる自動コミットのコミット履歴を処理対象から除外できる。
　また別の例として、図８の対数ヒストグラムの符号１５０で示す部分は、大量のライン数を一回のコミットで実施しており、解析の妨げとなると考えられる。図８では、修正ライン数のｌｏｇ１０を横軸としている。したがって、例えば符号１５０内の横軸が５の階級では、１０の５乗（１０万）行を１回のコミットで修正していることになる。そこで、取得部１１は、１回のコミットにおける修正ライン数が大きすぎるコミット履歴を除外する。これにより、異常コミットと思われるコミット履歴を処理対象から除外できる。
　このように、前処理として除外条件に合致するコミット履歴を分析対象から除外することで、開発チームの安定性を客観的に測定することが可能となる。
　コミット履歴の前処理として、取得部１１は、コミット履歴のコミット著者の名前の表記揺れを是正してもよい。
　例えば、バージョン管理システムとして広く利用されているＧｉｔでは、コミット者の名前を任意に設定できる。開発担当者が複数の開発環境（例えばデスクトップとサーバ）を利用して開発している場合、開発環境毎に名前の表記揺れが発生する可能性がある。解析部１２が開発担当者毎の統計情報を集計する場合、名前の表記揺れが発生すると、コミット履歴の分析に影響が出てしまう。
　そこで、取得部１１は、コミット履歴のコミット著者を変換して表記揺れを是正する。例えば、コミット履歴からコミット著者を抽出し、同一人物であって複数のコミット著者を含むものについて、コミット著者の変換前／変換後の正誤表を作成しておく。取得部１１は、正誤表を用いて機械的にコミット著者の名前を変換する。
　あるいは、開発チームに存在している開発担当者の名前の一覧を作成しておく。取得部１１は、一覧に記載されている名前とコミット著者の名前の標準化レーベンシュタイン距離を算出し、算出された標準化レーベンシュタイン距離が閾値より小さい、かつ、最小となる名前に変換する。取得部１１は、一覧に記載されている名前とコミット著者の名前のジャロウィンクラー距離を算出し、算出されたジャロウィンクラー距離が閾値より大きい、かつ、最大となる名前に変換してもよい。なお、表記揺れの是正方法は上記に限るものではない。
　以上説明したように、本実施形態の分析装置１は、スプリントを繰り返して実施するソフトウェア開発チームの成果を分析する分析装置であって、ソフトウェア開発チームの成果物を格納する開発リポジトリ２からコミット履歴を取得する取得部１１と、スプリントの単位でコミット履歴を集計して統計情報を算出する解析部１２と、統計情報を表示する表示部１３を備える。また、解析部１２は、ソフトウェア開発チームの成果の偏在性をスプリントの単位でみたジニ係数を算出する。これにより、継続的な成果創出についての偏在性を定量的に可視化でき、開発チームにおける生産性と安定性の客観的な評価が可能となる。その結果、アジャイル開発の効率的なマネジメントを可能にできる。
　上記説明した分析装置１には、例えば、図９に示すような、中央演算処理装置（ＣＰＵ）９０１と、メモリ９０２と、ストレージ９０３と、通信装置９０４と、入力装置９０５と、出力装置９０６とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、分析装置１が実現される。このプログラムは磁気ディスク、光ディスク、半導体メモリ等のコンピュータ読み取り可能な記録媒体に記録することも、ネットワークを介して配信することもできる。
　１…分析装置
　１１…取得部
　１２…解析部
　１３…表示部

Claims (6)

  1. 　開発サイクルを繰り返して実施するソフトウェア開発チームの成果を分析する分析装置であって、
    　前記ソフトウェア開発チームの成果物を格納する開発リポジトリからコミット履歴を取得する取得部と、
    　前記開発サイクルの単位で前記コミット履歴を集計して統計情報を算出する解析部と、
    　前記統計情報を表示する表示部を備える
    　分析装置。
  2. 　請求項１に記載の分析装置であって、
    　前記解析部は、前記ソフトウェア開発チームの成果の偏在性を前記開発サイクルの単位でみたジニ係数を算出する
    　分析装置。
  3. 　請求項１または２に記載の分析装置であって、
    　前記取得部は、除外条件に合致する前記コミット履歴を除外する
    　分析装置。
  4. 　請求項１ないし３のいずれかに記載の分析装置であって、
    　前記取得部は、前記コミット履歴に含まれる名前の表記揺れを是正する
    　分析装置。
  5. 　開発サイクルを繰り返して実施するソフトウェア開発チームの成果を分析する分析方法であって、
    　コンピュータが、
    　前記ソフトウェア開発チームの成果物を格納する開発リポジトリからコミット履歴を取得し、
    　前記開発サイクルの単位で前記コミット履歴を集計して統計情報を算出し、
    　前記統計情報を表示する
    　分析方法。
  6. 　請求項１ないし４のいずれかに記載の分析装置の各部としてコンピュータを動作させるプログラム。
PCT/JP2020/031080 2020-08-18 2020-08-18 分析装置、分析方法、およびプログラム WO2022038666A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2020/031080 WO2022038666A1 (ja) 2020-08-18 2020-08-18 分析装置、分析方法、およびプログラム
JP2022543833A JPWO2022038666A1 (ja) 2020-08-18 2020-08-18
US18/019,964 US20230273773A1 (en) 2020-08-18 2020-08-18 Analysis apparatus, analysis method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/031080 WO2022038666A1 (ja) 2020-08-18 2020-08-18 分析装置、分析方法、およびプログラム

Publications (1)

Publication Number Publication Date
WO2022038666A1 true WO2022038666A1 (ja) 2022-02-24

Family

ID=80322821

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/031080 WO2022038666A1 (ja) 2020-08-18 2020-08-18 分析装置、分析方法、およびプログラム

Country Status (3)

Country Link
US (1) US20230273773A1 (ja)
JP (1) JPWO2022038666A1 (ja)
WO (1) WO2022038666A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09248736A (ja) * 1996-03-12 1997-09-22 Toshiba Corp 生産計画立案装置
US20050044037A1 (en) * 2001-01-30 2005-02-24 David Lawrence Systems and methods for automated political risk management
JP2019125158A (ja) * 2018-01-17 2019-07-25 日本電信電話株式会社 リスク判定装置及びプログラム
JP2019175273A (ja) * 2018-03-29 2019-10-10 株式会社日立ソリューションズ 品質評価方法および品質評価装置
US20200097870A1 (en) * 2018-09-24 2020-03-26 Salesforce.Com, Inc. Work task commitment manager

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09248736A (ja) * 1996-03-12 1997-09-22 Toshiba Corp 生産計画立案装置
US20050044037A1 (en) * 2001-01-30 2005-02-24 David Lawrence Systems and methods for automated political risk management
JP2019125158A (ja) * 2018-01-17 2019-07-25 日本電信電話株式会社 リスク判定装置及びプログラム
JP2019175273A (ja) * 2018-03-29 2019-10-10 株式会社日立ソリューションズ 品質評価方法および品質評価装置
US20200097870A1 (en) * 2018-09-24 2020-03-26 Salesforce.Com, Inc. Work task commitment manager

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MASUDA AYAKO; MATSUODANI TOHRU; TSUDA KAZUHIKO: "Team Activities Measurement Method for Open Source Software Development Using the Gini Coefficient", 2019 IEEE INTERNATIONAL CONFERENCE ON SOFTWARE TESTING, VERIFICATION AND VALIDATION WORKSHOPS (ICSTW), IEEE, 22 April 2019 (2019-04-22), pages 140 - 147, XP033559416, DOI: 10.1109/ICSTW.2019.00042 *

Also Published As

Publication number Publication date
JPWO2022038666A1 (ja) 2022-02-24
US20230273773A1 (en) 2023-08-31

Similar Documents

Publication Publication Date Title
US10055337B2 (en) Methods and systems for analyzing software development risks
Sawatsky et al. Partial least squares regression in the social sciences
Smith et al. Identifying influences on model uncertainty: an application using a forest carbon budget model
Shepperd Software project economics: a roadmap
US20220027744A1 (en) Resource data modeling, forecasting and simulation
Aranha et al. An estimation model for test execution effort
JP2020500420A (ja) マシンラーニング基盤の半導体製造の収率予測システム及び方法
Mockus Missing data in software engineering
Popović et al. A comparative evaluation of effort estimation methods in the software life cycle
Ramos et al. A systematic review of research guidelines in decision-analytic modeling
CN108491991B (zh) 基于工业大数据产品工期的约束条件分析系统与方法
Radlinski et al. On predicting software development effort using machine learning techniques and local data
JPWO2018079225A1 (ja) 自動予測システム、自動予測方法および自動予測プログラム
Eisty et al. A survey of software metric use in research software development
Rupšys New insights into tree height distribution based on mixed effects univariate diffusion processes
CN110232130B (zh) 元数据管理谱系生成方法、装置、计算机设备和存储介质
CN113723747A (zh) 分析报告生成方法、电子设备及可读存储介质
Đorđević Evaluation of the usability of Web-based applications
WO2022038666A1 (ja) 分析装置、分析方法、およびプログラム
CN115018106A (zh) 异常分析方法、装置、设备及计算机可读存储介质
US20180130002A1 (en) Requirements determination
Goyal Development of a survival based framework for bridge deterioration modeling with large-scale application to the North Carolina bridge management system
US20180060279A1 (en) System and method for creating a metrological/psychometric instrument
Dórea et al. Vetsyn: An R package for veterinary syndromic surveillance
Wang et al. Software reliability model of open source software based on the decreasing trend of fault introduction

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20950232

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022543833

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20950232

Country of ref document: EP

Kind code of ref document: A1