Monografia1 131205204308 Phpapp01

Universidad nacional de Trujillo
1
UNIVERSIDAD NACIONAL DE TRUJILLO SUB SEDE VALLE
JEQUETEPEQUE
FACULTAD DE CIENCIAS FSICAS Y MATEMTICAS
INFORMTICA

MONOGRAFA

METODOLOGA XP

AUTORES:
JOS SANCHZ FLORES
JOS RODRGUEZ CARUAJULCA
GUIDO MOSTACERO ESPINOZA

GUADALUPE PER
2013


2

NDICE

DEDICATORIA 3
INTRODUCCIN 4
1. MARCO TERICO 5

1.1 Extreme programing 5

1.1.1 Definicin 5
1.1.2 Valores 5
1.1.3 Conceptos 6
1.1.4 Caractersticas 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
BIBLIOGRAFA 29


3

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 da a
da para lograr nuestros objetivos, adems de
su infinita bondad y amor.

A nuestros padres por habernos apoyado en
todo momento, por sus consejos, sus valores,
por la motivacin constante que nos ha
permitido ser personas de bien, pero ms que
nada, por su amor.


4

INTRODUCCION

La metodologa gil es importante durante el desarrollo del software, pero como
elegir una metodologa que sea eficiente y nos ayude con el desarrollo del
proyecto.

La XP se puede definir como un conjunto de pasos de diversas metodologas,
acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso
comn, para realizar un desarrollo ms agradable y sencillo.

As, la XP se puede definir como un conjunto de pasos de diversas
metodologas, acopladas de manera que sean pasos flexibles a seguir
utilizadas con el uso comn, para realizar un desarrollo ms agradable y
sencillo.
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.
Esta metodologa tiene como base la simplicidad y como objetivo principal la
satisfaccin del cliente.
Las etapas que recomienda seguir esta metodologa se plantean de manera
sencilla pero a la vez son estrictas, y se inspiran en la total participacin de los
involucrados.
Por lo cual la presente monografa nos presentar la metodologa xp, sus
valores, principales conceptos entre otros.


5

1. MARCO TERICO

1.1 EXTREME PROGRAMMING (XP)

1.1.1 Definicin
Fue creado por Kent Beck, para la plantilla del proyecto C3 en
Chrysler.
Durante el proceso del proyecto C3 Chrysler naci una nueva
metodologa llamada extreme programming.
La programacin extrema o eXtreme Programming (XP) es una
metodologa de desarrollo gil, una de las ms exitosas en tiempo
reciente. Su autor principal es Kent Beck, quien eligi algunas
caractersticas de otras metodologas 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 diseado 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 metodologa XP en un proyecto tenemos
que conocer los valores principales, los cuales son los siguientes.
Simplicidad: La simplicidad es la base de la programacin
extrema, se refiere que ante todo y sin importar qu funcionalidad
requiera el usuario en su sistema, ste debe ser fcil. El diseo
debe ser sencillo y amigable al usuario, el cdigo debe ser simple
y entendible, programando slo lo necesario y lo que se utilizar.

Comunicacin: Es muy importante que haya una comunicacin
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

6
sencilla, entendible y que se entregue al cliente lo que necesita.

Coraje/valenta: La valenta le permite a los desarrolladores que
se sientan cmodos con reconstruir su cdigo cuando sea
necesario. Esto significa revisar el sistema existente y modificarlo
si con ello los cambios futuros se implementaran ms fcilmente.
Otro ejemplo de valenta es saber cundo desechar un cdigo:
valenta para quitar cdigo fuente obsoleto, sin importar cuanto
esfuerzo y tiempo se invirti en crear ese cdigo. Adems,
valenta significa persistencia: un programador puede
permanecer sin avanzar en un problema complejo por un da
entero, y luego lo resolver rpidamente al da siguiente, slo si
es persistente.

Retroalimentacin (Feedback): Al estar el cliente integrado en
el proyecto, su opinin sobre el estado del proyecto se conoce en
tiempo real. Es la comunicacin constante entre el desarrollador y
el usuario.

1.1.3 Conceptos
Los principales conceptos son los siguientes:
Story Cards: Las story cards sirven para registrar los
requerimientos de los clientes y son utilizadas para poder realizar
la estimacin de cada una de las iteraciones durante la fase de
planificacin. Las story cards son escritas por los clientes en
base a lo que se estima es necesario para el sistema. Estn
escritas en un formato de oraciones en la terminologa del cliente,
sin necesidad de sintaxis tcnicas.
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 nmero ideal para poder crear un plan de entregas es entre 20
y 80 stories.

Iteracin: Consta de un perodo 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 iteracin puede terminar de manera
exitosa.

7
Otro punto que no debe ser pasado por alto es el tema de la
duracin de cada iteracin. 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
ms simple, para aumentar la eficiencia o para que el cdigo sea
mucho ms entendible.

Release: La idea de cada release es poder tener un producto
intermedio al final de cada iteracin en la cual el cliente pueda
testear la funcionalidad pedida. Con esto los clientes pueden,
adems, 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 aceptacin: Los test de aceptacin representan algn
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
aceptacin. Esto significa que en cada iteracin se deben realizar
nuevos test de aceptacin o de lo contrario el equipo tendr una
avance de cero.

Test unitario: Son realizados desde el punto de vista del
programador y sirven, adems de testear el cdigo, para poder
realizar el refactoring del mismo. Cada programador, antes de
comenzar a programar, debe preparar los test unitarios. Esto
hace que dichos test estn preparados para ser corridos durante
la codificacin y adems, hace que al programador le surjan
dudas y pueda evacuarlas con el cliente antes de empezar con la
codificacin.

1.1.4 Caractersticas fundamentales
Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: Pequeas mejoras, unas
tras otras.

Pruebas unitarias continuas: Frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresin. Se aconseja

8
escribir el cdigo de la prueba antes de la codificacin.

Programacin en parejas: Se recomienda que las tareas de
desarrollo se lleven a cabo por dos personas en un mismo
puesto. La mayor calidad del cdigo escrito de esta manera -el
cdigo es revisado y discutido mientras se escribe- es ms
importante que la posible prdida de productividad inmediata.

Frecuente integracin del equipo de programacin con el
cliente o usuario: Se recomienda que un representante del
cliente trabaje junto al equipo de desarrollo.

Correccin de todos los errores: Antes de aadir nueva
funcionalidad. Hacer entregas frecuentes.

Refactorizacin del cdigo: Es decir, reescribir ciertas partes
del cdigo para aumentar su legibilidad y mantenibilidad pero sin
modificar su comportamiento. Las pruebas han de garantizar que
en la refactorizacin no se ha introducido ningn fallo.

Propiedad del cdigo compartida: En vez de dividir la
responsabilidad en el desarrollo de cada mdulo en grupos de
trabajo distintos, este mtodo promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto. Las
frecuentes pruebas de regresin garantizan que los posibles
errores sern detectados.

Simplicidad en el cdigo: La simplicidad y la comunicacin son
extraordinariamente complementarias. Con ms comunicacin
resulta ms fcil identificar qu se debe y qu no se debe hacer.
Cuanto ms simple es el sistema, menos tendr que comunicar
sobre ste, lo que lleva a una comunicacin ms 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:
Exploracin: En esta fase los clientes realizan las story cards
que desean que estn 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 tecnologa y las prcticas a ser utilizadas
durante el proyecto. La duracin de esta fase puede extenderse
desde unas pocas semanas a varios meses dependiendo de la
adaptacin del equipo de desarrollo.

Planificacin: El propsito de esta fase es el de llegar a un

9
acuerdo entre los clientes y los programadores en cules sern
las stories a ser implementadas durante cada iteracin. Si se
hace una buena preparacin durante la fase de exploracin esta
actividad no suele llevar ms de un da o dos. La entrega del
primer release debe tomar entre dos a seis meses de duracin.

Iteraciones por entregas: Una vez elegido el orden en el cual se
implementarn las stories se procede a definir cuantas
iteraciones sern necesarias para el proyecto. Cada iteracin
tiene una duracin 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 iteracin el cliente debe analizar que todas las
stories estn implementadas. Debe tambin correr todos los test
funcionales y que estos resulten ser exitosos.

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.

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. Adems, se prueba la nueva
tecnologa que se va a utilizar en el prximo release o migrar a
nuevas versiones de la tecnologa que se est utilizando.

Muerte: 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.


10

Figura 1. Ciclo de vida XP

1.1.6 Actores y responsabilidades

Programador: Responsable de decisiones tcnicas; construir el
sistema; disea y realizar pruebas. Debe existir una
comunicacin y coordinacin 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 decisin de
cuando se debe implementar determinada funcionalidad, as
como tambin en el orden a ser implementadas.
Los clientes tambin priorizan cada uno de los requerimientos.

Entrenador (Coach): Es el lder del equipo, toma las decisiones
ms importantes. Adems es el encargado de asegurar el
cumplimiento de todas las prcticas, transmitiendo sus

11
conocimientos y experiencia al resto del equipo.

Encargado de pruebas (Tester): Los tester ayudan a los
clientes a escribir los test funcionales del sistema. Adems,
corren dichos testing regularmente, envan 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 recoleccin de mtricas. Mide el
progreso del proyecto y lo compara con lo estimado. Tambin
observa el desempeo del equipo, haciendo nfasis en el
cumplimiento de los plazos y aconsejando al equipo si deben
realizar cambios para lograr los objetivos. Adems 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 especfico en algn tema necesario para el
proyecto. Gua al equipo para resolver un problema especfico.

Gestor (Big boss): Es el vnculo entre clientes y programadores,
ayuda a que el equipo trabaje efectivamente creando las
condiciones adecuadas. Su labor esencial es de coordinacin.

1.1.7 Artefactos
A continuacin describimos los artefactos de XP, entre los que se
encuentran: Historias de Usuario, Tareas de Ingeniera y Tarjetas
CRC.

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


12

Historia de Usuario
Nmero: Nombre Historia de Usuario:
Modificacin (o extensin) de Historia de Usuario (Nro. y
Nombre):
Usuario: Iteracin Asignada:
Prioridad en Negocio:

(Alta / Media / Baja)
Puntos Estimados:
Riesgo en Desarrollo:

(Alto / Medio / Bajo)
Puntos Reales:
Descripcin:
Observaciones:

Figura 2. Historia de usuario

Las Historias de Usuario tienen tres aspectos:

Tarjeta: En ella se almacena suficiente informacin para
identificar y detallar la historia.
Conversacin: cliente y programadores discuten la historia
para ampliar los detalles (verbalmente cuando sea posible,
pero documentada cuando se requiera confirmacin).
Pruebas de Aceptacin: permite confirmar que la historia
ha sido implementada correctamente.


13

Figura 3. Prueba de aceptacin

Caso de Prueba de Aceptacin
Cdigo: Historia de Usuario (Nro. y Nombre):
Nombre:
Descripcin:

Condiciones de Ejecucin:
Entrada / Pasos de ejecucin:

Resultado Esperado:
Evaluacin de la Prueba:


14

Tarjetas CRC (Clase-Responsabilidad-Colaborador): Estas
tarjetas se dividen en tres secciones que contienen la informacin
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 mtodos. Los
colaboradores de una clase son las dems clases con las que
trabaja en conjunto para llevar a cabo sus responsabilidades.
En la prctica conviene tener pequeas tarjetas de cartn, que
se llenarn 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

15
Disponer las tarjetas

1.1.8 Ventajas y Desventajas

1.1.8.1 Ventajas:

Programacin organizada.
Menor taza de errores.
Satisfaccin del programador.
Solucin de errores de programas.
Versiones nuevas.
Implementa una forma de trabajo donde se adapte
fcilmente a las circunstancias

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


16
EJEMPLO DE XP FERRETERIA

1. Historias de usuario:
Historia de Usuario
Nmero: 1 Usuario: Vendedor
Nombre historia: Registro de clientes
Prioridad en negocio:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 2 Iteracin asignada: 1
Programador responsable: equipo xp

Descripcin:
Se mostrar por pantalla una interfaz donde permitir al administrador ingresar los
datos de los clientes.

Observaciones:
Estos datos de los clientes se almacenarn en una Base De Datos
CONFIRMADO con el cliente

Historia de Usuario
Nombre historia: Registrar productos
Alta
Alta

Descripcin:
datos de los productos.

Observaciones:
Cada producto tiene un id diferente y est divido en categoras y marcas.



17

Historia de Usuario
Nombre historia: Generar Factura
Alta
Alta

Descripcin:
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 automticamente su nmero de factura y su serie.

CONFIRMADO con el cliente.

Historia de Usuario
Nmero: 3 Usuario: Administrador
Nombre historia: Registrar proveedor
Alta
Alta

Descripcin:
datos de los proveedores.

Observaciones:
Cada proveedor tiene un id diferente y est divido en categoras y marcas.



18
Historia de Usuario
Nombre historia: Pedido De Productos
Alta
Alta

Descripcin:
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 iteracin 1
La tarea realizada en la primera iteracin fue:
Crear la Base de datos con la que trabajaremos.
Historia de Usuario
Nombre historia: Registrar productos
Alta
Alta

Descripcin:
datos de los productos.

Observaciones:
Cada producto tiene un id diferente y est divido en categoras y marcas.



19
1.2 Historia de usuario- iteracin 2

- El cliente hizo una modificacin en cuanto a la seguridad, agregar login.
- Modificacin en la Base de datos.
Historia de Usuario
Nmero: 4 Usuario: Administrador y vendedor
Nombre historia: Ingresar al Sistema
Alta
Alta

Descripcin:
Se muestra por pantalla una interfaz donde podrn colocar su nombre y contrasea.

Observaciones:
El administrador y cliente tendrn un nombre y contrasea almacenada en la Base de
datos.


Historia de Usuario
Nombre historia: Registro de clientes
Alta
Alta

Descripcin:
datos de los clientes.

Observaciones:
Estos datos de los clientes se almacenarn en una Base De Datos


20
Historia de Usuario
Nombre historia: Seleccionar producto
Alta
Alta

Descripcin:
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
Nombre historia: Seleccionar cliente
Alta
Alta

Descripcin:
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


21
Historia de Usuario
Nombre historia: Generar Factura
Alta
Alta

Descripcin:
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 automticamente su nmero de factura y su serie.
Seleccionar el producto deseado con la historia de usuario nmero 2.
Seleccionar el cliente con la historia de usuario nmero 3.

1.3 Historia de usuario iteracin 3

Historia de Usuario
Nombre historia: Alerta de pedido
Alta
Alta

Descripcin:
Se muestra por pantalla una interfaz en donde el sistema avisa al administrador los
productos faltantes o que estn por agotarse.

Observaciones:
Este se llevar a cabo cuando la cantidad de venta llegue a la cantidad mnima del
producto.

22

Historia de Usuario
Nombre historia: Historial de Facturas
Alta
Alta

Descripcin:
Se muestra por pantalla una interfaz en donde se podr registrar las facturas de
ventas del vendedor/cajero

Observaciones:

Historia de Usuario
Nombre historia: Historial de Facturas-proveedor
Alta
Alta

Descripcin:
Se muestra por pantalla una interfaz en donde se podr registrar las facturas de
compras de los productos solicitados a los proveedores

Observaciones:


23

2. Casos de prueba de aceptacin

Casos de Prueba
Cdigo: 1 Historia de usuario: 1 registrar clientes
Nombre:
Registro de Clientes
Descripcin:
Este permitir ingresar los datos de los clientes y almacenarlos en la base de datos.
Condiciones de ejecucin:
Este se llevar a cabo si el cliente a registrar al menos ha comprado un producto de la
ferretera.
Entrada/ Pasos de ejecucin:
Tenemos como parmetros de entrada:
- Nombre del cliente
- Apellidos del cliente
- Ruc
- Dni
- Telfono
- Direccin
Pasos de ejecucin:
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
Evaluacin de la prueba:
Despus de hacer las pruebas, nos dimos cuenta que tenemos que hacer una
actualizacin cada vez que ingresamos un nuevo registro.


24

Casos de Prueba
Cdigo: 2 Historia de usuario: 2 registrar productos
Nombre:
Registro de Productos
Descripcin:
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
- Cdigo del producto
- Categora
- Marca
- Descripcin
- Cantidad mnima
- Cantidad de venta
- Cantidad de almacn
Pasos de ejecucin:
Resultado esperado:


25
Casos de Prueba
Cdigo: 3 Historia de usuario: 3 registrar proveedores
Nombre:
Registro de Productos
Descripcin:
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
- Cdigo del proveedor
Pasos de ejecucin:
Resultado esperado:

Casos de Prueba
Cdigo: 4 Historia de usuario: 4 ingresar al sistema
Nombre:
Login
Descripcin:
Este permitir ingresar al sistema siempre y cuando tengas un permiso
Este se llevar a cabo si en la base de datos estn registrados
- Nombre del producto
- Contrasea
Pasos de ejecucin:
Luego ingresar los datos, enviarlos a la base de datos, compararlos y finalmente
devolver el acceso al sistema siempre y cuando ests registrado de caso contrario
acceso denegado.
Resultado esperado:
Los datos comparados con xito
Prueba exitosa


26

Casos de Prueba
Cdigo: 5 Historia de usuario: 5 seleccionar productos
Nombre:
Lista de productos
Descripcin:
Este permitir visualizar todos los productos almacenados en la Base de datos
Este se llevar a cabo si en la base de datos estn registrados los productos
Pasos de ejecucin:
Ingresar a la interfaz listar productos e inmediatamente aparecern los productos
Resultado esperado:
Los datos son visualizas con xito
Despus de haber analizado la prueba nos dimos cuenta que esto es bueno para
cuando existen pocos productos.

Casos de Prueba
Cdigo: 6 Historia de usuario: 6 seleccionar clientes
Nombre:
Lista de clientes
Descripcin:
Este permitir visualizar todos los clientes almacenados en la Base de datos
Este se llevar a cabo si en la base de datos estn registrados los clientes
Pasos de ejecucin:
Ingresar a la interfaz listar clientes e inmediatamente aparecern los productos
Resultado esperado:
Los datos son visualizas con xito
Despus de haber analizado la prueba nos dimos cuenta que esto es bueno para
cuando existen pocos clientes.


27

Casos de Prueba
Cdigo: 7 Historia de usuario: 7 generar factura
Nombre:
Facturar
Descripcin:
Este permitir realizar una venta de los productos almacenados a determinado
cliente.
Este se llevar a cabo si en la base de datos estn registrados los productos a vender, si
no est registrado en cliente, se puede almacenar en el acto.
Entrada/Pasos de ejecucin:
Entrada:
- Datos de los clientes
- Datos de los productos
- Cantidad de los productos a vender
Pasos de ejecucin:
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
Despus de haber analizado la prueba nos dimos cuenta que tenemos que hacer varios
ingresos a la base de datos para realizar una venta.


28

CONCLUSIONES

El desarrollo de software no es una tarea fcil. Prueba de ello es que existen
numerosas propuestas metodolgicas. No existe una metodologa universal
para hacer frente con xito a cualquier proyecto de desarrollo de software.
Toda metodologa debe ser adaptada al contexto del proyecto.
Una de las cualidades ms destacables de XP es su sencillez, tanto en su
aprendizaje como en su aplicacin, reduciendo as los costos de implantacin
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 metodologa, pero para decidir que metodologa usar,
primero se deben examinar las distintas propuestas metodolgicas.


29

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

Monografia1 131205204308 Phpapp01

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Monografia1 131205204308 Phpapp01

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad nacional de Trujillo

S-ar putea să vă placă și