Ingeniería de Software I

INGENIERÍA DE
SOFTWARE I

Investigación Sobre
Programación Extrema (XP)

Docente:
Licda. Lourdes Lorena Mendoza
Medina

Estudiante:

Campus CEUTEC

Fecha: 05 de Febrero de 2018

2018
Ingeniería de Software I

Programación Extrema
La programación extrema o EXtreme Programming (PX) es un
enfoque de la Ingeniería de Software formulado por Kent Beck, autor
del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change 1999. Es el más destacado de los procesos ágiles
de desarrollo de software.

Al igual que éstos, la programación extrema se diferencia de las

metodologías tradicionales principalmente en que pone más énfasis en
la adaptabilidad que en la previsibilidad. Los defensores de PX
consideran que los cambios de requisitos sobre la marcha son un
aspecto natural, inevitable e incluso deseable del Desarrollo de
Proyectos.

Creen que ser capaz de adaptarse a los cambios de requisitos en

cualquier punto de la vida del proyecto es una aproximación mejor y
más realista que intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos después en controlar los cambios en los
requisitos.

Resumiendo: Se puede definir la programación extrema como la

adopción de las mejores Metodologías de Desarrollo de acuerdo a lo
que se pretende llevar a cabo con el proyecto, y aplicarlo de manera
dinámica durante el Ciclo de Vida del Software.

Valores en Programación Extrema

Comunicación
Muchos de los problemas que existen en proyectos de software (así
como en muchos otros ámbitos) se deben a problemas de
comunicación entre las personas. La comunicación permanente es
fundamental en XP. Dado que la documentación es escasa, el diálogo
frontal, cara a cara, entre desarrolladores, gerentes y el cliente es el

2018
Ingeniería de Software I

medio básico de comunicación. Una buena comunicación tiene que

estar presente durante todo el proyecto.

Simplicidad
XP, como metodología ágil, apuesta a la sencillez, en su máxima
expresión. Sencillez en el diseño, en el código, en los procesos, etc.
La sencillez es esencial para que todos puedan entender el código, y
se trata de mejorar mediante recodificaciones continuas.

Retroalimentación
La retroalimentación debe funcionar en forma permanente. El cliente
debe brindar retroalimentación de las funciones desarrolladas, de
manera de poder tomar sus comentarios para la próxima iteración, y
para comprender, cada vez más, sus necesidades.

Los resultados de las pruebas unitarias son también una

retroalimentación permanente que tienen los desarrolladores acerca
de la calidad de su trabajo.

Coraje
Cuando se encuentran problemas serios en el diseño, o en cualquier
otro aspecto, se debe tener el coraje suficiente como para encarar su
solución, sin importar que tan difícil sea. Si es necesario cambiar
completamente parte del código, hay que hacerlo, sin importar cuanto
tiempo se ha invertido previamente en el mismo.

Respeto
El valor del respeto en XP establece: “Todos en el equipo dan y
reciben el respeto que merecen como integrantes del equipo y los
aportes de cada integrante son valorados valorados por todos. Todos
contribuyen, así sea simplemente con entusiasmo. Los desarrolladores
respetan la experticia de los clientes y viceversa. La Gerencia respeta
el derecho del equipo de asumir responsabilidad y tener autoridad
sobre su trabajo”.

Respeto es tanto por el trabajo de los demás como por el trabajo de

uno mismo, por ejemplo, los desarrolladores nunca deben subir
cambios que impidan la compilación de la versión, que hagan fallar
2018
Ingeniería de Software I

pruebas unitarias ya realizadas o que de alguna otra forma retrasen el

trabajo de sus pares, esto significa tener respeto por el trabajo (y el
tiempo) de los demás.

Asimismo, los desarrolladores respetan su propio trabajo por medio de

su compromiso con una alta calidad y buscando el mejor diseño para
la solución por medio de la refactorización constante.

En cuanto al trabajo en equipo, nadie debe sentirse poco apreciado o

ignorado, todos deben colaborar en esto, tratando con respeto a sus
compañeros y mostrando respeto por sus opiniones, esto asegura
altos niveles de motivación y lealtad hacia el proyecto.

El Ciclo de Vida de Programación Extrema

Fase I: Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de
usuario que son de interés para la primera entrega del producto. Al
mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologías y prácticas que se utilizarán en el proyecto.
Se prueba la tecnología y se exploran las posibilidades de la
arquitectura del sistema construyendo un prototipo. La fase de
exploración toma de pocas semanas a pocos meses, dependiendo del
tamaño y familiaridad que tengan los programadores con la tecnología.

Fase II: Planificación de la Entrega

En esta fase el cliente establece la prioridad de cada historia de
usuario, y correspondientemente, los programadores realizan una
estimación del esfuerzo necesario de cada una de ellas. Se toman
acuerdos sobre el contenido de la primera entrega y se determina un
cronograma en conjunto con el cliente. Una entrega debería obtenerse
en no más de tres meses. Esta fase dura unos pocos días.

2018
Ingeniería de Software I

Las estimaciones de esfuerzo asociado a la implementación de las

historias la establecen los programadores utilizando como medida el
punto. Un punto, equivale a una semana ideal de programación. Las
historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo
de desarrollo mantiene un registro de la "velocidad" de desarrollo,
establecida en puntos por iteración, basándose principalmente en la
suma de puntos correspondientes a las historias de usuario que fueron
terminadas en la última iteración.

La planificación se puede realizar basándose en el tiempo o el

alcance. La velocidad del proyecto es utilizada para establecer
cuántas historias se pueden implementar antes de una fecha
determinada o cuánto tiempo tomará implementar un conjunto de
historias. Al planificar por tiempo, se multiplica el número de
iteraciones por la velocidad del proyecto, determinándose cuántos
puntos se pueden completar. Al planificar según alcance del sistema,
se divide la suma de puntos de las historias de usuario seleccionadas
entre la velocidad del proyecto, obteniendo el número de iteraciones
necesarias para su implementación.

Fase III: Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser
entregado. El Plan de Entrega está compuesto por iteraciones de no
más de tres semanas. En la primera iteración se puede intentar
establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las historias
que fuercen la creación de esta arquitectura, sin embargo, esto no
siempre es posible ya que es el cliente quien decide qué historias se
implementarán en cada iteración (para maximizar el valor de negocio).
Al final de la última iteración el sistema estará listo para entrar en
producción.

Los elementos que deben tomarse en cuenta durante la elaboración

del Plan de la Iteración son: historias de usuario no abordadas,
velocidad del proyecto, pruebas de aceptación no superadas en la
iteración anterior y tareas no terminadas en la iteración anterior. Todo

2018
Ingeniería de Software I

el trabajo de la iteración es expresado en tareas de programación,

cada una de ellas es asignada a un programador como responsable,
pero llevadas a cabo por parejas de programadores. Wake en [18]
proporciona algunas guías útiles para realizar la planificación de la
entrega y de cada iteración.

Fase IV: Producción

La fase de producción requiere de pruebas adicionales y revisiones de
rendimiento antes de que el sistema sea trasladado al entorno del
cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión
de nuevas características a la versión actual, debido a cambios
durante esta fase.

Es posible que se rebaje el tiempo que toma cada iteración, de tres a

una semana. Las ideas que han sido propuestas y las sugerencias son
documentadas para su posterior implementación (por ejemplo, durante
la fase de mantenimiento).

Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto
XP debe mantener el sistema en funcionamiento al mismo tiempo que
desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas
de soporte para el cliente. De esta forma, la velocidad de desarrollo
puede bajar después de la puesta del sistema en producción. La fase
de mantenimiento puede requerir nuevo personal dentro del equipo y
cambios en su estructura.

Fase VI: Muerte del Proyecto

Es cuando el cliente no tiene más historias para ser incluidas en el
sistema. Esto requiere que se satisfagan las necesidades del cliente
en otros aspectos como rendimiento y confiabilidad del sistema. Se
genera la documentación final del sistema y no se realizan más
cambios en la arquitectura. La muerte del proyecto también ocurre
cuando el sistema no genera los beneficios esperados por el cliente o
cuando no hay presupuesto para mantenerlo.

2018
Ingeniería de Software I

Principios Básicos Programación Extrema

Tenemos 12 principios básicos que se agrupan en 4 categorías
distintas:

Retroalimentación
Principio de pruebas: lo primero que se debe hacer es establecer un
período de pruebas de aceptación del programa, en el cual se
definirán las entradas y salidas del sistema. Básicamente se define lo
que debe hacer el software desarrollado. Como si fuese una caja
negra.

Planificación: el cliente (o su representante) escribirá sus

necesidades para definir concretamente las actividades que el sistema
debe realizar. En esta fase se creará un documento que contendrá
historias de usuario que forman el plan de liberación, el cual define los
tiempos de entrega de la aplicación para poder recibir feedback por
parte del cliente.

Cliente in-situ: el cliente (o su representante) deberá formar parte del

equipo de desarrollo. Se le dará poder para determinar los requisitos
de la aplicación, definir la funcionalidad y dar prioridad a determinadas
cosas. Gracias a esto, habrá una fuerte interacción con los
programadores, disminuyendo así el tiempo de comunicación y la
cantidad de documentación a redactar. El cliente estará con el equipo
durante todo el proceso de desarrollo del proyecto.

Pair-programming: este punto junto con el anterior son los más

radicales de esta metodología. Consiste en escribir código en parejas
compartiendo una sola máquina. Según los experimentos ya
realizados sobre este método, se producen mejores y más
consistentes aplicaciones a igual o menor coste.

Proceso Continuo en Lugar de por Bloques

Integración continua: consiste en implementar progresivamente las
nuevas características del software. En lugar de crear versiones
estables en función de una planificación previamente realizada, los

2018
Ingeniería de Software I

programadores reúnen su código y reconstruyen el proyecto varias

veces al día si hace falta.

Refactorización: mediante la constante eliminación de código

duplicado y/o ineficiente los equipos de programación mejoran el
diseño del sistema. El código se evalúa continuamente para ofrecer la
mayor calidad posible.

Entregas pequeñas: el producto es evaluado en un ambiente real

mediante la colocación de un sistema sencillo en producción el cual se
actualizará rápidamente, es decir, cada 2 semanas (3 como máximo)
el software será puesto en producción.

Entendimiento Compartido
Diseño simple: el mejor programa será aquel que cumpla con los
requisitos y sea más simple. Es importante proporcionar un software
que cubra las necesidades de un cliente. Ni más ni menos.

Metáfora: expresa la visión evolutiva del proyecto y define los

objetivos del sistema mediante una historia.

Propiedad colectiva del código: el código tiene propiedad

compartida. Nadie es propietario de nada, ni siquiera de lo que ha
desarrollado. Todos los programadores son "dueños" de todo el
código. Según esta metodología, cuantos más programadores haya
trabajado en una parte de código, menos errores tendrá.

Estándar de programación: define las reglas para escribir y

documentar código, además de cómo se comunican las diferentes
piezas de código desarrolladas por diferentes equipos. El objetivo de
esto es que parezca que el código ha sido escrito por una única
persona.

Bienestar del Programador

Semana de 40 horas: los programadores cansados escriben peor
código. Es importante minimizar las horas extras y mantener a los
programadores frescos y descansados. De esta manera, se generará

2018
Ingeniería de Software I

mejor código. Si es necesario hacer horas extras, quiere decir que el

proyecto está mal planificado.

Cuando se Aplica Programación Extrema

Es mejor utilizar XP cuándo el proyecto en cuestión tiene un alto
riesgo de elementos añadidos. Quizá sea satisfacer un plazo muy
ajustado. Quizá sean alguna cantidad o medio de requerimiento
dinámico desconocido que la solución propuesta no tiene garantías de
satisfacer. Cabe la posibilidad de que la solución propuesta sea tan
avanzada que corre el riesgo simplemente de no funcionar.

Las Cuatro Actividades Básicas

Codificar: Es la única actividad de la que no podremos prescindir. Sin
código fuente no hay programa, aunque hay gente que cuenta que
existe software en producción del que se perdió el código fuente. Por
tanto necesitamos codificar y plasmar nuestras ideas a través del
código. En una programación en PX en pareja el código expresa tu
interpretación del problema, así podemos utilizarlo para comunicar,
para hacer mías tus ideas, y por tanto para aprender y mejorar.

Hacer pruebas: Las características del software que no pueden ser

demostradas mediante pruebas simplemente no existen. Las pruebas
me dan la oportunidad de saber si lo que implementé es lo que en
realidad yo pensaba que había implementado. Las pruebas nos
indican que nuestro trabajo funciona, cuando no podemos pensar en
ninguna prueba que pudiese originar un fallo en nuestro sistema
entonces has acabado por completo.

No debemos de escribir tan solo una prueba ver que funciona y salir
corriendo, debemos de pensar en todas las posibles pruebas para
nuestro código, con el tiempo llegaras a conclusiones sobre las
pruebas y podrás pensar que si dos de tus pruebas ya funcionan la

2018
Ingeniería de Software I

tercera prueba no será necesaria escribirla, sin caer en demasiada

confianza. Programar y probar es más rápido que sólo programar.
Puedes ganar media hora de productividad sin hacer pruebas, pero
perderás mucho tiempo en la Depuración.

Tendrás menos errores, tendrás que volver menos veces sobre el

código, te costará menos localizar los errores, perderás menos tiempo
escuchado como tus clientes te dicen que no funciona. Las pruebas
deben de ser sensatas y valientes. No podemos hacer pruebecillas
que no testen a fondo el sistema, esos agujeros que vamos dejando
nos esperan para cuando pasemos de nuevo por allí y volveremos a
caer dentro.

Escuchar: Los programadores no lo conocemos todo, y sobre todo

muchas cosas que las personas de negocios piensan que son
interesantes. Si ellos pudieran programarse su propio software ¿para
qué nos querrían?. Si vamos a hacer pruebas tenemos que preguntar
si lo obtenido es lo deseado, y tenemos que preguntar a quién
necesita la información.

Tenemos que escuchar a nuestros clientes cuales son los problemas

de su negocio, debemos de tener una escucha activa explicando lo
que es fácil y difícil de obtener, y la Realimentación entre ambos nos
ayudan a todos a entender los problemas.

Diseñar: El Diseño crea una estructura que organiza la lógica del

sistema, un buen diseño permite que el sistema crezca con cambios
en un solo lugar. Los diseños deben de ser sencillos, si alguna parte
del sistema es de desarrollo complejo, divídela en varias. Si hay fallos
en el diseño o malos diseños, estos deben de ser corregidos cuanto
antes.

Tenemos que codificar porque sin código no hay programas, tenemos

que hacer pruebas porque sin pruebas no sabemos si hemos acabado
de codificar, tenemos que escuchar, porque si no escuchamos no
sabemos que codificar ni probar, y tenemos que diseñar para poder
Codificar, probar y escuchar indefinidamente.

2018
Ingeniería de Software I

Características Fundamentales las Características

Fundamentales del Método son:
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras
otras.

Pruebas unitarias continuas, frecuentemente repetidas y

automatizadas, incluyendo [[Pruebas de Regresión. Se aconseja
escribir el código de la prueba antes de la codificación.

Véase, por ejemplo, las herramientas de prueba JUnit orientada a

Java, DUnit orientada a Delphi y NUnit para la plataforma.NET. Estas
dos últimas inspiradas en JUnit.

Programación en parejas: se recomienda que las tareas de

desarrollo se lleven a cabo por dos personas en un mismo puesto. Se
supone que la mayor calidad del código escrito de esta manera -el
código es revisado y discutido mientras se escribe- es más importante
que la posible pérdida de productividad inmediata.

Frecuente integración del equipo de programación con el cliente o

usuario. Se recomienda que un representante del cliente trabaje junto
al equipo de desarrollo.

Corrección de todos los errores antes de añadir nueva funcionalidad.

Hacer entregas frecuentes.

Refactorización del código, es decir, reescribir ciertas partes del

código para aumentar su legibilidad y mantenibilidad pero sin modificar
su comportamiento. Las pruebas han de garantizar que en la
refactorización no se ha introducido ningún fallo.

Propiedad del código compartida: en vez de dividir la

responsabilidad en el desarrollo de cada módulo en grupos de trabajo
distintos, este método promueve el que todo el personal pueda
corregir y extender cualquier parte del proyecto.

2018
Ingeniería de Software I

Las frecuentes pruebas de regresión garantizan que los posibles

errores serán detectados.

Simplicidad en el código: es la mejor manera de que las cosas

funcionen. Cuando todo funcione se podrá añadir funcionalidad si es
necesario. La programación extrema apuesta que es más sencillo
hacer algo simple y tener un poco de trabajo extra para cambiarlo si se
requiere, que realizar algo complicado y quizás nunca utilizarlo.

La Simplicidad y la Comunicación son extraordinariamente

complementarias. Con más comunicación resulta más fácil identificar
qué se debe y qué no se debe hacer. Cuanto más simple es el
sistema, menos tendrá que comunicar sobre éste, lo que lleva a una
comunicación más completa, especialmente si se puede reducir el
equipo de programadores.

2018
Ingeniería de Software I

Bibliografía

Extremeprogramming.org. (2018). Extreme Programming: A Gentle

Introduction.. [online] Available at:
http://www.extremeprogramming.org[Accessed 6 Feb. 2018].

Anon, (2018). [online] Available at:

http://tech.groups.yahoo.com/group/xpspanish/[Accessed 6 Feb.
2018].

Chuidiang.com. (2018). Programación extrema. [online] Available at:

http://www.chuidiang.com/ood/metodologia/extrema.php[Accessed 6
Feb. 2018].

2018