El problema con el software
El problema con el software es que lleva demasiado tiempo y dinero para desarrollar, y es frágil cuando se utiliza en situaciones para las cuales no fue diseñado de manera explícita. Diversas metodologías de diseño de software frente a este problema:
· 1970: la programación estructurada hace que sea factible construir a gran escala los sistemas de software - siempre y cuando haya una especificación de los resultados deseados en el inicio del proyecto y el pliego de condiciones rara vez cambia. Una aplicación típica es un informe de base de datos del programa por escrito que lee un archivo de entrada y produce un archivo de salida. A esto le llamamos una entrada / salida basada en la aplicación.
· 1980: Programación orientada a objetos hace que sea más fácil para reorganizar cuando cambien las especificaciones, ya que la funcionalidad se divide en clases separadas, que están diseñados para tener una mínima interacción entre ellos Sin embargo, cada cambio en la especificación (o para el medio ambiente) requiere la intervención del programador , con / un costoso rediseño / reimplementar / rebuild retest ciclo Una aplicación típica es un sistema de publicación de escritorio, donde el usuario inicia eventos (clic del ratón, selecciones de menú, etc) el cálculo de disparo.. Llamamos a esto una solicitud iniciada por el usuario basada en eventos.
· Hoy: Programación adaptativa tiene como objetivo el problema de la producción de aplicaciones que se pueden adaptar fácilmente ante las necesidades cambiantes de los usuarios, los deseos, y el medio ambiente. Esto hace posible para el usuario para cambiar los objetivos sin necesidad de reescribir el programa. A typical application is an information filter which searches the Internet or company intranet for information of personal interest to the reader. Una aplicación típica es un filtro de información que busca en Internet o intranet de la empresa para obtener información de interés personal para el lector.Tenga en cuenta que gran parte de la búsqueda puede continuar cuando el usuario ni siquiera se registran in La aplicación hace más en nombre del usuario sin interacción constante, y la sofisticación proviene de una división de responsabilidades entre el programa y el usuario. A esto le llamamos una aplicación basada en agentes.
· Algunos abordar el problema de la gestión del cambio, pero sólo la programación de adaptación es de anticipar el cambio y automáticamente se ocupan de que dentro de un programa en ejecución, sin necesidad de un programador
· "El software adaptable utiliza la información disponible sobre
cambios en su entorno para mejorar su comportamiento. "
cambios en su entorno para mejorar su comportamiento. "
Adaptive Software Development
Jim Highsmith en su libro [Highsmith, 1999] es la mente detrás de este proceso ágil. ASD consiste en un cambio de filosofía en las organizaciones pasando de la transición del modelo Comando-Control al modelo Liderazgo-Colaboración. Basado en los conceptos de los Sistemas Adaptativos Complejos relacionada con la Inteligencia
Artificial, Highsmith lleva los mismos al campo de la Ingeniería de Software en particular. Dada la complejidad inherente al software concluye que la aplicación de esta teoría es esencial para el nuevo escenario que plantea la economía global.
Comenzando por un cambio en el modelo de desarrollo determinista, tomado del ciclo de Deming, en que se aplica la secuencia Planificar-Ejecutar-Evaluar. Dicho esquema es llevado a la práctica con el modelo en cascada, en que se realiza una precisa planificación inicial mediante el WBS, el Gantt, y el Pert definiendo las tareas a realizar en detalle, luego se tiene las fases de construcción, y finalmente, se tiene el testing que brinda el feedback en relación al producto construido.
EL PROYECTO COMIENZA CON UNA FASE DE ESPECULACIÓN.-E n que en que se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se irán realizando. La utilización del verbo Especular demuestra el interés de Highsmith en demostrar la naturaleza impredecible de los sistemas complejos. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que no será el lugar en que finalizará el proyecto. En cada iteración, se aprenderán nuevas funcionalidades, se entenderán viejas cuestiones, y cambiarán los requerimientos.
Gracias a centrarse en la especulación, ASD permite administrar estos proyectos de alto cambio y rápido desarrollo que se encuentran en el borde del caos. Respecto a la especulación, se recomienda realizar un component breakdown structure en vez del muy conocido y tradicional work breakdown structure (WBS) en el cual mediante una grilla u hoja de cálculo se pueda conocer la funcionalidad a ser liberada en cada ciclo.
Sin embargo, no es más que una especulación ya que el carácter adaptativo del proceso permite pequeñas desviaciones en un sentido – por lo que Highsmith sugiere que cada ciclo se componga de un mix entre funcionalidades críticas, útiles, y opcionales, previendo los posibles retrasos que puedan existir mediante el movimiento de las funcionalidades de menor prioridad a futuros ciclos – y grandes desviaciones en otro, las cuales son utilizadas para la exploración del dominio y de la aplicación, que puede llevar a cambiar el rumbo del proyecto – estos desvíos está representado por las flechas de divergencia en la Figura
LA SIGUIENTE FASE DEL CICLO DE VIDA, COLABORAR, es aquella en la que se construye la funcionalidad definida durante la especulación. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo.
Durante cada iteración el equipo colabora intensamente para liberar la funcionalidad planificada. También, existe la posibilidad de explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto profundamente. ASD no propone técnicas ni prescribe tareas al momento de llevar a cabo la construcción simplemente mencionando que todas las prácticas que sirvan para reforzar la colaboración serán preferidas, siguiendo de esta forma la línea de las metodologías ágiles respecto a la orientación a componentes. El énfasis se ubica en la relaciones entre las personas que deben estar lo suficientemente lubricadas para generar una propiedad imprescindible de los organismos complejos: emergencia. La emergencia es una propiedad de los sistemas adaptativos complejos que crea alguna propiedad más grande del todo (comportamiento del sistema) a partir de la interacción entre las partes
(comportamiento auto-organizativo de los agentes). Gracias a esta propiedad los grupos de desarrollo logran sacar lo mejor de si en la el borde del caos.
LA FASE FINAL DE ASD, APRENDER, consiste en la revisión de calidad que se realiza al final de cada ciclo. En la misma se analizan cuatro categorías de cosas para aprender
[Highsmith, 2000]:
• Calidad del resultado de la desde la perspectiva del cliente
• Calidad del resultado de la desde la perspectiva técnica
• El funcionamiento del equipo de desarrollo y las prácticas que este utiliza
• El status del proyecto
Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar grupos de enfoque en el cliente, mediante los cuales se explora un modelo de la aplicación y se anotan los requerimientos de cambio del cliente.
Las revisiones al diseño, al código o a las pruebas permitirán aprender sobre la calidad de los mismos. En este caso, el énfasis estará puesto en aprender cuales han sido los errores o desvíos y poder resolverlos, y no en encontrar culpables. Asimismo, está es la etapa en que se evaluarán las exploraciones que se hayan realizado dando la capacidad de poder modificar la arquitectura del sistema si se ha encontrado algún camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los requerimientos.
El tercer proceso de feedback está relacionado con la interacción entre las partes, la dinámica de grupo, y las técnicas empleadas. Para medir la performance y el grado de cohesión del mismo, se podrán realizar al final de cada ciclo pequeñas reuniones de postmortem. En las mismas se discuten los aspectos del proceso que contribuyen al desarrollo y aquellos que deben ser descartados por su influencia negativa.
En relación al status del proyecto, se realizarán revisiones para determinar el estado del mismo en relación a lo planificado. En este momento, se detectarán posibles diferencias que pueden surgir de la exploración y que cambiarán el rumbo a que apuntaba el proyecto.
En la Figura se puede ver el detalle interno de cada fase como ya fue explicado, mostrándose con una flecha que trasciende las tres fases en sentido inverso, el bucle de aprendizaje. Este bucle es algo crítico para ASD ya que denota un cambio en el esquema tradicional de la vista de un sistema en que se tenía un bucle de control para detectar diferencias y corregirlas. Es decir, en las metodologías tradicionales las diferencias respecto a lo planificado eran vistas como errores que debían ser enmendados para que cumplieran lo pautado. ASD y las metodologías ágiles plantean la necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de entender más respecto al dominio y construir la aplicación que mejor satisfaga las necesidades del cliente. Highsmith lo expone claramente en la siguiente frase:
En ambientes complejos, el seguir un plan al pie de la letra produce el producto que pretendíamos, pero no el producto que necesitamos.
CONCLUSIÓN,
Tenemos en ASD un marco filosófico basado en la teoría de Sistemas Adaptativos Complejos que nos permite encarar la construcción de software en forma ágil utilizando las prácticas que nos resulten convenientes en cada caso. En este sentido resulta similar a Scrum.
BIBLIOGRAFÍA
No hay comentarios:
Publicar un comentario