TENDENCIAS MODERNAS DE MODELOS DE LA INGENERIA DE SOFTWARE.

TENDENCIAS MODERNAS DE MODELOS DE LA INGENERIA DE SOFTWARE.

Programación Extrema (XP)

De todas las metodologías ágiles, ésta es la que ha recibido más atención. Esto se debe en parte a la notable habilidad de los líderes en el campo de la programación extrema, en particular Kent Beck, para llamar la atención. También se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento, y tomar un papel principal en él. De algunas maneras, sin embargo, la popularidad de la programación extrema se ha vuelto un problema, pues ha acaparado la atención fuera de las otras metodologías y sus valiosas ideas.

Las raíces de la programación extrema yacen en la comunidad de Smalltalk, y en particular la colaboración cercana de Kent Beck y Ward Cunningham a finales de 1980. Ambos refinaron sus prácticas en numerosos proyectos a principios de los 90s, extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente.

La programación extrema empieza con cuatro valores: comunicación, retroalimentación, simplicidad y coraje. Construye sobre ellos una docena de prácticas que los proyectos de este tipo deben seguir. Muchas de estas prácticas son técnicas antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos,

Incluyendo la mayoría de los procesos planeados. Además de resucitar estas técnicas, la programación extrema las teje en un todo sinérgico dónde cada una refuerza a las demás.

En esta plataforma este tipo de programación construye un proceso de diseño evolutivo que se basa en re-factorar un sistema simple en cada iteración. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la más desarrollada entre todas las metodologías adaptables.

La familia de cristal de cockburn

Es una familia porque él cree que los tipos diferentes de proyectos requieren tipos diferentes de metodologías. Él mira esta variación a lo largo de dos ejes: el número de personas en el proyecto, y las consecuencias de los errores. Cada metodología encaja en una parte diferente de la reja, de modo que para un proyecto de 40 personas que puede perder dinero discrecionalmente tiene una metodología diferente a la de un proyecto vital de seis personas.

Los cristales comparten con la programación extrema una orientación humana, pero esta centralización en la gente se hace de una manera diferente. Alistair considera que las personas encuentran difícil seguir un proceso disciplinado, así que más que seguir la alta disciplina de la xp, Alistair explora la metodología menos disciplinada que aun podría tener éxito, intercambiando conscientemente productividad por facilidad de ejecución. Él considera que aunque cristal es menos productivo que la xp, más personas serán capaces de seguirlo.

Alistair también pone mucho peso en las revisiones al final de la iteración, animando al proceso a ser auto mejorante. Su aserción es que el desarrollo iterativo está para encontrar los problemas temprano, y entonces permitir corregirlos. Esto pone más énfasis en la gente supervisando su proceso y afinándolo conforme desarrollan.

Código abierto

Después de todo el código abierto es un estilo de software, no tanto un proceso. Sin embargo hay una manera definida de hacer las cosas haciendo en la comunidad de código abierto, y mucho de su acercamiento es tan aplicable a los proyectos de código cerrado como a los de código abierto. En particular su proceso se engrana a equipos físicamente distribuidos, lo qué es importante porque la mayoría de los procesos adaptables exigen equipos locales.

La mayoría de los proyectos de código abierto tienen uno o más mantenedores. Un mantenedor es la única persona a la que se le permite integrar un cambio en el almacén de código fuente. Sin embargo otras personas pueden hacer cambios a la base del código. La diferencia importante es que estas otras personas necesitan enviar su cambio al mantenedor que entonces lo revisa y lo aplica a la base del código. Normalmente estos cambios son hechos en forma de archivos de parches que hacen este proceso más fácil.

El mantenedor así es responsable de coordinar los parches y mantener la cohesión en el diseño del software.

Proyectos diferentes manejan el papel del mantenedor de diferentes maneras. Algunos tienen un mantenedor para el proyecto entero, algunos lo dividen en módulos y tiene un mantenedor por módulo, algunos rolan el mantenedor, algunos tienen múltiples mantenedores sobre el mismo código, otros tienen una combinación de estas ideas. La mayor parte de la gente de código abierto son de tiempo parcial, así que hay una duda en qué tan bien se coordina un equipo así para un proyecto de tiempo completo.

Un rasgo particular del desarrollo de código abierto es que la depuración es altamente paralelizable. Muchas personas pueden involucrarse en el depurado. Cuando encuentran un bug pueden enviar el parche al mantenedor. Esto es un buen papel para los no mantenedores ya que la mayor parte del tiempo se gasta en encontrar bugs. También es bueno para gente sin mucha destreza en programación.

El proceso para el código abierto aun no se escribe bien. La referencia más famosa es el artículo de Eric Raymond, “The catedral and the bazar”, que aunque es una descripción excelente también es bastante informal. El libro de Karl Fogel sobre el almacén de código cvs también contiene varios buenos capítulos sobre el proceso de código abierto que incluso serían interesantes para aquéllos que no quieren hacer una actualización cvs.

El desarrollo de software adaptable de highsmith

Jim Highsmith ha pasado muchos años trabajando con metodologías predictivas. Él las desarrolló, instaló, enseñó, y concluyó que son profundamente defectuosas: particularmente para los negocios modernos.

Su reciente libro se enfoca en la naturaleza adaptable de las nuevas metodologías, con un énfasis particular en aplicar las ideas que se originaron en el mundo de los sistemas complejos adaptables (normalmente conocida como teoría del caos.) No proporciona el tipo de prácticas detalladas como lo hace la programación

...