Queda entregada la práctica 6 de AESM: Modelado con UML.


Modelado Con UML

Práctica 6 (9ª sesión)

Damos comienzo a la práctica 6 - Modelado UML.

En esta práctica realizaremos el modelado UML del proyecto del cual hicimos el documento de especificación de requisitos (práctica 5). La herramienta CASE elegida para construir los modelos es  Gliffy. El reparto de tareas es el siguiente:


Rómulo Espinosa Montoya

• Diagrama de casos de uso
• Diagrama de clases
• Diagramas de interacción
• Dibujar diagramas de interacción
• Diagramas de estados
• Dibujar diagramas de estados
• Diagrama de actividad
• Revisar documento final

Dulce Isis Segarra López

• Diagrama de casos de uso
• Diagrama de clases
• Dibujar diagrama de clases
• Diagramas de interacción
• Dibujar diagramas de interacción
• Diagramas de estados
• Diagrama de actividad
• Unir documento 

Laura Sirvent Collado

• Diagrama de casos de uso
• Dibujar diagrama de casos de uso
• Diagrama de clases
• Diagramas de interacción
• Dibujar diagramas de interacción
• Diagramas de estados
• Diagrama de actividad
• Dibujar diagrama de actividad

El plazo para terminar todas las partes expira el Martes 22 de Mayo de 2012, día en el que toda la documentación será enviada a Dulce Isis Segarra López, que es la encargada de recibir las diferentes partes en esta práctica. Para la unión de las diferentes partes y para la revisión de las mismas, cada miembro del grupo irá subiendo las versiones de su parte a Google Docs.

Práctica 5 (8ª Sesión)

En esta sesión el grupo se ha dedicado a continuar la práctica y ha resolver las dudas que ha ido apareciendo a los largo el desarrollo de la práctica.

Práctica 5 (7ª Sesión)

Damos comienzo a la práctica 5 - Análisis y especificación de requisitos

Debemos de realizar un análisis y especificación de los requisitos de manera formal del proyecto de red social realizado en la asignatura del primer cuatrimestre Sistemas Multimedia. Hemos concluido en el reparto de tareas de la práctica, quedando la misma de la siguiente forma:

Rómulo Espinosa Montoya

• Introducción: Definiciones, acrónimos y abreviaturas, referencias y resumen
• Descripción General: Perspectiva del producto y funcionalidad del producto
• Requisitos: Requisitos funcionales
• Apéndices
• Dar formato a todo el documento y cohesionar las partes

Dulce Isis Segarra López

• Introducción: Alcance y personal involucrado
• Descripción General: Suposiciones y dependencias y evolución previsible del sistema
• Requisitos Específicos: Requisitos comunes de los interfaces
• Corrección ortográfica

Laura Sirvent Collado

• Introducción: Introducción y propósito
• Descripción General: Características de los usuarios y restricciones
• Requisitos: Requisitos no funcionales, otros requisitos
• Revisión del documento

El plazo para terminar todas las partes expira el Lunes 2 de Abril de 2012, día en el que toda la documentación será enviada a Laura Sirvent Collado, que es la encargada de recibir las diferentes partes en esta práctica. Para la unión de las diferentes partes y para la revisión de las mismas, cada miembro del grupo irá subiendo las versiones de su parte a Google Docs.  

Práctica5-AESM

Refactorización en la práctica: peligros y soluciones - Resumen y preguntas

Resumen

INTRODUCCIÓN

Refactorizar es una práctica muy importante dentro de las metodologías ágiles, como Extreme Programming. Implica hacer modificaciones en el código para así mejorar su estructura interna sin variar el comportamiento del mismo. Por tanto, no es una técnica para modificar la aplicación, o encontrar y corregir errores. Refactorizar más bien consiste en hacer cambios pequeños en el código pero sin variar su comportamiendo, siempre manteniendo el control y sin cometer equivocaciones. Se propone seguir ciertas técnicas matemáticas con el fin de reducir partes complejas del código en partes mucho más simples, y que a fin de cuentas, hacen lo mismo.

Aún así, es importante conocer que en la práctica hay que tener en cuenta ciertos factores que puedan entorpecer o complicar el proceso de refactorización. Factores como por ejemplo el factor humano, que al tener un exceso de celo en querer conseguir un diseño y código perfecto, se pierda demasiado tiempo en realizar infinitas refactorizaciones, o el hecho de estar trabajando en equipo, donde hay que llevar sumo cuidado en la sincronización de las tareas y escuchar a todos los miembros del equipo en sus posibles propuestas de rediseño o refactorización del código.

CARACTERÍSTICAS

Mediante la refactorización obtendremos en nuestro proyecto las siguientes características:

• Calidad: un código de calidad trata de un código sencillo y bien estructurado de forma que cualquiera pueda leerlo y entenderlo en poco tiempo. Esta calidad se obtiene gracias al continuo proceso de reflexión que se lleva a cabo sobre el código pudiendo corregirlo y simplificarlo.
• Eficiencia: gracias a la refactorización obtendremos un código eficiente al evitar la duplicación de código y al simplificarlo, ya que esto nos facilita la modificación y correcion de código y el añadir nuevas funciones.
• Diseño Evolutivo en lugar de Gran Diseño Inicial: se realizará un buen diseño a partir de un simple diseño inicial que sólo represente algunas funcionalidades. Esto se debe a que se va refactorizando el diseño y poco a poco se van añadiendo nuevas funciones haciendo un diseño más completo. El diseño inicial sólo contemplará algunas funcionalidades debido a que inicialmente no se suelen tener claros los requisitos.
• Evitar la Reescritura de código: hay que enfrentarse al código y refactorizarlo en vez de reescribirlo por no seguir los mismos estándares del código ya existente.

CONCLUSIONES

Refactorizar es una técnica muy útil ya que suele abordar uno de los puntos débiles de muchos de los proyectos software, el código.  En muchos proyectos se suele crear el código y comprobar que funcione, pero son pocas las ocasiones en las que se refactoriza el código, es decir, se trata de simplificar y estructurar de tal forma que sea lo más eficiente y claro posible, eliminando redundancias, clases, variables, etc….  Gracias a la posibilidad  de preparar el código para poder adaptarse a cambios en el sistema, esta técnica es empleada sobre todo en el desarrollo ágil de software.

Pero hay ciertos problemas asociados a esta técnica que hacen que algunos equipos no quieran hacer uso de la misma. Esto es debido a que la técnica de refactorizar no ofrece resultados a simple vista, y en muchas ocasiones, se suele pensar que no es útil, sin embargo mantener el código estructurado y simple, puede facilitar futuras pruebas y modificaciones, pudiendo adaptar el código del sistema a construir fácilmente cuando se producen cambios en los requisitos o especificaciones. Otro problema de la factorización es la necesidad de un buen entendimiento entre todo el equipo de desarrollo ya que un cambio por parte de un desarrollador a la hora de refactorizar, puede afectar al resto del equipo, esto puede hacer que el equipo se muestre reticente a refactorizar. Además los desarrolladores encargados de refactorizar pueden sentirse menospreciados por tener que realizar esta tarea y no la de crear código, aunque sea una tan tarea de suma importancia. Por último, un problema muy habitual de esta técnica, es que se emplea la refactorización de código pero no de forma asidua, de tal forma que tratar de refactorizar un código avanzado, amplio y con muchas funcionalidades, se vuelve una tarea demasiado costosa.

En conclusión, refactorizar es una técnica que requiere de un equipo comprometido y crea firmemente en que la refactorización ayuda a crear software de calidad y que se trata de una técnica muy valiosa.

Enlaces utilizados:

• http://www.willydev.net/descargas/WillyDev_Refactorizacion.pdf
• http://es.wikipedia.org/wiki/Refactorizaci%C3%B3n

Preguntas tipo test:

1. La refactorización:

1. Es una técnica en desuso
2. Es idea poco realista por su elevada complejidad
3. Se asemeja a las pruebas unitarias
4. Ninguna de las anteriores

2. Sobre la refactorización:

1. Consiste en tener el mínimo código aunque se pierda funcionalidad.
2. Se basa en simplificar y estructurar el código.
3. Motiva cambios en el código para cambiar la funcionalidad del mismo.
4. Ninguna de las anteriores

3. En refactorización, ¿qué es un “Bad Smell”?

1. Encontramos una parte del programa que no funciona y no sabemos encontrar el por qué.
2. Secciones de código que nos indican que el desarrollo funciona perfectamente y sin problemas.
3. Secciones de código que nos indican que el programa puede volverse problemático o inmanejable si seguimos desarrollándolo.
4. Ninguna de las anteriores.

4. La refactorización continua:

1. Consiste en refactorizar el código cada cierto intervalo de tiempo determinado.
2. Consiste en refactorizar cada vez que se acaba una parte del código, cuando está reciente.
3. Consiste en refactorizar el código al final de cada iteración.
4. Ninguna de las anteriores.

5. La realización de pruebas automáticas:

1. No es necesario en la refactorización, ya que no supone riesgo.
2. Es necesario en la refactorización, ya que el no realizar prueba conllevaría un alto riesgo en la refactorización.
3. Es necesario realizar pruebas automáticas, pero sólo en algunas partes de código.
4. Ninguna de la anteriores.

6. Los pasos de la refactorización son:

1. Pruebas, Herramientas, Formar sobre patrones de refactorización, refactorizar los principales fallos de diseño, refactorizar al final del desarrollo.
2. Pruebas, Herramientas, Formar sobre patrones de refactorización y arquitectura, refactorizar los principales fallos de arquitectura, refactorizar cada nueva funcionalidad.
3. Pruebas, Herramientas, Formar sobre patrones de refactorización y diseño, refactorizar los principales fallos de diseño, refactorizar cada nueva funcionalidad, refacorización continua al completo.
4. Ninguna de las anteriores.

7. La refactorización en el trabajo en equipo supone:

1. Coordinarse en el trabajo de refactorización, porque podrían modificarse archivos que están siendo modificados simultaneamente por otros desarrolladores.
2. Que si un miembro del equipo encuentra una idea diferente a la que se está llevando a cabo, comunicarlo en base a una posible refactorización.
3. Reunirse diariamente el equipo de desarrolladores para plantear las posibles refactorizaciones a llevar a cabo.
4. Todas son correctas.

8. La características de un código simple son:

1. Que el código funciones.
2. Que no haya código duplicado.
3. Que el código permita entender el diseño.
4. Todas las anteriores.

Microsoft patterns & practices - Resumen y preguntas

Resumen

INTRODUCCIÓN

Microsoft Patterns & Practices son una serie de recomendaciones probadas y seguidas por el equipo de desarrollo de Microsoft, que explican cómo se debe diseñar, desarrollar,  desplegar y operar una aplicación para que pueda operar con la arquitectura de la plataforma Microsoft. El equipo de desarrollo sigue la filosofía de las metodologías ágiles, empleando un híbrido entre Scrum y Extreme Programming. Gracias a esto pueden entregar de forma incremental versiones del producto para que el cliente pueda retroalimentar al equipo lo más rápido posible y que el resultado final satisfaga sus exigencias de la forma más completa posible.

Otro punto importante es la distribución del equipo. En los equipos que siguen una metodología ágil, prima la idea de agrupar a todo el equipo de desarrollo y al cliente en una única habitación, pero no siempre será posible pues existen algunos elementos externos que hacen que los equipos sean más distribuidos:

• Mercados mundiales (Global Markets):  en muchas ocasiones las empresas se expanden hacia nuevos mercados, necesitando pues equipos especializados en estos mercados, quizá se lleven a cabo fusiones o adquisiciones, teniendo parte del equipo en una localización diferente.
• Talento global (Global Talent): las empresas suelen buscar empleados experimentados en otras ciudades o incluso otros países. Para ello es necesario disponer de visas de trabajo, soportar los costes de reubicación y contar con el deseo del nuevo empleado de trasladarse.
• Reducción de los costes: a menudo las empresas buscan reducir costes mediante la externalización de ciertos servicios,  teniendo pues equipos en diferentes países. En cualquier caso habrá que tener en cuenta una serie de factores como la reducción de la productividad o los costes adicionales de los viajes para saber si es una opción rentable ya que la reducción de los costes de desarrollo no siempre será suficiente.

Usualmente, el equipo de Patterns & Practices, se compone de owners (propietarios o dueños), developers (desarrolladores), testers (probadores) y documentation writers (redactores de documentación o documentalistas), además si es necesario se unen al equipo expertos de la materia sobre la que se va a trabajar.

En cualquier caso existen una serie de roles con unas responsabilidades asociadas a cada uno:

• Product Owner: es el responsable de representar al cliente, además ayuda al equipo de desarrollo para que puedan entender de forma correcta los requerimientos del mismo.
• Coach: El coach o Scrum Master es el principal responsable de cómo trabaja el equipo, se encarga básicamente de supervisar todo el trabajo y de aportar la retroalimentación necesaria para que todo el equipo trabaje en equipo.
• Team Member: el equipo está compuesto por desarrolladores, testers o probadores y documentalistas.
• Expertos en la materia: se trata de expertos que se incluyen en el equipo siempre que sea necesario pues aportan información valiosa sobre temas concretos.

CARACTERÍSTICAS

Enfocado a la comunicación: los miembros del equipo han de poder comunicarse fácilmente en caso de haber alguna reunión, tener dudas a la hora de realizar una tarea, necesitar la ayuda de un miembro del equipo o comunicarse con el cliente. Por ello, han de tener a su alcance software que les permita comunicarse, por ejemplo por videoconferencia, o una sala cercana a todos ellos con las herramientas necesarias para una reunión (proyector...). Para ello, Microsoft patterns & practices utiliza para comunicarse, teléfonos de mesa, Windows Live Messenger y Office Communicator.

Viajes: en Microsoft patterns & practices en muchas ocasiones se realizan viajes al comienzo, durante y al final del proyecto en los que se reúnen los equipos del mismo con el fin de hacer mejoras en los proyectos, tener retroalimentación entre los equipos o por la necesidad mandar un especialista a otro proyecto en el que no hay este tipo de especialista.

Distribución del equipo: en Microsoft patterns & practices los equipos están distribuidos en diferentes partes del mundo con diferencias horarias significativas. A pesar de ello, son capaces de coordinar a cada uno de los equipos para que cuando cada uno de los equipos llegué a su puesto de trabajo sea capaz de saber que tiene que hacer en función de que han hecho los demás equipos.

Enfocado a dirigir al equipo: en Microsoft patterns & practices se ha guiado al equipo de forma que ellos eligan que metodología es mejor para su forma de trabajo.

Distribución del trabajo: en muchas ocasiones, debido a la distribución del trabajo en diversas partes del mundo, puede que en un proyecto se perciba inconsistente. Por ello, en Microsoft patterns & practices, los distintos equipos se comunican y transfieren sus conocimientos mediante sesiones de emparejamiento y diseño. Todo ello con el objetivo de emparejar y revisar el código independientemente de la zona geográfica.

Construcción del equipo: en múltiples ocasiones no se mantienen los mismos equipos y se contrata a nuevos miembros. El problema de esta situación es que los nuevos miembros pueden tardar en adaptarse a la forma de trabajo del equipo ya existente por falta de docmentación de anteriores proyectos y retrasar el desarrollo de nuevas veriones de un proyecto. Por ello, en Microsoft patterns & practices se intenta mantener al menos a la mitad del equipo, que hizo un proyecto, para la realización de otra versión de dicho proyecto. También se utiliza SharePoint wikis para almacenar la documentación de los proyectos y así poder documentar y poner al día a los nuevos miembros.

Proporcionar la herramientas adecuadas: Microsoft patterns & practices utiliza una serie de herramientas útiles para un seguimiento progresivo y entornos distribuidos:

• Visual Studio Team System
• Scrum for Team System

CONCLUSIONES

Utilizar el desarrollo ágil en equipos distribuidos en mayor o menor grado puede ser satisfactorio para el negocio ya que podemos formar un equipo con mucho talento buscando los mejores miembros en ámbito mundial para cada rol del proceso de desarrollo, disminuyendo además los costes.

Microsoft con sus equipos patterns & practices ha conseguido llegar a esta meta con éxito, aunque siempre siendo consciente de unos posibles inconvenientes que pueden generarse a partir de crear un equipo de desarrollo distribuido, sabiendo que hay que apoyar en todo momento al equipo, facilitando siempre la comunicación entre los miembros, ya sea facilitando y proveyendo los medios para que esta comunicación sea satisfactoria.

Además, otra característica de patterns & practices es centrarse en las historias de usuario ante todo, y desarrollar en base a estas historias, y no en base a funcionalidades o componentes. También es importante para mantener la disciplina en un desarrollo ágil, y más en un equipo distribuido, establecer un rol de coach que ayude a supervisar el trabajo realizado. Otro punto de vital importancia es no realizar cambios drásticos en el equipo de desarrollo de un proyecto a otro, es decir, intentar mantenerlo en el tiempo, o realizar los cambios lenta y gradualmente.

En definitiva, seguir las pautas que Microsoft ha establecido en patterns & practices puede ser satisfactoria y tener un alto grado de éxito para un equipo ágil y distribuido, siempre buscando la mejor forma para mantener un buen ambiente en el equipo y a su vez desarrollando software provechoso y que cumpla las expectativas iniciales.

Enlaces utilizados:

• http://msdn.microsoft.com/en-us/practices/ff921345
• http://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cts=1331660450287&ved=0CEAQFjAC&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F4%2F4%2Fa%2F44a2cebd-63fb-4379-898d-9cf24822c6cc%2Fdistributed_agile_development_at_microsoft_patterns_and_practices.pdf&ei=oIZfT5PJGuPS0QW4vdiPBw&usg=AFQjCNFj33D_qk-IiFQ7IivjuM15v1NbNQ&sig2=kUxflQCH6hAUGcc_Tg37ZQ
• http://netindonesia.net/blogs/wely/archive/2008/07/28/microsoft-patterns-and-practices-an-introduction.aspx

Preguntas tipo test:

1. Los roles presentes en Microsoft Patterns & Practices son:

1. Product Owner, Coach o Scrum Master, Team Member, Expertos en la materia (opional)
2. Product Owner, Team Member
3. Product Owner, Coach o Scrum Master, Team Member
4. Product Owner, Coach o Scrum Master, Team Member, Expertos en la materia

2. Microsoft Patterns & Practices nos ofrece un catálogo de directrices para la construcción de aplicaciones:

1. En la nube
2. De escritorio
3. Web
4. Todas las anteriores

3. Microsoft patterns & practices se basa en las metodologías ágiles:

1. Scrum y Extreme Programming
2. Kanban y Extreme Programming
3. Kanban y Scrum.
4. Ninguna de las anteriores.

4. Cada patterns & practices ofertada es desarrollada:

1. En una comunidad pública conocida como CodePlex.
2. De forma privada, por un equipo de desarrollo conocido como CodePlex.
3. Únicamente por el equipo de desarrollo de Microsoft.
4. Ninguna de las anteriores.

5. Sobre Microsoft patterns & practices:

1. Sigue metodologías tradicionales
2. No externaliza parte de su equipo
3. No emplean roles
4. Ninguna de las anteriores.

6. Microsoft patterns & practices:

1. Recomienda hacer nuevos equipos o grupos de trabajo para cada nuevo proyecto.
2. Recomienta reorganizar el equipo para cada nuevo proyecto.
3. Recomienta no reorganizar continuamente el equipo para cada nuevo proyecto.
4. Ninguna de las anteriores.

7. Los equipos Microsoft patterns & practices:

1. Obligatoriamente deben estar físicamente presentes en un mismo lugar.
2. Igualmente que los equipos de Microsoft, están en un mismo edificio.
3. Suelen estar distribuidos en mayor o menor grado.
4. Ninguna de las anteriores.

8. La distribución de tareas para patterns & practices:

1. Debe hacerse pensando siempre en las funcionalidades del sistema, y no en las historias de usuario.
2. Debe hacerse pensando individualmente en cada historia de usuario.
3. Debe hacerse en función de la localización geográfica de los miembros del equipo.
4. Las anteriores son correctas.

Práctica 4 (6ª Sesión)

En esta sesión el grupo se ha dedicado a la revisión y mejora de la práctica 4. Una vez hecho esto se ha comenzado a realizar la preguntas tipos test de la actividad complementaria.

Práctica 4 (5ª Sesión)

Damos comienzo a la práctica 4 - Herramientas CASE

Para la investigación de las herramientas CASE se ha elegido Visual Paradigm SDE para Eclipse.

Rómulo Espinosa Montoya

• Descripción de la herramienta
• Conclusión
• Corrección ortográfica

Dulce Isis Segarra López

• Prueba de la herramienta
• Revisión del documento

Laura Sirvent Collado

• Manual de usuario
• Dar formato a todo el documento y cohesionar las partes

El plazo para terminar todas las partes expira el Martes 13 de Marzo de 2012, día en el que toda la documentación será enviada a Dulce Isis Segarra López, que es la encargada de recibir las diferentes partes en esta práctica. Para la unión de las diferentes partes y para la revisión de las mismas, cada miembro del grupo irá subiendo las versiones de su parte a Google Docs. 

SDE AESM

Test Driven Development - Resumen y preguntas

Resumen

Introducción

TDD (Test Driven Development), cuyas siglas en inglés significan "desarrollo dirigido por pruebas", es una técnica de diseño e implementación de software basada en metodologías ágiles, que se centra en seguir tres pasos: pruebas, codificación y refactorización.

Más concretamente, el proceso se basa en escribir las pruebas en primer lugar y verificar que el software las falla, para en segundo lugar implementar el código que hace que pase la prueba sin errores, y por último refactorizarlo. Conseguimos así, que el código escrito es robusto y manejable, además de conseguir rapidez en el desarrollo.

Esta metodología está sostenida por tres pilares fundamentales:

1. Implementar las funciones que el cliente pide y no más.
2. Minimizar la cantidad de errores que tiene el software.
3. Producir software modularizado, reutilizable y preparado para el cambio.

Con esta metodología se va a conseguir a partir de realizar las pruebas, analizar profundamente cuales son los requisitos del software, hacer que el código sea el mínimo necesario, reduciendo partes del mismo que resultan innecesarias y que nunca son utilizadas, y además conseguir un código totalmente optimizado, fácil de entender y de mantener, a través de su refactorización.

Características

Podemos enumerar algunas de los hechos que caracterizan TDD:

• Antes de escribir el código, se crean las pruebas. Estas deben ser unitarias, es decir, que hagan pasar sólo una funcionalidad concreta del código.
• El código en primer lugar tiene que fallar la prueba, para así asegurar en que casos el código funciona en qué casos no lo hace.
• Escribir sólo el código mínimo para pasar la prueba, así se asegura que funciona, y que no se va a crear software que nunca va a utilizarse.

Ciclo de vida

1. Requisitos: dados unos requerimientos establecidos para la realización del sistema se escoge el que más fácil parezca y que más información sobre el sistema abarque. Para ello, el desarrollador debe conocer cada una de las especificaciones y requerimientos.
2. Pruebas: el desarrollador debe realizar la prueba del requerimiento escogido una vez entendidos los requerimientos. Las pruebas se habrán de realizar desde el punto de vista del cliente, intentando visualizar la interfaz que ha de ver el cliente.
3. Verificar que la prueba falla: en caso de que la prueba no falle querrá decir que el requerimiento escogido ya se ha implementado o que la prueba es errónea.
4. Implementación: se ha de realizar el código para el requerimiento seleccionado lo más simple posible, de forma que la prueba pase el test realizado.
5. Ejecución de pruebas automáticas: se ha de comprobar si las pruebas realizadas funcionan correctamente mediante el código realizado.
6. Duplicación: se revisa el código realizado en busca de código duplicado. Cada vez que se haga elimine código duplicado se habrán de pasar las pruebas otra vez y, una vez se realicen correctamente, seguir la búsqueda de código duplicado.
7. Actualizar requisitos: una vez hecho las pruebas del requisito seleccionado, y cuando ya se haya implementado y probado, se actualiza la lista de requisitos eliminando el requisito realizado e incorporando nuevos requisitos en caso de que sea necesario.

Ventajas

Las ventajas del Test Driven Development son:

• El programador ve los resultados rápidamente ya que se va desarrollando por partes.
• Permite que el programador se centre en la tarea actual, es decir, que el código pase la primera prueba.
• Ofrece flexibilidad ya que el código se ha realizado en pequeñas partes.
• Obtenemos un catálogo de tests realizados durante el desarrollo del código, los cuales nos servirán para posteriores sistemas.
• Se obtiene un código claro, estructurado y modularizado debido a que se ha desarrollado el software con detenimiento y de forma modularizada para pasar cada una de las pruebas realizadas.
• Al obtener un código más claro y seguro, el programador obtiene un mayor nivel de confianza en el código.

Limitaciones

• Puede resultar difícil de usar esta metodología cuando se requieren pruebas totalmente funcionales para determinar el éxito o el fracaso de una implementación. Algunos ejemplos son los programas que trabajan con bases de datos, ya que es necesario de pruebas muy elaboradas para poder contemplar y probar correctamente un programa de estas características.
  
  
• Es necesario que la dirección del proyecto vea que toda la organización confía en esta metodología, sino podría pensar que el realizar tantas pruebas es una pérdida de tiempo.
  
  
• En la mayoría de ocasiones, la persona que escribe el código es la que crea las pruebas unitarias. Esto es una desventaja, cuando un desarrollador escribe un código a veces no tiene en cuenta ciertos aspectos del sistema o posibles casos de uso de los clientes, es probable entonces, que tampoco tenga en cuenta estos casos o aspectos del sistema a la hora de realizar pruebas. Por ejemplo, si el desarrollador escribe código, y en el mismo no contempla que no se pueda introducir como parámetro un número negativo, seguramente cuando realice las pruebas, no compruebe si esto falla, ya que normalmente los desarrolladores no pruebas cosas que ni tan siquiera pensaron a la hora de escribir el código.
  
  
• Un número elevado de pruebas puede hacer pensar al equipo que el sistema es muy seguro, haciendo que se realicen menos pruebas de las necesarias.
  
  
• Aunque esta metodología esté enfocada en las pruebas, no hay que realizar pruebas demasiado complicadas ya que el mantenimiento y actualización de las mismas también forma parte del desarrollo del proyecto y podrían resultar en un coste más elevado del proyecto. Además si no se realiza un mantenimiento correcto de las pruebas, podrían generar fallos erróneos que con el tiempo se ignorarían, con la consecuencia de que no se podrían detectar los posibles fallos reales.
  
  
• El nivel de cobertura y detalle de las pruebas durante las diferentes iteraciones del Test Driven Development no puede ser recreado en fechas avanzadas del desarrollo del sistema. Por consiguiente, las pruebas originales se convierten en algo muy preciado. En cualquier caso, si debido a un diseño o arquitectura ineficiente o a una estrategia de pruebas incorrecta, se produce un error en fechas avanzadas del desarrollo del sistema, es posible que docenas de pruebas comiencen a fallar, en ese caso la mejor estrategia será atender a cada prueba individualmente.

Opinión personal, conclusiones

Test Driven Development (TDD) es una metodología ideal si se emplea en proyectos cuyo perfil sea el indicado. Por ejemplo, no es una buena idea emplear una metodología de este tipo en un proyecto a gran escala ya que la realización de las pruebas y la escritura del código sería más una carga que una ventaja. Además en esta metodología no se emplea tanta documentación ni se guía tanto el desarrollo como en otras metodologías. Por todo esto hay que saber muy bien cuándo es idóneo emplear Test Driven Development y cuando no.

Una vez se estudian ciertas características y se determina que Test Driven Development es una buena metodología a seguir, ¿por qué usar esta metodología y no otra similar?. Esta metodología nos permite, mediante pruebas, enfrentarnos a problemas tanto concretos como generales, cerrando desde un principio las posibles brechas del sistema y evitando por lo tanto arrastrar una cantidad elevada de fallos a fases avanzadas del desarrollo.

Enlaces utilizados:

• http://www.developer.com/java/ent/article.php/3622546
• http://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebas#Ventajas
• http://en.wikipedia.org/wiki/Test-driven_development#Benefits
• http://www.dirigidoportests.com/wp-content/uploads/2009/12/disenoAgilConTDD.pdf

Preguntas tipo test:

1.Las fases del test driven development se realizan en el siguiente orden:

1. Codificar, Requisitos y Pruebas
2. Requisitos, Codificar y Pruebas
3. Requisitos, Pruebas y Codificar
4. Ninguna de las anteriores

2.Lo más importante en test driven development es:

1. Implementación
2. Interfaz
3. Cumplir los objetivos
4. Todas las anteriores

3.Test driven development ofrece:

1. Flexibilidad
2. Rápidos resultados
3. Código de calidad
4. Todas las anteriores

4.El Test Driven Development:

1. Está dirigido por casos de uso.
2. Está centrado en la arquitectura.
3. Está enfocado en la realización de pruebas.
4. Ninguna de las anteriores.

5.Sobre el Test Driven Development:

1. Es difícil realizar cambios en el código ya que al haberse llevado a cabo tantas pruebas el código es ininteligible.
2. Es fácil realizar modificaciones profundas en el programa, basta con realizar el cambio y pasar las pruebas para saber si todo funciona correctamente.
3. El código no debe modificarse si las pruebas han sido pasadas satisfactoriamente.
4. El código debe modificarse y aunque algunas pruebas fallen se debe continuar.

6.TDD (Test Driven Development) nos conduce a obtener un código:

1. Extensible pero no modularizado.
2. Modularizado pero no flexible.
3. Flexible pero no extensible.
4. Ninguna de las anteriores.

7. ¿Cuál de las siguientes características NO pertenecen a la técnica TDD?:

1. El código implementa las funcionalidades que justo pide el cliente, ahorrando así funcionalidades que no van a ser  utilizadas.
2. Al estar dirigido por casos de usos, es más lento que implementarse utilizando cualquier otra técnica.
3. Produce software modular, reutilizable y preparado para los cambios.
4. Los tests se escriben antes que la implementación.

8.Los tests de TDD:

1. En ningún caso sirven como documentación técnica.
2. Se crean a partir de los casos de uso, y son por tanto, reducciones de éstos.
3. Aunque no falle, se escribe el código igualmente.
4. Están pensados para que cuando el desarrollador esté programando pensando en un test, resuelva otros fallos de su código, aunque no tengan nada que ver con el test.

Práctica 3 (4ª Sesión)

Damos comienzo a la práctica 3 - Metodologías Ágiles

Para la investigación de las diferentes metodologías ágiles se han elegido 3 de ellas, de las cuales cada miembro del grupo investigará.

Rómulo Espinosa Montoya

• DSDM: Dynamic Systems Development Method
• Corrección ortográfica

Dulce Isis Segarra López

• Crystal: Crystal Clear
• Revisión del documento

Laura Sirvent Collado

• AUP: Agile Unified Process
• Dar formato a todo el documento y cohesionar las partes

De cada una de las metodologías se estudiarán los siguientes puntos:

• Introducción (qué es, para qué)
• Características (ventajas, desventajas...)
• Elementos (fases, hitos...)
• Fases
• Roles
• Herramientas de aplicación 

Una vez analizados estos puntos, se realizarán una comparativa grupal de las metodologías investigadas.

El plazo para terminar todas las partes expira el Lunes 5 de Marzo de 2012, día en el que toda la documentación será enviada a Dulce Isis Segarra López, que es la encargada de recibir las diferentes partes en esta práctica. Para la unión de las diferentes partes y para la revisión de las mismas, cada miembro del grupo irá subiendo las versiones de su parte a Google Docs.
Metodologias Agiles