Sample dashboards in Kibana

Technical inventory indicator

Indicators of lines of code, source members and objects. The number in blue color is the total number by indicator, the color green/amber/red is the ratio by metrics with threshold warning indicators. For all indicators you can see the détails by click on icon information on left the corner of different panels.

Line of code

Total number of rows found in the application's libraries source files. These are raw figures before a possible cleaning. Some of the sources are duplicated (backup, versioning, ...). Others are not linked to an object when they should be because they have never been compiled or because the object has been deleted. Some source files sometimes contain something other than source code.

Details line of code

Total number of line of code add by years. Also compare with the line of comments and empty lines These are raw figures before a possible cleaning. Some of the sources are duplicates (backup, versioning, ...). Others are not linked to an object when they should be because they have never been compiled or because the object has been deleted. Some source files sometimes contain something other than source code.

Source members

Total number of sources members found in the application's libraries source files. These are raw figures before a possible cleaning. Some of the sources are duplicates (backup, versioning, ...). Others are not linked to an object when they should be because they have never been compiled or because the object has been deleted. Some source files sometimes contain something other than source code.

Missing objects

Numbers of members found in the source files that are not linked to an object. This metric only counts source members whose type is known and can be compiled. So sources of type RPGLE, DSPF, C, ... but not sources of type TXT, FTP, DUMMY, ... . To the list of known PDM types, ARCAD adds types such as TABLES, INDEX, VIEW, SQLUDF, ... used in particular to create objects with SQL scripts. For more details, you can use the AWRKSRCTYP command. Members used as copybooks in other sources have been identified and are not included in this metric. After analysis, it may be appropriate to delete or archive some of these sources.

Metrics XREF check

The more a file is used by programs, the more complicated the maintenance of this file becomes. It is often necessary to recompile these programs and therefore test and deliver them. The most frequently used files are good candidates for access outsourcing, via sub-procedures for example. As part of an evolution towards ILE and service programs, the most used programs are highlighted.

Obsolete objects

Number of obsolete objects Obsolete objetcs (unused objetcs). Objects considered obsolete are those that were created before a certain date, usually 36 months earlier, and have not been used since that date. It is possible to adjust this pivot date to evaluate with shorter or longer periods. Obsolete components should be archived to avoid being recompiled based on cross-referencing, and therefore tested.

Number libraries and objects

It is interesting to have the list of objects but the results are not the same depending on whether you are on a development or production machine. On a dev machine we will find modules and binding directories, for example, which are not necessary in production. On the other hand, there we will find dynamically generated objects (file by month, day, user, ...) or by setup commands (JOBD, JOBQ, OUTQ, ... ) without correspondence on the other machine.

Usage of objects

Usage of objects created by type. Simply the usage number of objects

Flow velocity

Flow Velocity gauges whether value delivery is accelerating. Flow Velocity is the number of Flow Items of each type completed over a particular period of time. This is also referred to as throughput.

Flow efficiency

The proportion of time flow items are actively worked on to the total time elapsed Flow Efficiency examines the two basic components that make up your lead time: working time and waiting time. Flow Efficiency[%]=(Work/(Work + Wait))*100 Flow efficiency is the ratio between value-adding time and the lead time required to complete a process. Value-adding is when a person or a machine is actively working towards the completion of a given target. Lead time is the frame between the order and delivery of the product. Value-added Time/Lead Time*100 Wait time can be real wait time and also blocked time Explaining it practically, if one of your software engineers needs 5 days to complete a feature, but spends only one day actively working on it, then the flow efficiency of developing this particular feature is 20%.

Flow load

Number of MR linked to a version with status ONG or WTG.

Flow distribution

The proportion of each flow item within a value stream across time.

Flow time

Time elapsed when a flow item enters the value stream to when it is released to the customer.

JIRA Timeline

The average time on days that JIRA tickets spend in each state. you can filter the view by projects. The second diagram shows the 20 tickets that are still in progress with whose status has lasted the longest.

Deployment frequency

Innovation begets rapid technology changes. Track code deployment frequency for a clear picture of how quickly new features and capabilities roll out. This metric should stay consistent or trend upward over time. A decrease or stutter suggests a bottleneck somewhere within the DevOps team workflow.

Defects volume and Correction rate

A change might deploy successfully, but generate a lot of bugs. While these errors aren't necessarily significant enough to cause an outage, they negatively affect the end-user experience. Ideally, the DevOps KPI for defect volume should remain as low as possible. However, some organizations embrace the concept of an error budget, positing that 100% uptime and reliability negatively affect app capabilities and project budgets. In its most basic form, an error budget encourages innovation and rapid iterations, with an expected tolerable level and frequency of bugs and downtime.

Change by Release

Determine how long it takes a change, such as a bug fix or new feature, to go from inception through dev and test to production. Long lead times could suggest inefficient processes that inhibit change implementations; short lead times can indicate a smooth DevOps process overall. We have two calculation methods. First calculate the difference between the opening date and the update reference date. The second, the average difference per day between the date of creation of a maintenance record and the reference date of update of the version.

Time line JIRA Tickets

This is the average time in days that jira tickets spend in each state. It is possible to filter by project. The second diagram gives the 20 tickets still in progress with whose status has lasted the longest.

JIRA Nb Issues by Project

JIRA Nb Issues by Type

JIRA Nb Issues by Status

JIRA Nb Issues by Period

JIRA Mean Time To Repair

Unplanned work

Statistics of unplanned work. This indicators provide statistics of unplanned work. It use the data maintenance reports with the values save in NRLOAD (real time work) and NELOAD (estimated time work).

Defect escape Rate/ratio