Repblica Bolivariana De Venezuela

Universidad Nororiental Privada

Gran Mariscal De Ayacucho
Ncleo Barcelona - Facultad De Ingeniera

Programacin
Extrema

Integrantes:

Barrios, Mara C.I. 26.217.167

Espinoza, Christian C.I: 24.655.689
Hernndez, Kevin C.I. 25.860.640
Rodrguez, Vctor C.I. 21.612.811
 Barcelona, abril de 2017

Metodologas de desarrollo gil

Son mtodos de desarrollo de software en los que las necesidades y soluciones

evolucionan a travs de una colaboracin estrecha entre equipos
multidisciplinarios. Se caracterizan por enfatizar la comunicacin frente a la
documentacin, por el desarrollo evolutivo y por su flexibilidad.

Estas metodologas surgen a principios del 2001 en respuesta a los modelos de

proceso clsicos ya existentes. La aparicin de procesos giles se debe al hecho
de haber encontrado estos supuestos clave en desarrollos precedentes:

Es difcil predecir qu requisitos persistirn y cuales cambiarn, as como

las prioridades del cliente.
El diseo y el desarrollo de software estn intercalados. Por ello se
realizarn conjuntamente, probando el diseo a medida que se crea, pues
es complicado predecir cunto diseo es necesario antes de llegar a
implementarlo.
El anlisis, el diseo y la implementacin no son predecibles desde el punto
de vista de la planificacin.

Comparacin de metodologas de desarrollo gil y metodologas de

desarrollo tradicional

Metodologa gil Metodologa tradicional

Pocos artefactos. El modelado es Ms artefactos. El modelo es esencial,
prescindible, modelos desechables. mantenimiento de modelos.
Pocos roles, ms genricos y flexibles. Ms roles, ms especficos.
No existe un contrato tradicional, debe Existe un contrato prefijado.
ser bastante flexible.
El cliente es parte del equipo de El cliente interacta con el equipo de
desarrollo (in-situ) desarrollo mediante reuniones
Orientada a proyectos pequeos. Corta
Aplicables a proyectos de cualquier
duracin, equipos pequeos y
tamao, pero suelen ser especialmente
trabajando en el mismo sitio. efectivas/usadas en proyectos grandes
y con equipos posiblemente dispersos.
La arquitectura se va definiendo y Se promueve que la arquitectura se
mejorando a lo largo del proyecto. defina tempranamente en el proyecto.
nfasis en los aspectos humanos: el nfasis en la definicin del proceso:
individuo y el trabajo en equipo. roles, actividades y artefactos.
Se esperan cambios durante el Se espera que no ocurran cambios de
proyecto. gran impacto durante el proyecto.

Programacin extrema

Es una metodologa de desarrollo de la ingeniera de software formulada por Kent

Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el ms destacado de los procesos giles de
desarrollo de software. Al igual que stos, la programacin extrema se diferencia
de las metodologas tradicionales principalmente en que pone ms nfasis en la
adaptabilidad que en la previsibilidad. Los defensores de la XP 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
aproximacin mejor y ms realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en
los requisitos.

Se puede considerar la programacin extrema como la adopcin de las mejores

metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software.

sta es un arma poderosa ya que las metodologas tradicionales suelen seguir la

curva de forma que el coste de modificacin del software incrementa
exponencialmente a medida que se invierte ms tiempo en todas las fases del
desarrollo.

Por ejemplo, es ms efectivo aadir opciones en la fase de requerimientos que

durante la implementacin, cundo cuesta significativamente ms, pero
supongamos que el desarrollo de nuestro proyecto ha seguido una curva dnde
los costos de modificacin crecen ms lentamente y se nivelan ms rpidamente.
Si tuviramos la libertad de aadir, eliminar, modificar las opciones siempre que se
quiera, habra una razn para intentar predeterminar todo el conjunto de opciones
dentro de las fases inciales del proyecto.

Objetivos.

Establecer las mejores prcticas de Ingeniera de Software en los desarrollo

de proyectos.
Mejorar la productividad de los proyectos.
Garantizar la Calidad del Software desarrollando, haciendo que este supere
las expectativas del cliente.
 Caractersticas xp

Metodologa basada en prueba y error

Fundamentada en Valores y Prcticas
Expresada en forma de 12 PrcticasConjunto completoSe soportan unas
a otrasSon conocidas desde hace tiempo. La novedad es juntarlas

Valores xp

Simplicidad XP: propone el principio de hacer la cosa ms simple que

pueda funcionar, en relacin al proceso y la codificacin. Es mejor hacer
hoy algo simple, que hacerlo complicado y probablemente nunca usarlo
maana.
Comunicacin: Algunos problemas en los proyectos tienen origen en que
alguien no dijo algo importante en algn momento. XP hace casi imposible
la falta de comunicacin.
Realimentacin:Retroalimentacin concreta y frecuente del cliente, del
equipo y de los usuarios finales da una mayor oportunidad de dirigir el
esfuerzo eficientemente.
Coraje: El coraje (valor) existe en el contexto de los otros 3 valores.(si
funcionamejralo)

El estilo xp

Est orientada hacia quien produce y usa el software

Reduce el costo del cambio en todas las etapas del ciclo de vida del
sistema.
Combina las que han demostrado ser las mejores prcticas para desarrollar
software, y las lleva al extremo.

Roles

Programador: Escribe las pruebas unitarias y produce el cdigo del

sistema. Es la esencia del equipo.
Cliente: Escribe las historias de usuario y las pruebas funcionales para
validar su implementacin. Asigna la prioridad a las historias de usuario y
decide cules se implementan en cada iteracin centrndose en aportar el
mayor valor de negocio.
Tester: Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas
regularmente, difunde los resultados en el equipo y es responsable de las
herramientas de soporte para pruebas.
Tracker: Es el encargado de seguimiento. Proporciona realimentacin al
equipo. Debe verificar el grado de acierto entre las estimaciones realizadas
 y el tiempo real dedicado, comunicando los resultados para mejorar futuras
estimaciones.
Entrenador (coach): Responsable del proceso global. Gua a los miembros
del equipo para seguir el proceso correctamente.
Consultor: Es un miembro externo del equipo con un conocimiento
especfico en algn tema necesario para el proyecto. Ayuda al equipo a
resolver un problema especfico. Adems este tiene que investigar segn
los requerimientos.
Gestor (Big boss): Es el dueo de la tienda y el vnculo entre clientes y
programadores. Su labor esencial es la coordinacin.

Fases de la programacin extrema

1 Fase: Planificacin del proyecto.

Historias de usuario:

El primer paso de cualquier proyecto que siga la metodologa X.P es definir las
historias de usuario con el cliente. Las historias de usuario tienen la misma
finalidad que los casos de uso pero con algunas diferencias: Constan de 3 o 4
lneas escritas por el cliente en un lenguaje no tcnico sin hacer mucho hincapi
en los detalles; no se debe hablar ni de posibles algoritmos para su
implementacin ni de diseos de base de datos adecuados, etc. Son usadas para
estimar tiempos de desarrollo de la parte de la aplicacin que describen. Tambin
se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que
especifica la historia de usuario. Cuando llega la hora de implementar una historia
de usuario, el cliente y los desarrolladores se renen para concretar y detallar lo
que tiene que hacer dicha historia. El tiempo de desarrollo ideal para una historia
de usuario es entre 1 y 3 semanas.

Planificacin de publicaciones:

Despus de tener ya definidas las historias de usuario es necesario crear un plan

de publicaciones. Un plan de publicacin es una planificacin donde los
desarrolladores y clientes establecen los tiempos de implementacin ideales de
las historias de usuario, la prioridad con la que sern implementadas y las historias
que sern implementadas en cada versin del programa. Despus de un "plan de
publicacin" tienen que estar claros estos cuatro factores:
 Los objetivos que se deben cumplir (que son principalmente las historias
que se deben desarrollar en cada versin).
El tiempo que tardarn en desarrollarse y publicarse las versiones del
programa.
El nmero de personas que trabajarn en el desarrollo.
Cmo se evaluar la calidad del trabajo realizado.

Iteraciones:

Todo proyecto que siga la metodologa X.P. se ha de dividir en iteraciones de

aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los
clientes deben seleccionar las historias de usuario definidas en la "planificacin de
publicaciones" que sern implementadas. Tambin se seleccionan las historias de
usuario que no pasaron el test de aceptacin que se realiz al terminar la iteracin
anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 das de
duracin que se asignarn a los programadores.

Velocidad del proyecto:

La velocidad del proyecto es una medida que representa la rapidez con la que se
desarrolla el proyecto; estimarla es muy sencillo, basta con contar el nmero de
historias de usuario que se pueden implementar en una iteracin; de esta forma,
se sabr el cupo de historias que se pueden desarrollar en las distintas
iteraciones. Usando la velocidad del proyecto se controla que todas las tareas se
puedan desarrollar en el tiempo del que dispone la iteracin.

Programacin en pareja:

La metodologa X.P. aconseja la programacin en parejas, pues incrementa la

productividad y la calidad del software desarrollado. El trabajo en pareja involucra
a dos programadores trabajando en el mismo equipo; mientras uno codifica
haciendo hincapi en la calidad de la funcin o mtodo que est implementando,
el otro analiza si ese mtodo o funcin es adecuado y est bien diseado.

Reuniones diarias:

Es necesario que los desarrolladores se renan diariamente y expongan sus

problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser
fluidas y todo el mundo tiene que tener voz y voto.

2 Fase: Diseo.

Diseos simples: La metodologa X.P sugiere que hay que conseguir diseos
simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible
para conseguir un diseo fcilmente entendible e implementable que a la larga
costar menos tiempo y esfuerzo desarrollar.

Glosarios de trminos: Usar glosarios de trminos y una correcta especificacin

de los nombres de mtodos y clases ayudar a comprender el diseo y facilitar
sus posteriores ampliaciones y la reutilizacin del cdigo.

Riesgos: Si surgen problemas potenciales durante el diseo, X.P sugiere utilizar

una pareja de desarrolladores para que investiguen y reduzcan al mximo el
riesgo que supone ese problema.

Funcionalidad extra: Nunca se debe aadir funcionalidad extra al programa

aunque se piense que en un futuro ser utilizada. Slo el 10% de la misma es
utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio
de tiempo y recursos.

Refactorizar: Es mejorar y modificar la estructura y codificacin de cdigos ya

creados sin alterar su funcionalidad. Supone revisar de nuevo estos cdigos para
procurar optimizar su funcionamiento.

Tarjetas C.R.C. (Class, Responsabilities and Collaboration): Su uso permite al

programador centrarse y apreciar el desarrollo orientado a objetos olvidndose de
los malos hbitos de la programacin procedural clsica.

Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se

puede escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se
pueden escribir las responsabilidades u objetivos que debe cumplir el objeto y a la
derecha, las clases que colaboran con cada responsabilidad.

3 Fase: Codificacin.

La codificacin debe hacerse ateniendo a estndares de codificacin ya creados.

Programar bajo estndares mantiene el cdigo consistente y facilita su
comprensin y escalabilidad.

Crear test que prueben el funcionamiento de los distintos cdigos implementados

ayudar a desarrollar dicho cdigo. Crear estos test antes ayuda a saber qu es
exactamente lo que tiene que hacer el cdigo a implementar y se sabr que una
vez implementado pasar dichos test sin problemas ya que dicho cdigo ha sido
diseado para ese fin.

X.P sugiere un modelo de trabajo usando repositorios de cdigo dnde las parejas
de programadores publican cada pocas horas sus cdigos implementados y
corregidos junto a los test que deben pasar. De esta forma el resto de
programadores que necesiten cdigos ajenos trabajarn siempre con las ltimas
versiones. Para mantener un cdigo consistente, publicar un cdigo en un
repositorio es una accin exclusiva para cada pareja de programadores.

X.P tambin propone un modelo de desarrollo colectivo en el que todos los

programadores estn implicados en todas las tareas; cualquiera puede modificar o
ampliar una clase o mtodo de otro programador si es necesario y subirla al
repositorio de cdigo. El permitir al resto de los programadores modificar cdigos
que no son suyos no supone ningn riesgo ya que para que un cdigo pueda ser
publicado en el repositorio tiene que pasar los test de funcionamiento definidos
para el mismo.

La optimizacin del cdigo siempre se debe dejar para el final. Hay que hacer que
funcione y que sea correcto, ms tarde se puede optimizar.

4 Fase: Pruebas.

Uno de los pilares de la metodologa X.P es el uso de test para comprobar el

funcionamiento de los cdigos que se vayan implementando.

El uso de los test en X.P es el siguiente:

Se deben crear las aplicaciones que realizarn los test con un entorno de
desarrollo especfico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los
mtodos ms triviales.
Se deben crear los test que pasarn los cdigos antes de implementarlos.
Un punto importante es crear test que no tengan ninguna dependencia del
cdigo que en un futuro evaluar. Hay que crear los test abstrayndose del
futuro cdigo, de esta forma aseguraremos la independencia del test
respecto al cdigo que evala.
Los distintos test se deben subir al repositorio de cdigo acompaados del
cdigo que verifican. Ningn cdigo puede ser publicado en el repositorio
sin que haya pasado su test de funcionamiento, de esta forma, se asegura
el uso colectivo del cdigo.
El uso de los test es adecuado para observar la refactorizacin. Los test
permiten verificar que un cambio en la estructura de un cdigo no tiene por
qu cambiar su funcionamiento.

Test de aceptacin.

Los test mencionados anteriormente sirven para evaluar las distintas tareas en las
que ha sido dividida una historia de usuario. Para asegurar el funcionamiento final
de una determinada historia de usuario se deben crear "Test de aceptacin"; estos
test son creados y usados por los clientes para comprobar que las distintas
historias de usuario cumplen su cometido.

Ventajas y desventajas de extreme programming

Ventajas:

Programacin organizada.
Menor taza de errores.
Satisfaccin del programador.
Implementa una forma de trabajo donde se adopte fcilmente a las
circunstancias.
Cuenta con una tasa de errores muy pequea.
Fomenta la comunicacin entre los clientes y los desarrolladores.
Permite ahorrar mucho tiempo y dinero.
Puede ser aplicada a cualquier lenguaje de programacin.
La XP es mejor utilizada en la implementacin de nuevas tecnologas.

Desventajas:

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar.
Requiere de un rgido ajuste a los principios de XP.
Puede no siempre ser ms fcil que el desarrollo tradicional.

Cundo utilizar XP

Es mejor utilizar XP cundo el proyecto en cuestin tiene un alto riesgo de

elementos aadidos. Quiz sea satisfacer un plazo muy ajustado. Quiz sean
alguna cantidad o medio de requerimiento dinmico desconocido que la solucin
propuesta no tiene garantas de satisfacer. Cabe la posibilidad de que la solucin
propuesta sea tan avanzada que corre el riesgo simplemente de no funcionar.

El equipo de desarrollo real debe ser pequeo (no menos de dos personas y no
ms de 10 u 11) y todos los miembros del equipo de proyecto (no slo los de
desarrollo) pueden apropiarse del proceso de creacin.

Estos son los resultados deseados de XP:

Se incrementa considerablemente la productividad del equipo de desarrollo.

Se consigue con ms facilidad la satisfaccin del cliente.
Se satisfacen y mantienen los estndares de calidad.
Se satisfacen con ms precisin los requisitos del cliente.
 Se cumplen los plazos con mayor exactitud y consistencia.

Existe mucho debate entre la comunidad de programacin sobre el xito relativo y

la fiabilidad de XP. Con frecuencia las enormes presiones comerciales significan
que simplemente es un paradigma imposible de seguir. Sin embargo, cmo en
todo paradigma, es simplemente un modelo (algo a lo que se pretende llegar).