¿De dónde es esto (originalmente) ?: “El 80% del costo de por vida de una pieza de software se destina al mantenimiento” [cerrado]

En el documento de convenciones de codificación Sun Java (aquí: http://www.oracle.com/technetwork/java/codeconv-138413.html ), dice:

"El 80% del costo de por vida de un software se destina al mantenimiento"

¿Alguien sabe de dónde proviene esta estadística? No dudo de la afirmación, pero también puedo hacer estadísticas sin atribución y me gustaría saber de dónde vino esto antes de comenzar a usarlo como base para otras declaraciones.

Primero debe definir qué significa mantenimiento. Por lo general, los costos de mantenimiento superiores al 50% incluyen mejoras y eliminación de defectos.

La cifra del 80% no parece ser directamente atribuible a un estudio específico, pero puede encontrar varias cifras creíbles en el rango> 50% en los estudios mencionados en esta página: https://web.archive.org/web/ 20120313070806 / http: //users.jyu.fi/~koskinen/smcosts.htm

Tabla 3-7 de Medición de software aplicado, tercera edición. enumera que de los 8200 proyectos estudiados, solo 2410 fueron desarrollos nuevos. 1385 fueron proyectos de mantenimiento, y el resto fueron proyectos de mejora. Eso corresponde a aproximadamente el 70% de los proyectos que mantienen el código existente.

La economía de la ingeniería de software de Barry Boehm. Y no es 80%, es 50% -75%.

Capítulo 30. Página 533-534.

http://www.amazon.com/Software-Engineering-Economics-Barry-Boehm/dp/0138221227

La regla general 80-20 se invoca muy comúnmente en muchos contextos, ya que los números de muestra concretos representan la frase "la gran mayoría".

Esto puede ser solo una invocación de este tipo.

de Convenciones del Código Java - 12 de septiembre de 1997 por Sun Microsystems.

Verá esta cita en la introducción del documento debajo de

1.1 ¿Por qué tener convenciones de código?

• El 80% del costo de por vida de un software se destina al mantenimiento
• Casi ningún software es mantenido durante toda su vida por su autor original
• Las convenciones de código mejoran la legibilidad del software permitiendo a los ingenieros comprender el nuevo código de manera más rápida y exhaustiva.
• Si envía su código fuente como producto, debe asegurarse de que esté tan bien empaquetado y limpio como cualquier otro producto que cree.

Para 2011, este documento está bastante anticuado. El software y los sistemas se están desarrollando en una multitud de lenguajes que incluyen y excluyen Java.

Sin embargo, Java es muy lento y tiene una huella de memoria extremadamente grande en comparación con C / C ++. Cuando algunos usuarios experimentan la lentitud de la ejecución de Java en comparación con otros lenguajes como PHP, C / C ++, etc., a menudo piensan que algo está mal con el programa. Luego se gasta dinero en tratar de mejorar el rendimiento en vano. Por esta razón, siempre cuestiono la motivación de las personas para saltar al titánico y zarpar. Como no tiene sentido implementar muchos programas en Java, especialmente cuando el rendimiento o la huella de la memoria son una preocupación.

De hecho, he visto a personas dedicar más tiempo a implementar algo en Java por el simple hecho de ser una implementación de Java de lo que habrían pasado implementando el mismo software que un script bash en Linux o en Python o C ++.

No digo que evite Java a toda costa, pero hay una herramienta adecuada para el trabajo correcto y hay muchas más herramientas que Java en estos días.

¡Felicitaciones a Apple por finalmente desaprobar Java!