Ahorra tiempo y dinero con la Ingeniería del Software

Estos últimos días estoy leyendo por enésima vez Code Complete, mi libro preferido sobre desarrollo de software, y el de mucha más gente. A este libro pertenece esta tabla, basada en diversos estudios, que ejemplifica el coste medio de arreglar un error durante el proceso de desarrollo de software según la etapa en que se introdujo y la etapa en que se terminó solucionando.

Coste Etapa en que se detectó
Requisitos Arquitectura Construcción Pruebas Mantenimiento
Etapa en que se introdujo Requisitos 1 3x 5-10x 10x 10-100x
Arquitectura 1 10x 15x 25-100x
Construcción 1x 10x 10-25x

Como vemos, un defecto cuyo arreglo podía suponer un coste de 100€ en la fase de toma de requisitos podría multiplicarse hasta los 300€ de no encontrarse hasta que estuvieramos definiendo la arquitectura del sistema. Esta cantidad subiría hasta los 500€ si hubieramos empezado a escribir el código, 1.000€ si estuvieramos en la fase de pruebas, y hasta 10.000€ de no encontrarse el error hasta que el sistema se encontrara ya funcionando. Tenedlo en cuenta si alguien intenta justificaros el no seguir ningún tipo de método.

Comentarios
  1. Bueno, por esto se está poniendo de moda el TDD (Test-Driven Development). Por lo menos, en la comunidad en la que trabajo (Ruby + Ruby on Rails) el TDD está muy arraigado…

    Para quien no conozca qué es TDD, un breve resumen:

    1) Escribimos las pruebas. Imaginemos que queremos implementar una serie de métodos: las pruebas tienen que contemplar los “edge cases” que pueden hacer petar el código y ocasionar bugs.

    2) Escribimos el código de la aplicación, comprobando siempre que nuestro código no rompe nada de lo que ya funciona

    Lo que permite el TDD es encontrar estos errores ANTES de empezar a programar la aplicación en sí, por lo que el ahorro es mucho mayor. Además, al estar trabajando siempre contra las pruebas nos aseguramos que nuestro código siempre funcionará en los casos que hemos especificado en las pruebas.

    Si no usáis TDD os recomiendo darle un vistazo, os puede llegar a ahorrar mucho tiempo y dinero 🙂

    Responder

    • Coincido. Además ya no es sólo el feedback, es que el simple hecho obligarte a escribir código fácil de testear suele provocar que todo sea más legible.

      Responder

      • Ya tengo dos tareas, por un lado, hacerme con el libro y leerlo (de una vez por todas, que no es la primera vez que lo pones y digo ¡a leerlo!). Y por otro lado, estudiar la metodología TDD. Ya estuve leyendo un poco, poquito sobre esta, pero tengo que ponerme.

        Responder

  2. este libro es muy interesante es de mis favoritos sobre programación.

    Responder

  3. ing de software, esta materia no me gustaba

    Responder

Deja un comentario