Metodología XP Universidad Nacional de Trujillo

UNIVERSIDAD NACIONAL DE TRUJILLO SUB SEDE VALLE
JEQUETEPEQUE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
INFORMÁTICA

MONOGRAFÍA

METODOLOGÍA XP

AUTORES:
JOSÉ SANCHÉZ FLORES
JOSÉ RODRÍGUEZ CARUAJULCA
GUIDO MOSTACERO ESPINOZA

GUADALUPE – PERÚ
2013

Universidad nacional de Trujillo

1

ÍNDICE

DEDICATORIA

3

INTRODUCCIÓN

4

1. MARCO TEÓRICO

5

1.1 Extreme programing

5

1.1.1 Definición

5

1.1.2 Valores

5

1.1.3 Conceptos

6

1.1.4 Características fundamentales

7

1.1.5 Ciclo de vida

8

1.1.6 Actores y responsabilidades

10

1.1.7 Artefactos

11

1.1.8 Ventajas y desventajas

15

1.1.8.1 Ventajas

15

1.1.8.2 Desventajas

15

1.1.9 Ejemplo

16

CONCLUSIONES

28

BIBLIOGRAFÍA

29


2

Primeramente a Dios a Dios por habernos
permitido llegar hasta este punto y habernos
dado salud, ser el manantial de vida y darnos
lo necesario para seguir adelante día a día
para lograr nuestros objetivos, además de su
infinita bondad y amor.
A nuestros padres por habernos apoyado en
todo momento, por sus consejos, sus valores,
por la motivación constante que nos ha
permitido ser personas de bien, pero más que
nada, por su amor.


3

INTRODUCCION

La metodología ágil es importante durante el desarrollo del software, pero como
elegir una metodología que sea eficiente y nos ayude con el desarrollo del
proyecto.
La XP se puede definir como un conjunto de pasos de diversas metodologías,
acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso
común, para realizar un desarrollo más agradable y sencillo.
Así, la XP se puede definir como un conjunto de pasos de diversas
metodologías, acopladas de manera que sean pasos flexibles a seguir
utilizadas con el uso común, para realizar un desarrollo más agradable y
sencillo.
Se puede considerar 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.
Esta metodología tiene como base la simplicidad y como objetivo principal la
satisfacción del cliente.
Las etapas que recomienda seguir esta metodología se plantean de manera
sencilla pero a la vez son estrictas, y se inspiran en la total participación de los
involucrados.
Por lo cual la presente monografía nos presentará la metodología xp, sus
valores, principales conceptos entre otros.


4

1. MARCO TEÓRICO
1.1 EXTREME PROGRAMMING (XP)
1.1.1 Definición
Fue creado por Kent Beck, para la plantilla del proyecto C3 en
Chrysler.
Durante el proceso del proyecto C3 Chrysler
metodología llamada extreme programming.

nació

una nueva

La programación extrema o eXtremeProgramming (XP) es una
metodología de desarrollo ágil, una de las más exitosas en tiempo
reciente. Su autor principal es Kent Beck, quien eligió algunas
características de otras metodologías y las relacionó de forma que
cada una complementara a la otra.
En XP se realiza eel software que el cliente solicita y necesita, en el
momento que lo precisa, alentando a los programadores a responder
a los requerimientos cambiantes que plantea el cliente en cualquier
momento. Esto es posible porque está diseñado para adaptarse en
forma inmediata a los cambios, con bajos costos asociados, en
cualquier etapa del ciclo de vida.
1.1.2 Valores
Para poder implementar la metodología XP en un proyecto tenemos
que conocer los valores principales, los cuales son los siguientes.
Simplicidad:
La simplicidad es la base de la programación
extrema, se refiere que ante todo y sin importar qué funcionalidad
requiera el usuario en su sistema, éste debe ser fácil. El diseño
debe ser sencillo y amigable al usuario, el código debe ser simple
y entendible, programando sólo lo necesario y lo que se utilizará.
Comunicación: Es muy importante que haya una comunicación
constante con el cliente y dentro de todo el equipo de trabajo, de
esto dependerá que el desarrollo se lleve a cabo de una manera


5

sencilla, entendible y que se entregue al cliente lo que necesita.
Coraje/valentía: La valentía le permite a los desarrolladores que
se sientan cómodos con reconstruir su código cuando sea
necesario. Esto significa revisar el sistema existente y modificarlo
si con ello los cambios futuros se implementaran más fácilmente.
Otro ejemplo de valentía es saber cuándo desechar un código:
valentía para quitar código fuente obsoleto, sin importar cuanto
esfuerzo y tiempo se invirtió en crear ese código. Además,
valentía significa persistencia: un programador puede
permanecer sin avanzar en un problema complejo por un día
entero, y luego lo resolverá rápidamente al día siguiente, sólo si
es persistente.
Retroalimentación (Feedback): Al estar el cliente integrado en
el proyecto, su opinión sobre el estado del proyecto se conoce en
tiempo real. Es la comunicación constante entre el desarrollador y
el usuario.

1.1.3 Conceptos
Los principales conceptos son los siguientes:
StoryCards: Las storycards sirven para registrar los
requerimientos de los clientes y son utilizadas para poder realizar
la estimación de cada una de las iteraciones durante la fase de
planificación. Las storycards son escritas por los clientes en base
a lo que se estima es necesario para el sistema. Están escritas
en un formato de oraciones en la terminología del cliente, sin
necesidad de sintaxis técnicas.
Otra diferencia entre las stories y los documentos tradicionales es
que se centran en lo que el cliente necesita.
Cada story puede llevar entre 1 a 3 semanas en ser desarrollada
en un desarrollo ideal.
El número ideal para poder crear un plan de entregas es entre 20
y 80 stories.
Iteración: Consta de un período de una a dos semanas en las
cuales el cliente selecciona las stories en ser desarrolladas.
Luego de ser implementadas este cliente corre sus test
funcionales para ver si la iteración puede terminar de manera
exitosa.


6

Otro punto que no debe ser pasado por alto es el tema de la
duración de cada iteración. Con iteraciones cortas se pretende
que el equipo tenga objetivos a corto plazo y pueda ver el
resultado de su trabajo cada cierto tiempo y no esperar varios
meses para ver si lo que se hizo estuvo bien o no.
Refactoring: Consiste en realizar cambios al sistema sin
modificar la funcionalidad del mismo para poder hacer el sistema
más simple, para aumentar la eficiencia o para que el código sea
mucho más entendible.
Release: La idea de cada release es poder tener un producto
intermedio al final de cada iteración en la cual el cliente pueda
testear la funcionalidad pedida. Con esto los clientes pueden,
además, ver el avance del proyecto y poder realizar comentarios
a los programadores y no esperar hasta el final del mismo
cuando esté todo integrado
Test de aceptación: Los test de aceptación representan algún
tipo de resultado por parte del sistema. Los clientes son los
responsables de verificar la exactitud de estos test y de revisar
los resultados para poder así priorizar los test que fracasaron.
Una story no es aceptada hasta que haya pasado su test de
aceptación. Esto significa que en cada iteración se deben realizar
nuevos test de aceptación o de lo contrario el equipo tendrá una
avance de cero.
Test unitario: Son realizados desde el punto de vista del
programador y sirven, además de testear el código, para poder
realizar el refactoring del mismo. Cada programador, antes de
comenzar a programar, debe preparar los test unitarios. Esto
hace que dichos test estén preparados para ser corridos durante
la codificación y además, hace que al programador le surjan
dudas y pueda evacuarlas con el cliente antes de empezar con la
codificación.
1.1.4 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

7

escribir el código de la prueba antes de la codificación.
Programación en parejas: Se recomienda que las tareas de
desarrollo se lleven a cabo por dos personas en un mismo
puesto. 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. Las
frecuentes pruebas de regresión garantizan que los posibles
errores serán detectados.
Simplicidad en el código: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.
1.1.5 Ciclo de vida
El ciclo de vida ideal de XP consiste de seis fases:
Exploración: En esta fase los clientes realizan las storycards
que desean que estén para la primera entrega. Cada story
describe una de las funcionalidades que el programa tendrá. Al
mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, la tecnología y las prácticas a ser utilizadas
durante el proyecto. La duración de esta fase puede extenderse
desde unas pocas semanas a varios meses dependiendo de la
adaptación del equipo de desarrollo.
Planificación: El propósito de esta fase es el de llegar a un

8

acuerdo entre los clientes y los programadores en cuáles serán
las stories a ser implementadas durante cada iteración. Si se
hace una buena preparación durante la fase de exploración esta
actividad no suele llevar más de un día o dos. La entrega del
primer release debe tomar entre dos a seis meses de duración.
Iteraciones por entregas: Una vez elegido el orden en el cual se
implementarán las stories se procede a definir cuantas
iteraciones serán necesarias para el proyecto. Cada iteración
tiene una duración de una a cuatro semanas, en las cuales se
realizan los test funcionales para cada una de las stories a ser
implementadas.
Al final de cada iteración el cliente debe analizar que todas las
stories estén implementadas. Debe también correr todos los test
funcionales y que estos resulten ser exitosos.
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.
Mantenimiento: En esta fase se debe agregar nueva
funcionalidad, mantener el sistema corriendo e incorporar nuevos
integrantes al equipo. Se hacen los refactoring que no se
pudieron realizar anteriormente. Además, se prueba la nueva
tecnología que se va a utilizar en el próximo release o migrar a
nuevas versiones de la tecnología que se está utilizando.
Muerte: 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.


9

Figura 1. Ciclo de vida XP

1.1.6 Actores y responsabilidades
Programador: Responsable de decisiones técnicas; construir el
sistema; diseña y realizar pruebas. Debe existir una
comunicación y coordinación adecuada entre los programadores
y otros miembros del equipo
Cliente (Customer): Es parte del equipo y es quien establece
que es lo que debe realizar el sistema, tomando la decisión de
cuando se debe implementar determinada funcionalidad, así
como también en el orden a ser implementadas.
Los clientes también priorizan cada uno de los requerimientos.
Entrenador (Coach): Es el líder del equipo, toma las decisiones
más importantes. Además es el encargado de asegurar el
cumplimiento de todas las prácticas, transmitiendo sus

10

conocimientos y experiencia al resto del equipo.

Encargado de pruebas (Tester): Los tester ayudan a los
clientes a escribir los test funcionales del sistema. Además,
corren dichos testing regularmente, envían los informes con los
resultados y realizan el mantenimiento a las herramientas de
testing.
Rastreador (Tracker): Tiene como principal responsabilidad
realizar las mediciones y la recolección de métricas. Mide el
progreso del proyecto y lo compara con lo estimado. También
observa el desempeño del equipo, haciendo énfasis en el
cumplimiento de los plazos y aconsejando al equipo si deben
realizar cambios para lograr los objetivos. Además de todo esto,
mantiene los registros de los casos de prueba ejecutados, los
defectos encontrados y sus responsables.
Consultor: Es un miembro externo del equipo con un
conocimiento específico en algún tema necesario para el
proyecto. Guía al equipo para resolver un problema específico.
Gestor (Big boss): Es el vínculo entre clientes y programadores,
ayuda a que el equipo trabaje efectivamente creando las
condiciones adecuadas. Su labor esencial es de coordinación.

1.1.7 Artefactos
A continuación describimos los artefactos de XP, entre los que se
encuentran: Historias de Usuario, Tareas de Ingeniería y Tarjetas
CRC.

Historias de Usuario (Story Cards): Representan una breve
descripción del comportamiento del sistema, se emplean para
hacer estimaciones de tiempo y para el plan de lanzamientos.


11

Historia de Usuario
Número:

Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro. y
Nombre):
Usuario:

Iteración Asignada:

Prioridad en Negocio:

Puntos Estimados:

(Alta / Media / Baja)
Riesgo en Desarrollo:

Puntos Reales:

(Alto / Medio / Bajo)
Descripción:

Observaciones:

Figura 2. Historia de usuario

Las Historias de Usuario tienen tres aspectos:
 Tarjeta: En ella se almacena suficiente información para
identificar y detallar la historia.
 Conversación: cliente y programadores discuten la historia
para ampliar los detalles (verbalmente cuando sea posible,
pero documentada cuando se requiera confirmación).
 Pruebas de Aceptación: permite confirmar que la historia
ha sido implementada correctamente.


12

Caso de Prueba de Aceptación

Código:

Historia de Usuario (Nro. y Nombre):

Nombre:

Descripción:

Condiciones de Ejecución:

Entrada / Pasos de ejecución:

Resultado Esperado:

Evaluación de la Prueba:

Figura 3. Prueba de aceptación


13

Tarjetas CRC (Clase-Responsabilidad-Colaborador): Estas
tarjetas se dividen en tres secciones que contienen la información
del nombre de la clase, sus responsabilidades y sus
colaboradores.

Figura 4. Tarjeta CRC

Una clase es cualquier persona, cosa, evento, concepto, pantalla
o reporte. Las responsabilidades de una clase son las cosas que
conoce y las que realizan, sus atributos y métodos. Los
colaboradores de una clase son las demás clases con las que
trabaja en conjunto para llevar a cabo sus responsabilidades.
En la práctica conviene tener pequeñas tarjetas de cartón, que
se llenarán y que son mostradas al cliente, de manera que se
pueda llegar a un acuerdo sobre la validez de las abstracciones
propuestas.
Los pasos a seguir para llenar las tarjetas son los siguientes:
 Encontrar clases
 Encontrar responsabilidades
 Definir colaboradores


14

 Disponer las tarjetas

1.1.8 Ventajas y Desventajas
1.1.8.1 Ventajas:
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
Solución de errores de programas.
Versiones nuevas.
Implementa una forma de trabajo donde
fácilmente a las circunstancias

se adapte

1.1.8.2 Desventajas:
Es recomendable emplearlo solo en proyectos a corto
plazo
Altas comisiones en caso de fallar
Imposible prever todo antes de programar
Demasiado costoso e innecesario


15

EJEMPLO DE XP – FERRETERIA
1. Historias de usuario:
Historia de Usuario
Número: 1

Usuario: Vendedor

Nombre historia: Registro de clientes
Prioridad en negocio:
Alta

Riesgo en desarrollo:
Alta

Puntos estimados: 2

Iteración asignada: 1

Programador responsable: equipo xp
Descripción:
Se mostrará por pantalla una interfaz donde permitirá al administrador ingresar los
datos de los clientes.
Observaciones:
Estos datos de los clientes se almacenarán en una Base De Datos
CONFIRMADO con el cliente

Historia de Usuario
Número: 2

Usuario: Vendedor

Nombre historia: Registrar productos
Alta
Puntos estimados: 2

Alta

Descripción:
datos de los productos.
Observaciones:
Cada producto tiene un id diferente y está divido en categorías y marcas.


16

Historia de Usuario
Número: 3

Usuario: Administrador

Nombre historia: Registrar proveedor
Alta
Puntos estimados: 2

Alta

Descripción:
datos de los proveedores.
Observaciones:
Cada proveedor tiene un id diferente y está divido en categorías y marcas.

Historia de Usuario
Número: 3

Usuario: Vendedor

Nombre historia: Generar Factura
Alta

Alta

Puntos estimados: 2


Descripción:
Se muestra por pantalla una interfaz en donde se podrá realizar una venta, tiene como
entradas datos del cliente, datos de los productos y su total de monto.
Observaciones:
En la factura se genera automáticamente su número de factura y su serie.
CONFIRMADO con el cliente.


17

Historia de Usuario
Número: 4


Nombre historia: Pedido De Productos
Alta
Puntos estimados: 2

Alta

Descripción:
Se muestra por pantalla un tipo comprobante para que pueda realizar el pedido de los
productos de acuerdo al proveedor.
Observaciones:

1.1

Historia de Usuario – iteración 1

La tarea realizada en la primera iteración fue:
Crear la Base de datos con la que trabajaremos.
Historia de Usuario
Número: 1

Usuario: Vendedor

Nombre historia: Registrar productos
Alta
Puntos estimados: 2

Alta

Descripción:
datos de los productos.
Observaciones:
Cada producto tiene un id diferente y está divido en categorías y marcas.


18

1.2 Historia de usuario- iteración 2
-

El cliente hizo una modificación en cuanto a la seguridad, agregar login.
Modificación en la Base de datos.
Historia de Usuario

Número: 4

Usuario: Administrador y vendedor

Nombre historia: Ingresar al Sistema
Alta

Alta

Puntos estimados: 2


Descripción:
Se muestra por pantalla una interfaz donde podrán colocar su nombre y contraseña.
Observaciones:
El administrador y cliente tendrán un nombre y contraseña almacenada en la Base de
datos.
Historia de Usuario
Número: 2

Usuario: Vendedor

Nombre historia: Registro de clientes
Alta

Alta

Puntos estimados: 2


Descripción:
datos de los clientes.
Observaciones:
Estos datos de los clientes se almacenarán en una Base De Datos


19

Historia de Usuario
Número: 5

Usuario: Vendedor

Nombre historia: Seleccionar producto
Alta
Puntos estimados: 2

Alta

Descripción:
Se muestra por pantalla una interfaz en donde se podrá visualizar todos los productos
registrados en la Base de Datos.
Observaciones:
Se hace una consulta a la Base de Datos.

Historia de Usuario
Número: 6

Usuario: Vendedor

Nombre historia: Seleccionar cliente
Alta

Alta

Puntos estimados: 2


Descripción:
Se muestra por pantalla una interfaz en donde se podrá visualizar todos los clientes
registrados en la Base de Datos.
Observaciones:
Se hace una consulta a la Base de Datos. Si el cliente no está registrado, se podrá
registrar en el acto


20

Historia de Usuario
Número: 7

Usuario: Vendedor

Nombre historia: Generar Factura
Alta
Puntos estimados: 2

Alta

Descripción:
Se muestra por pantalla una interfaz en donde se podrá realizar una venta, tiene como
entradas datos del cliente, datos de los productos y su total de monto.
Observaciones:
En la factura se genera automáticamente su número de factura y su serie.
Seleccionar el producto deseado con la historia de usuario número 2.
Seleccionar el cliente con la historia de usuario número 3.

1.3

Historia de usuario – iteración 3

Historia de Usuario
Número: 8


Nombre historia: Alerta de pedido
Alta
Puntos estimados: 2

Alta

Descripción:
Se muestra por pantalla una interfaz en donde el sistema avisa al administrador los
productos faltantes o que están por agotarse.
Observaciones:
Este se llevará a cabo cuando la cantidad de venta llegue a la cantidad mínima del
producto.


21

Historia de Usuario
Número: 9


Nombre historia: Historial de Facturas
Alta

Alta

Puntos estimados: 2


Descripción:
Se muestra por pantalla una interfaz en donde se podrá registrar las facturas de
ventas del vendedor/cajero
Observaciones:

Historia de Usuario
Número: 10


Nombre historia: Historial de Facturas-proveedor
Alta

Alta

Puntos estimados: 2


Descripción:
Se muestra por pantalla una interfaz en donde se podrá registrar las facturas de
compras de los productos solicitados a los proveedores
Observaciones:


22

2. Casos de prueba de aceptación
Casos de Prueba
Historia de usuario: 1 registrar clientes
Código: 1
Nombre:
Registro de Clientes
Descripción:
Este permitirá ingresar los datos de los clientes y almacenarlos en la base de datos.
Condiciones de ejecución:
Este se llevará a cabo si el cliente a registrar al menos ha comprado un producto de la
ferretería.
Entrada/ Pasos de ejecución:
Tenemos como parámetros de entrada:
- Nombre del cliente
- Apellidos del cliente
- Ruc
- Dni
- Teléfono
- Dirección
Pasos de ejecución:
En primer lugar tenemos que ingresar al sistema
Luego ingresar los datos, enviarlos a la base de datos y por último guardarlos.
Resultado esperado:
Los datos ingresaron con éxito
Evaluación de la prueba:
Después de hacer las pruebas, nos dimos cuenta que tenemos que hacer una
actualización cada vez que ingresamos un nuevo registro.


23

Casos de Prueba
Historia de usuario: 2 registrar productos
Código: 2
Nombre:
Registro de Productos
Descripción:
Este permitirá ingresar los datos de los productos y almacenarlos en la base de datos.
Este se llevará a cabo si el administrador tiende productos a registrar.
- Nombre del producto
- Código del producto
- Categoría
- Marca
- Descripción
- Cantidad mínima
- Cantidad de venta
- Cantidad de almacén
Resultado esperado:


24

Casos de Prueba
Historia de usuario: 3 registrar proveedores
Código: 3
Nombre:
Registro de Productos
Descripción:
Este permitirá ingresar los datos de los proveedores y almacenarlos en la base de
datos.
Este se llevará a cabo si el administrador tiende proveedores a registrar.
- Nombre del proveedor
- Código del proveedor
Resultado esperado:

Casos de Prueba
Historia de usuario: 4 ingresar al sistema
Código: 4
Nombre:
Login
Descripción:
Este permitirá ingresar al sistema siempre y cuando tengas un permiso
Este se llevará a cabo si en la base de datos estén registrados
- Nombre del producto
- Contraseña
Luego ingresar los datos, enviarlos a la base de datos, compararlos y finalmente
devolver el acceso al sistema siempre y cuando estés registrado de caso contrario
acceso denegado.
Resultado esperado:
Los datos comparados con éxito
Prueba exitosa


25

Casos de Prueba
Historia de usuario: 5 seleccionar productos
Código: 5
Nombre:
Lista de productos
Descripción:
Este permitirá visualizar todos los productos almacenados en la Base de datos
Este se llevará a cabo si en la base de datos estén registrados los productos
Ingresar a la interfaz listar productos e inmediatamente aparecerán los productos
Resultado esperado:
Los datos son visualizas con éxito
Después de haber analizado la prueba nos dimos cuenta que esto es bueno para
cuando existen pocos productos.

Casos de Prueba
Historia de usuario: 6 seleccionar clientes
Código: 6
Nombre:
Lista de clientes
Descripción:
Este permitirá visualizar todos los clientes almacenados en la Base de datos
Este se llevará a cabo si en la base de datos estén registrados los clientes
Ingresar a la interfaz listar clientes e inmediatamente aparecerán los productos
Resultado esperado:
Los datos son visualizas con éxito
Después de haber analizado la prueba nos dimos cuenta que esto es bueno para
cuando existen pocos clientes.


26

Casos de Prueba
Historia de usuario: 7 generar factura
Código: 7
Nombre:
Facturar
Descripción:
Este permitirá realizar una venta de los productos almacenados a determinado
cliente.
Este se llevará a cabo si en la base de datos estén registrados los productos a vender, si
no está registrado en cliente, se puede almacenar en el acto.
Entrada/Pasos de ejecución:
Entrada:
- Datos de los clientes
- Datos de los productos
- Cantidad de los productos a vender
Ingresar a la interfaz factura e inmediatamente empezar a realizar la venta.
Primero seleccionar el cliente (historia de usuario 6), luego seleccionar los productos
(historia de usuario 5), ingresar la cantidad a vender de los productos seleccionados y
calcular monto total.
Resultado esperado:
La venta es realizada con éxito
Después de haber analizado la prueba nos dimos cuenta que tenemos que hacer varios
ingresos a la base de datos para realizar una venta.


27

CONCLUSIONES

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen
numerosas propuestas metodológicas. No existe una metodología universal
para hacer frente con éxito a cualquier proyecto de desarrollo de software.
Toda metodología debe ser adaptada al contexto del proyecto.
Una de las cualidades más destacables de XP es su sencillez, tanto en su
aprendizaje como en su aplicación, reduciendo así los costos de implantación
en un equipo de desarrollo.
Usar o no XP, depende del grupo de desarrollo de software y del sistema a
implementar, este documento solo es una referencia para aquellos interesados
en conocer o usar esta metodología, pero para decidir que metodología usar,
primero se deben examinar las distintas propuestas metodológicas.


28

BIBLIOGRAFIA

http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema
https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&cad=rja&ved=0C
FoQFjAG&url=http%3A%2F%2Fwww.dsic.upv.es%2Fasignaturas%2Ffacultad%2Flsi%2Fdoc%2F
MetodologiasAgilesyExtremeProgramming.ppt&ei=VjShUuv_AdPnkAfvo4GoBw&usg=AFQjCNG
QW5dyLViXWxZ2N5F4Pce1B1IrmQ&sig2=0yhnm9aMWAWtrxJy_LXPQw
http://ingsoftware072301.obolog.com/metodologia-xp-2012877
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html


29

Metodología XP Universidad Nacional de Trujillo

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Metodología XP Universidad Nacional de Trujillo

Similar a Metodología XP Universidad Nacional de Trujillo (20)

Último

Último (20)

Metodología XP Universidad Nacional de Trujillo