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

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 AMOR Y

ETERNA GRATITUD POR HABERME
APOYADO CON SUS CONSEJOS Y A DAR
CULMINACIÓN MIS ESTUDIOS.
A LA MAGISTER DIANA MUÑOZ CASANOVA POR

BRINDARME SU AMISTAD Y ASESORAMIENTO EN
EL DESARROLLO DEL PROYECTO.
AL PROMOTOR DE LA ORGANIZACIÓN
GALILEO JORGE VIDAL MONTERO POR
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 presente informe de Práctica
Pre – Profesional titulado:
“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 extremeprogramming 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 DE LA INSTITUCIÓN
EDUCATIVA PRONOE GALILEO”, el cual esta estructurado de la siguiente
manera:
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 i
DEDICATORIA ii
PRESENTACIÓN iii
RESUMEN iv
ABSTRACT v
INTRODUCCIÓN vi-viii
CAPÍTULO I:
DE LA INSTITUCIÓN 1-7
1.1. RAZÓN SOCIAL. 1
1.2. UBICACIÓN. 1
1.3. DESCRIPCIÓN DE LA INSTITUCIÓN. 1
1.4. MISIÓN. 2
1.5. VISIÓN. 2
1.6. OBJETIVOS. 2-3
1.7. PRINCIPIOS INSTITUCIONALES. 3-4
1.8. MERCADO. 4
1.9. SERVICIOS QUE BRINDA LA INSTITUCIÓN. 4-5

1.10. ORGANIGRAMA ESTRUCTURAL DE LA INSTITUCIÓN. 6
1.11. ORGANIGRAMA FUNCIONAL DE LA INSTITUCIÓN. 7
CAPÍTULO II:
PLANTEAMIENTO DEL PROBLEMA. 8-14
2.1. REALIDAD PROBLEMÁTICA. 8-9
2.2. FORMULACIÓN DEL PROBLEMA. 9
2.3. JUSTIFICACIÓN DEL PROYECTO. 9-10
2.4. HIPOTESÍS. 11
2.5. VARIABLES. 11
2.6. OBJETIVOS. 11-13
2.7. ANTECEDENTES. 13
2.8. METODOLOGÍA EMPLEADA. 13
2.9. ALCANCE. 14
CAPITULO III:
MARCO TEÓRICO. 15-71
3.1. SITIO WEB DINÁMICO. 15-16
3.2. APLICATIVO WEB. 16-17
3.3. MODELO DE OBJETOS DE DOCUMENTO. 18-19
3.4. AJAX. 19-23
3.5. WEB 2.0. 23-29

3.6. XHTML. 30-31
3.7. JAVASCRIPT. 31-32
3.8. HOJAS DE ESTILO EN CASCADA (CSS). 32-33
3.9. XML. 33-36
3.10. RSS. 36-37
3.11. YOUTUBE. 37
3.12. MASHUP. 37-38
3.13. YAHOO PIPES. 38
3.14. SERVIDOR HTTP APACHE. 38-39
3.15. PHP. 39-40
3.16. MySQL. 40-41
3.17. DBDESIGNER4. 41
3.18. ARGOUML 42-43
3.19. TECNOLOGÍA WAP. 43-44
3.20. PROGRAMACIÓN ORIETANDA A OBJETOS. 44-49
3.21. MACROMEDIA DREAMWEAVER. 49-50
3.22. WINDOWS 2003 SERVER. 50-51
3.23. LENGUAJE UNIFICADO DE MODELADO. 51-53
3.24. APLICACIONES EN CAPAS. 53-54
3.25. CONTABILIDAD. 54-56
3.26. CONTROL DE INVENTARIOS 56

3.27. METODOLOGÍA PROGRAMACIÓN EXTREMA (XP). 56-71
CAPITULO IV:
METODOLOGÍA. 72-214
4.1 . RESUMEN DE LA METODOLOGÍA APLICADA (XP). 72-75
4.2 . APLICACIÓN DE LA METODOLOGÍA XP. 76-214
1. EXPLORACIÓN. 76-98
A. DESCRIPCIÓN DE LOS PROCESOS ACTUALES

EN LA TOMA DE INVENTARIOS DE LA INSTITUCIÓN
EDUCATIVA PRONOE GALILEO. 76-77
B. DESCRIPCIÓN DEL REGISTRO EN EL CATÁLOGO. 77-78
C. DESCRIPCIÓN DEL REGISTRO DEL DOCUMENTO

DE INVENTARIO. 78-79
D. DESCRIPCIÓN DE LAS CONSULTAS. 79
E. DESCRIPCIÓN DE LOS REPORTES. 79
F. DESCRIPCIÓN DEL BALANCE DE INVENTARIO. 80
G. MODELO DEL SISTEMA ACTUAL. 80
H. HISTORIAS DE USUARIO (USER STORIES). 80-96
I. HERRAMIENTAS. 96-97
J. TECNOLOGÍAS. 98
K. PROTOTITPO. 98
2. PLANIFICACIÓN DE LAS ENTREGAS. 98-105
A. ESTIMACIONES DE ESFUERZO. 99-101
B. PLANIFICACIÓN. 101-105
3. ITERACIONES. 106-213
A. PRIMERA ITERACIÓN. 106-143

B. SEGUNDA ITERACIÓN. 144-155
C. TERCERA ITERACIÓN. 156-175
D. CUARTA ITERACIÓN. 176-213
4. PRODUCCIÓN. 214
CAPITULO V:
EVALUACIÓN DEL SISTEMA. 215-222
5.1. EVALUACIÓN ECONÓMICA. 215-219
5.2. ANÁLISIS DE LOS BENEFICIOS. 219-220
5.3. CÁLCULO DE LA RECUPERACIÓN DE LA INVERSIÓN. 220-222
CONCLUSIONES. 223
RECOMENDACIONES. 224
REFERENCIA BIBLIOGRÁFICA. 225-228
ANEXOS.
ÍNDICE DE TABLAS
Pág.
Tabla 1. Lenguajes Orientados a Objetos. 48
Tabla 2. Estructura del código de los tipos de Bien. 78
Tabla 3. Algunos códigos del catálogo. 78
Tabla 4. Acciones de los Personajes que interactúan

con el Sistema. 83
Tabla 5. Funcionalidad común. 99
Tabla 6. Gestión de Usuario. 99
Tabla 7. Gestión de la Institución. 100
Tabla 8. Gestión de Inventario. 100
Tabla 9. Gestión del Personal. 100
Tabla 10. Gestión de las cuentas contables. 101
Tabla 11. Fechas de entrega. 102
Tabla 12. Historias Primera Iteración. 103
Tabla 13. Historias Segunda Iteración. 104
Tabla 14. Historias Tercera Iteración. 104
Tabla 15. Historias Cuarta Iteración. 105
Tabla 16. Detalle - Historias Primera Iteración. 106
Tabla 17. Detalle - Historias Segunda Iteración. 144

Tabla 18. Detalle - Historias Tercera Iteración. 156
Tabla 19. Detalle - Historias Cuarta Iteración. 181
Tabla 20. Tiempo del desarrollo del sistema. 215
Tabla 21. Costo inicial del sistema. 216
Tabla 22. Costo de materiales. 217
Tabla 23. Costo de equipos. 217
Tabla 24. Costo de software. 218
Tabla 25. Utilidad por año. 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 5. Arquitectura en tres Capas. 54
Figura 6. Fases de un proyecto en eXtreme Programming. 71
Figura 7. Ciclos en eXtreme Programming. 71
Figura 8. Descripción del código de un tipo de bien en catálogo. 77
Figura 9. Sistema Actual. 80
Figura 10. Arquitectura del Sistema a desarrollar. 98
Figura 11. Caso de Uso para la primera iteración. 109
Figura 12. Diagrama de clase para la primera iteración. 109
Figura 13. Interfaz - Administración. 120
Figura 14. Interfaz - Usuario. 121

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

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

Figura 57. Interfaz-Dispositivo móvil-Clave. 185
Figura 58. Interfaz-Dispositivo móvil-Consulta Personal. 186
Figura 59. Interfaz-Dispositivo móvil-Código del área del Personal. 186
Figura 60. Interfaz-Dispositivo móvil-Información del Personal. 187
Figura 61. Diseño lógico de la base de datos. 213
Figura 62. Tiempo de recuperación del capital invertido. 221
Figura 63. Fórmula para determinar el valor presente. 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 con R.D. Nº 017-99 como
Institución Educativa PRONOE GALILEO.
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 aprendizajes a través de la aplicación de

módulos y 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.

B. OBJETIVO ESPECÍFICO.
• Dar cobertura a las necesidades insatisfechas en la

educación tradicional a través de su educación
Pre Universitaria.
• 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 a las necesidades vocacionales que se
identifiquen.
• Desarrollar una actitud critica reflexiva en los

estudiantes.
• 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.

• Responsabilidad
• Respeto
• Innovación
• Justicia.
1.8. MERCADO.
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
logren ingresar a la universidad, generando entre estas instituciones
competencia académica en el compartir de sus conocimiento.
La organización Galileo gestor del modelo Pre Universitario en

nuestra localidad ha logrado que sus estudiantes ingresen a penas
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.

• 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.

1.10. ORGANIGRAMA ESTRUCTURAL DE LA INSTITUCIÓN.
Figura 1. Organigrama Estructural de la Institución Educativa

PRONOE GALILEO.

1.11. ORGANIGRAMA FUNCIONAL DE LA INSTITUCIÓN.
Figura 2. Organigrama Funcional de la Institución Educativa

PRONOE GALILEO.

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.

• 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 permite que el sistema

funcione vía WEB/WAP.
• Al desarrollar una aplicación WEB permite que funcione en

cualquier sistema operativo no requiriendo instalar otros
paquetes.
• 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.

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.

- 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 su

ubicación y estado actual en el menor tiempo.
- 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.

- 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
(Sánchez, 2007), que tiene por finalidad el desarrollo de un sistema de
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).

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

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.

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

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).

- 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

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 AJAX-
entre 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

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).

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.

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:

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.

• 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, nuestros proyectos tienen que renovarse y

evolucionar. 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.

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

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 co-
desarrolladores, 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,

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

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 HTML esta escrito en un
lenguaje llamado XML.
Por lo tanto el nombre ha cambiado a XHTML. Esto asegura que el

lenguaje más usado en la Web hoy, permanecerá tan Popular por varios largos
años venidero, aun si los dispositivos nuevos con capacidades diferentes
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
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.

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

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.

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

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.

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>

<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 los weblogs,

aunque han ayudado mucho a su popularización. Siempre se han sindicado

contenidos y se ha compartido todo tipo de información en formato XML, de
esta forma podemos ofrecer contenidos propios para que sean mostrados en
otras páginas web de forma integrada, lo que aumenta el valor de la página
que muestra el contenido y también nos genera más valor, ya que
normalmente la sindicación web siempre enlaza con los contenidos originales.
3.11. YOUTUBE.
(Wikipedia, 2007e), YouTube es un sitio web que permite a los usuarios

subir, ver y compartir clips de vídeos. Fue fundado en febrero de 2005 por tres
antiguos empleados de PayPal: Chad Hurley, Steve Chen, Jawed Karim.
YouTube usa un formato Adobe Flash para servir su contenido. Es popular de
la misma manera que lo es Google Video debido a la posibilidad de alojar
vídeos personales de manera sencilla. YouTube aloja una variedad de clips de
películas, programas de televisión, vídeos musicales, y vídeos caseros (a
pesar de las reglas de YouTube contra subir vídeos con copyright, este
material existe en abundancia). Los enlaces a vídeos de YouTube pueden ser
también puestos en blogs y sitios web personales usando APIs.
YouTube es propiedad de Google, desde su compra, 10 de octubre de 2006

por 1.650 millones de dólares.
3.12. MASHUP.
(Wikipedia, 2007f), una aplicación web híbrida (mashup o remezcla), es un

sitio web o aplicación web que usa contenido de más de una fuente para crear
un nuevo servicio completo.
El contenido usado en un mashup es típicamente usado de terceros a través

de una interfaz pública o usando un API. Otros métodos que constituyen el
origen de sus datos incluyen: sindicadores web (RSS o Atom) y JavaScript.
Así como los weblogs han revolucionado la publicación en línea, los

mashups están revolucionando el desarrollo web, permitiendo que cualquiera

combine, de forma innovadora, datos que existen en eBay, Amazon.com,
Google, Windows Live y Yahoo!. Las grandes facilidades brindadas por
simples y ligeras API's han hecho que los mashups sean relativamente fáciles
de diseñar. El que se requiera de mínimos conocimientos técnicos ha hecho
que los mashups sean creados en su mayoría de casos por innovadores,
quienes combinan en formas nuevas y creativas datos disponibles
públicamente. Así como hay mashups muy útiles, existen otros que no pasan
de sólo ser novedosos o publicitarios, con mínima utilidad práctica.
Los defensores e impulsores de las aplicaciones Web 2.0 expresan que los
mashups son un ejemplo de este nuevo movimiento con sus usuarios en activa
participación e interacción.
3.13. YAHOO PIPES.
(Carvajal, 2007), Yahoo tiene un nuevo servicio llamado Pipes (tuberías),

enfocado a la creación de mashups.
Con él se pueden crear de forma sencilla mashups de datos o reunir varios

feeds en uno sólo, recolectar información de distintas fuentes como las citas a
tu blog en otros blogs o webs, etc.
Lo bueno del sistema es que permite navegar y ver las Pipes creadas por
otros usuarios y clonarlas. De ese modo, desde tu cuenta puedes modificarlas,
por ejemplo incluyendo los datos de tu blog, y guardarlas.
3.14. SERVIDOR HTTP APACHE.
(Wikipedia, 2007g). El servidor HTTP Apache es un software (libre) servidor

HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etcétera),
Windows y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio
virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código
del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su
nombre se debe a que originalmente Apache consistía solamente en un

conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy
server (un servidor "parcheado").
El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de

la Apache Software Foundation.
Apache presenta entre otras características mensajes de error altamente

configurables, bases de datos de autenticación y negociado de contenido, pero
fue criticado por la falta de una interfaz gráfica que ayude en su configuración.
Apache tiene amplia aceptación en la red: en el 2005, Apache es el servidor

HTTP más usado, siendo el servidor HTTP del 70% de los sitios Web en el
mundo y creciendo aún su cuota de mercado (estadísticas históricas y de uso
diario proporcionadas por Netcraft).
3.15. PHP
(Welling y Thompson, 2005), PHP es un lenguaje de secuencia de

comandos de servidor diseñado específicamente para la Web. Dentro de una
página Web puede incrustar código PHP que ejecutara cada vez que se visite
una página. El código PHP es interpretado en el servidor Web y genera código
HTML y otro contenido que el visitante visitara.
Algunas de las cualidades de PHP son:
• Alto Rendimiento.
• Interfaces para diferentes sistemas de base de datos.
• Bibliotecas incorporadas para muchas tareas Web

habituales.
• Bajo coste.
• Facilidad de aprendizaje y uso.
• Portabilidad.
• Disponibilidad de código abierto.

Según Wilfred y Gupta (2002), señala que:
PHP es un preprocesador de hipertexto y como tal, se ejecuta en un

servidor Web remoto para procesar páginas Web antes de que sean cargadas
en el navegador.
PHP permite la conexión a diferentes tipos de servidores de bases de datos

tales como MySQL, PostgreSQL, Oracle, dbm, mSQL, FilePRO, HyperWave,
Informix, Internase, DB2, Microsoft SQL Server, Firebird , SQLite y otros; lo
cual permite la creación de Aplicaciones Web muy robustas.
PHP también tiene la capacidad de ser ejecutado en la mayoría de los

sistemas operativos tales como UNIX (y de ese tipo, como Linux), Windows y
Mac OS X, y puede interactuar con los servidores de Web más populares ya
que existe en versión CGI, módulo para Apache, e ISAPI.
El modelo PHP puede ser visto como una alternativa al sistema de Microsoft
que utiliza ASP.NET/C#/VB.NET, a ColdFusion de la compañía Macromedia, a
JSP/Java de Sun Microsystems, y al famoso CGI/Perl. Aunque su creación y
desarrollo se da en el ámbito de los sistemas libres, bajo la licencia GNU,
existe además un IDE comercial llamado Zend Optimizer.
3.16. MySQL
(Gilfillan, 2004), MySQL es un sistema de gestión de base de datos, multi

hilo y multiusuario con más de seis millones de instalaciones. MySQL AB
desarrolla MySQL como software libre en un esquema de licenciamiento dual.
Por un lado lo ofrece bajo la GNU GPL, pero, empresas que quieran
incorporarlo en productos privativos pueden comprar a la empresa una licencia
que les permita ese uso.
MySQL 5 es un sistema de administración de bases de datos relacional

(RDBMS). Se trata de un programa capaz de almacenar una enorme cantidad

de datos de gran variedad y de distribuirlos para cubrir las necesidades de
cualquier tipo de organización, desde pequeños establecimientos comerciales
a grandes empresas y organismos administrativos. MySQL compite con
sistemas RDBMS propietarios conocidos, como Oracle, SQL Server y DB2.
MySQL incluye todos los elementos necesarios para instalar el programa,
preparar diferentes niveles de acceso de usuario, administrar el sistema y
proteger y hacer volcados de datos. Puede desarrollar sus propias
aplicaciones de base de datos en la mayor parte de los lenguajes de
programación utilizados en la actualidad y ejecutarlos en casi todos los
sistemas operativos.
MySQL utiliza el lenguaje de consulta estructurado (SQL). Este lenguaje

permite crear bases de datos, así como agregar, manipular y recuperar datos
en función de criterios específicos.
(Welling y Thompson, 2005), en MySQL 5 podemos apreciar importantes

cambios, entre los que destacamos:
• Los procedimientos almacenados.
• La compatibilidad con cursores.
Entre otras de las novedades podemos mencionar la compatibilidad con el

estándar ANSI y las mejoras de velocidad.
Desde la versión 4.0 tiene las siguientes novedades:
• Compatibilidad con subconsultas.
• Tipos GIS para almacenar datos geográficos.
• El método de almacenamiento InnoDB compatible con

transacciones se incluye como estándar.
• La caché de consultas MySQL, que mejora considerablemente la

velocidad de las consultas repetitivas que suelen ejecutar las
aplicaciones Web.

3.17. DBDesigner 4
Es una herramienta visual de trabajo con base de datos. Está bajo licencia
GPL. Proporciona facilidades para el diseño, el modelado, la creación y el
mantenimiento de bases de datos.
Soporta multitud de opciones, entre las que se encuentran:
• Modo de diseño o consulta.
• Ingeniería inversa de bases de datos MySQL, Oracle, MSSQL y

cualquiera con driver ODBC.
• Control de versiones.
• Constructor de queries.
• Permite usar "drag and drop".
• Soporte especial para MySQL
• Impresión del modelo según varios formatos (incluye gráfica y

XML).
• Generación del esquema de la base de datos definida por el

usuario.
• Sincronización del modelo con la base de datos.
• Soporta índices.
• Sustitución automática de "foreign keys".
• Almacenamiento de los comandos SQL con el modelo.
3.18. ArgoUML
ArgoUml es una aplicación OpenSource utilizada en el modelaje de

sistemas, mediante la cual se realizan diseños en UML (”Unified Markup
Language”) llevados acabo en el análisis y pre-diseño de Sistemas de

Software. La versión que se usará en el Proyecto es 0.24 teniendo las
características:
• Multiplataforma (Java 1.2).

• Clase, estado, casos de uso, actividad, colaboración, despliegue,
secuencia.
• Soporte para bases de datos.
• Exporta los diagramas a distintos formatos.
• Generación de código (parcial).
3.19. TECNOLOGÍA WAP.
(Herrera y Huerta, 2004), WAP es el acrónimo de Wireless Application

Protocol que podríamos traducir como Protocolo de Aplicación Inalámbrico. La
tecnología WAP es realmente un estándar impulsado por la industria del
sector de las telecomunicaciones con el objetivo de proporcionar un sistema
avanzado de servicios de Internet para dispositivos móviles.
La arquitectura de la tecnología WAP se basa en 3 elementos:
• Cliente: El cliente será el micro-navegador WML de un terminal

móvil. Este será el equivalente al navegador de un PC en el
Internet “Fijo” que todos conocemos.
• Pasarela o Gateway: LA pasarela constituye la interfaz entre la
red inalámbrica y la red física.
• Servidor Web: En toda arquitectura cliente/servidor tenemos un
servidor encargado de procesar las peticiones del cliente y enviar
las páginas solicitadas.
Los teléfonos WAP utilizan como lenguaje WML para las páginas estáticas y
WMLS para las páginas dinámicas.
Se precisa de un editor de textos, para escribir el código de la aplicación

WAP, una vez que se tiene la página codificada, para visualizar el resultado
se puede utilizar el propio teléfono o un navegador que puede adoptar el
aspecto de un teléfono móvil y simule como quedaría nuestra aplicación si

realmente estuviera en un servidor y estuviéramos accediendo de nuestro
teléfono.
En el desarrollo del modulo para la aplicación WAP se utilizo como editor de

texto a dreamweaver y como emulador WAP (IGSM, 2006).
3.20. PROGRAMACIÓN ORIENTADA A OBJETOS.
Los conceptos de la programación orientada a objetos tienen origen en

Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-
Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Según
se informa, la historia es que trabajaban en simulaciones de naves, y fueron
confundidos por la explosión combinatoria de cómo las diversas cualidades de
diversas naves podían afectar unas a las otras. La idea ocurrió para agrupar
los diversos tipos de naves en diversas clases de objetos, siendo responsable
cada clase de objetos de definir sus propios datos y comportamiento. Fueron
refinados más tarde en Smalltalk, que fue desarrollado en Simula en Xerox
PARC (y cuya primera versión fue escrita sobre Basic) pero diseñado para ser
un sistema completamente dinámico en el cual los objetos se podrían crear y
modificar "en marcha" en lugar de tener un sistema basado en programas
estáticos.
La programación orientada a objetos tomó posición como el estilo de

programación dominante a mediados de los años ochenta, en gran parte
debido a la influencia de C++ , una extensión del lenguaje de programación C.
Su dominación fue consolidada gracias al auge de las Interfaces gráficas de
usuario, para los cuales la programación orientada a objetos está
particularmente bien adaptada. En este caso, se habla también de
programación dirigida por eventos.
Las características de orientación a objetos fueron agregadas a muchos

lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal,
entre otros. La adición de estas características a los lenguajes que no fueron
diseñados inicialmente para ellas condujo a menudo a problemas de
compatibilidad y a la capacidad de mantenimiento del código. Los lenguajes

orientados a objetos "puros", por otra parte, carecían de las características de
las cuales muchos programadores habían venido a depender. Para saltar este
obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados
en métodos orientados a objetos, pero permitiendo algunas características
imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un
temprano y moderadamente acertado lenguaje con esos objetivos pero ahora
ha sido esencialmente reemplazado por Java, en gran parte debido a la
aparición de Internet, y a la implementación de la máquina virtual de Java en la
mayoría de navegadores.
La programación orientada a objetos es una nueva forma de programar que

trata de encontrar solución a estos problemas. Introduce nuevos conceptos,
que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan
los siguientes:
• Objeto: entidad provista de un conjunto de propiedades o atributos

(datos) y de comportamiento o funcionalidad ("métodos").
Corresponden a los objetos reales del mundo que nos rodea, o a
objetos internos del sistema (del programa).
• Clase: definiciones de las propiedades y comportamiento de un

tipo de objeto concreto. La instanciación es la lectura de estas
definiciones y la creación de un objeto a partir de ellas.
• Método: algoritmo asociado a un objeto (o a una clase de objetos),

cuya ejecución se desencadena tras la recepción de un "mensaje".
Desde el punto de vista del comportamiento, es lo que el objeto
puede hacer. Un método puede producir un cambio en las
propiedades del objeto, o la generación de un "evento" con un
nuevo mensaje para otro objeto del sistema.
• Evento: un suceso en el sistema (tal como una interacción del

usuario con la máquina, o un mensaje enviado por un objeto). El
sistema maneja el evento enviando el mensaje adecuado al objeto
pertinente. También se puede definir como evento, a la reacción
que puede desencadenar un objeto, es decir la acción que genera.

• Mensaje: una comunicación dirigida a un objeto, que le ordena
que ejecute uno de sus métodos con ciertos parámetros asociados
al evento que lo generó.
• Propiedad o atributo: contenedor de un tipo de datos asociados a

un objeto (o a una clase de objetos), que hace los datos visibles
desde fuera del objeto, y cuyo valor puede ser alterado por la
ejecución de algún método.
• Estado interno: es una propiedad invisible de los objetos, que

puede ser únicamente accedida y alterada por un método del
objeto, y que se utiliza para indicar distintas situaciones posibles
para el objeto (o clase de objetos).
• Componentes de un objeto: atributos, identidad, relaciones y

métodos.
• Representación de un objeto: un objeto se representa por medio

de una tabla o entidad que esté compuesta por sus atributos y
funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable", no es más que

un contenedor interno del atributo del objeto o de un estado interno, así como
la "función" es un procedimiento interno del método del objeto.
A. Características de la POO.
Hay un cierto desacuerdo sobre exactamente qué

características de un método de programación o lenguaje le
definen como "orientado a objetos", pero hay un consenso
general en que las características siguientes son las más
importantes (para más información, seguir los enlaces
respectivos):
• Abstracción: Cada objeto en el sistema sirve como modelo

de un "agente" abstracto que puede realizar trabajo,
informar y cambiar su estado, y "comunicarse" con otros
objetos en el sistema sin revelar cómo se implementan

estas características. Los procesos, las funciones o los
métodos pueden también ser abstraídos y cuando lo están,
una variedad de técnicas son requeridas para ampliar una
abstracción.
• Encapsulamiento: Significa reunir a todos los elementos

que pueden considerarse pertenecientes a una misma
entidad, al mismo nivel de abstracción. Esto permite
aumentar la cohesión de los componentes del sistema.
Algunos autores confunden este concepto con el principio
de ocultación, principalmente porque se suelen emplear
conjuntamente.
• Principio de ocultación: Cada objeto está aislado del

exterior, es un módulo natural, y cada tipo de objeto expone
una interfaz a otros objetos que específica cómo pueden
interactuar con los objetos de la clase. El aislamiento
protege a las propiedades de un objeto contra su
modificación por quien no tenga derecho a acceder a ellas,
solamente los propios métodos internos del objeto pueden
acceder a su estado. Esto asegura que otros objetos no
pueden cambiar el estado interno de un objeto de maneras
inesperadas, eliminando efectos secundarios e
interacciones inesperadas. Algunos lenguajes relajan esto,
permitiendo un acceso directo a los datos internos del objeto
de una manera controlada y limitando el grado de
abstracción. La aplicación entera se reduce a un agregado o
rompecabezas de objetos.
• Polimorfismo: comportamientos diferentes, asociados a

objetos distintos, pueden compartir el mismo nombre, al
llamarlos por ese nombre se utilizará el comportamiento
correspondiente al objeto que se esté usando. O dicho de
otro modo, las referencias y las colecciones de objetos
pueden contener objetos de diferentes tipos, y la invocación

de un comportamiento en una referencia producirá el
comportamiento correcto para el tipo real del objeto
referenciado. Cuando esto ocurre en "tiempo de ejecución",
esta última característica se llama asignación tardía o
asignación dinámica. Algunos lenguajes proporcionan
medios más estáticos (en "tiempo de compilación") de
polimorfismo, tales como las plantillas y la sobrecarga de
operadores de C++.
• Herencia: las clases no están aisladas, sino que se

relacionan entre sí, formando una jerarquía de clasificación.
Los objetos heredan las propiedades y el comportamiento
de todas las clases a las que pertenecen. La herencia
organiza y facilita el polimorfismo y el encapsulamiento
permitiendo a los objetos ser definidos y creados como tipos
especializados de objetos preexistentes. Estos pueden
compartir (y extender) su comportamiento sin tener que
reimplementar su comportamiento. Esto suele hacerse
habitualmente agrupando los objetos en clases y estas en
árboles o enrejados que reflejan un comportamiento común.
Cuando un objeto hereda de más de una clase se dice que
hay herencia múltiple; esta característica no está soportada
por algunos lenguajes (como Java).
B. Lenguajes orientados a objetos.
Entre los Principales lenguajes orientados a objetos

destacan:
Ada C++ PHP5 C#
VB.NET Visual FoxPro Smalltalk Clarion
Delphi Harbour Python Eiffel
Java PowerBuilder Ruby Oz, etc.
Tabla 1. Lenguajes Orientados a Objetos.

Algunos de los lenguajes de programación que existen en la
actualidad no son puramente orientados a objetos, sino que son
híbridos que combinan la OOP con otros paradigmas.
También es necesario recalcar que en la programación

orientada a objetos es factible de utilizar en JavaScript.
3.21. MACROMEDIA DREAMWEAVER
Es un editor WYSIWYG de páginas Web, creadas por Macromedia

(actualmente Adobe Systems). Es el programa de este tipo más utilizado en el
sector del diseño y la programación Web, por sus funcionalidades, su
integración con otras herramientas como Macromedia Flash y, recientemente,
por su soporte de los estándares del World Wide Web Consortium. Su principal
competidor es Microsoft Frontpage. Tiene soporte tanto para edición de
imágenes como para animación a través de su integración con otras
herramientas.
Se vende como parte de la suite Macromedia Studio, junto con Macromedia

Flash, Macromedia Freehand y Macromedia Fireworks.
Las versiones originales de la aplicación se utilizaban como simples editores

WYSIWYG, sin embargo, versiones más recientes soportan otras tecnologías
Web como CSS, JavaScript y algunos frameworks del lado servidor.
Esta aplicación está disponible tanto para la plataforma MAC como

Windows, aunque también se puede ejecutar en plataformas basadas en UNIX
utilizando emuladores como Wine.
Macromedia incorpora herramientas de creación de contenido dinámico en

Dreamweaver. En lo fundamental de las herramientas HTML WYSIWYG,
también permite la conexión a Bases de Datos como MySQL y Microsoft
Access, para filtrar y mostrar el contenido utilizando tecnología de script como,
por ejemplo, ASP (Active Server Pages), ASP.NET, ColdFusion, JSP
(JavaServer Pages), PHP.

Un aspecto de alta consideración de Dreamweaver es su arquitectura
extensible. Es decir, permite el uso de "Extensiones". Las extensiones, tal y
como se conocen, son pequeños programas, que cualquier desarrollador Web
puede escribir (normalmente en HTML y Javascript) y que cualquiera puede
descargar e instalar, ofreciendo así funcionalidades añadidas a la aplicación.
Dreamweaver goza del apoyo de una gran comunidad de desarrolladores de

extensiones que hacen posible la disponibilidad de extensiones gratuitas y de
pago para la mayoría de las tareas de desarrollo Web, que van desde simple
efectos rollover hasta completas cartas de compra.
En el Proyecto a realizar se utiliza Dreamweaver Versión 8 y la extensión

“MX Kollection Pro”.
3.22. WINDOWS 2003 SERVER
Windows Server 2003 es la versión de Windows para servidores lanzada

por Microsoft en el año 2003. Está basada en el núcleo de Windows XP, al que
se le han añadido una serie de servicios, y se le han bloqueado algunas
características (para mejorar el rendimiento, o simplemente porque no serán
usadas).
Características
Sus características más importantes son:
• Sistema de archivos NTFS.
• Cifrado y compresión de archivos
• Gestión de almacenamiento, backups... incluye gestión jerárquica

del almacenamiento, consiste en utilizar un algoritmo de cache
para pasar los datos menos usados de discos duros a medios
ópticos o similares más lentos, y volverlos a leer a disco duro
cuando se necesitan.

• Windows Driver Model: Implementación básica de los dispositivos
más utilizados, de esa manera los fabricantes de dispositivos sólo
han de programar ciertas especificaciones de su hardware
• ActiveDirectory Directorio de organización basado en LDAP,

permite gestionar de forma centralizada la seguridad de una red
corporativa a nivel local.
• Autentificación Kerberos5
• DNS con registro de IP's dinámicamente.
• Políticas de seguridad.
3.23. LENGUAJE UNIFICADO DE MODELADO (UML).
(Alarcón, 2000), UML es un lenguaje estándar que sirve para escribir los
planos del software, puede utilizarse para visualizar, especificar, construir y
documentar todos los artefactos que componen un sistema con gran cantidad
de software. UML puede usarse para modelar desde sistemas de información
hasta aplicaciones distribuidas basadas en Web, pasando por sistemas
empotrados de tiempo real. UML es solamente un lenguaje por lo que es sólo
una parte de un método de desarrollo software, es independiente del proceso
aunque para que sea optimo debe usarse en un proceso dirigido por casos de
uso, centrado en la arquitectura, iterativo e incremental. UML es un lenguaje
por que proporciona un vocabulario y las reglas para utilizarlo, además es un
lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan
para la representación conceptual y física del sistema. UML es un lenguaje que
nos ayuda a interpretar grandes sistemas mediante gráficos o mediante texto
obteniendo modelos explícitos que ayudan a la comunicación durante el
desarrollo ya que al ser estándar, los modelos podrán ser interpretados por
personas que no participaron en su diseño (e incluso por herramientas) sin
ninguna ambigüedad. En este contexto, UML sirve para especificar, modelos
concretos, no ambiguos y completos.

Debido a su estandarización y su definición completa no ambigua, y aunque
no sea un lenguaje de programación, UML se puede conectar de manera
directa a lenguajes de programación como Java, C++ o Visual Basic, esta
correspondencia permite lo que se denomina como ingeniería directa (obtener
el código fuente partiendo de los modelos) pero además es posible reconstruir
un modelo en UML partiendo de la implementación, o sea, la ingeniería
inversa.
(Ramírez, 2002), UML es un lenguaje para especificar, visualizar,

construir y documentar los “artefactos” del software (desde las fases iniciales
hasta la implementación del sistema), así como el modelado de flujo de trabajo
y otros sistemas no software.
Podemos decir que UML permite a los creadores de sistemas generar

diseños utilizando diagramas que capturen sus ideas para comunicarlas a
otras personas.
(Wikipedia, 2007h), en UML 2.0 hay 13 tipos diferentes de diagramas,

categorizados de la siguiente forma:
Diagramas de estructura: enfatizan en los elementos que deben existir

en el sistema modelado:
• Diagrama de clases
• Diagrama de componentes
• Diagrama de objetos
• Diagrama de estructura compuesta (UML 2.0)
• Diagrama de despliegue
• Diagrama de paquetes
Diagramas de comportamiento: enfatizan en lo que debe suceder en el

sistema modelado:
• Diagrama de actividades

• Diagrama de casos de uso
• Diagrama de estados
Diagramas de Interacción: un subtipo de diagramas de comportamiento,

que enfatiza sobre el flujo de control y de datos entre los elementos del
sistema modelado:
• Diagrama de secuencia
• Diagrama de comunicación
• Diagrama de tiempos (UML 2.0)
• Diagrama de vista de interacción (UML 2.0)
En el desarrollo del sistema se usará algunos diagramas.

Las herramientas de modelado puede ser software gratuito o de pago.
3.24. APLICACIONES EN CAPAS.
(Príapo y Rodríguez, 2005), “Las aplicaciones han pasado por un proceso

evolutivo enorme. Desde su inicio con las aplicaciones monolíticas donde en
una aplicación todo estaba ligado o mezclado por decirlo de alguna manera.
Es decir, la interfaces de usuario, la lógica de cómo funcionaba la empresa y el
manejo de la información almacenada y recuperada estaban juntas. La
estrategia tradicional de utilizar aplicaciones compactas causa gran cantidad
de problemas de integración en sistemas software complejos como pueden ser
los sistemas de gestión de una empresa o los sistemas de información
integrados consistentes en más de una aplicación. Estas aplicaciones suelen
encontrarse con importantes problemas de escalabilidad, disponibilidad,
seguridad, integración. Para solventar estos problemas se ha generalizado la
división de las aplicaciones en capas que normalmente serán tres: una capa
que servirá para guardar los datos (base de datos), una capa para centralizar
la lógica de negocio (modelo) y por último una interfaz gráfica que facilite al
usuario el uso del sistema…”

Figura 5. Arquitectura en tres capas
3.25. CONTABILIDAD.
(Roque, 2005), la contabilidad es una herramienta empresarial que permite

el registro y control sistemático de todas las operaciones que se realizan en las
empresas haciendo abstracción de las características de ésta.
La contabilidad es el producto de toda una gran cantidad de prácticas

mercantiles diferentes que han exigido a través de los años, el mejorar la
calidad de la información financiera en las empresas.
La contabilidad hacia el siglo XXI se ve influenciado por tres variables:
• La tecnología.
• La globalización de los negocios.
• La capacitación y educación continua.
La tecnología de la comunicación e información a través del impacto que

genera el aumento en la velocidad con la cual se generan las transacciones
financieras, a través de internet. La segunda variable de complejidad y
globalización de los negocios, requiere que la contabilidad establezca nuevos
métodos para el tratamiento y presentación de la información financiera. La

ultima variable relacionada con la formación y educación requiere que los
futuros gerentes dominen el lenguaje de los negocios.
Describiremos algunos términos contables:
A. Las cuentas.
Son nombres especiales que en contabilidad se da para representar a
los distintos valores que intervienen en la formación de una empresa.
Ejemplos:
• La cuenta “Mercaderías”, representa todos los artículos
(valores) que para la venta tiene la empresa.
• La cuenta “Letras por pagar” representa el importe que la
empresa debe presentan de las letras a cargo.
B. Activo.
Representa los bienes y derechos de la empresa. Dentro del
concepto de bienes están el efectivo, los inventarios, los activos fijos, etc.
Dentro del concepto de derechos se pueden clasificar las cuentas por
cobrar, las valorizaciones, etc.
C. Pasivo.
Son todas las obligaciones o deudas que afectan el patrimonio bruto
contribuyente.
D. Bien inmueble.
Son los bienes corporales que no pueden trasladarse de un lugar a
otro; por ejemplo: Los edificios, los árboles, etcétera.
E. Bien mueble.
Son las cosas(muebles) que pueden trasladarse de un lugar a otro ya
sea por sí misma, como animales, ya sea por una fuerza extraña, como
una silla, una mesa, etcétera. Valor de los contratos de arrendamiento
financiero de inmueble, maquinaria, equipo, mueble, enseres, etcétera.

B. El Inventario.
Es la relación detallada y pormenorizada de los valores bienes y
derechos, así como las obligaciones y deudas que tiene una empresa al
iniciar o finalizar sus operaciones en un periodo contable y que le permite
determinar, en un momento dado, su situación patrimonial.
F. Balance de inventario.
Es el cuadro financiero que se redacta en base al
inventario, presentándolo en forma resumida, globalizando las cuentas de
activo y pasivo, balanceándola con la cuenta capital.
3.26. CONTROL DE INVENTARIO
Los diversos aspectos de la responsabilidad sobre los inventarios

afectan a muchos departamentos y cada uno de éstos ejerce cierto grado
de control sobre los productos, a medida que los mismos se mueven a
través de los distintos procesos de inventarios. Todos estos controles que
abarcan, desde el procedimiento para desarrollar presupuestos y
pronósticos de ventas y producción hasta la operación de un sistema de
costo pro el departamento de contabilidad para la determinación de
costos de los inventarios, constituye el sistema del control interno de los
inventarios, las funciones generales son: Planeamiento, compra u
obtención, recepción, almacenaje, producción, embarques y contabilidad.
3.27. METODOLOGIA eXtreme Programming (XP).

En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el
término “ágil” aplicado al desarrollo de software. En esta reunión participan un
grupo de 17 expertos de la industria del software, incluyendo algunos de los
creadores o impulsores de metodologías de software. Su objetivo fue esbozar
los valores y principios que deberían permitir a los equipos desarrollar software
rápidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rígidos y dirigidos por la

documentación que se genera en cada una de las actividades desarrolladas.
Varias de las denominadas metodologías ágiles ya estaban siendo utilizadas
con éxito en proyectos reales, pero les faltaba una mayor difusión y
reconocimiento.
XP es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentación continua entre el cliente y el equipo de desarrollo, comunicación
fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo técnico.
Los principios y prácticas son de sentido común pero llevadas al extremo,
de ahí proviene su nombre.
a. Esta metodología promueve los siguientes valores:
• Comunicación.
El eXtreme Programming se nutre del ancho de banda más

grande que se puede obtener cuando existe algún tipo de
comunicación: la comunicación directa entre personas. Es muy
importante entender cuales son las ventajas de este medio.
Cuando dos (o más) personas se comunican directamente pueden
no solo consumir las palabras formuladas por la otra persona, sino
que también aprecian los gestos, miradas, etc. que hace su
compañero. Sin embargo, en una conversación mediante el correo
electrónico, hay muchos factores que hacen de esta una
comunicación, por así decirlo, mucho menos efectiva.
• Coraje.
El coraje es un valor muy importante dentro de la programación

extrema. Un miembro de un equipo de desarrollo extremo debe de
tener el coraje de exponer sus dudas, miedos, experiencias sin

"embellecer" éstas de ninguna de las maneras. Esto es muy
importante ya que un equipo de desarrollo extremo se basa en la
confianza para con sus miembros. Faltar a esta confianza es muy
grave.
• Simplicidad.
Dado que no se puede predecir como va a ser en el futuro, el

software que se esta desarrollando; un equipo de programación
extrema intenta mantener el software lo más sencillo posible. Esto
quiere decir que no se va a invertir ningún esfuerzo en hacer un
desarrollo que en un futuro pueda llegar a tener valor. En el XP
frases como "...en un futuro vamos a necesitar..." o "Haz un
sistema genérico de..." no tienen ningún sentido ya que no aportan
ningún valor en el momento.
• Feedback.
La agilidad se define (entre otras cosas) por la capacidad de

respuesta ante los cambios que se van haciendo necesarios a lo
largo del camino. Por este motivo uno de los valore que nos hace
más ágiles es el continuo seguimiento o feedback que recibimos a
la hora de desarrollar en un entorno ágil de desarrollo. Este
feedback se toma del cliente, de los miembros del equipo, en
cuestión de todo el entorno en el que se mueve un equipo de
desarrollo ágil.
• Se fundamenta en las siguientes doce prácticas (Ron, 2001).
i. Planificación incremental.
La Programación Extrema asume que la planificación nunca

será perfecta, y que variará en función de cómo varíen las
necesidades del negocio. Por tanto, el valor real reside en
obtener rápidamente un plan inicial, y contar con mecanismos
de feedback que permitan conocer con precisión dónde
estamos. Como es lógico, la planificación es iterativa: un

representante del negocio decide al comienzo de cada iteración
qué características concretas se van a implementar.
El objetivo de la XP es generar versiones de la aplicación tan

pequeñas como sea posible, pero que proporcionen un valor
adicional claro, desde el punto de vista del negocio. A estas
versiones se las denomina releases.
Una release cuenta con un cierto número de historias. La

historia es la unidad de funcionalidad en un proyecto XP, y
corresponde a la mínima funcionalidad posible que tiene valor
desde el punto de vista del negocio. Durante cada iteración se
cierran varias historias, lo que hace que toda iteración añada un
valor tangible para el cliente.
Es fundamental en toda esta planificación la presencia de un

representante del cliente, que forma parte del equipo y que
decide cuáles son las historias más valiosas. Estas historias son
las que se desarrollarán en la iteración actual.
La obtención de feedback que permita llevar a cabo

estimaciones precisas es fundamental. Se hacen estimaciones
para cada historia, de modo que en cuanto se comienzan a
tener datos históricos, éstos se utilizan para hacer que las
siguientes estimaciones sean más precisas.
Como se puede ver, y como siempre ocurre con la

Programación Extrema, el enfoque utilizado para llevar a cabo la
planificación es eminentemente pragmático. Gran parte de la
eficacia de este modelo de planificación deriva de una división
clara de responsabilidades, que tiene en cuenta las necesidades
del negocio en todo momento. Dentro de esta división, el
representante del cliente tiene las siguientes responsabilidades:
• Decidir qué se implementa en cada release o iteración.

• Fijar las fechas de fin de la release, recortando unas
características o añadiendo otras.
• Priorizar el orden de implementación, en función del valor

de negocio.
Las responsabilidades del equipo de desarrollo son

las siguientes:
• Estimar cuánto tiempo llevará una historia: este feedback

es fundamental para el cliente, y puede llevarle a
reconsiderar qué historias se deben incluir en una
iteración.
• Proporcionar información sobre el coste de utilizar

distintas opciones tecnológicas.
• Organizar el equipo.
• Estimar el riesgo de cada historia.
• Decidir el orden de desarrollo de historias dentro de la

iteración.
ii. Testing.
La ejecución automatizada de tests es un elemento clave de

la XP. Existen tanto tests internos (o tests de unidad), para
garantizar que el mismo es correcto, como tests de aceptación,
para garantizar que el código hace lo que debe hacer. El cliente
es el responsable de definir los tests de aceptación, no
necesariamente de implementarlos. Él es la persona mejor
cualificada para decidir cuál es la funcionalidad más valiosa.
El hecho de que los tests sean automatizados es el único

modo de garantizar que todo funciona: desde el punto de vista
de la XP, si no hay tests, las cosas sólo funcionan en

apariencia. Aún más, si un test no está automatizado, no se le
puede considerar como tal.
El objetivo de los tests no es corregir errores, sino

prevenirlos. Por ejemplo, los tests siempre se escriben antes
que el código a testear, no después: esto aporta un gran valor
adicional, pues fuerza a los desarrolladores a pensar cómo se
va a usar el código que escriben, poniéndolos en la posición de
consumidores del software. Elaborar los tests exige pensar por
adelantado cuáles son los problemas más graves que se
pueden presentar, y cuáles son los puntos dudosos. Esto evita
muchos problemas y dudas, en lugar de dejar que aparezcan
"sobre la marcha".
Un efecto lateral importante de los tests es que dan una gran

seguridad a los desarrolladores: es posible llegar a hacer
cambios más o menos importantes sin miedo a problemas
inesperados, dado que proporcionan una red de seguridad. La
existencia de tests hace el código muy maleable.
iii. Programación en parejas.
La XP incluye, como una de sus prácticas estándar, la

programación en parejas. Nadie programa en solitario, siempre
hay dos personas delante del ordenador. Ésta es una de las
características que más se cuestiona al comienzo de la
adopción de la XP dentro de un equipo, pero en la práctica se
acepta rápidamente y de forma entusiasta.
El principal argumento contra la programación en parejas es

que es improductiva. Esta idea se basa en el hecho de que dos
programadores "programan el doble por separado". Esto sería
así si no fuera por las siguientes razones:
• El hecho de que todas las decisiones las tomen al menos

dos personas proporciona un mecanismo de seguridad
enormemente valioso.

• Con dos personas responsabilizándose del código en
cada momento, es menos probable que se caiga en la
tentación de dejar de escribir tests, etc., algo fundamental
para mantener el código en buena forma. Es muy difícil
que dos personas se salten tareas por descuido o
negligencia.
• El hecho de programar en parejas permite la dispersión

de know-how por todo el equipo. Este efecto es difícil de
conseguir de otro modo, y hace que la incorporación de
nuevos miembros al equipo sea mucho más rápida y
eficaz.
• El código siempre está siendo revisado por otra persona.

La revisión de código es el método más eficaz de
conseguir código de calidad, algo corroborado por
numerosos estudios, muchos de los cuáles son anteriores
a la Programación Extrema.
• En contra de lo que pueda parecer, los dos

desarrolladores no hacen lo mismo: mientras el que tiene
el teclado adopta un rol más táctico, el otro adopta un rol
más estratégico, preguntándose constantemente si lo que
se está haciendo tiene sentido desde un punto de vista
global.
• Los datos indican que la programación en parejas es

realmente más eficiente. Si bien se sacrifica un poco de
velocidad al comienzo, luego se obtiene una velocidad de
crucero muy superior. Esto contrasta con lo que ocurre en
la mayor parte de los proyectos, en los que se arranca
con una velocidad enorme pero rápidamente se llega a
un estado muy parecido a la parálisis, en el que
progresos cada vez más pequeños consumen cantidades
de tiempo cada vez más grandes. Todos conocemos

proyectos que se pasan el 50% del tiempo en el estado
de "finalizado al 90%".
iv. Refactorización.
A la hora de la verdad, el código de la mayor parte de las

aplicaciones empieza en un razonable buen estado, para luego
deteriorarse de forma progresiva. El coste desorbitado del
mantenimiento, modificación y ampliación de aplicaciones ya
existente se debe en gran parte a este hecho.
Uno de los objetivos de la XP es mantener la curva de costes

tan plana como sea posible, por lo que existen una serie de
mecanismos destinados a mantener el código en buen estado,
modificándolo activamente para que conserve claridad y
sencillez. A este proceso básico para mantener el código en
buena forma se le llama refactorización.
La refactorización no sólo sirve para mantener el código

legible y sencillo: también se utiliza cuando resulta conveniente
modificar código existente para hacer más fácil implementar
nueva funcionalidad.
v. Diseño simple.
Otra práctica fundamental de la Programación Extrema es

utilizar diseños tan simples como sea posible. El principio es
"utilizar el diseño más sencillo que consiga que todo funcione".
Se evita diseñar características extra porque a la hora de la
verdad la experiencia indica que raramente se puede anticipar
qué necesidades se convertirán en reales y cuáles no. La XP
nos pide que no vivamos bajo la ilusión de que un diseño puede
resolver todas o gran parte de las situaciones futuras: lo que
parece necesario cambia con frecuencia, es difícil acertar a
priori.

Es obvio que, si no vamos a anticipar futuras necesidades,
debemos poder modificar el diseño si alguna de estas se
materializa. La XP soporta estas modificaciones gracias a los
tests automatizados. Estos permiten hacer cambios importantes
gracias a la red de protección que proporcionan. La
refactorización, que hace que el código existente sea claro y
sencillo, también ayuda a hacer factibles las modificaciones.
La XP define un "diseño tan simple como sea posible" como

aquél que:
• Pasa todos los tests.
• No contiene código duplicado.
• Deja clara la intención de los programadores

(enfatiza el qué, no el cómo) en cada línea de
código.
• Contiene el menor número posible de clases y

métodos.
vi. Propiedad colectiva del código.
La XP aboga por la propiedad colectiva del código. En otras

palabras, todo el mundo tiene autoridad para hacer cambios a
cualquier código, y es responsable de ellos. Esto permite no
tener que estar esperando a otros cuando todo lo que hace falta
es algún pequeño cambio.
Por supuesto, cada cuál es responsable de las

modificaciones que haga. El principio básico es "tú lo rompes, tú
lo arreglas, no importa si está en el código propio o en el de
otros".
Por último, vale la pena tener en cuenta que la existencia de

tests automatizados impide que se produzca un desarrollo
anárquico, al ser cada persona responsable de que todos los

tests se ejecuten con éxito al incorporar los cambios que ha
introducido al programa.
vii. Integración continúa.
En muchos casos la integración de código produce efectos

laterales imprevistos, y en ocasiones la integración puede llegar
a ser realmente traumática, cuando dejan de funcionar cosas
por motivos desconocidos. La Programación Extrema hace que
la integración sea permanente, con lo que todos los problemas
se manifiestan de forma inmediata, en lugar de durante una fase
de integración más o menos remota.
La existencia de una fase de integración separada tiene dos

efectos laterales indeseables: se empieza a hacer codificación
"yo-yo", en la que todo el mundo modifica código "sólo para que
funcione, ya lo ajustaremos", y hace que se acumulen defectos.
Evitar que se acumulen defectos es muy importante para la XP,
como lo es el conseguir que los defectos que cada programador
inyecta los elimine él mismo.
viii. Cliente en el equipo.
Algunos de los problemas más graves en el desarrollo son los

que se originan cuando el equipo de desarrollo toma decisiones
de negocio críticas. Esto no debería ocurrir, pero a la hora de la
verdad con frecuencia no se obtiene feedback del cliente con la
fluidez necesaria: el resultado es que se ha de optar por detener
el avance de los proyectos, o por que desarrollo tome una
decisión de negocio. Por otra parte, los representantes del
negocio también suelen encontrarse con problemas inesperados
debido a que tampoco reciben el feedback adecuado por parte
de los desarrolladores.
La XP intenta resolver este tipo de problemas integrando un

representante del negocio dentro del equipo de desarrollo. Ésta
persona siempre está disponible para resolver dudas y para

decidir qué y qué no se hace en cada momento, en función de
los intereses del negocio. Debido a su inmersión dentro del
equipo, y a que es él quien decide qué y qué no se hace, junto
con los tests que verifican si la funcionalidad es la correcta y
deseada, esta persona obtiene un feedback absolutamente
realista del estado del proyecto.
ix. Releases pequeñas.
Siguiendo la política de la XP de dar el máximo valor posible

en cada momento, se intenta liberar nuevas versiones de las
aplicaciones con frecuencia. Éstas deben ser tan pequeñas
como sea posible, aunque deben añadir suficiente valor como
para que resulten valiosas para el cliente.
x. Semanas de 40 horas
La Programación Extrema lleva a un modo de trabajo en que

el equipo está siempre al 100%. Una semana de 40 horas en las
que se dedica la mayor parte del tiempo a tareas que suponen
un avance puede dar mucho de sí, y hace innecesario recurrir a
sobreesfuerzos -excepto en casos extremos.
Además, el sobreesfuerzo continuado pronto lleva a un

rendimiento menor y a un deterioro de la moral de todo el
equipo.
xi. Estándares de codificación
Para conseguir que el código se encuentre en buen estado y

que cualquier persona del equipo pueda modificar cualquier
parte del código es imprescindible que el estilo de codificación
sea consistente. Un estándar de codificación es necesario para
soportar otras prácticas de la XP.
Sin embargo, la XP también es pragmática en esto, y apuesta

por establecer un número mínimo de reglas: el resto se irán

pactando de-facto. Esto evita un ejercicio inicial más o menos
estéril.
xii. Uso de Metáforas.
La comunicación fluida es uno de los valores más

importantes de la Programación Extrema: la programación en
parejas, el hecho de incorporar al equipo una persona que
represente los intereses del negocio y otras prácticas son
valiosas entre otras cosas porque potencian enormemente la
comunicación.
Para conseguir que la comunicación sea fluida es

imprescindible, entre otras cosas, utilizar el vocabulario del
negocio. También es fundamental huir de definiciones
abstractas. Dicho de otro modo, la XP no pretende seguir la
letra de la ley, sino su espíritu. Dentro de este enfoque es
fundamental buscar continuamente metáforas que comuniquen
intenciones y resulten descriptivas, enfatizando el qué por
delante del cómo.
b. La metodología XP es una metodología ágil (Beck y Grenning,

2001).
• Los individuos e interacciones son más importantes que los

procesos y herramientas.
• Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de éxito
de un proyecto software. Es más importante construir un buen
equipo que construir el entorno. Muchas veces se comete el error
de construir primero el entorno y esperar que el equipo se adapte
automáticamente. Es mejor crear el equipo y que éste configure su
propio entorno de desarrollo en base a sus necesidades.
• Software que funcione es más importante que documentación

exhaustiva.

• Desarrollar software que funciona más que conseguir una buena
documentación. La regla a seguir es “no producir documentos a
menos que sean necesarios de forma inmediata para tomar un
decisión importante”. Estos documentos deben ser cortos y
centrarse en lo fundamental.
• La colaboración con el cliente es más importante que la

negociación de contratos.
• La colaboración con el cliente más que la negociación de un

contrato. Se propone que exista una interacción constante entre el
cliente y el equipo de desarrollo. Esta colaboración entre ambos
será la que marque la marcha del proyecto y asegure su éxito.
• La respuesta ante el cambio es más importante que el seguimiento

de un plan.
• Responder a los cambios más que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a los largo
del proyecto (cambios en los requisitos, en la tecnología, en el
equipo, etc.) determina también el éxito o fracaso del mismo. Por lo
tanto, la planificación no debe ser estricta sino flexible y abierta.
c. Ciclo de vida de un Proyecto XP.
El ciclo de vida ideal de XP consiste de seis fases (Canós, Leiter y

Penadés, 2003).
• Exploración
En esta fase, los clientes plantean a grandes rasgos las

historias de usuario que son de interés para la primera entrega
del producto. Al mismo tiempo el equipo de desarrollo se
familiariza con las herramientas, tecnologías y prácticas que se
utilizarán en el proyecto. Se prueba la tecnología y se exploran
las posibilidades de la arquitectura del sistema construyendo un
prototipo. La fase de exploración toma de pocas semanas a

pocos meses, dependiendo del tamaño y familiaridad que tengan
los programadores con la tecnología.
• Planificación de la Entrega (Release)
En esta fase el cliente establece la prioridad de cada historia

de usuario, y correspondientemente, los programadores realizan
una estimación del esfuerzo necesario de cada una de ellas. Se
toman acuerdos sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el cliente. Una entrega
debería obtenerse en no más de tres meses. Esta fase dura unos
pocos días. Las estimaciones de esfuerzo asociado a la
implementación de las historias la establecen los programadores
utilizando como medida el punto. Un punto, equivale a una
semana ideal de programación. Las historias generalmente valen
de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene
un registro de la “velocidad” de desarrollo, establecida en puntos
por iteración, basándose principalmente en la suma de puntos
correspondientes a las historias de usuario que fueron terminadas
en la última iteración. La planificación se puede realizar
basándose en el tiempo o el alcance. La velocidad del proyecto
es utilizada para establecer cuántas historias se pueden
implementar antes de una fecha determinada o cuánto tiempo
tomará implementar un conjunto de historias. Al planificar por
tiempo, se multiplica el número de iteraciones por la velocidad del
proyecto, determinándose cuántos puntos se pueden completar.
Al planificar según alcance del sistema, se divide la suma de
puntos de las historias de usuario seleccionadas entre la
velocidad del proyecto, obteniendo el número de iteraciones
necesarias para su implementación.
• Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de

ser entregado. El Plan de Entrega está compuesto por iteraciones
de no más de tres semanas. En la primera iteración se puede

intentar establecer una arquitectura del sistema que pueda ser
utilizada durante el resto del proyecto. Esto se logra escogiendo
las historias que fuercen la creación de esta arquitectura, sin
embargo, esto no siempre es posible ya que es el cliente quien
decide qué historias se implementarán en cada iteración (para
maximizar el valor de negocio). Al final de la última iteración el
sistema estará listo para entrar en producción. Los elementos que
deben tomarse en cuenta durante la elaboración del Plan de la
Iteración son: historias de usuario no abordadas, velocidad del
proyecto, pruebas de aceptación no superadas en la iteración
anterior y tareas no terminadas en la iteración anterior. Todo el
trabajo de la iteración es expresado en tareas de programación,
cada una de ellas es asignada a un programador como
responsable, pero llevadas a cabo por parejas de programadores.
• Producción
La fase de producción requiere de pruebas adicionales y

revisiones de rendimiento antes de que el sistema sea trasladado
al entorno del cliente. Al mismo tiempo, se deben tomar
decisiones sobre la inclusión de nuevas características a la
versión actual, debido a cambios durante esta fase. Es posible
que se rebaje el tiempo que toma cada iteración, de tres a una
semana. Las ideas que han sido propuestas y las sugerencias
son documentadas para su posterior implementación (por
ejemplo, durante la fase de mantenimiento).
• Mantenimiento
Mientras la primera versión se encuentra en producción, el

proyecto XP debe mantener el sistema en funcionamiento al
mismo tiempo que desarrolla nuevas iteraciones. Para realizar
esto se requiere de tareas de soporte para el cliente. De esta
forma, la velocidad de desarrollo puede bajar después de la
puesta del sistema en producción. La fase de mantenimiento

puede requerir nuevo personal dentro del equipo y cambios en su
estructura.
• Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas

en el sistema. Esto requiere que se satisfagan las necesidades
del cliente en otros aspectos como rendimiento y confiabilidad del
sistema. Se genera la documentación final del sistema y no se
realizan más cambios en la arquitectura. La muerte del proyecto
también ocurre cuando el sistema no genera los beneficios
esperados por el cliente o cuando no hay presupuesto para
mantenerlo.
Fígura 6. Fases de un proyecto en eXtreme Programming.
Fígura 3-5. Ciclos en eXtreme Programming.

CAPÍTULO IV
METODOLOGÍA
CAPÍTULO IV
METODOLOGÍA
4.1 RESUMEN DE LA METODOLOGÍA APLICADA (XP).
Se ha optado por la programación extrema (XP) ya que ésta se ajusta mejor a

las características del proyecto.
Se cumplen las recomendaciones para emplear XP en el proyecto (Wells y

Ferrer, 2003).
• Interés sincero por todas las partes en que el proyecto tenga éxito.
• El equipo de trabajo es pequeño.
• Posible cambio de negocios.
• Requieren el Sistema cuanto antes.
• El equipo dispone de la capacidad de aprender.
• El proyecto tiene un riesgo alto en cuanto a lo innovador de la

tecnología.
También se ha tenido en cuenta el éxito que ha tenido extreme programming

en proyectos Web., cuyas características hacen que se adapte especialmente
bien esta metodología.
Como es evidente no todas las prácticas son aplicables al presente proyecto,

por lo que a continuación se especifica para cada una de ellas su aplicación en
el aplicativo Web:
1. Planificación incremental
Se ha decidido realizar cuatro releases con sus respectivas
iteraciones. Cada una de ellas proporcionando un valor de negocio
claro, a grosso modo serán:
• Funcionalidad común.
• Gestión de usuario.
• Gestión de inventario.
Capítulo IV: Metodología Programación Extrema. 72

• Gestión de personal.
• Gestión de cuentas contables.
El modulo de Funcionalidad común se refiere a la autenticación y

accesibilidad al sistema desde dispositivos móviles.
Desde la página 106 hasta el 213, se detalla cada una de estas

iteraciones.
En cuanto a la evaluación económica se detalla en el Capítulo V.
2. Testing
Una de las principales aportaciones de esta metodología es el
concepto de desarrollo dirigido por tests (Test Driven Development).
Los tests son realizados a priori con el fin de prevenir errores. Esto
confiere una gran calidad al software resultante. Los tests son
ejecutados automáticamente cada día para asegurar que el sucesivo
desarrollo del sistema no afecta a su estabilidad. Dado que los tests
son creados a priori fallarán hasta que la funcionalidad esté
implementada, en el proceso que comúnmente se llama rojo a verde.
En caso de que se encuentren fallos no detectados previamente, es
requisito escribir un test que falle para posteriormente solucionar el
problema.
La automatización de los tests proporciona una gran seguridad, por

ejemplo en las pruebas del sistema con distintos gestores de base de
datos se tiene la certeza de que si los tests se ejecutan
correctamente la compatibilidad existe.
3. Programación en parejas
Dado el impuesto carácter individual del proyecto esta práctica no
ha sido aplicada.

4. Refactorización
En las sucesivas iteraciones ha sido necesario refactorizar partes
del núcleo del sistema y este proceso ha sido realmente sencillo, a lo
que ha contribuido en gran parte la cantidad de tests realizados.
5. Diseño simple
El diseño se ha mantenido sencillo, desde luego pasando los tests,
sin código duplicado y con un mínimo de código gracias al núcleo del
sistema que proporciona un gran dinamismo y evita la necesidad de
implementación de operaciones repetitivas.
6. Propiedad colectiva del código

A pesar de que en la elaboración del proyecto no hubo un grupo
de desarrolladores como tal, se ha puesto a disposición en el blog
(Guerra, 2006), llevandose acabo la práctica esta propiedad
colectiva, donde cualquier desarrollador puede examinar el código y
realizar las modificaciones que consideren pertinentes, pudiendo
revertirse estas contribuciones en el proyecto.
7. Integración continua
La integración es permanente gracias a los tests, a los gestores

de proyectos como XPWEB y el uso de Dreamweaver.
8. Cliente en el equipo
El cliente ha participado en todo el desarrollo (proceso),
compartiendo información, dando sus intereses y visión de negocio.
9. Releases pequeñas.
Se ha seguido esta práctica, liberando nuevas versiones según
las funcionalidades requeridas por el usuario.
10. Semanas de 40 horas.

Se aplicado a este proyecto.

11. Estándares de codificación
Aunque no se ha trabajado con varios desarrolladores, se ha
desarrollado algunos estandares:
• Las etiquetas en XHTML deben estar en minuscula.
• las setencias SQL deben estar en mayuscula.
• las hojas de estilo deben estar en minuscula, etc.
Y se ha tratado tambien de seguir las directivas de PHP

Extension and Application Repository (PEAR), como su nombre
indica: Extensión de PHP y Repositorio de Aplicaciones.
PEAR es un conjunto de extensiones de PHP y una librería de

código PHP.
PEAR provee un conjunto de estandares.
Algunos estandares a seguir:
• Para nombrar las clases, funciones y metodos debemos

usar la capitalización de las palabras.
• Debemos usar las etiquetas <?php … ?> y no <?...?>.
• Para añadir comentarios podemos usar el estilo de C (/* */)

o de C++ ( // ). Sin embargo debemos evitar el uso del
estilo de Perl, donde se utiliza el símbolo #, etc.
12. Uso de Metáforas

Se ha utilizado el vocabulario adecuado para facilitar la
comprensión de los módulos y para facilitar la comunicación con el
cliente.

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.
En la Institución Educativa se ha conformado un comité de

Inventarios, cumpliendo con la Resolución Directoral, con los
siguientes integrantes:
• Director (a)-Presidente(a).
• Un (a) Profesor (a) con más tiempo de servicio en la

I. E.-Miembro.
• Un Representante de los Padres de Familia –

Miembro.
• Un (a) Personal Administrativo-Secretario (a).
El personal de la Comisión de Inventario y/o de los equipos

de apoyo se procede a inventariar los bienes que se
encuentren en cada ambiente de la Institución.
La información requerida para el registro de los bienes
muebles esta acorde con el Catálogo Nacional de Bienes
Muebles del Estado como ayuda.
Las institución elabora el Inventario físico de los bienes
muebles que detecten, sea cual fuere el origen, modalidad de su
adquisición.
Luego de la toma de inventario, el reporte es presentado al
promotor de la Organización Galileo.
El Promotor de la Institución Educativa PRONOE GALILEO
es el gerente de esta Institución.

El Director del Comité es el propio director de la Institución
Educativa PRONOE GALILEO.
B. DESCRIPCIÓN DEL REGISTRO EN EL CATÁLOGO.
El registro del catálogo es realizado por el comité de

inventario, y se realiza cuando existe un tipo de bien no
encontrado, entonces se le asigna un código. El código tiene 3
partes:
Primera:
Se le denomina Grupo y hace referencia al tipo de

bien dentro del grupo, ejemplo para el grupo Cultura y
Arte se le colocará un código 39.
Segunda:
Hace referencia a la clase, ejemplo para la clase

equipo se le colocará un código 22.
Tercera:
Hace referencia al tipo de bien mediante un código.
Ejemplo: 39 22 7763
Figura 8. Descripción del código de un tipo de bien

en catálogo.

GRUPO GENERICO CODIGO GRUPO CLASE CODIGO CLASE
Equipo 22
Agrícola y Pesquero 04
Mobiliario 64
Aire Acondicionado
11 Equipo 22
y Refrigeración
Aseo y Limpieza 25 Equipo 22
Equipo 22
Cocina y Comedor 32
Mobiliario 64
Equipo 22
Cultura y Arte 39
Mobiliario 64
Tabla 2. Estructura del código de los tipos de Bien.
Denominación Código Denominación Código

AGENDA ELECTRÓNICA 74220013 FACSIMIL 95233791
ANTENA PARABÓLICA 95220995 FOTOCOPIADORA EN GENERAL 74222726
ARCHIVADOR DE MADERA 74640321 FUENTE DE PODER 46226076
ARCHIVADOR DE METAL TIPO
74640457 GABINETE DE MADERA 74644474
KARDEX
ARCHIVADOR DE METAL Y MADERA 74640525 GABINETE DE METAL 74644491
IMPRESORA A INYECCIÓN DE
ARCHIVADOR DE METAL 74640389 74083650
TINTA
ARMARIO DE MADERA 74640592 IMPRESORA LASER 74084100
IMPRESORA MATRIZ DE
ARMARIO DE METAL Y MADERA 74640796 74084550
PUNTOS
Tabla 3. Algunos códigos del catálogo.
C. DESCRIPCIÓN DEL REGISTRO DEL DOCUMENTO DE

INVENTARIO.
El registro del documento de inventario, lo realiza el comité

de inventario realizando las siguientes acciones:
• El comité de inventario busca el código del Bien en un

catálogo.
• Una vez encontrado le asigna un código correlativo.

• Luego registra en una hoja de Excel todos los datos de
este Bien como fecha de adquisición, tipo de
procedencia, valor de este bien, en que área se
encuentra, que personas estan a cargo, etc.
D. DESCRIPCIÓN DE LAS CONSULTAS.
Para realizar las consultas en el catálogo o documento de

inventario, se realizan las siguientes acciones:
• El Comité de inventarios busca en la hoja de Excel del

catálogo el código o descripción del tipo de Bien
registrado.
• El comité de inventarios busca en la hoja de Excel del

documento de inventario los datos del bien registrado.
• Estas consultas se utilizan cuando el Promotor decide

verificar si el Bien existe o no, pero también puede darse
si el comité de inventarios quiere verificar.
• Si el Promotor es quien ordeno la consulta, se realiza un

pequeño informe del tipo de Bien del catálogo y de los
datos que se encuentra en el documento de inventario.
E. DESCRIPCIÓN DE LOS REPORTES.
El registro de los reportes ya sea totales o por tipo de cuenta,

se realiza cuando el promotor solicita al comité de inventarios
un reporte de los bienes que existen en la Institución en la
fecha indicada.
El comité de inventarios elabora un informe.

F. DESCRIPCIÓN DEL BALANCE DE INVENTARIO.
El promotor una vez que tiene los reportes, lo deriva al

contador de la institución.
El Contador en base a los reportes lo resume globalizando

las cuentas de activo y pasivo, balanceándola con la cuenta
Capital.
G. MODELO DEL SISTEMA ACTUAL.
Realizar consulta
Promotor
Registrar tipo de bien en Catalogo
Realizar reporte <<include>>
Comite de
inventario
<<include>>
Registrar el bien
Verificar codigo en catalogo
Contador
Realizar Balance de inventario
Figura 9. Sistema Actual.
H. HISTORIAS DE USUARIO (USER STORIES).
Se describe las historias de usuario:
• El Promotor tendrá un código y password para ingresar al

Sistema de administración.

• El Promotor dará mantenimiento a los datos de la
Institución Educativa (Código modular, dirección,
télefono, etc.).
• El Promotor podrá disponer de un gráfico estadístico de

cuanto dinero existe por cuenta contable.
• El Promotor registrará los datos del director.
• El Promotor asignará un código y password al director de

la Institución educativa para que ingrese al sistema.
• El Promotor y director pueden cambiar su contraseña.
• El promotor puede generar el balance de inventario.
• El Promotor y director pueden obtener los

reportes(informes y estadística)
• El Promotor y director pueden realizar búsquedas de

Instituciones educativas mostrando información de estás,
la localización geográfica y algunas noticias locales e
internacionales.
• El Director registra las áreas de la Institución.
• El Director registra el personal a cargo de las áreas.
• El Director da mantenimiento a las áreas, así como a

quienes están a cargo de estas
• El Director es el encargado de registrar los bienes o

modificarlos.

• El Promotor y director consultarán en el sistema si existe
el tipo de bien en el catálogo.
• El Promotor y director pueden realizar la consulta de

bienes en cualquier momento.
• El contador recibe por parte del promotor los reportes y

el balance de inventario.
• El Promotor puede utilizar algún dispositivo móvil para

realizar las consultas por bien, área, personal y obtener
el resumen de cuanto de dinero existe por cuenta
contable.
Se describen las características del sistema según las

historias de usuario.
Se reconoció a los siguientes personajes:
• Promotor.
• Director del comité de inventarios.
• Contador.
Estos personajes interactúan recíprocamente con el sistema.

Le asignamos los siguientes nombres:
• Al Promotor como Administrador del Sistema.
• Al Director del comité de inventario como Usuario y

con el mismo nombre al Contador.

INTERACTÚAN RECÍPROCAMENTE LA ACCIÓN QUE DESARROLLA
CON EL SISTEMA.
Representa al Promotor de la
Institución, quíen puede agregar,
modificar, eliminar datos referentes a la
Institución educativa, del usuario,
tambien puede realizar búsquedas de
otras instituciones a través de un
Administrador del Sistema.
localizador geográfico mostrando los
datos de esta y noticias de la localidad.
El administrador puede obtener la
consulta referente a los bienes y generar
los reportes (informes - estadística) y el
balance de inventario.
El administrador puede realizar
consultas mediante dispositivos móviles.
El contador recibirá por parte del
Contador Promotor los reportes y el balance de
inventario.
Representado por el director del comité
de inventario quien contará con un
código y clave de acceso otorgado por
el administrador del sistema, el usuario
es el encargado de registrar y
Usuario.
actualizar los bienes, áreas, personal
(que están a cargo de las áreas),
también el usuario podrá realizar
consultas y reportes (informes -
estadística).
Tabla 4. Acciones de los Personajes que interactúan con el Sistema.

Se ha encontrado los siguientes grupos de funcionalidades
bien diferenciadas: Funcionalidad común (Autenticación y
accesibilidad para dispositivos móviles), Gestión de la
Institución, Gestión de inventario, Gestión de áreas, Gestión del
personal, Gestión del usuario y Gestión de cuentas contables.
Se detalla a continuación:
a. Funcionalidad común.
El administrador tiene el control del sistema y el
usuario podrá acceder a un subconjunto de datos y
operaciones a realizar (Se usará la autenticación
mediante código y password para el ingreso del
Sistema).
El administrador podrá realizar sus consultas desde
dispositivos móviles (WAP).
b. Gestión de la Institución.
El Administrador del aplicativo Web es el único que

puede ingresar los datos de la Institución, realizar
consultas o modificarlo.
La institución cuenta con un atributo código modular
que se utiliza para referirse a la Institución Educativa y
unos atributos según sea:
• Código de grupo, se refiere que en la

institución pueden existir diferentes programas,
en el sistema a desarrollar la Institución
Educativa PRONOE pertenece al Grupo
Organización Galileo.
• Código de UGEL, en este caso pertenece a la
UGEL del Santa.
• Nombre de la Institución.

• Dirección de la Institución.
• Teléfono de la Institución.
• Email de la Institución.
• Web de la Institución.
• Nombre del Director de la Institución.
• Numero de resolución de la Institución.
• Provincia a la que pertenece.
• Centro poblado.
• Distrito.
Para ingresar la información de la institución en el

sistema este debe contar:
1. Con un grupo asociado.
Este grupo debe tener un código que

represente a toda la Organización Galileo, y un
nombre.
2. Con una modalidad
Esta modalidad debe tener un código que

represente que la Institución es un PRONOE y
el nombre de la modalidad, El Ministerio de
Educación dispone de los códigos y nombres de
todas las modalidades existentes en el Perú.
3. Con un departamento al que pertenece la

Institución.
El departamento debe contar con un código

y un nombre establecido.

4. Con una UGEL a donde pertenece la
institución.
La UGEL debe contar con un código y un

nombre establecido por el Ministerio de
Educación.
5. La Institución educativa debe contar con

áreas.
Las áreas de la Institución consisten en que

existen departamentos especializados, que
puede ser departamento de música,
computación, etc.
La Gestión de áreas estará a cargo del

Administrador.
Cada Área consta con un código para

referirse a él, y unos atributos:
• Nombre del área.

• Observación del área.
• Código modular de la institución.
La Gestión de la institución permitirá registrar,

modificar, buscar y eliminar:
• Registro de la institución
Para el registro de la Institución solo el

Administrador podrá ingresar la información.

• Modificación de la Institución.
El Administrador podrá cambiar los

atributos de la institución.
• Eliminación de la Institución.
El Administrador procederá a eliminar todo

los datos concernientes a la Institución.
• Búsqueda de Institución.
El administrador podrá realizar búsquedas

por cualquiera de los atributos de la Institución,
si el administrador registrará otra institución en
el sistema.
• Localización de la Institución.
El administrador y usuario podrán realizar

busquedas geograficas de otras instituciones
educativas, mostrando información de estas y
las noticias locales e internacionales.
• Registro del Grupo
Para el registro del Grupo sólo el

administrador podrá ingresar la información.
• Modificación del Grupo.

atributos del grupo.

• Eliminación del grupo.

los datos concernientes al grupo.
• Búsqueda de Grupo.
Se podrán realizar búsquedas por

cualquiera de los atributos del grupo, si el
administrador ha registrado otros grupos en el
sistema.
• Registro de modalidad.
Para el registro de la modalidad solo el

• Modificación de la modalidad.

atributos de la modalidad.
• Eliminación de la modalidad.

los datos concernientes a la modalidad.
• Búsqueda de modalidad.

cualquiera de los atributos de la modalidad, si
el administrador ha registrado otras
modalidades en el sistema.
• Registro de UGEL.
Para el registro de la UGEL (Zona) solo el


• Modificación de la UGEL.

atributos de la UGEL
• Eliminación de la UGEL.

los datos concernientes a la UGEL
• Búsqueda de UGEL.

cualquiera de los atributos de la UGEL, si el
administrador ha registrado otras UGEL en el
sistema.
• Registro de área
Ingresaran los datos requeridos del área.
• Modificación del Área
Se podrá cambiar los atributos del área.
• Eliminación del Área.
Cuando el administrador considere que el

área ya no es necesaria procederá a
eliminarlo.
• Búsqueda del área.

cualquiera de los atributos del área.
• Registro del departamento.
Solo el administrador podrá ingresar un

nuevo tipo de bien en catalogó.

• Modificación del departamento.
El administrador podrá cambiar los

atributos del departamento.
• Eliminación del departamento.

departamento ya no es necesario procederá a
eliminarlo.
• Búsqueda por departamento

cualquiera de los atributos del departamento.
c. Gestión de Usuario.
El Administrador del aplicativo Web es el único que

puede registrar nuevos usuarios para el uso del
Sistema.
Cada uno de los usuarios tiene como atributo un

código que es el utilizado comúnmente para referirse a
él, y unos atributos según sea:
• DNI.
• Nombres.
• Apellidos.
• El rol (si es directivo (promotor o contador) o si

es secretaria.
• Password (Clave).
Además de esto pueden tener información para

contactar con ellos, como pueden ser:

• Teléfono
• Dirección
• Dirección de correo electrónico (e-mail)
• Observación.
En la gestión de usuario se puede realizar lo

siguiente:
• Creación de usuario
Para la creación de un usuario el

administrador deberá ingresar los datos de
este.
• Modificación del usuario.

atributos del usuario.
• Eliminación de Usuario.
Cuando se considere que el usuario ya no

ingresará más al sistema se procederá a
eliminarlo.
• Búsqueda de Usuario

cualquiera de los atributos del usuario.
d. Gestión de Inventario.
El usuario, directivo, administrador del aplicativo

Web pueden interactuar con los bienes.
Cada Bien tiene como atributo un código para

referirse a él, y unos atributos según sea:

Si el valor ingresado es mayor a 1/8 UIT
• Nombre del tipo de bien.

• Forma de adquisición.
• Entidad de procedencia.
• Fecha de adquisición.
• Valor en libros (Cantidad de dinero).
• Datos de adquisición.
• Unidad de medida.
• Estado del Bien.
• Área
• Otros.
Si el valor ingresado es menor a 1/8 UIT
• Nombre del tipo de bien.

• Forma de adquisición.
• Entidad de procedencia.
• Fecha de adquisición.
• Datos de adquisición.
• Unidad de medida.
• Cantidad.
• Valor unitario.
• Estado del Bien.
• Área.
• Otros.
Para poder ingresar los bienes en el sistema estos

deben pertenecer a un tipo de bien, esto se encuentra
en el catálogo.
El tipo de bien debe contar con un código principal

(código de catálogo) y una descripción de este.

En la gestión de inventario se puede realizar lo
siguiente:
• Registro de bienes
Solo el usuario ingresará los datos

requeridos del bien.
• Modificación del Bien.
El usuario podrá cambiar los atributos

del bien.
• Eliminación de Bien.
Cuando el usuario considere que el bien

ya no es necesario procederá a eliminarlo.
• Búsqueda de Bien.
El usuario y administrador podrán realizar

búsquedas por cualquiera de los atributos del
bien.
• Reportes de los Bienes.
El usuario y administrador podran obtener

información de los bienes registrados en una
cuenta contable o en todas, tambíen se puede
obtener una grafica estadística del dinero por
cuenta contable.
• Balance de inventario
El administrador podrá generar un

resumen de las cuentas contables con el valor
monetario en ella (Balance de inventario).

• Registro en el catalogo.
Solo el administrador podrá ingresar un

nuevo tipo de bien en catalogó.
• Modificación del catalogo.

atributos del tipo de bien.
• Eliminación del tipo de bien en catalogo.

bien ya no es necesario procederá a
eliminarlo.
• Búsqueda del tipo de bien en catalogo

cualquiera de los atributos del tipo de bien.
e. Gestión del Personal.
Se refiere a las personas que estas en una

determinada área, el administrador es el único que
puede registrar estas áreas.
Cada Personal consta con un código para referirse a

él, y unos atributos:
• DNI del personal.

• Nombre del personal.
• Apellidos del personal.
• Teléfono del personal.
• Dirección del personal.
• Email del personal.
• Observación.

• Área al que pertenece el personal.
En la gestión del Personal se puede realizar lo

siguiente:
• Registro de personal.
Ingresaran los datos requeridos para el

personal.
• Modificación del personal.
Se podrá cambiar los atributos del

personal.
• Eliminación del Personal.

personal ya no es necesario procederá a
eliminarlo.
• Búsqueda del Personal.

cualquiera de los atributos del Personal.
f. Gestión de cuentas contables.
Se refiere a las cuentas con que se registrarán los

bienes para su respectivo balance de inventario.
El administrador es el único que puede gestionar
las cuentas contables.
Cada cuenta consta con un código principal único y

unos atributos:

• Nombre de la cuenta.
• Descripción.
• UIT
En la gestión del las cuentas contables se puede

realizar lo siguiente:
• Registro de cuenta.
Ingresara los datos requeridos para la

cuenta.
• Modificación de la cuenta contable.
Se podrá cambiar los atributos de la

cuenta contable.
• Eliminación de la cuenta contable.
Cuando el administrador considere que la

cuenta contable ya no es necesaria procederá
a eliminarla.
• Búsqueda de cuenta contable.

cualquiera de los atributos de la cuenta
contable.
I. HERRAMIENTAS.
En el desarrollo de este proyecto se han utilizado las

siguientes herramientas en cada ámbito.
La mayor parte del software utilizado es gratuito y tan sólo la
herramienta Macromedia Dreamweaver y la extensión MX
Kollection Pro, son de pago.

a. DESARROLLO.
• Navegador Mozilla Firefox 2.0.

• DBdesginer 4.0.
• ArgotUML 0.24.
• Extensión FireBug 1.04. para las pruebas
unitarias del Sistema.
• Dreamweaver 8.
• MX Kollection Pro
b. GESTIÓN DEL PROYECTO.
Se utilizo XPWeb v3.3.2 para la gestión integral del

proyecto.
c. EJECUCIÓN.
El software requerido para la ejecución del sistema

es:
• Un servidor de aplicaciones Web.
• Lenguaje.
• Un sistema gestor de base de datos relacional.
• Un navegador Web.
Este es el software que ha sido utilizado para la

ejecución y los tests de todo el Sistema:
• Servidor de aplicaciones Web: Apache 2.2.4.

• Lenguaje: PHP 5.2.1, JavaScript, CSS, XML.
• Base de datos: MySQL 5.0.27.
• Navegador Web: Mozilla Firefox 2.0.
• Emulador WAP (IGSM, 2006).

J. TECNOLOGÍAS.
Las tecnologías a usar se describieron en el Marco

Teórico, Capitulo III.
K. PROTOTIPO.
La arquitectura se desarrolla durante la primera iteración a

la vez que se realiza el prototipo, donde se comprobará su
adecuación al desarrollo del sistema.
Figura 10. Arquitectura del Sistema a desarrollar.
2. PLANIFICACIÓN DE LAS ENTREGAS.
En esta fase se establece la prioridad de cada historia de usuario

así como una estimación del esfuerzo necesario de cada una de
ellas con el fin de determinar un cronograma de entregas.
Las estimaciones de esfuerzo asociado a la implementación de

las historias se establecen utilizando como medida el punto. Un
punto, equivale a una semana ideal de programación. Las historias

generalmente valen de 1 a 3 puntos. Por otra parte, se mantiene un
registro de la “velocidad” de desarrollo, establecida en puntos por
iteración, basándose principalmente en la suma de puntos
correspondientes a las historias de usuario que fueron terminadas
en la última iteración.
La planificación se puede realizar basándose en el tiempo o el

alcance. La velocidad del proyecto es utilizada para establecer
cuántas historias se pueden implementar antes de una fecha
determinada o cuánto tiempo tomará implementar un conjunto de
historias.
Al planificar por tiempo, se multiplica el número de iteraciones por
la velocidad del proyecto, determinándose cuántos puntos se
pueden completar. Al planificar según alcance del sistema, se divide
la suma de puntos de las historias de usuario seleccionadas entre la
velocidad del proyecto, obteniendo el número de iteraciones
necesarias para su implementación.
A. ESTIMACIONES DE ESFUERZO.
1. Funcionalidad común
Funcionalidad común(
autenticación y 1
accesibilidad desde
dispositivos móviles)
Tabla 5. Funcionalidad común.
2. Gestión de Usuario.
Registro. modificación,
búsqueda, eliminación 1
del usuario.
Tabla 6. Gestión de Usuario.

3. Gestión de la Institución.
Registro, modificación,
del grupo, área,
departamento, UGEL y
modalidad.
búsqueda, eliminación de 1
datos de la Institución.
Localizar Institución.
1
Tabla 7. Gestión de la Institución.
4. Gestión de Inventario.
del tipo de bien en
catálogo.
bienes.
Generador del Balance de
inventario y 1
Reportes de
inventario(informes -
estadística).
Tabla 8. Gestión de Inventario.
5. Gestión del Personal.
del personal.
Tabla 9. Gestión del Personal.

6. Gestión de las cuentas contables.
cuenta contable.
Tabla 10. Gestión de las cuentas contables.
B. PLANIFICACIÓN.
Partiendo de las historias de usuario anteriores se realiza la

planificación en cuatro iteraciones basándose en el tiempo y
procurando agrupar la funcionalidad relacionada en la misma
iteración.
En la Tabla 11. Fechas de entrega, pueden verse las

fechas en las que cada versión ha sido entregada al cliente.
El motivo por el que se crean nuevas versiones de alguno

de los módulos puede ser cambios desde la última versión o
simplemente actualización de las dependencias en otros
módulos cuando una nueva versión de éstos últimos es
entregada, para evitar posibles problemas.
Con estos datos y teniendo en cuenta que el desarrollo

como tal comenzó el 10 de noviembre del año 2006, se
obtienen los datos de duración de cada iteración tal y como
se muestran en cada apartado.

3 semanas 3semanas 2 semanas 3 semanas
(05/02/2007 (26/02/2007 (19/03/2007 (02/04/2007
Modulos
al al al al
23/02/2007) 16/03/2007) 30/03/2007) 20/04/2007)
Funcionalidad
común
Gestión de
Institución.
Gestión de usuario
Gestión de
inventario
Gestión de personal
Gestión de cuenta
contable
VERSIONES 0.1 0.2 0.3 0.4
Tabla 11. Fechas de entrega.
Podemos ver las funcionalidades de cada iteración:
1. Primera Iteración: Prototipo.
En esta primera iteración se creará un prototipo con

el que se comprobará la adecuación de la tecnología
escogida y se intentará crear la mayor parte de la base
de la arquitectura del sistema. No se implementará una
funcionalidad muy extensa tan sólo un mínimo para
tener cuanto antes una demo para ser mostrada al
cliente.

Registro, modificación, 1
búsquedad, eliminación
del grupo, área,
departamento, UGEL y
modalidad.
Registro, modificacion, 1
búsqueda, eliminación de
datos de la Institución.
búsquedad, eliminación
del personal.
Estimación Inicial 3
Final 4
Tabla 12. Historias Primera Iteración.
Como se puede comprobar, la duración real de esta

iteración ha superado en una semana la planificación
de entrega en el tiempo estimado. Este retraso ha sido
debido principalmente a la curva de aprendizaje de la
tecnología usada.
2. Segunda Iteración: Funcionalidad común, Gestión

de Usuario y la implementación del cátalogo.
En esta iteración se añadirá la funcionalidad

necesaria para la autenticación de los usuarios,
gestión de usuario, y la implementación del cátalogo.
La duración real de la iteración ha sido menor en

comparación con la primera iteración, gracias a que la
parte principal del sistema ya había sido realizado en
la iteración anterior con todo el esfuerzo de integración
de tecnologías. Una vez hecho esto, la gestión de
autenticacición ha sido sencilla de integrar en el

sistema, así como también ha sido breve parte de la
implementación del catálogo.
búsqueda, eliminación
del tipo de bien en
catálogo.
del usuario.
Funcionalidad común. 1
Final 2
Tabla 13. Historias Segunda Iteración.
3. Tercera Iteración: Se realiza la gestión de cuenta

contable y parte de la gestión de Inventario.
En esta tercera iteración se realiza toda la

funcionalidad de la cuenta contable y se añadirá parte
de la funcionalidad de la gestión de inventario.
bienes.
cuenta contable.
Final 2
Tabla 14. Historias Tercera Iteración.

La duración de la iteración no ha aumentado, lo que
indica que se ha sobreestimado el esfuerzo de las
historias de usuario.
4. Cuarta Iteración: Se termina con la gestión de la

Institución, de Inventario y con la funcionalidad
común.
La cuarta iteración conllevará la finalización del

sistema tras la implementación de las historias
correspondientes a la gestión de la institución, de
inventarios y se culmina con la autenticación y
accesibilidad desde dispositivos móviles para el
administrador del sistema.
El tiempo planificado ha sido de tres semanas,

reduciéndose lo estimado a solo una semana, se
puede notar que la implementación de nuevas
funcionalidades es un proceso bastante ágil.
Localizar Institución. 1
Generador del Balance 1
de inventario y Reportes
de inventario (informes-
estadística).
Funcionalidad común X1
(autenticación y
accesibilidad desde
dispositivos móviles).
Final 1
Tabla 15. Historias Cuarta Iteración.

3. ITERACIONES.
Esta fase incluye varias iteraciones sobre el sistema antes de ser

entregado. El Plan de Entrega está compuesto por iteraciones de no
más de tres semanas. En la primera iteración se puede intentar
establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las historias
que fuercen la creación de esta arquitectura, sin embargo, se puede
variar con el fin de maximizar el valor de negocio. Al final de la última
iteración el sistema estará listo para entrar en producción. Los
elementos que deben tomarse en cuenta durante la elaboración del
Plan de la Iteración son: historias de usuario no abordadas, velocidad
del proyecto, pruebas de aceptación no superadas y tareas no
terminadas en la iteración anterior.
Detallamos cada Iteración:
A. Primera Iteración.
En esta iteración se contempla la realización del

prototipo que además de servir para evaluar la
tecnología también establecerá la arquitectura base del
sistema.
Registro, modificación, búsquedad,
eliminación del grupo, área, 1
departamento, UGEL y modalidad.
Registro, modificacion, búsquedad,
eliminación de datos de la
1
Institución.
Registro, modificación, búsqueda,

1
eliminación del personal.
Final 4
Tabla 16. Detalle - Historias Primera Iteración.

• Estructura de directorios y repositorio de
código fuente.
Para comenzar el desarrollo es necesario

configurar una estructura de directorios adecuada
que facilite las tareas. Utilizando XPWeb esto no
supone un gran problema ya que para cada
proyecto se tiene una estructura bien definida.
Se creará una carpeta principal llamada

inventario y dentro de está las siguietes
subcarpetas:
- bd: Contiene un archivo con el código en

SQL para generar la base de datos.
- Connections: Contiene el archivo PHP para
la conexión a MySQL.
- Content: Contiene los archivos PHP del
usuario para interactuar con el sistema.
- includes: Contiene las librerías y clases.
- imágenes: Dentro de esta carpeta se
encuentran 2 subcarpetas: la carpeta
principal, contiene las imágenes generales
del sistema, dentro de una subcarpeta con el
nombre imagenesusuario, contiene las
imagenes del usuario y la otra subcarpeta con
el nombre iefotos, contiene las imágenes de
la institución Educativa.
- css: Contiene las hojas de estilos para la
interfaz gráfica del Sistema.
- js: Contiene los archivos javascript.
- securePages: Contiene los archivos que
permiten la autenticación.

- Templates: Aquí se encuentran los archivos
html que serán usados como templates en la
autenticación.
- mapa: Contiene los archivos que permitiran
usar los servicios de googlemaps y dos
subcarpetas una para el estilo con el nombre
cssmapa y el otro para las imágenes con el
nombre imagenesmapa.
- wap: Esta carpeta contiene los archivos que
permiten la accesibilidad al sistema desde los
dispositivos móviles.
- administrator: Dentro de esta carpeta se
encuentran 3 subcarpetas: Una subcarpeta
con el nombre clases (contiene las clases
usadas por el administrador del sistema), la
siguiente subcarpeta con el nombre avisos
(contiene los mensajes ante alguna operación
por el administrador del sistema), la ultima
subcarpeta con el nombre scriptadmin
(contiene los archivos PHP que permiten
realizar algunas operaciónes con la base de
datos).
• Diagrama
Se realiza los diagramas UML para las historias

de usuario en esta iteración.

Gestion de la Institucion
Administrador del
sistema
Gestion del personal

Usuario
Figura 11. Caso de Uso para la primera iteración.
Figura 12. Diagrama de clase para la primera

iteración.

• Interfaz Web.
Para la construcción de la interfaz se uso hojas

de estilo y estos fueron llamados desde archivos
PHP para generar la página.
El usuario ingresará al sistema mediante la
siguiente dirección: http://localhost/inventario/
puede variar la palabra localhost dependiendo
donde se alojen los archivos.
El administrador del sistema ingresará al sistema
mediante la siguiente dirección:
http://localhost/inventario/administrator/
- Interfaz Gráfica:
Se realizará varias hojas de estilo durante el
desarrollo del proyecto.
Se muestra el código de la hoja de estilo
“estilos.css”, se encuentra dentro de la carpeta
css.
.texto {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 12px;
font-style:italic;
font-weight: bold;
text-transform: capitalize;
color:#FFFFFF;
}
.mensaje{
font-size: 14px;
font-style: normal;
font-weight: bold;
text-transform: capitalize;
color:#999999;
}
a:link {
color: #FFFFFF;
text-decoration: none;
}

a:visited {
color: #FFFFFF;
}
a:hover {
text-decoration: underline;
color: #FFFFFF;
}
a:active {
color: #FFFFFF;
}
.titulos {
font-size: 20px;
font-style: normal;
font-weight: bold;
color: #00FF66;
}
.tirj {
font-size: 22px;
font-style: normal;
font-weight: bold;
color:#33FFCC;
}
.avisohw{
font-size: 17px;
font-style: normal;
font-weight: bold;
color:#FFFFFF;
}
.textogrande {
font-size: 18px;
font-weight: bold;
color: #00FF00;
}
.tablaleyenda {
font-size: 18px; color: #FFFF00; font-weight: bold;
}
.tablaarea{
color: #FFFF00; font-size: 18px; font-weight: bold;
}
.titulotabla{
color:#00FF00;
font-size: 23px;

font-weight: bold;
}
body {
padding-right: 0px; padding-left: 0px; font-size: 11px; padding-bottom:
0px;
margin: 0px; color: #bcd7ea; padding-top: 0px; font-family: arial,
verdana,
helvetica, sans-serif; background-color: #b9b9b9
}
.numeroitem {
font-size: 9px; width: 20%; text-decoration: none
}
h1 {
font-weight: normal; font-size: 11px; height: 5px
}
h2 {
padding-right: 0px; padding-left: 0px; font-weight: normal; font-size:
11px; padding-bottom: 0px; margin: 0px; color: #e9f3fa;
padding-top: 0px
}
td {
font-size: 11px; color: #3c3c3c; font-family: arial,verdana, sans-serif
}
p{
}
div {
}…
Se muestra el código de la hoja de estilo

“cssadministrador.css”, este archivo se
encuentra dentro de la carpeta css.
/* Documento css (hoja de estilo) para el administrador. */
h1 {
color:white;font-size:24px;text-align:center;
font-family:arial, helvetica, sans-serif;
}
.menu {
color:white;font-size:12px;text-align:center;
font-family:arial, helvetica, sans-serif;font-weight:bold
}
.fondotd{
background:black
}

p{
color:white; font-size:12px;text-align:justify; font-family:arial, helvetica,
sans-serif
}
p.foot{
color:white;font-size:16px;text-align:center; font-family:arial, helvetica,
sans-serif;font-weight:bold
}
a:link,a:visited,a:active{
color:white
}
.td1{
font-size:13px; color:#663399; font-weight:bold; background: #00cccc;
}
body {
background:#000066; background-image:url(../imagenes/agua.jpg)
}
.cabecera {
background:#006699;
padding: 0;
top: auto;
float: inherit;
margin: 0;
position: relative;
}
.foot {
background:#006699;
}
.titulo {
color:#ffffff;
}
.style4 {
color:#ffffff; font-weight:bold;
}…
El resto del código se encuentra en el CD adjunto al Informe o visitar

el blog antes mencionado.
- Código PHP que genera la pagina de

administración creando un objeto de la clase
page.
Este código se encuentra dentro carpeta

administrator.
El archivo tiene por nombre inicio.php

<?php
//incluimos el archivo page.php que contiene la clase
require_once ("clases/page.php");
//crea un objeto de la clase.

$pagina=new Pagina ();
//asignamos información a mostrar en la propiedad contenido
$pagina->contenido = "<p class=\"titulo\" >Bienvenido al Sistema de

Inventarios</p>";
//llamamos al metodo para generar la página

$pagina->Mostrar();
?>
- Para generar la interfaz del administrador

tambien se uso la herencia de clases
Este código se encuentra dentro de la

subcarpeta llamada clases (la subcarpeta
llamada clases esta dentro de la carpeta
administrator).
La clase que se muestra tiene el nombre
consultaClase.php
<?php
//incluimos el archivo page.php que contiene la clase
require_once ("page.php");
//usamos la herencia de clase.
//tenemos la clase Paginahw.

class Paginahw extends Pagina
// creamos la variable $fila2 que tendra la lista de botones a usar

public
$fila2=array("Consultas"=>"consultas.php","Agregar"=>"agregar.php","Estadis
tica"=>"estadistica.php","Ubicacion"=>"ubicacion.php");

//Este metodo genera toda la página a mostrar
public function Mostrar()
{
echo "<html>\n<head>\n";
$this->mostrarTitulo();
$this->mostrarPalabras();
$this->mostrarCssJs();
$this->Estilos2();
echo "</head>\n<body>\n";
$this->mostrarCabecera();
$this->mostrarMenu($this->botones);
$this->mostrarMenu($this->fila2);
echo $this->contenido;
echo $this->contenidoh;
$this->mostrarPie();
echo "</body>\n</html>\n";
}
//Este metodo llama a la hoja de estilos.
public function Estilos2()
{
?>
<link href="../../css/estilo2hw.css" rel="stylesheet" type="text/css" />
<?php
}
}
?>
- Código PHP que generar la página de

presentación del usuario
Este código se encuentra dentro de la carpeta

inventario con el nombre “usuario.php”.
<?php
// Cargamos las clases para la aplicacion
require_once('includes/common/KT_common.php');
// Cargamos las clases para generar los panels.
require_once('includes/jaxon/panels/panels.inc.php');
/**
Creamos un objeto $ctrl de la clase PanelController para realizar las
configuraciones de los paneles(Los paneles contienen la cabecera, el
cuerpo, el menú y el pie de la página web).
*/

$ctrl = new PanelController();
/* Configuración del panel content (Este panel contiene el cuerpo de la
página). */
$panel_Content = & $ctrl->createPanel("Content");
$panel_Content->setStyle("rounded");
$panel_Content->setUpdateEffect("");
$panel_Content->addState("", "content/bienvenido.php", "Bienvenido", "", "");
$panel_Content->addState("Registrarinventario",
"content/registrarinventario.php", "Registrar inventario", "", "");
$panel_Content->addState("Consulta", "content/consulta.php", "Consulta", "",
"");$panel_Content->addState("Reporte", "content/reporte.php", "Reporte", "",
"");$panel_Content->addState("Modificar", "content/modificar.php",
"Modificar", "", "");$panel_Content->addState("RegistrarArea",
"content/registrararea.php", "Registrar Area", "", "");
$panel_Content->addState("RegistrarPersonal",
"content/registrarpersonal.php", "Registrar Personal", "", "");
$panel_Content->addState("cambiarclave", "content/cambiarclave.php",
"Cambiarclave", "", "");$panel_Content->addState("enviaremail",
"content/enviaremail.php", "Enviaremail", "", "");$panel_Content-
>addState("geolocalizador", "content/geolocalizador.php", "Geolocalizador",
"", "");$panel_Content->addState("emuladorwap",
"content/emuladorwap.php", "Emuladorwap", "", "");$panel_Content-
>addState("noticias", "content/noticias.php", "Noticias", "", "");$panel_Content-
>addState("informacionusuario", "content/informacionusuario.php",
"Informacionusuario", "", "");$panel_Content->addState("tooltipusuario",
"content/tooltipusuario.php", "Tooltipusuario", "", "");
//Fin de la configuración del panel content.
// Configuración del panel Footer (Este panel contiene el pie de la página
web).
$panel_Footer = & $ctrl->createPanel("Footer");
$panel_Footer->setStyle("");
$panel_Footer->setUpdateEffect("");
$panel_Footer->addState("", "content/footer.php", "", "", "");
//Fin de la configuración del panel Footer.

/* Configuración del panel Header (Este panel contiene la cabecera de la
página web).*/
$panel_Header = & $ctrl->createPanel("Header");
$panel_Header->setStyle("");
$panel_Header->setUpdateEffect("");
$panel_Header->addState("", "content/header.php", "", "", "");
//Fin de la configuración del panel Header.
/* Configuración del panel Menu (Este panel contiene el menú izquierdo

de la página web). */
$panel_Menu = & $ctrl->createPanel("Menu");
$panel_Menu->setStyle("");
$panel_Menu->setUpdateEffect("");
$panel_Menu->addState("", "content/menu.php", "", "", "");
//Fin de la configuración del panel Menu.
/* Configuración del panel News (Este panel contiene el menú derecho

de la página web). */
$panel_News = & $ctrl->createPanel("News");
$panel_News->setStyle("");
$panel_News->setUpdateEffect("");
$panel_News->addState("", "content/newsnugget.php", "", "", "");
//Fin de la configuración del panel News.
$ctrl->setMasterPanel("Content");
// Fin de la sección de configuración de los paneles.
$ctrl->init();
/* Incluimos un archivo javascript, que contiene las funciones de

petición ajax. */
require_once('includes/jaxon/panels/mx_ajax_request.php');
?>

<!— Está es la pagina en html -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>{{TITLE}}</title>
<meta name="description" content="{{META_DESCRIPTION}}"/>
<meta name="keywords" content="{{META_KEYWORDS}}"/>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>

<link href="includes/jaxon/css/panels.css" rel="stylesheet" type="text/css" />
<link href="css/usuario.css" rel="stylesheet" type="text/css" />


<script type="text/javascript" src="includes/kore/kore.js"></script>
<script type="text/javascript" src="includes/jaxon/js/panels.js"></script>
<script type="text/javascript" src="js/funciones.js"></script>
<?php echo $ctrl->serializeConfigToJs(); ?>
<script type="text/javascript">
</script>
</script>
</head>
<body>
<div id="wrapper" class="threecols">
<div id="header">
<?php
//Generamos la cabecera de la página web.
$panel_Header->renderBegin();
require($panel_Header->getFileName());
$panel_Header->renderEnd();
//Fin de la cabecera.
?>
</div>

<div id="left">
<?php
//Generamos el menú izquierdo de la página web.
$panel_Menu->renderBegin();
require($panel_Menu->getFileName());
$panel_Menu->renderEnd();
//Fin del menu izquierdo.
?>
</div>
<div id="center">
<?php
//Generamos el cuerpo de la página web.
$panel_Content->renderBegin();
require($panel_Content->getFileName());
$panel_Content->renderEnd();
//Fin del cuerpo.
?>
</div>
<div id="right">
<?php
//Generamos el menú derecho de la página web.
$panel_News->renderBegin();
require($panel_News->getFileName());
$panel_News->renderEnd();
//Fin del menu derecho.
?>
</div>
<br style="clear: both" />
<div id="footer">
<?php
//Generamos el pie de la página web.
$panel_Footer->renderBegin();

require($panel_Footer->getFileName());
$panel_Footer->renderEnd();
//Fin del pie.
?>
</div>
</div>
<?php echo $ctrl->renderJsBindings(true); ?>
<!—Incuimos el cargador, cada vez que se realice alguna operación, el
cargador se mostrará, indicando que una operación esta en proceso. -->
<?php require_once("includes/jaxon/loading.html"); ?></body>
</html>
<?php
//Finalizamos.
$ctrl->end();
?>
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.
• Lógica-Código.
Al examinar los diagramas UML y las historias de

usuario., diseñamos la base de datos.
Con el siguiente código creamos una conexión con

la base de datos, realizaremos una conexión local,
puede cambiar la palabra localhost, usuario y
contraseña.
<?php
//variables que almacenan los datos para la conexión.
//Si es local
$hostname_inventario = "localhost";
/* en vez de local host puede ir la ip o el nombre del host en
donde esta alojado el servidor. */
$database_inventario = "inventariohw";
$username_inventario = "root";
$password_inventario = "741285";

//aquí nos conectamos a la base de datos.
$inventario = mysql_pconnect($hostname_inventario,
$username_inventario, $password_inventario) or
trigger_error(mysql_error(),E_USER_ERROR);
?>
Se dejara el código del registro de la I.E. los demás

módulos siguen la misma secuencia, solo cambian
los nombres de los campos en los controles, y en
las consultas SQL.
<?php
//Realizamos la conexion con MySQL.
require_once('../../../Connections/inventario.php');
?>
<?php
/* Cargamos las clase para los avisos ajax ante un dato duplicado
en la base de datos.*/.
require_once('../../../includes/jaxon/widgets/webservice/webservice.php'
);
/* Configuramos los parametros de los avisos, para el codigo
modular si hubiera duplicado */
$web_service1 = new WebService('web_service1');
$web_service1->callFunction('checkearcodigo');
$web_service1->setParameter('form1.codigo_modular', 'form-value');
$web_service1->setResponseElement('duplicate_ie', 'set-innerhtml');
$web_service1->setActionElement('form1.codigo_modular', 'onBlur');
//Seleccionamos la base de datos.
mysql_select_db($database_inventario, $inventario);
/* Esta función permite seleccionar el codigo modular si existiera

en a base de datos, devolviendo un mensaje si existe o una
cadena vacia al contrario. */
function checkearcodigo($loginUsername){
$loginUsername = trim($loginUsername);

//$loginUsername = strtoupper($loginUsername);
$LoginRS__query = "SELECT codigo_modular FROM ie WHERE
codigo_modular='" . $loginUsername . "'";
mysql_select_db($GLOBALS['database_inventario'],
$GLOBALS['inventario']);
$LoginRS=mysql_query($LoginRS__query, $GLOBALS['inventario'])
or die(mysql_error());
$loginFoundUser = mysql_num_rows($LoginRS);
if($loginFoundUser){
return "Este código modular existe ".$loginUsername." escoge
otro!! ";
}
return "";
}
/*Si el código modular es duplicado, entonces se redirecciona a

otra página. */
$MM_flag="MM_insert";
if (isset($_POST[$MM_flag])) {
$MM_dupKeyRedirect="../../avisos/avisoagregar/aie/avisoie.php";
$loginUsername = $_POST['codigo_modular'];
$LoginRS__query = "SELECT codigo_modular FROM ie WHERE
codigo_modular='" . $loginUsername . "'";
$LoginRS=mysql_query($LoginRS__query, $inventario) or
die(mysql_error());
$MM_qsChar = "?";
//append the username to the redirect page
if (substr_count($MM_dupKeyRedirect,"?") >=1) $MM_qsChar = "&";
$MM_dupKeyRedirect = $MM_dupKeyRedirect . $MM_qsChar
."requsername=".$loginUsername;
header ("Location: $MM_dupKeyRedirect");

exit;
}
}
//Esta función restringe la inyección SQL en la base de datos sin
permiso.
function GetSQLValueString($theValue, $theType, $theDefinedValue =
"", $theNotDefinedValue = "")
{
$theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) :
$theValue;
switch ($theType) {
case "text":
$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
break;
case "long":
case "int":
$theValue = ($theValue != "") ? intval($theValue) : "NULL";
break;
case "double":
$theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" :
"NULL";
break;
case "date":
break;
case "defined":
$theValue = ($theValue != "") ? $theDefinedValue :
$theNotDefinedValue;
break;
}
return $theValue;
}

/* Una vez enviado el formulario entra en esta sección.
$editFormAction = $_SERVER['PHP_SELF'];
if (isset($_SERVER['QUERY_STRING'])) {
$editFormAction .= "?" . htmlentities($_SERVER['QUERY_STRING']);
}
if ((isset($_POST["MM_insert"])) && ($_POST["MM_insert"] ==
"form1")) {
//Comprueba que los campos no esten vacios.

if(empty($_POST['codigo_modular'])){ echo "Debe escribir el codigo
modular"; echo "<br/>"; echo "<a href=\"ained.php\">Volver</a>";
exit;
}
if(empty($_POST['nombre_ie'])){echo "Debe escribir el nombre de la
I.E.";echo "<br/>";echo "<a href=\"ained.php\">Volver</a>";
exit;
}
if(empty($_POST['director_ie'])){echo "Debe escribir el nombre del
director de la I.E.";echo "<br/>";echo "<a ref=\"ained.php\">Volver</a>";
exit;
}
//Asignamos a la variable $insertSQL una cadena SQL.

$insertSQL = sprintf("INSERT INTO ie (codigo_modular, idgrupo_ie,
codigo_ugel, codigo_modalidad, nombre_ie, direccion_ie, telefono,
email, web_ie, director_ie, numero_resolucion, provincia,
centro_poblado, distrito_ie) VALUES (%s, %s, %s, %s, %s, %s, %s,
%s, %s, %s, %s, %s, %s, %s)",
GetSQLValueString($_POST['codigo_modular'], "text"),
GetSQLValueString($_POST['idgrupo_ie'], "int"),
GetSQLValueString($_POST['codigo_ugel'], "text"),
GetSQLValueString($_POST['codigo_modalidad'],
"text"),
GetSQLValueString($_POST['nombre_ie'], "text"),

GetSQLValueString($_POST['direccion_ie'], "text"),
GetSQLValueString($_POST['telefono'], "text"),
GetSQLValueString($_POST['email'], "text"),
GetSQLValueString($_POST['web_ie'], "text"),
GetSQLValueString($_POST['director_ie'], "text"),
GetSQLValueString($_POST['numero_resolucion'],
"text"),
GetSQLValueString($_POST['provincia'], "text"),
GetSQLValueString($_POST['centro_poblado'], "text"),
GetSQLValueString($_POST['distrito_ie'], "text"));
//Ejecutamos la setencia SQL

$Result1 = mysql_query($insertSQL, $inventario) or die(mysql_error());
//Si la ejecución fue exitosa, mostramos el siguiente mensaje.

echo "<div align=\"left\" class=\"tablaarea\"></p>Se agrego con
exito!!!</p></div>";
}
//Seleccionamos el codigo de la ugel y el nombre

$query_ugel = "SELECT codigo_ugel, nombre_ugel FROM dreugel
ORDER BY nombre_ugel ASC"; $ugel = mysql_query($query_ugel,
$inventario) or die(mysql_error());$row_ugel =
mysql_fetch_assoc($ugel);$totalRows_ugel = mysql_num_rows($ugel);
//seleccionamos todos los campos de modalidad.

$query_modalidad = "SELECT * FROM modalidad ORDER BY
nombre_modalidad ASC";$modalidad = ysql_query($query_modalidad,
$inventario) or die(mysql_error());$row_modalidad =
mysql_fetch_assoc($modalidad);$totalRows_modalidad =
mysql_num_rows($modalidad);

//seleccionamos todos los campos del grupo.
$query_grupo = "SELECT * FROM grupo_ie ORDER BY
nombregrupo_ie ASC";
$grupo = mysql_query($query_grupo, $inventario) or
die(mysql_error());$row_grupo = mysql_fetch_assoc($grupo);
$totalRows_grupo = mysql_num_rows($grupo);
/* creamos un objeto de la clase AjaxService ,uno de sus metodos

permite ejecutar la función checkearcodigo. */
$ajax_service = new AjaxService();
$ajax_service->exportFunction('checkearcodigo');
$ajax_service->handleAjaxRequest();
?>


<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-
8859-1" />
<title>Agregar I.E.</title>


<link href="../../../css/estilos.css" rel="stylesheet" type="text/css" />


<script type="text/javascript" src="../../../includes/kore/kore.js"></script>
<?php
echo $ajax_service->renderJavascriptStubs();
?>
<?php
echo $web_service1->renderServiceCall();
?>

<script type="text/javascript"
src="../../../includes/jaxon/widgets/webservice/js/webservice.js"></script
>
<!—Fin de cabecera -->
</head>


<body><div align="center"><span class="tirj">Agregar I.E.</span>
</div> <p> </p>

<form method="post" name="form1" action="<?php echo
$editFormAction; ?>">
<table align="center" border="3">
<tr valign="baseline">
<td align="right" ><div align="left" class="letras">Codigo
modular:</div></td>
<td>

<div id="duplicate_ie" style="color:yellow;"></div>
</td> </tr> <tr valign="baseline">
<td align="right" ><div align="left" class="letras">Idgrupo
ie:</div></td> <td><label>

<select name="idgrupo_ie" id="idgrupo_ie">
<?php
do {
?>

<option value="<?php echo $row_grupo['idgrupo_ie']?>"><?php
echo $row_grupo['nombregrupo_ie']?></option>
<?php
} while ($row_grupo = mysql_fetch_assoc($grupo));
$rows = mysql_num_rows($grupo);
if($rows > 0) {
mysql_data_seek($grupo, 0);
$row_grupo = mysql_fetch_assoc($grupo);
}
?>
</select> </label></td> </tr>
<td align="right" ><div align="left" class="letras">Nombre
UGEL:</div></td>
<td><label>

<select name="codigo_ugel" id="codigo_ugel">
<?php
do {
?>
<option value="<?php echo $row_ugel['codigo_ugel']?>"><?php
echo $row_ugel['nombre_ugel']?></option>
<?php
} while ($row_ugel = mysql_fetch_assoc($ugel));
$rows = mysql_num_rows($ugel);
if($rows > 0) {
mysql_data_seek($ugel, 0);
$row_ugel = mysql_fetch_assoc($ugel);
}
?>
</select>
</label></td>

</tr>
<td align="right" ><div align="left" class="letras">Codigo
modalidad:</div></td>
<td><label>

<select name="codigo_modalidad" id="codigo_modalidad">
<?php
do {
?>
<option value="<?php echo
$row_modalidad['codigo_modalidad']?>"><?php echo
$row_modalidad['nombre_modalidad']?></option>
<?php
} while ($row_modalidad = mysql_fetch_assoc($modalidad));
$rows = mysql_num_rows($modalidad);
if($rows > 0) {
mysql_data_seek($modalidad, 0);
$row_modalidad = mysql_fetch_assoc($modalidad);
}
?>
</select> </label></td> </tr>


<td align="right" ><div align="left" class="letras">Nombre
IE:</div></td>
<td><input type="text" name="nombre_ie" value="" size="32"></td>
</tr>
<td align="right" ><div align="left" class="letras">Direccion
IE:</div></td>

<td><input type="text" name="direccion_ie" value=""
size="32"></td></tr>
<td align="right" ><div align="left"
class="letras">Telefono:</div></td>
<td><input type="text" name="telefono" value="" size="32"></td>
</tr>
<td align="right" ><div align="left" class="letras">Email:</div></td>
<td><input type="text" name="email" value="" size="32"></td></tr>
<td align="right" ><div align="left" class="letras">Web
IE:</div></td>
<td><input type="text" name="web_ie" value="" size="32"></td>
</tr>
<td align="right" ><div align="left" class="letras">Director
IE:</div></td>
<td><input type="text" name="director_ie" value="" size="32"></td>
</tr>
<td align="right" ><div align="left" class="letras">Numero
resolucion:</div></td>
<td><input type="text" name="numero_resolucion" value=""
size="32"></td></tr>
<td align="right" ><div align="left"
class="letras">Provincia:</div></td>
<td><input type="text" name="provincia" value="" size="32"></td>
</tr>
<tr valign="baseline"> <td align="right" ><div align="left"
class="letras">Centro poblado:</div></td><td><input type="text"
name="centro_poblado" value="" size="32"></td> </tr>

<td align="right" ><div align="left" class="letras">Distrito
IE:</div></td>
<td><input type="text" name="distrito_ie" value="" size="32"></td>
</tr><tr valign="baseline">
<td nowrap align="right"> </td>


<td><input type="submit" class="asectiontableheadera"
value="Grabar"></td>
</tr></table>

<input type="hidden" name="MM_insert" value="form1">
</form><p> </p></body></html>
<?php
//Liberamos memoria usada de las consultas realizadas.
mysql_free_result($ugel);
mysql_free_result($modalidad);
mysql_free_result($grupo);
?>
• Tests - Pruebas Unitarias.
Se observa en la Figura 30., la velocidad con

que se carga la página.
Con las unidades de pruebas ejecutadas

podemos darnos cuenta de algún error y de la
consistencia, corregirlos y de esta forma disminuir
el tiempo de carga. (Se uso Firebug).
Tests de Pruebas para el Registro de la UGEL
(Zona).

Figura 30. Tiempo de Ejecución: Agregar UGEL (Zona).

Aquí obtenemos nuestro modelo de Objetos del
documento.
Figura 31. DOM: Agregar UGEL (Zona).

Aquí observamos la estructura del documento
xhtml y el código CSS, Javascript, etc. Si existe
algun error nos mostrará con lineas tachadas, previa
corrección, disminuiremos el tiempo de ejecución
de la carga de página y de la consistencia de esta.
Figura 32. Agregar UGEL- Estructura XHTML, CSS y JavaSCript.

B. Segunda Iteración.
En esta interacción se realizará parte de la gestión de

inventario, la gestión de usuario y la autenticación.
del tipo de bien en
catálogo.
del usuario.
Funcionalidad 1
común.(Autenticación)
Final 2
Tabla 17. Detalle - Historias Segunda Iteración.
• Diagrama
Se realiza los diagramas UML para las historias de

usuario en esta iteración.

Autenticacion
Usuario
<<include>>
Registrar usuario
Administrador
del sistema
Gestionde usuario
<<include>>
Cambiar clave
Gestionde inventario
Figura 33. Caso de Uso para la segunda iteración.

Figura 34. Diagrama de clase para la segunda iteración.
• Interfaz Web.
Para la construcción de la interfaz se uso hojas

de estilo y estos fueron llamados desde archivos
PHP para generar la página.
Para la autenticación, el usuario ingresará al

sistema mediante la ruta:

http://localhost/inventario/, si se encuentra de
manera local, y desde Internet, cambiar la palabra
localhost por www.organizaciongalileo.com.
El administrador del sistema ingresará

mediante la ruta:
http://localhost/inventario/administrator/, si se
encuentra de manera local, y desde Internet,
cambiar la palabra localhost por
www.organizaciongalileo.com.
Si el administrador o usuario quieren ingresar al

sistema alterando la ruta, sin previa autenticación,
serán direccionados a la página de autenticación.
Se muestran las interfaces para agregar catálogo,

usuario, para la autenticación, mantenimiento de
catálogo y usuario.
Figura 35. Interfaz –Agregar Tipo de Bien en Catálogo.

Figura 36. Interfaz –Agregar Usuario.
Figura 37. Interfaz –Autenticación.

Figura 38. Interfaz –Mantenimiento Catálogo.
Figura 39. Interfaz –Mantenimiento Usuario.


usuario., diseñamos la base de datos, agregando
las nuevas tablas.
Aquí se muestra el código del Mantenimiento del

Catálogo, el resto del código se encuentra en el
CD adjunto al Informe o en la dirección web antes
mencionada.
- Mantenimiento del Catálogo.
<?php
//Realizamos la conexion a MySQL.
?>
<?php
/*Cargamos las clases para realizar las consultas y
modificaciones asincronas.*/
require_once('../../../includes/common/KT_common.php');
// Incluimos las clase del panel.

require_once('../../../includes/jaxon/widgets/editinplace/editinplace.php')
;
require_once('../../../includes/jaxon/panels/panels.inc.php');
//Incluimos la clase para realizar las tablas.

require_once('../../../includes/jaxon/widgets/dtable/dtable.php');
// Realizamos la conexion con la base de datos.

$conn_inventario = new KT_connection($inventario,
$database_inventario);
//Creamos un objeto de la tabla.

/*Configuramos las tablas para proveer la funcionalidad de
busquedas y modificaciones asincronicas.*/
$dtable_DWAjaxTable1 = new dtable($conn_inventario, 'czona',

'dtable_DWAjaxTable1', 'dreugel');
$dtable_DWAjaxTable1->setUrl(KT_getFullUri());
$dtable_DWAjaxTable1->setMaxRows(10);

$dtable_DWAjaxTable1->addColumn("nombre_ugel",
"STRING_TYPE", "nombre_ugel", "%");
$dtable_DWAjaxTable1->addColumn("nombre_departamento",
"STRING_TYPE", "nombre_departamento", "%");
$dtable_DWAjaxTable1->addColumn("codigo_departamento",
"STRING_TYPE", "codigo_departamento", "%");
$dtable_DWAjaxTable1->setPK("codigo_ugel", "STRING_TYPE");
$dtable_DWAjaxTable1->setDefaultSortColumn('nombre_ugel', 'ASC');
$dtable_DWAjaxTable1->Execute();
$dtable_DWAjaxTable1_filter_sql = $dtable_DWAjaxTable1-
>getFilter();
$dtable_DWAjaxTable1_order_sql = $dtable_DWAjaxTable1-
>getSorter();
$edit1 = new EditInPlace("edit1");

$edit1->setConnection("inventario");
$edit1->setTable("dreugel");
$edit1->setPrimaryKey("codigo_ugel");
$edit1->setEditField("nombre_ugel", "STRING_TYPE");
$edit1->setEnabledCondition("");
$maxRows_czona = $dtable_DWAjaxTable1->getMaxRows();
$pageNum_czona = 0;
if (isset($_GET['pageNum_czona'])) {
$pageNum_czona = $_GET['pageNum_czona'];
}
$startRow_czona = $pageNum_czona * $maxRows_czona;
$NXTFilter_czona = "1=1";
if (isset($dtable_DWAjaxTable1_filter_sql)) {
$NXTFilter_czona = $dtable_DWAjaxTable1_filter_sql;
}
$NXTSort_czona = "nombre_ugel";
if (isset($dtable_DWAjaxTable1_order_sql)) {
$NXTSort_czona = $dtable_DWAjaxTable1_order_sql;
}

//Realizamos la consulta a la base de datos.

$query_czona = sprintf("SELECT * FROM dreugel,departamento
WHERE
dreugel.codigo_departamento=departamento.codigo_departamento
AND %s ORDER BY %s ", $NXTFilter_czona,$NXTSort_czona);

$query_limit_czona = sprintf("%s LIMIT %d, %d", $query_czona,
$startRow_czona, $maxRows_czona);
$czona = mysql_query($query_limit_czona, $inventario) or
die(mysql_error());$row_czona = mysql_fetch_assoc($czona);
if (isset($_GET['totalRows_czona'])) {
$totalRows_czona = $_GET['totalRows_czona'];
} else {
$all_czona = mysql_query($query_czona);
$totalRows_czona = mysql_num_rows($all_czona);
}
$totalPages_czona = ceil($totalRows_czona/$maxRows_czona)-1;
/**
Creamos un objeto de la clase PanelController, y
realizamos la configuración.
*/
$ctrl = new PanelController();
// Esta es la sección de los panels.

// Panel UGEL (Zona).
//Configuramos el panel,
$panel_Zona = & $ctrl->createPanel("Zona");
$panel_Zona->setStyle("");
$panel_Zona->setUpdateEffect("");
$panel_Zona->addState("", "czonapanel.php", "Consulta Zona", "", "");
$panel_Zona->addState("modificarzona", "modificarzona.php",
"Modificarzona", "", "");
// Fin del panel –UGEL (Zona)
$ctrl->setMasterPanel("Zona");
$ctrl->init();
// Estas son las tablas dinámicas que permiten interactuar con el

cliente.
$dtable_DWAjaxTable1->setStartRow($startRow_czona);
$dtable_DWAjaxTable1->setPageNum($pageNum_czona);
$dtable_DWAjaxTable1->setTotalRows($totalRows_czona);
$dtable_DWAjaxTable1->setTotalPages($totalPages_czona);

$ajax_service->exportMethod('edit1', 'updateValue');
// Incluimos la función de peticion AJAX.

require_once('../../../includes/jaxon/panels/mx_ajax_request.php');
?>

<!—Cabecera de la página -->

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-
8859-1" />
<title>{{TITLE}}</title>
<style type="text/css">
.style1 {
color: #000000;
font-weight: bold;
font-size: 24px;
}
.style2 {color: #000000; font-weight: bold; font-size: 24px; }
</style>
<!—Incluimos la hoja de estilo para las tablas -->

<link href="../../../includes/jaxon/widgets/dtable/css/dtable.css"
rel="stylesheet" type="text/css" />
<!—Incluimos los archivos javascript que permiten interactuar

con la tabla para realizar las busquedas. -->
<script type="text/javascript" src="../../../includes/kore/kore.js"></script>
src="../../../includes/jaxon/widgets/dtable/js/dtable.js"></script>
.style3 {
font-size: 12px;
color: #FFFF00;
font-weight: bold;
}
</style>
<!—Incluimos la hoja de estilo editinplace, que se utilizará

cuando la tabla se encuentre en mododedición.-->
<link href="../../../includes/jaxon/widgets/editinplace/css/editinplace.css"
<!—Incluimos los archivos javascript que permiten interactuar

con el cliente en la edición. -->
src="../../../includes/jaxon/widgets/editinplace/js/editinplace.js"></script>

<?php
?>
.style4 { color: #003366;
font-weight: bold;
font-size: 24px;
}
</style>
<!—Incluimos la hoja de estilo para el panel. -->

<link href="../../../includes/jaxon/css/panels.css" rel="stylesheet"
type="text/css" />
<!—Incluimos el archivo javascript para el panel. -->

src="../../../includes/jaxon/js/panels.js"></script>
</script>
<meta name="description" content="{{META_DESCRIPTION}}" />
<meta name="keywords" content="{{META_KEYWORDS}}" />
</head>
<!—Cuerpo de la página -->

<body>
<p>
<?php
//Generamos el panel.
$panel_Zona->renderBegin();
require($panel_Zona->getFileName());
$panel_Zona->renderEnd();
?>
</p>
<?php echo $ctrl->renderJsBindings(true); ?>
</body>
</html>
<?php
//Liberamos la memoria de las consultas realizadas.
mysql_free_result($czona);
//Finalizamos

$ctrl->end();
?>
- Autenticación.
En cada archivo será agregado este código, que

permite autenticar al usuario o administrador,
creando luego una sesion.
<?php
//Nos conectamos a MySQL.
require_once('Connections/inventario.php'); ?>
<?php
//Establecemos una variable global por seguridad.
DEFINE('HELWERGUERRA',TRUE);
/*Incluimos el archivo funciones1 que contiene varias

funciones a utilizar*/
require_once ("funciones1.php");
/* Usamos el modulo SecuresPages, consiste en

consultar en la base de datos, si el login de usuario y
contraseña son los correctos para ese usuario, si no lo
son le muestra un mensaje indicando que no esta
registrado y que vuelva a ingresar.*/
//Incluimos al script que realizara la autenticación.
$rutadirectorio = 'securePages/';
require_once($rutadirectorio."secure.php");
?>
• Test-Pruebas Unitarias.
Realizamos para cada modulo anterior las

respectivas pruebas unitarias, verificando la
velocidad de carga, los posibles errores, la
consistencia en el uso de CSS, XTHML, JavaScript,
etc.

C. Tercera Iteración.
En esta tercera iteración se añadirá parte de la

funcionalidad de la gestión de inventario y se realiza la
gestión de la cuenta contable.
bienes.
cuenta contable.
Final 2
Tabla 14. Detalle - Historias Tercera Iteración.
• Diagrama


Usuario
Verificar catalogo
<<include>>
Gestiondeinventario
Administrador
del sistema
Gestiondecuentas
contables
Figura 40. Caso de Uso para la tercera iteración.

catalogo
codigo_catalogo
descripcion
cuenta
registrar_catalogo()
modificar() codigo_cuenta
buscar() nombre
eliminar() descripcion
uit
1
registrar_cuenta()
1
modificar()
buscar()
eliminar()
1..n
inventario_ie
codigo_inventario
nombre_bien
forma_adquisicion
entidad_procedencia
fecha_adquisicion 0..n area
valor_libros
codigo_area
datos_adquisicion
nombre
unidad_medida
observacion
cantidad
valor_unitario
0..n 1 registrar_area()
valor_total
modificar()
estado_bien
buscar()
otros
eliminar()
registrar_inventario() 1
modificar()
buscar()
eliminar()
localizar()
1..n
personal
codigo_personal
dni
nombre
apellidos
direccion
telefono
email
observacion
registrar personal()
modificar()
buscar()
eliminar()
Figura 41. Diagrama de clase para la tercera iteración.

• Interfaz Web.
Mostraremos la interfaz para registrar el Bien,

cuentas contables y para el mantenimiento de los
Bienes.
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.

usuario., diseñamos la base de datos, agregando
las nuevas tablas.
El Mantenimiento se realiza mediante AJAX,

comentadas en la anterior iteración, se realiza de la
misma forma, solo cambiando los campos, y la
sentencia de SQL.
Observemos el código, de Mantenimiento del Bien

y el Registro de las Cuentas contables.

- Mantenimiento del Bien.
<?php
//Comprobamos si ha establecido sesion, por seguridad.
DEFINE('HELWERGUERRA',TRUE);
include("../../../funciones1.php");
//ruta al admin.
$scriptPath = "../../../";
$rutadirectorio = $scriptPath.'securePages/';
include($rutadirectorio."secure.php");
$thisPage = $_SERVER['PHP_SELF'];
?>
<?php
//Establecemos la conexion a MySQL.
php require_once('../../../Connections/inventario.php');
?>
<?php
/*Incluimos las clases para la aplicación, tablas dinamicas
y para la edición asincronica en estás*/
require_once('../../../includes/common/KT_common.php');
require_once('../../../includes/jaxon/widgets/dtable/dtable.php');
require_once('../../../includes/jaxon/widgets/editinplace/editinpla
ce.php');
// Realizamos una conexion a la base de datos.

$conn_inventario = new KT_connection($inventario,
$database_inventario);
/**
Creamos un objeto de la clase dtable, y lo inicializamos
con el conjunto de registros consultados.
*/
$dtable_DWAjaxTable1 = new dtable($conn_inventario,

'Recordset1', 'dtable_DWAjaxTable1', 'usuario');
$dtable_DWAjaxTable1->setUrl(KT_getFullUri());
$dtable_DWAjaxTable1->setMaxRows(15);
$dtable_DWAjaxTable1->addColumn("codigo_usuario",
"STRING_TYPE", "codigo_usuario", "%");
$dtable_DWAjaxTable1->addColumn("dni", "STRING_TYPE",
"dni", "%");
$dtable_DWAjaxTable1->addColumn("nombre_usuario",
"STRING_TYPE", "nombre_usuario", "%");
$dtable_DWAjaxTable1->addColumn("apellidos_usuario",
"STRING_TYPE", "apellidos_usuario", "%");
$dtable_DWAjaxTable1->addColumn("telefono",
"STRING_TYPE", "telefono", "%");

$dtable_DWAjaxTable1->addColumn("direccion",
"STRING_TYPE", "direccion", "%");
$dtable_DWAjaxTable1->addColumn("email",
"STRING_TYPE", "email", "%");
$dtable_DWAjaxTable1->addColumn("observacion",
"STRING_TYPE", "observacion", "%");
$dtable_DWAjaxTable1->setPK("codigo_ie",
"STRING_TYPE");
$dtable_DWAjaxTable1-
>setDefaultSortColumn('codigo_usuario', 'ASC');
$dtable_DWAjaxTable1->Execute();
$dtable_DWAjaxTable1_filter_sql = $dtable_DWAjaxTable1-
>getFilter();
$dtable_DWAjaxTable1_order_sql = $dtable_DWAjaxTable1-
>getSorter();
/*Creamos un objeto de la clase EditInPlace y lo

configuramos para los controles a utilizar la edición.*/

$edit1->setTable("usuario");
$edit1->setPrimaryKey("codigo_usuario");
$edit1->setEditField("dni", "STRING_TYPE");
$edit2->setEditField("nombre_usuario", "STRING_TYPE");
$edit3->setEditField("apellidos_usuario", "STRING_TYPE");
$edit4->setEditField("telefono", "STRING_TYPE");
$edit5->setEditField("direccion", "STRING_TYPE");

$edit6->setEditField("email", "STRING_TYPE");
$edit7->setEditField("observacion", "STRING_TYPE");
//Configuramos el conjunto de registros obtenidos.

$maxRows_Recordset1 = $dtable_DWAjaxTable1-
>getMaxRows();
$pageNum_Recordset1 = 0;
if (isset($_GET['pageNum_Recordset1'])) {
$pageNum_Recordset1 = $_GET['pageNum_Recordset1'];
}
$startRow_Recordset1 = $pageNum_Recordset1 *
$maxRows_Recordset1;
$NXTFilter_Recordset1 = "1=1";
if (isset($dtable_DWAjaxTable1_filter_sql)) {
$NXTFilter_Recordset1 = $dtable_DWAjaxTable1_filter_sql;
}
$NXTSort_Recordset1 = "codigo_usuario";
if (isset($dtable_DWAjaxTable1_order_sql)) {
$NXTSort_Recordset1 = $dtable_DWAjaxTable1_order_sql;
}

//Ejecutamos la consulta.
$query_Recordset1 = sprintf("SELECT * FROM usuario
WHERE %s ORDER BY %s ",
$NXTFilter_Recordset1,$NXTSort_Recordset1);
$query_limit_Recordset1 = sprintf("%s LIMIT %d, %d",
$query_Recordset1, $startRow_Recordset1,
$maxRows_Recordset1);
$Recordset1 = mysql_query($query_limit_Recordset1,
$inventario) or die(mysql_error());
$row_Recordset1 = mysql_fetch_assoc($Recordset1);
if (isset($_GET['totalRows_Recordset1'])) {
$totalRows_Recordset1 = $_GET['totalRows_Recordset1'];
} else {

$all_Recordset1 = mysql_query($query_Recordset1);
$totalRows_Recordset1 =
mysql_num_rows($all_Recordset1);
}
$totalPages_Recordset1 =
ceil($totalRows_Recordset1/$maxRows_Recordset1)-1;
//End NeXTenesio3 Special List Recordset
/* Metodos que permiten generar las estadisticas, cuantos

registros se encuentran en la consulta */
$dtable_DWAjaxTable1->setStartRow($startRow_Recordset1);
>setPageNum($pageNum_Recordset1);
>setTotalRows($totalRows_Recordset1);
>setTotalPages($totalPages_Recordset1);
//Se realiza las operaciones asincronicas.

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0

Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
<!—Cabecera de la página-->
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<title>Consulta Usuario</title>
<!—Incluimos la hojas de estilo para la tabla-->

<link href="../../../includes/jaxon/widgets/dtable/css/dtable.css"
<!—Incluimos el archivo javascript para interactuar en las

busquedas con la tabla-->

src="../../../includes/kore/kore.js"></script>
src="../../../includes/jaxon/widgets/dtable/js/dtable.js"></script>
<!—Incluimos la hojas de estilos a utilizar cuando la tabla
se encuentre en modo edición-->
<link
href="../../../includes/jaxon/widgets/editinplace/css/editinplace.c
ss" rel="stylesheet" type="text/css" />
<!—Incluimos el archivo javascript para interactuar en

modo edición con la tabla-->
src="../../../includes/jaxon/widgets/editinplace/js/editinplace.js">
</script>
<?php
?>
.style1 {
color: #000099;
font-weight: bold;
font-size: 24px;
}
.style2 {
font-size: 14px;
color: #FFFFFF;
font-weight: bold;
}
.style4 {font-size: 12px; color: #FFFF33; font-weight: bold; }
</style>
</head>
<!—Cuerpo de la página -->

<body>
<p> </p>
<p class="style1">CONSULTA USUARIO </p>
<p class="style1"> </p>
<p>
<!—Formulario-conteniendo los controles. -->

<form class="dtable" id="<?php echo $dtable_DWAjaxTable1-
>listName; ?>" action="<?php echo
KT_escapeAttribute($dtable_DWAjaxTable1->getFilterUri());
?>" method="get">
<div> <?php echo $dtable_DWAjaxTable1->beginList(); ?>
<table border="0" cellpadding="0" cellspacing="0">
<caption>

<?php
$dtable = &$dtable_DWAjaxTable1;
?>
<?php
/*Incuimos el archive PHP que nos permite mostrar la
estadistica (cuantos registros existen)*/
require("../../../includes/jaxon/widgets/dtable/nav/NAV_Text_Sta
tistics.inc.php");
?>
</caption>
<!—Mostramos la tabla -->

<thead>
<tr>
<th class="KT_sort <?php echo
$dtable_DWAjaxTable1->getSortIcon('codigo_usuario');
?>"> </th>
$dtable_DWAjaxTable1->getSortIcon('codigo_usuario');
?>"><a href="<?php echo $dtable_DWAjaxTable1-
>getSortLink('codigo_usuario'); ?>">Codigo_usuario</a></th>
$dtable_DWAjaxTable1->getSortIcon('dni'); ?>"><a
href="<?php echo $dtable_DWAjaxTable1->getSortLink('dni');
?>">Dni</a></th>
$dtable_DWAjaxTable1->getSortIcon('nombre_usuario');
>getSortLink('nombre_usuario');
?>">Nombre_usuario</a></th>
$dtable_DWAjaxTable1->getSortIcon('apellidos_usuario');
>getSortLink('apellidos_usuario');
?>">Apellidos_usuario</a></th>
$dtable_DWAjaxTable1->getSortIcon('telefono'); ?>"><a
href="<?php echo $dtable_DWAjaxTable1-
>getSortLink('telefono'); ?>">Telefono</a></th>
$dtable_DWAjaxTable1->getSortIcon('direccion'); ?>"><a
>getSortLink('direccion'); ?>">Direccion</a></th>
$dtable_DWAjaxTable1->getSortIcon('email'); ?>"><a
>getSortLink('email'); ?>">Email</a></th>
$dtable_DWAjaxTable1->getSortIcon('observacion'); ?>"><a

>getSortLink('observacion'); ?>">Observacion</a></th>
<th> </th>
</tr>
<tr class="filter">
<th class="over_edittext style2"> </th>
<th><input type="text"
name="dtable_DWAjaxTable1_codigo_usuario" value="<?php
echo KT_escapeAttribute($dtable_DWAjaxTable1-
>getFilterValue('codigo_usuario')); ?>" size="25"
maxlength="25" /></th>
name="dtable_DWAjaxTable1_dni" value="<?php echo
KT_escapeAttribute($dtable_DWAjaxTable1-
>getFilterValue('dni')); ?>" size="8" maxlength="8" /></th>
name="dtable_DWAjaxTable1_nombre_usuario" value="<?php
>getFilterValue('nombre_usuario')); ?>" size="30"
name="dtable_DWAjaxTable1_apellidos_usuario"
value="<?php echo
>getFilterValue('apellidos_usuario')); ?>" size="40"
name="dtable_DWAjaxTable1_telefono" value="<?php echo
>getFilterValue('telefono')); ?>" size="15" maxlength="15"
/></th>
name="dtable_DWAjaxTable1_direccion" value="<?php echo
>getFilterValue('direccion')); ?>" size="30" maxlength="50"
/></th>
name="dtable_DWAjaxTable1_email" value="<?php echo
>getFilterValue('email')); ?>" size="35" maxlength="35" /></th>
name="dtable_DWAjaxTable1_observacion" value="<?php
>getFilterValue('observacion')); ?>" size="20" maxlength="35"
/></th>
<th><input class="filterButton" type="submit"
name="dtable_DWAjaxTable1" value="Filter"/></th>
</tr>
</thead>
<tfoot>

<tr>
<td colspan="11"><?php $dtable =
&$dtable_DWAjaxTable1; ?>
<?php
//incluimos los botones para navegar si existiesen más
registros.
require_once("../../../includes/jaxon/widgets/dtable/nav/NAV_Te
xt_Navigation.inc.php");?> </td></tr></tfoot>
<tbody class="data">
<!—Si no existen registros nos aparece el siguiente

mensaje-->
<?php if ($totalRows_Recordset1 == 0) { ?>
<tr>
<td colspan="11">No existen Registros… </td>
</tr>
<?php } ?>
<?php if ($totalRows_Recordset1 > 0) { ?>
<!—Si existen registros en la busquedad se genera la

tabla -->
<?php do { ?>
<tr>
<td><?php echo "<a
href=\"eusuario/eusuario.php?codigo_usuario=".$row_Records
et1['codigo_usuario']."\">";?> <img
src="../../imagenes/eliminar.png" alt="eliminar" width="16"
height="16" border="0" /></a> </td><td><?php echo
KT_FormatForList($row_Recordset1['codigo_usuario'], 25);
?></td> <td><?php
echo $edit1->editForId(@$row_Recordset1['codigo_usuario'],
@$row_Recordset1['dni']);
?></td><td><?php
@$row_Recordset1['nombre_usuario']);
?></td><td><?php
@$row_Recordset1['apellidos_usuario']);?></td>
<td><?php
@$row_Recordset1['telefono']);
?></td><td><?php
@$row_Recordset1['direccion']);?></td><td>
<?php
@$row_Recordset1['email']);
?></td> <td><?php

@$row_Recordset1['observacion']);
?></td> <td> </td> </tr>
<?php } while ($row_Recordset1 =
mysql_fetch_assoc($Recordset1)); ?>
<?php }?>
</tbody></table>
new Widgets.DataTable("<?php echo
$dtable_DWAjaxTable1->listName; ?>");
</script>
<?php echo $dtable_DWAjaxTable1->endList(); ?> </div>
</form></p></body></html>
<?php
//Liberamos la memoria utilizada, debido a la consulta
realizada.
mysql_free_result($Recordset1);
?>
- Agregar Cuenta contable.
<?php
//Realizamos la conexión a MySQL.
php require_once('../../../Connections/inventario.php'); ?>
<?php
/*Cargamos la clase que nos permite realizar consultas
cuando escribimos. */
require_once('../../../includes/jaxon/widgets/webservice/webser
vice.php');
$web_service1 = new WebService('web_service1');

$web_service1->callFunction('checkUsercuenta');
$web_service1->setParameter('form1.cuenta', 'form-value');
$web_service1->setResponseElement('duplicate_cuenta', 'set-
innerhtml');
$web_service1->setActionElement('form1.cuenta', 'onBlur');
/* Esta función nos permitir realizar la consulta del codigo

de la cuenta contable, si existe nos envia un mensaje en
caso contrario una cadena vacia*/
function checkUsercuenta($loginUsername)
{
$LoginRS__query = "SELECT cuenta FROM cuenta WHERE
cuenta='".$loginUsername. "'";
mysql_select_db($GLOBALS['database_inventario'],
$GLOBALS['inventario']);

$LoginRS=mysql_query($LoginRS__query,
$GLOBALS['inventario']) or die(mysql_error());
return "Esta cuenta existe ".$loginUsername." escoge otro!! ";
}
return "";
}
/*Si enviamos el formulario con el código de la cuenta

contable duplicado, la página será redireccionada a otra
(donde nos mostrará que el código de la cuenta contable
es repetido). */
$MM_flag="MM_insert";
if (isset($_POST[$MM_flag])) {
$MM_dupKeyRedirect="../../avisos/avisoagregar/acuentas/avis
ocuenta.php";
$loginUsername= $_POST['cuenta'];
$LoginRS__query = "SELECT cuenta FROM cuenta WHERE
cuenta='".$loginUsername."'";
$LoginRS=mysql_query($LoginRS__query, $inventario) or
die(mysql_error());
$MM_qsChar = "?";
//append the username to the redirect page
if (substr_count($MM_dupKeyRedirect,"?") >=1)
$MM_qsChar = "&";
$MM_dupKeyRedirect = $MM_dupKeyRedirect .
$MM_qsChar ."requsername=".$loginUsername;
header ("Location: $MM_dupKeyRedirect");
exit;
}
}
//
//Esta function es para impedir la inyección SQL.
function GetSQLValueString($theValue, $theType,
$theDefinedValue = "", $theNotDefinedValue = "")
{
$theValue = (!get_magic_quotes_gpc()) ?
addslashes($theValue) : $theValue;
switch ($theType) {
case "text":
break;
case "long":

case "int":
$theValue = ($theValue != "") ? intval($theValue) : "NULL";
break;
case "double":
$theValue = ($theValue != "") ? "'" . doubleval($theValue) .
"'" : "NULL";
break;
case "date":
break;
case "defined":
$theValue = ($theValue != "") ? $theDefinedValue :
$theNotDefinedValue;
break;
}
return $theValue;
}
$editFormAction = $_SERVER['PHP_SELF'];
if (isset($_SERVER['QUERY_STRING'])) {
$editFormAction .= "?" .
htmlentities($_SERVER['QUERY_STRING']);
}
if ((isset($_POST["MM_insert"])) && ($_POST["MM_insert"] ==
"form1")) {
//Estas funciones es para verificar si los campos nos estan

vacios.
if(empty($_POST['cuenta']))
{
echo "Codigo de cuenta vacio , porfavor vuelva a llenar";
echo "<br/>";
echo "<a href=\"./acuenta.php\">VOLVER</a>";
return ;
}
if(empty($_POST['nombre']))
{
echo "Nombre de Cuenta vacio , porfavor vuelva a llenar";
echo "<br/>";
return ;
}
if(empty($_POST['descripcion']))
{
echo "Descripcion vacio , porfavor vuelva a llenar";
echo "<br/>";
return ;
}

//Asignamos a una variable la consulta SQL
$insertSQL = sprintf("INSERT INTO cuenta (codigo_cuenta,
cuenta, nombre, descripcion, uit) VALUES (%s, %s, %s, %s,
%s)",
GetSQLValueString($_POST['codigo_cuenta'],
"int"),
GetSQLValueString($_POST['cuenta'], "text"),
strtoupper(GetSQLValueString($_POST['nombre'], "text")),
strtoupper(GetSQLValueString($_POST['descripcion'], "text")),
GetSQLValueString($_POST['uit'], "text"));
//Seleccionamos la base de datos

$Result1 = mysql_query($insertSQL, $inventario) or

die(mysql_error());
echo "<div align=\"left\" class=\"tablaarea\"></p>Se agrego
con exito!!!</p></div>";
}
$ajax_service->exportFunction('checkUsercuenta');
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0

Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
<!—Cabecera de la página web.-->

<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<title>Agregar Cuentas</title>
<!—inluimos los archivos javascript y hojas de estilo a

usar-->
src="../../../includes/kore/kore.js"></script>
<?php
?>
<?php
echo $web_service1->renderServiceCall();

?><script type="text/javascript"
src="../../../includes/jaxon/widgets/webservice/js/webservice.js"
></script>
<link href="../../../style/estilos.css" rel="stylesheet"
type="text/css" />
</head>
<body>
<p align="center" class="tirj">Agregar Cuenta </p>
<p> </p>
<!—El formulario - conteniendo los controles -->

<form method="post" name="form1" action="<?php echo
$editFormAction; ?>">
<table border="3" align="center" bordercolor="#006699">
<input type="hidden" name="codigo_cuenta" value=""

size="32">
<td align="right" nowrap class="avisohw1">Cuenta:</td>
<td>
<input name="cuenta" type="text"

onblur="do_web_service1_checkUsercuenta();" value=""
size="32" maxlength="25">
<!—Cuando se ingresan datos en el control cuenta(input –

text field) se realiza de manera asincronica la consulta a la
base de datos y si el codigo de cuenta existe nos muestra
un mensaje en el div con identificador duplicate_cuenta
-->
<div id="duplicate_cuenta"
style="color:yellow;"></div></td>
</tr>
<td align="right" nowrap class="avisohw1">Nombre:</td>
<td><input name="nombre" type="text" value="" size="32"
maxlength="80"></td>
</tr>
<td align="right" nowrap
class="avisohw1">Descripcion:</td>
<td><input name="descripcion" type="text" value=""
size="32" maxlength="80"></td>
</tr>

<td align="right" nowrap class="avisohw1">Uit:</td>
<td><label>
<select name="uit" id="uit">
<option value="menor">menor</option>
<option value="mayor">mayor</option>
</select>
</label></td>
</tr>
<td nowrap align="right"> </td>
<td><input name="submit" type="submit"
class="asectiontableheadera" value="Grabar" /></td>
</tr>
</table>
<input type="hidden" name="MM_insert" value="form1">
</form>
<p> </p>
</body>
</html>

consistencia en el uso de CSS, XHTML, JavaScript,
etc.

D. Cuarta Iteración.
La cuarta iteración conllevará la finalización del

sistema tras la implementación de las historias
correspondientes a la gestión de la institución y de
inventarios.
El tiempo planificado ha sido de tres semanas,
reduciéndose lo estimado a una semana, se puede notar
que la implementación de una nueva funcionalidad es un
proceso bastante ágil.
Localizar Institución. 1
Generador del Balance 1
de inventario y Reportes
de inventario (informes-
estadística).
Funcionalidad común 1
(autenticación y
accesibilidad desde
dispositivos móviles).
Final 1
Tabla 19. Detalle - Historias Cuarta Iteración.
• Diagrama


Autenticación
Localizar I.E.
Administrador
del sistema
Consulta dispositivo
móvil
Gestión de inventario
<<include>>
Genera Balance de
inventario
Usuario
Contador
Reporte
Figura 46. Caso de Uso para la cuarta iteración.

Figura 47. Diagrama de clase para la cuarta iteración.

• Interfaz Web.
Mostraremos la interfaz para localizar las

Instituciones educativas, los reportes (informes y
estadística), la presentación del balance de
inventario y la interfaz para los dispositivos
móviles.
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
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.


usuario, diseñamos la base de datos, agregando las
nuevas tablas.
Recordamos que en todos los archivos debe
incluirse en la cabecera-parte principal el archivo
que realiza la autenticación y que verifica si existe la
sesión (módulo de autenticación).
La localización geogr7áfica de la Institución
Educativa se realizará usando la API de google.
Para presentar el video informativo dentro de
cada marcador dentro del mapa se utilizará los
videos de YOU TUBE, las noticias dentro de la
página se realizará utilizando tuberías de YAHOO
usando para ello RSS.
Los Reportes (informes-estadística) y el Balance
de inventario, se realizará mediante consultas a la
base de datos, generando las tablas respectivas.
El módulo para los dispositivos móviles, lo
realizaremos con el leguaje PHP y WML, solo
permitirá realizar consultas, mostrando los datos
mediante barajas y cartas.
- Localización de Institución Educativa.
Se obtuvo una cuenta en google y luego se

solicito un key para usar los servicios de
googlemaps, dentro de la carpeta hwr3 se
encuentra el archivo indice.php que contiene el
código para la presentación del mapa, el archivo
almacenamarcador conteniendo el código que se
encargará de registrar en el archivo
información.xml los datos de una nueva
ubicación geográfica, el archivo

recuperamacadores.php contiene el código
encargado de recuperar toda la información del
archivo información.xml, el archivo
funcionesmapa.js es el encargado de contener
todas las funciones a utilizar, en la subcarpeta
imagenesmapa se encuentra las imágenes para
los marcadores y dentro de la subcarpeta
cssmapa se encuentra el archivo estyle.css
conteniendo el estilo a utilizar.
Para obtener las noticias se obtuvo primero
una cuenta en yahoo para poder usar las tuberías
permitiendo de esta manera unir varios rss de
diferentes canales de noticias. Las noticias en
ingles se tradujeron al español con el servicio de
BABEL FISH dentro de la tubería. Luego se
filtraron las 10 principales noticias. El contenido
de estas noticias es usado para realizar una
búsqueda en YOU TUBE obteniéndose los 10
principales videos de esta información.
Se mostrará el código del archivo indice.php,
recupera marcador y almacena marcador, el
resto del código se encuentra en el CD adjunto o
el página antes mencionada.
Archivo indice.php
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-
com:vml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>Geo Localizador-Galileo</title>


<script
src="http://maps.google.com/maps?file=api&v=2&key=ABQIAAAA
ET6tc7fzrvAW-BOgPAD1-RT-HYfEcmckTAIJpBYgv-
md2QQArhQM5dX9CTCmc4CRcc3j81rwZVW1bA"
type="text/javascript"></script>


<script src="funciones_mapa.js" type="text/javascript"></script>
<link href="style.css" rel="stylesheet" type="text/css" />



<link href="cssmapa/style.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div align="center" class="letras1">Geo Localizador-Galileo</div>


<div id="map" style="width: 800px; height: 600px"></div>
<!—La leyenda del mapa -->

<div>
<p class="style3">Leyenda</p>
<table border="0" bgcolor="#CCCCCC">
<tbody>
<tr>
<td><ul class="style7">
<li><img src="imagenesmapa/ie.gif" alt="Institución Educativa"
width="30" height="35" <span class="style8">I.E.</span></li>
<li><img src="imagenesmapa/dos.png" alt="Universidad" width="20"
height="34" /><span class="style8">Universidad </span></li>
</ul></td>
<li><img src="imagenesmapa/tres.png" alt="Tecnológico" width="20"
height="34" /><span class="style8">Tecnológico</span></li>
<li> <img src="imagenesmapa/cuatro.png" alt="Mercado" width="20"
height="34" /><span class="style8">Mercado</span></li>
</ul></td>
<li><img src="imagenesmapa/cinco.png" alt="Restaurante"
width="20" height="34" /><span class="style8"> Restaurante</span></li>
<li><img src="imagenesmapa/seis.png" alt="Parque" width="20"
height="34" /><span class="style8"> Parque</span></li>
</ul></td>
<li><img src="imagenesmapa/siete.png" alt="Tienda" width="20"
height="34" /><span class="style8"> Tienda </span></li>

<li><img src="imagenesmapa/otros.png" alt="Otros" width="20"
height="34" /><span class="style8">Otros </span></li>
</ul></td>
</tr>
</tbody>
</table>
</div>
<div>
<!—Descripción del modo de uso del mapa-->

<p class="style4">Modo de uso: </p>
<ul class="style5">
<li class="style6">Para ver los datos de las Instituciones y/o casa ya
introducidos, simplemente tienes que pulsar sobre las marcas en el mapa.
</li>
<li class="style6">Para introducir una nueva Institución y/o casa, debes
pulsar sobre su posicion en el mapa y rellenar los datos en el formulario
que aparece. </li>
<li class="style6">Para ingresar un nuevo video, debes escribir la ruta del
video (ejemplo src="<span class="style5">hgygjkhklfild</span>"
de YOUTUBE) </li>
</ul>
<br/>
src="http://app.feeddigest.com/digest3/IEYS7T2N9U.js"><noscript><a
href="http://app.feeddigest.com/digest3/IEYS7T2N9U.html">Click for
"noticiasyoutube".</a> </noscript></script>
</div>
</body>
</html>
Archivo almacenamarcador.php
<?php
// Incluimos la cabecera que contendra el tipo de documento a usar.

header('Content-Type: text/xml');
// Recuperamos los valores de las variables pasadas mediante GET.

$lat = (float)$_GET['lat'];
$lng = (float)$_GET['lng'];
$nombre = $_GET['nombre'];
$direccion= $_GET['direccion'];

$telefono= $_GET['telefono'];
$email= $_GET['email'];
$observacion = $_GET['observacion'];
$enviado = $_GET['enviado'];
$video = $_GET['video'];
// Creamos un nodo XML.

$icon = $_GET['icon'];
$marker = <<<MARKER
<marker lat="$lat" lng="$lng" nombre="$nombre"
direccion="$direccion"telefono="$telefono" email="$email"
observacion="$observacion" enviado="$enviado" video="$video"
icon="$icon"/>\n
MARKER;
// Abrimos el archivo información.xml para añadir información.

$f=@fopen('informacion.xml', 'a+');
// Sino se puede abrir mostrará un mensaje.

if(!$f) die('<?xml version="1.0"?>
<response type="error"><![CDATA[No se ha podido abrir el archivo
informacion.xml]]></response>
');
// Añadimos información en el nodo.

//añadir el nodo
$w=@fwrite($f, $marker);
// Sino se puede escribir en el nodo se mostrará un mensaje.

if(!$w) die('<?xml version="1.0"?>
<response type="error"><![CDATA[No se ha podido escribir en el archivo
informacion.xml]]></response>');
// Cerramos el archivo.
@fclose($f);
// Devolvemos una respuesta.

$newMarkerContent = "<div><b>Nombre
</b>$nombre</div><div><b>Dirección
</b>$direccion</div><div><b>Teléfono
</b>$telefono</div><div><b>Email Institución </b>$email</div>
<div><b>Observación </b>$observacion</div><div><b>Enviado por
</b>$enviado</div><div><embed src=\"$video\" width=\"380\"
height=\"300\"/></div>";
echo <<<XML
<?xml version="1.0"?>
<response type="success"
icon="$icon"><![CDATA[$newMarkerContent]]></response>
XML;
?>

Archivo recuperamarcadores.php
<?php
// Incluimos la cabecera que contendra el tipo de documento a usar.

header('Content-Type:text/xml');
// Abrimos y leemos el archivo informacion.xml.

$markers = file_get_contents('informacion.xml');
// Generamos un documento xml.

echo <<<XML
<markers>
$markers
</markers>
XML;
?>
- Reporte de inventario.
Existen dos tipos de reportes, el reporte por

cuenta contable, y el reporte para todas las
cuentas contables.
En el reporte por cuenta contable,
escogeremos la cuenta contable, luego daremos
clic en aceptar y esta cuenta contable (en la
variable cuenta_contable) se enviara mediante el
método post al archivo reporte1.php, mediante
sesión se obtendrá el código modular, estas dos
variables permiten realizar las consultas y
generar las tablas dinámicas.
Se mostrará el código del reporte por cuenta
contable, el nombre del archivo es reporte1.php.
Archivo reporte1.php
/*Incluimos el archivo que contiene el codigo para la conexión a la base

de datos*/
<?php require_once('../ Connections/inventario.php'); ?>

<?php
/*Verificamos si existe la variable codigo_cuenta y por seguridad usamos

la funcion addslashes*/
$codigo_cuentahw = "-1";
if (isset($_POST['codigo_cuenta'])) {
$codigo_cuentahw = (get_magic_quotes_gpc()) ? $_POST['codigo_cuenta'] :
addslashes($_POST['codigo_cuenta']);
}
/*Verificamos si existe la variable código_modular y por seguridad

usamos la funcion addslashes*/
$codigo_modularhw = "-1";
if (isset($_SESSION['codigo_modular'])) {
$codigo_modularhw = (get_magic_quotes_gpc()) ?
$_SESSION['codigo_modular'] :
addslashes($_SESSION['codigo_modular']);
}

//Calculando la suma total del dinero por cuenta contable consultada.

$query_reportecuenta = sprintf("SELECT sum(valor_libros) +sum( valor_total)
as total FROM inventario_ie WHERE codigo_cuenta = '%s'",
codigo_cuentahw);
$reportecuenta = mysql_query($query_reportecuenta, $inventario) or
die(mysql_error());
$row_reportecuenta = mysql_fetch_assoc($reportecuenta);
$totalRows_reportecuenta = mysql_num_rows($reportecuenta);
//Consultamos toda la información del bien registrado.

$query_reportetablacuenta = sprintf("SELECT codigo_inventario, codigo_area,
nombre_bien, forma_adquisicion, entidad_procedencia, fecha_adquisicion,
valor_libros, datos_adquisicion, unidad_medida, cantidad, valor_unitario,
valor_total, estado_bien, otros FROM inventario_ie WHERE codigo_cuenta
= '%s' ORDER BY codigo_cuenta ASC", $codigo_cuentahw);
$reportetablacuenta = mysql_query($query_reportetablacuenta, $inventario) or
die(mysql_error());
$row_reportetablacuenta = mysql_fetch_assoc($reportetablacuenta);
$totalRows_reportetablacuenta = mysql_num_rows($reportetablacuenta);
//Consultamos la tabla área y personal.

$query_areapersonal = sprintf("SELECT
area.codigo_area,area.nombre_area,personal.nombre_personal,personal.ap
ellidos_personal, personal.observacion_personal FROM area,personal
WHERE area.codigo_area = personal.codigo_area AND
area.codigo_modular= %s",$codigo_modularhw);
$areapersonal = mysql_query($query_areapersonal, $inventario) or
die(mysql_error());

$row_areapersonal = mysql_fetch_assoc($areapersonal);
$totalRows_areapersonal = mysql_num_rows($areapersonal);
//Realizamos la consulta para obtener informacion de la I.E.

$query_cabeceratabla = sprintf("SELECT dreugel.nombre_ugel,
ie.nombre_ie,departamento.nombre_departamento,ie.direccion_ie,ie.provinc
ia,ie.distrito_ie,
modalidad.nombre_modalidad,cuenta.codigo_cuenta,cuenta.nombre FROM
ie,dreugel,modalidad,cuenta,departamento WHERE ie.codigo_ugel =
dreugel.codigo_ugel AND dreugel.codigo_departamento =
departamento.codigo_departamento AND ie.codigo_modalidad =
modalidad.codigo_modalidad AND ie. codigo_modular = '%s' AND
cuenta.codigo_cuenta = '%s'", $codigo_modularhw,$codigo_cuentahw);
$cabeceratabla = mysql_query($query_cabeceratabla, $inventario) or
die(mysql_error());
$row_cabeceratabla = mysql_fetch_assoc($cabeceratabla);
$totalRows_cabeceratabla = mysql_num_rows($cabeceratabla);
//
?>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Reporte</title>
</style>


<link href="../css/reportes.css" rel="stylesheet" type="text/css" />
</head>
<body>


<table width="17%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td> <img src="../imagenes/logominedu.PNG" alt="MINEDU"
width="129" height="59" longdesc="http://www.minedu.com" /></td>
</tr>
<tr>
<td><div align="center" class="letramenorcabecera">MINISTERIO DE
EDUCACIÓN<br />
REPÚBLICA DEL PERÚ</div></td>
</tr>


</table>
<p> </p>

<table width="118%" border="0" align="left" cellpadding="0" cellspacing="0">
<tr>
<td colspan="4" class="charrepor1">ENTIDAD:<?php
$row_cabeceratabla['nombre_ugel'];?></td>
</tr>
<tr>
<td width="36%" class="charrepor1">INSTITUCIÓN
EDUCATIVA:<?php $row_cabeceratabla['nombre_ie'];?></td>
<td width="25%"> </td>
<td width="39%" class="charrepor1">FECHA: <?php echo date('d ')."/".date(
'm')."/".date(' Y'); ?></td>
</tr>
<tr>
<td class="charrepor1">MODALIDAD:<?php
$row_cabeceratabla['nombre_modalidad'];?></td>
<td colspan="3" class="charrepor1"></td>
</tr>
<tr>
<td class="charrepor1">DEPARTAMENTO:<?php
$row_cabeceratabla['nombre_departamento'];?> </td>
<td class="charrepor1">PROVINCIA:<?php
$row_cabeceratabla['provincia'];?> </td>
<td colspan="2">DISTRITO:<?php $row_cabeceratabla['distrito_ie'];?> </td>
</tr>
<tr>
<td colspan="2" class="charrepor1">DIRECCIÓN:<?php
$row_cabeceratabla['direccion_ie'];?></td>
<td colspan="2" class="charrepor1">CUENTA:<?php
$row_cabeceratabla['codigo_cuenta'];?> </td>
</tr>
</table>
<p>


</p>
<p> </p>
<p> </p>


<table width="65%" border="1" align="center" cellpadding="2" cellspacing="0"
class="style57">
<tr>
<td>Código</td>
<td>Área</td>
<td>Nombre</td>
<td>Adquisición</td>

<td>Procedencia</td>
<td>Fecha-adquisición </td>
<td>Valor libros </td>
<td>Datos-adquisición </td>
<td>Unidad-medida</td>
<td>Cantidad</td>
<td>Valor-unitario</td>
<td>Valor-total</td>
<td>Estado del bien</td>
<td>Otros</td>
</tr>
<?php do { ?>
<tr>
<td><?php echo $row_reportetablacuenta['codigo_inventario']; ?></td>

<td><?php echo $row_reportetablacuenta['codigo_area']; ?></td>
<td><?php echo $row_reportetablacuenta['nombre_bien']; ?></td>
<td><?php echo $row_reportetablacuenta['forma_adquisicion']; ?></td>
<td><?php echo $row_reportetablacuenta['entidad_procedencia']; ?></td>
<td><?php echo $row_reportetablacuenta['fecha_adquisicion']; ?></td>
<td><?php echo $row_reportetablacuenta['valor_libros']; ?></td>
<td><?php echo $row_reportetablacuenta['datos_adquisicion']; ?></td>
<td><?php echo $row_reportetablacuenta['unidad_medida']; ?></td>
<td><?php echo $row_reportetablacuenta['cantidad']; ?></td>
<td><?php echo $row_reportetablacuenta['valor_unitario']; ?></td>
<td><?php echo $row_reportetablacuenta['valor_total']; ?></td>
<td><?php echo $row_reportetablacuenta['estado_bien']; ?></td>
<td><?php echo $row_reportetablacuenta['otros']; ?></td>
</tr>
<?php } while ($row_reportetablacuenta =

mysql_fetch_assoc($reportetablacuenta)); ?>
</table>

<p> </p>
<p> </p>


<p>Valor total:<?php echo $row_reportecuenta['total']; ?></p>

<p>Leyenda: </p>
<p>Área-Encargado</p>


<table border="1" cellpadding="0" cellspacing="0">
<tr>
<td>codigo_area</td>
<td>nombre_area</td>
<td>nombre_personal</td>
<td>apellidos_personal</td>
<td>observacion_personal</td>
</tr>
<?php do { ?>
<tr>
<td><?php echo $row_areapersonal['codigo_area']; ?></td>

<td><?php echo $row_areapersonal['nombre_area']; ?></td>
<td><?php echo $row_areapersonal['nombre_personal']; ?></td>
<td><?php echo $row_areapersonal['apellidos_personal']; ?></td>
<td><?php echo $row_areapersonal['observacion_personal']; ?></td>
</tr>
<?php } while ($row_areapersonal = mysql_fetch_assoc($areapersonal)); ?>
</table>

<p> </p>
<p class="style20">*Adquisición y Estado del Bien:</p>
<table width="39%" height="38%" border="2" align="left" cellpadding="2"

cellspacing="0">
<tr>
<td width="42%" height="14%" bgcolor="#CCCCCC"

class="style64">FORMA DE AQUISICIÓN </td>
<td width="58%" bgcolor="#CCCCCC" class="style64">ESTADO DEL BIEN
</td>
</tr>
<tr>
<td height="14%" class="style63"><strong>C: COMPRA </strong></td>

<td class="style63"><strong>N: NUEVO </strong></td>
</tr>
<tr>
<td height="14%" class="style63"><strong>D: DONACIÓN

</strong></td>
<td class="style63"><strong>B: BUENO </strong></td>
</tr>
<tr>
<td height="14%" class="style63"><strong>F: FABRICACIÓN

</strong></td>
<td class="style63"><strong>R: REGULAR </strong></td>
</tr>
<tr>
<td height="14%" class="style63"><strong>R: REPOSICIÓN

</strong></td>
<td class="style63"><strong>M: MALO </strong></td>
</tr>
<tr>
<td height="14%" class="style63"><strong>P: PERMUTA </strong></td>

<td class="style63"> </td>
</tr>
<tr>
<td height="16%" class="style63"><strong>O:OTRO CASUAL

</strong></td>
<td class="style63"> </td>
</tr>
</table>
<p> </p>


</body>
</html>

<?php
//Liberamos la memoria.
mysql_free_result($reportecuenta);
mysql_free_result($reportetablacuenta);
mysql_free_result($areapersonal);
mysql_free_result($cabeceratabla);
?>
- Estadística de los Bienes.
Para realizar la estadística el administrador

desde la página principal dará clic en el link con
el nombre Generador y luego debe escribir en el
campo estadística el código modular, obtendrá de
esta manera la información gráfica indicando la
cuenta contable y la respectiva cantidad de
dinero en cada una.
El usuario en la página principal, sólo dará clic

en el link-estadística y obtendrán la información
gráfica.
Se mostrará el código del archivo

estadisticarespuesta.php del administrador.
Archivo estadisticarespuesta.php
<?php
/* Incluimos el archivo que contiene el codigo de conexion con la base de

datos */
?>

<?php
/*Aqui capturamos la variable pasada, y por seguridad usamos

addslashes */
$colname_ie = "-1";
if (isset($_POST['codigo_modular'])) {
$colname_ie = (get_magic_quotes_gpc()) ? $_POST['codigo_modular'] :
addslashes($_POST['codigo_modular']);

//Realizamos la consulta para obtener informacion de la I.E.

$query_cie = sprintf("SELECT * FROM ie,modalidad,dreugel,departamento
WHERE ie.codigo_modular = '%s' AND
ie.codigo_modalidad=modalidad.codigo_modalidad AND
ie.codigo_ugel=dreugel.codigo_ugel AND
dreugel.codigo_departamento=departamento.codigo_departamento",$colna
me_ie);
$cie = mysql_query($query_cie, $inventario) or die(mysql_error());

$row_cie = mysql_fetch_assoc($cie);
$totalRows_cie = mysql_num_rows($cie);
//
/*Realizamos las sumas de la cantidad de dinero por cuenta para el

respectiva I.E. */
$query_cinventario = sprintf("SELECT sum(inventario_ie.valor_libros) AS
valor,sum(inventario_ie.valor_total) AS total,cuenta.codigo_cuenta FROM
inventario_ie,cuenta WHERE codigo_modular = '%s' AND
cuenta.codigo_cuenta=inventario_ie.codigo_cuenta GROUP BY
cuenta.codigo_cuenta",$colname_ie);
$cinventario = mysql_query($query_cinventario, $inventario) or
die(mysql_error());
$row_cinventario = mysql_fetch_assoc($cinventario);
$totalRows_cinventario = mysql_num_rows($cinventario);
$cont=$totalRows_cinventario;
//
/*Se realiza la gráfica.*/

/* Asignamos valores para el ancho y vertical */
$anchohorizontal =580;
$anchovertical = 420;
$ancho_char=180;

//Creamos la imagen
$estadistica=ImageCreate($anchohorizontal,$anchovertical);
//Esta funcion asigna color

$bgcolor=ImageColorAllocate($estadistica,250,250,250);
//Para el color del fondo.

ImageFill($estadistica,0,0,$bgcolor);
//Color de pixel.
$pixelcolor=ImageColorAllocate($estadistica,255,255,255);
//Para el color de las barras.

$color[]=ImageColorAllocate($estadistica,0,0,255);
$max=0;
//Recorremos los datos devuelto por la consulta.

do {
//Recuperamos los códigos de cuenta en un array.

$title[]=$row_cinventario['codigo_cuenta'];
/* La cantidad de dinero del Bien en algunos se ingreso en el campo

valor en libros y en otros en valor total.*/
if(empty($row_cinventario['total']))
{
$arr[]=$row_cinventario['valor'];
}else{
$arr[]=$row_cinventario['total'];
} while ($row_cinventario= mysql_fetch_assoc($cinventario));
//
/* Esta funcion es para obtener el dinero mayor de todas las cuentas,

este valor se usará para graduar las barras gráficas o si es cero
significa que no existe dinero en las cuentas por lo tanto no se
mostrara ninguna gráfica*/
for($i=0;$i<$cont+1;$i++)
if($arr[$i]>$max)

{
$max=$arr[$i];
//Si no existe dinero en las cuentas, nos devolvera un mensaje.

if($max==0)
{
die("Los bienes no tienen dinero assignado o no hay bienes
registrados, para generar estadistica");
}
//Graduamos el espacio entre barrás y cuantas barras se graficarán

$ratio = $ancho_char/$max;
$barwidth = round(500/$cont);
for($i=0;$i<$cont;$i++)
{
if(!($j<3))
{
$j=0;
}
else
{
$j++;
}
$iniciox=50+($i*$barwidth);
$finx=50 + ($i*$barwidth) + $barwidth;
$inicioy = 250-$arr[$i]*$ratio;
$finy = 250;
//
//Pintamos la barra y colocamos los respectivas titulos.

ImageFilledRectangle($estadistica,$iniciox,$inicioy,$finx,$finy,$color[$j]);
Imagestring($estadistica,3,$iniciox,$inicioy-20,"S/.".$arr[$i],$color[$j]);
Imagestringup($estadistica,3,$finx-
$barwidth,$finy+105,$title[$i],$color[$j]);
//
//Dibujamos las coordenadas.

ImageLine($estadistica,50,50,50,250,$color[3]);
ImageLine($estadistica,50,250,400,250,$color[3]);

//Generamos el grafico.
ImagePNG($estadistica,"estadistica.png");
//Destruimos
ImageDestroy($estadistica);
?>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Estadística</title>
<link href="../../../css/estilos.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div align="center" class="tirj">Estadística</div>

<p> </p>
<p> </p>


<div align="center" >
<img src="estadistica.png" alt="Estadistica" width="653" height="517" />
</body>
</html>
<?php
//Liberamos la memoria usada por las consultas.

mysql_free_result($cinventario);
mysql_free_result($cie);
?>
- Balance de inventario.
Para realizar el Balance de Inventario el

administrador del sistema deberá estar en la

página principal y debe pulsar en link con el
nombre Generador, luego debe escribir el código
modular en el campo Balance, entonces se
abrirá una nueva ventana generando el Balance
de inventario hasta la fecha (revisar el código en
CD o en el blog antes mencionado).
- Consultas Dispositivo móvil.
El emulador usado se encuentra desarrollado

en otro idioma, teniendo en cuenta esto, los
botones para adelante y atrás aparecen con
unos caracteres distintos al nuestro.
Para ingresar a consultar al sistema mediante
un dispositivo móvil, se tendrá que escribir la
URL:
www.organizaciongalileo.com/inventario/wap/
Para usar PHP y WML podemos configurar
dentro del archivo httpd.conf, o se puede forzar
la salida del documento de PHP con un header.
En el módulo para dispositivos móviles,
forzaremos la salida.
En el archivo cabecera.php se escribió el
header:
<?php
header("Content-type: text/vnd.wap.wml");
header("Cache-Control: no-cache, must-
revalidate");
header("Pragma: no-cache");
echo ("<?xml version='1.0'?>");
?>

El cual incluimos en cada archivo PHP.
La primera página(index.php) muestra una
imagen por un intervalo de tiempo, luego aparece
un mensaje pidiendo el código del usuario, lo
envía al archivo verificación.php, el cual verifica
si el usuario existe y si es así le pide la clave,
luego ingresa al menú consultas(wap.php)
previa verificación de la clave.
En el menú consultas, se puede escoger el tipo
de consulta por bien, área, personal y resumen.
Para realizar las consultas se tiene que escribir
el código de bien, área, personal, luego serán
mostrados los resultados.
Para salir del sistema, escoger salir del menú,
entonces se anularán los valores de las variables,
enviándonos un mensaje que salimos.
Se mostrará el código de index.php y

wap.php, el resto del código revisar el CD adjunto
al informe o visitar el blog antes mencionado
Archivo index.php
<?php
//Cabecera-Header
include("wml/cabecera.php");
?>
<wml>
<card id="inventario" title="inventario" ontimer="#usuario">



<onevent type="onenterforward">
<refresh>
<setvar name="codigo_usuario" value=""/>
</refresh>
</onevent>

<onevent type="onenterbackward">
<refresh>
<setvar name="codigo_usuario" value=""/>
</refresh>
</onevent>


<timer value="40"/>
<do type="accept" label="Ingresar">
<!—Si acepta sera enviado a la carta usuario. -->

<go href="#usuario">
</go>
</do>
<! – Centra la imagen -->

<p align="center">
<img src="../imagenes/wapgalileo.wbmp" alt="Galileo"/>
</p>
<?php
//La fecha es mostrada.
echo "Hoy es :".date(d)." de ".date(F)." del ".date(Y);
?>
</card>

//Carta usuario.
<card id="usuario" title="Usuario">

<do type="accept" label="OK">
<go method="post" href="wml/verificacion.php">
<postfield name="codigo_usuario" value="$codigo_usuario"/>
</go>
</do>
<p>INVENTARIO</p>
<p>
<!—Ingreso del codigo de usuario -->
USUARIO:<br/>
<input type="text" name="codigo_usuario" value="" size="6"/>
<br/>
</p>
</card>
</wml>
Archivo wap.php
<?php
//Cabecera-Header
include("cabecera.php");
?>
<!—DTD del documento -->
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">

<?php
//Incluimos el archive que permite la connexion con la base de datos.
include("../../Connections/inventario.php");
//Recogemos las variables pasadas.
$codigo_usuario = $_POST['codigo_usuario'];
$password = $_POST['password'];
//Verificamos si el usuario y password son los correctos.
$query_Recordset1 = sprintf("SELECT codigo_usuario, password FROM

usuario WHERE codigo_usuario = '%s' AND
password='%s'",$codigo_usuario,$password);
$Recordset1 = mysql_query($query_Recordset1, $inventario) or

die(mysql_error());
$row_Recordset1 = mysql_fetch_assoc($Recordset1);
$cantidad = mysql_num_rows($Recordset1);
if($cantidad < 1){
//Si no existe el usuario, entonces ingresa a la baraja siguiente.
?>
<wml>
<card id="password" title="clave incorrecta">

<do type="accept" label="Inicio">
<go method="post" href="../index.php">
<postfield name="codigo_usuario" value=""/>
<postfield name="password" value=""/>

</go>
</do>
<p align="center"> GALILEO </p>
<p> Clave Incorrecta <br/> </p>
</card>
</wml>
<?php }else{
//Si existe el usuario, entonces ingresa al menu de consultas.
?>
<wml>
<card id="menu" title="Consultas">
<!—Se Puede escoger el tipo de consulta a realizar, enviando además

por el metodo post las variables codigo_usuario y password. -->
<p>Consultas:
<select>
<option value="1">Bien
<onevent type="onpick">
<go method="post" href="consultabien.php">
<postfield name="codigo_usuario" value="<?php echo $codigo_usuario;

?>"/>
<postfield name="password" value="<?php echo $password; ?>"/>
</go>
</onevent>
</option>
<option value="2">Area

<go method="post" href="consultaarea.php">
<postfield name="codigo_usuario" value="<?php echo $codigo_susuario;

?>"/>
</go>
</onevent>
</option>
<option value="3">Personal
<go method="post" href="consultapersonal.php">

?>"/>
</go>
</onevent>
</option>
<option value="4">Resumen
<go method="post" href="resumen.php">

?>"/>
</go>
</onevent>
</option>
<option value="5">Salir

<go method="post" href="salida.php">

?>"/>
</go>
</onevent>
</option>
</select>
</p>
</card>
</wml>
<?php
/*Liberamos memoria por la consultas realizadas. */
mysql_free_result($Recordset1);
?>

consistencia en el uso de CSS, XHTML, JavaScript,
etc.

• Base de Datos.
En cada iteración se realizo los diagramas de clase

y se diseñó la base de datos, quedando al final la
base de datos de esta manera:
Figura 61. Diseño lógico de la base de datos.

4. PRODUCCIÓN.
La fase de producción requiere de pruebas adicionales y revisiones

de rendimiento antes de que el sistema sea trasladado al entorno del
cliente. Al mismo tiempo, se deben tomar decisiones sobre la
inclusión de nuevas características a la versión actual, debido a
cambios durante esta fase. Tras cada iteración se ha entregado los
módulos al cliente.

CAPÍTULO V
EVALUACIÓN DEL SISTEMA
CAPÍTULO V
EVALUACIÓN DEL SISTEMA
5.1. EVALUACIÓN ECONÓMICA.
A. COSTO INICIAL DEL SISTEMA.

Sumamos las horas correspondientes de cada iteración realizada para
luego convertirlos en jornadas (cada jornada tiene 8 horas laborales
equivalentes a un día de trabajo).
Se trabajó de lunes a viernes, cumpliendo por semana 40 Horas.
3 semanas 3semanas 2 semanas 2 semanas

(05/02/2007 (26/02/2007 (19/03/2007 (02/04/2007
Modulos
al al al al
23/02/2007) 16/03/2007) 30/03/2007) 13/04/2007)
Autenticación
Gestión de Institución.
Gestión de usuario
Gestión de inventario
Gestión de personal
Gestión de cuenta
contable
Versión 0.1 0.2 0.3 0.4
Horas: 3*40=120 3*40=120 2*40=80 2*40=80
Total 400 Horas.
Tabla 20. Tiempo del desarrollo del sistema.
Convertimos en meses laborales, como obtenemos el costo (costo

por hora 7 soles).
Capítulo V: Evaluación del Sistema. 215

Inversión Total
Total de horas estimadas. 400 Horas
Total jornadas por persona 50

(8horas).
Total meses (25dias). 2
Total Horas * S/.7.00 S/.2800.00
Tabla 21. Costo inicial del sistema.
Se acordo disponer de un monto adicional de 300 soles, si el

cliente desea cambiar, eliminar o agregar otras historias de usuario.
El monto adicional se usó.
Costo Inicial del sistema = S/. 2800.00 + S/.300.00
Costo inicial del sistema = S/. 3100.00
B. COSTO DE MATERIALES, EQUIPOS Y SOFTWARE.
La institución educativa PRONOE GALILEO, cuenta con los equipos y

algunos de los software utilizados, representaremos con un asterisco (*) si es
que cuenta, siendo el costo S/. 0.00.

Materiales:
Descripción Cantidad P.Unitario(S/.) Costo(S/.)
Kit de útiles de escritorio. 1Kit 6.00 6.00
Papel Bond Atlas A4 80 gr. 1 Millar 12.00 12.00
Cartucho de tinta negra y a color. 2 Und. 75.00 150.00
Memoria Flash Simpletech. 1 unidad 35.00 35.00

500MB
Costo de materiales: 203.00
Tabla 22. Costo de materiales.
Costo total de materiales: S/. 203.00
Equipos:
Descripción Cantidad P.Unitario(S/.) Costo(S/.)
Computadora Pentium IV, 3.0 4 Unidad 2070.00 8280.00*

Ghz, 512Mb de RAM, HD 80 GB,
FD 1.44.
Impresora Epson Stylus 468 1 Unidad 195.00 195.00*

Color.
Costo de equipos: 8475.00*
Tabla 23. Costo de equipos.
Costo total de equipos: S/. 0.00

Licencia de software:
Descripción Cantidad P.Unitario($) Costo($)
Windows 2003 Server. 1 Unidad 280.00 280.00*
Windows XP Profesional. 3 Unidad 200.00 600.00*
Macromedia Dreamweaver 8. 1 Unidad 340.00 340.00
MX Kollection Pro 1 Unidad 120.00 120.00
Gestion de proyecto XPWeb 3.3.2. 0.00 0.00

1 Unidad
(Software libre)
DBdesginer 4.0. 0.00 0.00
1 Unidad
(Software libre)
ArgotUML 0.24.
1 Unidad 0.00 0.00
(Software libre)
Extensión FireBug 1.04.
1 Unidad 0.00 0.00
(Software libre)
Servidor Apache 2.2.4.
1 Unidad 0.00 0.00
(Software libre)
Lenguaje: PHP 5.2.1, JavaScript,
CSS, XML. 1 Unidad 0.00 0.00
(Software libre)
MySQL 5.0.27.
1 Unidad 0.00 0.00
(Software libre)
Navegador Mozilla Firefox 2.0.
1 Unidad 0.00 0.00
(Software libre)
Costo de Software: 1340.00
Tabla 24. Costo de software.
Costo total de equipos:
$ 1340.00 – $/.880.00 = $ 460.00
El cambio de dólar a la fecha 10 de febrero del 2007 es de 3.182,

convirtiendo en soles tenemos:

Costo de software: 460* 3.182
Costo de software: S/. 1463.72
C. COSTO OPERATIVO.
El costo operativo es de S/. 250.00 soles al mes, ya que el director de la

institución educativa tomará como una de sus funciones la administración de
los bienes, por lo tanto se incrementará su sueldo.
5.2. ANÁLISIS DE LOS BENEFICIOS.
A. BENEFICIOS TANGIBLES.
Del comité de inventarios se escogió a un integrante para que pueda
realizar la toma de inventarios, desgastando esté mucho tiempo y
cometiendo muchos errores.
El sistema genera beneficios económicos al reducir el tiempo en la toma

de inventario de los bienes, con la cual el personal se podrá dedicar a otras
actividades.
Se prescindirá de un trabajador.
Ganancia: S/. 520.00 * 1 = S/. 520.00 por mes
B. BENEFICIOS INTANGIBLES.
• Reducción del tiempo de consultas.
• Mejor control de los bienes de la institución.

• Menor tiempo de respuesta para elaborar los reportes y el balance de
inventario.
5.3. CALCULO DE LA RECUPERACIÓN DE LA INVERSIÓN.
• Costo inicial del sistema: S/. 3100.00 (Solo una vez).
• Costo de materiales: S/. 203.00
• Costo de equipos: S/. 0.00
• Costo de software: S/. 1463.72
• Licenciamiento del software: S/. 1463.72
• Costo operacional anual: S/.250.00*12= S/.3000.00
• Beneficios tangibles en ahorro de personal para un periodo de un año:

S/. 520.00 * 12 = S/. 6240.00.
Ganancia anual:
S/. 6240.00 – S/.3000.00 = S/. 3240.00
Costo total inicial:
S/. 3100.00 + S/. 203.00 + S/.0.00 + S/. 1463.72 = S/.4766.72
Determinado el costo total de desarrollo del sistema: S/. 4766.72 y

habiendo establecido un beneficio anual la cual proporcionará un ingreso de
S/. 3240.00. y tomando en cuenta la tasa de interes bancario de 8.7% anual,
calcularemos el tiempo de la recuperación del capital invertido.

Figura 62. Tiempo de recuperación del capital invertido.
Trasladando los ingresos anuales al tiempo presente podemos determinar

en cuanto tiempo el capital invertido será recuperado.
Haciendo los cálculos tenemos:
Figura 63. Fórmula para determinar el valor presente.
Donde:
P = Valor presente.
F = Valor futuro.
n = Periodo de tiempo.
i = Tasa de interes anual.

Para el primer año tenemos:
1
P = 3240/(1+0.087)
P = 2980.68
Y así sucesivamente hasta obtener la recuperación total de la inversión.
Año Inversión Inicial Beneficio Presente Beneficio Anual Utilidad(S/.)

0 4.766,72 0,00 0,00 -4.766,72
1 4.766,72 2.980,68 3.240,00 -1.786,04
2 1.786,04 2.742,12 3.240,00 956,08
3 -956,08 2.522,65 3.240,00 3.478,72
Tabla 25. Utilidad por año.
Como se puede apreciar, apartir del segundo año se empieza a obtener

utilidades.
No se requiere de mucha inversión inicial debido a que la institución

educativa PRONOE GALILEO cuenta con parte de los equipos y software.
Además la gran parte de software utilizado es Libre.

CONCLUSIONES
Se obtuvieron las siguientes conclusiones en todo el proceso del desarrollo del

proyecto:
• Debido al uso de la Metodología Programación Extrema, el sistema se

logró entregar antes del tiempo acordado, consiguiéndose la satisfacción y
confianza del cliente.
• La arquitectura desarrollada es extensible y reutilizable, siendo realmente

sencilla y rápida la implementación de nuevas funcionalidades.
• Se logró disminuir los errores al registrar el bien.
• Se eliminó la duplicidad de datos.
• Se logró disminuir el tiempo en las consultas de los bienes
• Se logró disminuir el tiempo en hallar el valor en dinero de los bienes que

cuenta la institución educativa.
• Se logró disminuir el tiempo en las actualizaciones de los bienes.
• Se logró entregar a tiempo el balance de inventario.
• Se logró conocer de donde proviene el bien mobiliario.
• Se logró conocer a que área pertenece y quién esta a cargo de un

determinado bien.
• El sistema permitió mejorar el control de los bienes de la Institución

Educativa PRONOE GALILEO.
• El Sistema fue evaluado a través de sus costos y beneficios, la cual

evidencia la factibilidad del desarrollo del sistema, resumidos en un retorno
del capital invertido, reducción del tiempo y costo de los procesos.
Conclusiones. 223
RECOMENDACIONES
• Implementar otro módulo que permita realizar el mantenimiento del

inventario desde dispositivos móviles.
• Implementar un modulo que permita auditar los cambios que se realizan

en los datos del sistema (Auditoría).
• Extender la aplicación web que se desarrolló en un inventario de

existencias.
• Desarrollar módulos para la obtención del libro diario, caja y bancos,

mayor, etc. Que permitan interactuar con el modulo de inventarios.
• Mejorar la seguridad en la transferencia de información usando SSL o

TLS.
• Usar servicios web (web services) en el sistema, para obtener el cambio

de dólar, temperatura, etc.
• Mejorar el mashup realizado, trazando un plano de la ciudad de

Chimbote.
• Realizar un módulo que permita brindar información mediante RSS del

mashup a la red.
• Implementar una zona de foros y chat para el sistema.
• La creación del área de informática en la organización galileo, que se

encargue de realizar proyectos informáticos así como el mantenimiento
de los sistemas y la capacitación de su personal en el uso de las TIC.
Recomendaciones. 224
REFERENCIA BIBLIOGRÁFICA
Alarcón, R. (2000). Diseño orientado a objetos con UML (pp. 15-16). Madrid,
España: Editorial Eidos.
Beck, K. y Grenning, J. (2001, 15 de Noviembre). Manifesto for agile software

development. Extraído el 09 de Febrero, 2007, desde http://agilemanifesto.org
Canós, J., Leiter, P. y Penadés, C. (2003, 10 de Octubre). Metodologías ágiles

en el desarrollo de software. Extraído el 07 de Febrero, 2007, desde
http://www.willydev.net/descargas/prev/TodoAgil.Pdf
Catarí, E. (2001). El control interno contable para el inventario de la división de

repuestos en la Empresa Mega Tunal C.A.. Tesis Para optar al Titulo de
Licenciatura en Contaduría Pública, Escuela de Contabilidad, Universidad
Centroccidental "Lisandro Alvarado", Venezuela.
Carvajal, G. (2007, 08 de Febrero). YAHOO PIPES. Extraído el 12 de Febrero,

2007, desde http://www.labrujulaverde.com/2007/02/08/yahoo-pipes/
Cranford, J. (2005). DHTML y CSS advanced (pp. 25-26). Madrid, España: Editorial
Grupo Anaya S.A.
Duckett, J. (2005). Accessible XHTML and CSS web sites. Indiana, Estados Unidos
de América: Editorial Wiley Publishing INC.
Eidos (2000). HTML dinámico, modelos de objetos y javascript, (versión 1.0.0).
Ferrer, J. (2003, 13 de Diciembre). Metodología Ágiles. Extraído el 07 de Febrero,

2007, desde http://libresoft.dat.escet.urjc.es/html/downloads/ferrer-20030312.pdf
Referencia bibliografía. 225

Gilfillan, I. (2002). La Biblia de MySQL. Madrid, España: Editorial Grupo Anaya
S.A.
Google. Google Maps. Extraído el 14 de Febrero, 2007, desde

http://maps.google.es/
Guerra, H. (2005, 16 de Abril). Blog. Extraído el 14 de Febrero, 2007, desde

http://hw123.blogspot.com
Herrera, E y Huerta, C. (2004). Programación básica para dispositivos móviles con

tecnología WAP, (1ra ed.). Lima, Perú: Editorial Megabyte.
IGSM (2006, 11 de Enero). Emulador WAP. Extraído el 13 de Febrero, 2007, desde

http://www.igsm.pl/emulator/
Monografía. Control de inventarios. Extraído el 12 de Febrero, 2007, desde

http://www.monografias.com/trabajos15/inventario/inventario.shtml
OG (2006, 10 de Septiembre). Página Web. Extraído el 11 de Febrero, 2007, desde

http://www.organizaciongalileo.com
Oviedo (2004, 11 de Abril). Universidad de Oviedo – SGML. Extraído el 11 de

Febrero, 2007, desde http://www6.uniovi.es/sgml.html
Posadas, M. (2000). Introducción al lenguaje XML. Madrid, España: Editorial Eidos.
Pressman, R. (2002). Ingeniería del software un enfoque práctico, (5ta ed.). Madrid,
España: Editorial McGRAW-HILL Companies.
Príapo, N. y Rodríguez, T. (2005, 17 de Agosto). Arquitectura de 3 Capas.

Extraído el 08 de Febrero, 2007, desde http://www.colabora.net
Ramírez, L. (2002). Aplicando herramientas UML, (1ra ed.). Lima, Perú: Editorial
Macro.

Ron, J. (2001, 19 de Febrero). What is extreme programming. Extraído el 10 de
Febrero, 2007, desde http://www.xprogramming.com/xpmag/whatisxp.htm
Roque, J. (2005). Contabilidad computarizada con SISCONT, (1ra ed.). Lima, Perú:
Editorial Macro E.I.R.L.
Sánchez, G. (2007). ONESS: un proyecto open source para el negocio textil

mayorista desarrollado con tecnologías open source innovadoras. Proyecto de fin de
carrera para optar el Bachiller en Ingeniería de informática, Facultad de informática,
Universidad Da Coruña, España. Disponible en http://oness.sourceforge.net
SBNP (2006, 22 de Febrero). Software de inventarios mobiliarios institucional de la

SuperIntendencia de Bienes Nacionales del Perú. Extraído el 11 de Febrero, 2007,
desde http://www.sbn.gob.pe/sbn1/wmain/home.html
Software ARGOUML. ARGOUML. Extraído el 11 de Febrero, 2007, desde

http://argouml.tigris.org/
Software DBDESIGNER. DBDESIGNER. Extraído el 11 de Febrero, 2007, desde

http://www.fabforce.net/dbdesigner4/
Vila, F. (2004, 16 de Junio). Manual de referencia javascript. Extraído el 06 de

Febrero, 2007, desde http://www..softdownload.com.ar/manualfv.pdf
Welling, L. y Thompson, L. (2005). Desarrollo web con PHP y MYSQL, (3ra ed.).
Madrid, España: Editorial Grupo Anaya, S.A.
Wells, D. (2003, 10 de Agosto). Extreme Programming: A gentle introduction.

Extraído el 09 de Febrero, 2007, desde http://www.extremeprogramming.org
Wikipedia (2007a). Problemas de compatibilidad del DOM. Extraído el 12 de

Febrero, 2007, desde http://es.wikipedia.org/wiki/Document_Object_Model

Wikipedia (2007b). JavaScript. Extraído el 12 de Febrero, 2007, desde
http://es.wikipedia.org/wiki/JavaScript
Wikipedia (2007c). CSS. Extraído el 12 de Febrero, 2007, desde

http://es.wikipedia.org/wiki/CSS
Wikipedia (2007d). RSS. Extraído el 12 de Febrero, 2007, desde

http://es.wikipedia.org/wiki/RSS
Wikipedia (2007e). YOUTUBE. Extraído el 12 de Febrero, 2007, desde

http://es.wikipedia.org/wiki/YouTube
Wikipedia (2007f). MASHUP. Extraído el 12 de Febrero, 2007, desde

http://es.wikipedia.org/wiki/YouTube
Wikipedia (2007g). Servidor Apache. Extraído el 12 de Febrero, 2007, desde

http://es.wikipedia.org/wiki/Servidor_HTTP_Apache
Wikipedia (2007h). UML. Extraído el 12 de Febrero, 2007, desde

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
Wilfred, A. y Gupta, M. (2002). Proyectos Profesionales PHP. Madrid, España:

Editorial Grupo Anaya, S.A.

ANEXO
CATALOGO DE BIENES NACIONALES
GRUPO CLASE TIPO CODIGO DESCRIPCION
04 22 0050 04220050 ABONADORAS EN GENERAL
32 22 0013 32220013 ABRELATA INDUSTRIAL
74 22 0007 74220007 ABRIDORA DE SOBRES - EXTRACTORA DE CORRESPONDENCIA
53 22 0010 53220010 ACELERADOR LINEAL
60 22 0013 60220013 ACELEROGRAFO
60 22 0025 60220025 ACELEROMETRO
60 22 0033 60220033 ACIDOMETRO
60 22 0041 60220041 ACLIMETRO
67 50 0009 67500009 ACONDICIONADOR CILINDRICO
39 22 0050 39220050 ACORDEON
60 22 0050 60220050 ACTINOGRAFO
60 22 0107 60220107 ACTINOMETRO
46 22 0050 46220050 ACUMULADOR DE ENERGIA - EQUIPO DE UPS
67 22 0050 67220050 ACUÑADORA
74 08 0028 74080028 ADAPTADOR INALAMBRICO PARA RED
53 22 0019 53220019 ADAPTADOR RADIOLOGICO PEDIATRICO
53 22 0028 53220028 ADAPTOMETRO
60 22 0135 60220135 ADITOMETRO
53 22 0037 53220037 ADMITANCIMETRO
39 64 0050 39640050 ADORNO DECORATIVO (MAYOR A 1/8 UIT)
60 22 0163 60220163 AEROCARTOGRAFO
39 22 0280 39220280 AEROGRAFO
60 22 0220 60220220 AEROMETRO
67 22 0139 67220139 AEROSIMPLEX
53 22 0050 53220050 AFILADOR AUTOMATICO DE CUCHILLAS
95 22 0050 95220050 AFINADOR DE SONIDO
74 22 0013 74220013 AGENDA ELECTRONICA
53 22 0160 53220160 AGITADOR (OTROS)
53 22 0164 53220164 AGITADOR CON ROLLOS
53 22 0166 53220166 AGITADOR DE BALANCEO
53 22 0168 53220168 AGITADOR DE BOLSAS DE SANGRE
53 22 0145 53220145 AGITADOR DE PIPETA
53 22 0176 53220176 AGITADOR DE PLACAS
53 22 0182 53220182 AGITADOR DE PRECISION
53 22 0188 53220188 AGITADOR DE TUBOS
53 22 0189 53220189 AGITADOR DE VAIVEN
53 22 0190 53220190 AGITADOR DE VARILLA
04 22 0240 04220240 AGITADOR MAGNETICO
53 22 0191 53220191 AGITADOR ORBITAL - AGITADOR DE ROTACION CIRCULAR
53 22 0192 53220192 AGITADOR ORBITAL Y VAIVEN
53 22 0194 53220194 AGLUTINADOR
53 22 0200 53220200 AGLUTINOSCOPIO
60 22 0234 60220234 AGREGOMETRO
60 22 0241 60220241 AGREGONOMETRO
39 64 0325 39640325 AGUAMANIL (MAYOR A 1/8 UIT)
67 64 0007 67640007 AHUMADOR DE METAL
81 22 0050 81220050 ALA DELTA
32 64 0050 32640050 ALACENA
46 22 0265 46220265 ALARMA DE LUZ
60 22 0248 60220248 ALBUMINOMETRO
60 22 0262 60220262 ALCOHOLIMETRO
60 22 0269 60220269 ALEXOMETRO
74 22 0025 74220025 ALIMENTADOR AUTOMATICO DE TRANSPARENCIAS
04 22 0335 04220335 ALIMENTADOR AUTOMATICO PARA PECES
11 22 0050 11220050 ALIMENTADOR DE AIRE SECO
95 22 0088 95220088 ALIMENTADOR DE SEÑAL
67 50 0014 67500014 ALINEADOR DE BIELAS
67 50 0026 67500026 ALINEADOR DE LUCES DE VEHICULOS
53 22 0203 53220203 ALINEADOR DE PROTESIS ORTOPEDICAS
67 50 0038 67500038 ALINEADOR DE RUEDAS - BALANCEADOR DE RUEDAS
67 22 0228 67220228 ALINEADOR LASER
67 50 0050 67500050 ALISADORA
67 50 0077 67500077 ALISADORA DE CONCRETO - ALISADORA DE PAVIMENTO
39 64 0600 39640600 ALTAR
46 22 0480 46220480 ALTERNADOR
60 22 0276 60220276 ALTIMETRO
53 22 0207 53220207 AMALGAMADOR
67 36 0050 67360050 AMASADORA MEZCLADORA DE ASFALTO
67 82 0050 67820050 AMBULANCIA
60 22 0304 60220304 AMILOGRAFO
53 22 0218 53220218 AMNIOSCOPIO
67 50 0105 67500105 AMOLADORA
60 22 0333 60220333 AMPERIMETRO
67 50 0160 67500160 AMPLIADORA DE FOTOGRAFIAS
67 50 0215 67500215 AMPLIADORA DE PLACAS FOTOGRAFICAS
95 22 0126 95220126 AMPLIFICADOR (OTROS)
95 22 0163 95220163 AMPLIFICADOR DE AUDIO
95 22 0201 95220201 AMPLIFICADOR DE RADIOFRECUENCIA
95 22 0220 95220220 AMPLIFICADOR MEZCLADOR
95 22 0239 95220239 AMPLIFICADOR TELEFONICO
53 22 0229 53220229 AMPOLLETADOR
60 22 0338 60220338 AMPRODER
60 22 0339 60220339 ANALIZADOR AUTOMATICO DE FLUORESCENCIA POLARIZADA
53 22 0240 53220240 ANALIZADOR BIOQUIMICO
53 22 0259 53220259 ANALIZADOR CARDIOLOGICO COMPUTARIZADO
67 22 0250 67220250 ANALIZADOR DE BUJIAS
46 22 0695 46220695 ANALIZADOR DE CALIDAD DE LA ENERGIA ELECTRICA
53 22 0278 53220278 ANALIZADOR DE CALIDAD PARA RAYOS X
95 22 0248 95220248 ANALIZADOR DE COMUNICACION DIGITAL

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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL DEL SANTA

“DESARROLLO DE UN APLICATIVO WEB BASADO

INFORME DE PRÁCTICAS PRE - PROFESIONALES PARA

M.S. DIANA CECILIA MUÑOZ CASANOVA.

NVO. CHIMBOTE – PERÚ.

A MIS PADRES CON PROFUNDO AMOR Y

A LA MAGISTER DIANA MUÑOZ CASANOVA POR

A DIOS, POR ACOMPAÑARME EN TODO

A MI MADRE GLICERIA ELICIA FLORES LÓPEZ

A OMAR BELLIDO VALDIVIEZO POR SU

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

“DESARROLLO DE UN APLICATIVO WEB BASADO EN AJAX

Con el propósito de optar el Grado de Bachiller en ingeniería de Sistemas

Dicho trabajo es producto de los conocimientos adquiridos durante

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

Por lo expuesto espero, sabrán dispensar las omisiones que pueda

El área de dirección forma la parte principal del organigrama estructural de

Actualmente, la organización galileo cuenta con un servidor web apache

Hasta ahora para el registro de sus bienes lo ha realizado en excel y el

El presente trabajo, propone realizar un aplicativo web que permita mejorar

Para desarrollar dicho trabajo se hace uso de la metodología de

At present, The organization galileo considers with a server web apache

The extreme- programming methodology is made use of to develop said

Hoy en día con la rápida expansión de Internet y los avances de las

Las aplicaciones web son populares debido a la practicidad del navegador

Una ventaja significativa en la construcción de aplicaciones web es que

Los desarrolladores web comúnmente utilizan lenguajes interpretados del

La actitud de esta sociedad ha provocado la transición de aplicaciones

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

En el CAPITULO II, Se realiza el Planteamiento del Problema a través de

En el CAPITULO III, Se detalla el Marco Teórico, base del desarrollo de

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

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

Finalmente se anotarán las conclusiones y recomendaciones que se han

1.1. RAZÓN SOCIAL. 1

1.3. DESCRIPCIÓN DE LA INSTITUCIÓN. 1

1.6. OBJETIVOS. 2-3

1.7. PRINCIPIOS INSTITUCIONALES. 3-4

1.9. SERVICIOS QUE BRINDA LA INSTITUCIÓN. 4-5

1.11. ORGANIGRAMA FUNCIONAL DE LA INSTITUCIÓN. 7

PLANTEAMIENTO DEL PROBLEMA. 8-14

2.1. REALIDAD PROBLEMÁTICA. 8-9

2.2. FORMULACIÓN DEL PROBLEMA. 9

2.3. JUSTIFICACIÓN DEL PROYECTO. 9-10

2.6. OBJETIVOS. 11-13

2.8. METODOLOGÍA EMPLEADA. 13

MARCO TEÓRICO. 15-71

3.1. SITIO WEB DINÁMICO. 15-16

3.2. APLICATIVO WEB. 16-17

3.3. MODELO DE OBJETOS DE DOCUMENTO. 18-19

3.4. AJAX. 19-23

3.5. WEB 2.0. 23-29

3.7. JAVASCRIPT. 31-32

3.8. HOJAS DE ESTILO EN CASCADA (CSS). 32-33

3.9. XML. 33-36

3.10. RSS. 36-37

3.12. MASHUP. 37-38

3.13. YAHOO PIPES. 38

3.14. SERVIDOR HTTP APACHE. 38-39

3.15. PHP. 39-40

3.16. MySQL. 40-41

3.18. ARGOUML 42-43