Desarrollo de Software Utilizando La Metodología XP

INTRODUCCIÓN
La presente investigación sobre el aprovechamiento integral y racional de la Tara es

producto de una extensa revisión bibliográfica relativa a este producto, con la
finalidad de conocer como utilizar la materia prima para la obtención del ácido
tánico, muy usado en las industrias peleteras, farmacéutica, química, de pinturas,
etc., y de gomas para uso alimenticio proveniente del endospermo, constituyéndose
en alternativa a las gomas tradicionales en la industria mundial de alimentos, pintura,
barnices, entre otros; considerando que el Perú es un país de geografía variada que
condiciona la heterogeneidad de los recursos naturales.
La Tara es producida en varias zonas del país, siendo cultivada en terrenos situados
entre los 1000 y 2900 msnm, siendo sus principales productores los departamentos de:
Cajamarca, La Libertad, Ayacucho, Huancavelica, Apurímac, Ancash y Huanuco.
La vaina separada de la pepa se muele y es un extraordinario producto de
exportación como materia prima para la obtención del ácido tánico. De las semillas,
pepas o pepitas se obtiene, mediante un proceso térmico-mecánico una goma de
uso alimenticio proveniente del endospermo, constituyéndose en alternativa a las
gomas tradicionales en la industria mundial de alimentos, pinturas, barnices, entre
otros. Esta goma ha sido aprobada, por Resolución del 26 de setiembre de 1996 (Nº
E.C.C: E-417) por la Comunidad Europea, para ser usada como espesante y
estabilizador de alimentos para consumo humano. De esta manera ingresó al
mercado mundial de Hidrocoloides alimenticios como producto alternativo a la
goma de Algarrobo, producida en España y en Medio Oriente. La cadena de
producción de tara en nuestra región básicamente esta orientada a la producción y
comercialización de tara en vaina, hecha por algunas empresas ubicadas en la
provincia de Huanta, que a su vez transforman tara en polvo, hojuelas de tara, debido
al creciente incremento y demanda del mercado externo, de esta manera se
favorece en forma directa al productor, desde este momento y gracias a la
intervención de las diferentes instituciones se valora la tara como un producto de
importancia para el mejoramiento del medio ambiente y como consecuencia tiene
un impacto en la economía del productor.
1
CAPITULO I
1.1 ANTECEDENTES DE INVESTIGACION.

Según el artículo de José Bravo, Isel Bustamente [1], en el 2006 se registró un
significativo incremento de las exportaciones de tara, planta originaria del Perú,
precisó que respecto al 2005 las exportaciones de tara en polvo aumentaron el año
pasado a 78%, y que los principales compradores fueron Italia (20%), Brasil (18%) y
Argentina (15%), lográndose US$ 11.7 millones. En tanto, las ventas al exterior de goma
de tara aumentaron 120%, lo que significó un ingreso de US$ 8.3 millones, siendo
Estados Unidos (14%), España (11%) e Italia (11%) los mayores importadores. La tara
de polvo es utilizada en el curtido de cueros, en la fabricación de plásticos y
adhesivos, en la elaboración de medicamentos y productos de belleza, en la
protección de metales, en la perforación y mantenimiento de pozos de petróleo, y
otras actividades industriales, mientras que la goma de tara es usada en el
procesamiento de productos lácteos, de confitería, de alimentos dietéticos y otros.
Los técnicos de Sierra exportadora detallaron que la empresa Silvateam Perú S.A.C.,
de capital italiano, se constituyó en el principal exportador de ambos productos, con
41% de tara en polvo y 35% de goma de tara. Perú produce el 80% de la producción
mundial de tara, siendo los principales productores son los departamentos de
Ayacucho y Cajamarca, cuya producción proviene de bosques (forma silvestre),
explicaron. Bolivia es otra nación que posee bosques de tara, y en Chile, Ecuador y
Colombia existen plantas aisladas. De otro lado, se dio a conocer que en enero último
se ha exportado tara en polvo por US$ 1.03 millones en dos presentaciones: tara en
polvo ultrafina y tara en polvo gruesa; y se ha exportado goma de tara por US$ 0.3
millones en sus dos presentaciones: goma de tara en polvo y split. En los próximos 5
años, las exportaciones de tara han presentado una tendencia creciente (23%)
Debido a ello, Sierra Exportadora contribuirá con el manejo de bosques y
plantaciones de 3,000 hectáreas de tara para el 2007 y 10,000 has. En 5 años; las
cuales serán absorbidas por el mercado. Además, realizará un estudio para conocer
el potencial y las tendencias del mercado chino, que será el principal competidor del
Perú en este rubro. Se hace referencia a tara en vaina y sus derivados como la goma
de tara, polvo de tara, entre otros.
2
Según Efraín Avendaño Torres SOLID-2007 [2], menciona que en el año 2007 la
producción de tara en Ayacucho se estima en 810 has, de las cuales el 35% son
instaladas y el 65% son silvestres. El 57% del total de la extensión de tara es manejado.
Y representa para Ayacucho $ 4.76 millones en exportaciones, y que en el 2006 se
registró una producción total de 5083 Tm. El año 2007 el precio promedio ha sido el
mas alto en la historia de tara, así en el mes de mayo llegó hasta S/. 2,80 y en agosto
S/. 3,20/Kg de tara en chacra. Las zonas de producción analizadas concentran
aproximadamente el 90% de la oferta regional. Para producir la tara en vaina el
productor realiza las labores de plantación, labores agronómicas, cosecha de tara y
la venta al acopiador y comercializador.
A. DESCRIPCIÓN DEL ESLABÓN DE COMERCIALIZACIÓN

Según Efraín Avendaño Torres IDESI, SNV-2007 [2], la comercialización de tara en
el Departamento de Ayacucho empieza en abril y termina en afines de agosto,
comprando de 1 a 2000 Kg. aproximadamente. Si los volúmenes son mayores a 100
Kg reciben adelantos para la campaña; pero si los productores poseen regular
cantidad de plantaciones de tara reciben adelantos por anticipado en cualquier
mes del año. Los adelantos, transacciones, acuerdos y otros se realizan de manera
informal; es decir, no existen contratos, recibos ni regulación de las balanzas. Estos
adelantos se cobran en un período no mayor a un mes. El comercializador compra la
tara a los acopiadores, previa revisión, un mínimo de 100 Kg. con un precio mayor al
que se compra del productor trasladando los productos en camiones de recolección.
En el 2006 el 93,80% de la producción de tara provenía de las provincias de Huanta y
Huamanga, el 3,78% de Cangallo y La Mar y el 2,42% de otras provincias.
El comercializador vende tara en vaina al transformador trasladando el producto por

su propio medio, entregando como mínimo 10 TM por envió y previa revisión de
calidad. El precio de la tara a nivel local ha crecido en un 9% anual; esta tendencia
podría mantenerse hasta llegar a un precio máximo de S/. 3,50/Kg en chacra; sin
embargo, luego de 2 ó 3 años, probablemente se registre una caída hasta llegar a
un precio real y estable de entre S/. 1,00 y S/. 1,50/Kg de tara en chacra. En Huanta
y Huamanga los precios pagados por la tara han sido mayores que el de las demás
provincias. Las provincias de Cangallo y La Mar, tienen precios mas bajos que las
primeras, pero aún altos respecto a las otras provincias. El comercializador compra
3
tara procesada previa revisión de calidad al transformador. De las 5.083 TM de tara,
el 74% se comercializa en vaina y el 26% transformado en goma y harina. Los
principales demandantes del mercado ayacuchano son: Silvateam Perú, 35%;
Productos del País, 30%; Exportadora el sol, 8%; otros, 27%. Las empresas exportadoras
salen rápidamente del mercado, así hace 4 años atrás existían más de 40 empresas.
En el año 2006 sólo quedaron aproximadamente 20 y para el presente año quedan
de 12 a 15 empresas. Las principales empresas exportadoras del país son: Silvateam
Perú, 33,7%; Exportadora el Sol, 17,7%; Transformadora Agrícola, 10,7%; Productos del
País, 9%; Molinos Chipoco, 9%; Exportaciones de la Selva, 7%; otras empresas, 12%.
4
CAPITULO II
MARCO TEORICO
2.1 LA COMERCIALIZACIÓN DE TARA DE LA REGIÓN AYACUCHO.

Según Primo De la Cruz Lapa [3], “el aprovechamiento integral y racional de la
Tara es producto de una extensa revisión bibliográfica relativa a este producto, con
la finalidad de conocer como utilizar la materia prima para la obtención del ácido
tánico, muy usado en las industrias peleteras, farmacéutica, química, de pinturas,
etc.., y de gomas para uso alimenticio proveniente del endospermo, constituyéndose
en alternativa a las gomas tradicionales en la industria mundial de alimentos, pintura,
barnices, entre otros; considerando que el Perú es un país de geografía variada que
condiciona la heterogeneidad de los recursos naturales, cuya disponibilidad y
calidad es necesario conocer para poder planificar el desarrollo económico social
en provecho de la población rural”.
2.1.1 Descripción de la tara

Según Primo De la Cruz Lapa [3], la tara, también conocida como “Taya”, es
una planta originaria del Perú utilizada desde la época prehispánica en la medicina
folclórica o popular y en años recientes, como materia prima en el mercado mundial
de hidrocoloides alimenticios; de nombre científico Caesalpina Spinosa o Caesalpina
Tinctoria. Sus características botánicas son las siguientes:
a) Es un árbol pequeño, de dos a tres metros de altura, de fuste corto, cilíndrico y
a veces tortuoso, y su tronco está provisto de una corteza gris espinosa, con
ramillas densamente pobladas. En muchos casos las ramas se inician desde la
base dando la impresión de varios tallos. La copa de la Tara es irregular,
aparasolada y poco densa, con ramas ascendentes.
b) Sus hojas son en forma de plumas, parcadas ovoides y brillante ligeramente
espinosa de color verde oscuro y miden 1.5 cm de largo.
c) Sus flores son de color amarillo rojizo, dispuestos en racimos de 8 cm a 15 cm de
largo.
5
d) Sus frutos son vainas explanadas e indehiscentes de color naranja de 8 cm a 10
cm de largo y 2 cm de ancho aproximadamente, que contienen de 4 a 7 granos
de semilla redondeada de 0.6 cm a 0.7 cm de diámetro y son de color pardo
negrusco cuando están maduros.
e) Inflorescencia con racimos terminales de 15 a 20 cm. de longitud de flores
ubicadas en la mitad distal, flores hermafroditas, zigomorfas, cáliz irregular
provisto de un sépalo muy largo de alrededor de 1 cm, con numerosos
apéndices en el borde, cóncavo, corola con pétalos libres de color amarillento,
dispuestas en racimos de 8 a 20 cm de largo, con pedúnculos pubescentes de
56 cm de largo, articulado debajo de un cáliz corto y tubular de 6 cm de
longitud; los pétalos son aproximadamente dos veces más grandes que los
estambres. Cada árbol de Tara puede rendir un promedio de 20 kg a 40 kg de
vaina cosechándolos dos veces al año. Generalmente, un árbol de Tara da
frutos a los tres años; y si es silvestre, a los cuatro años. Su promedio de vida es
de cien años y el área que ocupa cada árbol es de 10 metros cuadrados.
Grafico Nº 01: Variedades de la Tara.
Vaina de Tara Semilla de la Tara Hojuela de Tara Goma de la Tara
Fuente: http://www.molinosasociados.com/
2.1.2 Aprovechamiento integral de la tara

Según Primo De la Cruz Lapa [3], la tara se encuentra en estado silvestre y posee
un inmenso potencial médico, alimenticio e industrial, siendo de gran utilidad para la
producción de hidrocoloides o gomas, taninos y ácido gálico, entre otros.
Además, es utilizada en la protección de suelos, especialmente cuando no se

dispone de agua de riego, a fin de dar buena protección a muchas tierras que hoy
6
están en proceso de erosión y con fines comerciales. Se usa frecuentemente en
asociación con cultivos como el maíz, papa, habas, alfalfa, sorgo o pastos. No ejerce
mucha competencia con los cultivos, por su raíz pivotante y profunda y por ser una
especie fijadora de nitrógeno; así como tampoco por su copa, que no es muy densa
y deja pasar la luz. Debido a su pequeño porte y a su sistema radicular profundo y
denso, es preferida para barreras vivas, control de cárcavas y otras prácticas
vinculadas a conservación de suelos en general, sobre todo en zonas áridas o
semiáridas. El aprovechamiento de los frutos permite obtener numerosos productos
de interés. La vaina representa el 62% del peso de los frutos y es la que precisamente
posee la mayor concentración de taninos que oscila entre 40% y 60%. Estos taninos se
utilizan en la industria para la fabricación de diversos productos, o en forma directa
en el curtido de cueros, fabricación de plásticos y adhesivos, galvanizados y
galvanoplásticos, conservación de aparejos de pesca de condición bactericida y
funguicida, como clarificador de vinos, como sustituto de la malta para dar cuerpo
a la cerveza; en la industria farmacéutica por tener un amplio uso terapéutico, para
la protección de metales, cosmetología, perforación petrolífera, industria del caucho,
mantenimiento de pozos de petróleo y como parte de las pinturas dándole una
acción anticorrosivo.
Otro elemento que se obtiene de los taninos de la Tara, es el ácido gálico que es
utilizado como antioxidante en la industria del aceite y en la industria cervecera
como un elemento blanqueante o decolorante, en fotografía, tintes, como agente
curtiembre, manufactura del papel, en productos de farmacia y otros relacionados
al grabado o litografía.
Las semillas de uso forrajero tienen en su composición porcentual en peso el 28% de

cáscara, 34% de gomas y 37.5% de germen (almendra) como altísimo contenido de
proteínas de gran concentración de metionina y triftofano de buena calidad, grasas
y aceites que podrían servir para el consumo humano. De esta parte del fruto se
obtiene aceite, goma (usada para dar consistencia a los helados), harina proteica y
derivados como: jabones, pinturas, barnices, esmaltes, tintes de imprenta, mantecas
y margarinas comestibles, pues presenta un contenido de ácidos libres de 1,4% (ácido
oleico) es aceptable comercialmente por su baja acidez.
7
Industrialmente se integra como parte de los medicamentos gastroenterológicos,
para curar úlceras; cicatrizantes, por sus efectos astringentes, antinflamatorios,
antisépticos, antidiarreicos, antimicóticos, antibacterianos, antiescorbúticos,
odontálgicos y antidisentéricos, siendo más utilizados aquellos que producen
constricción y sequedad. Es utilizada, muy frecuentemente, en la medicina
tradicional para aliviar malestares de la garganta, sinusitis, infecciones vaginales y
micóticas; lavado de los ojos inflamados; heridas crónicas y el índice cariado, dolor
de estómago; las diarreas; cólera; reumatismo y resfriado; depurativo del colesterol.
La madera sirve para la confección de vigas, viguetas o chaclas, para construir
viviendas; mangos de herramientas de labranza de buena calidad y postes para
cercos, así como leña y carbón debido a sus bondades caloríficas.
Según Edwin Almeyda ochoa, Coordinador Gitara [4], la situación de la

cadena de la Tara es una actividad productiva de recolección, falta de técnicas de
manejo agronómico, Producción de la tara dispersa e individualizada, la intervención
de instituciones facilitadoras (estables y privadas) no es unificada, informabilidad de
mercado, ocasiona la variabilidad de precios (producción y comercialización), etc.”.
Según Gina Karina Quiñonez Cachay [5], “La Tara posee un inmenso potencial
médico, alimenticio e industrial, siendo de gran utilidad para la producción de
hidrocoloides o gomas, taninos y ácido gálico, entre otros. Además, es utilizada en la
protección de suelos, especialmente cuando no se dispone de agua de riego, a fin
de dar buena protección a muchas tierras que hoy están en proceso de erosión y
con fines comerciales. No ejerce mucha competencia con los cultivos, por su raíz
pivotante y profunda y por ser una especie fijadora de nitrógeno; así como tampoco
por su copa, que no es muy densa y deja pasar la luz. Debido a su pequeño porte y
a su sistema radicular profundo y denso, es preferida para barreras vivas, control de
cárcavas y otras prácticas vinculadas a conservación de suelos en general, sobre
todo en zonas áridas o semiáridas.
El polvo es utilizado como tinte y curtidor de cueros, su precio internacional del polvo
asciende a 550 dólares por tonelada y el de la goma, substituta de la pectina,
alcanza los 4.200 dólares por tonelada. El árbol de tara es productivo a los 4 años y
su producción se concentra en los departamentos de Ancash, Ayacucho,
8
Cajamarca, Huanuco, Ica, La Libertad y Lambayeque. El valor exportado alcanzó los
6,14 millones de dólares en 1993.
Las gomas tienen una gran aplicación en la industria en alimentos procesados,

productos farmacológicos, cosméticos y productos de tocador, adhesivos, tintes y
tintas, litografías, pinturas, textilería, papelería, etc.”
Gráfico Nº 02: Usos diversos de la Tara.
Fuente: Extraído del Proyecto de Pre factibilidad para la instalación de 100 hectáreas de tara
(caesalpinia spinosa) en Jayanca Lambayeque – Perú
2.1.3 Proceso Productivo Para La Obtención De Concentrado Tánico

Según Primo De la Cruz Lapa [3], de la tara se obtiene el polvo de tara que
contiene un gran porcentaje de taninos. El polvo de Tara se consigue mediante un
proceso mecánico simple de trituración de vaina, previamente despepitada,
obteniendo como producto un aserrín fino de coloración amarilla clara, con un
aproximado de 52 a 54% de taninos. Posteriormente, se obtiene extracto de Tara o
extracto tánico, mediante un proceso de concentración. Los taninos son sustancias
polifenólicas naturales de origen vegetal que tienen la propiedad de curtir la piel
transformándola en cuero y dar, en conjunción con sales de fierro, coloraciones azul
oscura, negra o verde. El proceso para la obtención del concentrado tánico es el
siguiente:
9
a) Las vainas de Tara pasan por el proceso de separación de materias extrañas.
b) Las vainas de Tara son desviadas (usando una desviadora o despepitadora),
obteniéndose porcentualmente:
Tabla Nº 01: Despepitadora de la Tara.

SEMILLA POLVO FIBRA
33% 45% 22%
Fuente: Primo De la Cruz Lapa, “Aprovechamiento Integral y racional de la Tara” Revista del
Instituto de Investigación de la Facultad de Ingeniería Geología, Minera, Metalurgia y Geografía
- Universidad San Marco 2004.
c) Posteriormente, la fibra y el polvo (que salen juntos de la despepitadora), con

un contenido de taninos de 52% a 54% pasan por el proceso de extracción bajo
los siguientes parámetros:
Tabla Nº 02: Parámetros de la tara.

TEMPERATURA 65º - 67 ºC
TIEMPO 30 -40 minutos
RELACIÓN AGUA/POLVO 5/1 a 4/1
NÚMERO DE LAVADOS 4-5
d) La purificación del extracto líquido se realiza por medio de decantación y

filtración.
e) La concentración del extracto líquido purificado se lleva de 2-5 grados Berilio

hasta 11-12 grados Berilio.
f) El secado del extracto se realiza por atomización.
Tabla Nº 03: Atomización de la tara.

HUMEDAD 5%- 4%
TANINOS 66% -71.5%
10
NO TANINOS 27% - 19%
NÚMERO DE LAVADOS 53% -5.5 %
CENIZAS 3% - 3.5 %
g) Del extracto de tara se puede obtener: ácido tánico, ácido galotánico y ácido
gálico
Según Lorenzo Basurto Rodríguez [6], “De la tara se obtiene el polvo de tara
que contiene un gran porcentaje de taninos. El polvo de tara se consigue mediante
un proceso mecánico simple de trituración de vaina, previamente despepitada,
obteniendo como producto un aserrín fino de coloración amarilla clara, con un
aproximado de 52% a 54% de taninos. Para su exportación se requiere:
- Tara Gruesa: solo se requiere de un despepitador con una criba de agujeros
de 2mm de diámetro.
- Tara Ultra fina: Requiere de una molida mucho más perfecta para llegar a una
finura pasante 100 mesh al 100%.
2.2 LAS GOMAS O HIDROCOLOIDES

Según Primo De la Cruz Lapa [3], llamados también biopolímeros, son moléculas
polisacáridos, frecuentemente asociadas con metálicos como Ca, K o Mg, y se
clasifican como gomas naturales, modificadas o sintéticas; producen a bajas
concentraciones (menor al 1%), efectos gelificantes o suspensiones viscosas por lo
que se usan como adhesivos, inhibidores de cristales y agentes gelificantes.
Los hidrocoloides o gomas tienen un amplio campo de aplicación en la industria

alimentaria como estabilizante, emulsionante o espesantes. Aunque no contribuyen
al aroma, sabor o poder nutritivo de los alimentos. Son también utilizados en la
industria farmacéutica, papelera y textil, mejorando las propiedades de los diferentes
productos elaborados. Otras propiedades apreciadas en los hidrocoloides son su
acción coagulante, lubricante y formadora de películas, aún encontrándose en muy
bajas concentraciones.
11
Según Carlos Elías Peñafiel, Betti Salvá Ruiz [7], “El presente trabajo de
investigación en aplicar el Método de Diseño de Mezclas para determinar el máximo
porcentaje de inclusión de goma de tara en la formulación de salchichas tipo
Frankfurter, en función a las restricciones establecidas: CRA/humedad y agua
añadida”.
Según Lorenzo Basurto Rodríguez [6], “La Goma de Tara se deriva del
endospermo molido de la planta de Tara, Caesalpinia Spinosa, de la familia de las
Caesalpinaceae leguminosas. La planta es cultivada comercialmente en el Perú
para el consumo humano y animal. El tiempo de cultivo es de aproximadamente 3 a
4 años. La planta de Tara es una leguminosa que lleva una vaina, fijadora del
nitrógeno, es robusta y resistente a sequedad y crece con tallos de 2 a 5 m de altura.
Las vainas de la semilla tienen aproximadamente de 8 a 10 cm de largo y contienen
cuatro a siete semillas de aproximadamente 6 a 7 mm en el diámetro.
Aproximadamente 39.5 a 41% de la semilla son la cáscara, 25 a 27% representan el
endospermo 25.5 a 27% el germen y 11% a 5% la humedad.”
2.2.1 Promedio
Tabla Nº 04: Promedio de porcentaje de la goma de tara.

Germen 40%
Cáscara 38%
Endosperno 22%
Fuente: Lorenzo Basurto Rodríguez “productos agroindustriales de exportación”, lima – Perú – Alnicolsa
Del Perú Sac. 2009.
Tabla Nº 05: Características de la goma de tara.
Descripción: Es una goma natural obtenida de las semillas de la Tara (Caesalpinia

spinosa)
Color: Crema claro
Cenizas: < 2%
12
Humedad: < 15%
Granulometría: Pasante:
250 micrones (60 mesh) al 100%
Viscosidad: propiedades: Viscosity 1% solution, Brookfield RVT, a 20 RPM , Spindle 4.
Hot Dissolution 86 °C 10 min.
Measured at 25 °C 5000-6000 cPs
Cold Dissolution 25 °C
After 30 min. 3500-4000 cPs
After 24 hours 4500-5500 cPs
Características Polisacárido, hidrocoloide de alto peso molecular, constituido por
unidades de Galactosa y manosa, combinados por enlaces
glicosídicos (galactomanos).
Presentación Sacos laminados de polipropileno de 25 kg neto o bolsas de papel
multi-pliego cubiertos de polietileno de 25 Kg.
Fuente: Lorenzo Basurto Rodríguez “productos agroindustriales de exportación”, lima – Perú –
Alnicolsa Del Perú Sac. 2009
2.2.2 Procesamiento
Según Lorenzo Basurto Rodríguez [6],”En el procesamiento comercial de la
goma de Tara, se utiliza una variedad de métodos para separar eficazmente el
endospermo de la cáscara y del germen. La cáscara, el germen y el endospermo se
separan por un proceso térmico-mecánico usándose una molienda diferencial ya
que hay una diferencia en la dureza de cada componente. Luego se clasifica e
ingresar a un selector óptico; saliendo con una limpieza del 98%. Terminando después
la limpieza final a un 100%. El endospermo separado, que contiene 80% galactomano,
se muele finalmente a un tamaño de partícula fino y se vende como goma de Tara.
Esta molienda se hace en varias fases y cernido. Se usan molinos de martillos, de roce
o de rodillo.”
Grafico Nº 03: Semilla de Tara.
13
Grafico Nº 04: Procesamiento de la Tara.
Fuente: Extraído De Goma De Tara – Alnicolsa Del Perú S.A.C. Perú
2.2.3 Características físicas

14
Según Lorenzo Basurto Rodríguez [6], “La Goma de Tara es un polvo blanco a
blanco-amarillento, sin olor y sin sabor. Las calidades técnicas son ligeramente más
oscuras en el color. Los tamaños de la malla fácilmente disponibles son de 40 a 300
micrones.”
2.2.4 Propiedades
Según Lorenzo Basurto Rodríguez [6], “Evita las reacciones indeseables de
sinéresis y otras alteraciones, y por ello es considerado un sustituto o complemento
ideal de las gomas garrofín, guar, xantana,etc. Tiene una gran capacidad de
absorción de agua y en agua fría se dispersa lentamente; cuando se calienta, se
transforma en un gel homogéneo que mantiene sus propiedades al enfriar. “
Grafico Nº 05: Estabilidad al congelamiento y descongelamiento de la Tara y el LBG
2.2.5 Solubilidad
Según Lorenzo Basurto Rodríguez [6], “Soluble en agua al 60% a 25ºC,
alcanzando su total solubilidad a 98ºC. Las viscosidades alcanzadas por las
dispersiones tanto en agua fría (25ºC) como azúcar caliente (85ºC) son superiores a
las de la goma garrofin, guar, xantana, tragacanto y carragenina, con los que
compite con ventaja en usos industriales.
La Goma de Tara se dispersa e hidrata casi completamente en agua frío o caliente,

formando soluciones muy viscosas. Es insoluble en solventes orgánicos.”
2.2.6 Viscosidad
15
Según Lorenzo Basurto Rodríguez [6], “La viscosidad de dispersiones o
soluciones de goma de Tara depende de temperatura, tiempo, concentración, pH,
velocidad de agitación y tamaño de la partícula del polvo,. En agua fría la viscosidad
máxima se logra en 1 a 4 horas. El polvo más fino de goma de Tara se hidrata más
rápido que los polvos gruesos. Para uso en alimentos la viscosidad de una solución al
1% varía de 2000 a más de 5000 cps.”
2.2.7 Características químicas

Según Lorenzo Basurto Rodríguez [6], “La Goma de Tara, como la goma de
algarrobo, es un polisacárido de elevado peso molecular, sobre todo
galactomananos. El componente principal consiste en una cadena lineal de
unidades de (1->4)- -D-manopiranosa con unidades de -D-galactopiranosa con
enlaces (1->6). La proporción entre manosa y galactosa en la goma de tara es de
3:1. (En la goma de algarrobo esta proporción es de 4:1 y en la goma de guar es de
2:1) . El peso molecular de este galactomano es 220, +/- un 10%. La goma de de Tara
tiene bifurcaciones únicas de galactosa en cada cuarta unidad del manosa. La
bifurcación lateral mayor de las moléculas de goma de Tara causa su mejor
hidratación en agua fría, así como una mayor actividad en la fijación de hidrógeno.
En promedio, la goma de Tara contiene 80% galactomannan, 13.76% agua, 2.5%
proteína, 2% residuo insoluble en ácidos o fibra cruda, 0,53% ceniza, 0,7% grasa, cero
arsénico, y cero plomo, aproximadamente.”
Gráfico Nº 06: caracteristicas de goma de Tara

16
Tabla Nº 06: característica química de la goma de tara.
Humedad Fibra Extracto Azúcares

Proteínas Cenizas Grasa Carbohidratos
bruta etéreo totales
8- 0,53 - 0,86 - O.5
2,50 - 6% O,48% 81,87% 83,2%
13,76% 2% 4% - 1%
2.2.8 pH
Según Lorenzo Basurto Rodríguez [6], “El pH de una solución al 1% de goma
de Tara está entre 5,0 y 7,0. Las soluciones de goma de Tara tienen una acción de
buffer y son muy estables a pH de 4 a 10,5. El método preferido para preparar una
solución con un pH muy bajo o muy alto es preparar una solución con un pH de 8 y
entonces ajustar el pH a tan alto como mayor de pH 11 o a tan bajo como pH 1. La
hidratación más rápida ocurre entre el pH 7,5 y 9.”
2.2.9 Compatibilidad
Según Lorenzo Basurto Rodríguez [6], “La Goma de Tara es un polímero no
iónico compatible con la mayoría de otros hidrocoloides vegetales como la goma
guar, tragacanto, karaya, arábiga, el agar, alginatos, carragenatos, goma de
algarrobo, pectina, metilcellulosa y carboxy-metilcellulosa. La Goma de Tara también
es compatible con casi todos los almidones químicamente modificados, almidones
crudos, celulosas modificadas, polímeros sintéticos, y proteínas solubles en agua.
Algunas sales multivalentes y solventes miscibles en agua alteran la hidratación y la
viscosidad de soluciones de goma de Tara y producen geles. El ion del borato inhibirá
la hidratación de goma de Tara.
2.3 PRINCIPALES IMPORTADORES DE TARA EN POLVO

Según Primo De la Cruz Lapa [3], los principales importadores de tara en polvo
son: transmarcon NV o Omnichem S.A., Unipektin AG., Industria Chimica Legno SPA.,
H & P Export., Pilar River Place Corp., S. Golman GMBH & CO., LMF Bioguimica SPA.,
Richard & Frappa, Mitsui and Co Ltd., Sochim International S.p.A., Worlee Chemie
GMBH Occ., Chart Corporation Inc., Atomergic Chemetals Corp., Suffern Chemical.,
Isochem S.A., Ets Arnaud S.A., Tannin Co., etc.
2.4 ANÁLISIS QUÍMICO DE LA TARA
17
Según Primo De la Cruz Lapa [3], éstos se realizaron sobre:
a) Frutos (vaina y semilla).
b) Semillas.
c) Gomas o hidrocoloides.
d) Germen.
e) Cáscara.
Y la composición química son los siguientes: humedad, proteína, extracto etéreo,
cenizas, carbohidratos y fibra bruta. Los carbohidratos se determinan por diferencia,
habiéndose comprobado su porcentaje por otros métodos como azúcares totales y
fibra dietética.
2.4.1 Humedad: El contenido de humedad se expresa por la pérdida de peso de la

muestra bajo condiciones de temperatura y presión.
2.4.2 Proteína: El porcentaje de proteína se determinó empleando el método Kjeldhal,

utilizando como catalizador selenio; factor de conversión de proteínas 6,25.
2.4.3 Extracto etéreo: Se determinó por el método Boxhlet en un tiempo de extracción

de 6 horas.
2.4.4 Cenizas: Se determinó por el método de incineración a la temperatura de 550

ºC por 6 horas.
2.4.5 Fibras brutas: Es el residuo orgánico lavado y seco que queda después de hervir
sucesivamente el material con H2SO4 y NaOH, y finalmente convertirlo en
ceniza.
2.4.6 Carbohidratos: Se determina por diferencia de los análisis de humedad,

proteína, cenizas, fibra bruta y extracto etéreo.
2.4.7 Azúcares totales: Se utilizó el método volumétrico de Lane Eynon que consiste
en agregar la solución hidrolizada de goma a un volumen determinado de
solución de Fehling, a fin de reducir todo el ión cúprico o cuproso.
18
2.4.8 Fibra dietética: La muestra es gelatinizada y digestada enzimáticamente con
proteasa y amiglucosidasa para remover la proteína y el almidón. Se agrega
cuatro volúmenes de 60 ml de etanol al 95% para precipitar la fibra soluble. El
precipitado es filtrado, secado y pesado.
Tabla Nº 07: Análisis químico en los frutos (vainas y semillas).

HUMEDAD 11.70%
PROTEÍNAS 7.17%
CENIZAS 6.24%
FIBRA BRUTA 5.30%
ESTRACTO ETÉREO 2.01%
CARBOHIDRATOS 67.58%
TANINOS(vainas) 62%
Fuente: Primo De la Cruz Lapa, “Aprovechamiento Integral y racional de la Tara” Revista del Instituto de
Investigación de la Facultad de Ingeniería Geología, Minera, Metalurgia y Geografía - Universidad San
Marco 2004.
Tabla Nº 08: Análisis químico de la semilla.

HUMEDAD 12.01%
PROTEÍNAS 19.62%
CENIZAS 3.00%
FIBRA BRUTA 4.00%
Marco 2004.
Tabla Nº 09: Análisis químico de las gomas o hidrocoloides.

HUMEDAD 13.76%
PROTEÍNAS 2.50%
CENIZAS 0.53%
19
FIBRA BRUTA 0.86%
CARBIHIDRATOS 81.87%
AZÚCARES TOTALES 83.2%
Marco 2004.
Tabla Nº 10: Análisis químico del germen:
HUMEDAD 11.91%
PROTEÍNAS 40.22%
CENIZAS 8.25%
FIBRA BRUTA 1.05%
CARBIHIDRATOS 25.66%
Marco 2004.
Tabla Nº 11: Análisis químico de la cáscara:

HUMEDAD 10.44%
PROTEÍNAS 1.98%
CENIZAS 3.05%
FIBRA BRUTA 1.05%
Marco 2004.
2.5 PROGRAMACIÓN EXTREMA
2.5.1 CONCEPTO
20
Según Ron Jeffries, Ann Anderson, Chet Hendricrickson [8], “La Programación
Extrema es una disciplina de desarrollo de software con valores de sencillez,
comunicación, retro alimentación y coraje. Nos centramos en los papeles de cliente,
administrador y programador y acuerdo clave derechos y responsabilidades a las
personas en esas funciones”.
Según William C. Wake [9], “La Programación Extrema (XP) es un nuevo enfoque
de peso ligero para el desarrollo del software, XP utiliza la información rápida y de
gran ancho de banda de la comunicación a fin de maximizar el valor entregado, a
través de una inspección sobre el cliente, un enfoque particular de planificación, y
probando constantemente”.
Según Michele Marchesi, Giancarlo Succi, Don Wells, Laurie Williams [10],
para algunas personas “La Programación Extrema (XP) es un nuevo juego de reglas,
para otros esto es un juego humanista de valores, y esto a la vez es una simplificación
excesiva muy peligrosa”
Según Kent Beck, Martin Fowler [11], “XP es una metodología ágil, eficiente, y de
bajo riesgo, flexible, predecible, científico, y una manera divertida de desarrollar
software. XP es una disciplina de desarrollo de software Se trata de una
disciplina, porque hay ciertas cosas que tienen que hacer para estar haciendo
el proyecto si usted no accede a lo que él decide, usted no esta en extremo:
final del debate”
2.5.2 ¿CÓMO EMPIEZO CON XP?

La forma más obvia para iniciar la programación extrema (XP) es con un nuevo
proyecto. Comienza con recoger historias de usuario y conducir soluciones para
cosas que parecen de alto riesgo.
Programe una reunión de planificación para acordar la liberación. Invite a los

clientes, desarrolladores y administradores para crear un calendario en el que todo
el mundo esté de acuerdo. Comience su desarrollo iterativo con una reunión de
planificación. La mejor manera de empezar XP es tomarse un buen tiempo buscando
21
en la actual metodología de software que usa y averiguar lo que se está llevando
hacia abajo.
Gráfico Nº 07: Proyecto de la Programación Extrema
Fuente: Extraído de la página http: // www.extremeprogramming.org/map/project.html.
2.5.3 ROLES DE LOS INTEGRANTES DE PROGRAMACIÓN EXTREMA
A. El papel del cliente

Según Ron Jeffries, Ann Anderson, Chet Hendricrickson [8], “El cliente elige lo que
va a entregar, decide qué hacer primero y qué aplazar, y define las pruebas para
demostrar que el sistema hace lo que necesita”.
El equipo será más eficaz si el cliente permanece en el lugar y esté presente con el
equipo, a tiempo completo. El cliente, tiene la responsabilidad fundamental de elegir
las historias de elementos más valiosos, de más alto valor comercial y él especifica las
pruebas que muestran si las historias se han aplicado correctamente.
Según William C. Wake [9], el cliente tiene cinco trabajos importantes durante la
iteración:
1. Responder a las preguntas
2. Escribir las pruebas de aceptación.
3. Ejecutar las pruebas de aceptación.
22
4. Dirigir la iteración y un trabajo (después de varias iteraciones), cuando la
entrega está lista.
5. Aceptar la entrega.
B. El papel del programador

Según Ron Jeffries, Ann Anderson, Chet Hendricrickson [8], “Los programadores
analizan, diseñan, prueban el programa, e integran el sistema. Los programadores
estiman la dificultad de todas las historias, y realizan el seguimiento del ritmo al que
puede ofrecer las historias para el cliente”.
Según Kent Beck, Martin Fowler [11], “El programador es el corazón de XP. En
realidad, si los programadores siempre pueden tomar decisiones que
cuidadosamente equilibrados a corto plazo y prioridades a largo plazo, no habría
necesidad de ningún otro personal técnico en el proyecto, además de los
programadores. Por supuesto, si el cliente no tienen una necesidad imperiosa de
software para mantener el negocio funcionando, no habría necesidad de los
programadores, por lo que no hacer, para obtener demasiado grande encabezada
por haber sido vital el programador”
C. El papel del Tester

Según Extreme Programming [10], “Dado que una gran cantidad de pruebas
recae sobre la responsabilidad de los programadores, el papel del probador en un
equipo de XP está realmente centrado en el cliente. Que es responsable de ayudar
a los clientes a escoger y escribir las pruebas de funcionalidad. Si las pruebas
funcionales no son parte de la integración, que es responsable de ejecutar las
pruebas funcionales y la publicación periódica de los resultados en un lugar
destacado”.
El Testeador de XP no es una persona independiente, dedicado a romper el sistema y humillar a los

programadores. Sin embargo, alguien tiene que correr todas las pruebas regularmente (si no puede
ejecutar las pruebas unitarias y las pruebas funcionales en conjunto).
23
D. El papel del Manager.
Según Jeffries, Ann Anderson, Chet Hendricrickson [8], “El manager hace que
el cliente y los desarrolladores estén juntos y les ayuda a combinar en el correcto
funcionamiento del equipo”.
Cuando se trata del proceso de planificación, diseño, ensayo, codificación, en la

liberación, los jefes de proyectos no hacen ninguna de estas cosas directamente. El
jefe de proyecto promoverá estas cosas por hacer, coordinar las tareas, e informará
los resultados.
Como jefe de proyecto, promoverá una reunión. En una sesión stand-up un poco
antes de la liberación del tiempo planificación. Si hay un acuerdo general, el gerente
debe ir en la cabeza. Si hay conflictos en la programación, ponerse de acuerdo con
los miembros del equipo y encontrar una fecha adecuada. Si es necesario, cambiar
una cita en conflicto.
Según William C. Wake [9], “El jefe de proyecto tiene varios trabajos importantes:
frente a terceros, forma el equipo, obtiene los recursos, gestiona el equipo, y maneja
los problemas del equipo”.
2.5.4 FASES DE PROGRAMACION EXTREMA

Según Extreme Programming [12], define 4 fases iterativas en los cuáles definen
su proceso.
A. Planificación.
B. Diseño.
C. Código.
D. Prueba.
A. PLANIFICACIÓN.
Según DSIIC [13], ésta es la planificación de historias que realizamos al inicio del
proyecto, tras estudiar el proyecto y mantener conversaciones con el cliente. De esta
redacción inicial de historias de usuario se realizó una planificación inicial y
posteriormente fue cambiada a lo largo del proyecto. Algunas de estas historias
24
fueron eliminadas o cambiadas, a medida que cambiaban los requisitos del cliente,
se tenía una concepción más clara del proyecto.
Para poder guiarnos de una manera sencilla, construimos una tabla de Actividades,
Tareas, Artefacto, Técnica, Participantes, en el cual nos indica específicamente que
pasos uno debe realizar en el transcurso del proyecto, en la fase de planificación.
25
Tabla Nº 12: Tabla de actividades, Tareas, Artefacto, Técnica, Participantes.
Actividad Tareas Artefacto Técnica Participantes
A1. Exploración del T1. Explorar las posibilidades de la arquitectura del sistema. Esquema del Lluvias de ideas. Cliente,
sistema. sistema manager y
programador.
T2. Elegir tecnologías que serán utilizados en el sistema. Herramientas Experiencia Cliente,
de desarrollo propia del manager y
programador. programador
A2. Planificación T1. Escribir historias de usuario que serán incluidos en el proyecto. Historias de Entrevista con el Cliente y
inicial. usuario. cliente Programador.
T2. Realizar un calendario de actividades detallado (dentro de Calendario de Programador.

una iteración). actividades.
A3. Planificación T1. Estimar la prioridad y velocidad de las historias de usuario. Historias de Lluvia de ideas. Equipo XP
por iteraciones. usuario
seleccionadas.
T2. Romper las historias de usuario en tareas. Tareas de Lluvia de ideas. Programador y
Ingeniería. manager
A4. Planificación T2. Definir un conjunto de características necesarias para la Pequeña Entrevista con el Cliente,
por entregas. primera entrega. liberación cliente Manager,
Fuente: Elaboración propia
26
DESCRIPCION DE LAS TAREAS
A1. EXPLORACIÓN DEL SISTEMA.
T1. Explorar las posibilidades de la arquitectura del sistema.

Se prueba la tecnología y se exploran las posibilidades de la arquitectura
del sistema construyendo un prototipo, los clientes plantean a grandes rasgos
los requerimientos del sistema, es decir algunas especificaciones que son de
interés para el proyecto.
T2. Elegir tecnologías que serán utilizados en el sistema.

Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas,
tecnologías y prácticas que se utilizarán en el proyecto de esta manera se
obtienen las posibilidades de la arquitectura
A2. PLANIFICACIÓN INICIAL.
T1. Escribir historias de usuario que serán incluidos en el proyecto.

Se crean a partir de la documentación e información obtenida durante las
entrevistas y reuniones con el cliente. El cliente participa activamente en la
redacción de las historias de usuario, de hecho lo normal es que el cliente sea
quien redacte las historias de usuario,
T2. Realizar un calendario de actividades detallado (dentro de una iteración).

EL programador está encargado de desarrollar el calendario en el cual se
detallan el tiempo que va tomar cada iteración del proyecto.
A3. PLANIFICACIÓN POR ITERACIONES.
T1. Estimar la prioridad y velocidad de las historias de usuario.

Una vez creadas las historias de usuario hemos de asignarles un valor (una
prioridad) a cada historia basándonos en los valores generales del negocio,
27
respecto de la característica o la función, mientras que los programadores
asignan puntos a la dificultad de cada historia de acuerdo a ciertos criterios de
evaluación. El cliente tiene que prepararse para responder a la pregunta "¿Qué
te gustaría aplicar en primer lugar? Las historias suelen mezclar las prioridades,
las cuales pertenecen a cada iteración. Usando la velocidad del proyecto
controlaremos que todas las tareas se puedan desarrollar en el tiempo del que
dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4
iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente
un nuevo "Release Plan".
T2. Romper las historias de usuario en tareas.

Se realiza porque se necesita unidades más pequeñas para realizar un
seguimiento de las historias de usuario, es mejor para los programadores
inscribirse para las pequeñas tareas y así darles la oportunidad de expresar sus
especialidades. Cada tarea tiene una duración ideal de 1 a 3 días. Si bien a
menudo es útil disponer de un programador responsable que vea una historia
hasta su terminación,
A4. PLANIFICACIÓN POR ENTREGAS
T3. Definir un conjunto de características necesarias para la primera entrega

Se toman decisiones de desarrollo y de negocios, se negocia un
cronograma que será cumplido por todos. Es decir se define los conjuntos de
historias de usuario a implementar en cada iteración así como también sus
respectivas fechas de entrega con sus respectivos costos de implementación.
28
A.1 ESCRIBIR LAS HISTORIAS DEL USUARIO (USER HISTORIES)
Según DSIIC [13], las historias de usuarios están formadas por dos
componentes. La escritura en la tarjeta es la primera. Se recomienda escribir la
historia en tan sólo un par de frases en una tarjeta y que apunta a toda la
documentación acreditativa. El segundo componente, y el más importante, son
las conversaciones que tendrá lugar entre el cliente y los programadores a lo
largo de la vida del proyecto. Estas conversaciones serán capturadas como
documentación adicional que se adjunta a la historia.
Tabla Nº 13: Formato de Historia de Usuario.

Historia de Usuario
Número: Usuario:
Nombre historia:
Prioridad en negocio: Riesgo en desarrollo:
(Alta / Media / Baja) (Alta / Media / Baja)
Puntos estimados: Iteración asignada:
Programador responsable:
Descripción:
Observaciones:
Fuente: Obtenido del Ejemplo de desarrollo de Software utilizando la metodología XP,
DSIIC, universidad politécnica de Valencia ,2006.
El cliente, comentará de cómo el sistema será utilizado. Los programadores

escuchan y hacen preguntas para entender. Ahora, los clientes, escribe la
historia, con sus propias palabras, en una sola tarjeta. Si la historia es demasiado
grande, solo escribe el núcleo esencial. Cada historia del usuario es una breve
descripción del comportamiento del sistema, desde el punto de vista del usuario
del sistema. En XP, el sistema está totalmente especificado a través de historias.
A.1.1 Las historias deben ser completadas entre una y dos semanas
Según Kent Beck, Martin Fowler [11], ellos recomiendan tomar historias de
usuario entre uno y cinco semanas para la programación. Hemos acortado a
un máximo de dos semanas, pero realmente depende de usted. Si una historia
calcula que llevará más tiempo, esto es una señal de que debe separarlas en
29
pequeñas historias. Si es inferior a una semana, trate de combinarla con otras
pequeñas historias.
A.1.2 Las historias deben ser comprobables

Según Kent Beck, Martin Fowler [11], al final de cada iteración, usted debe
probar no sólo que la historia se ha terminado si no que también funcione. A
veces las pruebas automatizadas pueden ser creadas y administradas por el
cliente al final de una iteración.
Al crear una historia, se necesita tasar una prioridad, riesgo, tipo, interfaz, o
desarrollo del lado del servidor y sus dependencias. No se recomienda que las
historias dependan el uno del otro, pero esto a veces es imposible de evitar en
el desarrollo web.
A2. PROPONER REUNIONES PARA CREAR EL PLAN DE LIBERACIÓN (RELEASE

PLAN).
Según Jeffries, Ann Anderson, Chet Hendricrickson [8], el propósito del plan
liberación XP es primordial y continúo en la planificación del círculo de vida de
XP. No hay plan que pueda predecir el futuro perfectamente, pero la
planificación puede ayudarle a dirigir el proyecto al éxito.
Gráfico Nº 08: Circulo de Vida de XP
Fuente: Ron Jeffries, Ann Anderson, Chet Hendrickson” Instalando la programación Extrema”, 2000.
30
Nadie puede decirle exactamente, cuánto tiempo se necesitará para construir
el software. Los pasos necesarios para un plan de liberación en una reunión de
planificación son los siguientes:
 Escribir historias suficientes para definir un producto exitoso.

 Realice una exploración necesaria.
 Estimar la dificultad de aplicación de cada historia.
 Estimación de la velocidad de ejecución de cada historia.
 Elija historias para la primera versión basada en el valor del negocio y la
dificultad.
El cliente trae a la reunión todas las historias que le gustaría tener para el primer
lanzamiento. Los programadores lo dividen en pequeños grupos, rápidamente
discuten las tareas que tendrá que hacer por la historia, y se registra la
estimación.
La historia más fácil se valora con un punto. Los demás con dos, tres, y así
sucesivamente. La base de la filosofía de la liberación es que la planificación de
un proyecto puede ser cuantificado por cuatro variables; ámbito de aplicación,
recursos, tiempo y calidad. Ámbito de aplicación es cuánto se va a hacer. Los
recursos son cuántas personas están disponibles. El tiempo es cuando el
proyecto o la liberación se harán. Y calidad es lo bueno que el software y cómo
se prueba que así será.
a. Planificación de entrega creando calendario

El objetivo de la liberación de planificación es ayudar al cliente a
identificar las características del software que quieran, dar a los programadores
una oportunidad de explorar la tecnología y hacer estimaciones, y proporcionar
un sentido del calendario general para todo el mundo.
b. Planificación de la iteración
Durante la planificación de la liberación, que se examina la definición del
cliente, se considera el valor comercial de cada historia, mientras que los
programadores asignan puntos a la dificultad de cada historia. El papel del
cliente en la reunión es presentar y describir las historias de uno en uno, y los
31
programadores definen rápidamente tareas de programación para cada
historia. Cuando todas las historias se han presentado, los programadores deben
firmar el trabajo y estimar las tareas. Si hay poco o mucho por hacer sobre la
base de las historias que traen, llegando a decidir cuáles agregar o quitar.
El cliente explica una historia, los programadores hacen preguntas. A medida

que comienzan a entender la historia, los programadores piensen sobre las
tareas para ellos y luego colocan en el tablero. Luego continuar con la siguiente
historia. Cuando todas las historias se han explicado y la tarea, hay una breve
ráfaga de actividad mientras que los programadores firman y hacen una
estimación del trabajo.
c. La reunión de planificación
c1. El cliente presenta historias del usuario para garantizar que el equipo
entienda lo que va hacer.
c2. El equipo suelta una lluvia de ideas, éste paso permite a menudo al cliente
ver en que parte los programadores no entienden la historia. Los
programadores aceptan la responsabilidad para completar el trabajo. El
equipo no fuerza a nadie a hacer las tareas.
c3. Los programadores estiman su propio tiempo en que lograran completar
la tarea. Además, los programadores se sienten más comprometidos con
el trabajo que está programado.
d. Al principio, Comience con estimaciones intuitivas del Tiempo

Los clientes necesitan saber cuánto van a costar las historias con el fin de
elegir cuáles se hacen y cuales se aplazan. Los programadores evaluaran las
historias la cual facilitará esta información.
Trate de comenzar con una historia que usted puede imaginar cómo hacerlo. Si
cree que usted puede hacer una historia perfecta en una semana, le da un
punto. Si siente que puede hacerlo dos, le da dos. Si se siente que es tres, OK, le
dan tres puntos, sino considere la posibilidad de pedir el cliente de dividir la
historia en dos o más. Y nuestro consejo es que si piensa que lo podría hacer en
32
un mes, su intuición se ha convertido en demasiado difuso. Si su mejor estimación
es de cuatro semanas o más, por favor que el cliente divida la historia.
A3. HACER PEQUEÑAS LIBERACIONES

La reunión de planificación de la liberación se usa para descubrir unidades
pequeñas de funcionalidad que da un buen sentido al negocio y puede libera
al cliente tempranamente en el proyecto.
Si es posible, no espere más de dos meses para liberar una versión del software,
y la liberación después de cada par de meses. Y no significa una versión demo,
nos referimos a una versión actual que hace algo útil.
Si su cliente sabe ahora exactamente lo que quiere, y si por el momento haya
terminado pues aún va a querer la misma cosa, puede ser la primera vez en la
historia del software que esto ha sucedido. Como usted sabe lo que es fácil de
hacer y lo que es más costoso, se le hace mejor y mejores decisiones sobre qué
hacer y cuándo hacerlo.
A4. VELOCIDAD DEL PROYECTO

Como cliente, usted define la puesta en libertad de seleccionar la mejor
combinación de historias que el rendimiento del equipo sugiere que se puede
lograr. Se debe obtener más información sobre y acerca de cómo el sistema
está tomando forma, ajustar y afinar la combinación de historias que solicite.
Todo el mundo en el equipo es responsable. Si un equipo es capaz de hacer

cinco historias en una iteración y sólo dos en la siguiente, hay un problema que
necesita ser resuelto. ¿Hay menos horas de trabajo para esta iteración? Si es así,
¿por qué? ¿Todos tuvieron una semana llena de labores?
a. Medir la velocidad del proyecto.

Al comienzo del proyecto el equipo adivinará la estimación de la
velocidad. Pero tan pronto como se obtiene experiencia al hacer las historias, el
33
equipo podrá medir la velocidad real. La velocidad no es algo que este en
función del número de miembros del equipo, o de las horas de trabajo, o por
número de líneas de código o de páginas. Puede ser valorado solamente
después de varias iteraciones como una función del alcance individual que
puede ser terminada por cada miembro del equipo.
b. ¿Por qué es importante la velocidad?

Los clientes nerviosos hacen un infierno de la vida del equipo. Una
velocidad consecuente que reparte la funcionalidad de manera previsible
cada dos semanas pone al cliente a gusto. Si la velocidad no es la adecuada,
el cliente tiene la opción de aumentar el presupuesto y añadir más miembros al
equipo. Si usted va a negociar con un cliente sobre cuánto puede esperar de
un equipo, usted tiene mostrar un proyecto consecuente con la velocidad
respectiva y sacar los cálculos aproximados y actuales.
c. Un impacto imprevisible
¿Qué ocurre cuando tres personas dejan el equipo y son reemplazadas
por nuevo personal? ¿Qué sucede cuando el lenguaje de programación se
cambia? ¿Cómo afectará este cambio a la velocidad? Estos cambios sin duda
tienen un efecto. Cambios en el equipo o la naturaleza del proyecto tendrán un
impacto sobre el proyecto en formas imprevisibles. Sólo después de la medición
de una serie de iteraciones va a tener una idea clara de este impacto y puede
ser capaz de establecer una nueva velocidad para el proyecto.
A5. EL PROYECTO ES DIVIDIDO EN ITERACIONES

En XP, las emisiones se componen de iteraciones, donde cada iteración
implementa historias, que se componen de tareas, y realiza un seguimiento de
cómo muchas historias se hacen en cada iteración. Los proyectos XP se realizan
en cortas "iteraciones" de dos o tres semanas. Su misión es la de seleccionar los
trabajos que maximizan el valor del negocio concluyendo al final de la iteración.
Primera Iteración
Según DSIIC [13], la primera iteración debe ser un esqueleto del sistema en su
conjunto. En la primera iteración, probablemente vamos a hacer diez puntos,
34
en el segundo otros puntos, y así sucesivamente. Experimentado en el equipos
que ni siquiera se molestan, porque saben que las prioridades cambiarán y que
son completamente cómodos trabajando con cualquiera que sea el cliente.
Gráfico Nº 09: Iteración
Fuente: Extraído de la página Web http://www.extremeprogramming.org/map/iteration.html
A6. ASIGNAR PERSONAS EN PARES (MOVE PEOPLE AROUND).

Dos programadores que trabajan en conjunto generan más y mejor
código, que los mismos dos programadores que trabajan por separado. Ellos
pueden trabajar más tiempo sin cansancio, y cuando ellos están terminando,
las dos personas están entendiendo todo, en lugar de comprender la mitad de
todo.
La mayoría de los equipos de XP cambian de socios muchas veces al día. Pero

para algunas tareas, es probable trabajar con un solo socio principal, el cambio
se hace sólo para hacer frente a algunos problemas particulares o cuando su
pareja se ausenta. La pareja de programación trabaja en una sola tarea a la
vez. Después de completar cada tarea, la pareja se integrará en los programas
ya puestos en libertad, luego se ejecutará la unidad de todas las pruebas en
todo el sistema, asegurándose de que todos ellos funcionan a 100 %. Luego ellos
liberarán el código y las pruebas para su tarea en el repositorio.
A7. CADA DÍA INICIA CON UNA REUNIÓN DONDE TODOS ESTÉN DE PIE.
35
Tener una breve reunión una vez al día para que todo el mundo sepa que
es lo que está pasando, y qué no. Hemos detectado que las reuniones cortas
diarias tienen un valor inestimable para dar a todos una idea de lo que las otras
personas están haciendo.
Todo el mundo está en un círculo, cada persona debe ser breve y contar lo que
se hizo ayer y lo que está haciendo hoy. El objetivo de la stand-up es comunicar
los problemas, para resolverlos. Mantener la reunión breve. Todo lo que requiere
algo más que un breve anuncio debe ser suspendido a otro período de sesiones
en que sólo aquellos que estén interesados deben asistir a la reunión.
A8. REORGANIZAR XP CUANDO ÉSTA FALLA

Los programadores aprenden algunas cosas que son más difíciles de lo
que pensaba, y que algunas cosas son más fáciles. Los resultados de esta son
evidentes. Estoy seguro de que su propia historia al mirar hacia atrás sobre el
mismo: en la mayoría de los proyectos, las estimaciones son a menudo mal,
demasiado alta o demasiado baja, y las prioridades va a cambiar, incluso antes
de que comience, y mucho menos antes de llegar a el final.
B. DISEÑO
Para iniciar con el diseño, veamos la tabla siguiente:
36
Tabla Nº 14: Tabla de actividades, tareas, artefacto, técnica, participantes para diseño en XP.
Actividad Tareas Artefacto Participantes Técnica
A1. Realizar períodos T1. Reunir al equipo de desarrollo para maquetar el diseño. Esbozo del Programador Lluvia de
diseño del y cliente. ideas
de sesión para un
sistema.
diseño progresivo y
ordenado. T2. Construir una arquitectura común del diseño del sistema. Glosario de Cliente y Metáfora.
palabras y programador
diagrama de
paquetes.
A2. Usar tarjetas CRC T1. Asignar responsabilidades y colaboración a las clases. Tarjetas CRC, Programador lluvia de
ideas,
para el diseño del
sistema. T2. Ejecutar el primer caso de prueba para asegurarse de que Pruebas Programador Refactorizaci
y tester ón, métodos
funcionen los objetos o clases. unitarias
de prueba
A3. Elegir los diseños T1. Crear un prototipo de diseño que produzca un diseño simple. Prototipos del Programador Mood borrad,
más simples que
sitio en y cliente. Spike.
funcionen.
papel.
Métodos de
T2. Percibir los problemas de diseño del sistema. Pruebas Programador pruebas.
unitarias de y tester
diseño
37
DESCRIPCIÓN DE LAS TAREAS
A1. REALIZAR PERÍODOS DE SESION PARA UN DISEÑO PROGRESIVO Y

ORDENADO.
T1. Reunir a pocas personas para bosquejar el diseño.

Se reúnen pocas personas y bosquejan utilizando el UML en la pizarra o una
hoja de papel sin definir el diseño final, las sesiones deben tomar menos de
media hora. La idea es entender los objetos que participan en lo que estamos
a punto de hacer y entender la forma de aplicarlos, o cambiarlos, para llevar a
cabo la tarea.
T2. Construir una imagen común del diseño del sistema.

El diseño es la creación de una estructura que organiza la lógica en el
sistema, un buen diseño organiza la lógica de modo que un cambio en una
parte del sistema no siempre requiere un cambio en otra parte del sistema, un
buen diseño permite la extensión del sistema a los cambios en un solo lugar.
Cada proyecto de software en XP se rige por una sola metáfora global, la
metáfora sólo ayuda a todos a comprender los elementos básicos y sus
relaciones sobre el proyecto.
A2. USAR TARJETAS CRC PARA UN DISEÑO SIMPLE
T1. Convertir las historias de usuario en objetos.

Mediante las historias de usuario podemos identificar los objetos (concepto
importante del negocio), un objeto es una instancia de una clase, es decir se
utilizan estos objetos para nombrar clases.
T2. Reestructurar el actual objeto en varios objetos.

Viendo la complejidad del objeto tratado, es preferible dividir en varios
objetos, con el fin de simplificar la dificultad en el proceso de diseño.
38
T3. Asignar responsabilidades y colaboración a las clases.
Permite ver las clases como algo más que un depósito de datos, es decir
conocer el comportamiento de cada una de las clases en un nivel alto. Para así
poder identificar las responsabilidades y como colaboran con las demás clases.
T4. Ejecutar el primer caso de prueba para asegurarse de que funcionen los
objetos o clases.
Para verificar que el objeto o clases funcionen adecuadamente se somete
a la primera prueba de diseño, obteniendo como resultado objetos o clases que
cumplan con las funcionalidades del sistema.
T5. Eliminar toda duplicación de lógica en el sistema.

Frente a la duplicación de lógica, el coste de un mal diseño se convierte en
abrumadora. Usted simplemente no puede recordar todos los cambios
vinculados implícitamente que tenga lugar. No puede añadir nuevas funciones
sin romper funciones existentes.
A3. ELEGIR LOS DISEÑOS MÁS SIMPLES QUE FUNCIONEN
T1. Crear un prototipo de diseño que produzca un diseño simple.

Antes de asignar la programación en pares, el diseñador gráfico creaba
prototipos del sitio en papel, que se convertían en una serie de instrucciones
para el programador de interfaz. Sí, esto representaba la maqueta de cada
página del sitio web, lo que el programador de interfaz traduciría en XSLT. Esto
sólo funciona si el diseñador tiene una profunda comprensión de la aplicación,
la funcionalidad, datos y lo que los navegadores soportan.
T2. Verificar la calidad de diseño.

En el proyecto se trabaja en parejas, utilizando el diseño más simple de
valorización para mantener el diseño de alta calidad. Integramos todo el
tiempo, para que todos podamos mejorar el código donde quiera que se
necesite mejorar. Y nos comunicamos a través del código escrito en un sentido,
de una forma estándar.
T3. Percibir los problemas de diseño del sistema.
39
El diseñador debe tener la capacidad de detectar un mal diseño en base a
su experiencia, pruebas y entre otras. Un cambio conceptual exige cambios en
muchas partes del sistema. La complejidad es otra fuente de mal diseño.
B1. BUSCAR SIMPLICIDAD

Lo que se quiere es que el sistema sea lo más simple posible, para
mantenerlo en todo momento, entonces facilitara mantener nuestro código,
esto se dará cuando:
- Ejecutan todas las pruebas.
- Expresa cada idea que usted necesita
- No contiene código duplicado
- Tiene el número mínimo de clases y métodos
Si encuentra algo que es complejo reemplácelo con algo sencillo.

Siempre es más rápido y barato reemplazar un código complejo
tempranamente.
B.2. ESCOGER UN SISTEMA DE METÁFORAS.

El uso de metáforas adecuadas en el diseño de un interfaz, facilita y
acelera el aprendizaje del funcionamiento de un producto. Las metáforas
ayudan al usuario a entender más rápidamente cómo moverse por un producto
interactivo.
B.3. USAR TARJETAS CRC PARA EL DISEÑO POR SESIONES

Se eligen los diseños más simples que funcionen, el mayor valor de las
tarjetas CRC es permitir a las personas romper con el procedimiento del modo
de pensamiento y de apreciar más cabalmente la tecnología. Las tarjetas CRC
permiten equipos de todo el proyecto para contribuir a la concepción. Cuanto
mayor sea el número de personas, será mayor el número de buenas ideas
incorporadas que pueden ayudar a diseñar el sistema.
No suele ser necesario escribir la tarjeta completa; los participantes se

familiarizan rápidamente con el propósito de cada clase. Las tarjetas CRC se
utilizan para representar objetos. La clase de objeto puede ser escrito en la parte
40
superior de la tarjeta, las responsabilidades enumeradas en el lado izquierdo, las
clases se enumeran a la derecha de cada responsabilidad.
Los participantes por lo general sólo necesitan unas pocas tarjetas con el
nombre de la clase. El Diseño de alternativas se puede explorar rápidamente
simulando el diseño que se propone. En la reunión CRC alguien simula el sistema
discutiendo los mensajes intercambiados entre objetos. Limitar a 1 ó 2 personas
de pie exponiendo, mientras los demás permanecen sentados. Cuando una
persona se sienta otro puede levantarse. Esto funciona para los períodos de
sesiones en que suele salirse de las manos, que a menudo sucede en equipos
bulliciosos.
B.4. CREAR SOLUCIONES QUE REDUZCAN RIESGOS

Crear soluciones mediante spike solución para averiguar las respuestas de
los problemas de diseño. Un spike es una solución muy simple al programa para
explorar posibles soluciones. Construir un sistema que sólo aborda el problema
objeto y hacer caso omiso de todas las demás preocupaciones.
El objetivo es reducir el riesgo de un problema técnico o aumentar la fiabilidad

de una historia de usuario. Cuando una dificultad técnica amenaza con
detener el desarrollo del sistema, es mejor poner un par de desarrolladores sobre
el problema y en una o dos semanas se reducirá el riesgo potencial.
B.5. NO AGREGAR FUNCIONALIDADES TEMPRANAMENTE

Mantener el sistema despejado con cosas extras, suponiendo que se
utilizaran más tarde. Sólo se cuenta con el 10% de material extra que nunca se
utilizará, por lo tanto se está perdiendo el 90% de su tiempo empleado cosas
extra.
Si estas pensando añadir la funcionalidad ahora en lugar de más tarde, ver

exactamente cómo se debe agregar, o cómo se haría mucho mejor el sistema
al añadir funcionalidades mas tarde.
B.6 REFACTORIZAR DONDE Y CUANDO SEA POSIBLE

41
Refactorización es el proceso de mejorar la estructura del código sin dejar
de preservar su función. Incluso si pasamos mucho tiempo delante del diseño. A
través de refactorización se centran en un diseño simple, se centra en un valor
del negocio, sin tener que ser acorralado por una pronta decisión que resulta
ser incorrecta. Refactorización es un proceso formal (pero no difícil) que le
permite cambiar el código sin romper. Cada paso de Refactorización es
reversible, por lo que puede probar las cosas y si no te gusta el resultado, puedes
retroceder. Esto le permite tener una curiosidad, experimentación, aprendizaje
y actitud con respecto al código.
Una de las razones de las personas que no cambian el código actual es que
temen que van a romper. Cuando haya terminado con un poco de
refactorización, ejecute de nuevo. Si hay pausa, ver qué ha sucedido. Lo más
probable es que usted rompió algo, aunque a veces encuentran la prueba que
necesitaba cambiar para que coincida con el refactorización.
C. CODIFICACIÓN
Gráfico Nº 10: Desarrollo
Fuente: Extraído de la página http://www.WebSites\ExtremeProgramming\rules\squential.htm
42
Tabla Nº 15: Tabla de actividades, tareas, artefacto, técnica, participantes en la fase de codificación.
A1. Establecer T1. Definir un estilo de trabajo entre el par de programadores. Normas de Practicas de XP. Programadores.
Normas de trabajo del
Codificación equipo.
T2. Definir un estilo de codificación para todo el equipo de XP. Lista de los Notación de Equipo de XP.
nombres de código.
las variables
A2. Programación T1. Programar las tareas de ingeniería por cada par de Código Notación de Programador.
en pares. programadores. fuente inicial, código.
T2. Codificar primero la prueba unitaria automatizada de cada Pruebas Refactorización. Programador,
método o clase a la vez. unitarias. tester y cliente
A3. No realizar T1. Mantener una semana de 40 horas, para tener un nivel sostenible Horario de Practicas de XP. Programador y
horas extras. de productividad. trabajo tester.
T2. Devolver las tareas de las historias que no se pudo desarrollar en la Tareas de Refactorización Programador
primera iteración y dejarlo para la siguiente iteración. ingeniería
A4. Propiedad T1. Compartir el código entre el equipo. Código Propiedad Equipo de XP.
Colectiva del fuente colectiva.
código. colectivo.
43
T2. Modificar alguna parte del código si es necesario. Pruebas Refactorización Programador y
unitarias. tester.
A5. Integración T1. Verificar la funcionalidad del código del par de programadores en Código Métodos de Programador,
continua el proyecto. fuente pruebas. Tester
mejorado,
T2. Integrar el código al proyecto. Pruebas de Métodos de Programador y

integración pruebas. tester.
44
DESCRIPCION DE LA TAREAS
A1. ESTABLECER NORMAS DE CODIFICACIÓN.
T1. Definir un estilo de trabajo entre el par de programadores.

En XP, la programación en pares es la práctica de tener dos personas
trabajando juntos en toda la producción del código. Ellos hacen esto, como
socios de pleno derecho, turnándose, escribiendo y observando, para
proporcionar el diseño constante y la revisión del código.
T2. Definir un estilo de codificación para el par de programadores.

Es conveniente elegir un estilo de programación para el par de
programadores para que posteriormente no ocurran problemas en la
integración de código y el desarrollo de las pruebas unitarias.
T3. Definir un estándar de codificación para todo el equipo de XP.

El estándar definido por todo el equipo debe ser adoptado
voluntariamente, el estándar deberá hacer hincapié en la comunicación de
todos los pares de programadores que lo conforman con el objetivo de no
duplicar líneas de código, para que posteriormente no ocurran problemas en la
integración de código.
A2. PROGRAMACIÓN EN PARES.
T1. Programar las tareas de ingeniería por cada par de programadores.

El programador implementa una tarea de ingeniería (la unidad más
pequeña de la programación) lo cual será integrado con el resto del sistema
mediante la refactorización.
T2. Programar para reducir la probabilidad de errores.

El desarrollo del sistema es impulsado por las pruebas, una vez que corran
todos los casos de prueba para el código implementado se estará añadiendo
valor al sistema.
45
T3. Codificar primero la prueba unitaria automatizada de cada método o clase
a la vez.
Pregunte primero ¿Cuales son los casos de prueba para esta tarea? Una vez
definido los casos de prueba verifique la estructura de algunos de los actuales
casos de prueba que podrán ser aplicados para un determinado método o
clase, una vez refactorizando el código de la clase estará sometido
necesariamente a una serie de casos de prueba, lo cual nos garantiza si es
posible integrar la clase al resto del sistema.
A3. NO REALIZAR HORAS EXTRAS.
T1. Mantener una semana de 40 horas, para tener un nivel sostenible de

productividad.
Evitar las Horas extraordinarias ya que es un síntoma de un grave problema
en el proyecto, Si vienes el lunes y dices, "Para cumplir nuestras metas, tendremos
que trabajar hasta tarde otra vez", entonces usted ya tiene un problema que no
puede ser resuelto por trabajar más horas, por lo cual debe optar por, “Quiero
estar fresco y ansioso cada mañana, cansado y satisfecho cada noche”.
T2.Devolver las historias que no se pudo desarrollar en la primera iteración y

dejarlo para la siguiente iteración.
Para evitar las horas extras de programación se debe cumplir con las 40 horas
por semana, en caso de no terminar las responsabilidades asignadas de las tares
de cada historia de usuario, entonces las tareas se desplazan a la siguiente
iteración.
A4. PROPIEDAD COLECTIVA DEL CÓDIGO.
T1. Compartir el código entre el equipo.

El los días antiguos el código era propiedad de nadie, si alguien quería
cambiar algo de código lo hacían para satisfacer sus propios fines, si encajaba
bien con lo que ya existe o no, el resultado era un caos especialmente con los
objetos que lo relacionaban entre una línea de código aquí y una línea de
46
código por ahí no era fácil de determinar estáticamente, el código creció
rápidamente, pero también creció rápidamente inestable. Para obtener el
control de esta situación la propiedad colectiva del código proporciona al
equipo el código fuente del proyecto.
T2. Modificar alguna parte del código si es necesario.

Usted vea la posibilidad de modificar alguna parte de código del sistema
con el fin de mejorar y de evolucionar el diseño mismo del sistema.
T3. Asumir la responsabilidad del sistema como un todo.

En XP, todo el mundo asume la responsabilidad de la totalidad del sistema.
No todo el mundo conoce cada parte igual de bien, aunque todo el mundo
sabe algo acerca de cada parte. Si una pareja está trabajando y que ve una
oportunidad para mejorar el código, sigue adelante y mejora, hace su vida más
fácil.
A5. INTEGRACIÓN CONTINÚA.
T1. Verificar la funcionalidad del código del par de programadores en el

proyecto.
Verificar la funcionalidad del código entre el par de programadores, con
algunos casos de prueba ejecutados en un 100% antes de ser sometidos a la
integración y así disminuir los conflictos en la integración de código.
T2. Integrar el código al proyecto.
Usted no puede integrar posiblemente después de sólo unas pocas horas de

trabajo. La integración toma demasiado tiempo y hay demasiados conflictos
aumentando la posibilidades de romper algo accidentalmente, para ello debe
estar ejecutar pruebas constantemente, refactorizar para generar pieza más
pequeña de código y hace reducir la posibilidad de conflictos, entonces tal vez
podría integrar en unas pocas horas, además si no se integra rápidamente
entonces la oportunidad de los conflictos aumenta y el costo de integración
sube.
C.1. EL CLIENTE ESTÁ SIEMPRE DISPONIBLE

47
Uno de los pocos requisitos de programación extrema (XP) es tener al
cliente disponible. No sólo para ayudar al equipo de desarrollo sino también
para ser parte del equipo. Todas las fases de un proyecto en XP requieren la
comunicación con el cliente, preferentemente cara a cara. Es mejor destinar
uno o varios clientes al equipo de desarrollo. Los clientes ayudan asegurando
que la mayor parte de la funcionalidad deseada del sistema es cubierta dentro
de las historias.
C.2. EL CÓDIGO DEBE SER ESCRITO SIGUIENDO ESTÁNDARES

Estamos todos de acuerdo con una norma de codificación. De esta forma
se garantiza que el código se comunica con la mayor claridad posible y apoya
nuestra responsabilidad compartida en materia de calidad de todo el mundo.
Sangría. Utilice un formato compatible. Todo el tiempo con la misma anchura,

el mismo soporte de colocación. Siempre el guión subordinado en el código,
incluso si no está usando Python, donde tiene que ser.
Capitalización. Coherente uso de mayúsculas prácticas. Siga lo que es típico en

su idioma, incluso si usted está más familiarizado con ella. Capitalizar las clases.
Comentando. Utilice escasos comentarios. Al centrarse en claro, la intención de

revelar el código es más valiosa que todos los comentarios que usted puede
escribir. Escribir cuando usted los necesita para explicar una optimización, para
explicar algo que no se puede simplificar, y así sucesivamente. No escriba
cuando en realidad no ayuda.
Tamaño del método. Mantenga métodos pequeños. Si el código no puede ser

visto en una pantalla, es demasiado largo. Mientras estás en ello, evitar los
grandes bloques de comentario al comienzo del método, que oculta lo que
importa, el actual código.
Nombres. Hay otro ámbito de la normalización que desea trabajar en todo el
proyecto, y estos son los nombres propios. A pesar del formato de nombre serán
compatibles, los nombres de las cosas que puede ser coherente también. Por
ejemplo es útil si lo llaman a un método totalSalary y yo lo llamo totPay. Tenemos
48
que poner el nombre de las cosas de manera similar a fin de que podamos
encontrar, por lo que podemos entender rápidamente cuando los veamos.
El código debe estar formateado de acuerdo a normas de codificación. Las

Normas de codificación debe mantener el código coherente, fácil de leer y
refactorizar que servirá para todo el equipo. Estas prácticas aumentan su
productividad y la calidad de lo que produce.
C.3. PRIMERO SE CREA LA PRUEBA UNITARIA

Los programadores en las pruebas tienen la posibilidad de romper,
utilizando pruebas automatizadas que debe ejecutar perfectamente todo el
tiempo.
a. Prueba poco a poco

Crear una clase de prueba. Nombre de tal forma como para evocar la
clase o el proceso se le prueba. Si está probando la clase Scrutinizer, llame a la
clase de prueba ScrutinizerTestCase.
Se puede encontrar la necesidad de añadir ejemplos a la creación de métodos

de prueba para la clase de ayuda en la configuración. Asegúrese de probar
este código, como un error en este tipo de código puede ser muy difícil de
depurar más tarde. Al ejecutar la prueba es probable que falle. Si no es así, ya
está. Todo lo que se deja de hacer es puesta en libertad. Modificar el modelo
de código y repetir los pasos cuatro y cinco hasta que la prueba se ejecuta con
éxito. Libere el modelo de código y el caso de prueba
b. ¿Cómo se prueba cuando usted tiene una base de datos adjunto?

Hay un par de cosas que preocupa cuando las pruebas son con una base
de datos adjunta. En primer lugar puede ser el rendimiento. Necesitamos
pruebas unitarias para ejecutarlas mucho más rápido, por lo que podemos
hacer nuestro código de pruebas en el ciclo de liberación lo más pronto posible.
Si los lotes de pruebas unitarias se basan en la base de datos, que pueden
retrasar las pruebas. Por lo tanto es menos frecuente el código liberado por los
49
programadores, lo que aumenta las colisiones al administrar el código, que
frena aún más.
C.4. TODO CÓDIGO ES PROGRAMADO EN PARES.

Cuando una pareja de programadores están trabajando, su código pasa
por tres fases. Estas fases son:
a) Local. Esta es la primera fase de desarrollo. La pareja acaba de comenzar el

trabajo y sus cambios no están disponibles para cualquiera de los otros
desarrolladores.
b) Libere candidatos. Los programadores han terminado su tarea, y estamos

dispuestos a iniciar el proceso de liberación de sus cambios a los otros
programadores.
c) Liberando al repositorio. Esta es la actual versión oficial del código. Este

código está garantizado al trabajo. Es decir, todas las pruebas unitarias se
ejecutan en un 100 %. Liberados los cambios que estén disponibles para
todos los demás programadores.
A lo largo del día, un pareja de programadores XP liberan cambios por lo menos

una vez y posiblemente muchas más veces. Mientras tanto, otras parejas
también han venido haciendo los cambios y la liberación de ellos, existe una
probabilidad de que se han cambiado las mismas cosas que hizo. Usted
necesitará un enfoque de la liberación de los cambios que mantengan las cosas
funcionando sin dificultades. En el proceso le recomendamos que va de este
modo:
a) Siempre empezar con todos los código liberados. Esto asegura que usted
está comenzando con las últimas y mejores versiones de todo.
b) Escribir pruebas que corresponden a su tarea. (Escriba la prueba en primer
lugar).
c) Ejecutar todas las pruebas unitarias.
50
d) Determinar cualquier prueba unitaria que se rompan. Desde que se inició
con el código liberado, las únicas pruebas que deben salir son los que acaba
de escribir.
e) Cuando todas las pruebas unitarias están ejecutadas en un 100 % y
realizadas por la misma pareja llegan a ser liberados código.
f) Si el código liberado se modificó mientras estaban haciendo los cambios,
comparar las diferencias entre sus cambios y la liberación del código.
g) Una vez que se han integrado todos los cambios necesarios, ejecute las
pruebas unitarias para integrar en la máquina. Debe correr al 100%
h) Cuando las pruebas unitarias realizadas en un 100 %, libera todo el código
es decir, hace que el código se integre en la versión oficial.
La mejor forma de programación en pares, es sólo sentarse uno al lado del otro
al frente del monitor. Una persona piensa en los atributos y métodos que se está
creando, mientras que otros piensan estratégicamente acerca de cómo el
método encajará dentro de la clase. Se necesita tiempo para acostumbrarse a
la programación en pares, por lo que no se preocupe si se siente incómodo al
principio.
C.5. CADA PAREJA DE PROGRAMACIÓN INTEGRA EL CÓDIGO AL MISMO TIEMPO

(INTEGRACIÓN CONTINÚA)
Un buen equipo de XP integra y pone a prueba todo el sistema muchas
veces al día. Vamos a dividir el sistema. Debe tener sólo unos pocos meses
llevando a cabo todas las pruebas de nuestro trabajo. Luego, cuando todo
está escrito, sólo tendremos que integrar el código en una semana o así,
ejecutar algunas pruebas de aceptación, y de la liberación.
C.6. HACER EL CÓDIGO DE PROPIEDAD COLECTIVA

El uso de código es de propiedad colectiva. Cada clase y método
pertenece al equipo, y cualquier miembro del equipo puede mejorar todo lo
que necesita. El código de propiedad colectiva permite al equipo hacer un
progreso más rápido.
Una de las más importantes partes del código de propiedad colectiva en el

trabajo es el proceso de liberación de los cambios a otros programadores en el
51
equipo. El código del administrador debe detectar los conflictos y su solución
debe ser sencilla. No deben esperar una pareja modificar algo, debe sentirse
libre para seguir adelante.
Un buena pareja de programadores ahorra código con mucha frecuencia,

muchas veces al día. Si el código gestor está haciendo que desea liberar con
menos frecuencia. El Código de Propiedad Colectiva anima a todos a aportar
nuevas ideas en todos los segmentos del proyecto. Cualquier desarrollador
puede cambiar cualquier línea de código para añadir funcionalidad.
Gráfico Nº 11: Código de Propiedad Colectiva
Fuente: Extraído de la página Web http://www.extremeprogramming.org/map/code.html
C.7. NO OPTIMIZAR EL CÓDIGO SI NO HASTA EL FINAL.

Nunca trate de adivinar el cuello de botella del sistema que será. ¡Mídalo!
Hágale trabajar, hágale corregir, entonces hágalo rápidamente.
C.8. NO HACER HORAS EXTRAS.

52
Estamos seguros de que las horas extras pesadas son malas. De este modo,
una de las reglas de XP es la cuarenta horas, no trabaje más de una semana
consecutiva de las horas extras. XP incorpora la programación en un proceso
que permite a los programadores mantenerse saludable a lo largo de un
proyecto, ayudando a que el proyecto se mantenga saludable. A medida que
el proyecto, trabajo en parejas, utilizando el diseño más simple de valorización
para mantener el diseño de alta calidad. Integramos todo el tiempo, para que
todos podamos mejorar el código donde quiera que se necesite mejorar.
D. PRUEBAS
Según William C. Wake [9] “XP utiliza las pruebas de dos maneras: los
clientes desarrollan pruebas de aceptación que determinan el comportamiento
general del sistema, y los programadores crean pruebas unitarias en la
programación”.
Gráfico Nº 12: Pruebas
Fuente: Ron Jeffries, Ann Anderson, Chet Hendrickson, “Instalando la

programación Extrema” ,2000.
Hay muchas maneras diferentes para aplicar las pruebas de aceptación en su

proyecto, y los programadores pueden elegir uno. El cliente crea pruebas de
aceptación para cada historia que solicita. Las pruebas de aceptación
constituyen una prueba de existencia para la comprobabilidad de las
características solicitadas. Por último, el equipo debe tratar de tener sus pruebas
automatizadas. El usuario tiene una interfaz familiar, y los programadores
pueden escribir un pequeño programa para leer la hoja de cálculo y ejecutar
la prueba.
53
Para el proceso de pruebas, tenemos el siguiente cuadro en el cual
mencionamos cosas fundamentales en el desarrollo del proyecto.
54
Tabla Nº 16: Tabla de actividades, tareas, artefacto, técnica, y participantes en la fase de pruebas.
A1. Realizar las T1. Escribir una prueba unitaria antes de escribir el método Pruebas Uso de la Programador,
pruebas unitarias. funcional. unitarias. herramienta tester.
JUnit.
T2. Ejecutar las pruebas unitarias para todas las tareas. Pruebas Software de Programador.
unitarias. prueba JUnit.
T3. Organizar todas las pruebas unitarias. Código fuente Revisión del Programador,
de las pruebas código. tester.
unitarias.
A2. Realizar las T1. Escribir pruebas de aceptación independientes, para todas las Pruebas de Revisión de las Cliente, tester.
pruebas de historias. aceptación. historias de
aceptación. usuario.
T2. Ejecutar todas las pruebas de aceptación para todas las Resultado de Hoja de cálculo Cliente, tester.
historias. las Pruebas de para pruebas
aceptación. automáticas.
55
T3. Aprobar o desaprobar las pruebas de aceptación. Pruebas de Revisión de las Equipo de XP.
aceptación. pruebas de
aceptación.
T4. Medir el progreso de desarrollo del sistema. Estimación de Contabilizar las Equipo de XP.
progreso. historias que
pasaron las
pruebas de
aceptación.
56
DESARROLLAR LAS TAREAS DE LAS ACTIVIDADES.
A1. REALIZAR LAS PRUEBAS UNITARIAS.
T1. Escribir una prueba unitaria antes de escribir el método funcional.

Antes de escribir las pruebas unitarias, es necesario informarnos de la
existencia de la herramienta JUnit. Esta herramienta nos permite probar módulos
que componen un programa.
T2. Ejecutar las pruebas unitarias para todas las tareas.

Cuando probamos un programa, lo ejecutamos con unos datos de entrada
(casos de prueba) para verificar que el funcionamiento cumple los requisitos
esperados. Definimos prueba unitaria como la prueba de uno de los módulos
que componen un programa.
T3. Organizar todas las pruebas unitarias.

Ya que se escribe pruebas unitarias para cada método funcional, es
importante organizar estas pruebas e inclusive automatizarlas para no volver
programar estas pruebas reiteradamente.
A3. REALIZAR LAS PRUEBAS DE ACEPTACIÓN.
T1. Escribir pruebas de aceptación independientes para todas las Historias.

Las pruebas de aceptación lo realiza el cliente, y estas pruebas son escritas
para todas las Historias, en el cual se especifican los requerimientos del cliente.
T2. Ejecutar todas las pruebas de aceptación para todas las Historias.
Ejecute todos los días las pruebas de aceptación para todas las historias que
se esperó llevarse a cabo a finales de esta iteración.
T3. Aprobar o desaprobar las pruebas de aceptación.

Deje que el equipo decida que pruebas pasan y cuáles no. Esta decisión le
compete a todo el equipo de XP.
57
T4. Medir el progreso de desarrollo del sistema.
Obteniendo el número historias que pasaron las pruebas de aceptación
que el cliente realizó, se tiene un porcentaje del avance del proyecto, en el cual
se mide el progreso de desarrollo del sistema.
D.1 EL PROCESO DE PRUEBAS

La única manera de avanzar rápidamente con confianza, es tener una red
sólida de las pruebas, tanto la unidad y la aceptación, que garanticen que los
cambios en el sistema no rompen las cosas que ya se han trabajado. Las
pruebas de aceptación deben ser automatizadas. Impulse sus pruebas de
aceptación hasta el límite, en amplitud y en profundidad.
 Todo código tiene pruebas unitarias.

 Todo código pasa por pruebas unitarias antes de que pueda liberarse.
 Cuando un error es encontrado las pruebas son creadas
 Las pruebas de aceptación son ejecutadas antes de que sea publicada.
D.2. AUTOMATIZACIÓN DE LAS PRUEBAS

Los ensayos deben ser automatizados, existen muchas maneras que esto
puede hacerse. La elección concreta depende de sus programadores. Aquí
hay algunas ideas:
 Si el programa es un programa de lotes, lectura y producción de insumos

de productos, hacer una serie estándar de archivos de entrada, ejecutar
el programa, comprobar manualmente la salida una vez, y después
escribir scripts simples para comparar la prueba de salida para el bien
conocido salida.
 Utilice el truco de arriba y las listas de cualquier programa, lote o no.
 Permitir a los clientes a establecer las pruebas en su hoja de cálculo
favorita, a continuación, lee en la prueba y ejecutarlo. Algunos utilizan la
"automatización" de la hoja de cálculo para leer la información. Son
pocos en realidad los resultados de las pruebas de exportación de vuelta
a la hoja de cálculo.
58
Programadores, tienen el derecho a saber lo que se necesita. Exija a este
derecho en forma automática de pruebas funcionales. Se alegrara que usted
lo haya hecho.
Los clientes, tienen el derecho de ver el progreso en un sistema en

funcionamiento, resultado de trabajar de forma automatizada las pruebas que
usted especifique. Insista en este derecho, y ponga de su parte de proporcionar
la información necesaria.
Cuando un error es encontrado se crean pruebas para evitar que regrese. Un

error en la producción exige una prueba de aceptación por escrito. Creando
una prueba de aceptación antes de la depuración ayuda a los clientes a definir
el problema y comunicar este problema a los programadores. Los
programadores no tienen una prueba para concentrar sus esfuerzos y saber
cuando el problema es fijo.
Dado una prueba de aceptación fallada, los desarrolladores pueden crear

pruebas unitarias para demostrar el defecto de un código fuente específico. Las
pruebas unitarias falladas dan la regeneración inmediata a los esfuerzos de
desarrollo cuando el error ha sido reparado. Cuando la unidad de pruebas a
sido corrido al 100% entonces la prueba de aceptación no se puede ejecutar
de nuevo para validar el fallo o refactorizar.
PRUEBAS UNITARIAS
La creación de las pruebas unitarias ayuda al desarrollador, para considerar
realmente lo que hay que hacer. Los requisitos se establecen firmemente
exactos por medio de ensayos. No puede haber ningún malentendido, una
especificación escrita en forma de código ejecutable. También se tiene
información inmediata mientras se trabaja. A menudo no está claro cuando un
desarrollador ha acabado la funcionalidad necesaria. El ámbito de aplicación
puede ocurrir como ampliaciones y condiciones de error se consideran. Si
vamos a crear nuestras primeras pruebas unitarias entonces sabemos cuándo
se realizan, el plazo de todas las pruebas unitarias.
59
También hay un beneficio para el diseño del sistema. A menudo son muy difíciles
las pruebas unitarias de algunos sistemas de software. En estos sistemas
primeramente se construye el código y segundo las pruebas, a menudo por un
equipo totalmente diferente. Mediante la creación de su primera pruebas su
diseño se verá influido por un deseo de poner a prueba todo lo de valor a su
cliente. Su diseño reflejará este por ser más fácil de probar. Puede crear una
prueba para definir algunos pequeños aspectos del problema en la mano.
Luego de crear el código más simple hay que hacer que pase la prueba. Luego
de crear una segunda prueba. Ahora se agrega el código que acaba de ser
creada para que esta nueva prueba pase, No hasta que haya una tercera
prueba. Usted continuará hasta que no quede nada para poner a prueba. El
código creado es simple y conciso, sólo la aplicación de las características que
quería. Otros desarrolladores pueden ver la forma de utilizar este nuevo código
de la navegación por las pruebas.
PRUEBAS DE ACEPTACIÓN
Las pruebas de aceptación son creadas a partir de las historias de usuario que
son seleccionados en la reunión de planificación de iteración y se traducirá en
pruebas de aceptación. El cliente especifica los escenarios para pruebas
cuando una historia de usuario ha sido aplicada correctamente. Una historia
puede tener una o varias pruebas de aceptación.
Cada prueba de aceptación representa algunos de los resultados esperados

del sistema. Los clientes son los responsables de verificar la exactitud de las
pruebas de aceptación y la revisión de los resultados de las pruebas para decidir
cuales son de alta prioridad.
Una historia de usuario no se considerará completa hasta que ha pasado

pruebas de aceptación. Esto significa que las nuevas pruebas de aceptación
se deben crear en cada iteración.
El aseguramiento de la calidad (QA) es una parte esencial del proceso de XP.

En algunos proyectos de control de calidad es realizada por un grupo aparte,
mientras que en otros QA serán integrados en el desarrollo de sí mismo. En
60
cualquier caso XP requiere el desarrollo que tiene relación mucho más estrecha
con la garantía de la calidad.
Las pruebas de aceptación deben ser automatizadas por lo que se puede
ejecutar con frecuencia. Las pruebas de aceptación de puntuación son
publicadas en el equipo.
Tabla Nº 17: Formato de Pruebas de Aceptación

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:
Fuente: Ejemplo de desarrollo software utilizando la metodología XP, LSI-PSW-LDS
Departamento Sistemas Informáticos y Computación (DSIIC) – Universidad Politécnica
de Valencia, 2006.
61
CAPITULO III
RESULTADOS
3.1 PLANIFICACIÓN
3.1.1 HISTORIAS INICIALES PREVISTAS PARA EL DESARROLLO DEL

PROYECTO. En una primera reunión con el cliente, se definieron una
serie de historias, que son mencionadas en la tabla siguiente:
Tabla Nº 18: Historia, prioridad, riesgo, esfuerzo, iteración.

Nº Historia Prioridad Riesgo Esfuerzo Iteración
1 El actor emite una oferta de tara. ALTA MEDIA 5 1
2 El actor cotiza una compra de tara. ALTA MEDIA 5 1
3 El actor emite una proforma de venta ALTA MEDIA 5 1
de tara.
4 El actor registra compra de tara. ALTA ALTA 5 1
5 El actor registra una venta de tara ALTA ALTA 5 1
6 El proveedor oferta servicio MEDIA MEDIA 5 1
7 El actor cotiza servicios. MEDIA MEDIA 5 1
8 El proveedor proforma servicios MEDIA MEDIA 5 1
9 El Proveedor registra compra de ALTA ALTA 5 1
Servicio
10 El proveedor oferta bienes. MEDIA MEDIA 5 1
11 El actor cotiza bienes ALTA MEDIA 5 1
12 El proveedor proforma bienes. MEDIA MEDIA 5 1
13 El Proveedor registra compra de ALTA ALTO 5 2
Bienes.
14 EL Actor realiza mantenimiento de MEDIO ALTA 5 2
ofertas de tara.
15 EL Actor realiza Mantenimiento de MEDIO ALTA 5 2
proformas de venta de tara
16 EL Actor realiza Mantenimiento de MEDIO ALTA 5 2
cotizaciones de compra tara.
62
17 EL Actor consulta cotizaciones de ALTA ALTA 5 2
compra de tara.
18 EL Actor consulta proformas de venta ALTA ALTA 5 2

de tara
19 EL Actor consulta registros de venta ALTA ALTA 5 2

de tara
20 EL Actor consulta registros de compra ALTA ALTA 5 2

de tara
21 EL Proveedor realiza Mantenimiento MEDIA ALTA 5 3
de ofertas de Bienes
22 EL Proveedor realiza mantenimiento MEDIA ALTA 5 3
de cotizaciones de Bienes
23 EL Proveedor realiza mantenimiento MEDIA ALTA 5 3
de proformas de bienes
24 EL Proveedor consulta cotizaciones ALTA ALTA 5 3
de bienes
25 EL Proveedor consulta proformas de ALTA ALTA 5 3
Bienes.
26 EL Proveedor consulta registros de ALTA ALTA 5 3
compra de Bienes
de ofertas de Servicios.
de cotizaciones de Servicios.
de proformas de Servicios.
30 EL Proveedor consulta cotizaciones ALTA ALTA 5 3
de Servicios.
31 EL Proveedor consulta proformas de ALTA ALTA 5 3
Servicios.
32 EL Proveedor consulta registros de ALTA ALTA 5 3
compra de Servicios
33 El Actor y proveedor solicitan ALTA ALTA 5 1
admisión al Sistema Web.
34 El administrador emite respuesta de ALTA ALTA 5 1
admisión o rechazo.
63
35 El administrador del sistema realiza MEDIA ALTA 5 1
mantenimiento del sistema web.
36 El usuario realiza mantenimiento de MEDIA ALTA 5 1
sus datos personales.
Fuente: Elaboración propia.
a. Planificación Inicial
Usando el desarrollo del acápite 2.5.4 escribimos las historias de usuario, son
correctas y completas aplicando el tema de iteración visto en A.5
Tabla Nº 19: El actor emite una oferta de tara
Historia de Usuario
Número: 1 Usuario: Actor
Nombre historia: El actor emite una oferta de tara
Prioridad en negocio: ALTA Riesgo en desarrollo: MEDIA
Puntos estimados: 5 Iteración asignada: 1
Descripción:
El Actor (productor, acopiador, transformador o comercializador) emite una oferta ante
la existencia de inventario de tara en vaina, polvo, semilla, harina, hojuelas o goma,
indicando la fecha de emisión, fecha de vigencia, descripción, unidad de medida,
cantidad, descuento, valor de impuesto, precio unitario y la calidad del producto.
Siendo los actores individuales, asociados o empresariales
Observaciones:
Tabla Nº 20: El actor cotiza una compra de tara.

64
Historia de Usuario
Nombre historia: El actor cotiza una compra de tara

Descripción:
El actor (acopiador, transformador, comercializador, cliente) cotiza libremente una
compra ante la necesidad de tara en vaina, polvo, semilla, harina, hojuelas o goma,
indicando la fecha de emisión, fecha de vigencia, descripción, unidad de medida,
cantidad, descuento, valor de impuesto, precio unitario y la calidad del producto.
También el actor cotiza una compra ante la oferta de tara en vaina, polvo, semilla,
goma, harina u hojuela, indicando la fecha de emisión, fecha de vigencia, descripción,
unidad de medida, cantidad, descuento, valor de impuesto, precio unitario y la
calidad del producto. Los actores pueden ser individuales, asociados o empresariales.
Observaciones:
Tabla Nº 21: El actor emite una proforma de venta de tara.

Historia de Usuario
Nombre historia: El actor emite una proforma de venta de tara.

Descripción:
El Actor, tales como productor y acopiador emiten una proforma de venta ante la
cotización de tara en vaina, polvo o semilla; mientras que el transformador y
comercializador emiten una proforma de venta ante la cotización de tara en vaina,
polvo, semilla, harina, hojuelas o goma indicando la fecha de emisión, fecha de
vigencia, descripción, unidad de medida, cantidad, descuento, valor de impuesto,
precio unitario y la calidad del producto.
El actor puede ser individual, asociado o empresarial.
Observaciones:
Tabla Nº 22: El actor registra compra de tara.

65
Historia de Usuario
Nombre historia: El actor registra compra de tara
Prioridad en negocio: ALTA Riesgo en desarrollo: ALTA

Descripción:
El actor (acopiador, transformador, comercializador, cliente) registra una compra de
tara en vaina, polvo, semilla, harina, hojuelas o goma, indicando la fecha de emisión,
fecha de vigencia, descripción, unidad de medida, cantidad, descuento, valor de
impuesto, precio unitario, la calidad del producto y documento de transacción.
Siendo los actores individuales, asociados o empresariales.
Observaciones:
Tabla Nº 23: El actor registra una venta de tara.

Historia de Usuario
Nombre historia: El actor registra una venta de tara

Descripción:
El actor (productor, acopiador, transformador o comercializador) registra una venta de
tara en vaina, polvo, semilla, harina, hojuela o goma; indicando la fecha de emisión,
fecha de vigencia, descripción, unidad de medida, cantidad, descuento, valor de
impuesto, precio unitario, la calidad del producto y documento de transacción.
Los actores pueden ser individuales, asociados o empresariales.
Observaciones:
Tabla Nº 24: El proveedor oferta servicios.
66
Historia de Usuario
Número: 6 Usuario: Proveedor de servicios
Nombre historia: El proveedor oferta servicio
Prioridad en negocio: MEDIA Riesgo en desarrollo: MEDIA

Descripción:
El proveedor de servicio emite una oferta ante la existencia de servicios disponibles
detallando el tipo de servicio e indicando la fecha de emisión, fecha de vigencia,
descripción, unidad de medida, precio unitario, cantidad, descuento y valor de
impuesto.
Observaciones:
Tabla Nº 25: El actor cotiza servicios.

Historia de Usuario
Nombre historia: El actor cotiza servicios.

Descripción:
El Actor (productor, acopiador, transformador, comercializador) cotiza libremente un
servicio a los proveedores, detallando el tipo de servicio que requiera e indicando la
fecha de emisión, fecha de vigencia, precio unitario, cantidad, descuento, valor
impuesto
También el actor cotiza un servicio ante la oferta de los proveedores de servicio,
detallando el tipo de servicio que requiera e indicando la fecha de emisión, fecha de
vigencia, precio unitario, cantidad, descuento, valor impuesto. Los actores pueden ser
individuales, asociados o empresariales.
Observaciones:
Tabla Nº 26: El proveedor proforma servicios.
67
Historia de Usuario
Nombre historia: El proveedor proforma servicios

Descripción:
El proveedor de servicio emite una proforma ante la cotización de servicios que son
requeridos por el actor (productor, acopiador, transformador, comercializador),
impuesto. Los actores pueden ser individuales, asociados o empresariales.
Observaciones:
Tabla Nº 27: El proveedor registra compra de servicio.

Historia de Usuario
Nombre historia: El Proveedor registra compra de Servicio

Descripción:
El Proveedor de servicios registra una compra de servicios detallando el tipo de
servicio, fecha de emisión, fecha de vigencia, descripción, unidad de medida,
cantidad, descuento, valor de impuesto, precio unitario, la calidad del producto y
documento de transacción.
Observaciones:
Tabla Nº 28: El proveedor oferta bienes.
68
Historia de Usuario
Número: 10 Usuario: Proveedor de bienes
Nombre historia: El proveedor oferta bienes.
Descripción:
El proveedor de bienes emite una oferta ante la existencia de inventario de bienes,

detallando los tipos de bienes e indicando la fecha de emisión, fecha de vigencia,
Observaciones:
Tabla Nº 29: El actor cotiza bienes.

Historia de Usuario
Nombre historia: El actor cotiza bienes

Descripción:
El Actor (productor, acopiador, transformador, comercializador) cotiza libremente un
bien a los proveedores, detallando el tipo de bien que requiera e indicando la fecha de
emisión, fecha de vigencia, precio unitario, cantidad, descuento, valor impuesto.
También el actor cotiza un bien ante la oferta de los proveedores, detallando el tipo de
bien que requiera e indicando la fecha de emisión, fecha de vigencia, precio unitario,
cantidad, descuento, valor impuesto. Los actores pueden ser individuales, asociados o
empresariales.
Observaciones:
69
Tabla Nº 30: El proveedor proforma bienes.
Historia de Usuario
Número: 12 Usuario: Proveedor de bienes
Nombre historia: El proveedor proforma bienes.

El proveedor de bienes emite una proforma ante la cotización de un bien que son
requeridos por el actor (productor, acopiador, transformador, comercializador),
Observaciones:
Tabla Nº 31: El proveedor registra compra de bienes.
Historia de Usuario
Número: 13 Usuario: Proveedor de Bienes
Nombre historia: El Proveedor registra compra de Bienes
Descripción:
El Proveedor de Bienes registra una compra de Bienes detallando el tipo de Bien, fecha
de emisión, fecha de vigencia, descripción, unidad de medida, cantidad, descuento,
valor de impuesto, precio unitario, la calidad del producto y documento de
transacción. Siendo los actores individuales, asociados o empresariales.
Observaciones:
70
Tabla Nº 32: El actor realiza mantenimiento de ofertas de tara.
Historia de Usuario
Nombre historia: EL Actor realiza mantenimiento de ofertas de tara.
Prioridad en negocio: MEDIA Riesgo en desarrollo: ALTA
Descripción:
EL Actor (acopiador, transformador, productor, comercializador) ubica por un numero

de oferta que anteriormente fue registrado, visualiza los datos de la oferta y modifica
los datos de la oferta (fecha de vigencia, quitar o añadir los ítems del detalle de la
oferta) y actualiza los datos de la oferta. Siendo los actores individuales, asociados o
empresariales.
Observaciones:
Tabla Nº 33: EL Actor realiza Mantenimiento de proformas de venta de tara

Historia de Usuario
Nombre historia: EL Actor realiza Mantenimiento de proformas de venta de tara

Descripción:
de proforma que anteriormente fue registrado, visualiza los datos del cotizador y
modifica los datos de la proforma (fecha de vigencia, quitar y añadir los ítems del detalle
de la proforma) y actualiza los datos de la proforma. Siendo los actores individuales,
asociados o empresariales.
Observaciones:
71
Tabla Nº 34: EL Actor realiza Mantenimiento de proformas de venta de tara.
Historia de Usuario
Nombre historia: EL Actor realiza Mantenimiento de cotizaciones de compra tara.
Descripción:
EL Actor (acopiador, transformador, cliente, comercializador) selecciona el tipo de

cotización: cotización libre o cotización por una oferta.
EL Actor ubica por un número de cotización que anteriormente fue registrado, visualiza
los datos del ofertante y modifica los datos de la cotización (fecha de vigencia, quitar o
añadir los ítems del detalle de la cotización) y actualiza los datos de la cotización.
EL Actor ubica por un numero de cotización Libre que anteriormente fue registrado,
visualiza los datos del detalle de la cotización libre y modifica los datos de la cotización
libre (fecha de vigencia, quitar o añadir los ítems del detalle de la cotización libre) y
actualiza los datos de la cotización libre.
Observaciones:
Tabla Nº 35: EL Actor consulta cotizaciones de compra de tara.
72
Historia de Usuario
Nombre historia: EL Actor consulta cotizaciones de compra de tara.
Descripción:
EL Actor (acopiador, transformador, cliente, comercializador) ubica por un numero de

oferta todas las cotizaciones y luego selecciona una cotización, visualiza los datos del
cotizador, ofertante, detalles de la cotización y que tenga la opción de imprimir mi
consulta. Siendo los actores individuales, asociados o empresariales.
Observaciones:
Tabla Nº 36: EL Actor consulta proformas de venta de tara.

Historia de Usuario
Nombre historia: EL Actor consulta proformas de venta de tara
Descripción:

de cotización todas las proformas de venta y luego selecciona una proforma, visualiza
los datos del pro formante, cotizador, detalles de la proforma y que tenga la opción de
imprimir mi consulta. Siendo los actores individuales, asociados o empresariales.
Observaciones:
Tabla Nº 37: EL Actor consulta registros de venta de tara.
73
Historia de Usuario
Nombre historia: EL Actor consulta registros de venta de tara
Descripción:

de comprobante (boleta o factura) que anteriormente fue registrado, visualiza los datos
del vendedor, comprador, comprobante de pago, detalle del registro de la venta de
tara y que tenga la opción de imprimir mi consulta.
Observaciones:
Tabla Nº 38: EL Actor consulta registros de compra de tara.

Historia de Usuario
Nombre historia: EL Actor consulta registros de compra de tara

Descripción:
EL Actor (acopiador, transformador, cliente, comercializador) ubica por un numero de
comprobante (boleta o factura) que anteriormente fue registrado, visualiza los datos del
vendedor, comprador, comprobante de pago, detalle del registro de la compra de tara
y que tenga la opción de imprimir mi consulta.
Observaciones:
Tabla Nº 39: EL Proveedor realiza Mantenimiento de ofertas de Bienes.
74
Historia de Usuario
Nombre historia: EL Proveedor realiza Mantenimiento de ofertas de Bienes

Descripción:
EL Actor (proveedor de bienes) ubica por un numero de oferta que anteriormente fue
registrado, visualiza los datos de la oferta y modifica los datos de la oferta (fecha de
vigencia, quitar o añadir los ítems del detalle de la oferta) y actualiza los datos de la
oferta. Siendo los actores individuales, asociados o empresariales.
Observaciones:
Tabla Nº 40: EL Proveedor realiza mantenimiento de cotizaciones de Bienes.

Historia de Usuario
Nombre historia: EL Proveedor realiza mantenimiento de cotizaciones de Bienes

Descripción:
El Actor (proveedor de bienes) selecciona el tipo de cotización: cotización libre o
cotización por oferta. EL Actor ubica por un numero de cotización que anteriormente
fue registrado, visualiza los datos del ofertante y modifica los datos de la cotización
(fecha de vigencia, quitar o añadir los ítems del detalle de la cotización) y actualiza
los datos de la cotización. EL Actor ubica por un numero de cotización Libre que
anteriormente fue registrado, visualiza los datos del detalle de la cotización libre y
modifica los datos de la cotización libre (fecha de vigencia, quitar o añadir los ítems
del detalle de la cotización libre) y actualiza los datos de la cotización libre. Siendo los
actores individuales, asociados o empresariales.
Observaciones:
75
Tabla Nº 41: EL Proveedor realiza mantenimiento de proformas de bienes
Historia de Usuario
Nombre historia: EL Proveedor realiza mantenimiento de proformas de bienes

Descripción:
EL Actor (proveedor de bienes) ubica por un numero de proforma que anteriormente
fue registrado, visualiza los datos del cotizador (comercializador, productor, acopiador,
transformador) y modifica los datos de la proforma (fecha de vigencia, quitar o añadir
los ítems del detalle de la proforma) y actualiza los datos de la proforma. Siendo los
Observaciones:
Tabla Nº 42: EL Proveedor consulta cotizaciones de bienes

Historia de Usuario
Nombre historia: EL Proveedor consulta cotizaciones de bienes

Descripción:
EL Actor (proveedor de bienes) ubica por un número de oferta todas las cotizaciones y
luego selecciona una cotización, visualiza los datos del cotizador, ofertante, detalles
de la cotización y que tenga la opción de imprimir mi consulta.
Observaciones:
76
Tabla Nº 43: EL Proveedor consulta proformas de Bienes.
Historia de Usuario
Nombre historia: EL Proveedor consulta proformas de Bienes.

Descripción:
EL Actor (proveedor de bienes) ubica por un número de cotización todas las proformas
de venta y luego selecciona una proforma, visualiza los datos del pro formante,
cotizador, detalles de la proforma y que tenga la opción de imprimir mi consulta.
Observaciones:
Tabla Nº 44: EL Proveedor consulta registros de compra de Bienes.

Historia de Usuario
Nombre historia: EL Proveedor consulta registros de compra de Bienes

Descripción:
EL Actor (proveedor de bienes) ubica por un numero de comprobante (boleta o
factura) que anteriormente fue registrado, visualiza los datos del vendedor, comprador,
comprobante de pago, detalle del registro de compra de bienes y que tenga la
opción de imprimir mi consulta. Siendo los actores individuales, asociados o
empresariales.
Observaciones:
Tabla Nº 45: EL Proveedor realiza Mantenimiento de ofertas de Servicios.

Historia de Usuario
77
Número: 27 Usuario: Proveedor de Servicios
Nombre historia: EL Proveedor realiza Mantenimiento de ofertas de Servicios.

Descripción:
EL Actor (proveedor de Servicio) ubica por un numero de oferta que anteriormente fue
registrado, visualiza los datos de la oferta y modifica los datos de la oferta (fecha de
vigencia, quitar o añadir los ítems del detalle de la oferta) y actualiza los datos de la
oferta. Siendo los actores individuales, asociados o empresariales.
Observaciones:
Tabla Nº 46: EL Proveedor realiza Mantenimiento de cotizaciones de Servicios.

Historia de Usuario
Nombre historia: EL Proveedor realiza Mantenimiento de cotizaciones de Servicios

Descripción:
EL Actor (proveedor de Servicio) selecciona el tipo de cotización, cotización libre o
cotización por oferta. EL Actor ubica por un numero de cotización que anteriormente
fue registrado, visualiza los datos del ofertante y modifica los datos de la cotización
(fecha de vigencia, quitar o añadir los ítems del detalle de la cotización) y actualiza los
datos de la cotización. EL Actor ubica por un numero de cotización Libre que
anteriormente fue registrado, visualiza los datos del detalle de la cotización libre y
modifica los datos de la cotización libre (fecha de vigencia, quitar o añadir los ítems del
detalle de la cotización libre) y actualiza los datos de la cotización libre. Siendo los
Observaciones:
Tabla Nº 47: EL Proveedor realiza Mantenimiento de proformas de Servicios.
78
Historia de Usuario
Nombre historia: EL Proveedor realiza Mantenimiento de proformas de Servicios

Descripción:
EL Actor (proveedor de Servicio) ubica por un numero de proforma que anteriormente
fue registrado, visualiza los datos del cotizador (comercializador, productor, acopiador,
transformador) y modifica los datos de la proforma (fecha de vigencia, quitar o añadir
los ítems del detalle de la proforma) y actualiza los datos de la proforma. Siendo los
Observaciones:
Tabla Nº 48: EL Proveedor consulta cotizaciones de Servicios.

Historia de Usuario
Nombre historia: EL Proveedor consulta cotizaciones de Servicios.
Descripción:
EL Actor (proveedor de Servicio) ubica por un número de oferta todas las cotizaciones
y luego selecciona una cotización, visualiza los datos del cotizador, ofertante, detalles
de la cotización y que tenga la opción de imprimir mi consulta. Siendo los actores
individuales, asociados o empresariales.
Observaciones:
79
Tabla Nº 49: EL Proveedor consulta proformas de Servicios.
Historia de Usuario
Nombre historia: EL Proveedor consulta proformas de Servicios

Descripción:
EL Actor (proveedor de Servicio) ubica por un número de cotización todas las proformas
de venta y luego selecciona una proforma, visualiza los datos del pro formante,
cotizador, detalles de la proforma y que tenga la opción de imprimir mi consulta. Siendo
los actores individuales, asociados o empresariales.
Observaciones:
Tabla Nº 50: EL Proveedor consulta registros de compra de Servicios.

Historia de Usuario
Nombre historia: EL Proveedor consulta registros de compra de Servicios

Descripción:
EL Actor (proveedor de Servicios) ubica por un número de comprobante (boleta o
factura) que anteriormente fue registrado, visualiza los datos del vendedor, comprador,
comprobante de pago, detalle del registro de compra de servicio y que tenga la
opción de imprimir mi consulta. Siendo los actores individuales, asociados o
empresariales.
Observaciones:
80
Tabla Nº 51: El Actor y proveedor solicitan admisión al Sistema Web.
Historia de Usuario
Número: 33 Usuario: Actor y proveedor
Nombre historia: El Actor y proveedor solicitan admisión al Sistema Web.

Un actor que pudiera ser productor, acopiador, transformador, comercializador, cliente
o un proveedor de servicios o bienes, envían una solicitud dirigida al webmaster,
solicitando admisión al sistema.
Observaciones:
Tabla Nº 52: El administrador emite respuesta de admisión o rechazo.

Historia de Usuario
Número: 34 Usuario: El administrador del sistema.
Nombre historia: El administrador emite respuesta de admisión o rechazo.
Descripción:
El administrador del sistema emite respuesta de admisión o rechazo al solicitante que
pudiera ser el productor, acopiador, transformador, comercializador, cliente o un
proveedor de servicios o bienes.
Observaciones:
81
Tabla Nº 53: El administrador del sistema realiza mantenimiento del sistema web.
Historia de Usuario
Número: 35 Usuario: El administrador del sistema.
Nombre historia: El administrador del sistema realiza mantenimiento del sistema web.

Descripción:
El administrador del sistema modifica el estado de los usuarios en caso del uso
inadecuado del sistema, también se encarga de adicionar los estándares de calidad
de la tara, además fundamentando algunos estándares de calidad.
Observaciones:
Tabla Nº 54: El usuario realiza mantenimiento de sus datos personales.

Historia de Usuario
Número: 36 Usuario: usuario
Nombre historia: El usuario realiza mantenimiento de sus datos personales.

Descripción:
Un usuario que pudiera ser productor, acopiador, transformador, comercializador,
cliente o proveedor de servicio o bienes una vez que son admitidos al sistemas están
en la capacidad de modificar sus datos personales como contraseña, dirección,
localidad, teléfono y web, conservando sus datos anteriores.
Observaciones:
b. Planificación por iteraciones: Tareas de las historias de usuario

82
Tareas de la historia 1
Tabla Nº 55: Tarea 1 de la historia El actor emite una oferta de tara.
Tarea
Número tarea: 1 Número historia: 1
Nombre tarea: Análisis y construcción de la base de datos
Tipo de tarea : Desarrollo Puntos estimados: 3
Fecha inicio: 17 octubre 2008 Fecha fin: 31 octubre 2008
Programador responsable: Equipo XP
Descripción:
Comenzamos analizando a cada actor como interactúa en el sistema contrayendo

así la base de datos de una manera sistemática para la pro forma de venta de tara.
Tarea
Nombre tarea: conexión de la base de datos.
Descripción: Clases e interfaces jdbc: Conexión:
 DriverManager: Es la clase gestora de los drivers, esta clase se encarga de cargar

y seleccionar el driver adecuado para realizar la conexión con la BD en este caso
Mysql.
 Connection: Representa una conexión con una BD.
83
Tarea
Nombre tarea: Generación de la base de datos
Tipo de tarea : Desarrollo Puntos estimados:
Descripción: La generación de la base de datos de esta historia se empleo el MySql a

partir del diagrama de clases.
Tarea
Nombre tarea: Diseño interfaz cuando el actor emite una oferta de tara
Fecha inicio: 4 noviembre 2008 Fecha fin: 16 noviembre 2008
Descripción:
Se diseñara una ventana que muestre un menú ya sea para el productor,

comercializador, transformador y acopiador puedan realizar una oferta de tara.
84
Tarea
Nombre tarea: Implementación cuando el actor emite una oferta de tara.
Fecha inicio: 25 noviembre 2008 Fecha fin: 30 diciembre 2008
Descripción:
Se hace uso para la implementación la arquitectura Modelo-Vista-Controlador Para la

capa de vista se usan los Servlets y la capa de modelo, controlador se usan las clases
del Negocio.
Tabla Nº 60: Tarea 1 de la historia el actor cotiza una compra de tara.
Tarea
Nombre tarea: Análisis y construcción de la base de datos.
Descripción:
Comenzamos analizando a cada actor como interactúa en el sistema contrayendo así

la base de datos de una manera sistemática para la proforma de venta de tara.
85
Tabla Nº 61: Tarea 2 de la historia El actor cotiza una compra de tara.
Tarea
Nombre tarea: Conexión de la base de datos
 DriverManager: Es la clase gestora de los drivers, esta clase se encarga de cargar y

seleccionar el driver adecuado para realizar la conexión con la BD en este caso
Mysql.
 Connection: Representa una conexión con una BD.
Tarea
Descripción:
La generación de la base de datos de esta historia se empleo el MySql a partir del

diagrama de clases.
86
Tarea
Nombre tarea: Diseño interfaz cuando el actor cotiza una compra de Tara.
Descripción:
Se diseñara una ventana que muestre un menú ya sea para el comercializador,

transformador, acopiador y cliente puedan cotizar una compra de tara.
Tarea
Nombre tarea: Implementación cuando el actor cotiza una compra de Tara.
Tipo de tarea :
Puntos estimados:
Desarrollo
Descripción:

del Negocio.
87
Tabla Nº 65: Tarea 1 de la historia el actor emite una proforma de venta de tara.
Tarea
Descripción:

la base de datos de una manera sistemática para la Pro forma de venta de tara.
Tarea
Nombre tarea: conexión de la base de datos
 DriverManager: Es la clase gestora de los drivers, esta clase se encarga de cargar y

Mysql.
88
Tarea
Nombre tarea: Diseño interfaz para una proforma.
Descripción:
Se diseñara una ventana que muestre un menú ya sea para el productor,

comercializador, transformador y acopiador puedan realizar una Pro forma de venta de
tara.
Tarea
Nombre tarea: Implementación de la proforma.
Tipo de tarea :
Puntos estimados:
Desarrollo
Descripción:

capa de vista se usan los Servlets y la capa de modelo, controlador se usan las clases del
Negocio.
Tabla Nº 69: Tarea 1 de la historia El actor registra compra de tara.
89
Tarea

Tarea
Nombre tarea: Conexión de la base de datos.
Programador
Fecha inicio: responsable: Equipo XP
17 octubre 2008 Fecha fin: 31 octubre 2008

Descripción:
la base de datosel
seleccionar dedriver
una manera
adecuadosistemática para la
para realizar la pro forma de
conexión conventa
la BDdeen
tara.
este caso
Mysql.
Tarea
Nombre tarea: Generación de la base de datos.
Descripción:
90
diagrama de clases.
Tarea
Nombre tarea: Diseño interfaz cuando el actor registra compra de tara.
Descripción:

transformador, cliente y el acopiador pueden registrar la compra de la tara.
Tarea
Nombre tarea: Implementación cuando el actor registra compra de tara.
91
Descripción:

del Negocio.
Tabla Nº 74: Tarea 1 de la historia El actor registra una venta de tara.
Tarea
Descripción:

la base de datos de una manera sistemática para la pro forma de venta de tara.
Tarea
92

Mysql.
Tarea
Descripción:

diagrama de clases.
Tarea
93
Fecha inicio: : 4 noviembre 2008 Fecha fin: 16 noviembre 2008
Descripción:

Tarea
Nombre tarea: Implementación cuando el actor registra una venta de tara.
Fecha inicio: : 25 noviembre 2008 Fecha fin: : 30 diciembre 2008
Descripción:

del Negocio.
Tabla Nº 79: Tarea 1 de la historia El actor cotiza servicios.
Tarea
94
Descripción:

Tarea
Nombre tarea: Conexión de la base de datos.
Fecha inicio: : 17 octubre 2008 Fecha fin: : 31 octubre 2008
- DriverManager: Es la clase gestora de los drivers, esta clase se encarga de cargar y

seleccionar el driver adecuado para realizar la conexión con la BD en este caso Mysql.
- Connection: Representa una conexión con una BD.
Tarea
95
Fecha inicio: : 17 octubre 2008 Fecha fin: : 31 octubre 2008
Descripción:

diagrama de clases.
Tarea
Fecha inicio: : 4 noviembre 2008 Fecha fin: 16 noviembre 2008
Descripción:

Tarea
Nombre tarea: Implementación cuando el actor registra una venta de tara.
96
Fecha inicio: 25 noviembre 2008 Fecha fin: : 30 diciembre 2008
Descripción:

del Negocio.
Tabla Nº 84: Tarea 1 de la historia El proveedor proforma servicios.
Tarea
Descripción:
Comenzamos analizando a cada actor como interactúa en el sistema contrayendo

así la base de datos de una manera sistemática para la pro forma de venta de tara.
Tarea
97
DriverManager: Es la clase gestora de los drivers, esta clase se encarga de cargar y

Connection: Representa una conexión con una BD.
Tarea
Descripción:

diagrama de clases.
Tarea
98
Nombre tarea: Diseño interfaz cuando el proveedor proforma servicios.
Descripción:
Se diseñara una ventana que muestre un menú donde el proveedor Pro forma servicio
al productor, comercializador, cliente, acopiador y trasformador.
Tarea
Nombre tarea: Implementación cuando el actor cotiza servicios.
Descripción:

Negocio.
Tabla Nº 89: Tarea 1 de la historia El actor cotiza bienes.
99
Tarea
Descripción:

Tarea
Nombre tarea: Conexión de la base de datos

Mysql.
100
Tarea
Descripción:

diagrama de clases.
Fuente: elaboración propia
Tarea
Nombre tarea: Diseño interfaz cuando el proveedor Pro forma servicios.
Descripción:
101
Tarea
Descripción:

Negocio.
Tabla Nº 94: Tarea 1 de la historia El proveedor proforma bienes.
Tarea
Descripción:

102
Tarea
DriverManager: Es la clase gestora de los drivers, esta clase se encarga de cargar y

Connection: Representa una conexión con una BD.
Tarea
Descripción:

diagrama de clases.

103
Tarea
Nombre tarea: Diseño de interfaz cuando el proveedor proforma servicios.
Descripción:
Tarea
Descripción:

Negocio.
104
Tabla Nº 99: Tarea 1 de la historia El Actor y proveedor solicitan admisión al Sistema
Web.
Tarea
Descripción:

del Negocio.
Tabla Nº 100: Tarea 2 de la historia El Actor y proveedor solicitan admisión al Sistema Web.
Tarea
Descripción: Clases e interfaces Jdbc: Conexión:
 DriverManager: Es la clase gestora de los drivers, esta clase se encarga de cargar

y seleccionar el driver adecuado para realizar la conexión con la BD en este caso
Mysql.
105
Tarea
Descripción:

diagrama de clases.
Tabla Nº 102: Tarea 4 de la historia El Actor y proveedor solicitan admisión al Sistema Web
Tarea
Nombre tarea: Diseño interfaz cuando el proveedor proforma servicios.
Descripción:
106
Tarea
Descripción:

Negocio.
Tabla Nº 104: Tarea 1 de la historia El administrador emite respuesta de admisión o rechazo.
Tarea

Tarea
Nombre tarea: Diseño interfaz cuando el Administrador valida al Actor o Proveedor.
Nombre tarea: Actualización de la base de datos
Fecha
Tipo deinicio:
tarea 4: noviembre
Desarrollo 2008 Fecha
Puntosfin: 16 noviembre
estimados: 3 2008
Programador
Fecha inicio: 17
responsable:
octubre 2008
Equipo XP Fecha fin: 31 octubre 2008

Descripción:
Descripción:
Se diseñara una ventana que muestre un menú donde el proveedor Pro forma bienes al
El Administrador
productor, al Emitir unacliente,
comercializador, Respuesta Al Actoryotrasformador.
acopiador Proveedor Actualiza la base de datos.
Tabla Nº 105: Tarea 2 de la historia El administrador emite respuesta de admisión o

rechazo.
Sin base de datos la historia 35 y 36

107
Usuario
CambiarPassword Admnitrador
CerraSesion Actor
ConsultarUsuario OfertarProducto
IniciarSession Cotizaproducto
ListarUsuario Proformaproducto
Compraproducto
Ofertaservicio
Cotizaserviciolibre
Proformaservicio
Compraservicio
Comprabien
Ofertabien
Cotizabien
Cotizarbienlibre
proformarbien
3.2 DISEÑO
1ª Parte: Equipo, Integrantes y roles
Tabla Nº 106: Integrantes y roles

Miembro Grupo Roles XP Metodología
Belito Allaucca, Aquiles A- 1 Programador
Bautista Gómez, Ruth Betty A- 1 Programador
Pacotaipe Taquiri, Vladimir A- 2 Programador
García Valdivia, Luis A- 2 Programador
Meneses Céspedes, Julio A- 3 Tester
XP
Luya Castro, Ludmila A- 3 Tester
Huamán Bautista , Haydee A- 4 Cliente
Porras Flores, Efraín A- 4 Cliente
2º Parte: Tarjetas CRC

Tabla Nº 107: Usuario
Tabla Nº 108: Administración
108
Tabla Nº 109: Localidad

Tabla Nº 110: Persona

Tabla Nº 111: Natural

Natural
ConsultarPersona Persona
CrearPersona Natural
ListarPersonaNatural
ModificarPersonaNatural
Tabla Nº 112: Jurídica
Administrador
CambioEstadoUsuario Usuario
ConsultarAdministración Localidad
CrearAdministrador
ModificarAdministración
VerificarUsuario
Localidad
ConsultarLocalidad Administrador
CrearLocalidad persona
ModificarLocalidad
Persona
ConsultarPersona Localidad
Natural
Juridica
Actor
Jurídica
109
ConsultarpersonaJuridica Persona
CrearPersonaJuridica
ListarPersonaJuridica
ModificarPersonajuridica
Tabla Nº 113: TipoActor

TipoActor
Borrartipoactor Actor
ConsultartipoActor
CreartipoActor
ListartipoActor
ModificartipoActor
Tabla Nº 114: Actor

Actor
borrarActor Persona
ConsultarActor TipoActor
CrearActor Usuario
ListarActor
ModificarActor
Tabla Nº 115: OfertarProducto

OfertarProducto
BorrarOfertaProducto Usuario
CalcularMontoTotal CotizarProducto
ConsultarOfertaProducto DetalleOfertarProducto
CrearOfertaProducto
ListarOfertaProducto
ModificarOfertaProducto
Tabla Nº 116: DetaleOfertarProducto

DetaleOfertarProducto
BorrarDetalleOfertaProducto OfertarProducto
CalcularValorDescuento Producto
CalcularValorImpuesto
ConsultarDetalleOfertaProducto
CrearDetalleOfertaProducto
ListarDetalleOfertaProducto
ModificarDeatalleOfertaProducto
110
Tabla Nº 117: CotizarProducto
CotizarProducto
BorrarCotizarProducto Usuario
CalcularMontoTotal OfertarProducto
ConsultarCotizaProducto DetalleCotizarProducto
CrearCotizaProducto
ListarCotizaProducto
ModificarCotizaProducto
Tabla Nº 118: DetalleCotizarProductoLibre

DetalleCotizarProductoLibre
BorrarDetalleCotizaProductoLibre CotizarProductoLibre
ConsultarDetalleCotizaProductoLibre
CrearDetalleCotizaProductoLibre
ListarDetalleCotizaProductoLibre
CrearDetalleCotizaProductoLibre
ModificarDetalleCotizaProductoLibre
Tabla Nº 119: ProformarProducto

ProformarProducto
BorrarProformaProducto CotizarProductoLibre
CalcularMontoTotal Usuario
ConsultarProformaProducto DetalleProformarProducto
CrearProformaProducto
ListarProformaProducto
ModificarProformaProducto
Tabla Nº 120: CompraProducto

CompraProducto
BorrarCompraProducto Usuario
CalcularMontoTotal DetalleCompraProducto
ConsultarCompraProducto DocumentoTransaccionProducto
CrearCompraProducto
ListarProformaProducto
ModificarCompraProducto
111
Tabla Nº 121: DetalleCompraProducto
DetalleCompraProducto
BorrarDetalleCompraProducto CompraProducto
ConsultarDetalleCompraProductore
CrearDetalleCompraProducto
ListarDetalleCompraProducto
CrearDetalleCompraProducto
ModificarDetalleCompraProducto
Tabla Nº 122: DocumentoTransaccionProducto

DocumentoTransaccionProducto
BorrarDocumentoTransaccionproducto CompraProducto
CrearDocumentoTransaccionproducto VentaProducto
ModificarDocumentoTransaccionproducto
Tabla Nº 123: VentaProducto

VentaProducto
BorrarVentaProducto DocumentoTransaccionProducto
CalcularMontoTotal DetalleVentaProducto
ConsultarVentaProducto Usuario
CrearVentaProducto
ListarVentaProducto
ModificarVentaProducto
Tabla Nº 124: OfertaServicio

OfertaServicio
BorrarOfertaServicio Usuario
CalcularMontoTotal DetalleOfertaServicio
ConsultarOfertaServicio CotizarServicio
CrearOfertaServicio
ListarOfertaServicio
ModificarOfertaServicio
Tabla Nº 125: DetalleVentaProducto

DetalleVentaProducto
BorrarDetalleVentaProducto Producto
CalcularValorDescuento VentaProducto
ConsultarDetalleVentaProducto
CrearDetalleVentaProducto
ListarDetalleVentaProducto
ModificarDetalleVentaProducto
112
Tabla Nº 126: DetalleCotizarServicio

DetalleCotizarServicio
BorrarDetalleCotizarServicio CotizarServicio
ConsultarDetalleCotizarServicio o
CrearDetalleCotizarServicio
ListarDetalleCotizarServicio
ModificarDetalleCotizarServicio
Tabla Nº 127: CotizarServicio

CotizarServicio
BorrarCotizarServicio Usuario
CalcularMontoTotal OfertarServicio
ConsultarCotizarServicio DetalleCotizarServicio
CrearCotizarServicio
ListarCotizarServicio
ModificarCotizarServicio
Tabla Nº 128: CotizarServicioLibre

CotizarServicioLibre
BorrarCotizarServicioLibre DetalleCotizarServicioLibre
CalcularMontoTotal PorformarServicio
ConsultarCotizarServicioLibre Usuario
CrearCotizarServicioLibre
ListarCotizarServicioLibre
ModificarCotizarServicioLibre
Tabla Nº 129: DetalleCotizarServicioLibre

DetalleCotizarServicioLibre
BorrarDetalleCotizarServicioLibre CotizarServicioLibre
ConsultarDetalleCotizarServicioLibre
CrearDetalleCotizarServicioLibre
ListarDetalleCotizarServicioLibre
113
ModificarDetalleCotizarServicioLibre
Tabla Nº 130: DetalleProformaServicio

DetalleProformaServicio
BorrarDetalleProformaServicio DetalleCotizarServicioLibre
CalcularValorDescuento CotizarServicioLibre
ConsultarDetalleProformaServicio
CrearDetalleProformaServicio
ListarDetalleProformaServicio
ModificarDetalleProformaServicio
Tabla Nº 131: ProformaServicio

ProformaServicio
BorrarProformaServicio DetalleProformaServicio
CalcularMontoTotal CotizarServicioLibre
ConsultarProformaServicio Usuario
CrearProformaServicio
ListarProformaServicio
ModificarProformaServicio
Tabla Nº 132: CompraServicio

CompraServicio
BorrarCompraServicio Usuario
CalcularMontoTotal DetalleCompraServicio
ConsultarCompraServicio DocumentoTransaccionBienServicio
CrearCompraServicio
ListarCompraServicio
ModificarCompraServicio
Tabla Nº 133: DetalleCompraServicio

DetalleCompraServicio
BorrarDetalleCompraServicio Producto
CalcularValorDescuento CompraServicio
ConsultarDetalleCompraServicio
CrearDetalleCompraServicio
114
DetalleCompraServicio Modificar
DetalleCompraServicio
Tabla Nº 134: DocumentoTransaccionBienServicio

DocumentoTransaccionBienServicio
BorrarDocumentoTransaccionBienServicio CompraServicio
CrearDocumentoTransaccionBienServicio CompraBien
ModificarDocumentoTransaccionBienServicio
Tabla Nº 135: CompraBien

CompraBien
BorrarCompraBien CompraBien
CalcularMontoTotal DetallleCompraBien
ConsultarCompraBien Usuario
CrearCompraBien
ListarCompraBien
ModificarCompraBien
Tabla Nº 136: DetallleCompraBien

DetallleCompraBien
Borrar DetallleCompraBien CompraBien
CalcularValorDescuento Bien
Consultar DetallleCompraBien
Crear DetallleCompraBien
Listar DetallleCompraBien
Modificar DetallleCompraBien
Tabla Nº 137: OfertaBien

OfertaBien
BorrarOfertaBien Usuario
CalcularMontoTotal DetalleOfertaBien
ConsultarOfertaBien CotizarBien
CrearOfertaBien
ListarOfertaBien
ModificarOfertaBien
115
Tabla Nº 138: DetalleOfertaBien
DetalleOfertaBien
BorrarDetalleOfertaBien Bien
CalcularValorDescuento OfertaBien
ConsultarDetalleOfertaBien
CrearDetalleOfertaBien
ListarDetalleOfertaBienModificar
DetalleOfertaBien
Tabla Nº 139: CotizarBien

CotizarBien
BorrarCotizarBien Usuario
CalcularMontoTotal OfertaBien
ConsultarCotizarBien DetalleCotizarBien
CrearCotizarBien ListarCotizarBien
ModificarCotizarBien
Tabla Nº 140: DetalleCotizarBien

DetalleCotizarBien
Borrar DetalleCotizarBien CotizarBien
Consultar DetalleCotizarBien
Crear DetalleCotizarBien Listar
DetalleCotizarBien Modificar
DetalleCotizarBien
Tabla Nº 141: CotizarBienLibre

CotizarBienLibre
BorrarCotizarBienLibre DetalleCotizarBienLibre
ConsultarCotizarBienLibre Crear CotizarBien
CotizarBienLibre
ListarCotizarBienLibre
ModificarCotizarBienLibre
116
Tabla Nº 142: CotizarBien

CotizarBien
BorrarCotizarBien Usuario
CalcularMontoTotal DetalleCotizarBien
ConsultarCotizarBien CotizarBienLibre
CrearCotizarBien
ListarCotizarBien
ModificarCotizarBien
Tabla Nº 143: DetalleCotizarBienLibre

DetalleCotizarBienLibre
BorrarDetalleCotizarBienLibre CotizarBienLibre
ConsultarDetalleCotizarBienLibre
CrearDetalleCotizarBienLibre
ListarDetalleCotizarBienLibre
ModificarDetalleCotizarBienLibre
Tabla Nº 144: ProformarBien

ProformarBien
BorrarProformarBien CotizarBienLibre
ConsultarProformarBien DetalleProformaBien
CrearProformarBien o
ListarProformarBien
ModificarProformarBien
Tabla Nº 145: DetalleProformaBien

DetalleProformaBien
BorrarDetalleProformaBien ProformarBien
ConsultarDetalleProformaBien
CrearDetalleProformaBien
ListarDetalleProformaBien
ModificarDetalleProformaBien
Tabla Nº 146: Bienes

117
Bienes
BorrarBien DetalleProformaBien
CrearBien DetalleCotizarBienLibre
ModificarBIen DetalleCotizaBien
DetalleOfertaBien
DetallleCompraBien
Tabla Nº 147: DetalleBien

DetalleBien
BorrarDetalleBien Bienes
CrearDetalleBien Impuesto
ModificarDetalleBien
Tabla Nº 148: Producto

Producto
BorrarProducto CaracteristicaInorganica
BorrarProductoCalidad CaracteristicaOrganica
ConsultarProducto CaracteristicaQuimica
CrearProducto CaracteristicaFisica
CrearProductoCalidad DetalleOfertaProducto
ListarProducto DetalleCotizaProducto
ModificarProducto DetalleCotizaProductolibre
ModificarProductoCalidad DetalleProformaProducto
DetalleCompraProducto
DetalleVentaProducto
Impuesto
Tabla Nº 149: Impuesto

Impuesto
BorrarImpuesto Servicio
ConsultarImpuesto Producto
CrearImpuesto Bien
ListarImpuesto
ModificarImpuesto
118
3ª Parte: diagrama de Clases
Los diagramas de clases se adjuntan en el anexo A.
119
4ª Parte: modelo físico de la base de datos
H1: El actor emite una Pro forma de venta de tara.
Gráfico Nº 13: Base de datos de la emisión de una Pro forma venta de tara por el actor.
120
H2: El actor cotiza una compra de tara.
Gráfico Nº 14: Base de datos de una cotización de compra de la tara
121
H3: El actor emite una oferta de tara
Gráfico Nº 15: Base de datos de la oferta de la tara.
H4: El actor registra compra de tara

Gráfico Nº 16: Base de datos de compra de tara
122
H5: El actor registra una venta de tara

Gráfico Nº 17: Base de datos del registro de la venta de la tara
123
H6: El actor cotiza servicios.
Gráfico Nº 18: Base de datos de la cotización de servicios.
124
125
H7: El actor cotiza servicios
Gráfico Nº 19: Base de datos de la cotización de servicios por el actor.
126
H8: El proveedor proforma servicios
Gráfico Nº 20: Base de datos de la Pro forma de servicios por el proveedor.
127
H9: El actor cotiza bienes
Gráfico Nº 21: Base de datos de la cotización de bienes.
128
H10: El proveedor proforma bienes
Gráfico Nº 22: Base de datos de la Pro forma de bienes del proveedor
129
H11: El Actor y proveedor solicitan admisión al Sistema Web
Gráfico Nº 23: Base de datos de la solicitud de admisión al sistema Web por el actor y
proveedor.
130
H12: El usuario realiza mantenimiento de sus datos personales.
Gráfico Nº 24: Base de datos del mantenimiento de sus datos personales realizado por el usuario
131
5ª Parte: Prototipos
P1: Los usuarios del sistemas Ingresan su nombre de usuario y pass Word
Gráfico Nº 25: Interfaz de ingreso de datos al Sistema.
Fuente: Extraído de la Aplicación del Sistema Web para Comercialización de la Tara

en la Región Ayacucho.
P2: Proceso de gestión del administrador.
Gráfico Nº 26: Interfaz de datos del administrador.

132
P3: Proceso de gestión de Estado de Usuario
Gráfico Nº 27: Interfaz de Sistema Web para la Comercialización de la Tara en la

Región Ayacucho

P4: Proceso de gestión de usuario
Gráfico Nº 28: Activar y desactivar cuentas de usuario para la aplicación.

133
P5: Proceso de gestión de calidad del producto.
Gráfico Nº 29: Interfaz para la calidad del producto
Fuente: Extraído de la Aplicación del Sistema Web para Comercialización de la Tara en la Región Ayacucho.
134
P6: Proceso de gestión y mantenimiento del producto tara
Gráfico Nº 30: Gestión y mantenimiento del producto tara

P7: Proceso de gestión de las características físicas de la calidad de la tara.
Gráfico Nº 31: Gestión de las características físicas de la calidad de la tara.
135
6ª Parte: Incidencias
- Tras esta fase nos ha quedado claro que es prácticamente imposible crear
una planificación inmutable de lo que es las entregas, Las historias de usuario
creadas inicialmente en la planificación fue variando a medida que se fue
trabajando , por tal motivo es que se produjo la desaparición y sustitución de
algunas historias de usuario.
- El desempeño de un grupo de trabajo es una labor larga y laboriosa, siempre

se presentaron pequeños problemas como la selección de herramientas de
trabajo y la unificación de horarios se convirtió en el principal problema de
la fase de planificación.
- La importancia del cliente ha quedado demostrada como máxima ya que

la visión de los miembros del equipo pueden llegar a tener una interpretación
distinta a la del cliente de una hoja de usuario.
136
Diario de Actividades
El diario de actividades son las anotaciones de las reuniones que tuvimos con el
cliente a lo largo del desarrollo del proyecto.
Tabla Nº 150: Diario de Actividades en la Comercialización De Tara De La Región

Ayacucho
Tiempo
Fecha
Actividad Realizada Dedicado Observaciones
(dd/mes)
(en horas)
Primera reunión con el cliente. No sabemos lo que
17/10
3 hacemos y es
frustrante.
21/10 Revisión con el grupo de las Frustrante.
2
hojas de cliente
Reunión con el grupo para
23/10
hacer y acordar las historias de 4
usuario del cliente.
Reunión con el cliente para ver Productiva
27/10 2
las historias de usuario.
Rehacer las historias de usuario Poco productiva
30/10 2
pedidas por el cliente.
Reunión con el cliente para ver Empezamos a
03/11 las historias de usuario y hacer 4 enterarnos.
un prototipo de la interfaz.
Reorganización de historias y Productivo
07/11 4
hacer las interfaz con el grupo.
Reunión con el cliente para ver
11/11 la interfaz y si esta de acuerdo 2
con ellas.
Generación de prototipos y Empezamos a
17/11 presentación de las interfaces y 4 entendernos
137
Reunión con el cliente para
24/11 comenzar a hacer la base de 3
datos.
27/11 Reunión con el grupo para Superada
2
hacer la base de datos. satisfactoriamente
Reunión con el cliente para ver productiva
05/12
la base de datos y ver si esta 3
bien.
Trabajo en grupo y revisión de productiva
06/12
la DB y hacer el informe 4
conforme el trabajo.
Corrección de la base de datos productiva
con el cliente, generación de
08/12 3
prototipos y presentación del
informe.
Reunión con el grupo para productiva
11/12 separar la base de datos según 1
Cita con el cliente para la productiva
corrección con el cliente de las
15/12 4
historias de usuario con sus
respectivas bases de datos.
Reunión del grupo para hacer productiva
17/12 el informe conforme lo manda 3
el cliente y avanzar el código.
Revisión del informe y del productiva
23/12 2
código por el cliente.
Reunión con el grupo de XP productiva
28/12 para ver la corrección del 3
informe y del código.
138
Historial De Revisiones
Tabla 151: Historial de revisiones
Fecha Autor
versión Descripción
17/10/08 1.0 Ing. Efraín Elías Porras

inicio Flores
27/10/08 1.1 Ing. Efraín Elías Porras
Revisión
Flores
1.2 Ing. Efraín Elías Porras
03/11/08 Revisión
Flores
11/11/08 Revisión
Flores
24/11/08 Revisión
Flores
05/12/08 Revisión
Flores
15/12/08 Revisión
Flores
23/12/08 Revisión
Flores
139
BIBLIOGRAFÍA
MONOGRAFÍA
[3] Primo De la Cruz Lapa, Aprovechamiento Integral y Racional de la Tara,

Caesalpinia spinosa – Caesalpinia tinctoria, Revista del Instituto de
Investigación FIGMMG, Vol. 7, Nº 14, 64 -73, Perú - 2004.
[4] Edwin Almeyda Ochoa, Coordinador Gitara, “Experiencia de Fortalecimiento

de la Cadena Productiva de Tara en Ayacucho”, Grupo impulsor de la Tara
en Ayacucho Gitara, IDFESI – Ayacucho, setiembre 2007.
[7] Carlos Elías Peñafiel, Betti Salvá Ruiz, “Utilización del método de diseño de
mezclas en la formulación de salchichas tipo Frankfurter con inclusión de
goma de tara (Caesalpina spinosa)”, Universidad nacional Agraria la
Molina, Lima 12. Perú.
SITIO WEB
[1] José Bravo, Isel Bustamente, DP. Importante incremento de Exportaciones

de Tara. Viernes 16 de Febrero de 2007.
http://www.sierraexportadora.gob.pe/info@sierraexportadora.gob.pe
[consulta: 24 nov. 2008]
[2] Efraín Avendaño Torres “Cadena Productiva de la Tara en Ayacucho”,

Ayacucho – Perú – www.solidinternational.ch [consulta: 15 nov. 2008].
[5] Gina Karina Quiñonez Cachay, “La demanda y oferta de tara (Perú)”,
www.monografias.com, Lima, abril 2007. Perú.
[6] Lorenzo Basurto Rodríguez “Productos Agroindustriales De Exportación”,

Lima – Perú – ALNICOLSA DEL PERÚ S.A.C [consulta: 21 feb. 2009].
140
[12] Extreme Programming: A gentle introduction.
http://www.extremeprogramming.org/ [Consulta: 18 oct. 2008].
[13] Ejemplo de desarrollo software utilizando la metodología XP, “Desarrollo de

un sistema de gestión de una empresa de confecciones”, DSIIC,
Universidad Pontificia de Valencia,
http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemploxp[consulta:15
oct2008].
LIBROS
[8] Ron Jeffries, Ann Anderson, Chet Hendricrickson, “Extreme Programming

Installed”, Editorial “Pearson Education, 1999”, Addison Wesley, 2000.
[9] William C. Wake, “Extreme Programming Explored”, Editorial Pearson

Education, Addison Wesley, Copyright 2000, All Rights Reserved.
[10] Michele Marchesi, Giancarlo Succi, Don Wells, Laurie Williams, “Extreme
programming Perpectives”, publisher, Adisson Wesley, Pags. 640, Agosto,
30 del 2002.
[11] Kent Beck, Martin Fowler, “Planning Extreme Programming”, Pearson

Education, 1999”, Addison Wesley, 2000.
141
ANEXO A
142

Desarrollo de Software Utilizando La Metodología XP

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Desarrollo de Software Utilizando La Metodología XP

Загружено:

Авторское право:

Доступные форматы

INTRODUCCIÓN

La presente investigación sobre el aprovechamiento integral y racional de la Tara es

1.1 ANTECEDENTES DE INVESTIGACION.

A. DESCRIPCIÓN DEL ESLABÓN DE COMERCIALIZACIÓN

El comercializador vende tara en vaina al transformador trasladando el producto por

2.1 LA COMERCIALIZACIÓN DE TARA DE LA REGIÓN AYACUCHO.

2.1.1 Descripción de la tara

Grafico Nº 01: Variedades de la Tara.

Vaina de Tara Semilla de la Tara Hojuela de Tara Goma de la Tara

2.1.2 Aprovechamiento integral de la tara

Además, es utilizada en la protección de suelos, especialmente cuando no se

Las semillas de uso forrajero tienen en su composición porcentual en peso el 28% de

Según Edwin Almeyda ochoa, Coordinador Gitara [4], la situación de la

Las gomas tienen una gran aplicación en la industria en alimentos procesados,

Gráfico Nº 02: Usos diversos de la Tara.

2.1.3 Proceso Productivo Para La Obtención De Concentrado Tánico

Tabla Nº 01: Despepitadora de la Tara.

c) Posteriormente, la fibra y el polvo (que salen juntos de la despepitadora), con

Tabla Nº 02: Parámetros de la tara.

d) La purificación del extracto líquido se realiza por medio de decantación y

e) La concentración del extracto líquido purificado se lleva de 2-5 grados Berilio

Tabla Nº 03: Atomización de la tara.

2.2 LAS GOMAS O HIDROCOLOIDES

Los hidrocoloides o gomas tienen un amplio campo de aplicación en la industria

Tabla Nº 04: Promedio de porcentaje de la goma de tara.

Tabla Nº 05: Características de la goma de tara.

Descripción: Es una goma natural obtenida de las semillas de la Tara (Caesalpinia

Grafico Nº 04: Procesamiento de la Tara.

Fuente: Extraído De Goma De Tara – Alnicolsa Del Perú S.A.C. Perú

2.2.3 Características físicas

Grafico Nº 05: Estabilidad al congelamiento y descongelamiento de la Tara y el LBG

Fuente: Extraído De Goma De Tara – Alnicolsa Del Perú S.A.C. Perú

La Goma de Tara se dispersa e hidrata casi completamente en agua frío o caliente,

2.2.7 Características químicas

Gráfico Nº 06: caracteristicas de goma de Tara

Fuente: Extraído De Goma De Tara – Alnicolsa Del Perú S.A.C. Perú

Humedad Fibra Extracto Azúcares

2.3 PRINCIPALES IMPORTADORES DE TARA EN POLVO

2.4.1 Humedad: El contenido de humedad se expresa por la pérdida de peso de la

2.4.2 Proteína: El porcentaje de proteína se determinó empleando el método Kjeldhal,

2.4.3 Extracto etéreo: Se determinó por el método Boxhlet en un tiempo de extracción

2.4.4 Cenizas: Se determinó por el método de incineración a la temperatura de 550

2.4.6 Carbohidratos: Se determina por diferencia de los análisis de humedad,

Tabla Nº 07: Análisis químico en los frutos (vainas y semillas).

Tabla Nº 08: Análisis químico de la semilla.

Tabla Nº 09: Análisis químico de las gomas o hidrocoloides.

Tabla Nº 11: Análisis químico de la cáscara:

2.5 PROGRAMACIÓN EXTREMA

2.5.2 ¿CÓMO EMPIEZO CON XP?

Programe una reunión de planificación para acordar la liberación. Invite a los

Gráfico Nº 07: Proyecto de la Programación Extrema

Fuente: Extraído de la página http: // www.extremeprogramming.org/map/project.html.

2.5.3 ROLES DE LOS INTEGRANTES DE PROGRAMACIÓN EXTREMA

A. El papel del cliente

B. El papel del programador

C. El papel del Tester

El Testeador de XP no es una persona independiente, dedicado a romper el sistema y humillar a los

Cuando se trata del proceso de planificación, diseño, ensayo, codificación, en la

2.5.4 FASES DE PROGRAMACION EXTREMA

Actividad Tareas Artefacto Técnica Participantes

T2. Realizar un calendario de actividades detallado (dentro de Calendario de Programador.

A1. EXPLORACIÓN DEL SISTEMA.

T1. Explorar las posibilidades de la arquitectura del sistema.