Las pruebas que comprueban la corrección del código fuente de una aplicación son

Clasificado en Otras materias

Escrito el en español con un tamaño de 6,99 KB

 

Metodologías Ágiles


EXTREME PROGRAMMING

1.-Ingenierí a del software: (Introducción)



No existe el proceso de desarrollo que sirva para todo tipo de proyecto. XP no es valido para cualquier proyecto. No es valido para equipos grandes, clientes desconfiados o tecnologías sin soporte a cambios graduales. Los procesos clásicos tampoco son validos para todos los proyectos.

2.-¿ Qué es XP?



-

Definición:

proceso ligero de desarrollo de software OO.
-Diseñado para centrase en 4 cosas: Escuchar, Pruebas, Codificar, Diseñar
-Carácterísticas: + El código es el centro de todo el proceso. +Las prácticas son aplicadas de forma extrema. +Ninguna de las ideas es nueva. +La combinación de ideas y su aplicación extrema es lo que define XP.

3.- Desconcertante


-No hay documentación del diseño. Tampoco existen estándares de cómo se debe documentar.
-Sin diseño. El diseño se refleja en cada actividad diaria pero no existe un diseño explicito.
-XP es fácil. Trata de trabajar con tendencias naturales pero requiere gran disciplina y consistencia.
-XP es ideal para algunos tipos de proyectos.

4.-Prá cticas


-XP se basa e la aplicación de 12 practicas (guidelines or rules):
a.)

Proceso Continuo:

(Releases frecuentes, Refactoring, Integración continua.)
b.)

Feedback rá pido:

(Pruebas, Programación en pareja, Cliente in-situ.)
c.)

Conocimiento compartido:

(Propiedad colectiva de código, Codificación estándar, Planning game, Metáfora, Diseño simple.)
d.)

Beneficio al Desarrollador:

(Semanas de 40 horas).

5.-Planning Game


-

Piezas:

requisitos de usuario
-

Participantes:

usuario & desarrollador
-

Acciones:


a.)

Recogida de requisitos del usuario

Los requisitos son escritos por el usuario en pequeñas tarjetas, escritas en un lenguaje propio del negocio y describen las cosas que el sistema debe hacer. A cada tarjeta se le asigna un valor de importancia sobre el negocio. Para un proyecto de pocos meses debe haber entre 50 y 100 tarjetas.
b.)

Estimació n

El desarrollador asigna un coste a cada tarjeta. El coste se mide en semanas (1-3 semanas). Un tarjeta debe ser partida por el usuario si supera las 3 semanas.
c.)

Acuerdo:

El usuario y el desarrollador deciden que tarjetas constituyen la próxima release.
d.)

Valor y riesgo primero:

El desarrollador ordena las tarjetas de la release teniendo en cuenta: Las tarjetas más importantes o de más riesgo se colocan antes en la planificación, Se debe poder generar un sistema ejecutable en 2 semanas.

6.-Releases frecuentes


-El proceso de desarrollo es muy iterativo.
- El ciclo de una release no debe superar los 3 meses.
-Un ciclo consiste de iteraciones de no más de 3 semanas.
-En cada iteración se implementan las tarjetas seleccionadas.
-Cada tarjeta se divide en tareas de programación de 1 a 3 días.
-Releases pequeñas y frecuentes proporcionan información constante del usuario.

7.-Metá fora de sistema


-Sinónimo de arquitectura e sistema. Proporciona una vista global de los objetivos del proyecto. Define el ámbito al que se pueden referir desarrolladores y usuario. El sistema se construye a partir de uno o más system metaphor a partir de los cuales se deriva.

8.-Pruebas


-Las pruebas juegan el papel más importante en XP. Se escriben antes de codificar (Fuerza la concentración en los interfaces, Acelera el desarrollo, Asegura la codificación y el refactoring.
)
-Todos los test son automatizados (framework de pruebas, pe. Junit).
Si las tarjetas son consideradas los requisitos las pruebas son consideradas la especificación del sistema.
-2 tipos de pruebas:

A.)Pruebas de aceptació n (funcionales):


El usuario proporciona los casos de prueba para sus tarjetas. Los desarrolladores los automatizan.

B.)Pruebas unitarias:


Los desarrolladores escriben las pruebas para sus clases (antes de implementar las clases). Todas las pruebas unitarias deben ser ejecutadas siempre con 100% de éxito.


9.-Refactoring


-Proceso de mejora del código que mantiene la funcionalidad ya creada. Los objetivos de refactorizar son: (Hacer el diseño más simple, Hacer el código más legible, Mejorar la tolerancia de cambios del código.)
-El código no debería necesitar comentarios: (No hay documentación en XP, El código y las tarjetas de usuario son la única documentación.)
-Se deben usar nombres significativos.
Refaztorizar se hace constantemente. Eliminar el código duplicado. Las pruebas garantizan que la refaztorización no ha cambiado el comportamiento.

10.-Programació n en pareja


-Se sientan 2 programadores por ordenador: (Uno introduce el código, Y otro revisa el código y piensa.)
-Es la segunda práctica más importante después de las pruebas.
-Las parejas cambian constantemente (varias veces en el día). Cada programador sabe todos los aspectos del sistema. Un programador puede ser sustituido fácilmente.
-El código es más simple (menos líneas) y con menos defectos. Se asegura la continua inspección del código.
-El coste es de 10-15% más que en programación normal (uno solo).

11.-Propiedad colectiva del có digo


-El código pertenece a un equipo y no a un programador. Un programador puede cambiar el código en cualquier momento para: (Hacerlo más simple, Hacerlo mejor.) Esto obliga al equipo a trabajar más estrechamente y por lo tanto los programadores producen código de mayor calidad: Más limpio, el sistema mejora y todos conocen mejor el sistema.

12.-Integració n continua


-Al menos integración diaria. Todo el sistema se construye cada 2 horas.
-El ciclo: Desarrollar pruebas unitarias, Codificar, Integrar, Ejecutar todas las pruebas, hacer release.
-Siempre hay disponible una versión probada del sistema.

13.-Semanas de 40 horas


-Los programadores no deberían trabajar más una semana con horas extras. Si tienen que trabajar más es que hay algo mal en la planificación y por lo tanto mantiene a la gente feliz. Esto hace q los programadores están descansados y trabajan más eficientemente.

14.-Usuario in-situ


-Las tarjetas de usuario no están detalladas y siempre hay cosas que preguntar al usuario. El usuario debe estar disponible para: (Resolver ambigüedades, Establecer prioridades, Proporcionar casos de prueba.)
-El usuario debe ser considerado como parte del equipo.

Entradas relacionadas: