Category Archives: metriche

Software Engineering sorpassato?

Software Engineering: An Idea Whose Time Has Come and Gone?
Tom DeMarco, IEEE Software, July/August 2009

Quanto è importante, quanto decisivo il ruolo delle metriche e dei sistemi di controllo per il successo di un progetto? DeMarco rianalizza uno dei suoi testi più influenti, Controlling Software Projects, del 1982, e ne critica l’impostazione globale.

“The book for me is a curious combination of generally true things written on every page but combined into an overall message that’s wrong.
It’s as though the book’s young author had never met a metric he didn’t like. The book’s deep message seems to be, metrics are good, more would be better, and most would be best. […]

I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.
Consistency and predictability are still desirable, but they haven’t ever been the most important things.”

Le iniziative metriche durano poco

Secondo Ed Yourdon, solo il 10% circa delle iniziative intraprese dalle organizzazioni per impiantare un sistema metrico in ambito software ha una durata superiore ai 18 mesi.

Perché? I motivi, secondo Yourdon, sono principalmente legati ai conflitti politici interni alle organizzazioni.

Previsioni a partire dai function point

In un intervento sulla mailing list requirements-engineering, Capers Jones, un’autorità nelle statistiche relative allo sviluppo software, ha fornito queste indicazioni:

“Function point size raised to the 0.4 power gives a useful prediction of
development schedules in calendar months. (Agile projects should use the 0.34
power).

Function point size raised to the 1.25 power gives a useful and alarming
prediction of the probable number of bugs that will be encountered.

Function point size raised to the 1.2 power predicts numbers of test cases
needed.

Function point size divided by 150 predicts development team size.”