Hechos y falacias de la ingeniería de software

Aleksandr Shitik

Escribo mis propios posts y libros, y hago reseñas de películas y libros. Experto en cosmología y astronomía, informática, productividad y planificación.

Robert L. Glass

Géneros: Programación

Año de publicación: 2008

Año de lectura: 2020

Mi calificación: Máxima

Número de lecturas: 1

Páginas totales: 233

Resumen (páginas): 0

Idioma original de la publicación: Inglés

Traducciones a otros idiomas: Ruso, Chino

Información general

Libro del año 2008, compuesto por 55 hechos y 10 mitos sobre los desarrolladores y la programación en general. Todo el material está dividido en grupos específicos, como: gestión, desarrollo y otros.

Es importante señalar de inmediato que casi todos los temas y cuestiones tratados por el autor son bastante controvertidos, y diferentes lectores pueden tener opiniones muy distintas. Para ahorrar tiempo y espacio, no voy a describir mi propia opinión o visión sobre cada uno de los puntos. Aquí simplemente enumeraré brevemente todos los hechos y mitos, y al final daré una evaluación general del libro. Cada hecho o mito se presenta en un volumen equivalente a un artículo promedio, por lo tanto, si te interesa, puedes leer no todo el libro, sino elegir temas específicos. Antes de enumerar todos los hechos y mitos, también destaco que el autor sigue una estructura clara en la presentación del material:

• Primero discute el hecho o mito en sí.
• Luego describe las controversias y debates a su alrededor.
• Al final, proporciona fuentes de información relacionadas con el tema.

Hechos de la programación

El factor humano

1. El factor más importante en el desarrollo de software no son los métodos y herramientas utilizados por los programadores, sino los propios programadores.
2. Según un estudio sobre diferencias individuales, los mejores programadores superan a los más débiles hasta en 28 veces. Si consideramos que su remuneración nunca es proporcional, entonces el mejor programador es la adquisición más valiosa en la industria del software.
3. Si un proyecto se retrasa, añadir más personal lo retrasará aún más.
4. Las condiciones laborales influyen fuertemente en la productividad y la calidad del resultado.
5. El bombo publicitario en torno a las herramientas y métodos es una plaga de la industria del software. La mayoría de las mejoras en herramientas y métodos solo aumenta la productividad y la calidad entre un 5 y un 35%. Sin embargo, muchas de estas mejoras se anuncian como si dieran ventajas "de un orden de magnitud".
6. Aprender un nuevo método o herramienta reduce primero la productividad del programador y la calidad del producto. Solo se puede obtener beneficios después de superar la curva de aprendizaje. Por eso, solo tiene sentido introducir nuevos métodos y herramientas si: a) se ve su valor real y b) se tiene paciencia para esperar los beneficios.
7. Los desarrolladores hablan mucho sobre herramientas. Prueban muchas, adquieren suficientes, pero casi no trabajan con ellas.
8. A menudo, una de las razones de la falta de control de un proyecto es una mala estimación. (La segunda razón se trata en el Hecho 23.)
9. La mayoría de las estimaciones en proyectos de software se hacen al inicio del ciclo de vida. Y esto no nos molesta hasta que comprendemos que estas estimaciones se hacen antes de definir los requisitos, y por tanto antes de estudiar la tarea. Por lo tanto, la estimación generalmente se hace en el momento equivocado.
10. La mayoría de las estimaciones en proyectos de software las hacen altos directivos o personal de marketing, y no quienes desarrollarán el software ni sus líderes. Es decir, las estimaciones las hacen las personas equivocadas.
11. Las estimaciones en los proyectos de software rara vez se refinan después. En otras palabras, las estimaciones hechas por las personas equivocadas y en el momento equivocado, por lo general, no se corrigen.
12. Dado que las estimaciones son tan incorrectas, no hay muchas razones para preocuparse de que los proyectos no se terminen a tiempo. Sin embargo, a todos les preocupa.
13. No hay contacto entre los gerentes y los programadores. En un estudio sobre un proyecto que no cumplió los plazos estimados y fue considerado un fracaso por la dirección, los técnicos lo calificaron como el mejor proyecto en el que habían trabajado.
14. El análisis de viabilidad del proyecto casi siempre da como resultado un "sí".
15. La reutilización "a pequeña escala" (en bibliotecas de subrutinas) apareció hace casi 50 años, y está bien resuelta.
16. La reutilización "a gran escala" (en componentes) sigue siendo en gran parte un problema sin resolver, aunque todos están de acuerdo en que es muy importante lograrlo.
17. El éxito de la reutilización a gran escala se da sobre todo en familias de sistemas relacionados, y por tanto depende del dominio de aplicación. Esto limita la aplicabilidad potencial de la reutilización a gran escala.
18. En la práctica de la reutilización existen dos "reglas del tres": a) los componentes reutilizables son tres veces más costosos de desarrollar que los de un solo uso; y b) un componente reutilizable debe probarse en tres aplicaciones distintas antes de considerarse suficientemente genérico para incluirse en una biblioteca.
19. Modificar código reutilizable conlleva un alto riesgo de errores. Si se necesita cambiar más del 20-25% del código, es mejor reescribirlo desde cero.
20. La reutilización de patrones de diseño es una solución a los problemas relacionados con la reutilización de código.
21. Aumentar la complejidad de una tarea en un 25% complica la solución en un 100%. Esto no es algo que se pueda cambiar fácilmente (aunque siempre es deseable reducir la complejidad), sino una realidad.
22. El 80% del trabajo de desarrollo de software es intelectual. Una parte considerable de este trabajo puede considerarse creativa, y solo una pequeña parte es técnica.

Requisitos

23. Una de las dos causas más comunes de proyectos incontrolables son los requisitos cambiantes. (La otra causa se trata en el Hecho 8.)
24. Corregir errores en los requisitos es más caro si se detectan en la fase de explotación, y más barato si se descubren en las primeras etapas del desarrollo.
25. Los requisitos que no existen son el error más difícil de corregir.

Diseño

26. A medida que se avanza de los requisitos iniciales a la arquitectura, se genera una avalancha de "requisitos derivados" (requisitos de soluciones específicas), provocada por la complejidad del proceso. La lista de estos requisitos derivados suele ser 50 veces más larga que la original.
27. La mejor solución de diseño rara vez es única.
28. El diseño es un proceso iterativo complejo. La primera solución de diseño suele ser incorrecta y, sin duda, no óptima.

Codificación

29. Los programadores pasan del diseño a la codificación cuando la tarea se ha descompuesto en "primitivas" que domina el diseñador. Si el codificador y el diseñador son personas distintas, es probable que sus primitivas no coincidan, lo que provocará problemas.
30. COBOL es un lenguaje muy malo, pero todos los demás (para el procesamiento de datos empresariales) son mucho peores.
31. La fase de depuración de errores es la más laboriosa del ciclo de vida del software.

Pruebas

32. Resulta que, en el software que un programador típico cree que está exhaustivamente probado, a menudo solo se han verificado entre el 55 y el 60% de las rutas lógicas. El uso de herramientas automatizadas, como los analizadores de cobertura, permite aumentar esta proporción a aproximadamente el 85–90%. Probar el 100% de las rutas lógicas del software es prácticamente imposible.
33. Incluso si fuera posible lograr una cobertura del 100%, no serviría como criterio suficiente de prueba. Alrededor del 35% de los defectos del software se deben a rutas lógicas omitidas y otro 40% se relaciona con la ejecución de combinaciones únicas de rutas lógicas. Estos no se detectan con una cobertura del 100%.
34. Sin herramientas, es casi imposible realizar adecuadamente el trabajo de corrección de errores. Se utilizan ampliamente los depuradores, a diferencia de otras herramientas como los analizadores de cobertura.
35. Las pruebas rara vez se automatizan. Es decir, ciertos procesos de prueba pueden y deben automatizarse. Pero una parte importante del trabajo relacionado con las pruebas no se puede automatizar.
36. Un complemento importante a las herramientas de prueba es el código de depuración incorporado creado por el programador, preferiblemente incluido en el código objeto según las directivas de compilación.
37. Las inspecciones minuciosas permiten eliminar hasta el 90% de los errores del producto de software antes de que se ejecute la primera prueba de referencia.
38. Las inspecciones detalladas ofrecen muchas ventajas, pero no pueden sustituir las pruebas.
39. Se reconoce ampliamente que las revisiones posteriores (también llamadas retrospectivas) son importantes tanto desde la perspectiva del usuario del software como desde la mejora del proceso. Sin embargo, en la mayoría de las organizaciones no se realizan revisiones retrospectivas.
40. En las inspecciones, además de los factores técnicos, también hay un factor social. Prestar demasiada atención a uno en detrimento del otro conduce directamente al desastre.
41. El mantenimiento suele representar entre el 40 y el 80% (en promedio 60%) del coste del software. Por lo tanto, esta fase del ciclo de vida puede ser la más importante.
42. Aproximadamente el 60% de los costos de mantenimiento corresponden a mejoras del código y alrededor del 17% a la corrección de errores. Así, el mantenimiento y soporte del software consiste principalmente en agregar nuevas funcionalidades, no en corregirlo.
43. El mantenimiento es una solución, no un problema.
44. Si se comparan las tareas de desarrollo y mantenimiento del software, en su mayoría son iguales, excepto por una tarea adicional del mantenimiento: “estudiar el producto mantenido”. Esta actividad consume alrededor del 30% del tiempo total de mantenimiento y predomina en este proceso. Por lo tanto, se puede decir que el mantenimiento es más laborioso que el desarrollo.
45. Mejorar la calidad del desarrollo de software lleva a que haya más mantenimiento, no menos.

Calidad

46. La calidad es un conjunto de propiedades.
47. La calidad no se define por la satisfacción del usuario, el cumplimiento de los requisitos del cliente, la aceptabilidad del precio ni el cumplimiento de los plazos o la fiabilidad.
48. Hay errores a los que la mayoría de los programadores son propensos.
49. Los errores tienden a agruparse.
50. Aún no se ha desarrollado un único enfoque óptimo para la corrección de errores.
51. Los errores son inevitables. El objetivo es evitar errores críticos o reducirlos al mínimo.

Eficiencia

52. La eficiencia depende más del diseño de calidad de la aplicación que de la programación de calidad.
53. El rendimiento del código de alto nivel compilado con parámetros de optimización adecuados puede alcanzar el 90% de la eficiencia del código ensamblador funcionalmente equivalente. En algunas arquitecturas modernas complejas, puede ser incluso mayor.
54. Existen compromisos entre la optimización del tamaño y la optimización de la velocidad. A menudo, mejorar uno de estos aspectos empeora el otro.

Sobre la investigación científica

55. Muchos científicos que trabajan en la industria del software tienden más a defender sus teorías que a investigar. Resultado: a) el valor de algunas teorías promovidas es mucho menor de lo que creen sus defensores; b) hay poca investigación destinada a determinar el verdadero valor de estas teorías.

Conceptos erróneos sobre la programación

1. No se puede gestionar lo que no se puede medir.
2. La gestión puede hacer que un producto de software sea de calidad.
3. La programación puede y debe ser impersonal.
4. Las herramientas y tecnologías son universales.
5. La programación necesita más metodologías.
6. Para estimar costos y plazos, primero cuente las líneas de código.
7. El uso de datos de entrada aleatorios es una buena forma de optimizar las pruebas.
8. “Todos los errores se hacen evidentes si suficientes ojos los observan”.
9. Conociendo el costo del soporte en el caso anterior, se puede predecir su costo futuro y decidir sobre la conveniencia de reemplazar el producto.
10. A las personas se les puede enseñar a programar mostrándoles cómo escribir programas.

Conclusión

A pesar de que el libro fue escrito en el lejano 2008, aún lo recomiendo a quienes estudian programación. Una de las desventajas más evidentes es que es difícil confirmar o refutar los porcentajes y cifras que el autor proporciona en algunos hechos. También hay algunos puntos que hoy en día han perdido actualidad. Por lo demás, la gran mayoría del material sigue siendo relevante y será útil tanto para desarrolladores como para gerentes.