Diseño Evolutivo y Diseño Planificado

Transcripción

1 Informe de Ingeniería de Software Avanzada Diseño Evolutivo y Diseño Planificado Integrantes Ricardo Rivera B k Angel Roa M

2 Introducción En el siguiente trabajo se estudiará una de las practicas más conocidas como el de los métodos ágiles: Diseño en programación Extrema. Nos centraremos en lo que es Diseño simple de XP, comparando el Diseño Evolutivo Versus el Diseño Planificado. Veremos los beneficios y los contra de usar uno y otro, se estudiará que el diseño evolutivo crece conforme se implanta el sistema, al contrario como se realiza en el Diseño planifico que se basa en estudiar y plantear los grandes problemas con anticipación. También se planteará los slogans que caracterizan a XP, los cuales son: "Haz la cosa más simple que pueda funcionar" y "No lo va a necesitar", los cuales están arraigados en las practicas de XP, finalmente se añadirá el tema de costos por conceptos de errores en diseño que son unos de los más caros al crear Software.

3 Extreme Programmig La metodología extreme Programming (XP) pretende que el desarrollo de un proyecto de software sea un desarrollo ágil, aunque disciplinado, y aporte soluciones sencillas. XP tiene un enfoque adaptativo. XP se caracteriza por poseer principalmente 12practicas las que describen en la siguiente figura. Nos abocaremos al a lo que es Diseño simple, más precisamente a lo que es diseño evolutivo utilizado en XP, el cual se comparará con el diseño planificado. Una analogía de XP es que se puede pensar como un rompecabezas. En el cual hay muchos pedazos pequeños que individualmente no tiene sentido, pero cuando se combinan, juntos pueden forman una figura que puede ser vistas por todos No requieren el objeto el Diseño Orientado Objeto (OOD) para practicar XP, pero esto realmente ayuda. La prueba primero programa la técnica promueve el edificio y el software de pruebas en pequeño pedazos independientes. Pequeños pedazos independientes son realmente con fuerza crear en lenguas procesales como C. Independiente los pedazos son mucho más fáciles para desarrollar la utilización OO el programa lenguas como Javanés, C++ o Smalltalk. Independiente las clases se dirigen a otras clases por su interfaz.

4 Qué es Simplicidad? La simplicidad es querer hacer nuestro código tan simple como sea posible. Eso no suena difícil de sostener, después de todo quién quiere ser complicado? Pero desde luego esto trae la pregunta " qué es simple?" Existen cuatro criterios para un diseño simple, en orden de importancia: Correr todas las pruebas: Ya que si corremos todas las pruebas podemos identificar errores que en las fases anteriores no fueron detectados. Revelar toda la intención: Así podemos revisar la información y no se encontrará con cosas ocultas u otros. Evitar duplicación: La duplicación conlleva a redundancia de datos que en exceso es malo. La duplicación de datos no es mala si es necesaria, por ejemplo en base de datos en algunos casos es necesario repetir atributos entre clases, ya que hace más rápida la búsqueda de información. El menor número de clases y métodos: Si tengo pocas clases y métodos nos lleva a un sistema fácil de diseñar, ya que hay menos cosas que hacer. El diseño simple explota las prácticas de la XP y es también una práctica facilitadora. Sólo si has hecho pruebas, integrado continuamente y refactorizado puedes practicar el diseño simple efectivamente. Dos de los más grandes gritos de batalla de la XP son los slogans "Haz la cosa más simple que pueda funcionar" y "No lo vas a necesitar" (conocido como YAGNI por sus siglas en inglés). Ambos son manifestaciones de la práctica XP del diseño simple. La manera en que usualmente se describe YAGNI, es que no deberías añadir hoy código que sólo será usado por alguna característica que será necesaria mañana. Una de las razones de esto es la parte económica. Si tengo que trabajar por una característica que sólo se necesitará mañana, estoy comprometiendo esfuerzo de características que necesitan hacerse para la iteración actual. Esta característica económica es reforzada por la posibilidad de que pudiéramos no hacerlo bien.

5 La segunda razón por el diseño simple es que un diseño complejo es más difícil de entender que un diseño simple. Por lo tanto cualquier modificación al sistema se hace más difícil por la complejidad añadida. En conclusión, no se debe gastar esfuerzo añadiendo capacidades que no serán necesarias hasta una iteración futura. Aún si el costo es cero, ya que el gasto se va realizar en esfuerzo, ósea horas hombres y en tiempo que entre más grande sea el proyecto más necesario es.

6 Diseño En la practica la programación Extrema de integración continua, pruebas. Se realizan trabajando en diseño evolutivo, con más eficacia que el diseño planificado, la debilidad del diseño planificado en que en la creación de este debe ser resistente y esto es complejo, otra característica del diseño evolutivo es que se puede trabajar a través del cambio y esta es una gran ventaja, ya que en caso que un proyecto es poco complejo pero en la practica se torna complejo. Ahora definiremos más formalmente con características lo que son ambos diseños, es una definición simple de cada uno para introducir en el tema. Diseño planificado: Cuando uno piensa en un pedazo de software uno crea el diseño primero, podría tomar la forma de UML o se podría expresar en términos de división de un sistema en subsistemas, hay un interruptor definido entre los dos modos de crear el diseño y luego cifrarlo. Y aquellas tareas a menudo pueden ser realizadas por gente diferente. Diseño evolutivo: Usted espera que el diseño se desarrolle despacio sobre el curso del ejercicio de programa. No hay ningún diseño al principio. Usted comienza por cifrar una pequeña cantidad de funcionalidades, añadiendo más funcionalidades, y dejando al cambio de diseño y la forma. El desarrollo ocurre en iteraciones cortas y todo el código constantemente es probado.. Para entender mejor lo que es Diseño Evolutivo se representará en una analogía. Plantamos una semilla de funcionalidad en el centro de este subsistema y simulado sus interacciones con su ambiente. Nuevas historias son traídas para hace la semilla crecer incrementalmente que traigan más funcionalidad y complejidad. Hemos sido capaz de mirar el diseño crecer y nos desarrollamos. El diseño principal no se ha cambiado mucho desde el primero, pero el sistema ha crecido. De su simple principio de media docena de clases y unas simulaciones, el diseño se ha desarrollado a 100 clases. Esto tomó aproximadamente seis meses con un pequeño equipo. Esto no es un enorme sistema, pero no habría producido tan limpio y flexible como rápidamente y con tal confianza. El diseño evolutivo releva mucha presión del equipo. No tenemos que crear el mejor diseño de todo el tiempo para cosas que no estamos exactamente seguros. Sólo necesitamos crear el mejor diseño para lo que sabemos hoy.

7

8 Diseño Planificado Versus Diseño Planificado Quizá el más común es el diseño evolutivo. Esencialmente, evolutivo significa que el diseño del sistema crece conforme se implanta el sistema. El diseño es parte del proceso de programación y conforme el programa evoluciona el diseño cambia. En su uso común, el diseño evolutivo es un desastre. El diseño acaba siendo la agregación de una sarta de decisiones tácticas ad-hoc, cada una de las cuales hace el código más difícil de modificar (practica para proyectos pequeños). El diseño planeado es todo lo contrario, y contiene nociones nacidas de otras ramas de la ingeniería, como por ejemplo son los diseñadores piensan los grandes problemas con anticipación. No necesitan programar porque no están construyendo el software, sólo lo están planeando. Así que pueden usar técnicas de diseño como el UML que deja de lado algunos de los detalles de la programación y permite a los diseñadores trabajar a un nivel más abstracto. Una vez echo el diseño, pueden pasarlo a otro grupo (o a otra compañía) que lo construya. Ya que los diseñadores están pensando en una escala mayor, pueden evitar las series de decisiones tácticas que llevan a la entropía del software. Los programadores pueden seguir la dirección del diseño y, dado que siguen el diseño al pie de la letra El diseño planeado ha estado allí desde los 70s, y mucha gente lo ha usado. Es mejor en muchas formas que el diseño evolutivo de codificar y corregir. Pero tiene algunas fallas. La primera es que es imposible pensar en todos los problemas que se necesitan tratar cuando se programa. Es inevitable que al programar se encuentren cosas que ponen en entredicho el diseño. Si los diseñadores ya acabaron y ya están en otro proyecto, qué pasa? Los programadores empiezan a codificar en torno al diseño y la entropía aparece. Aún si el diseñador no se ha ido, lleva tiempo organizar los problemas de diseño, cambiar los dibujos y alterar el código. Usualmente se hace una corrección rápida por la presión de tiempo. Además frecuentemente hay un problema cultural. Los diseñadores se han hecho por su habilidad y experiencia, pero están tan ocupados trabajando en diseños que ya no tienen mucho tiempo para programar. Sin embargo las herramientas y materiales de desarrollo de software cambian rápidamente. Cuando dejas de programar no solo pierdes los cambios que ocurren en este flujo tecnológico, también pierdes el respeto de los que programan.

9 Una manera de controlar los requerimientos cambiantes es añadir flexibilidad en el diseño de modo que se pueda cambiar fácilmente conforme cambian los requerimientos. Esto requiere perspicacia en la clase de cambios esperados. Un diseño puede planearse para tratar con áreas de volatilidad, pero mientras eso ayuda con cambios de requerimientos previstos La XP es controversial por muchas razones, pero una de las banderas rojas clave de la XP es que aboga por el diseño evolutivo en lugar del diseño planeado. Como sabemos, el diseño evolutivo no puede funcionar debido a decisiones ad-hoc y la entropía de software. El meollo para entender este argumento es la curva de cambio del software. La curva del cambio dice que mientras más avanza el proyecto, es exponencialmente más caro hacer cambios. La idea de esto es muy simple si tengo algo hecho y me doy cuenta que es los requerimientos cambiaron, para volver a estructurar esto se debe re-diseñar, desarmar o acomodar al nuevo requerimiento y luego re hacer, por cada una de estas fases se debe pasar lo que lleva a realizar gastos tanto económico como de tiempo que en proyectos grandes puede ser fatal para el mismo. Finalmente no se puede concluir cual de los tipos de diseño es mejor, ya que cabe recalcar que depende del tamaño del proyecto, y que ambos sirven para un tipo de proyectos y el otro para otros. Así que ambos tienen sus ventajas y desventajas, es a gusto del usuario cual de los dos se usa, o le parece mejor usar. Es por ello que siempre existe una libre elección.

10 Como el diseño simple ayuda a acortar los costos Si Alguien llamara y dijera que le van a ahorrar US en su empresa de 30 empleados, y vamos a incrementar su productividad, sin gastar ni un céntimo: sin arriesgar; sin comprometerse; y poder volver atrás cuando no se sienta a gusto con el proyecto, la forma de hacer esto es a través de un diseño simple que haga que las cosas se hagan bien y a la primera. Haciendo que las personas a cargo, estén correctamente alineados con el trabajo y que las cosas se realicen eficientemente. Ya que los costos de diseño son los más caros dentro del desarrollo del SW. Ya luego del desarrollo existen otras capas. Es por ello de la importancia del diseño.

11 Conclusiones No se debe gastar esfuerzo añadiendo capacidades que no serán necesarias hasta una iteración futura, en el diseño simple. Aún si el costo es cero, ya que el gasto se va realizar en esfuerzo, ósea horas hombres y en tiempo que entre más grande sea el proyecto más necesario es Un diseño complejo es más difícil de entender que un diseño simple. Por lo tanto cualquier modificación al sistema se hace más difícil por la complejidad añadida El diseño evolutivo es más fácil de adaptar si se presentan cambios en los requerimientos dado que al no ser rígido, se puede ir adaptando a los nuevas funcionalidades Del mismo modo, si se presentan errores en el diseño, pueden corregirse más fácilmente en un diseño evolutivo, lo que conlleva un menor gasto dinero No se puede afirmar cual tipo de diseño es mejor o peor, esto depende del tamaño del proyecto y de la experiencia de los desarrolladores

12 Bibliografía