CAPITULO II MARCO TERICO

2.1 ANTECEDENTES En el Per y en la Regin Ayacucho no existe trabajos sobre Software para produccin de quinua que influye en el ingreso econmico del productor; mediante la implementacin de calendario agrcola, actividades agrcolas, aplicaciones de fertilizantes y aplicaciones fitosanitarias, entre otros; la bibliografa es recopilado en la biblioteca de Universidad Nacional de San Cristbal de Huamanga, INIA Ayacucho y Ministerio de Agricultura Ayacucho. Entre los resultados de antecedentes de la investigacin, Pillaca (2009), que la papa es el principal cultivo del pas, socialmente representa la base de la alimentacin de la poblacin de la zona alto andina y genera alrededor de 110 mil puestos de trabajo permanente (30 millones de jornales) cada ao 7 700 en la costa y 102 300 en la Sierra, Contribuyendo al sector agrario con 13% del PBI agrcola. Con la implementacin del software para produccin de papa se busca contar informacin operativa de manera oportuna. Mediante el software Web los actores de la cadena, podrn tener acceso a la informacin y actualizar la informacin de su competencia. La tesis realiza el anlisis, diseo e implementacin del software para apoyar la produccin de papa en la regin Ayacucho 2009. Lagos (2010, p.14), la cadena productiva de la palta genera una dinmica econmica importante en la regin Ayacucho, implica un ingreso anual para la regin de S/. 3 162 928; por lo tanto la gestin adecuada de la cadena es de vital importancia para los ingresos econmico de la regin y de la provincia de Huanta. La tesis buscar desarrollar una aplicacin web para la cadena productiva de la palta con el propsito de mejorar sus procesos colaborativos y la finalidad de brindar informacin operativa y confiable.
7

Segn Sismagro (2011), es un software especialmente desarrollado para la planificacin, administracin y gestin de las actividades realizadas en el sector agropecuario, que se adapta a las diversas reas de negocio y permite obtener un mayor nivel de control y calidad en la produccin. Beneficios: Facilidad de uso Pantallas diseadas para un rpido aprendizaje y manejo; Planificaciones agrcolas giles el sistema incluye todos los puntos a tener en cuenta en el desarrollo de un plan de produccin. Las labores del plan se esquematizan en un calendario de accin; Obtencin del margen bruto se obtiene informe acerca del margen bruto planificado y margen bruto real, se contrastan entre ellos pudiendo as analizar las diferencias econmicas; Generacin de reportes ficheros, tablas entre otros; Acceso remoto va web para ingresar al sistema slo debe acceder a un browser (navegador web, como el Explorer o Firefox), teniendo la facilidad de poder ingresar desde cualquier computadora. De acuerdo a ANAPQUI (2010), el desarrollo Software para mejorar la

Exportacin de quinua, La iniciativa tecnolgica ser utilizada para certificar el producto para su exportacin, a travs de un proceso de seguimiento, con estndares de calidad internacional. Los productores de quinua, en el mbito nacional, estandarizan procesos de produccin de quinua para la exportacin; con la entrega de un sistema informtico (software), el mismo que ya estuvo en un proyecto piloto, se buscar optimizar las condiciones de trabajo y comercializacin de este sector. Desde 1992 se trabajaba manualmente en un sistema de control y seguimiento a la produccin de la quinua, una tarea que requera de dos semanas de trabajo, slo en su esquematizacin, ahora con el nuevo sistema software se abreviar considerablemente el proceso. El producto tecnolgico ser utilizado para certificar el producto para su exportacin, a travs de un proceso de seguimiento, con estndares de calidad internacionales. El nuevo software agiliza el sistema de seguimiento y control de los pasos a seguir, en la cualificacin del producto milenario. El seguimiento es realizado mediante el control de contratos, planillas parcelas y plan de trabajo, de acuerdo a un ciclo productivo.

Tambin se evala la calidad de los insumos, plagas, cosecha y condiciones de produccin. Asimismo, se desarrolla el control de la venta y transaccin, inmerso en el programa especializado para la quinua, que empieza desde la siembra, proceso de crecimiento, cuidado de la produccin, los mercados y la calidad de producto. Ahora se pretende que el avance tecnolgico se generalice para que se beneficie una mayor cantidad de productores y exista una igualdad en el tema de la certificacin de las normas de origen y otras que exige el sistema de exportacin. La intencin es que todos los productores, entre los que se encuentran empresas, microproductores y cooperativas, utilicen el sistema y puedan hacer un control estndar de la produccin de quinua. 2.2 MARCO TERICO Se realiza la revisin literaria sobre los enfoques tericos y conceptuales, y teoras que existen sobre las variables de investigacin. Asimismo, los mtodos y tcnicas existentes para abordar el problema. 2.2.1 LA QUINUA Segn Bonifaz (2010), la quinua es un grano alimenticio que se cultiva ampliamente en la regin andina, desde Colombia hasta el norte de la Argentina para las condiciones de montaas de altura, aunque un eco tipo que se cultiva en chile, se produce a nivel del mar. Domesticada por las culturas prehispnicas, se la utiliza en la alimentacin desde por lo menos unos 3000 aos. CARACTERSTICAS GENERALES La quinua (Chenopodium quinoa), es un grano con un alto contenido proteico, considerado como un pseudos cereal. Originaria de los areas andinas del Peruanos y de Bolivia, de Amrica del Sur. Su color vara notablemente entre blanco, rojo y negro. Nombre cientfico : Familia : Chenopodium quinoa. Chepodiaceace.

Otros Nombres

Palo colorado, Trigo Inca, rbol de papel, Yagual, Pantza, Quiual, quiua, Parca (quechua), Supha, jopa, vocali(aymara).

DESCRIPCIN.- Hierba que alcanza 2m de altura; su tallo posee de diversas formas y color verde, rojo o morado; su inflorescencia Terminal es puntiaguda, con gran variedad de tipos; las semillas miden hasta 2,5 mm. DISTRIBUCIN.- Crece en los andes de Amrica, desde Colombia hasta Chile y Argentina, concentrndose en Bolivia y Per. Actualmente ya se ha introducido en otros pases del hemisferio norte. ORIGEN.- Esta planta ha sido cultivada desde hace 5 800 aos en los Andes y tiene diferentes centros domesticacin en Per, Bolivia y Ecuador. CLASIFICACIN.- La quinua se puede clasificar segn su concentracin de saponinas en: dulce (sin saponina o con menos del 0.11% en base al peso en fresco), y amarga (cuando contiene un nivel mayor al 0.11% se saponina). VARIEDADES De acuerdo a los tipos de quinua, generalmente se reconocen 5 categoras: a. b. c. d. e. Tipo valle, que crece en los valles andinos entre los 2 000 y 3 600 msnm, con perodos largos de crecimiento. Tipo Altiplnico, que se desarrolla alrededor del lago Titicaca, resistente a heladas, sin ramas y con perodos de crecimiento cortos. Tipo Salar, propio de los salares del altiplano peruano boliviano, con resistencia a suelos salinos y alcalinos. Tipo Nivel del Mar, que desarrollo en el sur de chile y no posee ramas. Tipo Subtropical, de los valles interandinos de Bolivia, de color verde intenso y anaranjado. Per y Bolivia tienen la mayor diversidad en variedades, siendo Bolivia el principal foco de diversidad con ms de 3.000 muestras de ecotipos. Se destacan las siguientes variedades; Sajama (Patacamaya, Bolivia), Real (Llica,

10

Bolivia), Kaslala (Bolivia), Toledo Iri (Bolivia), Pasancalla (Bolivia), Kuli negra (Bolivia), Wila coimini (Bolivia), Kata-mari (Bolivia), Kanccolla (Cabanillas, Puno, Per), Cheweca (Puno, Per), Blanca de Juli (Lago Titicaca, Per), Blanca de Chuquito (Per), Blanca de Junn (Per), Rosada de Junn (Per), Ccoito (Per), Choquetipo (Per), Chullpi (Per), Witulla (Per), Amarilla de Marangam (Sicuani, Cuzco, Per), Chaucha (Cayambe y Cotopaxi, Ecuador), Dulce de Quitopamba (Nario, Colombia), Catentoa (Concepcin, Chile), Regalona (Temuco, Chile). VALOR NUTRITIVO.- La quinua tiene un excepcional valor nutritivo que lamentablemente ha sido escasamente difundido. Posee grandes cantidades de carbohidratos, pero no contiene gluten, un alto contenido proteico (16%), es decir, tiene ms protenas que el trigo y el doble de hierro, y un excelente balance de aminocidos esenciales, as, la quinua biolgica contiene los10 aminocidos esenciales. Aporta adems con calcio, fsforo y vitaminas (B, E, I y C). Para la FAO, la quinua es uno de los alimentos con ms futuro y una fuente de solucin a los problemas de nutricin (INIA, 2008).

Componentes (%) Protenas Grasas Fibras Cenizas Calcio Fsforo Hidrato de Carbono

Quinua 13.00 6.70 3.45 3.06 0.12 0.36 71.00

Trigo 11.43 2.08 3.65 1.46 0.05 0.42 71.00

Maz 12.28 4.30 1.68 1.49 0.01 0.30 70.00

Arroz 10.25 0.16 Vegetal 0.60 0.10 78.00

Avena 12.30 5.60 8.70 2.60 60.00

Tabla N 2.1: Composicin de la quinua respecto a otros productos (INIA, 2008)

2.2.2 PRODUCCIN DE QUINUA Actualmente la quinua que se produce en los Andes, se cultiva generalmente en forma orgnica. Por ejemplo, alrededor del lago Titicaca, la quinua en rotacin despus de un cultivo de papa no requiere a aplicacin de fertilizante qumico o solo en pequeas dosis en la mayora de casos. Segn la FAO (2011), afirma que sin embargo, es necesario diferenciar los

11

distintos sistemas de produccin de la quinua. Un sistema es el que se cultiva en campos de rotaciones sectoriales, denominados laymes o aynocas en el sur del Per y Bolivia, en donde es fcil encontrar reas de 2 a 6 hectreas con solo quinua. En la regin de los salares al sur de Bolivia sobre los 3600 m se cultiva la quinua en suelos alcalinos y arenosos, sembrada en forma muy distanciada para utilizar mejor la escasa humedad. En los valles interandinos, entre 2000 a 3800 m, est asociada con otros cultivos como maz, habas, papas u hortalizas. A. SELECCIN DE TERRENO Todo agricultor debe realizar una adecuada seleccin de terreno antes de iniciar la siembra para garantizar una buena calidad del grano, tener xito en la cosecha y mejorar sus ventas (Solid, 2011, p.6). Las caractersticas ms importantes a considerar para la seleccin de terreno son: LA BUENA UBICACIN DEL TERRENO.- Un factor importante a considerar, debern ser terrenos no expuesto a riesgos climatolgicos (heladas, granizadas, sequias demasiadas prolongadas) exceso de malezas. Contar con vas de acceso; para la preparacin con maquinaria, caso contrario usar yunta, la preparacin del terreno se realiza utilizando palas, zapapicos, picos. PENDIENTE ADECUADA DEL TERRENO.- Terrenos con demasiada pendiente ubicado en laderas, genera problemas del lavado de la semilla y los fertilizantes, ante la presencia de las lluvias, para lo cual se deber realizar un buen trazado de los surcos y habilitar los desfogues del agua de lluvia. Igual sucede con terrenos planos con el empozamiento del agua que va generar ahogamiento de la quinua, en estos casos se deber mullir y nivelar bien el terreno. CONDICIONES DEL TERRENO (PH, TEXTURA).- Para el cultivo de quinua se recomienda terrenos con un pH que flucta entre 6.5 a 8; suelos ligeramente acido o ligeramente alcalino, por que el cultivo de quinua es muy susceptible a la acidez y salinidad de los suelos. Suelos de textura franco arenosos, sueltos,

12

profundos, ricos en materia orgnica, no escoger terrenos fangosos (arcillosos), pedregosos, pobres, que van a generar problemas al cultivo de quinua. B. PREPARACIN DE TERRENO De acuerdo a Quintanilla (2010), afirma que La preparacin del terreno debe realizarse idealmente en el verano anterior a la plantacin, que se efectuar en Julio. Esto se hace con el objetivo de controlar malezas, y nivelar el suelo, para preparar las terrazas de plantacin. Posteriormente a principios de otoo se recomienda subsolar el suelo en seco, hacer una aradura profunda (30 cm), y luego hacer rastrajes sucesivos para mullir bien los primeros centmetros del suelo, ya que la quinua presenta un sistema radical muy superficial. Los procesos principales que se debe considerar para la preparacin de terreno: ANLISIS DE SUELO.- Realizar el anlisis del suelo previa toma muestras para conocer las condiciones del terreno a preparar, PH ideal 6.5 a 8.

Figura N 2.1: Anlisis de suelo (Solid, 2011).

INCORPORACIN DE MATERIA ORGNICA.- La aplicacin de la materia orgnica debe efectuarse junto con la preparacin de suelos de tal manera que pueda descomponerse y estar disponible para el cultivo. As mismo esta facilitara la retencin de la humedad, mejorar la estructura del suelo. ARADO.- Utilizando arado de discos profundidad de 30cm. (capa arable), tratar de remover todo el terreno, en caso de no contar con maquinaria o ser

13

inaccesible el terreno utilizar yunta con su arado con reja para la remocin del terreno.

Figura N 2.2: Arado de suelo (Solid, 2011).

PASADA DE RASTRA.- Pasar la rastra, hasta mullir el suelo evitar la presencia de terrones en el campo.

Figura N 2.3: Pasada de rastra (Solid, 2011).

NIVELADO.-

Tratar

de

nivelar

el

terreno,

para

evitar

inundaciones

posteriormente. SURCADO.- Utilizar surcadora, profundidad del surco de 10-12cm de profundidad utilizando el distanciamiento indicado, en caso de no contar con surcadora utilizar yunta con arado de reja para apertura de surcos, esta

14

actividad se efecta el mismo da de la siembra.

Figura N 2.4: Surcado de suelo (Solid, 2011).

C.

SIEMBRA Siembra es el proceso de plantar semillas, con el objetivo de que

germinen y se desarrollen plantas. Para que la siembra sea efectiva es importante seleccionar semillas de buena calidad. Las semillas deben ser sanas y estar libres de elementos contaminantes. (INIA, 2011). La siembra debe efectuarse de preferencia en suelo hmedo, o regar por aspersin inmediatamente despus de la siembra. Esta operacin se efecta depositando uniformemente la semilla en el fondo del surco a chorro continuo, y teniendo la precaucin de dejar caer a poca altura del suelo ya que el viento hace desviar la semilla fuera del surco por su poco peso. (FAO, 2011). Direccin Regional de Investigacin Agraria (2006), la siembra correcta asegura la emergencia rpida y la uniformidad del cultivo. Estos dos factores son afectados por las condiciones del tubrculo-semilla y del suelo. Las condiciones del tubrculo-semilla estn determinadas por el estado fisiolgico de los tubrculos, su tamao y sus condiciones fsicas. Las condiciones del suelo estn determinadas por sus estructura, humedad y temperatura. Por medio del ajuste de la profundidad de siembra, el cultivo de quinua puede ser adaptado a las condiciones existentes de humanidad y temperatura. La distancia y el procedimiento de siembra dependen de factores agronmicos y de la
15

experiencia local. Los procesos ms importantes, que se deben considerar para la siembra son: DESINFECCIN DE LA SEMILLA.- Desinfectar la semilla contra las plagas y enfermedades.

Figura N 2.5: Desinfeccin de la semilla (Solid, 2011).

DISTRIBUCIN DE LA SEMILLA.- Para la siembra de la quinua se recomienda la utilizacin de 8 a 10 Kg., de semilla por hectrea, utilizndose el mtodo de siembra de lnea continua, echndose la semilla al fondo del surco o a la costilla del surco.

Figura N 2.6: Distribucin de la semilla (Solid, 2011).

TAPADO DE LA SEMILLA.- la semilla de la quinua una vez sembrada se cubrir

16

con tierra, con un espesor de 2 a 3 cm utilizndose una rama no se enterrara ms profundo lo cual va generar problemas en la germinacin, cuando el terreno esta hmedo el tapado deber ser ms superficial de 1 a 2 cm.

Figura N 2.7: Tapado de la semilla (Solid, 2011).

DISTANCIAMIENTO UTILIZADO.- El distanciamiento utilizado en la siembra de quinua es de 80 a 90 cm., entre surcos, para poder posibilitar la labor del aporque. VARIEDADES DE QUINUA.- Escoger la variedad de quinua recomendada para la zona. D. FERTILIZACIN RAE (2011) define que Fertilizar, Disponer la tierra para que d ms fruto. Direccin Regional Agraria Puno (2008), la quinua responde favorablemente a la fertilizacin, lo que representa mayores rendimientos y una mejor calidad del grano. Por este motivo debe aplicarse en cantidades altas, teniendo en cuenta el anlisis de suelo y las recomendaciones de un tcnico. El potasio y el calcio suministran firmeza y resistencia a los golpes. Los pasos que se siguen para una buena fertilizacin: a. Calcular la formula de abonamiento considerando el anlisis de suelo, y los fertilizantes a usar.

17

b.

Mezclar en forma homognea los fertilizantes potasio).

a aplicar en el primer

abonamiento de la quinua (la mitad del nitrgeno y todo el fsforo y c. d. e. Aplicar a lnea continua, una vez aperturado los surcos, la mezcla, luego proceder con el tapado con una rama. Para el segundo abonamiento aplicar, la segunda parte del nitrgeno, al costado de las plantas en lnea continua y se tapa con el aporque. La fertilizacin pesticidas. f. Incorporar la materia orgnica en la preparacin del terreno, o tambin a la siembra en el fondo del surco (compost). E. RALEO O DESAHIJ El desahij o raleo es una actividad o labor de mantenimiento de mucha importancia en el cultivo de quinua por que permite eliminar las plantas ms pequeas, de malas condiciones, que no permiten el desarrollo de las otras plantas de mejores condiciones, se realiza cuando las plantas tienen de 10-20 cm de altura. Los pasos para un buen raleo en la siembra de la quinua son: a. b. c. Solamente dejar de 10 a 12 plantas por metro lineal, las mejores. Eliminar las plantas que no estn en buenas condiciones, y que no correspondan a la variedad. Las plantas que quedan van a tener mejores condiciones para su desarrollo. foliar se realiza segn la necesidad del cultivo, es opcional, unas veces se utiliza el foliar solo, o acompaado con los

18

Figura N 2.8: Raleo de quinua (Solid, 2011).

F.

CONTROL DE MALEZAS Para el control de malezas, los productores combinan mtodos qumicos y

mecnicos. Se aplican herbicidas en preemergencia (Gramoxone y Afaln) y en emergencia temprana (Sencor); luego las malezas se controlan con la prctica de aporque (Ewell et al., 2004, p.38). (INIA, 2011), el control de las malezas ayuda, por una parte, a conservar la humedad del suelo al disminuir la competencia por el agua entre el cultivo y las malezas. Por otra parte, permite disminuir los aportes de fertilizantes. Adems, contribuye a disminuir el ataque de muchas plagas y enfermedades de las cuales las malezas son hospederas. Pueden emplearse sin problemas herbicidas de contacto o residuales. RALE (2011) define que Maleza, Espesura que forma la multitud de arbustos, como zarzales, jarales, etc. RALE (2011) define que Control, Comprobacin, inspeccin, fiscalizacin, intervencin.

19

Como maleza se considera toda planta que crece fuera de su sitio e invade otro cultivo en el cual causa ms perjuicio que beneficio. Las malezas se caracterizan por su capacidad para sobrevivir en condiciones ambientales adversas. Los pasos para un adecuado control de malezas en la siembra de la quinua son: a. b. Malezas entre las plantas de quinua en la hilera o surco se eliminan manualmente al momento del raleo. Malezas entre los surcos o hileras, que deben tener una separacin de 0.80 0.90 m, se eliminan con ayuda de una herramienta manual, (picota), yuntas o tractor. En los dos ltimos casos se realiza removiendo la tierra entre los surcos, luego realizar el aporque. Se debe dar nfasis en la eliminacin de quinuas silvestres que desmejoran la calidad del producto por el color oscuro del grano (ayara).

Figura N 2.9: Control de malezas (Solid, 2011).

G.

APORQUE El aporque es necesario para que la quinua sea ms resistente al viento,

no se tumbe y puede sostener sus enormes y pesadas panojas (Solid, 2011, p.28). Los beneficios del aporque de la quinua son: a. El aporque permite una mejor aireacin de las races del cultivo.
20

b. c. d.

Con el aporque se refuerza a la planta contra el acame o tumbado. Se libera a cultivo, cuando hay encharcamiento dentro del surco. Aumenta el rendimiento.

Figura N 2.10: Aporque (Solid, 2011).

H.

CONTROL DE PLAGAS Y ENFERMEDADES Segn la Organizacin Mundial de la Salud (OMS), el producto

fitosanitario se define, como aquella sustancia o mezcla de sustancias destinadas a prevenir la accin de, o destruir directamente, insectos (insecticidas), caros (acaricidas), moluscos (molusquicidas), roedores (rodenticidas), hongos (fungicidas), malas hierbas (herbicidas), bacterias (antibiticos y bactericidas) y otras formas de vida animal o vegetal perjudiciales para la salud pblica y tambin para la agricultura (es decir, considerados como plagas y por tanto susceptibles de ser combatidos con plaguicidas); durante la produccin, almacenamiento, transporte, distribucin y elaboracin de productos agrcolas y sus derivados. Entre los productos fitosanitarios se incluyen tambin los defoliantes, desecantes y las sustancias reguladoras del crecimiento vegetal o fitorreguladores. Los medicamentos de uso humano o veterinario y los mecanismos de control biolgico quedaran
21

fuera de esta denominacin. Tambin reciben la denominacin de venenos tiles. Labores fitosanitarios es la prevencin y control de enfermedades e insectos que afectan al cultivo de la quinua.

PRINCIPALES PLAGAS PLAGAS Cortadora de plantas tiernas NOMBRE COMN Polilla, gusano de tierra y gorgojo. Kcona Kcona(wiqui, tio Minadores y destructores de granos y hojas filucha), mosca minadora, polilla de la quinua. Insectos masticadores y defolidores Gusano minador, padre curo (llama llama), accchu, carhua. Pulguilla, pulgones, cigarritas, trips. Cyperklin, Regent, Oncol. Cyperklin. Trycer, Regent, oncol. CONTROL Regent, Oncol.

Picadores y chupadores

Tabla N 2.2: Principales plagas (INIA, 2011).

PRINCIPALES ENFERMEDADES ENFERMEDADES Mildiu MICROORGANISMOS Perinospora farinosa CONTROL Ridomil, Positron, trivia, infinito. Nativo, Ridomil, Positron. Ridomil, Positron. Ridomil, Positron. Derosal, Fukarim.

Mancha Foliar Podredumbre marrn del tallo Mancha ojival Chupadera

Ascochyta hyalaspora

Phoma exigua var, Foveata Phoma Sp. Rhizoctonia Sp, Fusarium Sp.

Tabla N 2.3 principales enfermedades (INIA, 2011).

22

Figura N 2.11: Control de plagas y enfermedades (Solid, 2011).

Figura N 2.12: Insecticidas para cultivo de quinua (Solid, 2011).

I.

COSECHA Segn (Solid, 2011), la cosecha es una labor de mucha importancia en el

proceso productivo, de ella depende el xito para la obtencin de la calidad comercial del grano, esta labor tiene cinco etapas, cuando se efecta en forma manual o utilizando trilladoras estacionarias: Siega o Corte, Emparvado o formacin de arcos, Trilla, Aventado y limpieza del grano, Secado, Seleccin, Envasado y Almacenamiento, cuando se efecta en forma mecanizada utilizando cosechadoras autopropulsadas, se reduce a trilla, secado, seleccin, envasado y almacenamiento.
23

Figura N 2.13: Emparvado de quinua (Solid, 2011).

Figura N 2.14: Trilla de quinua (Solid, 2011).

24

Figura N 2.15: Venteo de quinua (Solid, 2011).

2.2.3 INGRESO ECONMICO DEL PRODUCTOR El ingreso est calculado sobre la base de la produccin agrcola, cultivada de la quinua; sin embargo es preciso realizar mayores estudios, toda vez que este es el campo con mayores deficiencias de la informacin producida para Tierras en el Per (INIA, 2011). a. Productividad Segn la FAO (2011), la productividad es la relacin entre la produccin obtenida por un sistema productivo y los recursos utilizados para obtener dicha produccin. Tambin puede ser definida como la relacin entre los resultados y el tiempo utilizado para obtenerlos, cuanto menor sea el tiempo que lleve obtener el resultado deseado, ms productivo es el sistema. En realidad la productividad debe ser definida como el indicador de eficiencia que relaciona la cantidad de producto utilizado con la cantidad de produccin obtenida. b. Superficie cultiva

Es la cantidad de tierra de labranza, que puede ser utilizado para el cultivo de quinua. Se incluyen todas las tierras con cultivos temporales, temporales prados de siega o pastoreo y la tierra temporalmente en barbecho (menos de cinco aos) (FAO, 2011).

25

2.2.4 INGENIERA DE SOFTWARE Estndar IEEE, 1993 (2011) seala que: es la aplicacin de un enfoque sistemtico, software. Sommerville (2005) concluy: la ingeniera del software es una disciplina de ingeniera comprende todos los aspectos de la produccin de software. Cul es la diferencia entre la ingeniera del software y ciencia de la computacin? La ciencia de la computacin comprende la teora y los fundamentos; la ingeniera del software comprende las formas prcticas para desarrollar y entregar un software til. Cul es la diferencia entre ingeniera del software y ingeniara de sistemas? La ingeniera de sistemas se refiere a todos los aspectos del desarrollo de sistemas informticos, incluyendo hardware, software e ingeniera de procesos. La ingeniera del software es parte de este proceso. A. SOFTWARE Segn Pressman (2005), el software de computadora es el producto que los ingenieros de software construyen y despus mantienen en el largo plazo; El software se forma con las instrucciones (programas de computadora) que al ejecutar proporcionan las caractersticas, funciones y el grado de desempeo deseados. Segn Sommerville (2005), software son programas de computadora, la disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de la ingeniera al

documentacin asociada y la configuracin de datos que se necesitan para hacer que estos programas operen de manera correcta. Los productos de software se pueden desarrollar para algn cliente o para un mercado general. B. ARQUITECTURA DEL SOFTWARE Segn Clements, (1996), la Arquitectura del Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar

26

la misin del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones. Segn Dewayne (1992), una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construccin del software para un sistema de informacin. 2.2.5 PROGRAMACION EXTREMA XP Segn Anderson (2000), la programacin extrema es una metodologa de desarrollo ligera (o gil) basada en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programacin se basa en una serie de metodologas de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programacin. Una de las caractersticas principales de este mtodo de programacin, es que sus ingredientes son conocidos desde el principio de la informtica.

Segn Kendall, (2005) la programacin extrema (XP, Extreme Programming) es un enfoque para el desarrollo de software que utiliza buenas prcticas de desarrollo y las lleva a los extremos. Se basa en valores, principios y prcticas esenciales. Los cuatros valores son la comunicacin, la simplicidad, la retroalimentacin y la valenta. Recomendamos a los analistas de sistemas que adopten estos valores en todos los proyectos que emprendan, no slo cuando recurran a medidas de programacin extrema.

27

Figura N 2.16: Presentacin de valores asociando los principios a cada uno de ellos (Moya, 2008).

Segn Kendall (2005, p.94), Las cuatro variables que un desarrollador de sistemas puede controlar son el tiempo, el costo, la calidad y el alcance. Cuando estas cuatro variables de control se incluyen de manera apropiada en la planificacin, se genera un estado de equilibrio entre los recursos y las actividades que se requieren para terminar el proyecto. Las actividades de XP consisten en codificar, probar, escuchar y disear. Por supuesto, la codificacin es esencial en cualquier proyecto de software. Las pruebas de funcionalidad, desempeo y conformidad son obligatorias. La actividad de escuchar al cliente y otros programadores y analistas es fundamental. El diseo de un sistema funcional, esttico y al cual se le pueda dar mantenimiento es extremadamente importante. La principal diferencia entre la administracin de proyectos de XP y otros tipos de administracin de proyectos ms tradicionales es que al escuchar lo que desean los usuarios, usted puede calcular la cantidad que se requerir de cada recurso. Con el fin de equilibrar los resultados del proyecto, el analista de XP puede ajustar cualquiera de las cuatro variables de recursos. La Programacin Extrema es una metodologa ligera de desarrollo de software que se basa en la simplicidad, la comunicacin y la realimentacin o reutilizacin del cdigo desarrollado (Beck, 2002).

28

Figura N 2.16: Cuatro variables de programacin extrema de control de recurso (Kendall, 2005).

A.

PRINCIPIOS BASICOS DE LA PROGRAMACIN EXTREMA (XP)

VARIABLES DE CONTROL DE RECURSOS QUE UTILIZA LA XP Las cuatro variables que un desarrollador de sistemas puede controlar son el tiempo, el costo, la calidad y el alcance. Cuando estas cuatro variables de control se incluyen de manera apropiada en la planificacin, se genera un estado de equilibrio entre los recursos y las actividades que se requieren para terminar el proyecto.

Figura N 2.17: Variables de control de recursos que utiliza la XP (Kendall, 2005).

29

ACTIVIDADES RELACIONADAS CON LA XP Las actividades de XP consisten en codificar, probar, escuchar y disear. Por supuesto, la codificacin es esencial en cualquier proyecto de software. Las pruebas de funcionalidad, desempeo y conformidad son obligatorias. La actividad de escuchar al cliente y otros programadores y analistas es fundamental. El diseo de un sistema funcional, esttico y al cual se le pueda dar mantenimiento es extremadamente importante.

Figura N 2.18: Actividades relacionadas con la XP (Kendall, 2005).

B.

PROCESO DE DESARROLLO DE LA PROGRAMACIN EXTREMA (XP) Segn Beck (2002), la programacin extrema parte del caso habitual de

una compaa que desarrolla software, normalmente a medida, en la que hay diferentes roles: un equipo de gestin (o diseo), uno de desarrollo y los clientes finales. La relacin entre el equipo de diseo, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologas tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validacin posterior al mismo. VARIABLES DE CONTROL PARA EQUILIBRAR LAS ACTIVIDADES EN UN PROYECTO DE XP EXITOSO TIEMPO.- Se debe dedicar tiempo para escuchar a los clientes, tiempo para disear, tiempo para codificar y tiempo para probar. Es difcil administrar el tiempo. La XP desafa la idea de que ms tiempo le permitir obtener los resultados que desea. Quizs el cliente preferira que usted terminara a tiempo en lugar de extender la fecha lmite para agregar otra funcin al sistema. COSTO.- El costo puede usarse para equilibrar el proyecto. El tiempo extra tampoco ayuda mucho. Aumenta el costo, pero no siempre incrementa la productividad. Los programadores cansados son menos eficaces que los

30

programadores alertas y tardan ms tiempo para completar una tarea, y tambin cometen errores que requieren an ms tiempo para arreglarlos. A menudo es aconsejable invertir en herramientas como paquetes grficos para comunicar a otros sus ideas sobre el proyecto, y las herramientas CASE pues contribuyen a acelerar los proyectos. Incluso el nuevo hardware podra ser un gasto redituable. CALIDAD.- La calidad puede ajustarse tanto interna como externamente. La calidad interna involucra probar factores del software como la funcionalidad y la conformidad. Por lo general no es conveniente escatimar la calidad interior. En la calidad externa, o cmo el cliente percibe el sistema. Al cliente le interesa el desempeo. La filosofa extrema de XP permite sacrificar algunos de los aspectos de calidad externos. Para que el sistema sea liberado a tiempo. ALCANCE.- El alcance se determina escuchando a los clientes y ponindolos a redactar sus relatos. Los relatos deben ser breves y fciles de comprender. Sera an mejor si el analista pudiera determinar el tiempo y el dinero necesarios para satisfacer cada uno de estos relatos y establecer tambin su nivel de calidad; con el fin de mantener la calidad, manejar el costo y terminar el proyecto a tiempo, el analista de XP podra recurrir a ajustar el alcance del proyecto.

VARIABLE

SI AUMENTA EN EXCESO

SI SE REDUCE Permite mejorar la calidad, siempre que resuelve el problema bsico del cliente. Tambin permite reducir plazo y coste. La herramienta ms potente de gestin (*)

ALCANCE

Mas puede mejorar calidad y alcance, pero en exceso en TIEMPO puede daar, pues la mejor retroalimentacin viene del sistema en produccin. COSTO Ms dinero puede engrasar el Con dinero ser imposible Si poco, sufrir la calidad e inmediatamente detrs el alcance, el tiempo y el coste.

31

sistema, pero en exceso puede crear que lo resuelve. Insistir en mayor calidad permite conseguir CALIDAD Efecto plazo menores se o hacer ms en un tiempo dado. humano: trabaja mejor si siente que se hace un buen trabajo.

resolver cliente.

los

problemas

del

Variable terrible de control. Se puede sacrificar para obtener ganancias a corto, pero los costes enormes posteriormente (humanos, son de

negocio y tcnicos)

Tabla N 2.4: Interaccin entre las cuatro variables de Gestin de proyecto (Beck, 2004).

PRCTICAS ESENCIALES DEL ENFOQUE DE DESARROLLO DE XP

Figura N 2.19: Prcticas esenciales del enfoque de desarrollo de XP (Kendall, 2005).

a.

LIBERACIN LIMITADA. Para que el desarrollo de XP tenga xito, los productos deben liberarse con rapidez. Esto significa que aun cuando los programadores no puedan implementar todas las caractersticas en una sola pieza de software, la versin debe liberarse de acuerdo con lo programado.

b.

SEMANA DE TRABAJO DE 40 HORAS. Esta prctica esencial de la programacin extrema tiene como propsito motivar a los miembros del equipo a que laboren intensamente en el lugar de trabajo, y que tomen un periodo de descanso para que vuelvan al trabajo relajados y menos presionados, con capacidad de detectar los problemas y menos proclives a cometer errores.

32

c.

CLIENTE EN EL SITIO. La prctica esencial del cliente en el sitio llega al extremo al insistir en que un experto en el negocio debe trabajar en el sitio durante todo el proceso de desarrollo. Esta persona toma parte activa en el proceso, pues escribe los relatos del usuario, se comunica con los miembros del equipo y ayuda a establecer prioridades.

d.

PROGRAMACIN EN PAREJAS. Significa que dos programadores que eligen trabajar juntos hacen la programacin, ejecutan las pruebas y conversan acerca de formas de hacer eficiente y eficazmente el trabajo. Al trabajar con otro programador puede clarificar su forma de pensar.

ROLES QUE SE DEBEN DESEMPEAR DURANTE EL PROCESO DE DESARROLLO DE XP Los siete roles son: programador, cliente, probador, rastreador, entrenador, consultor y gran jefe.

Figura N 2.20: Roles que se deben desempear durante el proceso de desarrollo de XP (Kendall, 2005).

PROGRAMADOR.- Se necesita contar con excelentes habilidades tcnicas para programar, refactorizar y realizar pruebas unitarias al cdigo que escriba. Adems, necesita una buena disposicin para abordar con sencillez los problemas ms difciles, aprender de otros, compartir el cdigo y el diseo, y tener el valor para superar cualquier temor de incompetencia o fracaso al

33

enfrentar nuevos problemas. CLIENTE.- El cliente ms adecuado para el equipo de XP es alguien que ser usuario del sistema y que conoce la funcionalidad de negocios que ste requiere. El cliente debe aprender a escribir relatos de usuario, aprender a escribir pruebas funcionales para las aplicaciones que generen los programadores, y tomar decisiones acertadas sobre las caractersticas esenciales del sistema e incluso sobre ajustes a la programacin del proyecto y a las fechas de entrega. PROBADOR.- El programador tambin necesita comunicarse con el cliente sobre las pruebas de funcionamiento, realizar pruebas con regularidad, dar mantenimiento a las herramientas de prueba y elaborar informes precisos acerca de los resultados de las pruebas. RASTREADOR.- ste da seguimiento al progreso general del grupo calculando el tiempo que toman sus tareas y el progreso general hacia sus metas. El rastreador realiza estimaciones de tiempo, pero tambin da retroalimentacin acerca de las estimaciones del equipo. Los rastreadores tambin forman como parte memoria del equipo, al dar seguimiento a los resultados de todas las pruebas de funcionamiento. ENTRENADOR.- Los entrenadores son muy importantes. Ya que ellos conservan la calma cuando todo el equipo est asustado. Ellos moldean las situaciones de manera indirecta, y slo de vez en cuando necesitan retirar con firmeza el mando a un programador errtico, volver a encarrilarlo y devolverle las riendas otra vez. CONSULTOR.- El rol de un experto en consultora tcnica es muy singular. Lo que los equipos de desarrollo de XP esperan de un consultor es que ste les ensee a resolver sus propios problemas. A medida que aprendan, renacer en ellos la confianza, y cuando deje el equipo tal vez ellos utilicen o desechen la solucin que les haya presentado, esto es comn.

34

GRAN JEFE O LDER.- El equipo espera que el gran jefe confe en ellos, demuestre disposicin para apegarse a los valores y principios a los que ellos se apeguen, y que tenga la capacidad de sealar un error si el equipo se desva del camino. El equipo requerir mantenerse en comunicacin con usted (incluso los pequeos cambios al diseo o las desviaciones de otras metas). Su tarea es conseguir que la comunicacin fluya. ste es un rol que exige una total conviccin en el enfoque de XP y de que si todos en el equipo se apegan a sus valores y principios bsicos, es muy probable que lograran algo que valga la pena. 2.2.6 ARTEFACTOS XP A continuacin describimos los artefactos de XP, entre los que se encuentran: Historias de Usuario, Tareas de Ingeniera y Tarjetas CRC. A. HISTORIAS DEL USUARIO Representan una breve descripcin del comportamiento del sistema, emplea terminologa del cliente sin lenguaje tcnico, se realiza una por cada caracterstica principal del sistema, se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan un gran documento de requisitos y presiden la creacin de las pruebas de aceptacin.

Segn Kent Beck (2002), una historia de usuario es una representacin de un requerimiento de software escrito en una o dos frases utilizando el lenguaje comn del usuario. Las historias de usuario son utilizadas en las metodologas de desarrollo giles para la especificacin de requerimientos (acompaadas de las discusiones con los usuarios y las pruebas de validacin). Cada historia de usuario debe ser limitada, esta debera poderse escribir sobre una nota adhesiva pequea. Dentro de la metodologa XP las historias de usuario deben ser escritas por los clientes. Las historias de usuario son una forma rpida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rpidamente a los requerimientos cambiantes:

35

a. b. c.

Las historias de usuario tienen el mismo propsito que los casos de uso. Las escriben los propios clientes, tal y como ven ellos las necesidades del sistema. Las historias de usuario son similares al empleo de escenarios, con la excepcin de que no se limitan a la descripcin de la interfaz de usuario. Tambin conducirn el proceso de creacin de los test de aceptacin (empleados para verificar que las historias de usuario han sido implementadas correctamente).

d.

Existen diferencias entre estas y la tradicional especificacin de requisitos. La principal diferencia es el nivel de detalle. Las historias de usuario solamente proporcionaran los detalles sobre la estimacin del riesgo y cunto tiempo conllevar la implementacin de dicha historia de usuario.

Historia de Usuario Nmero: Nombre Historia de Usuario:

Modificacin (o extensin) de Historia de Usuario (Nro. y Nombre): Usuario: Prioridad en Negocio: (Alta / Media / Baja) Riesgo en Desarrollo: (Alto / Medio / Bajo) Descripcin: Observaciones: Tabla N 2.5: Modelo propuesto para una historia de usuario, (Porras, 2010). Iteracin Asignada: Puntos Estimados:

Puntos Reales:

36

Figura N 2.21: Modelo propuesto para una historia de usuario (Beck, 2004).

B.

TAREAS DE INGENIERA

Tarea de Ingeniera Nmero Tarea: Nombre Tarea: Tipo de Tarea : Desarrollo / Correccin / Mejora / Otra (especificar) Fecha Inicio: Programador Responsable: Descripcin: Tabla N 2.6: Modelo propuesto para una tarea de ingeniera, (Porras, 2010). Fecha Fin: Puntos Estimados: Historia de Usuario (Nro. y Nombre):

37

Figura N 2.22: Modelo propuesto para una historia de usuario (Beck, 2004).

C.

TARJETAS CRC (CLASE - RESPONSABILIDAD COLABORADOR) Estas tarjetas dividen en tres secciones que contienen la informacin del

nombre de la clase, sus responsabilidades y sus colaboradores. En la siguiente figura se muestra cmo se distribuye esta informacin.

Cada tarjeta representa una clase en la programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con ellas) (Beck, 2002).

Nombre del clase Responsabilidades colaboradores

Tabla N 2.7: Modelo de tarjeta CRC, (Porras, 2010).

38

Figura N 2.23: Modelo propuesto para una historia de usuario (Beck, 2004).

D.

CASO DE PRUEBAS DE ACEPTACIN

Estas pruebas las realiza el cliente. Son bsicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificacin de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sera impresentable al cliente; sino que se realizan sobre el producto terminado e integrado o pudiera ser una versin del producto o una iteracin funcional pactada previamente con el cliente. La experiencia muestra que an despus del ms cuidadoso proceso de pruebas por parte del desarrollador, quedan una serie de errores que slo aparecen cuando el cliente comienza a usarlo. Los desarrolladores suelen llevar las manos a la cabeza y expresan: "Pero, a quin se le ocurre usar as mi programa?", Sea como sea, el cliente siempre tiene razn. Decir que los requisitos no estaban claros, o que el manual es ambiguo puede salvar la cara; pero ciertamente no deja satisfecho al cliente. Alegar que el cliente es un intil es otra tentacin muy fuerte, que conviene reprimir. Una prueba de aceptacin puede ir desde un informal caso de prueba hasta la ejecucin sistemtica de una serie de pruebas bien planificadas. De hecho, las pruebas de aceptacin pueden tener lugar a lo largo de semanas o meses, descubriendo as errores latentes o escondidos que pueden ir degradando el funcionamiento del sistema. Estas pruebas son muy importantes, ya que definen el paso nuevas fases del proyecto como el despliegue y mantenimiento.

39

La Prueba de Aceptacin es una prueba formal conducida para determinar si un sistema satisface los criterios de aceptacin y permite al cliente determinar si acepta o no el sistema (Beck, 2002).
Caso de Prueba de Aceptacin Cdigo: Nombre: Descripcin: Condiciones de Ejecucin: Entrada / Pasos de ejecucin: Resultado Esperado: Evaluacin de la Prueba: Tabla N 2.8: Modelo propuesto para una prueba de aceptacin (Porras, 2010). Historia de Usuario (Nro. y Nombre):

2.2.7 ETAPAS DEL PROCESO DE DESARROLLO DE XP Hay cinco etapas: exploracin, planeacin, iteraciones a la primera versin, puesta en produccin y mantenimiento.

Figura N 2.24: Etapas del proceso de desarrollo de XP (Kendall, 2005).

EXPLORACIN.- Se examinar su entorno, sosteniendo su conviccin de que el problema puede y debe enfrentarse mediante programacin extrema, conformar el equipo y valorar las habilidades de los miembros del mismo. Esta etapa durar desde unas cuantas semanas hasta algunos meses y
40

Tambin se ocupar de examinar las tecnologas potenciales que requerir para construir el nuevo sistema. Durante esta etapa debe practicar el clculo de tiempo que tomarn diversas tareas. Los clientes tambin experimentarn con la escritura de relatos del usuario. El objetivo es lograr que el cliente refine lo suficiente un relato para que usted pueda calcular con eficiencia la cantidad de tiempo que tomar construir la solucin en el sistema que est planeando. LA PLANEACIN.- La planeacin podra tomar slo algunos das. En esta etapa usted y sus clientes establecen una fecha de comn acuerdo, que puede ir de dos meses a medio ao a partir de la fecha actual, para la entrega de soluciones a los problemas de negocios ms urgentes de los clientes. ITERACIONES A LA PRIMERA VERSIN.- Por lo general, estas iteraciones (ciclos de pruebas, retroalimentacin y cambios) duran aproximadamente tres semanas. Tendr que bosquejar toda la arquitectura del sistema, aunque slo sea un diseo preliminar. Una meta es realizar pruebas de funcionamiento escritas por el cliente al final de cada iteracin. Al finalizar todas las iteraciones, el sistema est listo para pasar a la siguiente etapa. LA PUESTA EN PRODUCCIN.- Durante esta etapa se realiza diversas actividades. El ciclo de retroalimentacin se acelera, de tal manera que en lugar de recibir retroalimentacin para una iteracin cada tres semanas, las revisiones del software se realizan en una semana. El producto se libera en esta etapa, aunque se puede mejorar incorporndole otras caractersticas. MANTENIMIENTO.- Una vez que se ha liberado el sistema, es necesario mantenerlo funcionando sin problemas. Se pueden agregar nuevas caractersticas, se pueden tomar en cuenta las sugerencias ms arriesgadas del cliente y se pueden cambiar o incorporar nuevos miembros del equipo. 2.2.8 PROGRAMACION ORIENTADO A OBJETOS Dicho paradigma no es ms que un modelo que representa un enfoque particular para la construccin de sistemas. No hay uno mejor que otro, sino

41

que cada uno tiene ventajas y desventajas (Pizarro, 2005). De acuerdo a Mndez, (2005), la POO estructura un programa dividindolo en una cantidad determinada de objetos de alto nivel. Cada objeto le da forma a algn aspecto del problema que se intenta resolver. Menciona tambin que una secuencia de llamadas a procedimientos para controlar el flujo del programa ya no es el enfoque principal de la programacin orientada a objetos. En vez de ello, los objetos interactan entre s para dar lugar al flujo total del programa. De cierta forma, un programa orientado a objetos se convierte en una simulacin real del problema que se intenta resolver. Segn Sintes, (2002), la programacin orientado a objetos (POO) combina las prcticas probadas a lo largo del tiempo de la forma ms eficiente posible. La POO estructura un programa dividindolo en una cantidad determinada de objetos de alto nivel. Cada objeto le da forma a algn aspecto del problema que se intenta resolver. Menciona tambin que una secuencia de llamadas a procedimientos para controlar el flujo del programa ya no es el enfoque principal de la programacin orientada a objetos. En vez de ello, los objetos interactan entre s para dar lugar al flujo total del programa. De cierta forma, un programa orientado a objetos se convierte en una simulacin real del problema que se intenta resolver. JAVA Segn Joyanes, L. (2002), Java es un lenguaje de programacin orientado a objetos que posee un sistema que interpreta y ejecuta los archivos de clase compilados en tiempo real, adems posee un juego de herramientas de desarrollo y una interfaz de programacin de aplicaciones (API). La utilera del archivo java es el jar que genera los archivos java, estos son similares a los archivos zip en que comprimen los archivos a un tamao ms pequeo y proporciona un manera conveniente de distribuir clases de java compilados. 2.2.9 SISTEMA DE GESTION DE BASE DE DATOS

42

Segn Alejandre, (2004), un sistema de gestin de bases de datos almacena los registros de usuarios as como tambin los datos de los grupos dentro de sus propios catlogos de sistema. De esta manera, cualquier conexin a este debe ser realizada con un usuario especfico, y cualquier usuario puede pertenecer a uno o ms grupos definidos. Cabe sealar que un gestor de bases de datos implementa su propio sistema de archivos, manejando directamente particiones o discos completos. Esto se ha hecho principalmente para facilitar y mantener la portabilidad y hacerlo ms eficiente. POSTGRESQL Es un sistema de gestin de base de datos relacional orientada a objetos y libre, publicado bajo la licencia BSD. Como muchos otros proyectos de cdigo abierto, el desarrollo de PostgreSQL no es manejado por una empresa y/o persona, sino que es dirigido por una comunidad de desarrolladores que trabajan de forma desinteresada, altruista, libre y/o apoyada por organizaciones comerciales. Dicha comunidad es denominada el PGDG. Segn Matthew y Stones, (2005) sostiene que PostGreSQL es un sistema de gestin de bases de datos objeto-relacional (ORDBMS) basado en el proyecto POSTGRES, de la universidad de Berkeley. El director de este proyecto es el profesor Michael Stonebraker, y fue patrocinado por Defense Advanced Research Projects Agency (DARPA), el Army Research Office (ARO), el National Science Foundation (NSF), y ESL, Inc. PostGreSQL es una derivacin libre (OpenSource) de este proyecto, y utiliza el lenguaje SQL92/SQL99, as como otras caractersticas que comentaremos ms adelante. Fue el pionero en muchos de los conceptos existentes en el sistema objetorelacional actual, incluido, ms tarde en otros sistemas de gestin comerciales.

43

PostGreSQL es un sistema objeto-relacional, ya que incluye caractersticas de la orientacin a objetos, como puede ser la herencia, tipos de datos, funciones, restricciones, disparadores, reglas e integridad transaccional. A pesar de esto, PostGreSQL no es un sistema de gestin de bases de datos puramente orientado a objetos. 2.2.10 MODELO VISTA CONTROLADOR Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en tres componentes distintos. El patrn de llamada y retorno MVC (segn CMU), se ve frecuentemente en aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina. El modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. MODELO Segn Deitel (2011) sostiene que un modelo se puede ver como una representacin abstracta de cmo los datos son procesados por el sistema. Los modelos estn representados, como un conjunto de datos y mtodos necesarios para procesar estos datos por medio del encapsulamiento de estos datos y funcionalidades. Deber ser independiente de la entrada o salida de datos. Un modelo puede ser dividido en varios sub-modelos pero todos estos submodelos deben ser totalmente compatibles con el principal. Caractersticas: a. b. c. Se le considera el ncleo de la aplicacin. Lleva a cabo las tareas de la aplicacin Si se presentan cambios significativos en este, se deben actualizar todos los componentes de la aplicacin necesarios.

44

Figura N 2.25: Modelo vista controlador, conjunto modelo (Deitel, 2010).

VISTA De acuerdo a Deitel (2011) sostiene que la vista se encarga de desplegarle la informacin al usuario de la aplicacin por medio de una interfaz grafica, y obtener los datos del modelo. Es la nica parte de la aplicacin que interacta con el usuario. Un modelo puede tener ms de una vista asociada, cada vista es capaz de mostrar una o ms representaciones del modelo en la pantalla. En esta se muestran cuales operaciones son las que puede realizar el usuario dentro de la aplicacin. Gracias es esta caracterstica de mltiples vistas se pueden existir por ejemplo en una aplicacin una vista para el cliente, una vista del operador, o tener una vista general del administrador del sistema. Cada vista tiene asociado un controlador que recibe la entrada de los datos, la cual debe pasar al modelo para obtener un resultado. Cada vez que el modelo devuelve algn resultado a la vista, esta se debe actualizar para desplegar la nueva informacin en la pantalla.

45

Figura N 2.26: Modelo vista controlador, conjunto vista (Deitel, 2010).

Figura N 2.27: Modelo vista controlador, conjunto vista de reportes (Deitel, 2010).

Las vistas no necesariamente se limitan a un sistema dentro de una organizacin sino que tambin pueden ser vistas desde un modelo ms amplio donde interactan con otros sistemas. CONTROLADOR Los controladores son asociados a las vistas en una relacin uno a uno, existen tantos controladores como vistas en una aplicacin.
46

De acuerdo a Deitel (2011) , el contralor toma la entrada proveniente de la vista como un evento, este despacha estos eventos dependiendo de la funcionalidad que presente el modelo, traduciendo estos para ser interpretados tanto para la vista como el modelo, esto se realiza por cada evento notable que se obtenga. El comportamiento del controlador es definido por los diferentes estados del modelo, este registra cualquier cambio que se presente, disparando un proceso para que se actualice la informacin.

Figura N 2.28: Modelo vista controlador, conjunto controladores (Deitel, 2010).

2.2.11 MVC PARA APLICACIONES DESKTOP

Figura N 2.29: Relacin entre los mdulos del patrn MVC (Deitel, 2010).

47

Como lo muestra la figura N 2.28 este es un tpico ejemplo del diagrama del MVC para una aplicacin Desktop, en este se muestra la independencia que existente entre cada uno de los componentes que integran el patrn. Se debe distribuir el controlador y a la vista en la capa de presentacin y al modelo en un servidor de contenido. El Modelo lo constituyen los datos y las operaciones de la aplicacin a implementar. La Vista despliega la informacin del modelo en formato correspondiente en este caso una interfaz grafica. El Controlador responde a los eventos de la interfaz y comunica las acciones al modelo.

48