Esta no es una pregunta sobre la calidad de la métrica SLoC. Lo acepto como una métrica limitada, inexacta o incluso pobre.
Dicho esto, estoy buscando datos que indiquen qué tarifas razonables para el desarrollo de software se dan en SLoC. De particular interés son las tasas para diferentes agencias gubernamentales, pero cualquier información ayudará.
Aclaración
Ya he desarrollado una aplicación de software y está lista para enviarse. El precio se fijó previamente por contrato y no está en disputa. Sin embargo, el equipo de contabilidad está buscando una razón numérica para dar su sello de aprobación. Estas personas no tienen en cuenta la habilidad o el conocimiento requerido, la curva de aprendizaje, el código generado, la eficiencia o cualquier otra cosa. Ya se les han presentado métricas válidas que muestran el “ahorro de costos”. Les salvamos el 80%. Pero ahora estamos obligados a justificar el 20% restante. Se les han dado otras estimaciones de costos, pero eso no es suficiente. Entonces, estoy tratando de apaciguar a la burocracia con algo que pueda relacionarse.
En Estimación de software: desmitificando el arte negro , Steve McConnell presenta una tabla adaptada y ampliada de Medidas para la excelencia: software confiable a tiempo, dentro del presupuesto , software de fuerza industrial y cinco métricas principales: la inteligencia detrás de la gestión exitosa de software para la línea de código por personal-mes para diferentes tipos de software. Esta tabla presenta los valores mínimo, máximo y nominal para diferentes tipos de proyectos y el tamaño total total (en líneas de código, que van desde 10 000 LOC hasta 250 000 LOC).
A continuación, resumo esta tabla con el rango de la tasa de productividad alta más alta, la tasa de productividad baja más baja y el rango de tasas nominales entre paréntesis:
Como siempre, cabe señalar que los datos internos de su organización serán más útiles, ya que dan cuenta de sus métodos y procedimientos. Los datos recopilados de encuestas amplias tienden a ser más ruidosos, ya que incluyen una amplia variación en habilidades de ingeniería, procesos, herramientas, etc.
Tenga en cuenta que esto no tiene en cuenta otra fuente de variación. Por ejemplo, el lenguaje de programación y el entorno sí importan. La reutilización de los componentes existentes importa. La experiencia importa. La complejidad general y la variabilidad importan.
Como respuesta rápida: "Aproximadamente 1 pantalla, por miembro del equipo, día profesional" de código probado (depurado).
Entonces, alrededor de 24 líneas en los años 70/80. Y hasta 50 líneas en la actualidad.
¡Pero depende mucho de cómo se organice el desarrollo! Por ejemplo, introducir lean/agile/scrum (correctamente) puede mejorar esos números en un 30 %.
Ashok Ramachandran