XP (Extreme Programming)

Aunque muchos aun creen que el XP (programación extrema) es tomar el laptop irse a la nieve y lanzarse a 100km/hr  y hacer el terrible algoritmo de programación en c# o java, no lo es.  Así como lo hice en el post de SCRUM, la idea de este es dar una conceptualización general acerca de XP y obviamente con un ejemplo práctico, en base a la información que he logrado reunir de google, libros y articulos fidedignos que hay en la red.

Let’s Begin!!!

¿Que no es XP?

No es una herramienta de software

No es una tecnología

No es una fruta, ni objeto, ni un brazo mecánico ni nada de eso…

Entonces…    ¿Que es XP?

XP es una metodología de desarrollo de software orientada a los procesos mas que a las personas.  Es una metodología porque para poder hacer XP hay que usar los elementos que entrega y hacerlo como nos indica la metodología.  Es parte de aquellas metodologías denominadas “agiles” (i.e. SCRUM).  La gran diferencia que existe entre XP y SCRUM es que ésta última esta mas orientada a los procesos de gestión del proyecto y no involucra demasiado a las pruebas dentro del ciclo de vida, al contrario de XP que si lo hace.  De hecho es uno de los fuertes poderosos de la metodología, incorporar a las pruebas de software de manera fuerte dentro del ciclo de vida del proyecto.  Ahora, que impacto existe en esta nueva forma de trabajo, ¿Porque debo involucrar a las pruebas en la especificación de requisitos y el diseño?.  La respuesta  a esta pregunta no es tan dificil, si tomamos como ejemplo un proyecto de desarrrollo de software cualquiera, usando un ciclo de vida clásico por ejemplo.

Recordatorio:

El ciclo de vida básico de un software consta de los siguientes procedimientos:

  • Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
  • Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
  • Diseño general: requisitos generales de la arquitectura de la aplicación.
  • Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
  • Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
  • Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
  • Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
  • Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
  • Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
  • Implementación
  • Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

Como vemos las pruebas se encuentran casi al final del ciclo de vida y después de la codificación, donde tenemos pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas de aceptación (fases de la Ingeniería de Testing, según el estándar deberían cumplirse como mínimo las mencionadas), si nos ponemos a estimar esfuerzo y horas hombre para las pruebas a estas alturas del ciclo de vida nos podremos dar cuenta de que es mucho mayor el tiempo de inversión, a través de la técnica de amplificación de defectos de la Ingeniería de Testing demostraremos esto, veamos la siguiente imágen:

AmplificacionDefectosTesting

La imágen nos demuestra como es posible amplificar el tiempo de demora de las pruebas de software desde la codificación y hacia los requerimientos del sistema, además como es posible demostrar a partir de una ecuación matemática la detección de defectos de manera temprana.

Pero en fin, toda esa explicación para que puedan darse cuenta del porque XP dentro de su metodología define las pruebas de software de manera temprana…

Continuará…

Anuncios

2 comentarios

Archivado bajo Arquitectura de Software, Magister en Informatica

2 Respuestas a “XP (Extreme Programming)

  1. chancho cero

    Wena viejo!!, la embarro el XP!!! y yo que pensaba que era una metodologia de microsoft (jajajaja), o sea que no hay una programacion vista?(jajajaja), interesante tu blog, te felicito

  2. Es difícil que una organización use simplemente XP. Casi siempre es Scrum & XP, de tal forma que XP nos sirve a un nivel técnico. No se comenta la base de XP, el TDD, no solamente es programar una prueba unitaria, es un giro de 180° practicar TDD. Otro de los pilares fundamentales, la Integración Continua a través de herramientas como Git & Jenkins en el mundo open source o Team Rational Concert de IBM en el mundo privativo.

    Como te comentaba en el post anterior, hay una diferencia muy peculiar y significativa entre la literatura de la ingeniería de software clásica (Somerville por ejemplo) a la ingniería de software ágil, en esta última tenemos joyas como el mini libro Scrum and XP from Trenches (que además es gratis) donde su autor, Henrik Kniberg da una cantidad “terriblemente dolorosa” (así es como el lo describe) de detalles de como implementó Scrum y XP en Crisp, la empresa donde Él labora, es decir, una persona con mucha experiencia en el desarrollo de software empresarial y nos comparte su caso de éxito. Algo diferente a leer la literatura clásica de ingeniería de software, digo, escribirlo detrás de un escritorio, si suena a que funcionará bien, la realidad ha sido muy diferente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s