FACULTAD DE INGENIERA

ESCUELA PROFESIONAL DE INGENIERA DE SISTEMAS

PROGRAMACION EXTREMA

Nombre del Estudiante

ANDRES ELEODORO SOSA GARCIA

Asignatura

ADMINISTRACION DE PROYECTOS TICS

Docente

ING. NILTON ZAMBRANO SALINAS

2015

DEDICATORIA

Al creador de todas las cosas, el que me ha dado fortaleza para

continuar cuando a punto de caer he estado; por ello, con toda la
humildad que de mi corazn puede emanar, dedico primeramente
mi trabajo a Dios.
A mi esposa Janett y a mi hijo Sebastian, por el poyo que me
brindaron con su paciencia en los momentos que no podia estar
con ellos y comprender que mi sacrificio es por ellos.

AGRADECIMIENTOS

Quiero agradecer a mi casa de estudios y al Ing. Nilton Walter

Zambrano Salinas por incentivarnos en uestra formacion
profesional y en la busqueda del tema de investigacion que nos
permite fortalecer nuestros conocimientos para aplicarlos en un
futuro en nuestros retos laborales.

EPIGRAFE

Sigamos hambrientos, sigamos alocados

Steve Jobs

SUMARIO
I.

DEFINICIN ........................................................................................................... 7

II.

VALORES ................................................................................................................ 8

III.

PRINCIPIOS ............................................................................................................ 8

IV.

PROCESO DE DESARROLLO .............................................................................. 8

1.
2.
3.
4.
5.
6.

V.

Exploracin. ......................................................................................................... 8
Planificacin ........................................................................................................ 8
Iteraciones ............................................................................................................ 9
Produccin ......................................................................................................... 10
Mantenimiento ................................................................................................... 10
Muerte del Proyecto ........................................................................................... 10

PRCTICAS ESPECFICAS DE LA PROGRAMACIN EXTREMA .............. 10

1) El Juego de la Planificacin ............................................................................... 11
2) Pequeas Liberaciones ....................................................................................... 11
3) Metfora ............................................................................................................. 11
4) Diseo Simple .................................................................................................... 11
5) Pruebas Automatizadas ...................................................................................... 12
6) Refactoring ......................................................................................................... 12
7) Programacin por Pares ..................................................................................... 12
8) Propiedad Colectiva ........................................................................................... 13
9) Estndares de Cdigo ......................................................................................... 13
10) Cliente Siempre Disponible ............................................................................... 13

VI.

COMPARACIN CON RUP-XP .......................................................................... 14

VII.

COMPARACIN SCRUM XP ........................................................................... 16

BIBLIOGRAFA ..................................................................................................................... 18

INTRODUCCION
En el desarrollo de software de nada sirven buenas notaciones y herramientas si no se proveen
directivas para su aplicacin. As, esta dcada ha comenzado con un creciente inters en
metodologas de desarrollo. Hasta hace poco el proceso de desarrollo llevaba asociada un
marcado nfasis en el control del proceso mediante una rigurosa definicin de roles,
actividades y artefactos, incluyendo modelado y documentacin detallada.
Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo
y necesario en proyectos de gran tamao (respecto a tiempo y recursos), donde por lo general
se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el
ms adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy
cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero
manteniendo una alta calidad.
Ante las dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo
y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la
ingeniera del software, asumiendo el riesgo que ello conlleva. En este escenario, las
metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico.
Por estar especialmente orientadas para proyectos pequeos, las metodologas giles
constituyen una solucin a medida para ese entorno, aportando una elevada simplificacin que
a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del producto.
La curiosidad que siente la mayor parte de ingenieros de software, profesores, e incluso
alumnos, sobre las metodologas giles hace prever una fuerte proyeccin industrial. Por un
lado, para muchos equipos de desarrollo el uso de metodologas tradicionales les resulta muy
lejano a su forma de trabajo actual considerando las dificultades de su introduccin e
inversin asociada en formacin y herramientas. Por otro, las caractersticas de los proyectos
para los cuales las metodologas giles han sido especialmente pensadas se ajustan a un
amplio rango de proyectos industriales de desarrollo de software; aquellos en los cuales los
equipos de desarrollo son pequeos, con plazos reducidos, requisitos voltiles, y/o basados en
nuevas tecnologas.

I.

DEFINICIN

La programacin extrema es una metodologa reciente (alrededor de 5 aos) utilizada

en el desarrollo de software. La filosofa de X.P es satisfacer al completo las
necesidades del cliente, por eso, lo integra como una parte ms del equipo de
desarrollo.

La programacin extrema, es una de las llamadas Metodologas giles de desarrollo

de software ms exitosas de los tiempos actuales. Es un conjunto de normas y
recomendaciones encaminadas a producir software de calidad, fue diseada teniendo
en cuenta los problemas que existan con las metodologas tradicionales de
programacin en cuanto a tiempos de entrega y satisfaccin del cliente. Su objetivo
principal es buscar la satisfaccin del mismo tratando de mantener durante todo el
tiempo su confianza en el producto.

Consta de un conjunto de prcticas que a lo largo de los aos han demostrado ser las
mejores prcticas de desarrollo de software, llevadas al extremo y fundamentadas en
un conjunto de valores.

La programacin extrema hace especial nfasis en equipos de desarrollo pequeos

(diez o doce personas como mximo) que, naturalmente, se podrn ir incrementando a
medida que sea necesario, pero no antes, o los resultados generalmente sern
contrarios a los esperados.

X.P fue inicialmente creada para el desarrollo de aplicaciones dnde el cliente no tiene
una concepcin clara de las funcionalidades que tendr la aplicacin que se
desarrollar. Este desconocimiento podra provocar un cambio constante en los
requisitos que debe cumplir la aplicacin por lo que es necesaria una metodologa gil
como X.P que se adapta a las necesidades del cliente y dnde la aplicacin se va
revisando constantemente.

X.P est diseada para el desarrollo de aplicaciones que requieren un grupo de

programadores pequeo, dnde la comunicacin sea ms factible que en grupos de
desarrollo grandes. La comunicacin es un punto importante y debe realizarse entre
los programadores, los jefes de proyecto y los clientes.

II. VALORES
La programacin extrema est fundamentada en una serie de valores y principios que la
guan. Los valores representan aquellos aspectos que los autores de XP han considerados
como fundamentales para garantizar el xito de un proyecto de desarrollo de software. Los
cuatro valores son:
1.
2.
3.
4.

Comunicacin
Retroalimentacin
Simplicidad
Coraje

III. PRINCIPIOS
Los principios fundamentales de la programacin extrema se apoyan en los valores antes
mencionados y tambin son cuatro. Se busca:
1.
2.
3.
4.

Retroalimentacin Rpida
Cambio Incremental
Trabajo de Calidad
Asumir Simplicidad

IV. PROCESO DE DESARROLLO

El proceso de desarrollo extremo consta de cinco fases: Exploracin, Planificacin,
Produccin, Mantenimiento y Muerte.
1. Exploracin
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son
de inters para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnologas y prcticas que se
utilizarn en el proyecto.
Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del
sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas
a pocos meses, dependiendo del tamao y familiaridad que tengan los
programadores con la tecnologa.
2. Planificacin
En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimacin del esfuerzo
8

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
debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das.
Las estimaciones de esfuerzo asociado a la implementacin de las historias la
establecen los programadores utilizando como medida el punto. Un punto,
equivale a una semana ideal de programacin. 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 iteracin, basndose
principalmente en la suma de puntos correspondientes a las historias de usuario
que fueron terminadas en la ltima iteracin.
La planificacin se puede realizar basndose en el tiempo o el alcance. La
velocidad del proyecto es utilizada para establecer cuntas historias se pueden
implementar antes de una fecha determinada o cunto tiempo tomar implementar
un conjunto de historias. Al planificar por tiempo, se multiplica el nmero de
iteraciones por la velocidad del proyecto, determinndose cuntos puntos se
pueden completar. Al planificar segn alcance del sistema, se divide la suma de
puntos de las historias de usuario seleccionadas entre la velocidad del proyecto,
obteniendo el nmero de iteraciones necesarias para su implementacin.
3. Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan
de Entrega est compuesto por iteraciones de no ms de tres semanas. En la
primera iteracin 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 creacin de esta arquitectura, sin embargo, esto no siempre
es posible ya que es el cliente quien decide qu historias se implementarn en cada
iteracin (para maximizar el valor de negocio). Al final de la ltima iteracin el
sistema estar listo para entrar en produccin.
Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la
Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas
de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la
iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de
programacin, cada una de ellas es asignada a un programador como responsable,

pero llevadas a cabo por parejas de programadores.

4. Produccin
La fase de produccin 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 inclusin de nuevas caractersticas a la versin
actual, debido a cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana.
Las ideas que han sido propuestas y las sugerencias son documentadas para su
posterior implementacin (por ejemplo, durante la fase de mantenimiento).
5. Mantenimiento
Mientras la primera versin se encuentra en produccin, 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 despus de la puesta del sistema
en produccin. La fase de mantenimiento puede requerir nuevo personal dentro del
equipo y cambios en su estructura.
6. Muerte Del Proyecto
Es cuando el cliente no tiene ms 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 documentacin final del
sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto
tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente
o cuando no hay presupuesto para mantenerlo.
V. PRCTICAS ESPECFICAS DE LA PROGRAMACIN EXTREMA
La programacin extrema es una coleccin de ideas y prcticas deducidas de las
metodologas ya existentes.
Las prcticas, que a continuacin se presentan, se soportan entre s, esto es, las
debilidades de una son cubiertas por las fortalezas de otras:
10

1) El Juego de la Planificacin
Es un espacio frecuente de comunicacin entre el cliente y los programadores. El
equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin
de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las
entregas y de cada iteracin. Esta prctica se puede ilustrar como un juego, donde
existen dos tipos de jugadores: Cliente y Programador.
El cliente establece la prioridad de cada historia de usuario, de acuerdo con el valor
que aporta para el negocio. Los programadores estiman el esfuerzo asociado a cada
historia de usuario. Se ordenan las historias de usuario segn prioridad y esfuerzo, y se
define el contenido de la entrega y/o iteracin, apostando por enfrentar lo de ms valor
y riesgo cuanto antes.
Este juego se realiza durante la planificacin de la entrega, en la planificacin de cada
iteracin y cuando sea necesario reconducir el proyecto.
2) Pequeas Liberaciones
La idea es producir rpidamente versiones del sistema que sean operativas, aunque
obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero s
que constituyan un resultado de valor para el negocio. Una entrega no debera tardar
ms 3 meses.
3) Metfora
En XP no se enfatiza la definicin temprana de una arquitectura estable para el
sistema. Dicha arquitectura se asume evolutiva y los posibles inconvenientes que se
generaran por no contar con ella explcitamente en el comienzo del proyecto se
solventan con la existencia de una metfora. El sistema es definido mediante una
metfora o un conjunto de metforas compartidas por el cliente y el equipo de
desarrollo. Una metfora es una historia compartida que describe cmo debera
funcionar el sistema. Este conjunto de nombres ayuda a la nomenclatura de clases y
mtodos del sistema.
4) Diseo Simple
Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un
11

momento determinado del proyecto. La complejidad innecesaria y el cdigo extra debe

ser removido inmediatamente. Kent Beck dice que en cualquier momento el diseo
adecuado para el software es aquel que: supera con xito todas las pruebas, no tiene
lgica duplicada, refleja claramente la intencin de implementacin de los
programadores y tiene el menor nmero posible de clases y mtodos.
5) Pruebas Automatizadas
La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas unitarias
son establecidas antes de escribir el cdigo y son ejecutadas constantemente ante cada
modificacin del sistema. Los clientes escriben las pruebas funcionales para cada
historia de usuario que deba validarse. En este contexto de desarrollo evolutivo y de
nfasis en pruebas constantes, la automatizacin para apoyar esta actividad es crucial.
6) Refactoring
La refactorizacin es una actividad constante de reestructuracin del cdigo con el
objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y
hacerlo ms flexible para facilitar los posteriores cambios. La refactorizacin mejora
la estructura interna del cdigo sin alterar su comportamiento externo. Robert Martin
seala que el diseo del sistema de software es una cosa viviente. No se puede
imponer todo en un inicio, pero en el transcurso del tiempo este diseo evoluciona
conforme cambia la funcionalidad del sistema. Para mantener un diseo apropiado, es
necesario realizar actividades de cuidado continuo durante el ciclo de vida del
proyecto. De hecho, este cuidado continuo sobre el diseo es incluso ms importante
que el diseo inicial. Un concepto pobre al inicio puede ser corregido con esta
actividad continua, pero sin ella, un buen diseo inicial se degradar.
7) Programacin por Pares
Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores.
Segn Cockburn y Williams en un estudio realizado para identificar los costos y
beneficios de la programacin en parejas, las principales ventajas de introducir este
estilo de programacin son: muchos errores son detectados conforme son introducidos
en el cdigo (inspecciones de cdigo continuas), por consiguiente la tasa de errores del
producto final es ms baja, los diseos son mejores y el tamao del cdigo menor
12

(continua discusin de ideas de los programadores), los problemas de programacin se

resuelven ms rpido, se posibilita la transferencia de conocimientos de programacin
entre los miembros del equipo, varias personas entienden las diferentes partes sistema,
los programadores conversan mejorando as el flujo de informacin y la dinmica del
equipo, y finalmente, los programadores disfrutan ms su trabajo. Dichos beneficios se
consiguen despus de varios meses de practicar la programacin en parejas. En los
estudios realizados por Cockburn y Williams este lapso de tiempo vara de 3 a 4
meses.
8) Propiedad Colectiva
Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema
puede llegar a ser integrado y construido varias veces en un mismo da. Todas las
pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo cdigo sea
incorporado definitivamente. La integracin continua a menudo reduce la
fragmentacin de los esfuerzos de los desarrolladores por falta de comunicacin sobre
lo que puede ser reutilizado o compartido. Martin Fowler en afirma que el desarrollo
de un proceso disciplinado y automatizado es esencial para un proyecto controlado, el
equipo de desarrollo est ms preparado para modificar el cdigo cuando sea
necesario, debido a la confianza en la identificacin y correccin de los errores de
integracin.
9) Estndares de Cdigo
XP enfatiza la comunicacin de los programadores a travs del cdigo, con lo cual es
indispensable que se sigan ciertos estndares de programacin (del equipo, de la
organizacin u otros estndares reconocidos para los lenguajes de programacin
utilizados). Los estndares de programacin mantienen el cdigo legible para los
miembros del equipo, facilitando los cambios.
10) Cliente Siempre Disponible
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran
parte del xito del proyecto XP se debe a que es el cliente quien conduce
constantemente el trabajo hacia lo que aportar mayor valor de negocio y los
programadores pueden resolver de manera inmediata cualquier duda asociada. La
13

comunicacin oral es ms efectiva que la escrita, ya que esta ltima toma mucho
tiempo en generarse y puede tener ms riesgo de ser mal interpretada. En Jeffries
indica que se debe pagar un precio por perder la oportunidad de un cliente con alta
disponibilidad. Algunas recomendaciones propuestas para dicha situacin son las
siguientes: intentar conseguir un representante que pueda estar siempre disponible y
que acte como interlocutor del cliente, contar con el cliente al menos en las reuniones
de planificacin, establecer visitas frecuentes de los programadores al cliente para
validar el sistema, anticiparse a los problemas asociados estableciendo llamadas
telefnicas frecuentes y conferencias, reforzando el compromiso.
VI. COMPARACIN CON RUP-XP
METODOLOGIA RATIONAL

METODOLOGIA EXTREME

UNIFIED PROCESS(RUP)
PROGRAMMING(XP)
RUP Forma disciplinada de asignar tareas XP Nace en busca de simplificar el desarrollo
y responsabilidades en una empresa de del software y que se lograra reducir el costo
desarrollo (quin hace qu, cundo y del proyecto.
cmo).
Mtodo Pesado

Mtodo Ligero:
No produce demasiado overhead sobre las
actividades de desarrollo, y no impide el
avance de nuestro proyectos

Costo de cambio:

Costo Cambio:

Un cambio en las etapas de vida del Reduce el costo del cambio en las etapas de
sistema incrementara notablemente el vida del sistema.
costo.
Requiere

un

grupo

grande

de Se

requiere

un

grupo

pequeo

de
14

programadores para trabajar con esta programadores

metodologa.

para

trabajar

con

esta

metodologa entre 2-15 personas y estas irn

RUP es un macro del proyecto que aumentando conforme sea necesario.

describe una clase de los procesos que son Combina las que han demostrado ser las
iterativos e incrementales.

mejores prcticas de desarrollo de software, y

las lleva al extremo.

RUP define un manojo entero de las El desarrollo de software es riesgoso y difcil

actividades y de los artefactos que usted de controlar.
necesita elegir para sus propios procesos Se redisear todo el tiempo (refactoring),
individuales.

dejando el cdigo siempre en el estado ms

simple posible.

Los procesos de RUP estiman tareas y Se harn pruebas todo el tiempo, no slo de
horario del plan midiendo la velocidad de cada nueva clase (pruebas unitarias) sino que
iteraciones concerniente a sus estimaciones tambin los clientes comprobarn que el
originales. Las iteraciones tempranas de proyecto va satisfaciendo los requisitos
proyectos conducidos RUP se enfocan (pruebas funcionales).
fuertemente

sobre

arquitectura

del Las pruebas de integracin se efectuarn

software; la puesta en prctica rpida de siempre, antes de aadir cualquier existente

caractersticas se retrasa hasta que se ha (integracin continua), utilizando frameworks
identificado

se

ha

probado

una de testing, como el xUnit.

arquitectura firme.

Las iteraciones sern radicalmente ms cortas

de lo que es usual en otros mtodos, esto

RUP proporciona muchas ventajas sobre permite beneficiarse de la retroalimentacin

XP le da nfasis en los requisitos y el tan a menudo como sea posible.
diseo.

XP define 4 variables para el proyecto de

software:

RUP proporciona muchas ventajas sobre

XP le da nfasis en los requisitos y el
diseo.

Coste
Tiempo
Calidad
Alcance

La ventaja principal de RUP es que se basa

todo en las mejores prcticas que se han XP tiene como valores lo siguiente:
intentado y se han probado en el campo.
RUP se divide en cuatro fases:

Comunicacin
Simplicidad
Realimentacin
Coraje
15

 Inicio(Define

el

alcance

proyecto)
Elaboracin(definicin,

valores que permitirn hacer la vida ms fcil

anlisis, del grupo, la gerencia y los clientes. Sirve

diseo)
Construccin(implementacin)
Transicin(fin del proyecto
puesta en produccin)
Cada fase concluye

del Este es un conjunto mnimo y consiste de

con

HITO(T. Decisiones)

tanto a los fines como a los comerciales.

y XP derivada una docena de Principios
Bsicos:
un Realimentacin rpida, Asumir la simplicidad,
El Cambio, Incremental, Adherirse (Abrazar)
al cambio, Trabajo de Alta calidad.

VII COMPARACION SCRUM XP

SCRUM

XP

Es una metodologa de desarrollo gil basada Es una metodologa de desarrollo que est
en la administracin del proyecto.

ms centrada en la programacin o creacin

del producto.

Cada miembro de del equipo trabaja de forma Los miembro del equipo programan en
individual.

parejas.

Las iteraciones de entrega son de 1 a 4 Las iteraciones de entrega son de 1 a 3

semanas.

semanas

Al finalizar un Sprint, las tareas del Sprint Las tareas se van terminando aunque son
Backlog que se hayan realizado y que el susceptibles de ser modificadas durante el
Product Owner (propietario del producto) transcurso de proyecto, incluso, despus de
haya mostrado su conformidad ya no se que funcionen correctamente.
16

retoca. Si funciona y est bin, se aparta y a

otra cosa.
Trata de seguir el orden de prioridades que El equipo de desarrollo sigue estrictamente el
marca el Product Owner en el Sprint Backlog orden de prioridad de las tareas definido por
pero puede cambiarlo si es mejor para el el cliente.
desarrollo de la tareas.

17

BIBLIOGRAFIA

http://www.fcad.uner.edu.ar/jai/6JAI/XP_6JAI.pdf

http://programacion-extrema.wikispaces.com/5.+Ciclo+de+vida+y+fases

http://www.willydev.net/descargas/prev/ExplicaXP.pdf

http://www.ecured.cu/index.php/Programaci%C3%B3n_Extrema_(XP)

http://www2.uacj.mx/IIT/CULCYT/mayo-agosto2006/8ArtProg.pdf

http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf

18