Existen herramientas gratuitas de buena caliadad para UML. Tanto Netbeans como Eclipse soportan esta funcionalidad con el ciclo completo de desarrollo desde generación de código hasta reingenieria. Esto, claro, si se quiere trabajar en Java. En .Net no he encontrado este grado de funcionalidad en herramientas Open Source. Una opción de bajo costo, relativo a RUP y similares, es Visual UML. Visual Paradigm tiene una edición limitada sin costo, Smart Development Environment Community Edition for Visual Studio.
Uno de los problemas fundamentales con las metodologías de desarrollo, de hecho, con cualquier esfuerzo de normalizar un proceso entre personas, es que el deber ser en un sentido moral idealista obscurece el es. eXtreme Programming es un enfoque contra intuitivo para aumentar la productividad de los programadores.
A pesar de los esfuerzos heroicos del equipo de mercadotecnia y de la necesidad de los usuarios de mantener los costos bajos, un programador es productivo alrededor de 2 a 4 horas diarias en promedio. Un monstro en el closet pero una realidad. Esto anuado al hecho de la programación es una arte en al que unos pocos virtuosos pueden realizarla con soltura, 5% de los programadores (o menos) hacen 95% del trabajo (o más). Por eso los beneficios de programación en pares en realidad no implican un costo en productividad. Antes al contrario, probablemente un equipo de 2 de programadores trabajando bajo el esquema de programación extrema sea 2 a 3 veces más productivo que los mismos programadores trabajando de manera aislada.
El énfasis en diseño y pruebas es simplemente una realidad del ciclo de desarrollo:
Un defecto en codificación es un defecto, aunque corregirlo puede generar más defectos.
Un error en la fase de diseño produce más de 10 defectos en código
Un error en la fase de levantamiento de requerimientos produce más de 100 defectos en código
Por eso el esfuerzo de desarrollo debe concentrarse en el análisis y realizar iteraciones cortas donde rápidamente la funcionalidad del sistema sea aparente al usuario final y este pueda dar la retroalimentación necesaria para mantener las cosas en la dirección correcta de manera eficaz.
El esfuerzo de desarrollo debe seguir aproximadamente la siguiente ponderación:
Seguí los ejemplos del libro, la primera parte usando C#; aunque el libro usa Java y la segunda parte con Python 3.1, haciendo algunas adecuaciones al código del libro. De hecho, primero lo intente con IronPython para seguir con el tema de .Net, pero con Python 3.1 y IDLE me fue más fácil hacer trabajar el código.
TDD es una técnica avanzada que en su expresión ortodoxa no es seguida ni por el mismo Beck. Es fácil caer en callejones sin salida y el desarrollador debe tener un plan top-down implícito basado en su experiencia y dominio técnico. Por otro lado su aceptación y referencias de éxito son evidencia de su validez.
La primera parte del libro me pareció incompleta, llena de manitas de puerco, visión nocturna, multiplicaciones por el número que pensaste, y conjuros de magia negra.
la segunda parte es de más alto nivel de abstracción pero muestra claramente los fundamentos del marco de xUnit. El uso de Python aquí parece apropiado ya que permite desarrollar la estructura básica de xUnit de manera clara y directa.
