Software Development Performance; a question of metrics?

See AMP Version

The assessment of software development performance, be it of a software development team or a software development project will vary greatly depending on the type of metrics used.

This request for performance assessment in software development projects is constantly coming back and is a source of major concern for Managers; which is quite normal considering the low ratio of projects delivered in time… and costs.

The question remains: how is it that my real estate contractor is able to certify that my house with the specific ABC features will be delivered by June 30, but that my IT director not only fails to deliver my IT project (the expected functionalities) in the foreseen deadlines but can’t either tell me when, in the end, my IT project will be completed?

In our previous posts, we talked about types of management, process, and innovation. In this post, we want to analyze and demystify the notion of metrics because it is she who will provide the key performance indicators (KPIs) that will enable assessment and comparison …

The fact is that there are several possible approaches and, in this sense, the evaluation of the performance is also a question of method.

For example, emphasis could be placed on the quantity of codes or features delivered; others will want to measure the quality of the code or features delivered. And still, others will take into account the final execution against the objectives of the project, project costs, project delivery time or benefits of the project for the company or departments concerned and involved.

The big question is how to measure consistently any software development team performance in any software development project; regardless of country, technology, type of management or industry.

In short, is there a software development performance metrics that is universal?

The answer is yes “; the FFP, Full Functional Point of the CMMI model, Capability Maturity Model Integration.

CMMI was originally created by the US Department of Defense (DoD) to track developments and budgets under the CMM designation. Subsequently, by absorbing other relative specifications, the reference was added to the letter I for Integration. The main purpose of CMMI is to measure the ability of software development projects to be completed properly in terms of time, functionality and budget. (source: pilot.org)

Although we do not consider ourselves at Analystik as “CMMI gurus”, we apply several basic principles including the evaluation of our development projects via the FFP metric, the “Full Functional Point”.

A functional point is a basic activity in software development such as read, write, enter and exit of a data. This notion is linked to the notion of “functional process” which in turn translates the concept of “data processing” and will be composed of several functional points as illustrated in the three diagrams below.

Functional Process
Source : COSMIC
Source : Software Engineering by K.K. Agarwal & Yogesh Singh (2007)

So, how many hours will be required for each Function Point (FFP) in our various software projects? This metric will allow us not only to compare ourselves to our industry while taking into account our specificities but also to better plan our future software development projects.

The number of function points, normally, for the same project will be the same, regardless of the technology or location in the world; what varies from one software development team to another is the number of hours / FFP ratio called velocity. For the IT director, the metrics that will interest him will be the speed of his development teams, always taking into account the constraints specific to each sector of activity.

For example, does the technical documentation in our industry lead to extra work?

Another example is that of a banking project that imposes very high standards of security and confidentiality that will necessarily add a heavier workload on the processing, transferring, read, writing and archiving of data than the development of an automation software for a production line.

The banking project may provide a 30 hr / FFP velocity while the production line industrial project will have a velocity of 15 hrs / FFP; let’s say!

Conclusion

Finally, from the moment that all our software development projects are evaluated in a standard, reproducible and comparable way; as projects progress, we will be able to evaluate the performance of our software development team and establish development time frame based on the nature of the projects.

The notion of performance will always be relative to the sector of activity … and the level of maturity!

Performance, just as the universe, is a matter of relativity, but you still need to be able to quantify it!

 

Denis Paul & Michel

Leave a Reply

Your email address will not be published.