Plataforma

El problema malévolo y su coste en el diseño de software

El problema malévolo y su coste en el diseño de software

La frase “diseño de software” significa la concepción, invención o estrategia de un plan para transformar unos requerimientos a un software operativo. El diseño es la actividad que enlaza los requerimientos a la programación y la depuración. Un buen diseño es útil en pequeños proyectos e indispensable en los grandes.

El problema malévolo en el diseño de software

Horst Rittel y Melvin Webber definieron un problema “malévolo” como uno que podía ser claramente definido solo cuando estuviera solucionado, o solucionado en parte. Esta paradoja implica esencialmente que primero hay que resolver el problema para definirlo y entonces resolverlo de nuevo para crear la solución que funcione.

Un ejemplo de este problema está en el diseño del puente original de Tacoma Narrows (1940). La consideración principal en el diseño de un puente en aquella época era que fuese lo suficientemente fuerte para soportar la carga prevista. En el caso del puente de Tacoma Narrows, el viento creaba un inesperado movimiento armónico de lado a lado del puente. Un ventoso día de 1940, el movimiento creció de forma incontrolable hasta que el puente colapsó.

Este es un buen ejemplo de un problema malévolo, porque hasta que el puente no colapsó sus ingenieros no sabían que la aerodinámica debía tenerse en cuenta en su construcción.

Solo cuando el puente fue construido (se solucionó el problema) pudieron aprender sobre las consideraciones adicionales al problema, que les permitió construir otro puente que todavía existe.

Diseñar es un proceso descuidado

El diseño de una aplicación finalizada puede parecer bien organizada y limpia, pero el proceso para desarrollar el diseño no es tan ordenado como el resultado final.

Diseñar es descuidado porque supone dar pasos a atrás en el proceso, desechar elementos creados, cometer errores y tener que rehacer partes del diseño por ello. Precisamente los errores cometidos durante el diseño son más baratos de corregir en el diseño que reconocerlos durante el desarrollo y tener que corregirlos en el mismo código.

Diseñar también es descuidado porque es difícil saber cuando tu diseño es suficientemente bueno. ¿Cuánto detalle es necesario? ¿Cuánto habría que diseñar con una notación de diseño formal y cuanto hay que dejar para ser escrito?. Desde que el diseño tiene un final abierto, la respuesta más común a las preguntas es: “Cuando se te acabe el tiempo”.

Al final diseñar software es una cuestión de prioridades: ¿Cuánto tiempo tenemos? ¿Con qué recursos contamos?

Calcular el coste de resolver el problema

Algo a lo que estamos habituados en el diseño y desarrollo de software es a la presión desde distintas partes para acelerar el proceso (clientes, jefes, etc.). Ya sea por una cuestión de oportunidad de negocio, por plazos, falta de tiempo, o presupuesto.

Tanto los pequeños proyectos como los grandes requieren una planificación previa antes de iniciar el proceso de desarrollo, para poder detectar los posibles problemas que pudieran surgir. A más grande el proyecto, más complejo, y por tanto mucho más importante dedicar el mayor tiempo posible al diseño del proyecto. Proyectos más grandes requieren más planificación; proyectos más pequeños requieren menos.

Planificar significa determinar la cantidad de tiempo, número de personas, y numero de ordenadores que el proyecto necesita. Desde un punto de vista técnico planificar significa comprender qué es lo que quieres desarrollar, de tal forma que no dediques recursos construyendo algo equivocado.

Algunos usuarios no saben del todo lo que quieren al principio, pero modificar el diseño es más barato que desarrollar algo que no es lo que quieren.

Disponemos de estudios realizados durante los últimos 25 años que nos proveen información sobre el coste de realizar modificaciones durante la fase de diseño, desarrollo o puesta en producción del software.

Investigadores de Hewlett-Packard, IBM, Hughes, Aircraft, TRW, y otras organizaciones han encontrado que eliminar los errores al comienzo del desarrollo permite que corregirlos pueda ser hecho de 10 a 100 veces menos caro que hacerlo en las últimas fases del proceso, durante la fase de tests, o después de su puesta en producción (Fagan 1976; Humphrey, Snyder, y Willis 1991; Leffingwell 1997; Willis 1998; Grady 1999; Shull 2002; Boehm y Turner 2004).

En general, lo ideal es encontrar los errores tan pronto como sea posible después de haberlos añadido al diseño o la programación. Mantener un error durante mucho tiempo en el desarrollo implicará mayores problemas y costes para poder resolverlo.

captura-de-pantalla-2016-10-07-a-las-13-01-33

El la tabla anterior podemos ver que, por ejemplo, un error en la fase de arquitectura que cuesta 1.000 € corregirlo cuando se está en esa fase, puede costar 15.000 € corregirla durante la fase de test.

En la mayoría de proyectos, el tiempo dedicado a la corrección de defectos suele ser del 50% del tiempo dedicado al desarrollo del proyecto (Mills 1983; Boehm 1987a; Cooper y Mullen 1993; Wiegers 2002). Docenas de compañías han encontrado que simplemente corrigiendo los defectos en las fases más tempranas del desarrollo en vez de las últimas se puede reducir los costes del proyecto en un factor de dos o más (McConnel 2004). Esto es un saludable incentivo para encontrar y corregir problemas tan pronto como sea posible.

Estos datos nos permiten calcular el coste que puede tener el problema malévolo que tratamos al principio, pero también nos permite ver el coste que tiene cometer errores durante el diseño de software, y durante el desarrollo, testeo y puesta en producción.

Paliar los efectos del problema

Como hemos visto, corregir los problemas en fases tempranas del desarrollo nos permite reducir el coste del proyecto. Para poder aprovechar esta situación es necesario disponer de una metodología de trabajo que nos permita aplicar esta técnica de forma continua durante el desarrollo.

Aquí ya hemos hablado de Metodologías Ágiles, Scrum y Kanban, además de la importancia que tiene el proceso de testeo para evitar problemas posteriores, que serán más caros corregir.

Y aun con todo, el problema malévolo no desaparece

Por desgracia el problema malévolo termina apareciendo por algún lado. Los grandes cambios que se realizan en el sector aeronáutico suelen ser provocados por algún accidente o incidente grave producido por algún problema que no fue detectado en la fase de diseño. Por ejemplo el Vuelo 009 de British Airways (1982), también conocido como Speedbird9 o el incidente Yakarta. Penetró en una nube de ceniza volcánica provocando que se parasen sus cuatro motores.

La historia tiene un final feliz: pudieron recuperar tres de los motores y aterrizar.

El motivo del incidente fue que la naturaleza de la nube de cenizas era árida, y no aparecía en la pantalla del radar meteorológico, diseñado para detectar las partículas de humedad de las nubes. El piloto entró en la nube, y las partículas de ceniza se acumularon en los motores, atascandolos y provocando su parada.

Evitemos que no nos suceda en nuestros proyectos.

Valora el artículo:

1 Estrella2 Estrellas3 Estrellas4 Estrellas5 Estrellas (4 valoraciones, media: 4,00 sobre 5)
Cargando...
Avatar photo José Miguel Gil Desarrollador Full-Stack Ver más artículos de José Miguel Gil

Otros artículos de la categoría Gestión empresarial