Principios de la Ingeniería del Software

Los principios son leyes naturales de carácter general que actúan independientemente a que nosotros tengamos conocimiento o no de ellos, los principios pueden aparecer en la mayoría de las doctrinas por ello vamos a ver principios indiscutibles de la “Ingeniería del Software”.

No te repitas

Podremos encontrarlo escrito de varias formas “No te repitas”, “Una vez y sólo una”, “Don’t repeat yourself”, “DRY”, etc.

Es posiblemente el principio por excelencia, no se debe duplicar información ya que la duplicación incrementa la dificultad de cambios y su posterior evolución.

Es muy importante entender la palabra “información” en su sentido más amplio, como por ejemplo datos almacenados en una base de datos, código fuente de una aplicación, documentación, etc.

Si hacemos caso a este principio cualquier cambio tendrá que ser efectuado en un único lugar, de lo contrario los cambios pueden provocar fallos y la información no estará sincronizada.

Regla del noventa-noventa

“El primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo.”

(The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.)

Este principio fue hecho popular por Jon Bentley’s en Septiembre de 1985, en una columna llamada “Programming Pearls” de la revista “Communications of the ACM”.

Tambień se enuncia como: el tiempo que falta para acabar el proyecto es constante.

La regla del noventa-noventa es una instancia del Principio de Pareto.

Principio de Hanlon

• Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez
• Nunca le atribuya a estupidez lo que pueda explicarse adecuadamente mediante la ineptitud
• Nunca le atribuya a ineptitud lo que pueda explicarse adecuadamente mediante el desconocimiento

La primera frase es bastante común entre hackers.

Peor es mejor

Peor es mejor es una técnica de desarrollo de software y a la vez un principio, en la cual la simplicidad en la interfaz y en la implementación es más importante que cualquier otra propiedad del sistema (incluyendo corrección, consistencia y completitud).

Lo podemos resumir diciendo que como el programa inicial es básicamente bueno, es más fácil trasladarlo a nuevas máquinas y situaciones, su implementación inicial tomará mucho menos tiempo y esfuerzo, y su uso se difundirá mucho antes.

Principio KISS

El principio KISS es aquel que recomienda el desarrollo empleando partes sencillas, comprensibles y con errores de fácil detección y corrección, rechazando lo enrevesado e innecesario en el desarrollo de sistemas complejos en ingeniería.

El nombr de kiss no viene dado de la palabra “beso” como muchos habréis pensado, KISS es un acrónimo de la frase en inglés “Mantenlo simple, estúpido” (Keep It Simple, Stupid).

Gran bola de lodo

En programación, “gran bola de lodo” es un término aplicable a un sistema de ordenador sin una arquitectura realmente discernible.

Una Gran bola de lodo es una selva de código enrevesado, chapucero, caóticamente estructurado, que crece descontroladamente, que se mantiene como unido a base de cuerda y cinta aislante. Este tipo de sistemas presentan signos inconfundibles de crecimiento incontrolado y constantes necesidades de reparación. Elementos lejanos en el sistema comparten información profusamente, incluso hasta el punto de que prácticamente cualquier información importante se trata de manera global o se duplica. La estructura global del sistema puede no haber llegado a estar claramente definida nunca. Si alguna vez lo estuvo, es probable que se haya deteriorado hasta el punto de ser imposible reconocerla. Los programadores con un mínimo respeto por la estructuración huyen de esta clase de cenagales. Sólo a aquéllos a los que la arquitectura les trae sin cuidado y que tal vez se sienten cómodos programando por inercia parches día tras día para los interminables agujeros de estos diques que hacen aguas por todas partes, no les importa trabajar en tales condiciones.

Los programadores a cargo de proyectos con grandes bolas de lodo deben estudiar su comportamiento para entender su función, cambios de tecnología (de una filosofía cliente-servidor a una basada en web, de la utilización de ficheros al empleo de una base de datos, etc.) pueden proporcionar un buen motivo para empezar desde cero.