Performance in Software Development; a question of metrics?
The evaluation of performance in software development, of a software development team, for an IT project, will vary greatly depending on the type of metrics used.
This request for performance measurement 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 performance indicators that will enable us to evaluate and compare ourselves …
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 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 evaluate consistently the performance of any development team in any IT project; regardless of country, technology, type of management or industry.
In short, is there a universal measure of performance in software development?
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 the letter I for Integration. The main purpose of CMMI is to measure the ability of 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.
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 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, reading, 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 as the universe is a matter of relativity, but you still need to be able to quantify it!
Michel Martel