Modelo de caos

En informática , el modelo de caos es una estructura de desarrollo de software . Su creador, que utilizó el seudónimo LBS Raccoon, ^{[ 1 ]} señaló que los modelos de gestión de proyectos, como el modelo espiral y el modelo en cascada , si bien eran eficaces para gestionar cronogramas y personal, no proporcionaban métodos para corregir errores ni resolver otros problemas técnicos. Del mismo modo, las metodologías de programación, aunque eficaces para corregir errores y resolver problemas técnicos, no ayudaban a gestionar plazos ni a responder a las solicitudes de los clientes. Esta estructura intenta subsanar esta deficiencia. La teoría del caos se utilizó como herramienta para comprender mejor estos problemas. ^{[ 2 ]}

El modelo del caos señala que las fases del ciclo de vida se aplican a todos los niveles de los proyectos, desde el proyecto completo hasta las líneas de código individuales.

• Todo el proyecto debe ser definido, implementado e integrado.
• Los sistemas deben ser definidos, implementados e integrados.
• Los módulos deben definirse, implementarse e integrarse.
• Las funciones deben definirse, implementarse e integrarse.
• Las líneas de código se definen, implementan e integran.

Un cambio importante de perspectiva radica en si los proyectos pueden considerarse unidades completas o si deben concebirse por partes. Nadie escribe decenas de miles de líneas de código de una sola vez. Se escriben pequeñas partes, línea por línea, verificando que funcionen correctamente. A partir de ahí, se va construyendo el sistema. El comportamiento de un sistema complejo surge del comportamiento combinado de sus componentes más pequeños.

La estrategia del caos es una estrategia de desarrollo de software basada en el modelo del caos. La regla principal es siempre resolver primero el problema más importante .

• Un problema es una tarea de programación incompleta.
• El problema más importante es una combinación de grande , urgente y sólido .
  • Los problemas importantes aportan valor a los usuarios como funcionalidad operativa.
  • Los asuntos urgentes son oportunos en el sentido de que, de lo contrario, retrasarían otros trabajos.
  • Los problemas graves son fiables y se someten a pruebas una vez resueltos. De este modo, los desarrolladores pueden centrar su atención en otros aspectos con tranquilidad.
• Resolver significa llevarlo a un punto de estabilidad .

La estrategia del caos se asemeja a la forma en que los programadores trabajan hacia el final de un proyecto, cuando tienen una lista de errores que corregir y funcionalidades que desarrollar. Normalmente, alguien prioriza las tareas restantes y los programadores las solucionan una a una. La estrategia del caos afirma que esta es la única forma válida de realizar el trabajo.

La estrategia del caos se inspiró en la estrategia del juego de Go .

Existen varias conexiones con la teoría del caos .

• El modelo del caos puede ayudar a explicar por qué el software tiende a ser tan impredecible.
• Esto explica por qué conceptos de alto nivel como la arquitectura no pueden tratarse independientemente de las líneas de código de bajo nivel.
• Sirve como punto de partida para explicar qué hacer a continuación, en términos de la estrategia del caos.

• Modelo V

• Roger Pressman (1997) Ingeniería de software: un enfoque práctico, 4.ª edición, páginas 29-30, McGraw Hill.
• Raccoon (1995) El modelo del caos y el ciclo de vida del caos , en ACM Software Engineering Notes, Volumen 20, Número 1, Páginas 55 a 66, enero de 1995, ACM Press.