FANDOM


Estado del Arte

TDD

(Fontela, 2011)[1] afirma que aunque existe mucha evidencia empírica disponible sobre el uso de TDD se presentan algunos inconvenientes. En primer lugar, porque no todos los estudios que se han hecho comparan lo mismo ni se detienen a medir todos los aspectos. Por ejemplo, se esperaría que el tiempo de desarrollo, siendo un factor crítico en la mayor parte de los proyectos, y tal vez más aún en proyectos ágiles, fuese menor usando TDD que si no seguimos la práctica. Pero los estudios no nos ayudan a determinarlo con claridad, ya que no todos miden los tiempos de proyecto de la misma manera ni incluyen el mismo alcance para el ciclo de vida. Hay estudios que excluyen el tiempo de corrección de los defectos del sistema en producción, probablemente por la dificultad de poder medirlo en un experimento acotado en el tiempo; pero precisamente allí se puede esperar un menor retrabajo gracias a TDD. Por la misma razón, el mantenimiento evolutivo, probablemente favorecido por el uso de TDD, tampoco se mide, lo cual sólo tendría sentido para aplicaciones efímeras.

En segundo lugar, hay estudios que han comparado el mismo desarrollo, con y sin TDD, pero esto resulta poco común: la mayor parte de los mismos se enfoca en comparar desarrollos diferentes, lo cual hace dudosa la validez de los resultados obtenidos.

Un tercer inconveniente es que a veces se comparan proyectos disímiles, como uno de juegos sobre dispositivos móviles con otro de control industrial. Estos estudios los hemos desechado. Finalmente, son muy pocos los experimentos en los que se mantuvo a la gente bajo análisis en el desconocimiento de que su trabajo estaba siendo analizado. Y es sabido que el revelar a las personas que están siendo observadas suele generar resultados sesgados.

Otro inconveniente es que en todos los casos de estudio se analizan proyectos desarrollados desde cero con TDD, lo cual está muy en línea con la práctica, pero es poco realista en contextos industriales. De hecho, muy probablemente TDD no se a una buena opción para desarrollar cambios sobre funcionalidades ya existentes de grandes aplicaciones que se hicieron sin pruebas automatizadas. Pero hay zonas grises que tampoco han sido analizadas, por ejemplo, qué tan bueno es TDD para agregar nuevas funcionalidades a aplicaciones que no han seguido a TDD en su desarrollo.

Por lo tanto, podemos seguir sosteniendo que no contamos con suficiente evidencia empírica que cubra todos los tipos de proyectos, tecnologías, tipos de clientes y lenguajes. No obstante, estudios hay, y en ello nos detendremos en este punto. Al fin y al cabo, siempre es difícil realizar experimentos del mundo real en ingeniería de software, y por ello muchas personas los descalifican con expresiones tales como “investigación en pequeño”, agregando que no es válida la extrapolación a grandes proyectos. Pero algo se ha hecho, y sería desatinado descartarlo sin más.

Los trabajos más representativos que el autor ha encontrado son:

  • El realizado en una universidad sueca, que expone el resultado de una investigación industrial que analiza el uso de TDD en 48 trabajos que examinan casos concretos del empleo de la práctica.
  • Un estudio de 4 grupos de trabajo en la industria, en las empresas IBM y Microsoft, de los cuales no todos siguen necesariamente otras prácticas ágiles. Uno de los equipos analizados está disperso en varios países.
  • Un experimento llevado a cabo en una empresa desarrolladora de software en España, en la que todos los desarrolladores eran graduados universitarios en computación, tenían amplio manejo de programación y modelado de software y más 5 años de experiencia con Java, que fue la plataforma elegida.
  • El examen de un caso de desarrollo de aplicaciones móviles con Java ME [33].
  • Una comparación entre dos equipos, uno utilizando una metodología en cascada y otro con XP y TDD, trabajando ambos sobre el mismo alcance de un pequeño desarrollo en una fábrica de software china que trabaja para mercados del primer mundo.

FDD

Para desarrollar el estado del arte de la metodología FDD nos encontramos con escases de documentación y aplicación académica sobre esta temática. De todos modos, a continuación serán citados dos autores que muestran algunos aspectos fundamentales sobre FDD.

(Villarreal Escamilla, 2013)[2] expresa que FDD fue creado inicialmente por Jeff De Luca, para satisfacer las necesidades específicas de un proyecto grande de desarrollo de software de 15 meses y 50 personas en un Banco de Singapur en 1997. Jeff De Luca entregó un conjunto de cinco procesos que cubren el desarrollo de un modelo general, el listado, la planificación, el diseño y la construcción de las funcionalidades.

El primer proceso es influenciado por el enfoque de Peter Coad de modelado de objetos. El segundo proceso incorpora las ideas de Peter para usar una lista de funcionalidades para la gestión de requerimientos funcionales y tareas de desarrollo. Los otros procesos y la mezcla de los procesos en un todo es el resultado de la experiencia de Jeff De Luca. Desde su utilización en el proyecto de Singapur, ha habido varias implementaciones de FDD.

Por otra parte, (Artola, 2009)[3] dice que todas las metodologías ágiles siguen una serie de principios que hacen que se parezcan entre sí. FDD, concretamente, te ofrece unas cuantas claves respecto a la forma de organizar el equipo y la forma de programar el código, que la hacen especialmente viable para equipos de desarrollo grandes desarrollando software complejo.

Biografia de los Autores de "DISEÑO AGIL CON TDD"

Carlos Blé Jurado

   Nació en Córdoba en 1981, hijo de cordobeses pero cuando tenía 4 años emigró a Lanzarote y, salvo algunos años intercalados en los que vivió en Córdoba, la mayor parte de su vida la ha pasado en Canarias. Primero en Lanzarote y después en Tenerife.

   Es ingeniero técnico en informática de sistemas. La primera vez que ganó dinero con un desarrollo de software fue en 2001. En 2003 entró de lleno en el mercado laboral. Al principio trabajó administrando sistemas además de programar.

   En 2005 se le ocurrió la genial idea de montar una empresa de desarrollo de software a medida con sus colegas. Sin tener suficiente experiencia como desarrollador y ninguna experiencia como empresario ni comercial, fue toda una aventura sobrevivir durante los dos años que permaneció en la empresa. Fueron dos años equivalentes a cuatro o cinco trabajando en otro sitio. Ver el negocio del software desde todos los puntos de vista, le brindó la oportunidad de darse cuenta de muchas cosas y valorar cuestiones que antes no valoraba. Aprendió que no podía tratar al cliente como si fuera un tester. No podía limitarse a probar las aplicaciones 10 minutos a mano antes de entregarlas y pensar que estaban hechas. Aprendió que la venta era más decisiva que el propio software. Al final se dio cuenta de que la odisea lo sobrepasaba y no era capaz de llevar la empresa a una posición de estabilidad donde por fín dejase de amanecer sentado frente a la pantalla. Cansado de los morosos y de que la administración pública los tuviera sin cobrar meses y meses, mientras estaba con el agua al cuello, en 2007 se mudó a Irlanda para trabajar como desarrollador. Aprendió lo importante que era tener un equipo de QA1 y se volcó con los tests automatizados. Llegó a vivir el boom de los sueldos en Dublin, cobrando 5000 euros mensuales y sin hacer ni una sola hora extra. En 2008 regresó a Tenerife.

   En la actualidad ha vuelto a emprender. Desarrolla software profesionalmente de manera vocacional. Además se dedica a formar a desarrolladores impartiendo cursos sobre TDD, código limpio, metodología y herramientas de programación. 

José Manuel Beas

   En 2008 decidió aprovechar sus circunstancias personales para tomarse un respiro, mirar atrás, a los lados y, sobre todo, hacia adelante. Y así, aprovechó ese tiempo para mejorar su formación en temas como Scrum asistiendo al curso de Angel Medinilla. Pero también quiso poner su pequeño granito de arena en el desarrollo y la difusión de Concordion, una herramienta de código abierto para realizar pruebas de aceptación, y rellenar su “caja de herramientas” con cosas como Groovy y Grails. Pero sobre todo vio que merecía la pena poner parte de su energía en revitalizar una vieja iniciativa llamada Agile Spain y buscar a todos aquellos que, como él, estuvieran buscando maneras mejores de hacer software. Y vaya que si los encontró. Actualmente es el Presidente de la asociación Agile Spain, que representa a la comunidad agilista en España y organizadora de los Agile Open Spain y las Conferencias Agile Spain. También participa en la elaboración de los podcasts de Podgramando.es, una iniciativa de “agilismo.es powered by iExpertos.com”.

Juan Gutiérrez Plaza

   Escribir, ha escrito poco, pero aprender, muchísimo. Ha intentado hacer algo con sentido con Python en el capítulo 11 aunque más que escribir, ha sido discutir y re-discutir con Carlos sobre cuál era la mejor forma de hacer esto y aquello (siempre ha ganado él). Cuando no está discutiendo con la gente de Agile Spain, trabaja como “Agile Coach” en F-Secure donde intenta ayudar a equipos de Finlandia, Malasia, Rusia y Francia en su transición a las metodologías ágiles (tanto en gestión como en prácticas de software entre las que se incluye, por supuesto, TDD). ¿Pero cómo ha llegado hasta aquí? Su devoción por los ordenadores lo llevó a estudiar la carrera de ingeniería en informática en la UPM de Madrid. Trabajó en España por un tiempo antes de decidir mudarse a Finlandia en el 2004 para trabajar en Nokia. En las largas y oscuras “tardes” del invierno Finlandés estudió un master en “industrial management” antes de cambiar a F-Secure. 

Fran Reyes Perdomo

   Es un apasionado desarrollador de software interesado en “prácticas ágiles”. Lleva cerca de 4 años trabajando para la rígida Administración Pública con un fantástico equipo. Conoció a Carlos Blé en un provechoso curso de TDD que impartió para un grupo de compañeros. Entre cervezas, compartimos ideas y experiencias del mundo del software, y le habló además del proyecto en el que se encontraba embarcado, en el cual le brindó la oportunidad de participar con un pequeño apéndice sobre integración continua. 

Gregorio Mena

   Su corta vida profesional ha sido suficiente para dar sentido a la frase de “Ningún hombre ha llegado a la excelencia en arte o profesión alguna, sin haber pasado por el lento y doloroso proceso de estudio y preparación”. Aunque en su caso el camino no es doloroso, sino apasionante. Siguiendo esta filosofía, intenta formarse y fomentar la formación, por lo que ha organizado un curso de TDD impartido con gran acierto por Carlos Blé y va a participar en futuras ediciones. Trabaja desde iExpertos para que entre todos se pueda hacer posible el primer curso de Scrum en Canarias, pues también colabora con la plataforma ScrumManager.

Biografia del Autor de “METODOLOGÍA FDD”

Luis Calabria

   Es ingeniero en sistemas, especialista en monitoreo y capacitación en la Gerencia de Gestión de Proyectos, División Desarrollo Corporativo de la Administración Nacional de Telecomunicaciones de Uruguay (ANTEL). Tutor de proyectos de fin de carrera y coordinador adjunto del Laboratorio de Simulación y Juegos de la Universidad ORT. 

Relevancia del Material

   La relevancia que adquiere el libro “Diseño Ágil con TDD” es muy grande ya que trae a nuestro idioma conocimiento técnico que lleva años circulando por países de habla inglesa. Tal es así, que hay muy pocos libros, además de este, sobre agilismo en español: Scrum de Juan Palacio, Angel Medinilla ha traducido el libro de Henrik Kniberg (“Scrum y XP desde las Trincheras” y Leo Antolí ha traducido “The Scrum Primer”. 

   Relevancia similar adquiere “Metodología FDD”, aunque no alcanza la dimensión del anterior ya que se trata simplemente de un artículo. De todos modos, en dicho artículo, el autor brinda los conceptos fundamentales para comprender a grandes rasgos de qué se trata FDD.     

Resumen del Libro "DISEÑO ÁGIL CON TDD"

Resumen del Articulo "METODOLOGÍA FDD"

Puntos/tópicos mas importantes

Respecto a TDD, el punto que nos parece más importante y que supone un cambio de mentalidad, es que primero escribo cómo debe funcionar mi programa y después, una vez que lo tengo claro, paso a codificarlo.

   Al escribir el test estoy diseñando cómo va a funcionar el software. Realmente es la forma natural de pensar, primero pensamos en qué queremos hacer y después pasamos al cómo, la diferencia es que con TDD el test ya queda escrito y se ejecutará cada vez que compilamos nuestro programa.   

   Mientras que de FDD, podemos decir que los puntos más importantes son:

  • Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.
  • Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado.
  • Propone tener etapas de cierre cada dos semanas. Se obtienen resultados periódicos y tangibles.
  • Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorear.
  • Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.
  • No hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y construcción. 

Puntos/Temas mas complejos de implementar

Los puntos más complejos de implementar cuando hablamos de TDD son:

  • Hay que utilizarlo y entenderlo bien para que sea realmente productivo, te ayuda a centrarte en lo importante y a no sobrediseñar, pero es importante saber refactorizar el código según vaya evolucionando para que sea consistente.
  • Aunque hay soluciones parciales propuestas, para nosotros TDD solo funciona en la capa de negocio, no encaja con interfaces visuales.
  • Hacer pruebas de código que trabaja con base de datos es complejo porque requiere generar unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba. Los objetos simulados (MockObjects) son otra opción, pero creemos que se pierde mucho tiempo con esto.
  • Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades.
  • Por otra parte, a la hora de hablar de FDD señalamos como puntos complejos de implementar a los siguientes:
  • Falta de documentación del diseño.
  • Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades.
  • FDD es demasiado jerárquico para ser un método ágil.
  • Ausencia de procedimientos detallados de prueba.

Herramientas Automatizadas

Herramientas TDD

Para (Bengochea Casado & Remírez Gabiña, 2014)[4] son muchas y variadas las herramientas que se han ido desarrollando hasta día de hoy. Algunas han surgido en forma de frameworks, otras en formato plug-in bajo el control de algún browser o incluso como librerías para su uso en plataformas de programación.

   Quizás el formato en el que más usado ha sido este tipo de metodología haya sido el de los frameworks, debido a su naturaleza estructural y organizativa que enlaza perfectamente con las características que requiere el TDD, ya que es un modo bastante efectivo de especificar el dominio sobre el que se debe mover el desarrollo de la aplicación.

   Los frameworks que han ido siendo utilizados para el desarrollo de la metodología TDD están agrupados en el conjunto xUnit, los cuales se dividen a su vez en una parte dedicada a las premisas necesarias para la realización de las pruebas y otra parte orientada directamente al proceso de las pruebas en sí mismas.

   Todos estos frameworks poseen sus propias funciones y atributos de clase de test que pueden ser utilizados para incluirlos en la plataforma de desarrollo utilizando el lenguaje correspondiente de forma que puedan ser manejados los test necesarios en cada momento.

xUnit

   Dentro de los xUnit encontramos distintos frameworks, cada uno orientado a su lenguaje de programación y/o a su plataforma de desarrollo:

  • NUnit: este framework se encarga de realizar pruebas unitarias de ensamblajes que desean realizarse en .NET, permitiendo el análisis del diseño a implementar y la ejecución de los test que verifiquen el correcto funcionamiento del mismo.
  • JUnit: este es el framework más importante con que cuenta la metodología TDD, de él han ido surgiendo la mayoría de los frameworks del conjunto de los xUnit. Su importancia seguramente radica en que está basado en el lenguaje java que es un lenguaje muy ágil, reusable y adaptable a otros lenguajes y plataformas. JUnit es utilizado para testear funcionalidades sobre si funcionarán correctamente o no a través de funciones que ya trae consigo el propio framework, como runners para ejecutar directamente los test o asserts para comprobar la validez de los resultados.
  • HttpUnit: viene a ser un cliente web programable. Se puede usar de forma aislada o como complemento del framework JUnit. Básicamente, ha nacido del hecho de pensar que JUnit trabaja sobre java con aplicaciones web y HttpUnit pretende ocupara el vacío que supone que los sitios web se comuniquen a través de http y no de funciones de java. Tiene la capacidad de simular el acceso web de un cliente a un sitio web a través de un navegador, gracias a su simulación de navegadores, control de cookies, manejo de código javascript, etc.
  • DBUnit: en realidad es una extensión de JUnit que tiene como ventaja el poder tener en cuenta la existencia de una base de datos a la hora de realizar las pruebas de los test. De forma que se pueda diferenciar cuando el error ha sucedido por ejemplo por un motivo relativo a la conexión de la base de datos y no relativo al diseño de otro nivel de la aplicación como pueda ser el de navegación o el de presentación.

Edición de Mock’s

   Otro tipo de herramientas importantes de cara al uso del TDD son las dirigidas a la realización de los objetos mockup los cuales no son otra cosa que pequeños diseños de funcionalidades muy concretas que deberá tener la aplicación que deseamos implementar. A partir de esto, han sido varias las librerías que se han ido desarrollando de cara a la elaboración de dichos objetos:

  • EasyMock: sirve para realizar pequeñas pruebas unitarias en complemento con JUnit creando un pequeño diseño o prototipo de un objeto fantasma de forma que compruebe que los resultados devueltos a ciertas entradas introducidas sean los correctos. 
  • JMock: es una librería que nos ayuda en la implementación de las pruebas necesarias cuando utilizamos JUnit para llevar a cabo una metodología TDD. La ventaja de esta librería es su adaptabilidad a la diversidad de tipos de objetos con los que se puede encontrar una aplicación de modo que facilite la tarea, a veces difícil, de realizar un test unitario.    

Improving Test

   Por otro lado, existen otras herramientas que han tratado de mejorar las que ya existían introduciendo nuevas funcionalidades de forma que faciliten la realización de los test y el control del desarrollo TDD que se desea procesar. Principalmente se encuentran estos dos frameworks:

  • TestNG: está basado en JUnit y en NUnit y trabaja con el lenguaje de programación java. Varias son las características que TestNG aporta al desarrollo de pruebas unitarias con JUnit, como capacidad de introducir parámetros, pruebas sobre servidores, funciones para JDK, pero quizás la más importante sea la que permite organizar el desarrollo de los test, de modo que se pueda estructurar el orden en el que queremos que se ejecuten las pruebas. Por ejemplo podríamos ordenar que la prueba ejecutara en primer lugar la carga de datos, después la muestra de dichos datos, la actualización de los mismos y finalizar con el borrado. 
  • Selenium: es toda una herramienta dedicada al Test-driven Development, tiene distintos formatos en los que puede ser utilizados y aporta una importante cantidad de funcionalidades nuevas para la creación de los test. Algunas de estas nuevas características pasan por un mayor control en la simulación de la navegación web desde el punto de vista del cliente. Por ejemplo se podría simular el click que un cliente realiza sobre un enlace o el movimiento del ratón al arrastrar una determinada ventana. De esta forma se amplía el campo sobre el que se puede realizar los test, permitiendo un mayor control de la aplicación según la metodología TDD. 

FDD Tools

(FDD Tools, 2013)[5] se utiliza para producir gráficos de seguimiento de proyecto para compartir con el equipo de gestión y organización en general. Esta herramienta proporciona soporte para sólo una pequeña parte de la metodología FDD, sin embargo, para otros puede ser útil incluso en la situación actual.

   Permite llevar un control gráfico de los programas que se están llevando a cabo.

   La herramienta no se debe instalar ya que para su ejecución trae archivos java (.jar). Es decir, solo debe ejecutarse el archivo principal “FDD Tool” y se abrirá la aplicación.

   Algunas imágenes de la aplicación…

   Así se ve al crear un nuevo proyecto, donde ya se crea un programa por defecto.

FDD1.png

   En esta imagen se abrió un proyecto más avanzado, donde podemos observar que varios de los programas ya fueron terminados, uno está en un 92%, otro en un 40% y uno sin empezar.

FDD2.jpg

   Otro ejemplo en el cual varios de los programas fueron empezados y están en curso.

FDD3.jpg

   También es posible configurar los elementos “Program”:

  • Modificar el nombre del elemento.
FDD4.png
   
FDD5.png
  •    Modificar el elemento planificando tiempos y colocando también tiempos reales consumidos.
FDD6.png

Ventajas y Desventajas de las Metodologías FDD y TDD

TDD

   A continuación se analizarán ventajas y desventajas de TDD propuestas por (Test Driven Development (TDD): Ventajas y desventajas, 2012)[6]

Ventajas

  1. Mayor calidad: garantiza que las pruebas se ejecuten (no sean omitidas), evitando que las aplicaciones tengan fallas la primera vez que el usuario las ejecuta o que el usuario encuentre los errores, en lugar de ser encontrados por el equipo de desarrollo. Asimismo, el hacer pruebas en etapas tempranas del desarrollo es una forma de incorporar la calidad al proceso, resultando en menos errores (bugs) en las etapas finales del proyecto.
  2. Diseño enfocado en las necesidades: el escribir las pruebas primero que el código, obliga a que las necesidades reales del cliente sean consideradas primero, obligando a analizar primero qué es lo que realmente se necesita que el código haga y no al contrario. Como resultado, habrá menos retrabajo después.
  3. Mayor simplicidad en el diseño: en lugar de enfocarse en realizar diseños extensos y complejos, el equipo se enfocará en la necesidad o requerimiento del cliente, agregando solamente la funcionalidad que el cliente necesita. Esto es muy importante, pues es la complejidad la que produce los errores. Esto obliga a escribir código enfocado en las necesidades del usuario, evitando antipatrones como los objetos multipropósito (clase gorda) o el acoplamiento del código, dado que desarrollarán códigos específicos a los requerimientos que se estén atendiendo en esa iteración.
  4. El diseño se va adaptando al entendimiento del problema: a medida que se realizan iteraciones de probar y programar, el entendimiento del problema se incrementa, de esta forma, sucesivas iteraciones cuentan con un mayor entendimiento, lo que reduce los malos entendidos de la funcionalidad al final del desarrollo, resultando en menos retrabajo.
  5. Mayor productividad: en un proyecto tradicional, generalmente lo que sucede es que al principio se es muy productivo, sin embargo, esa productividad cae hacia el final del proyecto, cuando empiezan a encontrarse errores en todas partes, se encuentran malentendidos en lo que el cliente quería, o cuando el cliente hace un par de cambios desestabilizadores. En contraposición a este esquema, una de las principales ventajas de TDD es que se obtiene retroalimentación (feedback) inmediato sobre el software desarrollado.
  6. Menos tiempo invertido en debugging de errores: el código se va desarrollando por piezas pequeñas, por ende, cuando surge un error, los esfuerzos se enfocan en la pequeña pieza de código que fue modificada, por lo que se le pueden llegar a los problemas de forma más directa.

Desventajas

  1. Interfaz de usuario: TDD es difícil de implementar en la capa de interfaz de usuario (presentación), debido a que esta actividad contiene elementos que alargan el ciclo de prueba y desarrollo.
  2. La base de datos: uno de los principales problemas de usar TDD en aplicaciones con bases de datos, es que una vez que se ha ejecutado una prueba, la base de datos puede quedar en un estado distinto al que se necesita para hacer la siguiente prueba (por ejemplo, si la aplicación necesita cambiar el valor de un campo de A a B, cuando la prueba termina el valor queda en B, por lo que no se puede ejecutar una siguiente prueba). Una forma de abordar este problema es escribir código para inicializar la base de datos en el estado previo, sin embargo esto añade carga de trabajo adicional. Otra solución es utilizar objetos para representar la base de datos, por medio de objetos cascaron, respuestas predefinidas o dummies que emulen las respuestas de la base de datos.
  3. Errores no identificados: sólo por el hecho de pasar todas las pruebas en la herramienta que se utilice, no significa que no se tengan errores, sólo significa que las pruebas que se han ejecutado no han encontrado errores. El utilizar TDD podría llevar a un falso sentimiento de seguridad, por ende, se necesita enfocarse en que las pruebas sean detalladas y cubran todos los escenarios posibles.
  4. Perder la visión general (ver el árbol en lugar del bosque): TDD es un enfoque de abajo hacia arriba, y se debe estar al tanto que podría perderse visibilidad general del proyecto y del aplicativo. Es una buena idea mantener un modelo general (bajo un enfoque tradicional como UML) y revisarlo de vez en cuando, quizás se encuentren oportunidades para refactorizar y hacer que la aplicación se le pueda dar mantenimiento en el tiempo.
  5. Pronunciada curva de aprendizaje: TDD es difícil de adoptar, por lo que puede esperarse un descenso en la productividad durante los primeros dos meses de implementación. Lo recomendable para enfrentar esto es buscar ayuda, por medio de formación (cursos) y consultorías que apoyen en la adopción de la nueva forma de trabajo.

FDD

   A continuación se analizarán ventajas y desventajas de FDD propuestas por (Metodología FDD (Feature Driven Development / Desarrollo Basado en Funciones), 2012)[7] y (Estrada Cota, Carreño León, Sandoval Bringas, & Aisputo Félix, 2012)[8].

Ventajas

  1. El diseño de un modelo global al inicio del desarrollo, elimina confusiones entre los miembros de los grupos y ayuda a comprender mejor y con mayor rapidez las características que deben ser implementadas.
  2. El no realizar casos de uso, elimina el tiempo de documentar requerimientos que posiblemente cambien en la siguiente inspección de los usuarios.
  3. Las características son lo más pequeñas posibles, de modo que puedan ser entregadas en máximo dos semanas.
  4. Las inspecciones son continuas y la participación activa del cliente permite la detección de defectos y su corrección a tiempo.
  5. El cliente percibe los resultados en tiempos cortos.
  6. Cada componente del producto final ha sido probado y satisface los requerimientos.
  7. Rápida respuesta a cambios de requisitos a lo largo del desarrollo.

Desventajas

  1. Necesita tener un conocimiento amplio sobre los procesos del negocio y contar con un profesional de alta experiencia para poder diseñar el modelo global del dominio.
  2. La falta de documentación del diseño. El código no puede tomarse como una documentación. En sistemas de tamaño grande se necesitar leer los cientos o miles de páginas del listado de código fuente.

Comparación con Metodologías Tradicionales

Basado en la documentación, en primer lugar cabe aclarar que FDD y TDD son técnicas para el desarrollo del software, más específicamente para la programación y construcción del sistema, que se utilizan en conjunto con una metodología para gestionar todo el proyecto, como Scrum o XP. Lo anterior se justifica en los casos de éxito hallados, donde se encuentran aplicadas de esta manera.

FDD

   En cuanto a FDD, puede ser recomendable su utilización ya que es un proceso iterativo, que reduce los riesgos entregando nuevas funcionalidades en un periodo máximo de dos semanas, contribuye a la calidad en todo el proceso de desarrollo y apunta a la verificación constante de los resultados. Incluye varias características que comparte con otras metodologías modernas y también con metodologías tradicionales.

Tabla2.png

TDD

Si se practica TDD dentro de alguna metodología ágil puede ser recomendable, ya que en su documentación describe grandes ventajas y buenos argumentos para su aplicación, pero también existen algunas dificultades para su puesta en marcha y la escasa cantidad de casos de éxito hallados pone en duda sus buenas prestaciones.

   Sin involucrar las metodologías agiles XP y SCRUM no se recomienda el uso de TDD, debido a que tiene muy poca probabilidad de éxito, es sumamente necesario que exista una estrecha comunicación entre analistas, desarrolladores y testers, y fuera del contexto ágil generalmente no sucede.

Tabla1.png

Casos de Éxito en el uso de TDD y FDD

Innova4j

   (Innova4j)[9] surge como iniciativa de un grupo de profesionales en informática con amplia experiencia en el área de sistemas computacionales y desarrollo de aplicaciones. Está basada en la creciente demanda de servicios y soporte para la utilización de la tecnología Java a nivel empresarial, con amplia disposición al cambio.

   Rompe con los paradigmas de desarrollo tradicionales para convertirse en una empresa que aplica una metodología ágil, cuya pretensión no es buscar desarrollos o desarrolladores perfectos, sino ofrecer técnicas que brinden confianza y a la vez generen valor para sus clientes y las personas que conforman su equipo de desarrollo.

   Mantienen la convicción de ofrecer una primera versión del producto en una etapa muy temprana del desarrollo, minimizando así el riesgo de abandono de proyectos, por tanto continúan generando cambios y retroalimentándose con los usuarios obteniendo una constante motivación positiva.

   Esta empresa no es una casa de software, es un laboratorio de consultoría y desarrollo en constante evolución. Está conformada por expertos en múltiples herramientas que a la vez permanecen motivados por el aprendizaje de nuevos productos y metodologías para estar a la par con los últimos avances en el mundo informático.

   A continuación se podrán ver dos casos de éxito de esta empresa. 

Tarjetas de Crédito Virtuales

   Uno de sus clientes europeos es un integrador online de servicios del sector turístico. Una de las dificultades que afronta todo integrador es el establecimiento de métodos estándar para cobrar y/o pagar los servicios. En particular este utiliza, entre otros medios, tarjetas de crédito virtuales que son generadas por un proveedor externo.   

Desafío

   Para permitir el acceso de manera eficiente por parte de otras entidades de pago que pudieran venir en un futuro, se concibió el proyecto de gestión de recaudo bajo la siguiente premisa: las tarjetas virtuales actúan como garantía de la reserva y como medio de cobro para el proveedor.

   El desafío de esta premisa implicaba la creación de un producto que se convirtiera en un gestor de tarjetas de crédito virtuales. Debería estar en capacidad de integrar nuevos proveedores desde el primer día, y tenía que desarrollarse muy rápido.   

Beneficios

   La arquitectura del proyecto estuvo encaminada a diseñar la solución con enfoque de orientación a servicios para lograr la interoperatividad de diversas entidades. La interfaz se compone de web services basados en el protocolo HTTP y en la especificación REST.

   En la implementación se aplicó la metodología ágil de desarrollo de proyectos Scrum y la práctica de programación TDD (Test Driven Develoment), lo cual trajo para el cliente estos beneficios:

  •    Al enfocarse primero en las pruebas, el equipo de desarrollo tuvo que comprender a cabalidad cómo iba a ser usada la funcionalidad en un entorno del mundo real.
  •     Los ciclos o iteraciones de desarrollo fueron cortas, así el cliente pudo ir validando el producto antes de que estuviera finalizado al 100%.
  •     Se pudo verificar en etapas tempranas la correcta implementación de los requerimientos.

Equipos Geográficamente Distribuidos (Offshoring)

   Innova4j ha tenido la oportunidad de exportar sus productos y servicios a Europa, donde cuentan con una sólida relación de negocios que se originó en el año 2007.

   El estilo de trabajo, expectativas y, en especial, la idiosincrasia, son aspectos fuertemente influenciados por el lugar de origen o de residencia de las personas. Han encontrado gran afinidad de su filosofía de trabajo con empresas europeas, lo cual es apropiado para sostener una relación comercial de largo plazo que sea exitosa.

   Uno de los aspectos clave para lograr esto es mantener una fuerte adherencia a los estándares de calidad, sin perder de vista la agilidad que debe permanecer en rigor en tanto que corresponda a la mejor manera que tenga la empresa para alcanzar las metas de la mano de sus clientes y proveedores.   

Desafío

   En la actualidad, las empresas necesitan contar con el apoyo de profesionales en informática que sean expertos en su negocio y puedan ayudar en todas las etapas del ciclo de desarrollo de sus proyectos, desde la especificación de la necesidad hasta su puesta en marcha, reduciendo el "Time to Market", para poder evolucionar ágilmente en un mundo tan competitivo.   

Beneficios

   Innova4j ofrece a sus clientes un seguimiento completo de los proyectos para conocer en todo momento el estado de avance de los mismos. Este esquema les permite conservar su propia metodología y procesos de análisis que conducen a una mejor definición del producto a desarrollar, además les ha permitido ayudar a implantar nuevas tecnologías y estándares en sus empresas.

   El proceso inicia cuando la documentación que reciben para un nuevo proyecto es revisada por su equipo de análisis para realizar una oferta técnica y comercial, la cual es refinada con el interventor designado. Una vez  aprobada registran en su sistema de gestión de proyectos todas las tareas que hayan sido identificadas, luego son priorizadas y se inicia un desarrollo iterativo. Los clientes pueden conocer el estado, porcentaje de avance, y las anotaciones que se hayan hecho a cada tarea, de tal forma que puedan participar muy activamente del control y monitoreo del proyecto, basados en el enfoque de la metodología Scrum.

   El modelo TDD (Test Driven Development) que utilizan ayuda a reforzar este propósito, ya que los casos de prueba pueden ser analizados por el cliente para confirmar si cubre toda la lógica de negocio que se espera que el producto pueda satisfacer.

   La tenencia de un ciclo continuo de integraciones de los desarrollos permite detectar desde las primeras etapas las mejoras necesarias para evitar que se tengan impactos fuertes en la obtención de la meta final.   

Banco de Singapur

   (Rocha Boza, Mendez Salas, Jimenez Herrera, & Lumbi, 2013)[10] expresan que FDD nació a raíz de un proyecto de software de un gran banco en Singapur en 1997, cuyo resultado solo fue un modelo de objetos complejos y ningún código con funcionamiento, llegando a concluir que no se podía realizar el proyecto. Entonces Jeff De Luca a finales de 1997 es contratado para salvar este gran y complicado proyecto de software que posteriormente contrata a Peter Coad. Jeff De Luca entregó un conjunto de cinco procesos que cubría el desarrollo de una estrategia global modelo y el establecimiento, planificación, diseño y construcción de características. El primer proceso está fuertemente influenciado por el enfoque de Peter Coad de modelado de objetos. El segundo proceso incorpora las ideas de Peter Coad de utilizar una lista de funciones para gestionar los requisitos funcionales y tareas de desarrollo. Los otros procesos y la mezcla de los procesos en un todo cohesivo es un resultado de la experiencia de Jeff De Luca. Desde su utilización con éxito en el proyecto de Singapur, ha habido varias implementaciones de FDD. 

Bayt.com

   (Abuhijleh, 2009)[11] afirma que en Bayt.com realizaron estudios previos para determinar la utilización de la metodología. Luego de un tiempo, optaron por utilizar FDD. Si bien consideraron que SCRUM, como todas las otras metodologías ágiles es excelente en el apoyo de entornos de desarrollo de software orientado al ser humano,  piensan que carece de puntos de control bien definidos (hitos) y además se centra claramente más en el aspecto de gestión de proyectos que en la parte de desarrollo de software. 

Vídeo resumen de la Metodología FDD

Metodología FDD (Feature-Driven Development)01:48

Metodología FDD (Feature-Driven Development)

Bibliografia

  1. Fontela, M. C. (Junio de 2011). Estado del arte y tendencias en Test-Driven Development. La Plata, Buenos Aires, Argentina.
  2. Villarreal Escamilla, F. D. (1 de Agosto de 2013). Adopción de una metodología ágil para proyectos de software . México.
  3. Artola, L. (21 de Julio de 2009). Programania. Recuperado el 06 de Septiembre de 2014, de Feature Driven Development : http://www.programania.net/desarrollo-agil/feature-driven-development/
  4. Bengochea Casado, B., & Remírez Gabiña, N. (Julio-Agosto de 2014). TDD. Epistemowikia, 8(3)
  5. FDD Tools. (2013). Recuperado el 12 de Septiembre de 2014, de surceforge: http://sourceforge.net/p/fddtools/wiki/Home/
  6. Test Driven Development (TDD): Ventajas y desventajas. (3 de Diciembre de 2012). Recuperado el 10 de Septiembre de 2014, de PMOInformática.com: http://www.pmoinformatica.com/2012/12/test-driven-development-ventajas-y.html
  7. Metodología FDD (Feature Driven Development / Desarrollo Basado en Funciones). (12 de Junio de 2012). Recuperado el 2014 de Septiembre de 2014, de Metodología FDD: http://metodologiafdd.blogspot.com.ar/
  8. Estrada Cota, I., Carreño León, M. A., Sandoval Bringas, J. A., & Aisputo Félix, E. E. (Enero-Abril de 2012). Metodología Ágil FDD aplicada al desarrollo de un Sistema Web para el control de Asistencia. Computación y Tecnología(3)
  9. Innova4j. (s.f.). Recuperado el 07 de Septiembre de 2014, de http://innova4j.com:8080/web/guest
  10. Rocha Boza, E., Mendez Salas, W., Jimenez Herrera, M., & Lumbi, J. R. (13 de Septiembre de 2013). Metodología FDD. Recuperado el 08 de Septiembre de 2014, de Prezi: http://prezi.com/1k5pu8arfhnu/metodologia-fdd-feature-driven-development-desarrollo-bas/
  11. Abuhijleh, A. Y. (5 de Diciembre de 2009). Perspective: FDD vs SCRUM. Recuperado el 11 de Septiembre de 2014, de IT Project Management and Service Management Expert: http://abuhijleh.net/2009/12/05/scrum-vs-fdd/

¡Interferencia de bloqueo de anuncios detectada!


Wikia es un sitio libre de uso que hace dinero de la publicidad. Contamos con una experiencia modificada para los visitantes que utilizan el bloqueo de anuncios

Wikia no es accesible si se han hecho aún más modificaciones. Si se quita el bloqueador de anuncios personalizado, la página cargará como se esperaba.

También en FANDOM

Wiki al azar