Our KPI definitions

For analysis without a headache

bg-20214F.png
 

Size

These KPIs assess the size of applications and workstreams. Size can help evaluate the impact of an identified problem

 
 
 

Overall Code Size

[Lines of code]

The total number of lines of code in an application. This helps identify overly large applications, which are not always a risk, but can denote monolithic and legacy applications

 

 

Code Size

[Lines of code]

The real lines of code in an application (excluding comments, empty lines, etc.). This helps identify overly large applications, which are not always a risk, but can denote monolithic and legacy applications

 

 

Logic Size

[Logic points]

The number of logic branches in the application source code based on the McCabe metric. This is an indicator of how much business functionality the application provides. This KPI helps identify monolithic and legacy applications, which can be time consuming and expensive to develop and maintain

 

 

The number of developers working on the relevant code in the most recent week. This helps determine whether developers are assigned in accordance with a plan or if there are major deviations from that plan that could lead to delays or unanticipated expenses

Resources

[Number of developers]

 

 

The total number of developers working on relevant code within the selected date range. This identifies the distribution of an organisation’s development resources to check whether it aligns with the organisation's strategic goals and objectives

Resources (total)

[Number of developers]

 
 
 

Budget

These KPIs assess the investment made into an application or a workstream. Investment is measured in person weeks. Seerene uses the commits a developer makes each week to allocate effort across the relevant applications and workstreams. It assesses these numbers proportionally against the effort of one person week. The effort invested into an application or workstream is determined by adding up the fractions of person weeks for all the developers working on that application

 
 
 

Effort

[Person weeks]

The time spent by all developers working on the relevant code in a single (or most recent) week. This indicates the effort spent on each workstream, and helps determine whether it aligns with the strategic goals and objectives of the organisation

 

 

The time spent by all developers working on the relevant code within a selected time range (e.g., six months, one year). This indicates the development efforts/investments made in each application or workstream or across the whole portfolio

Effort (total)

[Person weeks]

 

 

Effort Defect Fixing

[Person weeks]

The total time developers spend fixing defects (i.e., bugs). This indicates effort expended to fix defects in the relevant code and helps to clarify each application’s maintenance costs

 

 

% Effort Defect Fixing

[Percent of person weeks]

Effort Defect Fixing / Effort. The ratio of time spent on development efforts to that spent on defects. A high ratio indicates problems in the development process or in quality assurance

 
 
 

Activity

These KPIs measure development activity in the code base. They count the number of changes independent of how much time each one took

 
 
 

Code Changes

[Number of changes]

The number of code changes committed to the version control system per unit of time (e.g., per week). This helps map out development activities over time so abnormal development cycle patterns can be identified (e.g., many changes made shortly before shipment)

 

 

The total number of code changes committed to the version control system during a specified period (e.g., the last six months). This shows how many changes were made to the code and can be used to determine if an application has reached stability (assuming that after some time the number of changes to the code base stabilises)

Code Changes (total)

[Number of changes]

 
 
 

Risk

These KPIs highlight where teams encounter difficulties in their work and identify potential business risks for the organisation. The risks span code and people dimensions

 
 
 

Branch Coverage

[Number of branches]

The total number of branches in an application that are covered by unit tests. This is an indicator of code quality. Test coverage reduces the risk of errors when the code is modified or extended

 

 

Coding Violations

[Number of violations]

The total number of coding violations in an application’s source code. Seerene supports four levels of severity: minor, major, critical and blocking. Its platform integrates with third-party systems, like SonarQube, to measure these KPIs. Coding violations indicate suboptimal quality and buggy, which slows the development

 

 

Complexity

[Lines of code]

The total number of complex lines of code (nesting level of four or higher) in the relevant code. A more complex application is harder for a developer to understand, which results in the slow and costly development of new functionalities

 

 

Complexity Density

[Percent of lines of code]

Complexity / Code Size. The ratio of complex lines of code (nesting level of four or higher) to the total lines of code in an application. This indicates the code’s complexity. An application with more complex code is harder for a developer to understand, which results in the slow and costly development of new functionalities

 

 

Complexity 6+

[Lines of code]

Complexity 6+ / Code Size. The total number of very complex lines of code in the relevant code (nesting level of six or higher). This measures an application’s complexity risk. A more complex application is harder for a developer to understand, and results in the slow and costly development of new functionalities

 

 

Complexity Density 6+

[Percent of lines of code]

Complexity 6+ / Code Size. The ratio of very complex lines of code to the total lines of code in an application. An application with more complex code is harder for a developer to understand, and results in the slow and costly development of new functionalities

 

 

Deactivated Code

[Lines of code]

The total number of lines of code in an application that are commented out. Well-maintained code should not contain any deactivated code

 

 

Knowledge Monopoly

[Lines of code]

The sum of complex lines of code (nesting level of four or higher) for code units touched by a single developer in a 12 months period. This is a risk because the code is hard to understand and is only known to one developer whose availability may change. Knowledge monopolies make it difficult to reorganise teams

 

 

Line Coverage

[Lines of code]

The total number of lines of code in the relevant code that were covered by unit tests. This is an indicator of code quality as test coverage reduces the risk of errors when the code is modified or extended

 

 

Logic Density

[Logic points per line of code]

Logic Size / Code Size. The ratio of logic points to lines of code in an application. This indicates how much business functionality is provided per piece of code. High-density code is hard to understand and maintain, and results in the slow and costly development of new functionalities

 

 

Missing Documentation

[Logic points]

The total number of logic branches that are not documented, as calculated in logic points based on the McCabe metric. A logic branch is documented if it is preceded by a comment or method signature that appears, at the most, 10 branch keywords earlier in the code. The less source code is documented, the slower any future developments, as it takes longer for developers to figure out the logic than to read about it

 

 

% Undocumented Logic

[Percent of logic points]

Missing Documentation / Logic Size. The ratio of undocumented logic branches to the total number of logic branches in an application. The less source code is documented, the slower any future developments, as it takes longer to for developers to figure out the logic on their own than to read about it

 

 

Team Churn

[Percent of number of developers]

The ratio of developers who were active in an application in the penultimate month to the number who were not active in the previous month. This indicates the fraction of developers who left the workstream’s team. A large fraction typically means a lower workstream performance, which results from knowledge drain and the effort required to onboard new team members