XP WebML, fusin de dos

metodologas para la implantacin

de sistemas WEB
Universidad Tecnolgica Boliviana
Mayra Alejandra Galvez Ticona
9 de agosto de 2014










Contenido
Resumen ....................................................................................................................................... 4
CAPITULO I ............................................................................................................................... 4
1. MARCO REFERENCIAL ................................................................................................. 4
1.1. PRESENTACIN ....................................................................................................... 4
1.2 COMO FUNCIONA EL RGIMEN SANCIONATORIO? ......................................... 5
1.3. DEFINICIN DEL PROBLEMA .................................................................................. 6
1.4. OBJETIVOS ..................................................................................................................... 8
1.4.1 Objetivo General ........................................................................................................ 8
1.4.2 Objetivos Especficos .................................................................................................. 8
1.5. ALCANCES, LIMITES Y APORTES .......................................................................... 9
1.5.1 Alcances ....................................................................................................................... 9
1.5.2. Limites ........................................................................................................................ 9
CAPITULO II ............................................................................................................................ 10
MARCO TERICO ................................................................................................................. 10
2.1 INTRODUCCIN ........................................................................................................... 10
2.2 INGENIERIA DE SOFTWARE .................................................................................... 10
2.2.2 Metodologas Agiles .................................................................................................. 10
2.3 PROGRAMACION EXTREMA ................................................................................... 11
2.3.1 Qu es la programacin extrema (XP)? ............................................................... 11
2.3.4 Fases del XP ............................................................................................................. 11
2.3.4.1 Fase 1: Planificacin del proyecto ..................................................................... 11
a) Historias de usuario ...................................................................................................... 12
b) Release planning* ......................................................................................................... 12
c) Iteraciones ...................................................................................................................... 13
d) Velocidad del proyecto ................................................................................................. 13
e) Programacin en pareja ............................................................................................... 13
f) Reuniones diarias ........................................................................................................... 14
2.3.4.2 Fase 2: Diseo. ..................................................................................................... 14
a) Diseos simples .............................................................................................................. 14
b) Glosarios de trminos ................................................................................................... 14
c) Riesgos ............................................................................................................................ 14
d) Funcionalidad extra ...................................................................................................... 14
e) Refactorizar ................................................................................................................... 14
f) Tarjetas C.R.C. .............................................................................................................. 15
2.3.4.3 Fase 3: Codificacin. ........................................................................................... 15
a) El cliente est siempre disponible ................................................................................ 15
c) Desarrollar la unidad de pruebas primero ................................................................. 15
2.3.4.4 Fase 4: Pruebas. ................................................................................................... 16
2.4 INGENIERIA WEB ....................................................................................................... 16
2.4.1 Metodologas de Modelado WEB ........................................................................... 16
2.5 WEBML .......................................................................................................................... 16
2.6 GRAILS ........................................................................................................................... 17
2.7 MySQL ............................................................................................................................. 17
CAPITULO III .......................................................................................................................... 18
MARCO APLICATIVO ........................................................................................................... 18
3.1 INTRODUCCION ........................................................................................................... 18
3.2. REQUERIMIENTOS GENERALES ........................................................................... 18
3.3 ADAPTACION DEL PROCESO DE DESARROLLO XP Y WEBML ................... 19
3.4 ITERACION 0 ................................................................................................................. 20
3.5 ITERACION 1: I.- MODULO DE ADMINISTRACION DE CUENTAS DE
USUARIOS ............................................................................................................................ 20
3.5.1 Fase I: Planificacin ................................................................................................. 20
3.5.2 Fase II: Diseo .......................................................................................................... 23
3.5.3 Fase III: Codificacin ............................................................................................... 27
3.5.4 Fase IV: Pruebas ...................................................................................................... 28
3.6 ITERACION 2: II. MODULO DE ADMINISTRACION DE PARAMETROS ....... 28
3.7. ITERACION 3: III- MODULO DE REGISTRO Y PENALIZACION .................... 29
3.7.1 Fase I: Planificacin ................................................................................................. 29
3.8 ITERACION 4: IV- MODULO DE ESTADISTICAS Y REPORTES ...................... 29
3.8.1 Fase I: Planificacin ................................................................................................. 29
CAPITULO IV .......................................................................................................................... 30
CONCLUSIONES Y RECOMENDACIONES ...................................................................... 30
6.1 INTRODUCCION ........................................................................................................... 30
6.2 Conclusiones .................................................................................................................... 30


Resumen
El presente documento contiene el procedimiento para el desarrollo del SCSA Sistema
Web de Control a los Servicio de Aseo- Caso EMALT- EL ALTO. En el primer captulo
se desarroll aspectos introductorios para el sistema, desde la descripcin de la
problemtica, pasando por el planteamiento del objetivo general y los objetivos
especficos, adems de mencionar los respectivos alcances.
El segundo captulo hace hincapi en las metodologas utilizadas como la Programacin
Extrema XP y la metodologa WebML la fusin de dos metodologas, una gil y la otra
WEB, tambin se describe tecnologas y herramientas usadas para llevar a cabo este
proyecto.
Para el tercer captulo se presenta lo que es el desarrollo mismo del proyecto, donde se
aplic las metodologas XP y WebML desarrollados en sus distintas fases como
corresponde y se realiz la integracin exitosa de ambas metodologas. En este captulo se
hace importante revisar las iteraciones que conlleva la metodologa XP y la forma como se
hace la integracin con la metodologa WebML.
En los ltimos captulos mencionamos aspectos sobre de calidad del software, seguridad de
sistema, y finalmente las conclusiones y recomendaciones necesarias para este sistema.
CAPITULO I
1. MARCO REFERENCIAL

1.1. PRESENTACIN

La Empresa Municipal de Aseo El Alto (E.M.A.L.T) es una entidad descentralizada del
Gobierno Autnomo Municipal de El Alto que se encarga del aseo en la ciudad de El Alto
y que da servicio a ocho distritos, servicio a industrias, servicio a hospitales y el servicio
de lavado. Para llevar a cabo esta tarea, contrata los servicios de las empresa te TREBOL y
COLINA.
La misin de la empresa de TREBOL es el de realizar el aseo en la Ciudad de El Alto y
EMALT se encarga de supervisar dicho trabajo, para este trabajo EMALT consta con
personal que son denominados Fiscales que se despliega por cada uno de los distritos,
Hospitales e Industrias de la Cuidad de El Alto.
En las instalaciones de la empresa TREBOL es donde se realiza el debido registro de las
observaciones y los reportes que se realizan en cada uno de los distritos de la Ciudad de El
Alto.
La ubicacin actual de EMALT es en ciudad Satlite Plaza Bolivia lado Ex-cine Fanola,
Ciudad de El Alto.
1.2 COMO FUNCIONA EL RGIMEN SANCIONATORIO?

El trabajo de aseo en la ciudad de El Alto es una labor que tiene que estar supervisada en
todo momento, ya que si se llegara a realizar un trabajo deficiente no se podra sancionar, y
es tras este problema que se realizaron normas y reglas que se tienen que seguir para poder
tener un servicio mucho ms eficiente y de calidad.
Cuando realizan una falta los funcionarios de la empresa TREBOL, el Fiscal de EMALT
reporta de inmediato al radio operador a una central que se encuentra en las mismas
instalaciones de TREBOL. Para llegar a realizar un reporte antes debe haberse realizado
dos observaciones el cual tendr dos llamadas de atenciones y a la tercera observacin se
convierte directamente en Reporte, despus de esto segn la infraccin que se haya
cometido se sancionara a la empresa TREBOL.
Las penalizaciones y las faltas en las que se basa el rgimen sancionatorio estn regidas por
normas custodiadas bajo normas legales que la empresa E.M.A.L.T. sigue con cuidado.
El rgimen sancionatorio se encarga de sancionar una deficiencia o una infraccin a la
empresa TREBOL, bajo unas lista de faltas o delitos con la que cuenta la empresa EMALT
y que cada una de esta cuentan con su respectiva multa o penalidad donde se van
acumulando puntos dependiendo del tipo de falta que se haya cometido.
Cuando hay una infraccin el radio operador de EMALT pasa un informe al radio operador
de TREBOL para que este de una llamada de atencin a los trabajadores que estn
cometiendo esta infraccin y as tambin la empresa de TREBOL estar al pendiente de las
infracciones que se comete por sus trabajadores.
Lo que se pretende realizar con este sistema en base al funcionamiento del rgimen
sancionatorio es automatizar todas las tareas que se realiza en esta rea desde lo ms
principal que es el resguardo de la informacin hasta poder brindar informacin actualizada
y en tiempo real.
Una de las tareas ms importantes ser el poder sancionar de manera automtica todas las
deficiencias de los servicios de aseo, tambin realizar el control y seguimiento a estos
servicios de esta manera tener informacin actualizada y de manera precisa.
1.3. DEFINICIN DEL PROBLEMA
Al analizar el comportamiento que se tiene para realizar una sancin se pudo evidenciar
que existen problemas de control y de organizacin en el departamento de B.L.R.I.T
El departamento de B.L.R.I.T. Se encarga del registro, la organizacin y la actualizacin
de esta sanciones emitida por los funcionarios, lo que implica tener un seguimiento y
control de las actividades de los servicios de aseo de la ciudad de El Alto, generando un
gran volumen de informacin a diario, haciendo mucho ms complejo el manejo de esta
informacin por la cantidad de esta, ya que diariamente se genera una gran informacin de
sanciones.
Tambin el trabajo que se desarrolla es demasiado lento, en el momento de realizar algn
reporte ya que se tiene que revisar una variedad de documentos e ir seleccionando los
datos que son de su utilidad con herramientas computacionales aisladas, llegando a
retrasar la emisin de informes y de reportes que son solicitados por diferentes unidades
de la empresa TREBOL y la empresa EMALT.
Existe cantidad masiva de informacin recibida diariamente por lo cual en el
momento de buscar informacin se vuelve muy moroso y complicado.
La informacin es procesada manualmente lo cual causa demoras en el momento
del registro causando una prdida de informacin e informacin imprecisa.
Toda la informacin est guardada en documentos Excel, el cual este formato
permite cierto lmite de registros y si este llegara a su lmite causara una gran prdida de
informacin.
El procesamiento de grandes volmenes de informacin es manual por lo cual el
seguimiento y control de estas no es el adecuado, y se observa deficiencias en el servicio
como ser retraso de los resultados requeridos o de reportes.
La informacin va en crecimiento, por lo tanto la documentacin tambin crece lo
que hace ms complicado el manejo de esta informacin de reportes de las infracciones.
Los reportes tambin se lo realizan de forma manual y se repiten diariamente, lo
cual causa demoras en el momento de la emisin del reporte llegando as de manera
imprecisa a manos de los gerentes.
Los equipos computacionales se encuentran aislados por este motivo la informacin
llega a destiempo a las personas interesadas.
No existe informacin completa de todos los funcionarios de la Empresa TREBOL
provocando un gran retraso en el momento de realizar el registro de las penalidades.
El empleo de herramientas computacionales se lo realiza de forma aislada
provocando que la informacin demore en llegar a las personas interesadas tanto de
TREBOL y de EMALT.
Cmo se puede optimizar el proceso de sancin de infracciones a las empresas de los
servicios de aseo de la ciudad de El Alto para llevar un mejor control y seguimiento de
sus funciones?
1.4. OBJETIVOS

1.4.1 Objetivo General

Desarrollar un sistema Web de Seguimiento y control de los servicios de aseo de la ciudad
de El Alto, para que la empresa EMALT automatice las actividades de los operadores.
1.4.2 Objetivos Especficos

Realizar los registros de forma automtica teniendo ya los datos necesarios en el
sistema.
Disear una Base de Datos que nos permita guardar toda la informacin
necesaria y en el momento de realizar algunas bsquedas se lo realice consultando
la base de datos
Desarrollar scripts para generar los reportes de forma automtica, as se
optimizara el tiempo de emisin
Manejar toda la informacin posible de forma digital para evitar la cantidad
masiva de papeles.
Procurar la menor perdida de informacin, para poder realizar una buena auditoria
en cualquier momento.
Dar informacin a EMALT y TREBOL en tiempo real.
Mantener actualizada la informacin de la base de datos, por altas, bajas y
modificaciones.
Generar de forma automtica informes y reportes de acuerdo a las necesidades de
la institucin, evitando retrasos en la entrega de los resultados.
Jerarquizar a los usuarios del sistema dando privilegios segn el tipo de usuario
que sean.
Realizar un reporte que nos permita saber que personas utilizaron el sistema y
para que lo utilizaron dndonos la hora y la fecha exacta para que en algn
momento se pueda realizar una auditora si fuera necesario.
1.5. ALCANCES, LIMITES Y APORTES

1.5.1 Alcances

Con la elaboracin del proyecto se pretende desarrollar un sistema de informacin el cual
cubra con las necesidades urgentes de B.L.R.I.T., acortando el tiempo de respuesta y de
servicio presentando una informacin oportuna, considerndose en el proyecto lo siguiente:
Este proyecto a desarrollar se manejara con tecnologa web ya que los operadores se
encuentran en lugares diferentes de la ciudad de El Alto.
El sistema se encargara de registrar, alertar e infraccionar todas las faltas que reportan los
fiscales de la empresa TREBOL.
Los registros de las primeras observaciones sern nicos, para las posteriores
observaciones se contaran las incidencias de las mismas observaciones.
Emisin de reportes e informes peridicos (Diario semanal o mensual) por tiempos de
servicio, definido por el usuario.
Se definir diferentes tipos de usuario los cuales cada uno de ellos contaran con diferentes
procesos que estn asociados directamente a las asignaciones dentro de la institucin
Registro de todas las entidades que trabajan en la empresa TREBOL, para el debido
almacenamiento de datos e informacin.
1.5.2. Limites

El proyecto no realizara las siguientes tareas:
No controlara al personal administrativo de ambas empresas ya que solo se
dedicara al seguimiento a los servicios de aseo.
El sistema se limitara al registro, alerta e infraccin y no as a la sancin econmica
que estn a cargo de otras direcciones de ambas empresas.
No emitir informes aparte de los mencionados en los objetivos especficos.
El sistema no dar multa automtica a las infracciones cometidas o encontradas.

CAPITULO II
MARCO TERICO

2.1 INTRODUCCIN
En este captulo presentamos en primera instancia un resuman del fundamento terico de la
metodologa eXtrme Programming (XP), WebML, FrameWorks Grails que ser utilizada
para el desarrollo del presente proyecto, en una apartado siguiente se hace una descripcin
de algunas de algunas herramientas tecnolgicas.
2.2 INGENIERIA DE SOFTWARE
La Ingeniera del Software es una disciplina o rea de la informtica o ciencias de la
computacin, que ofrece mtodo y tcnicas para desarrollar y mantener software de calidad
que resuelven problemas de todo tipo. Hoy da es cada vez ms frecuente la consideracin
de la Ingeniera del Software como un nueva rea de la ingeniera, y el Ingeniero del
Software comienza a ser una profesin implantada en el mundo laboral internacional, con
derechos, deberes y responsabilidades que cumplir, junto a una, y reconocida consideracin
social en el mundo empresarial y, por suerte, para esas personas con brillante futuro.
2.2.2 Metodologas Agiles
El desarrollo gil de software es un conjunto de mtodos de desarrollo de software basado
en el desarrollo iterativo e incremental de , donde las necesidades y soluciones evolucionan
a travs de la colaboracin entre la auto-organizacin , los equipos multifuncionales . Se
promueve la planificacin adaptativa, desarrollo evolutivo y la entrega, un enfoque iterativo
de tiempo en caja, y alienta a la rpida y una respuesta flexible a los cambios. Se trata de un
marco conceptual que promueve las interacciones previstas durante todo el ciclo de
desarrollo.
2.3 PROGRAMACION EXTREMA
Alrededor de cmo hacer software hay un gran nmero de autores teoras, propuestas, etc.,
se tratara de presentar una disciplina de desarrollo de software, la programacin extrema.

2.3.1 Qu es la programacin extrema (XP)?
XP (eXtreme Programing) nace como nueva disciplina de desarrollo de software y ha
causado un gran revuelo entre el colectivo de programadores del mundo. Kent Beck, su
autor, es un programador que ha trabajado en mltiples empresas y que actualmente lo hace
como programador en la conocida empresa automovilstica DaimlerChrysler. Con sus
teoras ha conseguido el respaldo de gran parte en la industria del software y el rechazo de
otra parte.
La programacin extrema se basa en la simplicidad, la comunicacin y el reciclado
continuo de cdigo, para algunos no es ms que aplicar una pura lgica.
2.3.4 Fases del XP

2.3.4.1 Fase 1: Planificacin del proyecto

XP plantea la planificacin como un permanente dilogo entre la parte empresarial y
tcnica del proyecto, en la que los primeros decidirn el alcance qu es lo realmente
necesario del proyecto?, la prioridad qu debe ser hecho en primer lugar, la
composicin de las versiones qu debera incluir cada una de ellas y la fecha de las
mismas. En cuanto a los tcnicos, son los responsables de estimar la duracin requerida
para implementar las funcionalidades deseadas por el cliente, de informar sobre las
consecuencias de determinadas decisiones, de organizar la cultura de trabajo y, finalmente,
de realizar la planificacin detallada dentro de cada versin. XP no es slo un mtodo
centrado en el cdigo que lo es, sino que sobre todo es un mtodo de gestin de
proyectos software. [Beck, 2000]
a) Historias de usuario
El primer paso de cualquier proyecto que siga la metodologa X.P es definir las historias de
usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de
uso pero con algunas diferencias: Constan de 3 o 4 lneas escritas por el cliente en un
lenguaje no tcnico sin hacer mucho hincapi en los detalles; no se debe hablar ni de
posibles algoritmos para su implementacin ni de diseos de base de datos adecuados, etc.
Son usadas para estimar tiempos de desarrollo de la parte de la aplicacin que describen.
Tambin se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que
especifica la historia de usuario. Cuando llega la hora de implementar una historia de
usuario, el cliente y los desarrolladores se renen para concretar y detallar lo que tiene que
hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3
semanas.
b) Release planning*
Despus de tener ya definidas las historias de usuario es necesario crear un plan de
publicaciones, en ingls "Release plan", donde se indiquen las historias de usuario que se
crearn para cada versin del programa y las fechas en las que se publicarn estas
versiones.
Un "Release plan" es una planificacin donde los desarrolladores y clientes establecen los
tiempos de implementacin ideales de las historias de usuario, la prioridad con la que sern
implementadas y las historias que sern implementadas en cada versin del programa.
Despus de un "Release plan" tienen que estar claros estos cuatro factores: los objetivos
que se deben cumplir (que son principalmente las historias que se deben desarrollar en cada
versin), el tiempo que tardarn en desarrollarse y publicarse las versiones del programa, el
nmero de personas que trabajarn en el desarrollo y cmo se evaluar la calidad del
trabajo realizado. (*Release plan: Planificacin de publicaciones).
c) Iteraciones
Todo proyecto que siga la metodologa X.P. se ha de dividir en iteraciones de
aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los clientes deben
seleccionar las historias de usuario definidas en el "Release planning" que sern
implementadas. Tambin se seleccionan las historias de usuario que no pasaron el test de
aceptacin que se realiz al terminar la iteracin anterior. Estas historias de usuario son
divididas en tareas de entre 1 y 3 das de duracin que se asignarn a los programadores.
d) Velocidad del proyecto
La velocidad del proyecto es una medida que representa la rapidez con la que se desarrolla
el proyecto; estimarla es muy sencillo, basta con contar el nmero de historias de usuario
que se pueden implementar en una iteracin; de esta forma, se sabr el cupo de historias
que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto
controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la
iteracin. Es conveniente revaluar esta medida cada 3 o 4 iteraciones y si se aprecia que no
es adecuada hay que negociar con el cliente un nuevo "Release Plan".
e) Programacin en pareja
La metodologa X.P. aconseja la programacin en parejas pues incrementa la productividad
y la calidad del software desarrollado. El trabajo en pareja involucra a dos programadores
trabajando en el mismo equipo; mientras uno codifica haciendo hincapi en la calidad de la
funcin o mtodo que est implementando, el otro analiza si ese mtodo o funcin es
adecuado y est bien diseado. De esta forma se consigue un cdigo y diseo con gran
calidad.
f) Reuniones diarias
Es necesario que los desarrolladores se renan diariamente y expongan sus problemas,
soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el mundo
tiene que tener voz y voto.
2.3.4.2 Fase 2: Diseo.
a) Diseos simples
La metodologa X.P sugiere que hay que conseguir diseos simples y sencillos. Hay que
procurar hacerlo todo lo menos complicado posible para conseguir un diseo fcilmente
entendible e implemntable que a la larga costar menos tiempo y esfuerzo desarrollar.
b) Glosarios de trminos
Usar glosarios de trminos y una correcta especificacin de los nombres de mtodos y
clases ayudar a comprender el diseo y facilitar sus posteriores ampliaciones y la
reutilizacin del cdigo.
c) Riesgos
Si surgen problemas potenciales durante el diseo, X.P sugiere utilizar una pareja de
desarrolladores para que investiguen y reduzcan al mximo el riesgo que supone ese
problema.
d) Funcionalidad extra
Nunca se debe aadir funcionalidad extra al programa aunque se piense que en un futuro
ser utilizada. Slo el 10% de la misma es utilizada, lo que implica que el desarrollo de
funcionalidad extra es un desperdicio de tiempo y recursos.
e) Refactorizar
Refactorizar es mejorar y modificar la estructura y codificacin de cdigos ya creados sin
alterar su funcionalidad. Refactorizar supone revisar de nuevo estos cdigos para procurar
optimizar su funcionamiento. Es muy comn rehusar cdigos ya creados que contienen
funcionalidades que no sern usadas y diseos obsoletos. Esto es un error porque puede
generar cdigo completamente inestable y muy mal diseado; por este motivo, es necesario
refactorizar cuando se va a utilizar cdigo ya creado.
f) Tarjetas C.R.C.
El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration) permiten al
programador centrarse y apreciar el desarrollo orientado a objetos olvidndose de los malos
hbitos de la programacin procedural clsica.
.Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se puede
escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden escribir
las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las clases que
colaboran con cada responsabilidad.
2.3.4.3 Fase 3: Codificacin.
a) El cliente est siempre disponible
El cliente es una parte ms del equipo de desarrollo; su presencia es indispensable en las
distintas fases de X.P. A la hora de codificar una historia de usuario su presencia es an
ms necesaria. No olvidemos que los clientes son los que crean las historias de usuario y
negocian los tiempos en los que sern implementadas. Antes del desarrollo de cada historia
de usuario el cliente debe especificar detalladamente lo que sta har y tambin tendr que
estar presente cuando se realicen los test que verifiquen que la historia implementada
cumple la funcionalidad especificada.
c) Desarrollar la unidad de pruebas primero
Crear test que prueben el funcionamiento de los distintos cdigos implementados nos
ayudar a desarrollar dicho cdigo. Crear estos test antes nos ayuda a saber qu es
exactamente lo que tiene que hacer el cdigo a implementar y sabremos que una vez
implementado pasar dichos test sin problemas ya que dicho cdigo ha sido diseado para
ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a programar en
pequeas unidades, de esta forma se crearn primero los test para cada unidad y a
continuacin se desarrollar dicha unidad, as poco a poco conseguiremos un desarrollo que
cumpla todos los requisitos especificados.
2.3.4.4 Fase 4: Pruebas.
Un punto importante es crear test que no tengan ninguna dependencia del cdigo que en un
futuro evaluar. Hay que crear los test abstrayndose del futuro cdigo, de esta forma
aseguraremos la independencia del test respecto al cdigo que evala.
Como se coment anteriormente los distintos test se deben subir al repositorio de cdigo
acompaados del cdigo que verifican. Ningn cdigo puede ser publicado en el
repositorio sin que haya pasado su test de funcionamiento, de esta forma, aseguramos el uso
colectivo del cdigo.
2.4 INGENIERIA WEB
La ingeniera Web est relacionada con el establecimiento y utilizacin de principios
cientficos, de ingeniera y gestin, y con enfoques sistemticos y disciplinados del xito y
desarrollo, empleo y mantenimiento de sistemas y aplicaciones basados en el Web de alta
calidad [PRE03]
2.4.1 Metodologas de Modelado WEB
Dentro de la variabilidad que ofrecen los sistemas de informacin global, existen muchas
tendencias de metodologas que ofrecen diferentes marcos que los desarrolladores pueden
asumir a la hora de realizar su trabajo. Estos trabajos estn orientados a diferentes entornos
de trabajo: aplicaciones multimedia, aplicaciones en la web, bibliotecas digitales, entre
otras.
2.5 WEBML

Tal y como sus propias autores lo definen, WebML [Ceri et al. 2000], [Ceri et al. 2003] es
una notacin para especificar complejos sitios web en el mbito conceptual [Ceri et al.
2002]. Permite una descripcin de los sitios web desde distintos puntos de vista: el
conceptual, el navegacional, el de presentacin, etc.
El proceso de desarrollo comienza con el modelado conceptual del sistema, en el que
mediante algn lenguaje de modelado como UML, WebML no exige ninguno en concreto,
se representa la estructura esttica del sistema.
Tras esto, se realiza el modelo de hipertexto en el que se describen uno o ms hipertextos
que pueden ser publicados en el sitio web. Cada uno de estos hipertextos define una vista
del sitio.
La descripcin de los hipertextos se realiza mediante dos modelos: el modelo de
composicin, que define las pginas que componen el sistema, y el modelo de navegacin,
que describe cmo se podr navegar a travs de ellas.
En el siguiente paso del proceso se describe el modelo de presentacin, que define la
apariencia fsica de las pginas.
Y por ltimo, el modelo de personalizacin define como debe adaptarse el sistema a los
2.6 GRAILS
Es un FrameWorks para desarrollo de aplicaciones Web construido sobre cinco fuertes
pilares.
Groovy para la creacin de propiedades y mtodos dinmicos en los objetos de la
aplicacin
Spring para os flujos de trabajo e inyeccin de dependencias
Hibernate para la persistencia.
SiteMesh para la composicin de la vista.
Ant para la gestin de proceso de desarrollo.
2.7 MySQL
MySQL es un sistema de gestin de bases de datos relacional, licenciado bajo la GPL de la
GNU. Su diseo multihilo le permite soportar una gran carga de forma muy eficiente.
MySQL fue creada por la empresa sueca MySQL AB, que mantiene el copyright del cdigo
fuente del servidor SQL, as como tambin de la marca.

CAPITULO III
MARCO APLICATIVO

3.1 INTRODUCCION
En este captulo se describir el mbito aplicativo de la investigacin, plasmando los
requerimientos generales del cliente y el proceso de desarrollo de los componentes de la
aplicacin y su adaptacin a la metodologa aplicada, en este caso Programacin Extrema
(XP, por sus siglas en ingls). Tambin mencionar que en el presente capitulo realizamos la
fusin del lenguaje de modelado WebML con la metodologa de desarrollo XP
Programacin Extrema.
Finalmente se explica la adaptacin del proceso de desarrollo (XP) y sus prcticas, llevadas
al desarrollo del proyecto, en cada una de sus iteraciones o fases.
Este proceso se lo desarrolla de la siguiente manera:
Para dar solucin a la problemtica y con un previo estudio del caso se vio
conveniente dividir el sistema en mdulos e introducir estos mdulos en un
iteracin de XP.

3.2. REQUERIMIENTOS GENERALES
A gran escala, el proyecto busca automatizar el proceso de sancin a los servicios de Aseo
de la Ciudad de el Alto
El proceso de llamado, consisti primordialmente en el registro de una observacin de un
distrito, junto con cierta informacin adicional, donde dicha ser instanciada si no se
corrige en el transcurso de cierto tiempo.
Adems de ese proceso, se requiere tener cierta informacin que sera:
Penalizacin. Es un proceso que se realiza en el transcurso de del registro de la
observacin en el cual deber adecuar la observacin a una penalidad.
Frecuencias: proceso en el que una observacin (especial tiene la posibilidad de tener una
frecuencia.
Modificacin: proceso en el que se pueda retractas una observacin ya realizada bajo
ciertas caractersticas.
Cabe destacar que se desea conocer en todo momento el estatus de las llamadas.
Se requieren distintos perfiles en la aplicacin, entre los cuales tenemos:
Operador: usuario encargado nicamente de la realizacin de registros de llamadas de los
fiscales.
Supervisor: usuario encargado de monitorear el estatus de las llamadas hechas por
operadores, posibilidad de hacer alguna modificacin en el registro.
Administrador: usuario encargado de la gestin y supervisin de todo el sistema.
Pudiendo ver las estadsticas de ventas, ingresar nuevos usuarios al sistema y capaz de
realizar labores de los perfiles del validador y supervisor, entre otras funciones.
Se requiere automatizar el proceso de carga de posibles clientes en el sistema.
3.3 ADAPTACION DEL PROCESO DE DESARROLLO XP Y WEBML
Como se mencion en el segundo captulo de la investigacin, el proceso de desarrollo XP
es ligero y capaz de manejar los requerimientos cambiantes del cliente, tenindolo bastante
involucrado con el desarrollo.
En esta seccin se ilustrar la adaptacin de WebML en el proceso de desarrollo de la
programacin extrema en la presente investigacin. Puesto que WebML es un lenguaje de
modelado para la web y nos brinda un conjunto de modelos se lo incorporo en la segunda
fase de XP, Modelado, haciendo hincapi en los diversos modelos web, de navegacin,
Hipertextualidad, etc., que nos brinda esta metodologa y fortaleciendo el proyecto en el
entorno web.
El proceso de desarrollo de software XP est basado en entregas e iteraciones. Se dividi el
proyecto en 4 iteraciones, con un tiempo aproximado de 2 a 3 semanas por iteracin.
En cada iteracin se aplicarn las siguientes prcticas: Planificacin, Diseo,
Codificacin.
Dado que este proyecto se realizara por una sola persona, no ser posible la aplicacin de la
prctica de programacin en pareja.
3.4 ITERACION 0
En la iteracin 0 se defini la planificacin general de todo el proceso de desarrollo de los
componentes de software que se realizaron en la investigacin en el cual se lleg a la
conclusin de desarrollar 4 mdulos, los cuales se atacaran uno por iteracin.
3.5 ITERACION 1: I.- MODULO DE ADMINISTRACION DE CUENTAS DE
USUARIOS
Es en esta iteracin desarrollaremos el Modulo de Administracin de roles de Usuario ya
que en este mdulo se encuentran muchas clases bases del sistema que sin ellas no se
podra dar desarrollo al sistema.
A continuacin detallaremos un listado de Historia de Usuarios en orden de importancia.

Nro. de Historia Historia de Usuario
Historia 1 Registro de Persona
Historia 2 Asignar Rol Usuario
Historia 3 Registrar de Modulo
Historia 4 Registrar de Rol

3.5.1 Fase I: Planificacin
En esta fase se realizan historias de usuario del primer mdulo que atacaremos, para que se
familiarice con la tecnologa como tambin en el desarrollo del proyecto.
Estas tareas estn como mdulo 1 porque con ellas se podr realizar el correspondiente
registro de observaciones, ya que cada observacin depende de la mayora de estas
entidades.

Historia 1
La primera historia de usuario describe el registro del personal ya que es un componente
muy importante para la administracin de roles.
Historia de Usuario
Numero: 1 Nombre historia de usuario: Registro de personal
Usuario: Administrador Iteracin Asignada: 1
Prioridad en negocio: Media Puntos Estimados: 1/2
Riesgo en Desarrollo: Media Puntos Reales: 1/2
Descripcin:
El sistema debe poder almacenar los datos personales del funcionario (C.I., Apellidos,
Nombres, sexo, fecha de nacimiento, telfono, direccin), fecha de ingreso. Para
administrar de forma adecuada se debe llevar un archivo de todo el personal.

Observaciones: El personal que se toma en cuenta es solo el que interacta con el sistema.

Como primera tarea tenemos que disear la estructura de datos para esta historia de usuario.
Tarea
Numero de tarea: 1 Nombre historia de usuario: 1. Registro de personal
Nombre de la tarea: Disear la estructura para el registro de personal
Tipo de tarea: Diseo Puntos Estimados: 1/2
Programador responsable: Mayra Alejandra Galvez Ticona
Descripcin: Se realiza el diseo de la base de datos para el registro del personal que
interacta con el sistema

Como segunda tarea tenemos que disearan interfaces de usuario entendibles para los
usuarios.
Tarea
Numero de tarea: 2 Nombre historia de usuario: 1. Registro de personal
Nombre de la tarea: Interfaz de usuario
Tipo de tarea: Desarrollo Puntos Estimados: 1/2
Programador responsable: Mayra Alejandra Galvez Ticona
Descripcin: Se disearan interfaces de usuario entendibles para los usuarios

Como siguiente tabla mostramos la siguiente tarea, que es desarrollar un proceso que
permita ingresar los datos personales de un funcionario y los pueda almacenar en la base de
datos.
Tarea
Numero de tarea: 3 Nombre historia de usuario: 1. Registro de personal
Nombre de la tarea: Aadir personal
Tipo de tarea: Desarrollo Puntos Estimados: 1/2
Programador responsable: Mayra Alejandra Galvez Ticona
Descripcin: Desarrollar un proceso que permita ingresar los datos personales de un
funcionario y los pueda almacenar en la base de datos.


En la siguiente tarea tenemos que desarrollar un proceso y el interfaz que permita realizar
el listado del personal.
Tarea
Numero de tarea: 4 Nombre historia de usuario: 1. Registro de personal
Nombre de la tarea: Listado personal
Tipo de tarea: Desarrollo Puntos Estimados: 1/2
Programador responsable: Mayra Alejandra Galvez Ticona
Descripcin: Desarrollar un proceso y el interfaz que permita realizar el listado del
personal.


Como ultima tarea tendremos que desarrollar un proceso que permita hacer la edicin de
algn registro ya existente.
Tarea
Numero de tarea: 5 Nombre historia de usuario: 1. Registro de personal
Nombre de la tarea: Edicin del personal
Tipo de tarea: Desarrollo Puntos Estimados: 1/2
Programador responsable: Mayra Alejandra Galvez Ticona
Descripcin: Desarrollar un proceso que permita hacer la edicin de algn registro
ya existente.


En esta tabla de Historias de Usuario se muestra los puntos que cada historia de usuario
tiene donde cada punto es equivalente a una semana de trabajo.
Historia de Usuario Puntos
Historia 1: Registrar de Personal 1/2
Historia 2: Asignar Rol Usuario 1/2
Historia 3: Registrar Modulo 1/2
Historia 4: Registrar Rol 1/2

Planificacin de Historias, en esta tablas se mostrara el tiempo en el que se realizaran
las historias de usuarios programadas en este modulo
ITER. N HISTORIA INICIO FIN OBSERVACION
1ra 1 Registrar de Personal 1-2-2012 3-2-2012 Solo Usuarios
Clasificados
2 Registrar de Rol
usuario
4-2-2012 7-2-2012 Solo Usuarios
Clasificados
3 Registrar Modulo 8-2-2012 10-2-2012 Solo Usuarios
Clasificados
4 Registrar Rol 11-02-
2012
14-02-
2012
Solo Usuarios
Clasificados

3.5.2 Fase II: Diseo
En esta fase se modelo una estructura con las clases siguientes: Personal, Rol de Usuario,
Usuario, Dando ya una base para el desarrollo del sistema.
3.5.2.1 Tarjetas CRC
En estas tarjetas CRC describimos todas las clases que estn involucradas en este modulo

CONTROLADOR
Esta clase se encarga
de almacenar los
controladores que se
tendr en el sistema
Modulo

MODULO
Esta clase registra la
cantidad de mdulos del
que consta el sistema




3.5.2.2 Modelado (WEBML)
En la parte de modlalo haremos una fusin con WebML ya que nos brinda un conjunto de
modelos especializados para el diseo web.
Modelo de datos: administracin de Mdulos
Como primer modelo de WebML tenemos el modelos de datos que nos describe las cases
que intervendrn en el primer mdulo de Administracin de cuentas de Usuario




Modelo de Hipertexto
Como segundo modelo de WebML tenemos el Modelo de hipertexto que representa la
navegacin que tendrn los usuarios en este mdulo dependiendo del tipo de rol que tenga
el usuario.
Modelo de Hipertexto Administrador



Modelo de Presentacin
Como tercer modelo de WebML tenemos el modelo de presentacin que muestra un
esquema de la vista del administrador del sistema.

3.5.3 Fase III: Codificacin
Para la codificacin se desarroll todas las historias de usuario planeadas donde se
desarroll la parte de asignacin de roles a los usuario, ya que con esta parte se podra
asignar roles a los distintos usuarios del sistema para poder tener una mejor administracin
del sistema.


En el siguiente diagrama mostramos una captura de pantalla del cdigo que se est
utilizando para este mdulo.


3.5.4 Fase IV: Pruebas
Se realizaron un conjunto de pruebas de registro. Dichas pruebas involucraban acciones
bsicas de guardado, Edicin y listados verificando simultneamente la base de datos para
ver si se realiz el registro correspondiente.
3.6 ITERACION 2: II. MODULO DE ADMINISTRACION DE PARAMETROS
Es en esta iteracin desarrollaremos el mdulo de administracin de los parmetros del
sistema porque sin estos datos no se podr realizar el siguiente modulo, ya que su
informacin es de mucha importancia.
A continuacin detallaremos un listado de Historia de Usuarios en orden aleatorio.
Nro. de Historia Historia de Usuario
Historia 5 Registro de Conductor
Historia 6 Asignar Rol Distrito
Historia 7 Registrar Zonas
Historia 8 Registrar Entidad
Historia 9 Registro de Frecuencia
Historia 10 Registro de Vehculos
Historia 11 Registro de Infracciones
3.7. ITERACION 3: III- MODULO DE REGISTRO Y PENALIZACION
En la tercera iteracin se procedi a implementar Registro y penalizacin de infracciones
considerando que se tenan dos tipos de infracciones.
3.7.1 Fase I: Planificacin
En esta fase se desarrollaron las siguientes Historias de Usuario dando nfasis a la
penalizacin de las infracciones y tratando de abarcar todos los casos posibles con las
historias de usuarios que se realizaron.
Nro. de Historia Historia de Usuario
Historia 12 Registro de Observaciones
Historia 13 Registro de Observacin o Reporte(N)
Historia 14 Registro de Observaciones Especiales
Historia 15 Evaluacin de las Observaciones
3.8 ITERACION 4: IV- MODULO DE ESTADISTICAS Y REPORTES
En la cuarta iteracin desarrollamos el mdulo de reportes de observaciones, realizando los
reportes ms solicitados segn los requerimientos del cliente.
3.8.1 Fase I: Planificacin
En esta fase se realizan historias de usuario para que se familiarice con la tecnologa como
tambin en el desarrollo del proyecto.
A continuacin mostramos la historia de usuario de estadistas y reportes.
La siguiente tablas nos muestra el detalle de las Historias de Usuario con las tareas
respectivas del cuarto modulo.
Nro. de Historia Historia de Usuario
Historia 16: Estadsticas y
Reportes
Tarea1: Generar Reporte


CAPITULO IV
CONCLUSIONES Y RECOMENDACIONES

4.1 INTRODUCCION

En este captulo detallaremos las conclusiones y el daremos algunas recomendaciones para
el uso del sistema.
4.2 Conclusiones
Tras todos los aspectos destacados a lo largo de estos apartados y de todo el proyecto, poco
queda que decir. Durante El desarrollo del proyecto se ha presentado un trabajo que ha
comenzado con un planteamiento del problema basado en los resultados y conclusiones
resultantes de trabajos comparativos.

El resto del trabajo se ha dividido en dos partes: una parte terica, que engloba el grueso de
la documentacin, y que est compuesta por la definicin de los modelos y de las y una
fusin de dos metodologas, y una segunda parte que acerca el contenido terico al entorno
prctico representada por XP-WEBML.

El trabajo presentando resulta novedoso en cuanto al tratamiento que se propone para la
navegacin en las primeras etapas del ciclo de vida, aadiendo, adems un importante
soporte en el desarrollo con los procesos de XP que se obtienen desde el estudio de las
relaciones entre modelos. Es un trabajo pionero en su entorno por mltiples motivos, como
se ha presentado en el documento, y ha dado resultados ptimos.

En el inicio se hizo el estudio correspondiente al caso y se tom los datos pertinentes para
el diseo de los mdulos, tambin se realizaron reuniones para que se analizara si el
producto estaba cumpliendo con las necesidades de los funcionarios.
Por tanto se llegaron a cumplir cada uno de los objetivos especficos:
Se dise una Base de Datos que nos permite guardar toda la informacin
necesaria y en el momento de realizar alguna bsquedas se lo realiza consultando
la base de datos
Se realiz los registros de forma automtica teniendo ya los datos necesarios en el
sistema.
Se desarrollar scripts para generar los reportes de forma automtica, as se
optimizo el tiempo de emisin
Se manejar toda la informacin posible de forma digital para evitar la cantidad
masiva de papeles.
Ya no existe perdida de informacin, Ahora se podr realizar una buena auditoria
ala sistema.
La informacin que se da a EMALT y TREBOL es en tiempo real.
Se mantiene actualizada la informacin de la base de datos, por altas, bajas y
modificaciones.
Se generar de forma automtica informes y reportes de acuerdo a las necesidades
de la institucin, evitando retrasos en la entrega de los resultados.
Se jerarquizo a los usuarios del sistema dando privilegios segn el tipo de usuario
que sean.
Se realiz un reporte que nos permita saber que personas utilizaron el sistema y
para que lo utilizaron dndonos la hora y la fecha exacta para que en algn
momento se pueda realizar una auditora si fuera necesario.
Cumplido todos los objetivos especficos se cumpli el objetivo general:
Se concluy el sistema Web de Seguimiento y control de los servicios de aseo de la
ciudad de El Alto, para que la empresa EMALT automatice las actividades de los
operadores.
4.3. Recomendaciones
Establecer un entorno que disponga de unas condiciones apropiadas para el uso del
SCSA
Las caractersticas del entorno en el que se encuentran ubicado del SCSA pueden
contribuir a que se produzcan errores. Numerosos errores comunicados a los
programas de notificacin presentan como factor contribuyente comn unas
condiciones ambientales inapropiadas, fundamentalmente un entorno de trabajo
ruidoso y un rea de trabajo ocupada y desordenada.
Garantizar la seguridad de los SCSA
Se deben establecer procedimientos de seguridad para garantizar el control
adecuado de los registros almacenados y evitar la posibilidad de que se produzcan
registros no justificados de observaciones.
Establecer un procedimiento explcito para la asignacin de nuevos usuarios y
contraseas que defina claramente la jerarquizacin de niveles de acceso por tipo de
usuario, el departamento responsable y el procedimiento para cambiar y/o actualizar
las contraseas.
Definir los niveles de acceso de cada usuario en funcin de la necesidad de
restringir el acceso a determinadas tareas, dependiendo de la unidad donde est
ubicado el SCSA.
Prohibir explcitamente que se compartan o se reutilicen contraseas.
Asignar contraseas para usuarios temporales por un periodo de tiempo finito.
Establecer y mantener un contenido apropiado de los SCSA
El contenido del SCSA debe establecerse y actualizarse en funcin del tipo de
cambios que se vayan realizando en datos. Los tipos y los recorridos de las zonas y
los usuarios incluidos en los SCSA
Definir procedimientos seguros para la retractacin de una observacin o un reporte de
SCSA
La retractacin de los reportes u observaciones del SCSA es de manera directa y
es por eso que es importante disear un procedimiento con redundancias, para que
siempre que sea necesario se lo realice de manera correcta.
Las recomendaciones que se harn a continuacin son de manera personal, segn a la
experiencia obtenida en el transcurso de la elaboracin del sistema.
El sistema debera de tener una mantenimiento anual para filtrar informacin que
ya no se de utilidad para evitar reconduca de informacin por algn caso.
Para la visualizacin del sistema se recomienda el uso del explorador Mozilla Fire
Fox, Google Chrome, Safari y no as el Internet Explorer ya que con este ltimo el
sistema muestra ciertas incoherencias.
Realizar Backups peridicamente para evitar prdidas de informacin en algn
caso.
Se recomienda a EMALT que a partir del sistema se ample a un sistema que
abarque ms reas de la empresa.