P. 1
Bachiller 2008 - Desarrollo de Un Aplicativo Web Basado en AJAX Para El Control de Inventarios Mobiliarios de La Institución Educativa PRONOE Galileo

Bachiller 2008 - Desarrollo de Un Aplicativo Web Basado en AJAX Para El Control de Inventarios Mobiliarios de La Institución Educativa PRONOE Galileo

|Views: 1.040|Likes:
Publicado porEdgar Cruz
Para mayor información ingresar a www.ingedgarcruz.com en la sección Inicio - Aportaciones donde encontrará varios informes de Bachiller y TESIS para descargar, así como sus respectivas presentaciones en ppt y los Sistemas (software) desarrollado por los tesistas y bachilleres.
Para mayor información ingresar a www.ingedgarcruz.com en la sección Inicio - Aportaciones donde encontrará varios informes de Bachiller y TESIS para descargar, así como sus respectivas presentaciones en ppt y los Sistemas (software) desarrollado por los tesistas y bachilleres.

More info:

Published by: Edgar Cruz on Mar 12, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/21/2014

pdf

text

original

UNIVERSIDAD NACIONAL DEL SANTA FACULTAD DE INGENIERÍA

ESCUELA ACADÉMICA PROFESIONAL DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

“DESARROLLO DE UN APLICATIVO WEB BASADO EN AJAX PARA EL CONTROL DE INVENTARIOS MOBILIARIOS DE LA INSTITUCIÓN EDUCATIVA PRONOE GALILEO”

INFORME DE PRÁCTICAS PRE - PROFESIONALES PARA OPTAR EL GRADO ACADÉMICO DE BACHILLER EN INGENIERÍA DE SISTEMAS E INFORMÁTICA.

AUTOR: GUERRA FLORES TORIBIO HELWER.

ASESOR: M.S. DIANA CECILIA MUÑOZ CASANOVA.

NVO. CHIMBOTE – PERÚ. 2007

AGRADECIMIENTO

A MIS PADRES CON PROFUNDO ETERNA APOYADO GRATITUD POR

AMOR Y HABERME A DAR

CON SUS CONSEJOS Y

CULMINACIÓN MIS ESTUDIOS.

A LA MAGISTER DIANA MUÑOZ

CASANOVA POR

BRINDARME SU AMISTAD Y ASESORAMIENTO EN EL DESARROLLO DEL PROYECTO.

AL

PROMOTOR JORGE

DE

LA

ORGANIZACIÓN MONTERO POR

GALILEO

VIDAL

BRINDARME SU CONFIANZA Y AMISTAD.

i

DEDICATORIA

A DIOS, POR ACOMPAÑARME EN TODO MOMENTO, Y DARME LAS FUERZAS PARA SEGUIR ADELANTE.

A

MI MADRE GLICERIA ELICIA FLORES LÓPEZ

POR SU AMOR, COMPRENSION Y APOYO EN EL TRANSCURSO DE MI EXISTENCIA.

A OMAR BELLIDO VALDIVIEZO POR SU AMISTAD Y PROMOVER EN MI UNA

ACTITUD EMPRENDEDORA.

ii

PRESENTACIÓN
Señores Miembros de la Comisión de Prácticas Pre-Profesionales:

En cumplimiento con el reglamento general de grados y títulos de la Facultad de Ingeniería, de la Escuela Académica Profesional de Ingeniería de Sistemas e Informática de la Universidad Nacional del Santa, me permito presentar a Ustedes el Pre – Profesional titulado: presente informe de Práctica

“DESARROLLO DE UN APLICATIVO WEB BASADO EN AJAX PARA EL CONTROL DE INVENTARIOS MOBILIARIOS DE LA INSTITUCIÓN EDUCATIVA PRONOE GALILEO.”
Con el propósito de optar el Grado de Bachiller en ingeniería de Sistemas e Informática.

Dicho trabajo es producto de los conocimientos adquiridos durante mi estancia en la Universidad Nacional del Santa, el cual es puesto a disposición para su evaluación respectiva.

Deseando que éste informe pueda servir de referencia y aporte a futuros estudios.

Por lo expuesto espero, sabrán dispensar las omisiones que pueda tener, solicito a ustedes miembros del jurado, su dictamen de justicia y equidad.

Gracias.

iii

RESUMEN
El área de dirección forma la parte principal del organigrama estructural de la institución educativa PRONOE GALILEO, tiene como una de sus funciones inventariar sus bienes y luego presentar los reportes al promotor de la organización galileo, las instituciones educativas particulares mantienen este proceso y las nacionales lo presentan al director del área de almacén de la UGEL DEL SANTA teniendo este reporte una estructura fijada. Actualmente, la organización galileo cuenta con un servidor web apache 2.2.4, soportando PHP 5.2.1 y como gestor de base de datos MySQL

5.0.27, como sistema operativo Windows 2003 Server, manteniendo su página web (OG, 2006).

Hasta ahora para el registro de sus bienes lo ha realizado en excel y el resto de proceso en forma manual, demandando para ello mucho tiempo y cometiéndose errores. El presente trabajo, propone realizar un aplicativo web que permita mejorar el control de los bienes de la institución educativa PRONOE GALILEO, el cuál podría adaptarse a otras instituciones o ser usada por las UGEL en el Perú para controlar los bienes de las instituciones educativas a cargo.

Para desarrollar dicho trabajo se hace uso de la metodología de programación extrema (XP), y se adoptan las normas dadas por la Superintendencia de Bienes Nacionales del Perú para el control de los bienes, permitiendo así que el sistema pueda crecer y adaptarse a los nuevos cambios en sus próximas versiones. Además se hace uso: para la gestión del proyecto el sistema XPWeb 3.3.2, para los diagramas en UML el software ArgoUML 0.24, como herramienta CASE el software DBDesigner4 0.5.6, Como editor WYSIWYG a Macromedia Dreamweaver 8 con la extensión MX Kollection Pro, para la localización Geográfica la API de Google, para las noticias RSS, como emulador WAP (IGSM, 2006); los lenguajes XML, XHTML, JAVASCRIPT, PHP, CSS y WML.

iv

ABSTRACT
The directing area instructs the principal part of the educative institution's structural organizational chart GALILEO PRONOE, It has as one of his functions to take stock of his good’s and next showing the reports to the organization galileo's promoter, the educational institutions particular they maintain this process and the nationals show it to her director of the store area UGEL of the SANTA having this report a structure once was fixed.

At present, The organization galileo considers with a server web apache 2.2.4, withstanding PHP 5.2.1 and as base data manager MySQL 5.0.27, as operating System Windows 2003 Server maintaining his page web (OG, 2006).

Until now he has accomplished it in excel in order to his goods's record and in shape - process the rest manual, demanding in order to it long time and provoking errors.

The present work, a system proposes realizing web that he permit improving the control of the institution educative PRONOE GALILEO's goods, the system UGEL in the Peru would be able to become adapted to another institutions or being once was used for them to control goods institutional educative to debit.

The extreme- programming methodology is made use of to develop said work (XP), and adopt him the standards delivered the National- Goods Superintendence of the Peru in order to the goods's control, permitting well then system may grow and becoming adapted to the new changes in his proximate versions. Besides use is made: In order to the project's steps the system XPWeb 3.3.2, in order to the diagrams in UML the software ArgoUML 0.24, as tool CASE the software DBDesigner4 0.5.6, As publisher WYSIWYG to Macromedia Dreamweaver 8 with the extension MX Kollection Pro, in order to the Geographic location her API of Google, in order to the news RSS, as emulative WAP (IGSM, 2006); The languages XML, XHTML, JAVASCRIPT, PHP, CSS and WML.

v

INTRODUCCIÓN
Hoy en día con la rápida expansión de Internet y los avances de las tecnologías web han aparecido un nuevo tipo de aplicaciones en estos entornos cada vez más complejos y dinámicos, conocidos como aplicaciones web.

Las aplicaciones web son populares debido a la practicidad del navegador web como cliente ligero. La habilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software en miles de potenciales clientes es otra razón de su popularidad. Aplicaciones como GMAIL, GOOGLE MAPS, NETSUITE ERP/CRM, BOUCHARD TRANSLATOR, FLICKR, STELLENT UCM, SUGARCRM, YOU TUBE, LOS WIKIS, WEBLOGS, MMORPGS, tiendas online y otros; son ejemplos bien conocidos de aplicaciones web.

Una ventaja significativa en la construcción de aplicaciones web es que deberían funcionar igual independientemente de la versión del sistema operativo instalado en el cliente, en vez de crear clientes para Windows, Mac OS X, GNU/Linux, y otros sistemas operativos; la aplicación es escrita una vez y es mostrada casi en todos lados. Sin embargo, aplicaciones inconsistentes de HTML, CSS, DOM y otras especificaciones de browsers pueden causar problemas en el desarrollo y soporte de aplicaciones web. Adicionalmente, la habilidad de los usuarios a personalizar muchas de las características de la interfaz (como tamaño y color de fuentes, tipos de fuentes, inhabilitar Javascript) puede interferir con la consistencia de la aplicación web.

Los desarrolladores web comúnmente utilizan lenguajes interpretados del lado del cliente para añadir más funcionalidad, especialmente para crear una experiencia interactiva que no requiera recargar la página cada vez (cosa que suele molestar a los usuarios). Se han desarrollado tecnologías para coordinar estos lenguajes con tecnologías del lado del servidor, como por ejemplo PHP y una técnica de desarrollo web que usa una combinación de varias tecnologías llamado AJAX.

vi

Cuando se iniciaron las páginas web, nos encontrábamos en un entorno estático, con páginas en HTML que sufrían pocas actualizaciones y no tenían interacción con el usuario.

Para desarrollar los aplicativos web se requiere contar con un servidor web, un lenguaje de lado del servidor, un servidor de base de datos los cuales pueden residir en un mismo ordenador y contar con un nombre de dominio registrado en el servidor de dominio del proveedor de Internet, para implementar estos servidores existen variedades en tecnologías software, los cuales mantienen una compatibilidad en configuración, tenemos como

servidores web a internet información server (IIS), apache, servlets como servidores web y otros, como lenguajes de lado del servidor PHP, JSP y otros, como servidores de base de datos SQL Server 2005, MySQL, PostgreSQL Firebird y otros.

La actitud de esta sociedad ha provocado la transición de aplicaciones tradicionales hacia aplicaciones que funcionan a través del web enfocadas al usuario final conocido como la web 2.0, permitiendo esto generar colaboración en el intercambio de información y de servicios que reemplacen las aplicaciones de escritorio.

Frente a

todas estas tecnologías y de la web 2.0 se hace necesario

adoptarlas para brindar un servicio de calidad siendo un ejemplo de ello la institución educativa PRONOE GALILEO que busca mejorar el control de sus bienes, brindando información oportuna, exacta, precisa y completa tanto al director de la institución como al promotor de la organización galileo. Para lo cual se hace necesario el desarrollo del presente informe que lleva por titulo “DESARROLLO DE UN APLICATIVO WEB BASADO EN AJAX PARA EL CONTROL DE INVENTARIOS MOBILIARIOS EDUCATIVA manera: DE LA INSTITUCIÓN

PRONOE GALILEO”, el cual esta estructurado de la siguiente

vii

En el CAPITULO I, Se ha recolectado información acerca de la Institución como su Misión, Visión, Objetivos, Políticas Institucionales, Servicios que brinda, Organigrama y se realiza la descripción del mercado.

En el CAPITULO II, Se realiza el Planteamiento del Problema a través de la Realidad Problemática, Formulación del Problema, Justificación, como también se identificará sus objetivos, antecedentes, justificación, metodología a emplear y su alcance.

En el CAPITULO III, Se detalla el Marco Teórico, base del desarrollo de este estudio, se describen las tecnologías y la metodología a usar.

En el CAPITULO IV, Se aplica la Metodología Programación Extrema para el desarrollo del Sistema.

En el CAPITULO V, Se describe la evaluación del Sistema.

Finalmente se anotarán las conclusiones y recomendaciones que se han podido determinar después de haber realizado el desarrollo del Sistema.

viii

INDICE GENERAL

Pág.

AGRADECIMIENTO DEDICATORIA PRESENTACIÓN RESUMEN ABSTRACT INTRODUCCIÓN

i ii iii iv v vi-viii

CAPÍTULO I: DE LA INSTITUCIÓN

1-7

1.1. RAZÓN SOCIAL. 1.2. UBICACIÓN. 1.3. DESCRIPCIÓN DE LA INSTITUCIÓN. 1.4. MISIÓN. 1.5. VISIÓN. 1.6. OBJETIVOS. 1.7. PRINCIPIOS INSTITUCIONALES. 1.8. MERCADO. 1.9. SERVICIOS QUE BRINDA LA INSTITUCIÓN.

1 1 1 2 2 2-3 3-4 4 4-5

1.10. ORGANIGRAMA ESTRUCTURAL DE LA INSTITUCIÓN. 1.11. ORGANIGRAMA FUNCIONAL DE LA INSTITUCIÓN. CAPÍTULO II: PLANTEAMIENTO DEL PROBLEMA. 2.1. REALIDAD PROBLEMÁTICA. 2.2. FORMULACIÓN DEL PROBLEMA. 2.3. JUSTIFICACIÓN DEL PROYECTO. 2.4. HIPOTESÍS. 2.5. VARIABLES. 2.6. OBJETIVOS. 2.7. ANTECEDENTES. 2.8. METODOLOGÍA EMPLEADA. 2.9. ALCANCE. CAPITULO III: MARCO TEÓRICO. 3.1. SITIO WEB DINÁMICO. 3.2. APLICATIVO WEB. 3.3. MODELO DE OBJETOS DE DOCUMENTO. 3.4. AJAX. 3.5. WEB 2.0.

6 7

8-14 8-9 9 9-10 11 11 11-13 13 13 14

15-71 15-16 16-17 18-19 19-23 23-29

3.6. XHTML. 3.7. JAVASCRIPT. 3.8. HOJAS DE ESTILO EN CASCADA (CSS). 3.9. XML. 3.10. RSS. 3.11. YOUTUBE. 3.12. MASHUP. 3.13. YAHOO PIPES. 3.14. SERVIDOR HTTP APACHE. 3.15. PHP. 3.16. MySQL. 3.17. DBDESIGNER4. 3.18. ARGOUML 3.19. TECNOLOGÍA WAP. 3.20. PROGRAMACIÓN ORIETANDA A OBJETOS. 3.21. MACROMEDIA DREAMWEAVER. 3.22. WINDOWS 2003 SERVER. 3.23. LENGUAJE UNIFICADO DE MODELADO. 3.24. APLICACIONES EN CAPAS. 3.25. CONTABILIDAD. 3.26. CONTROL DE INVENTARIOS

30-31 31-32 32-33 33-36 36-37 37 37-38 38 38-39 39-40 40-41 41 42-43 43-44 44-49 49-50 50-51 51-53 53-54 54-56 56

3.27. METODOLOGÍA PROGRAMACIÓN EXTREMA (XP). CAPITULO IV: METODOLOGÍA. 4.1 . RESUMEN DE LA METODOLOGÍA APLICADA (XP). 4.2 . APLICACIÓN DE LA METODOLOGÍA XP. 1. EXPLORACIÓN. A. DESCRIPCIÓN DE LOS PROCESOS ACTUALES EN LA TOMA DE INVENTARIOS DE LA INSTITUCIÓN EDUCATIVA PRONOE GALILEO. B. DESCRIPCIÓN DEL REGISTRO EN EL CATÁLOGO.

56-71

72-214 72-75 76-214 76-98

76-77 77-78

C. DESCRIPCIÓN DEL REGISTRO DEL DOCUMENTO DE INVENTARIO. D. DESCRIPCIÓN DE LAS CONSULTAS. E. DESCRIPCIÓN DE LOS REPORTES. F. DESCRIPCIÓN DEL BALANCE DE INVENTARIO. G. MODELO DEL SISTEMA ACTUAL. H. HISTORIAS DE USUARIO (USER STORIES). I. HERRAMIENTAS. J. TECNOLOGÍAS. K. PROTOTITPO. 2. PLANIFICACIÓN DE LAS ENTREGAS. A. ESTIMACIONES DE ESFUERZO. B. PLANIFICACIÓN. 3. ITERACIONES. A. PRIMERA ITERACIÓN.

78-79 79 79 80 80 80-96 96-97 98 98 98-105 99-101 101-105 106-213 106-143

B. SEGUNDA ITERACIÓN. C. TERCERA ITERACIÓN. D. CUARTA ITERACIÓN. 4. PRODUCCIÓN. CAPITULO V: EVALUACIÓN DEL SISTEMA. 5.1. EVALUACIÓN ECONÓMICA. 5.2. ANÁLISIS DE LOS BENEFICIOS. 5.3. CÁLCULO DE LA RECUPERACIÓN DE LA INVERSIÓN. CONCLUSIONES. RECOMENDACIONES. REFERENCIA BIBLIOGRÁFICA. ANEXOS.

144-155 156-175 176-213 214

215-222 215-219 219-220 220-222

223 224 225-228

ÍNDICE DE TABLAS
Pág.

Tabla Tabla Tabla Tabla

1. Lenguajes Orientados a Objetos. 2. Estructura del código de los tipos de Bien. 3. Algunos códigos del catálogo. 4. Acciones de los Personajes que interactúan con el Sistema.

48 78 78

83 99 99 100 100 100 101 102 103 104 104 105 106 144

Tabla Tabla Tabla Tabla Tabla

5. Funcionalidad común. 6. Gestión de Usuario. 7. Gestión de la Institución. 8. Gestión de Inventario. 9. Gestión del Personal.

Tabla 10. Gestión de las cuentas contables. Tabla 11. Fechas de entrega. Tabla 12. Historias Primera Iteración. Tabla 13. Historias Segunda Iteración. Tabla 14. Historias Tercera Iteración. Tabla 15. Historias Cuarta Iteración. Tabla 16. Detalle - Historias Primera Iteración. Tabla 17. Detalle - Historias Segunda Iteración.

Tabla 18. Detalle - Historias Tercera Iteración. Tabla 19. Detalle - Historias Cuarta Iteración. Tabla 20. Tiempo del desarrollo del sistema. Tabla 21. Costo inicial del sistema. Tabla 22. Costo de materiales. Tabla 23. Costo de equipos. Tabla 24. Costo de software. Tabla 25. Utilidad por año.

156 181 215 216 217 217 218 222

INDICE DE FIGURAS
Pág.

Figura

1. Organigrama Estructural de la Institución Educativa PRONOE GALILEO. 6

Figura

2. Organigrama Funcional de la Institución Educativa PRONOE GALILEO. 7

Figura

3. El modelos tradicional para las ampliaciones Web (Izq.) comparado con el modelo de AJAX (der.). 20

Figura

4. El patrón de interacción sincrónica de una Aplicación Web tradicional (arriba) comparada con el patrón asincrónico de una aplicación AJAX (abajo). 22

Figura Figura Figura Figura Figura

5. Arquitectura en tres Capas. 6. Fases de un proyecto en eXtreme Programming. 7. Ciclos en eXtreme Programming. 8. Descripción del código de un tipo de bien en catálogo. 9. Sistema Actual.

54 71 71 77 80 98 109 109 120 121

Figura 10. Arquitectura del Sistema a desarrollar. Figura 11. Caso de Uso para la primera iteración. Figura 12. Diagrama de clase para la primera iteración. Figura 13. Interfaz - Administración. Figura 14. Interfaz - Usuario.

Figura 15. Interfaz – Agregar Grupo. Figura 16. Interfaz – Registrar Área. Figura 17. Interfaz – Agregar Departamento. Figura 18. Interfaz – Agregar UGEL. Figura 19. Interfaz – Agregar Modalidad. Figura 20. Interfaz – Agregar Institución. Figura 21. Interfaz – Registrar Personal. Figura 22. Interfaz – Mantenimiento Grupo. Figura 23. Interfaz – Mantenimiento Departamento. Figura 24. Interfaz – Mantenimiento UGEL. Figura 25. Interfaz – Mantenimiento Modalidad. Figura 26. Interfaz – Mantenimiento Área. Figura 27. Interfaz – Consulta Institución. Figura 28. Interfaz – Mantenimiento Institución. Figura 29. Interfaz – Mantenimiento Personal. Figura 30. Interfaz – Tiempo de Ejecución: Agregar UGEL Figura 31. DOM – Agregar UGEL (Zona). Figura 32. Agregar UGEL – Estructura XHTML, CSS y JavaScript. Figura 33. Caso de Uso para la segunda iteración. Figura 34. Diagrama de clase para la segunda iteración. Figura 35. Interfaz-Agregar Tipo de Bien en Catálogo.

122 122 123 123 123 124 125 125 126 126 127 127 128 128 129 141 142 143 145 146 147

Figura 36. Interfaz-Agregar Usuario. Figura 37. Interfaz-Autenticación. Figura 38. Interfaz-Mantenimiento Catálogo. Figura 39. Interfaz-Mantenimiento Usuario. Figura 40. Caso de Uso para la tercera iteración. Figura 41. Diagrama de clase para la tercera iteración. Figura 42. Interfaz-Registrar El Bien. Figura 43. Interfaz-Agregar Cuenta contable. Figura 44. Interfaz-Mantenimiento del Bien. Figura 45. Interfaz-Mantenimiento de Cuentas contables. Figura 46. Caso de Uso para la cuarta iteración. Figura 47. Diagrama de clase para la cuarta iteración. Figura 48. Interfaz-Localizar Institución. Figura 49. Interfaz-Registrar información. Figura 50. Interfaz-Leyenda de Geolocalizador. Figura 51. Reporte de inventario para una cuenta contable. Figura 52. Reporte de inventario para todas las cuentas contables. Figura 53. Estadística de los bienes. Figura 54. Balance de Inventario. Figura 55. Interfaz-Dispositivo móvil-Inicio. Figura 56. Interfaz-Dispositivo móvil-Usuario.

148 148 149 149 157 158 159 160 160 161 177 178 179 180 180 181 182 183 183 184 185

Figura 57. Interfaz-Dispositivo móvil-Clave. Figura 58. Interfaz-Dispositivo móvil-Consulta Personal. Figura 59. Interfaz-Dispositivo móvil-Código del área del Personal. Figura 60. Interfaz-Dispositivo móvil-Información del Personal. Figura 61. Diseño lógico de la base de datos. Figura 62. Tiempo de recuperación del capital invertido. Figura 63. Fórmula para determinar el valor presente.

185 186 186 187 213 221 221

CAPÍTULO I DATOS DE LA INSTITUCIÓN

CAPÍTULO I DATOS DE LA INSTITUCIÓN
1.1. RAZON SOCIAL.

Institución Educativa PRONOE GALILEO.

1.2.

UBICACIÓN.

La Institución Educativa PRONOE GALILEO esta ubicada en la Avenida pardo 623, del Distrito de Chimbote, Provincia del Santa, en el Departamento de Ancash.

1.3.

DESCRIPCIÓN DE LA INSTITUCIÓN.

La necesidad de trabajar a temprana edad hace necesario el uso de programas no escolarizados para permitir que las personas sigan sus estudios sin postergarlos o abandonarlos.

Instituciones no escolarizadas con el sistema Pre Universitario

no

existe en nuestra localidad, siendo así la primera Institución con este sistema, creado el 09 de julio del 1999 Institución Educativa PRONOE GALILEO. con R.D. Nº 017-99 como

La Institución Educativa cuenta 5 secciones de nivel secundario. Las plazas docentes y administrativa se encuentran cubiertas de acuerdo al presupuesto de la Organización Galileo, contando en la actualidad con 10 profesores y 4 personas cumpliendo la labor administrativa, en cuanto a infraestructura cuenta con 6 aulas, un laboratorio de computo, una biblioteca escolar, un ambiente para realizar clases de educación Física, otro para las clases de música, una sala de profesores, una oficina del auxiliar y 4 oficinas administrativas. Capítulo I: Datos de la Institución Educativa.

1

1.4.

MISIÓN.

Somos una Institución Educativa Privada no Escolarizada Pre Universitaria, que proporciona Educación Secundaria en los turnos

Sábados y Domingos, dirigido a personas de 15 años a mas de la provincia del santa y anexos, que se han visto en la necesidad de interrumpir sus estudios por razones económicas, familiares o por trabajo.

Promovemos módulos y

aprendizajes

a

través

de

la

aplicación

de

prácticas en

laboratorios

dirigidos por una plana de

docentes capacitada periódicamente desarrollando una actitud de emprendimiento y de innovación.

1.5.

VISIÓN.

En el 2011, queremos ser una institución líder de la Provincia del Santa, a través del diseño, implementación y desarrollo de un modelo educativo innovador que brindará un servicio de calidad, formando

jóvenes competentes, con valores sólidos, capaces de relacionarse en cualquier campo educativo y laboral.

1.6.

OBJETIVOS.

A. OBJETIVO GENERAL.

La Institución Educativa PRONOE GALILEO tiene como objetivo formar integralmente a los alumnos, con mentalidad de

emprendimiento y con sólidos valores.

Capítulo I: Datos de la Institución Educativa.

2

B. OBJETIVO ESPECÍFICO. •

Dar cobertura a las necesidades insatisfechas educación tradicional Pre Universitaria. a través de su

en la

educación

Consolidar un proceso educativo, eficiente y eficaz en respuesta a la globalización.

• •

Fomentar la práctica de valores.

Desarrollar

en el estudiante identificación por su

institución Educativa. • •

Desarrollar una fuerte Identificación Cultural.

Mantener una actitud critica y de análisis para ir dando respuestas identifiquen. a las necesidades vocacionales que se

Desarrollar una actitud estudiantes.

critica

reflexiva en los

• •

Desarrollar el liderazgo en los estudiantes.

Realizar eventos culturales y deportivos que posibiliten el desarrollo integral de los alumnos.

1.7.

PRINCIPÍOS INSTITUCIONALES. • •

Honestidad.

Solidaridad.

Capítulo I: Datos de la Institución Educativa.

3

• • • • 1.8. MERCADO.

Responsabilidad

Respeto

Innovación

Justicia.

Durante estos últimos años se han creado varias instituciones educativas no escolarizadas ubicadas en el distrito de chimbote y nuevo chimbote, pero en su modelo educativo no presentan la enseñanza Pre Universitaria.

Cada año mas personas no pueden asistir a las instituciones educativas donde las clases se realizan de lunes a viernes en sus diferentes turnos, por motivo de trabajo, familiares u otros, entonces la labor de los PRONOE es que estas personas sigan sus estudios y entre estas instituciones

logren ingresar a la universidad, generando

competencia académica en el compartir de sus conocimiento.

La organización Galileo nuestra localidad

gestor

del modelo Pre Universitario en a penas

ha logrado que sus estudiantes ingresen

terminando sus estudios secundarios a universidades nacionales y particulares del Perú, demostrando su calidad educativa e innovadora.

1.9.

SERVICIOS QUE BRINDA LA INSTITUCIÓN.

Los servicios que brinda la Institución Educativa PRONOE GALILEO: •

Se desarrollan las clases presénciales: sábados y Domingos.

Capítulo I: Datos de la Institución Educativa.

4

• • •

Asesoramiento vocacional a los estudiantes.

Cursos de computación a los estudiantes y público en general.

Talleres de capacitación a los profesores que laboran en la institución.

Encuentros académicos y deportivos entre las diferentes instituciones educativas.

Capítulo I: Datos de la Institución Educativa.

5

1.10. ORGANIGRAMA ESTRUCTURAL DE LA INSTITUCIÓN.

Figura 1. Organigrama Estructural de la Institución Educativa PRONOE GALILEO.

Capítulo I: Datos de la Institución Educativa.

6

1.11. ORGANIGRAMA FUNCIONAL DE LA INSTITUCIÓN.

Figura 2. Organigrama Funcional de la Institución Educativa PRONOE GALILEO.

Capítulo I: Datos de la Institución Educativa.

7

CAPÍTULO II PLANTEAMIENTO DEL PROBLEMA

CAPÍTULO II PLANTEAMIENTO DEL PROBLEMA
2.1. REALIDAD PROBLEMÁTICA

La institución educativa PRONOE GALILEO es parte de la Organización Galileo, en esta institución se han perdido algunos bienes, sin saber que persona estuvo a cargo, siendo esto un problema repetitivo, además el promotor y director del PRONOE GALILEO desconocen en su mayor parte con que bienes cuentan al no tener un documento con un registro completo de estos. Existen demasiados errores en la toma de inventarios y mucha demora en entregar el documento al promotor y contador, así mismo cuando el promotor necesita obtener un reporte o consulta esto demora demasiado.

Los posibles errores y retrasos que pueden cometerse son:

-

Duplicidad y errores al momento de llenar los datos en el archivo de excel.

-

La consulta y búsquedas de bienes es realizado manualmente generando mucho tiempo.

-

La realización de los reportes diarios, mensuales, anuales o de una fecha específica demanda mucho tiempo y esta propensa a errores.

-

El valor en dinero de los bienes con que cuenta la Institución se realiza en forma manual, abarcando mucho tiempo.

-

Retrasos en los procesos de actualizaciones de los bienes de la institución educativa.

Capítulo II: Planteamiento del problema.

8

-

Demora en generar el balance de inventario.

-

Demora en ubicar de donde proviene el bien mobiliario.

-

Demora en detectar a que área y que personal esta cargo de un determinado bien.

La Organización Galileo ha comenzado a informatizar sus áreas, pero hasta la fecha todavía no cuenta con un sistema informático para el control de sus bienes.

La UGEL Del Santa da a cada director de las instituciones educativas un archivo en excel que cuenta con cinco (5) tipos de formatos con sus respectivas cuentas contables cada uno, el director nombra a un comité

encargado de registrar todos los bienes de cada área y de las personas a cargo de estás, luego estos registros son presentados al promotor si esta institución es particular, sino a la UGEL Del Santa. Esta respectivamente envía un reporte a la Superintendencia de Bienes Nacionales del Perú.

2.2. FORMULACIÓN DEL PROBLEMA

¿DE QUÉ MANERA EL DESARROLLO DE UN APLICATIVO WEB MEJORARÁ EL CONTROL DE LOS INVENTARIOS MOBILIARIOS DE LA INSTITUCIÓN EDUCATIVA PRONOE GALILEO?

2.3. JUSTIFICACIÓN

-

ECONÓMICA •

La Organización Galileo cuenta con los recursos necesarios para desarrollar el proyecto para su institución educativa PRONOE GALILEO - Chimbote.

Capítulo II: Planteamiento del problema.

9

La mayor parte del software es software libre, por lo cual no se pagó por la licencia.

-

TÉCNICA •

El aumento del ancho de banda funcione vía WEB/WAP.

permite que el sistema

Al desarrollar una aplicación WEB permite que funcione en cualquier sistema operativo no requiriendo paquetes. instalar otros

Al utilizar AJAX permite que la interacción sea rápida del usuario con el sistema.

-

OPERATIVA •

La Institución Educativa PRONOE GALILEO, cuenta con el personal capacitado en computación.

El Promotor de la Institución Educativa participa en el desarrollo del sistema.

Disminuir los errores en la toma de inventarios, ya que existen muchos datos duplicados, no permitiendo un buen control del inventario mobiliario.

Las consultas y reportes deben ser rápidos para poder tomar las decisiones adecuadas, por lo que se disminuirá el tiempo que demanda las consultas y entrega de los reportes al promotor y/o UGEL respectiva.

Capítulo II: Planteamiento del problema.

10

2.4. HIPÓTESÍS

“EL DESARROLLO DE UN APLICATIVO WEB MEJORARÁ EL CONTROL DE INVENTARIOS MOBILIARIOS DE LA INSTITUCIÓN

EDUCATIVA PRONOE GALILEO”

2.5. VARIABLES

A. VARIABLE INDEPENDIENTE Desarrollo de un aplicativo web.

B. VARIABLE DEPENDIENTE Control de inventarios mobiliarios de la institución educativa PRONOE GALILEO.

2.6. OBJETIVOS

A. OBJETIVO GENERAL

Desarrollar un aplicativo web que permita mejorar el control de los inventarios mobiliarios de la institución educativa PRONOE GALILEO.

B. OBJETIVOS ESPECIFICOS

-

Registrar oportunamente las adquisiciones de los bienes desde la intranet o desde Internet.

Capítulo II: Planteamiento del problema.

11

-

Identificar y clasificar

los tipos de bienes de forma flexible,

registrándolos en un catalogo por códigos.

-

Facilitar la identificación precisa de un bien, permitiendo ubicación y estado actual en el menor tiempo.

su

-

Disminuir los errores al registrar el bien.

-

Llevar un control tanto de las compras, donaciones y traslados de bienes, facilitando su seguimiento.

-

Clasificar los bienes en las respectivas cuentas contables

-

Eliminar la duplicidad de datos.

-

Disminuir el tiempo en las consultas de los bienes.

-

Disminuir el tiempo en hallar el valor en dinero de los bienes que cuenta la institución educativa.

-

Disminuir el tiempo en las actualizaciones de los bienes.

-

Entregar a tiempo el balance de inventario.

-

Conocer de donde proviene el bien mobiliario.

-

Conocer

a que área

pertenece y quién esta a cargo de un

determinado bien.

-

Determinar de donde proviene un bien donado.

-

Disminuir el tiempo que demanda la búsqueda y entrega de los reportes al promotor y/o a la UGEL respectiva.

Capítulo II: Planteamiento del problema.

12

-

Permitir obtener reportes rápidos para la toma de decisiones en el menor tiempo posible.

-

Disminuir el porcentaje de errores que se pueda cometer en el momento de ingresar los datos.

-

Mejorar la interacción del usuario con el sistema, permitiendo que el sistema responda en el menor tiempo posible las peticiones realizadas por este.

2.7. ANTECEDENTES

Existen diversos trabajos de investigación relacionados con el tema como la tesis (Catarí, 2001), que tiene por fin diseñar un programa de evaluación del control interno contable para el inventario de la empresa Mega Tunal C. A., pero el que contribuyó significativamente en la culminación del proyecto el desarrollo de un sistema de

(Sánchez, 2007),

que tiene por finalidad

gestión para cualquier empresa que se dedique a la venta al mayor dentro del comercio textil, utilizando para ello las últimas y más innovadoras soluciones desarrolladas dentro de la comunidad open source, minimizando el tiempo de desarrollo a la vez que maximizando la calidad del producto.

Varios desarrolladores han creado software de inventarios, el que más se acerca al propósito es el software de Inventarios Mobiliarios Institucional (SBNP, 2006), usando para ello Visual Fox Pro.

2.8. METODOLOGÍA EMPLEADA

Se utilizó la metodología: Programación Extrema (XP).

Capítulo II: Planteamiento del problema.

13

2.9. ALCANCE

El aplicativo web

para el control de inventarios mobiliarios tendrá un

alcance mundial ya que la aplicación estará funcionando en Internet y estará disponible su código.

Cualquier institución educativa, puede utilizar el sistema, modificando los tipos de cuentas y el catálogo de bienes respectivamente de acuerdo a su realidad.

Capítulo II: Planteamiento del problema.

14

CAPÍTULO III MARCO TEÓRICO

CAPÍTULO III MARCO TEÓRICO
3.1. SITIO WEB DINÁMICO. Según Cranford (2005), señala que: Sitio Web dinámico puede significar muchas cosas, dependiendo de con quién estemos hablando (y quizá incluso de cuándo estemos hablando). Sin embargo, en su forma más simple, significa que la información se presenta activamente, de modo que el visitante participa de alguna forma, en lugar de ser simplemente un espectador pasivo. Un sitio Web dinámico permite al usuario interactuar con el contenido. Tenemos los siguientes componentes en la arquitectura básica de un Sitio Web dinámico: • Servidor Web. El servidor Web es un programa que corre sobre el servidor que escucha las peticiones HTTP que le llegan y las satisface. Dependiendo del tipo de la petición, el servidor Web buscara una página Web o bien ejecutará un programa en el servidor. De cualquier modo, siempre devolverá algún tipo de resultado HTML al cliente o navegador que realizó la petición, son servidores Web: Internet Information Server, Apache, etc. • Pagina de Servidor. Pagina Web que necesita procesamiento en el lado del servidor (Página Dinámica), representa las reglas de negocio, tiende a modificar el estado del negocio en el servidor, tiene acceso a todos los recursos del servidor (base de datos, sistemas heredados,

componentes de lógica de negocio), Construye las páginas HTML y los envía al Browser que los solicitó, el lenguaje a utilizar pueden ser ASP, PHP, JSP, etc.

Capítulo III: Marco teórico.

15

Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor Web. • Base de datos. Ofrece la estructura para alojar los datos. Tenemos como base de datos a MySQL, Firebird, SQL Server y otros. • Navegadores. Constituye el software cliente que presenta la interfaz para el

usuario ejemplo: Internet Explorer para Sistemas operativos Windows, Firefox para Sistemas operativos Linux y Windows, Opera, etc.

3.2. APLICATIVO WEB. Según Pressman (2002), señala que: Las aplicaciones Web hacen posible que una población extensa de

usuarios finales dispongan de una gran variedad de contenido y funcionalidad. Cada vez es más importante la necesidad de construir sistemas fiables,

utilizables y adaptables. Esta es la razón por la que es necesario un enfoque disciplinado para el desarrollo de las aplicaciones Web. Podemos decir que una aplicación Web extiende un Sitio Web,

permitiendo al usuario invocar la lógica del negocio. Es necesario utilizar la ingeniería en su desarrollo (Ingeniería Web). En los últimos años las aplicaciones Web han sufrido un gran auge gracias en gran parte a Internet y la proliferación de sitios Web, sobre todo con el fin de fomentar el comercio electrónico. La facilidad de uso de los interfaces Web y el hecho de que cada día más personas están acostumbradas a la navegación por Internet hace que el tiempo de aprendizaje se reduzca considerablemente respecto a aplicaciones tradicionales.

Capítulo III: Marco teórico.

16

El auge de multitud de soluciones o frameworks open source hace que su desarrollo sea sencillo y que un gran número de desarrolladores tengan experiencia con ellos. 1. Componentes Básicos. • • • • Navegador del Cliente. Servidor Web. Servidor de Aplicaciones. Servidor de Base de Datos.

2. Componentes Avanzados. • Scripts del cliente Los scripts del cliente son por lo general código JavaScript,

mezclados con código XHTML, cuando el browser ejecuta un script en el cliente, éste no tiene acceso director a los recursos del servidor. • Applets. Componente Java que esta compuesto por 2 archivos uno con extensión java que describe al applets mismo y otro con extensión class que es el applets compilado. • Controles Active X Son componentes de Microsoft y permite asignar a las páginas Web efectos multimedia y otros, compatible con Internet Explorer. • Objetos Distribuidos Son componentes que brindan determinado servicio y radican en el servidor Web para comunicarse con el aplicativo cliente. Utilizan protocolos de conexión como DCOM para la Tecnología Microsoft y RMI para la tecnología JAVA.

Capítulo III: Marco teórico.

17

3.3. MODELO DE OBJETOS DE DOCUMENTO Eidos (2000), señala que: “El modelo de objetos esta diseñado para convertir el lenguaje HTML en DHTML a esto se le denomina DOM (Modelo de Objetos de Documento). Es algo que debe ser aportado por el propio navegador (generalmente, en forma de una DLL que se carga al abrir el programa explorador) y que modifica la forma en que las páginas Web son procesadas.” DOM es lo que convierte el HTML estático en dinámico, y podemos entenderlo como la forma en la que los exploradores interpretan una página desprovista de comportamientos programables, transformando sus elementos en objetos, que como tales, poseen propiedades, métodos y eventos, y que por lo tanto, se convierten en entidades programables. Esta era la base del dinamismo del nuevo HTML, junto a la incorporación de algunas etiquetas nuevas que permiten aplicar estilos de forma global, como <SPAN> y <DIV>. Wikipedia (2007a), al respecto, señala que la guerra entre navegadores que hubo entre el Netscape Navigator y el Internet Explorer de Microsoft creó graves problemas para los programadores de páginas Web, ya que, aunque ambos navegadores utilizaban Javascript como lenguaje de programación, los objetos no se comportaban de la misma forma, lo que obligaba con frecuencia a programar dos veces las páginas, una para el Netscape, y otra para el Explorer; aun así, seguían teniendo problemas, ya que no todas las versiones de un mismo navegador se comportaban igual. Finalmente, el W3C, el consorcio encargado de definir los estándares de la Web, decidió crear un modelo de objetos único, el DOM, para que todos los fabricantes pudieran adoptarlo, facilitando la compatibilidad plena entre ellos. No obstante, Microsoft ha añadido su propia extensión al DOM, creando problemas de interoperabilidad para los navegadores Web. Como el navegador de Microsoft, Internet Explorer, es desde el año 2002 el navegador Web estándar de facto, esto lleva a un problema real a los

Capítulo III: Marco teórico.

18

desarrolladores de navegadores más comprometidos con los estándares, como Mozilla. Si adoptan las extensiones de Microsoft al DOM, se arriesgan a perder credibilidad en sus llamadas a que los sitios Web respeten el estándar, y si no lo hacen, se arriesgan a alienar a sus usuarios por la pérdida de compatibilidad con casi todos los sitios Web que utilizan las extensiones de Microsoft. Los críticos ven esta actitud como otro caso de aplicación de la táctica de Microsoft de "adoptar, extender y extinguir". Esto puede ser considerado irónico, debido a que tanto Microsoft como Netscape fueron responsables de proporcionar extensiones no estándares en la "carrera armamentística" por el control del estándar, y Mozilla surgió como una iniciativa de Netscape. La opinión general parece indicar que esto cambiará sólo si nuevos navegadores que respeten los estándares ganan una cuota de mercado significativa en la Web, de forma que el uso de extensiones no estándares se convierta en un problema comercial para los autores de los sitios Web que las usen. Se espera que en un futuro, cuando Internet Explorer 7 comience a ser utilizado masivamente, vale aclarar que es el explorador por defecto del nuevo sistema operativo de Microsoft Windows Vista, los estándares Web comiencen a ser cumplidos más estrictamente ya que este nuevo explorador promete acatar los estándares.

3.4. AJAX Según Garret (2005), explica que AJAX no es una tecnología. Es realmente muchas tecnologías, cada una floreciendo por su propio mérito, uniéndose en poderosas nuevas formas. AJAX incorpora:

-

Presentación basada en estándares usando XHTML y CSS. Exhibición e interacción dinámicas usando el Document Object Model (DOM).

Capítulo III: Marco teórico.

19

-

Intercambio y manipulación de datos usando XML y XSLT. Recuperación de datos asincrónica usando XMLHttpRequest. JavaScript.

El modelo clásico de aplicaciones Web funciona de esta forma: La mayoría de las acciones del usuario en la interfaz disparan un requerimiento HTTP al servidor Web. El servidor efectúa un proceso (recopila información, procesa números, hablando con varios sistemas propietarios), y le devuelve una pagina HTML al cliente.

Figura 3. El modelo tradicional para las aplicaciones Web (izq.) comparado con el modelo de AJAX (der.). El término "AJAX" fuese creado en 2005, la historia de las tecnologías que permiten AJAX se remonta a una década antes con la iniciativa de Microsoft en el desarrollo de Scripting Remoto. Sin embargo, las técnicas para la carga asíncrona de contenidos en una página existente sin requerir recarga completa Capítulo III: Marco teórico. 20

remontan al tiempo del elemento iframe (introducido en Internet Explorer 3 en 1996) y el tipo de elemento layer (introducido en Netscape 4 en 1997, abandonado durante las primeras etapas de desarrollo de Mozilla). Ambos tipos de elemento tenían el atributo src que podía tomar cualquier dirección URL externa, y cargando una página que contenga javascript que manipule la página paterna, pueden lograrse efectos parecidos al AJAX. El Microsoft's Remote Scripting (o MSRS, introducido en 1998) resultó un sustituto más elegante para estas técnicas, con envío de datos a través de un applet Java el cual se puede comunicar con el cliente usando JavaScript. La comunidad de desarrolladores web, primero colaborando por medio del grupo de noticias microsoft.public.scripting.remote y después usando blogs,

desarrollaron una gama de técnicas de scripting remoto para conseguir los mismos resultados en diferentes navegadores. Los primeros ejemplos incluyen la librería JSRS en el año 2000, la introducción a la técnica imagen/cookie en el mismo año y la técnica JavaScript bajo demanda (JavaScript on Demand) en 2002. En ese año, se realizó una modificación por parte de la comunidad de usuarios al Microsoft's Remote Scripting para reemplazar el applet Java por XMLHttpRequest. Si estuviéramos diseñando la Web desde cero para aplicaciones, no querríamos hacer esperar a los usuarios. Una vez que la interfaz esta cargada, ¿Porque la interacción del usuario debería detenerse cada vez que la aplicación necesita algo del servidor? De hecho, ¿Porque debería el usuario ver la aplicación dirigiéndose al servidor? Una aplicación AJAX elimina la naturaleza arrancar-frenar- arrancar-frenar de la interacción en la Web introduciendo un intermediario -un motor AJAXentre el usuario y el servidor. Parecería que sumar una capa a la aplicación la haría menos reactiva, pero la verdad es lo contrario. En vez de cargar un pagina Web, al inicio de la sesión, el navegador carga al motor AJAX (escrito en JavaScript). Este motor es el responsable por renderizar la interfaz que el usuario ve y por comunicarse con el servidor en nombre del usuario. El motor AJAX permite que la interacción del usuario con la aplicación suceda asincrónicamente (independientemente de la 21

Capítulo III: Marco teórico.

comunicación con el servidor). Así el usuario nunca estará mirando una ventana en blanco del navegador y un icono de reloj de arena esperando a que el servidor haga algo.

Figura 3-2: El patrón de interacción sincrónica de una aplicación Web tradicional (arriba) comparada con el patrón asincrónico de una aplicación AJAX (abajo). Capítulo III: Marco teórico. 22

Cada acción de un usuario que normalmente generaría un requerimiento HTTP toma la forma de un llamado JavaScript al motor AJAX en vez de ese requerimiento. Cualquier respuesta a una acción del usuario que no requiera un viaje de vuelta al servidor (como una simple validación de datos, edición de datos en memoria, incluso algo de navegación) es manejada por su cuenta. Si el motor necesita algo del servidor para responder (sea enviando datos para procesar, cargar código adicional, o recuperando nuevos datos) hace esos pedidos asincrónicamente, usualmente usando XML, sin frenar la interacción del usuario con la aplicación. Quien está usando AJAX. Google está haciendo una significativa inversión en el acercamiento AJAX. Todos los grandes productos que Google ha introducido en el ultimo año (Orkut, Gmail, Google Shuttle, la última versión de Google Groups, Google Suggest, y Google Maps) son aplicaciones AJAX. Otros están siguiendo la tendencia: muchas de las funciones que la gente ama en Flickr dependen de AJAX, y el motor de búsqueda de Amazon A9.com aplica tecnologías similares. Las aplicaciones AJAX pueden ser de cualquier tamaño, de simples funciones como Google Suggest a las muy complejas y sofisticadas como Google Maps, Google Spreadsheet (Hoja de calculo online), Google Doc. (Writely-Procesador de texto en línea), AjaxWrite (Procesar de texto en línea). Vemos que AJAX es un desarrollo importante para las aplicaciones Web, y su importancia solo va a crecer. Y como hay tantos desarrolladores que ya conocen como usar estas tecnologías, esperamos ver mas empresas y organizaciones siguiendo el liderazgo de Google en explotar la ventaja competitiva que AJAX provee.

3.5. WEB 2.0 La Web 2.0 es la representación de la evolución de las aplicaciones tradicionales hacia aplicaciones Web enfocadas al usuario final. El Web 2.0 es una actitud y no precisamente una tecnología. Capítulo III: Marco teórico. 23

Cuando el Web inició, nos encontrábamos en un entorno estático, con páginas en HTML que sufrían pocas actualizaciones y no tenían interacción con el usuario. La Web 2.0 es la transición que se ha dado de aplicaciones tradicionales hacia aplicaciones que funcionan a través de la Web enfocadas al usuario final. Se trata de aplicaciones que generen colaboración y de servicios que reemplacen las aplicaciones de escritorio. Todo inició cuando Dale Dougherty de O’Reilly Media utilizó este término en una conferencia en la que compartió una lluvia de ideas junto a Craig Cline de MediaLive en la que hablaba del renacimiento y evolución de la Web. Constantemente estaban surgiendo nuevas aplicaciones y sitios con sorprendentes funcionalidades. Y así se dio la pauta para la Web 2.0

conference de 2004. Esta conferencia no solo fue exitosa sino que ya tuvo seguimiento en la Web 2.0 Conference del 2005 celebrada en Octubre. En la charla inicial del Web Conference se habló de los principios que tenían las aplicaciones Web 2.0: • • • • La Web es la plataforma La información es el procesador Efectos de la red movidos por una arquitectura de participación. La innovación surge de características distribuidas por

desarrolladores independientes. • El fin del círculo de adopción de software ("Servicios en beta perpetuo"). A. La Web 2.0 con ejemplos La forma más fácil de comprender lo que significa la Web 2.0 es a través de ejemplos. Podemos comparar servicios Web que marcan claramente la evolución hacia el Web 2.0:

Capítulo III: Marco teórico.

24

Web 1.0 > Web 2.0 Doubleclick –> Google AdSense (Servicios Publicidad) Ofoto –> Flickr (Comunidades fotográficas) Akamai –> BitTorrent (Distribución de contenidos) mp3.com –> Napster (Descargas de música) Britannica Online –> Wikipedia (Enciclopedias) Sitios personales –> Blogs (Páginas personales) Especulación con dominios –> Optimización en motores de búsqueda Page views –> Cost per click CMSs –> Wikis (Manejo de contenidos) Categorías/Directorios –> Tagging B. ¿Qué tendencias y tecnologías apoyan a la Web 2.0? El Web 2.0 no significa precisamente que existe una receta para que todas nuestras aplicaciones Web entren en este esquema. Sin embargo, existen varias tecnologías que están utilizándose actualmente y que deberíamos de examinar con más cuidado en busca de seguir evolucionando junto a la Web. • Transformar software de escritorio hacia la plataforma del Web. • • Respeto a los estándares del XHTML. Separación de contenido del diseño con uso de hojas de estilo. • Sindicación de contenidos. 25

Capítulo III: Marco teórico.

• • • •

AJAX (Asincronical javascript and xml). Uso de Flash, Flex o Lazlo. Uso de Ruby on Rails para programar páginas dinámicas. Utilización de redes sociales al manejar usuarios y

comunidades. • Dar control total a los usuarios en el manejo de su información. • Proveer APIS o XML para que las aplicaciones puedan ser manipuladas por otros. • Facilitar el posicionamiento con URL sencillos.

C. ¿En qué nos sirve la Web 2.0? El uso del término de Web 2.0 está de moda, dándole mucho peso a una tendencia que ha estado presente desde hace algún tiempo. En Internet las especulaciones han sido causantes de grandes burbujas tecnológicas y han hecho fracasar a muchos proyectos. Además, evolucionar. nuestros proyectos tienen que renovarse y

El Web 2.0 no es precisamente una tecnología, sino

es la actitud con la que debemos trabajar para desarrollar en Internet. D. La Web como plataforma Y no se refiere sólo a esas maravillosas aplicaciones que se ejecutan a través de la Web, dejando atrás el sistema operativo. En la visión de O'Reilly, las Web es un tejido vivo, sobre la cual puede basarse desde un programa hasta una base de datos colaborativa.

Capítulo III: Marco teórico.

26

Precisamente, ejemplifica el caso con BitTorrent, el popular sistema de intercambio de archivos: "Como otros pioneros del movimiento P2P (persona a persona), BitTorrent adopta una perspectiva radical de la descentralización de Internet donde cada cliente es al mismo tiempo servidor. De esta forma se demuestra un punto clave de la Web 2.0: entre más gente utilice el servicio, mejor se pone". E. Enlazar inteligencia colectiva Se refiere a que si en la antigua Web el conocimiento estaba relacionado a través de hipervínculos, directorios como Yahoo o motores de búsqueda, en la Web 2.0 se agregan compendios activos como la Wikipedia, Flickr, etiquetas (tags) que clasifican y asocian en directo la información, sindicaciones RSS que la llevan a los usuarios o – sin ir más lejos – los proyectos de código abierto, desarrollados y distribuidos en línea. O'Reilly hace un dictamen claro de este punto: Los efectos en red de las contribuciones de los usuarios serán la llave para conquistar mercados en la era de la Web 2.0. F. Los datos son el próximo 'Intel Inside' Cuando Intel cambió su giro de los chips de memoria a los procesadores, se enfrentó al desafío de dar valor a un producto que solía pasar desapercibido como una pieza más entre los componentes de un ordenador. Tras varias jugadas estratégicas y una astuta campaña de promoción, Intel no sólo logró posicionar su marca para que "no diera lo mismo", sino que creó un capital invaluable del que hasta hoy disfruta. En la misma forma que los computadores y el procesador, la Web ofrece servicios que funcionan sobre bases de datos ocultas a simple vista, pero verdaderas esencias del sistema. El mejor ejemplo lo ofrecen los servicios de mapas de Google, Yahoo o Capítulo III: Marco teórico. 27

Microsoft, servidos por empresas desconocidas como NavTeq o DigitalGlobe. Ellas son las verdadera dueñas del negocio, así como Amazon posee una base de datos que desbordó a gigantes como Barnes&Noble, o Technorati se ha establecido sobre la blogósfera. G. Fin de los ciclos de renovación de software Para O'Reilly no hay duda: una de las características principales de la era Internet es que el software deja de ser un producto para transformarse en un servicio. De esta forma, tanto los modelos de de negocio como los de desarrollo deben adaptarse a una realidad en que los ciclos pasan a ser un continuo. ¿Cuántos servicios Web – como Gmail, Google Maps, You Tube, Flickr o Delicio.us – se mantienen en un estado "beta" perpetuo?, algo que sería impensable para un producto a la venta en tiendas. Las actualizaciones se realizan cada semana, cada día e incluso cada hora, adaptándolo a los requerimientos de los usuarios, quienes a su vez se transformar en una especie de codesarrolladores, especialmente en proyectos open source. H. Modelos livianos de programación Aunque hablamos de un nivel más técnico, la simplicidad sigue siendo clave y más aún a la hora de implementar servicios o soluciones de software. La Web adopta cada vez con más fuerza estándares sencillos, de carga liviana, como la sindicación via RSS o la compatibilidad con XML. La misma idea subyace tras AJAX: reemplazar sistemas de producción propietarios y complejos como Java o Flash con un conjunto de técnicas livianas. I. Software por sobre un solo dispositivo Durante años, Internet era sinónimo de un PC. Hoy, una amplia gama de dispositivos son capaces de conectarse a la red, incluyendo PDAs, televisores (WebTV), reproductores de música,

Capítulo III: Marco teórico.

28

automóviles e incluso otros más inesperados como refrigeradores o lavadoras. Dado que la barrera del acceso es cada vez menor, las aplicaciones y servicios de la Web 2.0 deberían estar preparadas para funcionar con independencia del sistema o plataforma de entrada. Es más, O'Reilly destaca cadenas como la formada por iTunes e iPod, donde el computador funciona como el entorno de 'trabajo' para luego ser descargado al reproductor para su ejecución. J. Experiencias de usuario enriquecidas Y aquí es un solo nombre el que domina este punto: AJAX. El conjunto de tecnologías inherentes a los navegadores y capaces de crear experiencias interactivas e instantáneas para los usuarios, interesa cada vez más a los desarrolladores por sus múltiples beneficios, en especial desde la salida de Gmail y Google Maps. Es rápida, compatible, no requiere plugins adicionales, flexible y, por sobre todo, gratuita. La Web 2.0 engloba un conjunto fascinante de perspectivas de desarrollo, pero para muchos usuarios también conlleva una forma de pensar el ciberespacio. Tras años de una comercialización forzada que violentó el antiguo espíritu académico y colaborativo de la red, esta nueva perspectiva podría perfilarse como una conciliación de ambos factores. Dejando de lado esto, los diseñadores de interacción Web no pueden evitar sentirse envidiosos de nuestros colegas que crean software de escritorio. Las aplicaciones de escritorio tienen una riqueza y respuesta que parecía fuera del alcance en Internet. La misma simplicidad que ha permitido la rápida proliferación de la Web también crea una brecha entre las experiencias que podemos proveer y las experiencias que los usuarios pueden lograr de las aplicaciones de escritorio. Esa brecha se está cerrando. Una mirada a las Google Suggest. Mira la forma en que los términos sugeridos se van actualizando a medida que uno Capítulo III: Marco teórico. 29

tipea casi instantáneamente. Ahora mire Google Maps. Hace zoom. Usen el cursor para agarrar el mapa y navegarlo un poco. Otra vez, todo sucede casi instantáneamente, sin esperar que las páginas se recarguen.

3.6. XHTML Según Duckett (2005), explica que HTML ha sido reemplazado con un lenguaje nuevo que ha cambio en la forma de marcado, tiene una sintaxis ligeramente refinada porque el sucesor para lenguaje llamado XML. Por lo tanto el nombre ha cambiado a XHTML. Esto asegura que el HTML esta escrito en un

lenguaje más usado en la Web hoy, permanecerá tan Popular por varios largos años venidero, aun si los dispositivos comienzan a emerger. La necesidad de una versión más estricta de HTML se sintió principalmente porque el contenido de la World Wide Web ahora puede visualizarse desde numerosos dispositivos (como móviles) aparte de los ordenadores nuevos con capacidades diferentes

tradicionales, donde no pueden dedicarse recursos suplementarios para afrontar la complejidad añadida de la sintaxis del HTML. La mayoría de las versiones recientes de los navegadores Web más populares soportan XHTML adecuadamente, pero algunas versiones más antiguas solo pueden leer el XHTML como si se tratara de HTML. Asimismo casi todos los navegadores que son compatibles con XHTML también leen HTML correctamente. Algunos argumentan que esta compatibilidad ralentiza el cambio de HTML a XHTML. En octubre de 2005 aproximadamente el 10% de los internautas utilizaban un navegador compatible con el estándar XHTML. El Internet Explorer de Microsoft es incompatible con XHTML, a pesar de que esta empresa sea miembro de la W3C. Por tanto, gran parte de los autores de sitios Web se ven forzados a elegir entre la escritura de documentos válidos, respetuosos con los estándares u ofrecer contenido que se visualice correctamente en la mayor parte de los navegadores.

Capítulo III: Marco teórico.

30

A. Ventajas Las principales ventajas del XHTML sobre otros formatos son:

Compatibilidad

parcial

con

navegadores

antiguos:

la

información se visualiza, aunque sin formato. Cabe apuntar que el XHTML 1.0 fue diseñado expresamente para ser mostrado en navegadores que soportan HTML de base.

Un mismo documento puede adoptar diseños radicalmente distintos en diferentes dispositivos, pudiendo incluso escogerse entre varios diseños para un mismo medio.

• •

Facilidad de edición directa del código y de mantenimiento. Formato abierto, compatible con los nuevos estándares que actualmente está desarrollando el W3C como recomendación para futuros agentes de usuario o navegadores.

Los documentos escritos conforme a XHTML 1.0 pueden potencialmente presentar mejor rendimiento en las actuales herramientas Web que aquellos escritos conforme a HTML.

B. Inconvenientes.

Algunos navegadores antiguos no son totalmente compatibles con los estándares, lo que hace que las páginas no siempre se muestren correctamente. Esto cada vez es menos

problemático, al ir cayendo en desuso.

Muchas herramientas de diseño Web aún no producen código XHTML correcto.

3.7. JAVASCRIPT (Vila, 2001), es un lenguaje de programación creado por la empresa Netscape (creadora de uno de los navegadores más conocido). Es el lenguaje de programación más utilizado en Internet para añadir interactividad a las Capítulo III: Marco teórico. 31

páginas Web. No confundir el JavaScript con el Java. El Java es un lenguaje de programación de propósito general como lo son el C++. Un programa en JavaScript se integra en una página Web (entre el código HTML) y es el navegador el que lo interpreta (ejecuta). Es decir el JavaScript es un lenguaje interpretado, no compilado (no se genera ningún tipo de fichero objeto o exe). Para programar en JavaScript sólo necesitamos un editor de texto y un navegador (utilizaremos el Microsoft Internet Explorer) para ejecutarlo. (Wikipedia, 2007b), el lenguaje fue inventado por Brendan Eich en la empresa Netscape Communications, que es la que fabricó los primeros navegadores Web comerciales. Apareció por primera vez en el producto de Netscape llamado Netscape Navigator 2.0. Tradicionalmente, se venía utilizando en páginas Web HTML, para realizar tareas y operaciones en el marco de la aplicación únicamente cliente, sin acceso a funciones del servidor. JavaScript se ejecuta en el agente de usuario al mismo tiempo que las sentencias van descargándose junto con el código HTML. Los autores inicialmente lo llamaron Mocha y más tarde LiveScript pero fue rebautizado como JavaScript en un anuncio conjunto entre Sun Microsystems y Netscape, el 4 de diciembre de 1995. En 1997 los autores propusieron JavaScript para que fuera adoptado como estándar de la the European Computer Manufacturers' Association ECMA, que a pesar de su nombre no es europeo sino internacional, con sede en Ginebra. En junio de 1997 fue adoptado como un estándar ECMA, con el nombre de ECMAScript. Poco después también lo fue como un estándar ISO. JScript es la implementación de ECMAScript de Microsoft, muy similar al JavaScript de Netscape, pero con ciertas diferencias en el modelo de objetos del navegador que hacen a ambas versiones con frecuencia incompatibles. Para evitar estas incompatibilidades, el World Wide Web Consortium diseñó el estándar Document Object Model (DOM, ó Modelo de Objetos del Documento en castellano), que incorporan Konqueror, las versiones 6 de Internet Explorer y Netscape Navigator, Opera versión 7, y Mozilla desde su primera versión.

Capítulo III: Marco teórico.

32

3.8. HOJAS DE ESTILO EN CASCADA (CSS). (Wikipedia, 2007c), las hojas de estilo en cascada (Cascading Style Sheets) es un lenguaje formal usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML). El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirá de estándar para los agentes de usuario o navegadores. La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación. La información de estilo puede ser adjuntada tanto como un documento separado o en el mismo documento HTML. En este último podrían definirse estilos generales en la cabecera del documento o en cada etiqueta particular mediante el atributo "style".

3.9. XML (Posadas, 2000), XML se considera un subconjunto de otra especificación superior (bastante más compleja), que establece cómo deben de hacerse los lenguajes de marcas de cualquier tipo (SGML o Standard Generalized Markup Language), y que ha sido adaptada para el almacenamiento de datos. En SGML, se hace, por primera vez, distinción entre el contenido y la presentación, tal y como encontramos en la siguiente definición, cita en una página sobre SGML (Oviedo, 2004), SGML permite que la estructura de un documento pueda ser definida basándose en la relación lógica de sus partes. Esta estructura puede ser validada por una Definición de Tipo Documento (DTD - Document Type Definition). La norma SGML define la sintaxis del documento y la sintaxis y semántica de DTD. Un documento SGML se marca de modo que no dice nada respecto a su representación en la pantalla o en papel. Un programa de presentación debe unir el documento con la información de estilo a fin de producir una copia impresa en la pantalla o en el papel. La sintaxis de SGML es suficiente para sus necesidades, pero pocos pueden decir que es particularmente "bella". El lenguaje

Capítulo III: Marco teórico.

33

muestra que se originó en sistemas donde el texto era el contenido principal y el marcado era la excepción. Así pues, se define

el estándar XML como: El formato universal para documentos y datos estructurados en Internet, y podemos explicar las características de su funcionamiento a través de 7 puntos importantes, tal y como la propia W3C recomienda: 1. XML es un estándar para escribir datos estructurados en un fichero de texto 2. XML parece HTML 3. XML está en formato texto, pero no para ser leído. 4. XML consta de una familia de tecnologías. 5. XML es prolijo, pero eso no supone un problema. 6. XML es nuevo, pero no tanto. 7. XML no requiere licencias, es independiente de la plataforma, y tiene un amplio soporte. A. Ventajas del XML. • Es extensible, lo que quiere decir que una vez diseñado un lenguaje y puesto en producción, igual es posible extenderlo con la adición de nuevas etiquetas de manera de que los antiguos consumidores de la vieja versión todavía puedan entender el nuevo formato. • El analizador es un componente estándar, no es necesario crear un analizador específico para cada lenguaje. Esto posibilita el empleo de uno de los tantos disponibles. De esta manera se evitan bugs y se acelera el desarrollo de la aplicación. • Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarlo. Mejora la compatibilidad entre aplicaciones. Capítulo III: Marco teórico. 34

B. Estructura de un documento XML. La tecnología XML busca dar solución al problema de expresar información estructurada de la manera más abstracta y reutilizable posible. Que la información sea estructurada quiere decir que se compone de partes bien definidas, y que esas partes se componen a su vez de otras partes. Entonces se tiene un árbol de pedazos de información. Ejemplos son un tema musical, que se compone de compases, que están formados a su vez con notas. Estas partes se llaman elementos, y se las señala mediante etiquetas. Una etiqueta consiste en una marca hecha en el documento, que señala una porción de este como un elemento, un pedazo de información con un sentido claro y definido. Las etiquetas tienen la forma <nombre>, donde nombre es el nombre del elemento que se está señalando. A continuación se muestra un ejemplo para entender la estructura de un documento XML:
<?xml version=”1.0”?> <!DOCTYPE MENSAJE SYSTEM “mensaje.dtd”> <mensaje> <remitente> <nombre>CORSITEC</nombre> <mail>corsiteccgmr@gmail.com</mail> </remitente> <destinatario> <nombre>Helwer</nombre> <mail>helwer_acv@hotmail.com</mail> </destinatario> <asunto>Hola Helwer</asunto>

Capítulo III: Marco teórico.

35

<texto> <parrafo>¿Hola que tal?, hace <enfasis>mucho</enfasis> que no escribes. A ver si llamas y quedamos en cenar. </parrafo> </texto> </mensaje>

3.10. RSS

(Wikipedia, 2007d), RSS no es otra cosa que un sencillo formato de datos que es utilizado para sindicar (redifundir) contenidos a suscriptores de un sitio web. El formato permite distribuir contenido sin necesidad de un navegador, lo cual también puede verse como desventaja ya que necesita de la instalación de otro software. Algunos adelantos han permitido utilizar el mismo navegador para ver los contenidos RSS mediante programación de los denominados scripts de interpretación. Así también las nuevas versiones de los navegadores permitirán leer los RSS sin necesidad de software adicional. El acrónimo se usa para los siguientes estándares:
• • •

Rich Site Summary (RSS 0.91) RDF Site Summary (RSS 0.9 y 1.0) Really Simple Syndication (RSS 2.0)

Los programas que leen y presentan fuentes RSS de diferentes procedencias se denominan agregadores. Gracias a los agregadores o lectores de feeds (programas o sitios que permiten leer fuentes web) se puede obtener resúmenes de todos los sitios que se desee desde el escritorio de tu sistema operativo, programas de correo electrónico o por medio de aplicaciones web que funcionan como agregadores. No es necesario abrir el navegador y visitar decenas de webs. La sindicación web no es sólo un fenómeno vinculado a

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->